1. TALLINNA TEHNIKAÜLIKOOL
Infotehnoloogia teaduskond
Informaatikainstituut
KURSUSTE HALDAMISSÜSTEEMI
ITERATIIVNE ARENDUS
Bakalaureusetöö
Üliõpilane: Kadri Säde
Üliõpilaskood: 990791LAP
Juhendaja: Mart Roost
Tallinn
2004

2. Autorideklaratsioon
Deklareerin, et käesolev lõputöö on minu töö tulemus ja seda ei ole kellegi teise poolt varem
kaitsmisele esitatud.
.............................. ...............................
(kuupäev) (lõputöö kaitsja allkiri)
2

3. Sisukord
Sissejuhatus............................................................................................6
1. Taust ........................................................................................................................7
1.1 Visioon ................................................................................................ 7
1.2 Iteratiivne arendusprotsess ............................................................. 9
2. Planeerimise dokumentatsioon ............................................................12
2.1 Sõnastik ............................................................................................ 12
2.2 Nõuded ja vajadused ...................................................................... 12
2.2.1 Eesmärgid.......................................................................................................12
2.2.2 Kasutajad .......................................................................................................12
2.2.3 Põhiobjektid ...................................................................................................13
2.2.4 Põhilised sündmused ......................................................................................14
2.2.5 Funktsionaalsed nõudmised...........................................................................14
2.2.6 Mittefunktsionaalsed nõudmised...................................................................15
2.2.7 Riskid..............................................................................................................15
2.2.8 Turvalisus .......................................................................................................16
2.3 Kasutusjuhud kõrgformaadis ........................................................ 17
2.3.1 Kasutusjuhtude diagramm ............................................................................17
2.4 Domeenimudel................................................................................. 20
2.5 Arendusplaan................................................................................... 21
2.5.1 Esimene iteratsioon ........................................................................................21
2.5.2 Teine iteratsioon.............................................................................................21
2.5.2 Kolmas iteratsioon .........................................................................................22
2.5.3 Neljas iteratsioon............................................................................................22
2.5.4 Viies iteratsioon ..............................................................................................22
2.6 Arendusvahendid ............................................................................ 23
2.6.1 Rational Suite Enterprise tarkvara ...............................................................23
2.6.2 Oracle veebipõhine andmebaasi arendusvahend ..........................................23
2.6.3 PL/SQL...........................................................................................................24
3. Esimese iteratsiooni dokumentatsioon ...........................................25
3.1 Iteratsiooni plaan ja riskianalüüs ................................................ 25
3.2 Analüüsi dokumentatsioon ............................................................ 25
3.2.1 Tehnoloogia valik ...........................................................................................25
3.2.2 Kasutusjuhtude diagramm ............................................................................27
3.2.3 Kasutusjuhud laiendatud formaadis .............................................................27
3.2.4 Täpsustatud domeenimudel ...........................................................................29
3.2.5 Avalduse sisestamise tegevusdiagramm ........................................................30
3.2.6 Avalduse olekudiagramm ..............................................................................31
3.3 Disaini dokumentatsioon ............................................................... 31
3.3.1 Paketidiagramm .............................................................................................31
3.3.2 Komponendidiagramm ..................................................................................32
3.3.3 Reaalsed kasutusjuhud ..................................................................................33
3.3.4 Avalduse tekitamise kood ..............................................................................34
3

4. 3.3.5 Füüsiline andmemudel ...................................................................................36
3.4 Realisatsioon ................................................................................... 37
3.5 Iteratsiooni tulemused.................................................................... 37
4. Teise iteratsiooni dokumentatsioon ..................................................39
4.1 Iteratsiooni plaan ja riskianalüüs ................................................ 39
4.2 Analüüsi dokumentatsioon ............................................................ 39
4.2.1 Kasutusjuhtude diagramm ............................................................................39
4.2.2 Kasutusjuhud laiendatud formaadis .............................................................40
4.2.3 Kursuslase olekudiagramm ...........................................................................41
4.3 Disaini dokumentatsioon ............................................................... 41
4.3.1 Reaalsed kasutusjuhud ..................................................................................41
4.3.2 Füüsiline andmemudel ...................................................................................42
4.4 Realisatsioon ................................................................................... 43
4.5 Iteratsiooni tulemused.................................................................... 43
5. Kolmanda iteratsiooni dokumentatsioon.......................................44
5.1 Iteratsiooni plaan ja riskianalüüs ................................................ 44
5.2 Analüüsi dokumentatsioon ............................................................ 44
5.2.1 Kasutusjuhtude diagramm ............................................................................44
5.2.2 Kasutusjuhud laiendatud formaadis .............................................................45
5.2.2 Kursuslase olekudiagramm ...........................................................................46
5.3 Disaini dokumentatsioon ............................................................... 47
5.3.1 Reaalsed kasutusjuhud ..................................................................................47
5.3.2 Füüsiline andmemudel ...................................................................................48
5.4 Realisatsioon ................................................................................... 48
5.5 Iteratsiooni tulemused.................................................................... 49
6. Neljanda iteratsiooni dokumentatsioon ..........................................50
6.1 Iteratsiooni plaan ja riskianalüüs ................................................ 50
6.2 Analüüsi dokumentatsioon ............................................................ 50
6.2.1 Kasutusjuhtude diagramm ............................................................................50
6.2.2 Kasutusjuhud laiendatud formaadis .............................................................51
6.2.3 Täpsustatud domeenimudel ...........................................................................52
6.2.4 Kursuse sisestamise tegevusdiagramm..........................................................53
6.3 Disaini dokumentatsioon ............................................................... 54
6.3.1 Reaalsed kasutusjuhud ..................................................................................54
6.3.2 Füüsiline andmemudel ...................................................................................56
6.4 Realisatsioon ................................................................................... 56
6.5 Iteratsiooni tulemused.................................................................... 57
7. Viienda iteratsiooni dokumentatsioon ............................................58
7.1 Iteratsiooni plaan ja riskianalüüs ................................................ 58
7.2 Analüüsi dokumentatsioon ............................................................ 58
7.2.1 Kasutusjuhtude diagramm ............................................................................58
7.2.2 Kasutusjuhud laiendatud formaadis .............................................................58
4

5. 7.2.3 Täpsustatud semantika ..................................................................................59
7.2.3 Kursuse laiendatud olekudiagrammid ..........................................................61
7.3 Disaini dokumentatsioon ............................................................... 63
7.3.1 Reaalsed kasutusjuhud ..................................................................................63
7.3.2 Füüsiline andmemudel ...................................................................................64
7.4 Realisatsioon ................................................................................... 65
7.5 Iteratsiooni tulemused.................................................................... 65
8. Arengukava .......................................................................................................66
Kasutatud kirjandus .............................................................................68
Kokkuvõte............................................................................................69
Summary ..............................................................................................70
5

6. Sissejuhatus
Käesolev bakalaureusetöö kirjeldab arendusetapis olevat reaalset veebiliidest, mille
eesmärgiks on hõlbustada kursustele registreerumine ja kursuste haldamine koolitusega
tegelevas ettevõttes.
Koostatava dokumentatiooni põhjal loodav rakendus on veebipõhine. Internet on tänapäeval
igapäevaelu loomulik abivahend. Ühest küljest on veebipõhine kursustele registreerimise
süsteem konkreetne lahendus koolitusettevõtte klientidele, mis tekitab klientides usaldust,
andes koolitusfirmale mitmeid marketingieeliseid teiste koolitust pakkuvate ettevõtete ees.
Lisaks on taolise lahenduse puhul tagatud andmete erinevad haldamisvõimalused kursuste
korraldajale. Varasem kursuste haldussüsteem ei rahuldanud enam koolitusettevõtte
kasvavaid vajadusi kursuste hulga suurenemise tõttu, mis tingis elektroonilise
haldamissüsteemi loomise vajalikkuse. Seega on loodavale veebiliidesele seatavaks oluliseks
nõudmiseks CRM (Customer Relationship Management) ehk kliendihalduse võimalus. See
tähendab, et loodav rakendus peab võimaldama kliendi andmete kogumist ja haldamist nii, et
tekiks ülevaade kursustele registreerunud klientidest ja nende arvetest.
Töö keskendub lisaks iteratiivse arendusmeetodi käsitlemisele antud rakenduse arendamisel
ORACLE veebipõhise andmebaasi arendusvahendi tundmaõppimisele, sisaldades veebiliidese
arendamisvõimaluse analüüsi, lähtudes valitud veebipõhise arendusvahendi spetsiifikast.
Kokkuvõtlikult on antud bakalureusetöös peatähelepanu keskmes järgmiste tulemuste
saavutamine:
1) omandada praktiline iteratiivse arendusprotsessi kasutamise kogemus Craig Larmani järgi
antud lõputöös käsitletava veebiliidese arendamisel
2) arendada oskusi kasutada analüüsil ja modelleerimisel CASE (Computer Aided Software
Design) vahendit ja UML (Unified Modeling Language) diagramme Rational Rose
Enterprise tarkvaraga.
3) õppida tundma üht veebipõhist arendusvahendit, milleks on siin valitud ORACLE
veebipõhine andmebaasi arendusvahend.
4) ehitada kursuste haldamissüsteemi veebiliides
6

7. 1. Taust
1.1 Visioon
EAIE-sse (European Association for International Education) kuuluvad teabe- ja
testimiskeskuseid on üle maailma kokku ligi 400. Ligi pooled neist viivad läbi
rahvusvaheliselt sertifitseeritud keeletestide ettevalmistuskursusi. Kursused on erineva
kestuse ja mahuga. Paralleelselt toimub enamasti 2-5 kursust.
Veebipõhise kursuste haldamissüsteemi väljatöötamisest on huvitatud Eesti teabekesus,
täpsemalt Põhja-Ameerika ülikoolide teabekeskus Tallinna Tehnikaülikoolis, kes soovib
esialgset arendust esitleda EAIE nõustajate konverentsil augustis 2004.
Kursuste haldamise süsteem luuakse peamiselt teabekeskuse kursuste ja kursuslaste
haldamise töö lihtsustamise eesmärgil. Sama oluline on pakkuda kursuslastele kaasaegset
kursustele registreerimise võimalust.
Teabekeskuse infosüsteemi moodustavad erinevad teenused ja tegevused, mille ülevaade on
antud järgmisel joonilisel nr 1.
osaleb
Konsultatsioon
osaleb
organiseerib
Admi nistreerija haldab Koolitus
müüb Raamat
on korra ldab
ostab
on vä ljastab tasub
Töötaja Nõustaja Arve Klient
on
nõustab
osaleb
Testimine
Juhataja sõlmib vajab
vahendab
Stipendium
kirjuta b
koostab
Eelarve Aruanne Tööleping
Joonis 1. Teabekeskuse lihtsustatud infosüsteem
7

