1. SUIP in a Nutshell

SUIP aims to support the step of requirements engineering in the development of information systems. It offers a UML-compliant framework for verification and validation using scenarios as a vehicle. SUIP allows linking UML models with UI prototypes. It implements algorithms for deriving a prototype of the UI from scenarios and generating a formal specification of the information system. Scenarios are acquired in the form of UML collaboration diagrams and are enriched with UI information. These diagrams are automatically transformed into partial Statechart specifications of all objects involved. These partial specifications are then merged to obtain global object specifications, and an algorithm is applied on them to generate a UI prototype. The prototype is embedded in a UI builder environment for further refinement. Based on end user feedback, the collaboration diagrams and the UI prototype may be iteratively refined, and the result of the overall process is a specification consisting of the Statechart diagrams of all the objects involved, together with the generated and refined prototype of the UI.

SUIP consists of several algorithms corresponding to distinct activities in the process of deriving UI prototypes from scenarios. Figure 1 gives an overview of this iterative process at a high level; Figure 2 shows more details about some activities of the process.

Data specifications (see Figure 1) are captured in a detailed Class Diagram (ClassD) which shows structural relationships between classes, and specifies class attributes and methods together with pre- and postconditions. This information is used for scenario acquisition via Collaboration Diagrams (CollDs), and for prototype generation to enhance the visual aspect of the generated prototypes. User interface specifications are derived from scenario descriptions, and are used for both generation of UI prototypes and for specification verification (verifying coherence and completeness of the UI specification). The generated prototypes are evaluated with end users to validate the user needs.

Figure 1: View of the overall process combining formal specification and UI prototyping.

Figure 2: The five activities of the UI prototyping process.

1.1 Requirements acquisition

In this activity, the analyst first elaborates the ClassD of the system, and for each class of the ClassD, a detailed analysis can be done by identifying attributes and methods and defining pre- and postconditions. Secondly, the analyst elaborates the UsecaseD for the system. Finally, the analyst acquires scenarios as CollDs for each use case in the UsecaseD.

Scenarios of a given use case are classified by type and ordered by frequency of use. We have considered two types of scenarios: normal scenarios, which are executed in normal situations, and scenarios of exception executed in case of errors and abnormal situations. The frequency of use (or the frequency of execution) of a scenario is a number between 1 and 10 assigned by the analyst to indicate how often a given scenario is likely to occur.

1.2 Generation of partial specifications from scenarios

In this activity, we apply repeatedly on each CollD of the system the CTS (CollD To StateD) algorithm, in order to generate automatically partial specifications for all the objects participating in the input scenarios.

1.3 Analysis of partial specifications

The partial StateDs generated in the previous activity are unlabeled, i.e., their states do not carry names. However, the scenario integration algorithm is state based, requiring labeled StateDs as input. To obtain labeled StateDs, our approach uses the pre- and postconditions of the underlying ClassD to add state names and structuring information (grouping states). Given an unlabeled StateD, its state names are identified via the preconditions of outgoing and the preconditions of incoming events. Note that the events in a StateD correspond to the methods of its underlying class. Furthermore, structural information like grouping states may also be added.

1.4 Integration of partial specifications

The objective of this activity is to integrate for each object of the system all its partial labeled StateDs into one single StateD. At first, we proceed by merging the StateDs by use case, and afterwards we merge the StateDs of the different use cases. This integration in two steps is required for the activity of UI prototype generation.

1.5 User interface prototype generation

In this activity, we derive UI prototypes for all the "interface objects" found in the system. Both the static and the dynamic aspects of the UI prototypes are generated from the StateDs of the underlying interface objects. For each interface object, we generate from its StateDs, as found in the various use cases, a standalone prototype. This prototype comprises a menu to switch between the different use cases. The different screens of the prototype visualize the static aspect of the object; the dynamic aspect of the object maps into the dialog control of the prototype. In our current implementation, prototypes are Java applications comprising each a number of frames and navigation functionality.