PANEVROPSKI UNIVERZITET APEIRON

FAKULTET POSLOVNE INFORMATIKE

Redovne studije
Smjer „Poslovna informatika”

Predmet
SOFTVERSKI INŽINJERING SA OBJEKTNIM
PROGRAMIRANJEM

"CASE ALATI"
(seminarski rad)

Predmetni nastavnik
Prof. dr Zoran Ž. Avramović

Student
Marko Vukić
Indeks br. 55-13/RPI

Banja Luka, Novembar 2016.

Sadržaj
1. Uvod ........................................................................................................................ 1
1.1. Pojam CASE tehnologija ................................................................................ 1
1.2. Ciljevi CASE tehnologija ................................................................................ 1
1.3. Struktura CASE tahnologija ............................................................................ 3
2. Klasifiakcija CASE tehnologija .............................................................................. 4
2.1. Klasifikacija na osnovu funkcija ...................................................................... 5
3. Efekti primjene ........................................................................................................ 7
4. Osobine CASE tehnologija ..................................................................................... 8
5. Načini na koje je moguće integrisati CASE tehnologije ....................................... 11
5.1. Razmjena podataka ........................................................................................ 11
5.2. Zajednički pristup alatima.............................................................................. 11
5.3. Zajedničko upravljanje podacima .................................................................. 12
5.4. Podjela podataka ............................................................................................ 12
5.5. Međusobna operatiblnost ............................................................................... 12
6. Izbor CASE tehnologije ........................................................................................ 13
7. Pravci razvoja CASE tehnologije .......................................................................... 14
8. Modeliranje poslovnih podataka pomoću CASE alata ......................................... 16
8.1. Implementacija ............................................................................................... 17
8.2. Sistem kao naručilac ...................................................................................... 17
8.3. Metodika proizvođača softvera kao implementatora ..................................... 17
8.4. Mogući problemi između izvođača i naručioca ............................................. 18
8.5. Kontrola implementacije ................................................................................ 18
9. Neki od CASE alata .............................................................................................. 20
9.1. Visio2003 ....................................................................................................... 20
9.2. COOL:Bizz .................................................................................................... 20
9.3. Erwin .............................................................................................................. 21
10. Reverzno inžinjerstvo ............................................................................................ 22
11. Modeliranje sistema .............................................................................................. 23
11.1. Dijagrami procesa .......................................................................................... 24
11.2. Dijagram toka podataka ................................................................................. 25
11.3. Konceptualna šema baze podatka .................................................................. 25
11.4. Interna i implementaciona šema .................................................................... 26
11.5. Programska specifikacija modula .................................................................. 28
12. Kratka istorija CASE alata .................................................................................... 29
13. Zaključak ............................................................................................................... 32
14. Literatura ............................................................................................................... 33
1. Uvod

CASE (Computer Aided Software Enginerring) je najjednostavnije rečeno razvoj

softvera pomoću samog računarskog uređaja. Ideja je da se sam proces razvoja softvera u što
većoj mjeri automatizuje. Najjednostavnije rečeno, CASE tehnologijama možemo zvati svaki
softver koji je rađen namjenski da bi se pomoću njega automatizovali zadaci za izradu nekog
drugog softvera.
Dakle, ove tehnologije se koriste za određene zadatke u automatizaciji kao što su
pojedinačni alati za neki softver ali takođe i za izradu kompletnih alata za automatizaciju
softvera tj. cilj je da se što više koraka u izradi softvera automatizuje. Važno je napomenuti da
CASE tehnologije nisu zamišljene kao neka vrsta zamjene za neku tehniku ili metodu u razvoju
softvera već isključivo kao neka vrsta dodatka samim tim metodama i tehnikama koje se
primjenjuju da bi se na kraju dobio kvalitetan proizvod.
Upotreba grafike je takođe bitan dio u CASE tehnologijama, sve bi trebalo u čim većoj
mjeri da bude prilagođeno samom korisniku. Korištenje CASE tehnologija je interaktivno i
zbog toga je važno da se prilagode korisniku.
1.1. Pojam CASE tehnologija
Tvorci CASE tehnologija su zapravo osobe koje rade na razvoju softvera, razvijaju ih sa
ciljem da bi sopstvernu produktivnost u razvoju softvera unapredili. Sama ideja potekla je od
toga da računar praktično sam poveća svoju produktivnost jer nema smisla težiti ka tome da se
poveća produktivnost drugih u razvoju softvera ukoliko sam računar nije u potpunosti iskorišten
jer i same informacione tehnologije generalno zasnivaju se na primjeni računara. Samo
povećanje produktivnosti nije jedini cilj, jednako je važno da se vrijeme koje je potrebno za
izradu nekog projekta što više skrati ali da se zbog toga ne izgubi kvalitet performansi tog
softvera te da se one dovedu na što veći nivo primjenom razvojne procedure.
U cilju postizanja prethodno navedenih zadataka bilo je neophodno da se konzistentna
tehnologija disciplinarno primjenjuje te da se njeni koraci uz primjenu računara dosledno
realizuju. Najjednostavnije rečeno CASE tehnologije su primjenjivane za automatizaciju
postupka u razvoju nekog softvera i riješenje je bilo da se one što više primjenjuju.
1.2. Ciljevi CASE tehnologija
 Da se poveća produktivnost samog projektanta kod aktivnosti vezanih za razvoj
nekog softvera
 Da se vrijeme izrade projekta skrati
 Kvalitet softvera je poželjno povećati
 Performanse softvera je potrebno unaprediti
Zamišljeno je da se konzistentna tehnologija disciplinirano primjenjuje da bi se postigli
navedeni ciljevi, naravno, svaki od koraka se realizuje primjenom računara. Opet se dolazi do
zaključka da je cilj primjene CASE alata automatizacija samog postupka softverskog
projektovanja.
Nastec Corporation su bili prvi korisnici akronima CASE još davne 1982. godine.
Designe Aid je naziv prvog proizvoda te korporacije, to je bio alat koji je služio za semantičku i
logičku procjenu softvera, isto tako i sistemskog dizajna dijagrama te se na osnovu toga gradio
riječnik podataka. Pored toga alat je podržavao dizajn i strukturnu analizu.
1
 Akronim CASE zapavo ima dva značenja, prvi kao Computer Aided Software
Engineering tj. inžinjersko projekovanje softvera ali isto tako ista skraćenica se koristi i za
Computer Aided System Software što bi bukvalo prevedeno bilo inžinjersko projektovanje
informacionih sistema, sve to uz pomoć računara naravno. Generalno, bilo koji softver koji je
namjenjen za izradu nekog drugog softvera uz prisutnost automatizacije možemo svrstati pod
CASE tehnologije, ovde se doslovno sam informacioni sistem koristi za razvoj nekog drugog
informacionoh sistema.
U skladu sa svime navedenim, može se zaključiti da CASE tehnologije polaze od alata
koji se koriste pri automatizaciji nekog pojedinačnog dijela sofvera ali isto tako i u slučaju kada
je potrebno kompletno rešenje za automatizaciju tj. većin koraka se rješava automatski
korištenjem CASE tehnologija, poenta je da se praktično izrada kompletnog softvera kao
cjeline bazira na korištenju CASE tehnlogija. Ovako je na samom početku bila zamišljena
primjena CASE tehnologija dok već danas ih koriste svi koji se ozbiljnije bave softverom, neki
ih primjenjuju u samoj praksi ali isto tako dosta je onih za koje je još u eksperimentalnoj fazi
što izražava njihovu tendenciju veće primjene u budnućnosti.
Zbog veoma brzog razvoja te samog stepena napredka u kome se trenutno nalaze CASE
tehnologije ne možemo posmatrati više samo kao skup računarskih programa. S obzirom na to
kakvu poziciju zauzimaju i svijetu informacionih tehnologija danas CASE tehnologije su
definitivno puno više od toga. Poznato jee da bez metodologije tehnologiju je nemoguće
zamisliti pa takav je slučaj i kod CASE tehnologija. Dok nisu izmjenjene primjenjene
metodologije od strane samih organizacija koje su usvojile CASE tehnologije na samom
početku nije bilo moguće ostvariti neku značajnu korist od primjene CASE tehnologija.
S obzirom na to koliko su CASE tehnologije danas napredne nemoguće ih je više
pojmiti samo kao zbir samij alata koji se koriste za razvoj softvera. Složen sistem se sastoji od
više podsistema, svaki od njih integriše komponente:
 Hardver
 Softver
 Bazu podataka
 Procedure
 Kadrove
Integralna cjelina u CASE tehnologiji sastavljena od komponenti softvera i hardvera
predstavlja CASE alat. Pod CASE metodologiju se mogu svrstati procedure i još imamo CASE
enciklopediju koja bi zapravo bila sama baza podataka. Da bi se primjena CASE tehnologija
smatrala uspješnom podrazumjeva se da odgovarajuća metodologija za razvoj softvera bude
usvojena. Ako ovaj zahtjev nije ispunjen onda u tom slučaju CASE tehnologije nisu adekvatno
iskorištene.
Automatizacija ima par bitnih karakterisrika koje je predstavljaju:
 Svaki rezultat koraka metodologije mora biri međusobno usaglašen,
 Sve realizovane aktivnosti na projektu moraju biti kompletne,
 Vođenje dokumentacije.
Samom pojavom CASE alata dolaze i neki zahtjevi kao što su disciplinirani i novi
pristup inžinjeringu softvera. CASE alati su uvijek namjenjeni za određene aplikacije i
neophodno je da budu primjenjeni i selektirani u tim aplikacijama. Obuka ljudi koji rade sa
samin CASE alatima je isto tako obavezna jer sami CASE alati kao i većina drugog softvera su
samo praktično sredstvo koje softverski inžinjer ili neka druga osoba moraju adekvatno

2
iskoristiti ukoliko žele da oni ispun svoju namjenu. Shodno tome, sam krajnji efekat ne zavisi
samo od samog CASE alata i njegovog kvaliteta nego i od znanja koje posjeduje njegov
korisnik i sposobnosti dag a iskoristi.
1.3. Struktura CASE tahnologija
Opšta struktura CASE tehnologije se sastoji od sledećih alata koji se koriste za:
 strateško planiranje
 sistem analizu
 dizajniranje baze
 razvoj sistema
 izgradnju samog sistema
 upravljanje tim sistemom
 podršku svim procesima
 upravljanje cjelokupnim projektom
 enciklopediju sistema
Podaci o razvoju i formacionog sistema is vim njegovim elementima nalaze se u CASE
enciklopediji. Nju možemo posmatrati kao sponu između svih elemenata strukture CASE
tehnologije koje smo naborjali, ona pored toga nudi mogućnost nadovezivanja nekih of faza
razvoja informacionog sistema pomoću nje. U slučaj kada se u informacionom sistemu neke
faze razvoja automacki nadovezuju međusobno poenta je da se alati iz neke faze u istom
trenutku nude na raspolaganje drugim alatima u nekoj od budućih faza u procesu razvoja
sistema.
Navedene alate ne posjeduju svi CASE proizvodi u svojoj matičnoj strukturi, bitno je to
naglasiti, iako svaki dobavljač u suštini nastoji da razvije neke sopstvene ili u saradnji sa nekim
neku određenu CASE tehnologiju koja bi na kraju predstavljala određenu zaokruženu cjelinu.
Isto tako, moć CASE tehnologija nije jednaka u svim slučajevima. Tako recimo neke od njih
imaju dobar alat za analiziranje sistema dok druge dobro rade za dizajniranje baze podataka,
zatim recimo neke imaju razvijenu mogućnost strateškog planiranja ili čak mogu upravljati
cijelim projektom itd. Dakle, kao što se može zaključiti, najbolji rezultati se postižu ukoliko
kombinujemo više CASE tehnologija koje su dobre na različitim područjima. Sama primjena se
organizuje tako što se alati iz jednog skupa primjenjuju u prvoj fazi razvoja, pa onda neki drugi
u drugoj fazi razvoja i tako svaka redom koristi potrebne alate za svoju realizaciju.
Primjena CASE tehnologije na ovaj način može izazvati neke neminovne problem jer do
sada nije definisana struktura CASE enciklopedije koja bi važila za sve. Tako recimo ako
imamo u jednoj enciklopediji podatke koji su vezani za neku tehnologiju oni u većini slučajeva
nisu kompatibilni sa podacima koji se nalaze u nekoj drugoj enciklopediji koja služi u neku
drugačiju svrhu. Dakle, glavni problem u tome je što svaka različita tehnologija ima drugačije
standard pa se pri samom odabiru na to mora skrenuti pažnja.
Isto tako važno je napomenuti da same CASE tahnologije nisu u mogućnosti samostalno
automatski razviti neki sistem već samo posjeduju alate i metodologiju koji dalje omogućuju
razvoj samog sistema čija je radna produktivnost visoka.

3
2. Klasifiakcija CASE tehnologija

CASE tehnologije se klasikuju na osnovu više kriterijuma, a to su:

 Prema posjedujućim funkcijama
 Instrumentalnu ulogu koju imaju kada dođu do izvršioca ili upravljača
