AlmendrosandIribarne Chapter Accepted (1)

8/13/2019 AlmendrosandIribarne Chapter Accepted (1)

1/30

User Interaction and Interface Design with UML

Jess M. Almendros-Jimnez and Luis IribarneDpto. de Lenguajes y Computacin. Universidad de Almera

{jalmen,liribarne}ual.es

Abstract

This chapter is devoted to show how to use andspecialise UML diarams !or describing t!e user

inter"aceso! a so!tware s"stem. In order to accomplish the description o! user inter!aces# the proposed

techni$ue considers three specialised UML diarams called user#interaction# user#inter"aceand $U%#

class diagrams# which will be built !ollowin a model#driven development%M&&' perspective. These

diarams can be seen as the U&L#based U% modelso! the s"stem. In addition# this paper concerns with

code-eneration to implement the user inter!aces o! the s"stem b" usin $U%#class diagrams and

user#interaction diagrams. A case stud" o! an %nternet boo' s!opping system is introduced in this

chapter to proo! and illustrate the proposed user interaction and inter!ace desin techni$ue.

(ey )ords( UML ).*# Use +ases# Model-&riven &evelopment# ,isual Lanuaes# Interactive

+omputin# Interaction &esin.

INTRODUCTION

The emerence o! the Uni"ied &odelling Language %UML' %M# )**/' as an industr"

standard !or modellin s"stems has encouraed the use o! automated so!tware tools that

!acilitate the development process !rom anal"sis throuh codin. The user inter"ace *U%+# as a

sini!icant part o! most applications# should also be modelled usin UML. UML diarams

could be used to model user inter!aces# and automatic +A01 tools could help to enerate code!or user inter!aces !rom UML desins. In eneral terms# visual modelling allows the

developers to visualize source code in a raphical !orm( raphical abstractions# such as !low

charts to depict alorithmic control !lows and structure charts or simple bloc2 diarams with

bo3es representin !unctions and subprorams# and so on. UML provides s"stem architects

with a visual language!or speci!"in# constructin and documentin the arte!acts o! so!tware

s"stems. In particular# user inter!aces should be visuall" modelled in order to describe the

behaviour o! the window s"stem in response to user interactions.

This chapter is !irstl" devoted to show how to useandspecialiseUML diarams in order to

describe the user inter!ace and user interactions o! a so!tware s"stem# !ollowin a particular

model#driven development%M&&' perspective. Model-driven development involves creatin

models throuh a methodoloical process that beins with re$uirements and loo2s into a hih-

level architectural desin. Model-driven development !acilitates and improves the so!tware

anal"sis and desin and code eneration !acilities !rom models prevent the loss o! substantial

in!ormation durin the transition o! a model to its implementation.

In our M&& perspective# we consider the !ollowin steps !or user inter!ace desin and

modellin(

%a' 4irstl"# we use a UML use case diagram!or e3tractin the main user inter"aces.

%b' 0econdl"# we describe each use case b" means o! a special 2ind o! U&L activitydiagrams# called user#interaction diagrams# whose states represent data output actions


2/30

and transitions represent data input events. This perspective allows the desiner to model

the user interaction %i.e. input-output interaction' in each main user inter!ace.

%c' Thirdl"# each input and output interaction o! the user#interaction diagrams allows the

desiner to e3tract $U% componentsused in each user inter!ace. There!ore# we can obtain

a new andspecialied version o" t!e use case diagram representin the user inter!ace

desin# and a class diaram !or UI components( user#inter"aceand $U%#classdiarams#respectivel".

%d' The user#interaction# user#inter"ace and $U%#classdiarams can be seen as the U&L#

based user inter"ace modelso! the s"stem.

This chapter is also devoted to deal with code generationtechni$ues. In our M&& perspective

the UML-based user inter!ace models can be used !or eneratin e-ecutable codewith the

!ollowin advantaes(

%a' 4irstl"# !or rapid prototypingo! the developed so!tware( so!tware modellers would !ind it

use!ul to $uic2l" enerate user inter!aces !rom hih-level descriptions o! the s"stem.

%b' 0econdl"# !or model validation and re"inement( 5rotot"pin can detect !ails in desin andre!inement and validation o! model b" testin user inter!aces and user re$uirements.

%c' Thirdl"# !or model#based code generation( enerated code would !it with developed

models.

%d' 4inall"# starting point "or implementers( protot"pes can be re!ined until !inal

implementation.

BACKGROUND

In the literature there are some wor2s dealin with the problem o! user inter!aces in UML.

Use Cases and UI Design

0ome o! these wor2s %6unes 7 4alcao# )**8' %5aterno# )**8' %+onstantine 7 Loc2wood#

)**8' are !ocused on the utilization o! UML use case diagramsas 9startin point: o! the user

inter!ace desin# or even as a 9hih-level description: o! the structure o! the user inter!ace.

;owever# there are some considerations about the use case diaram st"le. 4ollowin the UML

philosoph"# a use case diaram could not be suitable !or e3tractin the user inter!aces. Use

case diarams ma" include some use cases re!erred to parts o! the s"stem not related to user

inter!aces# such as classes# human tas2s# components o! other s"stems interactin with us# and

so on. r even# decomposin use cases b" means o! include and e-tend relationships# one

could speci!" speci!ic parts o! the s"stem which are not related with the user inter!ace.

There!ore# in our opinion# a specialized version o! the use case model could be re$uired# or

even some other UML diarams could be used to complete the use case view.

Adapting UML to UI Design

ther wor2s %;eumann# )**


3/30

)***' %1l2outbi et al.# 8===' interested in the description o! the loic o! UI components#

usin activit" and state diarams !or that. In this case# user interaction can be speci!ied b"

means o! states# where the s"stem shows output data# and re$uests input data. It should be

speci!ied how the user can naviate throuh the user inter!ace# openin# closin windows#

pic2in up in lin2s# and so on. The speci!ied loic should describe the set o! states %input#

output# windows' in which the user can be !ound.

Code Generation and UML

@ith respect to code eneration# un!ortunatel"# the capabilities o! code enerator +A01 Tools

to trans!orm desin to an implementation are o!ten restricted to produce class de!initions

consistin o! attributes and operation sinatures captured in class diarams# but not methods

to implement the procedural !low within the operations. 13istin approaches in this last sense

turn statecharts into e3ecutable code. 0tatecharts are used as obect controllers !or speci!"in

when an obect is willin to accept re$uest. +A01 tools supportin code eneration !rom

statecharts are 0tatemate %Iloi3# )**B'# mate %;arel 7 er"# 8==C'# Dhapsod" %Iloi3#

)**B' and 4uaba %0chE!er# )**)'.

