VISOKA TEHNICKA SKOLA STRUKOVNIH STUDIJA

SEMINARSKI RAD

PREDMET: Operativni sistemi i korisnicki softweri

TEMA: Strukturna Sistemska Analiza (SSA)

Studenti:

Mentori:

Mladen Marjanovic
Andrej Goranovic
Bozidar Popovic

dr. Medenica Miroslav

Strukturna sistemska analiza

2015

1. Uopteno o SSA i kratka istorija

Kod uvoenja IS u neku organizaciju na samom poetku potrebno je sagledati sve
procese koji se u njoj deavaju. U ovoj fazi potrebno je izvriti samo specifikaciju odreenih
zahteva, a ne i sagledavanje naina realizovanja istih. Realizacija zahteva pripada fazi
projektovanja, gde se uzima u obzir realno okruenje, nain na koji e se to realizovati, kao i
sam sistem u kome e se implementirati. Zato je vrlo vano da se u fazi specifikacije ne
obraa panja na nain realizovanja, ve samo na analizu zahteva. Dobro odraena
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
zvanini tvorci ove metode smatraju se Yourdon i DeMarco, ali pomagali su im i brojni
asistenti. Na samom poetku ova metoda se pokazala kao veoma jednostavna za razumevanje
zbog svojih karakteristika koje se ogledaju kroz lak grafiki 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 omoguuje da sve one procese koji su
sloeniji ralanimo na jednostavnije, a samim tim i uinimo preglednijim i lakim za
razumevanje ta se to zapravo u njima deava.
Strukturna sistemska analiza (SSA) predstavlja jednu od metoda za analizu sistema
i zahteva korisnika, tj. slui za modelovanje funkcija sistema.1
Sada se postavlja pitanje, zato je potrebna analiza procesa u organizaciji? Najei
odgovor na ovo pitanje lei u samom poslovanju organizacije. Svaka organizacija moe da
izvri unapreenje ili zapone neki novi segment svog poslovanja, a upravo SSA im daje
smernice i olakice u sprovoenju stratekih 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 zakljuka da to se, u fazi analize,
realnije i na vreme dogovore potrebe korisnika i ciljevi organizacije, to e biti bolja i
efikasnija upotreba budueg IS-a.
Primenom metode SSA treba da se dobije model procesa odreene organizacije, koji
e u sebi imati odgovore na sva pitanja vezana za to, koje to funkcije (procesi) pripadaju ovoj
organizaciji, koje su meusobne zavisnosti izmeu njih, koji su podaci ulazni a koji su to
izlazni, ta ti procesi zapravo rade i kuda obraeni podaci odlaze. Izgradnja ovog modela je
precizno definisana metodom SSA i ona podlee odreenim pravilima, a sve to u cilju
globalne jednakosti kako ne bi svako ponaosob definisao nain izgradnje kako to njemu
odgovara. Pored funkcija koje su sastavni deo ovih modela, potrebno je na neki nain opisati
i strukturu podataka koji cirkuliu u sistemu. Za ovu svrhu uveden je koncept pod nazivom
Renik podataka.
Ono to je karakteristino za metodu SSA je to, da ona IS vidi kao jedan globalni
proces koji ima ulazne podatke, ti podaci se unutar njega mogu obraivati i nakon toga oni
izlaze iz njega. Unutar IS-a procesi mogu meusobno da razmenjuju podatke koji se nalaze u
tzv. skladitima podataka, ali takoe mogu se razmenjivati podaci i sa spoljanjim objektima
(interfejsi). Podaci se kreu preko tokova podataka, koji predstavljaju put preko koga stalno
cirkuliu podaci.
Grafika interpretacija ove metode se prikazuje pomou Dijagrama Tokova Podataka
(DTP).

Uvod u informacione sisteme, FON Beograd. Web url http://uis.fon.bg.ac.yu/

Strukturna sistemska analiza

2015

2. Dijagrami tokova podataka (DTP)

