Architectures for Software Systems - PowerPoint PPT Presentation

1 / 58
About This Presentation
Title:

Architectures for Software Systems

Description:

Aesop style-specific arch design languages. ArTek TeKnowledge description language ... Example Environment: Aesop/PF. 14. 14. Software Architectures David Garlan ... – PowerPoint PPT presentation

Number of Views:97
Avg rating:3.0/5.0
Slides: 59
Provided by: DAVIDG182
Category:

less

Transcript and Presenter's Notes

Title: 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.
Write a Comment
User Comments (0)
About PowerShow.com