MAIN TRU!T O" T# CA$T#R

@ith reard to previous wor2s on UML %Use +ases' and UI &esin# our contribution can be

summarized as !ollows.

4irstl"# we consider use cases as a startin point o! the user inter!ace desin. ;ere we

de!ine a new 2ind o! diaram# user#inter"ace diagram( a specialized version o! the use

case diaram as a hih-level description o! the user inter!ace.

In addition# !ollowin the M&& perspective# we interate this s"stem view with a set o!

specialized activit" diarams !or user interaction desin %user#interaction diagrams'. ne

o! the bene!its o! this interation is that each use case in the specialized use case diaram

is described b" means o! a specialized activit" diaram# and there!ore inter!aces can be

anal"zed and built !rom these two models.

In addition# a class diaram is enerated !rom the specialized activit" diarams. UI

components can also be built !rom both modellin techni$ues.

@ith reard to previous wor2s on code eneration# the UI models can et protot"pes o! the

user inter!ace o! our application. Throuh mappin between UML and Java# we are able to

enerate low-level Java code directl" !rom the user interaction diaram. This code eneration

is adapted to the special case o! user inter!aces# which is user event-based and handles inputand output data b" means o! special 2inds o! UI components.

ORGANI%ATION O" T# CA$T#R

The ne3t section describes our model-driven development techni$ue !or User Inter!aces. The

chapter continues with the techni$ue !or the code eneration b" usin user-inter!ace models.

This chapter !inishes with some conclusions and !uture wor2.


4/30

MOD#L&DRI'#N D#'#LO$M#NT "OR U!#R INT#R"AC#!

Use Case Diagra(s

Use case diarams are used as startin point !or user-inter!ace desin. Use cases are also a

wa" o! speci!"in re$uired usaes o! a s"stem# and the" are t"picall" used !or capturin there$uirements o! a s"stem %that is# what a s"stem is supposed to do'. The 2e" concepts

associated with the use-case model are actorsand use cases. The users and s"stems that ma"

interact with the s"stem are represented b" actors. Actors alwa"s model entities that are

outside the s"stem. Use cases represent the set o! tas2s that the actors carr" out. In addition#

the 9use cases: can be decomposed b" means o! includerelationships# and the" can also be

related b" means o!generaliationspecialiationrelationships that compare more eneral and

particular tas2s.

In order to desin a protot"pe o! the user inter!ace# the use case diaram should include the

s"stem actors and the set o! %main' tas2s !or each one in which heFshe ta2es part. 4rom a point

o! view o! user inter!ace modellin# the use case diaram can be seen as a hih leveldescription o! the main windows o! the s"stem.

To illustrate the !unctionalit" o! the M&&-based techni$ue we will e3plain a simple Internet

boo2 shoppin %IG0' model.

"ig)re *+ A pre,i(inar- )se case description of the IB! e.a(p,e

In the IG0 e3ample %4iure 8'# there basicall" appear three actors( the customer# the orderin

manaer# and the administrator. A customer directl" ma2es the purchases b" the Internet#$uer"in certain issues o! the product in a cataloue o! boo2s be!ore ma2in the purchase.

The manaer deals with customerHs orders %total or partiall"'. And !inall"# the s"stemHs

administrator can manae the cataloue o! boo2s b" addin and eliminatin boo2s in the

cataloue or modi!"in those alread" e3istin. The administrator can also update or cancel

certain component characteristics o! an order or those orders !ul!illin certain searchin

criteria.

This in!ormation is described with a use case diaram containin the identi!ied actors and

main tas2s o! the s"stem. In our case stud" %see 4iure 8'# the actors are the Customer# the

Managerand the Administrator# and the main tas2s are purchase# manage orders#

manage partial orders# manage catalogue# update orders and update

partial orders.


5/30

4rom this use case diaram one can identi!" the "uture )indo)s o! the s"stem that will

compl" with the needs o! thepresentation logic%raphical user inter!aces'.

