Section 1: Introduction to xADL
Section 2: Background
Section 3: The Instances Core (xArch)
Section 4: Modeling Architectural Structure
Section 5: The xADL Type System
Section 6: Implementation Mappings
Section 7: Options and Variants
Section 8: Boolean Guards
Section 9: Versions
Section 10: Extending xADL
Section 11: xADL Tools
Section 12: Conclusion and Wrap-Up

Section 1: Introduction to xADL

In addition to the set of xADL schemas provided by U.C. Irvine, xADL can be extended by end-users to optimize the language for particular domains. Tools are available that provide users with support for both using existing modules (schemas) and creating and manipulating their own extensions to xADL.

Section 2: Background

<name><first>Herb</first> <last>Mahler</last></name>

<types:component xsi:type="types:Component" types:id="xArchADT">
  <types:description xsi:type="instance:Description">xArchADT</types:description>
  <types:interface xsi:type="types:Interface" types:id="xArchADT.IFACE_TOP">
    <types:description xsi:type="instance:Description">xArchADT Top Interface</types:description>
    <types:direction xsi:type="instance:Direction">inout</types:direction>
    <types:type xsi:type="instance:XMLLink" xlink:type="simple" xlink:href="#C2TopType" />
  </types:interface>
  <types:interface xsi:type="types:Interface" types:id="xArchADT.IFACE_BOTTOM">
    <types:description xsi:type="instance:Description">xArchADT Bottom Interface</types:description>
    <types:direction xsi:type="instance:Direction">inout</types:direction>
    <types:type xsi:type="instance:XMLLink" xlink:type="simple" xlink:href="#C2BottomType" />
  </types:interface>
  <types:type xsi:type="instance:XMLLink" xlink:type="simple" xlink:href="#xArchADT_type" />
</types:component>

<component type="Component" id="xArchADT">
  <description type="Description">xArchADT</description>
  <interface type="Interface" id="xArchADT.IFACE_TOP">
    <description type="Description">xArchADT Top Interface</description>
    <direction type="Direction">inout</direction>
    <type type="XMLLink" xlink:type="simple" xlink:href="#C2TopType" />
  </interface>
  <interface type="Interface" id="xArchADT.IFACE_BOTTOM">
    <description type="Description">xArchADT Bottom Interface</description>
    <direction type="Direction">inout</direction>
    <type type="XMLLink" xlink:type="simple" xlink:href="#C2BottomType" />
  </interface>
  <type type="XMLLink" xlink:type="simple" xlink:href="#xArchADT_type" />
</component>

component{
  (attr) id   = "xArchADT"
  description = "xArchADT"

  interface{
    (attr) id = "xArchADT.IFACE_TOP"
    description = "xArchADT Top Interface"
    direction = "inout"
    (xlink) type = "#C2TopType"
  }

  interface{
    (attr) id = "xArchADT.IFACE_BOTTOM"
    description = "xArchADT Bottom Interface"
    direction = "inout"
    (xlink) type = "#C2BottomType"
  }

  (xlink) type = "#xArchADT_type"
}

As such, xADL was not meant to address one specific semantic domain, but rather to serve as the basis for experimenting with creating new domains, combining existing domains, experimenting with different modeling constructs in existing domains, or modeling existing domains in a new, more open format.

Section 3: The Instances Core (xArch)

A common theme throughout xADL, defined first in the instance schema, is that of IDs and Descriptions. Many elements in xADL have an ID and/or a Description. Identifiers are assumed to be unique to a particular document. They do not necessarily have to be human-readable, although it helps if they are. Descriptions are intended to be human-readable identifiers of the described constructs.

Furthermore, the instance schema defines an element type called an XMLLink that is used over and over again in other xADL schemas. XMLLinks are links to other XML elements. xADL borrows the linking strategy from the XLink standard. However, because of poor support for the XLink standard in terms of real tools, xADL document authors are advised to follow the following simplified convention for specifying XMLLinks.

In xADL, anything with an ID can be the target (i.e. the thing being pointed to) for an XMLLink. Every XMLLink has two parts (implemented as XML attributes), type and href; these are defined by the XLink standard. For xADL XMLLinks, the type field should always be the string simple, indicating a simple XLink. The href field should be filled out with a URL such as:

http://server/directory/document.xml#id