aktivnostima
 Zavisno od mogućnosti primjene i to u raznim fazama razvijanja softvera
 U zavisnosti od softvera i hardvera koji imaju na raspolaganju
 Izvorno porijeklo
 Cijena izrade
Još jedan od kreiterijuma na osnovu koga je moguće klasifikovati CASE tehnologije je
kompletnost same CASE tehnoloigje. Njome definišemo koliko zadataka metodologije u svom
životnom ciklusu automatizacije CASE tehnologija podržava i na taj način dobijamo sledeću
podjelu:
 Upper CASE
 Middle CASE
 Lower CASE
Upper CASE obuhvata sve one CASE tehnologije koje imaju namjenu da automatizuju
faze upravljanja projektima i faze strateškog planiranja u samom sistemu.
Middle CASE se bave automatizacijom sistema u fazama dizajna i fazi analize.
Lower CASE automatizuju onaj dio alata u CASE tehnologijama koji je vezan za
programiranje i takođe fazu testiranja kao i uvođenje samog informacionog sistema.
Naredna podjela bila bi prema integrisanosti CASE tehnologija:
 CASE tool
 CASE toolkit
 CASE workbench
CASE tool predstavljaju alate koji neke aktivnosti CASE tehnologija automatizuju u
kada je informacioni sistem u fazi razvoja. One koriste grafičku podršku koja danas predstavlja
jako moćan alat što zančajno olakšava dokumentovanje i opis sistema. Grafički se takođe što
više nastoji približiti korisnički interfejs da bi bio što bliži korisniku i na taj način olakšao rad
sa samim alatom.
CASE toolkit složi za to da bi se jedna kompleksnija faza ili funkcija podijelila na više
faza a da ih ovaj alat sve ujedini. Dakle tu krećemo od razvoja svake funkcije ili faze
pojedinačno da bi na kraju dobili jedan složeniji projekat.
CASE workbench se koristi kada automatizujemo sve zadatke u procesu razvoja
informacionog sistema po fazama i samim tim predstavljaju kolekciju CASE paketa koja je
integrisana. Kada se kolekcije CASE paketa usklade sa odgovarajućim hardverom dobije se
radna stanica za razvoj softvera. Treba imati na umu kada se biraju CASE alati da vrste sistema
i karakteristike kojima su oni prvenstveno namjenjeni budu usklađeni sa potrebama korisnika i
zahtjevima njegovog sistema u zavisnosti za šta želimo koristi neku od CASE tehnologija.

4
 CASE tehnologije možemo još takođe podijeliti prema fazama životnog ciklusa koje
CASE tehnologije pokrivaju, pa tako imamo:
 Projektanski CASE
Početak automatizacije životnog ciklusa (prve tri faze):
1. Strategijsko planiranje
2. Analiza
3. Dizajn
 Programerski CASE
Automatizacija sledećih faza životnog ciklusa:
1. Programiranje
2. Implementacija
3. Eksploatacija
4. Održavanje
 Integrisani CASE
Učestvuje u svim fazama razvoja sistema.
2.1. Klasifikacija na osnovu funkcija
Ako za primarni kriterijum za klasifikaciju CASE tehnologija budu same funkcije koje
one posjeduju tada dobijamo sledeću podjelu:
 Alati koji se koriste za planiranje poslovnoh sistema
 Alati pomoću kojih se upravlja projektima
 Alati za podršku
 Alati za dizajn i analizu
 Programerski alati
 Testni alati i alati integracije
 Alati za fazu prototipskog razvoja
 Podrška održavanja
CASE tehnologije koje se koriste za praćenje aktivnosti između organizacionih jedinica
i tokova informacija spadaju pod alate za planiranje poslovnoh sistema.
Kod alata za upravlajnje projektima imamo sledeći skup aktivnosti:
1. Upravljanje podacima i prikupljanje informacija
2. Analizu rizika
3. Verifikaciju standarda
4. Vrijednost projekta i procjena vrijednosti
5. Plan projekta
6. Ocjena produktivnosti
7. Osiguranje kvaliteta
8. Skupljanje informacija i pronalaženje resursa
Alati koji su neophodni kroz čitav proces softverskog inžinjeringa su alati podrške, ove
aktivnosti su dakle dostupne u svakom trenutku. Sadrže alate za potrebe dokumentovanja, zatim
alate koji daju podršku sistemskom softveru, isto tako alate za podršku kod osiguranja
kvaliteda, zatim za upravljanje bazom podataka itd.
Alati za dizajn i analizu su dio CASE tehnologija koje pomažu inžinjerima da krairaju
sam model sistema koji se gradi. Ovaj model se sastoji od prikaza toka podatka, prikazuje
sadržaj podatka, kao i sadržaj procesa, prikazuje kontrole itd. Na kvalitetu i razvoj modela
direktno utiču ovi alati jer oni se koriste za samo kreiranje modela i dalji razvoj. Pomoću njih se
5
otklanjaju greške na osnovu obavljene provjere konzistentnosti te provjene vrijednosti modela,
velika prednost je što na ovaj način to možemo učiniti prije nego se pređe na dizajn ili čak
počne sa implementacijom.
Za pomoć pri kreiranju programskih rešenja tu su alati za programiranje koji su
namjenjen da podržavaju CASE tehnologije u ovoj klasi. U tu grupu se obično svrstavaju neki
od konvencionalnih alata koji se koriste za podršku programskim jezicima, zatim simulatori
setova instrukcija kao i editori te generatoti modula i koda itd.
Da bi se softver na pravi način uklopio u okolinu u kojoj će funkcionisati zaduženi su
alati za testiranje i integaraciju. CASE tehnologije ove klase razvnijene su u što većoj mjeri da
bi se konačni proizvod što bolje usavršio za potrebe korisnika i na taj način osigurao svoje
mjesto na tržištu. Primarna svrha ovih alata je da prikupe što više informacija i podataka koji
će se dalje koristiti tokom testiranja. Pored njih tu su alati koji izvorni kod analiziraju bez
prethodno izvršenog testa, pa zatim alati pomoću kojih se izvorni kod analizira u toku obrade,
te alati koji za zadatak imaju da pomognu u planiranju. Jako važna grupa alata su oni koji
simuliraju sam hardver i još dodatno neke spoljene elemente jer se na ovaj način rade
najpouzdaniji testovi i provjere.
Jako bitan dio kod izrade softvera su alati koji služe za podršku održavnja. Prema nekim
podacima koji se odnose na CASE tehnologije ovo je praktično 70% posla u cjelokupnoj izradi
softvera. Funkcije se mogu podijeliti u tri grupe:
1. Inžinjering u suprotnom smijeru (generiše razvojni i analitički model na osnovu
izvornog koda)
2. Rekonstrukcija koda
3. Reinžinjering

6
3. Efekti primjene

Prve tri faze automatizacije su najvažnije u razvojnom ciklusu CASE tehnologija i zbog
toga se njima daje najviše pažnje. Bitno je to naglasiti jer su veliki torškovi ukoliko dođe do
greške da bi se ona poslije uklonila u nekoj od faza živornog ciklusa. U praksi se pokazalo da
ako se kasnije otkrije greška njeno saniranje je skuplje.
Kvalitetu samog softversog inžinjeringa značajno može doprinijeti primjena CASE
tehnologija ako se efikasno koristi. CASE tehnologije imaju mnogo pozitivnih strana, najbitnije
je to da svoju funkciju izvršavaju a pored toga se uštedi na radnoj snazi, isto tako in a vremenu
kao i na finansiranju a pored toga omogućuju u dosta slučajeva nešto što bez njih ni ne bi bilo
izvodivo ili bi bilo teško izvodivo. Važno je naglasiti da se primjenom CASE tehnologija
značajno smanjuju greške pa se samim tim i produktivnost povećava.
Pozitivni efekti CASE tehnologija:
 Model sistema se grafički prezentuje
 Korekcija nekonzistentnosti i detekcija grešaka
 Prototip sistema se interaktivno izrađuje
 Ukoliko se neka komponenta može u razvoju ponovo upotrijebiti sistem ju
identifikuje
 Razvojem sistema se efektivno upravlja
 Vrijeme utrošeno za razvoj se efektivno kontroliše
 Sredstva koja su namjenjena za razvoj se takođe kontrolišu
 Dokumentacija koja je uvijek ažurna se generiše automacki
Dakle, CASE tehnologije prednjače u odnosu na neke tradicionalne načine za razvoj
sistema kao što može vidjeti iz prethodno navedenih efekata pa tako da ako su problem tipa
netačnosti ili kašnjenja u izvedbi zastupljeni, kao i u slučaju kada je dokumentovanost loša ili se
izmjene teško rade CASE tehnologije mogu znatno pomoći.
Teško je tačno procijeniti koliki su efekti primjene CASE tehnologija jer je period
korištenja do sada relativno kratak. Ali neka istraživanja i dosadašnje studije pokazuju
poboljšanja koja se kreću od 30% pa do 60%. Rezultati su još uvijek prilično neusaglašeni ali
bez obzira na to veoma je pozitivna mjera da su skoro pa u svim studijama primjena CASE
tehnologija dovele do poboljšanja. Samo povećanje produktivnosti, a pored toga i mnogo
tačnija izgradnja sistema za kraći period dovela je do toga da inžinjeri koji se bave izgradnjom
softvera često u potpunosti promjene metode razvoja ili ih izmjene u nekoj mjeri kako bi na taj
način omogućili implementaciju CASE tehnologija.

7
4. Osobine CASE tehnologija

Uopšteno gledano, korisnički zahtjevi su ti koji diktiraju razvoj CASE tehnologija i

samim tim šta i u kom okruženju je potrebno primjeniti te se tako dolazi do finalne ideje na koji
način će funkcionisati tehnologija. Ne postoje neki konkretni standardi kada je riječ o CASE
tehnologiji. One su brojne, što je jasno na osnovu svih grupa koje su navedene kao i opširnim
mogućnostima primjene u mnogim of faza u razvoju nekog softvera. Dakle, jasno je da CASE
tehnologije pokrivaju skoro sve faze u izgradnji softvera.
Osobine koje moraju zadovoljiti proizvodi CASE tehnologija da bi se smatrali
kvalitetnim su sledeće:
 Lako i jednostavno korištenje
 Mogućnost otkrivanja i otklanjanja greške
 Podobnost
 Moć tehnologije
 Pouzdanost
 Konzistentnost
 Funkcionalnost
 Metodologija
 Integracija
 Podrška

