Projektovanje Informacionih Sitema-seminarski Rad

DOBOJ

Projektovanje informacionih sistema

Seminarski rad

Tema:

Modeliranje događaja

Profesor/asistent: Student:

Mr Gordana Jotanović, prof. inf.

SADRŽAJ

1.Uvod

2.

Pojam događaja kao djela logičkog procesa

3. Modeliranje procesa vođeno događajima

4. Matrica entiteti/ događaji

4.1. Generisanje matrica CASE alatima...8

4.2. Model istorije života entiteta...11

4.3. Dijagram prelaza stanja...13

4.4. Mape dijaloga...14

5. Zaključak

1. U v o d

Projektovanje informacionih sistema (IS) je kompleksna kreativna djelatnost koja zahtijeva sistemski pristup, metodologiju primjerenu tehnološkim mogućnostima. Za organizaciju koja modernizuje IS, i prati dostignuća u tehnologiji i metodologijiprojektovanja, nije svrsishodno težiti za standardom koji bi čvrsto definisao pristup,metodu, sredstva i dokumentaciju, ne uzimajući u obzir vrstu primjene, stepen razvoja IS, karakteristike korisnika i osobine realnog sistema u kome IS djeluje.

Brzi tehnološki razvoj zahtjeva da se dugoročno zna šta se hoće. Neophodno je imati strategijsku sliku razvoja IS, koja će obezbjediti kompatibilnost sistema i biti fleksibilna u prihvatanju nove tehnologije. Totalno integrisani IS je nedostižan i nepotreban. Ono što je potrebno je dovoljno slobode kako bi korisnici mogli da razvijaju svoju inicijativu u kreiranju sistema koji im je potreban. Pri tome je potrebno poštovanje pravila koja će omogućiti da razmjenjuju podatke, šta podrazumjeva zajedničku mrežu za prenos, zajednički model podataka i njihov standardni oblik.

U prošlosti je razvoj programskih proizvoda bio oslonjen na različite tipove alata za programiranje. U prvoj fazi razvoja u upotrebi su bili mašinski jezici (jezici 1. generacije), čija je čitljivost bila veoma mala i koji su zavisili od hardvera. U drugoj fazi se koriste asembleri (jezici 2. generacije), koji su, takođe, bili zavisni od hardvera i teško čitljivi. Poslije jezika 1. i 2. generacije, u trećoj fazi, u upotrebu su ušli jezici 3. generacije (3rd generation languages (3GL)). Jezici 3. generacije su, kao i mašinski jezici i asembleri, proceduralno orijentisani. Sa jezicima 3GL, u upotrebu je ušla i tehnika strukturiranog programiranja. Bitna karakteristika 3GL je njihova nezavisnost od hardvera.1

2.

Pojam događaja kao djela logičkog procesa

Sistem je skup različitih entiteta (ljudi i mašina) koji u toku vremena utuču uzajamno jedni na

druge da bi ostvarili jedan ili više ciljeva.

Model je apstraktno predstavljanje sistema. Odlikuje se strukturnom, logičkom i

matematičkom povezanošću. Model opisuje sistem kroz vreme, njegove entitete i atribute, podešavanje procesa, događaja i odlaganja.

Logički procesi (koje sačinjavaju funkcije, događaji i elementarni procesi) su akcije koji se

obavljaju bez obzira na način ugradnje i raspoložive resurse sistema. Neke metode poistovjećuju funkcije i procese. Stvarni problemi su preveliki i presloženi da bi se riješili odjednom („u komadu”) te je potrebno njihovo strukturno raščlanjivanje (razlaganje). Načelo je poznato i glasi „podijeli pa s/vladaj” (lat. divide et impera, eng. divide and conquer). Sistem se razlaže i opisuje hijerarhijskim modelima. Modeli sistema se oblikuju iterativnim razlaganjem sa vrha prema dolje. Razlagati se mogu: funkcije i procesi, organizaciona struktura, struktura podataka i struktura programske opreme.

Funkcije su skup logički povezanih trajnih poslovnih aktivnosti i zadataka (npr. djelatnost,

posao). Funkcije se obavljaju stalno (nemaju određeni početak i kraj). Funkcije obavljaju osobe, grupe radnika ili organizacione cjeline. Primjeri funkcija: Prodaja, proizvodnja, otprema, računovodstvo. Funkcija se može sastojati od desetina pa i stotina diskretnih procesa. Funkcije se mogu hijerarhijski razložiti do nivoa diskretnih procesa, koji obavljaju određeni zadatak kojim odgovaraju na poslovne događaje.

