The
following example presents a simple case in which coordination contracts
are applied to a control system. In particular, it presents how contracts
can coordinate and superpose behaviour to a number of components (devices)
of a control system without having such components interacting directly or even via a
mediator. As we have repeatedly discussed in previous sections, such absence of coupling between components
provides higher possibility for "black-box" reuse and
library-based development and facilitates the evolution of systems based
on changes performed only on the interconnections (contracts) between
components and not on the components themselves.
The System
Consider a very simple control system consisting of
a Sensor that periodically reads values of a Variable (for instance
temperature) and an Actuator that performs actions increasing or
decreasing the variable of interest based on the sensor's samples. A Java simulating
implementation of such components is given in the following classes: Variable.java,
Sensor.java,
Actuator.java.
Notice that Sensor and Actuator know the variable of interest but do
not communicate with each other either directly or indirectly. Consider
the following cases of desired system functionality and the contract-based
solutions:
How we can perform the appropriate actions on the Actuator, decreasing or increasing the variable (to be more precise, correcting the next variable value towards a desired direction) based on the values read by the sensor even though the Actuator does not know the Sensor nor they communicate via a mediator. Consider the following contract, SensorActuatorController.ctr, that imposes the appropriate actions to the Actuator whenever the value read by the Sensor is not within a desired interval.
Consider now a class BoundSensor.java, that implements a "sensitive" Sensor that should operate only when the variable of interest values are within an interval, and should be stopped otherwise. The following contract, BoundSensorController.ctr, superposes this requirement on a BoundSensor instance. Notice, that this is a case in which a contract's rule has as trigger an operation that is not defined on the participant but inherited from the participant's superclass.
A third case is one in which you can combine the two previous cases by applying to the BoundSensor both SensorActuatorController and BoundSensorController contracts so that the Actuator is now operating together with BoundSensor (and not Sensor as in the first case) and that BoundSensor can still be stopped if the variable values are out of the its operating bounds. This case, also, illustrates that you may apply an instance of a subclass (BoundSensor) to a contract (SensorActuatorController) that defines as participants types of a base/super class .
The following file Application.java, puts together the previous three cases. Remove the comments for each case specified and observe the output for each one of them. Feel free, as an exercise, to change the rules or add your own contracts, for instance adding a contract that restarts the BoundSensor when it is stopped. You may also even extend the application to a more realistic case by using multithreading or synchronization.
© Copyright 2001 ATX Software SA. All rights
reserved.