Manger

Sveučilište u Zagrebu
Prirodoslovno Matematički fakultet

Matematički odsjek
Robert Manger
SOFTVERSKO INŽENJERSTVO
Skripta
Nadopunjeno drugo izdanje

Zagreb, rujan 2013.
Robert Manger
2 PMF – Matematički odsjek

Softversko inženjerstvo - skripta
Sadržaj
Predgovor ....................................................................................................................................... 7
1. Uvod u softversko inženjerstvo ............................................................................................ 9
1.1. Osnovni pojmovi vezani uz softversko inženjerstvo ................................................... 9
1.1.1. Softverski produkt i softversko inženjerstvo ........................................................ 9
1.1.2. Softverski proces, metode i alati ........................................................................ 10
1.1.3. Dokumentacija softvera...................................................................................... 11
1.2. Modeli za softverski proces ....................................................................................... 12
1.2.1. Model vodopada ................................................................................................. 13
1.2.2. Modeli evolucijskog i inkrementalnog razvoja .................................................. 14
1.2.3. Modeli formalnog i grafičkog razvoja ............................................................... 15
1.2.4. Model usmjeren na ponovnu upotrebu ............................................................... 17
1.3. Klasične i agilne metode razvoja softvera ................................................................. 18
1.3.1. Vrste metoda i njihova svojstva ......................................................................... 18
1.3.2. Primjer klasične metode ..................................................................................... 19
1.3.3. Primjer agilne metode ........................................................................................ 21
1.4. Upravljanje softverskim projektom ........................................................................... 22
1.4.1. Poslovi softverskog menadžera .......................................................................... 23
1.4.2. Planiranje i praćenje projekta ............................................................................. 24
1.4.3. Upravljanje rizicima ........................................................................................... 27
2. Utvrđivanje zahtjeva ........................................................................................................... 29
2.1. Općenito o utvrđivanju zahtjeva ................................................................................ 29
2.1.1. Funkcionalni i nefunkcionalni zahtjevi .............................................................. 29
2.1.2. Postupak utvrđivanja zahtjeva ............................................................................ 31
2.1.3. Načini zapisivanja i organiziranja zahtjeva ........................................................ 32
2.2. Otkrivanje zahtjeva .................................................................................................... 35
2.2.1. Intervjui i ostali tradicionalni postupci............................................................... 35
2.2.2. Scenariji i slučajevi uporabe .............................................................................. 36
2.2.3. Upotreba prototipova.......................................................................................... 39
2.2.4. Etnografski pristup ............................................................................................. 40
2.3. Modeliranje sustava ................................................................................................... 41
2.3.1. Vrste modela i načini njihove uporabe ............................................................... 41
2.3.2. Modeliranje konteksta i interakcije .................................................................... 42
2.3.3. Modeliranje strukture ......................................................................................... 45
2.3.4. Modeliranje ponašanja ....................................................................................... 49
PMF – Matematički odsjek 3

Robert Manger
3. Oblikovanje i implementacija ............................................................................................ 55
3.1. Općenito o oblikovanju i implementaciji .................................................................. 55
3.1.1. Podaktivnosti unutar oblikovanja ....................................................................... 55
3.1.2. Dekompozicija većih dijelova u manje .............................................................. 56
3.1.3. Modeliranje tijekom oblikovanja ....................................................................... 58
3.1.4. Novi trendovi vezani uz implementaciju ........................................................... 59
3.2. Oblikovanje arhitekture ............................................................................................. 60
3.2.1. Podsustavi i odnosi među njima ......................................................................... 60
3.2.2. Strukturiranje sustava ......................................................................................... 61
3.2.3. Modeliranje kontrole .......................................................................................... 66
3.3. Objektni pristup oblikovanju ..................................................................................... 69
3.3.1. Svojstva objektno oblikovanog softvera ............................................................ 69
3.3.2. Koraci unutar objektnog oblikovanja ................................................................. 70
3.3.3. Primjer objektnog oblikovanja ........................................................................... 71
3.3.4. Obrasci za oblikovanje ....................................................................................... 76
3.4. Oblikovanje distribuiranih sustava ............................................................................ 79
3.4.1. Prednosti i mane distribuiranih sustava .............................................................. 79
3.4.2. Arhitekture s klijentima i poslužiteljima ............................................................ 80
3.4.3. Druge distribuirane arhitekture .......................................................................... 83
3.5. Oblikovanje i implementacija uklopljenih sustava .................................................... 88
3.5.1. Osobine uklopljenih sustava............................................................................... 88
3.5.2. Arhitekture uklopljenih sustava ......................................................................... 91
3.5.3. Analiza vremenskih ograničenja za procese ...................................................... 94
3.5.4. Implementacija uklopljenih sustava ................................................................... 97
4. Verifikacija i validacija ....................................................................................................... 99
4.1. Općenito o verifikaciji i validaciji ............................................................................. 99
4.1.1. Metode za verifikaciju i validaciju ................................................................... 99
4.1.2. Mjesto verifikacije i validacije u softverskom procesu .................................... 100
4.1.3. Odnos verifikacije, validacije i debuggiranja ................................................... 101
4.2. Statička verifikacija ................................................................................................. 101
4.2.1. Inspekcija programa ......................................................................................... 101
4.2.2. Automatska statička analiza ............................................................................. 103
4.2.3. Formalna verifikacija ....................................................................................... 104
4.3. Testiranje softvera ................................................................................................... 105
4.3.1. Vrste i faze testiranja ........................................................................................ 105
4.3.2. Testiranje dijelova softvera .............................................................................. 108
4.3.3. Testiranje integracije ........................................................................................ 112
4.3.4. Razvoj softvera vođen testiranjem ................................................................... 115

5. Održavanje i evolucija ...................................................................................................... 117

5.1. Općenito o održavanju i evoluciji ............................................................................ 117
5.1.1. Strategije mijenjanja softvera ........................................................................... 117
5.1.2. Vrste i dinamika održavanja softvera ............................................................... 118
5.1.3. Cijena održavanja softvera ............................................................................... 118
5.1.4. Održavanje unutar agilnih metoda ................................................................... 119
5.2. Upravljanje konfiguracijom ..................................................................................... 120
5.2.1. Svrha upravljanja konfiguracijom, podjela na podaktivnosti........................... 120
5.2.2. Upravljanje promjenama .................................................................................. 122
5.2.3. Upravljanje verzijama ...................................................................................... 125
5.2.4. Gradnja sustava ................................................................................................ 128
5.2.5. Upravljanje izdanjima ...................................................................................... 130
5.3. Baštinjeni softver i njegovo mijenjanje ................................................................... 131
5.3.1. Građa i osobine baštinjenog softvera ............................................................... 131
5.3.2. Softversko reinženjerstvo ................................................................................. 132
5.3.3. Arhitekturna transformacija ............................................................................. 135
6. Ponovna upotreba ............................................................................................................. 139
6.1. Općenito o ponovnoj upotrebi ................................................................................. 139
6.1.1. Svojstva i oblici ponovne upotrebe .................................................................. 139
6.1.2. Popis tehnika za ponovnu upotrebu ................................................................. 140
6.1.3. Odabir tehnike za ponovnu upotrebu ............................................................... 141
6.2. Neki tradicionalni oblici ponovne upotrebe ............................................................ 141
6.2.1. Aplikacijski okviri ............................................................................................ 141
6.2.2. Produktne linije ................................................................................................ 143
6.2.3. Upotreba COTS produkata ............................................................................... 145
6.3. Razvoj softvera zasnovan na komponentama .......................................................... 147
6.3.1. Komponente i njihovo korištenje ..................................................................... 148
6.3.2. Softverski procesi zasnovani na komponentama ............................................. 150
6.3.3. Kompozicija komponenti ................................................................................. 154
6.4. Razvoj aplikacija pomoću web servisa .................................................................... 159
6.4.1. Web servisi kao temelj nove distribuirane arhitekture ..................................... 159
6.4.2. Standardi vezani uz web servise....................................................................... 161
6.4.3. Usporedba web servisa i komponenti............................................................... 163
6.4.4. Softverski procesi vezani uz web servise ......................................................... 164
Literatura ................................................................................................................................... 171

Robert Manger

Predgovor
Ova skripta sadrže predavanja iz kolegija „Softversko inženjerstvo“ koji se predaje
studentima sveučilišnog diplomskog studija Računarstvo i matematika na PMF-
Matematičkom odsjeku Sveučilišta u Zagrebu. Osnovni cilj kolegija „Softversko
inženjerstvo“ je stjecanje temeljnih znanja o softverskom inženjerstvu. Dodatni ciljevi su da
se studenti kroz vježbe upoznaju s barem jednom konkretnom metodom razvoja softvera te da
se susretnu s barem jednim alatom za modeliranje softvera. Kolegij ima važnu svrhu: on
potreban zato da bi studentima na kraju studija omogućio sintezu i sistematizaciju znanja koja
su oni već stekli u prethodnim računarskim kolegijima. Drugim riječima, kolegij je koristan
zato što on prethodna znanja o programiranju, algoritmima, bazama podataka, mrežama
računala i drugim računarskim disciplinama povezuje u cjelinu, stvarajući pritom globalnu
sliku o cjelokupnom procesu razvoja softvera i o pozivu softverskog inženjera.
Tekst ovih skripta uglavnom se oslanja na udžbenik [1], tako da se taj udžbenik može smatrati
glavnom literaturom. Knjige [2, 3, 4, 5, 6, 7, 8] nisu neposredno uporabljene u oblikovanju
teksta, no one imaju sličan sadržaj pa mogu poslužiti kao dodatna literatura. Skripta ne
uključuju materijale za vježbe iz istog kolegija. Posljednjih godina, vježbe su se izvodile po
ugledu na knjigu [9].
Skripta se sastoje od šest poglavlja. Prvo poglavlje je uvodno i u njemu se objašnjavaju

osnovni pojmovi, modeli i metode softverskog inženjerstva. Daljnja četiri poglavlja bave se
pojedinim fazama ili aspektima razvoja softvera: ona slijede zamišljeni proces od utvrđivanja
zahtjeva i specifikacije, preko oblikovanja i implementacije, uz verifikaciju i validaciju, sve
do održavanja i evolucije. U zadnjem poglavlju govori se o ponovnoj upotrebi razvijenog
softvera, temi koja je od presudne važnosti za budućnost softverskog inženjerstva.
U ovim skriptama naglasak je na „inženjerskim“ (računarskim) aspektima softverskog

inženjerstva, budući da se „menadžerski“ aspekti pokrivaju posebnim kolegijem. Tekst se ne
opredjeljuje ni za jednu konkretnu metodu razvoja softvera, već umjesto toga nastoji studente
upoznati s različitim (često suprotstavljenim) idejama i modelima te njihovim prednostima i
manama. To još uvijek ostavlja mogućnost da se vježbe izvedu na konkretniji način, dakle
primjenom odabrane metode i odgovarajućih alata.

Robert Manger

1. Uvod u softversko inženjerstvo

U ovom uvodnom poglavlju najprije ćemo objasniti osnovne pojmove koji se susreću u
softverskom inženjerstvu. Zatim ćemo detaljnije govoriti o modelima koji ugrubo opisuju
kako bi se trebao odvijati proces razvoja softvera. Dalje ćemo govoriti o danas relevantnim
metodama razvoja softvera, koje profinjavaju i konkretiziraju pojedine modele. Na kraju
ćemo istaći da softversko inženjerstvo ima i svoj menadžerski aspekt, dakle da se u okviru
razvoja softvera pojavljuje i problematika upravljanja složenim projektima.
1.1. Osnovni pojmovi vezani uz softversko inženjerstvo
Osnovni pojmovi u ovom kolegiju odnose se na razvoj softvera i već smo ih susretali u
prethodnim kolegijima kao što su programski jezici, računarski praktikumi, strukture
podataka i algoritmi, baze podataka, mreže računala i slično. Ipak, sad tim istim pojmovima
nastojimo dati preciznije značenje.
1.1.1. Softverski produkt i softversko inženjerstvo
Softverski produkt je skup računalnih programa i pripadne dokumentacije, stvoren zato da bi

se prodao nekom korisniku. Može biti razvijen za sasvim određenog korisnika (bespoke
product, customized product) ili općenito za tržište (generic product). Softverski produkt
često ćemo kraće nazivati softver ili (softverski) sustav.
Za današnji softver podrazumijeva se da on mora biti kvalitetan. Preciznije, od softverskog

produkta se očekuje da se on odlikuje sljedećim atributima kvalitete.
 Mogućnost održavanja. Softver se mora moći mijenjati u skladu s promijenjenim
potrebama korisnika.
 Pouzdanost i sigurnost. Softver se mora ponašati na predvidiv način te ne smije izazivati
fizičke ili ekonomske štete.
 Efikasnost. Softver mora imati zadovoljavajuće performanse te on treba upravljati
strojnim resursima na štedljiv način.
 Upotrebljivost. Softver treba raditi ono što korisnici od njega očekuju, sučelje mu treba
biti zadovoljavajuće te za njega mora postojati dokumentacija.
Softversko inženjerstvo je disciplina koja se bavi svim aspektima proizvodnje softvera. Dakle,
softversko inženjerstvo bavi se modelima, metodama i alatima koji su nam potrebni da bi na
što jeftiniji način mogli proizvoditi što kvalitetnije softverske produkte.
Softversko inženjerstvo može se smatrati znanstvenom disciplinom no također i tehničkom

strukom. U oba slučaja, ono je u bliskoj vezi s još dva područja znanja:
 Računarstvo (computer science). Poznavanje teorijskog računarstva potrebno je
softverskom inženjeru na sličan način kao što je poznavanje mehanike potrebno
strojarskom inženjeru.

Robert Manger
 Sistemsko inženjerstvo (system engineering). Bavi se razvojem složenih sustava koji se

sastojtoje od hardvera, softvera i ljudskih aktivnosti. Softverski inženjer mora svoje
softversko rješenje uklopiti u takav složeniji sustav.
Softversko inženjerstvo također je i profesija. U mnogim zemljama softverski inženjeri

organizirani su u strukovne udruge koje štite njihova prava ali donekle i ograničavaju slobodu
njihovog djelovanja. Primjeri takvih udruga su ACM, IEEE-CS i British Computer Society.
Udruge donose pravila ponašanja za svoje članove. Na web stranici [27] može se naći etički
kodeks softverskih inženjera kojeg su zajednički usvojili ACM i IEEE-CS.
Softversko inženjerstvo počelo se razvijati krajem 60-ih godina 20. stoljeća. Sam naziv
izgleda da je bio skovan na jednoj NATO konferenciji u Njemačkoj 1968. godine. Disciplina
je nastala kao odgovor na takozvanu „softversku krizu“. Naime, pojavom računala treće
generacije (na primjer IBM serija 360) stvorila se potreba za složenijim softverom (na primjer
multi-tasking operacijski sustav). Pokrenuti razvojni projekti višestruko su premašili planirane
troškove i rokove. Vidjelo se da se dotadašnje neformalne tehnike individualnog
programiranja ne mogu uspješno „skalirati“ na velike programe gdje sudjeluje velik broj
programera. Osjećala se potreba za metodama razvoja softvera koje bi bile u stanju
kontrolirati kompleksnost velikog softverskog projekta. Stanje svijesti iz tih vremena
plastično je opisano u čuvenoj knjizi [26].
Od 60-ih godina 20. stoljeća do danas softversko inženjerstvo prešlo je dug put. Ispočetka su
se predlagale metode razvoja softvera oblikovane po analogiji s metodama iz tradicionalnih
tehničkih struka (na primjer mostogradnja). Kasnije se uvidjelo da je softver po mnogočemu
specifičan te da zahtijeva drukčije pristupe. Razvijali su se novi programski jezici, bolji načini
utvrđivanja zahtjeva, grafički jezici za modeliranje, formalne metode za specifikaciju i
verifikaciju, pouzdaniji načini vođenja projekata i procjene troškova, alati koji nastoje
automatizirati proces razvoja softvera. Zahvaljujući takvom razvoju, softversko inženjerstvo
uspjelo se etablirati kao važan dio tehnike i računarstva. Softver se u današnje vrijeme
proizvodi daleko predvidljivije i efikasnije nego prije. Ipak, još uvijek postoji širok prostor za
poboljšanje.
Važna osobina softverskog inženjerstva je da u njemu nema „jednoumlja“ ni jednoobraznosti.

Za razliku od matematike gdje se proučavaju nepobitne istine, u softverskom inženjerstvu
razvijaju se različite ideje i pristupi koji su često u međusobnom nesuglasju. Glavni razlog za
takvu raznolikost pristupa je raznolikost samih softverskih produkata – zaista, teško je
očekivati da se sve vrste softvera mogu razvijati na isti način. Drugi razlog za raznolikost je
činjenica da softversko inženjerstvo još uvijek nije doseglo svoju zrelu fazu – ta disciplina se i
ovog trenutka intenzivno razvija, a nove spoznaje stalno revidiraju stare.
1.1.2. Softverski proces, metode i alati
Softverski proces je skup aktivnosti i pripadnih rezultata čiji cilj je razvoj ili evolucija
softvera. Osnovne aktivnosti unutar softverskog procesa su: utvrđivanje zahtjeva, oblikovanje,
implementacija, verifikacija i validacija te održavanje odnosno evolucija.
Model za softverski proces je idealizirani prikaz softverskog procesa, kojim se određuje

poželjan način odvijanja i međusobnog povezivanja osnovnih aktivnosti. Na primjer, model

može zahtijevati sekvencijalno odnosno simultano odvijanje aktivnosti. Najvažniji modeli bit
će opisani u potpoglavlju 1.2.
Metoda razvoja softvera je profinjenje i konkretizacija odabranog modela za softverski

proces. Metoda uvodi specifičnu terminologiju. Također, ona dijeli osnovne aktivnosti u
podaktivnosti te propisuje što se sve mora raditi unutar pojedine podaktivnosti. Dalje, metoda
uvodi konkretan način dokumentiranja rezultata podaktivnosti (dijagrami, tabele, pseudojezik,
… ) te daje naputke vezane uz organizaciju rada, stil oblikovanja, stil programiranja i tako
dalje. Više o metodama razvoja softvera bit će rečeno u potpoglavlju 1.3.
CASE alati (Computer Aided Software Engineering) su softverski paketi koji daju
automatiziranu podršku za pojedine aktivnosti unutar softverskog procesa. Obično su
napravljeni u skladu s određenom metodom razvoja softvera, implementiraju pravila iz te
metode, sadrže editore za odgovarajuće dijagrame i služe za izradu odgovarajuće
dokumentacije. Dijele se u dvije vrste.
 Upper-CASE alati daju podršku za početne aktivnosti unutar softverskog procesa, kao što
su utvrđivanje zahtjeva i oblikovanje.
 Lower-CASE alati podržavaju samu realizaciju softvera, dakle programiranje, verifikaciju
i validaciju te eventualno održavanje.
Na vježbama iz ovog kolegija obradit ćemo jednu konkretnu metodu razvoja softvera, koja se
zove UP i koja je potpomognuta grafičkim jezikom UML. Služit ćemo se upper-CASE alatom
Visual Paradigm [11] za modeliranje sustava i crtanje UML dijagrama. Na vježbama iz drugih
kolegija studenti su imali prilike raditi s lower-CASE alatom Microsoft Visual Studio [12]
koji daje podršku za implementaciju i verifikaciju softvera pisanog u jezicima poput C++ ili
C#.
1.1.3. Dokumentacija softvera
Kad smo govorili o softverskom produktu rekli smo da se on sastoji od računalnih programa i
pripadne dokumentacije. Dakle, razvoj softvera ne svodi se samo na razvoj programa nego
također i na sastavljanje dokumenata koji prate te programe. Dokumentacija je sastavni i
nezaobilazni dio onoga što softverski inženjeri proizvode.
Dokumentacija softvera može se podijeliti u dvije kategorije.

 Sistemska dokumentacija namijenjena je softverskim inženjerima ili članovima razvojnog
tima, opisuje zahtjeve ili građu ili funkcioniranje sustava te omogućuje sam razvoj
softvera i njegovo kasnije održavanje.
 Korisnička dokumentacija namijenjena je korisnicima, omogućuje im da koriste sustav te
opisuje funkcije sustava na njima razumljiv način.
U daljnjim poglavljima opisat ćemo nekoliko primjera dokumenata koji spadaju u sistemsku
dokumentaciju. Na primjer to su sljedeći dokumenti.
 Dokument o zahtjevima. Opisuje zahtjeve na sustav, dakle što sustav treba raditi i uz koja
ograničenja.
 Dizajn sustava (projektna dokumentacija). Nastaje kao rezultat oblikovanja sustava.
Opisuje kako sustav treba biti građen te kako treba raditi da bi obavio svoje funkcije.

Robert Manger
 Plan testiranja. Sadrži primjere test podataka i odgovarajućih očekivanih rezultata. Služi
nakon bilo kakve promjene programa za provjeru da li je sačuvana dotadašnja
funkcionalnost programa.
 Izvorni tekst programa, pisan u programskom jeziku i nadopunjen odgovarajućim
komentarima. Nastaje kao rezultat implementacije sustava i na najizravniji način
dokumentira sustav.
Kad god koristimo neki generički softverski produkt, na primjer operacijski sustav ili paket za
uredsko poslovanje ili sustav za upravljanje bazom podataka, susrećemo se s raznim
dokumentima koji spadaju u korisničku dokumentaciju. Evo nekoliko primjera takvih
dokumenata.
 Funkcionalni opis. Namijenjen je evaluatorima sustava, dakle osobama koje će odlučiti da
li da se koristi taj sustav ili neki drugi. Daje se grubi opis što sustav može a što ne može
raditi. Priloženi su primjeri, tabele i dijagrami. Ne objašnjavaju se operativni detalji.
 Vodič za instalaciju. Namijenjen je sistem-administratoru ili korisniku. Opisuje instalaciju
sustava na zadanoj vrsti računala. Sadrži opis distribucijskog medija, definiciju minimalne
hardverske i softverske konfiguracije potrebne za pokretanje sustava, proceduru
instaliranja i podešavanja.
 Uvodni priručnik. Namijenjen je novim korisnicima. Daje neformalni uvod u sustav te
opisuje njegovu „normalnu“ uporabu. Pisan je u formi „tečaja“, sadrži mnogo primjera,
te uputa kako izbjeći uobičajene greške.
 Referentni priručnik. Namijenjen je iskusnim korisnicima. U potpunosti i na vrlo precizan
način dokumentira sve funkcije sustava, sve oblike njegove uporabe te sve greške koje
mogu nastupiti. Nije u formi tečaja. Stil je formalan, struktura je stroga. Snalaženje u
tekstu osigurano je preko indeksa pojmova.
 Priručnik za administriranje. Namijenjen je sistem-administratorima ili operatorima.
Opisuje aktivnosti poput backup-a, upravljanja resursima, praćenja performansi,
podešavanja rada, evidentiranja korisnika, postavljanja zaštite.
Izradu dokumentacije jednim dijelom je moguće automatizirati ili barem olakšati korištenjem
CASE-alata. No za konačno oblikovanje dokumenata potrebni su nam standardni uredski alati
poput tekst procesora ili alata za crtanje dijagrama. Osim u obliku dokumenata (bilo
papirnatih bilo elektroničkih) dokumentacija može postojati i u on-line obliku, dakle ona
može biti izravno dostupna iz samog softvera koji opisuje.
1.2. Modeli za softverski proces
Zajednička osobina svih modela za softverski proces je da se oni u većoj ili manjoj mjeri
zasnivaju na otprilike istim osnovnim aktivnostima. Zaista, to su sljedeće aktivnosti.
 Utvrđivanje zahtjeva (specifikacija). Analiziraju se zahtjevi korisnika. Utvrđuje se što
softver treba raditi.
 Oblikovanje (design). Oblikuje se građa sustava, način rada njegovih dijelova te sučelje
između dijelova. Dakle projektira se rješenje koje određuje kako će softver raditi.
 Implementacija (programiranje). Oblikovano rješenje realizira se uz pomoć raspoloživih
programskih jezika i alata.
 Verifikacija i validacija. Provjerava se da li softver radi prema specifikaciji, odnosno da li
radi ono što korisnik želi. Obično se svodi na testiranje, mada postoje i druge tehnike.
 Održavanje odnosno evolucija. Nakon uvođenja u uporabu, softver se dalje popravlja,
mijenja i nadograđuje, u skladu s promijenjenim potrebama korisnika.
Modeli se razlikuju po načinu odvijanja i međusobnog povezivanja osnovnih aktivnosti.

Također, svaki od njih može staviti veći ili manji naglasak na pojedinu aktivnost. U sljedećim
odjeljcima opisat ćemo nekoliko modela te ćemo istaknuti njihove prednosti i mane.
1.2.1. Model vodopada
Model vodopada (waterfall model) nastao je u ranim 70-im godinama 20. stoljeća, kao
neposredna analogija s procesima iz drugih inženjerskih struka (na primjer mostogradnja).
Softverski proces građen je kao niz vremenski odvojenih aktivnosti, u skladu sa slikom 1.1.
Utvrđivanje zahtjeva Dokument o zahtjevima

(specifikacija)
Dizajn sustava
Oblikovanje (design)
Programiranje i testiranje Moduli

modula
Integracija modula i Sustav
testiranje sustava
Puštanje u rad i održavanje
Slika 1.1: softverski proces prema modelu vodopada.
Model je dobio ime zbog oblika dijagrama. Vidimo da se aktivnosti odvijaju kao faze
sekvencijalno jedna iza druge. Svaka faza daje neki rezultat koji „teče“ po vodopadu i
predstavlja polazište za iduću fazu. Makar je na slici naznačena mogućnost povratka u raniju
fazu (u slučaju naknadnog otkrivanja greške), ta mogućnost samo se iznimno koristi. Povratak
je nepoželjan jer remeti normalni tijek procesa te izaziva kašnjenje.
Prednosti modela vodopada su sljedeće.

 Model omogućuje detaljno planiranje cijelog softverskog procesa i podjelu poslova na
velik broj suradnika.
 Lagano se može utvrditi stanje u kojem se proces trenutno nalazi.
 Zato je model je dobro prihvaćen od menadžera.
Mane modela vodopada su sljedeće.

 Navedene faze u praksi je teško razdvojiti, pa dolazi do naknadnog otkrivanja grešaka i
nepoželjnog vraćanja u prethodne faze.
 Zbog tendencije da se zbog poštovanja rokova u određenom trenutku „zamrzne“ pojedina
faza, dešava se sustav nastavlja razvijati u nezadovoljavajućem obliku.
 Proces je spor, pa se može dogoditi da u trenutku puštanja u rad sustav već bude neažuran
i zastario.

Robert Manger
Zbog navedenih prednosti te unatoč navedenim manama, model se često koristi u praksi.
Model je pogodan onda kad treba razviti veliki sustav s relativno jednostavnim i jasnim
zahtjevima uz pomoć velikog broja programera.
1.2.2. Modeli evolucijskog i inkrementalnog razvoja
Model evolucijskog razvoja (evolutionary development) nastao je kao protuteža modelu

vodopada. U tom modelu na osnovu približnog opisa problema razvija se polazna verzija
sustava koja se pokazuje korisniku. Temeljem korisnikovih primjedbi, ta polazna verzija se
poboljšava, opet pokazuje, i tako dalje. Nakon dovoljnog broja iteracija dobiva se konačna
verzija sustava. Unutar svake iteracije, osnovne aktivnosti se obavljaju simultano i ne daju se
razdvojiti. Postupak je ilustriran slikom 1.2.
Polazna
simultane aktivnosti verzija
Utvrđivanje zahtjeva
(specifikacija) Oblikovanje (design)
Približni Privremene
opis verzije
Implementacija Verifikacija, validacija
Konačna
verzija
Slika 1.2: evolucijski razvoj softvera.
Evolucijski razvoj čiji cilj je da se s korisnikom istraže zahtjevi te zaista proizvede konačni
sustav zove se istraživačko programiranje. Ukoliko je jedini cilj istraživanje zahtjeva (nakon
čega slijedi oblikovanje i implementacija modelom vodopada), tada je riječ o prototipiranju -
vidi potpoglavlje 2.2.
Prednosti modela evolucijskog razvoja su sljedeće.

 Model je u stanju proizvesti brzi odgovor na zahtjeve korisnika.
 Razvoj je moguć i onda kad su zahtjevi ispočetka nejasni.
 Specifikacija se može postepeno razvijati u skladu sa sve boljim korisnikovim
razumijevanjem problema.
Mane modela evolucijskog razvoja su sljedeće.

 Proces nije transparentan za menadžere, naime oni ne mogu ocijeniti koliki dio posla je
napravljen i kad će sustav biti gotov.
 Konačni sustav obično je loše strukturiran zbog stalnih promjena te je nepogodan za
kasnije održavanje.
 Zahtijevaju se posebni alati i natprosječni softverski inženjeri.

Model se uspješno koristi za razvoj web sjedišta te za male sustave s kratkim životnim
vijekom, pogotovo za sustave s nejasnim zahtjevima.
Model inkrementalnog razvoja (incremental development) sličan je modelu evolucijskog

razvoja i može se shvatiti kao hibrid vodopada i evolucije. Sustav se opet razvija u nizu
iteracija. No za razliku od evolucijskog modela, pojedina iteracija ne dotjeruje već realizirani
dio sustava, nego mu dodaje sasvim novi dio - inkrement. Razvoj jednog inkrementa unutar
jedne iteracije odvija se po bilo kojem modelu - na primjer kao vodopad. Ideja je prikazana na
slici 1.3.
Rasporedi Oblikuj
Definiraj
zahtjeve na arhitekturu
okvirne zahtjeve
inkremente sustava
Specificiraj,
Verificiraj i
oblikuj i imple- Integriraj novi
mentiraj novi
validiraj novi Konačni sustav
inkrement
inkrement
inkrement
sustav je nedovršen
Slika 1.3 inkrementalni razvoj softvera.
Prednosti modela inkrementalnog razvoja su sljedeće.

 Proces je još uvijek prilično transparentan za menadžere, budući da je vidljivo do kojeg
smo inkrementa došli.
 Korisnici ne moraju dugo čekati da bi dobili prvi inkrement koji zadovoljava njihove
najpreče potrebe. Razvoj slijedi prioritete.
Mane modela inkrementalnog razvoja su sljedeće.

 Koji put je teško podijeliti korisničke zahtjeve u smislene inkremente.
 Budući da cjelokupni zahtjevi nisu dovoljno razrađeni na početku, teško je odrediti
zajedničke module koji su potrebni raznim inkrementima i koji bi morali biti
implementirani u prvom inkrementu.
Ipak, ovo je vrlo uporabljiv model koji se intenzivno koristi u praksi. Svi generički softverski
paketi poput Microsoft Office-a i slični zapravo su se razvijali u inkrementima. Svaka njihova
nova verzija donosila je nove mogućnosti.
1.2.3. Modeli formalnog i grafičkog razvoja
Model formalnog razvoja (formal systems development) zasniva se na korištenju takozvanih

formalnih metoda za razvoj softvera. Zahtjevi se precizno definiraju na formalni način,
korištenjem nedvosmislene matematičke notacije. Zatim se ta formalna specifikacija
transformira do programa, nizom koraka koji čuvaju korektnost. Cijeli proces prikazan
je u slikom 1.4, dok je ideja formalnih transformacija detaljnije ilustrirana slikom 1.5.
Robert Manger
Neformalna Formalna Formalne Integracija

specifikacija specifikacija transformacije i testiranje sustava
Slika 1.4: proces formalnog razvoja softvera.
Formalne
transformacije:
Formalna Sve detaljnije

Izvršivi reprezntacije
specifikacija R1 R2 R3
program sustava
softvera
Dokazi
korektnosti
D1 D2 D3 D4 transformacija
Slika 1.5: formalne transformacije u sklopu formalnog razvoja softvera.
Prednosti modela formalnog razvoja su sljedeće.

 Nakon izrade formalne specifikacije, sve daljnje faze razvoja softvera mogle bi se
automatizirati.
 Postoji „matematički“ dokaz da je program točna implementacija polazne specifikacije;
nema velike potrebe za testiranjem.
 Rješenje je neovisno o platformi, dakle portabilno.
Mane modela formalnog razvoja su sljedeće.

 Izrada formalne specifikacije zahtijeva velik trud i znanje.
 Dokazi korektnosti transformacija postaju preglomazni za iole veće sustave.
 Korisnici ne mogu pratiti razvoj.
 Postojeći specifikacijski jezici nisu pogodni za interaktivne sustave.
Model formalnog razvoja za sada se relativno malo koristi u praksi te se preporučuje jedino za
sustave gdje se zahtijeva izuzetno velika pouzdanost i sigurnost. Moguće je da će se model
znatno više koristiti u budućnosti ukoliko se razviju bolji specifikacijski jezici te bolji alati za
automatske transformacije.
Model grafičkog razvoja (Model Driven Engineering – MDE) u osnovi je sličan modelu
formalnog razvoja. Umjesto formalne specifikacije razvija se grafički model (skup dijagrama)
koji prikazuje građu i ponašanje sustava. Koristi se grafički jezik za modeliranje poput UML
– vidi potpoglavlje 2.3. Primijetimo da se ovdje riječ „model“ pojavljuje u dva značenja:
model sustava nije isto što i model softverskog procesa. Pretpostavlja se da postoji alat koji
dijagrame automatski pretvara u program. Cijeli proces prikazan je slikom 1.6.
Model grafičkog razvoja ima svoje pobornike i trenutno je predmet intenzivnog istraživanja.
Prednosti su mu slične kao kod formalnog razvoja, s time da bi trebao biti jednostavniji za
korištenje. Glavna mana mu je da za sada nije uporabljiv osim u vrlo jednostavnim
primjerima. Današnji CASE alati u stanju su generirati dio programskog koda iz UML
dijagrama, no daleko su od toga da bi mogli generirati cijeli program.

Utvrđivanje Grafičko Automatsko

modeliranje generiranje
zahtjeva
(analiza, programa iz
(specifikacija)
oblikovanje) grafičkog
modela
Slika 1.6: proces grafičkog razvoja.
Kod složenijih sustava UML dijagrami zapravo i ne mogu jednoznačno opisati sve detalje. To
se u UML verziji 2.0 nastoji nadoknaditi uvođenjem posebnog jezika zvanog Object
Constraint Language – OCL; on služi za specificiranje ograničenja koja nisu vidljiva iz
dijagrama. Očekuje se da će OCL i slični jezici pomoći da se ostvari automatsko generiranje
programa iz modela ustava. No uvođenjem takvih jezika grafički pristup postaje još sličniji
formalnom pristupu.
1.2.4. Model usmjeren na ponovnu upotrebu
Model usmjeren na ponovnu upotrebu (reuse-oriented development) polazi od pretpostavke

da već postoje gotove i upotrebljive softverske cjeline, kao što su COTS sustavi (Commercial
Off-The-Shelf Systems) ili dijelovi prije razvijenih sustava. Novi sustav nastoji se u što većoj
mjeri realizirati spajanjem postojećih dijelova, u skladu sa slikom 1.7. Ista ideja prisutna je i u
drugim tehničkim disciplinama: novi mehanički ili elektronički proizvod nastoji se sklopiti od
postojećih standardnih dijelova (vijaka, čipova, ... ).
Analiza Oblikovanje
Utvrđivanje raspoloživih Modifikacija sustava uz
zahtjeva dijelova zahtjeva ponovnu upotrebu
dijelova
Implementacija Verifikacija i
i integracija validacija sustava
Slika 1.7: proces razvoja softvera uz ponovnu upotrebu.
Prednosti modela usmjerenog na ponovnu upotrebu su sljedeće.

 Smanjuje se količina softvera kojeg stvarno treba razviti te se tako smanjuje vrijeme,
trošak i rizik.
 Stavlja se oslonac na provjerene i dobro testirane dijelove softvera.
Mane modela usmjerenog na ponovnu upotrebu su sljedeće.

 Zbog kompromisa u specifikaciji moguće je da sustav neće u potpunosti odgovoriti
stvarnim potrebama korisnika.
 Djelomično je izgubljena kontrola nad evolucijom sustava, budući da ne upravljamo
razvojem novih verzija korištenih dijelova.

Robert Manger
Očekuje se da će ovaj model ipak postati prevladavajući u 21. stoljeću, budući da je broj
gotovih rješenja sve veći, a korisnici imaju sve manje vremena za čekanje rješenja. Ideja
ponovne upotrebe te razni načini njene realizacije detaljno će biti obrađena u poglavlju 6.
1.3. Klasične i agilne metode razvoja softvera
Rekli smo da se rad softverskog tima obično organizira u skladu s nekom metodom razvoja
softvera. Svaka od metoda slijedi jedan od modela za softverski proces ili kombinira više
modela. Osnovne aktivnosti iz modela podijeljene su u manje aktivnosti. Propisuje se način
odvijanja svake aktivnosti te način njenog dokumentiranja. U sljedećim odjeljcima navodimo
osnovna svojstva pojedinih vrsta metoda te detaljnije opisujemo dvije danas aktualne metode:
UP odnosno XP.
1.3.1. Vrste metoda i njihova svojstva
Od početka softverskog inženjerstva do danas pojavilo se nekoliko stotina metoda za razvoj

softvera. Njih ugrubo možemo podijeliti u klasične i agilne metode.
Klasične metode pojavile su se još u 70-im godinama 20. stoljeća, a razvijaju se i danas. One
se odlikuju sljedećim svojstvima.
 Razvoj softvera promatra se kao pažljivo planirani proces koji ima svoj početak i kraj. U
tom procesu u potpunosti se utvrđuju zahtjevi te se softver realizira u skladu s njima.
 Provodi se upravljanje projektom. Određuje se precizni plan aktivnosti, po potrebi i za
dulji vremenski period unaprijed. Određuje se raspored ljudi i resursa po aktivnostima.
 Inzistira se na urednom dokumentiranju svih aktivnosti i svih proizvedenih dijelova
softvera.
Klasične metode dalje se dijele na funkcionalno-orijentirane te na objektno-orijentirane.

Starije funkcionalno-orijentirane metode poput Yourdonove ili Jacksonove JSD (80-e godine
20. stoljeća) slijede logiku starijih funkcionalno-orijentiranih programskih jezika (Cobol, C,
Fortran). Novije objektno-orijentirane metode predstavljaju nadgradnju objektno-orijentiranih
programskih jezika (Java, C++, C#) i danas su se integrirale u zajednički standard UP
(Unified Process - Booch, Rumbaugh, Jacobson - 90-e godine) koji se oslanja na grafički
jezik UML (Unified Modelling Language).
Kao protuteža klasičnim metodama, početkom 21. stoljeća pojavile su se agilne metode.
Njihova glavna namjera bila je ubrzati razvoj softvera i izbjeći nepotrebnu administraciju.
Agilne metode imaju sljedeća svojstva.
 Razvoj softvera promatra se kao kontinuirani niz iteracija čiji broj nije moguće
predvidjeti. Svaka iteracija usklađuje sustav s trenutnim zahtjevima. Zahtjevi se stalno
mijenjaju, ne postoji cjelovita ili konačna specifikacija.
 Ne postoji upravljanje projektom u pravom smislu riječi. Aktivnosti se dogovaraju s
korisnicima te se odvijaju uz njihovo aktivno sudjelovanje. Planiranje je kratkoročno –
jedan ili dva tjedna unaprijed.
 Izbjegavaju se svi oblici dokumentacije osim onih koji se mogu automatski generirati iz
programa. Smatra se da sam program u izvornom obliku predstavlja svoju najpouzdaniju
dokumentaciju.

Najpopularnija agilna metoda je Extreme Programming – XP. Također je poznata metoda

Scrum koja se uglavnom bavi agilnim vođenjem projekta i može se kombinirati s XP. Ima i
pokušaja da se definira agilna varijanta inače klasične metode UP.
U literaturi su zabilježena brojna istraživanja koja mjere i uspoređuju učinkovitost pojedinih

metoda za razvoj softvera. Prema tim istraživanjima, agilne metode imaju svojih prednosti
kad je riječ o malim i kratkoročnim projektima u brzo promjenjivom poslovnom okruženju.
No nije se još dokazalo da se agilne metode mogu uspješno skalirati na velike projekte. Zato
se danas veliki softverski sustavi i dalje razvijaju klasičnim i to objektno-orijentiranim
metodama. Agilne metode našle su svoje mjesto na primjer u razvoju web aplikacija ili u
razvoju mobilnih aplikacija.
1.3.2. Primjer klasične metode
Kao primjer klasične metode razvoja softvera opisat ćemo Unified Process – UP. Riječ je o
„public domain“ verziji komercijalne metode Rational Unified Process – RUP. I UP i RUP
koriste se za razvoj objektno-orijentiranih sustava.
UP je nastala na samom kraju 20. Stoljeća u tvrtci Rational Corporation koja je danas dio
IBM-a. Stvorio ju je Ivar Jacobson u suradnji s Grady Boochom i Jamesom Rumbaughom.
Ime je odabrano zato što je UP objedinio nekoliko prijašnjih metoda istih autora. UP je u
bliskoj vezi s grafičkim jezikom UML – vidi potpoglavlje 2.3 – obje tvorevine razvijene su u
okviru istog projekta s namjerom da budu komplementi jedna drugoj. Zaista, UP određuje
kako će se odvijati proces razvoja softvera, a UML omogućuje da se rezultati tog razvoja
dokumentiraju.
Slika 1.8: Faze i temeljne aktivnosti unutar UP.

Robert Manger
Proces razvoja softvera u skladu s UP sastoji se od 4 faze (phases) koje se realiziraju u

vremenskom slijedu jedna iza druge. Pojedina faza završava onda kad se dosegne njezin
međaš (milestone), dakle kad se postignu njeni ciljevi. Svaka faza realizira se kroz simultano i
iterativno odvijanje 5 temeljnih aktivnosti (core workflows). Sve je to ilustrirano slikom 1.8.
Zbog postojanja vremenski odvojenih faza mogli bismo reći da UP uspostavlja softverski
proces nalik na model vodopada. S druge strane, iteracija temeljnih aktivnosti liči na model
evolucijskog razvoja. Dakle UP ustvari kombinira ta dva modela nastojeći iskoristiti prednosti
jednog i drugog.
Slika 1.8 također pokazuje da u svakoj fazi postoji jedna ili dvije osnovne aktivnosti na koje
je stavljen poseban naglasak i koje se obavljaju s povećanim intenzitetom. Kod manjih
projekata faze možemo poistovjetiti s odgovarajućim dominantnim aktivnostima, pa
dobivamo proces sličan vodopadu.
U nastavku detaljnije opisujemo faze u UP, njihove ciljeve, naglaske i međaše.

 Inception. Ciljevi su: dokazati izvedivost i isplativost projekta, utvrditi ključne zahtjeve da
bi se vidio kontekst (doseg) sustava, prepoznati rizike. Naglasak je na temeljnim
aktivnostima: zahtjevi i analiza. Naziv međaša je: Life Cycle Objectives.
 Elaboration. Ciljevi su: stvoriti izvršivu jezgru arhitekture sustava. Profiniti procjenu
rizika, definirati atribute kvalitete, evidentirati slučajeve uporabe (use case) koji pokrivaju
80% funkcionalnih zahtjeva, stvoriti detaljni plan za fazu konstrukcije. Naglasak je na
temeljnim aktivnostima: zahtjevi, analiza te pogotovo oblikovanje. Naziv međaša je: Life
Cycle Architecture.
 Construction. Ciljevi su: dovršiti zahtjeve, analizu i oblikovanje te dograditi jezgru
arhitekture do konačnog sustava. Pritom treba očuvati integritet arhitekture i oduprijeti se
pritiscima da se sustav dovrši na brzinu. Obaviti beta test i pokrenuti sustav. Naglasak je
na temeljnim aktivnostima: oblikovanje te pogotovo implementacija. Naziv međaša je:
Initial Operational Capability.
 Transition. Ciljevi su: popraviti uočene greške, prirediti sustav za rad u korisničkoj
okolini, distribuirati ga na korisnička radna mjesta, stvoriti korisničku dokumentaciju,
organizirati podršku korisnicima, napraviti “post-project review”. Naglasak je na
temeljnim aktivnostima: implementacija te pogotovo testiranje. Naziv međaša je: Product
Release.
Dalje opisujemo temeljne aktivnosti u UP.

 Zahtjevi (requirements). Utvrđuje se što sustav treba raditi.
 Analiza (analysis). Zahtjevi se analiziraju, profinjuju i strukturiraju.
 Oblikovanje (design). Predlaže se građa sustava koja će omogućiti da se zahtjevi
realiziraju.
 Implementacija (implementation). Stvara se softver koji realizira predloženu građu.
 Testiranje (test). Provjerava se da li stvoreni softver zaista radi onako kako bi trebao.
Makar je nastala relativno nedavno, UP je po svojim osobinama ipak klasična metoda. Naime,
ona razvoj softvera promatra kao kompleksan projekt koji ima svoj početak i kraj i kojim
treba upravljati. Također, ona predviđa da će se svi rezultati dokumentirati, na primjer
pomoću odgovarajućih UML dijagrama. Više detalja o UP-u može se naći u knjizi [9].

1.3.3. Primjer agilne metode
Kao primjer agilne metode razvoja softvera opisat ćemo Extreme Programming – XP. Metoda
je nastala oko 2000-te godine i pripisuje se autoru Kentu Becku. Detaljnije je opisana u knjizi
[10]. Naziv je odabran zato što XP ideju iterativnog razvoja softvera s naglaskom na
programiranje tjera do ekstremnih razmjera.
Razvojni proces u skladu s XP prikazan je na slici 1.9. Proces se sastoji od kontinuiranog niza
vrlo brzih iteracija. Svaka iteracija stvara novo izdanje sustava koje se isporučuje korisniku.
Vremenski razmak između dvije isporuke nije veći od dva tjedna.
Izaberi Razbij
Planiraj novo
korisničke priče korisničke priče
izdanje
za novo izdanje u zadatke
Razvij,
Isporuči novo
Evaluiraj sustav integriraj i
izdanje
testiraj softver
Slika 1.9: jedna iteracija metode XP.
Novo izdanje sustava može sadržavati novu funkcionalnost – tada XP podsjeća na model
inkrementalnog razvoja za softverski proces. No moguće je da novo izdanje samo popravlja
ili mijenja već postojeću funkcionalnost – tada XP liči na model evolucijskog razvoja. Dakle,
XP kombinira inkrementalni i evolucijski model. No naglasak je na izuzetno kratkim i brzim
iteracijama.
Zahtjevi u XP prikazuju se kao skup kratkih kartica teksta, takozvanih korisničkih priča (user
stories). Na početku iteracije biraju se one priče koje će se implementirati u dotičnom izdanju
– uzima se onoliko priča koliko se može implementirati u dva tjedna i to one s najvišim
prioritetom. Ostale priče se ostavljaju za buduća izdanja. Odabrane priče razgrađuju se u
manje zadatke koji se raspoređuju programerima u skladu s procijenjenom složenošću.
Opisani neformalni postupak planiranja novog izdanja naziva se planning game.
U XP-u ne može doći do kašnjenja isporuke – ono što se do predviđenog roka isporuke
uspjelo implementirati to se isporučuje, ostalo se ostavlja za buduća izdanja. Naručitelj
programerima plaća utrošeno radno vrijeme. Nema ugovora koji bi vezao plaćanje uz traženu
funkcionalnost.
U metodi XP iznimno važnu ulogu igraju korisnici. Postoji predstavnik korisnika koji je član
razvojnog tima i stalno je dostupan ostalim članovima. On donosi korisničke priče, određuje
prioritete, dogovara se o sadržaju idućeg izdanja, sudjeluje u testiranju sustava. Također,
predstavnik korisnika odlučuje što će se napraviti s nerealiziranim pričama te treba li neku od
već implementiranih priča promijeniti i ponovo implementirati.

Robert Manger
Zanimljiva inovacija koju je XP donio u programersku praksu naziva se test-first

development. Pri realizaciji bilo kojeg programerskog zadatka najprije se sastavljaju testovi za
dotični novi komad funkcionalnosti, a tek onda se ta funkcionalnost ide implementirati. Čim
je novi programski kod napisan, on se odmah testira. Da bi se ovakav način rada bio efikasan,
nužan je odgovarajući CASE-alat koji omogućuje lagano zadavanje, pohranjivanje te
automatsko izvršavanje testova.
Testovi dobiveni primjenom test-first development-a trajno se pohranjuju. Kad god se stvori
nova verzija softvera, nad njom se osim najnovijih testova također moraju izvršiti i svi
prijašnji testovi. Time se osigurava da najnovije promjene nisu narušile staru funkcionalnost.
Druga inovacija koju je XP donio u programersku praksu je programiranje u paru (pair

programming). Dakle, jedan zadatak ne obavlja jedan programer nego dvojica – oni sjede za
istom radnom stanicom i zajedno pišu isti programski kod. Prednost takvog načina rada je da
dvojica suradnika u zajedničkoj diskusiji lakše dolaze do dobrog rješenja te jedan drugom
ispravljaju greške. Parovi nisu fiksirani već se mijenjaju od zadatka do zadatka. Time se
postiže kolektivno vlasništvo nad programskim kodom, gdje su svi upućeni u sve dijelove
programa i sve mogu promijeniti.
Još jedna osobina XP-a je da se softver oblikuje tako da podrži trenutne zahtjeve i ništa više
od toga. Takvo oblikovanje je u suprotnosti s principima tradicionalnog softverskog
inženjerstva gdje se softver nastoji izgraditi dovoljno općenito da bi se u budućnosti lako
mogao mijenjati. Pobornici XP smatraju da se promjene ionako ne mogu predvidjeti, pa se ne
isplati o njima brinuti unaprijed.
Opasnost kod bilo koje vrste iterativnog razvoja softvera je da se struktura softvera postepeno
degradira uslijed stalnih promjena. XP se bori protiv te opasnosti povremenim
reorganiziranjem programskog koda, takozvanim refactoring-om. Dakle, kad programer
primijeti da se struktura programa previše narušila, on je popravlja tako da pojednostavi ili
premjesti neke dijelove koda, eliminira ponavljanje sličnih dijelova, i tako dalje.
Metoda XP ne propisuje nikakve oblike dokumentacije. Naime, prema pobornicima XP,

jednostavan i pregledno napisani programski kod sam sebe najbolje dokumentira. Štoviše, iz
tog koda moguće je automatski generirati razne izvještaje i dijagrame kakvi se inače koriste u
dokumentima. Ovakav pristup je realističan u situaciji kad se nove verzije softvera proizvode
gotovo svakodnevno – ažuriranje zasebne dokumentacije predstavljalo bi preveliki teret i bilo
bi podložno greškama.
Iz svega izloženog vidimo da XP ima sve osobine agilne metode za razvoj softvera. Brojni
softverski timovi u cijelosti su prihvatili XP i pokazali da agilni način rada može biti efikasan
barem kod manjih projekata s vrlo promjenjivim zahtjevima. No još je veći broj onih timova
koji su izabrali samo neke od XP-ovih značajki, na primjer test-first development ili
programiranje u paru te ih uklopili u neku klasičnu metodu.
1.4. Upravljanje softverskim projektom
Vidjeli smo da klasične metode razvoja softvera predviđaju da će se softverski proces odvijati
kao projekt. To znači da softversko inženjerstvo, osim računarskog i tehničkog aspekta, ima i

svoj menadžerski aspekt. Upravljanje softverskim projektom povjerava se softverskom

menadžeru, dakle osobi koja raspolaže menadžerskim znanjima i sposobnostima.
Upravljanje softverskim projektom bit će tema posebnog kolegija. Zato ovo potpoglavlje daje
samo uvodni prikaz te složene problematike. U idućim odjeljcima najprije se nabrajaju razni
poslovi koje obavlja softverski menadžer. Zatim se nešto podrobnije opisuju dva takva posla:
planiranje i praćenje projekta te upravljanje rizicima.
1.4.1. Poslovi softverskog menadžera
U svom radu softverski menadžer nastoji postići sljedeće ciljeve.

 Isporučiti softver naručitelju do ugovorenog roka.
 Držati ukupne troškove unutar planiranih granica.
 Stvoriti softver koji zadovoljava naručiteljeva očekivanja.
 Postići da razvojni tim dobro funkcionira i da njegovi članovi budu zadovoljni poslom
koji obavljaju.
Slični ciljevi žele se postići u bilo kojem inženjerskom projektu. Ipak, softversko inženjerstvo
razlikuje se od drugih inženjerskih struka, a te razlike čine upravljanje softverskim projektom
i postizavanje ovakvih ciljeva posebnim izazovom za menadžere. Evo nekih osobina po
kojima se razvoj softvera razlikuje od na primjer gradnje mosta ili broda.
 Produkt je „neopipljiv“. Teško je vidjeti rezultat. Teško je procijeniti koliki dio posla je
obavljen i da li je kvalitetno obavljen. Menadžer se mora pouzdati u apstraktne dokumente
ili na mišljenja suradnika.
 Nema standardnog razvojnog procesa. Postoje razne metode i alati, oni dosta ovise o
organizaciji koja ih primjenjuje. Ne zna se koji je najbolji način razvoja zadane vrste
softvera u zadanim okolnostima.
 Projekt je obično „neponovljiv“. Novi softver donosi nešto novo i još neviđeno. Iskustva
na starim projektima nisu sasvim primjenjiva. Ulaskom u nova područja susrećemo se s
nepredviđenim problemima. Tehnologija se brzo mijenja pa je način rada svaki put
drukčiji.
Zbog navedenih osobina nije nikakvo čudo da mnogi softverski projekti kasne, premašuju
troškove ili daju rezultate ispod očekivanja. Očito je da upravljanje softverskim projektom
zahtijeva izuzetno dobrog i snalažljivog menadžera.
Bilo bi vrlo teško sastaviti sveobuhvatni opis radnog mjesta softverskog menadžera. Taj opis
varira ovisno o organizaciji koja razvija softver te o vrsti softverskog produkta. Ipak, većina
menadžera u većoj ili manjoj mjeri obavlja sljedeće poslove.
 Pisanje prijedloga projekta, traženje podrške za njegovu realizaciju.
 Procjenjivanje troškova projekta.
 Planiranje i praćenje projekta.
 Upravljanje rizicima.
 Podnošenje izvještaja nadređenom menadžmentu ili naručiteljima.
 Izbor suradnika, poticanje njihovog individualnog i timskog rada.
Neki od ovih poslova, na primjer planiranje i praćenje, relativno su egzaktni i podržani su

odgovarajućim metodama i alatima. Za neke od preostalih poslova, na primjer za
procjenjivanje troškova, ne postoje pouzdane metode, tako da se kod njih menadžer mora
osloniti na svoje iskustvo i intuiciju.
Robert Manger
1.4.2. Planiranje i praćenje projekta
Planiranje i praćenje projekta predstavlja redoviti, svakodnevni i najegzaktniji posao

softverskog menadžera. Posao uključuje sljedeće:
 Definiranje projektnih aktivnosti, njihovog trajanja i međuzavisnosti.
 Određivanje kalendara početka i završetka svake aktivnosti.
 Raspoređivanje ljudi i drugih resursa na aktivnosti.
 Praćenje izvršenja aktivnosti.
 Povremenu reviziju svih parametara.
Za planiranje i praćenje menadžer koristi egzaktne upravljačke modele i metode, poput

mrežnih planova, analize kritičnih putova te Ganttovih dijagrama. Ti modeli i metode
implementirani su u alatima za upravljanje projektima kao što je Microsoft Project [13].
U nastavku ovog odjeljka slijedi ilustracija postupka planiranja i praćenja uz primjenu

spomenutih modela i metoda. Zamislimo projekt koji se može podijeliti u 12 aktivnosti.
Procijenjena trajanja tih aktivnosti u danima te njihove međuovisnosti prikazane su na slici
1.10. Na primjer, vidimo da aktivnost T5 treba trajati 10 dana te da ona može početi tek nakon
što su dovršene aktivnosti T2 i T4.
Slika 1.10: aktivnosti, trajanja, međuzavisnosti.
Postupak počinje tako da informacije sa slike 1.10 prikažemo kao mrežu (aciklički usmjereni
graf). U toj mreži čvorovi odgovaraju aktivnostima, a lukovi međuovisnostima (luk kaže da
aktivnost iz njegovog polaznog čvora mora prethoditi aktivnosti iz dolaznog čvora). Svakom
luku kao duljinu pridružimo trajanje aktivnosti iz njegovog polaznog čvora. Duljine putova u
mreži tada odgovaraju minimalnim trajanjima niza aktivnosti koje se zbog međuovisnosti
moraju odvijati sekvencijalno jedna nakon druge.

Za naš projekt mreža izgleda kao na slici 1.11. Osim „pravih“ aktivnosti T1, T2, ..., T12,
dodane su fiktivne aktivnosti Start i Finish koje odgovaraju početku i kraju projekta.
Također, dodani su takozvani međaši (milestones) M1, M2, ..., M8. Međaš je značajno mjesto
u projektu gdje su upravo završene neke aktivnosti i stvara se određeni izlaz. Taj izlaz može
biti na primjer izvještaj o obavljenom poslu ili dokument koji je dio sistemske dokumentacije
ili dio softvera. Međaši olakšavaju praćenje projekta – da bi ustanovio da li je neki međaš
dostignut menadžer provjerava postojanje traženog izlaza.
Slika 1.11: mreža s kalendarom aktivnosti.
Idući korak u planiranju projekta je sastavljanje kalendara aktivnosti. Kalendar se najlakše

zadaje uz pomoć mreže. Najprije se čvoru Start pridruži proizvoljni datum početka projekta.
Zatim se svakom čvoru čiji prethodnici već imaju određene datume odredi datum početka kao
najraniji mogući dan s obzirom na početke i trajanja prethodnika. Postupak se nastavlja sve
dok čvor Finish ne dobije datum – to je datum završetka cijelog projekta. Na slici 1.11 već je
upisan jedan mogući kalendar.
Mreža poput one na slici 1.11 omogućuje da se provede takozvana analiza kritičnih putova.
Kritični put je najdulji put od Start do Finish – taj pojam je dobro definiran jer je mreža
aciklička. Duljina kritičnog puta zapravo predstavlja minimalno vrijeme u kojem je moguće
izvršiti cijeli projekt. Aktivnosti na kritičnom putu zovu se kritične aktivnosti – na našoj slici
to su T1, M1, T3, M4, T9, M6, T11, M8, T12. Menadžer mora posvetiti posebnu pažnju
kritičnim aktivnostima jer kašnjenje bilo koje od njih izazvat će kašnjenje cijelog projekta. S
druge strane, za aktivnosti koje nisu na kritičnom izračunavaju se maksimalna kašnjenja koja
se mogu tolerirati jer još ne ugrožavaju vrijeme završetka cijelog projekta.
Informacije s mreže na slici 1.11 zajedno s rezultatima analize kritičnih putova mogu se
kompaktnije prikazati pomoću Ganttovog dijagrama – vidi sliku 1.12. Na Ganttovom
dijagramu vodoravna os odgovara vremenu a na uspravnoj osi su poredane aktivnosti.
Kalendar odvijanja svake aktivnosti prikazan je odgovarajućim pravokutnikom (vrpcom).
Zatamnjeni dio pravokutnika predstavlja tolerirano kašnjenje – primijetimo da za kritične
aktivnosti taj zatamnjeni dio ne postoji.

Robert Manger
Slika 1.12: Ganttov dijagram s kalendarom aktivnosti i toleriranim kašnjenjima.
Daljnji korak u planiranju projekta je raspoređivanje ljudi na aktivnosti. slika 1.13 sadrži
Ganttov dijagram gdje se vidi koji čovjek obavlja koju aktivnost u koje vrijeme. Raspored je
konzistentan s kalendarom aktivnosti sa slike 1.12, a također poštuje pravila da jednu
aktivnost obavlja samo jedan čovjek te da jedan čovjek istovremeno obavlja samo jednu
aktivnost. Osim ljudi, na sličan način mogu se rasporediti i drugi resursi poput računala,
prostorija i slično.
Slika 1.13: Ganttov dijagram s rasporedom ljudi po aktivnostima.

Dijagrami na slikama 1.11, 1.12 i 1.13 predstavljaju plan izvršavanja projekta. Nakon što se
projekt počne izvršavati, menadžer treba pratiti da li sve teče po planu. Kod većine projekata
prije ili kasnije dolazi do odstupanja od plana, na primjer desi se da neka od aktivnosti zakasni
više nego što se to može tolerirati. Tada je potrebno uvažiti nove podatke i ponovo generirati
sve dijagrame – dobit ćemo revidirani plan s odgođenim datumima završetka nekih aktivnosti.
Revizija plana obavlja se relativno lako i brzo ako se služimo alatom za upravljanje projektom
poput Microsoft Project.
1.4.3. Upravljanje rizicima
Upravljanje rizicima jedan je od najvažnijih poslova softverskog menadžera. Sastoji se od

predviđanja rizika koji bi mogli utjecati na projekt te od poduzimanja akcija da se oni
izbjegnu ili umanje. Rizici su nešto što bi voljeli da se ne desi, a dijele se u tri kategorije.
 Rizici vezani uz projekt. Utječu na odvijanje projekta ili na njegove resurse.
 Rizici vezani uz produkt. Utječu na kvalitetu softvera koji razvijamo u sklopu projekta.
 Poslovni rizici. Utječu na organizaciju koja izvršava ili financira projekt.
Ove kategorije donekle se preklapaju. slika 1.14 sadrži tri konkretna primjera rizika, svaki od
njih spada u jednu od tri navedene kategorije.
Primjer 1 Primjer 2 Primjer 3

Ključni članovi Baza podataka koju
Financijer projekta
razvojnog tima ugrađujemo u naš
možda će imati
možda će se produkt možda neće
Opis rizika financijskih problema
razboljeti u moći obraditi dovoljan
pa će htjeti smanjiti
najnezgodnije broj transakcija u
sredstva za projekt.
vrijeme. sekundi.
Kategorija
vezan uz projekt vezan uz produkt poslovni
rizika
Vjerojatnost
velika umjerena mala
pojavljivanja
Učinak rizika ozbiljan podnošljiv katastrofalan
Napiši unaprijed
dokument koji
Reorganiziraj tim
dokazuje da projekt
tako da ima više Nabavi odmah bolju
daje važan doprinos
Plan za preklapanja poslova bazu podataka za koju
poslovnim ciljevima
upravljanje pa će ljudi lakše je manje vjerojatno da
financijera te da bi
moći zamijeniti jedan će stvarati probleme.
smanjivanje sredstava
drugog.
donijelo više štete
nego koristi.
Strategija
minimizacija izbjegavanje priprema
plana
Slika 1.14: primjeri upravljanja rizicima.
Postupak upravljanja rizicima prikazan je slikom 1.15. Kao što vidimo, postupak se sastoji od
četiri faze od kojih svaka daje odgovarajuće rezultate. Zadnje tri od njih se iteriraju. U
nastavku detaljnije opisujemo svaku fazu.

Robert Manger
Identifikacija Analiza Planiranje Nadziranje

rizika rizika rizika rizika
Lista Rang lista Planovi za Nove

potencijalnih najznačajnijih upravljanje procjene
rizika rizika rizicima rizika
Slika 1.15: postupak upravljanja rizicima.
U prvoj fazi potrebno je identificirati rizike koji bi mogli predstavljati prijetnju procesu
razvoja softvera, softveru koji se razvija ili organizaciji koja je uključena u razvoj.
Identifikacija se najčešće svodi na „brainstorming“ u kojem sudjeluju svi članovi tima.
Također, softverski menadžer može upotrijebiti svoja iskustva iz prošlih projekata te se sjetiti
teškoća s kojima se ranije susretao. Postoje i check-liste uobičajenih rizika. Identifikacija
obično daje dosta dugačku listu potencijalnih rizika. No nastavak postupka izdvojit će samo
najvažnije članove te liste.
U fazi analize rizika za svaki od identificiranih rizika potrebno je procijeniti njegovu

vjerojatnost pojavljivanja te ozbiljnost njegovog učinka. Procjene se temelje na prosudbi i
iskustvu menadžera i obično se biraju iz sljedećeg skupa vrijednosti.
 Vjerojatnost pojavljivanja rizika može biti: vrlo mala (<10%) mala (10-25%), umjerena
(25-50%), velika (50-75%) ili jako velika (>75%).
 Učinak rizika može biti: katastrofalan (ugrožava opstanak projekta), ozbiljan (uzrokuje
veliko kašnjenje projekta), podnošljiv (kašnjenje je unutar dozvoljenog) ili neznatan.
Na slici 1.14 vide se procjene za naša tri primjera rizika. Te vrijednosti možda će se mijenjati
u idućim iteracijama postupka, dakle onda kad budemo imali više informacija.
Nakon što su napravljene sve procjene, oblikuje se rang lista rizika po kriteriju njihove
značajnosti. Gleda se kombinacija vjerojatnosti pojavljivanja i učinka. Dakle najznačajniji su
rizici s velikom vjerojatnošću koji imaju katastrofalan ili ozbiljan učinak. Daljnje faze
postupka provode se samo za 10-ak rizika s vrha rang liste.
U fazi planiranja rizika razmatra se svaki od značajnih rizika i razvijaju se planovi za

upravljanje tim rizicima. Odabir pojedinog plana opet ovisi o prosudbi i iskustvu menadžera.
Planovi najčešće slijede jednu od tri strategije.
 Izbjegavanje. Nastojimo smanjiti vjerojatnost pojavljivanja rizika.
 Minimizacija. Nastojimo smanjiti učinak rizika.
 Priprema. Nastojimo pripremiti sve što je potrebno za djelovanje u trenutku pojave rizika.
Na slici 1.14 upisani su planovi za naša tri primjera rizika, svaki od njih koristi jednu od
navedene tri strategije.
Faza nadziranja rizika sastoji se od provjere jesu li sve pretpostavke o projektu, produktu i
poslovnom okruženju i dalje iste ili su se promijenile. Povremeno treba ispitati za svaki od
rizika da li je on postao više ili manje vjerojatan te da li se promijenila ozbiljnost njegovog
učinka. Ako je došlo do promjena, pokreće se nova iteracija.

2. Utvrđivanje zahtjeva
U ovom poglavlju govorimo o prvoj osnovnoj aktivnosti u softverskom procesu, a to je
utvrđivanje zahtjeva (specifikacija). Najprije ćemo reći nešto općenito o toj aktivnosti te o
zahtjevima i načinima kako da se oni dokumentiraju. Zatim ćemo detaljnije govoriti o
metodama otkrivanja zahtjeva. Na kraju ćemo obraditi modeliranje uz pomoć grafičkog jezika
UML – ono predstavlja sastavni dio analize zahtjeva makar se također koristi i u daljnjim
fazama razvoja softvera.
2.1. Općenito o utvrđivanju zahtjeva
Utvrđivanje zahtjeva (specifikacija) je aktivnost unutar softverskog procesa gdje se otkrivaju i

analiziraju zahtjevi na budući sustav. Rezultat je dokument o zahtjevima, koji opisuje što
sustav treba raditi, po mogućnosti bez prejudiciranja kako da se to postigne. Utvrđivanjem
zahtjeva bavi se tim sastavljen od razvijača softvera i budućih korisnika. U sljedećim
odjeljcima opisujemo vrste zahtjeva, postupak njihovog utvrđivanja te načine njihovog
zapisivanja i organiziranja.
2.1.1. Funkcionalni i nefunkcionalni zahtjevi
Zahtjeve dijelimo na dvije vrste:

 Funkcionalni zahtjevi. Opisuju funkcije sustava, dakle usluge koje bi on trebao obavljati,
izlaze koje on daje za zadane ulaze te njegovo ponašanje u pojedinim situacijama.
 Nefunkcionalni zahtjevi. Izražavaju ograničenja na funkcije sustava, na primjer traženo
vrijeme odziva, potrebnu razinu pouzdanosti, dozvoljeno zauzeće memorije, obavezu
korištenja određenog programskog jezika, poštivanje određenih standarda ili propisa.
U stvarnosti, razlika između ovih dviju vrsta nije sasvim precizno određena. Na primjer,
sigurnosni zahtjev da je pristup sustavu dozvoljen samo ovlaštenim korisnicima u prvi čas
djeluje kao nefunkcionalni. No njegovom razradom dolazimo do zahtjeva koji su sasvim
funkcionalni, na primjer uključivanje procedure za provjeru identiteta korisnika. Ovo ujedno
pokazuje da zahtjevi nisu nezavisni, to jest jedan od njih često stvara ili ograničava druge.
Dok se za funkcionalni zahtjev obično mogu locirati komponente sustava koje ga

implementiraju, znatno je teže locirati komponente odgovorne za nefunkcionalni zahtjev jer je
njegova implementacija obično rasprostranjena kroz cijeli sustav. Neispunjavanje
funkcionalnog zahtjeva korisnici obično mogu neutralizirati tako da „zaobiđu“ neke od
funkcija sustava. S druge strane, neispunjavanje nefunkcionalnih zahtjeva stvara znatno veće
teškoće jer se ono ne može zaobići. Na primjer, ako sustav za upravljanje avionom ne
zadovoljava zahtjeve pouzdanosti, on ne smije biti prihvaćen za uporabu bez obzira što većinu
stvari radi dobro. U tom smislu, nefunkcionalni zahtjevi su u većoj mjeri „kritični“ od
funkcionalnih.
Slika 2.1 sadrži nekoliko primjera funkcionalnih zahtjeva vezanih uz zamišljeni središnji
bolnički informacijski sustav. Vidimo da zahtjevi mogu biti oblikovani na različitim razinama

Robert Manger
detaljnosti. Često su i neprecizni, što u kasnijim fazama razvoja softvera može stvoriti
nesporazume između korisnika i softverskih inženjera. Na primjer, za prvi zahtjev nije jasno
mora li se implementirati traženje zadanog pacijenta u svim listama, ili je dovoljno prikazati
listu za zadanu bolnicu.
1. Korisnik treba moći pretraživati liste čekanja za sve bolnice.

2. Sustav treba svaki dan za svaku bolnicu generirati listu pacijenata koji bi
tog dana trebali doći na pregled.
3. Svaki zaposlenik koji koristi sustav treba biti jednoznačno određen svojim
8-znamenkastim identifikacijskim brojem.
Slika 2.1: primjeri funkcionalnih zahtjeva.
Zahtjev na produkt. Sustav treba biti dostupan svim bolnicama tijekom radnog
vremena ponedjeljak-petak 8.30-17.30 h. Zastoji u radu sustava unutar
radnog vremena ne smiju prijeći 5 sekundi dnevno.
Organizacijski zahtjev. Korisnici sustava trebaju dokazati svoj identitet

provlačenjem posebne magnetske kartice koju izdaje Minstarstvo zdravlja.
Vanjski zahtjev. Sustav mora poštovati Zakon o zaštiti osobnih podataka te ne

smije dopustiti da podaci o bolestima pojedinog pacijenta budu vidljivi na
javnim web stranicama.
Slika 2.2: primjeri nefunkcionalnih zahtjeva.
Polazna verzija. Sustav treba medicinskom osoblju biti jednostavan za

korištenje te treba biti organiziran tako da minimizira ljudske greške.
Preformulirana verzija. Medicinsko osoblje treba biti u stanju koristiti sve

funkcije sustava nakon četiri sata treninga. Broj grešaka koje rade iskusni
korisnici ne smije biti veći od dvije na sat.
Slika 2.3: primjer preformulacije nefunkcionalnog zahtjeva u svrhu provjerljivosti.
Slika 2.2 prikazuje tri primjera nefunkcionalnih zahtjeva. Oni su opet vezani uz središnji
bolnički informacijski sustav. Primjeri usput pokazuju da se nefunkcionalni zahtjevi općenito
dijele na tri velike skupine.
 Zahtjevi na produkt. Određuju ili ograničavaju ponašanje softvera. Tu spadaju zahtjevi na
brzinu rada, utrošak memorije, pouzdanost, sigurnost, uporabljivost.
 Organizacijski zahtjevi. Slijede iz poslovnih pravila u organizacijama koje sudjeluju u
razvoju softvera. Na primjer, tu spada zahtjev da se mora koristiti određeni programski
jezik ili određena baza podataka.

 Vanjski zahtjevi. Posljedica su faktora koji se nalaze izvan samog produkta i njegovog
razvojnog procesa. Na primjer, kod bankarskog softvera to je zakonska regulativa koja
određuje način poslovanja banke u nekoj zemlji. Ili to može biti zakon o zaštiti osobnih
podataka odnosno autorskih prava.
Za razliku od funkcionalnih zahtjeva, koji se u slučaju precizne formulacije lako mogu
testirati, nefunkcionalni zahtjevi često znaju biti takvi da ih je teško provjeriti. Slika 2.3
prikazuje najprije tipičan način kako korisnik bolničkog sustava opisuje uporabljivost tog
sustava. Zatim se vidi preformulacija istog zahtjeva u svrhu njegove provjerljivosti.
2.1.2. Postupak utvrđivanja zahtjeva
Aktivnost utvrđivanja zahtjeva detaljnije se može podijeliti u sljedeće podaktivnosti.

 Studija izvodljivosti. Procjenjuje se da li se uočene potrebe korisnika mogu zadovoljiti uz
pomoć dostupnih hardverskih i softverskih tehnologija, da li bi predloženi sustav bio
isplativ u poslovnom smislu te da li sustav može biti razvijen s raspoloživim budžetom.
 Otkrivanje i analiza zahtjeva. Primjenom odgovarajućih metoda, zahtjevi se najprije
otkrivaju a zatim analiziraju. Analizom otkrivenih zahtjeva stvaraju se modeli sustava. Ti
modeli omogućuju diskusiju s korisnicima, bolje razumijevanje njihovih potreba te
poboljšanu formulaciju zahtjeva.
 Dokumentiranje zahtjeva. Informacije skupljene otkrivanjem i analizom pretvaraju se u
dokumente koji definiraju zahtjeve. Postoje barem dvije razine u opisivanju zahtjeva:
„korisnički zahtjevi“ i „zahtjevi na sustav“.
 Validacija zahtjeva. Na razne načine provjerava se jesu li zahtjevi dobro opisani ili u
njihovoj specifikaciji postoji neka greška.
Odvijanje ovih pod-aktivnosti prikazano je na slici 2.4.
Otkrivanje
Studija i analiza Dokumentiranje Validacija
izvodljivosti zahtjeva zahtjeva zahtjeva
Izvještaj o Korisnički Dokument o

Modeli sustava zahtjevi i zahtjevi
izvodljivosti na sustav zahtjevima
Slika 2.4: podaktivnosti unutar utvrđivanja zahtjeva.
Za otkrivanje zahtjeva koriste se razne metode, na primjer intervjui s korisnicima, zamišljeni

scenariji korištenja, prototipovi, … i tako dalje. Te metode detaljnije ćemo opisati u idućem
potpoglavlju 2.2. Analiza zahtjeva danas se uglavnom provodi modeliranjem predloženog
sustava pomoću grafičkog jezika UML - pritom su za takvu analizu najvažniji takozvani use
case i sequence dijagrami. Modeliranje sustava pomoću UML-a opširnije će biti obrađeno u
potpoglavlju 2.3.

Robert Manger
Dokumentiranje zahtjeva svodi se na to da zahtjeve zapišemo u nekom pogodnom jeziku te da

takve zapise organiziramo u dokumente. Pregled raznih načina zapisivanja zahtjeva te raznih
vrsta dokumenata o njima nalazi se u idućem odjeljku 2.1.3.
Validacija zahtjeva važna je zato da se na vrijeme otkriju eventualne greške u njima. Naime,
greške u zahtjevima najskuplje su greške budući da se one prenose u sve daljnje faze razvoja
softvera. Validacija se svodi na sljedeće provjere.
 Opravdanost. Je li zahtjev kojeg je jedan korisnik postavio zaista potreban? Što drugi
korisnici misle o tome?
 Konzistencija. Jesu li zahtjevi usklađeni jedan s drugim ili su u međusobnom konfliktu?
 Potpunost. Jesu li uključene sve potrebne funkcije i ograničenja?
 Realizam. Mogu li se zahtjevi ostvariti raspoloživom tehnologijom i budžetom?
 Provjerljivost. Je li zahtjev tako formuliran da se njegovo ispunjavanje kasnije može
testirati?
Postupak utvrđivanja zahtjeva nažalost ne ide uvijek glatko. Treba biti spreman na to da bi se
mogli pojaviti sljedeći problemi.
 Ukoliko novi sustav treba promijeniti sadašnji način rada, tada je teško otkriti zahtjeve na
njega budući da s njim još nema iskustava.
 Razni korisnici imaju različite zahtjeve koji mogu biti u konfliktu. Konačni zahtjevi su
nužno kompromis s kojim nitko nije zadovoljan.
 Financijeri sustava i njegovi korisnici obično nisu isti ljudi. Kupac postavlja zahtjeve
motivirane organizacijskim ili budžetskim ograničenjima koji su u konfliktu s korisničkim
zahtjevima.
 Poslovno i tehničko okruženje se mijenja. Time se mijenjaju i zahtjevi. Prije nego što ih
implementiramo, zahtjevi će možda već biti promijenjeni.
Teškoće kod otkrivanja zahtjeva nastoje se riješiti raznim nestandardnim postupcima
otkrivanja zahtjeva kao što je na primjer upotreba prototipova. Konflikti u zahtjevima najlakše
se rješavaju pomoću modela sustava i u diskusiji s korisnicima. Velika promjenjivost zahtjeva
nalaže nam da koristimo fleksibilne metode dokumentiranja i donekle agilni pristup u razvoju
softvera.
2.1.3. Načini zapisivanja i organiziranja zahtjeva
Da bi zahtjeve mogli pretočiti u dokumente, najprije ih moramo na neki način zapisati. Postoji
nekoliko vrsta „jezika“ za zapisivanje zahtjeva.
 Prirodni jezik. Zahtjevi su popisani kao numerirani niz rečenica u prirodnom jeziku
(hrvatskom, engleskom). Svaka rečenica izražava jedan zahtjev.
 Strukturirani prirodni jezik. Zahtjevi su pisani u prirodnom jeziku, ali tako da se ispuni
zadani obrazac. Svako polje u obrascu daje informaciju o jednom aspektu zahtjeva.
 Formalni jezik. Zahtjevi su specificirani uz pomoć posebnog jezika koji liči na programski
jezik ili na matematičku notaciju (funkcije, skupovi, algebarske operacije, …).
 Grafička notacija. Da bi se definirali funkcionalni zahtjevi, koriste se grafički modeli
nadopunjeni tekstualnim bilješkama. Obično je riječ o UML dijagramima.
Rezultati utvrđivanja zahtjeva uključuju se u dokumente koji sadrže zapisane zahtjeve. Tih
dokumenata ima više vrsta, svaki od njih koristi neki od spomenutih jezika, a međusobno se
razlikuju po svom sadržaju i detaljnosti. Uvodimo sljedeće nazive za pojedine vrste
dokumenata.
 Korisnički zahtjevi. To je manje precizan tekst u prirodnom jeziku, popraćen dijagramima

i tablicama, opisuje funkcije sustava i ograničenja pod kojima sustav radi. Prilagođen je
krajnjim korisnicima.
 Zahtjevi na sustav. Riječ je o detaljnom i preciznom opisu funkcija sustava i ograničenja.
Može služiti kao temelj ugovoru između naručitelja i razvijača softvera. Služi softverskim
inženjerima kao polazište za oblikovanje. Pisan je u donekle strukturiranom prirodnom
jeziku.
 Modeli sustava. Riječ je o pretežno grafičkoj notaciji. To su dijagrami koji opisuju
granice, građu i ponašanje sustava na način koji je precizniji i jezgrovitiji od prirodnog
jezika. Nastaju tijekom analize zahtjeva kao sredstvo komunikacije između razvijača
softvera i budućih korisnika.
 Dokument o zahtjevima. Riječ je o konačnom rezultatu utvrđivanja zahtjeva koji se dobiva
kao unija svih prethodno opisanih dokumenata.
 Specifikacija softverskog dizajna. Ovaj dokument nije obavezan. Predstavlja apstraktni
opis građe softvera i funkcija koje on obavlja, pisan je u formalnom jeziku. Pretpostavlja
određenu arhitekturu sustava te na osnovu nje dalje razrađuje zahtjeve. Stvara se kao most
između aktivnosti utvrđivanja zahtjeva i oblikovanja. Služi razvijačima softvera kao
polazište za daljnje oblikovanje i implementaciju.
Korisnički zahtjev.
1. Sustav treba generirati mjesečni izvještaj koji prikazuje cijenu lijekova
potrošenih u svakoj od bolnica tijekom tog mjeseca.
Zahtjevi na sustav.
1.1 Zadnjeg radnog dana u mjesecu treba biti generiran izvještaj iz kojeg
se vide potrošeni lijekovi, njihova cijena i bolnica koja ih je potrošila.
1.2 Sustav treba automatski generirati taj izvještaj u 17.30h zadnjeg
radnog dana u mjesecu.
1.3 Izvještaj treba biti generiran posebno za svaku bolnicu, a treba
navesti pojedinačna imena lijekova, ukupan broj recepata i propisanih
doza za pojedini lijek te ukupnu cijenu propisanih lijekova.
1.4 Ako je isti lijek dostupan u raznim dozama (na primjer 10 mg, 20 mg),
tada treba postojati posebni ispis za svaku dozu.
1.5 Pristup izvještajima sa cijenama mora biti omogućen samo
ovlaštenim korisnicima koji su navedeni na odgovarajućoj listi.
Slika 2.5: primjer korisničkih zahtjeva i zahtjeva na sustav.
Različite vrste dokumenata potrebne su u prvom redu zato što su one namijenjene različitim
vrstama čitatelja, od korisnika, preko korisnikovih menadžera, do softverskih inženjera. Slika
2.5 ilustrira razliku između korisničkih zahtjeva i zahtjeva na sustav – opet je riječ o
središnjem bolničkom informacijskom sustavu, jedan korisnički zahtjev razrađen je u
odgovarajućih pet zahtjeva na sustav. Slika 2.6 daje jedan mogući prijedlog strukture
sumarnog dokumenta o zahtjevima – prijedlog je zasnovan na preporukama udruge IEEE.

Robert Manger
Poglavlje Opis
Definira se kome je dokument namijenjen. Opisuje se povijest

Predgovor verzija dokumenta, razlog zašto je koja verzija nastala i sažetak
promjena za svaku od verzija.
Obrazlaže se potreba za sustavom. Ukratko se opisuju njegove

funkcije i način kako će on surađivati s drugim sustavima.
Uvod
Također se opisuje kako se sustav uklapa u strateške ili
poslovne ciljeve organizacije koja ga je naručila.
Definiraju se tehnički pojmovi koji se koriste u dokumentu. Ne

Glosarij
pretpostavlja nikakvo posebno predznanje čitatelja.
Opisuju se usluge koje sustav treba pružiti korisnicima, Također

se opisuju i nefunkcionalni zahtjevi. Opis koristi prirodni jezik,
Korisnički zahtjevi dijagrame i drugu notaciju koja je razumljiva korisnicima. Mogu
se spomenuti i standardi za proces razvoja softvera koji se
misle slijediti.
Prikazuje se pretpostavljena arhitektura sustava, vidi se

raspored funkcija po podsustavima ili komponentama.
Arhitektura sustava
Označavaju se komponente koje se misle realizirati ponovnom
upotrebom.
Razrađuju se i detaljno se specificiraju funkcionalni i

Zahtjevi na sustav nefunkcionalni zahtjevi. Po potrebi se definiraju sučelja prema
drugim sustavima.
Uključuju se grafički modeli sustava (na primjer UML dijagrami)

Modeli sustava koji prikazuju granice, građu ili ponašanje sustava, njegove
veze s okolinom, odnose između komponenti ili podsustava.
Opisuju se sadašnje pretpostavke na kojima je sustav zasnovan

te predvidive promjene zbog napretka hardvera, novih potreba
Evolucija sustava korisnika i tako dalje. To se sve daje na znanje razvijačima
softvera tako da oni izbjegnu rješenja koja bi mogla ograničiti
buduću evoluciju sustava.
Daju se detaljne ili specifične informacije vezane uz aplikaciju

Prilozi koja se razvija, na primjer opis predviđenog hardvera ili opis
raspoložive baze podataka.
To je popis pojmova ili sadržaja te brojeva stranica u

dokumentu gdje se ti pojmovi ili sadržaji pojavljuju. Može
Kazalo
postojati više takvih popisa, na primjer posebni za slike ili
tablice.
Slika 2.6: prijedlog strukture dokumenta o zahtjevima.

Idealno bi bilo kad bi svi nabrojani dokumenti opisivali „vanjske“ osobine predloženog
sustava, dakle njegove funkcije i ograničenja, bez prejudiciranja njegove unutrašnje građe. No
taj ideal obično nije moguće postići. Da bi same zahtjeve bolje strukturirali i točnije opisali,
kod iole većih sustava moramo ipak već u specifikaciji predložiti pogodnu arhitekturu
sustava, dakle podjelu na podsustave ili komponente. Ova primjedba pogotovo vrijedi za
zadnju vrstu dokumenata, dakle za specifikaciju softverskog dizajna.
2.2. Otkrivanje zahtjeva
Otkrivanje zahtjeva je proces u kojem se skupljaju informacije o postojećim sustavima i o

traženom novom sustavu. Iz tih informacija filtriraju se zahtjevi vezani uz novi sustav. Postoji
više metoda za otkrivanje zahtjeva i one će biti opisane u sljedećih nekoliko odjeljaka.
Tradicionalna metoda oslanja se na intervjue s korisnicima i na čitanje raspoloživih pisanih
izvora. Druge metode temelje se na scenarijima, slučajevima uporabe, korištenju prototipova
ili na takozvanoj „etnografiji“. Spomenuti načini otkrivanja zahtjeva međusobno su
komplementarni, tako da se najbolji rezultati postižu njihovim kombiniranjem.
2.2.1. Intervjui i ostali tradicionalni postupci
Da bi saznali zahtjeve, softverski inženjeri razgovaraju s korisnicima i postavljaju im pitanja o

njihovom sadašnjem radu i o sustavu koji bi trebalo razviti. Postoje dvije vrste intervjua.
 Zatvoreni intervjui gdje korisnici odgovaraju na unaprijed pripremljena pitanja.
 Otvoreni intervjui gdje nema unaprijed definiranog dnevnog reda ni pitanja.
U stvarnosti, intervjui su obično mješavina obje vrste. Počinje se s pripremljenim pitanjima,
no ovisno o odgovorima razgovor se dalje nastavlja na manje strukturirani način.
Kod planiranja intervjua treba paziti da se razgovara s predstavnicima svih grupa korisnika.
Naime, svaka grupa ima svoje viđenje o tome što bi sustav trebao raditi. Na primjer, u slučaju
središnjeg bolničkog sustava, neke od grupa korisnika navedene su na slici 2.7.
Korisničke grupe za središnji bolnički informacijski sustav:

1. Pacijenti čiji podaci se unose u sustav.
2. Liječnici koji se brinu za pacijente.
3. Medicinske sestre koje obavljaju neke terapije i pomažu liječnicima.
4. Medicinski recepcionari koji unose podatke o pacijentima i određuju
termine pregleda.
5. Osoblje informatičkih centara u bolnicama.
6. Ravnatelji i ostali menadžeri koji vode poslovanje bolnica.
7. Službenici u Ministarstvu zdravlja koji žele dobiti zbirne podatke o
poslovanju bolnica.
8. Dobavljači lijekova i medicinskog materijala koji opskrbljuju bolnice.
Slika 2.7: primjeri korisničkih grupa.

Robert Manger
Intervjui predstavljaju dobar način da se stekne općenit dojam o tome što korisnici rade i kako
bi im novi sustav u tome trebao pomagati. Ipak, kroz intervjue je dosta teško otkriti specifična
stručna znanja i zahtjeve vezane uz dotičnu aplikacijsku domenu (struku). Razlozi za te
teškoće su sljedeći.
 Specijalisti iz aplikacijske domene koriste svoju specifičnu terminologiju koju softverski
inženjeri možda neće dobro razumjeti.
 Neka znanja iz domene toliko su poznata korisnicima da se oni ne sjete da ih trebaju
spomenuti.
Intervjui također nisu dobra metoda otkrivanja znanja o organizaciji u kojoj bi novi sustav
trebao raditi. Naime:
 Često postoje suptilni odnosi snaga između različitih ljudi unutar organizacije.
 Proklamirana organizacijska struktura rijetko se poklapa sa stvarnim putovima donošenja
odluka.
 Zaposlenici strancu često ne žele otkriti stvarnu istinu o svojoj organizaciji nego iznose
službenu istinu.
Zbog svih ovih teškoća, informacije dobivene kroz intervjue moraju se nadopuniti
informacijama iz drugih izvora. Tradicionalno, ti drugi izvori su:
 literatura koja opisuje aplikacijsku domenu i poslovne procese u njoj,
 dokumentacija postojećih softverskih sustava koje novi sustav treba zamijeniti ili s kojima
se mora povezati,
 papirnati obrasci koji trenutno kolaju u poslovnim procesima,
 postojeće baze podataka koje bi se trebale koristiti u novom sustavu,
 zakoni i drugi propisi koje se odnose na aplikacijsku domenu.
2.2.2. Scenariji i slučajevi uporabe
Većini korisnika teško je raspravljati o apstraktnim i sveobuhvatnim specifikacijama. Puno im

je lakše diskutirati o konkretnijim scenarijima koji opisuju neke od mogućih načina rada sa
sustavom. Iz takvih diskusija softverski inženjeri mogu skupiti informacije potrebne za
formuliranje stvarnih zahtjeva na sustav.
Scenarij je neformalni opis zamišljene interakcije korisnika i sustava. Jedan takav opis
pokriva samo mali dio mogućih interakcija. Da bi dobili cjelovitiju sliku o zahtjevima na
sustav, potreban je veći broj scenarija.
Postoje razne vrste scenarija, koje se razlikuju po vrsti informacije i stupnju detaljnosti.
Korisničke priče (user stories) iz metode XP koju smo spominjali u potpoglavlju 1.3 zapravo
predstavljaju jednu relativno jednostavnu vrstu scenarija. Nešto opširniji i bolje strukturirani
primjer vezan uz bolnički informacijski sustav prikazan je na slici 2.8. Iz tog primjera vidimo
da dobro napisani scenarij treba sadržavati sljedeće informacije.
 Polazne pretpostavke koje vrijede na početku interakcije.
 Opis normalnog ili uobičajenog tijeka interakcije.
 Opis mogućih iznimnih situacija koje remete normalni tijek te kako se s njima izlazi na
kraj.
 Popis drugih aktivnosti koje se mogu odvijati u isto vrijeme kad i naša interakcija i mogu
donekle utjecati na nju.
 Stanje sustava nakon što interakcija završi.
SCENARIJ ZA UNOS POVIJESTI BOLESTI U BOLNIČKI INFORMACIJSKI SUSTAV
Polazne pretpostavke
Pacijent se prethodno javio medicinskom recepcionaru. Recepcionar je već stvorio
zapis i unio u njega osobne podatke pacijenta (prezime i ime, datum rođenja, adresu, i
tako dalje). Medicinska sestra je prijavljena u sustav i sad će u isti zapis upisati povijest
bolesti pacijenta.
Normalni tijek scenarija

Medicinska sestra pretražuje zapise po pacijentovom prezimenu. Ako ima više
pacijenata s istim prezimenom i imenom, koristi datum rođenja da bi identificirala
pacijenta.
Sestra na izborniku izabire opciju za dodavanje povijesti bolesti.
Sestra dalje slijedi niz „prompt-ova“ i unosi informacije o pacijentovim prethodnim
pregledima, zdravstvenim problemima (slobodni tekst), postojećem zdravstvenom
stanju (izbor s izbornika), lijekovima koje trenutno uzima (izbor s izbornika), alergijama
(slobodni tekst).
Što sve može krenuti krivo

Pacijentov zapis ne postoji ili se ne može pronaći. Sestra tada treba stvoriti novi zapis i
unijeti u njega osobne podatke.
Pacijentovo zdravstveno stanje ili lijekovi koje on uzima ne mogu se pronaći na
izborniku. Sestra tada treba izabrati opciju „ostalo“ i upisati slobodni tekst koji opisuje to
zdravstveno stanje ili lijek.
Pacijent ne može ili ne želi dati informacije o svojoj povijesti bolesti. Sestra tada treba
unijeti slobodni tekst koji bilježi pacijentovu nemogućnost ili nespremnost davanja
informacija. Sustav tada treba ispisati standardni obrazac na kojem stoji da će zbog
nedostatka informacija liječenje će možda biti ograničeno ili neadekvatno. Pacijent
mora potpisati taj obrazac.
Druge aktivnosti
Za vrijeme unosa podataka, isti zapis mogu gledati i drugi zaposlenici bolnice, no oni
ne mogu mijenjati sadržaj zapisa.
Završno stanje sustava

Sestra je i dalje prijavljena u sustav. Zapis o pacijentu zajedno s poviješću bolesti
pohranjen je u bazi podataka. U žurnalu sustava postoji bilješka koja sadrži vrijeme
početka i kraja unosa podataka te ime sestre koja je unosila podatke.
Slika 2.8: primjer scenarija.
Slučajevi uporabe (use cases) pojavljuju se u grafičkom jeziku za modeliranje UML. U svom
najjednostavnijem obliku, jedan slučaj uporabe bilježi jednu interakciju između sustava i
njegove okoline – dakle on određuje aktere (ljude, druge sustave) koji su uključeni u tu
interakciju te joj daje ime.

Robert Manger
Skup od više slučajeva uporabe dokumentira se jednim use case dijagramom, gdje su akteri
nacrtani kao čovječuljci a interakcije kao ovali. I čovječuljci i ovali imaju upisana imena.
Svaki slučaj uporabe s use case dijagrama dalje se zasebno opisuje strukturiranim tekstom
nalik na onaj sa slike 2.8 ili takozvanim sequence dijagramom.
Slika 2.9 sadrži primjer use case dijagrama vezan uz bolnički informacijski sustav. Vidimo da
postoje akteri s imenima Medicinski recepcionar, Medicinska sestra, Menadžer i
Liječnik. Oni sudjeluju u slučajevima uporabe s imenima Registracija pacijenta, Unos
osobnih podataka, ... i drugima. Daljnji primjeri use case dijagrama te drugih UML
dijagrama mogu se naći u potpoglavlju 2.3.
Registracija pacijenta
Unos osobnih podataka

Generiranje statistike
Menadžer
Medicinski recepcionar
Pregled zapisa
Generiranje izvještaja
Medicinska sestra
Uređivanje zapisa
Liječnik
Određivanje termina pregleda
Slika 2.9: primjer use case dijagrama.
Ne postoji neka jasna razlika između scenarija i slučajeva uporabe. Zapravo je riječ o sličnim
tvorevinama koje su neovisno uveli razni autori. Po mišljenju nekih autora, svaki slučaj
uporabe s use case dijagrama zapravo je jedan scenarij. Drugi pak misle da jedan slučaj
uporabe obuhvaća više scenarija budući da može uključivati više mogućih tokova kontrole.
Scenariji i slučajevi uporabe predstavljaju efikasnu tehniku otkrivanja zahtjeva koji se tiču
neposredne interakcije korisnika sa sustavom. No tom tehnikom ne mogu se otkriti specifični
zahtjevi vezani uz aplikacijsku domenu, niti se mogu obuhvatiti nefunkcionalni zahtjevi.

2.2.3. Upotreba prototipova
Korisnici budućeg sustava često ne uspijevaju jasno izraziti svoje zahtjeve, budući da ne
mogu predvidjeti kako će taj sustav utjecati na njihove radne navike, u kakvoj će interakciji
biti s drugim sustavima te u kojoj mjeri on može automatizirati radne procese. Tada se
pribjegava izradi prototipa. Riječ je o jednostavnom i brzo razvijenom programu, koji
oponaša budući sustav, lako se mijenja i nadograđuje te omogućuje isprobavanje raznih ideja,
koncepcija i opcija.
Prototip ustvari podržava čak dvije podaktivnosti unutar aktivnosti utvrđivanja zahtjeva:
 Otkrivanje zahtjeva. Korisnici eksperimentiraju, pa tako otkrivaju svoje potrebe i dobivaju
nove ideje o tome što bi sustav trebao raditi.
 Validacija zahtjeva. Uočavaju se greške i propusti u polaznim zahtjevima, na primjer
nepotpuni ili nekonzistentni zahtjevi.
Osim toga, prototip može donijeti sljedeće dodatne koristi.
 Otkrivaju se nesporazumi između razvijača softvera i korisnika.
 Lakše se identificiraju komplicirane funkcije koje zahtijevaju pozornost.
 Menadžmentu se demonstrira izvedivost i korisnost sustava.
U praksi se pojam prototipiranja često miješa s pojmom istraživačkog programiranja, dakle

razvoja softvera po modelu evolucijskog razvoja. Razlike između ta dva pojma su sljedeće.
 Cilj istraživačkog programiranja je postepeno dotjerivanje „prototipa“ u skladu sa
zahtjevima koji se otkrivaju, sve dok se taj „prototip“ ne pretvori u konačni sustav.
Prioritet kod implementiranja zahtjeva imaju oni koji su najjasniji i korisnicima
najpotrebniji.
 Cilj „pravog“ prototipiranja je otkrivanje i validacija zahtjeva. Prioritet kod
implementiranja imaju baš oni zahtjevi koji su nejasni i koje treba istražiti. Nakon
utvrđivanja zahtjeva prototip se „baca“, a sustav se dalje oblikuje i implementira na
konvencionalan način.
U slučaju „pravog“ prototipiranja, cjelokupni softverski proces izgleda kao na slici 2.10.
Pritom treba biti oprezan u izboru dijelova iz prototipa, budući da su oni često loše
strukturirani, loše dokumentirani, imaju slabe performanse, slabu pouzdanost te ne
zadovoljavaju zahtjeve sigurnosti.
Skiciraj Specificiraj
polazne Razvij prototip Evaluiraj
prototip sustav
zahtjeve
Upotrebljivi
dijelovi
Konačni
Razvij softver Validiraj sustav softverski
sustav
Slika 2.10: softverski proces s uključenim prototipiranjem.

Robert Manger
Da bi prototipiranje imalo smisla, sam prototip se mora stvoriti na brz, jeftin i fleksibilan
način. Za to su nam potrebne odgovarajuće razvojne tehnike, koje možemo ovako klasificirati.
 Razvoj u dinamičnim jezicima visoke razine. Riječ je o programskim jezicima koji su
velikim dijelom interpretirani te zahtijevaju glomaznu run-time okolinu. Programi se pišu
brzo i jednostavno te se lako mijenjaju, makar su njihove performanse obično slabe zbog
interpretiranja i run-time podrške. Primjeri takvih jezika su Smalltalk, Prolog i donekle
Java.
 Programiranje za baze podataka. Svi komercijalni sustavi za upravljanje bazama
podataka opskrbljeni su vlastitim alatima za izradu aplikacija koje obavljaju uobičajene
radnje s podacima: ažuriranje, pretraživanje, izrada izvještaja. Takvi alati nazivaju se
jezici 4. generacije (4GL). Primjeri za 4GL mogu se naći unutar baza Oracle ili DB2.
Izrada aplikacija (ustvari prototipova) pomoću 4GL je brza i jednostavna te ne zahtijeva
puno programiranja. No dobivena aplikacija je prilično spora i rastrošna. Daljnja mana
4GL je da su oni nestandardni i neprenošljivi s jedne baze na drugu.
 Povezivanje gotovih dijelova ili aplikacija. Prototip se slaže od već gotovih dijelova. U tu
svrhu moramo imati na raspolaganju dovoljan broj upotrebljivih gotovih dijelova te okvir
ili mehanizam za povezivanje tih dijelova. Primjeri za ovakvu tehniku su Microsoft Visual
Basic, gdje se prototip se razvija „vizualnim“ programiranjem, a okvir za povezivanje je
prozor u kojeg se interaktivno ubacuju gotove komponente grafičkog sučelja poput
tekstualnih polja, izbornika ili gumba. Daljnji primjeri su skriptni jezici poput Shell, Perl
ili TCL/TK. Okvir za povezivanje je sama skripta: njene naredbe mogu biti komande
kojima se pozivaju gotove aplikacije ili uključuju komponente grafičkog sučelja.
Pokazalo se da je prototipiranje vrlo pogodna metoda za specificiranje korisničkog sučelja.

Naime, zahtjeve na sučelje teško je opisati riječima, pogotovo kad se radi o grafičkom sučelju.
Do pogodnog sučelja dolazi se eksperimentiranjem. Dovoljan je prototip koji implementira
samo sučelje bez odgovarajuće funkcionalnosti – takozvani „čarobnjak iz Oza“. Pogodni alati
za prototipiranje korisničkog sučelja su: jezici 4. generacije, Visual Basic, TCL/TK, alati za
web stranice, i drugi.
2.2.4. Etnografski pristup
U svom standardnom značenju, etnografija je znanost koja proučava i opisuje materijalnu,

društvenu i duhovnu kulturu pojedinih naroda. Da bi proučio neko pleme, etnograf se
uključuje u život tog plemena te bilježi sve ono što vidi i čuje oko sebe: odjeću, običaje,
vjerovanja, plesove, pjesme, ... .
U kontekstu softverskog inženjerstva, etnografija je metoda za otkrivanje zahtjeva, gdje

softverski inženjer preuzima ulogu etnografa, a korisnici ulogu plemena. Dakle, softverski
inženjer boravi na radnim mjestima korisnika te iz dana u dan promatra i bilježi njihove radne
postupke. Na taj način otkrivaju se:
 implicitni zahtjevi vezani uz dotičnu aplikacijsku domenu koje korisnici inače ne
spominju jer ih smatraju očiglednima;
 stvarni načini kako ljudi rade koji se mogu razlikovati od službeno proklamiranih načina;
 suptilni detalji vezani uz socijalni i organizacijski kontekst u kojem bi budući sustav
trebao raditi.
Sve su ovo informacije do kojih je teško doći na primjer intervjuiranjem.
Unatoč dobrim stranama, etnografija ima i svojih slabosti. Na primjer.

 Previše je usmjerena na krajnje korisnike, pa ne može otkriti zahtjeve vezane uz

organizaciju kao cjelinu.
 Previše je zaokupljena sadašnjim načinom rada, pa ne može formulirati zahtjeve kojima bi
novi sustav promijenio i poboljšao radne procese.
Fokusirana
etnografija
Početna Utvrđivanje Evaluacija
etnografska nejasnoća u prototipa
analiza zahtjevima
Prototipiranje
sustava
Slika 2.11: otkrivanje zahtjeva kombiniranjem etnografije i prototipiranja.
Zbog svih ovih razloga, etnografija najbolje funkcionira u kombinaciji s drugim pristupima,
dakle kao njihov komplement. Na primjer, etnografija se dobro može povezati s
prototipiranjem, kao što je ilustrirano na slici 2.11. Naime, u skladu sa slikom:
 početna etnografska analiza omogućuje da odmah stvorimo dobar prototip i preskočimo
nekoliko iteracija njegovog profinjavanja;
 taj prototip daje se korisnicima, čime se mijenja njihova radna okolina;
 nova radna okolina postaje predmetom nove etnografske analize.
Cijeli ciklus ponavlja se nekoliko puta.
2.3. Modeliranje sustava
Modeliranje je proces razvoja apstraktnih modela sustava. Obično se svodi na primjenu neke
vrste grafičke notacije, dakle na crtanje dijagrama. U prošlosti su se koristile razne notacije,
no danas je kao standard prihvaćen Unified Modeling Language – UML [8,9].
Modeli se koriste u raznim fazama razvoja softvera. Najprije se pojavljuju unutar utvrđivanja
zahtjeva kao sastavni dio analize zahtjeva. Isti modeli dalje se profinjavaju tijekom
oblikovanja i time se pretvaraju u opis sustava kojeg treba implementirati. Nakon
implementacije, modeli dalje služe kao dokumentacija građe i načina rada sustava.
U idućim odjeljcima najprije ćemo nabrojati razne vrste modela te načine njihove upotrebe.
Zatim ćemo detaljnije govoriti o vrstama modela koji promatraju sustav iz perspektive
konteksta, interakcije, strukture, odnosno ponašanja. Svi primjeri dijagrama bit će nacrtani u
skladu s pravilima UML.
2.3.1. Vrste modela i načini njihove uporabe
Kao prvo, razlikujemo dvije vrste modela ovisno o tome da li oni modeliraju postojeći sustav
ili sustav koji tek treba razviti.

Robert Manger
1. Modeli postojećeg sustava koriste se tijekom utvrđivanja zahtjeva. Oni objašnjavaju što
postojeći sustav radi te omogućuju diskusiju o njegovim prednostima i manama. Kroz tu
diskusiju dolazimo do zahtjeva na novi sustav.
2. Modeli novog sustava koriste se tijekom utvrđivanja zahtjeva da bi se korisnicima lakše
objasnilo što će novi sustav raditi i po čemu će se on razlikovati od postojećeg sustava.
Iste modele softverski inženjeri kasnije koriste da bi diskutirali o različitim varijantama
dizajna te da bi dokumentirali varijantu koja će se implementirati.
Glavno svojstvo modela je da on ističe važne osobine sustava a ispušta detalje. Također, od
važnih osobina on izabire samo neke, a zanemaruje ostale. Da bismo dobili cjelovitu
informaciju, za isti sustav moramo razviti više modela od kojih svaki promatra sustav iz
drukčije perspektive. Najvažnije perspektive su sljedeće.
 Kontekst. Modelira se okolina sustava, dakle utvrđuje se granica koja određuje što je dio
sustava a što se nalazi izvan njega.
 Interakcija. Modelira se interakcija između sustava i njegove okoline, ili interakcija
između komponenti sustava.
 Struktura. Modelira se građa sustava ili građa podataka koje sustav obrađuje.
 Ponašanje. Modeliraju se dinamičke pojave u sustavu te kako on reagira na događaje.
Modele dalje možemo podijeliti po vrsti UML dijagrama koja je upotrjebljena za njihovo
zadavanje. U UML-u postoji trinaest vrsta dijagrama, no najčešće se koristi sljedećih pet.
1. Activity dijagram. Prikazuje aktivnosti u nekom procesu te tok kontrole ili tok podataka u
tom procesu.
2. Use case dijagram. Prikazuje interakcije između sustava i njegove okoline.
3. Sequence dijagram. Detaljnije prikazuje interakcije između aktera izvan sustava i
pojedinih objekata unutar sustava.
4. Class dijagram. Prikazuje klase objekata koji se pojavljuju u sustavu te veze između tih
klasa.
5. State machine dijagram. Prikazuje kako sustav ili objekt reagira na unutrašnje ili vanjske
događaje te prelazi iz stanja u stanje.
Konačno, modele možemo podijeliti po načinu ili svrsi njihove upotrebe. Postoje tri
uobičajena načina.
1. Model služi kao pomagalo koje olakšava diskusiju o postojećem ili budućem sustavu.
2. Model služi kao dokumentacija postojećeg sustava.
3. Model služi kao polazište za automatsku implementaciju sustava – vidi odjeljak 1.2.3.
Svaki od ovih načina uporabe postavlja drukčije zahtjeve u pogledu detaljnosti i rigoroznosti
modeliranja. Očigledno, prvi način dozvoljava neformalne i neprecizne modele, dok modeli
koji se koriste na treći način moraju biti razrađeni do najsitnijih detalja.
2.3.2. Modeliranje konteksta i interakcije
U ranoj fazi utvrđivanja zahtjeva potrebno je odrediti granice novog sustava. U dogovoru s
korisnicima treba odlučiti koja funkcionalnost mora biti uključena u sustav, a što će se
prepustiti njegovoj okolini.
Na primjer, ako razvijamo bolnički informacijski sustav, trebamo odlučiti da li će sustav uz

informacije o bolničkim pregledima, terapijama i lijekovima također pohranjivati osobne

podatke o pacijentima, ili će se oslanjati na registar zdravstvenog osiguranja koji vodi

Ministarstvo zdravlja. Obje mogućnosti imaju svoje prednosti i mane.
 Prednost oslanjanja na drugi sustav je manje posla i izbjegavanje dupliciranja podataka.
 Mana oslanjanja na drugi sustav je sporiji pristup do podataka te ovisnost o ispravnom
funkcioniranju tog drugog sustava.
Nakon što su određene granice sustava, crta se kontekstni model nalik na sliku 2.12. Zapravo
je riječ o UML class dijagramu gdje pravokutnici umjesto klasa predstavljaju cijele sustave –
to je označeno takozvanim stereotipom <<system>>. Prikazane su i veze među sustavima,
one obično znače razmjenu podataka. Na slici 2.12 sustav kojeg razvijamo nalazi se u sredini,
a ostali sustavi čine njegovu okolinu. Na primjer, vidi se da naš sustav komunicira s registrom
zdravstvenog osiguranja iz Ministarstva zdravlja te također sa sustavom za izdavanje
elektroničkih recepata.
<<system>> <<system>>
Informacijski Registar
sustav Zavoda zdravstvenog
za statistiku osiguranja
<<system>>
Bolnički
informacijski
sustav
<<system>> <<system>>
Sustav Sustav
elektroničkih elektroničkih
uputnica recepata
Slika 2.12: primjer kontekstnog modela.
Kontekstni model sa slike 2.12 ne objašnjava točnu prirodu veza između našeg sustava i
njegove okoline. Više informacija o tim vezama dobivamo iz modela interakcije. UML nudi
dva načina modeliranja interakcija.
1. Use case dijagrami. Imenuju takozvane slučajeve uporabe (use cases) dakle interakcije
između aktera izvan sustava i samog sustava.
2. Sequence dijagrami. Detaljnije razrađuju interakcije između aktera izvan sustava i
pojedinih objekata unutar sustava, ili međusobne interakcije između tih objekata.
Use case dijagrame već smo upoznali u odjeljku 2.2.2. Jedan primjer već smo vidjeli na slici
2.9. Drugi, nešto jednostavniji primjer nalazi se na slici 2.13 – tu vidimo da medicinski
recepcionar može pokrenuti transfer podataka iz našeg sustava u vanjski sustav.
Transfer podataka
Medicinski recepcionar Registar zdravstvenog osiguranja
Slika 2.13: drugi primjer use case dijagrama.

Robert Manger
Kao što smo već objašnjavali, use case dijagram sastoji se od imenovanih aktera koji su
nacrtani kao čovječuljci, imenovanih slučajeva uporabe koji su nacrtani kao ovali te spojnica
koje pokazuju sudjelovanje pojedinog aktera u pojedinom slučaju uporabe. Akter je korisnik
ili vanjski sustav koji stupa u interakciju s našim sustavom. Slučaj uporabe je usluga koju naš
sustav daje akteru ili funkcija koju je akter pokrenuo.
Kad god je to moguće, svi slučajevi uporabe crtaju se na istom use case dijagramu. Takav
dijagram osim interakcija također opisuje i kontekst. Naime, svi slučajevi uporabe (ovali)
nalaze se unutar sustava, a akteri (čovječuljci) čine njegovu okolinu. Koji put se to naglašava
tako da se ovali ograde od čovječuljaka okvirom koji predstavlja granicu sustava.
Primijetimo da use case dijagram samo imenuje interakcije, no ne opisuje kako se te

interakcija zaista odvijaju. Da bismo pojedini slučaj uporabe detaljnije opisali, služimo se
strukturiranim tekstom nalik na onaj sa slike 2.8 ili se služimo sequence dijagramom. Slika
2.14 sadrži sequence dijagram koji razrađuje slučaj uporabe Pregled zapisa sa slike 2.9.
P: PacijentInfo D: BolnickaDB A: Autorizacija
Medicinska sestra
Gledaj (PID)
Report (Info, PID, UID)

Autoriziraj (Info, UID)
Autorizacija
Alt Zapis o pacijentu
[Autorizacija OK]
[Autorizacija nije prošla]

Greška (nema ovlaštenja)
Slika 2.14: primjer sequence dijagrama.
Kao što se vidi na slici 2.14, sequence dijagram je organiziran na sljedeći način. U
vodoravnom smjeru nanizani su akteri i objekti iz sustava koji sudjeluju u interakciji. Iz
svakog aktera ili objekta izlazi okomita crta koja označava tijek vremena. Podebljani
pravokutnik na toj crti određuje period aktivnosti dotičnog aktera ili objekta. Vodoravne
strelice označavaju vremenski redoslijed poruka koje akteri ili objekti međusobno
razmjenjuju. Ustvari je riječ o pozivima objektovih operacija (metoda) od kojih svaka ima
svoje ime i parametre. Okvir Alt određuje da će se od dvije uokvirene poruke izvršiti samo
jedna, i to ovisno o ispunjenju odgovarajućeg uvjeta.

U fazi analize zahtjeva sequence dijagrami ne moraju biti do kraja razrađeni. Naime, mnoge
interakcije ne mogu se do kraja opisati jer ovise o odlukama koje će biti donesene tek u
implementaciji. Na primjer, na slici 2.14 nije određeno kako će se doći do podatka UID koji
služi za autorizaciju korisnika.
2.3.3. Modeliranje strukture
Model strukture prikazuje organizaciju ili građu sustava. Model se sastoji od dijelova koji
čine sustav i veza između tih dijelova. Može biti riječ o:
 statičkom modelu koji pokazuje strukturu dizajna sustava, ili
 dinamičkom modelu koji pokazuje organizaciju sustava za vrijeme njegovog rada.
Dinamičko modeliranje više je zastupljeno u kasnijim fazama razvoja softvera. Za sada ćemo
se ograničiti na ono što je važnije za početne faze softverskog procesa, a to je modeliranje
statičke strukture.
Objektno orijentirane metode razvoja softvera zahtijevaju da sustav promatramo kao skup
objekata koji međusobno komuniciraju. Ti objekti pripadaju odgovarajućim klasama. Slijede
definicije tih pojmova.
 Objekt je entitet uz kojeg je vezan skup atributa i skup operacija. Vrijednosti atributa
vezanih uz objekt određuju stanje tog objekta. Operacije vezane uz objekt mijenjaju
vrijednosti njegovih atributa te na taj način djeluju na njegovo stanje.
 Klasa je skup istovrsnih objekata. Definicija klase služi kao obrazac za stvaranje objekata.
Definicija klase sadrži deklaracije svih atributa i operacija vezanih uz objekt iz te klase.
Modeliranje statičke strukture sustava najvećim dijelom se svodi na modeliranje klasa. U fazi
analize zahtjeva, klase obično opisuju nešto što postoji u stvarnom svijetu, na primjer
pacijente, liječnike, recepte, preglede, ... . U kasnijim fazama pojavljuju se i apstraktnije klase
koje su potrebne za implementaciju sustava, na primjer klasa za pristup bazi podataka ili klasa
koja inkapsulira mrežnu komunikaciju.
Modeliranje statičke strukture također obuhvaća definiranje veza između klasa. Makar se veze
definiraju na razini klasa, one se najčešće realiziraju na razini objekata, to jest one kažu da
neki objekti iz tih klasa mogu biti međusobno povezani, „znati“ jedan za drugoga, ili biti u
nekom drugom odnosu. Na primjer, ako jedan objekt sadrži referencu na drugi objekt,
pripadne klase su u vezi.
Statička struktura obično se modelira pomoću UML class dijagrama. Taj dijagram sastoji se
od pravokutnika koji predstavljaju klase i spojnica koje predstavljaju veze. Klase imaju
zadana imena, a veze mogu i ne moraju biti imenovane. Na spojnicama mogu biti upisani
takozvani multipliciteti veza, to jest brojevi koji kažu koliko objekata jedne klase može biti
povezano s odabranim objektom druge klase.
Slika 2.15 sadrži class dijagram za bolnički informacijski sustav. Vidimo da postoje klase
koje odgovaraju pacijentima, pregledima, liječnicima, lijekovima, i tako dalje. Između tih
klasa uspostavljaju se razne veze. Na primjer pacijent se podvrgava pregledu, pacijent je
upućen u bolnicu od liječnika opće prakse, i tako dalje. Oznaka multipliciteta 1 znači „točno
1“, oznaka 1..4 znači „od 1 do 4“, 1..* znači „jedan ili više“, a 0..* znači „nula jedan ili više“..
Tako na primjer jedan liječnik opće prakse može uputiti u bolnicu više pacijenata, no svaki

Robert Manger
pacijent je upućen od točno jednog liječnika opće prakse. Slično, jedan pregled mogu
obavljati najviše 4 bolnička liječnika zajedno.
Liječnik
specijalist
1
Upućen_prema
1..*
0..* 1..* 1..* 1 Liječnik opće
Stanje Pacijent prakse
Dijagnosticirano Upućen_od
1
Podvrgava_se
1..*
1..* 0..*
Pregled Lijek
Propisuje
1..*
Sudjeluje_u
1..4
Bolnički liječnik
Slika 2.15: primjer class dijagrama.
Primijetimo da class dijagrami poput onog sa slike 2.15 izgledaju vrlo slično kao Chenovi
dijagrami koji se koriste za opis konceptualne sheme baze podataka u skladu s modelom
entiteta, veza i atributa. Zaista, class dijagram zapravo poopćuje Chenov dijagram, naime
entitet iz baza podataka može se shvatiti kao jednostavna vrsta klase koja ima atribute ali
nema operacije. Na taj način, class dijagram koji se pojavio relativno nedavno uklopio je u
sebi dobra iskustva znatno starije grafičke notacije iz 70-ih godina 20. stoljeća.
UML class dijagrami mogu se oblikovati uz razne stupnjeve detaljnosti. Kad prikazujemo
veze među klasama, spretno je svaku klasu prikazati na najjednostavniji način, samo imenom.
No za točniji opis pojedine klase moramo dodati informacije o njezinim atributima i
operacijama. Slika 2.16 prikazuje razrađenu verziju jedne od klasa s prethodnog dijagrama.
Pravokutnik koji predstavlja klasu sad je podijeljen u tri dijela: na vrhu je ime klase, u sredini
je popis atributa, a na dnu su popisane operacije.
Definicija klase sa slike 2.16 vjerojatno je dovoljno dobra da posluži za analizu zahtjeva, no
nedovoljna je za stvarnu implementaciju. Naime, atributima nisu zadani tipovi, a operacijama
se ne znaju parametri. U kasnijim fazama razvoja sustava ove definicije morat će se još bolje
razraditi.
U objektno orijentiranim metodama razvoja softvera važnu ulogu ima generalizacija. Riječ je
o posebnoj vezi koja povezuje podklase i nadklase, dakle vezi koja kaže da je svaki objekt
jedne klase ujedno i objekt druge klase. Generalizacija podrazumijeva nasljeđivanje: atributi i
operacije definirani za nadklasu također su implicitno definirani i za podklasu. No podklasa
može imati svoje dodatne atribute i operacije.

Bolnički liječnik
IdentifikacijskiBroj
Prezime
Ime
DatumRođenja
Odjel
Plaća
Status
….
Zaposli ()
Otpusti ( )
Umirovi ()
PromijeniPlaću ()
…..
Slika 2.16: primjer detaljnije razrađene klase.
Običaj je da se na class dijagramu nadklasa crta iznad podklase. Da bi se veza generalizacije

lakše prepoznala, UML uvodi posebnu notaciju u obliku trokutaste strelice. Slika 2.17 sadrži
hijerarhiju klasa o liječnicima. Vidimo da liječnici opće prakse i bolnički liječnici
predstavljaju podklase općenitije klase liječnika. Također, vidimo da ima više podvrsta
bolničkih liječnika.
Slika 2.18 prikazuje nasljeđivanje za tri klase iz hijerarhije predmeta u knjižnici. Atributi i
operacije koji su definirani za klasu Publikacija primjenjivi su i na objekte iz podklase
Knjiga odnosno Časopis. No vidimo da svaka od podklasa ima i svoje specifične atribute.
Liječnik
Liječnik opće
Bolnički liječnik prakse
Liječnik
specijalist Timski liječnik
Liječnik Kvalificirani
pripravnik liječnik
Slika 2.17: primjer generalizaciju i hijerarhiju klasa.

Robert Manger
Publikacija
Kataloški broj
Naslov
Izdavač
Status
Nabavi ()
Katalogiziraj ()
Otpiši ()
Posudi ()
Vrati ()
Knjiga Časopis
Autor Volumen
Izdanje Broj
Godina izdanja ISSN
ISBN
Slika 2.18: primjer za nasljeđivanje atributa i operacija.
Još jedna važna vrsta veza između klasa je agregacija. Ta veza kaže da objekt jedne klase
sadrži objekte druge klase kao svoje sastavne dijelove. Na primjer, objekt iz klase Avion
sadrži sva objekta iz klase Krilo i četiri objekta iz klase Motor.
Nastavni
materijali
1 1 1
1 1..* 1..*
Udžbenik Slajdovi Zadaci za vježbu
Slika 2.19: primjer agregacije.
Da bi se na class dijagramu veza agregacije lakše prepoznala, UML uvodi posebnu oznaku u
obliku romba koji se stavlja na spojnicu uz složeniju klasu. Slika 1.19 prikazuje agregaciju
vezanu uz predmet na fakultetu. Nastavni materijali za učenje sastoje se od udžbenika sa
cjelovitim prikazom gradiva, slajdova koje nastavnik koristi u nastavi te dodatnih zadataka za
vježbu.

2.3.4. Modeliranje ponašanja
Modeli ponašanja opisuju dinamičke promjene u sustavu za vrijeme njegovog rada. Ti modeli
pokazuju što će se desiti kad sustav odgovori na podražaj iz svoje okoline. Postoje dvije vrste
podražaja.
1. Podaci (data). Pojavi se neki podatak koji sustav mora obraditi.
2. Događaj (event). Desi se neki događaj na koji sustav mora reagirati.
Događaj može imati uza sebe vezane neke podatke, no to ne mora uvijek biti slučaj. Bitna
razlika između podatka i događaja je to što sustav sam odlučuje kad će obraditi neki podatak,
dok na događaj mora reagirati odmah tako da prekine ono što je taj čas radio.
Većina sustava je takva da njihovo ponašanje možemo opisati kao vođeno podacima (data
driven) ili kao vođeno događajima (event driven). Evo primjera.
 Tipični poslovni sustav uglavnom je vođen podacima. Sustav za obračunavanje
telefonskih usluga čita datoteku sa zabilježenim pozivima pretplatnika, računa cijenu tih
poziva i ispisuje račun.
 Sustav u realnom vremenu (real time) najčešće je vođen događajima. Sustav za
prospajanje poziva u telefonskoj centrali reagira na događaje kao što su dizanje slušalice,
utipkavanje brojeva i slično.
Zbog toga i modele ponašanja dijelimo na one koji su vođeni podacima te na one koji su
vođeni događajima.
Modeli vođeni podacima (data driven models) prikazuju nizove aktivnosti do kojih dolazi
tijekom obrade ulaznih podataka i stvaranja izlaznih podataka. Pojavili su se još u 70-im
godinama 20. stoljeća u sklopu funkcionalno-orijentiranih metoda razvoja softvera. U svojoj
čuvenoj knjizi [28], autor Tom DeMarco uveo je takozvane dijagrame toka podataka (data
flow diagrams), kao prvi oblik grafičkog modeliranja u softverskom inženjerstvu. Ti
dijagrami svojevremeno su bili vrlo popularni, a prikazivali su funkcije (procese) koji
transformiraju podatke i tokove podataka između tih funkcija.
Današnji UML ne podržava dijagrame toka podataka u njihovom izvornom obliku. No UML
je u verziji 2.0 na traženje stručne zajednice uveo activity dijagrame, koji su slični i mogu se
koristiti kao zamjena. Ustvari, UML activity dijagram je generalizacija dijagrama toka
podataka i još starijeg dijagrama toka kontrole.
Slika 2.20 sadrži activity dijagram koji opisuje postupak ubrizgavanja inzulina pacijentu
dijabetičaru onda kad mu je izmjerena razina šećera u krvi izvan dozvoljenih granica.
Općenito, u activity dijagramu ovali predstavljaju aktivnosti a pravokutnici objekte (dakle
podatke). Strelica predstavlja ili tok podataka ili tok kontrole, ovisno o tome je li na njoj
prisutan objekt ili nije.
Drugi način prikazivanja tijeka obrade podataka je pomoću UML sequence dijagrama, istih
onih koje smo već upoznali u odjeljku 2.3.2. Prije smo vidjeli da sequence dijagram modelira
interakciju. No ako je dijagram takav da poruke na njemu idu samo s lijeva na desno, onda je
riječ o sekvencijalnoj obradi podataka. Dok je activity dijagram isticao aktivnosti (funkcije),
sequence dijagram u većoj mjeri ističe objekte (podatke). Kao primjer takvog korištenja
sequence dijagrama imamo sliku 2.21 gdje se vidi obrada neke narudžbe opreme u poduzeću i
slanje te narudžbe dobavljaču.

Robert Manger
Senzor za Pročitaj Podaci sa Izračunaj Razina

vrijednost razinu šećera u
šećer sa senzora senzora šećera krvi
Izračunaj
potrebnu
količinu
inzulina
Naredbe za Generiraj Potrebna

Inzulinska Upravljaj naredbe za
upravljanje upravljanje količina
pumpa pumpom
pumpom pumpom inzulina
Slika 2.20: primjer activity dijagrama.
: Narudžba : Budžet :BazaNarudžbi
Dobavljač
Službenik
Ispuni ()
Provjeri ()
[Provjera OK]
Ažuriraj (Iznos)
Spremi ( )
Pošalji ( )
Slika 2.21: primjer sequence dijagrama koji prikazuje obradu podataka.
Modeli vođeni događajima (event driven models) prikazuju kako sustav odgovara na vanjske
ili unutarnje događaje. Zasnovani su na pretpostavci da se sustav može naći u konačno mnogo
stanja te da događaji služe kao podražaji koji potiču prijelaz iz jednog stanja u drugo.

Modeliranje ponašanja vođenog događajima u novije vrijeme ostvaruje se pomoću UML state
machine dijagrama. No više-manje ista vrsta dijagrama koristila se i u starijim metodama za
oblikovanje sustava u realnom vremenu u 80-im godinama 20. stoljeća [29]. Sa stanovišta
matematike ili teorijskog računarstva, state machine dijagram nije ništa drugo nego konačni
automat.
State machine dijagram sastoji se od ovala koji predstavljaju stanja sustava (ili objekta) te od
strelica koje predstavljaju prijelaze iz stanja u stanje. Na svakoj strelici označen je podražaj
koji uzrokuje prijelaz. Unutar ovala može biti upisana neka akcija koju sustav izvodi dok se
nalazi u tom stanju. Polazno i završno stanje označeni su ispunjenim krugovima.
Puna snaga
Do: postavi Znamenka

Puna snagu na 600 W Timer
snaga
Pola Postavi vrijeme Rad
snage
Do: učitaj Do: upravljaj
Čekanje znamenku radom pećnice
Exit: postavi
Do: prikazuj vrijeme Vrata
Puna
vrijeme zatvorena Start Cancel
snaga
Timer
Pola snage Osposobljena
Čekanje
Do: postavi Do: prikaži
Vrata Do: prikaži
snagu na 300 W poruku
otvorena vrijeme
"Spremna za
rad" Vrata
otvorena
Vrata
zatvorena
Onesposobljena
Do: prikaži
poruku "Vrata
otvorena"
Slika 2.22: primjer state machine dijagrama.
Na slici 2.22 vidi se primjer state machine dijagrama koji opisuje rad jednostavne mikrovalne
pećnice. Ta pećnica ima sklopku za podešavanje grijanja punom snagom ili s pola snage,
numeričku tipkovnicu za unos vremena pečenja, gumb start/cancel, alfanumerički displej za
ispis poruka te zvono. Normalni redoslijed akcija je da se izabere jačina grijanja, upiše
pomoću tipkovnice vrijeme pečenja te pritisne gumb za start. No zbog sigurnosnih razloga
pećnica neće raditi ako su njena vrata otvorena. Detaljniji opis svih stanja i podražaja nalazi
se na slici 2.23.

Robert Manger
Stanje Opis
Čekanje Pećnica čeka unos podataka. Displej pokazuje vrijeme.
Snaga pećnice je postavljena na 300 W. Displej pokazuje

Pola snage
poruku „Pola snage“.
Snaga pećnice je postavljena na 600 W. Displej pokazuje

Puna snaga
poruku „Puna snaga“.
Vrijeme pečenja je postavljeno prema vrijednosti koju je korisnik

Zadavanje vremena unio. Displej pokazuje unesene znamenke i osvježava se dok
se znamenke unose.
Rad pećnice je prekinut zbog sigurnosnih razloga. Svjetlo
Onesposobljena unutar pećnice je upaljeno. Displej pokazuje poruku „Vrata
otvorena“.
Pećnica je spremna za rad. Svjetlo unutar pećnice je ugašeno.
Osposobljena
Displej pokazuje poruku „Spremna za rad“.
Pećnica radi. Svjetlo unutar pećnice je upaljeno. Displej
odbrojava preostalo vrijeme pečenja. U trenutku završetka
Rad pečenja zvono zvoni 5 sekundi, svjetlo unutar pećnice je i dalje
upaljeno. Za vrijeme dok zvono zvoni displej pokazuje poruku
„Pečenje je završeno“.
Podražaj Opis
Pola snage Korisnik je okrenuo sklopku na položaj „Pola snage“.

Puna snaga Korisnik je okrenuo sklopku na položaj „Puna snaga“.
Timer Korisnik je pritisnuo neku od numeričkih tipki.
Znamenka Korisnik je opet pritisnuo numeričku tipku.
Vrata otvorena Brava na vratima pećnice nije zatvorena.
Vrata zatvorena Brava na vratima pećnice je zatvorena.
Start Korisnik je pritisnuo gumb Start.
Cancel Korisnik je pritisnuo gumb Cancel.
Slika 2.23: opis stanja i podražaja za state machine dijagram s prethodne slike.
Problem sa state machine dijagramima je da broj mogućih stanja jako brzo raste čim sustav
postane iole složeniji. Kod velikih modela zato treba na neki način sakriti detalje. Jedan način
sakrivanja detalja je uvođenje super-stanja, dakle stanja koje na dijagramu više razine
izgledaju kao jedno stanje ali se na posebnom dijagramu niže razine razgrađuju na više stanja.

Rad
Provjera
Status ok Pečenje
Do: provjeri Do: puštaj
stanje grijalicu da radi
Greška na
obrtnoj
platformi
Prošlo je
Greška na vrijeme
emiteru
Alarm Gotovo
Do: ispiši Do: zvoni

poruku o zvono 5
događaju sekundi
Vrata
otvorena Cancel
Onesposobljena Čekanje
Slika 2.24: razrada super-stanja s prethodnog state machine dijagrama.
Kao primjer, promatramo stanje Rad sa slike 2.22. Tu je zapravo riječ o super-stanju koje se
može razraditi na način prikazan na slici 2.24. Dakle Rad se sastoji od četiri manja stanja,
početno od njih je Provjera, a završno je Gotovo koje uključuje i oglašavanje zvona. U
slučaju bilo kakvih problema, operacija se prekida.

Robert Manger

3. Oblikovanje i implementacija
U ovom poglavlju bavimo se osnovnim aktivnostima koje u softverskom procesu obično
slijede nakon utvrđivanja zahtjeva: to su oblikovanje i implementacija. Najprije ćemo reći
nešto općenito o tim aktivnostima i pripadnim podaktivnostima, pristupima i trendovima.
Zatim ćemo detaljnije obraditi pojedine izuzetno važne aspekte oblikovanja, kao što su
oblikovanje arhitekture i objektni pristup oblikovanju. Na kraju ćemo se posvetiti
specifičnostima razvoja danas vrlo raširenih distribuiranih odnosno uklopljenih sustava.
3.1. Općenito o oblikovanju i implementaciji
Nakon što je specifikacija ustanovila što softverski sustav treba raditi, oblikovanje treba
utvrditi kako će sustav raditi. Rezultat oblikovanja je dizajn sustava: precizni opis građe
sustava, dijelova od kojih se on sastoji, sučelja između dijelova, korisničkog sučelja te
eventualno struktura podataka i algoritama koji se koriste. Oblikovanje je iterativni postupak,
to jest do dizajna se dolazi postepenim profinjavanjem i razradom kroz više iteracija.
Nakon oblikovanja slijedi implementacija, to jest svi dijelovi predviđeni dizajnom realiziraju
se uz pomoć pogodnog programskog jezika. Zadnje iteracije oblikovanja obično se preklapaju
s implementacijom. Također, implementacija se donekle preklapa s verifikacijom
(testiranjem), budući da se programeri odmah bave debuggiranjem.
3.1.1. Podaktivnosti unutar oblikovanja
Oblikovanje je kreativna aktivnost koju je teško precizno opisati. Ipak, možemo reći da se
oblikovanje sastoji od podaktivnosti u skladu sa slikom 3.1. Svaka od njih daje svoje izlazne
rezultate.
Utvrđivanje
zahtjeva
Oblikovanje Oblikovanje
Oblikovanje Apstraktno struktura
specificira- Oblikovanje dijelova Oblikovanje
arhitekture nje sučelja sustava podataka algoritama
Specifikacija
Arhitektura Opis dijelova Opis struktura Opis
softverskog Opis sučelja
sustava sustava podataka algoritama
dizajna
Slika 3.1: proces i rezultati oblikovanja.

Robert Manger
Slijedi kratko objašnjenje za svaku od navedenih podaktivnosti.

 U oblikovanju arhitekture uočavaju se i dokumentiraju podsustavi koji čine sustav te veze
među tim podsustavima. Ova podaktivnost je od ključne važnosti budući da bitno
određuje daljnji tijek oblikovanja i način kako će se cijeli posao dalje strukturirati.
Opširniji prikaz nalazi se u potpoglavlju 3.2.
 Unutar apstraktnog specificiranja, za svaki podsustav piše se specifikacija softverskog
dizajna, dakle apstraktni i vrlo precizni opis zahtjeva. Ova podaktivnost predstavlja mjesto
gdje se aktivnost oblikovanja donekle preklapa s utvrđivanjem zahtjeva i već smo je
spominjali u potpoglavlju 2.1. Nije obavezna već se uključuje po potrebi, na primjer onda
kad se služimo formalnim metodama razvoja softvera.
 U sklopu oblikovanja sučelja, za svaki podsustav oblikuje se i dokumentira sučelje prema
drugim podsustavima i prema korisniku. Ova podaktivnost važna je kod većih projekata
jer ona omogućuje da se daljnjim razvojem podsustava paralelno bave nezavisni timovi.
 Oblikovanje dijelova obavlja se tako da se svaki podsustav dalje rastavlja na sastavne
dijelove: opisuje se svaki dio zasebno, a veći dijelovi se dalje rastavljaju na manje. Pritom
se primjenjuje neki od pristupa za dekompoziciju većih dijelova u manje, kao što će biti
opisano u sljedećem odjeljku.
 U oblikovanju struktura podataka ili algoritama detaljno se oblikuju i opisuju složenije
strukture podataka odnosno algoritmi koji se pojavljuju u sustavu. Ova podaktivnost isto
nije obavezna već se uključuje onda kad očekujemo da će strukture podataka ili algoritmi
biti presloženi da bi ih prepustili programerima.
3.1.2. Dekompozicija većih dijelova u manje
Da bi izašli na kraj sa složenošću sustava koji treba oblikovati, softverski inženjeri obilato se
služe principom „podijeli pa vladaj“. Dakle, oblikovanje se u velikoj mjeri svodi na
dekompoziciju većih dijelova u manje te posebno razmatranje svakog od tih manjih dijelova.
Najprije kod oblikovanja arhitekture, cijeli sustav rastavljamo na podsustave. Kasnije kod
oblikovanja dijelova, svaki podsustav dalje rastavljamo na dijelove, pa te dijelove na još
manje dijelove, i tako dalje.
Sama dekompozicija može se obavljati u skladu sa sljedećim pristupima oblikovanju:

 Funkcionalni pristup. Sustav se oblikuje sa stanovišta funkcija (procesa). Znači, dijelovi
su moduli i pojedine funkcije. Budući da se kreće od procesa na najvišoj razini, pa ih se
postepeno razgrađuje u sve manje procese, dobiva se hijerarhijski sustav koji je lako
implementirati u klasičnim programskim jezicima (glavna funkcija, podfunkcija, pod-
podfunkcija i tako dalje). Stanje sustava prikazano je globalnim podacima koji su dostupni
raznim funkcijama. Ovakav pristup danas je već pomalo zastario, no koristio se u
klasičnim funkcionalno-orijentiranim metodama za razvoj softvera.
 Objektni pristup. Sustav se oblikuje kao skup objekata koji međusobno komuniciraju.
Znači, dijelovi su objekti odnosno klase. Građa sustava obično nije hijerarhijska, a može
se promatrati iz perspektive nasljeđivanja, agregacije, odnosno korištenja operacija među
klasama. Sustav se izravno može implementirati u objektno-orijentiranim programskim
jezicima. Nema globalnih podataka, a stanje sustava je zbroj stanja pojedinih objekata.
Ovakav pristup koristi se danas u aktualnim klasičnim no objektno-orijentiranim
metodama za razvoj softvera. Detaljniji opis zajedno sa studijskim primjerom nalazi se u
potpoglavlju 3.2.

Razlika između dva pristupa oblikovanju ilustrirana je slikama 3.2 i 3.3. Te slike prikazuju
dva dizajna za isti sustav koji obrađuje fakture. Prvi dizajn dobiven je funkcionalnim
pristupom, a drugi slijedi iz objektnog pristupa. U skladu s time slika 3.2 građu sustava
prikazuje UML activity dijagramom, a sustav se sastoji od procesa koji su nacrtani kao ovali.
S druge strane, slika 3.3 građu sustava prikazuje UML class dijagramom, a sustav se sastoji
od objekata iz klasa koje su nacrtane kao pravokutnici .
Ustanovi je
Čitaj izdane li faktura Faktura
fakture Izdaj račun Račun
plaćena [plaćena]
Faktura Izdaj
Sve fakture Faktura Sve uplate opomenu Opomena
[neplaćena]
Slika 3.2: primjer sustava oblikovanog funkcionalnim pristupom.
Kupac Račun
idKupca Faktura idRačuna

ime datum
adresa iznos
poček idFakture idKupca
datum
iznos
idKupca
Uplata izdaj ()
šaljiOpomenu ()
idUplate primiUplatu ()
datum šaljiRačun ()
iznos
idKupca
Slika 3.3: primjer sustava oblikovanog objektnim pristupom.
Očito je da konačna građa softvera bitno utječe na njegovu kvalitetu. Postavlja se pitanje:
kako treba oblikovati softver da bi on bio kvalitetan? Kako na tu kvalitetu utječe sam pristup
u oblikovanju, dakle način dekomponiranja? Odgovor ovisi o tome koji od atributa kvalitete
softvera nam je najvažniji.
 Na primjer, ako nam je prvenstveno stalo do mogućnosti održavanja, tada je dobro da se
softver sastoji od velikog broja malih dijelova. Unutar pojedinog dijela treba postojati jaka
„kohezija“ njegovih još manjih dijelova, a veze između osnovnih dijelova trebaju biti
relativno „labave“. Takav dizajn dobiva se primjenom objektnog pristupa.
 S druge strane, ako nam je prvenstveno stalo do efikasnosti (performansi), tada je dobro
da se softver sastoji od malog broja relativno velikih dijelova, tako da se smanji
komuniciranje između tih dijelova. Poželjno je da razne funkcije direktno pristupaju
Robert Manger
podacima, što stvara potrebu za globalnim podacima. Takav dizajn moguće je dobiti
primjenom funkcionalnog pristupa.
U skladu s upravo izloženim zaključujemo da sadašnja popularnost objektnog pristupa zaista
ima svoje opravdanje. Naime kod većine sustava glavno mjerilo kvalitete je baš mogućnost
održavanja, dok efikasnost obično nije od presudne važnosti. S druge strane, vidimo da stariji
funkcionalni pristup isto ima svojih prednosti i može se pokazati opravdanim na primjer kod
uklopljenih sustava i sustava u realnom vremenu.
3.1.3. Modeliranje tijekom oblikovanja
U prethodnom potpoglavlju 2.3 upoznali smo se s modeliranjem. Vidjeli smo da se tijekom

analize zahtjeva stvaraju modeli sustava koji opisuju njegov kontekst, interakcije, strukturu i
ponašanje. No modeliranje ne služi samo za analizu zahtjeva. Isti modeli dalje se profinjavaju
i nadopunjuju tijekom oblikovanja. Na taj način modeli predstavljaju sponu koja povezuje
osnovne aktivnosti unutar softverskog procesa.
Način modeliranja tijekom oblikovanja bitno ovisi o pristupu u samom oblikovanju.

 Kod starijeg funkcionalnog pristupa, glavno polazište bio je model toka podataka stvoren
tijekom analize zahtjeva. Procesi iz tog modela shvaćali su se kao podsustavi ili moduli
koje treba realizirati pomoću funkcija. Daljnjim profinjavanjem tih funkcija dolazilo se do
takozvanog strukturalnog modela sustava koji je pokazivao kako se pojedina funkcija
realizira pozivanjem podređenih funkcija. Strukturalni model crtao se kao dijagram, gdje
su pravokutnici prikazivali funkcije (nadređena iznad podređene), a spojnice su
označavale pozive.
 Kod današnjeg objektnog pristupa, polazište su modeli strukture i ponašanja stvoreni
tijekom analize zahtjeva, na primjer UML class i sequence dijagrami, koji put i state
machine dijagrami. Ti modeli dalje se profinjavaju razradom postojećih klasa ili
dodavanjem novih klasa. Po potrebi dodaju se i neki novi modeli koje nismo susretali u
analizi zahtjeva, na primjer UML component ili timing dijagrami.
Budući da se i analiza zahtjeva i oblikovanje oslanjaju na modeliranje, teško je postaviti jasnu

granicu među njima. To jest, teško je odrediti gdje prestaje analiza a gdje počinje oblikovanje.
To pogotovo vrijedi u slučaju objektnog pristupa, gdje se i u analizi i u oblikovanju koriste
iste vrste UML dijagrama. Ipak postoje neke bitne razlike između modela koji se pojavljuju u
jednoj odnosno drugoj aktivnosti.
 Model na razini analize prikazuje sam problem (poslovni sustav) u terminima dotične
poslovne domene. Razumljiv je korisnicima.
 S druge strane, model na razini oblikovanja prikazuje rješenje problema (softverski
sustav) i služi se informatičkim pojmovima. Namijenjen je softverskim inženjerima.
 Model na razini analize jednostavan je i neformalan. On daje idealiziranu predodžbu o
građi i ponašanju sustava te njegovoj interakciji s okolinom.
 S druge strane, model na razini oblikovanja znatno je kompliciraniji jer sadrži sve
tehničke detalje koji su potrebni za implementaciju tražene funkcionalnosti i
uspostavljanje sučelja prema okolini.
Razlike između modela iz analize odnosno modela iz oblikovanja najbolje se vide kad se
usporedi slika 2.16 iz prethodnog poglavlja sa slikom 3.4 iz ovog poglavlja. U oba slučaja
riječ je o specifikaciji jedne klase. Slika 2.16 primjerena je analizi zahtjeva, naime prikazana
klasa spada u poslovnu domenu i definirana je na neformalan način. S druge strane, slika 3.4

spada u oblikovanje. Naime prikazana klasa služi za implementaciju komunikacije korisnika

putem e-mail-a i ne susreće se u poslovnoj domeni. Njezina definicija dovoljno je detaljna jer
sadrži tipove atributa, signature operacija i oznake „vidljivosti“.
Inbox
-InboxId : int
-VlasnikID : int
-Poruka: String[*]
+dajInboxId() : int
+dajVlasnikId() : int
+dajPoruku(indeks : int) : String
+nađiPoruku(obrazac : String) : int [*]
+brisiPoruku (indeks : int) : void
+posaljiPoruku (posiljateljId : int, primateljId : int, poruka : String) : void
Slika 3.4: primjer modela klase na razini oblikovanja.
3.1.4. Novi trendovi vezani uz implementaciju
Aktivnost implementacije prilično je razumljiva onima koji su se bavili programiranjem.

Dakle implementacija se sastoji od pisanja koda u odabranom programskom jeziku kao što je
C, C++, C# ili Java. Taj programski kod trebao bi realizirati sve funkcije, klase i druge
dijelove koji su predviđeni oblikovanjem. Rad programera danas je olakšan korištenjem
lower-CASE alata poput Microsoft Visual Studio [12], koji razumiju sintaksu programskog
jezika, omogućuju pisanje izvornog koda, kompiliranje, povezivanje s bibliotekama
potprograma te izvršavanje i debuggiranje programa.
Ručno kodiranje velikih sustava predstavlja napor koji se mjeri u velikom broju radnih sati
programera. Neki od novih trendova vezanih uz implementaciju nastoje taj napor smanjiti
tako da se dio programa stvori automatski ili zamijeni već prethodno stvorenim kodom. Evo
nekoliko načina kako se to može postići.
 U skladu s idejom formalnog razvoja, izrađuje se formalna specifikacija softvera. Zatim se
ta formalna specifikacija primjenom odgovarajućih alata automatski pretvara u
programski kod.
 U skladu s idejom grafičkog razvoja, izrađuje se skup preciznih grafičkih modela sustava.
Zatim se ti grafički modeli primjenom odgovarajućih alata automatski pretvaraju u
programski kod.
 U skladu s idejom razvoja usmjerenog na ponovnu upotrebu, sustav se oblikuje tako da se
u što većoj mjeri sastoji od već gotovih dijelova. Ti gotovi dijelovi ne moraju se ponovo
kodirati.
Zajedničko svojstvo svih ovdje navedenih tehnika je da one teret implementacije prebacuju na
ranije faze softverskog procesa, dakle na oblikovanje ili utvrđivanje zahtjeva.
Kao što smo već napominjali, formalni razvoj je već dulje vremena predmet intenzivnog
istraživanja, no za sada je primjenjiv samo u vrlo specifičnim situacijama. Također, mnogo se

Robert Manger
istražuje i ideja grafičkog razvoja: pokazuje se da je na primjer iz UML dijagrama kao što su
class, sequence odnosno state machine dijagrami moguće generirati upotrebljivi programski
kod, no taj kod je obično nedovršen i treba ga ručno doraditi. U ovom trenutku najveće uštede
u kodiranju postižu se primjenom razvoja usmjerenog na ponovnu upotrebu. Postoji više
konkretnih tehnika takvog razvoja i one će detaljnije biti opisane u potpoglavljima 6.1 - 6.3.
Osim spomenutih trendova koji teret implementacije prebacuju na oblikovanje ili

specifikaciju, u najnovije vrijeme pojavom agilnih metoda jačaju i sasvim suprotni trendovi.
Agilne metode poput XP ponovo etabliraju programiranje kao glavnu aktivnost unutar koje se
implicitno obavlja i oblikovanje. Za razliku od grafičkog pristupa gdje se programski kod
nastoji automatski generirati iz dijagrama, u XP se dijagrami automatski izvode iz
programskog koda. Ipak, treba primijetiti da takvi suprotni trendovi za sada nisu dominantni.
Naime, agilne metode imaju svoj krug pobornika, uspješne su kod malih sustava, no nisu se
još dokazale u razvoju velikih sustava.
3.2. Oblikovanje arhitekture
Oblikovanje arhitekture sustava predstavlja početnu fazu oblikovanja. Sustav se dekomponira

na nekoliko podsustava, od kojih svaki obavlja određeni skup zadataka. Okvirno se utvrđuje
način komuniciranja podsustava te način njihove kontrole.
Oblikovanje arhitekture često se preklapa s apstraktnim specificiranjem odnosno s izradom

detaljne specifikacije softverskog dizajna. Idealno, specifikacija ne bi smjela sadržavati
informacije o dizajnu. No u praksi je to gotovo nemoguće postići, osim za vrlo male sustave.
Oblikovanje arhitekture je među ostalim nužno i zato da bi se bolje strukturirala sama
specifikacija.
Oblikovanje arhitekture dobro se uklapa u klasične metode razvoja softvera. No zanimljivo je

napomenuti da potrebu za tom aktivnošću prepoznaju također i agilne metode. Na samom
početku agilnog procesa postavlja se arhitektura sustava, a daljnji razvoj u obliku brzih
iteracija najčešće ne mijenja tu arhitekturu. Refactoring programskog koda koji smo
spominjali u metodi XP zapravo se odnosi na manje dijelove (module) a ne na cijelu
arhitekturu.
U nastavku ćemo najprije reći nešto općenito o podsustavima i odnosima među njima. Zatim
ćemo detaljnije objasniti dvije podaktivnosti unutar oblikovanja arhitekture, a to su
strukturiranje sustava odnosno modeliranje kontrole.
3.2.1. Podsustavi i odnosi među njima
Podsustav definiramo kao relativno samostalnu cjelinu, čije funkcioniranje uglavnom ne ovisi
o uslugama koje pružaju drugi podsustavi. Podsustav je sastavljen od svojih dijelova
(komponente, moduli, objekti, … ). On ima definirano sučelje za komunikaciju s drugim
podsustavima te se podvrgava određenim režimima kontrole.
Da bi oblikovali arhitekturu nekog sustava, nije dovoljno samo definirati njegove podsustave,
već također treba odrediti odnose između tih podsustava. Primijetimo da postoje dvije bitno
različite vrste odnosa podsustava: međusobna komunikacija, odnosno međusobna
kontrola. Zato se u sklopu oblikovanja arhitekture pojavljuju sljedeće dvije podaktivnosti.
 Strukturiranje sustava. Sustav se rastavlja na podsustave. Utvrđuje se komunikacija

između podsustava, dakle razmjena podataka.
 Modeliranje kontrole. Određuje se tok kontrole između podsustava, dakle tko s kime
upravlja.
Svaku od ovih podaktivnosti detaljnije ćemo opisati u zasebnom odjeljku.
3.2.2. Strukturiranje sustava
Rezultat strukturiranja predočuje se kao neformalni blok dijagram, gdje su blokovi pod-
sustavi, a strelice označavaju komunikaciju. Pojedini blok može sadržavati podblokove. Od
UML dijagrama moguće je za tu istu svrhu koristiti class ili package ili component dijagram.
Slika 3.5 sadrži blok dijagram sustava za pakiranje uz pomoć robota. Predmeti stižu po
tekućoj traci, robot ih uzima, prepoznaje, pakira te stavlja na drugu tekuću traku. Slika 3.6
sadrži blok dijagram sustava za automatsko ubrizgavanja inzulina pacijentu dijabetičaru onda
kad mu je izmjerena razina šećera u krvi izvan dozvoljenih granica.
Pod-sustav za
umjetni vid
Pod-sustav za Upravljanje Upravljanje

identificiranje robotskom robotskom
predmeta rukom hvataljkom
Pod-sustav za
odabir načina
pakiranja
Pod-sustav za Upravljanje
pokretnom
pakiranje trakom
Slika 3.5: model strukture sustava za pakiranje pomoću robota.
Sklop s iglom Pumpa Sat
Senzor Kontroler Alarm
Displej 1 Displej 2
Slika 3.6: model strukture sustava za ubrizgavanje inzulina pacijentu.

Robert Manger
Primjeri na prethodnim slikama pokazuju kako se za svaki sustav može razviti specifična
arhitektura. No postoje i uobičajeni modeli strukture koji su se pokazali upotrebljivi za razne
sustave. U nastavku ćemo opisati četiri takva modela.
Model s repozitorijom. Svi zajednički podaci čuvaju se u središnjoj bazi podataka

(repozitoriju), kojem mogu pristupiti svi podsustavi. Komunikacija između podsustava
odvija se tako da jedan podsustav zapiše podatke u bazu, a drugi podsustav pročita te podatke.
Sam repozitorij također treba shvatiti kao jedan (specijalizirani) pod-sustav. Struktura je
vidljiva na slici 3.7.
Pod-sustav 1 Pod-sustav 2
Repozitorij
(baza podataka)
Slika 3.7: model za strukturu sustava s repozitorijom.
Ovo je uobičajena struktura za sustave koji rade s velikim količinama podataka (na primjer:
informacijski sustav banke ili poduzeća, CAD/CAM sustav, CASE alat). Konkretni primjer je
CASE alat Visual Paradigm kojeg koristimo na vježbama, ili informacijski sustav ISVU.
Slika 3.8 prikazuje strukturu zamišljenog lower-CASE alata.
Editori za Generatori
UML koda
Editor za
Javu
Prevoditelj
dizajna Projektni repozitorij
Editor za
Python
Analizator Generator
dizajna izvještaja
Slika 3.8: Lower-CASE alat građen u skladu s modelom repozitorija.

Model s repozitorijom ima sljedeće prednosti.

 Pojednostavnjena je komunikacija jer je izbjegnuto direktno slanje podataka iz podsustava
u podsustav.
 Administriranje podataka je centralizirano pa se podsustavi ne trebaju time baviti.
 Jednostavno se može dodati novi podsustav, on samo mora biti kompatibilan s utvrđenom
logičkom organizacijom podataka.
No model s repozitorijom ima i svoje mane.
 Podsustavi se moraju pokoriti zajedničkoj logičkoj organizaciji podataka, što može loše
utjecati na njihove performanse.
 Različiti podsustavi mogu imati različite zahtjeve u pogledu administriranja podataka, no
model ih prisiljava na zajedničku „politiku“.
 Teško je distribuirati repozitorij na više umreženih strojeva, pa repozitorij postaje usko
grlo.
Model klijent – poslužitelj (client - server). U skladu s njime, sustav se sastoji od sljedećih
dijelova:
 poslužitelji: podsustavi koji nude usluge drugim podsustavima,
 klijenti: podsustavi koji traže usluge ponuđene od poslužitelja,
 mreža: omogućuje komunikaciju klijenata i poslužitelja.
Klijent mora znati imena dostupnih poslužitelja i njihove usluge. Poslužitelj ne mora znati ni
imena ni broj klijenata. Struktura je vidljiva na slici 3.9.
Klijent 1 Klijent 2 Klijent 3
Mreža
Poslužitelj 1 Poslužitelj 2
Slika 3.9: model za strukturu sustava klijent - poslužitelj.
Ovo je uobičajena struktura za mrežno-orijentirane sustave. Dobar primjer je world-wide-

web, gdje su poslužitelji web serveri poput Apache, klijenti su web preglednici poput
Microsoft Internet Explorer ili Mozilla Firefox, a mreža je Internet.
Slika 3.10 prikazuje zamišljenu multimedijsku knjižnicu. U njoj se čuvaju slike u visokoj
rezoluciji, filmovi i zvučni zapisi. Svaka vrsta sadržaja pohranjena je na specijaliziranom
poslužitelju. Postoji i dodatni poslužitelj s katalogom svih dokumenata. Korisnikov klijent u
stanju je komunicirati sa svakom od poslužitelja da bi od njega dobio traženi dokument ili
informaciju u odgovarajućem formatu.

Robert Manger
Klijent 1 Klijent 2 Klijent 3
Širokopojasna mreža
Poslužitelj
Video poslužitelj Audio poslužitelj Poslužitelj slika
kataloga
Filmovi u Digitalne
Digitalizirani
Katalog digitalnom fotografije u
zvučni zapisi
formatu visokoj rezoluciji
Slika 3.10: multimedijska knjižnica građena u skladu s modelom klijent - poslužitelj.
U nastavku nabrajamo prednosti modela klijent – poslužitelj.

 Omogućena je distribucija sustava na mrežu računala.
 Lagano se može dodati novi poslužitelj ili se može poboljšati rad postojećeg.
 Dopušta se da svaki poslužitelj koristi svoju optimiziranu organizaciju podataka.
Dalje nabrajamo mane.
 Svaki poslužitelj mora se sam brinuti za administriranje svojih podataka.
 Svaki klijent mora znati koje usluge se nalaze na kojem poslužitelju.
Slojeviti model (model apstraktnog stroja). Sustav je organiziran kao niz podsustava koji se
zovu slojevi. Svaki sloj definira „apstraktni stroj“ čiji strojni jezik (ustvari skup usluga) služi
za implementaciju idućeg sloja. Struktura je ilustrirana slikom 3.11.
Sloj 3
Sloj 2
Sloj 1
Slika 3.11: slojeviti model za strukturu sustava.
Ovakva struktura pojavljuje se kod sustava gdje želimo ostvariti što veću neovisnost rješenja
o hardverskoj platformi. Primjeri su: aplikacija stvorene u jeziku Java, grafičko sučelje
izgrađeno pomoću biblioteka Motif/X-Toolkit/Xlib, OSI model za mrežne protokole sa 7
slojeva, Internetski model za mrežne protokole sa 4 sloja. Slika 3.12 prikazuje zamišljeni
bibliotečni sustav sastavljen od 5 slojeva; on dozvoljava objedinjeni pristup znanstvenoj
literaturi koja je pohranjena u nekoliko digitaliziranih sveučilišnih knjižnica.

Sučelje preko web preglednika
Upravljanje Upravljanje
Login formularima
i upitima ispisom
Distribuirano Dohvat Naplata

pretraživanje dokumenta usluge
Objedinjeni katalog
Baza Baza Baza Baza

1 2 3 4
Slika 3.12: znanstveni bibliotečni sustav građen u skladu sa slojevitim modelom.
Prednosti slojevitog modela su sljedeće.

 Podržan je inkrementalni razvoj sustava.
 Bilo koji sloj može se promijeniti ukoliko zadrži isto sučelje.
 Ako se promijeni sučelje jednog sloja, pogođeni su samo susjedni slojevi.
 Sustav se lako prenosi na drugu platformu, jer su specifičnosti konkretnog računala ili
operacijskog sustava skrivene u unutrašnjim slojevima.
Mane slojevitog modela su sljedeće.
 Koji put je teško podijeliti sustav u slojeve, jer osnovne usluge donjih slojeva mogu biti
potrebne i znatno višim slojevima.
 Mogu nastupiti problemi s performansama, zbog višestrukog interpretiranja zahtjeva iz
sloja u sloj.
Model cjevovoda i filtra (pipe and filter). Sustav se sastoji od niza podsustava koji se zovu
filtri. Razmjena podataka odvija se u jednom smjeru i oblikuje takozvani cjevovod. Svaki
filtar prima podatke od prethodnog filtra, transformira ih, pa ih tako transformirane šalje
idućem filtru. Na taj način podaci koji ulaze u sustav doživljavaju niz transformacija da bi se
na kraju pretvorili u izlazne rezultate. Struktura je ilustrirana slikom 3.13. Naziv „cjevovod i
filtar“ potječe iz operacijskog sustava UNIX, gdje UNIX naredbe služe kao filtri, a cjevovod
se uspostavlja povezivanjem filtara pomoću pipe operatora „|“.
ulazni transf transf izlazni

Filter 1 Filter 2 Filter 3
podaci podaci podaci podaci
Slika 3.13: model cjevovoda i filtra za strukturu sustava.

Robert Manger
Ovaj model često se koristio u prošlosti za oblikovanje neinteraktivne (paketne, batch) obrade
podataka, na primjer računanje plaća zaposlenicima, ispis računa telefonskim pretplatnicima.
Najčešće se koristio posebni slučaj „ulaz-obrada-izlaz“ koji se sastoji od tri filtra: prvi učitava
podatke, drugi računa s njima, treći ispisuje rezultate. Slika 3.14 prikazuje nešto složeniji
primjer, gdje je model upotrjebljen za oblikovanje arhitekture prevodioca programskog jezika
(compiler-a).
izvorni Leksička Sintaktička Semantička Generiranje Strojni

tekst analiza analiza analiza koda kod
Slika 3.14: prevodilac (compiler) građen u skladu s modelom cjevovoda i filtra.
Prednost modela jest da je jednostavan i razumljiv te da se promjene u načinu obrade

podataka lagano implementiraju dodavanjem novih filtara ili promjenom postojećih. Prednost
je i to što se opisana obrada podataka po potrebi može implementirati kao sekvencijalni
sustav ili kao skup paralelnih procesa. Mana je u činjenici da prebacivanje podataka iz filtra u
filtar koji put zahtijeva suvišne konverzije ili reinterpretacije podataka. Također,
jednosmjerna komunikacija duž cjevovoda ne podržava složenije ili razgranatije vrste obrade
podataka ili interaktivni rad.
3.2.3. Modeliranje kontrole
Postoje dva bitno različita pristupa kako se može ostvariti tok kontrole između podsustava:
 Centralizirana kontrola: jedan podsustav igra ulogu „kontrolora“, dakle on pokreće i
zaustavlja ostale podsustave.
 Kontrola upravljana događajima (event driven): kontrola je distribuirana u tom smislu što
pojedini podsustavi samostalno reagiraju na vanjske događaje. Ti događaji mogu biti
generirani od drugih podsustava ili od okoline sustava.
Pod pojmom „događaj“ ponovo mislimo na signal koji može poprimiti zadani raspon
vrijednosti. To nije obični ulazni podatak, budući da vrijeme njegovog pojavljivanja nije pod
kontrolom procesa koji ga obrađuje.
Postoje opet standardni modeli kontrole koji su se pokazali upotrebljivi u raznim sustavima.
Opisat ćemo četiri takva modela, od kojih prva dva spadaju među centralizirane, a druga dva
među one koji su upravljani događajima. Svaki model kontrole može se kombinirati s bilo
kojim modelom za strukturu sustava.
Model poziva i povratka (call - return). Spada među modele sa centraliziranom kontrolom.
Riječ je o ideji koja je implementirana u klasičnim programskim jezicima. Kontrola kreće s
vrha hijerarhije podsustava (iz glavnog programa) i prosljeđuje se na niže članove hijerarhije
(preko poziva potprograma). Model je prikazan na slici 3.15.
Ovaj model ima smisla samo za sekvencijalne sustave: naime u jednom trenutku samo jedan
podsustav je aktivan. Prednost modela je mogućnost jednostavne analize toka kontrole. Mana
što je teško obraditi iznimne situacije (exceptions) koje remete normalni rad: ako se iznimka

dogodi negdje duboko u hijerarhiji, potrebno je više puta prebacivati kontrolu na više članove
hijerarhije.
Glavni program
Potprogram 1 Potprogram 2 Potprogram 3
Potprogram 1.1 Potprogram 1.2 Potprogram 3.1 Potprogram 3.2
Slika 3.15: model poziva i povratka za kontrolu.
Model menadžera. Jedan podsustav, takozvani menadžer, kontrolira ostale tako što im šalje
signale za početak, kraj, odnosno sinkronizaciju njihovog rada. Svi podsustavi u principu rade
paralelno, makar je to moguće simulirati i u sekvencijalnom sustavu. Menadžer izvršava
beskonačnu petlju u kojoj ispituje varijable stanja da bi ustanovio koje podsustave treba
pokrenuti ili zaustaviti. Model je predočen slikom 3.16.
Menadžer
Slika 3.16: kontrola prema modelu menadžera.
Ovaj model sa centraliziranom kontrolom susrećemo na primjer u multiprocessing

operacijskim sustavima, gdje jezgra operacijskog sustava igra ulogu menadžera time što
pokreće i zaustavlja druge procese.
Model difuzije (broadcast). Spada u modele upravljane događajima. Bilo koji događaj
prosljeđuje se svim podsustavima. Odgovara samo onaj podsustav koji je napravljen da
obrađuje taj događaj. Glavna razlika u odnosu na prethodni model je u tome što upravljanje
nije prepušteno jednom podsustavu, već svaki podsustav samostalno odlučuje hoće li reagirati
na događaj ili neće. Model je ilustriran slikom 3.17.
Ovaj model prisutan je na primjer u grafičkim korisničkim sučeljima, gdje se događaj klika
mišem emitira svim elementima sučelja, a reagira samo onaj element nad kojim se kursor
miša nalazio. Moguća je varijanta sa selektivnim emitiranjem događaja samo onim
podsustavima koji su „pretplaćeni“ na određene vrste događaja.

Robert Manger
Pod-sustav 1 Pod-sustav 2 Pod-sustav 3
(događaj)
Event and message handler
Slika 3.17: kontrola prema modelu difuzije.
Prednosti modela difuzije su sljedeće.

 Lagano se dodaje novi podsustav.
 Bilo koji podsustav lagano može aktivirati bilo koji drugi, bez da zna njegovo ime i
lokaciju (tako da generira odgovarajući događaj).
 Primjenjiv je u slučaju distribuiranih sustava, dakle na mreži računala.
Model difuzije ima sljedeće mane.
 Podsustavi ne znaju da li će i kada neki događaj (koji su sami generirali) biti obrađen.
 Mogući su konflikti ako više podsustava pokuša obraditi isti događaj.
Model upravljan prekidom (interrupt driven) također je upravljan događajima. Svakoj vrsti
vanjskog događaja pridružen je jedan hardverski prekid (interrupt). Svakom prekidu
pridružen je posebni podsustav - takozvani interrupt handler. Kad procesor primi prekid
odgovarajuće vrste, hardverska sklopka prekida trenutni proces i prebacuje kontrolu na
pripadni handler. Taj handler obradi događaj, nakon čega procesor nastavlja onaj proces koji
je bio prekinut. Model se vidi na slici 3.18.
(prekidi)
Interrupt
vector
Handler 1 Handler 2 Handler 3 Handler 4
Slika 3.18: model za kontrolu upravljan prekidom.
Ovaj model koristi se na primjer za komunikaciju računala s periferijskim uređajima. Pisanje

po tipkovnici izaziva prekid, a odgovarajući interrupt handler učitava utipkane znakove.
Model upravljan prekidom ima sljedeću prednost.

 Dobiva se najbrži mogući odgovor na odabrane događaje.
No model ima i sljedeće mane.
 Nepogodan je za testiranje, može dovesti do suptilnih grešaka, na primjer u situaciji kad
se više prekida desi u otprilike isto vrijeme.
 Otežana je nadogradnja ukoliko je broj prekida koje hardver podržava već potrošen. Tada
se više događaja mora pridružiti istom prekidu, a odgovarajući handler tada mora
ispitivati o kojem je događaju zapravo bila riječ.

3.3. Objektni pristup oblikovanju
Nakon oblikovanja arhitekture sustava, dalje je potrebno zasebno oblikovati svaki od

podsustava. U tu svrhu danas se obično koristi objektni pristup. Riječ je o takvom načinu
oblikovanja gdje projektant prvenstveno razmišlja o objektima i pripadnim klasama, a tek
onda o operacijama ili funkcijama. Pristup je postao popularan u 80-im u 90-im godinama 20.
stoljeća, a ispočetka je bio motiviran razvojem grafičkih sučelja.
U ovom potpoglavlju najprije navodimo svojstva softvera koji nastaje objektnim

oblikovanjem. Zatim nabrajamo korake unutar objektnog oblikovanja i ilustriramo te korake
na studijskom primjeru. Na kraju spominjemo obrasce za oblikovanje koji omogućuju
dokumentiranje i ponovnu upotrebu dobrih dizajnerskih rješenja dobivenih objektnim
pristupom.
3.3.1. Svojstva objektno oblikovanog softvera
Konačni rezultat objektnog oblikovanja je objektno-oblikovani softver. On se sastoji od

objekata koji su u međusobnoj interakciji, kao što je ilustrirano slikom 3.19. Svaki objekt
pripada nekoj klasi. Interakcija objekata odvija se na način da jedan objekt (klijent) pokrene
operaciju drugog objekta (poslužitelja). U tom smislu, operacije se mogu tumačiti kao usluge,
a svaki objekt može se pojaviti u ulozi klijenta i u ulozi poslužitelja. Prilikom poziva
operacija, objekti razmjenjuju podatke (parametre i rezultate).
U objektno-oblikovanom softveru ne postoje globalne funkcije koje bi se izvršavale neovisno

o objektima, već je funkcionalnost izražena isključivo u terminima operacija vezanih uz
objekte. Slično, ne postoje globalne varijable, već se stanje promatranog dijela sustava dobiva
kao zbroj stanja pojedinih objekata.
Objekti unutar objektno-oblikovanog softvera u principu se izvršavaju paralelno. To daje

mogućnost da se softver distribuira na više računala, ili da se istovremeni rad objekata
simulira na jednom računalu.
o1:C1 o3:C3 o4:C4
stanje o1 stanje o3 stanje o4
operacije1() operacije3() operacije4()
o2:C2 o6:C1 o5:C5
stanje o2 stanje o6 stanje o5
operacije2() operacije1() operacije5()
Slika 3.19: objekti u međusobnoj interakciji.

Robert Manger
Novi objektno-oblikovani sustavi mogu biti razvijeni uz upotrebu objekata koji su bili
stvoreni za prethodne sustave. To smanjuje cijenu razvoja softvera i vodi ka upotrebi
standardnih objekata. Ipak, pokazuje se da su za ponovnu upotrebu pogodnije veće cjeline od
pojedinih objekata, takozvane komponente – o njima će biti riječi u potpoglavlju 6.2.
Važno svojstvo objektno-oblikovanog softvera je da on omogućuje laganu evoluciju. Naime,

softver se sastoji od objekata, dakle dijelova s jakom unutarnjom kohezijom i labavim vezama
prema van. Evolucija će zahtijevati promjenu unutarnje građe pojedinog objekta ili dodavanje
novih objekata - takvi zahvati nemaju značajnog učinka na ostatak softvera. Ovo svojstvo bit
će ilustrirano na kraju primjera u odjeljku 3.3.3.
3.3.2. Koraci unutar objektnog oblikovanja
Objektno-orijentirane metode za razvoj softvera donekle se razlikuju u detaljima. Ipak, sve se

one slažu da je unutar objektnog oblikovanja potrebno izvršiti barem sljedeće korake.
 Utvrđivanje konteksta (okoline) za promatrani dio softvera te interakcije softvera s
njegovom okolinom.
 Oblikovanje na najvišoj razini, dakle podjela promatranog dijela softvera na još manje
sastavne dijelove.
 Identificiranje svih klasa koje su potrebne za realizaciju predviđenih dijelova.
 Razvoj profinjenih modela strukture i ponašanja za pojedine dijelove ili klase.
 Detaljno specificiranje sučelja svih dijelova ili klasa.
Ti koraci su u priličnoj mjeri isprepleteni, teško ih je obavljati u nekom fiksiranom
redoslijedu, pa se stoga moraju ponavljati u više iteracija.
Kontekst promatranog dijela softvera opisuje se modelima koje smo opisali u odjeljku 2.3.2,
na primjer pomoću UML class ili package ili component dijagrama. Važno je utvrditi granicu
našeg dijela softvera, identificirati druge podsustave ili komponente ili vanjske sustave koje se
nalaze u njegovoj okolini te uočiti veze između našeg dijela i dijelova iz okoline. Sve
interakcije našeg dijela softvera s okolinom modeliraju se UML use case dijagramom, dok za
detaljno specificiranje jedne interakcije može poslužiti UML sequence dijagram ili
strukturirani tekst.
Oblikovanje na najvišoj razini opet se može dokumentirati pomoću UML class ili package ili
component dijagrama. No na tim dijagramima promatrani dio softvera rastavljen je na manje
sastavne dijelove. Također se označavaju veze između manjih dijelova, koje mogu značiti
razmjenu podataka ili tok kontrole.
Kod identifikacije klasa koji put je potrebno klase iz aplikacijske domene koje smo dobili
analizom zahtjeva rastaviti na više jednostavnijih klasa. Također je potrebno dodati nove
klase koje su nužne za implementaciju, na primjer one koje omogućuju komunikaciju preko
mreže, pristup bazi podataka, grafičko korisničko sučelje i tako dalje. Sve skupa može se
prikazati pomoću UML class dijagrama.
Profinjeni modeli strukture i ponašanja dokumentiraju se UML class ili sequence ili state
machine dijagramima. Dovoljno su detaljni da omogućuju implementaciju. UML class
dijagrami precizno razrađuju veze među klasama. Tu može biti riječ o nasljeđivanju,
agregaciji ili o vezi koja kaže da objekti jedne klase pozivaju operacije nad objektima druge
klase.

Sučelje klase sastoji se od sučelja operacija koje će u objektima te klase biti dostupne drugim
objektima. Precizno se definiraju se broj i tipovi parametara za svaku operaciju te tip rezultata
operacije. Sve se to opet može dokumentirati razrađenim UML class dijagramima ili u nekom
programskom jeziku poput Jave ili C++ ili C#. Osim sučelja pojedine klase, mogu se
definirati i općenitija sučelja, na primjer za cijele komponente.
3.3.3. Primjer objektnog oblikovanja
U ovom primjeru bavimo se oblikovanjem softvera za meteorološku stanicu. Ta stanica nalazi

se negdje u prirodi i služi za skupljanje meteoroloških podataka. Postoji veći broj
meteoroloških stanica i one su dio većeg sustava koji također sadrži središnji meteorološki
informacijski podsustav i središnji kontrolni podsustav. Zadaća meteorološkog
informacijskog podsustava je da skuplja i obrađuje podatke iz svih meteoroloških stanica.
Zadaća kontrolnog podsustava je da prati stanje svih meteoroloških stanica te da ih po potrebi
resetira, pali, gasi i rekonfigurira. Komunikacija između meteorološke stanice i
meteorološkog informacijskog podsustava odnosno kontrolnog podsustava odvija se radio
vezom preko satelita.
Unutar jedne meteorološke stanice nalazi se nekoliko instrumenata koji mjere razne
meteorološke veličine poput brzine i smjera vjetra, temperature tla i zraka, tlaka zraka te
količine padalina po četvornom metru u 24 sata. Svaki od tih instrumenata nalazi se pod
kontrolom softvera koji periodički očitava i bilježi izmjerene vrijednosti. Budući da je
propusnost veze sa satelitom relativno uska, softver u meteorološkoj stanici lokalno obavlja
djelomičnu obradu i sažimanje izmjerenih podataka. Zatim se ti sažeti podaci na zahtjev šalju
preko satelita u meteorološki informacijski podsustav.
Meteorološka stanica sasvim je nezavisna i napaja se baterijom koja se puni solarnim

ćelijama. Ipak, zbog raznih utjecaja prirodnih sila, njezin rad može se narušiti. Kontrolni
podsustav preko satelita povremeno provjerava stanje stanice te u slučaju neispravnog rada
nastoji resetirati njene instrumente ili uključiti rezervne instrumente. Također, kontrolni
podsustav može rekonfigurirati softver u stanici, dakle instalirati novu verziju tog softvera.
U nastavku pratimo korake u objektnom oblikovanju softvera za meteorološku stanicu. Prvi

korak zahtijeva da se odredi kontekst (okolina) za taj softver te njegova interakcija s
okolinom. Kontekst je vidljiv iz UML class dijagrama na slici 3.20. Vidimo da je naša
meteorološka stanica zapravo podsustav cijelog sustava. U okolini meteorološke stanice
nalaze se još dva podsustava: informacijski i kontrolni. Četvrti podsustav je satelit koji
omogućuje međusobnu komunikaciju ostalih podsustava. Iz kardinalnosti veza vidimo da
postoji samo jedan informacijski podsustav, jedan kontrolni podsustav i jedan satelit, no
meteoroloških stanica ima mnogo. Interakcija meteorološke stanice s okolinom vidljiva je na
UML use case dijagramu na slici 3.21. Vidimo da se kao akteri pojavljuju dva vanjska
podsustava: informacijski i kontrolni. Informacijski podsustav može na primjer od stanice
zahtijevati da mu pošalje izvještaj sa sažetim vremenskim podacima. Kontrolni podsustav
može na primjer resetirati određeni instrument unutar stanice. Slika 3.22 sadrži detaljnu
specifikaciju jedne interakcije u obliku strukturiranog teksta.
Drugi korak oblikovanja traži da se softver za meteorološku stanicu oblikuje na najvišoj

razini, to jest da se odrede njegove komponente. Rješenje je prikazano UML package

Robert Manger
dijagramom na slici 3.23. Vidimo da se meteorološka stanica sastoji od nekoliko sastavnih

dijelova koji međusobno komuniciraju preko unutrašnje komunikacijske veze, na primjer
sabirnice.
1 Kontrolni 1
pod-sustav
1 1 1..n
Informacijski 1 1..n Meteorološka

pod-sustav stanica
1 1 1..n
Satelit 1
1
Slika 3.20: kontekst za meteorološku stanicu.
Izvještaj o vremenu
Informacijski pod-sustav Izvještaj o stanju
Ponovno pokretanje
Gašenje
Rekonfiguriranje
Kontrolni pod-sustav
Upravljanje na daljinu
Slika 3.21: interakcije meteorološke stanice s okolinom.

Podsustav Meteorološka stanica

Slučaj Izvještaj o vremenu
uporabe
Akteri Informacijski podsustav
Opis Meteorološka stanica šalje informacijskom podsustavu sažete podatke o
vremenu koje je skupila pomoću svojih instrumenata u razdoblju od
prethodnog slanja. Podaci koji se šalju su: maksimumi, minimumi i prosjeci
za temperaturu tla temperaturu zraka, tlak zraka i brzinu vjetra, zatim iznos
padalina po metru kvadratnom te smjerovi vjetra skupljeni u 5-minutnim
intervalima.
Podražaj Informacijski podsustav uspostavlja komunikacijsku vezu s meteorološkom
stanicom preko satelita i zahtijeva od stanice prijenos podataka.
Odgovor Meteorološka stanica šalje sažete podatke informacijskom podsustavu.
Komentari Uobičajeno je da se od stanice traži izvještaj jednom na sat, no ta frekvencija
može se razlikovati od stanice do stanice i možda će biti promijenjena u
budućnosti.
Slika 3.22: tekstualni opis jedne interakcije meteorološke stanice s okolinom.
Upravljanje Upravljanje Upravljanje

greškama konfiguracijom energijom
Unutrašnja komunikacija
Komunikacija Skupljanje
Instrumenti
preko satelita podataka
Slika 3.23: građa meteorološke stanice na najvišoj razini.
U trećem koraku oblikovanja potrebno je definirati klase. Meteorološka stanica zahtijeva

velik broj klasa. Slika 3.24 prikazuje samo neke od njih. Vidimo da neke klase odgovaraju
mjernim instrumentima. Objekt iz klase MeteoroloskiPodaci služi za skupljanje izmjerenih
podataka prije njihovog slanja u informacijski podsustav. Objekt iz klase
MeteoroloskaStanica predstavlja cijelu meteorološku stanicu i implementira sučelje stanice
prema okolini.
Četvrti korak oblikovanja sastoji se od razrade profinjenih modela strukture i ponašanja.

Takvih modela može biti mnogo, no mi ovdje prilažemo samo dva. Slika 2.25 sadrži UML
sequence dijagram koji opisuje realizaciju slučaja uporabe Izvještaj o vremenu, dakle
pokazuje kako meteorološka stanica šalje podatke informacijskom podsustavu. Na dijagramu
se pojavljuju objekti iz klasa s prethodne slike, no također i dva nova objekta: prvi od njih
enkapsulira komunikaciju stanice s vanjskim svijetom preko satelita, a drugi enkapsulira
internu komunikaciju unutar stanice. Slika 3.26 prikazuje UML state machine dijagram za
meteorološku stanicu. Vidimo stanja u kojima se stanica može naći te prijelaze iz stanja u
stanje ovisno o podražajima izvana ili o unutrašnjim događajima.

Robert Manger
MeteoroloskaStanica MeteoroloskiPodaci
Identifikator temperatureZraka
temperatureTla
brzineVjetra
izvjestajVrijeme () smjeroviVjetra
izvjestajStanje () tlakovi
daljinskoUpravljanje (naredbe) padaline
rekonfiguracija (naredbe)
restart (instrumenti) skupi ()
shutdown (instrumenti) obradi ()
TermometarTlo Anemometar Barometar
tt_identifikator an_identifikator b_identifikator

temperatura brzinaVjetra tlak
smjerVjetra visina
ocitaj () ocitaj () ocitaj ()

testiraj () testiraj () testiraj ()
Slika 3.24: neke od klasa za meteorološku stanicu.
:SatKomunikacija : MeteoroloskaStanica :UnutraKomunikacija :MeteoroloskiPodaci
Informacijski pod-sustav
zahtjev (izvjestaj)
potvrda
izvjestajVrijeme ( )
potvrda
zahtjev (obrada )
obradi ( )
salji (izvjestaj)
potvrda
odgovor (izvjestaj)
potvrda
Slika 3.25: slanje podataka iz meteorološke stanice u informacijski podsustav.

Pod daljinskim
upravljanjem
shutdown( ) daljinskoUpravljanje( )
izvjestajStanje( )
Ugašena restart( ) Radi Testira se

slanje
gotovo
rekonfiguracija skupljanje testiranje
rekonfiguracija( ) gotova sat gotovo gotovo
izvjestajVrijeme()
Skuplja
Konfigurira se Šalje podatke
podatke
izvještaj
gotov
Obrađuje
podatke
Slika 3.26: stanja za meteorološku stanicu, prijelazi iz stanja u stanje.
Kao ilustraciju zadnjeg koraka u oblikovanju, prilažemo sliku 3.27 na kojoj su definirana dva
sučelja za meteorološku stanicu. Prvo sučelje tiče se izvještavanja, dakle slanja izmjerenih
podataka i statusa u informacijski podsustav. Drugo sučelje služi za udaljeno upravljanje
stanicom preko satelita. Primijetimo da između sučelja i klasa ne mora postojati odnos jedan-
naprama-jedan. To je posebno naglašeno u programskom jeziku Java gdje se sučelja mogu
definirati neovisno o klasama, a razne klase mogu implementirati isto sučelje. U našem
primjeru operacije iz prvog sučelja izravno se preslikavaju na odgovarajuće operacije iz klase
MeteoroloskaStanica. No četiri operacije iz drugog sučelja realiziraju se različitim
komandnim nizovima znakova koje šaljemo jednoj te istoj operaciji daljinskoUpravljanje()
iz klase MeteoroloskaStanica.
<<interface>> <<interface>>
Izvjestavanje DaljinskoUpravljanje
VremenskiIzvjestaj(MS-Ident): Vizvjestaj startInstrument (instrument): iStatus

StatusniIzvjestaj(MS-Ident): Sizvjestaj stopInstrument (instrument): iStatus
skupiPodatke(instrument): iStatus
unesiPodatke(instrument): string
Slika 3.27: sučelja za meteorološku stanicu.

Robert Manger
MeteoroloskaStanica PodaciOZagadjenju
Identifikator podaciNO
podaciSmog
izvjestajVrijeme () podaciBenzen
izvjestajZagadjenje ()
izvjestajStanje () skupi ()
daljinskoUpravljanje (naredbe) obradi ()
rekonfiguracija (naredbe)
restart (instrumenti)
shutdown (instrumenti)
MjeracNO MjeracSmoga MjeracBenzena
no_identifikator s_identifikator bz_identifikator

vrijednostNO vrijednostSmog vrijednostBenzen
ocitaj () ocitaj () ocitaj ()

testiraj () testiraj () testiraj ()
Slika 3.28: nove klase za praćenje zagađenja zraka.
Da bi ilustrirali kako objektno-oblikovani softver lagano može evoluirati, pretpostavimo da se

naknadno pojavio zahtjev da meteorološka stanica mora također mjeriti i zagađenost zraka.
To zahtijeva sljedeće izmjene u dizajnu.
 Dodaje se klasa PodaciOZagadjenju, na istoj razini kao MeteoroloskiPodaci, koja
enkapsulira sažete podatke o zagađenosti.
 U klasu MeteoroloskaStanica dodaje se operacija IzvjestajZagadjenje(), kojom se
podaci o zagađenosti šalju u informacijski podsustav.
 Dodaju se klase MjeracNO, MjeracSmoga i MjeracBenzena koje odgovaraju fizičkim
instrumentima za mjerenje razine dušičnog oksida, smoga i benzena.
Sve ove promjene prikazane su na slici 3.28. Dakle vidi se izmijenjena verzija klase
MeteoroloskaStanica i četiri nove klase. Ove promjene nemaju nikakav učinak na
funkcioniranje ostalih dijelova stanice.
3.3.4. Obrasci za oblikovanje
U oblikovanju softvera često se dešava da se u različitim kontekstima pojavljuju otprilike isti

dizajnerski problemi. Takve probleme ne bi trebalo iznova rješavati, već bi za njih trebalo
primijeniti već poznata provjerena rješenja. Da bi se provjerena rješenja mogla ponovo
upotrebljavati, ona moraju biti dokumentirana. Unutar objektnog pristupa oblikovanju razvio
se posebni vid takvog dokumentiranja koji se zove obrasci za oblikovanje (design patterns).

Jedan obrazac za oblikovanje sastoji se od opisa dizajnerskog problema koji se često

pojavljuje te od opisa rješenja koje je dovoljno općenito da se može koristiti u raznim
okolnostima. Obrazac nije detaljna specifikacija rješenja, prije bi ga se moglo opisati kao
akumuliranu mudrost i iskustvo o tome kako da se neki česti problem riješi na provjereni
način.
Temelji obrazaca za oblikovanje bili su postavljeni u knjizi [30] autora Gamme i suradnika.
Ta knjiga definira 30-ak najpoznatijih obrazaca. Drugi autori dalje su definirali dodatne
obrasce, tako da ih se do danas skupilo više stotina. Obrasci su izvršili jak utjecaj na objektno
oblikovanje softvera. Osim što daju provjerena rješenja za česte probleme, oni postaju i neka
vrsta rječnika za razgovor o dizajnu. Jedan inženjer može drugom inženjeru objasniti svoj
dizajn tako da navede obrasce koje je koristio.
Prema Gammi i suradnicima i njihovoj knjizi [30], u dokumentaciji obrasca za oblikovanje

moraju biti prisutna sljedeća četiri elementa.
 Smisleno ime za obrazac.
 Opis problema, iz kojeg je vidljivo kad se obrazac može primijeniti.
 Opis rješenja, koji objašnjava dijelove predloženog dizajna te odnose između tih dijelova.
Opis rješenja obično se naslanja na dijagram s klasama, nasljeđivanjem, agregacijama ili
nekim drugim vrstama veza.
 Opis posljedica, koji nabraja prednosti i mane primjene predloženog obrasca.
Kao primjer korištenja obrazaca, promatrajmo situaciju sa slike 3.29. Riječ je o programu
gdje se stanje jednog te istog objekta prikazuje na više načina. Dakle vrijednosti atributa A, B,
C, D nacrtane su u obliku kružnog grafikona te također u obliku stupčastog grafikona.
Pojavljuje se sljedeći problem: kako osigurati da bilo koja promjena stanja objekta odmah
uzrokuje simultanu promjenu svih prikaza?
40%
B
25% 40
20% 25
20
15% 15
D
A B C D
C
Subjekt
A: 40
Promatrač 1 B: 25 Promatrač 2
C: 15
D: 20
Slika 3.29: više grafičkih prikaza istih podataka.

Robert Manger
Ime obrasca: Promatrač (Observer)

Kratki opis: Razdvaja se prikaz stanja nekog objekta od samog objekta, omogućuje se
postojanje više prikaza. Kad se stanje objekta promijeni, svi prikazi automatski se ažuriraju u
skladu s novim stanjem.
Opis problema: U mnogim situacijama potrebno je osigurati više simultanih prikaza istih
informacija o stanju, na primjer grafički prikaz i tabelarni prikaz. Svi prikazi trebaju podržavati
interakciju, dakle kad se stanje promijeni, svi prikazi moraju se ažurirati.
Ovaj obrazac može se koristiti u svim situacijama gdje se zahtijeva više od jednog formata
prikaza za stanje i gdje objekt koji čuva informacije o stanju ne mora znati koji sve formati
prikaza se koriste.
Opis rješenja: Ono se zasniva na dvije apstraktne klase Subject i Observer te na konkretnim
klasama ConcreteSubject i ConcreteObserver koje nasljeđuju odgovarajuće apstraktne
klase. Apstraktne klase sadrže općenite operacije koje su primjenjive u svim situacijama.
Stanje koje treba prikazivati sadržano je u objektu iz klase ConcreteSubject. Taj objekt
nasljeđuje operacije od Subject, što mu omogućuje dodavanje ili uklanjanje Observer-a
(svaki od njih odgovara jednom prikazu stanja) te slanje obavijesti da mu se stanje
promijenilo.
Objekt iz klase ConcreteObserver čuva kopiju stanja ConcreteSubject-a i implementira
apstraktnu operaciju Update( ) iz klase Observer. Time je omogućeno da se kopije stanja
usklađuju te da se prikazi obnavljaju kad god je došlo do promjene stanja. UML model
obrasca prikazan je na slici 3.31.
Posljedice: Subjekt zna samo za apstraktnog promatrača i ne zna detalje konkretnih klasa
koje nasljeđuju tog apstraktnog promatrača. Zato među tim objektima postoji minimalna
povezanost. S druge strane, zbog tog nedostatka znanja, ne mogu se izvesti optimizacije
koje bi poboljšale performanse kod iscrtavanja prikaza. Promjene u subjektu mogle bi
izazvati niz povezanih promjena u promatračima.
Slika 3.30: dokumentacija za obrazac Promatrač (Observer).
Subject Observer
Attach (Observer) Update ( )

Detach (Observer) for All o in observers
Notify ( ) o -> Update( )
ConcreteSubject ConcreteObserver
subjectState observerState
observerState =
GetState ( ) return subjectState Update ( ) subject -> GetState( )
Slika 3.31: UML class dijagram koji pobliže objašnjava obrazac Promatrač.

Rješenje ovog problema daje obrazac Promatrač (Observer) iz knjige [30], Dokumentacija tog
obrasca nalazi se na slici 3.30, a njen sastavni dio je i UML class dijagram na slici 3.31.
Vidimo da se predloženi dizajn sastoji od dvije apstraktne klase te od većeg broja konkretnih
klasa koje ih nasljeđuju. Konkretne klase implementiraju apstraktne operacije za ažuriranje
prikaza, uvodeći pritom polimorfizam.
3.4. Oblikovanje distribuiranih sustava
Distribuirani sustav je sustav čiji dijelovi su raspoređeni na više umreženih računala. Svi
današnji veliki sustavi su distribuirani pa je to razlog zašto njima treba posvetiti posebno
potpoglavlje. Nekadašnja mainframe računala s izravno spojenim terminalima zamijenili su
skupovi umreženih poslužiteljskih i osobnih računala. Umjesto privatnih mreža s posebnom
namjenom, za komunikaciju se koriste javne mreže Internet tipa. Razvoj brzih bežičnih mreža
omogućio je i uključivanje ručnih uređaja poput mobitela ili tableta. Na taj način nastali su i
sve više prevladavaju „sveprisutni“ distribuirani sustavi.
U prvom odjeljku ovog potpoglavlja najprije nabrajamo prednosti i mane distribuiranih

sustava. U daljnjim odjeljcima bavimo se ključnim aspektom u oblikovanju distribuiranih
sustava, a to je odabir modela za arhitekturu. Najprije ćemo obraditi generički model klijenata
i poslužitelja - njega smo već spominjali u potpoglavlju 3.2, no sad ćemo ga razraditi na
nekoliko podmodela. Zatim ćemo objasniti još tri modela koji se donekle razlikuju od
klijenata i poslužitelja – to su model gospodar-rob, arhitektura s distribuiranim objektima te
model ravnopravnih partnera.
3.4.1. Prednosti i mane distribuiranih sustava
Poželjna svojstva, a ujedno i prednosti distribuiranih sustava su sljedeće.

 Dijeljenje resursa. Moguće je s jednog računala koristiti hardverske ili softverske resurse
koji pripadaju drugom računalu, na primjer disk, štampač, datoteku, softverski alat.
 Otvorenost. Moguće je međusobno povezati hardver i softver različitih proizvođača. To
zahtijeva poštivanje određenih standarda za komunikaciju.
 Paralelnost. Više procesa može se istovremeno odvijati na različitim računalima te po
potrebi međusobno komunicirati preko mreže. Time je moguće obaviti više poslova u isto
vrijeme, ili jedan posao obaviti u kraćem vremenu.
 Skalabilnost. Performanse sustava mogu se u principu povećati dodavanjem novih
računala i preraspodjelom poslova.
 Robusnost (fault tolerance). U slučaju kvara jednog računala u principu je moguće
poslove preraspodijeliti na preostala računala, tako da sustav i dalje radi uz nešto
oslabljene performanse.
 Transparentnost. Korisniku se sustav može predočiti kao integrirana cjelina, dakle
korisnik ne mora znati ni brinuti o tome gdje se fizički nalaze resursi koje on koristi.
Mane distribuiranih sustava su sljedeće.

 Složenost u odnosu na centralizirane sustave. Teško ih je testirati. Paralelni rad može
dovesti do suptilnih grešaka. Koriste se složeni softveri za mrežnu komunikaciju.
 Smanjena sigurnost. Podaci putuju mrežom pa ih je moguće „prisluškivati“ ili čak
mijenjati. Napadač se može lažno predstaviti kao dio sustava.

Robert Manger
 Otežano upravljanje. Veći broj raznorodnih računala teže je održavati nego jedno
računalo.
 Nepredvidivost kakvoće usluge. Brzina odziva ovisi o ukupnom opterećenju (obično
javne) mreže na koje nemamo utjecaja.
3.4.2. Arhitekture s klijentima i poslužiteljima
Model za strukturu sustava zasnovan na klijentima i poslužiteljima već smo ih spomenuli u

potpoglavlju 3.2. U skladu s tim modelom, sustav se sastoji od klijenata i poslužitelja
povezanih mrežom. Poslužitelji daju usluge, klijenti traže usluge. Dozvoljavamo da
poslužitelj zatraži uslugu od drugog poslužitelja, no ne i od klijenta. Klijenti moraju biti
svjesni postojanja poslužitelja, no ne moraju znati za druge klijente. I klijenti i poslužitelji
shvaćeni su kao procesi (softverske komponente) koji se na različite načine mogu pridružiti
procesorima (hardverskim komponentama). Slika 3.32 prikazuje sustav koji se sastoji od 12
klijenata i 4 poslužitelja. Na slici 3.33 vidi se razmještaj tih procesa na 8 računala, tako da
jedno računalo izvodi više klijentskih odnosno poslužiteljskih procesa.
c2 c3 c4 c12
c11
c1 s1 s4
c10 Poslužiteljski
c5 proces
s2 s3 c9
c6
Klijentski
c8 proces
c7
Slika 3.32: primjer sustava građenog od klijenata i poslužitelja.
c1 s1, s2 c2 c3, c4
cc1 sc2 cc2 cc3
Poslužiteljsko
mreža računalo
cc4 sc1 cc5 cc6

Klijentsko
c5, c6, c7 s3, s4 c8, c9 c10, c11, c12 računalo
Slika 3.33: razmještaj klijenata i poslužitelja na računala.

Arhitektura sustava s klijentima i poslužiteljima treba odražavati logičku strukturu aplikacije.

Jedan način gledanja na aplikaciju je njena podjela na tri sloja (layers), u skladu sa slikom
3.34. Dakle razlikujemo sloj za prezentaciju, obradu odnosno upravljanje podacima.
Prezentacijski sloj bavi se prikazivanjem informacija korisniku te interakcijom aplikacije i
korisnika. Sloj obrade implementira logiku same aplikacije (poslovna pravila ili business
rules). Sloj upravljanja podacima izvršava transakcije nad bazom podataka. Ova tri sloja treba
razlikovati zato što se svaki od njih može staviti na drugo računalo.
Prezentacijski sloj
(presentation layer)
Sloj obrade
(processing layer)
Sloj upravljanja podacima

(data management layer)
Slika 3.34: podjela aplikacije na tri sloja.
Jednostavni razmještaj slojeva na računala zove se dvoredni (two-tier), gdje je aplikacija

raspoređena na jedno poslužiteljsko računalo i mnogo klijentskih računala. Pritom u skladu
sa slikom 3.35 postoje dvije mogućnosti, budući da tri sloja treba smjestiti na dva računala.
Prezentacija Prezentacija + obrada

Poslužitelj Poslužitelj
Obrada,
klijent klijent Upravljanje
upravljanje
podacima
podacima
Slika 3.35: dvoredni razmještaji slojeva aplikacije na računala.
Kod modela mršavog klijenta (thin client) većinu posla obavlja poslužitelj, a klijent se bavi
samo prezentacijom. Primjeri su: aplikacija s web sučeljem (klijent je zapravo web
preglednik), ili stara „baštinjena“ mainframe aplikacija (klijent je emulator tekstualnog
terminala). Kod modela debelog klijenta (fat client) klijent izvršava veći dio aplikacije, a
poslužitelj se bavi isključivo transakcijama nad bazom podataka. Na slici 3.36 imamo primjer
sustava bankomata, gdje se na bankomatu nalazi klijent, a na bančinom mainframe računalu je
poslužitelj.

Robert Manger
ATM
ATM Poslužitelj računa

Tele- Baza
procesing korisničkih
monitor računa
ATM
ATM
Slika 3.36: sustav bankomata s debelim klijentima.
Prednost mršavog klijenta je da klijentsko računalo ne mora biti pravi PC nego može biti i
nešto jednostavnije i jeftinije; mana je da je poslužitelj usko grlo. Prednost debelog klijenta je
bolji raspored tereta i veća autonomija klijenta; mana je složenije administriranje jer se nova
verzija aplikacije mora distribuirati na svaki od klijenata. Hibrid između mršavog i debelog
klijenta predstavljaju aplikacije zasnovane na Java applet-ima koji se s poslužitelja prebacuju
(download) na klijenta.
Složeniji raspored slojeva na računala zove se troredni (three-tier) gdje je svaki sloj na
zasebnom računalu. Ako se na bilo kojem sloju pojavi usko grlo, moguće je povećati broj
računala. Troredni raspored prikazan je na slici 3.37.
Prezentacija Poslužitelj Poslužitelj
klijent Obrada Upravljanje

podacima
Slika 3.37: troredni razmještaj slojeva aplikacije na računala.
Klijent
HTTPS interakcija
Klijent Web poslužitelj Poslužitelj baze pod

Generiranje SQL upit Baza
web stranica, SQL korisničkih
aplikacijski servisi računa
Klijent
Klijent
Slika 3.38: sustav internetskog bankarstva s trorednim rasporedom.

Slika 3.38 prikazuje sustav za internetsko bankarstvo. Korisnici ustvari gledaju web formulare
pomoću običnog web preglednika. Te web formulare dinamički oblikuje web poslužitelj,
služeći se podacima o bankovnim računima kojima upravlja poslužitelj baze podataka. Ako
promet postane prevelik, dodaje se više web poslužitelja.
3.4.3. Druge distribuirane arhitekture
Makar se većina distribuiranih sustava sastoji od klijenata i poslužitelja, postoje i sustavi koji
slijede drukčije modele. U ovom odjeljku opisat ćemo tri takva alternativna modela. Oni
naravno nisu međusobno isključivi, tako da su moguće i njihove razne kombinacije.
Model gospodar – rob (master – slave). Riječ je o jednostavnom modelu gdje se sustav
sastoji od jednog glavnog procesa koji zovemo gospodar i niza pomoćnih procesa koje
zovemo robovi. Gospodar upravlja radom sustava tako da robovima dodjeljuje poslove.
Robovi paralelno obavljaju poslove koje im je dodijelio gospodar.
Model se često koristi u znanstvenom računanju, sa ciljem da se skrati vrijeme izvršavanja

zahtjevnih proračuna. Da bi obavio zadani računski zadatak, gospodar ga najprije dijeli na
više manjih nezavisnih podzadataka koje dodjeljuje robovima. Robovi paralelno rješavaju
svoje podzadatke i svoja rješenja šalju gospodaru. Dobivena rješenja podzadataka gospodar
objedinjuje u konačno rešenje cijelog zadatka. Ideja je ilustrirana slikom 3.39.
Gospodar Rob Pod-zadatak
Rob
Rezultati rješavanja
pod-zadatka
Rob
Slika 3.39: model gospodar – rob za distribuirano računanje.
Na primjer, zamislimo da se računski zadatak sastoji od pronalaženje najmanjeg člana u

nesortiranom nizu od 10 milijuna brojeva. Tada gospodar dijeli niz u 10 manjih nizova od po
1 milijun brojeva. Svaki od 10 robova paralelno pretražuje jedan od podnizova i dojavljuje
gospodaru svoj minimum. Gospodar na kraju uspoređuje 10 dojavljenih vrijednosti i pronalazi
konačni minimum. Postupak očito traje otprilike 10 puta kraće nego kad bi jedan proces
pregledavao cijeli niz.
Osim u znanstvenom računanju, model gospodar – rob također se koristi u sustavima u

realnom vremenu (real-time sustavi) – vidi potpoglavlje 3.5, gdje postoje senzori i aktuatori.
Sustav u realnom vremenu upravlja nekim tehnološkim procesom. Senzor su uređaji koji
skupljaju podatke iz okoline procesa, a aktuatori su uređaji koji djeluju da bi mijenjali tu
okolinu. Gospodar pojedinom robu dodjeljuje posao praćenja jednog ili više senzora ili posao
kontroliranja jednog ili više aktuatora.

Robert Manger
Procesor u
kontrolnoj sobi
Proces za
koordinaciju i
prikaz
situacije
Procesor za
senzore Gospodar
Proces koji Proces za

kontrolira upravljanje
senzore semaforima
Operatorove
Rob Rob
konzole
Slika 3.40: sustav za upravljanje prometom sagrađen po modelu gospodar – rob.
Kao primjer, pogledajmo sliku 3.40 koja prikazuje arhitekturu sustava u realnom vremenu za
upravljanje prometom oblikovanu po modelu gospodar – rob. Gospodar od roba zaduženog za
senzore prima podatke o intenzitetu prometa na pojedinim raskrižjima. Na osnovu tih
podataka, gospodar bira način regulacije prometa. Rob zadužen za aktuatore zapravo pali i
gasi semafore u skladu s načinom regulacije koji je dojavio gospodar.
Arhitektura s distribuiranim objektima. Kod ovog modela za strukturu sustav se promatra

kao skup objekata koji su raspoređeni na raznim računalima i koji međusobno komuniciraju
preko mreže. Dakle građa izgleda otprilike kao na slici 3.19. Dijelovi sustava su objekti od
kojih svaki daje sučelje na skup usluga koje on pruža. Isti objekt može tražiti jednu vrstu
usluge a pružati drugu vrstu usluge. Fizički raspored objekata po računalima je irelevantan za
funkcioniranje sustava.
Objekt 1 Objekt 2 Objekt 3
Usluge 1 Usluge 2 Usluge 3
middleware (softverska sabirnica)
Objekt 4 Objekt 5
Usluge 4 Usluge 5
Slika 3.41: distribuirani objekti i njihova komunikacija preko middleware-a.

Za ovu arhitekturu bitno je da se komunikacija distribuiranih objekata ostvaruje pomoću

posredničkog softvera, takozvanog middleware-a. Kao što hardverska sabirnica omogućuje
komuniciranje različitih PC kartica umetnutih u utore na matičnoj ploči računala, tako
middleware igra ulogu „softverske sabirnice“. Middleware je nužan zato što objekti mogu biti
implementirani u različitim programskim jezicima, zato što mogu raditi na različitim
platformama te zato što njihova stvarna imena i fizičke lokacije ne trebaju biti poznate drugim
objektima. Zahvaljujući middleware-u, komunikacija objekata odvija se na transparentan i
fleksibilan način. Cijela arhitektura prikazana je na slici 3.41.
U dosadašnjoj praksi korištenja arhitekture s distribuiranim objektima nastala su tri važna

standarda za middleware.
 CORBA (Common Object Request Broker Architecture). To je skup standarda koje je
definirao OMG. Konzorcij OMG (Object Management Group) uključuje kompanije Sun,
HP, IBM i druge. Postoje implementacije CORBA-e za UNIX, Linux i Microsoft
Windows.
 .NET Remoting. To je standard razvijen i implementiran od Microsofta, integriran je u
Microsoftovu okolinu za razvoj aplikacija .NET, naslijedio je neka starija rješenja koja su
se zvala OLE , COM odnosno DCOM. Model distribuiranog računanja manje je općenit
od CORBA-inog te je ograničen na komuniciranje .NET aplikacija na Windows
računalima.
 Java RMI (Remote Method Invocation). Alat i standard koji je razvila kompanija SUN
Microsystems početkom 21. stoljeća. Služi kao proširenje programskog jezika Java kojim
se postiže pokretanje udaljenih metoda. Korištenje je ograničeno na programe pisane u
jeziku Java.
Fizički raspored middleware-a po računalima je takav da svako računalo koje ima objekte
također ima i svoju kopiju middleware-a. Dva objekta koja se nalaze na istom računalu
komuniciraju preko lokalne kopije middleware-a, dok se komunikacija objekata na različitim
računalima ostvaruje tako da pripadni middleware-i „razgovaraju“.
Arhitektura s distribuiranim objektima dobra je zato jer ona u najvećoj mjeri može iskoristiti
prednosti distribuiranih sustava. Naime vrijedi sljedeće.
 Fizički raspored objekata irelevantan je sa stanovišta korektnog rada aplikacije, pa se
može podešavati tako da osigura što bolje performanse.
 Sustav je otvoren u smislu da pojedini objekti mogu biti razvijeni u različitim
programskim jezicima za različite platforme.
 Sustav je skalabilan u smislu da je lagano dodati nove objekte ili kopije istog objekta da bi
se otklonila uska grla.
 Sustav se dinamički može rekonfigurirati, tako da objekti u toku rada sele s jednog
računala na drugo, u skladu s promijenjenim zahtjevima.
No arhitektura s distribuiranim objektima ima i sljedeće nedostatke.
 Kompliciranija je od arhitekture s klijentima i poslužiteljima ili arhitekture gospodar-rob.
Zahtijeva instalaciju i održavanje složenog middleware-a na svim računalima gdje se
nalaze objekti.
 Nije podržana nekim općeprihvaćenim standardom. Takav standard trebala je biti
CORBA, no ona se nije uspjela nametnuti u dovoljnoj mjeri. Umjesto CORBA-e, u praksi
se najviše koriste middleware-i kompanija Microsoft i Sun koji su međusobno
nekompatibilni.

Robert Manger
Na slici 3.42 vidi se arhitektura s distribuiranim objektima za data mining sustav. Taj sustav
nastoji otkriti zakonitosti među podacima koji su spremljeni u različitim bazama podataka i
odnose se na prodaju više vrsta roba u više robnih kuća. Na primjer, jedna takva zakonitost
bila bi: „Muški kupac od 30-ak godina koji u petak popodne dolazi kupiti pelene vjerojatno će
kupiti i pivo“.
Na slici 3.42 svaka od baza podataka prikazana je kao distribuirani objekt s read-only
pristupom. Svaki od objekata-integratora bavi se drukčijom vrstom odnosa među podacima:
na primjer jedan integrator proučava varijacije prodaje roba ovisne o godišnjim dobima, a
drugi se zanima za korelacije između različitih tipova roba. Objekt-vizualizator grafički
prikazuje otkrivene zakonitosti, a generator izvještaja daje tekstualne prikaze. Korisnici
pristupaju sustavu preko složenog sučelja koje povezuje grafičke i tekstualne prikaze. Objekti
se povezuju međusobnim pozivanjem operacija uz posredništvo middleware-a. Vidimo da
većina objekata i traži i daje usluge.
Baza podataka 1 Generator

izvještaja
Integrator 1
Baza podataka 2 Vizualizator
Integrator 2
Baza podataka 3 Složeno sučelje
korisnici
Slika 3.42: arhitektura s distribuiranim objektima za data mining sustav.
Model ravnopravnih partnera (peer-to-peer). Sustav građen modelu ravnopravnih partnera

sastoji se od velikog broja istovrsnih procesa, takozvanih partnera (peer). Jedan partner u
pravilu radi na osobnom računalu jednog korisnika, no može po potrebi komunicirati s
drugima preko mreže. Svi partneri obavljaju istu zadaću prema potrebama svojih korisnika.
Koji put partner uspijeva samostalno obaviti svoju zadaću. No obično mu je potrebna pomoć,
i tada on stupa u komunikaciju sa svojim susjedima u mreži. Tijekom te komunikacije,
uključeni partneri privremeno igraju uloge klijenta odnosno poslužitelja. Drugom prilikom
uloge će možda biti drukčije raspoređene.

Arhitektura ravnopravnih partnera ilustrirana je slikom 3.43. Čvorovi na slici predstavljaju

partnere, a spojnice pokazuju tko je kome susjed. Na primjer, možemo zamišljati da je riječ o
sustavu za pohranjivanje znanstvenih radova. Svaki znanstvenik pohranjuje radove na
vlastitom računalu, no svoju zbirku stavlja na raspolaganje i drugima. Kad neki znanstvenik
želi vidjeti neki rad, njegov partner najprije gleda da li ga ima na lokalnom disku, ako ga
nema tada pita susjede, ako ga ni susjedi nemaju, oni pitaju svoje susjede, i tako dalje. Kad se
konačno pronađe partner koji ima traženi rad, on stupa u neposrednu komunikaciju s
polaznim partnerom te mu omogućuje uvid. Za vrijeme te komunikacije polazni partner igra
ulogu klijenta, a pronađeni partner igra ulogu poslužitelja.
p5 p6 p7
p11
p8
p4 p3 p10
p12
p9
p1 p2
Slika 3.43: decentralizirana arhitektura ravnopravnih partnera.
Tehnologije ravnopravnih partnera uglavnom su se koristile za osobne svrhe, na primjer za

dijeljenje glazbenih ili video sadržaja. Poznati primjeri su: Napster, BitTorrent i Gnutella.
Ovakvi sustavi često su kršili ili zaobilazili autorska prava, pa su bili predmet sudskih sporova
ili čak zabrana. Sustavi internetske telefonije (VoIP) poput Skype također se mogu smatrati
primjerima ravnopravnih partnera, gdje partner koji uspostavlja poziv privremeno preuzima
ulogu klijenta, a partner koji prima poziv privremeno postaje poslužitelj.
Model ravnopravnih partnera ima sličnosti s modelom distribuiranih objekata po tome što
također zaobilazi ili prevladava uobičajenu podjelu procesa na klijente i poslužitelje. Ipak,
između ova dva modela postoje i sljedeće razlike.
 Kod distribuiranih objekata sustav se sastoji od međusobno različitih dijelova; svaki od tih
dijelova specijalizirao se za obavljanje jedne fiksirane uloge. Kod ravnopravnih partnera
sustav se sastoji od istovrsnih dijelova; svaki od tih dijelova samo privremeno preuzima
neku od uloga.
 Kod distribuiranih objekata dijelovi su relativno čvrsto integrirani pomoću middleware-a
koji podržava paradigmu poziva udaljenih metoda. Kod ravnopravnih partnera ti partneri
su puno labavije povezani, naime oni komuniciraju samo povremeno služeći se
uobičajenim mrežnim protokolima i razmjenom poruka.
U modelu ravnopravnih partnera nastoji se da sustav u što većoj mjeri funkcionira na

decentralizirani način, dakle kao na slici 3.43, samo kroz interakciju partnera bez ikakve
središnje kontrole. Ipak, kod velikih mreža takav način rada postaje spor i neefikasan – lako
se može desiti da se mreža zaguši velikom brojem repliciranih poruka ili redundantnim
obradama istog upita. Tada se pribjegava polu-centraliziranoj arhitekturi prikazanoj na slici
3.44, koja se donekle udaljava od izvorne partnerske ideje.

Robert Manger
Poslužitelj za
pronalaženje
(super-partner)
p5 p6
p3
p4
p2
p1
Slika 3.44: polucentralizirana arhitektura ravnopravnih partnera.
U skladu sa slikom 3.44, polucentralizirana arhitektura osim običnih partnera uvodi i super-
partnere koji imaju sve informacije o mreži i služe kao posrednici u uspostavljanju veza
između običnih partnera. Da bi jedan partner našao odgovarajućeg partnera za komunikaciju,
on se obraća za pomoć super-partneru, što je na slici označeno crtkanim linijama. Super-
partner dojavljuje koji su drugi partneri na raspolaganju. Čim su obični partneri otkrili jedan
drugoga, oni uspostavljaju neposrednu komunikaciju, što je na slici označeno punim linijama.
Ovakvo rješenje koristi se na primjer u internetskoj telefoniji, gdje takozvani media gateway
controller služi kao neka vrsta telefonske centrale pretvarajući telefonske brojeve u IP adrese.
3.5. Oblikovanje i implementacija uklopljenih sustava
Uklopljeni sustavi predstavljaju specifičnu no vrlo raširenu vrstu softvera. Makar ih često ne
primjećujemo, oni se nalaze doslovce svuda oko nas: u perilicama rublja, telefonima,
glazbenim linijama, mikrovalnim pećnicama, bojlerima, automobilima, avionima, ... . U
prvom odjeljku ovog potpoglavlja navodimo osobine uklopljenih sustava, a u drugom
odjeljku bavimo se modelima za njihovu arhitekturu. Treći odjeljak posvećen je važnom
aspektu uklopljenih sustava, a to je ispravan timing njegovih procesa. Zadnji odjeljak govori o
alatima koji omogućuju efikasnu implementaciju uklopljenih sustava.
3.5.1. Osobine uklopljenih sustava
Uklopljeni sustav (embedded system) je softver koji je ugrađen u neki hardverski uređaj,
neposredno je u interakciji s hardverom i osigurava njegovo ispravno funkcioniranje. Taj
softver reagira na događaje koje mu dojavljuje hardver. Kao odgovor na događaje, on šalje
kontrolne signale hardveru. Pritom odgovor mora biti dovoljno brz jer u protivnom cijeli
hardversko-softverski sklop neće raditi kako treba.
Pravovremeno odgovaranje na događaje ključna je osobina svih uklopljenih sustava. Zbog

toga uklopljene sustave možemo otprilike poistovjetiti sa sustavima u realnom vremenu. Ipak,
zahtjevi u pogledu brzine odziva nisu uvijek jednako strogi. Na primjer, softver u
meteorološkoj stanici iz odjeljka 3.3.3 ne treba biti osobito brz. No ABS koji u automobilu
kontrolira upotrebu kočnice mora reagirati na blokadu kotača unutar nekoliko milisekundi.

Općenito, sustav u realnom vremenu (real-time system) je softver čiji ispravni rad ovisi ne
samo o rezultatima koje on proizvodi nego i o vremenu u kojem su ti rezultati proizvedeni.
„Meki“ sustav u realnom vremenu (soft real-time system) je sustav kod kojeg se kršenje
zahtjeva o brzini stvaranja rezultata smatra degradacijom performansi. „Tvrdi“ sustav u
realnom vremenu (hard real-time system) je takav sustav gdje se spora proizvodnja rezultata
smatra neispravnim radom.
Osim potrebe za odzivom u realnom vremenu, postoje još neke osobine po kojima se
uklopljeni sustavi razlikuju od drugih vrsta softvera. Slijedi popis tih osobina.
 Uklopljeni sustav kontinuirano radi od trenutka paljenja hardvera do trenutka gašenja. U
slučaju greške on se mora „oporaviti“ i nastaviti rad.
 Interakcije s okolinom su nepredvidive i ne mogu se kontrolirati. Uklopljeni sustav mora
odgovarati na neočekivani događaj čim se taj događaj desi, a ne onda kad bi to njemu
odgovaralo. To znači da se takav sustav mora sastojati od više paralelnih procesa.
 Za hardverski uređaj mogu postojati fizička ograničenja, kao što su ograničenje na
raspoloživu energiju ili ograničenje na predviđeni prostor. Zato uklopljeni sustav mora
štedjeti energiju ili mora preuzeti funkciju nekih dijelova hardvera koji ne stanu u prostor.
 Uklopljeni softver često stupa u neposrednu interakciju s hardverom, bez posredovanja
driver-a ili operacijskog sustava. To je potrebno zbog boljih performansi ili zbog
specifičnosti samog hardvera.
 Za uklopljenog sustave izuzetno je važno da su oni pouzdani i sigurni. Naime, uklopljeni
sustavi često upravljaju uređajima čiji krivi rad bi mogao ugroziti ljude ili stvoriti velike
materijalne štete. To onda vodi do konzervativnog pristupa u razvoju, dakle do korištenja
starijih no provjerenih metoda i alata.
Uklopljeni sustav treba zamišljati kao reakcijski sustav, dakle sustav koji reagira na događaje
iz svoje okoline brzinom te okoline. Tražena vremena odziva obično su određena zakonima
fizike. To je drukčije nego kod standardnih vrsta softvera gdje sam softver upravlja brzinom
interakcije.
Zahtjevi na uklopljeni sustav zadaju se navođenjem sljedećih elemenata.

 Popis svih podražaja (događaja) koje sustav prima.
 Odgovor sustava na svaki od podražaja.
 Vrijeme odziva u kojem sustav mora proizvesti odgovor na pojedini podražaj.
Kao primjer, prilažemo sliku 3.45 – ona prikazuje podražaje i odgovore za sustav zaštite od
provalnika koji je instaliran u nekoj zgradi. O pripadnim vremenima odziva raspravljat ćemo
u odjeljku 3.5.3.
Vidimo da u sustavu zaštite od provalnika postoje četiri vrste podražaja: pad napona,
otvaranje vrata, otvaranje prozora te pokreti u sobi. Ovisno o kombinaciji podražaja,
proizvode se neki od sljedećih odgovora: prebacivanje napajanja s električne mreže na
akumulatorsku bateriju, aktiviranje alarma, paljenje svjetala, slanje sintetizirane glasovne
poruke policiji preko telefona.
Ponašanje uklopljenog sustava zorno se može modelirati UML state machine dijagramom.
Naime podražaji (događaji) na koje sustav reagira obično uzrokuju prelazak sustava iz jednog
stanja u drugo. U odjeljku 2.3.4 na slici 2.22 već smo imali dijagram koji prikazuje rad
mikrovalne pećnice. Sad kao drugi primjer prilažemo Sliku 3.46 – na njoj je state machine
dijagram za benzinsku pumpu.

Robert Manger
Podražaj Odgovor
Otvorila su se jedna vrata ili prozor ili Pokreni alarm, upali svjetlo na odgovarajućem
je opažen pokret u jednoj sobi. mjestu u zgradi.
Otvaranje vrata, otvaranje prozora ili Pokreni alarm, upali svjetlo na odgovarajućem
pokreti istovremeno na dva ili više mjestu, pošalji sintetiziranu glasovnu poruku
mjesta u zgradi. policiji telefonom.
Pad napona između 10% i 20%. Prebaci napajanje na akumulatorsku bateriju.
Prebaci napajanje na akumulatorsku bateriju,

Pad napona više od 20% pokreni alarm, pošalji sintetiziranu glasovnu
poruku policiji telefonom.
Slika 3.45: podražaji i odgovori za sustav zaštite od provalnika.
Timeout
Čitanje Inicijalizacija
Do: čitaj Do: inicijaliziraj

kreditnu karticu prikaz
Kartica
utaknuta Kartica izvađena Cijev izvan Cijev u
držača držaču
u čitač
Kartica ok
Validacija
Čekanje Spremna Točenje
Do: provjeri
Do: prikazuj Do: toči gorivo,
valjanost
dobrodošlicu Brizgalica ažuriraj prikaz
kreditne kartice
aktivirana
Neispravna kartica Brizgalica Brizgalica

Timeout deaktivirana aktivirana
Resetiranje Zaustavljena
Do: prikaži
poruku o greški
Plaćanje
Do: tereti
Potvrda plaćanja kreditnu Cijev u držaču
karticu
Slika 3.46: UML state machine dijagram za sustav koji upravlja benzinskom pumpom.

Proces oblikovanja uklopljenog sustava drukčiji je nego za obične vrste softvera [14]. Prvi
korak obično se sastoji od donošenja odluke koje od funkcionalnosti će se implementirati u
softveru a koje u hardveru. Ograničenja na energiju i prostor prilično sužavaju projektantovu
slobodu, tako da klasični proces dekompozicije većih dijelova u manje obično nije primjenjiv.
Najopćenitiji model građe uklopljenog sustava zasniva se na činjenici da sustav na podražaje

reagira odgovorima. Podražaji se detektiraju pomoću hardverskih sklopova koji se zovu
senzori (na primjer termometar, tlakomjer, voltmetar, fotoćelija, ...). Odgovori se postižu
djelovanjem drugih hardverskih sklopova koji se zovu aktuatori (na primjer ventil, sirena,
grijač, displej, ...). Softver se treba sastojati od više paralelnih procesa: svaki od tih procesa
prati jedan ili više senzora, odnosno upravlja s jednim ili s nekoliko aktuatora.
Daljnji korak u oblikovanju uklopljenog sustava je određivanje načina pokretanja njegovih

procesa.
 Proces za praćenje senzora pokreće se ovisno o prirodi samog podražaja.
- Ako je riječ o periodičkom ili kontinuiranom podražaju, tada se proces za praćenje
odgovarajućeg senzora treba automatski pokretati određeni broj puta u sekundi. Na
primjer, senzor temperature (termometar) u kotlu treba se očitavati svakih 50 ms.
- Ako je riječ o aperiodičkom podražaju koji se pojavljuje na nepredvidljiv način, tada
se reakcija sustava treba pokrenuti preko hardverskog prekidnog mehanizma
(interrupt). Dakle proces za praćenje senzora zapravo je interrupt handler. Na primjer,
otvaranje vrata na mikrovalnoj pećnici pokreće hardverski prekid.
 Proces za upravljanje aktuatorom pokreće se onda kad je potrebno odgovoriti na podražaj.
 Mogu postojati i procesi koji rade stalno u pozadini i koriste trenutke kad procesor nije
zauzet drugim poslovima – to se na primjer koristi za samo-testiranje uređaja.
3.5.2. Arhitekture uklopljenih sustava
Kao što smo već rekli, uklopljeni sustav sastoji se od više paralelnih procesa, svaki o njih
prati jedan ili više senzora odnosno upravlja s jednim ili s nekoliko aktuatora. Općeniti model
arhitekture prikazan je na slici 3.47. Veza između procesa koji odgovaraju jednom senzoru
odnosno jednom aktuatoru detaljnije je prikazana na slici 3.48.
Praćenje Praćenje Praćenje Praćenje Praćenje

senzora senzora senzora senzora senzora
Podražaji
Uklopljeni sustav
(sustav u realnom vremenu)
Odgovori
Upravljanje Upravljanje Upravljanje Upravljanje

aktuatorom aktuatorom aktuatorom aktuatorom
Slika 3.47: najopćenitiji model arhitekture uklopljenog sustava.

Robert Manger
Senzor Aktuator
Podražaj Odgovor
Praćenje Obrada Upravljanje
senzora podataka aktuatorom
Slika 3.48: veza između procesa za senzor i procesa za aktuator
Općenita arhitektura sa slike 3.47 dalje se može profiniti tako da bolje odgovara nekim
posebnim vrstama uklopljenih sustava. U nastavku ćemo promatrati tri takva profinjenja.
Promatranje i reagiranje. Koristi se za sustave čiji rad se uglavnom svodi na redovito

praćenje senzora i prikazivanje očitanih vrijednosti. U iznimnim situacijama kad senzori
pokažu neuobičajene vrijednosti pokreće se neki dodatni proces. Struktura je prikazana na
slici 3.49.
Prikaz
Senzori
Vrijednosti Vrijednosti
Proces iz senzora Proces analize za prikaz Proces
promatranja podataka prikazivanja
Proces Proces za
alarmiranja poduzimanje akcije
Alarm Druga oprema
Slika 3.49: arhitektura promatranja i reagiranja.
Primjer uklopljenog sustava koji bi mogao koristiti ovakvu arhitekturu je prije spominjani
sustav za zaštitu od provalnika. Jedna varijanta njegove građe bit će priokazana u sljedećem
odjeljku na slici 3.55. Dakle, sustav prati nekoliko vrsta senzora koji bilježe pokrete u
sobama, otvaranje vrata ili prozora, pad napona u električnoj mreži. Kad sustav posumnja na
prisutnost provalnika, on automatski zove policiju, pali svjetla u sobama i svira alarm. U
slučaju pada napona također se uključuje pomoćno napajanje iz akumulatora.
Upravljanje okolinom. Koristi se za sustave koji upravljaju radom nekog uređaja na osnovi
podražaja iz okoline tog uređaja. Struktura je vidljiva na slici 3.50.

Prikaz
Senzori
Vrijednosti Vrijednosti
Proces iz senzora Proces analize za prikaz Proces
promatranja podataka prikazivanja
Upravljačke Stanje
naredbe aktuatora
Proces za upravljanje Proces za nadgledanje

aktuatorom aktuatora
Aktuator
Slika 3.50: arhitektura za upravljanje okolinom.
Primjer uklopljenog sustava građenog u skladu s ovom arhitekturom je anti-lock braking

system – ABS). Ugrađuje se u automobile da bi spriječio blokiranje kotača prilikom kočenja.
Preko senzora na svakom kotaču ABS registrira da li se kotač okreće ili je blokiran. U slučaju
blokade on šalje brzi niz on/off signala odgovarajućoj kočnici, što omogućuje kotaču da se
opet pokrene. Detaljna građa ABS-a prikazana je na slici 3.51.
Senzor pritiska
Kočnica 1 na pedalu Kočnica 2
Nadgledanje
pedale kočnice
kočnicom 1 kočnicom 2
Proces analize
podataka
Upravljanje Nadgledanje Upravljanje

kočnicom 3 kotača kočnicom 3
Kočnica 3 Senzori na Kočnica 3

kotačima
Slika 3.51: struktura procesa za ABS.

Robert Manger
Cjevovod procesa. Koristi se za sustave koji skupljaju podatke iz okoline i zatim ih obrađuju
ili transformiraju. Budući da podaci stižu velikom brzinom, obrada također mora biti brza,
inače bi se dio podataka mogao izgubiti. Zato se obrada razbija u niz zasebnih transformacija.
Svaku od tih transformacija obavlja posebni procesor ili procesorska jezgra, što znači da se
pojedine faze obrade odvijaju paralelno. Arhitektura cjevovoda prikazana je na slici 3.52.
Proizvedeni Podaci za
Proces podaci Proces potrošača Proces
...
proizvođač međuspremnik potrošač
Slika 3.52: arhitektura u obliku cjevovoda procesa.
Prikaz
Senzori za
neutronski fluks Identifikator
senzora i
vrijednost Pohranjivanje
fluksa Međuspremnik
A/D konverter za sirove prosječnih
vrijednosti razina
Prosječne
razine
Obrada sirovih fluksa Međuspremnik za
vrijednosti fluksa prosječne razine
Slika 3.53: procesi za skupljanje i obradu podataka o neutronskom fluksu.
Primjer uklopljenog sustava koji bi mogao koristiti cjevovod procesa jest sustav za skupljanje
podataka unutar nuklearnog reaktora. Skupljaju se podaci sa senzora koji mjere neutronski
fluks (gustoću neutrona) u reaktoru. Podaci iz senzora skupljaju se u međuspremniku, pa se iz
međuspremnika izdvajaju i obrađuju. Prosječna razina fluksa prikazuje se na operatorovom
zaslonu i zatim se sprema za buduću obradu. Detaljniji prikaz građe vidi se na slici 3.53.
3.5.3. Analiza vremenskih ograničenja za procese
Rekli smo da korektnost rada uklopljenog sustava ovisi o brzini njegovog odgovaranja na
podražaje. Zato kod oblikovanja uklopljenog sustava posebnu pažnju treba posvetiti timing-u
njegovih procesa. Dakle za svaki proces treba procijeniti njegovo trajanje te predložiti način i
frekvenciju njegovog pokretanja. Analiza procijenjenih i predloženih vrijednosti treba
pokazati da će sustav biti u stanju obraditi sve podražaje i proizvesti sve odgovore na vrijeme.

Analiza timing-a posebno je složena kad sustav mora izlaziti na kraj s mješavinom periodičkih
i aperiodičkih podražaja. Budući da su aperiodički podražaji nepredvidljivi, analiza mora
počivati na pretpostavkama o vjerojatnosti njihovog pojavljivanja. Ako se te pretpostavke
pokažu krive, performanse sustava možda neće biti zadovoljavajuće.
Ipak, današnja računala su brza pa je postalo moguće većinu podražaja tretirati kao
periodičke. Dakle umjesto da podražaj implementiramo kao hardverski prekid, služimo se
brzim procesom koji opetovano u kratkim vremenskim razmacima ispituje da li je do
podražaja došlo ili nije. Zato ćemo se u nastavku koncentrirati na vremenska ograničenja za
periodičke procese.
U analizi vremenskih zahtjeva i oblikovanju sustava koji ispunjava te zahtjeve promatramo

sljedeće veličine.
 Krajnji rok (deadline). Vrijeme u kojem sustav mora proizvesti odgovor na određeni
podražaj, mjereno od trenutka nastanka tog podražaja, Ako sustav promaši taj rok, to se
smatra greškom odnosno degradacijom usluge, ovisno o tome da li je riječ o „tvrdom“ ili
„mekom“ sustavu.
 Frekvencija. Broj koliko se puta u jedinici vremena određeni proces mora izvršavati tako
da smo sigurni da će dostići rokove.
 Vrijeme izvršavanja. Vrijeme koje određeni proces troši na jedno svoje izvršavanje, dakle
od početka do kraja svojeg rada. Riječ je o veličini koja varira ovisno o ulaznim
podacima. Kod „tvrdih“ sustava procjenjujemo vrijeme u najgorem slučaju, a kod
„mekih“ sustava može poslužiti i vrijeme u prosječnom slučaju.
Kao primjer vremenske analize promatrat ćemo opet sustav za zaštitu od provalnika. Popis
podražaja i odgovora već smo vidjeli na slici 3.45. No sada prilažemo i sliku 3.54 gdje su
navedeni zahtjevi vezani uz vremena odziva.
Podražaj / odgovor Zahtjev u pogledu vremena

Prebacivanje na akumulatorsku bateriju mora se dovršiti
Pad napona.
unutar krajnjeg roka od 50 ms.
Svaki od senzora za vrata mora se provjeravati barem
Otvaranje vrata.
dvaput u sekundi.
Svaki od senzora za prozor mora se provjeravati barem
Otvaranje prozora.
dvaput u sekundi.
Svaki od senzora za pokrete mora se provjeravati barem
Pokreti u prostorijama.
dvaput u sekundi.
Alarm se mora uključiti unutar pola sekunde od trenutka

Zvučni alarm.
pojave podražaja na senzoru.
Svjetlo se mora upaliti unutar pola sekunde od trenutka

Paljenje svjetla.
pojave podražaja na senzoru.
Komunikacija s Poziv policiji mora biti upućen unutar dvije sekunde od

policijom. trenutka pojave podražaja na senzorima.
Slika 3.54: zahtijevana vremena odziva sustava za zaštitu od provalnika.

Robert Manger
Jedan mogući rezultat oblikovanja sustava za zaštitu od provalnika u skladu sa zahtjevima sa

slike 3.45 i 3.54 prikazan je na slici 3.55. Dakle predlaže se građa koja se sastoji od glavnog
kontrolnog procesa, dva procesa za interakciju s korisnikom, procesa za samo-testiranje,
nekoliko procesa koji prate senzore i otkrivaju podražaje te nekoliko procesa koji upravljaju
aktuatorima dakle proizvode odgovore.
50 Hz (0,5 ms) B
Proces za Proces za praćenje Proces za samo-

50 Hz korisnikovih unosa testiranje
praćenje senzora
(0,5 ms)
vrata
Proces za 250 Hz (1 ms) Proces za prikaz
50 Hz 50 Hz
praćenje senzora informacija
(0,5 ms) (1 ms)
pokreta Glavni kontrolni korisniku
proces
250 Hz Proces za
(0,5 ms) praćenje napona Proces za R
upravljanje (20 ms)
Proces za napajanjem
50 Hz
praćenje senzora
(0,5 ms)
prozora
Proces za Proces za Proces za slanje
upravljanje upravljanje poruke preko
zvučnim alarmom rasvjetom telefona
R (5 ms) R (5 ms) R (10 ms)
Slika 3.55: građa sustava za zaštitu od provalnika, timing procesa.
U zamišljenoj građi senzor za pad napona samo je jedan. No da bi sustav bio učinkovit,
senzora za vrata, prozore odnosno pokrete mora biti više, na primjer do 20 od svake vrste, a
oni moraju biti raspoređeni na raznim mjestima u zgradi. Proces zadužen za otkrivanje
podražaja određene vrste redom prati sve odgovarajuće senzore, ali tako da pri jednom
pokretanju gleda samo jedan senzor.
Za svaki od procesa na slici 3.55 označen je način pokretanja. Proces za samo-testiranje

označen je s B, što znači da se on stalno izvršava u pozadini (background), dakle onda kad
procesor nema drugog posla. Procesi s oznakom R pokreću se onda kad se pojavila određena
kombinacija podražaja, ili točnije njih pokreće glavni kontrolni proces nakon što su mu
procesi za praćenje senzora dojavili podražaje. Svi ostali procesi su periodički, automatski ih
pokreće operacijski sustav u pravilnim vremenskim razmacima, a navedena im je frekvencija
u Hz (broj uzastopnih pokretanja u sekundi).
Na slici 3.55 je za sve procese osim testnog također navedeno vrijeme jednog izvršavanja u
najgorem slučaju. Procesi za praćenje senzora vrlo su jednostavni, svode se na čitanje i
usporedbu jednog podatka, zato su njihova vremena vrlo kratka i iznose 0,5 ms. Glavni
kontrolni proces ima nešto više posla jer mora provjeriti više podataka i donijeti odluke, zato
je njegovo vrijeme 1ms. Procesi koji upravljaju aktuatorima još su zahtjevniji, pa traju 5, 10
ili čak 20 ms. Kod periodičkih procesa frekvencije su konzistentne s vremenima izvršavanja,
dakle proces završava prije trenutka kad bi se ponovo morao pokrenuti.
Lako je provjeriti da sustav na slici 3.55 zadovoljava vremenske zahtjeve sa slike 3.54. Kao
primjer, analizirat ćemo učestalost provjere vrata. Proces za praćenje senzora za vrata ima
frekvenciju 50 Hz, što znači da se pokreće svakih 20 ms. No senzora za vrata ima do 20, pa se
isti senzor ponovo gleda tek nakon 20 pokretanja procesa. Dakle između dvije provjere istih
vrata može proteći 400 ms, no to je još uvijek manje od traženih 500 ms. Slična analiza vrijedi
i za prozore i pokrete.
Primijetimo da proces za praćenje napona ima vrlo visoku frekvenciju 250 Hz – to je nužno
da bi se prebacivanje napajanja na bateriju stiglo izvesti u traženom roku od 50 ms. Zaista,
frekvencija od 250 Hz znači da se napon provjerava svakih 4 ms. No da bi se otkrio pad
napona potrebne su dvije provjere i usporedba izmjerenih vrijednosti, što traje 9,5 ms. Nakon
tog otkrića treba pričekati da se pokrene i izvrši glavni kontrolni proces, što može potrošiti
daljnjih 5 ms. Glavni kontrolni proces pokrenut će proces za prebacivanje napajanja koji traje
20 ms. Dakle odgovor sustava proizvest će se u 33,5 ms, a to je unutar traženih 50 ms.
Kad bi proces za praćenje napona radio na sporijoj frekvenciji od 50 Hz, reakcija na pad
napona bila bi prespora. Naime, tada bi dva mjerenja i usporedba vrijednosti trajala 40,5 ms, a
rad glavnog kontrolnog procesa i procesa za prebacivanje napajanja zahtijevao bi daljnjih 25
ms, pa bi ukupno vrijeme odziva bilo barem 65,5 ms.
3.5.4. Implementacija uklopljenih sustava
Da bi implementirali uklopljeni sustav, potrebno je implementirati svaki od njegovih procesa.

Također je potrebno osigurati da se procesi na željeni način pokreću i istovremeno izvršavaju.
Za implementaciju svakog pojedinog procesa koriste se programski jezici. Ako je riječ o

„tvrdom“ sustavu u realnom vremenu ili baratanju sa specifičnim hardverskim uređajima, tada
se programira u assembleru. Inače se također intenzivno koristi i (obični) C. Objektno-
orijentirani programski jezici se izbjegavaju – naime oni u pravilu proizvode manje efikasan
programski kod koji često nije u stanju zadovoljiti postavljene zahtjeve na brzinu odziva.
Ipak, postoje i posebne verzije objektno-orijentiranih jezika koje su bolje prilagođene

potrebama uklopljenih sustava. Primjer za to je Real-time Java [15] gdje je promijenjen
mehanizam dretvi tako da automatski garbage collector ne može prekinuti ili usporiti rad
dretvi. Real-time Java za sada se koristi na platformama s relativno dobrom procesorskom
snagom i memorijskim kapacitetom kao što su mobiteli.
Nakon što smo implementirali sve procese, njihov istovremeni rad i međusobna suradnja
ostvaruju se uz pomoć real-time operacijskog sustava (RTOS) [16]. Za razliku od
standardnog operacijskog sustava poput Linux-a ili Microsoft Windows-a, RTOS je manji i
jednostavniji, no on omogućuje finiju kontrolu izvršavanja procesa. Za svaki proces moguće
je zadati način kako se on pokreće te frekvenciju njegovog uzastopnog pokretanja – RTOS će
nastojati izvršavati procese onako kako mu je zadano. Primjeri RTOS-a su Windows CE,
VxWorks, QNX i RTLinux.
Građa RTOS-a vidljiva je na slici 3.57. Dakle, RTOS se obično sastoji od sljedećih dijelova:
1. Sat koji mjeri realno vrijeme i daje informacije potrebne za periodičko pokretanje procesa.
2. Interrupt handler koji poslužuje aperiodičke zahtjeve za uslugama.

Robert Manger
3. Scheduler koji pregledava listu procesa i bira one koji su spremni za izvršavanje.
4. Resource manager koji alocira memoriju i procesor za proces koji je spreman za
izvršavanje.
5. Dispatcher koji pokreće proces s već alociranom memorijom i procesorom.
Informacije o
načinu i frekvenciji
pokretanja procesa
Sat u realnom
Scheduler Interrupt handler
vremenu
Zahtjevi procesa
za resursima
Procesi koji Lista dostupnih

Resource manager
čekaju resurse resursa
Spremni Oslobođeni
procesi resursi
Lista spremnih
Dispatcher Lista procesora
procesa
Proces koji se izvršava
Slika 3.56: dijelovi real-time operacijskog sustava.
Procesi unutar uklopljenog sustava često se moraju sinkronizirati ili moraju razmijeniti
poruke. Takve operacije nisu izravno podržane u assembleru ili C-u, pa se ostvaruju pozivima
sistemskih funkcija iz RTOS-a. Također, dešava se da dva procesa trebaju koristiti zajedničku
strukturu podataka, tako da jedan piše u strukturu a drugi čita iz nje. Tada je potrebno
osigurati međusobno isključivanje konfliktnih pisanja i čitanja, za što se opet koriste
mehanizmi iz RTOS-a, na primjer semafori [16].

4. Verifikacija i validacija
U ovom poglavlju bavimo se verifikacijom i validacijom (V&V). Riječ je o osnovnoj
aktivnosti unutar softverskog procesa kojom se nastoji utvrditi da li softver zadovoljava
specifikaciju te da li on odgovara potrebama korisnika. Prvo potpoglavlje sadrži definicije
pojmova vezanih uz V&V. Daljnja dva potpoglavlja proučavaju dvije metode verifikacije
softvera, a to su statička verifikacija odnosno testiranje.
4.1. Općenito o verifikaciji i validaciji
V&V srodni su pojmovi, no među njima ipak postoji suptilna razlika. Naime.
 Verifikacija (Are we building the product right?) je provjera da li softver odgovara
specifikaciji, dakle dokumentu o zahtjevima.
 Validacija (Are we building the right product?) je provjera da li softver zadovoljava
„stvarnim“ potrebama korisnika.
Razlika nastaje zato što specifikacija obično ne uspijeva u potpunosti zabilježiti stvarne
potrebe korisnika.
Konačni cilj V&V je uvjeriti se da je softver dovoljno dobar i pouzdan da može poslužiti
svojoj svrsi. To ne znači da softver mora biti sasvim bez greške, već samo da on mora biti
dovoljno dobar i pouzdan za predviđeni oblik korištenja. Stupanj toleriranja grešaka ovisi o
funkciji koju softver obavlja, očekivanjima korisnika te o tržišnim uvjetima.
U nastavku ovog potpoglavlja pobliže opisujemo metode V&V te mjesto i ulogu V&V u
cjelokupnom softverskom procesu. Također naglašavamo da V&V nije isto što i
debuggiranje.
4.1.1. Metode za verifikaciju i validaciju
Metode za verifikaciju i validaciju ugrubo se mogu podijeliti u sljedeće dvije skupine.

 Statička V&V (vidi potpoglavlje 4.2). Svodi se na analizu i provjeru dokumenata, modela
sustava, dizajna, odnosno programskog koda. Odvija se bez stvarnog izvođenja softvera.
 Testiranje (vidi potpoglavlje 4.3). Svodi se na pokusno izvođenje softvera ili njegovih
dijelova na umjetno pripravljenim podacima, uz pažljivo analiziranje rezultata.
Testiranje je uobičajena metoda, no statička V&V ima sljedeće prednosti.

 Jedna statička provjera može otkriti puno grešaka. Testiranje obično odjednom otkriva
samo jednu grešku budući da se nakon greške program „ruši“ ili radi s krivim podacima.
 Statička provjera omogućuje bolje korištenje znanja o programiranju ili aplikacijskoj
domeni. Osobe koje obavljaju provjeru znaju koje vrste grešaka se često pojavljuju u
dotičnom programskom jeziku ili aplikaciji te se koncentriraju na takve greške.
Većina autora smatra da se statičkim metodama može uz male troškove otkriti 60-90%
grešaka, nakon čega testiranje ide brže, a ukupni troškovi su manji. Znači, dvije vrste metoda
su komplementarne te se obje trebaju primjenjivati.

Robert Manger
4.1.2. Mjesto verifikacije i validacije u softverskom procesu
V&V se prvenstveno primjenjuju na programski kod, no poželjno je da se u što većoj mjeri

primjenjuju i u ranijim fazama razvoja softvera, kao što je prikazano na slici 4.1. Vidimo da
se statička provjera može obavljati u raznim fazama softverskog procesa, dok je testiranje
primjenjivo samo na program odnosno prototip. Program se najprije provjerava statičkim
metodama, a nakon toga se još podvrgava testiranju.
Statička
V&V
Dizajn na Formalna Detaljni

Zahtjevi specifikacija Program
visokoj razini dizajn
Prototip Testiranje
Slika 4.1: primjena verifikacije i validacije u raznim fazama razvoja softvera.
Utvrđivanje Specifikacija Oblikovanje Detaljno

zahtjeva sustava sustava oblikovanje
Plan za Plan za test Plan za test Kodiranje i testiranje

primopre- integracije integracije modula i manjih
dajni test sustava pod-sustava dijelova
Test Test
Puštanje u Primopre-
integracije integracije
rad dajni test
sustava pod-sustava
Slika 4.2: nastanak planova za testiranje softvera.
Da bi aktivnosti V&V dale očekivane efekte, planovi testiranja trebali bi nastati već u fazi
specifikacije i oblikovanja sustava, kao što je prikazano na slici 4.2. Plan za testiranje softvera
je dokument sa sljedećim dijelovima:
 opis procesa testiranja,
 popis zahtjeva koji će se testirati,

 popis dijelova softvera koji će se testirati,

 kalendar testiranja,
 opis načina bilježenja rezultata testiranja,
 popis hardvera i softvera koji je potreban za testiranje,
 ograničenja koja utječu na proces testiranja.
4.1.3. Odnos verifikacije, validacije i debuggiranja
Tijekom V&V otkrivaju se greške. Softver se mijenja da bi se greške popravile. Taj proces
debuggiranja često je integriran s aktivnostima V&V. Ipak, V&V i debuggiranje su različiti
procesi. Naime:
 V&V je proces koji utvrđuje postojanje grešaka u softveru.
 Debuggiranje je proces koji locira (otkriva uzrok) i popravlja te greške.
Rezultati
Zahtjevi Test primjeri
testiranja
Oblikuj Ponovo
Lociraj Popravi testiraj
popravak
grešku grešku program
greške
Slika 4.3: proces debuggiranja softvera.
Opis procesa debuggiranja vidljiv je na slici 4.3. Debuggiranje je kreativni proces kojeg je
teško precizno opisati. Vješti programeri koji provode debuggiranje pouzdaju se u svoje
iskustvo, poznavanje čestih grešaka i poznavanje svojstava korištenog programskog jezika, pa
na taj način otkrivaju uzrok greške. Pritom programerima mogu biti od pomoći interaktivni
debugger-i kakvi postoje u lower-CASE alatima.
4.2. Statička verifikacija
Vidjeli smo da se statička V&V može obavljati u raznim fazama softverskog procesa. Ipak, u
ovom potpoglavlju ograničit ćemo se na najčešći oblik takve V&V, a to je statička
verifikacija programa. Ona se svodi na analizu i pregled programskog koda, bez stvarnog
izvođenja programa. Primjenjuje se prije testiranja programa, da bi se otkrila glavnina
grešaka. Nakon toga testiranje ide znatno brže, a ukupni troškovi verifikacije su znatno manji.
U sljedeća tri odjeljka obradit ćemo tri tehnike koje spadaju u statičku verifikaciju.
4.2.1. Inspekcija programa
Inspekcija programa prakticirala se u velikim tvrtkama poput IBM i HP tijekom 70-ih, 80-ih i
90-ih godina 20. stoljeća. Riječ je o reguliranom procesu u kojem sudjeluje grupa ljudi sa
strogo zadanim ulogama:

Robert Manger
 autor ili vlasnik: programer odgovoran za program i za naknadni popravak grešaka;

 inspektor: pronalazi greške, propuste i nekonzistentnosti u programu;
 čitač: glasno čita programski kod na sastanku;
 zapisničar: bilježi rezultate sastanka;
 moderator: planira i organizira sastanke, upravlja procesom.
Sam proces odvija se u skladu sa slikom 4.4. Najvažnija faza je dobro pripremljen sastanak
(do 2 sata) na kojem inspekcijska grupa pregledava program i otkriva greške. Na sastanku se
ne raspravlja o tome kako će se greške popraviti, već je to naknadni posao autora. Moderator
u fazi nastavka odlučuje da li je potrebno ponoviti cijeli proces.
Distribucija Individualna Sastanak Popravak

Planiranje materijala priprema programa Nastavak
inspekcije
Slika 4.4: proces inspekcije programa.
Vrsta greške Inspekcijska provjera

Greške s Postoje li varijable koje nisu deklarirane?
podacima Postoje li varijable koje su deklarirane no nisu nigdje korištene?
Jesu li sve varijable u programu bile inicijalizirane prije korištenja?
Postoji li varijabla koja između dvaju pridruživanja vrijednosti nije bila korištena?
Imaju li sve konstante svoja imena?
Jesu li indeksi elemenata polja uvijek unutar predviđenih granica?
Postoji li u svakom nizu znakova (stringu) znak za kraj niza?
Greške vezane Za svaku uvjetnu naredbu, je li uvjet ispravan?
uz tok kontrole Za svaku petlju, je li sigurno da će ona završiti?
Jesu li složene naredbe ispravno zatvorene u zagrade?
U case naredbama, jesu li obuhvaćeni svi mogući slučajevi?
Jesu li u case naredbama navedene sve potrebne break naredbe?
Postoji li nedostupan programski kod?
Postoje li goto naredbe koje prebacuju kontrolu u unutrašnjost petlje?
Greške s Koristi li se svaki od ulaznih podataka?
ulazom i Je li svakom izlaznom podatku pridružena vrijednost prije njegovog ispisa?
izlazom Postoje li izlazne varijable koje se dvaput ispisuju makar između tih ispisa nije došlo
do promjene njihove vrijednosti?
Mogu li neočekivani ulazi proizvesti „korupciju“ programa?
Greške sa Imaju li svi pozivi funkcija ispravan broj parametara?
sučeljima Jesu li tipovi formalnih i stvarnih parametara u pozivima funkcija međusobno
usklađeni?
Jesu li parametri u pozivima funkcija u ispravnom poretku?
Postoje li funkcije koje vraćaju vrijednosti, no te vrijednosti se ne koriste?
Postoje li funkcije koje se nigdje ne pozivaju?
Greške vezane Postoje li neinicijalizirani pokazivači?
uz upravljanje Jesu li kod promjene vezane strukture svi pokazivači ispravno preusmjereni?
memorijom Je li dinamička memorija alocirana na ispravan način?
Je li alocirana memorija ispravno dealocirana onda kad se više ne koristi?
Greške u Jesu li sva moguća stanja greške uzeta u obzir?
upravljanju
iznimkama
Slika 4.5: lista čestih programerskih grešaka.

Da bi sastanak inspekcije uspio, važno je da:

 postoji precizna specifikacija (odgovarajućeg dijela) programa;
 postoji ažurna i dovršena verzija programskog koda;
 postoji „check-list“ čestih programerskih grešaka;
 članovi grupe su upoznati s organizacijskim standardima i žele surađivati.
Primjer moguće liste čestih programerskih grešaka vidi se na slici 4.5.
Inspekcija programa danas možda djeluje zastarjelo. Ipak, ona se zasniva na neospornoj
činjenici da programeri teško uočavaju greške u svojem vlastitom programskom kodu, no
znatno bolje uočavaju greške u tuđem programskom kodu. Ova činjenica u današnje vrijeme
je ponovno došla do izražaja u agilnoj metodi XP. Naime, programiranje u paru unutar XP
može se shvatiti kao vrsta uzajamne inspekcije, gdje dva programera jedan drugome
pregledavaju programski kod i otkrivaju greške.
4.2.2. Automatska statička analiza
Automatska statička analiza obavlja se pokretanjem softverskih alata koji prolaze kroz izvorni
tekst programa i otkrivaju moguće greške i anomalije u tom tekstu. Skreće se pažnja na
„sumnjiva mjesta“ u programu koja bi mogla sadržavati greške. Ispisuju se poruke. Sam popis
sumnjivih situacija koje upućuju na grešku ovisi o programskom jeziku i nalikuje na popis sa
slike 4.5.
> more lint_ex.c
#include <stdio.h>
printarray (Anarray) {
int Anarray;
printf (“%d”, Anarray);
}
main ( ) {
int Anarray[5]; int i; char c;
printarray (Anarray, i, c);
printarray (Anarray);
}
> cc lint_ex.c
> lint lint_ex.c
lint_ex.c(8): warning: c may be used before set

lint_ex_c(8): warning: i may be used before set
printarray: variable # of args. lint_ex.c(2) :: lint_ex.c(8)
printarray: arg. 1 used inconsistently. lint_ex.c(2) :: lint_ex.c(8)
printarray: arg. 1 used inconsistently. lint_ex.c(2) :: lint_ex.c(9)
printf returns value which is always ignored
Slika 4.6: seansa rada s alatom lint.

Robert Manger
Slika 4.6 prikazuje seansu analiziranja (malog i besmislenog) C programa pomoću

standardnog UNIX alata za statičku analizu lint. U gornjem dijelu priloga vidi se sam C kod;
zatim se vidi da prevodilac cc ne javlja nikakve greške; nakon toga poziva se lint; dalje se
vide lint-ove poruke (upozorenja) - na primjer varijabla c odnosno i bila je korištena prije
nego što je bila inicijalizirana, a funkcija printarray() bila je pozivana s krivim brojem ili
tipom parametara.
Nema sumnje da za jezike poput C statička analiza predstavlja efikasnu tehniku za otkrivanje
programerskih grešaka. No u „strožim“ jezicima poput Jave samim pravilima jezika
izbjegnute su neke konstrukcije koje lako dovode do greške, na primjer sve varijable moraju
biti inicijalizirane, nema goto naredbi (pa je teže stvoriti nedostupni kod), upravljanje
memorijom je automatsko (nema pokazivača). Takav pristup sprečavanja grešaka umjesto
njihovog kasnijeg otkrivanja pokazuje se efikasnim načinom poboljšavanja pouzdanosti
programa. Zato je statička analiza u slučaju Java programa manje isplativa nego u slučaju C
programa.
4.2.3. Formalna verifikacija
Formalna verifikacija svodi se na matematičko dokazivanje da je program konzistentan sa

svojom specifikacijom. Moguća je pod sljedećim uvjetima:
 semantika programskog jezika je formalno definirana;
 postoji formalna specifikacija za program.
Dokaz se provodi tako da se polazni uvjeti iz specifikacije i same naredbe iz programa uzmu
kao činjenice, pa se iz njih izvode konačni uvjeti koji po specifikaciji moraju biti zadovoljeni
nakon izvršenja programa.
Formalna verifikacija je zahtjevna i mukotrpna aktivnost. Obično se provodi samo nad

manjim dijelovima softvera, i to dijelovima koji su važni sa stanovišta sigurnosti ili
pouzdanosti. Da bi se posao ubrzao, koriste se alati za automatsko dokazivanje, takozvani
theorem prover-i. U praksi se ova tehnika često reducira na malo strožu inspekciju: razvijaju
se strogi (no ne sasvim formalni) argumenti da program radi korektno. Primjer takvog
pristupa koji uključuje strogu inspekciju je Cleanroom Software Development (IBM, 90-e
godine 20. stoljeća, autor Mills i drugi).
Idejom formalne verifikacije intenzivno su se bavila mnoga velika imena računarstva tijekom
70-ih godina 20. stoljeća (Hoare, Dijkstra, Wirth). Ipak, u to vrijeme nije se došlo dalje od
malih akademskih primjera. Ideja se i dalje njeguje u krugovima pobornika formalnih metoda
za razvoj softvera, predmet je intenzivnog istraživanja te polako postiže sve bolje rezultate. U
posljednje vrijeme pažnju istraživača privlači varijanta formalne verifikacije koja se zove
provjera modela (model checking).
Kod model checking-a, softver koji želimo verificirati prikazuje se odgovarajućim

matematičkim modelom, na primjer konačnim automatom ili logičkim izrazom. Zatim se
dokazuje da taj model ima neko poželjno svojstvo. Dokazivanje se obično svodi na
sistematsku provjeru svih mogućnosti, na primjer prolazak svih putova kroz konačni automat
ili generiranje svih kombinacija vrijednosti varijabli u logičkom izrazu. Provjeru obavlja
posebni alat, takozvani model checker. Rezultat provjere je ili potvrda da svojstvo vrijedi ili
protuprimjer koji pokazuje da svojstvo ne vrijedi. Cijeli postupak ilustriran je slikom 4.7.

Gradnja
modela Model sustava
Dizajn ili Model

program checker
Poželjna
Specifikacija
svojstva
svojstava
sustava
Potvrda ili
kontra-
primjeri
Slika 4.7: postupak provjere modela (model checking).
Kao primjer model checking-a, zamislimo da za meteorološku stanicu koju smo proučavali u
odjeljku 3.3.3 želimo dokazati da ona uvijek prije ili kasnije ulazi u stanje slanja podataka.
Tada nam kao model može poslužiti UML state machine dijagram sa slike 3.26. Provjera
svojstva svodi se na generiranje svih mogućih putova (svih mogućih nizova prijelaza) kroz
dijagram. Ako svaki od tih putova sadrži stanje „Šalje podatke“, svojstvo je dokazano. Inače
smo našli protuprimjer, dakle mogući niz prijelaza za koji svojstvo ne vrijedi. Primijetimo da
se metodama model checking-a postiže samo parcijalna verifikacija softvera: provjeravaju se
samo neka svojstva koja slijede iz specifikacije, a zanemaruju se ostala svojstva.
Ključna stvar u model checking-u je stvaranje modela programa. Ako se model stvara ručno,
to može zahtijevati previše vremena. Također, lako se može desiti da model ne odgovara u
potpunosti programu. Zato je puno bolje ako se model stvara automatski iz izvornog teksta
programa. Takvo automatsko stvaranje postoji na primjer u alatu Java Pathfinder kojeg je
razvila NASA i koji služi za verifikaciju Java programa.
Pobornici formalne verifikacije tvrde da ona vodi do pouzdanijeg i sigurnijeg softvera.

Tvrdnja je velikom dijelom točna, no ne u potpunosti. Razlozi za to su sljedeći.
 Specifikacija (čak i formalna) ne mora odražavati stvarne zahtjeve korisnika.
 Dokaz korektnosti programa je velik i složen, pa može sadržavati i greške.
 Korisnici će možda koristiti softver na način koji se razlikuje od onoga koji se
pretpostavljao u dokazu korektnosti.
4.3. Testiranje softvera
Testiranje je pokusno izvođenje softvera ili njegovih dijelova na umjetno pripravljenim

podacima, uz pažljivo analiziranje rezultata. Svrha testiranja može biti verifikacija ili
validacija. U ovom potpoglavlju ograničavamo se na testiranje u svrhu verifikacije, dakle na
testiranje kojim se provjerava da li softver radi prema svojoj specifikaciji. U sljedećih
nekoliko odjeljaka objašnjavamo najvažnije vrste testiranja, a u zadnjem odjeljku bavimo se
danas aktualnom idejom razvoja softvera vođenog testiranjem.
4.3.1. Vrste i faze testiranja
Postoje razne vrste testiranja. Jedna moguća klasifikacija prikazana je na slici 4.8. Prva razina
podjele na toj slici napravljena je po kriteriju tko odnosno kada sudjeluje u testiranju.

Robert Manger
 Razvojno testiranje provodi razvojni tim tijekom razvoja softvera.

 Testiranje izdanja obavlja posebni tim za testiranje unutar softverske kuće uoči isporuke
novog izdanja softvera.
 Korisničkim testiranjem bave se sami korisnici tijekom isporuke softvera.
Testiranje
Razvojno testiranje
(development testing)
Statističko testiranje
Testiranje u svrhu
otkrivanja grešaka
Testiranje dijelova
Funkcionalno testiranje
Strukturalno testiranje
Testiranje po putovima
Testiranje integracije
Testiranje izdanja
(release testing)
Testiranje zahtjeva
Testiranje scenarija
Testiranje performansi
Korisničko testiranje
(user testing)
Alfa testiranje
Beta testiranje
Primopredajno testiranje
Slika 4.8: klasifikacija raznih vrsta testiranja.

Svaka vrsta testiranja s prve razine podjele dalje se dijeli na podvrste. Na primjer, razvojno
testiranje uključuje u sebi sljedeće dvije podvrste. One obje služe za provjeru da li softver koji
razvijamo zadovoljava zahtjeve, no razlikuju se s obzirom na vrstu zahtjeva i način biranja
test-podataka.
 Testiranje u svrhu otkrivanja grešaka. Služi za provjeru funkcionalnih zahtjeva. Namjera
je otkriti odstupanja između softvera i njegove specifikacije. Ta odstupanja posljedica su
grešaka u softveru. Test-podaci su konstruirani tako da otkriju prisutnost greške, a ne tako
da simuliraju normalnu uporabu softvera.
 Statističko testiranje. Služi za provjeru nekih oblika nefunkcionalnih zahtjeva. Namjera je
na primjer izmjeriti performanse softvera ili stupanj njegove pouzdanosti. Test-podaci su
odabrani tako da liče na stvarne korisničke podatke te da odražavaju njihovu stvarnu
statističku razdiobu. Obično je riječ o velikom broju slučajno odabranih test primjera, što
omogućuje statističku procjenu performansi ili pouzdanosti.
U nastavku ovog odjeljka ograničavamo se na testiranje u svrhu otkrivanja grešaka. Takvo

testiranje smatra se uspješnim onda kad ono pokaže da softver ne radi dobro. Nakon testiranja
grešaka slijedi postupak debuggiranja (vidi potpoglavlje 4.1). Primijetimo da testiranje može
pokazati da u softveru postoje greške, no ne može dokazati da grešaka nema.
Testiranje
Testiranje integracije
dijelova
Testiranje jedinki Testiranje Testiranje Testiranje

(funkcija, klasa) modula pod-sustava sustava
Slika 4.9: proces testiranja u svrhu otkrivanja grešaka - detaljni prikaz.
Testiranje Testiranje
dijelova integracije
Slika 4.10: proces testiranja u svrhu otkrivanja grešaka - sažeti prikaz.
Proces testiranja u svrhu otkrivanja grešaka obično se sastoji od nekoliko faza, koje uzimaju u
obzir da veliki sustav ima složenu građu. Detaljni prikaz faza vidi se na slici 4.9. Sažetiji
prikaz tih istih faza nalazi se na slici 4.10. S jedne strane testiramo sastavne dijelove softvera,
s druge strane testiramo da li su ti dijelovi na ispravan način integrirani u veće cjeline te da li
su te veće cjeline ispravno integrirane u još veće cjeline, i tako dalje. U fazi testiranja
integracije, testiranje se fokusira na interakcije između dijelova te na funkcionalnost cjeline.
Ipak, često se dešava da se u toj fazi otkrivaju i greške u dijelovima. Zbog toga se faze mogu
ponavljati. Testiranje dijelova obično provode osobe koje su razvile te dijelove, a testiranje
integracije može bit posao nezavisnog tima.

Robert Manger
4.3.2. Testiranje dijelova softvera
Da bi testiranje dijela softvera bilo uspješno, važno je znati odabrati test podatke. U nastavku
ćemo promatrati nekoliko pristupa koji se razlikuju po načinu odabira test podataka.
Funkcionalno testiranje (black-box testing). Test-primjeri izvode se isključivo iz

specifikacije dotičnog dijela softvera. Ili, drukčije rečeno, softver se promatra kao „crna
kutija“ o kojoj jedino znamo da bi ona (prema specifikaciji) za zadane ulaze trebala proizvesti
zadane izlaze. Zbog postojanja grešaka, ulazi iz određenog (nepoznatog) skupa Ie izazvat će
neispravno ponašanje, koje ćemo prepoznati po izlazima iz skupa Oe. To je sve prikazano na
slici 4.11. U postupku testiranja nastojimo izabrati ulaze za koje postoji velika vjerojatnost da
pripadaju skupu Ie. Izbor takvih test primjera najčešće se zasniva na iskustvu softverskog
inženjera. Ipak, moguć je i sistematičniji pristup zasnovan na podjeli skupa svih mogućih
ulaznih podataka (domene) na klase. Ovdje riječ „klasa“ nije upotrjebljena u smislu objektno-
orijentiranog pristupa, nego u smislu matematičkog pojma „klasa ekvivalencije“. Očekujemo
da će se program ponašati slično za sve podatke iz iste klase. Biramo barem po jedan test-
primjer iz svake klase. Također je dobro isprobati „rubove“ klasa.
Ulazni
Ie
podaci
Testirani dio
softvera
Izlazni
Oe
rezultati
Slika 4.11: funkcionalno testiranje grešaka (black box).
Kao ilustraciju, promatramo proceduru za traženje elementa Key u polju T koja bi trebala
zadovoljavati specifikaciju sa slike 4.12. Procedura vraća odgovor Found da li je Key
pronađen u T te indeks L na kojem se Key nalazi u T. Iz same specifikacije, jasno je da
domenu možemo podijeliti na dvije klase:
 ulazi gdje je Key zaista element polja T (Found = true);
 ulazi gdje Key nije element polja T (Found = false).
Dalje, iskustva u radu s poljima govore nam da treba probati:
 polje T s ekstremnom duljinom, u ovom slučaju s jednim elementom;
 element Key na rubovima odnosno na sredini polja T.
Kad kombiniramo ova dva načina podjele domene na klase, dobivamo particiju sa slike 4.13
koja se sastoji od 6 klasa. Shodno tome, biramo 6 test-primjera koji se vide na slici 4.14.

procedure Search (Key: ELEM; T: SEQ of ELEM;

Found: in out BOOLEAN; L: in out ELEM_INDEX);
Pre-condition
-- the sequence has at last one element
T'FIRST <= T'LAST
Post-condition
-- the element is found and is referenced by L
(Found and T(L) = Key)
or
-- the element is not in the sequence
(not Found and
not (exists i, T'FIRST <= i <= T'LAST, T(i) =Key ) )
Slika 4.12: specifikacija procedure za traženje elementa u polju.
Polje Traži se
Jedna vrijednost Element iz polja
Jedna vrijednost Element koji nije u polju
Više od jedne vrijednosti Prvi element u polju
Više od jedne vrijednosti Zadnji element u polju
Više od jedne vrijednosti Srednji element u polju
Više od jedne vrijednosti Element koji nije u polju
Slika 4.13: particija domene za funkcionalno testiranje.
Ulazno polje (T) Tražena vrijednost (Key) Izlaz (Found, L)

17 17 true, 1
17 0 false, ??
17, 29, 21, 23 17 true, 1
41, 18, 9, 31, 30, 16, 45 45 true, 7
17, 18, 21, 23, 29, 41, 38 23 true, 4
21, 23, 29, 33, 38 25 false, ??
Slika 4.14: test-primjeri za funkcionalno testiranje.
Strukturalno testiranje (white-box testing). Dodatni test-primjeri izvode se na osnovu

poznavanja interne strukture testiranog dijela softvera i korištenih algoritama. Dakle služimo
se analizom programskog koda dotičnog dijela softvera da bi odabrali dodatne test primjere,
to jest da bi bolje podijelili domenu na klase.
Kao primjer, pogledajmo na slici 4.15 implementaciju u Javi naše procedure za traženje
elementa u polju. Koristi se algoritam binarnog traženja. Sad se podrazumijeva malo stroža
specifikacija, naime polje mora biti uzlazno sortirano. Promatranjem programskog koda
uočavamo da svaki korak algoritma dijeli polje na tri dijela. Zato osim izbora elementa Key

Robert Manger
na rubovima te na sredini polja T uvodimo i dva nova izbora: neposredno ispred i iza srednjeg
elementa u polju - vidi sliku 4.16. Nakon revizije starih test primjera (polje mora biti
sortirano) te dodavanja dvaju novih primjera dobivamo ukupno 8 test primjera sa slike 4.17.
Class BinSearch{
// Ovo je enkapsulacija funkcije binarnog traženja.

// Funkcija uzima kao parametre sortirano polje cijelih brojeva elemArray i
// cjelobrojnu vrijednost key. Funkcija vraća objekt s dva atributa:
// index - indeks elementa u polju elemArray gdje se pojavljuje vrijednost key,
// found - booleovska vrijednost koja kaže je li key pronađen u polju ili nije.
// Ako key nije pronađen, tada se indeks u odgovoru postavlja na -1.
Public static void search (int key, int[] elemArray, Result r) {

1. int bottom = 0:
2. int top = elemArray.length – 1;
int mid
3. r.found = false;
4. r.index = -1;
5. while (bottom <= top) {
6. mid = (top + bottom) / 2;
7. if (elemArray[mid] == key) {
8. r.index = mid;
9. r.found = true:
10. return;
}
else {
11. if (elemArray[mid] < key)
12. bottom = mid + 1;
else
13. top = mid – 1;
}
}
14. }
}
Slika 4.15: implementacija procedure za traženje elementa u polju (binarno traženje).
Granice klasa ekvivalencije
Elementi < srednjeg Elementi > srednjeg
Element na sredini
Slika 4.16: particija domene za strukturalno testiranje.

Ulazno polje (T) Tražena vrijednost (Key) Izlaz (Found, L)

17 17 true, 1
17 0 false, ??
17, 21, 23, 29 17 true, 1
9, 16, 18, 30, 31, 41, 45 45 true, 7
17, 18, 21, 23, 29, 38, 41 23 true, 4
17, 28, 21, 23, 29, 33, 38 21 true, 3
12, 18, 21, 23, 32 23 true, 4
21, 23, 29, 33, 38 25 false, ??
Slika 4.17: test primjeri za strukturalno testiranje.
Testiranje po putovima (path testing). Riječ je o posebnoj vrsti strukturalnog testiranja, gdje
se test primjeri biraju tako da se isproba svaki „nezavisni put“ kroz dijagram toka kontrole
testiranog dijela softvera. Dakle najprije se mora nacrtati dijagram toka kontrole dotičnog
dijela softvera. Dijagram se crta tako da se naredbe while i if - then - else prikažu obrascima
sa slike 4.18, a ostale naredbe se prikažu svaka po jednim čvorom. Uočavaju se čvorovi koji
predstavljaju „početak“ i „kraj“ toka kontrole. Testiranje po putovima zahtijeva da se
konstruiraju takvi test primjeri koji će isprobati svaki od nezavisnih putova kroz dijagram.
Nezavisni put je onaj koji ide od „početka“ do „kraja“ i prolazi bar jednim novim lukom.
ne
Uvjet Uvjet
da da ne
Tijelo True-grana False-grana
Nastavak while Nastavak if-then-else
Slika 4.18: obrasci za crtanje dijagrama toka kontrole.
Za Java implementaciju binarnog traženja sa slike 4.15 odgovarajući dijagram toka kontrole
vidi se na slici 4.19. Brojevi čvorova na dijagramu odgovaraju brojevima redaka u Java kodu.
Početak toka kontrole je čvor 1 a kraj je čvor 14. Postoje 4 nezavisna puta, i to:
 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14;
 1, 2, 3, 4, 5, 14;
 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, 6, 7, 8, 9, 10, 14;
 1, 2, 3, 4, 5, 6, 7, 11, 13, 5, 6, 7, 8, 9, 10, 14 ;
Ako se u test primjerima prođe svaki od ovih putova, tada smo sigurni da je:
 svaka naredba bila izvršena bar jednom,
 svako grananje bilo isprobano za slučaj istine i za slučaj laži.

Robert Manger
bottom > top while bottom <= top

5
elemArray[mid] != key
7 11
elemArray[mid] = key elemArray[mid] > key elemArray[mid] < key
8 12 13
14 10
Slika 4.19: dijagram toka kontrole za proceduru binarnog traženja.
Može se dokazati da je maksimalni broj nezavisnih putova u dijagramu jednak je takozvanoj

ciklomatskoj složenosti dijagrama, koja se računa kao: (broj lukova) – (broj čvorova) + 2.
Također se može pokazati je da je ciklomatska složenost za program bez goto naredbi
jednaka broju uvjeta u if, while i sličnim naredbama, plus 1.
U slučaju naše implementacije binarnog traženja lako bismo konstruirali 4 test primjera koji
odgovaraju uočenim nezavisnim putovima. No kod kompliciranijih rutina (mnogo grananja i
petlji) to bi moglo biti znatno teže. Zato se pribjegava takozvanim dinamičkim analizatorima
programa. Oni mjere broj izvršavanja pojedine naredbe tijekom testiranja. Na taj način
otkrivamo koji dijelovi programa nisu bili dovoljno testirani pa smišljamo nove test primjere.
4.3.3. Testiranje integracije
Testiranje integracije provodi se nakon što se manji dijelovi softvera udruže u veću cjelinu.
Cilj testiranja je otkriti greške koje nastaju zato što dijelovi na pogrešan način koriste
međusobna sučelja. U skladu sa slikom 4.20, test primjeri se primjenjuju na cjelinu, a ne na
pojedine dijelove.

A B
Test primjeri
Slika 4.20: primjena test primjera kod testiranja integracije.
Ova vrsta testiranja osobito je važna za objektno-oblikovane sustave. Naime, objekti su

definirani preko svojih sučelja te se ponovo upotrebljavaju u kombinaciji s drugim objektima
u drugim sustavima – tada nastaju greške čiji uzrok je interakcija objekata, a ne rad pojedinog
objekta.
Postoje različiti tipovi sučelja između udruženih dijelova. Nabrajamo četiri tipa.
 Proceduralno sučelje. Jedan dio softvera poziva proceduru koja pripada drugom dijelu
softvera.
 Parametarsko sučelje. Podatak ili referenca na njega prenosi se kao parametar u pozivu
procedure iz jednog dijela softvera u drugi.
 Slanje poruka. Jedan dio softvera zahtijeva uslugu od drugog dijela tako što mu pošalje
poruku. Povratna poruka uključuje rezultat izvršene usluge.
 Zajednička memorija. Blok memorije dostupan je raznim dijelovima softvera. Jedan dio
sprema podatke u blok, a drugi ih čita iz bloka.
Greške u korištenju sučelja mogu se podijeliti na sljedeće tri vrste.

 Nerazumijevanje sučelja. Na primjer kod proceduralnog sučelja, dio koji poziva rutinu za
binarno traženje ne zna da polje mora biti sortirano.
 Pogrešna upotreba sučelja. Na primjer, krivi tip podatka u parametarskom sučelju.
 Greške u sinkronizaciji. Na primjer, kod slanja poruka ili kod zajedničke memorije.
Dijelovi koji proizvode odnosno troše podatke rade na različitim brzinama.
Testiranje integracije posebno je teško zato što se greške mogu pojaviti samo u iznimnim
situacijama (veliko opterećenje sustava) ili pak na neočekivanim mjestima (u sasvim drugom
dijelu softvera). Slijede općeniti naputci za testiranje integracije.
 Pregledaj programski kod svakog dijela softvera i popiši sve interakcije jednog dijela s
drugim dijelovima.
 U slučaju proceduralnog sučelja probaj situaciju kad procedura vraća status greške.
 U slučaju parametarskog sučelja oblikuj testove koji koriste ekstremne vrijednosti
parametara.
 Ako se prenašaju pokazivači (pointer-i), isprobaj primjere s nul-pokazivačima.

Robert Manger
 Ako se razmjenjuju poruke, probaj stvoriti znatno više poruka nego što se očekuje u
normalnim okolnostima.
 Ako se koristi zajednička memorija, variraj redoslijed aktiviranja dijelova softvera koji
pristupaju toj memoriji.
Softverski sustavi obično sadrže nekoliko razina integracije. Na primjer: najmanje jedinke
udružuju se u module, koji se spajaju u podsustave, koji čine sustav. Zbog više razina
integracije, testiranje integracije mora se ponoviti više puta. Pritom redoslijed testiranja može
biti jedan od sljedeća dva.
 Top-down: najprije se testira integracija na najvišoj razini, zatim na nižoj razini, … , na
kraju na najnižoj razini. Pritom se nepostojeći ili netestirani dijelovi s niže razine
zamjenjuju s nadomjescima - takozvanim stub-ovima. Stub ima isto sučelje kao
odgovarajući dio ali vrlo ograničenu funkcionalnost.
 Bottom-up: najprije se testira integracija na najnižoj razini, zatim na idućoj višoj razini,
…, na kraju na najvišoj razini. Nisu potrebni stub-ovi jer za svaku iduću razinu integracije
već imamo implementirane i testirane sve sastavne dijelove. Ipak, potrebni su test driver-i
koji pozivaju manje dijelove softvera i simuliraju njihovu okolinu.
Dva redoslijeda testiranja integracije ilustrirana su na slikama 4.21 i 4.22.
Redoslijed
Razina 1 Razina 1 ...
testiranja
Umetci za Razina 2 Razina 2 Razina 2 Razina 2

razinu 2
Umetci za
razinu 3
Slika 4.21: testiranje integracije u redoslijedu top-down.
Test
driver-i
Razina N Razina N Razina N Razina N Razina N

Redoslijed
testiranja
Test
driver-i
Razina N-1 Razina N-1 Razina N-1
Slika 4.22: testiranje integracije u redoslijedu bottom-up.

Prednost top-down redoslijeda je da on ranije otkriva eventualne greške u arhitekturi.

Također, psihološka prednost top-down-a je da se relativno rano dobiva sustav koji radi
(doduše s ograničenom funkcionalnošću) i koji se može pokazivati. Mana top-down-a je da se
troši vrijeme na izradu stub-ova.
Prednost bottom-up redoslijeda je da se lakše uključuju gotove komponente. Također,

prednost bottom-up-a je da arhitektura ne mora biti dovršena sve do zadnjeg časa. Mana
bottom-up-a je da se troši vrijeme na izradu test driver-a.
4.3.4. Razvoj softvera vođen testiranjem
Neki autori smatraju da je testiranje toliko važno da ono može voditi cijeli proces razvoja
softvera. Ti autori formulirali su ideju razvoja vođenog testiranjem (test-driven development)
[17]. Riječ je o pristupu gdje se testiranje isprepliće s razvojem programskog koda. Dakle kod
se razvija na inkrementalan način zajedno s testovima za taj inkrement. Nema pomaka na
idući inkrement sve dok trenutna verzija koda ne prođe test.
Razvoj softvera vođen testiranjem sastavni je dio agilnih metoda poput XP [10] i tamo se
zove test-first development. No isti pristup može se uklopiti i u klasične metode. Proces
razvoja vođenog testiranjem ilustriran je slikom 4.23.
Identificiraj prošao
novu
funkcionalnost
nije Implementiraj
prošao
Napiši test Izvrši test funkcionalnost
uz refactoring
Slika 4.23: razvoj softvera vođen testiranjem.
Kao što vidimo na slici 4.23, razvoj vođen testiranjem sastoji se od sljedećih koraka.
1. Identificira se novi inkrement funkcionalnosti. On treba biti relativno mali, tako da se
može implementirati u nekoliko desetaka redaka koda.
2. Piše se test za tu funkcionalnost te se taj test implementira pomoću CASE alata za
automatsko testiranje.
3. Nad trenutnom verzijom softvera izvršava se novi test zajedno sa svim prijašnjim
testovima koji su bili implementirani ranije. U prvom pokušaju novi test neće proći budući
da nova funkcionalnost još nije bila implementirana.
4. Sad se tek implementira nova funkcionalnost i ponovo se izvršava test. Implementiranje
može uključiti i refactoring postojećeg koda.
5. Nakon što novi testovi uspješno prođu, moguće je nastaviti s implementacijom idućeg
komada funkcionalnosti.
Robert Manger
Da bi razvoj vođen testiranjem bio izvediv, neophodan je odgovarajući CASE-alat za

automatsko testiranje. Primjer takvog alata je JUnit [18] – on služi za testiranje Java
programa. JUnit radi tako da testove ugrađuje u posebni program. Taj program pokreće
testove time što poziva sustav koji testiramo. Na taj način moguće je pokrenuti stotine
pohranjenih testova u nekoliko sekundi.
Prema mišljenju njegovih pobornika, razvoj vođen testiranjem ima sljedeće prednosti.
 Bolje razumijevanje koda. Pisanjem testa programer bolje artikulira svoju ideju o tome što
bi idući segment koda trebao raditi.
 Bolja pokrivenost koda testovima. Osigurano je da za svaki komad koda postoji
odgovarajući test. Sigurni smo da će se svi dijelovi koda izvršiti prilikom testiranja.
 Testiranje unatrag. Skup testova postepeno se razvija zajedno sa sustavom. Nakon svake
promjene programskog koda moguće je odmah izvesti sve stare testove i provjeriti da
promjena nije narušila staru funkcionalnost.
 Jednostavnije debuggiranje. Kad test ne prođe, očito je da se uzrok nalazi u novom dijelu
koda – njega treba provjeriti i promijeniti. Nisu potrebni alati za debuggiranje.
 Dokumentiranje sustava. Sami testovi služe kao vrsta dokumentacije koja opisuje što bi
programski kod trebao raditi. Čitanje testova omogućuje lakše razumijevanje koda.
S druge strane, primijećeno je da razvoj vođen testiranjem ima sljedeće nedostatke.

 Nepogodan je ako upotrebljavamo velike dijelove tuđeg ili baštinjenog koda, pa moramo
pisati testove za te velike dijelove.
 Nije efikasan kod sustava s više dretvi. Naime, dretve se mogu drukčije ispreplesti pri
različitim pokretanjima testa, što može stvoriti različite rezultate.
 Nije primjenjiv za testiranje integracije ili testiranje performansi ili pouzdanosti cijelog
sustava.
Slično kao i agilne metode, razvoj vođen testiranjem za sada se pokazao uspješnim kod malih
ili srednje velikih projekata.

5. Održavanje i evolucija
Nakon puštanja u uporabu, softverski sustav mora se i dalje mijenjati. Promjene softvera
nužne su da bi se držao korak s novim korisničkim zahtjevima, promjenama poslovnog
okruženja, napretkom hardvera i tako dalje. U sljedećim potpoglavljima najprije govorimo
općenito o dva osnovna načina mijenjanja softvera, a to su održavanje odnosno evolucija.
Zatim detaljnije proučavamo organizirani proces održavanja koji se obično naziva upravljanje
konfiguracijom. Na kraju se bavimo specifičnom problematikom mijenjanja zastarjelog
(baštinjenog) softvera.
5.1. Općenito o održavanju i evoluciji
Proces mijenjanja softvera nazivamo održavanje odnosno evolucija. Za neke autore ove dvije
riječi su sinonimi, s time da je prva tradicionalna i posuđena iz tehnike, a druga je novija i
točnija. Mi ćemo pod održavanjem podrazumijevati planirani rutinski dio procesa koji
se sastoji od manje radikalnih promjena, dok će evolucija označavati ukupni proces s
nepredvidivim elementima koji može dovesti do bitnih promjena u arhitekturi softvera i
korištenoj tehnologiji. U odjeljcima koji slijede najprije objašnjavamo razlike između raznih
vidova mijenjanja softvera. Zatim detaljnije govorimo o vrstama i dinamici održavanja te o
cijeni održavanja. Na kraju raspravljamo o održavanju unutar agilnih metoda razvoja softvera.
5.1.1. Strategije mijenjanja softvera
Prema autoru Warrenu [31], postoje sljedeće tri strategije mijenjanja softvera koje se
međusobno dopunjuju.
 Održavanje softvera. Promjene se rade zato da bi se držao korak s (promijenjenim)
zahtjevima. Mijenja se funkcionalnost, no struktura softvera uglavnom ostaje ista.
 Arhitekturna transformacija. Riječ je o značajnoj promjeni arhitekture softverskog
sustava. Na primjer, sustav se iz centralizirane mainframe arhitekture prebacuje u
distribuiranu arhitekturu s klijentima i poslužiteljima. Funkcionalnost se može ili ne mora
promijeniti.
 Softversko reinženjerstvo. Ne dodaje se nikakva nova funkcionalnost. Također, nema
velike promjene u arhitekturi. Umjesto toga, sustav se transformira u oblik koji se lakše
može razumjeti i dokumentirati te obrađivati raspoloživim alatima. Na primjer,
programski kod se automatski prebacuje iz jednog (zastarjelog) programskog jezika u
drugi (suvremeni).
Održavanje softvera je kontinuirani rutinski proces koji se svodi na niz uzastopnih promjena.
Kao rezultat održavanja nastaje velik broj različitih verzija softvera, od kojih svaka
predstavlja nešto drukčiju konfiguraciju sastavnih dijelova. Cijeli proces treba pažljivo
planirati i kontrolirati. Također je neophodno imati točnu evidenciju svih verzija i njihovih
konfiguracija. Skup potrebnih metoda, alata i organizacijskih zahvata naziva
se upravljanje konfiguracijom i bit će opisan u potpoglavlju 5.2.

Robert Manger
Arhitekturna transformacija i softversko reinženjerstvo su jednokratni i radikalni zahvati

kojima se pribjegava onda kad održavanje više ne daje rezultate ili postane preskupo. Ti
zahvati obično se primjenjuju na stari „baštinjeni“ (legacy) softver, zato da bi se takav softver
osuvremenio te učinio pogodnijim za daljnje korištenje i mijenjanje. Nakon arhitekturne
transformacije ili reinženjerstva, transformirani softver dalje se podvrgava održavanju.
Transformiranje baštinjenog softvera bit će obrađeno u potpoglavlju 5.3.
5.1.2. Vrste i dinamika održavanja softvera
Održavanje se sastoji od mijenjanja postojećih dijelova softvera te po potrebi od dodavanja

novih dijelova, bez bitnog narušavanja postojeće arhitekture. S obzirom na sadržaj i karakter
promjena razlikujemo sljedeće vrste održavanja.
 Korekcijsko održavanje. Ispravljaju se uočene greške. Može se raditi o greškama u
kodiranju (jeftino za ispraviti), u oblikovanju (skuplje), odnosno u specifikaciji
(najskuplje).
 Adaptacijsko održavanje. Obavlja se prilagodba na novu platformu, na primjer drugi
hardver, drugi operacijski sustav, ili drugu biblioteku potprograma. Funkcionalnost
softvera nastoji se održati nepromijenjenom.
 Perfekcijsko održavanje. Implementiraju se novi funkcionalni ili nefunkcionalni zahtjevi.
Ti zahtjevi odražavaju povećane potrebe korisnika ili promjene u poslovnom okruženju.
Pojedina nova verzija softvera obično kombinira više vrsta promjena, no na menadžmentu je
da odluči kojoj vrsti održavanja će dati prednost.
Autori Lehman i Belady [32] objavili su empirijska istraživanja dinamike održavanja softvera.
Istraživanja sugeriraju da vrijede sljedeći, takozvani Lehmanovi „zakoni“.
1. Nužnost mijenjanja. Softver koji se zaista koristi u stvarnom svijetu nužno se mora
mijenjati jer u protivnom ubrzo postaje neuporabljiv.
2. Povećavanje složenosti. Dok se softver mijenja, njegova struktura teži tome da postane
sve složenija. Da bi se očuvala jednostavnost strukture, potrebno je uložiti dodatni trud i
resurse.
3. Ograničena brzina unapređivanja. Količina novosti koju pojedino izdanje softvera može
donijeti otprilike je konstantna i karakteristična je za taj softver.
Prvi i drugi Lehmanov zakon dovoljno su razumljivi bez dodatnih komentara. Treći zakon
znači da ako u jednom izdanju unesemo previše novosti, unijet ćemo i mnogo novih grešaka,
pa će iduće izdanje morati biti posvećeno ispravljanju tih grešaka, a prosječna količina
novosti po izdanju vratit će se na svoju normalnu vrijednost. Konstanta iz trećeg zakona
određena je procesom polaznog razvoja softvera i ne može se naknadno popraviti. Znači, ako
je proces razvoja bio kvalitetniji, stvorit će se softver koji je pogodniji za održavanje, pa će
konstanta biti veća, to jest dopuštat će veću brzinu kasnijeg unapređivanja softvera.
5.1.3. Cijena održavanja softvera
Ukupna cijena održavanja softvera dostiže i prelazi cijenu njegovog polaznog razvoja. Cijenu
održavanja možemo smanjiti opet tako da povećamo kvalitetu originalnog razvojnog procesa.
Uz veću kvalitetu cijena razvoja će biti veća, ali će se stvoriti softver koji je jeftiniji za kasnije
održavanje. Ova ideja ilustrirana je slikom 5.1.

Manje
sustav 1 kvalitetan Skuplje održavanje
razvoj
Kvalitetniji razvoj Jeftinije

sustav 2 održavanje
cijena
Slika 5.1: utjecaj kvalitete razvojnog procesa na cijenu održavanja softvera.
U nastavku nastojimo popisati osnovne faktore koji utječu na cijenu održavanja.

1. Cjelovitost polazne specifikacije. Ukoliko odmah uključimo sve zahtjeve, kasnije će biti
manje perfekcijskog održavanja.
2. Dobrota oblikovanja. Dobar dizajn je jeftiniji za održavanje. Smatra se da su sa stanovišta
održavanja najbolji objektno-oblikovani sustavi, koji se sastoje od malih modula s jakom
unutrašnjom kohezijom i labavim vezama prema van.
3. Način implementacije. Kod u „strožem“ programskom jeziku poput Jave lakše se održava
nego kod u jeziku poput C-a. Strukturirani kod (if, while) sa smisleno imenovanim
varijablama razumljiviji je od kompaktnog koda s mnogo goto naredbi.
4. Stupanj verificiranosti. Dobro verificirani softver ima manje grešaka pa će zahtijevati
manje korekcijskog održavanja.
5. Stupanj dokumentiranosti. Uredna, dobro strukturirana i cjelovita dokumentacija olakšava
razumijevanje softvera te na taj način pojeftinjuje održavanje.
6. Način upravljanja konfiguracijom. Ukoliko se primjenjuju metode, alati i organizacijska
pravila upravljanja konfiguracijom, tada je održavanje na dugi rok jeftinije.
7. Starost softvera. Što je softver stariji, to je skuplji za održavanje, budući da mu se građa
degradirala, ovisan je o zastarjelim razvojnim alatima, a dokumentacija mu je postala
neažurna.
8. Svojstva aplikacijske domene. Ako je riječ o stabilnoj domeni gdje se poslovna pravila
rijetko mijenjaju, tada će se rijetko pojavljivati potreba za perfekcijskim održavanjem u
svrhu usklađivanja s novim pravilima.
9. Stabilnost razvojnog tima. Održavanje je jeftinije ako se njime bave originalni razvijači
softvera, jer oni ne moraju trošiti vrijeme na upoznavanje sa softverom.
10. Stabilnost platforme. Ako smo softver implementirali na platformi koja će još dugo biti
suvremena, tada neće trebati adaptacijsko održavanje.
Na prvih šest faktora moguće je utjecati tijekom originalnog razvojnog procesa.
5.1.4. Održavanje unutar agilnih metoda
Klasične metode razvoja prave jasnu razliku između originalnog razvoja softvera i njegovog
kasnijeg održavanja. Kod agilnih metoda zapravo nema jasne razlike. Naime.
 Razvoj se ionako promatra kao beskonačni niz iteracija u kojima se softver stalno mijenja
i usklađuje sa zahtjevima.
 Prve iteracije u tom nizu mogu se smatrati originalnim razvojem.
 Kasnije iteracije odgovaraju održavanju.
Robert Manger
Najpoznatija agilna metoda XP odlikuje se raznim osobinama koje smo opisali u odjeljku
1.3.3. Neke od tih osobina posebno su zanimljive i korisne sa stanovišta održavanja. Zaista:
 Korisničke priče, koje prvo služe za izražavanje početnih zahtjeva, kasnije mogu služiti za
opis zahtjeva za promjenama.
 Stalna uključenost korisnika u razvojni proces omogućuje da se ispravno odredi prioritet
promjena tijekom održavanja.
 Tehnika test-first development rezultira velikim brojem testova koji omogućuju
automatsku provjeru ispravnosti softvera nakon svake promjene tijekom održavanja.
 Reorganizacija programskog koda takozvanim refactoring-om može se shvatiti kao
preventivno održavanje, dakle kao investicija u kvalitetu softvera u svrhu njegovog lakšeg
kasnijeg mijenjanja.
U skladu s agilnim metodama, održavanje nije ništa drugo nego nastavak agilnog razvojnog
procesa. Ipak, poteškoće mogu nastupiti onda kad se originalnim razvojem softvera bavio
jedan tim, a održavanje se prepušta nekom drugom timu. Postoje dvije problematične
situacije.
1. Ako je razvojni tim koristio agilni pristup, a tim za održavanje nije tome vičan pa želi
raditi na klasičan način. Timu za održavanje tada će nedostajati detaljna dokumentacija
sustava.
2. Ako je razvojni tim koristio klasični pristup, no tim za održavanje preferira agilne metode.
Tada tim za održavanje mora potrošiti dosta vremena za razvoj nedostajućih
automatiziranih testova.
5.2. Upravljanje konfiguracijom
Tijekom svog životnog vijeka softverski sustav se održava. Kao rezultat tog održavanja
nastaju brojne verzije sustava. Svaka verzija može se promatrati kao nešto drukčija
konfiguracija sastavnih dijelova. Da bismo mogli izaći na kraj sa svim tim konfiguracijama,
potrebna nam je posebna aktivnost koji se naziva upravljanje konfiguracijom. U sljedećim
odjeljcima najprije ćemo opisati svrhu upravljanja konfiguracijom te njegovu podjelu na
podaktivnosti. Zatim ćemo detaljnije opisati svaku od podaktivnosti.
5.2.1. Svrha upravljanja konfiguracijom, podjela na podaktivnosti
Upravljanje konfiguracijom (configuration management) je organizirani skup pravila,

postupaka i alata kojima se kontrolira mijenjanje softvera i evidentiraju se njegove različite
verzije.
Upravljanje konfiguracijom potrebno je kod velikih sustava gdje postoji velik broj različitih
verzija koje su istovremeno u razvoju ili u uporabi. Pojedine verzije implementiraju pojedine
prijedloge za promjenama, popravke grešaka te prilagodbe različitim hardverima ili
operacijskim sustavima. Kad se ne bi služili odgovarajućim pravilima, postupcima i alatima,
lako bi nam se moglo desiti da izgubimo evidenciju o tome koje promjene ili dijelovi su bili
ugrađeni u koju verziju sustava. Također bi nam se moglo desiti da počnemo mijenjati krivu
verziju, ili da krivu verziju isporučimo korisnicima, ili da zaboravimo gdje je pohranjen
izvorni kod za neku određenu komponentu. Osim evidencije o promjenama i verzijama,
sustav za upravljanje konfiguracijom mora također omogućiti timski rad većeg broja (možda

dislociranih) programera, tako da oni mogu raditi svoje promjene bez da jedan drugom
smetaju.
Upravljanje konfiguracijom je aktivnost koja u sebi uključuje sljedeće četiri podaktivnosti.

1. Upravljanje promjenama. Prate se zahtjevi za promjenama koje su postavili korisnici.
Procjenjuju se troškovi i učinci tih promjena. Za svaku predloženu promjenu odlučuje se
da li će se ona implementirati i kada će se implementirati.
2. Upravljanje verzijama. Identificiraju se različite verzije sustava i njegovih dijelova.
Osigurava se da promjene koje rade različiti inženjeri ne interferiraju jedne s drugima,
nego rezultiraju različitim verzijama.
3. Gradnja sustava. Za određenu verziju sustava pronalaze se odgovarajuće verzije dijelova
programskog koda, podataka i biblioteka te se njihovim prevođenjem i spajanjem stvara
izvršivi program.
4. Upravljanje izdanjima. Vodi se evidencija o izdanjima, dakle verzijama sustava koje su
dane korisnicima na uporabu. Odlučuje se o objavi novog izdanja, pa se zatim softver
priprema za isporuku korisnicima.
Navedene četiri podaktivnosti u bliskoj su vezi i nemoguće ih je sasvim razdvojiti. To je

ilustrirano slikom 5.2. Na primjer, kao rezultat upravljanja promjenama nastaju nove verzije
sustava koje se evidentiraju unutar upravljanja verzijama. Da bi gradnja sustava ispravno
sagradila novu verziju, potrebne su joj informacije iz domene upravljanja verzijama koje kažu
od kojih se dijelova ta određena verzija sastoji. S obzirom da su izdanja sustava samo neke od
verzija, upravljanje izdanjima opet se oslanja na upravljanje verzijama.
Zahtjevi za
promjenama
Gradnja
sustava
Upravljanje
promjenama
Verzije Verzije Izdanja

dijelova sustava sustava
verzijama izdanjima
Slika 5.2: podaktivnosti unutar upravljanja konfiguracijom.
Rekli smo da se upravljanje konfiguracijom sastoji od pravila, postupaka i alata. Pravila i

postupci definiraju na primjer način postavljanja zahtjeva za promjenama, način odlučivanja o
promjenama, način baratanja s različitim verzijama sustava i njegovim dijelovima, ili način

Robert Manger
distribuiranja novih izdanja korisnicima. Alati služe na primjer za bilježenje i pretraživanje

zahtjeva za promjenama, pohranjivanje verzija svih dijelova, gradnju sustava iz tih dijelova,
identificiranje svih verzija i izdanja. Može biti riječ o jednostavnim alatima koji podržavaju
samo pojedini zadatak poput evidencije bug-ova, ili o složenim integriranim okolinama koje
podržavaju i objedinjuju sve podaktivnosti unutar upravljanja konfiguracijom.
Jasno je da je upravljanje konfiguracijom to važnije što je softverski sustav složeniji a njegove

verzije koje se istovremeno moraju održavati brojnije. Veliki sustavi s mnogo verzija u
pravilu nastaju primjenom klasičnih metoda razvoja. Kod malih sustava i agilnih metoda
potreba za strogo organiziranim upravljanjem konfiguracijom znatno je manja. Naime,
upravljanje se tada odvija na implicitan i neformalan način unutar samog agilnog procesa
razvoja i održavanja. Zaista, u skladu s metodom XP, korisnici su neposredno uključeni u
planiranje novih verzija, što predstavlja jedan vid neposrednog upravljanja promjenama.
Također, naglasak je na stalnom mijenjanju više-manje samo jedne (zadnje) verzije sustava,
što pojednostavnjuje upravljanje verzijama i gradnju sustava. Isto tako, korisnicima se
redovito svaki tjedan isporučuje nova verzija sustava, što znači da nema potrebe za zasebnim
upravljanjem izdanjima.
5.2.2. Upravljanje promjenama
Upravljanje promjenama treba osigurati da se promjene sustava odvijaju na kontrolirani način

te da se prioritet daje najhitnijim, najvažnijim i najisplativijim promjenama. Riječ je o procesu
koji se bavi cost/benefit analizom predloženih promjena, odobravanjem promjena koje su
svrsishodne te identificiranjem dijelova sustava koje treba promijeniti. Jedan od mogućih
modela tog procesa prikazan je na slici 5.3.
Upravljanje promjenama počinje kad korisnik ili član tima za podršku korisnicima pošalje
zahtjev za promjenom. To na primjer može biti izvještaj o bug-u s opisom simptoma ili
zahtjev za dodatnom funkcionalnošću. Zahtjev za promjenom obično se oblikuje
ispunjavanjem predviđenog obrasca koji je danas obično u elektroničkom obliku. Korisnik
ispunjava samo neka polja u tom obrascu, a u postupku obrade zahtjeva te donošenja odluke
odgovorne osobe ispunjavaju dodatna polja. Na taj način u svakom trenutku je vidljivo
trenutno stanje zahtjeva. Primjer djelomično ispunjenog obrasca vidi se na slici 5.4.
Nakon što je zahtjev bio poslan, odgovorna osoba iz tima za podršku korisnicima provjerava
je li on valjan. Provjera je potrebna zato što su mnogi zahtjevi takvi da ne zahtijevaju akciju.
Na primjer, isti bug možda je već bio prijavljen. Ili je možda riječ o nesporazumu o tome što
sustav treba raditi. Ili se zahtijeva funkcionalnost koja je već implementirana no korisnik to ne
zna. U svim ovakvim slučajevima, zahtjev se zatvara s time da se u obrazac prethodno upisuje
razlog zatvaranja. No ako je riječ o valjanom zahtjevu, on se stavlja na listu aktivnih
neriješenih zahtjeva koji čekaju daljnju analizu.
Sljedeća faza u obradi valjanog zahtjeva je tehnička procjena opsega i cijene tražene
promjene. To obično radi tim za razvoj i održavanje softvera. Proučava se utjecaj promjene na
ostatak sustava, to jest utvrđuje se koji sve dijelovi sustava su pogođeni promjenom. Ako
jedna promjena zahtijeva i niz promjena na drugim mjestima, to će povećati njenu cijenu.
Nakon tehničke procjene opsega i cijene, posebna grupa odgovornih osoba odlučuje je li
promjena svrsishodna i isplativa s poslovnog stanovišta. Ta grupa obično se naziva change

control board (CCB) i ona treba razmotriti sve netrivijalne promjene te odrediti prioritete.
Odobrene promjene vraćaju se timu za razvoj i održavanje, a odbijeni zahtjevi se zatvaraju i
arhiviraju. Sitne korekcije bug-ova automatski se odobravaju.
Važni faktori koje treba uzeti u obzir kod odobravanja ili neodobravanja neke promjene su
sljedeći.
 Posljedice neimplementiranja promjene.
 Korisnost od promjene.
 Broj korisnika kojih se tiče promjena.
 Cijena implementiranja promjene.
 Razdoblje proteklo od posljednjeg izdanja (ne valja prečesto).
Zadnji dio upravljanja promjenama sastoji se od implementacije same promjene unutar nove
verzije softvera. To radi tim za razvoj i održavanje. Čim softver nakon implementacije
uspješno prođe testove, zahtjev za promjenom se zatvara.
Korisnik Podrška korisnicima
Pošalji Provjeri
zahtjev zahtjev
nevaljan valjan
Zahtjevi za Zatvori Registriraj

promjenama zahtjev zahtjev
Razvoj i održavanje
Analiza
implemen-
Change tacije
Control Board
Poslovna Procjena
procjena opsega i
cijene
Odobravanje Promjena
promjene softvera
odob-
reno Testiranje
nije softvera
odobreno
Zatvori prošao
zahtjev nije
prošao
Zatvori
zahtjev
Slika 5.3: proces upravljanja promjenama.

Robert Manger
Zahtjev za promjenom
Projekt: Bolnički informacijski sustav

Broj zahtjeva: 328/12
Osoba koja traži promjenu: R. Manger
Datum postavljanja zahtjeva: 19.06.2012.
Opis tražene promjene: Na listi liječnika bolnice trebao bi bolje biti uočljiv status
liječnika (specijalist, kvalificirani liječnik, pripravnik).
Osoba koja je analizirala promjenu: M. Mauher

Datum analize: 21.06.2012.
Komponente koje promjena pogađa: DoctorListDisplay, StatusUpdater
Vezane komponente: EmployeeDatabase
Procjena opsega promjene: Može se relativno jednostavno implementirati
promjenom boje prikaza ovisno o status liječnika. Mora se dodati tablica koja
povezuje status s bojom. Nisu potrebne promjene u vezanim komponentama.
Procjena cijene promjene: 2 radna sata programera
Odluka CCB: Promjena se prihvaća i treba biti implementira u Izdanju 1.2

Datum odluke CCB: 26.06.2012
Prioritet promjene: Srednji
Osoba koja je implementirala promjenu:

Datum implementiranja:
Slika 5.4: obrazac za postavljanje zahtjeva za promjenom.
// Bolnicki informacijski sustav

//
// HOSPITAL/EmployeeDatabase
//
// Klasa: DoctorListDisplay
// Autor: M. Mauher
// Datum stvaranja: 13.11.2010
//
// Povijest promjena
// Verzija Programer Datum Promjena Razlog
// 1.0 Z. Culic 15.01.2011. Dodano zaglavlje Zahtjev 531/10
// 1.1 M. Mauher 03.09.2011. Novo polje Zahtjev 211/11
Slika 5.5: povijest promjena zapisana u obliku komentara.
Kad razvojni tim mijenja neki dio softvera (funkciju, klasu, modul), potrebno je o tome voditi
evidenciju. Uobičajeni način je pratiti povijest promjena u obliku standardiziranog komentara
na početku izvornog programskog koda tog dijela. Primjer takvog komentara vidljiv je na slici
5.5.

U agilnim metodama poput XP postupak upravljanja promjenama nije u tolikoj mjeri

formaliziran. Naime, prema pravilima XP korisnici su neposredno uključeni u odlučivanje
hoće li ili neće neka promjena biti implementirana te koji je prioritet pojedine promjene. Ipak,
promjene koje se tiču poboljšanja strukture samog softvera, takozvani refactoring, prepuštene
su isključivo programerima.
Upravljanje promjenama obično je podržano specijaliziranim softverskim alatom. Primjer

takvog alata je Bugzilla koja služi za prijavljivanje problema sa sustavima otvorenog koda.
Također, koriste se i složeniji no općenitiji alati za praćenje tijeka dokumenata (workflow
management tools).
5.2.3. Upravljanje verzijama
Upravljanje verzijama je središnja podaktivnost unutar upravljanja konfiguracijom na koju se

naslanjaju sve ostale podaktivnosti. Riječ je o evidentiranju i praćenju različitih verzija
dijelova sustava te različitih verzija samog sustava. Upravljanje verzijama također omogućuje
da više programera istovremeno mijenjaju isti softver a da pritom jedan drugom ne smetaju.
Slika 5.6 ilustrira tipičnu situaciju gdje je potrebno pratiti više verzija sustava i njegovih
dijelova. Slika također uvodi uobičajenu englesku terminologiju vezanu uz verzije sustava i
dijelova.
Codeline (A) Baseline – V1

A A1.1 A1.2 A1.3
A B1.2 C1.1
Codeline (B)
L1 L2 Ex1
B B1.1 B1.2 B1.3
Baseline – V2
Codeline (C)
C C1.1 C1.2 C1.3 A1.3 B1.2 C1.2
L1 L2 Ex2
Biblioteke i vanjske komponente
L1 L2 Ex1 Ex2
Mainline
Slika 5.6: dijelovi sustava obuhvaćeni upravljanjem verzijama.
Niz verzija izvornog koda gdje su kasnije verzije izvedene iz prethodnih verzija naziva se
codeline. Jedan codeline u pravilu odgovara jednom dijelu sustava (funkciji, klasi, modulu,
komponenti, … ), što znači da za jedan te isti dio imamo više verzija. Skup verzija dijelova i
pomoćnih biblioteka koje se mogu kombinirati u cjelovit sustav naziva se baseline. Jedan
baseline dakle odgovara jednoj verziji sustava. Na slici se vidi da različiti baseline-i koriste
različite verzije dijelova iz pojedinih codeline-a. Niz verzija sustava (dakle niz baseline-a)
razvijenih iz nekog polaznog baseline-a naziva se mainline.

Robert Manger
Baseline-i se dokumentiraju pomoću posebnog konfiguracijskog jezika. Riječ je o jeziku koji

omogućuje da se za zadanu verziju sustava eksplicitno specificiraju uključeni dijelovi i verzije
tih dijelova. Dokumentacija baseline-a je važna jer se pomoću nje naknadno može
reproducirati neka starija verzija sustava koja je možda bila isporučena nekim specifičnim
grupama korisnika.
Upravljanje verzijama ostvaruje se uz pomoć posebnih alata koji se nazivaju version

management tools ili version control systems. Najpoznatiji primjeri su CVS i Subversion [19,
20]. Alati za upravljanje verzijama obično imaju sljedeće mogućnosti.
 Identifikacija verzija i izdanja. Svakoj verziji se prilikom njenog pohranjivanja u
repozitorij alata pridružuje identifikator. Obično je riječ o imenu i brojevima. Na primjer,
ButtonManager 1.3 znači treća verzija u codeline-u 1 za klasu ButtonManager. Neki
alati dozvoljavaju i pridruživanje atributa verzijama te pretraživanje verzija po atributima.
 Kompaktna pohrana. Da bi se uštedilo na prostoru, verzije istog dijela softvera koje se
neznatno razlikuju pohranjuju se na kompaktan način. Umjesto da se čuva cjelovita kopija
svake verzije, čuva se samo zadnja verzija te liste razlika (takozvane delte) između
susjednih verzija. Primjenom tih razlika na zadnju verziju moguće je reproducirati bilo
koju od starijih verzija. Ideja je ilustrirana na slici 5.7.
 Bilježenje povijesti promjena. Bilježi se svaka promjena koju je netko napravio na nekom
dijelu softvera. Te bilješke mogu služiti za pronalaženje određene verzije. Ili se za
određeni dio softvera može ispisati povijest svih promjena.
 Podrška za nezavisni razvoj. Više programera može istovremeno raditi nad istim dijelom
softvera u isto vrijeme. Alat prati koji se dijelovi mijenjaju i osigurava da višestruke
promjene neće smetati jedna drugoj.
Datum stvaranja
Niz verzija
Verzija 1.0 Verzija 1.1 Verzija 1.2 Verzija 1.3
Izvorni tekst
D1 D2 D3 za V1.3
Način pohranjivanja
Slika 5.7: pohrana verzija pomoću delta.
Stariji alati za upravljanje verzijama najviše su pažnje posvećivali kompaktnoj pohrani. Kod
današnjih alata najvažnije je podržati nezavisni razvoj. Način na koji se omogućuje
nesmetani istovremeni rad više programera prikazan je na slici 5.8. Kao što vidimo, alat za
upravljanje verzijama sve verzije svih dijelova pohranjuje u zajednički repozitorij. Da bi
izvršio neke promjene, programer mora „izvaditi“ (check-out) dijelove iz repozitorija i
kopirati ih u svoj radni prostor. Nakon izvršenih promjena, programer „vraća“ (check-in)
promijenjene dijelove iz svog radnog prostora u repozitorij.

Radni prostor 1 Radni prostor 2
A B X Y
Alice Bob
C C
check_in check_out check_in check_out
A1.1 B1.1 C1.1 Y P Q
A B C Z X R
Sustav za upravljanje verzijama
Slika 5.8: rad s repozitorijem verzija dijelova softvera.
Slika 5.8. prikazuje konkretnu situaciju gdje dva programera Alice i Bob mijenjaju isti dio
softvera C. Te istovremene promjene neće jedna drugoj smetati. Naime, prilikom vraćanja C-a
u repozitorij, alat će ono što vraća Alice pretvoriti u novu verziju s novim identifikatorom, a
ono što vraća Bob u još noviju verziju s još novijim identifikatorom. Tako će na kraju u
repozitoriju postojati tri verzije za C (stara i dvije nove).
Codeline 2.1
<branch>
V2.1.1 V2.1.2
Codeline 2
<merge>
V2.0 V2.1 V2.4
<branch> V2.2 V2.3
V1.0 V1.1 V1.2

Codeline 1
Slika 5.9: grananje i spajanje verzija.
Posljedica ovakvog nezavisnog mijenjanja istog dijela softvera je da se codeline može granati.
Umjesto linearnog niza verzija može postojati više nezavisnih grana, kao što je prikazano na
slici 5.9. U nekim situacijama potrebno je napraviti naknadno spajanje grana, to jest stvoriti
novu verziju koja uključuje sve promjene. Na slici 5.9, vidi se da je verzija 2.4 dobivena je
kombiniranjem verzija 2.1.2 i 2.3. Spajanje se obično ne može napraviti sasvim automatski
već programer mora ručno prilagoditi obje verzije da bi ih učinio kompatibilnima.

Robert Manger
5.2.4. Gradnja sustava
Gradnja sustava je proces prevođenja i povezivanja dijelova sustava, pomoćnih biblioteka,

konfiguracijskih datoteka i tako dalje. Kao rezultat, nastaje cjeloviti izvršivi program koji se
može pokrenuti na računalu. Alat za gradnju sustava treba biti u stanju sagraditi bilo koju od
razvijenih verzija sustava, i u tu svrhu on mora usko surađivati s alatom za upravljanje
verzijama. Naime, proces gradnje zahtijeva da se iz repozitorija alata za upravljanje verzijama
izvadi baš točno odgovarajuća verzija svakog od dijelova sustava. Pritom se za pronalaženje
tih verzija koristi ista specifikacija pisana u konfiguracijskom jeziku koje je prije služila za
opis i identifikaciju odgovarajućeg baseline-a. Suradnja alata za gradnju i alata za upravljanje
verzijama prikazana je na slici 5.10.
Razvojni sustav Ciljni sustav

Razvojni Izvršivi
alati sustav
Privatni Ciljna
radni prostor platforma
check_in
check_out
(co) Sustav za Poslužitelj
co
upravljanje za gradnju
verzijama
Upravljanje verzijama i gradnja
Slika 5.10: suradnja alata za gradnju sustava i alata za upravljanje verzijama.
Kao što se vidi na slici 5.10, gradnja sustava je složeni proces budući da su u njega uključene
tri platforme.
1. Platforma za razvoj na kojoj programer mijenja i testira programski kod (obično radna
stanica).
2. Platforma na kojoj rade alat za upravljanje verzijama i alat za gradnju (obično mrežni
poslužitelj).
3. Ciljna platforma na kojoj će se izvršavati izgrađeni sustav.(na primjer mobitel ili procesor
u perilici rublja).
Rad alata za gradnju sustava detaljnije je prikazan na slici 5.11. Vidimo da za gradnju nije
dovoljan samo izvorni kod programa, nego su također potrebne biblioteke potprograma,
datoteke s podacima (na primjer datoteka s porukama o greškama), konfiguracijske datoteke,
zbirke testova i drugo. Također, moraju biti dostupni odgovarajući prevodioci (compiler-i) i
povezivači (linker-i). Jedan od prvih alata za gradnju sustava bio je UNIX-ov make, no po
današnjim kriterijima on je već zastario. Neki od novijih alata su Apache Ant, Microsoft
Build, Rational ClearMake i drugi.

Datoteke s Konfigu-
Izvršivi
izvornim racijske testovi
kodom datoteke
Automatizirani
Datoteke s Izvršivi ciljni
sustav za
podacima sustav
gradnju
Prevoditelji i Rezultati
Biblioteke
povezivači testova
Slika 5.11: rad alata za gradnju sustava.
Od suvremenog alata za gradnju očekuje se da ima sljedeće osobine.

 Rad sa skriptama za gradnju. Alat treba analizirati program koji se gradi, identificirati
ovisnosti među dijelovima te koristiti ili čak automatski generirati skriptu za gradnju. Alat
također treba podržati ručno stvaranje i editiranje skripte. Skriptni jezik trebao bi biti onaj
isti konfiguracijski jezik koji je prije služio za opis baseline-a.
 Suradnja s alatom za upravljanje verzijama. Alat za gradnju treba tražene verzije dijelova
softvera izvaditi iz repozitorija alata za upravljanje verzijama.
 Štedljivo prevođenje i povezivanje. Alat za gradnju treba prevesti sve dijelove sustava i
povezati ih s bibliotekama u izvršivi program. Pritom treba izbjeći nepotrebna prevođenja
dijelova koji se nisu mijenjali nakon zadnje gradnje.
 Automatsko testiranje. Neki od alata za gradnju mogu automatski pokrenuti testove
služeći se alatom za testiranje poput JUnit. Na taj način provjerava se je li sagrađeni
program zaista ispravan ili je bio oštećen promjenama programskog koda.
 Izvještavanje. Alat za gradnju treba stvoriti izvještaj o uspjehu ili neuspjehu postupka
gradnje te o izvršenim testovima.
 Stvaranje dokumentacije. Alat za gradnju mogao bi također biti u stanju automatski
generirati release notes za izgrađeni program te stranice s uputama.
Spomenuta mogućnost izbjegavanja nepotrebnog prevođenja zahtijeva ispravno uparivanje

izvornih i object datoteka. Dakle alat treba biti u stanju odrediti da li za zadanu izvornu
datoteku već postoji odgovarajuća (ažurna) object datoteka. Uparivanje se postiže tako da alat
izvornim i object datotekama pridruži signature koje su u odgovarajućoj vezi. Pritom postoje
dvije vrste signatura.
1. Vremenski žig (timestamp). Signatura bilo koje datoteke je datum i vrijeme njene zadnje
promjene. Ako je izvorna datoteka mijenjana nakon stvaranja object datoteke, tada se ona
mora ponovo prevesti, inače se object datoteka smatra ažurnom. Ovako je radio klasični
make.
2. Kontrolni zbroj (checksum) za izvorni kod. Signatura za object datoteku računa se kao
kontrolni zbroj koji uzima u obzir sve znakove iz izvorne datoteke. Smatra se da je object
datoteka usklađena s izvornom ako je njena signatura jednaka ponovo izračunatom
kontrolnom zbroju. Naime, bilo koja promjena izvornog koda izazvala bi promjenu
kontrolnog zbroja.
Robert Manger
Primijetimo da prva vrsta signature ne predviđa mogućnost da istovremeno postoji više

verzija izvornih datoteka, to jest gradnja je moguća samo za zadnju verziju sustava. Druga
vrsta signature podržava rad s više verzija izvornih datoteka i više verzija pripadnih object
datoteka. Naime object datoteku uparujemo s odgovarajućom izvornom datotekom na osnovu
podudaranja signature s kontrolnim zbrojem.
5.2.5. Upravljanje izdanjima
Kod klasičnih metoda održavanja, mnoge od nastalih verzija sustava zapravo se ne isporučuju
korisnicima budući da donose premalo promjena. Verzija koja se daje na uporabu korisnicima
naziva se izdanje. Postoje dvije vrste izdanja.
1. Veliko izdanje (major release). Donosi značajnu novu funkcionalnost. Obično se
naplaćuje korisnicima.
2. Malo izdanje (minor release). Popravlja greške iz prethodnog izdanja. Obično se šalje
korisnicima kao update bez naplate.
Upravljanje izdanjima uglavnom se sastoji od sljedećeg.

 Donošenje odluke koja verzija sustava će se pretvoriti u veliko odnosno malo izdanje.
 Priprema odabrane verzije za isporuku.
 Isporuka pripremljenog izdanja korisnicima.
Odluka o pretvaranju određene verzije sustava u izdanje važna je poslovna odluka. Nju
donose menadžeri softverske kuće uzimajući u obzir sljedeće faktore.
 Tehnička kvaliteta sustava. Ako u aktualnom izdanju postoje ozbiljne greške, potrebno je
hitno objaviti novo ispravljeno izdanje.
 Promjena u platformi. Ako se pojavilo novo izdanje operacijskog sustava, potrebno je i za
aplikacijski sustav stvoriti novo prilagođeno izdanje.
 Lehmanovi zakoni. Nakon izdanja s mnogo nove funkcionalnosti mora brzo slijediti
izdanje koje popravlja greške i poboljšava performanse.
 Držanje koraka s konkurencijom. Ako je konkurencija u svojem proizvodu uvela novu
funkcionalnost, moramo našim korisnicima što prije ponuditi istu funkcionalnost.
 Zahtjevi marketinga. Odjel marketinga može zahtijevati da se novo izdanje pojavi do
određenog datuma, na primjer do Božića.
 Korisnički zahtjevi. Kod sustava koji se rade po narudžbi, ako su korisnici postavili
određene zahtjeve za promjenama i platili za njih, tada se novo izdanje s implementiranim
promjenama mora isporučiti što prije.
 Ritam izdavanja. Izdanja ne smiju biti ni prečesta ni prerijetka. Ako su prečesta, korisnici
ih neće instalirati jer im to uzima vrijeme. Ako su prerijetka, korisnici bi mogli prijeći na
konkurentske proizvode.
Priprema izdanja za isporuku korisnicima sastoji se od opremanja samog softvera pratećim

sadržajima te eventualnog snimanja na medije i pakiranja u kutije. Izdanje sustava nikad nije
samo izvršivi program. Osim njega pojavljuju se sljedeći prateći sadržaji.
 Konfiguracijske datoteke koje definiraju kao se dijelovi sustava trebaju instalirati na
ciljanom hardveru ili operacijskom sustavu.
 Datoteke s podacima, na primjer datoteka s porukama o greškama za odabrani jezik.
 Program za instalaciju koji automatski instalira sustav na ciljanoj platformi.
 Elektronička ili papirnata dokumentacija za korisnike koja opisuje rad sa sustavom.
 Reklame i obavijesti o drugim proizvodima iste softverske kuće.
Novo izdanje sustava mora biti pripremljeno na dovoljno općenit način, tako da se može
instalirati u svim predvidivim situacijama. Na primjer, zamislimo da imamo ovakav scenarij.
1. Prvo izdanje sustava bilo je distribuirano korisnicima i koristilo se neko vrijeme.
2. Drugo izdanje stvorilo je potrebu za instalacijom nove datoteke s podacima.
3. Treće izdanje zahtijeva datoteku instaliranu s drugim izdanjem.
Tada postupak instalacije trećeg izdanja ne smije pretpostaviti da je datoteka s podacima već
instalirana. Naime, neki korisnici možda su preskočili drugo izdanje te s prvog odmah prelaze
na treće. Dakle, datoteka se mora ponovo distribuirati i instalirati s trećim izdanjem.
Isporuka novog izdanja korisnicima izvodi se na razne načine ovisno o vrsti softvera i vrsti
izdanja. Kompanije poput Microsoft, Adobe ili Apple velika izdanja svojih generičkih
proizvoda prodaju u kutijama preko tradicionalnih trgovačkih kanala, a mala izdanja
dostavljaju besplatno preko Interneta u obliku automatskih update-a. Isporuka specijaliziranih
softverskih produkata teže se može automatizirati budući da su takvi produkti kod svakog
korisnika konfigurirani na nešto drukčiji način.
5.3. Baštinjeni softver i njegovo mijenjanje
U velikim organizacijama postoje takozvani baštinjeni (legacy) sustavi. Riječ je o softveru

razvijenom tijekom 70-ih ili 80-ih godina 20. stoljeća koji je u tehnološkom smislu zastario.
Održavanje baštinjenih sustava izuzetno je skupo, koji put i nemoguće. S druge strane,
organizacija se ne može tek tako odreći tog softvera, budući da je on neophodan za njezino
svakodnevno funkcioniranje. Izlaz iz ove situacije nastoji se pronaći u jednokratnim
radikalnim zahvatima kao što su softversko reinženjerstvo odnosno arhitekturna
transformacija. Tim zahvatima baštinjeni softver se najprije mijenja u oblik koji se lakše može
razumjeti, dokumentirati i obrađivati suvremenim alatima. Nakon toga, softver se nastoji
osuvremeniti i učiniti pogodnijim za daljnje korištenje i održavanje. U sljedećim odjeljcima
najprije opisujemo osobine baštinjenog softvera, a zatim posebno govorimo o reinženjerstvu
odnosno o arhitekturnoj transformaciji.
5.3.1. Građa i osobine baštinjenog softvera
Baštinjeni sustav obično je bio razvijen prije 20-30 godina te je kasnije bio mijenjan. U
originalnom razvoju koristila se neka od funkcionalno-orijentiranih metoda za razvoj softvera.
Zato imamo sljedeće osobine.
 Sustav se sastoji od više programa i zajedničkih podataka koje koriste ti programi. Podaci
se čuvaju u datotekama ili pomoću (zastarjelog) sustava za upravljanje bazom podataka.
 Pojedini program unutar sustava oblikovan je funkcionalnim pristupom i sastoji se od
funkcija koje komuniciraju preko parametara i globalnih varijabli.
 U slučaju poslovnih primjena, sustav se obično svodi na „batch“ obradu ili obradu
transakcija. U oba slučaja, opća organizacija je s skladu s modelom „ulaz-obrada-izlaz“
koji je već bio spomenut u odjeljku 3.2.2.
 Sustav je implementiran u zastarjelom programskom jeziku koji današnji programeri ne
razumiju te za koji više nema prevoditelja.
 Dokumentacija sustava je dijelom izgubljena ili neažurna. U nekim slučajevima jedina
dokumentacija je izvorni programski kod. Ima slučajeva kad je čak i izvorni kod izgubljen
te jedino postoji izvršiva verzija programa.

Robert Manger
 Dugogodišnje održavanje pokvarilo je strukturu sustava, tako da ju je vrlo teško razumjeti.

 Izvorni kod pisan je s namjerom da se optimiziraju performanse ili smanje zahtjevi za
memorijom, a ne s namjerom da kod bude razumljiv. To stvara poteškoće današnjim
programerima koji su učili suvremene tehnike softverskog inženjerstva i nikad nisu vidjeli
takav stil programiranja.
5.3.2. Softversko reinženjerstvo
Cilj softverskog reinženjerstva je da se poboljša struktura sustava te da se ona dovede u oblik

koji se može lakše razumjeti. Očekuje se da će se na taj način smanjiti cijena daljnjeg
održavanja sustava. Razlika između „običnog“ softverskog inženjerstva i reinženjerstva vidi
se na slici 5.12.
Specifikacija Oblikovanje i Novi sustav obično softversko

sustava implementacija inženjerstvo
Bolje
Postojeći Razumijevanje i strukturirani i softversko
sustav transformacija razumljiviji re-inženjerstvo
sustav
Slika 5.12: razlika između softverskog inženjerstva i reinženjerstva.
Reinženjerstvo uključuje sljedeće podaktivnosti.

 Prevođenje izvornog koda. Automatska (uglavnom) konverzija programa pisanog u
jednom (zastarjelom) programskom jeziku u drugi (suvremeni) jezik. Ovaj zahvat je
nužan ukoliko za zastarjeli jezik više nema prevoditelja ili ako ga mladi programeri ne
razumiju.
 Reverzno inženjerstvo. To je proces reproduciranja dizajna i specifikacije sustava na
osnovu njegovog programskog koda. Potrebno je ukoliko je originalna dokumentacija
izgubljena. Koriste se pomoćni alati, takozvani program-browser-i kojima se obavlja
„navigacija“ kroz kod, na primjer pronalaženje mjesta gdje se koristi određena varijabla, i
slično.
 Poboljšanje strukture programa. Uključuje na primjer zamjenu nestrukturiranih
kontrolnih konstrukcija poput goto s ekvivalentnim while petljama i if naredbama.
Postupak se može automatizirati. Nakon ovog zahvata, kod postaje uredniji i pogodniji za
daljnje održavanje.
 Modularizacija programa. Svodi se na reorganizaciju izvornog koda, tako da se dijelovi
koji su u međusobnoj vezi grupiraju zajedno. Nakon toga ti dijelovi postaju razumljiviji,
pa ih je lakše optimizirati, ili je lakše ukloniti redundanciju.
 Podatkovno reinženjerstvo. Potrebno je ukoliko programi na nekonzistentan ili zastarjeli
način upravljaju podacima. Uključuje na primjer modifikaciju svih programa tako da
umjesto vlastitih datoteka koriste zajedničku bazu podataka, ili na primjer prelazak sa
zastarjele (hijerarhijske) baze na suvremenu (relacijsku) bazu.
Mogući slijed podaktivnosti unutar reinženjerstva vidi se na slici 5.13.

Originalni Dokumentacija Modularizirani Originalni

program programa program podaci
Reverzno
inženjerstvo
Modularizacija Podatkovno
programa re-inženjerstvo
Prevođenje
izvornog koda
Poboljšanje
strukture
programa
Strukturirani Reorganizirani
program podaci
Slika 5.13: podaktivnosti unutar softverskog reinženjerstva.
Kao primjer poboljšanja strukture programa pogledajmo sliku 5.14. Riječ je o nestrukturiranoj
verziji kontrolera sustava za grijanje. Kod je gotovo nemoguće razumjeti zbog brojnih goto
naredbi – to je takozvana „špageti logika“. Nakon reinženjerskog zahvata, dobili smo znatno
razumljiviju verziju sa slike 5.15. Ovakav zahvat moguće je obaviti uz pomoć automatskog
alata, koji najprije konstruira dijagram toka kontrole originalne „goto“ verzije, a zatim
realizira taj dijagram uz pomoć if i while naredbi.
Start: Get (Time-on, Time-off, Time, Setting, Temp,

Switch)
if Switch = off goto off
if Switch = on goto on
goto Cntrld
off: if Heating-status = on goto Sw-off
goto loop
on: if Heating-status = off goto Sw-on
goto loop
Cntrld: if Time = Time-on goto on
if Time = Time-off goto off
if Time < Time-on goto Start
if Time > Time-off goto Start
if Temp > Setting goto off
if Temp < Setting goto on
Sw-off: Heating-status := off
goto Switch
Sw-on: Heating-status := on
Switch: Switch-heating
Loop: goto Start
Slika 5.14: program sa „špageti“ logikom.

Robert Manger
Loop
--The Get statement finds values for the given variables from
-- The system's environment
Get (Time-on, Time-off, Time, Setting, Temp, Switch) ;
case Switch of
when On => if Heating-status = off then
Switch-heating; Heating-status := on ;
end if ;
when Off => if Heating-status = on then
Switch-heating; Heating-status := off ;
end if ;
when Controlled =>
if Time >= Time-on and Time <= Time-off then
if Temp > Setting and Heating-status = on then
Switch-heating; Heating-status := off ;
elsif Temp < Setting and Heating-status = off then
Switch-heating; Heating-status := on ;
end if ;
end if ;
end case ;
end loop ;
Slika 5.15: strukturirani program.
Program 1 Program 2 Program 3
Datoteka Datoteka Datoteka Datoteka Datoteka Datoteka

1 2 3 4 5 6
Program 4 Program 5 Program 6 Program 7
postaje
Program 3 Program 4 Program 5 Program 6
Program 2 Program 7
Sustav za
upravljanje
bazom Logički i
Program 1 podataka fizički modeli
podataka
Slika 5.16: migracija podataka.

Slika 5.16 ilustrira ideju o zamjeni datoteka sa zajedničkom bazom podataka. Programi u
polaznom sustavu koristili su klasične datoteke u kojima je postojala redundancija i
nekonzistentnost, i od kojih je svaka bila optimizirana za jednu aplikaciju a nepogodna za
druge. Nakon reinženjerskog zahvata imamo integriranu i konzistentnu bazu podataka koja
osim postojećih aplikacija može podjednako dobro podržati i razne buduće aplikacije. Za
ovakav zahvat potrebno je stvoriti logički model podataka, prepraviti sve programe tako da
pristupaju bazi umjesto datotekama te prebaciti podatke iz datoteka u bazu.
Softversko reinženjerstvo ima svoja ograničenja. Na primjer, sustav razvijen funkcionalnim

pristupom nije moguće pretvoriti u objektni sustav. Nakon reinženjerstva softver je pogodniji
za održavanje, no ipak se ne može tako dobro održavati kao novi softver. Podatkovno
reinženjerstvo može biti izuzetno skupo. Menadžment treba procijeniti da li se reinženjerstvo
uopće isplati, ili je bolje krenuti u razvoj sasvim novog sustava.
5.3.3. Arhitekturna transformacija
Nakon reinženjerstva, baštinjeni softver obično se podvrgava arhitekturnoj transformaciji te se

na taj način nastoji prilagoditi suvremenim tehnologijama. Tipični baštinjeni sustav je
centralizirani sustav za rad na mainframe računalu i tekstualnim terminalima, prikazan
na slici 5.17.
(terminali)
Baštinjeni (mainframe)
sustav
Slika 5.17: polazna arhitektura baštinjenog sustava.
Najčešći cilj arhitekturne transformacije je prelazak na arhitekturu klijent-poslužitelj, tako da

se transformirani sustav može instalirati na mrežu sastavljenu od osobnih i poslužiteljskih
računala u skladu sa slikom 5.18.
Prelazak na arhitekturu klijent-poslužitelj je poželjan iz sljedećih razloga.

 Cijena kupovine i održavanja hardvera. Distribuirana računalna mreža znatno je jeftinija
od mainframe računala ekvivalentne snage.
 Očekivanja u pogledu korisničkog sučelja. Tradicionalni mainframe sustavi daju sučelje s
tekstualnim formularima. No korisnici danas očekuju grafičko sučelje i laganu interakciju
sa sustavom. Grafičko sučelje zahtijeva znatno više lokalnog procesiranja i može se
efikasno implementirati jedino na klijentima kao što su osobna računala ili radne stanice.
 Distribuirani pristup sustavu. Organizacije su sve više fizički distribuirane, pa računalni
sustavi moraju biti dostupni s različitih vrsta opreme.

Robert Manger
(osobna računala na kojima radi

korisničko sučelje i možda još neki
dijelovi baštinjenog sustava)
(mreža)
Jezgra
baštinjenog (mrežni poslužitelj)
sustava
Slika 5.18: transformirana arhitektura baštinjenog sustava.
Kod planiranja arhitekturne transformacije, korisno je zamišljati da se naš polazni baštinjeni

sustav sastoji od slojeva, kao što je prikazano na slici 5.19. Pojedini slojevi obavljaju sljedeće
zadaće.
 Prezentacijski sloj bavi se prikazom i organizacijom formulara za unos ili prikaz
podataka.
 Sloj za validaciju podataka provjerava ispravnost podataka koje korisnik unosi u
formular.
 Sloj za kontrolu interakcije upravlja redoslijedom korisnikovih operacija te redoslijedom
formulara koji se prikazuju korisniku.
 Sloj s aplikacijskim servisima obavlja obradu podataka i računanje.
 Sloj s bazom podataka omogućuje pristup podacima koji su pohranjeni u bazi.
Prezentacija
Validacija podataka » korisničko sučelje
Kontrola interakcije
Aplikacijski servisi
Baza podataka
Slika 5.19: slojevi unutar baštinjenog sustava.
Postoje razni načini distribuiranja sustava, koji se razlikuju po načinu kako su slojevi
raspoređeni između poslužitelja i klijenata. Spektar mogućnosti ilustriran je slikom 5.20.
Slojevi koji su prebačeni na klijenta u pravilu se moraju mijenjati jer u protivnom nećemo
moći iskoristiti prednosti grafičkog sučelja. Zato distribucije gdje je sve veći broj slojeva
prebačen na klijenta postaju sve skuplje. Najjeftinije rješenje prebacuje samo prezentaciju na
klijenta, no time ne dobivamo mnogo jer se klijent tada ponaša kao emulator terminala,
pa sučelje i dalje slijedi logiku tekstualnih formulara. Najskuplje rješenje je da se sve osim
baze prebaci na klijenta - tada se poslužitelj svodi na poslužitelja baze podataka i možda se
može zamijeniti komercijalnim DBMS-om, čime bi se cijeli baštinjeni sustav izbacio iz

uporabe. Srednje rješenje je da na klijentu budu prezentacija, validacija i kontrola interakcije -

ta tri sloja zajedno mogu se na najbolji način zamijeniti novim grafičkim sučeljem koje više
neće slijediti logiku tekstualnih formulara.
Klijent: prezentacija,
Klijent: prezentacija, validacija, kontrola,
Klijent: prezentacija validacija, kontrola servisi
Poslužitelj: validacija, Poslužitelj: servisi, Poslužitelj:

kontrola, servisi, baza podataka baza podataka
baza podataka
(spektar mogućnosti) (sve veća cijena i napor)
Slika 5.20: načini raspoređivanja slojeva unutar baštinjenog sustava na klijente i poslužitelje.
Opisani načini distribuiranja sustava pretpostavljali su da polazni sustav ima jasno odijeljene
slojeve. U praksi to često nije slučaj, to jest slojeve nije moguće izdvojiti budući da su njihove
funkcije pomiješane u raznim modulima. Tada se pribjegava nešto drukčijem vidu
arhitekturne transformacije, koji je opisan slikom 5.21. Transformirana arhitektura tada se
sastoji od sljedeća tri dijela.
 Baštinjeni sustav, „zamrznut“ u svom originalnom obliku, instaliran na poslužiteljskom
računalu.
 Iznova razvijeno (grafičko) korisničko sučelje, koje radi kao klijent na osobnom računalu.
 Posebno razvijeni „wrapper“, koji prevodi zahtjeve klijenata u interakcije s
nepromijenjenim baštinjenim sustavom. Iz perspektive klijenta, wrapper izgleda kao
poslužitelj. Iz perspektive baštinjenog sustava, wrapper izgleda kao skup tekstualnih
terminala.
(osobna računala na kojima radi

grafičko korisničko sučelje)
(mreža)
Wrapper (middleware) (mrežni poslužitelj ili

osobno računalo)
Baštinjeni sustav (mrežni poslužitelj)
Slika 5.21: transformirana arhitektura baštinjenog sustava s wrapper-om.

Robert Manger
Spomenuta arhitektura s wrapper-om opet dozvoljava razne varijante, koje se razlikuju po

tehnologiji upotrjebljenoj na strani klijenta. Neke od varijanti su sljedeće.
 Klijent je off-the-shelf emulator terminala. Wrapper je tada nepotreban ili vrlo
jednostavan. Ovo je svakako najjeftinije no i najmanje kvalitetno rješenje. Naime, sučelje
je zadržalo tekstualni oblik, makar je uklopljeno u prozor unutar grafičkog sučelja.
 Klijent je standardni web preglednik poput Microsoft Internet Explorer. Wrapper je tada
web server poput Apache, nadopunjen servlet-ima ili CGI-bin skriptama koje
komuniciraju s baštinjenim sustavom i dinamički generiraju web stranice za klijenta. Ovo
je prilično jeftino rješenje gdje postoji velika neovisnost o klijentskoj platformi. Ipak, u
skladu s mogućnostima web preglednika, grafičko sučelje je relativno skromno.
 Klijent je program razvijen nekim od alata za razvoj PC aplikacija, koji koristi sve
mogućnosti grafičkog sučelja na osobnim računalima. Ovo rješenje je najkvalitetnije i
najskuplje te ima dodatnu manu da je vezano uz određenu klijentsku platformu poput
Microsoft Windows.

6. Ponovna upotreba
U dosadašnjim poglavljima govorili smo o procesu razvoja softvera. Implicitno smo
pretpostavljali da je riječ o novom softveru koji nastaje za točno određenu svrhu ili za
određenu grupu korisnika. U ovom poglavlju bavimo se pitanjem kako već razvijeni softver
ponovo upotrijebiti za neku drugu svrhu ili za neke druge korisnike.
Ideja ponovne upotrebe prisutna je 40-ak godina, još od pojave prvih viših programskih jezika
i biblioteka potprograma. Ideja je također utjelovljena u modelu razvoja softvera uz ponovnu
upotrebu, koji smo zajedno s njegovim prednostima i manama opisali u potpoglavlju 1.2.
Ipak, da bi ponovna upotreba zaista bila učinkovita i isplativa, potrebne su sofisticirane
tehnike. Takve tehnike počele su se razvijati tek početkom 21. stoljeća i u ovom trenutku
predstavljaju predmet intenzivnog istraživanja. Smatra se da je ponovna upotreba jedan od
najvažnijih aktualnih trendova softverskog inženjerstva. Očekuje se da će ona u bliskoj
budućnosti donijeti bitne pomake u produktivnosti razvoja softvera.
U sljedećem potpoglavlju najprije općenito govorimo o ponovnoj upotrebi. Zatim u idućem

potpoglavlju opisujemo nekoliko njezinih tradicionalnih oblika. Zadnja dva potpoglavlja
posvećena su dvjema tehnikama koje predstavljaju današnji state-of-the-art ponovne
upotrebe: riječ je o razvoju softvera zasnovanom na komponentama, odnosno o razvoju
zasnovanom na web servisima.
6.1. Općenito o ponovnoj upotrebi
U ovom potpoglavlju nabrojat ćemo razne tehnike koje su se s više ili manje uspjeha koristile
kao način ponovne upotrebe softvera. Također ćemo uočiti neka bitna svojstva po kojima se te
tehnike razlikuju. Raspravljat ćemo i o kriterijima za izbor pogodne tehnike ovisno o
konkretnoj situaciji.
6.1.1. Svojstva i oblici ponovne upotrebe
U posljednjih 30-ak godina razvijene su brojne metode i tehnike za ponovnu upotrebu. One se
razlikuju po mnogim svojim svojstvima, na primjer po veličini dijelova softvera koji se
ponovno upotrebljavaju, ili po samoj prirodi onoga što se upotrebljava.
S obzirom na veličinu dijelova, razlikujemo tri vrste ponovne upotrebe.

1. Ponovna upotreba cijelog sustava. Postojeći sustav se nakon odgovarajuće konfiguracije i
prilagodbe daje na uporabu novim korisnicima. Ili se ugradnjom manjih promjena stvara
nova verzija postojećeg sustava koja je prilagođena potrebama novih korisnika.
2. Ponovna upotreba dijela sustava. Dio postojećeg sustava srednje veličine ugrađuje se u
novi sustav. Također može biti riječ o upotrebi komponente koja je bila razvijena zato da
bi se ponovno upotrebljavala, ili o korištenju web servisa opće namjene.
3. Ponovna upotreba funkcije ili klase. Manji dio postojećeg sustava, na primjer jedna
funkcija ili klasa, ugrađuje se u novi sustav. Također može biti riječ o korištenju funkcije
ili klase iz biblioteke opće namjene, na primjer iz biblioteke matematičkih funkcija.

Robert Manger
S obzirom na prirodu onoga što se upotrebljava, razlikujemo dvije vrste ponovne upotrebe.
1. Ponovna upotreba programskog koda ili izvršivog programa. Već napisani softver
uključuje se u novi sustav. Na primjer, može biti riječ o korištenju biblioteke,
nasljeđivanju klase, uključivanju komponente, pozivu web servisa.
2. Ponovna upotreba modela, koncepta ili dizajnerskog rješenja. Na primjer, koristi se
poznati obrazac za oblikovanje, no na osnovi njega piše se vlastiti programski kod. Ili se u
skladu s modelom grafičkog razvoja koristi već postojeći UML dijagram te se iz njega
automatski generira programski kod.
6.1.2. Popis tehnika za ponovnu upotrebu
Dalje slijedi popis nekih od metoda i tehnika koje su se s više ili manje uspjeha koristile kao
oblik ponovne upotrebe.
1. Obrasci za oblikovanje. Bili su opisani u odjeljku 3.2.4. Riječ je o ponovnoj upotrebi
provjerenih generičkih rješenja za probleme oblikovanja koji se često pojavljuju u raznim
kontekstima.
2. Aplikacijski okviri. Riječ je o korištenju skupa apstraktnih ili konkretnih klasa koje treba
nadograditi ili proširiti da bi se od njih dobio željeni aplikacijski sustav. Detaljnije ćemo
obraditi u odjeljku 6.2.1.
3. Produktne linije. Mijenjanjem polazne generičke aplikacije nastaje niz sličnih konkretnih
aplikacija sa zajedničkom arhitekturom. Svaka aplikacija u nizu prilagođena je određenoj
grupi korisnika. Detaljnije ćemo obraditi u odjeljku 6.2.2.
4. Ponovna upotreba COTS produkata. Kratica COTS znači Commercial Off-the-Shelf.
Potrebe korisnika rješavaju se korištenjem pogodno konfiguriranih postojećih javno
dostupnih softverskih paketa, ili njihovim integriranjem. Primjeri COTS-a su: Microsoft
Excel, WRI Mathematica ili SAP. Detaljnije ćemo obraditi u odjeljku 6.2.3.
5. Razvoj zasnovan na komponentama. Sustav se razvija integriranjem gotovih komponenti,
dakle integriranjem dijelova koji su razvijeni baš za ponovnu upotrebu u skladu s
odgovarajućim standardima za komponente. Ovoj tehnici bit će posvećeno posebno
potpoglavlje 6.3.
6. Razvoj zasnovan na web servisima. Sustav se razvija povezivanjem servisa koji su javno
dostupni na webu i s kojima se može komunicirati preko odgovarajućih protokola. Ova
tehnika bit će tema potpoglavlja 6.4.
7. Ponovna upotreba baštinjenih sustava. Korištenjem odgovarajućih wrapper-a uspostavlja
se sučelje prema starom baštinjenom sustavu te se na taj način stari sustav ponovo koristi
u suvremenom okruženju. O ovoj tehnici već smo govorili u potpoglavlju 5.3.
8. Korištenje standardnih biblioteka. U novom sustavu koriste se funkcije ili klase iz neke
biblioteke, na primjer koristi se matematička funkcija, ili klasa koja enkapsulira
komunikaciju preko mreže, ili klasa za implementaciju rada sa stogom, i tako dalje. Ova
tehnika zapravo je najstariji oblik ponovne upotrebe i postoji već 40-ak godina.
9. Grafički razvoj softvera (model-driven engineering). O tome smo govorili u potpoglavlju
1.2. Softver se opisuje grafičkim modelom, na primjer skupom UML dijagrama.
Programski kod automatski se generira iz tog modela. Ovdje je riječ o ponovnoj upotrebi
znanja kako se pojedini element grafičkog modela treba pretvoriti u programski kod.
10. Korištenje generatora programa. U nekim usko specijaliziranim domenama postoje alati
koji iz specifikacije problema automatski generiraju odgovarajući program. Na primjer,
softveri za baze podataka za zadanu SQL tablicu mogu generirati aplikaciju koja
omogućuje ažuriranje i pretraživanje te tablice. Riječ je o ponovnom korištenju znanja o
domeni i programskih rješenja koja su ugrađena u alat.

6.1.3. Odabir tehnike za ponovnu upotrebu
Vidimo da postoji velik broj tehnika za ponovnu upotrebu. Postavlja se pitanje koja od njih je
najpogodnija u danoj situaciji. Pri traženju odgovora na to pitanje treba uzeti u obzir sljedeće
faktore.
 Rok za isporuku rješenja korisnicima. Ako softver treba razviti u vrlo kratkom roku, tada
treba pokušati s upotrebom COTS produkata, makar to možda neće dati rješenje koje je
sasvim u skladu sa zahtjevima.
 Očekivani životni vijek softvera. Ako se razvija sustav s dugim vijekom trajanja, tada se
treba koncentrirati na ostvarivanje uvjeta za lako održavanje, pa možda ipak treba pribjeći
samostalnom razvoju.
 Znanje i vještina razvojnog tima. Metode ponovne upotrebe prilično su složene, pa je
potrebno dosta vremena da bi se one savladale i počele efikasno koristiti. Ako razvojni tim
već ima iskustva s nekom određenom tehnikom, tada ta tehnika treba ući u uži izbor.
 Zahtjevi na pouzdanost ili na performanse. Ako se od sustava traži izuzetna pouzdanost ili
posebno dobre performanse, tada treba izbjegavati tehnike ponovne upotrebe gdje
nemamo pristup do izvornog koda. Naime, bez dostupnog programskog koda ne možemo
dati nikakve garancije za pouzdanost. Također, treba znati da automatski generatori
obično ne daju kod s dobrim performansama.
 Aplikacijska domena. U nekim domenama, na primjer kod upravljanja proizvodnjom ili u
knjižnicama ili u bankarstvu, već postoje dobri generički proizvodi koje možemo
konfigurirati ili nadograditi u skladu sa specifičnim potrebama. Nema velike potrebe za
samostalnim razvojem.
 Platforma na kojoj bi sustav trebao raditi. Razvoj zasnovan na komponentama obično je
prilagođen određenoj platformi. Na primjer, postoje sustavi komponenti koje rade unutar
Microsoftove .NET arhitekture ili sustavi komponenti za Java RMI. Dakle ako koristimo
komponente, vezani smo uz određeni operacijski sustav ili programski jezik.
Odluka o tome da li će se razvoj softvera zasnivati na ponovnoj upotrebi ili neće često je u
većoj mjeri menadžerska nego tehnička odluka. Menadžeri nerado pristaju na kompromise
koji su nužni da bi se mogli koristiti gotovi dijelovi. Također, menadžeri se boje rizika koje
donosi ponovna upotreba, posebno se boje gubitka kontrole nad evolucijom sustava.
6.2. Neki tradicionalni oblici ponovne upotrebe
U ovom potpoglavlju opisujemo oblike ponovne upotrebe softvera koji se koriste već
nekoliko desetljeća. Riječ je o aplikacijskim okvirima, produktnim linijama, odnosno upotrebi
COTS produkata. Svaki od ovih oblika obrađen je u posebnom odjeljku.
6.2.1. Aplikacijski okviri
Rani pobornici objektno-orijentiranog pristupa vjerovali su da je glavna prednost objekata u

tome što se oni lagano mogu ponovno upotrijebiti. Ipak, vrijeme je pokazalo da su pojedine
klase premale i suviše specijalizirane cjeline da bi omogućavale efikasnu ponovnu upotrebu.
Danas prevladava mišljenje da objektno-orijentirana ponovna upotreba postaje zaista isplativa
tek onda kad koristimo glomaznije strukture za ponovnu upotrebu. Takve strukture zovu se
aplikacijski okviri (application frameworks).
Robert Manger
Aplikacijski okvir je integrirani skup klasa koje međusobno surađuju i grade zajedničku
arhitekturu za porodicu sličnih aplikacija. Aplikacijski okvir možemo promatrati kao kostur
buduće aplikacije ili kao nedovršenu aplikaciju - da bi ga pretvorili u aplikaciju, moramo na
neki način dovršiti njegov kod.
Budući da je okvir implementiran kao skup konkretnih ili apstraktnih klasa, on je uvijek
vezan uz određeni objektno-orijentirani programski jezik. Postoje okviri za Javu, C#, C++ i
druge jezike. Kao izaberemo neki okvir, moramo dalje raditi u njegovom jeziku.
Aplikacijski okviri mogu se na sljedeći način podijeliti u vrste s obzirom na sadržaj ili
područje kojim se bave.
 Okviri za sistemsku infrastrukturu. Služe za razvoj infrastrukture poput mrežne
komunikacije, grafičkog korisničkog sučelja, ili „parsiranja“ komandi (prevođenja jezika).
 Okviri za middleware. Implementiraju standarde za komunikaciju komponenti i razmjenu
podataka između komponenti. Primjeri su Microsoft .NET ili Enterprise Java Beans.
Omogućuju razvoj zasnovan na komponentama o kojem ćemo govoriti u potpoglavlju 6.3.
 Okviri za specifične aplikacije. Odnose se na pojedine aplikacijske domene poput
financijskih sustava, knjižnica, zdravstvenih informacijskih sustava i tako dalje. Uključuju
znanje o dotičnoj domeni i implementiraju njene uobičajene operacije.
 Okviri za web aplikacije. Podržavaju razvoj web aplikacija s dinamičkim web stranicama.
Sadrže klase koje omogućuju laganu implementaciju uobičajenih funkcionalnosti kao što
su: prijavljivanje korisnika, kontrola pristupa korisnika sadržajima, generiranje
dinamičkih web stranica, povezivanje s bazom podataka, upravljanje sesijom, interakcija s
korisnikom (ajax).
Petlja
GUI događaja
Callback
Klase koje su specifične

za aplikaciju
Callback Callback
Baza Petlja Plat- Petlja

poda- događaja forma događaja
taka
Slika 6.1: inverzija kontrole u okvirima.

Makar je aplikacijski okvir dostupan u obliku izvornog programskog koda, programer koji ga
koristi u pravilu ne mijenja taj kod. Umjesto toga programer radi nešto od sljedećeg.
 On dodaje konkretne klase koje nasljeđuju apstraktne klase iz okvira.
 On piše glavni program koji na osnovu zadanih klasa najprije stvara sve potrebne objekte,
a zatim upravlja izvođenjem cijele aplikacije.
 On definira takozvane callback–ove: to su metode koje se automatski pozivaju kao
odgovor na događaje koje okvir prepoznaje.
Na primjer, ako koristimo okvir za grafičko korisničko sučelje, tada sam okvir već definira
klase koje odgovaraju elementima korisničkog sučelja, dakle prozorima, gumbima,
izbornicima i tako dalje. Naš posao je da napišemo program koji će stvoriti objekte iz tih klasa
i time sastaviti konkretno sučelje za našu aplikaciju. Također, naš posao je da napišemo
callback–ove koji će se aktivirati onda kad korisnik klikne mišem na određeni gumb ili onda
kad korisnik odabere određenu stavku s određenog izbornika. Dakle, naš posao je da okviru
dodamo funkcionalnost koja je specifična za našu aplikaciju. To je ilustrirano na slici 6.1.
6.2.2. Produktne linije
Produktna linija ili porodica aplikacija je skup srodnih aplikacija koje je u pravilu razvila ista
softverska kuća i koje imaju zajedničku arhitekturu. Svaki član porodice je specijaliziran u
nekom smislu. Zajednička jezgra svih članova ponovo se upotrebljava svaki put kad se pojavi
potreba za novim članom. Razvoj novog člana sastoji se od pisanja dodatnih dijelova ili od
prepravljanja postojećih dijelova u nekoj od starih aplikacija.
Postoji nekoliko tipova specijalizacije jedne aplikacije unutar produktne linije.

 Platformska specijalizacija. Razne verzije u biti iste aplikacije razvijaju se za različite
platforme (na primjer Microsoft Windows, Linux, i tako dalje). Funkcionalnost u svim
verzijama je ista, a promijenjeni su oni dijelovi koji komuniciraju s hardverom i
operacijskim sustavom.
 Konfiguracijska specijalizacija. Razne verzije aplikacije stvaraju se zato da bi rukovale s
različitim vanjskim uređajima. Na primjer, sustav za dojavljivanje požara postoji u više
verzija ovisno o tipu radio sustava. Funkcionalnost verzija varira s obzirom na drukčiju
funkcionalnost vanjskih uređaja.
 Funkcionalna specijalizacija. Razne verzije aplikacije stvaraju se za kupce s različitim
zahtjevima. Na primjer, informacijski sustav knjižnice modificira se za gradsku, odnosno
školsku, odnosno znanstvenu knjižnicu. Moguće je da će neki dijelovi biti promijenjeni te
da će znanstvena knjižnica imati dodatne dijelove koji se odnose na znanstvene časopise.
Kao primjer ponovne upotrebe softvera korištenjem produktne linije pogledajmo arhitekturu
sustava za upravljanje inventarom na slici 6.2. Riječ je o slojevitoj arhitekturi. Prati se
raspored nekih komada opreme unutar neke organizacije. Ukoliko je riječ o elektrani i
njezinim generatorima i transformatorima, tada oprema u pravilu ne mijenja svoju lokaciju.
Ukoliko isti sustav koristimo za praćenje opreme na fakultetu, morat ćemo dodati modul za
premještanje na primjer računala iz jednog laboratorija u drugi, pa ćemo na taj način dobiti
novog člana produktne linije. Slika 6.3 prikazuje značajnije promijenjenu verziju polazne
aplikacije koja ovaj put služi za raspoređivanje vatrogasnih vozila ili vozila hitne pomoći;
dodani su specifični moduli za planiranje rute vozila, za rad s kartama, za sučelje prema
komunikacijskom sustavu, i tako dalje. Baza podataka je podijeljena u tri dijela koji se odnose
na vozila, drugu opremu i karte.

Robert Manger
Interakcija
Korisničko sučelje
Upravljanje ulazom i izlazom

Autentikacija Upravljanje
Izvještavanje
korisnika upitima
Upravljanje inventarom
Praćenje Upravljanje Raspore-

pravilima za rad đivanje
inventara s inventarom inventara
Upravljanje bazom podataka

Upravljanje Baza podataka
transakcijama o inventaru
Slika 6.2: generička arhitektura produktne linije sustava za upravljanje inventarom.
Interakcija
Sučelje za
Sučelje za komunikacijski
operatora sustav
Upravljanje ulazom i izlazom

Autentikacija Upravljanje Generator Upravljanje
kartama i
operatora planiranje ruta izvještaja upitima
Upravljanje inventarom
Praćenje Bilježenje Raspo- Upravljanje Lociranje
statusa incidenata ređivanje opremom vozila
vozila vozila u vozilima
Upravljanje bazom podataka

Upravljanje Baza Baza Baza
transakcijama podataka o podataka o
vozilima opremi karata
Slika 6.3: arhitektura jednog člana produktne linije - raspoređivanje vatrogasnih vozila.
Slika 6.4 prikazuje korake u razvoju novog člana produktne linije. Ponovno pregovaranje o
zahtjevima je poželjno zato da bi se minimizirale promjene u postojećoj (najsličnijoj) verziji
aplikacije. Ukoliko korisnik pristane na kompromise u zahtjevima, tada će nova verzija biti
jeftinija i brže isporučena.

Izaberi Ponovo
Otkrij zahtjeve najsličnijeg pregovaraj s
korisnika člana produktne korisnikom o
linije zahtjevima
Isporuči novog Promijeni

člana produktne postojećeg člana
linije produktne linije
Slika 6.4: razvoj novog člana produktne linije.
Uzastopni razvoj novih članova produktne linije dovest će do postepenog kvarenja polazne
arhitekture. U jednom trenutku softverska kuća mora se odlučiti na razvoj nove (bolje)
generičke aplikacije koja će služiti kao polazište za novu produktnu liniju. Ta nova aplikacija
ne nasljeđuje programski kod nego samo znanje i iskustvo stečeno kroz razvoj polazne linije.
Produktne linije i aplikacijski okviri očito imaju mnogo zajedničkih svojstava. Obje tehnike
podržavaju zajedničku arhitekturu za skup sličnih aplikacija, obje zahtijevaju dodatno
programiranje da bi se stvorila nova verzija sustava. No postoje i sljedeće razlike između ta
dva pristupa.
 Aplikacijski okviri oslanjaju se na objektno-orijentirane mehanizme poput nasljeđivanja i
polimorfizma. U pravilu, programski kod samog okvira nikad se ne mijenja. Produktne
linije ne moraju biti pisane u objektno-orijentiranom jeziku. Njihov programski kod se
mijenja svaki put kad stvaramo novu verziju.
 Aplikacijski okviri prvenstveno su usmjereni na općenitu tehničku podršku, na primjer na
izradu bilo kakve web aplikacije. Produktne linije obično uključuju znanje o određenoj
domeni. Na primjer, mogla bi postojati programska linija za izradu web aplikacija iz
domene knjižničarstva.
 Produktne linije često kontroliraju određenu opremu. Na primjer, mogla bi postojati
programska linija driver-a za porodicu pisača. To znači da produktna linija sadrži sučelja
prema hardveru. Aplikacijski okviri obično su softverski orijentirani i oni u pravilu
izbjegavaju ovisnost o hardveru.
 Produktna linija zapravo je porodica od nekoliko sličnih konkretnih aplikacija. Kad
pomoću produktne linije stvaramo novu aplikaciju, polazna točka nam je najsličnija
konkretna aplikacija iz porodice. S druge strane, aplikacijski okvir čini samo jedna
generička (nedovršena) aplikacija. Kad pomoću aplikacijskog okvira stvaramo novu
aplikaciju, krećemo od te jedne generičke i nadograđujemo je.
6.2.3. Upotreba COTS produkata
Kratica COTS znači commercial off-the-shelf. COTS produkt je javno dostupni softverski
sustav koje se može kupiti u dućanu ili dobiti besplatno i koji se može prilagoditi potrebama
raznih korisnika bez da se mijenja njegov izvorni programski kod. Primjeri COTS produkata
su: Microsoft Word ili Excel, WRI Mathematica, ERP sustavi poput SAP, DBMS-i poput
Oracle ili MySQL.

Robert Manger
COTS produkti se upotrebljavaju tako da se prilagode određenoj grupi korisnika. Prilagodba

se obavlja pomoću ugrađenih mehanizama za konfiguraciju. Dakle, novi „sustav“ stvara se
bez ikakvog programiranja konfiguriranjem gotovog softvera opće namjene. Na primjer, ako
korisnicima treba baza podataka, tada nije potrebno razvijati novi sustav za rad s tom bazom
podataka. Umjesto toga, instalira se DBMS Oracle ili MySQL. Konfiguracija DBMS-a
obavlja se zadavanjem logičke sheme konkretne baze, dakle definiranjem SQL tablica. Nakon
toga, općeniti DBMS spreman je za rad sa sasvim konkretnom bazom.
Upotreba COTS produkata prilično je popularan način korištenja softvera i u velikim i u

malim kompanijama. Riječ je o načinu ponovne upotrebe gdje dijelovi softvera koji se
ponovno upotrebljavaju imaju najveću moguću veličinu. Zahvaljujući toj veličini dijelova, sve
prednosti i mane ponovne upotrebe poprimaju ekstremne vrijednosti. Na primjer.
 Razvoj softverskih rješenja je izrazito brz jer nema nikakvog programiranja.
 No zahtjevi se obično moraju jako prilagoditi da bi se uskladili s mogućnostima COTS
produkta. To može dovesti do neželjenih promjena postojećih poslovnih procesa.
Sustavi dobiveni upotrebom COTS produkata dijele se na sljedeće dvije vrste s obzirom na
način upotrebe samog COTS produkta.
1. Sustavi sa COTS rješenjem. Sastoje se od po jednog velikog COTS produkta koji je
konfiguriran u skladu s korisnikovim zahtjevima.
2. Sustavi dobiveni integracijom COTS produkata. Sastoje se od više COTS produkata,
možda od različitih proizvođača, koji su povezani u cjelinu obično preko dodatno
razvijenih adaptera.
Kod razvoja sustava sa COTS rješenjem naglasak je na konfiguriranju postojećeg softvera.

Tipičan primjer takve vrste je razvoj takozvanog enterprise resource planning (ERP) sustava
pomoću COTS produkta SAP. ERP sustav služi za vođenje proizvodnje, naručivanja dijelova
i isporuke proizvoda u velikoj proizvodnoj kompaniji. SAP je sam po sebi vrlo složen produkt
koji se sastoji od velikog broja modula. Konfiguracija SAP-a za određenu kompaniju svodi se
na odabir modula koji su potrebni toj kompaniji te na pisanje brojnih konfiguracijskih
datoteka koje određuju detalje u poslovnim procesima, poslovna pravila, strukturu i
organizaciju baze podataka, izgled ulaznih formulara odnosno izlaznih izvještaja, interakcije s
vanjskim sustavima. Konfiguracija SAP-a vrlo je složena i njome se ne bave korisnici nego
SAP-ovi stručnjaci. Funkcioniranje i održavanje sustava također je briga SAP-ovih
stručnjaka. Ideja ERP sustava ilustrirana je slikom 6.5.
Upravljanje Isporuka Upravljanje

Nabava odnosima s
sirovina proizvodnjom proizvoda
kupcima
Procesi Procesi Procesi Procesi
Poslovna pravila
Baza podataka
Slika 6.5: arhitektura ERP sustava.

Integracija COTS produkata potrebna je onda kad ni jedan od tih produkata ne pruža svu
potrebnu funkcionalnost, ili onda kad novi COTS produkt želimo integrirati s postojećim
sustavima. Kod razvoja sustava koji uključuju integraciju COTS produkata naglasak je na
samoj integraciji. To obično uključuje pisanje dodatnih komada softvera, takozvanih adaptera,
koji izlaze jednog COTS produkta pretvaraju u ulaze za drugi COTS produkt i obratno.
Također je osjetljivo pitanje izbora COTS produkta i izbora funkcija koje će se zaista koristiti
u pojedinom produktu (obično postoje preklapanja u funkcionalnosti).
Kao primjer integracije COTS produkata, zamislimo neku veliku organizaciju koja želi
stvoriti sustav za objedinjenu nabavu. Taj sustav treba omogućiti zaposlenicima da naručuju
uredski materijal i druge potrepštine sa svog stolnog računala. Objedinjavanjem svih narudžbi
i centraliziranom kupovinom kod dobavljača koji daje najveći količinski popust ostvarit će se
značajna ušteda. Kompanija već ima baštinjeni sustav za naručivanje koji se koristi u
središnjem uredu za nabavu
Klijent
Web E-mail klijent

preglednik
Poslužitelj
E-commerce Sustav ureda

sustav Adapter za nabavu
E-mail Adapter
sustav
Slika 6.6: sustav za objedinjenu nabavu realiziran integracijom COTS produkata.
Da bi se stvorio novi sustav, baštinjeni sustav se integrira s web aplikacijom za e-commerce te

s e-mail sustavom koji će omogućiti komunikaciju sa zaposlenicima. Struktura konačnog
sustava za nabavu ilustrirana je slikom 6.6. Vidimo da se nekoliko COTS produkata integrira
s baštinjenim sustavom preko adaptera.
6.3. Razvoj softvera zasnovan na komponentama
U ovom potpoglavlju bavimo se danas aktualnom i po svemu sudeći vrlo efikasnom tehnikom
ponovne upotrebe koja se zasniva na takozvanim komponentama. Najprije govorimo općenito
o komponentama i njihovom korištenju. Zatim opisujemo dva razvojna procesa koji su vezani
uz komponente: prvi se odnosi na razvoj samih komponenti koje će se ponovo upotrebljavati,
a drugi na razvoj novih aplikacija uz upotrebu komponenti. Na kraju proučavamo postupke
međusobnog spajanja komponenti u svrhu izgradnje složenijih podsustava odnosno cijelih
sustava.

Robert Manger
6.3.1. Komponente i njihovo korištenje
Tehnika razvoja softvera zasnovana na komponentama pojavila se u kasnim 90-im godinama

20. stoljeća, a razvija se i danas. Slično kao aplikacijski okviri, ta tehnika je nastala kao
rezultat frustracije činjenicom da objektni pristup sam po sebi nije doveo do intenzivne
ponovne upotrebe. Naime, uvidjelo se da su za rentabilnu ponovnu upotrebu neophodne veće i
zatvorenije cjeline od objekata. Komponente [21] predstavljaju jednu vrstu takvih cjelina.
Komponentu treba promatrati kao samostalnog pružatelja usluga. Kad naš sustav treba neku
uslugu, on poziva komponentu preko njezinog javnog sučelja, ne brinući se o tome gdje i
kako se ona izvršava.
Razni autori daju donekle različite definicije komponente, no svi se otprilike slažu da ona
mora imati sljedeća svojstva.
 Komponenta je nezavisna izvršiva cjelina. Nije nam dostupan njezin izvorni kod, ona se
ne kompilira zajedno s ostalim dijelovima našeg sustava, već se instalira u binarnom
obliku i pokreće kao zasebni proces.
 Komponenta objavljuje svoje sučelje. Sve interakcije s njom odvijaju se kroz to sučelje.
Samo sučelje zadaje se u obliku parametriziranih operacija, slično kao kod objekta.
 Sučelje komponente sastoji se od dva dijela.
- Ponuđeno sučelje (provides interface) definira usluge koje komponenta pruža.
- Traženo sučelje (requires interface) definira koje usluge moraju biti dostupne samoj
komponenti u sustavu koji je koristi. Ako tih usluga nema, komponenta neće moći
raditi.
 Komponenta se ponaša kao crna kutija. Nije nam vidljivo njezino unutrašnje stanje. Ne
znamo na koji način ona implementira svoje operacije. U pravilu je nevažno u kojem
programskom jeziku je ona razvijena.
 Komponenta je zamjenjiva cjelina. Dakle ako imamo dvije komponente koje pružaju iste
usluge preko istih sučelja, tada jednu od njih možemo zamijeniti drugom.
 Svaka komponenta pokorava se jednom od standardnih modela za komponente. Taj model
određuje pravila kako se zadaju sučelja za komponente, dakle pravila vezana uz imena
operacija, parametre, tipove podataka, iznimke, metapodatke.
 Komponente se međusobno integriraju pomoću posebnog softvera koji se zove
middleware. Na svakom stroju gdje je instalirana komponenta mora biti instaliran i
middleware. Bez obzira nalaze li se na istom ili na različitim strojevima, dvije
komponente međusobno komuniciraju posredstvom middleware-a. Svaki middleware
implementira jedan određeni model za komponente.
 Komponenta mora biti detaljno dokumentirana, tako da njeni potencijalni korisnicu mogu
odlučiti da li ona ispunjava njihove potrebe. Dokumentacija u prvom redu mora definirati
sintaksu i semantiku svih operacija iz sučelja.
Slika 6.7. prikazuje komponentu koja pruža usluge štampanja. Ponuđeno sučelje sastoji se od
sljedećih operacija: slanje dokumenta na štampanje na zadanom štampaču, uvid u stanje reda
dokumenata koji čekaju štampanje na zadanom štampaču, registriranje ili deregistriranje
štampača, prebacivanje dokumenta iz reda jednog u red drugog štampača, izbacivanje
dokumenta iz reda. Traženo sučelje sastoji se od operacije koja daje datoteku s opisom
određenog štampača te od operacije koja prosljeđuje naredbu određenom štampaču. Očito je
da je opisana komponenta ponovo upotrebljiva: ona se može uključiti u bilo koji sustav koji
treba usluge štampanja.

Traženo sučelje Ponuđeno sučelje

Print
GetQueue
GetPDfile
Remove
PrintService
PrinterInt Transfer
Register
Unregister
Slika 6.7: komponenta koja upravlja štampanjem dokumenata na nekoliko štampača.
Slika 6.7 ujedno predstavlja i jednostavni primjer UML component dijagrama. Takvi
dijagrami služe za prikaz građe sustava sastavljenog od komponenti. Vidimo da se po UML-
ovim pravilima komponenta crta kao pravokutnik s odgovarajućom ikonom. Ponuđeno
sučelje obično se crta kao niz „utikača“, a traženo sučelje kao niz „utičnica“. Na složenijim
component dijagramima pojavljuje se više komponenti. Situacija kad jedna komponenta daje
uslugu a druga je prima crta se tako da odgovarajući utikač prve komponente bude utaknut u
odgovarajuću utičnicu druge komponente. Primjeri takvih složenijih dijagrama pojavit će se
na slikama 6.12 – 6.17.
Iz svega što smo do sada rekli, jasno je da korištenje komponenti donosi bitne promjene u
načinu kako se softver oblikuje, implementira i kasnije pokreće. Da bi neki sustav uspješno
realizirali pomoću komponenti, nužno je da su ispunjeni sljedeći uvjeti.
 Sam sustav mora biti oblikovan kao skup komponenti koje međusobno komuniciraju,
dakle njegova građa treba biti prikazana pomoću UML component dijagrama.
 Moramo imati dostupne odgovarajuće komponente koje imaju traženu funkcionalnost i
koje se mogu instalirati na naša računala.
 Sve odabrane komponente moraju biti kompatibilne u smislu da se pokoravaju istom
modelu, dakle mogu raditi pod kontrolom istog middleware-a.
 Na našim računalima moramo imati instaliran middleware koji implementira taj odabrani
model i koji je u stanju integrirati sve odabrane komponente u cjelinu.
Vidimo da nam za rad s komponentama treba posebna softverska podrška, takozvani

middleware. Riječ je o istoj vrsti softvera koju smo već spominjali u odjeljku 3.4.3 kad smo
govorili o arhitekturi s distribuiranim objektima. Zaista, osim što služe za ponovnu upotrebu,
komponente se mogu promatrati i ako sredstvo za izgradnju distribuiranih sustava. Ideja o
komponentama zapravo je proširenje ideje o distribuiranim objektima.
Kao konkretan primjer middleware-a mogli bismo navesti bilo koji alat koji implementira
otvoreni standard CORBA. No danas se mnogo više koriste „proprietary” softveri poput
Microsoftovog .NET ili Sunovog Enterprise Java Beans.
Rekli smo da je osnovna zadaća middleware-a da omogući međusobnu komunikaciju

komponenti, bez obzira nalaze li se one na istom ili na različitim računalima. No današnji
middleware-i obično omogućuju i više od toga. Slika 6.8 prikazuje uobičajene usluge koje
middleware pruža.

Robert Manger
Servisi za podršku
Upravljanje Upravljanje Upravljanje

komponentama transakcijama resursima
Istovremeni rad Perzistentnost Sigurnost
Platformski servisi
Adresiranje Definicija Upravljanje Komunikacija

sučelja iznimkama komponenti
Slika 6.8: usluge koje pruža middleware.
U donjem dijelu slike 6.8 nalaze se obavezne usluge koje se tiču interoperabilnosti
komponenti u distribuiranoj okolini. Gornji dio slike navodi dodatne usluge koje mogu biti od
koristi komponentama i koje olakšavaju razvoj aplikacija. Na primjer, mnogi middleware-i
pružaju usluge vezane uz sigurnost. Ako neka komponenta zahtijeva autentikaciju korisnika,
ona ne mora sama implementirati postupak autentikacije, već se može osloniti na mehanizam
iz middleware-a.
6.3.2. Softverski procesi zasnovani na komponentama
Pojavom komponenti nastala je posebna vrsta softverskog inženjerstva, takozvano softversko

inženjerstvo zasnovano na komponentama (component based software engineering – CBSE).
Unutar CBSE pojavljuje se nekoliko specifičnih procesa koji su prikazani na slici 6.9.
CBSE za
CBSE uz
ponovnu
ponovnu upotrebu
upotrebu
Nabava
komponenti
Certificiranje Upravljanje Vanjski izvor

komponenti komponentama
Repozitorij
komponenti
Slika 6.9: procesi unutar CBSE.

Kao što vidimo na slici 6.9, unutar CBSE postoje dva glavna i tri pomoćna procesa. Glavni
procesi su sljedeći.
 Razvoj za ponovnu upotrebu. Cilj je stvoriti same komponente koje će se kasnije ponovo
upotrebljavati. Proces se obično sastoji od generalizacije postojećih komponenti.
 Razvoj uz ponovnu upotrebu. Cilj je stvoriti novu aplikaciju korištenjem postojećih
komponenti.
Pomoćni procesi su sljedeći.
 Nabava komponenti. Riječ je o pronalaženju pogodnih komponenti koje će služiti za
ponovnu upotrebu ili za pretvorbu u ponovno-upotrebljivu komponentu. Može se raditi o
pristupu lokalno razvijenim komponentama ili o pretraživanju komponenti iz nekog
vanjskog izvora.
 Upravljanje komponentama. Proces se bavi evidencijom ponovo upotrebljivih
komponenti. Osigurava se da su one ispravno katalogizirane i dostupne za ponovnu
upotrebu.
 Certificiranje komponenti. Riječ je o verifikaciji komponente i izdavanju potvrde da ona
zaista zadovoljava svoju specifikaciju.
Komponente koje neka organizacija održava obično su pohranjene u repozitoriju. On uz same
komponente također sprema i informacije o njihovom korištenju.
U nastavku ovog odjeljka, reći ćemo nešto više o CBSE za ponovnu upotrebu. Početkom 20.
stoljeća vjerovalo se da će se CBSE za ponovnu upotrebu brzo razviti u veliku industriju.
Slično kao što u svijetu hardvera postoje kompanije koje proizvode samo hardverske
komponente (procesore, memorijske čipove, matične ploče, ... ), očekivalo se da će se pojaviti
softverske kuće koje žive isključivo od razvoja i prodaje softverskih komponenti. No to se za
sada nije ostvarilo. Umjesto toga, CBSE za ponovnu upotrebu zaživio je unutar velikih
kompanija kao dio njihove unutrašnje racionalizacije poslovanja. Dakle, velike kompanije
bave se pretvorbom komponenti iz svojih starih projekata u komponente koje su pogodne za
ponovnu upotrebu u idućim projektima.
Komponenta razvijena unutar kompanije u sklopu jednog projekta obično nije odmah
ponovno upotrebljiva. Naime, ona često sadrži specifičnosti aplikacije u kojoj je nastala. Da
bi se takva komponenta učinila ponovno upotrebljivom, ona se mora doraditi i proširiti te
postati u većoj mjeri generička. Pitanje je da li se takva prepravka uopće isplati. Pokazuje se
da je prepravka isplativa ukoliko komponenta implementira neku stabilnu apstrakciju dotične
aplikacijske domene, dakle nešto što se sporo mijenja a uvijek iznova koristi (na primjer rad s
bankovnim računima u bankarstvu, katalogizacija knjiga u bibliotekarstvu, ... ).
Promjene koje se u postojećoj komponenti moraju učiniti da bi ona postala ponovo

upotrebljiva sastoje se od sljedećeg.
 Izbacivanje operacija koje u specifične za jednu aplikaciju.
 Promjena imena operacija i uvođenje novih parametara, tako da operacije postanu
općenitije.
 Dodavanje novih operacija tako da se postigne cjelovitost podrške.
 Ujednačavanje načina kako operacije postupaju u slučaju iznimki.
 Dodavanje sučelja za konfiguraciju koje omogućuje da se komponenta rekonfigurira.
 Integracija što većeg broja usluga koje je komponenta do sada dobivala preko svog
traženog sučelja, u svrhu njene veće neovisnosti.
 Izrada dokumentacije koja opisuje sintaksu i semantiku svih operacija.

Robert Manger
Kod dodavanja novih operacija u svrhu postizavanja cjelovitosti podrške treba se sjetiti svih
operacija koje nisu bile potrebne u polaznoj aplikaciji a mogle bi postati potrebne u budućim
aplikacijama. Na primjer, ako postojeća komponenta liči na onu sa slike 6.7 i daje podršku za
rad s jednim štampačom, treba joj dodati mogućnost rada s više štampača i operaciju
prebacivanja dokumenta iz reda jednog u red drugog štampača.
Rukovanje iznimkama u pravilu treba riješiti tako da sama komponenta ne obrađuje iznimke
nego ih prosljeđuje aplikaciji. Naime, svaka aplikacija ima svoje zahtjeve u pogledu obrade
iznimki. No takav pristup često rezultira nezgrapnim sučeljima, a koji put je i nemoguć ako
funkcionalnost komponente zahtijeva da se iznimka obradi lokalno u komponenti.
Očito je da povećavanjem općenitosti komponente (dodavanjem novih operacija ili

parametara) povećavamo njenu ponovnu upotrebljivost, no istovremeno je činimo sve
kompliciranijom za upotrebu. Prevelika složenost komponente i njenih sučelja te opširnost
njene dokumentacije može odbiti korisnike. Stoga također treba paziti da se ne pretjera s
općenitošću. Dakle treba naći dobar kompromis između ponovne upotrebljivosti i lakoće
korištenja.
U preostalom dijelu ovog odjeljka raspravljamo o CBSE uz ponovnu upotrebu. Da bi ponovna

upotreba komponenti u nekom novom sustavu bila uspješna, sam proces razvoja tog novog
sustava mora uzimati u obzir mogućnost korištenja komponenti. Drugim riječima, taj proces
mora izgledati kao na slici 6.10. Primijetimo da je slika 6.10 zapravo specijalan slučaj
općenitije slike 1.7 iz potpoglavlja 1.2.
Identificiraj Prilagodi
Skiciraj zahtjeve komponente- zahtjeve u skladu
na sustav kandidate s otkrivenim
komponentama
Opet
identificiraj Komponiraj
Oblikovanje komponente i
arhitekture komponente-
kandidate tako stvori sustav
Slika 6.10: razvoj softvera uz ponovnu upotrebu komponenti.
Neke od aktivnosti na slici 6.10, na primjer polazno otkrivanje korisničkih zahtjeva, odvijaju
se na uobičajeni način. No uočavamo da na slici 6.10 u odnosu na konvencionalne softverske
procese postoje sljedeće razlike.
1. Od korisnika se traži da budu što fleksibilniji kod definiranja zahtjeva, Naime, zahtjevi
koji su jako specifični ograničavaju broj komponenti koje ih mogu zadovoljiti.
2. Zahtjevi se razrađuju i modificiraju u skladu s raspoloživim komponentama, Korisnici će
rado pristati na kompromise ukoliko to povlači jeftiniju i bržu isporuku sustava.

3. Nakon što je oblikovana arhitektura sustava, pristupa se ponovnoj potrazi za

komponentama. To je potrebno zato što se neka od na početku izabranih komponenti
može kasnije pokazati nepogodnom ili nekompatibilnom u sklopu odabrane arhitekture.
4. Realizacija sustava svodi se na postupak kompozicije komponenti, gdje se odabrane
komponente međusobno integriraju u sustav. To se svodi na uključivanje komponenti u
middleware te također na razvoj pomoćnih modula (adaptera) koji ispravljaju
nekompatibilnosti u sučeljima komponenti. Također, ako odabrane komponente ne
pokrivaju svu traženu funkcionalnost, piše se dodatni programski kod.
U procesu sa slike 6.10 od presudne važnosti je odabir robusne arhitekture koja će omogućiti
uspješnu ponovnu upotrebu komponenti. Autor Ivar Jacobson o tome opširno raspravlja u
knjizi [33]. Arhitektura sustava mora se oblikovati na način koji je prikaziv UML component
dijagramima. Dakle arhitektura se mora svoditi na skup komponenti s međusobno povezanim
traženim odnosno ponuđenim sučeljima.
Jednu od posebnosti CBSE uz ponovnu upotrebu predstavlja aktivnost pronalaženja

komponenti-kandidata za ponovnu upotrebu. Ta aktivnost uključuje nekoliko podaktivnosti
koje su prikazane na slici 6.11. Na početku se koncentriramo na pretraživanje i izbor
komponenti iz lokalnih ili vanjskih repozitorija. Nakon što je oblikovana arhitektura sustava,
koncentriramo se na validaciju komponenti.
Pretraživanje Izbor Validacija

komponenti komponenti komponenti
Slika 6.11: pronalaženje komponenti za ponovnu upotrebu.
U procesu sa slike 6.11 posebnu pažnju treba posvetiti validaciji svake od odabranih
komponenti. Moramo biti sigurni da komponenta zaista pruža svu funkcionalnost koju mi od
nje tražimo te da nam njena dodatna funkcionalnost neće stvarati smetnje.
Kao primjer loše provedene validacije komponente i problema koji odatle slijede u literaturi
se često navodi primjer neuspjelog lansiranja europske rakete Ariane 5. Softver koji je
upravljao s Ariane 5 sadržavao je komponentu naslijeđenu od prethodne rakete Ariane 4.
Unatoč temeljitoj validaciji u simuliranim uvjetima, ta komponenta je zakazala u stvarnim
uvjetima i Ariane 5 se srušila. Do zakazivanja je došlo zbog operacije unutar komponente
koja je kod pretvorbe realnog broja u cijeli broj izazvala overflow. Ta operacija ispravno je
radila u Ariane 4 jer su tamo motori bili manje snažni a brojevi manji. Ista operacija nije
uopće bila potrebna u sklopu Ariane 5, tako da prilikom validacije nije ni bila testirana. No
komponenta je u stvarnom radu tu operaciju ipak pokrenula automatski.
Iz primjera Ariane 5 vidimo koja je osnovna poteškoća kod validacije komponenti. Poteškoća
je u tome što je komponenta bila razvijena unutar jedne okoline, a pokušava se upotrijebiti
unutar drukčije okoline. Pretpostavke polazne okoline obično nisu u potpunosti
dokumentirane, tako da je teško provjeriti da li one vrijede i u novoj okolini.

Robert Manger
6.3.3. Kompozicija komponenti
Kompozicija je proces integriranja komponenti, ili međusobno ili s posebnim dijelovima

„koda za lijepljenje“ – takozvanim adapterima. Na taj način stvara se nova složenija
komponenta ili cijeli sustav. Postoji više načina komponiranja i oni su prikazani na slikama
6.12, 6.13 i 6.14.
 Sekvencijalna kompozicija vidi se na slici 6.12. Iz dvije postojeće komponente A i B
stvaramo novu komponentu tako da A i B zovemo jednu za drugom. Dakle poziva se
usluga ponuđena od A, pa se rezultati vraćeni od A koriste kao parametri u pozivu usluge
koju nudi B. Primijetimo da A i B ne zovu jedna drugu. Umjesto toga, potreban je adapter
koji poziva usluge u ispravnom redoslijedu i osigurava da se rezultati od A pretvaraju u
oblik koji je kompatibilan s ulazima koje očekuje B.
 Hijerarhijska kompozicija vidi se na slici 6.13. Komponenta A neposredno poziva uslugu
koju nudi komponenta B. To znači da ponuđeno sučelje od B mora u potpunosti biti
kompatibilno (ustvari jednako) s traženim sučeljem od A. No ako postoji neka manja
nekompatibilnost, ona se može riješiti posredstvom dodatno napisanog adaptera koji se
umeće između A i B.
 Aditivna kompozicija vidi se na slici 6.14. Komponente A i B spojene su u novu
komponentu koja kombinira njihovu funkcionalnost. Ponuđeno odnosno traženo sučelje
nove komponente je kombinacija odgovarajućih sučelja od A i B. Potrebna su dva
adaptera koja služe kao vanjsko ponuđeno odnosno traženo sučelje nove komponente i
koji koordiniraju pozive usluga. Pritom A i B ne ovise jedna o drugoj i ne pozivaju se
međusobno.
Slika 6.12: sekvencijalna kompozicija komponenti.
Rekli smo da se dvije komponente neposredno povezuju tako da se ponuđeno sučelje jedne
spoji na traženo sučelje druge. Na dijagramu to prepoznajemo po tome što je „utikač“ jedne
komponente utaknut u „utičnicu“ druge. U takovoj situaciji podrazumijeva se da su
odgovarajuća sučelja kompatibilna, štoviše sasvim jednaka. Ako komponente koje želimo
spojiti razvijamo sami, ujednačavanje sučelja neće biti problem. No ako koristimo gotove
komponente iz drugih izvora, tada će se vjerojatno pojaviti veće ili manje nekompatibilnosti.
Općenito, postoje tri vrste nekompatibilnosti sučelja.
1. Nekompatibilnost parametara. Operacije u ponuđenom sučelju prve komponente imaju

ista imena kao operacije u traženom sučelju druge komponente, no brojevi ili tipovi
parametara se razlikuju.
2. Nekompatibilnost operacija. Imena operacija u ponuđenom sučelju prve komponente
razlikuju se od imena operacija u traženom sučelju druge komponente.
3. Nepotpunost operacija. Ponuđeno sučelje prve komponente je podskup traženog sučelja
druge komponente, ili obratno.
Slika 6.13: hijerarhijska kompozicija komponenti.
A B
Slika 6.14: aditivna kompozicija komponenti.
Kao što smo također već rekli, manje nekompatibilnosti među sučeljima mogu se riješiti
pisanjem adaptera i njihovim umetanjem između komponenti koje želimo povezati.
Primijetimo da adapter također komunicira s okolinom preko svojih ponuđenih i traženih
sučelja. Dakle adapter se može shvatiti kao još jedna komponenta koja sudjeluje u našoj
kompoziciji.

Robert Manger
string location (string pn)
phoneDatabase (string command) string owner (string pn)

addressFinder
string propertyType (string pn)
displayMap (string streetName,

string streetNo, int scale)
mapDB (string command)

mapper printMap (string streetName,
string streetNo, int scale)
Slika 6.15: primjer nekompatibilnih komponenti koje bi trebalo sekvencijalno povezati.
Kao prvi primjer potrebe za adapterima promatrajmo dvije komponente na slici 6.15 čija
sučelja su nekompatibilna. One bi trebale biti dio sustava koji koristi služba hitne pomoći u
nekom gradu. Prva komponenta addressFinder sadrži podatke o telefonskim pretplatnicima:
za zadani telefonski broj ona pronalazi i vraća adresu na kojoj se nalazi taj telefon, odnosno
prezime i ime pretplatnika, odnosno tip građevinskog objekta. Druga komponenta mapper
generira digitalnu kartu u zadanom mjerilu dijela grada oko zadane ulice i kućnog broja. Karta
se može prikazati na nečijem zaslonu ili štampati.
Sustav hitne pomoći trebao bi funkcionirati ovako. Kad operator primi poziv za hitnu pomoć,
telefonski broj pozivatelja ubacuje se u komponentu addressFinder da bi se odredila adresa.
Nakon toga se koristi komponenta mapper koja na osnovu ulice i kućnog broja iz pronađene
adrese generira kartu oko te adrese u mjerilu 1:10000. Karta se šalje a zaslon vozaču hite
pomoći.
Opisane komponente u principu se mogu komponirati jer adresa sadrži ulicu i kućni broj. No
budući da prva komponenta vraća cijelu adresu kao jedan niz znakova, a druga traži zasebno
ulicu odnosno kućni broj, potrebno je ipak napisati adapter. Taj adapter iz adrese koju je
vratio addressFinder izdvaja ulicu odnosno kućni broj te ih šalje kao zasebne parametre u
mapper. Riječ je o primjeru sekvencijalne kompozicije. Skica programskog koda za adapter
prikazana je na slici 6.16.
address = addressFinder.location(phonenumber);
streetname = addressStripper.getStreetName(address);
streetNo = addressStripper.getStreetNo(address);
mapper.displayMap(streetName, streetNo, 10000);
Slika 6.16: skica programskog koda za adapter koji će povezati komponente sa slike 6.15.

Kao drugi primjer korištenja adaptera promatrajmo sliku 6.17. Riječ je o dijelu mogućeg
rješenja za softver meteorološke stanice koju smo proučavali u odjeljku 3.3.3. Komponenta
DataCollector ugrađuje se u meteorološku stanicu. Ona upravlja skupom senzora ugrađenih
u stanicu (termometri, anemometri, barometri, ...) te skuplja i objedinjuje podatke koji stižu s
tih senzora. Ponuđeno sučelje od DataCollector omogućuje korisniku da na posredan način
pokrene ili zaustavi određeni senzor ili da dobije skupljene podatke od svih senzora. Traženo
sučelje od DataCollector služi za njegovo povezivanje sa samim senzorima i sastoji se od
dijela za upravljanje senzorom i dijela za očitavanje vrijednosti sa senzora. Komponenta
Sensor na slici 6.17 predstavlja jedan od senzora – njegovo ponuđeno sučelje sastoji se
operacija za pokretanje i zaustavljanje senzora te operacije za očitavanje vrijednosti.
addSensor
removeSensor
start sensorManagement startSensor
stop stopSensor
Sensor Adapter Data Collector testSensor
getData
sensorData initialize
report
listAll
Slika 6.17: primjer hijerarhijskog povezivanja komponenti preko adaptera.
Problem kod arhitekture na slici 6.17 je u tome što je DataCollector jedan, a Sensor-a ima
mnogo. Svaki senzor ima malo drukčije ponuđeno sučelje, pa nije moguće traženo sučelje od
DataCollector ujednačiti s ponuđenim sučeljima svih senzora. Rješenje problema postiže se
primjenom adaptera koji posreduje između DataCollector-a i svakog pojedinog Sensor-a.
Tražemo sučelje od DataCollector je generičko. Obje operacije iz tog sučelje koriste

tekstualni parametar koji se interpretira kao naredba senzoru. Na primjer, da bi očitao
vrijednost sa senzora, DataCollector generira poziv SensorData(˝collect˝), a da bi
zaustavio senzor, DataCollector poziva SensorManagement(˝stop˝). S druge strane,
konkretni senzor prikazan na slici 6.17 ne razumije ovakve naredbe jer se njegovo ponuđeno
sučelje sastoji od besparametarskih operacija start(), stop() i getData(). No tu sad uskače
adapter. Na primjer, kad adapter primi poziv SensorData(˝collect˝), on „parsira“ parametar s
kojim je operacija pozvana i kad u njemu otklrije riječ ˝collect˝ on dalje senzoru upućuje
poziv getData(), a dobivenu vrijednost prosljeđuje DataCollector-u kao odgovor na poziv
SensorData(). Sličan postupak primjenjuje se i kod poziva SensorManagement(˝stop˝).
Primijetimo da je situacija sa slike 6.17 primjer hijerarhijske kompozicije potpomognute
adapterom.
Kompozicija komponenti nije jednoznačan proces. Sustav sa traženom funkcionalnošću

obično se može sastaviti na razne načine. U odabiru najpogodnije kompozicije trebamo se
rukovoditi sljedećim pitanjima.

Robert Manger
1. Koja kompozicija je najefikasnija u smislu što brže i što jeftinije isporuke sustava
korisnicima?
2. Koja kompozicija osigurava lagano mijenjanje sustava u budućnosti kad se zahtjevi
promijene?
3. Koja kompozicija daje najbolje performanse sustava?
Nažalost, kriteriji iz ovih pitanja najčešće su u međusobnom konfliktu. U odabiru rješenja
tada je nužno napraviti neku vrstu kompromisa.
Report
Data Data Report
Collection Management Generator
Report
Data Data Base
Collection
Slika 6.18: dvije realizacije sustava za skupljanje podataka i generiranje izvještaja .
Kao primjer konflikta između adaptabilnosti i performansi, promatrajmo kompozicije na slici

6.18. Riječ je o dva rješenja za isti sustav koji skuplja podatke iz različitih izvora, sprema ih u
bazu podataka te zatim proizvodi različite izvještaje o spremljenim podacima.
 Prvo rješenje koristi zasebne komponente za upravljanje podacima odnosno generiranje
izvještaja. To znači da kod generiranja izvještaja komponenta ReportGenerator najprije
traži podatke od komponente DataManagement pa ih zatim obrađuje da bi stvorila
izvještaj.
 Drugo rješenje koristi istu komponentu DataBase za upravljanje podacima i za
generiranje izvještaja. Riječ je o DBMS-u s ugrađenim mogućnostima izvještavanja.
Prvo rješenje je očito bolje sa stanovišta laganog mijenjanja. Ako se komponenta za

upravljanje podacima pokaže nezadovoljavajuća, možemo je promijeniti bez da mijenjamo
ostale komponente. Slično možemo postupiti ako komponenta za generiranje izvještaja nije u
stanju proizvesti neku novu vrstu izvještaja. Drugo rješenje vjerojatno je bolje sa stanovišta
performansi, naime u njemu ima manje sučelja, pa i manje komunikacijskih zastoja.
Općenito i dugoročno gledajući, princip koji bi trebalo slijediti pri kompoziciji komponenti je
princip razdvajanja odgovornosti. Dakle sustav bi trebalo oblikovati tako da svaka
komponenta ima jasno definiranu ulogu te da se te uloge po mogućnosti ne preklapaju. No
ovo je lakše reći nego ostvariti. Često je jeftinije uzeti jednu gotovu komponentu s mnogo
funkcija nego razviti dvije ili tri komponente s razdvojenim funkcijama. Također, kod ponovo
upotrebljivih komponenti funkcionalnosti se obično preklapaju jer svaka od njih nastoji biti
što samostalnija.

6.4. Razvoj aplikacija pomoću web servisa
U ovom potpoglavlju bavimo se još jednom aktualnom tehnikom ponovne upotrebe. Ona se
zasniva na takozvanim web servisima. Riječ je o tehnici koja u konceptualnom pogledu ima
sličnosti s razvojem zasnovanim na komponentama, no bitno se razlikuje u pogledu tehničke
realizacije. U prvom odjeljku govorimo općenito o web servisima kao temelju nove
arhitekture distribuiranih sustava. Drugi odjeljak nabraja standardne jezike i protokole koji
omogućuju njihovu upotrebu. Treći odjeljak objašnjava zašto se oni mogu shvatiti kao oblik
ponovne upotrebe te koje su sličnosti i razlike u odnosu na komponente. U četvrtom odjeljku
proučavamo softverske procese koji su vezani uz web servise, dakle proces njihovog razvoja
odnosno proces razvoja aplikacija koje ih koriste.
6.4.1. Web servisi kao temelj nove distribuirane arhitekture
Pojava weba u 1990-im godinama donijela je revoluciju u mogućnostima razmjene podataka

preko Interneta. No podaci i usluge s weba isprva su bili dostupni samo web preglednicima.
Web servisi [22] predstavljaju nadogradnju klasične web tehnologije. Njime sadržaji s weba
postaju dostupni i drugim programima. Točnije rečeno, web servis je resurs na webu, koji je
prikazan na standardizirani način, i koji se može koristiti iz nekog drugog programa. To može
biti podatkovni resurs, kao na primjer katalog proizvoda, ili računalni resurs, na primjer
pretvarač slika iz jednog grafičkog formata u drugi, ili kombinacija jednog i drugog.
Web servisi omogućuju novu vrstu arhitekture distribuiranih sustava koja se naziva
arhitektura usmjerena na servise (Service Oriented Architecture – SOA) [23]. Prema SOA,
aplikacija se gradi povezivanjem samostalnih servisa koji su dostupni na Internetu i izvršavaju
se na geografski udaljenim računalima. Ideja SOA ilustrirana je na slici 6.19. Dobavljači
usluga oblikuju i implementiraju servise te definiraju sučelja preko kojih se pristupa tim
servisima. Također, oni objavljuju informacije o svojim servisima u nekom registru. Tražitelji
usluga otkrivaju u registru specifikacije servisa koji ih zanimaju i lociraju dobavljače usluga.
Nakon toga oni mogu povezati svoju aplikaciju s odabranim servisom i komunicirati s njime
preko njegovog sučelja razmjenom poruka u skladu s predviđenim protokolom. Ovisno o
modelu poslovanja, dobavljači svoje servise mogu učiniti dostupnima cijelom svijetu ili samo
pripadnicima neke kompanije, a svoje usluge mogu naplaćivati ili davati besplatno.
Registar
servisa
otkrivanje objavljivanje
Tražitelj Dobavljač
usluga povezivanje (SOAP) Servis
usluga
(WSDL)
Slika 6.19: arhitektura usmjerena na servise - SOA.

Robert Manger
Osim SOA, u literaturi se često pojavljuje i srodan pojam Software as a Service – SaaS. Treba
primijetiti da ta dva pojma nisu sinonimi. Naime, SOA se odnosi na razvoj novih aplikacija
kombiniranjem web servisa, a SaaS na mogućnost da korisnici neposredno preko web
preglednika koriste funkcionalnost udaljenog poslužitelja. Obje paradigme doprinose danas
često spominjanoj viziji računanja u oblaku (cloud computing).
Tehnologija web servisa omogućuje kompanijama da jedna drugoj stave na raspolaganje svoje
poslovne funkcije. Na taj način omogućen je razvoj fleksibilnih sustava s intenzivnom
međusobnom razmjenom informacija. U tim sustavima dolazi do integracije i automatizacije
poslovnih procesa gdje sudjeluje više kompanija. Na primjer, aplikacija u jednoj kompaniji
može automatski naručiti robu od servisa u drugoj kompaniji.
Dodatni vid fleksibilnosti korištenja web servisa sastoji se u tome što se veza između
aplikacije i servisa može dinamički mijenjati tijekom izvršavanja. To znači da se u različitim
prilikama mogu pokretati različite no ekvivalentne verzije servisa. Na primjer, aplikacija koja
naručuje robu može svaki put naručiti robu od drugog dobavljača. Također, aplikacija ne
mora biti građena isključivo od web servisa, nego može po potrebi miješati vanjske servise s
lokalno razvijenim komponentama.
Kao ilustraciju fleksibilne upotrebe web servisa i lokalnih modula promatrajmo sljedeći
scenarij. Potrebno je razviti informacijski sustav koji radi unutar automobila i koji vozača
snabdijeva s informacijama o vremenskim prilikama, prometnoj situaciji na cesti, i tako dalje.
Automobil ima ugrađen GPS uređaj s kojeg je moguće očitati trenutne geografske koordinate.
Sustav koristi te koordinate da bi od vanjskih informacijskih servisa dobio relevantne podatke
o vremenu i prometu. Veza s vanjskim servisima ostvaruje se posredstvom mobilnog telefona
u automobilu. Informacije se vozaču dostavljaju u obliku sintetiziranog govora koji se čuje
preko radio aparata u automobilu na posebnom radio kanalu i na jeziku kojeg je vozač sam
odabrao.
Na slici 6.20 prikazana je jedna moguća organizacija traženog sustava. Softver unutar
automobila sastoji se od pet modula. Oni obavljaju komunikaciju s vozačem, GPS uređajem,
telefonom, odnosno radio aparatom. Moduli Slanje podataka i Primanje podataka
obavljaju svu komunikaciju s vanjskim servisima putem mobilne telefonske veze.
Softver u automobilu u jednom trenutku komunicira samo s jednim vanjskim informacijskim

servisom, no taj jedan informacijski servis skuplja i objedinjuje informacije od niza
specijaliziranih servisa zaduženih za vrijeme, odnosno promet, i tako dalje. Ove usluge na
različitim mjestima nude različiti dobavljači. Stoga se sustav u automobilu stalno mora baviti
otkrivanjem servisa, da bi se nakon promjene položaja mogao prespojiti na neki drugi
informacijski servis. Sam informacijski servis također se služi otkrivanjem servisa da bi
otkrio njemu potrebne specijalizirane servise. Svi servisi međusobno razmjenjuju poruke od
kojih većina sadrži GPS koordinate automobila. Objedinjene informacije stižu u automobil
posredstvom dodatnog servisa koji ih automatski prevodi u traženi jezik.
Ovaj primjer dobro ilustrira ključne prednosti SOA. U trenutku implementacije sustava ne
moramo odlučiti koji dobavljači usluga će se angažirati ni koje točno usluge će se od njih
tražiti. Dok se automobil kreće, on otkriva dostupne informacijske servise te od njih dobiva
relevantne informacije. Zahvaljujući usluzi prevođenja, automobil može prelaziti granice, a
vozač će i dalje dobivati informacije na svojem jeziku.

Informacije o prometu na
Druge cesti
info
Info o
vremenu Lociranje Info o
GPS koord ceste prometu
GPS koord
GPS koord
Mobilni info Otkrivanje

servis servisa
Prevoditelj Pronalazi
Jezik, Objedinjuje
dostupne
Informacije informacije
servise
Prevedene
Informacije Naredba,
Jezik,
GPS koord
Primanje Slanje podataka Korisničko

podataka sučelje
Prima Šalje GPS

informacije iz koordinate i Prima zahtjev od
vanjskog servisa zahtjev za korisnika
informacijama
vanjskom
servisu
Radio Lociranje
Pretvara
Otkriva GPS
digitalne
koordinate
informacije u
automobila
radio signal
Softverski sustav
unutar automobila
Slika 6.20: informacijski sustav u automobilu zasnovan na web servisima.
6.4.2. Standardi vezani uz web servise
Razvoj tehnologije web servisa bio je popraćen razvojem odgovarajućih standarda. Sve važne
kompanije prihvatile su te standarde, pa su time osigurale kompatibilnost svojih rješenja. Na
slici 6.21 prikazani su jezici i protokoli koji su od ključne važnosti za funkcioniranje web
servisa. Svi oni zasnivaju se na XML-u. Kao što vidimo, riječ je o sljedećem.

Robert Manger
1. Service Oriented Architecture Protocol – SOAP. To je protokol za razmjenu poruka

između web servisa. Definiraju se obavezni i opcionalni dijelovi poruka.
2. Web Service Definition language – WSDL. To je jezik za opisivanje sučelja web servisa.
Omogućuje zadavanje imena operacija koje servis nudi, parametara i njihovih tipova,
iznimki, adrese na webu gdje se servis nalazi te načina na koji se aplikacija treba povezati
sa servisom.
3. Web Service – Business Process Execution Language – WS-BPEL. To je jezik za pisanje
aplikacije koja poziva web servise i kombinira njihove ulaze i izlaze.
XML tehnologije (XML, XSD, XSLT, ...)
Podrška (WS-Security, WS Addressing, ...)
Proces (WS-BPEL)
Definicija servisa (UDDI, WSDL)
Razmjena poruka (SOAP)
Transport (HTTP, HTTPS, SMTP, ...)
Slika 6.21: standardi za web servise.
Na slici 6.21 vidimo također da tehnologija web servisa predstavlja nadogradnju web
tehnologije. Zaista, kao transportni protokol ispod SOAP-a u pravilu se koristi HTTP, a sam
HTTP radi na vrhu stoga protokola TCP/IP. To znači da se komunikacija aplikacije i web
servisa odvija posredstvom web poslužitelja.
U nastavku ćemo reći nešto više o WSDL-u. Rekli smo da jedan dokument u WSDL-u služi
kao opis sučelja jednog web servisa. Struktura takvog dokumenta prikazana je na slici 6.22.
Nakon uvodnog dijela koji sadrži XML-ove deklaracije prostora imena (namespace), slijede
dijelovi u kojima se definiraju tri stvari o web servisu: što on radi, kako on komunicira te gdje
se on može naći. Odgovor na pitanje „što“ svodi se na opis operacija, parametara, tipova
podataka, poruka i iznimki. Odgovor na „kako“, takozvani binding, specificira protokol za
komunikaciju sa servisom - u pravilu to je SOAP no može se odabrati i neki drugi. Odgovor
na „gdje“ određuje adresu na webu gdje je servis instaliran, dakle njegov Uniform Resource
Identifier – URI.
Zanimljivo je napomenuti da se uz spomenuta tri standarda SOAP, WSDL i WS-BPEL prije

desetak godina predlagao i još jedan:
4. Universal Description, Discovery and Integration – UDDI. To je standard koji propisuje
način na koji se servis treba dokumentirati tako da bi ga tražitelji usluga lako mogli naći.

WSDL definicija servisa
Uvod XML deklaracije za prostore imena
deklaracije tipova,
Apstraktno sučelje deklaracije sučelja,
deklaracije poruka
Konkretna implementacija deklaracija načina povezivanja,

deklaracija web adrese
Slika 6.22: organizacija specifikacije u WSDL-u.
Očekivalo se da će dobavljači usluga stvarati svoje UDDI registre s opisima servisa koje
nude. Neke od kompanija, na primjer Microsoft, zaista su to učinile u prvim godinama 21.
stoljeća. No danas su svi ti registri ugašeni, a UDDI je pao u zaborav. Razlog za to je taj što se
servisi danas sasvim uspješno mogu pronaći korištenjem standardnih tražilica. Dovoljno je na
web postaviti odgovarajuće WSDL opise.
SOAP, WSDL, WS-BPEL i UDDI zamišljeni su kao glavni standardi za web servise. No
osim njih postoji i niz pomoćnih standarda koji se odnose na neke posebne aspekte. Na
primjer postoje standardi za pouzdanu razmjenu poruka, za sigurnost, za koordinaciju
transakcija i drugi. Neki autori kritizirali su standarde za web servise da su preglomazni,
preopćeniti i neefikasni. Zbog toga su neke kompanije poput Google i Amazon odustale od
standardnih jezika i protokola pa su počele koristiti svoju nestandardnu ali jednostavniju
verziju web servisa koju su nazvale RESTful [24].
6.4.3. Usporedba web servisa i komponenti
Web servisi očito predstavljaju jedan oblik ponovne upotrebe softvera. Zaista, kad veći broj
aplikacija koristi isti servis, tada se ista implementacija dotične usluge upotrebljava mnogo
puta. Štoviše, stječe se dojam da je riječ o vrlo djelotvornoj tehnici ponovne upotrebe. Naime,
kad razvijamo aplikaciju, tada nam u pravilu stoji na raspolaganju obilje servisa diljem
Interneta, pa je za očekivati da ćemo za svaku uslugu koja nam treba uspjeti pronaći
odgovarajuću implementaciju.
Web servisi su po mnogim karakteristikama usporedivi s komponentama o kojima smo

govorili u potpoglavlju 6.3. Neki autori smatraju da je ustvari riječ o dvije inačice u osnovi
istog pristupa. Mi ipak posebno obrađujemo svaku od tehnika, a u nastavku ovog odjeljka
nabrojat ćemo njihove sličnosti i razlike.
Sličnosti između komponenti i web servisa su sljedeće.

 Obje tvorevine zasnivaju se na konceptu pružanja usluga.
 Obe tvorevine koristimo preko (ponuđenog) sučelja koje se sastoje od operacija s
parametrima.

Robert Manger
 U oba slučaja aplikaciju gradimo na sličan način, dakle kombiniranjem raspoloživih

usluga, pretvorbom rezultata jedne usluge u ulaz za drugu uslugu, i tako dalje.
 Obje tehnike nagovještavaju nastanak nove softverske industrije, koja bi se umjesto
razvojem aplikacija bavila isključivo razvojem ponovno upotrebljivih dijelova za
aplikacije.
 Obje tehnike nastoje biti neovisne o programskom jeziku, to jest ne bi trebalo biti važno u
kojem jeziku su razvijeni ponovno upotrebljivi dijelovi, a u kojem jeziku sama aplikacija.
Dalje slijede razlike.

 Komponenta je proces koji se izvršava na stroju pod nadležnošću korisnika aplikacije.
Web servis je proces koji se izvršava na udaljenom stroju pod nadležnošću dobavljača
usluge.
 Ako više aplikacija koristi istu komponentu, tada svaka od njih pokreće svoju kopiju te
komponente. Ako više aplikacija koristi isti web servis, tada sve one dobivaju usluge od
istog primjerka servisa.
 Aplikacija se s komponentom povezuje preko middleware-a, dakle u skladu s paradigmom
poziva udaljenih procedura. Aplikacija s web servisom komunicira na znatno labaviji
način, razmjenom poruka koje se prenašaju na vrhu stoga internetskih protokola.
 Komponenta osim ponuđenog sučelja može imati i traženo sučelje – ono opisuje uvjete
koje aplikacija treba pružiti komponenti da bi ona mogla raditi. Web servis nema traženo
sučelje – to je zato što web servis funkcionira u svojem okruženju neovisno o aplikaciji.
 Slično kao konačni automat, komponenta može prelaziti iz stanja u staje te pamtiti svoje
trenutno stanje. To znači da se komponenta kod svakog uzastopnog poziva može drukčije
ponašati. S druge strane, web servis nema stanja pa se kod uzastopnih poziva ponaša na
potpuno isti način. To je nužno zato što isti primjerak servisa istovremeno služi raznim
aplikacijama.
 Postoji nekoliko različitih modela za komponente te nekoliko odgovarajućih tipova
middleware-a. Komponente predviđene za različite modele međusobno su
nekompatibilne. S druge strane, svi web servisi su u pravilu kompatibilni budući da
poštuju iste standarde i povezuju se na labaviji način.
Zahvaljujući ovim razlikama, web servisi mogu se pokazati boljim rješenjem od komponenti
u jednoj situaciji no lošijim rješenjem u nekoj drugoj situaciji. Za razliku od komponenti, koje
se danas uglavnom interno koriste unutar velikih kompanija, web servisi su u većoj mjeri
ostvarili ideju globalne softverske industrije, gdje se rješenje stvara na jednom mjestu a
ponovo se upotrebljava bilo gdje drugdje u svijetu. No s druge strane, zbog načina
komuniciranja preko XML-a i internetskih protokola, web servisi su bitno sporiji od
komponenti pa nisu pogodni za aplikacije gdje se traže dobre performanse.
6.4.4. Softverski procesi vezani uz web servise
Slično kao kod komponenti, u softverskom inženjerstvu zasnovanom na web servisima

razlikujemo dvije vrste softverskih procesa.
 Razvoj samih web servisa koje će netko drugi upotrebljavati.
 Razvoj aplikacija korištenjem postojećih web servisa.
U prvom dijelu ovog odjeljka bavimo se procesom razvoja samih servisa. Taj proces prikazan
je slikom 6.23 i sastoji se od tri faze.

1. Identifikacija kandidata za servis. Uočavamo moguće servise i definiramo zahtjeve za

njih.
2. Oblikovanje sučelja servisa. Oblikujemo logičko sučelje servisa i poruke te sastavljamo
odgovarajući opis u WSDL-u.
3. Implementacija i instalacija servisa. Realiziramo i testiramo servis te ga činimo
dostupnim za upotrebu.
Identifikacija Implementacija
Oblikovanje
kandidata za sučelja servisa i instalacija
servis servisa
Specifikacija Validirani i
Zahtjevi na servis
sučelja servisa instalirani servis
Slika 6.23: proces razvoja web servisa.
Slično kao kod komponenti, razvoj ponovno upotrebljivog servisa obično počinje
identifikacijom nekog postojećeg softverskog modula koji se pokazao korisnim i koji bi
mogao biti od šireg interesa. Na primjer, može biti riječ o modulu koji preračunava valute ili
dijelu softvera koji obavlja plaćanje PDV-a. U daljnjem postupku razvoja postojeći modul
mora se generalizirati, to jest iz njega treba izbaciti specifičnosti njegove originalne aplikacije
te mu treba dodati novu funkcionalnost koja će ga učiniti cjelovitijim i nezavisnijim.
Oblikovanje sučelja servisa sastoji se od sljedećih koraka.

 Logičko oblikovanje sučelja. Definiramo operacije koje će servis izvršavati, njihove
ulazne i izlazne parametre te iznimke.
 Oblikovanje poruka. Definiramo strukturu poruka koje servis prima ili šalje.
 Razvoj u WSDL-u. Rezultati logičkog oblikovanja i oblikovaja poruka prevode se u
apstraktni opis sučelja zapisan u jeziku WSDL.
Specifičnost oblikovanja sučelja web servisa je pisanje teksta u WSDL-u. WSDL je prilično
složen jezik zasnovan na XML-u, a specifikacije u njemu obično su dugačke i detaljne. Zato
se kod u WSDL-u obično ne piše ručno već se dobiva automatski primjenom posebnih alata,
na primjer iz UML dijagrama koji prikazuje sučelje kao klase ili iz ekvivalentnog Java koda.
Primjer opisa sučelja u WSDL-u vidi se na slici 6.24. Riječ je o sučelju za servis koji za
zadani datum i ime grada vraća maksimalnu i minimalnu temperaturu na taj datum u tom
gradu. Prikazan je samo dio teksta: vidimo specifikaciju samo jednog tipa podataka te
specifikaciju samo jedne operacije s pripadnim ulaznom i izlaznom porukom i porukom o
greški.

Robert Manger
Define some of the types used. Assume that the namespace prefixes ‘ws’ refers
to the namespace URI for XML schemas and the namespace prefix associated
with this definition is weathns.
<types>
<xs: schema targetNameSpace = “http://.../weathns”
xmlns: weathns = “http://…/weathns” >
<xs:element name = “PlaceAndDate” type = “pdrec” />
<xs:element name = “MaxMinTemp” type = “mmtrec” />
<xs: element name = “InDataFault” type = “errmess” />
<xs: complexType name = “pdrec”
<xs: sequence>
<xs:element name = “town” type = “xs:string”/>
<xs:element name = “country” type = “xs:string”/>
<xs:element name = “day” type = “xs:date” />
</xs:complexType>
Definitions of MaxMinType and InDataFault here
</schema>
</types>
Now define the interface and its operations. In this case, there is only a single
operation to return maximum and minimum temperatures.
<interface name = “weatherInfo” >

<operation name = “getMaxMinTemps” pattern = “wsdlns: in-out”>
<input messageLabel = “In” element = “weathns: PlaceAndDate” />
<output messageLabel = “Out” element = “weathns:MaxMinTemp” />
<outfault messageLabel = “Out” element = “weathns:InDataFault” />
</operation>
</interface>
Slika 6.24: dio opisa u WSDL-u za meteorološki web servis.
Implementacija servisa svodi se na programiranje u nekom od standardnih programskih jezika

ili na modificiranje već postojećeg programskog koda. Obično se koristi Java ili C#. Naime,
današnje programerske okoline za rad s tim jezicima poput Eclipse ili Microsoft Visual Studio
sadrže svu potrebnu podršku za razvoj web servisa, dakle opskrbljene su odgovarajućim
bibliotekama i u stanju su proizvesti odgovarajući izvršivi program s propisanim sučeljem.
Instalacija servisa svodi se na kopiranje izvršivog programa na određeni direktorij te od
stavljanja WSDL opisa i drugih informacija o servisu na web.
U preostalom dijelu ovog odjeljka bavimo se procesom razvoja aplikacije koja koristi web
servise. Uobičajeno je da se tijek takve aplikacije opisuje kao radni tok (workflow). Pojam
workflow potječe iz poslovnog svijeta i označava niz aktivnosti koje se moraju izvršiti
vremenski jedna za drugom da bi se postigao neki poslovni cilj. U našem slučaju aktivnosti se
izvršavaju tako da se pozove odgovarajući web servis.

Proces razvoja aplikacije prikazan je na slici 6.25. Vidimo da se taj proces sastoji od šest
koraka.
1. Oblikovanje polaznog workflow-a. Na osnovu zahtjeva na aplikaciju predlažemo idealni
tijek aktivnosti unutar aplikacije.
2. Otkrivanje servisa. Pretražujemo odgovarajuće registre ili kataloge da bi ustanovili koji
nama zanimljivi servisi nam stoje na raspolaganju te tko ih daje i pod kojim uvjetima.
3. Izbor servisa. Iz skupa mogućih kandidata koje smo otkrili biramo one servise koji
najbolje mogu implementirati aktivnosti iz našeg workflow-a.
4. Profinjenje workflow-a. Na osnovu informacija o izabranim servisima profinjujemo
polazni workflow. To znači da dodajemo detalje o operacijama i parametrima te možda
dodajemo ili izbacujemo aktivnosti. Da bi se izabrani servisi što bolje mogli upotrijebiti,
često je potrebno napraviti manje kompromise u funkcionalnosti aplikacije.
5. Stvaranje workflow-programa. Profinjeni workflow pretvaramo u izvršivi program. U tu
svrhu koristimo konvencionalni programski jezik poput Java ili C#, ili specijalizirani jezik
WS-BPEL.
6. Testiranje aplikacije. Provjerava se da li workflow-program stvoren u prethodnom koraku
ispravno radi i da li on zadovoljava uvjete iz specifikacije.
Oblikovanje
polaznog Otkrivanje
servisa Izbor servisa
workflow-a
Lista servisa Specifikacije

Polazni workflow
kandidata izabranih servisa
Testiranje Stvaranje Profinjenje

aplikacije workflow-
programa workflow-a
Aplikacija koja je Profinjeni

spremna za Izvršivi workflow
upotrebu workflow
Slika 6.25: proces razvoja aplikacije koja koristi web servise.
Aplikaciju koja koristi web servise možemo oblikovati kao obični korisnički program ili kao
novi složeni web servis. Ako je naša aplikacija ustvari novi servis, onda i njoj moramo
definirati odgovarajuće sučelje te ga opisati u WSDL-u.

Robert Manger
Oblikovanje workflow-a obično se obavlja na grafički način, pomoću takozvanih BPMN-

dijagrama [25]. Riječ e o notaciji razvijenoj u IBM-u koja je raširena u poslovnom svijetu.
Kratica znači Business Process Modeling Notation. BPMN dijagrami otprilike su ekvivalentni
UML activity dijagramima, no razlikuju se od njih u nekim sintaktičkim i semantičkim
detaljima. Prednost BPMN-a je u tome što postoje alati koji na osnovu BPMN dijagrama
automatski generiraju izvršivi kod u WS-BPEL-u. To je dobro zato što je WS-BPEL, kao
jezik zasnovan na XML-u, prilično nezgrapan za ručno pisanje.
Slika 6.26 sadrži primjer jednostavnog BPMN dijagrama. Riječ je o workflow-u aplikacije
koja klijentu avionske kompanije omogućuje ne samo kupovinu avionske karte, nego također
i rezervaciju hotelske sobe u odredišnom gradu, narudžbu rent-a-car-a ili taksija te kupovinu
ulaznica za kazalište. Prikazane aktivnosti zapravo su pozivi web servisa – prvi servis pripada
avionskoj kompaniji a preostali su vanjski servisi iz odredišnog grada. Puna strelica na
dijagramu predstavlja tok kontrole, a crtkana strelica tok podataka.
Kupi karte Rezerviraj Naruči rent- Pretraži informacije Kupi ulaznice

za let sobu u hotelu a-car ili taksi o predstavama za kazalište
Datum i vrijeme Datumi,

dolaska i odlaska preferencije
Lokacija hotela
Slika 6.26: workflow aplikacije za organiziranje putovanja avionom.
Pokušaj ponovo
Odustani
Nema soba Hoteli
NijeRaspoloživo
Hoteli Hoteli
DajZahtjeve ProvjeriRaspoloživost
Hoteli
Ima soba RezervirajSobe
Hoteli
PotvrdiRezervaciju
Kupac
Slika 6.27: fragment workflow-a za rezervaciju hotela.

Dijagram sa slike 6.26 pretpostavljao je da će se nacrtane aktivnosti uvijek moći izvršiti jedna
za drugom. No u stvarnosti su moguće razne komplikacije. Na primjer, nakon što je putnik
kupio avionsku kartu, možda će se kod rezervacije hotela ustanoviti da ne postoji slobodna
hotelska soba u zadanom razdoblju. Dizajner workflow-a mora predvidjeti takvu situaciju te
omogućiti putniku ili promjenu datuma putovanja ili odustajanje od kupovine avionske karte.
Na slici 6.27 prikazan je još jedan BPMN dijagram. Njime se djelomično profinjuje dijagram
s prethodne slike, to jest razrađuje se aktivnost rezervacije sobe u hotelu. Definira se postupak
u slučaju kad nema slobodne sobe. Vidimo još neke grafičke elemente iz BPMN-a, na primjer
rombove koji predstavljaju donošenje odluke.

Robert Manger

Literatura
Općeniti udžbenici o softverskom inženjerstvu:
1. Sommerville I.: Software Engineering, 9-th Edition. Pearson Education Inc, Boston MA,
USA, 2010. ISBN 0-13-705346-0.
2. Van Vliet H.: Software Engineering - Principles and Practice, 3-rd Edition. John Wiley
and Sons, Chichester, England UK, 2008. ISBN 0-470-03146-8.
3. Pressman R.S.: Software Engineering - A Practitioner’s Approach, 7-th Edition.
McGraw Hill, New York NY, USA, 2009. ISBN 0-07-337597-7.
4. Schach S.R.: Object Oriented and Classical Software Engineering, 8-th Edition.
McGraw Hill, New York NY, USA, 2010. ISBN 0-07-337618-3.
5. Braude E.J., Bernstein M.E.: Software Engineering – Modern Approaches. John Wiley
and Sons, New York NY, USA, 2010. ISBN 0-471-69208-5.
6. Pfleeger S.L, Atlee J.M.: Software Engineering - Theory and Practice, 4-th Edition.
Prentice Hall, Englewood Cliffs NJ, USA, 2009. ISBN 0-13-606169-9.
7. Tsui F., Karam O., Bernal B.: Essentials of Software Engineering, 3-rd Edition. Jones &
Bartlett Publishers, Sudbury MA, USA, 2013. ISBN 1-4496-9199-4.
Udžbenici koji obrađuju pojedine metode ili alate softverskog inženjerstva:

8. Bruegge B., Dutoit A.H.: Object-Oriented Software Engineering Using UML, Patterns,
and Java, 3-rd Edition. Prentice Hall, Englewood Cliffs NJ, USA, 2009. ISBN 0-13-
606125-7.
9. Arlow J., Neustadt I.: UML 2 and the Unified Process, 2-nd Edition. Addison-Wesley.
Upper Saddle River NJ, USA, 2005. ISBN 0-321-32127-8.
10. Beck K., Andres C.: Extreme Programming Explained – Embrace Change, 2-nd Edition.
Addison-Wesley, Upper Saddle River NJ, USA, 2004. ISBN 0-321-27865-8.
11. Visual Paradigm International: Korisnička dokumentacija za Visual Paradigm for UML.
http://www.visual-paradigm.com/support/documents
12. Randolph N., Gardner D., Anderson C., Minutillo M.: Professional Visual Studio 2010.
(Wrox Programmer to Programmer), Wiley Publishing Inc., Indianapolis IN, USA, 2010.
ISBN: 0470548657.
13. Chatfield C., Johnson T.D.: Microsoft Project 2010 Step by Step. Microsoft Press,
Redmond WA, USA, 2010. ISBN 0-7356-2695-2.
14. Cooling J.: Software Engineering for Real-Time Systems. Addison Wesley, Harlow UK,
2003. ISBN: 0201596202.
15. Burns A., Wellings A.: Real-Time Systems and Programming Languages – Ada, Real-
Time Java and C/Real-Time POSIX. Addison-Wesley, Boston MA, USA, 2009. ISBN:
0321417453.
16. Silberschatz A., Galvin P., Gagne G.: Operating Systems Concepts, 8-th Edition. John
Wiley and Sons, New York NY, USA, 2008. ISBN: 0470128720.
17. Beck K: Test Driven Development – By Example. Addison-Wesley, Boston MA, USA,
2002. ISBN: 0-321-14653-0.
18. Massol V., Husted T.: JUnit in Action. 2-nd Edition. Manning Publications, Stamford CT,
USA, 2010. ISBN: 1-935182-02-1.
19. Vesperman J.: Essential CVS. O’Reilly and Associates, Sebastopol CA, USA, 2003.
ISBN: 0596004591.

Robert Manger
20. Pilato C.M., Collins-Sussman B., Fitzpatrick B.W.: Version Control with Subversion. 2-
nd Edition. O’Reilly and Associates, Sebastopol CA, USA, 2008. ISBN: 0596510330.
21. Szyperski, C.: Component Software – Beyond Object-oriented Programming. 2-nd
edition. Addison-Wesley, Harlow UK, 2001. ISBN: 0-201-17888-5.
22. Newcomer E., Lomow G.: Understanding SOA with Web Services. Addison-Wesley,
Boston MA, USA, 2005. ISBN: 0-321-18086-0.
23. Erl T.: Service-Oriented Architecture – Concepts, Technology and Design. Prentice Ha..,
Upper Saddle River NJ, USA, 2005. ISBN: 0-13-185858-0.
24. Richardson L., Ruby S.: RESTful Web Services. O’Reilly media Inc, Sebastopol CA,
USA, 2007. ISBN: 0-596-52926-0.
25. White S.A., Miers D.: BPMN Modeling and Reference Guide – Understanding and Using
BPMN. Future Strategies Inc, Lighthouse Point FL, USA, 2008. ISBN: 0-9777527-2-0.
Klasična djela i dodatni sadržaji vezani uz softversko inženjerstvo:

26. Brooks F.P.: The Mythical Man Month - Essays on Software Engineering, Anniversary
Edition. Addison-Wesley, Reading MA, USA, 1995. ISBN 0-201-83595-9.
27. ACM and IEEE-CS Joint Task Force: Software Engineering Code of Ethics and
Professional Practice (Version 5.2). http://www.acm.org/about/se-code
28. DeMarco T. Structured Analysis and System Specification. Yourdon Press, New York
NY, USA, 1978. ISBN 0138543801.
29. Ward P., Mellor S.: Structured Development for Real-Time Systems. Volume I, II, III.
Prentice Hall, Englewood Cliffs NJ, USA, 1986. ISBN: 0138547874, 0138547955,
013854803X.
30. Gamma E., Helm R., Johnson R., Vlissides J.: Design Patterns – Elements of Reusable
Object-Oriented Software. Addison-Wesley, Reading MA, USA, 1995. ISBN: 0-201-
63361-2.
31. Warren I.E.: The Renaissance of Legacy Systems. Springer, London UK, 1998. ISBN:
1852330600.
32. Lehman M.M., Belady L.: Program Evolution – Processes of Software Change. Academic
Press, London UK, 1985. ISBN: 0124424406.
33. Jacobson I., Griss M., Jonsson P.: Software Reuse. Addison-Wesley, Reading MA, USA,
1997. ISBN: 0-201-92476-5.

Manger

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manger

Uploaded by

Copyright:

Available Formats

Sveučilište u Zagrebu

Prirodoslovno Matematički fakultet

Nadopunjeno drugo izdanje

2 PMF – Matematički odsjek

PMF – Matematički odsjek 3

4 PMF – Matematički odsjek

5. Održavanje i evolucija ...................................................................................................... 117

PMF – Matematički odsjek 5

6 PMF – Matematički odsjek

Skripta se sastoje od šest poglavlja. Prvo poglavlje je uvodno i u njemu se objašnjavaju

U ovim skriptama naglasak je na „inženjerskim“ (računarskim) aspektima softverskog

PMF – Matematički odsjek 7

8 PMF – Matematički odsjek

1. Uvod u softversko inženjerstvo

1.1. Osnovni pojmovi vezani uz softversko inženjerstvo

1.1.1. Softverski produkt i softversko inženjerstvo

Softverski produkt je skup računalnih programa i pripadne dokumentacije, stvoren zato da bi

Za današnji softver podrazumijeva se da on mora biti kvalitetan. Preciznije, od softverskog

Softversko inženjerstvo može se smatrati znanstvenom disciplinom no također i tehničkom

PMF – Matematički odsjek 9

 Sistemsko inženjerstvo (system engineering). Bavi se razvojem složenih sustava koji se

Softversko inženjerstvo također je i profesija. U mnogim zemljama softverski inženjeri

Važna osobina softverskog inženjerstva je da u njemu nema „jednoumlja“ ni jednoobraznosti.

1.1.2. Softverski proces, metode i alati

Model za softverski proces je idealizirani prikaz softverskog procesa, kojim se određuje

10 PMF – Matematički odsjek

Metoda razvoja softvera je profinjenje i konkretizacija odabranog modela za softverski

1.1.3. Dokumentacija softvera

Dokumentacija softvera može se podijeliti u dvije kategorije.

PMF – Matematički odsjek 11

1.2. Modeli za softverski proces

Modeli se razlikuju po načinu odvijanja i međusobnog povezivanja osnovnih aktivnosti.

1.2.1. Model vodopada

Utvrđivanje zahtjeva Dokument o zahtjevima

Programiranje i testiranje Moduli

Puštanje u rad i održavanje

Slika 1.1: softverski proces prema modelu vodopada.

Prednosti modela vodopada su sljedeće.

Mane modela vodopada su sljedeće.

PMF – Matematički odsjek 13

1.2.2. Modeli evolucijskog i inkrementalnog razvoja

Model evolucijskog razvoja (evolutionary development) nastao je kao protuteža modelu

Slika 1.2: evolucijski razvoj softvera.

Prednosti modela evolucijskog razvoja su sljedeće.

Mane modela evolucijskog razvoja su sljedeće.

14 PMF – Matematički odsjek

Model inkrementalnog razvoja (incremental development) sličan je modelu evolucijskog

Slika 1.3 inkrementalni razvoj softvera.

Prednosti modela inkrementalnog razvoja su sljedeće.

Mane modela inkrementalnog razvoja su sljedeće.

1.2.3. Modeli formalnog i grafičkog razvoja

Model formalnog razvoja (formal systems development) zasniva se na korištenju takozvanih

Neformalna Formalna Formalne Integracija

Slika 1.4: proces formalnog razvoja softvera.

Formalna Sve detaljnije

Slika 1.5: formalne transformacije u sklopu formalnog razvoja softvera.

Prednosti modela formalnog razvoja su sljedeće.

Mane modela formalnog razvoja su sljedeće.

16 PMF – Matematički odsjek

Utvrđivanje Grafičko Automatsko

Slika 1.6: proces grafičkog razvoja.

1.2.4. Model usmjeren na ponovnu upotrebu

Model usmjeren na ponovnu upotrebu (reuse-oriented development) polazi od pretpostavke