UML Modeling of User and Database Interaction - INFORMATION ...

The Computer Journal Advance Access published May 21, 2008 # The Author 2008. Published by Oxford University Press on behalf of The British Computer Society. All rights reserved. For

Permissions, please email: [email protected] doi:10.1093/comjnl/bxn028

UML Modeling of User and Database Interaction J ESU´S M. ALMENDROS-J IMEŃEZ1

AND

LUIS I RIBARNE2,*

1 2

Information System Group, University of Almerıá, 04120 Almerıá, Spain Applied Computing Group, University of Almerıá, 04120 Almerıá, Spain *Corresponding author: [email protected]

In this paper, we will present a design technique for user and database interaction based on UML. User interaction will be modeled by means of UML state diagrams, and database interaction by means of UML sequence diagrams. The proposed design technique establishes how to integrate both diagrams in order to describe the user interface and database interaction of a business software system. A case study of an Internet Book Shopping system will be shown to illustrate the proposal. Keywords: UML; software modeling; human–computer interaction; model driven development Received 7 September 2007; revised 26 February 2008

INTRODUCTION Domain-specific modeling (DSM) [1] is a way to design and develop systems that use Domain-specific languages (DSLs) to model the different elements of a software system. Such systems focus on higher-level abstractions and models, and architects work with domain concepts. A DSM environment allows us to specify constructs and rules for modeling a target domain. Examples of DSM environments are MetaEditþ or Eclipse. On the other hand, Model-driven development (MDD) is a framework of techniques for software design based on visual modeling. The advantages of software design based on MDD have been recognized by several authors [2–5]. MDD has arisen in the context of the Unified modeling language (UML) [6]. UML provides a visual language for the description of the artifacts of a software system. UML is a modeling language suitable for high-level modeling in which constructions can be mapped into code with the help of Model transformation tools [3, 5], integrated in a DSM environment. UML is a visual language equipped with a rich set of diagrams. Each kind of UML diagram provides a different perspective of the system to be developed. For instance, use case diagrams are suitable for requirement capture, state diagrams describe system states and transitions to be triggered for state changes and sequence diagrams are intended to be used for object-interaction design: message exchange and execution threads. A DSM environment should provide architects support for developing business applications in which user interactions

and database interactions are the main tasks. In addition, MDD techniques can be used for business software modeling. User interactions are achieved by means of user interfaces, in which interactions can be classified into input and output interactions. In addition, user interactions are accomplished by means of client or server-side processes. Client-side processes usually handle user interface components and serverside processes usually involve database interactions. Database interactions consist in data requesting (and data updating) from (to) a database server. Database interactions are usually due to user interactions. Database interactions involve client-side processes (user interface components updating) and server-side processes (database updating and requesting). In a typical client-server application the user interacts with the system through a user interface. Typically, this interface can consist in static (i.e. HTML documents), active (i.e. Applet, Javascript) or dynamic (i.e. JSP, PHP, CGI) technologies in which there is an interaction with a database. Modern user interface technologies (Web 2.0) have the capability of storing information about user interaction at the client-side: some user interface components are containers storing particular data for each user. For instance, a shopping system stores the user shopping cart during the purchase process. In such a context, a suitable software architecture should separate concerns such as the presentation logic, navigation/ interaction, business logic and workflows, and database transactions. One of most relevant proposals for such an

THE COMPUTER JOURNAL, 2008

Page 2 of 20

J. M. ALMENDROS-JIMEŃEZ

architecture is the Model-view-controller (MVC) pattern [7]. The MVC pattern is a design pattern for the organization of user interface programs. In MVC the model components handle the state of objects used by the user interface. The view components are responsible for the user interactions that display the state of the model components. Finally, the controllers handle the user interactions, modifying the state of the models. MVC has been successfully applied for user interface design (see for instance [8, 9]). Following an MVC architecture, the model components are the user interfaces (at the client-side) which interact with the databases (at the server-side). The user interface requests data (with the help of the controller components) from the database and shows (with the help of the view components) to the user the output data. The server executes the request at the server-side and sends the data to the user interface (with the help of the controller components), which can update some user-interface containers with the output data, or can update the database server with the input data. In some cases of user interface technologies, the server sends the user interface to the client properly by dynamically generating the user interface. The previous MVC architecture is complex enough to be considered as a UML profile, and user and database interactions should be modeled in UML in separate diagrams. User interface design has been already proposed as a UML profile in some works [10, 11]. In this context, user interactions, and also database interactions, should be modeled by means of some kind of UML diagrams. UML should be used for describing these kinds of models in detail, and user and database interaction UML views should be integrated. Such a design technique can be integrated in a DSM environment providing UML modeling and model transformation. But now, would the models be consistent with each other? The answer to this question leads us to the definition of a design technique for user and database interactions based on UML, which is the main aim of this paper. Model consistence means, therefore, that each design technique should complement each other according to MDD principles.

1.1.

–

–

–

–

Contributions of the paper

In this paper we will present a design technique for user and database interactions based on UML. User interfaces and user interactions will be modeled in UML by means of class and state diagrams. Databases and database interactions will be modeled by means of class and sequence diagrams. In addition, the use case diagram is used for modeling user requirements. The proposed design technique can be summarized as follows. – We build a use case diagram in which we identify actors and use cases. From each use case we build the so-called

–

AND

L. IRIBARNE

