Modeling%20and%20Analysis%20of%20Software%20Architecture

1
Modeling and Analysis of Software Architecture
Robert T. Monroe
Carnegie Mellon University 5000 Forbes
Ave. Pittsburgh, PA 15213 bmonroe_at_cs.cmu.edu
FreeMarkets Corp. One Oliver Plaza Pittsburgh, PA
15222 bmonroe_at_freemarkets.com
2
Acknowledgment

• Some of the material in this tutorial was drawn
  from a tutorial on Software Architecture
  developed by Mary Shaw and David Garlan.
• Some parts are adapted from a semester course on
  Software Architecture taught by Mary Shaw and
  David Garlan from 1992-1998. Robert Allen, of
  IBM, helped greatly in the creation of a previous
  version of this tutorial.

The development of the tutorial was supported in
part by grants from the US Department of Defense
Advanced Research Project Agency. The underlying
research has been supported by the US Department
of Defense, the National Science Foundation,
Siemens Corporation, The Eastman Kodak
Corporation, and Carnegie Mellon University.
3
Outline

• Introduction to Software Architecture
• Architectural Modeling
• Architectural structure and topology
• Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities challenges

4
Three Ideas To Take Away

• Architecture description languages and toolkits
  (ADLs) are useful for describing, documenting,
  and reasoning about Software Architectures.
• There are a number of interesting and useful
  architecture-level analyses that can be performed
  with existing ADLs and their associated toolkits.
• There are further powerful analysis and
  generation capabilities on the horizon.

5
Typical Descriptions ofSoftware Architectures
The Architecture of This System

• Descriptions of software systems often include a
  section on the architecture of this system
• Usually informal prose plus box-and-line diagram
• Lots of appeal to intuition
• Little precision, rarely formal

Next Section
6
Typical Descriptions ofSoftware Architectures

• "Camelot is based on the client-server model and
  uses remote procedure calls both locally and
  remotely to provide communication among
  applications and servers." Spector 87
• "We have chosen a distributed, object-oriented
  approach to managing information." Linton 87
• "The easiest way to make the canonical sequential
  compiler into a concurrent compiler is to
  pipeline the execution of the compiler phases
  over a number of processors." Seshadri 88
• "The ARC network follows the general network
  architecture specified by the ISO in the Open
  Systems Interconnection Reference Model." Paulk
  85

7
Observations about Designers

• They freely use informal patterns (idioms)
• Very informal, imprecise semantics
• Diagrams as well as prose, but no uniform rules
• Communication takes place anyhow
• Their vocabulary uses system-level abstractions
• Overall organization (styles)
• Kinds of components and interactions among them
• They compose systems from subsystems
• Tend to think about system structure statically
• Often select organization by default, not by
  design

8
Architectural Design Level of Software

• Deals with the composition of software systems
  from module-scale elements
• Gross decomposition of required function
• What patterns of organization are useful?
• Which organization fits the application best?
• Assignment of function to design elements
• What are the elements?
• How do the elements interact?
• Emergent system properties
• Scaling and performance Capacities, balance,
  schedules
• Security
• ...
• Selection among design alternatives
• Which implementations of elements will work best?

9
Architectural Design Task
Issues for architecture and programs
differ Architecture Programs

• interactions among parts implementations of parts
• structural properties computational properties
• declarative operational
• mostly static mostly dynamic
• system-level performance algorithmic performance
• outside module boundary inside module boundary
• composition of subsystems copy code or call
  libraries

10
Promised Benefits of Architectural Modeling

• Clarify design intentions
• Intended architecture is often lost. It's mostly
  informal, it's hard to communicate anyhow.
• Provide basis for analysis in design
• Engineering design entails performance prediction
  and design tuning. Routine practice.
• Improve maintenance
• Over half of maintenance effort goes into
  figuring out just what's there.
• Address the hard questions
• Even without formal methods, explicit
  architectural modelling can uncover fuzzy
  requirements, thinking, and design approaches

11
Promised Benefits of Architectural Modeling
test debug (28)
Reduce maintenance costs, directly and indirectly

• Clarify intentions
• Make decisions and implications explicit
• Permit system-level analysis

