UVOD U INFORMACIONE SISTEME SSA SISTEMSKA STRUKTURNA ANALIZA

Visoka kola BLC Colegge Banja Luka

Uvod u informacione sisteme Skripta Strukturna sistemska analiza 1.Strukturna sistemska analiza.......................................................................................................3 1.1.Uvod.....................................................................................................................................3 1.1.1.Sadraj..........................................................................................................................3 1.1.2.Ciljevi............................................................................................................................4 1.2.Analiza sistema....................................................................................................................4 1.2.1.Sistem............................................................................................................................4 1.2.2.Analiza sistema.............................................................................................................5 1.2.3.Modelovanje sistema....................................................................................................6 1.2.3.1.Model sistema........................................................................................................6 1.2.3.2.Metoda modelovanja.................................................................................................7 1.3.Strukturna sistemska analiza...............................................................................................8 1.3.1.Osnovni koncepti strukturne sistemske analize..........................................................8 1.3.2.Dijagrami tokova podataka..........................................................................................10 1.3.2.1.Proces.........................................................................................................................10 1.3.2.2.Tok podataka.............................................................................................................11 1.3.2.3.Skladite podataka.....................................................................................................11 1.3.2.4.Interfejs......................................................................................................................12 1.3.3.Pravila i preporuke za kreiranje DTP...........................................................................13 1.3.4.Dekompozicija dijagrama tokova podataka.................................................................15 1.3.4.1.Dijagram konteksta....................................................................................................16 1.3.4.2.Primitivni procesi......................................................................................................18 1.3.4.3.Pravila i kriterijumi dekompozicije...........................................................................18 1.3.4.4.Dijagram hijerarhijske dekompozicije......................................................................21 1.3.5.Rijenik podataka.........................................................................................................22 1.3.5.1.Primitivne komponente strukture..............................................................................22 1.3.5.2.Sloena struktura podataka........................................................................................23 1.3.6.Postupak modelovanja..................................................................................................24 Logiki i fiziki modeli procesa............................................................................................25 1.3.6.1.Modelovanje logikog modela procesa.....................................................................25 1.4.Ostali pristupi za modelovanje funkcija sistema.................................................................26 1.4.1.Konvencionalni pristupi...............................................................................................27 1.4.2.Savremeni pristupi........................................................................................................27 1.4.2.1.Pristupi za specifikaciju softvera...............................................................................27 1.4.2.2.Pristupi za modelovanje poslovnih procesa..............................................................28 1.5.Primjer-studija sluaja.........................................................................................................29 1.5.1.Opis okruenja sistema.................................................................................................29 1.5.1.1.Specifikacija svrhe informacionog sistema...............................................................29 1.5.1.2.Dijagram konteksta....................................................................................................30 1.5.2.Opis ponaanja sistema.................................................................................................30 1.5.2.1.Dijagrami tokova podataka.......................................................................................30 1.5.2.2.Dijagram dekompozicije...........................................................................................33 1.5.2.3.Rijenik podataka......................................................................................................33 1.6.Rezime.................................................................................................................................34 1.7.Pitanja...................................................................................................................................34 2.Koriena i preporuena literatura..............................................................................................36

Strana

2/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza 1. Strukturna sistemska analiza 1.1. Uvod

Glavni cilj razvoja, odnosno uvoenja informacionog sistema (IS) je da se informaciono podre sutinski procesi koji se odvijaju u jednoj organizaciji potrebni za ostvarenje njenih ciljeva. Iz tog razloga je na samom poetku razvoja IS neophodno utvrditi koji su to sutinski procesi u organizaciji koje treba podrati, a to drugim rijeima znai, postaviti sljedee pitanje: ta budui informacioni sistem u pogledu funkcija treba da radi da bi ispunio zahtjeve korisnika, odnosno pomogao u ostvarenju ciljeva organizacije? Analiza sistema i zahtijeva korisnika, kao prva faza u ivotnom ciklusu razvoja IS, ima za cilj da odgovori na ovo pitanje. Posmatrajui sistem sa aspekta njegovih funkcija, kao rezultat ove faze i ujedno kao odgovor na postavljeno pitanje dobija se model procesa posmatranog sistema. Strukturna sistemska analiza predstavlja jednu od metoda za analizu sistema i zahtjeva korisnika, odnosno za modelovanje funkcija sistema. Ona je najire koriena metoda za analizu sistema u okviru konvencionalnog strukturnog pristupa razvoju IS. Razvijena krajem sedamdesetih godina, ona je uz modifikacije dugo godina predstavljala dio standardne metodologije za razvoj IS u vladi Velike Britanije, a takoe je u osnovi standarda dravnih organa SAD za modelovanje funkcija. Glavna karakteristika ove metode ogleda se u mogunosti hijerarhijskog opisa procesa sistema, tj. postupnom dekomponovanju kompleksnih procesa sistema na podprocese. SSA za opis procesa definie skup jednostavnih grafikih koncepata, imajui u vidu injenicu da u analizi sistema i zahteva korisnika uestvuju i krajnji korisnici sistema. Ako se jedna grupa italaca (konkretno mislei na budue i sadanje inenjere organizacije menadere) ve nakon kratkog uvodnog dijela pita kakvu korist ona ima od ovog poglavlja kada se sve odnosi samo na informatiare, sljedee reeno pogaa ba njih. Analiza sistema, odnosno modelovanje funkcija ne mora de facto da znai samo funkcionalnu specifikaciju sistema, kao osnovu procesa razvoja IS. Modeli (poslovnih) procesa se mogu iskoristiti za simuliranje i analizu funkcionisanja realnog poslovnog sistema i otkrivanje uskih grla poslovanja. Time modeli funkcija sistema igraju znaajnu ulogu u procesu (re)inenjeringa poslovanja, odnosno poslovnih procesa u organizaciji. Takoe, dokumentovani modeli poslovnih procesa organizacije pruaju osnovu za standardizaciju poslovanja u cilju uvoenja sistema kvaliteta. Isto tako modeli poslovnih procesa pronalaze primjenu i kod obuke zaposlenih, pri emu doprinose bazi znanja jedne organizacije. Konano, gledajui sa suprotne strane, linija menadmenta odluuje o tome da li e se i koje funkcije jednog IS uvesti u organizaciju, pa se poznavanje metoda za analizu sistema, odnosno modelovanja procesa vidi kao prednost u komunikaciji sa strunjacima iz IT-a. to se potrebe krajnjih korisnika IS i ciljevi menadmenta organizacije u fazi analize sistema realnije i tanije iskau, to e efektivnija biti upotreba budueg IS u smislu zadovoljenja postavljenih organizacionih ciljeva. 1.1.1. Sadraj Ovo poglavlje se bavi strukturnom sistemskom analizom, kao metodom za analizu, odnosno modelovanje funkcija sistema. Zbog toga se na samom poetku jedno poglavlje posveuje osnovnim konceptima u analizi, odnosno modelovanju sistema. Zatim slijedi detaljno bavljenje metodom SSA. S jedne strane se uvode osnovni koncepti metode SSA koji ine alat za modelovanje funkcija, dok se sa druge strane objanjava nain i postupak njihovog korienja. Nakon glavnog dijela koji razmatra SSA, daje se saet pregled ostalih pristupa za modelovanje funkcija sistema, podijeljen na konvencionalne i savremene pristupe. Primjer studija sluaja u kojoj se modeluju funkcije jedne e-prodavnice kompletira poglavlje o metodi SSA.

Strana

3/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza 1.1.2. Ciljevi Konkretan cilj poglavlja je upoznavanje Strukturne sistemske analize, kao konvencionalne metode za modelovanje funkcija sistema. Ne samo kroz navoenje osnovnih koncepata i pravila izgradnje modela definisana ovom metodom, nego i kroz diskutovanje primjene i opteg postupka modelovanja, italac moe ovladati tehnikom strukturne analize sistema, koja e mu omoguiti da na postupan nain analizira sisteme razliitih nivoa sloenosti i proizvede odgovarajue modele. Opti cilj poglavlja sastoji u razumijevanju znaaja faze analize sistema u procesu razvoja informacionih sistema. S tim u vezi eli se istai njen znaaj ne samo u pogledu specifikacije softvera, ve i u pogledu modelovanja poslovanja to je naroito izraena karakteristika savremenih pristupa za modelovanje funkcija sistema. 1.2. Analiza sistema

Cilj uvodnog poglavlja o analizi sistema nije da izloi detaljnu teorijsku pozadinu o sistemima i sistemskom razmiljanju. Obimna literatura o teoriji sistema je tome posveena. Nasuprot tome, ovo poglavlje se, na manje formalan nain, osvre na osnovne pojmove sistema, analize sistema i modelovanja sistema. Nakon uvedenih osnovnih pojmova, objanjava se pojam modelovanja funkcija sistema. Osnovni cilj je da se znaenje pomenutih, vrlo optih pojmova ogranii i saeto izloi imajui u vidu glavnu temu poglavlja Strukturnu sistemsku analizu. Time se eli obezbijediti lake, sistematinije razumijevanje Strukturne sistemske analize, kao jednog od pristupa za analizu, odnosno modelovanje funkcija sistema. 1.2.1. Sistem Besmisleno je govoriti o bilo kakvoj analizi sistema, ako se prethodno ne ustanovi ta je uopte sistem. Postoji jako puno definicija sistema koje se meusobno razlikuju u zavisnosti od toga o kojoj se vrsti sistema govori. Meutim, jedna uoptena definicija moe da glasi ovako: Sistem predstavlja skup elemenata i njihovih meusobnih veza. Ipak, skup elemenata sistema ne moe biti neogranien skup, jer bi se, u suprotnom, svaka diskusija o bilo kom sistemu zavravala sa zakljukom da je svaki sistem univerzum. Da bi bilo jasno ta ini jedan sistem, tj. koji su to njemu pripadajui elementi, sistem se mora posmatrati u odnosu na njegovo okruenje; mora se definisati granica sistema. Zato se moe rei je sistem u odnosu na okruenje jedan ogranien skup elemenata i njihovih meusobnih veza.
Granica sistema

Sistem Sistem (1) iz okruenja

Interakcija sistema sa okruenjem Interakcija sistema sa okruenjem Sistem (n) iz okruenja

Slika 1 Sistem i njegovo okruenje Strana 4/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza Slika 1 prikazuje jedan sistem i njegov poloaj u odnosu na okruenje. Granica sistema razdvaja sistem od spoljnih sistema. Sistem je u neprekidnoj interakciji sa svojom okolinom. Interakcija sistema sa okruenjem se sastoji iz skupa ulaznih i izlaznih dejstava. Dejstvo okoline na sistem naziva se ulaz, a dejstvo sistema na okolinu izlaz sistema. Jedan sistem se moe posmatrati sa razliitih aspekata. Svaki ugao posmatranja definie jedan podskup sistemskih elemenata. Na primer, jedan organizacioni sistem se moe posmatrati sa funkcionalnog aspekta, pri emu su osnovni elementi tog sistema funkcije koje se u njemu odvijaju. S druge strane, isti sistem se moe posmatrati sa aspekta njegove strukture, odakle se kao elementi uoavaju organizacione jedinice, odnosno radna mesta, odeljenja, divizije i dr. Gledano sa funkcionalnog aspekta, jedno proizvodno preduzee kao svoje elemente sadri npr. funkcije proizvodnje, nabavke, prodaje i upravljanja. to se tie interakcije proizvodnog sistema sa okruenjem, jedan od spoljnih sistema proizvodne organizacije moe biti dobavlja osnovnih sirovina. On je sa sistemom od interesa u interakciji kroz kontinuiranu razmenu materijala i informacija. Pokuajte da na osnovu slike 1. i uvedenog primjera sami skicirate sliku slinog sistema i njegovog okruenja. U nastavku teksta se, kada se govori o sistemima, njihovoj analizi, odnosno modelovanju, podrazumijevaju dve vrste sistema: informacioni (softverski) sistemi i organizacioni (poslovni) sistemi. 1.2.2. Analiza sistema Analiza predstavlja postupak izuavanja neke pojave u cilju njenog boljeg razumevanja, odnosno nekog problema u cilju njegovog reavanja. Postupak analize se, generalno, karakterie time to se posmatrana pojava, odnosno problem razlae na sastavne dijelove koji se pojedinano razmatraju. Problem moe da se definie kroz postavljanje sljedeih pitanja: ta ini jedan sistem? Kako izgleda unutranjost nekog (kompleksnog) sistema? U tom sluaju se odgovor na ova pitanja dobija postupkom analize sistema. U postupku analize sistema se sistem najprije posmatra kao crna kutija1. Posmatrajui sistem kao jednu cjelinu, utvruje se koji ga to spoljni sistemi okruuju, odnosno sa kojim drugim sistemima je u interakciji. Zatim se definiu skupovi ulaznih (dejstvo okruenja na sistem) i izlaznih dejstava (dejstvo sistema na okruenje). U daljim koracima se, postupno razlaui sistem, uoavaju sistemski elementi i njihove meusobne veze. Postupak analize sistema se zavrava na onom nivou detalja na kom su svi dobijeni sistemski elementi i njihove veze sa strane posmatraa dovoljno jasni da se dalje ne moraju razlagati. Ovako postavljena analiza sistema, koja zapoinje posmatranjem sistema kao crne kutije i njegovim daljem razlaganjem na pojedinane elemente ima karakter metode Od grubog ka detaljnom (Top-Down) i bazira se na pristupu sistemskog razmiljanja, holistikom pristupu prouavanja kompleksnih sistema2. Top-down metoda podrazumeva postupak analize sistema od apstraktnog ka konkretnom, odnosno od generalnog ka specijalnom. Pod pojmom analize sistema se u oblasti informatike podrazumijeva prva faza u razvoju informacionog sistema, odnosno softvera. U okviru ove faze potrebno je specificirati ta jedan
1

Crna kutija je sistem, ili dio sistema, sa poznatim ulazom, izlazom ali nepoznatom internom strukturom. Posmatranje sistema kao crne kutije omoguuje analitiaru da se koncentrie samo na ulaze i izlaze sistema, privremeno zanemarujui detalje vezane za internu strukturu sistema, odnosno nain funkcionisanja. 2 Sistemsko razmiljanje obuhvata : Koncepte za opis kompleksnih cjelina i njihovih zavisnosti Pristupe bazirane na modelima, pomou kojih je mogue predstaviti realna kompleksna pojavljivanja Pristupe koji podravaju sveobuhvatno razmiljanje.

