Softversko inzenjerstvo - Zagreb PMF

Sveučilište u Zagrebu

Prirodoslovno Matematički fakultet

Matematički odsjek

Robert Manger

SOFTVERSKO INŽENJERSTVO

Skripta

Drugo izdanje

Zagreb, rujan 2012.

Robert Manger

2 PMF – Matematički odsjek

Softversko inženjerstvo - skripta

PMF – Matematički odsjek 3

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

Robert Manger


3. Oblikovanje i implementacija ............................................................................................ 55

3.1. Općenito o oblikovanju i implementaciji .................................................................. 55

3.1.1. Pod-aktivnosti 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. Pod-sustavi 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

4. Verifikacija i validacija ....................................................................................................... 89

4.1. Općenito o verifikaciji i validaciji ............................................................................. 89

4.1.1. Metode za verifikaciju i validaciju ................................................................... 89

4.1.2. Mjesto verifikacije i validacije u softverskom procesu ...................................... 90

4.1.3. Odnos verifikacije, validacije i debuggiranja ..................................................... 91

4.2. Statička verifikacija ................................................................................................... 91

4.2.1. Inspekcija programa ........................................................................................... 91

4.2.2. Automatska statička analiza ............................................................................... 93

4.2.3. Formalna verifikacija ......................................................................................... 94

4.3. Testiranje softvera ..................................................................................................... 95

4.3.1. Vrste i faze testiranja .......................................................................................... 95

4.3.2. Testiranje dijelova softvera ................................................................................ 98

4.3.3. Testiranje integracije ........................................................................................ 102

4.3.4. Razvoj softvera vođen testiranjem ................................................................... 105



5. Održavanje i evolucija ...................................................................................................... 107

5.1. Općenito o održavanju i evoluciji ............................................................................ 107

5.1.1. Strategije mijenjanja softvera ........................................................................... 107

5.1.2. Vrste i dinamika održavanja softvera ............................................................... 108

5.1.3. Cijena održavanja softvera ............................................................................... 108

5.1.4. Održavanje unutar agilnih metoda ................................................................... 109

5.2. Upravljanje konfiguracijom ..................................................................................... 110

5.2.1. Svrha upravljanja konfiguracijom, podjela na pod-aktivnosti ......................... 110

5.2.2. Upravljanje promjenama .................................................................................. 112

5.2.3. Upravljanje verzijama ...................................................................................... 115

5.2.4. Gradnja sustava ................................................................................................ 118

5.2.5. Upravljanje izdanjima ...................................................................................... 120

5.3. Baštinjeni softver i njegovo mijenjanje ................................................................... 121

5.3.1. Građa i osobine baštinjenog softvera ............................................................... 121

5.3.2. Softversko re-inženjerstvo ................................................................................ 122

5.3.3. Arhitekturna transformacija ............................................................................. 125

6. Ponovna upotreba ............................................................................................................. 129

6.1. Općenito o ponovnoj upotrebi ................................................................................. 129

6.1.1. Svojstva i oblici ponovne upotrebe .................................................................. 129

6.1.2. Popis tehnika za ponovnu upotrebu ................................................................. 130

6.1.3. Odabir tehnike za ponovnu upotrebu ............................................................... 131

6.2. Neki tradicionalni oblici ponovne upotrebe ............................................................ 131

6.2.1. Aplikacijski okviri ............................................................................................ 131

6.2.2. Produktne linije ................................................................................................ 133

6.2.3. Upotreba COTS produkata ............................................................................... 135

6.3. Razvoj softvera zasnovan na komponentama .......................................................... 137

6.3.1. Komponente i njihovo korištenje ..................................................................... 138

6.3.2. Softverski procesi zasnovani na komponentama ............................................. 140

6.3.3. Kompozicija komponenti ................................................................................. 144

6.4. Razvoj aplikacija pomoću web servisa .................................................................... 149

6.4.1. Web servisi kao temelj nove distribuirane arhitekture ..................................... 149

6.4.2. Standardi vezani uz web servise ....................................................................... 151

6.4.3. Usporedba web servisa i komponenti ............................................................... 153

6.4.4. Softverski procesi vezani uz web servise ......................................................... 154

Literatura ................................................................................................................................... 161

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 [24] 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-tih godina 20-tog 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 složenijim 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 [23].

Od 60-tih godina 20-tog 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željni 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 pod-

aktivnosti te propisuje što se sve mora raditi unutar pojedine pod-aktivnosti. Dalje, metoda

uvodi konkretan način dokumentiranja rezultata pod-aktivnosti (dijagrami, tabele, pseudo-

jezik, … ), 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, te 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 specifikacija 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“ upotrebu. 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, te na vrlo

precizan način dokumentira sve funkcije sustava, sve oblike njegove upotrebe, 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 kojeg 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. Točnije, 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 komponenti, te sučelje između

komponenti. 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 upotrebu, 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-tim godinama 20. stoljeća, kao

neposredna analogija s procesima iz drugih inženjerskih struka (na primjer mostogradnja).

Softverski proces je građen kao niz vremenski odvojenih aktivnosti, u skladu sa Slikom 1.1.

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 č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.

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 Poglavlje 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.

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 upotrebljiv 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


Slika 1.4: proces formalnog razvoja softvera.

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 Poglavlje 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

upotrebu. Glavna mana mu je da za sada nije upotrebljiv 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

zahtjeva

(specifikacija)

Grafičko

modeliranje

(analiza,

oblikovanje)

Automatsko

generiranje

programa iz

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, ... ).

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-tim godinama 20-tog 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-te godine

