UNIVERZITET U NOVOM SADU

TEHNIČKI FAKULTET “MIHAJLO PUPIN” ZRENJANIN

INFORMACIONI SISTEM ŠKOLE

Skripta za teorijski deo – radna verzija

Autori: Doc dr Ljubica Kazi

ZRENJANIN 2016. godine

ISPITNA PITANJA 1. Osnovni pojmovi – sistem, podatak, informacija 2.Definicija i struktura informacionog sistema 3. Proces razvoja informacionog sistema 4. Tehnike specifikacije znanja o organizacionom sistemu - poslovnim procesima i toku podataka 5. Modeli poslovnih procesa i elementi 6. UML modeli 7. Modeli podataka 8. Fizički model podataka, Referencijalni integritet, SQL 9. Savremene tehnologije implementacije informacionog sistema 10. Podrska odlucivanju u informacionom sistemu Dodatna pitanja – odbrana praktičnog dela

1. Elementi i postupak implementacije korisnickog interfejsa 2. Povezivanje korisnickog interfejsa sa bazom podataka 3. Implementacija osnovnih funkcija softvera (unos,prikaz)

OSNOVNI POJMOVI SISTEM – skup povezanih elemenata koji predstavljaju jasno izdvojenu celinu sa određenim ponašanjem, gde je funkcionisanje svakog elementa podređeno ostvarenju zajedničkih ciljeva. Ključne karakteristike sistema su: skup elemenata, postoje relacije između elemenata i interakcije sa okruženjem, hijerarhijska uređenost elemenata u strukturi, uređenost, organizovanost sa jasnom ulogom elemenata u doprinosu ciljevima celine, atributi kao karakteristike elemenata, strukture, funkcionisanja i sistema kao celine, karakteristike sistema kao celine (statičke i dinamičke), izdvojena celina od okruženja, funkcionisanje (pravila, funkcija, zakon), ponašanje – niz stanja, procesi, ulaz/izlaz, cilj. ORGANIZACIONI SISTEM - sistemi čije osnovne elemente čine sociološki (ljudi povezani sociološkim vezama) i tehničko-tehnološki podsistemi (sistemi čiji su sastavni delovi i veze materijalno-fizičkog karaktera). STRUKTURA SISTEMA - broj i karakter elemenata sistema, broj i karakter veza između elemenata sistema. Uloga veza u sistemima je omogućavanje prenošenja rezultata rada pojedinih elemenata sistema. FUNKCIONISANJE SISTEMA - skup aktivnosti koje izvršavaju elementi sistema u određenom vremenu, a usmerene su ka realizaciji svrhe i ciljeva sistema. Produkt funkcionisanja sistema predstavlja njegovu funkciju. Osnovne funkcionalne komponente organizacionih sistema nose informaciona, energetska i materijalna obeležja. U funkcionisanju organizacioni sistemi razmenom materije, energije i informacija ostvaruju ciljeve i svrhu postojanja putem internih strukturnih veza ili veza sa okruženjem. PROCES – Proces se sastoji od aktivnosti rada sistema u toku vremena, produkata tog rada i izvršilaca (ljudska i materijalno-tehnička komponenta) rada. U organizacionim sistemima ne postoji ni jedan proces koji ne sadrži informacionu komponentu. Postoje i procesi koji imaju gotovo isključivo informacioni karakter. Razlikujemo: • osnovne procese - ostvaruju svrhu postojanja sistema; • procese održavanja - uklanjanje smetnji i snabdevanje resursima; • razvojne procese - menjaju strukturu i funkcionisanje sistema radi obezbeđivanja prilagođavanja promenama u okruženju i uspešnijem ostvarivanju ciljeva u okviru osnovnih procesa; • upravljački procesi - postavljanje ciljeva, usmeravanje, nadgledanje, odlučivanje, vrednovanje ostvarivanja ciljeva. PODATAK - misaoni oblik i zapis o činjenici (postojanje određene stvarnosti) o nekoj pojavi, aktivnosti, događaju ili objektu - o vrsti atributa i vrednosti atributa koji opisuje te činjenice. INFORMACIJA – nastaje obradom podataka i prezentovanjem u formi pogodnoj za dodeljivanje značenja i vrednosti (značaja), čime predstavlja osnov za donošenje odluka ili izvršenje aktivnosti na ostvarenju donetih odluka.

DEFINICIJA I STRUKTURA INFORMACIONOG SISTEMA Informacioni sistem se razvija za realni sistem, te je struktura realnog sistema osnova za modeliranje strukture IS. Pod realnim sistemom se podrazumeva stvarni dinamički sistem koji postoji u objektivnoj realnosti, odnosno to je i organizacioni sistem. Informacioni sistem se smatra jednom od infrastruktura organizacionog sistema. Informacioni sistem organizacije uvek postoji, makar i u neautomatizovanoj formi. Svrha informacionog sistema je prikupljanje, skladištenje, obrada, prenošenje, prezentovanje podataka u cilju dobijanja kvalitetnih informacija koje predstavljaju osnov funkcionisanja, odlučivanja i razvoja u organizaciji. Struktura informacionog sistema (odnosno arhitektura IS), njegovi delovi i međusobne veze, kao i odnos prema realnom sistemu [LAZAREVIĆ i sar., 1988], bez obzira na to kojim softverom je izgrađen, prikazana je na sledećoj šemi:

Slika 1. Struktura informacionog sistema

U realan sistem ulaze materija, energija i podaci, kao i podaci o ulaznoj materiji i energiji. Stanje sistema opisuje prošlost i sadašnjost sistema, koje pod uticajem ulaza i procesa transformacije dovodi do promene stanja sistema i generisanja izlaza. U informacionom sistemu ulaz predstavljaju podaci, kao i podaci o ulazima u realan sistem (podaci o materiji, energiji..), kao njihova "slika". Ovi podaci se pomoću programa za ažuriranje unose u bazu podataka koja u svakom trenutku sadrži opis stanja realnog sistema. Prikaz stanja realog sistema izraženo podacima u bazi podataka vrši se pomoću programa za izveštavanje. Strukturu informacionog sistema čine 4 komponente:

1. Hardver (Hardware) – računarska oprema, mrežna oprema, telekomunikaciona oprema 2. Softver (Software) – operativni sistem, uslužni programi (antivirus, bekap itd), aplikativni softver(program i

baza podataka) 3. Orgver (Orgware) – organizacija rada informacionog sistema – korišćenja, održavanja i razvoja izražena

kroz pravilnike, statute, zakone... 4. Lajfver (Lifeware) – kadrovi koji koriste informacioni sistem i kadrovi koji rade na održavanju i razvoju

sistema, sa svojim osobinama: znanje, sposobnosti, očekivanja, interesi i slično.

PROCES RAZVOJA INFORMACIONOG SISTEMA S obzirom na složenost informacionog sistema, uvođenje novih rešenja ili unapređenje postojećeg sistema zahteva:

1. Razvoj kroz faze i aktivnosti – najvažnije aktivnosti: početna analiza problema i specifikacija zahteva, planiranje projekta, modelovanje, implementacija, testiranje, instalacija, obuka

2. Razvoj kroz module (delove) – postepena realizacija delova sistema prema prioritetima 3. Obuhvat celokupnog posla u okviru projekta, tj. Definisanje i rukovođenje projektom razvoja (gde je

posebno značajno definisati ciljeve, obuhvat posla, aktivnosti, resurse, rokove izrade, rizike i slično) Ceo proces prati odgovarajuća dokumentacija. Prema tradicionalnoj metodologiji, u toku razvoja se formulišu:

1. Idejni projekat – skica rešenja (komponente, moduli, razmeštaj), studija izvodljivosti i opravdanosti, procena troškova i slično.

2. Glavni projekat – detaljna sistemska analiza, modeli i opis načina implementacije 3. Izvođački projekat – detalji implementacije u konkretnoj tehnologiji

Postoje različiti pristupi razvoju informacionih sistema, odnosno definisanju faza životnog ciklusa razvoja.

I GRUPA PRISTUPA RAZVOJU IS

1. LINEARAN

Slika 2. Linearni pristup razvoju informacionog sistema Karakteristike:

- Sukcesivan sled faza u razvoju IS - Nema povratka na prethodne faze - Vrednovanje se dešava na kraju razvoja - Korisnik na početku ne zna mogućnosti novog IS

Linearnim (konvencionalnim) modelom životnog ciklusa se razvoj informacionog sistema deli na faze: 1. planiranje razvoja (najčešće korišćena BSP - Business System Planning metoda kompanije IBM) 2. analiza zahteva 3. specifikacija informacionog sistema 4. projektovanje baze podataka 5. projektovanje programa 6. implementacija (kodiranje, testiranje) 7. uvodenje sistema u rad 8. održavanje sistema

i na kraju prestanak upotrebe. Ova metodologija razvoja informacionog sistema je došla u krizu zbog haosa koji se stvara prilikom dvostrukog održavanja sistema (paralelno održavanje sistema i dokumentacije), kao i zbog predugog ciklusa razvoja informacionih sistema. Njen najveći nedostatak je što je korisnik upoznat sa informacionim sistemom tek na kraju njegove realizacije (fizičke implementacije), te su moguća velika odstupanja kreiranog informacionog sistema u odnosu na realni sistem i očekivanja njihovih korisnika. 2. PROTOTIPSKI

Karakteristike: - U ranoj fazi razvoja IS-a teži se razvoju prototipa (početne

verzija koja se menja u skladu sa korisnikovim zahtevima) - Postoji mogućnost povratka na prethodne faze u razvoju IS-a Problemi: - Uvođenje dokumantacije - Integracija delova u jedinstven IS.

Faze kod protipskog razvoja IS:

1. Planiranje razvoja

2. Analiza i specifikacija zahteva 3. Izrada prototipa 4. Implementacija 5. Održavanje

