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
(Perry & Wolf 92)
Topic 2
Software
Architecture
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
(Garlan & Shaw 93)
Topic 2
Software
Architecture
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
(Shaw & Garlan 96)
Topic 2
Software
Architecture
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
Civil Architecture
Topic 2
Software
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
and Software Architecture
Topic 2
Software
Architecture
• Physical vs. conceptual
• Static vs. dynamic
• Little evolution vs. frequent evolution
• Different mathematical and scientific bases
• Different notions of “reuse”
6
ICS 123
Elements of Software
Architecture
Topic 2
Software
Architecture
ICS 123
• Perry & Wolf
– Structural Elements
» Processing
» Data
» Connecting (“glue”)
– Form: Weighted Properties and
Relationships
– Rationale
• Shaw & Garlan:
–
–
–
–
7
Components
Interconnections
Rules of Composition
Rules of Behavior
   This Class   
•
•
•
•
•
Components
Connectors
Interfaces
Configurations
 (implies) Links
Components
Topic 2
Software
Architecture
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
Components and Objects
Topic 2
Software
Architecture
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
Connectors
Topic 2
Software
Architecture
• 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
ICS 123
The Difference Between
Components and Connectors
Topic 2
Software
Architecture
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
11
Not everybody agrees on this!
Interfaces
Topic 2
Software
Architecture
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
Configurations
Topic 2
Software
Architecture
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
Graphically (cont).
Clock
Bus1
LCD
Driver
15
Topic 2
Software
Architecture
ICS 123
Configuration
Links
Example:
Architectures for a Compiler
Scanner
Scanner
File
Semantic
Analyzer
Parser
16
Component
Code
Generator
File
Parse Tree
Legend:
ICS 123
Semantic
Analyzer
Parser
File
Topic 2
Software
Architecture
Connector
Code
Generator
What does architecture buy
you?
Topic 2
Software
Architecture
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
Architectural Styles
Topic 2
Software
Architecture
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
Architecture
The Pantheon
Rome, Italy
19
Topic 2
Software
Architecture
ICS 123
The Gothic Style
Topic 2
Software
Architecture
ICS 123
Nôtre-Dame Cathedral
Paris, France
20
The Mediterranean Style
Irvine, California
21
Topic 2
Software
Architecture
ICS 123
Common Software Architectural
Styles (Shaw & Garlan 96)
Topic 2
Software
Architecture
• 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
ICS 123
Common Software
Architectural Styles (Cont.)
• Virtual Machines
– Interpreters
– Rule-based systems
• Data-Centered Systems (Repositories)
– Databases
– Hypertext systems
– Blackboards
23
Topic 2
Software
Architecture
ICS 123
Pipe and Filter Example
Topic 2
Software
Architecture
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
Pipe & Filter Constraints
Topic 2
Software
Architecture
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
Pipe & Filter Qualities
Topic 2
Software
Architecture
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-
Based Composition & Reuse
Topic 2
Software
Architecture
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:
Architectural Mismatch
Topic 2
Software
Architecture
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
(Cont.)
Topic 2
Software
Architecture
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
Standards: The Solution?
Topic 2
Software
Architecture
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:
“Architectural Drift”
Topic 2
Software
Architecture
• How are architectures implemented now?
ICS 123
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
Architecture
31
Semi-Cohesive
Object Design in UML
Incomprehensible
Python Code
Why does drift happen?
Topic 2
Software
Architecture
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
Solutions for Drift
Topic 2
Software
Architecture
• 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
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/
Overview
Topic 2
Software
Architecture
ICS 123
• Architecture-centric Development Environments
– ArchStudio
• Architecture Description Languages
– xADL 2.0
• Architecture Frameworks
– c2.fw and others
35
The Vision
Topic 2
Software
Architecture
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.
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
•Project Management
•Source file configuration
management
37
Topic 2
Software
Architecture
•Various analysis tools
•Style-specific constraint
management
•Component-based
configuration management
ArchStudio
Topic 2
Software
Architecture
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
ArchStudio 3 Today
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
Topic 2
Software
Architecture
ICS 123
Architecture Description
Languages
Topic 2
Software
Architecture
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
Architecture Description?
Topic 2
Software
Architecture
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
their descriptions
Distribute
d Systems
Events
Configuration
Management
Dynamic
Systems
42
Product
Families
Topic 2
Software
Architecture
ICS 123
Behaviora
l
Properties
Implementatio
n Mappings
Mobile,
Dynamic
Architecture
s
What really goes in an ADL?
Topic 2
Software
Architecture
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)
Solution
Topic 2
Software
Architecture
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 ADL
Topic 2
Software
Architecture
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.
–
–
–
–
–
45
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!
How does extensibility work
in xADL 2.0?
Topic 2
Software
Architecture
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{
comp*:Component;
conn*:Connector;
link*:Link;
}
Component{
id:String;
if:Interface*
}
46
Interface{
id:String
}
ComponentWithVersion extends Component{
add{
versionID: String;
}
remove{
}
}
ArchitectureWithVersions extends Architecture{
add{
vtree*:VersionTree
}
…
}
Topic 2
Software
Architecture
Design-Time vs. Run-Time
Behavior information
for static analysis
Event queue contents
Design-oriented Properties
Author=André
Author=Dick
Last Update:
08/18/2001
ICS 123
Comp1_Beh{
If(recv(evt(q))){
doProcess(q)
emit(evt(b));
}
}
Comp1
Run-time State
State= BLOCKED
Comp
Inst 1
Waiting on
event “A”
Comp
Inst 2
Comp2
Conn
Inst 1
Conn1
Comp3
Invariant a{
comp1.interface
.type = top ->
comp1.interface
.link.type =
bottom
}
47
aba - -
Constraints
Comp
Inst 3
Machine = magister
Pid = 242
CPU = 1
Port = 8080
…
Information about
distributed components
Implementation Mappings
Topic 2
Software
Architecture
ICS 123
Comp1
Foo.class
Comp2
Baz.dll
Conn1
Comp4
Comp3
.NET
Service
Adding information
about implementations to
component, connector, and
interface types is essential
if the architecture is to be
instantiated.
48
Bar.jar
Helps prevent architectural
drift!
Product Families &
Architecture Evolution
Topic 2
Software
Architecture
ICS 123
1.0
Component
With Variant Type
Comp1
Version Graph
for Type T
1.1
Comp2
2.0
1.1.1
Comp4
1.1.2
Comp3
Optional
Component & Link
3.0
Can you think of an example of where a lack of this
sort of support has caused you problems?
49
xADL 2.0 Feature
Dependencies
Topic 2
Software
Architecture
ICS 123
Instances
Structure &
Types
Versions
Options
Variants
Abstract
Implementation
Java
Implementation
50
Architecture
Diffing
Messaging
Interfaces
Type
Relationships
xADL 2.0 Tool Support
Topic 2
Software
Architecture
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 Relationships
xADL 2.0
Schemas
uses
Apigen
ArchEdit
Apache
Xerces
Topic 2
Software
Architecture
ICS 123
uses
generates
Data
Binding Library
changes the
interface to
events
uses
xArchADT
Visio for
xADL
uses
use
Design
Critics
ArchStudio Components
52
Gratuitous Graphics: ArchEdit
53
Topic 2
Software
Architecture
ICS 123
Gratuitous Graphics: Visio
54
Topic 2
Software
Architecture
ICS 123
Gratuitous Graphics: Critics
55
Topic 2
Software
Architecture
ICS 123
Architecture Frameworks
Topic 2
Software
Architecture
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
56
Can you think of a concrete example from
your favorite programming language?
Architecture Frameworks
Topic 2
Software
Architecture
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:
–
–
–
–
–
57
Fidelity
Platform/Language
Any –ility
Size
Reliance on other software
Each layer may make use of
services provided by any layer
below, although should
concentrate on upper layers.
Architecture-Based Application
Architecture Framework
Middleware (JMS, CORBA)
Programming Language
OS/Filesystem/Network
C2 Frameworks
Topic 2
Software
Architecture
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)
–
–
–
–
58
Highly flexible C2 framework
Supports pluggable message queuing, threading, topology managers
More message types allowed
Improved support for distribution, dynamism
A closer vision: architecturebased evolution and reuse
Process
Support
Tools?
Topic 2
Software
Architecture
ICS 123
Feedback
and
Planning
Analysis Tools
Framework
ADL
59
Architecture
Evolution
Manager
Implementation
Issues
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/
Recall…
Topic 2
Software
Architecture
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…
Darwin
Rapide
Koala
Distribute
d Systems
Events
Mae
Configuration
Management
Darwin,
C2SADL
62
ICS 123
Dynamic
Systems
Product
Families
Wright
Behaviora
l
Properties
Implementatio
n Mappings
xADL 1.0
Mobile,
Dynamic
Architecture
s
????
A Brief Look at Three Other
Approaches
Topic 2
Software
Architecture
ICS 123
• Rapide (Stanford, D. Luckham)
• Darwin (Imperial College London, J. Kramer & J.
Magee)
• ACME (Carnegie-Mellon, D. Garlan)
63
Rapide
• Key foci
–
–
–
–
–
64
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
Topic 2
Software
Architecture
ICS 123
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
Wash Windows
Pump Gas
Credit Card
What are the orderings
between these events?
Pump Gas
Wash
Leave
Pull Up
Wash
Credit Card
65
Credit Card
Pump Gas
Pump Gas
A Rapide Interface
Topic 2
Software
Architecture
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
ICS 123
A Rapide Configuration
Topic 2
Software
Architecture
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
ICS 123
The Result
Can you identify a
potential problem
revealed by this
event trace?
68
Topic 2
Software
Architecture
ICS 123
The Result
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
ICS 123
Darwin
• Key foci
– Model distributed systems
– Model dynamic systems
70
Topic 2
Software
Architecture
ICS 123
Darwin Example
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
ICS 123
Darwin: Specifying Change
Topic 2
Software
Architecture
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
ICS 123
Darwin: Tools
73
Topic 2
Software
Architecture
ICS 123
ACME
• 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
ICS 123
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;
Attachments = {
viewer.sendReq to conn.caller;
viewer.receiveReq to conn.callee;
};
};
75
viewer
database
*Slides From Bob Monroe’s ICSE’99 Tutorial
ACME Example (cont).
Topic 2
Software
Architecture
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
Summary
Topic 2
Software
Architecture
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