user interaction diagram which is a specialized version of the UML state diagram. In the user interaction diagrams, states represent output interactions (and data requesting) and transitions represent input interactions (i.e. user clicks). Therefore user interaction diagrams represent the dialogue model of the software to be designed. From the set of user interaction diagrams a new diagram called user interface diagram can be built, which is a specialized version of the use case diagram, and describes the set of windows of the system to be developed. In some sense, the user interface diagram can be considered as a user task model given that it represents the set of tasks that the user accomplishes, each associated to a separate window. From the user interaction diagrams, a class diagram can be built representing the so-called user interface class diagram containing the set of user interface components for each window. Once the user interface class diagram is built, we can proceed to build a new class diagram with classes representing the database components, the so-called database class diagram. Finally, we can build the so-called database interaction diagram, which is a specialized version of the UML sequence diagram. The database interaction diagram represents the interactions of the objects. Objects that interact in a database interaction diagram can be classified into user interface objects and database objects. Database interaction diagrams describe how user interface and database components collaborate to accomplish the user tasks. Some use cases can be described by means of user interface objects, and therefore these are client-side use cases. User interface containers can be considered as (small) databases at the client-side. Some other use cases can be described by means of user interface and database objects, and therefore these are server-side use cases. In addition, some database interaction diagrams can be used to describe business logic; that is, some of the objects involved in the database interaction diagrams can achieve business logic tasks. Therefore, database interaction diagrams can be used for describing the manipulation of persistent and non-persistent data in the software to be developed. Database interaction diagrams complement user interaction diagrams in the following sense. User interaction diagrams describe user interface interactions (input and output data) but each user interaction has usually an effect in user interface and database components which is described by means of database interaction diagrams. One of the main contributions of the proposed technique is the correspondence between the use case diagram (use cases and use case relationships) and the UML models developed from the use case diagram. Use case relationships (inclusion and generalization relationships) are also identified in (and mapped into) state and sequence


UML MODELING

OF

USER

AND

diagrams (i.e. user and database interaction diagrams). In other words, we distinguish in our approach more general and particular tasks (i.e. use cases) and inclusion of tasks (i.e use cases). Now, state and sequence diagrams specify the set of states (i.e. sequence of steps) to be achieved for each task (use case) and they can be mapped into the use case relationships.

DATABASE INTERACTION

Page 3 of 20

In the literature there are several proposals for adopting UML for user interface modeling. Some of them also cover database interaction modeling. The kind of user interfaces modeled in UML ranges from traditional WIMP (Windows, Icons, Menus and Pointers) interfaces to Web interfaces including Web navigation. Some of them integrate Web interface modeling with database interaction modeling using UML state and sequence diagrams. Finally, there are UML proposals about combination of state and sequence diagrams in different contexts. Next, we will review the most relevant contributions in these lines.

Although the aim of TERESA project is similar to ours, the approaches are different in both modeling language and rules of design. Partially based on UML, WISDOM (Whitewater Interactive System Development with Object Models) [19–22] is a proposal for user interface design based on UML. WISDOM mainly uses UML but the authors have also adopted the ConcurTaskTrees for task modeling. The domain model in WISDOM captures the objects, and the business model describes each user task and entities involved in such tasks. The business model in WISDOM is represented by the UML use case model and the domain model by means of a stereotyped class diagram. Use case model is completed by state diagrams in order to describe the service that the system offers its users. The design model offers a separation between application level and user interface. The dialog model is specified by means of ConcurTaskTrees. Our model is similar to WISDOM in the use of the use case diagram as a starting point of the user interface design. In addition, a class diagram is also used in our approach for describing objects interacting with the user in the user interface. However, in our approach task/dialog modeling is achieved by means of a specialized version of the use case diagram, completed by means of state diagrams and sequence diagrams, instead of the non-UML diagram CTT. Fully based on UML, UMLi [11, 23, 24] proposes an extension of UML for user interface design. It distinguishes application objects and interaction objects. In our case we also distinguish both. Application objects are described in our approach by means of the database class diagram and the database interaction diagrams. Interaction objects are described in our approach by means of the user interaction diagrams and the user interface class diagram. UMLi proposal is very similar to ours in the adoption of UML diagrams for user interface and task modeling design. However the extensions are different. In our case, we focus more on the use case diagram, use cases and use case relationships. Use case relationship identification and mapping into state and sequence diagrams is one of the most relevant contributions of our proposal.

1.2.1. User interface modeling tools With respect to user interface modeling, in most cases UML is mixed with other non-UML notations. Most recent works have been developed in the context of MDD-based techniques, and there are many relevant proposals with tool support (see [16] for a survey). Among the closest to our work, TERESA [17, 18] (Transformation Environment for InteRactivE System RepresentAtions) is a tool designed for the generation of user interfaces for multiple platforms from task models designed using ConcurTaskTrees (CTT). Our user interface diagram has some similarities with the CTT diagram. By means of the proposed specialization of the use case diagram we might decompose tasks into subtasks, but a more fine and accurate decomposition is reached by means of user interaction and database interaction diagrams.

1.2.2. WIMP and Web modeling With respect to the kind of user interfaces to be modeled, most of UML proposals model traditional user interfaces, those based on WIMP interfaces, but there are recent proposals concerned with the design of modern user interfaces (PostWIMP interfaces) based on hypertext with dynamic content. For instance, there are interesting proposals [10, 25– 30] in the context of UML about user interface design of Web applications. Most cases focus on class diagrams for navigation modeling of Web applications. The most relevant contribution in this framework is [10], in which a rich set of technologies for Web design are used and modeled. Similarly, the work of [29] introduces navigation modeling integrated with sequence diagrams to describe the interaction of user interface components.

Therefore our proposed technique accommodates to the MVC architecture in the following sense. Dialog modeling is described by means of user interaction diagrams; therefore controller components can be described by transitions in user interaction diagrams. In addition, view components are also described in the user interface diagrams and the user interface class diagram. The collaboration between controllers and view components is described by means of the user interaction diagrams and database interaction diagrams. Finally, model components are present in the user interface class diagram and the database class diagram. Our design technique can be considered as an extension of our previous work of user interface design [12 – 14] in which the database interaction view completes the design of a client – server application. In addition, our design technique is influenced by our previous work [15] about the description of use case relationships by means of sequence diagrams. 1.2.

