Extending UML for UI
A position paper for the TUPIS2000 workshop at UML2000
by David J. Anderson

This paper seeks to set out my current position and opinion on how the Unified Modeling Language might be extended to accommodate the modeling of interaction design and user interface design for the purpose of facilitating a user centered design process.

This paper has been heavily cannibalized from earlier papers published at uidesign.net and listed in the Related Articles section on this page.

I will be presenting proposals for two distinct levels of abstraction in the development of a user interface design. For the higher level, the Interaction Design, I will seek to layout a laundry list of attributes that would be required by a good modeling language for Interaction Design.

For the lower level, the User Interface Design, I will be proposing that the implementation level abstraction is modeled using an extended version of the existing UML Statechart notation.

For the purposes of this paper, "User Interface Design" is used to mean the process of elaborating and the documentation of, a design which leads to program code which implements the Presentation Layer, Views or "screens" within a computer system.

Interaction Design

Interaction Design is used to express the process of elaborating and the documentation of, a design which abstracts the navigational flow of user facing part of a system for the purpose of completing the user tasks. Interaction Design does not concern itself with the code implementation but instead focuses on delivering a solution to the user requirement. Interaction Design models have also been called Storyboards or Navigation Maps or Models.

Implementation Model

In this paper, the term "Implementation Model" is used to describe the diagrams which represent the User Interface Design. Diagrams from which actual code can be built.

Navigation Model

The term "Navigation Model" is used to describe diagrams which represent and describe the Interaction Design. Diagrams which need further abstraction and elaboration before code can be constructed for the Presentation Layer. A Navigation Model should precede an Implementation Model.

Presentation Layer

Computer code which constructs and implements the User Interface of a computer system regardless of the underlying technologies in use.

Unit of Work

A logical boundary within the Interaction Design, representing a subset of the Navigation Model, which the User will see as a task or activity which must be undertaken, having a clear starting point, a logical conclusion and the possibility that the task can be abandoned, whereby the system would return to a condition before the starting point.

Logical Transaction

A Unit of Work

Transaction Boundary

A method for delimiting the elements of a Navigation Model or Implementation Model which lie within a Logical or Physical Transaction.

Physical Transaction

A boundary within the User Interface Design, representing a subset of the Implementation Model, which the underlying computer system will see as a series of interactions with a persistent storage mechanism such as a database or file system. A series of interactions which have a clear logical starting point, a logical conclusion at which point any modifications become persistent, or the possibility of abandonment, whereby any changes would be ignored and the persistent storage returned to the state before the physical transaction began.

A physical transaction can map directly to a logical one, or several physical transactions may occur within one logical one.

The key difference between a logical and physical transaction is that a logical transaction is user centric and a physical transaction is database (or system) centric.

Nested Transaction

A transaction (logical or physical) which is contained within another transaction of the same type (logical or physical).

Exception

A condition in the processing of the operational system which is not described in the Interaction Design and Navigation Model. Due to exceptional behavior rather than expected behavior the system cannot continue as intended but may be able to recover.

Exceptions can be accommodated in the User Interface Design and modeled in the Implementation Model.

Direct support for processing exceptions is provided in a number of computer programming languages and runtime environments.

Over recent years there have been several attempts to outline an approach for modeling navigation maps. David Ruble [Ruble 97] used a system derived from Data Model ERDs. Larry Constantine and Lucy Lockwood [Constantine 99] have proposed a system loosely based on UMT Class diagrams and Dave Roberts et al have proposed a system for object oriented navigation maps [Roberts 98], directly derived from UML Class Diagrams.

For my own part I believe that any of these approaches could lead to a complete solution but none of the current offerings goes far enough and has sufficient vocabulary to allow for complete modeling of navigation maps and interaction designs.

In principle, I would like to see a resulting Navigation Modeling Language derived from UML Class Diagrams. I would like to set out a list of attributes which I would like to see in the resulting solution.

Attributes of a Navigation Modeling Language

1. Easily drawn by hand. The basic vocabulary should lend itself to pencil sketching and to easy rendering on a white board using markers or a combination of markers and sticky notes.

2. Easily implemented in an electronic tool. Like existing UML notations, the new notation should lend itself to rendering in a computer based tool and manipulation in a WYSIWYG environment.

3. Visually clean. Elements should be sufficient to communicate their meaning without over elaboration. They should be sufficiently distinct to avoid confusion or misinterpretation of hand drawn models.

4. Sufficient vocabulary to express interaction designs without being overly verbose. Generally, only 1 method should be provided to convey any single concept. For example, UML Class Diagrams have two methods to show an Interface. This should be avoided if possible.

5. The language should allow for the expression of User Interface Objects and Classes of Objects.

6. Objects or Classes can have attributes e.g. dimensions.

7. There may be a number of ways for expressing attributes e.g. dimensions may be expressed in absolute or relative terms

8. It should allow for the expression of basic navigation between elements or objects.