12
Architectural Design Reviews
13
Elements of Architectural Descriptions

• A system architecture identifies
• Components define the locus of computation
• Examples filters, databases, objects,
  clients/servers
• Connectors mediate component interactions
• Examples procedure call, pipes, event broadcast
• Properties specify info for construction
  analysis
• Examples signatures, pre/post conds, RT specs
• An architectural style defines a family of
  architectures constrained by
• Component/connector vocabulary
• Topology rules
• Semantic constraints

14
Example Key Word In Context

• Problem Description
• "The KWIC index system accepts an ordered set of
  lines, each line is an ordered set of words, and
  each word is an ordered set of characters.
• Any line may be circularly shifted by
  repeatedly removing the first word and appending
  it at the end of the line.
• The KWIC index system outputs a listing of all
  circular shifts of all lines in alphabetical
  order."

On the Criteria for Decomposing Systems into
Modules. David Parnas. CACM, 1972
15
KWIC Key Word In Context

• Inputs Sequence of lines
• Pipes and Filters
• Architectures for Software Systems
• Outputs Sequence of lines, circularly shifted
  and alphabetized
• and Filters Pipes
• Architectures for Software Systems
• Filters Pipes and
• for Software Systems Architectures
• Pipes and Filters
• Software Systems Architectures for
• Systems Architectures for Software

16
KWIC Shared Memory Solution
Advantage Good performance
17
KWIC ADT Solution
Advantage Information hiding simplifies
implementation changes.
18
KWIC Event Solution
Advantage Tool separation supports function
enhancements.
19
KWIC Dataflow Solution
Advantage Tool separation eases functional
enhancements.
20
Design Considerations

• Change in Algorithm
• Eg., batch vs incremental
• Change in Data Representation
• Eg., line storage, explicit vs implicit shifts
• Change in Function
• Eg., eliminate lines starting with trivial words
• Performance
• Eg., space and time
• Reuse
• Eg., Sorting

21
KWIC Comparisons
Shared Memory
ADT
Events
Dataflow
_ _ _
_ _
_ _ _
_ _

• Change in Algorithm
• Change in Data Repn
• Change in Function
• Performance
• Reuse

22
Outline

• Introduction to Software Architecture
• Architectural Modeling
• Architectural structure and topology
• Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities challenges

23
Architectural Vocabulary (Structure)
24
Architectural Structure Components, Connectors,
Systems

• Components
• computational elements
• Ports
• interface points for components
• Connectors
• interactions between components
• Roles
• interface points for connectors
• Systems
• graphs of component and connectors

25
System Description Example (Acme)
Component Type ClientT Port sendReq
Component Type ServerT Port receiveReq
Connector Type RPCT Roles caller
callee System SimpleClientServer
Component viewer ClientTComponent database
ServerTConnector conn RPCT Attachments
viewer.sendReq to conn.caller viewer.receiv
eReq to conn.callee
viewer
database
26
Architectural StructureHierarchical Descriptions

• Representations
• describe subsystems
• may be architectural or external
• Abstraction mappings
• relate the inside and outside of architectural
  representations
• bindings are special case

27
Representations

• Provide a description of a complete view of the
  design element
• May be external e.g. file, URL or
  sub-architecture

28
Abstraction Maps
29
Beyond Simple Structure

• What else can we represent?
• Local component or connector properties
• Rates, capacities, latencies, etc. for individual
  components and connectors
• Emergent system-wide properties
• Overall system performance, reliability,
  security, etc.
• Behavior
• computations of components
• protocols of connectors
• Many forms and notations for semantics
• property lists
• protocol specifications
• type systems ...

30
Capturing Local Properties (with Acme)
Component Type ServerT Port receiveReq
ODBCPortT Property supportsODBCLevel int
2 Property supportsConcurrentTrans boolean
true Property maxConcurrentTrans int
20 Property averageTransProcessingLatency
float Property ODBCComplianceLevel
int Connector Type RPCT Roles caller
callee Property synchronous boolean
true
31
Capturing System Properties (with Acme)
System SimpleClientServer Components
viewer1 ClientT viewer2 ClientT
Component database ServerT Connector conn
RPCT Attachments Property
viewerRequestDistribution interleaved ltlt
origination asserted gtgt Property
transactionProcessingCapacity float
34.5 ltlt units transactions-per-second
origination computed gtgt Property
maxConcurrentViewers int 5 ltlt origination
computed gtgt
32
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)

