|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:
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:
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:
Based on these needs, the following use cases have been identified:
CREATING USE CASES IN RATIONAL ROSE
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 :
CREATING A USE CASE BRIEF DESCRIPTION IN RATIONAL ROSE
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:
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.
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.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.
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
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
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
Figure 3-8. Associate Model to RequisitePro Project window
|I l @ ve RuBoard|