1.

Uopšteno o SSA i kratka istorija

Kod uvođenja IS u neku organizaciju na samom početku potrebno je sagledati sve

procese koji se u njoj dešavaju. U ovoj fazi potrebno je izvršiti samo specifikaciju
određenih zahteva, a ne i sagledavanje načina realizovanja istih. Realizacija zahteva
pripada fazi projektovanja, gde se uzima u obzir realno okruženje, način na koji će se
to realizovati, kao i sam sistem u kome će se implementirati. Zato je vrlo važno da se
u fazi specifikacije ne obraća pažnja na način realizovanja, već samo na analizu
zahteva. Dobro odrađena specifikacija treba da dovede do formiranja modela procesa
posmatrane organizacije na kraju ove faze.
Krajem sedamdesetih godina najpre u Velikoj Britaniji, a zatim i u SAD-u
razvijena je jedna od metoda za analizu sistema pod nazivom Strukturna Sistemska
Analiza (SSA). Kao zvanični tvorci ove metode smatraju se Yourdon i DeMarco, ali
pomagali su im i brojni asistenti. Na samom početku ova metoda se pokazala kao
veoma jednostavna za razumevanje zbog svojih karakteristika koje se ogledaju kroz
lak grafički dizajn i hijerarhijski opis funkcija sistema, što je i bio glavni cilj, jer nije
bila razvijana samo za eksperte u ovoj oblasti, već i za same krajnje korisnike.
Hijerarhijski opis nam omogučuje da sve one procese koji su složeniji raščlanimo na
jednostavnije, a samim tim i učinimo preglednijim i lakšim za razumevanje šta se to
zapravo u njima dešava.
Strukturna sistemska analiza (SSA) predstavlja jednu od metoda za analizu sistema
i zahteva korisnika, tj. služi za modelovanje funkcija sistema.
Sada se postavlja pitanje, zašto je potrebna analiza procesa u organizaciji?
Najčešći odgovor na ovo pitanje leži u samom poslovanju organizacije. Svaka
organizacija može da izvrši unapređenje ili započne neki novi segment svog
poslovanja, a upravo SSA im daje smernice i olakšice u sprovođenju strateških
poslovnih odluka. Kada se u organizaciji detektuju koji su to problemi, onda je lako
videti u kom pravcu treba nastaviti poslovanje kako bi se ti problemi otklonili. Na
kraju se dolazi do zaključka da što se, u fazi analize, realnije i na vreme dogovore
potrebe korisnika i ciljevi organizacije, to će biti bolja i efikasnija upotreba budućeg
IS-a.
Primenom metode SSA treba da se dobije model procesa određene
organizacije, koji će u sebi imati odgovore na sva pitanja vezana za to, koje to
funkcije (procesi) pripadaju ovoj organizaciji, koje su međusobne zavisnosti između
njih, koji su podaci ulazni a koji su to izlazni, šta ti procesi zapravo rade i kuda
obrađeni podaci odlaze. Izgradnja ovog modela je precizno definisana metodom SSA
i ona podleže određenim pravilima, a sve to u cilju globalne jednakosti kako ne bi
svako ponaosob definisao način izgradnje kako to njemu odgovara. Pored funkcija
koje su sastavni deo ovih modela, potrebno je na neki način opisati i strukturu
podataka koji cirkulišu u sistemu. Za ovu svrhu uveden je koncept pod nazivom
Rečnik podataka.
Ono što je karakteristično za metodu SSA je to, da ona IS vidi kao jedan
globalni proces koji ima ulazne podatke, ti podaci se unutar njega mogu obrađivati i
nakon toga oni izlaze iz njega. Unutar IS-a procesi mogu međusobno da razmenjuju
podatke koji se nalaze u tzv. skladištima podataka, ali takođe mogu se razmenjivati
podaci i sa spoljašnjim objektima (interfejsi). Podaci se kreću preko tokova podataka,
koji predstavljaju put preko koga stalno cirkulišu podaci.
Grafička interpretacija ove metode se prikazuje pomoću Dijagrama Tokova Podataka
(DTP).
2. Dijagrami tokova podataka (DTP)
Naziv dijagram tokova podataka, potiče od samog načina na koji on gleda na
funkcije sistema. Naime, on fukcije posmatra na taj način što definiše koji su to
podaci koji ulaze u sistem, gde se to obrađuju i koji su to podaci koji izlaze iz njega.
Ovakav način pristupa nam omogučava da mi uvidimo koji su to procesi koji se
dešavaju unutar sistema, bez toga da smo najpre krenuli od samih procesa pa tek onda
uočili sve prethodno navedeno. Znači, DTP se fokusira kako se podaci kreću kroz
sistem a zatim uočava procese. Ukoliko kvalitetno odradimo DTP onda i krajnji
korisnik ima jasnu sliku o tome kako sistem zapravo funkcioniše.
Osnovni elementi koji se koriste za kreiranje dijagrama tokova podataka su:
procesi, tokovi podataka, skladišta podataka i interfejsi.