33
WRIGHT Configuration
Configuration SimpleSimulation Component
WorldModel(map Function) Port Provide ltprovide
protocolgt Computation ltprovide world
modelgt Component VehicleModel Port Environment
ltvalue protocolgt Computation ltVehicle
behaviorgt Connector UpdateValues(n 1..
) Role Model1..n lt1 models protocolgt Glue
ltdata from one model to anothergt Instances Envt
WorldModel(ltmapgt) V VehicleModel Cn
UpdateValues(2) Attachments Envt.Provide as
Cn.Model1 V.Environment as Cn.Model2
Envt
V
Cn
34
Example What is UpdateValues Connector?
Connector UpdateValues(n 1.. ) Role Model1..n
Glue
lta models protocolgt
ltdata travels from one model to anothergt
35
Example What is UpdateValues Connector?
Connector UpdateValues(n 1.. ) Role Model1..n
Glue
(open request ?????newVal?y
?????update!x ?????close
36
Example What is UpdateValues Connector?
Connector UpdateValues(n 1.. ) Role Model1..n
Glue
(open request ?????newVal?y
?????update!x ?????close
? Operate)
37
Example What is UpdateValues Connector?
Connector UpdateValues(n 1.. ) Role Model1..n
Glue
(open request ?????newVal?y
?????update!x ?????close
where Operate ?
? Operate ??? ?
Operate ?? ?
? Operate)
38
Example What is UpdateValues Connector?
Connector UpdateValues(n 1.. ) Role Model1..n
Glue
(open request ?????newVal?y
?????update!x ?????close
? Operate)
where Operate ?
? Operate ??? ?
Operate ?? ?
39
Example What is UpdateValues Connector?
Connector UpdateValues(n 1.. ) Role Model1..n
Glue
(open request ?????newVal?y
?????update!x ?????close
where Operate ?
? Operate ??? ?
Operate ?? ?
??
???????????????????????
? Operate)
40
Example What is UpdateValues Connector?
Connector UpdateValues(n 1.. ) Role Model1..n
Glue
(open request ?????newVal?y
?????update!x ?????close
where Operate ?
? Operate ??? ?
Operate ?? ?
??
???????????????????????
? Operate)
Statev where Statev i1..n ?
Modeli.open ? Statev i1..n ?
Modeli.request ? Modeli.newVal!v ? Statev
i1..n ? Modeli.update?x ? Statex
i1..n ? Modeli.close ? Statev
41
Example What is UpdateValues Connector?
Connector UpdateValues(n 1.. ) Role Model1..n
Glue
(open request ?????newVal?y
?????update!x ?????close
where Operate ?
? Operate ??? ?
Operate ?? ?
??
???????????????????????
? Operate)
Statev where Statev i1..n ?
Modeli.open ? Statev i1..n ?
Modeli.request ? Modeli.newVal!v ? Statev
i1..n ? Modeli.update?x ? Statex
i1..n ? Modeli.close ? Statev
42
Outline

• Introduction to Software Architecture
• Architectural Modeling
• Architectural structure and topology
• Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities challenges

43
Kinds of Analyses

• Consistency
• Do the parts fit together?
• Completeness
• Are parts missing?
• Refinement
• Can one architecture be substituted for another?
• Verification
• 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

44
Analysis Strategies

• Use existing specification languages calculi
• Examples CSP, UML, Queuing Theory,
  Napkin/Envelope (back of)
• Advantages well understood, tools, reuse
• Disadvantages may not be expressive may require
  a lot of initial context building before you
  can do anything useful
• Develop new architectural specification languages
  reasoning techniques
• Examples Rapide, Wright, Meta-H
• Advantages good match to the problem
• Disadvantages learning curve, proliferation of
  languages, analysis techniques, tools, mismatch
  of problem and technique

45
Analysis consistency completeness

• Consistency do the parts fit together?
• analog of type checking
• depends on what you say about the parts
• behavior example does the behavior of a
  component conform to the protocols of a connector
  to which it is attached?
• Completeness are any parts missing?
• connector roles?
• unattached ports?
• missing functionality?

46
Consistency Check 1 Faulty Client

• Trivial Client-Server system (1 client, 1 server)
• Client should initialize before requesting, but
  it doesnt do so.
• Disaster detected and averted early ...
• Connector Faulty
• Role Client (request?result?Client) ??
• Role Server initialize? Operate...
• Glue Client.initialize?Server.initialize?Glue
• Client.request?Server.request?Glue
• ...

47
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

48
Paused on Join
Federate
Federate
(1) joinFedExecution (2) requestPause (3)
schedulePause (4) pauseAchieved
(5) joinFedExecution (6) requestPause
RTI
49
Oops!
Federate
Federate
(1) joinFedExecution (2) requestPause (3)
schedulePause (4) pauseAchieved (7)
schedulePause
(5) joinFedExecution (6) requestPause
RTI
50
Consistency Check 3Save Boundary Condition
Federate1
Federate2
RTI internal

updateAttrValue (receive update) (commit
to send) reflectAttrValue
Save will be inconsistent
RTI
51
Example of a completeness check

• Example completeness rule All clients need to
  be attached to at least one server.
• Client with no server is incomplete
• but server with no client is fine.
• Completeness rules can be style-specific

Client
Client
Client
Server
Server
Complete
52
Analysis Refinement Verification

• Refinement can one architecture be substituted
  for another?
• Verification does an implementation conform to
  the architecture?
• Important because supports design at a high level
  of abstraction
• Example Implement a pipe-filter system using
  procedure call

53
Analyzing system-wide properties

• Key idea calculate properties of a system, given
  properties of its parts
• Different kinds of property will have different
  calculi for compositionality
• Usually depends on using a specific style
• Example 1 queuing theory can be used to
  calculate overall throughputs and latencies if
  use asynchronous message passing style
• Example 2 reliability block diagrams can be used
  to determine aggregate reliability from the
  parts, for certain styles

54
Example 1 Performance predictions

• Can the servers handle the expected demand?
• Will the average response time meet requirements?
• How large should the buffers be?
• Highest demand the servers can handle?
• Which component is the bottleneck?
• How would server/database replication affect this?

55
Performance Analysis Alternatives

• Measurement
• Most accurate modifications difficult
• Requires existing system, workload
• Simulation
• Accuracy and ease of modifications vary
• Requires existing simulator, workload
• Analytical model
• Back-of-the-envelope accuracy in design phase
• Nontrivial systems require nontrivial
  calculation analysis tools can help.

56
Queuing Networks

• Domain Computer Systems
• Elements
• service centers
• queues, associated with service centers
• Assumptions
• asynchronous arrival of jobs in queues
• exponential rates, independence
• each job exists in exactly one place at a time
• Given for each service center
• average arrival time of jobs
• average service time to process a job
• For details see SG98

57
Queueing Network Predictions

• fraction of time service center is occupied
  (utilization)
• average time a job spends waiting in queue
• average queue length
• probability queue length n
• throughput of a system
• latency for a job processed by system
• number of outstanding jobs in system
• potential bottlenecks

58
Naive Application to SW Arch

• Define an architectural style in which
• Service centers distributed processing
  components
• Transmission lines directional asynchronous
  message passing connectors
• Associate service times with components and
  arrival rates with system
• Use Queueing Networks to calculate derived values
  for the components and the system

59
Complicating Factors

• Cycles -- jobs may pass through same component
  several times before exiting
• Autonomous clients -- generate jobs by themselves
• Delays in connectors -- present for architectures
  of real systems
• Replication -- meaning and effect on calculations

60
QN Example Local Properties

• User defines local performance properties by
• Simulation
• Guesstimate
• Measured values

Component microbiology-db Ports
Property localPerformance replication
2 serviceTime 1000ms outputMessagePaths
Property computedPerformance
?
61
QN Example Emergent Global Properties
System hospitalMIS Property
systemPerformance avgResponseTime
2784ms avgSystemMsgs 2.342 Component
microbiology-db Ports Property
localPerformance Property
computedPerformance avgResponseTime
2143ms avgQueueLength 0.923 avgUtilization
0.48 overloaded false

• Tool computes system-wide performance properties
  based on configuration

62
Example 2 Reliability predictions

• Basic idea apply Reliability Block Diagrams to
  Software Architecture
• Reuses well developed reliability model
• Slightly modified to work with Software Arch.
• Initial information includes
• reliability of individual components
• topology of interaction, concurrency, replication
• From this we calculate expected reliability of
  the system as a whole.
• Reliability defined as R e-?T where
• ? is a components failure rate
• T is the time period over which reliability is
  measured

63
Reliability Block Diagrams Example

• Example from
• Abd-Allah, Ahmed, Extending Reliability Block
  Diagrams to Software Architectures, USC
  Technical Report USC-CSE-97-501. AbdAllah97

Serial Composition
Parallel Composition
64
Reliability Block Diagram Complications

• Simple model has some complications
• Concurrency
• Distribution
• Dynamism
• Connectors may be unreliable
• These complications are addressed for many (but
  not necessarily all) styles.
• See AbdAllah97 for details

65
Detailed RBD Example

• Modeling a Java/WWW-based client-server system

server machine
client machine
Example borrowed from AbdAllah97
66
Analysis Evaluating Design Choices
Should you use a database? file system? symbol
table? array? knowledge-base? other?

• What questions should you ask about the
  application?
• How do the answers help you choose a design and
  implementation strategy?
• how do you then make further design decisions?
• what classifications of the alternatives help?
• Can the memory questions be structured?

67
Architecture Tradeoff Analysis Method

• ATAM -- The Architecture Tradeoff Analysis Method
• A framework for evaluating the tradeoffs between
  different design decisions
• Emphasizes design decision interactions
• Supports decision sensitivity analysis
• Better for finding big effects than precise
  numbers
• Spiral design model supports iterative evaluation
  of design options
• Kazman et al, ICECCS 98

68
ATAM Process

• 1) Collect system usage scenarios
• 2) Collect requirements/constraints/envt
• These are the requirements for which analyses
  will be performed
