This chapter focuses on use-case diagrams, which depict the functionality of a system. First, I introduce use-case diagrams and how they are used. Next, I discuss actors and use cases. Finally, I go over various relationships relating to actors and use cases. Many details that were not fleshed out in Chapter 2 are more fully elaborated here, and throughout the chapter I include suggestions relating to use-case diagrams.
Use-case modeling is a specialized type of structural modeling concerned with modeling the functionality of a system. You usually apply use-case modeling during requirements activities to capture requirements that define what a system should do. Use-case modeling typically starts early in a project and continues throughout a system development process. It is usually done as a series of workshops between users and analysts of a system in which ideas can be explored and requirements may be fleshed out over time.
As a use-case driven process uses use cases to plan and perform iterations, it is important to understand how use cases are related to one another, including what use cases have in common, which use cases are options of other use cases, and which use cases are similar to each other. Given that every project has limited resources, you can use this information about use cases to determine how best to execute a project. Use cases that are common to two or more other use cases need only be implemented once, and then they can be reused. Use cases that are options of other use cases may be implemented at a later time, and use cases that are similar allow us to implement one use case that may be reused. An understanding of how use cases are related allows users and analysts to negotiate and reach agreement concerning the scope and requirements of a system.
A use-case diagram may be considered a "table of contents" for the functional requirements of a system. The details behind each element on the use case diagram may be captured in textual form or using other UML modeling techniques. All the use-case diagrams and their associated details for a specific system form the functional requirements of the system. However, the UML does not provide any explicit guidance on how to capture the textual details, but focuses more on the notation.