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

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

W

RIGHT

Configurations

Configuration SimpleClientServer Component Server Port provide:

Computation :

Component Client Port request:

Computation :

Connector C-S-connector Role client:

Role server:

Glue

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 cs s

W

RIGHT

Styles

Style ClientServerStyle Connector C-S-connector ( n: 1..

) Role client 1..n

:

Role server:

Glue

Constraints

end ClientServerStyle

Parameterized connectors Style inclusion

System SimpleClientServer Style ClientServerStyle Component Server ...

Component Client ..

.

Instances … cs: C-S-connector(1) Attachments ...

end SimpleClientServer

Connector instantiation

Specifying Behavior (Protocols) Notation (based on CSP):

 Events: request, newValue?y

 Processes: P, WorldModel, Client , § 

Sequence: e



P, P;Q



Choice: P



Q, P

[]

Q



Quantification:

[]

x: S



P(x)

Software Architectures © David Garlan 6

A Client-Server Connector

Connector ClientServer Role Client = open  Operate  § where Operate = request  result?x  Operate  close  § Role Server = open where  Operate 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 where  Exit Read = (read?x

 Glue = Reader) [] (eof  Exit = close  § Writer.write?x  Reader.read!y  Writer.close  Glue [] ReadOnly [] Reader.close  Glue [] WriteOnly Exit) where ...

Software Architectures © David Garlan 8

A Pipe Connector (continued)

where WriteOnly = Writer.write?x  WriteOnly [] Writer.close

 § and ReadOnly = Reader.read!y  [] Reader.eof  [] Reader.close

ReadOnly Reader.close

 §  § Software Architectures © David Garlan 9

Components

Component ReadOneFilter = Port ReadOne = (read  close Port WriteOne = write  close Computation = …   §)  § ( close  §) Component DataFile Port File = Action [] Exit where Action = (read  File [] write  File) and Exit = close  § Computation = … Software Architectures © David Garlan 10

Analyzing W