8. Teabekeskuses on kolm täiskohaga töötajat, kes on juhataja, administreerija ja nõustaja.
Juhataja koostab eelarveid, kirjutab aruandeid ja sõlmib töölepinguid. Nõustaja organiseerib
konsultatsioone, müüb raamatuid, väljastab arveid, nõustab testimisega seonduvat, vahendab
stipendiumiinfot ja korraldab koolitusi, mida administreerija haldab ja millel klient osaleb.
Klient osaleb konsultatsioonidel, testimistel, vajab stipendiume ja ostab raamatuid. Nõustaja
väljastab raamatute ja koolituste eest kliendile tasumiseks arveid. Siin ongi tarvidus
infosüsteem ümber korraldada, et nõustaja töö mahtu vähendada. Ühe mahukama osa tööst
moodustab kursustega seonduv. Kui kursuste haldamisel saaks kasutada süsteemi, mis
lihtsustaks tunduvalt kursuste korraldamisega seotud tööd ja millele ei pea palka maksma, siis
ümberkorraldusteks ressurside olemasolu korral tuleb seda võimalust ka kasutada.
Kavandatav kursuste haldamissüsteem peab esmalt võimaldama teabekeskuse administreerijal
hallata kursuseid. Oluline on kursuste veebipõhisesse andmebaasi lisamise võimalus, et
teabekeskuse kliendid saaksid registreeruda kursusele niipea, kui see on välja kuulutatud.
Süsteem peab tagama igale süsteemi kasutajaks registreerunud kliendile veatu avalduse
sisestamise kursustel osalemiseks ja tagastama arve numbri, mis tuleb tasuda kindlaks
määratud maksetähtaja jooksul. Administreerija kontrollib antud rakenduse välisest
raamatupidamissüsteemist arvete laekumisi ja saab kursuste haldamissüsteemis arvete
tasutuks märkimisega anda kursuslasele ligipääsu kursuse keskkonda.
Kursuslane peab saama lisaks avalduste esitamisele kursustel osalemiseks näha ja otsida oma
kasutajakontol olevaid kursuseid, arveid ja sisestatud avaldusi. Samuti on administreerijal
oluline näha ja otsida kursuslaste, arvete ja kursuste infot.
8

9. 1.2 Iteratiivne arendusprotsess
Tarkvaraprojektide arendusmaastikul on iteratiivse arendusprotsessi mõiste tuntud ja ettevõtte
äriprotsesside interpreteerimisel laialdaselt kasutusel. Iteratiivsusena käsitletakse antud töö
kontekstis tarkvaraarenduprotsessi tsüklilisust. Järgnevalt on kirjeldatud ülevaatlikult
iteratiivse arendusprotsessi sisu. Iteratiivsele arendusprotessile on iseloomulik erinevate
arendustsüklite sees samade süsteemiarenduse tegevuste kordamine, mis on tuntud kose
mudelist, kus süsteemiaernduse tegevusteks on klassikaliselt analüüs, disain ja realiseerimine,
mida iteratiivses arendusprotsessis korratakse tsükliliselt. Niisiis laiendab iga tsükkel vaatluse
all olevat süsteemi ja kõik tsüklid kokku annavad lõpptulemusena tervikliku süsteemi.
Üks levinumaid iteratiivseid arendusprotsesse on UP (Unified Process). UP, on RUPi
(Rational Unified Process) lihtsustatud ja üldisem mudel, kus projekti arendamine läbib nelja
suuremat faasi, millest iga faas sisaldab vähemalt ühte iteratsiooni. Need faasid on algfaas,
viimistlemine, ehitamine ja üleminek.[1]
Alfaasi põhiülesanneteks on anda edasi süsteemi visioon ja ligikaudsed hinnangud
ressurssidele ja ajale. Algfaasi eesmärk on panna paika projekti kontseptsioon, mida süsteem
peab tegema, millised on nõudmised ja riskid ning koostatakse esialgne plaan projekti
läbiviimiseks.
Järgnevas viimistlusfaasis realiseeritakse tehnilisest ja ärilisest funktsionaalsusest lähtuvalt
kõige olulisem süsteemi osa. Keskendutakse prioriteetidelt kõige kõrgema riskantsusega
iteratsioonidele, kus tehakse kindlaks kõik süsteemile esitatavad nõudmised ja leitakse
võimalusi riskide vähendamiseks. Viimistlusfaasis stabiliseeritakse arhitektuur, mis jäetakse
seejuures külmutamata, et edaspidi säilitada vajalike täienduste võimalikkus.
Ehitusfaas koosneb tavaliselt samuti mitmest iteratsioonist, mille eesmärgiks on ehitada
lõppkasutajale üleandmiseks valmis terviksüsteem. Ka ehitusfaasis tegeldakse madalamate
allesjäänud riskidega.
Viimases üleminekufaasis antakse kasutajale valmis süsteem, mis hõlmab süsteemi
juurutamist ja kasutaja koolitamist. Üleminekufaas võib koosneda mitmest iteratsioonist.
Praktikas paraku on viimane faas alahinnatud, kuid süsteemi kasutusele võtmisel on
üleminekufaasil tähtis roll.
Iteratiivne arendusmudel on juhitud konkreetsete kasutusjuhtude (Use-Case Driven) ja
stabiilse arhidektuuri poolt. Inglise keelne mõiste Use-Case Driven tähendab siin, et
kasutusjuhtude funktsionaalsuste arendamisele on määratud prioriteedid riskantsuse järgi.
Süsteemiarenduse algfaasis määratletakse süteemi valmimise ja valmis süsteemiga seostuvad
9

10. riskid. Riskidena käsitletakse olukordi, mis takistavad projekti eesmärkide saavutamist.
Riskid, mis otseselt mõjutavad süsteemi loomist, võivad olla seotud süsteemi nõudmiste
valesti mõistmisega või üldse süsteemist selge ettekujutuse puudumisega, nõudmiste
muutumisega, ebasobiva tehnoloogia valikuga või süsteemi jõudluse probleemidega, mis
võivad ilmneda alles süsteemi arendamise lõppfaasides, kui mitte kasutada iteratiivset
arendusprotsessi.
Arenduse käigus vähendataksegi süsteemi riske tsüklilise detailanalüüsi, disaini ja
realiseerimise kaudu.
Esimesestes iteratsioonides võetakse vaatluse alla kõrgeima prioriteediga riskid, mis
mõjutavad süsteemi valmimist kõige rohkem. Järgmistes iteratsioonides keskendutakse
madalama prioriteediga riskidele ja nende vähendamise meetoditele. Arenduse käigus
defineeritud riskid määravad järgmiste iteratsioonide sisu ja kestuse. Seejuures iteratsioonide
arv ei ole fikseeritud, vaid vareerub projektiti. [2]
Iteratiivse arenduse tsükliline sieloom avaldub kõige paremini selles, et korraga ei tehta kogu
toote lõplikku analüüsi, vaid analüüsi ühe sammuga läbitakse mitu etappi, mille jooksul
süsteemi täiendatakse. Iga iteratsioon lõpeb tehtud töö analüüsimisega. Selleks planeeritakse
iga iteratsiooni jaoks tulemused, mis peavad töös oleva arendustsükli lõppedes saavutatud
olema. Ühe iteratsiooni lõppedes püstitatakse järgmise iteratsiooni eesmärgid.
Projekti iteratsiivne arendustsükkel võimaldab projekti muutunud nõudmistest või arendamise
käigus avastatud ning teha vajalikke muudatusi eelmistes iteratsioonides. Kuigi kirjeldatud
olukorras iteratiivne arendusprotsess aitab vältida suuremahulisi muudatusi hilisemates
arendusetappides, on kasulik enamus projekti kitsaskohti ja riske defineerida kohe esimeste
iteratsioonide käigus.
Üks iteratsioon käsitleb lõppprojekti teatud funktsionaalsusi. Igas iteratsioonis läbitakse
vaadeldava tükelduse analüüsi-, disaini- ja realiseerimisetapp. Iga iteratsiooni tulemuseks
saadakse täienenud funktsionaalsusega süsteem, milles on vähendatud süsteemi algfaasis
defineeritud või süsteemi arendamisel avastatud riske.
Iga iteratsioon keskendub vähemalt ühele kasutusjuhule või kasutusjuhtude grupile, mida
nimetatakse ka süsteemi tükeldseks. Kasutusjuhu kõrgema keerukuse korral uuritakse
lihtsustatud kastusjuhtu ühes iteratsioonis ja jagatakse kasutsjuhuga seotud funktsionaalsus
mitme iteratsiooni vahel. Vastavalt eespool mainitule, käsitletakse esimestes iteratsioonides
kõige riskantsemaid kasutusjuhte, mis otseselt mõjutavad süsteemi loomist kõige rohkem.
Iga arendustsükli jaoks valitakse nõudmised, mida hakatakse täitma ja määratakse ajaperiood,
mille jooksul iteratsioon läbi viiakse. Ajaperiood peab olema määratud optimaalseim, et ei
10

11. tekiks ajapuudust, mille tõttu ei suudeta kõiki eesmärke täielikult täita ega aja üleküllust, kus
süsteemi viimistletakse liigselt selle keerukuse kasvuni, mis ei vasta planeeritule. Mõlemal
juhul on risk, et järgmised arendustsüklid võivad hilineda.
Vastupidiselt kose mudelile, kus kõik vajalikud nõudmised läbitakse vaid ühekordselt kõigi
süsteemi nõudmiste suhtes, viiakse igas iteratsioonis läbi väike osa süsteemi nõudmistest.
Eeliseks on, et süsteemi arendamine on kergelt hallatav, sest kõiki nõudmisi ei ei käsitleta
korraga, mistõttu süsteem ei kasva keerukaks ning raskelt mõistetavaks. Samuti on iteratiivse
arenduse tulemused selgemini näha ehk nn läbipaistvamad, sest vaheversioonid võimaldavad
saada tagasisidet õigeaegselt.
Iteratiivse arendustsükli õigeks mõismiseks ja probleemideta kasutamiseks on tähtis just
esimeste iteratsioonide käigus kavandada süsteemi ehitamise plaan, teha kindlaks nõudmised
ja leida peamised riskid. Kui neid samme teha erinevates iteratsioonides, peab tõenäoliselt
alustama korduvalt algusest. Edasimineku tagamiseks järgmistesse iteratsioonidesse tuleb
paika panna igale iteratsioonile plaan, milliseid tulemusi iteratsiooni käigus saavutama peab.
Juhul kui iteratsioon osutub liiga mahukaks, on vajalik valida osa, mis realiseeritakse ja
vähem kriitilisem osa on mõtekas paigutada järgmisesse iteratsiooni. Oluline on ka riskide
identifitseerimine ja prioriteetide määramine, et vältida kõrgema taseme riskide tähelepanu
alla sattumist alles süsteemiarenduse viimastes etappides. [3]
Käesoleva töö korral on iteratsioonide läbiviimisel ja dokumentatsiooni koostamisel aluseks
võetud Craig Larmani poolt raamatus “Applying UML and Patterns: An introduction to
object-oriented analysis and design and Unified Process” [2] välja pakutud lahendus.
Iteratsiooni alguses koostatakse plaan ja püstitatakse eesmärgid, mida iteratsioonide
tulemustena saavutada soovitakse. Analüüsietapis võetakse vaatluse alla süsteemi laiendatud
kasutusjuhud, tehakse täiendusi domeenimudelis vastavalt iteratsioonis vaadeldud objektidele
ja tuuakse ära mõned põhiobjektide olekudiagrammid. Disainimise käigus võetakse vajadusel
vaatluse alla süsteemi arhitektuur, kirjeldatakse reaalsed kasutusjuhud ning täiendatakse
andmebaasimudelit. Realiseerimise osas antakse ülevaade, milliste vahenditega süsteemi
vaheversioon realiseeritakse ja milline süsteem üldiselt välja hakkab nägema. Arendusetapis
antakse järgmiste võimalike ja vajalike iteratsioonide lühikirjaldus. Iteratsioonide
dokumentatsioon peaks andma piisavalt tõepärase ülevaate süsteemi arendamise ja
realiseerimise kulgemisest.
11

