Software Architecture in Practice

Carnegie Mellon University
Software Engineering Institute

Pittsburgh, PA 15213-3890
Software Architecture
in Practice
Paul C. Clements
This material is approved for public release. Distribution is limited by the
Pittsburgh,
PA 15213-3890
Software Engineering Institute to attendees.
Sponsored
theDepartment
U.S. Department
Sponsored by by
the U.S.
of Defense of Defense
2002 byby
Carnegie
Mellon University
2002
Carnegie
Mellon University
Version 1.5
page 1
The SEI: Who we are -1

The Software Engineering Institute (SEI) is
a federally funded research and development center
sponsored by the U. S. Department of Defense
hosted by Carnegie Mellon University in Pittsburgh
staffed by about 200 people
The SEIs core purpose is to help others make measured
improvements in their software engineering capabilities.
2002 by Carnegie Mellon University
Version 1.5
page 2
The SEI: Who we are - 2

First objective:
Accelerate the introduction and widespread use of highpayoff software engineering practices and technology
by identifying, evaluating, and maturing promising or
underused technology and practices.
We are a small organization. We have to pick these
practices carefully.
One we have chosen is
Software architecture
Version 1.5
page 3
The Ascendance of Software

Architecture
Over the past 10 years, software architecture has
emerged as the prominent paradigm in large-system
development.
There are:
worldwide conferences devoted to it
books devoted to it
defined architect roles in organizations
courses and training for it
Version 1.5
page 4
And yet...
It is still not well understood in some circles.
Some organizations have no architect position. Others
have the position but it is informally defined.
Some organizations are still proceeding to development
without an architecture in place.
The tools of the trade -- styles and patterns, views,
evaluation -- are used sparingly if at all.
Version 1.5
page 5
Todays talk
What is software architecture and why is it important?
A benefit of architecture: Software product lines
Evaluating software architectures
Documenting software architectures
Version 1.5
page 6
Todays talk
Version 1.5
page 7
What Is Software Architecture?

Software architecture is the structure or structures of
the system, which comprise software elements, the
externally visible properties of these elements, and
the relationships among them.
The exact structures to consider

and the ways to represent
them vary according to
engineering goals.
Version 1.5
page 8
Implications of this Definition 1

A software architecture is an abstraction of a system.
Architecture defines elements and how they interact.
Architecture suppresses purely local information about
elements; private details are not architectural.
Externally-visible properties of elements are assumptions
that one elements can make about another:
provided services, required services, performance
characteristics, fault handling, resource usage
Version 1.5
page 9

Every system has an architecture.
Every system is composed of elements and there are
relationships among them.
In the simplest case, a system is composed of a single
elements, related only to itself.
Just having an architecture is different from having an
architecture that is known to everyone:
The architecture versus specification of the architecture
If you dont explicitly develop an architecture, you will get one
anyway and you might not like what you get.
Version 1.5
page 10

This means that box-and-line drawings alone are not
architectures; but they are just a starting point.
You might imagine the behavior of a box labeled
database or executive -- but thats all
You need to add specifications and properties.
Systems have many structures (views).
No single structure can be the architecture.
The set of candidate structures is not fixed or
prescribed: choose whatever is useful for analysis,
communication, or understanding.
Version 1.5
page 11
Example of Multiple Views

Software Architecture for A-7E Corsair II Aircraft
U. S. carrier-based, light attack aircraft
Used from the 1960s through the 1980s
Small computer on board for navigation, weapons
delivery
Version 1.5
page 12
Extended
computer
module
Function
driver
module
Behavior-Hiding Module
Hardware-Hiding Module
Device
interface
module
Shared
services
module
Version 1.5
Software -Decision-Hiding Module
Module View (2 Levels)

Data banker
module
Physical
models module
Application
data types mod.
Filter
behavior module
Software
utilities module
System
generation mod.
page 13
Data Flow View

