1

1. Paradigme arhitekture softvera

Primena raunara u nauno-istraivakom radu prouzrokovala je ovladavanje
sloenim tehnolokim procesima i novim proizvodima, meu kojima se nalaze i
kvalitetniji raunari. Ova povratna sprega dovela je do eksplozije znanja kojom su
nastale hardverske arhitekture izuzetno visokog kvaliteta. Razvoj softvera, meutim,
nije pratila opisana dinamika, jer se on mogao meriti porastom od svega nekoliko
procenata godinje. Poboljanje performansi u razvoju i korienju informacionih
sistema javljalo se skokovito, sa pojavom novih paradigmi arhitekture softvera.
Paradigme arhitekture softvera mogu se posmatrati i kroz etiri faze razvoja softvera.
Prvu etapu karakterie razvoj softvera koji su realizovali proizvoai raunarske
opreme, razvijajui kompletan neophodni softver za svoje proizvode. Drugu etapu
karakterie softver razvijen za viekorisniki rad u on-line reimu rada i pojava prvih
sistema za upravljanje bazama podataka. Treu etapu razvoja karakterie softver
za podrku distribuiranih raunarskih sistema koji su meusobno komunicirali i
pojava personalnih raunara, koja je jo vie iskazivala potrebu da se izmeni nain
razvoja softvera, odnosno potrebu da se brzo i jeftino dolazi do univerzalnih i opte
primenljivih programa. etvrtu etapu razvoja softvera karakteriu dalji razvoj
softvera za primenu snanih personalnih raunara, raunara povezanih u mree i
paralelnu obradu. Takoe, iz eksperimentalne u iroku upotrebu se stavljaju nove
vrste informacionih sistema kakvi su ekspertni sistemi, vetaka inteligencija i
neuralne mree, kao i objektno orijentisane tehnologije.
2. Monolitna programska podrka
U poetnom periodu primene raunara, od 1948. do 1965. godine, hardver je bio
izuzetno skup i ljudski rad potreban za razvoj softvera je bio zanemarljivo mali u
odnosu na hardver, pa je softver bio u potpunosti prilagoen hardveru. Ovaj period
nazivamo faza monolitne programske podrke i u njoj su programi proistekli iz opisa
postupaka bili vrsto vezani za ulazno-izlazne ureaje raunara i njegov monitorski
program. Programi su pisani u mainskom jeziku ili asembleru i to tako da njihovo
vreme rada bude to krae. Korisniki interfejs je bio vezivan za odreeni hardver i
sadrao je male mogunosti, a njegovo korienje je bilo krajnje nekomforno i
svodilo se na elektrinu pisau mainu u funkciji konzole.
3. Dihotomija aplikacija - sistemski softver
Povratna sprega nastala razvojem softvera uticala je na znaajno snienje cena
hardvera, poboljanje njegovih performansi i pojavu niza gotovih programskih
proizvoda koje su, zajedno sa hardverom, nudili njegovi proizvoai. Ovako formirani
interfejs poznat je pod nazivom sistemski softver i predstavlja prvi korak u razvoju
korisnikih interfejsa. Tako je nastala faza poznata pod nazivom dihotomija aplikacija
- sistemski softver i karakteristina je za period od 1965. do 1985. godine. Deo
sistemskog softvera blii hardveru naziva se operativni sistem, a deo blii
aplikacijama - pomoni programi. U ovoj fazi pojavljuje se multiprogramski rad. Ova
promena paradigme podigla je produktivnost programera i smanjila trokove za
njihovu obuku, koji u ovoj fazi koriste vie programske jezike i biblioteke napisanih
delova programa. Najvanija karakteristika ove faze je mogunost prenosa napisanih
aplikacija sa jednog raunara na drugi i to istog ili razliitih proizvoaa. Korisnici
poinju da se dele na profesionalce za razvoj programa - programere i na krajnje

korisnike, koji u ovoj fazi postaju aktivni, ali ne i dominantni. Korienje vizuelnog
alfanumerikog komuniciranja pomou terminala u interaktivnom reimu i razmena
podataka pomou telekomunikacija sa udaljenim raunarima postaju standardi
obrade podataka u ovoj fazi.
4. Paradigma korisniku bliskog sistema
Osamdesetih godina, sa pojavom personalnog raunara, dolazi do nove paradigme
arhitekture programske podrke, okruenja bliskog korisniku. Karakteristika ovog
perioda je kupovina gotovih reenja, to znai da korisnici kupuju mikroraunare sa
skupovima gotovih aplikacija koje slue za automatizaciju kojom se podie
produktivnost rada korisnika. Pad cena je drastian i sada su trokovi eksploatacije
personalnog raunara daleko ispod cene rada korisnika. U takvoj situaciji aplikacije
moraju korisniku pruiti okruenje slino onom na koje je navikao. Vei deo hardvera
i softvera preuzimaju ulogu interfejsa izmeu korisnika i aplikacije koji treba da
ispunjava njegove elje. Tako nastaje grafiki korisniki interfejs zasnovan na
korienju "ikona" koji nije karakteristian samo za hardver (ekrani u boji visoke
rezolucije i grafike kartice), ve i za softver (Windows). Aplikacije poinju da se
prodaju kao konfekcijski proizvodi, ijim se kombinovanjem vri automatizacija
odreenog poslovnog okruenja.
5. Raunarska mrea
Pojavom lokalnih raunarskih mrea personalni raunar postaje komparativno
najatraktivniji za realizaciju informacionih sistema odeljenja ili organizacija manje ili
srednje veliine. Razmena podataka sa irim okruenjem vri se pomou
telekomunikacione raunarske mree u koju se, pomou transportnih
komunikacionih protokola, povezuju raunari sa razliitim hardverom i operativnim
sistemima. Paradigmu raunarske mree karakterie podela aplikacije na sistemski
deo (ljusku) i korisniku, distribuiranu aplikaciju. Izmeu velikog broja modela
povezivanja distribuiranih aplikacija u primeni je dominantan TCP/IP, koji koristi
najvea svetska mrea Internet. Mree ovog tipa predstavljaju osnovu za globalne
informacione sisteme, kod kojih sve informacije, bez obzira na geografski poloaj,
postaju pristupane svim korisnicima u svetu.
6. Koncept upravljana projektima
Za realizaciju sloenih programa i projekata stvorena je koncepcija upravljanja
projektom (Project menager). Koncept je razvijen da bi se u sloenim projektima
postigli planirani ciljevi u planiranom vremenu i sa planiranim trokovima. Koncept se
bazira na uspostavljanju takve organizacione forme koja na najbolji nain
omoguava iskorienje raspoloive metode planiranja i kontrole za efikasnu
realizaciju projekta.

