Filter
Top Products
52 Model Driven Systems Development with Rational Products
Use case flows of events
Here we discuss how to write use case flows of events.
MDSD Step 6: Write use case flows of events
With the use cases identified, the next step is to write flows of events. As noted
before, use case modeling is, for the most part, done in MDSD exactly as in
traditional use case modeling, Here we offer just a few highlights of the most
important things to remember in writing a flow of events for MDSD.
Level of detail in use case flows
One of the common questions asked about use cases is How much detail should
be included in a use case? The question implies that there is a sort of sliding
scale of detail that one can increase or decrease. Actually, it is simpler than that.
Use cases should contain enough detail to fully explain the actor interactions
necessary to accomplish the use case. Thus the use case will keep to the
black-box perspective, and not contain any details about what happens inside the
system to accomplish the use case. Some exceptions can be made to this rule,
but let us consider the dangers before we explain those.
If, while writing a use case, we begin to include details about what is happening
inside the system, we risk spiraling down into system details that will prevent us
from seeing the important aspects of the level of abstraction we are examining.
Remember that the focus of the use case is the interactions between the
elements outside the system and the system itself.
Use cases are statements of requirements, and thus should not include
white-box design decisions, even if they are known at this point. For one thing,
they can change multiple times as the design is validated, and for another, such
details will be specified at a lower level of abstraction, and thus would be
redundant here.
That use cases should keep to a black-box perspective is not to say that they
should not be specific and detailed within that perspective. Sometimes we see
use cases that contain steps akin to this:
The user enters the important information into the system.
Use cases should indeed specify what information is required, either by stating
the data items directly or by specific reference to a data dictionary or other
outside source. As we will see, this information can be included in the model in
the form of operation signatures as the use cases are analyzed, and it can also
be further modeled in the domain diagrams.