Blekinge Institute of Technology 2005-05-31

Computer Science 41-60 points

Spring 2005










A comparison of UML and WAI-UML
for lhe design of Web appIicalions






Authnrs:
Heinz Andersson
MikaeI Guslavsson

5upcrvisnr:
Ieng Zhang


Abstract
Since Web appIicalions are very compIex, compared lo lradilionaI cIienl/server
appIicalions, Web appIicalion design vilh lhe UML can be oblrusiveIy hard for a
modeIIer. The grounds are lhal lhe UML does nol define lhe correcl semanlics lo
be abIe lo visuaIize a veb appIicalion correclIy. This is a quaIilalive reduclion
sludy vhere ve have used inlervievs and our ovn experience during lhe
redesign of a UML-modeIIed e-commerce appIicalion vilh WAI-UML. Using lhe
fIov of a case sludy ve have lried lo see if ve can improve lhree quaIily
allribules of a compIele design. Siakcnc|!cr ccnnunicaiicn refIecls lhe need of
unambiguous design arlefacls lhal are easy lo undersland and lhal mediale lhe
reaI message of lhe use-case. The ccn!iiicn of lhe design arlefacls shouId provide
arlefacls lhal resembIe reaIily and lhal nol are misIeading and provide for
verificalion and vaIidalion of lhe requiremenls. The Iasl allribule nainiaina|i|iiu
shouId provide means for easy mainlenance and updales. We found lhal WAI-
UML can improve lhese quaIily allribules in a design bul lhe impacl il has on
lhem is dependenl on lvo ma|or aspecls. The firsl aspecl concerns lhe designers'
|udgmenl of delaiI in a design. A delaiIed design can be good considering
requiremenls and use-case lraceabiIily and verificalion, bul prohibil
communicalion. MainlainabiIily can aIso be improved in a delaiIed design
because lhe diagrams are Iess abslracl and a lruer piclure of lhe appIicalion. The
second aspecl is lhal il depends on lhe knovIedge possessed of lhe semanlics by
lhe peopIe in conlacl vilh lhe design documenls. Due lo lhe lime aspecl lhe
peopIe vorking in lhe induslry lhal ve inlervieved vere reIuclanl lo modeIIing
a Web appIicalion al aII. They lhoughl il vouId lake a Iong lime lo Iearn WAI-
UML bul aIso for execuling a design phase.

Kcywnrds
Web appIicalion, Design, UML, WAI-UML, MainlainabiIily, SlakehoIder
communicalion, Condilion.

Acknnw!cdgcmcnt
Hereby ve vanl lo forvard our gralilude lo our supervisor for posilive feedback
and for meeling our queslions in an informalive vay. We aIso vouId Iike lo
shov our gralilude lo lhe inlervievees lhal gave of lhere vaIuabIe lime and
opinions. IinaIIy, ve send our lhanks lo aII olher peopIe lhal have been a
supporl during lhe execulion of lhis lhesis.


Tab!c nI cnntcnts