20-tog 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-te 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 Poglavlje 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 kas se dosegne njen 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 posebni 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 use primjere korištenja (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 test. 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

korisničke priče

za novo izdanje

Razbij

korisničke priče

u zadatke

Planiraj novo

izdanje

Evaluiraj sustavIsporuči novo

izdanje

Razvij,

integriraj i

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 u 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, na primjer MS 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

Opis rizika

Ključni članovi razvojnog tima možda će se razboljeti u

najnezgodnije vrijeme.

Baza podataka koju ugrađujemo u naš

produkt možda neće moći obraditi dovoljan

broj transakcija u sekundi.

Financijer projekta možda će imati

financijskih problema pa će htjeti smanjiti sredstva za projekt.

Kategorija rizika

vezan uz projekt vezan uz produkt poslovni

Vjerojatnost pojavljivanja

velika umjerena mala

Učinak rizika ozbiljan podnošljiv katastrofalan

Plan za upravljanje

Reorganiziraj tim tako da ima više

preklapanja poslova pa će ljudi lakše

moći zamijeniti jedan drugog.

Nabavi odmah bolju bazu podataka za koju je manje vjerojatno da će stvarati probleme.

Napiši unaprijed dokument koji

dokazuje da projekt daje važan doprinos poslovnim ciljevima financijera, te da bi

smanjivanje sredstava donijelo više štete

nego koristi.

Strategija plana

minimizacija izbjegavanje priprema

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

rizika

Analiza

rizika

Planiranje

rizika

Nadziranje

rizika

Lista

potencijalnih

rizika

Rang lista

najznačajnijih

rizika

Planovi za

upravljanje

rizicima

Nove

procjene

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-tak 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, upotrebljivost.

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 upotrebljivost 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 pod-aktivnosti.

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.

Studija

izvodljivosti

Otkrivanje i analiza zahtjeva

Dokumentiranje zahtjeva

Validacija

zahtjeva

Izvještaj o

izvodljivostiModeli sustava

Korisnički zahtjevi i zahtjevi

na sustav

Dokument o

zahtjevima

Slika 2.4: pod-aktivnosti 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

Poglavlju 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 su takozvani

use-case i sequence dijagrami. Modeliranje sustava pomoću UML-a opširnije će biti obrađeno

u Poglavlju 2.3.

Robert Manger


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

da te 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 ga 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 koja 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

Predgovor Definira se kome je dokument namijenjen. Opisuje se povijest verzija dokumenta, razlog zašto je koja verzija nastala i sažetak promjena za svaku od verzija.

Uvod

Obrazlaže se potreba za sustavom. Ukratko se opisuju njegove funkcije i način kako će on surađivati s drugim sustavima. Također se opisuje kako se sustav uklapa u strateške ili poslovne ciljeve organizacije koja ga je naručila.

Glosarij Definiraju se tehnički pojmovi koji se koriste u dokumentu. Ne pretpostavlja nikakvo posebno predznanje čitatelja.

Korisnički zahtjevi

Opisuju se usluge koje sustav treba pružiti korisnicima, Također se opisuju i nefunkcionalni zahtjevi. Opis koristi prirodni jezik, dijagrame i drugu notaciju koja je razumljiva korisnicima. Mogu se spomenuti i standardi za proces razvoja softvera koji se misle slijediti.

Arhitektura sustava

Prikazuje se pretpostavljena arhitektura sustava, vidi se raspored funkcija po podsustavima ili komponentama. Označavaju se komponente koje se misle realizirati ponovnom upotrebom.

Zahtjevi na sustav Razrađuju se i detaljno se specificiraju funkcionalni i nefunkcionalni zahtjevi. Po potrebi se definiraju sučelja prema drugim sustavima.

Modeli sustava Uključuju se grafički modeli sustava (na primjer UML dijagrami) koji prikazuju granice, građu ili ponašanje sustava, njegove veze s okolinom, odnose između komponenti ili podsustava.

Evolucija sustava

Opisuju se sadašnje pretpostavke na kojima je sustav zasnovan, te predvidive promjene zbog napretka hardvera, novih potreba 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.

Prilozi Daju se detaljne ili specifične informacije vezane uz aplikaciju koja se razvija, na primjer opis predviđenog hardvera ili opis raspoložive baze podataka.

Kazalo

To je popis pojmova ili sadržaja te brojeva stranica u dokumentu gdje se ti pojmovi ili sadržaji pojavljuju. Može 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 su

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, 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.

Medicinski recepcionar

Medicinska sestra

Menadžer

Liječnik

Unos osobnih podataka

Određivanje termina pregleda

Pregled zapisa

Registracija pacijenta

Generiranje statistike

Generiranje izvještaja

Uređivanje zapisa

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 pod-aktivnosti unutar aktivnosti specifikacije:

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

konvencionalni 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.

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

velikom 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 jr 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.

Etnografska

analiza

Dodatno

ispitivanje

Fokusirana

etnografija

Evaluacija

prototipa

Generički

razvoj sustava

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 kojeg 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 kao 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>>

Informacijski

sustav Zavoda

za statistiku

<<system>>

Bolnički

informacijski

sustav

<<system>>

Sustav

elektroničkih

uputnica

<<system>>

Sustav

elektroničkih

recepata

<<system>>

Registar

zdravstvenog

osiguranja

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.

Medicinski recepcionar Registar zdravstvenog osiguranja

Transfer podataka

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.

Medicinska sestra

P: PacijentInfo D: BolnickaDB A: Autorizacija

Gledaj (PID)

Report (Info, PID, UID)

Autoriziraj (Info, UID)

Autorizacija

Zapis o pacijentu

Greška (nema ovlaštenja)

Alt

[Autorizacija OK]

[Autorizacija nije prošla]

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

PacijentStanjeLiječnik opće

prakse

Pregled

Bolnički liječnik

Lijek

Dijagnosticirano Upućen_od

Upućen_prema

Podvrgava_se

Sudjeluje_u

Propisuje

1..*

1

0..* 1..*

1

1..*

1..*

1..4

1..* 1

1..* 0..*

Slika 2.15: primjer class dijagrama.

Primijetimo da class dijagrami poput onog sa Slike 2.15 izgledaju vrlo slično kao Chen-ovi

dijagrami koji se koriste za opis konceptualne sheme baze podataka u skladu s modelom

entitete, veza i atributa. Zaista, class dijagram zapravo poopćuje Chen-ov 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-tih godina 20. stoljeća.

UML class dijagrami mogu se oblikovati u raznim stupnjevima 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 njenim 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 pod-klase i nad-klase, 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 nad-klasu također su implicitno definirani i za pod-klasu. No pod-klasa

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 nad-klasa crta iznad pod-klase. 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 pod-klase 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 pod-klase

Knjiga odnosno Časopis. No vidimo da svaka od pod-klasa ima i svoje specifične atribute.

Liječnik

Liječnik opće prakseBolnički liječnik

Liječnik specijalist

Kvalificirani liječnik

Timski liječnik

Liječnik pripravnik

Slika 2.17: primjer generalizaciju i hijerarhiju klasa.

Robert Manger


Publikacija

ČasopisKnjiga

Kataloški brojNaslovIzdavačStatus

Nabavi ()Katalogiziraj ()

Otpiši ()Posudi ()Vrati ()

AutorIzdanje

Godina izdanjaISBN

VolumenBrojISSN

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

SlajdoviUdžbenik Zadaci za vježbu

1..*

1

1

1 1

1..*

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-tim

godinama 20. stoljeća u sklopu funkcionalno-orijentiranih metoda razvoja softvera. U svojoj

čuvenoj knjizi [25], 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


Inzulinska

pumpa

Naredbe za

upravljanje

pumpom

Potrebna

količina

inzulina

Upravljaj

pumpom

Generiraj naredbe za upravljanje pumpom

Izračunaj potrebnu količinu inzulina

Izračunaj razinu šećera

Pročitaj vrijednost

sa senzora

Senzor za

šećer

Podaci sa

senzora

Razina

šećera u

krvi

Slika 2.20: primjer activity dijagrama.

Službenik

: Narudžba : Budžet :BazaNarudžbi

Ispuni ()

Ažuriraj (Iznos)

Spremi ( )

Provjeri ()

Dobavljač

Pošalji ( )

[Provjera OK]

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-tim godinama 20. stoljeća [26]. 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

snagu na 600 W

Čekanje

Do: prikazuj

vrijeme

Postavi vrijeme

Do: učitaj

znamenku

Exit: postavi

vrijeme

Rad

Do: upravljaj

radom pećnice

Pola snage

Do: postavi

snagu na 300 W

Osposobljena

Do: prikaži

poruku

"Spremna za

rad"

Onesposobljena

Do: prikaži

poruku "Vrata

otvorena"

Čekanje

Do: prikaži

vrijeme

Pola

snage

Puna

snaga

Timer ZnamenkaPuna

snaga

Timer

Vrata

otvorena

Vrata

zatvorena

Vrata

zatvorena Start

Vrata

otvorena

Cancel

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.

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

Puna snaga Snaga pećnice je postavljena na 600 W. Displej pokazuje poruku „Puna snaga“.

Zadavanje vremena Vrijeme pečenja je postavljeno prema vrijednosti koju je korisnik unio. Displej pokazuje unesene znamenke i osvježava se dok se znamenke unose.

Onesposobljena Rad pećnice je prekinut zbog sigurnosnih razloga. Svjetlo unutar pećnice je upaljeno. Displej pokazuje poruku „Vrata otvorena“.

Osposobljena Pećnica je spremna za rad. Svjetlo unutar pećnice je ugašeno. Displej pokazuje poruku „Spremna za rad“.

Rad

Pećnica radi. Svjetlo unutar pećnice je upaljeno. Displej odbrojava preostalo vrijeme pečenja. U trenutku završetka 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.



Provjera

Do: provjeri

stanje

Pečenje

Do: puštaj

grijalicu da radi

Alarm

Do: ispiši

poruku o

događaju

Gotovo

Do: zvoni

zvono 5

sekundi

Greška na obrtnoj

platformi

Greška na emiteru

Status ok

Vrataotvorena

Prošlo je

vrijeme

Rad

Onesposobljena Čekanje

Cancel

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 pod-aktivnostima, pristupima i trendovima.

Zatim ćemo detaljnije obraditi specifične no danas izuzetno važne aspekte oblikovanja, kao

što su oblikovanje arhitekture, objektni pristup oblikovanju, te razvoj distribuiranih 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. Pod-aktivnosti unutar oblikovanja

Oblikovanje je kreativna aktivnost koju je teško precizno opisati. Ipak, možemo reći da se

oblikovanje sastoji od pod-aktivnosti u skladu sa Slikom 3.1. Svaka od njih daje svoje izlazne

rezultate.

Slika 3.1: proces i rezultati oblikovanja.

Robert Manger


Slijedi kratko objašnjenje za svaku od navedenih pod-aktivnosti.

U oblikovanju arhitekture uočavaju se i dokumentiraju pod-sustavi koji čine sustav, te

veze među tim pod-sustavima. Ova pod-aktivnost 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širnije prikaz nalazi se u Potpoglavlju 3.2.

Unutar apstraktnog specificiranja, za svaki pod-sustav piše se specifikacija softverskog

dizajna, dakle apstraktni i vrlo precizni opis zahtjeva. Ova pod-aktivnost 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 pod-sustav se oblikuje i dokumentira sučelje prema

drugim pod-sustavima i prema korisniku. Ova pod-aktivnost važna je kod većih projekata

jer ona omogućuje da se daljnjim razvojem pod-sustava paralelno bave nezavisni timovi.

Oblikovanje dijelova obavlja se tako da se svaki pod-sustav 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 pod-aktivnost isto

nije obavezna već se uključuje onda kad očekujemo da će potrebne strukture podataka ili

algoritmi biti presložene 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 kojeg 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 pod-sustave. Kasnije kod

oblikovanja dijelova, svaki pod-sustav 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 kojeg je lako

implementirati u klasičnim programskim jezicima (glavna funkcija, pod-funkcija, pod-

pod-funkcija 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 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 .

Sve faktureFaktura

[neplaćena]Opomena

Ustanovi je

li faktura

plaćena

Izdaj opomenu

Izdaj računČitaj izdane

fakture

Sve uplate

Faktura

[plaćena]Račun

Faktura

Slika 3.2: primjer sustava oblikovanog funkcionalnim pristupom.

Faktura

Kupac

Uplata

idFakturedatumiznos

idKupca

izdaj ()šaljiOpomenu ()primiUplatu ()šaljiRačun ()

idUplatedatumiznos

idKupca

idKupcaime

adresapoček

Račun

idRačunadatumiznos

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 Poglavlju 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 pod-sustavi 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. Slike 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 specifikaciju.

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 Poglavljima 6.1, 6.2 i 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 pod-sustava, od kojih svaki obavlja određeni skup zadataka. Okvirno se utvrđuje

način komuniciranja pod-sustava, 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 pod-aktivnosti unutar oblikovanja arhitekture, a to su

strukturiranje sustava odnosno modeliranje kontrole.

3.2.1. Pod-sustavi i odnosi među njima

Pod-sustav definiramo kao relativno samostalnu cjelinu, čije funkcioniranje uglavnom ne

ovisi o servisima koje pružaju drugi pod-sustavi. Pod-sustav je sastavljen od svojih dijelova

(komponente, moduli, objekti, … ). On ima definirano sučelje za komunikaciju s drugim pod-

sustavima, te se podvrgava određenim režimima kontrole.

Da bi oblikovali arhitekturu nekog sustava, nije dovoljno samo definirati njegove pod-

sustave, već također treba odrediti odnose između tih pod-sustava. Primijetimo da postoje

dvije bitno različite vrste odnosa pod-sustava: međusobna komunikacija, odnosno međusobna

kontrola. Zato se u sklopu oblikovanja arhitekture pojavljuju sljedeće dvije pod-aktivnosti.



Strukturiranje sustava. Sustav se rastavlja na pod-sustave. Utvrđuje se komunikacija

između pod-sustava, dakle razmjena podataka.

Modeliranje kontrole. Određuje se tok kontrole između pod-sustava, dakle tko s kime

upravlja.

Svaku od ovih pod-aktivnosti 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 pod-blokove. 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 na odgovarajući način, te zapakirane

stavlja na drugu tekuću traku. Slika 3.6 sadrži blok dijagram sustav koji služi za zaštitu protiv

provalnika i upravlja alarmom.

Pod-sustav za identificiranje

predmeta

Pod-sustav za odabir načina

pakiranja

Pod-sustav za

pakiranje

Upravljanje pokretnom

trakom

Upravljanje robotskom

rukom

Pod-sustav za umjetni vid

Upravljanje robotskom hvataljkom

Slika 3.5: model strukture sustava za pakiranje pomoću robota.

Sirena

Upravljanje alarmom

Sintetizator

glasa

Upravljanje telefonskim

pozivom

Senzori pokreta

Senzori za vrata

Vanjski kontrolni centar

Slika 3.6: model strukture sustava za zaštitu protiv provalnika.

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 pod-sustavi. Komunikacija između pod-sustava

odvija se tako da jedan pod-sustav zapiše podatke u bazu, a drugi pod-sustav pročita te

podatke. Sam repozitorij također treba shvatiti kao jedan (specijalizirani) pod-sustav.

Struktura je vidljiva na Slici 3.7.

Pod-sustav 3

Repozitorij(baza podataka)

Pod-sustav 4

Pod-sustav 1 Pod-sustav 2

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 primjeri

je CASE alat Visual Paradigm kojeg koristimo na vježbama, ili informacijski sustav ISVU.

Slika 3.8 prikazuje strukturu zamišljenog lower-CASE alata.

Analizator dizajna

Projektni repozitorij

Editor za Python

Prevoditelj dizajna

Editor za Javu

Editori za UML

Generatori koda

Generator izvještaja

Slika 3.8: Lower-CASE alat građen u skladu s modelom repozitorija.



Modela s repozitorijom ima sljedeće prednosti.

Pojednostavnjena je komunikacija jer je izbjegnuto direktno slanje podataka iz pod-

sustava u pod-sustav.

Administriranje podataka je centralizirano pa se pod-sustavi ne trebaju time baviti.

Jednostavno se može dodati novi pod-sustav, 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 pod-sustavi 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: pod-sustavi koji nude usluge drugim pod-sustavima,

klijenti: pod-sustavi 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

Mreža

Klijent 2 Klijent 3

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

Širokopojasna mreža

Klijent 2 Klijent 3

Video poslužitelj Audio poslužiteljPoslužitelj

katalogaPoslužitelj slika

Katalog

Filmovi u

digitalnom

formatu

Digitalizirani

zvučni zapisi

Digitalne

fotografije u

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 pod-sustava 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.



Objedinjeni katalog

Baza

1

Sučelje preko web preglednika

Baza

2

Baza

3

Baza

4

LoginUpravljanje formularima

i upitima

Upravljanje

ispisom

Distribuirano

pretraživanjeDohvat

dokumenta

Naplata

usluge

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 pod-sustava 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 „|“.

Filter 1 Filter 2 Filter 3ulazni

podaci

transf

podaci

transf

podaci

izlazni

podaci

Slika 3.13: model cjevovoda i filtra za strukturu sustava.

Robert Manger


Ovaj model često se koristio u prošlosti za oblikovanje ne-interaktivne (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).

Leksička analiza

Sintaktička analiza

Semantička analiza

izvorni

tekst

Generiranje koda

Strojni

kod

Slika 3.14: prevodilac (compiler) građen u skladu s modelom cjevovoda i filtra.

Prednost modela je 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 pod-sustava:

Centralizirana kontrola: jedan pod-sustav igra ulogu „kontrolora“, dakle on pokreće i

zaustavlja ostale pod-sustave.

Kontrola upravljana događajima (event driven): kontrola je distribuirana u tom smislu što

pojedini pod-sustavi samostalno reagiraju na vanjske događaje. Ti događaji mogu biti

generirani od drugih pod-sustava ili od okoline sustava.

Pod pojmom „događaj“ opet 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 pod-sustava (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

pod-sustav 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.

Slika 3.15: model poziva i povratka za kontrolu.

Model menadžera. Jedan pod-sustav, takozvani menadžer, kontrolira ostale tako što im šalje

signale za početak, kraj, odnosno sinkronizaciju njihovog rada. Svi pod-sustavi 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 pod-sustave treba

pokrenuti ili zaustaviti. Model je predočen Slikom 3.16.

Slika 3.16: kontrola prema modelu menadžera.

Ovaj model sa centraliziranom kontrolom pogodan je za takozvane „meke“ sustave u realnom

vremenu: pod-sustavi upravljaju nekim tehnološkim procesom, vezani su uz senzore i

aktuatore, a zahtjevi za brzinom odziva u realnom vremenu nisu prestrogi.

Model difuzije (broadcast). Spada u modele upravljane događajima. Bilo koji događaj

prosljeđuje se svim pod-sustavima. Odgovara samo onaj pod-sustav 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 pod-sustavu, već svaki pod-sustav samostalno odlučuje hoće li

reagirati na događaj ili neće. Model je ilustriran Slikom 3.17.

Ovaj model pogodan je za sustave u realnom vremenu sa „srednje tvrdim“ zahtjevima na

brzinu odgovora na događaje. Moguća je varijanta sa selektivnim emitiranjem događaja samo

onim pod-sustavima koji su „pretplaćeni“ na određene vrste događaja.

Robert Manger


Slika 3.17: kontrola prema modelu difuzije.

Prednosti modela difuzije su sljedeće.

Lagano se dodaje novi pod-sustav.

Bilo koji pod-sustav 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.

Pod-sustavi ne znaju da li će i kada neki događaj (koji su sami generirali) biti obrađen.

Mogući su konflikti ako više pod-sustava 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 pod-sustav - 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.

Slika 3.18: model za kontrolu upravljan prekidom.

Ovaj model koristi se za „tvrde“ sustave u realnom vremenu. Može se kombinirati s nekim

modelom centralizirane kontrole.

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 kojeg 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 pod-

sustava. 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-tim u 90-tim godinama

20. stoljeća, a najprije 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 servisi,

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.

o3:C3

stanje o3

operacije3()

o6:C1

stanje o6

operacije1()

o1:C1

stanje o1

operacije1()

o2:C2

stanje o2

operacije2()

o4:C4

stanje o4

operacije4()

o5:C5

stanje o5

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 tome ć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 pod-sustave 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 koje 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 pod-sustav i središnji kontrolni pod-sustav. Zadaća meteorološkog

informacijskog pod-sustava je da skuplja i obrađuje podatke iz svih meteoroloških stanica.

Zadaća kontrolnog pod-sustava je da prati stanje svih meteoroloških stanica te da ih po

potrebi resetira, pali, gasi i re-konfigurira. Komunikacija između meteorološke stanice i

meteorološkog informacijskog pod-sustava odnosno kontrolnog pod-sustava 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 pod-sustav.

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 pod-

sustav preko satelita povremeno provjerava stanje stanice te u slučaju neispravnog rada

nastoji resetirati njene instrumente ili uključiti rezervne instrumente. Također, kontrolni pod-

sustav može re-konfigurirati 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 pod-sustav cijelog sustava. U okolini meteorološke stanice

nalaze se još dva pod-sustava: informacijski i kontrolni. Četvrti pod-sustav je satelit koji

omogućuje međusobnu komunikaciju ostalih pod-sustava. Iz kardinalnosti veza vidimo da

postoji samo jedan informacijski pod-sustav, jedan kontrolni pod-sustav 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 pod-

sustava: informacijski i kontrolni. Informacijski pod-sustav može na primjer od stanice

zahtijevati da mu pošalje izvještaj sa sažetim vremenskim podacima. Kontrolni pod-sustav

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 oblikovanju zahtijeva 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.

Kontrolni

pod-sustav

Meteorološka

stanica

Satelit

Informacijski

pod-sustav

1

1

1

1 1

1

1

1..n

1..n

1..n

Slika 3.20: kontekst za meteorološku stanicu.

Informacijski pod-sustav

Kontrolni pod-sustav

Izvještaj o stanju

Rekonfiguriranje

Ponovno pokretanje

Izvještaj o vremenu

Gašenje

Upravljanje na daljinu

Slika 3.21: interakcije meteorološke stanice s okolinom.



Pod-sustav Meteorološka stanica

Slučaj uporabe

Izvještaj o vremenu

Akteri Informacijski pod-sustav, meteorološka stanica

Opis Meteorološka stanica šalje informacijskom pod-sustavu 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 pod-sustav uspostavlja komunikacijsku vezu s meteorološkom stanicom preko satelita i zahtijeva od stanice prijenos podataka.

Odgovor Meteorološka stanica šalje sažete podatke informacijskom pod-sustavu.

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

greškama

Unutrašnja komunikacija

Upravljanje

konfiguracijomUpravljanje

energijom

Komunikacija

preko satelita

Skupljanje

podatakaInstrumenti

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 pod-sustav. 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 pod-sustavu. Na dijagramu

se pojavljuju objekti iz klasa sa prethodne slike, no također i dva nova objekta: prvi od njih

enkapsulira komunikaciju stanice s vanjskim svijetom preko satelita, a drugi enkapsulira

Robert Manger


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.

MeteoroloskaStanica

Identifikator

izvjestajVrijeme ()izvjestajStanje ()

daljinskoUpravljanje (naredbe)rekonfiguracija (naredbe)

restart (instrumenti)shutdown (instrumenti)

MeteoroloskiPodaci

temperatureZrakatemperatureTla

brzineVjetrasmjeroviVjetra

tlakovipadaline

skupi ()obradi ()

TermometarTlo

tt_identifikatortemperatura

ocitaj ()testiraj ()

Anemometar

an_identifikatorbrzinaVjetrasmjerVjetra


Barometar

b_identifikatortlak

visina


Slika 3.24: neke od klasa za meteorološku stanicu.

Informacijski pod-sustav

:SatKomunikacija : MeteoroloskaStanica :UnutraKomunikacija

zahtjev (izvjestaj)

salji (izvjestaj)

zahtjev (obrada )obradi ( )

:MeteoroloskiPodaci

izvjestajVrijeme ( )potvrda

potvrda

potvrda

odgovor (izvjestaj)

potvrda

Slika 3.25: slanje podataka iz meteorološke stanice u informacijski pod-sustav.



daljinskoUpravljanje( )

restart( )

testiranje

gotovo

Ugašena Radi

Pod daljinskim

upravljanjem

Testira se

Konfigurira seSkuplja

podatkeŠalje podatke

Obrađuje

podatke

izvjestajStanje( )

shutdown( )

rekonfiguracija( )rekonfiguracija

gotova satskupljanje

gotovo

izvjestajVrijeme()

izvještaj

gotov

slanje

gotovo

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 pod-sustav. 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>>Izvjestavanje

VremenskiIzvjestaj(MS-Ident): VizvjestajStatusniIzvjestaj(MS-Ident): Sizvjestaj

<<interface>>DaljinskoUpravljanje

startInstrument (instrument): iStatusstopInstrument (instrument): iStatusskupiPodatke(instrument): iStatusunesiPodatke(instrument): string

Slika 3.27: sučelja za meteorološku stanicu.

Robert Manger


MeteoroloskaStanica

Identifikator

izvjestajVrijeme ()izvjestajZagadjenje ()

izvjestajStanje ()daljinskoUpravljanje (naredbe)

rekonfiguracija (naredbe)restart (instrumenti)

shutdown (instrumenti)

PodaciOZagadjenju

podaciNOpodaciSmog

podaciBenzen

skupi ()obradi ()

MjeracNO

no_identifikatorvrijednostNO


MjeracSmoga

s_identifikatorvrijednostSmog


MjeracBenzena

bz_identifikatorvrijednostBenzen


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 pod-sustav.

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 [27] autora Gamme i suradnika.

Ta knjiga definira 30-tak 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 [27], 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?

Subjekt

A: 40B: 25C: 15D: 20

Promatrač 1 Promatrač 2

20%15%

25%

40%

40

25

1520

A B C D

A

B

C

D

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 tabularni 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

ConcreteSubject

Attach (Observer)Detach (Observer)

Notify ( )

subjectState

GetState ( )

Observer

ConcreteObserver

Update ( )

observerState

Update ( )return subjectState

for All o in observers

o -> Update( )

observerState =

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 [27], 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čnih 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 pod-modela. 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.

s4

s3s2

s1c1

c2 c3 c4

c5

c6

c7

c12

c11

c10

c9

c8

Poslužiteljski proces

Klijentski proces

Slika 3.32: primjer sustava građenog od klijenata i poslužitelja.

sc1

sc2

mreža

cc1 cc2 cc3

cc5cc4 cc6

Poslužiteljsko računalo

Klijentsko računalo

s1, s2c1 c2 c3, c4

c5, c6, c7 s3, s4 c8, c9 c10, c11, c12

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.

Poslužitelj

Obrada,

upravljanje

podacima

klijent

Prezentacija Poslužitelj

Upravljanje

podacimaklijent

Prezentacija + obrada

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


Poslužitelj računa

Tele-

procesing

monitor

ATM

Baza

korisničkih

računaATM

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.

Poslužitelj

Obradaklijent

PrezentacijaPoslužitelj

Upravljanje

podacima

Slika 3.37: troredni razmještaj slojeva aplikacije na računala.

Web poslužitelj

Generiranje

web stranica,

aplikacijski servisi

Klijent

Klijent

Klijent

Klijent

Poslužitelj baze pod

SQL

Baza

korisničkih

računa

SQL upit

HTTPS interakcija

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 pod-zadataka koje dodjeljuje robovima. Robovi paralelno rješavaju

svoje pod-zadatke i svoja rješenja šalju gospodaru. Dobivena rješenja pod-zadataka gospodar

objedinjuje u konačno rešenje cijelog zadatka. Ideja je ilustrirana Slikom 3.39.

Gospodar

Rezultati rješavanja

pod-zadatka

Pod-zadatakRob

Rob

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 pod-nizova 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), gdje postoje senzori i aktuatori. Sustav u realnom

vremenu upravlja nekim tehnološkim procesom. Senzor su uređaju 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 senzora ili posao kontroliranja jednog

aktuatora.

Robert Manger


Proces za

koordinaciju i

prikaz

situacijeProcesor za

senzore

Proces za

upravljanje

semaforima

Proces koji

kontrolira

senzore

Rob Rob

Gospodar

Procesor u

kontrolnoj sobi

Operatorove

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

Usluge 1

middleware (softverska sabirnica)

Objekt 2

Usluge 2

Objekt 3

Usluge 3

Objekt 4

Usluge 4

Objekt 5

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 ga 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 je dobra 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 re-konfigurirati, 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-tak 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 2

Baza podataka 3

Baza podataka 1Integrator 1

Integrator 2

Složeno sučelje

Vizualizator

Generator izvještaja

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 trž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.

p3

p5 p6

p8p4

p1 p2

p7

p9

p10

p11

p12

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


p3p5

p4

p1

p2

p6

Poslužitelj za pronalaženje

(super-partner)

Slika 3.44: polu-centralizirana arhitektura ravnopravnih partnera.

U skladu sa Slikom 3.44, polu-centralizirana 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.



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čkaV&V

Testiranje

Specifikacija

zahtjeva

Dizajn na

visokoj razini

Formalna specifikacija

Detaljni

dizajnProgram

Prototip

Slika 4.1: primjena verifikacije i validacije u raznim fazama razvoja softvera.

Specifikacija

zahtjeva

Specifikacija

sustava

Oblikovanje

sustava

Detaljno

oblikovanje

Plan za

primopre-

dajni test

Plan za test

integracije

sustava

Plan za test

integracije

pod-sustava

Puštanje u

rad

Primopre-

dajni test

Test

integracije

sustava

Test

integracije

pod-sustava

Kodiranje i testiranje modula i manjih

dijelova

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

testiranja

Specifikacija

(zahtjevi) Test primjeri

Lociraj

grešku

Oblikuj

popravak

greške

Popravi

grešku

Ponovo testiraj

program

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-tih, 80-tih

i 90-tih 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.

PlaniranjeDistribucija materijala

Individualna priprema

Sastanak inspekcije

Popravak programa Nastavak

Slika 4.4: proces inspekcije programa.

Vrsta greške Inspekcijska provjera

Greške s podacima

Postoje li varijable koje nisu deklarirane? 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 uz tok kontrole

Za svaku uvjetnu naredbu, je li uvjet ispravan? 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 ulazom i izlazom

Koristi li se svaki od ulaznih podataka? Je li svakom izlaznom podatku pridružena vrijednost prije njegovog ispisa? 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 sučeljima

Imaju li svi pozivi funkcija ispravan broj parametara? 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 uz upravljanje memorijom

Postoje li ne-inicijalizirani pokazivači? Jesu li kod promjene vezane strukture svi pokazivači ispravno preusmjereni? Je li dinamička memorija alocirana na ispravan način? Je li alocirana memorija ispravno de-alocirana onda kad se više ne koristi?

Greške u upravljanju iznimkama

Jesu li sva moguća stanja greške uzeta u obzir?

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-te

godine 20. stoljeća, autor Mills i drugi).

Idejom formalne specifikacije intenzivno su se bavila mnoga velika imena računarstva

tijekom 70-tih 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 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 neka 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

kontra-primjer koji pokazuje da svojstvo ne vrijedi. Cijeli postupak ilustriran je Slikom 4.7.



Dizajn ili program

Poželjna svojstva sustava

Model sustavaGradnja modela

Specifikacija svojstava

Model checker

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 kontra-primjer, 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)