9. Navigation can be conditional so the language must be able to cope with branches in the navigation flow.

10. It should allow for the expression of actions. An action is the occurrence of system behavior which may change the state of the user interface or the underlying business logic, but may not or need not result in a navigation to another element.

For example, a view displaying a mortgage calculator may display edit boxes for Loan Amount, Interest Rate and so forth and a Button which performs the action "calculate", the result of pressing the button causes a new Monthly Payment Amount to be calculated and displayed. This is a description of an Action in the user interface.

11. A number of basic principles from Object Oriented concepts should be adopted into the language. It should allow for the concept of containment of Objects within other Objects.

12. Further it should allow for aggregation of Objects

13. All Objects or Classes should be visual, audio or of other sensual stimulate and should be distinct from Business Objects. In other words, there should be a clearly understood difference between a Class in a UML Class Diagram and a Visual Element Class in a Navigation Model Diagram

14. The language should allow for inheritance between classes of visual elements. For example, a ComboBox which allows typed input as well as selection from a drop down list could be seen as a subclass of DropDownList or inheriting the behavior from DropDownList.

15. The language should be easily mappable to/from a basic storyboard or mockup of a user interface. The storyboard being a precursor and predecessor of the Navigation Model which is a further abstraction.

16. The Navigation Model should be easily and robustly mapped to a Statechart of the Implementation Model (described below).

17. The Navigation Model should be easily mapped against a Content Model [Constantine 99] or Content elements should be an active part of the vocabulary of the Navigation Model.

18. There should be a method for mapping Actions and Visual Elements (either User Interface Objects or Content Objects) against Business Objects in a UML Class Diagram to show from where the behavior and the data is sourced. This will ease the task of mapping the Navigation Model into an Implementation Model and may eventually facilitate the automatic creation and partial population of source code, as is currently available through many UML Modeling tools. Furthermore, this may eventually facilitate simultaneous round-trip engineering of user interface code and design in a similar fashion to the simultaneous round-trip engineering offered in the Together UML tool for business objects through UML Class and Sequence Diagrams.

19. Multiple threads of operation. The notation must be able to communicate where multiple active navigation flows are possible. It should be able to show where a new thread begins and what might bring it to an end.

20. A Navigation modeling language must be able to convey the notion of a Unit of Work, clearly indicating the elements which are within a Unit of Work and the navigations which move the system into and out of a Unit of Work.

21. Finally, a navigation map needs to show recovery from exceptions including error catching screens or views.

Summary

From elaboration of early requirements for a system, a development group may have elaborated, Storyboards or Essential Use Cases / Task Cases, to describe navigational flow. They should also have developed a Content Model which maps required visual content against User Goals or Tasks. A Navigation Modeling Language must be capable of expressing these navigational flows in a more abstract manner and mapping in the required content to each element in the navigation flow. Furthermore, any Navigation Modeling Language must allow the further elaboration of navigational elements which result in the progression of the user flow through the navigation map, as well as allowing for the elaboration of action elements which result in necessary functional behavior.

All the elements should be mappable backwards towards the requirements and forwards towards the further elaboration of the Implementation Model and program code.

Directly following earlier work by Ian Horrocks, then of British Telecom [Horrocks 98], I am proposing that the implementation model for a user interface design is delivered using David Harel's Statechart notation which is already adopted into the UML.

However, practical experience using Statecharts for user interface design have shown that it is not completely up to the task in its current form. Ian Horrocks deliberately chose not to modify Harel's original notation, with the direct intent of improving buy-in to his technique. It was important not get bogged down in debate over notation but to make progress on improved modeling techniques for user interface. However, now is the time to propose some improvements. It is my intention to make as few proposed changes as possible, in order to minimize impact on the existing notation and to maintain the simplicity and brevity of the existing Statechart notation.

There are three key areas where Statechart notation is not currently sufficient for the purpose of user interface modeling. The first is the notational scoping of transactions or units of work. The second is the ability to cope with processing exceptions where the normal flow of states is interrupted. The third is derived out of the hierarchical nature of user interface design problems. This leads to a large depth count in the hierarchy of states which diagrammatically problematic. Drawing user interface implementation models with current Statechart notation is difficult.

Finally it would be nice to see a naming convention emerge for States within Statechart diagrams, so that is possible to identify a given State on a diagram and understand its position in relation to others in a hierarchy.

Transaction Boundaries

Several schemes may be possible for the indication that a State belongs within a transaction or a unit of work. So far I have adopted the convention of using a container drawn in a different color. This is sufficient providing that one large caveat remains true - there are no overlapping transactions, only flat or nested transactions. Generally speaking for good design and robust transaction isolation this would be true. However, it may be better to adopt a notation that allows a single State to exist within more than one transaction.

There may be another objection to my existing notation, that it simply introduces yet another box or container, and however, this is rendered, using a different color, dotted line, filled background etc., it is problematic for drawing by hand and is difficult to distinguish from a containing state.

