Software Architecture

Introduction to the Design Process

 Session Outline
In this module we’ll look at the design
activity itself
• We’ll look at attribute driven design
• We’ll walk through an example of applying
such a design approach
Later we’ll look at how this design activity
fits into the larger design process

© Matthew Bass 2018 2

 The Architectural Design
Activity
We’ll first look at the architectural design
activity itself
• Inputs
• Core concepts for the design
• Outputs

© Matthew Bass 2018 3

 Architectural Design à
Inputs/Outputs
• Inputs – architectural drivers
• technical and business constraints
• high level functional requirements
• quality attribute requirements
• Outputs
• architectural decomposition: elements, responsibilities,
relations, and interfaces
• initial documentation including
• representations of the software architecture from the 3 primary
perspectives
• data, rationale, descriptive prose, and so forth

© Matthew Bass 2018 4

 Functional Requirements and
Constraints
• High level functional requirements are those
functional requirements with architectural impact
• “Shall” descriptions of system behavior
• Use cases describing system operation
• Constraints include
• Technical constraints, which are requirements where the
design decisions are pre-specified.
• Business or programmatic constraints, which are non-
technical in nature but have deep indirect impact upon the
architectural design.

© Matthew Bass 2018 5

 Quality Attributes
• Quality attribute requirements are often derived from
abstract specifications
• “Be competitive in the low-cost market.”
• “The system must be secure.”
• “The system must be modifiable.”
• Quality Attribute Workshop is a good technique for
getting initial quality attribute scenarios but
• are usually only good starting positions – they will often lack
the details necessary to support design
• will need further refinement involving preliminary design,
prototyping, and/or dialog with stakeholders

© Matthew Bass 2018 6

 Attribute-Driven Design
• The Attribute-Driven Design (ADD) method,
developed by the SEI, is an approach to defining a
software architecture that bases the decomposition
process on the quality attributes the software must
fill.

• ADD follows a recursive decomposition process

where, at each stage in the decomposition, tactics
and architectural patterns are chosen to satisfy a set
of quality attribute scenarios.

© Matthew Bass 2018 7

 Steps of the ADD Method
1. Choose the module to decompose.
2. Refine the module according to these steps:
a. Choose architectural drivers.
b. Choose an architectural pattern that satisfies the architectural
drivers.
c. Instantiate modules and allocate functionality from the use cases
using multiple views.
d. Define the interfaces of the child modules.
e. Verify and refine the use cases and quality attribute scenarios, and
make them constraints for the child modules.
3. Repeat Steps 1-2e for the next module.

© Matthew Bass 2018 8

 Example
• Travel companies really came into
being in the 1950’s
• It was difficult for novice travelers to
arrange all aspects of travel
• This company was the first to establish
the “complete vacation package”
• This became their competitive advantage

© Matthew Bass 2018 9

 Complete Vacation Package
• This company would handle all aspects
of your trip including:
• Hotel
• Flight
• Transfers
• Visas
• …

© Matthew Bass 2018 10

 The Travel Business
• Things have changed significantly over the
years
• It used to be the case that it was difficult and
time consuming to schedule travel
• Airlines, hotels, cruises, and so forth used
travel agents as a primary sales channel
• They would thus give significant discounts to
these travel companies

© Matthew Bass 2018 11

 Times Have Changed
• The advent of the internet changed
everything, however
• It’s now very easy for people to find
flights, hotels, ect
• In order to be competitive companies offer
discounts directly to the consumer
• As a result travel agents are no longer the
primary sales channel
© Matthew Bass 2018 12
 Differentiator
• The consumer is primarily shopping on
price these days
• Very little brand loyalty
• Having the “complete vacation package”
is no longer sufficient

© Matthew Bass 2018 13

 Price Advantage
• A successful Travel Agent has to compete on
price
• They are no longer the primary sales channel
for the travel providers
• They rely on two advantages to get the lowest
price
• More comprehensive search
• Collective bargaining (smaller margin today)

© Matthew Bass 2018 14

 System Goals
• A travel agency typically has several sales
channels
• Web
• Call center
• Agent (in their stores)
• They need to be able to support consumer
and corporate business
• They had many heterogeneous systems that
needed to be integrated
© Matthew Bass 2018 15
 System Goals II