2.1. Osnovni elementi dijagrama toka podataka

2.1.1. Proces

Proces predstavlja deo sistema koji ima ulogu da transformiše ulazne podatke u
izlazne.Proces se na grafiku predstavlja elipsom (Slika 1).

Slika 1. Proces
Proces predstavlja određenu radnju ili aktivnost nad podacima, te je zato vrlo
važno uočiti koji su to procesi prisutni u sistemu i dati im simbolično ime koje će nas
asocirati šta oni zapravo rade. Običaj je da se njihov naziv iskaže parom „predikat-
objekat“, međutim ponekada se objekat u nazivu može izostaviti ukoliko je on
očigledan. Neki od naziva elemenata procesa mogu biti: Evidentiranje kandidata,
Izdavanje potvrde o položenom ispitu, Obrada ispita itd. Ulazni podaci za procese
mogu biti različitog tipa. To može biti neka papirna dokumentacija, na primer kada
nego preda dokumenta potrebna za upis ili pristup određenoj organizaciji preko
procesa Učlanjivanje, zatim to može biti neki elektronski vid podataka, na primer
popunjavanje korisničkog naloga kod procesa Logovanje itd.
Ukoliko je funkcionalnost procesa složena onda se on može raščlaniti na
podprocese koji ga detaljnije opisuju, ali prethodno je potrebno uvesti određenu
numeričku notaciju. Ta notacija se ogleda u tome što proces koji se raščlanjuje sadrži
redni broj (npr. 1, 2, 3 ....), a procesi koji ga detaljnije obrađuju sadrže oznaku
procesa koji obrađuju i svoju oznaku (npr. 1.1, 1.2, 2.1, 3.7 ...), i tako redom u
zavisnosti koliko procesa i podprocesa imamo. Važno je napomenuti da ova
numerička notacija ne označava redosled izvršavanja procesa, već samo tzv.
„nasleđivanje“ procesa (ko je roditelj a ko dete proces).

Ono što je takođe karakteristično za procese u nekoj organizaciji jeste to da se oni ne

odvijaju jedan za drugim, već se izvršavaju paralelno. Na primeru funkcionisanja
neke pekare može se uvideti paralelizam odvijanja procesa. Naime, proces se
započinje narudžbinom brašna i svih ostalih potrebnih sastojaka. Zatim se krene sa
izradom testa i pečenjem istog, da bi se na kraju izvršila njegova prodaja. Međutim,
nikada se sa narudžbinom ne čeka dok ne nestane brašna, već se ona unapred obavlja,
a takođe i pečenje ne prestaje kada trenutno imamo hleba u prodaji, već se on unapred
peče. Tako da, može se zaključiti da u jednom trenutku u organizaciji se odvijaju sva
tri procesa: nabavka sastojaka, pečenje hleba i prodaja.
2.1.2. Tok podataka

Tok podataka se tretira kao vod kroz koji stalno teku podaci ili kao pokretna traka
koja stalno prenosi pakete podataka iz jednog dela sistema u drugi, i na taj način
ostvaruje veu imeđu komponenti sistema. Tok podataka se na grafiku predstavlja
pomoću usmerene linije (slika 2).

Slika 2. Tok podataka

