ICS 123

Software Architecture

ICS 123 Spring 2002

Richard N. Taylor and Eric M. Dashofy*
UC Irvine
http://www.isr.uci.edu/classes/ics123s02/

* with very special thanks to David S. Rosenblum for the use of his materials.
 Software Architecture
Topic 2
Software
Architecture
(Perry & Wolf 92)
ICS 123

“Architecture is concerned with the selection of

architectural elements, their interactions, and the
constraints on those elements and their interactions
necessary to provide a framework in which to satisfy
the requirements and serve as a basis for the
design.”
(vs. design…)
“Design is concerned with the modularization and
detailed interfaces of the design elements, their
algorithms and procedures, and the data types
needed to support the architecture and to satisfy the
requirements.”

2
 Software Architecture
Topic 2
Software
Architecture
(Garlan & Shaw 93)
ICS 123

“Software architecture is a level of design that goes

beyond the algorithms and data structures of the
computation; designing and specifying the overall
system structure emerges as a new kind of problem.
Structural issues include gross organization and
global control structure; protocols for
communication, synchronization, and data access;
assignment of functionality to design elements;
physical distribution; composition of design
elements; scaling and performance; and selection
among design alternatives.”

3
 Software Architecture
Topic 2
Software
Architecture
(Shaw & Garlan 96)
ICS 123

“The architecture of a software system defines that

system in terms of computational components and
interactions among those components. … In
addition to specifying the structure and topology of
the system, the architecture shows the
correspondence between the requirements and
elements of the constructed system, thereby
providing some rationale for the design decisions.”

4
 Analogies with
Topic 2
Software
Architecture
Civil Architecture
ICS 123
Civil Engineering and Civil Architecture
are concerned with the engineering and design of
civic structures (roads, buildings, bridges, etc.)
• Architecture vs. Construction
• Multiple views
– Civil: Artist renderings, elevations, floor plans, blueprints
– Software: Code, object design, boxes-and-arrows, GUI

• Architectural styles
– Civil: Classical, Romanesque, Gothic, Renaissance, Baroque, Art Deco
– Software: Pipe-and-filter, client/server, layered system

• Influence of style on engineering principle

• Influence of style on choice of materials
5
 Differences Between Civil
Topic 2
Software
Architecture
and Software Architecture
ICS 123

• Physical vs. conceptual

• Static vs. dynamic
• Little evolution vs. frequent evolution
• Different mathematical and scientific bases
• Different notions of “reuse”

6
 Elements of Software
Topic 2
Software
Architecture
Architecture
ICS 123

• Perry & Wolf

– Structural Elements
» Processing
» Data    This Class   
» Connecting (“glue”)
– Form: Weighted Properties and
Relationships
– Rationale • Components
• Connectors
• Shaw & Garlan: • Interfaces
– Components
– Interconnections • Configurations
– Rules of Composition •  (implies) Links
– Rules of Behavior

7
 Topic 2
Software
Architecture
Components
ICS 123

• A component is a building block that is …

– A unit of computation or a data store, with an interface specifying
the services it provides
– A unit of deployment
– A unit of reuse

8
 The Difference Between
Topic 2
Software
Architecture
Components and Objects
ICS 123

• Lifecycle
– Objects are created and destroyed constantly
– Components are created and destroyed infrequently
• Purpose of use
– Graphics toolkit (component) vs. graphics widget (object)
– Data store (component) vs. data structure (object)
• Type system
– Objects are instances of a class, with classes arranged in hierarchies according
to inheritance relationships
– Components may have their own type system (may be trivial), often very few
components of the same type
• Size
– Objects tend to be small
– Components can be small (one object) or large (a library of objects or a
complete application)

9
 Topic 2
Software
Architecture
Connectors
ICS 123

• A connector is a building block that enables

interaction among components
– Shared variables
– Procedure calls (local or remote)
– Messages and message buses
– Events
– Pipes
– Client/server middleware

• Connectors may be implicit or explicit

– Implicit: procedure calls
– Explicit: First-class message buses

10
 The Difference Between
Topic 2
Software
Architecture
Components and Connectors
ICS 123

