7 Summary and Discussion

We have described an approach to architectural specification that permits the representation and analysis of dynamic architectures. The approach is based on four ideas:

1.

sep -3pt

2.

Localization of reconfiguration behavior, so that it is possible to understand and analyze statically what kinds of dynamic (topological) architectural changes can occur in a running system.

3.

Uniform representation of reconfiguration behavior and steady state behavior, so that interactions between the two can be analyzed.

4.

Clearly delimited interactions between the two kinds of behavior through the use of control events, so that one can explicitly identify the points in the steady state behavior at which reconfigurations are permitted.

5.

Semantic foundations based on CSP, so that we can exploit traditional tools and analytic techniques based on process algebras.

We illustrated the approach with a simple example, to show how specification and analysis could help us detect and then fix a bug in the description. We argued briefly that such a bug is one that might well occur in a naive implementation of such a system.

The approach we have taken differs in several fundamental ways from those taken by other researchers. The most obvious, and perhaps most contentious, is the use of CSP as the underlying semantic model. In choosing CSP we have made an important trade-off: we are willing to reduce the class of dynamic systems that we can describe, in exchange for a formalism that is amenable to deep static analysis. In particular, the class of system excludes systems that inherently create an infinite number of configurations during run time. (This rules out, for example, algorithms such as the Prime Sieve in which a new filtering process is created for each prime number).

On the other hand, we are able to account for the large (and we would argue, central) class of system where the collection of possible topologies is effectively bounded and known at system definition. This includes a broad class of client-server systems and many fault tolerant architectures (such as Simplex [RD95]).

We believe that this trade-off is worth making, and that we have identified an important place in the design space of architectural formalization. However, at present this is largely a conjecture. On-going research will hopefully shed further light on the strengths and weakness of the approach that we are advocating.

In addition to gaining further experience with the approach, there are a number of technical extensions that are worth exploring. First, we think the relationship between Wright specifications and the concrete implementations should be studied (e.g. automatic code skeleton generation, or conversely reverse ingineering extracting a Wright specification). Second, fault tolerance introduces notions (e.g. timeout, preemption) along with idiomatic encoding (replace the absence of event by a timeout event, set an interruptible interpretative cycle). Wright could be specialized, so that libraries of style with specialized transformations and analysis provide these idioms. Finally, all interesting properties can't be expressed in CSP. Our framework could be reused by replacing CSP by another formalism (e.g. temporal logic).