# An Architecture Description Language Based on Dynamic Description Logics

Zhuxiao Wang, Hui Peng, Jing Guo, Ying Zhang, Kehe Wu, Huan Xu, Xiaofeng Wang

► To cite this version:

Zhuxiao Wang, Hui Peng, Jing Guo, Ying Zhang, Kehe Wu, et al.. An Architecture Description Language Based on Dynamic Description Logics. 7th International Conference on Intelligent Information Processing (IIP), Oct 2012, Guilin, China. pp.157-166, 10.1007/978-3-642-32891-6_21 hal-01524967

HAL Id: hal-01524967

https://inria.hal.science/hal-01524967

Submitted on 19 May 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
An Architecture Description Language Based on
Dynamic Description Logics

Zhuxiao Wang¹, Hui Peng², Jing Guo³, Ying Zhang¹, Kehe Wu¹, Huan Xu¹, Xiao-feng Wang⁴

¹School of Control and Computer Engineering, State Key Laboratory of Alternate Electrical Power System with Renewable Energy Sources, North China Electric Power University, Beijing 102206, China

{wangzx, yingzhang, wkh, xuhuan}@ncepu.edu.cn

²Education Technology Center, Beijing International Studies University, Beijing 100024, China
penghui@bisu.edu.cn

³National Computer Network Emergency Response Technical Team/Coordination Center of China, Beijing 100029, China

guojing.research@gmail.com

⁴Institute of Computing Technology, Chinese Academy of Sciences, Beijing 100190, China
wangxiaofeng@ict.ac.cn

**Abstract.** ADML is an architectural description language based on Dynamic Description Logic for defining and simulating the behavior of system architecture. ADML is being developed as a new formal language and/or conceptual model for representing the architectures of concurrent and distributed systems, both hardware and software. ADML embraces dynamic change as a fundamental consideration, supports a broad class of adaptive changes at the architectural level, and offers a uniform way to represent and reason about both static and dynamic aspects of systems. Because the ADML is based on the Dynamic Description Logic DDL(*SHON* (*D*)), which can represent both dynamic semantics and static semantics under a unified logical framework, architectural ontology entailment for the ADML languages can be reduced to knowledge base satisfiability in DDL(*SHON* (*D*)), and dynamic description logic algorithms and implementations can be used to provide reasoning services for ADML. In this article, we present the syntax of ADML, explain its underlying semantics using the Dynamic Description Logic DDL(*SHON* (*D*)), and describe the core architecture description features of ADML.

**Keywords:** Architecture Description Languages, Knowledge Representation and Reasoning, Software Architecture, Dynamic Description Logics, Dynamic Adaptation

# 1 Introduction

ADML is a promising Architecture Description Language (ADL) towards a full realization of the representing and reasoning about both static and dynamic aspects of concurrent and distributed systems. Concurrent and distributed systems, both hard-
ware and software, can be understood as a world that changes over time. Entities that act in the world (which can be anything from a monitor to some computer program) can affect how the world is perceived by themselves or other entities at some specific moment. At each point in time, the world is in one particular state that determines how the world is perceived by the entities acting therein. We need to consider some language (like the Architecture Dynamic Modeling Language, ADML) for describing the properties of the world in a state. By means of well-defined change operations named transition rules in ADML, transition rules can affect the world and modify its current state. Such transition rules denote state transitions in all possible states of the world.

In this paper we describe the main features of ADML, its rationale, and technical innovations. ADML is based on the idea of representing an architecture as a dynamic structure and supporting a broad class of adaptive changes at the architectural level. However, simultaneously changing components, connectors, and topology in a reliable manner requires distinctive mechanisms and architectural formalisms. Many architecture description languages[1-4] are dynamic to some limited degree but few embrace dynamic change as a fundamental consideration. ADML is being developed as a way of representing dynamic architectures by expressing the possible change operations in terms of the ADML constructors.

ADML can be viewed as syntactic variants of dynamic description logic. In particular, the formal semantics and reasoning in ADML use the DDL(*SHON*(D)) dynamic description logic, extensions of description logics (DLs) [5] with a dynamic dimension [6-9]. So the main reasoning problem in ADML can be reduced to knowledge base (KB) satisfiability in the DDL(*SHON*(D)). This is a significant result from both a theoretical and a practical perspective: it demonstrates that computing architectural ontology entailment in ADML has the same complexity as computing knowledge base satisfiability in DDL(*SHON*(D)), and that dynamic description logic algorithms and implementations can be used to provide reasoning services for ADML.

