Beruflich Dokumente
Kultur Dokumente
jaroslav
PREDGOVOR
"Klasina predstava o svemiru, koji se sastoji od materije i energije, mora da ustupi mjesto predstavi o svijetu sastavljenom od tri komponente: energije, materije i informacija, jer bez informacija organizovani sistemi nisu mogui. Jedino mogue materijalistiko tumaenje odravanja organizovanosti je neprekidno izvlaenje iz spoljnjeg svijeta (okoline) i iz samog sistema mase informacija o pojavama i procesima koji se tu odvijaju" [A. Lerner, 2003]. Predvianje sa kraja 2005. godine, koje je objavila kompanija "Gartner" - USA, vodea u svijetu u analizi kretanja u oblasti globalne industrije informatike tehnologije, glasi: Trend automatizacije informatikih tehnologija e imati veliki uticaj na razvoj softvera, posebno softvera za nadzor sistema, testiranje aplikacija, tehniku podrku i umreavanje. Neka informatika zaduenja e biti vea, neka e biti umanjena, neka prebaena u druge dijelove kompanije, a neka e biti ukinuta". Specijalizovani informatiki radnici, koji se istiu samo svojim poznavanjem informatikih tehnologija i vjetinama vezanim za raunare, bez posjedovanja drugih funkcionalnih znanja, bie manje potrebni, predviaju Gartner-ovi analitiari. Prosjeno informatiko odijeljenje u srednjim i velikim kompanijama e do 2010. godine biti za trideset procenata manje, tvrde analitiari trita kompanije Gartner, i zakljuuju: Informatiki radnici budunosti e biti zaposleni u jednom od etiri glavna podruja: tehnolokoj infrastrukturi, projektovanju i upravljanju informatikim sistemima, projektovanju i upravljanju procesima ili upravljanju odnosima. Osim autorovog iskustva u projektovanju IS, knjiga je, uglavnom, raena na osnovu dostupne literature i obrauje savremeni pristup projektovanju IS. Izvori, na osnovu kojih je nastala ova knjiga, jednim dijelom su navedeni u samom tekstu knjige, dok je cjelovit pregled dan u okviru pregleda koritene literature. Zahvaljujem se autorima iji su manji dijelovi radova, u djelimino izmijenjenom obliku, uli u sastav ove knjige. Ukoliko njihovo autorstvo nije na svakom mjestu jasno naglaeno, taj propust e rado biti naknadno otklonjen. U pojedinim sluajevima bilo je nemogue razgraniiti autorstvo pojedinih tekstova, jer se isti ili slian tekst mogao nai u razliitim izvorima. Knjiga je, prvenstveno, namjenjena studentima postdiplomskog specijalistikog studija Elektrotehnikog fakulteta u Podgorici i moe posluiti kao potrebna literatura.
Knjiga moe korisno posluiti projektantima IS, kao i svima koji se bave razvojem savremenih IS ili ele da se detaljnije upoznaju sa ovom oblasti.
Autor
SADRAJ
1. Opte o informacionim sistemima ........................................................... 1.1. Uvod ...................................................................................................... 1.2. Pojam informacionog sistema................................................................ 1.3. Elementi i osobine sistema i informacionih sistema .............................. 1.4. Vrste informacionih sistema .................................................................. 1.5. ivotni ciklus razvoja sistema ................................................................ 1.6. Kompleksnost razvoja informacionog sistema ...................................... 2. Planiranje razvoja informacionog sistema .............................................. 2.1. Modaliteti razvoja informacionog sistema ............................................. 2.2. Analiza izvodljivosti, trokova i koristi projekta ...................................... 2.3. Strategija i planiranje razvoja informacionog sistema ............................ 2.4. Modeli razvoja informacionih sistema .................................................... 2.5. Metodologija razvoja informacionih sistema .......................................... 2.6. Savremeni postupci razvoja informacionog sistema .............................. 3. Uvod u projektovanje i definisanje zahtjeva za informacionim sistemom ........................................................................... 3.1. Uvod u projektovanje i izgradnju informacionog sistema ....................... 3.2. Definisanje zahtjeva za informacionim sistemom ................................... 4. Analiza sistema ........................................................................................... 4.1. Uvod u analizu sistema .......................................................................... 4.2. Aktivnosti analize ................................................................................... 4.3. Definisanje zahtjeva koje sistem mora posjedovati ............................... 9 9 11 13 15 16 18 21 21 27 30 38 48 51 57 57 60 67 67 67 69
5. Modeliranje funkcija i procesa .................................................................. 77 5.1. Uvod u modeliranje funkcija i procesa ................................................... 77 5.2. Metode strukturiranog modeliranja, analize i dokumentovanja tehnolokih procesa ................................................... 83 5.3. Modeliranje toka podataka ..................................................................... 89 5.4. Elementarni procesi ............................................................................... 98
6. Modeliranje podataka ............................................................................... 101 6.1. Osnovni pojmovi modela podataka ...................................................... 101 6.2. Razvoj modela podataka ..................................................................... 111 6.3. Logiko modeliranje podataka ............................................................. 116 7. Modeliranje dogaaja ................................................................................. 123 7.1. Modeliranje procesa voeno dogaajima .............................................. 123 7.2. Matrica entiteti/dogaaji ......................................................................... 124 7.3. Model istorije ivota entiteta .................................................................. 128 7.4. Dijagram prelaza stanja ............................................ 129 7.5. Mape dijaloga .. 130 8. Inenjerski pristup izgradnji IS ................................................................. 132 8.1. Uvod ...................................................................................................... 132 8.2. Programsko inenjerstvo ....................................................................... 133 8.3. Informaciono inenjerstvo ..................................................................... 134 8.4. Sistemsko inenjerstvo ......................................................................... 135 8.5. CASE proizvodi ..................................................................................... 136 8.6. Reverzno inenjerstvo ........................................................................... 148 9. Oblikovanje i arhitektura informacionog sistema .................................. 151 9.1. Oblikovanje (dizajn) sistema ............................................................... 151 9.2. Arhitektura informacionog sistema ..................................................... 153 10. Dizajn baza podataka ................................................................................ 162 10.1. Uvod u dizajn baza podataka ............................................................. 162 10.2. Normalizacija ...................................................................................... 163 10.3. Denormalizacija .................................................................................. 164 10.4. Ugradnja pravila za ouvanje integriteta ............................................ 165 10.5. Podeavanje baze podataka .............................................................. 166 10.6. Trigeri u relacionim bazama podataka ............................................... 168 10.7. Implementaciono projektovanje, generisanje i programiranje BP pomou CASE alata ............................................... 176 10.8. ifarski sistem .................................................................................... 180 10.9. Rjenik podataka katalog ................................................................ 181 11. Dizajn programske podrke ..................................................................... 11.1. Specifikacija i dizajn programske podrke ......................................... 11.2. Pristup oblikovanju programa ............................................................. 11.3. Strukturirani dizajn ............................................................................. 11.4. Dizajn interfejsa .................................................................................. 11.5. Ulanavanje procedura .................................................................... 11.6. Organizacija modula i aplikacija ........................................................ 11.7. Standardizacija i modularnost programske podrke ....................... 186 186 186 187 191 194 195 196
7
201 201 201 202 204 209 211 213 213 216 221 222 224 225 226 233 233 233 234 235 236 236 237 238 239 240 241 242 243 245 245 246 246 247 248
12. Implementacija informacionog sistema .................................................. 12.1. Izrada sistema .................................................................................... 12.2. Programiranje (kodiranje) .................................................................... 12.3. Pristup programiranju ......................................................................... 12.4. Programski standardi i preporuke ...................................................... 12.5. Provjera ispravnosti informacionog sistema ....................................... 12.6. Izrada dokumentacije ......................................................................... 13. Logiko projektovanje programa i programski jezici ............................. 13.1. Dijagram toka (blok dijagram, algoritam) ............................................ 13.2. Strukturirani prirodni jezik (pseudokod) .............................................. 13.3. Akcioni dijagram ................................................................................. 13.4. Stablo odluivanja .............................................................................. 13.5. Tabele odluivanja .............................................................................. 13.6. Struktogram ........................................................................................ 13.7. Programski jezici ................................................................................ 14. Organizacija i upravljanje projektom ....................................................... 14.1. Generiki modeli organizacije ............................................................ 14.2. Organizacija i timski rad ..................................................................... 14.3. Modeli timova ..................................................................................... 14.4. Organizacija velikih projekata ............................................................ 14.5. Upravljanje projektom ........................................................................ 14.6. Planiranje projekata ........................................................................... 14.7. Tehnike za vremensko planiranje ...................................................... 14.8. Izrada plana ....................................................................................... 14.9. Prikaz plana ....................................................................................... 14.10. Raspodjela zadataka ....................................................................... 14.11. Evidencija projekta .......................................................................... 14.12. Praenje napretka (izvrenja) projekta ............................................ 14.13. Preporuke za planiranje poslova ..................................................... 15. Primjena i odravanje informacionog sistema ....................................... 15.1. Uvoenje sistema u primjenu ............................................................. 15.2. Obuka korisnika IS ............................................................................. 15.3. Odravanje informacionog sistema .................................................... 15.4. Poboljanje sistema i reinenjerstvo .................................................. 15.5. Elementi konfiguracije ........................................................................
10
tehnikom povezivanja programa, pisanih pomou 3GL, sa asemblerskim programima, ili daljim poveanjem mogunosti samih 3GL. Meutim, oekivanja da e programski proizvodi, koji su razvijeni upotrebom 3GL, pratiti potrebe krajnjih korisnika i mogunosti hardvera se ve 70-ih godina nisu ostvarila, to je dovelo do fenomena nazvanog softverska kriza. Osnovni pojavni oblik softverske krize je bio u tome da oekivani efekti od razvoja programskih proizvoda brzo izostaju, bez obzira na znatno poveanje ulaganja u ovu djelatnost, to je ilustrovano dijagramom na slici 1.1. Identifikovani su slijedei problemi kroz koje se softverska kriza prelamala. Programiranje upotrebom 3GL je bilo neefikasno i dugotrajno. Najvei dio programerskog vremena je odlazio na odravanje postojeih programskih proizvoda, to je blokiralo dalji razvoj IS. Tvrdnja da je najvei dio programerskog vremena odlazio na odravanje postojeih programskih proizvoda se moe potkrijepiti slijedeim statistikim podacima. Prema tim podacima 64% greaka pri razvoju IS se pravilo u toku analize korisnikih zahtjeva i projektovanja IS, dok se preostalih 36% greaka pojavljivalo tokom realizacije IS. Od pomenutih 64% ranih greaka, svega 30% je otklonjeno prije isporuke softvera. Pri tome, kasno otkrivanje i otklanjanje greaka iz poetnih faza razvoja programskih proizvoda dovodi do eksponencijalnog rasta trokova uvoenja u upotrebu i odravanje proizvoda. Tako, na primjer, otklanjanje strateke greke u fazi odravanja kota 100 puta vie nego kad se greka otkrije na poetku rada na projektu. Ovo je dovelo do jedne neprirodne raspodjele finansijskih sredstava, uloenih u razvoj IS, prema kojoj preko 70% ukupnih sredstava uloenih u razvoj IS odlazi na njegovo odravanje [Mogin et al. 2000].
Slika 1.1. Grafiki prikaz fenomena softverska kriza. Poveanje cijene odravanja i neefikasno programiranje su doveli do velikih zakanjenja u realizaciji projekata IS. Prema nekim podacima, veliki projekti u SAD su
11
1985. godine kasnili od 30 do 45 mjeseci. U skladu sa navedenim injenicama, vremenom su identifikovani slijedei uzroci softverske krize: 1. Projektovanje IS bez primjene odgovarajue metodologije dovodi do loeg projekta, pojave velikog broja greaka i prekoraenja zadanih vremenskih rokova zavretka projekta; 2. Nedostatak softverskih alata, koji bi podrali projektovanje IS ili automatizovali postupke projektovanja sa dovoljnim nivoom ekspertskog znanja. Ovo, takoe, vodi ka nekvalitetnom projektu uslijed oteanog rukovoenja projektom, fragmentiranog i nekonzistentnog dokumentovanja i neusaglaenosti dijelova projekta IS; 3. Nedostatak odgovarajuih softverskih alata za razvoj aplikacija IS, to vodi ka neefikasnoj realizaciji i odravanju IS. Svi ovi uzroci su doveli do prethodno opisanih posljedica. Rjeenje softverske krize je, prema tome, trebalo traiti u otklanjanju navedena tri uzroka. To je vodilo ka formalizaciji metodologija i tehnika projektovanja IS i pojavi CASE proizvoda i jezika 4. generacije (4th generation languages (4GL)), kao podrke odgovarajuim tehnikama i metodologijama.
12
dokumenata unutar nekog poslovnog sistema, kretanje materijala koji se obrauje, itd. Objekti u sistemu mogu biti veoma razliiti, a veze izmedju objekata u sistemu i dejstvo okoline na sistem se ostvaruje na tri naina: razmjenom materije, energije ili informacija.
ULAZ
O3
On
Slika 1.2. Opti prikaz sistema. Rije informacija, u svakodnevnom govoru, ima smisao obavjetavanja, objanjenja, prenoenja znanja. Za pojam informacije uobiajene su slijedee definicije: "Informacija je kapacitet poveanja znanja" [I. Wilson, 1975]; "Informacija je neto to ukida ili smanjuje neodreenost" [N. Winer, 1979]. Iz ugla upravljanja i donoenja odluka, informacija se moe razmatrati kao svaka vrsta znanja ili poruka koja moe da se upotrijebi za poboljanje upravljanja u nekom sistemu. Ako se poveu definicije pojmova sistema i informacije, moe se izvesti slijedea opta definicija informacionog sistema: Informacioni sistem (eng. Information System) je sistem u kome se veze izmedju objekata i veze sistema sa okolinom ostvaruju razmjenom informacija. Takoe, informacioni sistemi su sastavni deo upravljanja ("odranja eljene organizovanosti") nekog sistema. Iz tog ugla posmatranja moe im se pridodati atribut "upravljaki" i definisati upravljaki IS kao sistem koji prenosi, uva i obrauje podatke pretvarajui ih u informacije potrebne za upravljanje. Pojmovi podatak i informacija se, u svakodnevnom govoru, koriste kao sinonimi. Medjutim, za precizno razgranienje koncepata o kojima se govori, neophodno je i ova dva pojma precizno definisati i razgraniiti.
13
Podatak je kodirana predstava o nekoj injenici iz realnog svijeta, on je nosilac informacije i slui za tehniko uobliavanje informacija, kako bi se one mogle sauvati ili prenijeti. Informacija je protumaeni podatak o pojavi koju podatak prikazuje. Krajnje tumaenje nekom podatku daje sam primalac (ovjek), uz pomo razliitih postupaka obrade podataka. Osnovna funkcija IS je uvanje i prenos podataka o injenicama iz sistema i njegove okoline i njihova obrada u informacije koje zahtjeva korisnik. Znanje se gradi na osnovu novih informacija koje se nadovezuju na postojee znanje. Isti podaci mogu biti razliito interpretirani od strane razliitih ljudi u zavisnosti o njihovom znanju.
Organizacija je struktura i poredak, odnosno hijerarhijske veze koje odreuju formalnu komunikaciju i upravljaki lanac (npr. ustanova, preduzee). Interakcija predstavlja nain na koji pojedine komponente sarauju sa drugim komponentama (npr. Nabavka sa Proizvodnjom, Proizvodnja sa Prodajom). Meuzavisnost pokazuje
14
da jedan podsistem zavisi od drugog (ulaz) da bi mogao funkcionisati, dok je integrisanost mjera povezanosti komponenti. Za informacione sisteme se mogu izdvojiti bitni elementi i definisati njihovne glavne osobine: (1) sistemi za obavjetavanje, odnosno informacioni sistemi; (2) sistemi za upravljanje informacijama vanim za organizaciju i drutvo; (3) sistemi za upravljanje sadrajem ljudskih aktivnosti [Checkland, 1980]. Pojam informacionog sistema podrazumijeva sisteme koji su podrani raunarom, tj. raunarski (kompjuterizovani, kompjuterski) i sisteme koji se ne oslanjaju na raunare, ali obrauju informacije. Namjena IS je prikupljanje i pruanje informacija korisnicima u jednom ili vie poslovnih sistema, te se mogu nazvati organizacioni IS. Korisnici informacionih sistema su poslovodstvo, radnici (zaposleni, osoblje), klijenti i drugi. Upravljanje informacijama se obavlja bez obzira na vrstu sistema, a sainjavaju ga: prikupljanje podataka, zapisivanje i pamenje podataka, obrada podataka, skladitenje i pronalaenje informacija, kao i prikaz informacija u odgovarajuem obliku. Informacioni sistem je podsistem poslovnog sistema. Sainjavaju ga ulazni podaci i izlazne informacije, procesi (obrada podataka o stanjima stvarnog sistema) i izvrioci (osobe, programi, raunari). Poslovne sisteme sainjavaju materijalni ulazi i izlazi (sirovine, energija, proizvodi) i informacioni tokovi (poruke, dokumenti). Ulaz u neki poslovni sistem predstavlja izlaz iz nekog drugog poslovnog sistema. Poslovni sistemi sadre procese (npr. obrada, prerada, proizvodnja), povratne veze (npr. poreenje plana i realizacije), skladita podataka (informacija), izvrioce (osobe, maine, alati, sirovine), skladita materijala, ... . Informacioni sistem odreuju slijedee karakteristike: sloena okolina, koju je teko u potpunosti definisati, sloeni interfejs prema okolini, koji ukljuuje razliite ulaze i izlaze, sloene veze izmeu ulaza i izlaza (strukturno i algoritmiki), kao i veliki obim i sloenost podataka. Problemi projektovanja, izrade i odravanja IS se prevazilaze zbog vanosti IS za jedan poslovni sistem. Informacija je postala upravljaki resurs jednake vanosti kao to su vlasnitvo (osnovna sredstva), ljudski resursi ili kapital. Informacioni sistem sadri/predstavlja znanje organizacije koju podrava. IS i aplikacije pokazuju se prijeko potrebnim za odravanje konkurentnosti ili postizanje kompetitivnog prestia poslovnog sistema. Poslovni sistemi u kojima se IS primjenjuju visoko su zavisni o stalnoj raspoloivosti IS kroz due vrijeme.
15
16
17
odreivanje (granica) projekata. Planiranje projekta se sastoji od izrade plana rada, odreivanja kadrova za projekat, upravljanje i nadzor projekta. Poslovni cilj je izrada glavnog projekta informatizacije. Analiza zahtjeva je detaljna analiza kojom se preciziraju granice projekta i poslovni zahtjevi. Vri se detaljna analiza postojeeg sistema, problema i poslovnih zahtjeva. Specifikacija zahtjeva je detaljni opis zahtjeva za IS, oblikovan tako da ga razumiju dizajneri. Predstavlja model budueg sistema. Oblikovanje sistema, odnosno dizajn (modeliranje) IS, predstavlja pogled projektanta na budui IS. Slui za donoenje odluke o tome kako graditi sistem. Sadri dizajn potrebnih rjeenja. Postoje rjeenja koja ne treba dizajnirati. Detaljni dizajn predstavlja razradu rjeenja, odnosno izradu tehnolokog modela IS (pogled izvoaa). Potrebno je izvriti dizajn arhitekture, interfejsa, pohranjivanja podataka i programa, drugim rijeima izvriti tehniku specifikaciju sistema. Izrada (implementacija) podrazumjeva ugradnju baze podataka (BP), kodiranje procesa (funkcija) novog IS, a vri se nakon odabira raunarske platforme. Testiranje je provjera ugraenih komponenti. Integracija i provjera sistema je udruivanje dijelova i provjera cjeline, da bi se dokazalo da sistem radi (da je ispravno napravljen), te da radi ono to je zahtijevano (da je napravljen pravi sistem koji ispunjava zahtjeve korisnika).
Slika 1.3. Dijagram ivotnog ciklusa i faza razvoja IS [Fertalj & Kalpi, 2005].
18
Uvoenje u primjenu sistema predstavlja prenoenje radnih aktivnosti i konverzija podataka sa starog na novi sistem. Odravanje se sastoji od izmjena sistema radi poboljanja njegovih radnih karakteristika (performansi), poboljanja ili prilagoavanja naina upotrebe. Odravanje podrazumjeva i podrku dobavljaa opreme, pomo tehnikog osoblja korisnicima informacionog sistema u toku njegove upotrebe, kao i izradu plana odravanja. Novi razvojni ciklus se provodi nakon preispitivanja itavog sistema i konstatacije da su potrebne vee izmjene uslijed promjena u poslovanju ili promjena poslovnih ciljeva. Novi razvojni ciklus, najee, predstavlja novi projekat. Na slici 1.4 su navedene tipine faze ivotnog ciklusa razvoja softvera, bez naglaavanja da se radi o diskretnim i/ili sekvencijalnim aktivnostima.
19
cijeni. Neki od problema koji se mogu pojaviti prilikom razvoja IS su: prekoraenje planiranog vremena i finansijskih sredstava, neispunjavanje zahtjeva, odnosno neodgovarajui sistem, nepouzdanost, nesigurnost, neelastinost IS u primjeni, kao i tekoe u odravanju IS. Oko 70% informacionih sistema u svijetu se smatra neuspjenim. Prosjeno kotanje projekta prema The CHAOS Report [Standish Group, 1994, http://www.standishgroup.com] iznosi: velike kompanije 2,32 miliona $, srednje kompanije 1,33 miliona $ i male kompanije 434 hiljade $. Prosjeno prekoraenje trokova je 189%, a prosjeno prekoraenje rokova 222%. Projekti zavreni na vrijeme, u okviru predvienih sredstava i sa predvienim funkcijama, sainjavaju 16,2%, a projekti zavreni i u funkciji, ali uz vee trokove, due trajanje i/ili reduciranu funkcionalnost 52,7%. Prekinutih projekata je 31,1%. Procenat uspjenih i neuspjenih projekata IS prema Standish Group, 2002. iznosi 34% uspjenih projekata i 17% potpunih neuspjeha.
20
organizacije, pretjerani optimizam, izostanak praenja napretka i nedostatak komunikacije izmeu korisnika i izvoaa. U naem okruenju uzroci neuspjeha se, uglavnom, ne istrauju, a informacije o neuspjenim projektima nerado se objavljuju. Meu najeim uzrocima moe se pretpostaviti da su: loa organizacija i voenje projekata, oslonac na vanjske projektante i savjetnike, delegirano upravljanje projektima, nerealno planiranje, formalno izvjetavanje o napretku, formalni nadzor nad projektom, kao i podcijenjena uloga vlastitih strunjaka. Ne treba iskljuiti i slijedee uzroke neuspjeha: loa izvedba projekata, neodgovarajua analiza sistema, greke u dizajnu i kontroli kvaliteta, neodgovarajui CASE alati i krivo koritenje, pa ak i svojevrsna zloporaba CASE alata. Mnogi sistemi su propali, ili su bili odbaeni, jer su se izvoai trudili napraviti lijepa programska rjeenja, a nisu razumjeli sutinu poslovnog sistema i poslovanja.
21
22
Nedostaci i rizici su takoe prisutni. Dolazi do gubitka povjerljivih informacija, gubitka nadzora nad sadanjim i/ili buduim razvojem (zavisnost o dobavljau), kao i gubitak vlastite strunosti. Nuno je da upravljanje projektom informatizacije na sebe preuzme vlastito kompetentno osoblje koje ima mogunost odluivanja.
23
konsultanata. Mogui modalitet nabavke je da se prilagoavanje vri vlastitim snagama uz savjetovanje i pomo dobavljaa.
U dodatne kriterijume mogu se svrstati: otvorenost sistema (portabilnost, interoperabilnost), tehnike mogunosti (Client-Server, OLTP, OLAP), referense dobavljaa (prisutnost dobavljaa na lokalnom tritu) i podrka korisnicima. Pod podrkom korisnicima se podrazumjeva: kolovanje, tehnike konsultacije, odravanje (dinamika razvoja i mogunosti nabavke novih verzija), blagovremeno otklanjanje problema, ponuda gotovih aplikacija, kao i pomo u razvoju vlastitih aplikacija.
24
potrebama, ta daje elastinost pri promjenama organizacije poslovanja. Nema bojazni da e nakon prve potrebne izmjene prestati upotreba IS zbog toga to isporuilac nije trenutno dostupan, postavlja nerazumne uslove ili je u meuvremenu nestao sa trita. Uvidom u kvalitetna gotova rjeenja pomae se razvoju vlastitih informatikih radnika. Mane narudbe izvornog koda su, takoe, prisutne. Izvorni kd je viestruko skuplji od izvedbenog. Potrebna je razvojna varijanta programskog alata u kojem je IS razvijen. Naruilac se izlae iskuenju da nekompetentno mijenja nabavljeni izvorni kd, onesposobi aplikaciju za rad i izgubi pravo na odravanje. Odravanje je skuplje ukoliko se radi o programskoj opremi podlonoj promjenama. Snienje cijene izvornog koda moe se postii automatizacijom kodiranja, upotrebom generatora izvornog koda. Preporuke za izbor programskog koda su slijedee. Izvedbeni kd treba preporuiti u slijedeim sluajevima: kada se radi o standardnim, masovno prodavanim aplikacijama, kada korisnik nema vlastite informatike strunjake, kada se radi o visokostrunim aplikacijama koje se nee mnogo mijenjati, a korisnik nema namjeru da se baviti detaljima te struke, kada korisnik nema novaca ili elje za vlastiti informatiki razvoj. Izvorni kd treba preporuiti onda: kada programska oprema predstavlja strateku investiciju, kada korisnik raspolae kompetentnim informatiarima ili ima motiva razvijati vlastitu informatiku djelatnost, kada isporuilac ne moe preuzeti obavezu odravanja ili ne moe garantovati da e ostati na tritu, kada na tritu ne postoji IS koji odgovara potrebama, ne moe se povoljno kupiti slian, a korisnik raspolae vlastitim informatikim snagama dovoljnim za projektovanje novog.
25
karakteristike moguih rjeenja, karakteristike i cijene hardvera i softvera, referense i uslovi dobavljaa, a izlazi analiza izvodljivosti za svako mogue rjeenje. Prijedlog rjeenja sistema koji e se oblikovati i ugraditi se donosi na osnovu izbora onog rjeenja koje ima najbolju ukupnu kombinaciju izvodljivosti. Ulazi su napravljena analiza izvodljivosti, plan projekta, procjena veliine projekta, a izlazi prijedlog sistema sa usvojenim promjenama dizajna predloenog sistema.
Teinski Super Video Video Boss Video ZZ Video faktor Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi
2 1 4 1 1 2 2 2 4 3 4 3 1 1 2 3 1 1 2 3 4 4 5 4 0 5 5 4 5 4 2 5 5 3 5 5 3 3 2 3 8 4 20 4 0 10 10 8 20 12 8 15 5 3 10 15 3 3 4 9 4 4 4 5 0 5 0 0 1 3 3 5 0 5 0 5 2 3 5 2 8 4 16 5 0 10 0 0 4 9 12 15 0 5 0 15 2 3 10 6 1 2 1 2 5 3 0 0 2 0 5 0 0 5 5 0 5 5 4 5 2 2 4 2 5 6 0 0 8 0 20 0 0 5 10 0 5 5 8 15 3 1 4 2 0 3 0 4 5 0 5 0 0 3 5 3 5 5 2 3 6 1 16 2 0 6 0 8 20 0 20 0 0 3 10 9 5 5 4 9
Ukupno bodova:
171
124
97
124
26
Si = 3sij wj
j =1
gdje su: Si = ukupna vrijednost i - tog rjeenja, sij = vrijednost j - tog kriterijuma za i - to rjeenje, wj = vanost ili teina j - tog kriterijuma. Najbolji je onaj sistem sa najveim brojem bodova (npr. Super Video, tabela 2.1). esto se mogu javiti slijedee nedoumice: ta uiniti kada su sistemi (pod)jednako bodovani? ta uiniti ako pojedino svojstvo ima vie podsvojstava?
27
Analiza organizaciono - operativne izvodljivosti projekta sadri procjenu hitnosti rjeavanja problema (planiranje), kao i procjenu prihvatljivosti rjeenja (kasnije faze). Tu se neminovno nameu i slijedea pitanja: Vrijedi li rjeavati problem? i Da li predloeno rjeenje rjeava problem? Da bi se odgovorilo na ova pitanja potrebno je analizirati: performanse (odnosno protonost i odziv sistema u odnosu na ulaze), informacije (da li su dovoljne, pravovremene, prikladne, aurne, tane, korisne), ekonomiske aspekte (gdje spadaju problemi trokova i mogunosti uteda), kontrolu (u prvom redu sigurnost i zatitu podataka), efikasnost (odnosno poboljavanje upotrebe raspoloivih resursa: ljudi, opreme, novca, itd.), kao i usluge (poeljni i pouzdani servisi, elastinost i mogunost prilagoavanja, zadovoljstvo). Nita manje bitni nisu ni odgovori na slijedea pitanja: Koji je stav korisnika prema rjeenju? i Da li e se sistem koristiti? Neophodni su podrka uprave i prihvatanje sistema od krajnjih korisnika. Treba na vrijeme uoiti otpore ulozi ili tehnikim
28
rjeenjima sistema i predloiti naine njihovog otklanjanja. Krajnjeg korisnika treba na vrijeme pripremiti za promjenu radnog okruenja i procedura. Procjena upotrebljivosti sistema se najlake moe izvriti koritenjem prototipa. Potrebno je pravilno ocjeniti potrebno vrijeme osposobljavanja korisnika za postizanje pune primjene sistema. Namjeniti jednostavni interfejs za poetnike i povremene korisnike, sloenije operacije za iskusne korisnike. Obezbjediti da korisnik daje prednost ponuenom rjeenju u odnosu na postojei nain rada. Analiza tehniko - tehnoloke izvodljivosti projekta sadri procjenu moguih rjeenja i alternativa. U prvom redu potrebno je izvriti procjenu stanja na tritu opreme, procjenu postojeih rjeenja u drugim organizacijama (tamo gdje je mogue), kao i procjenu primjenjivosti razliitih tehnologija. Veoma bitna osobina je da se zastupljena tehnoloka rjeenja mogu jednostavno primijeniti. Raspoloivost tehnologije podrazumijeva da se primjenljiva tehnologija moe nabaviti. Ako je rije o gotovom rjeenju, ima li to rjeenje potrebne karakteristike, ili ga u nekoj mjeri treba prilagoditi ili doraditi. Nita manje bitno nije ni injenica da li postoje potrebni strunjaci za primjenu nove tehnologije. Pri tome treba imati na umu da se i najnovija tehnologija moe savladati. Analiza vremenske izvodljivosti projekta treba da d odgovor da li su predvieni rokovi ostvarivi, obzirom na raspoloivu strunost. Oekivano vrijeme zavretka moe biti poeljno ili obavezno. Bolje je isporuiti ispravan sistem dva mjeseca kasnije, nego neispravan ili beskoristan na vrijeme! Ekonomska izvodljivost projekta e biti objanjena preko analiza i uporedbe ukupnih trokova - koristi (cost-benefit analysis (CBA)). Trokovi i korist mogu biti mjerljivi (npr. cijena opreme, iznos plata, prodaja, prihod, ...) i nemjerljivi (npr. zadovoljstvo korisnika, brzina odluivanja, dobra referensa). Finansijski troak i korist se mogu izraziti formulama: (1) razlika korist troak u nekom razdoblju (Net Present Value), (2) povrat investicije (korist troak)/troak (Internal Rate of Return), (3) trenutak u kojem korist nadvlada troak (Payback Point). CBA rauna trokove i korist projekta kao trenutnu vrijednost (Present Value (PV)). Dananja vrijednost onoga to e postati $1,00 nakon n godina u budunosti, ako se uzmu u obzir kamate I iznosi: PV = 1/(1 + I)n = (1 + I) n Razlika predstavlja kamatu koja se moe zaraditi tim novcem ($ oznaava novanu jedinicu u bilo kojoj valuti). . Primjeri: Trokovi razvoja od $100.000 imaju trenutnu vrijednost od $100.000;
29
Korist projekta u iznosu od $30.000 za pet godina uz kamatnu stopu od 8% ima trenutnu vrijednost od samo: $30.000 / (1 + 0.08)5 = $20.417 Povrat investicije (Return On Investment (ROI)) se obino dijeli sa duinom trajanja projekta kako bi se dobio godinji ROI. Nizak ROI (~ manji od 10% godinje) moe pokazivati da je korist preniska da bi bila isplativa. Odnos troak/korist je prikazan tabelom 2.2 i grafikim prikazom tabele. Primjer: Analiza troak korist [Fertalj & Kalpi, 2005]. Tabela 2.2.
30
Razlozi zbog kojih treba planirati IS su viestruki. Na primjer, u Poslovnom sistemu koji se sastoji od vie cjelina, kao to su Uprava, Finansije, Proizvodnja i Informatika esto postoji vie razliitih tehnikih sistema ili aplikacija, takozvanih informatikih ostrva. To ima za posljedicu umnoavanje informacija uz razliito tumaenje u razliitim dijelovima, nepotpunost informacija, naroito kada svaka cjelina prikuplja samo njoj vane informacije, problem povezivanja informacija pri pokuaju cjelovite interpretacije, kao i problem razliitog posluivanja, razmjene podataka i odravanja.
31
Tradicionalno planiranje IS se provodi odvojeno od poslovnog planiranja ili provodi se kao reakcija na promjene u poslovnoj politici. Strategojsko planiranje IS je prikladno za stabilne poslovne sisteme. U praksi je teko izvodljivo u uslovima preivljavanja. Sastoji se od uspostave smjera i prioriteta usklaivanja informacionih servisa u skladu sa misijom, vizijom i ciljevima poslovnog sistema, planiranja IS u skladu sa strategijom razvoja poslovnog sistema, tako da informatizacija bude podrka promjeni poslovnog sistema i poslovnih procesa. Jo se mogu navesti primjene metoda analize i dizajna za prouavanje poslovnog sistema, sa ciljem definisanja opteg (sveobuhvatnog) plana i arhitekture IS iji razvoj slijedi. U praksi situacija je slijedea. Umjesto prema strategijskom planu, poslovni sistem se "dovodi u red" tokom informatizacije i pomou informatizacije. Analizom sistema evidentiraju se problemi i slabosti poslovnih procesa, budui da se dizajnom sistema predlau ili nameu poboljanja.
32
uesnika iz razliitih djelatnosti, npr. radnici razliitih poslovnih podruja ili organizacijskih jedinica, uprava, vanjski konsultanti), pri emu je vano osigurati predanost uesnika zajednikom cilju, i, na kraju, uspostava upravljanja i nadzora projekta.
Srednja
515000
Novi razvoj
12 mjeseci
Niska
15000
3 mjeseca
Visoka
35000
Nakon razvoja novog sistema, pruiti korisnicima lako savladive alate za pisanje izvjetaja. Brza ispravka, a zatim novi razvoj.
33
Novi razvoj, dodatna ocjena koristi moe poveati aurnost. Budue verzije tek razvijenog sistema. Brza ispravka, a zatim novi razvoj.
12 mjeseci 3 mjeseca
Niska Visoka
nepoznata 65000
4 1
Vidljivost: U kojoj mjeri e rjeenje ili novi sistem biti vidljivi korisnicima. Korist: Paualna procjena koliko bi rjeenje povealo dobit ili smanjilo troak u jednoj godini.
Vremensko planiranje obuhvata odreivanje prioritetnih zadataka i vremenskih okvira prioriteta. Izrada poetnog (preliminarnog) plana razvoja IS zapoinje podjelom projekta u manje cjeline i odreivanje redoslijeda realizacije pojedinih podprojekata. Ovakvim pristupom se dobija okvirni vremenski plan rada po fazama, obavlja razrada i raspodjela poslova, kao i odreivanje prioriteta. Nastoji se pronai takva podjela posla na cjeline da cjelinu moe obaviti jedna osoba ili ekipa, da se cjelina moe obaviti jednom metodom i posao zavri jednim proizvodom (dokumentom, aplikacijom ili podsistemom). Poetni plan razvoja IS sadri nazive podprojekata i omoguava doradu i auriranje u skladu sa napretkom projekta. Moe se koristiti za prezentaciju projekta radi traenja saglasnosti o njegovom nastavku. Konsolidovani prijedlog projekta moe posluiti kao interni ugovor projekta (tabela 2.4).
34
Primjer: Poetni (preliminarni) plan informacionog sistema, tabela 2.4. Tabela 2.4.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Nabavka sistema za upravljanje bazama podataka; Obuka opte informatike pismenosti za rukovodioce odjeljenja; Obuka za programere u jeziku za upravljanje bazama podataka; Obuka za administratore baze podataka; Izrada prototipa programske podrke za i-tu fazu realizacije; Izrada - verzije aplikacije; Testiranje - verzije u informacionim sistemima; Uklanjanje uoenih nedostataka i izrada - verzije programa; Obuka za odabrane korisnike na - verziji; Testiranje kod korisnika u paralelnom radu sa dosadanjim programom; Uklanjanje nedostataka i izrada stabilne verzije; Zamjena dotadanjeg programa novim programom, uz preuzimanje podataka; Obuka za ostale korisnike; Uvoenje koritenja programa kod ostalih korisnika; Obuka za upoznavanje sa mogunostima programa za odabrano poslovodstvo; Prikupljanje primjedbi korisnika i novih zahtjeva; Izrada slijedee faze/verzije programa. Povratak na taku 5).
Detaljan prijedlog - Obrazloenje prijedloga * Hitne prepravke * Brze prepravke * Unapreenja * Novi razvoj Plan projekta * Poetni ciljevi projekta * Poetni glavni plan projekta (na nivou faza) * Detaljni plan za slijedeu fazu Prilozi - Zahtjev za uslugama sistema - Matrica obrazloenja problema - (ostala dokumentacija)
35
Zadatak analitiara je da razdvoji uzroke i posljedice problema. Drugi primjer: Dug red u videoteci nije poseban problem, a moe biti posljedica pomanjkanja osoblja, 'lijenosti' ili nezainteresovanosti osoblja za posao ili pak posljedica runog unosa podataka i izdavanja rauna.
36
U razmatranom primjeru analitiar treba razmotriti da li je zahtjev vlasnika videoteke za ubrzanjem procesa izdavanja filmova realan. Primjeri poslovnih ciljeva mogu biti raznovrsni. Ovdje e biti navedeni, kao primjeri, neki od moguih ciljeva: pomoi reorganizaciju u trino orijentisanom poslovnom sistemu prema EU normama, osigurati informacije o izvorima, razlozima i mjestu nastanka svakog troka u sistemu, uskladiti hijerarhiju odluivanja sa hijerarhijom u poslovnom sistemu ili racionalizovati utroak novca za ... . Ogranienja mogu biti slijedea: osoblje (npr. odjel informatike smije zaposliti najvie tri stalno zaposlena radnika), materijalni troak (npr. nabavka kancelarijskog i potronog materijala ne smije premaiti XXX ),raunarska oprema (npr. projekat se mora obaviti bez nabavke novog hardvera ili poeljno je da troak opreme predstavlja najmanje 33% budeta), finansijska sredstva (npr. ukupni budet projekta je XXXXX ) ili naknade izvoaima ne smiju prekoraiti XX% ukupnog iznosa). Analiza uzroka i posljedice problema, njihovi ciljevi i ogranienja su prikazani u tabeli 2.6 [Fertalj & Kalpi, 2005]. Tabela 2.6.
ANALIZA UZROKA I POSLJEDICA Problem ili mogunost 1. Vrijeme odgovora na narudbu je neprihvatljivo dugo. Uzroci i posljedice 1. Promet je povean, a broj slubenika smanjen. Vrijeme obrade narudbe je isto. 2. Sistem previe zavisi o runom unosu. Pojedine vrijednosti se unose vie puta. Posljedica je da se narudbe obrauju due nego je potrebno. 3. Sredinji raunar radi na maksimumu svoga kapaciteta, ta se ogleda u sporijem radu aplikacije za unos narudbi. Budui da slubenici pokuavaju bre raditi, poveao se broj greaka pri unosu. CILJEVI I OGRANIENJA SISTEMA Ciljevi sistema 1. Smanjiti vrijeme unosa pojedine narudbe za 30%. 2. Runi unos narudbi svesti na 50% ukupnog broja. 3. Na ekranskoj formi raunara za runi unos smanjiti broj potrebnih pritisaka na tastaturu. 4. Prenijeti unos podataka sa sredinjeg raunara na PC. 5. Zamjeniti postojee obrasce za prikupljanje narudbi mrenim sistemom izmeu skladita i prodaje, tako da se eliminie upotreba Ogranienja sistema 1. Broj zaposlenih u obradi narudbi se ne moe poveati. 2. Novi sistem mora biti kompatibilan sa postojeim Windows XX standardom. 3. Novi sistem mora biti kompatibilan sa ve odabranim sistemom za automatsku identifikaciju tapiastim kodom.
37
4. Obrasci za prikupljanje narudbi iz skladita nisu oblikovani za racionalno popunjavanje, to dodatno usporava unos narudbi.
papirne dokumentacije.
38
(alternativa) i prijedlog najboljeg rjeenja, a pored toga vratiti uloenu investiciju. Na kraju se (opet!) moe oekivati pokretanje, odbacivanje, odgaanje ili prilagavanje (ostalih, pojedinih) projekata. Tabela 2.7 prikazuje idejno rjeenje plana razvoja IS. Tabela 2.7.
Saetak - Saetak prijedloga - Saetak problema, mogunosti i direktiva - Kratki navod ciljeva unapreenja sistema - Kratki navod sadraja izvjetaja Poznate informacije - Popis odranih razgovora i kordinisanih grupnih sastanaka - Popis ostalih izvora informacija - Opis tehnika koritenih u analizi Pregled postojeeg sistema - Strategijske odrednice - Modeli postojeeg sistema * Model interfejsa (kontekst) * Model resursa (prostor) * Model procesa (funkcija) * Model podataka (kategorije) Analiza postojeeg sistema
* problemi, mogunosti i analiza uzroka i posljedica za pojedine elemente
- Performanse - Informacije - Ekonomija - Kontrola - Djelotvornost - Usluge (servisi) Detaljni prijedlozi - Ciljevi i prioriteti unapreenja sistema - Preporuke unapreenja sistema - Plan projekta * Precizirati domet projekta * Revidirati glavni plan * Detaljni plan za slijedei korak Dodaci - Modeli sistema (ako nisu dio studije) - (ostala dokumentacija prema potrebi)
39
gdje je greka napravljena. Ovakav nain primjene metodologije ivotnog ciklusa i strukturiranog pristupa se zove sekvencijalni ili vodopadni (waterfall) model primjene metodologije ivotnog ciklusa. Dobre strane ovog pristupa su: integrisanost IS, dobra dokumentovanost i praktino istovremeni zavretak svih podsistema IS. Zahvaljujui dobroj dokumentovanosti pojednostavljeno je odravanje aplikacija IS. Takoe, ovaj pristup daje dobre garancije da e, u konanom vremenu, doi do zadovoljavajueg rjeenja programskog proizvoda, ime se smanjuje rizik od neuspjeha razvoja. Sekvencijalni pristup, pored dobrih osobina, ne daje uvijek prave efekte kada je u pitanju ostvarenje prethodno definisanih ciljeva. Uzroci su viestruki, a neki od njih su slijedei [Mogin et al. 2000]: 1. U sekvencijalnom modelu primjene metodologije ivotnog ciklusa krajnji korisnik nije dovoljno ukljuen u proces razvoja programskog proizvoda; 2. Izmeu poetka projekta i prvih operativno primjenljivih rezultata kod korisnika vremenski interval je dosta dug; 3. esto se javlja potreba da se precizni, metodoloki kompleksni projektantski koraci izvode na osnovu nedovoljno precizno identifikovanih informacionih zahtjeva; 4. Umjesto da to bude postupno, postoji potreba da se u razvoj IS odjednom uloe znaajna finansijska sredstva. Uzajamnio djelovanje prva tri nedostatka sekvencijalnog pristupa ima za posljedicu da se skrivene mane programskog proizvoda i prethodno neidentifikovani korisniki zahtjevi esto otkrivaju tek u fazi uvoenja aplikacije u upotrebu, to je jako kasno jer se korekcija greaka i odravanje komplikuju, a produava se vrijeme potrebno za dobijanje konanog rjeenja aplikacije. U cilju izbjegavanja negativnih efekata sekvencijalnog pristupa javio se prototipski pristup, kao i evolutivni, inkrementalni, spiralni, zvjezdasti, V model i drugi manje znaajni modeli. Mogu se izdvojiti slijedee varijante sekvencijalnog (vodopadnog) modela: klasini vodopadni model, pseudostrukturirani vodopadni model i radikalni (strukturirani) razvoj. Klasini vodopadni model (slika 2.1(a)) redoslijedno (sekvencijalno) napreduje iz faze u fazu. Nisu dozvoljene naknadne promjene rezultata prethodnih faza. Prikladan je velikim projektima (investicijama), za dobro definisano okruenje, gdje postoje razraene procedure rune obrade ili raunarski sistem koji treba unaprijediti. Nedostaci ovog modela su izraeni u sluaju greaka ili novih/promijenjenih zahtjeva, kao i u potrebi uvoenja prema gore (bottom up) modula, podsistema i sistema. Sistem nije upotrebljiv dok nije u potpunosti gotov. Problem predstavlja i predodba o proizvodu na osnovu pisane specifikacije.
40
Pseudostrukturirani vodopadni model (slika 2.1(b)) sadri povratnu vezu i mogunost promjene rezultata prethodnih faza. Ovaj model razvoja IS omoguava primjenu tehnika strukturiranog programiranja.
Analiza
Oblikovanje
Izrada
Evaluacija
Slika 2. 1. Uporedni prikaz klasinog razvoja (a), pseudostrukturiranog i radikalnog razvoja (b). Radikalni (strukturirani) razvoj (slika 2.1(b)) omoguava da se aktivnosti razliitih faza mogu obavljati istovremeno. Dozvoljava koritenje rjenika podataka, programskih jezika etvrte generacije (4GL) i generatora aplikacija. Prikladan je kada se unaprijed ne zna konani izgled sistema.
41
Test prihvatljivosti Testirani sistem
Analiza
Scenariji aplikacije
Specifikacija zahtjeva
Strukturirano oblikovanje
Ogledni sluajevi
Integracija sistema
Ogledni sluajevi
42
vieekranski model kojim se prikazuje kako e izgledati dio sistema (npr. interfejs), istraivaki model, za istraivanje dijelova sistema kako bi se provjerile neke kljune postavke (npr. provjera performansi odreenog modula) i, na kraju, ugradbeni model, tj. traenje razliitih naina na koje se sistem moe izgraditi (npr. koji sistem za upravljanje BP, programski jezik, raunari). Prototip moe postupno, inkrementalnom doradom, da postane dio zavrnog IS. Prototipski razvoj podrazumijeva iteraktivni pristup, obino koritenjem 4GL. Radni model daje se na uvid korisniku i omoguava korisniku stvaranje slike o izgledu sistema. Korisnik daje primjedbe za popravak i poboljanja, ime se stie bolja slika o zahtjevima korisnika. Ujedno se uklanjaju mogua iznenaenja na kraju razvoja. Savremeni softverski alati omoguavaju brzu izradu prototipa. Funkcionalni prototip dogradnjom moe da postane radni sistem (slika 2.3). Ovakav pristup razvoju IS je prikladan za male projekte. Prednosti su u iteracijama promjena (korisnici se smiju predomisliti), poveanju kreativnosti i brzini razvoja. Nedostaci su u tome to se zaboravlja da prototip nije pravi sistem, mogui neuspjeh zamjene prototipa radnim sistemom, dokumentacija proizlazi iz izrade pa postoji opasnost da pisane specifikacije nikad nee biti napravljene, kao i nemogunost ispravne procjene i planiranja resursa. Ogranieni/strukturirani razvoj prototipa slui kao sredstvo za odreivanje zahtjeva. Dobija se nefunkcionalni prototip (koji se ne moe koristiti u obavljanju radnih zadataka korisnika, a sadri izgled ekranskih formi, menia i izvjetaja), iji se razvoj u odreenom trenutku prekida i slijedi faza oblikovanja sistema (slika 2.4). Odreivanje zahtjeva
Radni sistem
43
Odreivanje zahtjeva Dizajn prototipa Izrada prototipa Razvoj prototipa Radni sistem Prototip Dokumentovanje zahtjeva Oblikovanje Specifikacije zahtjeva
Slika 2.4. Dijagram ogranienog/strukturiranog razvoja prototipa. Praktini aspekti primjene prototipskog pristupa su viestruki. Rije je, uglavnom, o injenicama proisteklim iz iskustva u praktinoj primjeni prototipskog pristupa. Zbog toga, moe se rei da su te injenice prije savjetodavnog, nego formalno strogog karaktera. Opte preporuke za primjenu prototipskog pristupa su slijedee [Mogin et al. 2000]: 1. Potrebno je, prije poetka primjene prototipskog pristupa, precizno definisati standarde za izgled korisnikog interfejsa, projektovanje i programiranje. Standarde treba usaglasiti sa mogunostima odabranog CASE proizvoda, a generator programskog koda upotrebljenog CASE proizvoda treba prilagoditi za programiranje i izgled korisnikog interfejsa, a sve u cilju postizanja bolje podrke standarda; 2. Preporuuje se dekomponovanje cjeline IS na manje projekte, a zatim definisanje nieg stepena meusobne integracije informacionih podsistema, u odnosu na klasinu primjenu metodologije ivotnog ciklusa; 3. Kako korisnik ne bi bio doveden u zabludu, prilikom predaje korisniku prototipa aplikacije, obavezno ga upoznati sa injenicom da je u pitanju prototip a ne konano rjeenje. Pri tome treba precizirati nain upotrebe prototipa od strane korisnika;
44
4. Ne treba praviti vie od tri prototipa jedne aplikacije, ukoliko je to mogue, kako se ne bi produilo ukupno vrijeme izrade aplikacije i dolo do zamora krajnjih korisnika i projektantskog tima; 5. Treba se orijentisati preteno ka odbacivim prototipovima aplikacija, ukoliko se eli postii to krae vrijeme dolaska do prototipa, jer se time izrada samog prototipa pojednostavljuje (odbacivi prototip se dobija primjenom generatora koda, a koristi BP ija shema ne mora biti blizu konanog rjeenja); 6. Radei sa prototipom aplikacije, korisnik treba da upotrebljava iskljuivo test podatke. On mora biti prethodno pripremljen na injenicu da, ukoliko u meuvremenu doe do prestrukturiranja sheme BP, uneseni test podaci mogu biti izgubljeni. Do gubitka test podataka moe doi u situaciji kada je za njihovo prestrukturiranje potrebno uloiti veliki napor, pa se od predstrukturiranja svjesno odustaje, ili kada je takvo prestrukturiranje nemogue izvriti zbog izmjena u shemi BP; 7. Prototip aplikacije moe da predstavlja rjeenje koje je dobijeno pomou generatora koda nekog CASE proizvoda, prvenstveno na osnovu specifikacija konceptualnog nivoa. To znai da se detalji, koji se definiu tek u implementacionom projektu, a nisu podrani odgovarajuim generatorom, ne realizuju u okviru prototipa aplikacije kako slijedea generisanja ne bi unitila tako isprogramirane cjeline. Na taj nain se postie kratko vrijeme izrade prototipskog rjeenja, ali ne i njegova potpuna funkcionalnost; 8. Ako je mogue, u prototip aplikacije treba ukljuiti i odgovarajue izvjetaje, jer tada korisnik lake sagledava upotrebljivost aplikacije; 9. Rjeenja IS, istih ili slinih poslovnih sistema, mogu biti dobra osnova u primjeni prototipskog razvoja. Potekoe koje se mogu izbjei primjenom prethodno opisanih preporuka, a koje se mogu javiti prilikom primjene prototipskog razvoja, su slijedee. Iterativni pristup moe dovesti do zamora krajnjih korisnika i projektanata. U cilju izbjegavanja problema, posebno treba obratiti panju na preporuke 3 i 4. Upotreba generatora koda je mogua tek kada je formiran odgovarajui dio sheme BP, a sa druge strane treba koristiti prototip aplikacije upravo da bi se pribavile sve relevantne informacije za strukturiranje sheme BP, to znai da su ova dva zahtjeva meu sobom u suprotnosti. Primjena preporuka 5, 7 i 9 vodi ublaavanju ovog konflikta. Ako se radi o neodbacivim prototipovima (neodbacivi prototipovi se evolutivnim podeavanjem pretvaraju u konana rjeenja aplikacija), dorada izgenerisanih aplikacija moe biti zamoran i vremenski zahtjevan posao. U cilju pribliavanja korisnikog interfejsa i funkcionalnosti generisane aplikacije konanom rjeenju, odnosno olakavanja postupka dorade izgenerisanih aplikacija, vano je preduzeti mjere predviene
45
preporukom 1. Usaglaavanje podataka, unesenih putem neodbacivog prototipa sa bitno prestrukturiranom shemom BP, je esto vremenski zahtjevan i neizvjestan posao. U cilju izbjegavanja problema, posebno treba obratiti panju na preporuke 5 i 6. Intervencije na prototipu kod korisnika mogu stvoriti lani utisak da je projektovanje IS trivijalan posao. Da bi se problem izbjegao, posebno treba obratiti panju na preporuku 3. Primjena preporuke 9, ako za nju postoje uslovi, moe biti u funkciji ublaavanja ovog problema. Ako je rije o manje iskusnim korisnicima ili projektantima, moe se dogoditi da primjena prototipskog pristupa ne ostvari jadan od osnovnih ciljeva, odnosno pravovremeno identifikovanje informacionih zahtjeva, a da pri tome projektant ne uoi takav propust na vrijeme. Primjena preporuka 8 i 9 moe pozitivno uticati na ublaavanje ili izbjegavanje ovog problema. Primjena prototipskog pristupa IS je pokazala da on nije primjeren razvoju integrisanih IS, jer insistiranje na brzom uvoenju aplikacija u funkciju dovodi do parcijalizacije IS. Zbog toga je vano obratiti panju na preporuku 2. Aplikacije koje se razvijaju samo primjenom prototipskog pristupa mogu postati izolovana ostrva. Imajui u vidu tu injenicu, direktna primjena iskljuivo prototipskog pristupa je mogua u sluaju da treba razvijati skoro izolovane podsisteme sa niskim stepenom meusobne integracije. Sa druge strane, oekuje se da prototipski pristup doivi svoju punu afirmaciju ukoliko se primjenjuje u kombinaciji sa nekim od modela primjene metodologije ivotnog ciklusa. U tom smislu, posebno znaajnu ulogu ima evolutivni pristup razvoju IS.
46
nedovoljno precizno identifikovanih informacionih zahtjeva. Brzi prelazak u narednu fazu treba da obezbjedi bolju osnovu za kasniji uspjeni zavretak prethodne faze. Kako je jedan od bitnih motiva za nastanak evolutivnog pristupa problem nedovoljno precizno identifikovanih informacionih zahtjeva, smatra se da njegova praktina primjena ima smisla ukoliko se on kombinuje sa prototipskim pristupom, kao metodom za tano utvrivanje informacionih zahtjeva. Za utvrivanje informacionih zahtjeva se preteno primjenjuju odbacivi prototipovi. Primjenjuju se dvije varijante evolutivnog pristupa. Prema prvoj, nakon utvrivanja preciznih informacionih zahtjeva, rezultati konceptualnog i implementacionog projektovanja BP se integriu, a projekti podsistema se usaglaavaju sa shemom integrisane BP. Drugim rijeima, potprojekti se ponovo posmatraju kao cjelina i na njih se primjenjuju, neto izmjenjeni, koraci konceptualnog i implementacionog projektovanja, kao pri primjeni sekvencijalnog modela metodologije ivotnog ciklusa. Ova varijanta evolutivnog pristupa kombinuje mnoge dobre strane sekvencijalnog modela metodologije ivotnog ciklusa i prototipskog pristupa, ali ne rjeava probleme dugog vremenskog intervala od poetka projekta do pojave prvih, operativno primjenljivih rezultata kod korisnika, i potrebe ulaganja finansijskih sredstava odjednom, a ne postupno. Prema drugoj varijanti, potprojekti se realizuju meusobno nezavisno i mogu biti fazno pomjereni u vremenu. Na taj nain se rjeavaju problemi dugog vremenskog intervala od poetka projekta do pojave prvih rezultata i potrebe ulaganja odjednom finansijskih sredstava. Ovakav nezavisan rad, meutim, moe dovesti do nieg stepena integrisanosti IS. Analiza Oblikovanje Izrada Evaluacija
Analiza
Oblikovanje
Izrada
Evaluacija
Analiza
Oblikovanje
Izrada
Evaluacija
Analiza
Oblikovanje
Izrada
Evaluacija
47
Na slici 2.5 je prikazan mogui evolutivni model primjene metodologije ivotnog ciklusa. Razvoj se vri u inkrementalnim koracima, dovoljno malim da se mogu obavljati prototipski. Svaki od nizova razvojnih aktivnosti (analiza, oblikovanje, izrada, evaluacija) vodi operatibilnom proizvodu koji se isporuuje i koji generie naredne zahtjeve.
PRIMJENA
48
Spiralni model metodologije ivotnog ciklusa prikazan je na slici 2.7(a). Y osa predstavlja kumulativni troak, a na x osi svaka petlja spirale predstavlja jednu fazu razvoja i to: analizu, oblikovanje, izradu i integraciju. Faza moe biti realizovana redoslijedno, prototipski ili evolutivno, a odluka o nastavku razvoja donosi se prolaskom kroz osu x.
kumulativni troak integracija izrada oblikovanje analiza
Programiranje
Projektovanje
1. 2. 3. 4.
Analiza rizika, procjena alternativa; Razvoj i verifikacija slijedeeg proizvoda; Planiranje slijedee faze; Pregled odreivanje ciljeva, alternativa i ogranienja.
(a)
(b)
Slika 2.7. Spiralni (a) i zvjezdasti (b) model metodologije ivotnog ciklusa. Zvjezdasti model, slika 2.7(b), ne uvodi stroga ogranienja u redoslijedu primjene faza i koraka metodologije ivotnog ciklusa. To ne znai da prirodnog redoslijeda izvravanja odreenih koraka metodologije u ovom modelu nema, ve da on zavisi od vie faktora, impliciranih konkretnim projektom. Tako, na primjer, reverzno inenjerstvo, ili potreba za reinenjeringom postojeeg IS, mogu zahtjevati potpuno obrnuti redoslijed primjene faza ivotnog ciklusa (primjena "odozdo na gore").
49
Komponente metodologije se mogu razvrstati u slijedeih pet taaka: 1. 2. 3. 4. 5. Etape projekta; Zadaci za svaku pojedinu etapu; Izlazi (projektna dokumentacija); Preporuke (vodi) upotrebe odabranih tehnika i pomagala; Nain upravljanja projektom i nadzorom projekta.
Cilj metodologije je da omogui sistemski postupak razvoja kojim e se moi pratiti napredak, uspostavi komunikaciju izmeu uesnika ukljuenih u izgradnju IS (poslovodstvo, korisnici, analitiari, programeri), osigura skup tehnika koje e omoguiti da se zadaci izvravaju na standardne i provjerene naine, osigura efikasan nadzor sa ciljem uoavanja greaka u ranim fazama. Osim navedenog, cilj metodologije je da omogui elastine promjene poslovanja i tehnologije (npr. odvajanjem analize i oblikovanja), uokviri razvojnu strategiju kojom e se ukloniti ad hoc rjeavanje problema, odredi ili ukae kada i u kojoj mjeri je potrebno ukljuivanje korisnika, te potie i omoguava ukljuivanje korisnika kada se za to ukae potreba. Metodologija omoguava da se dovoljno panje posveti analizi poslovanja, ime e se osigurati izrada sistema koji odgovara poslovanju i zahtjevima korisnika. Jeftinije je otkriti i popraviti greku u ranim fazama, jer je lake popraviti dokumentaciju nego mijenjati programski kd. Izmjene u kasnijim fazama zahtjevaju promjene rezultata prethodnih faza. Lake je pronai greku tokom faze u kojoj je nastala, nego traiti je i popravljati na osnovu posljedinih uinaka primijeenih u kasnijim fazama.
Slika 2.8. Relativno trajanje i cijena otkrivanja greaka u razliitim fazama. Relativno trajanje i cijena otkrivanja greaka u razliitim fazama razvoja IS prikazani su na slici 2.8.
50
51
Primjena neke od ovih metodologija ne znai da e IS biti dobar! Zahtjevi korisnika se mogu mijenjati u vremenu. Preporuene aktivnosti ne moraju uvijek biti prikladne, primjenjive ili potrebne. Insistiranje na provoenju propisanih procedura vodi u zanemarivanje stvarnih problema, to za posljedicu moe imati formalno dobro napravljen, ali neuspjean sistem. Veina metodologija je namijenjena analizi i oblikovanju. Rijetke metodologije podravaju sve faze ivotnog ciklusa (npr. IEM). Metodologije treba da su podrane odgovarajuim alatima za upravljanje i projektovanje (CASE), to nije uvijek ispunjeno u praksi. Alternative komercijalnim metodologijama je zdrav razum, najbolje dokazano u praksi, preice do rjeenja problema zasnovane na slinim iskustvima, kao i prilagoavanje razvojnog procesa.
52
3. JAD (Joint Application Design) zdrueno oblikovanje aplikacija. Nastoji se oblikovati sistem tako da potpuno odgovara zahtjevima. Zahtijeva tijesnu saradnju korisnika, projektanta i menadera; 4. Konstrukcija - iterativna izrada prototipa; 5. Zavretak projekta - provjera rada, izrada dokumentacije, obuka korisnika. Primjer: RAD projekat. Sedmice 1-4 pokretanje projekta, istraivanje, priprema JRP sjednice, obavljanje JRP sjednice, priprema JAD sjednice; Sedmice 5-9 prva JAD sjednica, poetak dizajna, konsolidacija JAD dizajna i prototipa, prototipovi za test uporabljivosti, druga JAD sjednica, zavretak dizajna; Sedmice 10-14 razvoj i testiranje, priprema konverzije, planiranje zavretka; Sedmice 15-20 izrada dokumentacije, priprema obuke, obuka, zavrno testiranje, zavretak projekta.
53
sveobuhvatnog plana i arhitekture za redoslijedni razvoj informacionih (pod)sistema. Vri se izdvajanje poslovnih podruja i odreivanje prioriteta. Pod poslovnim podrujem se podrazumjeva skup poslovnih procesa koji se proteu organizacijom, a moraju biti visoko integrisani da bi se ostvarila strategija ili misija; 2. Analiza poslovnih podruja - Business Area Analysis (BAA); 3. Prouavanje poslovnih podruja i definisanje poslovnih zahtjeva za visoko organizirani i integrisani skup informacionih (pod)sistema i aplikacija podrke poslovnog podruja; 4. Definisanje aplikacija, odnosno izdvajanje aplikacija i definisanje njihovih prioriteta na osnovu analize poslovnih podruja. Aplikacije postaju projekti u kojima se primjenjuju drugi postupci analize i dizajna. Budui da je informacija proizala iz podataka, podaci moraju biti prvi planirani. Modeliranje zapoinje modelima podataka. Nakon toga se rade modeli procesa, slino onima u strukturiranoj analizi. Napomena: O informacionom inenjerstvu bie jo govora u poglavlju 8.
54
XP uvaava mogunost promjene specifikacija koje definiu funkcionalnost sistema. Prihvati promjenu! je jedan od osnovnih XP postulata. Igra planiranja definie funkcionalnosti slijedee verzije, prije nego to njen razvoj stvarno i pone. U poetku se kreira grubi plan koji se redefinie kroz razgovore sa naruiocima i korisnicima. Korisnici se izraavaju "priama", tako da svaka pria definie jedan dio funkcionalnosti sistema. Priama se dodjeljuju prioriteti i ciljano vrijeme implementacije (1 do 3 sedmice po zahtjevu). XP preporuuje relativno esto izdavanje novih verzija sistema, obino u prvom trenutku u kojem to ima poslovnog smisla, tj. kada sistem zadovoljava funkcionalnost traenu od strane naruioca. esto izdavanje novih verzija pojaava komunikaciju, a time i dotok povratnih informacija i igru planiranja. Metafora sistema je analogna onome to veina drugih metodologija naziva arhitekturom sistema. Metafora mora biti jasno izraena te nedvosmisleno shvatljiva svim lanovima projektantskog tima. XP ne definie format ili tehniku u kojoj metafora mora biti izraena. Najei argument osporavaoca XP-a je u tvrdnji da XP zanemaruje dizajn sistema. U stvati, dizajn arhitekture sistema je kontinuirani proces koji se u malim koracima odvija tokom itavog razvoja. Testiranje se sastoji od testova komponenti i testova prihvatljivosti. Prilagoavanje programskog kda (refactoring) je tehnika kojom se pojednostavljuje programski kod uklanjanjem ponavljanog koda i uklanjanjem (nepotrebnog) sloenog koda. Programeri rade u parovima, na nain da jedan pie kd, a drugi prati pisanje i revidira kd, pazei da kd bude jasan i razumljiv. Zajedniko vlasnitvo se sastoji u tome da svi inenjeri koji uestvuju u razvoju projekta imaju pravo mijenjati bilo koji njegov dio u bilo kojem trenutku. XP nalae izgradnju novih verzija nekoliko puta dnevno, tj. nakon svake implementirane funkcionalnosti. Zastupljeno je potovanje 40-satne radne sedmice. Smatra se da umorni projektanti ne mogu postii maksimalnu efikasnost u radu, pa se zabranjuje prekovremeni rad dvije sedmice zaredom. Naruilac ili predstavnik naruioca mora biti prisutan prilikom razvoja sistema kako bi bio dostupan u sluaju potrebe za pojanjenima, te kako bi pomogao u definisanju sistema i pisanju testova. Programeri moraju pisati kd u skladu sa dogovorenim standardima.
55
1. Softver se razvija i objavljuje po dijelovima; 2. Glavne faze razvoja se obavljaju kroz niz iteracija; 3. Faza konstrukcije (izrade) slijedi nakon provoenja prethodnih faza. Svaka iteracija se obavlja standardnim ivotnim ciklusom koji ukljuuje analizu, oblikovanje, ugradnju i provjeru. Rezultat iteracije je proizvod zavrnog kvaliteta, provjeren i integrisan, koji zadovoljava podskup ukupnih zahtjeva. Isporuke mogu biti interne ili prema korisnicima. Mogu se izdvojiti slijedee glavne faze razvoja (slika 2.9). Poetak (Inception), koga sainjavaju opravdanje razloga za pokretanje projekta, prikupljanje najvanijih zahtjeva (10% detaljno) i odreivanje dosega projekta.
Elaboracija
Gradnja
Prelaz
Oblikovanje Ugradnja
Provjera
iter. #1
iter. #2
Inkrementi
iter. #n-1
iter. #n
Slika 2.9. Dijagram glavnih faza razvoja. Elaboracija (Elaboration), odnosno prikupljanje detaljnih zahtjeva (80%), globalna analiza i dizajn, ustanovljavanje osnovne arhitekture i planiranje konstrukcije. Konstrukcija (Construction), gradnja, se sastoji od prikupljanja ostalih zahtjeva plus promjene zahtjeva, razrade arhitekture i izrade sistema, kao i kontinuirane integracije. Prelaz (Transition) sainjavaju beta testiranje, podeavanje performansi, obuka korisnika, provjera prihvatljivosti i zadovoljstva korisnika.
56
je
nastavak
evolutivnog
razvoja,
Broj i trajanje iteracija za ujedinjeni razvojni proces, za projekte do 18 mjeseci, je okvirno 3 do 6 iteracija. Uobiajeno, iteracije imaju podjednako trajanje. Trajanje iteracije moe varirati u zavisnosti od faze. U fazi konstrukcije to vrijeme je due. Prva iteracija je najee i najtea. Zahtijeva pripremu okruenja, ekipe i posla. Opasna je zbog mogueg pretjeranog optimizma. Ako se krivo procjeni moe izazvati pomake i neeljene uinke. Smanjenje broja iteracija za posljedicu ima slabije rezultate razvoja.
57
Korisniki/poslovni zahtjev
Budui organizacijski IS
58
drugim poslovnim sistemima ili razvoj zapoeti sa izradom logikog modela. Tehnika oblikovanja dijagramima odvija se na slijedei nain. Izradom modela nastoji se opisati situacija u kojoj dogaaj iz vanjskog svijeta pokree (okida) process. Proces ima odreeni uinak na podatke u nekom stanju. Obavljanjem procesa podaci prelaze u novo stanje (slika 3.2).
Dogaaj Staro stanje podataka
uinak
Struktura podataka
59
60
61
upotpunile dobijene informacije ili uskladili proturjeni iskazi. Ukupan broj razgovora ne moe se unaprijed tano odrediti i treba ga prilagoditi stvarnoj situaciji.
62
Autorizacija (ovjera) zapisnika se vri tako da se zapisnik dostavlja na uvid sagovorniku, koji potvruje vjerodostojnost zapisnika. Po potrebi sagovornik moe nadopuniti dijelove za koje smatra da nisu evidentirani ili pojasniti dijelove za koje misli da su pogreno protumaeni.
63
Na osnovu navedenog, moe se zakljuiti da Pomou intervjua se moe vie nauiti o stavovima, Tokom intervjua analitiar i ispitanik se nalaze jedan moe posmatrati nain na koji ispitanik odgovara i pitanja.
je intervjuisanje najelastinije! osjeajima i motivaciji osoblja. nasuprot drugom, pa analitiar po potrebi proiriti ili usmjeriti
64
Nedostaci modela podataka mogu biti razliiti. Najei nedostaci su razliitost modela podataka postojeih aplikacija i nedostaci unutar pojedinih modela. Razliitost modela podataka postojeih aplikacija se oituje u tome da entiteti iz stvarnog svijeta nisu jednako zastupljeni u postojeim modelima, isti entitet iz stvarnog svijeta pojavljuje se pod razliitim nazivima, isti entitet iz stvarnog svijeta opisan je razliitim atributima, dva ili vie entiteta iz stvarnog svijeta su prikazani razliitim brojem entiteta u modelu podataka. Nedostaci unutar pojedinih modela su, najee, nedefinisanost identifikatora (primarnih kljueva), nedefinisanost veza meu podacima, najee kao posljedica nepostojanja primarnih kljueva, nedefinisanost veza i pored postojanja primarnih i drugih (stranih) kljueva. Navedene pojave su posljedica razvoja tokom upotrebe i nedoslijednosti tog razvoja, naglaenog ponavljanje uvedenog prilikom izrade zahtjevnih ili sloenih programskih rjeenja, kao i ukupne nenormalizovanosti modela.
65
koristan tamo gdje postoje korisnici koji dobro poznaju sistem, ali teko prihvataju nove ideje.
Slika 3.3. Prostor za radne sjednice [A.Dennis & B. Haley Wixom, Systems Analysis and Design, John Wiley & Sons, 2000]. Prednosti radnih sjednica su njihova pogodnost za projekte kojima se rjeavaju problemi vani za cijeli poslovni sistem ili vei dio poslovanja. Njihovim organizovanjem se izbjegavaju specifini (egzotini) i nejasni zahtjevi, preciznije se ustanovljava doseg projekta i bolje uoava protivrjenost zahtjeva. Nedostaci radnih sjednica su pasivnost uesnika, usitnjavanje razgovora i esto udaljavanje od tema. Sjednice treba da traju vie dana (5 do 10) u nekoliko sedmica. Ovom zahtjevu u praksi je vrlo teko udovoljiti zbog obaveza uesnika. Otpor sjednici je srazmjeran nivou poloaja konkretnog uesnika. Otpor je naroito naglaen kada poslovni sistem zapoljava informatiare, jer se podrazumijeva da je informatizacija iskljuivo njihov posao.
66
teka vizuelizacija budueg sistema. Da bi se olakala vizuelizacija budueg sistema izgrauje se sistem koji zadovoljava neke osnovne, inicijalne potrebe. U radu sa takvim sistemom korisnik otkriva svoje informacione potrebe, te se sistem modifikuje kako bi se zadovoljile te potrebe. Postupak koritenje sistema i modifikovanje istog iterativno se ponavlja, a informacione potrebe korisnika otkrivaju koritenjem sistema. Izrada prototipa pogodna je u onim okruenjima gdje je teko definisati konkretni model sistema, te u okruenjima gdje se informacione potrebe korisnika mjenjaju ili razvijaju (prototipski model razvoja IS je obraen u podtaki 2.4.3).
67
4. Analiza sistema
4.1. Uvod u analizu sistema
Analiza sistema (sistemska analiza) je ralanjivanje sistema na njegove komponente da bi se prouilo kako te komponente rade i meusobno komuniciraju. Analiza sistema se provodi sa namjerom slijedee sinteze sistema i razvoja aplikacija. Sinteza sistema je ponovno objedinjavanje komponenti u cjeloviti, poeljno poboljani, sistem. Bie navedene mogue definicije analize sistema. Analiza sistema je: (1) razmatranje i planiranje sistema i projekta, (2) prouavanje i analiza postojeeg poslovnog i informacionog sistema, te (3) definisanje poslovnih zahtjeva i prioriteta novog ili poboljanog postojeeg sistema [Whitten et. al, 2000]. Svrha, cilj i dubina analize sistema mogu se predstaviti slijedeim aktivnostima: Automatizacijom poslovnih procesa (Business Process Automation (BPA)), odnosno poveanjem efikasnosti korisnika analizom problema i uklanjanjem uzroka; Poboljanjem poslovnih procesa (Business Process Improvement (BPI)), tj. poveanjem efikasnosti i djelotvornosti, analizom trajanja i kotanja poslovnih procesa, te predlaganjem poboljanja (udruivanje procesa, paralelizam izvedbe); Reinenjeringom poslovnih procesa (Business Process Reengineering (BPR)) ili preoblikovanjem poslovnih procesa (Business Process Redesign (BPR)), ta predstavlja radikalni redizajn poslovnih procesa analizom moguih posljedica, procjenom alternativnih tehnologija, ukidanjem ili zamjenom pojedinih aktivnosti, analizom trokova - koristi i analizom rizika.
68
1. Detaljna analiza postojeeg sistema, te utvrivanje potreba i zahtjeva: Kako radi postojei sistem?, Na koji nain korisnici koriste sistem da bi obavili svoj posao?, Koji su problemi pri koritenju aplikacija? 2. Detaljna specifikacija zahtjeva za IS: Koji su podaci potrebni?, Ko ih treba?, Kada?, Od koga?, Ko ih stvara?, Koji su izlazni podaci?, Kakav im je oblik?, Koji su izvori izlaznih podataka?, Na koji nain se podaci prikupljaju i objedinjuju? 3. Daljnja razrada granica projekta. Primjeri: ProtokDokumenata, RazmjenaPodataka. Pozadinska analiza treba da pomogne razumjevanju strukture organizacije, ko u njoj radi, ko je kome potinjen, kako sarauju razliiti odjeli, itd. Za potrebe pozadinske analize moe se izraditi shema organizacione strukture iz koje e biti vidljivo koja osoba ili grupa ljudi obavlja koji dio posla (modeliranje funkcija). Za ostale elemente, takoe, se rade odgovarajui modeli (modeliranje procesa, modeliranje podataka).
69
70
Za 40 do 60% greaka u projektu uzrok lei u grekama napravljenim u fazi postavljanja zahtjeva. Tipina posljedica su "prazna oekivanja", razlika izmeu onog to oekuje naruilac i onoga ta je izvrilac mislio da treba napraviti. Naknadne prepravke mogu predstavljati do 40% trokova razvoja, od ega je 70 do 85% pripisivo pogrenim zahtjevima. Nepotpuno definisani zahtjevi ine nemoguim planiranje projekta i praenje promjena [Leffingwell, 1997].
71
U idealnom sluaju zahtjevi vlasnika podudaraju se sa poslovnim ciljevima! Primjer 2: Zahtjevi krajnjih korisnika. Prehrana kod bilo kojeg izvrioca usluga: Novi sistem mora omoguiti da student ostvaruje svoje pravo kod bilo kojeg izvrioca usluge subvencionirane prehrane. Dosadanja praksa je bila da svaki izvrilac usluga izdaje svoje bonove koji se mogu koristiti samo u odreenim restoranima. Ukinuti plaanje unaprijed: Treba izbjei bilo kakvo plaanje od strane studenata za potrebe ostvarivanja prava, a naroito unaprijed. Ukloniti nepotrebne postupke za ostvarivanje prava: Sistem mora biti tako koncipiran da kad se studentu jednom zavedu prava na matinoj ustanovi nisu potrebna nikakva daljnja dokazivanja za ostvarivanje prava kod izvrioca usluga. Smanjiti rizik gubitka ostvarenih prava: Sistem mora onemoguiti zloupotrebu steenih prava. Lake ostvarivanje ostalih prava iz studentskog standarda, npr. javni prijevoz po povlatenoj cijeni, pozorita, kina, smjetaj u studentskim domovima, student - servis, itd. Primjer 3: Nepotpuni zahtjev. Zahtjev "Softverski proizvod e ispisati statusnu poruku u redovnim intervalima, ne manjim od 60 sekundi" namee slijedea pitanja: ta je statusna poruka i pod kojim uslovima e biti ispisana?, Koliko dugo ostaje vidljiva?, Koji dio proizvoda e ispisati poruku?, Koliko doslijedni intervali moraju biti? Zahtjev definisan preciznije i detaljnije: Modul za nadzor e ispisivati statusnu poruku u za to odreeni dio interfejsa. Poruka e se aurirati svakih 60 s (10 s) nakon to zapone izvoenje pozadinskog zadatka i bie vidljiva cijelo vrijeme. Ukoliko se pozadinski zadatak izvodi normalno, modul za nadzor e ispisivati postotak obavljenog posla. Modul za nadzor e ispisati "Zadatak obavljen" nakon to se zadatak obavi. Modul e ispisati poruku o greci ukoliko doe do zastoja u izvoenju. Problem je rastavljen u vie zahtjeva budui da e svaki zahtijevati posebno testiranje. Ukoliko je vie zahtjeva grupisano u jedan lake je previdjeti neki od njih tokom izrade ili testiranja. Primjeuje se da u zahtjevu nije detaljno opisano kako i gdje e se poruka ispisivati. To e biti odlueno tokom dizajna. Primjer 4: Neostvariv zahtjev. Zahtjev "Softverski proizvod e se trenutno prebaciti izmeu ispisivanja i skrivanja oznaka koji se ne mogu tampati" je neostvariv zahtjev iz slijedeih razloga: Raunari nita ne mogu napraviti trenutno! Da li programska podrka sama odluuje kad e se prebaciti iz jednog stanja u drugo ili je to inicirano akcijom korisnika? Na koji dio teksta e se primijeniti promjena prikaza: da li samo oznaeni tekst, cijeli dokument ili neto
72
tree?. Uoava se i nejednoznanost: da li su "oznake koje se ne mogu tampati" skrivene oznake, posebne oznake ili kontrolne oznake? Bolji zahtjev glasi: "Korisnik e posebno dogovorenom akcijom, odabrati da li e se HTML (Hyper Text Markup Language) oznake u trenutno otvorenom dokumentu prikazivati ili ne". Sad je jasno da je rije o HTML oznakama, te da korisnik mora moi da obavi nekakvu akciju, ali nije tono navedeno kakvu (npr. kombinacija tipki), ta se preputa dizajnerima. Primjer 5: Neodreeni zahtjev. U zahtjevu "Parser e brzo generisati izvjetaj o grekama HTML oznaka, koji omoguava brzu ispravku greaka kada program koriste poetnici u HTML-u" uoavaju se slijedee neodreenosti: rije "brzo" je neodreena, nije definisano ta predstavlja izvjetaj i to ini zahtjev nekompletnim. Postavljaju se i slijedea pitanja: Kako se ovjerava zahtjev?, Kako pronai nekoga ko se smatra poetnikom u HTML-u i zatim vidjeti kako brzo e, uz pomo izvjetaja, ispraviti greke?, Kada se generie izvjetaj? Bolje rjeenje glasi: Nakon to je HTML analizator obradio datoteku, generisae izvjetaj koji sadri broj linije i tekst pronaenih HTML greaka, te opis svake greke. Ukoliko nema greaka prilikom analize, nee se generisati izvjetaj.
73
odreene funkcije. Predloeni funkcionalni zahtjevi ponekad predstavljaju zastarjele ili neefikasne poslovne procese koji ne trebaju biti ukljueni u novi sistem. Atributi kvaliteta: Izjave koje opisuju kako dobro sistem obavlja funkciju su atributi kvaliteta, tj. jedna vrsta nefunkcionalnih zahtjeva. Zahtjeve koji opisuju poeljne karakteristike sistema: brzinu, jednostavnost, intuitivnost, robustnost, pouzdanost, sigurnost i efikasnost treba razmotriti sa korisnicima, da bi se precizno utvrdilo ta oni misle pod tim dvosmislenim i subjektivnim terminima. Zahtjevi vanjskih interfejsa: Ova klasa zahtjeva opisuje veze izmeu sistema i vanjskog svijeta. Specifikacija sistemskih zahtjeva treba da ukljuuje odlomke za ove zahtjeve, ukljuujui i interfejse, te mehanizme komunikacije za korisnike, hardver i druge softverske sisteme. Ogranienja su uslovi koji ograniavanju izbor rjeenja raspoloivih dizajneru ili programeru. Spadaju u nefunkcionalne zahtjeve i trebaju biti dokumentovani. Neopravdana ogranienja treba pokuati odbaciti jer onemoguavaju postizanje najboljeg rjeenja. Takoe, mogu umanjiti primjenu komercijalnog softvera i komponenti u rjeenju. Neka ogranienja mogu pomoi u zadovoljavaju atributa kvaliteta. Primjer je poboljanje prenosivosti programa koritenjem samo standardnih naredbi nekog programskog jezika. Definicija podataka je bilo koji opis formata, dozvoljenih vrijednosti, pretpostavljenih vrijednosti ili kompozicija sloenih struktura podataka. Sve definicije treba pohraniti u Rjenik podataka, kao glavni orjentir za uesnike na projektu. Ideje o rjeenju: Ako korisnik opisuje specifian nain interakcije sa sistemom, kojom bi mogao obaviti neku akciju, npr. Korisnik odabira podatak koji eli iz padajue liste, on predlae rjeenje, a ne zahtjev. Predloeno rjeenje moe odvui panju od pravih zahtjeva. Kod postavljanja zahtjeva treba se usmjeriti na ono to je potrebno obaviti, a ne na nain realizacije. Treba istraiti zato korisnik predlae odreenu ugradnju, jer to moe pomoi u razumijevanju stvarne potrebe i korisnikovih oekivanja o nainu kako sistem treba da raditi.
74
Poeljno svojstvo sistema su funkcije koje korisnik eli na kraju da ima. Ranije verzije sistema mogu pruiti (ne potpunu) funkcionalnost bez tih zahtjeva. Poeljni zahtjevi mogu i trebaju biti rangirani. Neobvezna svojstva sistema su proizvoljni zahtjevi, svojstva i mogunosti bez kojih se moe, iako bi lijepo bilo ih imati. To nisu pravi zahtjevi. Ovi zahtjevi, takoe, mogu biti rangirani.
75
prioriteti, model organizacione strukture (strukturirani dijagrami), opis toka dokumenata (dijagrami toka), model procesa (dijagrami toka podataka), kao i konceptualni model podataka (dijagrami entiteti - veze).
76
Na osnovu izjava korisnika i prikupljene dokumentacije modeliraju se pojedine komponente sistema (procesi, podaci, dogaaji). Mogu se definisati preslikavanja uoenih imenica i glagola u konkretne komponente analitikog modela. Mogua preslikavanja su opisana u tabeli 4.2. Tabela 4.2.
Tip rijei Imenica Primjer - Ljudi, organizacije, softverski sistemi, jedinice podataka ili postojei objekti Komponente analitikog modela - Skladita podataka (DFD modeliranje toka podataka) - Entiteti ili njihovi atributi (ERD dijagram entiteti - veze) - Klase ili njihovi atributi (dijagram klasa) - Procesi (DFD) - Odnosi (ERD) - Prelazi (iz stanja u stanje) (STD dijagram prelaza stanja) - Metode klasa (dijagram klasa)
Glagol
- Akcije, ono to korisnik moe poduzeti ili dogaaji koji se mogu dogoditi
77
78
Proces se obavlja uvijek na isti nain (za odreeni ulaz se dobija isti izlaz). Trajanje procesa je konano i odredivo (poznati: poetak, zavretak i ponavljanje). Za obavljanje procesa se koriste sredstva (npr. ljudska, materijalna, finansijska). Poslovna pravila su instrukcije i logika koji odreuju proceduru obavljanja procesa. Ugrauju se u raunarski program (npr. preduslovi izlaska na ispit, broj polaganja ispita, uslovi upisa). Poslovna politika je skup poslovnih pravila. U veini poslovnih sistema predstavlja osnovu za donoenje odluka.
Slika 5.1. Iterativno razlaganje hijerarhija funkcija do nivoa procesa. Dijagram funkcionalne dekompozicije (Functional Decomposition Diagram (FDD)) koristi istu notaciju za razlaganje bilo koje hijerarhijske strukture, pa se esto zove samo Dijagram dekompozicije ili Mapa hijerarhije.
79
Elementi dijagrama dekompozicije su: funkcije, procesi, spojnice i vanjski spojevi. Funkcije se oznaavaju se (glagolskom) imenicom (npr. Prodaja, Proizvodnja), procesi glagolskim izrazom oblika infinitiv+objekat (ofarbati dio, osuiti dio), spojnice su spojevi izmeu funkcija i procesa, a vanjski spojevi su spojevi sa dijelovima dijagrama na drugim stranicama (slika 5.2). Primjer dijagrama dekompozicije za jedan sistem /podsistem prikazan je na slici 5.3.
Funkcija
Proces
Nabava
Knjigovodstvo
Prodaja
Evidentiranje dobavljaa
Naruivanje robe
Knjienje
robe
Evidentiranje kupca
Fakturisanje robe
Prodaja robe
Izrada narudbi
Zaprimanje robe
Izrada otpremnice
Otprema robe
Dodavanje
Auriranje
Brisanje
80
Izrada globalnog modela funkcija moe zapoeti izradom hijerarhijske liste funkcija po pojedinim organizacionim cjelinama. Primjer: NABAVA Evidentiranje dobavljaa Nabavka robe - Izrada narudbi - Zaprimanje robe UPRAVLJANJE OSOBLJEM Evidentiranje slube - Prijem u slubu - Praenje slube redovni rad prekovremeni rad bolovanje godinji odmori - Otputanje iz slube Obraun plata
Izrada dijagrama dekompozicije odvija se po slijedeem postupku. Polazi se od korijena dijagrama, kome se dodjeljuje ime sistema. Slijedi razrada u podsisteme i poslovne funkcije. Daljnja razrada je do nivoa operacionalizacije. Pri izradi dijagrama dekompozicije potrebno je pridravati se slijedeih pravila: svaki proces je roditelj ili dijete, roditelj mora imati barem dvoje djece, dok po veini standarda, dijete smije imati samo jednog roditelja. Preporuke: Izostaviti procese koji samo premjetaju ili preusmjeravaju podatke, a pri tome ih ostavljaju nedirnute. Panju usmjeriti na procese koji: neto raunaju (npr. prosjek ocjena), donose ili potpomau odluke (npr. odreivanje raspoloivosti robe pri naruivanju), filtriraju ili sumiraju podatke (npr. rauni kojima je istekao rok plaanja), organizuju podatke u korisne informacije (npr. generisanje izvjetaja), pokreu druge procese (npr. mijenjaju modalitet rada ureaja) ili rukuju podacima (npr. stvaranje, itanje, auriranje, brisanje i slino). Pomou hijerarhijskih dijagrama se moe prikazati funkcionalna dekompozicija realnog sistema. Takav jedan dijagram, dobijen pomou alata Function Hierarchy Diagramer (Designer 2000, ORACLE), je prikazan na slici 5.4. Svaka funkcija, koja se kreira putem navedenog alata istovremeno predstavlja i proces u buduim dijagramima toka podataka. Zato pojam procesa i funkcije, ili poslovne funkcije, predstavljaju sinonime u terminologiji mnogih CASE alata.
81
Slika 5.4. Primjer dijagrama dekompozicije funkcija (procesa). Pored osnovnih podataka za funkcije, za svaku funkciju se odreuje da li je rije o elementarnoj funkciji ili ne. Za funkciju se kae da je elementarna ukoliko njeno zapoinjanje podrazumjeva da e se ona u cjelosti izvriti, ili e efekti njenog izvravanja u cjelosti biti poniteni. Elementarne funkcije se, u principu, ne moraju dalje dekomponovati i tada one predstavljaju listove u hijerarhijskoj strukturi funkcija. U cilju preciznijeg specificiranja, postoji mogunost da se elementarna funkcija dalje dekomponuje na atomine funkcije, koje u tom sluaju predstavljaju listove u hijerarhijskoj strukturi funkcija.
82
Biblioteka
Raunarska tehnika
Informacioni sistemi
Slika 5.6.Ekranska forma CASE alata Repository Object Navigator (Designer 2000, ORACLE).
83
Prozor na lijevoj strani ekranske forme prikazuje hijerarhijski navigator objekata rjenika. Elementi organizacione strukture se definiu kreiranjem pojava tipa objekta pod nazivom Business Units, odnosno poslovne (organizacione) cjeline. Navoenjem oznake neposredno nadreene organizacione cjeline, prilikom unoenja nove organizacione cjeline, uspostavlja se hijerarhijska struktura organizacionih cjelina (desna strana ekranske forme).
Ulaz
Poslovna funkcija
Izlaz
Mehanizam
84
Uzajamno dejstvo izmeu funkcija u IDEF0 se predstavlja u obliku duge, koja odraava tok podataka ili materijala, koji sa izlaza jedne funkcije dolaze na ulaz druge. U zavisnosti od toga sa koje strane bloka se nalazi, tok dobija naziv ulazni, izlazni ili upravljaki. Drugim rjeima, poslovne funkcije se mogu prikazati ICOM konceptom (slika 5.7), koji se sastoji od: ulaz (I = Input): neto to se troi u procesu (nije obavezan), upravljanje (C = Control): ogranienje na izvravanje procesa (obavezno), izlaz (O = Output): rezultat procesa (obavezan), mehanizam (M = Mechanism): koristi se u procesu, ali se ne troi (nije obavezan).
Principi modeliranja u IDEF0. U IDEF0 su realizovana tri osnovna principa modeliranja procesa: princip funkcionalne dekompozicije, princip ogranienja sloenosti i princip konteksta. Princip funkcionalne dekompozicije se sastoji u predstavljanju sloene poslovne funkcije skupom elementarnih funkcija, slika 5.8. Princip ogranienja sloenosti se sastoji u tome da broj blokova na dijagramu mora biti od 2 do 6. Princip konteksta se sastoji u tome da modeliranje poslovnog procesa poinje sa crtanjem kontekstnog dijagrama. Na kontekstnom dijagramu se prikazuje samo jedan blok, odnosno samo glavna poslovna funkcija sistema koji se modelira. Pri odreivanju glavne poslovne funkcije, neophodno je imati u vidu cilj modeliranja. Jedan poslovni sistem se moe opisati na razne naine, u zavisnosti od toga sa kog stanovita se posmatra.
85
Kontekstni dijagram ima jo jednu ulogu u funkcionalnom modeliranju. On odreuje granice modeliranja poslovnog sistema, odnosno odreuje uzajamnu vezu izmeu sistema koji se modelira i njegovog okruenja. Nakon upoznavanja s osnovnim pojmovima funkcionalnog modeliranja poslovnih procesa, neminovno se postavlja pitanje kako ovo modeliranje pomae poveanju efikasnosti i kvaliteta djelatnosti poslovnog sistema. Postojei modeli KAKO JE. Razmatrani poslovni sistem je obavezno dio nekog projekta izgradnje ili razvoja korporativnog IS. Izgraeni funkcionalni modeli KAKO JE omoguavaju jasno utvrivanje koji poslovni procesi se ostvaruju u poslovnom sistemu, koji se informacioni objekti koriste pri izvravanju poslovnih procesa i zasebnih operacija. Funkcionalni model KAKO JE je polazna taka za analizu zahtjeva poslovnog sistema, pojave problema i uskih grla u razradi projekta usavravanja poslovnih procesa. Poslovna pravila. Model parcijalnih procesa omoguava uoavanje i tano odreivanje poslovnih pravila, koja se koriste u radu poslovnog sistema.
Instrukcija Dokument za rukovodstvo
Sortirati dokumente
Neregistrovani dokumenti
Registrovati dokumente
Registrovani dokumenti
Prijemno
Slika 5.9. Grafiki prikaz dijela funkcionalnog modela toka dokumenata. Na slici 5.9 je predstavljen dio funkcionalnog modela toka dokumenata (eng. DocFlow, rus. kretanje dokumenata u organizaciji od trenutka nastajanja ili dobijanja do zavretka koritenja ili odailjanja). Pri izvravanju operacije sortirati dokumente koristi se poslovno pravilo: ne podleu registraciji kopirani
86
dokumenti, telegrami i pisma. Ovo pravilo je definisano u instrukciji o toku podataka. Funkcionalni model omoguava ne samo identifikaciju postojanja pravila, nego i na kom radnom mjestu poslovno pravilo se mora primjeniti. U okviru funkcionalnog modela poslovno pravilo ima slijedei oblik: ukoliko je u prijemno doao dokument namjenjen rukovodstvu, on podlijee sortiranju, a kao rezultat, na osnovu instrukcije, se odreuje da li dokument podlijee registraciji ili ne. Informacioni objekti. Funkcionalni model omoguava identifikaciju svih informacionih objekata, koje koristi poslovni sistem u svojoj djelatnosti. Za razliku od nekih informacionih modela (Data Flow Diagrams (DFD), IDEF1x), funkcionalni model IDEF0 odreuje kako se koriste informacioni objekti u okvirima poslovnih procesa. Izgraeni modeli KAKO E BITI. Razvoj i implementacija korporativnog IS dovodi do promjena uslova izvravanja pojedinih operacija, kao i strukture poslovnih procesa. To zahtjeva promjenu poslovnih pravila, promjena u poslovnom sistemu, modifikaciju vaeih instrukcija zaposlenih. Funkcionalni model KAKO E BITI omoguava ve u fazi projektovanja budueg IS predvianje tih promjena. Primjena funkcionalnog modela KAKO E BITI omoguava, ne samo skraenje roka implementacije IS, nego i smanjenje mogueg rizika uslijed neprilagoenosti korisnika informacionim tehnologijama. Raspodjela resursa. Funkcionalni model omoguava jasnu raspodjelu resursa izmeu operacija poslovnog procesa, ta doprinosi efikasnosti koritenja resursa. Taj zadatak je naroito aktuelan pri uvoenju novih poslovnih procesa u poslovnom sistemu. Daljnja razrada metodologije funkcionalnog modeliranja IDEF0 je razvoj slijedee dvije tehnike, i to: tehnike za dokumentovanje tehnolokih procesa (IDEF3) i tehnike za oblikovanje tokova podataka (DFD), koja prikazuje tok informacija.
87
Postoje dva tipa dijagrama u standardu IDEF3, koji predstavljaju opise jednog te istog scenarija tehnolokog procesa iz razliitih uglova posmatranja. Dijagrami prvog tipa su Dijagrami opisa redoslijeda faza procesa (Process Flow Description Diagrams (PFDD)), a drugi tip su Dijagrami stanja objekta i njegovi transformacioni procesi (Object State Transition Network (OSTN)). Primjer: Potrebno je opisati proces farbanja dijelova u proizvodnoj radionici. Pomou dijagrama PFDD dokumentuje se redoslijed i opis faza obrade dijela u okviru razmatranog tehnolokog procesa. Dijagrami OSTN se koriste za ilustraciju transformacija dijela, koje se javljaju u svakoj fazi obrade. Razmatrani proces se sastoji od farbanja i faze kontrole kvaliteta, koja odreuje da li je potrebno dio ponovo ofarbati (u sluaju odstupanja od standarda) ili ga poslati na dalju obradu.
OFARBATI PONOVO OFARBATI DIO OSUITI DIO TESTIRATI DIO POSLATI U SLIJEDEU RADIONICU
Slika 5.10. Primjer PFDD dijagrama. Na slici 5.10 je prikazan dijagram PFDD, koji predstavlja grafiku predstavu scenarija obrade dijela. Pravougaonici na dijagramu PFDD se zovu funkcionalni elementi ili elementi ponaanja (Unit of Behavior (UOB)) i oznaavaju aktivnosti, fazu procesa ili primljena rjeenja. Svaki UOB se imenuje glagolskim izrazima oblika infinitiv + objekat i jedinstvenim brojem. Dijagrami PFDD slue za vizuelni prikaz scenarija odvijanja procesa u realnom sistemu. Na dijagramima za veze izmeu funkcija se koriste slijedei grafiki simboli: - prethoenje (Precedence), prethodna aktivnost se mora zavriti da bi slijedea zapoela (crta se slijeva nadesno ili odozgo prema dole), - tok objekata (Object Flow), izlaz prethodne je ulaz u slijedeu aktivnost, - relacioni (Relational Link), povezivanje uz korisniki definisani uslov. Prelazi, veze (J - junction) su slijedee: & (logiko I) - svaka povezana aktivnost uvijek se obavlja/zavrava, X (ekskluzivno ILI) - obavlja se samo jedna od povezanih aktivnosti, O (ILI) - obavlja se jedna ili vie povezanih aktivnosti.
88
Ako je dijagram PFDD tehnoloki proces sa stanovita posmatraa, onda dijagram OSTN omoguava posmatranje istog procesa sa stanovita objekta, slika 5.11. Stanje objekta, dijela u razmatranom primjeru, i promjena tog stanja su kljuni pojmovi OSTN dijagrama. Stanje objekta je prikazano krugovima, a promjene stanja usmjerenim linijama. Svaka linija je povezana sa odgovarajuim funkcionalnim blokom UOB, a kao rezultat je prikazana promjena stanja objekta.
UOB/ Testirati sloj boje UOB/ Ofarbati dio
Rijetka boja
Slika 5.11. Primjer OSTN dijagrama. Na slici 5.12 je prikazana ekranska forma, sa izvodom iz jednog dijagrama, CASE alata Process Modeller (Designer 2000, ORACLE), koji je namjenjen za izradu dijagrama procesa. Process Modeller je zasnovan na slijedeim konceptima: organizaciona jedinica, proces (funkcija), depozit, tok, okida (triger) i ciljni rezultat. Organizacija dijagrama procesa prati funkcionalnu dekompoziciju IS. Za svaki proces u hijerarhiji dekompozicije se formira jedan dijagram. Prilikom otvaranja novog dijagrama bira se proces za koji se dijagram crta i taj proces se zove kontekstni proces. Procesi, koji se na samom dijagramu prikazuju, su prevashodno neposredno podreeni procesi kontekstnom procesu, ali to moe biti i bilo koji drugi proces iz funkcionalne dekompozicije. Procesi na dijagramu se, u terminologiji ovog alata, nazivaju koracima ili aktivnostima. CASE alat Process Modeller omoguava oblikovanje i prikaz organizacione strukture poslovnog sistema, pri emu se cjelokupna hijerarhija organizacionih jedinica, ili neki njen dio, prikazuje na krajnjem lijevom dijelu dijagrama. Svaka organizaciona jedinica, prikazana na dijagramu, ima svoju oblast nadlenosti u
89
pogledu izvoenja pojedinih aktivnosti. Oblast nadlenosti je na dijagramu prikazana u obliku horizontalne trake, koja se protee u visini odgovarajue organizacione jedinice. To znai da je za sve procese u danoj oblasti zaduena nadlena organizaciona jedinica. Matrica organizacione jedinice/procesi se definie pomou dijagrama procesa.
Slika 5.12. Dijagram procesa na ekranskoj formi CASE alata Process Modeller (Designer 2000, ORACLE).
90
Sinonimi za dijagram toka podataka su: transformacioni grafikon, mjehurasti grafikon, mjehurasti dijagram (Bubble Chart). Tehnika, koja se koristi za modeliranje toka podataka, se primjenjuje pri razvoju aplikacija, odakle je i potekla. Ne moe se koristiti za opis programske logike, opis promjene stanja, izradu upravljakih specifikacija ili dizajn korisnikog interfejsa.
D1
Spremite podataka
Tok podataka
a P1
Vanjski entitet
Tok materijala
Proces
91
Vanjski entitet (external entity, external agent) je objekat vanjskog svijeta povezan sa posmatranim sistemom. Odreuje granice posmatranog sistema. Vanjski entiteti predstavljaju izvorita i odredita podataka, to jest izvore i ponore podataka. Vanjski entiteti mogu biti osobe, orgazicione jedinice, ustanove, drugi sistemi. Za oznaavanje entiteta se koriste imenice, npr. Student, Kupac, Dobavlja.
Slika 5.14. Primjer dijagrama toka podataka oblikovan pomou alata Dataflow Diagramer (Designer 2000, ORACLE) .
92
Postupak se zaustavlja kada postane oigledna ugradnja (implementacija) procesa na najniem nivou. Preporuke za oznaavanje elemenata kojih se treba pridravati prilikom crtanja dijagrama su slijedee. Hijerarhijski nivoi nose brojane oznake. Nivo konteksta se oznaava 0. Nazivi spremita, izvora i odredita se oznaavaju velikim slovima, slovne oznake, ili slovo+broj. Procesi i tokovi podataka se oznaavaju malim slovima. Dijagram konteksta prikazuje sistem na najviem nivou hijerarhije prikaza. Definie okruenje sistema i podruje analize. Prikazuje jedan proces i vanjske entitete. Zapoinje se procesom koji prikazuje sistem u cjelini, a nakon toga odreuju vanjski entiteti i njihova povezanost sa sistemom (slika 5.15). Pregledni dijagram (initial diagram) omoguava uoavanje glavnih tokova informacija (npr. koriteni dokumenti, potrebni podaci), odreivanje glavnih aktivnosti sistema i njihovo prikazivanje odgovarajuim procesima. Osim navedenog, pregledni dijagram omoguava ukljuivanje vanjskih entiteta i tokova podataka sa dijagrama konteksta, utvrivanje sa korisnikom granica sistema, kao i utvrivanje procesa i spremita podataka (slika 5.16).
Zahtjev za identifikaciju
P0
Narudba
Osoba
Videoteka
Novi video
Dobavlja
Rezultat upita
Upit
lan
93
Rezervisati video
Slika 5.16. Odreivanje dometa dijagrama toka podataka: Videoteka [Fertalj & Kalpi, 2005]. U toku razrade procesa na poddijagramu, potrebno je za svaki proces sa preglednog dijagrama identifikovati podaktivnosti. Na primjer, za proces Upisati novog lana, podaktivnosti su: zatraiti line podatke, evidentirati novog lana i izraditi lansku kartu (slika 5.17). Ponavljati postupak za svaki od procesa na poddijagramu. Uspostaviti nivo detalja slijedei pravilo 72. Na kraju je potrebno provjeriti potpunost i ispravnost modela. Model obrazloiti korisniku, a zatim ga po potrebi aurirati. Dubinu i uravnoteenost modela teko je odrediti. U praksi to moe znaiti doradu dijagrama u veem broju ponavljanja, ak i kada dijagrame rade iskusni analitiari.
94
Identifikacija
P1.3
lan
lan
lanska karta
95
Trivijalni tokovi su izlazi iz procesa koji ne ulaze u spremita ili odredita. Obino imaju posebno znaenje, a mogu se koristiti za prikaz posebnih stanja kao to je dojava poruke sistema (npr. dojava greke). Neposredno povezani procesi su kada jedan od procesa eka na zavretak prethodnog. Procesi koji ne obavljaju pretvaranje podataka su kada je izlazni tok jednak ulaznom. U tom sluaju treba preimenovati jedan od tokova ili treba obaviti prespajanje tokova, ta je uinjeno sa tokom podataka b, slika 5.18. Procesi se mogu odvijati istovremeno.
96
a
Vanjski entitet
Ulazni tok
Proces
D1
Izlazni tok
Spremite podataka
Proces
Izlazni tok
Spremite podataka
Vanjski entitet
Ulazni tok
Proces
D1
Izlazni tok
Spremite podataka
Slika 5.19. Notacije koje se koriste kod izrade DTP. Proirenja modela je izvreno uvoenjem okidaa (trigera), koji prikazuju uestalost procesa (npr. tri puta dnevno), zatim posebnih simbola za prikaz ponavljanja procesa, razdvajanje i spajanje tokova (alternativni tokovi), kao i posebnih simbola za tok resursa, tok dokumenata ili tok upravljanja (npr. razliite linije ili ikone).
97
** @
Primjer: Opis podataka moe zapoeti opisom najmanje logike cjeline podataka, odnosno elementarnih podataka. Nakon toga se opisuju grupe sainjene od elementarnih podataka, ta definie strukturu podataka. Struktura podataka odreuje sadraj spremita podataka, kao i tokove podataka (slika 5.20).
Tok podataka
Spremite podataka
98
99
Tabela 5.3.
100
Proces Ulaz (od)
Tabela 5.4.
Izlaz (prema) Vanjski entitet Spremite Komentar/Algoritam
Dobavlja
... Osoba
Struktura tokova ne mora u potpunosti odgovarati strukturi spremita Provjeri zahtjev prema Pravilniku o zapoljavanju, pa napii rjeenje
101
6. Modeliranje podataka
6.1. Osnovni pojmovi modela podataka
6.1.1. Uvod u modeliranje
Modeliranje podataka je tehnika organizovanja i dokumentovanja podataka IS. Sinonim je modeliranje baze podataka, budui da se podaci najee pohranjuju u BP. Prema mnogim autorima modeliranje podataka je najvanija tehnika oblikovanja informacionog sistema. Podaci su resurs koji se dijeli izmeu veeg broja procesa i zbog toga moraju biti organizirani na nain koji je prilagodljiv poslovnim zahtjevima. Strukture podataka i njihova svojstva su trajniji i stabilniji od procesa. Modeliranje podataka se zavrava bre nego modeliranje procesa i modeli podataka se bre pribliavaju rezultatu nego modeli procesa. Pored toga, modeli podataka su bitno manji od modela procesa. Modeli podataka postojeeg i budueg sistema meusobno su sliniji nego modeli procesa postojeeg i budueg sistema, a i lake ih je preoblikovati, pa se manje posla baca. Omoguavaju dobru komunikaciju sa korisnicima i lake utvrivanje naziva.
102
6.1.3. Entiteti
Entitet (entity) je neto 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 moe zasebno identifikovati [Chen, 1976], (2) bilo koji objekat koji se moe razlikovati i predstaviti u bazi podataka [Date, 1986], (3) logika reprezentacija podatka [Finkelstein, 1989], (4) bilo ta o emu pohranjujemo informaciju [Martin, 1989]. Entitet moe biti: osoba, npr. Ivo Ban, objekat, npr. roman Zloin i kazna, apstraktni pojam, npr. engleski jezik ili iskustvo (poznavanje jezika), ustanova (ETF), poslovni sistem (Hotel Proljee ili Elektroprivreda), dogaaj (situacija, stanje) - proli, sadanji ili budui, npr. roenje, kolovanje, zaposlenje, penzionisanje, povezanost razliitih objekata stvarnog svijeta, npr. srodstvo.
Pojedinane pojave (instance), u zavisnosti o metodi, se grupiu u: skup entiteta (entity set), tip entiteta (entity type) i klasu entiteta (entity class). U praksi se moe poistovjetiti pojam entitet sa skupom entiteta, ako se ne razmatraju konkretni podaci. Oznaava se imenicom (u jednini), npr. Osoba, Fakultet. Entiteti mogu poprimiti razliite uloge u zavisnosti od konteksta, npr. Osoba je Kupac i/ili Dobavlja, Student ili Nastavnik.
103
Obzirom na uskladitenu vrijednosti, atributi mogu biti atributi za uskladitenje i izvedeni atributi, gdje im se vrijednost moe odrediti na osnovu vrijednosti drugih atributa: starost = (DananjiDatumDatumRoenja). Vrijednosti atributa definiu tip podatka (domen) i pretpostavljena ili standardna vrijednost (default). Tipovi podataka mogu biti netehniki (logiki) ili tehniki. Netehniki tipovi podataka su opti tipovi koji se koriste u sistem analizi i pri prikupljanju zahtjeva (npr. broj, datum-vrijeme, znakovni niz, tekst, BLOB (Binary Large OBject)), dok su tehniki tipovi podataka generiki tipovi podataka koji se mogu preslikati u konkretne tipove (npr. integer, character ili konkretni tipovi char, int, byte (iz sastava SUBP SQLserver)). Standardna vrijednost atributa je vrijednost koja se zapisuje kada je korisnik ne specificira. Uopteno reeno, veina atributa treba da ima standardnu vrijednost. Domeni su skup moguih vrijednosti koje, nad njima definisani atributi, mogu poprimiti. Domeni mogu biti jednostavni i sloeni, isto kao i atributi. Nad svakim domenom se moe definisati po volji mnogo atributa. Skup vrijednosti (domen) se moe definisati: tipom podatka (npr. integer), podskupom vrijednosti tipa podatka (npr. formula CC66, interval [10-99]) ili skupom konstanti (npr. Pol = {M, }). Ilustracija atributa i domena dana je na slici 6.2.
Prezime (Prezime)
Ime (Ime)
Adresa (Adresa)
104
6.1.5. Kljuevi
Klju (key) ili identifikator (Id, @) je atribut ili skup atributa koji (svojim vrijednostima) jednoznano identifikuju svaki od entiteta u nekom skupu entiteta. Mora se sastojati od bar jednog atributa (jednostavni klju): npr. OSOBA = @JMBG + Prezime + Ime; MJESTO = @ifraMjesta + NazivMjesta, a moe se sastojati od vie atributa (sloeni, sastavljeni, ulanani klju): npr. MJESTO = @ifraDrave +@ifraMjesta. Klju mora zadovoljavati uslove jednoznanosti i minimalnosti. Jednoznanost se definie na slijedei nain: u skupu entiteta ne smiju postojati dvije pojave sa istim vrijednostima svih kljunih atributa (npr. ne smiju postojati 2 osobe sa JMBG=2209964100028), dok minimalnost znai da ne postoji podskup atributa kljua koji je, takoe, jednoznaan (npr. lo primjer: OSOBA = @JMBG + @Prezime + ... , dobar primjer: KURS = @OznakaValute + @DatumKursa + ... ). Osim navedenih uslova, klju mora zadovoljiti i slijedee uslove: odreenost (postojanje vrijednosti u trenutku stvaranja instance), stabilnost (otpornost na promjene tokom vremena), raspoloivost (dostupnost svim korisnicima), neutralnost (obzirom na znaenje vrijednosti kljua).
Identifikator Osobe (IdOsobe) Prezime (Prezime) Ime (Ime) Adresa (Adresa) ifra mjesta (SifMjesta)
001 282
Slika 6.3. Povezivanje entiteta ili skupova entiteta stranim kljuem. Entitet moe imati jedan ili vie kljueva. Entitet mora imati barem jedan klju. Entitet moe imati vie moguih kljueva, tj. kandidata za primarni klju, koji ne moraju
105
biti meusobno disjunktivni, tj. mogu imati atribute presjeka. Jedan od kljueva se odabira za primarni klju (primary key): npr. Osoba.IdOsobe, Mjesto.SifMjesta. Nakon odabira primarnog kljua, ostali mogui kljuevi postaju alternativni kljuevi (alternate key (AK)): npr. Osoba.JMBG, Mjesto.PostBr. Strani klju (foreign key (FK)) je skup atributa koji se odnosi na klju drugog skupa entiteta, tj. skup atributa ije se vrijednosti odnose na vrijednosti kljua drugog entiteta (Osoba.SifMjesta odnosi se na Mjesto.SifMjesta). Strani klju ukazuje na povezanost izmeu entiteta, odnosno skupova entiteta (slika 6.3.). Moe poprimiti vrijednost primarnog kljua drugog entiteta ili nula-vrijednost (null value). Primjer: Osoba.SifMjesta odnosi se na Mjesto.SifMjesta, odnosno Entitet Osoba (IdOsobe=8746) ima SifMjesta=038, tj. referensira entitet Mjesto sa IdMjesta=038. Nula-vrijednost oznaava nepoznatu vrijednost atributa ili neodreenu vrijednost atributa, tj. nadomjeta vrijednost atributa koji se ne koristi. Nula-vrijednost nije 0 (nula) niti (prazan znakovni niz). Primjer: Mogue nula-vrijednosti: Osoba (IdOsobe=37528) boravi u nepoznatom mjestu, pa joj je SifMjesta neodreena (nepoznata) vrijednost; Vozilo (tipa putniki automobil) nepoznatog registarskog broja, nasuptot vozila (tipa buldoer) koje se ne registruje na isti nain (neprimjenljiva vrijednost).
6.1.6. Veze
Veza (relationship) pokazuje odnos izmeu entiteta. Analogno entitetima, pojedinana veza uspostavlja se na nivou instanci entiteta, a veze se grupiu u skupove veza (relationship sets). Kada se ne razmatraju instance, pojam veza podrazumijeva skup veza. Veza moe izraavati ulogu entiteta koje povezuje, a imenuje se glagolom ili glagolskom imenicom. Primjer: Veza i uloge: Osoba STANUJE u Mjestu (Osoba je STANOVNIK Mjesta), u Mjestu STANUJE Osoba (Mjesto je MJESTO STANOVANJA Osobe).
106
Mjesto MjestoStan
Stanuje Stanovnik
Osoba
Slika 6.4. Primjer veze i uloga. Stepen veze je broj entiteta koji sudjeluju u vezi. Uopteno, moe se povezati bilo koji broj entiteta (pri emu treba biti oprezan!). Tako veza drugog stepena je binarna veza, veza treeg stepena je ternarna veza, dok je, uopte, veza n-tog stepena: n-arna veza. Posebni sluaj je veza nekog entiteta sa tim istim entitetom. To je veza prvog stepena: unarna veza (refleksivna, rekurzivna, involucijska). U nekim metodama se smatra posebnim sluajem binarne veze, tj. posebnom vezom 2. stepena. Tip, klasifikacija veze (type of relationship) oznaava nain pridruivanja pojava entiteta u vezi: jedan-prema-jedan (1:1), jedan-prema-vie (1:N) - moe postojati vie (paralelnih) veza izmeu dva entiteta, vie-prema-vie (M:N). Kardinalnost veze (donja i gornja granica kardinalnosti) je minimalni i maksimalni broj pojava jednog entiteta za pojedinanu pojavu sa njim povezanog entiteta. Donja granica moe biti 0, 1, pozitivni cijeli broj ili znak (npr. M). Kada je donja granica jednaka nuli postoji djelomino, neobavezno pridruivanje. Ne mora postojati nijedna instanca sa druge strane veze. Kada je donja granica razliita od nule postoji potpuno, obavezno pridruivanje. Mora postojati barem neki broj ili openito M instanci sa druge strane veze. Gornja granica moe biti 1, pozitivni cijeli broj ili znak (npr. N). Moe imati konkretan broj ili openito N instanci sa druge strane veze. Veze su dvosmjerne pa se kardinalnost definia za oba smjera veze. Primjer: Binarna veza 1:N. 1,1
Mjesto
Stanuje
0,N
Osoba
107
Proizvodi
Slika 6.5. Primjeri binarnih veza 1:N i M:N. Primjer: Ternarna veza. Zanimanje 1,N Osoba 1,N Zaposlen 1,N OrgJed
Primjer: Unarna veza 1:N i unarna veza M:N. 0,1 Pripada PodJed 0,N Proizvod Dio 0,N 0,M Sastav
NadJed OrgJed
Cjelina
6.1.7. Specijalizacija/generalizacija
Specijalizacija/generalizacija se zove i "je" veza (is a relationship). Ova veza opisuje posebne sluajeve u nekom skupu entiteta, to jest odnos nekog entiteta (nadtip) i njegovih posebnosti (podtip). Podreeni entiteti stvaraju se na osnovu njima nadreenog entiteta sa kojim dijele zajednike atribute:
108
nadtip (supertype) - sadri zajednike atribute i predstavlja generalizaciju podreenih entiteta, podtip (subtype) - sadri samo njemu svojstvene atribute i predstavlja specijalizaciju nadreenog entiteta. Primjeri: 1. B je podtip od A ako: B je uvijek A, A je ponekad B; 2. Radnik je uvijek Osoba, Osoba je ponekad Radnik (Saradnik); 3. Igla je uvijek Proizvod, Proizvod je ponekad Igla (Avion). Specijalizacija moe biti neekskluzivna (npr. Osoba je Radnik ili Saradnik, ali u isto vrijeme moe biti i Radnik i Saradnik) ili ekskluzivna (Proizvod je Igla ili Avion, ali ne moe istovremeno biti Igla i Avion). Osoba Proizvod 11 0,1 Radnik NS 0,N Saradnik 0,1 Igla ES 0,1 Avion
109
Osoba
StavkaRacuna
Zanimanje
1,N 0,N
0,1 NadJed
Pripada
0,N Proizvodi 0,M Sastav Dio 0,N 0,1
PodJed 1,N
Stanuj
Osoba
1,N
Zaposlen
OrgJed
0,M
Raun
1,1
RaStRa OdnosiSeNa
Proizvod
1,1 0,1
NS
0,1 0,N
1,N
StavkaRauna
ES
Radnik
Saradnik
0,N
Igla
Avion
110
2. Martin-ova notacija.
Mjesto
Zanimanje
Pripada Stanuje
Osoba
Zaposlen
OrgJed
Sastav
Proizvod Raun
Radnik
Saradnik
Stavka rauna
Igla
Avion
111
M zahtjeva
Zahtjev za hemikalijom
popisuje
Zahtjeva
M M 1 M
sadri
Hemikalija
opisuje M
Dobavljaev katalog
Slika 6.11. Primjer dijagrama entitetiveze za hemijsku laboratoriju [Fertalj & Kalpi, 2005].
112
potpuno odreenim atributima (fully attributed data model) i potpuno opisani model podataka (fully described data model). Kategorije entiteta, koji ulaze u sastav modela podataka, su slijedee: osnovni (fundamentalni, jaki entiteti), koji ne spadaju u ostale kategorije (npr. Mjesto), asocijativni (spojni, vezni), koji proizlaze iz asocijativnih veza (npr. Zaposlenje), atributivni, koji opisuju ili kategoriziraju druge entitete (npr. Zanimanje, Stanje) i podtipovi specijalizacije (npr. Radnik, Saradnik, Igla, Avion).
113
Slika 6.12. Ekranska forma, sa izvodom iz jednog dijagrama ERD, CASE alata Entity Relationship Diagramer (Designer 2000, ORACLE). Notacija za prikaz ERD-a u Entity Relationship Diagramer-u se razlikuje od prethodno navedene notacije. Najbitnija razlika je u tome da se tipovi veze ovdje ne prikazuju simbolima za romb i linijama, ve samo pomou jedne linije koja povezuje dva tipa entiteta. Ta linija moe biti puna, isprekidana ili djelimino isprekidana i na sebi imati dodatne oznake u zavisnosti od parametara tipa veze. Pored optih pravila za tumaenje prikazanog ERD-a, koja se mogu nai u literaturi o BP, potrebno je naglasiti da simbol: "#" uz atribut (obiljeje) oznaava da je rije o atributu koje je u sastavu primarnog kljua tipa entiteta, "*" uz atribut oznaava da je rije o atributu koji je obavezan za unos, odnosno korespondira ogranienju Null(N, A) = , "o" uz atribut oznaava da je rije o atributu koji nije obavezan za unos, odnosno korespondira ogranienju Null(N, A) = T,
114
"|" na tipu veze oznaava da je tip entiteta na strani gdje se nalazi simbol "|" identifikaciono zavisan od tipa entiteta na drugoj strani, to znai da e u sastav primarnog kljua takvog tipa entiteta ui i svi atributi primarnog kljua tipa entiteta na drugoj strani posmatranog tipa veze, a " " na tipu veze oznaava da se pojave tipa entiteta na strani gdje se nalazi simbol " " ne mogu "prevezivati" za druge pojave tipa entiteta na drugoj strani.
115
Slika 6.13. Primjer modela podataka sa definisanim atributima entiteta i kljuevima entiteta (konceptualna shema).
116
117
Atributi mogu imati slijedee kardinalnosti preslikavanja: kardinalnost 0 - opciona vrijednost (null), kardinalnost 1 - zahtijevana vrijednost (not null) i kardinalnost N vieznani atribut (npr. Osoba.Telefon). Atribut Prezime entiteta Osoba se predstavlja sa Osoba.Prezime. Izvedeni atribut je atribut koji se pamti ili se izostavlja, npr. Osoba.Staz, dok je sloeni atribut dobijen grupisanjem, npr. grupisanjem (dan, mjesec, godina) dobija se atribut Datum (slika 6.14).
Osoba IdOsobe Prezime Ime Adresa DatRodj Staz
Slika 6.14. Atributi skupa entiteta Osoba. Vieznani atribut je skup odgovarajuih atributa, npr. Osoba.Telefon: Osoba.TelefonNaPoslu, Osoba.TelefonKodKuce, Osoba.MobilniTelefon ili prikazano kao slabi entitet, npr. Osoba.Telefon: Telefon (IdOsobe, VrstaTelefona, BrojTelefona), slika 6.15.
Osoba IdOsobe Prezime Ime TelefonNaPoslu TelefonKodKuce MobilniTelefon Adresa DatRodj Staz Osoba 1,1 0,N Telefon
118
Kljuevi mogu biti primarni, npr. Osoba.IdOsobe, Mjesto.SifMjesta ili alternativni (AK), koga sainjava indeks nad jedinstvenim vrijednostima (unique index) + oznaka zahtijevane vrijednosti (not null), npr. Mjesto.PostBr (slika 6.16).
OsobaSKljucem IdOsobe Prezime Ime Adresa DatRodj Staz
Slika 6.16. Primjeri primarnog i alternativnog kljua <AK>. Veza moe biti binarna veza 1:N sa stranim kljuem. Na slici 6.17 su prikazane binarne veze egzistencijalno slabog entiteta sa obinim stranim kljuem i to: Stanuje (Osoba.SifMjesta) <FK1>, Pripada (OrgJed.SifNadJed) <FK2> i RacunOsoba (Racun.IdOsobe) <FK3>.
119
Identifikaciono slabi entitet naslijeuje klju jakog entiteta. Taj klju moe biti spojni klju, npr. StavkaRacuna (BrRacuna, SifProizvoda, JedCijena, Kolicina) ili kompozitni klju, npr. StavkaRacuna (BrRacuna, RbrStRac, SifProizvoda, JedCijena, Kolicina), slika 6.18.
Racun BrRac DatRac IdOsobe <FK> IznosRac StavkaRacuna BrRacuna <FK1> SifProizvoda <FK2> JedCijena Kolicina Proizvod SifProizvoda NazProizvoda JedCijena TipProizvoda StavkaRacuna BrRacuna <FK1> RbrStRac SifProizvoda <FK2> JedCijena Kolicina
Slika 6.18. Primjeri sloenog kljua. Binarna veza 1,1:0,1 sa stranim kljuem transformie se u identifikaciono slabi entitet bez deskriptora: npr. Osoba (IdOsobe, Prezime, , Staz), SlikaOsobe (IdOsobe, Slika). Po potrebi se moe razmotriti udruivanje entiteta u binarnoj vezi 1,1:1,1 (1,1:0,1) u jednu relaciju: Osoba (IdOsobe, Prezime, , Staz), Komentar (IdOsobe, TekstKom), Osoba (IdOsobe, Prezime, , Staz, TekstKom).
0,M 0,N
OrgJed
Proizvodi
Proizvod
1,N
OrgJed
Zaposlen IdOsobe <FK1> SifOrgJed <FK2> SifZanim <FK3> DatPoc DatZav KoefPlate Proizvod SifProizvoda NazProizvoda JedCjena TipProizvoda
DatPoc
DatZav
0,M
Cjelina
Proizvod
Dio
Sastav
120
Nespecifine veze se sastoje od asocijativnog entiteta + n binarnih veza 1:N. Klju asocijativnog entiteta je unija kljueva entiteta spojenih vezom (slika 6.19). Primjer: Proizvodi, Zaposlen, Sastav. Specijalizacija nadtipa u n podtipova (n binarnih veza) u kojoj je nadtip (jaki) entitet, kome se po potrebi odreuje klasifikacioni atribut, npr. Proizvod.TipProizvoda i podtip (identifikaciono) slabi entitet, npr. Igla, Avion (slika 6.20).
Proizvod SifProizvoda NazProizvoda JedCijena TipProizvoda Proizvod
1,1 0,1
ES
0,1
Igla
Avion
121
Slika 6.21. Dijagram implementacione sheme aplikacije Komercijalni poslovi. Na osnovu implementacione sheme BP se automatski generie ORACLE/SQL (ili ANSI/SQL) opis sheme BP, koji treba implementirati na odgovarajuem serveru BP. Implementaciona shema slui, takoe, kao osnova za modeliranje programske specifikacije modula i samo generisanje programskih modula, ta je detaljnije opisano u taki 10.7. Programska specifikacija modula za interaktivni rad sa bazom podataka, kreiranje izvjetaja, grafikonski prikaz podataka ili bibliotekog modula, se mogu oblikovati odgovarajuim CASE alatom, npr. Design Editor/Modules (Designer 2000, ORACLE), slika 6.23. Pomou istog alata se formira struktura ekranskih formi aplikacije i obezbjeuje meusobno povezivanje programskih modula, sa mogunou prenosa podataka izmeu modula.
122
Slika 6.22. Ekranska forma CASE alata Design Editor/Server Model (Designer 2000, ORACLE).
Slika 6.23. Ekranska forma CASE alata Design Editor/Modules (Designer 2000, ORACLE).
123
7. Modeliranje dogaaja
7.1. Modeliranje procesa voeno dogaajima
Dogaaj je zgoda ili zbivanje u sistemu koja vodi ili pokree procese sistema. Sm dogaaj nije proces, nego okida procesa koji se njime pokree. Primjer: Kupac dostavom narudbe pokree proces provjere da li se radi o narudbi postojeeg ili novog kupca, proces stvaranja podataka o narudbi i stavkama narudbe, provjeru prethodnih zaduenja kupca, provjeru stanja skladita, itd. Dogaaj moe biti vanjski, vremenski i unutranji. Vanjski dogaaji se pokreu od strane vanjskih entiteta, koji zahtijevaju informaciju ili auriranje podataka (ulazni tokovi podataka). Imenuje se tako da naziv sadri naziv vanjskog entiteta, npr. zahtjev za upis studenta ili zaprimanje narudbe kupca. Vremenski dogaaji su vremenski uslovljeni, npr. rok, uestalost (ulazni upravljaki tokovi). Imenuju se tako da naziv sadri vremensku oznaku, npr. istek roka plaanja rauna, mjeseni obraun plata, zakljuivanje ispitnog roka i slino. Unutranji dogaaji su dogaaji stanja, odnosno posljedica prelaza sistema iz jednog stanja u drugo na takav nain da to zahtjeva obradu (ulazni upravljaki tokovi), npr. isporuka robe sa skladita zahtijeva naruivanje nove robe. Raspodjela dogaaja vezanih za projektovanje IS: 1. Izrada dijagrama konteksta sistema, postavljanje poetnog dometa projekta; 2. Izrada dijagrama funkcionalne dekompozicije, podjela sistema u logike podsisteme i/ili funkcije; 3. Izrada popisa dogaaja i odziva, utvrivanje poslovnih dogaaja na koje sistem mora odgovoriti. Elementi popisa su dogaaj, ulaz i izlaz; 4. Izrada dijagrama dekompozicije dogaaja, dodavanje procesa za rukovanje dogaajima. Dodaje se po jedan proces za svaki utvreni dogaaj; 5. Izrada dijagrama dogaaja, odnosno razrada procesa za obradu dogaaja. Izrauje se po jedan dijagram za svaki dogaaj; 6. Izrada dijagrama sistema, odnosno udruivanjem dijagrama dogaaja; 7. Izrada primitivnih dijagrama. Razrada dijagramom toka podataka koji sadri osnovne procese, spremita i tokove za svaki pojedini dogaaj. Opti prikaz dijagrama sistema izraen modeliranjem procesa voenim dogaajima prikazan je na slici 7.1.
124
Sistem
Funkcija 2
Dogaaj 1
Dogaaj 2
Dogaaj 3
Dogaaj 4
Dogaaj 5
Dogaaj 1
Dogaaj 5
Dogaaj n
Zavretak je kada se ostvari da svaki dogaaj ima uinak na barem jedan entitet, a svaki entitet mora imati dogaaj koji ga stvara i brie.
125
Pojednostavnjeni primjer matrice dogaaj/entitet za rezervaciju sobe u hotelu Proljee, prikazan je na slici 7.2.
126
Na slici 7.3 je prikazana matrica Elementarne funkcije/Tipovi entiteta za aplikaciju Komercijalni poslovi, a na slikama 7.4 do 7.6 su prikazane matrice Elementarne funkcije/Atributi, za tipove entiteta KUPAC, SKLADISTE i ROBA za istu aplikaciju. Naini upotrebe tipa entiteta u zavisnosti od funkcije, kod matrice Funkcije/Tipovi entiteta, mogu biti: Create (C), sa znaenjem da je zadatak funkcije formiranje nove pojave posmatranog tipa entiteta, Retrieve (R), sa znaenjem da je zadatak funkcije preuzimanje podataka o postojeim pojavama tipa entiteta, Update (U), sa znaenjem da je zadatak funkcije modifikacija podataka o postojeim pojavama tipa entiteta, Delete (D), sa znaenjem da je zadatak funkcije brisanje pojave tipa entiteta, Archive (A), sa znaenjem da je zadatak funkcije da posebnim postupcima arhivira pojave tipa entiteta, i Other (O), sa znaenjem da funkcija ima zadatke koji prethodnim nainima upotrebe nisu pokriveni.
127
Slike 7.6. Matrice Elementarne funkcije/Atributi za tip entiteta ROBA. Naini upotrebe atributa tipova entiteta u zavisnosti od funkcije, kod matrice Funkcije /Atributi, mogu biti: Insert (I), sa znaenjem da je zadatak funkcije da prvi put zadaje vrijednost atributa tipa entiteta, Retrieve (R), sa znaenjem da je zadatak funkcije preuzimanje postojee vrijednost atributa tipa entiteta,
128
Update (U),sa znaenjem da je zadatak funkcije modifikovanje prethodno zadane vrijednosti atributa tipa entiteta, Nullify (N), sa znaenjem da je zadatak funkcije omoguavanje zadavanja nula vrijednosti za atribut tipa entiteta, koji prethodno nije imao nula vrijednost, Archive (A), sa znaenjem da je zadatak funkcije da posebnim postupcima arhivira vrijednosti atributa tipa entiteta, i Other (O), sa znaenjem da funkcija ima, u odnosu na vrijednosti atributa tipa entiteta, zadatke koji prethodnim nainima upotrebe nisu pokriveni.
129
potvrda rezervacije 3
najavljeni dolazak 2
stvaranje troka
plaanje usluga
arhiviranje rezervacije 7
3 3 5 6 poveanje troka 4
privremena rezervacija 1
dolazak gosta
opoziv rezervacije 3
nedolazak gosta 3
1. Kreirati rezervaciju 2. Zauzeti sobu 3. Aurirati status rezervacije 4. Kreirati zaduenje 5. Ponititi zaduenje 6. Osloboditi sobu 7. Obrisati podatke o rezervaciji
130
"besposlen". Na slici 7.9 je prikazan Dijagram prelaza stanja Sokomata hotela Proljee ili Bankomata banke Montenegro, na kome su naglaena stanja ekanje.
ekanje na izbor
obavljen odabir/ Pokupite izvaeno/ Jo neto?
natoeno (izbrojano) Slika 7.9. Dijagram prelaza stanja Sokomata hotela Proljee ili Bankomata banke Montenegro.
131
Dijalog mape su, takoe, korisne kod modeliranja vizuelne arhitekture web sjedita, pa se ponekad tako i nazivaju (eng. site maps). Navigacioni linkovi u sjeditu pojavljuju se kao tranzicije na dijalog mapi. Koristi se notacija dijagrama prijelaza stanja. Uslov koji pokree korisniku navigaciju prikazan je kao tekst na strelicama. Postoji nekoliko vrsta pokretakih uslova: korisnika akcija, kao to je pritisak tastera ili klik na link ili dugme dijalog prozora, vrijednost podataka, kao to je pogrean unos koji pokree pojavljivanje poruke o greci, sistemski uslov, kao to je signal da je pisa ostao bez papira i kombinacija navedenih, kao to je kucanje opcije iz ekranske forme i pritisak na taster Enter. Radi pojednostavnjenja mogu se izostaviti neke opte funkcije, npr. pritiskanje 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 uobiajenog puta, npr. uobiajeni put bi bio naruiti hemikaliju od vanjskog dobavljaa, a alternativno se hemikalija moe dobiti iz zaliha hemijske laboratorije. Prilikom analize zahtjeva, dijalog mapa predstavlja interakciju korisnika i sistema na konceptualnom nivou. Konkretna ugradnja moe biti drugaija. Primjer: Korisnik inicira model koritenja odabirom opcije "zatrai hemikaliju" iz glavnog odabiraa. Polazna taka za ovaj model koritenja je popis traenih hemikalija koji se naziva "Trenutna lista zahtjeva".
132
133
134
kasne 70-te, rane '80-te: strukturirana analiza - odvajanje logikog opisa od fizikog opisa (informacionog) sistema, oblikovanje podataka, rane '80-te: CASE alati; izrada prototipova, sredinom '80-ih: informaciono inenjerstvo, zdrueni razvoj aplikacija (Joint Application Development), kasne '80-te: brzi razvoj aplikacija (Rapid Application Development), rane 90-te: objektno usmjereni razvoj, kasne 90-te, rane 2000-te: automatizacija informatikih tehnologija, ... . Raunarsku osnovu (Computing Fundamentals) softverskog inenjeringa sainjavaju: algoritmi i strukture podataka (Algorithms and Data Structures), arhitektura raunara (Computer Architecture), matematika podrka (Mathematical Foundations), operativni sistemi (Operating Systems) i programski jezici (Programming Languages). Proizvodi softverskog inenjeringa (Software Product Engineering) su: zahtjevi softverskog inenjeringa (Software Requirements Engineering), softverski dizajn (Software Design), kodiranje softvera (Software Coding), testiranje softvera (Software Testing), rad softvera i odravanje (Software Operation and Maintenance). Upravljanje softverom (Software Management) u slijedeim segmentima: softversko upravljanje projektom (Software Project Management), softversko upravljanje odluivanjem (Software Risk Management), softversko upravljanje kvalitetom (Software Quality Management), softversko upravljanje konfiguracijom (Software Configuration Manage-ment), softversko upravljanje procesima (Software Process Management) i softverska akvizicija (Software Acquisition).
135
Softverski alati (tool) je instrument, sredstvo koje se koristi u razvoju IS. Informacionu tehnologiju (Information Technology) sainjavaju: arhitektura kompjutera (Computer Architectures), algoritmi i strukture podataka (Algorithms and Data Structures), programski jezici (Programming Languages)), operativni sistemi (Operating Systems), telekomunikacije (Telecommunications), baze podataka (Database) i vjetaka inteligencija (Artificial Intelligence). Organizacioni i upravljaki koncepti (Organizational and Management Concepts) informacione tehnologije su: opta teorija organizacije (General Organization Theory), upravljaki informacioni sistemi (Information Systems Management), teorija odluivanja (Decision Theory), organizacioni postupci (Organizational Behavior), upravljanje procesima za promjene (Managing the Process of Change), pravni i etiki aspekti IS (Legal and Ethical Aspects of IS), profesionalizam (Professionalism) i interdisciplinarno znanje (Interpersonal Skills). Teoriju i razvoj sistema (Theory and Development of Systems) sainjavaju: sistemski i informacioni koncepti (Systems and Information Concepts), pristup razvoju sistema (Approaches to Systems Development), koncepti razvoja sistema i metodologije (Systems Development Concepts and Methodologies), alati za razvoj sistema i tehnike (Systems Development Tools and Techniques), planiranje aplikacija (Application Planning), upravljanje odluivanjem (Risk Management), upravljanje projektom (Project Management), informaciona i poslovna analiza (Information and Business Analysis), informacioni sistemski dizajn (Information Systems Design), implementacija sistema i strategija testiranja (Systems Implementation and Testing Strategies), rad sistema i odravanje (Systems Operation and Maintenance) i razvoj posebnih vrsta informacionih sistema (Systems Development for Specific Types of Information Systems).
136
137
U skladu sa navedenim razlozima, od CASE proizvoda se oekuje da obezbjede to vii stepen automatizacije kada se obavljaju slijedei zadaci: izrada dokumentacije, izrada dijagrama i matrica, konceptualno i implementaciono projektovanje shema baza podataka, projektovanje programskih proizvoda, izrada (generisanje) programskih proizvoda, obavljanje izmjena na programskim proizvodima, integracija parcijalnih rezultata projektovanja u jedinstvenu cjelinu, kontrola funkcionalnosti, konzistentnosti, kompletnosti i kvaliteta projekta, itd. Da bi zadovoljili navedene zahtjeve, CASE proizvodi su organizovani tako da rade nad jedinstvenom BP, koja se naziva Rjenik podataka CASE proizvoda. Rjenik sadri podatke o svim konceptima (objektima, vezama, dijagramima, matricama, dokumentaciji, itd.), definisanim u okviru jednog, ili vie projekata, koji se smjetaju u rjenik. Svi pojedinani alati jednog CASE proizvoda koriste i smjetaju podatke u isti rjenik podataka, ta je prikazano na slici 8.1.
Alat za modeliranje dijagrama toka podataka Alat za modeliranje ER dijagrama
Rjenik podataka
Generatori koda
Slika 8.1. Meusobni odnos razliitih CASE alata i jedinstvenog rjenika podataka. Mogu se sresti razliite klasifikacije CASE proizvoda. Jedna, uobiajena i ne suvie selektivna, je izvrena prema fazama ivotnog ciklusa koje CASE proizvod pokriva. Prema toj klasifikaciji, razlikuju se:
138
1. Projektantski CASE proizvodi, koji su namjenjeni za podrku prve (gornje) tri faze ivotnog ciklusa, odnosno za podrku projektovanju programskog proizvoda (strategija, snimanje i analiza, projektovanje); 2. Programerski CASE proizvodi, namjenjeni za podrku posljednje (donje) tri faze ivotnog ciklusa, odnosno za podrku realizacije programskog proizvoda (programiranje, uvoenje u upotrebu, eksploatacija i odravanje); 3. Integrisani CASE proizvodi, tj. integrisani projektantski i programerski CASE proizvodi, namjenjeni da podre svih est faza ivotnog ciklusa, odnosno kompletan ivot programskog proizvoda.
139
pravila upotrebe odgovarajue tehnike, koji dani alat podrava. Na taj nain projektant dobija tehniku pomo u radu. Pored toga, na viem nivou, oekuje se da alat prui projektantu i ekspertnu, tj. intelektualnu, pomo u primjeni odgovarajue tehnike. Takva pomo se ogleda u mogunosti da sam alat prua odgovarajua projektantska rjeenja ili da je u stanju da analizira, vrednuje i ocjenjuje rjeenja, koja je napravio projektant softverskog proizvoda.
140
Uoava se da su svi alati iz okruenja 4. generacije, iz istih razloga kao i CASE proizvodi, oslonjeni na jedinstveni rjenik podataka. ta vie, nastoji se da ovi alati budu integrisani sa CASE proizvodima po pitanju koritenja zajednikog rjenika podataka, ime se obezbjeuje jedinstveno razvojno okruenje programskih proizvoda. Da se prevazie neproduktivno i dugotrajno programiranje uz upotrebu jezika 3. generacije razvijeni su generatori koda i 4GL okruenje. Neposredni pozitivni efekti primjene generatora koda i 4GL okruenja se ogledaju u ubrzanju i olakanju procesa izrade programskog proizvoda, kao i smanjenju trokova odravanja aplikacija, budui da je olakano otkrivanje, pronalaenje i ispravljanje uoenih greaka. Posredni pozitivan efekat je mogunost primjene prototipskog pristupa razvoju programskih proizvoda, o emu je detaljnije bilo govora u podtaki 2.4.3. Prisutni su i negativni efekti primjene generatora koda i jezika 4. generacije. Jezik 4. generacije ili generisana aplikacija pomou jezika 4. generacije je, na istoj hardverskoj platformi, sporija od odgovarajue aplikacije razvijene uz pomo jezika 3. generacije. Funkcionalnost, odnosno irina primjene, generatora koda i 4GL okruenja je manja od funkcionalnosti jezika 3. generacije. Uoava se da ovi nedostaci predstavljaju kontinuitet trendova koji se odnose i na uvoenje i upotrebu jezika 3. generacije. Prednosti i nedostaci upotrebe generatora koda i 4GL okruenja ukazuju da se pravilnim izborom generatora koda i 4GL okruenja, jezika 3. generacije i naina povezivanja sa 4GL okruenjem i odgovarajue (jae) hardverske platforme, mogu obezbjediti sve prednosti upotrebe generatora koda i 4GL okruenja, uz ouvanje dovoljno dobrih performansi izvravanja razvijene aplikacije i dovoljno dobre funkcionalnosti za rad. To znai da se mogu postii velike utede pri realizaciji i odravanju aplikacija IS dodatnim ulaganjima u hardver i alate za razvoj aplikacija.
Uloeni napor, potreban za realizaciju aplikacije
Sloenost aplikacije
Slika 8.3. Problematika funkcionalnosti generatora koda, 4GL okruenja i jezika 3. generacije [Mogin et al. 2000].
141
Problematika funkcionalnosti generatora koda, 4GL okruenja i jezika 3. generacije ilustrovana je dijagramom na slici 8.3. Uoava se da se manje sloene aplikacije mogu neposredno dobiti upotrebom generatora koda. Za sloenije aplikacije je, nakon generisanja koda potrebno izvriti dodatna prilagoavanja, upotrebom alata 4. generacije, dok se vrlo sloeni i dominantno proceduralni dijelovi aplikacija mogu uspjeno realizovati samo upotrebom jezika 3. generacije. Iz navedenih razloga je prethodno i naglaena potreba kombinovane upotrebe alata 4. generacije i jezika 3. generacije. Upotreba generatora koda ima jo jedan nedostatak. Ponovno generisanje aplikacije, nakon ve izvrenog prilagoavanja generisanog koda pomou alata 4. generacije, moe znaiti unitavanje prethodno izvrenih prilagoavanja. Savremeni trendovi razvoja generatora koda idu ka tome da se ovaj nedostatak ublai na dva naina. Prvi nain predvia pomjeranje granice upotrebljivosti generatora koda, tako da se pomou generatora koda mogu izgraditi i sloenije aplikacije. Cilj je da se pree granica od 80% ukupno generisanog koda, koji bi bez daljih dorada bio spreman za upotrebu. Drugi nain se zasniva na sistematinom evidentiranju doraenih dijelova generisanog koda u okviru rjenika podataka, tako da svako slijedee regenerisanje uzme u obzir i postojea prilagoenja koda.
142
Savremeni CASE proizvodi za projektovanje konceptualne, implementacione i interne sheme najee omoguavaju projektovanje konceptualne sheme u modelu entiteti veze (ER model) i automatsko prevoenje ER konceptualne u implementacionu shemu, zasnovanu na relacionom modelu podataka. Pojedini CASE proizvodi omoguavaju i projektovanje fizike organizacije relacione BP. Rezultat ovakvog projektovanja je automatski generisan opis implementacione i interne sheme u relacionom upitnom jeziku SQL. CASE proizvod za projektovanje ER konceptualne sheme se sastoji od grafikog editora za poluautomatsko crtanje ER dijagrama i analizatora konzistentnosti nacrtanih shema. Grafiki editor sadri predefinisane standardne geometrijske simbole koncepata ER modela. Crtanje ER dijagrama se obavlja biranjem simbola i njihovim povezivanjem, u skladu sa pravilima strukturiranja ER dijagrama. Analizator konzistentnosti je namjenjen za provjeru usaglaenosti nacrtanog ER dijagrama sa pravilima strukturiranja, kao i pronalaenje potencijalnih sinonima i homonima. Mogunost definisanja funkcionalnih zavisnosti posjeduju samo pojedini CASE proizvodi, najee u skupu tipa entiteta ili tipa veze. Nakon definisanja skupa funkcionalnih zavisnosti, CASE proizvod vri normalizaciju relacija. Ukoliko rezultat normalizacije pokae da posmatrani tip entiteta ili tip veze treba dekomponovati, CASE proizvod tu izmjenu u ER dijagramu vri automatski. Meutim, u praksi se esto deava da ovako nacrtan ER dijagram ne predstavlja lako razumljivu osnovu za komunikaciju izmeu projektanta i korisnika. Krajnji korisnik je, prvenstveno, zainteresovan da pomou raunara olaka, ubrza i povea kvalitet obavljanja svojih radnih zadataka i nije spreman da se udubljuje u analizu kvaliteta konceptualne sheme, koja je predstavljena, za njega, apstraktnom i stranom notacijom. Tek kada dobije gotove programe, ili njihove prototipove, korisnik moe da ocjeni da li mu rjeenje odgovara. Sa druge strane, programere interesuje podshema u implementacionom modelu podataka. Prema tome, crtanje ER dijagrama se moe posmatrati samo kao usputan, i ne ba jednostavan, korak u projektovanju implementacione sheme i, u sutini, predstavlja heuristiki postupak. Nema dokaza da paljivo projektovanje ER dijagrama, nakon prevoenja u relacioni model podataka, uvjek rezultuje u skup relacija, koje su bar u treem normalizovanom obliku (3NO). Na slikama 8.4, 8.5 i 8.6 su prikazani primjeri nekih aktuelnih CASE proizvoda. Na slici 8.4 je prikazana ekranska forma integrisanog CASE alata (ICASE) Popkin System Architect, koji podrava vie metodologija projektovanja IS (SSAD, OOAD), reverzno inenjerstvo i generisanje programskog koda. Na slici 8.5 je prikazana ekranska forma alata za oblikovanje BP CA AllFusion ERwin, koji je namjenjen za dizajn i reinnjerstvo BP, podravajui razliite notacije projektovanja (IDEF1X, IE, DM). Na slici 8.6 je prikazana ekranska forma alata za projektovanje objektno orijentisanog softvera Rational ROSE, koji podrava OO metode (UML, OMT, Booch, ).
143
144
Slika 8.6. Ekranska forma CASE alata za projektovanje objektno orijentisanog softvera.
145
izmjena u okviru projekta. Takoe, olakava odravanje razliitih verzija projektne dokumentacije i zatitu sadraja rjenika podataka od brisanja, nenamjernih izmjena ili neovlatenog pristupa. Navedeni pristup ne uvodi ogranienja koja bi negativno uticala na integrisanost IS. Postoji i mogunost da se cjelokupni IS razvija putem samo jednog aplikativnog sistema. Prilikom prijavljivanja za rad sa Designer-om 2000, korisnik se odluuje za aplikativni sistem nad kojim e realizovati svoje projektantsko-programerske aktivnosti. Odgovarajua ovlatenja za rad sa izabranim aplikativnim sistemom moraju biti prethodno dodjeljena korisniku. Designer-a 2000 svoju metodologiju moe da zasnovana, kako na klasinom modelu primjene metodologije ivotnog ciklusa, tako i na bilo kojoj od kombinacija, koja ukljuuje evolutivni, inkrementalni ili zvjezdasti model primjene metodologije ivotnog ciklusa, kao i na prototipskom razvoju. Designer 2000 omoguava, takoe, i primjenu tehnika reverznog inenjerstva BP i aplikacija IS. Po svom sastavu Designer 2000 je integrisani skup programskih alata, razliite namjene, slika 8.7.
Slika 8.7. Ekranska forma ORACLE/Designer-a 2000. Za fazu strategijskog planiranja, kao i faze snimanja i analize, Designer 2000 predvia upotrebu slijedeih alata:
146
Process Modeller, koji je namjenjen za dijagramski prikaz procesa i tokova u realnom sistemu i podrku njihovog eventualnog reverznog inenjeringa, Function Hierarchy Diagramer - alat za modeliranje funkcionalne dekompozicije realnog sistema i strukture programske podrke informacionog sistema, Dataflow Diagramer - alat za modeliranje tokova podataka unutar poslovnog i informacionog sistema, putem dijagrama tokova podataka, i Entity Relationship Diagramer - alat za konceptualno modeliranje sheme baze podataka, putem dijagrama tipova entiteta i veza. Za fazu projektovanja informacionog sistema su namjenjeni slijedeci alati: Database Design Transformer, za prevoenje ER konceptualne sheme baze podataka u relacionu shemu baze podataka, Design Editor / Server Model, za projektovanje relacione, implementacione sheme baze podataka (oblikovanje shema relacija - tabela, programiranje procedura, funkcija, paketa procedura i funkcija, kao i trigera baze podataka), Application Design Transformer, za inicijalno generisanje programskih specifikacija (opisa programskih modula, podshema i strukture ekranskih formi), Design Editor / Modules, za implementaciono projektovanje programskih modula (tj. programa za interaktivno auriranje baze podataka, generisanje izvjetaja, grafiki prikaz podataka i biblioteka procedura i funkcija), kao i struktura programskih modula (ekranskih formi aplikacija), Design Editor / DB Admin, za projektovanje interne sheme baze podataka (zadavanje parametara fizike organizacije podataka), i Design Editor / Distribution, za projektovanje distribuirane sheme baze podataka. Kada su u pitanju faze: programiranja, uvoenja u upotrebu i eksploataciju i odravanje informacionog sistema, Designer 2000 je opremljen slijedeim generatorima koda: Generate Database From Server Model, za generisanje SQL opisa implementacione sheme baze podataka, Generate Database Administration Objects - generisanje SQL opisa interne sheme baze podataka, Generate Module / Forms, za generisanje programskih modula za interaktivni pristup bazi podataka, zasnovanih na jeziku IV generacije Developer 2000 / Forms, Generate Module / Reports, za generisanje programskih modula za formiranje izvjetaja, zasnovanih na jeziku IV generacije Developer 2000 / Reports,
147
Generate Module / Graphics, za generisanje programskih modula za grafiki prikaz podataka, zasnovanih na jeziku IV generacije Developer 2000 / Graphics, Generate Module / Visual Basic, za generisanje programskih modula za interaktivni pristup bazi podataka, zasnovanih na programskom jeziku Visual Basic, Generate Module / Web Server, za generisanje ORACLE WebServer programskih modula, za pristup bazi podataka preko Internet/Web servera, zasnovanih na HTML formatu, i Generate Module / Help System, za generisanje programskih modula za prezentiranje uputstava i ostalih tekstualnih informacija, zasnovanih na Forms ili Microsoft Help korisnikom interfejsu. Moe se konstatovati da je Designer 2000, u dijelu koji se odnosi na generatore koda, dosta vrsto povezan i sa ORACLE-ovim okruenjem etvrte generacije Developer 2000, u koje, izmedju ostalih, spadaju alati: Form Builder, za kreiranje interaktivnih programskih modula (koji se jos nazivaju i "forme"), Report Builder, za kreiranje programskih modula za izvjetavanje (koji se nazivaju i "izvjetaji") i Graphics Builder, za kreiranje programskih modula za grafiki prikaz podataka ("grafikona"). Pored nabrojanih, Designer 2000 posjeduje i slijedee programe, koji se svrstavaju u oblast reverznog inenjerstva: Capture Design of Database, namjenjen za reverzni inenjering implementacione ili interne sheme baze podataka, na osnovu stanja rjenika ORACLE baze podataka, kao i utvrivanje i eliminisanje razlika izmeu stanja rjenika ciljne baze podataka i rjenika Designer-a 2000, Table To Entity Retrofit, namjenjen za prevoenje implementacione sheme baze podataka u konceptualnu shemu baze podataka, prikazanu putem dijagrama tipova entiteta i veza, Capture Design of Form, namjenjen za reverzni inenjering interaktivnih programskih modula, kreiranih u okviru alata Developer 2000/Forms, Capture Design of Report, namjenjen za reverzni inenjering programskih modula za izvjetaje, kreiranih u okviru alata Developer 2000/Reports, Capture Design of Library, namjenjen za reverzni inenjering bibliotekih modula, kreiranih u okviru paketa Developer 2000, Capture Design of Visual Basic, namjenjen za reverzni inenjering interaktivnih programskih modula, kreiranih pomou alata Visual Basic, i Capture Applicatoin Logic, namjenjen za usaglaavanje implementacione specifikacije Forms modula iz Designer-a 2000 i postojeeg Forms modula iz Developer-a 2000. U skupu alata opte namjene, Designer 2000 posjeduje slijedee:
148
Repository Object Navigator, namjenjen za direktni pristup objektima u rjeniku podataka Designer-a 2000, putem hijerarhijski organizovanog navigatora objekata, Matrix Diagramer, namjenjen za izgradnju razliitih tipova matrinih dijagrama, Repository Reports, za generisanje velikog broja razliitih tipova izvjetaja, na osnovu stanja rjenika podataka Designer-a 2000, pri emu ti izvjetaji slue za sprovoenje odreenih kontrola i analiza kvaliteta projekta, ili samo kao "papirna" projektna dokumentacija, Repository Administration Utility, pomou kojeg se obavljaju administrativni zadaci nad Designer-om 2000, kao to su: instalacija i deinstalacija rjenika podataka, dodjela prava pristupa korisnicima, arhiviranje i dearhiviranje rjenika podataka, obavljanje odreenih formalnih kontrola, itd, Online Help, kao alat za prezentiranje uputstava za koritenje Designer-a 2000, i SQL Plus, za interaktivno izvravanje SQL naredbi nad ORACLE bazom podataka. Kada je u pitanju objektno orijentisani pristup razvoju informacionog sistema, u okviru Designer-a 2000 se pojavljuje alat pod nazivom: Object Database Designer, namjenjen za projektovanje dijagrama klasa objekata, prevoenje dijagrama klasa objekata u implementacionu shemu baze podataka i implementaciono i fiziko projektovanje sheme baze podataka.
149
generisanje projektnih i programskih specifikacija programskog proizvoda u formatu "razumljivom" CASE proizvodu, pomou kojeg se eli razviti nova verzija tog programskog proizvoda. Na slici 8.8 je prikazana ekranska forma alata za reverzno inenjerstvo.
Slika 8.8. Ekranska forma CASE alata za reverzno inenjerstvo. Tehnike reverznog inenjerstva, u domenu IS, se primjenjuju za ostvarenje slijedeih zadataka: 1. Generisanje implementacionog opisa sheme BP, na osnovu nekih od slijedeih parametara: realnih podataka koji postoje u BP, stanja rjenika podataka konkretnog sistema za upravljanje bazama podataka (SUBP) pod kojim je posmatrana BP realizovana ili opisa datoteka i formata slogova u programskom kodu aplikacija tekue verzije IS (npr. u okviru SUBP ORACLE/Designer 2000 reverzni inenjering implementacione sheme BP, na osnovu stanja rjenika ORACLE baze podataka i eliminisanja razlika izmeu rjenika ciljne BP i rjenika Designer-a 2000, obavlja program Capture Design of Database); 2. Generisanje konceptualne sheme BP, na osnovu implementacione sheme baze podataka (npr. u okviru SUBP ORACLE/Designer 2000 prevoenje implementacione sheme BP u konceptualnu shemu BP obavlja program Table To Entity Retrofit); 3. Generisanje programskih specifikacija (struktura menia, ekranskih formi ili formi za izvjetaje, podshema i proceduralne logike) na osnovu programskih kodova aplikacija tekue verzije IS (npr. u okviru SUBP ORACLE /Designer
150
2000 za reverzni inenjering ekranskih formi, izvjetaja i bibliotekih modula, namjenjeni su programi Capture Design of Form, Capture Design of Report i Capture Design of Library). Izbor tehnike reverznog inenjerstva i njena automatizovana primjena u velikoj mjeri zavisi, kako od prirode konkretnog zadataka koji se rjeava, tako i od kvaliteta, tj. "informativnosti" ulazne specifikacije, na koju se tehnika reverznog inenjerstva primjenjuje. Samim tim je i kvalitet generisanog rezultata u reverznom inenjerstvu bitno odreen kvalitetom ulazne specifikacije. Ukoliko se, na primjer, tehnika reverznog inenjerstva primjenjuje za generisanje implementacione sheme BP, najbolji rezultat se, u optom sluaju, moe oekivati ukoliko se kao ulazna specifikacija koriste podaci iz rjenika podataka sistema za upravljanje bazama podataka, a najloiji ako se kao ulazna specifikacija koriste samo realni podaci iz BP. Ova konstatacija, medjutim, ne mora biti uvijek tana. Ukoliko rjenik podataka konkretnog sistema za upravljanje bazama podataka sam po sebi nije dovoljno informativan, ili se u tom rjeniku, iz nekog razloga, ne nalaze svi potrebni podaci, tada ni izlazni rezultat reverznog inenjerstva ne moe biti dobar.
151
152
koji treba obaviti, dok su fizika skladita: baze podataka, tabele (relacije) i datoteke; 2. Grupisanje i distribucija obrade na razliite lokacije; 3. Dizajn raunarske mree, povezivanje sa drugim, postojeim, sistemima; 4. Definisanje prava pristupa logikih grupa korisnika. Opti dizajn interfejsa se odnosi na poboljanje izgleda (ergonomija). Izrada planova konverzije i instalacije predstavlja posljednju fazu definisanja optog dizajna.
153
mrea Svi podaci na mainframe serveru Sva poslovna logika na mainframe serveru Distribuirani podaci (2-slojna) mrea Distribuirani podaci i logika (3-slojna) mrea Podaci i procesi BP na serveru Poslovna logika na aplikativnom serveru Internet i Intranet mrea Podaci na serveru BP Sigurni Intranet provajder za pristup podacima, logici i Dio logike na Intranet serveru interfejsu Siguran ulaz za zatitu aplikacija i podataka mrea Korisniki interfejs na PC klijentu Korisniki interfejs na PC klijentu
154
Uobiajeni modeli arhitekture su: serverski (server-based) obrada se obavlja na serveru, klijentski (client-based) obrada se obavlja na personalnom raunaru, klijent-server (client-server based) kombinacija prethodne dvije. Model mree sadri prikaz glavnih komponenti sistema, njihove fizike lokacije i nain njihovog meusobnog povezivanja. Funkcije sistema, odnosno slojevi arhitekture, su odreeni pohranom podataka (data storage), pristupom podacima (data access logic), elementima obrade (application logic) i interfejsom (presentation logic). Serveri mogu biti: veliki raunari (Mainframe), mali raunari (Minicomputer), mikroraunari (Microcomputer), personalni raunari (PC). Klijenti su klasini terminali (npr. ansi, vt220) i mikroraunari (PC), koji omoguavaju pristup terminal emulatorima ili udaljenim radnim plohama. Tu spadaju i terminali posebne namjene, kao to su banini terminali (bankomati), Internet kiosci, runi raunari i sl. Na slici 9.1 su prikazani primjeri arhitekture IS.
155
Skladitenje podataka
Server (mikroraunar, mali raunar ili veliki raunar)
Slika 9.3. Dvoslojna arhitektura klijent-server. Server je viekorisniki raunar. Omoguava rad sa dijeljenom bazom podataka, obradu podataka i servisiranje interfejsa. Posjeduje mogunost povezivanja sa klijentima i drugim serverima. Korisnicima izgleda kao da jedan raunar obavlja cijeli posao. Prednosti dvoslojne arhitekture klijent-server (slika 9.3) su u izolaciji promjena u pojedinom sloju, kvalitetnijoj (lakoj) obradi i sredinjem upravljanju integritetom podataka na serveru. Nedostak ove arhitekture je u oteanom odravanju aplikacione logike (programa) na svim klijentima i pojava debelog klijenta. Debeli klijent je onaj klijent kod koga je integrisana logika podataka. Nema obrade podataka na serveru ili je obrada minimalna. Posjeduje minimalnu ili nikakvu elastinost na promjenu poslovne politike. Prednosti debelog klijenta su: brzi poetni razvoj aplikacije, vea samostalnost klijenta i rastereenje glavnog raunara (servera). Moe imati lokalnu bazu podataka. Kao debeli klijenti mogu se koristiti jeftini raunari sa snanim procesorima. Nedostatak je da je poslovna logika integrisana na klijentu. Promjena poslovne logike znai
156
instalisanje nove verzije aplikacije na svim klijentima. Velika je mogunost rada sa zastarjelim podacima. Ako sa vremenom aplikacija postane spora (zbog koliine podataka), treba promijeniti sve klijente. Razvoj velike aplikacije sa vremenom postaje vrlo kompleksan (sav programski kod je na klijentu). Tanki klijent je onaj klijent kod koga se logika podataka nalazi na serveru. Osnovna namjena tankog klijenta je prikaz podataka. Veinom se koriste u poslovnim sistemima, a tipini primjer tankog klijenta je web pretraiva. Prednosti tankog klijenta su: promjena poslovne logike ne znai obavezno i promjenu u klijentskom dijelu aplikacije, promjena poslovne logike moe se obaviti centralizovano, raunari ne moraju imati veliku procesorsku snagu, ukoliko sa vremenom obrada postane spora (zbog koliine podataka) moe se jednostavno poveati snaga sredinjeg raunara. Kao tanki klijent moe se koristiti npr. web pretraiva (dobro definisano i svima dostupno). Smanjena je mogunost rada sa zastarjelim podacima (gotovo za svaku promjenu ide se na server). Manja je kompleksnost razvoja velikih aplikacija (kod je podijeljen na serverski dio i klijentski dio). Nedostaci su: veliko optereenje glavnog raunara, a to znai skupi glavni raunar. Ukoliko se kao klijent koristi web pretraiva moraju se potivati njegova ogranienja.
157
esto se vri podjela u tri nivoa, i to: klijent - GUI (u web aplikaciji to je web pretraiva), server aplikacija odnosno BLL (npr. web servis) i baza podataka (npr. SQL Server).
Klijent (mikroraunar) Server aplikacija (mikroraunar) Server BP (mikroraunar, mali raunar ili veliki raunar)
Prezentaciona logika
Klijent (mikroraunar)
Aplikaciona logika
Prezentaciona logika
Server aplikacija (mikroraunar)
Aplikaciona logika
Server BP (mikroraunar, mali raunar ili veliki raunar)
Aplikaciona logika
158
Dvoslojne K/S arhitekture sa debelim klijentima
Aplikacije gdje se aplikativna obrada izvodi na klijentu sa COTS (Commercial Off-The Shelf Software) programskom podrkom. Aplikacije koje zahtjevaju raunarsko zahtjevne obrade podataka (npr. vizualizacija podataka interaktivno ili u izvjetajima). Aplikacije sa relativno vrstom krajnje - korisnikom funkcionalno-u, koritene u okolini gdje je dobro uspostavljeno upravljanje sistemom. Aplikacije velikog opsega sa stotinama ili hiljadama klijenata. Sistemi u kojima su i podaci i aplikacije promjenljivi. Aplikacije u kojima se integriu podaci iz viestrukih izvora.
Primjer 1: Sa arhitekturom klijent-server potrebno je napraviti aplikaciju koja e prikazivati [Fertalj & Kalpi, 2005]: kupce, prodavae i datume narudbi, nazive artikala, jedininu cijenu i koliinu za pojedinu narudbu, ukupnu koliinu i ukupnu vrijednost narudbe, treba prikazivati zadnjih 20 narudbi. Rjeenje sa debelim klijentom glasi: na klijentu napraviti SQL upit kojim se obuhvataju podaci o zadnjih 20 narudbi, na klijentu napraviti SQL upit kojim se obuhvataju detalji za zadnjih 20 narudbi, kad se promjeni narudba proi kroz sve detalje i ispisati one koje pripadaju trenutnoj narudbi. Usput raunati zbirne vrijednosti. Rjeenje sa tankim klijentom je: na klijentu pozvati stored proceduru koja vraa podatke o zadnjih 20 narudbi, kad se promjeni trenutna narudba pozvati stored proceduru koja vraa detalje trenutne narudbe i zbirne vrijednosti. Primjer 2: Promjene zahtjeva navedenih u primjeru 1: korisnik se nakon mjesec dana rada aplikacije, naravno, predomislio i eli da se prikazuje zadnjih 50 narudbi. Ispunjenje promjene zahtjeva se sastoji u slijedeem. Na debelom klijentu treba promijeniti SQL upite u izvornom kodu, prevesti ga u novu izvrnu opciju te dostaviti aplikaciju korisnicima (sporo i skupo). Na tankom klijentu treba na serveru promijeniti samo pohranjenu proceduru za dohvat narudbi (brzo, manje od pet minuta, i jeftino). Primjer 3: Rjeenje razmatranog primjera u vieslojnoj arhitekturi sadri slijedee nivoe, slika 9.5: 1. Prezentacioni sloj GUI, koji slui za prikupljanje informacija od korisnika, vrenje osnovnih provjera unijetih podataka, njihovo slanje sloju poslovne logike, primanje rezultata od sloja poslovne logike i prezentaciju dobijenih rezultata korisniku u razumljivom formatu. Ovaj sloj sainjavaju HTML, DHTML, Win32 aplikacije, klijent-server skriptovanje, Java apleti, ActiveX kontrole, itd. Prezentacioni sloj se moe generisati generatorom koda npr. Visual Studio.NET 2003, u programskom jeziku Visual C (C#);
159
2. Sloj poslovne logike BLL, koji je namjenjen za primanje podataka od prezentacionog sloja, interakciju sa slojem za pristup podacima radi procesiranja podataka i slanje obraenih informacija prezentacionom sloju. Ovaj sloj obezbjeuje poslovna pravila i servise koji pomau tokom pisanja skalabilnih aplikacija (npr. Web servise, transakcione i servise komponenti, asinhrone i servise redova, serverska skriptovanja). Ovi servisi su vrsto integrisani jedan sa drugim i sa OS i dostupni su preko komponentnog modula (COM+). Sloj poslovne logike BLL se moe generisati generatorom koda npr. Visual Studio.NET 2003, u programskom jeziku C#; 3. Sloj pristupa podacima DAL, koji direktno ostvaruje interakciju sa podacima koji, obino, egzistiraju u BP kao to su SQL Server ili ORACLE. Ovaj sloj slui za smjetanje, pronalaenje i odravanje podataka, kao i za integritet podataka. Pristup podacima preko Windows DNA se naziva Universal Data Access (UDA). UDA je skup modela sistemskog i aplikacionog nivoa, koji se zovu OLE-DB, ADO i RDO. Sloj pristupa podacima DAL se moe generisati generatorom koda npr. LLBLGen, u programskom jeziku C#.
COM+
Prezentacioni sloj
DHTML, Forme
Sistemski servisi
Administracija
Mreni servisi
Alati
Zatita
Web server IIS Transakcije MTS
Osnovni servisi
Slika 9.5. Arhitektura Windows DNA (Distributed interNet Aplication architecture). Tok izrade aplikacije u vieslojnoj arhitekturi je slijedei. Prezentacioni sloj GUI (generator koda Visual Studio.NET 2003 u programskom jeziku C#). Prema pravilima vieslojnog programiranja na prezentacionom sloju (formi) koristi se sloj poslovne logike (b-klasa). U razmatranom primjeru treba konstruisati b-klasu i ispisati podatke u gridu. U konstruktoru b-klase se uitavaju podaci o narudbama. Nakon toga se okine event, na kojem se prikazuju podatci o detaljima narudbi. Programski kod glasi: private void FormLastOrders_Load(object sender, System.EventArgs e){ // Konstruisi bklasu _bLastOrders = new BLastOrders(_connectionString); // Postavi DataSource na oba grida 1.
160
dataGridOrders.DataSource = _bLastOrders.OrdersEntityCollection; dataGridOrderDetalis.DataSource = bLastOrders.OrderDetailsEntityCollection; // Ispii detalje trenutno selektirane narudbe dataGridOrders_CurrentCellChanged(sender, e); } Kod promjene selektirane narudbe treba osvjeiti podatke o detaljima. To se radi tako da se pozove pripadajua metoda u b-klasi (SelectOrderDetails). Ta metoda dohvata detalje neke narudbe, a usput rauna i zbirne podatke (ti podaci su dostupni preko property-a b-klase). Programski kod glasi: private void dataGridOrders_CurrentCellChanged(object sender, System.EventArgs e) { // Dohvati podatke o trenutno selektiranoj narudbi _bLastOrders.SelectOrderDetails(Convert.ToInt32(dataGridOrde rs[ dataGridOrders.CurrentRowIndex, 0])); // Ispii zbirne podatke na formu textBoxTotalPrice.Text = _bLastOrders.TotalPrice.ToString("C"); textBoxTotalQuantity.Text = _bLastOrders.TotalQuantity.ToString(); } 2. Sloj poslovne logike BLL (generator koda Visual Studio.NET 2003 u programskom jeziku C#). Bie naveden primjer konstruktora u b-klasi (sloju poslovne logike). Sloj poslovne logike treba paljivo definisati, tako da GUI slui samo za prikazivanje podataka, a sve vee obrade i rad sa bazom moraju se odvijati u b-klasi. U razmatranom primjeru uz bklasu postoji i sloj pristupa podacima (DAL) prije same baze podataka. U b-klase se intenzivno koristi DAL, a iz priloenog koda se vidi da je programiranje znatno jednostavnije nego upotrebom SQL upita. Programski kod glasi: public BLastOrders(string connectionString) { // Konstruiranje adaptera za pristup bazi podataka _dataAccessAdapter = new DataAccessAdapter(connectionString); // Definiranje EntityCollection-a za narudbe _ordersEntityCollection = new EntityCollection(new OrdersEntityFactory()); SelectLastOrders(); // Definiranje EntityCollection-a za detalje narudbe
161
_orderDetailsEntityCollection = new EntityCollection(new OrderDetailsEntityFactory()); } Navedeni primjer sa dohvatom zadnjih 20 narudbi u b-klasi se moe promjeniti da se dohvati zadnjih 50 narudbi. Radi se o primjeru pristupa bazi podataka preko objekata. Mada se ne ini jednostavnim, u praksi ima mnoge prednosti u odnosu na pisanje SQL upita. Osnovna prednost je manja mogunost greke, kao i preglednost koda. Na slian nain bi se rijeio i dohvat detalja pojedine narudbe. Programski kod glasi: public EntityCollection SelectLastOrders() { // Isprazni trenutni sadraj _ordersEntityCollection.Clear(); // Narudbe treba sortirati prema datumu unatrag ISortExpression sorter = new SortExpression( SortClauseFactory.Create(OrdersFieldIndex.OrderDate, SortOperator.Descending)); // Definisanje dodatnih staza za dohvat podataka (treba dohvatiti podatke o kupcima i radnicima) IPrefetchPath2 path = new PrefetchPath2((int)EntityType.OrdersEntity); path.Add(OrdersEntity.PrefetchPathCustomers); path.Add(OrdersEntity.PrefetchPathEmployees); // Dohvat podataka iz baze (uz koritenje sortera i dodatnih staza za dohvat) _dataAccessAdapter.FetchEntityCollection(_ordersEntityCollec tion, null, 20, sorter, path); // Vrati podatke dohvaene iz baze return _ordersEntityCollection; } 3. Sloj pristupa podacima DAL (generator koda LLBLGen u programskom jeziku C#). Ovaj sloj slui za pristup bazi podataka (DAL); Programski kod se generie pomou generatora koda; DAL se u ovom primjeru dijeli na dva dijela: DALGeneric - objekti za pristup bazi koji su isti za sve baze i DALDBSpecific - objekti za pristup bazi koji su specifini za pojedine baze podataka; Prednosti rjeenja upotrebom generatora programskog koda: mogunost pristupa bazi podataka preko objekta (nije potrebno znanje SQL-a), mogunost promjene baze podataka, nema velikog gubljenja vremena na pisanje koda za pristup bazi podataka, manja mogunost greke, itd.
162
Product Access 2002 Cache DB2 eXtremeDB FileMaker FoxPro Informix Matisse Objectivity/DB OpenInsight Oracle 8i, 9i
Developer Microsoft InterSystems Corp. IBM McObject FileMaker Microsoft IBM Matisse Software Objectivity Revelation Software Oracle
License
DB Type
Commercial Relational Commercial Post-relational Commercial Relational Commercial Navigational Commercial FileMaker Commercial Relational Commercial Relational Commercial Object-oriented Commercial Object-oriented Commercial Multi-valued Commercial Relational
163
SQL Server 2000 Sybase ASE 12.5 UniData UniVerse Versant enJin
Commercial Relational Commercial Relational Commercial Nested relational Commercial Nested relational Commercial Object-oriented
10.2. Normalizacija
Normalizacija, odnosno tehnika organizovanosti atributa, je postupak strukturiranja sheme relacione baze podataka tako da se ukloni to vie neodreenosti (nekonzistentnosti). Stepen normalizacije (normalizovani oblici) se poveava od 1NO do 5NO. Veina dizajnera se zaustavlja na 3NO ili na BCNO (Boyce-Codd NO). Formalne definicije normalizovanih oblika glase: a) Relacija R je u prvom normalizovanom obliku ako svi njeni atributi imaju samo "atomske" vrijednosti. Relacija u 1NO ne moe opisivati entitete ili veze u sistemu koji imaju vieznane atribute, ne moe za atribut imati neku drugu relaciju. b) Relacija R je u prvom normalizovanom obliku ako je bilo koji podskup neprimarnih atributa funkcionalno zavisan od kljua. c) Relacija R je u prvom normalizovanom obliku ako izmeu kandidata za klju i ostalih neprimarnih atributa postoje slijedei tipovi preslikavanja: 1:1, 1:M, C:1 i C:M. Relacija R je u drugom normalizovanom obliku, ako je u prvom, i ako svi njeni neprimarni atributi potpuno funkcionalno zavise od svih kandidata za kljueve. Relacija R je u treem normalizovanom obliku, ako je u drugom, i ako ne sadri tranzitivne zavisnosti neprimarnih atributa od kandidata za klju. Relacija R je u BCNO ako je svaka determinanta kandidat za klju. Determinanta je svaki atribut, prost ili sloen, od koga neki drugi atribut potpuno funkcionalno zavisi. Relacija R (X, Y, Z) je u etvrtom normalizovanom obliku ako postojanje netrivijalne vieznane zavisnosti X Y uslovljava postojanje funkcionalne zavisnosti X A za svaki atribut A relacije R.
Relacija R je u petom normalizovanom obliku ako i samo ako se svaka zavisnost spajanja u relaciji R moe pripisati kandidatu za klju. Informatikim argonom reeno, normalizacija se svodi na ispunjenje tzv. "relacione zakletve" [Finkelstein, 1989]:
164
klju - 1NO: nema ponavljajuih grupa, definisan primarni klju, cijeli klju - 2NO: svi nekljuni atributi u potpunosti zavisni o itavom PK, nita drugo nego klju - 3NF: svaki nekljuni atribut je neposredno zavisan samo o PK, BCNO: svi atributi koji odreuju druge atribute ine mogue kljueve. Prevoenje modela i normalizacija uporabom CASE alata se odvija slijedeim redoslijedom: 1. Automatizovano dodjeljivanje stvarnih tipova podataka konkretnog SUBP; 2. Stvaranje relacija (tabela) za entitete nadtipa i podtipa; 3. Automatizovana migracija kljua i prepoznavanje tzv. viseih veza (dangling relationships), odnosno veza na tabele koje nisu ukljuene u generisanje modela; 4. Veina CASE alata normalizira u 1NO: zamjena veza vie-prema-vie asocijativnim entitetima i zamjena vieznanih atributa entitetima; 5. Vii normalizovani oblici: problem prepoznavanja djelominih i tranzitivnih zavisnosti; 6. Generisanje programskog koda okidaa (trigera). Prije poetka kodiranja obavlja se ogranieno uvoenje konzistentnosti i ugaanje baze podataka, zbog poboljanja elastinosti i poboljanja performansi, gdje zahvat moe rezultirati u logiki model odreenim brojem intervencija. Denormalizacija se svodi na ogranieno i kontrolisano naruavanje NO.
10.3. Denormalizacija
Zamjenici (surogati) kljueva su kljuevi sa samopoveavajuim vrijednostima (serial), koji se umeu ispred kljua sastavljenog od veeg broja atributa (npr. 3). Na originalni klju postavlja se jednoznaan (unique) kompozitni indeks. Teorijski se ne preporuuje za asocijativne entitete, koji naslijeuju kljueve svojih roditelja, jer se time gubi smisao identifikacione veze. Praktino, zamjenika kljua treba ugraditi kada je relacija (tabela) u koju se ugrauje referensirana iz drugih relacija, a to nije u suprotnosti sa poeljnim redundantnim vezama. Primjer 1: @IdRadnogMjesta = @IdOrgJedinice, @IdZanimanja RadnoMjesto = @IdRadnogMjesta Zaposlenje = @IdOsobe, @IdRadnogMjesta, @DatZaposlenja, ... .
Primjer 2: Drzava 1:N Mjesto 1:N Osoba, pri emu je Mjesto = @IdDrzave, @IdMjesta, ... .
165
isti dizajn je dosljedna ugradnja zamjenika kljua sa samopoveavajuim vrijednostima u sve tabele (relacije) baze podataka, ime se pojednostavljuje ugradnja. Dolazi do umnoavanja kljueva, zamjenik postaje primarni a originalni postaje alternativni klju, i dolazi do gubitka izvorne vrijednosti stranog kljua. Dijeljenje relacija je smjetanje rijetko koritenih atributa u posebnu relaciju. Udruivanje relacija je uklanjanje pojedinih relacija stapanjem atributa obine veze 1:1 ili udruivanje nadtipa sa podtipovima kardinalnosti 1:1, pod uslovom da su sline strukture i sadraja. Uvoenje konzistentnosti je dodavanje atributa za uvanje izvedenih vrijednosti. To mogu biti atributi uvanja za izvedenu vrijednost koja se moe izraunati agregiranom funkcijom (npr. iznos rauna kao suma iznosa stavki) ili oznake zadnje vrijednosti nekog stanja kada se vrijednosti pojedinih stanja nalaze u relaciji sa velikim brojem zapisa (torki), npr. stanje skladita. Dodavanje atributa uvanja moe biti za redundantne vrijednosti koje se inae dobijaju sloenim i/ili sporim upitima (zadnje zaposlenje + zadnji izbor u zvanje + zadnje kolovanje) ili dodavanje atributa kao to su zastavice za "trajno" oznaavanje zapisa. Podrazumijeva se da se denormalizacija obavlja samo na mjestima gdje je to stvarno nuno i na takav nain da ne ugroava integritet podataka, odnosno aplikativno upravljanje integritetom.
166
[ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ]. Upravljanje referensijalnim integritetom okidaima (triggers) je elastiniji pristup, koji omoguava ugradnju i ostalih postupaka prilikom unosa/izmjene/ brisanja torki (vidjeti taku 10.6). Aplikaciono upravljanje integritetom su postupci unosa/izmjene/brisanja podrani programskim kodom. Javlja se problem umnoavanja programskog koda, naroito kod hibridnih sistema (4GL + GUI). Mjeovito upravljanje referencijalnim integritetom je kombinacija navedenih mogunosti, sa tim da neposredno upravljanje referencijalnim integritetom od strane SUBP (DRI) ima prednost. Mogui problemi su viestruki. Neki atribut stranog kljua moe biti primarni atribut. Pokuaj auriranja na nul-vrijednost stranog kljua koji je dio primarnog kljua u suprotnosti je sa pravilom entitetskog integriteta. Prilikom auriranja stranog atributa koji je ujedno i primarni atribut ne smije se naruiti jedinstvena vrijednost kljua. Postupak kaskadnog auriranja ili brisanja torki treba provesti rekurzivno, da bi se referencijalni integritet ouvao u svim dijelovima baze podataka, a ne samo na mjestu obrade.
167
Minimizaciji nul-vrijednosti treba posvetiti nunu panju. Moe se pojaviti problem neodreenih vrijednosti agregatnih funkcija, problem operacija sa nulvrijednostima, gdje opisna polja mogu da sadre zahtijevanu vrijednost + pretpostavljenu vrijednost, npr. SELECT AVG(polje), gdje polje ima/nema nulvrijednosti. Moe se pojaviti problem vanjskih spojnih upita, gdje su strana polja posebne vrijednosti u ifrarnicima, npr. 0-nepoznata vrijednost, 999-nepostojea vrijednost. Ubrzanje upita omoguava: analiza plana izvoenja (Execution Plan) i odabir poeljnog plana, npr. SELECT ... OPTION (FORCE ORDER), primoravanje koritenja odreenog indeksa, npr. SELECT ... WITH (INDEX(index, index...)), primoravanje nekoritenja indeksa primjenom nekodljive funkcije nad poljem nad kojim se uobiajeno koristi indeks, npr. WHERE NULLIF ( polje, ) = ... , ostale opcije, npr. SELECT ... OPTION (FAST n_rows). Punjenje baze podataka se vri razliitim vrstama datoteka/relacija, koje mogu biti: matine, gdje dodani zapis ostaje zauvijek u sistemu, a moe se mijenjati, npr. Kupac, Artikl, Predmet, OrgJedinica, transakcione (prometne), predstavljaju zapise poslovnih dogaaja sa ogranienim vijekom, a uklanjanje zapisa se vri uz arhiviranje, npr. Racun, Prijavnica, ifarnici, odnosno statiki podaci koji se koriste od razliitih aplikacija radi ouvanja konzistentnosti podataka i poboljanja performansi, npr. Mjesto (potanski brojevi), StatusNecega, dokumentacione, odnosno kopije istorijskih podataka za laki dohvat i pregled bez regenerisanja dokumenata, arhivske, koje su uklonjene iz medija za direktni (on-line) pristup, dnevnici (audit, log), koji predstavljaju evidenciju pristupa i promjena podataka. Fiziku raspodjelu podataka odreuju faktor blokiranja (blocking factor), koga odreuje broj logikih zapisa koji se obrauju jednim itanjem (fiziki zapis). Ovaj faktor uobiajeno je odreen i automatski podeen, ali se moe i runo podeavati. Distribucija podataka je raspodjela pojedinih relacija, zapisa i/ili polja u razliite fizike BP ili razliite fizike segmente BP, npr. odvajanje matinih datoteka i ifarnika od transakcionih relacija. Replikacija podataka predstavlja umnoavanje relacija, zapisa i/ili polja u razliite fizike BP, npr. replikacija ifarnika izmeu baze podataka na serveru i BP debelog klijenta.
168
Smjetaj fizikih datoteka obezbjeuje poveanje sigurnosti i brzine pristupa odvajanjem SUBP, prostora za podatke, prostora za voenje evidencije i rezervnih kopija na razliite fizike ureaje. Primjer: Dvije fizike jedinice, etiri logike podjele: C:\...\binn\MSSQL.exe D:\...\data\*.mdf E:\...\log\*.log F:\...\backup\*
169
170
4. Izlaz, pri naputanju forme ili kada kursor napusti blok, slog ili polje; 5. Pritisak na taster, kada korisnik pritisne funkcionalni taster. Moe se izdvojiti jo jedna grupa trigera, koja se ne odnosi na naprijed navedene sluajeve: 6. Trigeri imenovani od korisnika, obini trigeri ili podtrigeri, koji se pozivaju iz drugih trigera. Trigeri se mogu definisati na tri nivoa forme, i to: trigeri na nivou polja, kada su udrueni sa odreenim poljem, trigeri na nivou bloka, kada su udrueni sa odreenim blokom i trigeri na nivou forme, kada su udrueni sa cijelom formom. Na svakom nivou postoje odreeni trigeri koji se mogu primjeniti. Na nivou polja se mogu primjeniti slijedei trigeri: prije polja, poslije promjene, poslije polja, trigeri za tastere i trigeri imenovani od korisnika. Na nivou bloka se mogu primjeniti slijedei trigeri: prije bloka, prije pretraivanja bloka, poslije bloka, prije sloga, poslije pretraivanja sloga, trigeri prihvatanja, prije brisanja, poslije brisanja, prije unosa, prije auriranja, poslije auriranja, poslije sloga, trigeri za tastere i trigeri imenovani od korisnika. Na nivou forme se mogu primjeniti slijedei trigeri: prije forme, poslije forme, trigeri za tastere i trigeri imenovani od korisnika. Svaki tip trigera se moe definisati na njegovom nivou ili bilo kojem viem nivou. Na primjer, triger "poslije promjene" se moe definisati na nivou polja, bloka ili forme. Podruje rada trigera je odreeno nivoom na kojem je definisan. Na primjer, triger "poslije promjene" definisan na nivou bloka e se primjenjivati na svako polje bloka, odnosno izvravae se odmah nakon to korisnik promjeni vrijednost u bilo kojem polju bloka, a ne samo kada korisnik naputa blok. Triger "poslije promjene", definisan na nivou forme, e se primjenjivati na svako polje forme.
33
171
2. Izabrati CREATE da se prikae TRIGGER STEP prozor, gdje se mogu unijeti naredbe koje treba izvriti. Mogue je izvriti modifikaciju postojeeg trigera, brisanje trigera ili promjenu njegovog imena. Pomenuti TRIGGER STEP prozor se koristi da se napiu ili promjene koraci trigera, a TRIGGER STEP ATTRIBUTES prozor da se kontrolie ta se dogaa kada korak uspije ili ne. Triger se sastoji od serije koraka, koji se obino, ali ne uvijek, izvravaju u nizu. Korak se sastoji od jedne SQL naredbe, SQL naredbe generatora aplikacija ili korisnike izlazne naredbe. Za definisanje koraka trigera, potrebno je: 1. Seq#: upisati redoslijed za normalno izvravanje koraka; 2. Label (oznaka): ako se eli drugaiji pristup koraku u trigeru, u ovoj rubrici se upisuje oznaka koja to omoguava; 3. Podruje trigera: u ovu rubriku se upisuje SQL naredba ili SQL naredba generatora aplikacija, koja e se izvravati u ovom koraku; 4. Poruka ako triger ne uspije: u ovu rubriku se upisuje poruka koja e se prikazati ako korak ne uspije; 5. Za definisanje atributa koraka trigera (neobavezno), potrebno je izabrati ATTRIBUTES da se prikae TRIGGER STEP ATTRIBUTES prozor. Kada je izvreno uspjeno definisanje koraka trigera, za dalji rad postoje dvije mogunosti: da se izvri dalje pomjeranje u slijedei korak (NEXT STEP) ili da se kreira novi korak izborom CREATE i ponovi postupak. Atributi koraka trigera (korak 5) saoptavaju: ta se deava kada korak uspije ili ne uspije ili koliko memorije se dodjeljuje korisniku. Definisanje atributa koraka trigera se vri na slijedei nain: 1. Abort trigger when step fails (prekini triger kada korak ne uspije): ako je ovaj prekida odabran, a oznaka prekida nije specifirana, neuspjeh koraka e zaustaviti izvravanje trigera; 2. Reverse return code (obrnuto javljanje): ako je ovaj prekida izabran, normalni kriterijum za uspjeh ili neuspjeh se obre; 3. Return success when aborting trigger (javi uspjeh kada se prekine triger): ovaj prekida ima znaenje samo ako je izabran i Abort trigger when step fails (prekini triger kada korak ne uspije); 4. Separate cursor data area (odvojeni prostor memorije): svakom koraku trigera je dodjeljen vlastiti prostor u radnoj memoriji raunara; 5. Success and Failure labels (oznake uspjeha i neuspjeha): koraci trigera se normalno izvravaju u nizu. Meutim, mogu se koristiti oznake koraka da se promjeni redoslijed izvravanja.
172
Odreivanje uspjeha i neuspjeha trigera je prilino sloeno i zbog ogranienog prostora nee se dalje razmatrati u ovoj knjizi.
173
rad sa varijablama, i izvoenje naredbi operativnog sistema. SQL naredbe generatora aplikacija se unose neposredno u TRIGGER STEP prozor. Jedan korak trigera ukljuuje jedan iskaz (naredba + argument ili funkcija). Sve SQL naredbe generatora aplikacija poinju znakom #. Postoje etiri naredbe koje se mogu koristiti u koracima trigera, i to: #EXEMACRO, #COPY, #ERASE i #HOST. #EXEMACRO naredba se koristi za izvravanje serije akcija u formi. Akcije mogu biti korisnike funkcije (kao da korisnik pritiska odreene tastere), ili specijalne funkcije koje se mogu izvoditi samo sa trigerima. Makroserija naredbi se koristi da: olaka korisniku sloeno ukucavanje ili esto ponavljanje, kontrolie tok aplikacije (npr. usklaivanje slogova iz dva ili vie blokova forme), osigurava da se neke akcije izvode uvijek u nizu i obezbjedi pomo (npr. pozivanjem druge forme da se proita traeni podatak). Kada generator aplikacija izvrava korak trigera koji sadri makro, on izvodi sve funkcije po redoslijedu. Na primjer, naredba: #EXEMACRO NXTBLK; NXTSET; PRVBLK; radi kao da je korisnik pritisnuo tastere <Next Block>, <Next Set of Record> i <Previous Block> navedenim redoslijedom. #COPY naredba se moe koristiti u koraku trigera da se kopiraju konstante, vrijednosti polja, globalne varijable ili sistemske varijable sa izvornog na eljeno mjesto. I izvorno i eljeno mjesto prate kljunu rije #COPY. Na primjer, slijedea naredba dodjeljuje sadraj NARUDBA.BRNARUDBE polja varijabli GLOBAL.ID: #COPY NARUDZBA.BRNARUDZBE GLOBAL.ID #ERASE naredba se upotrebljava za brisanje vrijednosti globalne varijable, ije ime dolazi iza kljune rijei #ERASE. Na primjer, slijedea naredba brie GLOBAL.ID varijablu iz prethodnog primjera: #ERASE GLOBAL.ID #HOST naredba se koristi u koraku trigera da izvri neku naredbu operativnog sistema. Iza naredbe #HOST se stavlja niz naredbi u navodnicima ili ime polja, odnosno varijable koja sadri niz naredbi. Na primjer, slijedea naredba u operativnom sistemu UNIX tampa datoteku dat1: #HOST 'lpr -b dat1' Korak trigera moe privremeno izai iz generatora aplikacija u neki drugi napisani program. Takvi izlazi se mogu koristiti da se obrade podaci iz polja relacija i formi, prikau poruke i izvode druge radnje koje su izvan domaaja SQL naredbi i SQL naredbi generatora aplikacija.
174
Korisnike izlazne naredbe su mnogo komplikovanije za pisanje i izvoenje od SQL naredbi i SQL naredbi generatora aplikacija, pa se koriste samo za one radnje koje ove triger naredbe ne mogu izvriti, kao npr.: izvoenje sloenih provjera polja, izvoenje sloenih rauna, izvoenje auriranja koja iniciraju vrijednosti u formi i optimiziranje izvoenja aplikacija. Korisniki izlazi se mogu pisati u bilo kojem od nekoliko programskih jezika, ukljuujui C, COBOL, FORTRAN, PL/1, Pascal, Ada, a kod najnovije verzije SUBP ORACLE 9i i u programskoim jezicima Java, XML i HTML. Kada se napie program korisnikog izlaza, potrebno ga je ispraviti, pretkompajlirati, kompajlirati i povezati sa trigerom.
Postupak implementacionog projektovanja jednog trigera baze podataka, pomou alata softverskog inenjeringa Designer-a 2000, ORACLE, prikazan je na slikama 10.1, 10.2 i 10.3. Rije je o trigeru PP_Stav_Nal_INS, koji je definisan nad shemom relacije (tabele) Stav_Nal. Hijerarhijski navigator objekata je prikazan na lijevoj strani ekranske forme, slika 10.1. Vidljivo je da je triger PP_Stav_Nal_INS direktno podreen tabeli Stav_Nal. Na desnoj strani ekranske forme, ista slika, prikazano je tijelo trigera, iskazano putem neproceduralnog jezika PL/SQL. Cjelokupni programski kod trigera predstavlja objekat, odnosno PL/SQL program, pod nazivom PP_Stav_Nal_INS, koji je definisan u okviru klase Trigger Definitions.
Slika 10.1. Postupak implementacionog projektovanja jednog trigera baze podataka u okviru Designer-a 2000.
175
Na slici 10.2 je prikazana ekranska forma za zadavanje naziva, opisnog polja "svrha" i naziva PL/SQL programa, pridruenog trigeru.
Slika 10.2. Postupak implementacionog projektovanja jednog trigera baze podataka u okviru Designer-a 2000. Slijedea ekranska forma, prikazana na slici 10.3, omoguava definisanje: dogaaja koji pokree izvrenje trigera, trenutka okidanja trigera, kao i to da li je rije o trigeru koji se pokree na nivou polja (iskaza), ili na nivou sloga (torke).
Slika 10.3. Postupak implementacionog projektovanja jednog trigera baze podataka u okviru Designer-a 2000.
176
Ako se za dogadjaj izabere operacija UPDATE, tada se otvara posebna ekranska forma, putem koje se zadaje skup obiljeja tabele (relacije), ija modifikacija dovodi do pokretanja trigera. Ukoliko triger treba da sadri logiki (WHEN) uslov, ekranska forma "When" omoguava zadavanje takvog uslova.
Poliuk E. Jaroslav: Projektovanje informacionih sistema IDK NUMBER(6) NOT NULL, STN VARCHAR2(17) NOT NULL, OSN VARCHAR2(17)); CREATE TABLE STAV_NAL (IDS NUMBER(6) NOT NULL, BRN NUMBER(6) NOT NULL, IDR NUMBER(6) NOT NULL, STA VARCHAR2(17) NOT NULL, KOL NUMBER(12,4) DEFAULT 0 NOT NULL);
177
Slika 10.4. Izvod iz datoteke koja sadri SQL naredbe za kreiranje odgovarajuih relacija (tabela).
178
Slika 10.6. Izgled prethodne ekranske forme, u trenutku kada se kursor nalazio na polju za unos identifikacionog broja kupca (IDK). Izgled ekranske forme, u trenutku kada se kursor nalazio na polju za unos identifikacionog broja kupca (IDK) i kada je pozvana lista izbora vrijednosti identifikacionog broja kupca, prikazan je na slici 10.6. U okviru ove, kao i svih drugih lista izbora u ovom modulu, korisnik moe da zada dodatne kriterijume za prikaz izvoda iz cjelokupne evidencije (u ovom sluaju cjelokupne evidencije kupaca). Izgled ekranske forme za formiranje naloga za otpremu, u trenutku kada se kursor nalazio na polju za unos identifikacionog broja robe (IDR) i kada je pozvana lista izbora vrijednosti identifikacionog broja robe, je prikazan na slici 10.7. U ovoj listi vrijednosti, mogu se nai samo podaci o robi koja je evidentirana na zalihama onog skladita, ciji je identifikacioni broj naveden u zaglavlju naloga. U ovom primjeru, rije je o skladitu sa identifikacionim brojem 10.
179
Slika 10.7. Prikaz ekranske forme za formiranje naloga za otpremu. Logika izvravanja interaktivnog modula naloga za otpremu jeste da korisnik, nakon pokretanja programa i prijavljivanja na server BP, moe da selektira, zadaje, modifikuje ili brie podatke o nalogu za otpremu, putem prikazane ekranske forme. Ti podaci se smjetaju u radnu zonu programa. U sluaju da je putem ekranske forme izvreno auriranje podataka u radnoj zoni programa, korisnik je obavezan da pokrene postupak auriranja podataka u BP, izborom funkcije Save (Sauvaj), npr. pokretanjem opcije menija Action/Save ili aktiviranjem odgovarajue ikone. U suprotnom treba da odustane od izmjena podataka. Postupak auriranja se sprovodi automatski, putem jedne transakcije, a korisnik e, na kraju izvoenja transakcije, biti obavjeten o efektima njenog sprovoenja. Za svaku novododanu torku u radnoj zoni programa, u okviru transakcije e automatski biti formirana jedna SQL INSERT naredba. Isto tako, za svaku modifikovanu torku u radnoj zoni programa, transakcija e sadravati jednu UPDATE naredbu, dok e za svaku torku u radnoj zoni programa, koja je oznaena kao izbrisana, transakcija sadravati jednu DELETE naredbu.
180
R P U V L O
redovne studije paralelne studije studije uz rad vanredne studije paralelne studije sa pravom prehrane studije za line potrebe
DA NE NE NE DA DA
Primjer jedinstvene ifre: Jedinstveni matini broj akademskog graanina (JMBAG) je jedinstveni broj u sistemu koga student dobija prilikom upisa na studije i zadrava sve do kraja svog studija. Ako se isti student upie na dvije ili vie ustanova
181
uvijek zadrava JMBAG koji je dobio na prvoj ustanovi. Radnici u ustanovama ne unose taj podatak, ve se on automatski generie. JMBAG ima deset brojeva podijeljenih u dvije grupe, te kontrolni broj (deseti). Prva etiri broja oznaavaju matinu ustanovu vlasnika. Slijedeih 5 brojeva su oznaka vlasnika u ustanovi (matini broj vlasnika ili se generie redoslijedom). Unutar ustanove JMBAG i matini broj (broj indeksa) su takoer jedinstveni. Broj kartice se generie automatski, a u sebi sadri 6 grupa brojeva: (601983) 11 (0036324986) 0 A BC D E A - jedinstveni broj u meunarodnom kartinom poslovanju (IIN), glasi 601983, i prema meunarodnom standardu ISO/IEC 7812 na jedinstven nain identifikuje Studentsku karticu u meunarodnom sistemu kartinog poslovanja, B - oznaka vrste kartice (1 broj) - npr: 1 - student i 4 - privremena kartica, C - redni broj kartice koju je student dobio (1 broj), D - JMBAG (10 brojeva), E - Kontrolni broj kartice (1 broj).
182
Slika 10.8. Primjer strukture rjenika podataka. Na slici 10.9 je prikazana praktina realizacija relacija iz sastava Rjenika podataka. Meta modeliranje moe korisno posluiti za opis poslovnih sistema i funkcija poslovnog sistema. Na slici 10.10 je predstavljen strukturirani prikaz (meta model) jednog poslovnog sistema, na slici 10.11 strukturirani prikaz (meta model) za primjer Narudba, na slici 10.12 strukturirani (meta model) aplikacije Prodaja i na slici 10.13 je prikazan primjer ekranske forme aplikacije nad meta modelom.
183
Slika 10.9. Primjer praktine realizacije rjenika podataka. Org cjelina Hijerar. (rad.mj) Osoba Propis Opis procesa Zakon Vrsta dogaaja
Organiz. Pravni Inform. Finans. Materij.
Vrsta dokumenta
Osoba na dok.
Plan
Doga. na dok.
Dokument
Dogaaj
Pravna osoba
Fizika osoba
***
Vrsta sredstva
Sastavnica sredstva
Svojstvo
Sredstvo
Svojstvo sredstva
184
Primjer: Narudba. Narudba MBB-Nabava za osnovno tehniko sredstvo prema preduzeu IMB Br. xxxx od xx.xx.200x. Veza: Ponuda preduzea IMB br. xxxx od xx.xx.200x. Narudbu izradio: Pero Odobrio njegov ef: Ivo Stavke: Raunar IMB estium: xx kom MBO, CPU, RAM, HDD, CDR, FDD, CASE Monitor 15 xx kom tampa xx kom Skener xx kom
MBB Nabava Pravilnik o poslovanju Opis poslova naruiv. Zakon Vrsta dogaaja Pravni Finansij. Menad.
ef
Narudbenica
Plan
Osoba
Narudba
Naruivanje
Pravna osoba
Fizika osoba
Sredstvo
Svojstvo sredstva
Poliuk E. Jaroslav: Projektovanje informacionih sistema Korisnik SifMje Zaglavlje SifZag VrstaDok VrDok StandSifPlac StandSifOtpr StandSifZag StandSifNap Napomena SifNap NacinPlac SifPlac Otprema SifOtp
185
Parametar SkracParam
Mjesto SifMje
Tarifa TarBroj
Dokument IdDok Partner SifPart SifMje VrDok IdPrethDok SifPart SifOtpr SifPlac SifZag SifNap
186
187
Strukturna karta
Pseudokod
Strukturna karta (Structure Chart) prikazuje modeliranje programske podrke na osnovu dijagrama toka podataka. Dijagram toka podataka prikazuje TA treba postii, a strukturnom kartom se izraava KAKO ostvariti te zahtjeve, slika 11.2. podatak (data couple) funkcija niz poziv ugraena funkcija (modul) iteracija selekcija
188
Prikaz hijerarhije programskih modula ukljuuje prenos podataka i upravljanja izmeu razliitih nivoa obrade, kao i prikaz naredne, ponavljajue i uslovne obrade. Primjer: Izvjetaj o poslovanju kompanije Gazda & ortaci, slika 11.3. Sistem izvjetaja o prodaji
datum zbir datum zbir
Uzmi datum
datum
Zapii izvjetaj
zbir
zbir
Ispii zbir
zbir
datum
vrijednost EOF
Uspjeh
Katastrofa
Zapii zaglavlje
Zapii red
datum EOF podatak
vrijednost
Raunaj zbir
podatak
itaj podatak
Pii podatak
Slika 11.3. Strukturna karta za DTP izvjetaja o poslovanju kompanije. Transformaciona analiza (transform analysis) je analiza promjene/ pretvaranja podataka. Primjenljiva je na sisteme koji imaju strukturu oblika ulazsredite-izlaz, tj. aplikacije sa jasno raspoznatljivim ulazima, sredinjom obradom i izlazima, koji se mogu prikazati linearnim tokom podataka, slika 11.4. Struktura dizajna, prikladna za ovakve sisteme, se sastoji od tri odgovarajua elementa (ulaz, obrada, izlaz), tj. podsistema: Get C, koji pribavlja podatak C, C I, koji obradom pretvara podatak C u podatak I, Put I, koji ispisuje rezultat I.
189
Slika 11.4. Ilustracija transformacione analize. Transakciona analiza (transaction analysis) je analiza izvrenja/obavljanja obrade. Primjenjuje se na sisteme sa jasno raspoznatljivim sreditima izvrenja, tj. sisteme u kojima se donosi odluka o tome koji e se proces koristiti za pretvaranje ulaza u izlaze (npr. interaktivne aplikacije). Ulaz se usmjerava nekom od modula obrade, a pojedini izlazi se kasnije koriste u daljnjoj obradi, slika 11.5. Primjer: sredite zaprima ulaz B, koji se usmjerava (kao B1, B2 ili B3) u odgovarajui proces (3, 4 ili 5), rezultirajui podatak (C1, C2 ili C3) koristi se kao izlazni tok C.
190
Sistemi koji nisu ni transformacioni ni transakcioni se obrauju na poseban nain. Najee se oblikuju plonim razlaganjem glavnog procesa u sastavne procese. Nadreeni proces mora pribaviti sve ulaze potrebne za obavljanje pojedinih podreenih procesa, te prikupiti i uvati proizvedene rezultate obrade, slika 11.6. Primjer:
Slika 11.6. Strukturna karta za DTP razloen plonom dekompozicijom. Stvarni sistemi su, obino, sloeni sistemi. Za oblikovanje programa se, najee, primjenjuje kombinacija osnovnih postupaka, slika 11.7.
191
192
Interfejsom moraju biti podrane razliite vrste ekranskih formi za izbor (npr. vertikalne i krune), uz mogunost brzog odabira (funkcionalnom tipkom ili slovom opcije). Horizontalna ekranska forma za izbor (menu bar) je uvijek vidljiva i lako dohvatljiva. Padajue (pull-down) i kaskadne ekranske forme su "nevidljive", ali se opcije daju grupisati. Skone forme (pop-up) nisu oigledne, skau na razliitim mjestima. Trake sa ikonama (toolbar) su vidljivi i lako se pamte, ali postoji problem ikona i skrivanja. Tipke za obavljanje standardnih funkcija moraju biti definisane paljivo i jednoznano, a unaprijed treba predvidjeti i one za aktiviranje dodatnih funkcija. Doslijednost interfejsa nuan je uslov koji programska oprema mora ispuniti. Standardni izgled ekranske forme prikazan je na slici 11.8..
Slika 11.8. Prikaz standardnog oblika ekranske forme. Ergonomija interfejsa. Polja ekranske forme moraju biti logiki grupisana. Unos se mora obavljati u redoslijedu kojim su polja fiziki poredana. Treba ustrajati na preglednosti podataka i minimizirati prekrivanje informacija (npr. u sluaju vie istovremeno prikazanih "prozora"). Interfejs mora imati ujednaene standardne poruke, zvune signale i upozorenja, kojima se prua dovoljna informacija, a korisnik nepotrebno ne optereuje. Poruke moraju biti jednostavne, precizne te zavisne o kontekstu. Izbjegavati raunarski argon
193
i skraenice. Mora biti ugraena interaktivna pomo zavisna o kontekstu. Prilikom izgradnje interfejsa treba ukloniti ili prevesti poruke na stranom jeziku (npr. one koje javlja SUBP) i izbjegavati strune izraze. Na slici 11.9 je prikazana ekranska forma jednog grafikog interfejsa.
Slika 11.9. Primjer grafikog interfejsa. Funkcionalnost interfejsa. Poeljno je da se traenje, unos i izmjena podataka obavljaju na istoj ekranskoj formi i na isti nain. Treba omoguiti prekid akcija koje predugo traju, pod uslovom da se tim prekidom ne naruava integritet podataka (npr. prekid selekcija velikog broja zapisa, prekid transakcija). U svakom dijelu obrade treba omoguiti odustajanje uz potvrdu korisnika da to stvarno eli (npr. brisanje). Upozorenja i potvrde prekida pohrane podataka treba provoditi samo ukoliko je stvarno dolo do promjene. Unesene podatke treba provjeravati to ranije, po mogunosti neposredno nakon promjene sadraja polja ekranske forme. Na polju za unos ifri treba omoguiti odabir iz suenog skupa podataka smjetenih u ifarnik. Suenje skupa treba da se moe obaviti na osnovu dijela tekstualnog opisa ifre, uz mogunost upotrebe meta znakova. Korisniku treba omoguiti pregled teksta koji e biti napisan u izvjetaj. Pregled na ekranskoj formi uklanja potrebu za ispisom na papiru i olakava prilagoavanje uslova za selekciju podataka. Dijelove aplikacije, kojima se obavlja masovni unos podataka,
194
potrebno je prilagoditi kretanju unutar jedne ekranske forme i minimizirati potreban broj tastera.
Slika 11.10. Primjer ulanavanja procedura. Rjeenje je da se na polju za unos vrijednosti stranog kljua omogui otvaranje prozora, sa listom za pregled i odabir zahtijevanog podatka, uz prikaz svih zapisa u odgovarajuoj relaciji. Takoe, treba omoguiti otvaranje liste za pregled (uz prikaz ogranienog skupa zapisa na osnovu prethodno postavljenog uslova), aktiviranje funkcije za unos ili izmjenu vezanog podatka i, na kraju, aktiviranje itavog modula za obradu vezanih podataka. Programska oprema mora slijediti poslovne procese. Gdje god je to mogue, treba smanjiti broj postupaka za jedan poslovni proces da korisnici ne bi ponavljali iste akcije. Primjer ulanavanja procedura je prikazan na slici 11.10.
195
P1 M1 F1 R1
P2 M2 F1 R1
Pi Mi Fi Ri
Pn Mn Fn Fn
Slika 11.11. Primjer modula pune i reducirane funkcionalnosti. Sistem nakon reorganizacije i kodiranja modula dobija hijerarhijski oblik (slika 11.12). To je hijerarhijski ekranski meni, proizvoljne dubine, nad izvedbenih programa, koji sadre udrueni glavni program Mj, (j) skupova standardnih funkcija, (j) reduciranih skupova funkcija te (j) skupova runo ugraenih funkcija, (j = 1, , ).
196
Hijerarhijski meni
197
5. Brisanje uitanog i prikazanog zapisa uz odgovarajue integritetske provjere i poruke. Brisanje se obavlja uz dodatnu potvrdu; 6. Pregledanje (eng. browsing) prethodno uitanih podataka: grupni pregled veeg broja uitanih zapisa u prozoru po redovima, po stranicama, skok na prvi/zadnji/n-ti zapis, pretraivanje liste podataka po dijelu naziva (filter) ili po elji koji moe odabrati jedan ili vie zapisa ili onemoguiti odabir. Standardno se prikazuju samo osnovni elementi zapisa (primarni klju i relevantni zavisni atributi); 7. Poredak (sort) zapisa koji se prikazuju: odreivanje poretka prije selekcije ili naknadni preraspored ve uitanih zapisa; 8. Ispisivanje izvjetaja (report): sadraj ispisa, trenutno prikazani zapis, svi uitani zapisi, format ispisa, odnosno osnovni podatci (ifra i naziv) ili svi podaci, odredite ispisa, npr. tampa, ekranska forma, datoteka (nova datoteka, dodavanje na kraj postojee datoteke); 9. Izlaz iz modula: sa prenosom informacija o odabranom zapisu (primarni klju ili cijeli zapis). Primjer: Uitavanje po uzorku [Fertalj & Kalpi, 2005]. Pretpostavljena naredba za selekciju podataka: SELECT Vrsta.* FROM Vrsta ORDER BY ImenaLat modifikuje se u: SELECT DISTINCTROW Vrsta.* FROM (((Vrsta) INNER JOIN Rod ON Vrsta.IdRoda = Rod.IdRoda) INNER JOIN NarodnoImeVrste ON NarodnoImeVrste.IdVrste = Vrsta.IdVrste) INNER JOIN NarodnoIme ON NarodnoImeVrste.IdNarodnogImena = NarodnoIme.IdNarodnogImena WHERE Rod.NazRoda LIKE "vitis*" AND NarodnoIme.NazNarodnogImen a LIKE "*loza*" ORDER BY ImenaLat
198
Slika 11.13. Primjer osnovnog standardnog modula. Primjer: Udruivanje standardnih modula. Forma je kreirana kao kombinacija kopija osnovnih formi, dok se sofisticirane funkcije nadograuju runo (slika 11.14).
199
Slika 11.14. Primjer udruivanja standardnih modula. Primjer: Univerzalni modul za tabelarnu obradu. Sadri samo osnovne objekte i pozive na standardne procedure (metode) za obradu dogaaja vezanih uz te objekte. U trenutku aktiviranja obavlja se prilagoavanje relacije za obradu podataka strukturi relacije podataka (slika 11.15).
200
Primjer: Univerzalni modul za pojedinanu obradu sadri objekte za posluivanje standardnih funkcija, te po jednu instancu objekata za prikaz/obradu podataka, koji se prilikom aktiviranja modula dinamiki umnoavaju u skladu sa strukturom relacije. Unaprijed se ugrauju pozivi standardnih procedura vezanih uz standardne funkcije, te objekte za prikaz/obradu podataka (slika 11.16).
201
202
Proceduralno programiranje je nain programiranja koji omoguava da se program definie kao skup programskih cjelina, poeljno takvih da se mogu ponovo koristiti. Programska cjelina (unit) je skup programskih naredbi koje obavljaju jedan zadatak ili jedan dio zadatka, npr. glavni program, potprogrami (procedure, funkcije). Programski modul je skup logiki povezanih programskih cjelina. Uvoenje programskog modula uslovljava pojavu modularnog programiranja. Komponenta je bilo koji sastavni dio softvera. Uobiajeno se podrazumijevaju fizike cjeline.
Slika 12.1. Inkrementalni pristup: struktura programa. 2. Prvo se kodiraju sve funkcije, a zatim se udruuju; 3. Pokretanje programa zavrava fatalnom grekom; 4. Problem: kako ustanoviti u kojoj funkciji se nalazi greka; 5. Rjeenje je u postupnom kodiranju i udruivanju funkcija. Prilikom izrade funkcije koja poziva neke druge funkcije, pozvane funkcije se kodiraju kao
203
odresci ili okrajci (stub), tako da je tijelo funkcije prazno ili sadri poruku (Tu sam B): Funkcija A () poziv B() Funkcija B() ispis "Tu sam B" Prilikom izrade funkcije koja e biti pozvana iz neke druge, jo neugraene funkcije, izrauje se pogonska funkcija (driver): Funkcija M (a, b, c, ) Program DriverM poziv M (1, "test", 3.14, ) Programiranje od vrha prema dolje (Top-Down). Ako funkcija fGornja poziva funkciju fDonja, onda se fGornja kodira i integrie prije fDonja. Mogui redoslijed kodiranja: abcdefghijklm, pisanjem odrezaka (npr. bcd za a). Alternativni redoslijed je a+beh+cdfi+gjklm. Nakon to je funkcija a napravljena i provjerena, jedan programer izrauje beh, a drugi istovremeno radi cdfi. Nakon to su zavreni d i odrezak f, trei programer zapoinje gjklm (slika 12.2). Prednost ovog pristupa programiranju je bolja provjera logikih funkcija (na viem nivou hijerarhije, u kojima se donose odluke), odnosno bre otkrivanje logikih greaka i manji utroak odrezaka. Nedostatak je nedovoljna provjera operativnih funkcija (na niim nivoima obavljaju stvarni posao). a b e h c f i l j m d g k
Slika 12.2. Programiranje od vrha prema dolje. Programiranje od dna prema gore (Bottom-Up). Ako se funkcija fDonja poziva iz funkcije fGornja, onda se fDonja izrauje prije fGornja. Redoslijed kodiranja je lmhijkefgbcda (slika 12.3): prvi programer radi heb, drugi programer radi ifc i trei programer radi lmjkgd. Nakon to su zavrene b, c i d, pristupa se konanom udruivanju.
204
Prednost ovog pristupa programiranju je bolja provjera operativnih funkcija i manji utroak pogonskog koda. Nedostatak je kasno otkrivanje logikih greaka. a b e h c f i l j m d g k
Slika 12.3. Programiranje od dna prema gore. Mjeoviti (sandwich) pristup. Prvo se od vrha prema dolje izrauju logike funkcije, npr. abcdgj. Zatim se od dna prema gore rade operativne funkcije, npr. efhiklm (slika 12.4). Prednost ovog pristupa programiranju je rano otkrivanje logikih greaka uz bolju provjeru operativnih funkcija. a b e h c f i l j m d g k
205
koji duinom prelaze irinu ekranske forme, pisanje jedne programske naredbe u redu, podjela nizova naredbi na odsjeke koji su u cjelini vidljivi na ekranskoj formi, formatiranje izvornog koda, odnosno pomicanje u desnu stranu naredbi unutar programskih struktura, tzv. "uvlaenje".
206
5. Razlikovati nazive globalnih i lokalnih varijabli, te formalnih argumenata koji se odnose na isti pojam, ime se olakava snalaenje u programskom kodu i uklanja mogua "neodreenost" sadraja, npr. gCount, sCount, lCount, aCount. Standardizacija naziva. Dodjeljivanje naziva objektima modela podataka odraava se na nazive programskih varijabli. O tome treba voditi rauna ve prilikom oblikovanja baze podataka. Poeljno je oblikovanje obaviti takvim alatom za modeliranje, koji osim stvarnih naziva ima mogunost evidentiranja kodova koji e se koristiti prilikom stvaranja objekata BP. Preporuuje se upotreba razliitih notacija, kao to su: koritenje velikih i malih slova (BrojCipela), umetanje podcrte izmeu dijelova od kojih je sastavljen pojam (broj_cipela) ili kombinovanje spomenutih notacija. Primjeri: PascalCase, koji se koristi kod imenovanja prostora: imena, klasa, interfejsa, pobrojanih tipova, postupaka i svojstava, static, public ili protected atributa, zahtjeva da poetno slovo svake rijei u imenu bude veliko slovo, npr. BackColor. Identifikator klase moe zapoeti znakom @. Dok, sa druge strane, camelCase, koji se koristi kod zatienih atributa i lokalnih varijabli postupaka, zahtjeva da poetno slovo prve rijei u imenu bude malo slovo, poetna slova ostalih rijei u imenu su velika slova, npr. backColor. Preporuke, kojih se treba pridravati: imena interfejsa uobiajeno zapoinju slovom I, koristiti imenice za imena klasa i koristiti glagole za imena postupaka.
207
'Public
Const
FTP_DIR
'... '***************************************************************
208
209
210
provjera funkcionalnosti prema zahtjevima korisnika), testiranje performansi i testiranje dokumentacije (tj. provjera korisnike dokumentacije i primjera). Testiranje performansi (odnosno provjeru nefunkcionalnih zahtjeva) sainjavaju: stress - verifikacija velikog broja simultanih pristupa, volume - test na koliinu podataka, sloenost algoritama, fragmentaciju, ..., security - provjera prava pristupa, timing - brzina odziva, recovery - mogunost oporavka pri forsiranom padu sistema.
Test prihvatljivosti je test sistema kojim se dokazuje da proizvod zadovoljava korisnike zahtjeve i potrebe organizacije, te uslove pod kojima ga je naruilac spreman preuzeti. To je sveobuhvatni i konani test sa stvarnim podacima. Alfa-testiranje je verifikaciono testiranje. Sastoji se od probne upotrebe sistema, a provode ga korisnici kod izvoaa. Vri se simulacija stvarnog okruenja, traenje greaka i propusta. Beta-testiranje je validaciono testiranje. Testiranje provode korisnici kod sebe, bez prisustva izvoaa. Provjera se vri u stvarnim uslovima. Provjeravaju se performanse sistema, vrna optereenja, upotrebljivost i lakoa upotrebe metoda i procedura, izrada rezervnih kopija i oporavak sistema. Nadzorni test se provodi prema potrebi. Predstavlja potvrdu da je sistem gotov, ispravan i spreman za primjenu. Ovaj test provode nezavisne institucije za osiguravanje kvaliteta.
211
4. Plan upravljanja softverskim projektom - Software Project Management Plan (SPMP); 5. Specifikacija softverskih zahtjeva - Software Requirements Specification (SRS); 6. Document za softverski dizajn - Software Design Document (SDD); 7. Izvorni kod (Source code); 8. Dokumentacija softverskog testa - Software Test Documentation (STD); 9. Korisniko uputstvo (User's manual). Korisnika dokumentacija mora pruiti pomo korisnicima pri upotrebi sistema i mora biti prilagoena korisnicima razliitog iskustva. Tu spadaju: upute za upotrebu (user manual), instalacioni prirunik (installations manual), detaljni prirunik (reference manual), upute za vjebu (training guide, tutorial), podsjetnici ili kratke upute (quick reference guide, pocket guide, cue cards). Broj, vrsta i obim dokumenata zavisi o aplikaciji. Tehnika dokumentacija je namijenjena tehnikom osoblju. Potrebna je za razumijevanje, izradu i odravanje sistema. Omoguava upravljanje projektom i konfiguracijom sistema, budui da sadri plan razvoja, specifikaciju dizajna, opis arhitekture sistema i specifikaciju interfejsa prema drugim sistemima. Pored navedenog, tehniku dokumentaciju sainjavaju: programska dokumentacija (izvorni kd, opis baze podataka, probni podaci i rezultati provjere, dnevnik promjena i programski prirunici), instalacioni prirunik (odnosno opis instalacione procedure) i upute za rukovanje i odravanje (opis procedura za pokretanje/zaustavljanje - startup/shutdown, opis izrade rezervnih kopija i vraanja podataka - backup, restore, opis postupka ponovnog pokretanja i oporavka - restart, recovery).
212
213
214
Primjer 2:
215
Primjer 4:
Slika 13.5.Ekranska forma generatora dijagrama toka Code Visual to Flowchart V3.5 (2006).
216
Promjenljive i njihovi tipovi se u pseudokodu posebno ne deklariu. Ako to ne proizilazi iz njihovog naziva, opisuju se u okviru komentara. Piu se italic slovima, nisu ograniene duinom, a ako se sastoji od vie rijei povezuju se podcrtom (_), npr. p. Glagoli: Svaka imperativna naredba pseudokoda poinje glagolom. Taj glagol se pie velikim slovima, npr. POSTAVI.
217
Operator dodjele: Naredba dodjele vrijednosti promjenljivoj posjeduje dvije komponente. To su glagol POSTAVI i strelica , koja predstavlja operator dodjele. Naredba ima oblik: POSTAVI p i, gdje je p promjenljiva, kojoj se dodjeljuje vrijednost, a i neki izraz. Nakon realizacije naredbe dodjele, promjenljiva p posjeduje vrijednost izraza i. Aritmetiki i algebarski operatori: Aritmetiki, skupovni, logiki i relacioni operatori se, u naredbama pseudokoda, koriste na uobiajen nain. Komentar u pseudokodu ima slijedeu sintaksu: ( * tekst komentara * ), gdje ( * oznaava poetak, a *) kraj komentara. Sam tekst komentara je niz alfanumerikih znakova, koji ne smije sadravati oznake za poetak ili kraj komentara. Primjer: ( * ovo je ispravan komentar * ) ( * ovo je neispravan komentar ( ** ) ( ********************************* ovo je ispravan komentar *********************************** ).
218
BLOK DIJAGRAM A B C
Slika 13.6. Pseudokod i blok dijagram sekvence. Selekcija je osnovna struktura koja slui za prikaz uslovnog grananja u algoritmima. Semantika ove strukture se moe opisati na slijedei nain. Ako je zadovoljen uslov P, tada se izvrava aktivnost A, inae se izvrava aktivnost B. Na slici 13.7 je prikazana sintaksa pseudokoda i blok dijagram selekcije. U sintaksi selekcije se za svako AKO JE uslov TADA, pie INAE i jedno KRAJ AKO, poevi od iste kolone kao AKO . PSEUDOKOD: AKO JE P TADA IZVRI A INAE IZVRI B KRAJ AKO BLOK DIJAGRAM da P A B
Slika 13.7. Pseudokod i blok dijagram selekcije. Primjer: Neka je a promjenljiva ija je trenutna vrijednost 0. Tada e promjenljiva a imati vrijednost 1, nakon izvrenja selekcije: AKO JE a 0 TADA POSTAVI a a+1 INAE POSTAVI a a-1 KRAJ AKO
219
Da je inicijalna vrijednost promjenljive a bila 1, nakon izvrenja selekcije bi imala vrijednost a = 0. Iteracija RADI DOK JE je algoritamska struktura u kojoj se aktivnost A ponovljeno izvrava tako dugo dok je postavljeni uslov P zadovoljen. Svaka iteracija ima svoje ime. Poinje glagolom RADI, a zavrava se frazom KRAJ RADI, koja se pie od iste kolone kao i RADI. Kada je rije o iteraciji tipa RADI DOK JE, za nju je specifino da ukoliko uslov P nije zadovoljen kod prvog ispitivanja, aktivnost A se uopte ne izvodi. Na slici 13.8 je prikazana sintaksa pseudokoda i blok dijagram iteracije tipa RADI DOK JE.
BLOK DIJAGRAM
A da P
Slika 13.8. Pseudokod i blok dijagram iteracije RADI DOK JE. Primjer: Neka je n = 10, tada se oduzimanje u iteraciji: RADI oduzimanje_od_n DOK JE n > 1 POSTAVI n n - 1 KRAJ RADI oduzimanje_od_n izvrava 9 puta. Da je, inicijalno , bilo n 1, tada se oduzimanje ni jedan put ne bi izvrilo. Iteracija RADI DOK NE BUDE je iteracija kod koje se, za razliku od iteracije tipa RADI DOK JE, aktivnost A izvrava prije ispitivanja postavljenog uslova P. Aktivnost A e se sigurno izvriti bar jedan put, bez obzira na ispunjenje uslova P. Aktivnost A se izvrava tako dugo dok ne bude zadovoljen uslov P. Na slici 13.9 je prikazana sintaksa pseudokoda i blok dijagram iteracije RADI DOK NE BUDE.
220
PSEUDOKOD:
BLOK DIJAGRAM
A P da
Slika 13.9. Pseudokod i blok dijagram iteracije RADI DOK NE BUDE. Primjer: Neka je n = 10, tada se oduzimanje u iteraciji: RADI oduzimanje_od_n DOK NE BUDE n = 1 POSTAVI n n - 1 KRAJ RADI oduzimanje_od_n izvrava 9 puta. Da je, inicijalno bilo n 1, tada uslov za izlazak iz iteracije ne bi nikada bio zadovoljen. Mogue oznake za pisanje pseudokoda: Abc abc Abc := # " s v M IvI & Si I&I naziv algoritma rezervisana rije pseudokoda za opis algoritama ugraena ili trivijalna funkcija (procedura) pridruivanje zamjena vrijednosti komentar konstanta ili parametar skalar vektor matrica nula-vektor modul (duina) vektora skup element skupa kardinalni broj skupa prazan skup
221
222
Slika 13.12. Primjer stabla odluivanja za zooloki vrt ivotinje. Moe se uspostaviti veza izmeu stabla odluivanja i pseudokoda. Na slici 13.13 je prikazano stablo odluivanja za Videoteku i na slici 13.14 pripadajui pseudokod.
223
Kategorija filma:
bilo koliko
Slika 13.13. Primjer stabla odluivanja za Videoteku. cijena = 0 ako je hit film tada rok iznajmljivanja = 1 dan Slika 14.13. Primjer pseudokoda za Videoteku. cijena = cijena + (osnovna cijena filma x 1,5) inae ako je ukupni broj filmova manji od 3 tada rok iznajmljivanja = 1 dan cijena = cijena + osnovna cijena filma inae ako je ukupni broj filmova manji od 7 rok iznajmljivanja = 3 dana inae rok iznajmljivanja = 7 dana ako film nije trei po redu (svaki trei obini film je besplatan) tada cijena = cijena + osnovna cijena filma
224
225
13.6. Struktogram
Struktogram (Nassi-Shneiderman Chart) je grafiki prikaz programskih struktura. Znatno je prikladniji od dijagrama toka. Neprikladan je za runu izradu, naroito kada ga je potrebno esto mijenjati. Osnovni elementi struktograma su prikazani na slici 13.15.
Sekvenca
Selekcija
Iteracija
Slika 13.15. Osnovni elementi struktograma. Nassi-Shneiderman dijagrami su pogodni za reverzni inenjering programa pisanih u C programskom jeziku i za generisanje koda. Na slici 13.16 je prikazan Nassi-Shneiderman dijagram uraen pomou CASE alata Xper-C.
226
227
Jezik za poslovne probleme: COBOL (COmmon Business Oriented Language), jezik prikladan za poslovne aplikacije i rad sa podacima. Jezik orijentisan listama i redovima: LISP (LISt Processing), nastao sa namjerom da se razvije programski jezik pogodan za probleme iz podruja vjetake inteligencije. Jezik vjetake inteligencije: PROLOG (PROgramming in LOGic), namjenjen logikom programiranju. Vienamjenski jezici: PL/I, pogodan za numeriko-inenjerske i poslovne aplikacije, C, razvijen radi izrade operativnog sistema iz kojeg je nastao Unix, danas predstavlja standard kada se radi o proceduralnom programiranju, C++, C sa svojstvima objektnog programiranja, Pascal, nastao sa namjerom da se napravi jezik koji se moe efikasno ugraditi na veinu raunara, a koji e biti pogodan za uenje programiranja kao logike i sistematske discipline, ADA, pokuaj postavljanja standarda za jezik integrisanih raunarskih sistema (kontrola industrijskih pogona, vazduhoplova ili bolnikih sistema), Modula-2 i Oberon, proirenje Pascal-a podrkom sistemskom programiranju, konceptom procesa i modula koji meusobno komuniciraju. Veina dananjih 3GL su vienamjenski jezici.
228
Podjezici SQL-a su: 1. Jezik za opis podataka (DDL - Data Definition Language), odnosno jezik za definisanje sheme BP u rjeniku podataka (kreiranje objekata); 2. Jezik za rukovanje podacima (DML - Data Manipulation Language), za rad sa podacima (postavljanje upita, unos, izmjena, brisanje); 3. Jezik za upravljanje podacima (DCL Data Control Language), za kontrolu pristupa podatcima (dodjeljivanje i ukidanje prava pristupa). Jezici etvrte generacije (4GL) kao programski jezici se koriste za pisanje aplikacija nad bazom podataka. Primjer: Strukturirani upitni jezik SQL se koristi u sistemima za upravljanje slijedeim relacionim bazama podataka: DB2, Oracle, Informix, MS SQL Server, MS Access i drugim. Matrini kalkulatori (Spreadsheet) su tabele organizovane kao mrea redova i kolona. Elementi tabele su: konstante, izrazi (formule), grafiki znakovi i objekti. Elementi jezika su aritmetike i agregatne funkcije: SUM, COUNT, AVERAGE, MIN, MAX , logiki izrazi: OR, IF, AND, NOT, matematike funkcije: SIN, COS, TAN, ASIN, EXP, SQRT, LN, LOG, statistike funkcije (npr. oekivanje) i finansijske funkcije (npr. kamatni raun). Nakon izraunavanja vrijednosti formula automatski slijedi promjena podataka, npr. D31=ROUND(SUM(D1:D30) * 0.65;-1). Integrisana programska podrka (Integrated Software) objedinjuje matrini kalkulator, obradu teksta i grafiki prikaz podataka, kao i pristup bazama podataka (postavljanje upita) i kreiranje dijaloga. Primjenjuje se za analizu, planiranje (finansije, proizvodnja, prodaja), kao i za pomo pri donoenju odluka (problemi tipa "ta ako"). Grafiki orijentisani jezici (raunarska grafika) slue za sintezu slika pomou raunara (dijagrami, animacija, digitalizacija). CAD/CAM (Computer Aided Design/Computer Aided Manufacturing) su raunarom podrano projektovanje i raunarom podrana proizvodnja. Ovdje se jo mogu svrstati simulatori, programski paketi za prenos slika, . Geografski IS (GIS - Geographic Information System) ukljuuju podatke o geometriji, koncept vie slojeva, kao i koncept objekata. Programi i jezici za prenos podataka se sreu u komunikacionim sistemima (modem, telefax, elektronska pota ... ), kao i kod rada u mrei raunara (emulatori terminala, programi za prenos podataka, ... ). Programska proirenja operativnih sistema (skeleti, ljuske) predstavljaju najraireniji pristup nadogradnje OS (npr. Unix-a). Nad istim jezgrom (kernel), mogu se
229
koristiti razliiti skeleti (shell), npr: Bourne shell, C shell, Mashey shell i dr. Skelet se koristi kao tuma (interpreter) naredbi, npr.: kreiranje liste argumenata prilikom poziva programa (ls *.c 1.c 2.c ... ), sposobnost testiranja rezultata prethodno izvrene naredbe (if test prog then ... ), redoslijedno izvoenje vie programa (cd dir, ls, cd, ... ), obrada u pozadini (background processing) (prog &, jobs, fg), usmjeravanje ulaza i izlaza (prog > output.dat, prog < input.dat), ulanavanje naredbi na principu "cjevovoda" (cat | more). Elementi programskog jezika su: prenos i zamjena parametara (script prog arg1 arg2 $1=arg1 $2=arg2), supstitucija varijabli (set TERM=vt100, echo $TERM), naredbe za kontrolu programskog toka (while, if-then-else, case, ... ). Ostala programska proirenja OS se zasnivaju na primjeni raunarske grafike, podravanju rada sa "prozorima", "ikone", ekranske forme i dr.
230
231
Slika 13.17. Primjer izvjetaja. Pojedina 4GL naredba zamjenjuje do nekoliko hiljada 3GL-a naredbi. Prave se krae programske liste, jezgrovitiji i itljiviji programski kod. Kodiranje je sa manje greaka, a ujedno je olakano otklanjanje greaka. Slinost programa strukturiranom govornom jeziku pojednostavnjenje izradu programske dokumentacije. Izradi programske opreme se pristupa u ranoj fazi razvoja, koristei prototipski razvoj. Bitno je ubrzana izrada programa sa neproceduralnom sintaksom i generatorima koda. Poveanje efikasnosti je od 6 do 60 puta (ne i skraenje vremena izrade!). Poveanje efikasnosti se postie smanjenjem broja naredbi i pomou interne optimizacije. Ista aplikacija napisana u jeziku SQL moe na istom raunaru biti od 5 do 20 puta bra od odgovarajue aplikacije napisane u nekom 3GL, kao to su COBOL ili FORTRAN. Prednost se gubi u sluajevima kada se radi o aplikacijama koje ukljuuju rjeenja proceduralnog tipa, odnosno rjeenja dobijena povezivanjem na 3GL, npr. C.
232
Prenosivost (portabilnost) programske opreme omoguavaju: oslonac na standardne OS (MS-DOS/WINDOWS, UNIX, ... ), koritenje vienivovskih prevodilaca (npr. 4GL-EC-C-O-4GE), upravljaki programi koji su nadgradnja OS (npr. SQLEXEC), kao i manje dijalekata (npr. ANSI SQL standard). Programska oprema razvijena pomou 4GL posjeduje jednostavnu i razumljivu sintaksu, slinu govornom jeziku, kvalitetniji razvojni i korisniki interfejs. Odlikuje se prikladnou za uenje i rukovanje jezikom i podacima. Moe se provjeriti tzv. dvodnevnim testom (TWO DAY TEST). Veina korisnika treba da moe nauiti osnove 4GL za 2 do 3 dana. Nakon toga korisnik bi morao biti u mogunosti samostalno da obavlja neke manje poslove. Poeljno je da korisnik nakon manjih prekida u radu (npr. 10 dana) bude u mogunosti nastaviti sa radom bez potekoa. Napred navedeno ne vrijedi jednako za sve 4GL!
233
234
Razvoj tima definiu slijedee karakteristike: formiranje (Forming), koje podrazumjeva ljubaznost, nesklonost iznoenju stavova, preputanje voenju, "jurianje" (Storming), koje se ogleda u neslozi, sukobu linosti, grupaenju /stranakoj pripadnosti, pomanjkanju kvalitetne komunikacije, neuspjenosti dogovaranja, normiranje (Norming), odnosno uvianje dobrih strana zajednikog rada, meusobno uvaavanje i predstavljanje (Performing), djelovanje, tj. povezivanje u efikasnu operativnu grupu. Uticaj karakteristika tima na njegovu uspjenost prikazan je slikom 14.1.
Administrator
Programer
Slika 14.2. Prikaz klasine organizacije tima. Modernu organizaciju tima (4GL tim) sainjavaju izvrioci slijedeih radnih zadataka: rukovodilac projekta, odnosno vii sistem analitiar, saradnju sa korisnikom ostvaruje poslovni analitiar, konceptualno i logiko oblikovanje obavlja sistem analitiar, a isporuku sistema/aplikacija vri poslovni analitiar. Nabavka i pogon opreme je radni zadatak sistem inenjera za raunare, mreni servisi su zaduenje sistem inenjera za komunikacije, programsko inenjerstvo obavlja programeranalitiar, dok izrada dokumentacije je posao razvojnog tima. Pomono osoblje se sastoji od administrativnog koordinatora, tehniara i inovnika. Neki stvarni poslovni sistemi koriste gornju podjelu za opis radnih mjesta.
235
Elastini model tima ima oblik: upravnik tima, koji upravlja osobljem (plate, reije, ... ), rukovodilac tima, upravlja razvojem (organizacija posla), projektant (analitiar - programer) je zaduen za analizu, oblikovanje i izvedbu, a programer (programer aplikacija) vri kodiranje i testiranje aplikacija. Administrator baze podataka je zaduen za BP, a sistem inenjer(i) obavlja(ju) odravanje mree i raunara. Sastav tima odgovara poslovima koje treba obaviti. Raspodjela uloga konkretnim lanovima, kao i broj lanova pojedine kategorije, zavisi o konkretnom projektu i raspoloivosti radnika. Primjer: Ulogu upravnika tima i rukovodioca tima moe imati ista osoba. Tim moe imati vie programera. Uloga administratora BP i sistem inenjera moe se dodijeliti istoj osobi. Ovakav model tima se moe primijeniti bez obzira na moguu razliitu sistematizaciju radnih mjesta u nekom poslovnom sistemu.
236
237
Sloeni projekti zahtijevaju velike ekipe. Najbolja strategija je podijeliti projekt u niz manjih projekata (podprojekata) koji se mogu nezavisno obaviti. Izrada plana sadri slijedee aktivnosti: utvrivanje kljunih aktivnosti i dogaaja, odreivanje vremenskih redoslijeda aktivnosti i dogaaja, kao i utvrivanje potrebnih sredstva. Potrebno je racionalizovati pripadajue trokove, povezati pojedine podprojekte/poslove u glavni projekat, iterativno razraditi plan i revidirati plan u skladu sa postojeim iskustvom/saznanjima. Metode namijenjene za upravljanje projektima su mnogobrojne, a mogu se izdvojiti PRINCE (PRojects IN Controlled Environments) i COCOMO (COnstructive COst MOdel). Metoda PRINCE je strukturirana metoda za upravljanje projektom, za definisanje organizacione strukture projekta, definisanje strukture i sadraja plana projekta, definisanje skupa provjera i izvjetaja koji se koriste za nadzor realizacije.
Slika 14.4. Primjer gantograma. Mreni plan - PERT/CPM (Program Evaluation Review Technique/Critical Path Method) prikazuje vremensku predstavu aktivnosti i njihovih uslovljenosti. Vidljivo je
238
koje aktivnosti se mogu vriti paralelno, a koje u nizu, ukoliko zavise o ranijim aktivnostima. Naglaava kritini put projekta, slika 14.5.
Slika 14.5. Primjer mrenog plana PERT/CPM. Upravljanje kljunim dogaajima se vri tabelarnim prikazima planiranih aktivnosti i trenutnog statusa njihovog izvrenja. U odreenim vremenskim trenutcima se razmatra stepen dovrenosti neke/nekih projektnih aktivnosti. Kljuni dogaaj je obino kraj neke faze ili aktivnosti, kao npr. oekuje se da faza ili aktivnost bude gotova, druge aktivnosti zapoinju nakon to se to ostvari ili pomak kljunog dogaaja ima za posljedicu vremenski preraspored.
239
Pristupa se izradi mrenog plana na osnovu definisanih zadataka i zavisnosti (slika 14.6). Aktivna mrea se ita sa desna na lijevo. Sve aktivnosti moraju zavravati u kljunim takama (M1, M2, M3, M4, ... ). Tek kad se uspjeno pree kljuna taka moe se zapoeti sa slijedeom aktivnosti. Npr. zadatak T9, ne moe zapoeti sve dok zadaci T3 i T6 nisu zavreni. Dolazak na taku M4 pokazuje da su ti zadaci zavreni.
T12
Slika 14.6. Primjer dijagrama mrenog plana. Kritini put. Minimalno vrijeme potrebno za zavretak projekta se moe procjenjivati prema kritinom putu, odnosno najduem putu na aktivnoj mrei. U navedenom primjeru to je 11 sedmica ili 55 radnih dana. (T1-T3-T9-T11-T12, slika 14.6). Prekoraenje vremenskog roka najee je vezano uz kritini put. Aktivnosti koje kasne, a ne lee na kritinom putu ne bi trebale uzrokovati vremensko prekoraenje (npr. ako T8 kasni ne bi trebalo uticati na krajnji datum, jer T8 ne lei na kritinom putu).
240
241
242
Slika 14.10. Drugi primjer ekranske forme CASE alata za upravljanje projektima.
243
Na slici 14.11 je prikazan primjer dijagrama za praenje napretka projekta, dok je na slici 14.12 prikazan primjer tabele za evidentiranje napretka.
P1
prilagoavanje plana
D1 plan
projekta
P2
praenje napretka
O rukovodilac projekta
lan ekipe
D2 radnih sati
evidencija
244
Komunikacija moe biti: verbalna (brzo sluaj i misli, sporo i jasno govori, biljei izreeno), pisana (sadraj, forma, uestalost), elektronska (E-mail, Chat, News), obavjetavanje (pismenim putem, elektronskom potom), uvanje informacija (mreni rjenik, FTP rjenik, web server) ili u obliku organizacije rjenika (Admin, Materijali, Projekt, Backup, Tmp, itd). Druenja moraju biti efikasna! Izbjegavati raspravu o optepoznatim ili nevanim stvarima. Rasprave treba prekinuti u trenutku kada se pretvore u razgovor o temama koje se ne odnose na posao. Sastanci moraju biti pripremljeni (mjesto, vrijeme, teme, uesnici)! Tehnike za poboljanje rada: Brainstorming (iznoenje ideja), izbjegavanje "jedinih" rjeenja (traenje alternativa), zapisivanje odluka (zapisivanje da bi se izbjegla pogrena tumaenja), konstruktivne povratne informacije (kritikovanje postupaka, a ne osoba), razumijevanje neuspjeha (analiza i poboljanje svega to nije dobro), raspodjela moi i odgovornosti (ravnopravnost, izbjegavanje hijerarhije).
245
246
Karakteristike razliitih naina uvoenja sistema u primjenu su prikazani u tabeli 15.1. Tabela 15.1.
Uvoenje Rizik Troak Trajanje
247
Tokom primjene i odravanja obavlja se analiza dodatnih zahtjeva, planiranje i priprema aktivnosti koje slijede, te tako zapoinje novi ciklus razvoja.
248
novih zahtjeva uzrokovana je promjenama u poslovanju, potrebama za dodatnim informacijama ili novim idejama (eljama korisnika). Reinenjerstvo. Neke aplikacije je teko odravati (npr. uslijed zastarjelosti tehnologije), a troak odravanja pojedinih aplikacija moe dosei troak izrade novih. Reinenjerstvo je adaptacija sa ciljem smanjenja trokova odravanja, odnosno prilagoavanje veim promjenama tehnologije, ispravka sistema prije nego to doe do mogueg prekida u radu, kao i ispravka sistema koji e biti lake popraviti ako doe do prekida. Pisanje jednostavnih novih programa. Jednostavni program je onaj program koji koristi samo postojee podatke. Primjeri takvih programa su pretraivanje i pregledanje podataka, kao i generisanje izvjetaja. Ove promjene su najee i najsigurnije. Restukturiranje datoteka i baza podataka je promjena strukture u postojeoj bazi podataka. Prelazak na novu tehnologiju upravljanja podacima predstavlja veliki rizik. Reinenjerstvo programa je reorganizacija koda, odnosno restrukturiranje organizacije modula ili programske logike. Konverzija koda je prelazak na novi programski jezik. Rezanje koda ili odsjecanje koda je izdvajanje dijelova programa radi izrade odvojenog programa ili potprograma. Poboljanja i reinenjerstvo moraju biti planski provedeni.
249
Verzije konfiguracije su slijedee: verzija (version) odreeno izdanje (issue, release) proizvoda, objava, isporuka (release) originalna verzija u primjeni, npr. zadnja v2.0, revizija (revision) ona koja se koristi umjesto originalne, podrazumijeva izmjene u odreenim vremenskim intervalima, npr.v1.2, varijanta (variant) alternativa originalu (hardverska platforma, razliiti jezik), ivi paralelno sa njim, npr. v1.1.2.1. Na slici 15.2 shematski su prikazane navedene verzije konfiguracije.
V 1.0 V 1.1 V 1.2 V 2.0
V 1.1.2.1 V 1.1.4.1
V 1.1.2.2 V 1.1.4.2
250
251
Literatura
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Axosoft Company - http://www.axosoft.com/, 2005. Axtools - http://www.axtools.com/, 2006. Awad A.M.: System Analysis and Design, Irwin, 1985. Avison, D.E. & Fitzgerald, G.: Information Systems development: methodologies, techniques and tools, 2nd. ed. McGraw-Hill, 1998. Blum, B.I.: A taxonomy of software development methods, Comm. Of the ACM, vol. 37 (no. 11), 82-94, 1994. Boehm, B.W.: Seven Basic Principles of Software Engineering, Journal of Systems & Software, 3(1), March 1983, pp. 3-24, 1983. Brooks, F.P.: The Mythical Man Month, AddisonWesley, 1975. Brooks, F.P.: No silver bullet: essence and accidents of software engineering, Computer vol. 20 (no 4), pp. 10-19, 1987 Cameron, J.R., Campbell, A. & Ward, P.T.: Comparing software development methods: example, Information and Software Technology, Vol 33 (no. 6), pp. 386 402, 1991. Carnegie Mellon University, Software Engineering Institute - http://www.sei. cmu.edu/seihome, 2006. Cattel R. G. G.: Object Data Management, Object-Oriented and Extended Relational Database Systems, Addison - Wesley Publishing Company, 1991. CollabNet, Inc. - http://argouml.tigris.org/, 2006. Construx Software - http://www.construx.com/doc.htm, 2006. Enterprise IT Management (EITM) - http://www3.ca.com/Solutions/, 2006. ZPM & FER - http://www.zpm.fer.hr, 2005. Grady Booch, James Rumbaugh and Ivar Jacobson: The Unified Modeling Language (UML), User Guide, Rational Software Corporation, Original Copyright by Addison Wesley Longman, Inc., 1999. Harel, D.: Biting the Silver Bullet: Toward Brighter Future for System Development, Computer, vol. 25 (no.1), pp. 8-20, 1992. Hirscheim, R. and Klein, H.K.: Four paradigms of information systems development, Comm. of the ACM, Vol 32 (no. 10), pp. 1199 1216, 1989. Hoffer A. J., George F. J., Valacich S. J.: Modern Systems Analysis and Design, 3/e, Prentice Hall College Div., 2001. Hornby, P et all: Human and organisational issues in information systems development Behaviour and Information Technology, vol.11 (no. 3), pp. 160-174, 1992. IEEE Std 610.12-1990: "Standard Glossary of Software Engineering Terminology" in IEEE Software Engineering Standards Collection, New York, pp. 67, 1994. Institute of Electrical and Electronics Engineers, Inc. - http://www.swebok.org/, 2001.
252
23. Intelligentedu.com - http://www.intelinfo.com, 2006. 24. JYACC Company - http://www.prolifics.com/do/panther.html, 2005. 25. Kim Won: Introduction to Object-Oriented Databases, The MIT Press Cambridge, Massachusetts, London, 1992. 26. Lazarevi B., Jovanovi V., Vukovi M.: Projektovanje informacionih sistema, I deo, Nauna knjiga, Beograd, 1986. 27. Lazarevi B., Dizdarevi P., Jovanovi V.: Projektovanje informacionih sistema, II deo, Nauna knjiga, Beograd, 1986. 28. Maciaszek L: Requirements Analysis and System Design: Developing Information Systems with UML, 1/e, Addison Wesley Higher Education, 2002. 29. McConnell S.: Software Project Survival Guide Microsoft Press, ISBN: 1-57231621-7, 1998. 30. McLeod R., Jordan E.: Systems Development: A Project Management Approach, ISBN: 0-471-22089-2, Wiley Higher Education, 2002. 31. Mogin P., Lukovi I., Govedarica M.: Principi projektovanja baza podataka, STYLOS, Novi Sad, 2000. 32. Murch R.: Project Management: Best Practices for IT Professionals, 1/e, Prentice Hall PTR, ISBN 0-130-21914-2, 2000. 33. Object Management Group, Inc. - http://www.omg.org/uml/, 2006. 34. Objektno - orijentisani pristup razvoju informacionih sistema, Fakultet organizacionih nauka, Institut za organizacione sisteme, Beograd, 1998. 35. Original Copyright by IBM: The Business System Planning (BSP), 1991. 36. Poliuk E. J.: Software etvrte generacije ORACLE, NIP "Tehnika knjiga", Beograd, 1991. 37. Poliuk, E. J.: Baze podataka, Informatika literatura JEP (vlastito izdanje), Podgorica, 2003. 38. Poliuk, E. J.: Informacioni sistemi (skripta), Elektrotehniki fakultet, Podgorica, 2004. 39. Poliuk, E. J.: Ekspertni sistemi, Informatika literatura JEP (vlastito izdanje), Podgorica, 2004. 40. Poliuk, E. J.: Multiprocesorski i distribuirani raunarski sistemi (skripta), Elektrotehniki fakultet, Podgorica, 2004. 41. Poliuk, E. J.: Projektovanje informacionih sistema pomoci CASE alata (skripta), Elektrotehniki fakultet, Podgorica, 2004. 42. Poliuk, E. J.: Objektne baze podataka (skripta), Elektrotehniki fakultet, Podgorica, 2005. 43. Poliuk E. J.: Prilog metodologiji razvoja sistema za podrku odluivanju i ekspertnih sistema, (doktorska disertacija), Sveuilite u Zagrebu, 1992. 44. Poliuk E. Jaroslav: Neproceduralni razvoj informacionih sistema, (magistarski rad), Postdiplomske studije informatike na Univerzitetu u Banja Luci, 1990.
253
45. Poliuk E. J.: Projektovanje informacionih sistema (skripta), Elektrotehniki fakultet, Podgorica, 1998. 46. Poliuk E. J.: Savremeni pristup razvoju informacionih sistema, PRAKSA: Jugoslovenska revija za informatiku i automatsku obradu podataka, Beograd, 1991. 47. Poliuk E. J.: Informatika organizacija ili "organizacija budunosti", PRAKSA: Jugoslovenska revija za informatiku i automatsku obradu podataka, Beograd, 1992. 48. Poliuk E. J.: Novi pristup razvoju informacionih sistema, JISA INFO, asopis Jugoslovenskog informatikog saveza , Beograd, 1996. 49. Poliscuk E. J.: Some Features of Object Data Management Concepts, INFO SCIENCE, Journal of Information, Comunication and Computer Sciences, Beograd, 1998. 50. Poliuk E. J.: Neke osobine sistema za objektno upravljanje podacima, IV nauno - struni skup: Informacione tehnologije - sadanjost i budunost, Zbornik radova sa IV nauno strunog skupa IT '99, abljak, 1999. 51. Poliuk E. J.: Koncepti hijerarhija klasa i naslijeivanje u objektno orijentisanom modelu podataka, VI nauno - struni skup: Informacione tehnologije sadanjost i budunost, Zbornik radova sa VI nauno strunog skupa IT 01, abljak, 2001. 52. Poliuk E. J.: Neki aspekti razvoja sistema za podrku odluivanju, III meunarodni simpozij informacijske i komunikacijske tehnologije u uredskom poslovanju '92 "OFFICE AUTOMATION", Sveuilite u Zagrebu, Zbornik radova '92 OFFICE AUTOMATION, Varadin, 1992. 53. Poliuk E. J.: Informatiko obrazovanje "inenjera budunosti", V meunarodna konferencija "Informatika u obrazovanju i nove informacione tehnologije", Univerzitet u Novom Sadu, Zbornik radova I, Novi Sad, 1995. 54. Poliuk E. J.: Neki problemi korienja informacione tehnologije, VI meunarodna konferencija "Informatika u obrazovanju i nove informacione tehnologije", Univerzitet u Novom Sadu, Zbornik radova, Apatin, 1996. 55. Poliuk E. J.: Koncepti objektno orijentisanog modela podataka, IX meunarodna konferencija "Informatika u obrazovanju, kvalitet i nove informacione tehnologije", Univerzitet u Novom Sadu, Zbornik radova, Zrenjanin, 2000. 56. Poliscuk, E. J.: The Analysis Of Experimental Results Of Machine Learning Approach, Journal of Information and Organizational Sciences, ISSN 0351-1804, vol. 27, No. 1, pp. 29-42, 2003. 57. Poliscuk, E. J. and Stojanovic, D. R.: The Intelligent Agent: An Analysis of the Experimental Results, WSEAS Transactions on Systems, ISSN 1109 - 2777, Issue 10, Vol. 3, pp. 3248 3253, 2004. 58. Poliscuk, E. J.: The Machine Learning Method: Analysis of Experimental Results, Journal of Quantitative Linguistics, Taylor & Francis Group, ISSN 0929 6174, Vol. 11, No.3, pp. 215-233, 2004.
254
59. Poliuk, E. J.: Automatic Programming Systems Dedicated for Proving of Theorems, WSEAS Transactions on Computers, ISSN 1109 - 2750, Issue 2, Vol. 5, pp. 261-266, 2006. 60. Poliscuk, E. J.: Intelligible Automated Reasoning: Systems with the Resolution, Induction and Symmetry, Journal of Applied Computer Science, ISSN 1507-0360, vol.13, No.2, pp. 7-28, 2005. 61. Poliuk, E. J.: Adaptive Machine Reinforcement Learning, Centrum ksiazki akademickiej i naukowe, Motto.Pl-Ksiegarnia Internetowa, http://www.motto.pl/, Krakow, 2005. 62. Poliuk, E. J.: The Machine Learning Method: Analysis of Experimental Results, Taylor & Francis Group, http://www.citeulike.org/article/84531/, London 2005. 63. Poliuk, E. J.: The Machine Learning Method: Analysis of Experimental Results, Universita di Milano, Biblioteca di informatica, http://fantomas.usr.dsi.unimi.it/, Milano, 2005. 64. Poliuk E. J.: Automatic Theorem Proving: Situation Management and Decision Making, Emerging Technologies, Robotics and Control System, International Society for Advanced Research, Vol. 2, pp. 154-167, 2007. 65. Popkin Software - http://www.popkin.com/, 2005. 66. Pressman R.S.: Software Engineering: A Practitioner's Approach, 5/e, McGrawHill, ISBN 0-07-249668-1, 2001. 67. ProxySource, Inc. - http://www.proxysource.com/, 2003. 68. Rational Software Corporation - http://www.rational.com, 2006. 69. R.S. Pressman & Associates, Inc. - http://www.rspa.com/docs/index.html, 2006. 70. R.S. Pressman & Associates, Inc. - http://www.rspa.com/apm/index.html, 2006. 71. School of Computing at Queen's University Canada - http://www.qucis.queensu.ca /Software-Engineering/ tools. html, 2006. 72. SOFTEAM - http://www.objecteering.com/, 2006. 73. Software Engineering Environments at Auburn University - http://www.pittarese. com/Auburn/cse625/case.htm, 1998. 74. Sommerville, I.: Software Engineering, Addison-Wesley Publishing Company, 2000. 75. Sparx Systems Pty Ltd. - http://www.sparxsystems.com.au/, 2006. 76. Standish Group International, Inc. - http://www.standishgroup.com, 2006. 77. Steve McConnell's: Software Project Survival Guide (Microsoft Press, 1998). 78. http://www.construx.com/survivalguide/, 2005. 79. Visible Systems Corporation - http://www.visible.com/, 2004. 80. Visual Paradigm International - http://www.visual-paradigm.com, 2006. 81. Whitten J. L., Bentley L. D., Dittman K. C.: Systems Analysis & Design Methods, McGraw-Hill/Irwin; ISBN 0-07-25523-60; 5th ed., 2001.