Modeling and Analysis

of Software Architecture
Robert T. Monroe
Carnegie Mellon University FreeMarkets Corp.
5000 Forbes Ave. One Oliver Plaza
Pittsburgh, PA 15213 Pittsburgh, PA 15222
bmonroe@cs.cmu.edu bmonroe@freemarkets.com

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 1

 Acknowledgment

Some of the material in this tutorial was drawn

from a tutorial on Software Architecture
developed by Mary Shaw and David Garlan.
Some parts are adapted from a semester course
on Software Architecture taught by Mary Shaw
and David Garlan from 1992-1998. Robert Allen,
of IBM, helped greatly in the creation of a
previous version of this tutorial.
The development of the tutorial was supported in part by
grants from the US Department of Defense Advanced
Research Project Agency. The underlying research has
been supported by the US Department of Defense, the
National Science Foundation, Siemens Corporation, The
Eastman Kodak Corporation, and Carnegie Mellon
University.
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 2
 Outline

• Introduction to Software Architecture

• Architectural Modeling
> Architectural structure and topology
> Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities & challenges

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 3

 Three Ideas To Take Away

• Architecture description languages and

toolkits (ADLs) are useful for describing,
documenting, and reasoning about Software
Architectures.

• There are a number of interesting and useful

architecture-level analyses that can be
performed with existing ADLs and their
associated toolkits.

• There are further powerful analysis and

generation capabilities on the horizon.
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 4
 Typical Descriptions of
Software Architectures

The Architecture of This System

• Descriptions of software
systems often include a
section on “the architecture
of this system”
• Usually informal prose plus
box-and-line diagram
• Lots of appeal to intuition
• Little precision, rarely
formal
Next Section

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 5

 Typical Descriptions of
Software Architectures

> "Camelot is based on the client-server model and

uses remote procedure calls both locally and
remotely to provide communication among
applications and servers." [Spector 87]
> "We have chosen a distributed, object-oriented
approach to managing information." [Linton 87]
> "The easiest way to make the canonical
sequential compiler into a concurrent compiler is
to pipeline the execution of the compiler phases
over a number of processors." [Seshadri 88]
> "The ARC network [follows] the general network
architecture specified by the ISO in the Open
Systems Interconnection Reference Model."
[Paulk 85]

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 6

 Observations about Designers

• They freely use informal patterns (idioms)

> Very informal, imprecise semantics
> Diagrams as well as prose, but no uniform rules
> Communication takes place anyhow

• Their vocabulary uses system-level

abstractions
> Overall organization (styles)
> Kinds of components and interactions among them

• They compose systems from subsystems

> Tend to think about system structure statically
> Often select organization by default, not by design

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 7

 Architectural Design Level of Software
• Deals with the composition of software
systems from module-scale elements
> Gross decomposition of required function
» What patterns of organization are useful?
» Which organization fits the application best?
> Assignment of function to design elements
» What are the elements?
» How do the elements interact?
> Emergent system properties
» Scaling and performance: Capacities, balance, schedules
» Security
» ...
> Selection among design alternatives
» Which implementations of elements will work best?

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 8

 Architectural Design Task

Issues for architecture and programs differ

Architecture Programs
interactions among parts implementations of parts
structural properties computational properties
declarative operational
mostly static mostly dynamic
system-level performance algorithmic performance
outside module boundary inside module boundary
composition of subsystems copy code or call
libraries

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 9

 Promised Benefits of
Architectural Modeling
• Clarify design intentions
> Intended architecture is often lost. It's mostly
informal, it's hard to communicate anyhow.
• Provide basis for analysis in design
> Engineering design entails performance
prediction and design tuning. Routine
practice.
• Improve maintenance
> Over half of maintenance effort goes into
figuring out just what's there.
• Address the hard questions
> Even without formal methods, explicit
architectural modelling can uncover fuzzy
requirements, thinking, and design approaches

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 10

 Promised Benefits of
Architectural Modeling
update document (6%) review document (6%)
test & debug (28%)
define/analyze change
Requirements (18%)

Architecture

trace logic (23%)

Design implement change (19%)

Reduce maintenance
costs, directly and
Code/Integ
• Clarify intentions indirectly
• Make decisions and
Test/Accept
implications explicit
• Permit system-level
analysis Maintenance

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 11

 Architectural Design Reviews

Prospectus Planning and

Architecture Phase

Requirements

Discovery
Review Architecture

High-Level
Design
Source:
Joe Maranzano
ATT Bell Labs Architecture Low-Level
Review Design
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 12
 Elements of Architectural Descriptions

• A system architecture identifies

