Advances in Effective Languages for Architecture Definition

1
Advances in Effective Languages for Architecture
Definition

• David Garlan
• garlan_at_cs.cmu.edu
• Bradley Schmerl
• schmerl_at_cs.cmu.edu
• ABLE Research Group
• School of Computer Science
• Carnegie Mellon University
• Pittsburgh, PA
• http//www.cs.cmu.edu/able

2
Outline

• Introduction to software architecture
• Terminology of Acme and ADML
• Current and ongoing Acme developments
• Tool support for Acme at CMU
• Current and future directions
• xArch XML infrastructure
• Liaison with UML working group

3
Architecture in Systems

• Architecture
• the underlying structure of things
• not just what, but why
• Good architecture (like much good design) is
• the result of a consistent set of principles and
  techniques, applied consistently through all
  phases of a project
• resilient in the face of (inevitable) changes
• source of guidance throughout the product
  lifetime
• reuse of established engineering knowledge

4
Issues Addressed by Architectural Design

• Gross decomposition of a system into interacting
  components
• typically hierarchical
• using rich abstractions for component interaction
  (or system glue)
• often using common design idioms/styles
• Emergent system properties
• performance, throughput, latencies
• reliability, security, fault tolerance,
  evolvability
• Rationale and assignment of function to
  components
• relates requirements and implementations
• Envelope of allowed change
• load-bearing walls, limits of scalability and
  adaptation
• design idioms and styles

5
Architectures in Development
Requirements
Code
Architecture Description Languages (ADLs)
providea method for specifying software
architectures
6
Why ADLs

• ADLs provide a way to model designs precisely and
  explicitly
• Focus attention on essential design factors
• Enable unambiguous communication
• Provide a secure foundation for reasoning
• Enable automated analysis
• There are over a dozen ADLs in use today

7
Commonalities among ADLs

• ADLs largely agree on use of structure
• Components define the locus of computation
• E.g. filters, databases, objects, clients,
  servers
• Connectors mediate component interactions
• E.g. procedure call, pipes, event broadcast
• Interfaces component interface to envt.
• E.g., http socket, corba/com interface
• Properties specifications for compilation and
  analysis
• E.g. signatures, pre/post conditions, RT specs

8
Acme A Generic ADL

• Acme was originally developed as an exchange
  language for architecture descriptions
• Embodies commonality between ADLs
• Domain-Neutral structural descriptions
• Properties for encoding semantics
• Extensibility through type-system and tools
• This is in contrast with other ADLs, which have
  hard-wired semantics
• ADML was based heavily on Acme, and so the
  terminology for Acme applies to ADML

9
Acme Structural Language
system
component
connector
10
Acme Properties

• Properties provide a semantic extension mechanism
  to Acme
• Arbitrary attribute-value annotations
• Associated with all major language constructs
• Domain specific information can be captured in
  properties
• E.g. protocols of interaction, performance,
  reliability

11
Acme Representations

• Hierarchical abstractions (encapsulation)
• Can represent sub-architectures or views

12
Architectural Styles

• Need to capture domain-specific architectural
  elements
• For specific kinds of components, connectors
• For a particular software system or enterprise
• This is done through the definition of Acme
  families
• Defines architectural vocabulary
• Defines constraints on use of that vocabulary
• May define specialized visualization for tools

13
Style Example

• If we are defining a software system using a
  style called Pipes and Filters, then we can
  define types
• Pipe a particular kind of connector, with two
  roles named source and sink
• Filter a particular kind of component, with
  default ports in and out
• Architectures defined in this style can make use
  of this vocabulary

14
ADML

• ADML (Architecture Description Markup Language)
  is
• An XML encoding of architectures (as already
  outlined)
• Being promoted by the Open Group for
  specification of enterprise architectures
• Originally developed at MCC
• ADML adds to Acme
• Industry-standard representation (parsable by
  ordinary XML parsers)
• The ability to define links to objects outside
  the architecture
• Straightforward ability to interface with
  commercial repositories, and transparent
  extensibility
• However, Acme has been extended in recent years

15
Armani Design Constraints

• Armani is a constraint language extension to Acme
• Based on first-order predicate logic
• Augmented with architecture-specific predicates
• For defining architectural element types and
  styles
• Armani constraints specify how a design may
  evolve over time. Examples
• A particular type of component can only have
  particular types of ports
• Property values must be within certain ranges
• Two types of constraints
• Invariants must never be violated
• Heuristics should be observed but may be
  selectively violated

16
Current Research

• Mapping between multiple views
• Expresses correspondence between multiple views
  of an architecture
• Runtime architectural events
• Dynamic events in an architectural context
• Repair strategies
• Architectural modifications that can occur at
  runtime when constraints fail

17
Acme Tools at CMU
AcmeLib A foundation for building tools
18
AcmeStudio

• Graphical design environment for Acme
• Supports development and analysis of
  architectural descriptions
• Customizable for different architectural styles
• Domain-specific design vocabulary captured in
  types and families
• Graphical depictions of architecture based on
  style
• Style-specific analysis tools
• Interfaces to other design tools
• Armani constraint checker
• Various analysis tools (e.g., performance
  analysis)
• Exports ADML (import planned)

19
AcmeLib

• AcmeLib is a library supporting Acme
• Defines an object library for creating and
  manipulating architectural representations in
  Acme
• Provides parser/unparser to import/export Acme
  descriptions
• Available in C and Java
• AcmeLib is a common data structure that can be
  used as the foundation for various architectural
  tools

20
xArch

• A core XML representation for architecture
  structure
• Simpler than ADML/Acme just hierarchical
  component-connector graphs
• Defined using an XML Schema
• For use within DARPA/DASADA Program
• For experimentation and future extension
• Developed in collaboration with CMU
  (Garlan/Schmerl), UCI (van der Hoek/Taylor) and
  TeKnowledge (Wile)

21
xArch Extensions

• Several groups are extending xArch
• CMU ADML/Acme extension
• Plans to marry xArch and ADML
• Layered approach
• Initially Types, Properties, Families
• Later Constraints, mappings, events
• UCI extensions
• Currently Types, Versions and variants,
  Implementation

22
xArch, Acme, ADML
23
UML

• UML story is needed
• To support integration of software architecture
  with standard UML tools and notations
• Architectures and UML used for different phases
  of a design lifecycle
• Many ways to encode architectures in UML
• UML experts may assign different semantics
  depending on which strategy is used

24
Acme and UML

• Two paths for integrating Acme and UML
• Provide translators between Acme and UML
• Collaboration with OMG to include architectural
  concepts in UML 2.0
• Proposal for UML 2.0 extensions due out soon
• Includes extensions to UML metamodel for
  architectural modeling
• Taking Acme as a starting point
• Both paths are being pursued at CMU

25
Summary

• Acme and ADML distill elements common to other
  ADLs
• Research is continuing in software architecture
  on several fronts
• There is a need to reconcile different XML
  encodings
• There is ongoing work in understanding and
  codifying the relationship between architectures
  and UML
• For more information
• http//www.cs.cmu.edu/able