Prototipski pristup razvoju IS predstavlja unapređenje u odnosu na konvencionalni pristup. Osnova ove meto-dologije je da se napravi što je moguće brže prototip softvera, da bi se na osnovu njega utvrdile potrebe korisnika. U odnosu na to da li se prototip dalje razvija i dopunjuje ili ne postoje odbacivi i nadgradivi prototipi. Odbacivi prototip služi samo za utvrđivanje potreba korisnika, odnosno za specificiranje zahteva. Kada se ove potrebe utvrde, prototip se odbacuje, a na osnovu njega se ponovo izrađuje ceo novi sistem. Ovakvi prototipi se obično rade koristeći jednostavne, ali ne i efikasne generatore aplikacija ili jezike četvrte generacije kojima je lako opisati sistem i brzo napraviti prototip koji približno radi ono što je zahtevano. Na osnovu odbacivog prototipa se vrši projektovanje novog sistema koristeći konkretne alate, klasične programske jezike ili neki od sistema za upravljanje bazom podataka. Za razliku od odbacivog prototipa nadgradivi prototipi se usavršavaju i koriguju i u nekoliko iteracija dovodeći do konačnog rešenja. Nedostatak prototipa predstavlja dokumentacija, jer se često dokumentacija ne piše ili je nepotpuna prilikom razvoja prototipa. Takode, prototip celog sistema se ne može napraviti, pa se zbog toga pravi više manjih prototipa (prototipi podsistema), koji mogu dovesti do haosa. Rešenje se nalazi u prvobitnom projektovanju zajedničke baze podataka za sve prototipe koja obezbeđuje koordinirani razvoj sistema. Ovakav način izrade prototipa je poznat kao Data Driven (vođen podacima) prototip. Takođe, korisnici se aktivno uključuju u sam proces izrade prototipa, pa su i manja odstupanja od zahteva korisnika i potreba realnog sistema. Od korisnika se, u ovom slučaju, zahteva poznavanje metodologije projektovanja IS i osnova informaciono-komunikacionih tehnologija. 3. TRANSFORMACIONI Karakteristike:

- Objedinjuje dobre osobine linearnog i prototipskog pristupa u razvoju IS-a. - Zasniva se na postojanju alata za brzi razvoj IS-a. - Specifikacija zahteva je na jeziku koji je blizak korisniku, a sam alat generiše programski kod.

Slika 1.4. Transformacioni pristup razvoju informacionog sistema Faze su sledeće:

1. Analiza zahteva 2. Formalna specifikacija 3. Validacija specifikacije 4. Održavanje 5. Automatska optimizacija

Metoda koja predstavlja unapređenje prototipskog pristupa razvoju je operacioni ili transformacioni razvoj informacionog sistema. Suština ovog načina razvoja je u korišćenju alata koji na osnovu specifikacije problema automatski generišu softversko rešenje, tj. program u određenom programskom jeziku. Takvi alati se nazivaju CASE alati (Computer Aided Software Engineering). Ceo proces se svodi na formulisanje analize zahteva u obliku u kojem se izrađuje formalna, izvršiva specifikacija, a na osnovu toga prototip programa. Validacija i održavanje modela se vrše nad formalnom specifikacijom, a radi dobijanja izvršnog koda programa, ponovno se pokreće proces automatske transformacije.

1 2 5

3

4

II GRUPA PRISTUPA RAZVOJU IS-a Pristupi TOP – DOWN (od vrha ka dnu) i BOTTOM-UP (od dna ka vrhu) sastoje se u odluci odakle započeti razvoj informacionog sistema. Kao pravilan pristup koristi se top-down kod analize i projektovanja informacionog sistema (svrha postojanja sistema, cilj, definisanje celine i podsistema itd.), a bottom-up da se koristi kod implementacije i uvođenja IS deo po deo.

III GRUPA PRISTUPA RAZVOJU IS-a Zasniva se na sledeće dve podele:

1. STRUKTURNO - projektovanje, dizajn i programiranje. Definišu se procesi i funkcije koje vrši sistem. 2. OBJEKTNO – atributi (osobine) i metode (procedure i funkcije). Pri razvoju IS-a treba definisati

objekte u sistemu (elemente, veze između elemenata i sl.) i procedure i funkcije koje se dešavaju nad tim objektima, koje su veze između objekata. Realizacija funkcija i procedura se ostvaruje preko poziva odgovarajućih metoda.

IV GRUPA PRISTUPA RAZVOJU IS-a

1. SISTEMSKI (totalni) – svi podsistemi se istovremeno razvijaju i implementiraju. Zahteva izuzetno mnogo vremena i novca.

2. PARCIJALNI (ad hoc) – ne vodi računa o sistemskom pristupu jer se razvija i implementira samo jedna služba, sektor ili organizaciona jedinica. Komunikacija sa ostalim delovima IS-a i integracija sa globalnom bazom podataka se ostvaruje kad se ukaže potreba.

3. MODULARNI – udružuje oba ova pristupa. Definišu se MODEL PODATAKA i MODEL PROCESA na nivou cele organizacije.