Naziv dijagram tokova podataka, potie od samog naina na koji on gleda na funkcije
sistema. Naime, on fukcije posmatra na taj nain to definie koji su to podaci koji ulaze u
sistem, gde se to obrauju i koji su to podaci koji izlaze iz njega. Ovakav nain pristupa nam
omoguava da mi uvidimo koji su to procesi koji se deavaju unutar sistema, bez toga da smo
najpre krenuli od samih procesa pa tek onda uoili sve prethodno navedeno. Znai, DTP se
fokusira kako se podaci kreu kroz sistem a zatim uoava procese. Ukoliko kvalitetno
odradimo DTP onda i krajnji korisnik ima jasnu sliku o tome kako sistem zapravo
funkcionie.
Osnovni elementi koji se koriste za kreiranje dijagrama tokova podataka su: procesi,
tokovi podataka, skladita podataka i interfejsi.
2.1. Osnovni elementi dijagrama toka podataka
2.1.1. Proces
Proces predstavlja deo sistema koji ima ulogu da transformie ulazne podatke u izlazne. 2
Proces se na grafiku predstavlja elipsom (Slika 1).

Slika 1. Proces

Proces predstavlja odreenu radnju ili aktivnost nad podacima, te je zato vrlo vano uoiti
koji su to procesi prisutni u sistemu i dati im simbolino ime koje e nas asocirati ta oni
zapravo rade. Obiaj je da se njihov naziv iskae parom predikat-objekat, meutim
ponekada se objekat u nazivu moe izostaviti ukoliko je on oigledan. Neki od naziva
elemenata procesa mogu biti: Evidentiranje kandidata, Izdavanje potvrde o poloenom ispitu,
Obrada ispita itd. Ulazni podaci za procese mogu biti razliitog tipa. To moe biti neka
papirna dokumentacija, na primer kada nego preda dokumenta potrebna za upis ili pristup
odreenoj organizaciji preko procesa Ulanjivanje, zatim to moe biti neki elektronski vid
podataka, na primer popunjavanje korisnikog naloga kod procesa Logovanje itd.
Ukoliko je funkcionalnost procesa sloena onda se on moe ralaniti na podprocese koji
ga detaljnije opisuju, ali prethodno je potrebno uvesti odreenu numeriku notaciju. Ta
notacija se ogleda u tome to proces koji se ralanjuje sadri redni broj (npr. 1, 2, 3 ....), a
procesi koji ga detaljnije obrauju sadre oznaku procesa koji obrauju i svoju oznaku (npr.
1.1, 1.2, 2.1, 3.7 ...), i tako redom u zavisnosti koliko procesa i podprocesa imamo. Vano je
napomenuti da ova numerika notacija ne oznaava redosled izvravanja procesa, ve samo
tzv. nasleivanje procesa (ko je roditelj a ko dete proces).
Ono to je takoe karakteristino za procese u nekoj organizaciji jeste to da se oni ne
odvijaju jedan za drugim, ve se izvravaju paralelno. Na primeru funkcionisanja neke pekare
moe se uvideti paralelizam odvijanja procesa. Naime, proces se zapoinje narudbinom
2

Uvod u informacione sisteme, FON Beograd. Web url http://uis.fon.bg.ac.yu/

Strukturna sistemska analiza

2015

brana i svih ostalih potrebnih sastojaka. Zatim se krene sa izradom testa i peenjem istog, da
bi se na kraju izvrila njegova prodaja. Meutim, nikada se sa narudbinom ne eka dok ne
nestane brana, ve se ona unapred obavlja, a takoe i peenje ne prestaje kada trenutno
imamo hleba u prodaji, ve se on unapred pee. Tako da, moe se zakljuiti da u jednom
trenutku u organizaciji se odvijaju sva tri procesa: nabavka sastojaka, peenje 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 nain ostvaruje veu
imeu komponenti sistema.3 Tok podataka se na grafiku predstavlja pomou usmerene linije
(slika 2).

Slika 2. Tok podataka