• Integration with travel partners including
• Hotel
• Airlines
• Travel aggregators
• Reduce maintenance costs
• The partners are changing all the time
• High availability 24 X 7

© Matthew Bass 2018 16

 Setting Context
1. Choose the module to decompose.
2. Refine the module according to these steps:
a. Choose architectural drivers.
b. Choose an architectural pattern that satisfies the architectural
drivers.
c. Instantiate modules and allocate functionality from the use cases
using multiple views.
d. Define the interfaces of the child modules.
e. Verify and refine the use cases and quality attribute scenarios, and
make them constraints for the child modules.
3. Repeat Steps 1-2e for the next module.

© Matthew Bass 2018 17

 Decomposition – 1
• The system context sets the stage for subsequent
decomposition of the system.
• If the system context is inaccurate, incomplete, or
never precisely established, the subsequent
decomposition and resulting implementation may
suffer
• ill defined responsibilities between organizations
• undefined inputs/outputs
• integration difficulties (compounded in distributed
development)
• mismatched expectations
© Matthew Bass 2018 18
 Decomposition – 2
• Historically, decomposition has been driven by
functionality.
• However, as we discussed, the structure of a system
generally has little to do with pure functionality and
more with the satisfaction of
• constraints: Constraints become “load-bearing walls” in the
design space. We can only satisfy or negotiate to relax them.
• quality attributes: Quality attribute requirements are often
intertwined with functionality, but satisfying the quality
attribute response measure usually comes down to
structure.

© Matthew Bass 2018 19

 System Context

Travel
External Travel System Back Office Systems
Partners

Mainframe Customer Management System

© Matthew Bass 2018 20

 Choose the Architectural
Drivers
1. Choose the module to decompose.
2. Refine the module according to these steps:
a. Choose architectural drivers.
b. Choose an architectural pattern that satisfies the architectural
drivers.
c. Instantiate modules and allocate functionality from the use cases
using multiple views.
d. Define the interfaces of the child modules.
e. Verify and refine the use cases and quality attribute scenarios, and
make them constraints for the child modules.
3. Repeat Steps 1-2e for the next module.

© Matthew Bass 2018 21

 Key Quality Attribute Concerns I

In this case one major concern is the

scalability/performance concerns
• Needs to be able to support millions of
transactions a day
• Need to be able to manage peak loads
without degrading latency

© Matthew Bass 2018 22

 Key Quality Attribute Concern II
Another concern is the ability to add and
change applications at runtime
• Travel partners change all the time
• The travel agent doesn’t have direct
control over the travel partners
applications

© Matthew Bass 2018 23

 Key Quality Attribute Concern III

Availability of the application is important

• The system needs to be available even
if key travel partners are offline
• There is an international customer base
that may need to access the system
24/7

© Matthew Bass 2018 24

 Key Quality Attribute Concern IV

The overall user experience is important

for retaining customers
• Certainly response time is a factor
• But we also need to worry about
correctness
• If a flight is given at a particular price but
then can’t be purchased it will be annoying

© Matthew Bass 2018 25

 Selecting the Initial Scenarios
• Ultimately you’ll need to consider all of
the scenarios
• You may want to first consider one then
consider the impact on others
• Perhaps the most important
• Or the most difficult

© Matthew Bass 2018 26

 Select Pattern/Tactic
1. Choose the module to decompose.
2. Refine the module according to these steps:
a. Choose architectural drivers.
b. Choose an architectural pattern that satisfies the architectural
drivers.
c. Instantiate modules and allocate functionality from the use cases
using multiple views.
d. Define the interfaces of the child modules.
e. Verify and refine the use cases and quality attribute scenarios, and
make them constraints for the child modules.
3. Repeat Steps 1-2e for the next module.

© Matthew Bass 2018 27

 Select A Starting Element – 1
• Select initial perspective as decompose – remember it as
you decompose; switch perspectives as a conscience act!
• Select an overall architectural pattern that satisfies the key
architectural drivers.
• Some problems may suggest a particular pattern.
• Patterns are starting points and need to be refined.
• While systems may exhibit an overall pattern, real systems are
composed of ensembles of patterns.
• A single pattern cannot maximize all the required architectural
drivers – tradeoffs will be made.
• This highlights the importance of prioritizing architectural drivers.

© Matthew Bass 2018 28

 Select A Starting Element – 2
