Software Architecture in Practice

Part One:
Envisioning Architecture

2nd Ed.
Len Bass, Paul Clements, Rick Kazman
Ch 1: The Architecture Business Cycle

For decades, software designers have been taught to

build systems based exclusively on the technical
requirements.
Software architecture encompasses the structures of
large software systems:
abstract view
eliminates details of implementation, algorithm, & data
representation
concentrates on the behavior & interaction of black box
elements
 Definition

The software architecture of a program or

computing system is the structure or
structures of the system, which comprise
software elements, the externally visible
properties of those elements, and the
relationships among them.
 Architecture Business Cycle (ABC)

Quick Exercise :
What is the relationship of a systems software
architecture to the environment in which the system
will be constructed and exist?
 Architecture Business Cycle (ABC)

Answer:
Software architecture is a result of technical, business,
and social influences.
In turn, it affects each of these environments.
 Where do Architectures Come From?

The result of a set of business and technical

decisions.
In any development effort, the requirements make
explicit some - but only some - of the desired
properties of the final system.
Failure to satisfy non-documented constraints can
cause as many problems as if it functioned poorly.
Figure 1.2 Influence of
stakeholders on the architect
 Architectural Influences
Stakeholders
each stakeholder has different concerns & goals, some contradictory
Development Organization
immediate business, long-term business, and organizational (staff
skills, schedule, & budget)
Background & Experience of the Architects
repeat good results, avoid duplicating disasters
The Technical Environment
standard industry practices or common SE techniques
 Ramifications of Influences
Almost never are the properties required by the
business & organizational goals consciously
understood, let alone fully articulated.
Architects need to know & understand the nature,
source, and priority of constraints on the project as
early as possible.
Architects must identify & actively engage the
stakeholders to solicit their needs & expectations.
Use architecture reviews & iterative prototyping.
 Books Main Message

Architectures affect the factors that

influence them.
The relationships among business goals,
product requirements, architects experience,
architectures, and fielded systems form a cycle
with feedback loops that a business can
manage:
to handle growth, to expand enterprise area, and to
take advantage of previous investments in
architecture & system building.
 Software Processes & the ABC

What activities are involved in creating a

software architecture, using that
architecture to realize a design, and then
implementing or managing the evolution of
a target system or application?
 Quick Exercise

How do you
Design one?
Build one?
Modify one?
 Architectural Activities
Creating the Business Case for the System
Understanding the Requirements
Creating or Selecting the Architecture
Communicating the Architecture
Analyzing or Evaluating the Architecture
Implementing Based on the Architecture
Ensuring Conformance to an Architecture
What makes a Good Architecture?
No such thing as an inherently good or bad
architecture.
Architectures are more or less fit for some stated
purpose.
Architectures can be evaluated - one of the great
benefits of paying attention to them - but only in
the context of specific goals.
Rules of Thumb: process & product (structural)
recommendations
 Rules of Thumb (pp 15 & 16)

Process Recommendations:
include functional requirements and a prioritized list of quality
attributes the system must satisfy
analyze & formally evaluate before it is too late to change
Product Recommendations:
well-defined modules using principles of information hiding &
separation of concerns
separate modules that produce data from those that consume data to
increase modifiability & staged upgrades
write tasks or processes to allow easy reallocation, perhaps at
runtime
 Ch 2: What is Software Architecture?

Quite often shown as box-and-arrow diagrams.

Control
Process
(CP)

Prop Loss Reverb Noise

Model Model Model
(MODP) (MODR) (MODN)

Figure 2.1
 Whats Missing?
What is the nature of the elements?
What are the responsibilities of the elements?
What is the significance of the connections?
What is the significance of the layout?

Unless we know precisely what the elements are &

how they cooperate to accomplish the purpose of
the system, this diagram is unhelpful!
 Definition Again
The software architecture of a program or
computing system is the structure or structures of
the system, which comprise software elements, the
externally visible properties of those elements, an
the relationships between them.

We see the elements (CP, MODP, MODR,

MODN), but what properties do they or their
relationships have?
 Externally Visible Properties

The assumptions that other elements can make of

an element, such as:
its provided services,
performance characteristics,
fault handling,
shared resource usage,
etc.
 Definition Implications
1 - architecture defines software elements.
2 - systems can and do comprise more than one
structure, all are part of the architecture.
3 - every computing system with software has an
architecture.
4 - the behavior of each element is part of the
architecture as far as its behavior can be observed or
discerned from the point of view of another element.
5 - the definition doesnt judge goodness or badness.
 Useful Concepts
Three stages that capture characteristics of an
architecture, on the way from box-and-arrow to full
software architectures:
Architectural Patterns
Reference Models
Reference Architectures

Reference Model
Reference Software
Architecture Architecture
Architectural
Pattern
Figure 2.2
 Architectural Patterns

A description of element & relation types together

with a set of constraints on how they may be used.
These constraints on an architecture define a set or
family of architectures.
For example, the client-server pattern has 2 element
types (?); their relationship is a protocol that the server
uses to communicate with each of its clients, the clients
dont communicate directly. Functionality is excluded.
 Value of Patterns
They exhibit known quality attributes, and are a
reuse of experience.
Some patterns solve performance problems, others
apply to high-security systems, or high-
availability goals.
Often the architects first major design decision.
Also referred to as architectural styles.
 Reference Models

A division of functionality together with data flow

between the pieces.
A standard decomposition of a known problem
into parts that cooperatively solve the problem.
They arise from experience, and are thus a
characteristic of mature domains.
For example, the standard parts of a compiler or
database management system & how they work
together.
 Reference Architectures

A reference model mapped onto software elements