Događaj je logički dio posla koji se obavlja kao nedjeljiva cjelina. Često je u upotrebi i naziv

transakcija. Pokreće se diskretnim ulazom i završava nakon što proces odgovori odgovarajućim izlazom. Poslovni događaj može se predstaviti jedni procesom kojim sistem reaguje na taj događaj. Logički događaj dalje se razlaže do elementarnih procesa kojima se prikazuje reakcija sistema na taj događaj.

Proces (elementarni, primitivni proces) je postupak, način rada, doslijedna izmjena stanja.

Takođe, proces je diskretna odluka, aktivnost ili zadatak kojim se obavlja neki posao. Proces se obavlja uvijek na isti način (za određeni ulaz se dobija isti izlaz). Trajanje procesa je konačno i odredivo (poznati: početak, završetak i ponavljanje). Za obavljanje procesa se koriste sredstva (npr. ljudska, materijalna, finansijska).

Poslovna pravila su instrukcije i logika koji određuju proceduru obavljanja procesa. Ugrađuju

se u računarski program (npr. preduslovi izlaska na ispit, broj polaganja ispita, uslovi upisa).

Poslovna politika je skup poslovnih pravila. U većini poslovnih sistema predstavlja osnovu za

donošenje odluka.2

3. Modeliranje procesa vođeno događajima

Događaj je zgoda ili zbivanje u sistemu koja vodi ili pokreće procese sistema. Sâm događaj nije proces, nego okidač procesa koji se njime pokreće.

Primjer: Kupac dostavom narudžbe pokreće proces provjere da li se radi o narudžbi postojećeg

ili novog kupca, proces stvaranja podataka o narudžbi i stavkama narudžbe, provjeru prethodnih zaduženja kupca, provjeru stanja skladišta, itd.3

Događaji mogu biti: 1) Vanjski,

2) Vremenski i 3) Unutrašnji.

Vanjski događaji se pokreću od strane vanjskih entiteta, koji zahtijevaju informaciju ili

ažuriranje podataka (ulazni tokovi podataka). Imenuje se tako da naziv sadrži naziv vanjskog entiteta, npr. zahtjev za upis studenta ili zaprimanje narudžbe kupca.

Vremenski događaji su vremenski uslovljeni, npr. rok, učestalost (ulazni upravljački tokovi).

Imenuju se tako da naziv sadrži vremensku oznaku, npr. istek roka plaćanja računa, mjesečni obračun plata, zaključivanje ispitnog roka i slično.

Unutrašnji događaji su događaji stanja, odnosno posljedica prelaza sistema iz jednog stanja u

drugo na takav način da to zahtjeva obradu (ulazni upravljački tokovi), npr. isporuka robe sa skladišta zahtijeva naručivanje nove robe.

Raspodjela događaja vezanih za projektovanje IS:

1) Izrada dijagrama konteksta sistema, postavljanje početnog dometa projekta;

2) Izrada dijagrama funkcionalne dekompozicije, podjela sistema u logičke podsisteme i/ili funkcije;

3) Izrada popisa događaja i odziva, utvrđivanje poslovnih događaja na koje sistem mora odgovoriti. Elementi popisa su događaj, ulaz i izlaz;

4) Izrada dijagrama dekompozicije događaja, dodavanje procesa za rukovanje događajima. Dodaje se po jedan proces za svaki utvrđeni događaj;

5) Izrada dijagrama događaja, odnosno razrada procesa za obradu događaja. Izrađuje se po jedan dijagram za svaki događaj;

6) Izrada dijagrama sistema, odnosno udruživanjem dijagrama događaja;

7) Izrada primitivnih dijagrama. Razrada dijagramom toka podataka koji sadrži osnovne procese, spremišta i tokove za svaki pojedini događaj.

3_{http://oliver.efos.hr/nastavnici/jmesaric/modeliranje/P1MODELIRANJE%20I%20IMPLEMENTACIJA%20INFORMACIJSKIH} %20SUSTAVAII.pdf

Opšti prikaz dijagrama sistema izrađen modeliranjem procesa vođenim događajima prikazan je na slici 1.

Slika 1. Primjer modeliranja procesa vođeno događajima4

4.

Matrica entiteti/ događaji

Matrica entiteti/događaji omogućava pogled na sistem usmjeren događajima. Matrica sadrži

događaje (redovi) i entitete (stupci). Elementi koji prikazuju učinak događaja na entitete su:5

1) stvaranje – C (reate),