7. Definisanje koncepta upravljanja projektima (UP)

Prepisi celo 6. pitanje .plus ovo:
UP u sebi sadri: - Postavljanje cilja (rezultat, vreme i trokovi); - Planiranje
(odreivanje strukture, izraunavanje vremena, utvrivanje budeta i planiranje
resursa); - Organizaciju (funkcije, kompletiranje personala, neophodne instrukcije,
uzajamna povezanost); - Kontrola (rezultat, vreme i trokovi). Osnovne k-ke
koncepta UP su: - Definisanje i korienje najpogodnije organizacije za upravljanje
realizacijom projekta; - Formiranje i korienje odgovarajueg IS za upravljanje
realizacijom projekta pomou odgovarajueg softvera; - Korienje tehnike mrenog
planiranja i gantograme u planiranju, praenju i kontroli realizaciji projekta. Uspeno
UP u sebi sadri 8 funkcionalnih oblasti: - Upravljanje klimom projekta; - Upravljanje
trokovima; - Upravljanje vremenom; - Upravljanje kvalitetom; - Upravljanje ljudskim
resursima; - Upravljanje komunikacijama; - Upravljanje ugovaranjem; - Upravljanje
rizikom. Standardni programi za UP su: Primavera, Super project, Projacs,
PMCS/66, OPTIMA.

8. Upravljane softverskim projektima. CMM Model

Kvalitetni razvojni softverski paketi mogu se realizovati jedino kombinovanjem 3
kritina faktora: Dobrih kadrova, Upravljakih tehnika, Tehnologija. Sprovoenje
upravljakih tehnika spreava rasipanje ljudske energije (primena standarda
ISO9000 i SEI ). Najbolje organizacije fokusiraju se na sveobuhvatnu metriku
procesa i usavravanje, a prosene na formalizaciju testiranja, upravljanje
konfiguracijom, tehnike revizije koda kao i na formalizaciju odgovarajuih metoda
softverskog inenjerstva za sistemsku analizu, dizajn i implementaciju. Za dobro
upravljanje softverskim projektima potrebno je jasno definisati uloge i odgovornosti
unutar definisanog procesa. Definisani procesi se jasno auriraju i usavravaju kroz
pilot testove i analizu trokova.Potrebna je da menaderi prate kvalitet softverskih
proizvoda i zadovoljstvo korisnika. Ovakav okvir upravljanja softverskim projektima
predstavlja CMM model (model zrelosti projekta) koji trasira put za postizanje
kontrole razvoja i odravanja softvera. CMM ini 5 nivoa zrelosti procesa: - Inicijalni
nivo, k- e kao povremen ak kao haotini, samo su neki procesi definisani a uspeh
zavisi od pojedinanih napora; - Ponavljajui nivo, vri se planiranje i praenje
projekta. Ranija uspena iskustva se dosledno primenjuju; - Definisani nivo, i
upravljake i upravljane aktivnosti su dokumentovane i standaradizovane u
standardni softverski proces organizacije; - Upravljivi nivo, softverski proces se
procenjuju i kontroliu; - Opimizirajui nivo, konstantno se poboljava softverski
proces to se postie povratnom spregom koja ukljuuje sam proces i realizaciju
novih ideja i tehnolokih inovacija.

9. Metodologija - organizacioni aspekti

Osnova ove metodologije zasniva se ne sugestijama da projekat treba da realizuje
projektni tim koji se nalazi pod nadzorom upravljakog tima. Upravljaki tim izrauje
nacrt projekta i formira projektni tim. Rukovodei tim nadgleda posao, obezbeuje
potrebne resurse reava eventualne problema i slui kao iterfejs izmeu projeketnog

tima i ostatka organizacije proizvoaa. Rukovodei tim ne upravlja projektnim

timom ve to ini ef proj. tima. Projektni tim sadri vodeeg dizajnera koji je i voa
tima on odgovara i podnosi izvetaje rukovodeem timu. Ostali lanovi rukovodeeg
tima su implementator (programer koji pie kod) i tehniki recenzent (programer koji
ocenjuje tehnike aspekte implementacije). Ukoliko se radi o sloenom projektu on
se deli na podprojekte i stvara se vie projektnih timova. Meu njima je potrebno
ostvariti koordinaciju to je uloga koordinatora koji je ujedno i voa projekta. U
procesu planiranja identifikuju se standardi za kodiranje testiranje i upravljanje
konfiguracijom, voenje projektne dokumetacije itd.
10. Metodologija - procesni aspekti (PADRE metodologija)
Proces na nivou objekta sadri: 1. Postavljanje projekta: - organizacija izvoaa
(formiranje upravljakog tima); - Upravljaki tim (izrauje nacrt projekta i formira
projektni tim). 2. Planiranje projekta, u ovoj fazi projektni tim deli projekat na etape
vri ustanovljavanje standarda i procedura za postizanje kvaliteta dobija potvrdu za
planove od strane upravljakog tima. 3. Realizacija projekta, projektni tim prati
proces na nivou etapa, a upravljaki tim otklanja prepreke i obezbeuje
resurse. 4. Ocena projekta, oba tima rade na Pronalaenju naina za poboljanje
proizvoda projekta, planiranje projekta i naina njegove realizacije.
Proces na nivou etape sadri: 1. Planiranje etape, etapa se deli na module i vri se
dodela svakom lanu tima, te se dobija potvrda za planove od rukovodeeg
tima. 2. Realizacija etape, projektni tim prati proces na nivou modula i koriguje
proizvod etape. Voa tima otklanja prepreke i obezbeuje resurse, i prati rezultate
provere koju vri korisnik.3. Ocena etape, vri je projektni tim.
Proces na nivou modula sadri: 1. Planiranje modula, programer ili vodei
programer razvija dizajn implementacije i testiranje. 2. Realizacija modula,
programer vri programiranje modula pratei detaljno dizajn, vodi evidenciju o
napredovanju odgovarajuim razvojnim alatom i koriguje implementaciju prema
rezultatima provere koju vri projektni tim. 3. Ocena modula, voa tima i programer
rade na pronalaenju naina za poboljanje proizvoda modula.
Na svakom nivou proces ukljuuje sledee korake: 1. Planiranje (plan). 2. Realizacija
(Do). 3. Ocena (Evaluate). Svaki nivo takoe ukljuuje potvrdu planiranog koraka
(Approval) i iterativnu proveru (Review) i korekciju (Revise) rezultata koraka
realizacije.
11. Planiranje projekta i etapa
Planiranje se izvodi od vrha ka dnu dok se posao unutar etapa ne podeli na manje
delove (module). To nisu moduli u obliku podprograma ve jedinice posla. Svaki lan
projektnog tima koristi proces planiranja na nivou modula za upravljanjem razvoja
svog modula, dok voa tima upravlja serijom modula, to omoguava lake praenje
progresa u poslu, rano otkrivanje problema itd. Rezultat planiranja etape se koristi za
planiranje modula. To daje detaljan plan za etapu koji se sastoji iz Pert dijagrama,
kao dodatak ovome dodaje se i opis svakog modula to predstavlja preliminarni
dizajn.

