Sa 009 add

Software Architecture

Attribute Driven Design – ADD 2.0

Vakgroep Informatietechnologie – IBCN

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

Evolutionary Delivery Life Cycle


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.


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


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


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.


ADD – Agile - SCRUM
Scrum Process

ADD

ADD 2.0 steps


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.


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.


Controlling the car of the future


Controlling the car of the future

What are the business drivers for car manufacturers ?


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


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


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.


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


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


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 ?


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


Modifiability UI & sensors


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


Automotive : Design Concepts
Step 4.2 : Supporting tactics
 Semantic coherence
 Abstract common services
 Encapsulation
 Use intermediary
 Runtime binding


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

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


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.


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

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.


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.


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


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.


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

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.


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.


Sa 009 add

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (12)

Similaire à Sa 009 add

Similaire à Sa 009 add (20)

Plus de Frank Gielen

Plus de Frank Gielen (20)

Sa 009 add