Statechart Diagrams Problematic!

UML Statechart Diagrams are clumsy when used to model the Implementation Level of a large User Interface. A few small changes to the notation could make a significant difference to the usability of this notation for the design of User Interfaces and Presentation Layers. Here is why...

In his book, Constucting the User Interface with Statecharts, reviewed in March, Ian Horrocks was careful to point out that he had adopted David Harel's Statechart notation and made no attempt to update or modify it. It was obvious that he was interested in pushing his design and construction technique and didn't want to muddy the water with a pointless debate on notation.

I intend to show that the technique is indeed very useful and it will be a key part of several articles appearing at this website over the coming months. However, the notation can become unwieldy when applied to a large user interface design. Something which could be significantly improved with just a few changes. Changes which have already been seen as useful in other areas of the UML.

Firstly, let me make it quite clear that the existing Statechart Notation is workable. It is a significant improvement over Finite State Diagrams (FSDs). Horrock's proved conclusively in his book that FSDs are unworkable for User Interfaces due to the huge number of possible combinations. Harel's Statechart Notation works because it is a fractal representation of the whole state spectrum. It is only interested in the number of states which are possible, not all the impossible combinations. FSDs are cumbersome because they insist that every state even those which are completely impossible must appear in the diagrams. So, Statecharts are a workable design solution for User Interface. FSDs are not.

The key problem with Statechart notation is that it echoes Entity-Relationship Diagrams and uses a containment hierarchy.

Figure 1. A simple Statechart Diagram showing two sub-states

For User Interfaces with large a-modal designs this quickly becomes unwieldy. Maintaining the diagram in a tool is difficult as the design is developed, printing it is difficult and states have to be continually re-sized to make space for new sub-states. Consider a simplified Statechart for this website. The diagram is unwieldy and practically unworkable.

Inheritance

The problem with this is that inheritance in the Statechart is shown using a containment in a similar fashion to Types and sub-types in an ERD.

figure 3. An ERD for a simple inheritance relationship

UML would show this same ralationship like this...

figure 4. UML Class Diagram simple inheritance relationship

Although the diagram takes as much space as the ERD, it is much more easily extended and manipulated. You can easily change and add details to a sub-class like ChequePayment without having to move or manipulate the ChequePayment or the Payment super-class. This is not the case with the ERD. The ERD is a more cumbersome notation to work with when the hierarchy is deep.

In business systems there is rarely a deep hierarchy. For Problem Domain Analysis, ERDs work reasonably well. The style of notation does not lend itself well for User Interface state modeling where hierarchies of 8 levels deep are not uncommon.

Consider, a sub-state 2.1.1 "is a" 2.1 which in turn "is a" 2. There is a clear inheritance relationship going on.

figure 5. A UML Statechart with a simple inheritance relationship

In UML and other OO notations, the unwieldiness of containment to denote inheritance was recognised and fixed by using a relationship arrow to denote inheritance. I would like to see the same convention adopted for Statecharts. Reconsider the simplified UIDesign.net Statechart when this convention is adopted

Its clear that the above alternative does not represent a complete solution. There are no Event arrows shown. Clearly, a strong visual differentiation between inheritance links and Event arrows would be required. As you can see I have chosen to tag an inheritance arrowhead with the start state indicator to show that the default sub-state. It is not clear how the action on the default sub-state might be represented.

This diagram is intended as a discussion point. Although busy looking, it would represent a notation which is more easily manipulated in a tool and in some respects communicates better the elements of the User Interface. The containment hierarchy can be confusing. Try explaining to a client business analyst why the "Button Up" state is "inside" the "Button" state. It can be tricky.

Stereotypes

The earlier version of Together/J 2.x allowed the addition of <<stereotype>> tags into the Statechart. I think this was probably a bug and it has been corrected in the latest edition which is much truer to the UML specification. However, the <<stereotype>> tag was in fact incredibly useful for User Interface design. I had introduced a number of <<stereotype>> tags to indicate the nature of the state and what it represented e.g. <<Screen>>, <<Window>>, <<Frame>>, <<Label>>, <<Button>>. This was a considerable aid to communicating what the diagram represented and easily cross referencing it with a Paper Prototype, a Navigation Diagram and actual code.I found that graphic designers, coders, testers and clients could all read the Statechart diagrams and follow what it represented. This relied on a sensible naming convention for the states and the use of the Stereotype tags. With the latest version of Together/J this will no longer be possible.

Better Tools may be the other alternative

Changing the notation may be an answer to making flat Statechart Diagrams work better. However, changing any notation is always hard. So many people have already learned the existing notation. The barrier for a new notation is always high. Consider how many of you initially resisted a move to UML? I know that I was comfortable with Booch and Coad notations. Learning UML was a matter of necessity.

If the notation is not to change then we must look at better tools. One way that the current notation could be made to work, would be to make the Diagrams 3-dimensional. Allow the drill down into a state and link Statechart Diagrams 3-dimensionally. This way any diagram could remain a manageable size while the full complexity could be expressed in the model.

UML and User Interface Design Notation

This article only hints at the bigger picture. The real problem is that UML has never seriously been intended for User Interface Analysis and Design. I believe that the industry genuinely wants to tighten up the procedures and methodologies for development of User Interfaces and Presentation Layers. It is obvious that this should be done within the framework of the UML. Statecharts are only one part of what is required. A Statechart is useful as an Implementation Level diagram. We also need to develop conventions for Requirements, Analsysis and Navigation/Interaction Design.

With a coherent set of notations for each aspect of User Interface design within UML it would then be possible to provide cross referencing between them. To show the relationship of a state in the Statechart to an entity on a Navigation Diagram, to a Class in the Presentation Layer Class Diagram, to the messaging in a Sequence Diagram and so on.

At that point, we are finally making progress.

Thanks to Ian Horrocks for his comments and the observation that 3D diagrams may be a better way to go.

The Class and Statechart Diagrams for this paper were produced using Together/J from Togethersoft