• Task Performed
– Components focus on computational tasks
– Connectors focus on communication tasks

• Application Semantics
– Components generally implement most of the application semantics
– Connectors do not (they may change the form of the message, but do
not generally change its meaning)

• “Awareness”
– Components (should be) unaware of who is using them and for what
purpose
– Connectors are more aware of components connected to them so they
can better facilitate communication

Not everybody agrees on this!

11
 Topic 2
Software
Architecture
Interfaces
ICS 123

• An interface is the external “connection point” on a

component or connector that describes how other
components/connectors interact with it
• Provided and required interfaces are important
• Spectrum of interface specification
– Loosely specified (events go in, events go out)
– API style (list of functions)
– Very highly specified (event protocols across the interface in CSP)

• Interfaces are the key to component interoperability

(or lack thereof)

12
 Topic 2
Software
Architecture
Configurations
ICS 123

• A configuration is …
– The overall structure of a software architecture
– The topological arrangement of components and connectors
» Implies the existence of links among components/connectors
– A framework for checking for compatibility between interfaces,
communication protocols, semantics, …

• “If links had semantics, they’d be connectors.”

• Usually constructed according to an architectural
style

13
 Topic 2
Software
Architecture
Graphically…
ICS 123

Interfaces

Clock Component

Connector
Bus1

Interfaces

14
 Topic 2
Software
Architecture
Graphically (cont).
ICS 123

Clock Configuration

Links
Bus1

LCD
Driver

15
 Example:
Topic 2
Software
Architecture
Architectures for a Compiler
ICS 123

Semantic Code
Scanner Parser
Analyzer Generator

File File File

Semantic Code
Scanner Parser
Analyzer Generator

Parse Tree

Legend: Component Connector

16
 What does architecture buy
Topic 2
Software
Architecture
you?
ICS 123

• On its face, nothing!

• A bad architecture can imply a spaghetti code
system
– See “Big Ball of Mud,”
http://www.devcentre.org/mud/mudmain.htm

• How can we use architecture to improve the

qualities (-ilities) of our software systems?
• Answer: Architectural Styles

17
 Topic 2
Software
Architecture
Architectural Styles
ICS 123

• An architectural style is …
– A set of constraints you put on your development to elicit desirable
properties from your software architecture.
– These constraints may be:
» Topological
» Behavioral
» Communication-oriented
» etc. etc.
– Working within an architectural style makes development harder
– BUT architectural styles help you get beneficial system properties that
would be really hard to get otherwise

18
 The Classical Style of Civil
Topic 2
Software
Architecture
Architecture
ICS 123

The Pantheon
Rome, Italy
19
 Topic 2
Software
Architecture
The Gothic Style
ICS 123

Nôtre-Dame Cathedral
Paris, France
20
 Topic 2
Software
Architecture
The Mediterranean Style
ICS 123

Irvine, California

21
 Topic 2
Common Software Architectural Software
Architecture
Styles (Shaw & Garlan 96)
ICS 123

• Dataflow Systems
– Batch sequential
– Pipes and filters

• Call-and-Return Systems
– Main program and subroutines
– Object-oriented systems
– Hierarchical layers (onion layers)

• Independent Components
– Communicating processes (client/server and peer-to-peer)
– Event systems
– Implicit invocation

22
 Common Software
Topic 2
Software
Architecture
Architectural Styles (Cont.)
ICS 123

• Virtual Machines
– Interpreters
– Rule-based systems

• Data-Centered Systems (Repositories)

– Databases
– Hypertext systems
– Blackboards

23
 Topic 2
Software
Architecture
Pipe and Filter Example
ICS 123

• You, too, are a software architect!

• ls –l *.java | grep “foobar” | lpr –P gaston
– Components: Filters
– Connectors: Stream-based pipes
– Interfaces: One in, one out on each pipe or filter, exchange byte
streams
– Links: Implicit in above command line
– Configuration: Specified by ordering on the command line

24
 Topic 2
Software
Architecture
Pipe & Filter Constraints
ICS 123

• All communication via byte streams

• One “in,” one “out” interface on each component
• Only connectors are pipes
• A pipe is mandatory between each pair of sequential
filters
• Filters must be ordered sequentially, starting and
ending with a filter