Pošto se radi o usmerenoj liniji, to samim tim povlači za sobom činjenicu da tok
podataka prikazuje smer kretanja podataka. To dalje znači da svaki tok podataka mora
da ima lokaciju sa koje polazi i svoju destinaciju (tzv. izvor i ponor). Kao i kod
elementa proces, neophodno je adekvatno imenovanje toka podataka. Nepisano
pravilo je da im se obično pridodaju nazivi na osnovu podataka koje prenose, i da ti
nazivi budu potpuni (bez ikakvih skraćenica). Tako, neki od primera za nazive tokova
podataka mogu biti: PrijavaZaPolaganje, PotvrdaOPlaćanju, ZahtevZaUpis itd.

2.1.3. Skladište podataka

Skladište podataka predstavlja podatke u stanju mirovanja. Skladište podataka se

predstavlja pomoću dve horizontalne linije, između kojih se obično piše naziv
skladišta (slika 3).

Slika 3. Skladište podataka

Nepisano pravilo kod davanja naziva ovog elementa DTP-a je da se koristi množina
imenice tokova podataka koji pristižu u skladište podataka.
Skladišta podataka se mogu simbolički opisati kao određene baze podataka
ukoliko se radi o nekom savremenom sistemu ili organizaciji, a takođe mogu
predstavljati i određene arhive u organizacijama koje još uvek koriste tradicionalni
način poslovanja. Naime, u njima se čuvaju svi relevantni podaci za poslovanje, i u
onom trenutku kada ih sistem treba one su mu uvek na raspolaganju. Obično je da se
dva procesa nikada ne povezuju direktno, već uvek upravo preko skladišta podataka.
Postavlja se pitanje zašto je to tako? Odgovor leži u tome, da zavšetak prethodnog
procesa u nekom lancu odvijanja procesa, ne znači i automatski započinjanje
narednog procesa, već se najpre podaci smeštaju u skladištima podataka i tu stoje sve
dok naredni proces ne bude spreman za njihovu dalju obradu. Na primeru polaganja
vozačkog ispita, kada kandidat preda svu potrebnu dokumentaciju za upis kursa
polaganja, sva papirologija se smešta u skladište Kanditati, a tek nakon isteka nekog
određenog vremena koliko traje obuka, ta dokumenta se koriste kod npr. procesa
Izdavanje potvrde o položenom ispitu, koji će tu dokumentaciju upotrebiti za
popunjavanje potvrde o položenom vozačkom ispitu.

2.1.4. Interfejs

Interfejs predstavlja spoljni objekat sa kojim sistem komunicira. Interfejs se na

grafiku predstavlja pomoću pravougaonika, u kome se upisuje njegov naziv (Slika 4).

Slika 4. Interfejs
Obično se vodi polemika oko toga šta zapravo znači spoljni objekat. Spoljni
objekat se može definisati kao određeno lice, odeljenje pa i čitava organizacija koja
koristi ovaj sistem. U našem primeru, jedan od interfejsa je Kandidat, koji upućuje
razne zahteve ka sistemu, a sistem najpre unutar sebe sprema odgovor (obrađuje
zahteve) i zatim ga šalje kandidatu. Međutim, spoljni objekat može biti i unutar iste
organizacije, ali ne sme biti deo IS. Primer za ovo može biti prodavnica računara i
prateće opreme, koja nudi svojim korisnicima online naručivanje proizvoda. Naplata
se vrši preko posebnog servisa za naplatu, koji nije deo organizacije ali su u tesnoj
poslovnoj vezi i on koristi određene podatke IS organizacije.

2.2. Pravila kreiranja dijagrama toka podataka

