Analiza sistema i zahteva korisnika

Strukturna sistemska analiza (SSA) je jedna potpuna metodologija za specifikaciju

informacionog sistema, odnosno softvera. Ona se na različite načine može povezati sa
metodama drugih faza u neku specifičnu metodologiju celokupnog razvoja IS.

Tako na primer, ona može biti polazna osnova za metodu strukturnog projektovanja
programa ili projektovanja logičke strukture baze podataka metodom normalizacije ili se
može tretirati kao metodološki postupak dekompozicije nekog sistema na podsisteme sa
ciljem da se, nalaženjem modela podataka podsistema i njihovom integracijom, dođe do
potpunog modela podataka posmatranog sistema.

Upravo, zbog mogućnosti njene raznovrsne primene, metoda SSA se ovde tretira kao
jedinstvena, samosvojna metoda, dok se u drugim materijalima pokazuje kako se ona
koristi u pojedinim koracima standardne metodologije razvoja informacionih sistema.

Potpuna, tačna, formalna i jasna specifikacija IS, ili kako se to obično kaže, specifikacija
zahteva korisnika, zahteva koje budući sistem treba da zadovolji, predstavlja bitan
preduslov za uspešno dalje projektovanje i implementaciju sistema. Očigledno je zbog
čega specifikacija IS treba da bude potpuna i tačna. Zahtev da specifikacija bude
formalna iskazuje se zbog toga što je formalna specifikacija osnov za „transformaciono”
projektovanje i implementaciju, za atomatizovano generisanje baze podataka i programa
iz nje, odnosno za korišćenje CASE sistema. Zahtev da specifikacija bude jasna iskazuje
se zbog toga što u specifikaciji IS u velikoj meri učestvuju korisnici sitema,
neinformatičari, pa jezik specifikacije mora biti i njima prilagođen.

Originalna SSA čiji su tvorci Yourdon i njegovi saradnici (DeMarco i drugi) poseduje
veoma jednostavne, grafičke, pa samim tim i jasne koncepte.

SSA i uvod u bazu podataka

Specifikacija IS treba da prikaže (potpuno, tačno, formalno i jasno) šta budući

informacioni sistem treba da radi. Veoma je bitno odmah istaći da specifikacija IS
prikazuje ŠTA IS treba da dâ, a ne i KAKO to treba da ostvari.

Očigledno je da prerano definisanje "kako", odnosno davanje nekih projektantskih

rešenja u okviru specifikacije, ograničava kasniji mogući izbor (optimizaciju) načina
implementacije sistema.

Odgovor na pitanje „kako" daje se za konkretno okruženje, za definisanu tehnologiju i

organizaciju u kojoj se sistem implementira. Da specifikacija ne bi sadržala tehnološki i
organizaciono ograničena rešenja, obično se kaže da ona treba da opiše funkcionisanje
IS u „idealnoj tehnologiji", gde praktično nikakva ograničenja ne postoje. Ako je
specifikacija ovako zadata, onda je, pre prelaska na dalje projektovanje, neophodno da
se definišu sva ograničenja koja nameće okolina u kojoj se sistem implementira.
Analiza sistema SSA - specifikacija

Specifikacija IS treba da poseduje sledeća dva dela:

1. funkcionalnu specifikaciju u kojoj se opisuje budući IS u „idealnoj tehnologiji",

2. nefunkcionalnu specifikaciju koja definiše sva ograničenja implementacione
okoline.

SSA u potunosti obuhvata samo funkcionalne specifikacije, dok nefunkcionalne samo

delimično pokriva prikazujući tokove podataka u novoimplementiranom sistemu. Ostali
deo nefunkcionalnih specifikacija obično predstavlja samo nabrajanje zahtevanih
performansi budućeg IS i ograničenja implementacione okoline.

SSA posmatra informacioni sistem kao funkciju (proces obrade) koja, na bazi ulaznih,
generiše izlazne podatke. Ulazni podaci se dovode u proces obrade, a izlazni iz njega
odvode preko tokova podataka. Tok podataka se tretira kao vod ili kao pokretna traka
kroz koji stalno teku ili koja stalno nosi podatke na najrazličitijim nosiocima - papirni
dokumenti, niz poruka koje čovek unosi preko tastature terminala, „paket" informacija
dobijen preko neke telekomunikacione linije ili slično.