• What software qualities are brought out by this

style?
25
 Topic 2
Software
Architecture
Pipe & Filter Qualities
ICS 123

• Configurability: Any set of filters may be combined in any

order
– Although reasonable semantics are not guaranteed by this style

• Efficiency: All data does not have to be processed for the

next filter to start working
• Customizability: Filters can be easily inserted, removed into
the software architecture
• Domain-specific: Works very well for text-processing
problems.

26
 The Vision: Architecture- Topic 2
Software
Architecture
Based Composition & Reuse
ICS 123

• A framework for design and implementation of

large-scale software systems
• A basis for early analysis of software system
properties
• A framework for selection and composition of
reusable off-the-shelf components
• A basis for controlled evolution of software
• A basis for runtime evolution of software

27
 The Reality: Topic 2
Software
Architecture
Architectural Mismatch
ICS 123

• Architectural mismatch refers to a mismatch

between assumptions made by different components
about the structure of the system and the nature of
the environment in which they operate
• Assumptions about the nature of the components
– substrate on which a component is built
– control model
– data model

• Assumptions about the nature of the connectors

– protocols
– data model

28
 Architectural Mismatch
Topic 2
Software
Architecture
(Cont.)
ICS 123

• Assumptions about the global configuration

– topology
– presence of certain components or connectors
– absence of certain components or connectors

• Assumptions about the system construction process

– order in which elements are instantiated
– order in which elements are combined

• Assumptions about the operating environment

– Threading concerns
– Availability or characteristics of lower-level functionality (OS-level,
network)

29
 Topic 2
Software
Architecture
Standards: The Solution?
ICS 123

• Standards define a set of “assumptions” that all

components must adhere to
– Component interface standards (e.g., JavaBeans, ActiveX, Netscape
Plug-in API)
– Component interoperability standards (e.g., CORBA, DCOM, Java RMI)
– Standard component frameworks (e.g., Microsoft Foundation Classes)

• But standards also reduce design flexibility

30
 More Reality: Topic 2
Software
Architecture
“Architectural Drift”
ICS 123
• How are architectures implemented now?
Python 1.5.2 (#1, Apr 18 1999,
16:03:16) Copyright 1991-1995
Stichting Mathematisch Centrum,
Amsterdam >>> import asynchat #
create an instance >>> channel =
asynchat.async_chat() # access to
attributes from an instance >>>
channel.ac_in_buffer '' >>>
channel.ac_in_buffer_size 4096 # now
let's look at the name spaces >>>
channel.__dict__['ac_in_buffer'] ''
>>>
channel.__dict__['ac_in_buffer_size'
] Traceback (innermost last): File
"<pyshell#11>", line 1, in ?
channel.__dict__['ac_in_buffer_size'
] KeyError: ac_in_buffer_size # not
found in the instance's namespace! #
check the class namespace >>>
asynchat.async_chat.ac_in_buffer_siz
e 4096

Brilliant Software Semi-Cohesive Incomprehensible

Architecture Object Design in UML Python Code

31
 Topic 2
Software
Architecture
Why does drift happen?
ICS 123

• Eventually, software must become code

– Programming languages and operating systems provide poor support
for entities at the architecture level of abstraction

• Induces “architectural drift” (Garlan & Allen)

– As the system gets built and (especially) maintained, the system drifts
further away from its original intended design/architecture
– Increases software costs and failures dramatically

32
 Topic 2
Software
Architecture
Solutions for Drift
ICS 123

• Maintain a persistent view of architecture at

implementation time
• Co-evolve requirements and architecture
• Use architecture as the basis for:
– System Design
– Maintenance
– System evolution
– Deployment

• Much of this is still “research!”

33
 ICS 123

Architecture Tools and

“Real” Technologies

ICS 123
Richard N. Taylor and Eric M. Dashofy
UC Irvine
http://www.isr.uci.edu/classes/ics123s02/
 Topic 2
Software
Architecture
Overview
ICS 123

• Architecture-centric Development Environments

– ArchStudio

• Architecture Description Languages

– xADL 2.0

• Architecture Frameworks
– c2.fw and others