12. 2. Planeerimise dokumentatsioon
2.1 Sõnastik
Kursus – Koolitusega tegeleva ettevõtte teenus. Antud juhul rahvusvaheliselt sertifitseeritud
keeletestide ja akadeemilise võimekuse testide ettevalmistuskursus, mille eest saadud
ainepunkte aktsepteerivad kokkuleppete kohaselt erinevad Eesti kõrgemad õppeasutused ja
ülikoolid.
Kasutaja – Süsteemi kasutaja, kellel on kas süsteemi administreerija st haldaja või
registreeruja ning edaspidi kursuslase õigused.
Administreerija – Süsteemis kursuste ja kursuslaste haldaja.
Registreeruja – Süsteemi kasutaja, kes soovib saada kasutaja õigusi, et sisestada kursuse
avaldusi ja saada kursuslase õigused.
Kursuslane – Süsteemi kasutaja, kes on juba registreerunud süsteemi ja sisestanud avaldusi.
Omab õigusi teha kursuslase pädevusalasse kuuluvaid toiminguid.
2.2 Nõuded ja vajadused
2.2.1 Eesmärgid
Eesmärgid, mille süsteem peab täitma:
• loob tervikliku veebipõhise andmebaasi kursustest ja kursuslastest
• annab kasutajale võimaluse siseneda kursuste registreerumise keskkonda
• võimaldab kasutajatel registreeruda kursustele
• annab kasutajale ülevaate, milliseid kursuseid ta on valinud
• võimaldab kasutajal otsida avaldusi ja kursuste arveid
• võimaldab süsteemi administreerijal hallata kursusi, kursuslasi, arveid ja ligipääse
2.2.2 Kasutajad
Süsteemil on kolme tüüpi kasutajaid:
Administreerija – Infotöötaja, kes omab süsteemi haldamise õigusi, sealhulgas kursuste ja
kursuslaste haldamise õigusi.
12

13. Registreeruja – Registreeruja, kes soovib saada süsteemi kasutaja õigusi. Omab kursusele
avalduse sisestamise õigust, mille järgselt saab kursuslase õigused.
Kursuslane - Kursuslane, kes omab kursusele uute avalduste sisestamise õigust kursustel
osalemiseks, valitud kursuste, arvete ja avalduste otsimise ja vaatamise õigust ning kursuse
veebikeskkonda ligipääsu pärast saadud arve maksmist.
Administreerija staatus lubab süsteemi haldajal teha tüüptoiminguid andmebaasi kursustega.
Administreerija saab kursusi lisada, muuta ja erijuhtudel kustutada. Samuti on võimalik
lisatud kursuseid otsida ja vaadata. Arvete sisestamine ja ligipääsude andmine pärast arve
maksmise kontrollimist süsteemiväliselt on süsteemi administraatori ülesanne.Admistreerija
õigused annavad loa peale kursuslaste otsimise ka erijuhtudel kursuslasi lisada, kustutada või
kursuslase andmeid muuta. Administraator saab luua erinevaid raporteid, näiteks kursustele
laekunud avalduste ja kursuslaste kohta.
Registreeruja on registreeruja kuni avalduse sisestamiseni, mille järgselt temast saab
kursuslane.
Kursuslase staatus annab süsteemi kasutajaks registreerunul õiguse sisestada süsteemi
avaldusi kursustest osavõtmise sooviga. Lisaks lubab otsida ja vaadata lisatud avalduse
andmeid, valitud kursuseid ja kursuste arveid.
2.2.3 Põhiobjektid
Süsteemi põhiobjektid on:
Kasutaja – süsteemi kasutavad isikud;
Kursuslane – kasutaja, kellel on kursuse õigused; kursustele registreeruja/regisreerunu;
Avaldus – registreerumise vorm kursuste valimiseks ja isikuandmete sisestamiseks;
Kursus – koolitus, millele kursuslased saavad registreeruda esitades avalduse;
Arve – teatis, mis viitab kursuse eest tasumisele ja selleks vajalikele andmetele;
Administreerija– kasutaja, kellel on süsteemi haldaja õigused;
Kursuse periood – kursuse toimumise kindlaksmääratud ajavahemik;
Valitud kursus – kursus, millele kursuslane on avaldust lisades registreerunud;
Arve numbrite vahemik – vahemik, mis on kursusele määratud arve numbreid tähistama.
13

14. 2.2.4 Põhilised sündmused
Tegevused, mida kasutajad kõige sagedamini süsteemis sooritavad:
• Kursuse andmete sisestamine. Administreerija sisestab kursuse andmed ja kirjelduse,
kursuse perioodi andmed ning kursusega seotud arve numbrite vahemikud ja arvete
andmed.
• Kursuse keskkonna kasutajaks registreerumine. Kursustele registreeruda soovija
registreerib oma andmed avalduse sisestamiseks ja kasutajakonto saamiseks.
• Kursuse avalduse lisamine. Registreeruja täidab avalduse vormil nõutud isikuandmed,
maksja andmed, valib kursuse, millel soovib osaleda ning kas ta soovib ainepunkte
lisades lõpuks kogu avalduse täitmise vältel tehtud valikud andmebaasi.
• Valitud kursuste otsimine ja vaatamine. Registreerujal on võimalik valitud kursusi
erinevate parameetrite järgi otsida ja vaadata.
• Arvete otsimine ja vaatamine. Registreeruja saab otsida konkreetset arvet või kõiki
arveid tema poolt määratud otsingukriteeriumide järgi.
• Maksete tasutuks märkimine. Administreerija määrab makstud arved tasutuks ja
kursuslane saab automaatselt sisenemisõiguse tema poolt valitud kursuse keskkonda.
2.2.5 Funktsionaalsed nõudmised
Süsteem peab võimaldama järgmiseid üldiseid funktsionaalsusi:
Administreerija – kursuste, kursuslaste, arvete ja ligipääsude haldamine;
Registreeruja – kursustele registreerimine ja ligipääs kursuse veebikeskkonda.
Detailsemalt peab süsteem vastama funktsionaalsetele nõudmistele, mis on järgnevad:
Kasutaja kursuste haldussüsteemi sisenemine;
Registreeruja:
Registreerumine;
Kursuslane:
1) Avalduse sisestamine/muutmine;
2) Avalduse vaatamine/otsing;
3) Arve vaatamine/otsing;
4) Valitud kursuse vaatamine/otsing;
Administreerija:
1) Kursuse sisestamine/otsimine/muutmine;
14

15. 2) Kursuslase sisestamine/otsimine/muutmine;
3) Arve otsimine/tasutuks märkimine/vaatamine/annulleerimine;
4) Ligipääsu tekitamine/eemaldamine.
2.2.6 Mittefunktsionaalsed nõudmised
Süsteemi kasututusmugavust, töökindlust, jõudlust ja toetatavust :
• Süsteem peab kergesti olema kättesaadav kõigile soovijatele, esitamata suuri nõudmisi
kliendi riist- või tarkvarale, mis puudutab süsteemi veebikeskkonna kasutamist;
• Kasutajaliidese ekraanivormide laadimisaeg peab olema lühike;
• Süsteem peab olema kergelt hallatav, muudetav ja laiendatav
• Süsteem peab tagama kasutajate isiklike andmete varjatuse;
• Kasutajaliidese ekraanivormid peavad olema lihtsad ja arusaadavad;
• Kasutajaliidese navigatsioon peab olema lihtsalt mõistetav – kasutaja peab otsitava
kergelt leidma ja sisestatavaid välju üheselt mõistma;
• Juhised vormide täitmiseks peavad olema piisavad;
• Sisestatud andmetel peavad kehtima piirangud (põhiliselt andmetüüp ja pikkus);
• Süsteem peab olema võimeline sisestatud andmeid mõningal määral kontrollima.
2.2.7 Riskid
Riskianalüüs kujutab endast esmalt võimalike riskide identifitseerimist.
Potensiaalsed riskid on järgmised:
1) kasutajapoolsed riskid:
a) süsteem ei ole kasutajale lihtsalt arusaadav ja hõlpsasti kasutatav;
b) kasutaja andmed on avalikud ja nähtavad teistele süsteemi kasutajatele;
2) nõudmistest põhjustatud riskid:
a) Süsteemi kasutusse võtjal ei pruugi olla visiooni loodavast süsteemist või kui on,
siis võib kasutaja ettekujutus loodavast süsteemist arendamise käigus muutuda.
b) Süsteemi kasutusse võtja ei pruugi olla üldse huvitatud süsteemi arenduse protsessis
osalemisest, mis raskendab pideva tagasiside olemasolu, mis on aga oluline tingimus
süsteemi iteratiivsel arendamisel.
15

16. 3) tehnoloogiast tulenevad riskid:
a) Süsteemi kasutusse võtja tehnoloogilised eelistused või erinevate tehnoloogijate
kasutusvõimalused on muutunud.
Riskide minimeerimiseks on võimalik kasutada järgmiseid meetodeid:
• Kasutajapoolsete riskide üheks vähendamise meetodiks on vaheversioonide loomine,
et oleks võimalik saada kasutajatelt tagasisidet. Otstarbekas on juba esimesel
võimalusel disaini algfaasis süsteemi tulevaselt administreerijalt ja kasutajapoolselt
testijalt uurida, milline lahendus ekraanivormide puhul nende arusaamade kohaselt on
kõige kasutajasõbralikum.
• Nõudmistest tulenevate riskide lahendamiseks on tarvis luua vaheversioone süsteemi
kasutusse võtjale esitamiseks ja süsteemi arendamisel kasutada iteratiivset
arendusprotsessi, mis kõige efektiivsemalt aitab ennetada tõsiseid vigu, kui süsteemi
arendamise algfaasis pole suudetud kokku leppida süsteemile vastavates nõudmistes ja
tingimustes arendaja ja süsteemi tulevase kasutuselevõtja vahel. [2]
• Tehnoloogiariskide lahendamiseks tuleb uurida ja analüüsida tulevaste
administreerijate ja kasutajate nõudmisi ja tegelikke võimalusi. Võimalikult varajases
süsteemi planeerimise etapis tuleb välja selgitada süsteemi arhitektuur ja sobivaim
tehnoloogia ning kooskõlastada süsteemi tulevase haldajaga valikud ja muudatused
igas süsteemi arendamise etapis.
Peamiseks tehnoloogijariskide vähendamise abinõuks on valida sobiv tehnoloogia, mis on
võimalikult universaalne ja standardiseeritud, kusjuures standardid ei uuene tihedalt ega
muuda seega süsteemi pidevat muutmist uuele standardile vastavaks omaette tülikaks
protsessiks.
2.2.8 Turvalisus
Loodava süsteemi turvalisuse nõuded eeldavad, et süsteemis registreerunud kasutajate
andmed on kaitstud teiste kasutajate eest. Süsteemi registreerunud kasutajad on sisestanud
oma isikuandmeid, sealhulgas isikukoodi, aadressi, telefoni ja e-maili.
Kasutaja õiguste kontrollimiseks on mõistlik lahendus kasutajakonto loomine, kus kasutaja
identifitseeritakse kasutajanime ja parooli alusel.
16