Related work


Page 4 of 20


In our case, we focus on WIMP interfaces; in particular, we have adapted our technique to Java technologies: the Java swing package and the Java Database Connection (JDBC) library. In other words, we have adopted a Java client-server architecture for the system design. However, we believe that it is not a strong restriction of our proposal, and we expect to extend our proposal to post-WIMP user interfaces in the future. In addition, we will partially describe user interface components by means of sequence diagrams, and partially by means of state diagrams. 1.2.3. State and sequence diagrams for UI modeling The use of state diagrams for user-interface design is not new; there are well-known proposals [31], and some more recent ones too [32]. For database interaction modeling there are proposals of using state machines like [33], and that which integrates both (i.e. user-interface and database interaction modeling) can be found in [34]. Although the proposal of [34] relies on such integration, their framework focuses more on Web applications. However, there are some interesting points of the quoted work. First, they distinguish between the entities, from which the presentation unit retrieves the content, and the selectors, which are predicates that describe the objects contributing to the content of the presentation unit. Secondly, they distinguish contextual links connecting two presentation units and noncontextual links that represent links between pages. Finally, they support the specification of services and content management operations requiring write access over the information hosted in a site, and the specification of update operations of entities. Our approach has some similarities with the cited [34] in the way of structuring user interface and database interaction modeling. Entities in our case will be non-persistent containers, and selectors will be specified by means of database interaction diagrams applied to non-persistent containers. In addition, our database interaction diagrams are able to specify the service that the database servers provide to clients (i.e. user interfaces). 1.2.4. State and sequence diagram integration Finally, there are some works in the context of UML where the transformation of state diagrams into sequence diagrams has been studied [35 – 37]. Our work proposes a combination of state and sequence diagrams to describe user and database interaction, and both design techniques are complementary to each other. In other words, rather than transforming one diagram to another, we are more concerned in the description of complementary views of the same artifacts. However, the quoted works have some similarities with our work once they show that the task modeling with state diagrams can be transformed, and therefore complemented by task modeling with sequence diagrams.

AND

L. IRIBARNE

Finally, an interesting proposal in this line is [38], where they provide descriptions of use cases by means of state diagrams, integrated with sequence diagrams. The validation and verification of use case specifications are the main goals of the quoted work. In our case, we are also concerned with the consistence of models represented by state and sequence diagrams for user and database interactions. Basically, the consistence is forced by following a design technique in which a set of rules for a correct design is formulated. Validation and verification of such rules could be included as part of the DSM tool supporting the design technique. 1.3.

Previous work

The proposed design technique has as basis our previous work on user interface modeling [12 – 14] and sequence diagram modeling [15] from use cases. This work presents a significant extension of our previous works by considering (and completing) the user interface view with a database view, in which user interface components interact with database/user interface container components. In our previous papers [13] we were more concerned with the identification of user interface components and modeling of user interactions. However we omitted how the user interface and database components are consulted/updated and how the database interactions are modeled. Here we fully describe these aspects of the proposed design technique. In addition, the main contributions of our proposals was the identification of use case relationships, and how such relationships should be represented in state [12] and sequence diagrams [15]. Following the same ideas as [12, 15], here we will identify use case relationships and we will map such relationships into both design techniques. In addition, in our previous work [14] we were concerned with code generation for user interfaces. Here, we will discuss how the introduction of database interactions could complete the code generation with database code. 1.4.

Structure of the paper

The structure of the paper is as follows. Section 2 will introduce an integrated design technique for user interface and database interactions. Section 3 will present a case study of an Internet Book Shopping (IBS) system, to describe the proposed design technique in detail and will discuss some aspects about code generation. Section 4 will conclude and present future work.

2.

UML MODELING OF USER AND DATABASE INTERACTION

In this section we will present the steps of the proposed design technique for UML modeling of user and database interaction. As case study, we will consider an Internet Book Shopping (IBS) system. Such system describes how Customers and


UML MODELING

OF

USER

AND

employers (i.e. a Manager and an Administrator) interact with the system to accomplish the tasks of purchasing and catalog administration. To illustrate the steps of the proposed technique we will focus on the Customer’s side, in particular, in the Purchase task. A sketch of the steps to be followed is shown in the Fig. 1. The case study will be described in detail in the next section. The proposed design technique can be summarized as follows. 2.1.

Building a use case diagram

The first step of the proposed technique consists in building a use case diagram, in which actors and use cases are identified. For each actor a set of use cases is specified describing each task that each user can accomplish in the software to be developed. Actors and use cases (i.e. tasks) are connected by means of associations. In addition, generalization relationships between actors, and generalization and inclusion relationships between use cases can be identified, respectively. Generalization between actors means that some actors are more general than others: the particular actors add new tasks to more general actors. Generalization between use cases denotes more general and particular tasks. A task is more particular than another whenever the states or steps to be achieved by the task are more particular or the set of states or steps is bigger. Finally, use cases can be compared by means of the inclusion relationship, showing that some use cases are pieces of another use case. In other words, one of the states or steps of one use case is another use case. One of the most relevant contributions of our work is the mapping of use case relationships into state (and sequence) diagrams relationships. In other words, inclusion and generalization of use cases can be mapped into certain elements of state and sequence diagrams. Figure 1 shows a piece of the use case diagram of the case study, describing an association between the actor Customer and the task (i.e. use case) Purchase. 2.2.

Building user interaction diagrams