Pilot, external world
Device interfaces
values
to display
sensor inputs
Data banker
computed values
stored
values
calculated
real-world
values
Physical models
stored values
Shared services
sensor
values
computed values
Function drivers
Version 1.5
filtered
values
Filter behaviors
page 14
Layers View
Function drivers
Shared services
Data
banker
Physical
models
Filter
behaviors
Software
utilities
Device interfaces
Application data types
Extended computer
Version 1.5
page 15
Views -1
An architecture is a very complicated
construct -- too complicated to be seen all at once.
Views are a way to manage complexity.
1974: Parnas observed that software is composed of
many structures
1992: Perry and Wolf recognize that, similar to buildings
(with plumbing and electrical and wall diagrams), different
views of a system are required.
1995: Kruchten defined the 4+1 views approach to
software architecture.
2000: Hofmeister, Nord, and Soni defined the Siemens
Four Views approach to software.
Version 1.5
page 16
Views -2
A view is a representation
of a set of architectural
elements and the
relations associated
with them.
All information
Not all architectural

elements -- some of them.
Some information
A view binds element

types and relation types
of interest, and shows
those.
Version 1.5
page 17
Views -3
In box-and-line diagrams,
a way of asking what
the boxes and lines mean is:
What element types and relation types
are you showing?
In other words,
What view are you showing?
Which view shows the architecture?
None of them.
All of them.
Version 1.5
page 18
Architecture As Communication
Vehicle
Architecture provides a common frame of reference in
which competing interests may be exposed and
negotiated.
negotiating requirements with users and other
stakeholders
keeping the customer informed of progress and cost
implementing management decisions and allocations
Version 1.5
page 19
Architecture Constrains
Implementation
An architecture defines constraints on an implementation.
Architectures are descriptive and prescriptive
- descriptive for communication
- prescriptive for design and implementation
Global resource allocation decisions constrain
implementations of individual components
System tradeoffs regarding quality attributes are in the
architectural realm.
Version 1.5
page 20
Architecture Organizes the

Development Project
The architecture influences the organizational structure for
development/maintenance efforts. Examples include
division into teams
units for budgeting, planning
basis of work breakdown structure
organization of documentation
organization of CM libraries
basis of integration
basis of test plans, testing
basis of maintenance
Incremental deployment
Version 1.5
page 21
Architecture Permits/Precludes
Achievement of Quality Attributes
For example
If you desire
performance
modifiability
security
scalability
ability to subset
reusability
Examine
inter-component communication
component responsibilities
inter-component communication,
specialized components (e. g., kernels)
localization of resources
inter-component usage
inter-component coupling
Version 1.5
page 22
Architecture is Key to Managing

Change
An architecture helps reason about and manage change.
important since 80% of effort in systems occurs after
deployment
Architecture divides all changes into three classes:
local: modifying a single component
non-local: modifying several components
architectural: modifying the gross system topology,
communication, and coordination mechanisms
A good architecture is one in which the most likely changes
are also the easiest to make.
Version 1.5
page 23
Architecture is Basis for

Incremental Development
An architecture helps with evolutionary prototyping and
incremental delivery.
Architecture serves as a skeletal framework into which
components can be plugged.
By segregating functionality into appropriate
components, experimentation is easier.
Risky elements of the system can be identified via the
architecture and mitigated with targeted prototypes.
Version 1.5
page 24
Architecture is a Reusable Model

An architecture is an abstraction: enables a one-to-many
mapping (one architecture, many systems).
Systems can be built from large, externally developed
components that are tied together via architecture.
Architecture is the basis for product (system)
commonality.
Entire software product lines can share a single
architecture.
Version 1.5
page 25
Todays talk
Version 1.5
page 26
What is a Software Product Line?
A software product line is a set of software-intensive

systems sharing a common, managed set of features
that satisfy the specific needs of a particular market
segment or mission and that are developed from a
common set of core assets in a prescribed way.
Version 1.5
page 27
Software Product Lines

