Xadl 2 0 a highly extensible xml based architecture description language
Download
1 / 43

xADL 2.0: - PowerPoint PPT Presentation


  • 628 Views
  • Uploaded on

xADL 2.0: A Highly-Extensible, XML-Based Architecture Description Language. Eric M. Dashofy [email protected] ICS 223/280 W2003. Discussion Topic #1. What is the purpose of a software architecture description language?. Discussion Topic #2.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'xADL 2.0:' - Donna


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Xadl 2 0 a highly extensible xml based architecture description language l.jpg

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

Eric M. Dashofy

[email protected]

ICS 223/280 W2003


Discussion topic 1 l.jpg
Discussion Topic #1

  • What is the purpose of a software architecture description language?


Discussion topic 2 l.jpg
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 l.jpg
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

????


A survey of adls l.jpg
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 l.jpg
The Problem

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


Solution an extensible adl l.jpg
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.


Xml as the basis for a modularly extensible adl l.jpg
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 l.jpg

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


Design time schema core l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Example with Subarchitecture

“AOL-style” instant messaging app

Server

Conn1

Client1

Client2

Structure


Example with subarchitecture14 l.jpg
Example with Subarchitecture

“AOL-style” instant messaging app

Server

Server_Type

Client_Type

Conn1

Conn_Type

Client1

Client2

ChatIface_Type

Types

Structure


Example with subarchitecture15 l.jpg
Example with Subarchitecture

“AOL-style” instant messaging app

Server

Server_Type

Client_Type

Conn1

Conn_Type

Client1

Client2

ChatIface_Type

Types

Structure


Example with subarchitecture16 l.jpg
Example with Subarchitecture

“AOL-style” instant messaging app

Server

Server_Type

Client_Type

Conn1

Conn_Type

Client1

Client2

ChatIface_Type

Types

Structure


Example with subarchitecture17 l.jpg
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


Example with subarchitecture18 l.jpg
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)


Design time vs run time l.jpg
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


Design time vs run time in xadl 2 0 l.jpg
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


Implementation mappings l.jpg
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.


Implementation mappings in xadl 2 0 l.jpg
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


Cm product family architectures l.jpg
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


Cm product family architectures in xadl 2 0 l.jpg
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


Product family example l.jpg
Product Family Example

PAL

Grad Student TV

Professor TV

NTSC

Television Sets


Tv product line architecture l.jpg
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


Semantics in xadl 2 0 l.jpg
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 l.jpg
Total Set of Schemas

Instances

Structure & Types

Versions

Options

Variants

Abstract

Implementation

Architecture

Diffing

Messaging

Interfaces

Java

Implementation

Type

Relationships


Tool support l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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


ad