SLIDE 1
- J. Scott Hawker/R. Kuehl
- p. 1
R I T
Software Engineering
- J. Scott Hawker/R. Kuehl
- p. 2
R I T
Software Engineering
Software Architecture Design Example Using Attribute Driven Design - - PowerPoint PPT Presentation
Software Architecture Design Example Using Attribute Driven Design - - PowerPoint PPT Presentation
Software Architecture Design Example Using Attribute Driven Design J. Scott Hawker/R. Kuehl p. 1 R I T Software Engineering Garage Door Example Design a product line architecture for a garage door opener integrated with a home
SLIDE 2
SLIDE 3
- J. Scott Hawker/R. Kuehl
- p. 3
R I T
Software Engineering
For new (green field) systems it is the whole system For legacy, what is being added After the first iteration what comes next, element breath or depth?
Depth if technology risk or resourcing concerns
Garage door opener is the system
Step 1: Choose a System Element to Design
SLIDE 4
- J. Scott Hawker/R. Kuehl
- p. 4
R I T
Software Engineering
Step 2: Identify the ASRs
(Architecturally Significant Requirements)
Start with quality scenarios
Device and controls differ for various products in product line Product processors differ Garage door descent must stop within 0.1 second after obstacle detection Access to opener from home info system for control and diagnostics with proprietary protocol
SLIDE 5
- J. Scott Hawker/R. Kuehl
- p. 5
R I T
Software Engineering
Step 2: Identify the ASRs (cont)
ASRs are a combination of functional requirements, constraints and quality attributes Prioritize ASRs and select those that will “drive“ the architecture design Garage door system:
Real-time performance Modifiability to support the product line Interoperability for on-line control and diagnostics
SLIDE 6
- J. Scott Hawker/R. Kuehl
- p. 6
R I T
Software Engineering
Step 3: Generate a Design Solution For the Chosen Element
Goal: establish an overall architecture design that satisfies architectural drivers For each ASR for this element choose a design solution … The patterns, tactics, design principles to achieve quality attributes Watch for QA design tradeoffs between tactics It’s possible the domain problem may call for a “custom” architecture pattern
SLIDE 7
- J. Scott Hawker/R. Kuehl
- p. 7
R I T
Software Engineering
Step 3: Generate a Design Solution (cont)
Performance
Concerned with critical computational performance scheduling and efficiency Need tactics to deal with the control of resource demand and resource management Choose “increase resource efficiency” and “schedule resources” Solution - separate critical and non-critical performance computation
SLIDE 8
- J. Scott Hawker/R. Kuehl
- p. 8
R I T
Software Engineering
Performance Tactics
SLIDE 9
- J. Scott Hawker/R. Kuehl
- p. 9
R I T
Software Engineering
Step 3: Generate a Design Solution (cont)
Modifiability
Primarily concerned with changes at build time, not runtime Need tactics to support separation of responsibilities to localize changes
- Increase cohesion, reduce coupling
Choose “increase semantic coherence”, “encapsulation”, and “abstract common services” as our tactics Solution - separate responsibilities dealing with the user interface, communication, and sensors into their
- wn modules
SLIDE 10
- J. Scott Hawker/R. Kuehl
- p. 10
R I T
Software Engineering
Modifiability Tactics
Modifiability Tactics
Increase Cohesion Reduce Coupling Split Module Encapsulate Use an Intermediary Change Requests Changes Made and Deployed Reduce Size
- f a Module
Increase Semantic Coherence Restrict Dependencies Refactor Abstract Common Services Defer Binding
SLIDE 11
- J. Scott Hawker/R. Kuehl
- p. 11
R I T
Software Engineering
Pattern for Garage Door Opener
User Interface Non-Performance- Critical Computation Virtual Machine Performance-Critical Computation Schedule that Guarantees Deadlines
SLIDE 12
- J. Scott Hawker/R. Kuehl
- p. 12
R I T
Software Engineering
Step 4: Validate Design and Refine Requirements
Requirements satisfied Done, no more refinement Requirements not fully satisfied
- Defer to the next iteration
- Delegate or distribute
requirement satisfaction to sub- module elements Requirements cannot be satisfied with this design
- Revisit the design - backtrack
- Refine or push back on the
requirement
Test the element design for requirements satisfaction
SLIDE 13
- J. Scott Hawker/R. Kuehl
- p. 13
R I T
Software Engineering
Step 4: Validate Design and Refine Requirements (cont)
ASRs Not Met Action
Quality attribute
- Apply tactics to address
tradeoff or downside Functional responsibility
- Add responsibilities to
existing module
- Create new module
Constraint
- Modify the design
- Relax the constraint
Note: Previous designs become a constraint
SLIDE 14
- J. Scott Hawker/R. Kuehl
- p. 14
R I T
Software Engineering
Step 5: Repeat Until all ASRs Have Been Satisfied
If all ASR’s satisfied, done – a workable architecture
Or elaborated sufficiently for construction (or you run out of time and money)
Otherwise … Repeat step 1 - choose the next (sub)element(s) to design Repeat steps 2-4 As necessary refine use cases and QA scenarios as ASRs for the next design iteration
SLIDE 15
- J. Scott Hawker/R. Kuehl
- p. 15
R I T
Software Engineering
Are the ASR’s Satisfied? Or is the Design Sufficient?
Device and controls differ for various products in product line Product processors differ Garage door descent must stop within 0.1 second after obstacle detection Access to opener from home info system for control and diagnostics with proprietary protocol
SLIDE 16
- J. Scott Hawker/R. Kuehl
- p. 16
R I T
Software Engineering
Next Iteration Decomposition
Define sub-modules, assign functionality Two types of virtual machine – sensors/actuators and communications modules Non-performance critical functional modules – diagnostics and normal raising/lowering the door modules Obstacle detection and halting the door functions assigned to performance critical module Connections
SLIDE 17
- J. Scott Hawker/R. Kuehl
- p. 17
R I T
Software Engineering