Use Cases

I l @ ve RuBoard

Use cases model a dialogue between an actor and the system. They represent the functionality provided by the system; that is, what capabilities will be provided to an actor by the system. The collection of use cases for a system constitute all the defined ways the system may be used. The formal definition for a use case is: A use case is a sequence of transactions performed by a system that yields a measurable result of values for a particular actor.

The following questions may be used to help identify the use cases for a system:

• What are the tasks of each actor?

• Will any actor create, store, change, remove, or read information in the system?

• What use case will create, store, change, remove, or read this information?

• Will any actor need to inform the system about sudden, external changes?

• Does any actor need to be informed about certain occurrences in the system?

• What use cases will support and maintain the system?

• Can all functional requirements be performed by the use cases?

In the UML, a use case is represented as an oval, as shown in Figure 3-4.

Figure 3-4. UML Notation for a Use Case

What Constitutes a "Good" Use Case?

Over the years there has been a lot of discussion dealing with the "goodness" of a use case. One problem that I have encountered is the level of detail found in use cases. That is, how big (or how little) should they be? There is no one, right answer. The rule of thumb that I apply is the following:

A use case typically represents a major piece of functionality that is complete from beginning to end. A use case must deliver something of value to an actor.

For example, in the ESU Course Registration System, the student must select the courses for a semester, the student must be added to the course offerings, and the student must be billed. Is this three use cases, or just one? I would make it one because the functionality represents what happens from beginning to end. What good would the system be if a student was not added to the courses selected (or at least notified if the addition does not occur)? Or if the student was not billed (the University would not stay in business if all courses were free!)?

Another problem is how to bundle functionality that is different but seems to belong together. For example, the Registrar must add courses, delete courses, and modify courses. Three use cases or one use case? Here again, I would make one use casethe maintenance of the curriculum, since the functionality is started by the same actor (the Registrar) and deals with the same entities in the system (the curriculum).

Use Cases in the ESU Course Registration System

The following needs must be addressed by the system:

• The Student actor needs to use the system to register for courses.

• After the course selection process is completed, the Billing System must be supplied with billing information.

• The Professor actor needs to use the system to select the courses to teach for a semester, and must be able to receive a course roster from the system.

• The Registrar is responsible for the generation of the course catalog for a semester, and for the maintenance of all information about the curriculum, the students, and the professors needed by the system.

Based on these needs, the following use cases have been identified:

• Register for courses

• Select courses to teach

• Request course roster

• Maintain course information

• Maintain professor information

• Maintain student information

• Create course catalog

CREATING USE CASES IN RATIONAL ROSE

1. Right-click on the Use Case View in the browser to make the shortcut menu visible.

2. Select the New:Use Case menu option. A new unnamed use case is placed in the browser.

3. With the use case selected, enter the desired name of the use case.

The browser view of the use cases for the ESU Course Registration System is shown in Figure 3-5.

Figure 3-5. Use Cases

Brief Description of a Use Case

The brief description of a use case states the purpose of the use case in a few sentences, providing a high-level definition of the functionality provided by the use case. This description typically is created during the Inception Phase as the use case is identified.

The brief description of the Register for Courses use case is as follows :

This use case is started by the Student. It provides the capability to create, modify, and/or review a student schedule for a specified semester.

CREATING A USE CASE BRIEF DESCRIPTION IN RATIONAL ROSE

1. Click to select the use case in the browser.

2. Position the cursor in the documentation window and enter the brief description for the use case. If the documentation window is not visible, select the View:Documentation menu choice to make the window visible.

The brief description of the Register for Courses use case is shown in Figure 3-6.

Figure 3-6. Use Case Brief Description

The Flow of Events for a Use Case

Each use case also is documented with a flow of events. The flow of events for a use case is a description of the events needed to accomplish the required behavior of the use case. The flow of events is written in terms of what the system should do, not how the system does it. That is, it is written in the language of the domain, not in terms of implementation. The flow of events should include:

• When and how the use case starts and ends

• What interaction the use case has with the actors

• What data is needed by the use case

• The normal sequence of events for the use case

• The description of any alternate or exceptional flows

The flow of events documentation typically is created in the Elaboration Phase in an iterative manner. At first, only a brief description of the steps needed to carry out the normal flow of the use case (i.e., what functionality is provided by the use case) is written. As analysis progresses, the steps are fleshed out to add more detail. Finally, the exceptional flows are added to the use case (the what happens if . . . part of the flow of events).

The flow of events for a use case is contained in a document called the Use Case Specification. Each project should use a standard template for the creation of the Use Case Specification. I use the template from the Rational Unified Process.

1.0 Use Case Name

1.1 Brief Description

2.0 Flow of Events

2.1 Basic Flow

2.2 Alternate Flows

2.2.x < Alternate Flow x >

3.0 Special Requirements

3.x < Special Requirement x >

4.0 Preconditions

4.x < Precondition x >

5.0 Post Conditions

5.x < Postcondition x >

6.0 Extension Points

6.x < Extension Point x >

A sample completed Use Case Specification document for the Select Courses to Teach use case follows.

Use Case Specification for the Select Courses to Teach Use Case

1.0 Use Case Name

Select Courses to Teach.

1.1 Brief Description