17. Vähemalt sama oluline on, et kliendikonto omanik ei oma ligipääsu veebiliidese osale, mis
hõlmab süsteemi administreerimise toiminguid. Sellest tulenevalt on vajadus eraldi määrata
kursuslase ja administreerija õigused.
2.3 Kasutusjuhud kõrgformaadis
2.3.1 Kasutusjuhtude diagramm
Kursuse
Admini streerij a
sisestamine/otsimine/muutmine
Kursuslase
Andmete korrektsuse kontroll
sisestamine/otsimine/muutmine
Arve tasutuks määramine/otsimine
Registreerumine
Avalduse sisestamine/muutmine
Registreeruja
Avalduse vaatamine/otsing
Kursuslane
Arve va atamine/o tsi ng
Kasuta ja kontro ll
Valitud kursuse vaatamine/otsing
Joonis 2. Algfaasi kasutusjuhtude diagramm
Kasutusjuht: Registreerumine
Tegutsejad: Registreeruja
17

18. Kirjeldus: Registreeruja sisestab oma andmed ja kasutajanime ning parooli. Süsteem
salvestab need, tekitab uue kasutaja ning kuvab registreeruja isikuandmed ja edasi võimaldab
koheselt pääsu süsteemi avalduse esitamiseks jm toiminguteks.
Kasutusjuht: Avalduse sisestamine/muutmine
Tegutsejad: Registreeruja
Kirjeldus: Kursuslane täidab kursuse avalduse vormi, kuhu sisestab oma isikuandmed.
Süsteem kuvab aktiivsed kursused. Registreeruja valib kursuse ja kas ta soovib ainepunkte
(ülikoolidega on leping, mis võimaldab kursuslasele ainepunkte anda). Süsteem kuvab maksja
andmete vormi. Registreeruja määrab maksja andmed. Süsteem kuvab sisestatud andmed ja
tehtud valikud. Kursuslane kinnitab lõplikult avalduse lisamise. Süsteem tekitab kursuslase,
avalduse, seostab kursuslasega arve ja kursuslase valitud kursuse. Süsteem kuvab, et klient on
kursusele registreeritud ja kursuse veebikeskkonnale ligipääsu saamiseks tuleb maksta teatud
kuupäevade jooksul arve. Avalduse muutmine on võimalik kuni lõpliku kinnitamiseni.
Kasutusjuht: Avalduse vaatamine/otsing
Tegutsejad: Registreeruja
Kirjeldus: Registreeruja otsib avaldust erinevate otsingu parameetrite järgi. Süsteem tagastab
vastava(d) avalduse(d).
Kasutusjuht: Valitud kursuse vaatamine/otsing
Tegutsejad: Registreeruja
Kirjeldus: Registreeruja otsib valitud kursusi erinevate parameetrite järgi. Süsteem kuvab
vastava(d) kursuse(d).
Kasutusjuht: Arve vaatamine/otsing
Tegutsejad: Registreeruja
Kirjeldus: Registreeruja otsib valitud kursusi erinevate parameetrite järgi. Süsteem kuvab
vastava(d) arve(d).
Kasutusjuht: Kasutaja kontroll
Tegutsejad: Süsteem
Kirjeldus: Süsteem kontrollib vormi kuvamisel, kas tegemist on õige kasutajaga.
18

19. Kasutusjuht: Andmete korrektsuse kontroll
Tegutsejad: Süsteem
Kirjeldus: Süsteem kontrollib, kas kasutaja on sisestanud kõik andmed ja kas need on
korrektsed.
Kasutusjuht: Kursuse sisestamine/otsimine/muutmine
Tegutsejad: Administreerija
Kirjeldus: Administreerija sisestab algatatava kursuse andmed, sisestab kursuse perioodi, ja
arve numbri vahemiku. Süsteem näitab tehtud valikuid ja palub neid kinnitada.
Administreerija kinnitab sisestatud andmed. Süsteem tekitab kursuse, kursuse perioodi ja arve
numbri vahemiku ning salvestab sisestatud andmed.
Kasutusjuht: Kursuslase sisestamine/otsimine/muutmine
Tegutsejad: Administreerija
Kirjeldus: Administreerija saab süsteemist otsida kursuslasi erinevate parameetrite järgi.
Süsteem kuvab otsitud kursulase(d).
Kasutusjuht: Arve otsimine/tasutuks märkimine/vaatamine/annulleerimine
Tegutsejad: Administreerija
Kirjeldus: Administreerija otsib arveid erinevate parameetrite järgi. Süsteem kuvab
vastava(d) arved(d). Administreerija märgib arve(d) tasutuks. Süsteem lisab muudatuse ja
tekitab kursuslasele valitud kursuse veebikeskkonna lingi tema kasutaja alla.
Administreerija võib erandjuhul arveid tühistada. Süsteem kustutab arve vastava kasutaja alt.
Kasutusjuht: Ligipääsu eemaldamine
Tegutsejad: Administreerija
Kirjeldus: Administreerija otsib kursuse valinud kursuslasi. Süsteem kuvab kursuslased.
Administreerija saab märkega eemaldada kursuslaste ligipääsud kursuse keskkonda. Süsteem
eemaldab kasutaja(te)lt lingi(d) antud kursuse veebikeskkonna aadressiga.
19

20. 2.4 Domeenimudel
Avaldus
Maksja_eesn imi : Stri ng
Maksja_perenimi : String
Registreeruja
Maksja_isikukood : Integer
Olek : Boole an
Kasutaja esitab
Kasu tajanimi : Stri ng
seotu d
Tuup : Boole an
Oi gused : String
Parool : String Arve
Eesn imi : String Arve_nr : Integer
Pereni mi : Stri ng Koostamise_kp : Date
E-mail : String Summa : Integer
Telefon : Stri ng Maksetahtaeg : Date
Aadress : String Makseviis : String
Isi kukood : Integer Tasutud_kp : Date
sisestab Olek : Boolean
Admi ni streerij a
vastab
Kursus
Nimetus : String
Keskkond : String
Kirjeldus : String
Olek : Boolean
Joonis 3. Algfaasi lihtsustatud domeeni eskiismudel
Kursuse periood
Arve nr vahemik
Piirang : Integer
Nr_algus : Integer
Tahtaeg : Date
Nr_lopp : Integer
Algus : Date
Valitud kursus Nr_viimane : Integer
Lopp : Date
Algoritm : Integer
Ainepunktid : Boolean Hind : Integer
Ainepunkte : Integer Programm : String
Ainepunkte : Integer
sisaldab vastab
sisaldub
Arve sisaldab
Avaldus Arve_nr : Integer
Koostamise_kp : Date Kursus
Maksja_eesnimi : String seo tud
Summa : Integer
Maksja_perenimi : String Nimetus : String
Maksetahtaeg : Date
Maksja_isikukood : Integer Keskkond : String
Makseviis : String
Olek : Boolean Kirjeldus : String
Tasutud_kp : Date
Olek : Boolean
Olek : Boolean
esitab
sisestab
Kasutaja
Kasutajanimi : String
Tuup : Boolean
Oigused : String
Parool : String
Eesnimi : String
Perenimi : String
E-mail : String
Telefon : String
Aadress : String
Isikukood : Integer
Re gistreeruj a Administreerija
Joonis 4. Algfaasi domeeni eskiismudel
20

21. Administreerija on süsteemi kasutaja, kes sisestab süsteemi kursuse, mis sisaldab kursuse
perioodi. Registreeruja on kasutaja, kes sisestab süsteemi avalduse, mis sisaldab valitud
kursust. Avaldus on seotud arvega, mis on võetud arve numbri vahemikust. Arve on seotud
kursuse perioodiga. Algfaasi domeeni eskiismudel ei ole külmutatud ja seda arendatakse
iteratsioonide käigus edasi.
2.5 Arendusplaan
2.5.1 Esimene iteratsioon
Esimeses iteratsioonis võetakse vaatluse alla süsteemi põhifunktsionaalsusest kursuslase
avalduse sisestamise ja muutmisega seotud kasutusjuhud. Lisatakse vormide täitmise juhendid
ja andmete sisestamise kontroll. Arendustsükli eesmärgiks on leevendada süsteemi
kasutajapoolseid riske, mis on seotud kasutaja arusaamisest, kuidas süsteemis teha tema
pädevusalale vastavaid toiminguid. Tehnoloogiaga seotud riskide vähendamiseks
projekteeritakse süsteemi esialgne arhitektuur ning ehitatakse süsteemi vaheversioon, mis
aitab süsteemi tulevasel kasutusele võtjal saada ettekujutuse arendaja poolt loodavast
süsteemist ja läbi viia esmased kasutajapoolsed testid, et vähendada nõudmistega seotud riske.
Lisatakse veebikeskkonna kujunduslikud elemendid.
Kestvus: üks nädal
Dokumentatsioon: Kursuslase avalduse sisestamise ja muutmise kasutusjuhud, täpsustatud
domeenimudel ja esialgne arhitektuur, avalduse olekudiagramm ja avalduse sisestamise
tegevusdiagramm. [7]
Süsteemi vaheversioon: Kursuslase avalduse sisestamise ja muutmise liides.
2.5.2 Teine iteratsioon
Teise iteratsiooni ülesandeks on lisada süsteemi turvalisus. Käsitletakse registreeruja süsteemi
registreerumise kasutusjuhtu. Teises iteratsioonis lisatakse süsteemi kasutaja (esmalt
registreeruja) tuvastamise mehhanism. Kavandatakse vormide täitmise juhendid ja piirangud
andmete sisestamisel.
Kestvus: üks nädal
Dokumentatsioon: Süsteemi registreerumise kasutusjuht. Piirangute ja turvalisuse
dokumentatsioon, kursuslase olekudiagramm.
21

