Modeling and Analysis
of Software Architecture
Robert T. Monroe
Carnegie Mellon University
5000 Forbes Ave.
Pittsburgh, PA 15213
bmonroe@cs.cmu.edu
Modeling & Analysis of Software Architecture
FreeMarkets Corp.
One Oliver Plaza
Pittsburgh, PA 15222
bmonroe@freemarkets.com
©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
structural properties
declarative
mostly static
system-level performance
outside module boundary
composition of subsystems
Modeling & Analysis of Software Architecture
implementations of parts
computational properties
operational
mostly dynamic
algorithmic performance
inside module boundary
copy code or call libraries
©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
review document (6%)
update document (6%)
test & debug (28%)
define/analyze change
(18%)
Requirements
Architecture
trace logic (23%)
Design
implement change (19%)
Code/Integ
• Clarify intentions
• Make decisions and
implications explicit
• Permit system-level
analysis
Modeling & Analysis of Software Architecture
Reduce maintenance
costs, directly and
indirectly
Test/Accept
Maintenance
©1998 Robert T. Monroe
11
Architectural Design Reviews
Planning and
Architecture Phase
Prospectus
Requirements
Discovery
Review
Architecture
High-Level
Design
Source:
Joe Maranzano
ATT Bell Labs
Modeling & Analysis of Software Architecture
Architecture
Review
©1998 Robert T. Monroe
Low-Level
Design
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
Characters
Alphabetizer
Index
Output
Alphabetized
Index
Output
Medium
Input
Medium
Advantage: Good performance
Modeling & Analysis of Software Architecture
©1998 Robert T. Monroe
16
KWIC: ADT Solution
Subprogram Call
System I/O
Master Control
Input
Output
Characters
Input
Medium
Circular Shift
Alphabetic
Shifts
Advantage: Information hiding
simplifies implementation changes.
Modeling & Analysis of Software Architecture
©1998 Robert T. Monroe
Output
Medium
17
KWIC: Event Solution
Implicit Invocation
Subprogram Call
System I/O
Input
Input
Medium
Master Control
Circular
Shift
Lines
Alphabetizer
Lines
Output
Output
Medium
Advantage: Tool separation supports function enhancements.
Modeling & Analysis of Software Architecture
©1998 Robert T. Monroe
18
KWIC: Dataflow Solution
Input
Medium
Circular
Shift
Input
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
Modeling & Analysis of Software Architecture
role
©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; … };
Component Type ServerT = { Port receiveReq; … };
Connector Type RPCT = { Roles {caller; callee}; … };
System SimpleClientServer = {
Component viewer : ClientT;
Component database : ServerT;
Connector conn : RPCT;
Attachments = {
viewer.sendReq to conn.caller;
viewer.receiveReq to conn.callee;
};
};
Topology
Description
Design
Vocabulary
System
Description
viewer
database
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 subarchitecture
Configuration
Component Representations
...
if(x>0)
{
write(out);
x--;
}
Source
code
Modeling & Analysis of Software Architecture
...
...
...
...
Formal
specification
Configuration
(sub-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>
Computation <provide world model>
Component VehicleModel
Port Environment <value protocol>
Computation <Vehicle behavior>
Connector UpdateValues(n : 1.. )
Role Model1..n <1 model’s protocol>
Glue <data from one model to another>
Instances
Envt : WorldModel(<map>)
V : VehicleModel
Cn : UpdateValues(2)
Attachments
Envt.Provide as Cn.Model1
V.Environment as Cn.Model2
Component
types
Connector
types
Instances
Attachments
Envt
V
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  Operate
 close 
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  Operate
 close 
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  Operate
 close  §
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  Operate
 close  §
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  Operate
 close  §
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
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
Server
Server
Incomplete!
Modeling & Analysis of Software Architecture
Client
Client
Server
Complete
©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
Modeling & Analysis of Software Architecture
Abs
©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?
• Will the average response
time meet requirements?
• How large should the
buffers be?
• Highest demand the
servers can handle?
• Which component is the
bottleneck?
• How would server/database
replication affect this?
Modeling & Analysis of Software Architecture
infectious-diseases-ui
©1998 Robert T. Monroe
microbiology-ui
i-ui
m-ui
trend-tracker
microbiology-db
p-ui
simple-server
p-db-2
m-db-2
pharmacy-ui
m-db-1
p-db-1
pharmacy-db
Hospital MIS System
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
performance properties by:
infectious-diseases-ui
> Simulation
> Guesstimate
> Measured values
microbiology-ui
i-ui
m-ui
trend-tracker
Component microbiology-db = {
Ports {…};
Property localPerformance = [
replication = 2;
serviceTime = 1000ms;
outputMessagePaths = […];
];
Property computedPerformance = [
…?
];
};
Modeling & Analysis of Software Architecture
microbiology-db
p-ui
simple-server
p-db-2
m-db-2
pharmacy-ui
m-db-1
p-db-1
pharmacy-db
Hospital MIS System
©1998 Robert T. Monroe
60
QN Example: Emergent Global Properties
System hospitalMIS = { …
Property systemPerformance = [
avgResponseTime = 2784ms;
avgSystemMsgs = 2.342; ];
Component microbiology-db = {
Ports {…};
Property localPerformance = […];
Property computedPerformance = [
avgResponseTime = 2143ms;
avgQueueLength = 0.923;
avgUtilization = 0.48;
overloaded = false;
]; };
};
Modeling & Analysis of Software Architecture
infectious-diseases-ui
microbiology-ui
i-ui
m-ui
trend-tracker
microbiology-db
p-ui
simple-server
p-db-2
m-db-2
pharmacy-ui
m-db-1
p-db-1
pharmacy-db
Hospital MIS System
Tool computes system-wide
performance properties
based on configuration
©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
R1
...
R2
R2
Rn
...
Rn
n
Rsys   Ri
i 1
Serial Composition
Modeling & Analysis of Software Architecture
n
Rsys  1   1  Ri 
i 1
Parallel Composition
©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*
client machine
WWW Server
Java Client
2 failures/1000h
10
100%
Database A
Database A
Database A
3
1
2
2  31 2
server 
2
4
client  10
88.7%
80.3%
75%
72.6%
65.7%
59.5%
50%
25%
0%
1
2
3
4
5
Number of clients
system  server  nclient ( for n  0)
Modeling & Analysis of Software Architecture
Overall System Reliability
(after 10 hours)
server machine
©1998 Robert T. Monroe
* Example borrowed
from [AbdAllah97]
65
Analysis: Evaluating Design Choices
Memory
Should you use a
database?
file system?
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:
Domain
Translator
Wrapper
Internal
Object
C2 Component
Dialog &
Constraints
• Primary Connector Type: Message Bus
> Transports messages between components
> Supports multiple distribution and filtering policies
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
S-R
R-S
• 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
Outi.send  Si+1, when 1is
Si = 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 realtime, 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
Tools for
ADL-1
Acme
representation
Acme
tool1
Acme
tool2
Tools for
ADL-2
Modeling & Analysis of Software Architecture
Acme
tooln
©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
Description
Aesop
Generator
Environment
For That
Style
Shared
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, nondeterminism, 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
SharedData
SeqFile
Filter
Process
SchedProcess
Module
pure function
Fortran common +
unix file
unix filter
unix process
real-time process
conventional compilation unit
• Abstractions for connectors
Pipe
FileIO
ProcedureCall
DataAccess
RemoteProcCall
RTScheduler
PLBundler
Modeling & Analysis of Software Architecture
unix pipe
unix ops between process & file
architectural use of proc
shared data within process
RPC
processes compete for time
set of procedure calls and data
©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