A Systematic Approach to

Making Architecture Design

Decisions
Software Architecture Design

The design for a system consists of a collection

of decisions.
Design is the process of making decisions.
Decisions made early constrain ones made
later.

So
make decisions early that have the farthest
reaching impact.
Categories of Architectural Concerns
1. Coordination model
2. Data and object model
3. Allocation of functionality
4. Management of resources
5. Binding time decisions
6. Mapping among architectural elements
7. Choice of Technology
Coordination Model

Determine which elements of the system need to
coordinate and what the properties of that
coordination are; e.g. timeliness, currency,
completeness, correctness, consistency

Determine the coordination model (between the
system and non-system entities, between system
elements, within elements) and what communication
mechanisms realize this model. Determine what
information they share. Determine if this information
be completely consistent all the time.

Determine the properties of the communication
mechanisms; e.g., synchronous, asynchronous,
guaranteed delivery, throughput, latency,
Data and Object Model

Determine the major data abstractions,
operations, and properties, and whether they
support inter-element communication.

Determine which abstraction mechanisms are
used.

Determine whether the object model makes it
easy to model entities in the application
domain.
Allocation of Functionality

Determine the allocation of major system functions
to architectural elements; e.g., payroll processing,
inventory management, missile tracking, map
display

Determine how the major modes of operation are
realized; e.g. startup, normal processing, overload
processing, backup/recovery, degraded operation,
takeoff, landing, level flight,

Determine the major responsibilities and how they
are allocated to hardware and software, run-time
and non run-time elements (components and
modules)? e.g. functional decomposition,
decomposition based on frame rates, decomposition
based on modeling real-world objects, information
hiding decomposition,
Management of Resources

Determine what resources need to be managed.

Determine the resource limits.

Determine the hard resources (e.g. CPU, memory,
battery, hardware buffers, system clock, I/O ports,
...) and the soft resources (e.g. system locks,
software buffers, thread pools, )

Determine what system element(s) manage what
resources.

Determine what resources are shared and how
these are arbitrated; e.g., what process/thread
models will be employed? what scheduling
strategies will be employed?
Binding Time Decisions

Determine how and when are decisions in the
other models are resolved.
 Compile time (e.g., compiler switches)
 Build time (e.g., replace modules, pick from
library)
 Load time (e.g., dynamic link libraries [DLLs])
 Initialization time (e.g., resource files)
 Run time (e.g., load balancing)
Mapping Among Architectural
Elements

Determine how elements in different
architectural structures map to each other, e.g.
 Determine how modules and runtime elements map to
each other. Determine what runtime element(s) are
created for each module. Determine what module(s)
contain the code for each runtime element.
 Determine how runtime elements are assigned to
processors.
 Determine how objects in the data model are assigned
to data stores.
 Determine how modules and runtime elements are
mapped to units of delivery.
Choice of Technology

Determine what technologies are available to realize
the architecture.

Determine how the choice of technology affects
operational considerations: deployment, usage, and
interoperation options.

Determine how the choice of technology affects
business considerations: cost, pedigree, availability
of personnel, market size, productivity, integration
with existing systems/enterprise architecture,
opportunity enablement.

Determine what tools are available to support this
technology choice (IDEs, testing tools, ).
Questions vis--vis QAs

For each of the 7 design decision categories we can
now elaborate on 8 sets of questions for the
architecture, for each of the following QAs:
 Availability
 Interoperability
 Modifiability
 Performance
 Safety
 Security
 Testability
 Usability
How Are Early Design Decisions Made?
Early software architecture design decisions
are made in the context of these architectural
drivers.
For each decision you make, consider whether
the decision impacts any of the architectural
drivers (supports them or hinders them).
For example, consider the early design
decisions associated with the Coordination
model and the communication mechanisms
between the system and external entities
Allocn of Functionality/ Availability

Determine the system responsibilities that need
to be highly available.

Within those responsibilities, ensure that
additional responsibilities have been allocated to
detect an omission, crash, incorrect timing, or
incorrect response and perform the following:
 log the fault
 notify appropriate entities (people or systems)
 disable source of events causing the fault
 be temporarily unavailable
 fix or mask the fault/failure
 operate in a degraded mode
Allocn of Functionality/ Modifiability

Determine which changes or categories of changes are likely to occur
through consideration of changes in technical, legal, social, business, and
customer forces. For each change or category of changes
 Determine whether the changes will be made by an end user, a privileged user, or a
developer. For those changes to be made for some category of user, determine when
those changes will be made: runtime, compile time, design time, and build time.

For those changes to be made by an end user or privileged user, determine
the mechanisms (plug-ins, pub/sub, etc) to be used to allow the user to
make the desired changes during runtime. Ensure that responsibilities have
been allocated to implement these mechanisms.

