Next: 5 Analysis
Up: Specifying Dynamism in Software
Previous: 3 Simulating Dynamism
Our solution consists of introducing special ``control" events, into a component's alphabet, and permitting them to be used in port descriptions. In this way, the interface of a component is extended to describe when reconfigurations are permitted in each protocol in which it participates. These control events are then used in a separate view of the architecture, the configuration program, which describes how these events trigger reconfigurations.
To illustrate, the configurations pictured in Figure 5 are triggered (as before) by the ``serverDown" and ``serverUp" events, now explicitly marked as ``control" rather than ``communication" events. The changes to the architectural topology are achieved using sequences of ``new", ``del", ``attach", and ``detach" actions, as defined by the reconfiguration program, ``Configuror", as illustrated in Figure 6 and Figure 7.
This reconfiguration program is responsible for describing change of the architecture in terms of the architecture types (e.g., ``Client", ``FlakyServer", ``SlowServer") declared in the usual way. In this example, the ``Client" component type is as in Figure 2. The primary server (a component of type ``FlakyServer", not shown here) indicates the states in which it may go down, and the link and secondary server indicate the states in which they can be reconfigured. For example, Figure 8 shows how a ``FaultTolerantLink" might indicate its possible reconfigurations. In this description, the control event ``ChangeOK" indicates the states at which the link is prepared to accept reconfiguration.
Robert Allen, Remi Douence, and David Garlan