pertain to
Market strategy/
Application domain
is satisfied by
share an
Architecture
Products
used to structure
are built from
Components
CORE
ASSETS
Product lines
take economic advantage of commonality

bound variability
Version 1.5
page 28
How Do Product Lines Help?

Product lines amortize the investment in these
and other core assets:
requirements and requirements analysis
domain model
software architecture and design
performance engineering
documentation
earlier lifecycle
reuse
test plans, test cases, and data

people: their knowledge and skills
processes, methods, and tools
more
benefit
budgets, schedules, and work plans

components
Version 1.5
page 29
The Key Concepts

Use of a
common
asset base
in
production
Version 1.5
of a related
set of
products
page 30
Economics of Product Lines

Current
Practice
With Product Line Approach
Cumulative
Cost
Number of Products
Derived from data supplied by

Lucent Technologies
Bell Laboratories Innovations
Version 1.5
page 31
Example: Cummins, Inc.

Worlds largest
manufacturer of
large diesel engines
(over 200 hp)
25,000 employees
350 controls and
electronics engineers
$7B annual sales
Version 1.5
page 32
Complex Domain Of Variation

Todays diesel engines are driven by software.
Micro-control of ignition timing to achieve optimum mix
of power, economy, emissions.
Conditions change dynamically as function of road
incline, temperature, load, etc.
Must also respond to statutory regulations that often
change.
Reliability is critical! Multi-million dollar fleets can be
put out of commission by a single bug.
130KSLOC -- C, assembler, microcode.
Different sensors, platforms, requirements.
Version 1.5
page 33
Changing the Way to Do Business

In 1994, with six engine projects under way and 12 more
planned, Cummins
realized that it could not continue to do business the old
way
realized hiring to fill the need was out of the question
launched a software product line
built a core asset base from the most successful of its
projects
turned the other projects into product development
projects using the core assets
Version 1.5
page 34
Cummins Results
In early 1995, the first product was launched on time
(relative to re-vamped schedule) with high quality. Others
followed -- on time and with high quality.
Cummins achieved a product family capability with a

breathtaking capacity for variation, or customization
9 basic engine types
4-18 cylinders
3.9 - 164 liter displacement
12 kinds of electronic control modules
5 kinds of microprocessors
10 kinds of fuel systems
diesel fuel or natural gas
Version 1.5
page 35
Quantitative Results - 1
20 product groups launched, which account for over
1000 separate engine applications
75% of all software, on average, comes from core assets
Product cycle time has plummeted. Time to first engine
start went from 250 person-months to a few personmonths. One prototype was built over a weekend.
Software quality is at an all-time high, which Cummins
attributes to product line approach.
Version 1.5
page 36
Customer satisfaction is high. Productivity gains
enable new features to be developed (more than 200
to date).
Projects are more successful. Before product line
approach, 3 of 10 were on track, 4 were failing, and 3
were on the edge. Now, 15 of 15 are on track.
Widespread feeling that developers are more
portable, and hence more valuable.
Version 1.5
page 37
Supported
Components
Electronic control
modules (ECMs)
1992 1993 1994 1995 1996 1997 1998

3
11
12
Fuel Systems
10
11
Engines
12
16
17
Features * ECM
60
80
180
370
1100 2200 2400
Achieving this flexibility without the product line approach

would have required 3.6 times the current staff.
Version 1.5
page 38
Todays largest teams are smaller than yesterdays
smallest teams. Two-person teams are not unusual.
Cummins management has a history of embracing
change, but carefully targeted change.
They estimate that process improvement alone has
brought a benefit/cost ratio of 2:1 to 3:1.
They estimate that the product line approach has
brought a benefit/cost ratio of 10:1.
Product line approach let them quickly enter and then
dominate the industrial diesel engine market.
Version 1.5
page 39
Lessons Learned
Cummins story echoes product line success
themes seen on other successful efforts, namely
a compelling business case
deep domain expertise
a rich legacy base
a dedicated champion
organizational cohesion
courage to try new engineering approaches
Version 1.5
page 40
Examples of Product Line Practice - 1

