Carnegie Mellon University
Software Engineering Institute
The Role of Architecture
in Understanding Software
Rick Kazman
Hausi Müller
Jeromy Carrière
Carnegie Mellon University
Software Engineering Institute
Software Architecture:
What is it and How to Represent It
Rick Kazman
kazman@sei.cmu.edu
www.sei.cmu.edu/staff/rkazman
Carnegie Mellon University
Software Engineering Institute
A Software Architecture (?)
Control
process
(CP)
Prop loss
model
(MODP)
Reverb
model
(MODR)
Noise
model
(MODN)
Carnegie Mellon University
Software Engineering Institute
What is Wrong with this Diagram?
Many things are left unspecified:
 What
kind of components?
 What kind of connectors?
 What do the boxes and arrows mean?
 What is the significance of the layout?
 Why is control process on a higher level?
 Box and arrow drawings alone are not
architectures; rather, they are a starting point.
Carnegie Mellon University
Software Engineering Institute
What’s Wrong with the Diagram?
Which structure? Software is composed of many
structures.
 modules
 tasks
 functions
 hardware
 classes
Thus, when seeing boxes and lines, we must ask
 What
do the boxes represent?
 What do the arrows mean?
Carnegie Mellon University
Software Engineering Institute
What is Software Architecture?
The software architecture of a program or
computing system is the structure or
structures of the system, which comprise
software components, the externally visible
properties of those components, and the
relationships among them.
Carnegie Mellon University
Software Engineering Institute
Implications of this Definition
Architecture is an abstraction of systems.
 Architecture
defines components and how they
interact.
 Architecture suppresses purely local information;
private component details are not architectural.
Systems have many structures (views).
 No
single view can be the architecture.
 The set of candidate views is not fixed or prescribed:
whatever is useful for analysis or communication.
Carnegie Mellon University
Software Engineering Institute
More Implications
Every system has an architecture.
 Every
system is composed of components and
relationships among them.
 In the simplest case, a system is composed of a
single component, related only to itself.
Having an architecture is different from having
an architecture that is known. Issues:
 precise
specification of the architecture
 architecture recovery and conformance
 rationale for the architecture
Carnegie Mellon University
Software Engineering Institute
Why Is Architecture Important?
Architecture is important for (at least) three
reasons.
 It
provides a vehicle for communication among
stakeholders.
 It is the manifestation of the earliest design
decisions about a system.
 It is a transferable, reusable abstraction of a
system.
Carnegie Mellon University
Software Engineering Institute
Communication Vehicle
Architecture provides a common frame of
reference in which competing interests may be
exposed and negotiated.
 negotiating
requirements with users
 keeping the customer informed of progress and cost
 implementing management decisions and
allocations
Carnegie Mellon University
Software Engineering Institute
Result of Early Design Decisions -1
An architecture constrains an implementation.
 implementations
must conform to architecture
 (global) resource allocation decisions constrain
implementations of individual components
 system tradeoffs are manifested in the architecture
Carnegie Mellon University
Software Engineering Institute
Result of Early Design Decisions -2
The architecture dictates organizational structure
for development/maintenance efforts, e.g.
 division into teams
 units for budgeting, planning
 basis of work breakdown structure
 organization for documentation
 organization for CM libraries
 basis of integration, test plans, testing
 basis of maintenance
 Once committed to, an architecture is
extremely hard to change!
Carnegie Mellon University
Software Engineering Institute
Result of Early Design Decisions-3.
Architecture permits/precludes the achievement
of a system’s desired quality attributes
(modifiability, performance, security, etc.).
The architecture influences qualities, but does not
guarantee them.
An architecture helps with evolutionary
prototyping.
 Architecture
serves as a skeletal framework into
which components can be plugged.
 By segregating functionality into appropriate
components, experimentation is easier.
Carnegie Mellon University
Software Engineering Institute
Reusable Model
An architecture forms a reusable model. It:
 provides
a vocabulary of design
 enables template-based component development
 enables product lines
 enables systems to be built from externally
developed components
 separates functionality from packaging and
interconnection mechanisms
Carnegie Mellon University
Software Engineering Institute
Architectural Structures - 1
In a house, there are plans for rooms, electrical
wiring, plumbing, ventilation, . . .
Each of these constitutes a “view” of the house.
These views are
 used
by different people
 used to achieve different qualities in the house
 used as a description and prescription
So it is with software architecture.
Carnegie Mellon University
Software Engineering Institute
Architectural Structures - 2.
Functional
Development
Scenarios
Concurrency
Physical
 Similar to Kruchten’s 4+1 View Model
Code
Carnegie Mellon University
Software Engineering Institute
Functional View
Components:
 functions,
elements
key system abstractions, domain
Connectors:
 dependencies,
data flow
Users:
 domain
engineers, product-line designers, end users
Reasoning:
 functionality,
modifiability, product
lines/reusability, tool support, work allocation
Carnegie Mellon University
Software Engineering Institute
Functional View Example
Dialogue
Virtual Toolkit
Presentation
Virtual Application
Application
Carnegie Mellon University
Software Engineering Institute
Code View
Components:
 classes, objects, procedures, functions
 subsystems, layers, modules
Connectors:
 calls, invokes
 is-a-sub-module-of
Users:
 programmers,
designers, reusers
Reasoning:
 modifiability/maintainability,