The second step consists in building state diagrams for each use case. We build a specialized version of UML state diagrams for the description of the user interface. This specialized version is called user interaction diagram. Assuming that each use case (i.e. task) needs a user interface (i.e. window); each window is described by means of a user interaction diagram in which states represent output interactions (and data requesting) and transitions represent input interactions (i.e. user clicks). Output and input interactions are labeled by means of a UML stereotype representing which kind of user interface component will be used for the interaction. In a Java swingbased architecture, they will be buttons, boxes, lists and text area components.


Page 5 of 20

User interaction diagrams can be compared by means of inclusion and generalization relationships. A user interaction diagram is included into another whenever one of the states of the second one is called as the first one. A user interaction diagram is more general than another in two cases. In the first case, the more particular diagram includes one state which is called the more general state and in addition, some input/output interactions are added to this state. In other words, the more particular user interaction diagram adds new interactions to the more general one. Therefore the set of transitions is bigger. In the second case, the more particular diagram includes one state which is more particular than the state representing the more general user interaction diagram. A state is more particular than another whenever the set of substates is bigger or some substates or transitions are more particular. This relationship is more complex than the first one: some user interaction diagrams can specialize states which have been already described by means of another user interaction diagram. The architect of the system is responsible to detect more general and particular states. When the set of states is bigger the detection can be done automatically, but the detection of more particular/general states and transitions depends on the architect knowledge. In our case, we have some specific criteria for comparing states/ transitions. In the context of user interfaces, some user interface components have richer behavior than others, and therefore we can induce specialization/generalization relationships between states/transitions (i.e. user interface components). Figure 1 shows the user interaction diagram of the Purchase use case in the case study, decomposed into three states (i.e. Manage shopping cart, Input card and Input PIN) reached by means of transitions linked to buttons.

2.3.

Building user interface diagrams

The third step of the proposed technique consists in building a specialized version of the use case diagram, called user interface diagram. In this diagram, each use case represents either a task, described in the use case diagram built in the first step, or states in which use cases have been decomposed into user interaction diagrams built in the second step, to which a separate window will be associated. Figure 1 shows a piece of the user interface diagram of the Customer’s side in the case study in which the use cases Purchase, Query catalogue, Shopping cart and Confirm remove article have been associated to system windows.

2.4.

Building user interface class diagrams

The fourth step consists in building the so-called user interface class diagram which contains the set of classes for the user interface.


Page 6 of 20


AND

L. IRIBARNE

FIGURE 1. Steps for UML modeling of user and database interaction.

Each use case of the use interface diagram is supposed to be represented by means of a window. Given that each use case has been described in the previous step by means of a user interaction diagram, we can identify user interface components for each window. Therefore the user interface class

diagram includes classes for each user interface component connected by means of associations to the window class. In particular, some user interface containers have been identified in the user interaction diagrams which are used for storing data in the user interface. User data are non-persistent


UML MODELING

OF

USER

AND

data or client-side data which are handled by means of the user interface at client-side. Therefore the user interface diagram can be seen as the client-side (class) description of the system. Figure 1 shows a piece of the user interface class diagram of the Customer’s side including a class for the Purchase window. 2.5.

Building database class diagrams

The fifth step consists in building a class diagram for the database (or application) components, called database class diagram. From the use case diagram and user interaction diagrams, we can identify which kind of persistent data should be stored in our application. Persistent data are server-side data and will be handled by user interface requesting/updating. We will follow a specific architecture for database design— we believe that some other proposals [39, 40] for database design in UML can also be adopted in our framework—in which there is a root class, usually called database main class, which is a container of table classes, each one for a piece of the whole database. It ensures the data distribution and normalization, but forces that database operations are more complex. In each table class JBDC code is supposed to be embedded. The main class is responsible for the creation and destruction of the table classes, and coordinates the table accesses. Therefore, we assume that data can be distributed; that is, table classes include each a piece of the whole database, and they can be physically distributed. One of the contributions of our work is the description by means of sequence diagrams of not only the database interactions with the user interface but also how databases collaborate in order to supply/update the requested/sent data. Figure 1 shows a piece of the database class diagram in which a realization dependence between the main class (i.e. DB_main) and an interface called ICustomer is described. The window of the customer will be connected to this interface to achieve the customer tasks.


diagram in the first step, later identified in the user interface diagram and also described in the user interaction diagrams. However, the user interaction diagram does not describe how the corresponding containers are updated by user interactions, and in database interaction diagrams they are described. The second kind are those handling persistent data, that is, server-side operations. In this case database interaction diagrams describe how the user interface interacts with the server, and how it requests or updates persistent data. However, some of the steps can refer to user interface components. Typically, the requested data from the server become local to the client. In this case, the database class diagram is used for collecting information about which kind of objects (table class instances) interacts for each request. In both cases, some of the objects can achieve tasks of business logic which can be identified by the architect. The proposed technique builds a database interaction diagram for each transition consulting/updating the data containers of the system—the architect is still free to select which data containers (user interface and database containers) are updated or requested in each transition. We have described our technique by means of six steps. However, they have not to be followed necessarily in this order, and in general the development model can be in spiral: developing some parts of the system and some mistakes can be found leading to a previous step. In addition, some parts of the system can be developed in more detail before other parts of the system have been developed. Figure 1 shows a database interaction diagram corresponding to the purchase process from the customer window, in which there is an interaction with the persistent containers of the database involving the catalog and the customer and customer order database. In addition, the sequence diagram shows how the task consults data from the non-persistent containers included in the customer window (i.e. Input card, Input PIN and GUI_Shopping_Cart).

2.7. 2.6.

Building database-interaction diagrams

