Extending UML to GUI Modeling

Kai Blankenhorn, Wilhelm Walter

Fachochschule Furtwangen FB Digitale Medien

The UML Profile for GUI Layout

Graphical user interfaces (GUIs) are one of the most important parts in most software systems. They consist of two major parts: a dynamic or behavior part and a static or layout part. This separation is often reflected in development processes, which hand over each part to specialists, either software engineers or screen designers. This division of labor leads to problems and conflicts during the early phases of the design process. As both domains make use of modeling, we have decided to bridge the gap by creating a common language for both groups to

use when developing GUIs. We consider a model of GUI layout the missing link between the two mostly separate worlds of graphics design and software development. While dynamics and behavior can be modeled using existing UML diagrams layout cannot, as all existing UML diagrams are not layout-aware. Therefore, we have created the UML Profile for GUI Layout, a UML 2.0 profile that uses Diagram Interchange to store layout information while staying fully conform with the standard. The profiles metamodel employs stereotyped classes that are linked by constrained associations, as described by the UML 2.0 extension mechanisms. The main concept of the profile is the ScreenArea, a region of screen space that serves a specific purpose (Fig. 1). Each can either contain other ScreenAreas or present a piece of functionality to the user, like Images, Texts, Links and Forms. Position and size of

each ScreenArea is stored using the Diagram Interchange elements Point and Dimension, respectively. The stereotype icons defined for the screen elements mimic the sketches graphics designers often do for the first versions of a layout. This way it was possible to transfer the general look of designer sketches to models. Fig. 2 shows the stereotype icons along with their meaning and their sketched origin. When applied for modeling a web page (Fig. 3) a large degree of resemblance can be observed between web page and model (Fig. 4). Such a model can be used by non-designers to visualize basic ideas and concepts, for instance the application architect can create a rough layout scheme, or the account manager can compose a layout while working with the customer. Communicating these ideas visually avoids common errors that occur when visuals have to be described verbally.

Profile Metamodel and Stereotype Icons

profile GUILayout stereotype ScreenArea +position: Point {subsets position} +size: Dimention {subsets size} +isVisible: Boolean = false +isExternal: Boolean = false {subsets nestedClassifier} +contained * Class

Example: A Screen and the Corresponding GUI Layout Diagram

Stereotype Icons
Sketch

Icon

An Image is a screen element that displays a picture.

{subsets class} 0..1 +container

A Heading displays a short text in a larger font that states the topic of the following screen elements. A Logo is a screen element that is the key element of the corporate design of owner of the system. A Text is a continuous text that includes several lines and possibly paragraphs.

stereotype FunctionalScreenArea +owner 1 {subsets class} {subsets nestedClassifier} +functionality Class

stereotype ContainerScreenArea

1..* stereotype Screen { self.container->isEmpty() }

stereotype UIFunctionality

stereotype ActivatableUIFunctionality

stereotype StaticUIFunctionality

A Link is an activatable functionality that triggers the display of another ScreenArea.

DiagramInterchange:: Point DiagramInterchange:: Dimension

A Navigation provides the user with efficient means of reaching all major parts of the modeled system. A Form requests a given set of data from the user.

stereotype Form

stereotype Navigation

stereotype Heading

stereotype Image

stereotype Link

stereotype Workspace

stereotype Logo

stereotype Text

A Workspace provides complex interactions in order to edit data. Fig. 2: Stereotype icons and their sketched counterparts. The righthand column shows the original screen elements, as we have extracted them from designers sketches. Each element has been abstracted from in order to generate simple geometric icons that match the UML lookand feel. Obviously, two of the stereotypes have no sketched counterpart. We have decided to introduce them, as we have found that they significantly improve the versatility of the graphical language. Fig. 3: A typical web page, including navigation, login and search form, a few paragraphs of text and some images as eye-catchers. While the overall look of the page is good and it is well structured, it looks a little cluttered and disordered. With all the elaborate details to distract the eye, it is hard to identify clearly where this comes from. Fig. 4: Model of the web page in Fig. 3. Using the corresponding diagram, identifying the layout issues on this page gets much easier. Theres a lack of alignment all over the page; then there are two logos and two navigations. Imagine this diagram had been drawn prior to developing the whole screen - the design team would probably have spotted these problems early on and avoided them by taking special care of alignment. This example also shows the combination of multiple UIFunctionalities within one ScreenArea, for instance, the images at the right are links at the same time.

Fig. 1: Metamodel of the UML profile for GUI Layout. The base element is the ScreenArea, a stereotyped class that represents a rectangular area of screen space. Its two subclasses can either be a container for other ScreenAreas or have some sort of functionality, which is modeled using the UIFunctionality stereotype and its subclasses. While StaticUIFunctionalities simply present a visual element on the screen, ActivatableUIFunctionalities perform an action if clicked on.

