In this lesson you learned about use cases. A use case diagram shows which actors interact with each use case. In more detail, the basic elements of a use case diagram are:
- Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.
- Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures.
- Associations. Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicate the direction of the initial invocation of the relationship or to indicate the primary actor within the use case. The arrowheads are typically confused with data flow and as a result I avoid their use.
- System boundary boxes (optional). You can draw a rectangle around the use cases, called the system boundary box, to indicate the scope of your system. Anything within the box represents functionality that is in scope, while anything outside the box represents functionality that is not in scope. System boundary boxes are rarely used, although on occasion I have used them to identify which use cases will be delivered in each major release of a system.
If you were analyzing a sentence in English, the subject in the sentence could be identified as a potential actor and the verb part of the sentence could be a potential use case. Remember, this may or may not apply to the problem at hand, but is a good starting point for use case modeling.
This lesson is a bridge from the discussion of general techniques of systems analysis to modeling a system. It was an extremely important lesson because of the growing application of use case modeling. The next lesson will be much faster in pace and focus on the skill of data and object modeling. The next lesson will also address feasibility analysis of alternative systems solutions.