advances in effective languages for architecture definition
DESCRIPTION
Advances in Effective Languages for Architecture Definition. David Garlan [email protected] Bradley Schmerl [email protected] ABLE Research Group School of Computer Science Carnegie Mellon University Pittsburgh, PA http://www.cs.cmu.edu/~able. Outline. - PowerPoint PPT PresentationTRANSCRIPT
Advances in Effective Languages for Architecture Definition
David [email protected]
Bradley [email protected]
ABLE Research GroupSchool of Computer ScienceCarnegie Mellon University
Pittsburgh, PA
http://www.cs.cmu.edu/~able
February 7, 2001 Open Group Architecture Program, San Jose, CA
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
February 7, 2001 Open Group Architecture Program, San Jose, CA
3
Architecture in SystemsArchitecture:
“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
February 7, 2001 Open Group Architecture Program, San Jose, CA
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
February 7, 2001 Open Group Architecture Program, San Jose, CA
5
Architectures in Development
Requirements
Code
Architecture Description Languages (ADLs) providea method for specifying software architectures
?Requirements
Code
Software Architecture
February 7, 2001 Open Group Architecture Program, San Jose, CA
6
Why ADLsADLs 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
February 7, 2001 Open Group Architecture Program, San Jose, CA
7
Commonalities among ADLsADLs 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
February 7, 2001 Open Group Architecture Program, San Jose, CA
8
Acme – A Generic ADLAcme 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” semanticsADML was based heavily on Acme, and so the
terminology for Acme applies to ADML
February 7, 2001 Open Group Architecture Program, San Jose, CA
9
Acme Structural Language
connector
componentsystem
role
port
attachment
February 7, 2001 Open Group Architecture Program, San Jose, CA
10
Acme PropertiesProperties provide a semantic extension mechanism to Acme
• Arbitrary attribute-value annotations• Associated with all major language
constructsDomain specific information can be captured in properties
• E.g.: protocols of interaction, performance, reliability
February 7, 2001 Open Group Architecture Program, San Jose, CA
11
Acme Representations• Hierarchical abstractions (encapsulation)• Can represent sub-architectures or “views”
System(sub-architecture)
Binding
Representation
February 7, 2001 Open Group Architecture Program, San Jose, CA
12
Architectural StylesNeed 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
February 7, 2001 Open Group Architecture Program, San Jose, CA
13
Style ExampleIf 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
February 7, 2001 Open Group Architecture Program, San Jose, CA
14
ADMLADML (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 extensibilityHowever, Acme has been extended in recent years
February 7, 2001 Open Group Architecture Program, San Jose, CA
15
Armani Design ConstraintsArmani 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 rangesTwo types of constraints
• Invariants must never be violated• Heuristics should be observed but may be selectively
violated
February 7, 2001 Open Group Architecture Program, San Jose, CA
16
Current ResearchMapping 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
February 7, 2001 Open Group Architecture Program, San Jose, CA
17
Acme Tools at CMU
AcmeLib – A foundation for building tools
AcmeStudio
Armani constraintchecking
Performance analysis
AcmeADMLxArchMeta H…
February 7, 2001 Open Group Architecture Program, San Jose, CA
18
AcmeStudioGraphical 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)
February 7, 2001 Open Group Architecture Program, San Jose, CA
19
AcmeLibAcmeLib 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 JavaAcmeLib is a common data structure that can be used as the foundation for various architectural tools
February 7, 2001 Open Group Architecture Program, San Jose, CA
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)
February 7, 2001 Open Group Architecture Program, San Jose, CA
21
xArch ExtensionsSeveral 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
February 7, 2001 Open Group Architecture Program, San Jose, CA
22
xArch, Acme, ADML
xArch
ADML*
ADML+
Core-Acme
Acme
Acme+Armani
structure
properties, types,families
constraints
events, versions, patterns
XML Acme Contents
February 7, 2001 Open Group Architecture Program, San Jose, CA
23
UMLUML 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
February 7, 2001 Open Group Architecture Program, San Jose, CA
24
Acme and UMLTwo 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
February 7, 2001 Open Group Architecture Program, San Jose, CA
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