35
 Topic 2
Software
Architecture
The Vision
ICS 123

• Architecture-driven Software Development

– Architecture as the primary abstraction for design
– The architecture is defined very early in the development cycle
(possibly in parallel with the requirements)
– The architecture persists into the implementation and maintenance
phases of development

• Gap analysis: how do we get there from here?

– Ways to represent, manipulate, and visualize architectures
– Tool support for designing, implementing and evolving architectures
– Development of Architecture-centric Development Environments
» Think “Visual Studio” but for architectures, rather than code

Can you name some tools that would go in a

{code-based/architecture-based} environment?
36
 Contrast: IDE vs.
Topic 2
Software
Architecture
Architecture-based DE
ICS 123
Code-based IDE Tools: Architecture-based Tools:
•Text editor •Visual Editor
•GUI Builder •Composition assistants
•Compiler •Code generator
•Debugger •Instantiation & Evolution
Management
•Static Analysis Tools
•Various analysis tools
•Project Management
•Style-specific constraint
•Source file configuration
management
management
•Component-based
37 configuration management
 Topic 2
Software
Architecture
ArchStudio
ICS 123

• ArchStudio is an extensible architecture-centric

development environment
– Tools within the environment have special support for the C2
architectural style
– The environment itself is built in the C2 style
• ArchStudio Tools (integrated in various versions):
– Editors (visual, syntax-directed, and command-line)
– Analysis tools (static & dynamic analysis, design critics)
– Off-the-shelf integrations
» Code-based IDEs (Eclipse, Metamata, etc.)
» OOAD tools (Rational Rose)
» Hypermedia systems (Browsers, Chimera)
– And more…

38
 Holds architecture descriptions Topic 2
Software

ArchStudio 3 Today
Architecture

ICS 123
Manages open issues

Critics watch architecture for problems

Manages design critics

Architecture-to-implementation mappings

GUIs for various high-level tools

Graphical and syntax-directed editors

39
Manages open files and tools
 Architecture Description
Topic 2
Software
Architecture
Languages
ICS 123

• How do we “write down” a software architecture?

• An architecture description language (or architecture
definition language, or ADL) is a formal notation for
describing the structure and behavior of a software
architecture
• ADLs provide
– a concrete syntax
– a formal semantics
– a conceptual framework
– for explicitly modeling the conceptual architecture of a system
• Contrast with programming languages, which define
the implementation of a system

40
 What Goes in a Software
Topic 2
Software
Architecture
Architecture Description?
ICS 123

• From Medvidovic and Taylor, 2000:

– “An ADL must explicitly model components, connectors, and their
configurations; furthermore, to be truly usable and useful, it must provide tool
support for architecture-based development and evolution. These four
elements of an ADL are further broken down into constituent parts.”
– “In order to infer any kind of information about an architecture, at a minimum,
interfaces of constituent components must also be modeled. Without this
information, an architectural description becomes but a collection of
(interconnected) identifiers, similar to a “boxes and lines” diagram with no
explicit underlying semantics.”

What else would you model about a software

system you were designing?

41
 What people have put in
Topic 2
Software
Architecture
their descriptions
ICS 123

Distribute Product
d Systems Families Behaviora
l
Events Properties
Implementatio
n Mappings
Configuration
Management

Dynamic
Mobile,
Systems Dynamic
Architectures

42
 Topic 2
Software
Architecture
What really goes in an ADL?
ICS 123

• “There is, however, still little consensus in the

research community on what an ADL is, what
aspects of an architecture should be modeled by an
ADL…”
• This can be a good thing!
– Model only what you will find useful.
– Model things that your tools can work with or analyze.
– Model critical aspects of your software system in more detail.
• This can be a bad thing!
– Limits on architectural interchange.
– Limits applicability of tools on divergent notations.

Do you think this occurs in the programming

language domain?
43
 Problem and (Potential)
Topic 2
Software
Architecture
Solution
ICS 123

• Problem: How can we exploit commonalities and

experiment with different features in an ADL without
duplicating effort?
• Solution: An extensible ADL
– Start with a core of “common” features
» Components, Connectors, Interfaces, Links (configurations)
– Extend that core by adding features as necessary