User interaction Diagra(s

The second modellin techni$ue in our !ramewor2 is the activit" diaram. ;owever# we need

to specialise the activit" diaram !or user inter!ace desin in the !ollowin sense.

ur activit" diarams include states and transitions. The states represent data output actions#

that is# how the s"stem responds to user interactions showin data %or re$uestin them'. Then

the user can introduce data# and the correspondin event is handled# and speci!ied b" means o!

transitions. Transitions can be conditioned# that is# the handled event is controlled b" means

o! condition# which can be re!erred to dataFbusiness loic or a previous user interaction. In

other words# it is possible more than one transition !rom a state# and to 2now which o! them

will run depends on dataFbusiness loic or the previous user choices. @e call user#interaction

diagramsto this 2ind o! activit" diarams used !or user interaction description.

6ow# it is supposed that each use case in the use case diaram is described b" means a user#

interaction diagram. ;owever# !rom a practical point o! view# it is convenient to use more

than one user#interaction diagram!or describin a use case. This is so because the loic o! a

use case is usuall" too comple3. 4or this reason# a user#interaction diagramcan be deplo"ed

in several user#interaction diagrams# where a part o! the main loic is separatel" described.

4or this reason# user interaction diarams can include states that do not correspond to data

output# rather than representin subdiarams. 6ow# it is desirable in some cases to be able to

combine the loic o! the subdiarams and the main loic. 4or this reason# we will use in the

main diaram transition conditions that can be re!erred to the loic o! the subdiarams.

Activit" diarams describe input and output user interactions. iven that we have decided to

implement our user inter!ace b" means o! Java swin pac2ae# we will consider the JFrame

class as a container class that opens new !rame windows %i! needed'. In addition# raphical

components can be classi!ied as input %a te3t !ield# a button# etc' and output components %a

label# list# etc'. InputFoutput components are associated with terminal states and transitions b"

usin the appropriate stereot"pe. 4or instance# the stereot"pes JTextField# JList# JLabel

are associated with states and the stereot"pe JButtonwith transitions. 0ince the raphical

behaviour concerns with states and transitions# ne3t we will describe them separatel".

!tatescan be stereot"ped or not. 0tereot"ped states represent terminal states# which can be

labelled b" # and stereot"pes. 4or instance# letus !ocus our attention in the Purchaseuse case. 4iure ) shows the whole user-interaction

diaram modelled !or the purchasin process. Initiall"# the behavioural description starts with

an oriinal user-interaction description %4iure )# a'. The behaviour shows how the customer

beins the purchasin process o! $uer"in# addin or removin articles o! the shoppin cart.

A!ter a usual purchasin process# the shoppin s"stem re$uests the customer a card number

and an address to carr" out the shipment# whenever the shoppin cart is not empt". This

diaram shows the raphical and behavioural content o! the applet window where the

purchases can be carried out.


6/30

"ig)re /+ The who,e )ser&interaction diagra( of the $)rchase )se case

The main user#interaction diagram%4iure )# a' is composed o! three states %i.e.# 9uer"

cataloue:# 9+on!irm 5roceed: and 90hoppin cart:'. Two o! them are terminal states %i.e.#

9+on!irm 5roceed: and 9uer" +ataloue:'. A terminal state is described in a new diaram

whose states correspond to raphical elements stereot"ped %!or instance or' and labelled b" a te3t related to the raphical element. The name o! a separate

user#interaction diagramsshould be the same as that o! the state. A non-terminal state is also

described in a separate user-interaction diaram containin one or more non-terminal states.

Transitions can be labelled b" means o! stereotypes# conditionsor both. 4or instance# a

button is connected with a transition b" usin a stereot"pe# and the name o!

the label is the name o! the button. 4or e3ample# a ho! cart transition stereot"ped as

will correspond with a button component called 90how cart:.

Conditionscan represent user c!oicesor businessdata logic. The !irst one is a condition o!

the userHs interaction with a raphical component %related to button or list states'# and the

second one is an internal chec2in condition %not related to the states# but to the internal

process'. 4or e3ample# in our case stud" the selections !rom a list are modelled b" conditions.

6ote in the uer" +ataloue user#interaction diagramhow the "esultslist is modelled b" a

state and a #elected article$condition.

4iure ) shows some transitions %i.e. #Close$# #%xit$or #Proceed$' that correspond with

conditions o! the user c!oice t"pe. The #%xit$ output transition o! the state &uer'

Catalogue%4iure )# a' means that the user has pressed a button called %xit# which has

been de!ined in a separate uer" +ataloue user#interaction diagram. 6evertheless#

conditions li2e the #cart no empt'$condition are businessdata logicconditions# in whichthe human !actor does not ta2e part.


7/30

4urthermore# stereot"ped transitions %buttons in our e3ample' and conditions connect %non'

terminal states with %non' terminal states. A condition would be an output o! a non-terminal

state i! the user interacted with a button or a list component inside the respective non-terminal

state. The usual wa" o! 9conditionFevent: transition can connect %no'terminal states with

%non' terminal states. A conditionFevent transition between states means which conditionshould be present to trier the event. In our case stud"# an event can onl" be a button. 4or

instance# to remove an article !rom the shoppin cart# it must previousl" be selected !rom the

cart list %4iure )# c'.