12. Proces na nivou modula

Svaki modul prolazi kroz mini ivotni ciklus sa 5 kontrolnih taaka: Dizajn (20%),
Potvrda (5%), Kodiranje (40%), Provera (15%), Korekcija (20%). Na svakom nivou
modul prolazi sledee korake: 1. Planiranje (plan). 2. Realizacija (Do). 3. Ocena
(Evaluate). Svaki nivo takoe ukljuuje potvrdu planiranog koraka (Approval) i
iterativnu proveru (Review) i korekciju (Revise) rezultata koraka realizacije. to je u
sutini PADRE metodologija od vrha ka dnu. Ovakav ivotni ciklus u softverskom
ininjerstvu naziva se spiralni ivotni ciklus.

13. Iterativna strategija

Kompleksne sisteme je teko formalno specificirati. Nemogue ih je specificirati u
prvom ciklusu, a retko i drugom. Zbog toga se zahtevi kod ovakvih sistema menjaju
tokom razvoja. Zbog toga se prihvata iterativna strategija u razvoju softvera. Po
PADRE metodologiji postoji 5 tehnika za borbu protiv kompleksnosti
softvera: 1. Planiranje i realizacija, vri se razbijanjem projekta preko etapa na
dvonedeljne radne celine, module koji se realizuju kroz mini ivotni
ciklus. 2. Objektna tehnologija koja je vrlo pogodna za iterativni razvoj. 3. Alati za
realizaciju prototipova, omoguuju jednostavnu realizaciju dizajna aplikacija.
Realizacija prototipa i korisnikog interfejsa pomae dizajnerima da svoje ideje
iskau korisnicima. 4. Inkrementalno testiranje, svaki modul se potpuno testira pre
ukljuenja u postojei sistem. Programer pie test procedure kojima testira svoj
modul. 5. Spiralni ivotni ciklus.
14. Objektno orjentisana metodologija i distribuirani raunarski sistemi
Pri projektovanju IS koji e preslikati ponaanje i strukturu poslovnih sistema i ujedno
omoguiti transformaciju i rast sistema, dolazilo je do nezadovoljavajuih rezultata u
domenu fizike arhitekture IS i domenu arhitekture aplikacija koje opisuju poslovne
procese. Osnovni problem programera je kompleksnost ovakvog sistema. Poslednji
odgovor na izazov komleksnosti je objektni pristup u sagledavanju i modeliranju
modernog sveta. Ovaj pristup rezultira u paradigmi koja se u ambijentu
funkcionisanja poslovnih sistema naziva objektnom tehnologijom.

15. Objektno orjentisana tehnologija (OOT)

OOT je nain modeliranja realnih sistema. Poinje OBJEKTNO ORJENTISANOM
analizom koja je osnov za OBJEKTNO ORJENTISANO dizajniranje modela i preko
OBJEKTNO ORJENTISANOG programiranja rezultira u softveru sa eljenim
osobinama. Analitiaru je ostavljeno da odredi nivo apstrakcije na kome ga
interesuje ponaanje realnog sveta i da na osnovu toga projektuje osnovne
funkcionalne elemente posmatranog sistema u obliku klasa. Na osnovu klasa
analitiar e nasleivanjem osnovnih klasa e stvoriti itavu hijerarhiju elemenata
posmatranog sistema koje preslikavaju njihove atribute ponaanje i interakcije.
Objekt prezentuje objekt iz realnog sistema obuhvatajui njegove atribute, funkcije i
ogranienja. Svaki objekat poseduje identitet i komunicira sa okruenjem pomou

svojih metoda. Klase su tipovi podataka u nekom od programskih jezika koji

podravaju OBJEKTNO ORJENTISANU metodologiju. Enkapsulacija ili skrivanje
podataka, je zatita unutranje realizacije tipa od pristupa spolja. Ovo podrazumeva
strogo kontrolisan pristup podacima unutar tipa. Ova osobina obezbeuje
autonomnost tipa to eliminie rizik pojave greke u ostatku modela jer se ni jedan
drugi objekat ne oslanja na podatke koji mu nisu dostupni. Nasleivanje,
podrazumeva izgradnju novih, izvedenih klasa koje nasleuju podatke i funkcije od
ve definisanih klasa i jo im se dodaju nove f-je i podaci to rezultira u evoluciji
odreene hijerarhije klasa. Polimorfizam je k-ka koja podrazumeva mogunost
pojavljivanja u vie oblika. OBJEKTNO ORJENTISANI programski jezici
omoguavaju pomou definisanja virtualnih funkcija da se jedna ista virtualna
funkcija na razliite naine koristi u razliitoj hijerarhiji. Svi problemi iz inenjeringa
poslovnih procesa postaju tipovi podataka u domenu softverskog inenjerstva.
Objekti su potpuno ne zavisni od vrste programskih jezika u kojima su kodirani, od
alata koji je kreirao aplikaciju i od platforme na kojima ta aplikacija funkcionie.
OBJEKTNO ORJENTISANI pristup razvoju softvera se preslikava u domen
modeliranog sistema ime se u modelu IS i modeliranom poslovnom sistemu otvara
mogunost upravljanja rastom postojeih reenja uz potovanje izabranih
kriterijuma. Svako novo reenje je rezultat evolucije prethodnog, to smanjuje
razvojni ciklus i time prua bri odgovor na neophodnost konstantnih izmena.