CelsiusTech - large shipboard command/control systems
hardware-to-software cost ratio switched from 35:65 to 80:20
staff decreased from over 200 to about 40
Motorola - FLEXworks Project (family of one-way pagers)
4x cycle time improvement
80% reuse
Hewlett Packard - printer systems
2-7x cycle time improvement
Sample Project
shipped 5x number of products
that were 4x as complex
and had 3x the number of features
with 4x products shipped/person
Version 1.5
page 41
Examples of Product Line Practice - 2

Nokia - mobile phones
went from 4 different phones produced per year to 25-30 per
year
58 languages, multiple platforms, wide range of features
National Reconnaissance Offices Control Channel Toolkit ground-based satellite systems
first product using core assets requiring 1/10 the
normal number of developers
Market Maker - website stock market software
each product uniquely configured for customer
three days to put up a customized system
Version 1.5
page 42
Todays talk
Version 1.5
page 43
Architecture Evaluation
A software architecture is the earliest life-cycle artifact that
embodies significant design decisions. Analyzing for system
qualities early in the life cycle allows for a comparison of
architectural options.
With the advent of cost-effective, repeatable architecture
evaluation methods, architecture evaluation should be a
standard part of every architecture-based development
methodology.
Version 1.5
page 44
When and Why To Evaluate an

Architecture
When building a system
Evaluation should be done when deciding on
architecture.
When acquiring a system
Architectural evaluation is useful if the system will
have a long lifetime within organization.
Evaluation provides a mechanism for understanding
how the system will evolve.
Evaluation can also provide insight into other visual
qualities.
Version 1.5
page 45
Forces Preparation for Review

Documentation/specifications must be provided, hence
they must exist or be created.
Some evaluations use standard questions, and the
architect can prepare ahead to ensure that the
architecture scores well.
Evaluations make the criteria for evaluation explicit by
prioritizing requirements or quality goals.
Version 1.5
page 46
Early Detection of Problems

The problems that can be found by an architecture
evaluation include
unreasonable requirements
performance problems
problems associated with potential future modifications
The earlier in the life cycle that problems are found, the
easier it is to fix them.
Version 1.5
page 47
Validation of Requirements
Evaluations put stakeholders in the same room with each
other, often for the first time.
uncovers conflicts and tradeoffs
provides a forum for negotiated resolution of problems
It often results in the generation of new requirements or
the clarification of existing requirements.
Version 1.5
page 48
Improved Architectures
Development organizations anticipate types of questions
raised at evaluations and
design architectures with questions in mind
prepare documentation of the type needed at
evaluation
give explicit consideration to qualities to be evaluated
Version 1.5
page 49
The ATAMSM
The SEI has developed the Architecture
Tradeoff Analysis MethodSM (ATAMSM).
The purpose of ATAMSM is: to assess the
consequences of architectural decisions
in light of quality attribute requirements and
business goals.
Version 1.5
page 50
ATAMSM Steps
1. Present the ATAMSM
2. Present business drivers
3. Present architectural views
4. Identify architectural approaches
Phase 1:
Evaluation team,
key decision-makers
5. Generate quality attribute utility tree

6. Analyze architectural approaches
7. Brainstorm and prioritize scenarios
8. Analyze architectural approaches
9. Present results
Version 1.5
Phase 2:
Evaluation team,
stakeholders
page 51
Conceptual Flow of ATAMSM

Business
Drivers
Quality
Attributes
Scenarios
Analysis
Software
Architecture
Architectural
Approaches
Architectural
Decisions
Tradeoffs
impacts
Sensitivity Points
Risk Themes
distilled
into
Version 1.5
Non-Risks
Risks
page 52
Todays talk
Version 1.5
page 53
Documenting an architecture
Architecture serves as the blueprint for the system, and the
project that develops it.
It defines the work assignments.
It is the primary carrier of quality attributes.
It is the best artifact for early analysis.
It is the key to post-deployment maintenance and mining.
Documenting the architecture is the crowning step to
creating it.
Documentation speaks for the architect, today and 20 years
from today.
Version 1.5
page 54
Views and Beyond approach to

