Formal Modeling and Analysis
of Software Architecture:
Components, Connectors, and
Events
SFM 2003
Bertinoro, Italy
David Garlan
Carnegie Mellon University
Software Architectures
© David Garlan
1
Examples of Architecture Descriptions
Software Architectures
© David Garlan
2
Talk Outline
Part
1: Overview of Software Architecture
 What
is software architecture?
 What are essential architectural concepts?
Part
2: Modeling and Analysis
 Formal
representations of architecture
 Formal analysis and model checking of
architectures
 UML
Part
3: Frontiers
 Ubiquitous
computing
 Mobility
 Two-tiered
methods (MDA)
 Others
Software Architectures
© David Garlan
8
The Problem
Requirements
How to bridge the
gap between
requirements and
code?
???
Code
Software Architectures
© David Garlan
9
The Traditional Answer
Requirements
 Ad
A Miracle Happens!
hoc
 Requires gurus
 Unpredictable
 Costly
Code
Software Architectures
© David Garlan
10
Software Development Methods
Requirements
 Increased
JSP
SADT
OO
Code
Software Architectures
© David Garlan
predictability
 Some design
guidance
BUT
 Limited applicability
 Still requires gurus
 Weak support for
design analysis
11
The Role of Software Architecture
Requirements
 Composition
large-scale
components
 System-level
abstractions
 Reuse of
system-level
design idioms
Software Architecture
Code
Software Architectures
of
© David Garlan
12
Definitions of Software Architecture
 Many
definitions
 Here is a typical one
A software architecture for a system is the
structure or structures of the system, which
comprise elements, their externally-visible
behavior, and the relationships among them.
 But
what structures? What is “behavior”? What
kinds of relationships?
Software Architectures
© David Garlan
13
Issues Addressed by
an Architectural Design
 Gross
decomposition of a system into interacting
components
 typically
hierarchical
 using rich abstractions for component interaction
(or system “glue”)
 often using common design idioms/styles
 Emergent
system properties
 performance,
throughput, latencies
 reliability, security, fault tolerance, evolvability
 Rationale
and assignment of function to
components
 relates
requirements and implementations
 Envelope
of allowed change
 “load-bearing
walls”, limits of scalability and adaptation
Software Architectures
 design idioms and styles
© David Garlan
14
Many Views of Architecture

There are many possible views of software
systems
 Module
structures: code/implementation structures
e.g.,
class diagrams, work breakdown structures, “def-use”
graphs
 Deployment
e.g.,
structures: physical/resources structures
processors , networks
 Run-time
structures: system structure and behavior at
run time
e.g.,
clients, servers, databases, instances of objects
 Each
has its purpose in understanding the
overall nature of a system
 Modules
good for reasoning about maintenance
 Deployment good for reasoning about resources
Software Architectures
© David Garlan
 Run-time good for reasoning
about system behavior
15
Example: Alternating Characters
(Module View)
Produce alternating case of characters in a stream
main
split
lower
upper
config
merge
input/output
Definition/Use Modularization
Software Architectures
© David Garlan
16
Example: Architectural Description
(Component-and-Connector View)
lower
split
merge
upper
Components and Connectors
Software Architectures
© David Garlan
17
Why Formalize Software Architecture?
 Understanding
 Precise
definition of system
 Clarification of requirements
 Analysis
 System-level analysis of critical properties
 Construction
 Blueprint for construction; basis for code
generation
 Identify opportunities for reuse
 Evolution
 Define allowable envelope of change, ensure that
system invariants are not violated
Software Architectures
© David Garlan
18
Software Architecture in Context
Integrated product lines
Component-based systems
2000
Software architecture
Packages
Pipes and filters
Software development environments
Inheritance
1980
Abstract data types objects
Programming-in-the-large
Information hiding
NATO SE conference 1970
Separate compilation
Subroutines
1950
Software Architectures
1960
1990
Programmingin-the-world
Programmingin-the-large
Programming
-in-the-small
Programmingany-which-way
© David Garlan
19
Evolution of the Field
Today
 Recognition
of the value of architects in software
development organizations
 Processes that require architectural design reviews
and explicit architectural documentation
 Emerging use of product line architectures,
commercial architectural standards, component
integration frameworks
 Codification of vocabulary, notations & tools for
architectural design
 Books/courses on software architecture
 Unfortunately
 Little
use of formal models, tools, analyses
 Many gaps in our understanding about how to model
Software Architectures
and analyze key aspects of software architecture
© David Garlan
20
Elements of Architectural
Descriptions: Systems
The
architecture of an individual system
identifies its principle
 Components:
define the locus of computation
Examples: filters, databases, objects, ADTs
 Connectors: mediate interactions of components
Examples: procedure call, pipes, event broadcast
 Properties: specify information for construction &
analysis
Examples: signatures, pre/post conditions, RT specs,
protocols, performance attributes
Software Architectures
© David Garlan
21
Elements of Architectural
Descriptions: Styles
An
architectural style defines a family of
architecture instances including
 Component/connector
types
 the vocabulary of architectural building blocks
 Constraints on how the building blocks can be
used, including
topological rules
interface standards
required properties
Note: relationship between architectural styles
and system instances is similar to that between
types and instances
Software Architectures
© David Garlan
22
Taxonomy of Architectural Styles
Data Flow
Data-oriented repository
Batch sequential
Dataflow network (pipes&filters)
Transactional databases
True client/server
acyclic, fanout, pipeline, Unix
Blackboard
Modern compiler
Closed loop control
Call-and-return
Data-sharing
Main program/subroutines
Information hiding
Compound documents
Hypertext
Fortran COMMON
LW processes
ADT, object, naive client/server
Interacting processes
Communicating processes
LW processes, distrib objects,
Hierarchical
Event systems
implicit invocation, pure events
Software Architectures
© David Garlan
Layered
Interpreter
23
Styles: Questions to Address
 System
 What
Model
is the overall organizational pattern?
 Structure
 What
are the basic components and connectors?
 What topologies are allowed?
 Computation
 What
is the underlying computational model?
 How is control and data transferred between
components?
 Properties
 Why
is this style useful?
 What kinds of properties are exposed?
 Analyses
 What
Software Architectures
kinds of analysis ©does
the style support?
David Garlan
24
Data Flow:
Pipes and Filters
Dataflow
Signal
Couple
Acquire
pipe
To-XY
Waveform
Computation
Software Architectures
Trace
Measure
filter
© David Garlan
Clip
Measurement
25
Pipes and Filters
 Filter
 Incrementally
transform some amount of the data at
inputs to data at outputs
Stream-to-stream
transformations
 Use
little local context in processing stream
 Preserve no state between instantiations
 Pipe
 Move
data from a filter output to a filter input
 Pipes form data transmission graphs
 Computational
Model
 Run
pipes and filters (non-deterministically) until no
more computations are possible.
 Analysis
 Functional
Software Architectures
composition; additive latencies; etc.
© David Garlan
26
Data Oriented Repository:
Blackboard
Direct access
ks2
ks1
Computation
ks3
ks8
Blackboard
(shared
data)
ks4
ks7
ks5
ks6
Software Architectures
© David Garlan
Memory
27
The Blackboard Model
 Knowledge
Sources
 World
and domain knowledge partitioned into separate,
independent computations
 Respond to changes in blackboard
 Blackboard
Data Structure
 Entire
state of problem solution
 Hierarchical, non-homogeneous
 Only means by which knowledge sources interact to yield
solution
 Computational
Model
 Changes
to data in blackboard by one knowledge source
trigger the actions of other knowledge sources to create
new blackboard data
Software Architectures
© David Garlan
28
Call-Return:
Object-Oriented
Manager ADT
obj
op
op
Proc call
obj
op
op
op
obj
op
op
op
obj
op
op is an invocation
Software Architectures
op
op
op
obj is a manager
op
op
obj
op
obj
obj
op
obj
© David Garlan
29
Call-Return Systems
 Objects
 Encapsulate
representations
 Provide interfaces to access services
 Connectors
 Call-return;
service invocation
 Computational
Model
 Services
requested from known service provider;
Requester blocks
 Analysis
 Correctness
of a component depends on correctness of
services it invokes
Software Architectures
© David Garlan
30
Loosely Coupled Components:
Publish-Subscribe
!
?
!
Object or Process
!
!
?
?
!
!
?
!
?
?
?
Publish-Subscribe
Software Architectures
© David Garlan
31
Publish-Subscribe
(Implicit Invocation)
 Components
 Objects,
processes
 Have a set of methods
 Announce (publish) events – via multicast
 Subscribe to events by associating a procedure to call
 Connectors
 Event
space (bus)
 Typically implemented as a dispatcher
 Computational
model
 When
an event is announced invoke associated
procedures (in any order)
 Correctness of a component should not depend on
correctness of components that subscribe to its
announced events.
Software Architectures
© David Garlan
32
Tiers:
3-Tiered Client Server
Users
Client-Server
Business
Logic
Client-Server
Databases
Software Architectures
© David Garlan
33
Many Others
 Often