• Benefits
– Shared features may imply shared tools
– “Pick and choose” features that model aspects you care about
– Reuse other people’s modeling constructs and the effort therein

44
 Topic 2
Software
Architecture
xADL 2.0: An Extensible ADL
ICS 123

• xADL 2.0 is an example of an extensible ADL

• Has a core set of features (called xArch) that model
the usual core ADL features:
– Components, Connectors, Interfaces, Links
– BUT! These are “semantically neutral”—nothing is said about what
these things are/do.
• Has several extensions that you can choose and
incorporate into your modeling efforts if you want.
– Design-time/Run-time separation
– Type system for components, connectors, interfaces
– Implementation Mappings
– Variants, Options, and Versions (Product Families and Architecture CM)
– More on the way!

45
 How does extensibility work
Topic 2
Software
Architecture
in xADL 2.0?
ICS 123

• xADL 2.0 is built as an XML-based language

• Uses extensibility constructs from XML schemas
(more on this later in the quarter)
• Simplified explanation :
Architecture{ ComponentWithVersion extends Component{
comp*:Component; add{
conn*:Connector; versionID: String;
link*:Link; }
} remove{
}
Component{ }
id:String;
if:Interface* ArchitectureWithVersions extends Architecture{
} add{
vtree*:VersionTree
Interface{ }
id:String …
} }
46
 Topic 2
Software
Architecture
Design-Time vs. Run-Time
ICS 123

Behavior information Event queue contents

for static analysis
Comp1_Beh{ Run-time State
If(recv(evt(q))){
Design-oriented Properties doProcess(q)
emit(evt(b));
aba - -
} State= BLOCKED
Author=André }
Author=Dick Waiting on Comp
Last Update: Inst 1
08/18/2001 Comp1 event “A”
Comp
Inst 2
Comp2
Conn
Inst 1
Conn1

Comp
Inst 3
Comp3 Constraints Machine = magister
Pid = 242
Invariant a{ CPU = 1
comp1.interface Port = 8080
.type = top -> …
comp1.interface
.link.type = Information about
bottom
} distributed components
47
 Topic 2
Software
Architecture
Implementation Mappings
ICS 123

Comp1
Foo.class
Comp2

Baz.dll Conn1
Comp4

Comp3

.NET
Service

Adding information Bar.jar

about implementations to
component, connector, and
interface types is essential
if the architecture is to be Helps prevent architectural
instantiated. drift!
48
 Product Families &
Topic 2
Software
Architecture
Architecture Evolution
ICS 123

1.0
Component
With Variant Type
Comp1 1.1 Version Graph
for Type T
Comp2
2.0 1.1.1
Comp4

Comp3
1.1.2

Optional 3.0
Component & Link

Can you think of an example of where a lack of this

sort of support has caused you problems?
49
 xADL 2.0 Feature
Topic 2
Software
Architecture
Dependencies
ICS 123

Instances

Structure &
Types

Abstract Architecture Messaging

Versions Options Variants Implementation Diffing Interfaces

Java Type
Implementation Relationships

50
 Topic 2
Software
Architecture
xADL 2.0 Tool Support
ICS 123

• xADL 2.0 is meant to be read & written by people and

computers
– Contrast with a formal notation like Z (“Zed”)…
– People need some way of creating, editing xADL 2.0 documents
– Programs need some way of creating, editing xADL 2.0 documents
programmatically
• Several tools available
– XML Tools off-the-shelf
» XML Spy, Tibco XML Authority, Apache Xerces, Xalan, etc.
– xADL 2.0 Tools
» Apigen: Can generate Java objects for xADL 2.0 (and extensions!)
constructs based entirely on the language definition
» Data Binding Library: Java objects for xADL 2.0 constructs, generated by
Apigen
» ArchEdit: Syntax-directed Editor for xADL 2.0
» Visio for xADL: Graphical box & arrow editor for xADL 2.0 documents

51
 Topic 2
Software
Architecture
xADL 2.0 Tool Relationships
ICS 123
Apache
Xerces
xADL 2.0 uses uses
Schemas
generates Data
Apigen
Binding Library
changes the
interface to
events
ArchEdit uses
xArchADT