> Components: define the locus of computation
» Examples: filters, databases, objects, clients/servers
> Connectors: mediate component interactions
» Examples: procedure call, pipes, event broadcast
> Properties: specify info for construction &
analysis
» Examples: signatures, pre/post conds, RT specs
• An architectural style defines a family of
architectures constrained by
> Component/connector vocabulary
> Topology rules
> Semantic constraints

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 13

 Example: Key Word In Context

Problem Description:
"The KWIC index system accepts an ordered set
of lines, each line is an ordered set of words,
and each word is an ordered set of characters.
Any line may be ‘circularly shifted’ by
repeatedly removing the first word and
appending it at the end of the line.
The KWIC index system outputs a listing of all
circular shifts of all lines in alphabetical
order."

On the Criteria for Decomposing Systems into Modules. David Parnas. CACM, 1972

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 14

 KWIC: Key Word In Context

• Inputs: Sequence of lines

Pipes and Filters
Architectures for Software Systems
• Outputs: Sequence of lines, circularly
shifted and alphabetized
and Filters Pipes
Architectures for Software Systems
Filters Pipes and
for Software Systems Architectures
Pipes and Filters
Software Systems Architectures for
Systems Architectures for Software

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 15

 KWIC: Shared Memory Solution

Direct Memory Access

Subprogram Call Master Control
System I/O

Input Circular Shift Alphabetizer Output

Characters Index Alphabetized

Index

Output
Input
Medium
Medium

Advantage: Good performance

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 16
 KWIC: ADT Solution

Subprogram Call Master Control

System I/O

Input Output

Alphabetic
Characters Circular Shift Shifts

Input Output
Medium Advantage: Information hiding Medium
simplifies implementation changes.
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 17
 KWIC: Event Solution

Implicit Invocation Master Control

Subprogram Call
System I/O

Input Circular Output

Alphabetizer
Shift

Input Output
Medium Medium
Lines Lines

Advantage: Tool separation supports function enhancements.

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 18
 KWIC: Dataflow Solution

Input Circular
Input
Medium Shift

Pipe
System I/O
Alphabetizer Output Output
Medium

Advantage: Tool separation eases functional enhancements.

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 19

 Design Considerations

• Change in Algorithm
> Eg., batch vs incremental
• Change in Data Representation
> Eg., line storage, explicit vs implicit shifts
• Change in Function
> Eg., eliminate lines starting with trivial words
• Performance
> Eg., space and time
• Reuse
> Eg., Sorting

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 20

 KWIC Comparisons

Shared
Memory ADT Events Dataflow

Change in Algorithm _ _ + +

Change in Data Repn _ + _ _

Change in Function + _ + +

Performance + + _ _

Reuse _ + _ +

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 21

 Outline

• Introduction to Software Architecture

• Architectural Modeling
> Architectural structure and topology
> Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities & challenges

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 22

 Architectural Vocabulary (Structure)

system

connector

component

port role

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 23

 Architectural Structure:
Components, Connectors, Systems

• Components
> computational elements
• Ports
> interface points for components
• Connectors
> interactions between components
• Roles
> interface points for connectors
• Systems
> graphs of component and connectors

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 24

 System Description Example (Acme)

Component Type ClientT = { Port sendReq; … };

Design
Component Type ServerT = { Port receiveReq; … }; Vocabulary
Connector Type RPCT = { Roles {caller; callee}; … };

System SimpleClientServer = {
Component viewer : ClientT;
Component database : ServerT;
System
Connector conn : RPCT;
Attachments = { Description
viewer.sendReq to conn.caller;
viewer.receiveReq to conn.callee; viewer
};
};
Topology database
Description
 Architectural Structure:
Hierarchical Descriptions

• Representations
> describe subsystems
> may be architectural or external

• Abstraction mappings
> relate the inside and outside of architectural
representations
> bindings are special case

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 26

 Representations

• Provide a description of a complete “view” of the

design element
• May be external [e.g. file, URL] or sub-architecture

Configuration

Component Representations
...
if(x>0) ...
{ ...
write(out);
x--; ...
} ...

Source Formal Configuration

code specification (sub-architecture)

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 27

 Abstraction Maps

map

representation

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 28

 Beyond Simple Structure

• What else can we represent?

> Local component or connector properties
» Rates, capacities, latencies, etc. for individual
components and connectors
> Emergent system-wide properties
» Overall system performance, reliability, security, etc.
> Behavior
» computations of components
» protocols of connectors
• Many forms and notations for semantics
> property lists
> protocol specifications
> type systems ...

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 29

 Capturing Local Properties (with Acme)

Component Type ServerT = {

Port receiveReq : ODBCPortT = {
Property supportsODBCLevel : int = 2;
Property supportsConcurrentTrans : boolean = true;
};
Property maxConcurrentTrans : int = 20;
Property averageTransProcessingLatency : float;
Property ODBCComplianceLevel : int;
};

