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: Selected Frontiers
 Ubiquitous
Computing
 Mobility and Task-based Systems
 Two-tiered methods (MDA)
 Others
Software Architectures
© David Garlan
1
Kinds of Analyses
 Consistency
Do the parts fit together?
 Completeness
Are parts missing?
 Refinement
Can one architecture be substituted for another?
 Verification and Architectural Conformance
Does an implementation conform to the architecture?
 System-wide
behavior, performance, reliability,
etc.
What
is the aggregate behavior of a system, given the behaviors
of the parts?
 Evaluating design choices and trade-offs
Software Architectures
How do we decide what architectural
decisions to make?
© David Garlan
2
Analyzing Architectural Behavior
 Much
of the architectural research effort has been
devoted to modeling and analysis of architectural
behavior
 Defines
abstract events at the architectural level
 Usually identifies protocols of interaction for connectors
 Based
on various modeling formalisms
 Process
algebras
 Chemical Abstract Machine
 Statecharts
 Pre/post conditions
 Category theory (ComUnity)
 … and many others
Software Architectures
© David Garlan
3
WRIGHT Configurations
Configuration SimpleClientServer
Component Server
Port provide: <provide protocol>
Computation: <Server behavior>
Component Client
Port request: <request protocol>
Computation: <Client behavior>
Connector C-S-connector
Role client: <request protocol>
Role server: <server protocol>
Glue <glue protocol>
Instances
s: Server
c: Client
cs: C-S-connector
Attachments
s.provide as cs.server
c.request as cs.client
end SimpleClientServer
Component
types
Connector
types
Instances
Attachments
c
s
cs
WRIGHT Styles
Style ClientServerStyle
Connector C-S-connector (n: 1..)
Role client1..n: <request protocol>
Role server: <server protocol>
Glue <glue protocol>
Constraints <constraints>
end ClientServerStyle
System SimpleClientServer
Style ClientServerStyle
Component Server ...
Component Client ...
Instances …
cs: C-S-connector(1)
Attachments ...
end SimpleClientServer
Parameterized
connectors
Style
inclusion
Connector
instantiation
Specifying Behavior (Protocols)
Notation (based on CSP):
 Events:
request, newValue?y
 Processes:
P, WorldModel, Client, §
Sequence:
Choice:
e  P,
P  Q,
Quantification:
Software Architectures
P;Q
P [] Q
[] x: S  P(x)
© David Garlan
6
A Client-Server Connector
Connector ClientServer
Role Client = open  Operate  §
where Operate = request  result?x  Operate
 close  §
Role Server = open  Operate [] §
where Operate = request  result!x  Operate
[] close  §
Glue = Client.open  Server.open  Glue
[] Client.close  Server.close  Glue
[] Client.request Server.request  Glue
[] Server.result?x  Client.result!x  Glue
[] §
Software Architectures
© David Garlan
7
A Pipe Connector
Connector Pipe
Role Writer = (write!x  Writer)  (close  §)
Role Reader = Read  Exit
where Read = (read?x  Reader) [] (eof  Exit)
Exit = close  §
Glue = Writer.write?x  Glue []
Reader.read!y  Glue []
Writer.close  ReadOnly []
Reader.close  WriteOnly
where ...
Software Architectures
© David Garlan
8
A Pipe Connector (continued)
where
WriteOnly =
Writer.write?x  WriteOnly [] Writer.close  §
and
ReadOnly =
Reader.read!y  ReadOnly
[] Reader.eof  Reader.close  §
[] Reader.close  §
Software Architectures
© David Garlan
9
Components
Component ReadOneFilter =
Port ReadOne = (read  close  §)  (close  §)
Port WriteOne = write  close  §
Computation = …
Component DataFile
Port File = Action [] Exit
where Action = (read  File [] write  File)
and Exit = close  §
Computation = …
Software Architectures
© David Garlan
10
Analyzing WRIGHT Specifications

Consistency

Connector is deadlock-free
 roles do not conflict with each other or the glue

Component interface matches its computation
 ports are projections of the component behavior

Compatibility