documentation
Views give us our first principle of architecture
documentation:
Document the relevant views,
and then add information
that applies to more than one view.
Version 1.5
page 55
Which views are relevant? -1

Kruchtens 4+1 views
Logical view: supports behavioral requirements. Key
abstractions, which are objects or object classes
Process view: addresses concurrency and distribution.
Maps threads to objects.
Development view: organization of software modules,
libraries, subsystems, units of development.
Physical view: maps other elements onto processing
and communication nodes.
Plus one view: Maps the other views onto important
use cases to show how they work.
Version 1.5
page 56

Siemens Four-Views (Hofmeister, Nord,
Soni, Applied Software Architecture, 2000):
Conceptual view
Module interconnection view
Execution view
Code view
Herzum & Sims (Business Component Factory, 1999):
Technical architecture
Application architecture
Project management architecture
Functional architecture
Version 1.5
page 57

Software Cost Reduction method
(Parnas, et al., 1980s)
Module view: shows modules as units of
encapsulation; used to isolate changes and achieve
modifiability
Process view: shows processes and how they
synchronize and communicate at run-time; used to
achieve performance
Uses view: shows programs and how they depend on
each other; used to achieve incremental development
and the ability to quickly field subsets
Version 1.5
page 58

Which views are relevant? It depends on:
who the stakeholders are
how they will use the documentation.
Three primary uses for architecture documentation:
Education -- introducing people to the project
Communication -- among stakeholders
Analysis -- assuring quality attributes
Version 1.5
page 59
What views are available? -1

Plenty! Too many!
Already, weve seen 15 different views,
and many more are available, based
on examining the literature.
An architect needs a way to choose
the useful ones.
One thing that would help is to organize
the views into broad categories.
Version 1.5
page 60

An architect must consider the system in three ways:
How is it structured as a set of code units?
How is it structured as a set of elements that have runtime behavior and interactions?
How does it relate to non-software structures in its

environment?
Version 1.5
page 61

This suggests looking for three kinds of views that help:
How is it structured as a set of code units?
Module views (module viewtype)
How is it structured as a set of elements that have runtime behavior and interactions?
Component-and-connector views (C&C viewtype)
How does it relate to non-software structures in its
environment?
Allocation views (allocation viewtype)
Version 1.5
page 62
How many views do we need in

our documentation package?
Each view comes with
a cost.
Each view comes with
a benefit.
Planning a view set
requires understanding
the needs of the
stakeholders, and
the resources available.
Version 1.5
page 63
How to proceed?
1. Build a table.
ROWS: Enumerate the stakeholders
COLUMNS: Enumerate the set of styles that could apply
to the architecture being documented. This is our potential
set of views.
Check box (x,y) if stakeholder x would like view y.
2. Combine views appropriately to reduce number.
3. Prioritize views based on need. (Some stakeholders may
have extra weight.)
Version 1.5
page 64
Documenting a view -1
1. A primary presentation
Usually graphical (we call this a cartoon)
May be textual -- e.g., a table
If graphical, includes a key explaining the notation (or
pointing to explanation)
Shows elements and relationships among them
Shows information you wish to convey about the view
(view packet) first
Many times, the primary presentation is all you get. Its
not enough!
Version 1.5
page 65
2. An element catalog
Explains the elements depicted in the primary
presentation
Lists elements and their properties (as defined by the
relevant style guide)
Explains relations, and any exceptions or additions to
the relations shown in the primary presentatio
Interfaces of elements
3. A context diagram
Shows how system (or portion shown in this view
packet) relates to its environment.
Version 1.5
page 66
4. A variability guide
Shows the architectural mechanisms available to
change the element
5. Architecture background
Rationale for design decisions that apply to the entire
view (or to that portion of the view being shown),
including rejected alternatives and factors that
constrained the design
Analysis results validating the design decisions
Assumptions about the environment and about the
need that the system is fulfilling
Version 1.5
page 67
6. Other information
System- and project-specific.
CM information, ownership information
Mapping to requirements
Not architectural, strictly speaking. But useful to
capture alongside the architecture anyway.
7. Related view packets
Pointers to sibling, child, and parent view packets
Version 1.5
page 68
Documentation beyond views - 1