RIGHT

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 Role User2 = (set   User1) User2)   (get  User1)  § (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 Role

P = (push R = (push

 

P)



R)

 §

(pop



R)

 § No: Port Role

P = (push R = init

 

R' P)

 § 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 W

RIGHT

Analyses

 Most of the checks can be automated  for finite models  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  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 if P = (e  P P = (e  P   f  P) and [] f  P) and Q = e  Q = e  Q then Q then Q refines P Q doesn’t refine P  several flavors: trace, failures, failure/divergences  To 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  3-year effort

Sim1

 high visibility

Sim2 Sim3

Software Architectures © David Garlan 16

The HLA Architecture

Software Architectures Federate Federate ...

FedInterface Runtime Interface (RTI) © David Garlan 17

Software Architectures

W

RIGHT

View: an RTI Connector

Glue FedInterface (Role) Runtime Interface (RTI) © David Garlan 18

Software Architectures © David Garlan 19

The Wright Specification

Style HLA Connector RTI(nsim:1..) Role Fed 1..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  Fed i .requestPause  memberFeds?S  pausedFeds?T  (; j:(S \ T)  Fed j .schedulePause

[] ([] i:1..nsim  Fed i  .requestResume § ) ; PauseProtocol  … [] § Software Architectures © David Garlan 22

Consistency Check 2: Paused on Join

Role JoinFed = joinFedExecution



FedRunning FedRunning = requestPause



schedulePause

 

FedRunning pauseAchieved



FedPaused FedPaused = requestResume



scheduleResume

 

FedPaused resumeAchieved ___________



FedRunning Glue

HandlePause S =  i: S [] Fed i .requestPause  (  i: S ; Fed HandlePause S i .schedulePause

 §) ; Software Architectures © David Garlan 23

Pause on Join

Federate

(

1) joinFedExecution (2) requestPause (3) schedulePause (4) pauseAchieved Software Architectures Federate (5) joinFedExecution (6) requestPause RTI © David Garlan 24

Oops!

Federate (1) joinFedExecution (2) requestPause (3) schedulePause (4) pauseAchieved (7) schedulePause Software Architectures Federate (5) joinFedExecution (6) requestPause RTI © 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 wording  critical reading, Wright, other  Inadequate pre-/post-conditions  critical reading  Missing information  critical reading, Wright, FDR  Race conditions  FDR, Wright  Errors (invariant violation, unexpected conseqs)  critical reading, Wright, other  Misc (typos, impl warnings, doc n inconsistencies)  critical reading ,Wright, FDR 28 12 20 5 11 11

87 issues

Software Architectures © David Garlan 27

Other Examples

 Java Phone  Enterprise Java Beans  See papers on www.cs.cmu/edu/~able Software Architectures © David Garlan 28

What about UML?

 Unified Modeling Language (UML)  emerging standard for object-oriented modeling  collection of many different notations, mostly graphical  object diagrams, class diagrams, sequence diagrams, …  very hot area in the oo community

Requirements

Software Architectures

Software Architecture Code

© David Garlan

UML???

29

Software Architectures

Arch Description and UML

Requirements ADLs UML Code

© 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 interfaces of the same type  Note Java or Com interfaces won’t work  Scoped substructure  Note 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, © David Garlan 35  Mobile users

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 Constraint Evaluator Interpreter Translator Runtime Manager Implementation Layer Software Architectures Arch. Model Monitoring Mechanisms Executing System © David Garlan 39

Client 1 Client 2

Example

Spare Servers Req-queue: ftp.server.com

Client 3 Req-queue Client 4 Client 6 Spare Servers srv1.server.com

ServerGrp1 srv3.server.com

Client 5 40 Software Architectures srv2.server.com

© David Garlan

Software Architecture

    Graph of interacting components User1   Components Connectors Properties capture semantics  E.g., performance properties, protocols Tools to analyze   Style conformance QoS conformance Assumptions   System can be monitored System can be modified at run time User2 Server1 User3 ServerGrp1 Server2 User4 Server3 Component ServerGrp1 (ServerGrpRep) ServerGrp2 User5 User6 ServerGrp3 Software Architectures © David Garlan 41

Run-Time Monitoring & Repair

Client1 L 1 = 427 Client2 L 2 = 603 Client3 L 3 = 1156 Client5 L 4 = 658 Client6 L 5 = 444 Client4 L 6 = 470 B 6 = 45 ServerGrp3 u s = 60.7 % T s = 17 ms ServerGrp1 u s = 26.0 % T s = 14 ms ServerGrp2 Software Architectures Server1 Server2 Server3 Component ServerGrp1 (ServerGrpRep) © David Garlan Server1 Server2 Component ServerGrp2 (ServerGrpRep) 42

Making Repairs

False! Find the right tactic

Repairer (Tailor)

Client6.moveClient (ServerGrp2) True?: avg_latency <= max_latency

Interpreter Analyzer (Armani)

Client6.avg_latency = 3.1

Translator

Move impl 4 second latency

© David Garlan Software Architectures 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 Applications OS/Network Physical Devices

Software Architectures

Tasks Services OS/Network

© David Garlan

Physical Devices

48

Adapting to Environment

User Task access Task Space Environment C

Mobility/ Resource change

Environment A

Software Architectures

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 Service

Software Architectures © David Garlan 50

Model-based Adaptation

Software Architectures Task Manager

Task model

Model Mgr.

System architecture

Run-time Manager © David Garlan

Run-time system

51

Frontier 3: Two-Tiered Models

Software Architectures © David Garlan 52

The Problem



Refinement of architectures to implementations is difficult



Past approaches

 Formal refinement theory  Not practical for most industrial developers  Code generation  Not feasible for most systems  Build and check  Hard to reverse-architect a system from code 

New 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 tier

 Real components from a library Software Architectures © David Garlan 54

Missing Tools



Design tools

 Enforce constraints  Provide visual views  Do analyses 

Refinement tools

 Create low-level connections from high level ones  Typically an expansion factor of 100!!!

 Check for missing connections  Provide access to respositories of components  Thousands of components  Limit design space  Relationships between components are complex  Estimate 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 approaches to software architecture 

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