Testiranje izdanja (release testing)

Korisničko testiranje (user testing)

Statističko testiranje

Testiranje u svrhu otkrivanja grešaka

Testiranje dijelova

Testiranje integracije

Funkcionalno testiranje

Strukturalno testiranje

Testiranje po putovima

Testiranje zahtjeva

Testiranje scenarija

Testiranje performansi

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 upotrebu softvera.

Statističko testiranje. Služi za provjeru nekih oblika ne-funkcionalnih 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 jedinki

(funkcija, klasa)

Testiranje

modula

Testiranje

pod-sustava

Testiranje

sustava

Testiranje

dijelovaTestiranje integracije

Slika 4.9: proces testiranja u svrhu otkrivanja grešaka - detaljni prikaz.

Testiranje

dijelovaTestiranje

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đnog (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.

Testirani dio

softvera

OeIzlazni

rezultati

IeUlazni

podaci

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).

Elementi < srednjeg Elementi > srednjeg

Granice klasa ekvivalencije

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.

Uvjet

Tijelo

Nastavak

Uvjet

False-grana

Nastavak

True-grana

ne

da neda

while 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

1

2

3

4

5

6

7

8

9

1014

11

12 13

while bottom <= top

elemArray[mid] = keyelemArray[mid] != key

elemArray[mid] > key elemArray[mid] < key

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.



