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
https://netmind.net/en/prisoners-of-the-organization-chart-how-the-configuration-of-teams-conditions-software-development/
Slide 19
Slide 19 text
And there are always some constraints
Slide 20
Slide 20 text
Attributes
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
Modeling/Design
Slide 26
Slide 26 text
Simple != Easy
Rick Hickey “Simple made easy” https://www.youtube.com/
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
Technology
Mapping
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
architecture
http://www.flickr.com/photos/hyperclouds/459716791/
Slide 55
Slide 55 text
Leap
Slide 56
Slide 56 text
Parallel
Slide 57
Slide 57 text
Simplification
Slide 58
Slide 58 text
Stepping Stone