subsetability
portability,
Carnegie Mellon University
Software Engineering Institute
Code View Example
WindowKit
CreateScrollBar()
CreateWindow()
MotifWindowKit
CreateScrollBar()
CreateWindow()
OpenLookWindowKit
CreateScrollBar()
CreateWindow()
return
new OpenLookWindow
return
new MotifWindow
Carnegie Mellon University
Software Engineering Institute
Development View
Components:
 files,
directories
Connectors:
 contains
Users:
 managers,
programmers, configuration managers
Reasoning:
 modifiability/maintainability
 testing
 configuration management/version
control
Carnegie Mellon University
Software Engineering Institute
Development View Example
ALE3D
advect
AdvectHist.c
AdvectVars.c
...
chem
ArheniusReaction.c
ArheniusReaction.h
ArheniusReactionType.h
...
generator
BuildObjects.c
BuildObjects.h
BuildSlide.c
...
implicitHydro
CreateMatrix.cc
FormMatrix.cc
ImpSlide.c
...
io
BCInput.c
Chem_Input.c
Chem_Input.h
material
Alum_Matmodel.c
Alum_Matmodel.h
CT_ReactiveFlow.c
...
object
AngleWall.c
AngleWall.h
Boundary.c
...
parallel
Comm.h
CommDeplete.c
CommElements.c
...
slide
InitSlide.c
InitSlide.h
Prepass.c
...
thermal
HeatGeneration.c
HeatGeneration.h
Carnegie Mellon University
Software Engineering Institute
Concurrency View
Components:

processes, threads
Connectors:
 synchronization,
data flow, events
Users:
 performance
engineers, integrators, testers
Reasoning:
 performance,
availability
Carnegie Mellon University
Software Engineering Institute
Concurrency View Example
Operational unit
Client
SAS
Standby
data mgt.
PAS
Standby
data mgt.
SAS
service
request
response
service
request
Operational unit
Server
PAS
Standby
data mgt.
SAS
SAS
Carnegie Mellon University
Software Engineering Institute
Physical View
Components:

CPUs, sensors, storage
Connectors:
 networks,
communication devices
Users:
 hardware
engineers, system engineers
Reasoning:
 system
delivery and installation, performance,
availability, scalability, security
Carnegie Mellon University
Software Engineering Institute
Physical View Example
LCN Backbone Ring and Bridges to Access Rings
Host
interface
HCS A
HCS B
Dual
LIU-Hs
Dual
LIU-Hs
Multiple
Common
Console
Access Rings
Test and
Training
Subsystem
3 LIU-Cs
Central
Processor
3 LIU-Cs
Common
Consoles
(up to
210)
3 LIU-Cs
Central
Processor
Host
systems
3 LIU-Cs
Dual ESIs
EDARC
Systems external
to ISSS
ESIP
(one per
ESI)
BCN
Dual
BCN
M&C
Consoles
Dual
LCN
M&C
Consoles
Carnegie Mellon University
Software Engineering Institute
Scenarios
What are scenarios?
 use
cases: sequences of responsibilities
 change cases: changes to the system
Why use scenarios?
 to
understand and validate the design
 to communicate the design
 to tie the views together
 to animate the design
 to understand the limits of the design
Carnegie Mellon University
Software Engineering Institute
What Are Views Used For?
Each view provides an engineering handle on
certain quality attributes.
Views are an engineering tool to help achieve
desired system qualities.
In some systems, distinct views collapse into one.
(E.g., the concurrency and physical views may
be the same for small systems.)
Carnegie Mellon University
Software Engineering Institute
What Are Views Used For?
Documentation vehicle for
 current development and
 managers and customers
future development
Thus, views must be annotated to support
analysis.
Scenarios aid in annotating views with design
rationale.
Carnegie Mellon University
Software Engineering Institute
Hierarchical Views
Every view is potentially hierarchical, e.g.:
 functional:
functions contain sub-functions
 development: directories contain files
 code: modules contain sub-modules; systems
contain sub-systems
 concurrency: processes contain threads
 physical: clusters contain computers contain
processors
Because views are complex and hierarchical, they
need to be navigable.
Carnegie Mellon University
Software Engineering Institute
View Navigability - 1
A skilled software engineer with some domain
knowledge should be able to read the
documentation and navigate through it.
There should be an obvious starting point,
portraying the system as a collection of
interconnected subsystems.
Subsystems should be named, with their
responsibilities, functionality, and
interconnections identified.
Carnegie Mellon University
Software Engineering Institute
View Navigability - 2.
Pointers should direct the reader to more detailed
documentation of sub-structures.
Tool support can and should aid in navigation.
At every stage, the nature of the connections
among the parts should be clearly identified.
Carnegie Mellon University
Software Engineering Institute
Architectural Representation
Summary
Architectural views are related to each other in
complicated ways.
Lesson: Choose the views that are useful to the
system being built and to the achievement of
qualities that are important to you.
The architectural views should be hierarchical
(where needed) and navigable.
The views should contain enough annotated
information to support desired analyses.
Carnegie Mellon University
Software Engineering Institute
Part II
Software Architecture
Patterns and AntiPatterns
Hausi A. Müller
Carnegie Mellon University
Software Engineering Institute
Outline
• Architecture Patterns
 Motivation
 Software
patterns
 Pattern formats
 Shaw’s architecture patterns
 Qualities of a pattern