2) čitanje - R (read) (u nekim metodama se ne bilježi), 3) ažuriranje - U (update) ili M (odify),

4) brisanje - D (elete). Proces izrade matrice:

1) prepoznati sve događaje za dati entitet 2)prepoznati događaje koji kreiraju entitet(C)

3) prepoznati događaje koji brišu entitet (D) prepoznati događaje koji mijenjaju

Entitet (entity) je nešto što postoji u stvarnom svijetu i posjeduje osobine koje ga opisuju i po kojima se razlikuje od svoje okoline. Definicije entiteta istaknutih autora su:

1) stvar koja se može zasebno identifikovati [Chen, 1976],

2) bilo koji objekat koji se može razlikovati i predstaviti u bazi podataka [Date, 1986], 3) logička reprezentacijapodatka [Finkelstein, 1989],

4) bilo šta o čemu pohranjujemo informaciju [Martin,1989]. Entitet može biti:

1) osoba, npr. Petar Kočić,

2) objekat, npr. roman Zločin i kazna,

3) apstraktni pojam, npr. engleski jezik ili iskustvo (poznavanje jezika), 4) ustanova (ETF),

5) poslovni sistem (Hotel Proljeće ili Elektroprivreda),

6) događaj (situacija, stanje) - prošli, sadašnji ili budući, npr. rođenje, školovanje, zaposlenje, penzionisanje,

7) povezanost različitih objekata stvarnog svijeta, npr. srodstvo.

Završetak je kada se ostvari da svaki događaj ima učinak na barem jedan entitet, a svaki entitet mora imati događaj koji ga stvara i briše.

Prije konacne izrade sheme (detaljnog plana o bazi podataka) služimo se pomocnom ´ fazom koja se zove modeliranje entiteta i veza (Entity-Relationship Modelling). Cilj je izgraditi manje preciznu konceptualnu shemu (ER-sheme) koje su apstrakcija realnog svijeta.

U praksi se može poistovjetiti pojam entitet sa skupom entiteta, ako se ne razmatraju konkretni podaci. Označava se imenicom (u jednini), npr. Osoba, Fakultet. Entiteti mogu poprimiti različite uloge u zavisnosti od konteksta, npr. Osoba je Kupac i/ili Dobavljač, Student ili Nastavnik.6

5 _{Poliščuk E. J., Novi pristup razvoju informacionih sistema, JISA INFO, časopis Jugoslovenskog informatičkog saveza , Beograd, 1996.}

Pojednostavnjeni primjer matrice događaj/entitet za rezervaciju sobe u hotelu Proljeće, prikazan je na slici 2.

Slika 2. Primjer matrice događaj/entitet7

Prednosti kreiranja matrice entiteti/događaji:

1) kontrola da svaki entitet ima događaj koji ga stvara i briše 2) fokusiranje na sve ono što se može dogoditi određenom entitetu

3) daje novu perspektivu na analizu sustava (osigurava kompletnost procesa) 4) osigurava da se svi entiteti na koje uteče jedan događaj promatraju zajedno Za entitet (koji utječe na druge entitete i često se mijenja) pita se:

1) koji događaj uzrokuje kreiranje nove instance entiteta? 2) koji događaj uzrokuje promjenu instance entiteta?

3) koji događaj uzrokuje brisanje postojeće instance entiteta?

4.1. Generisanje matrica CASE alatima

CASE predstavlja skraćenicu od engleskih reči "Computer Aided Software Engineering", što bi u prevodu značilo "računarom podržano softversko inženjerstvo" ili, slobodnije, "razvoj programskih proizvoda uz pomoć računara".

CASE proizvod je bilo koji programski proizvod, namenjenGenerisanje matrica CASE alatima biće ilustrovano kreiranjem matrica Funkcije/Tipovi entiteta i Funkcije/ Atributi pomoću Matrix Diagrammer-a iz sastava Designer-a 2000, ORACLE. Matrice Funkcije/Tipovi entiteta i Funkcije/ Atributi se projektuju tako da se u njima pojavljuju sve elementarne funkcije.

