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

  • Published on

  • View

  • Download

Embed Size (px)


xADL 2.0: A Highly-Extensible, XML-Based Architecture Description Language. Eric M. Dashofy edashofy@ics.uci.edu ICS 223/280 W2003. Discussion Topic #1. What is the purpose of a software architecture description language?. Discussion Topic #2. - PowerPoint PPT Presentation


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

    Eric M. Dashofyedashofy@ics.uci.eduICS 223/280 W2003

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

  • Discussion Topic #2What, 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 ADLsEvents

    Dynamic SystemsConfiguration ManagementDistributed SystemsProductFamiliesBehavioral PropertiesImplementation MappingsxADL 1.0DarwinMaeKoalaWrightRapideDarwin,C2SADLMobile, Dynamic Architectures????

  • A Survey of ADLsMedvidovic survey [MT00] reveals:A proliferation of ADLs availableMuch commonality among themComponents, Connectors, LinksDeeper pairwise similaritiesE.g. Mae and KoalaPoints of variation are killer featuresEach ADL has a small subset of killer featuresThese features supported by toolsMany killer features are orthogonal!

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

  • Solution: An Extensible ADLOur target ADL should support modular extensiblityThis allows the ADLs users to:Encapsulate ADL features in modulesAdd new modules to:Add new featuresExtend existing featuresMake tools available efficientlyExperiment with different combinations of modeling constructsThe ADL will be independently extensible byusers with different, possibly conflicting goals.

  • XML As the Basis for a Modularly Extensible ADLXML is good for structured data storage and interchangeXML tools and technologies are proliferatingXML schemas provide a metalanguage for developing modular languagesProvide a subtyping mechanism that does not require modification of the base type definition

  • xADL 2.0xADL 2.0 = A set of modules that form an ADLEach module is a schema 100-500 lines of XML

  • Design-Time Schema: CoreFive core structural constructsComponentsLoci of computationConnectorsLoci of communicationInterfacesConnection points between component/connector & outside worldLinksSemantic free associations between interfacesIf links had semantics, theyd be connectors Dashofys 8th law of ArchitecturesGroupsSemantically meaningful association among things

  • Design-Time Schema (cont)Three constructs for reasoning about relationship between structural elementsComponent TypeHas signatures (prescribed interfaces)(Can have subarchitecture)Connector TypeHas 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 elementsTwo components share a type they share a subarchitectureSignature-interface mappings connect the inner world to the outer world

  • Example with SubarchitectureClient 2Client 1Conn1ServerAOL-style instant messaging appStructure

  • Example with SubarchitectureClient 2Client 1Conn1ServerAOL-style instant messaging appStructureServer_TypeClient_TypeConn_TypeChatIface_TypeTypes

  • Example with SubarchitectureClient 2Client 1Conn1ServerAOL-style instant messaging appStructureServer_TypeClient_TypeConn_TypeChatIface_TypeTypes

  • Example with SubarchitectureClient 2Client 1Conn1ServerAOL-style instant messaging appStructureServer_TypeClient_TypeConn_TypeChatIface_TypeTypes

  • Example with SubarchitectureClient 2Client 1Conn1ServerAOL-style instant messaging appStructureServer_TypeClient_TypeConn_TypeChatIface_TypeTypes (View as a library of independent types) Look inside here

  • Example with SubarchitectureAOL-style instant messaging appClient_TypeTypes Look inside hereStructure 2 (May be in a different file)ContentFilterGUILocalConnAdsAdsAdsNetworkConn(subarchitecture)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.

  • Design-Time vs. Run-TimeComp2Comp3Comp1Comp1_Beh{ If(recv(evt(q))){ doProcess(q) emit(evt(b)); }}

    Behavior informationfor static analysisCompInst 2CompInst 3CompInst 1aba--Event queue contentsMachine = magisterPid = 242CPU = 1Port = 8080Information aboutdistributed componentsState= BLOCKED

    Waiting on event ARun-time StateConn1ConnInst 1ConstraintsInvariant a{ comp1.interface .type = top -> comp1.interface .link.type = bottom}Design-oriented PropertiesAuthor=AndrAuthor=DickLast Update: 08/18/2001

  • Design-time vs. Run-timein xADL 2.0Instances model run-time aspectsComponent InstancesConnector InstancesInterface InstancesLink InstancesSubarchitecturesGeneral Groupsinstance.xsdIndependentlyExtensibleModelstypes.xsdStructure & Types model designComponentsConnectorsInterfacesLinksGeneral GroupsSubarchitecturesComponent typesConnector typesInterface types

  • Implementation MappingsAdding information about implementations to component, connector, and interface types is essential if the architecture is to be instantiated.Foo.classBar.jarBaz.dll.NETServiceComp2Comp1Comp3Comp4Conn1

  • Implementation Mappingsin xADL 2.0javaimplementation.xsdimplementation.xsdAbstract ImplementationPlaceholder for implementation data on:Component TypeConnector TypeInterface TypeextendsJava ImplementationConcrete schema for Java implementation data

  • CM/Product Family ArchitecturesComp4ComponentWith Variant TypeOptionalComponent & Link1. Graphfor Type TComp1Comp2Comp3

  • CM/Product Family Architectures in xADL 2.0OptionsOptional componentsOptional connectorsOptional linksoptions.xsdversions.xsdVersionsVersion graphs for:Component typesConnector typesInterface typesVariantsVariant component typesVariant connector typesvariants.xsd

  • Product Family ExampleTelevision SetsProfessor TVGrad Student TVNTSCPAL

  • TV Product-lineArchitectureInfraredRcvrPicture inPicture(model==PROF)ConnTunerStructureVariant_Tuner_Type

    Pic_in_Pic_TypeConn_TypeNote: Interfaces present but omitted for simplicity.ChannelSelectNTSC_Tuner_TypeV1: (loc==USA)V2: (loc==EUR)PAL_Tuner_TypeInfrared_Rcvr_TypeChannel_Select_typeType LibraryVariant Component TypeOptional Component and Link

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

  • Total Set of SchemasInstancesStructure & TypesVersionsOptionsVariantsAbstractImplementationJavaImplementationArchitectureDiffingMessagingInterfacesTypeRelationships

  • Tool supportCOTS/Open Source XML toolsXML Authority, XML Spy, Apache XercesIn-house toolsDOM-based Java LibrariesProgrammatic, syntax-directed editing of xADL 2.0 documents, hiding nearly all of XMLApigenGenerates DOM-based Java Libraries using only the XML schemasArchEditSyntax-directed graphical tree-based editorMenageGraphical editor focusing on product-line featuresVisio for xADLMicrosoft Visio extensions provide graphical visualization and editing capabilities for xADL 2.0 architectures

  • Experience & EvaluationLockheed Martin Systems IntegrationAWACS aircraft software systems modeled in 10,000 lines of xADL 2.0Used as the basis for an architecture-derived simulation of the inter-component communication on AWACSJet Propulsion Laboratories (JPL)Extended xADL 2.0 to add domain-specific interface descriptionsExperimenting with modeling software architectures in xADL 2.0 for use in future Mars missions

  • Related Work[MT00] Medvidovic, Taylor SurveyA 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 ADLsC2SADL, ACME, Wright, Darwin, RapideXML DTD-based ADLsxADL 1.0, ADMLProduct-line ADLsKoala, Mae

  • Future ExtensionsArch Diffing and MergingDetermines the difference between two xADL 2.0 architecturesCan merge (architecture + diff) architectureDynamic & Distributed ArchitecturesGraphical layout information

  • SummaryMotivationArchitecture research needs flexible ways to deal with novel modeling constructs and combinations thereofA modularly extensible ADL is the keyxADL 2.0A modularly-extensible ADL based on XML schemasGet into new domains quickly and effectivelyProvides novel, reusable featuresDesign-time vs. Run-time, Implementation Mapping, Configuration Management / PFA supportPositive initial experiencesSignificant tool supportVisit the Website!http://www.isr.uci.edu/projects/xarchuci/

  • Feature InteractionxADL 2.0 does not solve the feature interaction problemWhen presented with two conflicting schemas:Do not model the featureChoose one schema over the otherRewrite one or both schemas to be compatibleTranslate between the two with tools

  • Desirable Features of an ADLExtensiblityAbility to add new constructs without knowing, a priori, what information they containIncrementalityAbility to expand on these constructs as new needs/research ideas ariseModularityAbility to use only a subset of the total feature setBase Feature SetSemantically agnostic features that provide a framework for future development

  • Existing XML-based ADLsxADL 1.0From UCIKey features include implementation mapping, analyzable properties (from C2SADL)Extension through standard DTD mechanismsADMLFrom MCCA translation of ACME 1.0 into an XML DTDExtension through properties

  • NumbersAverage xADL 2.0 extension schema100-500 lines of XML schemaIncluding commentsYes, it scalesLargest xADL 2.0 schema to date: AWACS150+ components, 150+ connectors10,000 lines of valid xADL 2.0Generated by
  • Is it an Interchange Format?It can be, but its not meant to beSince xADL 2.0 is so extensible, it can quickly take on the modeling characteristics of other ADLsHave created xADL 2.0 extensions that capture PLAsKoalaMaeLossless translation from other ADLs is possible

  • Tool InteroperabilityIn theory, well-built tools should be able to interoperate with unknown extensionsExample: List all components in the architecture.Meta-level tools like ArchEdit and Visio for xADL show the potentialMore semantically-oriented tools can share common extensions & related semantics.

  • Independent ExtensionsJPL has refined interface specificationsExtensions underway by various researchers at UCI to add analysis dataxACME from CMU is another set of xArch extensionsCompatibility under evaluation

  • Feature Interaction ProblemThe key problem in extensible languagesMany architectural modeling constructs are conceptually orthogonalArchitects choose the subset of features they want to use, potentially minimizing interactions

  • What About UML?UML is not (yet) an ADLSome work underway to adapt/extend UML to encompass architectural conceptsxADL 2.0 = lightweight experimental platformUML = heavyweight comprehensive design notation


View more >