User Interface Diagra(s

There!ore# in our techni$ue we have obtained a use case diaram toether with a set o! user#

interaction diagrams# !rom which some correspond to use cases and others to states o! use

cases. ;owever# it could be use!ul to have a new version o! the use case diaram# to 2now

what are the main user#interaction diagrams# that is# which are the user#interaction diagrams

correspondin to use cases# and which are the secondary user#interaction diagrams# that is#which are states o! use cases. 4or this reason# we will build a new version o! the use case

diaram# called user#inter"ace diagramas !ollows. The user#inter"ace diagramcontains the

same actors# and use cases o! the use case diaram. In addition# we will add states %as use

cases' o! each use case correspondin to user interaction diarams. In order to connect use

cases# we will use the 9include: or 9eneralization: use case relations.

User %nter"ace /elations!ips

Include and eneralization relationships have the !ollowin meanin in this user#inter"ace

diagram# similarl" to the same relations in the use case diaram. I! a use case contains in its

user interaction diaram a state described b" means o! another user interaction diaram# the

state is also considered as a use case# and the included state %use case' is related in the userinter!ace diaram b" the inclusion relationship with the main use case. ;owever# this is

achieved whenever the loic o! the included use case is not modi!ied b" the main use case.

The loic o! an included use case is modi!ied in the main use case whenever the user

interaction diaram o! the main use case includes transitions that are re!erred to internal states

or conditions o! the included use case. This t"picall" happens when the main use case de!ines

its own loic usin the included use case as a piece o! behaviour# but accessto the included

use case. therwise# that is# whenever the loic o! the included use case is modi!ied# we relate

the main use case and the state %use case' b" means o! the eneralization relationship.

In addition# we have to identi!" a special case o! eneralization relationship# in which we have

a main use case includin a state and the state itsel! is a specialization version o! another use

case. This happens when the user interaction diaram o! the state specialises the user

interaction diaram o! another use case. The specialization consists o! the rep,ace(ent o!

states and transitions o! the user interaction diaram b" means o! more particular states and

transitions with similar semantics. ;ere we are interested in the identi!ication o! similarit"

between interactions !ollowin the same pattern however# the di!!erence in our case consists

o! several 2inds o! UI components and inputFoutput data.

In other words# the specialization o! use cases allows us to build new use cases with a more

comple3 loic containin the specialized use case# and addin transitions and states or

modi!"in the e3istent ones. n the contrar"# the inclusion allows us to build new use caseswith a more comple3 loic without addin or modi!"in the states and transitions o! the


8/30

included use case.

iven that the user inter!ace diaram is a 2ind o! hih-level description o! the user inter!ace#

the developer still could decide not to include in it all the states representin user interaction

diarams. In other words# the user inter!ace diaram represents the set o! windows o! the

s"stem b" means o! use cases. ;owever# there could be more user interaction diarams thanwindows. Usuall"# some user interaction diarams can be built !or deplo"in some states but

the" will not correspond to s"stem windows.

nce user#interaction diagramshave been described# the desiner proceeds to build the user

inter"ace diagram. It contains new use cases that are some o! the non-terminal states o! the

user interaction diarams. In addition# the developer has to identi!" use case relationships in

the new user inter!ace diaram as !ollows.

%nclude relations!ips

Let us consider the purchasin process described in previous user#interaction diagrams.

"ig)re 0+ A )ser&interface diagra( for the p)rchasing process

Purchase use case is a !rame that includes %uses' three other !rames %use cases'( &uer'

catalogue# hopping cart and Confirm Proceed. These use cases are described b"

means o! separate user interaction diarams. In addition# the loic o! the use cases is not

modi!ied in the Purchase user interaction diaram. It interates the loic &uer'

cataloguediaram b" chec2in which buttons %i.e. %xit' the user pressed when %s'he e3its

!rom 0hoppin cart.


9/30

"ig)re 1+ A piece of the )ser interface diagra( of the Ad(inistrator side

The developer can also identi!" an inclusion relationship between Manage catalogueand

(ithdra! article# Modif' articleand Add articleuse cases %4iure >'. In these

cases# !our windows can be optionall" opened %dependin on a menu' !rom the Manage

catalogue window. In addition# the Administrator identification window ismandator" opened !rom the Manage cataloguewindow in order to achieve the s"stemHs

administrator tas2s.

$eneraliation relations!ips

In order to illustrate the eneralizationFspecialization relationship# we will pa" attention to

three use cases( Purchase# &uer' catalogue and &uer' catalogue b'

administrator. In previous sections we have identi!ied two cases o!

eneralizationFspecialization.

"ig)re 2+ A piece of the )ser&interface diagra(

The !irst case is the &uer' catalogueand Purchase case. In this case the Purchase

user-interaction diaram contains a state %use case' that specialises &uer' Cataloguein the

!ollowin sense. The &uer' Catalogueuser interaction diaram describes how to $uer"

the cataloue o! the IG0 b" introducin the searchin criteria and showin the results.

;owever# the Purchase user interaction diaram can interrupt the $uer"in process b"

addin the searched items to the shoppin cart. It is speci!ied b" addin the Add to cart

button as transition !rom %and to' &uer' catalogue. There!ore we can identi!" a

specialization relationship between Purchaseand &uer' Catalogue. It is also supposed

that there will be a window !or &uer' catalogue!rom which Purchaseinherits.

"ig)re 3+ The )ser&interaction diagra( for the 4)er- cata,og)e b- ad(inistrator


10/30

The second case is the relationship between &uer' catalogueand &uer' catalogueb'

administrator. In this case# the administrator is supposed to have hiher privilees !or

$uer"in the cataloue and there!ore the user interaction diaram o! the &uer' catalogue

b' administrator %see 4iures / and B' specialises the &uer' catalogue user

interaction diaram in the !ollowin sense. The states o! the &uer' catalogue b'administrator correspondin with the searchin criteria and results are modi!ied with

respect to the &uer' catalogue. It is supposed that the searchin and result !ields are

di!!erent but the loic is similar. In other words# the &uer' cataloguecan be replaced b"

&uer' catalogueb' administratoriven that the states can be replaced. In this case

we can identi!" a eneralization relationship between them. Analoousl"# (ithdra!

article and Modif' article combine both 2inds o! specialisation# once the"Hve

specialized the &uer' catalogueb' administratorin the same sense that Purchase

specializes &uer' catalogue# and the" specialize indirectl" &uer' catalogue %see

4iure B'.

The complete user inter!ace diaram o! our case stud" can be seen in 4iure C.

"ig)re 5+ The Internet !hopping )ser&interface diagra(


11/30

GUI C,ass Diagra(

The ne3t step o! our model-driven techni$ue consists o! the buildin o! a class diaram !or

UI components. The user#inter"ace diagramsobtained in the previous state ive us the main

windows. 1ach use case connected to an actor can be converted into a window# and i! an actor

is connected to more than one use case# it can be considered a window b" the actor that

invo2es %or embeds' each window o! each use case.

There!ore# the actor window can be a menu window. In addition# in the user#interaction

diagramsobtained !rom use cases# we have also described input and output components !or

data output and re$uest and user events. It ives us the UI components !or each window. I! a

user#interaction diagramhas a state described b" means o! another user#interaction diagram#

we can suppose that the window o! the use case could also contain a separate window !or this

separate tas2. ;owever# now# we have to ta2e into account the user#inter"ace diagramand the

use case relationships. In the case o! inclusion# the loic is also separate# and it is possible to

consider a new window. ;owever# in the case o! eneralizationFspecialization# the window

corresponds with a specialization# and there!ore it is better to consider a new window b" usinthe inheritance relation.

The windows obtained !rom use cases# and the UI components obtained !rom each user#

interaction diagramsallow us to build a class diaram# which we call $U%#class diagram#

where there are windows classes connected b" associations or b" inheritance. In addition#

there are UI component classes# connected b" associations to window classes.

nce the user#inter"ace diagramhas been built and a set o! user#interaction diagrams has

been obtained# now we can enerate a $U%#class diagram.

The $U%#class diagram is built !rom Java s)ing classes. In the method# each use casecorresponds with a !rame class. Use cases are translated into classes with the same name as

these use cases. The translated classes specialise a Java 0rameclass. The components o! the

!rame %use case' are described in user#interaction diagrams. A terminal state is translated into

that Java s)ing class represented b" the stereot"pe o! the state. The Java s)ing class is

connected !rom the container class. 4or e3ample# those terminal states stereot"ped as

are translated into a 12e-t0ield class in the $U%#class diagram.

0omethin similar happens with the rest o! stereot"ped states and transitions. 4iures K to 8)

show the main classes o! $U%#class diagramo! the customerHs side.

As it can be seen in these !iures# the stereot"ped states and transitions in the user#interaction

diagramsare translated into Java classes in the $U%#class diagram. The stereot"pe name o! atransition or state is translated into the appropriate 1ava s)ing class. 4or e3ample# the

stereot"pe o! the Proceed transition that appears in the 5urchase user#

interaction diagram%see 4iure )# a' is translated into a JButtonclass.


12/30

"ig)re 6+ $)rchase c,ass obtained fro( )ser&interface diagra(s and )ser&interaction diagra(s

"ig)re 7+ 8)er- Cata,og)e c,ass obtained fro( )ser&interface diagra(s and )ser&interaction diagra(s


13/30

"ig)re *9+ !hopping Cart c,ass obtained fro( )ser&interface diagra(s and )ser&interaction diagra(s

"ig)re **+ Confir( $roceed c,ass obtained fro( )ser&interface diagra(s and )ser&interaction diagra(s

"ig)re */+ Confir( Re(o:e Artic,e c,ass obtained fro( )ser&interface diagra(s and )ser&interaction

diagra(s


14/30

GUI $rotot-pes

4inall"# rapid UI protot"pes could be obtained !rom the $U%#class diagram. 4iure 8# modellin it with user-

inter!ace and user#interaction diagrams%4iures ) and


18/30

In this e3ample# these !ive use cases lead to !ive Java !iles o! 4rame t"pe. Their names are

obtained !rom the use case name %which will be the same as the one !or the user-interaction

diaram# one per use case'. I! compound nouns e3ist then a simple name is created with the

initials o! each word in capital letters %Table 8'.

User-interface &user-interaction name

File name

5urchase 5urchase.ava

uer" cataloue uer"+ataloue.ava

0hoppin cart 0hoppin+art.ava

+on!irm 5roceed +on!irm5roceed

+on!irm remove article +on!irmDemoveArticle.ava

Tab,e *+ Correspondence between diagra( na(es and fi,e na(es

+lasses e3tend 10rameclass and present a eneral structure o! implementation based on

!rames %see Table )'. The basic structure o! !rame protot"pe created in the diarams-to-code

transition# is composed o! !our sections( one headin# one class constructor# one initiator o!

the !rame %jb%nit' and one basic protot"pe o! the implementation o! the detected methods

%related with the loic o! presentation'. In the headin %labelled with +-- ./01components

-+' the attributes are considered to be raphical components that have been detected in the

correspondin user#interaction diagram. The class constructor is the same !or all code !iles

created %e3cept !or the name o! the constructor'. In the initiator o! the !rame %jb%nit' it is

included the code lines that model the raphical content o! the window. The desiner should

establish the position and size o! the raphical components o! the !rame later on# as the code

enerated is ust a protot"pe o! the window. In the !ourth section o! the 4rame# it is createdthe basic methods related to the interaction o! the user with the raphic elements that heFshe

can interact with( buttons# lists and te3t !ields.

User-InterfaceDiagram

Code generation

&uer'catalogue

import 2a)a,a!t,-3import 2a)ax,s!ing,-3

public class&uer'Catalogue extendsJFrame 4 +-- ./01components -+ ,,,

public&uer'Catalogue56 4 try4 2b1nit563 7 catch5%xception e6 4 e,printtac8Trace563 7 7private void2b1nit56 throws%xception 4 ,,,7

++ Methods implementation ,,,7

Tab,e /+ Genera, str)ct)re of 8)er-Cata,og)e


19/30

GUI co(ponents

In order to anal"ze how translatin the diarams components to code inside the 4rame# weHll

use aain the 5urchase e3ample in 4iure 8/.

The behaviour o! the 5urchase window beins with the initial state 8uery catalogue

%represented b" the desiner as an inheritance o! behaviour in the user#inter"ace diagram'. As

it can be observed# the 5urchase window inherits all the raphical components %and

behaviour' o! the 9uer" cataloue: window and it also adds the Add to cart# ho! cart

and Proceedbuttons# which are not activated. 4rom the initial state 8uery catalogue# the

!our out comin transitions correspond to interactions with the buttons o! the window and

deal to new states. @hat the diaram shows !rom its initial state is the !ollowin( I! there is an

element selected !rom the list# then it is activated the button to add one element to cart.

# selected article $ + Add to cart

I! the cart is not empt" %#cart not empt'$' it is activated the button to show the content o!the cart and ma2e the purchase o! the products in the cart.

# cart not empt' $ + hopping cart

# cart not empt' $ + Proceed

The transition #%xit$#in the initial 8uery cataloguestate# corresponds with the operation o!

clic2in on the %xitbutton inside the behaviour diaram o! the window %4rame'( 8uery

catalogue%window inherited b" 5urchase'. The same happens with the other two transitions

that reach this initial state !rom the state Con"irm proceed%window to con!irm the purchase'.

4or this e3ample there are !our modelled raphical components( labels# te3t !ields# lists and

buttons. In table


20/30

The columns 9Attribute: and 9+lass: represent the name o! the attribute and the base class

instantiated in the code enerated. The criterion !ollowed to establish the name enerated in

the code is( name92ype. That is# as a name it is used the same name indicated in the

interaction diaram in capital letters# !ollowed b" a h"phen %i.e. 9:' and then !inished b"

base t"pe %Label# Gutton# List# etc.'. I! the oriinal name has ot blan2s in between# the" are

substituted b" h"phens. 4or e3ample# the label(

hopping cart

It is translated to the name o! the attribute 0hoppin cart button and then it is enerated the

!ollowin Java code(

publicJLabel shopping9cart9Button : newJLabel563

The 9InFut: column represents an e3it !romFto the user %or window'. 0o# !or e3ample# one

stereot"pe label will represent a te3t shown !rom the s"stem towards the user %window'

whereas the button %accordin to its raphic behaviour' represents an income action%interaction' !rom the user towards the s"stem. The 9te3t!ields: and lists stereot"pes represent

both options( the s"stem shows and modi!ies the content o! these raphic components and at

the same time# the user can either write %te-t"ield' or choose %list' in these raphic

components. The 9ut: components have no correspondence with the code# whereas the 9In:

components have correspondence with one Listener class.

The 9listener: column indicates whether a raphical component is moved b" means o! a

Listener class. This t"pe o! class allows the class creatin it !or listen the behaviour o! the

raphic component with the user. ItHs usual to use listener in buttons and lists %weHll stud"

these later'.

The 90FT: column is re!erred to whether the raphic component corresponds with a state or a

transition in the user-interaction diaram.

4inall"# 9Mar2up: column is re!erred to the mar2 protot"pe created be!ore the translated code.

This mar2 helps to identi!" the content o! the te3t when the prorammer has to rewrite or

insert the new code to add and complete the !unctionalit" o! the windows.

Mapping !tates into Code

As previousl" said# the states o! a user-interaction diaram can be re!erred to terminal states

%Label# Te3t!ield# List' and non terminal states

:on terminal states

Let us bein with the user#interaction diagram 5urchase %see 4iure 8/'. The diaram is

composed o! three non terminal states. @e should remember that a non terminal state is a

state whose behaviour is de!ined separatel" !rom other diaram o! interaction. 4or e3ample#

the 8uery catalogue# Con"irm proceed and 6!opping cart states will be de!ined in

independent user-interaction diarams havin the same name as the correspondin state. In

the user#inter"ace diagram# the 8uery catalogue is established b" the desiner as an

inheritance !or 5urchase# whereas the other two states %which are 9use cases: and there!ore

windows' are established as conclusions in the user#inter"ace diagram%i.e. '.

The translation is as !ollows(


21/30

public classPurchase extends&uer'Catalogue 4

+-- ./01 -+ hoppingCart shoppingcart9/01 : newhoppingCart563

+-- ./01 -+

ConfirmProceed confirmproceed9/01 : newConfirmProceed563 ,,,

6ote that 5urchase class inherits uer"+ataloue in the code. The two 9include: relationships

are included in the code in the headin section %one o! the !our that 4rame has ot'. n the

code line a ./01mar2 is inserted to trace an inclusion o! the window in the process o!

translation. Moreover# the criterion !or the name o! the UI variable is considerin the

oriinal name o! the included window !ollowed b" 9UI:.

2erminal states

Terminal states %Label#List# 2e-t0ield' are translated into code lines in the headin# initiationo! 4rame %jb%nit+ and implementation o! methods sections %onl" in List'. Appendi3 A contains

the Java code patterns translated !rom the raphical components o! the user#interaction

diagram. LetHs see each o! them separatel".

4or a Label case three basic code lines are enerated( one in the headin to de!ine the t"pe

%1Label' and two in the initiation %jb%nit' to establish the component. In 4iure 8B# it is shown

a bit o! code enerated to the label state 9+on!irm remove article:. The code line < creates

one variable o!1Labelt"pe. 6ote how the name o! the variable is obtained !rom the name

iven to the state in the user#interaction diagram. The line C establishes the

te3t that will appear in the window. Line = adds the label to the container. Lines )# B and = are

mar2s established previousl" that are inserted in the code to !acilitate the identi!ication o!

each part o! the code.

"ig)re *3+ The Confirm remove article&,abe, state in 8)er- Cata,og)e

In Table A.) o! Appendi3 A shows the Java code pattern that is translated !rom the

raphical components o! user#interaction diagram.

4or the 9te3t !ields:# !ive basic code lines are enerated. Two o! them are enerated in the

headin to de!ine two raphical components in the headin( one JTextField and one

Jlabel to name it in the window. The other three code lines are enerated in the initiationsection o! !rame %jb%nit'. 4or e3ample# 4iure 8C shows how translatin the terminal state


22/30

0earchin criteria %in the user#interaction diagramo! !rame 8uery catalogue' into a code in

two components %lines ) and


23/30

Lines /# B# and C are enerated in the headin %a!ter +-- ./01components -+' de!inin

the name o! the variables o! the three raphical components. Aain the criterion used !or the

namin o! the variables is the same as that one used in previous e3amples. In the initiation

section %jb%nit' the !ollowin code is created. 4irstl"# the label te3t is established in the panel

%line 88'. Then# an event o! listenert"pe is used to catch the interactions o! the user with thelist when heFshe presses the elements o! the list. There!ore# in line 8> there is the container

6crollpanet"pe where the list is and !rom lines 8/ to 8K there is the listenerevent on the list.

To do so# the librar" 2a)ax,s!ing,e)ent,- is imported %line 8'. Lines )8 and )) add

raphical elements to the panel. 4inall"# the method implementation section %line )B' includes

the protot"pe o! the method used each time the user presses on an element !rom the list. The

implementation o! the method is a later tas2 o! the prorammer.

In table A.< o! Appendi3 A it is shown the Java code pattern translated !rom 1Listraphical

components o! user#interaction diagram.

Mapping Transitions into Code

Transitions correspond with buttons %' or chanes in the internal state o! the

data loic. The" are represented in the diaram as a condition mar2up %p.e.# #cart not

empt'$ o #Close$'. Table A.8 %Apendi3 A' shows the Java code pattern !or a raphical

component translated !rom the user#interaction diagram.

Transitions represent raphical components that enerate code at several sections o! the

proram. The translation into code is the more important issue in the code eneration process#

since it reveals the use!ull" o! the user-interaction diarams !or the traceabilit" o! the

interaction o! the user with the raphical components o! the window and also how that

%window' responds to the user. To e3plain the translation o! states to code# we will use aainthe 5urchase windows sample. In 4iure 8= we show %at the riht side' the two related user#

interaction diagramso! the 5urchase window %showed at le!t side'.

"ig)re *7+ The $)rchase window

Demember that the s"stemHs desiner has described the 5urchase window !rom the 8uery

cataloguewindow# which represents a state in the user#interaction diagram o! the 5urchase

window. This state inherits the inner behaviour o! the 8uery catalogue %whose behavioural


24/30

interaction is shown at the riht-lower side in 4iure 8='. It arrives at two possible states

throuh !our transitions !rom the state 8uery catalogue( %a' see the state o! the cart %6!opping

cartstate' or %b' carr" out the purchase o! the products stored in the cart %Con"irm 7roceed

state'. Goth states are reached !rom the 5urchase window throuh the buttons ho! cart

and Proceed. In the state# a conditioned transition has been included !or reachin these two

windows !rom 5urchase( that the cart is no empt". In other words# a conditioned button-transition corresponds with an operation o! activationFdeactivation o! buttons.

0ince these three buttons are conditioned b" a selection action in a list# a listeneroperation is

enerated on the list in the7urc!ase class. Demember that both the list and the most o! the

raphical components o! the 5urchase window are inherited !rom 8uery Cataloguewindow

%i.e.# public class Purchase extends &uer'Catalogue'# and there!ore the

operation listeneris done on the superclass which contains the list.

+-- .List -+super,results9List,addListelectionListener5 new2a)ax,s!ing,e)ent,ListelectionListener56 4 public void)alueChanged5Listelection%)ent e6 4 selected9articles9List9&uer'Catalogue9/01563 7 7 63

In this wa"# whenever the user presses on the list# an event is captured# which calls to the

!unction selected9articles9List9&uer'Catalogue9/0156. The name o! the method

is established b" the te3t included in the condition o! the transition in the user#interaction

diagram. 4or instance# a button-transition Add to cartcontainin a condition #selected

articles$means that the class %!rame' 5urchase enables the button Add to cartin the

window i! and onl" i! an element o! the list has been selected in other case# the button will

remain disabled %see 4iure 8='. In case o! e3ist a selected element in the list# the button is

activated and the transition leads aain to the same state# to include the selected element %and

others' to the list. This enerates the !ollowin lines o! code !or the method on the listenedelement.

+-- .List -+voidselected9articles9List9&uer'Catalogue9/0156 4 if5results9List,getelected1ndex56::;6 add9to9cart9Button,set%nabled5false63 elseadd9to9cart9Button,set%nabled5true637

The activation o! the button %add9to9cart,Button,set%nabled' implies the button has

been be!ore declared in the panel# created and added.

public classPurchase extends&uer'Catalogue 4 +-- ./01components -+publicJButton add9to9cart9Button : newJButton563

private void 2b1nit56 throws%xception 4 +-- .Button -+ name9Button,setText5=Add to cart=63 name9Button,addActionListener5 new2a)a,a!t,e)ent,ActionListener56 4 public void actionPerformed5Action%)ent e6 4 add9to9cart9Button9nameClass9/01563 7 763

+-- .Panel -+ this,getContentPane56,add5add9to9cart9Button null63 7 ++ end 2b1nit56


25/30

++ Methods ,,, +-- Button -+ voidadd9to9cart9Button9class?ame9/0156 4 ,,, 77

4ollowin the trace o! the e3ample# the other two button-transitions that leave the state 8uery

catalogueremain disabled until the cart is not empt" %button Add to cart'(

+-- .Button -+voidadd9to9cart9Button9Purchase9/0156 4 sho!9cart9Button,set%nabled5true63

proceed9Button,set%nabled5true637

nce the buttons is activated# two other states can be reached !rom the state 8uery catalogue(

%a' the state 6!opping cart# whether the button ho! cart is pressed or %b' the state

Con"irm 7roceed, whether the button Proceed is pressed. 0ince both states are not

stereot"ped# the" are translated into two independent windows %!rames'# with independent

behaviours in user#interaction diagrams# also independent %i.e.# with an initial state andanother end state'.

6evertheless# this encapsulated behaviour %i.e.# a user#interaction diagram' can be interrupted

b" means o! conditioned simple transitions %or simpl" 9simple transitions:'. 0imple

transitions are those transitions that are labelled onl" b" a condition %p.e.# #creen$#

#Accept$# #Close$and #%xit$'. These transitions re!er to an action o! pressin a button

that e3ists inside the non-terminal state %a window'. 4or instance# the button-transitions

#Accept$ and #creen$ re!er that# bein in the state %!rame' Con"irm 7roceed the user

presses one o! these buttons# and one returns to the state %!rame' 8uery catalogue. The same

!or the transition #Close$.

6evertheless there is a special case o! simple transition( that one that does not come !rom

another state# but it departs !rom the taret state. 4or e3ample# the simple transition #%xit$

means that there has been pressed the button %xitinside the !rame 8uery catalogue# whose

behaviour is de!ined in another independent user#interaction diagram%in which the button is

de!ined'. In an" case# both the simple-transitions o! the t"pe#Accept$or o! the t"pe #%xit$

the interpretation in the code is re!lected b" means o! a listeneroperation on those buttons o!

the window %class' containin the buttons# that interrupts the normal interaction se$uence o!

the above mentioned class.

public classPurchase extends&uer'Catalogue 4 ,,, private void2b1nit56 throws%xception 4

,,, ++ Listener on children

+-- .Button -+ shoppingcart9/01,close9Button,addActionListener5 new2a)a,a!t,e)ent,ActionListener56 4 public voidactionPerformed5Action%)ent e6 4 close9Button9hoppingCart9/01563 7 7 63 +-- .Button -+ confirmproceed9/01,accept9Button,addActionListener5 ,,, 63 +-- .Button -+ confirmproceed9/01,cancel9Button,addActionListener5 ,,, 63