Connector Type RPCT = {

Roles {caller; callee};
Property synchronous : boolean = true;
};
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 30
 Capturing System Properties (with Acme)

System SimpleClientServer = {
Components { viewer1 : ClientT; viewer2 : ClientT; }
Component database : ServerT;
Connector conn : RPCT;
Attachments = { … };

Property viewerRequestDistribution = interleaved

<< origination = asserted; >>;
Property transactionProcessingCapacity : float = 34.5
<< units = transactions-per-second;
origination = computed; >>;
Property maxConcurrentViewers : int = 5
<< origination = computed; >>;
};

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 31

 Specifying Behavior (Protocols)

Notation (based on CSP):

> Events: request, newValue?y
> Processes: P, WorldModel, Client, §
» Sequence: e  P, P;Q
» Choice: P  Q, P [] Q
» Quantification: [] x: S  P(x)

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 32

 WRIGHT Configuration
Configuration SimpleSimulation
Component WorldModel(map: Function)
Port Provide <provide protocol> Component
Computation <provide world model> types
Component VehicleModel
Port Environment <value protocol> Connector
Computation <Vehicle behavior> types
Connector UpdateValues(n : 1.. )
Instances
Role Model1..n <1 model’s protocol>
Glue <data from one model to another>
Instances Attachments
Envt : WorldModel(<map>)
V : VehicleModel
Cn : UpdateValues(2)
Envt V
Attachments
Envt.Provide as Cn.Model1
Cn
 Example:
What is “UpdateValues Connector”?
Connector UpdateValues(n : 1.. )
Role Model1..n =

<a model’s protocol>

Glue =

<data travels from one model to another>

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 34

 Example:
