1. Advances in Effective Languages for Architecture Definition David Garlan garlan@cs.cmu.edu Bradley Schmerl schmerl@cs.cmu.edu ABLE Research Group School of Computer Science Carnegie Mellon University Pittsburgh, PA http://www.cs.cmu.edu/~able

2. 23 January 2001Open Group Regional Meeting, Washington DC 2 Outline Introduction to software architecture Terminology of Acme and ADML Extending Acme Tool support for Acme at CMU Current and future directions »xArch – XML infrastructure »Liaison with UML working group

3. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 5 Architectures in Development Requirements Code Architecture Description Languages (ADLs) provide a method for specifying software architectures. ? Requirements Code Software Architecture

6. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 9 Acme Structural Language connector component system role port

10. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 11 Acme Representations Hierarchical abstractions (encapsulation) Can represent sub-architectures or “views” System (sub-architecture) Binding Representation

12. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 14 ADML ADML (Architecture Description Markup Language) is: An XML encoding of architectures (as already outlined) Being promoted by the OpenGroup 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. 23 January 2001Open Group Regional Meeting, Washington DC 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 have certain values Two types of constraints Invariants must never be violated Heuristics should be observed but may be selectively violated

16. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 17 Acme Tools at CMU AcmeLib – A foundation for building tools AcmeStudio Armani constraint checking Performance analysis Acme ADML xArch Meta H …

18. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 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. 23 January 2001Open Group Regional Meeting, Washington DC 22 xArch, Acme, ADML xArch ADML* ADML+ Core-Acme Acme Acme+Armani structure properties, types, families constraints events, versions, patterns XMLAcmeContents

23. 23 January 2001Open Group Regional Meeting, Washington DC 23 Acme and 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 Two paths for integrating Acme and UML Provide translators between Acme and UML Collaboration with OMG to include architectural concepts in UML 2.0 Both paths are being pursued at CMU