Za pravilno kreiranje DTP-a postoje definisana pravila kojih bi se trebalo pridržavati
radi što efikasnijeg kreiranja istog, a i kasnije njegovog lakšeg tumačenja od strane
krajnjeg korisnika sistema koji se modeluje. Pravila i preporuke za kreiranje
Dijagrama tokova podataka su sledeća:
1. Svaki proces mora da ima barem jedan ulazni i jedan izlazni tok podataka.
2. Svaka dva procesa bi trebalo da se povezuju samo posredno preko skladišta
podataka.
3. Tokovi podataka koji idu ka, odnosno od skladišta podataka ne moraju biti
imenovani.
4. Tokovi podataka koji poniru u jedno skladište ili iz njega izviru, mogu da
prenose samo one pakete podataka koji se u skladištu mogu čuvati.
5. Svaki Tok podataka mora da ima izvor i ponor. Iz ovog pravila sledi da dva
interfejsa, dva skladišta, ili interfejs i skladište ne mogu direktno biti povezani
tokom podataka.
6. Svako skladište mora da ima barem jedan ulazni i barem jedan izlazni tok
podataka.
7. Interfejsi moraju biti povezani sa sistemom, odnosno procesima sistema barem
sa jednim ulaznim ili izlaznim tokom podataka.
8. Preporuka vezana za preglednost dijagrama kaže, da se u cilju izbegavanja
nepotrebnog presecanja linija bilo skladište bilo interfejs na jednoj slici može
 višestruko ponoviti. U tom slučaju potrebno je samo pored imena koncepta
dodati znak „*“.

2.3. Hijerarhijska dekompozicija dijagrama tokova podataka

Osnovno pitanje kod analize funkcionisanja nekog sistema jeste kako to da

obuhvatimo sve procese koji se u njemu dešavaju a da to ne bude glomazno i
nerazumljivo. Ovo se može rešiti na dva načina.
Prvi način se ogleda u tome da mi obuhvatimo samo najvažnije procese u
organizaciji i da njih opišemo. Ovakav način se karakteriše obuhvatanjem malog
broja procesa, što samo po sebi povlaći činjenicu da što je nešto nedovoljno
objašnjeno tu je i prostor gde mogu nastati brojni problemi i nejasne situacije. Dakle,
ovakav način realizovanja može dovesti do nekvalitetnog opisa funkcionisanja
sistema u vidu nedovoljno informacija što će za krajnjeg korisnika, koji je u najgorem
slučaju možda i potpuni laik u ovoj oblasti, biti apsolutno neprihvatljivo. Zato se u
praksi najčešće ovaj problem rešava na drugi način.
Drugi, i mnogo bolji način, je da se izvrši određeno raščlanjivanje složenih
procesa na podprocese. Na ovaj način mogu se obuhvatiti svi procesi u organizaciji i
obraditi se do detalja, tako da krajnji korisnik može u potpunosti da razume kako i šta
se to zapravo odvija u samoj organizaciji. Međutim, uvodi se i pojam hijerarhije.
Hijerarhija se ogleda u tome što postoje dijagrami različitih nivoa složenosti. Kod
složenih sistema se najpre krene od opštih dijagrama koji prikazuju IS kao jednu
celinu, i oni prikazuju samo tokove podataka koji se tiču interagovanja spoljašnjih
objekata sa sistemom. Takvi dijagrami se nazivaju dijagami konteksta i oni se
karakterišu svojom grafičkom jednostavnošću i preglednošću. Obično nose naziv
celog IS-a (na primer IS Auto škole RUSN), i od suštinskog je značaja prepoznati sve
ulazne i izlazne tokove iz sistema. Izostavljanje jednog ili drugog može dovesti do
nepravilnog i ne logički korektnog dijagrama tokova podataka, koji u krajnjem slučaju
može da pruži krajnjem korisniku lažni uvid u funkcionisanje organizacije. Daljom
dekompozicijom ovih dijagrama dobijaju se dijagrami nižih nivoa, koji sadrže
podprocese glavnog procesa i koji bolje opisuju njegovu funkcionalnost. Ukoliko su
ovi procesi i dalje nedovoljno jasni i složeni, nastavlja se sa dekompozicijom.
Logično je da se sada postavlja pitanje dokle treba ići sa njom. Onog trenutka kada se
procesi jednostavno ne mogu dalje dekomponovati i kada su svi potrebni procesi do
detalja obrađeni, treba prestati sa dekompozicijom. Ovi procesi se nazivaju
primitivnim procesima, a u nekim literaturama se još nazivaju i atomskim procesima,
po analogiji na to da su oni nešto nedeljivo kako kaže sama definicija atoma.
Primitivni procesi se znači nalaze na dnu hijerarhije, i njihova glavna karakteristika je
da se za razliku od globaljnijih procesa (procesa sa viših nivoa hijerarhije) odvijaju
serijski a ne paralelno.
Na ovaj način mi smo od jednog polaznog i nedovoljno objašnjenog dijagrama, dobili
skup dijagrama pri čemu svaki od njih opisuje određeni segment funkcionisanja i kao
takavnam daje kompletan uvid u stanje organizacije. Na slici 5. prikazan je neki opšti
princip hijerarhijske dekompozicije funkcija sistema.
 Slika 5. Princip hijerarhijske dekompozicije funkcija sistema