What is “UpdateValues Connector”?
Connector UpdateValues(n : 1.. )
Role Model1..n = (open
request newVal?y
update!x
close

Glue =

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 35

 Example:
What is “UpdateValues Connector”?
Connector UpdateValues(n : 1.. )
Role Model1..n = (open  Operate)
request newVal?y
update!x
close

Glue =

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 36

 Example:
What is “UpdateValues Connector”?
Connector UpdateValues(n : 1.. )
Role Model1..n = (open  Operate)
where Operate = request newVal?y
 
Operate update!x
 close  Operate


 
Glue =

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 37

 Example:
What is “UpdateValues Connector”?
Connector UpdateValues(n : 1.. )
Role Model1..n = (open  Operate)
where Operate = request newVal?y
 
Operate update!x
 close  Operate


 
Glue =

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 38

 Example:
What is “UpdateValues Connector”?
Connector UpdateValues(n : 1.. )
Role Model1..n = (open  Operate)  §
where Operate = request newVal?y
 
Operate update!x
  close  Operate§


 
Glue =

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 39

 Example:
What is “UpdateValues Connector”?
Connector UpdateValues(n : 1.. )
Role Model1..n = (open  Operate)  §
where Operate = request newVal?y
 
Operate update!x
  close  Operate§


 
Glue = Statev where Statev =
[] i:1..n  Modeli.open  Statev
[] [] i:1..n  Modeli.request  Modeli.newVal!
v  Statev
[] [] i:1..n  Modeli.update?x  Statex
[] [] i:1..n  Modeli.close  Statev
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 40
 Example:
What is “UpdateValues Connector”?
Connector UpdateValues(n : 1.. )
Role Model1..n = (open  Operate)  §
where Operate = request newVal?y
 
Operate update!x
  close  Operate§


 
Glue = Statev where Statev =
[] i:1..n  Modeli.open  Statev
[] [] i:1..n  Modeli.request  Modeli.newVal!
v  Statev
[] [] i:1..n  Modeli.update?x  Statex
[] [] i:1..n  Modeli.close  Statev
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 41
 Outline

• Introduction to Software Architecture

• Architectural Modeling
> Architectural structure and topology
> Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities & challenges

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 42

 Kinds of Analyses

> Consistency
» Do the parts fit together?
> Completeness
» Are parts missing?
> Refinement
» Can one architecture be substituted for another?
> Verification
» Does an implementation conform to the architecture?
> System-wide behavior, performance, reliability, etc.
» What is the aggregate behavior of a system, given the
behaviors of the parts?
> Evaluating design choices and trade-offs

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 43

 Analysis Strategies

• Use existing specification languages &

calculi
> Examples: CSP, UML, Queuing Theory,
Napkin/Envelope (back of)
> Advantages: well understood, tools, reuse
> Disadvantages: may not be expressive; may
require a lot of initial “context building” before
you can do anything useful
• Develop new architectural specification
languages & reasoning techniques
> Examples: Rapide, Wright, Meta-H
> Advantages: good match to the problem
> Disadvantages: learning curve, proliferation of
languages, analysis techniques, tools, mismatch
of problem and technique

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 44

 Analysis: consistency & completeness

• Consistency: do the parts fit together?

> analog of type checking
> depends on what you say about the parts
> behavior example: does the behavior of a
component conform to the protocols of a
connector to which it is attached?
?
• Completeness: are any parts missing?
> connector roles?
> unattached ports?
> missing functionality?

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 45

 Consistency Check 1: Faulty Client

• Trivial Client-Server system (1 client, 1 server)

• Client should initialize before requesting, but it
doesn’t do so.
• Disaster detected and averted early ...

Connector Faulty
Role Client = (requestresultClient)  §
Role Server = initialize Operate...
Glue = Client.initializeServer.initializeGlue
[] Client.requestServer.requestGlue
...
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 46
 Consistency Check 2: Paused on Join

Role
JoinFed = joinFedExecution  FedRunning

FedRunning = requestPause  FedRunning

 schedulePause  pauseAchieved  FedPaused

FedPaused = requestResume  FedPaused

 scheduleResume  resumeAchieved  FedRunning
___________

Glue
HandlePauseS =  i: S [] Fedi.requestPause
 ( i: S ; Fedi.schedulePause  §) ; HandlePauseS
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 47
 Paused on Join

Federate Federate

(1) joinFedExecution
(2) requestPause
(3) schedulePause
(4) pauseAchieved
(5) joinFedExecution
(6) requestPause

RTI

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 48

 Oops!

Federate Federate

(1) joinFedExecution
(2) requestPause
(3) schedulePause
(4) pauseAchieved
(5) joinFedExecution
(6) requestPause
(7) schedulePause

RTI

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 49

 Consistency Check 3
Save Boundary Condition

Federate1 Federate2 RTI internal

Save will be inconsistent

updateAttrValue

(receive update)

(commit to send)

reflectAttrValue

RTI

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 50

 Example of a completeness check

• Example completeness rule: All clients

need to be attached to at least one server.
> Client with no server is incomplete
> … but server with no client is fine.
> Completeness rules can be style-specific

Client Client Client Client Client Client

Server Server Server

Incomplete! Complete
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 51
 Analysis: Refinement & Verification

• Refinement: can one architecture be

substituted for another?
• Verification: does an implementation
conform to the architecture?
• Important because supports design at a
high level of abstraction
• Example: Implement a pipe-filter system
using procedure call

Abs Abs

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 52

 Analyzing system-wide properties

• Key idea: calculate properties of a system,

given properties of its parts
• Different kinds of property will have
different calculi for compositionality
• Usually depends on using a specific style
> Example 1: queuing theory can be used to
calculate overall throughputs and latencies if
use asynchronous message passing style
> Example 2: reliability block diagrams can be
used to determine aggregate reliability from the
parts, for certain styles

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 53

 Example 1: Performance predictions

• Can the servers handle the

expected demand?
infectious-diseases-ui microbiology-ui pharmacy-ui
• Will the average response
time meet requirements? i-ui
m-ui p-ui

• How large should the trend-tracker simple-server

buffers be?
p-db-2

• Highest demand the m-db-1 p-db-1

m-db-2

servers can handle? microbiology-db pharmacy-db

• Which component is the

Hospital MIS System
bottleneck?
• How would server/database
replication affect this?
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 54
 Performance Analysis Alternatives

• Measurement
> Most accurate; modifications difficult
> Requires existing system, workload
• Simulation
> Accuracy and ease of modifications vary
> Requires existing simulator, workload
• Analytical model
> Back-of-the-envelope accuracy in design
phase
> Nontrivial systems require nontrivial
calculation; analysis tools can help.

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 55

 Queuing Networks

• Domain: Computer Systems

• Elements
> service centers
> queues, associated with service centers
• Assumptions
> asynchronous arrival of jobs in queues
> exponential rates, independence
> each job exists in exactly one place at a time
• Given for each service center
> average arrival time of jobs
> average service time to process a job
• For details see [SG98]

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 56

 Queueing Network Predictions

• fraction of time service center is occupied

(utilization)
• average time a job spends waiting in
queue
• average queue length
• probability[ queue length = n ]
• throughput of a system
• latency for a job processed by system
• number of outstanding jobs in system
• potential bottlenecks

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 57

 Naive Application to SW Arch

• Define an architectural style in which

> Service centers distributed processing
components
> Transmission lines directional
asynchronous message passing connectors

• Associate service times with components

and arrival rates with system
• Use Queueing Networks to calculate
derived values for the components and
the system

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 58

 Complicating Factors

• Cycles -- jobs may pass through same

component several times before exiting
• Autonomous clients -- generate jobs by
themselves
• Delays in connectors -- present for
architectures of real systems
• Replication -- meaning and effect on
calculations

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 59

 QN Example: Local Properties

User defines local

infectious-diseases-ui
performance properties by:
microbiology-ui pharmacy-ui

> Simulation
> Guesstimate i-ui
m-ui p-ui

> Measured values

trend-tracker simple-server

Component microbiology-db = {
p-db-2

Ports {…}; m-db-1 p-db-1

m-db-2

Property localPerformance = [
microbiology-db pharmacy-db
replication = 2;
serviceTime = 1000ms;
Hospital MIS System
outputMessagePaths = […];
];
Property computedPerformance = [
…?
];
};
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 60
 QN Example: Emergent Global Properties

System hospitalMIS = { …
infectious-diseases-ui microbiology-ui
Property systemPerformance = [ pharmacy-ui

avgResponseTime = 2784ms;
i-ui
avgSystemMsgs = 2.342; ]; m-ui p-ui

trend-tracker simple-server
Component microbiology-db = {
Ports {…}; m-db-2
p-db-2
m-db-1 p-db-1

Property localPerformance = […];

Property computedPerformance = [ microbiology-db pharmacy-db

avgResponseTime = 2143ms;
avgQueueLength = 0.923; Hospital MIS System
avgUtilization = 0.48;
overloaded = false; Tool computes system-wide
]; }; performance properties
}; based on configuration

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 61

 Example 2: Reliability predictions

• Basic idea: apply Reliability Block

Diagrams to Software Architecture
> Reuses well developed reliability model
> Slightly modified to work with Software Arch.
• Initial information includes:
> reliability of individual components
> topology of interaction, concurrency, replication
• From this we calculate expected reliability
of the system as a whole.

• Reliability defined as R = e-T where:

  is a component’s failure rate
» T is the time period over which reliability is measured

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 62

 Reliability Block Diagrams Example

Example from:
Abd-Allah, Ahmed, “Extending Reliability Block
Diagrams to Software Architectures”, USC
Technical Report USC-CSE-97-501. [AbdAllah97]

R1

... R2
R1 R2 Rn ...
Rn
n n
Rsys   Ri Rsys 1   1  Ri 
i 1 i 1
Serial Composition Parallel Composition

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 63

 Reliability Block Diagram Complications

• Simple model has some complications

> Concurrency
> Distribution
> Dynamism
> Connectors may be unreliable

• These complications are addressed for

many (but not necessarily all) styles.
> See [AbdAllah97] for details

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 64

 Detailed RBD Example

Modeling a Java/WWW-based client-server system*

server machine client machine
100%
WWW Server Java Client
88.7%
2 failures/1000h 10

Overall System Reliability

80.3%
75% 72.6%

(after 10 hours)
65.7%
59.5%

Database A Database A Database A 50%

3 1 2
25%
2  3 1  2
server  2
4 0%
1 2 3 4 5

client 10 Number of clients

system server  nclient ( for n 0) * Example borrowed

from [AbdAllah97]
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 65
 Analysis: Evaluating Design Choices

Should you use a

database?
file system?
Memory symbol table?
array?
knowledge-base?
other?
• What questions should you ask about the
application?
• How do the answers help you choose a design and
implementation strategy?
> how do you then make further design decisions?
> what classifications of the alternatives help?
• Can the memory questions be structured?
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 66
 Architecture Tradeoff Analysis Method

• ATAM -- The Architecture Tradeoff

Analysis Method
> A framework for evaluating the tradeoffs
between different design decisions
> Emphasizes design decision interactions
> Supports decision sensitivity analysis
• Better for finding big effects than precise
numbers
• Spiral design model supports iterative
evaluation of design options

• [Kazman et al, ICECCS ‘98]

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 67
 ATAM Process

1) Collect system usage scenarios

