InfosÃ¼steemide Projekteerimise konspekt

Sissejuhatus infosüsteemide loomisesse – õppejõu konspekt 1 

Indrek Sander (2001 sügis) 

Sissejuhatus infosüsteemide loomisesse 

I osa 

Hoiatus! Käesolev materjal on puhtal kujul õppejõu konspekt loengu lugemiseks. Loengu käigus seletatakse 

mõisteid täpsemalt ning tuuakse rohkem näiteid. Ainult selle konspekti põhjal ei tarvitse eksami sooritamine olla 

tulemuslik. 

Sisukord 

1. Infosüsteemi põhimõisted ........................................................... 2 

1.1. Definitsioon ............................................................. 2 

1.2. Informatsioon ............................................................ 2 

1.3. Toimesüsteem vs infosüsteem ................................................ 2 

1.4. Tarkvaratehnika .......................................................... 2 

1.5. IS loomise etapid ......................................................... 2 

1.6. Prototüüpimine ........................................................... 3 

1.7. IS loomise jälgimine ....................................................... 3 

1.8. Memorandum ja diagramm .................................................. 3 

1.9. CASE vahendid .......................................................... 3 

1.10. Info hankimise meetodid ................................................... 4 

2. Tehnikad ....................................................................... 5 

2.1. Suhtlusdiagramm (Task Communication Diagram) ................................ 5 

2.2. Protsessijada (Event driven Process Chains) ..................................... 8 

2.3. Kasutusjuhtum (Use-Case) .................................................. 8 

2.4. Andmevoodiagramm (Data Flow Diagram) .................................... 10 

2.5. Andmetüüpide hierarhia ................................................... 11 

2.6. ER-mudel .............................................................. 11 

2.7. Objektimudel (Class Diagram) .............................................. 12 

2.8. Andmebaasiskeem ....................................................... 14 

2.9. Stsenaariumid ........................................................... 14 

2.10. Sündmuste diagramm (Event Trace Diagram) .................................. 15 

2.11. Olekudiagramm (State Diagram) ........................................... 15 

2.12. Äravisatav prototüüp .................................................... 15 

2.13. Algoritmide kajastamise skeemid ............................................ 16 

Genereeritud: 27.11.2001



1. Infosüsteemi põhimõisted 

1.1. Definitsioon 

Infosüsteem (IS) omab palju enamjaolt sarnaseid määratlusi. 

Tüüpilisim: (Organisatsiooni) infosüsteem on info liikumist ja töötlemist käsitlevate reeglite kogumik 

(organisatsiooni) ülesannete täitmiseks. 

Paljudes definitsioonides on lisatud klausel “ja kasutades selleks kõiki (organisatsiooni) resursse optimaalselt”. 

Tegelikult on tegemist IS’ga ka resursside mitteoptimaalse kasutamise juhul. 

IS on kellegi/millegi oma. Olles millegi oma – valdkonnaspetsiifiline (nt hambaarsti infosüsteem). Olles kellegi 

oma – kogu organisatiooni (peaaegu) kõiki valdkondi haarav. Seega , IS eksisteerib kindlas kontekstis ning omab 

sellest kontekstist tulenevaid iseärasusi. IS loomise juures ongi tähtis nende iseärasuste kindlakstegemine. 

1.2. Informatsioon 

Olemiks loetakse kõike, mis eksisteerib enam-vähem tajutaval kujul ning mida on võimalik temale iseloomulike 

tunnuste väärtuste põhjal eristada teistest samalaadsetest olemitest. Nt elusolendid, asjad, mõisted, 

abstraktsioonid, tegevused. 

Infoks loetakse olemit või väärtust, mis vähendab teadmatust millegi kohta (mingi sündmuse või oleku kohta). 

Tänapäevases kontekstis loetakse infoks arvutisse talletatavaid struktuuri omavaid andmeid, mille hulka võivad 

kuuluda arvandmed, pildid, hääl, video, maakaardid jpm. 

1.3. Toimesüsteem vs infosüsteem 

Kuna infosüsteem iseenesest ei eelda arvutisüsteemi olemasolu, siis eristatakse arvutiseeritud infosüsteeme, mida 

tegelikult vaadeldakse tarkvarana. Täieliku segaduse vältimiseks kutsutakse reaal-elu süsteemi toimesüsteemiks 

(business system). 

IS ei tarvitse hõlmata tervet TS’i. Tüüpiline näide: firmal on olemas IS erijuhu FinantsIS lihtne realisatsioon 

raamatupidamistarkvara näol, aga tegelikke protsesse ei juhita arvutisüsteemi kaudu. 

1.4. Tarkvaratehnika 

Igasuguse tarkvara tegemise saab jagada etappideks: mida teha, kuidas teha, tegemine ise, töölepanek. Need 

etapid on alati olemas (va juhul, kui mingi etapi ajal otsustakse, et edasi enam ei tehta). 

Tarkvara loomisega tegeleb teadusharu nimega Tarkvaratehnikaks (software engineering). 

Etappidel on mitmeid nimesid, kui tüüpiliselt on kõik taandatavad järgmistele: 

analüüs (analysis) 

kavandamine (design) 

programmeerimine (implementing, programming, coding) 

juurutamine (deployment) 

Analüüsi ja kavandamist kokku nimetatakse projekteerimiseks. Inglisekeelses terminoloogias võib see olla veidi 

segadusseajav (kavandamine = design, projekteerimine = design). 

1.5. IS loomise etapid 




IS juures võidakse vahet teha süsteemianalüüsil (system analysis) ja nõuete analüüsil (requirements analysis). 

Esimene tähendab toimesüsteemi analüüsi. See tähendab kas valdkonna (mille IS) või organisatsiooni (kelle IS) 

