next up previous
Next: 2 Motivating Example Up: Specifying Dynamism in Software Previous: Specifying Dynamism in Software

1 Introduction

Recently, there has been considerable progress on the development of architecture description languages (ADLs [Med97]) to support software architecture design and analysis. These languages capture the key design properties of a system by exposing the architectural structure as a composition of components interacting via connectors. Examples include Wright [All97] [AG97], UniCon [SDK+95], Rapide [LAK+95], Darwin [MK96] and ACME [GMW].

There are many aspects of a software system that can be addressed in an architectural description, including functional behavior, allocation of resources, performance, fault-tolerance, flexibility in the face of altered requirements, and so on. Each ADL tend to focus on one or more of these aspects.

In this position paper we address the problem of capturing dynamic architectures. By ``dynamic" we mean systems for which composition of interacting components changes during the course of a single computation. We distinguish this aspect of dynamic behavior from the steady-state behavior, by which we mean the computation performed by a system without reconfiguration.

We argue that it is both possible and valuable to separate the dynamic re-configuration behavior of an architecture from its non-reconfiguration functionality. While there exist ADLs, such as Darwin, that capture reconfiguration behavior, and facilities such as object-oriented languages that permit the combined description of both dynamic aspects and steady-state behavior, we believe that, at the architectural level, it is important to provide a notation that supports both aspects of design while maintaining a separation of concerns. In the remainder of this paper we illustrate a new technique by which these two aspects can be described in a single formalism while keeping them as separate ``views". This facilitates the understanding of each aspect in isolation while still supporting analysis of the combined interaction between the two.

By providing a notation that provides a precise interpretation of each of these aspects, we permit the description to be analyzed for consistency and completeness, as well as for whether the system has application specific properties desired by the architect. For example, we would like to guarantee that reconfigurations occur only at points in the computation permitted by the participating components and connectors. Also, whenever a new connection is established, it must be shown that the participating components exist at the moment of attachment. By considering interactions between the two forms of description, we can consider whether changing the participants at run time will result in inconsistencies among participants' states.

In the remainder of this short paper we will sketch the basic idea using the Wright ADL as our notational basis. We first illustrate the problem. Then we show how a language originally designed for steady-state architectures, such as Wright, can be extended to handle dynamic aspects of architecture modeling and analysis. Next, we illustrate the kinds of analysis that such a formalism supports. Then we briefly sketch the semantic model on which the approach is based.


next up previous
Next: 2 Motivating Example Up: Specifying Dynamism in Software Previous: Specifying Dynamism in Software

Robert Allen, Remi Douence, and David Garlan
Sept. 4, 1997