2. Where are we ?
Previously we have examined:
Quality attributes
Software Architecture Views
Some tactics and patterns for achieving quality attributes
Now we focus on Design of an Architecture
Architecture in the software life cycle
Designing the architecture
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2
4. When do we start developing the SA?
Requirements come first
But not all requirements are necessary to get started
Not all requirements are equal.
Architecture shaped by :
Functional requirements
Quality requirements
Design Constraints
We call these “Architectural Drivers”
The architecture of of an Air Traffic Control system is driven
by high availability.
A Flight simulator is driven by hard real time response times.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4
5. ASRs: Architectural Drivers
Identify the Architectural Drivers:
Identify the highest priority business goals
Only a few of these
Turn these into scenarios or use cases
Choose architecture significant requirements (ASRs)
These are the architectural drivers
There should be less than 10 of these
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5
6. Attribute Driven Design: ADD (1/2)
Design an architecture that supports functional
requirements, quality requirements and design
constraints.
ADD: architecture design using a decomposition process that is
based on the quality attributes of the the system
ADD input: architectural drivers (ASRs)
ADD output: levels of decomposition and related architectural
views
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6
7. Attribute Driven Design: ADD (2/2)
Add is a recursive design process:
Plan: Quality attributes and design constraints are considered to
select which tactics or patterns will be used in the architecture.
Do: Software architectural elements are instantiated to satisfy the
ASRs (architecture significant functional and quality
requirements).
Check: The architecture design is analyzed to determine if the
other (non ASR) functional and quality requirements are met.
Relation to Agile ?
ADD can be part of the high level design steps in Agile.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7
8. ADD – Agile - SCRUM
Scrum Process
ADD
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8
10. Output of ADD
During ADD:
Document all design decisions as well as their rationale.
ADD produces an initial software architecture design:
How to partition the system into computational &
developmental elements
The software elements that will be part of the different
structures, the type of elements, the properties and structural
relations
The interactions between the software elements, the properties
of the interactions and the mechanisms by which they occur.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10
11. ADD Step 1: Requirements Information
Step 1: Confirm there is sufficient requirements
information.
Sufficient does NOT equal complete.
The list of prioritized requirements according to
business goals.
Quality attributes should be described using
measurable (testable) responses
This information is needed to select tactics and
patterns that can be used to achieve the
requirements.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11
12. Controlling the car of the future
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12
13. Controlling the car of the future
What are the business drivers for car manufacturers ?
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13
14. Requirements: Automotive platform
Functional: The platform shall
manage data from all possible sensors in a car.
perform real time diagnostics and plan maintenance
enable ecological driving modes.
Quality attributes
Modifiability:
The platform will work on all cars from the vendor(s): from low-end to luxury car.
Automatically take into account the options selected by a customer.
Performance:
Data from security events has to be send immediately to the driver.
Design constraints
The platform executes on a microcontroller environment
The hardware cost must be minimal
The power consumption must be minimal
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14
15. ADD Step 2: Element Selection
Step 2: Choose an element of the system to
decompose
Start with the entire system as a decomposition
element.
All requirements are allocated to the system level.
Once the system is partitioned, assign
requirements to the decomposition elements.
Different levels of decomposition and elements:
System ,
Sub-system ,
Module ,
Sub-module
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15
16. ADD Step 3: Architectural Drivers
Step 3: Identify candidate architectural drivers
Rank requirements with respect to their impact on
the architecture:
(H,H); (H,M), …(M,L) from the utility tree
Priority/Complexity score from the use case index
Select the architectural drivers.
Less important requirements are satisfied within
constraints obtained by satisfying more important
requirements.
Not all requirements apply to all decomposition
elements.
This is a difference of ADD from other SA design
methods.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16
17. Automotive: Architectural Drivers
Step 3: ASR - Modifiability
-Support all models from the vendor
-Extensible to new models &
electric vehicles - Reuse
-Support the option list
- Configurable
-Run on different types of
microcontrollers
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17
18. ADD Step 4: Design Concepts
Step 4: Choose design concepts that satisfy the
architectural drivers
Design concepts can be tactics or patterns.
Patterns are collections of tactics.
Step 4 involves a number of sub-steps to
determine the type of software elements that will
be part of the design.
Important design decisions are taken while others
can be deferred: document both !
Major types of elements at this design level
Functionality of the elements
Types of communication between elements
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18
19. ADD Step 4: Sub- steps
Step 4 sub-steps:
1. Identify the design concerns associated with the
architectural drivers.
This comes straight from the utility tree
1. For each design concern, list the alternative tactics or
patterns that address the concern.
Inspiration comes from the quality attribute tactics
From your experience
1. Find the tactics and patterns that satisfy most ASRs
Create a table with patterns & tactics in the columns and ASRs
in the rows.
1. Patterns have an impact of several quality attributes.
How do we balance?
What are the trade-offs ?
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19
20. Automotive: Design Concepts
Step 4.1: Modifiability Concerns
Extensibility:
Hardware platform
New sensors
New applications
– Self park
Reuse :
Across models
Integration:
3rd party car entertainment
3rd party GPS
3rd party smartphone
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20
22. Modifiability Scenario
Support for HUD
Head up display
Artifact
Display &
Control code
Source Stimulus Environment Response Response
Developer Adds support Build Addition measure
for a HUD Time is made No changes
without to existing
(production)
effects on interfaces
other
modules
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22
24. Automotive: Design Concepts
Step 4.2 : Supporting Patterns
Layers
MVC
Broker
Publish Subscribe
…
Step 4.3 : Find the tactics and
patterns that satisfy most
ASRs
Tradeoffs ?
Performance
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24
25. ADD Step 5: Instantiate elements
Step 5: Instantiate Architectural Elements and
allocate responsibilities.
Example: Selecting a layered pattern (step 4) to
support modifiability does not tell how many layers
you need and what the responsibilities of each
layer are.
Responsibilities for instantiated elements are
derived from functional requirements and use
cases.
Examine multiple views: static , dynamic,
deployment.
Apply implicit use cases
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 25
26. ADD Step 5: Sub- steps (1/2)
Step 5 sub-steps:
1. Instantiate the elements.
2. Consider multiple views:
Static views provide containers for functionality and show
relations between modules
Dynamic views show parallel activities such as resource
contention, deadlock .
1. Apply use cases with the CRC methodology
Every use case of the parent element must be implemented by a
sequence of responsibilities of the children.
Assigning these responsibilities to the children will also determine
communications: producer/consumer relationship
How the information is exchanged is not critical at this point.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26
27. Automotive : Instantiate elements
Step 5.1 : Instantiate MVC
1. Separate core functions from
(inter)action, input & output.
User input
Data , commands
Sensor input
Controls
Actuators
Car control systems
Views
Main dashboard
HUD
Central display screen
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 27
28. Automotive : ..allocate responsibilities
Model instances
CCP: the car control platform
View instances
dBoard: the driver dashboard
cDisplay : the central console display
Controllers (Intermediaries)
Sensors: Global sensor controller
iDrive : man machine controller on central console
sWheel : steering wheel controls.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28
29. Automotive : Allocate responsibilities
ASR: Tire pressure loss:
When the tire sensor detects a loss of pressure in
the tire, the driver will be alerted immediately.
In case the pressure drops more then 50% below
the normal value, the driver is advised to pull over
and stop.
In case the car has run flat tires, the driver is
advised that the trip can be continued at reduced
speed.
The platform will identify the service centers in the
area or will forward a call to the local road service
center.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 29
30. Automotive : Static View- subsystems
<<Model>> <<View>> <<View>>
:CCP :dBoard :cDisplay
<<Controller>> <<Controller>> <<Controller>>
:Sensors :sWheel :iDrive
1. Make CRC cards
2. “Role” play the scenario
3. Allocate responsibilities & collaboration
4. Document using sequence diagrams
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 30
31. ADD Step 5: Sub- steps (2/2)
Step 5 sub-steps ctd:
4. Discover new responsibilities using typical system use
cases:
One user doing many tasks simultaneously
Many users doing similar tasks simultaneously
Startup of the system
Shutdown of the system
Disconnected operations
Failure of various elements
5. Analyze and document the design decisions using different
views:
Static views for non runtime properties
Dynamic views for reasoning about runtime behavior and
properties
Deployment views to reason about the relation between software
and hardware.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 31
32. ADD Step 6: Interfaces
Step 6: Define the interfaces for the instantiated
elements.
Interfaces describe the PROVIDE and REQUIRE
assumptions that software elements make about each other.
This can include
Information exchanged (events, data, …)
Syntax of operations (signature)
Semantics (description, pre- & post conditions, restrictions )
Error handling
Analyzing the decomposition into the three views provides
interaction information for the interface
Static or Module view (producer/consumer info)
Dynamic or Concurrency view (communication patterns,
synchronization, thread interaction, ..)
Allocation or Deployment view (timing , communication, ..)
Document the interfaces
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 32
33. ADD Step 7: Verification
Step 7: Verify and refine requirements and make
them constraints for instantiated elements.
Steps 4, 5 and 6 are executed taking into account mainly the
ASRs. Next we have to verify if all other requirements are
satisfied by this decomposition. If this is not the case we
need to backtrack.
Verifying the decomposition by “running” the parent’s use cases -
iterative design
Verify if all requirements have been allocated to one or more
elements.
Preparing children for their own decomposition by inheriting use
cases/constraints from the parent.
Translate the responsibilities of elements into functional
requirements for those elements.
Refine quality attributes for individual elements.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 33
34. Summary: Designing a Software Architecture
Plan: From Requirements to Architectural Drivers
Use the most important ones: ASRs
Less than 10
Do: From ASRs to the initial Architecture
ASRs are satisfied with tactics and patterns.
Attribute Driven Design (ADD) top down design process
Quality requirements determine the design concepts that can
be tactics, patterns or a combination of both.
Functional requirements instantiate modules for that pattern.
Check: Verify the initial design with respect to the other
(non ASR) requirements.
Start the next level decomposition.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 34