7 ,,,7


26/30

The Appendi3 G partiall" shows the ava code o! one o! the !ive classes o! the proect

e3ample( the class 6!oppingCart. This in!ormation is available in the !ollowin web pae(

http*++indalog,ual,es+mdd+purchase.

CONCLU!ION! AND "UTUR# >ORK

In this chapter# we have studied a model-driven development techni$ue !or UI desin. @e

have de!ined a new 2ind o! UML diaram %i.e. the user#inter"ace diagram' which specialises

the use case diaram !or user inter!ace desin. In addition# we have shown how to describe

use cases b" means o! specialized activit" diarams %user#interaction diagrams'# in order to

speci!" the user inter!ace o! each use case. 4inall"# we have shown how to enerate class

diarams !or UI# and how to build rapid protot"pes !or the user inter!ace. As !uture wor2#

we plan to stud" the !ollowin e3tensions o! our wor2(

%a' interate the user inter!ace view with the data and business loic

%b' incorporate our method in a +A01 tool in order to automate it%c' interate our techni$ue in the whole development process.

ACKNO>L#DG#M#NT!

This wor2 has been partiall" supported b" the 0panish proect o! the Ministr" o! 0cience and

Technolo" TI6)**/-*=)*C-+*) %8*'# B


27/30

Use +ases %Tech. Dep.'. Dational 0o!tware.

Iloi3. %)**B'./!apsody .


28/30

A$$#NDI? A+ GUI COD# $ATT#RN!

User-Interactionstereotype

Code generation


29/30

User-Interactionstereotype

Code generation

name

import 2a)ax,s!ing,e)ent,-3