In the following sections, we firstly present an overview of the capabilities of ADML in Section 2. It covers the basic language features and includes a few small examples. Furthermore, we demonstrate the descriptions of transition rules can be formalized as actions in the DDL(*SHON*(D)). In Section 3, we summarize basic ADML syntax with an overview of ADML semantics. We show that the main reasoning problem in ADML can be reduced to knowledge base (KB) satisfiability in the DDL(*SHON*(D)) dynamic description logic. Finally, we summarize the paper in Section 4.

## 2 An Overview of Adml

ADML is intended as a new formal language and/or conceptual model for describing the architecture of a system. ADML is built on a core ontology of six types of entities for architectural representation: components, connectors, systems, ports, roles, and behaviors. These are illustrated in Figure 1 and Table 1. Of the six types, the most basic elements of architectural description are components, connectors, systems, and
behaviors. It's important to recognize that ADML is based on the idea of representing
an architecture as a dynamic structure. In other words, ADML may also be used as a
way of representing reconfigurable architectures by expressing the possible reconfigu-
rations in terms of the ADML structures (like behaviors). For example, an architec-
tural model might include behaviors that describe components that may be added at
run-time and how to attach them to the current system.

## 2.1 ADML design element types

As a simple illustrative example, Figure 1 shows the architectural model of a secure
wireless remote-access infrastructure, which is represented as a graph of interacting
components. Nodes in the graph are termed components, which represent the primary
computational elements and data stores of the system. Typical examples of compo-
nents include such things as terminals, gateways, filters, objects, blackboards, data-
bases, and user interfaces. Arcs are termed connectors, and represent communication
glue that captures the nature of an interaction between components. Examples of con-
nectors include simple forms of interaction, such as data flow channel (e.g., a Pipe), a
synchronous procedure call, and a particular protocol (like HTTP). Table 1 contains
an ADML description of the architecture of Figure 1. In the software architecture
illustrated in Table 1, the secure access gateway (SAG), and the wireless terminal are
components. The component exposes its functionality through its ports, which
represents a point of contact between the component and its environment. The wire-
less terminal component is declared to have a single send-request port, and the SAG
has a single receive-request port. The connector includes the network connections
between the wireless terminal and the SAG. A connector includes a set of interfaces
in the form of roles, which may be seen as an interface to a communication channel.
The rpc connector has two roles designated caller and callee. The topology of this
system is defined by listing a set of attachments, each of which represents an interac-
tion between a port and some role of a connector.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Elements of an ADML Description</figcaption></figure>
<table><caption>**Table 1.** The architectural model in ADML</caption><thead><tr><th>Element Axioms</th><th>Property Axioms</th><th>Facts</th></tr></thead><tbody><tr><td>Element(System complete Thing restriction (hasComp minCardinality (1)))</td><td>ObjectProperty( hasComp domain(unionOf (System Comp)) range(Comp));</td><td>Individual( sys type (System));<br/>Individual( term type (Comp));<br/>Individual( SAG type (Comp));<br/>Individual( send-request type (Port));<br/>Individual( receive-request type (Port));</td></tr><tr><td>Element(Comp complete Thing unionOf (restriction (hasPort minCardinality (1)) restriction (hasComp minCardinality (1))));</td><td>ObjectProperty( hasPort domain(Comp) range(Port));<br/>ObjectProperty( hasRole domain(Connector) range(Role));</td><td>Individual( caller type (Role));<br/>Individual( callee type (Role));<br/>Individual( sys value (hasComp term));<br/>Individual( sys value (hasComp SAG));</td></tr><tr><td>Element(Connector complete Thing restriction (hasRole minCardinality (2)));</td><td>DatatypeProperty(Heuristic domain(Connector) range(Float));<br/>ObjectProperty( attached domain(Port) range(Role));</td><td>Individual( sys value (hasConnector rpc));<br/>Individual( term value (hasPort send-request));<br/>Individual( SAG value (hasPort receive-request));<br/>Individual( rpc value (hasRole caller));<br/>Individual( rpc value (hasRole callee));<br/>Individual( rpc value (Heuristic expectedLatency));<br/>Individual( send-request value(attached caller));<br/>Individual( receive-request value(attached callee));</td></tr></tbody></table>

