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