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,
• Architecture vs. Construction
etc.)
• 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
 and Software Topic 2
Software
Architecture
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
 Components and Topic 2
Software
Architecture
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
 Architectures for a Topic 2
Software
Architecture
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 Topic 2
Software
Architecture
buy 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 Topic 2
Software
Architecture
Civil 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
 Common Software Topic 2
Architectural Styles (Shaw Software
Architecture
& 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
 Architectural Styles Topic 2
Software
Architecture
(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
 Based Composition & Topic 2
Software
Architecture
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
Can you“Visual
name Studio”
somebut for architectures,
tools that wouldrather
go inthan
a
code
{code-based/architecture-based}
36 environment?
 Contrast: IDE vs. Topic 2
Software
Architecture
Architecture-based DE
ICS 123
Code-based IDE Architecture-based
Tools: 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
management
configuration
37 management •Component-based
 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
Architecture
s
42
 What really goes in an Topic 2
Software
Architecture
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
 xADL 2.0: An Extensible Topic 2
Software
Architecture
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 Topic 2
Software
Architecture
work 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
 Design-Time vs. Run- Topic 2
Software
Architecture
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
 Implementation Topic 2
Software
Architecture
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
instantiated. architectural
48 drift!
 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
49 problems?
 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
 xADL 2.0 Tool Topic 2
Software
Architecture
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
 Gratuitous Graphics: Topic 2
Software
Architecture
ArchEdit
ICS 123

53
 Gratuitous Graphics: Topic 2
Software
Architecture
Visio
ICS 123

54
 Gratuitous Graphics: Topic 2
Software
Architecture
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 Architecture:
Language:
•Components
•Objects
•Connectors, Events
•Procedure calls,
•Threading Policy
callbacks
•Architectural Styles
•Threads of control
Can you think of a concrete example from
•Design Patterns
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
– Architecture-Based Application
Platform/Language
– Any –ility
Architecture Framework
– Size
– 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
 architecture- based Topic 2
Software
Architecture
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, Architecture
s
62
C2SADL ????
 A Brief Look at Three Topic 2
Software
Architecture
Other 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
}
 Darwin: Specifying Topic 2
Software
Architecture
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