16. Kategorija objekata

Postoje glavne 3 kategorije objekata: Poslovni, Tehnoloki, Aplikacioni. Svaka
kategorija ima specifinu namenu i moe se primeniti smo u svom domenu pri
projektovanju IS. Poslovni objekti predstavljaju autorne resurse iz poslovnog domena
i u sebi obuhvataju naziv, definiciju, atribute, ponaanje, veze sa okolinom i
ogranienja. Oni omoguavaju da se pravi podaci spregnu sa pravim procedurama
na pravom mestu to se naziva Semantika normalizacija. Tehnoloki objekti
predstavljaju programske ili tehnoloke koncepte koji sainjavaju aplikacije i
primenjene poslovne objekte. One su komponente IS i aplikativnog okruenja.
Primeri tehnolokih objekata su komponente grafikog korisnikog interfejsa,
programske konstrukcije koje realizuju usluge mrene distribucije objekata, baze
podataka itd. Tehnoloki objekti su tako struktuirani da omoguavaju punu slobodu
pri kreiranju aplikacija, olakavaju njihovo odravanje, a selekcija ovih objekata se
vri u skladu sa vodeim standardima. Potovanje standarda omoguava integraciju
i kompatibilnost proizvoda razliitih proizvoaa. Aplikativni objekti su programi koji
prezentuju zahtevanu informaciju i omoguuju komunikaciju krajnih korisnika sa IS.
Oni predstavljaju reenja odreenih poslovnih reenja, angaujui odgovarajue
skupove poslovnih objekata u cilju realizacije specifinih zadataka. Aplikativni objekti
su sastavljeni od poslovnih i tehnolokih objekata koji uz pomo programskog koda
daju odreena aplikativna reenja. Aplikativnim objektima se automatizuju odreeni
poslovni procesi i mogu sluiti kao aplikativna podrka odluivanju. Postoje 3 vrste
poslovnih objekata: Entiteti, Dogaaji, Procesi.

17. Spajanje Klijent/ Server arhitekture (K/SA) i objektne tehnologije

K/SA IS se moe analizirati sa 2 aspekta: - Prvi se odnosi na arhitekturu aplikacije
(prezentacije, funkcionalna logika i podaci ); - Drugi nain se odnosi na konfiguraciju
hardverskih komponenti IS. Prezentacija se odvija na liniji korisnikih interfejsa i on
upravlja deavanjima na ekranu korisnika. Funkcionalna logika preslikava nain
odvijanja automatizovanih poslovnih procesa. Funkcionalna logika je obuhvaena
programskim kodom i obuhvata odgovarajue usluge za izvravanje tog koda. Deo
aplikacije koji se odnosi na podatke obezbeuje smetanje svih relevantnih podataka
poslovnog sistema kao i usluge neophodne za pristup i upravljanje podacima. Kod
klasine konfiguracije hardverskih komponenti se uoavaju 2 nivoa (TWO TIER
model) koji dele odgovornosti za realizaciju aplikacije: 1. Nivo servera (odgovoran za
upravljanje podacima); 2. Nivo klijenta (Odgovoran za izvravanje logike i
prezentaciju dobijenih podataka). Kod ovog modela klijent i server komuniciraju
direktno bez posrednika pomou komunikacionih mehanizama. Svaka promena bilo
u emi baze podataka ili u logici funkcionisanja kod ovog modela podrazumeva
modifikaciju kompletne aplikacije. Zbog toga ovaj model IS je skup za odravanje i
ne poseduje potrebnu fleksibilnost (nema reinenjering procesa). Sledea K/SA je
THREE TIER model gde se izmeu klijenta i servera instalira 3 nivo meuservera
koji realizuje logiku funkcionisanja aplikacije i usluge u distribuiranom okruenju.
Korisnike radne stanice obavljaju zadatke vezane za prezentaciju aplikacije, a linija
krajnjeg servera vri obradu podataka. Kod ovog modela delovi aplikacije koji se
odnose na prezentaciju, funkcionalnu logiku i podatke su nezavisne komponente
aplikacije.

18. Prednosti THREE TIER modela

1.Arhitektura fizike konfiguracije je u saglasnosti sa arhitekturom aplikacije to
poveava performanse IS. Ovo znai da svaka od komponenti moe biti
modifikovana ili zamenjena i da to ne zahteva dodatne intervencije u ostatku
aplikacije. 2. Modul aplikacije mogue je koristiti na razliitim platformama poto su
delovi aplikacije nezavisni moduli povezani odgovarajuim interfejsom. 3. Usluge i fje koje procesiraju meu serveri mogu da se koriste od strane mnogih aplikacija.
Trea faza evolucija K/SA je preobraaj THREE TIER K/SA u distribuirano objektno
okruenje (DOC). Ova transformacija se sprovodi implementacijom tehnolokih
aplikativnih i poslovnih objekata. Prelazak na distribuiranu TREE TIER aplikaciju
omoguava pretragu prostora stanja i sistema i traganje za optimalnim stanjima. Na
ovaj nain IS dobija obeleje sistema za podrku odluivanju.
19. GUIDS metoda
Ovo je metoda za OBJEKTNO ORJENTISANO projektovanje sastoji se iz 5 faza:
Projektovanje na osnovu ciljeva (GOAL), Sprega izmeu korisnika i aplikacije (USER
INTERFACE), Projektovanje implementacije (IMPLEMENTATION), Projektovanje
podataka (DATA DESIGN) , Strategije za konstruisanje (STRATEGES FOR
KONSTRUCTION). Nakon OBJEKTNO ORJENTISANOG projektovanja sledi
OBJEKTNO ORJENTISANO programiranje gde su objekti povezani uglavnom preko
tri osnovna tipa relacija: Pod klase, Kontejneri, Kolaboratori. Osnovni elementi

OBJEKTNO ORJENTISANOG sistema su: Apstrakcija,Inkapsulacija, Nasleivanje,

