Lecture 4

Software Architectures

Roadmap of the course

15-Nov-11 2

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 1 week

SA terminology,3

15-Nov-11 3

4. Software architecture Applies to one system Describes element types, how they interact, how

the product functionality is mapped to them Describes the instances that exist in the system Level of specificity needed to design a system

Architecture in the life cycle

4

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 Hardware

Architecture design

Detailed design, Coding,

Integration, Testing 15-Nov-11

Evolutionary delivery life cycle

15-Nov-11 5

Requirements

15-Nov-11 6

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)

Attribute-Driven Design (ADD) method

15-Nov-11 7

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 are chosen to satisfy some qualities Functionality is added to instantiate the module

types provided by the tactic Input: the set of quality scenarios for drivers Key drivers may change during design, due to Better understanding or changing of requirements

ADD output

15-Nov-11 8

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

Case study

15-Nov-11 9

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)

Sample input

15-Nov-11 10

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

Case study: quality scenarios

15-Nov-11 11

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

Case study: quality scenarios 2

15-Nov-11 12

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

ADD Steps

15-Nov-11 13

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 tactic/style 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

Choose module to decompose

15-Nov-11 14

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

home information system (HIS)

Choose architectural drivers

15-Nov-11 15

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

More on architectural drivers

15-Nov-11 16

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

Choose architectural style

15-Nov-11 17

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

Choose architectural style 2

15-Nov-11 18

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

Choose architectural style: exp 1

15-Nov-11 19

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

Choose architectural style: exp 2

15-Nov-11 20

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

Instantiate modules and allocate functionality

15-Nov-11 21

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

Instantiate modules and allocate functionality 2

15-Nov-11 22

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

Concurrency view

15-Nov-11 23

Models dynamic aspects Parallel activities Synchronization

Identifies Resource contention problems Possible deadlock situations Data consistency issues

Leads to uncover new responsibilities in the modules and possibly new modules Recorded in module decomposition view Exp new module: resource manager

Concurrency view 2

15-Nov-11 24

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

Concurrency view 3

15-Nov-11 25

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

Concurrency view 4

15-Nov-11 26

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

Concurrency view 5

15-Nov-11 27

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

Deployment view

15-Nov-11 28

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

Deployment view 2

15-Nov-11 29

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

Define interfaces of child modules

15-Nov-11 30

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

Define interfaces of child modules 2

15-Nov-11 31

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

Define interfaces of child modules 3

15-Nov-11 32

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

Verify and refine

15-Nov-11 33

Decomposition into modules needs to be verified Child modules need preparation for their own

decomposition Done for Functional requirements Constraints Quality requirements

Functional requirements

15-Nov-11 34

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

Case study

15-Nov-11 35

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

Case study 2

15-Nov-11 36

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

Case study 3

15-Nov-11 37

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

Constraints

15-Nov-11 38

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)

Case study

15-Nov-11 39

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

is unavailable Constraint satisfied by a single child

Quality scenarios

15-Nov-11 40

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

Case study

15-Nov-11 41

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

Case study 2

15-Nov-11 42

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

Step outcome

15-Nov-11 43

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

Iteration progress

15-Nov-11 44

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

Iteration outcome

15-Nov-11 45

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

Forming the team structure

15-Nov-11 46

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

Team communication

15-Nov-11 47

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

Modules as mini-domains

15-Nov-11 48

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

Organization Architecture

15-Nov-11 49

The expertise determines the architecture Database specialist Telecom specialist

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)

Microsoft and EDLC

15-Nov-11 51

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

Flight simulation example

15-Nov-11 52

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

Boeing simulators

15-Nov-11 53

Some history of the simulator

15-Nov-11 54

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

Roles in the simulator

15-Nov-11 55

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

Fidelity of models

15-Nov-11 56

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

Today’s takeout

15-Nov-11 57

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

Main idea Incrementtal developing, testing SA in the centre