This is a fairly standard fully-specified URL, linking to a document, but using the anchor part of the URL (i.e. the part after the pound sign ('#')) to indicate the identifier of the specific target element. Of course, if you are linking to an element in the same document, it is often preferable to link using a relative URL, such as:

#id

Which would be the element with ID id in the current document. So, two examples of valid hrefs might be:

http://www.isr.uci.edu/foo/bar/archstudio.xml#ArchEdit
#ArchEdit (from within the file archstudio.xml)

Semantics of the Instance Schema

An architecture instance is composed of sets of component, connector, and link instances, along with a set of groups. Each component or connector instance has a set of interface instances (explained below).

In addition to the hierarchical relationships here, we make a few additional assumptions about how these elements can be arranged. These assumptions are:

• Component and connector instances each have a set of interface instances. These interface instances serve as the only interfaces to the component or connector instance that they belong to. That is, all data that passes from one component or connector instance to another travels through some interface. They are the "gateway" to the internals of the component or connector instance. This is not inconsistent with the object-oriented view of interfaces.
• Link instance endpoints, while being generic XML links, are intended to link two interface instances. So, a link may link a particular "in" interface instance on component instance A to a particular "out" interface instance on connector instance B.
• Link instances are not directional. The order of the points is irrelevant. Directional flow of data across a link is determined by the directions of interfaces linked ("in", "out", "inout", or "none").
• Link instances should not be extended to add semantics on the links. If links had semantics, they would be connectors.

Notionally, in a boxes-and-arrows sense, the relationships between components, connectors, interfaces, and links can be seen in this diagram (example):

As you can see, the endpoints of the links are interfaces, and interfaces are the "gateway" to the outside world for both components and connectors.

The above example architecture instance in xADL terms would be expressed as (in abbreviated, non-XML notation):

archInstance{
  componentInstance{
    (attr) id   = "comp1"
    description = "Component 1"

    interfaceInstance{
      (attr) id = "comp1.IFACE_TOP"
      description = "Component 1 Top Interface"
      direction = "inout"
    }

    interfaceInstance{
      (attr) id = "comp1.IFACE_BOTTOM"
      description = "Component 1 Bottom Interface"
      direction = "inout"
    }
  }

  connectorInstance{
    (attr) id   = "conn1"
    description = "Connector 1"

    interfaceInstance{
      (attr) id = "conn1.IFACE_TOP"
      description = "Connector 1 Top Interface"
      direction = "inout"
    }

    interfaceInstance{
      (attr) id = "conn1.IFACE_BOTTOM"
      description = "Connector 1 Bottom Interface"
      direction = "inout"
    }
  }

  componentInstance{
    (attr) id   = "comp2"
    description = "Component 2"

    interfaceInstance{
      (attr) id = "comp2.IFACE_TOP"
      description = "Component 2 Top Interface"
      direction = "inout"
    }

    interfaceInstance{
      (attr) id = "comp2.IFACE_BOTTOM"
      description = "Component 2 Bottom Interface"
      direction = "inout"
    }
  }

  linkInstance{
    (attr) id = "link1"
    description = "Comp1 to Conn1 Link"
    point{
      (link) anchorOnInterface = "#comp1.IFACE_BOTTOM"
    }
    point{
      (link) anchorOnInterface = "#conn1.IFACE_TOP"
    }
  }

  linkInstance{
    (attr) id = "link2"
    description = "Conn1 to Comp2 Link"
    point{
      (link) anchorOnInterface = "#conn1.IFACE_BOTTOM"
    }
    point{
      (link) anchorOnInterface = "#comp2.IFACE_TOP"
    }
  }
}

An additional construct to address at this point is the instance schema's notion of subarchitectures. Subarchitectures occur when a component or connector has an internal architecture that is also described using constructs from the instance schema. When this occurs, the "subarchitecture" element of the component or connector will contain:

1. An "archInstance": a full architecture specification of the internal architecture.
2. A set of interface instance mappings: Which map interfaces on the internal architecture to interfaces on the external architecture.

For the balance of this discussion, we will talk about the subarchitecture of a component, but what is detailed here can be equally applied to connectors with subarchitecture.

Interface instance mappings can be confusing at first, but are really quite simple. The point is that there must be some way to associate interfaces on the outer component with interfaces on some of the inner components or connectors. This creates a "bridge" between the higher-level (i.e. outer) architecture and the lower level (i.e. inner) architecture. This is best illustrated with a diagram:

