User Interface Modeling Within Application System Development Vjeran Strahonja University of Zagreb Faculty of Organization and Informatics Varaždin
[email protected]
Ruben Picek University of Zagreb Faculty of Organization and Informatics Varaždin
[email protected]
Abstract. A well-designed user interface, nowadays exclusively graphical, is one of the key factors determining the application's appeal to the user. GUI modeling should be a part of the overall process of application system development. The aim of this article is to show different methodological approaches to the GUI modeling. Nowadays, UML is a widely used standard for object-oriented modeling software in the software industry. The paper investigates whether it is possible to successfully model GUI by using UML and suggests a way in which this can be achieved. by using some UML extensions without disrupting the standardization. Keywords. GUI modeling, UML, objectoriented development, UML extensions
1. Introduction Graphical User Interface (GUI) is a computer program that displays or facilitates the display of text and on-screen options, usually in the form of pictorial symbols (icons) or menus, by means of which users may enter commands by using a mouse or a keyboard as an input device. Elements of a GUI include features such as windows, pull-down menus, icons, push buttons, scroll bars, multimedia wizards and others. A well-designed user interface, nowadays exclusively graphical, is one of the key factors determining the application's appeal to the user. The user finds the graphical interface to be an equivalent of the application system, rather than diagrams, documentation, a well-defined database or the code. However, modeling and designing a GUI is frequently not given its due
attention. This task is neglected in certain software development methodologies. Unfortunately, this usually results in the failure to elicit requirements concerning the user interface. The interface is rarely modeled; rather, it is designed by the programmer during the construction phase. Therefore, the programmer simultaneously acts as the designer as well, with a minimum contribution from the part of the user. GUI modeling should be a part of the overall process of application system development. Naturally, this should be handled carefully, in order to ensure that the appropriate methodology is selected, so that its development process includes segments of GUI modeling in detail. The basis of most, or indeed all of currently existing object-oriented methodologies, also recognized as the standard in application system development, is UML – a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system, as well as for modeling business processes. Experience has shown that individual organizations and problem domains require specific development processes. Therefore, UML is independent from the development process. Many authors, however, as will be demonstrated in this paper, claim that UML does not provide sufficient support for GUI modeling. It is the aim of this paper to examine the benefits of applying UML concepts and diagrams in GUI modeling. In the opening sentences of this paper, the importance of GUI modeling, often not recognized, has been pointed out. Consequently, the following issues seem to be particularly relevant:
1. If UML is a standardized language for system modeling, and GUI development is a constituent part of application system development (a very important one), is it possible to use UML as a language for modeling the graphical user interface, its elements and their links with the remainder of the application? 2. How to model GUI by applying UML, if this language has no predefined concepts or diagrams for GUI development? 3. Is it possible to develop GUI by means of the existing UML concepts and diagrams, or it requires an additional set of missing concepts and diagrams, which should be integrated into UML? These are some key issues which will be addressed in this paper.
2. GUI Development and "Structured" Methodologies The history details the evolution of computers and human-computer interaction and user interface design in several phases. The first implementations of user interface design methods are dated back in the early 1970s, to the dumb character terminal era. This was an early on-line application era with Ad-Hoc or no methods development process, while formal development techniques were yet to be developed. Human-computer interaction was based on hierarchical menus, table and formfilling screens. Many system developers and researchers support the need for a methodology for information systems development in order to establish a productive software development environment. The final result was development and implementation of structured methodologies, such as Information Engineering – IE [8], Structured Systems Analysis and Design Methodology SSADM [5] and other [16]. These combine the data and process orientations into a multiple perspective approach. SSADM is good example how structured methodologies handle and integrate user interface design. SSADM is a methodology developed in the early 1980s, used in the analysis and design stages of systems development. In 1983, SSADM was declared as the standard to be applied for government computing projects in the UK Since then, it has been permanently upgraded. SSADM may be implemented without any license fee to pay and is frequently used as
the basis of organization-specific standards for application development. SSADM uses a combination of text and diagrams throughout the analysis and design, but it does not cover the construction, testing and implementation of software. The current release of SSADM is version 4.3, which was launched in 1996 and is targeted at the development of applications with graphical user interfaces. SSADM breakdown consists of modulestage-step-task structure: - Stage 0: Feasibility Study - Stage 1: Investigation of Current Environment (Requirements Analysis Module) - Stage 2: Business System Options (Requirements Analysis Module) - Stage 3: Definition of Requirements (Requirements Specification Module) - Stage 4: Technical System Options (Logical System Specification Module) - Stage 5: Logical Design (Logical System Specification Module) - Stage 6: Physical Design (Physical Design Module). SSADM's default structural model has GUI design as part of Stage 3 Definition of Requirements (Step 330: Derive System Functions; Task: Develop GUI Prototype, Produce GUI Design). A specification of the GUI can help in identifying and confirming user requirements. However, by including GUI Design in Stage 3, there is a serious risk of overloading this stage in terms of delays and the amount of user resource required. Therefore, an equally valid approach is to leave GUI Design until either Stage 5 Logical Design or Stage 6 Physical Design. Components of the User Interface Design are: - Window Navigation Model - This defines the windows and navigation options which are available to users in carrying out on-line functions. - Window Specifications -These define the windows in the interface. - Help System Specification - This defines the help system which will be implemented to assist users in using the application. The extent to which the GUI design is documented depends on the particular components of the GUI. In some cases, it may be that a hand-drawn sketch of a window or a dialog design model. With regard to possible notations see [9 p. 311].
However, more complex GUI windows will require a detailed GUI prototype. The purpose of prototyping is to demonstrate that the requirements have been properly understood rather to produce a working version of the system. 3. Benefits of UML application in GUI modeling Like all other structured methodologies, SSADM methods and models are entirely separate from the physical code. Changes to the code were not always reflected in the model, and vice versa. SSADM also isolates GUI development from the development of other components. The proprietary nature of recent ‘round-trip engineering’, built into object-oriented methodologies and tools, means that changes to the code are immediately reflected in the model, and vice versa. The basis of most or indeed all of currently existing object-oriented methodologies is UML Unified Modeling Language. UML has been adopted in November 1997 by the Object Management Group (OMG) as their standard for expressing object-oriented analysis, design modeling and documenting object-oriented and component-based system architectures. UML is a standard with far greater market penetration, so models from one developer or one tool can be read and manipulated by other developers and within different modeling tools. Many authors, however, as will be demonstrated in this paper, claim that UML does not provide sufficient support to GUI modeling. Is it possible to use UML as a language for modeling the graphical user interface, its elements and their links with the remainder of the application? At a first glance, this should be possible, since GUI is normally an object-oriented environment. Similarly, modern object-oriented software development processes are based on UML (as a unified modeling language); some of them additionally define the GUI development model, in the early phases of application system development. Yet, what is it really like? Paulo Pinheiro da Silva and Norman W. Paton [12] point out that UML is a standardized language for object-oriented modeling and therefore they assume that the user interface, as a
vital part of contemporary application systems, should be able to be modeled by means of UML. Actually, UML is a logical choice as a notation for GUI modeling. However, in the remainder of the paper they point out that it is not completely clear how exactly this is supposed to be achieved. This can be complemented by opinions of some other leading authors on this issue. Scott W. Ambler is rather critical when he addresses the issue of GUI modeling by means of UML. He proposes a new diagram to enhance GUI modeling. In his reference to UML 2 in his article [2], he points out that even in the revised version of UML 2.0 certain flaws related to GUI development still have not been eliminated, owing to the lack of concepts of its development, albeit according to him a few methodologists, such as Craig Larman, Jim Connalen, Geri Winters and Ambler himself, have proposed several approaches to modeling the user interface flow based on UML. In spite of that, no effort has been officially put into developing a unique profile to be incorporated into UML. He concludes that all of the above presents a serious problem, considering that a GUI is virtually equivalent to the application system for most users; this problem should have been eliminated in this version of UML. Chris Phillips, Elizabeth Kemp and Sai Mei Kek state in their paper [10] that UML provides insufficient support to GUI development, and therefore propose to use cases to be complemented by activity diagrams and certain prototyping steps. Paulo Pinheiro da Silva and Norman W. Paton deal with this issue in detail and they confirm the fact that UML lacks concepts for GUI modeling in several of their papers. In one of their papers [13], they state that there are numerous examples of industrial and academic projects demonstrating the benefits of UML in application system development. Nevertheless, a majority of these successful projects fail to specify any issues related to GUI design; only certain aspects of GUI architecture are covered by these projects. In another paper [12], they point out that it is still not clear how to identify GUI elements and model the user interface. In addition, they emphasize the need for a unique notation which would encompass the overall object-oriented GUI design. Scogings and Phollips [15] argue that UML provides hardly any support for GUI modeling, which they find surprising, as GUI has recently
been gaining an increasing importance. Such stances have been confirmed by other authors in their papers. These are but a few opinions leading us to conclude that: - GUI modeling is a significant segment in application system development - UML does not specify details of GUI modeling - there are differing approaches to using UML to enhance GUI development - in the course of GUI development by means of UML, problems have been encountered owing to a lack of concrete concepts concerning GUI. How to model GUI by applying UML, if this language has no predefined concepts or diagrams for GUI development? This is best achieved by means of extension mechanisms (stereotypes and tagged values) applied to the existing diagrams: class, interaction (sequence and collaboration), statechart and activity, which also need to be stereotyped. UML provides no specific concepts or diagrams for developing user interfaces and connecting them with business classes or the application system itself [15 p.74]. Yet, it contains extension mechanisms enabling certain stereotypes to be created on the basis of the existing elements – in other words, a mechanism allowing the existing UML elements to be renamed by giving them a new meaning and visual appearance, and tagged values – a mechanism allowing other qualities to be granted instead of attributes. However, it remains to be answered which diagrams are suitable for GUI modeling? Following diagrams are used by several authors in individual segments of GUI modeling: David Anderson states in his paper [3] that GUI windows (static view) should be represented by navigation maps. Apparently, many authors so far, such as Larry Constantine and Lucy Lockwood [4], have been creating navigation maps based on UML class diagrams, thus proposing their own stereotypes. The author claims that all of the above mentioned approaches to creating navigation maps are sound, but at the same time they are not detailed enough to provide the sufficient expressiveness for the overall modeling of windows.
For dynamic view – flow of windows, the author proposes the application of UML statecharts. He acknowledges that the practical application of a statechart in the form taken at each particular moment shows that they are not fully appropriate for GUI modeling. Chris Phillips and Elizabeth Kemp analyze in their paper [10] the importance of applying a use case diagram as the starting point in GUI modeling. They find it particularly useful and therefore propose that use case description in the early phases of GUI modeling be complemented with activity diagrams, which would result in a clear representation of interaction sequences (including the parallel ones), as well as the overall flow described in a narrative form. Apart from that, the authors propose including GUI elements into use cases, which these authors consider to be unnecessary, particularly when complex systems are being developed, since in the course of use case description it is not possible to foresee the visual appearance of GUI. It is only in proceeding from the phase of analysis to the phase of design that the appearance is defined. The creation of the prototype will be later based on that appearance. Scott W. Ambler suggests in his book on modeling the dynamic flow of windows [1] the design of "Interface-Flow Diagrams". Additionally, on his web pages [17], [18] he emphasizes that using components diagram, proposed by some authors [14], is not used for GUI modeling. Instead, he suggests that it is preferable in GUI modeling to use modified statecharts or activity diagrams, or interaction diagrams of both sequence and collaboration, which he had personally used before developing his own diagram. Ben Lieberman extensively discusses in his article [7] the application of UML activity diagrams in showing the flow of windows. He considers that these diagrams are best suited for representing actions the user undertakes while interacting with GUI. Besides, he argues that a few carefully selected stereotypes – which he introduces into activity diagrams – provide the basis for the description of GUI dynamic flow. As Lieberman claims, he is not the first author to propose the modification of UML semantics in GUI modeling, he compares his own proposal of GUI dynamic flow modeling by means of activity diagrams with the approaches taken by David Andersen and Scott W. Ambler, which have already been discussed.
He is of the opinion that activity diagrams are much more natural than state diagrams, and that user actions, by which windows are initiated in Scott's "Interface-Flow Diagrams" can also be shown in activity diagrams. Finally, Craig Larman's method [6] of GUI modeling should be discussed. It is mentioned in this paper, in order to demonstrate how GUI modeling works in practice. Larman starts by creating an "essential UI informational model", representing windows by Post-It® stickers, on which controls are defined. He defines a navigation model of the flow of windows by using a UML state chart. However, rather than drawing it by a CASE tool, he uses a whiteboard, since, according to him, that tool distracts him more than it aids him. Once a model has been developed, it is photographed. Both models are developed simultaneously. On the basis of this analysis it can be concluded that: - use cases are the starting point in GUI modeling, - UML provides no special diagrams for GUI modeling, so UML extension mechanisms – stereotypes of individual UML elements and diagrams – should be applied in GUI modeling, - for the dynamic view – flow of windows – certain stereotype diagrams, such as activity diagrams and interaction diagrams, are more suitable than other diagrams, such as statecharts, and some of those are entirely unacceptable, for example components diagrams. Is it possible to develop GUI by means of the existing UML concepts and diagrams, or it requires an additional set of missing concepts and diagrams, which should be integrated into UML? The approaches discussed above show that the existing UML diagrams, which need to be stereotyped, make possible the modeling of the user interface. However, the question remains how successful the result achieved can be? 4. The Development of an Abstract Model of GUI Representation In order to show how it is possible to UML in GUI modeling, it is necessary to methodology involving a UML based development. Consequently, steps of
apply use a GUI GUI
modeling are encompassed within RUP development process. GUI at an abstract level will be modeled through the following steps: - identifying GUI details in use cases - determining abstract windows in use cases - defining windows - modeling window diagrams for use cases - modeling window interaction for use cases by means of a diagram of window flow. All of the above indicates that the application of this model is of a major significance in the course of the development of a graphical user interface within the overall application system development. Therefore an abstract model of graphical user interface representation has been developed by applying the existing diagrams and UML extension mechanisms. The starting point of the model are well-described use cases (with usability aspects and requirements) and user's profile. Below is an example of one use case which include details of user interface: USE CASE: Bid on Item ACTOR….(define his profile: frequency of use, computer experience, environment, users…) FLOW OF EVENT: Basic flow (BF) 1. BID: … 2. ENTER AMOUNT: … 3. BUYER CONFIRMS BID: … 4. POST BID: … 5. SENT E-MAIL:… 6. SYSTEM CONFIRM BID:… Alternative flows (AF) 1. AUCTION IS CLOSED: 2. BUYER HAS PENDING PAYMENTS: 3. ENTERED BID IS INVALID: 4. BID NOT CONFIRMED: SPECIAL REQUIREMENTS: Usability: Basic flow (BF) 1. BID: {picture of the bid item should be visible even in a large format and in high resolution} 2. ENTER AMOUNT: [the system should be able to offer at least three more bids incremented by the minimum bid amount] 3. BUYER CONFIRMS BID: {information on the legal obligations of placing a bid amount to approximately 150 characters}. The Buyer should confirm his/her bid by a click of the mouse within 15 seconds, which should be clearly displayed. 4. POST BID: The system should be able to update the current bid within 5 seconds after the Buyer has confirmed his/her bid. 5. SEND E-MAIL: 6. SYSTEM CONFIRM BID: The system should be able to display the confirmed and accepted bid offered to the Buyer within 2 seconds. Alternative flows (AF):…
Although UML was originally developed for modeling objects, it contains certain extension mechanisms. One of these mechanisms is a stereotype, a mechanism which makes it possible for the developer to rename the existing UML element by attributing it a new meaning and a new visual representation. Out of the three class stereotypes, for the abstract view of windows or reports, the predefined stereotype shown in Fig. 1. can be used. a Window
a Window
a Window
Figure 1. Visual representation of the stereotype This stereotype is used to model interaction between the system and its environment – actors. The static description and the windows interconnection within each individual use case is modeled by a stereotyped class diagram, called window diagram. This diagram is suitable for the initial GUI design and it can be used in evaluating the usability of the interface. The dynamic flow of windows described in use cases, including the flow of windows, is represented by stereotyped interaction diagrams called window flow diagrams. These are used to show the interaction between the user and the system through windows, i.e. how the use case has been implemented by the windows to be used. The diagram makes it possible to analyze the efficiency of the window's initial design.
5. Conclusion A well-designed user interface, nowadays exclusively graphical, is one of the key factors determining the application's appeal to the user. So GUI modeling should be a part of the overall process of application system development. Naturally, this should be handled carefully, in order to ensure that the appropriate methodology is selected, so that its development process includes segments of GUI modeling in detail. This paper demonstrates the importance of GUI modeling within the overall application system development. It can be concluded that GUI modeling is indeed essential in any application system development, and that GUI design should not be postponed until the final phase of the system development – its implementation – letting the
programmers "deal with it" as best as they can; it should rather be modeled, and its development incorporated into each application system development phase. Today, UML is a widely used standard for object-oriented modeling software in the software industry. The aim of this article is to show whether it is possible to successfully model GUI by using that language and suggest a way in which this can be achieved. Some experiences in the field as well as contemporary views on GUI modeling by means of UML have been briefly presented, with certain flaws of UML pointed out. Some UML extensions are suggested aimed to increase the specification and cognitive values of the object model without disrupting the UML standardization. Although this paper may suggest that it is possible to model a graphical user interface by means of the existing UML diagrams and the extension mechanisms, these authors believe that it would be useful for UML to contain a single diagram containing the final, standardized set of all GUI concepts. Such a diagram would naturally be connected with the existing diagrams, in order to encompass the overall modeling of the graphical user interface.
6. References [1] Ambler SW. The Object Primer 3rd Edition: Agile Model Driven Development with UML 2, 2003, Chapter 6 [2] Ambler SW. What’s New in UML 2, Software Development, February 2004 [3] Anderson JD. Extending UML for UI, SprintPCS.com, Kansas City, Missouri, 2000 [4] Constantine L, Lockwood L.: Software For Use, ACM Press, 1999 [5] Downs E, Clare P, Coe I. Structured Systems Analysis and Design Method, Prentice Hall, Englewood Cliffs, N.J., 1988 [6] Larman C. "RE: GUI-modeling" 11th February 2004. Personal e-mail [11th February 2004]. [7] Lieberman B. UML Activity Diagrams: Detailing User Interface Navigation, The Rational Edge, October 2001 [8] Martin J, Finkelstein C. Information Engineering, Savant Institute, 1981 [9] Martin, J. Recommended Diagramming Standards for Analysts and Programmers: A
Basis for Automation, Prentice Hall, Englewood Cliffs, N.J., 1987 [10]Phillips C, Kemp E, Kek SM. Extending UML Use Case Modelling to Support Graphical User Interface Design, Melbourne, 2002 [11]Phillips C, Kemp E. In Support of User Interface Design in the Rational Unified Process, Melbourne, 2002 [12]Pinheiro da Silva P, Paton NW. User Interface Modelling with UML, in Information Modelling and Knowledge Bases XII, 2001, Amsterdam, IOS Press [13]Pinheiro da Silva P, Paton NW. Improving UML Support for User Interface Design: A Metric Assessment of UMLi, Proceedings of ICSE-2003 Workshop on Bridging the Gaps
Between Software Engineering and HumanComputer Interaction, Portland, OR, USA, 2003, IFIP [14] Schmuller J. Sams Teach Yourself UML in 24 Hours, Sams Publishing, 1999, Ch.24 [15]Scogings CJ, Phollips CHE. Linking tasks, dialogue, and GUI design: a method involving UML and Lean Cuisine+, Interacting With Computers, 2001 [16]Strahonja V, Varga M, Pavlic M. Projektiranje informacijskih sustava, Zavod za informaticku djelatnost Hrvatske i INAINFO, Zagreb, 1992 [17] www.modelingstyle.info/component Diagram.html [18]www.agilemodeling.com/artefac