põhjalikku uurimist. Selle etapi käigus leitakse nõuded, mida esitab toimesüsteem (nn süsteeminõuded). Sinna 

alla kuuluvad süsteemi piirid (kasutusala), organisatsiooni nõuded, juurdepääsu nõuded,töötlemisnõuded. 

Tarkvaranõuded määravad ära hetkel loodava süsteemi. Siia alla kuuluvad funktsionaalsuse nõuded, välisliideste 

nõuded, ohutus- ja turvanõuded, andmete defineerimise ja andmebaasinõuded, installeerimis- ja 

dokumentatsiooninõuded, hooldus- ja ekspluatatsiooninõuded. Selleks kasutatakse Tellimust ehk Ülesande 

püstitust (Statements of Requirements). 

Kavandamise etappi loetakse süsteemi arhitektuuri ja kasutajaliideste kavandamine ning andmebaasi 

projekteerimine. Arhitektuurilt võidakse minna väga detailsete kavandusprojektideni, mis sisaldavad moodulite 

(objektide) funktsionaalsuse kirjeldusi. 

Programmeerimine ja silumine (testimise programmeerimisaegne nimetus). Testimine võidakse sellele etapile 

juurde lisada. Testimine võib olla realiseeritud ka juurutamise osana (st tellija vastava valdkonna spetsialistid 

testivad süsteemi enne üle võtmist). 

Juurutamine sisaldab nii tervikpaigaldamist kui ka täiendavate üksikute töökohtade paigaldamist (tegevusi + 

teadmisi), kasutajate väljaõpet (sh motiveerimist), kasutajatoe organiseerimist, edasiarenduse võimaluste 

organiseerimist. 

1.6. Prototüüpimine 

Tavaliselt vastandatakse etapiviisilisele loomisprotsessile, kuid tegelikult on prototüüpimine suure arvu 

kordustega etapiviisiline lähenemine (veidi dokumenteerimata analüüsi, veidi dokumenteerimata kavandamist, 

programmeerimine, tellijale näitamine ja otsast peale). 

1.7. IS loomise jälgimine 

Vaja aru saada kui kaugel ollakse. Lahenduseks töö jagamine osadeks ning aruandlus. Silt külge, et projekt. 

Kasutatakse projektijuhtimise metoodikaid. Projektijuhtimise kirjandus: Algis Perens “Projekti juhtimine”, 1999. 

Üheinimese näide: mp3-de kataloog ühe ööga. Rohkemate inimeste korral vajalik teadmiste säilitamine kõigile 

arusaadaval kujul. Eesmärgiga, et hiljem ise ja teised suvalisel hetkel suudaksid aru saada ilma ise (uuesti) 

läbimata info kogumise ja analüüsimise protsessi. 

1.8. Memorandum ja diagramm 

Selleks pannakse kogutud (ja töödeldud) info kirja. Vaba tekstina (memorandum) või joonistena e 

diagrammidena. Esimesel juhul tuleb kasutada head liigendamist, viimasel juhul vajalikul määral standardset 

notatsiooni (märgistust, mis määrab, kuidas mingit mõistet joonistada). 

1.9. CASE vahendid 

Suuremate süsteemide juures lähevad kõik diagrammid väga suurteks ning diagrammide omavaheliste seoste 

jälgimiseks on mõistlik kasutada arvuti abi. Vastava tarkvara abil saab säilitada süsteemi analüüsimisel kogutud 

ja töödeldud informatsiooni.Tarkvara kasutamise juures tekivad veel väikesed “lisasoovid” – et saadud teadmisi 

oleks nende säilitamiskujust võimalik viia võimalikult kaugele süsteemi valmimise suunas (nt andmebaasi 

loomiseks). Analüüsimist ja info säilitamist võiks teha ilma arvutita, kuid lisasoovide korral arvutita hakkama 




ei saa. Tavaliselt on selleks spetsiaaltarkvara – nn CASE-vahendid (computer aided software engineering). 

1.10. Info hankimise meetodid 

Info hankimiseks tuleb kasutada ajujõudu ja suhtlemisoskust. Mõlemad omadused on infosüsteemi loojatele väga 

tähtsad. 

1.10.1. Ajurünnak 

3-6 osavõtjat genereerivad kiiresti ideid. Suuline ja kirjalik vorm. 

1.10.2. Mõttekaardistus 

Mõttekaarditus on visuaalne ajurünnak. Mõttekaardistus on hea valdkonnast arusaamiseks, selguse lomiseks, 

ideede genereerimiseks, mõistete kokkukorjamiseks. Mõttekaardistud baseerub vabadel assotsiatsioonidel. Paberi 

keskele kirjutatakse alustusväljend (nt süsteemi nimi, tellija nimi), tõmmatakse ring ümber. Kõrvale kirjutatakse 

esimene uitmõte. Sellele samuti ring ümber ning ühendatakse ringid omavahel joonega. Järgmine uitmõte — 

seotud esimese või teise ringiga või mõlemaga (parem siduda ühega — hilisemas analüüsis on puud kergem 

läbida kui graafi). 

Ükski uitmõte pole halb! Teemast liiga kaugele jõudes mitte edasi minna. Hiljem saab mõttekaardi ette võtta ja 

märksõnad välja noppida. Töövahenditeks on suur paber ja kirjutusvahend. Tegijateks on analüüsijad, ka 

koostöös tellijaga. Suuremate projektide korral võib seda korrata mitmeid kordi. 

Miks paber on parem kui arvuti? 

1.10.3. Intervjuu 

Ettevalmistatud küsimused. Intervjueeritavaid 1-2. Töö stiilis "küsimus-vastus". Kõik vastused (ka triviaalsed) 

kirjutatakse üles. Alustada üldisemast: 

mis on intervjueeritava nimi ja positsioon (ametikoht, seotus)? 