Test primjeri

A B

C

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 testova 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 pod-sustave, 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.

Umetci za razinu 2

Razina 1 ...

Razina 2 Razina 2 Razina 2

Razina 1

Razina 2

Umetci za razinu 3

Redoslijed

testiranja

Slika 4.21: testiranje integracije u redoslijedu top-down.

Razina N Razina N Razina N Razina N

Razina N-1

Razina N

Test driver-i

Redoslijed

testiranja

Razina N-1 Razina N-1

Test driver-i

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)

[14]. 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 novu

funkcionalnost

Implementiraj funkcionalnost uz refactoring

Napiši test Izvrši test

prošao

nije prošao

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 re-factoring 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 [15] – 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 upotrebu, 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 Warren-u [28], 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 re-inž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 re-inž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 re-inž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 ne-funkcionalni 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 [29] objavili su empirijska istraživanja dinamike održavanja softvera.

Istraživanja sugeriraju da vrijede sljedeći, takozvani Lehman-ovi „zakoni“.

1. Nužnost mijenjanja. Softver koji se zaista koristi u stvarnom svijetu nužno se mora

mijenjati jer u protivnom ubrzo postaje neupotrebljiv.

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 Lehman-ov 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 kvalitetan

razvoj

Jeftinije održavanje

Kvalitetniji razvoj