Polimorfizam. Dananje OBJEKTNO ORJENTISANE metode koriste apstrakciju da
se obezbedi pristup koji omoguava uestvovanje korisnika tokom razvoja aplikacije.
Apstrakcija je usmerena na ono to je vaan za aplikaciju a ne na samu
implementaciju. Ovo omoguava da se aplikacije projektuju jezikom odreenog
posla a programerskom tehnologijom. Inkapsualizacija uvod i skrivanje privatnih
svojstava i implementacije ponaanja. Njime se pristupa preko zadatog javnog
interfejsa zbog toga se objekti mogu koristiti bez poznavanja njegove
implementacije. Nasleivanjem se obezbeuje izbegavanje ponavaljanja slinosti i
razlika meu objektima. Polimorfizam dozvoljava da javni interfejs objekta koji imaju
sline funkcije imaju ista imena procedura ali drugaiju implementaciju. Ne mora se
znati klasa objekta da bi se izvrilo polimorfno ponaanje.

20. Proces razvoja softvera

Ukljuuje sledee faze: Ideja, Zahtevi, Plan i raspored, Arhitektura, Izgradnja,
kontrola. Prvi korak u ostvarivanju neke ideje je proirenje ideje na skup specifinih
zahteva koji definiu projekat i oekivanja korisnika i tehnikog osoblja. Projektant
definie zahteve korisnika u saradnji sa njima. Ovi zahtevi se dokumentuju i slue
kao osnova projekta aplikacije. Pristup na osnovu ciljeva u saradnji sa korisnicima
definie prave ciljeve koji proizilaze iz njihovih potreba. U ovom sluaju rade se
sledei koraci: -Formira se projektni tim; - Urade se domai zadaci; - Postave se
ciljevi; - Odredi se obim; - Indentifikuju se potrebe; - Pretvaraju se potrebe u
zahteve; - Odreuju se prioriteti zahteva.
21. Planiranje i pravljenje rasporeda projekta
Plan projekta definie kako e se projekat razvijati da bi zadovoljio zahteve
definisane od strane korisnika. Prvo se pravi grub raspored projekta da bi se
isplanirao vremenski period. Ovaj raspored se bazira na pretpostavkama ,a ne na
detaljima projekta.

22. Razvijanje arhitekture

Metodologija za OBJEKTNO ORJENTISANO projektovane arhitekture (GUIDS)
sastoji se od: Projektovanje na osnovu ciljeva, Projektovanje korisnikog interfejsa,
Projektovanje implementacije, Projektovanje podataka, Strategije koje odreuju
pristup u pravljenju aplikacije (standardi i konvencije za programiranje, upravljanje,
testiranje, i plan i raspored implementacije).

23. Izgradnja i kontrola

Projekat arhitekture koji je razvijen nekom OO metodologijom slui kao osnova za
razvoj aplikacije. Kada budu zavreni neki delovi programa poinje postupak
kontrole. Kontrola moe da obuhvati proveru programskih linija, ispitivanje
programskih celina, ispitivanje njihove integrisanosti i ispitivanje sistema. Cilj

kontrole je pronalaenje greaka u programu to ranije u procesu razvoja. Gotova

aplikacija zahteva odravanje koje moe ukljuiti ispravljanje greaka, proirivanje
programa, promene pravila poslovanja itd.
24. Neke prednosti korienja OO pristupa
Apstraktni objekti omoguuju standardni jezik timu projektanata i bolji poslovni
model. GUIDS metoda daje puteve za ukljuivanje korisnika u fazi stvaranja
arhitekture. OO projektovanje smanjuje komleksnost programiranja, obezbeuje
logiku i red u nainu na koji se delovi aplikacije uklapaju. Ovo proces razvoja ine
efikasnijim jer se zna ko, ta i treba da radi. Segmenti aplikacije moraju biti
nezavisni. OO pristup pravi zidove izmeu segmenata definiui nezavisne
zatvorene objekte. Interakcija ovih objekata se obavlja preko javnih interfejsa. Klase
u OO projektovanju opisuju dobro definisane i nezavisne komponente. Inkapsulacija
klasa ini implementaciju nezavisno od ostatka sistema, to pojednostavljuje izmene
i testiranje aplikacije. OO projektovanje dozvoljava da se prave nezavisne
komponente koje se mogu kombinovati za probne verzije. OO projektovanje
dozvoljava da se definiu sve komponente aplikacije i da se ukljue u raspored kao
zadaci koji se mogu definisati i proceniti.
25. Odreivanje standarda kvaliteta
Standardi kvaliteta odreuju neke opte uslove za zahtevane kvalitete aplikacije. Pri
definisanju standarda kvaliteta treba razdvojiti sledee faktore: - Jednostavnost
upotrebe; - Usaglaenost sa ustanovljenim konvencijama za korisniki interfejs; Mogunos odravanja; - Pouzdanost; - Performanse; - Prihvatljivi nivo programskih
greaka; - Kompatibilnost sa drugim srodnim sistemima. Definisanjem standarda
kvaliteta u fazi preduslova za projekat postie se prilagoenost tokom celog razvoja.
U protivnom umesto da bude primarni projektni zahtev, standardi kvaliteta postaju
spisak bagova. Norme za projektovanje softvera ukljuuju: Minimalna hardverska
konfiguracija, Preporuena hardverska konfiguracija, Operativni sistem, Mrena
konfiguracija, Jezici, Baze podataka, Prenosivost, Mogunost ponovnog korienja
(REUSABILITY), Projektovani broj korisnika, Sigurnosni zahtevi, Veza prema drugim
sistemima, tekui tehniki standardi i programerske konvencije, Vreme
dooglaavanja, Internacionalizacija.

26. Analiza kvaliteta softvera primenom ISHIKAWA analize

Poto na kvalitet softvera utiu mnogi faktori te faktore je potrebno grupisati putem
neke metode primer ISHIKAWA metode. Kod ove metode se koristi dijagram za
prikaz i razmatranje odnosa izmeu date posledice i njenih moguih posledica.
Dijagram se konstruie tako da se svi mogui uzroci razmatraju i organizuju u
kategorije i podkategorije shodno meusobnim hijerarhiskim odnosima. ISHIKAWA
dijagram omoguuje: Analizu i prikaz uzrono poslediinih odnosa, Olakava
reavanje problema poevi od utvrivanja siptoma preko poslediica pa do reenja.
U osnovne uzroke koji utiu da se dobije dobar softver spadaju: ovek, Merljivost,
Sistem podataka (Menadment podataka IS ), Materijal, Metode, Okruenje,

10

Oprema. Uticaj oveka na razvoj softvera izraava se kroz njegovu motivaciju