Imajući u vidu zahtev da specifikacija treba da se oslobodi svih implementacionih detalja

od interesa su samo sadržaj i struktura ulaznog toka, a ne i medijum nosilac toka.

Izvori ulaznih, odnosno ponori izlaznih tokova podataka mogu biti objekti van IS koji sa
IS komuniciraju i koji se u SSA nazivaju interfejsi. Drugi procesi u sistemu ili tzv.
skladišta podataka koja se posmatraju kao „tokovi u mirovanju", odnosno odloženi,
akumulirani tokovi, različite vrste evidencija, arhiva, kartoteka i datoteka.

I za skladišta kao i za tokove od interesa su isključivo njihov sadržaj i struktura.

Simboli

Osnovni koncepti za specifikaciju IS u SSA su, znači, funkcije, odnosno procesi obrade
podataka, tokovi podataka, skladišta podataka i interfejsi. Njihov međusobni odnos se
prikazuje preko dijagrama toka podataka koji prikazuje vezu interfejsa, odnosno
skladišta kao izvora tj. ponora podataka, sa odgovarajućim procesima, kao i međusobnu
vezu procesa.

elipsa predstavlja funkciju ili proces obrade

1.
podataka

2. pravougaonik predstavlja interfejs

3. usmerena linija predstavlja tok podataka

dve paralelne linije ("otvoreni" pravougaonik)

4.
predstavlja skladište podataka

Slika 1: Dijagram tokova podataka

Na dijagramu tokova podataka egzistiraju sledeći grafički simboli:

 1. elipsa koja pretstavlja funkciju ili proces obrade podataka,