2.3.1. Pravila i kriterijumi dekompozicije

Kao što smo u pređašnjem tekstu napomenuli, a bilo je vezano za pravila i preporuke
kreiranja dijagrama tokova podataka, vrlo je važno postići neki zajednički dogovor u
vezi sa pitanjem kako treba nešto izgledati, kojim će to pravilima podlegati i koje će
preporuke biti usvojene. Kako bi se sprečila pojava, da u različitim poslovnim
sferama, svako kreira sopstvenu viziju dekompozicije, postoje sledeća pravila koja se
moraju poštovati:
 Pravilo balansa tokova. Ovo je najznačajnije pravilo i ono glasi: Ulazni i
izlazni tokovi na celokupnom DTP-u koji je dobijen dekompozicijom nekog
procesa P moraju odgovarati ulaznim i izlaznim tokovima toga procesa P na
dijagramu višeg nivoa. Drugim rečima, svi tokovi koji ulaze i izlaze iz procesa
moraju se pojaviti i na DTP sledećeg nivoa, koji taj proces dekomponuje.
 Slika 6. Opšti prikaz Pravila balansa tokova
 Pravilo numerisanja procesa i dijagrama: Potrebna je izvesna numeracija
procesa i dijagrama a u cilju lakšeg snalaženja kako autora dijagrama tako i
krajnjeg korisnika. Opširnije o ovom pravilu opisano je u poglavlju 2.1.1-
Proces.
 Uvođenje novih skladišta podataka. Možemo uvesti nova skladišta na nivoima
niže hijerarhije, bez obzira da li su ona bila prisutna na sledećem višem nivou.
Pravilo za uvođenje novih skladišta glasi: Skladišta se uvode po prvi put na
onom DTP-u na kome predstavljaju vezu između dva ili više procesa. Nakon
što su se pojavila na jednom nivou uz jedan proces, skladišta se moraju
pojavljivati i na svim dijagramima nižeg nivoa koji dekomponuju taj proces.
 Dodatak pravilima dekompozicije. Nepisano pravilo pri dekompoziciji
dijagrama glasi da se svaki proces može dekomponovati najviše u sedam
podprocesa.
 Slika 7. Opšti primer Dijagrama hijerarhijske dekompozicije

3. Rečnik podataka

Nemoguće je započeti priču o pojmu rečnik podataka a da se prethodno ne