The final step consists in building a set of specialized sequence diagrams for the description of user interface and database interactions, called database interaction diagrams. From the user interaction diagrams, the user interface class diagram and the database class diagram, we can build a set of database interaction diagrams. We distinguish two kinds of database interaction diagrams. The first kind are those handling non-persistent data, that is, client-side operations. In this case, database interaction diagrams describe how user interface components are modified by user tasks. Typically, they describe use cases in which the user adds or deletes elements from the containers of the user interface. Such user tasks have been identified in the use case

Page 7 of 20

Tool support

Our design technique involves many rules, naming conventions and synchronizations between models that are managed in the architect head. This would make the techniques difficult to apply. As the techniques rely on cross checking of names and certain conventions, they should be supported by a tool. Now, we would like to sketch the requirements of a tool for supporting our design technique. These requirements can be summarized as follows: † Model support: Basically, the tool should allow to model use case, state and sequence diagrams. † UML profile: The tool should provide a library of UI components and UML stereotypes for each UI component, to be used in state and sequence diagrams.


Page 8 of 20


Such UI components should be classified according to the following criteria: † By behavior: input, output and input/output UI components. In particular, UI containers should be distinguished from non-container components. † By similarity: some UI components are similar in behavior. For instance, database items can be shown to the architect by means of different user interface containers of similar behavior. The tool should allow the architect to define a hierarchical classification (i.e. more simple and richer) of UI components. Such classification will be useful for detecting generalization relationships between use cases in the user interface diagram.

†

† UI component specification: A complete set of attributes/ operations on UI components should be available for the architect. † Naming conventions: A data dictionary should be handled by the architect. It includes: use case names, state diagram names, state names, transition names and sequence diagram names. † Model synchronization: The tool should help the architect as follows: † Each use case is named and can be annotated to be associated to a user interface or not. † Each use case associated to a user interface is required to be described by means of a main user interaction diagram. The name of the main user interaction diagram is UI_usecase-name. † From the specified states of a user interaction diagram, the architect selects the states to be assigned a separate window. The name of the separate user interaction diagram is UI_state-name. † From the specified states of a user interaction diagram, the architect selects those to which a window will be associated. The name of the window is GUI_statename. In particular, use cases associated to a window have a window whose name is GUI_usecase-name. † The tool should generate automatically a user interface diagram in which inclusion and generalization relationships are added according to the proposed criteria. In particular, † The inclusion relationship has been specified by the architect by associating a separate window to certain states of use cases. † The generalization relationship is selected by the architect according to the specified criteria. † The tool should generate a user interface class diagram from the user interface diagram. Naming of window classes follows the above criteria. † From the specified transitions of the user interaction diagrams, the tool should request the names of the

†

† †

3.

AND

L. IRIBARNE

persistent and non-persistent containers to which such transition updates or consults. The architect selects such non-persistent containers from the user interaction diagrams. Persistent containers are added as classes in a new database class diagram. The name of the persistent container is DB_container-name. The tool should request a sequence diagram (i.e. a database interaction diagram) for each transition of the user interaction diagrams, adding as objects of the sequence diagram the set of persistent and non-persistent objects selected by the architect. The architect could select which of the transitions are not associated to a sequence diagram. The name of the sequence diagram (i.e. a database interaction diagram) associated to a transition is DBI_transitionname_UID-name. The architect should model each sequence diagram, and the tool should provide the available operations for each UI component and, in addition, the tool adds new operations from the messages to nonpersistent UI objects. In particular, for each transition the tool should add a new operation to the window class including such an event named UIcomponentname_class-name_GUI(). The tool should update the database class diagram with new operations for persistent containers. Finally, the tool could generate code from sequence diagrams. The code is generated for each class involved in each sequence diagram.

A CASE STUDY: AN INTERNET BOOK SHOPPING (IBS) SYSTEM

In this section we will present the IBS case study in more detail. For an extension of the example, and as a complement to this article, the reader is referred to the following web site, where all diagrams and the complete case study are given: http://indalog.ual.es/mdd/udbi.

3.1.

Building a use case diagram

As we have established in the proposed technique, the first step consists in identifying those actors and main tasks (i.e. use cases) of our future IBS application, by using a use case diagram. Let us suppose that the architect, who is designing the system, identifies three actors: first, the customer who interacts with some windows to consult and purchase by Internet, second, the architect also identifies an Ordering Manager, who deals (totally or partially) with pending orders sent by the customer, and finally, an Administrator who can manage the catalog (for instance, by adding, modifying, or removing items), update orders (for example, by canceling orders) or partially update orders.


UML MODELING

OF

USER

AND

FIGURE 2. Use case diagram for the IBS case study.

All these requirements are captured by the architect through a use case diagram as shown in Fig. 2. The three actors previously mentioned (Customer, Manager and Administrator) can be seen in the diagram, and the tasks each of them carries out in the IBS are represented in the diagram with use cases connected by means of associations to each actor. We will focus on the customer tasks in the following, whose complete analysis and design is enough to understand our technique.

3.2.

Building user interaction diagrams

Next we will describe the processes followed by the customer to make the purchase, that is, how the user interacts with the user interface components of the future windows of the system. In general, we have to model each task by means of the UML specialized state diagrams called user interaction diagrams. In this kind of diagrams the states are user interface containers of input/output interaction, for example, a text field where the user can type a searching criterion, or an item list where the query result from the database can be listed. Transitions represent interactions with the user interface components, that is, events associated to the windows or user interface components. For example, buttons are pressed in the windows by the user to carry out a specific task, or items can be selected with the mouse from a list in order to achieve a given action from them (for instance, removing or selecting items to put them into the shopping cart). In our proposed technique, states and transitions are stereotyped by the name of the user interface component they are associated with. User interface components are taken from the Java swing package. Therefore transitions can be labeled by means of kkJButtonll and states by means of kkJTextFieldll, kkJListll or kkJLabelll. Some states may not be stereotyped. A non-stereotyped state represents a user interaction diagram. In other words, a given task can be decomposed into subtasks, and each subtask can be described by means of a user interaction diagram.


