Software Architectures

Lecture 4

Roadmap of the course

What is software architecture?
Designing Software Architecture
Requirements: quality attributes or qualities
How to achieve requirements : tactics
How do tactics lead to architectural styles
Case studies on architectural styles, observe the achieved qualities
Today: how to build an architecture with ADD method

First exercise set is available on the web

Return answers in 2 weeks
2

3.2.2010

Architecture in the life cycle

Evolutionary Delivery Life Cycle
User and customer feedback
Iterate through several releases before final release
Adding of functionality with each iteration
Domain analysis,
Requirements analysis,
Risk analysis

SA design

Detailed design,
Coding,
Integration, Testing
3

Hardware
Architecture
design

Evolutionary delivery life cycle

3.2.2010

Requirements
Architecture is shaped by requirements
Functional, quality, and business requirements
Called architectural drivers
Identifying drivers
Determine highest priority business goals (few!)
Turn these business goals into quality scenarios
Choose the ones with most impact on architecture: these are
the architectural drivers (less than 10)

3.2.2010

Attribute-Driven Design (ADD)

method
Method to design architecture so that both functional and quality

requirements are met

Defines SA by decomposing based on the quality attributes
Recursive decomposition process; at each stage
Tactics and architectural patterns are chosen to satisfy some

qualities
Functionality is added to instantiate the module types provided
by the pattern
Input: the set of quality scenarios for drivers
Key drivers may change during design, due to
Better understanding or changing of requirements

3.2.2010

ADD output
First several levels of a module decomposition view of an

architecture
Not all details of the views result from applying ADD
Necessarily coarse grained

System described as

a set of containers for functionality

the interactions among the containers

Critical for achieving desired qualities

Provides framework for achieving the functionality
Difference between ADD output and an architecture ready for

implementation

Detailed design decisions postponed

Flexibility

3.2.2010

Case study
Garage door opener
Responsible for raising and lowering the garage door, via
Switch
Remote control
Home information system
It is possible to diagnose problems of opener from the home

information system (HIF)

Product line architecture! (PLA)

3.2.2010

Sample input
ADD assumes functional requirements and constraints as

input
ADD also needs the quality requirements
Set of system-specific quality scenarios

These provide a checklist to be used for the development of

system-specific scenarios
Only the necessary detail

3.2.2010

Case study: quality scenarios

Device and controls for opening and closing the door are

different for the different products in the product line

May include controls from within the HIF
Product architecture for a specific set of controls should be

directly derivable from the PLA

Processor used in different products will differ

Product architecture for each specific processor should be
directly derivable from the PLA

10

3.2.2010

Case study: quality scenarios 2

If an obstacle (person/object) is detected by garage door during

descent, it must halt or re-open within 0.1 second

Garage door opener should be accessible for diagnosis and
administration from within the HMI

Using a product-specific diagnosis protocol

Should be possible to directly produce an architecture that reflects

this protocol

11

3.2.2010

ADD Steps
Choose the module (initially whole system) to decompose
Required input available for that module
Refine the module according to following steps
Choose architectural drivers
Choose architectural pattern that satisfies the drivers
Instantiate modules and allocate functionality
Define interfaces of child modules
Verify and refine use cases and quality scenarios and make them
constraints for child modules
Repeat steps above for every module that needs further

decomposition

12

3.2.2010

Choose module to decompose

Modules: system, subsystem, submodule
Case study:
Garage door opener is the system
One constraint: opener must interoperate with the home

information system (HIS)

13

3.2.2010

Choose architectural drivers

Architectural drivers: functional and quality

requirements that shape the architecture

Among the top priority requirements for the module

To be addressed in the initial decomposition of the system

Case study:
Real-time performance
Modifiability to support product lines
Online diagnosis supported

14

3.2.2010

More on architectural drivers

Determining these drivers is not only in the beginning of the

process

Exp: we need to see an example of a garage door to know we

want it stopped in 0.1 sec

Less important requirements are satisfied within the

constraints of the most important

We decompose based on drivers

15

3.2.2010

Choose architectural pattern/style

For each quality attribute there are
Identifiable tactics and styles to implement them
Each tactic is designed to realize one/more attributes
The styles in which the tactics are embedded have impact on
other attributes
Balance between qualities needed
We need to identify child modules required to

implement the tactics

16

3.2.2010

Choose architectural pattern/style 2

Goal of this step
Establish overall style consisting of module types
Style should satisfy drivers
Constructed by composing selected tactics
Selection guided by
Drivers
Side effects of pattern on other qualities

17

3.2.2010

Choose architectural pattern/style:

case study 1
Modifiability at design time
localize changes tactic: semantic coherence and information

hiding

Separate responsibilities dealing with user interface, communication,

sensors, diagnosis
First 3 virtual machines: they will vary for the different products to be
derived from the PLA

18

3.2.2010

Choose architectural pattern/style:

case study 2
Performance
resource demand and resource arbitration tactics: increase

computational efficiency and choose scheduling policy

Performance-critical computations made efficient