• If a starting pattern isn't obvious, decomposition starts
with “the system.”
• Use the all architectural drivers to guide decomposition.
• Begin with constraints, then QAs, and finally functionality.
• The system decomposed into “elements” that are consistent with
the perspective

Constraints Design Structures

Forces
Quality attributes Architecture
: Design
High level functionality
Architect

© Matthew Bass 2018 29

 Example
• We will start by looking at the integration
problem
• We have a number of systems with
different interfaces, different data
models, and that are outside of our
control
• A natural starting place is to consider
using web services
© Matthew Bass 2018 30
 Travel System

Travel System

ESB

Services
Adapters

Air Partners Hotel Partners Car Partners Mainframe CRM

© Matthew Bass 2018 31

 Implications
• Dynamic binding
• Much easier to make changes without impacting the
system
• Change interfaces
• Can handle disparate systems and data models
• Lots of overhead
• XML transformations
• XML validation
• SOAP messages
• …

© Matthew Bass 2018 32

 Performance
• As we look at this candidate option with
respect to performance we see issues
• Each end user query translates into 10s of
queries and > 1MB data
• There is no way that this solution will provide
the response time required
• We need to apply some tactics to see if we
can improve performance

© Matthew Bass 2018 33

 Caching Data
• Caching data is one strategy for
improving performance
• If we don’t have to fetch and aggregate
data with each request we avoid most of
the overhead
• We can then reduce the latency of each
request to an acceptable level

© Matthew Bass 2018 34

 Issues With Cache
• When we have multiple copies of data we
need to worry about synchronization
• What happens if the data changes at the
source e.g.
• Number of seats available
• Price
• Schedule
• …

© Matthew Bass 2018 35

 Rule Based Cache
• It turns out the volatility of the data
varies
• Some data is quite stable e.g. airport
codes
• There is variation among the more volatile
data (e.g. flights to Las Vegas vs Hawaii)
• We can thus define a rule based cache
to align the timeout with the volatility
© Matthew Bass 2018 36
 And So On …
• Note that decomposition is (and should be) guided in
part by intuition and experience
• A knowledge of structures is helpful and will often temper
instinctive, reactionary decisions.
• While we start with a pattern, “pure” patterns don’t
often exist in practice
• Patterns can and will need to be adjusted to meet the
needs of the system
• We need to take care to do this in a reasoned and structured
way, however

*(BCK03 chapter 5)
© Matthew Bass 2018 37
Guidance For Initial Decomposition – 1
• The goals of initial decomposition are to decide upon
the gross partitioning of the system into elements and
proceed to refine the elements through further
decomposition.
• After the initial decomposition, element
decomposition proceeds iteratively
• assign responsibilities derived from the architectural drivers
to the elements as appropriate
• refine elements by selecting subordinate patterns and/or
further decompose elements as necessary
• applying refining tactics as appropriate
• develop and define the interfaces of subordinate elements

© Matthew Bass 2018 38

Guidance For Initial Decomposition – 2

• As you decompose the system

• Be consistent of perspective and with the elements and
relations of the perspective.
• It is helpful to create the legend first.
• Order of decomposition/refinement will vary.
• Need for special expertise – specific skills to be fully utilized
argues for depth first decomposition.
• Knowledge of domain – no major unknowns argues for
breadth first decomposition.
• New technology – requirement for prototypes argues for
depth first decomposition.

© Matthew Bass 2018 39

 Instantiate Modules
1. Choose the module to decompose.
2. Refine the module according to these steps:
a. Choose architectural drivers.
b. Choose an architectural pattern that satisfies the architectural
drivers.
c. Instantiate modules and allocate functionality from the use cases
using multiple views.
d. Define the interfaces of the child modules.
e. Verify and refine the use cases and quality attribute scenarios, and
make them constraints for the child modules.
3. Repeat Steps 1-2e for the next module.

© Matthew Bass 2018 40

 Assigning Responsibilities
• Responsibilities are derived from the architectural drivers.
• functional requirements: use cases, textual descriptions
• quality attribute scenarios
• technical and business constraints
• Functional responsibilities and technical constraints are
usually assigned to specific elements for satisfaction.
• Quality attribute and some business constraints are often
satisfied by the very partitioning of the system.

© Matthew Bass 2018 41

 Travel System