styles are used in combination
 Example:
each layer might be different style internally
 Example: a component might have substructure
defined in a different style than its surrounding
 Many
styles are closely tied to specific domains -often by specializing a more generic style
 sometimes
called component integration frameworks
 N-tiered MIS Systems
 OSI Protocol Stack
 Instrumentation Systems
 In
many cases these are specialized to a
particular product family,
 sometimes
Software Architectures
called a product line architecture
© David Garlan
34
Talk Outline
Part
1: Overview of Software Architecture
 What
is software architecture?
 What are essential architectural concepts?
Part
2: Modeling and Analysis
 Formal
representations of architecture
 Formal analysis and model checking of
architectures
 UML
Part
3: Frontiers
 Ubiquitous
computing
 Mobility
 Two-tiered
methods (MDA)
 Others
Software Architectures
© David Garlan
35
The Challenge for
Architectural Description
 Software Architecture
frees us from the
limitations of programming language abstractions
 new
kinds of components
not
 new
kinds of glue (connectors)
not
 new
just abstract data types, modules, and objects
just procedure call, data sharing
patterns, idioms, styles for system structure
not
just for algorithms and data structure
 many
properties of interest
not
just functional behavior
Software Architectures
© David Garlan
36
 How
can we establish intellectual control over
this new world? Ideally we would like to:
(1) express arch descriptions precisely and
intuitively
both
syntax and semantics
(2) develop soundness criteria & tools to check
them
what
type checkers and linkers do for current systems
(3) analyze architectures to determine key
properties
such
as performance, reliability, change impact,
interoperability
Software Architectures
© David Garlan
37
Architecture Description Languages
 A number
of architecture description languages (ADLs) have
been developed that attempt to do this
 Each language and supporting tool set
 emphasizes
different aspect of architecture
 is good for some things; bad for others
 Examples
Rapide
UniCon
Wright
Aesop
Darwin
SADL
Meta-H
C-2
Software Architectures
events with simulation and animation
emphasizing heterogeneity and compilation
formal specification of connector interactions
style-specific arch design languages
service-oriented architectures
SRI language emphasizing refinement
arch description for avionics domain
arch style using implicit invocation
© David Garlan
38
Tool Support for Architectural Design
???
Designer
Tool
?
Tool
?
Tool
?
Architectural
Design
Tools:
compatability
checker
real-time
analyser
etc...
Software Architectures
© David Garlan
39
Example Environment: C2
Software Architectures
© David Garlan
40
Example Environment: Meta-H
Software Architectures
© David Garlan
41
Example Environment: Aesop/PF
Software Architectures
© David Garlan
42
Example Environment: ObjecTime
Software Architectures
© David Garlan
43
Features of Modern ADLs
 System
structure is defined separately from individual
components
 parts
are “context independent”
 supports hierarchical design
 New
kinds of connectors can often be defined
 need
not be realizable directly by a single primitive of
an implementation language
 have rich semantics
 Can
express/analyze extra-functional properties
 performance,
 Support
for architectural styles
 reusable
Software Architectures
reliability, etc.
architectural patterns
© David Garlan
44
Acme ADL
 A good
example of an ADL
 Originally designed as an interchange language
 Later became full-fledged ADL
 Attempts to provide open-ended approach for
architectural representation
 Like
XML for architecture
 We’ll
use that in the next few slides to illustrate
modeling techniques and tools
Software Architectures
© David Garlan
45
Acme:
Modeling Architectural Structure
 Components
 computational
elements
 Ports
 interface
points for components
 Connectors
 interactions
between components
 Roles
 interface
points for connectors
 Systems
 graphs
Software Architectures
of component and connectors
© David Garlan
46
Modeling Architectural Structure
system
connector
component
port
Software Architectures
role
© David Garlan
47
client
server
Acme Structural Syntax
System simple-cs = {
Component client = { port call-rpc; };
Component server = { port rpc-request; };
Connector rpc = {
role client-side;
role server-side;
};
Attachments = {
client.call-rpc to rpc.client-side;
server.rpc-request to rpc.server-side;
}
}
Software Architectures
© David Garlan
48
Beyond Simple Structure
 What
else can we represent besides structure?
 Local
component or connector properties
 Rates,
capacities, latencies, etc. for individual components and
connectors
 Emergent
 Overall
system-wide properties
system performance, reliability, security, etc.
 Behavior
 computations
 protocols
 Many
of components
of connectors
forms and notations for semantics
 property
lists
 protocol