Strana

5/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza (softverski) sistem treba da prui u pogledu funkcionalnosti, ali ne i kako e sistem pruiti odreenu funkcionalnost, odnosno kako e biti realizovan. Jasno razdvajanje bavljenja pitanjima ta i kako olakava sa jedne strane sam proces analize sistema, a sa druge strane ostavlja mogunost za vie alternativnih realizacija sistema3. Pored toga, potrebno je da analiza sistema bude sastavljena iz ugla posmatranja njegovog korisnika, jer je on budui korisnik sistema, a ne sistem-analitiar koji samo vri posao analize i eventualno uestvuje u projektovanju. Time to jasno definie ta jedan IS treba da prui i to uzimajui u obzir zahtjeve korisnika, analiza sistema ne moe da osigura uspjean projekat razvoja IS, ali zato sigurno moe da smanji rizik od mogueg neuspjeha. Kao rezultat analize bilo kog sistema dobija se jasna slika o sistemu koji se posmatra. Ta slika o sistemu moe ostati zapamena u glavi sistem-analitiara (obino ne zadugo), ali sigurno to nije krajnji cilj analize sistema. Jasna slika o sistemu, odnosno znanje o sistemu se eksplicitno moe predstaviti modelom sistema. O modelu i metodi modelovanja sistema e u narednom poglavlju vie biti rijei. 1.2.3. Modelovanje sistema Modelovanje sistema predstavlja postupak kreiranja modela sistema. Postupak kreiranja modela sistema se definie i opisuje metodom modelovanja. Naredna dva podpoglavlja detaljnije opisuju ove pojmove najprije uopteno, a zatim u kontekstu razvoja informacionih sistema. 1.2.3.1. Model sistema

Model predstavlja subjektivnu, apstraktnu (uproenu) sliku sistema, opisujui elemente tog sistema i njegove veze. Model sistema je uvek subjektivna slika sistema sagledana iz ugla gledanja posmatraa. Pored toga, model je uvijek uproena slika sistema, posmatrana sa jednog apsekta. Najprostiji primer modela je geografska karta sveta. Subjektivnost se u sluaju geografske karte, kao modela svijeta, najekstremnije moe uoiti ako se dananja karta svijeta uporedi sa kartom svijeta jednog geografa sa poetka srednjeg vijeka koji je pokuavao da pronae etiri oka svijeta. Geografska karta posmatra svijet sa fizikog aspekta, a ona se definitivno razlikuje od karte svijeta koju gledamo za vrijeme vremenske prognoze, to predstavlja meteoroloki aspekt. I pojam uproavanja, odnosno zanemarivanja detalja je oigledan. Da li se na karti svijeta u razmjeri 1: 5 000 000 vidi zgrada Narodnog pozorita u Beogradu? emu slue modeli? Modeli slue za bolje razumijevanje, analizu, izgradnju novog sistema ili poboljanje postojeeg. U toku analize sistema se uz pomo modela zanemarivanjem nebitnih istiu samo one karakteristike sistema koje su od interesa za posmatraa i time olakava razumijevanje. S druge strane, pri izgradnji jednog sistema mogue je pomou modela budueg sistema ispitati njegove karakteristike, pa tako na vreme uoiti eventualne nedostatke. Da li se jedan most gradi bez prethodnog detaljnog nacrta, tj. modela mosta od strane arhitekte? U procesu razvoja softvera je takoe vano, posebno u fazi analize sistema i zahtjeva korisnika, sastaviti model budueg sistema. Na taj nain se karakteristike budueg sistema mogu provjeriti u odnosu na zahtjeve njegovih korisnika i prema potrebi, na vrijeme korigovati i usaglasiti. Mnogo je jeftinije i bezbolnije odbaciti jedan model sistema i napraviti novi, prilagoen korisniku, nego proizvesti gotov softver i onda ustanoviti da nikome ne koristi i zaboraviti ga. Cjelokupan razvoj informacionih sistema se zasniva na izgradnji modela. Svaka faza razvoja IS posmatra, odnosno opisuje sistem sa jednog specifinog aspekta, od kojeg zavisi i specifina vrsta modela koja se kreira. U fazi analize sistema i zahtjeva korisnika se sistem posmatra sa aspekta
3

Za koncepte analize sistema (ta?) i njegovog kasnijeg projektovanja (kako?) postoji interesantna fraza u engleskom jeziku: Do the right thing (analysis), and do the thing right (design).

Strana

6/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza njegovih funkcija, pa se kao rezultat te faze dobija model funkcija sistema. Model funkcija sistema daje opis svih funkcija koje budui informacioni sistem treba da prui svojim korisnicima. Pored funkcionalnog aspekta, sistem se u ostalim fazama jo posmatra sa aspekata strukture, dinamike, kao i fizikog aspekta, to rezultuje odgovarajuim vrstama modela. 1.2.3.2. Metoda modelovanja

Metoda modelovanja4 definie jedan mogui nain za modelovanje sistema. ta se podrazumijeva pod jednom metodom modelovanja? Da bi opisali sistem, odnosno kreirali model, potrebno je da raspolaemo odgovarajuim alatom, odnosno potrebno je da imamo adekvatan skup koncepata kojim se moemo posluiti da bi svoje znanje o sistemu pretoili u model. Jezik modelovanja definie skup koncepata potrebnih za izgradnju modela, odnosno predstavlja alat za opis sistema modelom5. Jezikom modelovanja se kao i kod govornog jezika definie sintaksa i semantika koncepata koji se koriste i dodatno, notacija. Sintaksa definie koncepte i pravila jezika i opisana je gramatikom, dok semantika definie znaenje koncepata. Notacija definie za svaki koncept njegovu grafiku predstavu, odnosno simbol. Pored toga, postavlja se pitanje kako na najbolji nain koristiti raspoloive koncepte u cilju izgradnje modela. S tim u vezi, potrebno je uz jezik kao alat za opis modela dati i uputstvo za njegovu upotrebu. Potrebno uputstvo za upotrebu se definie postupkom modelovanja, tako to se navodi redosjled koraka za izgradnju modela, kao i rezultat koji se dobija primjenom svakog od koraka ( u vidu modela ili njegovog dijela). Prema tome, jedna potpuna metoda modelovanja sastoji se iz: jezika modelovanja i postupka modelovanja, kao uputstva za korienje jezika u cilju uspjenog kreiranja modela. Jezik modelovanja se vrlo formalno moe definisati, za razliku od postupka koji je obino neformalan. Slika 2 prikazuje odnos uvedenih pojmova. Modelovanje sistema se moe zamisliti kao proces koji od posmatranog sistema (ulaz) generie model sistema (izlaz), na nain specificiran primjenjenom metodom modelovanja (transformacija).
Jezik modelovanja

M etoda m odelovanja
Postupak modelovanja

Sistem

M odelovanje

M odel sistem a

Slika 2 Odnos pojmova u modelovanju Kao to sve faze razvoja informacionog sistema prate razne vrste modela, isto tako se za izgradnju tih modela koriste odgovarajue metode. Skup specifinih metoda definisan za svaku od faza u razvoju IS predstavlja metodologiju razvoja informacionih sistema.

4 5

Kao sinonim za metodu koristi se i termin tehnika. I sam jezik modelovanja se moe predstaviti kao model, jer se po definiciji sastoji iz skupa koncepata i njihovih meusobnih veza. Takav model, pomou koga opisujemo druge modele predstavlja model o modelu i naziva se metamodel.

Strana

7/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza Nakon uvedenih pojmova se moemo vratiti na glavnu temu ovog poglavlja, Strukturnu sistemsku analizu, kao jednu od metoda za modelovanje funkcija sistema koja se koristi u fazi analize sistema i specifikacije zahtjeva korisnika. 1.3. Strukturna sistemska analiza

Strukturna sistemska analiza6 (SSA) je jedna poptuna, samosvojna metoda za analizu i funkcionalnu specifikaciju informacionog sistema, odnosno softvera. Ona se na razliite naine moe povezati sa metodama drugih faza u neku specifinu metodologiju cjelokupnog razvoja IS (, str. 351). Primenom metode SSA se dobija model procesa posmatranog sistema, koji treba da da odgovor na sljedea pitanja: Koje funkcije posjeduje sistem, odnosno koje funkcije mora imati budui IS? Kakve veze postoje izmeu funkcija? Kakve transformacije treba sistem da izvri? Koje ulaze (podatke) procesom obrade transformisati u koje izlaze? Koje zadatke treba da izvri sistem? Odakle sistem povlai informacije potrebne za izvravanje zadataka? Kuda odlaze rezultati obrade?

Kao metoda modelovanja, strukturna sistemska analiza jasno definie skup koncepata, odnosno jezik modelovanja i postupak modelovanja u cilju korektne izgradnje modela. Shodno tome e se i u narednim odjeljcima opisati sastavni dijelovi metode SSA. Nakon uvodnog pregleda osnovnih koncepata, slijedi pojedinano detaljno izlaganje osnovnih koncepata imajui u vidu njihovu strukturu, znaenje, nain predstavljanja i pravila koja se moraju potovati pri njihovom korienju (Poglavlja 3.3.1, 3.3.2, 3.3.3). Poglavlje 3.3.4 objanjava postupak dekomponovanja funkcija sistema, odnosno tehniku za postepeno savladavanje kompleksnosti sistema, kao glavne karakteristike metode SSA. S tim u vezi se uvodi jo nekoliko koncepata, a zatim navode dodatna pravila i kriterijumi dekompozicije. Kao to e se vidjeti, modelovanje funkcija sistema metodom SSA se bazira na uoavanju funkcija sistema na taj nain to se posmatraju podaci koje funkcije sistema obrauju. Zbog toga, pored uvedenih koncepata koji, pored funkcija, predstavljaju podatke u sistemu, poglavlje 3.3.5 uvodi Rijenik podataka, kao dodatni alat u metodi SSA za opis strukture i sadraja podataka sistema. 1.3.1. Osnovni koncepti strukturne sistemske analize SSA posmatra informacioni sistem kao funkciju (proces obrade) koja, na bazi ulaznih podataka i stanja sistema predstavljenog preko skladita podataka, generie izlazne podatke. Ulazni podaci se dovode u proces obrade, a izlazni iz njega odvode preko tokova podataka. Isto tako, proces obrade koristi i mijenja podatke o stanju sistema razmjenom tokova podataka sa skladitem. Tok podataka se tretira kao vod kroz koji stalno teku podaci ili kao pokretna traka koja stalno nosi podatke na najrazliitijim nosiocima - papirni dokumenti, niz poruka koje ovek unosi preko tastature terminala, paket informacija dobijen preko neke telekomunikacione linije ili slino (, str. 351). Entiteti iz okruenja sa kojima IS komunicira nazivaju se interfejsi. Ako ceo IS posmatramo kao jedan proces, onda interfejsi predstavljaju izvore svih ulaznih i ponore svih izlaznih tokova podataka.
6

Zato ba strukturna metoda? Autori strukturne sistemske analize dodali su epitet strukturne, da bi naglasili njene tada napredne karakteristike u odnosu na prethodne pristupe analizi sistema, koji su se odlikovali u najveoj mjeri vrlo obimnim tekstovima . Upotreba grafikih modela za specifikaciju sistema naspram dotadanjeg suvog teksta i mehanizam razlaganja sistema na podsisteme, omoguili su ureenu, kompozitnu tzv. strukturiranu analizu sistema.

Strana

8/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza Dakle, funkcije, odnosno procesi obrade podataka, skladita podataka, tokovi podataka i interfejsi predstavljaju osnovne koncepte metode SSA. Za njihov prikaz koriste se Dijagrami tokova podataka (DTP). Slika 3 daje primer tipinog DTP.

ZahtevZa lanstvom lan lanskaKarta

1. Ulanjivanje Distributeri Uplata Faktura Katalog lanovi 3. Nabavka Narudbenica Otpremnica Distributer

ListaFilmova Izdatnica Plaanje Filmovi KataloziFilmova 2. Izdavanje

Izdatnice

Slika 3 Primer DTP Opis osnovnih funkcija jednog Video-kluba Dijagram na slici 3 prikazuje model sutinskih procesa jednog Video-kluba. Cilj uvoenja ovog primera bez detaljnog rasvjetljavanja znaenja njegovih elemenata je da se postave sljedea pitanja: Da li se na prvi pogled dijagram ini razumljivim? Da li je notacija oigledna i jednostavna? Da li se intuitivno prepoznaje ta su funkcije, ta tokovi podataka, a ta skladita i interfejsi? Odgovor na ova pitanja je potvrdan, bez ikakve sumnje. Jednostavnost u prikazu i intuitivnost u razumevanju predstavljaju veoma vanu karakteristiku DTP. Razlog za to se moe izvui iz odgovora na pitanje kome su dijagrami uopte i namijenjeni. Sigurno ne samo sistemanalitiaru, odnosno projektantu IS, nego i krajnjem korisniku, neinformatiaru, koji treba da ocjenu o tome, da li su njegovi zahtjevi na adekvatan nain analizirani i izmodelovani. Na DTP se procesi predstavljaju elipsom, interfejsi pravougaonikom, tokovi podataka usmjerenim linijama, a skladite podataka sa dve paralelne linije. Dio dijagrama sa slike 3 se sada moe protumaiti na sljedei nain: Sistem Video-kluba se sastoji od osnovnih procesa: ulanjivanja, izdavanja filmova i nabavke. Spoljni objekti sistema su lanovi i distributeri filmova. Budui lan dostavlja popunjen zahtjev za lanstvom video-klubu, gde nakon ulanjivanja dobija lansku kartu i biva zapamen u listi lanova video-kluba. Lista lanova omoguuje video-klubu da vri proces izdavanja, tako to e zahtjevane filmove izdavati samo onim lanovima koji su registrovani u listi lanova. Video klub nabavlja filmove od ovlaenih distributera koji alju katalog najnovijih filmova itd. Do sada je postalo jasno kako tumaiti DTP, ali mnogo vanije i zabavnije je kako sastaviti jedan DTP i to tako da bude sintaksno i logiki korektan i pregledan. Sljedea dva poglavlja su posveena Dijagramima tokova podataka, odnosno konceptima i pravilima za njihovo uspeno kreiranje.

Strana