mis on asutuse nimi? 

mis on eesmärgid ja tegevussuunad? 

millised on seosed teiste asutustega? 

Jätkatakse spetsiifilistega. Kui vastuste saamise käigus tekib jooksvalt uusi küsimusi, siis endale kindlasti kirja 

panna ka oma küsimus. 

1.10.4. Valdkonna teadmised ja seadusandlus 

See on kirjaliku info kokkukorjamine. Internet & Riigi Teataja. Asutuse käskkirjad. Omanike visioon 

lähitulevikuks. Teatmeteosed. 

Õppeinfosüsteemi näide mõttekaardistuseks 

Kordamine 

Olgu meil vaja luua programm. Me mõtleme, milline see olla võiks, seejärel mõtleme, kuidas seda teha ning siis 

teeme ära ja paneme käima (analüüs, kavandamine, programmeerimine, juurutamine). Korrates neid samme 

vastavalt vajadusele saame toimiva elujõulise programmi. 

IS korral rääkisime, et analüüs hõlmab natuke laiemat ala – nimelt vaadeldakse IS loomise korral ka konteksti. 

Teostatakse toimesüsteemi analüüs. 

Edasi hakkame vaatama meetodeid, kuidas kahe esimese sammu tegevusi/tulemusi formaliseerida (“paberile 

kanda”). Pärast üksikute sõltumatute tehnikate ülevaatust seome nad kokku IS loomise etappideks või koguni 

terve IS loomise metoodikaks. Jääge meiega! 




2. Tehnikad 

2.1. Suhtlusdiagramm (Task Communication Diagram) 

Suhtlusdiagramm kuulub toimesüsteemi analüüsi alla, kuid TCD’d võib kasutada ka kavandamisel. 

Diagrammi põhiobjektiks on Ülesanne (task). See on tegemist vajav töö (nt arve allkirjastamine, süsteemi 

töötamine) ehk, “mis tuleb teha”. Kas ta ka tehakse, on teine küsimus... 

Ülesandel on 4 põhiparameetrit: 

nimi, toimumistingimus (triggering condition), tegija (performer), kestus (duration) 

Kohustuslikud on nimi (ilmselge miks!) ja tegija (täitja). Miks tegija? Diagrammil jaotatakse ülesanded 

sisemisteks (toimesüsteemi poolt kontrollitavateks) ja välisteks. Jaotus toimub tegija põhjal. Kui tegija on 

süsteemi kuuluv, siis on tegu sisemine. Ühistegevust süsteemi kuuluvate ja väliste tegijate vahel pole! Küll aga 

toimub ühistegevus süsteemi kuuluvate tegijate vahel. 

Ääremärkus: kuna tegu mitte IS, vaid TS analüüsi vahendiga, siis saab IS ise olla üheks tegijaks (kaastegijaks). 

Ülesannet kujutatakse ümarnurkse nelinurgana. Kui tegemist on välise ülesandega, siis joonistatakse nelinurk 

punktiirjoonega. Ülesande nelinurk jaotatakse horisontaalse joonega pooleks. Ülemisse poolde kirjutatakse (eri 

ridadele) kaks esimest põhiparameetrit (nimi ja toimumistingimus), alumisse teised kaks (tegija ja kestus). 

Sisemised ülesanded on kas tavalised või otsusega ülesanded. Otsusega ülesandeid kutsutakse ka jagunemisülesanneteks. 

Otsus tähendab, et ülesande täitmise käigus sõnastakse küsimus ning tehakse vastavalt vastusevariantidele 

otsus. Otsusest tingituna võidakse järgmiseks täitmisele võtta erinevad ülesanded. 

Otsusevariante tähistatakse pikaksvenitatud kuusnurkadega, kuhu on kirjutatud otsuse lühike sõnastus. Otsusevariante 

on alati vähemalt 2 ning nad paigutatakse (üldjuhul) ülesande alla üksteise kõrvale. Otsusvariandid 

seotakse ülesandega, mille juurde nad kuuluvad, tavalise joonega. Diagrammi mõttes on tegu ühe kujundiga 

(ülesanne ja temaga seotud otsusevariandid), mille tüübiks on otsusega ülesanne. 

Miks ülesanded üldse tekivad? Kuidas on nad järjestatud? Selle märkimiseks kasutatakse “sündmuse” mõistet. 

Sündmused on ainukesed üleminekud ühe ülesande juurest teise juurde. 

Sündmuseid on kolme liiki. 

1) Lihtsaim on juhtsündmus. Seda tähistatakse ilma nimeta noolega, mis näitab oma suunaga ülesannete 

järgnevust. Kui ülesandesse siseneb veel teisigi sündmuseid, siis asendatakse temasse sisenevad juhtsündmused 

andme- ehk teatesündmustega. 

2) Teatesündmust võib ette kujutada objektina. Sellise objektina, mis on ühe ülesande väljundiks ja teise 

sisendiks. Teatesündmusel on alati nimi. See nimi kirjeldab ära andmetüübi. Loomulikult ei räägita, et sündmus 

on objekt, vaid, et sündmus kannab objektiga määratud infot. Objekt võib olla materiaalne (asi, kaup) või lihtsalt 

teadaanne, sõnum või korraldus. Tähistatakse noolega, mille juurde on kirjutatud nimi. 

3) Kolmandaks sündmuse liigiks on ajasündmus. See on iseenesest juhtuvate asjade kajastamiseks. Miks meie 

ülesanded üldse üles kerkivad? On kaks võimalust: välise ülesande juurest saabub sündmus (tavaliselt teatesündmus) 

või tekib ajasündmus. Näiteks 8.00 algab tööpäev. Noole algusesse joonistakse kella kujutis (pisike 

ring osutitega) ja kõrvale kirjutatakse definitsioon: “iga 2 minuti järel”, “tööpäeviti”, “8.00”, “8.00 kuni 9.00”. 

