A Method for Program Design
IT, Høgskolen i Østfold
Program design > The Steps >Details
../../common/gfx/prev.gif ../../common/gfx/home.gif ../../common/gfx/next.gif

The Details

We have stressed that the design process should be open to participants with different background, and that the main objective with the tools we have introduced is that of communication. As a consequence of this it is necessary to offer a tool for sorting out the small details. A tool that has proven rather easy to understand and use is the state diagram, or state transition diagram.

The easiest way to explain it is to look at a very simple example:

buttonstate

A state is characterised as a stable situation in he dialog. The important thing is to get a map of all the possible actions we can take to change the state. One way to explain a state is to say that it is characterised by the possibilities we have to leave it.

The example above is included for simplicity. We would of course not use time and effort to analyse a standard situation like this. A slightly more complicated state transition is analysed in the sample at the end of the article.

It is important to note that we have focus on the dialog situation. We do not bother about "internal" states of the program. A lot of internal variables and data models may change without affecting the dialog.

State analyses is not an alternative to prototyping, it is a supplement. The idea is that that it should be possible to discuss alternatives without prototyping. The state diagram is available to all parties in a design group and is a very precise way to express a view on how the program should function.

Normally we would not draw a state diagram that covers the whole program, neither will we analyse all parts of a program with different state diagrams. Normally 90 percent of the interaction is predefined as part of standards without detailed analyses. There is however an interesting side to state diagrams that may be developed further. We may consider a state diagram as a map of the program where the user leaves a path when she uses the program. We could use this for testing, either by observation or automatically by logging the path. This could supply us with very useful information of how the user prefers to use the program, and how long tracks she takes to solve a problem or perform a task.

Sample

A Method for Program Design fra Høgskolen i Østfold: http://www.ia.hiof.no/~borres/marketmet/

../../common/gfx/prev.gif ../../common/gfx/home.gif ../../common/gfx/next.gif

Valid XHTML
popup card
Bygget med WXT : 02.jan.2006