Software Design Specifications with UML

Use Cases : Goals

Once we have identified the actors in our system, we have to identify the goals that each of them have. A goal is an end result that an actor wishes to accomplish. I usually ask people to think of an actor starting off by sitting down in front of our system and then to identify what he or she (or even it) wants to accomplish.

Let's start with Carol. As a student, she would want to check the scores she has received in a particular class. Along the way she may have to log into the system. She may even be able to see the class average along the way. We are not concerned with all the other things that Carol is able to do along the way as she checks her scores or one particular class. We want to identify the things that Carol would like to accomplish using the system we are developing. Once the actor has achieved his or her goal, the actor may wish to get up and walk away.

We have already identified that Carol would want to check her scores in one class. The question becomes: Does she check the scores from one class or will she be able to get the scores from all classes at the same time? Will she be presented with one screen that shows everything that Carol has done in all of her current courses? Will the class average for each assignment be automatically available to her or will she explicitly request it?

The tricky part of identifying the goals is that along the way we are starting to flesh out the scenarios as well. A scenario is the steps needed to accomplish a goal. While the two can be done simultaneously, I prefer to keep the seperate. It allows us to look at the list of goals for all the actors together.

Back to Carol. While we can implement things in many ways, we will opt for the simple approach where we are not given just one screen with all information. That does not mean we will not combine multiple results on the same screen. Some of the goals will have the exact same steps to get to the goal.

Carol has a few goals she would like to accomplish with our system. Carol is taking CompEng 1600, Architecture with Joan.
Carol wants to see all her scores from one class, CE1600.
Carol wants to see the class average score from the scores in one class, CE1600, along with her own scores.
Carol wants to see the class average score from one assignment, HW4, in one class, CE1600, along with her own score.
Carol wants to see her grade from one class, CE1600.
Carol wants to see her grades from all her classes, CE1600, CE1630, and CE1900.

The goal of seeing her scores is contained within the goal of seeing her scores in relationship to the class averages. That is fine. A goal is something that you set out to do when you start and one where you leave once you have accomplished it.

Sometimes I will explain a little more of the rationale for each goal. The difference between looking at one score along with the average and all the scores along with all the averages is based on what she wants to accomplish that is outside of the system. You can phrase it as:
Carol wants to see the class average score from the scores in one class, CE1600, along with her own scores (because she wants to see how well she is doing to be able to determine what grade she is going to get).
Carol wants to see the class average score from one assignment, HW4, in one class, CE1600, along with her own score (because she wants to see how well she did on the assignment she just completed).

Similar goals are best explained by identify the goal that is beyond the system. It is often very helpful to not just identify what they want to accomplish but also why they want to accomplish it.

We can identify the goals for a student graphically in a use case diagram:

FIGURE 1. Carol's Goals

What does Joan, our teaching assistant, need to accomplish? Her goals would include:
Joan wants to assign scores for all students in one class for one assignment (because she just finished grading the assignment).
Joan wants to change a score for one student in one class for one assignment (because the score was totaled incorrectly).
Joan wants to see the scores for all students in one class for one assignment (because she wants to double check to make sure she entered the scores correctly).
Joan wants to see all the scores for all the students in one class (because she wants to know how well the class is doing).

What does Aaron, our instructor, need to accomplish? His goals are very similar to Joan's goals. His goals include:
Aaron wants to assign scores for all students in one class for one assignment (because he just finished grading the assignment).
Aaron wants to change a score for one student in one class for one assignment (because the score was totaled incorrectly).
Aaron wants to see the scores for all students in one class for one assignment (because he wants to double check to make sure he entered the scores correctly).
Aaron wants to see all the scores for all the students in one class (because she wants to know how well the class is doing).
Aaron wants to assign grades to all the students in one class.
Aaron wants to change a grade for one student in one class.

As we can see from Joan and Aaron knowing how grading happens they will enter scores in for all students at one time, but will want to change scores or grades on an individual basis.

Since Joan and Aaron have similar goals, we can identify them graphically and show that they have similar goals in our use case diagram. We can start to see that there are many activities that can be reused from one actor for another.

FIGURE 2. Joan's and Aaron's Goals

Kathy, our administrator, is tricky. What is it that she wants to do with our system? If she is the person who can help everyone when they run into trouble then she really has to be able to do everything that everyone else can do.

To help a student, Kathy should be able to do the following:

Kathy wants to see all scores from one class, CE1600, for one student, Carol.
Kathy wants to see the class average score from the scores in one class, CE1600, along with the student's own scores, for one student, Carol.
Kathy wants to see the class average score from one assignment, HW4, in one class, CE1600, along with the student's own score for one student, Carol.
Kathy wants to see the student's grade from one class, CE1600, for one student, Carol.
Kathy wants to see one student's grades from all the student's classes, CE1600, CE1630, and CE1900, for one student, Carol.

Yes, this is a lot to write. Either put in the effort now or do ten times the effort later when you have forgotten something. Kathy should be able to help a teaching assistant as well as an instructor. We already pointed out that the goals of a teaching assistant is a complete subset of the goals of an instructor. We can eliminate explaining why as the reasons would be to help. Kathy's goals related to helping a teaching assistant or instructor are:
Kathy wants to assign scores for all students in one class for one assignment.
Kathy wants to change a score for one student in one class for one assignment.
Kathy wants to see the scores for all students in one class for one assignment.
Kathy wants to see all the scores for all the students in one class.
Kathy wants to assign grades to all the students in one class.
Kathy wants to change a grade for one student in one class.

Since Kathy has goals similar to Joan, Aaron, and Carol we represent them all together. It can be quite messy.

FIGURE 3. Combined Goals of Joan, Aaron, Kathy, and Carol

While the concept of viewing scores is duplicated, we can see that the actual goals of the student vs. the instructor and teaching assistant actors are very different.

Our last actor, our non-human actor, is the registration system. We have identified it as an actor as it participates in our system, but does it have any goal? Certainly making sure that we have the most up to date class list is something that the registration system may want to maintain, but does the registration system play an active part in maintaining the class list within our gradebook system? The registration system is more of a passive participant. It is the place where we will extract class lists and student information, but we are responsible for maintaining that information and not the registration system itself. The registration system does not use us to accomplish a goal so then it does not have any goals to be listed. On the other hand, if we were to discuss the registration system then certainly our gradebook program would be included as an actor that uses the registration system to accomplish a goal.

We could leave the registration system actor in our use case diagram as something to be shown as an actor in the system, though many will argue that if it has no goals then there is no benefit to showing it in the use case diagram. I agree. We will see the registration system coming up again when we discuss the deployment diagram. Until then we will not include the registration system.