• Architecture AntiPatterns
Carnegie Mellon University
Software Engineering Institute
Motivation
 Vehicle
for reasoning about design or
architecture at a higher level of abstraction
 gain
design confidence
 Mining
design patterns in legacy systems
 identify
 Software
product lines
architecture
 dissemination
 Engineering
 contain
of good design, design reuse
Handbooks
a wealth of experience
Carnegie Mellon University
Software Engineering Institute
Software Patterns
 Programming
patterns or idioms [Coplien95]
 Programming
 Design
language specific
patterns [GoF95]
 Class
and object level
 Creational, structural, behavioral
 Architectural
 Subsystem
 Pattern
 All
patterns [Shaw95]
level
languages [Coplien95, Vlissides96]
levels
 Reflective
patterns [Buschmann95]
 Metaprogramming
Carnegie Mellon University
Software Engineering Institute
Software Patterns ...
 Analysis
patterns [Fowler97]
 AntiPatterns [Brown98]
 Frameworks
 STL (C++ Template Library)
 Algorithms and data structures
 Conceptual patterns
 Generative patterns
 Organizational patterns
Carnegie Mellon University
Software Engineering Institute
Pattern Definitions
 A pattern
is a named nugget of insight that conveys
the essence of a proven solution to a recurring
problem within a certain context amidst competing
concerns
 A pattern is the abstraction from a concrete form
which keeps recurring in specific non-arbitrary
contexts.
Carnegie Mellon University
Software Engineering Institute
Pattern Definitions ...
 Description
of communicating objects and classes
that are customized to solve a general design in a
particular context [GoF95].
 Design patterns capture the static and dynamic
structures of solutions that occur repeatedly when
producing applications in a particular context
[Coplien95].
Carnegie Mellon University
Software Engineering Institute
Historical Perspective
1979
 Alexander’s
Timeless Way of Building
1987
 OOPSLA workshop
by Beck & Ward
1994
 First
PLoP (Pattern Languages on Programming)
conference
1995
 GoF
(Gamma, Helm, Johnson, Vlissides)
 Design Patterns; Elements of Reusable ObjectOriented Software
Carnegie Mellon University
Software Engineering Institute
A Good Pattern
It solves a problem
 Patterns
capture solutions, not just abstract
principles or strategies
It is a proven concept
 Patterns
capture solutions with a track record, not
theories or speculation
The solution isn’t obvious
 The
best patterns generate a solution indirectly;
normal for many design problems
Carnegie Mellon University
Software Engineering Institute
A Good Pattern ...
It describes a relationship
 Patterns
describe more than black boxes: system
structures and mechanisms
The pattern has a significant human component
 The
best patterns explicitly appeal to aesthetics
and utility
Carnegie Mellon University
Software Engineering Institute
Pattern Formats
 Alexandrian
form (canonical form)
 GoF format [GoF95]
 Shaw’s format [Shaw94]
 Essential components of a pattern format
 Name,
problem, context, forces
 Solution, examples, context,
 Rationale, related patterns, known uses
Carnegie Mellon University
Software Engineering Institute
Canonical Pattern Format ...
Name
 meaningful
phrase
Problem
a
statement of the problem which describes its
intent: the goals and objectives it wants to reach
within the given context and forces
Carnegie Mellon University
Software Engineering Institute
Canonical Pattern Format ...
Context
 preconditions
under which the problem and its
solutions seem to occur
 the pattern’s applicability
 may change over time
Forces
 relevant
forces and constraints and their
interactions and conflicts
 motivational scenario for the pattern
Carnegie Mellon University
Software Engineering Institute
Canonical Pattern Format ...
Solution
 Static
and dynamic relationships describing how
to realize the pattern
 instructions on how to construct the work
products
 pictures, diagrams, prose which highlight the
pattern’s structure, participants, and
collaborations
Carnegie Mellon University
Software Engineering Institute
Canonical Pattern Format ...
Examples
 one
or more sample applications to illustrate
a
specific context
 how the pattern is applied
Resulting context
 the
state or configuration after the pattern has
been applied
 consequences (good and bad) of applying the
pattern
Carnegie Mellon University
Software Engineering Institute
Canonical Pattern Format ...
Rationale
 justification
of the steps or rules in the pattern
 how and why it resolves the forces to achieve the
desired goals, principles, and philosophies
 how are the forces orchestrated to achieve
harmony
 how does the pattern actually work
Carnegie Mellon University
Software Engineering Institute
Canonical Pattern Format ...
Related patterns
 the
static and dynamic relationships between this
pattern and other patterns
Known uses
 to
demonstrate that this is a proven solution to a
recurring problem
Carnegie Mellon University
Software Engineering Institute
Shaw’s Architecture Pattern Format
Problem
 What
in the application requirements leads the
designers to select this pattern?
Context
 What
aspects of the setting constrain the designer
in the use of this pattern?
Solution
 The
system model captured by the pattern,
together with the components, connectors, and
control structure that make up the pattern.
Carnegie Mellon University
Software Engineering Institute
Shaw’s Format ...
Diagram
 A figure
showing a typical pattern, annotated to
show the components and connectors
Significant variants
 For
some patterns, major variants of the basic
pattern are noted.
Examples
 References
to examples or more extensive
overviews of systems that apply this pattern.
Carnegie Mellon University
Software Engineering Institute
Shaw’s Architecture Patterns
Pipeline
 Defined
