1Software Architectures
© David Garlan
Formal Modeling and Analysis of
Software Architecture: Components,
Connectors, and Events
SFM 2003Bertinoro, Italy
David GarlanCarnegie Mellon University
8Software Architectures
© David Garlan
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
9Software Architectures
© David Garlan
The Problem
Requirements
Code
???
How to bridge the gap between requirements and code?
10Software Architectures
© David Garlan
The Traditional Answer
Requirements
Code
A Miracle Happens!
Ad hoc Requires
gurus Unpredictable Costly
11Software Architectures
© David Garlan
Software Development Methods
Increased predictability Some design guidanceBUT Limited applicability Still requires gurus Weak support for
design analysis
Requirements
Code
OOJSP SADT
12Software Architectures
© David Garlan
The Role of Software Architecture
Code
Software Architecture
Composition of large-scale components
System-level abstractions
Reuse of system-level design idioms
Requirements
13Software Architectures
© David Garlan
Definitions of Software Architecture
Many definitions Here is a typical one
But what structures? What is “behavior”? What kinds of relationships?
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.
14Software Architectures
© David Garlan
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 design idioms and styles
15Software Architectures
© David Garlan
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 structures: physical/resources structurese.g., processors , networks
Run-time structures: system structure and behavior at run timee.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 Run-time good for reasoning about system behavior
In this lecture I will focus on run-time structures
16Software Architectures
© David Garlan
Example: Alternating Characters(Module View)
Produce alternating case of characters in a stream
mainmain
splitsplit lowerlower upperupper mergemerge
configconfig input/outputinput/output
Definition/Use Modularization
17Software Architectures
© David Garlan
Example: Architectural Description(Component-and-Connector View)
splitsplit
lowerlower
upperupper
mergemerge
Components and Connectors
18Software Architectures
© David Garlan
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
19Software Architectures
© David Garlan
Software Architecture in Context
2000
1980
1950
1970
1990
1960
Programming-any-which-way
Programming-in-the-small
Programming-in-the-large
Programming-in-the-world
Software architecture
NATO SE conference
Programming-in-the-large
Software development environments
Subroutines
Separate compilation
Integrated product linesComponent-based systems
Information hiding
InheritanceAbstract data types objects
PackagesPipes and filters
20Software Architectures
© David Garlan
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
and analyze key aspects of software architecture
21Software Architectures
© David Garlan
The architecture of an individual system identifies its principle Components: define the locus of computation
Examples: filters, databases, objects, ADTs Connectors: mediate interactions of
componentsExamples: procedure call, pipes, event broadcast
Properties: specify information for construction & analysisExamples: signatures, pre/post conditions, RT specs, protocols, performance attributes
Elements of Architectural Descriptions: Systems
22Software Architectures
© David Garlan
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, includingtopological rulesinterface standardsrequired properties
Note: relationship between architectural styles and system instances is similar to that between types and instances
23Software Architectures
© David Garlan
Taxonomy of Architectural Styles
Data FlowBatch sequentialDataflow network
(pipes&filters)acyclic, fanout, pipeline, Unix
Closed loop control
Call-and-returnMain program/subroutinesInformation hiding
ADT, object, naive client/server
Interacting processesCommunicating processes
LW processes, distrib objects, Event systems
implicit invocation, pure events
Data-oriented repositoryTransactional databases
True client/server
BlackboardModern compiler
Data-sharingCompound documentsHypertextFortran COMMONLW processes
HierarchicalLayered
Interpreter
24Software Architectures
© David Garlan
Styles: Questions to Address
System Model What 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 kinds of analysis does the style support?
25Software Architectures
© David Garlan
Data Flow:Pipes and Filters
Couple Acquire To-XY Clip
Measure
SignalWaveform Trace
Measurement
Dataflowpipe
filterComputation
26Software Architectures
© David Garlan
Pipes and Filters
Filter Incrementally transform some amount of the data
at inputs to data at outputsStream-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 composition; additive latencies; etc.
27Software Architectures
© David Garlan
Data Oriented Repository:Blackboard
Blackboard (shared
data)
ks1 ks2
ks3
ks4
ks5ks6
ks7
ks8
Direct access Computation
Memory
28Software Architectures
© David Garlan
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
29Software Architectures
© David Garlan
Call-Return:Object-Oriented
Proc call
ADTManager
obj is a manager
op is an invocation
obj
obj
obj
obj
obj
obj
objobj
opop
opop
op
opop
opop
op
op
opop
op
op
op
30Software Architectures
© David Garlan
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
31Software Architectures
© David Garlan
Loosely Coupled Components:Publish-Subscribe
!!
! !!
!
!
?
?
???
??
Publish-Subscribe
Object or Process
32Software Architectures
© David Garlan
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.
33Software Architectures
© David Garlan
Tiers:3-Tiered Client Server
Client-Server
Client-Server
Databases
BusinessLogic
Users
34Software Architectures
© David Garlan
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 called a product line architecture
35Software Architectures
© David Garlan
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
36Software Architectures
© David Garlan
The Challenge for Architectural Description
Software Architecture frees us from the limitations of programming language abstractions new kinds of components
not just abstract data types, modules, and objects new kinds of glue (connectors)
not just procedure call, data sharing new patterns, idioms, styles for system structure
not just for algorithms and data structure many properties of interest
not just functional behavior
37Software Architectures
© David Garlan
How can we establish intellectual control over this new world? Ideally we would like to:
(1) express arch descriptions precisely and intuitivelyboth syntax and semantics
(2) develop soundness criteria & tools to check themwhat type checkers and linkers do for current systems
(3) analyze architectures to determine key propertiessuch as performance, reliability, change impact, interoperability
(4) exploit patterns and styleswithout unnecessary proliferation and isolation of new design
languages and tools
38Software Architectures
© David Garlan
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
ExamplesRapide events with simulation and animation UniCon emphasizing heterogeneity and compilationWright formal specification of connector
interactionsAesop style-specific arch design languagesDarwin service-oriented architecturesSADL SRI language emphasizing refinementMeta-H arch description for avionics domainC-2 arch style using implicit invocation
39Software Architectures
© David Garlan
Tool Support for Architectural Design
ArchitecturalDesign
Tool Tool Tool
Designer
???? ? ?
Tools:
compatability checker
real-time analyser
etc...
44Software Architectures
© David Garlan
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, reliability, etc.
Support for architectural styles reusable architectural patterns
45Software Architectures
© David Garlan
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
46Software Architectures
© David Garlan
Acme: Modeling Architectural Structure
Components computational elements
Ports interface points for components
Connectors interactions between components
Roles interface points for connectors
Systems graphs of component and connectors
47Software Architectures
© David Garlan
Modeling Architectural Structure
connector
component
system
roleport
48Software Architectures
© David Garlan
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; }}
client server
49Software Architectures
© David Garlan
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 system-wide propertiesOverall system performance, reliability, security, etc.
Behaviorcomputations of componentsprotocols of connectors
Many forms and notations for semantics property lists protocol specifications type systems ...
50Software Architectures
© David Garlan
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”; };…};
client server
51Software Architectures
© David Garlan
Substructure
Provide hierarchical element abstractions
Can represent sub-architectures or “views”
Component Representation
Configuration
AbstractionMap
System(sub-architecture)
...
...
...
...
52Software Architectures
© David Garlan
Types and Styles
Types Define a collection of related architectural elements Subtyping and (multiple) inheritance Formally, a type is just a predicate Examples: filter component, pipe-connector, client-
server connector, dataflow-input-port Styles (called “Families” in Acme)
A collection of types and a set of constraints Types determine the “vocabulary” of the style Constraints determine how that vocabulary can be
used Can be viewed as a type of a system Example: pipe-filter family, client-server family
53Software Architectures
© David Garlan
Element and Property Types
Examples of component typesComponent Type filterT = { Ports {in,out} };
Component Type unixFilterT = filterT
extended with{ Port error;
Property throughput : int; };
Examples of property typesProperty Type pointT = record [x:int; y:int];Property Type messagesT = seq<string>;Property Type Wright-specT = string;
Property msgs : messagesT = <“start”, “stop”>;
54Software Architectures
© David Garlan
Styles/Families
Example
Family pipeFilterFam = {Component Type filterT = {…}Connector Type pipeT = {…}Connector Template
mkPipe(in:Port,out:Port)={…}; …}System pf : pipeFilterFam = {…}
55Software Architectures
© David Garlan
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
56Software Architectures
© David Garlan
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 flavors: Invariants and Heuristics
57Software Architectures
© David Garlan
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;}
58Software Architectures
© David Garlan
Example: Constraining a System
System simpleCS = { …
// simple rule requiring a primary serverInvariant exists c : server in self.components |
c.isPrimaryServer == true;
// simple performance heuristicHeuristic forall s : server in self.components |
s.transactionRate >= 100;
// do not allow client-client connectionsFunction no-peer-connections(sys : System) =
forall c1, c2 in sys.components | connected(c1, c2) ->
!(declaresType(c1,clientT) and declaresType(c2, clientT));
… };
59Software Architectures
© David Garlan
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
60Software Architectures
© David Garlan
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