For those changes to be made by a privileged user, ensure that
responsibilities have been allocated to determine whether the user has the
correct privileges and to ensure that only privileged users can make the
change.

For each potential change or category of changes
 Determine the responsibilities that would need to be added, modified, or deleted to
make the change.
 Determine what other responsibilities are impacted by the change.
 Determine an allocation of responsibilities to modules that places, as much as possible,
responsibilities that will be changed (or impacted by the change) together in the same
module, and places responsibilities that will be changed at different times in separate
modules.
Allocn of Functionality/ Performance

Determine those portions of the system that will be heavily loaded,
have time-critical response requirements, or impact portions of the
system where heavy loads or time critical events occur. For those
portions of the system, ensure that responsibilities have been
allocated to recognize and process requests appropriately. For the
responsibilities enumerated above, identify
 the threads of control that would execute these responsibilities including
combinations of threads crossing multiple processors
 additional responsibilities that result from design decisions impacting the
responsibilities, such as the impact of crossing process or processor boundaries
 additional responsibilities to manage the threads of control responsibilities for
allocation of threads, deallocation of threads, maintaining thread pools, and so on
 resources that may act as bottlenecks for executing these types of responsibilities
 processing requirements of each responsibility

For the enumerated responsibilities and resources, ensure that
performance requirements can be met.
Allocn of Functionality/ Security

Determine which system responsibilities need to be secure. For each of
these responsibilities ensure that additional responsibilities have been
allocated to identify individuals and systems and to determine whether
they are
 identified correctly; identified incorrectly; of unknown identity

Ensure that additional responsibilities have been allocated to decide, for
individuals and systems, whether they are
 internal or external; authorized/not authorized

Ensure that additional responsibilities have been allocated to decide, for
individuals and systems, whether they have
 limited access to specific resources; access to all resources

Ensure that additional responsibilities have been allocated to perform
the appropriate items from the following list
 authenticate the user
 hide the identity of the user
 grant or deny access to data and/or services
 record access/modification/attempts to access data and or services
 store data in encoded format
 recognize unexplainably high demands for services and inform appropriate personnel
and restrict access
 recover from an attack
Allocn of Functionality/ Testability

Determine which system responsibilities need to be most
thoroughly tested.

Ensure that additional responsibilities have been
allocated to do the following:
 execute test suite and capture results
 capture the activity that resulted in a fault
 inject state into the system
Allocn of Functionality/ Usability

Determine which system responsibilities need to be
usable.

Ensure that additional responsibilities have been
allocated to assist the user in
 learning how to use the system
 achieving the task at hand task
 adapting and configuring the system
 recovering from user and system errors
Allocn of Functionality/ Safety

Determine which system responsibilities will be safety
critical.

Ensure that, within these portions of the system,
additional responsibilities have been allocated to detect
failures of omission or commission, as well as failures
caused by early or late events. Both coarse incorrect and
subtle incorrect failures should be detected.

Ensure that additional responsibilities have been
allocated to
 recover, continue in degraded or safe mode, shut down, or switch to
manual operation
 notify appropriate entities (people or systems)
 log the failure (and the response to it)
Allocn of Functionality/ Interoperability

Determine which system responsibilities will need to
interoperate with (exchange information with) other
systems.

Ensure that additional responsibilities have been
allocated to detect a request to exchange information
with an external system and to determine whether the
external system is
 known to our system
 not known to our system

Ensure that responsibilities have been allocated to
 reject the request and notify appropriate entities (people or systems),
and log the request
 accept the request and exchange information
Coordination Model/ Availability

Determine the system responsibilities that need to be highly
available.

With respect to those responsibilities
 Ensure that coordination mechanisms exist to detect an omission,
crash, incorrect timing, or incorrect response. Consider, for
example, whether guaranteed delivery is necessary. Will the
coordination work under conditions of degraded communication?
 Ensure that coordination mechanisms exist to log the fault, notify
appropriate entities, disable the source of events causing the fault,
fix or mask the fault, or operate in a degraded mode
 Ensure that failures of system responsibilities and the artifacts that
support them (processors, communications channels, persistent
storage, and processes) can be communicated and replaced; e.g.,
does failure of an external entity cause the coordination to fail?
 Determine if the coordination will work under conditions of degraded
communication, at startup/shutdown, in repair mode, or under
overloaded operation. For example, how much lost information can
the coordination model withstand and with what consequences
Coordination Model / Modifiability

Determine which functionality or quality attribute can
change at runtime and how this affects coordination; for
example, will the information being communicated
change at run-time?

Determine which devices, protocols, and communication
paths that are used for coordination will change. For
those devices, protocols, and communication paths,
ensure that the impact of changes will be limited to a
small set of modules.
Coordination Model / Performance

