While use case flows of events can be written in many formats, we find that a simple numbered list of steps is the most useful. Remember that one of the main purposes of use cases is to be readable by many stakeholders. To make this possible, use cases should be written in plain language and using terms familiar to the organization. It does no good to write in
The MDSD template for a use case is shown in Appendix A, “MDSD use case specification template” on page 181. Note that this template has two alternate formats for the flow of events. The plain numbered list of steps should be used for enterprise and element use cases, and the table format, with columns for both black- and
Initiation of the use case
In MDSD, we require that actors initiate all use cases. Why is this? Since we are building a model in which we will ultimately express all system functionality as operations of system elements, what we are after is all of the functionality that can be requested of these elements. We will derive the needed operations from this set of requests. It will be seen later why system functionality that is assumed to be initiated by the system itself must be represented as part of a larger behavior that is initiated by an actor, but for now, simply write use cases as if they are initiated by an actor. Here is how.
It might take some looking to determine the correct actor to represent the initiator of the use case. A common case is behavior that is initiated based on a schedule. If such behavior is actually initiated based on an outside scheduler system, then this can be the actor. If the behavior is initiated by a clock, and the clock is external to the system, then the clock can be represented as an actor. In the rare case when the behavior is initiated by system, based on time, and the only time reference or clock is also inside the system, the best choice is to have an actor called time. This allows behavior to be modeled as if time is requesting it to happen. This might seem awkward, but by doing this all behavior will be captured as part of operations.
We have also found it best to adopt the convention of beginning each use case with the phrase This use case begins when… followed by the event that starts the use case. Some examples are shown here.
Chapter 3. | 53 |
