Transcript Overview
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