okruenje sticanje novih znanja i dobro kolovanje. Merljivost se odnosi na brzinu
izvravanja aplikacije, stepen jednostavnosti upotrebe softvera, osobine kompajlera,
debagovanje i BP. Sistem podataka dobrog softvera sadri zahteve korisnika,
Podatke iz domena, razne primere i literaturu za posmatrani problem. Materijal se
odnosi na literaturu vezanu za posmatrani problem. Kod metoda vodi se rauna o
metodama projektovanja i testiranja. Od metoda za razvoj softvera razlikuju se
modularni i OO pristup. Pod okruenjem se misli na trokove, budet i rokove
projekta. Oprema podrazumeva odgovarajuu hardversku konfiguraciju, Operativi
sistem i razvojni alat koji se koristi. Projektni zahtevi koji su osnov izrade svake
aplikacije, treba da omogue jednostavnu izradu i odravanje aplikacije. U okviru
ovih zahteva mogu se izdvojiti: - Interakcija sa drugim programima koja se ogleda u
radu sa raznim formatima dokumenata; - Iskorienost mogunosti OS; - Stabilnost
softvera; - Prenosivost koda na razliite platforme i OS; - Rad u mrei; Jednostavnost korisnikog interfejsa; - Hardverski zahtevi aplikacije odreuju
raunar na kojem aplikacija moe da se razvija. Primenom komparativne ISHIKAWA
metode svakoj grani dijagrama moe se dodeliti koeficijent od 1 do 10, koji opisuje
znaaj te grane. Postoje 2 naina zadavanja koeficijenata: - Top-Down, polazi od
definisanja koeficijenata na najniem nivou koju zadaje strunjak ili tim koji ima
najvie znanja iz tog domena. Na osnovu koeficijenta pretka, potomcima se
dodeljuje teinski koeficijent; - Bottom-Up, nema nikakvih izraunavanja koeficijenata
ve se koeficijenti mogu uneti za svaku granu posebno bez obzira da li ima potomke
ili ne. Mogue je uporeivanje 2 ISHIKAWA dijagrama tako to e se formirati
dijagrami iste strukture kojima e se pored teinskog koficijenta pridruiti i neki novi
koeficijenti: - Zahtevni koeficijent i te grane n tog nivoa (Isto to i teinski
koeficijent); - Ostvareni koeficijent i te grane n - tog nivoa (opsisuje koliko je
ostvaren uticaj uzroka na posledicu); - Koeficijent relativnog znaaja i grane n tog
nivoa (koeficijent procentualnog uenja); - Ukupni koeficijent. ISHIKAWA metoda
pomae u poboljanju kvaliteta softvera i odabiranja prave razvojne platforme.

27. Multimedije i ekspertni sistemi

Razvoj tehnologije ekspertnih sistema nejveim delom je bio nezavisan od razvoja
multimedijalnih sistema. Ovaj razvoj je doveo do pojave niza multimedijalnih ureaja
i njihovog povezivanja sa ekspertnim sistemima. Ova generacija se javlja zbog
problema koji multimedijalni nisu mogli sami da prevaziu. Kao to su interaktivan
pristup podatcima, efikasno selektovanje i prikaz datih podataka, uenje i poreenje
koristei obimne informacije i akumulirano znanje. Integrisanjem ove dve tehnologije
dobijamo novo nastali sistem koji pored dobrih osobina i jednog i drugog dobija i nov
kvalitet koji nastaje na osnovu komplementarnosti obilja tehnologija. Ekspertni
sistemi pored reda sa alfa- numerikim podacima dobijaju dobijaju mogunost rada
sa slikom, govorom, animacijama, vide zapisom itd. Ukljuivanjem multimedije u
ekspertne sisteme dobija se bolja komunikacija korisnika sa sistemom, uenje
korisnika postaje efikasnije, a donoenje odluka bolje. Multimedija moe da omogui
i modeliranje ireg opsega znanja, predstavljanje nove kategorije modela znanja i
poboljanje dela ekspertnog sistema za obrazloenje tipa zato?. Multimedijalni
sistem koristi skupljena znanja u ekspertnom sistemu radi poboljanja korisnikog
interfejsa tj. Stvaranje inteligentnog multimedijalnog korisnikog interfejsa. Proces

11

integracije ovih sistema dovodi do generike

multimedijalnog ekspertnog sistema (IMMES).

arhitekture

interaktivnog

28. Modeli realizacije IMMES

IMMES se moe dekomponovati na bar dve softvreske komponente, jednu kod koje
je ekspertni sistem dominantan i drugu kod koje je multimedija dominantna. Postoji 5
moguih naina povezivanja ekspertnih sistema i multimedija: - Povezivanje
arhitektura nezavisnih sistema: - Integracija reenja: - Slabo spregnuti sistemi; vrsto spregnutu sistemi; - Integrisano optimizovano reenje. Povezivanje
arhitektura nezavisnih sistema je multinovo integracije ekspernih i multimedijalnih
sistema. Prednosti ove aritekture su: Raspoloivost komercijalnih alata,
Jednostavnost, brzina razvoja, Nezavisno odravanje. Nedostatci su: Nepostojanje
bilo kakve integracije i izostavljanje sinergizma. Integracija reenja je prvi nivo
integracije EX i MM sistema. Aplikacija se sastoji od vie aplikacija razvijenih
pomou razliitih alata. Koristei ovaj model za aplikaciju razvijenu sa jednim alatom
neophodno je izvriti translaciju sadraja i strukture. Zato je potreban odreeni nivo
standardizacije. Prednosti ovog modela su: Raspoloivost komercijalnih alata,
Jednostavnost, brzina razvoja, brzina isporuke sistema. Nedostatak: Nije
ekonomino reenje i potpuno tana translacija moe biti neizvodljiva. Slabo
spregnuti sistem omoguava komunikaciju EX i MM sistema preko datoteke
podataka. To znai da postoji kooperativno procesiranje preko datoteke podataka.
Prednost je poboljani singerizam. Nedostatak je to postoji dodatno procesiranje
podatka u toku komunikacije. vrsto spregnutu sistemi realizuje komunikaciju
izmeu EX i MM sistema preko mehanizma slanja poruka ili mehanizma deljene
memorije. Prednosti ovog modela integracije su: Poveana robusnost, Modularnost,
Fleksibilnost projektovanja i Bre izvravanje aplikacija u odnosu na slabo spregnute
sisteme. Nedostatci: Nepostojanje komercijalnih alata, Poveanja sloenost razvoja,
odravanja, redundantni parametri i procesiranje podataka i pitanja validacije i
verifikacije. Integrisano optimizovano reenje optimizuje performanse celog sistema
u odnosu na aplikaciju. U ovakvom razvojnom okruenju podrani su i koncepti EX i
MM sistema. Prednosti: Najvii nivo singerizma, Robusnost, Odline performanse u
toku izvravanja, Eliminisana redudantnost, Poboljano reavanje problema.
Nedostatci: Poveano vreme razvoje i Nedostatak komercijalnih alata. Ovaj model je
najbolje reenje za IMMES.
29. Generika arhitektura IMMES-a
Korisniki interfejs postaje i audio i vizuelni interfejs. IMMES u ovom sluaju koristi tri
baze podataka: Alfanumeriku u kojoj se nalaze standardni alfanumeriki podaci,
MM BP koja sadri slike i audio-vizuelne podatke i Bazu podataka znanja koja
generie znanje. Kod ovakve arhitekture IMMES najvaniji je podsistem za
upravljanje podacima. Glavni zadatak podsistema za upravljane podacima je da
garantuje efikasan pristup podacima bez obzira na veliine datoteka u kojima se
podaci nalaze. Operatori koje ovaj podsistem treba da podrava su: INSERT, DEL,
UPDATE, SELECT, JOIN, CASH JOIN i SORT. Podsistem za upravljanje objektima