Skuplje održavanjesustav 1

sustav 2

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,

potreban nam je posebna aktivnost koji se naziva upravljanje konfiguracijom. U sljedećim

odjeljcima najprije ćemo opisati svrhu upravljanja konfiguracijom te njegovu podjelu na pod-

aktivnosti. Zatim ćemo detaljnije opisati svaku od pod-aktivnosti.

5.2.1. Svrha upravljanja konfiguracijom, podjela na pod-aktivnosti

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 upotrebi. 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 pod-aktivnosti.

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 upotrebu. Odlučuje se o objavi novog izdanja, pa se zatim softver

priprema za isporuku korisnicima.

Navedene četiri pod-aktivnosti 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 koji 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.

Verzije dijelova

Zahtjevi za promjenama

Gradnja sustava

Upravljanje izdanjima

Upravljanje promjenama

Verzije sustava

Izdanja sustava

Upravljanje verzijama

Slika 5.2: pod-aktivnosti 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 pod-aktivnosti 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.

Pošalji zahtjev

valjan

Zahtjevi za

promjenama

Provjeri zahtjev

Zatvori zahtjev

Registriraj zahtjev

nevaljan

nije prošao

Testiranje softvera

Zatvori zahtjev

Promjena softvera

prošao

Procjena opsega i cijene

