xADL 2.0 homepage! xADL 2.

0 is an architecture description language (ADL) for software and systems developed by the Institute for Software Research at the University of California, Irvine for modeling the architecture of software system. xADL 2.0 and tools such as Apigen and the xArch/xADL 2.0 Data Binding Library can be used by themselves, independent of any particular development environment or domain. However, we have integrated many more advanced xADL 2.0 tools in the ArchStudio 3 Architecture-centric Development Environment. Most users interested in working with xADL 2.0 will want to download and use ArchStudio 3 as well as the basic xADL 2.0 tools.
Category(ies): Institution/Company: Description: Design and Documentation, ADL Interchange. University of California, Irvine A set of extensions to the core (instance) xArch schema, adding a programming-language-style type system, a design-time model, and architectural configuration management features like options, variants, and versioning. It includes DOM-Based Java libraries for creating, manipulating, storing, and retrieving xArch documents. XADL 2.0 Homepage. Requires JDK 1.2. Extensions are published and ready for community review. Tools are documented research prototypes. Downloadable. XArch.

For more information: Assumptions: Status:

Availability: See also:

xADL 2.0 is a highly-extensible XML-based ADL that supports the specification of product line architectures. xADL 2.0 is built as a set of extensible schemas. The core of xADL 2.0 is the Structure and Types schema. The basic elements provided by this schema are the component and the connector with their interfaces, and the links between the interfaces. All elements (components, connectors and interfaces) are typed. xADL 2.0 is one of the ADLs that provides schemas to define product line architectures. The Options and Variants schemas extend the Structure and Types schema with variation points. The Version schema allows modelling the evolution of a PLA.

A Boolean guard must be specified in an architectural element that is optional. This guard decides if an optional component or connector should be included in a particular product architecture. Mutually exclusive Boolean guards describe which component or connector type (variant type) should be used in a given product architecture. Combined optional variant elements are supported by xADL 2.0, because the optionality is specified at structural level and variability at type level. The current set of xADL 2.0 schemas includes modeling support for:

run-time and design-time elements of a system; support for architectural types; advanced configuration management concepts such as versions, options, and variants; product family architectures; and architecture "diff"ing (initial support).

xADL 2.0 is also an application of xArch, a core XML schema defined jointly by UCI and Carnegie Mellon University

What is xArch?:
xArch is a standard, extensible XML-based representation for software architectures. xArch provides a common core XML notation for architectures that can serve:

as a simple stand-alone representation for architectures. Specifically, xArch provides a common set of bare-bones features that can be used to model an architecture. as a starting point for other, more advanced XML-based architectural notations. Specifically, the common core can be reused while support for other, more advanced ADLs (e.g., Acme, C2SADEL, Rapide) can be added through the creation of XML namespace extensions. as an interchange mechanism for architectural descriptions. Specifically, translators can be built to and from the XML notation.

MODELING ARCHITECTURAL TYPES:

xADL 2.0 adopts the more traditional types-and-instances model found in many programming languages. In this model, components, connectors, and interfaces all have types (called component types, connector types, and interface types, respectively). Links do not have types because links do not have any architectural semantics. The relationships between types, structure, and instances are shown in the following table:

Instance (Run-time)

Structure (Design-time)

Type (Design-time) Component Type Connector Type Interface Type (None) (None)

Component Instance Component Connector Instance Interface Instance Link Instance Group Connector Interface Link Group

Components, connectors, and interfaces are typed because, in real software architectures, there may be multiple elements that are highly similarperhaps they share behavior or an implementation. When designing xADL 2.0, we intended that types would be linked to implementations; as such, two structural elements (e.g. components) that shared a single type (e.g. component type) would imply that the two components shared an implementation (instantiated from the same class, perhaps, or were instances of the same shared library). However, this particular implication is not carried through in the language unless you choose to adopt the xADL 2.0 implementation schemas, discussed later. Cases where two components or connectors might be of the same type include:

When there are multiple, generic connectors (e.g. message buses) with identical behavior Multiple clients in a client-server system Redundant servers in a client-server system Two instances of the same component with different inputs (e.g. two instances of the "tee" command in a pipe and filter system). etc.

The xADL 2.0 constructs available for modeling architectural types are:

Component Types o Subarchitectures for Component Types o Signatures Connector Types* o Subarchitectures for Component Types o Signatures Interface Types

Using xADL 2.0 in Your Project

Using xADL 2.0 in a project means integrating it into a development process. Because of the diversity of projects and needs, it's unlikely that xADL 2.0 (or any other ADL or notation) will support all your needs right off the bat (although, as xADL 2.0 and its tool support grows, this may change). Unlike other notations, xADL 2.0's syntax and tools were meant to be extended to support project-specific needs. The process by which this is done is roughly as follows: 1. Identify discrepancies between what xADL 2.0 can model in its set of provided schemas and what you want to model for your project. 2. Decide which xADL 2.0 elements to extend to support your new modeling needsdo you need to add new kinds of data to structural elements like components and connectors? Their types? Or do you need new kinds of elements altogether? 3. Decide how to syntactically encode these new extensions or elements. 4. Write new XML schemas extending xADL 2.0 to add your new modeling constructs. Validate your new schemas with a tool like XSV. 5. Run Apigen to generate a new data binding library that includes your extensions. 6. Use syntax-based tools like ArchStudio 3's ArchEdit to extend existing architecture descriptions with new kinds of data in the format you specified. 7. Extend semantics based tools like ArchStudio 3's Archipelago and Tron to provide friendlier editors and analysis tools for your new notational extensions.