ScreenArea Inheritance
MainLayout

Use of Diagram Interchange

The Diagram Interchange specification originates from the XML metadata interchange format XMI, which is used to for storing information about the elements of a UML diagram. Although it serves this purpose well it fails to express the graphical layout information of the diagram. Diagram Interchange, as an integral part of UML 2.0, adds drawing and layout information to every UML Element, including size and position. This additional information enables new applications for UML that could not be handled nicely with previous versions of the language. Our profile is one of the first to probe these new possibilities.

account managers or customers. By providing a fixed graphical vocabulary that copies and simplifies the one used by designers, non-designers are capable of drawing diagrams that are understood by GUI designers and thus provide useful input for them.

ContentMain

FeaturedItem

Interactive Prototype
We have created an interactive prototype to demonstrate our ideas and provide a basis for evaluating the profile in design processes. The application has the look and feel of a vector graphics application and is prepared professional use by offering commonly used keyboard shortcuts for most functions and integrating into existing workflows by offering exports as HTML and Photoshop wireframes. In addition to the formally defined profile, the diagrams created with the prototype have a sketchy look in order to make designers, who often dont use geometrically shaped diagrams for their creative work, feel more comfortable with the program. The prototype is implemented as a Java Swing application so it can be run on almost any platform, including Windows and Mac OS X. It is available for download on the authors personal website at www.bitfolge.de/guilayout.

LastItems

Possible Usage Scenario

The main audience for our profile is any type of user interface designer, i.e. graphics, navigation and information designers. The diagrams produced with our profile are intended to be a supplement or replacement for freehand sketching, with the possibility to create sophisticated user interface models based on them. Therefore, the profile is best used for creating an initial model of the layout and the navigational concept of the application. In contrast to a sketches on paper, a diagram that is created this way can quickly be modified to reflect the evolving ideas in a creative process. Expressing visual ideas with written language is often difficult and can cause discrepancies between the writers and the readers understanding of the text. Misunderstandings like these can be avoided if visual ideas are represented visually, and this is what our profile achieves for GUI layout.

Fig. 5: The rough layout of a web page. This diagram concentrates on the basic ScreenAreas that dictate the functionality of the modeled web page. Three of the ScreenAreas are given names and are denoted as being abstract by putting their name in italics. Abstract ScreenAreas are ScreenAreas that cannot be instanciated, i.e. they cannot directly be displayed on a screen. They may have concrete specialized ScreenAreas, which can be displayed instead.

ContentMain CouponForm OrderForm RegistrationForm

OrderConfirmation

OrderSummary

Benefits for the Design Process and its Outcome

Using our profile yields significant benefits for the ones involved in the design process of GUIs. ScreenArea inheritance (Figs. 5 and 6) helps enforce consistent use of screen space within a large number of screens, as specialized ScreenAreas can not only inherit layout information from their parents, but also behaviour in terms of linked use cases. By restricting the elements that can be added to basic widgets, users of the profile are less likely to get lost in details than with sketches or graphics applications. As the diagrams can also be modified or completely redone quickly and effortlessly, this leads to a more complete exploration of the design space. Sketches made by specialist graphics designers often look more impressive than scrawly drawings by for instance system analysts,

Fig. 6: ScreenArea subclassing and specialization. As ScreenAreas are stereotyped classes, they may specialize other ScreenAreas, overriding their original content, and constrained to inherit their parents size and position attributes. Using this mechanism it is possible to use the rough layout in Fig. 5 as a template for multiple pages that share the same layout by specializing the differing ScreenAreas. Each of the five concrete subclasses of the ContentMain ScreenArea is displayed instead of ContentMain on a screen that has the above layout.

Fig. 7: A GUI Layout Diagram drawn in our interactive prototype. The application is used similar to a vector drawing application: First, the ScreenArea boxes are drawn using drag and drop, then they are decorated with their UIFunctionalities and combined into a Screen. The boxes can be dragged using the mouse and put into containers to group them. The diagrams can be exported as a Photoshop file to build a mockup on, and as an HTML wireframe that can serve as a basis for an interactive prototype. We consider integration into existing processes the key criterion for acceptance of the profile.

Dipl.-Inform. (FH) Kai Blankenhorn, M.Sc. kaib@bitfolge.de Prof. Wilhelm Walter wa@fh-furtwangen.de

FACHHOCHSCHULE FURTWANGEN
HOCHSCHULE FR TECHNIK UND WIRTSCHAFT UNIVERSITY OF APPLIED SCIENCES

Fachhochschule Furtwangen www.bitfolge.de/guilayout