xADL 2.0:A Highly-Extensible, XML-Based
Architecture Description Language
Eric M. [email protected]
ICS 223/280 W2003
Discussion Topic #1 What is the purpose of a software
architecture description language?
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?
Existing ADLs
Events
Dynamic Systems
Configuration Management
Distributed Systems
ProductFamilies
Behavioral
PropertiesImplementatio
n Mappings
xADL 1.0
Darwin
Mae
Koala
WrightRapide
Darwin,C2SADL
Mobile, Dynamic
Architectures
????
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!
The Problem How can we exploit commonalities
and experiment with different features in an ADL without duplicating effort?
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 byusers with different, possibly conflicting goals.
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
xADL 2.0 xADL 2.0 = A set of modules that form an ADL Each module is a schema – 100-500 lines of XML
Types & Structure(Design Time)
(ADL Core)
Run-Time Instances CM/Product Families(Versions, Options,
Variants)
ImplementationMappings
(Future Expansions)
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
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?)
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
Example with Subarchitecture
Client2
Client1
Conn1
Server
“AOL-style” instant messaging app
Structure
Example with Subarchitecture
Client2
Client1
Conn1
Server
“AOL-style” instant messaging app
Structure
Server_Type
Client_Type
Conn_Type
ChatIface_Type
Types
Example with Subarchitecture
Client2
Client1
Conn1
Server
“AOL-style” instant messaging app
Structure
Server_Type
Client_Type
Conn_Type
ChatIface_Type
Types
Example with Subarchitecture
Client2
Client1
Conn1
Server
“AOL-style” instant messaging app
Structure
Server_Type
Client_Type
Conn_Type
ChatIface_Type
Types
Example with Subarchitecture
Client2
Client1
Conn1
Server
“AOL-style” instant messaging app
Structure
Server_Type
Client_Type
Conn_Type
ChatIface_Type
Types (View as a library of independent types)
Look inside here
Example with Subarchitecture
“AOL-style” instant messaging app
Client_Type
Types
Look inside here
Structure 2 (May be in a different file)
ContentFilter
GUI
LocalConn
AdsAdsAds
NetworkConn(subarchitecture)
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.
Design-Time vs. Run-Time
Comp2
Comp3
Comp1
Comp1_Beh{ If(recv(evt(q))){ doProcess(q) emit(evt(b)); }}
Behavior informationfor static analysis
CompInst 2
CompInst 3
CompInst 1
aba - -
Event queue contents
Machine = magisterPid = 242CPU = 1Port = 8080…
Information aboutdistributed components
State= BLOCKED
Waiting on event “A”
Run-time State
Conn1
ConnInst 1
Constraints
Invariant a{ comp1.interface .type = top -> comp1.interface .link.type = bottom}
Design-oriented Properties
Author=AndréAuthor=DickLast Update: 08/18/2001
Design-time vs. Run-timein xADL 2.0
Instances model run-time aspects
Component Instances Connector Instances Interface Instances Link Instances Subarchitectures General Groups
instance.xsd
IndependentlyExtensible
Models
types.xsd Structure & Types model
design Components Connectors Interfaces Links General Groups Subarchitectures Component types Connector types Interface types
Adding information about implementations to component, connector, and interface types is essential if the architecture is to be instantiated.
Implementation Mappings
Foo.class
Bar.jar
Baz.dll
.NETService
Comp2
Comp1
Comp3
Comp4
Conn1
Implementation Mappingsin xADL 2.0
javaimplementation.xsdimplementation.xsd
Abstract Implementation “Placeholder” for
implementation data on:
Component Type Connector Type Interface Type
extends
Java Implementation Concrete schema for
Java implementation data
CM/Product Family Architectures
Comp4
ComponentWith Variant Type
OptionalComponent & Link
1.0
1.1
2.0 1.1.1
3.0
1.1.2
Version Graphfor Type T
Comp1
Comp2
Comp3
CM/Product Family Architectures in xADL 2.0
Options Optional
components Optional
connectors Optional
links
options.xsdversions.xsd
Versions Version graphs
for: Component
types Connector
types Interface
types
Variants Variant
componenttypes
Variantconnectortypes
variants.xsd
Product Family Example
Television Sets
Professor TV
Grad Student TV
NTSC
PAL
TV Product-lineArchitecture
InfraredRcvr
Picture inPicture
(model==PROF)
Conn
Tuner
Structure
Variant_Tuner_Type
Pic_in_Pic_Type
Conn_Type
Note: Interfacespresent but omitted
for simplicity.
ChannelSelect
NTSC_Tuner_Type
V1: (loc==USA)
V2: (loc==EUR) PAL_Tuner_Type
Infrared_Rcvr_Type
Channel_Select_type
Type Library
Variant Component Type
Optional Component and Link
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
Total Set of Schemas
Instances
Structure & Types
Versions Options Variants AbstractImplementation
JavaImplementation
ArchitectureDiffing
MessagingInterfaces
TypeRelationships
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
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
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
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
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/
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
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
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
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
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
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.
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
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
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
Recommended
