View
7
Download
0
Category
Preview:
Citation preview
UML Modeling of User and Database
Interaction
JESUS M. ALMENDROS-JIMENEZ1 AND LUIS IRIBARNE2,*
1Information System Group, University of Almerıa, 04120 Almerıa, Spain2Applied Computing Group, University of Almerıa, 04120 Almerıa, Spain
*Corresponding author: liribarn@ual.es
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 soft-
ware 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 pro-
cesses usually handle user interface components and server-
side 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) tech-
nologies 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
# The Author 2008. Published by Oxford University Press on behalf of The British Computer Society. All rights reserved. ForPermissions, please email: journals.permissions@oxfordjournals.org
doi:10.1093/comjnl/bxn028
The Computer Journal Advance Access published May 21, 2008
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 comp-
lement 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
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 classi-
fied into user interface objects and database objects.
Database interaction diagrams describe how user inter-
face 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 interac-
tion 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 relation-
ships (inclusion and generalization relationships) are
also identified in (and mapped into) state and sequence
Page 2 of 20 J. M. ALMENDROS-JIMENEZ AND L. IRIBARNE
THE COMPUTER JOURNAL, 2008
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 dia-
grams 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.
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 inter-
face 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
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 navi-
gation. 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.
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.
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 data-
base 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 inter-
face 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 relation-
ship identification and mapping into state and sequence dia-
grams is one of the most relevant contributions of our proposal.
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 (Post-
WIMP 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 naviga-
tion modeling of Web applications. The most relevant contri-
bution 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.
UML MODELING OF USER AND DATABASE INTERACTION Page 3 of 20
THE COMPUTER JOURNAL, 2008
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 interest-
ing 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 non-
contextual links that represent links between pages. Finally,
they support the specification of services and content manage-
ment 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 con-
tainers, 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.
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. Vali-
dation 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 contri-
butions 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
Page 4 of 20 J. M. ALMENDROS-JIMENEZ AND L. IRIBARNE
THE COMPUTER JOURNAL, 2008
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 tech-
nique 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 rela-
tionships 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 swing-
based architecture, they will be buttons, boxes, lists and text
area components.
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 particu-
lar 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.
UML MODELING OF USER AND DATABASE INTERACTION Page 5 of 20
THE COMPUTER JOURNAL, 2008
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 com-
ponents 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
FIGURE 1. Steps for UML modeling of user and database interaction.
Page 6 of 20 J. M. ALMENDROS-JIMENEZ AND L. IRIBARNE
THE COMPUTER JOURNAL, 2008
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.
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 dia-
grams 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
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 con-
tainers 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. Tool support
Our design technique involves many rules, naming conven-
tions and synchronizations between models that are
managed in the architect head. This would make the tech-
niques 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 com-
ponent, to be used in state and sequence diagrams.
UML MODELING OF USER AND DATABASE INTERACTION Page 7 of 20
THE COMPUTER JOURNAL, 2008
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 beha-
vior. 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_state-
name. 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
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_transition-
name_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 non-
persistent UI objects. In particular, for each transition
the tool should add a new operation to the window
class including such an event named UIcomponent-
name_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.
3. 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.
Page 8 of 20 J. M. ALMENDROS-JIMENEZ AND L. IRIBARNE
THE COMPUTER JOURNAL, 2008
All these requirements are captured by the architect through
a use case diagram as shown in Fig. 2. The three actors pre-
viously 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.
Then the main task includes subtasks by specifying non-
stereotyped 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
FIGURE 2. Use case diagram for the IBS case study.
UML MODELING OF USER AND DATABASE INTERACTION Page 9 of 20
THE COMPUTER JOURNAL, 2008
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 regis-
tration) 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
FIGURE 3. All user interaction diagrams for the customer.
Page 10 of 20 J. M. ALMENDROS-JIMENEZ AND L. IRIBARNE
THE COMPUTER JOURNAL, 2008
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 inter-
face 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 inter-
face components.
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_Confirm-
RemoveArticle; 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_Shopping-
Cart 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
FIGURE 4. The customer user interface diagram.
UML MODELING OF USER AND DATABASE INTERACTION Page 11 of 20
THE COMPUTER JOURNAL, 2008
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
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 presen-
tation 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.
Page 12 of 20 J. M. ALMENDROS-JIMENEZ AND L. IRIBARNE
THE COMPUTER JOURNAL, 2008
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
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.
UML MODELING OF USER AND DATABASE INTERACTION Page 13 of 20
THE COMPUTER JOURNAL, 2008
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 data-
base 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 comp-
lement the user interaction diagrams. In general, a given tran-
sition 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 associ-
ated 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 appro-
priate 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
[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
FIGURE 7. The user interaction diagram for the shopping cart.
Page 14 of 20 J. M. ALMENDROS-JIMENEZ AND L. IRIBARNE
THE COMPUTER JOURNAL, 2008
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 <<JButton.. Search of the UI_Query
Catalogue diagram), and on the other hand, the customer
proceeds with the purchase (associated to the transition
<<JButton.. Purchase of the UI_Purchase diagram).
FIGURE 8. The database interaction diagram for the button Accept.
FIGURE 9. A DBI diagram for an event associated to a list.
UML MODELING OF USER AND DATABASE INTERACTION Page 15 of 20
THE COMPUTER JOURNAL, 2008
These two scenarios are modeled by means of the diagrams of
Figs 10 and 11.
In Fig. 10 there are non-persistent containers (JTextField,
JList and Vector) and persistent containers (DB_Main and
DB_Book). The non-persistent containers have been declared
as attributes of the GUI_Query_catalogue component
(window). The methods required by the user interface
should be added to the Customer user interface class
diagram of Fig. 5 whenever they have not been added
before. The GUI_Customer class is the one that initiates
the sequence and is connected to the database through the
ICustomer interface associated to the Customer (see Fig. 6).
Here is the key point of our object-oriented modeling of
the user interface: the GUI_Customer window is connected
to the GUI_Purchase window but not to the GUI_Query_
catalogue window (see Fig. 5). However, the transition of
the Search button has been included in the user interaction
diagram associated to the GUI_Query_catalogue window
(i.e. the UI_QueryCatalogue user interaction diagram).
Therefore the method associated to the Search button has
FIGURE 11. The DBI diagram for the event associated with the Purchase button.
FIGURE 10. DBI diagram for the event associated with the Search button.
Page 16 of 20 J. M. ALMENDROS-JIMENEZ AND L. IRIBARNE
THE COMPUTER JOURNAL, 2008
been added to the GUI_Query_catalogue window class.
However, the GUI_Customer is the one connected to the data-
base and GUI_Purchase, and for this reason the object speci-
fied in Fig. 10 is GUI_Purchase instead of GUI_Query_
catalogue, but using the inherited methods. In addition, it is
consistent with the user interface diagram (see Fig. 3).
In summary, some transitions associated to user interaction
diagrams can be described by means of database interaction
diagrams in which the corresponding window objects are not
included. This is due to the inheritance relationships specified
in the user interface diagram. The architect has to take into
account the generalization relationships and the associations
specified in the user interface diagram, in order to know
which window objects participate, and which of them are
connected, in each database interaction diagram.
On the other hand, the methods offered from the database
should be added to the corresponding class in the database
class diagram whenever they have not been added before.
Now, in order to search from the catalog, the inherited
method associated to the button Search, called search_
Button_QueryCatalogue_GUI(), triggers the sequence
of calls. When the typed searching criteria is not empty the
GUI_Purchase object calls the GUI_Customer object
requesting the catalog query. The GUI_Customer object
calls by means of the ICustomer interface to the main
object of the database: DB_Main. This object is the container
of the catalog—the DB_Book object—and requests the catalog
object for the result of the query. Finally, the DB_Main object
returns to the GUI_Customer the result of the query, and
GUI_Customer updates the data container in the user interface
window.
In Fig. 11, the process followed after the customer has
pressed the Purchase button is shown. This diagram comp-
lements the UI_Purchase user interaction diagram (shown
in the Fig. 3). The architect has supposed that the customer
enters a card number and a control code in the corresponding
text fields. In addition, the method (get_valueCart)
associated to the shopping cart component requests the
content of the cart to prepare the purchase order by means
of the method call set_order(card, pin, cart),
which is split in three calls each one updating each table
class. Then, the order is added to the database by means of
the method add_requested_order(order). In this case
the window associated to the user interaction diagram is
specified in the database interaction diagram (i.e the Purchase
transition is included in the UI_Purchase user interaction
diagram, associated to the GUI_Purchase window).
The three database interaction diagrams which can also be
modeled for the case study are the following:
(a) DBI_AddToCart_Purchase: associated to the tran-
sition of the Add_to_cart button in the Purchase
window, it adds an element to the shopping cart
container;
(b) DBI_Clear_QueryCatalogue: associated to the
Clear button of the QueryCatalogue window, it
clears the searching criteria container;
(c) DBI_SelectedArticleEvent_ManageShopping
Cart: associated to the Result list in the Purchase
window, it enables and makes visible the Add to
cart button.
These diagrams do not introduce new elements w.r.t. the
proposed technique. However, the reader can find them and
the complete project in our web site: http://indalog.ual.es/
mdd/udbi.
Finally, Fig. 12 shows the system windows that can be
generated from the user interface class diagram, the user
interaction diagrams and the database interaction diagrams.
In practice, the architect of the system could make in
advance some preliminary sketches of the windows to facili-
tate the identification of the user interface components when
elaborating the user interaction diagrams.
3.7. Code generation
Finally, in this section we would like to sketch our proposal of
code generation from our design technique. Basically, code
generation can generate code from user interaction diagrams
and from sequence diagrams. From user interaction diagrams
the code generation would generate templates for each
window. Such templates would include code for generating
a frame (applet) window in which the UI components are
declared, and for each UI component the corresponding
event handler is added. The template for the case of a button
would be as follows:
import java.awt.event.*;
public class className extends JFrame f
/**@GUIcomponents */
public JButton name_Button ¼ new JButton();
private void jbInit() throws Exception f
/**@Button */
name_Button.setText(“name”);
name_Button.addActionListener(
new java.awt.event.ActionListener() f
public void actionPerformed(ActionEvent e) f
name_Button_nameClass_GUI(); g g);
/**@Panel */
this.getContentPane().add(name_Button,null);
g // end jbInit()
/***
*Method THIS
*/
/** Button */
void name_Button_className_GUI() f. . .g
g
Such code template should be filled with the code generated
from the sequence diagrams associated to the UI component.
UML MODELING OF USER AND DATABASE INTERACTION Page 17 of 20
THE COMPUTER JOURNAL, 2008
For instance, in the case of DBI_Accept_ShoppingCart
sequence diagram, the generated code would be:
void accept_Button_ConfirmRemoveArticle_GUI()
f
selected ¼ selected_articles.getAnchor
Selection Index();
valueCart.remove(selected);
selected_articles.setListData(valueCart);
g
4. CONCLUSIONS AND FUTURE WORK
We have developed a technique for user and database
interaction design based on UML use case, state and sequence
diagrams. In addition, we have studied a model transformation
technique of UML models for obtaining class diagrams from
use case, state and sequence diagrams. Such modeling and
transformation techniques are focused on WIMP user interface
design (in particular, the Java swing package). Our technique
allows the description of user interactions through a user inter-
face, and describes how the user interface interacts with a
database server to accomplish user tasks. Finally, the proposed
technique is able to model the interaction with the non-
persistent containers which can be added in user interfaces.
We believe that more complex user interfaces: static user
interfaces (i.e. HTML), active user interfaces (i.e. Applet,
JavaScripts, . . .), or dynamic user interfaces (i.e. JSP, ASP,
PHP, CGIs, . . .) could be modeled following our technique,
adapting our user and database interaction diagrams, and
user interface and database class diagrams. The starting
point of such extension could be the works [10, 25–30, 34].
The second extension of our work could be the code genera-
tion. We have shown how we can design the structure and beha-
vior of the user interfaces in our proposal, obtaining class, state
and sequence diagrams describing the user interface. In addition,
we can incorporate operation signatures to each class. A deeper
study about code generation is considered as future work.
Finally, a DSM tool supporting our technique seems to be
needed for the practical application of our design technique.
We have validated our technique with the student projects
in the classroom. However, many of the tasks are handmade
for students. We believe that some of the steps could be
automatized by means of a model transformation tool like
ATL [41].
ACKNOWLEDGEMENTS
The authors would like to thank the anonymous referees for
their insightful comments and suggestions, that greatly
helped them improve the contents and readability of the paper.
FUNDING
This work has been partially supported by the EU (FEDER)
and the Spanish MEC under grants TIN2005-09207-C03-02
and TIN2007-61497.
FIGURE 12. Windows at the Customer side associated to the Purchase use case.
Page 18 of 20 J. M. ALMENDROS-JIMENEZ AND L. IRIBARNE
THE COMPUTER JOURNAL, 2008
REFERENCES
[1] DSM. (2008) http://www.dsmforum.org/. DSM Forum. Technical
Report, Domain Specific Modeling Forum.
[2] Balmelli, L., Brown, D., Cantor, M. and Mott, M. (2006)
Model-driven systems development. IBM Syst. J., 45, 569–585.
[3] Hailpern, B. and Tarr, P. (2006) Model-driven development:
The good, the bad, and the ugly. IBM Syst. J., 45, 451–461.
[4] Selic, B. (2006) UML 2: A model-driven development tool.
IBM Syst. J., 45, 607–620.
[5] Sendall, S. and Kozaczynski, W. (2003) Model transformation:
the heart and soul of model-driven software development. IEEE
Softw., 20, 42–45.
[6] OMG. (2005) Unified Modeling Language Specification,
version 2.0. Technical Report, Object Management Group.
[7] Goldberg, M. and Robson, D. (1983) Smalltalk-80: The
Language and its Implementation. Addison-Wesley.
[8] Barclay, P. J., Griffiths, T., McKirdy, J., Paton, N. W.,
Cooper, R. and Kennedy, J. (1999) The Teallach Tool: Using
Models for Flexible User Interface Design. Proc. 3rd Int.
Conf. Computer-aided Design of User Interfaces, Norwell,
MA, USA, pp. 139–157. Kluwer Academic Publishers.
[9] Pinheiro da Silva, P., Griffiths, T. and Paton, N. W. (2000)
Generating User Interface Code in a Model based user
Interface Development Environment. AVI ’00: Proc. Working
Conf. Advanced Visual Interfaces, NY, USA, pp. 155–160.
ACM Press.
[10] Conallen, J. (1999) Modelling web application architectures
with UML. Commun. ACM, 42, 63–70.
[11] Pinheiro da Silva, P. and Paton, N. W. (2003) User interface
modeling in UMLi. IEEE Softw., 20, 62–69.
[12] Almendros-Jimenez, J. M. and Iribarne, L. (2005) Describing
Use Cases with Activity Diagrams. Proc. Metainformatics
Symp. (MIS’04), Heidelberg, Germany, Lecture Notes in
Comuter Science, Vol. 3511, Springer, pp. 141–159.
[13] Almendros-Jimenez, J. M. and Iribarne, L. (2005) Designing
GUI Components for UML Use Cases. 12th IEEE Int. Conf.
Workshops on the Engineering of Computer-Based Systems
(ECBS’05), pp. 210–217. IEEE Computer Society Press.
[14] Almendros-Jimenez, J. M. and Iribarne, L. (2007) User
interaction and interface design with UML, Visual Languages
for Interactive Computing: Definitions and Formalizations,
Chapter XVI, Information Science Reference. IGI Global.
pp. 324–352.
[15] Almendros-Jimenez, J. M. and Iribarne, L. (2007) Describing
use case relationships by means of sequence diagrams. Comp.
J., 50, 116–128.
[16] Pinheiro da Silva, P. (2000) User interface declarative models
and development environments: a survey. In Palenque, P.
and Paterno, F. (eds), Interactive Systems: Design, Specification,
and Verification, Lecture Notes in Computer Science, Vol.
1946. Heidelberg, Germany, Springer, pp. 207–226.
[17] Mori, G., Paterno, F. and Santoro, C. (2002) CTTE: Support for
Developing and Analyzing Task Models for Interactive System
Design. IEEE Transactions on Software Engineering, August,
pp. 797–813.
[18] Paterno, F. (1999) Model-Based Design and Evaluation of
Interactive Applications. Springer, Heidelberg, Germany.
[19] Campos, P. F. and Nunes, N. J. (2005) A UML-based tool for
designing user interfaces. UML 2004 Satellite Activities,
Lecture Notes in Computer Science, Vol. 3297. Heidelberg,
Germany, Springer, pp. 273–276.
[20] Nunes, N. J. (2001) Object modeling for user-centered
development and user interface design: the wisdom approach.
PhD Thesis, University of Madeira.
[21] Nunes, N. J. (2003) Representing User-Interface Patterns
in UML. Proc. OOIS 2003, Heidelberg, Germany, Lecture
Notes in Computer Science, Vol. 2817, Springer, pp. 142–151.
[22] Nunes, N. J. and e Cunha, J. F. (2001) Wisdom–A UML Based
Architecture for Interactive Systems. Proc. DSV-IS 2000,
Lecture Notes in Computer Science, Vol. 1946, Springer, pp.
191–205.
[23] Pinheiro da Silva, P. (2002) Object modelling of interactive
systems: the UMLi approach. PhD Thesis, University of
Manchester.
[24] Pinheiro da Silva, P. and Paton, N. W. (2000) User interface
modelling with UML. Information Modelling and Knowledge
Bases XII, pp. 203–217. IOS Press.
[25] Bellettini, C., Marchetto, A. and Trentini, A. (2004) WebUml:
Reverse Engineering of Web Applications. Proc. 2004 ACM
Symp. Applied Computing, NY, USA, pp. 1662–1669. ACM Press.
[26] Gomez, J., Cachero, C. and Pastor, O. (2000) Extending a
Conceptual Modelling Approach to Web Application Design.
Advanced Information Systems Engineering: 12th Int. Conf.
(CAiSE 2000), Heidelberg, Germany, Lecture Notes in
Computer Science, Vol. 1789, Springer, pp. 79–93.
[27] Hennicker, R. and Koch, N. (2007) A UML-based Methodology
for Hypermedia Design. UML’2000 – The Unified Modeling
Language – Advancing the Standard, Heidelberg, Germany.
Lecture Notes in Computer Science, Vol. 1939. Springer.
[28] Koch, N., Kraus, A., Cachero, C. and Melıa, S. (2004)
Integration of business processes in Web applications models.
J. Web Eng., 3, 22–49.
[29] Larsen, G. and Conallen, J. (2002) Engineering web-based
systems with UML assets. Ann. Softw. Eng., 13, 203–230.
[30] Schwabe, D. and Rossi, G. (2000) An object oriented approach
to web-based applications design. Theor. Pract. Object Syst., 4,
207–225.
[31] Balzert, H., Hofmann, F., Kruschinski, V. and Niemann, C.
(1996) The JANUS Application Development Environment –
Generating More Than the User Interface. Proc. Computer-
Aided Design of User Interfaces, (CADUI’96), pp. 183–208.
Press Universiteries of Namur.
[32] Storrle, H. (2002) Group Exercises for the Design & Validation
of GUIs. Proc. Modellierung, Lecture Notes in Informatics,
Vol. p-12, pp. 135–146.
[33] Dolog, P. (2004) Model-Driven Navigation Design for
Semantic Web Applications with the UML-Guide. ICWE
Workshops, pp. 75–86.
UML MODELING OF USER AND DATABASE INTERACTION Page 19 of 20
THE COMPUTER JOURNAL, 2008
[34] Brambilla, M., Comai, S., Fraternali, P. and Matera, M. (2007)
Designing web applications with webML and WebRatio, Web
Engineering: Modelling and Implementing Web Applications,
pp. 221–260. Springer, Heidelberg, Germany.
[35] Makinen, E. and Systa, T. (2000) An Interactive Approach for
Synthesizing UML Statechart Diagrams from Sequence Diagrams.
Proc. 10th ACM Conf. on Object-Oriented Programming Systems,
Languages and Applications, NY, USA. ACM Press.
[36] Petriu, D. C. and Sun, Y. (2000) Consistent Behaviour
Representation in Activity and Sequence Diagrams. UML
2000 – The Unified Modeling Language. Advancing the
Standard: 3rd Int. Conf., Heidelberg, Germany, Lecture Notes
in Computer Science, Vol. 1939, Springer. pp. 369–382.
[37] Whittle, J. and Schumann, J. (2000) Generating Statechart
Designs from Scenarios. Proc. 22nd Int. Conf. Software
Engineering, pp. 314–323, NY, USA. ACM Press.
[38] Kosters, G., Six, H.-W. and Winter, M. (2001) Coupling use
cases and class models as a means for validation and
verification of requirements specifications. Require. Eng., 6,
3–17.
[39] Marcos, E., Vela, B. and Cavero, J.M. (2001) Extending UML
for Object-Relational Database Design. UML 2001 – The
Unified Modeling Language. Modeling Languages, Concepts,
and Tools: 4th Int. Conf., Heidelberg, Germany, Lecture
Notes in Computer Science, Vol. 2185, Springer, pp. 225–239.
[40] Mok, W.Y. and Paper, D.P. (2001) On Transformations from
UML Models to Object-Relational Databases. Proc. 34th
Annual Hawaii Int. Conf. System Sciences, p. 10. IEEE
Computer Society Press.
[41] Jouault, F. and Kurtev, I. (2006) On the Architectural Alignment
of ATL and QVT. SAC ’06: Proc. 2006 ACM Symp. Applied
Computing, NY, USA, pp. 1188–1195. ACM Press.
Page 20 of 20 J. M. ALMENDROS-JIMENEZ AND L. IRIBARNE
THE COMPUTER JOURNAL, 2008
Recommended