public classclass?ame extendsJFrame 4 +-- ./01components -+

publicJLabel name9Label : newJLabel563publicJcrollPane name9crollPane : newJcrollPane563publicJList name9List : newJList563

private void 2b1nit56 throws%xception 4 +-- .Label -+ name9Label,setText5=name=63

+-- .List -+ name9crollPane,getie!port56,add5name9List null63 name9List,addListelectionListener5 new2a)ax,s!ing,e)ent,ListelectionListener56 4 public void )alueChanged5Listelection%)ent e6 4 selected9articles9List9hoppingCart9/01563 7 763

+-- .Panel -+ this,getContentPane56,add5name9Label null63 this,getContentPane56,add5name9crollPane null63 7 ++ end 2b1nit56

+--- - Method T@1 -+

+-- .List -+ )oid selected9articles9List9hoppingCart9/0156 4 ,,, 77

A+1+ Mapping liststo code


30/30

A$$#NDI? B+ T# !O$$ING CART "RAM#

public classhoppingCart extendsJFrame 4

+-- ./01components -+publicJLabel shopping9cart9Label : newJLabel563publicJLabel selected9articles9Label : newJLabel563

publicJButton remo)e9article9Button : newJButton563publicJButton close9Button : newJButton563publicJcrollPane selected9articles9crollPane : newJcrollPane563publicJList selected9articles9List : newJList563

