Arquitectura de Software

Attribute Driven Design (ADD)

Agenda

Presentación ADD (1 hora)

Diseño de la Arquitectura
Tácticas de Arquitectura
Ejemplo de Aplicación

Taller Práctico (1 hora y 20 min.)

Socialización (30minutos)
Overview
✓An architecture will inhibit or enable a system’s driving quality
attributes.
✓The decisions made in an architecture allow you to reason
about and manage change as the system evolves.
✓The analysis of an architecture enables early prediction of a
system’s qualities.
✓A documented architecture enhances communication among
stakeholders.
Overview

Architectural
Architectural
Drivers and Architectural Architectural
Analysis and
Requirements Documentation Evaluation
Design
Identification
Attribute Driven Design

PLAN
“The ADD method is an
approach to defining a
software architecture in which
the design process is based
on the software’s quality System
attribute requirements” (or system
elements)
Software Engineering Institute (SEI)
CHECK DO
 Attribute Driven Design
Inputs
Outputs
• Architecture Drivers
• Quality Attributes
System Design:
• Design Constraints
• Software Elements

ADD
• Functional
• Roles
Requirements
• Responsibilities
• Architecture Design • Properties
Objectives • Relationships
• Concerns
 Attribute Driven Design
Design Primary functional Quality attributes
Constraints Concerns
objectives requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to be considered in the iteration

Step 3: Choose one or more elements of the system to decompose

Step 8: Refine Step 4: Choose one or more design concepts that satisfy the inputs considered in the iteration
as necessary

Step 5: Instantiate architectural elements, allocate responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and review iteration goal and design objectives

Software architecture
design
ADD: Step 1
❑Priorized list of requirements
▪ According to business and mission
goals
❑Enough quality attribute information
• Expressed in “Stimulus Response”
• Measurable
Review Inputs
❑Other relevant information (type of
systems, business goals, concerns,
etc.)
ADD: Step 2
❑Choose element system (or system
itself) to analyze. Iteration goal
1. Structure the system
2. Support primary functionality
Establish iteration goal 3. Support quality attribute scenario and
additional concerns
and select inputs to be
❑Decision Making
considered in the ▪ Knowledge of the architecture
iteration (dependencies)
▪ Risk and difficulty
▪ Business criteria
▪ Organizational criteria
ADD: Step 3
❑Rank requirements
▪ Criteria: Impact on the architecture
❑ Candidate Architectural Drivers:
• May not have an impact on the
structure of the architecture
Select elements to
Architecture Impact
decompose
High Med Low

High REQ-01 REQ-02 REQ-02

REQ-04
Stakeholder Med REQ-05
importance
Low REQ-03
ADD: Step 4
1. Identify the design concepts that are associated
with the candidate architectural drivers.
✓ Reference Architectures
✓ Deployment Patterns
✓
Choose one or more ✓
Architectural / Design patterns
Tactics
✓ Frameworks or other externally developed components
design concepts that 2. Create a list of alternative patterns that address
the concern
satisfy the inputs 3. Select patterns from the list that you feel are most
appropriate for satisfying the candidate architectural
considered in the drivers. (Use trade-off analysis)

iteration 4.
5.
Relate the patterns selected to types of elements
Describe the patterns selected
6. Evaluate and resolve inconsistencies in the design
concept
Trade-off Analysis

“A trade-off is a
situation that involves
losing one quality or
aspect of something
in return for gaining
another quality or
aspect”
Architectural Tactics
“Tactics are decisions
to achieve quality
attribute
requirements”

• Each tactic is a design option

• Patterns are composed from
tactics
• Tactics can refine other
tactics.
Specification
Availability Tactic
Source of Stimulus
Stimulus
Environment
Artefact
Response
Response Measure
Tactics
Rational
Tactics: Availability
Ability of a system to mask or repair faults
such that the cumulative
service outage period does not exceed a
required value over a specified time
Interval.

May be categorized as addressing one of