• 3) Describe Architectural Views
• Describe multiple, competing architectural
  options
• 4) Attribute-Specific Analyses
• Analyze properties of each architecture option in
  isolation
• 5) Identify Sensitivities
• Determine the sensitivity of the various
  attributes to the available architectural design
  options
• 6) Identify Tradeoffs
• Determine which architectural elements are
  sensitive to multiple attributes (e.g. of
  servers affects both the cost of the system and
  its overall reliability)
• 7) Repeat

69
Outline

• Introduction to Software Architecture
• Architectural Modeling
• Architectural structure and topology
• Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities challenges

70
Architectural Style Families of Systems
...

• Systems share architectural vocabulary
• Analysis can be shared
• Simplifies design
• Infrastructure can be shared
• Simplifies implementation

71
Elements of Style

• Design Vocabulary -- Architectural Element Types
• Component and connector types
• Interfaces
• Representation/Notation
• Design Rules -- Configuration Constraints
• Topological constraints and patterns
• Valid property value ranges
• Invariants and heuristics
• Default system structure
• Basic infrastructure provided by style

72
Style Example C2

• Architectural style for GUI-based systems
• C2 can be informally summarized as a network
  of concurrent components hooked together by
  message routing devices. Central to the
  architectural style is a principle of limited
  visibility a component within the hierarchy can
  only be aware of components above it and
  completely unaware of components which reside
  beneath it.