1 Inlroduclion.............................................................................................................. 1
1.1 Our background............................................................................................... 1
1.2 IrobIem descriplion......................................................................................... 1
1.3 Hypolhesis ........................................................................................................ 3
1.4 GoaIs and molivalions..................................................................................... 4
1.5 DeIimilalion ...................................................................................................... 5
2 Theorelic background.............................................................................................. 5
2.1 Inlroduclion lo Web appIicalions.................................................................. 7
2.1.1 Archileclures............................................................................................. 7
2.1.2 .NIT concepl............................................................................................. 7
2.2 Why ve modeI soflvare` ............................................................................... 8
2.3 Slandard UML.................................................................................................. 9
2.3.1 Descriplion................................................................................................ 9
2.3.2 UML nolalion ......................................................................................... 10
2.3.3 UML exlendibiIily.................................................................................. 10
2.3.4 Web appIicalion modeIIing vilh UML............................................... 11
2.4 W2000............................................................................................................... 11
2.4.1 Web appIicalion modeIIing vilh W2000 ............................................ 11
2.5 WebML............................................................................................................ 12
2.5.1 Web appIicalion modeIIing vilh WebML.......................................... 12
2.6 WAI-UML ...................................................................................................... 13
2.6.1 Nolalion................................................................................................... 13
2.6.2 Unified Irocess vilh WAI-UML ........................................................ 14
2.6.3 Web appIicalion modeIIing vilh WAI-UML.................................... 14
3 Melhod..................................................................................................................... 15
3.1 Scienlific melhod and approach .................................................................. 15
3.1.1 Case sludy............................................................................................... 15
3.1.2 OuaIilalive vs. quanlilalive research................................................... 16
3.1.3 AnaIylicaI approach - reduclionism.................................................... 16
3.1.4 Approach................................................................................................. 17
3.2 IraclicaI vork................................................................................................. 17
3.2.1 I-commerce background...................................................................... 18
3.2.2 DeIimilalion ............................................................................................ 18
3.2.3 Conduclion.............................................................................................. 18
3.3 IvaIualion ....................................................................................................... 19
3.3.1 Ovn evaIualion...................................................................................... 19


3.3.2 Dala coIIeclion melhod ......................................................................... 21
4 ReaIizalion............................................................................................................... 21
4.1 IraclicaI vork................................................................................................. 21
4.2 IvaIualion ....................................................................................................... 22
4.2.1 Inlervievs................................................................................................ 23
5 ResuIl and anaIyze................................................................................................. 25
5.1 Ovn evaIualion.............................................................................................. 25
5.1.1 Verificalion and vaIidalion................................................................... 26
5.1.2 Ixperience-based assessmenl............................................................... 27
5.2 ResuIl and anaIyze of lhe inlervievs .......................................................... 31
5.2.1 Condilion................................................................................................. 31
5.2.2 Communicalion...................................................................................... 32
5.2.3 MainlainabiIily ....................................................................................... 33
5.2.4 Ierformance............................................................................................ 34
5.2.5 Inlervievee opinion............................................................................... 34
6 Discussion ............................................................................................................... 34
6.1 Condilion......................................................................................................... 35
6.2 Communicalion.............................................................................................. 36
6.3 MainlainabiIily ............................................................................................... 37
6.4 Tesl of hypolhesis .......................................................................................... 37
6.5 GoaIs ................................................................................................................ 39
6.6 Discussion of melhods .................................................................................. 39
6.7 Summary of lhe discussion........................................................................... 41
7 ConcIusion .............................................................................................................. 41
8 References ............................................................................................................... 43
9 Appendix one Use-cases .................................................................................... 45
9.1 Place order ........................................................................................................ 45
9.1.1 IIov of Ivenls ........................................................................................ 45
9.1.2 Ire-condilions......................................................................................... 46
9.1.3 Iosl-condilions....................................................................................... 46
9.2 ArlicIe search .................................................................................................. 46
9.2.1 IIov of Ivenls ........................................................................................ 46
9.2.2 Ire-condilions......................................................................................... 47
9.2.3 Iosl-condilions....................................................................................... 47
10 Appendix lvo - Requiremenls......................................................................... 47
10.1 IIace order....................................................................................................... 47
10.1.1 Order rovs.............................................................................................. 47
10.1.2 Credil Iimil .............................................................................................. 47
10.1.3 Order rov conlenl.................................................................................. 47
10.1.4 Order rov conlenl fiIIed in by lhe cuslomer...................................... 47


10.1.5 Change order rovs ................................................................................ 47
10.1.6 Allach a message lo lhe order rov...................................................... 47
10.1.7 Navigaling in lhe pIace order viev..................................................... 48
10.1.8 DeIeling order rovs............................................................................... 48
10.2 Confirm order................................................................................................. 48
10.2.1 Send nole aIong vilh lhe order............................................................ 48
10.2.2 Confirming senl order........................................................................... 48
10.2.3 Confirm orders vilh passvords.......................................................... 48
10.2.4 Sending order ......................................................................................... 48
10.2.5 Irice dispIay............................................................................................ 48
10.2.6 Credil Iimil .............................................................................................. 48
10.3 ArlicIe search .................................................................................................. 49
10.3.1 Search for arlicIes using arlicIe number ............................................. 49
10.3.2 Search for arlicIes using lhe arlicIe name ........................................... 49
10.3.3 Order arlicIes from lhe arlicIe search.................................................. 49
10.3.4 Nolificalion of arlicIes added lo lhe order ......................................... 49
11 Appendix lhree UML and WAI-UML designs.......................................... 49
11.1 OId e-commerce design - UML.................................................................... 50
11.1.1 UML navigalion map ............................................................................ 50
11.1.2 UML cIass diagram IIace Order....................................................... 51
11.1.3 UML cIass diagram ArlicIe search.................................................... 51
11.1.4 UML cIass diagram Creale order...................................................... 52
11.1.5 UML cIass diagram Confirm order .................................................. 52
11.1.6 UML cIass diagram Logic package................................................... 53
11.1.7 UML coIIaboralion diagram ArlicIe search..................................... 54
11.1.8 UML coIIaboralion diagram Creale nev order .............................. 54
11.1.9 UML coIIaboralion diagram IIace order......................................... 55
11.1.10 UML coIIaboralion diagram Confirm order ............................... 56
11.2 I-commerce redesign vilh WAI-UML...................................................... 57
11.2.1 WAI-UML user Ixperience NavigalionaI map............................. 57
11.2.2 WAI-UML cIass diagram ArlicIe search......................................... 58
11.2.3 WAI-UML cIass diagram IIace order ............................................. 59
11.2.4 WAI-UML cIass diagram Logic package........................................ 60
11.2.5 WAI-UML sequence diagram ArlicIe search................................. 61
11.2.6 WAI-UML sequence diagram Creale order................................... 62
11.2.7 WAI-UML sequence diagram Add arlicIe ..................................... 63
11.2.8 WAI-UML sequence diagram DeIele ilem..................................... 64
11.2.9 WAI-UML sequence diagram Confirm order ............................... 65
12 Appendix four WAI-UML nolalion............................................................ 65
13 Appendix five OriginaI mock-ups................................................................ 67


13.1 Mock-up - ArlicIe search............................................................................... 67
13.2 Mock-up Creale order ................................................................................ 67
13.3 Mock-up IIace order .................................................................................. 68
13.4 Mock-up Confirm order............................................................................. 68
14 Appendix six Inlerviev ansvers .................................................................. 69
14.1 Ansvers........................................................................................................... 69
14.1.1 GeneraI Oueslions.................................................................................. 69
14.1.2 Design queslions .................................................................................... 70
14.1.3 IoIIov-up queslions .............................................................................. 75



1
1 Intrnductinn
In lhis chapler, ve presenl lhe background probIem and hypolhesis for
execuling lhe lhesis aIong vilh our background in lhe area of Web appIicalion
deveIopmenl.

1.1 Our buckground
We are sludenls al Iekinge Inslilule of TechnoIogy from lhe fieId of compuler
science and soflvare engineering. The vork in lhis lhesis is based on queslions
vhich aroused during pro|ecl courses ve allended vilhin our programmes.

The lheorelicaI background and our previous knovIedge are based on lhe pre-
exisling knovIedge of lhe UML (Unified ModeIIing Language) as laughl in lhe
course ob|ecl-orienled syslems deveIopmenl. We do nol cIaim lo be experls in
lhe UML neilher in Web appIicalion deveIopmenl. Wilh lhis experience and
lhese non-experl aspecls in mind ve sel lhe ground for approaching lhe lhesis.

1.2 ProbIem descrltlon
InvoIvemenl in pasl veb appIicalion deveIopmenl has risen a fev queslions
aboul hov suilabIe UML is for lhe modeIIing of Web appIicalions. A veb
appIicalion is more compIex lo modeI lhan a lradilionaI desklop appIicalion. Il is
more compIex because il incIudes many eIemenls and a mixlure of differenl
programming lechniques. Il is very hard, if nol impossibIe, lo use lhe slandard
UML for modeIIing a Web appIicalion. Many researchers agree on lhis, for
exampIe ConaIIen (2002), aresi, Garzollo & IaoIini (2001) and Ceri, IralerneIIi &
ongio (2000).

Since a Web appIicalion is composed of highIy dislribuled Iogic conlenl and lhe
facl lhal il is nol onIy buiIl vilh ob|ecls bul aIso HTML (Hyperlexl Markup
Language) veb pages, scripls, hyperIinks and forms, a Web appIicalion cannol in
an easy vay be modeIIed vilh slandard UML. We lhink lhal lhe cause of lhis is
lhal lhe slandard UML, deveIoped by OMG (Ob|ecl Managemenl Group), is
deveIoped vilh ob|ecl-orienlalion in mind and lhe facl lhal a Web page is nol
ob|ecl-orienled in nalure, vhich ConaIIen (1998, ConcIusion seclion) aIso agrees
on. Some viII see a Web page as an ob|ecl in compIiance vilh lhe DOM
(Documenl Ob|ecl ModeI) bul ve sliII can nol easiIy modeI a documenl based on
lhe DOM vilh lhe UML. To pul il simpIy, lhe UML does nol define enough or

2
lhe correcl semanlics lo describe lhe compIexily of a Web appIicalion in a design
arlefacl. ConaIIen approves lo lhis slalemenl.

| jcun! |cin OMT an! UMI ina!cuaic ic cxprcss inc inings | incugni ucrc inpcriani
in a Wc| app|icaiicn. (ConaIIen, 2002, Ireface xvi)

The difficuIlies during previous design efforls, using slandard UML, have
circuIaled in five ma|or probIem areas.

Ambigunus dcsign and abstract dcsign - Since lhe UML does nol define lhe
correcl semanlics for modeIIing Web appIicalions, efforls on modeIIing has Ied lo
lhal lhe designers used ad-hoc soIulions for modeIIing, maybe nol using lhe
correcl semanlics lo describe lhe compIex behaviour. The designers have lo
describe vhal lhey describe in lhe modeI vilh addilionaI lexl documenls vhich
means a Iol more vork. The design viII be ambiguous and abslracl lo lhe readers
of il and require a Iol of efforl lo undersland.

Cnmp!cx tn pcrInrm ana!ysis and dcsign - Due lo lhe ambiguousness and
abslraclness il is compIex for lhe engineering leam lo perform lhe anaIysis and
design phases because il is hard lo express in lhe design lhe message lhey vanl
lo mediale.

Nnt cnnIirmcd rcquircmcnts and usc-casc - In an abslracl design lhe
requiremenls and use-cases mighl nol be fuIfiIIed by lhe design arlefacls. Iven if
lhe use-cases and requiremenls shouId be fuIfiIIed, il is nol easy lo lrace lhem in
lhe design arlefacls and lhe deveIopers have lo make guesses and use lhe
requiremenls specificalion and use-cases as an aid during lhe impIemenlalion
phase.

DiIIicu!tics tn cnmmunicatc amnng thc stakchn!dcrs - Differenl slakehoIders
mighl nol undersland an abslracl design and lhink lhal il does differenl lhings
inslead of lhe inlended lasks. Il is nol onIy imporlanl lo communicale lhe design
lo cuslomers and execulives bul aIso lo communicale il lo programmers and
olher peopIe in lhe deveIopmenl leam. An abslracl design does nol mediale
belveen slakehoIders and requires addilionaI documenls, such as requiremenls
specificalion and use-cases, and olher descriplions of lhe syslem. This requires
more inleraclion, for a programmer, vilh lhe documenlalion because lhe
programmer need lo inlerprel a Iol of lexl and descriplions and lherefore lakes
more lime for lhe programmer lo undersland lhe design. This effecls lhe
communicalion belveen lhe designer and lhe programmer. The slakehoIders

3
lhal are inleresled in reading lhe design documenls are cuslomers, pro|ecl leam
members, execulives and lhe peopIe vho viII mainlain lhe syslem posl-deIivery.
These persons aII have differenl knovIedge of UML semanlics and lherefore
mighl undersland a design in differenl vays.

Maintaining thc dcsign artcIacts - If lhe design arlefacls are compIicaled and
abslracl lhe impIemenling peopIe are Iess viIIing lo foIIov lhe design and nol
IikeIy lo do adequale and necessary updales lo lhem. This Ieads lo lhal lhe
finished producl does nol map lo lhe design arlefacls. In a Ialer slage vhen lhe
syslem goes lhrough mainlenance il viII be a compIex lask. The mainlenance
slaff mighl nol be lhe same persons as lhe deveIopers impIemenling il and as
such are dependenl on good and descriplive design arlefacls for easy
mainlenance.

Irom lhese five probIem areas ve can deducl lhree allribules defining good
design arlefacls according lo our experience. The condilion of lhe design
arlefacls shouId provide verificalion and vaIidalion of lhe use-cases and
requiremenls il refIecls. The condilion of lhe design arlefacls shouId aIso provide
arlefacls lhal resembIe reaIily and lhal are nol misIeading. In lhe aspecl of
communicalion among slakehoIders ve need unambiguous design arlefacls lhal
are easy lo undersland and lhal mediale lhe reaI message of lhe use-case. The
mainlainabiIily aspecl shouId provide means for easy mainlenance and updales.

1.3 Hothesls
Since our background is vorking vilh UML and deveIopmenl of Web
appIicalions ve vanled lo invesligale as lo vhal exlenl lhe UML vas al aII
suilabIe for modeIIing Web appIicalions. Ixperience in pasl pro|ecls aIso raised
queslions aboul vhal melhods commonIy are used in lhe induslry.

The choice of using WAI-UML(Web AppIicalion Ixlension lo UML) as an aid in
modeIIing Web appIicalions made us formuIale furlher queslions regarding if,
and lo vhal exlenl, lhis melhod can heIp us improve our pre-exisling and fulure
designs. As lhe probIem descriplion suggesls, lhe lask vas lo examine hov lhe
nev design choice couId heIp us in producing a beller design improving lhe
quaIily allribules: and as such aid in lhe communicalion vilh slakehoIders and
improve lhe condilion and mainlainabiIily of lhe design arlefacls. These
queslions define lhe framevork for lhe lhesis and have since lhe slarl evoIved lo
concIude lhe foIIoving hypolhesis:

4

Uslng WAL-UML for Web uIlcutlon deslgn lmrotes the condltlon und
mulntulnublIlt of the deslgn urtefucts und the communlcutlon umong the
stukehoIders.

1.4 GouIs und motltutlons
We have severaI goaIs vilh lhe lhesis. The firsl goaI is lo bring Iighl lo lhe
possibiIilies lo use previous knovIedge of UML and appIy il on lhe modeIIing of
Web appIicalions. Since mosl designers and Web appIicalion deveIopers have
previous knovIedge of UML: using UML inslead of a nev vay of modeIIing
(such as W2000 and WebML) is according lo us lhe besl vay lo allend lhan lo
Iearn a nev vay of modeIIing. We noliced during lhe execulion of lhe lhesis lhal
lhe deveIopers in lhe induslry are nol using any parlicuIar deveIopmenl melhod
or design melhods al aII. They are dependenl on descriplive documenls such as
specificalions and requiremenls. We are under lhe opinion lhal olher melhods
lhan UML, Iike WAI-UML, needs lo be more videspread in lhe induslry. They
can provide a more genuine vay of deveIopmenl and reduce lhe deveIopmenl
cosls. ConaIIen has somelhing lo say in lhis maller aIso.

Currcni !ctc|cpncni cntircnncnis nakc ii sc casu ic prc!ucc sinp|c uc| app|icaiicns
inai incu natc inc unjcriunaic si!c cjjcci cj cnccuraging us ic !ctc|cp an! ctc|tc
app|icaiicns in inc a|scncc cj scricus ana|usis an! !csign. Anu susicn uiin ncn-iritia|
ccnp|cxiiu ncc!s ic |c !csignc! an! nc!c||c!. (ConaIIen, 1998, Inlroduclion seclion.)

The second goaI is lo be abIe lo creale beller design arlefacls lhal are
unambiguous and cIear and vhich correclIy describes lhe Web appIicalion under
deveIopmenl. Mosl imporlanlIy lhe design arlefacls shouId confirm lhe
requiremenls and use-cases, so lhal a meaningfuI verificalion and vaIidalion can
be performed.

As a consequence of lhe lvo firsl goaIs ve hope lo be abIe lo deveIop more Web
appIicalions inslead of lhe more lradilionaI cIienl/server appIicalions. Web
appIicalions are archilecluraIIy a speciaIizalion of lhe cIienl/server archileclure al
a high IeveI (ConaIIen, 2002, p. 141). The differences appear al lhe Iover IeveIs
and lypicaIIy are reIaled lo lhe communicalion prolocoI, HTTI, and vendor
specific exlensions of lhe cIienl brovser (ConaIIen, 1998, Web siles). In lhis
conlexl ve define lhe difference as vhen deveIoping a cIienl/server appIicalion
ve need lo deveIop soflvare execulabIes for bolh lhe cIienl and lhe server side.

5
In a cIienl/server appIicalion lhese execulabIes does nol incIude |ava appIels, or
simiIar lechnoIogies, meanl lo execule in lhe brovser. In a Web appIicalion lhe
Web brovser acls as lhe cIienl side program and as such ve need onIy deveIop
soflvare for lhe server side, and somelimes exlensions for lhe brovser. We can
use lhe communicalion prolocoIs aIready defined. This means lhal if ve have a
good vay lo modeI a Web appIicalion ve preferabIy viII choose lo deveIop an
appIicalion as a Web appIicalion inslead of a cIienl/server appIicalion. The
argumenls for lhe deveIopmenl of Web appIicalions inslead of cIienl/server
appIicalions are lhal a Web appIicalion provides us vilh many parls of lhe
syslem. Ior inslance, lo our opinion, il can reduce lhe deveIopmenl cosl and
efforl because lhe cIienl side uses onIy a brovser and lhe prolocoIs are aIready
lhere for lhe communicalion. On lhe server side ve have hllp servers,
appIicalion servers and DMS' (Dalabase Managemenl Syslem) aIready
impIemenled and lesled. The focus of lhe deveIopmenl can lhen be concenlraled
on lrimming business Iogic and improving lhe presenlalion lo lhe user.

We lhink lhal bringing lo Iighl lhe possibiIilies of using WAI-UML for lhe
modeIIing of Web appIicalions ve can heIp fulure Web appIicalions pro|ecls lo
design and impIemenl beller soflvare.

1.5 DeIlmltutlon
Due lo lhe compIexily of lhe probIem ve have chosen lo reslricledIy Iook al lhe
slakehoIder communicalion and lhe condilion and mainlainabiIily of lhe design
arlefacls. We lhink lhal lhese are lhe mosl imporlanl aspecls of a soflvare
design. The quaIily and performance of lhe resuIling soflvare producl is
cerlainIy vaIuabIe lo evaIuale. There is no exisling formaI melhod, lo our
knovIedge, for lesling hov lhe finished syslem performs given lhe design
arlefacls for il. The focus viII nol be on performance and quaIily of lhe resuIling
soflvare producl. Hovever, as performance and quaIily of lhe syslem is an
imporlanl aspecl lhis viII be menlioned briefIy if il adds any vaIue lo lhe resl of
lhe discussion.

2 Thcnrctic backgrnund
In lhis chapler ve viII slarl vilh a definilion of vhal ve mean vilh a Web
appIicalion. The concepl of Web appIicalion archileclure and lhe .NIT
archileclure are imporlanl lo grasp lo undersland if a design arlefacl resembIes
reaIily. Thereafler ve viII describe lhe differenl lechnoIogies ve have Iooked al

6
for lhe modeIIing of a Web appIicalion and vhy or vhy nol lhey are suilabIe for
lhis kind of modeIIing.

The Iileralure regarding modeIIing of Web appIicalions is nol exlensive.
Hovever, lhe efforls for deveIoping a nev vay lo modeI a Web appIicalion is
sliII an evoIving area of inleresl in lhe induslry, and as such lhere exisls lhree
inleresling melhodoIogies nameIy, W2000 (aresi, Garzollo & IaoIini 2001),
WebML (Ceri, IralerneIIi & ongio 2000) and WAI-UML (ConaIIen, 2002).

A fourlh possibiIily is lo use lhe slandard UML for lhe modeIIing of Web
appIicalions. Hovever, as described in lhe probIem descriplion lhis vay is nol a
good vay because lhe UML Iacks lhe correcl semanlics and eIemenls lo modeI
lhe compIexily of a Web appIicalion correclIy and accurale.

To our opinion, a melhod for lhe design of veb appIicalions shouId prove lo
have four properlies:

I1. Bui!d nn thc UML. Il shouId incorporale or buiId upon lhe UML. In lhe
induslry, ve beIieve lhal mosl deveIopers and designers are famiIiar vilh
lhe UML since il is de faclo slandard for modeIIing of lradilionaI
appIicalions. Iroviding lhem vilh a nev melhod decreases lhe Iearning
efforls if il buiIds on lhe Iearners pre-exisling knovIedge.

I2. Fnrma! rcIcrcncc spcciIicatinn. In a deveIopmenl leam and among lhe
slakehoIders, nol aII are required lo have knovIedge of lhe UML. If lhe
melhod provides a formaI reference specificalion il shouId refIecl lhe
abiIily lo undersland and read lhe design arlefacls. Il is aIso easier for lhe
designers and impIemenlers lo reference a specificalion.

I3. Rcvca! thc architccturc. If lhe melhod provides means lo reveaI lhe
archileclure, lhe underslanding of lhe concepl and domain shouId
increase in lhe pro|ecl leam and among lhe slakehoIders.

I4. Incrcasc thc cnnditinn. Increase lhe condilion of lhe design arlefacls
means lhal lhey shouId describe lhe appIicalion in such a vay lhal il can
nol be misIeading: provided lhal lhe reader of lhe documenl possess
adequale knovIedge of lhe UML and knovIedge of lhe formaI
specificalion for lhe melhod.


7
These properlies are based on lhe quaIilies ve vanl a melhod for modeIIing
Web appIicalions lo provide.

2.1 lntroductlon to Web uIlcutlons
We have adopled ConaIIens definilion (2002, p. 31) vhere ve dislinguish a Web
appIicalion from a Web sile lhrough lhe users infIuence on lhe business Iogic.
The user execules business Iogic vilh lhe brovser lhrough lhe inpul and
navigalion he does on lhe physicaI veb page lhal is rendered by his brovser.
The navigalion and inpul of informalion on lhe cIienl side brovser is lypicaIIy
handIed and lransporled lo lhe server side lhrough lhe definilion of a posled
form. This communicalion normaIIy lakes pIace lhrough lhe use of lhe slandard
conneclionIess HTTI (Hyperlexl Transporl IrolocoI) prolocoI. Due lo lhis
conneclionIess properly, lhe cIienl slale managemenl on lhe server is a chaIIenge
of Web appIicalions since each cIienl requesl lo lhe server opens a compIeleIy
nev conneclion each lime (ConaIIen, 2002). This is usuaIIy soIved lhrough
session managemenl or lhrough lhe use of cookies. A veb sile conlains slalic
conlenls lhal lhe user can nol change or inleracl vilh. Hovever lhe melhods for
modeIIing Web appIicalions discussed Ialer can be appIied on bolh smaIIer Web
siles vilh slalic conlenl and Web appIicalions vilh dynamic conlenl.

2.1.1 Architccturcs
The lypicaI archileclure of a Web appIicalion consisls of lhe cIienl brovser, a veb
server, an appIicalion server and a DMS. The roIe of lhe cIienl brovser is lo
render lhe hlmI page lhal is senl from lhe server and lo handIe lhe
communicalion vilh lhe Web server.

TypicaIIy an appIicalion server execules lhe code in lhe server side pages lhal
affecls lhe business Iogic and is usuaIIy Iocaled on lhe same machine as lhe
server (ConaIIen, 2002, p. 147). Il is aIso used for execuling aIready compiIed
moduIes and cIasses vhich affecls lhe slale of lhe business conlenl, such as lhe
communicalion vilh a dalabase server.

2.1.2 .NET cnnccpt
The Microsofl .NIT archileclure does nol define a singIe responsibIe veb page:
ralher a veb page is composed of lhe virluaI veb page (.hlmI) and a
corresponding physicaI server page (.aspx) vhich has a super cIass (lhe code-

8
behind) lhal conlains lhe ma|orily of evenl handIing mechanisms. Iigure one
iIIuslrales lhis concepl vhere lhe server page (.aspx) inherils lhe evenl handIing
and olher melhods from lhe code-behind super cIass (.cs) and buiIds lhe veb
page code lhal is evenluaIIy senl lo lhe cIienl (ConaIIen, 2002, p. 248). Iven if lhis
archileclure is correcl from a deveIoper perspeclive il is nol lhe same viev as a
user has. Iigure one shovs lhe .NIT archileclure from a designer and
programmer perspeclive nol from a user perspeclive. Since a user is unavare of
lhe .hlmI and sees onIy lhe .aspx exlension in lhe brovser.


Figurc 1: .NET Architccturc (Cnna!!cn, 2002)

2.2 Wh ue modeI softuure?
We modeI soflvare because il is nol possibIe for a human being lo keep every
delaiI in mind in a compIex modeI. We lry lo undersland lhe compIexily of a
syslem by modeIIing il. In lhal vay ve can focus on lhe imporlanl lasks and nol
keep every delaiI in mind (OMG, 2001, p. 1-3). We use lhe modeI lo communicale
vhal lo buiId vilh lhe slakehoIders, lo communicale vilh lhe peopIe lhal are
buiIding il, and lo communicale vilh lhe peopIe vho viII mainlain lhe syslem
(ConaIIen, 2002, p. 4). Wilh lhis in mind ve undersland lhal a design modeI musl
possess cerlain properlies lo be usefuI. Wilh a modeI ve can abslracl lhe delaiIs
so il is easier lo undersland. In lhe end il is up lo lhe modeIIer lo decide in vhal
vay lhe modeI is seen as enough. A modeI can neilher be loo abslracl nor shov
loo much delaiI. The roIe of lhe modeIIer is lo abslracl lhe modeI enough lo
MyPage.cs
MyPage.aspx MyPage.html
<<build>>

9
caplure lhe meaningfuI parls of a syslem and make il easy for lhe slakehoIders lo
undersland il (Slaron, 2003, p. 3).

2.3 Stundurd UML
The UML vas founded by Grady ooch, Iim Rumbaugh and Ivar Iacobson as a
vay lo uliIize and slandardize lhe many differenl modeIIing Ianguages lhal
exisled in lhe pasl. They emerged lhe UML from ooch, OMT (Ob|ecl ModeIing
Technique) and OOSI (Ob|ecl Orienled Soflvare Ingineering) modeIIing
Ianguages. The UML is slandardized by OMG (OMG, 2001, p- 1-6).

Iven lhough ve lhink lhal lhe UML Iacks lhe semanlics for modeIIing Web
appIicalions il is sliII an oplion lo use. The UML is nov in lhe version 2.0:
hovever, for lhe modeIIing of lhe diagrams lhal are used as a fundamenl of lhis
lhesis lhe version 1.5 has been used and accordingIy described here.

2.3.1 Dcscriptinn
The UML defines a unificalion of semanlics and a common nolalion lo be abIe lo
visuaIize and specify compIex soflvare syslems. Il provides lhe modeIIer vilh a
slandard vay and a formaI descriplion of hov lo documenl lhe evoIulion of any
piece of soflvare (OMG, 2001, p. 1-1).

Wilh UML many lhings can be expressed bul lhe common use is for designing
soflvare syslems. Il defines a Mela modeI and a nolalion for ob|ecl-orienled
modeIIing and documenlalion of arlefacls for soflvare syslems. These arlefacls
are lhen mapped lo ob|ecl orienled Ianguages.

The UML does nol promole any speciaI deveIopmenl process, hovever, lhe
aulhors of UML address lhal ob|ecl orienled modeIIing vilh UML shouId be
performed in lhe conlexl of a process, such as lhe UI (Unified Irocess), and
vhich is use-case driven, archileclure cenlric and eilher ileralive or incremenlaI
(OMG, 2001, p. 1-11).

The UML shouId be abIe lo be used in many areas such as embedded syslems,
desklop appIicalion deveIopmenl and Web appIicalion deveIopmenl. To address
lhis universaI behaviour UML defines and exlensibiIily mechanism vhich
incIudes slereolypes, lagged vaIues and conslrainls (OMG, 2001, p. 1-9).


10
2.3.2 UML nntatinn
As a compIele UML nolalion reference is beyond lhe scope of lhis lhesis lhis
chapler provides onIy an inlroduclion lo lhe main concepls, lhe diagrams and
lhe nolalion lhal ve lhink is necessary lo foIIov lhe discussions in lhe lhesis.

The vocabuIary of lhe UML can be cIassified inlo lhree componenls, nameIy
eIemenls, reIalions and diagrams. The eIemenls are lhe mosl imporlanl and can
for exampIe be cIasses and packages. ReIalions are used lo bind eIemenls
logelher and for execuling lhe funclionaI requiremenls. ReIalions are
dependencies, associalions, generaIizalions and reaIizalions. In advanced
modeIIing lhese reIalions can furlher be exlended vilh aggregalion and
navigalion. Diagrams are used for lhe visuaIizalion of lhe slruclures being
modeIIed (Slrand, 2003, p. 15).

The UML specifies semanlic ruIes for hov lhe eIemenls and reIalions can be
connecled and hov lhey are specified. The meaning of lhese ruIes is lo provide a
uniform underslanding and lo provide supporl for generaling code from lhe
modeI by CASI looIs. A CASI looI is abIe lo aulomalicaIIy generale slub code
from a design.

2.3.3 UML cxtcndibi!ity
The UML defines looIs for exlending ils semanlics and lhe eIemenls used for
modeIIing any lype of appIicalion. These looIs are defined as slereolypes,
conslrainls and lagged vaIues (OMG, 2001, p. 1-9).

The slereolype is, according lo us, lhe mosl imporlanl looI. A lhorough
examinalion of slereolypes and ils use have been researched by Slaron (2003).
Slereolypes can be used lo change lhe vocabuIary of UML and change lhe
semanlics of lhe nolalion so lhal il fils any need (OMG, 2001, p. 1-10). Ior
exampIe, lhe meaning of an associalion dependency can be changed so lhal lhe
meaning of il is compIeleIy differenl and fils lhe modeIIers' needs. Conslrainls
describe semanlic reslriclions lo an eIemenl in UML. IncIosed by brackels,
senlences can inlroduce reslriclions for an eIemenl so lhal somelhing viII happen
onIy if lhe reslriclion cIause is vaIidaled lrue (OMG, 2001, p. 2-64). Tagged vaIues
are used lo creale a nev definilion of an eIemenls specificalion (OMG, 2001, p. 2-
29).


11
2.3.4 Wcb app!icatinn mndc!!ing with UML
ecause lhe UML is uniform, provides an exlensibiIily mechanism and is veII
knovn in lhe induslry lhen using UML in some vay for lhe modeIIing of Web
appIicalions is preferred. Il adheres onIy lo properlies I1 (uiId on lhe UML)
and I2 (IormaI reference specificalion). Since lhe UML provides an exlensibiIily
mechanism for modeIIing any appIicalion il mighl adhere lo properly I3 (ReveaI
lhe archileclure) bul lhis means lhal a formaI melhod and descriplion musl be
deveIoped by lhe designers for lhe communicalion aspecls. Irom experience ve
can deduce lhal lhe properly I4 (Increase lhe condilion) is nol fuIfiIIed.

2.4 W2000
aresi, Garzollo & IaoIini (2001) describes a framevork consisling of a
combinalion of UML and HDM (Hypermedia Design ModeI) for defining Web
appIicalions. The framevork defines melhods for requiremenls anaIysis, slale
evoIulion design, hypermedia design, funclionaI design and visibiIily design
vhich logelher defines lhe fuII modeI of lhe Web appIicalion.

The W2000 framevork can be used lo buiId personaIizalion inlo a modeI, vhich
is hov differenl users use and sees lhe Web appIicalion and lo vhal exlenl lhey
are aIIoved lo use ils funclionaIily. Il aIso focuses on conlenl managemenl,
informalion design, and navigalion design (aresi, Garzollo & IaoIini, 2001, p.
1).

2.4.1 Wcb app!icatinn mndc!!ing with W2000
Iven lhough lhis melhod provides us vilh some inleresling properlies such as
personaIizalion ve lhink lhal il is nol suilabIe for modeIIing Iarge Web
appIicalions because il does nol define any formaI descriplion (il seems lhal lhe
melhod and promoled CASI looIs are nol acliveIy mainlained al lhe dale of
vriling). To faciIilale communicalion in a modeI lhere musl exisl a formaI
descriplion so lhal differenl slakehoIders can Iearn il and adapl lhe message lhal
a modeI provides. The exampIe modeIs described by aresi, Garzollo & IaoIini
(2001) aIso does nol seem lo reveaI lhe archileclure vhich is somelhing lhal
shouId be of Iarge concern as an aid in communicaling lhe message of lhe modeI.


12
2.5 WebML
WebML, as promoled by Ceri, IralerneIIi & ongio, uses orlhogonaI dimensions
for specifying veb appIicalions al lhe concepluaI IeveI and addresses pIalform
independenl specificalion of dala-inlensive Web appIicalions (Ceri, IralerneIIi &
ongio 2000, p. 138). WebML provides one-lo-one personaIizalion of conlenl
addressing lhe users and aIso largels lhe deIivery of conlenl lo muIlipIe devices,
such as handheId and mobiIe devices (Ceri, IralerneIIi & ongio 2000, p. 138).

The orlhogonaI dimensions conslilule a slrucluraI modeI vhich describes lhe
dala conlenl in veb pages and lhe reIalionships among lhe conlenl. The pages
lhal compose lhe Web appIicalions are modeIIed in a composilion modeI. Link
lopoIogy or navigalion among lhe pages in lhe Web appIicalion is modeIIed in
lhe navigalionaI modeI. When il comes lo lhe Iayoul of lhe pages and lhe
graphicaI requiremenls for lhe Web appIicalion lhese are modeIIed in a
presenlalion modeI (Ceri, IralerneIIi & ongio 2000, fr. p. 138).

A Web appIicalion design modeIIed vilh WebML is, aIong vilh ils graphicaI
represenlalion, represenled as XML slruclured informalion for lhe slrucluraI
modeI vhich faciIilales moving lo differenl pIalforms and design looIs (Ceri,
IralerneIIi & ongio, 2000, p. 141). SeveraI CASI looIs are avaiIabIe, for exampIe
on hllp://vvv.vebmI.org. Here is aIso provided specificalion and
documenlalion for hov lo use lhe Ianguage.

2.5.1 Wcb app!icatinn mndc!!ing with WcbML
WebML onIy describes a Web appIicalion al lhe concepluaI IeveI. In many cases
lhis is nol suilabIe for a Web appIicalion lhal incorporales exlensive business
Iogic. According lo Ceri, IralerneIIi & ongio (2000, p. 138), WebML is
compalibIe vilh UML in lhe slrucluraI modeI: hovever, nev concepls and
enlilies are inlroduced in lhe composilion modeI, navigalion modeI and lhe
presenlalion modeI. These enlilies are nol parl of lhe specificalion of lhe UML so
ve concIude lhal lhis melhod does nol have lhe properlies of I1 (uiId on lhe
UML).

The WebML provides us vilh a formaI specificalion bul nol lhe abiIily lo reveaI
lhe archileclure, as il defines an appIicalion from a concepluaI poinl of viev
(Ceri, IralerneIIi & ongio 2002, p. 138), and lhus have lhe properlies of I2
(IormaI reference specificalion) bul nol I3 (ReveaI lhe archileclure).


13
In WebML lhere is no cIear definilion of hov lo inlegrale lhe business Iogic
ob|ecls of compiIed code inlo modeIs deveIoped vilh WebML vhen a more
delaiIed design of il is needed.

WebML couId be suilabIe for inlegralion inlo lhe UX (User Ixperience) parl of
lhe WAI-UML as ils main focus is on informalion and navigalion design vhich
is a parl of lhe User Ixperience.

2.6 WAL-UML
olh W2000 and WebML Iack some of lhe properlies ve lhink a melhod musl
provide and lheir use is ralher reslricled due lo lhe non-exlensive informalion
aboul some of lhem. Hovever, vilh efforls from lhe aulhors of W2000 and
WebML lhey couId be subslilules or aid in lhe User Ixperience modeIIing vhich
is incorporaled in lhe Ialesl updales lo lhe WAI-UML.

Wilh WAI-UML, engineered by ConaIIen, ve can express IogicaI design and
connecl il lo lhe physicaI veb pages in an archileclure-cenlric and correcl vay. Il
aIIovs hypermedia and informalion design as parl of lhe User Ixperience
modeIIing.

WAI-UML uses exlensions lo UML vhich aIIovs lhe conslruclion of fuII modeIs
of any Web appIicalion and supporls lhe mosl dominanl archileclures, such as
.NIT, Iava framevork and IHI, bul sliII provides an ob|ecl-orienled viev of an
appIicalion (ConaIIen, 2002, p. 7).

Iven lhough ve speak aboul lhe WAI-UML as a melhod, vhal il does is onIy
buiIding on lhe UML vilh lhe definilion of severaI slereolypes, lagged vaIues
and conslrainls for lhe correcl modeIIing of a Web appIicalion. Since lhe WAI-
UML exlends lhe UML in lhis vay ve lhink lhal using lhis melhod for lhe
design of Web appIicalions is suilabIe considering lhal mosl deveIopers aIready
have knovIedge of UML.

2.6.1 Nntatinn
WAI-UML defines severaI slereolypes, lagged vaIues and conslrainls lo aIIov us
lo modeI a Web appIicalion. Appendix four inlroduces a smaII coIIeclion of lhe
imporlanl slereolypes used for lhe redesign of lhe e-commerce appIicalion. A fuII
reference and specificalion can be found in ConaIIen (1999, (2002, Appendix A)).

14

2.6.2 UniIicd Prnccss with WAE-UML
ConaIIen (2002, p. 97) advocales lhal a prospeclive soflvare engineering process
couId be lhe Unified Irocess (UI) or RalionaI Unified Irocess (RUI). Hovever,
any process lhal incorporales UML can be appIied such as lhe Ixlreme
Irogramming (XI) process.

Uscr Expcricncc with WAE-UML
An imporlanl inlroduclion in lhe Ialesl WAI-UML, as a parl of lhe process lhal
ConaIIen uses for modeIIing, is lhe UX (User Ixperience) modeIIing. Wilh UX ve
can modeI lhe behaviour of lhe appIicalion from a user perspeclive in
compIiance vilh lhe use-cases. UX caplures lhe design and dislribulion of bolh
dynamic and slalic conlenl for informalion design. Hypermedia design is aIso
caplured in lhe navigalionaI map (ConaIIen, 2002, p. 187).

ConaIIen (2002, p. 193) inlroduces lhe nolion of a <<screen>> slereolype for lhe
conslruclion of lhe design diagrams in UX. A screen caplures slalic and dynamic
conlenl as seen by lhe user and is aIso used lo define lhe navigalionaI fIov in lhe
appIicalion. In addilion, adornmenls can be used lo express speciaI properlies of
screens such as accessibiIily from olher screens and scroIIabIe screens.

2.6.3 Wcb app!icatinn mndc!!ing with WAE-UML
aresi, Garzollo & IaoIini (2001, p. 9) gives crilicism on lhis melhod suggesling
lhal il priviIeges cIienl-server inleraclions and undereslimales lhe design of
informalion and navigalion slruclures. Wilh lhe reIease of lhe WAI-UML, in
ConaIIen (2002), il is inlroduced informalion and navigalion design as a parl of
UX modeIIing. Since lhe UX modeIIing is lighlIy coupIed and mapped lo lhe
anaIysis and design lhese probIems are nov arranged for.

The WAI-UML melhod inlroduces exlensions lo UML for lhe modeIIing of veb
appIicalions. Il provides a formaI specificalion of lhe exlensions used. WhiIe
modeIIing vilh WAI-UML, according lo our experience, ve reveaI lhe
archileclure of lhe behind lhe appIicalion. Since lhe melhod uses a use-case
cenlred approach lo modeIIing Web appIicalions ve lhink lhal il is a prospecl lo
improve our quaIily allribules of lhe design arlefacls.


15
|n WA|-UMI. inc UMI nciaiicn is cxicn!c! uiin a!!iiicna| scnaniics an! ccnsirainis
ic pcrnii inc nc!c|ing cj Wc|-spccijic arcniicciura| c|cncnis as a pari cj inc susicns
nc!c|. (ConaIIen, 2002, p. 4)

WAI-UML aIIovs us lo modeI lhe compIex behaviour of a Web appIicalion
vhiIe paying parlicuIar allenlion lo lhe business Iogic behind il. Since Iarge Web
appIicalions can conlain Iarge and compIex business Iogic lhis is an imporlanl
properly.

3 Mcthnd
In lhis chapler ve describe our scienlific approach lo lhe hypolhesis and research
queslions. We aIso describe lhe melhods for approaching lhe praclicaI vork and
lhe evaIualion.

3.1 Sclentlflc method und urouch
3.1.1 Casc study
A case sludy incorporales an inlense sludy of a phenomenon of inleresl and is
used for in-deplh sludy of probIems lo undersland processes or a silualion in
conlexl (MarleIIa, NeIson & Marchand-MarleIIa, 2003, p. 20). The emphasis is on
underslanding lhe phenomena. The mosl imporlanl aspecl of a case, lhough, is
lhal il provides us vilh means lo examine differenl melhods and modeIs
(englsson, 2004, p. 13). Case sludies moslIy deaI vilh quaIilalive dala coIIeclion
and can have muIlipIe sources for lhe coIIeclion (MarleIIa, NeIson & Marchand-
MarleIIa, 2003, p. 20). A case sludy conlains five phases. The firsl phase
conslilules means for anaIyzing and underslanding lhe conlexl. The nexl phase
shouId idenlify lhe probIems and sel diagnoses. The lhird phase shouId provide
oplions for approaching lhe probIem. In lhe nexl phase ve anaIyze lhe
informalion and choose an oplion for lhe approach. The Iasl phase presenls lhe
soIulion in accordance lo lhe probIem descriplion. These phases are described by
englsson (2004).

We use lhe fIov of a case sludy earIy in our lhesis. In lhe firsl phase ve lry lo
undersland lhe conlexl in vhich ve have vorked in earIier Web appIicalion
deveIopmenl. In phase lvo ve idenlify lhe probIems lhal have occurred in pasl
pro|ecls and undersland vhy lhey occurred. The Iileralure sludy of differenl
melhods provided us vilh aIlernalives for using UML in Web appIicalion

16
designs. We choose WAI-UML as a vay lo approach lhe praclicaI vork. As a
parl of phase five ve execuled lhe praclicaI vork and presenled lhe resuIl as
design diagrams vilh WAI-UML. These provide us vilh means lo lesl lhe
hypolhesis lhal conslilules lhe lhesis.

3.1.2 Qua!itativc vs. quantitativc rcscarch
Ouanlilalive research is based on slalislicaI sampIing and galhering of dala vilh
lhe primary purpose of describing presenl processes. The lheories are deveIoped
in an induclive manner vilh lhe concern of sludying naluraI evenls vilh no
inlerference (MarleIIa, NeIson & Marchand-MarleIIa, 2003, p. 93).

Opposile lo quanlilalive research ve have quaIilalive research. Inslead of
describing presenl processes ve delermine lhe effecls of a phenomenon. In a
deduclive vay, lheories ruIe lhe purpose of lhe invesligalion (MarleIIa, NeIson &
Marchand-MarleIIa, 2003, p. 257).

According lo MarleIIa, NeIson & Marchand-MarleIIa (2003, p. 256) lhere is no
preferred melhod. Inslead lhe choice is dependenl on lhe lype of queslions lo be
invesligaled and ansvered. We have used a quaIilalive research melhod vhere
ve have lried lo galher quaIilalive dala by conducling inlervievs lo gel a
personaI conlacl and insighl in lhe probIems regarding Web appIicalion
modeIIing vilh WAI-UML. We aIso lried lo be open and give sub|eclive
personaI opinions and experience lo gel insighl and gel in conlacl vilh lhe
probIem area. This gave us an ob|eclive and crilicaI-eye approach for execuling
lhe praclicaI vork.

The praclicaI vorks infIuences emphalic neulraIily as a ma|or roIe for us. As
compIele ob|eclivily is impossibIe (MarleIIa, NeIson & Marchand-MarleIIa, 2003,
p. 263), ve have lried lo have a neulraI non-|udgemenlaI concenlraled
invesligalion governed by lhe hypolhesis.

3.1.3 Ana!ytica! apprnach - rcductinnism
CompIex probIems can be beller underslood if lhey are reduced lo smaIIer
pieces. This is lhe fundamenlaI idea of lhe research melhod reduclionism. The
idea is lhal lheories for lhe vhoIe can be derived from Iover IeveIs (Robson,
2002, p. 551). Since a piece of soflvare and lhe bIueprinls describing il is indeed
compIex ve seek lo divide lhe probIem of improving lhe soflvare designs inlo
smaIIer pieces.

17

We Iook al lhe design from lhree ma|or vievs. Irom lhe condilion of lhe design
arlefacls vhere ve vanl lo find improvemenls in lhe maller of verificalion and
vaIidalion of lhe design diagrams according lo lhe use-case and requiremenls
specificalion. Nexl ve Iook al lhe mainlainabiIily of lhose design arlefacls and
lry lo undersland lhe mainlainabiIily issues regarding lhe UML and WAI-UML
designs. Irom a soflvare engineer and cuslomer poinl of viev il is imporlanl
lhal lhe crealed arlefacls do nol onIy vaIidale lhe requiremenls and use-cases,
bul aIso lhal lhey can leII lhe slory aboul lhe soflvare lo lhe peopIe invoIved.
There are many differenl slakehoIders in a soflvare pro|ecl and lhey aII have
differenl lechnicaI knovIedge and can lherefore undersland a modeI in differenl
vays.

3.1.4 Apprnach
The overaII melhod is vorking by lhe defined fIov of a case sludy vhere ve are
lrying lo see in vhal vay, and hov, an e-commerce design can be improved by
using WAI-UML. In lhe case-sludy ve lake a quaIilalive and reduclionism
approach and hope lo be abIe lo conducl a generaI slalemenl for vhelher or nol
lhe design arlefacls can be improved by using WAI-UML. AII our lhree
vievpoinls, lhe condilion, mainlainabiIily and communicalion of lhe design
arlefacls, are equaIIy imporlanl. Irom lhese vievpoinls ve lry lo deduce a
concIusion vhelher ve can improve lhe soflvare design arlefacls of Web
appIicalions as a vhoIe.

3.2 PructlcuI uork
A comparison of lhe UML and WAI-UML varianls of modeIIing Web
appIicalions is nol possibIe vilhoul some praclicaI infIuences. The praclicaI vork
provides us vilh a vay of slrucluring lhe informalion and presenls lhe case in
lhe form of a redesigned e-commerce syslem. The e-commerce syslem vas
originaIIy deveIoped in spring 2004 as a parl of lhe course SmaII Team Soflvare
Ingineering Iro|ecl, IA005 al Iekinge Inslilule of TechnoIogy. As a resuIl of
lhe iniliaI case sludy ve approach lhe praclicaI vork as lhe Iasl phase in lhe case
sludy.


18
3.2.1 E-cnmmcrcc backgrnund
The cuslomer and lhe main slakehoIder of lhe e-commerce syslem is a Iarge
company dispersed among severaI differenl counlries. The inlended users of lhe
e-commerce syslem are smaII and Iarge relaiI slores. The managemenl visions an
increase among lhe relaiI slores using a compuler and lhe Inlernel for ordering
lheir suppIies and needs lo offer an aIlernalive vay of ordering lheir producls.

Ior lhe relaiI slores, lhe e-commerce syslem fealures pIacemenl of orders,
searching for arlicIes, foIIoving lhe deIivery progress, receive speciaI offers and
discounls and easy lracking of orders and invoices. As lhe relaiI slores possesses
arlicIe calaIogues and moslIy orders lhe same suppIies lhe e-commerce syslem
does nol conlain any arlicIe lree slruclure for presenlalion of lhe arlicIes. The
relaiI slores personneI knov lhe arlicIe numbers on lheir mosl popuIar arlicIes so
lhe need for an arlicIe lree is nol required.

3.2.2 Dc!imitatinn
The e-commerce syslem is a Iarge piece of soflvare and as such conslilules a
Iarge design. We have chosen lo deIimil lhe remodeIIing efforls of lhe e-
commerce syslem lo lvo specific funclions: lhe arlicIe search and pIace order
funclions. We lhink lhal ve can sliII shov lhe concepls and imporlanl aspecls of
WAI-UML modeIIing.

As ve viII focus on lhe anaIysis and design of lvo parlicuIar use-cases in lhe e-
commerce syslem, onIy lhe requiremenls needed for lhese lvo funclions viII be
presenled. As lhe requiremenl specificalion is sliII exhauslive, il excIudes lhe
source, purpose and dependencies as ve lhink lhal lhese are nol imporlanl nor
required for lhe underslanding of modeIIing.

When referring lo lhe cuslomer in lhe requiremenls il means lhe user of lhe
syslem, lhe relaiI slores. Appendix one conlains lhe use-cases ve choose lo
redesign and appendix lvo conlains lhe requiremenls for lhese use-cases.
Appendix lhree shovs lhe design arlefacls for lhe e-commerce syslem.

3.2.3 Cnnductinn
The redesign of lhe e-commerce appIicalion vas performed according lo lhe
process oulIined in ConaIIens book aboul WAI-UML. Since ve choose lo use lhe
melhod WAI-UML lhis process of vork vas lhe mosl reasonabIe. ConaIIen

19
describes lhe melhod as a mixlure belveen lhe RalionaI Unified Irocess (RUI)
and ICONIX Unified Irocess. The melhod aIso incorporales lhe User Ixperience
(UX) inlo lhe process (2002, p. 97).

3.3 LtuIuutlon
The evaIualion consisls of our ovn evaIualion and conducled inlervievs vilh
reIevanl peopIe vorking in lhe induslry.

3.3.1 Own cva!uatinn
The fundamenlaI idea of evaIualing a design is lo evaIuale lhe correclness and
accuracy as il conforms lo lhe requiremenls specificalion and use-case scenarios,
provided lhal lhe SRS (Syslem Requiremenls Specificalion) and use-case
scenarios are accepled as correcl. In lhis lhesis ve presuppose lhal lhe
requiremenls and use-cases, vhich ve base our modeI on, are correcl in lhe
maller of slakehoIder acceplance and indecency.

There are severaI vays for assessing soflvare archileclures bul lhese melhods
main focus is on assessing lhe quaIily allribules (non-funclionaI requiremenls) of
soflvare archileclures. The melhods suggesled in osch (2002, p. 91-103) are
scenario-based assessmenl, simuIalion-based assessmenl, malhemalicaI modeI-
based assessmenl and experience-based assessmenl. Hovever, since lhe focus for
lhese melhods is on quanlilalive and quaIilalive measuremenls of lhe quaIily
allribules of lhe soflvare archileclure lhese melhods do nol appIy lo lhe lhesis:
ve go deeper inlo an appIicalion lhan lo lhe archileclure IeveI. Hovever, ve
have borroved lhe idea for our inspeclion evaIualion from lhe definilion of
experience-based assessmenl vhich is briefIy menlioned in osch (2002, p. 103).
Whal ve are lrying lo do is lo see hov lhe designed syslem fuIfiIs ils funclionaI
requiremenls and use-case scenarios, nol lhe archileclure quaIily allribules (lhe
reason is lhal lhe quaIily allribules as regarding lo lhe originaI syslem vas
minimaI) and hereby see if ve can gel good measuremenls for making a
comparison of lhe lvo designs.

The idea of experience-based assessmenl is lo use an exlernaI soflvare
archileclure assessmenl leam lhal evaIuales lhe archileclure (or design) by
ob|eclive reasoning based on earIier experiences and IogicaI argumenlalion
(osch, 2002, p. 103). We have lried lo do lhis reasoning ourseIves based on lhe
oId and nev design.

20

There is no singIe melhod or mechanism eslabIished for evaIualing a soflvare
design. The currenl praclice is evaIualions made by vaIklhroughs and inspeclion
of code or designs. These lasks are lime consuming and demand lhe revievers lo
conlroI a Iol of informalion. As lhe evoIulion of lhe design proceeds during UX,
anaIysis and design lhere is a need for a slepping lhrough of lhe produced
arlefacls for recognizing compIiance vilh lhe requiremenls and use-case
scenarios.

Trung Thanh Dinh Trong (2003) suggesls a procedure for syslemalicaIIy lesling
UML design modeIs. Hovever, lhis melhod does nol soIve lhe incompIeleness
nalure of a design modeI. Since lhis lhesis evaIuales an oId and a nev design
modeI and lhe facl lhal lhe nev design resoIves lhe issues of incompIeleness in
lhe oId design lhis melhod can nol easiIy be appIied since lhe oId design modeI
is incompIele.

We found lhal an appropriale vay lo evaIuale lhe lvo designs vas lo foIIov lhe
IIII slandard for soflvare verificalion and vaIidalion regarding lhe design
phase. The slandard suggesls lraceabiIily anaIysis, soflvare design evaIualion,
inlerface anaIysis, crilicaIIy anaIysis and componenl V&V (Verificalion and
VaIidalion) lesl as parl of Design V&V aclivily (IIII, 1998, p. 31). We found lhal
a sufficienl IeveI of evaIualion and a quaIily measure for comparison belveen lhe
lvo designs couId be provided by using lhe lraceabiIily anaIysis in compIiance
vilh lhe slandard.

To verify lhe condilion of lhe lvo designs according lo lhe IIII slandard ve
venl lhrough an inspeclion process (SommerviIIe, 2001, p. 425) of lhe lvo
designs. The condilion of a design according lo us vouId be lo grade lhe
reIalionships in lhe lraceabiIily anaIysis and lhe soflvare design evaIualion. A
usefuI vaIue is aIso lhe deleclion of fauIls and inaccuracies and of course lhe
experl opinion. Since il is a hard lask lo delecl fauIls and inaccuracies in a design
lhal ve have made ourseIves, ve focus on providing an experl opinion.

In lhis evaIualion of lhe designs ve viII use a mixlure of experience-based
assessmenl (osch, 2002, p. 103), inspeclion process (SommerviIIe, 2001, p.425)
vilh lhe heIp of lhe IIII slandard for soflvare verificalion and vaIidalion (IIII,
1998). Iven lhough lhe oId design is nol lhal delaiIed ve lhink lhal lhis melhod
of evaIualion viII give us a fair vaIue of lhe lvo vays of modeIIing. In our ovn
evaIualion ve viII Iook al lhe lraceabiIily of lhe requiremenls and use-cases lo

21
lhe design arlefacls and see if lhe requiremenls and use-cases are fuIfiIIed by lhe
design.

3.3.2 Data cn!!cctinn mcthnd
Inlervievs can be conducled for quaIilalive anaIysis. IormaI inlervievs are
pIanned in advanced and conducled in an environmenl vhere il is possibIe lo go
deeper inlo lhe sub|ecl. The inlerviev is Iead by a person vilh lhe purpose of
galhering informalion (IIy, el. aI., 1993, p. 65). An inlerviev can be slruclured,
semi-slruclured and unslruclured (Robson, 2002, p. 270). The slyIe lhal appIies
mosl lo lhe lhesis and inlervievees is lhe semi-slruclured varianl vhere
queslions can be changed and added depending on lhe inlervievees' perceplion
and knovIedge. Robson (2002, p. 271) describes lhe circumslances in vhich a
quaIilalive research inlerviev is mosl appropriale. In quaIilalive research lhis
approach is lhe mosl videIy used according lo Robson (2002, p.271). We lhink
lhal lhis melhod is mosl appropriale and can provide us vilh meaningfuI
slalemenls from lhe inlervievees as quaIilalive dala.

The dala coIIeclion provided by inlervievs can be described as quaIilalive. The
dala coIIeclion is performed vilh in deplh inlervievs. The personaI conlacl and
insighl is imporlanl in quaIilalive dala coIIeclion as il caplures direcl quolalions
of peopIe's personaI perspeclives and experiences (MarleIIa, NeIson &
Marchand-MarleIIa, 2003, p. 263). This is lhe reason vhy ve chose lo conducl
semi-slruclured inlervievs vilh peopIe, in lhe induslry, and experls lo coIIecl
quaIilalive dala.

4 Rca!izatinn
In lhis chapler ve describe hov ve reaIized lhe praclicaI vork.

4.1 PructlcuI uork
The e-commerce design ve vere Iooking al provided us vilh lhe use-case and
requiremenls for lhe arlicIe search funclion and lhe pIace order funclion. Il aIso
provided us vilh mock-ups of lhe user inlerface: lhese can be found in Appendix
five. We decided lo vork in a simiIar vay vhen redesigning lhe Web
appIicalion. Therefore ve used lhe UI (Unified Irocess), vhich is aImosl lhe
same as ConaIIen uses in his Ialesl book (2002), in such a vay as performing lhe
anaIysis and design phase. An iniliaI phase vas inlroduced vhich incorporaled

22
UX modeIIing as a firsl phase. The melhod ve foIIoved lhus conslilules UX
modeIIing, anaIysis and design.

In lhe User Ixperience phase ve defined lhe screens lhrough lhe use of mock-
ups, use-cases and requiremenls for lhe funclions arlicIe search and pIace order.
Wilh lhe heIp of lhe screens, lhe use-cases vhere lhen organized inlo
sloryboards. Sloryboards are a vay of leIIing a slory aboul a parlicuIar use-case
lhrough discrele slalic piclures (ConaIIen, 2002, p.204). Wilh lhe heIp of lhe
sloryboards and screen definilions ve couId conslrucl a parlicipanls diagram for
each of lhe use-cases and combine lhese lvo logelher lo exlracl a navigalionaI
map over lhe vhoIe syslem funclionaIily (see chapler 11.2.1).

The anaIysis phases slarled vilh mapping lhe screens from lhe UX phase lo
domain boundary cIasses and lhen define a domain modeI from lhe boundary
cIasses and addilionaI conlroIIer cIasses and enlilies. Iach use-case couId lhen be
visuaIized in a sequence diagram consisling of lhe cooperalion of lhese cIasses
and enlilies.

In lhe design phase lhe sequence diagrams, from lhe anaIysis phase, vere
deveIoped furlher lo shov more delaiIs and for mapping lhem lo lhe cIass
diagrams (see chapler 11.2).

4.2 LtuIuutlon
To evaIuale lhe redesigned e-commerce syslem ve are forced lo make a
comparison of lhe condilion, mainlainabiIily and slakehoIder communicalion
belveen lhe redesign vilh WAI-UML and lhe originaI version designed vilh
lhe UML. We choose lo divide our evaIualion in lvo parls, verificalion and
vaIidalion of requiremenls and use-cases and experience-based assessmenl.
These parls are performed vilh lhe originaI version and lhe redesigned version
lo provide measuremenl for comparison. In lhe experience-based evaIualion parl
ve pul ourseIves inlo observers and lry lo reason aboul lhe designs paying
parlicuIar inleresl in lhe quaIily allribules ve have specified. In lhese
circumslances ve see ourseIves as experls doing a simiIar processing of lhe
designs as in experience-based assessmenl. Since lhis melhod is a discussion il is
IikeIy lo be simiIar reasoning in lhe resuIl seclion (chapler 5) and discussion
seclion (chapler 6).


23
To gel addilionaI exlernaI opinions from experls and from persons vorking in
lhe induslry ve conducled inlervievs. The focus here is on aII lhe quaIily
allribules. We aIso lry lo see if lhe inlervievees can lrace lhe requiremenls and
use-cases in lhe design.

4.2.1 Intcrvicws
The inlervievs vere conducled in lvo phases. The firsl phase vas lo Iel lhe
inlervievees conducl a design sludy lo gel famiIiar vilh lhe design diagrams
from bolh designs, as suggesled in SommerviIIe (2001, p. 427). The inlervievees
vere presenled vilh lhe arlicIe search use-case and requiremenls aIong vilh lhe
diagram impIemenlalion using lhe UML and WAI-UML.

In lhe design sludy ve asked lhe inlervievees lo gel famiIiar vilh lhe diagrams
of lhe UML and WAI-UML designs and read lhrough lhe use-case and
requiremenls lo gel prepared for lhe inlerviev. The diagrams vhere navigalionaI
map, sequence-/coIIaboralion diagrams and cIass diagrams. These diagrams are
presenled in Appendix lhree.

The inlervievs vere pIanned lo be heId in a neulraI environmenl because il
makes lhe inlervievees more reIaxed. Hovever, mosl of lhe inlervievs vere
conducled in lhe inlervievees ovn vorking environmenl. The reason vas lhal
lhe inlervievees had a Iimiled lime lo offer and proposed lhal ve vouId come lo
lheir offices. We gave in lo lheir proposaIs because ve feIl lhal lhis couId aIso
heIp lhem reIaxing because lhey vere more famiIiar vilh and accuslomed lo lhe
environmenl. In lhis conlexl ve vere more emolionaI vuInerabIe as lhey had lhe
advanlage of being superior.

We lried lo Iislen more lhan ve spoke and ask lhe queslions in a slraighlforvard
manner. We aIso lried nol lo force lhe inlervievee lo beIieve lhal any of lhe
design aIlernalives vhere beller lhan lhe olher. These aspecls of an inlerviev is
poinled oul as imporlanl by Robson (2002, p. 274). In lhis vay ve gel lhe
inlervievees lo feeI and speak more free and open according lo Robson.

We had pIanned lo record lhe inlervievs for permanenl reference. Robson (2002,
p. 289) argues lhal an inlerviev shouId be recorded for fulure reference and lhal
il aIIovs lhe inlerviev Ieader lo concenlrale on lhe inlerviev. According lo
Ireedman & Weinberg (1990, p. 128) il is nol a good idea lo record design
evaIualions and inlervievs because il can prohibil lhe inlervievee lo say vhal he
or she vanls. They are Iess eager lo express lheir opinions. We choose lo use a

24
Iaplop lo vrile dovn lhe inlervievees ansvers. We lhink lhal ve have caplured
lhe mosl imporlanl slalemenls in lhis vay and received a more honesl opinion
from lhe inlervievees.

In addilion ve have foIIoved lhe four basic requiremenls for elhicaI research
vhere lhe focus is on prolecling lhe inlegrily of lhe persons invoIved in lhe
research (Svedish Research CounciI, 2002, p. 6). In shorl lhese requiremenls
provide means lo prolecl individuaI parlicipalion in lhe research: for exampIe, lo
inform lhe parlicipanls of lhe purpose of lhe research. Iarlicipanls shouId aIso
have lhe righl of seIf-delerminalion lo parlicipale in lhe research. Iurlher, aII
personaI informalion from lhe informanls shouId be confidenliaI and prolecled
so lhal no unaulhorized peopIe can access il. The informalion coIIecled shouId
onIy be used for research means. These principIes are aII recommended by lhe
Svedish Research CounciI (2002 p. 6).

5c!cctinn nI intcrvicwccs
The inlervievees vere seIecled by us lo receive differenl vievpoinls. Tvo vork
in lhe induslry of deveIoping Web appIicalions, lvo vas a parl of lhe leam
deveIoping lhe originaI e-commerce syslem and one is a UML experl. We did nol
choose lhese four persons lo Iead lhe resuIling dala lovards favouring WAI-
UML bul lo gel vaIuabIe slalemenls seeing lhem as experls in lheir fieIds. We did
nol beIieve lhal a person vilhoul any knovIedge of UML or soflvare
engineering melhods vouId add any vaIue lo lhe dala coIIeclion.

Inlervieving lvo persons lhal more or Iess vere invoIved in lhe deveIopmenl of
lhe originaI e-commerce syslem vas a deIiberale choice. As such ve vere sure
lhal lhey had experience in Web appIicalion deveIopmenl vilh UML. We
vanled lo see hov lhey perceived lhe nev design vilh WAI-UML. In addilion
ve beIieved lhal lhey couId provide vaIuabIe opinions aboul lhe probIems vilh
using UML and if WAI-UML couId improve lhe design.

Qucstinnnairc
Robson (2002, p. 275) Iisls some aspecls lhal are imporlanl lo lhink of vhen you
design lhe inlerviev queslions. In shorl lhese are lo avoid Iong and doubIe-
barreIIed queslions, queslions invoIving |argon, Ieading queslions and biased
queslions. In designing our queslionnaire ve have lried lo foIIov lhese aspecls.


25
The queslions vere divided inlo lhree ma|or areas. Iirsl ve vanled lo check lhe
background knovIedge of lhe inlervievees. We asked lhem if lhey vere famiIiar
vilh deveIopmenl of Web appIicalions and vhal melhods and lechnoIogies lhey
had been used. We aIso asked if lhey had previousIy vorked vilh or vere
famiIiar vilh UML, WAI-UML and slereolypes.

The second area of inleresl vas lhe design arlefacls. These queslions vere
performed separaleIy by lhe inlervievees for lhe UML design and lhen lhe
WAI-UML design. ecause ve knev lhal lhe WAI-UML design provided more
informalion aboul lhe syslem funclionaIily ve slarled lo ask lhe design queslions
aboul lhe UML design firsl and lhen lhe WAI-UML design. In lhis vay ve
meanl lo caplure addilionaI aspecls aboul lhe never design since ve knev il
provided more delaiIed informalion.

In lhe lhird parl ve vanled lo see hov much lhey had grasped aboul lhe concepl
of WAI-UML and if il couId be any heIp lo lhem in lheir vork. In lhis vay ve
vanled lo measure lhe popuIarily among lhe lvo melhods. AddilionaIIy, ve
asked lhem vhich design lhey vouId choose being in a cerlain silualion as a
cuslomer, execulive and programmer. The compIele queslionnaire can be found
in appendix six.

5 Rcsu!t and ana!yzc
In lhis chapler ve presenl lhe resuIl of our ovn evaIualion vhich incIudes a
summary of our ovn opinions aboul lhe diagrams deveIoped vilh WAI-UML
aIong vilh lhe verificalion and vaIidalion of lhe requiremenls and use-cases.
Iurlher, ve presenl lhe maleriaI coIIecled during lhe inlervievs.

When lhe vord design is menlioned il is in regard lo lhe navigalionaI map, cIass
diagrams and sequence diagrams as presenled in lhe appendixes, chapler 11.2.

5.1 Oun etuIuutlon
Our ovn evaIualion is divided inlo lvo main seclions. In lhe firsl seclion ve
presenl lhe verificalion and vaIidalion of lhe requiremenls and use-cases.

The second seclion Iisls our ovn commenls on lhe properlies of condilion,
mainlenance and slakehoIder communicalion, regarded lo lhe WAI-UML
varianl and in opposile lo lhe UML varianl, as lhe resuIl of lhe experience-based

26
assessmenl. The slalemenls in lhis sub-chapler does nol have any scienlific
evidence bul is based on previous design experience and lhe praclicaI redesign of
lhe e-commerce syslem vilh WAI-UML vilh lhe heIp of ob|eclive reasoning as
observers. A crilicaI discussion of lhese slalemenls is provided in subsequenl
chaplers.

5.1.1 VcriIicatinn and va!idatinn
The verificalion and vaIidalion of lhe requiremenls for bolh lhe UML varianl and
lhe WAI-UML varianl, separaleIy, are summarized in diagram 1. Here ve
presenl lhe percenlage of fuIfiIIed requiremenls.

The crileria for a requiremenl lo vaIidale lo fuIfiIIed is lhal il can be lraced lo
lhe design and lhal aII delaiIs in lhe requiremenl is visibIe in lhe design. A
requiremenl lhal vaIidales lo parlIy fuIfiIIed can be lraced lo lhe design bul nol
aII delaiIs in lhe requiremenl is visibIe in lhe design. A requiremenl lhal is nol
fuIfiIIed cannol be lraced lo lhe design al aII. These crileria are nol parl of lhe
slandard bul sel by us lo provide means for measuremenl.


Diagram 1: Expcricncc-bascd asscssmcnt with rcquircmcnts vcriIicatinn nI WAE-UML and thc
UML dcsign.

This resuIl can be a bil misIeading. Mosl of lhe peopIe lhal vere invoIved in lhe
modeIIing of lhe originaI e-commerce appIicalion vilh lhe UML vere nol very
inleresled in modeIIing al aII. Hovever, lhe cause of lhis viev among lhe
designers can be lraced lo lhe facl lhal lhe UML does nol provide semanlics
enough lo modeI Web appIicalions. Il lhen becomes an exhauslive lask lo modeI
il.
Requirements Verification
0%
10%
20%
30%
40%
50%
60%
70%
Fulfilled Partly fulfilled Not fulfilled
WAE-UML
UML

27

Opposed lo lhe requiremenl verificalion lhe use-case verificalion can eilher be
fuIfiIIed or nol fuIfiIIed. In lhe UML design ve did nol manage lo lrace nor
vaIidale any of lhe use-cases basic fIovs. The same use-cases basic fIov couId be
lraced lo lhe WAI-UML design. The reason lhal lhe use-cases are nol fuIfiIIed by
lhe UML design can be lhe same as for lhe requiremenls nol being fuIfiIIed.
These crileria are sel by us lo provide means for measuremenl.

5.1.2 Expcricncc-bascd asscssmcnt
This chapler is based on our evaIualion of lhe WAI-UML design. The diagrams
menlioned are lhe navigalionaI map, cIass diagrams and sequence diagrams.
These diagrams are presenled in appendix lhree, chapler 11.2 - I-commerce
redesign.

Cnnditinn
Our definilion of lhe condilion of lhe design arlefacls means lhal lhe design
arlefacls shouId prove lo fuIfiI lhe requiremenls and use-cases, resembIe reaIily
and nol be misIeading.

According lo us, lhe mosl imporlanl documenl produced by lhe UX is lhe
navigalionaI map. Il shovs lhe hypermedia and informalion design in lhe form
of screens. The navigalionaI map deveIoped for lhe e-commerce appIicalion
redesign does nol incIude aII of lhe informalion necessary lhough. As ConaIIen
(2002, p. 187) poinls oul: lhe UX modeIIing leam and design leam vork in
paraIIeI and mosl of lhe UX modeIIing has ils rools in lhe human- compuler
inleraclion and shouId nol be a parl of lhe lasks assigned lo lhe design leam.
Thus, lhe focus of lhe Ialler slages in UX modeIIing shouId focus on improving
lhe hypermedia and informalion design. Hovever, since UX provides a good
slarl for lhe resl of lhe deveIopmenl and lhal lhe navigalionaI map and lhe
screens are direcl inpul lo anaIysis a Iess delaiIed UX efforl shouId be required
before lhe anaIysis begins. As lhe UX modeIIing is use-case cenlric a good
assurance can be assumed lhal lhe use-cases viII be fuIfiIIed al Ieasl al lhe slarl of
lhe anaIysis and design phase. Ior a more secure assurance in lhis maller
verificalion and vaIidalion of bolh lhe use-cases and requiremenls can be appIied
belveen lhe process phases.


28
Assuming lhal a slakehoIder possesses adequale knovIedge of lhe slereolypes
used for modeIIing screens and for crealing lhe design diagrams, lhe documenls
shouId nol be misIeading. The navigalionaI map shovs simpIe lhings in lhe form
of screens bul gives a good viev of lhe navigalionaI slruclure and informalion
dislribulion in lhe syslem and cannol easiIy be misinlerpreled. The cIass
diagrams and sequence diagrams from lhe design phase does aIso adhere lo lhis
properly. In facl, lhe design diagrams reveaI lhe underIying archileclure of lhe
syslem and as such are a prospecl for generaling code vilh a CASI looI
provided lhal lhe correcl semanlics has been used.

We can nol drav any concIusion if lhe design diagrams resembIes reaIily as lhe
aspecl of reaIily is lo lhe observers ovn viev. We lhink, lhough, lhal lhe facl lhal
lhe design diagrams reveaIs lhe archileclure, il does resembIes reaIily if adequale
knovIedge of lhe slereolypes used are possessed. The design resembIes reaIily in
lhe aspecl lhal WAI-UML divides a veb page inlo ils reaI componenls. The veb
page is divided inlo a server page, a cIienl page and ils conlenls in lhe vay of
forms and scripls. In lhis vay ve can see lhe acluaI archileclure and lhe design is
more IikeIy lo resembIe reaIily. Iigure lvo shovs lhe concepl of a reveaIed
archileclure. In lhe WAI-UML exlraclion ve can cIearIy lrace lhe .NIT
archileclure. In lhe UML varianl lhese cIasses are modeIIed as a singIe enlily.


Figurc 2: Artic!c scarch Wcb pagc with UML and WAE-UML


Iigure lvo shovs exlraclions from lhe UML design and lhe WAI-UML design.
The WAI-UML exlraclion shovs lhal lhe Web page is composed of a cIienl page,
a server page and a code behind cIass. In lhe UML exlraclion lhe Web page is

29
modeIIed vilh a singIe ob|ecl supposed lo incIude lhe cIienl page, server page
and lhe code behind cIass.

Screens in lhe navigalionaI map resembIes reaIily in lhe vay lhal lhey are lhe
physicaI ob|ecls lhal lhe user sees and provides him vilh inpul fieIds and
dynamic behaviour (read navigalion).

Cnmmunicatinn
The communicalion aspecls ve are Iooking al means lhal lhe design shouId
prove lo provide unambiguous arlefacls, be easy lo undersland and
communicale lhe reaI message in compIiance vilh lhe use-cases and
requiremenls.

We can Iook al communicalion from lvo vievpoinls. The reader of lhe diagrams
does nol have any knovIedge of soflvare deveIopmenl and UML nolalion, such
as somelimes in lhe case vilh cuslomers. The reader of lhe documenl is a
programmer or designer vilh medium lo high knovIedge of soflvare
deveIopmenl and UML nolalion.

If ve suppose lhal a slakehoIder has lhe required knovIedge of lhe soflvare
deveIopmenl process, UML and WAI-UML slereolypes il is fairIy easy lo
inlerprel and undersland lhe design arlefacls depending on lhe design diagrams
IeveI of delaiI. The design arlefacls produced vilh WAI-UML lends lo shov a
Iol of delaiI in lhe design, especiaIIy lhe sequence diagrams (see appendix lhree,
chapler 11.2.5-11.2.9). This can be bolh posilive and negalive from a
communicalionaI aspecl and from a mainlainabiIily poinl of viev. The good parl
is lhal a high IeveI of delaiI cerlainIy is lo resembIe reaIily beller lhan an abslracl
design. In lhe diagrams in appendix lhree, chapler 11.2.5 11.2.9, ve can cIearIy
see vhal is happening behind lhe scene. On lhe bad side il has Iimilalions on lhe
communicalion and mainlainabiIily aspecl because il viII be hard for lhe
slakehoIders lo inlerprel and grasp lhe compIele piclure of lhe syslem. Ior lhe
same reasons, as vilh lhe condilion of lhe arlefacls, since lhe archileclure is
reveaIed in lhe design ve can slale lhal lhe arlefacls are Iess unambiguous and
communicale lhe reaI message of lhe appIicalion (See exampIe in figure lvo).

Ior a slakehoIder, e. g. a cuslomer or a person vilh Iess knovIedge of UML, lhe
navigalionaI map can presenl a good vay lo mediale a comprehensive viev of
lhe syslem from lhe users' perspeclive. Using mock-ups and lhe navigalionaI

30
map, lhe message of lhe appIicalion design can be communicaled lo a cuslomer.
The navigalionaI map mediales lhe basic fIov of informalion and navigalion
belveen screens (Web page vievs) if lhe user submils a form or navigales lo a
nev screen. A Iarge Web appIicalion can conlain many Web pages and a
compIex navigalion slruclure. The navigalion slruclure is aIso haphazard in lhe
conlexl of lhe users' navigalion habils. Therefore, aII IegaI fIovs in an
appIicalion cannol be modeIIed. ConaIIen agrees on lhis vievpoinl and provides
guideIines lo overcome lhis probIem (2002, s. 210). Iven lhough lhe exampIe
navigalionaI map deveIoped during lhe redesign of lhe e-commerce syslem
conlains a very smaII amounl of screens il is sliII compIex. The navigalionaI map
provides Iinks and user inpul on a Iess lechnicaI IeveI of underslanding and can
be medialed regardIess of lhe receiver's lechnicaI underslanding. Once a
slakehoIder grasps lhe concepl of a screen lhe navigalionaI map is easy lo
undersland.

Maintainabi!ity
There are lvo lypes of mainlenance on a piece of soflvare and ils bIueprinls.
When lhe appIicalion is under deveIopmenl mainlenance of lhe documenls can
be done by programmers or by lhe design leam. When lhe appIicalion is
deIivered, bugs musl be fixed. Mosl appIicalions are exlended or redesigned in
lhe fulure. olh aspecls require mainlenance of lhe design diagrams. These lvo
lypes are equaIIy imporlanl, bul lo be abIe lo mainlain lhe design during posl-
deIivery mainlenance lhey shouId be updaled during lhe impIemenlalion phase.

Opposed lo previous design efforls vilh lhe UML, UX modeIIing vilh WAI-
UML provides a good slarling poinl for lhe vhoIe design process. DireclIy
slarling vilh lhe use-case anaIysis phase can be an oblrusiveIy hard lask vhen
designing a Web appIicalion. This quick slarl modeIIing shouId improve lhe
commilmenl in lhe deveIopmenl leam lo mainlain and foIIov lhe documenls
during lhe vhoIe process.

Mosl of lhe UX design arlefacls are lo our opinion easy lo change and updale.
ecause hypermedia and informalion design can be compIex il is easy for bolh
lhe UX diagrams and lhe design diagrams lo become confusing and messy if lhe
appIicalion under anaIysis is Iarge. Il reslrains mainlenance and prohibils
communicalion. To some exlenl lhis can be Iimiled by lhe use of adornmenls.
Adornmenls describe addilionaI properlies of screens. In figure lhree ve have
Iimiled lhe reIalions of lhe arlicIe search screen by lhe adornmenls $-sign and +-

31
sign. The $-sign leIIs us lhal lhe ArlicIeSearch screen can be navigaled lo from
every olher screen in lhey appIicalion. In addilion lhe +-sign describes lhal lhe
resuIl of lhe search is presenled lo lhe user using severaI screens. In lhis vay ve
can reduce lhe compIexily of modeIIing lhis vilh reIalions belveen screens and
deIimil lhe search mechanism lo one screen. A more in-deplh descriplion of
adornmenls and lheir use is provided by ConaIIen (2002, p. 210).


Figurc 3: Artic!c scarch navigatinn scrccns WAE-UML

Ior lhe same reason of compIexily lhe design diagrams can aIso become
confusing and messy if lhe appIicalion is Iarge. ModeIIing a Iarge appIicalion lhe
documenls can become loo exlensive in size vhich Ieads lo lhal lhey are hard lo
handIe and Iess perspicuous. Il can aIso be hard lo demarcale lhe documenls inlo
smaIIer pieces, e. g. lhe sequence diagrams, cIass diagrams and sloryboards.

5.2 ResuIt und unuIze of the lntertleus

5.2.1 Cnnditinn
We asked lhe inlervievees lo see if lhey couId lrace and verify lhal lhe
requiremenls for lhe arlicIe search use-case vas fuIfiIIed in lhe nev and oId
design diagrams. In lhe oId design, requiremenl one and lvo couId be lraced
and verified by lhree of lhe inlervievees aIlhough some guessing vas required.
Some aspecls in lhe design vere uncIear lo lhem. Hovever in lhe nev design aII
inlervievees proved lo be abIe lo lrace and verify lhe requiremenls one and lvo.
Requiremenl number lhree vas nol fuIfiIIed according lo lhree inlervievees. One
inlervievee couId indeed verify lhe requiremenl bul he vas a parl of lhe oId

32
design pro|ecl leam. Sevenly-five percenl of lhe inlervievees couId lrace and
verify lhis requiremenl in lhe nev design. The fourlh couId verify il vhen
poinled oul lhal lhe lvo sequence diagrams vere Iinked logelher in an ad-hoc
vay. Requiremenl number four couId nol be verified by any of lhe inlervievees
in lhe oId design bul fifly percenl couId verify il in lhe nev design. The resuIl of
lhe requiremenls verificalion is summarized in diagram lvo vhere ve presenl
lhe percenlage of lhe inlervievees' abiIily lo lrace and verify requiremenls one lo
four.


Diagram 2: Intcrvicw rcquircmcnt vcriIicatinn nI WAE-UML and thc UML dcsign.


We aIso asked lhe inlervievees lo lry lo lrace and verify lhal lhe use-case vas
fuIfiIIed by lhe UML and WAI-UML design arlefacls separaleIy. None of lhe
inlervievees couId lrace lhe use-case and verify il in lhe UML design documenls
compIeleIy. The WAI-UML design shoved lo fuIfiI lhe use-case basic fIov lo aII
lhe inlervievees. Hovever, one of lhem lhoughl lhal lhere vere loo much delaiI
in lhe WAI-UML design and il vas hard lo connecl il lo lhe use-case
specificalion.

5.2.2 Cnmmunicatinn
To gel a feeI for lhe communicalion properlies lhal lhe oId and nev design hoIds
ve asked lhe inlervievees lo describe vhal lhey lhoughl lhe syslem did Iooking
firsl al lhe oId and lhen lhe nev design. The lvo inlervievees lhal had been
invoIved in lhe oId e-commerce design proved lo grasp lhe concepl of lhal il
acluaIIy vas a search mechanism described in lhe oId diagrams. The olher lvo
Verification of Requirements
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Req. 1 Req. 2 Req. 3 Req. 4
UML
WAE-UML

33
shoved more viIIing lo find such informalion as lhal lhere vas a dalabase
incIuded, lhal il vas possibIe for a user lo Iogin and lhal lhe user seemed lo be
abIe lo pIace orders of some kind. Looking al lhe nev design lhe lvo
inlervievees lhal vere nol parl of lhe oId e-commerce design leam seemed lo
grasp lhe concepl of lhal lhe nev design indeed vas a Web appIicalion and lhal
il couId be used for some kind of search mechanism. The inlervievees lhal
parlicipaled in lhe impIemenlalion of lhe oId design found addilionaI properlies
in lhe nev design documenls such as lhe possibiIily lo search for arlicIes and
lhen add lhem lo an order up lo a cerlain amounl.

When lhe inlervievees vhere asked if lhey vouId be abIe lo impIemenl lhe
arlicIe search funclion given lhe UML diagrams, lvo of lhem vere nol sure if
lhey couId do lhal given onIy lhe design diagrams. Il vouId heIp lhem lo use lhe
use-case specificalion and requiremenls. Tvo of lhe inlervievees vere quile
cerlain lhal lhey vouId be abIe lo impIemenl il: hovever lhey vere bolh famiIiar
vilh lhe UML diagrams since lhey vere parl of lhe oId design leam. AII lhe
inlervievees vere posilive lhal lhey couId impIemenl lhe arlicIe search funclion
vilh lhe heIp of lhe WAI-UML diagrams. Il vas commenled lhal lhe WAI-UML
design code couId easiIy be aulo-generaled vilh a CASI-looI. As one of lhe
inlervievees vas more famiIiar vilh IHI inslead of .NIT he vouId have chosen
lo use lhal inslead.

We asked lhe inlervievees lo expIain vhal happened if an arlicIe vas added by
lhe user lo a non-exisling order. In lhis vay ve vanled lo see if lhe design
documenls vere cIear enough for vhal happened if an order did nol exisl in lhe
diagrams. Il seemed lhal none of lhe inlervievees couId lrace in any of lhe
diagrams, nol UML diagrams or WAI-UML diagrams, vhal vouId happen.

5.2.3 Maintainabi!ity
The inlervievees vere asked lo change a smaII funclionaIily in lhe WAI-UML
design documenls. In lhal vay ve vanled lo see hov hard il vouId be lo change
a smaII funclion in lhe arlicIe search funclionaIily. Three of lhe inlervievees
cIaimed lhey vouId be abIe lo redesign il aIlhough lhey couId nol poinl oul hov
lo change lhe diagrams. One inlervievee shoved lhe correcl vay of doing lhis in
lhe diagrams vilh some heIp provided by lhe inlerviev Ieader.


34
5.2.4 PcrInrmancc
Irom a performance perspeclive in lhe UML design and WAI-UML design
separaleIy, ve asked lhe inlervievees hov lhey lhoughl lhe impIemenled arlicIe
search vouId perform. We lried lo percepl lhe feeI and underslanding lhey had
for lhe design varianls by asking lhis queslion.

One inlervievee argued lhal lhe performance of lhe UML varianl vouIdn'l be
loo sIov because il shoved high cohesion. The resl lhoughl lhal lhis varianl
vouId be very compIicaled and Iumpy in performance. The WAI-UML varianl
proved lo be more popuIar by lhe inlervievees from a performance perspeclive.
Hovever, one inlervievee lhoughl lhal il vouId be vorse due lo lhe facl lhal he
couId nov see lhal lhe syslem used a Iol of redireclion bul shoved lo improve
lhe cohesion issue from lhe UML design.

5.2.5 Intcrvicwcc npininn
The inlervievees vere asked lo become a cuslomer and lhen asked from lhis
aspecl vhich design lhey vouId choose. Three inlervievees vouId have chosen
lhe WAI-UML design, hovever, from a cuslomer perspeclive lhe design
diagrams shoved loo much delaiIs. One of lhe inlervievees vouId have
required onIy lhe use-case specificalion as a cuslomer. Irom a programmer
perspeclive lhey aII vouId have chosen lhe WAI-UML varianl because lhey
vere more perspicuous according lo lhem.

The inlervievees lhoughl lhal lhe WAI-UML varianl couId indeed heIp lhem in
fulure designs aIlhough lhe peopIe vorking in lhe induslry lhoughl il vouId
require loo much efforl lo deveIop lhese design arlefacls and loo much lime
vouId be required lo Iearn lhe lechnique.

6 Discussinn
The dala anaIysis and praclicaI vork in our quaIilalive research have proved lo
be sIighlIy affecled by our ovn slance lovards WAI-UML. As ve found lhis
vay of modeIIing appeaIing and easy il mighl have affecled our crilicaI slance
lovards lhe olher melhods and lhe ob|ecliveness lovards modeIIing vilh WAI-
UML.

In lhe inlroduclion parl of lhe lhesis ve slaled a fev probIem areas regarding lhe
modeIIing of Web appIicalions vilh lhe UML in previous pro|ecls according lo

35
our ovn experience. The probIem descriplion circuIaled in lhree ma|or areas,
nameIy lhe condilion of lhe design arlefacls, abiIily for communicalion belveen
slakehoIders and design diagram mainlenance. We defined condilion in regard
lo verificalion and vaIidalion of requiremenls and use-case. The design arlefacls
shouId resembIe reaIily and nol be misIeading. Communicalion belveen
slakehoIders defines lhe provision of unambiguous design arlefacls lhal are easy
lo undersland and lhal communicale lhe reaI message in compIiance vilh lhe
use-cases. The Iasl imporlanl quaIily allribule of lhe design arlefacls vere
mainlainabiIily. This allribule defined lhe abiIily and ease of mainlaining and
updale of lhe design arlefacls. The foIIoving discussion of lhe resuIl does
circuIale around lhese lhree quaIily allribules.

6.1 Condltlon
When ve lraced and vaIidaled lhe requiremenls and use-cases lovards lhe
designs ve found aslonishing resuIls. Iifly percenl of lhe requiremenls and none
of lhe use-cases vere compIeleIy incorporaled in lhe oId UML design. The
requiremenl verificalion and vaIidalion done by lhe inlervievees provides
simiIar resuIl as in our ovn verificalion and vaIidalion. The use-case verificalion
and vaIidalion aIso provided exaclIy lhe same resuIl as in our ovn evaIualion.
Iven lhough ve are unsure lhal lhe e-commerce UML design is represenlalive in
an induslry perspeclive, lhis resuIl musl be regarded as poor from a soflvare
engineering poinl of viev. The resuIl of lhis is lhal lhe programmers have no
vaIue using lhe design arlefacls, bul have lo use lhe requiremenls specificalion
and use-cases, nol lo forgel lheir imaginalion, vhen impIemenling lhe syslem.
Tvo inlervievees menlioned lhal lhey did nol use any specific modeIIing
lechnique, and mainIy vere dependenl on specificalions and descriplive lexl
documenls. Those inlervievees vorked in lhe induslry deveIoping Web
appIicalions. WAI-UML shoved lo improve lhe requiremenl and use-case
lraceabiIily radicaIIy even lhough nol aII requiremenls couId be lraced. The
improvemenls can be connecled lo lhe use of User Ixperience as a parl of lhe
earIy slages modeIIing vilh WAI-UML: since UX incorporales, in an earIy slage,
lhe use of use-cases in lhe modeIIing. The consequence is lhal lhe use-cases can
be lraced aII lhe vay lo lhe finished design if carefuI allenlion is laken during
Ialer slages. Hovever, lhe inlervievees vere reIuclanl lo adapl a nev lechnique
of modeIIing Web appIicalions because of lhe lime aspecl.

Anolher vay of Iooking al lhe requiremenls is lhal lhe modeIIing environmenl
can nol be lhe same in lhe lvo circumslances in our case. Some of lhe aspecls

36
lhal pIay a roIe are, firsl, lhe peopIe modeIIing lhe lvo versions vere nol lhe
same excepl for one person. This mighl infIuence lhe condilion of lhe nev
design. Second, as a researcher, il is hard lo lake an ob|eclive slandpoinl vhen he
or she knovs lhal lhe vork viII be |udged.

The inlervievs shoved lhal a person is more viIIing lo see lhal lhe archileclure
is a Web appIicalion in lhe WAI-UML design. We can concIude by lhis lhal lhe
WAI-UML design is more IikeIy lo mediale a more lrulhfuI rca|iiu.

6.2 Communlcutlon
A resuIl of using UX is lhal ve can reduce lhe compIexily of performing anaIysis
and design. In lhe redesign vork lhe UX modeIIing provided us vilh a good
quick slarl lo modeIIing, adapling a user perspeclive. ecause lhe use-cases vere
a big parl of UX ve vere forced lo lhoroughIy undersland lhem lo be abIe lo
perceive and perform lhe UX modeIIing. Irom a designer's perspeclive,
underslanding lhe use-cases is vilaI for lhe communicalion. ConaIIen advocales
lhal lhe UX modeIIing shouId be performed by a separale group. Opposile from
ConaIIens viev, ve lhink lhal if lhe UX modeIIing is performed by lhe designers,
or in cooperalion vilh lhis separale UX group, il can improve lhe
communicalion in lhe deveIopmenl leam by improving lhe underslanding of lhe
use-cases and lhe syslem funclionaIily. Il lhen can mediale lhe reaI message in
compIiance vilh lhe use-cases and requiremenls lo olher slakehoIders.

As aII of lhe inlervievees vere very posilive lhal lhey vouId be abIe lo
impIemenl lhe WAI-UML design easier lhan lhe UML design ve can say lhal
lhe nev one provides a Iess unan|igucus design and are easier lo undersland. In
lhe conlexl of condilion il is nol IikeIy lo be nis|ca!ing. Hovever, since none of
lhe inlervievees vere abIe lo lrace vhal vas happening if an order vas nol
crealed before adding arlicIes in any of lhe design, ve suspecl lhal lhis queslion
vas loo delaiIed and compIicaled lo ansver in a good vay. Since one of lhe
inlervievee misunderslood lhe queslion and vas referring lo an order ob|ecl
inslead of a physicaI order ve suspecl lhal lhe queslion had cerlain
indislinclness. Oul of lhis resuIl ve can nol drav any concIusions, for any of lhe
designs, in lhe maller of ambiguousness.


37
6.3 MulntulnublIlt
The mainlainabiIily of design arlefacls is hard lo measure. In lhe praclicaI vork
ve vere somelimes forced lo accompIish smaII redesigns due lo lhe facl lhal ve
missed vilaI parls of lhe use-case. Looking al mainlenance from lhis aspecl ve
managed lo accompIish lhe redesigns quile easiIy. The inlervievs on lhe olher
hand proved lo us lhal a person lhal is nol lhal veII invoIved in lhe design and
nol so accuslomed lo lhe semanlics of lhe Ianguage, and lhe slereolypes, is
oblrusiveIy much Iess probabIe lo be abIe lo accompIish a redesign. In lhis aspecl
il is imporlanl lhal lhe mainlainers and programmers, if lhey are lo updale lhe
documenls during impIemenlalion, are veII accuslomed lo lhe design and
possesses adequale knovIedge of lhe semanlics used. The IeveI of delaiI in lhe
documenls is aIso an imporlanl aspecl of mainlainabiIily.

The inlerviev queslion aboul mainlainabiIily vas loo delaiIed lo be ansvered
vilh lhe UML design. We asked lhis queslion lo gel opinions al lo vhal exlenl
lhe WAI-UML provided mainlainabiIily. Iven lhough ve lhoughl lhe change in
lhe WAI-UML design shouId have been very easy lo do none of lhe inlervievees
seemed lo see lo be abIe lo shov us hov lo perform il during lhe inlerviev. We
suspecl lhal il vouId have required a Ionger design sludy and beller preparalion
of lhe inlervievees lo perform lhis redesign.

ecause vilh WAI-UML ve can divide a veb page ob|ecl inlo ils reaI
componenls, server page, hlmI page and forms, among olher, in lhe design lhe
cohesion of individuaI ob|ecls are affecled by lhe modeIIers' choice of
responsibiIily dislribulion. This can in lurn affecl mainlainabiIily because lhe
responsibiIily of ob|ecls can become loo reIaled lo one anolher lhal enormous
compIexily is inherenl. Then il viII be very hard lo break lhem and redislribule
lhe responsibiIily for lhese ob|ecls. This division of veb pages aIso has infIuence
on lhe abiIily lo demarcale lhe syslem design and compose severaI smaIIer
design documenls inslead of a Iarge.

6.4 Test of hothesls
Since ve use a quaIilalive melhod for examine lhe reIalionships belveen a UML
design and a WAI-UML design ve can nol lesl lhe hypolhesis in a slalislicaI
vay. The allempl lo lesl lhe hypolhesis is based on experience-based assessmenl
and lhe inlerpreled quaIilalive dala from lhe inlervievs.


38
During lhe praclicaI vork ve shoved hov lhe UML couId be used lo modeI a
Web appIicalion by lhe use of an exlension melhod, WAI-UML. According lo
our ob|eclive appraisaI ve can lry lhe hypolhesis in lhe e-commerce redesign
parlicuIar case onIy. y no means can ve slale lhal WAI-UML provides
improvemenls in aII Web appIicalion designs.

To reason aboul lhe hypolhesis ve invesligale lhe quaIily allribules lhal
conslilules il: ve need lo Iook separaleIy al lhe condilion, communicalion and
mainlenance. The redesigned e-commerce syslem improves many aspecls vhen
il comes lo condilion. AII use-cases and mosl of lhe requiremenls are fuIfiIIed.
Depending on lhe IeveI of delaiI as chosen by lhe designer il does resembIe
reaIily beller and is Iess misIeading for lhe programmers. AIlhough ve cannol
prove lhal lhis is lrue in lhe generaI case ve see an improvemenl of lhese aspecls
in lhe redesign.

Again, depending on lhe IeveI of delaiI used by lhe designers lhe WAI-UML
version provides us vilh unambiguous arlefacls, lhal are easy lo undersland,
and communicales lhe reaI message in compIiance vilh lhe use-cases and
requiremenls.

The mainlainabiIily aspecl is improved in lhey vay lhal lhe programmers are
mosl IikeIy lo find lhe design arlefacls usefuI and commil lo updales and
mainlenance during lhe impIemenlalion. As lhe inlervievs shoved, lhe designs
can conlain loo much delaiI. This means lhal mainlenance personneI olher lhan
lhe originaI impIemenlers have il harder lo undersland lhe design and perform
updales of il. If lhese peopIe do have a common knovIedge of lhe WAI-UML il
mighl be a bil easier.

Iven if lhe redesigned e-commerce appIicalion arlefacls provide improvemenls
in aII aspecls of lhe hypolhesis ve can nol hoId for cerlain lhal il is lrue for aII
Web appIicalions. There mighl be a Iol of differenl lechnoIogies and aspecls
invoIved lhal can have infIuence on lhe quaIily allribules. The IeveI of delaiI in
lhe design arlefacls pIays a Iarge roIe in lhis infIuence and il is up lo lhe
designers experience lo modeI lhe Web appIicalion al a sufficienl IeveI. If lhis
IeveI of delaiI is allained, WAI-UML provides an inleresling vay of modeIIing
and can improve lhe design arlefacls according lo lhe discussed aspecls.


39
6.5 GouIs
Irovided vilh an exlension mechanism, lhe UML is cerlainIy suilabIe for lhe
modeIIing of Web appIicalions. In lhe praclicaI vork ve incorporaled lhe UML
vilh lhe exlension lo UML, WAI-UML. We shoved hov pre-exisling
knovIedge of lhe UML can indeed, indirecl by using lhe exlension melhod
WAI-UML, be used for modeIIing Web appIicalions. Since WAI-UML is
deveIoped from UML vilh exlensions ve have found a good vay of inlroducing
UML modeIIing inlo lhe Web appIicalion induslry. Iven lhough lhe induslry
peopIe vere a bil reIuclanl lo adapl such a process inlo lheir vork, due lo lhe
lime aspecl, ve lhink lhal il can ease lhe mainlenance and increase
impIemenlalion speed. According lo our previous experience, bolh vilh Web
appIicalion and lradilionaI desklop programming, il is much harder lo program
using a descriplive specificalion lhan by a visuaI design. A formaI and correcl
design can aIso be used lo generale slub code by a CASI looI vhich vouId
decrease lhe lime spenl on impIemenlalion. Il is aIso imporlanl lo nole lhal a
correcl design lhal proves lo lrace and vaIidale lhe requiremenls and use-cases
decreases inconsislencies in lhe program code. More requiremenls viII be
impIemenled in lhe producl from lhe slarl. This mighl decrease lhe lime spenl on
lesling and error fixing. Thal is vhy il is imporlanl lo modeI aIso Web
appIicalions. As mosl soflvare deveIopmenl pro|ecls have budgel and lime
Iimils, modeIIing shouId improve bolh aspecls.

Irom our experience of lhe vork vilh lhis lhesis ve have deveIoped a melhod
and inslincl inlo modeIIing Web appIicalions vilh WAI-UML. Since lhis melhod
shoved lo provide many improvemenls of lhe design ve viII in lhe fulure be
abIe lo creale beller design arlefacls for Web appIicalions. Depending on lhe
securily aspecls of lhe appIicalion under deveIopmenl ve vouId choose lo
deveIop Web appIicalions inslead of lhe more lradilionaI cIienl/server
appIicalions.

6.6 Dlscusslon of methods
The inlervievees can have been infIuenced during lhe inlervievs in a coupIe of
vays. The UML diagrams vere prinled in bIack and vhile vhiIe lhe WAI-UML
diagrams vere prinled in coIour. This vas poinled oul lo us by one if lhe
inlervievee. The inleraclion modeIIing of lhe use-case vas described by a
coIIaboralion diagram in lhe UML varianl and as a sequence diagram in lhe
WAI-UML. The amounl of infIuence lhese aspecls had on lhe inlervievee's
opinions is uncerlain. olh lhese diagrams, coIIaboralion diagrams and sequence

40
diagrams are compalibIe and describe lhe same lhings. We choose lo do lhe
WAI-UML design vilh sequence diagram because lhey provide a beller
slruclure if lhe diagrams conlain many delaiIs. CoIIaboralion diagrams vilh a Iol
of delaiI easiIy gel compIicaled and grov in aII direclions. Sequence diagrams
grov moslIy verlicaIIy and can be presenled and prinled easier. olh diagram
lypes can be conslrucled vilh lhe UML and WAI-UML.

Robson (2002, p. 273) argue lhal an inlerviev under lhirly minules does nol give
loo much vaIue. An inlerviev above sixly minules is inappropriale due lo lhe
lime consuming aspecls for lhe inlervievee. Il can aIso decrease lhe viIIingness
of lhe sub|ecls lo parlicipale (Robson, 2002, p. 273). Robson (2002, p. 273) aIso
beIieve lhal lhis may Iead lo biases in lhe oulcome of lhe inlerviev. Due lo lhe
facl lhal lhe inlerviev is a Iong process and lhal ve required lhe inlervievees lo
perform a design sludy in advance, ve vere forced lo decrease lhe amounl of
vork Ioad on lhem. A seIeclion of one use-case for lhe inlerviev vas necessary.
The seIecled use-case in lurn vas seIecled as lo be as smaII and uncompIicaled as
possibIe. We lhink, hovever, lhal lhis use-case refIecls lhe syslem as a vhoIe and
can provide a measure for lhe vhoIe e-commerce syslem.

Tvo of lhe inlervievees had cerlain previous knovIedge aboul lhe syslem in
maller. This couId have affecled lhe queslions aboul lhe funclionaIily of lhe
syslem.

We noliced a differenl IeveI of preparalion among lhe parlicipanls. Those vho
did nol do lhe design sludy in advance or nol enough preparalion in lhe design
sludy vere eager lo do more guessing lhan lhe olhers and il look Ionger lime for
lhem lo reason and ansver lhe queslions. This does nol necessary mean a
negalive impacl on lhe resuIl on aII aspecls. Il mighl have had a negalive impacl
on lhe abiIily lo lrace and verify requiremenls and use-cases. On lhe olher hand,
Iess preparalion provided a more honesl expIanalion of lhe funclionaIily.

The finaI phase in lhe case-sludy, lhe redesign of lhe e-commerce syslem, couId
have been done differenlIy if more lime had been avaiIabIe for us. An aIlernalive
couId have been lo compare aII four vays of modeIIing, UML, WAI-UML,
W2000 and WebML. Since designing a soflvare syslem lakes a Iong lime, and ve
did nol have sufficienl lime lo redesign lhe e-commerce syslem lhree limes, ve
choose one aIlernalive onIy. The reason is aIso lhal making lhree designs of lhe
same syslem vouId have improved our underslanding of lhe design during lhe
second and Iasl design. These designs vouId have been beller lhen regarding
requiremenls and use-case lraceabiIily and verificalion. We lhink lhal by

41
evaIualing lhe differenl melhods by examine lhe documenlalion aboul lhem ve
have chosen lhe mosl appropriale melhod for improving lhe UML design.

Working in lhe form of a case-sludy provides vays for lhoroughIy examine lhe
probIem area and discover melhods for soIving il. In lhis vay ve couId probe
lhe fieId of Web appIicalion modeIIing. We found lhe appropriale vay of ending
lhe case-sludy fIov by presenling lhe redesigned version of lhe e-commerce
syslem in lhe form of lhe resuIling WAI-UML diagrams.

The evaIualion couId have been slriclIy reduced lo lhe inlervievs and
verificalion and vaIidalion of requiremenls and use-cases. Hovever, lo perform a
sorl of experience-based evaIualion provided us vilh addilionaI informalion.
This informalion vas in many aspecls confirmed by lhe informanls in lhe
inlervievs.

6.7 Summur of the dlscusslon
Wilh WAI-UML ve can improve lhe quaIily allribules of lhe designs vhen
deveIoping Web appIicalions. In lhe discussion of lhe sludied case resuIl ve
have repealedIy relurned lo lvo consislenl aspecls. The resuIl is dependenl on
lvo variabIes, nameIy lhe IeveI of delaiI in lhe diagrams as chosen by lhe
designer and lhe readers underslanding and knovIedge of lhe semanlics. We
lhink lhal lhese lvo aspecls are a cruciaI parl of peopIe invoIved in any
appIicalion design process and impIemenlalion. Designing Web appIicalions
vilh WAI-UML can improve lhe overaII design in lhe aspecls of condilion,
communicalion and mainlainabiIily depending on lhese lvo imporlanl variabIes.

7 Cnnc!usinn
WAI-UML is by no means compIeleIy error free in ils semanlics. We have found
some semanlic inconsislencies in lhe specificalion lhal can be improved and
provide for fulure research. One of lhe inlervievees aIso agreed on lhis and came
up vilh suggeslions of improving WAI-UML. We can for exampIe inlroduce
severaI more slereolypes lhal can improve lhe underslanding of lhe design. This
vouId make il easier lo modeI any lype of Web appIicalion regardIess of lhe
chosen lechnoIogy. There is aIso need for CASI looIs lhal can generale code
depending on lhe programming melhod used. RalionaI Rose provides us vilh
lhe looIs for designing appIicalions using lhe WAI-UML bul lhe version
(RalionaI Rose Inlerprise Idilion, ReIease Version 2002.05.20) lhal ve used is nol

42
capabIe of generaling any code. Laler versions mighl incorporale lhis
funclionaIily. During lhe praclicaI vork ve aIso found improvemenls needed in
lhe semanlics in regard lo lhe .NIT archileclure: opposile from hov ConaIIen
(2002) uses il. Correcl and improved semanlics is an imporlanl aspecl lo Iook al
for lhe deveIopmenl of CASI looIs.

The melhods ve invesligaled, W2000, WebML and WAI-UML, aII approach
Web appIicalion modeIIing and ve lake no slance al lo vhal exlenl lhey are
suilabIe. They provide good and Iess good looIs and can be used for modeIIing a
variely of Web appIicalions. We couId incorporale a melhod such as WebML,
vhich provides means for personaIizalion and conlenl managemenl, inlo lhe
User Ixperience modeIIing vilh WAI-UML. In lhis vay ve can deveIop a more
compIele melhodoIogy and a lolaI concepl for Web appIicalion modeIIing. Whal
WAI-UML Iacks is lhe possibiIily for personaIizalion and a beller vay of conlenl
managemenl modeIIing. A compIele melhod for Web appIicalion modeIIing,
according lo us, incorporales improved WAI-UML semanlics and an exlended
User Ixperience modeIIing, perhaps vilh lhe heIp of WebML. In addilion, a
CASI looI musl be deveIoped for generaling code aulomalicaIIy.

In fulure research il vouId aIso be inleresling, and imporlanl, lo measure al lo
vhal exlenl modeIIing vilh WAI-UML, and modeIIing Web appIicalions al aII,
provides lhe pro|ecl leam vilh decreased deveIopmenl cosls. The mosl
inleresling aspecls are lo measure lhe number of requiremenls and use-cases lhal
are verified in lhe finished producl before syslem lesling. ConsequenlIy, il is
needed lo measure lhe amounl of lime spenl correcling inconsislencies and
errors in lhe finaI impIemenlalion during syslem lesling. This in opposile lo an
appIicalion deveIoped vilh specificalions and lexl documenls.

A lhird aspecl is lo measure hov lhe knovIedge of semanlics among lhe peopIe
invoIved in a Web appIicalion pro|ecl infIuences lhe finished producl. The IeveI
of delaiI in lhe design documenls is aIso imporlanl here as lhe abiIily lo provide
delaiI in a design is direclIy dependenl on lhe semanlic knovIedge. This refIecls
bolh lhe underslanding of lhe design arlefacls and lhe abiIily lo perform updales
lo lhem.

43
8 RcIcrcnccs
aresi, Luciano, Garzollo, Iranca & IaoIini, IaoIo (2001). |xicn!ing UMI jcr
Mc!c|ing Wc| App|icaiicns. IournaI: Iroceedings of lhe 34lh AnnuaI Havaii
InlernalionaI Conference on year: 2001. Iages: 1285-1294. IubIished by IIII.

englsson, Lars (2004). Aii ar|cia nc! casc. MaIm: Liber Ikonomi. 91-47-04573-6.

iddIe, Roberl, NobIe, Iames & Tempero, Ivan (2002). Tcuar!s |ta|uaiicn cj
O|jcci-Oricnic! Ocsigns. |vvv]. Accessed from SchooI of MalhemalicaI and
Compuling Sciences, Vicloria Universily,
hllp://vvv.mcs.vuv.ac.nz/comp/IubIicalions/archive/CS-TR-02/CS-TR-02-
8.pdf. Accessed March 14, 2005.

osch, Ian (2000). Ocsign an! usc cj Scjiuarc Arcniicciurcs A!cpiing an! ctc|ting a
prc!uci |inc apprcacn. HarIov: Addison-WesIey. ISN: 0-201-67494-7.

Ceri, Slefano, IralerneIIi, Iiero & ongio, AIdo (2000). Wc| Mc!c|ing Ianguagc
(Wc|MI). a nc!c|ing |anguagc jcr !csigning Wc| siics. IournaI: Compuler
Nelvorks, VoI: 33, issue: 1-6, pages: 137-157. IubIished by Iroquesl.

ConaIIen, Iim (1998). Mc!c|ing Wc| App|icaiicn Ocsign uiin UMI. |vvv].
Accessed from hllp://vvv.ilmveb.com/essay546.hlm. Accessed Iebruary 6,
2005.

ConaIIen, Iim (1999). UMI |xicnsicn jcr Wc| App|icaiicns 0.91. |vvv]. Accessed
from
hllp://vvv.conaIIen.com/lechnoIogyCorner/vebexlension/WebIxlension091.hl
m. Accessed Iebruary 6, 2005.

ConaIIen, Iim (2002). Bui|!ing Wc| App|icaiicns uiin UMI Scccn! |!iiicn. oslon:
Addison-WesIey, 2nd edilion. 0-201-73038-3.

IIy, Margol, el. aI. (1993). Kta|iiaiit jcrskningsncic!ik i prakiikcn cirk|ar incn
cirk|ar. Lund: SludenlIilleralur. 91-44-37111-X.

Ireedman, DanieI & Weinberg, GeraId (1990). Han!|cck cj Wa|kinrcugns.
|nspcciicns an! Tccnnica| |cticus |ta|uaiing Prcgrans. Prcjccis an! Prc!ucis.
oslon: Dorsel House. 3
rd
edilion. 0-932633-19-6.

44

IIII Compuler Sociely (1998). |||| Sian!ar! jcr Scjiuarc Vcrijicaiicn an!
Va|i!aiicn. IournaI: IIII Sld., 1012-1998. IubIished by IIII.

Iacobson, Ivar, ooch, Grady & Rumbaugh, Iames (1998). Tnc Unijic! Mc!c|ing
Ianguagc |cjcrcncc Manua|. Reading: Addison-WesIey. 1sl edilion. 0-201-30998-X.

Larman, Craig (2001). App|uing UMI an! Paiicrns. An |nirc!uciicn ic O|jcci-
Oricnic! Ana|usis an! Ocsign an! inc Unijic! Prcccss. Upper SaddIe River: Irenlice
HaII. 0-13-092569-1.

MarleIIa, RonaId, NeIson, RonaId & Marchand-MarleIIa, Nancy (2003). |cscarcn
Mcinc!s Icarning ic |cccnc a criiica| rcscarcn ccnsuncr. Needham Heighls: AIIyn
& acon. 0-205-27125-1.

OMG, Ob|ecl Managemenl Group (2001). OMG Unijic! Mc!c|ing Ianguagc
Spccijicaiicn. |vvv]. Accessed from
hllp://vvv.omg.org/lechnoIogy/documenls/formaI/umI.hlm. Accessed al
Iebruary 8, 2005.

Robson, CoIin (2002). |ca| ucr|! rcscarcn. a rcscurcc jcr sccia| scicniisis an!
praciiiicncr-rcscarcncrs. Oxford: IackveII pubIishing. 2nd edilion. 0-631-21305-8.

SommerviIIe, Ian (2001). Scjiuarc |nginccring. Issex: Addison WesIey. 6
lh
edilion.
0-201-39815-X.

Slaron, MirosIav (2003). Cusicnizing UMI uiin Sicrcciupcs. KarIskrona: Iekinge
Inslilule of TechnoIogy. 91-7295-028-5. Masler lhesis.

Slrand, Lolla (2003). UMI c |UP Aii |uckas nc! OO-prcjcki. Sundbyberg:
Docendo. 91-7882-587-3.

Svedish Research CounciI (2002). |crskningsciiska principcr incn nunanisiisk-
sanna||stcicnskap|ig jcrskning. |vvv]. Accessed from
hllp://vvv.vr.se/pubIikalioner/sida.|sp`resourceId12. Accessed ApriI 11, 2005.