Svaka nova tehnologija je u velikoj prednosti ako je prilagođena korisniku, zbog toga
jednostavnost korištenja praktično pretstavlja efektivnost same tehnologije posmatrano od
strane korisnika. Bez obzira na složenost tehnologije i samu funkcionalnost CASE tehnologije
se kreiraju na takav način da jednostavno, lako i bez potrebe za puno razmišljanja dovedu do
rešenje nekog konkretnog zadatka. U suprotnom, ako sam korisnik treba odraditi dio ovog posla
i utrošiti svoje vrijeme da bi na kraju tehnologija radila te da bi je on mogao koristiti onda je
već upitno koliko ona ispunjava svoj zadatak te da li uopšte pomaže jer ukoliko imamo ovakav
slučaj moguće je da ona onda samo predstavlja smetnju u radu.
Kako se CASE tehnologije smatraju naprednima od njih se očekuje da otrkrije greške u
samom procesu pa čak da neke od njih i samostalno koriguje. Komunikacija takođe treba da
bude na veoma visokom nivou interakcije te da jasno i koncizno vodi dijalog sa korisnikom u
toku rada, jako je važno da sve bude predstavljano na način koji je korisniku prihvatljiv i
razumljiv. Da bi tehnologija zadovoljila zahtjeve korisnika neophodno je da bude u mogućnosti
kombinovanja sa drugim tehnologijama, njena fleksibilnost u ovom smislu je veoma značajna
jer zahtjevi korisnika su različiti. Neka neplanirnja reagovanja od strane tehnologije ili slično
izazivaju najviše nezadovoljstba od strane korisnika, stoga je nužno takve situacije svesti na
minimum a poželjno je da se iste i u potpunosti otklone. Dakle, smatra se nedopustivim da zbog
svojih izlaza tehnologija dovodi do toga da blokira korisnika a nisu poželjna ni neka
iznenađenja, da korisnik bude zbunjen rezultatom ili slično. Takođe, od korisnika se očekuje da
koristi naredbe koje su koncizne, jednostavne i jasne.
Kada je riječ o podobnosti ona tehnologija koja ima nivo podobnosti da zahvaljujući
svojim performansama može riješini veliki broj zadataka u toku razvoja softvera onda se takva
tehnologija može smatrati kvalitetnom. Recimo samu podobnst moguće je izraziti tako što se
jednostavnom naredbom može dovesti do nekog od glavnih efekata za koje je tehnologija
razvijana. Pored toga, od CASE tehnologije se očekuje da predoči sve informacije o stanju
8
same CASE tehnologije, cilj ovoga je da se korisniku predoči podobnost tehnologije tako što će
izneijeti što više informacija o svom stanju, tako čak se stiče utisak da je tehnologija čak i
podobnija nego što to u stvari jeste.
Snaga ili moć tehnologije se rangira na osnovu nekoliko faktora:
1. Nivo pouzdanosi
2. Ponašanje pri lošim ili teškim uslovima
3. Funkcionisanje
4. Značajnost tehnološkog nedostatka
5. Aktivna konzistentnost u tehnološkom funkcionisanju
6. Način integracije u spoljno okruženje
Mogućnost alata da korisniku pruži rasterećenje kada je riječ o riziku koji bi sam
korisnik mogao napraviti predstavlja njegovu pouzdanost, što je za korisnika veoma značajno.
Zamišljeno je da CASE tehnologije najprije otkriju eventualne greške a zatim iste i otklone, s
tim da se takođe obrati pažnja in a posledice koje nastaju zbog greške. Ako se sama greška
otkloni a posledice koje je ona prouzrokovala ostanu to značajno ugrožava pouydanost sistema.
Samotestiranje je u ovome jako važno, tehnologija treba samu sebe da provjeri i taj mehanizam
je zadužen za to da omogući pravilno funkcionisanje .
Potvrda moći i veličina snage tehnologije stiče se na osnovu konzistentnosti aktivnosti,
ona podrazumjeva semantiku i sintaksu koja mora biti dobro definisana. U istom trenutku,
nužno je da thenologija bude razvijena do te mjere da bez problema podržava razlike između
pojedinih verzija i da iste budu u potpunosti kompatibilne.
Funkcionalnost je osobina koju nije moguće definisati samo na osnovu zadatka u svrhu
kojeg je neka od tehnologija dizajnirana, nego su jako bitne i same metode koje se koriste za
izvršavanje zadataka. Veoma je velik broj tehnologija od strane kojih su metodologije
podržane. Ispoljavanje efikasnosti od starane same tehnologije se ogleda kroz mogućnost
podrške metoda i ona doprinosti neposredno mogućnosti razumjevanja i definisanja tehnoloških
osobina. Efikasnost se isto tako može posmatrati kroz korisnost izlaza i njihov kvalitet sa
aspekta korisnika.
Cilj CASE tehnologija je da metode integtišu te ih povežu za metodologijom. Neke od
tehnologija imaju mogućnost podrške čak svih područja u metodologiji ili barem više njih, ako
ne onda u krajnjem slučaju najmanje jedno područje metodologije i mogu rezultate među
fazama nezavisno prenositi. Struktura i koncepcija CASE tehnologija određena je direktno
izabranom metodologijeom, samim tim i tehnikama te metodama koje se koriste. Obavezno je
da tehnologija osigura primjenu metodologije koja je konzistentna, a isto tako i metoda ne
kojima je zasnovana. To osigurava korektno funkcionisanje te naglašava potrebu da se
kontroliše da li je u potpunosti sprovedena metodologija. Još treba napomenuti i da sama
tehnologija ima zadatak da generiše korektne izlaze koji su metodologijom striktno strogo
definisani.
Postojeći sistem je obično temelj za razvoj CASE tehnologija. Shodno tome, od velikog
je značaja da se CASE tehnologija uklopi u postojeći sistem i praktično nadogradi na njega.
Lako povezivanje sa informatičkim sistemom koji već postoji tu je od velikog značaja. Cilj je
da instalacija bude jednostavna ted a postojeće structure baza podataka i datoteka budu
nesmetano korištene kao i prije nego su se CASE tehnolgije počele koristiti. Ukoliko se u
organizaciji, što je čest slučaj, koristi više tehnologija ovog tipa obavezno je da prenos podataka
i njihova razmjena bude omogućena i da se nesmetano izvodi između različitih CASE
tehnologija koje se koriste u istoj organizaciji.
9
 Za rangiranje CASE tehnologije na osnovu kvaliteta podrške bitno je obratiti pažnju na
nekoliko sledećih elemenata:
1. Reputacija koju ima dobavljač
2. Rasprostanjenost i zrelost tehnologije
3. Ukoliko se kupuje nekoliko kopija razamtranje mogućnosti da se troškovi u tom
slučaju umanje
4. Davanje tehnologije na raspolaganje za iznajmljivanje
5. Povrat sredstava ukoliko dođe do vraćanja tehnologije
6. Ukoliko je iz nekih razloga potreban izvorni kod tehnologije da se omogući
pravo pristupa istom
7. Uslovi održavanja
8. Blago vremena reakcija kada je održavanje u pitanju
9. Ukoliko dođe do nekog problema pružanje mogućnosti odgovora
10. Dogovor oko prava na nove verzije tehnologije ako je daljni razvoj u planu,
pogotovo sa aspekta financiskog gledišta
11. Rok trajanja garancije
12. Dozvoljeni rok za isporuku
13. Obuka za buduće korisnike tehnologije
14. Ukoliko je potrebno da li su na raspolaganju neki od programa obuke
15. Nivo stručnosti i pedagoške sposobnosti kadrova koji rade na obuci
Treba napomenuti i da CASE tehnologije nude mogućnost integralnog razvojnog
okruženja i to da metodološki pristup bude nezavistan od sistemskog razvoja te da pruži
prilikom svake aktivnosti podršku, počevši od definisanja, pa zatim razvoja softvera i sve do
samog održavanja tog softvera. Uz sve ovo bitno je da se omogući da funkcionisanje sistema
bude optimalno ted a procenat grešaka do kojih može doći u procesu bude sveden na minimum.

10
5. Načini na koje je moguće integrisati CASE tehnologije

Više je načina pomoću kojih se može integrisati CASE tehnologija. Međutim, broj alata
koji se koriste nezavisno i koji su uopšteno nezavisni je veoma mali. Oni koji su tako kreirani
mogu samostalno da ponude izlaze kao program, podatak ili document. U ovom slučaju veza
ovakvih alata sa ostatkom okruženja je papir koji graditelj softvera prenosi na uvid ostalima.
U stvrnom svijetu više je načina integracije kojima se mogu povezati CASE tehnologije,
s to su:
 Razmjena podataka
 Zajednički pristup alatima
 Upravljanje podacima je zajedničko
 Dijeljenje podataka
 Međusobna operatibilnost
5.1. Razmjena podataka
Mogućnost koju većin alata posjeduje je razmjena podataka a ona je i najčešći slučaj. U
takvom slučaju alati se prevode u oblik datoteke koja je nestruktuirana i to u formatu štampe.
Na ovaj način dobijamo mogućnost zaštite podataka alata, te se eliminišu potrebe za unošenje
elementa nanovo te upisivanje specifikacija elementa ponovo in a taj način se takođe i
štamparske greške sprečavaju. Zajedničkom akcijom razvijaju se prevodioci od strane samih
isporučilaca alata i od njih se ti alati najlakše mogu i nabaviti. Pored toga, u nekim slučajevima,
nudi se još jedna varijanta za nabavku prevodilaca, naime, u nekim slučajevima iste razvijaju i
korisnici i konsultanti. Problemi u ovom drugom slučaju često nastaju kod toga što se u dosta
slučajeva samo dio ovako prevedenih podataka može i prihvatiti na ovaj način i da se oni dalje
mogu koristiti u drugom alatu. Taj problem je moguće otkloniti tako što se kompatibilnost
naknadno definiše. Još jedan problem koji iziskuje konstantno prenošenje i prevođenje datoteka
jer se iste stalno razvijaju samim razvojem softvera koji je u većini slučajeva konstantan.
Problem sa sinhronizacijom takođe je često izražen kada su u pitanju dvije ili više različitih
verzija softvera.
Često je slučaj da se na jednom projektu koristi mnogo alata i tada je nužno izbjeći
stalno prevođenje i transferisanje, važno ga je izbjeći i zbog toga jer je dodatna otežavajuća
okolnost to što je jednosmjerno. Problem je u tome što mogućnost vršenja obostranih izmjena
nije moguća što direktno dovodi u pitanje integralnost konfiguracije i održavanje iste kroz
upotrebljivane nizove alata.
5.2. Zajednički pristup alatima
Naredni nivo integracije je zajednički pristup alatima. On omogućuje korisniku da se
više alata koji su različiti pozove na isti način, recimo iz padajućeg menija. Ovo najviše dolazi
do izražaja u multitasking okruženju jer se alati mogu otvarati simultano, isto tako ulazi se
mogu kodirati ručno a izlazi dizajna se upoređuju ručno kako god je to korisniku najpogodnije.
Kao primjer možemo navesti kada korisnik istovremeno treba dijegrame strukture, dijagrame
tokova podataka i još uz to izvorni kod i riječnik podataka a sve njih različiti alati održavaju.
Kada se zajednički pristup alata koristi u ovakvom okruženju, moguće je značajno
uporstiti razmjenu podataka iz jednog alata u drugi alat i to tako što se uvede procedura
prevođenja koja je uproštena izborom makro funkcije ili običnim izborom menija što je jako
čest slučaj u praksi.

11
 5.3. Zajedničko upravljanje podacima
Ovakav način umpravljanja podacima je zamišeljen tako da se u samo jednoj logičkoj
bazi podataka drže svi podaci tj. da su u njoj integrisani podaci iz više alata. Ova zajednička
baza može biti fizički centralizovana ili decentralizovana. Na ovaj način integrcija značajno
uprosti razmjenu informacija te diže nivo na kome su podaci integrisani. Odlika svakog alata je
da se najaktuelnijim podacima može trenutno pristupiti i da su stalno dostupni, u ovu kategoriju
uglavnom spadaju oni podaci koji su stalno ažurni. Istovremeno na ovaj način se stiče još jedna
prednost a to je da se lako upravlja verzijama alata i lako se mogu kontrolisati prava pristupa.
Kod kontrole prava pristupa to se uglavnom radi na takav način da se ručno sve
kontroliše pomoću procedura prijavljivanja i odjavljivanja. Tu je još jedna od dodatnih
pogodnosti a to je da je tvorcima softvera omogućeno da kombinuju poslove i rade na različitim
djelovima softvera a to sve zahvaljujući funkciji integrisanja podataka. Često ovakva grupa
alata posjeduje i karakteristiku provjere što omogućuje da se utvrde nekonzistentnosti među
rezultatima između različitih autora.
Iako se zajednički upravlja na istom nivou podacima iz alata koji su različiti ti alati ne
poznaju interne structure podataka međusobno te u dizajnu predstavljaju semantiku. Problem
predstavlja to što je i dalje potrebno prevođenje koje se vrši ručno ako želimo da izlaz nekog
alata koristi neki drugi alat.
5.4. Podjela podataka
U slučaju dijeljenja podataka integracija se vrši bez ikakve transformacije, ovaj način
integracije je najjednostavniji jer structure alata su kompatibilne, imaju isto tako istu semantiku
što i omogućuje njihovu direktnu upotrebu bez nekih dodatnih transformisanja. Pri samom
dizajniranju void se računa o tome da svaki alat bude kompatibian sa drugim alatima i tako je
omogučeno nesmetano djeljenje podataka.
S obzirom na sve navedeno, treba još napomenuti i to da se dijeljenje podataka najčešće
primjenjuje ukoliko se radi o alatima istog proizvođača ili ukoliko dođe do strateškog
povezivnja više proizvođača sa ciljem da naprave takav alat. Ovakve intervencije se u nekim
slučajevima vrše čak i ako zahtjev potiče od samo jednog korisnika. Najbitniji dio posla za
ovakav metod povezivanja odradili su standardi za integraciju CASE alata koji su omogućili
dobru osnovu za to.
5.5. Međusobna operatiblnost
Najviši nivo integracije jeste međusobna operatibilnost. Tu se pojedinačni alati integrišu
i da bi se postigla neophodno je da bude realizovana zajednička podjela podataka i zajednički
pristup. Pored ovoga da bi se ostvarila puna međusobna integrisanost u CASE okruženju
moraju se ispuni još dva uslova tj. elementa:
 Sredstva kontrole
 Upravljanje meta podacima
Pod meta podacima smatramo sve one koji su proizod nekih od CASE alata, pored toga
oni moraju nositi i informaciju o samom procesu softverskog inžinjeringa.
Pod meta podacima podrazumjevamo:
1. Definicije objekta
2. Zavisnosti i veze među objektima
3. Dizajnerska pravila
4. Procedure, događaje i tokove procesa
12
 Sredstva kontorle služe da se ostatku okruženja od strane pojedinačnih alata dostavi
obavjest o nekim značajnijim događajima. Pod ostatkom okruženja se podrazumjevaju
rukovodioci podatka, ostali alati ili neko treći. Takođe pored samog obavještavanja moguće je i
slanje zahtjeva za određenu akciju nekom servisu ili alatu, to se radi pomoću trigera. Kao
primjer može se navesti neki slučaj kada recimo alat za dizajniranje treba da obavjesti alat koji
upravlja konfiguracijom u slučaju kada se kreira neka nova verzija dizajnerskog dokumenta da
bi alat koji upravlja konfiguracijom mogao izvršiti provjeru da li je taj document konzistentan.
Sredstva kontrole su ta koja pomažu da se integritet okruženja održi te ona su takođe ta koja su
dužna da obezbjede sredstva koja su potrebna za automatizaciju standardnih procedura i
procesa.