use
Visio for uses
xADL Design
Critics

ArchStudio Components
52
 Topic 2
Software
Architecture
Gratuitous Graphics: ArchEdit
ICS 123

53
 Topic 2
Software
Architecture
Gratuitous Graphics: Visio
ICS 123

54
 Topic 2
Software
Architecture
Gratuitous Graphics: Critics
ICS 123

55
 Topic 2
Software
Architecture
Architecture Frameworks
ICS 123

• How do you implement a software architecture?

• Programming language constructs are often
insufficient
Programming Language: Architecture:
•Objects •Components
•Procedure calls, callbacks •Connectors, Events
•Threads of control •Threading Policy
•Design Patterns •Architectural Styles
Can you think of a concrete example from
56
your favorite programming language?
 Topic 2
Software
Architecture
Architecture Frameworks
ICS 123

• An architecture framework is software that assists

developers in building implementations of a software
architecture faithful to the target style by providing
services and tools that are not available in the
existing development environment.
• Frameworks can vary in:
– Fidelity
– Platform/Language Architecture-Based Application
– Any –ility
– Size Architecture Framework
– Reliance on other software
Middleware (JMS, CORBA)
Each layer may make use of
services provided by any layer Programming Language
below, although should
concentrate on upper layers. OS/Filesystem/Network
57
 Topic 2
Software
Architecture
C2 Frameworks
ICS 123

• Original C2 Frameworks (Java & C++, UCI)

– Highly faithful to C2 concepts
– Some dynamism support, support for various threading policies

• oC2 Framework (Java, USC)

– Version of the Original C2 Java Framework optimized for performance
• eC2 Framework (Java, USC)
– Built to be lightweight for embedded devices (Palms, iPAQ, etc.)
– Used central message queues, limited number of threads, low resource
consumption (memory, etc.)

• c2.fw Framework (Java, UCI)

– Highly flexible C2 framework
– Supports pluggable message queuing, threading, topology managers
– More message types allowed
– Improved support for distribution, dynamism

58
 A closer vision: architecture-
Topic 2
Software
Architecture
based evolution and reuse
ICS 123

Process
Support
Tools? Feedback
and
Planning
Analysis Tools

Implementation
Framework
Issues
ADL

Architecture
Evolution
59
Manager
 ICS 123

Other Architecture Approaches and

Tools

ICS 123
Richard N. Taylor and Eric M. Dashofy
UC Irvine
http://www.isr.uci.edu/classes/ics123s02/
 Topic 2
Software
Architecture
Recall…
ICS 123

• Architecture Description Languages are ways of

writing down software architectures.
• ADLs include, at minimum
– Components
– Connectors
– Interfaces
– Configurations ( links)

• Not everybody agrees on what else goes in an ADL

• xADL 2.0 is an attempt at an extensible ADL

61
 Topic 2
Software
Architecture
A Quick Look at ADLs…
ICS 123

Koala
Darwin Distribute Product Wright
d Systems Families Behaviora
Rapide l
Events Properties
Mae Implementatio
n Mappings
Configuration
Management xADL 1.0

Dynamic Mobile,
Systems Dynamic
Darwin, Architectures

62
C2SADL ????
 A Brief Look at Three Other
Topic 2
Software
Architecture
Approaches
ICS 123

• Rapide (Stanford, D. Luckham)

• Darwin (Imperial College London, J. Kramer & J.
Magee)
• ACME (Carnegie-Mellon, D. Garlan)

63
 Topic 2
Software
Architecture
Rapide
ICS 123

• Key foci
– Model behaviors of components, interactions
– Events are the method of communication
– Events organized in POSETs (Partially Ordered SETs)
– Specified systems can be simulated by Rapide toolset
– Simulations can be visualized in a graph format

64
 Topic 2
Software
Architecture
POSETs
ICS 123

• Consider events that a person might emit at a gas

station:
– Pull up
– Leave
– Use Credit Card Machine
What are the orderings
– Wash Windows
between these events?
– Pump Gas

Credit Card Pump Gas Wash

Pull Up Leave

Wash Credit Card Pump Gas

