1
Attribute-Driven Design Method
April 2015
Ying SHEN
SSE, Tongji University
Software Architecture, Spring 2015 School of Software Engineering
2
Lecture objectives
This lecture will enable student to
• understand ADD steps
• design the architecture using ADD method
Software Architecture, Spring 2015 School of Software Engineering
3
Architecture in the life cycle
Evolutionary Delivery Life Cycle (EDLC)
• User and customer feedback
• Iterate through several releases before final release
• Adding of functionality with each iteration
Software Architecture, Spring 2015 School of Software Engineering
4
Evolutionary delivery life cycle
Software
Concept
Deliver
Preliminary Final
Requirements Version
Analysis
Design of
Architecture
and System Core
Develop
a Version
Incorporate Deliver
Customer the Version
Feedback
Elicit
Customer
Feedback
Software Architecture, Spring 2015 School of Software Engineering
5
When do we start developing the SA?
Requirements come first
• But not all requirements are necessary to get started
Architecture shaped by (remember the ABC)
• Functional requirements
• Quality requirements
• Business requirements
• Expertise and experience of architects
We call these requirements “architectural drivers”
Software Architecture, Spring 2015 School of Software Engineering
6
Determining architectural drivers
To identify the Architectural Drivers
Identify the highest priority Business Goals
• Only a few of these
Turn these into scenarios or use cases
Choose the ones that have the most impact on the
architecture
• These are the architectural drivers
• There should be less than 10 of these
Software Architecture, Spring 2015 School of Software Engineering
7
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 are chosen to satisfy some qualities
• Functionality is added
Software Architecture, Spring 2015 School of Software Engineering
8
ADD input
Input:
1. The set of quality scenarios for drivers
• Key drivers may change during design, due to
o better understanding or changing of requirements
• Quality attribute requirements are a good start
o although they can’t be all known a priori
2. The context description
• What are the boundaries of the system being designed?
• What are the external systems, devices, users, and
environmental conditions with which the system being
designed must interact?
Software Architecture, Spring 2015 School of Software Engineering
9
ADD output
Output: a set of sketches of architectural views.
• First several levels of a module decomposition view of an
architecture
• Not all details of the views result from applying ADD
• System described as
o a set of containers for functionality
o the interactions among the containers
Software Architecture, Spring 2015 School of Software Engineering
10
ADD output
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
o e.g. choosing the names and parameter types of interface
• Flexibility
Software Architecture, Spring 2015 School of Software Engineering
11
Case study: Garage Door Opener
Garage door opener: A real-time system responsible for
raising and lowering the garage door, via
• Switch button
• Remote control
• Home information system
It is possible to diagnose problems of opener from the
home information system (HIS)
Product line architecture! (PLA)
• The processor is different from other products.
Software Architecture, Spring 2015 School of Software Engineering
12
Case study: Garage Door Opener
Input to ADD: a set of requirements
• Functional requirements as use cases
• Constraints
• Quality requirements
o Set of system-specific quality scenarios
o Only the necessary detail
Software Architecture, Spring 2015 School of Software Engineering
13
Case study: Scenarios
Scenarios for garage door system
• Reacting to obstacles [Performance]
o If an obstacle (person/object) is detected by garage door during
descent, it must halt or re-open within 0.1 second and report to
HIS and user interface.
• Door commands [Performance]
o Remote control; HIS; button.
o Open, close, halt, diagnosis
o Detect a command and initiate execution within 0.5 sec
Software Architecture, Spring 2015 School of Software Engineering
14
Case study: Scenarios
Scenarios for garage door system
• Processors [Modifiability]
o Processors can change due to either obsolescence or changes in
the marketplace.
• UI [Modifiability]
o Various garage door openers have various controls.
• Garage door opener should be accessible for diagnosis and
administration from within the HIS
o Using a product-specific diagnosis protocol
Software Architecture, Spring 2015 School of Software Engineering
15
ADD steps
Steps involved in Attribute Driven Design (ADD)
1. Choose the module to decompose
• Start with entire system
• Inputs for this module need to be available
o Constraints, functional and quality requirements
Software Architecture, Spring 2015 School of Software Engineering
16
ADD steps
2. Refine the module
• Choose architectural drivers
• Choose architectural pattern
• Instantiate modules and allocate functionality using
multiple views
• Define interfaces of child modules
• Verify and refine use cases and quality scenarios and make
them constraints for child modules
3. Repeat for every module that needs further
decomposition
Software Architecture, Spring 2015 School of Software Engineering
17
Choose the module to decompose
Modules: system → subsystem → submodule
Current design element is the whole system
Constraint for the Garage Door Opener system
• Garage door opener is the system
• One constraint: opener must interoperate with the home
information system (HIS)
Software Architecture, Spring 2015 School of Software Engineering
18
ADD steps
1. Choose the module to decompose
2. Refine the module
• Choose architectural drivers
• Choose architectural pattern that satisfies these 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
3. Repeat for every module that needs further
decomposition
Software Architecture, Spring 2015 School of Software Engineering
19
Refine the module: Choose arch. 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
Drivers for Garage Door Opener system
• Real-time performance
• Modifiability to support product lines
• Online diagnosis supported
Software Architecture, Spring 2015 School of Software Engineering
20
ADD steps
1. Choose the module to decompose
2. Refine the module
• Choose architectural drivers
• Choose architectural pattern that satisfies these 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
3. Repeat for every module that needs further
decomposition
Software Architecture, Spring 2015 School of Software Engineering
21
Refine the module: Choose arch. pattern
For each quality requirement there are
• identifiable tactics and patterns to implement them
• each tactic is designed to realize one/more attributes
• the patterns in which the tactics are embedded have impact
on other attributes
• balance between qualities needed
o As composition of tactics is used
We need to identify child modules required to implement
the tactics
Software Architecture, Spring 2015 School of Software Engineering
22
Refine the module: Choose arch. pattern
The goal of this step is
• to establish an overall architectural pattern for the module
• Architectural pattern should satisfy drivers
• Architectural pattern is built by “composing” the tactics
selected
• Two factors involved in selecting tactics:
o Architectural drivers themselves
o Side effects of the pattern implementing the tactic on other
requirements
Software Architecture, Spring 2015 School of Software Engineering
23
Refine the module: Choose arch. pattern
Example 1: Modifiability at design time
• Increase semantic coherence and information hiding
o Separate responsibilities dealing with user interface,
communication, sensors, diagnosis into their own module
– These modules are called virtual machine.
o The first 3 virtual machines: will vary for the different products to
be derived from the PLA
Software Architecture, Spring 2015 School of Software Engineering
24
Refine the module: Choose arch. pattern
Example 2: Performance
• Increase computational efficiency and choose scheduling
policy
o Performance-critical computations made efficient
o Performance-critical computations scheduled to achieve the
timing deadline
Software Architecture, Spring 2015 School of Software Engineering
25
Refine the module: Choose arch. pattern
Architectural patterns that utilize tactics to achieve garage
door drivers
Software Architecture, Spring 2015 School of Software Engineering
26
ADD steps
1. Choose the module to decompose
2. Refine the module
• Choose architectural drivers
• Choose architectural pattern that satisfies these 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
3. Repeat for every module that needs further
decomposition
Software Architecture, Spring 2015 School of Software Engineering
27
Refine the module: Instantiate modules
Previous step
• We defined the module types of the decomposition
Now
• We instantiate them
Virtual machine manages communication and sensor
interactions
• Software running on top of VM: an application
• One module for each group of functionality – instance of
the module types
Software Architecture, Spring 2015 School of Software Engineering
28
Refine the module: Instantiate modules
Our example
• Responsibility for managing obstacle detection and halting
door → performance critical section
o This functionality has deadline
• Management of normal door raising/lowering
o No deadline => non-performance critical section
o Same with diagnosis
• Several responsibilities for VM
o Communication and sensor reading and actuator control
o Results in 2 instances of VM
Software Architecture, Spring 2015 School of Software Engineering
29
Refine the module: Instantiate modules
First level decomposition of SGDO
Software Architecture, Spring 2015 School of Software Engineering
30
Refine the module: 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
Software Architecture, Spring 2015 School of Software Engineering
31
Refine the module: Allocate functionality
User interface
• Recognize user requests and translate them into the form
expected by the raising/lowering door module.
Raising/lowering door module
• Control actuators to raise or lower the door. Stop the door
when it reaches either fully open or closed.
Obstacle detection
• Recognize when an obstacle is detected and either stop the
descent of the door or reverse it.
Software Architecture, Spring 2015 School of Software Engineering
32
Refine the module: Allocate functionality
Communication virtual machine
• Manage all communication with HIS.
Sensor/actuator virtual machine
• Manage all interactions with the sensors and actuators.
Scheduler
• Guarantee that the obstacle detector will meet its deadlines.
Diagnosis
• Manage the interactions with HIS.
Software Architecture, Spring 2015 School of Software Engineering
33
ADD steps
1. Choose the module to decompose
2. Refine the module
• Choose architectural drivers
• Choose architectural pattern that satisfies these 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
3. Repeat for every module that needs further
decomposition
Software Architecture, Spring 2015 School of Software Engineering
34
Refine the module: Define interfaces of
child modules
Module interface
• Services and properties provided and required
• 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
Software Architecture, Spring 2015 School of Software Engineering
35
Refine the module: Define interfaces of
child modules
User interface:
• openDoor: send command to Raising/lowering door
module to open garage door
• closeDoor: to close door
• haltDoor: to halt door (manually halt function is available)
Raising/lowering door module
• startOpen: send command to Sensor/actuator virtual
machine module to turn on the actuator and open door.
• startClose: turn on the actuator and close door.
• stop: turn off the actuator and left the door in the current
position
Software Architecture, Spring 2015 School of Software Engineering
36
ADD steps
1. Choose the module to decompose
2. Refine the module
• Choose architectural drivers
• Choose architectural pattern that satisfies these 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
3. Repeat for every module that needs further
decomposition
Software Architecture, Spring 2015 School of Software Engineering
37
Refine the module: Verify and refine
Decomposition into modules needs to be verified.
Child modules need preparation for their own
decomposition on second level decomposition.
Done for
• Functional requirements
• Constraints
• Quality requirements
Software Architecture, Spring 2015 School of Software Engineering
38
Functional requirements
Child modules have responsibilities
• Derived from functional requirements decomposition
• As use cases for the module
• Split and refine parent use cases
• Example: use cases that initializes the whole system
o Broken into initialization of subsystems
Software Architecture, Spring 2015 School of Software Engineering
39
Functional requirements
Case study:
Initial responsibilities
• Open/close door on request
o Locally or remotely
• Stop door when detect obstacle
• Interact with HIS
• Support remote diagnostics
Software Architecture, Spring 2015 School of Software Engineering
40
Functional requirements
Case study:
Decomposition of responsibilities
• User interface:
o recognize user requests and translate them into form expected by
the raising/lowering door module
• Raising/lowering door module:
o Control actuators to raise/lower door
o Stop door when fully closed or fully open
• Obstacle detection
Software Architecture, Spring 2015 School of Software Engineering
41
Functional requirements
Case study:
Decomposition of responsibilities more
• Communication VM
o Manage communication with HIS
• Sensor/actuator VM
o Manage interaction with sensors and actuators
• Scheduler
o Guarantee deadline
• Diagnosis
o Manage interaction with HIS for diagnosis
Software Architecture, Spring 2015 School of Software Engineering
42
Constraints
Constraints of parent module satisfied by
1. Decomposition satisfies the constraints
o Using certain OS
2. Constraint satisfied by single child module
o Special protocol
3. Constraint satisfied by multiple child modules
o Web usage requires two modules (client and server)
Software Architecture, Spring 2015 School of Software Engineering
43
Constraints
Case study:
Constraint: communication with HIS is maintained
• Communication virtual machine will recognize if this is
unavailable
• Constraint satisfied by a single child
Software Architecture, Spring 2015 School of Software Engineering
44
Quality scenarios (QS)
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
o Layers and modifiability
• Decomposition neutral with respect to QS
o QS assigned to child modules
• QS not satisfiable by decomposition
o Decomposition reconsidered or reason for this recorded
o Typical trade-offs
Software Architecture, Spring 2015 School of Software Engineering
45
Quality scenarios (QS)
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 HIS
• QS is 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 is delegated to all modules
Software Architecture, Spring 2015 School of Software Engineering
46
Quality scenarios (QS)
Case study:
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 HIS
• Using a product-specific diagnosis protocol
• QS split between diagnosis and communication modules
Software Architecture, Spring 2015 School of Software Engineering
47
Step outcome
Decomposition of module into children
• Each child has
o Set of responsibilities
o Set of use cases
o Interface
o Quality scenarios
o Collection of constraints
• Enough for next iteration of decomposition
Software Architecture, Spring 2015 School of Software Engineering
48
ADD steps
1. Choose the module to decompose
2. Refine the module
• Choose architectural drivers
• Choose architectural pattern that satisfies these 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
3. Repeat for every module that needs further
decomposition
Software Architecture, Spring 2015 School of Software Engineering
49
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
Software Architecture, Spring 2015 School of Software Engineering
50
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
Software Architecture, Spring 2015 School of Software Engineering
51
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
Software Architecture, Spring 2015 School of Software Engineering
52
The End
Software Architecture, Spring 2015 School of Software Engineering
