The system is to monitor or control an external medium that in itself is passive (for example, the surrounding air or a fluid).
Characteristics: Common in some domains. Advanced blueprint.
Keywords: Measuring, sensor, unbound external medium.
This blueprint consists of one actor and one use case. The use case receives a value from a medium external to the system, but the medium itself is passive; that is, it does not actively send any information to the system. That is why the device measuring the value from the medium rather than the medium itself is modeled as the actor.
In some problem domains, it is quite common that a device in the system's surroundings provides input to the system. It can, for example, be a thermometer that transmits information about the current temperature of a liquid, or an altimeter that continuously transfers information about the present altitude above sea level.
In situations such as these, we measure some property of a medium outside the system: the liquid or the air, respectively. In neither case does the medium itself send a stimulus to the system, nor does it make use of the system; the medium is passive relative to the system. It would therefore be unnatural to say that the medium is an actor to the system and that the medium sends information to the system. Likewise, it would be wrong to say that the system sends information to the medium. Therefore, when the external entity is a passive, possibly unbound medium, such as a liquid or a gas, we usually model the measuring device as the actor to the system. The device can be said to interrogate the medium and inform the system about the current state of the medium; that is, the device actually does something to the system whereas the passive medium does not (see Figure 33.1).
Figure 33.1. If the external entity affecting the system is a passive medium, we model the device interrogating the medium as the actor, whereas in all other cases, we do not model the device but the user of the system as an actor.
It is important to emphasize that we normally do not model devices as actors but rather the individuals behind the devices, and that this situation with the passive medium is an exception. Usually it is the individual using the device for communication with the system that will benefit from using the system, whereas the device will not. The latter will just transform the input or the output into something that the system and the user can understand. For example, we do not model the receipt printer device or card reader device as actors to an ATM, because we do not see them as users of the ATM—they gain nothing from interacting with the ATM. The printer and the reader are just pieces of machinery transforming communications. It is the customer who takes an interest in using the ATM, and therefore the customer is modeled as the actor.
The example provided in this section consists of a heating control system. The model consists of two use cases guiding a heater (see Figure 33.2). The first use case reads the input values, and if they differ more than 2 degrees from the normal value, it will turn on or turn off the heater so that it will run or stop running at half capacity. If the input value is more than 5 degrees below the normal value, the second use case will start, and the heater will run at full power for 1 minute. Then the heater is turned off, and the use case ends. Because the heater is allowed to run on full power only for a short period and then it must be turned off, we have chosen to model this usage as one use case instead of applying a Future Task blueprint.
In this example, the heater is considered part of the system, and therefore it is not modeled as an actor. If it were not part of the system, we would just model the heater as an actor, and then have the two use cases associated with it.
Note that this is an example of a situation where the two use cases start in the same way, so it will not be possible to determine which of the two use cases a use-case instance will follow from the start (see the section Use-Case Instance: A Specific Utilization in Chapter 4, “Use Cases”). This cannot be determined until the use-case instance has calculated the temperature difference.
New use cases can be added to the model if other alternative responses to the value received from the thermometer are to be provided.
The CRUD and the Optional Service patterns and the Stream Input blueprints are also useful in this example.
The analysis model of a system with a passive external medium is modeled as an ordinary analysis model. The only thing specific with such a model is that the actor is a mediating device, but this is no different from any analysis model with a nonhuman actor. In Figure 33.3, the External Device actor interacts with an object of a boundary class, Device Interface, that models the interaction protocol between the system and the device. The boundary object transforms the received input to internal messages and sends them to objects of the Device Input Handler control class, which handles them as is formulated in the use-case descriptions. This may involve interaction with other control objects and entity objects as well as other boundary objects for communication with other actors.