Determine
 the elements of the system that must coordinatedirectly or indirectly
and ensure that the desired properties of that coordinationfor example,
deadlines, currency, throughput, latency, miss rate, data losscan be
met.
 the communication and coordination mechanisms necessary to capture
periodic, stochastic, or sporadic event arrivals
 the properties of the communication mechanisms, for example, stateful,
stateless, synchronous, asynchronous, guaranteed delivery, throughput,
or latency.
Coordination Model / Security

Determine mechanisms to communicate and coordinate with a system or
individual who is identified correctly, identified incorrectly, or of unknown
identity, and who is internal or external, authorized or not authorized, with
limited access to specific resources or to unlimited resources.

For the problematic communications, enumerate possible system actions
such as authenticating the user, hiding the identity of the user, granting or
denying access to data and/or services, recording
access/modification/attempts to access data and or services, encoding data
for transmission across the connection, recognizing unexplainably high
demands for services and inform user of the system and/or restricting the
connection.
Coordination Model / Testability

Determine the systems coordination mechanisms to
ensure that they will
 support the execution of a test suite and the capture of the results
within a system or between systems
 support capturing activity that resulted in a fault within a system
or between systems
 support injection of state into the communication channels for use
in testing, within a system or between systems
Coordination Model / Usability

Determine if the properties of system elements
coordinationtimeliness, currency, completeness,
correctness, consistencyaffect how a user learns to
use the system, achieves his or her task, adapts and
configures the system, recovers from user and system
errors, increases confidence and satisfaction. For
example, can the system respond to mouse events and
give semantic feedback in real time? Can long-running
events be canceled in a reasonable amount of time?
Coordination Model / Safety

Determine the coordination among system elements that
is necessary to detect failures of the following
categories: omission, commission, early, late, coarse
incorrect, or subtle incorrect.
 Ensure that the systems coordination, particularly in the face of a
failure, will support recovery, continuing in a degraded or safe
mode, shut down, or switching to manual operation, notifying
appropriate entities (people or systems), and logging the failure
(and the response to it).
Coordination Model / Interoperability

Ensure that when a request arrives to exchange information with a
known or unknown external system, there are responsibilities for
 determining the location of the known external system
 verifying that the system at that location is the correct system
 preparing a message for transmission to the external system
 accepting messages from external system
 verifying authenticity and validity of the messages from the external system
 setting those properties of the interchange that must be determined at run
time, such as timeliness, currency, completeness

If the messages are authentic, there should be responsibilities for
 translating messages from external system into appropriate internal
representation
 making the internal recipients of the messages aware of their existence

If the messages are not authentic then there should be
responsibilities for
 rejecting the messages
 informing appropriate parties of the arrival of non-authentic messages
 logging information about the non-authentic messages
Thats a lot of Questions!

These categories of design decisions have
led us to QA-specific questions.

But what do we, as architects, do to design
the solutions?
Architecture Design Workflow
Identify problem to solve.
 Characterize the quality attribute.
 Determine importance and difficulty.
 Analyze existing architectural approaches.
Identify the solution options.
 Generate hypotheses patterns/tactics that might solve the
problem.
Make design decisions.
 Assess options Select patterns/tactics and apply them.
 Rework architecture.
Manage design decisions.
 Manage backlog of problems, solution options, etc.
 Ensure consistency as decisions change.
Tactics-Based Approach to Design
In each design round we follow the software
architecture design workflow:
 Identify problem to solve: Pick one or more quality
attributes identified as the architectural drivers.
 Identify the solution options: Determine patterns/tactics
associated with quality attributes and constraints.
 Make design decisions: Select patterns/tactics, apply and
document them, and make additional design decisions.

We build our design concept iteratively applying

patterns, tactics, and design decisions.
Making Design Decisions
The core of the design process consists of the
designer generating a hypothesis and then testing
that hypothesis against some criteria.
 If the hypothesis does not pass the test, another hypothesis
is generated and tested.
The decisions made to manage QA responses are
called tactics.
Tactics have a role in
 the generation of hypotheses
 the validation of a design hypothesis

Lets examine tactics in detail.

Tactics 1

A systems design is a collection of decisions:
 Some decisions are made to achieve the systems
functionality.
 Other decisions are made to control quality
attribute responses.
Tactics 2.
Tactics to Response
Stimulus
Control
Response

Each tactic is a design option for the architect

 E.g., to promote availability, we might choose the Active
Redundancy tactic.

Each tactic is a hypothesis
 Active redundancy may or may not provide an adequate
level of availability.

Patterns package tactics
 E.g., a pattern that supports availability will likely use some
redundancy tactic.
Availability Tactics 1
Tactics to Response
Stimulus
Control
Fault Fault Masked
Response or Repair Made