## 2.2 Components

A component provides an abstract definition of externally visible behavior—i.e., the behavior that is visible to, and may be observed by, a system containing the component. A component defines

1) the ports which may be used to represent what is traditionally thought of as an interface: a set of operations available on a component.

2) its states and state transitions.

The syntax structure of components is outlined in Figure 2. Many features are omitted from this overview.

A component declares sets of port constituents. Those port constituents are visible to the system. Other components of the system can be wired up (by connectors) to those port constituents. Thus communication between components is defined by the ports.

A component must provide the objects and functions named in the port constituents. Thus, for example, other components can be connected to call its provided
<figure><img src="image_3.png" /><figcaption>Fig. 2. Outline of component syntax</figcaption></figure>

functions. Conversely, a component may call its requires functions and assume they
are connected to call provided functions of other components. Connectors between
required and provided functions define synchronous communication.

A component specifies the types of events it can observe and generate by declar-
ing, respectively, in and out ports. Connectors in the system can call the in ports of a
component, thus generating in events which the component can observe; conversely,
the component can call its out ports, thereby generating events which the system can
observe. Thus connectors define asynchronous communication between components.

A component optionally contains a behavior which consists of a set of objects,
functions, and transition rules. The set of objects, functions is described as ADML
facts (see Section 3). Facts declared in a component model state. Transition rules
model how the component react to patterns of observed events by changing its states
and generating events. The behavior of a component in a system is constrained to be
consistent with the component’s behavior.

A component observes in events from the system. It reacts by executing its transi-
tion rules and generating out events which are sent to other components. A compo-
nent observes calls to its provides functions; the component must declare functions in
its behavior that are executed in response to these calls. When a component calls its
requires functions it depends upon the system to connect those calls to provides func-
tions in other components.

## 2.3 Transition rules

One of the key ingredients of the behaviors in a component is a set of transition rules that model how the component react to patterns of observed events by changing their states and generating events. A state transition rule has two parts, a trigger and a body. A trigger is an event pattern (a finite set of facts). A body is an optional set of state assignments followed by a restricted pattern which describes a finite set of facts.
In our description frameworks for transition rules, functional descriptions are essen-
tially the state-based and use at least pre-state and post-state constraints to character-
ize intended executions of a transition rule. On the basis of the above consideration,
we give some formal definitions related to transition rules:

**Definition. 1(Atomic transition rules)** An atomic transition rule is a tuple Transition(t) = Transition(<trigger, transition_body>) = Transition(<Pre, Effects>), where Pre is a finite set of facts specifying the preconditions for the execution of t; and Effects is a finite set of facts holding in the newly-reached world by the transition rule's execution. A function body is treated as if it was a transition rule that is triggered by a function call; function calls are treated as events.

A close observation on the state transition rule reveals some resemblance between transition rules and DDL(*SHON*(D)) actions. As mentioned in [9-12], the formulas in both Pre and Effects are conferred with well-defined semantics encoded in some TBox, which specifies the domain constraints in consideration.

The execution semantics of transition rules are as follows. If any of the precondi-
tions of the transition rules are satisfied, the process of arbitrarily choosing one of the
transition rules, executing its rule body is repeated until none of the preconditions are
satisfied.

Executing a rule body consists of changing the state of the behavior part (by calling operations of facts declared there), generating new events defined by the instance of the restricted pattern, and adding the new events to the execution of the system.

Composite transition rules are constructed from atomic transition rules with the help of classic constructors in ADML. Both atomic and composite transition rules are transition rules:

**Definition. 2(Transition rules)** Transition rules are built up with the following
rule:

$t_i, t_j ::= Transition(t) | Transition(t_i test) | choiceOf(t_i t_j) | sequenceOf(t_i t_j) |$
Transition(t_i iteration), where t is an atomic transition rule; t_i, t_j denote transition rules.

We name sequenceOf(tᵢ tⱼ), choiceOf(tᵢ tⱼ), Transition(tᵢ iteration) and Transition(tᵢ test) as sequence, choice, iteration and test transition rules, respectively.

**Remark:** Note that test Transition(tᵢ test) is used to check the executability of the transition rules, which can be reduced to the satisfiability-checking of preconditions of the component transition rules. Test transition rules' execution effects no changes to the world.