2) Collect requirements/constraints/envt
» These are the requirements for which analyses will be performed
3) Describe Architectural Views
» Describe multiple, competing architectural options
4) Attribute-Specific Analyses
» Analyze properties of each architecture option in isolation
5) Identify Sensitivities
» Determine the sensitivity of the various attributes to the available
architectural design options
6) Identify Tradeoffs
» Determine which architectural elements are sensitive to multiple
attributes (e.g. # of servers affects both the cost of the system and
its overall reliability)
7) Repeat…

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 68

 Outline

• Introduction to Software Architecture

• Architectural Modeling
> Architectural structure and topology
> Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities & challenges

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 69

 Architectural Style:
Families of Systems

...

• Systems share architectural vocabulary

• Analysis can be shared
> Simplifies design
• Infrastructure can be shared
> Simplifies implementation
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 70
 Elements of Style

• Design Vocabulary -- Architectural Element

Types
> Component and connector types
> Interfaces
> Representation/Notation
• Design Rules -- Configuration Constraints
> Topological constraints and patterns
> Valid property value ranges
> Invariants and heuristics
• Default system structure
> Basic infrastructure provided by style

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 71

 Style Example: C2

• Architectural style for GUI-based systems

“[C2] can be informally summarized as a network of
concurrent components hooked together by
message routing devices. Central to the
architectural style is a principle of limited visibility:
a component within the hierarchy can only be
aware of components ‘above’ it and completely
unaware of components which reside ‘beneath’ it.”

