Slide 1

Slide 1 text

Software Design, Architecture and the secrets of the universe (WIP) Arnon Rotem-Gal-Oz

Slide 2

Slide 2 text

The Vasa

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

What is software design?

Slide 5

Slide 5 text

What is software architecture?

Slide 6

Slide 6 text

That thing that software architects do

Slide 7

Slide 7 text

Decisions we wish we got right

Slide 8

Slide 8 text

Software architecture is the fundamental concepts or properties of a system, embodied in its elements, relationships [to each other and the environment], and in the principles of its design and evolution (IEEE 42010:2022 Software, systems and enterprise — Architecture description)

Slide 9

Slide 9 text

Software design Software architecture is the concepts or properties of a component, embodied in its elements, relationships [to each other and the environment], and in the principles of its design and evolution within the constraints of the system architecture

Slide 10

Slide 10 text

Can you design something that doesn’t work with the overall architecture?

Slide 11

Slide 11 text

The differnece between Theory and Practice

Slide 12

Slide 12 text

Scope of design • Dog house • Dream house • Sky scrapper

Slide 13

Slide 13 text

Architecture Quality Attributes Technology Patterns & Anti-patterns Principles Community experience Stakeholders Design Constraints Requirements

Slide 14

Slide 14 text

The Usual Suspects Customer End-User Project Manager Management Developers Maintainers Security Analysts Project New comers Testers Customer’s IT group

Slide 15

Slide 15 text

Principles, Heuristics and Constraints

Slide 16

Slide 16 text

Amdahl’s law maximum potential improvement to the performance of a system is limited by the portion of the system that cannot be improved

Slide 17

Slide 17 text

Gall’s Law • “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a simple system.”

Slide 18

Slide 18 text

Conway’s Law

Slide 19

Slide 19 text

And there are always some constraints

Slide 20

Slide 20 text


Slide 21

Slide 21 text

Quality Attributes • Performance • Availability • Usability • Security ● Maintainability ● Portability ● Reusability ● Testability End User’s view Developer’s view ● Time To Market ● Cost and Benefits ● Projected life time ● Targeted Market ● Integration with Legacy System ● Roll back Schedule Business Community view A list of quality attributes exists in ISO/IEC 9126-2001 Information Technology – Software Product Quality

Slide 22

Slide 22 text

The secret to Quality Attribute Analysis is writing down Scenarios

Slide 23

Slide 23 text

Utility Performance Response Under normal conditions - update of an entity in the persistent storage <0.5 Second Latency Under normal or stress conditions, critical alert generated by the system will be displayed in less than 1 seconds (for generation) Data Loss under all conditions, a message acknowledged by the system will not be lost Availability Hardware Issues Under all conditions, when a server crash, the system will resume operation in less than 30 seconds Usability Compliance The system should comply with maritime data standards (e.g. Mercator projection) Operability The system should handle user request without impeding the user's ability to continue controlling the system (e.g. initiate additional requests) Security Unauthorized users under normal conditions and connectivity the system should alert an unauthorized login attempt (intrusion) within 1 minute Adaptability More Users When additional users need access to the system, add new /more hardware (to support load) under 4 man weeks Identify and prioritize scenarios

Slide 24

Slide 24 text

Anatomy of a scenario Under normal system load an activity upsert should take under 10ms 50th percentile, 50ms 99th percentile , 100ms 99.5th percentile Context Stimulus Response

Slide 25

Slide 25 text


Slide 26

Slide 26 text

Simple != Easy Rick Hickey “Simple made easy” watch?v=LKtk3HCgTa8

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

Law of demeter • Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. • Each unit should only talk to its friends; don't talk to strangers. • Only talk to your immediate friends.

Slide 29

Slide 29 text

It is always a trade-off

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

Patterns – because you don’t need to re-invent the wheel

Slide 33

Slide 33 text

How can you efficiently provide a level of guarantee in a loosely coupled manner while maintaining the autonomy and consistency of the services? Implement the Reservation pattern and have the services provide a level of guarantee on internal resources for a limited time.

Slide 34

Slide 34 text

If you want the architecture to be followed 
 it has to be communicated

Slide 35

Slide 35 text

 Two roads diverged in a yellow wood, 
 And sorry I could not travel both 
 And be one traveler, long I stood 
 And looked down one as far as I could 
 To where it bent in the undergrowth (The road not taken, Robert Frost 1915)

Slide 36

Slide 36 text

When you present consider your 
 target audience

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text


Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

Architecture Quality Attributes Technology Patterns & Anti-patterns Principles Community experience Stakeholders Design Constraints Requirements Where are we at?

Slide 42

Slide 42 text

OK then, so we are all set

Slide 43

Slide 43 text

The architecture has to be Evaluated to make sure it is any good

Slide 44

Slide 44 text

Consider Risk vs. Time to invest

Slide 45

Slide 45 text

All we have to do now is to deploy the architecture

Slide 46

Slide 46 text

Stakeholders Principles Attributes Modeling Mapping Evaluation Deployment

Slide 47

Slide 47 text

It is “easy” in waterfall & incremental

Slide 48

Slide 48 text

Can Agile and Architecture work together?

Slide 49

Slide 49 text

Building in small iterations 
 can be dangerous

Slide 50

Slide 50 text

Winchester Mystery House

Slide 51

Slide 51 text

How much design we need? “Design Stamina Hypothesis” Martin Fowler

Slide 52

Slide 52 text

Just enough design up-front Component A Component B Component C Component D Component F Component H Component I

Slide 53

Slide 53 text

Walking Skeleton

Slide 54

Slide 54 text

Evolve the 

Slide 55

Slide 55 text


Slide 56

Slide 56 text


Slide 57

Slide 57 text


Slide 58

Slide 58 text

Stepping Stone