GUI requirements

How to translate GUI requirements into code

The user interface of a use case consists of all dialog windows that are needed to perform a use case. Message boxes are also considered part of the user interface.

However, we do not necessarily have just one user interface. As new technologies emerge, we might need to design additional user interfaces for cell phones or PDAs, for example. User interfaces may differ dramatically in complexity. A cell phone user interface, for example, is less complex than a full-blown user interface on a desktop with all the bells and whistles. On a desktop computer we usually have a graphical interface with multiple windows whereas on a cell phone we have a Cards-like user interface with no graphics (so far).

As a consequence, we may have more than one user interface for a given use case. The question now is, if there is a way to describe the user interface in a device-independent manner.

Dialog windows

A dialog window is a means of interaction between user and system. What I denote a dialog window may be referred to as a frame, as a panel, as a form or just as a window. Various terms are common. However, I just stick to the rather neutral term "dialog window".

After we have described a use case we develop prototypes of the dialog windows for the user interface of the use case . Usually, we use an IDE such as JBuilder or VisualAge. When we are done with our first iteration we have static representations of dialog windows. What we see on a dialog window at this stage are just fields and buttons. We don't care about menus at this time, since menu structures are highly standardized (with our GUI style guide) and are not of much value to us, since we want to demonstrate the use case-specific things.

Is it really sufficient to just have dialog window layouts? In a review session, we not only deal with presentation (which is what we have developed so far) but also with behaviour. We only talk about behaviour in some informal way but we do not have it in our prototypes. As we all know from experience, this is a source of misunderstandings. Therefore, we would love to have a means to describe behaviour as well. And to even go beyond that we would value a way to describe our dialogs in a device-independent way.

XML (Extended Markup Language) is a capable candidate for describing dialog windows. A document type description (DTD) or an XML schema (much better) would be required to describe a dialog window on the meta level. Every single dialog window would then be described using the DTD or the schema.

However, things are not as easy as they look like in the first instance. We realize this when we think about what we need to describe:

Presentation description: the various GUI elements
Presentation events: the activities that occur within the dialog window (mouse clicks etc.)
Presentation behaviour: the state transitions that occur during interaction with the user and the application.

Of course, we also need a solid data model as a base for all forms processing. This data model layer not only is vendor-neutral but also device-neutral.

It certainly is quite a challenge to describe presentation behaviour. There are many aspects to presentation behaviour. Just to give a few examples, we might have relationships and dependencies between GUI elements, such as "if the user enters a value in field A then input is disallowed in field E" or "the value in field C must always be less than the value in field B" or "the value of field D is always the result of a computation (eg. Price * quantity)". As we describe relationships and dependencies we become aware that we also describe forms logic.

Developments to watch

Currently, we have no XML tag set to describe everything we need. There are quite interesting developments going on, however. We know of two efforts in this area.

A working group has formed under the umbrella of the WWW Consortium to provide a clean new forms model. They are still in the early stages. A requirements document is dated March 29, 2000. So far, we can see that they follow a layered approach.

Also, Universal Interface Technologies, Inc., have developed an XML based tag set for user interfaces which they named "User Interface Markup Language" (UIML). It already does a good job of presentation description and an adequate job on presentation events description. However, description of behaviour is not part of their effort at the moment.

Describing a dialog window with UIML directly is quite cumbersome and error-prone. We would need to learn the language which is not really what we want. A point-and-click editor (like those that are part of an IDE) would be extremely helpful. We would then be in the position to "draw" the dialog window right on the screen just as we are used to doing by using a conventional IDE. Doing this the modeler would produce UIML by using a generate function. A renderer then takes the UIML file as input and generates Java code.

If this technology unfolds as expected, we could speed up user interface design quite significantly. The extract from a process (see below) shows how GUI prototyping may happen. It is assumed that we edit the generated Java code. However, this would not be necessary if we were happy with what the GUI-IDE generates.

Does it really make sense?

In general, we are not used to going beyond the initial prototyping of dialog windows for the user interface of a use case. We argue that it is too early as we do not know all the necessary details to produce a full-fledged design of the dialog windows.

However, the very reason for doing prototyping at this early stage is to verify that the customer's requirements are met. If the customer demands changes we could easily apply the changes in the specialized IDE, regenerate a UIML file and regenerate executable Java code from there. This would not only increase confidence that we design what the customer really wants but also speed up the analysis and design process quite significantly. We could regenerate many work products again and again from a single source and this would help tremendously in our today's iterative and incremental approach.

Also, if we have some kind of structured description we can generate test cases and test scripts which we could later use with GUI test tools like WinRunner.

So, the verdict is: Yes!, Yes!, Yes!, it does make sense! We enhance productivity considerably and, at the same time, improve quality. Our productivity increase will be in the three-digit numbers. This is no exaggerated hype but sober calculation, although we cannot rely on experience yet.

We do not have everything we need, today. However, we definitely should go ahead and use the emerging XML tag sets and new tools as soon as they become available.

Products or trade names are trademarks or registered trademarks of their respective owners