This definition and subsequent details borrowed

from [Tay+96] and the UC Irvine C2 website at
www.ics.uci.edu/pub/arch/
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 72
 Informal C2 Overview
• Desired Properties
> Flexible system extensibility & reconfigurability
> Increased component and design reuse
• Primary Component Type: C2 Component
> Conforms to standard C2 structure:

• Primary Connector Type: Message Bus

> Transports messages between components
> Supports multiple distribution and filtering policies

Domain Wrapper
Translator
C2 Component Internal
Object
Dialog &
Constraints

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 73

 Informal C2 Overview

• Primary C2 Design Rules

> All communication done through message buses
> Requests sent ‘up’, notifications sent ‘down’
> Components may be attached to no more than
one “upper” bus and one “lower” bus
> There is no bound on the number of components
or connectors that may be attached to a single
connector

[From C2 website]
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 74
 C2 Tools

• Well-defined style standard supports tools

• C2-specific tools include:

> Argo architectural design environment
> Code generation
> Run-time environment that supports dynamic
component replacement for executing systems
> Design critics provide design guidance
> Consistency and completeness checking

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 75

 Style Example: Justo-Cunha

R-S S-R

• Desired Property
> Global Deadlock-freedom
• One Connector Type
> Buffered Message Passing
• Two Component Types
> Send-then-Receive (S-R)
> Receive-then-Send (R-S)
• Topological Constraint
> No cycles of Receive-then-Send

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 76

 Informal Definitions: J-C Style

“The S-R component can send its messages and

then it may block waiting to receive its messages.
The <compute> part corresponds to a block of
statements that should not include
communication and should terminate...”

“The R-S component is the dual of the S-R

component. In this case, the component first
receives its message, performs some
computation and then sends messages.”
[Justo94CDS, p. 149]

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 77

 Informal Rules: J-C Style

1. A cycle of R-S component processes

always deadlocks.
2. A cycle of S-R component processes
never deadlocks.
3. A cycle of R-S and S-R component
processes never deadlocks.

[Justo94CDS, p. 151]

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 78

 Formal Spec: S-R Component

Component S-R (r:1..; s: 1..)

Port In1..r = ReceiverType
Port Out1..s = SenderType
Computation = S1 where

