The Use Case technique captures information about how a system or business currently works or should work. Although not a true object-oriented approach, the Use Case technique helps you build scenarios which model the processes of the system. It is an excellent way to lead into object-oriented analysis of systems.
A Use Case for every scenario
Typically, Use Case diagrams are modeled for every scenario in the system or business. Each Use Case can be defined simply with text describing the scenario. You may also define the scenario with the sequence of steps performed within it or with the conditions that exist before the scenario begins or after it completes.
Actors as external agents
An actor is considered an external agent to a system: someone or something that requests a service from the system or acts as a catalyst for something in the system to occur. UML specifies that the actor is a class of objects, not a particular instance of a class (or object). The actor is represented as a class with a stereotype of actor.
Organization of Use Case diagrams
During business analysis of the system, you can develop one Use Case diagram that acts as the system Use Case, and draw packages on this Use Case to represent the various business domains of the system. For each package, you may create a child Use Case diagram. On each child Use Case diagram, you can draw all of the Use Cases of the domain, with actor interactions, and use the System symbol to further refine the categorization of the Use Cases. The extends and uses relationships can be used to eliminate redundant modeling of scenarios.
When to stop decomposing Use Case diagrams
When you have arrived at the lowest Use Case level, you can create a Child Sequence diagram (and accompanying Collaboration diagram) for the Use Case. With these Sequence and Collaboration diagrams, you can model the implementation of the scenario.
