A user uses the system to send a message to another user.
Characteristics: Very common in some domains. Simple.
Keywords: Batch job, communication, email, SMS, system alert.
The Message Transfer: Deferred Delivery blueprint consists of two use cases. The first, called Register Message, receives a message from the Sender and stores it to be delivered at a later moment in time. When requested by the Receiver, the second use case, Deliver Message, checks whether there are any stored messages to be delivered to the actor. If there are, these messages are delivered to the actor and then, possibly, eliminated from the system.
The Message Transfer: Immediate Delivery blueprint captures the situation when messages are delivered right away, and are not to be stored in the system. If no receiver is available when a message arrives, the message is just discarded and is not delivered to that receiver. No use case retrieving messages is therefore needed in this blueprint.
Another Message Transfer blueprint describes the situation when it is not an actor that initiates the sending of the message, but an action performed inside the system. In this case, the Create and Register Message use case models the creation and the storage of the message in the system. This use case will have an extend relationship to the use case comprising the initiating action, so the creating and storing actions will be added when a use-case instance executes the initiating action. Similarly, the delivery of the message is initiated by the performance of a use case, instead of by request of an actor.
When an actor sends a message to the system to be delivered to another actor (or to a collection of actors), the system looks up the receiver of the message and checks where it should be delivered so that it will reach its receiver. After the delivery location has been identified, the system delivers the message (Message Transfer: Immediate Delivery).
There is a huge number of examples where a system is used for transferring a message from one user to another user (or users). Two obvious examples are sending emails and sending SMS (Short Message Service), where the sender enters a message together with the address of the receiver. The system translates the address to a location where the message is to be delivered, and finally the system transfers the message to that location where it will reach its receiver.
Another kind of system emitting messages to its users is a warehouse system that will notify the purchaser when the number of items of a specific type falls below a threshold.
A third example of such a system is a surveillance system transferring alarms, such as burglary alarms, fire alarms, and flooding alarms, to an operator to take proper actions.
However, in some cases, the delivery of the message may be deferred. For example, the system may be overloaded; the message, its sender, or its receiver may have a low priority; the message can have a later delivery time; or the receiver may be disconnected from the system. In all these cases, the message must be stored in the system to be delivered later, as in the Message Transfer: Deferred Delivery blueprint.
If the receiver of an SMS has switched off the mobile phone, the system cannot deliver the SMS instantly. Instead, it is stored in the system until the receiver switches on the mobile phone. When the system detects that the receiver is again connected to the system, it delivers the SMS.
In some applications, there will not be a user of the system who initiates the sending of the message: It will be the system itself. In these cases, an action inside the system causes the creation and the transmission of the message. As discussed in Chapter 8, “Extend: Expanding Existing Use Cases,” the addition of extra actions is preferably modeled by a separate use case with an extend relationship to the original (the base) use case. Therefore, creating and transmitting the message is expressed in an extension use case with an extend relationship to the use case comprising the action causing the message to be sent. This situation is captured in the Message Transfer: Automatic blueprint.
People often have badges or cards granting them access to buildings and rooms. To enter through a locked door, they slide their cards through a card reader, which allows the system to check whether the cardholder is allowed to enter through that door. If so, the system unlocks the door. Otherwise, the door remains locked.
In such a system, a guard is notified, depending on the level of security, if an unauthorized person is trying to enter into a restricted area. The use case sending the message to the security guard is extending the use case checking whether the person is allowed to enter through the door and, if so, sends an unlock signal to the locking device of that door. In this example, we have used a degenerated form of the Message Transfer: Automatic blueprint, where the use cases for creating and for delivering the message are merged (see Figure 32.1).
This section provides an example of the Message Transfer: Automatic blueprint, and presents four examples of use-case descriptions from a warehouse system (see Figure 32.2).
Figure 32.2. The messages created in the Restock Item use case are delivered by the Deliver Message use case.
A Clerk will use the Create Order use case to register a new order in the system. The Restock Item use case extends the Create Order use case to check for each ordered item whether the number of items in stock falls below a given threshold. If so, a restock message to the purchaser is created in the system. Each time a System User, among them the purchaser, logs in to the system, the Deliver Message use case extends the login procedure and checks whether there are any messages to that user. If so, these messages are presented.
See also the CRUD and the Optional Service patterns and the Login and Logout blueprints, which are all relevant to this example.
The analysis model realizing the Message Transfer blueprints involves a collection of classes. First, we need to be able to handle information about the message to be transmitted, such as who is the receiver and what is the message. Second, to be able to check whether the receiver is connected to the system, and if so where the message is to be delivered, the model must capture information about the receivers. The model therefore contains two entity classes, called Message and User Information. Furthermore, the model contains one control class, called Message Handler, which performs the checks and stores, retrieves, and delivers the messages.
Finally, there must be a collection of boundary classes for the interactions with the two actors. For the Sender, we need a boundary class, called Message Definition UI, for preparation of the message. If the Sender can transmit messages directly to the system, this boundary class acts as a communication protocol. If the Sender is a human being who can select to send messages among a collection of tasks, however, this selection must be made through a separate, basic interface. Therefore, we introduce the System Form boundary class. In this case, the Message Definition UI will most likely be a kind of editor, like an email editor.
The situation is similar for the Receiver. There is one boundary class for presenting the message, called Message Presenting UI, which will be a communication protocol if the Receiver is a kind of machine or system. Otherwise, if the Receiver is a human being, the boundary class will be a window, a form, or similar. The System Form boundary class is used when the Receiver must request the system to deliver the stored messages. This leads us to the model presented in Figure 32.3.
The flow of the Transfer Message use case will start when the Sender chooses to send a message. This is either done in the System Form, where the Sender chooses to send a message that will cause the Message Definition UI to be presented where the Sender enters the message, or, for nonhuman senders, the Sender can immediately send the message through the Message Definition UI without initiating the use case through the System Form.
An instance of Message Handler is created that receives the message and checks where to find the receivers using the information in the User Information instances together with the information in the message. If the message is to be delivered immediately (Message Transfer: Immediate Delivery), the Message Handler transmits the message to the Receivers through the Message Presenting UI, whereas for a message to be stored in the system and delivered later (Message Transfer: Deferred Delivery) the Message Handler creates an instance of the Message entity class that will be stored in the system.
The next time a Receiver requests the stored messages, an instance of Message Handler is created to check whether there are any messages to that Receiver. If so, the Message Handler retrieves these messages, removes those instances of the Message entity class, and presents the messages to the receiver.
In those cases where the creation and the delivery of the messages are modeled in extension use cases (Message Transfer: Automatic), control classes of the base use cases replace the Message Definition UI and the System Form, respectively.