22. Süsteemi vaheversioon: Registreeruja süsteemi registreerumise liides. Süsteemi lisatakse
kasutaja autentimine ja süsteemi sisenemise ja registreerumise liides ning registreeruja ja
kursuslase liideste täiendused andmete sisestamise korrektsuse ja kasutaja kontrolliga.
2.5.2 Kolmas iteratsioon
Kolmandas iteratsioonis võetakse vaatluse alla süsteemi põhifunktsionaalusest kursuslase
avalduse, valitud kursuse ning arve vaatamise ja otsimisega seotud kasutusjuhud. Luuakse
vaheversioon kasutajapoolsete testide läbiviimiseks, et vähendada nõudmistega seotud riske.
Täiendatakse süsteemi vormide täitmise juhendeid ja piiranguid andmete sisestamisel.
Kestvus: üks nädal
Dokumentatsioon: Kursuslase avalduse, valitud kursuse ja arve vaatamise ja otsimisega
seotud kasutusjuhud.
Süsteemi vaheversioon: Kursuslase avalduse, valitud kursuse ja arve vaatamise ja otsimise
liides.
2.5.3 Neljas iteratsioon
Neljanda iteratsiooni ülesandeks on arendada administreerija allsüsteemi, kus vaatluse alla
võetakse kursuse sisestamise, otsimise ja muutmise kasutusjuhud. Täiendatakse
navigatsiooniskeemi ja luuakse administreerija kasutajaliides. Testitakse vaheversiooni
administreerija liidese toimimist.
Kestvus: üks nädal
Dokumentatsioon: Administreerija kursuse sisestamise, otsimise ja muutmise kasutusjuhud,
kursuse täiendatud olekumudel ja kursuse sisestamise tegevusdiagramm ja füüsiline
andmemudel.
Süsteemi vaheversioon: Süsteemi lisatakse administreerija kasutusjuhte hõlmav liides.
2.5.4 Viies iteratsioon
Viienda iteratsiooni ülesandeks on arendada administreerija allsüsteemi, kus vaatluse alla
võetakse arve otsimise, tasutuks märkimise, vaatamise ja annullerimise ning ligipääsu
eemaldamise kasutusjuhud. Täiendatakse vormide täitmise juhendeid ja piiranguid andmete
sisestamisel. Testitakse administreerijaliidese toimimist. Täiendatakse süsteemi navigeerimise
plaani.
22

23. Kestvus: üks nädal
Dokumentatsioon: Arve otsimise, tasutuks märkimise, vaatamise ja annullerimise ning
ligipääsu eemaldamise kasutusjuhud, täiendatud domeenimudel ja navigeerimise plaan.
Süsteemi vaheversioon: Süsteemi administreerija liides koos täiendustega.
2.6 Arendusvahendid
2.6.1 Rational Suite Enterprise tarkvara
Rational Suite Enterprise tarkvara liides Rational Rose on tarkvara projekteerimiseks mõeldud
CASE (Computer Aided Software Design) vahend, mis võimaldab modelleerida UML
(Unified Modeling Language) vahenditega.
Mudel on reaalsuse lihtsustus, mis kirjeldab süsteemi mingist vaatenurgast täielikult. Mudelite
ehitamine aitab komplekssetest süsteemidest paremini aru saada. Tarkvara modelleerimine
standardset modelleerimiskeelt (nt. UML) kasutades garanteerib, et kõik arendustöös osalejad,
(antud juhul on arendajaks ja realiseerijaks töö kirjutaja ühes isikus) üheseltmõistetavalt oma
otsuseid üksteisele teatavaks teha.
Suur osa UPist puudutab arendatava süsteemi mudelite loomist ja haldamist. UP on arendatud
käsikäes UMLiga. UML on graafiline keel tarkvarapõhise süsteemi tehiste visualiseerimiseks,
spetsifitseerimiseks, konstrueerimiseks ja dokumenteerimiseks. [6]
2.6.2 Oracle veebipõhine andmebaasi arendusvahend
Seoses interneti kiire kasvuga on kursuste haldamissüsteem realiseeritud veebiliidesena.
Kasutatud on Oracle Corporation’i poolt pakutud erinevate infosüsteemide väljatöötamise
võimalusi ja laiendusi. HTML DB veebipõhine andmebaasi arendusvahend võimaldab
süsteemi ehitada kasutades ainult veebibrauserit.
Vabavarana saadaval oleva arendusvahendi andmebaasi suurused on 2, 5, 50 ja 100
megabaiti. Suuremate vajaduste korral on Oracle Corporation käesoleval 2004. aastal turule
toonud uue toote, milleks on Portal, kus suuremaid võimalusi pakuvad HTML DB
veebipõhise andmebaasi arendusvahendi laiendus koos Oracle 10g andmebaasiserveriga.
HTML DB arendusvahendisse on integreeritud kõigi kolme tarkvara kihi, milleks on
andmebaasi, äriloogika ja andmete esitluskihi realiseerimise võimalused.
23

24. Application Builder SQL Workshop Data Workshop Administration
Joonis 5. Oracle HTML DB veebipõhise arendusvahendi põhikomponendid. [4]
HTML DB põhikomponendid on jaotunud järgnevalt:
Rakenduse ehitamine(Application Builder) – Rakenduse ehitus, mis hõlmab kasutajaliideste
lehekülgede menüüde, regioonide, väljade, nuppude, protsesside, piirangute, turvalisuse ja
muu sarnase määramist.
SQLi kirjutamine (SQL Workshop) – SQL käskude protsessor, skriptid, dll-d; andmete
brauser sisaldab funktsioonide, protseduuride, indeksite, tabelite, trigerite, vaadete loomise
võimalusi.
Andmetega toimingud (Data Workshop) – andmete eksportimine ja importimine teksti ja xml
kujul.
Administreerimine (Administration) – kasutajate, logide, sessioonide monitooring ja raportid.
HTML DB veebipõhises andmebaasi arendusvahendis on plussiks, et rakendust on võimalik
koheselt käivitada ja igas ehitamise etapis tehtud muudatust näha. Välistatud on mitte
töötavate funktsioonide või protseduuride sattumine andmebaasi, sest arendus toimub
iteratiivsele arendusprotsessile omaselt tsüklitena, mis ei luba järgmisesse faasi liikuda, kui
eelmine ei ole lõplik või eesmärk pole saavutatud.
2.6.3 PL/SQL
SQL on standardkeel andmete lugemiseks, lisamiseks, muutmiseks ja kustutamiseks
andmebaasist. PL/SQL (Procedural Languages/ Structured Query Language) on Oracle
laiendus SQLile. PL/SQL lisab protseduuridele programmeerimiskeele omadused nagu
tsüklilause, hargnemislause, muutujate deklareerimine ja vigade töötlus. Esmakordselt
tutvustas Oracle seda 1988. aastal ja sellest ajast peale on seda pidevalt edasi arendatud ja
arendatakse ka tulevikus.
Kuna PL/SQLi kompileeritakse ja hoitakse andmebaasis, siis annab see eelised kiirusele. See
ei nõua käitusaegset kompileerimist ega interpreteerimist. Samuti puudub veebilehe
24

25. kuvamisel serveri ja baasi vahel edasi-tagasi käimine, kui JSP, ASP või Perliga tehtud lehe
puhul võib skript käia korduvalt andmebaasi ja serveri vahel, siis PL/SQLi puhul seda ei
toimu, sest PL/SQL asub ise andmebaasis. Kiiruse vahe ilmneb eriti suuremate andmehulkade
töötlemisel. [5]
3. Esimese iteratsiooni dokumentatsioon
3.1 Iteratsiooni plaan ja riskianalüüs
Esimeses iteratsioonis viiakse läbi süsteemi kursuslase põhifunktsionaalsuse analüüsi-,
disaini- ja realisatsioonietapid. Põhifunktsionaalsus hõlmab avalduse sisestamist ja muutmist.
Iteratsioonis võetakse ühe nädala kestusel vaatluse alla järgmised kasutusjuhud:
1) Avalduse sisestamine/muutmine;
2) Andmete korrektsuse kontroll.
Esimeses iteratsioonis käsitletakse planeerimise dokumentatsioonis identifitseeritud riske (vt
p. 2.2.7). Kasutajapoolsetest võetakse vaatluse alla risk, kus süsteem ei ole kasutajale lihtsalt
arusaadav ja hõlpsasti kasutatav;
Nõudmistest tulenevatest riskidest püütakse kindlaks teha, kas süsteemi kasutusse võtja omab
muutumatut visiooni loodavast süsteemist ja kas süsteemi kasutusse võtja on üldse huvitatud
süsteemi arenduse protsessis osalemisest.
Antud riskide vähendamiseks kasutatakse süsteemi vaheversiooni loomist, mis aitab süsteemi
kasutusele võtjal olla kursis arendustööga, et oleks varakult võimalus vajadusel lisada või
täpsustada süsteemile esitatavaid nõudmisi.
3.2 Analüüsi dokumentatsioon
3.2.1 Tehnoloogia valik
Kasutatava tehnoloogia valikul tuli otsustada, millist tüüpi rakendus süsteemi loomisel
ehitada, milline server, programmeerimiskeel js andmebaas rakenduse aluseks valida.
Kõige praktilisem on antud süsteem luua veebipõhisena, et kursustele registreerumist oleks
kõigil soovijatel mugav läbi interneti teostada. Samuti on süsteemi haldamine läbi interneti
25

26. tänapäeva mobiilses töökeskkonnas juba levinud lahenduseks, kus töökoht ei pea asuma
tingimata kontoris, vaid pigem internetis.
Antud süsteemi realiseerimiseks osutus sobivaks ja esialgu ka piisavaks lahenduseks Oracle
veebipõhine andmebaasi server, mis serveri programmeerimise keeleks pakub PL/SQL-i.
Oluline, on et PL/SQL päringud ei pea võtma korduvalt ühendust andmebaasiga.
PL/SQL võimaldab sarnaselt PostgreSQLile:
1) alampäringute sooritamist;
2) trigerite kirjutamist;
3) tabelite vaheliste relatsioonide kasutamist;
4) salvestatud protseduuride kirjutamist;
5) vaadete loomist.
Samuti võimaldab Oracle veebipõhise andmebaasi arendusvahend lihtsalt luua ekraanivorme
nii administreerimise kui ka registreerumise liidesele. Antud projekti puhul kasutasin
põhiliselt standardpäringuid ja aruandeid (reports) otsinguprotsesside käivitamiseks ja
kuvamiseks.
Tehtud otsuste põhjal näeb süsteemi arhitektiuur piltlikult välja joonisel 3. esitatud kujul.
Joonis 6. Jäme süsteemi arhitektuur
26

