An actor provides a stream of input to the system, and the handling of this input is to be described by use cases. The solution to this problem depends on whether the stream consists of discrete values or of continuous values.
Characteristics: Common in some domains. Advanced.
Keywords: Analog device, analog system, continuous system, discrete stream, input signal, input stream.
Some systems continuously receive a stream of values to be handled in some way. We differentiate between two kinds of streams: streams consisting of discrete values and analog streams with analog values.
Typical examples of systems with input streams of discrete values are surveillance systems reading the distinct values produced by other systems, and production systems producing output values based on the received input. In cases such as these, we apply the first Stream Input blueprint and let the use case model how one value from the stream is consumed and handled by the system. Instances of these use cases will run very quickly, and there is, practically all the time, an instance of this type running in the system.
One advantage of modeling the consumption of only one value in a use case rather than including a loop in the use case consuming all the values in the stream is that we can have multiple use cases each of which describes how a subset of the possible input values are to be handled (see Figure 35.1). Therefore, we do not have to cover all the possible values in one use case. New types of values can be added in later versions of the model by just adding new use cases; we will not have to modify the existing ones.
Figure 35.1. If the system receives a discrete stream of input values of different kinds, we describe the handling of the different kinds of values in different use cases.
Another reason why we model only one input to the use case and not the complete sequence is that inserting a loop around the description of how the input is to be handled by the use case will not add any extra meaning to the model—it already captures what the system will do with the input. The only effect is that we reduce the number of instances of that use case. This may be tempting, especially for programmers who are used to thinking in terms of effectiveness and saving resources, but keep in mind that a use-case model does not capture such aspects. The number of use-case instances has no impact on the performance of the final implemented system!
Furthermore, we must not confuse the use case with a probable implementation of the system, which may contain a loop retrieving all input values and dispatching them to different routines handling different kinds of values. The use case describes one usage of the system, which, in this case, is the reception and handling of one value. If we insert the loop into the use case, we must also describe when and how we exit the loop, what is to be done when an unrecognized value is received (this can be captured by a separate use case if no loop is used), and so on.
Obviously, if the input stream consists of sub-sequences of discrete values forming a whole, the use case should consume a whole sub-sequence.
What, then, is to be done when the input can be characterized as a continuous function? A typical example of such a system is an analog electric amplifier. Unfortunately, use cases do not handle continuous values too well. In fact, languages based on Turing machines deal only with discrete, not continuous, values. We have found that such cases are best captured if the input and the checking of values are described using ordinary use-case description techniques, whereas the output function can be given in a separate chapter in the use-case description. The chapter on the output can of course be structured with subsections if the output function is complex with, for example, different behavior at different intervals of input.
According to the Stream Input: Analog blueprint, we have one use-case instance running as long as the input stream keeps coming (see Figure 35.2). This would seem to contradict what we said above about discrete input streams, where a use-case instance handles only one entity in the stream.
Figure 35.2. The system acts partly as an analog system, and this part of the system is described in one use case.
However, in a continuous analog signal, it is not possible to identify separate entities of the input, by definition.
The description of a use case operating an analog input stream looks quite like the description of an ordinary use case. However, there is one difference: What is performed on the input stream (the transformation) is here described by means of a mathematical function and not in the form of an operational description, like as a sequence of actions.
As stated previously, a use case receiving one value in a stream of discrete values is described as any other use case receiving a single input value, so there is no point in giving an example of such a situation.
The following example is an application of the Stream Input: Analog blueprint, describing a use case which models an amplifier that receives input in the form of an analog electrical current and outputs the amplified current (see Figure 35.2).
Other useful patterns in this example are the Business Rules and the Multiple Actors patterns.
Use Case: Amplify Input Stream
Brief Description
The use case amplifies an analog electric current received from the Input Stream Generator, and outputs it to the Output Stream Receiver.
Basic Flow
The use case starts when it receives an analog electric current from the Input Stream Generator.
As long as the current is received, the use case outputs an amplified analog output stream to the Output Stream Receiver according to the amplification function described in the section Function.
The use case ends when no input stream is received.
Function
The amplification is modeled by the following function:
where
Vout | : | voltage on the collector |
Vin | : | voltage on the base |
β | : | base–collector current amplification |
RC | : | resistance connected to the collector |
RE | : | resistance connected to the emitter |
r | : | base–emitter resistance |
For a more thorough description, see Microelectronic Circuits and Devices (Horenstein 1996).
The model of a system receiving a stream input will look like an ordinary analysis model (see Figure 35.3).
However, our experience is that if the system models the reception of an analog stream, it is unlikely that the model will contain an entity class, because no information is stored, and the number of control classes will also be small, as there will be only a few different tasks. The descriptions of the boundary classes and the control classes will mostly reference specifications found in other documents, like information about which amplification function is to be used.