Analiza implemen-

tacije

odob-reno

Odobravanje promjene

Zatvori zahtjev

Poslovna procjena

nije odobreno

Podrška korisnicima

Razvoj i održavanje

Change Control Board

Korisnik

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 pod-aktivnost unutar upravljanja konfiguracijom na koju se

naslanjaju sve ostale pod-aktivnosti. 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.

A

Codeline (A)

A1.1 A1.2 A1.3

B

Codeline (B)

B1.1 B1.2 B1.3

C

Codeline (C)

C1.1 C1.2 C1.3

L1

Biblioteke i vanjske komponente

L2 Ex1 Ex2

A B1.2 C1.1

L1 L2 Ex1

Baseline – V1

A1.3 B1.2 C1.2

L1 L2 Ex2

Baseline – V2

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 [16,

17]. 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.

Verzija 1.0 Verzija 1.1

Izvorni tekst za V1.3

Verzija 1.2 Verzija 1.3

D3D2D1

Niz verzija

Način pohranjivanja

Datum stvaranja

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.



check_in

X Y

C

Radni prostor 2

Y P Q

Z X R

check_out

Sustav za upravljanje verzijama

A1.1 B1.1 C1.1

A B C

A B

C

Radni prostor 1

check_in check_out

Alice Bob

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

V2.1.1 V2.1.2

V2.0

Codeline 2

V2.1 B1.3

<branch> V2.2 V2.3

V1.0

Codeline 1

V1.1 V1.2

<merge>

<branch>

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, ako š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.

check_in

Izvršivi sustav

Ciljna platforma

Upravljanje verzijama i gradnja