Fault detection
 Ping/Echo: when one component issues a ping and expects to
receive an echo within a predefined time from another component
 System Monitor: is used to monitor state of health, which includes
the detection of hung or runaway processes
 Voting: used to detect any inconsistency among the output states
of observed processes
 Exception Detection: detection of a system condition that alters
the normal flow of execution
Availability Tactics 2 Fault Fault
Masked or
Repair Made
Fault recovery: Preparation and repair
 Active Redundancy: when redundant components are
used to respond to events in parallel
 Passive Redundancy: when a primary component
responds to events and informs standby components
of the state updates they must make
 Spare: when a standby computing platform is
configured to replace failed components
 Exception handling: manage the detected exceptions
 Software upgrade: in-service upgrades to executable
code in a non-service-affecting manner
Availability Tactics 3 Fault Fault
Masked or
Repair Made
Fault recovery and reintroduction
 Shadow Operation: running a previously failed component in
shadow mode before it is returned to service
 State Resynchronization: saving a state periodically and then
using it to resynchronize failed components
 Rollback: allows system state to be reverted to the most recent
consistent set of checkpoints
 Escalating restart: varies the granularity of the components
restarted to minimizing the level of service affectation
 Non-Stop Forwarding: a device can maintain proper functioning
of the data plane, even when its control and/or management
planes are out of service
Availability Tactics 4. Fault Fault
Masked or
Repair Made
Fault prevention
 Removal from Service: removing a system component from
operation so it can undergo a procedure that will help it
avoid failure in the future (e.g., rebooting a component
prevents failures caused by memory leaks)
 Transactions: the bundling of several sequential steps such
that the entire bundle can be undone at once
 Process Monitor: Monitoring processes are used to monitor
critical components, remove them from service. and
re-instantiate new processes in their place.
 Exception Prevention: preventing exceptions from
occurring in the first place (e.g. smart pointers, wrappers)
Summary of Availability Tactics
Thinking About Performance - 1
The goal of performance tactics is to generate
a response to an event arriving at the system
within some time constraint.
Two basic contributors to the response time are
resource consumption and blocked time.
After an event arrives, either the system is
processing on that event or the processing is
blocked for some reason.
Thinking About Performance - 2
Resource consumption
 Resources include central processing unit (CPU),
data stores, network communication bandwidth,
and memory.
Blocked time
 A computation can be blocked from using a
resource because

there is contention for the resource,

the resource is unavailable, or

the computation depends on the result of other
computations that are not yet available.
 Queuing Model for Performance

Scheduling
Results
Arrivals algorithm
Queue
Server
Routing of
messages
Parameters:
Arrival rate
Queuing discipline
Scheduling algorithm Latency (time to compute
Service time results) can only be affected
Topology by changing one of the
Network bandwidth
parameters.
Routing algorithm
Managing Performance
Architectural means for controlling the parameters of a
performance model:
 Arrival rate restrict access, differential rate/charging structure
 Queuing discipline first-come first served (FCFS), priority
queues, etc.
 Service time

Increase efficiency of algorithms.

Cut down on overhead (reduce inter-process communication, use
thread pools, use pool of DB connections, etc.).

Use faster processor.
 Scheduling algorithm round robin, service last interrupt first, etc.
 Topology add/delete processors
 Network bandwidth faster networks
 Routing algorithm load balancing
Performance Tactics - 1
Tactics to Response
Stimulus
Control
Event Response Response generated
Arrives within time constraints

Performance tactic categories and their goals:

 Control Resource demand: Reduce or manage
the demand for resources.
 Manage Resources: Manage resources even
though the demand for resources is not
controllable.
 Arbitrate Resources: Control contention for
resources through scheduling.
Performance Tactics 2 Event Response
generated
Arrives
within time

Resource demand. constraints

 Increase computational efficiency: improving

algorithms used in critical areas will have the effect
of decreasing latency.
 Reduce computational overhead: reducing the need
for and use of resources, thereby reducing
processing.
 Manage event rate: reducing the arrival rate of
variables to which the system monitors or responds.
 Control frequency of sampling: queuing the arrival of
events and sample at a lower frequency.
Performance Tactics 3 Event Response
generated
Arrives
within time

Resource management. constraints

 Introduce concurrency: processing requests in

parallel thereby reducing blocked time.
 Maintain multiple copies: reducing the contention
that would occur if all data were accessed at a
single location or computations were performed
on a single resource.
 Increase available resources: using more and/or
faster processors, more and/or faster memory,
more and/or faster networks, and so forth.
Performance Tactics 4. Event Response
generated
Arrives
within time

Resource arbitration. constraints

 Scheduling policy: analyzing the usage

characteristics of each resource and choose
compatible scheduling strategies.

First in first out: treats all requests as equals.