Page 9 of 20

Then the main task includes subtasks by specifying nonstereotyped states in its user interaction diagram. The architect can decide to make a unique user interaction diagram for each task (i.e. use case) identified in the use case diagram or to decompose the main processes into two or more user interaction diagrams in order to improve/simplify the description and/or to reuse subtasks for other tasks of the same actor or another actor. Therefore, each use case (i.e. task) is modeled by means of one or more user interaction diagrams. In our case study, the purchase task is as follows. When the customers are registered, they access a window from which the purchase process is carried out. They can query the catalog about the items they want to buy and then choose from the query result those items they would like to add to the shopping cart. Moreover, at anytime, customers can look around for the items added to the shopping cart or eliminate some of them. When the customers have finished to add items into the shopping cart, they will achieve the purchase by pressing a button and the window will require a credit card number and the card control code (PIN) to carry out the transaction by Internet. The described process has been modeled by the architect by means of the user interaction diagrams shown in Fig. 3. The user interaction diagram associated to the Purchase use case has been decomposed by the architect into five user interaction diagrams to make the description more clear. One of the reasons for such decomposition could be that the architect could have detected some common subtasks of tasks related to another (or the same) actor, and decided to reuse them. Figure 3 shows that in the Purchase task the architect has identified a subtask which manages the shopping cart, which at the same time has been decomposed in subtasks. Such subtasks are non-stereotyped states. The user interaction diagram specifies what transitions are possible from a given state. In other words, what user interface components are available from each state. For instance, in the UI_Purchase user interaction diagram when the customer has typed the card number, the Next button is visible and enabled. This kind of stereotyped transitions of the form ‘kkUItype-namell UI-name’ are the most usual transitions of user interaction diagrams specifying a type for the user interface component and a name. In Fig. 3 there are some transitions which contain boolean conditions of the form [Condition]. In UML state diagrams, occurrences of boolean conditions are interpreted as a precondition for triggering the corresponding transition. This is the case of the boolean condition [cart not empty] in the UI_ManageShoppingCart user interaction diagram, ensuring that the shopping cart is not empty to proceed with the purchase. Some of the boolean conditions are related to a transition (i.e. event) of a subtask. For instance, the Proceed transition in the UI_Purchase user interaction diagram means that the customer will reach the state input card by pressing the


Page 10 of 20


AND

L. IRIBARNE

FIGURE 3. All user interaction diagrams for the customer.

button called Proceed, which occurs in the UI_Manage Shopping Cart user interaction diagram. This kind of boolean conditions of the form [UIName] means that from a subtask the given transition should be triggered. Now, let us focus our attention on the UI_Purchase user interaction diagram. The customer exits from the Manage shopping cart state by pressing the button Proceed and will introduce the credit card number in a text field kkJTextFieldll, labeled as Input Card. From this state the customer can reach two other states: either goes back to the shopping cart without purchasing (by pressing the button Back), or enters the credit card control code (by pressing the button Next). The remaining buttons and user interface containers (JTextField, JList, etc.) described in this user interaction diagram are supposed to be disabled or hidden when the user is found in this state. Once the customers have introduced the credit card number, they will press the button Next to enter now the PIN and finally confirm the purchase by pressing the button Purchase. When the customer presses the button Purchase, the system will register the order. This task (i.e. the order registration) belongs to the data logic of the system to be designed and involves an interaction with the database. This kind of tasks of data logic and involving interactions with the database

will be modeled later by means of database interaction diagrams. Following Fig. 3, the architect describes the states which carry out the state Manage shopping cart in the UI_Purchase diagram by using the diagram with the same name as the state (i.e. UI_ManageShoppingCart). This new diagram is again decomposed in two subtasks (i.e. two diagrams): (a) a subtask where the process of querying the catalog is described and (b) a subtask that describes the user interactions with the shopping cart. In the first case, the customer can consult the catalog by introducing a searching criterion in a text field and then pressing the button called Search (the customer can also clean the typed searching criterion or can click exit). In the Searching task, there is an interaction with the database. This interaction is linked to the button Search that uses the searching criteria for requesting data from the database and generates the query results in a user interface (i.e. non-persistent) container (i.e. of type JList). Again, the interaction with the database will be described later by means of the database interaction diagram. This kind of user interface components (i.e. lists) reveals new kinds of transitions that represent events on containers. In the UI_QueryCatalogue diagram there is a transition from the Results state (a list container) called [Selected


UML MODELING

OF

USER

AND

Article]. The architect specifies this kind of transitions by modeling specific events of user interface components. In this case, the architect has specified that the customer can select articles from the result list. The specification of such event is needed for specifying when the user can add items to the shopping cart (i.e. when at least one item has been selected). Such transitions are input user interactions but associated to output user interface components. Thus, the customer can (a) select items from the result list with the mouse, or (b) press the button Clear to clean the JList container, returning to the Searching criteria state, or (c) cancel the process by pressing the button Exit. Anyway, the transition [Selected article] on the state Results of the UI_QueryCatalogue diagram can be interrupted when the customer clicks on the button called Add to cart, defined in the user interaction diagram that contains the QueryCatalogue state (i.e. the UI_ManageShoppingCart diagram). Let us remark that in the state QueryCatalogue there is a transition of the type [Selected article]/Add to cart whose meaning is that whenever an element of the list has been selected, the button Add to cart is enabled, and in such a case, the customer can press the button (adding the selected elements to the shopping cart, as its name suggests). There is a subtask linked to Add to cart button which takes the selected elements and incorporates them to the shopping cart container. This subtask involves an interaction with the data container for the shopping cart (i.e. a non-persistent container). This subtask will be modeled later by means of a database interaction diagram. This kind of subtasks involving data containers in the user interface are modeled in our approach by means of database interaction diagrams. Finally, from the QueryCatalogue state the customer can look around the shopping cart (i.e. transition Show cart) or proceed with the purchase (i.e. transition Proceed) whenever the cart is not empty (i.e. condition [cart not empty]). Such a checking is linked to a data container (i.e. the shopping cart container) and can be specified by means of a database interaction diagram whenever the architect wants.

