Software Design Specifications with UML
Michael W. Bigrigg, Copyright
2004-2007
UML: Introduction
Use Cases: Actors |
Goals | Scenarios
Activity Diagrams: Overview |
Part 1 | Part
2
State Charts: Overview |
Part 1 | Part 2
Deployment Diagrams: Components |
Nodes | Communication
State Charts Part 1
Michael W. Bigrigg, Copyright
2004-2007
In our bottom-up approach, we are going to start with the activity diagram at the lowest level of it and work our way up. In particular, what we are going to do is to look at the activity diagrams that were created in the previous chapter, and identify the states associated with them. It is possible to do this starting with the use cases, but it becomes much harder.
We will start with the high level activity diagram. Since not all the lowest activities are identified there (the "instructor" is not an actual activity but a representation for a bunch of other activities), we will recursively look into subactivity diagrams and the sub-sub-sub-activity diagrams until we make it to the bottom to the actual activities.
The only activity identified in the high level activity diagram is the login activity.
FIGURE 1. High Level Activity Diagram
We will put the Sign On to our list of states, which we represent as our login screen.
FIGURE 2. Student Subactivity Diagram
The student subactivity diagram shows three potential states. This may seem simple, just look at the lowest level activities and make it a state. The first activity is: "Prompts with List of Classes. Select Class." Is that two states or one? If we overly simplify a state to be anywhere the computer will sit and wait for us to respond, then that is one state. Actually the prompt is more like a state and the act of Carol selecting a class is the transition. The "Prompts with List of Classes" goes on our list of states.
FIGURE 3. Course Selection Screen
What about the displays? What happens when the computer displays the scores and averages to Carol? It puts the information on the screen, but then it sits and waits. The waiting is what makes it a state. And if the act of selecting a class is a transition, what is our transition after having information displayed on the screen? The computer does not only display the information, but will also provide a button (typically with the word "OK" on it) for us to acknowledge the information. It is the act of pressing the OK button that moves us from the state of looking at the information that is displayed on the screen.
FIGURE 5. Displays All Grades Screen
As you can see, sometimes we will have a transition identified in the activity so we cannot just use whatever text is in the activity box.
The approach we are taking here is to recursively go down into each subactivity diagram until we hit the actual activities and identify the states associated with each activity. If you remember recursion, you can either do something with the parent either before or after you recurse. For our method here, we are going to do something with the parent after we recurse.
In particular, we will also look at the decision nodes. They are also candidates for being states. In the student subactivity diagram, notice that we have to select which of the paths we want to take. Basically, we would be prompted with a choice of paths, and the computer would sit and wait until we have made our selection and then proceed.
At the end of last chapter we discussed the different options for providing separate paths for students, teaching assistants, instructors, and administrators. Our system will present each type of actor his or her own specialized menu that represents all of the options available to him or her.
FIGURE 6. Student Menu Screen
The merge node does not make for a good state as it is mostly for readability in the activity diagram.
FIGURE 7. Teaching Assistant Subactivity
Turns out that the teaching assistant subactivity diagram is just made up of subactivity diagrams.
FIGURE 8. Assign Scores
The activities in the Assign Scores subactivity diagram seem like states. Actually it looks like the first line of each of the activities are states and the second line are the transitions. It turns out the states are much easier to identify than all the transitions, so it does get harder.
The "Prompts with List of Courses" screen is the same as the student "Prompts with List of Classes" screen. It may be useful to go back through the use cases and the activity diagrams to change them to be consistent. It may not seem critical, but it can be very hard to identify when you are elbow-deep in code to notice that a class is the same thing as a course. For now we'll make a mental note that they are the same, but we should really change it.
FIGURE 11. Change Scores
Again, we are in luck as our activities closely resemble states. We already have "Prompts with Course". We need "Prompts List of Students", "Prompts List of Assignments".
FIGURE 13. Assignment Selection Screen
In the last activity, it has a display and a prompt. In our earlier activity diagram we listed both display and prompt as individual states. Here it is important to mock up a screen shot to show that the display and the prompt are on the same screen. Remember we combined a few of the steps of the use case scenario together when we created this activity. It is the screen shot that will help show that it is only one state.
FIGURE 15. View Class Scores
We already have a prompt for class. Actually, we have "Prompt for Course", "Prompt for Class", and now we have "Prompt with Class List". These three activities were not related when part of a use case or even as part of the activity diagram. While in the activity diagram, we pulled everything together, we did not compare anything. It is very useful to always start again from the bottom and work your way up for every diagram you work on. That way you can identify the items that are the same and the items that should be the same.
FIGURE 16. Displays Scores Screen
Again, as we recurse back up to our high level activity diagram, we need to include the teaching assistant decision node as a state.
FIGURE 17. Teaching Assistant Menu Screen
FIGURE 18. Instructor Subactivity
Before we recurse into the instructor subactivity diagram's subactivity diagrams, we should remember that "Assign Scores", "Change Scores", and "View Class Scores" were already recursed into when we did the teaching assistant subactivity diagrams's subactivity diagrams.
We only have to recurse into "Assign Grade" and "Change Grade".
FIGURE 19. Assign Grade Subactivity
Prompting for a course has been discussed at length already and we know we already have that state. We only need to add a state for "Provides Student Names and Enters Grades".
FIGURE 20. Assign Grade Entry Screen
We are starting to not have to add as many states as many of them are somewhat redundant.
FIGURE 21. Change Grade Subactivity
We have "Prompts for Course" and "Prompts with Student List". We only have to add the state for "Displays Old Grades and Prompts and Enters New Grade".
Perhaps you notice that we could simplify it a bit. There isn't a big difference between assigning a score and assigning a grade. We may be able to put it all on the same screen. This is a valid question. Each method allows you to look at the system from different angles and raising questions about how it should work. I saw the same alternative. But then I noticed that if I did that then there would be no overlap between the teaching assistant and the instructor. Our problems statement said that only an instructor may assign a grade. Plus, if there is no overlap then there can be no code reuse between the two! As much as I stress that there is a wall between design and implementation, questions like these always seem to help me realize that the wall isn't an absolute. Implementation implications will always come up during the design. When we design the internals of our system it will come up all the time and there are ways to evaluate the tradeoff between design and implementation. When designing the outside of our system it is much more difficult.
The problem statement is clear that there is a strong difference between assigning a score and assigning a grade and the two should be different options. Because of that on top of the advantage of reuse, we will keep the two seperate.
FIGURE 22. Change Grade Entry Screen
And again we recurse upwards and create a state for the instructor decision.
FIGURE 23. Instructor Menu Screen
- Sign On
- Prompts with List of Classes
- Displays Scores and Averages
- Displays All Grades.
- Student Menu
- Prompts for Score Description.
- Provides a Chart of Student Names and Scores.
- Prompts with Course.
- Prompts List of Students.
- Displays Old Score. Prompts for New Score.
- Displays Scores
- Teaching Assistant Menu
- Assign Grade
- Change Grade
- Instructor Menu