12

sadri model objekata, programski prevodilac, biblioteke potrebne za rad u toku

izvravanja programa i interpreter.
30. Mogui naini za poboljanje performansi
Poboljanje ili pronalaenje novih algoritama struktura podataka za pristup podacima
(u praksi se koristi vie verzija B+ stabla) je nain za poboljanje performansi
sistema. B+ struktura ima podjednako vreme pristupa bilo kom slogu na osnovu
vrednosti kljua, ima odlinu brzinu pristupa, dobar nain odravanja indeksne
strukture i opseg slogova. Upravljanje B+ stablom garantuje balansiranje stabla (svi
listovi se nalaze na istoj dubini). Jedina posledica je neto vee zauzee
memorijskog prostora.

31. Nove arhitekture i pristupi objektno-orijnentisanom razvoju softvera

U savremenim pristupima razvoju softverskih sistema jasno se razlikuju sledei
koncepti: - Funkcionalna specifikacija sistema koja definie ta sistem treba da radi;
- Arhitektura sistema koja opisuje ta treba da se izgradi; - Modeli sistema koji
opisuju sistem sa razliitih aspekata; - Metodologija koja definie redosled aktivnosti
koje treba preduzeti da bi se eljeni sistem izgradio i koristio.

32. Funkcionalna specifikacija sistema

Formalno definie zahteve korisnika koji e biti u neposrednoj interakciji sa buduim
sistemom.U savremenim OO pristupima funkcionalna specifikacija se zadaje
pomou sluajeva korienja. Svaki kasniji korak u razvoju sistema treba da ima
jasan trag do odgovarajueg sluaja korienja. Odgovarajui sluajevi korienja
definiu buduu arhitekturu sistema. Meutim detaljna specifikacija novog sluaja
korienja zavisi i od usvojene arhitekture sistema. Zbog toga se specifikacija
sluaja korienja i arhitekture sistema zajedniki ugrauju u procesu razvoja
sistema to utie na karakteristike ivotnog ciklusa ovog proizvoda.
33. Arhitektura sistema
Arhitektura sistema opisuje ta treba da se izgradi. Pored zahteva korisnika na
arhitekturu utiu okruenje u kome se sistem razvija. Postojei softver i gotove
softverske komponente: aplikacioni kosturi i mustre. Savremena razvojna okruenja
predstavljaju arhitekture koje u sebi sadre mnotvo blokova koji se mogu direktno
koristiti, specializovati ili dograditi u procesu razvoja softverskog sistema.

34. Modeli sistema

Razliiti modeli sistema izgrauju se korienjem nekog formalnog i opte
prihvaenog jezika. Takav je danas UML. On omoguuje da se opie projektovani
sistem sa razliitih aspekata: - Strukturnog (dijagrami klase i dijagrami objekata); -

13

Dinamikog (dijagrami
sluajeva
korienja,
promene
stanja
itd.);
Fizikog (dijagrami komponenti i dijagrami razmetanja); - Sa aspekta upravljanja
modelima (paketi, podsistemi, modeli).

35. Proces razvoja sistema

Za razliku od konvencionalnih metodolokih pristupa, OO pristupi omoguavaju i
zagovaraju efikasan iterativno inkrementalni pristup. U iterativno
implementacionom modelu ivotnog ciklusa podrazumeva se razvoj sistema malim
koracima po strategiji: - Planiraj malo; -Specifiraj, projektuj i implementiraj malo; Integrii, testiraj i koristi svaku iteraciju malo.

36. Arhitekture programskih sistema