Slika 1.5. Modularni pristup razvoju informacionog sistema SAVREMENI PRISTUPI S obzirom da je osnovni element razvoja informacionog sistema softver, savremeni pristup razvoju informacionog sistema zasniva se na principima:

• Iterativno (razvoj u više ciklusa – iteracija) i inkrementalno (postepeno dodavanje novih funkcija) • Agilno – metodologija (skup srodnih agilnih metodologija), koja daje prednost realizaciji rešenja, a

minimizuju dokumentovanje i modelovanje (http://agilemanifesto.org/). Principi agilnog manifesta: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the

customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to

the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust

them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is

face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to

maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams.

1

4 3

2

BP

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Aktuelan je pristup disciplinovanog agilnog razvoja. Uključuje planiranje i modelovanje u početnoj fazi (www.agilemodeling.com) kojoj sledi niz iteracija gde se početni prototip aplikacije proširuje novim mogućnostima uz konstantnu saradnju sa korisnikom. Principi disciplinovanog agilnog pristupa (https://www.disciplinedagileconsortium.org/):

1. Individuals and interactions over processes and tools 2. Working solutions over comprehensive documentation 3. Stakeholder collaboration over contract negotiation 4. Responding to change over following a plan

Osnovni životni ciklus disciplinovanog agilnog razvoja softvera predstavljen je na sledećoj slici (http://i2.wp.com/www.disciplinedagiledelivery.com/wp-content/uploads/2014/05/disciplined-agile-lifecycle-basic1.jpg):

TEHNIKE SPECIFIKACIJE ZNANJA O ORGANIZACIONOM SISTEMU - POSLOVNIM PROCESIMA I TOKU PODATAKA

U okviru upoznavanja sa organizacionim sistemom, važno je prikupiti podatke i predstaviti ih na odgovarajući način. Specifikacija znanja se sastoji iz prikupljanja i prezentovanja. Tehnike prikupljanja podataka o načinu funkcionisanja organizacionog sistema:

• Intervju – sa zaposlenima koji će da koriste sistem, sa menadžmentom • Anketa – pripremljena pitanja, zaposleni popunjavaju • Prikupljanje dokumentacije – obrasci (popunjeni i prazni), pravilnici, zakoni • Posmatranje rada organizacije – prisustvo poslovnim procesima i beleženje zapažanja

Tehnike predstavljanja znanja – različite vrste modela poslovnih procesa

MODELI POSLOVNIH PROCESA I ELEMENTI

Različite vrste modela se mogu koristiti za prikaz poslovnih procesa. U okviru predstavljanja poslovnih procesa važno je predstaviti i protok podataka (paketi podataka, dokumenti) kroz sistem koji se koriste ili nastaju u okviru realizacije poslovnih procesa, a takođe je važno predstaviti i koje podatke treba čuvati u sistemu. Postoje različite vrste modela, ali se svode na 2 osnovna pristupa:

• Algoritamski pristup – sve aktivnosti se predstavljaju na jednom dijagramu o Activity dijagram UML-a, elementi: aktivnosti, tok aktivnosti, uslovna grananja o Business process model tipa Analysis, elementi: organizacione jedinice, aktivnosti, tok aktivnosti,

tok podataka, skladište podataka, uslovna grananja, sinhronizacija • Uređivanje procesa hijerarhijskom dekompozicijom – stablo procesa predstavlja osnov crtanja većeg

broja dijagrama gde se postepeno uvode detalji o Dijagram toka podataka (data flow dijagram), elementi: sistem iz okruženja (eksterni entitet),

proces, tok podataka, skladište podataka, konektor • Predstavljanje aktivnosti u odnosu na radna mesta i profile korisnika buduceg sistema

o USE CASE dijagram – nije prvenstveno namenjen predstavljanju poslovnih procesa, već radnih aktivnosti koje će biti podržane novim sistemom. Ta integracija poslovnog procesa i budućeg rešenja predstavlja se USE CASE dijagramom prema prvobitno osmišljenoj nameni ovog tipa dijagrama

PRIMER DIJAGRAMA AKTIVNOSTI:

[sluzbeni put][mesecni putni troskovi]

[gotovinski racuni]

Formiranje naloga za sluzbeni put

Uzimanje dnevnica na osnovu naloga za sluzbeni put

Uzimanje bonova za gorivo za sluzbeni put

Da li su dnevnice predvidjene za sluzbeni put

Preuzimanje adrese stanovanja o zaposlenom radi putnih troskova

Izbor aktivnosti

Podnosenje gotovinskog racuna

Razmatranje osnova za isplatu

Postoji osnov za isplatu

Isplata povodom gotovinskog racuna

Dijagram aktivnostiSLED POSLOVNIH DOGADJAJA

Formiranje naloga za isplatu putnih troskova

Razmatranje naloga za putne troskove

Razmotreni nalozi

Isplata mesecnih putnih troskova

Da li se koristi putnicko vozilo

Koja vrsta troskova

PRIMER BUSINESS PROCESS MODELA TIPA ANALYSIS:

DIREKTORRACUNOVODSTVOKADROVSKA SLUZBA

[da]

[ne]

Evidencija zaposlenih

Odsustva zaposlenih

Evidencija zaposljavanja

Evidencija odsustva

Obrada prestanka radnog odnosa

PravilniciDonosenje pravilnika

Odluka o sluzbenom putuPutni nalozi

Prijem podataka o zaposlenima i radu u narednom mesecu

Prijem dokumentacije o gotovinskom računu

Prijem putnog naloga

Evidentiranje podataka o načinu prevoza

Isplata dnevnica za put

Izdavanje bonova za gorivo

Zaprimanje bonova za gorivoOdobravanje isplate dnevnica

Formiranje naloga za isplatu dnevnica

Nalog za isplatu dnevnica

Formiranje naloga za isplatu povodom gotovinskog računa

Nalog za isplatu povodom gotovinskog računa

Odobravanje isplate za gotovinski račun

Isplata troškova povodom gotovinskog računa

Da li je bilo gotovinskih računa na putu

Formiranje naloga za isplatu mesečnih troškova putovanja

Nalog za isplatu mesečnih putnih troškova

Odobravanje naloga za isplatu mesečnih putnih troškovaIsplata mesečnih putnih troškova

BIZNIS PROCES MODEL za tok poslovnog procesaFREE MODEL simple flowchart je identican activity dijagramu, samo ima i resurse (skladista podataka). Dakle, kada bismo odeljak RACUNOVODSTVO

IZDVOJILI U POSEBAN DIJAGRAM, DOBILI BISMO NESTO STO IZGLEDA KAO SIMPLE FLOWCHART.

Podaci od zaposlenog

Komunikacija sa NIS-om

Komunikacija sa bankomKomunikacija sa bankom

Komunikacija sa bankom

Pregled troškova na periodičnom nivou

Planiranje budžeta za troškovePlan budžeta za kalendarsku godinu

PRIMER DATA FLOW DIJAGRAMA: STABLO:

DIJAGRAM KONTEKSTA ILI 0. NIVO DEKOMPOZICIJE

Odluka o nacinu prevoza

Nalog za sluzbeni put

Pravilnici

Podaci o izdavanju novca za bonove

Podaci o potrebnom novcu za izdavanje bonova

Podaci o potvrdi prijema bonova

Odobrenje isplate mesecnih putnih troskova

Odobrenje isplate dnevnica

Zahtev za isplatu mesecnih putnih troskova

Spisak zaposlenih za obracun mesecnih transportnih troskova

Zahtev za odobrenjem isplate dnevnica

Odobrenje isplate povodom gotovinskog racuna

Zahtev za odobrenjem isplate povodom gotovinskog racuna

Izvestaj o utrosku novca za gotovinski racun

Podaci o potvrdi prijema novca

Obavestenje o mogucnosti isplate troskova

Podaci o isplati novcaNalog za podizanje novca

Gotovinski i fiskalni racun

Podaci o izdavanju bonova

Izdatnica bonova

Zahtev za izdavanjem bonova

0

Obrada troškova

+

ZaposleniBanka

Kadrovska služba

Direktor

NIS

Trenutno ove podatke u obliku dokumenata i novac raznosi KURIR,a inace u elektronskom bankarstvu nalog za isplatu zaposlenima na racunDakle, kurir NIJE INTERFEJS, vec samo posrednik, koji postoji u postojecem organizacionom smislu.

Zaposleni dobija novac i bonove, ali se oni smatraju materijom, a ne tokom podataka.

Pravna sluzba

Formalno dobijaju od njih, ali sustinski uprava i direktor,drzavni organi, ministarstva, vlada itd.su izvori podataka u pravilniku

DIJAGRAM 1. NIVOA DEKOMPOZICIJE

Nalog za sluzbeni put

Odluka o nacinu prevoza

Podaci o pravilnicima Podaci o potvrdi prijema bonova

Izvestaj o utrosku novca za gotovinski racun

Podaci o potvrdi prijema novca

Odobrenje isplate mesecnih putnih troskova

Odobrenje isplate dnevnicaZahtev za isplatu mesecnih putnih troskova

Pravilnici

ZahtevZahtev

Odluka

Odluka

Zahtev za odobrenjem isplate povodom gotovinskog racuna

Odobrenje isplate povodom gotovinskog racunaZahtev za odobrenjem isplate dnevnica

Podaci o izdavanju novca za bonove

Podaci o potrebnom novcu za izdavanje bonova

Spisak zaposlenih za obracun mesecnih transportnih troskova

Obavestenje o mogucnosti isplate troskova

Podaci o podignutom novcu

Podaci o isplati novca

Podaci za isplatu novca

Podaci za isplatu novca

Podaci o isplati novcaNalog za podizanje novca

Gotovinski i fiskalni racun

Podaci o izdavanju bonova

Pravilnici u vezi troskova

Podaci za zahtevanje bonova

Podaci o prijemu bonova

Podaci o prijemu bonova

Podaci za zahtevanje bonova

Izdatnica bonova

Zahtev za izdavanjem bonova

Novi pravilnici

NIS

NIS

Zaposleni

Zaposleni

Banka Banka

Zaposleni

DirektorDirektor

Kadrovska služba

Direktor

1

Upravljacka delatnost

+ 2

Osnovna delatnost

+

3

Pomocna delatnost

+

Pravilnici

Bonovi

Isplata novca

Zahtevi i odluke

Pravna sluzba

Direktor

Zaposleni

PRIMER USE CASE DIJAGRAMA U FUNKCIJI PREDSTAVLJANJA POSLOVNIH PROCESA PODRZANIH RESENJEM:

popunjava

<<include>>upload

cita

salje

cita

Association_8

Association_9

Association_11

Association_12

<<extend>>c

Association_13<<extend>>

s

<<extend>>a

Dependency_5

Dependency_6

Dependency_7

Association_10

Association_14

Dependency_8

Dependency_9

Dependency_10

Dependency_12

<<extend>>a

<<extend>>v

<<extend>>s

Association_15

Association_16

Dependency_15

Dependency_16

Association_17

Association_18

Dependency_17

Dependency_18

radnik

Zahtev za isplatom troskova

Dijagram slucajeva koriscenja ZA POSLOVNI

DOMEN

isplata

blagajnik : 1

Kadrovska sluzba

Direktor : 1

Podnosenje dokumentacije za isplatu

Extend (Is a), Include (Sastavni deo), Use (Odnos ravnopravnih samostalnih)

Evidentiranje odluke o sluzbenom putu Obavestenja o sluzbenom putu

Evidentiranje pravilnika o putovanjima

Prikazivanje podataka o radnicima

Formiranje naloga za isplatu mesecnih troskova putovanja

Isplata mesecnih troskova putovanja

Odobravanje mesecnih troskova putovanja

Uvid u stanje, uplate i isplate sa racuna u banci

Evidentiranje podataka o radniku

blagajnik : 2Isplata dnevnica

Isplata za gotovinski racun

Direktor : 2

Odobravanje isplate dnevnica

Izdavanje bonova nije pokriveno

softverom

Zahtev za isplatu povodom gotovinskog racuna

Zahtev za isplatom dnevnica Zahtev za isplatom mesecnih troskova putovanja

Nece biti implementirano zato sto to krajnji korisnik ne radi, poslovna pravila to nalazu.

Odobravanje gotovinskog racuna

Izdavanje bonova za gorivo

UML MODELI

UML (Unified Modeling Language) predstavlja danas standardni jezik modelovanja objektno-orjentisanog softvera. Istorijat:

• U okviru firme Rational Software, Grady Booch, Ivar Jacobson i James Rumbaugh su u periodu 1994–1996 radili na standardizaciji I objedinjavanju različitih notacionih sistema I pristupa objektno-orjentisanom dizajnu softvera

• 1997. Rezultate iz firme Rational Software prihvata i prilagođava kao standard OMG (Object Management Group). Ta godina se smatra ostvarivanjem UML 1.0 verzije.

• 2005. Organizacija ISO (International Standard Organization) prihvata UML kao standard. Iste godine, verzija 1.5 UML je zamenjena sa UML 2.0 verzijom.

• Poslednja verzija UML je verzija 2.5 iz 2015. Godine.

Modeli:

• UML 1.0 uključuje modele: Class diagram, Object Diagram, , Statechart Diagram, Component diagram, Deployment Diagram, USE case diagram, Sequence diagram, Communication diagram, Activity Diagram

• UML 2.0 na prethodni spisak dodaje i modele: Package Diagram, Interaction Overview Diagram, Composite Structure Diagram.

Namena:

• USE case diagram – funkcionalne mogucnosti sistema i profili korisnika koji ih mogu koristiti • Class diagram – klase u implementaciji softvera • Object Diagram – objekti klasa (prethodno prikazanih dijagramom klasa) sa konkretnim vrednostima

atributa, radi ilustracije šta znače pojedini atributi • Statechart Diagram – jedan dijagram predstavlja sva moguća stanja jedne klase navođenjem naziva stanja

i načina kako prelaze iz jednog stanja u drugo • Component diagram – komponente softverskog rešenja – moduli, fajlovi • Deployment Diagram – razmeštaj softverskih komponenti u računarskoj mreži prema čvorovima • Sequence diagram – način realizacije jednog slučaja korišćenja : hronološki sled komunikacije korisnika i

softvera kao i prikaz međusobnih poziva metoda objekata (poruke) koji učestvuju u implementaciji jednog slučaja korišćenja, za svaki slučaj korišćenja se može predstaviti jedan ili čak više dijagrama sekvenci (osnovni i alternativni scenariji)

• Communication diagram – sličan kao dijagram sekvenci, samo ne predstavlja grafički vertikalno hronologiju međusobnog poziva metoda klasa, naglasak je na prikazu koje klase komuniciraju I putem poziva kojih metoda.

• Activity Diagram – algoritam realizacije jedne metode neke klase (može se koristiti I u okviru modelovanja poslovnih procesa)

Elementi:

• USE case diagram – slučajevi korišćenja (use case), profili korisnika (actor), veze zavisnosti između slučajeva korišćenja, veze profila korisnika i slučajeva korišćenja

• Class diagram – klase, veze između klasa • Object Diagram – objekti klasa, veze između klasa • Statechart Diagram – stanja, tranzicije stanja • Component diagram – komponente softverskog rešenja – moduli, fajlovi, veze između elemenata • Deployment Diagram – čvorovi, softverske komponente • Sequence diagram – actor, objekti, poruke (pozivi metoda), aktivacija (vreme trajanja objekta u memoriji) • Communication diagram – objekti, poruke, redni broj pokretanja poruke • Activity Diagram – aktivnost, tok aktivnosti, uslovno grananje, simbol pocetak, simbol kraj.

PRIMERI:

Dijagram klasa – opsti model

DIJAGRAM SEKVENCI

0..1

0..*

0..1

0..*

0..1

0..*

<<import>>

Class_1

Interface_1

File_1

Class_2{abstract}

Class_3

Class_4

Class_5

Class_6

Class_7

Realization Generalization Assotiation

Aggregation

Composition

DependencyExtended dependency

3: New

4: Bool:= PostojiKorisnik( )

1: New

5[Bool=false]: Ne postoji korisnik

6: ds:= DajSve 7: OtvoriKonekciju

10: ZatvoriKonekciju

8: DajDataset

9: ZatvoriAdapterDataset

11[Bool = false]: Ne postoji korisnik

2: btnPrijava_Click( )

fPrijava3:frmPrijavlj ivanjeKorisnika

objPrijavljeniKorisnik3:clsKorisnik

Sequence dijagram za slucaj koriscenja PRIJAVA

2. scenario - NE POSTOJI KORISNIK

Korisnik2

X2:clsTabela Y2:clsKonekcija

DIJAGRAM STANJA

DIJAGRAM SLUCAJEVA KORISCENJA

DIJAGAM KOMPONENTI

Dijagram razmestaja

[Exception]

[Success]

[Timeout]

State_1

State_2

State_3

<<extend>>

<<extend>>Korisnik

Prijava

Ucitavanje glavnog menija aplikacije

Izlaz

MODELI PODATAKA

Osnovni tipovi modela podataka koji su obuhvaceni gradivom na univerzitetima i koji su u upotrebi su:

• Konceptualni model – predstavlja entitete realnog sveta, opisuje ih detaljnije atributima (osobinama) i vezama kojima su povezani međusobno . Posebna vrsta: ER (Entity-Relationship-Attribute) dijagram.

• Relacioni model – predstavlja tabele u bazi podataka i njihovu povezanost. Svaka tabela je opisana primarnim ključem i poljima.

• Kada atributima relacionog modela dodelimo konkretne nazive tipova podataka koji odgovaraju nekom sistemu za upravljanje bazama podataka (DBMS – Database Management System), dobijamo fizički model.

• Objektni model izražava se kroz dijagram klasa. Prevođenje jednog u drugi tip modela podataka se realizuje poštujući određena pravila. Ova konverzija je automatizovana u okviru CASE (Computer Aided Software Engineering) alata. PRIMERI: KONCEPTUALNI MODEL

FIZIČKI MODEL ZA Microsoft SQL Server 2008

FIZIČKI MODEL PODATAKA U OKVIRU DBMS SISTEMA

OBJEKTNI MODEL sa dodatim GET-SET metodama

FIZIČKI MODEL PODATAKA, REFERENCIJALNI INTEGRITET, SQL

Relacioni model se zasniva na povezanosti tabela putem parova – primarni ključ i strani ključ. Primarni ključ je polje koje ne sme u jednoj tabeli imati više puta istu vrednost i na osnovu koje se jedinstveno identifikuje jedan zapis. Vrednost istog tipa I istog ili sličnog naziva treba da postoji u drugoj tabeli, tu je ova vrednost strani ključ. Na slici koja sledi vidimo odnos 1: M (jedan prema vise) gde za jednu sednicu moze biti vise materijala sa sednice.

SQL – Strukturirani jezik upita To je jezik kojim se obraćamo sistemu za upravljanje bazom podataka naredbama koje mogu biti tipa: DDL – data definition language – kreiranje baze podataka, kreiranje tabela, izmena strukture DML – data manipulation language – rad sa podacima: unos, brisanje, izmena, izdvajanje (select) PRIMERI: DDL CREATE DATABASE `TURISTICKAAGENCIJA` CHARACTER SET utf8 COLLATE utf8_general_ci; create table `TURISTICKAAGENCIJA`.`KORISNIK` ( IDKORISNIKA int NOT NULL AUTO_INCREMENT PRIMARY KEY, PREZIME varchar(50) not null, IME varchar(40) not null, EMAIL varchar(60) not null, KORISNICKOIME varchar(30) not null, SIFRA varchar(30) not null, URLSLike varchar(250) null, statusucesca varchar(30) not null ); DML INSERT INTO `TURISTICKAAGENCIJA`.`KORISNIK` (PREZIME, IME, EMAIL, KORISNICKOIME, SIFRA, URLSLIKE, STATUSUCESCA) VALUES ('Kazi', 'Ljubica', 'ljubicakazi@hotmail.com', 'lkazi', 'lk', 'Ljubica.jpg', 'admin'); SELECT * FROM KORISNIK;

Referencijalni integritet Osobina relacije između dve tabele. Kojom se obezbedjuje uskladjenost podataka u svakom trenutku u bazi podataka. Do narusavanja referencijalnog integriteta moze doci ukoliko bi se izmenila vrednost primarnog kljuca ili ako bi se obrisao zapis na strani 1 (u tabeli gde je primarni kljuc). Ugradjivanje tehnika ocuvanja referencijalnog integriteta se vrsi prilikom uspostavljanja relacije izmedju 2 tabele u okviru foreign key constraint podesavanja. ON DELETE – RESTRICT – znaci da ne moze da se obrise zapis na strani 1 ako postoji bar jedan na strani M ON UPDATE – CASCADE – kaskadno automatski izmena vrednosti stranog kljuca u svim vezanim podacima nakon izmene vrednosti primarnog kljuca u tabeli na strani 1. alter table `TURISTICKAAGENCIJA`.`MESTO` add constraint FK_PRIPADA foreign key (OZNAKAZEMLJE ) references `TURISTICKAAGENCIJA`.`ZEMLJA` (OZNAKA) on delete restrict on update cascade;

SAVREMENE TEHNOLOGIJE IMPLEMENTACIJE INFORMACIONOG SISTEMA

Windows aplikacije – PRIMER

Web aplikacije – PRIMER

Mobilne aplikacije

PODRSKA ODLUCIVANJU U INFORMACIONOM SISTEMU

Klasifikacija informacionih sistema prema stepenu automatizacije:

• neautomatizovani informacioni sistemi; • sistemi automatske obrade podataka; • upravljački informacioni sistemi; • izvršni informacioni sistemi; • sistemi za podršku odlučivanju; • ekspertni sistemi.

Ekspertni sistemi – softveri koji imaju ugradjena znanja I pravila eksperata iz odredjene oblasti, daju mogucnost postavljanja pitanja. Data warehouse – objedinjavanje podataka I analiza putem visedimenzionalne statistike kreiranjem OLAP kocki OLTP – Online transaction processing – transakcije nad podacima (svakodnevni unos podataka u bazu podataka koji prati dogadjaje realnog Sistema) OLAP – Online analytical processing – analiza podataka koji su prikupljeni u odredjenom periodu Data mining – izdvajanje pravila na osnovu analize veceg obima podataka

DODATNA PITANJA – ODBRANA PRAKTIČNOG DELA

ELEMENTI I POSTUPAK IMPLEMENTACIJE KORISNICKOG INTERFEJSA PHP aplikacije: Osnova grafičkog dela aplikacije je HTML – tabela koja sadrži druge elemente. Interaktivni deo (unos, unos kriterijuma za filter) se predstavlja putem HTML objekta tipa form, koji sadrzi druge elemente: input objekat tipa text – tekst box input objekat tipa date – datumska kontrola (kalendar) input objekat tipa file – dugme koje pokrece dijalog prozor za upload fajlova input objekat tipa submit – dugme Tabelarni prikaz - korišćenje standardne HTML tabele – TR, TD elementi Stilovi - CSS POVEZIVANJE KORISNICKOG INTERFEJSA SA BAZOM PODATAKA PHP aplikacije: KONEKTOVANJE NA BAZU PODATAKA: // Konektovanje na MYSQL system DBMS mysql_connect($host, $korisnik, $sifra); // Ostvarivanje konekcije ka bazi podataka mysql_select_db(nazivbaze, konekcijaMYSQL); UCITAVANJE: $RESULT = mysql_query($SQL); CITANJE VREDNOSTI POLJA: $BROJINDEKSA=mysql_result($result,$row,"BROJINDEKSA"); IMPLEMENTACIJA OSNOVNIH FUNKCIJA SOFTVERA (UNOS,PRIKAZ) PHP aplikacije: UNOS <form ACTION="korisniksnimi.php" METHOD="POST" enctype="multipart/form-data"> // preuzimanje vrednosti sa forme $Ime=$_POST['Ime']; $Prezime=$_POST['Prezime']; $SQL = "INSERT INTO `".$this->bazapodataka."`.`STUDENT` (IME, PREZIME, BROJINDEKSA, DATUMRODJENJA, POLMUSKO, BIOGRAFIJA, URLSLIKE ) VALUES ('$Ime', '$Prezime', '$BrojIndeksa', $DatumRodjenja, $Pol, '$Biografija', '$NazivSlike')"; $retval = mysql_query( $SQL, $this->Konekcija->konekcijaMYSQL); TABELARNI PRIKAZ: $BROJINDEKSA – PROMENLJIVA KOJA JE PRETHODNO DOBILA VREDNOST echo "<td style=\"width:10%; padding:0\"><font face=\"Trebuchet MS\" color:#3F4534 size=\"2px\">$BROJINDEKSA</font></td>";