series of independent computations
 Mapping data streams into data streams
Data abstraction
 Protection
of related bodies of information
 Localized state maintenance (info hiding)
Communicating processes
 Collection
of distinct, independent processes
 Message passing
 Simple messages, broadcast
Carnegie Mellon University
Software Engineering Institute
Shaw’s Architecture Patterns ...
Implicit invocation
 Loosely
coupled collection of components
 Independent reactive processes
 Without knowing the recipients (registered procs)
Repository
 Maintaining
a complex body of information
 Centralized data, richly structured
 Blackboard
Interpreter
 Extensibility,
end-user programming, portability
 Virtual machine (e.g., Java)
Carnegie Mellon University
Software Engineering Institute
Shaw’s Architecture Patterns ...
Main program and subroutines
 Hierarchy
of procedure definitions
 Forward call tree
 Modularity
Layered architecture
 Distinct
layers of services
 Hierarchy of transparent or opaque layers
Carnegie Mellon University
Software Engineering Institute
Qualities of a Pattern
Encapsulation and abstraction
 encapsulates
a well-defined and its solution in a
particular domain
 provides crisp, clear boundaries to crystallize the
problem and solution spaces
 serves as an abstraction which embodies domain
knowledge and experience
 may occur at different levels of abstraction
Carnegie Mellon University
Software Engineering Institute
Qualities of a Pattern ...
Openness and variability
 is
open for extension and parameterization by
other patterns
 is able to solve larger problems in concert with
other patterns
 can be realized by a variety of implementations
(variants)
Carnegie Mellon University
Software Engineering Institute
Qualities of a Pattern ...
Generativity and composability
 applying
a pattern once provides a context for
further applications
 patterns are easier to apply in another context
than C++ code
 can evolve into Golden Hammer AntiPattern
Carnegie Mellon University
Software Engineering Institute
Qualities of a Pattern ...
Equilibrium
 realizes
a balance among its forces and
constraints
 realizes an invariant, heuristics, or a policy which
minimize conflict within the solution space
 an invariant characterizes the problem solving
philosophy
Carnegie Mellon University
Software Engineering Institute
Outline
• Patterns
• AntiPatterns
 Motivation
 Pattern
and AntiPattern relation
 AntiPattern and program comprehension
 AntiPattern format
 Selected software Architecture AntiPatterns
 Summary
Carnegie Mellon University
Software Engineering Institute
Reference
 Brown,
Malveau, McCormick III, Mowbray
AntiPatterns: Refactoring Software, Architectures,
and Projects in Crisis
John Wiley & Sons, 1998
Carnegie Mellon University
Software Engineering Institute
Origins of AntiPatterns
 The
majority of published works in software
sciences have focused on positive and constructive
solutions
 AntiPatterns are derived by looking at the negative
solutions
 Def. An AntiPattern describes a commonly
occurring solution to a problem that generates
decidedly negative consequences.
Carnegie Mellon University
Software Engineering Institute
Origins of AntiPatterns
A manager or developer
 does
not know any better
 does not have sufficient knowledge or experience
solving a particular problem
 applied a perfectly good design pattern in the
wrong context
Carnegie Mellon University
Software Engineering Institute
Essence of an AntiPattern
 Two
solutions instead of a problem and a solution
 Problematic
solution which generates negative
consequences
 Refactored solution, a method to resolve and reengineer
the AntiPattern
 A pattern
in an inappropriate context
Carnegie Mellon University
Software Engineering Institute
Pattern & AntiPattern Relation
 Design
patterns often evolve into an AntiPattern
 Procedural programming was a great design pattern
in the 60’s and 70’s
 Today it is an AntiPattern
 Object-oriented programming is today a practiced
pattern ...
Carnegie Mellon University
Software Engineering Institute
Pattern & AntiPattern Relation
Context & Causes
Problem
Context & Forces
Solution
Benefits
Related
Consequences Solutions
[AP99]
AntiPattern
Solution
Symptoms
Consequences
Refactored
Solution
Benefits
Consequences Related
Solutions
Carnegie Mellon University
Software Engineering Institute
AntiPatterns & Comprehension
 AntiPatterns
are particularly prevalent during longterm software maintenance and evolution
 A software reengineer needs to assess the presence
or absence of AntiPatterns in a legacy system to be
able to implement the best reengineering strategy
Carnegie Mellon University
Software Engineering Institute
AntiPatterns and Reengineering ...
Premise
 Recognition
of AntiPatterns will make you a better
software engineer
 Refactoring AntiPatterns present in a legacy
system’s project will result in a better, more
successful, less risky software reengineering
project
Carnegie Mellon University
Software Engineering Institute
State of Affairs
 Five
out of six software projects are considered
unsuccessful
 One third of all software projects are canceled
 For delivered systems the actual budget and time is
double than expected
 Silver bullets ...
Carnegie Mellon University
Software Engineering Institute
Old Silver Bullets
 Structured
programming
 Top-down design
 Open systems
 Client/server architectures
 Quality code generation from models
 Object orientation
 GUI builders
 Frameworks
Carnegie Mellon University
Software Engineering Institute
New Silver Bullets
 Component
technologies
 Distributed objects
 Business objects
 Patterns
 Software reuse
 Scripting languages
 Software agents
 Network-centric computing
 Web interface
Carnegie Mellon University
Software Engineering Institute
AntiPattern Structure
 Description
