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

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

• Eric M. Dashofy
• edashofy_at_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
Distributed Systems
Darwin
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 ADLs 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
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, theyd be connectors
  Dashofys 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
Client2
Client1
Structure
14
Example with Subarchitecture
AOL-style instant messaging app
Server
Server_Type
Client_Type
Conn1
Conn_Type
Client2
Client1
ChatIface_Type
Types
Structure
15
Example with Subarchitecture
AOL-style instant messaging app
Server
Server_Type
Client_Type
Conn1
Conn_Type
Client2
Client1
ChatIface_Type
Types
Structure
16
Example with Subarchitecture
AOL-style instant messaging app
Server
Server_Type
Client_Type
Conn1
Conn_Type
Client2
Client1
ChatIface_Type
Types
Structure
17
Example with Subarchitecture
AOL-style instant messaging app
Server
Server_Type
Client_Type
? Look inside here
Conn1
Conn_Type
Client2
Client1
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
State BLOCKED Waiting on event A
AuthorAndré AuthorDick Last Update
08/18/2001
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
-gt comp1.interface .link.type
bottom
Information about distributed components
20
Design-time vs. Run-timein xADL 2.0
Independently Extensible Models
instance.xsd
types.xsd

• Instances model run-time aspects
• Component Instances
• Connector Instances
• Interface Instances
• Link Instances
• Subarchitectures
• General Groups

• 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
1.1
Comp1
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.xsd
versions.xsd
variants.xsd

• Options
• Optionalcomponents
• Optionalconnectors
• Optionallinks

• Versions
• Version graphsfor
• Componenttypes
• Connectortypes
• Interfacetypes

• Variants
• Variantcomponenttypes
• Variantconnectortypes

25
Product Family Example
PAL
Professor TV
Grad Student TV
NTSC
Television Sets
26
TV Product-lineArchitecture
Note Interfacespresent but omittedfor
simplicity.
NTSC_Tuner_Type
Variant_Tuner_Type
Tuner
V1 (locUSA)
PAL_Tuner_Type
V2 (locEUR)
Conn
Channel Select
Conn_Type
Variant Component Type
Channel_Select_type
Picture in Picture (modelPROF)
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/

34
(No Transcript)
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 lt1000 lines of boilerplate Java
  calilng DOM-based libraries

39
Is it an Interchange Format?

• It can be, but its 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