1. Documentation roadmap
How the documentation is organized to serve a
stakeholder
List of views, with the elements/relations of each, and a
statement of what the view is for
Scenarios for using the documentation, showing which
parts should be consulted
2. View template
Explanation of how each view is documented
The standard organization for each view
Version 1.5
page 69
Documentation beyond views -2

3. System overview
An informal, prose description of the system and its
purpose and functionality
Goal is to provide context for new member
Perfectly OK to point to overview elsewhere if one
exists in overall system documentation
4. Mapping between views
Establishes useful/insightful correspondence between
various views
Tabular
Version 1.5
page 70
Documentation beyond views -3

5. Directory
An index showing where every element, relation, and
property is defined and used.
6. Architecture glossary and acronym list
May be subset of overall system glossary and acronym
list. OK to point to larger document if so.
7. Background, design constraints, and rationale
As in views, but applied to cross-view design decisions.
Version 1.5
page 71
Source of material - 1
General overview
Software product lines
1998 (second edition 2003)
2001
Version 1.5
page 72
Source of material - 2
Architecture evaluation
Architecture documentation
2001
2002
Version 1.5
page 73
For more information

SEIs software architecture work:
www.sei.cmu.edu/architecture
SEIs software product line work:
www.sei.cmu.edu/plp/plp_init
Contact information:
Paul Clements
Pittsburgh, PA 15213
clements@sei.cmu.edu
Version 1.5
page 74

Software Architecture in Practice

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Software Architecture in Practice

Загружено:

Авторское право:

Доступные форматы

Carnegie Mellon University

Software Engineering Institute

The SEI: Who we are -1

2002 by Carnegie Mellon University

The SEI: Who we are - 2

The Ascendance of Software

2002 by Carnegie Mellon University

2002 by Carnegie Mellon University

2002 by Carnegie Mellon University

2002 by Carnegie Mellon University

What Is Software Architecture?

The exact structures to consider

2002 by Carnegie Mellon University

Implications of this Definition 1

2002 by Carnegie Mellon University

Implications of this Definition 2

Implications of this Definition 3

Example of Multiple Views

2002 by Carnegie Mellon University

2002 by Carnegie Mellon University

Software -Decision-Hiding Module

Module View (2 Levels)

Data Flow View

2002 by Carnegie Mellon University

2002 by Carnegie Mellon University

Not all architectural

A view binds element

2002 by Carnegie Mellon University

2002 by Carnegie Mellon University

Architecture Organizes the

2002 by Carnegie Mellon University

Architecture is Key to Managing

2002 by Carnegie Mellon University

Architecture is Basis for

2002 by Carnegie Mellon University

Architecture is a Reusable Model

2002 by Carnegie Mellon University

2002 by Carnegie Mellon University

What is a Software Product Line?

A software product line is a set of software-intensive

2002 by Carnegie Mellon University

Software Product Lines

take economic advantage of commonality

How Do Product Lines Help?

test plans, test cases, and data

processes, methods, and tools

budgets, schedules, and work plans

The Key Concepts

2002 by Carnegie Mellon University

Economics of Product Lines

With Product Line Approach

Derived from data supplied by

Example: Cummins, Inc.

Complex Domain Of Variation

2002 by Carnegie Mellon University

Changing the Way to Do Business

2002 by Carnegie Mellon University

Cummins achieved a product family capability with a

2002 by Carnegie Mellon University

1992 1993 1994 1995 1996 1997 1998

1100 2200 2400

Achieving this flexibility without the product line approach

2002 by Carnegie Mellon University