pozabavimo time zašto se taj pojam pre svega uvodi u svu ovu priču, zašto je on
toliko bitan i zaslužan za potpuno razumevanje funkcionalnosti jedne organizacije. Do
sada smo najviše pažnje posvetili kreiranju i objašnjavanju dijagrama tokova
podataka, kao i to za šta oni služe. Može se uvideti da i sam naziv dijagram tokova
podataka, spominje podatke u svom nazivu ali u smislu da ova vrsta dijagrama opisuje
kako se podaci kreću kroz sistem, na kojim se to mestima obrađuju i koji su to izlazi.
Ti podaci imaju samo svoje ime i jedino na osnovu njega i svog prethodnog iskustva,
u slučaju eksperta, u ovoj oblasti može se zaključiti o kakvom tipu podataka se tu
radi. Za krajnjeg korisnika, koji recimo nije imao dodirnih tačaka sa nekim od ovih
tokova podataka (recimo narudžbenica, razne vrste potvrda itd.) , ovo može biti
poteškoća jer on ne može sa sigurnošću da tvrdi da struktura tog podatka izgleda baš
tako, već može samo da nagađa. Upravo se zbog ovih problema, uvodi pojam rečnik
podataka koji će sada za razliku od dijagrama tokova podataka da opiše kakve su to
sve strukture moguće kod podataka, ali ne samo kod podataka već i kod skladišta
podataka gde se ti podaci čuvaju. Na taj način mi smo praktično pokrili celu oblast što
se tiće podataka, jer sada imamo nazive podataka, koji nas mogu asocirati koji bi to
podaci mogli biti, ali i u rečniku podataka imamo detaljnu specifikaciju tih podataka
tako da možemo stvoriti sebi u glavi celokupnu sliku o tome. Praktično rečnik
podataka se ne razlikuje bitno po svom konceptu od bilo kog rečnika. Naime, svaki
rečnik sadrži određeni skup reči koji je potanko objašnjen ne bi li tako čitaocu
približilo značenje istih.
Prethodno su bile obrađene razlike između dijagrama tokova podataka i rečnika
podataka, ali ako malo dublje zađemo u samu problematiku možemo uvideti da i kod
rečnika podataka zapravo postoji određena vrsta dekompozicije. Ako tok podataka
posmatramo kao jedan proces, onda su njegove komponente koje ga opisuju zapravo
podprocesi (isto kao kod DTP-a). Iz ovoga može se povući jedna paralela između
dijagrama tokova podataka i samog rečnika podataka. Rečnik podataka se može
definisati recimo na sledeći način:
Rečnik podataka (RP) predstavlja alat za strukturirani opis podataka u sistemu,
odnosno opis njihovog sadržaja i strukture.1

U zavisnosti od same složenosti komponenti koje čine strukturu podataka, mogu

se podeliti na:
 primitivne komponente i
 složene komponente

Primitivne komponente strukture se mogu uporediti sa primitivnim procesima u

smislu da se ni jedni ni drugi ne mogu dalje razlagati, da predstavljaju nešto nedeljivo
i osnovno. Kod strukture podataka se primitivne komponente nazivaju još i poljima.
Tako neki od primera elementarnih komponenti mogu biti u našem slučaju, IME i
PREZIME KANDIDATA, IME RODITELJA, DATUM RODJENJA
KANDIDATA, JMBG itd. Kao što se može videti svi ovi nazivi se ne bi mogli dalje
razlagati. Međutim, postoje određena ograničenja u uzimanju vrednosti ovih
nazovimo promenljivih. Na primer, ime i prezime kandidata može uzimati samo slova
(karaktere tipa string), jmbg može uzimati samo brojeve i slično. Skup iz kojeg
primitivna komponenta može uzimati svoje vrednosti naziva se domenom. Uvodi se
takođe i pojam ograničenje nad domenom koje se može shvatiti kao neko pravilo koje
očekuje da se ispoštuje kod kreiranja tokova podataka ovog tipa. Najčešće se nazivi
polja, njihovi domeni i ograničenja prikazuju pomoću tabela izgleda kao na slici 8. U
ovoj tabeli imamo polja Ime Kandidata, Prezime Kandidata, JMBG i Cena obuke.
Domeni iz kojih oni mogu uzimati vrednosti su tipa CHAR i to ne više od 20
karaktera, tipa INT i to ne više od 13 i tipa REAL, respektivno za svako polje. Jedino
ograničenje koje se ovde uvodi jeste da cena obuke budućih vozača bude veća od
nule, inače u protivnom ne bi imalo nikakvog smisla.
POLJA
NAZIV POLJA DOMEN OGRANIČENJE
Ime Kandidata CHAR(20)
Prezime Kandidata CHAR(20)
JMBG INT(13)
Cena obuke REAL >0
... ... ...
Slika 8. Tabela polja za primer obuke vozača

Naravno da kod složenijih sistema, a i kod većine prostijih, nemamo samo

primitivne komponente strukture podataka. Složena struktura podataka je takva
struktura koja se sastoji iz više primitivnih komponenti, ili može da se sastoji iz
primitivnih komponenti i nekih struktura koje su specifične za tu vrstu podataka.
Najefikasnije je komponente složene strukture objasniti na primeru koji obuhvata
polja i neke složene strukture definisane za taj primer, stoga u daljem tekstu se
objašnjava primer dokumenta Ispitna prijava, koji je neki uopšteni model prijavnice
za polaganje ispita studenata na bilo kom fakultetu. Kao što se vidi ovde imamo
definisane neke tri strukture koje su karakteristične za jedan ovakav dokument, a to su
Podaci o studentu, Podaci o ispitnom roku, Lista predmeta. U strukturu Podaci o