and the data flows between them. The elements
must cooperatively implement the functionality
defined in the reference model.
The mapping may be 1-1, but an element may
implement a part of a function or several
functions.
 Why is Architecture Important?
Three fundamental reasons from a technical
perspective:
Communication among stakeholders
a basis for mutual understanding, negotiation, & consensus
Early design decisions
earliest point at which decisions can be analyzed
Transferable abstraction of a system
can promote large-scale reuse
 Early design decisions

The architecture:
defines constraints on implementation
dictates organizational structure
inhibits or enables a systems quality attributes
some details on next slide, more on p. 30
studying it can predict system qualities
easier to reason about and manage change
helps in evolutionary prototyping
enables more accurate cost & schedule estimates

High performance
Scalability
Deliver incremental subsets
Re-usable elements
Quality Attributes
Manage the time-based behavior
of elements; the frequency &
volume of inter-element
communication
Carefully localize the use of
resources to facilitate the
introduction of high-capacity
replacements
Carefully manage inter-
component usage
Restrict inter-element couplings
so an extraction doesnt have too
many environment attachments
to be useful
Architecture: a Transferable, Reusable Model

The earlier in the lifecycle re-use is applied, the

greater the benefit.
Software Product Lines share a common architecture.
Composing with large, externally developed elements.
Restrict the vocabulary of design alternatives: patterns.
Architecture permits template-based development.
Used as the basis for training.
 Structures and Views
A view is a representation of a coherent set of
architectural elements, consisting of:
a set of elements
the relationships among them
A structure is the set of elements itself, as they
exist in software or hardware.
Often used interchangeably, text will distinguish.
 Groups of Architectural Structures

Module structures
units of implementation with assigned areas of
functionality - usually static
Component-and-connector structures
runtime components (principal units of computation)
and connectors (communication vehicles)
Allocation structures
show relationships between software elements &
external environments (creation or execution)
 Three Types of Structures
Correspond to the three broad types of decisions
that architectural design involves:
How is the system to be structured as a set of code units
(modules?)
How is the system to be structured as a set of elements
that have runtime behavior (components) and
interactions (connectors)?
How is the system to relate to non-software structures in
its environment (i.e., CPUs, file systems, networks,
development teams, etc. - allocation)?
Figure 2-3
 Non-functional Properties
Each structure provides a method for reasoning
about some of the relevant quality attributes, for
example:
the uses structure, must be engineered to build a system
that can be easily extended or contracted
the process structure is engineered to eliminate
deadlock and reduce bottlenecks
the module decomposition structure is engineered to
produce modifiable systems, etc.
 Value of Structures
Each structure provides the architect with a
different view into the system & a different
leverage point for design.
Table 2.1 on page 39-40 should be useful in your
class project...
 Relating Structures to Each Other

Although the structures give different system

perspectives, they are not independent.
Elements of one structure are related to elements
in another, and we need to reason about these
relationships.
For example, a module in a decomposition structure
may map to one, part of one, or several, components in
a component-and-connector structure at runtime.
In general, mappings are many-many.
 Choosing Structures
Kruchtens Four + One Views:
Logical - elements are key abstractions that are objects or
classes in OO. This is a module view.
Process - addresses concurrency & distribution of
functionality. This is a C&C view.
Development - shows organization of software modules,
libraries, subsystems, and units of development. This is an
allocation view.
Physical - maps other elements onto processing &
communication nodes, also an allocation view, but usually
referred to specifically as the deployment view.
 Quick Exercise
Please read Architecture Deja Vu on pages 43-
45.
What do you think? Do you agree or disagree?
Why?
 Ch 3: A-7E Avionics System

Architecture is focused on three structures:

Decomposition into modules
Uses how the modules relate
Process components and connectors
 Decomposition

Information hiding:
Also foundation to OO design,
Except information hiding modules are derived
by identifying expected changes over the
systems lifecycle
A module may have submodules
 Specific goals

Simple enough to understand fully

Change one module without knowing or
impacting others
Most likely changes should be easiest
Possible to make major changes as a set of
independent changes to individual modules
If the interfaces are not changed, any
combination of old and new should run
 A-7E Module Decomposition Structure

Architects observed that, in similar systems,

changes tend to come from three areas:
Hardware
Required externally visible behavior
Decisions controlled by the developer
 Uses Structure

Runtime execution information the

authoritative picture of how the software
interacts
Uses relation:
Procedure A is said to use procedure B if a
correctly functioning procedure B must be
present in order for A to meet its requirements.
 Uses Relation

Allows rapid identification of functional

subsets
The uses (allowed-to-use) structure is
documented in a table see Table 3.4 for an
example
 Process Structure

Implemented as a set of cooperating

sequential processes that synchronize with
each other to cooperatively use shared
resources
Pre-runtime scheduling produced a single
executable thread
 Processes

A set of programming steps that are

repeated in response to a triggering event or
to a timing constraint
It has its own thread of control, and can
suspend by waiting for an event
 A-7E Processes

Written for two main purposes

1. For the functional drivers to compute the
output values of the avionics software
2. Less frequently, they can implement
expensive access procedures continuously
compute in the background, returning the
most recent value when called
See their conceptual structures on pp 63-64
 Processes
Contains the synchronizes-with relation
Based on events that one process signals and one
or more processes await
Used as the primary input to the scheduling
activity, which includes deadlock avoidance
Process structure has two types of information:
What procedures are included in each process,
identifying threads and re-entrant requirements
Which processes cannot execute simultaneously
 Exercise

Write-up and hand-in a short

summary of you so your professor
can get to know you better: Name,
company, job/role/title, any
architecting experience?
What are two important objectives
you have for this class.