xADL 2.0: A Highly-Extensible, XML-Based Architecture Description Language

1. xADL 2.0:A Highly-Extensible, XML-Based Architecture Description Language Eric M. Dashofy edashofy@ics.uci.edu ICS 223/280 W2003

2. Discussion Topic #1 • What is the purpose of a software architecture description language?

3. Discussion Topic #2 • What, then, should go in an architecture description language? • Motivating discriminators: • At what level of detail? • Is UML sufficient? • How does the purpose of an ADL influence what should go in the ADL? • Is one ADL sufficient? • Are some features more important than others? Why? Howso?

4. Existing ADLs Product Families Koala Darwin Distributed Systems Wright Behavioral Properties Rapide Events Mae Implementation Mappings Configuration Management xADL 1.0 Dynamic Systems Mobile, Dynamic Architectures Darwin, C2SADL ????

5. A Survey of ADLs • Medvidovic survey [MT00] reveals: • A proliferation of ADLs available • Much commonality among them • Components, Connectors, Links • Deeper pairwise similarities • E.g. Mae and Koala • Points of variation are “killer features” • Each ADL has a small subset of killer features • These features supported by tools • Many “killer” features are orthogonal!

6. The Problem • How can we exploit commonalities and experiment with different features in an ADL without duplicating effort?

7. Solution: An Extensible ADL • Our target ADL should support modular extensiblity • This allows the ADL’s users to: • Encapsulate ADL features in “modules” • Add new modules to: • Add new features • Extend existing features • Make tools available efficiently • Experiment with different combinations of modeling constructs The ADL will be independently extensible by users with different, possibly conflicting goals.

8. XML As the Basis for a Modularly Extensible ADL • XML is good for structured data storage and interchange • XML tools and technologies are proliferating • XML schemas provide a metalanguage for developing modular languages • Provide a subtyping mechanism that does not require modification of the base type definition

9. Run-Time Instances CM/Product Families (Versions, Options, Variants) Types & Structure (Design Time) (ADL Core) (Future Expansions) Implementation Mappings xADL 2.0 • xADL 2.0 = A set of modules that form an ADL • Each module is a schema – 100-500 lines of XML

10. Design-Time Schema: Core • Five core structural constructs • Components • Loci of computation • Connectors • Loci of communication • Interfaces • Connection points between component/connector & outside world • Links • Semantic free associations between interfaces • “If links had semantics, they’d be connectors” – Dashofy’s 8th law of Architectures • Groups • Semantically meaningful association among things

11. Design-Time Schema (cont) • Three constructs for reasoning about relationship between structural elements • Component Type • Has signatures (prescribed interfaces) • (Can have subarchitecture) • Connector Type • Has signatures (prescribed interfaces) • (Can have subarchitecture) • Interface Type • (Why is there no link type?)

12. How do subarchitectures work? • Subarchitectures are properties of types, not structural elements • Two components share a type they share a subarchitecture • Signature-interface mappings connect the inner world to the outer world

13. Example with Subarchitecture “AOL-style” instant messaging app Server Conn1 Client1 Client2 Structure

14. Example with Subarchitecture “AOL-style” instant messaging app Server Server_Type Client_Type Conn1 Conn_Type Client1 Client2 ChatIface_Type Types Structure

15. Example with Subarchitecture “AOL-style” instant messaging app Server Server_Type Client_Type Conn1 Conn_Type Client1 Client2 ChatIface_Type Types Structure

16. Example with Subarchitecture “AOL-style” instant messaging app Server Server_Type Client_Type Conn1 Conn_Type Client1 Client2 ChatIface_Type Types Structure

17. Example with Subarchitecture “AOL-style” instant messaging app Server Server_Type Client_Type  Look inside here Conn1 Conn_Type Client1 Client2 ChatIface_Type Types (View as a library of independent types) Structure

18. Example with Subarchitecture “AOL-style” instant messaging app Client_Type  Look inside here Types GUI Network Conn (subarchitecture) Local Conn Content Filter Note: All structural elements inStructure 2 also have types, notdepicted here. Those typesmay also have subarchitectures.Eventually you run into a floorwhere all types are atomic. Ads Ads Ads Structure 2 (May be in a different file)

19. Design-Time vs. Run-Time Behavior information for static analysis Event queue contents Run-time State Comp1_Beh{ If(recv(evt(q))){ doProcess(q) emit(evt(b)); } } a b a - - Design-oriented Properties Author=André Author=Dick Last Update: 08/18/2001 State= BLOCKED Waiting on event “A” Comp Inst 1 Comp1 Comp Inst 2 Comp2 Conn Inst 1 Conn1 Comp Inst 3 Comp3 Constraints Machine = magister Pid = 242 CPU = 1 Port = 8080 … Invariant a{ comp1.interface .type = top -> comp1.interface .link.type = bottom } Information about distributed components

20. Design-time vs. Run-timein xADL 2.0 • Instances model run-time aspects • Component Instances • Connector Instances • Interface Instances • Link Instances • Subarchitectures • General Groups Independently Extensible Models types.xsd instance.xsd • Structure & Types model design • Components • Connectors • Interfaces • Links • General Groups • Subarchitectures • Component types • Connector types • Interface types

21. Implementation Mappings Comp1 Foo.class Comp2 Baz.dll Conn1 Comp4 .NET Service Comp3 Bar.jar Adding information about implementations to component, connector, and interface types is essential if the architecture is to be instantiated.

22. Implementation Mappingsin xADL 2.0 extends implementation.xsd javaimplementation.xsd • Abstract Implementation • “Placeholder” for implementation data on: • Component Type • Connector Type • Interface Type • Java Implementation • Concrete schema for Java implementation data