1
„Uvod u informacione sisteme“, FON Beograd. Web url http://uis.fon.bg.ac.yu/
studentu, student unosi sve podatke koji su relevantni za jednog studenta, u strukturu
Podaci o ispitnom roku, student unosi podatke u kom ispitnom roku koje godine
polaže naznačene ispite, a u strukturu Lista predmeta, student unosi nazive ispita koje
želi da polaže. Ovo su neke složene strukture koje se sastoje iz primitivnih
komponenti ili polja. Primeri polja su Broj indeksa, Redni broj, Ispitni rok itd. Takođe
imamo definisano i jedno polje van neke strukture a to je Datum. U tabeli su
iskošenim fontom prikazani podaci koji se menjaju u zavisnosti od podataka, a sve
ostalo predstavlja podatke koji se ne menjaju i oni su sastavni deo ovog dokumenta.
Obrazac za prijavu ispita
Datum: 14. 06. 2008

Podaci o studentu Podaci o ispitnom roku

Broj indeksa: 12345 Način finansiranja: FIB
Ime i prezime: Pera Perić Ispitni rok: junski
Profil/Smer: US/RUS Školska godina: 2007/2008
Godina studija: IV
Lista predmeta
Redni broj NAZIV PREDMETA pismeni usmeni
1. Inženjerska ekonomija x x
2. Projektovanje informacionih sistema x x
3. Internet upravljanje x x
4. Računarom objedinjena proizvodnja x x
5. Inteligentni sistemi i mašine x x
... ... ... ...

Slika 9. Primer složene strukture – Ispitna prijava

Kako bi se izbeglo crtanje ovakvih tabela, pribeglo se drugačijem načinu
predstavljanja struktura podataka. Taj način podrazumeva tekstualni zapis, pri čemu
su prethodno definisana neka pravila kako ne bi došlo do zabune kod onog koji to
čita. Pravila kojima podleže ovakvo predstavljanje rečnika podataka su:

 Agregacija komponenti. Kada imamo neku složenu strukturu koja se sastoji

bilo iz polja ili nekih definisanih složenih komponenti, a da je u obliku liste
podataka, uvodi se notacija <K1, K2,...Kn.>, gde su K1, K2, Kn sastavne
komponente te strukture. Kao na primeru PodaciOStudentu sa slike 9. , to isto
možemo napisati na sledeći način:
PodaciOStudentu: <BrIndeksa, ImePrezime, ProfilSmer, GodinaStudija>

Specijalizacija (unija) komponenti. Specijalizacija predstavlja strukturu u kojoj

se bira jedna (eksluzivna specijalizacija) ili više (neekskluzivna specijalizacija)
od navedenih komponenti (Opcija). Komponente ekskluzivne specijalizacije se
navode unutar uglastih zagrada: [K1, K2,...Kn]. Primer specijalizacije sa
eksluzivnim izborom je skladište podataka PoslovniPartneri:PoslovniPartneri:
<SifraPP, NazivPP, AdresaPP, [ImeKontaktOsobe, Pol]>

Struktura PoslovniPartneri predstavlja agregaciju polja SifraPP, NazivPP,

AdresaPP, i eksluzivne specijalizacije polja ImeKontaktOsobe (u slučaju kada
je poslovni partner pravno lice) i Pol (u slučaju kada je poslovni partner
fizičko lice).
 Komponente neeksluzivne specijalizacije se navode unutar kosih zagrada: /K1,
K2, ...Kn/. Primer specijalizacije u kojoj je moguće izabrati više od jedne
komponente je složeni tok podataka Uverenje:

Uverenje: </ UverenjeOUpisu, UverenjeOPolIspit />

