- State Chart Diagrams
- Activity Diagrams
- Use Case Diagrams
- Component and Deployment Diagrams
- Packages
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Use Case Diagrams
Use case diagrams are used to note the types of user of a system and what each type of user does with that system. For some obscure reason, each type of user is called an actor in UML. Each sequence of interactions that an actor makes with the system for some distinct purpose is called a use case. Although officially an actor may be person or another computer system, the UML symbol is a stick figure. Use cases are shown as ellipses, and may be grouped inside a system boundary that represents which system is responsible for implementing those use cases.
Figure 3 shows a basic use case diagram for our Point of Sales system. Actors are linked by solid lines to use cases with optional open arrowheads, showing whether the actor initiates the interaction or the use case does. Some actors may be special versions of another actor, and this relationship can be shown using the same generalization relationship used on class diagrams, a solid line with a closed solid arrowhead from the specialized actor to the more general actor.
)
Figure 3 Use case diagram.
Some use cases may include or extend other use cases. These relationships may be shown using the stereotyped dependency relationship identical to that used on class diagrams, a dashed line with an open arrowhead drawn to the included or extending use case.
Use Case Diagrams and Source Code
Unlike class and interaction diagrams, use case diagrams have no direct relationship to Java source code. However, actors often end up being represented in a system by classes of the Role class archetype introduced in the third article in this series. Some software development methods suggest creating a class for each use case. In these approaches care must be taken to avoid these classes becoming function blobs (classes with lots of methods and very few attributes) that act on data blobs (classes with lots of attributes but very few significant methods).
Using Use Case Diagrams
Use case diagrams are often complemented by textual descriptions of each use case. As with all tools, use cases can be very helpful when used well, and they can cause more problems than they solve when used badly. Great debate continues to surround the proper application of use cases, granularity, level of detail, format of the textual description, and so on. Again, as with all tools of this nature, it is important to ensure that use cases are earning their keep—that the benefits derived by the team outweigh the cost of producing and maintaining them.