In this diagram, we see a component with an internal architecture. The outer component has two interfaces which are mapped to two interfaces on internal components. In theory, the mapped interfaces are the "same" interface--that is, any data flowing in through the outer interface is passed to the inner interface, and vice-versa. It is important to note that we assume that the outer component does not provide any additional semantics not provided by its internal architecture; in other words, the outer component is merely a shell. It does not provide any functionality in addition to that of its internal architecture.

An obvious corrollary of this assumption is that hierarchically structured architectures really are not hierarchically structured—that the outer components merely provide a way of grouping similar internal architectures. In a sense, this is true, and implementors may choose to "flatten out" a hierarchical architecture when implementing it.

Section 4: Modeling Architectural Structure

To elaborate, we will model the structure (design-time) of the same architecture we modeled above:

archStructure{
  (attr) id = "My Structure"

  component{
    (attr) id   = "comp1"
    description = "Component 1"

    interface{
      (attr) id = "comp1.IFACE_TOP"
      description = "Component 1 Top Interface"
      direction = "inout"
    }

    interface{
      (attr) id = "comp1.IFACE_BOTTOM"
      description = "Component 1 Bottom Interface"
      direction = "inout"
    }
  }

  connector{
    (attr) id   = "conn1"
    description = "Connector 1"

    interface{
      (attr) id = "conn1.IFACE_TOP"
      description = "Connector 1 Top Interface"
      direction = "inout"
    }

    interface{
      (attr) id = "conn1.IFACE_BOTTOM"
      description = "Connector 1 Bottom Interface"
      direction = "inout"
    }
  }

  component{
    (attr) id   = "comp2"
    description = "Component 2"

    interface{
      (attr) id = "comp2.IFACE_TOP"
      description = "Component 2 Top Interface"
      direction = "inout"
    }

    interface{
      (attr) id = "comp2.IFACE_BOTTOM"
      description = "Component 2 Bottom Interface"
      direction = "inout"
    }
  }

  link{
    (attr) id = "link1"
    description = "Comp1 to Conn1 Link"
    point{
      (link) anchorOnInterface = "#comp1.IFACE_BOTTOM"
    }
    point{
      (link) anchorOnInterface = "#conn1.IFACE_TOP"
    }
  }

  link{
    (attr) id = "link2"
    description = "Conn1 to Comp2 Link"
    point{
      (link) anchorOnInterface = "#conn1.IFACE_BOTTOM"
    }
    point{
      (link) anchorOnInterface = "#comp2.IFACE_TOP"
    }
  }
}

Semantics of Modeling Architectural Structure

The only significant difference between modeling architectural structure and architectural instances is the way that subarchitectures are handled. In the instances case, subarchitectures are expressed in-line, that is, as a sub-element of the component instance or connector instance. In the structural case, however, subarchitectures are handled through component and connector types, which are discussed in more detail later.

The rest of the semantics for modeling architectural structure are basically the same as those for modeling instances. Namely, components and connectors are connected via links, whose endpoints are interfaces, which are the gateways to components and connectors. Additional semantics for structural elements are implied by the underlying type system, which is discussed in the next section.

Section 5: The xADL Type System

Semantics of Modeling Architectural Types

In xADL, all types are independent. Types are not composed of other types, nor is there (to date) a notion of subtyping or type inheritance in xADL. With appropriately documented semantics, however, type inheritance could easily be added through a new schema.

Signatures

One of the least intuitive constructs in xADL is the signature. Each component or connector type has a set of signatures. Each signature has a direction (like interfaces do) and a type XLink, which is intended to point at an interface type. The rationale behind signatures is as follows: let's assume there is are two components C1 and C2, of type T. Certainly, C1 and C2 share something in common, most likely a behavior or an implementation. If this is true, then both C1 and C2 should expose the same types of interfaces (i.e. C1 and C2 should each have the same number of interfaces, and those interfaces should be of the same type. If I find an interface C1-I1 on component C1, I should be able to find a corresponding interface of the same type C2-I1 on component C2). The signatures in the component type T prescribe what types of interfaces must exist on a component of type T for that component to properly be "of that type." This is illustrated here in a diagram (click to expand in new window):

