Documenting Use Cases

4.1 Introduction

Each use case 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 behaviour of the use case. Activity diagrams may also be created at this stage in the life cycle. These diagrams represent the dynamics of the system. They are flow charts that are used to show the workflow of a system; that is, they show the flow of control from one activity to another in the system.

.

4.1 Flow of Events

A description of events required to accomplish the behaviour of the use case, that:

• Show WHAT the system should do, not HOW the system does it.

• Written in the language of the domain, not in terms of implementation.

• Written from an actor point of view.

A flow of events document is created for each use case:

• Actors are examined to determine how they interact with the system.

• Break down into the most atomic actions possible.

4.2 Contents of Flow of Events

• 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.

4.4 Week 4 of Case Study Milestones

Below are the milestones (specific goals) to aim for during the sixth week of the project. The intention is to tie in with coverage presented in lectures and tutorials.

Milestones	X
1. Study how to document use cases in detail.
2. Know about scenarios (flow of events) and its importance.
3. Develop Use Case descriptions for WAIPS System.

4.5 Suggestions

Template for the flow of events document

Each project should use a standard template for the creation of the flow of events document. The following template seems to be useful.

X Flow of events for the use case

X.1 Preconditions

X.2 Main flow

X.3 Sub-flows (if applicable)

X.4 Alternative flows where X is a number from 1 to the number of use cases.

A sample completed flow of events document for the Select Courses to Teach use case follows.

1. Flow of Events for the Select Courses to Teach Use Case

1.1 Preconditions

Create course offerings sub-flow of the maintain course information use case must execute before this use case begins.

1.2 Main 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 (E-1) and prompts the professor to select the current semester or a future semester (E-2). 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 S-1: add a course offering sub-flow is performed.

If the activity selected is DELETE, the S-2: delete a course offering sub-flow is performed.

If the activity selected is REVIEW, the S-3: review schedule sub-flow is performed.

If the activity selected is PRINT, the S-4: print a schedule sub-flow is performed.

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

1.3 Sub-flows

S-1: Add a Course Offering:

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 (E-3). The system displays the course offerings for the entered course (E-4). The professor selects a course offering. The system links the professor to the selected course offering (E-5). The use case then begins again.

S-2: Delete a Course Offering:

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 (E-6). The system removes the link to the professor (E-7). The use case then begins again.

S-3: Review a Schedule:

The system retrieves (E-8) 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.

S-4: Print a Schedule

The system prints the professor schedule (E-9). The use case begins again.

1.4 Alternative Flows

E-1: An invalid professor ID number is entered. The user can re-enter a professor ID number or terminate the use case.

E-2: An invalid semester is entered. The user can re-enter the semester or terminate the use case.

E-3: An invalid course name/number is entered. The user can re-enter a valid name/number combination or terminate the use case.

E-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.

E-5: A link between the professor and the course offering cannot be created. The information is saved and the system will create the link at a later time. The use case continues.

E-6: An invalid course offering name/number is entered. The user can re-enter a valid course offering name/number combination or terminate the use case.

E-7: A link between the professor and the course offering cannot be removed. The information is saved and the system will remove the link at a later time. The use case continues.

E-8: The system cannot retrieve schedule information. The use case then begins again.

E-9: The schedule cannot be printed. The user is informed that this option is not available at the current time. The use case begins again.

Use case flow of events documents are entered and maintained in documents external to Sybase Power Designer. The documents are linked to the use case.