three categories:
fault detection, fault recovery, and fault
prevention.

Detection tactics depend, essentially, on

detecting signs of life from various
components.
Tactics: Availability
Availability Tactic
Source of Stimulus Users
Stimulus Unable to establish connection to the database
Environment Normal Operation
Artefact Database
Response Detect source that cause the failure, be unavailable for a pre-specified interval
Response Measure The system must be available again with...
Tactics Heartbeat, Passive Redundancy, Removal from Services
Rational To maintain the consistency of the system and highly availability for the users.
Tactics: Availability
Availability Tactic
Source of Stimulus Tour Package Providers
Stimulus Unable to register / Sign up
Environment Normal Operation
Artefact System
Response Detect the failure of unable to register, notify the system admin, disable the
registration feature.
Response Measure Repair Time not to exceed 10 min (Time interval when the system is in degraded
mode).
Tactics Exception, Shadow Operation, Process Monitor
Rational To avoid the failure of the system´s services and components.
Tactics: Modifiability
Tactics to control modifiability have as their
goal controlling the complexity of making
changes, as well as the time and cost to
make changes.

To understand modifiability, we begin with

coupling and cohesion.

May understand tactics and their

consequences as affecting one or more of
the previous parameters: reducing the size
of a module, increasing cohesion,
reducing coupling, and deferring binding
time.
Tactics: Modifiability
Availability Tactic
Source of Stimulus Developers
Stimulus Updating the user interface for modifying information (add, update, delete), to
increase the degree of fault tolerance in user input
Environment Runtime
Artefact System user default
Response Make modification without affecting other funcionality, Test modification, Deploy
modification.
Response Measure Maximum of 3 hours
Tactics Abstract common services, Use an intermediary, Maintain existing interface.
Rational Content must be simple to change, Implement new interface instead so there is no
affect to the existing interface while modification.
Tactics: Modifiability
Availability Tactic
Source of Stimulus System Administrator
Stimulus Installing replicated database for redundancy
Environment Runtime
Artefact Database / System Capacity
Response Make modification without affecting other funcionality.
Response Measure Not more than a period of one month
Tactics Abstract common services, Maintain existing interface
Rational To act as a redundancy database server in case of primary database failure.
Tactics: Performance
Generate a response to an event arriving at
the system within some time-based
constraint:
• Processing time
• Blocked time

Control resource demand. This tactic

operates on the demand side to produce
smaller demand on the resources that will
have to service the events.

Manage resources. This tactic operates on

