CS 

3212
Software Architecture & Design
(2011/2012)

Lecture 6
Achieving Quality Attributes
 Software Architecture in Practice

REFERENCE SLIDES

2nd Ed.
Len Bass, Paul Clements, Rick Kazman
 Overview

• Introduction to Architectural Tactics

• Tactics for Quality Attributes
• Tactics and Design Patterns
• Architectural Perspectives
 Introducing Tactics

• A tactic is a design decision that influences the

control of a quality attribute response.
• A collection of tactics is an architectural strategy .
• Tactics can refine other tactics: redundancy can be
refined into data or computational redundancy.
• Patterns package tactics: an availability pattern
uses both redundancy & synchronization tactics.
 Overview

• Introduction to Architectural Tactics

• Tactics for Quality Attributes
• Tactics and Design Patterns
• Architectural Perspectives
 Availability Tactics
• Fault Detection
– Ping/echo
– Heartbeat • Fault Prevention
– Exceptions – Removal from service
– Transactions
• Fault Recovery – Process monitor
– Voting
– Active redundancy (hot restart)
– Passive redundancy (warm restart)
– Spare
– Shadow operation
– State synchronization
– Checkpoint/rollback
 Modifiability Tactics

• Localize modifications
– Maintain semantic coherence
– Anticipate expected changes
– Generalize the module
– Limit possible options
 Modifiability, con’t

• Defer Binding Time

– Runtime registration
– Configuration files
– Polymorphism
– Component replacement
– Adherence to defined protocols
 General Definition

Tactics to
Control
Stimulus Response Response

Tactics are intended to control responses to stimuli

 Performance Tactics

Tactics to
Control
Events Performance Response generated
arrive within time
constraints

Goal of Performance Tactics

 Categories of Architectural
Tactics
• Security
– Resisting attacks
– Detecting attacks
– Recovering from attacks
• Testability
– Input/Output
– Internal monitoring
• Usability
– Runtime
– Design-time
 Overview

• Introduction to Architectural Tactics

• Tactics for Quality Attributes
• Tactics and Design Patterns
• Architectural Perspectives
 Architectural Tactics & Patterns

• An architect usually chooses a pattern or

collection of patterns, but any pattern implements
several tactics.
• Each of these tactics is often concerned with
different quality attributes
• Any implementation of the pattern makes choices
about tactics.
 Example:
Active Object Design Pattern

• Decouples method execution from method invocation

to enhance concurrency and simplify access to objects
that reside in their own thread of control.
• Goal is to achieve “Performance” via the “Introduce
Concurrency” tactic.
• However, the pattern involves other tactics concerned
with different quality attributes.
Active Object Design Pattern
 Tactics & Patterns

• Thus for an architect, the analysis process involves

understanding all tactics embedded in an
implementation.
• The design process involves making a judicious
choice of what combination of tactics will achieve
the system’s desired goals.
 Overview

• Introduction to Architectural Tactics

• Tactics for Quality Attributes
• Tactics and Design Patterns
• Architectural Perspectives
 Security Perspective Accessibility Perspective
Performance Perspective Location Perspective
Availability Perspective Modifiability Perspective
Usability Perspective Etc.

Functional View Development View

Information View Deployment View

Concurrency View Operational View

23

Applying Perspectives to Views

 Security Perspective

• Security is an important factor that affects aspects

of the architecture addressed by most, if not all of
the other viewpoints.
• Furthermore, which of the system's security
qualities are significant depends on which
viewpoint we are considering.
 Security Perspective

Functional viewpoint: The system needs the ability to identify and

authenticate its users (internal and external, human and
mechanical). Security processes should be effective but
unobtrusive, and any external processes exposed to the outside
world need to be resilient to attack.

Information viewpoint: The system must be able to control

different classes of access to information (read, insert, update,
delete). The system may need to apply these controls at varying
levels of granularity (e.g., defining object-level security within a
database).
 Security Perspective

Operational viewpoint: The system must be able to maintain and

distribute secret information (e.g., keys and passwords) and
must be up-to-date with the latest security updates and patches.
Development, Concurrency, and Deployment viewpoints: Certain
aspects of the architecture will be affected by security needs.

So the overall criterion of "the system must be secure" actually

breaks down across the viewpoints into a number of more
specific criteria.
 Applying Perspectives to Views

Security Performance Availability

Functional
View

Information Access Control, Access Classes,

View Object-Level Security

Concurrency Shared resources, blocking, queuing,

View coordination

Development
View

Deployment
View

Operational
View