Performance-critical computations scheduled to achieve the timing

deadline

19

3.2.2010

Instantiate modules and allocate

functionality
Allocate functionality
Use case for parent module => understand distribution of

functionality
Add/remove child modules to fulfill required functionality
Every use case of parent module: representable by a sequence of
responsibilities within child modules
Discover necessary info exchange
Information and producer/consumer roles

20

3.2.2010

Instantiate modules and allocate

functionality 2
Represent architecture with views
Dynamic and deployment info required to analyze achievement

of qualities
We need additional views

Module decomposition view

Concurrency view
Deployment view

21

3.2.2010

Concurrency view
Models dynamic aspects
Parallel activities
Synchronization
Identifies
Resource contention problems
Possible deadlock situations
Data consistency issues
Leads to discovery new responsibilities in the modules

and possibly new modules

Recorded in module decomposition view

Exp new module: resource manager

22

3.2.2010

Concurrency view 2
Component-and-connector view
Components: instances of modules
Connectors: carriers of virtual threads
Virtual thread: execution path through system or parts of it
Virtual versus operating system threads
Synchronizes with, starts, cancels, communicates with

23

3.2.2010

Concurrency view 3
Shows instances of modules in module decomposition view

for understanding mapping between views

Synchronization point located in a certain module
This responsibility assigned at right place

Crossing of two virtual threads: sign that some

synchronization needed

24

3.2.2010

Concurrency view 4
Use cases
Two users doing similar things at the same time
One user performing multiple activities simultaneously
Starting up the system
Shutting down the system

25

3.2.2010

Concurrency view 5
Concurrency might also be a point of variation
Sequential initialization for some products, parallel for others
In this case the decomposition should support techniques to

vary the initialization method

Exchanging component

26

3.2.2010

Deployment view
New responsibilities from need to deploy
On multiple processors or specialized hardware

Deployment view decomposes virtual threads

Virtual threads on distinct processors
Messages between them

Basis for analyzing network traffic, see possible congestion

27

3.2.2010

Deployment view 2
Decide if multiple instances of some modules are needed
Reliability

Supports reasoning about using special-purpose hardware

Architecture drivers help determining the allocation of

components to hardware

Replication vs real-time scheduling

28

3.2.2010

Define interfaces of child modules

Module interface
Services and properties provided and required
Different from signatures
Documents what others can use and on what they can depend

Module decomposition view documents

Producers/consumers on information
Patterns of interaction requiring modules to provide and use

services

29

3.2.2010

Define interfaces of child modules 2

Concurrency view documents
Interactions among threads, leading to module interface

providing or using a service

The info that a component is active
Own thread running

The info that a component synchronizes, sequentializes, blocks

calls

30

3.2.2010

Define interfaces of child modules 3

Deployment view documents
Hardware requirements (special purpose HW)
Timing requirements
Exp: computation speed of processor
Communication requirements
Exp: information updates not more than once per second

31

3.2.2010

Verify and refine

Decomposition into modules needs to be verified
Child modules need preparation for their own decomposition
Done for
Functional requirements
Constraints
Quality requirements

32

3.2.2010

Functional requirements
Child modules have responsibilities
Derived from functional requirements decomposition
Use cases for the module
Split and refine parent use cases
traceability

Exp: use cases that initializes the whole system

Broken into initialization of subsystems

33

3.2.2010

Case study
Initial responsibilities
Open/close door on request
Locally or remotely
Stop door within 0.1 sec when detect obstacle
Interact with HIS
Support remote diagnostics

34

3.2.2010

Case study 2
Decomposition of responsibilities
User interface: recognize user requests and translate them into

form expected by the raising/lowering door module

Raising/lowering door module:
control actuators to raise/lower door
Stop door when fully closed or fully open

Obstacle detection

35

3.2.2010

Case study 3
Decomposition of responsibilities, more:
Communication VM
Manage communication with HIS
Sensor/actuator VM
Manage interaction with sensors and actuators
Scheduler
Guarantee deadline
Diagnosis
Manage interaction with HIS for diagnosis

36

3.2.2010

Constraints
Constraints of parent module satisfied by
Decomposition satisfies the constraints
Using certain OS
Constraint satisfied by single child module
Special protocol
Constraint satisfied by multiple child modules
Web usage requires two modules (client and server)

37

3.2.2010

Case study
Constraint: communication with HIS is maintained
Communication virtual machine will recognize if this is

unavailable
Constraint satisfied by a single child

38

3.2.2010

Quality scenarios
Need to be refined and assigned to child modules
Possibilities
QS completely satisfied by decomposition
QS may be satisfied by decomposition with constraints on child
modules
Layers and modifiability

Decomposition neutral wrt QS

QS assigned to child modules
QS not satisfiable by decomposition
Decomposition reconsidered or reason for this recorded
Typical trade-offs

39

3.2.2010

Case study
Device and controls for opening and closing the door are

different for the different products in the product line

May include controls from within the HIF
QS delegated to user interface module

Processor used in different products will differ