Fixed priorities: assigns resources in fixed order of
priority.

Dynamic priorities: re-orders priorities (round robin) or
schedule those resources with the earliest deadlines.

Static scheduling: preemption and the sequence of
priority assignments are determine offline (compile
time).
Summary of Performance Tactics
Performance Tactics

Control Resource Manage Arbitrate

Demand Resources Resources

Response
Generated
Events within Time
Arrive Increase Scheduling
Introduce Constraints
Computational Policy
Concurrency
Efficiency
Reduce Maintain
Computational Multiple Copies
Overhead

Manage Event Increase

Rate Available
Resources
Control Frequency
of Sampling

Bound Execution
Times
Bound Queue
Sizes
Thinking About Modifiability - 1

The goal of modifiability tactics is to control
the time and cost to implement, test, and
deploy changes.

There are three aspects of modifiability:
 What is being changed?
 When in the life cycle does the change occur?
 How is the change measured?
Thinking About Modifiability 2.

Modification involves one or more of:
 Changing a responsibility
 Adding a new responsibility
 Deleting a responsibility

A modification may affect data and/or control
flow.

There may be additional responsibilities that
depend on the responsibility being modified.
This is called the ripple effect.
Dependency Analysis - 1

The Prevent Ripple Effects set of modifiability
tactics is fundamentally about dependency:
 If module A depends on module B, modifications
to B may require modifications to A.

Dependencies can be either code or data related.
 The tactics for achieving modifiability are all aimed
at reducing dependencies.

E.g., a tactic for reducing dependencies between two
modules is the introduction of intermediaries.
Dependency Analysis - 2

Intermediaries can be used to reduce code
and/or data dependencies:
 Code dependencies

Encapsulation is a form of indirection acting as an
intermediary to reduce code dependencies between two
elements.

Other forms of code intermediaries are virtual machines
and interpreters.
 Data dependencies

A data repository will reduce data dependency between
modules.
Cost Model for Modifiability
Key
Module
Resp. A A Module

cost Responsibility

propagates to
strength of assigned to

coupling Resp. B
Module
B

Resp. C
life cycle time
maximizing Module
relationships
C
Resp. D
Parameters:
average cost of modifying Cost (the number of elements
a single responsibility
coupling
affected, effort, money) can be
cohesion affected only by changing one of
life cycle time of modification the parameters.
Managing Modifiability

Architectural means for controlling the
parameters of a modifiability model
 Average cost of modifying a single responsibility:
reducing the cost of modifying a single responsibility
by splitting the responsibility into two portions based
on anticipated changes.
 Coupling: reducing coupling by breaking or weakening
dependencies.
 Cohesion: increasing cohesion by moving
responsibilities from one module to another.
 Life cycle time of modification: reducing the cost by
deferring bindings.
Modifiability Tactics 1 Change Changes
Arrives made,
tested,

Increase cohesion deployed
 Maintain semantic coherence: ensuring that all of the
responsibilities in a module work together without
excessive reliance on other modules.
 Abstract common services: provide a more abstract,
generic version of a service.
Modifiability Tactics 2 Change Changes
Arrives made,
tested,

Prevent ripple effects. deployed
 Use an intermediary: utilizing repositories, bridges,
proxies, name servers, resource brokers, and so forth.
 Restrict communications paths: restricting the
modules with which a given module shares data.
 Introduce an abstraction: parameterize the common
services so that they are useful in a wide variety of
contexts.
 Use encapsulation: providing common services
through specialized modules.
Modifiability Tactics 3. Change Changes
Arrives made,
tested,

Defer binding time. deployed
 coding time  initialization time

use aspect-oriented
use resource files
programming

use polymorphism
 runtime

use runtime registration

parameterize modules

interpret parameters
 build time
use start-up time binding

use component
use runtime binding
replacement

use name servers
 deployment time
use plug-ins

use configuration-time
binding
Summary of Modifiability Tactics
Security 1 Attack System detects,
resists, or
recovers from
attacks

Detect attacks
 Detect Intrusion: typically realized as an intrusion detection
system, comparing network activity to a set of signatures.
 Detect Service Denial is used to identify denial of service
(DOS) attacks where a large load is placed on the system.
To achieve this, the pattern or signature of incoming traffic
is compared to historic profiles of known attacks.
Security 2 Attack System detects,
resists, or
recovers from
attacks

Resist attacks
 Maintain confidentiality: encrypt data and communication
 Maintain integrity: through the use of encoded redundancy
information such as checksums and hash results.
 Limit exposure: allocate services to hosts and limit the
availability of services to a limited number of hosts
 Limit access:

Authenticate actors. e.g. via passwords, biometrics, digital certificates

Authorize actors. ensure that an authenticated actor has the rights to
access and modify either data or services.

