Filter
Top Products
Chapter 3. Black-box thinking: Defining the system context 53
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 IT-oriented technical language,
even if this is more precise, since it will hinder understanding and genuine
agreement from stakeholders.
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 white-box steps, should be used for operation realizations, derived in
the flowdown process as described in succeeding sections.
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.