Scribd
Upload
81 views10 pages

Software Architecture & High Level Design: All The Really Important Mistakes Are Made The First Day

Uploaded by

Ta-Sin Aqib
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
81 views10 pages

Software Architecture & High Level Design: All The Really Important Mistakes Are Made The First Day

Uploaded by

Ta-Sin Aqib
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

18-642:

Software Architecture &


High Level Design
9/27/2018

All the really important mistakes


are made the first day.
– Eberhardt Rechtin,
© 2017 Philip Koopman System Architecting © 2017 Philip Koopman 1
YOU ARE HERE
SPECIFY TRACEABILITY & VALIDATION ACCEPTANCE
PRODUCT
PRODUCT Test Plan & Test Results TEST
Product Software Test
Requirements Results

SPECIFY SOFTWARE
SOFTWARE Test Plan & Test Results TEST

Software Requirements Integration Test Results

CREATE SW INTEGRATION
ARCHITECTURE Test Plan & Test Results TEST

High Level Design Unit Test Results


Test
DESIGN Plan & UNIT
MODULES Test TEST
Results
Detailed Design Source Code

IMPLEMENT
© 2017 Philip Koopman 2
Architecture & High Level Design (HLD)
 Anti-Patterns:
 Skipping from requirements to code
 No picture that shows how all the
components fit together
 “Wedding cake” layer diagram that
omits interface information

 Elements of High Level Design https://goo.gl/J8MAuK

 Architecture: boxes, arrows, interfaces


– Arrows/interfaces show communication paths between components
– Recursive: one designer’s system is another designer’s component
 High Level Design (HLD) = architecture (nouns) + requirements (verbs)
– Sequence Diagrams (SDs) show interactions © 2017 Philip Koopman 3
Architecture: Boxes and Arrows
 Software architecture
shows the big picture
 Boxes: software modules/objects
 Arrows: interfaces
 Box and arrow semantics well-defined
– Meaning of box/arrow depends on goal
 Components all on a single page
https://goo.gl/WnciF3
– Nesting of diagrams is OK

 Many different architecture diagrams are possible, such as:


 Software architecture (components and data flow types)
 Hardware architecture with software allocation
 Controls architecture showing hierarchical control
 Call graph showing run-time hierarchy © 2017 Philip Koopman 4
Sequence Diagram as HLD Notation
 SD construction:
 Each object has a time
column extending downward
 Arcs are interactions
between objects

 Each SD shows a scenario


 Top ovals are preconditions
 Middle ovals are side effects
 Bottom ovals are postconditions

 SD is a partial behavioral description for objects


 Generally, each object participates in multiple SDs; each SD only has some objects
 The set of all SDs forms the HLD for all objects in the system © 2017 Philip Koopman 5
StateChart to SD Relationship
 For each object in each SD: identify input & output arcs
 Detailed Design: design statechart that accounts for all SD behaviors

Statechart Must Exhibit All Those Behaviors

SD set specifies behaviors

© 2017 Philip Koopman 6


Requirements Revisited: Levels of Abstraction
 Modes vs. States
 State: corresponds to internal state machine
– “When in state S1 the system shall display current time”
 Mode: user-visible change in operations
– “When in stopwatch mode, pressing Button 1 shall do XYZ”
 State-type descriptions in HLD should be modes
 Input & output behaviors can change depending upon mode
– GOOD: Pressing X in Mode Y displays Z
» Mode Y tells you which sequence diagram applies
– NOT: Pressing X in state S1 changes state to S2
» There is no point describing the detailed design this way
© 2017 Philip Koopman 7
High Level Design Best Practices
 HLD should include:
 One or more architecture diagrams
– Defines all components & interfaces
– HW arch., SW arch., Network arch., …
 Sequence Diagrams
– Both nominal and off-nominal interactions
– See 18-649 soda machine for a fully worked example
 HLD must co-evolve with requirements
– Need both nouns + verbs to define a system!
 High Level Design pitfalls: http://www.ece.cmu.edu/~ece649
/project/sodamachine/index.html
 Diagrams that leave out interactions
 Boxes and arrows don’t have well defined meanings
 HLD that bleeds into detailed design information
– Should have separate Detailed Design per component © 2017 Philip Koopman 8
2011 Health
Plan Flow
Chart:
What’s wrong
with this as an
architecture
diagram?

https://donyoung.house.gov/uploadedfiles/hous
e-democrats-health-plan.pdf

© 2017 Philip Koopman 9


https://xkcd.com/974/

© 2017 Philip Koopman 10

You might also like