Identify actors. e.g. via userids, access codes, IP addresses,
protocols, etc.

Limit access to computing resources. such as memory, network
connections, data, access points, and implementation details.
Security 3. Attack System detects,
resists, or
recovers from
attacks

Recover from attacks
 Restore:

See availability tactics
 Identify: maintain an audit trail of each transaction
applied to data and access to services
Summary of Security Tactics
Testability 1 Completion Faults
of an detected
increment

Managing input/output testing.
 Record/playback: using record and playback information
that crosses interface boundaries.
 Separate interfaces from implementations: substituting
implementations for various testing purposes.
 Specialized access routes/interfaces: testing interfaces or
pathways to components allowing the capture or
specification of test data independent of normal execution.

Internal monitoring.
 Built in monitors: provide access to state, performance,
security, or other information; record information and notify
people/systems if values are out of expected ranges.
Summary of Testability Tactics
Usability 1 User request User given
appropriate
feedback and
assistance

Separate user interface (UI).

 Design-time tactic: Separating the UI from the rest of
the application thereby localizing changes to it.
Usability 2 User request User given
appropriate
feedback and
assistance

Support User Initiative

 Cancel
 Undo
 Pause/Resume
 Aggregate
Usability 3 User request User given
appropriate
feedback and
assistance

Support System Initiative

 Maintain user model: maintaining the users
knowledge of the system and behavior and response
appropriately.
 Maintain system model: modeling the expected
behavior of the system so that appropriate feedback
can be given to the user.
 Maintain task model: determining the context so that
the system has some idea of what the user is
attempting to accomplish and can provide assistance.
Summary of Usability Tactics
 Tactics to
Safety 1 Failure
Control
Safety Failure avoided
or handled

Failure Avoidance
 Simplicity: Consolidate components, minimizing the
number of architectural elements, their interfaces, and
the number of unknowns in terms of interactions of
those elements, thereby limiting the opportunities for
failures.
 Substitution is where safer hardware protection
mechanisms are employed for potentially dangerous
software design features, e.g. hardware protection
devices such as watchdogs, monitors, and interlocks
 Tactics to
Safety 2 Failure
Control
Safety Failure avoided
or handled

Failure Detection
 Timeout
 Timestamp
 Sanity Checking
 Condition Monitoring
 Comparison
 Tactics to
Safety 3 Failure
Control
Safety Failure avoided
or handled

Failure Containment
 Redundancy: Replication, Functional redundancy,
analytic redundancy
 Recovery: Rollback, Fix the errors, Degradation, and
Reconfiguration
 Masking: Voting
 Barrier: Firewall, Interlock
Summary of Safety Tactics
Interoperability 1 Information
Exchange
Tactics to
Control
Interoperability
Information
Correctly
Request Exchanged

Reduce coupling
 see Modifiability

Increase cohesion
 see Modifiability
Interoperability 2. Information
Exchange
Tactics to
Control
Interoperability
Information
Correctly
Request Exchanged

Manage Interfaces
 Orchestrate: using a mediator or something more
complex like BPEL
 Translate Interface: using bridges, adapters, etc.
 Extend Interface: using wrappers, decorators, etc.
Summary of Interoperability Tactics
Tactics and Patterns
Tactics and Patterns - 1
A tactic is a design decision that is influential in the
control of a single quality attribute response.
A pattern is a prepackaged solution to a recurring
problem that resolves multiple forces.
Where to find patterns:
 Design Patterns: Elements of Reusable Object Oriented
Software
 Pattern-Oriented Software Architecture
 Core J2EE Patterns
 Hillside Group Pattern Library
 Conference on Pattern Languages of Programs (PLoP)
Tactics and Patterns 2. Patterns typically have at
least these four parts.

Pattern Name

Problem &
Solution
Context

Consequences

If you have a pattern in mind A tactic is a design step, transforming

for your problem, use it. the architecture to address a quality
attribute of interest.

Use tactics when you need help coming up with a pattern,

when an existing pattern isnt quite right and you need to
tailor it, or when you want to validate the choice of a pattern.
Tactics and Interactions
Tactics can and do interact with other tactics and with
patterns to resolve multiple forces.

For example, consider a system that needs to detect

faults.*

* Adapted from: K. Kumar, T.V. Prabhakar, Towards Formalizing Architecture Tactics

Knowledge
Tactics and Interactions - 2
A common tactic for detecting faults is
Ping/Echo.
Common side-effects of Ping/Echo are:

security: how to prevent a ping flood attack?

performance: how to ensure that the performance
overhead of ping/echo is small?

modifiability: how to add ping/echo to the existing
architecture?
Tactics and Interactions - 3

System

Ping/Echo

Add to Ping Performance