specifications
 type
Software Architectures
systems ...
© David Garlan
49
client
server
Acme Property Syntax
System simple-cs = {
…
Component server = {
port rpc-request = {
Property sync-requests : boolean = true;
};
Property max-transactions-per-sec : int = 5;
Property max-clients-supported : int = 100;
};
Connector rpc = { …
Property protocol : string = “aix-rpc”;
};
…
};
Software Architectures
© David Garlan
50
Substructure
 Provide
 Can
hierarchical element abstractions
represent sub-architectures or “views”
Configuration
...
...
...
...
Abstraction
Map
System
(sub-architecture)
Component Representation
Software Architectures
© David Garlan
51
Types and Styles
 Types
 Define
a collection of related architectural elements
 Subtyping
 Formally,
and (multiple) inheritance
a type is just a predicate
 Examples:
filter component, pipe-connector, client-server
connector, dataflow-input-port
 Styles (called “Families” in Acme)
 A collection
 Types
determine the “vocabulary” of the style
 Constraints
 Can
determine how that vocabulary can be used
be viewed as a type of a system
 Example:
Software Architectures
of types and a set of constraints
pipe-filter family, client-server family
© David Garlan
52
Element and Property Types
 Examples of component types
Component Type filterT = { Ports {in,out} };
Component Type unixFilterT = filterT
extended with{ Port error;
Property throughput : int; };
 Examples
of property types
Property Type pointT = record [x:int; y:int];
Property Type messagesT = seq<string>;
Property Type Wright-specT = string;
Property msgs : messagesT = <“start”, “stop”>;
Software Architectures
© David Garlan
53
Styles/Families
 Example
Family pipeFilterFam = {
Component Type filterT = {…}
Connector Type pipeT = {…}
Connector Template
mkPipe(in:Port,out:Port)={…};
…}
System pf : pipeFilterFam = {…}
Software Architectures
© David Garlan
54
Constraints
 Architectural
documentation requires the ability to
say what aspects of a description are invariant.
 Examples
 Topology
 Properties
 Types
of elements
 Behavior of system
 Possible configurations during run-time
Software Architectures
© David Garlan
55
Acme Constraints
 First-order
predicate logic
 Standard
boolean operators and quantifiers
 With special built-in functions for architecture
 First
class in the following sense
 Explicitly
defined in an architectural description
 Checkable by tools
 Can be named
 Can be aggregated into larger units (e.g., styles)
 Unified
with overall type system
 A type
is simply a predicate
 A style (family) is simply the type of a system
 Similar in spirit to PVS
 Two
Software Architectures
flavors: Invariants and Heuristics
© David Garlan
56
Example: Defining a Component Type
Component Type naïve-client = {
Port Request = {
Property protocol = rpc-client };
Property request-rate : integer
<< default = 0; units = “rate-per-sec” >>;
Invariant forall p in self.Ports |
(p.protocol = rpc-client);
Invariant size(Ports) <= 5;
Invariant request-rate >= 0;
Heuristic request-rate <= 100;
}
Software Architectures
© David Garlan
57
Example: Constraining a System
System simpleCS = { …
// simple rule requiring a primary server
Invariant exists c : server in self.components |
c.isPrimaryServer == true;
// simple performance heuristic
Heuristic forall s : server in self.components |
s.transactionRate >= 100;
// do not allow client-client connections
Function no-peer-connections(sys : System) =
forall c1, c2 in sys.components |
connected(c1, c2) ->
!(declaresType(c1,clientT)
and declaresType(c2, clientT));
… };
Software Architectures
© David Garlan
58
Example: Defining an Architectural Style
Style naïve-client-server-style = {
// declare vocabulary
Component Type naïve-client = {...};
Component Type naïve-server = {...};
...
// declare design analyses
Function no-peer-connections(sys : System)
= { ... };
...
// declare style-wide design rules
Invariant no-peer-connections(self);
Heuristic forall s : server in self.components|
s.transactionRate >= 100;
...
} // end style definition
Software Architectures
© David Garlan
59
Larger Example and Demo
 NASA Mission
Data Systems (MDS)
 Architectural
style for NASA space software
 To be used in 2009 mission to Mars
 Primarily autonomous, mobile, robotics
 The
Style
 Components:
sensors, actuators, controllers
 Connectors: state query, submit command
 Constraints: over 39 constraints
 Analyses
and Tools
 Style
conformance
 Performance
 Code generation
Software Architectures
© David Garlan
60
Demo of MDS and Acme Studio
Software Architectures
© David Garlan
61