2. pravougaonik predstavlja interfejs,
3. usmerena linija predstavlja tok podataka,
4. dve paralelne linije („otvoreni" pravougaonik) predstavlja skladište podataka.

Potpuna specifikacija

IS se sastoji iz mnoštva procesa, interfejsa, tokova i skladišta podataka. Specifikacija IS

treba da bude potpuna (detaljna) i jasna. Kada bi se jedan sistem detaljno opisao i
prikazao jednim DTP-om (Dijagram Toka Podataka), dobio bi se veoma nejasan opis
sistema, paukova mreža procesa, tokova, skladišta i interfejsa. Istovremeno detaljan i
jasan opis sistema zahteva opis na „različitim nivoima apstrakcije", odnosno hijerarhijski
opis u kome se na višim nivoima sistem opisuje opštije, a na nižim, postepenim i
organizovanim uvođenjem detalja, potpuno i detaljno.

Hijerarhijski opis sistema u tehnici DTP se svodi na to da se na višim nivoima definišu

globalniji procesi, a da se zatim svaki takav globalni proces, na sledećem nižem nivou
predstavi novim dijagramom. DTP na vrhu ovakve hijerarhije naziva se dijagram
konteksta, a procesi na najnižem nivou (procesi koji se dalje ne dekomponuju) nazivaju
se primitivni procesi.

Potpunu specifikaciju IS čine:

1. hijerarhijski organizovan skup dijagrama toka podataka,

2. rečnik podataka koji opisuje sadržaj i strukturu svih tokova skladišta
(specifikacija logike primitivnih procesa).

Karakteristike DTP-a

Dijagram toka podatka (DTP) predstavlja model sistema koji sadrži četiri osnovne
komponente: procese obrade podataka (aktivne komponente sistema), objekte
okruženja (interfejse) sa kojima sistem komunicira, skladišta podataka koje procesi
koriste i/ili ažuriraju i tokove podataka koji povezuju ostale komponente sistema u
celinu.

Slika 2: Dijagram toka podataka

Osnovne karakteristike DTP-a su:

  jasna grafička specifikacija, pogodna za komunikaciju sa korisnikom,
 istovremeno jasan i detaljan opis sistema, primenom metode apstrakcije tako da
se sistem na višim nivoima apstrakcije opisuje uopšteno, a na nižim detaljno.

Dekompozicija DTP-a

Slika 3: Dijagram konteksta

Dijagram toka podatka (DTP) na vrhu hijerarhije naziva se dijagram konteksta, a

funkcije na najnižem nivou (procesi koji se dalje ne dekomponuju) nazivaju se primitivne
funkcije.

Primitivne funkcije se detaljnije opisuju koristeći neku vrstu strukturnog prirodnog jezika
odnosno pseudokoda i ovaj opis se naziva specifikacija logike primitivnih procesa.

Pored funkcija mogu se dekomponovati i tokovi i skladišta i oni se opisuju u rečniku

podataka.

Na slici je prikazan primer dekomponovanja procesa B.

Pravila dekompozicije DTP-a

Najznačajnije pravilo koje se mora poštovati pri dekompoziciji procesa je pravilo balansa
tokova.

Ulazni i izlazni tokovi na celokupnom DTP-u koji je dobijen dekompozicijom nekog

procesa moraju odgovarati ulaznim i izlaznim tokovima toga procesa na dijagramu višeg
nivoa.

Pravila za izgradnju DTP:

Slika 4: Dekompozicija DTP pravila

 tok podatka ne može da vezuje dva interfejsa jer bi se na taj način opisivala
komunikacija entiteta van sistema koja nije od interesa,
 tok podatka ne može da vezuje interfejs i skladište jer bi to značilo da entitet van
sistema direktno pristupa nekom skladištu u sistemu bez kontrole nekog procesa
iz sistema koji modelujemo,
 svaki proces mora da ima bar jedan ulazni i jedan izlazni tok podatka. Po pravilu,
i svako skladište bi moralo da ima barem jedan ulazni ili bar jedan izlazni tok,
 ako skladište nema ulazni tok, smatra se da je to izvor podatka izvan sistema koji
posmatrani IS koristi. Ako skladište nema izlazni tok, ono predstavlja izvor
podataka za neki drugi IS.
 svaki interfejs mora da ima bar jedan, bilo ulazni bilo izlazni tok.

Radi razumevanja izložene problematike detaljno će biti analizirana dekompozicije

sistema za studijski primer „Mala trgovina”.
 OtpremnicaKupcu
NarudžbenicaDob
UplataDob
Račun
Katalog IS
Dobavljač FakturaDob Kupac
Mala trgovina
Plaćanja

OtpremnicaDob
NarudžbenicaKupca

Slika 5: Primer dekompozicije sistema Mala trgovina

Opis problema:

Dobavljač povremeno dostavlja Maloj trgovini svoje kataloge sa specifikacijom artikala

koje nudi i njihovim cenama. Na osnovu kataloga i stanja zaliha u skladištu artikala, vrši
se naručivanje preko narudžbenice. Dobavljač dostavlja svoje artikle zajedno sa
otpremnicom i fakturom. Prihvaćena isporuka se plaća. Kupac naručuje artikle preko
narudžbenice. Na osnovu stanja u skladištu artikala roba se isporučuje kupcu uz
otpremnicu i račun. Kupac plaća prihvaćene artikle korišćenjem dokumenta placanja.
Sva dokumenta koja se koriste u nabavci i prodaji, čuvaju se u odgovarajućim
skladištima podataka. Takođe se formira i održava skladište sa podacima o poslovnim
partnerima.

Na dijagramu konteksta su definisana dva interfejsa, objekta van našeg sistema, sa

kojima naš sistem komunicira i to kupac i dobavljač. Prikazani su i tokovi podataka preko
kojih se ova komunikacija obavlja.

Opis DTP:

Dobavljač dostavlja svoje kataloge procesu IS Mala trgovina imenovanim tokom

Katalog. Na osnovu kataloga i stanja zaliha proces IS Mala trgovina naručuje artikle od
interfejsa Dobavljač imenovanim tokom NarudžbenicaDob. Dobavljač na osnovu
narudžbenice dostavlja artikle zajedno sa otpremnicom imenovanim tokom
OtpremnicaDob i fakturom takođe imenovanim tokom FakturaDob. Prihvaćena
isporuka se plaća imenovanim tokom UplataDob. Ovim je komunikacija procesa IS Mala
trgovina i Dobavljač završena. Sa druge strane interfejs Kupac naručuje artikle
imenovanim tokom Narudžbenica kupca. Proces IS Mala trgovina otprema robu kupcu
uz otpremnicu i račun imenovanim tokovima OtpremnicaKupcu i Racun. Kupac plaća
prihvaćene artikle imenovanim tokom Plaćanja.

Nivo II u dekompoziciji sistema

Na slici je prikazana dekompozicija sistema tzv. drugog nivoa. Ako pogledamo konteksni
dijagram (površina obojena crnom bojom), možemo zapaziti da se IS Mala trgovina
može razložiti na dve funkcije i to na proces Nabavke (plavo) i proces prodaje (crno).
 OtpremnicaKupcu
NarudžbenicaDob
UplataDob
Racun
Katalog IS
Dobavljac FakturaDob Kupac
Mala trgovina
Placanja
OtpremnicaDob
NarudžbenicaKupca

Dokumenta Nabavke Poslovni Partner Dokumenta prodaje

NarudžbenicaDob
Artikal
UplataDob
Nabavka
Katalog Prodaja
FakturaDob Katalog

Dobavljac Placanja Otpremnica

OtpremnicaDob Narudžbenica Racun Kupca
Kupca

Kupac

Dokumenta Nabavke Poslovni Partner Dokumenta prodaje

NarudžbenicaDob
Artikal

UplataDob
Nabavka
Katalog Prodaja
FakturaDob Katalog

Dobavljač Plaćanja Otpremnica

OtpremnicaDob Narudžbenica Račun kupca
kupca

Kupac

Slika 6: Dekompozicija sistema II nivoa

U odnosu na konteksni dijagram na ovom nivou su uvedena i skladišta podataka. Svi

tokovi podataka na dijagramu su imenovani sem tokova podataka za skladišta.
Imenovanje tokova podataka za skladišta u suštini samo povećavaju prenatrpanost
dijagrama jer su to imena samih skladišta.

Nivo III u dekompoziciji sistema

Dekompozicija na trećem nivou sama za sebe govori. Čitaocu se prepušta da po

opisanim pravilima analizira dekokomponovanje.
 OtpremnicaKupcu
NarudžbenicaDob
UplataDob
Racun
Katalog IS
Dobavljac FakturaDob Kupac
Mala trgovina
Placanja
OtpremnicaDob
NarudžbenicaKupca

Dokumenta Nabavke Poslovni Partner Dokumenta prodaje

NarudžbenicaDob
Artikal
UplataDob
Nabavka
Katalog Prodaja
FakturaDob Katalog

Dobavljac Placanja Otpremnica

OtpremnicaDob Narudžbenica Racun Kupca
Kupca

Kupac

OtpremnicaDob
OtpremniceDob

Skladiš te artikala
Poslovni
partner 1.3
1.2 Prijem
Naručivanje

Katalog NarudžbeniceDob Prijemnice

1.1
Katalog Obrada 1.4
Poslovni
Kataloga Placanje
Partner

FakturaDob
FaktureDob
UplataDob

OtpremnicaDob
OtpremniceDob

Skladište artikala
Poslovni
partner 1.3
1.2 Prijem
Naručivanje

Katalog NarudžbeniceDob Prijemnice

1.1
Katalog Obrada 1.4
Poslovni
kataloga Plaćanje
partner

FakturaDob
FaktureDob
UplataDob

Slika 7: Dekompozicija sistema – nivo III

Nivo III u dekompoziciji sistema - prodaja

Pravila dekomponovanja su ista kao i na prethodnoj slici, takođe se čitaocima prepušta

analiza datog primera.
OtpremnicaKupcu
NarudžbenicaDob
UplataDob
Racun
Katalog IS
Dobavljac FakturaDob Kupac
Mala trgovina
Placanja
OtpremnicaDob
NarudžbenicaKupca

Dokumenta Nabavke Poslovni Partner Dokumenta prodaje

NarudžbenicaDob Artikal
UplataDob
Nabavka
Katalog Prodaja
FakturaDob Katalog

Dobavljac Placanja Otpremnica

OtpremnicaDob Narudžbenica Racun Kupca
Kupca

Kupac

OtpremnicaDob
Račun
OtpremniceDob
2.2 Otprema Otpremnice
Skladiste artikala
kupca računi
Poslovni Otpremnica
1.3
1.2 Partner Prijem Poslovni
Nalog za partner
Narucivanj otpremu
e Artikal

Katalog NarudžbeniceDob Prijemnice Narudžbenica 2.1 Obrada

kupca porudžbina

Kupac Poslovni
Katalog partner
1.1
1.4 Narudžbenice
Poslovni Obrada kupca
Kataloga Placanje Plaćanja
Partner
FakturaDob Plaćanja 2.3 Naplata
FaktureDob
UplataDob

Račun
2.2 Otprema Otpremnice
kupca računi
Otpremnica
Poslovni
Nalog za partner
otpremu
Artikal

Narudžbenica 2.1 Obrada

kupca porudžbina

Kupac Poslovni
partner
Narudžbenice
kupca
Plaćanja

Plaćanja 2.3 Naplata

Slika 8: Dekompozicija sistema – nivo III - prodaja

Dekompozicija sistema po nivoima

Slika pre svega prikazuje šablonizirani postupak za dekomponovanje realnog sistema.

Dobrom analizom ovog primera i poznavanjem iznešene metodologije SSA, moguće je
postupak primeniti na sve ostale relane sisteme.
 OtpremnicaKupcu
NarudžbenicaDob
UplataDob
Račun
Katalog IS
Dobavljač FakturaDob Kupac
Mala trgovina
Plaćanja
OtpremnicaDob
NarudžbenicaKupca

Dokumenta nabavke Poslovni partner Dokumenta prodaje

NarudžbenicaDob
Artikal

UplataDob

Nabavka
Katalog
Prodaja
FakturaDob
Katalog
Plaćanja
Dobavljač OtpremnicaDob
Otpremnica
Narudžbenica Račun kupca
kupca

Kupac

OtpremnicaDob
Račun
OtpremniceDob
Skladiš te artikala 2.2 Otprema Otpremnice
kupca računi
Poslovni Otpremnica
1.3
partner
Prijem Poslovni
1.2 Nalog za partner
Naruč ivanje otpremu
Artikal

Narudžbenica 2.1 Obrada

kupca porudžbina
Katalog NarudžbeniceDob Prijemnice

Kupac Poslovni
partner
1.1
1.4 Narudžbenice
Poslovni Katalog Obrada
Plaćanje kupca
Partner Kataloga Plaćanja

FakturaDob Plaćanja 2.3 Naplata

FaktureDob
UplataDob

Slika 9: Dekompozicija sistema po nivoima

Pravila kreiranja (sintaksa) DTP - pravilo I i II

Pri kreiranju DTP neophodno je pridržavati se sledećih pravila:

Tok podataka se može zamisliti kao pokretna traka u fabrici ili cev kojom do skladišta
podataka, procesa ili spoljneg objekta teku struktuirani podaci (različita dokumenta,
formulari, tekstovi, knjige, časopisi i slično). Tok podataka ostvaruje vezu između ostalih
komponenti sistema i na DTP-u se predstavlja imenovanim, orijentisanom linijom.

Dokument
Interfejs
Interfejs Dokument
Proces

Skladište Skladište

Dokument
Interfejs
Dokument Interfejs
Proces

Skladište
Skladište

Slika 10: Tok podataka

Tok podataka mora da ima izvor i ponor. Bilo koja druga komponeneta DTP može da
bude izvor ili ponor. Međutim, za jedan tok, bilo izvor, bilo ponor (bilo oba) mora da
bude proces. Drugim rečima, tokovima se ne mogu neposredno povezati dva skladišta,
dva interfejsa, ili skladište i interfejs.

Na slici su prikazani neki nekorektni delovi DTP i to na pvoj slici gde su direktno povezan
interfejs sa skladištem, pored toga što je to nekorektan prikaz delova DTP istovremeno
je i nelogičan, jer u realnom sistemu spoljni objekti nemaju direktan pristup skladištima,
već to obavljaju procesi. U drugom delu je iskazana još jedna nelogičnost i to: direktno
povezivanje interfejsa, objekata van sistema, nekim tokom podataka nije dozvoljeno, jer
pretstavlja opis odnosa objekata van posmatranog sistema, pa nije od interesa. Ako bi
takva veza bila od interesa, odnosno ostvarivala se preko posmatranog sistema, tada bi
se morao definisati proces u posmatranom sistemu koji takvu vezu uspostavlja.

Pravila kreiranja (sintaksa) DTP - pravilo III

Dalje pri kreiranju DTP obavezno je da svaki tok podatka na DTP-u mora imati ime, koje
treba da odražava značenje podataka koje on nosi.

Da bi se ostvarila čitljivost i razumljivost DTP-a, ova imena treba da budu prirodna, a ne

neka specifična, kodirana ili preterano skraćena imena. Izuzetak su tokovi koji idu ka,
odnosno od skladišta podataka koji ne moraju biti imenovani.

Ako tok između procesa i skladišta nije imenovan, podrazumeva se da tok nosi
celokupan sadržaj i strukturu podataka tog skladišta. Ukoliko to nije slučaj, tj. ako tok
sadrži samo deo strukture podataka, treba ga imenovati.

Slika 11: Pravila kreiranja (sintaksa) DTP - pravilo III

Konvencije o imenovanju prikazane su na slici, na kojoj je pretpostavljeno da proces

IZRADA_FAKTURE_KUP preuzima ceo sadržaj i strukturu podataka OTPREMNICE,
dok od svih podataka u skladištu PROIZVOD preuzima samo podatke
USLOVI_PRODAJE. Ako je tok između skladišta i procesa imenovan, imenivana
struktura mora biti deo strukture skladišta, što treba da bude specifikovano u rečniku
podataka.

Pravila kreiranja (sintaksa) DTP - pravilo IV

Tok podataka se može granati.

 Proces 1

Tok A
a) Interfejs 1