of the general form
 Symptoms on how to recognize the general form
 Causes that led to the general form
 Consequences of the general form
 Refactored solution on how to change the
AntiPattern into a healthier situation
Carnegie Mellon University
Software Engineering Institute
AntiPatterns
 A method
for efficiently mapping a general,
problematic situation to a specific class of solutions
 Provide real-world experience in recognizing
recurring problems in the software industry and
provide a detailed remedy for the most common
predicaments
 Provide a common vocabulary
for identifying problems and
discussing solutions
Carnegie Mellon University
Software Engineering Institute
AntiPattern Categories
 Development AntiPatterns
 Situations
encountered by programmers
 Architectural AntiPatterns
 Common
problems in system structure
 Managerial AntiPatterns
 Affect
people in all software roles
 AntiPatterns
apply to software construction as well
as software evolution
Carnegie Mellon University
Software Engineering Institute
AntiPattern Format
Root causes
 provide
fundamental context for the AntiPattern
Primal forces
 are
the key motivators for decision making
Software design-level model
 define
architectural scales; each pattern has a most
applicable scale
Carnegie Mellon University
Software Engineering Institute
Root Causes
Haste
 hasty
decisions compromise quality
 code that appears to work is acceptable
 testing is ignored
Apathy
 lack
of partitioning
 ignoring the separation of concerns (e.g., stable vs.
replaceable design)
Carnegie Mellon University
Software Engineering Institute
Root Causes ...
Narrow-mindedness
 refusal
of known or accepted solutions
 reluctance to use metadata
Sloth
 poor
decision based on an easy answer
 frequent interface changes
 lack of configuration control
 reliance on generating stubs and skeletons
Carnegie Mellon University
Software Engineering Institute
Root Causes ...
Avarice
 architectural
avarice—modeling of excessive
details
 excessive complexity due to insufficient abstraction
 overly complex systems are difficult to develop,
integrate, test, maintain, extend
Carnegie Mellon University
Software Engineering Institute
Root Causes ...
Ignorance
 failing
to seek understanding
 antonym of analysis paralysis
 focussing on code interfaces rather than system
interfaces
 no layering
 no wrapping to isolate details
Carnegie Mellon University
Software Engineering Institute
Root Causes ...
Pride
 not-invented-here
syndrome
 unnecessary invention of new designs
 reinventing the wheel
 rewrite from scratch
 ignoring requirements
 ignoring COTS, freeware, existing legacy system
Carnegie Mellon University
Software Engineering Institute
Forces
 Forces
or concerns that exist within a decisionmaking process
 Forces that are addressed lead to benefits
 Forces that remain unresolved lead to consequences
 For any given software problem there are a number
of forces that can influence a given solution
Carnegie Mellon University
Software Engineering Institute
Forces ...
Vertical forces
 Domain
specific
 Unique to a particular situation
 Ignored in AntiPatterns
Horizontal forces
 Applicable
across multiple domains
 Influence design and reengineering choice across
several software modules and components
 Choices made elsewhere may impact local choices
Carnegie Mellon University
Software Engineering Institute
Primal Forces ...
 Horizontal
forces are called primal forces
 Present in nearly all design or reengineering
situations
 Keep architecture and development on track or
synchronized
 A fundamental value system for software architects
Carnegie Mellon University
Software Engineering Institute
Primal Forces ...
Management of functionality
 Meeting
the requirements
Management of performance
 Meeting
required speed and operation
Management of complexity
 Defining
abstractions
Management of change
 Controlling
the evolution of the software
Carnegie Mellon University
Software Engineering Institute
Primal Forces ...
Management of IT resources
 People
and IT artifacts
Management of technology
 Controlling
technology evolution
Carnegie Mellon University
Software Engineering Institute
Architecture AntiPatterns
 The
Blob
 Cut-and-Paste Programming
 Stovepipe Enterprise
 Design By Committee
 Swiss Army Knife
 Reinvent the Wheel
Carnegie Mellon University
Software Engineering Institute
The Blob
Problem
 Procedural
style design leads to one object with a
lion’s share of the responsibilities
 Most other objects only hold data
 This is the class that is really the heart of our
architecture
 One class monopolizes the processing and the
others encapsulate data
Carnegie Mellon University
Software Engineering Institute
The Blob ...
Causes
 Lack
of an object-oriented architecture
 Lack of architecture enforcement
 Procedural design expert are chief architects
 Wrapping a legacy system results
in a Blob … acceptable
Carnegie Mellon University
Software Engineering Institute
The Blob ...
Solution
 Distribute
responsibilities more uniformly
 Isolate the effect of changes
 Identify or categorize attributes and operations
 Find “natural homes” for the identified classes
 Remove outliers
Carnegie Mellon University
Software Engineering Institute
Cut-and-Paste Programming
Problem
 Software
clones
 “Hey, I thought you fixed that bug already, so why
is it doing this again?”
 “Wow, you guys work fast. Over 400KLOC in
three weeks is amazing!”
 Degenerate form of reuse
 Very common in COBOL
Carnegie Mellon University
Software Engineering Institute
Cut-and-Paste Programming ...
Solution
 Clone
detection
 Parameterize types
 Introduce an additional level of indirection
 Exploit polymorphism
 Dynamic schemas
Carnegie Mellon University
Software Engineering Institute
Stovepipe Enterprise
Problem
 Stovepipe