6. Izbor CASE tehnologije

Ovaj dio posla praktično obavljaju organizacije koje žele nebaviti neku od CASE
tehnologija. Uglavnom svaka od organizacija se vodi nekim svjoim zahtjevima i potrebama
kada nabavljaju tehnologiju.
Prilikom procesa procjene prolazi se kroz sledeće korake:
 Analizranje zahtjeva i potreba korisnika
 Analiziranje postojećeg okruženja
 Utvrđivanje potencijalnih CASE tehnologija
 Izbor tehnologije te ocjenjivanje kvaliteta
Veoma značajan ako ne i najznačajni korak pri odabiru CASE tehnologije je analiza
zahtjeva i potreba korisnika. Za opredjeljivanje koji tačno model softvera će se primjeniti treba
organizacija da se opredjeli isto tako da odluči o osnovnim upravljačkim te tehničkim
zadacima. Ukoliko neki zadatak zelimo i realizovati bilo da se radi o djelimičnoj ili potpunoj
realizaciji ti zadaci se prethodno moraju tačno identifikovati da bi se mogla realizovati pomoć
automatizovanih alata.
Prethodni metodološki koraci su uvijek u potupunosti povezani sa analizom postojećeg
okruženja. Od CASE tehnologije se očekuje da bude okruženju potpuno prikladna, ali u svakom
slučaju uvijek treba ostaviti prostora za ograničenja jer su moguća i treba ih uzeti u razmatranje.
Neka od njih su recimo: dosadašnja praksa, iskustvo zaposlenih, odnosi sa dobavljačima,
vrijeme, novac itd. Ovakva ograničenja nije dovoljno samo identifikovati nego ih je potrebno i
analizirati, te da se utvrde mogućnosti njihovog otklanjanja ili aspekti mogućih promjena.
Naredni korak je identifikovanje potencijalne liste CASE tehnologija, tu se korisniku
praktično nude tehnologije za koje se smatra da bi ga potencijalno mogle zadovoljiti u
zavisnosti od njegovih zahtjeva i potreba. Izbor tehnologija je već sada jako veliki uz tendenciju
brzog daljnjer razvoja i rasta. Postojeće tehnologije se promovišu kroz reklamne materijale,
prezentacije itd.
Najznačajni korak u ovoj metodologiji je ujedno i poslednji. Na svaku od CASE
tehnologija koje su u potencijalnoj listi identifikovane se primjenjuju svi kriterijumi koji su
identifikovani. Za potrebe najobjektivnije selekcije postavljaju se kriterijumi, pri tome su na
vrhu liste vrijeme i troškovi. Ako je moguće najbolje je da sam dobavljač tehnologije dođe te na
licu mjesta testira i upozna tehnologiju.

13
 Glavni pokazatelj u kojoj mjeri neka tehnologija zadovoljava kriterijume koji su
postavljeni treba da budu zapažanja i bilješke sa testa. Najviše pažnje se daje najviše rangiranim
kriterijumima. Zaposleni u organizaciji bi u suštini trebali da budu ti koji će donijeti finalnu
odluku jer na kraju krajeva oni su ti kojima je u interesu da naprave dobar proizvod kako bi
ostvarili veću dobit.

7. Pravci razvoja CASE tehnologije

Kao elemnti softverskog inžinjeringa CASE tehnologije imaju primarni cilj a to je da

ponude odgovor na trenutne i buduće potrebe tog istog inžinjeringa.
Neke od njih su:
1. Stvaranje nekih od opštih šablona
2. Instrukcije koje se primjenjuju na prirodnom jeziku
3. Potreba za utvrđivanjem jedinstvenih standarda
Zadatak CASE tehnologija koje su standardizovane je da obuhvate brojne formalne
metode kao i standarde te da obezbijede adekvatan nivo dokumentovanja. Još jedan od zadataka
CASE tehnologija je da pomogne u upravljanju projektom razvoja softvera te da omogući
njegovo lakše i bolje održavanje. Ukoliko bi se CASE tehnologije pravilno primjenjivale to bi
doprinjelo efikasnom upravljanju troškovima kao i da proizvodi koji se izrađuju budu
kvalitetniji a da se pored toga svega vrijeme izrade skrati.
U tri grupe se mogu svrstati CASE tehnologije od kojih se očekuje da odgovore na ove
zahtjeve:
 Interne
 One koje su namjenjene prototipskom razvoju softvera
 Tehnologije podrške
CASE tehnologije koje su inteligentne možemo doslovno nazvati alatima budućnosti.
Njihova svrha je da uz minimalno uljučivanje čovjeka omoguće razvoj nekog računarskog
softvera koje bi poslije koristili kompleksni računarski sistemi. Takođe još jedan jako bitna
stvar su troškovi i od CASE tenologija se očekuje da na tom polju budu efikasne i efektivne.
Ova grupa tehnologija mora omogućiti da se pogodne metode odaberu i to automatizmom da bi
se mogli izvršavati kompletni zahtjevi kao i razvoj softvera. Još jedan zadatak koji se mora
obaviti su sami detalji i isto tako i nekonzistentnost te da se pojava iste spriječi.
Komponente tehnologija budućnosti:
 Moduli funkcija koji su odgovorni za zadatke u dizajniranju i analiziranju
softverskog sistema
 Simulacije pomoću kojih se ponašalje softvera koji se projektuje provjerava
 Dokumentacija koja omogućuje inžinjerima da u svakoj fazi u razvoju softvera
mogu da prate razvoj svih zahtjeva
 Matrice koje za zadatak imaju da daju podršku kada je riječ o logičkim greškama
te da sačuvaju softver od isih, pored toga ukoliko dođe do odsutnosti ulaza ili
izlaza potrebno je da to signaliziraju
 Za čuvanje i skladištenje matrica, dokumentacije te modula funkcija koristi se
riječnik podataka

14
 Elementi karakteristika koje su uključene u inteligentne CASE tehnologije:
1. U svakoj fazi životnog ciklusa pokrivaju softverski razvoj
2. Planiranje je uključeno
3. Dobra grafička podrška i alati koji su na znanju zasnovani
4. Automatizovano testiranje, kodovanje i dokumentacija
5. Reinžinjering softvera takođe podržan
6. Softver se može upotrijebiti više puta
7. Kompletan sistem kao i program mora biti u potpunosti konzistentan
8. Automacko integrisanje kodiranih modula s tim da se prije kodiranja testira
projekat
CASE tehnologije koje se u razvoju softvera koriste za prototipski razvoj morale bi
pomoći buduće verzije da komunikacija između samih projektanata sa krajnjim korisnicima
bude efektivna i efikasna. Najbolji načan za to bi bio da prije nego sam korisnik uđe u velike
investicije da se izradi neki prototip koji bi bio eksperimentalnog tipa. To bi bilo zamišljeno na
taj način da se ektani na ulazu te meniji razvijaju dok se u isto vrijeme prikazuje šta vidi
korisnik na ekranima na izlazu. Na kraju, kada bude donesena odluka za izradu softvera tada se
počinje sa pisanjem programa.
Upotreba simulacije se koristi da bi se definisale i provjerile neke od performansi kao
što su recimo vrijeme prolaza, vrijeme koje je potrebno za pristup bazi podataka kao i vrijeme
za generisanje podataka i još nekih koji su sistemu potrebni. Princip simulacije je zamišljen
tako da se ulazi demonstriraju pa da se zatim, na osnovu njih demonstriraju izlazi, s tim da
trebaju biti upravo takvi kakvi će biti u izvršenju te da tako korisnik može dobiti predstavu
kakvi će biti u izvršenju.
Koncepcija CASE tehnologija za podršku je takva da one bez greške podržavaju i to
nezavisno jedna od druge aktivnosti upravljanja projektom, generisanje test slučaja, kao i
vrednovanje kvalitativnih performansi. Daljnja integracija sa intelignetnim CASE
tahnologijama kao i CASE tehnologijama za prototipski razvoj softvera je predviđenja za ove
tehnologije u daljnjem periodu.

15
8. Modeliranje poslovnih podataka pomoću CASE alata

CASE alati su takođe primjenu našli u velikoj mjeri u poslovnom svijetu. Cilj preduzeća
je od starta bio da se realizaciji i projektovanju svojih informacionih sistema koji su korišteni za
poslovne svrhe pristupe korištenjem CASE metodologija koje su bile najsavremenije, ti
najnoviji alati su u svojoj osnovi imali riječnik podatka. Na početku razvoja zbog malih resursa
koji su bili potrebni za rad sam izbor alata bio je skroman. CASE alat su dobili na značaju
vremenom kako se brzina i snaga računara povećavala.
Generisanje baze podataka i modeliranje poslovnih podataka u jednom poslovnom
sistemu, koji bi se kao takav morao sastojati od poslovnih podataka koji su neophodni da bi taj
isti sistem funkcionisao. Funkcionisanje nekog posovnog informacionog sistema je zamišljeno
kao jedan cjelovit i integralan postupak. Baza podataka je veoma bitan dio sistema i njen značaj
se jasno ogleda u tome što svi podaci moraju da budu obuhvaćani u njoj jer se na temelju njih
donose odluke u poslovanju.
U bazi podataka svi odnosi kako postoje u realnom svijetu tako moraju biti i zabilježeni,
logika povezivanja u bazi podataka je organizovana na taj način. Korištenjem savremenih
CASE alata izrađuje se logički relacioni model podataka i generišu se relacione baze podataka
korištenjem automatike. Korištenjem ovih alata omogućeno je izdvajanje logičkog relacionog
modela koji je veoma detaljan i u ovom slučaju on se tretira kao proizvod koji je nezavistan.
Ovaj model je realizovan na ovakav način jer tako nudi mogućnost u poslovnom sistemu da se
vrši nezavisna implementacija aplikacija kao i kontrola razvoja u poslovnim procesmia. Postoji
nekoliko važnih CASE alata koji se u svakom slučaju moraju pomenuti sa aspekta moguće
izrade fizičkog ili logičkog modela podatka kao i kada se radi generisanje fizičke baze podataka
iz nekog modela koji je razvijen, naravno podrazumjeva se da je proces automacki.
Pod razvojem informacionog sistema smatramo proces koji obuhvata korektnu i
cjelovitu izradu rešenja, ona bi služala kao pomoć poslovanju tako što bi se njome odmah uvela
i komunikaciono-informaciona tehnologija. Ona omogućuje unapređenje poslovne tehnoloigije
u toj organizaciji za koju se sam sistem razvija tako što podrži sve poslovne procese na najbolji
mogući način. Naručilac je taj koji je odgovoran u najvećoj mjeri za funkcionisanj tog
razvijenog sistema, što se ne odnosi nužno na osobu nego u dosta slučajeva na samu
organizaciju koja naručuje neki sistem. Potencijalni problem je to što se neke greške i nedostaci
uočavaju tek kada je sistem razvijen i kada je taj informacioni sistem već uveden. Ukoliko se
uoči neki problem to znači da se mora prilagoditi ili popraviti.
Kada dođe do toga da je potrebno prilagođavanje, najveći problem je što sve to košta i
direktno utiče na cijenu uvođenja, što utiče na kompletan projekat, čak može doći i do toga da
odnos troškova i prihoda u cjelini dobije negativan predzank. Da bi se sve ovo izbjeglo,
prvenstveno zbog rizika od mogućih nepredviđenih troškova prvenstveno razvija se sistem za
kontrolu koji bi naručiocu direktno omogućio uvid i kontrolu tako da on u toku postupka prati i
nadrire postupak dok je isti još u toku. Sredstvo korištenja sistema i za kontrolisanje razvoja je
najčešće logički model podatka. Za ovakvo funkcionisanje potrebno je da prethnodno bude
ispunjen uslov da sam logički model podatka bude izrađen kao zaseban softver te da je isti
vlasništvo naručioca. Da bi ovo bilo izvodivo neophodno je da se koriste CASE alati koji
automacki da generišu iz objekta baze podataka logički model podatka pored toga što može da
automacki generiše model podatka iz modela podataka.

16
 8.1. Implementacija
Da bi se neke poslovna tehnologija određenje organizacije mogla unaprediti nužno je
dobro poznavati sistem poslovne tehnologije koja treba unapređenje. Prethodno zadani cilj je to
što uvijek vodi sam organizacioni sistem, te pri tome kreira dodatnu vrijenost tako što pretvara
izlazne i ulazne vještine. Razlikujemo dva moguća stanja prilikom izrađivanja modela, to je
neko trenutno ili sadašnje stanje i stanje kojem se teži, a to je unapređeno ili buduće stanje.
Gneneralno, sve faze razvoja se mogu svrstati u tri cjeline, na taj način dijelimo
projektovanje i razvoj cjelovitog ingormaconog sistema, to su:
 Kreiranje plana strategije informacionog sistema
 Generisanje baze podataka i njeno modeliranje, razvoj aplikacija
 Stavljanje sistema u funkciju
