UML Activity Diagrm Semantics and Automated GUI Prototyping

Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration, and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e., workflows), as well as the data, flows intersecting with the related activities.

ABSTRACT

Extended Activity Semantics (XAS) is a notation which can be used with Unified Modeling Language (UML) activity diagrams to specify user interactions with a system and to automatically generate a prototype of the graphical user interface (GUI) that would be used in these interactions. XAS has been incorporated in a CASE tool, Guibot, which has been developed as a plug-in for Rational Rose, a leading UML tool. The notation and tool address a specific gap in UML – the inability to model user interaction.

INTRODUCTION

While we are not likely to find a silver bullet to solve all of the problems of the system development lifecycle (Fedorowicz, 2004), a tool which speeds prototype development and adds precision to design specifications has promise for addressing problems in the requirements elicitation phase of the lifecycle. Extended Activity Semantics (XAS) is a notation which can be used with Unified Modeling Language (UML) activity diagrams to specify interactions with a system in a succinct style. XAS can be included in a modeling tool to automatically generate a graphical user interface (GUI) prototype. The notation and tool address a specific gap in UML – the inability to model user interaction.

LITERATURE REVIEW OF CURRENT APPROACHES

USED IN REQUIREMENTS ELICITATION

Most phased, iterative system development methodologies recognize that involving users as much as possible, preferably continually, throughout the system development process is key to successful elicitation of requirements (Hoffer, George, & Valacich, 2005). It is the requirements elicitation process with which this paper is particularly concerned.

Two main approaches are used to represent the elicited requirements and communicate them back to the users – modeling and prototyping. Prototyping user interfaces has been recognized as particularly effective in improving communication between the user and developer, and results in an improved final product (Phillips & Kemp, 2002; Hoffer et al. 2005). Seffah and Andreevskaia (2003) state that creating effective prototypes to model screen layouts and user interaction is a skill needed by software engineers to effectively conduct user-centered design, which aims at increasing usability. Effective as prototypes are for communicating, however, they are not a substitute for precise modeling.

Object-oriented techniques are recognized as powerful, and the Unified Modeling Language (UML) is emerging as an apparent modeling standard, but thus far it has not solved all modeling problems. Rational Rose is a UML-based modeling tool which can represent many types of detailed system requirements and behaviors.

Several problems are inherent in software modeling when addressing the end-user concerns. First is the problem of level of detail. Some diagrams, like sequence diagrams, can capture an enormous amount of detail, but are difficult for users to understand. If users cannot understand the diagram, they cannot confirm that requirements have been correctly understood by software developers (Wilcox, 2003). Other simpler diagramming techniques, such as use case and activity diagrams, may be easier for the user to understand, but do not capture sufficient detail to actually build a correctly functioning system (Phillips, Kemp, & Keck, 2001). Worse yet, modeling the user interface, which is the part of the system the user best understands and can best give feedback on, is not directly supported in UML (Scogings & Phillips, 2001, Meehan & Carr, 2005).

Prototyping is not without problems either. The most obvious problem is the time and expense that is required to build a functional prototype (Mannio & Nikula, 2001; Phillips & Kemp, 2002). Once the time and expense has been expended to create a functional prototype, there is a tendency on the part of both the developer and the user to commit to the technology and interface represented by the prototype, rather than exploring more options (Phillips & Kemp). Beyond these practical difficulties, which might be overcome with enough time and money, is the fact that prototypes generally provide fairly static screen shots, and simply do not give an easily understood dynamic view of the workflow involved in a process (Phillips and Kemp, Meehan & Carr, 2005). Because the prototypes do not provide clear understanding of the processes being modeled, users can come away from the design process with inaccurate expectations about how the system will behave in the workflow (Mannio & Nikula, Phillips & Kemp, Meehan & Carr), and developers can wind up building a system based on incorrect requirements.

Even when developers utilize both prototyping and modeling tools, they can, and frequently do, still have problems effectively capturing correct system specifications and communicating them to their users. The problem is that, although designers may build prototypes and create models, there is no built-in way in UML to link the prototypes to the models in a way that accurately describes the processes and workflow in sufficient detail. What is needed is a link between user-intuitive prototypes and models capable of capturing adequate detail. Phillips, Kemp and Kek identified the need to model user tasks “within the context of the visible interface” (2001, p. 49). In other words, while it is important to model tasks and behaviors and their attendant detail, there needs to be available a visual prototype of the user interface that users can refer to ensure understanding.