• This definition and subsequent details borrowed
  from Tay96 and the UC Irvine C2 website at
  www.ics.uci.edu/pub/arch/

73
Informal C2 Overview

• Desired Properties
• Flexible system extensibility reconfigurability
• Increased component and design reuse
• Primary Component Type C2 Component
• Conforms to standard C2 structure
• Primary Connector Type Message Bus
• Transports messages between components
• Supports multiple distribution and filtering
  policies

74
Informal C2 Overview

• Primary C2 Design Rules
• All communication done through message buses
• Requests sent up, notifications sent down
• Components may be attached to no more than one
  upper bus and one lower bus
• There is no bound on the number of components or
  connectors that may be attached to a single
  connector

From C2 website
75
C2 Tools

• Well-defined style standard supports tools
• C2-specific tools include
• Argo architectural design environment
• Code generation
• Run-time environment that supports dynamic
  component replacement for executing systems
• Design critics provide design guidance
• Consistency and completeness checking

76
Style Example Justo-Cunha
S-R

• Desired Property
• Global Deadlock-freedom
• One Connector Type
• Buffered Message Passing
• Two Component Types
• Send-then-Receive (S-R)
• Receive-then-Send (R-S)
• Topological Constraint
• No cycles of Receive-then-Send

77
Informal Definitions J-C Style