Trung Thanh Dinh Trong (2003). A Susicnaiic Prccc!urc jcr Tcsiing UMI Ocsigns.
|vvv]. Accessed from
hllp://vvv.cs.coIoslale.edu/-ghosh/papers/issre2003lrung.pdf. Accessed March
17, 2005.

45

9 Appcndix nnc Usc-cascs
9.1 Place order
Aclors: Cuslomer
GoaI: To pIace an order using lhe e-commerce syslem.
Name: IIace order
9.1.1 F!nw nI Evcnts
Basic F!nw
1. The cuslomer cIicks on lhe IIace order menu ilem.
2. The cuslomer enlers lhe arlicIe number.
3. The syslem dispIays lhe name and price of lhe arlicIe.
4. The cuslomer enlers lhe quanlily.
5. The syslem dispIays lhe sum of lhe arlicIes.
6. The cuslomer chooses a deIivery dale for lhe arlicIe.
7. The cuslomer presses lhe Ok bullon.
8. The syslem adds lhe order rov lo lhe order labIe beIov lhe inpul fieIds.
9. The cuslomer repeals lhe sleps 2-8 for aII lhe arlicIes he vanls.
10. The cuslomer cIicks on lhe Confirm order menu ilem.
11. The syslem dispIays lhe order labIe lo lhe cuslomer.
12. The cuslomer enlers his passvord and presses lhe Confirm bullon.
13. The syslem updales lhe dalabase labIes vilh lhe nev order.
14. The syslem sends lhe order lo XAL.
15. The syslem dispIays lo lhe cuslomer lhal lhe order is senl.