8.2. Sistem kao naručilac
Ostvarivanje nekog prethodno zamišljenog cilja je svrha svakog realnog poslovnog
sistema koji se nalazi na tržištu. Za nesmetan rad i obavljanje čak i nekih svakodnvnih poslova
organizacije koje su savremeno orjentisane ne mogu bez da im neki sistem koji je dobro
informatički razvijen pomogne, poenta je da se podaci mogu po potrebi koristiti u bilo kojem
trenutku i da se svi podaci koji su potrebni čuvaju.
Pred svaki informacioni sistem se postavljaju određeni poslovni zahtjevi za taj sistem,
vremenom ti zahtjevi postaju sve opsežniji, detaljniji i sofisticiraniji. Cilj svih informacionih
sistema je da u što većoj mjeri i u svakom pogledu odgovore na zahtjeva koji su postavljeni.
Kada je riječ o informacionim tehnologijama kao takvim uvijek se nude u praksi dvije opcije za
poboljšanje ili uvođenje nanovo informacionog sistema. Ukoliko je potrebno razvijaju se
tehnologije vlastite podrške ali takođe je moguća i kupovina gotovog rešenja. Na izbor između
ove dve opcije da li da se razvija novi softver ili kupuje neki postojeći utiče jako puno
kriterijuma. Nekada se pred informacioni sistem predstavljaju neki zahtjevi koji su zaprvo
potrebe koje su stvarne dobijene prethodnom analizom, te se u ovom slučaju sistem koji je
prilagođen svim tim zahtjevima pravi posebno za tog kupca po kriterijumima koje diktiraju isti
ti zahtjevi.
Postoji i druga varijanta, a to je kupovina nekog gotovog sistema. Za ovu opciju se
najčešće odlučuje ako je sistem već u upotrebi u nekoj sličnoj organizaciji pa je on praktično
več prilagođen svim njihovim zahtjevima ili se poslovni sistem, ukoliko je to potrebno prilagodi
samom softveru. Najvažnije je da zahtjevi na samom početku pudu precizno i jasno definisani
za šta je prvenstveno odgovoran sam naručilac. Ukolio se odabere pravi poslovni sistem onda
on poduprire poslovanje na najbolji način, te nekim novim potencijalima unapređuje poslovne
procese te da bi na koncu uvođenjem informacinog sistema cjelokupno poslovanje bilo
unapređeno i olakšan dolazak do tražanog cilja.
8.3. Metodika proizvođača softvera kao implementatora
Cilj ovog posla, kao i svakog drugog, je naravno ostvarivanje profita. Dakle, softver koji
proizvođač napravi je za prodaju. Da bi profit ostvaren prodajom bio što veći cilj je da se sa što
manje radih sati te uloženog truda proda čim više i na taj način izvuče traženi maksimum. U
zavisnosti od tipa preduzeća jer su uglavnom različita tako su različite i same metode rada.
Kako vremenom neke firme imaju jako puno razvijenih programa iza sebe nije rijedak slučaj da
nešto od tih postojećih softvera pokušaju implementirati u neki novi softver. U zavisnosti od
samog naručioca nekog sistema se dobija konačni rezultat ovakvog poslovanja, nekad se ista
rešenja implementiraju jako puno puta i svojim imenom su praktično referenca kvaliteta i
17
garancija sigurnosti kupcu. Suprotno tome postoji i slučaj kada se radi o proizvodima koji nisu
globalno poznati pa tako proivođači su prinuđeni da sam softver prilagođavaju zahtjevima
kupca. Ali čak i u ovom drugom slučaju, gdje se generalno rade novi softveri uglavnom postoje
dijelovi softvera ili aplikacije za koje se mogu iskoristiti neki postojeći programi. Ovo je
praktično neka vrsta parcijalnog rešenja jer se postojeći programi povezuju u neke veće
programe ili se nadograđuju po potrebi, mada ima varijanti u praksi kada se čak dijele na više
manjih programa.
8.4. Mogući problemi između izvođača i naručioca
Generalno gledano, postoje dva potencijalna problema. Praćenje proizvođača softvera,
kao prvi, ukoliko reimo on pogriješi pri izvođenju same baze i zbog toga ona na kraju ne
odgovara traženim zahtjevima sistema. Drugi problem je to što je u većini slučajeva poslovanje
u toku izgradnje softvera dinammično te se mnogi faktori mjenjaju u svakom trenutku pod
uticajem takve radne sredine. Ovaj problem je jako bitan jer samim tim što se promjene kostano
dešavaju tako dolazi i do promjene i u samim podacima sa kojima se radi.
Ovi problemi su specifični i zvog toga jer ih je jako teško uočiti do samog kraja procesa.
Predvidjeti ih je gotovo pa nemoguće. Greške se uglavnom pokažu pri samoj implemantaciji
novog rešenja, a to je već u praksi druga faza izvođenja. Naravno, sve ovo se odražava na
financijsku stranu priče što problem odmah čini još većim a pored toga i sistem je u tom slučaju
mnogo teže uvesti. Često za posledicu imaju i to, da na kraju, kada se sistem uvede on ne
funkcioniše kako je očekivano te ne daje tražene rezultate i adekvatna poboljšanja. Ukoliko se
stvar ne može ispraviti drugačije, izvođači su prisiljeni da odrade navnovo ciklus poboljšanja,
to na kraju jako puno košta u odnosu na planirani budžet pa često može dovesti i do toga da
troškovi premaše ostvarenu dobit. Na kraju, važno je napomenuti da ovakvi problemi zanju
odvući pažnju od stvarnih ciljeva a kako su sistemi na kojima se radi, kako je već rečeno,
uglavnom dinamični to može odvesti izvođača u nepovrat jer se infrastruktura konstantnu
mijenja i jako je teško na kraju dobiti traženi rezultat.
8.5. Kontrola implementacije
Kako je već rečeno, dvije faze se podrazumjevaju pri izvođenjju projekta, to su:
 Generisanje baze podataka i njeno modeliranje
 Stavljanje informacionog sistema u funkciju
Kako je druga faza prilično kompleksna, moguće ju je podijeliti na divije cjeline jer
kako danas postoje i razvijaju se neki novi alati pomoću kojiih se logički relacioni model
izrađuje mnogo je lakše raditi ukoliko se ovaj korak podijeli na sledeće dvije podfaze:
 Detaljan logički relacioni model se izrađuje i koristi kao generator za samu
fizičku bazu podataka
 Da bi se upravljalo modeliranom bazom podataka izrađuju se poslovne aplikaije
Prednost kada se ovako dobijena podfaza definiše kao nezavisna faza je ta što se na taj
način poslovnom sistemu daje mogućnost da kontroliše razvoj i implementacija samih
poslovnih aplikacija, njegova osnova je sačinjena od logičkog modela same baze podataka koji
je detaljan. Logički model mora biti u skaldu sa stratiškim planom informacionog sistema i
njegovog razvoja.
Cilj ovoga jeste prvenstveno da se svi problemi, nedostaci ili eventualne greške uoče
prije početka implementacije, to se radi na takav način da se postojeći sistem nadogradi unutar
samog sistema povratnom vezom te tako da praktično na neki način kontroliše sam sebe. Baza
podataka vidi ovaj element povratne veze u praksi kao novi logički model. Ovakav vid kontrole
18
u informacionom sistemu predstavlja praktično u strateškom planu razvoja sistem kontrole koji
se izvodi a da se pri tome temelji na generisanju i upravljanju modela baze podataka koji sadrži
logički objekat. On ima funkciju da osigura od samog početka kada se neka poslovna aplikacija
počne razvijati pa sve do implementacije koja je konačni korak te ima zadatak da osigura
minimane troškove te da na kraju se dobije takva komunikacijsko-informaciona podrška koja će
naručiocu najbolje odgovarati te mu ponuditi poslovni sistem koji udovoljava svim njegovim
zahtjevima.
Kada se logički model podatka izdvoji kao poseban objekat informacionog sistema i kao
takav je dostuan korisnicima tog istog informacionog sistema on tada ima više pozitivnih
faktora kada gledamo sa gledišta korisnika prvenstveno i poslovnog sitema, te prednosti su
sledeće:
 Baza podataka koja je stvorena kao početna verzija logičkog modela koji je
razvijen i on je generator te baze, ona je tada za razvoj nekih novih aplikacija
jako dobra kao osnova
 Oslanjajući se na aktualne aplikacije jača se baza poslovnih podataka i njena
nezavisnost
 Prateći podaci se mnogo jasnije povezuju sa pocesima
 Bazi podataka se može pristupati eksterno korištenjem nekih od SQL upita koji
su van standarnih aplikacija
 Kada je potrebna neka dorada određene aplikacije ili modela na taj način se
podstiče stvaranje kreativnih ideja
 Samom proizvođaču poslovnog softvera je upućen znatnio manji broj upita od
strane korisnika
Jednom kada se izradi, poslovni model je značajno kompunikaciono sredstvo između
proizvođača softvera kao izvođača sa naručiocem tj. nekim poslovnim sistemom. Korištenjem
modernih CASE alata koji su danas dostupni na tržištu iz logičkog modela se fizički model
baze podataka automacki generiše te za sobom odmah povlači i samu bazu podataka. Postoje
CASE alati koji pored svojstva da generišu automacki iz modela podataka bazu podataka več da
i iz objekra baze podataka generišu logički model. Na ovaj način interaktivni odnos se diže na
jedan novi nivo, misli se na komunikaciju proizvođača softvera sa poslovnim sistemom
odnosno naručiocem. Pozitivna strana svega je što se to pozitivno odražava na bolji kvalitet
softvera, te se napredkom aplikacije brže razvijaju, implementiraju brže što na kraju znači niže
troškove i financijsku dobit kada se novi informacioni sistem stavi u funkciju.

19
9. Neki od CASE alata

