Architectures for Software Systems

1

• Architectures for Software Systems
• Lecture 3
• Frontiers of Software Architecture

David Garlan Carnegie Mellon University
2
Course Outline

• Lecture 1 Overview of Software Architecture
• What is software architecture?
• Architectural Concepts Styles
• Lecture 2 Architecture in Practice
• Architecture in context
• Product lines and frameworks
• Evaluating architectures
• Lecture 3 Frontier of Software Architecture
• Emerging techniques and technologies
• How to find out more about this topic

3
This Lecture

• This lecture summarizes recent research in
  software architecture
• The goal is to give you an idea of what is on the
  horizon
• Ill spend a little time talking about formal
  modeling and analysis of software architecture
• I conclude by listing a number of sources for
  additional information

4
Some Research Topics in Software Architecture

• 1. Languages for Software Architecture
• Beyond existing MILs
• 2. Tools and Environments
• Automated support for architectural design
• 3. Formal Analysis of Software Architectures
• Reasoning about architectural description
• 4. Heterogeneity and Architectural Mismatch
• Coping with mismatched parts
• 5. Architectures for Pervasive and
  Network-Centric Computing
• When computing is everywhere

5
Representing Software Architecture
Requirements
Software Architecture
???
Code
6
The Challenge for Architectural Description

• Software Architecture frees us from the shackles
  of programming language abstractions
• new kinds of components
• not just abstract data types, modules, and
  objects
• new kinds of glue
• not just procedure call, data sharing
• new patterns, idioms, styles for system structure
• not just for algorithms and data structure
• new properties of interest
• not just functional correctness

7

• How can we establish intellectual control over
  this new world?
• (1) express arch descriptions precisely and
  intuitively
• both syntax and semantics
• (2) develop soundness criteria tools to check
  them
• what type checkers and linkers do for current
  systems
• (3) analyze architectures to determine key
  properties
• such as performance, reliability, change impact,
  interoperability
• (4) exploit patterns and styles
• without unnecessary proliferation and isolation
  of new design languages and tools

8
Architecture Description Languages

• A number of architecture description languages
  (ADLs) have been developed that attempt to do
  this
• Each language and supporting tool set
• emphasizes different aspect of arch
• is good for some things bad for others
• Some examples
• Rapide events with simulation and animation
• UniCon emphasizing heterogeneity and compilation
• Wright formal specification of connector
  interactions
• Aesop style-specific arch design languages
• ArTek TeKnowledge description language
• SADL SRI language emphasizing refinement
• Meta-H arch description for avionics domain
• C-2 arch style using implicit invocation

9
Key Features of Modern ADLs

• System structure is defined separately from
  individual components
• parts are context independent
• supports hierarchical design
• Components have multiple interfaces
• different points of interaction with their
  environment
• New kinds of connectors can be defined
• need not be realizable directly in a primitive of
  an implementation language
• have rich semantics
• Can express/analyze extra-functional properties
• performance, reliability, etc.
• Support for architectural styles
• reusable architectural patterns

10
Tool Support for Architectural Design
Tool
Tool
Tool
?
?
?
???
Architectural Design
Tools compatability checker real-time
analyser etc...
Designer
11
Example Environment C2
12
Example Environment Meta-H
13
Example Environment Aesop/PF
14
Example Environment ObjecTime
15
Architectural Structure
16
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

17
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 database.rece
iveReq to conn.callee
viewer
database
18
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

19
Representations

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

20
Abstraction Maps
21
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 ...

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

23
Beyond Simple Structure

• What else can we represent besides structure?
• 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 ...

24
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
25
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
26
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)

27
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
28
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

29
Checking 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 can be checked automatically using
model checking
30
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

31
Example The HLA Architecture
Federate
Federate
...
Runtime Interface (RTI)
32
WRIGHT View an RTI Connector
Glue
Runtime Interface (RTI)
FedInterface (Role)
33
Paused on Join
Federate
Federate
(1) joinFedExecution (2) requestPause (3)
schedulePause (4) pauseAchieved
(5) joinFedExecution (6) requestPause
RTI
34
Oops!
Federate
Federate
(1) joinFedExecution (2) requestPause (3)
schedulePause (4) pauseAchieved (7)
schedulePause
(5) joinFedExecution (6) requestPause
RTI
35
Results

• Modeled 5/6 of HLA behavior in Wright
• about 20 pages
• initially part of Robert Allens Ph.D. thesis
• 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
• many critical problems found using model checker
  (FDR)

36
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
37
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???
38
Lessons from the ADL CommunityWhat Needs to Be
First Class and Why?

• Connectors
• analyze whether two components can communicate
• determine system performance (throughput,
  latencies)
• Styles
• define and analyze a design vocabulary
• tailor tools and analyses to specific domains
• impose constraints on system topology
• Interfaces
• determine what a component requires of its
  environment
• understand attributes of an interface (e.g., max
  trans rate)