Alternatives are possible. For example, taking a cue from the UML Class notation for an interface a lollipop might be added to each state indicating the name of any transactions that it belongs to.

For the time being, I am sticking with the proposal that transactions be indicated using a simple box as shown below and that the transaction be named in the upper right corner for identification purposes.

Additionally, I would like to modify the notation to clearly mark the starting point of a transaction within the transaction boundary. I suggest that we do this by adopting the stereotype notation from other UML notations into the Statechart notation. Thus a Transaction Start state could be indicated with a <<Tx Start>> stereotype. Stereotypes would be a generally useful addition to the notation in any case.

Exception States

The current notation would allow the modeling of exception states and recovery. However, it would be messy and clutter the diagram unnecessarily. For example, say a system has 100 possible exceptions which can be thrown and caught and most of these can happen at any time. It would be necessary to model those 100 states coming off every other state in the diagram. This would lead to unreadable diagrams and make Statechart modeling unworkable.

Statechart notation was adopted as a method for simplifying the modeling of Finite State Machines, with the explicit goal of eliminating unnecessary diagram clutter. Therefore, I am proposing that we take the same philosophy when deciding whether to extend the notation language in order to simplify the handling of exception states.

Brian O'Byrne (of ebeon.com in Dublin, Ireland) and I have proposed a simple addition to the notation to signify the exception state. A simple "X" contained in a circle, similar to the existing History State element.

The precise exception being handled by the symbol can be indicated as a condition on the transition arrow to the recovery state. The condition can show the names of the exceptions which allow transition to the recover state when an exception is caught at or below the current level of the state hierarchy.

Statechart Notation Problematic

In a November 1999 editorial, I proposed a possible alternative to the current notation which eliminates containment in the notation. This proposed a similar change to that which was made between Data Model ERDs and Object Model UML Class Diagrams. In response to this Ian Horrocks suggested maintaining the existing notation but improving the tools so that it was much easier to facilitate hierarchical drill down through levels of the diagram.

Moving forward I will now propose that Statechart notation is modified to allow the indication of a hierarchy of states within a state on the diagram. Essentially a way of visually indicating a link to another set of substates contained in a separate diagram. This would visually facilitate Ian Horrocks desire to allow hierarchical drill down, and would provide suitable visual affordance for tool vendors to indicate that one diagram is contained within another.

Following the convention taken by Peter Coad and Togethersoft (and others) to signify a UML Class in a separate package using a class symbol with a clipped corner, I am proposing that a set of substates represented in a separate diagram be indicated with a state symbol with a clipped corner. The clipped corner symbol would be named for the outer state which it represents on another diagram. UML tools could then allow the opening of another diagram file through the double-clicking of the clipper corner state symbol.

Naming Convention

Following established Object Oriented programming conventions to delimit names using a simple dot ".", I propose that state names be derived by expressing the name through the hierarchy of states, delimiting each level with a dot. For example, the Transaction Started state, TxStarted, would be expressed by the full name, FirstPage.TxStarted

Multithreading

Not shown or discussed is the need for multiple threads of execution in complex UI designs. The Statechart Notation already has a mechanism for showing multiple threads of execution. It is important that this remains in the language and its use is reinforced with respect to user interface design implementation modeling.

I have attempted to layout some basic ideas for modeling languages which can be used to express the User Interface code design and the higher level abstraction of an Interaction Design as a Navigation Model. I firmly believe that it is possible to create a method for end-to-end documentation of a user centered design, computer system development project from requirements through to final testing. Such documentation should be traceable from one end to the other and clearly mappable at each each stage to its successor and from its predecessor. I believe that I have laid out the basic building blocks for achieving this in the user interface. However much work is required to elaborate these ideas and tests the proposed results before we will have a truly unified and universal modeling language for user interface design and user centered design in general.

References:

[Coad 99] Java Modeling in Color with UML, Coad, De Luca, Le Febvre, PTR-PH, 1999

[Constantine 99] Software For Use, ACM Press, Larry Constantine & Lucy Lockwood, 1999

[Gray 93] Transaction Processing : Concepts and Techniques, Jim Gray and Andreas Reuter, Morgan Kaufmann, 1993

[Gamma 95] Design Patterns : Elements of reusable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides, Addison Wesley, 1995

[Horrocks 98] Constructing the User Interface with Statecharts, Addison Wesley, Ian Horrocks, 1998

[Roberts 98] Designing for the User with OVID, MacMillan, Roberts, Berry, Isensee, Mulally, 1998

[Ruble 97] Analysis & Design for Client Server and GUI Systems, Yourdon Press, David Ruble, 1997

The Class Diagrams and Statechart Diagrams used in this paper were produced using Together/J v3.x from Togethersoft. The Transaction Boundaries, Exception States and other proposed additions to the Statechart language were added to the standard notation using Photoshop.