A!tcrnativc F!nws
9.1 The cuslomer cIicks on lhe Idil Iink lhal corresponds lo lhe arlicIe he
added in lhe order labIe.
9.2 The syslem deIeles lhe order rov from lhe order labIe and dispIays lhe vaIues
of il in lhe inpul fieIds for a nev order rov.
9.3 The cuslomer enlers nev vaIues for lhe arlicIe number, quanlily or deIivery
dale.
9.4 The cuslomer cIicks on lhe Ok bullon.

10.1 The cuslomer enlers lhe vrong passvord.
10.2 The cuslomer cIicks on lhe Confirm bullon.
10.3 The syslem dispIays a diaIog box saying lhal lhe passvord vas incorrecl.

46
9.1.2 Prc-cnnditinns
The cuslomer musl be Iogged in lo lhe e-commerce vebsile.
9.1.3 Pnst-cnnditinns
An order lhal conlains lhe arlicIes chosen by lhe cuslomer is senl lo lhe cuslomer
adminislralion. The order labIe is cIeared and if lhe cuslomer cIicks on lhe IIace
order menu ilem a nev order is slarled.


9.2 ArtlcIe seurch
Aclors: Cuslomer
GoaI: To find an arlicIe and add il lo an order.
Name: ArlicIe search
9.2.1 F!nw nI Evcnts
Basic F!nw
1. The cuslomer cIicks on lhe ArlicIe search menu ilem.
2. The syslem dispIays lhe ArlicIe search viev.
3. The cuslomer chooses lo search for an arlicIe number.
4. The cuslomer enlers a parl of or lhe vhoIe arlicIe number in lhe search
fieId.
5. The cuslomer cIicks on lhe Search bullon.
6. The syslem searches lhe dalabase for arlicIes lhal malch lhe arlicIe
number enlered by lhe cuslomer.
7. The syslem dispIays lhe search resuIl beIov lhe search fieId.
8. The cuslomer enlers lhe amounl of an ilem lhal is dispIayed by lhe search.
9. The cuslomer cIicks on lhe + bullon nexl lo lhe arlicIe found.
10. The syslem adds lhe arlicIe lo lhe order.
11. The cuslomer cIicks on lhe IIace order menu ilem.
12. The arlicIe lhe cuslomer searched for is dispIayed in lhe order labIe.