the response side to make the resources at
hand work more effectively in handling the
demands put to them.
Tactics: Performance
Availability Tactic
Source of Stimulus Users / Tourists / Tour Agencies
Stimulus Multiple users make massive requests for differents services of the system
Environment Peak Period
Artefact System
Response Continue to operate in normal or degraded mode
Response Measure 90% of requests shall be response within 5 sec.
Tactics Increase computational efficiency, Reduce computational overhead, Introduce
Concurrency, Increase Available Resources, Asynchronous.
Rational To be able to maintainaverage performance and avoid deterioration in response
time.
Tactics: Performance
Availability Tactic
Source of Stimulus Users / Tourists / Tour Agencies
Stimulus Multiple users using the system concurrently
Environment Peak Period
Artefact System
Response Changes level of services
Response Measure Number of users the system can handle without deterioration in response time
(average 5 sec peak period response time is maintained.
Tactics Reduce computational overhead, Maintain Multiple Copies, Increase Available
Resources, Asynchronous.
Rational Increase and/or Maintain the time of processing and information retrieval then
response the request within response time.
Tactics: Security
Security is a measure of the system’s
ability to protect data and information
from unauthorized access while still
providing access to people and systems
that are authorized:

• Confidentiality
• Integrity
• Availability
• Authentication
• Nonrepudiation
• Authorization
Tactics: Security
Availability Tactic
Source of Stimulus System Administrator / Tour Packages Providers / External (Hacker)
Stimulus Attempt to change the booking links from database
Environment Normal Operation
Artefact System Database
Response Grant or withdraw permission to modify the data.
Response Measure Percentage of accuracy on detecting unauthorizes access and attempt on modifying
information
Tactics Authenticate users, Authorize users, Maintain data confidentiality, Maintain
Integrity.
Rational Modification, changing, deletion of the information can be only done by authorized
users.
Tactics: Security
Availability Tactic
Source of Stimulus External (Hacker)
Stimulus Crushing the server / try to make the system to be unresponsive
Environment Normal Operation / Peak Period
Artefact System
Response Detecting attack, identifying the individual responsible for attack, notify the
administrator, disable some service to maintain stability (run in degraded mode).
Response Measure Percentage of accurancy on detecting the attack and at least 80% of services are
still available (Robustness to the attack)
Tactics Limit Exposure, Limit Access, Intrusion detection.
Rational To be able to detect the attack and preventing the attack by limit the services that
are available on each host and restrict access based on message source or
destination port.
Tactics: Testability
The goal of tactics for testability is to
allow for easier testing when an
increment of software development is
completed.

Controlling and observing the system

state is a major class of testability
tactics. Providing the ability to do fault
injection, to record system state at key
portions of the system, to isolate the
system from its environment, and to
abstract various resources are all
different tactics to support the control
and observation of a system and its
components.
Tactics: Testability
Availability Tactic
Source of Stimulus System Administrator / Tester
Stimulus Multiple request to edit, change, or add content to the system.
Environment Deployment Time
Artefact Complete System
Response Perform the resquests spontaneously
Response Measure At least 90% requested statements executed with a desired time
Tactics Specialized Access Routines/Interfaces, Built-in Monitors
Rational To focus on users that access to the system and capture all information of them
while the system is running. The system needs to monitor security and performance
load while users access to the system.
Tactics: Usability
One of the most helpful things an
architect can do to make a system
usable is to facilitate experimentation
with the user interface via the
construction of rapid prototypes.

• Learning system features.

• Using a system efficiently.
• Minimizing the impact of errors.
• Adapting the system to user needs.
• Increasing confidence and
satisfaction.
Tactics: Usability
Availability Tactic
Source of Stimulus Tour Packages Providers
Stimulus Disconnected (connection problem) while adding new package.
Environment RunTime
Artefact System
Response Reuse of already entered data
Response Measure Task time, user satisfaction
Tactics Cancel, Undo, User Model
Rational The user may cancel or undo the previous attempt that they were performing and
the system is to assists user.
ADD: Step 5 and 6
Instantiate 1. Instantiate one instance (children) of every
type of element you chose in Step 4.
Architectural Elements 2. Assign responsibilities to instance
elements according to their type.
and Allocate
3. Allocate responsibilities associated with the
Responsibilities and parent element among its children
according to the rationale and element
define interfaces properties recorded in Step 4.
4. Create additional instances of element
types.
5. Analyze and document the design
Sketch views and decisions
6. Define the services and properties required
record design and provided by the software elements in
our design
decisions
ADD: Step 7

1. Verify that all functional requirements,

quality attribute requirements, and design
constraints assigned to the parent
Perform analysis of element have been allocated to one or
more child elements in the
current design and decomposition.
review iteration goal 2. Translate any responsibilities that were
and design objectives assigned to child elements into functional
requirements for the individual elements.
3. Refine quality attribute requirements for
individual child elements as necessary.
Example
Context

Reference example ADD 3.0: Rethinking Drivers and Decisions in the Design Process.
 Inputs: Functional Requirements
Primary Quality
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration

Step 3: Choose one or more elements of the system

to decompose

Step 4: Choose one or more design concepts that

satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Quality Attributes Scenarios
Design
Primary Quality Quality Associated use
functional attributes Constraints Concerns
objectives ID Attribute Scenario case Priority
requirements scenarios
A failure occurs in the management system during operation. The
QA-3 Availability management system resumes operation in less than 30 seconds. All H, H
Step 1: Review Inputs
The management system collects performance data from a network Collect
device during peak load. The management system collects all performancedata
Step 2: Establish iteration goal and select inputs to
be considered in the iteration QA-4 Performance performance data within 5 minutes to ensure no loss of data. (UC-7) H, H
A user displays the event history of a particular network device
Step 3: Choose one or more elements of the system Performance, during normal operation. The list of events from the last 24 hours is Display Event
to decompose QA-5 Usability displayed within 1 second. history (UC-3) H, M
Auser performs a change in the system during normal operation. It is
Step 4: Choose one or more design concepts that possible to know who performed the operation and when it was
satisfy the inputs considered in the iteration QA-6 Security performed 100% of the time. All H, M
Auser performs a change in the system during normal operation. It is
Step 5: Instantiate architectural elements, allocate possible to know who performed the operation and when it was
responsibilities and define interfaces
QA-6 Security performed 100% of the time. All H, M
Auser performs a change in the system during normal operation. It is
Step 6: Sketch views and record design decisions possible to know who performed the operation and when it was
QA-6 Security performed 100% of the time. All H, M
Auser performs a change in the system during normal operation. It is
Step 7: Perform analysis of current design and
review iteration goal and design objectives possible to know who performed the operation and when it was
QA-6 Security performed 100% of the time. All H, M
Auser performs a change in the system during normal operation. It is
Software architecture
design
possible to know who performed the operation and when it was
QA-6 Security performed 100% of the time. All H, M
 Constraints
Primary Quality
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs ID Constraint

CON-1 A minimum of 50 simultaneous users must be supported.
Step 2: Establish iteration goal and select inputs to CON-2 User workstations use the following operating systems: Windows, OSX, and Linux.
be considered in the iteration
CON-3 An existing relational database server must be used.
CON-4 Network connection between users workstations and the server is unreliable
Step 3: Choose one or more elements of the system
to decompose CON-5 Futuresupport for mobile clients
A minimum of 600 time servers must be supported (Initial deployment 100 time servers,
Step 4: Choose one or more design concepts that CON-6 100 more / year during 5 years)
satisfy the inputs considered in the iteration
CON-7 Each time server sends, on average, 10 traps/hour.
Step 5: Instantiate architectural elements, allocate Performance data needs to be collected in intervals of no more than 5 minutes as higher
responsibilities and define interfaces
CON-8 intervals result in time servers discarding data.
CON-9 Events from the last 30 days must be stored
Step 6: Sketch views and record design decisions
CON-10 Thedevelopment team is familiar with Java technologies

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Goal: Iteration 1
Primary Quality
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs • Type Of System: Greenfield in

mature domain
Step 2: Establish iteration goal and select inputs to
be considered in the iteration

Step 3: Choose one or more elements of the system • Objective: Design in

to decompose
preparation for construction of
Step 4: Choose one or more design concepts that
an increment of the system
satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces • Concerns:
• Structure the system
Step 6: Sketch views and record design decisions • Organization of the
codebase
Step 7: Perform analysis of current design and
review iteration goal and design objectives
• Input validation
• Exception management
Software architecture • …
design
 Iteration 1
Primary Quality
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration
• Since this is a greenfield system, the only
Step 3: Choose one or more elements of the system
to decompose element to decompose is the system
Step 4: Choose one or more design concepts that
itself.
satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Selection of design concepts
Primary Quality • Mobile applications, Rich client applications, Rich internet applications,
Design
objectives
functional
requirements
attributes
scenarios
Constraints Concerns
Service Applications, Web Applications

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration

Step 3: Choose one or more elements of the system

to decompose

Step 4: Choose one or more design concepts that

satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Architecture Design and Views
Primary Quality
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration

Step 3: Choose one or more elements of the system

to decompose

Step 4: Choose one or more design concepts that

satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Architecture Design and Views
Primary Quality
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration

Step 3: Choose one or more elements of the system

to decompose

Step 4: Choose one or more design concepts that

satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Design Kanban Board
Primary Quality
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration

Step 3: Choose one or more elements of the system

to decompose

Step 4: Choose one or more design concepts that

satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Goal: Iteration 2
Primary Quality
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

• Objective: Identify the
Step 2: Establish iteration goal and select inputs to elements that support
be considered in the iteration
the primary
Step 3: Choose one or more elements of the system
to decompose
functionality
Step 4: Choose one or more design concepts that
satisfy the inputs considered in the iteration

• Inputs:
Step 5: Instantiate architectural elements, allocate
responsibilities and define interfaces • Primary Use Case

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Iteration 2
Primary Quality
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration Functional Requirements
Step 3: Choose one or more elements of the system
to decompose

Step 4: Choose one or more design concepts that

satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Selection of design concepts
Primary Quality • Domain objects, externally developed components
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration

Step 3: Choose one or more elements of the system

to decompose

Step 4: Choose one or more design concepts that

satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Architecture Design
Design
and Views Primary Quality
functional attributes Constraints Concerns
objectives
requirements scenarios

Logical View
Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration

Step 3: Choose one or more elements of the system

to decompose

Step 4: Choose one or more design concepts that

satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Interfaces
Primary Quality
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration

Step 3: Choose one or more elements of the system

to decompose

Step 4: Choose one or more design concepts that

satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Goal: Iteration 3
Primary Quality
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

• Objective: Address
Step 2: Establish iteration goal and select inputs to
quality attribute QA-3:
be considered in the iteration A failure occurs in
Step 3: Choose one or more elements of the system
the network
to decompose management system
Step 4: Choose one or more design concepts that
during operation. The
satisfy the inputs considered in the iteration
system resumes
Step 5: Instantiate architectural elements, allocate operation in less than
responsibilities and define interfaces
30 seconds.
Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and • Inputs:

review iteration goal and design objectives
• Quality Attributes
Scenarios
Software architecture
design
 Quality Attributes
Iteration 2 ID
Quality
Attribute Scenario
Associated use
case Priority
Primary Quality A failure occurs in the management system during operation. The
Design
functional attributes Constraints Concerns QA-3 Availability management system resumes operation in less than 30 seconds. All H, H
objectives
requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration

Since the scenario involves a

Step 3: Choose one or more elements of the system
to decompose failure of the system, the
selected elements are tiers
Step 4: Choose one or more design concepts that
satisfy the inputs considered in the iteration identified in the first
iteration
Step 5: Instantiate architectural elements, allocate
responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Selection of design concepts
Primary Quality • Tactics and from go to patterns or technologies
Design
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration

Step 3: Choose one or more elements of the system

to decompose

Step 4: Choose one or more design concepts that

satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
 Architecture Design
Design
and Views Primary Quality
functional attributes Constraints Concerns
objectives
requirements scenarios

Step 1: Review Inputs

Step 2: Establish iteration goal and select inputs to

be considered in the iteration

Step 3: Choose one or more elements of the system

to decompose

Step 4: Choose one or more design concepts that

satisfy the inputs considered in the iteration

Step 5: Instantiate architectural elements, allocate

responsibilities and define interfaces

Step 6: Sketch views and record design decisions

Step 7: Perform analysis of current design and

review iteration goal and design objectives

Software architecture
design
Practice
Bibliography
• Attribute Driven Design (ADD), Version 2.0
https://resources.sei.cmu.edu/asset_files/TechnicalReport/2006_005_001_14795.pdf
• Bass, Len. Clements, Paul. Zachman, Rick. Software Architecture in Practice. 3rd
Eddition.
• ADD 3.0: Rethinking Drivers and Decisions in the Design Process
https://resources.sei.cmu.edu/asset_files/Presentation/2015_017_101_438648.pdf
Gracias
Javier Eduardo Vargas M.
[email protected]
Diego Felipe Moreno Rodríguez
[email protected]