Poto se radi o usmerenoj liniji, to samim tim povlai za sobom injenicu da tok podataka
prikazuje smer kretanja podataka. To dalje znai 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 obino pridodaju nazivi
na osnovu podataka koje prenose, i da ti nazivi budu potpuni (bez ikakvih skraenica). Tako,
neki od primera za nazive tokova podataka mogu biti: PrijavaZaPolaganje,
PotvrdaOPlaanju, ZahtevZaUpis itd.
2.1.3. Skladite podataka
Skladite podataka predstavlja podatke u stanju mirovanja.4 Skladite podataka se
predstavlja pomou dve horizontalne linije, izmeu kojih se obino pie naziv skladita (slika
3).

Slika 3. Skladite podataka

Nepisano pravilo kod davanja naziva ovog elementa DTP-a je da se koristi mnoina
imenice tokova podataka koji pristiu u skladite podataka.

3
4

Uvod u informacione sisteme, FON Beograd. Web url http://uis.fon.bg.ac.yu/

Uvod u informacione sisteme, FON Beograd. Web url http://uis.fon.bg.ac.yu/

Strukturna sistemska analiza

2015

Skladita podataka se mogu simboliki opisati kao odreene baze podataka ukoliko se
radi o nekom savremenom sistemu ili organizaciji, a takoe mogu predstavljati i odreene
arhive u organizacijama koje jo uvek koriste tradicionalni nain 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. Obino je da se dva procesa nikada ne povezuju direktno, ve uvek
upravo preko skladita podataka. Postavlja se pitanje zato je to tako? Odgovor lei u tome,
da zavetak prethodnog procesa u nekom lancu odvijanja procesa, ne znai i automatski
zapoinjanje narednog procesa, ve se najpre podaci smetaju u skladitima podataka i tu
stoje sve dok naredni proces ne bude spreman za njihovu dalju obradu. Na primeru polaganja
vozakog ispita, kada kandidat preda svu potrebnu dokumentaciju za upis kursa polaganja,
sva papirologija se smeta u skladite Kanditati, a tek nakon isteka nekog odreenog vremena
koliko traje obuka, ta dokumenta se koriste kod npr. procesa Izdavanje potvrde o poloenom
ispitu, koji e tu dokumentaciju upotrebiti za popunjavanje potvrde o poloenom vozakom
ispitu.
2.1.4. Interfejs
Interfejs predstavlja spoljni objekat sa kojim sistem komunicira. 5 Interfejs se na grafiku
predstavlja pomou pravougaonika, u kome se upisuje njegov naziv (Slika 4).

Slika 4. Interfejs

Obino se vodi polemika oko toga ta zapravo znai spoljni objekat. Spoljni objekat se
moe definisati kao odreeno lice, odeljenje pa i itava organizacija koja koristi ovaj sistem.
U naem primeru, jedan od interfejsa je Kandidat, koji upuuje razne zahteve ka sistemu, a
sistem najpre unutar sebe sprema odgovor (obrauje zahteve) i zatim ga alje kandidatu.
Meutim, spoljni objekat moe biti i unutar iste organizacije, ali ne sme biti deo IS. Primer za
ovo moe biti prodavnica raunara i pratee opreme, koja nudi svojim korisnicima online
naruivanje proizvoda. Naplata se vri preko posebnog servisa za naplatu, koji nije deo
organizacije ali su u tesnoj poslovnoj vezi i on koristi odreene podatke IS organizacije.
2.2. Pravila kreiranja dijagrama toka podataka
Za pravilno kreiranje DTP-a postoje definisana pravila kojih bi se trebalo pridravati radi
to efikasnijeg kreiranja istog, a i kasnije njegovog lakeg tumaenja od strane krajnjeg
korisnika sistema koji se modeluje. Pravila i preporuke za kreiranje Dijagrama tokova
podataka su sledea: 6
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 skladita podataka.
3. Tokovi podataka koji idu ka, odnosno od skladita podataka ne moraju biti imenovani.
5
6

Uvod u informacione sisteme, FON Beograd. Web url http://uis.fon.bg.ac.yu/

Uvod u informacione sisteme, FON Beograd. Web url http://uis.fon.bg.ac.yu/

Strukturna sistemska analiza

2015