Sustav za upravljanje verzijama

Poslužitelj za gradnju

Razvojni alati

Privatni radni prostor

Razvojni sustav Ciljni sustav

check_out (co)

co

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, MS Build,

Rational ClearMake i drugi.



Datoteke s podacima

Biblioteke

Automatizirani sustav za gradnju

Prevoditelji i povezivači

Izvršivi ciljni sustav

Rezultati testova

Datoteke s izvornim kodom

Konfigu-racijske datoteke

Izvršivi testovi

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.

Povezanost s alatom za upravljanje verzijama. Alat za gradnju treba tražene verzije

dijelova softvera izvaditi iz repozitorija alata za upravljanje verzijama.

Stvaranje izvršivog sustava. Alat za gradnju treba do kraja povezati object datoteke s

bibliotekama i tako stvoriti izvršivi program.

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 upotrebu

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. Izdane 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-tih ili 80-tih 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 njeno

svakodnevno funkcioniranje. Izlaz iz ove situacije nastoji se pronaći u jednokratnim

radikalnim zahvatima kao što su softversko re-inž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 re-inž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 kojeg današnji programeri ne

razumiju, te za kojeg 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 re-inženjerstvo

Cilj softverskog re-inž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 re-inženjerstva vidi

se na Slici 5.12.

Specifikacija sustava

Bolje strukturirani i razumljiviji

sustav

Novi sustavOblikovanje i

implementacija

Razumijevanje i transformacija

Postojeći sustav

obično softversko inženjerstvo

softversko re-inženjerstvo

Slika 5.12: razlika između softverskog inženjerstva i re-inženjerstva.

Re-inženjerstvo uključuje sljedeće pod-aktivnosti.

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 re-inženjerstvo. Potrebno je ukoliko programi na nekonzistentan ili zastarjeli

na\v cin 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 pod-aktivnosti unutar re-inženjerstva vidi se na Slici 5.13.



Originalni program

Strukturirani program

Dokumentacija programa

Reverzno inženjerstvo

Podatkovno re-inženjerstvo

Modularizacija programa

Reorganizirani podaci

Modularizirani program

Originalni podaci

Prevođenje izvornog koda

Poboljšanje strukture programa

Slika 5.13: pod-aktivnosti unutar softverskog re-inženjerstva.

Kao primjer poboljšanja strukture programa pogledajmo Sliku 5.14. Riječ je o ne-

strukturiranoj verziji kontrolera sustava za grijanje. Kod je gotovo nemoguće razumjeti zbog

brojnih goto naredbi – to je takozvana „špageti logika“. Nakon re-inž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.

Datoteka

1

Datoteka

2Datoteka

3

Datoteka

4Datoteka

5

Datoteka

6

Program 1 Program 2 Program 3

Program 4 Program 5 Program 6 Program 7

Sustav za

upravljanje

bazom

podataka

Program 3 Program 4 Program 5 Program 6

Program 2

Program 1

Program 7

Logički i

fizički modeli

podataka

postaje

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 re-inženjerskog 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 re-inženjerstvo ima svoja ograničenja. Na primjer, sustav razvijen funkcionalnim

pristupom nije moguće pretvoriti u objektni sustav. Nakon re-inženjerstva softver je pogodniji

za održavanje, no ipak se ne može tako dobro održavati kao novi softver. Podatkovno

re-inženjerstvo može biti izuzetno skupo. Menadžment treba procijeniti da li se re-

inženjerstvo uopće isplati, ili je bolje krenuti u razvoj sasvim novog sustava.

5.3.3. Arhitekturna transformacija

Nakon re-inž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.

Baštinjeni

sustav(mainframe)

(terminali)

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


Jezgra

baštinjenog

sustava

(mrežni poslužitelj)

(mreža)

(osobna računala na kojima radi korisničko sučelje i možda još neki

dijelovi baštinjenog 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

Kontrola interakcije

Aplikacijski servisi

Baza podataka

» korisničko sučelje

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



upotrebe. 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

Poslužitelj: validacija, kontrola, servisi, baza podataka

Klijent: prezentacija, validacija, kontrola

Klijent: prezentacija, validacija, kontrola, servisi

Poslužitelj: servisi, baza podataka

Poslužitelj: 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.

Baštinjeni sustav (mrežni poslužitelj)

(mreža)

(osobna računala na kojima radi grafičko korisničko sučelje)

Wrapper (middleware) (mrežni poslužitelj ili osobno računalo)

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-tak 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-tak 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 upotrebu 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 osnovu 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: MS 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 web-u 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 Poglavlju 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-tak 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

Microsoft-ove .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 su u upotrebi 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 događajaGUI

Petlja događaja

Baza poda-taka

Petlja događaja

Plat-forma

Klase koje su specifične za aplikaciju

Callback

Callback Callback

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 MS 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


Korisničko sučelje

Autentikacija

korisnikaIzvještavanje Upravljanje

upitima

Praćenje

inventara

Upravljanje pravilima za rad

s inventarom

Raspore-đivanje

inventara

Upravljanje

transakcijamaBaza podataka

o inventaru

Interakcija

Upravljanje ulazom i izlazom

Upravljanje inventarom

Upravljanje bazom podataka

Slika 6.2: generička arhitektura produktne linije sustava za upravljanje inventarom.

Autentikacija

operatora

Upravljanje kartama i

planiranje ruta

Upravljanje

upitima

Praćenje statusa vozila

Bilježenje incidenata

Lociranje vozila

Upravljanje

transakcijama

Baza podataka o

vozilima

Interakcija

Upravljanje ulazom i izlazom

Upravljanje inventarom

Upravljanje bazom podataka

Sučelje za operatora

Sučelje za komunikacijski

sustav

Generator

izvještaja

Raspo-ređivanje

vozila

Upravljanje opremom u vozilima

Baza podataka o

opremi

Baza

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.



Otkrij zahtjeve korisnika

Izaberi najsličnijeg

člana produktne linije

Ponovo pregovaraj s korisnikom o zahtjevima

Isporuči novog člana produktne

linije

Promijeni postojećeg člana 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 ju.

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: MS Word, MS 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.

Procesi

Poslovna pravila

Upravljanje odnosima s

kupcima

Nabava sirovina

Upravljanje proizvodnjom

Isporuka proizvoda

Procesi Procesi Procesi

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

E-commerce sustav

AdapterSustav ureda

za nabavu

E-mail sustav

Web preglednik

E-mail klijent

Klijent

Adapter

Poslužitelj

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 poglavlju 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-tim 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 potrebne veće i

zatvorenije cjeline od objekata. Komponente [18] 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, meta-podatke.

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 de-registriranje

š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.



PrintService

Print

GetQueue

Remove

Transfer

Register

Unregister

GetPDfile

PrinterInt

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

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čin 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 su mnogo više u upotrebi „proprietary” softveri poput

Microsoft-ovog .NET ili Sun-ovog 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


Upravljanje komponentama

Upravljanje transakcijama

Perzistentnost

Adresiranje Definicija sučelja

Upravljanje resursima

Istovremeni rad

Upravljanje iznimkama

Komunikacija komponenti

Platformski servisi

Servisi za podršku

Sigurnost

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 ponovnu upotrebu

Certificiranje komponenti

CBSE s ponovnom upotrebom

Upravljanje komponentama

Nabava komponenti

Repozitorij

komponenti

Vanjski izvor

Slika 6.9: procesi unutar CBSE.



Kao što vidimo na Slici 6.9, unutar CPSE 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.

Skiciraj zahtjeve na sustav

Identificiraj komponente-

kandidate

Prilagodi zahtjeve u skladu

s otkrivenim komponentama

Opetidentificiraj

komponente-kandidate

Komponiraj komponente i

tako stvori sustav

Oblikovanje arhitekture

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, zatevi 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 [30]. 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 komponenti

Izbor komponenti

Validacija 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 koji 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 koja koordiniraju pozive usluga. Pritom A i B ne ovise jedna o drugoj i ne pozivaju se

međusobno.

A

B

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.

A

B

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


mapper

displayMap (string streetName,

string streetNo, int scale)

mapDB (string command)

addressFinder

string location (string pn)

string owner (string pn)

string propertyType (string pn)

phoneDatabase (string command)

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.

Data Collector

addSensor

removeSensor

startSensor

stopSensor

testSensor

initialize

sensorManagement

sensorData

report

listAll

Adapter

start

stop

getData

Sensor

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 bez-parametarskih 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.

Data Collection Data Base

Report

Data Collection

Data Management

Report Generator

Report

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 poglavlju 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 web-a u 1990-tim godinama donijela je revoluciju u mogućnostima razmjene podataka

preko Interneta. No podaci i usluge s web-a isprva su bili dostupni samo web preglednicima.

Web servisi [19] predstavljaju nadogradnju klasične web tehnologije. Njime sadržaji s web-a

postaju dostupni i drugim programima. Točnije rečeno, web servis je resurs na web-u, 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) [20]. 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.