Slika 3. Matrica Elementarne funkcije/Tipovi entiteta8

Na slici 3. je prikazana matrica Elementarne funkcije/Tipovi entiteta za aplikaciju Komercijalni poslovi.

Načini upotrebe tipa entiteta u zavisnosti od funkcije, kod matrice Funkcije/Tipovi entiteta, mogu biti:

1) Create (C), sa značenjem da je zadatak funkcije formiranje nove pojave posmatranog tipa entiteta,

2) Retrieve (R), sa značenjem da je zadatak funkcije preuzimanje podataka o postojećim pojavama tipa entiteta,

3) Update (U), sa značenjem da je zadatak funkcije modifikacija podataka o postojećim pojavama tipa entiteta,

4) Delete (D), sa značenjem da je zadatak funkcije brisanje pojave tipa entiteta, 5) Archive (A), sa značenjem da je zadatak funkcije da posebnim postupcima arhivira pojave tipa entiteta, i

6) Other (O), sa značenjem da funkcija ima zadatke koji prethodnim načinima upotrebe nisu pokriveni.

Slika 4. Matrica Elementarne funkcije/Atributi za tip entiteta KUPAC9

Slika 5. Matrica Elementarne funkcije/Atributi za tip entiteta SKLADISTE10

9_{Poliščuk E. Jarolsav, Projektovanje informacionih sistema, Elektrotehnički fakultet, Podgorica 2007.} 10_{Poliščuk E. Jarolsav, Projektovanje informacionih sistema, Elektrotehnički fakultet, Podgorica 2007.}

Slika 6. Matrice Elementarne funkcije/Atributi za tip entiteta ROBA11

Na slici 4, 5 i 6 su prikazane matrice Elementarne funkcije/Atributi, za tipove entiteta KUPAC, SKLADISTE i ROBA za istu aplikaciju.

Načini upotrebe atributa tipova entiteta u zavisnosti od funkcije, kod matrice Funkcije /Atributi, mogu biti:

1)Insert (I), sa značenjem da je zadatak funkcije da prvi put zadaje vrijednost atributa tipa entiteta,

2)Retrieve (R), sa značenjem da je zadatak funkcije preuzimanje postojeće vrijednost atributa tipa entiteta,

3)Update (U),sa značenjem da je zadatak funkcije modifikovanje prethodno zadane vrijednosti atributa tipa entiteta,

4) Nullify (N), sa značenjem da je zadatak funkcije omogućavanje zadavanja nula vrijednosti za atribut tipa entiteta, koji prethodno nije imao nula vrijednost,

5) Archive (A), sa značenjem da je zadatak funkcije da posebnim postupcima arhivira vrijednosti atributa tipa entiteta, i

6)Other (O), sa značenjem da funkcija ima, u odnosu na vrijednosti atributa tipa entiteta, zadatke koji prethodnim načinima upotrebe nisu pokriveni.12

4.2. Model istorije života entiteta

Istorijat života entiteta je pogled na sistem usmjeren učincima događaja koji uzrokuju promjene stanja. Opisuje vremenski zavisno ponašanje (jednog) entiteta, odnosno prati promjene ponašanja

11 _{Poliščuk E. Jarolsav, Projektovanje informacionih sistema, Elektrotehnički fakultet, Podgorica 2007.}

12_{Blagojević Branko, Modeliranje strukturnih sustava broda događajima-doktorski rad, Sveučilište u Zagrebu. Fakultet strojarstva i brodogradnje,}

entiteta koji prolazi kroz sistem. Dijagram podudarnosti učinka (Effect Correspondence Diagram – ECD), za opšti slučaj je prikazan na slici 7, a za rezervaciju sobe u hotelu Proljeće na slici 8.

Slika 7. Dijagram podudarnosti učinka za opšti slučaj13

Slika 8. Dijagram podudarnosti učinka za rezervaciju sobe u hotelu Proljeće14

13_{Poliščuk E. Jarolsav, Projektovanje informacionih sistema, Elektrotehnički fakultet, Podgorica 2007.} 14_{Poliščuk E. Jarolsav, Projektovanje informacionih sistema, Elektrotehnički fakultet, Podgorica 2007.}

Dijagram života entiteta ima sledeće prednosti: 1) daje vizuelni prikaz izoliranog entiteta,