Travel System

Applications

Shared
Packaging Rule
Business
System Engine
Services

Adapter Layer

© Matthew Bass 2018 42

 Assignment of Responsibilities
• We have begun to partition
responsibilities
• The partitioning is motivated by the
quality attribute requirements
• Notice we haven’t answered all of the
questions … yet
• We will need to continue to refine the
requirements and design
© Matthew Bass 2018 43
 Refining The Elements – 1
• After initial decomposition and assignment of
responsibilities, recursively decompose and
refine each element of the system.
• assign responsibilities to elements from the
architectural drivers
• complement architectural patterns or the initial
decomposition with tactics
• refine the subordinate elements
• define interfaces of subordinate elements

© Matthew Bass 2018 44

 Refining The Elements – 2
• Further decomposition of elements, may necessitate
further refinement of use cases, quality attribute
scenarios, and constraints.
• For example, a use case that initializes the whole system
might need to be broken down into use cases that
initialize the subsystems under a variety of conditions.
• Further refinement and decomposition of the elements will
impact the satisfaction of responsibilities.
• may involve individual subordinate elements
• may involve coordination of subordinate elements

© Matthew Bass 2018 45

 Refining The Elements – 3
• Responsibilities of a "parent" element can be satisfied
in one of the following ways
• If the responsibility is satisfied by the element with no further
decomposition then nothing more needs to be done.
• If the element is further decomposed, then any assigned
responsibilities are delegated to subordinate elements.
• Satisfying the responsibility then involves the cooperation of
multiple subordinate elements and becomes a distributed
responsibility among the each of the involved subordinate
elements.

© Matthew Bass 2018 46

Select Tactics To Refine Elements – 1

• Tactics refine patterns and can help balance the

negative effects of a pattern.
• Two main factors guide the selection of tactics:
• the architectural drivers (quality attributes in particular)
• the side effects of a pattern that implements the tactic has on
the architectural drivers
• The application of tactics is refinement of the initial
architectural design decisions.
• Think of element refinement as a kind of dialogue.

© Matthew Bass 2018 47

 Select Tactics To Refine Elements – 2
• Think of refinement as a kind of dialogue that proceeds
as follows:
• Requirement: build an online stock trading system
• Initial pattern: concurrent processing units
• Pattern promotes: scalability…
• Pattern Inhibits: availability …
• Tactic: introduce replication …
• Tactic promotes: availability
• Tactic inhibits: performance, more complex
... and so on..

© Matthew Bass 2018 48

Select Tactics To Refine Elements – 3
• The “goodness” of the patterns and tactics selected in the
previous example depends on the relative importance of
performance and modifiability.
• Again, this illustrates the notion of design tradeoffs and the
importance of prioritizing architectural drivers.
• Architects must constantly balance the array of patterns
and tactics that is the architectural design to achieve the
desired properties in the system – these are engineering
tradeoffs.

© Matthew Bass 2018 49

 Define the Interfaces
1. Choose the module to decompose.
2. Refine the module according to these steps:
a. Choose architectural drivers.
b. Choose an architectural pattern that satisfies the architectural
drivers.
c. Instantiate modules and allocate functionality from the use cases
using multiple views.
d. Define the interfaces of the child modules.
e. Verify and refine the use cases and quality attribute scenarios, and
make them constraints for the child modules.
3. Repeat Steps 1-2e for the next module.

© Matthew Bass 2018 50

 Define Interfaces – 1
• Now we turn our attention from the elements to the
relationships between them.
• The interface for each element must be defined.
• Interfaces consist of
• the services and the properties that a design element
requires and produces
• identified during the allocation of responsibilities
• the data and control flow information needed by each
element as defined

© Matthew Bass 2018 51

 Define Interfaces – 2
• Interfaces need not be as detailed as a signature.
• If not, then you have deferred binding the interface to
downstream designers
• Its OK, but the first task of downstream designers must be to define
the interfaces, and then they must be placed under strict
configuration control.
• Use cases and scenarios can be exercised to get a better
understanding of the interfaces
• interactions
• dependencies
• information that components share and exchange

© Matthew Bass 2018 52

 Document – 1
• Provide project background.
• Document architecture drivers and their relative
priority.
• Create the initial architecture representation(s).
• consider perspective and be consistent
• establish system/software context
• if graphical, include a key that explains the notation
• Document responsibilities of elements and the
relationships between them.