• The S-R component can send its messages and then
  it may block waiting to receive its messages.
  The ltcomputegt part corresponds to a block of
  statements that should not include communication
  and should terminate...
• The R-S component is the dual of the S-R
  component. In this case, the component first
  receives its message, performs some computation
  and then sends messages. Justo94CDS, p. 149

78
Informal Rules J-C Style

• 1. A cycle of R-S component processes always
  deadlocks.
• 2. A cycle of S-R component processes never
  deadlocks.
• 3. A cycle of R-S and S-R component processes
  never deadlocks.
• Justo94CDS, p. 151

79
Formal Spec S-R Component
Component S-R (r1.. s 1..) Port In1..r
ReceiverType Port Out1..s SenderType Computati
on S1 where Outi.send ? Si1, when 1?i?s
Si Ini-s.recv ? Si1, when slti?sr Ini-s.recv
? S1, when i?sr

80
Formal Spec Justo-Cunha Style Rules

• ??c Components ?
• Type(c) R-S ??Type(c) S-R
• ? ??c Connectors ?
• Type(c) MessageBuffer
• ? ????C P Components
• Cycle(C)
• ????c Components ? Type(c) R-S

81
Some Useful J-C Style Formal Definitions

• ??c1,c2 Components ? ConnectsTo(c1,c2)
• ? cn Connectorsp1,p2 Port
• ((c1,p1),(cn,Sender)),
• ((c2,p2),(cn, Receiver))
• ? Attachments
• ??C P Components ? Cycle(C)
• ??S seq C ran S C ?
• ??i 1..S-1 ? ConnectsTo(S(i),S(i1))
• ? ConnectsTo(S(S),S(1))

82
Analyzing Architectural Styles

• Style Properties, Invariants, Theorems
• What is true of all instances of the style?
• Specialization (implication)
• Is one style a substyle of another?
• Inter-style translation
• How can you map a system defined in one arch
  style to another
• Selection
• What style is appropriate for a given problem?

83
Style Analysis Theorems

• Style Properties, Invariants, Theorems what is
  true of all instances of the style?
• Important because can prove a result once that is
  automatically true for a large class of systems
• assuming that its easier to check style
  membership
• Example Encapsulation theorems
• Can a subsystem be encapsulated as a single
  component?
• Often can be proved by structural induction
  over the architectural structure
• Cf. Allen Thesis

84
Proof Technique Encapsulation

• Any component property is configuration property
• Induction on Component
• Component component ??component
• Induction on Connector
• Component connector ??component

85
Style Analysis Specialization

• Specialization (implication) is one style a
  substyle of another?
• Key issue Do the constraints imposed by one
  style imply those of another?
• Important because all theorems about one class of
  system hold for the other
• Examples
• Pipeline as a specialization of Pipe Filter
• Message passing with real-time constraints as a
  specialization of general message passing style

86
Style Analysis Translation

• Inter-style translation How can you map a system
  defined in one arch style to another?
• Important because the most natural architectural
  description may not be directly implementable.
• Moriconi has investigated translation patterns
  and proofs of correctness

Style 1
Style 2
Style 3
87
Style Analysis Selection

• Selection What style is appropriate for a given
  problem?
• Available analyses often determined by style
  selection
• Appropriate styles may guide system development
• Rules of thumb and good taste
• Garlan Shaw book Shaw Clements boxology
  paper
• Integration with requirements negotiation
• Style can clarify impact of requirements(cf.
  Boehms win-win)