Koncepcija CASE alata je takva da se pomoću njih mogu izrađivati različiti modeli
informacionih i poslovnih sistema. Današnji CASE alati mogu izraditi mnogo različitih modela
ali zapravo snaga same tehnologije nije u tome, ona se zapravo nalazi u repoziroriju znanja tj.
središnjoj riznici, svi objekti koji su korišteni u modeliranju se unose u nju odnosno njihovi
opisi. Pored objekata veći dio CASE alata posjeduje opis i popis veza među objektima koji su
različiti. Veze takvoga tipa se u vim modelima odražavaju, tako se za modelirani sistem
osigurava logička ispravnost i konzistentnost. Sam kvalitet nekog CASE alata, što je bitno reći,
ne zavisi od veličine riznice koju taj model podržava ili samog broja modela već je bitan način
njegove primjene i te svrha kojoj je namjenjen. Kao što se vidi iz prethodnog da bi se odabrao
dobar CASE alat nije dovoljno da bude najtraženiji na tržištu ili da ima najviše modela već on
mora odgovarati potrebama poslovnog sistema za koji će biti korišten. Zbog toga je važno da se
kod odabira dobro poznaju potrebe informacionog sistema da bi CASE alat nio u mogućnosti na
najbolji način njegoc daljnji razvoj da podrži.
Kao primjer u ovom slučaju navode se tri alata, a to su: Visio, COOL:bizz i Erwin.
Osobine ovih softvera važno je sagledati iz više aspekata da bi se stekla jasna slika o čemu se
radi, počevši od fizičkog modela podataka, mogućnosti izrade logičkog modela te generisanja
automacki iz fizičke baze podataka iz modela i obrnuto.
9.1. Visio2003
Ovaj alat je dio MS office paketa, on pruža mogućnost da se pomoću njega izrade
različiti modeli i to već sa verzijom koja se dobija tipičnom instalacijom. Kod ovog softvera
dijagrami pripadju jednom od 16 tipova modela tj. kategorija. Interfejs je orjentisan korisnički
te su simboli za crtanje veoma jednostavni za korištenje, pored toga dosta je primjera različitih
modela te oni omogućuju da alate koriste čak i osobe koje ne posjeduju mnogo zannja o samom
projektovanju softvera. Dijagrami se sastoje od opcija koje su standardne a to su one za
izrađivanje intiteta, zatim atributa entiteta, veza različitih vrsta i stributa entiteta koji su ključni.
Različite modele repozitorija nije moguće izraditi pomoću ovog programa, to je zato što
on nema ni vertikalne ni horizontalne povezanosti modela. Modeli se mogu prenositi u druge
programe ali samo u svrhu prezentovanja. Dakle, ovaj CASE alat ne posjeduje mogučnost da
generiše automacki bazu podataka niti obratno da iz baze podataka izvrši automacki postupak
generisanja modela. Iz prethodno navedenog može se zaključiti da model koji je izrađen u
ovom alatu ne može biti korišten u svrhu primjene logičkog modela podatka gdje bi on bio
proizvođaču nekog softvera kontrolno sredstvo na način na koji je to prethodno opisano.
9.2. COOL:Bizz
Kompanija Sterking software 1994. godine razvija CASE alat pod imenom COOL:Bizz.
Kao i prethnodi, ovaj softver takođe koristima za izradu raznih modela koji su potrebni da bi se
prikaz informaciong i poslovnog sistema oblikovo. Kada je riječ o korisnički orjentisanom
interfejsu tome se ovde nije posvetilo toliko pažnje kao u prethodnom slučaju. Ovde se sa liste
odabiu dijagrami, te se liste opcija nalaze u svakom od ovih dijagrama i sa njih možemo
odabrati neki od ponuđenih objekata. Zbog svega navedenog može se zaključiti da je program
namjenjen stručnjacima koji su već upoznati sa metodama kao i tehnikama modeliranja
poslovnih podataka te poslovnih procesa.
Za sve modele jedne datoteke koji se nalaze u riznici koja je jedinstvena ogleda se snaga
ovog alata jer postoji takva forma jedinstvene riznice u njemu. Ovakava riznica, koja je
20
jedinsvena sastoji se iz liste i opisa svih objekata, isti mogu biti element svakoga modela koji je
u pojedinoj datoteci sadržan. Pored toga ova datoteka sadži listu svih veza među pojedinim
objektima kao i njihov popis i opis. Na ovaj način je formalna i logička konzistentnost
osigurana svim modelima.
Dijagramom koji sadrži poveznicu između atributa, entiteta i relacija je omogućena
izrada logičkog modela podatka. Ovakav dijagram sadrži opcije za izradu veza između entiteta
kao i izradu samih entiteta, ovo su zapravo standardne opcije ali pored toga moguće je unijeti i
dodatna svojstva kojima se objekti zapravo definišu, to je primjenljivo za svaki objekat koji je
izgrađen. Dodatna pogodnost ovog modela je što je moguće fizički model podatka generisati
automacki tj. relacijski model koji sve elemente potrebne za generisanje fizičke baze podataka
sadrži u sebi. Primatni ključevi kao i sekundarni su takođe sadržani u relaciskom modelu i
pored toga sadrži i ripove entiteta za rješavanje veza koji su asocijativni. Svaki entitet moguće
je detaljnije definisat tako što upišemo njegova dodatna svojstva. Između fizičkog i logičkog
modela podataka moguća je i povratna veza.
Kod koji strukturu baze podataka definiše generiše se na osnovu fizičkog modela
podataka. Ovaj kod učitava program za generisanje baze podataka koji je odabran, te se na
osnovu njega definišu fizičke šeme baze podataka koje su relacione kao i veze koje postoje
između njih. Bazu podataka koja je generisana na ovakav način može se popunjavati podacima
nekog poslovnog sistema koji su stvarni. Bazu podataka je moguće sinhronizovati novim
relacijskim atributama ili šemama ukoliko se vremenom neka stavka promjeni. Takođe, iz
logičkog modela podatka može se generisati fizički pomoću ovog alata, kao i generisanje baze
podataka na osnovu fizičkog modela ali obrnuta varijanta ovog postupka nije izvodiva pomoću
ovog alata.
9.3. Erwin
Pomoću ovog alata može se kreirati te održavati fizički i logički model podatka kao i
generisanje fizičke baze podataka koja njima odgovara. Za rad sa ovim programom potrebno je
imati mnogo znanja o samom postupku modeliranja podataka iako je interfejs orjentisan
korisnički. Ovim alatom može se vršiti izrada fizičkog ili logičkog modela kao i istovremeno i
fizičkog modela i logičkog.
Logički model sadži:
1. Entitete
2. Veze između entiteta
3. Atribute entiteta
4. Primarne te sekundarne ključeve
Sadržaj fizičkog moela:
1. Tip atributa u relaciskim šemama
2. Indekse veza na druge šeme
3. Denormalizovane tablice
4. Informacije o bazi podataka
5. Ograničenja
U logičko-fizičkom modelu sadržani su elementi oba zasebna modela.
Opis i popis svakog od entiteta dio su same datoteke koja posjeduje riznicu zaduženu za
pamćenje ovih podataka. Skup podataka koji ga opisuju odnosno atributa postoji za svaki
entitet. Ovde se nalaze svi podaci o njima, kao što su primarni i sekundarni ključevi, zatim
podaci o vezama sa drugim entitetima, informacije o procedurama koje su ugrađene kao i
21
okidačima za njih itd. Fizičku bazu podataka automacki je moguće generisati na osnovu
fizičkog modela podatka. U ovu bazu se kasnije upisuju poslovni podaci. Razlika u odnosu na
prethodne alate je ta što ovaj podržava i obrnutu varijantu tj. da se fizički model podatka dobije
iz baze podataka automacki.
Reverzno inžinjerstvo je stručni naziv za ovakav postupak. Kao proces reverzno
inžinjerstvo iz baze podataka obuhvata informacije o relacijskim šemama, kao i njihovoj
strukturi i atributima. Struktua zapravo predstavlja veze kojima su povezane relacione šeme.
Nad nastalim modelom nakon što se u program prenesu informacije moguće je praviti
odgovarajuće izmejene u skaldu sa promjenama koje se dešavaju u poslovnim podacima kao i u
strukturi istih. Nakon određenih promjena baza podataka se nanovo sinhronizuje sa novim
modelom podataka. Ovaj alat posjeduje i sistem za izvještavanje pomoću koga je moguće
dokumentovati cijeli proces.

10. Reverzno inžinjerstvo

Kada na osnovu programskog proizvoda koji je prethodno realizovan primjenimo

postupak automatizovanog ili ručnog generisanja prograskih ili projektantnih specifikacija taj
postupak u razvoju programskih proizvoda nazivamo reverzno inžinjerstvo. Ova tehnika je
razvijena zbog pojave sledećeg slučaja. Dešava se to da u jako puno organizacija se ulaže
mnogo financiskih, materijalnih, kao i ljudskih resursa da bi se informacioni sistem razvio i
eksploatisao. Prelaskom na nove informacione tenologije postavlja se zahtjev da se ne kreće od
nule kada je riječ o razvoju inovirane verzije informacionog sistema. Ideja je da se postojeće
verzije informacionog sistema u što većoj mjeri iskoriste ulaganjem napora i iskustva da se one
poboljšaju te na taj način ostvari financijska ušteda u odnosu kada bi se sav posao radio od
početka.
Ciljevi reverznog inžinjerstva:
 Za određen programski proizvod koji je aktuelan potrebno je da se programska i
projektna dokumentacija generiše ukoliko to nije prethodno obavljeno. Ovo se
radi sa namjerom da se trenutna verzija tog programskog proizvoda održi za šta
se na ovaj način stvara osnova.
 Ukoliko je cilj da se razvije nova verzija programskog proizvoda onda se u
formatu koji je doslovno razumljiv CASE proizvodu moraju generisati
programske i projektne specifikacije tog proizvoda.
Zadaci reverznog inžinjerstva:
 Za samu pazu podataka potrebno je generisati implementacioni opis, za taj
postupak osnova su sledeći parametri:
1. U bazi postoje realni podaci
2. Stanja riječnika podataka pod kojim se baza podataka posmatra, a dio je
konkretnog sistema koji bazom podataka upravlja.
3. Format datoteka i njihov opis tekuće verzije sistema tj. programskog
koda aplikacije
 Na osnovu implementacione šeme same baze podataka generiše se konceptualna
šema baze podataka
 Tekuća verzija informacionog sistema sadrži programske kodove aplikacija na
osnovu kojih se generišu programske specifikacije.
22
 Od prirode zadatka koji se rješava zavisi koja će se tehnika reverznog inžinjerstva
odabrati, isto važi i za njenu automatizovanu primjenu. Pored toga na izbor još utiče i kvalitet
ulazna specifikacije na koju je potrebno primjeniti reverzno inžinjerstvo. Tako kvalitet ulazne
specifikacije direktno utiče na kvalitet samog generisanog rezultata reverznog inžinjerstva.
Recimo ako se za generisanje impementacione šeme baze podataka primjernjuje tehnika
reverznog inžinjerstva u takvoj situaciji najbolji rezultat se može očekivati ako se iz riječnika
podatka sistema za upravljanje bazom podatka iskoriste ulazni podaci dok u slučaju kada se
realni podaci iz baze koriste kao ulazna specifikacija tada se ne može očekivati dobar rezultat.
Prethnodno navedena teorija ne mora biti tačna u svakom slučaju. Ako nije dovoljno
informativan riječnik nekog konkretnog sistema koji se koristi za upravljanje bazom podataka
ili ako u tom istom riječniku nedostaju neki podaci tada se ne može očekivati dobar rezultat.

11. Modeliranje sistema

Pomoću hijerarhiskih dijagrama prikazuje se funkcionalna dekompozicija realnog

sistema. Struktura programske podrške informacionog sistema iskazuje se korištenjem istih ili
različitih dijagrama.
Da li se radi o elementarnoj funkciji ili ne radi treba da se naglasi i ovaj podatak pored
osnovnih podataka. Ukoliko se podrazumjeva da će se funkcija cijela izvršiti prilikom priliom
njeno započinjanja tada se ona klasifikuje kao elementarna, u suprotnom poništvaju se svi efekti
njenog izvršavanja u cjelini. U strukturi proizvoda koja je hijerarhiska dekeompovanje
elementarnih funkcija nije nužno te one kao takve predstavljaju listove te funkcije.
Dekompovanje atomarne funkcije sa cilem da se elementarna preciznije specificira dovodi do
toga da u tom slučaju atomarne funkcije u hijerarhiskoj strukturi predstavljaju listove.
Mouguće je da se za neku funkciju ukoliko je to potrebno završetak izvođenja
posmatrane funkcije inicira specificiranjem neke druge funkcije. Tekstualni opisi u slobodnom
formatu mogu se pridružiti za svaku funkciju, njima se priroda funkcije opisuje detaljno kao i
ograničenja i pravila pri njenom izvršavanju itd.
Nakon što se konceptualna šema baze podataka obilkuje pomoću dijagrama tipova, nudi
se mogućnost projektantu da zada za svaku funkciju naredne podatke:
 Tip entiteta koje će prilikom svog izvođenja funckcija koristiti
 Načini upotrebe za svaki tip entiteta mogu biti: modifikacija, dodavanje,
selekcija, arhiviranje, brisanje ili neki drugi
 Atribude koje za svaki od tipova entiteta funkcija koristi prilikom svog
izvođenja
Dijagramski orjentisani alati se koriste da bi se organizaciona struktura sistema
definisala što je moguće hijerarhiskim navigatorom objekta te se tako riječniku podatka
direktno pristupa. Kada hijerarhiski navigator objekta koristimo za definisanje organizacione
strukture u tom slučaju se elementi organizacione strukture kreiranjem pojavi tipa objekta
definišu. Hijerarhiska struktura organizacionih cjelina se uspostavlja tako što se oznake
nadređenje organizacione cjeline direktno navedu. Ne postoji poseban alat koji bi se mogao
koristiti da se lokacijska struktura sistema defniše kao dijagraski tip. Za to se koristi pristup
riječniku podataka koji je direktan. Svaki element prostoren strukture pri tome predstavlja jednu
pojavu. Moguće je orgenizovati hijerarhiski prostornu strukturu, kao cijelinu ili u dijelovima na
taj način što oznaka određene lokacije navodi.
23
 Moguće je različite tipove matrica zavisnosti definisati, dole navedene se koriste za fazu
analize i snimanja karakteristika:
 Matrica kojom se informacije iskazuju, njome se iskazuju informacije koji se
funkcije u posmatranim orgnaizatorskim cjelinama obavljaju
 Matrica pomoću koje se raspored organizacionih cjelina u relanom sistemu
iskazuje
 Matrica kojom se iskazuje kako se u posmatranim procesima koriste tipovi
entiteta
 Matrica kojom se iskazuje u procesima koji se posmatraju način kako se
pojedinačne vrijendnosti tributa upotrebljavaju
11.1. Dijagrami procesa
Za vizulani prikaz se koriste dijagrami procesa, pomoću njih se realnom vremenu vrši
prikaz scenarija. Koncepti na kojima se zasniva su sledeći: depozit, triger, tok, funkcija,
organizacijona jedinica i ciljni rezultat. U hijerarhiji dekompozicije svaki dijagram se formira
za jedan proces. Odabir procesa za dijagram koji se crta vrši se svaki puta kda se novi dijagram
otvara. Na dijagramu se prikazuju procesi koji su procesi koji su podređeni kontekstnom
porcesu međutim na njegovom mjestu se može naći i neki drugi proces kojii je dio funkcionalne
dekompozicije. U terminologiji ovoga alata procese na dijagramu nazivamo akticnstima tj.
koracima.
Vrstu aktovosti je moguće ne specifirati posebno ili se mogu deklarisati kao:
 Interna aktivnost
 Eksterna aktivnost
 Tačka odluke
 Aktivnost izvještavanja
 Aktivnost obuhvata podataka
Isti slučaj je i sa depozitom koji takođe može ostati ne specificiran ili se deklariše kao
depozit podatka ili skladište materijla. Tok se deklariše kao tok materijala, tok podatka ili
privremeni tok, u suprotnom, kao i u prethodnim slučajevima ostaje nespecificiran.
Prikaz organizacione strukture realnog sistema, kao i oblikovanje je omogućeno alatom.
Na krajnjem lijevom dijelu dijagrama prikazuje se dio hijerarhije organizacijonih jedinica ili
ona u cjelini. U pogledu izvođenja pojedinih aktivnosti u slučaju za neku organizacionu
jedinicu svaka od njih ima svoju oblast integracije koja se prikazuje na dijagramu.
Za svaku aktivnost je moguće:
 Definisati vrijeme pristupa depozitu kao i pripremno te radno vrijeme koje je
