|
|
|
UCDs allow you to capture business events by analyzing how objects external to the system interact with the system. A UCD represents a particular sequence of transactions between the system and an actor (an end user or system external to the system being analyzed). You can use UCDs to analyze system requirements and to help you define system boundaries.
This UCD models a banking system. Customer, Auditor, Clerk and Loan Officer are actors. Counter Transaction, Loan Application, and Audit are use cases -- ways in which the actors use the system.
Additional UCDs may be used to further refine this UCD. For example, you may have a UCD that describes the Loan Application use case in greater detail. You may also have a few sequence diagrams that describe the Counter Transaction use case in the form of a number of scenarios: one for a successful transaction and one or more for transactions that are not successful.
The analyst must choose the appropriate level of detail. You need enough detail to fully capture the business events and system requirement, but, you want to avoid using UCDs for functional decomposition.
The control panel for the UCD.
The stick figure represents an entity external to the system -- an end user or system -- that is interacting with the system.
A use case (an oval) represents the system or part of the system with which an actor communicates. If necessary, a use case can be further refined in another UCD.
A use case generalization (an unfilled arrow) indicates that the source use case includes the behavior of the destination use case. This can be stereotyped with <<uses>> or <<extends>>.
Use communication associations to represent the communication between the actor and the use case. To represent undirected (two-way) communication, use a line that has no arrowhead. To represent directed (one-way) communication, use an arrow; the arrow shows the direction of communication.