2) unosi vremensku strukturu na sve događaje koji mogu uticati na entitet kroz njegovo postojanje u sistemu,

3) određuje redoslijed procesa u dijagramu toka podataka itd.

4.3. Dijagram prelaza stanja

Dijagram prelaza stanja se zasniva na ideji mašine sa konačnim brojem stanja, hipotetičkom mehanizmu koji u nekom trenutku može biti u jednom od konačno mnogo diskretnih stanja. Predstavljaju grafički prikaz promjena stanja, tj vremenski zavisnog ponašanja sistema.

Elementi prikaza su:

1) stanje, kumulativni rezultat ponašanja nekog objekta (pravougaonik, krug ili elipsa),

2) prelaz, promjena stanja uzrokovana nekim događajem (usmjerena linija od jednog stanja prema drugom) i

3) događaj, uslov promjene stanja i akcija koja se obavlja (opis linije prelaza oblika događaj/akcija).

Dijagram prelaza stanja najčešće opisuje vremenski zavisno ponašanje čitavog sistema. Manji sistemi se mogu prikazati jednim dijagramom, dok veći sistemi se razlažu slično dijagramima toka podataka, pri čemu stanje na nekom nivou postaje početno stanje dijagrama na nižom nivou.

Primjenjuju se kod razvoja sistema za rad u stvarnom vremenu (real-time system), jezičke analize (parsing) i dizajna korisničkog interfejsa. Dijagrami prelaza stanja sistema za rad u stvarnom vremenu se razlikuju po tome što sadrže posebno stanje "besposlen". Na slici 9 je prikazan Dijagram prelaza stanja Sokomata hotela Proljeće ili Bankomata banke Montenegro, na kome su naglašena stanja „čekanje”.15