system flood overhead
Tactics and Interactions - 4
A tactic to address the performance side-effect
is Increase Available Resources.
Common side effects of Increase Available
Resources are:

cost: increased resources cost more

performance: how to utilize the increase resources
efficiently?
Tactics and Interactions - 5
System

Ping/Echo

Add to Ping Performance

system flood overhead

Increase Available
Resources

Resource
Cost
Utilization
Tactics and Interactions - 6
A tactic to address the efficient use of
resources side-effect is Scheduling Policy.
Common side effects of Scheduling Policy are:

modifiability: how to add the scheduling policy to the
existing architecture

modifiability: how to change the scheduling policy in the
future?
Tactics and Interactions - 7
System

Ping/Echo

Add to Ping Performance

system flood overhead

Increase Available
Resources

Resource
Cost
Utilization

Scheduling
Policy

Add to Modify
system policy
Tactics and Interactions - 8
A tactic to address the addition of the scheduler
to the system is Use an Intermediary.
Common side effects of Use an Intermediary
are:

modifiability: how to ensure that all communication
passes through the intermediary?
Tactics and Interactions - 9
System

Ping/Echo

Add to Ping Performance

system flood overhead
Increase Available
Resources

Cost Resource
Utilization
Scheduling
Policy

Add to Modify
system policy
Use an
Intermediary

Ensure
usage
Tactics and Interactions 10.
A tactic to address the concern that all
communication passes through the
intermediary is Restrict Communication
Paths.
Common side effects of Restrict
Communication Paths are:

performance: how to ensure that the performance
overhead of the intermediary are not excessive?

Note: this design problem has now become recursive!

Broker Pattern Exercise
You have seen how tactics can and do interact
with other tactics and with patterns to resolve
multiple forces.
Now consider a common pattern: the Broker.
Like all patterns, it is under-specified.
How do we improve it and tailor it?
Broker Pattern - 1
Broker: The Broker architectural pattern can be used to structure distributed
software systems with decoupled components that interact by remote
service invocations. A broker component is responsible for coordinating
communication, such as forwarding requests, as well as for transmitting
results and exceptions.

Source: Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented Software Architecture: A
System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996

Key: UML Class Diagram

Broker Pattern 2.

Key: UML Sequence Diagram

Broker Pattern Exercise 2.

Working in groups determine:
 What are the weaknesses of the broker pattern?
 How can tactics help?
 Create a new design that applies tactics to modify
the broker pattern.
 What are the side-effects of the tactics that you
have chosen?

Key: UML Sequence Diagram

More on Patterns and Tactics

For more information on architectural patterns, see
 Buschmann, F. Pattern-Oriented Software Architecture: A
System of Patterns, Volume 1. New York, NY: Wiley, 1996.
 Schmidt, D. Pattern-Oriented Software Architecture: Patterns for
Concurrent and Networked Objects, Volume 2. New York, NY:
Wiley, 2000.
 Kircher, F. Pattern-Oriented Software Architecture: Patterns for
Resource Management, Volume 3. New York, NY: Wiley, 2004.
 Buschmann, F. Pattern-Oriented Software Architecture: A
Pattern Language for Distributed Computing, Volume 4. New
York, NY: Wiley, 2007.
 Buschmann, F. Pattern Oriented Software Architecture: On
Patterns and Pattern Languages, Volume 5, New York, NY:
Wiley, 2007.
More on Patterns and Tactics

For more information on tactics, see:
 Bass, L.; Clements, P.; & Kazman, R. Software Architecture in
Practice, Second Edition. Boston, MA: Addison-Wesley, 2003.
 Bachmann, F., Bass, L., and Nord, R. Modifiability Tactics,
Software Engineering Institute Technical Report, Carnegie
Mellon University, CMU/SEI-2007-TR-002, 2007.
 Scott, J., and Kazman, R. Realizing and Refining Architectural
Tactics: Availability, Software Engineering Institute Technical
Report, Carnegie Mellon University, CMU/SEI-2009-TR-006,
2009.
Architecture Design: Examples
and Practice
Software Architecture Design Example
We will now use an example to illustrate the software
architecture design workflow.
Example: Web E-Commerce

System context: Internet

Technical environment: e-commerce reference
architecture

Initial pattern: canonical e-commerce three-tier
architecture

Browser/User Business Rules Data

Interaction and Applications Services

Key:
Component
Data Flow
Web E-Commerce Architectural Drivers
 Modifiability First Design Round

 Security Second Design Round

 High performance
 Scalability Third Design Round
 High availability
First Design Round: Problem to Solve
Modifiability: E-commerce Web sites change
frequently, in many cases daily, so their
content must be very simple to change.
First Design Round: Patterns and Tactics
The e-commerce pattern provides modifiability by
virtue of separation of responsibilities into distinct
tiers.
However, when later analyzing the architecture, it is
helpful to understand the underlying tactics.

