1 / 23

Advances in Effective Languages for Architecture Definition

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. Outline.

jaegar
Download Presentation

Advances in Effective Languages for Architecture Definition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 • Extending Acme • Tool support for Acme at CMU • Current and future directions • xArch – XML infrastructure • Liaison with UML working group Open 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 Open Group Regional Meeting, Washington DC

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

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

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

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

  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 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 Open Group Regional Meeting, Washington DC

More Related