© Matthew Bass 2018 53

 Document – 2
• Document rationale and key design decisions
• element responsibilities
• choices made as well as rejected alternatives
• include assumptions
• Provide analysis/prototype results supporting the design
decisions made.
• For each element document responsibilities and interfaces
as you assign them (and/or change assignments).
• Try to get into the habit of carrying an engineering
notebook with you.

© Matthew Bass 2018 54

 Document – 3
• Document as you architect
• Faithfully capturing information (especially design rationale)
as you design the architecture requires extraordinary
discipline.
• If you wait to document your architecture
• you will forget
• a bigger documentation chore will be waiting for you later
• it will take longer to document the architecture
• the document you produce, won't be as good
• Experience shows that the effort more than pays for itself.

© Matthew Bass 2018 55

 Verify and Refine
1. Choose the module to decompose.
2. Refine the module according to these steps:
a. Choose architectural drivers.
b. Choose an architectural pattern that satisfies the architectural
drivers.
c. Instantiate modules and allocate functionality from the use cases
using multiple views.
d. Define the interfaces of the child modules.
e. Verify and refine the use cases and quality attribute scenarios, and
make them constraints for the child modules.
3. Repeat Steps 1-2e for the next module.

© Matthew Bass 2018 56

 Evaluate – 1
• Use functional use case scenarios to “test” the
architecture to ensure that it meets the key high level
functional requirements.
• Use quality attribute scenarios and use cases to “test” the
architecture to ensure it meets key quality attribute
requirements.
• Ensure that all of the requirements have been satisfied in
one way or another

© Matthew Bass 2018 57

 Repeat
1. Choose the module to decompose.
2. Refine the module according to these steps:
a. Choose architectural drivers.
b. Choose an architectural pattern that satisfies the architectural
drivers.
c. Instantiate modules and allocate functionality from the use cases
using multiple views.
d. Define the interfaces of the child modules.
e. Verify and refine the use cases and quality attribute scenarios, and
make them constraints for the child modules.
3. Repeat Steps 1-2e for the next module.

© Matthew Bass 2018 58

 Repeat – 1
• What do we have so far?
• collection of elements and relationships
• assigned responsibilities
• interfaces
• documentation
• Continue to decompose, refine, evaluate, and
document.
• When do you stop?

© Matthew Bass 2018 59

 Repeat – 2
• In general, you are done architecting when downstream
designers are sufficiently constrained.
• Elements and relations are defined and documented.
• Responsibilities for satisfying architectural drivers are assigned to
elements.
• Element interfaces are defined (per our earlier discussion).
• The architecture documentation is reasonable complete; it is
prescriptive and descriptive.
• The architecture has been evaluated.

© Matthew Bass 2018 60

 Repeat – 3
• Precisely when you stop will depend. Factors include
• scope and complexity will influence duration
• ensuring the design sufficiently documented
• ensuring the down-stream designers and/or implementers
sufficiently constrained
• Many other factors could influence when the
architecture design is done, but the biggest factor
may be the architect's intuition.
• The goal of this course is to better equip you to make these
kinds of judgmental decisions.

© Matthew Bass 2018 61

 It Never Ends Really…
• Architecture design should be a continuous activity throughout a
product’s lifecycle.
• After deployment, the architecture plays a significant role in
managing and predicting the cost and impact of change.
Architecture divides change into:
• local change: changes restricted to the internals of an element
• non-local change: changes that ripple outside of the boundaries of
an element
• architectural change: changes that erode the fundamental structure
of the system
• Without a current architecture this kind of analysis is impossible.

© Matthew Bass 2018 62

 Summary
• First and foremost, this is not a “how to architect” lecture
but rather general guidance to apply when faced with a
design problem.
• Key points we introduced and discussed
• how to think about decomposition
• how to use architectural drivers
• how to refine the design
• how to use perspective to aid in analysis
• what to write down and when

© Matthew Bass 2018 63

 References
• Bass, L.; Clements, P. & Kazman, R. Software Architecture in Practice,
Second Edition. Boston, MA: Addison-Wesley, 2003.
• Lattanze, Anthony Architecting Software Intensive Systems Boca
Raton, FL: Auerbach, 2009

© Matthew Bass 2018 64