Advances in Effective Languages for Architecture Definition

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. 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 Open Group Architecture Program, San Jose, CA

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 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 Open Group Architecture Program, San Jose, CA

5. Requirements ? Software Architecture Code Architectures in Development Requirements Code Architecture Description Languages (ADLs) providea method for specifying software architectures Open Group Architecture Program, San Jose, CA

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 Open Group Architecture Program, San Jose, CA

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 Open Group Architecture Program, San Jose, CA

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 Open Group Architecture Program, San Jose, CA

9. port role attachment Acme Structural Language system component connector Open Group Architecture Program, San Jose, CA

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 Open Group Architecture Program, San Jose, CA

11. Representation Binding System (sub-architecture) Acme Representations • Hierarchical abstractions (encapsulation) • Can represent sub-architectures or “views” Open Group Architecture Program, San Jose, CA

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 Open Group Architecture Program, San Jose, CA

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 Open Group Architecture Program, San Jose, CA

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 Open Group Architecture Program, San Jose, CA

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 Open Group Architecture Program, San Jose, CA

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 Open Group Architecture Program, San Jose, CA

17. Armani constraint checking Performance analysis AcmeStudio Acme ADMLxArch Meta H … Acme Tools at CMU AcmeLib – A foundation for building tools Open Group Architecture Program, San Jose, CA

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) Open Group Architecture Program, San Jose, CA

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 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) Open Group Architecture Program, San Jose, CA

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 Open Group Architecture Program, San Jose, CA

22. XML Acme Contents xArch ADML* ADML+ Core-Acme Acme Acme+Armani structure properties, types, families constraints events, versions, patterns xArch, Acme, ADML Open Group Architecture Program, San Jose, CA

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 Open Group Architecture Program, San Jose, CA

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 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 Open Group Architecture Program, San Jose, CA