9/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza 1.3.2. Dijagrami tokova podataka Dijagram tokova podataka (DTP) predstavlja osnovni alat za opis funkcija sistema. Ali, zato onda dijagram tokova podataka? Zato se ne zove npr. Dijagram procesa, kada ve opisuje procese? Osnovni razlog lei u nainu posmatranja funkcija sistema. Funkcije sistema se u metodi SSA, odnosno pri izgradnji DTP posmatraju kao procesi obrade podataka, tj. posmatraju se sa take gledita podataka. Uoavajui podatke koji ulaze u sistem, obrauju se i iz sistema izlaze, drugim reima, koji teku sistemom, uoavamo i koji su procesi potrebni za obradu (transformaciju) tih podataka. Praenjem tokova podataka je mogue ustanoviti kompletnu sliku o tome ta se to deava unutar sistema, odnosno kako sistem funkcionie. DeMarco opisuje taj postupak kao intervjuisanje podataka . DTP kao alat za opis funkcija se nadalje objanjava kroz navoenje njegovih osnovnih komponenti: procesa, tokova podataka, skladita podataka i interfejsa. Sintaksa i semantika ovih koncepata je u velikoj mjeri naslonjena na originalne autore metode SSA . Kako postoje razliiti standardi za ilustraciju simbola u okviru DTP, ovde navedena notacija je u skladu sa, na naim prostorima etabliranom notacijom utvrenom u Laboratoriji za informacione sisteme na Fakultetu organizacionih nauka . 1.3.2.1. Proces

Proces predstavlja dio sistema (ili u posebnom sluaju cio sistem, o tome vie u poglavlju 3.3.4.1) koji ima ulogu da transformie ulazne podatke u izlazne. Grafiki se sistem predstavlja elipsom (Slika 4).
1 . P ro c e s _ 1

Slika 4 Proces Kako proces predstavlja aktivnost, radnju, vano je imenovati ga na adekvatan nain. Proces se obino imenuje parom predikat objekat (predmet). U imenima najoptijih procesa se objekat radnje moe izostaviti. Primjeri: Nabavka, Ulanjivanje, Knjigovostvo, Obrada porudbine, Provjera adrese itd. Kao to se vidi predmet obrade procesa su uvijek paketi podataka u nekoj formi, papirna ili elektronska dokumenta, pojedinani podaci uneeni preko tastature raunara i dr. Davanje smislenog imena procesu obrade umnogome olakava razumljivost dijagrama i opravdava njegovo ulogu. Postoji nepisano pravilo koje kae da, ako analitiar nije u stanju da dodijeli ime procesu, to samo znai da ne razumije funkciju koju proces obavlja (, str. 8). Jako je vano imati u vidu da se procesi u organizaciji koju analiziramo u jednom trenutku vremena izvravaju paralelno, a ne sekvencijalno, kako bi na prvi pogled to moda izledalo. Uzmimo primer proizvodne radne organizacije, koju ine sljedei osnovni procesi: nabavka, proizvodnja i prodaja. Naravno da moemo pitati: ekaj, ali redosljed odvijanja ovih procesa je prilino poznat, najprije nabavim materijale, lansiram proizvodnju i konano prodam proizvode, zar ne?. Odgovor je zasigurno potvrdan. Meutim, ako posmatramo organizacioni sistem u cjelini, u jednom trenutku vremena svi procesi se izvravaju paralelno, proces proizvodnje je lansiran, u istom trenutku proces nabavke obezbjeuje materijale za sljedei ciklus proizvodnje, a prodaja je prisutna na tritu sa gotovim proizvodima iz prethodnog ciklusa proizvodnje. Jo jedan primjer: Da li ste sluajno primjetili da fakultet prestane sa radom kada doete da prijavite ispit? Paralelizam u obavljanju funkcija je karakteristika odvijanja procesa u organizaciji (, str. 361). Podpoglavlje 3.3.2.3 o Skladitima podataka dodatno pojanjava ovu injenicu. Strana 10/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza Svaki proces posjeduje pored imena i svoju brojnu oznaku. Brojna oznaka procesa slui samo za referenciranje procesa, a nikako ne predstavlja redosljed izvravanja procesa, zbog paralelizma u izvravanju koji je upravo diskutovan. Nain numerisanja procesa e se detaljnije objasniti u poglavlju 3.3.4.3 o Pravilima i kriterijumu dekompozicije. 1.3.2.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 dijela sistema u drugi, i na taj nain ostvaruje vezu izmeu komponenti sistema. Odavde automatski slijedi da svaki tok podataka mora imati svoje izvorite i ponorite. Tok predstavlja podatak u stanju kretanja. Skladite predstavlja podatke u stanju mirovanja (vidi odjeljak 3.3.2.3). Grafiki simbol za prikaz toka podataka je usmjereni luk (Slika 5).
TokPodataka_1

Slika 5 Tok podataka Tok podataka se imenuje prema znaenju podataka koji se tim tokom prenose. Da bi se ostvarila itljivost i razumljivost DTP-a, imena treba da budu prirodna, nasuprot specifinim, kodiranim, skraenim imena. Primjeri: Faktura, Narudbenica, KatalogFilmova, lanskaKarta itd. Imena tokova podataka koja u sebi sadre rijei PodaciO, InformacijeO, ili jo gore, PotrebniPodaci, NeophodneInformacije treba u velikom luku izbjegavati. Takva imena sugeriu na potpuno nejasnu predstavu analitiara o tome, koji se paketi podataka prenose tokom. Nemogunost adekvatnog imenovanja moe da znai da takav tok nema egzistencijalnog smisla, a to dalje znai ili njegovo potpuno uklanjanje ili razlaganje na vie konkretnijih tokova podataka. Tok podataka takoe govori o usmjerenju kretanja podataka. Strelica oznaava da li podaci u jedan proces, skladite ili interfejs poniru ili iz njega izviru i obrnuto. 1.3.2.3. Skladite podataka

Skladite podataka predstavlja podatke u stanju mirovanja. Grafiki se prikazuje kao na slici 6.
Skladite_1

Slika 6 Skladite podataka Ime skladita bi trebalo da predstavlja mnoinu imenice toka podataka koji u njega ulazi ili izlazi, naglaavajui time da se radi o skupu objekata, paketa podataka. Na primer, skladite u koje ponire tok NarudbenicaDobavljaa treba da nosi naziv NarudbeniceDob. Jo jedan slikovit primjer predstavlja skladite Testovi, koje se sa ulaznim tokom IspitniTest moe zamisliti kao gomila papira koja na radnom stolu eka da bude pregledana. Skladite omoguava sistemu da uva svoje stanje u vremenu. To konkretno procesima omoguava meusobnu vremensku nezavisnost, odnosno da se u sluaju razliitih paketa podaka procesi mogu paralelno ili u sluaju istih paketa, sa zakanjenjem izvravati. Ilustrujmo to sljedeim primjerom. Na slici 7 je dat odsjeak jednog DTP.

Strana 11/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza

NoviZahtev ZahtevZaDopunu 1. PrijemZahteva 2. ObradaZahteva

PotvrdaOPrijemu

Podnosilac DospeliZahtevi

Slika 7 Neophodnost postojanja skladita Novi zahtjevi pristiu u sistem i bivaju primljeni od strane procesa PrijemZahteva. Nakon prijema (recimo da se u procesu Prijema zahteva moe vriti provjera validnosti zahtjeva i potrebnih dokumenata) se zahtjev preko toka podatka alje u skladite DospjeliZahtjevi. Dospjeli zahtjevi se itaju iz skladita i proces ObradaZahteva dalje vri potrebnu obradu. Ukoliko ne bi postojalo skladite izmeu procesa, svaki pristigli NoviZahtev bi nakon PrijemaZahteva morao istog momenta da pree u proces ObradeZahtjeva. ta ako u trenutku prijema novog zahtjeva prethodni zahtjev jo uvijek nije obraen? Skladite omoguava da se paketi podataka izmeu procesa obrade uvaju, to omoguava da se procesi u jednom trenutku mogu paralelno izvravati i obraivati razliite pakete podataka, to oslikava paralelizam odvijanja razliitih procesa u jednoj organizaciji. U naem sluaju PrijemZahtjeva prima nove zahtjeve, dok u isto vreme proces ObradaZahtjeva obrauje prethodno primljene, nagomilane zahtjeve. U sluaju istih paketa podataka, skladite omoguava da se obrada paketa podataka izmeu dva procesa vri sa kanjenjem. U primeru e primljeni zahtjev neko vrijeme ekati uskladiten da bi preao u proces Obrade zahteva. Drugaije reeno, skladita podataka na DTP slue da poveu dva procesa. Kad god izlazni tok jednog procesa predstavlja ulazni tok drugog procesa, potrebno je uvesti skladite podataka koje e premostiti vezu ta dva procesa. Sluaj kada tok podataka iz jednog procesa ulazi u skladite se moe tumaiti kao postupak upisivanja novih podataka, auriranja ili brisanja postojeih. Sluaj kada tok podataka iz skladita izlazi i ulazi u proces opisuje se kao mogunost procesa da ita podatke iz tog skladita, odnosno oznaava mogunost pristupa tom skladitu7. 1.3.2.4. Interfejs

Interfejs predstavlja spoljni objekat sa kojim sistem komunicira. Spoljni objekat moe npr. biti osoba ili grupa osoba, korisnika sistema. Dalje, spoljni objekat moe biti odjeljenje unutar organizacije ili van nje ili itava eksterna organizacija. Primjeri za to su respektivno: Odjeljenje Raunovodstva, Odjeljenje za opte poslove u Optini, Banka i sl.). Informacioni sistem iz okruenja ili njegov dio takoe moe predstavljati interfejs, sa kojim na sistem komunicira (Sistem za online naplatu, Servis za pretraivanje internet-stranica). Interfejs se na dijagramu vizuelno predstavlja kao pravougaonik (Slika 8).
Interfejs_1

Slika 8 Interfejs
7

Ako skladite unapred zamislimo kao bazu podataka, a proces kao softver koji radi nad bazom podataka, onda bi ulazni tokovi predstavljali ustvari procedure unosa podataka, auriranja ili brisanja postojeih podataka iz baze, a izlazne tokove kao standardne upite nad tabelama baze podataka.

Strana 12/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza Interfejse je lako identifikovati. Ako sistem posmatramo kao crnu kutiju, odnosno kao jedan proces koji na ulazu prima tokove podataka, vri proces obrade i generie izlazne tokove, lako moemo uoiti sa kim on komunicira, odnosno od kog spoljnog objekta prima podatke, a kome obraene podatke dalje isporuuje. Detaljnije o interfejsima u poglavlju 3.3.4.1 o Dijagramu konteksta. 1.3.3. Pravila i preporuke za kreiranje DTP U prethodnom poglavlju su predstavljene komponente Dijagrama toka podataka: proces, tok podataka, skladite podataka i interfejs. Tom prilikom su uz svaki koncept navedena i odreena pravila, kao na primer pravila za imenovanje koncepata. Za valjanu izgradnju dijagrama koristei se ovim jednostavnim konceptima, potrebno je uvesti jo nekoliko pravila. Pravila postavljaju ogranienja na odreene postupke u kreiranju DTP, kako bi se izbjeglo da rezultujui dijagrami budu pogreni, nepotpuni ili logiki nekorektni. Preporuke u smislu ogranienja treba labavije shvatiti. Moe se rei da pravila predstavljaju neophodan uslov, a preporuke dovoljan uslov za uspjenu izgradnju DTP. Pravila i preporuke za kreiranje Dijagrama tokova podataka su sljedea: (1) Svaki proces mora da ima barem jedan ulazni i barem jedan izlazni tok podataka. Proces bez ulaznog toka generisao bi izlaz ni iz ega, a proces bez izlaznog toka je nesvrsishodan (, str. 34). Postojanje takvih procesa automatski sugerie na logiku greku. Proces generisanja sluajnih brojeva bi bio jedini izuzetak kao proces koji posjeduje samo izlazne tokove podataka. Neto blae ogranienje u ovom smislu, dalje, moe da glasi: i. Proces moe da generie izlaz samo iz svih za obradu potrebnih ulaznih tokova podataka8, i obratno: ii. Proces moe da generie izlaz samo na osnovu za obradu raspoloivih tokova podataka. (2) Preporuuje se da se jedan proces povezuje sa drugim procesom samo posredno preko skladita podataka. Direktnu vezu dva procesa samo preko toka podataka trebalo bi izbjegavati, jer se na taj nain veoma ograniava njihovo nezavisno izvravanje. Trenutak generisanja izlaznog toka prvog procesa automatski uslovljava poetak izvravanja drugog procesa. U velikoj veini sluajeva potreban je izvjestan vremenski razmak, u kome e se izlazni paket podataka najpre sauvati u skladitu podataka, odakle u proizvoljnom trenutku moe biti iitan od strane drugog procesa. (Pogledati poglavlje 3.3.2.3 o skladitu podataka). Pored toga, nepostojanjem skladita podataka izmeu dva procesa sistem se liava mogunosti da zapamti sopstveno meustanje (nakon zavretka jedne i poetka druge obrade), a to je jedna od osnovnih osobina skladita podataka. (3) Samo tokovi podataka koji idu ka, odnosno od skladita podataka ne moraju biti imenovani. Ako tok izmeu procesa i skladita nije imenovan, podrazumijeva se da tok nosi cjelokupan sadraj i strukturu podataka tog skladita. Ukoliko to nije sluaj, tj. ako tok sadri samo dio strukture podataka, treba ga adekvatno imenovati. Primjer na slici 9 ilustruje sluaj kada tok podataka ne prenosi sve podatke o Graaninu (Ime, Prezime, Pol, Datum roenja, Adresa...) ve samo jedan dio podataka, novu adresu.

Proces ne moe biti nosilac podataka, osim u sluaju konstantnih vrednosti. Na primjer proces sraunavanja sumarne cijene jedne porudbine moe kao konstantu procesa pamtiti visinu poreza na dodatu vrijednost izraenu u procentima. Ipak, treba imati u vidu da svako pamenje podataka kao konstanti ini IS kruim u odnosnu na budue promjene.

Strana 13/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza

Slika 9 Skladite sa imenovanim tokom podataka (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) Tok podataka mora da ima izvor i ponor. Bilo koja druga komponenta DTP moe da bude izvor ili ponor. Meutim, za jedan tok, bilo izvor, bilo ponor (bilo oba) mora da bude proces (, str.34). Iz ovog pravila slijedi da dva interfejsa, dva skladita, ili interfejs i skladite ne mogu direktno biti povezani tokom podataka (Sluaj procesa je prodiskutovan pod (2)). Razmotrimo detaljnije ove sluajeve: i. Skladita ne mogu meusobno direktno biti povezana tokom podataka, jer skladita, kao pasivne komponente, ne vre nikakvu obradu. ii. Interfejsi ne mogu meusobno direktno biti povezani tokom podataka, jer bi se na taj nain opisivala komunikacija dva objekta van sistema koja, iako je mogua, nije od interesa za sistem koji posmatramo. iii. Interfejs i skladite ne mogu direktno biti povezani tokom podataka jer bi to znailo da spoljni objekat direktno, bez kontrole internog procesa posjeduje pristup skladitu podataka. Ovakve situacije se razrjeavaju uvoenjem odgovarajueg procesa izmeu interfejsa i skladita. U primjeru prikazanom na slici 10(i), interfejs Student direktno pristupa skladitu podataka PrijaveIspita. Loginije i sintaksno korektnije bi bilo uvoenje procesa obrade Prijava ispita, koji pretpostavlja kontrolu predate ispitne prijave, kao na primer i provjeru uplate ispita (Slika 10(ii)). I za sluaj obrnutog smjera toka podataka, od skladita podataka ka spoljnom objektu, data je ilustracija nekorektnog i korektnog modelovanja na slikama 10(iii) i 10(iv), respektivno. Bez postojanja sistemskog procesa, koji bi najprije provjerio identitet i prava klijenta, a zatim kreirao izvetaj o stanju na raunu, klijentu bi bio omoguen direktan pristup cjelokupnom skladitu bankovnih rauna.
Uplatnica Student Student IspitnaPrijava 1. Prijava ispita IspitnaPrijava

PrijaveIspita PrijaveIspita

nekorektno (i)

korektno (ii)

PotvrdaAutorizacije StanjeNaRa unu Klijent StanjeNaRa unu 1. Izrada izve taja o stanju na raunu BankovniRa uni

Klijent

BankovniRa uni

nekorektno (iii)

korektno (iv)