Lisaks saab diagrammil kujutada andmekogusid, mis kajastavad pikaajaliselt säilivaid andmeid (vastandina 

sündmuse andmetele, mis tarbitakse ära või transformeeruvad). Andmekogu tähistatakse rööpkülikuna. 

Andmekogu saab kasutada ülesande käigus, seega andmekogu on saab olla seotud ainult ülesannetega. Andmete 

liikumise suunda (ehk, kas andmeid loetakse või sisestatakse/muudetakse/kustutatakse) näitab noole suund. Noole 

ots ei ole mitte harjumuspärane teravik, vaid ringike. Kui ringike (ehk nooleots) on andmekogu poole suunatud, 

siis andmeid kirjutatakse. Kui ülesande käigus toimub mõlemasuunaline andmekogu kasutamine, siis pannakse 

ringike mõlemasse noole otsa (võib teha ka kaks noolt). Ilma nooleotsteta noolt tõlgendatakse kui “määramata” 




või “pole tähtis”. 

Soovitatavalt ei kajastata TCD’l üksikandmeobjekte. Samas on see võimalus siiski olemas – ristkülik. 

Toimimistingimustest näidete põhjal! AND (&), OR ( | ) 

Näited (Tööpäeva kohviga alustamine) 

1) juhtsündmus, ajasündmus 

2) otsustamine, andmekogu 

Sündmus “tööpäeviti 8.00" ootab ülesande “ukse 

taga” kuni vajalik resurss (sekretär) vabaneb (jõuab 

tööle). 

Andmekogust ainult loetakse andmeid. 

3) lisada bossi saabumine tööle (suvalisel ajal), kohvi joomine kohe, otsustamine, kas veel juua, kohvi olemasolu 

kontrollimine, sekretäri hõikamine, sekretäri iseseisev kohvi olemasolu kontroll iga 30 min tagant, bossi 

töötegemine, sekretäri töötegemine katkestustega. 

Kodutöö: Vanaemale külla! 




Detailiseerimine 

Ühe ülesande täpsustamiseks tuleb võtta kõik tema sisendid ja 

väljundid (sündmus+ülesanne). Algatajad ülesanded ja algatatavad 

ülesanded tähistatakse täiendava punktiirjoonega ristkülikuga. 

Neist tõmmatakse sündmused, mille otsad jäävad ripakile. Seejärel 

hakatakse detailiseeritavat ülesannet alamülesannetena lahti 

kirjutama. 

Võimsamad tingimuste kirjeldamise vahendid 

Tingimust vaatlesime siiani kujul: 

 

või 

{ } 

kus operaator on AND või OR 

ja sündmus on ülesande sisendsündmuste hulgast. 

Lisaks võib olla kasutuses märkimine: 

 

kus lisaklausliks võib olla: ALL, , REPEAT 

ALL: tarvitada ülesande jaoks ära kõik sedalaadi sündused 

: tarvitada ülesande jaoks ära täpne arv sedalaadi sündmuseid (nt 3 kohvisoovi) 

REPEAT: korrata ülesannet iga sündmuse tekkimise jaoks (omab mõtet teiste avaldisse pandavate tingimuste 

püsimajätmise korral) 

Lisaks avaldise lisatingimus: WHERE 

nt sündused a, b korral 

a AND b WHERE a.C = b.D 

a OR (b WHERE b.E > 0) 

Mittekohustuslik sündmus, mis tuleb ära tarvitada: a [AND b] 

Vahemiku tarvitamine: muud tingimused AND kohvisoov [AND kohvisoov] 

Hargnevustele saab lisada toimumine tõenäosuse. 

Transaktsioon (TID), notid (ehk any) 

Tegijate tingimused 

Täitjatele võib samuti panna tingimusi 

boss AND sekretär – 

boss [AND sekretär] – 

mõlemad peavad 

kohal olema 

k ui sekretär on 

olemas, 

siis 

kasutada 

boss OR sekretär – üks kahest 

Kuna täitja all mõeldakse ka muud resurssi 

kui inimene, siis on võimalik ka: 

boss AND auto 

tehnik AND (telefon OR auto) 

Saab kasutada nõudeid arvule: 

programmeerija 

ja kompententsile: 

programmeerija WITH COMPETENCY=php 




Ressursid saab panna hierarhiasse. Vastavat infot kajastavat diagrammi nimetatakse ORG-diagrammiks. 

Siis tingimustes saab kasutada punkt-notatsiooni nende tähistamiseks: 

Osakond1.programmeerija AND Osakond1.juhataja AND auto 

sel juhul tähistab ressurs, mida leidub mitmes kohas just nimelt täpsustamata alluvuse juhtu 

Osakond2.juhataja AND programmeerija – ükskõik, mis osakonna programmeerijad 

Sündmuste peale saab panna arvutusvalemeid, mis 

väärtustavad väljundsündmuse andmeid 

väärtustavad ülesannete atribuute 

2.2. Protsessijada (Event driven Process Chains) 

TCD teistsugune esitusvõimalus. On olemas peaaegu üks-ühene vastavus. 

Sündmust joonistatakse kuusnurgana. Jaotused ja ühinemised tehakse läbi ringina kujutatud loogiliste ühenduste. 

Loogilisteks ühendusteks on OR, AND ja XOR (välistav). Viimane tähendab hargnemist või sisendsüdmuste 

korral kindlat väidet, et juhtuda saab ainult üks sündmustest. 

Ring jagatakse pooleks – ülemisse poolde kirjutatakse operaator sisendi ja alumisse poolde väljundi jaoks. 

Üldjuhul on üks neist pooltest tühi. 

