FIGURE 1. All Interaction States

This is the tricky part. Now that we have all of our states, we need to understand how we go from one state to the next and identify the transition that will allow us to move.

We will start with the start state, the big black dot. The start state is not a typical state as it only a marker for what is the first state. We do not annotate the transition from the start state. We can identify only one state that the start state goes to. At least in our system it is easy, the first thing that happens is the login.

What we want to do is from each and every state we need to look at it individually and ask what states you can transition to and what needs to happen to make that transition happen.

From the "Sign On" state, we can move to any of the menu states based on who signs in. This means that when someone logs in we will process his or her information and determine which menu to show. It is also the case that if the login information is incorrect, that we are put back in at the login screen to try again. If we provide incorrect information, will a screen be displayed to say that our identification information was incorrect? If so, then we need to have another state that is a screen that gives us a warning and then we press OK to go back and redo our login information.

FIGURE 2. Login State Diagram

As you can see, this can get really big really fast.

Let's look at the student menu. What are all the states we can go to from the student menu. We know that we can transition to "Display All Grades", or "Display Scores and Averages." But then where do we go from there? We don't just stop in spite of our activity diagram implying that we are done. Actually our use case implies we are done at that point as well. But after we have gotten the information that we want, we can make another selection from the student menu.

FIGURE 3. Student State Diagram

Unlike our use case scenarios, we are trying to construct a complete system operation here. From our student menu we would want to be able to go back to the login screen again. Or should the student exit his/her browser to exit his/her session? If the student should be able to exit and log in again, there should be an EXIT button on the student menu screen. If the student exits the web browser to end the session, there should be a transition to a final state from the menu. We have not had the opportunity to have to go ask our client for input. We should consult our client to see what he or she wants.

Since this is a web-based application, it is more likely that we would have the user exit the web browser in order to exit the application. This also means there is no way to go back to the login screen again without exiting the application and then starting it again. Sounds awkward, but that is how most web-based applications work.

FIGURE 4. Student State Diagram with Exit

I had mentioned before that there are non-interaction states. Those states are ones where the computer is doing a significant amount of work, typically symbolized by the mouse cursor turning into an hourglass shape. Since we know that not only is this a web-based application, but one that interacts with a database, when do we extract the data from the database to provide the information to the student? If we make our connect when Carol explicitly asks for her grades or for her scores and averages, we may have to keep re-asking the database each time Carol makes that request. Instead, we may extract the data once when we construct the student's menu.

FIGURE 5. Student State Diagram with Database Connection

We can explore the states that follow from the teaching assistant menu as we have typically looked at the teaching assistant after the student. It is possible for us to choose the instructor or even the administrator because we could pick anything to look at next. We just have to be sure to pick every state and identify where it transitions.

The teaching assistant can assign scores, changes scores, or view class scores. The assign scores state is actually one that we get to after we have determined the course and the student. The assign score activity is just the choice made from the menu, it does not exist as an actual state mostly because it is not a specific screen, but a combination of screens.

Assign scores is: prompt course, enter score description, and then assign scores. Change scores is: prompt course, prompt student, prompt assignment, and then change score. View Class scores is: prompt class, then display scores.

They all have prompt course as their first state. We may think that they all go to the same state, but that would mean that from that state they all go to the same next state, which isn't true. Each prompt course has a different next state, so they are not the same.

I am not including the extra states on the state diagram as it can get quite confusing. From the student menu we see that we have no way of getting back to the login prompt again. Going to a menu is a one way transition.

FIGURE 6. Teaching Assistant State Diagram

We can read all the teaching assistant information before we construct the teaching assistant menu, but when do we commit our data? To constantly communicate with the database would make for a very slow process. We may wait to commit our information until we exit. This would be a good question for our client. For our system, we will minimize the interaction with the database and commit the changes upon exit.

FIGURE 7. Teaching Assistant State Diagram with Database Connection

The instructor is an extension to the teaching assistant. The administrator is an extension to the instructor.

FIGURE 8. Instructor State Diagram

FIGURE 9. Administrator State Diagram