27. 3.2.2 Kasutusjuhtude diagramm
Kursuslane Aval duse sisestam ine/ muutm ine
(f rom Actors)
Andmete korrektuse kontroll
Joonis 7. Esimese iteratsiooni kasutusjuhtude diagramm.
3.2.3 Kasutusjuhud laiendatud formaadis
Kasutusjuht: Avalduse sisestamine/muutmine
Tegutsejad: Registreeruja
Eesmärk: Võimaldada kursuslasel sisestada avalduse kursusel osalemiseks
Kirjeldus: Kursuslane täidab kursuse avalduse vormi, kuhu sisestab oma isikuandmed.
Süsteem kuvab aktiivsed kursused. Registreeruja valib kursuse ja kas ta soovib ainepunkte
(ülikoolidega on leping, mis võimaldab kursuslasele ainepunkte anda). Süsteem kuvab maksja
andmete vormi. Registreeruja määrab maksja andmed. Süsteem kuvab sisestatud andmed ja
tehtud valikud. Kursuslane kinnitab lõplikult avalduse lisamise. Süsteem tekitab kursuslase,
avalduse, seostab kursuslasega arve ja kursuslase valitud kursuse. Süsteem kuvab, et klient on
kursusele registreeritud ja kursuse veebikeskkonnale ligipääsu saamiseks tuleb maksta teatud
kuupäevade jooksul arve. Avalduse muutmine on võimalik kuni lõpliku kinnitamiseni.
Eeltingimused: Administraator on eelnevalt sisestanud aktiivseid kursusi.
Järeltingimused: Tekitatud on kursuslane, avaldus, valitud kursus ja arve.
Stsenaarium:
Kasutaja Süsteem
1. Sisestab avalduse andmed. 2. Kasutab kasutusjuhtu korrektsete andmete
kontroll. Kuvab aktiivsete kursuste loetelu.
3. Valib kursuse ja kas soovib ainepunkte. 4. Kuvab maksja andmete vormi.
5. Sisestab maksja andmed. 6. Kasutab kasutusjuhtu korrektsete andmete
kontroll. Kuvab tehtud valikud.
7. Kinnitab valikud. 8. Tekitab uue kursuslase, avalduse ja valitud
kursuse, seostab arvega ning salvestab lisatud
27

28. andmed andmebaasi.
9. Kuvab kursuse lisamise kinnituse ja arve
numbri.
2,4 Käivitab kasutusjuhu andmete korrektuse kontroll.
Alternatiivid: Juhul kui kasutaja soovib andmeid muuta on võimalik eelmistele vormidele
tagasi liikuda. Süsteem uuendab andmeid vaatel. Juhul kui kasutaja ei soovi avalduse täitmist
jätkata saab ta selle igas etapis katkestada.
Kasutusjuht: Andmete korrektsuse kontroll
Tegutsejad: Süsteem
Eesmärk: kindlustada võimalikult korrektsete andmete andmebaasi sattumine
Kirjeldus: Süsteem kontrollib sisestatud andmeid. Kui andmete sisestamise väli või väljad on
täitmata või ei vasta standardile, kuvab süsteem veateate ja ei luba edasi liikuda enne kui viga
on korrigeeritud. Isikukoodi sisestamisel kontrollitakse välja pikkust ja teisendatakse seda ka
kuupäevaks.
Eeltingimused: Kasutaja on sisestanud andmeid.
Järeltingimused: Andmebaasi on lisatud kontrollitud ja korrektsed andmed.
Stsenaarium:
Kasutaja Süsteem
1. Sisestab avalduse andmed. 2. Andmete kontroll. Leiab vea.
3. Parandab vea. 4. Kuvab aktiivsete kursuste loetelu.
5. Valib kursuse ja kas soovib ainepunkte. 6. Kuvab maksja andmete vormi.
7. Sisestab maksja andmed. 8. Andmete kontroll. Leiab vea.
9. Parandab vea. 6. Kasutab kasutusjuhtu korrektsete andmete
kontroll. Kuvab tehtud valikud.
7. Kinnitab valikud. 8. Tekitab uue kursuslase, avalduse ja valitud
kursused ning salvestab lisatud andmed
andmebaasi.
9. Kuvab kursuse lisamise kinnituse ja arve
numbri.
28

29. Alternatiivid: Juhul kui kasutaja soovib andmeid muuta on võimalik eelmistele vormidele
tagasi liikuda. Süsteem uuendab andmeid vaatel. Juhul kui kasutaja ei soovi avalduse täitmist
jätkata saab ta selle igas etapis katkestada.
3.2.4 Täpsustatud domeenimudel
Käesoleva peatüki domeenimudelil on ära toodud esimeses iteratsioonis käsitletavad
kontseptid. Mudelile on täpsustatavalt lisatud atribuudid ja kontseptide vahelised
assotsiatsioonid.
Vali tud kursus
Avaldus Kurs us
Vali tud_id (PK) : Integer
Maksja_eesni mi : Stri ng sisald ab määrab Nimetus : String
Aval dus_i d (FK) : Integer
Maksja_pere nim i : String Keskkond : String
Peri oodi _id (FK) : Integer
Maksja_isikukood : Integ er Kirjeldus : String
1 1..* Ainepunktid : Bo olea n 1..* 1
Ol ek : Boolean Olek : Boolean
Ainepunkte : Intege r
1..*
1 on seotud 1..* 1
sisa ldub
e sitab 1
Arve
1 1 Arve_nr : Integer
Kursuslane Koostamise_kp : Date
Summa : Integer vastab
Olek : Boolean
Registreerimise kp : Date Maksetahtaeg : Date
Makseviis : String 1 ..*
Tasutud_kp : Date
1
Olek : Boolean
esineb
1
Kasutaja
Kasutajanimi : String
Tuup : Boolean
Oigused : String
Parool : String
Eesnimi : String
Perenimi : String
E-mail : String
Telefon : String
Aadress : String
Isikukood : Integer
Registreeruj a
Joonis 8. Esimese iteratsiooni täpsustatud domeenimudel.
Süsteemi registreerunud kasutaja esineb kursuslasena, mis tähendab, et ta omab kursuslase
õigusi. Kursuslane esitab kursusel osalemiseks avalduse, mis sisaldab valitud kursusi.
Valitud kursus määrab kursuse, millel süsteemi registreerunud kursuslase õigusega
kasutaja soovib osaleda. Igale kursusele vastab arvete hulk. Arves sisalduvad valitud
kursused arve ridadena. Avaldusega on seotud arve, mida kursuslane omab ja on
kohustatud kursuse eest tasuma.
29

30. 3.2.5 Avalduse sisestamise tegevusdiagramm
Uue avalduse
sisesta mise valim ine
Avalduse vormi
kuvamine
Avalduse andm ete Väljad täitmata / ei ole korrektsed
sise stam ine
Viga parandatu d Ei lisa ja annab veateate
Aktiivseid kursuseid ei ole
Kursuse valik
Viga p arand atud
Ei lisa ja annab info aktiivsete kursuste puudumisega
Maksja andmete Väljad täitmata / ei ole korektsed
sisestamine
Ei lisa ja annab veateate
Aval duse valikute Viga parandatu d
kuvamine
Aval duse valikute Kasutaja poolne katkestamine
kinnitamine
Ei lisa ja katkestab
Viga p aranda tud
Kursuslase, avalduse ja
valitud kursuse tekitamine
Aval duse lisam ise kii nitus e j a
arve numbri kuvamine
Joonis 9. Avalduse sisestamise tegevusdiagramm
Märkus: Kuni avalduse valikute kinnitamiseni on võimalik iga tegevuse täitmise järel liikuda
eelnevalt sooritatud tegevuse juurde tagasi ja vaadata üle või teha täidetud vormidel
muudatusi.
30

31. 3.2.6 Avalduse olekudiagramm
Kasutaja sisestab avalduse andmed / kontrollitakse avalduse andmeid
Kasutaja sisestatab ebakorrektseid andmeid / kuvatakse veateade
Esialgsed avalduse
andmed
Kasutaja salvestab avalduse / avalduse andmed salvestatakse
Kasutaja muudab andme id / andm eid m uudetakse
Salvestatud
avalduse andmed
Kasutaja kustutab a valduse / aval duse andm ed kustutatakse
Joonis 10. Avalduse olekudiagramm.
Märkus: Kasutaja on esmakordel avalduse sisestamisel registreeruja, edaspidi kursuslane ja
kursuslase õigustega.
3.3 Disaini dokumentatsioon
3.3.1 Paketidiagramm
Kasutajaliides Kursuslane
Admini streerij a Süsteemi Registreeruja
toimimine
Suhtlus
andmebaasiga
PL/SQL
andmebaas is
Andmebaas
Joonis 11. Arhitektuuri paketidiagramm.
31

32. Antud töö arhitektuuri loogika lähtub Oracle HTML DB loogikast. Niisiis asub suhtlus
andmebaasiga andmebaasis sees, sest süsteemi toimimiseks PL/SQL ei käi kasutajaliidese
vaadete veebis kuvamisel korduvalt andmebaasi ja serveri vahel ega vaja käitusaegset
kompileerimist või interpreteerimist. Täpsemalt on PL/SQL-ist osas 2.6.3.
Süsteemi toimimiseks on administreerijal, kursuslasel ja registreerijal kasutajaliidesed veebis.
Registreerija liides on sisuliselt süsteemi sisenemise liides. Administreerija liidesel saab teha
kursuste haldamisega seotud tegevusi administreerija õigustega kasutaja ja kursuslane saab
oma liidesel teha oma pädevusalasse kuuluvaid tegevusi. Süsteemi toimimises on sees
süsteemi äriloogika, mis sisaldab süsteemi põhifunktsionaalsusi.
3.3.2 Komponendidiagramm
Registreerumise Administreeruja Kursuse
vorm avaleht sisestamise vorm
Kursuslase
otsimise vorm
Arve otsimi se
vorm
Kursuse
Kurs uslas e
otsimise vorm
aval eht Avalduse
otsimise vorm
Kursuse keskkonda
sisenemise vorm
Valitud kursuse
otsimise vorm
Avalduse Andme baas
sisestamise vorm
Joonis 12. Komponendidiagramm.
Komponendidiagramm käsitleb osa kasutajaliidesest üldiselt. Andmebaasiga on seotud veel
erinevad protsesside, trigerite, funtsioonide ja protseduuride komponendid.
32

33. 3.3.3 Reaalsed kasutusjuhud
Joonis 13. Avalduse andmete sisestamise vorm.
Kasutusjuht: Avalduse sisestamine (vormid antud joonistel 13, 15 ja 16.)
Tegutsejad: Kursuslane (esmakordsel avalduse sisestamisel registreeruja, sest kursuslast pole
veel loodud)
Kirjeldus: on kirjeldatud punktis 3.2.3
Käivitatav sündmus: Kursuslane soovib sisestada uue avalduse kursusele registreerumiseks.
Eeltingimused: Administraator on eelnevalt sisestanud aktiivseid kursusi.
Järeltingimused: Tekitatud on kursuslane, avaldus, valitud kursus ja arve.
Seotud kasutusjuhud: Andmete korrektsuse kontroll (käivitub vormidel 13, 15 ja 16).
Lisamärkus: Kasutusjuht avalduse sisestamine on realiseeritud multivormidel.
Joonis 14. Kursuse valiku vorm.
Joonis 15. Maksja andmete sisestamise vorm.
33

34. Joonis 16. Kokkuvõtte ehk avalduse andmete lõpliku sisestamise vorm.
Peale kinnitust järgneb ekraanil kuvatud avalduse kinnitus ja arve nr.
3.3.4 Avalduse tekitamise kood
Pärast kokkuvõtte ehk avalduse lõplikku kinnitamist ja sisestamist toimub avalduse
tekitamine. Järgnevalt on esitatud avalduse tekitamise kood, kus esmalt deklareeriakse
muutujad, seejärel juhul kui kursuslaste ei eksiteeeri tekitatakse kursuslane, tekitatakse
avaldus, lisatakse valitud kursus ja ainepunktid ning seostatakse avaldusega arve. Tabelid on
koondatud pakettidesse.
declare
sAinepunktid varchar2(4);
sArve_nr varchar2(40);
rAV ARVE_NR_VAHEMIK%rowtype;
nSumma number:=0;
nKURSUSLANE_ID number;
nAVALDUS_ID number;
nARVE_ID number;
34