ADML is a promising Architecture Description Language (ADL) towards a full
realization of the representing and reasoning about both static knowledge and dynam-
ic knowledge in concurrent and distributed systems. In addition to the features inhe-
rited from SHON (D), i.e., expressive power in static knowledge representation and
decidability in reasoning, DDL(SHON (D)) still employs actions to capture functio-
nalities of transition rules. Hence it is intuitive to model transition rules by actions in
DDL(SHON (D)). As demonstrated in this section, the functionalities of transition
rules can be semantically transformed into actions in DDL(SHON (D)) by a proper
domain ontology (TBox). As a result, all kinds of reasoning tasks concerning the
functionalities of transition rules thus can be reduced to the reasoning about actions in
DDL(SHON (D)).
### 3 Adml as the DDL(*SHON*(*D*)) Dynamic Description Logic

ADML is very close to the DDL(*SHON* (*D*)) Dynamic Description Logic which is itself an extension of the *SHON* (*D*) Description Logic [5] (extended with a dynamic dimension[6,9]). ADML can form descriptions of components, connectors, and systems using some constructs. Given the limited space available, in this article I will not delve into the details of the ADML syntax. ADML axioms, facts, and transition rules are summarized in Table 2 below. In this table the first column gives the ADML syntax for the construction, while the second column gives the DDL(*SHON* (*D*)) Dynamic Description Logic syntax.

Because ADML includes datatypes, the semantics for ADML is very similar to that of Dynamic Description Logics that also incorporate datatypes, in particular DDL(*SHON*(*D*)).

The specific meaning given to ADML is shown in the third column of Table 2. A DDL(*X*) model is a tuple $M = (W, T, \Delta, I)$, where,

*W* is a set of states;

*T*: $N_A \to 2^{W \times W}$ is a function mapping action names into binary relations on *W*;

*Δ* is a non-empty domain;

*I* is a function which associates with each state $w \in W$ a description logic interpretation $I(w) = <\Delta, I^{(w)}>$, where the mapping $\cdot I^{(w)}$ assigns each concept to a subset of $\Delta$, each role to a subset of $\Delta \times \Delta$, and each individual to an element of $\Delta$.

What makes ADML an architecture description language for concurrent and distributed systems, is not only its semantics, which are quite standard for a dynamic description logic, but also the use of transition rules for changes at the architectural level, the use of datatypes for data values, and the ability to use that dynamic description logic algorithms and implementations to provide reasoning services for ADML.