Dotted lines represent the "type" XLink on the various elements. This diagram illustrates the relationship between structural constructs, interfaces, types (especially interface types), and signatures. In the diagram, two components (C1 and C2) share a type, T1. The type has two signatures, Sig1 and Sig2, of interface types TopType and BottomType, respectively. Thus, the two components each have interfaces of types TopType and BottomType. This is a valid arrangement of structural elements, types, and signatures.

However, it is important to note that there is nothing in XML that can guarantee or constrain the various "types" XML links such that only valid arrangements of these constructs can be created. This has advantages and disadvantages. The obvious disadvantage is that this additional validity constraint must be verified by external tools, and cannot be verified solely by XML tools or by the structure of the language itself. The advantage is that the lack of a language-induced constraint here means that different xADL users have the opportunity to redefine the semantics of signatures (or ignore them entirely) if that makes sense in their target domain.

Signatures also play a role in design-time subarchitectures, described below.

At this point, it is possible to look at how the example in the above example would be specified in xADL (using pseudo-XML notation):

archStructure{
  (attr) id = "My Structure with Types"

  component{
    (attr) id   = "C1"
    description = "Component C1"

    interface{
      (attr) id = "comp1.IFACE_TOP"
      description = "Interface C1-Top"
      direction = "inout"
      (link) type = "#TopType"
    }

    interface{
      (attr) id = "comp1.IFACE_BOTTOM"
      description = "Interface C1-Bottom"
      direction = "inout"
      (link) type = "#BottomType"
    }

    (link) type = "#T1"
  }

  component{
    (attr) id   = "C2"
    description = "Component C2"

    interface{
      (attr) id = "comp2.IFACE_TOP"
      description = "Interface C2-Top"
      direction = "inout"
      (link) type = "#TopType"
    }

    interface{
      (attr) id = "comp2.IFACE_BOTTOM"
      description = "Interface C2-Bottom"
      direction = "inout"
      (link) type = "#BottomType"
    }

    (link) type = "#T1"
  }
}

archTypes{
  componentType{
    (attr) id = "T1"
    description = "Component Type T1"
    signature{
      direction = "inout"
      (xlink) type = "#TopType"
    }

    signature{
      direction = "inout"
      (xlink) type = "#BottomType"
    }
  }

  interfaceType{
    (attr) id = "TopType"
    description = "Type for Top interfaces on Components"
  }

  interfaceType{
    (attr) id = "BottomType"
    description = "Type for Bottom interfaces on Components"
  }
}

Design-Time Subarchitectures

Recall that, in xADL run-time, or instance models, subarchitectures (internal architectures of component or connector instances) are modeled in-line; that is, the specification of the internal component or connector architecture is part of the specification of the outer component or connector.

When a type system is introduced, however, things become more complicated. It stands to reason that two components or connectors of the same type would have similar internal architectures. In xADL, this is the case—internal architectures are associated with types rather than structural elements like components or connectors. Thus, two components or connectors who share a type will also have the same internal architecture (if any).

As an example, consider this client-server architecture diagram (connectors, interfaces, and signatures removed for simplicity, click to enlarge in separate window):

In this diagram, the server has an atomic type—that is, the type is not broken down any further. However, the two clients share a type, and they also share a subarchitecture (two linked components called UI and Logic). Conceptually, this works well, but when interfaces, signatures, and interface types become involved, things become more complicated.

Just as an atomic component/connector type has signatures that prescribe what kinds of interfaces a component or connector of that type will have, a composite component/connector type (one with a subarchitecture) also has signatures. So, we will add signatures to the composite type in the above diagram as such (note that many signatures/interfaces are still being omitted for clarity). Note also that the signature's types have been omitted:

Like the outer architecture, the inner architecture will also have interfaces. Interfaces for the inner architecture have been added in this diagram (other signatures, interfaces still omitted for clarity). Also note that the types for these interfaces exist, but have been omitted as well:

Now we need to map the signatures on the component type to interfaces on the subarchitecture. These mappings are given with Signature-Interface Mappings, analogous to the InterfaceInstanceMappings described above for the instance schema. We add signature-interface mappings to the diagram here:

Because of this mapping, it is assumed that the mapped signature and interface have the same interface type for reasons of consistency. In xADL terms, let's model the component type client_type in pseudo-XML notation, incluiding all interface types and signatures (but ignoring the rest of the outer architecture for simplicity).