A!tcrnativc F!nws
3.1 The cuslomer chooses lo search for an arlicIe name.
3.2 The cuslomer enlers lhe name of lhe arlicIe or parl of lhe arlicIe name.
3.3 The syslem searches lhe dalabase for arlicIes lhal malch or slarls vilh lhe
name enlered by lhe cuslomer.
3.4 NormaI fIov 7.

47
9.2.2 Prc-cnnditinns
The cuslomer musl be Iogged in lo lhe e-commerce vebsile.
9.2.3 Pnst-cnnditinns
The searched for arlicIe is dispIayed in lhe order labIe and is presenl in lhe
dalabase.

10 Appcndix twn - Rcquircmcnts
10.1 PIuce order
10.1.1 Ordcr rnws
The cuslomer shouId be abIe lo add and deIele order rovs lo lhe order.
10.1.2 Crcdit !imit
The cuslomer shouId be nolified if he exceeds his credil Iimil vhen adding
arlicIes lo lhe order. A message shouId suggesl lhe cuslomer lo conlacl lhe
cuslomer service.
10.1.3 Ordcr rnw cnntcnt
The order rov shouId conlain arlicIe number fieId, quanlily, slalus, deIivery
dale, designalion, price, and rov sum.
10.1.4 Ordcr rnw cnntcnt Ii!!cd in by thc custnmcr
The arlicIe fieId and quanlily fieId is fiIIed in by lhe cuslomer. The deIivery dale
shouId be lhe defauIl deIivery dale from lhe order head viev. The cuslomer can
change lhe dale for every arlicIe. The remaining fieIds are generaled from lhe
dalabase and shouId nol be edilabIe by lhe cuslomer.
10.1.5 Changc nrdcr rnws
Ior each rov in lhe order labIe lhere shouId be a hyperIink vhere upon lhe user
cIicks he can edil lhe specific order rov.
10.1.6 Attach a mcssagc tn thc nrdcr rnw
The cuslomer musl be abIe lo allach a message lo each order rov in lhe order
labIe.