Tactics
How Achieved

 Abstract common
services
 Semantic coherence
 Use an intermediary
 Maintain existing
interfaces
 Separation of browser
functionality,
database, and
business logic into
distinct tiers.
First Design Round: Design Decisions
The e-commerce pattern does not exempt the
architect from having to make other early
design decisions such as
 state management (which elements are stateful
and which are stateless).

This affects whether clients are thick or thin

the choice to use cookies, etc.
 First Design Round: Design Concept
Web
Browser Application Database
Server Server

Web
Browser

Web
Browser

Browser/User Business Rules and Applications Data

Interaction Services

Key: UML
Web E-Commerce Architectural Drivers
 Modifiability First Design Round

 Security Second Design Round

 High performance
 Scalability Third Design Round
 High availability
Second Design Round: Problem to Solve

Security. Users must be assured that any
sensitive information they send across the
Web is secure from snooping. Operators of
Web sites must be assured that their system
is secure from attack (stealing or modifying
data, rendering data unusable by flooding it
with requests, crashing it, etc.).
Second Design Round: Tactics

Tactics
How Achieved
 Limit access  Router/Firewall
 Maintain integrity  Encryption across public
 Limit exposure networks (HTTPS)
 Maintain data
confidentiality
 Second Design Round: Design Concept

Web
Browser Application Database
HTTPS Router/ Server Server
Firewall
Web
Browser

Web
Browser

Browser/User Business Rules and Applications Data

Interaction Services

Key: UML
Web E-Commerce Architectural Drivers
 Modifiability First Design Round

 Security Second Design Round

 High performance
 Scalability Third Design Round
 High availability
Third Design Round: Problem to Solve
High performance. A popular Web site will typically
have tens of millions of hits per day, and users
expect low latency from it. Customers will not
tolerate the site simply refusing their requests.
Scalability. As Web sites grow in popularity, their
processing capacity must be able to similarly grow,
to both expand the amount of data they can manage
and maintain acceptable levels of customer service.
High availability. E-commerce sites are expected to
be available 24/7. They never close, so must have
minimal downtime-perhaps a few minutes a year.
Third Design Round: Patterns and Tactics
To achieve high performance and availability in the e-
commerce architecture we need to make some
further architectural changes.

Tactics
How Achieved

 Introduce  Replicated servers
Concurrency  Load balancing
 Maintain Multiple  Proxy servers
Copies
 Increase Available
Resources
 Scheduling Policy
 Third Design Round: Design Concept
Database
Web Load Web
Server
Browser Balancer Server Application
Server

Web Router/ Web

Browser Firewall Server
:
: :
Application
Proxy Database
Web Web Server
Server Server
Browser Server

Browser/User Business Rules and Applications Data

Interaction Services

Key: UML
Exercise: Designing a Web-
conferencing System

Working in teams, you will be responsible for
the architecture of a web-conferencing
system.
Example - 1
Business goals for a new web-conferencing
system:
 A product-line of remote collaboration tools
 High security
 High reliability
 Extremely easy to use
 Support OEM/Integration into existing
products/tools/web-sites
 High performance
 Aimed at business customers
 Small footprint
Example - 2
Functional requirements:
 Screen sharing
 Voice-over-IP + SIP
 Text-based chat
 Whiteboarding
 One-click installation and removal: no admin
support required
 Scheduling of meetings/integration with calendars
 Moderation

Example 3.
Constraints:
 Must work on Windows XP, Vista, & System 7
 Must work on IE, Firefox, Chrome
 Must work over slow internet connections
 Must be ready for market in 12 months
 Total budget is 60 person-months of effort
Design Exercise

Working in your groups, determine:
 Your first (and hence most critical) design
decision for the web-conferencing system:

client-server or P2P?
 Document the rationale in terms of:

business goals

quality attribute scenarios
Reminder: SA Design Workflow
Identify problem to solve.
 Characterize the quality attribute.
 Determine importance and difficulty.
 Analyze existing architectural approaches.
Identify the solution options.
 Generate hypotheses patterns/tactics that might solve the
problem.
Make design decisions.
 Assess options Select patterns/tactics and apply them.
 Rework architecture.
Manage design decisions.
 Manage backlog of problems, solution options, etc.
 Ensure consistency as decisions change.
Design Exercise - Part 2

Create an additional scenario or two based
on the business goals for the web-
conferencing system.

Choose tactics to address these scenarios.

Document your decisions, assumptions, and
any anticipated side-effects of the tactics.

Document your design.
Validate Design Decisions

Design and analysis are two sides of the
same coin.

To validate a design, it must be analyzed.

That is the subject of the next part of the

course