System is characterized by a software
structure that inhibits change
 Must be constantly repaired
 Brittle, monolithic system architectures (usually
undocumented)
 Inability of systems to interoperate
Carnegie Mellon University
Software Engineering Institute
Stovepipe Enterprise ...
Solution
 Coordination
of technologies at several levels
 Identify common standards and migration direction
with a standard reference model
 Usage conventions across systems
 Detailed interoperability conventions across
systems
 Product lines (SEI)
Carnegie Mellon University
Software Engineering Institute
Design by Committee
Problem
 Gold
Plating, Standards Disease, Make Everybody
Happy, Political Party
 Project team are egalitarian; everyone has equal
say; decisions are democratic
 The majority rule leads to diffusion of abstraction
and excess complexity
 “A camel is a horse designed by a committee.”
Carnegie Mellon University
Software Engineering Institute
Design by Committee ...
Symptoms
 Design
documentation is voluminous
 The requirements do not converge and are unstable
 Design meetings are slow, concentrate on details,
and avoid big picture discussions
 Decisions are only made in meetings
 No prioritization of design features
Carnegie Mellon University
Software Engineering Institute
Design by Committee ...
Causes
 No
designated project architect
 Ineffective meeting facilitation
 The suggestions of all committee members are
incorporated to keep everybody happy
 No separation of concerns
Carnegie Mellon University
Software Engineering Institute
Design by Committee ...
Refactored solution
 Reform
the meeting process
 Why are we here?
 What outcomes do we want?
 Assign explicit roles
 Owner,
facilitator, architect, developer, tester, domain
expert
 “My specialty is being right when other people are being
wrong.” — George Bernard Shaw
Carnegie Mellon University
Software Engineering Institute
Design by Committee ...
Employ Spitwads meeting process
 Ask
question—How can we improve performance?
 Write down answer silently
 Toss spitwads à la Michael Jordan
 Redistribute, read, and record spitwads
 Reach common understanding
 Eliminate duplicates
 Prioritize by voting
 Discuss highest priority selections
Carnegie Mellon University
Software Engineering Institute
Design by Committee …
SQL example
 SQL89—115
pages
 SQL92—580 pages
 SQL3—still not complete; may never be fully
implemented; a dumping ground for advanced
database features
 Better solutions
 Open Database Connectivity (ODBC)
 Java Database Connectivity (JDBC)
Carnegie Mellon University
Software Engineering Institute
Reinvent the Wheel
Problem
 Our
problem is unique
 Developers have minimal knowledge of each
other’s code
 Building systems from the ground up even though
related legacy systems exist
 The existence of legacy systems is the norm rather
than the exception
 Lack of program families or product lines
Carnegie Mellon University
Software Engineering Institute
Reinvent the Wheel ...
Symptoms
 Closed
system architectures—no provision of
reuse, interoperability, or change management
 Replication of COTS components
 Inability to deliver desired features on time and
within budget
 Corporate knowledge is not leveraged
Carnegie Mellon University
Software Engineering Institute
Reinvent the Wheel ...
Causes
 No
communication and technology transfer among
software development projects
 Corporate knowledge is not leverage
 No explicit architecture process
 Lack of enterprise management
Carnegie Mellon University
Software Engineering Institute
Swiss Army Knife or Kitchen Sink
Problem
 Excessively
complex class interface
 Designer attempts to provide for all possible uses
of the class
 Complicated interface
 Many overloaded names
 Excessive regression test suites
 Several Swiss Army Knifes in a single design
Carnegie Mellon University
Software Engineering Institute
Swiss Army Knife ...
Refactored solution
 Provide
guidelines for using complicated standards
or interfaces
 Provide a template for exception handling
 Contract interfaces
Carnegie Mellon University
Software Engineering Institute
Summary
 During
program comprehension and evolution one
should be particularly aware of the potential
presence of AntiPatterns
 Awareness of AntiPatterns is critical for
reengineering projects
 Consider AntiPatterns next time you sign on to a
new project
 Invest in reading the AntiPatterns book
Carnegie Mellon University
Software Engineering Institute
Part III
Software Architecture
Reconstruction
S. Jeromy Carrière
Carnegie Mellon University
Software Engineering Institute
Outline
• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
 Extraction
and Storage
 Manipulation
 Presentation
• Reconstruction Methodologies
• Examples
Carnegie Mellon University
Software Engineering Institute
Another Definition of Architecture
A set of design decisions
Typically documented as a set of views
Realized in an implementation via mappings
Mappings are almost invariably informal
(i.e. not explicitly recorded in any
implementation artifact)
The implementation is the consequence of the
application of the mappings
Carnegie Mellon University
Software Engineering Institute
Example: Layers
Question: What is a layer?
Answers:
 At
worst a delusion.
 At best a convention.
 Nothing that exists in what we actually build (e.g.
no “layer” construct in a programming language).
 Nothing that is enforceable.
Carnegie Mellon University
Software Engineering Institute
And Yet . . .
Architectures use these abstractions regularly.
Architects think and plan and analyze in terms of
these abstractions.
So,
we should support these abstractions and connect
them to what we do build.
Carnegie Mellon University
Software Engineering Institute
So What Is Architecture
Reconstruction?
A process in which cultural hypotheses are
generated and tested  anthropological
These hypotheses are ideally the inverse of the
mappings developed during design
The reconstructor must add information during
the reconstruction process
 This