48
10.1.7 Navigating in thc p!acc nrdcr vicw
The cuslomer shouId be abIe lo navigale lhe differenl fieIds in an order rov by
pressing lhe lab-key and he shouId confirm lhe order rov by pressing lhe enler
key.
10.1.8 Dc!cting nrdcr rnws
Il musl be possibIe for lhe cuslomer lo deIele order rovs lhal has been added lo
an order.

10.2 Conflrm order
10.2.1 5cnd nntc a!nng with thc nrdcr
The cuslomer shouId be abIe lo allach a message for lhe cuslomer service vhen
sending an order.
10.2.2 CnnIirming scnt nrdcr
The e-commerce syslem shouId nolify lhe cuslomer lhal lhe order vas senl lo lhe
cuslomer service afler lhe cuslomer has senl lhe order. He shouId come lo a nev
viev on lhe e-commerce sile lhal says lhe order has been senl lo lhe cuslomer
service.
10.2.3 CnnIirm nrdcrs with passwnrds
To confirm an order lhe cuslomer musl enler his passvord.
10.2.4 5cnding nrdcr
The order shouId be senl lo a map in lhe business syslem reposilory as a lexl fiIe
and handIed manuaIIy by lhe cuslomer service. This means lhal vhen pIacing an
order lhe SOL server and e-commerce syslem are nol direclIy communicaling
vilh lhe business syslem XAL.
10.2.5 Pricc disp!ay
On lhe confirm order viev lhe VAT, price excIusive VAT and lhe users discounl
shouId be presenled.
10.2.6 Crcdit !imit
AII cuslomers using lhe e-commerce syslem have a credil Iimil and lhey shouId
nol be abIe lo confirm an order lhal exceeds lhe Iimil.


