FIGURE 1. View All Grades Activity Diagram

What we are not taking into account yet has been that a decision has actually been made in the course of the activity. When Carol selects "view all grades", she has made a decision. We should reflect that decision in our activity diagram, replacing the activity with a decision. Don't forget the merge node. The decision is a true or false question. Our outcome can only be a true or a false path. We may think it is better to write "Select View Al Grades?" with a question mark. It is reasonable to write it this way though by convention, we don't use a question mark.

FIGURE 2. View All Grades Activity Diagram with Decision

The second scenario for Carol is F1:

F1. View All Scores and Averages (all assignments, one class, one student)
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.

This scenario would produce an activity diagram similar to the "View All Grades" activity diagram. The decision node will say we are selecting the "View All Grades" menu option. We will not use a decision for selecting a class, as we will not do anything different (i.e. change our program flow) based on the class selected.

Also, while our scenario is very detailed in which actor does what action, we can combine activities such as prompting with the list of classes and selecting a class. We will merge those two into one node. Merging steps together into one action will still allow people to understand the transition but allows us to simplify our diagram. We could also split a step into more than one action if it will make our design more understandable. You should not make large changes and especially not reorder steps. That makes it very difficult to understand the relationship between the use cases and the activity diagram.

FIGURE 3. View All Scores and Averages Activity Diagram

As we continue with our bottom-up approach, we will do the same for the rest of the scenarios. They are presented here in alphabetical order as it does not matter what order we create the activity diagrams.

G2. Admin View All Grades (all classes, one student)
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.

FIGURE 4. Admin View All Grades

As we continue on, we will create an activity diagram for each use case. Later on we will combine the activity diagrams together. I should point out that you can make activity diagrams without use cases. It is in the software design method presented here that we first do use casess then activity diagrams.

I1. Assign Scores (all students, one class, one assignment)
1. Actor will sign on and receive menu
2. Actor selects assign scores.
3. System prompts with a list of courses.
4. Actor selects course
5. System prompts for score description.
6. Actor enters in score description.
7. System provides a chart of student names and score entries.
8. Actor enters scores for each student and presses OK to commit scores.
9. System presents entered scores.

FIGURE 5. Assign Scores

We merged steps five and six, as well as steps seven and eight. They were very closely related and it did not help the understanding of our system to have them separate. We could merge everything into one action, but then we would be taking unrelated actions and merging them unncessarily so we don't.

J1. Change Score (one student, one class, one assignment)
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.

FIGURE 6. Change Score

We elaborated step ten into a series of two statements. Step ten was actually two actions in the end. We could go back and re-write the use case to be more eplicit. If we made a sustantial change we should change our use case. Here we only split a compound statement. In preparation of this book I have gone back a few times to fix the use cases. As an actual exercise, don't hesitatate to go back and fix a previous step if you forget something. I am not making you go back now only because it can be confusing. Just know that you can and you should.

K1. View Class Scores (all students, one class, all assignments)
1. Actor will sign on and receive menu
2. Actor selects view class scores.
3. System prompts the actor to select course.
4. System displays scores.

FIGURE 7. View Class Scores

This may look similar to figure 7. We may wonder if there is a way to abstract F1 and K1 into one activity diagram. There is, using sub-activity diagrams. But before you do that "optimization" on F1 and K1, ask yourself if you are providing additional clarity to the problem. Remember we are not yet at the point where we are going to implement the system but instead providing a blackbox design. More importantly, will it make sense to our client? If we abstract the two and make the action action based on a parameter, will the client understand it. In this case while we can pat ourselves on the back for recognizing a similar pattern, it is best not to optimize it.

M1. Assign Grades (all students, one class)
1. Actor will sign on and receive menu
2. Actor selects assign grades.
3. System prompts with a list of courses.
4. Actor selects course.
5. System provides a chart of student names and grade entries.
6. Actor enters grades for each student and presses OK to commit grades.
7. System presents entered grades.

FIGURE 8. Assign Grades

Since we called the other "presses OK to commit grade" a verification, we have to do the same thing here. The reason I called it "verification" rather than "presses OK" in the activity diagram is that "presses OK" defines how it will work, but we aren't there yet. Why use "presses OK" in the use case then? It removes ambuguity as to the meaning of verification. This is subtle. If the use case used verification, the client would ask to define it. Here we can use it because we have estabilished the scope of how the system will operate. It also makes everything at the same level. After selects course, we didn't say "hits enter", but that is what might happen.

N1. Change Grade (one student, one class)
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.

FIGURE 9. Change Grade

FIGURE 10.