Näited: 

2.3. Kasutusjuhtum (Use-Case) 

Kujutatakse süsteemi (või tema alamosa, nt klassi) funktsionaalsust, mis avaldub väliste tegijate suhtluses 

süsteemiga (süsteemi osaga). Eesmärgiks on aru saada, kuidas süsteem paikneb muu maailma suhtes. 

Diagrammi keskne element on süsteemi funktsioon või hulk ühise nimetaja alla kokku võetavaid tegevusi. Seda 

nimetatakse kasutusjuhtumiks (või lihtsalt juhtumiks). Kasutusjuhtum peaks olema arusaadavalt eristatav teistest 

juhtumistest, olema terviklik ning tema kasu (tulemus) peaks olema kas mõõdetav või tajutav. 

Tähistatakse ellipsina. 

Teiseks komponendiks on tegija (actor). Roll antud süsteemi kontekstis. Modelleerimine on alati üldistus, nii ka 

siin! Tegijatena me üldistame inimeste käitumismalle. Mari ja Jüri on kliendid. Nad ostavad midagi. Nad 

üldistakse nime alla Klient. Samas võib Jüri koos Kallega olla partner, kes müüb mingit tooret. Sellesama Jüri 

üldistame Partneriks. Üks füüsiline isik võib olla mitmes rollis. Ühte rolli täidab üldjuhul mitu inimest. 

Tegija on kasutusjuhtumi initsiaatoriks, selles osalejaks ning selle tulemuste tarbijaks. 

Kasutusjuhtum peab olema terviklik – väljastpoolt vaadatuna. Sellest nõudest järeldub kohe meetodi suunitlus 

kliendikesksusele. Toimesüsteemi analüüsi juures on tegijateks organisatasioonist väljapoole jäävad nähtused. 

Nõuete analüüsi juures aga on tegijate hulgas ka töötajad (organisatsiooni ressursid). 

Tegijat tähistatakse kriipsujukuna. UML’is võib teda tähistada nagu iga teist objekti – ristkülikuga. UML’is on 

tegija spetsifitseeritud stereotüübiga . 

Ühel diagrammil võib kujutada: 

a) mingi olemuslikult seotud juhtumite hulka 

b) ühe tegijaga seotud juhtumeid 

c) juhtumid, mis tegelevad samade andmetega 

d) juhtumid, mis on seotud mingi tegijate grupiga 

e) kõige tähtsamad juhtumid 

f) jne.... 




Diagrammi koostamiseks joonistatakse Kasutusjuhtumid ning Tegijad. Tegija seotakse kasutusjuhtumiga lihtsa 

joonega. 

Laiendamine (extend) Tüüpjuhtumi jaoks leidub mingi situatsioon, kus lisanduvad täiendavad tegevused. 

Tüüpjuhtum peab olema terviklik ja täielik ilma täiendusteta – nood on ainult erijuhud! 

Nool on suunatud tüüpjuhtumi poole. 

Sisaldumine (include). Näitab sõltumatut (kapseldatud) juhtumit, mis on kohustuslik, kuid on eristatav. 

Nool on suunatud sisalduva juhtumi poole. Sisalduv juhtum on alati abstraktne ning ei ole kunagi seotud tegijaga 

(sisuliselt on seotud iga konkreetse tüüpjuhtumi tegijatega). 

Panga näide: Tüüpjuhtumid “Anna raha”, “Võta raha” ja “Tee ülekanne” vajavad sisalduvat juhtumit 

“Identifitseeri klient”. 

Üldistamine (generalization) 

Tuletusnool (nooleotsaks on suur seest tühi kolmnurk) otsaga üldistatud juhtumi poole. 

Võimalik ka tegijate üldistamise näitamine. Ettevaatust – mitte minna liiale. See meetod on siiski mõeldud 

suhtlemiseks IS tellijaga ja seega on soovitatav kõiki lisavõimalusi mitte kasutada. 




2.4. Andmevoodiagramm (Data Flow Diagram) 

Funktsionaalne mudel, mis näitab funktsionaalseid seoseid süsteemi sisend-, väljund- ja väliste andmete vahel. 

Võrreldes suhtlusdiagrammiga – AVD omab peaaegu samu komponente, kuid temaga ei saa näidata protsesside 

toimumise järjestust ega tingimusi. Puuduvad tegijad. 

Eesmärk – näidata andmete liikumist (andmevooge) läbi protsesside alates nende tekkitajatest kuni nende 

kasutajateni. 

Komponendid (tähistused Yourdon/DeMarco): 

andmevoog – kannab andmeid (data flow), tähistatakse noolega 

protsess – teisendab andmeid (process), tähistatakse ringiga 

välisobjekt – aktiivne objekt, mis tekitab või kasutab andmeid (actor, object), tähistatakse ristkülikuga 

andmekogu – passiivne objekt, mis hoiab andmeid (data store), tähistatakse 2 parall. hor.joonega 

Protsess 

AVD on nn hierarhiline protsesside mõttes – põhimõtteliselt võib iga protsessi edasi täpsustada (lahti kirjutada). 

Esimene tase – kontekstidiagramm – sisaldab ainult ühe protsessi – süsteemi enda.. Lisaks süsteemile on esimesel 

tasemel süsteemi kontekst (välisobjektid ja (tähtsamad) andmekogud ning sisend/väljund s.o seosed 

välisobjektidega). Järgmisel tasemel täpsustatakse, kuidas selle protsessi sisendist saada väljundit. 

Kõige detailsemal tasemel on protsess mingi kõrvalefektideta funktsioon (arvutuslik, ühe operatsiooni 

sooritamine), mis kirjeldatakse valemina või loomulikus keeles. 

(Välis)Objekt 