• Representations
• allow multiple elaborations of a design element
  (including connectors and interfaces
• show that a more detailed design implements
  another
• Visualizations
• support visual conventions of specific domains

39
Arch Description and UML
Requirements
ADLs
UML
Code
40
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.

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

42
What is Needed?

• NO a large number of UML Profiles that each
  reintroduce the same semantic notions missing
  from UML.
• e.g., the Capsules and Ports of the proposed
  UML Real-time Profile
• YES a careful examination of what is missing,
  awkward, unanalyzable
• YES a critical comparison of encoding strategies
  and the conditions under which each might be
  appropriate.
• YES changes to UML to make it more hospitable
  for architectural description

43
Synergies

• Patterns
• Parameterized structures
• Views
• Multi-dimensional viewpoints and their relations
• Dynamism
• Run-time structural changes
• Analysis
• Better support needed

44
Building Systems from Parts

• The hype
• ... and then well be able to construct
  software systems by picking out parts and
  plugging them together, just like Tinkertoys ...
• The hard cold truth
• Its more like having a bathtub full of
  Tinkertoy, Lego, Erector set, Lincoln logs, Block
  City, and six other incompatible kits -- picking
  out parts that fit specific functions and
  expecting them to fit together

45
Working with Mismatched Parts
Problem
A
B
?
?
A, B might be peer applications, peer components,
or caller/library, etc form might be
representation, communications, packaging,
semantics
46
Fixing Architectural Mismatch

• Current techniques include

47
Forces for Change Technical

• Pervasive Computing
• Proliferation of computing devices (e.g.,
  toasters, entertainment systems, cars), many with
  dedicated embedded processors
• Heterogeneous capabilities (e.g., toasters vs
  PDAs vs cell phones vs high-end workstations)
• Mobile computing (e.g., in cars and airplanes)
• Network-centric Computing
• Enabled by increasing connectivity of systems and
  information
• PCs become front ends to services information
  available on the net
• Tasks performed by coalitions of resources
  enlisted by the user
• Coalitions must be reconfigured dynamically as
  resource mix changes

48
Example Network-Centric Computing

• Internet provides rich variety of resources
• information, calculation, communication, services
• Autonomous, heterogeneous, interactive
• Inevitably, these will be incorporated in systems
• Coalitions, not true systems--open-shop, not
  closed shop development
• Specifications scanty and less than reliable
• Resources subject to unannounced change
• Problems brittleness get worse
• Research opportunities
• How to identify and validate a resource, then
  incorporate it
• How to determine what a coalition does and keep
  it doing that
• How to make it possible for nonexperts to recruit
  coalitions

49
Research Challenges and Opportunities

• Better principles, notations,tools for
  integration frameworks
• not just APIs
• SW architectures that scale with size/variability
  of the Internet
• millions of nodes, frequent reconfiguration, many
  formats/protocols
• Open, dynamic resource coalitions
• no longer under control of single organization or
  proprietor
• Techniques for bridging architectural mismatch
• heterogeneous data formats, component
  technologies
• Ensuring suitable properties for distributed
  system configurations
• even though absolute correctness is not
  achievable
• Architectures for mobility
• resource-aware, highly dynamic, multi-device

50
Resources

• Web sites
• Books and journals
• Conferences and Workshops

51
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/
• SEI Product Line Practice Initiative
• www.sei.cmu.edu/plp/plp_init.html

52
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/

53
Books

• Software Architecture Perspectives on an
  Emerging Discipline, Shaw Garlan. Prentice Hall
  1996.
• Software Architecture in Practice, Bass,
  Clements, Kazman. Addison Wesley 1998.
• The Art of Systems Architecting, Eberhardt
  Rechtin.
• Applied Software Architecture, Hoffmeister, Nord,
  Soni. Addison Wesley.
• Software Requirements Specifications, Michael
  Jackson. Addison Wesley, 1995

54
Books (continued)

• Problem Frames, Michael Jackson. Addison Wesley
  2000.
• Pattern-oriented Software Architecture,
  Buschmann, Meunier, Rohnert, Sommerlad, Stah.
  Wiley 1996.
• Other books on design patterns
• Software Architecture Documentation in Practice,
  Clements, Bachmann, Bass, Garlan, Ivers, Little,
  Nord, Stafford (to appear 2001).

55
Conferences and Workshops

• International Conference on Software Engineering
  (ICSE)
• annual major sw eng conference
• 1999 had approx 20 papers on software
  architecture
• Symposium on the Foundations of Software
  Engineering (FSE)
• annual conference, oriented toward research
• International Software Architecture Workshop
  (ISAW)
• next meeting will be with ICSE00, Limerick,
  Ireland

56
Conferences (continued)

• Coordination NN
• annual conference on coordination languages
• proceedings available through Springer Verlag
• New IFIP Software Architecture Working group to
  be formed
• WICSA 2001 to be held in Amsterdam in September,
  2001

57
ICSE 99 Case studies in Software Architecture

• Haemo Dialysis, Althin Medical
• product-line framework for safety-critical
  medical equipment
• Framework Modeling in Telecommunications
• layered architectures for telecommunications
• Baseball Seasons and Dog Years
• Web support for Instant Baseball
• Linux
• Operating systems structures
• Product lines for Axis Communications and
  Securitas
• printer/scanner/storage services security
  systems
• Real-Time Data Feeds
• COM-based arch for data feeds, such as Reuters

58
Summary

• Software architecture is a critical aspect in the
  design and development of software-based systems
• Principles of architectural engineering are now
  emerging, and will continue to do so over the
  next few years.
• New tools, languages, and methods are in
  development, and should become ready for
  industrial use in the next year or two.
• Good architectural design requires human
  creativity and hard work, but it can be
  significantly improved by understanding basic
  ideas of architectural design, including the
  principled use of styles, architecture-based
  analyses, and rigorous architectural
  documentation and review.