3.3.

Building the user interface diagram

The third step of our technique consists in refining the original use case diagram to generate the so-called user interface diagram. Let us remark that we have adopted the use case diagram as starting point for our design technique; in fact, the use case diagram of Fig. 2 retains the communicative role of use case diagrams. However, we reinterpret and accommodate the meaning of the use case diagram in the context of user interface design; that is, each use case is associated to a window, and inclusion and generalization relationships are interpreted as embedding and inheritance of user interaction/user interface components.


Page 11 of 20

FIGURE 4. The customer user interface diagram.

In our proposed technique the architect has now to decide how many windows will conform the system, and to build the user interface diagram including the set of windows for the system. But there are some considerations to be taken into account. First, the system windows have to be selected from the set of user interaction diagrams, and secondly, the user interface diagram has to express the relationships between the windows. For instance, in our case study, the architect has designed the user interface diagram of the Customer’s side, shown in Fig. 4, where he/she indicates that there are four windows: (1) The Purchase window described by means of the user interaction diagram UI_Purchase; (2) The Shopping cart window described by means of the user interaction diagram UI_ShoppingCart; (3) The Confirm remove article window described by means of the user interaction diagram UI_ConfirmRemoveArticle; and (4) The Query catalogue window described by means of the user interaction diagram UI_Query Catalogue. In the user interface diagram the architect also specifies by means of inclusion (i.e. kkincludell) and generalization relationships, the relationships between windows (i.e. user interaction diagrams). For instance, the window associated to UI_ShoppingCart is included in the window associated to UI_Purchase. In other words, one of the states (i.e. subtasks) of UI_Purchase is Shopping cart. The same can be said for UI_ShoppingCart and UI_ConfirmRemoveArticle. A more complex relationship (i.e. generalization) is described between UI_Purchase and UI_QueryCatalogue. In this case, the user interaction diagram for the Purchase task inherits from the user interface diagram of the Query Catalogue task in the following sense. The set of subtasks (i.e states) of Purchase is bigger than the set of subtasks (i.e. states) of the Query Catalogue task but, in addition, some transitions have been added to the subtasks of Query Catalogue task in order to build the Purchase process. Such transitions are [Selected article] Add to cart, [cart not empty] Proceed and [cart not empty] Show cart. In addition, they are


Page 12 of 20


able to interrupt the Query Catalogue process. In other words, the window for the Purchase process has been designed from the window for the Query Catalogue process adding three new buttons: Add to cart, Proceed and Show cart, which trigger new processes belonging to the Purchase task. We say in this case that Purchase is more particular than Query Catalogue. 3.4.

Building the user interface class diagram

The following step (the fourth) of our technique consists in transforming the user interface diagram and the set of user interaction diagrams into a specialized version of the UML class diagram, called user interface class diagram. Basically, the user interface class diagram (1) represents by means of icons of classes the set of windows for our system described in the user interface diagram, (2) adds as attributes to each window class the set of user interface components obtained from the set of user interaction diagrams, and (3) adds methods to each window class for each transition/event associated to an user interface component in the user interaction diagrams. In Fig. 5 we show this model transformation technique for the case study. For example, the class GUI_Purchase (class

AND

L. IRIBARNE

associated with the Purchase use case) has six buttons (and other three inherited from the class GUI_Query_catalogue). Such buttons were specified in the user interaction diagram UI_Purchase (and UI_QueryCatalogue). In addition, the class GUI_Purchase contains four data containers (a JList and three JTextfields) taken from the same user interaction diagrams. Finally, each data container has corresponding JLabels named as the corresponding state name in the cited user interaction diagrams. The proposed model transformation technique can be automatically used by a DSM tool supporting our design technique. However, there are some implementation details in which the architect should help the DSM tool. For instance, some of the classes: GUI_Query_catalogue and GUI_Shopping_ cart, include data containers like Vectors that do not correspond to a user interface component (i.e. with the presentation logic). These data containers are generally associated to user interface containers (for instance, Vectors are associated to JLists) in the implementation. In addition, for each user interface component—defined as attribute—having an associated transition/event in the user interaction diagrams a method is added to the class. Generally they are buttons and lists, although text fields might also have

FIGURE 5. The customer user interface class diagram.


UML MODELING

OF

USER

AND

associated events. In addition, specific data containers can have their own handler methods (for instance, the container Vector has get and set methods).

3.5.

Building the database class diagram

The following step of the proposed technique consists in defining a class diagram for the database components, called database class diagram. From the previous diagrams, the architect can identify which kind of persistent data should be considered to model the database. The interaction with database components will be modeled later by means of the so-called database interaction diagrams. In Fig. 6, we show the design of the database for the case study following an object-oriented model. The database main class (DB_Main) is composed of three table classes: (a) one for the customers (DB_Customer), (b) one for the customer orders (DB_Order) and another for the book


Page 13 of 20