Põhjustab andmevooge olles nende tekitaja või tarbija. Objektid määravad AVD piirid – nendes algavad ja 

lõppevad andmevood. Mida objektid teiste objektidega teevad, milline on nende sisemine hingeelu – see ei ole 

AVD ülesanne. 

Andmevoog 

a) näitab andmeid (väärtuseid), mis liiguvad 

b) ei muuda andmeid (väärtuseid) 

c) on ühe objekti või protsessi väljundiks ja teise objekti või protsessi sisendiks 

d) ei ühenda objekte 

e) võib jaguneda – minna mitmele tarbijale 

f) võib liituda teise vooga (tekivad liitandmed) 

Andmekogu 

Andmekogu võimaldab koguda andmeid 

hilisemaks kasutamseks. Andmekogu ei tekita 

mingeid operatsioone. Ta ainult reageerib andmete 

jurdepääsu ja salvestamise käskudele. Andmekogu 

võimaldab juurdepääsu andmetele erinevas 

järjekorras nende loomisele. 

Kõrvaloleval joonisel tähendab ilma nimeta 

andmevoog terve andmekogu etteandmist Hinna 

leidmise protsesile. 

Registrilaadsete infosüsteemide korral on olemas 

ainult operatsioonid lisa-muuda-kustuta ning seega 

on funktsionaalne mudel alates mingist detailsuse 

astmest juba triviaalne. 




2.5. Andmetüüpide hierarhia 

Aluseks on lihtandmetüübid 

(standardtüübid): 

char(n) – tekst maks. pikkusega n 

number(n,p) - arv kogupikkusega n 

(sh koma ja komatagused kohad) 

ning komataguse pikkusega p 

date – kuupäev 

time – kellaaeg 

binary – suvaline baidijada (fail) 

Selle põhjal luuakse liittüübid 

Joonisel toodud näites olgu hinne 

number (1,2,3,4,5). 

2.6. ER-mudel 

Chen 1976 

Olem (entity) 

Atribuut (attribute) – olemi omadus, parameeter, tunnus 

Seos (relationship) 

Olem või atribuut? Vastus: kui tekib olukord, kus atribuut omab atribuute, siis tuleb esialgne atribuut muuta 

olemiks. Kui atribuut omab seost ka teise olemiga, siis jällegi tegu pigem olemiga. 

Seos – rombi sees, verb. Probleem verbi suunatusega (nt “kuulub”). 

Andmete modelleerimist 

nimetatakse ka staatiliseks 

modelleerimiseks. 

Ei kujutata andmete liikumist, 

vaid vajalike andmete 

hoidmist andmebaasis (lõpptulemus). Selleks on vaja aru saada tehnilisel tasemel, missugused on andmed 

(andmetüübid) ja kuidas nad on omavahel seotud. 

Staatiline mudel näitab meie kontekstis süsteemi objektide paigalpüsimist. Teisisõnu, andmete hoidmist. 

Staatilisel mudelil saab vaadelda eri tasemeid: 

Kontseptuaalne ehk loogiline mudel 

Füüsiline mudel (vastab andmebaasile) 

Staatilise mudeli abil kirjeldatakse, mis andmeid peab süsteemi hoidma. Anal üüsi osas on põhirõhk küsimusel 

mis? (mida?). Selle etapi tarbeks ongi kontseptuaalne mudel nimega ER-mudel. Kavandamise faasis tuleb 

ER-mudelis salvestatud info põhjal luua füüsiline andmemudel. 

Mudel kujutab kõiki süsteemi mõisteid, millede andmed (väärtused) vajavad salvestamist (hoidmist), ning 




nendevahelisi seoseid. Mudeli tegemise käigus tuleb need mõisted leida! Leidmisel on aluseks nt mõttekaardistus, 

andmevoodiagramm, suhtlusdiagramm jne. 

Entity-Relationship Diagram (entity = olem, mõiste, objekt; relationship = seos) kirjeldab ära andmebaasi mõistes 

põhikomponendid (objekt = andmebaasi tabel, seos = andmebaasi tabel või välisvõti). 

Mitu detailsuse astet: 

a) Ainult olemid - kõik mõisted, mille kohta on vaja säilitada informatsiooni 

b) Lisatakse olemitevahelised seosed 

c) Olemitele lisatakse atribuudid 

d) Seostele lisatakse täpsustused 

e) Seostele lisatakse atribuudid (tekivad uued olemid, eriti juhul kui vaja seosele lisada seost) 

f) Olemitel fikseeritakse võtmed 

g) Olemite atribuutidele lisatakse tüübid 

Kaks notatsiooni: 

1) Olem – ristkülik, Seos – romb, Atribuut – ring 

2) Olem – ristkülik, mille sees on olemi nimi ja joone all atribuudid, seos – spetsotstega noolnotatsioon 

Seos kui spetsiaalotsaga nool 

Nool näitab seose olemasolu. Noole peale võõib kirjutada seose nime (tegevust näitava verbi või rolli näitava 

nimisõna). Võib kirjutada ka kaks nime (mõlema suuna jaoks oma nimi). 

Nooleotsad 

Olemisse suunduv nooleots näitab maksimaalsust – kas teises otsas oleva olemi ühe esitusega võib olla seotud 

1 või rohkem selle olemi esitusi. 

Võib olla kasutatud ka kaheosaline nooleots. Olemipoolne näitab maksimaalsust, teine minimaalsust (0 või 1). 

Kahe olemi vahel võib olla mitu seost. Näiteks, olemite Töötaja ja Osakond vahel on seosed “töötaja töötab 

osakonnas” ja “töötaja juhib osakonda”. Esimene on üks-mitmele ja teine on üks-ühele seos. 

Reeglid: 

Atribuudi asemel olem 

– võib, kui omab atribuut omaks omakorda atribuute 