+-- ./01 -+ Confirm"emo)eArticle confirmremo)earticle9/01 : newConfirm"emo)eArticle563

publichoppingCart56 4 ++ Constructor 7

privatevoid2b1nit56 throws%xception 4 +-- .Label -+ shopping9cart9Label,setText5=hopping Cart=63 ,,,

+-- .Button -+ remo)e9article9Button,setText5="emo)e article=63 remo)e9article9Button,set%nabled5false63 remo)e9article9Button,addActionListener5new2a)a,a!t,e)ent,ActionListener56 4 public )oid actionPerformed5Action%)ent e6 4 remo)e9article9Button9hoppingCart9/01563 7 763 ,,,

+-- .List -+ selected9articles9crollPane,getie!port56,add5selected9articles9List null63 selected9articles9List,addListelectionListener5 ,,, 63

+-- .Panel -+ this,getContentPane56,add5close9Button null63 ,,,

+--- - Listener on children

-+ confirmremo)earticle9/01,cancel9Button,addActionListener5 ,,, 63 confirmremo)earticle9/01,accept9Button,addActionListener5 ,,, 63 7 ++ end 2b1nit56

+--- - Methods T@1 -+

+-- .Button -+ voidremo)e9article9Button9hoppingCart9/0156 4 this,set%nabled5false63 confirmremo)earticle9/01,setisible5true63 7

+-- .Button -+ voidclose9Button9hoppingCart9/0156 4 this,setisible5false63 7

+-- .List -+ voidselected9articles9List9hoppingCart9/0156 4 remo)e9article9Button,set%nabled5true63 7

+--- - Methods children -+

+-- .Button -+ voidcancel9Button9Confirm"emo)eArticle9/0156 4 this,set%nabled5true63 7

+-- .Button -+ voidaccept9Button9Confirm"emo)eArticle9/0156 4 this,set%nabled5true63 77

Documents

AlmendrosandIribarne Chapter Accepted (1)