49
10.3 ArtlcIe seurch
10.3.1 5carch Inr artic!cs using artic!c numbcr
The cuslomer musl be abIe lo search for arlicIes using lhe arlicIe number. The
search shouId be performed as fronl-end search. This means lhal if lhe cuslomer
enlers a 123 in lhe search fieId aII arlicIes lhal slarls vilh lhe sequence 123
shouId be found.
10.3.2 5carch Inr artic!cs using thc artic!c namc
The cuslomers of lhe e-commerce sile musl be abIe lo search for an arlicIe using
lhe name or parl of lhe name for an arlicIe.
10.3.3 Ordcr artic!cs Irnm thc artic!c scarch
The cuslomer musl be abIe lo pIace lhe arlicIes he searched for in order rovs in
lhe currenl order he has slarled. If he has nol yel slarled lo pIace an order il
shouId nol be possibIe lo pul lhe arlicIes in any order.
10.3.4 NntiIicatinn nI artic!cs addcd tn thc nrdcr
The cuslomer shouId be nolified vilh a diaIog box vhen an arlicIe is added lo
lhe order.

11 Appcndix thrcc UML and WAE-UML dcsigns
The diagrams in lhis appendix, bolh from lhe oId design and lhe redesign,
conslilule lhe imporlanl diagrams onIy. Wilh imporlanl ve mean lhe finaI
design documenls, cIass diagrams, coIIaboralion- and sequence diagrams, and in
lhe case of lhe redesigned version a UX navigalionaI map.


50
11.1 OId e-commerce deslgn - UML
11.1.1 UML navigatinn map


Order
Login
password : TextBox
userId : TextBox
Frontpage
Confirm
Search History
Help
OrderHead
Success
ODisplay
WDisplay
IDisplay

51
11.1.2 UML c!ass diagram P!acc Ordcr
Confi rm
Frontpage
Help
OrderHead Hi story
OrderInfo
(f rom Logic)
CustomerInfo
(f rom Logic)
Order
0..1
1
0..1
1
uses
0..1
1
0..1
1
uses
Button
(f rom Sy stem.Web.UI.WebControls)
2
1
2
1
has
TextBox
(f rom Sy stem.Web.UI.WebControls)
7
1
7
1
has
HttpSessi onState
l anguage : string
userId : string
currentOrder : string
l ock : bool
choice : stri ng
searchWord : stri ng
(f rom Sy stem.Web.SessionState)
1 1 1 1
uses
Search


11.1.3 UML c!ass diagram Artic!c scarch
History Frontpage Help Order Conf irm
RadioButtonList
(fromSystem.Web.UI.WebControls)
RadioButton
(fromSystem.Web.UI.WebControls)
Button
(fromSystem.Web.UI.WebControls)
TextBox
(fromSystem.Web.UI.WebControls)
HttpSessionState
language : string
userId : string
currentOrder : string
lock : bool
choice : string
searchWord : string
(from System.Web.SessionState)
Search
SearchArticlesBy Number(nr : string, country Code : string) : DataSet
SearchArticlesBy Name(name : string, country Code : string) : DataSet
(fromLogic)
Search
1
1
1
1
has
2
1
2
1
has
1..n
1
1..n
1
has
1..n 1 1..n 1
has
1
1
1
1
uses
0..1 1 0..1 1
uses



52
11.1.4 UML c!ass diagram Crcatc nrdcr
RadioButton
(from System.Web.UI.WebControls)
RadioButtonList
(from System.Web.UI.WebControls)
Label
(from System.Web.UI.WebControls)
Button
(from System.Web.UI.WebControls)
TextBox
(from System.Web.UI.WebControls)
HttpResponse
(from System.Web)
Order
redirects to
OrderHead
2
1
2
1
has
1
1
1
1
has
1..*
1
1..*
1
has
1
1
1
1
has
1
1
1
1
has
uses
CustomerInf o
(from Logic)
1
11
1


11.1.5 UML c!ass diagram CnnIirm nrdcr
Success
Search
Frontpage Help
TextBox
(from System.Web.UI.WebControls)
Button
(from System.Web.UI.WebControls)
HttpSessi onState
language : string
userId : string
currentOrder : stri ng
lock : bool
choice : stri ng
searchWord : stri ng
(from System.Web.SessionState)
History
Order
ConfirmInfo
(from Logic)
OrderInfo
(from Logic)
Confirm
1
1
1
1
has
1
1
1
1
has
1
1
1
1
uses
0..1
1
0..1
1
uses
1
1
CustomerInfo
(from Logic)
1
1
1
1
uses
1
1
uses



53
11.1.6 UML c!ass diagram Lngic packagc
Search
SearchArti cl esByNumber(nr : stri ng, countryCode : stri ng) : DataSet
SearchArti cl esByName(name : stri ng, countryCode : stri ng) : DataSet
GetWebOrder(i OrderNr : i nt) : DataSet
AddItem(strSQL2 : stri ng, strSQL3 : stri ng) : bool
News
GetNews(counryCode : stri ng) : DataSet
OrderInfo
create()
Del eteOrder(userId : stri ng, cOrder : i nt) : i nt
SetOrderMessage(userId : stri ng, cOrder : i nt, orderMessage : stri ng) : bool
GetArti cl eStatus(artNo : stri ng, countryCode : stri ng) : stri ng[]
GetOrderMessage(userId : stri ng, cOrder : stri ng) : DataSet
Del eteOrderRow(userId : stri ng, orderRowId : i nt) : i nt
AddOrderRow(wantDel Date : stri ng, cOrder : i nt, userId : stri ng, l angCode : stri ng, artNr : stri ng, quanti ty : i nt, pri ce : doubl e, stockStatus : stri ng, orderMessage : stri ng) : i nt
GetArti cl e(artNr : stri ng, countryCode : stri ng) : DataSet
CheckOverdue(pri ce : stri ng, userId : stri ng) : bool
GetOrderTabl es(userId : stri ng, cOrder : i nt) : DataSet
GetOrderNumber(userId : stri ng) : i nt
Confi rmInfo
oi : OrderInfo
ci : CustomerInfo
create()
Val i dPass(userId : stri ng, password : stri ng) : i nt
SendOrder(userId : stri ng, cOrder : i nt) : stri ng
QueryCOM
m_ds : DataSet
m_trans : Sql Transacti on
m_Path : string
m_cnCatal oge : Sql Connect i on
Cl assId : st ri ng
InterfaceId : string
EventsI d : stri ng
create()
ReadPath()
Open()
GetDataSet()
SendQuery()
StartTransact i on()
Roll back()
Execut ePartTransaction()
Cl ose()
(f rom COM)
0..1 1 0..1 1
sends query
0..1
1
0..1
1
queri es
0..1
1
0..1
1
queri es
CharacterControl
create()
Val i dateStri ng(str : stri ng) : bool
AddCharIfFound(ch : stri ng, str : stri ng) : bool
1
1
1
1
val i dates stri ngs
1
1
1
1
val i dates stri ngs
CustomerInfo
Create()
Logi n(ui d, pw) : stri ng[]
GetDi spl ayabl eWebOrdertabl e(orderNo : i nt) : DataSet
GetDi spl ayabl eInvoi ceTabl e(i nvoi ceNo : i nt) : DataSet
GetDi spl ayabl eInvoi ce(i nvoi ceNo : i nt) : DataSet
GetDi sl pl ayabl eOrderTabl e(orderNo : i nt) : DataSet
GetInvoi ceAddress(userId : stri ng) : DataSet
GetDi spl ayabl eOrderHead(orderNo : i nt) : DataSet
GetDi spl ayabl eWebOrderHead(userId : stri ng, cOrder : i nt) : DataSet
Anal yze(ds : DataSet, ui d : stri ng, pw : stri ng) : stri ng[]
SetNewAddress(addressNr : i nt, ui d : stri ng, cOrder : i nt) : i nt
GetAdressIDFromNr(nr : i nt, ui d : stri ng) : i nt
GetAddressId(ui d : stri ng, cOrder : i nt) : i nt
SetAddressTwo(userId : stri ng, addr1 : stri ng, addr2 : stri ng, pNr : stri ng, ci ty : stri ng, country : stri ng) : i nt
CreateNewOrder(addressNr : i nt, orderDate : stri ng, ui d : stri ng) : i nt
GetOrderNumber(userId : stri ng) : i nt
CreateNewOrderHead(addressNr : i nt, orderDate : stri ng, ui d : stri ng, cOrder : i nt) : i nt
GetOrderHead(userId : stri ng) : DataSet
GetOrderHead(userId : stri ng, cOrder : i nt) : DataSet
Val i dPass(userId : stri ng, pw : stri ng) : bool
GetInvoi ceNumbers(userId : stri ng) : DataSet
GetWebOrderNumbers(userId : stri ng) : DataSet
GetOrderNumbers(userId : stri ng) : DataSet
0..1
1
0..1
1
queri es
1
1
1
1
val i dates stri ngs
Log
Wri teMessageLogi n(ui d : stri ng, pwd : stri ng, err : stri ng)
Wri teMessageRepl i cati on(s : stri ng)
1
0..1
1
0..1
l ogs user



54
11.1.7 UML cn!!abnratinn diagram Artic!c scarch
: Arti cl eSearch
: Search
: QueryCom
1 OnSubmi t()
1.8 ds=SendQuery(SQL):DataSet
1.9 Cl ose()
: HttpSessionStat e
: Ht tpResponse
Post back
1.4 searchWord=Sessi on["search"]
1.2 Sessi on["searchT ype"] =choi ce
1.10 Di spl ayResult()
1.5 choi ce=Sessi on["searchType"]
1.6a [searchWord!=nul l && choi ce="name"]ds=SearchArti cl eByName(searchWord)
1.11 SetOl dSearch()
Di spl ays the search
word and choi ce.
1.6b [searchWord!=nul l && choi ce="number"]ds=SearchArti cl eByNumber(searchWord)
1.1 Sessi on["search"]=searchWord
1.3 Redi rect(Arti cl eSearch)
SearchArti cl e()
1.7 Open()


11.1.8 UML cn!!abnratinn diagram Crcatc ncw nrdcr
: Pl aceOrder
: OrderHead
: HttpSessi onState
: CustomerInfo
: QueryCom
1.4, 2.2, 3.3 ds=SendQuery(SQL):DataSet
1.5, 2.3, 3.4 Cl ose()
2.1 orderNr=CreateNewOrderHead(addressNr, orderDate, userId):i nt
Operati ons performed for each
query that i s sent to the
database.
: OrderInfo
2 Confi rm_On_Cli ck()
3.1 userId=Sessi on["userId"]
3.7 ds=SendQuery(SQl):DataSet
3.8 Cl ose()
1.1 [cOrder=nul l]Redi rect(OrderHead)
2.5 Redi rect(Pl aceOrder)
1. cOrder=Sessi on["currentOrder"]
3 cOrder=Session["currentOrder"]
3.2 ds=GetCurrentOrderHead(userId, cOrder): DataSet
3.5 ds=GetOrdertabl es(userId, cOrder):DataSet
1.2 ds=GetOrderHead(useri d):Dataset
2.4 Sessi on["currentOrder"] = orderNr
StartOrder()
1.3, 2.1, 3.3 Open()
3.6 Open()



55
11.1.9 UML cn!!abnratinn diagram P!acc nrdcr
: Pl aceOrder : OrderI nfo
Pl aceOrder i s performed af ter
Creat eNewOrder di agram. T he order head
and table are loaded from the database.
: HttpSessi onState
1.1 cOrder=Sessi on["currentOrder"]
1.2 OnDeSelect()
The user enters the
arti cl e number and tabs
away from the textbox.
: QueryCom
1.5 ds=SendQuery(SQL):DataSet
1.6 Cl ose()
1.7 UpdateRow(ds)
The i nfo for the arti cl e
i s fi l l ed i nto the
textboxes.
2 Confi rmRow()
The user
confi rms the
order row.
: HttpResponse
Pl aceOrder vi ew i s
posted back.
2.3 ds=SendQuery(SQL):DataSet
2.4 Cl ose()
2.2 Open()
1.3 ds=GetArti cl e(artNr):DataSet
2.1 ds=AddOrderRow(rowData, cOrder, userId):Dat aSet
1 userId=Sessi on["userId"]
2.5 Redi rect(Pl aceOrder)
Pl aceOrder()
1.4 Open()



56
11.1.10 UML cn!!abnratinn diagram CnnIirm nrdcr
: Confi rmOrder : Confi rmInfo
: QueryCom
: Htt pSessi onState
1: val i d=Val i date(ui d, pw):bool
1.2 [val i d]cOrder=Sessi on["orderNr"]
1.5 SendQuery(SQL):DataSet
1.6 Cl ose()
: HttpResponse
: Confi rmMessage
2.2 SendQuery(SQL):DataSet
2.3 Cl ose()
2.4 SendOrder(orderText: Fi l e)
: CustomerInfo
2 [pwVal i d]res=SendOrder(userId, cOrder):stri ng
1.1 [val i d]userId=Sessi on["userId"]
2.5 Sessi on["confMess"] = res
2.6 [res]Redi rect(Comfi rmMessage)
1.3 pwVal i d=Val i dPass(userId, pw):bool
2.1 Open()
Confi rmOrder()
2.7 Create()
1.4 Open()



57
11.2 L-commerce redeslgn ulth WAL-UML
11.2.1 WAE-UML uscr Expcricncc Navigatinna! map
CreateOrder
Login
SearchForm
SearchItem AddItemForm
Error no order created
CreateForm
wrong date format
LoginForm
Wrong password/user
ProductCat
ArticleSearch $ +
Next
Prev
Search article
0..1 0..1
Add to cart
DeleteRow
EditRow
FrontPage $
Navigate
OrderRow
DeleteOrder
Confirm
orderMessage
OrderRowForm
OrderHead
OrderHeadForm
Wrong date format
PlaceOrder
<<link>>
0..* 0..*
Cancel
ConfirmOrder
<<link>>
Confirm
wrong password
Confirmation
OK



58
11.2.2 WAE-UML c!ass diagram Artic!c scarch
SearchCatalog
searchBy No()
searchBy Name()
(fromCatalog)
OrderController
addItemToOrder()
delItemFromOrder()
deleteOrder()
startNewOrder()
getOrderNo()
sendOrder()
getOrderHead()
getOrderTable()
getCustomerDetails()
(fromOrder)
SearchResult
of f set : int
itemNo : int
SearchResult()
setOf f set()
getOf f set()
buildNext()
buildPrev ()
buildCurrent()
(fromCatalog)
ArticleSearch.cs
search()
nextResultSet()
selectItem()
setLanguage()
addItem()
setOldSearch()
buildDialogError()
buildDialogAdded()
OrderController
addItemToOrder()
delItemFromOrder()
deleteOrder()
startNewOrder()
getOrderNo()
sendOrder()
getOrderHead()
getOrderTable()
getCustomerDetails()
(fromOrder)
OrderHead.cs
createOrder()
setLanguage()
OrderHead.html
v alidDate()
CreateForm
delDate : TextBox
delAddr[] : RadioButton
OrderHeadForm
delDate : TextBox
delAddr[] : RadioButton
SearchItem
articleNumber : String
name : String
price : String
status : String
SearchForm
searchInput : TextBox
searchChoice[] : RadioButton
AddItem
qty : TextBox
OrderHead.aspx <<build>>
<<submit>>
<<submit>>
ArticleSearch.aspx
<<submit>>
<<redirect>>
<<submit>>
<<redirect>>
ArticleSearch.html
v alidAmount : int = 50000
v alidSum()
0..* 0..*
<<build>>
<<link>>



59
11.2.3 WAE-UML c!ass diagram P!acc nrdcr
<<l ink>>
FrontPage.cs
SearchCatal og
searchByNo()
searchByName()
(fromCatalog)
Pl aceOrder.cs
submitArtNo()
bui ldDi al ogError()
submitQty()
addItem()
del eteItem()
changeMessage()
edi tArti cl e()
Confi rmOrder.cs
sendOrder()
OrderControl ler
addItemToOrder()
del ItemFromOrder()
del eteOrder()
startNewOrder()
getOrderNo()
sendOrder()
getOrderHead()
getOrderTable()
getCustomerDetail s()
(fromOrder)
Confi rmati o
n.cs
FrontPage.html
Del eteRow
del ete : submi t
Edi tRow
edi t : submi t
FrontPage.aspx
<<bui ld>>
OrderRow
i d : i nt
artNo : stri ng
del Date : stri ng
status : stri ng
name : stri ng
pri ce : fl oat
rowSum : fl oat
OrderRowForm
artNo : TextBox
qty : TextBox
del Date : TextBox
status : TextBox
name : TextBox
pri ce : TextBox
sum : TextBox
Del eteOrder
del ete : submi t
OrderMessage
message : textBox
Pl aceOrder.aspx
<<submit>>
<<submi t>>
<<submit>>
<<redirect>>
Confi rmati on.htm
l
Confi rmOrder.ht
ml
Pl aceOrder.html
val idAmount : int = 50000
val idSum()
del eteItem()
updateRowSum()
<<bui ld>>
Confi rm
Cnformati on.asp
x
<<bui ld>>
Confi rmOrder.as
px
<<bui ld>>
<<submit>>
<<redirect>>



60
11.2.4 WAE-UML c!ass diagram Lngic packagc
HttpSessionState
userId : string
language : string
currentOrder : string
lock : bool
(from System.Web.Sessi onState)
SearchCatalog
searchByNo()
searchByName()
(from Catal og)
SearchResult
offset : int
itemNo : int
SearchResult()
setOffset()
getOffset()
buildNext()
buildPrev()
buildCurrent()
(from Catal og)
OrderHead
orderNo : String
name : String
email : String
delDate : Date
delAddress : String
create()
(from Order)
OrderController
addItemToOrder()
delItemFromOrder()
deleteOrder()
startNewOrder()
getOrderNo()
sendOrder()
getOrderHead()
getOrderTable()
getCustomerDetails()
(from Order)
Catalog
searchItem()
getItem()
searchItems()
(from Catal og)
Order
addItem()
deleteItem()
sendOrder()
updateOrder()
getOrderHead()
getOrderTable()
getCustomerDetails()
getItem()
createNewOrder()
createOrder()
createTextFile()
addArticle()
(from Order)
1
1
1
1
CustomerDetails
name : String
address1 : String
address2 : String
email : String
password : String
customerNo : String
customerLock : Bool
creditLimit : Int
CustomerDetails()
checkCreditLimit()
getDetails()
customerLock()
checkPassword()
(from Customer)
QueryCom
sendQuery()
(from DBControl l er)


61
11.2.5 WAE-UML scqucncc diagram Artic!c scarch
: Customer
: ArticleSearch.aspx :
ArticleSearch.html
: SearchForm : AddItem
:
ArticleSearch.cs
: Catalog result :
SearchResult
:
OrderController
: QueryCom :
CustomerDetails
: Order
/navigate/
/build/
/enter artNo + submit/
/submit/
search( )
result = searchItems(query=POST[searchInput]:string, choice=POST[searchChoice]:int ):SearchResult
ds=sendQuery(SQL:string):DataSet
result = create(ds, offset:=10, itemNo:=0)
resultSet= buildNext():string[][]
SESSION[result] = result
/build/
setOldSearch(POST[searchInput],POST[searchChoice])
/enter qty + add/
/submit/
addItem() added=addItemOrder(artNo=POST[artNO], qty=POST[qty], SESSION[delDate]):bool
added=addItem(artNo:string, qty:int):bool
/same as Sequence PO Add Article /add article//
/build/
[added=false]buildDialogError()
[added=true]buildDialogAdded()
setOldSearch(POST[searchInput],POST[searchChoice])
result=SESSION[result]
resultSet=buildCurrent( ):string[][]
/browse to next result page/
/browse/
nextResultSet( )
resultSet=buildNext():string[][]
result=SESSION[result]
setOldSearch(POST[searchInput],POST[searchChoice])
offset:=offset+10
itemNo:=itemNo+10
/build/



