SISSEJUHATUS
Veebirakendused muutuvad üha populaarsemaks. See tuleneb tehnoloogiate
ja arendusvahendite kiirest arengust ja veebirakenduste eelistest traditsiooniliste
rakenduste ees. Veebirakendusi võib kasutada kõikjal, kus on olemas interneti-ühendus.
Eeliseks on ka see, et kliendi arvutile esitatavad nõudmised ei ole väga
suured.
Kuigi veebirakenduste esimene põlvkond oli lihtne ja pakkus vaid vähest
funktsionaalsust, oli ta ometi väga edukas. "Iga päev saab üha selgemaks,
et Võrk, nagu ka kõik teised pöördelised tehnoloogiad, võidab endale positsiooni,
mis muudab fundamentaalselt maailma toimimist. " (Louis Gerstner, IBM)[2].
Viimastel aastatel ongi esile kerkinud tarkvara arenduse uus põlvkond.
See on seotud selliste mõistetega nagu e-kaubandus ja e-äri. Need veebirakendused
pakuvad klientidele palju uusi funktsionaalsusi (online-transaktsioonid,
isiku tuvastamine jne.) Nendel süsteemidel on paindlik mitmekihiline arhitektuur,
mis võimaldab toime tulla ennustamatult suure kasutajate arvuga. Päevas
võidakse neid lehti kasutada kümneid või isegi sadu tuhandeid kordi. Taolist
tarkvarasüsteemi võib nimetada veebilahenduseks.
Kuni siiani disainiti ja rakendati veebirakendusi, pööramata sealjuures
tähelepanu formaalse arendusprotsessi ja modelleerimistehnikate piirangutele.
Nüüd on see muutunud. Veebirakendused ei ole enam lihtsad. Nad on muutunud
keerukateks ja kriitilise tähtsusega kohtades kasutatavateks rakendusteks,
millel võib olla tuhandeid kasutajaid. Neid tuleb ka vastavalt kohelda.
Paljude võimalustega rakenduse loomiseks on vaja arendusmeeskonda ja kindlalt
määratud arendusprotsessi. Standardi kasutamine on hädavajalik. UML (Unified
Modelling Language) on aktsepteeritud kui de-facto-standard objektorienteeritud
süsteemide modelleerimiseks.
Veebirakenduste loomine on paljuski sarnane teiste tarkvararakenduste loomisega,
kuid on ka olulisi erinevusi. Veebirakenduse näol on tegemist kliendi meediaga
(nagu näiteks film või video). Nagu iga kliendiprodukti puhul, on veebirakenduse
väljanägemine ja kasutatavus ülitähtis. Veebirakenduse loomisel omandavad
suure tähtsuse sellised rollid nagu marketingi spetsialist, kunstnik, kasutajaliidese
disainer, kasutatavuse testija, psühholoog.
Veebirakenduste looja ülesandeks ei ole seega ainult uute tehnoloogiate
kasutamine, vaid ka paljude erinevate rollidega inimeste kokkutoomine ja
efektiivse koostöö saavutamine.
Modelleerimise juures on kõige olulisem otsustada, mida modelleerida ning
millise detailsusega seda teha. Antud kirjutise peaeesmärk ongi rõhutada
vajadust korraliku arendusmetoodika ja modelleerimise järele.
PõHIMõISTETEST
Et vältida hilisemaid arusaamatusi, on kasulik kohe alguses defineerida
edasises arutelus kasutatavad põhimõisted. Veebi puudutavate märksõnade
kirjeldamiseks on peamiselt kasutatud internetis paikneva arvutikasutaja
sõnastiku [1] abi.
Brauser, lehitseja. Hüperteksti lugemise programm, nt (Netscape Navigator,
Internet Explorer).
Hüpertekst. Informatsiooni haldamisele lähenemine sellisel viisil, et andmed
on seatud sõlmede võrku, mis on omavahel ühendatud linkidega. Sõlmed võivad
sisaldada teksti, graafikat, hääli, videot, samuti programmi koodi või
teisi andmete edastamise viise [5].
Veeb. Omavahel hüperlinkidega seotud dokumentide kogum.
Sait. Kaugvõrguga ühendatud arvuti või arvutikogum.
Veebisait. Veebilehti talletav sait Internetis.
Veebirakendus. Veebirakendus on veebisait, kus kasutajate tegevus (mööda
saiti navigeerimine ja andmete sisestus) mõjutab äri olekut [2].
Veebiarendus. Veebidokumentide väljatöötamine ja kodeerimine.
Veebileht. Veebi kuuluv dokument.
UML (Unified Modelling Language) on visuaalne modelleerimiskeel. Visuaalne
modelleerimine on lihtsaim ja selgeim süsteemi kirjeldamise viis. UML on
suunatud ühise standardi, modelleerimise kontseptsiooni ja tähistuse loomiseks
mitmete objektorienteeritud modelleerimise metoodikate põhjal. See põhineb
Rumbaugh OMT-l (Object Modelling Language) ning sisaldab ka kasutusjuhtude
(use case) ja äriprotsesside kirjeldamise meetodeid (vt. joon. 1).
UML-i standardit toetavad tuntumad CASE-vahendid on Rational Rose, Select Enterprise ja COOL.
Rational Unified Process - Firma Rational poolt välja töötatud tarkvara
arendusprotsess (vt. joonis 2).
Rational Unified Process jagab arendustsükli ajateljel neljaks eraldi faasiks.
Visiooni loomise (ingl. k. inception) faasis otsustatakse see, mida kavatsetakse
ehitada. Visiooni kinnitamise (ingl. k. elaborate) faasis otsustatakse,
kuidas ehitada. Ehitamise (ingl. k. construction) faasis toimub tegelik
ehitamine. Tulemuse üleandmine tellijale toimub ülemineku- (ingl. k. transition)
faasis. Iga selline faas koosneb omakorda kordustest, mille tulemusena
saadakse mingi testitud tulemus. Iga faas kestab tavaliselt 2 nädalat kuni
2 kuud. Igas faasis on mingi põhitegevus ja sellele lisaks palju alamtegevusi. [3]
LOOMINGULISE DISAINI JA TRADITSIOONILISE TARKVARA ARENDUSE INTEGREERIMINE
Veebirakendused muutuvad üha populaarsemaks [2]:
- 3 päevaga installeerisid Cisco insenerid veebisaidi ja tarkvara, mis aitas
registreerida, jälgida ja identifitseerida Kosovo põgenikke
- 73 % Cisco müügist ja 79 % Cisco kasutajate toest toimub veebi vahendusel
- Aastaks 2003 peaks 14 % kõigist muusikapaladest müüdama veebi vahendusel
Internetis levib üha laiemalt nn. rakendusteenuste (ASP - Application
Service Provider) pakkumine. Rakendusteenuste pakkujate sihtgrupiks on
praegu peamiselt väikese ja keskmise suurusega firmad, korporatsioonide
osakonnad ning eraettevõtjad, kellele pakutakse Internetis võimalust oma
ärioperatsioonide sooritamiseks ilma sellelaadilistele tavarakendustele
omaste kõrgete kulutusteta. Kasutaja ei pea enam ostma ja installeerima
kallist tarkvara. Sellele vaatamata saab ta vahetada informatsiooni, leida
vajalikke faile ja saada ülevaadet enda ning teiste tegemistest. Veebipõhine
arhitektuur muudab rakendusteenuse kasutajatele takistusteta kättesaadavaks.
Tegemist on justkui virtuaalse kontoriga, mis annab kasutajale efektiivse
võimaluse hallata informatsiooni, olenemata oma hetkeasukohast. Tuleb lihtsalt
oma veebilehitseja kaudu vastavalt veebisaidilt süsteemi sisse logida ning
võibki hakata toiminguid sooritama. Turu-uuringute firma "Forrester Research"
ennustab rakendusteenuste turu kasvu 16 miljardini USD-ni aastaks 2001.
[9]
Järgnev ülevaade käsitleb seda, kuidas firma "Rational Software" poolt
välja töötatud nn. Rational Unified Process'i saab kasutada veebirakenduste
loomiseks. See lahendus on valminud firmade "Rational Software" ja "Context
Integration" ühistööna [6].
Kunagi varem pole tarkvara kasutajaliidesele ja selle kasutusmugavusele
pööratud niipalju tähelepanu kui praegu seoses veebirakendustega. Kuid
see pole iialgi olnud ka nii oluline. Tasub vaid vaadata veebifirmade aktsiate
hinnarallit New Yorgi börsil! Kui varem olid inimesed ilma suurema sõnaõiguseta
sunnitud vastu võtma kõik, mida uus tehnoloogia pakkus, siis nüüd on olukord
muutunud. Veebirakenduste turul ei osta kliendid enam tarkvara ega installeeri
seda oma arvutisse. Selle asemele seiklevad nad Internetis ja otsustavad
esmamuljete alusel, kas kasutada mingit rakendust või mitte. Esmamulje
on äärmiselt püsiv. Mõned psühholoogide uuringud on näidanud, et 2/3 esmamuljest
jääb püsima. Negatiivne esmamulje pidurdab osapoolte hilisemat suhtlemist.
Veebirakenduste puhul on väga olulised sellised omadused nagu kiirus, toimetulek
kasutajate rohkusega ja kasutajate arvu ebaühtlase jaotusega ööpäevas,
julgeolek, paindlikkus, võime pidevalt areneda. Väga olulised on ka rakenduse
hea väljanägemine ja kasutatavus. Seega tuleb nn. loominguline disain integreerida
üldisesse tarkvara arendusprotsessi (vt. joon.3).
Veebirakenduste (või mis tahes teise interaktiivse süsteemi) kasutatavuse
parandamiseks tuleb jälgida ainult ühte reeglit: mida sagedamini saab disainer
informatsiooni kasutatavuse probleemide kohta ja mida rohkem kordusi disain
sisaldab, seda parem on saadud rakenduse kasutatavus. Seega peab tellija
ja disaineri vahel toimuma pidev ideede vahetus ja tagasiside. Prototüübid
peaksid valmima päevaga. Tuleb kasutada joonistusvahenditega loodud kasutajaliidese
pilte, nn. "paberprototüüpe".
KASUTUSJUHUD INTEGREERIVAD LOOMINGULIST DISAINI JA TRADITSIOONILIST TARKVARAARENDUST
Veebirakendused laiendavad traditsioonilist tarkvaraarendust selliste valdkondadega
nagu kunst ja loominguline disain. Veebirakenduse loomine hõlmab rohkem
osapooli kui teiste tarkvararakenduste loomine. Osapoolte hulka kuuluvad
tavaliselt organisatsiooni juhid, turundusega tegelejad, disainerid / kunstnikud,
klienditoega tegelejad, programmeerijad, testijad jne. Toimub kultuuride
kokkupõrge. Osapooltevahelise kommunikatsiooni saavutamine on protsessi
seisukohalt kriitilise tähtsusega.
Veebirakenduste oodatava käitumise ühistes terminites kirjeldamiseks sobivad
nn. kasutusjuhud (ingl. k. use case'id). Kasutusjuhud on UML-i standardi
üheks osaks.
Kasutusjuhtude modelleerimistehnikat kasutatakse selleks, et näidata, mida
uus süsteem peaks tegema või mida olemasolev süsteem juba teeb. Kasutusjuhu
mudel ehitatakse iteratiivses protsessis, mille käigus toimub diskussioon
süsteemi arendajate ja tellijate (ja / või lõppkasutajate) vahel. Veebirakenduste
puhul võtavad diskussioonist osa näiteks kasutajad, juhid, kunstilise poolega
tegelejad, arhitektid, programmeerijad.
Kasutusjuhtude mudeli põhikomponentideks on kasutusjuhud, välissubjektid
ning modelleeritav süsteem. Kasutusjuhtude modelleerimisel vaadeldakse
süsteemi "musta kastina", mis pakub tegutsejatele (ingl. k. actor) teenuseid
(kasutusjuht). Kuidas süsteem seda teeb, kuidas kasutusjuhud on realiseeritud
ja kuidas nad sisemiselt töötavad, pole esialgu oluline. Seda ei pruugi
teada veel isegi projekteerijad. Tegutseja on igasugune välisüksus, kes
/ mis soovib suhelda antud süsteemiga. See võib olla inimene või süsteem
või riistvaraseade, mis peab suhtlema antud süsteemiga.
Kasutusjuhtude modelleerimise tulemusena saadakse vajaduste spetsifikatsioon,
millega on kõik osapooled nõus. See saadakse tellijate (ja / või lõppkasutajate)
ja süsteemi projekteerijate ning ehitajate vahelise koostöö tulemusel.
Kasutusjuhud annavad selge ja kooskõlalise kirjelduse sellest, mida
süsteem peab tegema. Seda kirjeldust kasutavad läbi kogu arendusprotsessi
süsteemi kõik osapooled, et üle anda soovitud tulemusi ning funktsionaalsusi.
Kasutusjuhud annavad ka aluse süsteemi testimisele, et saaks kindlaks
teha, kas üleantud süsteem täidab esialgselt soovitud funktsionaalsust.
NõUETE ANALüüS
Eduka veebirakenduse loomine algab visiooni loomisest. Visiooni kirjeldus
tuleb luua veebirakenduse loomise osapooltel. See peab tagama ühise arusaamise
projekti eesmärkidest.
Visiooni eesmärgid on:
- Saavutada kokkulepe probleemide osas, mida uus projekt peab lahendama
- Defineerida süsteemi piirid
- Kirjeldada süsteemi kõige tähtsamaid omadusi
Vead selles faasis võivad viia kogu projekti ebaõnnestumisele, vaatamata
sellele kui palju andekaid programmeerijaid hiljem lahenduse loomise kallal
töötab.
Kui visiooni osas on kokku lepitud, siis jätkuvad osapooltevahelised kohtumised,
et määrata kindlaks süsteemi kasutajad (rollid). Kasutajad ja neile pakutavad
teenused dokumenteeritakse, kasutades UML-i kasutusjuhtude kontseptsiooni.
Oluline on vajalik, et uue süsteemi kasutaja aktiivne osalus kasutusjuhtude
modelleerimisel, sest niiviisi saab mudelit täpselt kasutaja soovidega
kohandada . Kliendi ja tellija vajadused juhivad kogu arendusprotsessi.
Kasutusjuhud kirjeldatakse tellija ja kasutaja keeles ning mõistetes. Kasutusjuhud
võimaldavad lõppkasutajal kergesti kirjeldada vajalikke teenuseid, arendusmeeskond
aga saab hinnata, millised nõuded on täidetud.
Kus iganes võimalik, tuleks uuesti kasutada varasemates veebirakenduse
projektides defineeritud kasutusjuhte. Kujunevalt mudeliteturult võib samuti
vajaliku lahenduse leida ja sisse osta.
Luuakse ka nn. täiendav spetsifikatsioon, kuhu kogutakse informatsioon
süsteemi mittefunktsionaalsete nõuete kohta:
- Nõuded kasutatavusele
- Nõuded usaldatavusele
- Nõuded töökiirusele
|
- Nõuded julgeolekule
- Nõuded toetatavusele
- ...
|
Mittefunktsionaalsete nõuete näiteks on otsustus selle kohta, kes hakkavad
rakendust kasutama. See määrab paljuski ära ka tehnoloogiad, mida süsteemi
loomisel kasutatakse.
Ühine terminoloogia dokumenteeritakse sõnastikus. Sõnastik peab tagama,
et kõigil projekti liikmetel on ühine arusaamine põhimõistetest. [6]
ÜLDISED LOOMINGULISE DISAINI JUHISED
Paralleelselt kasutusjuhtude ja tegutsejate määramisega luuakse üldised
loomingulise disaini juhised (ingl. k. Creative Design Brief). Tegemist
on üldiste juhistega. Nad on osa kasutatavusest. Juhised defineerivad muuhulgas:
- Veebisaidi üldise väljanägemise (näiteks: kas sait nõuab kasutaja identifitseerimist? Kas sait on konservatiivne või provokatiivne?)
- Kuidas kasutajad saidile ligi pääsevad (ühenduse kiirus)
- Milliseid veebilehitsejaid kasutatakse
- Kas veebisaidis kasutatakse raame
- Kas on mingeid piiranguid värvide osas
- Millised on veebisaidi graafilisele küljele (näiteks logode ja firmavärvide standardid) esitatud nõuded
- Milliseid lisavõimalusi ja ilustusi ("kellad ja viled") soovitakse [6]
NAVIGATSIOONIKAART
Navigatsioonikaardi loomine eristab veebirakenduse loomist tavalise tarkvarasüsteemi
loomisest. Navigatsiooni disain on veebirakenduste juures kriitilise tähtsusega.
Ka väikesed rakendused võivad sisaldada keerukat navigatsioonisüsteemi,
mis aga kasutatavuse huvides peaks olema võimalikult lihtne ja arusaadav.
Navigatsioonikaart näitab, kuidas kasutajad saavad saidis navigeerida.
See esitatakse hierarhilise ("puukujulise") diagrammiga. Selliseid mudeleid
nimetatakse kirjanduses ka "saidikaartideks" (vt. joonis 4).
Iga diagrammi tase näitab seda, kuimitu hiireklikki kulub selle leheküljeni
jõudmiseks. Tüüpiliselt soovitakse, et veebisaidi kõige olulisemad piirkonnad
oleksid avaleheküljest vaid ühe kliki kaugusel.
Navigatsioonikaardi loomine projekti varases staadiumis tagab hea kommunikatsiooni
projekti erinevate osapoolte vahel. Kasutajad saavad hästi aru, kuidas
mööda veebirakendust navigeerida. Disainerid saavad samuti paremini aru
vajalikust navigatsiooniskeemist. Seetõttu tuleks navigatsioonikaart luua
kohe pärast esialgsete kasutusjuhtude defineerimist.
Mõnikord võib esialgne navigatsioonikaart olla skitseeritud juba enne kasutusjuhtude
mudeli loomist. Sel juhul pakub navigatsioonikaart kasuliku sisendi kasutusjuhtude
loomise arutelule. See tagab, et sait realiseerib kõigi osapoolte soovitud
käitumise.
Rational Unified Process'i puhul on selle vasteks tegevus "Modelleeri kasutajaliides".
Navigatsioonikaardi loomine algab sellest, et määratakse põhilised leheküljed
iga kasutusjuhu jaoks. Tüüpiliselt seatakse ühele kasutusjuhule vastavusse
üks lehekülg. Selles staadiumis ei ole veel teada, kuidas mingi lehekülg
hakkab välja nägema ja milline on lehekülgede lõplik hulk. Seega tuleb
keskenduda varasteks kasutajaliidese kandidaatideks olevate "loogiliste
lehekülgede" identifitseerimisele. Edasise analüüsi käigus võib nende hulk
muutuda. Loogilised leheküljed esitatakse UML-i konstruktsiooniga "boundary
class".
Kui loogilised leheküljed on loodud, näitab navigatsioonikaart seda, kuidas
kasutajad navigeerivad ühelt loogiliselt leheküljelt teisele. Samuti esitab
ta põhilisi omadusi, mida loogiline lehekülg pakub.
Suuremate süsteemide jaoks tuleks teha üks navigatsioonikaart tegutseja
kohta. Selleks et süveneda veelgi rohkem detailidesse, tehakse niisugune
mudel ka iga kasutusjuhu kohta. Sellel identifitseeritakse lisaleheküljed,
kuhu kasutaja kasutusjuhu täitmise käigus satub. Kui leheküljed on määratletud,
siis kirjeldatakse ka informatsiooni, mida need sisaldavad. [6]
KASUTAJALIIDESE PILDID
Kasutajaliidese väljanägemine on kasutaja peamine kontakt rakendusega.
Visuaalsed struktuurid teevad orienteerumise ja informatsiooni otsimise
lihtsamaks. Kasutajaliidese loomine on loominguline tegevus.
Selles vaates esitatakse osapooltele mitmeid esialgseid veebirakenduse
visuaalse väljanägemise võimalusi. Tavaliselt on tegemist mingi joonistusvahendi
abil joonistatud piltidega (ingl. k. Creative Design Comps). Paberil esitatud
piltide suurus võiks olla 150 % kasutajaliidese tegelikust suurusest. Pildid
esitatakse nii, nagu paistaksid nad veebilehitseja aknast. Selliste piltide
tegemise eesmärk on lükata tunduvalt kulukamate HTML-prototüüpide tegemine
aega, kuni on jõutud selgusele saidi graafilises väljanägemises. Pildid
aitavad vältida ka arusaamatusi, et veebirakenduse prototüüp on juba peaaegu
valmis.
Pildid võib joonistada ka käsitsi. Kui pilt näib suhteliselt "toores",
on kasutajatel suurem kalduvus teha sisulisi märkusi. Kui kasutada joonistusprogramme
ja luua pilt, mis praktiliselt sarnaneb juba tegeliku kasutajaliidesega,
siis keskenduvad kasutajad rohkem pisiasjadele. Teisest küljest, mida rohkem
aega ja vaeva kulutab disainerite meeskond prototüübi loomisele, seda rohkem
hoiavad nad sellest kinni ja seda raskem on neil kõike uuesti otsast alustada
[8].
Rippmenüüsid, hüpikmenüüsid ja muid selliseid kasutajaliidese elemente
saab kujutada eraldi väikestel paberilehtedel. Neid saab vajadusel suurele
kasutajaliidese pildile lisada või sealt ära võtta.
Rational Unified Process kirjeldab tegevust "Prototüübi kasutajaliides".
Selle käigus kogutakse ka tagasisidet kasutajaliidese kohta. Veebirakenduste
arenduse puhul on seda kasutajaliidese piltide koostamise arvelt laiendatud.
Selleks et luua pilte, valitakse üks tähtsamaid kasutusjuhtusid ja luuakse
vähemalt kümme erinevat kujundust. Nendest valitakse tellijatele esitamiseks
välja kolm kõige paremana tunduvat.
Kasutajaliidese pilte näidatakse tellijatele ja / või tulevastele kasutajatele.
Alustatakse mingist kindlast leheküljest ja esitatakse selle kohta küsimusi.
Küsitakse, kas pilt näeb välja selline, nagu kasutaja ootas, ja milline
on tema esimene reaktsioon sellele. Seejärel palutakse kasutajal ette kujutada,
et ta sõrm on kursor, ja osutada kohta, kus soovitakse klikkida. Esitatakse
küsimus: "Mis peaks siin klikkides teie arvates juhtuma?". Kui võimalik,
näidatakse kasutajale klikkimise tulemusel avanevat lehekülge ja kogu protseduur
kordub [8].
Tavaliselt peab toimuma kolm kordust (väljanägemise kujundamine - kasutajatele
esitamine - tagasisidega saadud paranduste / täienduste sisseviimine),
et jõuda välimuse osas lõplikule otsusele.
Kui lõpuks jõutakse kokkuleppele, saavad pildid aluseks funktsionaalse
kasutajaliidese prototüübi loomisele. Pildid on seejuures mittefunktsionaalsed
esimese põlvkonna prototüübid, mis on loodud saamaks tellijatelt tagasisidet.
Paljud visuaalsed omadused on juba esitatud. [6]
VEEBI DISAINI ELEMENDID
Veebi disaini elemendid on graafilised elemendid, mida kasutatakse veebisaiti
moodustavate lehekülgede kujundamisel. Graafilised elemendid on näiteks
navigatsioonivahendid ja lehekülje tagapõhjad. Kui kasutada kõrgekvaliteedilisi
standardseid graafilisi elemente kogu saidi ulatuses, siis vähendab see
rakenduse turule jõudmise aega ja arenduskulusid ning tõstab selle kvaliteeti.
Kogu kasutajaliidese kooskõlalisus on eriti oluline kasutatavuse seisukohalt,
seetõttu tuleb kogu saidis järjekindlalt rakendada standardseid graafilisi
elemente, mis tehakse valmis juba projekti varases staadiumis. Paralleelselt
koostatakse ka juhendid nende elementide kasutamiseks. Head graafilised
elemendid on illustratiivsed, selged ja nägusad, jäävad meelde ega luba
kaksipidi mõistmist. Neid kasutatakse erinevate programmide, tegevuste,
protsesside ja asjaolude identifitseerimiseks.
Rational Unified Process identifitseerib kasutusjuhtudest komponente punktis
"Töövoo detail: analüüsi käitumist". Neid komponente täiendatakse, rakendatakse
ja testitakse punktis "Töövoo detail: disaini komponendid".
Veebi disaini elemendid luuakse paralleelselt esialgse veebirakenduse kasutajaliidese
prototüübiga. Kasutajaliidese kohta koostatud pildid on kasutajaliidese
prototüübi loomisprotsessis sisendandmeteks. Selleks ajaks, kui kasutajaliides
lõplikult kooskõlastatakse, peavad ka veebi disaini elemendid olema lõpetatud
ja kooskõlastatud. [6]
VEEBIRAKENDUSE KASUTAJALIIDESE ESIALGNE PROTOTüüP
Prototüübi väljanägemine põhineb kooskõlastatud kasutajaliidese piltidel
ja selle loomisel kasutatakse veebi disaini graafilisi elemente. Rational
Unified Process'i puhul vastab sellele tegevus "Prototüübi kasutajaliides".
Esialgne kasutajaliidese prototüüp realiseerib tavaliselt kõige olulisematele
kasutusjuhtudele vastava süsteemi osa.
Kasutajaliidese esialgse prototüübi koostamine võimaldab kasutajatel ja
disaineritel paremini suhelda nii süsteemi funktsionaalsuse kui ka väljanägemise
küsimustes. Neil on, mille alusel rääkida ja mida arutada. Väga oluline
on saada kasutajatelt tagasiside enne seda, kui on tehtud suuri investeeringuid
kasutajaliidese funktsionaalsuse arendamisse. [6]
JUHENDID KASUTAJALIIDESE LOOMISEKS
Pärast seda, kui on loodud kasutajaliidese esialgne prototüüp, on aeg luua
detailsed kirjeldused kasutajaliidese loomiseks. Muu hulgas kirjeldatakse:
- millal ja kus kasutada veebi disaini elemente
- fonte
- värviskeeme
- kus paiknevad ja kuidas töötavad navigatsioonielemendid
Rational Unified Process'i puhul vastab sellele tegevus "Koosta juhised kasutajaliidese jaoks". [6]
VEEBIRAKENDUSE KASUTAJALIIDESE TÄIELIK PROTOTüüP
Kasutajaliidese täielikus prototüübis realiseeritakse kõik kasutusjuhud.
Prototüüp ei pea esitama täielikku navigatsiooni lehekülgede vahel ega
lehekülje lõplikku väljanägemist.
Järgneva iteratsioonilise ehitamise käigus täiendatakse prototüüpi pidevalt.
Täieliku prototüübi eesmärgiks on jõuda osapoolte vahel kokkuleppele iga
kasutajaliidese skoobi ja väljanägemise suhtes.
Täielik kasutajaliides põhineb Rational Unified Process'i juhisel "Use-Case
Storyboard". [6]
TäIELIK NAVIGATSIOONIKAART
Peale täieliku kasutajaliidese prototüübi tuleb luua ka täielik navigatsioonikaart.
See põhineb esialgsel navigatsioonikaardil ja täielikult defineeritud kasutusjuhtudel.
Täielik kaart peab sisaldama kõiki lehekülgi / ekraane, mis on esitatud
kasutajaliidese prototüübis. [6]
üLDISED NõUANDED TARKVARA ARENDAMISEKS
Järgnevalt esitatakse Rational Unified Process'i poolt pakutavad nõuanded
tarkvara arendamiseks [6]. Lisaks on kirjeldatud, kuidas neid kasutada
veebirakenduste loomisel.
- Arenda iteratiivselt: iteratiivne (korduv) arendamine põhineb pideval uurimisel,
avastamisel ja avastatu rakendamisel. See sunnib määratlema projekti riske
juba varases arendustsüklis. Seega saab nende vastu õigel ajal rakendada
õigeid meetmeid.
Veebirakendused vajavad just võimalikult lühikesi väljaandmise
tähtaegu, mida pakubki iteratiivne arendamine. Enne rakenduse käikuandmist
tuleb seda põhjalikult testida. Testimist on vaja alustada juba enne rakenduse
ehitamise lõppu. Iteratiivne arendusprotsess võimaldabki seda. Iga korduse
käigus peab toimuma kvaliteedi kontroll, mis sisaldab nii testimist kui
testimise käigus avastatud vigade parandamist.
- Juhi nõuded: nõuete analüüsi käigus tuuakse välja, organiseeritakse ja
juhitakse muutuvaid nõudeid tarkvaraga seotud süsteemides ja rakendustes.
Nõuded
veebirakendustele muutuvad niisama sagedasti kui turu nõuded. Seega muutub
nõuete jälgimine kogu arendustsükli jooksul veelgi tähtsamaks.
- Kasuta komponentarhitektuuri: arhitektuur kirjeldab rakenduste struktuuri
komponentide kaudu. Ta kirjeldab seda, kuidas need komponendid on ühendatud
ja kuidas nad omavahel suhtlevad. "Komponentidel põhinev arendus tähendab
rakenduste koostamist komponentidest: taaskasutatavatest, käivitatavatest
tarkvarapakettidest, mis pakuvad oma teenuseid läbi hästi defineeritud
liideste." [4]
Kui on võimalik, tuleks arhitektuurilahendus sisse osta.
Sellised funktsioonid nagu isiku kindlakstegemine, julgeoleku tagamine
jne. on juba ammu realiseeritud. Valmiskomponentide kasutamine kiirendab
veebirakenduse valmimist ja edasiarendamist. Kiiresti muutuvas maailmas
on see väga vajalik omadus. Komponentidel põhinev arendus on muutunud tavapäraseks.
Gartner Grupi ennustuste kohaselt põhineb aastal 2001 vähemalt 60 % kõigist
uutest tarkvaraarendustest komponenttehnoloogia kasutamisel [4].
- Modelleeri visuaalsete vahenditega: mudelid aitavad mõista ja hinnata nii
probleeme kui lahendusi. Mudel on reaalsuse lihtsustus. Visuaalne modelleerimine
on lihtsaim ja selgeim viis süsteemi kirjeldamiseks.
- Hinda kvaliteeti: kvaliteedi hindamisel pööratakse tähelepanu nii tootele
kui ka protsessile. Efektiivne ja kvaliteetne protsess viib ka kvaliteetse
tooteni.
Veebirakendust võivad päevas kasutada tuhanded inimesed. Vigadest
tulenev kahju võib olla väga suur. Kui rakenduse töökiirus on väike või
ta töötab valesti, ei pruugi kasutajad selle juurde enam kunagi tagasi
pöörduda. Veebirakenduste puhul on eriti oluline varane ja võimalikult
automaatne testimine.
Muu hulgas peab veebirakendus vastama järgmistele
nõuetele [3]:
Funktsionaalsus: Kasutajaliides peab kasutajatele meeldima ja rahuldama kõiki nende eesmärke.
Usaldusväärsus: Rakendus peab taluma suurt kasutatavust. Serverid ei tohi rivist välja langeda, rikkuda kasutajate andmeid või esitada kasutajale vigaseid andmeid.
Töökiirus: Rakendus peab olema võimeline kiiresti vastama kõigile kasutaja nõuetele.
Kontrolli muutusi: Veebirakendused sisaldavad palju objekte ja komponente,
mida võivad luua ja parandada paljud inimesed. Sageli toimuvad muudatused
paralleelselt. On väga oluline jälgida ja talletada informatsioon kõigi
muudatuste kohta.
TööD HõLBUSTAVAD KOOSOLEKUD
Veebirakenduste loomisel peavad koos töötama paljud erinevate elualade
ja rollidega inimesed. On vaja korraldada koosolekute seeriaid.
Rational Unified Process annab juhiseid, kuidas läbi viia:
- Nõuete analüüsi koosolek (ingl. k. Requirements Workshop).
- Kasutusjuhtude koosolek (ingl. k. Use-Case Workshop).
- Kasutusjuhtude analüüsi koosolek (ingl. k. Use-Case Analysis Workshop).
Loomingulise disaini puhul võib läbi viia vaid ühe koosolekute seeria -
Veebi võimaluste koosolek (ingl. k. Web Opportunity Workshop). Tegemist
on koosolekute hulgaga, mis on suunatud veebirakenduste loomisele. [6]
KOKKUVõTTEKS
Veebirakendused muutuvad üha populaarsemaks. Kuid need ei ole enam lihtsad.
Nad on muutunud keerukateks ja kriitilise tähtsusega kohtades kasutatavateks
rakendusteks ning neid tuleb ka vastavalt kohelda. Selliste rakenduste
loomiseks on vaja arendusmeeskonda ja kindlalt määratud arendusprotsessi.
UML (Unified Modelling Language) on sobilik selliste süsteemide modelleerimiseks.
Veebirakenduste loomine on paljuski sarnane teiste tarkvararakenduste loomisega,
kuid on ka olulisi erinevusi. Veebirakenduse näol on tegemist kliendimeediaga
(nagu näiteks film või video) ning seetõttu on ülitähtis selle hea väljanägemine
ja kasutatavus.
Firmad Rational Software ja Context International on pakkunud välja
veebirakenduste loomise arendusprotsessi, kus on integreeritud loominguline
disain ja traditsiooniline tarkvara arendusprotsess (Rational Unified Process).
Kõigepealt luuakse visioon uues süsteemis. Väga tähtis on nõuete
analüüs. Nõuete analüüsimiseks kasutatakse UML-i kasutusjuhtude modelleerimise
tehnikat. Kasutusjuhtude määramine võimaldab teha algust kliendilehekülgede
määratlemisega. Järgnevalt koostataksegi saidi navigatsioonikaart, mis
kirjeldab veebilehekülgede omavahelist seotust ja seda, kuidas kasutajad
saavad neil liikuda. Joonistusvahendeid kasutades koostatakse ka esialgsed
kasutajaliidese prototüübid. Samal ajal täpsustatakse disaini elemente
ja kasutajaliidesele esitatavaid nõudeid. Arendusprotsess on iteratiivne
ja võimaldab iga tsükliga mudeleid parandada ja täpsustada. Pärast seda,
kui tulevane kasutaja on kasutajaliidese välimusega nõustunud, algab töötava
prototüübi loomine.
See, et veebirakenduste loomisel pööratakse üha suuremat tähelepanu arendusmeeskonnale
ja arendusprotsessile, aitab kindlasti kaasa antud valdkonna ülikiirele
arengule.
KASUTATUD MATERJALID
- Arvutikasutaja sõnastik. http://ee.www.ee/AKS/
- G. Booch. "Architecting Web-centric Systems" - presentatsioon konverentsil '99.
- Building Web Solutions with the Rational Unified Process: Tuning Your Architecture Through Load-Testing. 1999.
http://www.rational.com/products/rup/prodinfo/whitepapers/index_bydate.jtmpl
- D. Chapell. "The Next Wave. Component Software Enters The Mainstream". 1997.
http://www.rational.com/uml/resources/whitepapers/index.jtmpl
- Hüpermeedia. http://www.tpu.ee/~aali/hm/
- P. Kroll, S. Ward. "Building Web Solutions with the Rational Unified Process: Unifying the Creative Design and the Software Engineering Process". A Rational Software & Context Integration white paper. 1999.
http://www.rational.com/products/rup/prodinfo/whitepapers/index_bydate.jtmpl
- I. Liiv. "Kontor Internetti: alternatiiv või saatus?" // Arvutimaailm (2000) 1, 16-18.
- J. Nielsen. "Prototyping Web designs". Jan. 21, 1999.
- UpShot.com pakub esimest tasuta onlain-rakendust äriasjade ajamiseks. // Arvutimaailm (1999) 9, 4.
Erki Eessaar
TTÜ informaatika õppesuuna magistriõppe üliõpilane