potrebno da se izvrši neka aktivnost
 Ukupno vrijeme se može izračunati koliko neki tok ili aktivnost traju, isti slučaj
je i kod potrebnog intervala da bi se pristupilo depozitu
 Cijenu za sve individulane korake je potrebno odrediti
 Na dijagramu pri prezenracii potrebno definisati multimedijalni element
Vrijeme početka i završetka svake aktivnosti je moguće izračunati automacki na osnovu
ovih podataka te odrediti put koji je najduži vremenski tj. koji se na dijagramu može
klasifikovati kao kritičan. Izvođenje aktivnosti na dijagramu je moguće simulirati vizuelno tj.
napraviti multimedijalnu animaciju dijagrama. Za zadavanje čitavih nizova podataka moguće je
koristiti ove alate, to se prvenstveno odnosi na aktivnosti i organizacione jedinice ali i za druge
releventne činioce kao i generalno za svu dokumentaciju koja je vezana za kvalitetu sistema.
24
 11.2. Dijagram toka podataka
Funkiconalnu dekompoziciju informacionog sistema prati organizacija dijagrama toka
podatka. Saglasno sa hijerarhijom koja je uvedena automacki se numerišu procesi. Za koji
dijagram toka se crta podatak je proces koji se mora odrediti svaki puta kada se neki novi
dijagram otvara. Ovaj proces se naziva kontekstni proces. Samo procesi koji su direktno
podređenji hijerarhiski u slučaju za neki proces se mogu prikazati na dijagramu. Ukoliko su
procesesi putem nekog drugog alata već kreirani njih je moguće preuzeti iz riječnika podataka,
druga solucija je da se novi proces direktno kreira te je on nakon doga u hijerarhiskoj
dekompoziciji funkcija vidljiv.
Ukoliko se na sledećem nivou dekompozicije novi dijagram otvori za kontekstni proces
u novom dijagramu se mora odabrati jedan proces koji je podređen. Nakon toga svi spoljni
entiteti, kao i depoziti podataka te tokovi podataka se automacki prenijeti sve to što je sa njim
povezano i taj podređeni proces se uzima u novom dijagramu kao kontekstni proces. Da bi
tokovi podataka bili balansirani za to postoje posebne taktike koje to obezbjeđuju po nivoima
dekompozicije.
Obavezno je da se odredi naziv za svaki tok podatka, depozit ili spoljni entitet pri
crtanju dijagrama toka, ovo ograničenje je jako bitno. Veza toka sa nekim procesom je
obavezna pa makar to bilo i samo sa jedne strane. Takođe, dva procesa se mogu direktno
povezati tokom podataka.
Alati osiguravaju da se sadržaj toka podatka, kao i depozita podatka definiše
navođenjem tipa entiteta i atribuda entiteta koje sadrži tok ili depozit koji se posmatra. Ukoliko
je to potrebno definiše se za spoljni entitet tip entiteta na koji se odnosi ili se navodi kojoj
organizacijonoj cejlini pripada. Potrebni opisi ili napomene se dodaju ukoliko je to potrebno
isto kao i kod procesa.
11.3. Konceptualna šema baze podatka
Tehnika dijagrama tipova i poveznika se koristi u slučaju kada je šemu beza podataka
potrebno konceptuapno modelirati.
Koncepti koji su posredno ili neposredno podržani su:
 Tip poveznika
 Kardinalitet tipa poveznika
 Slabi i regularni entitet
 Kategorizacija
 Hijerarhija
 Domen
 Ključ i atribut entiteta
Direktnim kreiranjem novih tipova poveznika i entiteta se oblikuju ovi dijagrami u
okviru aplikacionog sistema koji je izabran. Po potrebi se iz riječnika preuzimaju prethodno
kreirani tipovi poveznika i entiteta bez obzira da li pripadaju nekom drugom aplikacionom
sistemu ili izabranom sistemu. Konceptualna šema beze podataka inforamcinog sistema koja je
jedinstvena se oblikuje na ovaj način.
Nije ista u svim alatima notcija za prikaz dijagrama. U nekima se recimo tipovi
poveznika prikazuju linijama i simbolom za romb dok u drugim dva tipa entiteta povezuje samo
jedna linija. Zavisno od parametara tipa poveznika ova linija može biti puna, djelimično
isprekidana ili isprekidana te se na njoj takođe mogu po potrebi pisati i dodatne oznake.

25
 Tipovi poveznika imaju sledeće parametre:
 Kardinaliteti završnog i polazmog kraja
 Opcionalnost završnog i polaznog kraja
 Vrsta tipa poveznika
 Zabrana ili dozvola za prevezivanje
U alatima se čitav niz podataka zadaje pored samih naziva domena i atributa, koji su sa
stanovišta izrade konceptuapne šeme baze podatak važni. Oni su pored toga bitni i sa gledišta
implementacionog prjektovanja šeme baze podataka kao i samih aplikacija informativnog
sistema.
Koncept nasleđivanja je takođe pored toga podržan, na taj način nudi se mogućnost da
od domena koji mu je naslijeđen sam domen preuzme neke od osobina. U cilju da se dodatne
informacije prezentuju svako atributu te isto tako i entitetu je moguće dodati i tekstualni opis.
Taj opis će se poslije pri generisanju ekrana automacki preuzeti sa pomoćnim informacijama.
11.4. Interna i implementaciona šema
Korištenjem odgovoarajućih alata pomoću relacionog modela podataka oblikuje se
implementaciona šema baze podataka. Za formiranje interne šeme baze podataka koristi se alat
za direktan pristup riječniku. Implementaciono projektovanje same baze podataka se započinje
prevodom entitetsko-relacijskih dijagrama iz šeme baze podataka koja je konceptualna u model
podatka koji je relacioni. Za ovakvo prevođenje upotrebljava se alat koji pomoću konceptualne
šeme baze podataka generiše šemu baze podataka koja je relaciona tj. njenu prvu verziju.
Relaciona šema koja je izgenerisana na takav način dalje se dorađuje. Takođe i opcija direktnog
oblikovanja implementacione baze podataka postoji, u tome slučaju nije potrebno da se prije
toga modeliraju entitetsko-relacijski dijagrami te da se isti prevode u model koji je relacioni. U
samom alatu definicija tabele je polazni koncept, u tom slučaju pojam same relacije
reprezentuje tabela. Skup ograničenja i skup obelježja su osobine svake tabele što je isto kao i
kod relacija. Takođe, treba napomenuti da su obilježja su isto što i kolone, za svaku od njih se
još mora definisati čitav niz implementacionih karakteristika ili ih je moguće preuzeti iz
konceptualnog modela.
Kategorije karakteristika su sledeće:
 Podaci koji definišu kolonu (tip, domen, inicijalna vrijednost, dozvola odnosno
zabrana nula vrijendosti itd.)
 Podaci koji prezentuju kolonu (naslovn kolone, dužina, način te pormat prikaza,
poruka o semantici itd.)
 Validacioni podaci kolone (poruka koja se javlja ako je validaciono ograničenje
narušeno)
 Dodjeljivanje vrijednosti kolone
 Podaci o denormalizaciji
 Dodatni podaci kolone (tekstulana polja koja mogu biti različitih vrsta,
najvažnije je polje u kome se pmoćne informacije o koloni definišu)
Kada se SQL opis automacki generiše koriste se karakteristike kolona šeme baze
podataka i tada se programske specifikacije modula generišu, oni sadrže posmatrane kolone i
tabele u svojoj podšemi. Nebitno da li se radi o međurelacionom ili jednorelacionom
ograničenju sva ograničenja šeme baze podataka koja je relaciona se vezuju tehnički kod ovog
alata za odgovarajuću tabelu.

26
 Tipovi ograničenja koja se definišu za tabelu:
 Primarni ključ se ograničava (primarni ključ sadrži niz informacija da li je
dozvoljena ili ne modifikacija ključa)
 Ekvivalentni ključ se ograničava (ekvivalentni ključ sadrži niz informacija da li
je dozvoljena ili ne modifikacija ključa)
 Jedinstvena vrijednost se ograničava (kombinacija je jedinstvena ako su
vrijednosti svih obiježja rezličite od nule)
 Torka se ograničava (mora biti zadovoljen logički izraz koji je naveden ili je
potrebno navesti ime logičke funkcije čijim se pozivanjem sprovodi kontrola
dozvoljenih vrijednosti)
 Ograničenja stranog ključa
Kada se radi o ograničenjima stranog ključa potrebno je navesti ime referencirane tabele
u kojoj se odgovoarajući primarni ključ nalazi, obilježja koja sadrži strani ključ zatim aktivnost
(ova aktivnost ako dođe pri prisanju do narušavanja referencijalnog integriteta sprovodi se isto
važi i ako se takav slučaj javi pri modifikaciji podataka) i korespodentno obilježje primarnog
kluča za svako obilježje stranog ključa. Pored svega, navodi se poruka za svako ograničenje
koja se u slučaju narušavanja prikazuje i pored toga se navodi mjesto realizacije.
Implementacija tabele se formira korištenjem alata u okviru jednog korisničkog imena
te jedne baze podataka za svaku tabelu. Neki od parametara fizičke organizacije tabele mogu se
definisati na nivou implementacije tabele kao i prava pristupa za neku grupu korisnika ili nekog
korisnika kao pojedinca. Da li se može kreirati indeks nad samom tabelom je jedna od fizičkih
karakteristika organizacije koja je bitna. Konceptu tabele je direktno podređen koncept okidača
baze podataka, to bi zanačilo da se u okviru svake tabele definiše okidač. Triger, odnosno
njegov proceduralni dio se korištenjem jezika koji je proceduralno orjenrisan.
Raličite pomoćne informacije se takođe mogu automacki preuzeti ili zadati nad tabelom,
one su u slobodnom formatu prezentovane. Ovo se radi u svrhu toga da bi se u narednim
programskim aplikacijama može automacki generisati na osnovu oviih informacija opcija za
pomoć. Još se može i vođenje dnevnika promjena nad tabelom obezbijediti da bude automacko
a realizuje se korištenjem tabele promjena koja je zasebna.
Putem ovakvih alata se pored tabela mogu i procedure definisati kao i funkcije te paketi
funkcija i procedura, pored toga kursorska područja se takođe mogu deklarisati. Upotrebom
jezika koji je proceduralno orjentisan mogu se specifirati svi nabrojani objekti čijs je namjena
izvršavanje od strane servera kao i implementiranje u okviru riječnika baze podataka. U riječnik
se smiještaju kompletni programski kodovi kod ovakvih objekata što je takođe bitno za
naglasiti.
Koncept replikacione slike, kao i koncept pogleda su konceoti koje alati posjeduju pored
gore navedenih. Pojmu SQL pogleda je ekvivalentan koncept pogleda a za definisanje
replikacione šeme distribirane baze podataka koristi se koncept replikacione slike. Opis šeme
podataka se automacki generiše na osnovu interne šeme baze podataka tj. implementacione
šeme baze podataka te ju na odgvarajuči server baze podataka treba implementirati. Za
generisanje programskih modula kao i osnov za modeliranje programske specifikacije koristi se
implementaciona šema.

27
 11.5. Programska specifikacija modula
