x ADL 2 0 A HighlyExtensible XMLBased Architecture

x. ADL 2. 0: A Highly-Extensible, XML-Based Architecture Description Language Eric M. Dashofy edashofy@ics. uci. edu ICS 223/280 W 2003

Discussion Topic #1 n What is the purpose of a software architecture description language?

Discussion Topic #2 n n What, then, should go in an architecture description language? Motivating discriminators: n n n 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?

Existing ADLs Darwin Distribute d Systems Rapide Mae Events Configuration Management Koala Product Families Behaviora l Properties Implementatio n Mappings x. ADL 1. 0 Dynamic Systems Darwin, C 2 SADL Wright Mobile, Dynamic Architectures ? ?

A Survey of ADLs n Medvidovic survey [MT 00] reveals: n n A proliferation of ADLs available Much commonality among them • Components, Connectors, Links • Deeper pairwise similarities • E. g. Mae and Koala n 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!

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

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

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

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

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

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

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

Example with Subarchitecture “AOL-style” instant messaging app Server Conn 1 Client 2 Structure

Example with Subarchitecture “AOL-style” instant messaging app Server_Type Client_Type Conn 1 Conn_Type Client 1 Client 2 Structure Chat. Iface_Types

Example with Subarchitecture “AOL-style” instant messaging app Server_Type Client_Type Conn 1 Conn_Type Client 1 Client 2 Structure Chat. Iface_Types

Example with Subarchitecture “AOL-style” instant messaging app Server_Type Client_Type Conn 1 Conn_Type Client 1 Client 2 Structure Chat. Iface_Types

Example with Subarchitecture “AOL-style” instant messaging app Server_Type Client_Type Conn 1 Look inside here Conn_Type Client 1 Client 2 Structure Chat. Iface_Types (View as a library of independent types)

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

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

Design-time vs. Run-time in x. ADL 2. 0 Independently Extensible Models types. xsd n Structure & Types model design n n n n Components Connectors Interfaces Links General Groups Subarchitectures Component types Connector types Interface types instance. xsd n Instances model runtime aspects n n n Component Instances Connector Instances Interface Instances Link Instances Subarchitectures General Groups

Implementation Mappings Comp 1 Foo. class Comp 2 Baz. dll Conn 1 Comp 4 Comp 3 . NET Service Adding information about implementations to component, connector, and interface types is essential if the architecture is to be instantiated. Bar. jar

Implementation Mappings in x. ADL 2. 0 extends implementation. xsd n Abstract Implementation n “Placeholder” for implementation data on: n Component Type n Connector Type n Interface Type javaimplementation. xsd n Java Implementation n Concrete schema for Java implementation data

CM/Product Family Architectures 1. 0 Component With Variant Type Comp 1 Version Graph for Type T 1. 1 Comp 2 2. 0 1. 1. 1 Comp 4 1. 1. 2 Comp 3 Optional Component & Link 3. 0

CM/Product Family Architectures in x. ADL 2. 0 versions. xsd n Versions n Version graphs for: n Component types n Connector types n Interface types options. xsd n Options n n n Optional components Optional connectors Optional links variants. xsd n Variants n n Variant component types Variant connector types

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

TV Product-line Architecture Note: Interfaces present but omitted for simplicity. Variant_Tuner_Type Tuner V 1: (loc==USA) V 2: (loc==EUR) Channel Select Conn NTSC_Tuner_Type PAL_Tuner_Type Conn_Type Variant Component Type Channel_Select_type Picture in Picture (model==PROF) Infrared Rcvr Pic_in_Pic_Type Infrared_Rcvr_Type Optional Component and Link Structure Type Library

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

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

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

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

Related Work n [MT 00] Medvidovic, Taylor Survey n n First-Generation ADLs n n C 2 SADL, ACME, Wright, Darwin, Rapide XML DTD-based ADLs n n A Classification and Comparison Framework for Software Architecture Description Languages. IEEE Transactions on Software Engineering, vol. 26, no. 1, pp. 70 -93, January 2000. x. ADL 1. 0, ADML Product-line ADLs n Koala, Mae

Future Extensions n Arch Diffing and Merging Determines the difference between two x. ADL 2. 0 architectures n Can merge (architecture + diff) architecture’ n Dynamic & Distributed Architectures n Graphical layout information n

Summary n Motivation n Architecture research needs flexible ways to deal with novel modeling constructs and combinations thereof A modularly extensible ADL is the key x. ADL 2. 0 n n n 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 n n n Positive initial experiences Significant tool support Visit the Website! n http: //www. isr. uci. edu/projects/xarchuci/

Feature Interaction n x. ADL 2. 0 does not solve the feature interaction problem n 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

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

Existing XML-based ADLs n x. ADL 1. 0 n n From UCI Key features include implementation mapping, analyzable properties (from C 2 SADL) Extension through standard DTD mechanisms ADML n n n From MCC A translation of ACME 1. 0 into an XML DTD Extension through properties

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

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

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

Independent Extensions JPL has refined interface specifications n Extensions underway by various researchers at UCI to add analysis data n x. ACME from CMU is another set of x. Arch extensions n n Compatibility under evaluation

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

What About UML? n UML is not (yet) an ADL n Some work underway to adapt/extend UML to encompass architectural concepts x. ADL 2. 0 = lightweight experimental platform n UML = heavyweight comprehensive design notation n