Proces 2

Proces 1

Tok A

b) Interfejs 1
Tok A

Proces 2

Slika 12: Granjanje toka podataka

Slika a) eksplicitno prikazuje grananje jednoga toka, dok je na Slici b), ista struktura,
umesto preko grananja prikazana sa dva istoimena toka koja imaju isti izvor, a različite
ponore. Drugim rečima, istoimeni tokovi na DTP u suštini pretstavljaju grananje jednog
toka, pa moraju imati zajednički izvor, a mogu imati različite ponore.

Pravila kreiranja (sintaksa) DTP - pravilo V, VI, VII i VIII

Proces obrade podataka je aktivna komponenta sistema koja vrši transformaciju

strukture i sadržaja ulaznog toka (ili ulaznih tokova) u izlazni tok podataka (ili izlazne
tokove podataka).

Pravilo (V) obezbeđuje da svaki proces ima naziv i oznaku. Naziv procesa treba da
precizno označava funkciju koju on obavlja. Nepisano pravilo kaže da, ako analitičar nije
u stanju da dodeli ime procesu, to samo znači da ne razume funkciju koju proces
obavlja.

Brojna oznaka procesa služi za referenciranje procesa. O načinu dodeljivanja brojne

oznake govoriće se u odeljku o dekompoziciji procesa.