U nastavku slijedi par riječi o alatu pomoću koga se prikazuju podaci grafikonski,
kreiraju izvještaji i oblikuju bibiliotečki moduli a to su programske specifikacije za rad sa
bazom podataka. Povezivanje programskih modula međusobno kao i formiranje strukture
menija aplikacije uz moguće prenošenje putem parametara podataka između modula je moguće
isto tako pomoću ovog alata.
Prvo se definiše pošema kod ovog alata za sve programske module, projektant se ovde
oslanja na implementacionu šemu paze podataka koja je oblikovana prethodno. Skup izabranih
šema relacija iz šeme baze podataka čini podšemu skupa sa vezama kojima se označava
prostiranje ključeva. Skup obilježja koji je potreban se određuje za svaku šemu relacije iz
podšeme. Po jedno vezano polje se pravi u okviru modula za svako obilježje podšeme. Od
samog međusobnog odnosa šema relacija podšeme zavisi struktura ekranske forme budućeg
programskog modula, on je njihovom fizičkom pozicijom na dijagramu definisan.
Dvije uloge može imati šema u relaciji podšeme:
 Bazne šeme (namjena im je manipulacija podacima)
 Liste izbora (prikazuju listu izbora dodatnih odataka te dozvoljenih vrijednosti
na samom ekranu)
Šeme relacije podšeme su dio komponente programskog modula gdje jednu logičku
cjelinu treba da predstavlja jedna komponenta programskog modula za prezentovanje podataka
te isto tako može biti sačinjena od par šema relacija podšeme. Recimo modul napravljan da u
formi zaglavlje-stavke predstavlja modele na ekranu će imati dvije komponente. Jedna će
podatke koji odgovaraju stavkama prikazivati dok će druga biti zadužena za prikazivanje
podataka zaglavlja.
Zaglavlje ekranske forma u budućnosti predstavljat će komponenta sa pozicijom na
dijagramu iznad neke druge komponete te pored nje i odgovarajuća bazna šema relacije a
stavke zaglavlja će reprezentovati podređena komponenta. Za šemu relacije koja je data listu
izbora predstavlja šema koja je pozicionirana na desnoj strani u odnosu na naku drugu šemu
relacije. Dopušteno je i formiranje mnogo složenijih struktura, pod složenijim se misli na one
koje su u odnosu na dijagram složenije.
Proceduralna logika programskog modula se definiše izborom operacija ažuriranja koje
su standardne kao što su brisanje, unos ili modifikacija te selekcijom podataka tj. postavljanjem
upita. Potrebno je odobriti ove upite putem programskog modula nad bazom podataka tj. nekim
njenim dijelom tj. baznim šemama relacije podšeme.
Kada govorimo o opisivanju proceduralne logike programskog modula postoji još
mogućnosti, sam programer može definisati neke nestandardne postupke obrade podataka
pomoću posebnih funkcija i procedura. U okviru programskog modula definišu se funkcije i
procedure i kao takve može se za njih reći da su lokalnog karaktera. Druga varijanta je da se
definišu u kao poseban bibliotekarski modul čija bi namjena bila da pakete, procedure i funkcije
koje su smještene na klijentu skladišti. Moguće je rederenciranja bibilioteka pomoću drugih
programskih modula. Referenciranje funkcija i procedura u okviru programskih modula koje su
namjenjene za implementaciju na server baze nude se kao treća mogućnost.
U ekranskom modulu programer može definisati lokalne trigere korisničkog interfejsa.
Na osnovu komponente modula, samog ekranskog modula ili veznog polja definiše se ovakav
događaj. Proceduralna logika koju je potrebno izvršiti vezuje se za događaj, ona se praktično
svodi na funkcije i procedure koje su prethodno definisane. Komandna polja kao i nevezana
28
polja takođe se mogu kreirati. Za prikaz sumiranih vrijednosti, kao i vrijednosti koje se pomoću
funkcije koja je prethodno definisana koriste se nevezana polja, te ona kao takva niisu ni sa
jednim od obilježja baze podataka u direktnoj vezi. Element kojim se akrivira izvršavanje neke
specifične proedure naziva se dugme, njega reprezentuje komandno polje.
Veze između specifikacija modula moguće je vizuelno prikazati, oni pozivanje nekog
modula od strane drugog modula reprezentuju, sve to zahvaljujući tome što alat omogućuje da
se struktura obilukuje dijagramski. Definisanjem stranica za prikaz podataka kao i samij
prozora mjenja se vizualni izgled ekranske forma modula što je takođe moguće. Na osnovu
dijagrama tipova poveznika i entiteta koji su prethodno izrađeni mogu se generisati automacki
specifikacije programskih modula, važnu ulogu nose i matrice atribute entiteta povezuju sa
funkcijama kao i tipove entiteta sa funkcijama. Informacije o izlaznim i ulaznim parametrima u
programskom kodu mogu sadržati tokovi podataka.
Činjenice o alatima:
 U svoj riječnik smiještaju čitv proceduralni programski kod
 Putem koncepata koje sadrže moguće je aplikacije informacionog sistema
oblikovati do najsitnijih detalja
 Prema potrebama korisnika moguće je sopstvene alate prilagoditi
Na kraju treba napomenuti da aplikacije koje su izrađenje na ovaj način čak mogu biti
primjenjene kao finalan programski proizvod jer ovakav proizvod CASE tahnologija generiše
aplikacije koje su na toj razini.

12. Kratka istorija CASE alata

Na početku se razvoj programskih proizvoda oslanjao na razne alate ra proramiranje.

Bilo je tu nekoliko faza:
 Mašinski jezici su bili prvi koji su se upotrebljavali ali se tražila bolje solucija jer
su bila drastično zavisni od hardvera i jako teško čitljivi
 Naredni su bili asembleri koji su bili neznatno napredniji ali još se značajno
izraženim manama svog prethodnika
 Posle na red dolaze jezivi treće generacije koji su orjentisani proceduralno.
Veliki napredak je napravljen zato jer oni nisu bili u tolikoj mjeri zavisni od
hardvera te struktuirano programiranje ulazi u upotrebu.
Nakon što su uvedeni jezici treće generacije produktivnost programirana se povećala tj.
programski proizvodi su bili kvalitetniji a izrada mnogo brža. Na početku je bilo i nekih od nuz
pojava jer se zbog naglog povećanja profuktivnosti izgubilo na brzini kao i širini primjene.
Dakle, došlo je do toga da je bio potreban novi hardver i pored toga neki asemblerski programi
su unapređeni na jezike treće generacije da bi mogli ostati u upotrebi.
Tada na scenu nastupa softverska kriza zato jer se očekivalo da odmah softver koji je
napisan u jeziku treće generacije zadovolji odmah potrebe krajnjeg korisnika. Najveći porblem
je bio jer je ulaganje bilo drastično povećano a nisu dobijeni željeni rezultati. Jedan od najvećih
problema je bio taj što je usljed održavanja nekog programa programer gubio jako puno

29
vremena te na taj način praktično je bio blokiran daljni razvoj i pored toga se przo uvidjelo da je
programiranjem na ovaj način gubljeno puno vremena i da je bilo neefikasno.
Dolazi se do toga da je najviše vremena bilo potrebno da bi se održali proizvodi koji su
već na tržištu. Israživanja takođe pokazuju da se veći dio grešaka pravio prilikom samog
razvoje tokom projektovanja te analiziranja zahtjeva, a manji dio se javljao pri realizaciji. Još
jedan veliki problem je bio to što se tek možda polovnia grešaka otklonila prije nego je softver
isporučen, ovo je bilo posebno problematično jer svaka greška koja se kasnije otklanjala je
plaćena mnogo više nego da se sanirala prije isporuke. Sve to dovodi do podjele finansija koja
je bila krajnje neprirodna, odnosno večinski dio sredstava je trošen na održavanje dok je znatno
manji dio odlazio na sam razvoj. Pored finsncijske štete koja je nastala još jedan veliki problem
je predstavljalo vremensko kašnjenje.
Softversko inžinjerstvo je bila disciplina u računarstvu koja je predstavljena kao rešenje
softverske krize, a on je prethodio i samom razvijanju CASE tehnologija. Softversko
inžinjerstvo se baziralo na ideji da pristup razvoju programa bude inžinjerski i metodološki te
da se poštuju dati rokovi te da se kvalitetan softver primjenom odgovarajuće tehnike plasira a
tržište.
Pojava CASE alata je zapravo uslijedila nekon što je zaključeno da je drugi i treći uzrok
softverske krize zapravo bio jer za razvoj programskih proizvoda nije bilo dostupno dovoljno
softverskih alata. Ideja CASE proizvoda zasnivala se na automatizaciji zadataka te da se na
takav način otklone problemi koji su prethodili.
Primjenjivana je takođe metodologija pristupa koji je bio struktuiran te su na različitim
nivoima detaljnosti crtani dijagrami upotrebom više ili manje formalnih tehnika. Pored toga
kako je sve bilo povezano ukoliko se nivo detaljnosti mjenjao na jednom dijagramu često je to
povlačilo potrebu da se isto uradi i na ostalim, kao i sa samim izmejnama na dijagramu, ako se
jedan izmjeni često su te izmjene direktno uslovlajvale promjene na ostalim dijagramima.
Problem je bio takođe to što ukoliko se radilo o većem projektu jako teško je bilo sve to
efikasno obaviti ručno.
Još jedan novost koju CASE tahnologije uvode na polju same organizacije ticala se
podataka jer CASE alati su koristili jedinstven riječnik podataka koji je predstavljao bazu
podataka u koju je sve smiještano. CASE alati su bili u mogućnosti da opis šeme za neki
konkretan sistem baze podataka izgenerišu koristeći implementacionu šemu baze podataka, te
da programske aplikacije informacionog sistema izgenerišu korištenjem programskih
specifiakcija. Sve ovo omogućuju generatori koda.
Dolazi se do jezika četvrte generacije koji su treću generaciju jezika nadogradili jer su
bili znatno pregledniji, lakše je bilo programirati sa njima te su bili na velikom nivou
deklarativnosti. Tačnu definiciju je zapravo teško dati jer su ovi jezici pedstavljali jako širok
pojam, počevši od alata koji su jednostavni pa sve do jezika koji su bili veoma razvijeni. Kako
je jako teško bilo tačno definisati šta su to zašravao jezici četvrte genracije usvojio se neki
pojam koji je bio nešto opširniji a to je okruženje četvrte generacije.
Sve se zasnivalo na jednom jedinstvenom riječniku podataka što je kod jezika četvrte
generacije posebno izraženo jer je ideja bila da geeralno svi alari budu integrisani kao dio
CASE okruženja koje bi bukvlno predstavljalo jedno široko okruženje za razvoj programskih
proizvoda. Još jedna poteškoća koju se nastojala prevazići je dugotrajno i neproduktivno
programiranje. Unapređene CASE thnologije su imale znatne prednosti ali i neke nedostatke, i
jedni i drugi su navedeni u nastavku.

30
 Prednosti:
 Proces izrade programskog proizvoda znatno je olakšan i ubrzan
 Kako je olakšano pronalazenje grešaka znatno su smanjeni troškovi održavanja
aplikacija
Nedostaci:
 Znatno kompleksnije aplikacije su tražile bolji hardver što je dovodilo do toga da
lošije rade sa istim hardverom u odnosu na svoje prethodike
 Širina primjene manja
Pored toga bilo je moguće prototipski pristupati razvoju softvera što se može posmatrati
kao dodatna prednost. Kada je riječ o nedostacima može se slobono reći da su praktično
očekivani jer je prvenstveno potreba za boljim hardverom sasvim očekivana iako je u početku
sam razvoj hardvera bio značajno kompleksniji i sporiji nego danas.
Brzo se došlo do zaključka da se ulaganjem u hardver može snačajno isplatiti jer na
samom razvoju aplikacija se mnogo uštedi kao i održavanju programa posle. Neduko nakon
početka primjene jezika četvrte genracije došlo se na ideju da se oni kombinuju sa svojim
prethodnicima tj.jezicima treće generacije. Tako je recimo za neke složenije aplikacije kada se
kod generiše uočeno da u jeziku četvrte generacije su potrebna mnoga prilagođavanja dok su
uspješno realizovani bez greške upotrebom jezika treće genracije.

31
13. Zaključak

Jasno je da su CASE alati jedan veoma značajan dio programiranja. Doveli su do

mnogih unapređenja u izgradnji softvera ali isto tako u značajnoj mjeri olakšali život samim
programerima. Jasno je da kada neko naruči određen softver želi dobiti što bolji proizvod a da
cijena koju plaća bude što manja. Zbog toga su CASE alati jako značajni jer ne samo da
olakšavaju programiranje nego na osnuvu njih se dobije mnogo na ušteti vremena a samim tim
se štede sredstva za razvoj što na kraju dovodi do većeg profita. Sva ova priča je išla tim tokom
jer se na drugoj strani nalazi kompanija ili pojedinac koji te iste proizvode izrađuju te naravno
da će oni htjeti da uz minimalne troškove te uloženi rad i vrijeme ostvare što veću zaradu. Pored
samog profita zančaj CASE alata je bio i u tome što su softver značajno približili široj grupi
korisnika tj. smanjena je potreba za velikim predznanjem da bi se neki softver koristio jer je
okruženje bilo sve više korisnički orjentisano.
Još jedna velika prednost kod CASE alata je što imaju sistem unutrašnje kontrole koji
praktično rečeno provjerava sam sebe te se ne taj način veliki broj grešaka otkloni što
predstavlja veliki plus jer se dobija softver koji funkcioniše bez problema a pored toga se ne
troše sredstva na popravljanje grešaka koja su bila značajna ukoliko se greške servisiraju nakon
što sam program dospije na tržište. Važno je napomenuti da se CASE alati konstantno
usavršavaju te se samim tim širina njihove primjene povećava. Pored svega toga, iako je
tehnologija danas na jako visokom nivou razvijenosti nekada ni jedan sofrver ili mašina ne
mogu zamjeniti iskusno mišljenje nekog programera za određen problem jer oni svoja rešenja
temelje na iskustvu i na intuiciji kakvu ima samo čovjek i koja je ponekad jedino moguće
rješenje.

32
14. Literatura

1. Alempije, V., Zahorjanski, M.: Modeliranje informacionih sistema, Beograd

2016.
2. Dobrović, Ž.: Strategijsko planiranje, Zbornik radova konferencije CASE 12,
Opatija 2000
3. Uzelac, J.: Kibernetsko upravljanje poslovnim sistemima, Ekonomski
fakultet Sveučilišta u Rijeci, Rijeka 2002.

33