Credit Card Pump Gas

65
 Topic 2
Software
Architecture
A Rapide Interface
ICS 123
type Pump is interface
action in On(), Off(), Activate(Cost : Dollars);
out Report(Amount : Gallons;
Cost : Dollars); “disjoint AND”
behavior
Free : var Boolean := True;
Reading, Limit : var Dollars := 0;
action In_Use(), Done();
begin
(?X : Dollars)(On ~ Activate(?X)) where $Free => Free := False;
Limit := ?X;
In_Use;;
In_Use => Reading := $Limit; Done;;
Off or Done => Free := True; Report($Reading);;
-- constraint
end Pump;

66
 Topic 2
Software
Architecture
A Rapide Configuration
ICS 123
architecture gas_station1() return root
is
O : Operator;
P : Pump;
C1, C2 : Customer;
connect
(?C : Customer; ?X : Dollars) ?C.Pre_Pay(?X) => O.Request(?X);
(?X : Dollars) O.Schedule(?X) => P.Activate(?X);
(?X : Dollars) O.Schedule(?X) => C1.Okay; -- change this
(?C : Customer) ?C.Turn_On => P.On;
(?C : Customer) ?C.Turn_Off => P.Off;
(?X : Gallons; ?Y : Dollars)P.Report(?X, ?Y) => O.Result(?Y);
end gas_station1;

67
 Topic 2
Software
Architecture
The Result
ICS 123

Can you identify a

potential problem
revealed by this
event trace?
68
 Topic 2
Software
Architecture
The Result
ICS 123

Could this be a problem?

Ability to specify Constraints

(patterns that should or should
not happen) are important in
finding these issues.

69
 Topic 2
Software
Architecture
Darwin
ICS 123

• Key foci
– Model distributed systems
– Model dynamic systems

70
 Topic 2
Software
Architecture
Darwin Example
ICS 123
component filter{
provide output<stream char>;
require input<stream char>;
};

component pipeline(int n){

provide output;
require input;
array F[n]: filter;
forall k:0..n-1{
inst F[k] @ k+1;
when k < n-1;
bind F[k+1].input -- F[k].output;
}
bind
F[0].input -- input;
output -- F[n-1].output;
}

71
}
 Topic 2
Software
Architecture
Darwin: Specifying Change
ICS 123

Adding a node to a ring of components (dining philosophers,

in this case)

MERGE::
unlink pa[1] from pa[(1 mod N))+1], pa[(1 mod N))+1] from pa[1],
pb[1] from pb[(1 mod M))+1], pb[(1 mod M))+1] from pb[1];
link pa[1] to pb[1], pb[1] to pa[1];
pa[(1 mod N))+1] to pb[ (1 mod M))+1],
pb[ (1 mod M))+1] to pa[(1 mod N))+1];

72
 Topic 2
Software
Architecture
Darwin: Tools
ICS 123

73
 Topic 2
Software
Architecture
ACME
ICS 123

• Key Foci:
– Genericity (Usual Suspects + Name-Value Properties)
– Function as an “architecture interchange language”

• Later Developments
– Constraints on elements
– Constraint based type system

74
 Topic 2
Software
Architecture
ACME Example*
ICS 123

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;
viewer
Attachments = {
viewer.sendReq to conn.caller;
viewer.receiveReq to conn.callee;
}; database
};

75
*Slides From Bob Monroe’s ICSE’99 Tutorial
 Topic 2
Software
Architecture
ACME Example (cont).
ICS 123

Component Type ServerT = {

Port receiveReq : ODBCPortT = {
Property supportsODBCLevel : int = 2;
Property supportsConcurrentTrans : boolean = true;
};
Property maxConcurrentTrans : int = 20;
Property averageTransProcessingLatency : float;
Property ODBCComplianceLevel : int;
};

Can you identify potential drawbacks to

using this approach for architectural
interchange?
76
*Slides From Bob Monroe’s ICSE’99 Tutorial
 Topic 2
Software
Architecture
Summary
ICS 123

• No “one true approach”

• Flexibility, interchange, evolvability of ADLs is still
unachieved
– But we’re getting there, and hopefully will be there soon!

77