sa 009 add

Vakgroep Informatietechnologie – IBCN

Software Architecture

Attribute Driven Design – ADD 2.0

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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


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

2. For each design concern, list the alternative tactics or patterns that address the concern.

Inspiration comes from the quality attribute tactics From your experience

3. Find the tactics and patterns that satisfy most ASRs Create a table with patterns & tactics in the columns and ASRs

in the rows.

4. 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

p. 22 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

Artifact

Display & Control code

Environment

Build

Time

(production)

Response measure

No changes to existing interfaces

Response

Addition

is made without

effects on other

modules

Stimulus

Adds support

for a HUD

Support for HUDHead up display

Source

Developer

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 .

3. 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 inputControls

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

1. Make CRC cards

2. “Role” play the scenario

3. Allocate responsibilities & collaboration

4. Document using sequence diagrams


<<Model>>

:CCP

<<View>>

:dBoard

<<View>>

:cDisplay

<<Controller>>

:Sensors

<<Controller>>

:sWheel

<<Controller>>

:iDrive

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: InterfacesStep 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: VerificationStep 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

Documents

architecture architecture

important requirements

requirements informationstep

software elements

decomposition elements

recursive design process

architectural driversstep

architectural driversidentify