Software Design Specifications with UML

Use Cases : Scenarios

After identifying the goals of the system we begin to go into great detail developing the scenarios that identify how an actor will achieve the goal. For each goal, we will outline the steps.

We have identified 11 goals. It is important to cover every goal you have in your system. It is in these details that we start to understand how the overall system will operate which will help us understand any more questions we should ask of our client. When developing the scenarios, there is one other implied actor that we can use: System. The system is what we are developing. It is the thing that responds to the actors as they proceed through their scenarios.

We can start with the student Carol's goals. Every statement should start with the identification of the actor that is doing the action. Every statement should be numbered.

You may want to skip outlining all the steps in the scenario, but it helps to identify the details. For instance the idea that the system knows who each person is and what he/she is capable of doing in the system was not articulated. You may have had the notion of logging in to the system around but did not yet have an opportunity to write it down. If you are going to hand off your design to others to work on, they are going to have to know all the details.

Here is the use case text (scenario) for one of Carol's goals:

A1. View All Grades (all classes, one student)

Main Success Scenario:
1. System displays login prompt.
2. Student logs into gradebook program.
3. System presents menu of options.
4. Student selects view all grades.
5. System displays all grades.

We start out with the most positive approach to accomplishing the goal. It is only after the positive approach has been presented that we look at it for alternative approaches to achieve the goal. A simple alternative is that the student incorrectly typed his/her login information.

Extensions:
3a. System has been given incorrect login information.
3a1. System redisplays login prompt.
3a2. Student relogs into gradebook program.

The first line (3a) of the extension identifies the extension itself. The lines following it are the alternative steps to be taken based on the extension.

We could really outline a lot of alternatives in our extensions section. The level of detail is kept high so as to allow a client to review the scenario and be able to make an assessment. Remember this is an outside view of how the system will behave so try to avoid steps that are not visible to the outside world. For instance, we may use some other machine to be an authentication server for our login information. After step 2, the system may contact the server but from outside our system the user has no idea how the login information is validated. The use case should not go into the details of how things are done and only stick to what things are done.

Along those same lines we avoid error handling unless it is a significant activity to mention. It is possible that the grades have not been assigned. The student may not be taking any courses that are making use of the gradebook program. The database that holds all the information may be offline and the gradebook program cannot proceed. We do not present exception handling when presenting a use case scenario as an exception is typically part of the insides of the system.

Here is another use case text (scenario) for one of Carol's goals:

B1. View Grade (one class, one student)

Main Success Scenario:
1. System displays login prompt.
2. Student logs into gradebook program.
3. System presents menu of options.
4. Student selects view grade.
5. System prompts with a list of courses.
6. Student selects course.
7. System displays grade.

Extensions:
3a. System has been given incorrect login information.
3a1. System redisplays login prompt.
3a2. Student relogs into gradebook program.

A use case cannot provide all information. It is a helpful method to describe how the user will use the system. But there are a lot of assumptions that creep in. In the previous use case I outlined "System presents menu of options". I don't say what a menu is. The danger is that what you think of as a menu may not be what someone else thinks of as a menu. Some restaurants put everything on one big page and others break up items into categories such as entrees and desserts. Do not assume that because you identified a menu that you and your client agree on what that means.

As we begin to work on the next goal, we notice that the first few steps including the extensions are all the same. As they are all identical (not just close but identical) steps they can be put into a sub-goal of their own:

C1. Sign On and Receive Menu

Main Success Scenario:
1. System displays login prompt.
2. Student logs into gradebook program.
3. System presents menu of options.

Extensions:
3a. System has been given incorrect login information.
3a1. System redisplays login prompt.
3a2. Student relogs into gradebook program.

We can use this sub-goal as a part of our scenario, identifying the subgoal by underlining it:

D1. View Score (one assignment, one class, one student)

Main Success Scenario:
1. Student will sign on and receive menu
2. Student will select view score.
3. System will prompt with list of classes.
4. Student will select class.
5. System will display all scores, averages, and a grade for the class.

E1. View Score and Average (one assignment, one class, one student)

F1. View All Scores and Averages (all assignments, one class, one student)

In the system I am building, when the student asks to view scores, he/she will get all the scores for the class as well as the average for each assignment. There may be several goals, but only one scenario. We can change D and E to be:

D2. View Score (one assignment, one class, one student)

Main Success Scenario:
1. Student will view all scores and averages

E2. View Score and Average (one assignment, one class, one student)

Main Success Scenario:
1. Student will view all scores and averages

In our use case diagram, we can modify it to show that our goals will include other sub-goals. Your client may not like the approach that all information is presented upon requesting to view any of the scores or averages. By showing it as sub-goals you can show how they are all taking the same steps.

FIGURE 1. Sub-goals as Includes

If we look at our use case diagram we can see that Kathy, our administrator, shares the same goals as Carol, our student. If we re-write the A goal using our defined sub-goals, the scenario for a student would be:

A2. View All Grades (all classes, one student)

Main Success Scenario:
1. Student will sign on and receive menu
2. Student selects view all grades.
3. System displays all grades.

If an adminstrator shared the same scenario as the student, the goal would look like this:

G1. Admin View All Grades (all classes, one student)

Main Success Scenario:
1. Administrator will sign on and receive menu
2. Administrator selects view all grades.
3. System displays all grades.

This will not work as when the student logs in we know which student to use to select the classes and grades. When the administrator logs in, we are not able to implicitly know that information. Instead we will have to prompt the administrator for which student to use:

G2. Admin View All Grades (all classes, one student)

Main Success Scenario:
1. Administrator will sign on and receive menu
2. Administrator selects view all grades.
3. System prompts the administrator to select student.
4. Administrator selects student.
5. System displays all grades.

The result of this change is that the student and the administrator while sharing the same goal do not share the same approach to achieving that same goal. We will have to seperate their goals in the use case diagram to reflect this. Any good programmer will object to this saying that we can always pass in a parameter to a subprogram that will specify which student to use. That's an internal thing that describes how the system is implemented that doesn't fit because we're describing the external use of the system.

We can re-use C for our other actors if we change it slightly:

C2. Sign On and Receive Menu

Main Success Scenario:
1. System displays login prompt.
2. Actor logs into gradebook program.
3. System presents menu of options.

Extensions:
3a. System has been given incorrect login information.
3a1. System redisplays login prompt.
3a2. Actor relogs into gradebook program.

The student (Carol's) B goal would be changed since we did not change it yet to reflect the sub-goal we have in C.

B2. View Grade (one class, one student)

Main Success Scenario:
1. Student will sign on and receive menu
2. Student selects view grade.
3. System prompts with a list of courses.
4. Student selects course.
5. System displays grade.

The administrator (Kathy's) similar goal could be:

H1. Admin View Grade (one class, one student)

Main Success Scenario:
1. Administrator will sign on and receive menu
2. Administrator selects view grade.
3. System prompts the administrator to select student.
4. Administrator selects student.
5. System prompts with a list of courses.
6. Student selects course.
7. System displays grade.

If D, E, and F are all the same thing since we are presenting information and there really isn't a reason to seperate the results, maybe we want to do the same thing for the viewing of grades as well.

The student's B goal of viewing grades for one class would be the same as the student's D (remember our sub-goal is C) goal of viewing grades from all courses. The administrator's H goal of viewing grades for a student's one class would be the same as the administrator's G goal of viewing grades for all of a student's classes.

B3. View Grade (one class, one student)

Main Success Scenario:
1. Student will view all grades.

H2. Admin View Grade (one class, one student)

Main Success Scenario:
1. Administrator will do admin view all grades.

Many of you may believe that you could have come up with the same result by just thinking rationally about how the system would operate. What you would lack is a way to negotiate with your client. You would not be able to say why you decided to design the system the way you did it. What most people object to is the amount of work involved. What they mostly mean is that there is too much writing and it takes too long before you can get into the development, which is what most people see as the meat of the project. These activities done early on in the process will save you a lot of time later on.

I saved the instructor and teaching assistant goals for last because they are easier now that we have done the student goals and the administrator goals that were similar to the student goals. We will use the term Actor instead of Instructor, Teaching Assistant, or Administrator as any one of them can be used in the scenario.

I1. Assign Scores (all students, one class, one assignment)

Main Success Scenario:
1. Actor will sign on and receive menu
2. Actor selects assign scores.
5. System prompts with a list of courses.
6. Actor selects course
7. System prompts for score description.
8. Actor enters in score description.
9. System provides a chart of student names and score entries.
10. Actor enters scores for each student and presses OK to commit scores.
11. System presents entered scores.

J1. Change Score (one student, one class, one assignment)

Main Success Scenario:
1. Actor will sign on and receive menu
2. Actor selects change score.
3. System prompts the actor to select course.
4. Actor selects course.
5. System prompts with a list of students.
6. Actor selects student.
7. System prompts with a list of assignments.
8. Actor selects assignment.
9. System displays old score and prompts for new score.
10. Actor enters new score and presses OK to commit score.

K1. View Class Scores (all students, one class, all assignments)

Main Success Scenario:
1. Actor will sign on and receive menu
2. Actor selects view class scores.
3. System prompts the actor to select course.
7. System displays scores.

L1. View Assignment Scores (all students, one class, one assignment)

Main Success Scenario:
1. Actor will view class scores.

In the following two goals, only an instructor or an administrator can be used in place of the Actor. We are able to know this by looking at the use case diagram.

M1. Assign Grades (all students, one class)

Main Success Scenario:
1. Actor will sign on and receive menu
2. Actor selects assign grades.
5. System prompts with a list of courses.
6. Actor selects course.
7. System provides a chart of student names and grade entries.
8. Actor enters grades for each student and presses OK to commit grades.
9. System presents entered grades.

N1. Change Grade (one student, one class)

Main Success Scenario:
1. Actor will sign on and receive menu
2. Actor selects change grade.
3. System prompts the actor to select course.
4. Actor selects course.
5. System prompts with a list of students.
6. Actor selects student.
7. System displays old grade and prompts for new grade.
8. Actor enters new grade and presses OK to commit grade.

We now have the following scenarios outlined:

The subgoal shared by all scenarios is C2.
The student scenarios are A2, B3, D2, E2, and F1.
The teaching assistant scenarios are I1, J1, K1, and L1.
The instructor scenarios are I1, J1, K1, L1, M1, and N1.
The administrator scenarios are G2, H2, I1, J1, K1, L1, M1, and N1.

Since we had to split the goals of the student from the administrator, we will have to update our use case diagram to reflect this. We are also including many sub-goals within our goals. The use case diagram needs to be updated to reflect this as well.

Use cases can be used to model business activities. What has been presented here is a system level use case suitable for designing a software system.