Talk Outline

1
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

2
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
• How do we decide what architectural decisions to
  make?

3
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

4
WRIGHT Configurations
Configuration SimpleClientServer Component
Server Port provide ltprovide
protocolgt Computation ltServer
behaviorgt Component Client Port request
ltrequest protocolgt Computation ltClient
behaviorgt Connector C-S-connector Role client
ltrequest protocolgt Role server ltserver
protocolgt Glue ltglue protocolgt Instances s
Server c Client cs C-S-connector Attachmen
ts s.provide as cs.server c.request as
cs.client end SimpleClientServer
Connector types
Instances
Attachments
5
WRIGHT Styles

• Style ClientServerStyle
• Connector C-S-connector (n 1..)
• Role client1..n ltrequest protocolgt
• Role server ltserver protocolgt
• Glue ltglue protocolgt
• Constraints ltconstraintsgt
• 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
6
Specifying Behavior (Protocols)
Notation (based on CSP)

• Events request, newValue?y
• Processes P, WorldModel, Client,
• Sequence e ? P, PQ
• Choice P ?? Q, P Q
• Quantification x S ? P(x)

7
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

8
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 ...
9
A Pipe Connector (continued)

• where
• WriteOnly
• Writer.write?x ? WriteOnly Writer.close ?
• and
• ReadOnly
• Reader.read!y ? ReadOnly
• Reader.eof ? Reader.close ?
• Reader.close ?

10
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

11
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
12
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.
13
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)

14
Automating WRIGHT 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

15
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
  doesnt 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 -gt Q
• P P \ diff(alpha_P, S) e x x S

16
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
• high visibility

Sim1
Sim2
Sim3
17
The HLA Architecture
Federate
Federate
...
Runtime Interface (RTI)
18
WRIGHT View an RTI Connector
Glue
Runtime Interface (RTI)
FedInterface (Role)
19
(No Transcript)
20
The Wright Specification

• Style HLA
• Connector RTI(nsim1..)
• Role Fed1..nsim FedInterface
• Glue RTIBehavior
• Constraints
• rConnectors
• r Connectors L Type(r) RTI
• end HLA

21
FedInterface

• FedInterface
• FedMgmt DeclMgmt ObjMgmt OwnMgmt
• TimeMgmt FedJoined ControlPause
• where
• FedMgmt
• DeclMgmt
• General structure follows this pattern
• DeclMgmt
• InitiateDeclActivity
• WaitForDeclActivity
• resignFedExecution ?

22
RTIBehavior

• RTIBehavior MiniProtocols JoinedFeds
  HandleMembership
• where
• MiniProtocols
• PauseProtocol SaveProtocol
  SubscribeProtocol OwnershipProtocol
  ObjectProtocol OtherBehavior
• Example
• PauseProtocol
• ( i1..nsim Fedi.requestPause ?
  memberFeds?S ? pausedFeds?T ?
• ( j(S \ T) Fedj.schedulePause ? )
  PauseProtocol
• ( i1..nsim Fedi.requestResume ?

23
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

24
Pause on Join
Federate
Federate
(1) joinFedExecution (2) requestPause (3)
schedulePause (4) pauseAchieved
(5) joinFedExecution (6) requestPause
RTI
25
Oops!
Federate
Federate
(1) joinFedExecution (2) requestPause (3)
schedulePause (4) pauseAchieved (7)
schedulePause
(5) joinFedExecution (6) requestPause
RTI
26
Results

• Modeled 5/6 of HLA behavior in Wright
• about 20 pages
• initially part of Robert Allens 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

27
Classification of Findings

• Ambiguity/imprecise wording 28
• critical reading, Wright, other
• Inadequate pre-/post-conditions 12
• critical reading
• Missing information 20
• critical reading, Wright, FDR
• Race conditions 5
• FDR, Wright
• Errors (invariant violation, unexpected
  conseqs) 11
• critical reading, Wright, other
• Misc (typos, impl warnings, docn
  inconsistencies) 11
• critical reading ,Wright, FDR

87 issues
28
Other Examples

• Java Phone
• Enterprise Java Beans
• See papers on www.cs.cmu/edu/able

29
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

UML???
30
Arch Description and UML
Requirements
ADLs
UML
Code
31
Strategies to EncodeArchitectural 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.

32
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)

33
Specific Problem Areas

• Multiple interfaces of the same type
• Note Java or Com interfaces wont work
• Scoped substructure
• Note collaboration diagrams wont work
• First-class connectors
• Note associations arent sufficient, since cant
  represent substructure, or define independently
  of context
• Styles
• Profiles are too heavy-handed packages provide
  aggregation, but cant support restrictions

34
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

35
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
• Mobile users

36
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

37
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.

38
But how?

• Move from open-loop to closed-loop systems

• Systems monitor their own behavior, and have
  engineered control mechanisms to detect problems
  and effect repairs.

39
Architecture-Driven Adaptation
40
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
ServerGrp1
srv2.server.com
srv3.server.com
Client 5
41
Software Architecture

• Graph of interacting components
• 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

42
Run-Time Monitoring Repair
L1 427
L2 603
L3 1156
L4 658
L5 444
L6 470 B6 45
us 60.7 Ts 17 ms
us 26.0 Ts 14 ms
43
Making Repairs
False! Find the right tactic

Client6.moveClient (ServerGrp2)
True? avg_latency lt max_latency
Architecture Layer
Client6.avg_latency 3.1
4 second latency
Move impl
44
Frontier 2 Mobility
45
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 its 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

46
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 users attention

47
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

48
A New Layer of System Structure
49
Adapting to Environment
User
Task access
Feedback
Task Space
50
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

51
Model-based Adaptation
Task Manager
Model Mgr.
Run-time Manager
Run-time system
52
Frontier 3 Two-Tiered Models
53
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)

54
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

55
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

56
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

57
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