Examples of use case initiation:
This use case begins when the console operator selects to review the program log.
This use case begins at 4:00 am daily.
This use case begins when the scheduling system requests the nightly reconciliation process to begin.
This use case begins when it is time to check for the presence of rain.
Using activity diagrams
If the flow of events in a use case is complex, and especially if there are numerous or complex alternative flows of events, it might be helpful to draw an activity diagram to illustrate the entire flow of events. Activity diagrams have the advantage of being able to show all alternate flows in one view, but have the disadvantage of obscuring the main flow. Swimlanes can also be added to these diagrams to show the responsibilities of the actors and the system.
We do not use activity diagrams in place of sequence diagrams in the MDSD flowdown process. We have found that sequence diagrams have clearer semantics for operations analysis, and that it is easier to extract traceability information from the models using sequence diagrams.5 For now, it should just be clear that activity diagrams are used in MDSD as an optional view, to help illustrate complex use case flows of events. We have seen many situations where they were not used at all, with no ill affects, and others where they were used only for complex use cases.
Understanding collaboration from a black-box perspective
If we have completed our work through the previous MDSD step, what we have now is a complete set of use cases. The next step is to answer the question, What operations must the entity be capable of, in order to make possible all of the usages described in these use cases? To answer this question, we perform operation identification.
5Swimlanes and call operation actions in activity diagrams provide an alternative for those who are more comfortable using activity diagrams. We do not treat this option in this document.