Arhitektura softverskog sistema definie strukturne i dinamike karakteristike
sistema. Preko ovih karakteristika treba da se iskau upotrebljivost, funkcionalnost,
performanse kao i ekonomska i tehnoloka ogranienja sistema. Najznaajnija
karakteristika savremenih softverskih arhitektura treba da bude njena prilagodljivost
brzim promenama u poslovnom i tehnolokom okruenju. U K/SA razlikujemo
dvoslojni i troslojni generiki model arhitekturi. Dvoslojna K/SA uinila je nezavisnim
BP i aplikacije da bi se obezbedio integritet BP nezavisno izvan aplikacija koje nad
njom rade. Jedini mehanizam potreban za komunikaciju aplikacije sa BP je SQL upit
koji se prosleuje direktno kroz raunarsku mreu. Ovakva arhitektura ima dosta
nedostataka. Znaajan deo aplikacije se vezuje za klijenta. Ovo prouzrokuje skupo
odravanje zbog estih izmena u tehnologiji korisnikog interfejsa. Ovako razvijen
softver je nedovoljno modularan, teko prenosiv i loe podravaju veliki broj
korisnika.U troslojnom generikom modelu jasno se odvaja upravljanje podacima,
aplikaciona logika i korisniki interfejs. Sutina ove arhitekture odraena je u
srednjem sloju , aplikacionom serveru. Aplikacioni server omoguava transparentno
povezivanje aplikacija sa razliitim izvorima podataka na razliitim platformama a ne
samo sa jednim serverom. Poseban znaaj imaju distribuirane arhitekture softverskih
komponenti . Zadatak ovih arhitektura je da omogui izgradnju nove aplikacije na
osnovu postojeih komponenti i postojeeg koda izgraujui pri tome nove
komponente za budue ire korienje. Ovakva arhitektura reava problem
produktivnosti razvoja softvera i odravanja. Ovde nastaje problem kada treba
povezati staru i dolazeu tehnologiju zbog toga to je stara tehnologija realizovana
na veoma niskom nivou apstrakcije. Za reavanje ovog problema usvojena je
vieslojna arhitektura koja omoguuje uvoenje vie nivoa apstrakcije na kojima se
IS opisuje u okruenju definisanih poslovnih procesa i objekata. Predloene su dve
arhitekture: - Prva BOA - OMG ; - Druga predloena od strane IBM. Arhitektura BOA
OMG predvia sloj jedinstvenih poslovnih objekata i sloj poslovnih objekata
specifinih za datu organizaciju. IBM arhitektura predvia sloj zajednikih poslovnih
objekata i osnovnih poslovnih procesa. Komponente na ovim nivoima na obe
arhitekture nisu zatvorene ve ih je mogue modifikovati i nadograivati. Ove
komponente mogu da budu: - Softverske komponente; - Mustre (opte reenje za
opte objekte); - Kosturi (sloenija mustra kojom se definie neka opta aplikacija).
Infrastrukturni nivoi oba modela omoguuju izgradnju i funkcionisanje poslovnih
objekata i procesa i da stave na raspolaganje skup nekih optih uslunih servisa.

14

Najnii nivoi u oba modela predstavljaju osnovni skup mehanizama za ostvarivanje

arhitekture distribuiranih softverskih komponenti.
37. Ciljevi i znaaj softverskog ininjeringa
Znaaj inenjeringa je u sistematskom pristupu razvoju, uvoenju i odravanju
softvera kroz faze njegovog ivotnog ciklusa. Treba posebno naglasiti da ne postoji
jedno najbolje reenje ili pristup u reavanju problema razvoja softvera. Ipak
kombinovanjem velikog broja iroko obuhvatnih metoda u svim fazama razvoja
softvera, kvalitetnih alata za automatizovanje ovih metoda, snanih blokova za
implementaciju softvera, boljih tehnika za obezbeenje kvaliteta softvera i to je
najvanije filozofijom koordinacije, kontrole i upravljanja, moe se postii disciplina u
razvoju softvera ili softverski inenjering.
Softverski razvoj kao nauka i kao praktina aktivnost imaju neto zajedniko
raznovrstnost. U cilju ureenja ove raznovrsnosti, softverski inenjering predstavlja
strogo definisan pristup koji ine principi i ciljevi koji se primenjuju u razliitim fazama
razvoja softvera. Polazno odredite za odreivanje ciljeva softverskog inenjeringa
moe se nai u takozvanom 4P pravilu, prema kojem je cilj svakog projekta razvoja
softvera da stvori softverski proizvod u kojem projektanti stvaraju u efektivnom
procesu. Glavni ciljevi softverskog inenjeringa su: ostvarenje pouzdanosti,
promenljivosti, jasnosti, prilagodljivosti, ponovljivosti, efikasnosti, prenosivosti i
mogunosti odravanja softvera.
38. Alati za dizajn softvera
Alati obezbeuju automatizovanu ili poluautomatizovanu podrku u primeni metoda.
Oni predstavljaju pomo neophodnu da bi se automatizovale aktivnosti razvoja
softvera kao: upravljanje projektom odnosno planiranje, procenjivanje, terminiranje,
rasporeivanje, modeliranje, analiza, projektovanje, kodiranje, dokumentovanje,
testiranje, integracija elemenata sa sistemom, upravljanje konfiguracijom, kontrola
kvaliteta softvera, upravljanje podacima i dr. U stvarnosti, danas svaki metod
poseduje odreeno pomono sredstvo, instrument, alat. Kada su alati na takav nain
integrisani u jedan sistem da se rezultati kreirani od jednog alata mogu upotrebiti i od
drugog alata, tada govorimo o CASE alatima. CASE alati ine posebnu grupu alata,
koji automatizuju metode i procedure razvoja softvera i istovremeno skrauju vreme,
smanjuju trokove izrade i podiu kvalitet razvijenog softverskog proizvoda.

39. UML
UML (Unified Modeling Language) je objedinjeni vizuelni jezik za poslovno i
softversko modelovanje u svim fazama razvoja i za sve tipove sistema, kao i za
generalno modelovanje kojim se definiu statike strukture i dinamiko ponaanje.
Standardni je jezik za: vizuelizaciju, specifikaciju, konstruisanje i dokumentovanje
softverskih sistema
UML kombinuje najbolje iz:
Koncepta Data Modeling (Entity Relationships Diagrams)
Poslovnog modelovanja (work flow)

15

Objektnog i komponentnog modelovanja

UML je projektovan kao vrlo fleksibilan i prilagodiv jezik, koji omoguava vrlo razliite
vrste modelovanja, ukljuujui: modele koji olakavaju razumevanje poslovnih
procesa, odvijanja tokova dogaaja, sekvenci upita, aplikacija, baza podataka,
arhitektura i drugog.
UML je nastao kao rezultat evolucije objektno orijentisanih jezika za modelovanje.
Razvila ga je kompanija Rational Software objedinjavanjem tri vodee metode
objektno orijentisanog modelovanja:
Booch koji je razvio Grady Booch,
OMT (Object Modeling Technique) koji je razvio Jim Rambaugh i
OOSE (Object-Oriented Software Engineering) koji je razvio Ivar Jacobson.
UML koriste sledee kategorije korisnika:
Sistem analitiari i krajnji korisnici specifikacija zahtevane strukture i
ponaanje sistema
Arhitekte sistema projektanti sistema koji e zadovoljiti zahteve
Razvojni inenjeri (developers) transformiu arhitekturu u izvrni kod
Kontrolori kvaliteta provera strukture i ponaanje sistema
Rukovodioci projekta (menagers) vode i usmeravaju kadrove i resurse.