|
Identify and define relevant classes
| When sticking to the Observer/Controller Architecture, at least classes for observers and controllers have to
be defined. It is often helpful to also specify an agent model that holds the current agent state and classes for different
types of constraints. Existing elements from the agent or the system architecture can be re-used for this purpose or new
ones can be introduced. |
Define interaction between observer and agents
| A crucial aspect of the observation model is the way the observer gathers data from the agents. It is possible that the
observer can directly access the state data of the agents, that the agents communicate this information, or that the
observer solely relies on external observation. |
Define interaction between observer and controller
| Define the way the observer informs the controller of constraint violations and the controller informs the observer of a
finished reconfiguration. If necessary, the interaction between the controller and the agents should also be specified
here. |
Define relevant associations and fields of the classes in the observation model
| Depending on the way information is exchanged between observers and agents and how the observers and the controllers
interact, as well as the way state information about the agents is stored, associations between the classes have to be
introduced and fields have to be added. |
Specify behaviour of relevant methods
| Both the observer and the constraint classes contain methods that implement crucial system behaviour. The method that
checks whether a constraint holds is one example for this. As these methods will have to be transformed into code later on,
these methods should be specified, e.g., with activity charts to unambiguously define the dynamic behaviour. For the
example mentioned, the method should contain a placeholder for the concrete constraint that will later be checked by a
specialisation of the class, realising a variant of the Template Method pattern. |
|
