Menüü
· Viimane number
· A&A konverentsi slaidid
· Küberturve
· Tudengitelt
· E-õpe
· Videomaterjalid
· Avalikud loengud
· Ilmunud numbrid
· Magistrirubriik
· Teemad
· Otsi
· Tellimine
· Küsitlused
· Soovita meid
· Tagasiside
· Top 10
· Statistika
· Toimetuskolleegium

Logi sisse
Kasutajanimi

Parool

Registreeri kasutajaks
Unustasid parooli?

Veebirakenduste loomine - tarkvaraarenduse ja loomingulise disaini ühendamine
Postitatud: Wednesday, February 05 @ 19:00:22 EET by Erki Eessaar

Tarkvara
Ilmus numbris 03/2000


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).

Frame_7.JPG

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).

Frame_16.JPG

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".

Frame_156.JPG

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:

  1. Nõuete analüüsi koosolek (ingl. k. Requirements Workshop).
  2. Kasutusjuhtude koosolek (ingl. k. Use-Case Workshop).
  3. 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

  1. Arvutikasutaja sõnastik. http://ee.www.ee/AKS/
  2. G. Booch. "Architecting Web-centric Systems" - presentatsioon konverentsil '99.
  3. 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
  4. D. Chapell. "The Next Wave. Component Software Enters The Mainstream". 1997.
    http://www.rational.com/uml/resources/whitepapers/index.jtmpl
  5. Hüpermeedia. http://www.tpu.ee/~aali/hm/
  6. 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
  7. I. Liiv. "Kontor Internetti: alternatiiv või saatus?" // Arvutimaailm (2000) 1, 16-18.
  8. J. Nielsen. "Prototyping Web designs". Jan. 21, 1999.
  9. UpShot.com pakub esimest tasuta onlain-rakendust äriasjade ajamiseks. // Arvutimaailm (1999) 9, 4.

Erki Eessaar
TTÜ informaatika õppesuuna magistriõppe üliõpilane


 
Seotud lingid
· Veel Tarkvara


Kõige populaarsem artikkel kategoorias Tarkvara:
Holistlik süsteemiarendus süsteemimaatriksi abil


Artikli reiting
Keskmine tulemus: 0
Hääled: 0

Oleks tore kui sa annaksid sellele artiklile oma hinnangu:

Super!
Väga hea
Hea
Keskmine
Halb





All logos and trademarks in the site are property of their respective owner(s). Comments are property of their posters, all the rest © 2003 by A&A
A&A elektrooniline väljaanne on valminud IT Kolledži toetusel.
Sait kasutab PHP-Nuke mootorit © 2002. Kõik õigused reserveeritud. PHP-Nuke on GNU/GPL litsensiga tasuta levitatav tarkvara.
Lehe loomiseks kulus: 0.139 sekundit