Si = {
Outi.send  Si+1, when 1is
Ini-s.recv  Si+1, when s<is+r
Ini-s.recv  S1, when is+r

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 79

 Formal Spec: Justo-Cunha Style Rules

c : Components 
Type(c) = R-S Type(c) = S-R
 c : Connectors 
Type(c) = MessageBuffer

 C : P Components |
Cycle(C)
c : Components  Type(c) = R-S

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 80

Some Useful J-C Style Formal Definitions

c1,c2 : Components  ConnectsTo(c1,c2) =

 cn : Connectors;p1,p2 : Port |
{((c1,p1),(cn,Sender)),
((c2,p2),(cn, Receiver))}
 Attachments

C : P Components  Cycle(C) =

S : seq C | ran S = C 
i : 1..#S-1  ConnectsTo(S(i),S(i+1))
 ConnectsTo(S(#S),S(1))

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 81

 Analyzing Architectural Styles

• Style Properties, Invariants, Theorems

> What is true of all instances of the style?
• Specialization (implication)
> Is one style a “substyle” of another?
• Inter-style translation
> How can you map a system defined in one arch
style to another
• Selection
> What style is appropriate for a given problem?

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 82

 Style Analysis: Theorems

• Style Properties, Invariants, Theorems: what

is true of all instances of the style?
• Important because can prove a result once
that is automatically true for a large class of
systems
> assuming that it’s easier to check style
membership
• Example: Encapsulation theorems
> Can a subsystem be encapsulated as a single
component?
• Often can be proved by “structural
induction” over the architectural structure
> Cf. Allen Thesis

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 83

 Proof Technique: Encapsulation

Configuration

Configuration

R-S

Component Component
• Any component property is configuration property
• Induction on Component
> Component + component component
• Induction on Connector
> Component + connector component

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 84

 Style Analysis: Specialization

• Specialization (implication): is one style a

“substyle” of another?
• Key issue: Do the constraints imposed by
one style imply those of another?
• Important because all theorems about one
class of system hold for the other
• Examples:
> Pipeline as a specialization of Pipe & Filter
> Message passing with real-time constraints as a
specialization of general message passing style

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 85

 Style Analysis: Translation

• Inter-style translation: How can you map a

system defined in one arch style to
another?
• Important because the most natural
architectural description may not be
directly implementable.
• Moriconi has investigated translation
“patterns” and proofs of correctness
Style 1

Style 2

Style 3

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 86

 Style Analysis: Selection

• Selection: What style is appropriate for a

given problem?
> Available analyses often determined by style
selection
> Appropriate styles may guide system
development
• Rules of thumb and good taste
> Garlan & Shaw book; Shaw & Clements
boxology paper
• Integration with requirements negotiation
> Style can clarify impact of requirements
(cf. Boehm’s win-win)

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 87

 Outline

• Introduction to Software Architecture

• Architectural Modeling
> Architectural structure and topology
> Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities & challenges

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 88

 Some ADLs at a Glance

• Acme: architectural tool integration

• Aesop: style-specific environments
• Armani: designing with constraints
• Darwin: distributed systems exo-structure
• Meta-H: real-time, fault-tolerant avionics
• Rapide: event patterns, arch simulation
• SADL: refinement patterns
• UniCon: architectural compilation
• Wright: protocol analysis

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 89

 Dimensions of Variability

• Most Architecture Description Languages

(ADLs) agree on use of structure
> Essentially as outlined earlier
• But they differ considerably about
> Kinds of properties that can be characterized
and analyzed
> Whether there is a fixed set of connector types
> Emphasis on static versus dynamic analysis
> Support for dynamism (runtime system
evolution)
> Executability
> Openness (ability to incorporate external tools)
> Domain specificity

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 90

 Meta-H (Honeywell)

• Key Idea: Domain-specific ADL for real-

time, fault-tolerant software
• Main features
> Analysis capabilities
» Real-time schedulability analysis
» Reliability
» Safety/security
> Accepts external generators, libraries
> Automated system builder
» provides runtime communication/synch support
> Integrates hardware and software components
> Applied with success in avionics domain

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 91

 Rapide

• Key Idea: Define system behavior using

event patterns that permit simulation and
post facto analysis
• Main features
> Behavioral modeling allows one to determine
erroneous or missing causal information
> Trace viewing capabilities
> Architectural animation
> Supports dynamic architectures
> Applications include X/Open architecture, TRW
applications

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 92

 Darwin

• Key idea: specify structure of distributed

systems
• Declarative binding language for defining
dynamically-evolving, hierarchical
compositions.
• Component interfaces defined in terms of
provided/required services
• Fixed set of connector types
• Semantics given in terms of Pi-Calculus
• Behavior of components specified outside
system
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 93
 Acme
• Key Idea: support ADL integration
• Integrate diverse ADLs and toolsets
> Leverage/integrate capabilities of different ADLs
> Minimize ADL translation effort
• Platform for ADL-independent tool development
> Tool writers can build one tool for many ADLs
> Tool developers don’t need to invent new ADLs to do
architectural analyses
> Rich library for constructing ACME tools reduces tool
development cost for ACME adopters
• Extensible language base for new ADLs
> Explore ADL ideas by extending ACME instead of
building a new ADL from scratch
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 94
 Acme

• Tools written to manipulate Acme

descriptions
• External tools can treat Acme as another
ADL toolset

Acme
Tools for Acme tool1
ADL-1 representation
Acme
tool2
Tools for
ADL-2 Acme
tooln

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 95

 Armani

• Extends Acme with composable and

reusable design constraints
> Captures both invariant and heuristic
constraints
» Constraints expressed in logic-based predicate
language.
» Both types and system instances can specify rich
constraint predicates
• Emerging tool support for constraint
checking
> Text-based language processing infrastructure
> GUI-based environment

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 96

 Aesop

• Key idea: support rapid development of custom,

style-specific software architecture design
environments.
• Configurable architecture design environment can
be specialized by loading style descriptions
> Minimizes environment development cost
> Exploits commonalties of families of systems
> Supports domain-specific arch analysis and code
generation
• Permits integration with external analysis tools
> Reuse legacy applications
> Integration with existing CASE tools
> Sample styles (and analysis):
» Pipe and Filter (code generation)
» Real-Time-Message Passing (schedulability)
» Generic (completeness and consistency checks)

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 97

 Generating
Style-Specific Environments

Style
Style
Description
Description
Environment
Environment
Aesop
Aesop For
ForThat
That
Generator
Generator Style
Style

Shared
Shared
Infrastructure
Infrastructure

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 98

 WRIGHT
• Support analysis of arch connection and style
• Explicit connector types
> Support reuse of:
» Patterns of interaction
» Components in multiple contexts of interaction
> Capture high-level composition abstractions
• Statically checkable behavior notation
> Capture dynamic communication ordering, non-
determinism, and locus of control
> Architectural consistency and completeness checks
(using model checking tools)
• Explicit description of style as constraints
> Leverage analysis over families of systems
> Proofs exploit architectural structure
> Check conformance of configuration to style
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 99
 UniCon

• Open system supports incremental definition and

compilation of heterogeneous architectures
• Heterogeneous abstractions
> Supports many types of connectors
> Supports many types of components
> Distinct modes of interaction, packaging
• Open System
> Accepts externally developed components, connector
types and analysis tools
• System construction emphasis
> Separates structure from implementation
> Compiles to std. connector implementations
> Incremental development
» Partial/incremental specifications
» open-ended semantics via property lists

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 100

 UniCon Component and Connector Types
• Abstractions for components
Computation pure function
SharedData Fortran common +
SeqFile unix file
Filter unix filter
Process unix process
SchedProcess real-time process
Module conventional compilation unit
• Abstractions for connectors
Pipe unix pipe
FileIO unix ops between process & file
ProcedureCall architectural use of proc
DataAccess shared data within process
RemoteProcCall RPC
RTScheduler processes compete for time
PLBundler set of procedure calls and data

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 101

 Outline

• Introduction to Software Architecture

• Architectural Modeling
> Architectural structure and topology
> Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities & challenges

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 102

 Three Ideas To Take Away

• Architecture description languages and

toolkits (ADLs) are useful for describing,
documenting, and reasoning about Software
Architectures.

• There are a number of interesting and useful

architecture-level analyses that can be
performed with existing ADLs and their
associated toolkits.

• There are further powerful analysis and

generation capabilities on the horizon.
Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 103
 Software Architecture
And Your Organization
• What are some of the difficulties of
transferring these ideas and capabilities
from research labs to real software
development organizations?
> Immature/research tools
> Lack of awareness/education
> Start-up costs to begin using tools & techniques
» … and to get first results
> Mismatch with current software development
processes and tools

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 104

 Software Architecture
And Your Organization
How to begin using software architecture
> Try to describe some portion or aspect of target
systems
» individual module(s) or subsystems
» single aspect or view across a whole system

> Ask simple questions and demand solid answers

» Rough modeling supports back-of-the envelope and simple
high-return analyses
» Even rough modeling reveals design discrepancies

> Implement an architectural review process

> Be willing to express analysis results in terms that

other team members can understand (no ’s)

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 105

 Research Opportunities

• Formal classification of architectures

> comprehensive enumeration of architectural
styles
> taxonomic relationships between architectural
styles

• Analytic basis for architectural selection

> capturing architects' expertise
> applying domain knowledge
• Mismatch: when the parts of a system
don't fit together as well as hoped for
> avoidance: guidance about when/why
problems are most likely to occur
> repair: what to do about it

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 106

 More Opportunities

• Architecture Description Languages (ADLs)

> Calculi for non-behavioral properties (e.g.,
reliability, performance, security)
> Dynamism (evolving architectures at runtime):
modeling, monitoring, constraining

• Multiple views
> How to combine different representations?

• Architectural interchange
> Canonical representations of architecture so that
different architectural tool sets can be integrated

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 107

 Major Trends in ADL Research

• ADL Integration
• Better system generation capabilities
• New and improved analysis capabilities
> reliability, performance, security
• Dynamism
> modeling, monitoring, constraining
• COTS-oriented styles and tools
• Views integration
• Better integration with other software
development tools/processes

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 108

 Web Sites of Interest

• CMU Composable Systems Group

> www.cs.cmu.edu/~Compose/

• CMU Architecture Based Languages and

Environments Research Group
> www.cs.cmu.edu/~able/

• The Acme ADL

> www.cs.cmu.edu/~acme/

• Worldwide Institute of Software Architects

> www.wwisa.org

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 109

 Web Sites of Interest (continued)

• The WRIGHT Language

> www.cs.cmu.edu/~able/wright/

• Meta-H For Real-Time Software Analysis

> www.htc.honeywell.com/projects/dssa/
dssa_tools/dssa_tools_mh.html

• Rapide ADL
> pavg.stanford.edu/rapide/

• C2 Project at UC Irvine
> www.ics.uci.edu/pub/arch/

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 110

 Web Sites of Interest (continued)

• SEI Product Line Practice Initiative

> www.sei.cmu.edu/plp/plp_init.html

• Tutorial slides:
> www.cs.cmu.edu/~able/talks_online/icse99_tutorial

Modeling & Analysis of Software Architecture ©1998 Robert T. Monroe 111