UML is fundamentally based on an object-oriented analysis technique known as use case modeling, which was introduced in Chapter “Understanding and Modeling Organizational Systems“. A use case model shows a view of the system from the user perspective, thus describing what a system does without describing how the system does it. UML can be used to analyze the use case model, and to derive system objects and their interactions with each other and with the users of the system. Using UML techniques, you further analyze the objects and their interactions to derive object behavior, attributes, and relationships.
A use case provides developers with a view of what the users want. It is free of technical or implementation details. We can think of a use case as a sequence of transactions in a system. The use case model is based on the interactions and relationships of individual use cases.
A use case always describes three things: an actor that initiates an event; the event that triggers a use case; and the use case that performs the actions triggered by the event. In a use case, an actor using the system initiates an event that begins a related series of interactions in the system. Use cases are used to document a single transaction or event. An event is an input to the system that happens at a specific time and place and causes the system to do something. For more information about use case symbols and how to draw use case diagrams, see Chapter 2.
Figure shown below is a use case example of student enrollment at a university. Notice that only the most important functions are represented. The Add Student use case does not indicate how to add students, the method of implementation. Students could be added in person, using the Web, using a touch-tone telephone, or any combination of these methods. The Add Student use case includes the Verify Identity use case to verify the identity of the student. The Purchase Textbook use case extends the Enroll in Class use case, and may be part of a system to enroll students in an online course.
It may seem as if the Change Student Information use case is a minor system feature and should not be included on the use case diagram, but because this information changes frequently, administration has a keen interest in allowing students to change their own personal information. The fact that the administrators deem this to be important not only justifies, but calls for, the use case to be written up.
Students would not be allowed to change grade point average, outstanding fees, and other information. This use case also includes the Verify Identity use case, and in this situation, it means having the student enter a user ID and password before gaining access to the system. View Student Information allows students to view their personal information, as well as courses and grades. A use case scenario example is shown in the figure below.
Some of the areas included are optional, and may not be used by all organizations. The three main areas are:
- A header area containing case identifiers and initiators.
- Steps performed.
- A footer area containing preconditions, assumptions, questions, and other information.
In the first area the use case is identified by its name, Change Student Information; the actor is identified as a Student; and the Use Case and Triggering Event are described. The second area contains a series of steps that are performed as long as no errors are encountered. Finally, in the third area, all of the pre- and postconditions and assumptions are identified. Some of these are obvious, such as the precondition that the student is on the correct Web page and the assumption that the student has a valid student ID and password. Others are not so obvious, such as the outstanding issue regarding how many times the student is allowed to log on to the system.
Use case diagrams provide the basis for creating other types of diagrams, such as class diagrams and activity diagrams. Use case scenarios are helpful in drawing sequence diagrams. Both use case diagrams and use case scenarios are powerful tools to help us understand how a system works in general.