– soovitatav, kui atribuut on kasutuses mitmes olemis 

– peab, kui atribuut kordub olemi sees (nt asutuse telefon1, telefon2, telefon3 on halb lahendus) 

Üks-ühele seoses olevate olemite liitmine 

– kaotatakse see olem, kelle poolel on minimaalsus 0 (kui sellist pole, siis vähemtähtsam) 

– kaotatava olemi atribuudid liiguvad allesjääva olemi atribuutideks (võib olla vajalik übernimetamine) 

2.7. Objektimudel (Class Diagram) 

See on staatiline mudel, mille eesmärgiks on näidata erinevate mõistete omavahelisi seoseid. Objektimudeli nimi 

viitab seosele objekt-orienteeritud programmeerimise paradigmaga. 

Objekt on konkreetne esitus, isend. 

Klass on ühesuguste objektide kirjeldus, üldistus. 

(Võrdlus programmeerimisega: klass on tüüp ja objekt on muutuja) 

Ühte klassi kuuluvatel objektidel on ühte liiki omadused – neid (ühe klassi objekte) saab võrrelda. Omadused 

kajastuvad atribuutide ja operatsioonide hulgana. ER-mudeli juures rääkisime ainult atribuutidest. Klass võib 

olla teise klassi alamklassiks (täpsustuseks) ja vastupidi — klass võib olla teisele klassile ülemklassiks 

(üldistuseks). Alamklasse võib olla mitu. 

Näiteks, kolm klassi: Isik, Autor, Laenutaja. Iga laenutaja on isik, seega on klass Laenutaja klassi Isik suhtes 

alamklass ehk klass Isik on klassi Laenutaja ülemklass. 




O-O paradigma võimaldab ka juhtu, kus ka ülemklasse on mitu. Keerukuse tõttu on neid soovitav vältida (vt O-O 

teooriat selgituse saamiseks). 

Klassil on atribuudid, igal objektil on need väärtustatud konkreetsete väärtustega. Ülemklassi atribuudid on 

olemas kõigil tema alamklassidel. Joonisel seega neid ei märgita. Vt Laenutaja eesnimi. 

Klassil on operatsioonid. Sama operatsioon toimib kõigil klassi objektidel ühtemoodi. Alamklassil võib sama 

operatsioon käituda erinevalt. Iga objekt teab oma klassi ning kasutab vastava klassi operatsiooni. 

Näiteks, klassid Laenutus ja Harulduse laenutus. Laenutus omab operatsiooni Pikendamine. Kuna Harulduse 

laenutus on Laenutuse alamklass, siis omab ka tema operatsiooni Pikendamine, kuid viimase sisu on erinev 

(haruldase raamatu laenutamise korral teeb pikendamise operatsioon läbi suurema kontrolli enne uue tähtaja 

määramist või ei luba uut tähtaega määrata). Vrd Laenutaja operatsioon Nimemuutus, Harulduse laenutuse 

operatsioon Tagastamine. 

Seosed 

tavaline seos 

(association) 

osalusseos 

(aggregation) 

tuletus- ehk 

üldistusseos 

(generalization) 

ER’i analoog 

üks objekt (klass) sisaldub teises (nt raamat koosneb sisukorrast ja peatükkidest) 

seosnoole üks ots (romb) viitab tervikule, teine ots näitab sisalduvuse võimalikkust 

(üks, mitu). 

Seos võib levitada operatsiooni. Selleks, et sooritada tervikuga mingit operatsiooni 

võib vaja minna selle operatsiooni käivitamist tema koostisosadel. Nt raamatu 

väljatrükkimiseks tuleb trükkida välja sisukord ning kõik peatükid. Operatsiooni 

levitamist tähistatakse noolega osalusseose kohal, noole peale kirjutatakse 

levitatavad operatsioonid. 

“on sama sorti”-seos (nt laenutaja on isik — tehniliselt: Laenutaja on Isiku 

alamklass, Isik on Laenutaja ülemklass) 

Tähistatakse kolmnurgana üleklassi juures. Täidetud kolmnurk tähendab, et 

alamklassid on lõikuvad (üks üleklassi objekt võib kuuluda mitmesse alamklassi). 

Nt ülemklass Ülikooli inimesed, alamklassid Tudeng ja Õppejõud — sama isik 

võib olla nii tudeng kui ka õppejõud. 

Teoreetiline võimalus: ühel alamklassil võib olla mitu ülemklassi. 




Tingimused 

a) Atribuutide tingimused 

kontrollitingimused (nt Tellimise kuupäev < Tagastamise kuupäev) 

arvutusvalemid (nt Sünnipäeva isikukoodist tuletamise eeskiri) 

b) Seoste tingimused — abstaktsemad: üks seos on teise seose osa (klasside Töötaja ja Osakond vahel on kaks 

seost: "töötatab" ja "juhatab". Teine on esimese osa (juhataja on töötaja)). 

Väljendatakse noolega punktiirjoonega, mille juurde kirjutatakse tingimus. 

2.8. Andmebaasiskeem 

Eelteadmised 

OM: klassi objekti identifitseerimine. Võti, primaarvõti 

Üleminekureeglid (ER'ilt, OM'ilt) 

elimineerida mitu-mitmele seosed 

määrata võtmed 

valida primaarvõtmed 

osalusseosed (OM) lihtseosteks 

lihtseosed välisvõtmeteks 

tuletusseosed elimineerida: kas kaotada ülemklass (atribuudi kanduvad kõigile alamklassidele) või teha seosed 

1-1 seosteks. Viimasel juhul: kui alamklass ei sisalda ühtegi uut atribuuti, siis võib valida, kas lisada alamklassi 

kuulumist tähistav atribuut ülemklassile või panna üleklassi võti alamklassi ainsa(te)ks atribuudiks (üksiti nii 

primaarvõti kui ka välisvõti). 