Product architecture for each specific processor should be
directly derivable from the PLA
QS delegated to all modules

40

3.2.2010

Case study 2
If an obstacle (person/object) is detected by garage door

during descent, it must halt or re-open within 0.1 second

QS delegated to scheduler and obstacle detection module

Garage door opener should be accessible for diagnosis

and administration from within the HMI

Using a product-specific diagnosis protocol

QS split between diagnosis and communication modules

41

3.2.2010

Step outcome
Decomposition of module into children
Each child has
Set of responsibilities
Set of use cases
Interface
Quality scenarios
Collection of constraints
Enough for next iteration of decomposition

42

3.2.2010

Iteration progress
Vocabulary of modules and their responsibilities
Variety of use cases and quality scenarios and understood

some of their ramifications

Information needs of modules
Their interactions

Not decided yet

Communication language, algorithm for obstacle detection, etc

43

3.2.2010

Iteration outcome
We defined enough to allocate work teams and give them

charges

If we design a large system

We can proceed to next iteration and decide on answers for

the questions

If we design small system

44

3.2.2010

Forming the team structure

When modules fairly stable
They can be allocated to development teams (existing, new)
Team structure mirror module decomposition structure
Each team creates its own internal work practices (or

adopts a system-wide set)

Bulletin boards
Web pages
Naming conventions for files
Configuration control system

Quality assurance and testing procedures set up for each

group

Coordinate with others

45

3.2.2010

Team communication
Intra team
High bandwidth

Inter team
Low bandwidth

Assumes system designed based on separation of concerns

As software systems, the teams should strive for loose

coupling and high cohesion

46

3.2.2010

Modules as mini-domains
Modules encapsulate changeable details
They exhibit only the interface
Interface common, unified set of services to the users
Domain specialized knowledge or expertise

Examples
Module user interface layer of systems
UI tools independent of UI communication with other modules
Module process scheduler
Process number and algorithms: hidden

Most effective
Assign team members according to their expertise

47

3.2.2010

Organization Architecture
The expertise determines the architecture
Database specialist
Telecom specialist

48

3.2.2010

Creating a skeletal system

Provide underlying capability for implementing functionality
In order advantageous for project

Classical software engineering: stubbing out

Architecture-driven: sequence becomes clear
First
Implement the SW dealing with execution and interaction of arch comps
Scheduler, rule engine, process synchronization, CS coordination
Or install
Then: simplest functionality in each component
Then order decreasingly according to importance to project
Evolutionary Delivery Life Cycle (EDLC)
49

3.2.2010

Microsoft and EDLC

Complete skeletal system is early formed
Low-fidelity working system
Rebuilt frequently (nightly)
=> features can be judged if enough or not
Possible problem
First development team to complete portion of system defines interfaces
Penalty for more complex parts of the systems
Alleviation: negotiate interfaces in skeletal system early

50

3.2.2010

Flight simulation example

Most sophisticated SW

Highly distributed
Rigurous time requirements
Modifiability needed
Also integrability
The ease with which separately developed elements can be made to work

together under SW requirements

Tactics
Keeping interfaces simple, small, stable
Adhering to defined protocols
Loose coupling, minimal dependencies
Components

51

3.2.2010

Architecture business cycle

52

3.2.2010

Some history of the simulator

Very large (1.5 million LOC)
Long lifetimes (~40 years)
Stringent real-time and fidelity requirements
Simulator should behave EXACTLY like the real aircraft
Normal flight
Emergency maneuvers
Equipment failures

1987: Air Force investigates OO techniques

Existing simulators since 1960s, problems
Integration phase was increasing exponentially with size and complexity
Cost of modifications >cost of original system
53

3.2.2010

Roles in the simulator

Crew
Inside a motion platform, surrounded by instruments
Look at visuals and need to take actions
How to operate the aircraft
How to perform maneuvers: mid-air refuelling
How to respond to situations: attack
Fidelity important

Environment
Individuals, atmosphere, threats, weapons, other aircraft

Instructor
Monitors, initiate training situations

54

3.2.2010

Reference model for simulator

55

3.2.2010

Boeing simulators

56

3.2.2010

Fidelity of models
Exp: air pressure
Model considers just the aircraft altitude
Model considers the aircraft altitude and local weather
Model considers the aircraft altitude, local weather, nearby

aircraft

The more fidelity, the more computational complexity

57

3.2.2010

States of flight simulator

Operate
Configure
Halt
Replay

58

3.2.2010

Properties to satisfy
Real-time performance constraints
Continuous development and modification
Large size, complexity
Developed in geographically distributed areas
Also
Very expensive debugging, testing, modification
Unclear mapping between SW structure and aircraft structure

59

3.2.2010

Propulsion subsystem

60

3.2.2010

Achieving goals

61

3.2.2010

In a nutshell
ADD aims to create a skeleton system
Working interactions
Give a priority to implementing modules
Assign teams to modules

Main idea
Incrementtal developing, testing

Flight simulator
Via architectural techniques they uncovered a different module

decomposition
Performance with time budgets
62

3.2.2010