Fakultet može na zahtev studenta da izda bilo uverenje o upisu, bilo uverenje
o položenim ispitima, bilo oba uverenja.

 Skup (Iteracija). Kada imamo ponavljanje jedne komponente više puta, u cilju
smanjenja pisanja jednog te istog uvela se notacija {K 1}, pri čemu je K1
komponenta koja se ponavlja.

ObrazacZaPrijavuIspita: <Datum, BrojIndeksa, ImePrezime, ProfilSmer, GodinaStudija,

NačinFinansiranja, IspitniRok, ŠkolskaGodina {<RedniBroj, NazivPredmeta,Pismeni,
Usmeni>}>

Kao što smo videli, postoji izvesna analogija između dijagrama tokova podataka i
rečnika podataka. Međutim, njihova međusobna glavna razlika je u tome što se
dijagrami tokova podataka bave putanjama kretanja podataka a rečnik podataka
samom strukturom tih podataka.

4. Primer

Na primeru auto škole pod nazivom RUSN, prikazana je praktična primena

metode SSA. Prilikom izrade primera obraćena je pažnja da se obuhvati celokupna
teorijska strana ove metode. Prikazani su svi relevantni dijagrami, kao i sam rečnik
podataka koji opisuje složene tokove podataka.
Manje više je svima poznat način funkcionisanja jedne auto škole. Kandidati za
polaganje popunjavaju zahtev za upis polaganja vozačkog ispita u zavisnosti od
željene kategorije. Zatim se vrši plaćanje obuke,i tada su ispunjeni svi uslovi za
izvršavanje same obuke. Nakon obavljanja obuke, instruktor obaveštava kandidate
kada je datum polaganja vozačkog ispita. Kandidatima je pružena mogućnost
polaganja, kako ispita vezanog za poznavanje saobraćajnih propisa tako i ispita same
vožnje. U zavisnosti od toga da li su položena oba ispita, auto škola izdaje potvrdu na
osnovu koje kandidat može da u mesnom SUP-u izvadi vozačku dozvolu i postane
kvalifikovan za upravljanje vozilomkategorije za koju je stekao istu.
4.1. Dijagrami tokova podataka auto škole
 Slika 9. Dijagram konteksta IS auto škole

Slika 10. Dijagram prvog nivoa dekompozicije

 Slika 11. Dekompozicija procesa Evidentiranje Kanditata

Slika 12. Dekompozicija procesa Obrada ispita

4.2. Dijagram hijerarhijske dekompozicije

 Slika 13. Dijagram dekompozicije IS auto škole

4.3. Rečnik podataka

ZahtevZaUpis: < ImePrezimeKandidata, ImeJednogRoditelja, JMBG, BrojLičneKarte,

DatumRođenjaKandidata, UlicaBrojKandidata, KontaktTelefon, Email, Napomena,
DatumUpisa, Kategorija >
PotvrdaOPlaćanju: < ImePrezimeKandidata, ImeJednogRoditelja, BrojLičneKarte,
UlicaBrojKandidata, DatumIzdavanjaPotvrde, >
PrijavaZaPolaganje: < ImePrezimeKandidata, ImeJednogRoditelja, BrojLičneKarte,
DatumIspita, Kategorija, VrstaIspita >
PotvrdaOPoloženomVozačkomIspitu: < ImePrezimeKandidata, ImeJednogRoditelja,
JMBG, BrojLičneKarte, DatumRođenjaKandidata, UlicaBrojKandidata, DatumPolaganja,
Kategorija >
SpisakKandidataZaPolaganje: < DatumPolaganja, VrstaIspita,{<
RedniBrojKandidata, ImePrezimeKandidata, ImeJednogRoditelja, BrojLičneKarte,
Kategorija > } >
SpisakKandidataKojiSuPoložili: < DatumPolaganja, VrstaIspita, Kategorija,
{< RedniBrojKandidata, ImePrezimeKandidata, ImeJednogRoditelja, BrojLičneKarte,
KojiPut >} >
PodaciOPolazniku: < ImePrezimeKandidata, ImeJednogRoditelja, JMBG,
BrojLičneKarte, DatumRođenjaKandidata, UlicaBrojKandidata, KontaktTelefon, Email,
DatumUpisa, Kategorija, KojiPut >