Lisasammud 

Määrata atribuutide andmetüübid (sealhulgas pikkused, väärtuste puudumise võimalused, automaatsed 

väärtused). 

Määrata seoste (välisvõtmete) käitumine 

Terminoloogia muutus: klass -> (andme)tabel, atribuut -> (andme)väli 

Lisateema: SQL DDL (data definition language) 

create table, alter table, drop table 

2.9. Stsenaariumid 

Sündmus — midagi juhtub: esitatakse soovisedel, soovitakse pikendada tellimust, ... 

Sündmusel võivad olla argumendid (atribuudid): Jüri esitas tellimuse(raamatu kood, kuupäev). Sündmusel ei ole 

kestust (sündmuse töötlusel võib olla kestus). Sündmused võivad üksteisele järgneda (Jüri esitas tellimuse, Jürile 

väljastati raamat) või olla üksteisest sõltumatud (Jaak esitas tellimuse, Jüri esitas tellimuse). 

Sündmuse juhtumine tähendab info (andmete) kandumist ühelt objektilt teisele. Protsess on ühesuunaline. 

Analoogselt objektidega on ka sündmused kogutavad klassidesse. Kuna üksik sündmus omaette pole tähtis, siis 

nimetame edasises sündmusete klasse sündmusteks (objektide Jaak ja Jüri sündmusi nimetame klassi Laenutaja 

sündmusteks). 

Pannakse kirja (kõik)võimalikud juhtumised. 

Stsenaarium 1 

Laenutaja esitas tellimuse( raamat, kuupäev) 

Tellimusele leiti vaba eksemplar( eksemplar ) 

Eksemplar anti laenutajale( tähtaeg ) 

Laenutaja pikendas tellimust ( päevade arv) 




Laenutaja tagastas raamatu( kuupäev) 

Stsenaarium 2 

Laenutaja esitas tellimuse( raamat, kuupäev) 

Tellimusele ei leitud vaba eksemplari 

2.10. Sündmuste diagramm (Event Trace Diagram) 

Tehakse stsenaariumi põhjal. Märgitakse klassid, kes osalevad sündmuste saatmisel ja saamisel. Ülevalt alla 

läheb ajatelg (näitamaks soovitatavat sündnuste järjestust). Püüda teha üks diagramm 2 - 3 klassi jaoks. Kui on 

keerulisem stsenaarium, siis valida välja 2 klassi ning kolmandaks võtta ülejäänud kokku. 

 

2.11. Olekudiagramm (State Diagram) 

Objektid võivad olla paljudes olekutes (seisundites). Oleku määravad atribuudid ja seoste olemasolu teiste 

objektidega. Formaalselt annab iga erinev atribuutide väärtustus uue oleku. Praktikas on vaja teha üldistusi (nt 

temperatuur 12 C ja 13 C võivad tähendada sama olekut) ning elimineerimisi (nt kahe binaarse tunnuse "Tellimus 

esitatud", "Tellimus täidetud" korral saab anda 4 erinevat olekut, kuid tegelikkuses on neid 3). 

Kui objektil on võimalikke olekuid rohkem kui üks, siis on objektil ka põhjused minekuks ühest olekust teise. 

Põhjustajateks on sündmused. 

Olekudiagramm tegeleb ühe objektiga (klassiga) korraga. Diagrammil märgitakse ära objekti erinevad olekud 

ning sündmused, mis viivad objekti ühest olekust teise. Kahe oleku vahele joonistatud sündmus ei sõltu sündmuse 

tekitajast. Konkreetse sündmuse tekitaja saab leida sündmuste diagrammilt (event trace diagram). Objekti võivad 

ühest olekust teise viia mitu erinevat sündmust. 

Diagrammi joonise koostamine. Valida välja objekt, mille käitumine on dünaamiline. Võtta esimeselt sündmuste 

diagrammilt kõik objekti sisendsündmused ning luua neist teekond läbi olekute. Võtta järgmine sündmuste 

diagramm ja toimida samamoodi, vajadusel lisada uusi olekuid. 

Tingimuste lisamine joonisele. Sündmusel ei lasta tekkida, kui tingimus ei kehti. Märgitakse sündmuse nime taha 

nurksulgudesse. 

Operatsioonide lisamine joonisele. Tegevused, mis tehakse kogu aeg, kui objekt on antud olekus. Operatsiooni 

nimi märgitakse oleku sisse märksõna "do:" taha. Tegevus omab kestust. Kui tekib teine sündmus, mis peaks 

objekti sellest olekust ära viima, siis operatsioon peab katkema. Tegevuse täpsem kirjeldus antakse eraldi. Nimeta 

väljuv sündmus märgib automaatset üleminekut operatsiooni lõpu tõttu. 

Lisaks saab märkida ka reaktsioone sündmustele ehk ülesandeid. Nt reaktsioon olekusse sattumisele (entry/) või 

olekust väljakukkumisele (exit/) või muule sündmusele, mis ei vaheta olekut (event/). 

Alamdiagrammid. 

Üldistamine. Sisend- ja väljundpunktide märkimine. 

2.12. Äravisatav prototüüp 

Kui ajutine nähtus, kui meetod teadmisi hankida juhul, kui süsteem on liiga keeruline ja/või tellija ei oska omi 

soove sõnastada. 




2.13. Algoritmide kajastamise skeemid 

Ei ole eksamiteemade hulgas 

2.13.1. Nassi-Schneiderman struktogramm 

for 

do while 

repeat until 

if then else – vinge värk 

2.13.2. JSP (Jackson Structured Programming) 

protsesside hierarhiline jagamine 

2.13.3. E-skeem

InfosÃ¼steemide Projekteerimise konspekt

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?