Slika 9. Dijagram prelaza stanja Sokomata hotela Proljeće ili Bankomata banke Montenegro16 15_{http://web.efzg.hr/dok/inf/uis/PIS-%204.pdf}

4.4. Mape dijaloga

Korisnički interfejs u mnogim aplikacijama se može promatrati kao konačni automat. Jedan element interfejsa (odabirač, radna površina, komandna linija ili dijalog prozor) može biti aktivan u određenom trenutku. Korisnik može doći do ograničenog broja drugih elemenata u zavisnosti o akcijama koje preduzima. Broj putanji kojima korisnik može mijenjati dijaloge je obično vrlo velik, ali je konačan, i mogućnosti su, najčešće, poznate.

Mape dijaloga prikazuju sistem na visokom nivou apstrakcije. Prikazuju elemente dijaloga u sistemu i mogućnost navigacije između njih, ali ništa ne govore o dizajnu ekranske forme. Korisnici i razvojni tim mogu zajednički razmatrati dijalog mape kako bi postigli zajednički stav o tome kakva treba biti korisnikova interakcija sa sistemom kako bi se izvršio određeni zadatak. Dijalog mape su, takođe, korisne kod modeliranja vizuelne arhitekture web sjedišta, pa se ponekad tako i nazivaju (eng. site maps). Navigacioni linkovi u sjedištu pojavljuju se kao tranzicije na dijalog mapi. Koristi se notacija dijagrama prijelaza stanja. Uslov koji pokreće korisničku navigaciju prikazan je kao tekst na strelicama.17

Postoji nekoliko vrsta pokretačkih uslova: korisnička akcija, kao što je pritisak tastera ili klik na link ili dugme dijalog prozora, vrijednost podataka, kao što je pogrešan unos koji pokreće pojavljivanje poruke o grešci, sistemski uslov, kao što je signal da je pisač ostao bez papira i kombinacija navedenih, kao što je kucanje opcije iz ekranske forme iv pritisak na taster Enter. Radi pojednostavnjenja mogu se izostaviti neke opšte funkcije, npr. pritiskanjev tastera F1 da bi se dobila pomoć ili standardni navigacijski linkovi koji se pojavljuju na svakoj stranici.

Dijalog mape mogu prikazati alternativne putove kao grane koje odstupaju od uobičajenog puta, npr. uobičajeni put bi bio naručiti hemikaliju od vanjskog dobavljača, a alternativno se hemikalija može dobiti iz zaliha hemijske laboratorije. Prilikom analize zahtjeva, dijalog mapa predstavlja interakciju korisnika i sistema na konceptualnom nivou. Konkretna ugradnja može biti drugačija.18

Primjer: Korisnik inicira model korištenja odabirom opcije "zatraži hemikaliju" iz glavnog

odabirača. Polazna tačka za ovaj model korištenja je popis traženih hemikalija koji se naziva "Trenutna lista zahtjeva".19

5.

ZAKLJUČAK

17_{Božičković Z., Upravljanje informacijama u logistici- skripta, Saobraćajni fakultet, Doboj 2011.} 18_{http://www.docstoc.com/docs/102856262/Modeliranje-i-simulacija-sistema}

U radu su izložene osnovne postavke modeliranja događaja kao djela logičkog procesa u projektovanju informacionog sistema. U pogledu strukture budućeg IS menadžment kompanije postavlja zahtjeve u pogledu baze podataka, aplikacija i izvještaja. Baza podataka može biti jedna za cijelu kompanija ili nekoliko baza podataka, koje su međusobno povezane. IS može imati više aplikacija tj. programskih cjelina, koje pokrivaju pojedine organizacione cjeline. Vodeće svjetske kompanije su razvile IS-e iz različitih privrednih oblasti koji nude i implementiraju u drugim kompanijama. Najpoznatije svjetske kompanije, koje se bave razvojem IS su: SAP, ORACLE, MRO, IBM, Microsoft i dr. Svaka kompanija koja je tržišno orjentisana mora da analizira svoje okruženje, iskoristi šanse koje joj se ukažu i minimizira potencijalne opasnosti.

Sam pojam modelovanja povezan je direktno sa pojmom procesa ili sistema, pri čemu sistem predstavlja subjektivni pojam i definisan je usvojenim granicama koje obuhvataju samo one osobine realnog procesa koje su od interesa za datu primjenu. Na taj način, glavni zadatak modelovanja događaja je da osvjetli osnovne osobine realnog procesa koji se posmatra i da ih prevede na neki apstraktan jezik. Modelovanje događaja kao oblast u projektovanju informacionih sistema predstavlja integralni dio nauke i tehnike koji obuhvata sve oblasti ljudskih aktivnosti.Izbor navedenih granica istraživanja predstavlja najvažniji korak u modelovanju, pošto suviše uske, kao i suviše široke granice, mogu rezultovati praktično neprimjenjene modele sa aspekta analize realnih pojava. Metodologija modeliranja omogućava opisivanje, analizu, klasifikaciju, istraživanje, komuniciranje i simulaciju realnog sistema. Osnova modela se zasniva napostojanju određene sličnosti između dva objekta. Ako se između dva objekta posmatranja može utvrditi sličnost u bilo kom određenom smislu, onda između tih objekata postoji odnos modela i originala, odnosno jedan se može smatrati originalom, a drugi njegovim modelom.

Ponuda gotovih rješenja IS obuhvata veliki skup modula, koji odgovaraju različitim poslovnim procesima u kompanijama. Na budućim korisnicima je da izaberu rješenje koje im najviše odgovara i funkcije koje odgovaraju njihovim realnim potrebama.

[1] Božičković Z., Upravljanje informacijama u logistici- skripta, Saobraćajni fakultet, Doboj 2011.

[2] Blagojević Branko, Modeliranje strukturnih sustava broda događajima-doktorski rad, Sveučilište u Zagrebu. Fakultet strojarstva i brodogradnje, Zagreb 2005.

[3] Poliščuk E. Jarolsav, Projektovanje informacionih sistema, Elektrotehnički fakultet, Podgorica 2007.

[4] Poliščuk E. J., Novi pristup razvoju informacionih sistema, JISA INFO, časopis Jugoslovenskog informatičkog saveza , Beograd, 1996.

[5] http://web.efzg.hr/dok/inf/uis/PIS-%204.pdf [6]http://oliver.efos.hr/nastavnici/jmesaric/modeliranje/P1MODELIRANJE%20I %20IMPLEMENTACIJA%20INFORMACIJSKIH%20SUSTAVAII.pdf [7] http://ttl.masfak.ni.ac.rs/Programski%20paketi/Simulacija-Koncept%20(prevod).pdf [8] http://www2.fsr.ba/nastava/pi/predavanja.pdf [9] http://www.docstoc.com/docs/102856262/Modeliranje-i-simulacija-sistema [10] http://www.fer.unizg.hr/_download/repository/MJI_matrica_slides.pdf