21-05-2013, 02:56 PM
User Interaction and Interface Design with UML
Abstract
This chapter is devoted to show how to use and specialise UML diagrams for describing the user interfaces of a software system. In order to accomplish the description of user interfaces, the proposed technique considers three specialised UML diagrams called user-interaction, user-interface and GUI-class diagrams, which will be built following a model-driven development (MDD) perspective. These diagrams can be seen as the UML-based UI models of the system. In addition, this paper concerns with code-generation to implement the user interfaces of the system by using GUI-class diagrams and user-interaction diagrams. A case study of an Internet book shopping system is introduced in this chapter to proof and illustrate the proposed user interaction and interface design technique.
INTRODUCTION
The emergence of the Unified Modelling Language (UML) (OMG, 2005) as an industry standard for modelling systems has encouraged the use of automated software tools that facilitate the development process from analysis through coding. The user interface (UI), as a significant part of most applications, should also be modelled using UML. UML diagrams could be used to model user interfaces, and automatic CASE tools could help to generate code for user interfaces from UML designs. In general terms, visual modelling allows the developers to visualize source code in a graphical form: graphical abstractions, such as flow charts to depict algorithmic control flows and structure charts or simple block diagrams with boxes representing functions and subprograms, and so on. UML provides system architects with a visual language for specifying, constructing and documenting the artefacts of software systems. In particular, user interfaces should be visually modelled in order to describe the behaviour of the window system in response to user interactions.
BACKGROUND
In the literature there are some works dealing with the problem of user interfaces in UML.
Use Cases and UI Design
Some of these works (Nunes & Falcao, 2001) (Paterno, 2001) (Constantine & Lockwood, 2001) are focused on the utilization of UML use case diagrams as “starting point” of the user interface design, or even as a “high-level description” of the structure of the user interface. However, there are some considerations about the use case diagram style. Following the UML philosophy, a use case diagram could not be suitable for extracting the user interfaces. Use case diagrams may include some use cases referred to parts of the system not related to user interfaces, such as classes, human tasks, components of other systems interacting with us, and so on. Or even, decomposing use cases by means of include and extend relationships, one could specify specific parts of the system which are not related with the user interface. Therefore, in our opinion, a specialized version of the use case model could be required, or even some other UML diagrams could be used to complete the use case view.
Adapting UML to UI Design
Other works (Heumann, 2003) (Nunes, 2003) (Nunes & Falcao, 2001) (Campos & Nunes, 2005) (Conallen, 1999) (Liberman, 2004) propose the introduction of new UML elements in order to model user interfaces. In this case, it is well-known the need of new stereotypes or classifiers in UML in order to distinguish GUI components from other system components. In this case, tere is a common point of view: classes should be stereotyped with <<screen>>, <<applet>>, <<input form>>, to be distinguished from data classes.
Code Generation and UML
With respect to code generation, unfortunately, the capabilities of code generator CASE Tools to transform design to an implementation are often restricted to produce class definitions consisting of attributes and operation signatures captured in class diagrams, but not methods to implement the procedural flow within the operations. Existing approaches in this last sense turn statecharts into executable code. Statecharts are used as object controllers for specifying when an object is willing to accept request. CASE tools supporting code generation from statecharts are Statemate (Ilogix, 2006), Omate (Harel & Gery, 1997), Rhapsody (Ilogix, 2006) and Fujaba (Schäfer, 2002).
ORGANIZATION OF THE CHAPTER
The next section describes our model-driven development technique for User Interfaces. The chapter continues with the technique for the code generation by using user-interface models. This chapter finishes with some conclusions and future work.
MODEL-DRIVEN DEVELOPMENT FOR USER INTERFACES
Use Case Diagrams
Use case diagrams are used as starting point for user-interface design. Use cases are also a way of specifying required usages of a system, and they are typically used for capturing the requirements of a system (that is, what a system is supposed to do). The key concepts associated with the use-case model are actors and use cases. The users and systems that may interact with the system are represented by actors. Actors always model entities that are outside the system. Use cases represent the set of tasks that the actors carry out. In addition, the “use cases” can be decomposed by means of include relationships, and they can also be related by means of generalization/specialization relationships that compare more general and particular tasks.
User interaction Diagrams
The second modelling technique in our framework is the activity diagram. However, we need to specialise the activity diagram for user interface design in the following sense.
Our activity diagrams include states and transitions. The states represent data output actions, that is, how the system responds to user interactions showing data (or requesting them). Then the user can introduce data, and the corresponding event is handled, and specified by means of transitions. Transitions can be conditioned, that is, the handled event is controlled by means of condition, which can be referred to data/business logic or a previous user interaction. In other words, it is possible more than one transition from a state, and to know which of them will run depends on data/business logic or the previous user choices. We call user-interaction diagrams to this kind of activity diagrams used for user interaction description.
User Interface Diagrams
Therefore, in our technique we have obtained a use case diagram together with a set of user-interaction diagrams, from which some correspond to use cases and others to states of use cases. However, it could be useful to have a new version of the use case diagram, to know what are the main user-interaction diagrams, that is, which are the user-interaction diagrams corresponding to use cases, and which are the secondary user-interaction diagrams, that is, which are states of use cases. For this reason, we will build a new version of the use case diagram, called user-interface diagram as follows. The user-interface diagram contains the same actors, and use cases of the use case diagram. In addition, we will add states (as use cases) of each use case corresponding to user interaction diagrams. In order to connect use cases, we will use the “include” or “generalization” use case relations.
GUI Class Diagram
The next step of our model-driven technique consists of the building of a class diagram for GUI components. The user-interface diagrams obtained in the previous state give us the main windows. Each use case connected to an actor can be converted into a window, and if an actor is connected to more than one use case, it can be considered a window by the actor that invokes (or embeds) each window of each use case.
Therefore, the actor window can be a menu window. In addition, in the user-interaction diagrams obtained from use cases, we have also described input and output components for data output and request and user events. It gives us the GUI components for each window. If a user-interaction diagram has a state described by means of another user-interaction diagram, we can suppose that the window of the use case could also contain a separate window for this separate task. However, now, we have to take into account the user-interface diagram and the use case relationships. In the case of inclusion, the logic is also separate, and it is possible to consider a new window. However, in the case of generalization/specialization, the window corresponds with a specialization, and therefore it is better to consider a new window by using the inheritance relation.