23. CM/Product Family Architectures 1.0 Component With Variant Type Version Graph for Type T Comp1 1.1 Comp2 2.0 1.1.1 Comp4 1.1.2 Comp3 3.0 Optional Component & Link

24. CM/Product Family Architectures in xADL 2.0 • Options • Optionalcomponents • Optionalconnectors • Optionallinks versions.xsd options.xsd variants.xsd • Versions • Version graphsfor: • Componenttypes • Connectortypes • Interfacetypes • Variants • Variantcomponenttypes • Variantconnectortypes

25. Product Family Example PAL Grad Student TV Professor TV NTSC Television Sets

26. TV Product-lineArchitecture Note: Interfacespresent but omittedfor simplicity. NTSC_Tuner_Type Variant_Tuner_Type Tuner V1: (loc==USA) PAL_Tuner_Type V2: (loc==EUR) Channel Select Conn Conn_Type Variant Component Type Channel_Select_type Picture in Picture (model==PROF) Pic_in_Pic_Type Infrared Rcvr Infrared_Rcvr_Type Optional Component and Link Structure Type Library

27. Semantics in xADL 2.0 • As with any XML-based language, only syntax is enforced by XML tools • xADL 2.0 schemas, to date, are a semantically neutral feature set for describing architectures • Future schemas can provide more semantic information, supported by tools

28. Total Set of Schemas Instances Structure & Types Versions Options Variants Abstract Implementation Architecture Diffing Messaging Interfaces Java Implementation Type Relationships

29. Tool support • COTS/Open Source XML tools • XML Authority, XML Spy, Apache Xerces • In-house tools • DOM-based Java Libraries • Programmatic, syntax-directed editing of xADL 2.0 documents, hiding nearly all of XML • Apigen • Generates DOM-based Java Libraries using only the XML schemas • ArchEdit • Syntax-directed graphical tree-based editor • Menage • Graphical editor focusing on product-line features • “Visio for xADL” • Microsoft Visio extensions provide graphical visualization and editing capabilities for xADL 2.0 architectures

30. Experience & Evaluation • Lockheed Martin Systems Integration • AWACS aircraft software systems modeled in 10,000 lines of xADL 2.0 • Used as the basis for an architecture-derived simulation of the inter-component communication on AWACS • Jet Propulsion Laboratories (JPL) • Extended xADL 2.0 to add domain-specific interface descriptions • Experimenting with modeling software architectures in xADL 2.0 for use in future Mars missions

31. Related Work • [MT00] Medvidovic, Taylor Survey • A Classification and Comparison Framework for Software Architecture Description Languages.IEEE Transactions on Software Engineering, vol. 26, no. 1, pp. 70-93, January 2000. • First-Generation ADLs • C2SADL, ACME, Wright, Darwin, Rapide • XML DTD-based ADLs • xADL 1.0, ADML • Product-line ADLs • Koala, Mae

32. Future Extensions • Arch Diffing and Merging • Determines the difference between two xADL 2.0 architectures • Can merge (architecture + diff)  architecture’ • Dynamic & Distributed Architectures • Graphical layout information

33. Summary • Motivation • Architecture research needs flexible ways to deal with novel modeling constructs and combinations thereof • A modularly extensible ADL is the key • xADL 2.0 • A modularly-extensible ADL based on XML schemas • Get into new domains quickly and effectively • Provides novel, reusable features • Design-time vs. Run-time, Implementation Mapping, Configuration Management / PFA support • Positive initial experiences • Significant tool support • Visit the Website! • http://www.isr.uci.edu/projects/xarchuci/

35. Feature Interaction • xADL 2.0 does not solve the feature interaction problem • When presented with two conflicting schemas: • Do not model the feature • Choose one schema over the other • Rewrite one or both schemas to be compatible • Translate between the two with tools

36. Desirable Features of an ADL • Extensiblity • Ability to add new constructs without knowing, a priori, what information they contain • Incrementality • Ability to expand on these constructs as new needs/research ideas arise • Modularity • Ability to use only a subset of the total feature set • Base Feature Set • Semantically agnostic features that provide a framework for future development

37. Existing XML-based ADLs • xADL 1.0 • From UCI • Key features include implementation mapping, analyzable properties (from C2SADL) • Extension through standard DTD mechanisms • ADML • From MCC • A translation of ACME 1.0 into an XML DTD • Extension through properties

38. Numbers • Average xADL 2.0 extension schema • 100-500 lines of XML schema • Including comments • Yes, it scales • Largest xADL 2.0 schema to date: AWACS • 150+ components, 150+ connectors • 10,000 lines of valid xADL 2.0 • Generated by <1000 lines of boilerplate Java calilng DOM-based libraries

39. Is it an Interchange Format? • It can be, but it’s not meant to be • Since xADL 2.0 is so extensible, it can quickly take on the modeling characteristics of other ADLs • Have created xADL 2.0 extensions that capture PLAs • Koala • Mae • Lossless translation from other ADLs is possible

40. Tool Interoperability • In theory, well-built tools should be able to interoperate with unknown extensions • Example: “List all components in the architecture.” • Meta-level tools like ArchEdit and Visio for xADL show the potential • More semantically-oriented tools can share common extensions & related semantics.

41. Independent Extensions • JPL has refined interface specifications • Extensions underway by various researchers at UCI to add analysis data • xACME from CMU is another set of xArch extensions • Compatibility under evaluation

42. Feature Interaction Problem • The key problem in extensible languages • Many architectural modeling constructs are conceptually orthogonal • Architects choose the subset of features they want to use, potentially minimizing interactions

43. What About UML? • UML is not (yet) an ADL • Some work underway to adapt/extend UML to encompass architectural concepts • xADL 2.0 = lightweight experimental platform • UML = heavyweight comprehensive design notation