U pravilu (VI) se precizira da svaki proces mora da ima barem jedan ulazni i barem
jedan izlazni tok podataka. Proces bez ulaznog toka generisao bi izlaz niizčega, a proces
bez izlaznog toka je nesvrsishodan.

Pravilo (VII). Po pravilu, svako skladište takođe treba da ima barem jedan ulazni i barem
jedan izlazni tok. Međutim, dozvoljava se da skladište nema ulazni tok, podrazumevajući
da se formira i ažurira u nekom drugom sistemu (mada bi ga tada, možda, logičnije bilo
prikazati kao tok od nekog interfejsa), odnosno da nema izlazni tok, podrazumevajući da
posmatrani sistem formira i ažurira skladište koje se koristi u nekom drugom sistemu.
VIII pravilo definiše da svaki interfejs mora da ima barem jedan, bilo ulazni, bilo izlazni
tok podataka, inače bi bio izolovan od ostalog dela sistema.

Pravila kreiranja (sintaksa) DTP - pravilo IX

Da bi se DTP-ovi lakše crtali, odnosno izbeglo nepotrebno presecanje linija, dozvoljava

se da se jedno skladište ili interfejs, na jednoj slici višestruko ponove. Primer je dat na
slici, gde je ponovljeno skladište DOSIJE_STUDENTA.

Ovo su osnovna, jednostavna pravila za konstrukciju DTP-a. Jedan korektno konstruisan

DTP dat je na slici.

Slika 13: Pravila kreiranja (sintaksa) DTP - pravilo IX