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
Michael W. Bigrigg, Copyright
2004-2007
The usefullness of the state chart diagram is in the understanding of the program flow. The use case diagram is considered a static understanding of the programe execution with the state chart being a dynamic understanding. This chapter starts the notion of an implementation to go along with the specification. For an interactive application, it is the screen shots that we can use to represent our implementation. As with our use cases and deployment diagram, we are still looking at the outside of the system. We haven't yet introduced how we're going to do anything yet and are still describing how the system works.
A state chart diagram has four main parts: a start state, one or more final states, intermediate states, and transitions between states. More complicated state chart diagramming tools have been introduced, but the basic state chart tools will get you most of the way.
The start state is easy, it identifies where to begin, and is signified by a solid black dot. A final state signifies where the application ends, and is signified by a solid black dot with a circle around it. States are rectangles with rounded edges. It looks a lot like the activity diagram.
The parts that make a state diagram different from an activity diagram is the looping and the transitions. With an activity diagram you start at the beginning and proceed ever closer to the final state, while in a state diagram you move from state to state not even trying to get to the final state. Unlike in an activity diagram, the transitions in a state diagram are labeled identifying what it will take to go from one state to the other.
The bulk of the work in constructing a state chart is to identify the intermediate states that exist between the start and final states along with the transitions that explain what it takes to go from one state to another.
I like to tie in the screen shots with a state chart because they do go well together. A good starting point is that every major activity is a state. Since we're looking from the outside this means that it really is every major activity that we can observe from the outside is a state. I like to say that every time we can imagine that our mouse cursor goes from an arrow to an hourglass we are at a different state. After all, a major activity is something that is going to make us wait while the system performs some operation.
I tend to add in the states corresponding to major activities last. But a good example is right at the beginning. The start state can be the whole system is turned on. Given our system, the first thing that happens when we are turned on is that we contact the registration system and update our gradebook database with changes to the schedule:
Next we can say that every screen where the system will sit and wait for input is a state. An example of this is our login screen. It is the first thing that we get to after the system is running. Unlike the transition between the start state and our update state, we need to label the other transitions. After all, it is not an immediate transition, some event has to occur to trigger us to move to another state. In this case, if the login fails (perhaps a mistyped username or password) we are asked to login again. If we are successful, the system ends. It is not the most realistic example, but you get the idea.
This is also the point that I would sketch out what information is contained on each screen. This does not have to be a pretty screen shot and should really be more about the functional parts of the screen than the presentation. I use a graphical user interface (GUI) builder to just drag items onto a screen to show what information will be there. You can do this by hand and scan it in or you can use a drawing tool.