4. Tokovi podataka koji poniru u jedno skladite ili iz njega izviru, mogu da prenose
samo one pakete podataka koji se u skladitu mogu uvati.
5. Svaki Tok podataka mora da ima izvor i ponor. Iz ovog pravila sledi da dva interfejsa,
dva skladita, ili interfejs i skladite ne mogu direktno biti povezani tokom podataka.
6. Svako skladite 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 kae, da se u cilju izbegavanja
nepotrebnog presecanja linija bilo skladite bilo interfejs na jednoj slici moe
viestruko ponoviti. U tom sluaju 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 deavaju a da to ne bude glomazno i nerazumljivo. Ovo se moe
reiti na dva naina.
Prvi nain se ogleda u tome da mi obuhvatimo samo najvanije procese u organizaciji i
da njih opiemo. Ovakav nain se karakterie obuhvatanjem malog broja procesa, to samo
po sebi povlai injenicu da to je neto nedovoljno objanjeno tu je i prostor gde mogu
nastati brojni problemi i nejasne situacije. Dakle, ovakav nain realizovanja moe dovesti do
nekvalitetnog opisa funkcionisanja sistema u vidu nedovoljno informacija to e za krajnjeg
korisnika, koji je u najgorem sluaju moda i potpuni laik u ovoj oblasti, biti apsolutno
neprihvatljivo. Zato se u praksi najee ovaj problem reava na drugi nain.
Drugi, i mnogo bolji nain, je da se izvri odreeno ralanjivanje sloenih procesa na
podprocese. Na ovaj nain mogu se obuhvatiti svi procesi u organizaciji i obraditi se do
detalja, tako da krajnji korisnik moe u potpunosti da razume kako i ta se to zapravo odvija u
samoj organizaciji. Meutim, uvodi se i pojam hijerarhije. Hijerarhija se ogleda u tome to
postoje dijagrami razliitih nivoa sloenosti. Kod sloenih sistema se najpre krene od optih
dijagrama koji prikazuju IS kao jednu celinu, i oni prikazuju samo tokove podataka koji se
tiu interagovanja spoljanjih objekata sa sistemom. Takvi dijagrami se nazivaju dijagami
konteksta i oni se karakteriu svojom grafikom jednostavnou i preglednou. Obino nose
naziv celog IS-a (na primer IS Auto kole RUSN), i od sutinskog je znaaja prepoznati sve
ulazne i izlazne tokove iz sistema. Izostavljanje jednog ili drugog moe dovesti do
nepravilnog i ne logiki korektnog dijagrama tokova podataka, koji u krajnjem sluaju moe
da prui krajnjem korisniku lani uvid u funkcionisanje organizacije. Daljom
dekompozicijom ovih dijagrama dobijaju se dijagrami niih nivoa, koji sadre podprocese
glavnog procesa i koji bolje opisuju njegovu funkcionalnost. Ukoliko su ovi procesi i dalje
nedovoljno jasni i sloeni, nastavlja se sa dekompozicijom. Logino je da se sada postavlja
pitanje dokle treba ii sa njom. Onog trenutka kada se procesi jednostavno ne mogu dalje
dekomponovati i kada su svi potrebni procesi do detalja obraeni, 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 neto nedeljivo kako kae
sama definicija atoma7. Primitivni procesi se znai nalaze na dnu hijerarhije, i njihova glavna
karakteristika je da se za razliku od globaljnijih procesa (procesa sa viih nivoa hijerarhije)
odvijaju serijski a ne paralelno.
Na ovaj nain mi smo od jednog polaznog i nedovoljno objanjenog dijagrama, dobili
skup dijagrama pri emu svaki od njih opisuje odreeni segment funkcionisanja i kao takav
7