catalog (DB_Book). Each table will be stored in a separate class and the main class is a container for such table classes. Every DB class offers a set of methods. Such methods have been included in Fig. 6, but they will be identified later when the database interaction diagrams are modeled. On the other hand, as we can see from Fig. 6, the requested orders and the sent orders have been separately modeled in the diagram, and the common part of the orders (book, customer and order identifiers) are modeled as a generalization. In addition, the dates of the orders are stored separately from the dates on which the customer’s orders were sent. Such conceptual design of the database is enough for our proposal.

3.6.

Building database interaction diagrams

Finally, the matter is the design of database interactions by means of the specialized version of the UML sequence diagrams, the so-called database interaction diagrams.

FIGURE 6. The Customer database class diagram.


Page 14 of 20


The database interaction diagrams are used as a complement of the user interaction diagrams, although they are also based on the other diagrams. The criterion to be followed is to generate a database interaction diagram for transitions/events which interact with a data container. In our case study, transitions are associated to JButton, JList, JTextField components and in most cases they involve the consulting/updating of a data container (for instance, in our case study, the transitions Selected Articles and the Results lists, which interact with the catalogue, order and customer databases). As we have said, a data container can be non-persistent (for instance, JList or JTextField in our case study) or persistent (for instance, the catalogue, order and customer databases in our case study). In a database interaction diagram, the message exchange between the objects that take part in a given task is modeled. Such tasks are triggered by transitions/events that activate a sequence of messages to consult/update data containers. The database interaction diagrams can describe: (a) only non-persistent data containers (at the user interface side); (b) only persistent data containers (at the database side); (c) both kinds of containers (persistent and non-persistent containers). Cases of type (b) are less frequent, since generally a database interaction carries out the visualization or updation of data in some non-persistent container at the user interface side. The architect has to take the decision on how many database interaction diagrams have to be designed in order to complement the user interaction diagrams. In general, a given transition in the user interaction diagram can update as many data containers as the given process requires. For instance, let us suppose a transition associates to a button which refreshes the data visualized by the user. In this case, the system should update all the data containers of the user interface. Next, we will show four cases of database interaction diagrams, two for type (a) and two for type (c). 3.6.1. Database interaction diagrams for non-persistent data containers Let us focus our attention on the user interaction diagram associated with the shopping cart use case (i.e. UI_ShoppingCart), shown in Fig. 7. The scenario is as follows: The customer, after having added books to the cart, decides to consult the shopping cart, and observing that one of the books finally holds no interest proceeds to eliminate it from the cart, by selecting it from the list and pressing the appropriate button. In response, the application shows the customer a window where he/she is asked to confirm or to cancel the operation to be carried out. The diagram includes five transitions (i.e. [Selected article], Close, Remove article, [Cancel], and

AND

L. IRIBARNE

FIGURE 7. The user interaction diagram for the shopping cart.

[Accept]). In addition, there is a data container of type JList, called Selected Articles. Now, the architect should decide which transitions update the container and build database interaction diagrams for them. When the customer presses the button Remove article a small window opens requesting the customer to confirm the elimination of the selected items. In case the customer presses the button Cancel (represented as [Cancel]) the container Selected Articles is not updated. In case the customer presses the button Accept (represented as [Accept]), the container Selected Articles is updated and the item is removed. Therefore, the architect decides to design a database interaction diagram for the transition [Accept] of the given user interaction diagram. In Fig. 8, the database interaction diagram of the button Accept is modeled. The database interaction diagrams will be named DBI_transition-name_UI-name indicating the transition name together with the user interaction diagram name where it has been specified, for instance, DBI_Accept_ShoppingCart. In database interaction diagrams the actors (in this case, the Customer) initiate the sequence of message exchanging. The objects interacting in the diagram are the user window containing the user interface component associated to the transition (in the example, GUI_Shopping_cart), together with the data containers involved in the transition (in the example a JList and a Vector). The architect has to include all the required objects to complete the transition. The interaction of the customer with the button Accept supposes the triggering of a sequence of calls from the method of the GUI_Shopping_cart class called accept_Button_ConfirmRemoveArticle_GUI(). This method takes the element the customer has selected in the Selected Articles list and removes the element from the associated vector container and from the list. The architect has to include in such diagram all the non-persistent object containers (i.e. Selected_article:JList and valueCart:Vector declared as attributes of the GUI_Shopping_cart class in Fig. 8) that takes part on the operation. If they were not included as attributes in the


UML MODELING

OF

USER

AND


Page 15 of 20

FIGURE 8. The database interaction diagram for the button Accept.

FIGURE 9. A DBI diagram for an event associated to a list.

previous steps, this is the time the architect can update the user interface class diagram. The architect has to specify the complete sequence of calls from the specified objects, that is, selected=get AnchorSelectionIndex, remove(selected) and setListdata(valueCart) called from the accept_ Button_ConfirmRemoveArticle _GUI() method. The architect has now to decide whether other transitions of the diagram shown in Fig. 7 need to be specified by means of a database interaction diagram. The architect detects that the transition [Selected Article] updates some containers of the user interface. These data containers are the buttons associated to transitions conditioned by the [Selected Article] boolean condition. The boolean condition specifies that the corresponding transition can be triggered whenever the boolean condition holds. Therefore when the transition is linked to a button, the button has to be enabled and visible to the customer.

Figure 9 specifies the database interaction diagram of the [Selected Article] transition and how the corresponding buttons are activated. The method getSelectedIndex() of the Selected_articles_list object detects when the Remove Article button has to be activated. The same kind of diagram can be built from the UI_ManageShopingCart user interaction diagram, the Add to cart button and the Results list.

3.6.2. Database interaction diagrams for persistent data containers Let us see example database interaction diagrams of type (c): on the one hand, the customer consults the catalog (associated to the transition