88
Outline

• Introduction to Software Architecture
• Architectural Modeling
• Architectural structure and topology
• Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities challenges

89
Some ADLs at a Glance

• Acme architectural tool integration
• Aesop style-specific environments
• Armani designing with constraints
• Darwin distributed systems exo-structure
• Meta-H real-time, fault-tolerant avionics
• Rapide event patterns, arch simulation
• SADL refinement patterns
• UniCon architectural compilation
• Wright protocol analysis

90
Dimensions of Variability

• Most Architecture Description Languages (ADLs)
  agree on use of structure
• Essentially as outlined earlier
• But they differ considerably about
• Kinds of properties that can be characterized and
  analyzed
• Whether there is a fixed set of connector types
• Emphasis on static versus dynamic analysis
• Support for dynamism (runtime system evolution)
• Executability
• Openness (ability to incorporate external tools)
• Domain specificity

91
Meta-H (Honeywell)

• Key Idea Domain-specific ADL for real-time,
  fault-tolerant software
• Main features
• Analysis capabilities
• Real-time schedulability analysis
• Reliability
• Safety/security
• Accepts external generators, libraries
• Automated system builder
• provides runtime communication/synch support
• Integrates hardware and software components
• Applied with success in avionics domain

92
Rapide

• Key Idea Define system behavior using event
  patterns that permit simulation and post facto
  analysis
• Main features
• Behavioral modeling allows one to determine
  erroneous or missing causal information
• Trace viewing capabilities
• Architectural animation
• Supports dynamic architectures
• Applications include X/Open architecture, TRW
  applications

93
Darwin

• Key idea specify structure of distributed
  systems
• Declarative binding language for defining
  dynamically-evolving, hierarchical compositions.
• Component interfaces defined in terms of
  provided/required services
• Fixed set of connector types
• Semantics given in terms of Pi-Calculus
• Behavior of components specified outside system

94
Acme

• Key Idea support ADL integration
• Integrate diverse ADLs and toolsets
• Leverage/integrate capabilities of different ADLs
• Minimize ADL translation effort
• Platform for ADL-independent tool development
• Tool writers can build one tool for many ADLs
• Tool developers dont need to invent new ADLs to
  do architectural analyses
• Rich library for constructing ACME tools reduces
  tool development cost for ACME adopters
• Extensible language base for new ADLs
• Explore ADL ideas by extending ACME instead of
  building a new ADL from scratch

95
Acme

• Tools written to manipulate Acme descriptions
• External tools can treat Acme as another ADL
  toolset

96
Armani

• Extends Acme with composable and reusable design
  constraints
• Captures both invariant and heuristic constraints
• Constraints expressed in logic-based predicate
  language.
• Both types and system instances can specify rich
  constraint predicates
• Emerging tool support for constraint checking
• Text-based language processing infrastructure
• GUI-based environment

97
Aesop

• Key idea support rapid development of custom,
  style-specific software architecture design
  environments.
• Configurable architecture design environment can
  be specialized by loading style descriptions
• Minimizes environment development cost
• Exploits commonalties of families of systems
• Supports domain-specific arch analysis and code
  generation
• Permits integration with external analysis tools
• Reuse legacy applications
• Integration with existing CASE tools
• Sample styles (and analysis)
• Pipe and Filter (code generation)
• Real-Time-Message Passing (schedulability)
• Generic (completeness and consistency checks)

98
GeneratingStyle-Specific Environments
Style Description
Environment For That Style
Aesop Generator
Shared Infrastructure
99
WRIGHT

• Support analysis of arch connection and style
• Explicit connector types
• Support reuse of
• Patterns of interaction
• Components in multiple contexts of interaction
• Capture high-level composition abstractions
• Statically checkable behavior notation
• Capture dynamic communication ordering,
  non-determinism, and locus of control
• Architectural consistency and completeness checks
  (using model checking tools)
• Explicit description of style as constraints
• Leverage analysis over families of systems
• Proofs exploit architectural structure
• Check conformance of configuration to style

100
UniCon

• Open system supports incremental definition and
  compilation of heterogeneous architectures