35. aPer_id HTMLDB_APPLICATION_GLOBAL.VC_ARR2;
aAP HTMLDB_APPLICATION_GLOBAL.VC_ARR2;
begin
/*
Tekitan kursuslase kui teda veel ei ole, kui on siis võtan muutujast
*/
if v('G_KURSUSLANE_ID') is null then
nkursuslane_id:=AVALDUSE_TEKITAMINE.Tekita_kursuslane(
v('G_KASUTAJA_KASUTAJANIMI'),
v('G_KASUTAJA_EESNIMI'),
v('G_KASUTAJA_PERENIMI'),
v('G_KASUTAJA_ISIKUKOOD'),
v('G_KASUTAJA_TELEFON'),
v('G_KASUTAJA_E_MAIL'));
htmldb_util.set_session_state('G_KURSUSLANE_ID',nKursuslane_id);
else
nKursuslane_id:=v('G_KURSUSLANE_ID');
end if;
nAvaldus_id:=AVALDUSE_TEKITAMINE.Tekita_avaldus (
nKursuslane_id,
v('P60_EESNIMI'),
v('P60_PERENIMI'),
v('P60_ISIKUKOOD'),
v('P60_TOOKOHT_KOOL'),
v('P60_AADRESS'),
v('P60_TELEFON'),
v('P60_E_MAIL'),
v('P62_MAKSJA_EESNIMI'),
v('P62_MAKSJA_PERENIMI'),
v('P62_MAKSJA_ISIKUKOOD'));
aPer_id:=HTMLDB_UTIL.STRING_TO_TABLE(v('P61_VALITUD_KURSUS'));
aAP :=HTMLDB_UTIL.STRING_TO_TABLE(v('P61_VALITUD_AINEPUNKTID'));
for c1 in 1..aPer_id.count loop
sAinepunktid:='E';
for c2 in 1..aAP.count loop
if aAP(c2)=aPer_id(c1) then sAinepunktid:='J'; exit; end if;
end loop;
AVALDUSE_TEKITAMINE.Kursuse_perioodid (
aPer_id(c1),
nAvaldus_id,
sAinepunktid,
nSumma,
sArve_nr);
end loop;
35

36. nArve_id:=AVALDUSE_TEKITAMINE.Tekita_arve (nSumma);
/*
Tekitatud avaldusega seostan arve numbri.
*/
if aPer_id.count=1 then
update arve set arve_nr=sArve_nr where arve_id=nArve_id;
update avaldus set arve_nr=sArve_nr where avaldus_id=nAvaldus_id;
htmldb_util.set_session_state('P63_ARVE_NR',sArve_nr);
else
update arve set arve_nr=nArve_id where arve_id=nArve_id;
update avaldus set arve_nr=nArve_id where avaldus_id=nAvaldus_id;
htmldb_util.set_session_state('P63_ARVE_NR',nArve_id);
end if;
commit;
exception when others then
rollback;
raise;
end;
3.3.5 Füüsiline andmemudel
Kasutaja
Kasutajanimi (PK) : String
Tuup : Boolean
Oigused : String Kursuslane
Parool : String Kursuslane_id (PK) : Integer
Eesnimi : String Kasutajanimi (FK) : String
Perenimi : String Olek : Boolean
1 1
E-mail : String Registreerimise kp : Date
Telefon : String
Aadress : String 1
Isikukood : Integer 1..*
Avaldus
Aval dus_i d (PK) : Integer Valitud kursus
Kursus lane _id (FK) : Integ er Valitud_id (PK) : Integer
Arve_nr (FK) : Integ er Avaldus_id (FK) : Integer
Ma ksja_eesni mi : String Perioodi_id (FK) : Integer
1 Ma ksja_perenim i : String 1 1..* Ainepunktid : Boolean
Ma ksja_is iku kood : Integ er Ainepunkte : Integer
Ol ek : Boo lean
1
1 1
Arve Kursuse periood
Arve_id (PK) Perioodi_id (PK) : Integer
Kursus Kursuse_id (FK) : Integer
Arve_nr : Integer
Kursus e_id (PK) : Integ er Piirang : Integer
Koostamise_kp : Date
Ni metu s : String Tahtaeg : Date
Summa : Integer
Keskkon d : String Algus : Date
Maksetahtaeg : Date
1..* 1 Kirjel dus : Stri ng 1 1 Lopp : Date
Makseviis : String
Ol ek : Boo lean Hind : Integer
Tasutud_kp : Date
Olek : Boolean Programm : String
Ainepunkte : Integer
Joonis 17. Esimese iteratsiooni füüsiline andmemudel.
36

37. 3.4 Realisatsioon
Esimese iteratsiooni raames loodi süsteemi esimene vaheversioon, milles realiseeriti
iteratsiooni käigus teostatud detailanalüüsi ning disaini tulemused rakenduse
põhifunktsionaalsusest kursuslase avalduse sisestamise ja muutmise kohta.
Realiseerimisetapi alguses kaalutleti millised ekraanivormid peaksid välja nägema. Selleks
pakkus Oracle HTML DB välja oma standardiseeritud mooduli, kus andmete sisestamise saab
vormide täitmise lihtsuse huvides jagada osadeks, mille vahel on võimalik navigeerida, et
kontrollida andmed üle ja teha soovi korral muudatusi. Kujunduselt oli võimalik valida mitme
erineva malli vahel.
Andmete sisestamisel on kirjutatud kontrollfunktsioonid, mis ei luba enne järgmisele vormile
edasi liikuda, kui kõik kohustuslikud väljad on täidetud. Sama kehtib piirangute kohta, mis on
kirjutatud trigeritesse ja kontrollivad andmete õigsust. Toimub esmatähtis isikukoodi pikkuse
ja õigsuse kontroll, kus on minimeeritud valede ja väärtusetute andmete andmebaasi
sattumist.
Esialgu lisati kursuse andmed andmebaasi käsitsi, kuna administreerija liidest pole veel
arendatud.
3.5 Iteratsiooni tulemused
Iteratsiooni läbiviimiseks kulus antud töö teostajal täpselt üks nädal nagu planeeritud. Töö
käigus viidi läbi detailanalüüsi- ja disainietapid vaatluse all oleva funktsionaalsuse kohta ja
realiseeriti analüüsitud ja disainitud osa süsteemist.
Vaheversiooni valmimisel näidati seda tulevasele süsteemi kasutuselevõtjale. Senini
realiseeritud funktsionaalsusega oldi rahul ega esitatud lisasoove. Kasutajale teeb võimalus
liikuda avalduse täitmise ajal erinevate sisestusvormide vahel avalduse täitmise mugavaks ja
käepäraseks. Kogu täidetud avalduse kuvamine enne lõplikku sisestamist annab kasutajale
võimaluse vaadata üle sisestatud andmed, mis aitab garanteerida ainult korrektsete andmete
andmebaasi sattumise. Edaspidi arendatakse loodudud kursuslase kasutajaliidest edasi ja
lisatakse sinna süsteemi põhifunktsionaalsusest tulenevaid tegevusi.
Järgmistes iteratsioonides on tarvis kindlustada, et ülejäänud kursuslase kasutajaliidesel
võimalikud tegevused toimuksid ainult selle kasutaja andmetega, kes on parajasti süsteemi
sisenenud.
37

38. Tehnoloogijariski vähendamiseks vaadati iteratsiooni käigus üle esialgne süsteemi arhitektuur
ning otsustati, millised võiksid olla võimalikud vahendid süsteemi realiseerimiseks. Selleks,
et töö oleks arendajale uudne ja huvitav, valiti täiesti uus vahend – Oracle HTML DB
veebipõhine andmebaasi arendusvahend. Samas on sellisel juhul risk alles, mis on uue
süsteemi mitte tundimine, kuid antud töö teenib eelkõige õppimise eesmärki.
38

39. 4. Teise iteratsiooni dokumentatsioon
4.1 Iteratsiooni plaan ja riskianalüüs
Teise iteratsiooni ülesandeks on lisada süsteemi turvalisus. Oluline on eraldada
administraatori ja kursuslase õigused, et kursuslane ei saaks mingil juhul ligipääsu kursuste,
arvete või teiste kursuslaste andmete juurde. Tingimata on tarvis kindlustada, et kursuslase
kasutajaliidesel võimalikud tegevused toimuksid ainult selle kasutaja andmetega, kes on
parajasti süsteemi sisenenud.
Käsitletakse registreeruja süsteemi registreerumise kasutusjuhtu. Lisatakse süsteemi kasutaja
tuvastamise mehhanism, vormide täitmise juhendid ja piirangud andmete sisestamisel.
Süsteemi vaheversiooni loomine on oluline kasutaja õiguste määramise seisukohast, et
vähendada süsteemi turvalisuse riske. Süsteemi lisatakse kasutaja autentimine ja süsteemi
sisenemise ja registreerumise liides ning registreeruja ja kursuslase liideste täiendused
andmete korrektsuse kontrolli (3.2.3) ja kasutaja kontrolliga (4.2.2).
4.2 Analüüsi dokumentatsioon
4.2.1 Kasutusjuhtude diagramm
Administreerija Andmete korrektuse kontroll
(f rom Actors)
Registreerumine
Kasutaja kontroll
Registreeruja
(f rom Actors)
Joonis 18. Teise iteratsiooni kasutusjuhud.
39

40. 4.2.2 Kasutusjuhud laiendatud formaadis
Kasutusjuht: Registreerumine
Tegutsejad: Registreeruja, administreerija; üldisemalt kasutaja.
Eesmärk: Tekitada uus kursuslase või administreerija õigustega kasutaja.
Kirjeldus: Kasutaja sisestab oma andmed, kasutajanime ning parooli. Süsteem salvestab
need, tekitab uue kasutaja ning kuvab registreeruja isikuandmed ja edasi võimaldab koheselt
pääsu süsteemi avalduse esitamiseks ja muudeks toiminguteks.
Administreeruja puhul toimub süsteemi kasutaja õiguste saamine samal põhimõttel, kuid
vorm on kättesaadav salastatud aadressilt ja lisaturvalisuse jaoks on paroolid määratud
kindlaks tööandja poolt.
Eeltingimused: -
Järeltingimused: Tekitatud on kasutaja.
Stsenaarium:
Kasutaja Süsteem
1. Sisestab uue kasutaja loomiseks andmed 2. Kontrollib kas kõik nõutud väljad on
määratud käivitades kasutusjuhu andmete
korrektsuse kontroll (vt 3.2.3).
3. Kontrollib kasutaja poolt sisestatud
andmeid käivitades kasutusjuhu andmete
korrektsuse kontroll.
4. Tekitab uue kasutaja ja salvestab lisatud
andmed andmebaasi.
Kasutusjuht: Kasutaja kontroll
Tegutsejad: Süsteem
Eesmärk: Andmebaasi peavad sattuma võimalikult täielikud ja korrektsed andmed.
Kirjeldus:.Süsteem kontrollib, kas kasutaja andmed on õiged süsteemi sisenemisel.
40