depends on the reconstructor’s available
information and bias
Carnegie Mellon University
Software Engineering Institute
Outline
• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
 Extraction
and Storage
 Manipulation
 Presentation
• Reconstruction Methodologies
• Examples
Carnegie Mellon University
Software Engineering Institute
But Why Reconstruct?
We frequently need to reason architecturally
about existing systems.
We need to be able to:
 analyze
architectures
 (re)document architectures
 identify architectural dependencies
Carnegie Mellon University
Software Engineering Institute
Architectural Conformance - I
Question: If my architecture was designed with a
particular property in mind, does the property
hold for my target system?
(Probable) Answer: Who knows?
Carnegie Mellon University
Software Engineering Institute
Architectural Conformance - II
The architecture of the implemented system must
conform to the architectural design.
Otherwise, architectural drift and erosion are
inevitable.
But conformance (by hand) is a dreary task.
Carnegie Mellon University
Software Engineering Institute
Outline
• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
 Extraction
and Storage
 Manipulation
 Presentation
• Reconstruction Methodologies
• Examples
Carnegie Mellon University
Software Engineering Institute
Tools for Software Architecture
Reconstruction
Groups working on tools/toolsets:
 University
of Victoria (Hausi Müller)
 Software Engineering Institute
 MITRE (Penny Chase)
 University of Waterloo (CSER project)
 Philips (René Krikhaar)
Carnegie Mellon University
Software Engineering Institute
Tools for Software Architecture
Reconstruction
Manipulation
Extraction
Presentation
Repository
Carnegie Mellon University
Software Engineering Institute
Dali: A Software Architecture
Reconstruction Workbench (SEI)
Extraction
Lexical
View Fusion
Analysis
Parsing
Profiling
Presentation
Instrument
.
.
.
SQL Repository
Manipulation
Carnegie Mellon University
Software Engineering Institute
Software Bookshelf/PBS (Holt et al)
Manipulation
Extraction
Parsing
Presentation
.
.
.
Fact Files
Layout
Carnegie Mellon University
Software Engineering Institute
Outline
• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
 Extraction
and Storage
 Manipulation
 Presentation
• Reconstruction Methodologies
• Examples
Carnegie Mellon University
Software Engineering Institute
Extracting Information
Most approaches are opportunistic. In common
use are:
 parsers
(SNiFF+, cfx, CIA, rigiparse, EDG)
 CBMS systems (Reasoning SDK)
 lexical analyzers (LSME)
 profilers (gprof)
 code instrumentation
 ad hoc (grep, perl)
Carnegie Mellon University
Software Engineering Institute
Extracting Information - 2
Source code analysis is insufficient:
 late
binding
 system topology information
This information is available only in artifacts
other than source models.
Carnegie Mellon University
Software Engineering Institute
Repositories
Use of attributed relational models (E/R/A) is
almost universal:
 simple
 flexible
 sufficiently
expressive
 well supported by existing tools
Carnegie Mellon University
Software Engineering Institute
Example Repository Contents (Dali)
Some relations relevant to software architecture:
 function
calls function
 file contains function
 class has_subclass class
 class has_friend class
 process communicates_with process
 process writes file
. . .
Carnegie Mellon University
Software Engineering Institute
A Repository Schema (Bowman)
$ENTITY
inherits
Source
Artifact
declaredIn
inherits
inherits
$RELATION
definedIn
contains
Software
Object
Source File
inherits
inherits
typeRef
Type
Element
inherits
Subsystem
lexicalRef
inherits
Derived
Artifact
inherits
functionRef
contains
$RELATION
Functional
Element
Data
Element
dataRef
Carnegie Mellon University
Software Engineering Institute
A Schema for Procedural
Languages (Bowman)
Source
File
defines
defines
defines
Data Type
uses
type
uses
file
defines
defines
Procedure
uses
procedure
uses type
Data
uses
data
Carnegie Mellon University
Software Engineering Institute
Dali’s Repository
Dali uses an SQL database with a philosophy of
openness and lightweight tool integration via
text formats (RSF - Rigi Standard Format).
The database and tools are ignorant of each other.
The tools extract, modify, manipulate, and store
architectural artifacts in the database.
Integration is controlled via Rigi’s RCL and
scripts.
Carnegie Mellon University
Software Engineering Institute
PBS’ Repository
PBS uses a file-based approach to storing
“facts”:
 TA (Tuple-Attribute)
format - based on RSF
This approach improves “exchangeability” but
potentially involves more run-time overhead.
Integration is accomplished via scripts.
Carnegie Mellon University
Software Engineering Institute
Philip’s Repository
Based on the concepts of:
 InfoPacks:
information extracted from a system
 ArchiSpects: representation of an architectural
structure or analysis
Both include a description of the steps to
construct the model.
Integration is achieved via a variety of scripts
and tools.
Carnegie Mellon University
Software Engineering Institute
Information Interchange
It’s important to be able to exchange facts and
models.
We need two things to do this properly:
 an
agreed-upon syntax, including a schema
 an agreed-upon semantic model for describing the
facts and their manipulations
Carnegie Mellon University
Software Engineering Institute
Outline
• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
 Extraction
and Storage
 Manipulation
 Presentation
• Reconstruction Methodologies
• Examples
Carnegie Mellon University
Software Engineering Institute
Manipulation - Motivation
Architectural elements are not explicitly
represented in source code.
 “user