• Heterogeneous abstractions
• Supports many types of connectors
• Supports many types of components
• Distinct modes of interaction, packaging
• Open System
• Accepts externally developed components,
  connector types and analysis tools
• System construction emphasis
• Separates structure from implementation
• Compiles to std. connector implementations
• Incremental development
• Partial/incremental specifications
• open-ended semantics via property lists

101
UniCon Component and Connector Types

• Abstractions for components
• Computation pure function
• SharedData Fortran common
• SeqFile unix file
• Filter unix filter
• Process unix process
• SchedProcess real-time process
• Module conventional compilation unit
• Abstractions for connectors
• Pipe unix pipe
• FileIO unix ops between process file
• ProcedureCall architectural use of proc
• DataAccess shared data within process
• RemoteProcCall RPC
• RTScheduler processes compete for time
• PLBundler set of procedure calls and data

102
Outline

• Introduction to Software Architecture
• Architectural Modeling
• Architectural structure and topology
• Properties and protocols
• Architectural Analysis
• Architectural Style
• Overview of ADLs and Design Tools
• Conclusions, opportunities challenges

103
Three Ideas To Take Away

• Architecture description languages and toolkits
  (ADLs) are useful for describing, documenting,
  and reasoning about Software Architectures.
• There are a number of interesting and useful
  architecture-level analyses that can be performed
  with existing ADLs and their associated toolkits.
• There are further powerful analysis and
  generation capabilities on the horizon.

104
Software Architecture And Your Organization

• What are some of the difficulties of transferring
  these ideas and capabilities from research labs
  to real software development organizations?
• Immature/research tools
• Lack of awareness/education
• Start-up costs to begin using tools techniques
• and to get first results
• Mismatch with current software development
  processes and tools

105
Software Architecture And Your Organization

• How to begin using software architecture
• Try to describe some portion or aspect of target
  systems
• individual module(s) or subsystems
• single aspect or view across a whole system
• Ask simple questions and demand solid answers
• Rough modeling supports back-of-the envelope and
  simple high-return analyses
• Even rough modeling reveals design discrepancies
• Implement an architectural review process
• Be willing to express analysis results in terms
  that other team members can understand (no ?s)

106
Research Opportunities

• Formal classification of architectures
• comprehensive enumeration of architectural styles
• taxonomic relationships between architectural
  styles
• Analytic basis for architectural selection
• capturing architects' expertise
• applying domain knowledge
• Mismatch when the parts of a system don't fit
  together as well as hoped for
• avoidance guidance about when/why problems are
  most likely to occur
• repair what to do about it

107
More Opportunities

• Architecture Description Languages (ADLs)
• Calculi for non-behavioral properties (e.g.,
  reliability, performance, security)
• Dynamism (evolving architectures at runtime)
  modeling, monitoring, constraining
• Multiple views
• How to combine different representations?
• Architectural interchange
• Canonical representations of architecture so that
  different architectural tool sets can be
  integrated

108
Major Trends in ADL Research

• ADL Integration
• Better system generation capabilities
• New and improved analysis capabilities
• reliability, performance, security
• Dynamism
• modeling, monitoring, constraining
• COTS-oriented styles and tools
• Views integration
• Better integration with other software
  development tools/processes

109
Web Sites of Interest

• CMU Composable Systems Group
• www.cs.cmu.edu/Compose/
• CMU Architecture Based Languages and Environments
  Research Group
• www.cs.cmu.edu/able/
• The Acme ADL
• www.cs.cmu.edu/acme/
• Worldwide Institute of Software Architects
• www.wwisa.org

110
Web Sites of Interest (continued)

• The WRIGHT Language
• www.cs.cmu.edu/able/wright/
• Meta-H For Real-Time Software Analysis
• www.htc.honeywell.com/projects/dssa/dssa_tools/ds
  sa_tools_mh.html
• Rapide ADL
• pavg.stanford.edu/rapide/
• C2 Project at UC Irvine
• www.ics.uci.edu/pub/arch/

111
Web Sites of Interest (continued)

• SEI Product Line Practice Initiative
• www.sei.cmu.edu/plp/plp_init.html
• Tutorial slides
• www.cs.cmu.edu/able/talks_online/icse99_tutorial