41. 4.2.3 Kursuslase olekudiagramm
regi streeruja regi streerib süsteem i / regi streeruja saab kasutajaõ iguse d sü stee mi s
sisestatakse ebakorrektsed andm ed/ kuvata kse veateade
Registreeruja
kasutaja lisab avalduse/ esimesel korral tekitatakse/edaspidid lisatakse uus kasutaja
andmeid muudetakse / kirje muudetakse
Kursuslane
administreerija kustutab kursuslase/ kursuslane kustutatakse
Joonis 19. Kursuslase olekudiagramm
4.3 Disaini dokumentatsioon
4.3.1 Reaalsed kasutusjuhud
Joonis 20. Süsteemi registreerumise vorm.
Lisamärkus: Registreeruja või kursuslane näeb üleval paremal ainult linki Sisenemine. Antud
vorm on esialgne administreeruja ekraanivorm, kus on näha üleval paremal ka
administreerimise ja kursuslase liidese lingid Administreerimine ja Kursuslane.
41

42. Kasutusjuht: Registreerumine
Tegutsejad: Kursuslane (esmakordsel avalduse sisestamisel registreeruja, sest kursuslast pole
veel loodud), administreerija.
Kirjeldus: Registreeruja sisestab oma andmed, kasutajanime ning parooli. Süsteem salvestab
need, tekitab uue kasutaja ning kuvab registreeruja isikuandmed ja edasi võimaldab koheselt
pääsu süsteemi avalduse esitamiseks ja muudeks toiminguteks. Edaspidi pole tarvis sisestada
muud kui vaid kasutajanimi ja parool.
Administreeruja puhul toimub süsteemi kasutaja õiguste saamine samal põhimõttel, kuid
vorm on kättesaadav salastatud aadressilt ja lisaturvalisuse jaoks on paroolid määratud
kindlaks tööandja poolt.
Käivitatav sündmus: Kursuslane soovib siseneda avalduse kursusele registreerumiseks.
Eeltingimused: -
Järeltingimused: Tekitatud on kasutaja.
Seotud kasutusjuhud: Andmete korrektsuse kontroll (3.2.3) ja kasutaja kontroll (4.2.2).
4.3.2 Füüsiline andmemudel
Kurs uslan e
Kursuslane_id (PK) : Integer
Kasutajanimi (FK) : String
Olek : Boolean
Registreerimise kp : Date
1
1
Kasutaja
Kasutajanimi (PK) : String
Tuup : Boolean Kursus
Oigused : String
Kursuse_id (PK) : Integer
Parool : String
Ni metus : Stri ng
Eesnimi : String
Keskkond : Stri ng
Perenimi : String
1 0..* Kirjel dus : Strin g
E-mail : String
Ol ek : Bool ean
Telefon : String
Aadress : String
Isikukood : Integer
Registreeruja Administreerija
42

43. Joonis 21. Teise iteratsiooni andmemudel.
4.4 Realisatsioon
Teise iteratsiooni raames loodi süsteemi teine vaheversioon, milles realiseeriti iteratsiooni
käigus teostatud detailanalüüsi ning disaini tulemused rakenduse turvalisuse kohta kasutaja
süsteemi registreerumise ja sisenemise osas.
Realiseerimisetapi alguses kaalutleti, kuidas kasutajate turvalisust kõige paremini turvata.
Määrati globaalselt kasutaja õigused, mis lubavad kursuslasel ja administreerijal sisenda vaid
neile vastavasse süsteemi osasse ja kasutajaliidesesse.
Täiendati süsteemi juhiste regiooni lisamisega. Info all on kirjeldatud, mida antud
kasutajaliidese vormil tuleb teha ja millised on alterantiivsed toimingud. Samuti on võimalik
iga välja nimetuse juures klõpsates saada süsteemi poolt infot, mida tuleks konkreetsele
väljale sisestada.
4.5 Iteratsiooni tulemused
Teine iteratsioon õnnestus mahutada ettemääratud ajalistesse raamidesse. Iteratsiooni
läbiviimiseks kulus antud töö teostajal nädal nagu planeeritud. Töö käigus viidi läbi
detailanalüüsi- ja disainietapid vaatluse all oleva funktsionaalsuse kohta ja realiseeriti
analüüsitud ja disainitud osa süsteemist.
Vaheversiooni valmimisel näidati süsteemi tulevasele kasutuselevõtjale. Realiseeritud
funktsionaalsusega oldi rahul ega esitatud mingeid lisasoove. Üldiselt ei ole süsteemi
tulevasel kasutusele võtjal erilisi nõudmisi süsteemi suhtes, vaid süsteemiarendajale on antud
vaba tee tegutseda oma äranägemise järgi. Raskusi tekitatab asjaolu, et süsteemi tulevasel
kasutajal puuduvad igasugused teadmised, millise infoga peab süsteemi arendajat
kindlustama, et süsteemis oleks lõpuks kõik nõutud kriteeriumid täidetud. Seega tuleb
süsteemi projekteerijal väga täpselt formuleerida kõik küsimused süsteemi tulevasele
kasutajale mistahes süsteemi osa nägemuse osas.
Antud iteratsiooni põhieesmärk süsteemis kindlustatada, et kursuslase kasutajaliidesel
võimalikud tegevused toimuvad ainult selle kasutaja andmetega, kes on parajasti süsteemi
sisenenud, on iteratsiooni lõppedes saavutatud ja võib minna edasi järgmiste iteratsioonide
juurde.
43

44. 5. Kolmanda iteratsiooni dokumentatsioon
5.1 Iteratsiooni plaan ja riskianalüüs
Kolmanda iteratsiooni ülesandeks on edasi arendada süsteemi kursuslase osa, kus vaatluse
alla võetakse põhifunktsionaalusest kursuslase avalduse, valitud kursuse ning arve vaatamise
ja otsimisega seotud kasutusjuhud. Samuti käsitletakse kasutaja kontrolli kasutusjuhtu, mis on
juba eelpool defineeritud (vt. 2.3.1). Luuakse vaheversioon kasutajapoolsete testide
läbiviimiseks, et vähendada nõudmistega seotud riske. Täiendatakse süsteemi navigeerimise
plaani, vormide täitmise juhendeid ja piiranguid andmete sisestamisel.
Iteratsioonis võetakse ühe nädala kestusel vaatluse alla järgmised kasutusjuhud:
1) Avalduse vaatamine/otsing;
2) Arve vaatamine/otsing;
3) Kursuse vaatamine/otsing.
Kolmandas iteratsioonis käsitletakse planeerimise dokumentatsioonis identifitseeritud riske
(vt p. 2.2.7). Kasutajapoolsetest võetakse vaatluse alla risk, kus süsteem ei ole kasutajale,
antud iteratsiooni korral kursuslasele, lihtsalt mõistetav.
Antud riskide vähendamiseks kasutatakse järjekordselt süsteemi vaheversiooni loomist, mis
aitab süsteemi kasutusele võtjal olla kursus arendustööga.
5.2 Analüüsi dokumentatsioon
5.2.1 Kasutusjuhtude diagramm
Arve vaatamine/otsing
Kursuslane
Avaldus e vaatamine/otsimine
(f rom Actors)
Kasutaja kontroll
Valitud kursuse vaatamine/ots ing
Joonis 22. Kolmanda iteratsooni kasutusjuhud.
44

45. 5.2.2 Kasutusjuhud laiendatud formaadis
Kasutusjuht: Avalduse vaatamine/otsing
Tegutsejad: Registreeruja
Eesmärk: Avalduse otsingu tulemuse kuvamine
Kirjeldus: Registreeruja otsib avaldust erinevate otsingu parameetrite järgi. Süsteem tagastab
vastava(d) avalduse(d).
Eeltingimused: -
Järeltingimused: -
Stsenaarium:
Kasutaja Süsteem
1. Kursuslane otsib avaldust etteantud 2. Süsteem kuvab otsitud avalduse(d).
parameetrite järgi.
Kasutusjuht: Valitud kursuse vaatamine/otsing
Tegutsejad: Registreeruja
Eesmärk: Valitud kursuse otsingu tulemuste kuvamine.
Kirjeldus: Registreeruja otsib valitud kursusi erinevate parameetrite järgi. Süsteem kuvab
vastava(d) kursuse(d).
Eeltingimused: -
Järeltingimused: -
Stsenaarium:
Kasutaja Süsteem
1. Kursuslane otsib oma valitud kursusi 2. Süsteem kuvab otsitud valitud kursuse(d).
etteantud parameetrite järgi.
Kasutusjuht: Arve vaatamine/otsing
Tegutsejad: Registreeruja
Eesmärk: Arve otsingu tulemuste kuvamine.
Kirjeldus: Registreeruja otsib valitud kursusi erinevate parameetrite järgi. Süsteem kuvab
vastava(d) arve(d).
Eeltingimused: -
Järeltingimused: -
45

46. Stsenaarium:
Kasutaja Süsteem
1. Kursuslane otsib oma arvet etteantud 2. Süsteem kuvab otsitud arve(d).
parameetrite järgi.
Kasutusjuht: Kasutaja kontroll (vt 4.2.2).
5.2.2 Kursuslase olekudiagramm
Registreeruja registreerib süsteemi / registreeruja saab kasutajaõigused süsteemis
Registreeruja sisestatab ebakorrektsed andmed / kuvatakse veateade
Registreeruja
Registreeruja siseneb süsteemi / kontrollitakse kursuslase olemasolu
Kursuslane
Kursuslane muudab andmeid või sisestab uue avalduse/ muudatused salvestatakse
Kursuslast ei eksisteeri/ luua k kursu s e
se lan
Uu s Kursuslane eksisteerib/ kontrollitakse kursuslase andmeid Olemas olev
kursu slan e kursuslane
Kursuslase andmed aeguvad / kursuslane kustutatakse
Joonis 23. Kolmanda iteratsiooni täpsustatud kursuslase olekudiagramm.
46

47. 5.3 Disaini dokumentatsioon
5.3.1 Reaalsed kasutusjuhud
Joonis 24. Kursuslase veebiliidese avaleht.
Lähtuvalt arve ja valitud kursuse otsingu sarnasest ekraanivormi ülesehituse loogikast on
järgnevalt piirdutud avalduse otsimise ekraanivormi näitega.
Joonis 25. Avalduse otsimise ekraanivorm.
Kasutusjuht: Avalduse vaatamine/otsimine.
Tegutsejad: Kursuslane
Kirjeldus: Kursuslane sisestab oma otsingu parameetrid, süsteem kuvab otsitud andmed.
Käivitatav sündmus: Kursuslane soovib otsida sisestatud avalduse andmeid.
Eeltingimused: -
Järeltingimused: -
47