Port-role compatibility
 port satisfies requirements of role

Instance-style compatibility
 configuration obeys style constraints

Completeness

Unattached port check
 does a port require a connection
Most of these properties can be checked automatically
using model checking
Software Architectures
© David Garlan
11
Consistency Checking
Connector SharedData
Role User1 = (set  User1)  (get  User1)  §
Role User2 = (set  User2)  (get  User2)  §
Glue = User1.set  Continue [] User2.set  Continue [] §
where Continue =
User1.set  Continue [] User2.set  Continue []
User1.get  Continue [] User2.get  Continue
[] §
Deadlock occurs when both users choose to “get”
initially.
Software Architectures
© David Garlan
12
Compatibility Checking

When can a port be legally attached to as a role?
Yes:
Port P = (push  P)  §
Role R = (push  R)  (pop  R)  §
No:
Port P = (push  P)  §
Role R = init  R'
where R' = (push  R')  (pop  R')  §

So are the ports of the previous filters compatible
with the Pipe roles? (ans: yes)
Software Architectures
© David Garlan
13
Automating WRIGHT Analyses

Most of the checks can be automated


We use FDR from Formal Systems, Ltd.



commercial model checker for CSP
used extensively by Inmos
Our tools translate Wright into FDR syntax and
then invoke predefined tests




for finite models
flattens structure; expands names
calculates alphabets
adds explicit types for channels
Can also investigate other properties directly
through FDR

e.g., satisfaction of some particular trace
Software Architectures
© David Garlan
14
How FDR Works
 FDR
checks whether one process refines another
 refinement
means “is substitutable for”
if P = (e  P  f  P) and Q = e  Q then Q refines P
if P = (e  P [] f  P) and Q = e  Q then Q doesn’t refine P
 several
 To
flavors: trace, failures, failure/divergences
check some property of process P
 find
a process Q that embodies just that property
 hide irrelevant parts of P, and rename, to give P’
 check that the P’ refines Q
 Example:
check deadlock freedom of process P with
respect to events in set S
Q = e -> Q
P’ = P \ diff(alpha_P, S) [[ e  x | x : S ]]
Software Architectures
© David Garlan
15
Example: Distributed Simulation
 Distributed
simulation
 simulation
is a multi-billion $ industry
 critical problem for DoD (and others) is multi-vendor
interoperability
 envision ~1000 cooperating simulations
 The
"High-Level Architecture” (HLA)
 Defense
Modeling and Simulation Office (DMSO)
 standard -- about 250 pages
 http://www.dmso.mil/docslib/hla
 each page defines 1 API call
Sim1
Sim2
Sim3
 3-year effort
 high visibility
Software Architectures
© David Garlan
16
The HLA Architecture
Federate
Federate
FedInterface
Software Architectures
© David Garlan
...
Runtime Interface
(RTI)
17
WRIGHT View: an RTI Connector
Glue
FedInterface
(Role)
Software Architectures
© David Garlan
Runtime Interface
(RTI)
18
Software Architectures
© David Garlan
19
The Wright Specification
Style HLA
Connector RTI(nsim:1..)
Role Fed1..nsim = FedInterface
Glue = RTIBehavior
Constraints
$ r:Connectors
| {r} = Connectors L Type(r) = RTI
end HLA
Software Architectures
© David Garlan
20
FedInterface
FedInterface =
FedMgmt || DeclMgmt || ObjMgmt || OwnMgmt
|| TimeMgmt || FedJoined || ControlPause
where
FedMgmt = …
DeclMgmt = …
…
General structure follows this pattern
DeclMgmt =
InitiateDeclActivity
[] WaitForDeclActivity
[] resignFedExecution  §
Software Architectures
© David Garlan
21
RTIBehavior
RTIBehavior = MiniProtocols || JoinedFeds{} || HandleMembership
where
MiniProtocols =
PauseProtocol || SaveProtocol || SubscribeProtocol ||
OwnershipProtocol || ObjectProtocol || OtherBehavior
Example:
PauseProtocol =
([] i:1..nsim  Fedi.requestPause 
memberFeds?S  pausedFeds?T 
(; j:(S \ T)  Fedj.schedulePause  §) ; PauseProtocol
[] ([] i:1..nsim  Fedi.requestResume  …
[] §
Software Architectures
© David Garlan
22
Consistency Check 2: Paused on Join
Role
JoinFed = joinFedExecution  FedRunning
FedRunning = requestPause  FedRunning
 schedulePause  pauseAchieved  FedPaused
FedPaused = requestResume  FedPaused
 scheduleResume  resumeAchieved  FedRunning
___________
Glue
HandlePauseS =  i: S [] Fedi.requestPause
 ( i: S ; Fedi.schedulePause  §) ;
HandlePauseS
Software Architectures
© David Garlan
23
Pause on Join
Federate
Federate
(1) joinFedExecution
(2) requestPause
(3) schedulePause
(4) pauseAchieved
(5) joinFedExecution
(6) requestPause
RTI
Software Architectures
© David Garlan
24
Oops!
Federate
Federate
(1) joinFedExecution
(2) requestPause
(3) schedulePause
(4) pauseAchieved
(5) joinFedExecution
(6) requestPause
(7) schedulePause
RTI
Software Architectures
© David Garlan
25
Results
 Modeled
5/6 of HLA behavior in Wright
 about
20 pages
 initially part of Robert Allen’s Ph.D. thesis
 identified about 12 problems
 later full-time staff member took over major work
 Identified
over 80 issues
 clarified
design especially in areas of synchronization and
time stamping
 ended up authoring parts of published standard
 also used Z and StateCharts to model some aspects of
the architecture
 some of our formal model included in current
documentation
Software Architectures
© David Garlan
26
Classification of Findings
 Ambiguity/imprecise
 critical
 Missing
 critical
 Race
pre-/post-conditions
information
20
reading, Wright, FDR
5
Wright
 Errors (invariant violation, unexpected conseqs)
 critical
 critical
11
reading, Wright, other
 Misc (typos, impl warnings, docn inconsistencies)
Software Architectures
12
reading
conditions
 FDR,
28
reading, Wright, other
 Inadequate
 critical
wording
reading ,Wright, FDR
© David Garlan
11
87 issues
27
Other Examples
 Java
Phone
 Enterprise Java Beans
 See
Software Architectures
papers on www.cs.cmu/edu/~able
© David Garlan
28
What about UML?
 Unified
Modeling Language (UML)
 emerging
standard for object-oriented modeling
 collection of many different notations, mostly graphical
object
 very
diagrams, class diagrams, sequence diagrams, …
hot area in the oo community
Requirements
UML???
Software Architecture
Code
Software Architectures
© David Garlan
29
Arch Description and UML
Requirements
ADLs
UML
Code
Software Architectures
© David Garlan
30
Strategies to Encode
Architectural Designs in UML
 How
do you model an architectural component
type and architectural component instance?
1. classes and instances
2. stereotypes and classes
3. classes and classes
4. UML components
5. packages (subsystems)
… and for each of these strategies there are
many sub-alternatives for connectors,
interfaces, styles, representations, etc.
Software Architectures
© David Garlan
31
UML Limitations
All of these solutions suffer from one or more of the
following problems
1. Incompleteness
 no
home for essential information (associated with
previous list of first-class entities)
2. Illegibility
 can
find first-class home for architectural info, but the
result is a visual (and conceptual) mess
3. Semantic mismatch
 may
look visually clean, but underlying intuitions are
at odds
4. Unanalyzability
 even
when you can represent it, and it looks nice,
there is nothing you can do with it (except use it as
documentation)
Software Architectures
© David Garlan
32
Specific Problem Areas
 Multiple
 Note
Java or Com interfaces won’t work
 Scoped
 Note
interfaces of the same type
substructure
collaboration diagrams won’t work
 First-class
connectors
 Note
associations aren’t sufficient, since can’t represent
substructure, or define independently of context
 Styles
 Profiles
are too heavy-handed; packages provide
aggregation, but can’t support restrictions
Software Architectures
© David Garlan
33
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: Selected Frontiers
 Ubiquitous
Computing
 Mobility and Task-based Systems
 Two-tiered methods (MDA)
 Others
Software Architectures
© David Garlan
34
Frontier 1: Ubiquitous Computing
Computers
and information potentially
everywhere
 Thousands
of computing elements at our
disposal
 Heterogeneous universe
Desktops,
mainframes, PDAs,
Smart appliances
Wearable computers
Sensors and actuators
 Not
just keyboards: voice/speech/gesture
interfaces
 Convergence of communications, information,
computing
Software Architectures
© David Garlan
35
Consequences for Software & Systems
Increasingly,
systems must
 be
composed of parts built by many
organizations
 run continuously
 operate in environments where resources
change frequently
 be usable by mobile users
For
such systems, traditional methods
break down
 Exhaustive
verification and testing not possible
 Manual reconfiguration does not scale
 Off-line repair and enhancement is not an option
Software Architectures
© David Garlan
36
What Has to Change?
Goal:
systems automatically and optimally
adapt to handle
 changes
in user needs
 variable resources
 faults
 user mobility
In
short, systems must be come self-*
* = managing, healing, protecting, adaptive,
configuring, etc.
Software Architectures
© David Garlan
37
But how?
 Move
from open-loop to closed-loop systems
Control Mechanisms
Affect
?
Sense
Executing System
 Systems
monitor their own behavior, and have
engineered control mechanisms to detect problems
and effect repairs.
Software Architectures
© David Garlan
38
Architecture-Driven Adaptation
Architecture Layer
Repair
Handler
Generic
API
Constraint
Evaluator
Interpreter
Arch.
Model
Monitoring
Mechanisms
Translator
Runtime
Manager
Executing System
Implementation Layer
Software Architectures
© David Garlan
39
Example
Client 2
Spare
Servers
Req-queue: ftp.server.com
Client 6
Client 4
Client 3
Req-queue
Client 1
Spare
Servers
srv1.server.com
srv2.server.com
ServerGrp1
srv3.server.com
Client 5
Software Architectures
© David Garlan
40
Software Architecture

Graph of interacting
components



User4
User5
User6
E.g., performance properties,
protocols
Tools to analyze



User3
Properties capture semantics


Components
Connectors
User2
User1
ServerGrp1

ServerGrp3
Style conformance
QoS conformance
Assumptions

ServerGrp2
Server1
System can be monitored
System can be modified at run
time
Software Architectures
© David Garlan
Server2
Server3
Component ServerGrp1
(ServerGrpRep)
41
Run-Time Monitoring & Repair
Client1
L1 = 427
Client2
Client3
L2 = 603
L3 = 1156
Client5
L4 = 658
Client6
L5 = 444
us = 60.7 %
Ts = 17 ms
ServerGrp3
Server2
Server3
Component ServerGrp1
(ServerGrpRep)
Software Architectures
© David Garlan
L6 = 470
B6 = 45
us = 26.0 %
Ts = 14 ms
ServerGrp1
Server1
Client4
ServerGrp2
Server1
Server2
Component ServerGrp2
(ServerGrpRep)
42
Making Repairs
False! Find the right tactic
Repairer
(Tailor)
Architecture
Layer
Client6.moveClient (ServerGrp2)
True?: avg_latency <= max_latency
User1
Mathilde
User2
User2
User3
User4
User3
User4
User5
User5
User6
User6
Interpreter
ServerGrp2
ServerGrp1
ServerGrp1
ServerGrp2
ServerGrp3
ServerGrp3
Analyzer
(Armani)
Client6.avg_latency = 3.1
Translator
Move impl
Software Architectures
4 second latency
© David Garlan
43
Frontier 2: Mobility
Software Architectures
© David Garlan
44
A Simple Example
 Planning
a trip
 search
web for locations
 compare alternatives on spreadsheet
 book tickets …
 consult personal calendar
 Suppose
I move from my office to my home
 Today I must
 stop
all of the applications, being sure to save the files
 transfer data
 restart the applications
 And
it’s worse if I
 have
my calendar on my PDA
 have different platforms in my home and office
 want to involve my wife in the process
Software Architectures
© David Garlan
45
Problem
 Humans
interact at too low a level with
computer
 URLs,
filenames, program names, etc.
 very explicit, step-by-step interactions
 like programming in machine language!
 Result
 brittle
behavior
 many details change with failures, platform changes,
substitution of “equivalent” component, etc.
 consumes user’s attention
Software Architectures
© David Garlan
46
Solution: Task-Driven Computing
 Support
user intentions
 capture
high-level intent as tasks
 raise level of abstraction of user interactions
 Support
mobility
 suspend/resume
on different platforms and locations
 dynamically reconfigure to match available resources
 Support
proactivity
 active
guidance from system
 corrections, alternatives, persistence
Software Architectures
© David Garlan
47
A New Layer of System Structure
Users
Users
Tasks
Applications
Services
OS/Network
OS/Network
Physical Devices
Physical Devices
Software Architectures
© David Garlan
48
Adapting to Environment
Feedback
User
Environment
C
Task
access
Feedback
Instantiation
Task Space
Environment A
Software Architectures
Mobility/
Resource change
Mobility/
Resource change
© David Garlan
Environment B
49
Research Challenges
 Task
management
 Expressive
task definition language
 Mechanisms for tracking, controlling task state
 Support for multi-user task coordination, incl. privacy
 Task
realization
 Rapid
creation of tasks as coalitions of services
 Optimal use of available resources
 Task
adaptation
 Rapid
reconfiguration in presence of
environment change
 Automatic recovery from system errors
Task
Service
Service
Software Architectures
© David Garlan
Service
50
Model-based Adaptation
Task Manager
Task model
Model Mgr.
System architecture
Run-time
Manager
Software Architectures
Run-time system
© David Garlan
51
Frontier 3: Two-Tiered Models
Software Architectures
© David Garlan
52
The Problem
 Refinement
of architectures to implementations
is difficult
 Past approaches
 Formal
Not
 Code
Not
 Build
practical for most industrial developers
generation
feasible for most systems
and check
Hard
 New
refinement theory
to reverse-architect a system from code
approach: provide user with 2-tiered model
 Top
tier captures abstract functionality
 Bottom tier captures implementation dependencies
 Various manifestations: e.g, Model-Driven Architecture
(MDA)
Software Architectures
© David Garlan
53
Example:
Ford Automotive Control Systems
 Top
tier
 Control
theorists design space
 Components are abstract: e.g., ignition controller,
temperature sensor, brake actuator
 Connectors are simple: indicate which components talk to
which other components
 Designs reusable across many car models
 Bottom
 Real
Software Architectures
tier
components from a library
© David Garlan
54
Missing Tools
 Design
tools
 Enforce
constraints
 Provide visual views
 Do analyses
 Refinement
 Create
tools
low-level connections from high level ones
Typically
an expansion factor of 100!!!
Check for missing connections
 Provide
access to respositories of components
Thousands
 Limit
of components
design space
Relationships
 Estimate
between components are complex
savings: in 1 week do what took 6 months
before
Software Architectures
© David Garlan
55
Example 2: MDS
 NASA
Space Software Architecture
 Mission
Data Systems
 To be used in 2009 mission to Mars
 Top
tier: “state analysis”
 Domain
experts design control software in terms of
sensors actuators, etc.
 Worry about properties like power consumption, failures,
state estimation algorithms
 Bottom
tier: component framework
 Bind
abstract components to real code
 Add much of the glue through framework libraries
Software Architectures
© David Garlan
56
Other Frontiers
 Cognitive
Computing
 Building
in automated assistance that can learn what the
user wants
 Compositional
Connectors
 Transformational
 Architecture
approaches to software architecture
Conformance Checking
 How
do you know your implementation has the
architecture you designed?
 Value-based
Architecture
 How
do you balance competing economic tradeoffs in
making architectural decisions
 Key sub-problem: multi-model architectural design
Software Architectures
© David Garlan
57