This use case is started by the Professor. It provides the capability for the Professor to select up to four courses to teach for a selected semester.

2.0 Flow of Events

2.1 Basic Flow

This use case begins when the Professor logs onto the Registration System and enters his/her password. The system verifies that the password is valid (if the password is invalid, Alternate Flow 2.2.1 is executed) and prompts the Professor to select the current semester or a future semester (if an invalid semester is entered, Alternate Flow 2.2.2 is executed). The Professor enters the desired semester. The system prompts the Professor to select the desired activity: ADD, DELETE, REVIEW, PRINT, or QUIT.

If the activity selected is ADD, the system displays the course screen containing a field for a course name and number. The Professor enters the name and number of a course (if an invalid name/number combination is entered, Alternate Flow 2.2.3 is executed). The system displays the course offerings for the entered course (if the course name cannot be displayed, Alternate Flow 2.2.4 is executed). The Professor selects a course offering. The system links the Professor to the selected course offering (if the link cannot be created, Alternate Flow 2.2.5 is executed). The use case then begins again.

If the activity selected is DELETE, the system displays the course offering screen containing a field for a course offering name and number. The Professor enters the name and number of a course offering (if an invalid name/number combination is entered, Alternate Flow 2.2.3 is executed). The system removes the link to the Professor (if the link cannot be removed, Alternate Flow 2.2.6 is executed). The use case then begins again.

If the activity selected is REVIEW, the system retrieves (if the course information cannot be retrieved, Alternate Flow 2.2.7 is executed) and displays the following information for all course offerings for which the Professor is assigned: course name, course number, course offering number, days of the week, time, and location. When the Professor indicates that he or she is through reviewing, the use case begins again.

If the activity selected is PRINT, the system prints the Professor's schedule (if the schedule cannot be printed, Alternate Flow 2.2.8 is executed). The use case begins again.

If the activity selected is QUIT, the use case ends.

2.2 Alternate Flows

2.2.1 Invalid Password

An invalid password is entered. The user can re-enter a password or terminate the use case.

2.2.2 Invalid Semester: The system informs the user that the semester is invalid. The user can re-enter the semester or terminate the use case.

2.2.3 Invalid Course Name/Number: The system informs the user that the course name/number is invalid. The user can re-enter a valid name/number combination or terminate the use case.

2.2.4 Course Offerings Cannot Be Displayed: The user is informed that this option is not available at the current time. The use case begins again.

2.2.5 Cannot Create Link Between Professor and Course Offering: The information is saved and the system will create the link at a later time. The use case begins again.

2.2.6 Link Between Professor and Course Offering Cannot Be Removed: The information is saved and the system will remove the link at a later time. The use case begins again.

2.2.7 Schedule Information Cannot Be Retrieved: The user is informed that this option is not available at the current time. The use case begins again.

2.2.8 Schedule Cannot Be Printed: The user is informed that this option is not available at the current time. The use case begins again.

3.0 Special Requirements

There are no special requirements for this use case.

4.0 Preconditions

4.1 The Create Course Offerings subflow of the Maintain Course Information use case must execute before this use case begins.

5.0 Post Conditions

There are no post conditions.

Extension Points

There are no extension points.

Use Case Specification documents are entered and maintained in documents external to Rational Rose. The documents can be linked to the use case.

LINKING FLOW OF EVENTS DOCUMENTS TO USE CASES IN RATIONAL ROSE

1. Right-click on the use case in the browser to make the shortcut menu visible.

2. Select the Open Specification menu option.

3. Select the Files tab.

4. Right-click to make the shortcut menu visible.

5. Select the Insert File menu option.

6. Browse to the appropriate directory and select the desired file.

7. Click the Open button.

8. Click the OK button to close the specification.

Linked documents are also added to the Browser.

A linked use case flow of events document is shown in Figure 3-7.

Figure 3-7. Linked Flow of Events Document

A Use Case Specification document can also be created in Rational RequisitePro. These documents may also be linked to Rational Rose use cases. To link a RequisitePro document to a use case in Rational Rose you must first associate the Rational Rose model to a RequisitePro project.

ASSOCIATING A RATIONAL ROSE MODEL WITH A RATIONAL REQUISITEPRO PROJECT

1. Select the Tools: Rational RequisitePro: Associate Model to Project menu choice.

2. Click the Browse button and navigate to the directory containing the RequisitePro project.

3. Select the project and click the Open button.

4. Click the arrow in the Default Document Type field to make the drop-down menu visible.

5. Select Use Case Specification Document Type.

6. Click the arrow in the Default Requirement Type field to make the drop-down menu visible.

7. Select Use Case Requirement Type.

8. Click the OK button to close the Associate Model to RequisitePro Project window.

The Associate Model to RequisitePro Project window is shown in Figure 3-8.

LINKING RATIONAL REQUISITEPRO USE CASE SPECIFICATION DOCUMENTS TO USE CASES IN RATIONAL ROSE

1. Right-click on the use case in the browser to make the shortcut menu visible.

2. Select the Use Case Document: Associate menu choice.

3. Select the Use Case Specification document.

4. Click the OK button to close the Associate Document to Use Case 'Register for Courses' window.

Figure 3-8. Associate Model to RequisitePro Project window

I l @ ve RuBoard