Академический Документы
Профессиональный Документы
Культура Документы
Lecture 4
3.2.2010
SA design
Detailed design,
Coding,
Integration, Testing
3
Hardware
Architecture
design
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
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
implementation
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
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
system-specific scenarios
Only the necessary detail
3.2.2010
10
3.2.2010
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
13
3.2.2010
Case study:
Real-time performance
Modifiability to support product lines
Online diagnosis supported
14
3.2.2010
process
15
3.2.2010
16
3.2.2010
17
3.2.2010
hiding
sensors, diagnosis
First 3 virtual machines: they will vary for the different products to be
derived from the PLA
18
3.2.2010
deadline
19
3.2.2010
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
of qualities
We need additional views
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
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
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
26
3.2.2010
Deployment view
New responsibilities from need to deploy
On multiple processors or specialized hardware
27
3.2.2010
Deployment view 2
Decide if multiple instances of some modules are needed
Reliability
components to hardware
28
3.2.2010
services
29
3.2.2010
calls
30
3.2.2010
31
3.2.2010
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
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
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
39
3.2.2010
Case study
Device and controls for opening and closing the door are
40
3.2.2010
Case study 2
If an obstacle (person/object) is detected by garage door
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
43
3.2.2010
Iteration outcome
We defined enough to allocate work teams and give them
charges
the questions
44
3.2.2010
Bulletin boards
Web pages
Naming conventions for files
Configuration control system
group
45
3.2.2010
Team communication
Intra team
High bandwidth
Inter team
Low bandwidth
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
3.2.2010
50
3.2.2010
Highly distributed
Rigurous time requirements
Modifiability needed
Also integrability
The ease with which separately developed elements can be made to work
51
3.2.2010
52
3.2.2010
3.2.2010
Environment
Individuals, atmosphere, threats, weapons, other aircraft
Instructor
Monitors, initiate training situations
54
3.2.2010
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
57
3.2.2010
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