archTypes{
  componentType{
    (attr) id = "client_type"
    description = "Client Type"

    signature{
      (attr) id = "logic_signature"
      description = "Logic Signature"
      direction = "inout"
      (xlink) type = "#LogicInterfaceType"
    }

    signature{
      (attr) id = "ui_signature"
      description = "UI Signature"
      direction = "inout"
      (xlink) type = "#UIInterfaceType"
    }

    subarchitecture{
      (xlink) archStructure = "#client_architecture"
      signatureInterfaceMapping{
        (xlink) outerSignature = "#logic_signature"
        (xlink) innerInterface = "#logic_interface"
      }

      signatureInterfaceMapping{
        (xlink) outerSignature = "#ui_signature"
        (xlink) innerInterface = "#ui_interface"
      }
    }
  }


  interfaceType{
    (attr) id = "LogicInterfaceType"
    description = "Logic Interface Type"
  }

  interfaceType{
    (attr) id = "UIInterfaceType"
    description = "UI Interface Type"
  }

  interfaceType{
    (attr) id = "LogicUIBridgeInterfaceType"
    description "Logic UI Bridge Interface Type"
  }

  componentType{
    (attr) id = "client_ui_type"
    description = "Client UI Component Type"

    signature{
      (attr) id = "client_ui_signature"
      description = "Client UI Signature"
      direction = "inout"
      (xlink) type = "#UIInterfaceType"
    }

    signature{
      (attr) id = "client_logic_ui_bridge_out_signature"
      description "Client Logic-UI Bridge Signature, UI Side"
      direction = "out"
      (xlink) type = "#LogicUIBridgeInterfaceType"
    }
  }

  componentType{
    (attr) id = "client_logic_type"
    description = "Client Logic Component Type"

    signature{
      (attr) id = "client_logic_signature"
      description = "Client Logic Signature"
      direction = "inout"
      (xlink) type = "#LogicInterfaceType"
    }

    signature{
      (attr) id = "client_logic_ui_bridge_in_signature"
      description "Client Logic-UI Bridge Signature, Logic Side"
      direction = "in"
      (xlink) type = "#LogicUIBridgeInterfaceType"
    }
  }
}

archStructure{
  (attr) id = "client_architecture"
  description = "Client Architecture"

  component{
    (attr) id = "client_ui_component"
    description = "Client UI Component"

    interface{
      (attr) id = "client_ui_ui_interface"
      description "UI Interface on Client UI"
      direction = "inout"
      (xlink) type = "#UIInterfaceType"
    }

    interface{
      (attr) id = "client_logic_ui_bridge_out_interface"
      description = "Client Logic-UI Bridge Interface, UI Side"
      direction="out"
      (xlink) type= "#LogicUIBridgeInterfaceType"
    }
  }

  component{
    (attr) id = "client_logic_component"
    description = "Client Logic Component"

    interface{
      (attr) id = "client_logic_logic_interface"
      description = "Logic Interface on Client Logic"
      direction = "inout"
      (xlink) type = "#LogicInterfaceType"
    }

    interface{
      (attr) id = "client_logic_ui_bridge_in_interface"
      description = "Client Logic-UI Bridge Interface, Logic Side"
      direction = "in"
      (xlink) type = "#LogicUIBridgeInterfaceType"
    }
  }

  link{
    (attr) id = "client_logic_to_ui_link"
    description = "Client Logic to UI link"
    point{
      (xlink) anchorOnInterface = "#client_logic_ui_bridge_in_interface"
    }
    point{
      (xlinK) anchorOnInterface = "#client_logic_ui_brige_out_interface"
    }
  }
}

You will note in the above document that there is only one archTypes section, even though two levels of architectural hierarchy are being modeled here (the upper level represented by the client type and the lower level being represented by its subarchitecture). Because types are seen as independent entities, not necessarily bound to a single architecture or level of the hierarchy, they are grouped up in this fashion. This is normal. The exception would be if the architecture in which the client type is included and its internal architecture were modeled in different xADL files; in this case there would likely be one archTypes section in each file, although this is for organizational, rather than semantic, purposes.

Contact Us

If you have questions not answered by this website, please feel free to contact the software architectures group at UC Irvine through the ArchStudio developer's (mailman protected) email list at: archstudio-dev [@] uci [.] edu.