Tražiteljusluga

Registarservisa

Dobavljačusluga

otkrivanje objavljivanje

povezivanje (SOAP) Servis

(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.



Primanje podataka

Prima informacije iz

vanjskog servisa

Radio

Pretvara digitalne

informacije u radio signal

Mobilni info servis

Objedinjuje informacije

Slanje podataka

Šalje GPS koordinate i zahtjev za

informacijama vanjskom servisu

Lociranje

Otkriva GPS koordinate automobila

Korisničko sučelje

Prima zahtjev od korisnika

Informacije o prometu na cesti

Otkrivanje servisa

Pronalazi dostupne servise

Info o prometu

Lociranje ceste

Prevoditelj

Info o

vremenu

Druge

info

Prevedene

Informacije

GPS koord

GPS koord

GPS koord

Naredba,

Jezik,

GPS koord

Softverski sustav

unutar automobila

Jezik,

Informacije

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.

Transport (HTTP, HTTPS, SMTP, ...)

Definicija servisa (UDDI, WSDL)

Razmjena poruka (SOAP)

Proces (WS-BPEL)

Podrška (WS-Security, WS Addressing, ...)

XML tehnologije (XML, XSD, XSLT, ...)

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 web-u 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.



Konkretna implementacija

Apstraktno sučelje

Uvod

WSDL definicija servisa

XML deklaracije za prostore imena

deklaracije tipova,

deklaracije sučelja,

deklaracije poruka

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 [21].

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 staja 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

kandidata za

servis

Oblikovanje sučelja servisa

Implementacija i instalacija

servisa

Zahtjevi na servisSpecifikacija

sučelja servisa

Validirani i 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čelje 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 MS 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 ako 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

workflow-a

Otkrivanje servisa

Izbor servisa

Polazni workflowLista servisa

kandidataSpecifikacije

izabranih servisa

Profinjenje

workflow-a

Stvaranje workflow-programa

Testiranje aplikacije

Profinjeni

workflowIzvršivi workflow

Aplikacija koja je spremna za upotrebu

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 [22]. 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

za let

Rezerviraj

sobu u hotelu

Pretraži informacije

o predstavama

Naruči rent-

a-car ili taksi

Kupi ulaznice

za kazalište

Datum i vrijeme dolaska i odlaska

Lokacija hotela

Datumi, preferencije

Slika 6.26: workflow aplikacije za organiziranje putovanja avionom.

Hoteli

DajZahtjeve

Hoteli

ProvjeriRaspoloživostHoteli

RezervirajSobe

Hoteli

NijeRaspoloživo

Hoteli

PotvrdiRezervaciju

Kupac

Pokušaj ponovo

Ima soba

Nema sobaOdustani

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, 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.: Essentials of Software Engineering, 2-nd Edition. Jones & Bartlett

Publishers, Sudbury MA, USA, 2009. ISBN 0-7637-8534-2.

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. Beck K: Test Driven Development – By Example. Addison-Wesley, Boston MA, 2002.

ISBN: 0-321-14653-0.

15. Massol V., Husted T.: JUnit in Action. 2-nd Edition. Manning Publications, Stamford CT,

2010. ISBN: 1-935182-02-1.

16. Vesperman J.: Essential CVS. O’Reilly and Associates, Sebastopol CA, 2003. ISBN:

0596004591.

17. Pilato C.M., Collins-Sussman B., Fitzpatrick B.W.: Version Control with Subversion. 2-

nd Edition. O’Reilly and Associates, Sebastopol CA, 2008. ISBN: 0596510330.

18. Szyperski, C.: Component Software – Beyond Object-oriented Programming. 2-nd

edition. Addison-Wesley, Harlow UK, 2001. ISBN: 0-201-17888-5.

19. Newcomer E., Lomow G.: Understanding SOA with Web Services. Addison-Wesley,

Boston MA, 2005. ISBN: 0-321-18086-0.

20. Erl T.: Service-Oriented Architecture – Concepts, Technology and Design. Prentice Ha..,

Upper Saddle River NJ, 2005. ISBN: 0-13-185858-0.

http://www.visual-paradigm.com/support/documents

Robert Manger


21. Richardson L., Ruby S.: RESTful Web Services. O’Reilly media Inc, Sebastopol CA,

2007. ISBN: 0-596-52926-0.

22. White S.A., Miers D.: BPMN Modeling and Reference Guide – Understanding and Using

BPMN. Future Strategies Inc, Lighthouse Point FL, 2008. ISBN: 0-9777527-2-0.

Klasična djela i dodatni sadržaji vezani uz softversko inženjerstvo:

23. Brooks F.P.: The Mythical Man Month - Essays on Software Engineering, Anniversary

Edition. Addison-Wesley, Reading MA, USA, 1995. ISBN 0-201-83595-9.

24. 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

25. DeMarco T. Structured Analysis and System Specification. Yourdon Press, New York

NY, USA, 1978. ISBN 0138543801.

26. 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.

27. 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.

28. Warren I.E.: The Renaissance of Legacy Systems. Springer, London UK, 1998. ISBN:

1852330600.

29. Lehman M.M., Belady L.: Program Evolution – Processes of Software Change. Academic

Press, London, 1985. ISBN: 0124424406.

30. Jacobson I., Griss M., Jonsson P.: Software Reuse. Addison-Wesley, Reading MA, USA,

1997. ISBN: 0-201-92476-5.

http://www.acm.org/about/se-code

Documents

Softversko inzenjerstvo - Zagreb PMF