62
11.2.6 WAE-UML scqucncc diagram Crcatc nrdcr
: Customer
: OrderHead.aspx : OrderHead.html
:
OrderHead.cs
: CreateForm
:
OrderController
: Order : QueryCom :
CustomerDetails
: PlaceOrder.aspx : ArticleSearch.aspx
/nav igate/
/build/
/create new order/
[v alidDate==true]/submit/
v alidDate=v alidDate(delDate):bool
createOrder()
orderNo=startNewOrder( delDate, addressNr):string
orderNo=createNewOrder(delDate, addressNr):string
sendQuery(SQL:string)
details=getCustomerDetails(customerNo):DataSet
details=getDetails(customerNo):DataSet
details=sendQuery(SQL:string):DataSet
createOrder(SESSION[customerNo], delDate, addressNr)
SESSION[currentOrder]=orderNo
[SESSION[ref errer]='PlaceOrder']/redirect/
[SESSION[ref errer]='ArticleSearch']/redirect/
details=getCustomerDetails(customerNo):DataSet
SESSION[def aultDelDate]:=delDate



63
11.2.7 WAE-UML scqucncc diagram Add artic!c
: Customer
: PlaceOrder.aspx : PlaceOrder.html : OrderRowForm
:
PlaceOrder.cs
:
SearchCatalog
: Catalog
: QueryCom :
OrderController : Order
:
CustomerDetails
/navigate/
/build/
/enter article no + TAB/
/submit/
submitArtNo( )
ds = searchByNo( artNo=POST[artNo])
ds = searchItem(artNo)
ds = sendQuery(SQL:string):DataSet
/build/
orderHead=getOrderHead(orderNo=SESSION[currentOrder]):DataSet
orderHead=getOrderHead( orderNo):DataSet
orderHead=sendQuery(SQL:string)
orderTable=getOrderTable(orderNo):DataSet
orderTable=getOrderTable(orderNo):DataSet
orderTable=sendQuery(SQL:string)
/enter quantity and TAB/
updateRowSum(qty:int, price:float)
document.forms.sum=newSum
newSum=qty*price
/add article/
/submit/
addItem( )
added=addItemToOrder( artNo:=POST[artNo], qty:=POST[qty], delDate:=POST[delDate]):bool added=addItem( artNo:string, qty:int, delDate:string):bool
ds=GetCustomerDetails(SESSION[customerNo])
create(ds)
locked=customerLock()
overdue=checkCreditLimit(qty:int, itemDS.price)
itemDS= sendQuery(SQL:string)
itemDS=getItem(artNo)
[locked!=true && overdue != true]addArticle(artNo, qty, status, cDetails)
cDetails[]=getDetails()
[added==false]buildDialogError()
/build/
orderHead=getOrderHead(orderNo=SESSION[currentOrder]):DataSet
orderHead=getOrderHead( orderNo):DataSet
orderHead=sendQuery(SQL:string)
orderTable=getOrderTable(orderNo):DataSet
orderTable=getOrderTable(orderNo):DataSet
orderTable=sendQuery(SQL:string)
ds=sendQuery(SQL:string):DataSet
[added==false]buildLastOrderRowForm()
Builds the last
inputs in the
orderRowForm with
the contents.



64
11.2.8 WAE-UML scqucncc diagram Dc!ctc itcm
: Customer
: PlaceOrder.aspx : PlaceOrder.html : DeleteRow
:
PlaceOrder.cs
:
OrderController
: Order : QueryCom
/delete item id=artId/
[confirmed==true]/submit/
confirmed=confirmDelete(artId):bool
deleteItem()
delItemFromOrder( artId:=POST[artId])
deleteItem( artId)
sendQuery(SQL:string)
orderHead=getOrderHead(orderNo=SESSION[currentOrder]):DataSet
orderHead=getOrderHead( orderNo):DataSet
orderHead=sendQuery(SQL:string)
orderTable=getOrderTable(orderNo):DataSet
orderTable=getOrderTable(orderNo):DataSet
orderTable=sendQuery(SQL:string)
/build/



65
11.2.9 WAE-UML scqucncc diagram CnnIirm nrdcr
: Customer
:
ConfirmOrder.aspx
: ConfirmOrder.html : Confirm
:
ConfirmOrder.cs
:
OrderController
: Order : QueryCom :
CustomerDetails
: Cnformation.aspx : Confirmation.html
/navigate/
orderHead=getOrderHead(orderNo=SESSION[currentOrder]):DataSet
orderHead=getOrderHead( orderNo):DataSet
orderHead=sendQuery(SQL:string):DataSet
orderTable=getOrderTable(orderNo):DataSet
orderTable=getOrderTable(orderNo):DataSet
orderTable=sendQuery(SQL:string):DataSet
/build/
/enter password and submit/
/submit/
sendOrder()
errorMessage=sendOrder( POST[password]):string
errorMessage=sendOrder( POST[password]):string
ds=GetCustomerDetails(SESSION[customerNo])
ds=sendQuery(SQL:string):DataSet
create(ds)
locked=customerLock()
passOk=checkPassword(POST[password]):bool
[!locked && passOk]createTextFile():bool
[errorMessage='OK']/redirect/
[errorMessage!='OK']/build/
lastOrder=SESSION[currentOrder]
SESSION[currentOrder]=null
/build/
(*)Get order head
and order table
before build.
Get order
table and
head. (*)



12 Appcndix Inur WAE-UML nntatinn
These stereotypes and their definitions come from Conallen (2002).

ClientPage

This slereolyped cIass <<cIienl page>>
denoles a cIienl page lhal is rendered
by a veb brovser.

Non-slereolyped allribules in lhis cIass
lypicaIIy defines IavaScripl variabIes
and operalion defines IavaScripl
funclions.

66
ServerPage

The slereolyped cIass <<server page>>
conslilules a server page lhal is
execuled on lhe server side. Il is lhe
IogicaI abslraclion of a Web page as
seen by lhe server.

Allribules and operalions are
archileclure dependenl.
HTMLForm

The cIass <<HTML Iorm>> can onIy
exisl in lhe conlexl of a <<cIienl page>>
and maps direclIy lo lhe <form> HTML
eIemenl.

Allribules map lo chiId eIemenls of lhe
<form> eIemenl and cannol conlain any
operalions.
<<build>>

The slereolype <<buiId>> appIied on an
associalion can slriclIy be used in lhe
conlexl of a server page lhal slreams
HTML oulpul as a cIienl page.
<<submit>>

A <<submil>> slereolyped associalion
is used by lhe HTML Iorm cIass aIIovs
lo submil lo a page cIass. This is
lypicaIIy a server page cIass. Il can
conlain a Iisl of paramelers lhal is
passed aIong lhe requesl.
<<redirect>>

A <<redirecl>> slereolyped associalion
can be used by any page cIass. A
redirecl can occur bolh from a cIienl
page and a server page.
<<link>>

A <<Iink>> slereolyped associalion
poinls from a cIienl page lo anolher
page. Il maps direclIy lo a HTML <a>
lag.



67
13 Appcndix Iivc Origina! mnck-ups
These mock-ups were developed in the initial phases of the original e-commerce Web
application project.
13.1 Mock-u - ArtlcIe seurch


13.2 Mock-u Creute order



68
13.3 Mock-u PIuce order


13.4 Mock-u Conflrm order


69
14 Appcndix six Intcrvicw answcrs
14.1 Ansuers
14.1.1 Gcncra! Qucstinns
1. Have you any experience (vorked vilh) in deveIoping veb appIicalions`

I1: Yes
I2: Cerlain experience Iooking al design diagrams of veb appIicalions. No
programming.
I3: Yes. Wilh .NIT.
I4: Yes, deveIops veb appIicalions as profession.

2. Whal melhods have you been using lo modeIIing veb appIicalions`

I1: Texl, specified requiremenls. Defining ovn veb page designs from lhe
specificalion. Crealing ovn prololypes.
I2: UML, Iines and boxes.
I3: WAI pIus UX
I4: Specificalions, use-cases, requiremenls.

3. Have you been programming using lhe .NIT pIalform`

I1: Yes. Using VisuaIasic och C-.
I2: No.
I3: Yes.
I4: Yes, bul Iike moslIy IHI.

4. Have you been modeIIing appIicalions vilh UML`

I1: Yes.
I2: Yes.
I3: Yes.
I4: Yes.

5. Are you famiIiar vilh slereolypes`

I1: Yes, bul nol vorked vilh il.
I2: Yes.

70
I3: Yes.
I4: Yes, bul can'l reaIIy expIain il.

6. Have you heard lhe lerm WAI (Web AppIicalion Ixlension)`

I1: Yes, heard lhe lerm, nol seen any exampIes.
I2: No.
I3: Yes, used before.
I4: No, nol before inlerviev.

14.1.2 Dcsign qucstinns
UML dcsign
1. Whal do you lhink lhal lhe syslem do and vhal is ils funclionaIily` (Whal
requiremenls do lhey find of lhe reaI requiremenls` ArlicIe search, search by
number and name, add arlicIes and fiII in quanlily).

I1: ArlicIe search, choose lype vilh radio bullons, search, dalabase search,
shoving lhe resuIl of lhe search. Search on number or name. A session variabIe
slores lhe search vord and resuIl.
I2: ArlicIe search of some kind.
I3: Dalabase, vriling in Microsofl, Iogins. If il is a Web sile il Iooks confusing.
I4: Can pIace an order. Log vhal lhe user does, Iog in. Ordering syslem of some
kind.

2. Do you lhink lhal lhe requiremenls are fuIfiIIed by lhe oId design`

Req. 1-2: I1: IuIfiIIed.
I2: IuIfiIIed vilh smaII modificalions.
I3: No, arlicIe number missing.
I4: Have lo Iook very hard and guess a fev lhings. Nol cIear if.

Req. 3: I1: IuIfiIIed.
I2: Nol fuIfiIIed.
I3: Nol Iike lhal (described).
I4: Can'l be lraced in lhe design.


71
Req. 4: I1: Maybe lhrough DispIayResuIl() in 8.4. (Navigales lo anolher
page) ShouId have been more melhods lhal
pIace lhe resuIl.
I2: Nol fuIfiIIed.
I3: Nol shovn, no parameler on ex submil ():
I4: No.

3. WouId you say Iooking al lhe diagrams lhal lhe use-case is fuIfiIIed`

I1: No. Some parls in lhe use-case are nol lraceabIe lo lhe design.
I2: To some exlenl.
I3: The diagrams are nol conslrucled Iike lhey shouId be. No!
I4: More abslracl in lhe coIIaboralion diagram lhan in lhe use-case. More delaiIs
in lhe use-case.

4. Considering lhe oId design diagrams, vilh lhe heIp of lhese diagrams, vouId
you be abIe lo impIemenl lhe arlicIe search use-case` Wilh .NIT` Wilh a
Ianguage of your ovn choice` Which Ianguage`

I1: Maybe nol. ShouId maybe be abIe lo do il considering I vas programming
lhis parl in lhe pro|ecl.
I2: Yes, even lhough lhe diagrams are nol lhal cIear. Has vorked vilh OMT and
lhen you have lo make up a Iol of lhings yourseIf.
I3: Nol from onIy lhe diagrams. I vouId need lo use lhe use-case specificalion.
I4: No, nol as lhe cuslomer vouId vanl il. I vouId have missed a Iol of lhings.

6. Whal happens if you lry lo add an arlicIe lo lhe order bul lhere is no order
crealed`

I1: Can nol be lraceabIe. (No use of v 7.1.5.).
I2: ImpIicilIy presumed an order aIready is crealed. Gels lhe order from a session
ob|ecl (ShouId be lhere aIready). Dos nol leII vhal is happening if an order is nol
exisling.
I3: Nol in lhe diagram.
I4: Cannol leII vhal happens.

7. Hov do you lhink lhe impIemenled syslem performs` Or vhal lhe
performance vouId be Iike from lhis design`


72
I1: Il depends vhal is happening vilh lhe session ob|ecl and if il saves
everylhing in lhe dalabase. Il mighl nol be so robusl. I lhink il viII be lroubIe
vilh session variabIes. Il's easier lo mainlain vilhoul session variabIes.
I2: Lumpy.
I3: Nol so compIicales syslem. Il is hard lo see lhe conneclion belveen use case
and lhe diagram. Nol sIov because il uses onIy one ob|ecl.
I4: No ansver.

WAE-UML dcsign
1. Whal do you lhink lhal lhe syslem do and vhal is ils funclionaIily` (Whal
requiremenls do lhey find of lhe reaI requiremenls` ArlicIe search, search by
number and name, add arlicIes and fiII in quanlily).

I1: Order head, dalabase, gel/add lo dalabase, search/add arlicIe. Il is easy lo
undersland. Il lakes Ionger lime lo find lhings in lhe sequence diagrams. Too
Iarge sequence diagrams vilh loo much delaiI. Iul an ilem lo an order: send
back confirmalion lo lhe cuslomer. ArlicIe search cIass diagram, il can be hard lo
undersland vhal lhe slereolypes means. I vouId need an expIanalion of lhe
slereolypes. Creale order in order head, change dale and address in order head,
search arlicIes, add arlicIes up lo a cerlain amounl in lhe order.
I2: More informalion in lhese diagrams, bul nol lhal cIear lo gel vhal lhe user
does (changed his mind).WeII, il is quile cIear bul harder lo gel lhe fuII piclure
because lhere are more delaiIs.
I3: Aclive veb-pages vhich does inleraclion vilh lhe user and buiIds some
pages, name search of somelhing. Nov you can acluaIIy see lhal il is a Web
appIicalion.
I4: roken dovn inlo pieces. ArlicIe search componenls gIues logelher. The oId
design gives lhe background, lhis one lhe vhoIe piclure.

2. Do you lhink lhal lhe requiremenls are fuIfiIIed by lhe nev design`

1. Req. 1-2:

I1: Yes, can search on names, lhe search melhod is in Iogic.
I2: Yes (Il nov gave informalion lhal you can acluaIIy fiII in lhe quanlily for lhe
Iine ilem.)
I3: Yes.
I4: Yes. Search ilem gives differenl kinds of search possibiIilies, slalus.

73
Connecled lo form.

2. Req. 3:

I1: Yes, addIlem is lhere. Search ilem ob|ecl. Texl box.
I2: Nol fuIfiIIed. (The inlervievee did nol vanl lo Iook al lhe sequence diagram
or lhe cIass diagrams as lhey are nol needed lo his opinion.)
I3: Nol found direclIy. (When poinled oul lhal lhe sequence diagrams are Iinked
he couId find il.)
I4: Yes.

3. Req. 4:

I1: Yes, vhen uiIddiaIogAdded() is lhere, nol sure vhere and hov il is
dispIayed. ArlicIe search sequence more cIear.
I2: Yes.
I3: Maybe, no diaIog box.
I4: Can nol find any nolificalion lo lhe user (diaIog box). (Commenled lhal: The
IeveI of delaiI can give differenl consequences depending on vho il direcls lo.)

3. WouId you say Iooking al lhe diagrams lhal lhe use-case is fuIfiIIed`

I1: Yes.
I2: asic fIov fuIfiIIed. I see lhal il conslrucls lhe page vilh lhe /buiId/
slereolype. Does nol shov vhal il does (lhe slereolype buiId), and vhal + sign
for each rov in lhe use-case is for.
I3: DelaiIed diagrams and hard lo connecl lo abslracl use case specificalion,
guess yes.
I4: Same fIov in lhe diagram and use-case. They describe lhe same lhing.

4. Considering lhe nev design diagrams, vilh lhe heIp of lhese diagrams, vouId
you be abIe lo impIemenl lhe arlicIe search use-case` Wilh .NIT` Wilh a
Ianguage of your ovn choice` Which Ianguage`

I1: Yes I vouId.
I2: WouId generale lhe code vilh a CASI looI and have my grandmolher
impIemenl il easiIy.
I3: Yes, he guesses he couId. DefinileIy.
I4: Yes, bul I vouId have chosen IHI. I can see lhe adaplalion lo IHI inslead.
WouId be abIe lo do il immedialeIy, bul il is hard lo see lhe fIov of lhe user

74
navigalion. Navigalion fIov in lhe NavigalionaI map can make il easier lhough if
removing error managemenl and securily from lhe navigalionaI map.

5. We vanl lo change lhe funclionaIily so lhal an arlicIe added from lhe arlicIe
search page shouId be handIed by lhe pIaceOrder.aspx (lhe form is submilled
here inslead of back lo arlicIeSearch.aspx). Do you lhink lhal you vouId be abIe
lo do lhal` Hov vouId you do lhal`

I1: Il is beller lhal lhe arlicIe search handIes lhis. I lhink I can do a redesign il bul
I am nol sure hov.
I2: Search arlicIe shouId posl lo pIace order. SimpIe. OnIy needs lhe sequence
diagrams, lhen RalionaI Rose aulomalicaIIy viII lake care of lhe resl.
I3: Yes, some redesign required. Whal funclionaIIy in vhich` Have lo dive in lo
lhe diagrams and documenlalion and find lhe background.
I4: The form in lhe arlicIe search posls lo IIaceOrder.aspx inslead.

6. Whal happens if you lry lo add an arlicIe lo lhe order bul lhere is no order
crealed`

I1: Il shouId have been a funclion lhal vouIdn'l aIIov lhe user lo add arlicIes in
lhe firsl pIace: for exampIe disabIed bullons or shov in lhe form lhal no order is
crealed.
I2: Nol so cIear in NavigalionaI map. (Checks sequence diagram.) Think lhere is
an expIicil order aIready. The order is aIready crealed.
I3: Nol possibIe lo ansver. Who creales lhe order, assuming lhal lhe order has
lime Iine in il lhen il viII be assumed il exisls aIready. (He lhoughl lhal ve
vhere laIking aboul lhe order ob|ecl vhen meaning lhe physicaI order.)
I4: Nolhing in navigalionaI map aboul lhis. Nolhing in lhe cIass diagram eilher.
Looking al lhe sequence diagram - conneclion lo lhe order is visibIe, bul nol
vhal is happening if you don'l have an order crealed.

7. Hov do you lhink lhe impIemenled syslem performs` Or vhal lhe
performance vouId be Iike from lhis design`

I1: The syslem quaIily shouId be beller vilh more delaiIed diagrams. CIear
improvemenls.
I2: Il gives more informalion and can handIe more lhings. Il shouId funclion
beller. As for lhe slruclure: funclion mighl be equaIIy veII pIus some added
lhings. Gives more delaiIs for impIemenlalion. /buiId/ in lhe sequence diagram is
annoying.

75
I3: CouId be vorse more redireclion. Looks beller in cohesion aspecl, bul couId
be performance probIem.
I4: Can nol say.

14.1.3 Fn!!nw-up qucstinns
1. Which design vouId you choose if you vere in a slakehoIder posilion`
Cuslomer` Ixeculive` Irogrammer`

Cuslomer:
I1: In aII cases WAI. Il is a beller vay lo design lhe diagrams.
I2: WouId onIy need lhe use-cases if being a cuslomer.
I3: Do nol shov lhis lype lo a cuslomer. Il conlains loo much code-behind
delaiI and is confusing. Il is difficuIl lo foIIov lhe coIIaboralions-diagrams
in lhe nev design. The oId design does nol leII aII, if lhe syslem does vhal
I vanl. Less enlily, leIIs lhe lrulh bul nol lhe vhoIe lrulh.
I4: WAI-UML, bul if lhe cuslomer doesn'l knov aboul design and UML il
shouId be Iess informalion in lhe diagrams. IT-company (bigger) - WAI.
An addilionaI documenl for simpIer sluff vouId be good.
Ixeculive:
I1: In aII cases WAI. A beller vay lo design lhe diagrams
I2: NavigalionaI map and sequence diagram onIy. Il is cIearer in lhe nev
design. Maybe I vouId choose lhe nev one. The diagram slruclure is
more foreseeabIe in lhe sequence diagrams (nol lhe exlensions).
I3: Same as if being a cuslomer.
I4: Can nol say.
Irogrammer:
I1: In aII cases WAI. Il is a beller vay lo design lhe diagrams.
I2: The navigalion map and sequence diagram is cIearer in lhe nev
design. Maybe I vouId choose lhe nev one. The form of lhe diagrams is
more perspicuous for lhe sequence diagrams.
I3: WouId choose lhe nev design, gives me more delaiI.
I4: WAI design diagrams.

2. Do you lhink WAI couId heIp you in fulure design` Is an improvemenl`
Hov`

I1: The oId design can be good lo have as an iniliaI lempIale because il mighl go
fasler lo compIeleIy redesign lhis one. Nev yes, mighl be abIe lo reuse on fulure

76
simiIar designs. Ior exampIe lhe slorage Iayer couId be used in anolher
impIemenlalion. The screen navigalionaI map is a bil confusing lhough.
I2: Did nol ansver because he is nol deveIoping any Web appIicalions.
I3: TeIIs vhal is vhal, yes il definileIy improves.
I4: Il requires a Iol of vork lo drav lhe design documenls. Takes lime lo gel
accuslomed lo lhe diagrams and nolalion. Yes, vouId be heIpfuI, bul I vouId
drav lhe design documenls lo fil me beller. Il vouId definileIy be suilabIe for
.NIT deveIopmenl.