<table><caption>**Table 2.** ADML axioms, facts, and transition rules</caption><thead><tr><th>ADML Syntax</th><th>DDL Syntax</th><th>Semantics</th></tr></thead><tbody><tr><td><strong>Elements</strong></td><td></td><td></td></tr><tr><td>Element( A partial C<sub>1</sub> ... C<sub>n</sub>)</td><td>A &sub; C<sub>1</sub> &cap; ... &cap; C<sub>n</sub></td><td>A<sup>I</sup> &sub; C<sub>1</sub><sup>I</sup> &cap; ... &cap; C<sub>n</sub><sup>I</sup></td></tr><tr><td>Element( A complete C<sub>1</sub> ... C<sub>n</sub>)</td><td>A = C<sub>1</sub> &cap; ... &cap; C<sub>n</sub></td><td>A<sup>I</sup> = C<sub>1</sub><sup>I</sup> &cap; ... &cap; C<sub>n</sub><sup>I</sup></td></tr><tr><td>SubElementOf(C<sub>1</sub> C<sub>2</sub>)</td><td>C<sub>1</sub> &sub; C<sub>2</sub></td><td>C<sub>1</sub><sup>I</sup> &sub; C<sub>2</sub><sup>I</sup></td></tr><tr><td>EquivalentElements(C<sub>1</sub> ... C<sub>n</sub>)</td><td>C<sub>1</sub> = ... = C<sub>n</sub></td><td>C<sub>1</sub><sup>I</sup> = ... = C<sub>n</sub><sup>I</sup></td></tr><tr><td>DisjointElements(C<sub>1</sub> ... C<sub>n</sub>)</td><td>C<sub>1</sub> &cap; C<sub>j</sub> = &perp;, i &ne; j</td><td>C<sub>i</sub><sup>I</sup> &cap; C<sub>j</sub><sup>I</sup> = &empty;, i &ne; j</td></tr><tr><td>Datatype(D)</td><td></td><td>D<sup>I</sup> &sub; D<sub>D</sub></td></tr><tr><td>Datatype Properties (U)</td><td></td><td></td></tr><tr><td>DatatypeProperty(U super(U<sub>1</sub>) ... super(U<sub>n</sub>))</td><td>U &sub; U<sub>i</sub></td><td>U<sup>I</sup> &sub; U<sub>i</sub><sup>I</sup></td></tr><tr><td>DatatypeProperty(U domain(C<sub>1</sub>) ... domain(C<sub>m</sub>))</td><td>&ge; 1 U &sub; C<sub>i</sub></td><td>U<sup>I</sup> &sub; C<sub>i</sub><sup>I</sup> &times; D<sub>D</sub></td></tr><tr><td>DatatypeProperty(U range(D<sub>i</sub>) ... range(D<sub>j</sub>))</td><td>T &sub; &forall; U.D<sub>i</sub></td><td>U<sup>I</sup> &sub; D<sub>i</sub> &times; D<sub>j</sub><sup>I</sup></td></tr></tbody></table>
<table>
  <tbody>
    <tr>
      <td>DatatypeProperty(U Functional)</td>
      <td>T &sub; &le;1U</td>
      <td>U<sup>I</sup> is functional</td>
    </tr>
    <tr>
      <td>SubPropertyOf(U<sub>1</sub> U<sub>2</sub>)</td>
      <td>U<sub>1</sub> &sub; U<sub>2</sub></td>
      <td>U<sub>1</sub><sup>I</sup> &sub; U<sub>2</sub><sup>I</sup></td>
    </tr>
    <tr>
      <td>EquivalentProperties(U<sub>1</sub> ... U<sub>n</sub>)</td>
      <td>U<sub>1</sub> = ... = U<sub>n</sub></td>
      <td>U<sub>1</sub><sup>I</sup> = ... = U<sub>n</sub><sup>I</sup></td>
    </tr>
    <tr>
      <td>Object Properties</td>
      <td></td>
      <td></td>
    </tr>
    <tr>
      <td>ObjectProperty(R super(R<sub>1</sub>) ... super(R<sub>n</sub>))</td>
      <td>R &sub; R<sub>i</sub></td>
      <td>R<sup>I</sup> &sub; R<sub>i</sub><sup>I</sup></td>
    </tr>
    <tr>
      <td>ObjectProperty(R domain(C<sub>1</sub>) ... domain(C<sub>m</sub>))</td>
      <td>&ge; 1 R &sub; C<sub>i</sub></td>
      <td>R<sup>I</sup> &sub; C<sub>i</sub><sup>I</sup> &times; A</td>
    </tr>
    <tr>
      <td>ObjectProperty(R range(C<sub>1</sub>) ... range(C<sub>i</sub>))</td>
      <td>T &sub; &forall; R.C<sub>i</sub></td>
      <td>R<sup>I</sup> &sub; A &times; C<sub>i</sub><sup>I</sup></td>
    </tr>
    <tr>
      <td>ObjectProperty(R Functional)</td>
      <td>T &sub; &le;1R</td>
      <td>R<sup>I</sup> is functional</td>
    </tr>
    <tr>
      <td>ObjectProperty(R Transitive)</td>
      <td>Tr(R)</td>
      <td>R<sup>I</sup> = (R<sup>I</sup>)<sup>+</sup></td>
    </tr>
    <tr>
      <td>SubPropertyOf(R<sub>1</sub> R<sub>2</sub>)</td>
      <td>R<sub>1</sub> &sub; R<sub>2</sub></td>
      <td>R<sub>1</sub><sup>I</sup> &sub; R<sub>2</sub><sup>I</sup></td>
    </tr>
    <tr>
      <td>EquivalentProperties(R<sub>1</sub> ... R<sub>n</sub>)</td>
      <td>R<sub>1</sub> = ... = R<sub>n</sub></td>
      <td>R<sub>1</sub><sup>I</sup> = ... = R<sub>n</sub><sup>I</sup></td>
    </tr>
    <tr>
      <td>Annotation</td>
      <td></td>
      <td></td>
    </tr>
    <tr>
      <td>AnnotationProperty(S)</td>
      <td></td>
      <td></td>
    </tr>
    <tr>
      <td>Facts</td>
      <td></td>
      <td></td>
    </tr>
    <tr>
      <td>Individual( o type(C<sub>1</sub>) ... type(C<sub>n</sub>))</td>
      <td>o &sub; C<sub>i</sub></td>
      <td>o<sup>I</sup> &sub; C<sub>i</sub><sup>I</sup></td>
    </tr>
    <tr>
      <td>Individual( o value(R<sub>1</sub> o<sub>1</sub>) ... value(R<sub>n</sub> o<sub>n</sub>))</td>
      <td>&lt;o, o<sub>i</sub>&gt; &sub; R<sub>i</sub></td>
      <td>&lt;o<sup>I</sup>, o<sub>i</sub><sup>I</sup>&gt; &sub; R<sub>i</sub><sup>I</sup></td>
    </tr>
    <tr>
      <td>Individual( o value(U<sub>1</sub> v<sub>1</sub>) ... value(U<sub>n</sub> v<sub>n</sub>))</td>
      <td>&lt;o, v<sub>i</sub>&gt; &sub; U<sub>i</sub></td>
      <td>&lt;o<sup>I</sup>, v<sub>i</sub><sup>I</sup>&gt; &sub; U<sub>i</sub><sup>I</sup></td>
    </tr>
    <tr>
      <td>SameIndividual(o<sub>1</sub>... o<sub>n</sub>)</td>
      <td>o<sub>1</sub> = ... =o<sub>n</sub></td>
      <td>o<sub>1</sub><sup>I</sup> = ... =o<sub>n</sub><sup>I</sup></td>
    </tr>
    <tr>
      <td>DifferentIndividual(o<sub>1</sub>... o<sub>n</sub>)</td>
      <td>o<sub>1</sub> &ne; o<sub>j</sub>, i &ne; j</td>
      <td>o<sub>1</sub><sup>I</sup> &ne; o<sub>j</sub><sup>I</sup>, i &ne; j</td>
    </tr>
    <tr>
      <td>negationOf (&phi;)</td>
      <td>&not;&phi;</td>
      <td>(M,w) &ne; &phi;</td>
    </tr>
    <tr>
      <td>disjunctionOf(&phi; &phi;' ...)</td>
      <td>&phi;&or (&phi;'</td>
      <td>(M,w) &or; &phi; or (M,w) &or; &psi;</td>
    </tr>
    <tr>
      <td>diamondAssertion(&pi; &phi;)</td>
      <td>&lt;&pi;&gt;&phi;</td>
      <td>&exist;w' &isin; W, ((w, w') &isin; T(&pi;) and (M,w') &or; &phi;)</td>
    </tr>
    <tr>
      <td>Transition rules</td>
      <td></td>
      <td>T(&alpha;) = T(P, E) = { (w, w') | ① (M,w) &or; P, ② (M,w) &or; &not;&phi; for every &phi;&isin;E, ③ (M,w) &or; E, ④ C<sup>I(w)</sup> = (C<sup>I(w)</sup> &cup; {u<sup>I</sup> | C(u)&isin;E}) &smash; {u<sup>I</sup> | &not;C(u)&isin;E}, and ⑤ R<sup>I(w)</sup> = (R<sup>I(w)</sup> &cup; {u<sup>I</sup>, v<sup>I</sup> | R(u, v)&isin;E}) &smash; {u<sup>I</sup>, v<sup>I</sup> | &not;R(u, v)&isin;E}. }</td>
    </tr>
    <tr>
      <td>Transition(&phi; test)</td>
      <td>&phi;?</td>
      <td>{(w, w) | w &isin; W and (M,w) &or; &phi;}</td>
    </tr>
    <tr>
      <td>choiceOf(&pi; &pi;' ...)</td>
      <td>&pi; &cup; &pi;'</td>
      <td>T(&pi;) &cup; T(&pi;')</td>
    </tr>
    <tr>
      <td>sequenceOf(&pi; &pi;' ...)</td>
      <td>&pi; ; &pi;'</td>
      <td>{ (w, w') | &exist;w''.(w, w'') &isin; T(&pi;) and (w'', w') &isin; T(&pi;') }</td>
    </tr>
    <tr>
      <td>Transition (&pi; iteration)</td>
      <td>&pi;<sup>*</sup></td>
      <td>reflexive and transitive closure of T(&pi;)</td>
    </tr>
  </tbody>
</table>

4 Summary and Outlook
In this paper we presented ADML a new formal language and/or conceptual model for representing system architectures. We described the main features of ADML, its rationale, and technical innovations. By embracing transition rules into ADML, ADML combine the static knowledge provided by the system requirements with the dynamic descriptions of the computations provided by transition rules, and support the representing and reasoning about both static knowledge and dynamic knowledge in concurrent and distributed systems. ADML can be viewed as syntactic variants of dynamic description logic DDL(*SHON*(D)). The functionalities of the transition rules are abstracted by actions in DDL(*SHON*(D)), while the domain constraints, states, and the overall system objectives are encoded in TBoxes, ABoxes and DL-formulas, respectively. So the main reasoning problem in ADML can be reduced to knowledge base (KB) satisfiability in the DDL(*SHON*(D)) dynamic description logic. Afterwards, dynamic description logic algorithms and implementations can be used to provide reasoning services for ADML. ADML has evolved from several sources:1) Rapide[13] (a concurrent event-based simulation language for defining and simulating the behavior of system architectures.), 2) Acme[14] (a common representation for software architectures), 3) DDL[6][9] (for event patterns and formal constraints on concurrent behavior expressed in terms of description logics). While ADML is still too new to tell whether it will succeed as a community-wide tool for architectural development, we believe it is important to expose its language design and philosophy to the broader software engineering community at this stage for feedback and critical discussion.

In the future, we plan to investigate how we can leverage Distributed Dynamic Description Logics (D3Ls) to support a larger variety of heterogeneous systems with our approach. Another issue for future work is the design of “practical” algorithms for DDL(*SHON*(D)) reasoning.

## Acknowledgements

This work is supported by the Fundamental Research Funds for the Central Universities (No.11QG13) and the National Science Foundation of China (No.71101048).

## References

1. Dashofy, EM., Van der Hoek, A., Taylor, RN.: A comprehensive approach for the development of modular software architecture description languages. ACM transactions on software engineering and methodology, vol. 14, no. 2, pp. 199-245(2005)

2. Azevedo, R., Rigo, S., Bartholomeu, M.: The ArchC architecture description language and tools. International journal of parallel programming, vol. 33, no. 5, pp. 453-484(2005)

3. Mishra, P., Dutt, N.: Architecture description languages for programmable embedded systems. IEE proceedings-computers and digital techniques, vol. 152, no. 3, pp. 285-297(2005)
4. Perez, J., Ali, N., Carsi, JA., Ramos, I.: Designing software architectures with an aspect-oriented architecture description language. Lecture notes in computer science, vol. 4063, pp. 123-138(2006)

5. Baader, F., Calvanese, D., McGuinness, D., Nardi, D., Patel-Schneider, P. F.: The description logic handbook: theory, implementation, and applications. Cambridge University Press(2003)

6. Shi Z., Dong M., Jiang Y., Zhang H.: A logical foundation for the semantic web. Science in China, Ser. F, vol. 48, no. 2, pp. 161-178(2005)

7. Artale, A., Franconi, E.: A temporal description logic for reasoning about actions and plans. J. Artif. Intell. Res. USA, vol. 9, pp. 463-506(1998)

8. Baader, F., Lutz, C., Milicic, M., Sattler, U., Wolter, F.: Integrating description logics and action formalisms: First results. Proc. Natl. Conf. Artif. Intell. USA, vol. 2, pp. 572-577(2005)

9. Chang, L., Shi, Z., Gu, T., Zhao, L.: A Family of Dynamic Description Logics for Representing and Reasoning About Action. J. Autom. Reasoning. Springer Netherlands, pp. 1-52(2010)

10. Wang, Z., Yang, K., Shi, Z.: Failure Diagnosis of Internetware Systems Using Dynamic Description Logic. J. Softw. China, vol. 21, pp. 248-260(2010)

11. Wang Z., Guo J., Wu K., He H., Chen F.: An architecture dynamic modeling language for self-healing systems. Procedia Engineering, vol. 29, no. 3, pp. 3909-3913(2012)

12. Wang, Z., Zhang, D., Shi, Z.: Multi-agent based bioinformatics integration using distributed dynamic description logics. Int. Conf. Semant., Knowl., Grid. China, pp. 66-71(2009)

13. Luckham, DC., Vera J.: An Event-Based Architecture Definition Language. IEEE transactions on software engineering, vol. 21, no. 9, pp.717-734(1995)

14. Garlan D., Monroe R., Wile D.: Acme: an architecture description interchange language. CASCON First Decade High Impact Papers. USA, pp. 159-173(2010)