Atom je nedeljiva estica. (Web url http://bs.wikipedia.org/wiki/Atom)

Strukturna sistemska analiza

2015

nam daje kompletan uvid u stanje organizacije. Na slici 5. prikazan je neki opti princip
hijerarhijske dekompozicije funkcija sistema.8

Slika 5. Princip hijerarhijske dekompozicije funkcija sistema

2.3.1. Pravila i kriterijumi dekompozicije

8

Slika preuzeta iz Uvod u informacione sisteme, FON Beograd. Web url http://uis.fon.bg.ac.yu/

Strukturna sistemska analiza

2015

Kao to smo u preanjem tekstu napomenuli, a bilo je vezano za pravila i preporuke

kreiranja dijagrama tokova podataka, vrlo je vano postii neki zajedniki dogovor u vezi sa
pitanjem kako treba neto izgledati, kojim e to pravilima podlegati i koje e preporuke biti
usvojene. Kako bi se spreila pojava, da u razliitim poslovnim sferama, svako kreira
sopstvenu viziju dekompozicije, postoje sledea pravila koja se moraju potovati:9
Pravilo balansa tokova. Ovo je najznaajnije 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 vieg
nivoa. Drugim reima, svi tokovi koji ulaze i izlaze iz procesa moraju se pojaviti i na
DTP sledeeg nivoa, koji taj proces dekomponuje.

Slika 6. Opti prikaz Pravila balansa tokova

Pravilo numerisanja procesa i dijagrama: Potrebna je izvesna numeracija procesa i

dijagrama a u cilju lakeg snalaenja kako autora dijagrama tako i krajnjeg korisnika.
Opirnije o ovom pravilu opisano je u poglavlju 2.1.1- Proces.
Uvoenje novih skladita podataka. Moemo uvesti nova skladita na nivoima nie
hijerarhije, bez obzira da li su ona bila prisutna na sledeem viem nivou. Pravilo za
uvoenje novih skladita glasi: Skladita se uvode po prvi put na onom DTP-u na
kome predstavljaju vezu izmeu dva ili vie procesa. Nakon to su se pojavila na
jednom nivou uz jedan proces, skladita se moraju pojavljivati i na svim dijagramima
nieg nivoa koji dekomponuju taj proces.
Dodatak pravilima dekompozicije. Nepisano pravilo pri dekompoziciji dijagrama
glasi da se svaki proces moe dekomponovati najvie u sedam podprocesa.

Uvod u informacione sisteme, FON Beograd. Web url http://uis.fon.bg.ac.yu/

Strukturna sistemska analiza

2015

2.3.2. Dijagram hijerarhijske dekompozicije

Kao to smo ve napomenuli, rezultat hijerarhijske dekompozicije procesa neke
organizacije treba da rezultira odreenim skupom dijagrama tokova podataka koji do detalja
opisuju funkcionisanje iste. U zavisnosti od toga koliko je samo funkcionisanje organizacije
kompleksnije, utoliko je i broj tih dijagrama vei. Sve u svemu, glavni cilj dijagrama
hijerarhijske dekompozicije je da omogui kako samom autoru tako i krajnjem korisniku
olakano snalaenje u itanju ovih dijagrama. Princip dijagrama hijerarhijske
dekompozicije je veoma slian konceptu sadraja bilo koje literature. Naime, sadraj nam
pokazuje poglavlja i sadraj tih poglavlja po podnaslovima. Na isti nain, ovaj dijagram nam
pokazuje na koje podprocese se to glavni proces deli (oznaavaju se brojevima 1,2,3,...,N,
gde je N broj podprocesa), zatim koji su to podpodprocesi koji pripadaju nekom od ovih
podprocesa (oznaavaju se sa 1.1, 1.2, ...,1.M; 2.1, 2.2, ..., 2.Q; N.1, N.2, ..., N.P, gde su
M,Q,P broj popodprocesa) i tako redom.
Napomena koja ovde vai jeste da ovo numerisanje nikako ne oznaava raspored
odvijanja ovih procesa, ve samo prikazuje pripadnost procesa sa nieg procesu sa vieg
hijerarhijskog nivoa.
Slika 7. daje opti prikaz jednog dijagrama hijerarhijske dekompozicije.

Slika 7. Opti primer Dijagrama hijerarhijske dekompozicije

10

Strukturna sistemska analiza

3.

2015

Renik podataka

Nemogue je zapoeti priu o pojmu renik podataka a da se prethodno ne pozabavimo

time zato se taj pojam pre svega uvodi u svu ovu priu, zato je on toliko bitan i zasluan za
potpuno razumevanje funkcionalnosti jedne organizacije. Do sada smo najvie panje
posvetili kreiranju i objanjavanju dijagrama tokova podataka, kao i to za ta oni slue. Moe
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 kreu kroz sistem, na kojim se to
mestima obrauju i koji su to izlazi. Ti podaci imaju samo svoje ime i jedino na osnovu njega
i svog prethodnog iskustva, u sluaju eksperta, u ovoj oblasti moe se zakljuiti o kakvom
tipu podataka se tu radi. Za krajnjeg korisnika, koji recimo nije imao dodirnih taaka sa
nekim od ovih tokova podataka (recimo narudbenica, razne vrste potvrda itd.) , ovo moe
biti potekoa jer on ne moe sa sigurnou da tvrdi da struktura tog podatka izgleda ba
tako, ve moe samo da nagaa. Upravo se zbog ovih problema, uvodi pojam renik
podataka koji e sada za razliku od dijagrama tokova podataka da opie kakve su to sve
strukture mogue kod podataka, ali ne samo kod podataka ve i kod skladita podataka gde se
ti podaci uvaju. Na taj nain mi smo praktino pokrili celu oblast to se tie podataka, jer
sada imamo nazive podataka, koji nas mogu asocirati koji bi to podaci mogli biti, ali i u
reniku podataka imamo detaljnu specifikaciju tih podataka tako da moemo stvoriti sebi u
glavi celokupnu sliku o tome. Praktino renik podataka se ne razlikuje bitno po svom
konceptu od bilo kog renika. Naime, svaki renik sadri odreeni skup rei koji je potanko
objanjen ne bi li tako itaocu pribliilo znaenje istih.
Prethodno su bile obraene razlike izmeu dijagrama tokova podataka i renika podataka,
ali ako malo dublje zaemo u samu problematiku moemo uvideti da i kod renika podataka
zapravo postoji odreena vrsta dekompozicije. Ako tok podataka posmatramo kao jedan
proces, onda su njegove komponente koje ga opisuju zapravo podprocesi (isto kao kod DTPa). Iz ovoga moe se povui jedna paralela izmeu dijagrama tokova podataka i samog
renika podataka. Renik podataka se moe definisati recimo na sledei nain:
Renik podataka (RP) predstavlja alat za strukturirani opis podataka u sistemu, odnosno
opis njihovog sadraja i strukture.10
U zavisnosti od same sloenosti komponenti koje ine strukturu podataka, mogu se
podeliti na:
primitivne komponente i
sloene komponente
Primitivne komponente strukture se mogu uporediti sa primitivnim procesima u
smislu da se ni jedni ni drugi ne mogu dalje razlagati, da predstavljaju neto nedeljivo i
osnovno. Kod strukture podataka se primitivne komponente nazivaju jo i poljima. Tako neki
od primera elementarnih komponenti mogu biti u naem sluaju, IME i PREZIME
KANDIDATA, IME RODITELJA, DATUM RODJENJA KANDIDATA, JMBG itd. Kao to
se moe videti svi ovi nazivi se ne bi mogli dalje razlagati. Meutim, postoje odreena
ogranienja u uzimanju vrednosti ovih nazovimo promenljivih. Na primer, ime i prezime
kandidata moe uzimati samo slova (karaktere tipa string), jmbg moe uzimati samo brojeve i
slino. Skup iz kojeg primitivna komponenta moe uzimati svoje vrednosti naziva se
domenom. Uvodi se takoe i pojam ogranienje nad domenom koje se moe shvatiti kao
neko pravilo koje oekuje da se ispotuje kod kreiranja tokova podataka ovog tipa. Najee
10

Uvod u informacione sisteme, FON Beograd. Web url http://uis.fon.bg.ac.yu/

11

Strukturna sistemska analiza

2015

se nazivi polja, njihovi domeni i ogranienja prikazuju pomou 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 vie od 20 karaktera, tipa INT i to
ne vie od 13 i tipa REAL, respektivno za svako polje. Jedino ogranienje koje se ovde uvodi
jeste da cena obuke buduih vozaa bude vea od nule, inae u protivnom ne bi imalo
nikakvog smisla.

POLJA
NAZIV POLJA
Ime Kandidata
Prezime Kandidata
JMBG
Cena obuke
...

DOMEN
CHAR(20)
CHAR(20)
INT(13)
REAL
...

OGRANIENJE

>0
...

Slika 8. Tabela polja za primer obuke vozaa

Naravno da kod sloenijih sistema, a i kod veine prostijih, nemamo samo primitivne
komponente strukture podataka. Sloena struktura podataka je takva struktura koja se sastoji
iz vie primitivnih komponenti, ili moe da se sastoji iz primitivnih komponenti i nekih
struktura koje su specifine za tu vrstu podataka. Najefikasnije je komponente sloene
strukture objasniti na primeru koji obuhvata polja i neke sloene strukture definisane za taj
primer, stoga u daljem tekstu se objanjava primer dokumenta Ispitna prijava, koji je neki
uopteni model prijavnice za polaganje ispita studenata na bilo kom fakultetu. Kao to se vidi
ovde imamo definisane neke tri strukture koje su karakteristine za jedan ovakav dokument, a
to su Podaci o studentu, Podaci o ispitnom roku, Lista predmeta. U strukturu Podaci o
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 polae naznaene
ispite, a u strukturu Lista predmeta, student unosi nazive ispita koje eli da polae. Ovo su
neke sloene strukture koje se sastoje iz primitivnih komponenti ili polja. Primeri polja su
Broj indeksa, Redni broj, Ispitni rok itd. Takoe imamo definisano i jedno polje van neke
strukture a to je Datum. U tabeli su iskoenim 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

12

Strukturna sistemska analiza

2015

Datum: 14. 06. 2008

Podaci o studentu

Podaci o ispitnom roku

Broj indeksa: 12345

Ime i prezime: Pera Peri
Profil/Smer: US/RUS
Godina studija: IV

Nain finansiranja: FIB

Ispitni rok: junski
kolska godina: 2007/2008

Lista predmeta
Redni broj
NAZIV PREDMETA
pismeni
1.
Inenjerska ekonomija
x
2.
Projektovanje informacionih sistema
x
3.
Internet upravljanje
x
4.
Raunarom objedinjena proizvodnja
x
5.
Inteligentni sistemi i maine
x
...
...
...
Slika 9. Primer sloene strukture Ispitna prijava

usmeni
x
x
x
x
x
...

Kako bi se izbeglo crtanje ovakvih tabela, pribeglo se drugaijem nainu predstavljanja

struktura podataka. Taj nain podrazumeva tekstualni zapis, pri emu su prethodno definisana
neka pravila kako ne bi dolo do zabune kod onog koji to ita. Pravila kojima podlee ovakvo
predstavljanje renika podataka su:

Agregacija komponenti. Kada imamo neku sloenu strukturu koja se sastoji bilo iz
polja ili nekih definisanih sloenih 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 moemo napisati na sledei nain:
PodaciOStudentu: <BrIndeksa, ImePrezime, ProfilSmer, GodinaStudija>

Specijalizacija (unija) komponenti.11 Specijalizacija predstavlja strukturu u kojoj se

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

Struktura PoslovniPartneri predstavlja agregaciju polja SifraPP, NazivPP, AdresaPP,

i eksluzivne specijalizacije polja ImeKontaktOsobe (u sluaju kada je poslovni partner
pravno lice) i Pol (u sluaju kada je poslovni partner fiziko lice).
Komponente neeksluzivne specijalizacije se navode unutar kosih zagrada: /K 1,
K2, ...Kn/. Primer specijalizacije u kojoj je mogue izabrati vie od jedne komponente
je sloeni tok podataka Uverenje:
Uverenje: </ UverenjeOUpisu, UverenjeOPolIspit />

Fakultet moe na zahtev studenta da izda bilo uverenje o upisu, bilo uverenje o
poloenim ispitima, bilo oba uverenja.

11

Uvod u informacione sisteme, FON Beograd. Web url http://uis.fon.bg.ac.yu/

13

Strukturna sistemska analiza

2015

Skup (Iteracija). Kada imamo ponavljanje jedne komponente vie 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,
NainFinansiranja, IspitniRok, kolskaGodina {<RedniBroj, NazivPredmeta,Pismeni, Usmeni>}>

Kao to smo videli, postoji izvesna analogija izmeu dijagrama tokova podataka i
renika podataka. Meutim, njihova meusobna glavna razlika je u tome to se dijagrami
tokova podataka bave putanjama kretanja podataka a renik podataka samom strukturom tih
podataka.

4. Primer
14

Strukturna sistemska analiza

2015

Na primeru auto kole pod nazivom RUSN, prikazana je praktina primena metode SSA.
Prilikom izrade primera obraena je panja da se obuhvati celokupna teorijska strana ove
metode. Prikazani su svi relevantni dijagrami, kao i sam renik podataka koji opisuje sloene
tokove podataka.
Manje vie je svima poznat nain funkcionisanja jedne auto kole. Kandidati za
polaganje popunjavaju zahtev za upis polaganja vozakog ispita u zavisnosti od eljene
kategorije. Zatim se vri plaanje obuke,i tada su ispunjeni svi uslovi za izvravanje same
obuke. Nakon obavljanja obuke, instruktor obavetava kandidate kada je datum polaganja
vozakog ispita. Kandidatima je pruena mogunost polaganja, kako ispita vezanog za
poznavanje saobraajnih propisa tako i ispita same vonje. U zavisnosti od toga da li su
poloena oba ispita, auto kola izdaje potvrdu na osnovu koje kandidat moe da u mesnom
SUP-u izvadi vozaku 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

15

Strukturna sistemska analiza

2015

Slika 10. Dijagram prvog nivoa dekompozicije

Slika 11. Dekompozicija procesa Evidentiranje Kanditata

16

Strukturna sistemska analiza

2015

Slika 12. Dekompozicija procesa Obrada ispita

4.2. Dijagram hijerarhijske dekompozicije

Slika 13. Dijagram dekompozicije IS auto kole

17

Strukturna sistemska analiza

2015

4.3. Renik podataka

ZahtevZaUpis: < ImePrezimeKandidata, ImeJednogRoditelja, JMBG, BrojLineKarte,

DatumRoenjaKandidata, UlicaBrojKandidata, KontaktTelefon, Email, Napomena, DatumUpisa,
Kategorija >
PotvrdaOPlaanju:
<
ImePrezimeKandidata,
UlicaBrojKandidata, DatumIzdavanjaPotvrde, >
PrijavaZaPolaganje:

<
ImePrezimeKandidata,
DatumIspita, Kategorija, VrstaIspita >

ImeJednogRoditelja,

BrojLineKarte,

ImeJednogRoditelja,

BrojLineKarte,

PotvrdaOPoloenomVozakomIspitu: < ImePrezimeKandidata, ImeJednogRoditelja, JMBG,

BrojLineKarte, DatumRoenjaKandidata, UlicaBrojKandidata, DatumPolaganja, Kategorija >

SpisakKandidataZaPolaganje: < DatumPolaganja, VrstaIspita,{<

ImePrezimeKandidata, ImeJednogRoditelja, BrojLineKarte, Kategorija > } >

RedniBrojKandidata,

SpisakKandidataKojiSuPoloili: < DatumPolaganja, VrstaIspita, Kategorija,

{< RedniBrojKandidata, ImePrezimeKandidata, ImeJednogRoditelja, BrojLineKarte, KojiPut >} >

PodaciOPolazniku: < ImePrezimeKandidata, ImeJednogRoditelja, JMBG, BrojLineKarte,

DatumRoenjaKandidata, UlicaBrojKandidata, KontaktTelefon, Email, DatumUpisa, Kategorija,
KojiPut >

18