Slika 10 Ilustracija pravila za izgradnju korektnih DTP (6) Svako skladite mora da ima barem jedan ulazni i barem jedan izlazni tok podataka. U praksi je ponekad teko odmah uoiti da li jedno skladite stvarno ima i ulaz i izlaz. esto Strana 14/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza se za skladite najpre ustanovi samo jedan od tokova podataka, ali se kasnijom analizom drugog dela sistema utvrdi i ostatak tokova. (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 izbjegavanja nepotrebnog presijecanja linija bilo skladite bilo interfejs na jednoj slici moe viestruko ponoviti. U tom sluaju potrebno je samo pored imena koncepta dodati znak *. Prilikom izgradnje DTP treba imati i to u vidu, da prva skica dijagrama nikad ne moe biti perfektna, imuna na sve sintaksne i logike greke. ovek ima sposobnost da razmilja na iterativan nain. Kroz ponavljanje bilo kog postupka on se ui i usavrava, kao prirodan proces uenja. Imajui to u vidu generalna preporuka koja se tie izgradnje DTP glasi, da prvi put izgraen dijagram uvek treba kroz nekoliko prolaza revidirati i u skladu sa pravilima i preporukama poboljavati, ak i po cijenu odbacivanja stare i crtanja potpuno nove verzije. DeMarco u tom smislu kae: Ukoliko se naete u situaciji da ste proizveli konanu verziju dijagrama na papiru na kom ste i zapoeli kreiranje, to samo znai da niste dozvolili vaem mozgu da razmilja na prirodan, iterativan nain (, str.69). Pored navedenih postoji jo nekoliko pravila i preporuka koja se tiu sprovoenja pravilne hijerarhijske dekompozicije DTP, to je tema narednog poglavlja. 1.3.4. Dekompozicija dijagrama tokova podataka Uloga DTP se sastoji u tome da prikae sve sistemske procese koji na bazi ulaznih tokova podataka vre obradu i generiu izlazne tokove. Izvori i ponori svih tokova podataka jednog sistema su na DTP predstavljeni ili spoljnim objektima ili skladitima podataka. Veoma je vano da dijagrami tokova podataka budu pregledni, jasni i lako razumljivi, ne samo sistem-analitiaru, ve i krajnjem korisniku. Nain da dijagram ostane jednostavan je da sadri relativno mali broj procesa ukljuujui sve potrebne interfejse, tokove i skladita podataka. Ali, kako odrati jednostavnost, odnosno mali broj procesa ako se eli detaljan prikaz sloenog sistema koji se sastoji od nekoliko desetina, stotina ili hiljada procesa? Kada bi sistem takvih razmera predstavili samo jednim DTP, dobili bi neshvatljivu gomilu procesa isprepletanih mreom tokova podataka nalik pagetima, a sam dijagram bi bio veliine bilborda. Odgovor na ovo pitanje je jednostavan. Cio sistem moemo najpre da podijelimo na skup podsistema. Zatim svaki od podsistema dalje moemo podijeliti na podpodsisteme. Ovaj princip postepenog razlaganja sistema na podsisteme moemo pratiti sve dok se razlaganjem jo uvek dobijaju sloeni procesi, odnosno dok ne stignemo do nivoa prostog, primitivnog procesa koji se dalje ne moe dijeliti. Ako svaki nivo razlaganja sistema opiemo dijagramima, i to tako to emo na svakom nivou za svaki novodobijeni podsistem (skup podprocesa) kreirati odgovarajui dijagram, dobiemo hijerarhijski organizovan skup neuporedivo preglednijih, jasnijih DTP od prvobitnog bilborda9. Uvedeni postupak bazira se na osnovnom principu razrjeavanja kompleksnih problema postepenim uvoenjem detalja, odnosno korienjem metode apstrakcije10. Dakle, tehnika izgradnje dijagrama tokova podataka se svodi na to da se na viim nivoima definiu globalniji procesi, a da se zatim svaki takav globalni proces, na sljedeem niem nivou, predstavi novim
9

Slikovita analogija ovom postupku geografska karta, odnosno organizacija atlasa svijeta. Atlas svijeta zapoinje najprije slikom cijelog svijeta podijeljenog na kontinente. Zatim sljedi opis svakog kontinenta pojedinano dekomponujui ga na pojedinane drave. Zatim slijedi opis unutranje organizacije drave itd. 10 Apstrakcija predstavlja postupak zanemarivanja detalja u cilju isticanja bitnih karakteristika posmatrane pojave.

Strana 15/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza dijagramom toka podataka (, str.352). Princip dekompozicije funkcija koji se bazira na posmatranju sistema na razliitim nivoima apstrakcije, ilustrovan je na slici 11.

Slika 11 Princip hijerarhijske dekompozicije funkcija sistema Dijagram tokova podataka na vrhu hijerarhije naziva se dijagram konteksta, a procesi na dijagramima najnieg nivoa hijerarhije, koji se dalje ne mogu dekomponovati, nazivaju se primitivni procesi. Dijagram konteksta i primitivni procesi se detaljnije objanjavaju u naredna dva podpoglavlja. Nakon toga se navode pravila i kriterijumi dekompozicije. Na kraju, postavlja se potreba da se svi procesi sistema dobijeni dekompozicijom ili jedan deo procesa predstavi na jedan sveobuhvatan, sumaran nain. U tom smislu se uvodi Dijagram hijerarhijske dekompozicije funkcija, ime se okonava razmatranje dekompozicije DTP. 1.3.4.1. Dijagram konteksta

Najoptiji dijagram tokova podataka je dijagram konteksta. Dijagram konteksta posmatra sistem kao crnu kutiju, kao jedan proces, koji na bazi ulaza generie izlazne podatke. Uloga dijagrama konteksta je da definie kontekst analize, odnosno da odredi jasnu granicu sistema, da odgovori, Strana 16/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza ta su to sastavni dijelovi sistema, a ta su spoljni objekti sa kojima on interaguje. Zatim je potrebno identifikovati komunikaciju izmeu posmatranog sistema i njegovog okruenja, odnosno uoenih spoljnih objekata. Drugim reima, potrebno je znati koje informacije iz okruenja utiu u sistem i koje informacije sistem proizvodi i alje kao izlaz u okruenje. Kao specijalan sluaj DTP, dijagram konteksta mora sadrati samo jedan proces koji predstavlja sistem, skup interfejsa i tokove podataka, koji od interfejsa ulaze u sistem i obratno, koji kao rezultat procesa obrade izlaze iz sistema ka interfejsima. Primjer jednog Dijagrama konteksta dat je na slici 12 (Uporediti sa slikom 1 iz poglavlja 3.2.1).

Slika 12 Dijagram konteksta S obzirom da proces na Dijagramu konteksta predstavlja cio sistem, ime procesa obino predstavlja ime celokupnog informacionog sistema, kao to je na slici 12 sluaj. Interfejsi su povezani sa sistemom preko ulaznih i izlaznih tokova podataka. Vano je ponoviti da interfejsi ni u kom sluaju ne smiju meusobno direktno da komuniciraju. Ako ipak postoji povezanost dva interfejsa koja bi bila od interesa za sistem, onda je vjerovatno da e oni meusobno posredno komunicirati preko sistemskog procesa. Kada su identifikovani svi interfejsi, potrebno je uoiti sve relevantne tokove podataka. Sistem interreaguje sa okruenjem tako to reaguje na stimulanse iz okruenja. Na osnovu analize moguih dogaaja iz okruenja na koje sistem reaguje i dogaaja koje sistem kao reakciju generie, mogu se identifikovati neophodni tokovi podataka.. Dogaaji koji djeluju na sistem mogu biti spoljni dogaaji koje izazivaju objekti iz okruenja, vremenski dogaaji koji nastaju jer je nastupio odredjeni vremenski trenutak, ili interni dogaaji koji se okidaju kada sistem doe u neko specifino stanje (, str.31). Obino su spoljni dogaaji ti koji najvie govore o moguim tokovima podataka. Na primjer, za jedan IS Optine spoljni dogaaj moe biti Stranka podnosi zahtjev za izdavanje potvrde od dravljanstvu, na koji IS sistem treba da reaguje procesom obrade zahtjeva. Tako bi jedan ulazni tok podataka onda bio: Zahtjev za izdavanje potvrde o dravljanstvu, a izlazni tok podataka: Potvrda o dravljanstvu. Dogaaj koji IS nakon obrade zahtjeva generie bi mogao biti: Potvrda o dravljanstvu izraena uz odgovarajui tok podataka. Primjer vremenskog dogaaja moe biti neki datum kada graanima treba uputiti odreeno obavjetenje. U ovom sluaju dogaaj odgovara jednom izlaznom toku podataka ka graanima kao interfejsu. Na ovaj nain se mogu efikasno identifikovati svi tokovi podataka i to za svaki interfejs pojedinano, ime se sumarno dobija kompletan skup potrebnih tokova podataka za cio sistem. Izgradnja dijagrama konteksta je najvaniji zadatak u postupku kreiranja DTP. Izgleda jednostavno nacrtati jedan proces, nekoliko interfejsa i povezati ih sa procesom tokovima podataka. Meutim, Strana 17/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza vrlo je vano uoiti sve mogue interfejse na samom poetku, kao i sve dogaaje, odnosno tokove podataka koji ulaze u sistem i iz njega nakon obrade izlaze. Na primjer, zanemarivanje jednog ili grupe tokova podataka bi u daljem postupku dekompozicije moglo da dovede do izostavljanja procesa koji bi u normalnom sluaju trebalo da vre obradu podataka, kao i da prouzrokuje propuste u identifikaciji potrebnih skladita podataka. 1.3.4.2. Primitivni procesi Primitivni procesi su oni procesi koji se dalje ne mogu dekomponovati. Predstavljaju se Dijagramima tokova podataka na dnu hijerarhije, kao rezultat konane dekompozicije funkcija sistema. Primitivni procesi se nazivaju jo i atomskim procesima, to naglaava njihovu nemogunost daljeg dekomponovanja. Za razliku od sloenih procesa na viim nivoima hijerarhije, primitivni procesi se izvravaju sekvencijalno, redosled aktivnosti u okviru njih je definisan. Identifikovanjem svih primitivnih procesa jednog sistema zavrava se proces dekompozicije, pa samim tim i proces analize funkcija sistema, odnosno odgovora na pitanje ta sistem radi, odnosno koje funkcije sistem izvrava. Sljedei korak u metodi Strukturne sistemske analize jeste dati specifikaciju logike primitivnih procesa. Specifikacija logike primitivnih procesa, tzv. Minispeficikacija ima zadatak da za svaki primitivni proces detaljnije opie sekvencijalni postupak njegovog izvravanja. Drugim reima, mini-specifikacija svake funkcije treba da prui odgovor na pitanje kako na osnovu ulaznih podataka transformacijom dobiti izlazne podatke. S obzirom da na taj nain dobijamo odgovor na pitanje Kako?, sistem, shvaen kao funkcija koja na bazi ulaznih podataka generie izlazne, moe da se posmatra kao bijela kutija, jer je poznata ne samo njegova interna struktura, ve i nain funkcionisanja. Postoji iroka paleta tehnika za specifikaciju sekvencijalnih procesa, odnosno za opis logike primitivnih procesa. Najzastupljenije tehnike su dijagrami toka programa, strukturni jezici, pseudokod, tabele odluivanja, stabla odluivanja i dr. Specifikacija logike primitivnih procesa, odnosno tehnike za opis logike nisu od interesa, pa se nadalje ne razmatraju. Kada govorimo o primitivnim procesima, postavlja se pitanje kako razlikovati sloen proces od primitivnog, odnosno koji su to kriterijumi koji definiu kada prestaje dalja dekompozicija procesa. Sljedee poglavlje daje odgovor na to pitanje i navodi pravila za korektan postupak dekompozicije Dijagrama tokova podataka. 1.3.4.3. Pravila i kriterijumi dekompozicije

Kao to postoje pravila za izgradnju pojedinanih Dijagrama tokova podataka, potrebno je pridravati se i odreenih pravila pri dekompoziciji procesa, odnosno pri hijerarhijskom opisu funkcija sistema. Pored toga potrebno je znati i pod kojim uslovima treba prekinuti dalju dekompoziciju procesa, a to znai prepoznati primitivne procese koji se dalje ne dekomponuju. Kao to je to na slici 12 prikazano, na vrhu hijerarhije se nalazi Dijagram konteksta. Njegovom dekompozicijom se dobija tzv. Prvi nivo dekompozicije. Daljom dekompozicijom dijagrama prvog nivoa, dobijaju se dijagrami drugog nivoa iji ukupan broj odgovara ukupnom broju procesa sa prvog nivoa. Postupak se sukcesivno nastavlja na sljedeem nivou, sve dok se ne doe do nivoa primitivnih procesa. Sljedea pravila reguliu postupak dekompozicije: Pravilo balansa tokova. Najznaajnije pravilo koje se mora potovati pri dekompoziciji procesa je pravilo balansa tokova: Ulazni i izlazni tokovi na celokupnom DTP-u koji je dobijen dekompozicijom nekog procesa P moraju odgovarati ulaznim i izlaznim tokovima Strana 18/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza toga procesa P na dijagramu vieg nivoa (, str. 354). Drugim reima, svi tokovi koji ulaze i izlaze iz procesa moraju se pojaviti i na DTP sljedeeg nivoa, koji taj proces dekomponuje. Slika 13 ilustruje pravilo balansa tokova. Tokovi podataka TP1, TP2 i TP3 procesa ProcesA identifikovani na nivou N, javljaju se i na DTP nivoa N+1, koji dekomponuje ProcesA. Meutim, mogue je odstupiti od ovog pravila u sluaju dekompozicije samih tokova podataka. Ukoliko je na viem nivou hijerarhije uveden tok podataka koji se sutinski sastoji iz vie pojedinanih tokova, na sljedeem nivou se on moe dekomponovati i time prividno naruiti balans tokova. Na slici 14 je dat primer dekompozicije tokova podataka StudentskiZahjtev i StudentskoUvjerenje koji se dekomponuju na sljedeem nivou u tokove ZahtjevZaStatusom, ZahtjevZaPolIspit, UvjerenjeOUpisu i UvjerenjeOPolIspit, respektivno. Dekompozicija tokova podataka se eksplicitno dokumentuje u Rijeniku podataka (vidi poglavlje 3.3.4), ime balans tokova u hijerarhiji dijagrama ostaje nenaruen.

Slika 13 Opti primjer Pravila balansa tokova

Slika 14 Dekompozicija tokova podataka Pravilo numerisanja procesa i dijagrama: Procesi se u cilju lake itljivosti i preglednosti numeriu na sljedei nain. Procesi na Prvom nivou dekompozicije se numeriu redom sa 1, 2, ...N. Svaki dijagram nieg nivoa nosi oznaku procesa kojeg dekomponuje, a u njemu Strana 19/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza sadrani procesi na taj broj dodaju svoj jedinstveni broj. Dakle, dekompozicija procesa 1 predstavljena je dijagramom sa oznakom 1, i sastoji se od M podprocesa sa oznakama 1.1, 1.2, 1.3...1.M. Pravilo se nastavlja za svaki sljedei nivo hijerarhije daljim dodavanjem jedinstvenog broja procesa sa tog nivoa, 1.1.1, 1.1.2, .... Skladita podataka. Skladita podataka, sa sistemske take gledita, predstavljaju stanja sistema, odnosno fundamentalne, unutranje karakteristike kako cijelog IS, tako i svakog pojedinanog procesa. Zbog toga se ona mogu pojaviti i na niim nivoima dekompozicije, iako se nisu pojavljivala na prethodnim (, str.14). 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 (, str.204). Dodatak pravilima dekompozicije. Nepisano pravilo pri dekompoziciji dijagrama glasi da se svaki proces moe dekomponovati najvie u sedam podprocesa, tanije da svaki dijagram ne treba da sadri vie od sedam plus ili minus dva procesa 11. Vei broj procesa od ovoga mogao bi znaiti da je preskoen jedan nivo apstrakcije.

Oigledno je da proces dekompozicije u jednom trenutku mora prestati. Prirodno, dekompoziciju prekidamo kada doemo do primitivnih procesa. Ali, postavlja se pitanje, kada se za jedan proces moe rei da je primitivan. Originalni autori metode SSA, Yourdon, DeMarco navode veoma opte i neprecizne kriterijume pod kojima definiu trenutak prestanka dekompozicije, kao na primjer: Dekompoziciju treba prekinuti onda kada se logika procesa moe opisati mini-specifikacijom veliine ne vee od jedne stranice teksta (, str. 83, 84). Jo jedan primjer navodi Yourdon: esto se odluka o daljem dekomponovanju utvruje kada zamolite korisnika da Vam objasni ta proces treba da uradi. Ako se korisnik najpre namrti, zatim duboko udahne i kae Pa, znate, to je jedna dugaka pria, ali pokuau da Vam objasnim... onda je vrlo vjerovatno da treba da nastavite sa dekompozicijom procesa (, 433 441). Neto precizniji kriterijum glasi da dekompoziju procesa treba prekinuti u trenutku kada svaki proces posjeduje samo jedan ulazni i jedan izlazni tok podataka. Izuzetak u ovom kriterijumu je postojanje malog broja primitivnih procesa, koji za generisanje jednog izlaza zahtijevaju vie od jednog ulaznog toka. Navedeni kriterijumi predstavljaju korisne savjete u definisanju kriterijuma za prekid dekompozicije procesa i pomau u davanju odgovora na pitanje kada je jedan proces primitivan. Meutim, na ovo pitanje se mora dati sutinski odgovor. Podsjetimo se da, sa jedne strane, izvravanje procesa u organizaciji odlikuje paralelizam obavljanja funkcija (vidi poglavlje 3.3.2.1 o procesu obrade). Paralelni procesi se nazivaju sutinski procesi jedne organizacije. Uz to, paralelizam sutinskih procesa omoguen je postojanjem sutinskih skladita, o emu je bilo rei u poglavlju 3.3.2.3 o skladitima podataka. S druge strane, u poglavlju 3.3.4.3 o primitivnim procesima, reeno je da se primitivni procesi izvravaju sekvencijalno i da se opis njihove logike, umesto dekompozicijom, moe opisati tehnikama za opis sekvencijalne logike (Pseudokod, Strukturni jezici i dr.). Upravo iz razlike u karakteru procesa koji se odvijaju u organizaciji, odnosno iz razlike izmeu paralelnih i
11

Psiholog-matematiar George Miller je u svom radu, koji se bavi problemikom granica ljudske sposobnosti pri obradi informacija, doao do zakljuka da ljudi mogu efikasno da obrauju, odnosno prate u jednom trenutku sedam plus minus dva predmeta, odnosno koncepta. Preko tog broja se broj greaka u obradi informacija disproporcijalno poveava, odnosno efikasnost opada. Taan naziv publikovanog rada je: The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information . Ovaj zakljuak bio je fundamentalan za razvoj svih strategija za segmentiranje, dekomponovanje problema na podprobleme, u cilju njegovog lakeg savladavanja uz minimum greaka.

Strana 20/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza sekvencijalnih procesa Lazarevi dopunjuje originalne autore i izvodi osnovni kriterijum dekompozicije u SSA: Dekompoziciju treba vriti dok se neka funkcija prirodno moe dekomponovati na sutinske paralelne funkcije koje meusobno komuniciraju iskljuivo preko sutinskih skladita. Drugim rijeima, dekompoziciju treba okonati kada se doe do procesa koji su prirodno sekvencijalni. I sami alati SSA podravaju ovaj kriterijum - Dijagrami toka podataka za opis paralelnih procesa, a Pseudokod (Dijagram toka programa) za opis sekvencijalnih procesa (, str.361). 1.3.4.4. Dijagram hijerarhijske dekompozicije

Kao rezultat funkcionalne dekompozicije dobija se hijerarhijski ureen skup Dijagrama tokova podataka, kojim su postupno opisane sve funkcije jednog sistema. Oekivano je da sa poveanjem kompleksnosti sistema raste i broj kreiranih DTP, odnosno broj funkcija sistema. Jedan nain za, tako rei, navigaciju kroz gomilu dobijenih dijagrama i procesa je praenje hijerarhijske numeracije dijagrama i procesa o kojoj je bilo rei u prethodnom poglavlju. Ipak, javlja se potreba za jednom preglednom, a ipak dovoljno detaljnom, globalnom predstavom sistemskih funkcija. U tom smislu se, za prikaz svih funkcija sistema ili njegovog dela koristi hijerarhijski dijagram dekompozicije. Slika 15 daje opti prikaz jednog dijagrama dekompozicije.

Slika 15 Opti primjer Dijagrama hijerarhijske dekompozicije Postupak izgradnje ovog dijagrama je vie nego jednostavan. Dovoljno je pratiti hijerarhijsku numeraciju dijagrama i procesa i shodno tome, sastaviti hijerarhijski ureen skup svih procesa sistema ili pojedinih delova. Obino se u dokumentaciji specifikacije nekog sistema Dijagram dekompozicije koristi kao sadraj za laku navigaciju kroz Dijagrame tokova podataka koji ine jednu specifikaciju. Uloga Dijagrama dekompozicije je analogna ulozi sadraja jedne knjige, koji daje cjelokupan pregled sadranih poglavlja.

Strana 21/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza 1.3.5. Rijenik podataka Dijagrami tokova podataka prikazuju sve procese jednog sistema izvedene postupnom dekompozicijom sistema, kao i pakete podataka, koji tokovima podataka cirkuliu u sistemu, odnosno koji bivaju sauvani u skladitima podataka. Pored strukture procesa sistema dobijene detaljnom dekompozicijom, DTP u pogledu podataka daju samo uvid u to, koji podaci se u sistemu pojavljaju, bez detaljnijeg bavljenja njihovom strukturom, tj. strukturom tokova podataka i skladita podataka. Ba kao i procesi, i tokovi podataka i skladita mogu imati sloenu strukturu, pa je potrebno dekomponovati ih na prostije elemente. Dekompozicija tokova podataka i skladita se opisuje u Rijeniku podataka. Rijenik podataka (RP) predstavlja alat za strukturirani opis podataka u sistemu, odnosno opis njihovog sadraja i strukture. Opis je strukturiran zato to RP definie poseban skup koncepata i pravila za opis podataka, odnosnu sintaksu za opis strukture podataka12. Sintaksa za opis strukture e biti objanjena u predstojeem dijelu ovog poglavlja. Najprije se objanjava koje su to osnovne, primitivne komponente strukture podataka i na koji nain se one definiu. Zatim se uvode mogui oblici strukture sloenih tokova podataka i skladita. 1.3.5.1. Primitivne komponente strukture

Osnovne, primitivne komponente strukture podataka predstavljaju elementarni podaci, tzv. polja. Polja su osnovna komponenta strukture podataka jer predstavljaju podatke koji se dalje ne mogu dekomponovati. Primeri polja mogu biti: Ime, Prezime, BrLineKarte, Ocjena, Cijena, BrIndeksa itd. Svako polje ima svoju vrijednost. Skup iz kojeg jedno polje moe da uzima vrijednosti naziva se domen. Na primjer, polja Ime i Prezime mogu da sadre samo niz karaktera i to samo alfabeta, Ocjena i Cijena uzimaju vrijednosti iz skupa pozitivnih realnih brojeva itd. U primeru polja Ocjena, u cilju preciznije definicije, potrebno je suziti skup vrijednosti na podskup brojeva u intervalu od 5 do 10. Ogranienje nad domenom suava skup moguih vrijednosti koje polje moe da uzme iz domena. Po svojoj prirodi domeni mogu biti predefinisani ili semantiki domeni. Predefinisani domeni su standardni, sveprisutni domeni kao to su skup cijelih brojeva, skup realnih brojeva, skup karaktera ili skup logikih vrednosti (tano/netano). Semantiki domeni daju novo ime predefenisanim domenima i obino kroz ogranienje definiu samo podskup predefinisanog skupa elemenata. Na primjer, za polje Ocjena moe se definisati semantiki domen FakultetskeOcjene koji suava skup prirodnih brojeva na interval od 5 do 10. Uobiajeno je da se sva polja u Rijeniku podataka, njihovi domeni i ogranienja prikau preko odgovarajue tabele. Tabela 1 i Tabela 2 daju primer za opis polja, domena, odnosno domenskih ogranienja. POLJA NAZIV POLJA ImeIPrezime Ocjena VrstaStudija Cijena ... DOMEN CHAR(30) FakultetskeOcjene VrsteStudija REAL(10,2) ... Tabela 1 Tabela polja OGRANIENJE

>0 ...

12

Rijenik podataka metode SSA opisuje podatke ba kao to i bilo koji rijenik, npr. rijenik stranih termina i izraza opisuje sadraj i znaenje stranih pojmova. Za razliku od takvog rijenika u kome je opis neformalan, opisan prirodnim jezikom, Rijenik podataka SSA definie odgovarajuu sintaksu kojom se dobija strukturan, formalan opis. I uloga RP je slina klasinom rijeniku, jer slui da nedvosmisleno definie znaenje podataka u sistemu opisujui njihov sadraj i strukturu.

Strana 22/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza DOMENI NAZIV DOMENA FakultetskeOcjene VrsteStudija ...

PREDEFINISANI DOMEN INTEGER(2) CHAR(20) ... Tabela 2 Tabela semantikih domena

OGRANIENJE [5,10] (Osnovne, Magistarske, Doktorske) ...

Kao to se u primjeru vidi, za imena predefinisanih domena koriste se standardne oznake programskih jezika. Postoje razliite notacije za opis polja, domena i ogranienja. Ono to je bitno je da jednom preuzetu notaciju treba konzistentno primenjivati. Jedna detaljna specifikacija notacije za opis polja, domena i ogranienja moe se nai u . 1.3.5.2. Sloena struktura podataka

Tokovi i skladita podataka definisani na DTP obino imaju sloenu, kompozitnu strukturu. Tipini paketi podataka sa sloenom strukturom koji teku kroz jedan IS su dokumenta kao to su: Katalog (filmova, proizvoda), Narudbenica, Raun, Ispitna prijava, Uvjerenje, Cjenovnik i sl. Sloene strukture podataka se sastoje iz vie komponenata. Komponenta moe biti elementarna, tj. polje i/ili neka druga definisana sloena struktura. Na slici 16 je dat primjer dokumenta Narudbenice, koji se sastoji iz sljedeih polja: BrojNarudbenice, ifraKupca, NazivKupca, DatumNaruivanja. Pored polja, dokument Narudbenice sadri i jednu internu strukturu koju moemo nazvati ListaArtikala. ListaArtikala sa svoje strane sadri sljedei skup polja: RedniBroj, ifraArtikla, NazivArtikla, NarKoliina. NARUDBENICA Broj:00123 Podaci o kupcu ifra kupca: 009897342 Naziv kupca: SW-Inenjering D.o.o Adresa kupca: Ulica inenjera b.b, Beograd, SCG Lista artikala Redni broj 01 02 ... ifra artikla A-00222-1 C-30212-9 ... Naziv artikla Monitor Siemlips L2335 23 TFT Projektor Canjitzu XEED SX 50 ... Slika 16 Dokument Narudbenica Mogue su sledee konstrukcije kojima se od komponenata (primitivnih ili sloenih) gradi struktura (, str.18). Za svaku konstrukciju se navodi i nain njenog predstavljanja u Rijeniku podataka: 0. Agregacija komponenti. Agregacija predstavlja sloenu strukturu u vidu liste N komponenti, bilo elementarnih, bilo sloenih. Za njeno predstavljanje se koristi sljedea notacija: <K1, Strana 23/36 Koliina 6 1 ... Datum:12.12.2005

Uvod u informacione sisteme Skripta Strukturna sistemska analiza K2,...Kn.>, gde su K1, K2, Kn sastavne komponente strukture. Na primjer, tok podataka IspitnaPrijava se zapisuje na sljedei nain: IspitnaPrijava: <BrIndeksa, ImeStudenta, NazivPredmeta, DatumPolaganja, Ocjena, ImeNastavnika> 1. Specijalizacija (unija) komponenti. 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 untar kosih zagrada: /K1, K2, ...Kn/. Primjer specijalizacije u kojoj je mogue izabrati vie od jedne komponente je sloeni tok podataka Uvjerenje: Uvjerenje: </ UvjerenjeOUpisu, UvjerenjeOPolIspit /> Fakultet moe na zahtjev studenta da izda bilo uvjerenje o upisu, bilo uvjerenje o poloenim ispitima, bilo oba uvjerenja. 2. Skup (Iteracija). Skup je struktura u kojoj se jedna komponenta ponavlja vie puta, tj. iterira (kroz razliite vrijednosti komponente). Komponenta sa ponavljanjem se unutar neke strukture predstavlja vitiastim zagradama: {K1}. Primjer za strukturu skupa je upravo dokument Narudbenica sa Slike 16, koji u sebi pored elementarnih polja sadri i sloenu strukturu u vidu agregacije polja koja se viestruko ponavljaju: Narudbenica: <BrojNarudbenice, ifraKupca, NazivKupca, DatumNaruivanja, {<RedniBroj, ifraArtikla, NazivArtikla, NarKoliina>}> Ovakva struktura je vrlo esta i najlake se prepoznaje kod dokumenata koji u sebi pored elementarnih polja sadre i neki oblik nabrajanja u vidu tabele ili liste. Na kraju poglavlja o Rijeniku podataka recimo i to da u cilju izbjegavanja redudanse, rijenik treba sadri opis strukture svih tokova podataka i samo onih skladita koja nisu skladita ve opisanih tokova. Pored toga, strukture tokova podataka opisane Rijenikom predstavljaju solidnu osnovu za detaljni opis podataka, odnosno izgradnju modela podataka, o emu e biti rijei u poglavlju o Modelovanju podataka, odnosno modelu objekti i veze. 1.3.6. Postupak modelovanja U dosadanjem izlaganju je predstavljen kompletan alat za opis funkcija sistema u metodi SSA. Takoe su navedena pravila, preporuke i konkretni postupci pri izgradnji modela procesa. Meutim, potrebno je prodiskutovati i opti postupak modelovanja procesa metodom SSA, koji objedinjuje sve prethodno navedeno u jednu potpunu metodu za modelovanje funkcija sistema. S tim u vezi, postavlja se kao prvo opte pitanje, koji se sistem uopte analizira. Da li se modeluje Strana 24/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza postojee stanje sistema, odnosno postojea implementacija informacionog sistema neke organizacije ili se daje predlog budue verzije implementacije IS? Da li treba izgraditi model funkcija sistema nezavisno od tehnologije, odnosno budue implementacije ili sva tri prethodna sluaja treba modelovati? U ovom poglavlju se prvo daje odgovor na ova pitanja, a zatim sumira do sada izloeno navoenjem jednog mogueg postupka modelovanja. Logiki i fiziki modeli procesa Logiki model procesa predstavlja model sutinskih procesa realnog sistema (organizacije) nezavisno od tehnolokih i organizacionih ogranienja. Podsetimo se da se sutinski procesi karakteriu paralelizmom u izvravanju. Logiki model treba da odgovor na pitanje ta budui sistem treba da radi da bi zadovoljio zahtjeve korisnika, odnosno da bi ispunio ciljeve organizacije. Pri izgradnji logikog modela procesa sistem se posmatra nezavisno od toga kako je implementiran, tj. kao da je, ili e biti implementiran u idealnoj tehnologiji13. To izmeu ostalog znai da pri analizi procesa ne treba uzimati u obzir da li taj proces izvrava radnik u organizaciji ili je proces automatizovan postojeim, odnosno buduim IS, bitno je samo identifikovati potrebu postojanja procesa. S druge strane, fiziki model predstavlja model procesa informacionog sistema, uzimajui u obzir sva ogranienja postavljena tehnolokim i organizacionim okruenjem pri implementaciji tog IS u organizaciji. Fiziki model procesa koji analizira postojei IS naziva se snimak postojeeg stanja. Fiziki model procesa koji na bazi logikog modela procesa ukljuuje i specifina tehnoloka i organizaciona ogranienja budueg sistema predstavlja fiziki model budueg sistema. Cilj metode SSA je izgradnja logikog modela procesa sistema specificirajui tano ta sistem treba da uradi da bi zadovoljio organizacione ciljeve, ne razmatrajui kako e se sistem realizovati u specifinom tehnolokom i organizacionom okruenju. 1.3.6.1. Modelovanje logikog modela procesa

Klasian postupak modelovanja procesa zagovaran u originalnoj specifikaciji metode SSA je takozvani postupak Izdvajanja logikog iz fizikog modela procesa. Ideja se bazira na tome da se prvo uradi snimak postojeeg stanja, odnosno izmodeluje postojei fiziki model sistema, da bi se zatim iz tog modela izvukli sutinski procesi i dobio logiki model sistema, na taj nain to se uklanjaju sve komponente modela koje predstavljaju rezultat tehnolokih i organizacionih organienja. U kasnijim fazama se na bazi buduih ogranienja definie fiziki model budueg sistema. Ovaj postupak se pokazao kao neefikasnim u analizi, jer transformacija postojeeg fizikog u logiki model dosta zahtjevan zadatak i podloan subjektivnoj ocjeni analitiara. Vie o tome u (, str. 29, , str. 373 379). Jedan drugi postupak modelovanja, ovde od interesa, zagovara direktnu izgadnju logikog modela procesa tzv. postupak direktnog modelovanja logikog modela procesa ( str. 30 - 34). Ovaj postupak podrazumeva dobro poznavanje vrste sistema koji se analizira (bankarski, proizvodni, fakultetski, administrativni sistemi, sistem trgovine i dr). Polazi se od nekog opteg teorijskog poslovnog modela te vrste sistema (referentni model), a zatim se analiziraju karakteristike konkretnog sistema, da bi se opisali njegovi specifini zahtevi. Imajui u vidu postupak direktnog modelovanja i sve do sada prethodno navedene konkretne postupke i pravila za izgradnju pojedinih komponenti modela, odnosno dijagrama, moe se rei da se jedan postupak modelovanja logikog modela procesa metodom SSA moe podijeliti u dve osnovne faze:
13

Idealna je ona tehnologija koja je nezavisna od vremena i prostora, koja ne troi nikakve resurse i ne sadri greke.

Strana 25/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza Opis okruenja sistema. Opis okruenja sistema ima za cilj da definie svrhu postojanja sistema i kontekst u kojem on funkcionie, ne ulazei u detalje kako sistem iznutra funkcionie da bi ispunio ciljeve. To podrazumijeva: Definisanje osnovnog cilja i svrhe postojanja sistema koji se modeluje. Cilj je da se jednim kratkim, preciznim tekstom, ne veim od jednog pasusa, buduem korisniku (ili top-menadmentu org.) predstavi svrha postojanja sistema. Obino se iz ovog teksta vidi i koji su spoljni objekti u interakciji sa sistemom. Izgradnja dijagrama konteksta (DK). DK je detaljno obraen u ranijem tekstu (vidi poglavlje 3.3.4.3). Cilj: (1) identifikacija svih interfejsa, (2) za svaki od interfejsa, identifikacija svih dogaaja, odnosno informacija koje sistem prima i na koje reaguje odgovorom. Opis ponaanja sistema. Opis ponaanja sistema treba da prui sliku o tome kako sistem iznutra funkcionie da bi ispunio svoju svrhu. Razjanjava se kako sistem obrauje informacije koje prima i kako generie izlazne informacije - sistemski gledano, kako sistem reaguje na dogaaje iz okruenja. To se ostvaruje kroz: Hijerarhijski opis DTP. Zapoinje se sa dekomponovanjem DK na taj nain to se utvruju opti procesi koji obrauju jednu grupu povezanih informacija, odnosno koji reaguju na grupu povezanih dogaaja iz okruenja. Neophodno je procesima obuhvatiti sve ulazne i izlazne informacije identifikovane u opisu okruenja sistema. Dalje se postupak nastavlja potujui ranije opisana pravila. Meutim, treba na ovom mestu dodati da dekompozicija, ipak, ne mora biti striktno top-down proces. Nekad je teko uoiti big picture u startu. U tom sluaju treba poeti od nekog srednjeg nivoa na kome je slika jasnija i uoiti sitne procese koji se zatim grupiu u optije krupnije procese, to takoe vai i za tokove podataka. I kada pratimo top-down proces, esto se deava da analizirajui nivo N moramo da se popnemo na nivo N-1 i napravimo izmene, to nikako nije greka. Bitno je, pritom, voditi rauna o balansu tokova. U svakom sluaju, kao krajnji rezultat se uvek dobije hijerahijski top-down opis dijagrama. Opis podataka Rijenikom podataka(RP). Izgradnja Rijenika podataka moe otpoeti paralelno sa izgradnjom DTP, kada se opisuju sloeni tokovi i skladita podataka. Meutim, tek nakon izgradnje DTP se i RP moe kompletirati, tako to e se opisati svi elementarni tokovi i dekomponovati sloeni i na kraju provjeriti da li postoji redudansa u opisu i da li je RP u saglasnosti sa DTP. Specifikacija logike primitivnih procesa. Tek nakon to se opie i logika svih primitivnih procesa moe se rei da je potpuna specifikacija sistema metodom SSA gotova. Meutim, esto se u praksi specifikacija logike ostavlja za sljedeu fazu u razvoju IS ili se koriste drugi alati za opis, zbog ega mini-specifikacije nisu od znaaja za ovo poglavlje.

Postoji jo jedan postupak modelovanja, kao opti pristup koji je se primjenjuje za modelovanje sloenijih poslovnih sistema i koji se bazira se na Analizi ivotnih ciklusa osnovnih djelatnosti i resursa u sistemu, po emu pristup nosi naziv. Dalja analiza ovog postupka prevazilazi okvire poglavlja, pa se italac upuuje na navedenu literaturu (, str. 358 - 361). 1.4. Ostali pristupi za modelovanje funkcija sistema

Pristupe za modelovanje funkcija sistema moemo podijeliti na konvencionalne i savremene. Pored podjele na konvencionalne i savremene, pristupi se meusobno razlikuju i po konkretnoj Strana 26/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza specifinosti primjene, jer modelovanje funkcija sistema se moe koristiti, s jedne strane, za modelovanje poslovanja i s druge strane, za specifikaciju aplikacija. Ovim poglavljem e se samo ukratko navesti nekoliko najzastupljenijih konvencionalnih i savremenih metoda i pomenuti njihova specifina namjena. Opirnije bavljenje ovim metodama za modelovanje funkcija sistema prevazilazi potrebe ovog udbenika. U tom smislu se italac upuuje na navedenu listu ire literature. 1.4.1. Konvencionalni pristupi SSA spada u red konvencionalnih metoda. Kao to je reeno, SSA predstavlja metodu za analizu sistema i specifikaciju korisnikih zahteva, ime prua osnovu strukturnog pristupa razvoju softvera. SSADM (Structured Systems Analysis and Design Methodology SSADM) predstavlja specifinu implementaciju originalne metode SSA i dugo godina je bila koriena kao referentna metodologija za razvoj informacionih sistema u vladi Velike Britanije . U red konvencionalnih, strukturnih metoda spada i IDEF0 (Integration Definition for Function Modeling), standard dravnih organa SAD za modelovanje funkcija . IDEF0 standard je baziran na metodologiji SADT (Structured Analysis and Design Technique), razvijenoj u kompaniji SofTech . IDEF0 standard s jedne strane nalazi primjenu u projektima analize, razvoja, reinenjeringa i integracije IS. S druge strane koristi se kao tehnika modelovanja poslovnih procesa u cilju analize, simulacije, reinenjeringa i dokumentacije poslovnih procesa organizacije. Slino kao i SSA, IDEF0 standardni jezik za modelovanje funkcija se karakterie jednostavnim, grafikim konceptima, hijerarhijskim postepenim dekomponovanjem funkcija, to doprinosi da modeli budu lako razumljivi i neinformatiarima, ali i dovoljno precizni za detaljnu specifikaciju IS. Grupi konvencionalnih pristupa modelovanju funkcija sistema pripadaju i Petrijeve mree, kao alat za modelovanje dinamike sistema14. Za razliku od DTP u metodi SSA, Petrijeve mree modeluju sekvencu izvravanja funkcija (opis logike izvravanja funkcije u vremenu analogno Dijagramu toka programa). Klasine Petrijeve mree su tokom godina pretrpjele znaajna proirenja kako bi odgovorile na zahtjeve modelovanja funkcija kompleksnih i velikih sistema. Mogunost modelovanja podataka i vremena i koncept hijerahijske dekompozicije velikih modela su najznaajnija proirenja u tom smislu (, str. 41 - 48). 1.4.2. Savremeni pristupi Savremene pristupe za modelovanje funkcija sistema moemo podijeliti u dve grupe. Prvu grupu ine pristupi koji se prvenstveno koriste za specifikaciju softvera. Meutim, ovi pristupi se uz odgovarajua proirenja mogu koristiti i za analizu poslovnih sistema, odnosno modelovanje funkcija sistema. Drugu grupu ine pristupi koji imaju specifinu namjenu u modelovanju poslovanja, odnosno modelovanju poslovnih procesa organizacije. 1.4.2.1. Pristupi za specifikaciju softvera

U prvu grupu pristupa spadaju Modeli sluajeva korienja i Dijagrami aktivnosti, koji predstavljaju komponente UML-a (Unified Modeling Language), standardnog jezika za analizu i dizajn u sklopu objektno-orijentisanog pristupa razvoju softvera . Modeli sluajeva korienja (SK) se originalno koriste kao alat za specifikaciju aplikacija15, na taj nain to se, kako samo ime kae, za svakog korisnika
14

Petrijeve mree potiu iz radova Karla Adama Petrija (Carl Adam Petri), koji je ovaj jezik formalizovao u svojoj doktorskoj tezi (Komunikation mit Automaten) ranih ezdesetih godina . 15 Pojam aplikacije u ovom razmatranju treba razlikovati od pojma informacionog sistema. Informacioni sistem kao sloeni sistem integrie vie specifinih aplikacija.

Strana 27/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza uoavaju sluajevi korienja, odnosno funkcije koje aplikacija treba da prui korisniku. Iako pronalaze primjenu u modelovanju funkcija sistema, Modeli SK se pokazuju kao neadekvatna metoda za modelovanje sloenijih sistema. Osnovni nedostatak ovog alata ogleda se u nepostojanju mehanizma dekompozicije funkcija, to predstavlja osnovni koncept za istovremeno jasno i detaljno opisivanje sistema (, str.367). Postoje i drugi pristupi koji proiruju koncepte Modela SK upravo u pogledu koncepta dekompozicije funkcija. Jedan takav pristup je UMM (UN/CEFACT (United Nations Centre ofr Trade Facilitation and Electrionic Business) Modelling Methodology) . Dijagrami aktivnosti (DA) kao standardna komponenta UML-a predstavljaju alat za opis logike sluajeva korienja. Kako samo ime kae, dijagrami aktivnosti modeluju redosljed izvravanja aktivnosti unutar funkcija sistema i za tu svrhu posjeduju moan skup koncepata kao to su koncept odluivanja, specifikacija paralelnog izvravanja (grananje aktivnosti i sinhronizacija), plivake staze (za prikaz izvrilaca aktivnosti) i dr. Koncepti definisani u DA vode poreklo iz prethodno pomenutih Petrijevih mrea. U sluaju modelovanja poslovnih procesa, za razliku od metode SSA i sluajeva korienja, DA omoguavaju detaljno modelovanje sekvence izvravanja procesa, ali u isto vreme takoe pate za eksplicitnim mehanizmom za dekomponovanje procesa. Meutim, UML je dovoljno opt jezik koji konceptom stereotipa omoguuje da se njegovi standardni alati, kao to su Modeli SK i DA, proire dodatnim konceptima specifine namjene. 1.4.2.2. Pristupi za modelovanje poslovnih procesa

Druga grupa savremenih pristupa za modelovanje funkcija sistema orijentie se iskljuivo na modelovanje poslovnih procesa organizacije u sklopu optijeg menadment koncepta Menadmenta poslovnih procesa (BPM Business Process Management). Sveobuhvatni koncept menadmenta poslovnih procesa predstavlja pristup za strategijsko planiranje, upravljanje, izvravanje i kontrolu poslovnih procesa uz podrku informacionih tehnologija (IT). Podrka IT se sastoji, s jedne strane, od softverskih alata za modelovanje poslovnih procesa, a sa druge strane, od informacionih sistema koji vre automatizaciju poslovnih procesa. Sr ovog pristupa ini modelovanje poslovnih procesa, kao metoda koja omoguuje dokumentovanje, analizu, optimizaciju, izvravanje i kontrolu procesa u organizaciji. Jezici za modelovanje poslovnih procesa moraju biti jednostavni i orijentisani s jedne strane ka poslovnim korisnicima, neinformatiarima i analitiarima, a s druge strane dovoljno detaljni za opis kompleksnih procesa i formalni u cilju njihove implementacije pomou IS. Sljedei pristupi definiu jezike za modelovanje poslovnih procesa u okviru opteg koncepta menadmenta poslovnih procesa. Dogaajem voeni lanci procesa (EPC Event-driven Process Chains) predstavljaju jedan jezik za modelovanje poslovnih procesa prvenstveno zastupljen u kompanijama zemalja njemakog govornog podruja16 . Jezik EPC se u osnovi takoe bazira na konceptima Petrijevih mrea. Osnovna ideja pri modelovanju procesa je sljedea: dogaaji u sistemu pokreu izvravanje procesa, i obratno, procesi proizvode dogaaje u sistemu, ime se formira lanac procesa voenih dogaajima. Tokom godina je ova metoda pretrpjela poboljanja u vidu proirenja za modelovanje organizacione strukture i uloga radnika, modelovanje podataka, kao i integraciju sa jezikom UML. ADONIS standardni jezik17, je metoda za modelovanje poslovnih procesa i jo jedan predstavnik njemake kole, a dio je sveobuhvatnog menadment koncepta
16

EPK (Ereignissteuerte Prozesskette) u originalnom nazivu, je jezik razvijen na Institutu za Poslovnu informatiku Univeziteta Saarland u saradnji sa softerskom kuom SAP za potrebe modelovanja poslovnih procesa. 17 ADONIS standardni jezik je razvijen na Institutu za Poslovni i inenjenring znanja, Univerziteta u Beu.

Strana 28/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza BMPS (Business Process Management Systems) . Ovaj jezik nudi koncepte za modelovanje, dokumentaciju i optimizaciju kako procesa tako i strukture organizacionih sistema. LOVEM (Line Of Visibility Enterprise Modeling) je metoda za modelovanje poslovnih procesa razvijena unutar firme IBM . BPMN. Najnoviji i najznaajniji jezik za modelovanje poslovnih procesa u vidu standarda u oblasti menamenta poslovnih procesa je BPMN18 (Business Process Modeling Notation) . Kao najnoviji standard, BPMN je razvijen sa ciljem da obuhvati sve prednosti ranijih pristupa u modelovanju poslovnih procesa sa posebnim osvrtom na jednostavne grafike koncepte namijenjene poslovnim korisnicima. Istovremeno, baziran na matematikim formalizmima, BPMN prua mogunost izgradnje modela procesa koji se lako mogu transformisati u izvrni jezik podran od strane specijalizovanih IS za automatizaciju poslovnih procesa. Napomenimo jo na kraju ovog razmatranja da su svi ovi pristupi za modelovanje funkcija sistema, kako konvencionalni, a posebno moderni podrani monim softverskim alatima za vizuelno modelovanje. Modeli poslovnih procesa dobijeni ovim alatima obino predstavljaju poetnu kariku u lancu modela koji ine osnovu savremenog, modelima voenog pristupa razvoju softvera. 1.5. Primjer-studija sluaja

U primjeru koji slijedi daje se analiza sistema e-prodavnice primjenom metode SSA. Logiki model procesa ovog sistema rezultat je primjene direktnog modelovanja, postupka modelovanja objanjenog u odeljku 3.3.6.2. Kao teorijski model posluio je klasini model trgovinskog poslovanja, koji je zatim prilagoen uzimajui u obzir specifinosti online prodaje roba i usluga, kao vid e-poslovanja. Dati primer je fiktivna studija sluaja, jer se ne odnosi ni na jedan realan sluaj, pa zbog toga ne uzima u obzir specifine karakteristike konkretnog realnog sistema. Studija sluaja pretpostavlja sljedeu situaciju: Novoformirano trgovinsko preduzee eli da izae na trite prodajom roba savremenim nainom poslovanja, putem interneta. Osnovna ideja lei u prodaji robe kupcima preko firminog web-sajta, dok se nabavka proizvoda trenutno vri klasinim nainom katalokog naruivanja od dobavljaa. Prodaja se vri na sljedei nain: Kupac poruuje proizvode na web-sajtu preduzea tako to iz liste artikala u ponudi bira eljene proizvode, tj. puni kupovnu korpu, koju zatim predaju na naplatu. Naplata se vri putem platnih kartica preko eksternog servisa za online-naplatu. Naplaeni proizvodi se otpremaju potom na adresu kupca. Radi sigurne kupovine, ali i prepoznavanja specifinih zahteva kupaca, vodi se evidencija o kupcima. 1.5.1. Opis okruenja sistema 1.5.1.1. Specifikacija svrhe informacionog sistema

Svrha uvoenja informacionog sistema e-prodavnice sastoji se u informacionoj podrci poslovnog procesa nabavke proizvoda od dobavljaa i poslovnog procesa online-prodaje proizvoda kupcima. Nabavka artikala podrazumijeva obradu kataloga dobavljaa, naruivanje artikala, njihov prijem i plaanje. Prodaja proizvoda preko web-sajta treba da registrovanim kupcima omogui poruivanje artikala preko kupovne korpe, naplatu porudbine platnom karticom kupca preko eksternog sistema za naplatu i otpremu naplaenih proizvoda.
18

BPMN je inicijalno razvijen u okviru BPMI (Business Process Management Initiative) a trenutno je u fazi standardizacije u okviru OMG (Object Management Group), neprofitnog tijela za specifikaciju standarda u oblasti informatike.

Strana 29/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza 1.5.1.2. Dijagram konteksta
KupovnaKorpa Raun PlatnaKartica Kupac SpisakArtikalaUPonudi OtpremnicaKupca Potvrda ZahtevKupca NalogZaOnlineNaplatu IzvetajOTransakciji IS e-Prodavnica Uplata Faktura Narudbenica Dobavlja Katalog OtpremnicaDob

Servis za online naplatu

Slika 17 Dijagram konteksta IS e-prodavnice 1.5.2. Opis ponaanja sistema 1.5.2.1. Dijagrami tokova podataka
Nabavke Faktura Katalog 1. Nabavka Narudbenica Uplata Dobavlja

Artikli

PoslovniPartneri

Katalozi

KupovnaKorpa Raun PlatnaKartica Kupac SpisakArtikalaUPonudi OtpremnicaKupca Potvrda ZahtevKupca 2. Prodaja

NalogZaOnlineNaplatu IzvetajOtransakciji

UplateKupca

Servis za online naplatu

Slika 18 Dijagram prvog nivoa dekompozicije

Strana 30/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza

OtpremnicaDob OtpremniceDob Artikli Dobavljai

1.2 Naru ivanje Narudbenica Narudbenice Dobavlja Katalozi Katalog

1.3 Prijem

Prijemnice

1.1 Obrada kataloga Faktura Uplata

1.4 Plaanje

Fakture

Slika 19 DTP 1 - Nabavka

2.4 Otprema Artikli OtpremnicaKupca Kupci OtpremniceKupca NaloziZaOtpremu SpisakArtikalaUPonudi Raun KupovnaKorpa 2.2. Poru ivanje UplateKupca ZahtevZaRegistraciju PotvrdaRegistrovanja ZahtevZaPromAdrese PotvrdaPromAdrese 2.1 Voenje evidencije o kupcu Kupac*

Kupac

Rauni

KupovneKorpe

PlatnaKartica Kupci* 2.3 Naplata

NalogZaOnlineNaplatu IzvestajOTransakciji

Servis za online naplatu

Slika 20 DTP 2 Prodaja

ZahtevZaRegistraciju Kupac PotvrdaRegistrovanja 2.1.1 Registracija kupca

PotvrdaPromAdrese

KupovneKorpe

Kupci

ZahtevZaPromAdrese 2.1.2 IzmenaAdrese

Slika 21 DTP 2.1 - Voenje evidencije o kupcu Strana 31/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza

2.2.1 Formiranje liste artikala u ponudi Kupci SpisakArtikalaUPonudi Artikli 2.2.2 Kompletiranje Porudzbine 2.2.4 Kreiranje naloga za otpremu

Kupac

KupovnaKorpa

NaloziZaO tpremu Rauni Ra un 2.2.3 Kreiranje rauna

KupovneKorpe

Slika 22 DTP 2.2 - Poruivanje

Rauni Kupci

2.3.1 Priprema naloga za naplatu PlatnaKartica

NaloziZaOnlineNaplatu Kupac UplateKupca

2.3.2 Slanje naloga za online-naplatu

NalogZaOnlineNaplatu IzvetajOTransakciji

Servis za sigurna Online plaanja

Slika 23 DTP 2.3 Naplata

Kupac

UplateKupca Kupci

OtpremnicaKupca

2.4.1 Izrada otpremnice

2.4.2 Auriranje stanja na skladitu

NaloziZaOtpremu

OtpremniceKupca

Artikli

Slika 24 DTP 2.4 - Otprema

Strana 32/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza 1.5.2.2. Dijagram dekompozicije
IS e-prodavnica

1. Nabavka

2. Prodaja

1.1 Obrada kataloga

2.1 Voenje evidencije o kupcu 2.1.1 Registracija kupca 2.1.2 Izmena adrese kupca

2.2 Poruivanje

2.3 Naplata

2.4 Otprema

1.2 Naruivanje

2.2.1 Formiranje liste artikala u ponudi

2.3.1 Formiranje naloga za naplatu

2.4.1 Izrada otpremnice

1.3 Prijem

2.2.2 Kompletiranje porudbine 2.2.3 Kreiranje rauna

2.3.2 Slanje naloga

2.4.2 Auriranje stanja na skladitu

1.4 Plaanje

2.2.4 Kreiranje naloga za otpremu

Slika 25 Dijagram dekompozicije IS "e-Prodavnica" 1.5.2.3. Rijenik podataka

OtpremnicaDob: <ifraDob, NazivDob, AdresaDob, BrojOtpr, DatumOtpr, BrojNar, DatumNar, {<RB, ifraArtikla, NazivArtikla, OtprKoliina, Vrednost>}> Prijemnica: <BrojPrijem, DatumPrijem, ifraDob, NazivDob, AdresaDob, BrojOtpr, DatumOtpr, {<RB, ifraArtikla, NazivArtikla, PrimKoliina, Vrednost>}> Katalog: <ifraDob, NazivDob, AdresaDob, BrKataloga, DatumIzdavanja, {<RB, {<ifraArtikla, NazivArtikla, OpisArtikla, CenaVP, CenaMP>}> Narudbenica: <BrojNarudbenice, DatumNaruivanja, ifraDob, NazivDob, AdresaDob, {<RB, ifraArtikla, NazivArtikla, NarKol>}> Faktura: <ifraDob, NazivDob, AdresaDob, BrojFakture, DatumFakture, BrojOtprem, DatumOtpr, OpisFakture, Iznos, RokPlaanja> Uplata: <BrojUplate, Datum, ifraDob, NazivDob, AdresaDob, BrojFakture, IznosUplate, RokPlaanja> PoslovniPartneri: <[Dobavljai, Kupci]> Dobavljai: <ifraDob, NazivDob, AdresaDob, Delatnost> Kupci: <ifraKup, ImeKup, PrezimeKup, AdresaKup, AdresaIspor, Telefon> Artikal: <ifraArtikla, NazivArtikla, OpisArtikla, VrstaArtikla> Raun: <BrojRa, DatumRa, ifraKupKorpe, DatumPorudb, ifraKupca, ImeKup, PrezimeKup, AdresaKup, AdresaIspor, IznosRa, Napomena > KupovnaKorpa: <ifraKupKorpe, DatumPorudb, ifraKupca, ImeKup, PrezimeKup, AdresaKup, AdresaIspor, Telefon, {<RB, ifraArtikla, NazivArtikla, NarKol>}> NaloziZaOtpremu: <ifraNalOtpreme, DatumNalOpreme, Opis, RokIsporuke, {<RB, ifraArtikla, NazivArtikla, NarKol>}> PlatnaKartica: <BrPlatneKartice, DatumIsteka, TipKartice, ifraKup, ImeKup, PrezimeKup, AdresaKup, Telefon> Strana 33/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza NalogZaOnlineNaplatu: <ifraNalOnlineNap, DatumNalOnlineNap, BrRaunaPrimaoca, BrPlatneKartice, DatumIsteka, TipKartice, ifraKup, ImeKup, PrezimeKup, AdresaKup, Telefon, BrojRa, DatumRa, IznosZaNaplatu, Napomena> IzvetajOTransakciji: <ifraIzvetajaTrans, DatumTransakcije, ifraNalOnlineNap, DatumNalOnlineNap, BrRaunaPrimaoca, BrPlatneKartice, DatumIsteka, TipKartice, ifraKup, ImeKup, PrezimeKup, AdresaKup, Iznos, StatusTransakcije> UplateKupca: <ifraUplateKup, ifraIzvetajaTrans, DatumTransakcije, ifraNalOnlineNap, DatumNalOnlineNap, ifraKup, ImeKup, PrezimeKup, AdresaKup, IznosUpl, Napomena > OtpremnicaKupca: <ifraOtprKupca, DatumOtprKup, ifraUplateKup, DatumTransakcije, ifraKup, ImeKup, PrezimeKup, AdresaIspor, Telefon, ifraNalOtpreme, DatumNalOpreme, Opis, RokIsporuke, {<RB, ifraArtikla, NazivArtikla, OtprKol>}> SpisakArtikalaUPonudi: <ifraSpiska, DatumIzdavanja, {<RB, ifraArtikla, NazivArtikla, OpisArtikla, Cena, Popust >}> ZahtevKupca: <[ZahtevZaRegistraciju, ZahtevZaPromAdrese]> ZahtevZaRegistraciju: <ifraZahtReg, DatumZahtReg, ImeKup, PrezimeKup, AdresaKup, AdresaIspor, Telefon, KorisnikoIme, Lozinka> ZahtevZaPromAdrese: <ifraZahtAdr, DatumZahtAdr, ifraKupca, ImeKup, PrezimeKup, StaraAdresaKup, NovaAdresaKup> Potvrda: <[PotvrdaRegistrovanja, PotvrdaPromAdrese]> PotvrdaRegistrovanja: <ifraPotvrdeReg, DatumReg, ifraZahtReg, DatumZahtReg, ImeKup, PrezimeKup, AdresaKup, Status, OpisUslovaKorienja> PotvrdaPromAdrese: <ifraPotvrdeAdr, DatumPromAdr, Status, ifraKupca, ImeKup, PrezimeKup, StaraAdresaKup, NovaAdresaKup > 1.6. Rezime

Strukturna sistemska analiza predstavlja jednu od metoda za analizu sistema, odnosno modelovanje funkcija sistema. U ivotnom ciklusu razvoja softvera se metoda SSA koristi u fazi analize sistema i specifikacije zahtjeva korisnika. Kao metoda modelovanja, ona jasno definie osnovne koncepte za opis funkcija sistema i postupak modelovanja; drugim reima, ona daje alat i uputstvo za njegovu upotrebu u cilju izgradnje modela. Osnovne karakteristike metode SSA su mali broj jednostavnih grafikih koncepata i postupak hijerarhijske dekompozicije funkcija sistema predstavljenih dijagramima tokova podataka. Originalno ili u izmenjenoj formi, kao osnova drugih pristupa, ona predstavlja najire korienu konvencionalnu metodu za modelovanje funkcija sistema. Metode modelovanja funkcija sistema se sa jedne strane koriste za funkcionalnu specifikaciju softvera, a sa druge strane za modelovanja poslovanja, odnosno modelovanje poslovnih procesa u organizaciji. U domenu funkcionalne specifikacije softvera najznaajniji savremeni pristup definie UML sa Dijagramima sluajeva korienja i Dijagramima aktivnosti. U domenu modelovanja poslovnih procesa, odnosno upravljanja proslovnim procesima najaktuelniji je BPMN standard. 1.7. Pitanja 1. Da li je poznavanje metoda za analizu sistema od vanosti iskljuivo informatiarima? Odgovor objasniti jednim primerom. 2. ta je sistem? Opiite svojim rijeima. 3. Navedite nekoliko primjera za sisteme, sa kojima se svakodnevno susreete. Opiite u grubim crtama sisteme na jedan od tri naina: verbalno, tekstualno, grafiki. Definiite granicu sistema u odnosu na sisteme koji ga okruuju i veze sa njima, a zatim analizirajte u najgrubljim crtama njegovu strukturu, odnosno pronaite njegove elemente i osnovne veze Strana 34/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza izmeu njih. Sa kog aspekta ste posmatrali sistem? Opiite sistem svom kolegi. Koji vam se nain da se objasni sistem uinio najlakim: verbalni, tekstualni, grafiki? 4. ta se podrazumijeva pod pojmom analize sistema? Objasnite opti postupak analize sistema. 5. ta se podrazumeva pod pojmom analize sistema u informatici? Koje vrste sistema su pritom predmet analize sistema? 6. Definiite pojam modela i njegovu osnovnu svrhu? 7. Koja vrsta modela se izgrauje u fazi analize sistema u procesu razvoja IS? 8. ta se podrazumijeva pod jednom metodom modelovanja? 9. Objasnite svojim rijeima metodu Strukturne sistemske analize, njenu namjenu, poloaj u ivotnom ciklusu razvoja IS. 10. Opiite ukratko Dijagram tokova podataka. Kako se na DTP posmatraju procesi? Navedite osnovne koncepte koji se pojavljuju na DTP. 11. Na koji nain se imenuju procesi na DTP? Koja od sljedeih imena su ispravna: Naruivanje proizvoda, Odjeljenje prodaje, Ispitna prijava, Prijava ispita, Raunovodstvo, Proraun ostalog? Zato je vano pravilno imenovati procese? 12. ime se karakterie izvravanje procesa u organizaciji? Odgovor upotpuniti primjerom. 13. Kako se tumai podatak predstavljen tokom, a kako skladitem podataka? U emu se razlikuje imenovanje tokova u odnosu na imenovanje skladita podataka? 14. ta se predstavlja interfejsom? Navesti ta se obino moe smatrati interfejsom jednog IS. 15. Da li proces na DTP moe da ima samo ulazni, odnosno samo izlazni tok? Obrazloiti odgovor. 16. Zato se ne preporuuje direktno povezivanje dva procesa tokom podataka? 17. Dva interfejsa, dva skladita, ili interfejs i skladite ne mogu direktno biti povezani tokom podataka. Zato? 18. Na koji nain se odrava jednostavnost u prikazu, preglednost DTP uprkos sloenosti sistema, odnosno velikom broju procesa i drugih komponenata? 19. Objasniti postupak hijerhijskog opisa DTP? Na kom principu se bazira ovaj postupak? 20. Koja je uloga Dijagrama konteksta? U emu se on razlikuje od ostalih DTP? Na koji nain je mogue efikasno identifikovati komunikaciju sistema sa okruenjem? 21. Na websajtu neke kompanije proitajte tekst o opisu kompanije i njenoj osnovnoj djelatnosti (obino u odeljku O nama), a zatim pokuajte da skicirate Dijagram konteksta. 22. ta su to primitivni procesi? emu slue mini-specifikacije primitivnih procesa? 23. Koje je najvanije pravilo koje regulie postupak dekompozicije DTP? 24. Kako se numeriu procesi na DTP? Da li numeracija procesa utvruje njihov redosljed izvravanja? 25. U kom sluaju je potrebno uvesti novo skladite podataka na DTP? 26. Da li je tano da svaki DTP mora da sadri sedam plus ili minus dva procesa? 27. Navedite sve kriterijume koji pomau da se odredi kada je potrebno prestati sa dekompozicijom jednog procesa Kako znamo da je jedan proces primitivan? 28. ta prikazuje Dijagram dekompozicije? 29. Koja je uloga Rijenika podataka u metodi SSA? 30. Navedite primjer polja koje uzima vrijednosti iz semantikog domena? 31. ta ini strukturu jednog toka, odnosno skladita podataka koji se opisuje u Rijeniku podataka? 32. Koje se konstrukcije koriste za opis strukture tokova i skladita podataka? 33. ta znai saglasnost DTP i Rijenika podataka? 34. Kako se zove model koji procese opisuje nezavisno od tehnolokih i organizacionih ogranienja, a kako model koji ta ogranienja ukljuuje? 35. Koji od ova dva modela se izgrauje u postupku modelovanja sistema metodom SSA? Kako se zove takav postupak? Strana 35/36

Uvod u informacione sisteme Skripta Strukturna sistemska analiza 36. Navedite postupak modelovanja metodom SSA? 37. Ako se top-down dekompozicijom procesa stiglo do nivoa N, da li se smatra grekom vrenje izmena, tj. vraanje na nivo N-1? 38. Kako se mogu podijeliti svi pristupi za modelovanje funkcija sistema? 39. Koji je najzaajni savremeni pristup za modelovanje funkcija u smislu specifikacije softvera, a koji u smislu modelovanja poslovanja, tj. modelovanja poslovnih procesa? 2. Koriena i preporuena literatura [1] Daenyer W.: Systems Engineering, 7. Auflage, Verlag Industrielle Organisation, Zrich, 1992. [2] Yourdon, E., Constantine, L.: Structured Design Fundamentals of a Discipline of Computer Program and Systems Design, 2nd ed, Yourdon Press, New York, 1978. [3] DeMarco, T.: Structured Analysis and System Specification, Yourdon Press Computing Series Prantice Hall, New Jersey, 1978. [4] Yourdon, E.: Moderne strukturierte Analyse: ein Standardwerk zur modernen Systemanalyse, 1. Auflage, Wolframs Fachverlag, Freiburg, 1992. Titel der englischen Originalausgabe: Modern Structured Analysis, Prentice Hall, 1989. [5] Lazarevi B., Marjanovi Z., Anii N., Babarogi S.: Baze podataka, FON, Beograd, 2003. [6] Lazarevi B., et al: Strukturna sistemska analiza, Laboratorija za informacione sisteme, 1995. [7] Miller G., The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, Psychological Review, Vol. 63, 1956, str. 81-97. [8] Goodland, M., Ashworth, C.: An Introduction to SSADM Version 4, McGraw Hill, 1993. [9] Integration Definition for Function Modelling (IDEF0), FIPS Publication 183, National Institute of Standards and Technologies, 1993. [10] An Introduction to SADT (Strctured Analysis and Design Technique), SoftTech, Inc, Waltham, Mass, 1976. [11] Petri Nets World: Online Services for the International Petri Nets Community, http://www.informatik.uni-hamburg.de/TGI/PetriNets/, odziv od 18.12.2005. [12] Van der Aalst, W.M.P., Van Hee K.: Workflow Management Models, Methods and Systems, MIT Press, Cambridge, MA, 2004. [13] Booch, G., Rambaugh, J., Jacobson, I: The Unified Modeling Language User Guide, Addison Wesley Object Technology Series, 1999. [14] UN/CEFACT Modeling Methodology, United Nation Center for Trade Facillitation and Electronic Business, Technical Modeling Working Group, February 2001, http://www.unece.org/cefact/, odziv od 19.12.2005. [15] Keller, G., Nttgens, M., Scheer, A.-W.: Semantische Prozemodellierung auf der Basis Ereignisgesteuerter Prozeketten (EPK), Verffentlichungen des Instituts fr Wirtschaftsinformatik, Heft 89, Universitt Saarbrcken, 1992, http://www.iwi.unisb.de/Download/iwihefte/heft89.pdf, odziv od 19.12.2005. [16] Karagiannis, D.: BPMS: Business Process Management Systems, In: ACM SIGOIS Bulletin, Vol.16, Nr 1, 1995, S. 10-13. [17] Khn, H., Karagiannis, D.: Modellierung und Simulation von Geschftsprozessen. In: WISU Das Wirtschaftsstudium, 30.Jg., Ausgabe 8-9, Lange Verlag, 2001, S. 1161 - 1170. [18] IBM Corporation: LOVEM Line of Visibility Engineering Methodology Users Guide, Version 3, Third Edition, IBM Canada Ltd., 1999. [19] Business Process Modeling Notation Version 1.0, Business Process Management Initiative (BPMI), 2004. http://www.bpmn.org/, odziv od 13.04.2005.

Strana 36/36