SFM 2003 Bertinoro, Italy David Garlan Carnegie Mellon University

1Software Architectures

© David Garlan

Formal Modeling and Analysis of

Software Architecture: Components,

Connectors, and EventsSFM 2003

Bertinoro, ItalyDavid Garlan

Carnegie Mellon University


© David Garlan

Examples of Architecture Descriptions


© 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


© David Garlan

The Problem

Requirements

Code

???How to bridge the gap between requirements and code?


© David Garlan

The Traditional Answer

Requirements

Code

A Miracle Happens!

Ad hoc Requires gurus Unpredictable Costly


© David Garlan

Software Development Methods

Increased predictability Some design guidanceBUT Limited applicability Still requires gurus Weak support for

design analysis

Requirements

Code

OOJSP SADT


© 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


© 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.


© 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


© 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 structures

e.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


© David Garlan

Example: Alternating Characters(Module View)

Produce alternating case of characters in a stream

main

split lower upper merge

config input/output

Definition/Use Modularization


© David Garlan

Example: Architectural Description(Component-and-Connector View)

split

lower

upper

merge

Components and Connectors


© 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


© 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


© David Garlan

Evolution of the FieldToday

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


© 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


© 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


© David Garlan

Taxonomy of Architectural Styles

Data FlowBatch sequentialDataflow network

(pipes&filters)acyclic, fanout, pipeline, Unix

Closed loop controlCall-and-return

Main program/subroutinesInformation hiding

ADT, object, naive client/serverInteracting processes

Communicating processesLW processes, distrib objects,

Event systemsimplicit invocation, pure events

Data-oriented repositoryTransactional databases

True client/serverBlackboardModern compiler

Data-sharingCompound documentsHypertextFortran COMMONLW processes

HierarchicalLayered

Interpreter


© 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?


© David Garlan

Data Flow:Pipes and Filters

Couple Acquire To-XY Clip

Measure

SignalWaveform Trace

Measurement

Dataflowpipe

filterComputation


© 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.


© David Garlan

Data Oriented Repository:Blackboard

Blackboard (shared

data)

ks1 ks2

ks3

ks4

ks5ks6

ks7

ks8

Direct access Computation

Memory


© 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


© 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

op op op

op op

op op

op

op

opopop

op

op


© 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


© David Garlan

Loosely Coupled Components:Publish-Subscribe

!!

! !!

!

!

?

?

???

??

Publish-Subscribe

Object or Process


© 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.


© David Garlan

Tiers:3-Tiered Client Server

Client-Server

Client-Server

Databases

BusinessLogic

Users


© 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


© 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


© 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


© David Garlan

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(4) exploit patterns and styles

without unnecessary proliferation and isolation of new design languages and tools


© 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


© David Garlan

Tool Support for Architectural Design

ArchitecturalDesign

Tool Tool Tool

Designer

???? ? ?

Tools:compatability

checkerreal-time

analyseretc...


© David Garlan

Example Environment: C2


© David Garlan

Example Environment: Meta-H


© David Garlan

Example Environment: Aesop/PF


© David Garlan

Example Environment: ObjecTime


© 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


© 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


© 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


© David Garlan

Modeling Architectural Structure

connector

component

system

roleport


© David Garlan

Acme Structural SyntaxSystem 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


© 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 ...


© David Garlan

Acme Property SyntaxSystem 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


© David Garlan

Substructure

Provide hierarchical element abstractions Can represent sub-architectures or “views”

Component Representation

Configuration

AbstractionMap

System(sub-architecture)

...

...

...

...


© 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


© David Garlan

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 typesProperty Type pointT = record [x:int; y:int];Property Type messagesT = seq<string>;Property Type Wright-specT = string;

Property msgs : messagesT = <“start”, “stop”>;


© David Garlan

Styles/Families Example

Family pipeFilterFam = {Component Type filterT = {…}Connector Type pipeT = {…}Connector Template

mkPipe(in:Port,out:Port)={…}; …}System pf : pipeFilterFam = {…}


© 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


© 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


© 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;}


© 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));

… };


© 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


© 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


© David Garlan

Demo of MDS and Acme Studio

SFM 2003 Bertinoro, Italy David Garlan Carnegie Mellon University

Documents