interface”, “repository”, “cache”, etc. are
usually tangled collections of objects
architectural constructs are realized by many
mechanisms in an implementation
Therefore, we need to “reconstruct” architectural
elements.
Carnegie Mellon University
Software Engineering Institute
Manipulation in Dali: View Fusion
Motivation:
 Extractors
will frequently produce incomplete and
partially overlapping data
A complete view of a system requires views to be
fused:
 different
views provide complementary information
 one view can improve another
Carnegie Mellon University
Software Engineering Institute
Manipulation in Dali: Aggregation
Primary mechanism for manipulation is the
application of patterns for aggregation,
constructed using SQL.
Examples:
 aggregate
local variables with functions
 aggregate members with classes
 compose architecture-level elements
Carnegie Mellon University
Software Engineering Institute
Manipulation in PBS
Manipulation of facts in PBS is performed using
Grok
 Grok
is a relational calculator based on Tarski
relational algebra (with extensions)
 “abstraction” is the key transformation of the
model
 input for abstraction comes from containment
hierarchies specified by the reconstructor
Carnegie Mellon University
Software Engineering Institute
Manipulation in Philips’ Toolset
Manipulation of models is performed via the
Relational Partition Algebra (RPA)
 RPA is
also based on Tarski algebra
 Computation is carried out using a variety of
implementations of RPA
 ArchiSpects specify the creation of abstracted
views
Carnegie Mellon University
Software Engineering Institute
Outline
• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
 Extraction
and Storage
 Manipulation
 Presentation
• Reconstruction Methodologies
• Examples
Carnegie Mellon University
Software Engineering Institute
Presentation
The end goal of architecture reconstruction is
generation of architectural views that:
 improve
understanding of the system
 provide (improved) documentation
 improve maintainability
 facilitate analysis
Carnegie Mellon University
Software Engineering Institute
Presentation in Dali
Presentation in Dali is done using Rigi
Rigi provides useful graph editing functionality:
 layout
 direct
manipulation
 hierarchical navigation
 extensibility
Examples coming up...
Carnegie Mellon University
Software Engineering Institute
Presentation in Bookshelf/PBS
The “software landscape” presentation approach:
 hierarchical
 PBS
is Web-based (Java)
 incorporates architectural visualizations within a
framework of documentation
Carnegie Mellon University
Software Engineering Institute
PBS: Example
Carnegie Mellon University
Software Engineering Institute
Outline
• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
 Extraction
and Storage
 Manipulation
 Presentation
• Reconstruction Methodologies
• Examples
Carnegie Mellon University
Software Engineering Institute
Reconstruction Methodologies
A predictable, repeatable method is important
for management of reconstruction activities
Because the process is primarily one of
hypothesis formulation and test, we need
structured methods for information collection
Methods are universally semiautomatic
(shouldn’t be a surprise!)
Carnegie Mellon University
Software Engineering Institute
A Reconstruction Method Sketch (SEI)
Develop
information
model
Populate
information
model
Identify
architectural
components
Evaluate
Develop
architectural
rules
Apply
architectural
rules
Extract
information
Map
models to
template
Develop
representation template
Carnegie Mellon University
Software Engineering Institute
The Hybrid Approach (Tzerpos & Holt)
Hybrid: Combine extracted information with
information collected from developers.
Iterative steps at multiple levels of granularity:
 Choose
domain model
 Extract facts from source code
 Cluster into subsystems
 Refine clustering using “live” information
 Refine layout using “live” information
Carnegie Mellon University
Software Engineering Institute
The Architecture Reconstruction
Method (Guo)
Pattern- and style-oriented approach to
reconstruction
Four primary phases:
 Developing
a concrete pattern recognition plan
 Extracting a source model
 Detecting and evaluating pattern instances
 Reconstructing and analyzing the architecture
Carnegie Mellon University
Software Engineering Institute
Outline
• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
 Extraction
and Storage
 Manipulation
 Presentation
• Reconstruction Methodologies
• Examples
Carnegie Mellon University
Software Engineering Institute
Example: VANISH (using Dali)
As-designed Architecture
Dialogue
Functional
Core Adapter
Functional
Core
Logical
Interaction
Presentation
Carnegie Mellon University
Software Engineering Institute
Extract Information
“White noise”:
a typical extracted
model.
Carnegie Mellon University
Software Engineering Institute
Apply Generic Patterns
Aggregate
functions and
local variables;
classes and
members; classes
and files.
Carnegie Mellon University
Software Engineering Institute
Apply Application-Specific Patterns
Identify the layers
from the Arch model.
Carnegie Mellon University
Software Engineering Institute
The Final Product
As designed:
As implemented:
Dialogue
Dialogue
Functional
Core Adapter
Functional
Core
Logical
Interaction
Presentation
Functional
Core Adapter
Functional
Core
Logical
Interaction
Presentation
Carnegie Mellon University
Software Engineering Institute
Analysis - 1
Architectural conformance via RMTool (Murphy)
Carnegie Mellon University
Software Engineering Institute
Analysis - 2
If we believe in pattern-based simplicity . . .
. . . we should be able to measure this in an
architecture.
IAPR is an analysis tool to do this.
Approach pattern matching as sub-graph
isomorphism: a search task (NP-hard).
Carnegie Mellon University
Software Engineering Institute
Coloring an Architecture (Kazman & Burth)