SI Skripta v2

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

Robert Manger

SOFTVERSKO INŽENJERSTVO Skripta

Nadopunjeno drugo izdanje Zagreb, rujan 2013.

Robert Manger

2

PMF – Matematički odsjek

Softversko inženjerstvo - skripta

Sadržaj Predgovor ....................................................................................................................................... 7 1.

Uvod u softversko inženjerstvo ............................................................................................ 9 1.1.

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.

2.

Osnovni pojmovi vezani uz softversko inženjerstvo ................................................... 9

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

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


3

Robert Manger 3.

Oblikovanje i implementacija ............................................................................................ 55 3.1.

3.1.1.

Podaktivnosti unutar oblikovanja ....................................................................... 55

3.1.2.

Dekompozicija većih dijelova u manje .............................................................. 56

3.1.3.

Modeliranje tijekom oblikovanja ....................................................................... 58

3.1.4.

Novi trendovi vezani uz implementaciju ........................................................... 59

3.2.

Podsustavi i odnosi među njima ......................................................................... 60

3.2.2.

Strukturiranje sustava ......................................................................................... 61

3.2.3.

Modeliranje kontrole .......................................................................................... 66

Objektni pristup oblikovanju ..................................................................................... 69

3.3.1.

Svojstva objektno oblikovanog softvera ............................................................ 69

3.3.2.

Koraci unutar objektnog oblikovanja ................................................................. 70

3.3.3.

Primjer objektnog oblikovanja ........................................................................... 71

3.3.4.

Obrasci za oblikovanje ....................................................................................... 76

3.4.

Oblikovanje distribuiranih sustava ............................................................................ 79

3.4.1.

Prednosti i mane distribuiranih sustava .............................................................. 79

3.4.2.

Arhitekture s klijentima i poslužiteljima ............................................................ 80

3.4.3.

Druge distribuirane arhitekture .......................................................................... 83

3.5.

Oblikovanje i implementacija uklopljenih sustava .................................................... 88

3.5.1.

Osobine uklopljenih sustava............................................................................... 88

3.5.2.

Arhitekture uklopljenih sustava ......................................................................... 91

3.5.3.

Analiza vremenskih ograničenja za procese ...................................................... 94

3.5.4.

Implementacija uklopljenih sustava ................................................................... 97

Verifikacija i validacija ....................................................................................................... 99 4.1.

Općenito o verifikaciji i validaciji ............................................................................. 99

4.1.1.

Metode za verifikaciju i validaciju ................................................................... 99

4.1.2.

Mjesto verifikacije i validacije u softverskom procesu .................................... 100

4.1.3.

Odnos verifikacije, validacije i debuggiranja ................................................... 101

4.2.

Statička verifikacija ................................................................................................. 101

4.2.1.

Inspekcija programa ......................................................................................... 101

4.2.2.

Automatska statička analiza ............................................................................. 103

4.2.3.

Formalna verifikacija ....................................................................................... 104

4.3.

4

Oblikovanje arhitekture ............................................................................................. 60

3.2.1.

3.3.

4.

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

Testiranje softvera ................................................................................................... 105

4.3.1.

Vrste i faze testiranja ........................................................................................ 105

4.3.2.

Testiranje dijelova softvera .............................................................................. 108

4.3.3.

Testiranje integracije ........................................................................................ 112

4.3.4.

Razvoj softvera vođen testiranjem ................................................................... 115 PMF – Matematički odsjek

Softversko inženjerstvo - skripta 5.

Održavanje i evolucija ...................................................................................................... 117 5.1.

5.1.1.

Strategije mijenjanja softvera ........................................................................... 117

5.1.2.

Vrste i dinamika održavanja softvera ............................................................... 118

5.1.3.

Cijena održavanja softvera ............................................................................... 118

5.1.4.

Održavanje unutar agilnih metoda ................................................................... 119

5.2.

Upravljanje konfiguracijom ..................................................................................... 120

5.2.1.

Svrha upravljanja konfiguracijom, podjela na podaktivnosti........................... 120

5.2.2.

Upravljanje promjenama .................................................................................. 122

5.2.3.

Upravljanje verzijama ...................................................................................... 125

5.2.4.

Gradnja sustava ................................................................................................ 128

5.2.5.

Upravljanje izdanjima ...................................................................................... 130

5.3.

6.

Općenito o održavanju i evoluciji ............................................................................ 117

Baštinjeni softver i njegovo mijenjanje ................................................................... 131

5.3.1.

Građa i osobine baštinjenog softvera ............................................................... 131

5.3.2.

Softversko reinženjerstvo ................................................................................. 132

5.3.3.

Arhitekturna transformacija ............................................................................. 135

Ponovna upotreba ............................................................................................................. 139 6.1.

Općenito o ponovnoj upotrebi ................................................................................. 139

6.1.1.

Svojstva i oblici ponovne upotrebe .................................................................. 139

6.1.2.

Popis tehnika za ponovnu upotrebu ................................................................. 140

6.1.3.

Odabir tehnike za ponovnu upotrebu ............................................................... 141

6.2.

Neki tradicionalni oblici ponovne upotrebe ............................................................ 141

6.2.1.

Aplikacijski okviri ............................................................................................ 141

6.2.2.

Produktne linije ................................................................................................ 143

6.2.3.

Upotreba COTS produkata ............................................................................... 145

6.3.

Razvoj softvera zasnovan na komponentama .......................................................... 147

6.3.1.

Komponente i njihovo korištenje ..................................................................... 148

6.3.2.

Softverski procesi zasnovani na komponentama ............................................. 150

6.3.3.

Kompozicija komponenti ................................................................................. 154

6.4.

Razvoj aplikacija pomoću web servisa .................................................................... 159

6.4.1.

Web servisi kao temelj nove distribuirane arhitekture ..................................... 159

6.4.2.

Standardi vezani uz web servise....................................................................... 161

6.4.3.

Usporedba web servisa i komponenti............................................................... 163

6.4.4.

Softverski procesi vezani uz web servise ......................................................... 164

Literatura ................................................................................................................................... 171


5

Robert Manger

6



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


7

Robert Manger

8



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.


9

Robert Manger 

Sistemsko inženjerstvo (system engineering). Bavi se razvojem složenih sustava koji se sastojtoje od hardvera, softvera i ljudskih aktivnosti. Softverski inženjer mora svoje softversko rješenje uklopiti u takav složeniji sustav.

Softversko inženjerstvo također je i profesija. U mnogim zemljama softverski inženjeri organizirani su u strukovne udruge koje štite njihova prava ali donekle i ograničavaju slobodu njihovog djelovanja. Primjeri takvih udruga su ACM, IEEE-CS i British Computer Society. Udruge donose pravila ponašanja za svoje članove. Na web stranici [27] može se naći etički kodeks softverskih inženjera kojeg su zajednički usvojili ACM i IEEE-CS. Softversko inženjerstvo počelo se razvijati krajem 60-ih godina 20. stoljeća. Sam naziv izgleda da je bio skovan na jednoj NATO konferenciji u Njemačkoj 1968. godine. Disciplina je nastala kao odgovor na takozvanu „softversku krizu“. Naime, pojavom računala treće generacije (na primjer IBM serija 360) stvorila se potreba za složenijim softverom (na primjer multi-tasking operacijski sustav). Pokrenuti razvojni projekti višestruko su premašili planirane troškove i rokove. Vidjelo se da se dotadašnje neformalne tehnike individualnog programiranja ne mogu uspješno „skalirati“ na velike programe gdje sudjeluje velik broj programera. Osjećala se potreba za metodama razvoja softvera koje bi bile u stanju kontrolirati kompleksnost velikog softverskog projekta. Stanje svijesti iz tih vremena plastično je opisano u čuvenoj knjizi [26]. Od 60-ih godina 20. stoljeća do danas softversko inženjerstvo prešlo je dug put. Ispočetka su se predlagale metode razvoja softvera oblikovane po analogiji s metodama iz tradicionalnih tehničkih struka (na primjer mostogradnja). Kasnije se uvidjelo da je softver po mnogočemu specifičan te da zahtijeva drukčije pristupe. Razvijali su se novi programski jezici, bolji načini utvrđivanja zahtjeva, grafički jezici za modeliranje, formalne metode za specifikaciju i verifikaciju, pouzdaniji načini vođenja projekata i procjene troškova, alati koji nastoje automatizirati proces razvoja softvera. Zahvaljujući takvom razvoju, softversko inženjerstvo uspjelo se etablirati kao važan dio tehnike i računarstva. Softver se u današnje vrijeme proizvodi daleko predvidljivije i efikasnije nego prije. Ipak, još uvijek postoji širok prostor za poboljšanje. Važna osobina softverskog inženjerstva je da u njemu nema „jednoumlja“ ni jednoobraznosti. Za razliku od matematike gdje se proučavaju nepobitne istine, u softverskom inženjerstvu razvijaju se različite ideje i pristupi koji su često u međusobnom nesuglasju. Glavni razlog za takvu raznolikost pristupa je raznolikost samih softverskih produkata – zaista, teško je očekivati da se sve vrste softvera mogu razvijati na isti način. Drugi razlog za raznolikost je činjenica da softversko inženjerstvo još uvijek nije doseglo svoju zrelu fazu – ta disciplina se i ovog trenutka intenzivno razvija, a nove spoznaje stalno revidiraju stare. 1.1.2. Softverski proces, metode i alati Softverski proces je skup aktivnosti i pripadnih rezultata čiji cilj je razvoj ili evolucija softvera. Osnovne aktivnosti unutar softverskog procesa su: utvrđivanje zahtjeva, oblikovanje, implementacija, verifikacija i validacija te održavanje odnosno evolucija. Model za softverski proces je idealizirani prikaz softverskog procesa, kojim se određuje poželjan način odvijanja i međusobnog povezivanja osnovnih aktivnosti. Na primjer, model

10


Softversko inženjerstvo - skripta može zahtijevati sekvencijalno odnosno simultano odvijanje aktivnosti. Najvažniji modeli bit će opisani u potpoglavlju 1.2. Metoda razvoja softvera je profinjenje i konkretizacija odabranog modela za softverski proces. Metoda uvodi specifičnu terminologiju. Također, ona dijeli osnovne aktivnosti u podaktivnosti te propisuje što se sve mora raditi unutar pojedine podaktivnosti. Dalje, metoda uvodi konkretan način dokumentiranja rezultata podaktivnosti (dijagrami, tabele, pseudojezik, … ) te daje naputke vezane uz organizaciju rada, stil oblikovanja, stil programiranja i tako dalje. Više o metodama razvoja softvera bit će rečeno u potpoglavlju 1.3. CASE alati (Computer Aided Software Engineering) su softverski paketi koji daju automatiziranu podršku za pojedine aktivnosti unutar softverskog procesa. Obično su napravljeni u skladu s određenom metodom razvoja softvera, implementiraju pravila iz te metode, sadrže editore za odgovarajuće dijagrame i služe za izradu odgovarajuće dokumentacije. Dijele se u dvije vrste.  Upper-CASE alati daju podršku za početne aktivnosti unutar softverskog procesa, kao što su utvrđivanje zahtjeva i oblikovanje.  Lower-CASE alati podržavaju samu realizaciju softvera, dakle programiranje, verifikaciju i validaciju te eventualno održavanje. Na vježbama iz ovog kolegija obradit ćemo jednu konkretnu metodu razvoja softvera, koja se zove UP i koja je potpomognuta grafičkim jezikom UML. Služit ćemo se upper-CASE alatom Visual Paradigm [11] za modeliranje sustava i crtanje UML dijagrama. Na vježbama iz drugih kolegija studenti su imali prilike raditi s lower-CASE alatom Microsoft Visual Studio [12] koji daje podršku za implementaciju i verifikaciju softvera pisanog u jezicima poput C++ ili C#. 1.1.3. Dokumentacija softvera Kad smo govorili o softverskom produktu rekli smo da se on sastoji od računalnih programa i pripadne dokumentacije. Dakle, razvoj softvera ne svodi se samo na razvoj programa nego također i na sastavljanje dokumenata koji prate te programe. Dokumentacija je sastavni i nezaobilazni dio onoga što softverski inženjeri proizvode. Dokumentacija softvera može se podijeliti u dvije kategorije.  Sistemska dokumentacija namijenjena je softverskim inženjerima ili članovima razvojnog tima, opisuje zahtjeve ili građu ili funkcioniranje sustava te omogućuje sam razvoj softvera i njegovo kasnije održavanje.  Korisnička dokumentacija namijenjena je korisnicima, omogućuje im da koriste sustav te opisuje funkcije sustava na njima razumljiv način. U daljnjim poglavljima opisat ćemo nekoliko primjera dokumenata koji spadaju u sistemsku dokumentaciju. Na primjer to su sljedeći dokumenti.  Dokument o zahtjevima. Opisuje zahtjeve na sustav, dakle što sustav treba raditi i uz koja ograničenja.  Dizajn sustava (projektna dokumentacija). Nastaje kao rezultat oblikovanja sustava. Opisuje kako sustav treba biti građen te kako treba raditi da bi obavio svoje funkcije.


11

Robert Manger  

Plan testiranja. Sadrži primjere test podataka i odgovarajućih očekivanih rezultata. Služi nakon bilo kakve promjene programa za provjeru da li je sačuvana dotadašnja funkcionalnost programa. Izvorni tekst programa, pisan u programskom jeziku i nadopunjen odgovarajućim komentarima. Nastaje kao rezultat implementacije sustava i na najizravniji način dokumentira sustav.

Kad god koristimo neki generički softverski produkt, na primjer operacijski sustav ili paket za uredsko poslovanje ili sustav za upravljanje bazom podataka, susrećemo se s raznim dokumentima koji spadaju u korisničku dokumentaciju. Evo nekoliko primjera takvih dokumenata.  Funkcionalni opis. Namijenjen je evaluatorima sustava, dakle osobama koje će odlučiti da li da se koristi taj sustav ili neki drugi. Daje se grubi opis što sustav može a što ne može raditi. Priloženi su primjeri, tabele i dijagrami. Ne objašnjavaju se operativni detalji.  Vodič za instalaciju. Namijenjen je sistem-administratoru ili korisniku. Opisuje instalaciju sustava na zadanoj vrsti računala. Sadrži opis distribucijskog medija, definiciju minimalne hardverske i softverske konfiguracije potrebne za pokretanje sustava, proceduru instaliranja i podešavanja.  Uvodni priručnik. Namijenjen je novim korisnicima. Daje neformalni uvod u sustav te opisuje njegovu „normalnu“ uporabu. Pisan je u formi „tečaja“, sadrži mnogo primjera, te uputa kako izbjeći uobičajene greške.  Referentni priručnik. Namijenjen je iskusnim korisnicima. U potpunosti i na vrlo precizan način dokumentira sve funkcije sustava, sve oblike njegove uporabe te sve greške koje mogu nastupiti. Nije u formi tečaja. Stil je formalan, struktura je stroga. Snalaženje u tekstu osigurano je preko indeksa pojmova.  Priručnik za administriranje. Namijenjen je sistem-administratorima ili operatorima. Opisuje aktivnosti poput backup-a, upravljanja resursima, praćenja performansi, podešavanja rada, evidentiranja korisnika, postavljanja zaštite. Izradu dokumentacije jednim dijelom je moguće automatizirati ili barem olakšati korištenjem CASE-alata. No za konačno oblikovanje dokumenata potrebni su nam standardni uredski alati poput tekst procesora ili alata za crtanje dijagrama. Osim u obliku dokumenata (bilo papirnatih bilo elektroničkih) dokumentacija može postojati i u on-line obliku, dakle ona može biti izravno dostupna iz samog softvera koji opisuje.

1.2. Modeli za softverski proces Zajednička osobina svih modela za softverski proces je da se oni u većoj ili manjoj mjeri zasnivaju na otprilike istim osnovnim aktivnostima. Zaista, to su sljedeće aktivnosti.  Utvrđivanje zahtjeva (specifikacija). Analiziraju se zahtjevi korisnika. Utvrđuje se što softver treba raditi.  Oblikovanje (design). Oblikuje se građa sustava, način rada njegovih dijelova te sučelje između dijelova. Dakle projektira se rješenje koje određuje kako će softver raditi.  Implementacija (programiranje). Oblikovano rješenje realizira se uz pomoć raspoloživih programskih jezika i alata.  Verifikacija i validacija. Provjerava se da li softver radi prema specifikaciji, odnosno da li radi ono što korisnik želi. Obično se svodi na testiranje, mada postoje i druge tehnike.  Održavanje odnosno evolucija. Nakon uvođenja u uporabu, softver se dalje popravlja, mijenja i nadograđuje, u skladu s promijenjenim potrebama korisnika. 12



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

Utvrđivanje zahtjeva (specifikacija)

Dokument o zahtjevima

Oblikovanje (design)

Dizajn sustava Moduli

Programiranje i testiranje modula

Integracija modula i testiranje sustava

Sustav

Puštanje u rad i održavanje

Slika 1.1: softverski proces prema modelu vodopada.

Model je dobio ime zbog oblika dijagrama. Vidimo da se aktivnosti odvijaju kao faze sekvencijalno jedna iza druge. Svaka faza daje neki rezultat koji „teče“ po vodopadu i predstavlja polazište za iduću fazu. Makar je na slici naznačena mogućnost povratka u raniju fazu (u slučaju naknadnog otkrivanja greške), ta mogućnost samo se iznimno koristi. Povratak je nepoželjan jer remeti normalni tijek procesa te izaziva kašnjenje. Prednosti modela vodopada su sljedeće.  Model omogućuje detaljno planiranje cijelog softverskog procesa i podjelu poslova na velik broj suradnika.  Lagano se može utvrditi stanje u kojem se proces trenutno nalazi.  Zato je model je dobro prihvaćen od menadžera. Mane modela vodopada su sljedeće.  Navedene faze u praksi je teško razdvojiti, pa dolazi do naknadnog otkrivanja grešaka i nepoželjnog vraćanja u prethodne faze.  Zbog tendencije da se zbog poštovanja rokova u određenom trenutku „zamrzne“ pojedina faza, dešava se sustav nastavlja razvijati u nezadovoljavajućem obliku.  Proces je spor, pa se može dogoditi da u trenutku puštanja u rad sustav već bude neažuran i zastario.


13

Robert Manger Zbog navedenih prednosti te unatoč navedenim manama, model se često koristi u praksi. Model je pogodan onda kad treba razviti veliki sustav s relativno jednostavnim i jasnim zahtjevima uz pomoć velikog broja programera. 1.2.2. Modeli evolucijskog i inkrementalnog razvoja Model evolucijskog razvoja (evolutionary development) nastao je kao protuteža modelu vodopada. U tom modelu na osnovu približnog opisa problema razvija se polazna verzija sustava koja se pokazuje korisniku. Temeljem korisnikovih primjedbi, ta polazna verzija se poboljšava, opet pokazuje, i tako dalje. Nakon dovoljnog broja iteracija dobiva se konačna verzija sustava. Unutar svake iteracije, osnovne aktivnosti se obavljaju simultano i ne daju se razdvojiti. Postupak je ilustriran slikom 1.2.

Polazna verzija

simultane aktivnosti Utvrđivanje zahtjeva (specifikacija)

Oblikovanje (design)

Približni opis

Privremene verzije Implementacija

Verifikacija, validacija Konačna verzija

Slika 1.2: evolucijski razvoj softvera. Evolucijski razvoj čiji cilj je da se s korisnikom istraže zahtjevi te zaista proizvede konačni sustav zove se istraživačko programiranje. Ukoliko je jedini cilj istraživanje zahtjeva (nakon čega slijedi oblikovanje i implementacija modelom vodopada), tada je riječ o prototipiranju vidi potpoglavlje 2.2. Prednosti modela evolucijskog razvoja su sljedeće.  Model je u stanju proizvesti brzi odgovor na zahtjeve korisnika.  Razvoj je moguć i onda kad su zahtjevi ispočetka nejasni.  Specifikacija se može postepeno razvijati u skladu sa sve boljim korisnikovim razumijevanjem problema. Mane modela evolucijskog razvoja su sljedeće.  Proces nije transparentan za menadžere, naime oni ne mogu ocijeniti koliki dio posla je napravljen i kad će sustav biti gotov.  Konačni sustav obično je loše strukturiran zbog stalnih promjena te je nepogodan za kasnije održavanje.  Zahtijevaju se posebni alati i natprosječni softverski inženjeri.

14


Softversko inženjerstvo - skripta 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.

Definiraj okvirne zahtjeve

Rasporedi zahtjeve na inkremente

Oblikuj arhitekturu sustava

Specificiraj, oblikuj i implementiraj novi inkrement

Verificiraj i validiraj novi inkrement

Integriraj novi inkrement

Konačni sustav

sustav je nedovršen

Slika 1.3 inkrementalni razvoj softvera. Prednosti modela inkrementalnog razvoja su sljedeće.  Proces je još uvijek prilično transparentan za menadžere, budući da je vidljivo do kojeg smo inkrementa došli.  Korisnici ne moraju dugo čekati da bi dobili prvi inkrement koji zadovoljava njihove najpreče potrebe. Razvoj slijedi prioritete. Mane modela inkrementalnog razvoja su sljedeće.  Koji put je teško podijeliti korisničke zahtjeve u smislene inkremente.  Budući da cjelokupni zahtjevi nisu dovoljno razrađeni na početku, teško je odrediti zajedničke module koji su potrebni raznim inkrementima i koji bi morali biti implementirani u prvom inkrementu. Ipak, ovo je vrlo uporabljiv model koji se intenzivno koristi u praksi. Svi generički softverski paketi poput Microsoft Office-a i slični zapravo su se razvijali u inkrementima. Svaka njihova nova verzija donosila je nove mogućnosti. 1.2.3. Modeli formalnog i grafičkog razvoja Model formalnog razvoja (formal systems development) zasniva se na korištenju takozvanih formalnih metoda za razvoj softvera. Zahtjevi se precizno definiraju na formalni način, korištenjem nedvosmislene matematičke notacije. Zatim se ta formalna specifikacija transformira do programa, nizom koraka koji čuvaju korektnost. Cijeli proces prikazan je u slikom 1.4, dok je ideja formalnih transformacija detaljnije ilustrirana slikom 1.5. PMF – Matematički odsjek

15

Robert Manger Formalna specifikacija

Neformalna specifikacija

Formalne transformacije

Integracija i testiranje sustava

Slika 1.4: proces formalnog razvoja softvera. Formalne transformacije: Formalna specifikacija softvera

D1

R3

R2

R1

D2

Izvršivi program

D3

D4

Sve detaljnije reprezntacije sustava Dokazi korektnosti transformacija

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



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

Utvrđivanje zahtjeva

Analiza raspoloživih dijelova

Modifikacija zahtjeva

Oblikovanje sustava uz ponovnu upotrebu dijelova

Implementacija i integracija

Verifikacija i validacija sustava

Slika 1.7: proces razvoja softvera uz ponovnu upotrebu. Prednosti modela usmjerenog na ponovnu upotrebu su sljedeće.  Smanjuje se količina softvera kojeg stvarno treba razviti te se tako smanjuje vrijeme, trošak i rizik.  Stavlja se oslonac na provjerene i dobro testirane dijelove softvera. Mane modela usmjerenog na ponovnu upotrebu su sljedeće.  Zbog kompromisa u specifikaciji moguće je da sustav neće u potpunosti odgovoriti stvarnim potrebama korisnika.  Djelomično je izgubljena kontrola nad evolucijom sustava, budući da ne upravljamo razvojem novih verzija korištenih dijelova.


17

Robert Manger Očekuje se da će ovaj model ipak postati prevladavajući u 21. stoljeću, budući da je broj gotovih rješenja sve veći, a korisnici imaju sve manje vremena za čekanje rješenja. Ideja ponovne upotrebe te razni načini njene realizacije detaljno će biti obrađena u poglavlju 6.

1.3. Klasične i agilne metode razvoja softvera Rekli smo da se rad softverskog tima obično organizira u skladu s nekom metodom razvoja softvera. Svaka od metoda slijedi jedan od modela za softverski proces ili kombinira više modela. Osnovne aktivnosti iz modela podijeljene su u manje aktivnosti. Propisuje se način odvijanja svake aktivnosti te način njenog dokumentiranja. U sljedećim odjeljcima navodimo osnovna svojstva pojedinih vrsta metoda te detaljnije opisujemo dvije danas aktualne metode: UP odnosno XP. 1.3.1. Vrste metoda i njihova svojstva Od početka softverskog inženjerstva do danas pojavilo se nekoliko stotina metoda za razvoj softvera. Njih ugrubo možemo podijeliti u klasične i agilne metode. Klasične metode pojavile su se još u 70-im godinama 20. stoljeća, a razvijaju se i danas. One se odlikuju sljedećim svojstvima.  Razvoj softvera promatra se kao pažljivo planirani proces koji ima svoj početak i kraj. U tom procesu u potpunosti se utvrđuju zahtjevi te se softver realizira u skladu s njima.  Provodi se upravljanje projektom. Određuje se precizni plan aktivnosti, po potrebi i za dulji vremenski period unaprijed. Određuje se raspored ljudi i resursa po aktivnostima.  Inzistira se na urednom dokumentiranju svih aktivnosti i svih proizvedenih dijelova softvera. Klasične metode dalje se dijele na funkcionalno-orijentirane te na objektno-orijentirane. Starije funkcionalno-orijentirane metode poput Yourdonove ili Jacksonove JSD (80-e godine 20. stoljeća) slijede logiku starijih funkcionalno-orijentiranih programskih jezika (Cobol, C, Fortran). Novije objektno-orijentirane metode predstavljaju nadgradnju objektno-orijentiranih programskih jezika (Java, C++, C#) i danas su se integrirale u zajednički standard UP (Unified Process - Booch, Rumbaugh, Jacobson - 90-e godine) koji se oslanja na grafički jezik UML (Unified Modelling Language). Kao protuteža klasičnim metodama, početkom 21. stoljeća pojavile su se agilne metode. Njihova glavna namjera bila je ubrzati razvoj softvera i izbjeći nepotrebnu administraciju. Agilne metode imaju sljedeća svojstva.  Razvoj softvera promatra se kao kontinuirani niz iteracija čiji broj nije moguće predvidjeti. Svaka iteracija usklađuje sustav s trenutnim zahtjevima. Zahtjevi se stalno mijenjaju, ne postoji cjelovita ili konačna specifikacija.  Ne postoji upravljanje projektom u pravom smislu riječi. Aktivnosti se dogovaraju s korisnicima te se odvijaju uz njihovo aktivno sudjelovanje. Planiranje je kratkoročno – jedan ili dva tjedna unaprijed.  Izbjegavaju se svi oblici dokumentacije osim onih koji se mogu automatski generirati iz programa. Smatra se da sam program u izvornom obliku predstavlja svoju najpouzdaniju dokumentaciju.

18


Softversko inženjerstvo - skripta Najpopularnija agilna metoda je Extreme Programming – XP. Također je poznata metoda Scrum koja se uglavnom bavi agilnim vođenjem projekta i može se kombinirati s XP. Ima i pokušaja da se definira agilna varijanta inače klasične metode UP. U literaturi su zabilježena brojna istraživanja koja mjere i uspoređuju učinkovitost pojedinih metoda za razvoj softvera. Prema tim istraživanjima, agilne metode imaju svojih prednosti kad je riječ o malim i kratkoročnim projektima u brzo promjenjivom poslovnom okruženju. No nije se još dokazalo da se agilne metode mogu uspješno skalirati na velike projekte. Zato se danas veliki softverski sustavi i dalje razvijaju klasičnim i to objektno-orijentiranim metodama. Agilne metode našle su svoje mjesto na primjer u razvoju web aplikacija ili u razvoju mobilnih aplikacija. 1.3.2. Primjer klasične metode Kao primjer klasične metode razvoja softvera opisat ćemo Unified Process – UP. Riječ je o „public domain“ verziji komercijalne metode Rational Unified Process – RUP. I UP i RUP koriste se za razvoj objektno-orijentiranih sustava. UP je nastala na samom kraju 20. Stoljeća u tvrtci Rational Corporation koja je danas dio IBM-a. Stvorio ju je Ivar Jacobson u suradnji s Grady Boochom i Jamesom Rumbaughom. Ime je odabrano zato što je UP objedinio nekoliko prijašnjih metoda istih autora. UP je u bliskoj vezi s grafičkim jezikom UML – vidi potpoglavlje 2.3 – obje tvorevine razvijene su u okviru istog projekta s namjerom da budu komplementi jedna drugoj. Zaista, UP određuje kako će se odvijati proces razvoja softvera, a UML omogućuje da se rezultati tog razvoja dokumentiraju.

Slika 1.8: Faze i temeljne aktivnosti unutar UP.


19

Robert Manger Proces razvoja softvera u skladu s UP sastoji se od 4 faze (phases) koje se realiziraju u vremenskom slijedu jedna iza druge. Pojedina faza završava onda kad se dosegne njezin međaš (milestone), dakle kad se postignu njeni ciljevi. Svaka faza realizira se kroz simultano i iterativno odvijanje 5 temeljnih aktivnosti (core workflows). Sve je to ilustrirano slikom 1.8. Zbog postojanja vremenski odvojenih faza mogli bismo reći da UP uspostavlja softverski proces nalik na model vodopada. S druge strane, iteracija temeljnih aktivnosti liči na model evolucijskog razvoja. Dakle UP ustvari kombinira ta dva modela nastojeći iskoristiti prednosti jednog i drugog. Slika 1.8 također pokazuje da u svakoj fazi postoji jedna ili dvije osnovne aktivnosti na koje je stavljen poseban naglasak i koje se obavljaju s povećanim intenzitetom. Kod manjih projekata faze možemo poistovjetiti s odgovarajućim dominantnim aktivnostima, pa dobivamo proces sličan vodopadu. U nastavku detaljnije opisujemo faze u UP, njihove ciljeve, naglaske i međaše.  Inception. Ciljevi su: dokazati izvedivost i isplativost projekta, utvrditi ključne zahtjeve da bi se vidio kontekst (doseg) sustava, prepoznati rizike. Naglasak je na temeljnim aktivnostima: zahtjevi i analiza. Naziv međaša je: Life Cycle Objectives.  Elaboration. Ciljevi su: stvoriti izvršivu jezgru arhitekture sustava. Profiniti procjenu rizika, definirati atribute kvalitete, evidentirati slučajeve uporabe (use case) koji pokrivaju 80% funkcionalnih zahtjeva, stvoriti detaljni plan za fazu konstrukcije. Naglasak je na temeljnim aktivnostima: zahtjevi, analiza te pogotovo oblikovanje. Naziv međaša je: Life Cycle Architecture.  Construction. Ciljevi su: dovršiti zahtjeve, analizu i oblikovanje te dograditi jezgru arhitekture do konačnog sustava. Pritom treba očuvati integritet arhitekture i oduprijeti se pritiscima da se sustav dovrši na brzinu. Obaviti beta test i pokrenuti sustav. Naglasak je na temeljnim aktivnostima: oblikovanje te pogotovo implementacija. Naziv međaša je: Initial Operational Capability.  Transition. Ciljevi su: popraviti uočene greške, prirediti sustav za rad u korisničkoj okolini, distribuirati ga na korisnička radna mjesta, stvoriti korisničku dokumentaciju, organizirati podršku korisnicima, napraviti “post-project review”. Naglasak je na temeljnim aktivnostima: implementacija te pogotovo testiranje. Naziv međaša je: Product Release. Dalje opisujemo temeljne aktivnosti u UP.  Zahtjevi (requirements). Utvrđuje se što sustav treba raditi.  Analiza (analysis). Zahtjevi se analiziraju, profinjuju i strukturiraju.  Oblikovanje (design). Predlaže se građa sustava koja će omogućiti da se zahtjevi realiziraju.  Implementacija (implementation). Stvara se softver koji realizira predloženu građu.  Testiranje (test). Provjerava se da li stvoreni softver zaista radi onako kako bi trebao. Makar je nastala relativno nedavno, UP je po svojim osobinama ipak klasična metoda. Naime, ona razvoj softvera promatra kao kompleksan projekt koji ima svoj početak i kraj i kojim treba upravljati. Također, ona predviđa da će se svi rezultati dokumentirati, na primjer pomoću odgovarajućih UML dijagrama. Više detalja o UP-u može se naći u knjizi [9].

20


Softversko inženjerstvo - skripta 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 sustav

Isporuč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. PMF – Matematički odsjek

21

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 22


Softversko inženjerstvo - skripta svoj menadžerski aspekt. Upravljanje softverskim projektom povjerava se softverskom menadžeru, dakle osobi koja raspolaže menadžerskim znanjima i sposobnostima. Upravljanje softverskim projektom bit će tema posebnog kolegija. Zato ovo potpoglavlje daje samo uvodni prikaz te složene problematike. U idućim odjeljcima najprije se nabrajaju razni poslovi koje obavlja softverski menadžer. Zatim se nešto podrobnije opisuju dva takva posla: planiranje i praćenje projekta te upravljanje rizicima. 1.4.1. Poslovi softverskog menadžera U svom radu softverski menadžer nastoji postići sljedeće ciljeve.  Isporučiti softver naručitelju do ugovorenog roka.  Držati ukupne troškove unutar planiranih granica.  Stvoriti softver koji zadovoljava naručiteljeva očekivanja.  Postići da razvojni tim dobro funkcionira i da njegovi članovi budu zadovoljni poslom koji obavljaju. Slični ciljevi žele se postići u bilo kojem inženjerskom projektu. Ipak, softversko inženjerstvo razlikuje se od drugih inženjerskih struka, a te razlike čine upravljanje softverskim projektom i postizavanje ovakvih ciljeva posebnim izazovom za menadžere. Evo nekih osobina po kojima se razvoj softvera razlikuje od na primjer gradnje mosta ili broda.  Produkt je „neopipljiv“. Teško je vidjeti rezultat. Teško je procijeniti koliki dio posla je obavljen i da li je kvalitetno obavljen. Menadžer se mora pouzdati u apstraktne dokumente ili na mišljenja suradnika.  Nema standardnog razvojnog procesa. Postoje razne metode i alati, oni dosta ovise o organizaciji koja ih primjenjuje. Ne zna se koji je najbolji način razvoja zadane vrste softvera u zadanim okolnostima.  Projekt je obično „neponovljiv“. Novi softver donosi nešto novo i još neviđeno. Iskustva na starim projektima nisu sasvim primjenjiva. Ulaskom u nova područja susrećemo se s nepredviđenim problemima. Tehnologija se brzo mijenja pa je način rada svaki put drukčiji. Zbog navedenih osobina nije nikakvo čudo da mnogi softverski projekti kasne, premašuju troškove ili daju rezultate ispod očekivanja. Očito je da upravljanje softverskim projektom zahtijeva izuzetno dobrog i snalažljivog menadžera. Bilo bi vrlo teško sastaviti sveobuhvatni opis radnog mjesta softverskog menadžera. Taj opis varira ovisno o organizaciji koja razvija softver te o vrsti softverskog produkta. Ipak, većina menadžera u većoj ili manjoj mjeri obavlja sljedeće poslove.  Pisanje prijedloga projekta, traženje podrške za njegovu realizaciju.  Procjenjivanje troškova projekta.  Planiranje i praćenje projekta.  Upravljanje rizicima.  Podnošenje izvještaja nadređenom menadžmentu ili naručiteljima.  Izbor suradnika, poticanje njihovog individualnog i timskog rada. Neki od ovih poslova, na primjer planiranje i praćenje, relativno su egzaktni i podržani su odgovarajućim metodama i alatima. Za neke od preostalih poslova, na primjer za procjenjivanje troškova, ne postoje pouzdane metode, tako da se kod njih menadžer mora osloniti na svoje iskustvo i intuiciju. PMF – Matematički odsjek

23

Robert Manger

1.4.2. Planiranje i praćenje projekta Planiranje i praćenje projekta predstavlja redoviti, svakodnevni i najegzaktniji posao softverskog menadžera. Posao uključuje sljedeće:  Definiranje projektnih aktivnosti, njihovog trajanja i međuzavisnosti.  Određivanje kalendara početka i završetka svake aktivnosti.  Raspoređivanje ljudi i drugih resursa na aktivnosti.  Praćenje izvršenja aktivnosti.  Povremenu reviziju svih parametara. Za planiranje i praćenje menadžer koristi egzaktne upravljačke modele i metode, poput mrežnih planova, analize kritičnih putova te Ganttovih dijagrama. Ti modeli i metode implementirani su u alatima za upravljanje projektima kao što je Microsoft Project [13]. U nastavku ovog odjeljka slijedi ilustracija postupka planiranja i praćenja uz primjenu spomenutih modela i metoda. Zamislimo projekt koji se može podijeliti u 12 aktivnosti. Procijenjena trajanja tih aktivnosti u danima te njihove međuovisnosti prikazane su na slici 1.10. Na primjer, vidimo da aktivnost T5 treba trajati 10 dana te da ona može početi tek nakon što su dovršene aktivnosti T2 i T4.

Slika 1.10: aktivnosti, trajanja, međuzavisnosti. Postupak počinje tako da informacije sa slike 1.10 prikažemo kao mrežu (aciklički usmjereni graf). U toj mreži čvorovi odgovaraju aktivnostima, a lukovi međuovisnostima (luk kaže da aktivnost iz njegovog polaznog čvora mora prethoditi aktivnosti iz dolaznog čvora). Svakom luku kao duljinu pridružimo trajanje aktivnosti iz njegovog polaznog čvora. Duljine putova u mreži tada odgovaraju minimalnim trajanjima niza aktivnosti koje se zbog međuovisnosti moraju odvijati sekvencijalno jedna nakon druge. 24



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. PMF – Matematički odsjek

25

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.

26


Softversko inženjerstvo - skripta 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 Ključni članovi razvojnog tima možda će se razboljeti u najnezgodnije vrijeme.

Primjer 2 Baza podataka koju ugrađujemo u naš produkt možda neće moći obraditi dovoljan broj transakcija u sekundi.

vezan uz projekt

vezan uz produkt

poslovni

velika

umjerena

mala

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

Opis rizika

Kategorija rizika Vjerojatnost pojavljivanja Učinak rizika

Primjer 3 Financijer projekta možda će imati financijskih problema pa će htjeti smanjiti sredstva za projekt.

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. PMF – Matematički odsjek

27

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



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 PMF – Matematički odsjek

29

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

1. Korisnik treba moći pretraživati liste čekanja za sve bolnice. 2. Sustav treba svaki dan za svaku bolnicu generirati listu pacijenata koji bi tog dana trebali doći na pregled. 3. Svaki zaposlenik koji koristi sustav treba biti jednoznačno određen svojim 8-znamenkastim identifikacijskim brojem.

Slika 2.1: primjeri funkcionalnih zahtjeva.

Zahtjev na produkt. Sustav treba biti dostupan svim bolnicama tijekom radnog vremena ponedjeljak-petak 8.30-17.30 h. Zastoji u radu sustava unutar radnog vremena ne smiju prijeći 5 sekundi dnevno. Organizacijski zahtjev. Korisnici sustava trebaju dokazati svoj identitet provlačenjem posebne magnetske kartice koju izdaje Minstarstvo zdravlja. Vanjski zahtjev. Sustav mora poštovati Zakon o zaštiti osobnih podataka te ne smije dopustiti da podaci o bolestima pojedinog pacijenta budu vidljivi na javnim web stranicama.

Slika 2.2: primjeri nefunkcionalnih zahtjeva.

Polazna verzija. Sustav treba medicinskom osoblju biti jednostavan za korištenje te treba biti organiziran tako da minimizira ljudske greške. Preformulirana verzija. Medicinsko osoblje treba biti u stanju koristiti sve funkcije sustava nakon četiri sata treninga. Broj grešaka koje rade iskusni korisnici ne smije biti veći od dvije na sat.

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


Softversko inženjerstvo - skripta 

Vanjski zahtjevi. Posljedica su faktora koji se nalaze izvan samog produkta i njegovog razvojnog procesa. Na primjer, kod bankarskog softvera to je zakonska regulativa koja određuje način poslovanja banke u nekoj zemlji. Ili to može biti zakon o zaštiti osobnih podataka odnosno autorskih prava. Za razliku od funkcionalnih zahtjeva, koji se u slučaju precizne formulacije lako mogu testirati, nefunkcionalni zahtjevi često znaju biti takvi da ih je teško provjeriti. Slika 2.3 prikazuje najprije tipičan način kako korisnik bolničkog sustava opisuje uporabljivost tog sustava. Zatim se vidi preformulacija istog zahtjeva u svrhu njegove provjerljivosti. 2.1.2. Postupak utvrđivanja zahtjeva Aktivnost utvrđivanja zahtjeva detaljnije se može podijeliti u sljedeće podaktivnosti.  Studija izvodljivosti. Procjenjuje se da li se uočene potrebe korisnika mogu zadovoljiti uz pomoć dostupnih hardverskih i softverskih tehnologija, da li bi predloženi sustav bio isplativ u poslovnom smislu te da li sustav može biti razvijen s raspoloživim budžetom.  Otkrivanje i analiza zahtjeva. Primjenom odgovarajućih metoda, zahtjevi se najprije otkrivaju a zatim analiziraju. Analizom otkrivenih zahtjeva stvaraju se modeli sustava. Ti modeli omogućuju diskusiju s korisnicima, bolje razumijevanje njihovih potreba te poboljšanu formulaciju zahtjeva.  Dokumentiranje zahtjeva. Informacije skupljene otkrivanjem i analizom pretvaraju se u dokumente koji definiraju zahtjeve. Postoje barem dvije razine u opisivanju zahtjeva: „korisnički zahtjevi“ i „zahtjevi na sustav“.  Validacija zahtjeva. Na razne načine provjerava se jesu li zahtjevi dobro opisani ili u njihovoj specifikaciji postoji neka greška. Odvijanje ovih pod-aktivnosti prikazano je na slici 2.4.

Studija izvodljivosti

Otkrivanje i analiza zahtjeva

Dokumentiranje zahtjeva

Validacija zahtjeva

Izvještaj o izvodljivosti

Modeli sustava

Korisnički zahtjevi i zahtjevi na sustav

Dokument o zahtjevima

Slika 2.4: podaktivnosti unutar utvrđivanja zahtjeva. Za otkrivanje zahtjeva koriste se razne metode, na primjer intervjui s korisnicima, zamišljeni scenariji korištenja, prototipovi, … i tako dalje. Te metode detaljnije ćemo opisati u idućem potpoglavlju 2.2. Analiza zahtjeva danas se uglavnom provodi modeliranjem predloženog sustava pomoću grafičkog jezika UML - pritom su za takvu analizu najvažniji takozvani use case i sequence dijagrami. Modeliranje sustava pomoću UML-a opširnije će biti obrađeno u potpoglavlju 2.3. PMF – Matematički odsjek

31

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


Softversko inženjerstvo - skripta  



 

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.


33

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.

34



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. 2. 3. 4. 5. 6. 7. 8.

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

Slika 2.7: primjeri korisničkih grupa.


35

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



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.


37

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

Registracija pacijenta

Unos osobnih podataka Menadžer

Generiranje statistike

Medicinski recepcionar Pregled zapisa

Medicinska sestra

Generiranje izvještaja

Uređivanje zapisa Liječnik Određivanje termina pregleda

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

38


Softversko inženjerstvo - skripta 2.2.3. Upotreba prototipova Korisnici budućeg sustava često ne uspijevaju jasno izraziti svoje zahtjeve, budući da ne mogu predvidjeti kako će taj sustav utjecati na njihove radne navike, u kakvoj će interakciji biti s drugim sustavima te u kojoj mjeri on može automatizirati radne procese. Tada se pribjegava izradi prototipa. Riječ je o jednostavnom i brzo razvijenom programu, koji oponaša budući sustav, lako se mijenja i nadograđuje te omogućuje isprobavanje raznih ideja, koncepcija i opcija. Prototip ustvari podržava čak dvije podaktivnosti unutar aktivnosti utvrđivanja zahtjeva:  Otkrivanje zahtjeva. Korisnici eksperimentiraju, pa tako otkrivaju svoje potrebe i dobivaju nove ideje o tome što bi sustav trebao raditi.  Validacija zahtjeva. Uočavaju se greške i propusti u polaznim zahtjevima, na primjer nepotpuni ili nekonzistentni zahtjevi. Osim toga, prototip može donijeti sljedeće dodatne koristi.  Otkrivaju se nesporazumi između razvijača softvera i korisnika.  Lakše se identificiraju komplicirane funkcije koje zahtijevaju pozornost.  Menadžmentu se demonstrira izvedivost i korisnost sustava. U praksi se pojam prototipiranja često miješa s pojmom istraživačkog programiranja, dakle razvoja softvera po modelu evolucijskog razvoja. Razlike između ta dva pojma su sljedeće.  Cilj istraživačkog programiranja je postepeno dotjerivanje „prototipa“ u skladu sa zahtjevima koji se otkrivaju, sve dok se taj „prototip“ ne pretvori u konačni sustav. Prioritet kod implementiranja zahtjeva imaju oni koji su najjasniji i korisnicima najpotrebniji.  Cilj „pravog“ prototipiranja je otkrivanje i validacija zahtjeva. Prioritet kod implementiranja imaju baš oni zahtjevi koji su nejasni i koje treba istražiti. Nakon utvrđivanja zahtjeva prototip se „baca“, a sustav se dalje oblikuje i implementira na konvencionalan način. U slučaju „pravog“ prototipiranja, cjelokupni softverski proces izgleda kao na slici 2.10. Pritom treba biti oprezan u izboru dijelova iz prototipa, budući da su oni često loše strukturirani, loše dokumentirani, imaju slabe performanse, slabu pouzdanost te ne zadovoljavaju zahtjeve sigurnosti.

Skiciraj polazne zahtjeve

Razvij prototip

Evaluiraj prototip

Validiraj sustav

Konačni softverski sustav

Specificiraj sustav

Upotrebljivi dijelovi Razvij softver

Slika 2.10: softverski proces s uključenim prototipiranjem.


39

Robert Manger Da bi prototipiranje imalo smisla, sam prototip se mora stvoriti na brz, jeftin i fleksibilan način. Za to su nam potrebne odgovarajuće razvojne tehnike, koje možemo ovako klasificirati.  Razvoj u dinamičnim jezicima visoke razine. Riječ je o programskim jezicima koji su velikim dijelom interpretirani te zahtijevaju glomaznu run-time okolinu. Programi se pišu brzo i jednostavno te se lako mijenjaju, makar su njihove performanse obično slabe zbog interpretiranja i run-time podrške. Primjeri takvih jezika su Smalltalk, Prolog i donekle Java.  Programiranje za baze podataka. Svi komercijalni sustavi za upravljanje bazama podataka opskrbljeni su vlastitim alatima za izradu aplikacija koje obavljaju uobičajene radnje s podacima: ažuriranje, pretraživanje, izrada izvještaja. Takvi alati nazivaju se jezici 4. generacije (4GL). Primjeri za 4GL mogu se naći unutar baza Oracle ili DB2. Izrada aplikacija (ustvari prototipova) pomoću 4GL je brza i jednostavna te ne zahtijeva puno programiranja. No dobivena aplikacija je prilično spora i rastrošna. Daljnja mana 4GL je da su oni nestandardni i neprenošljivi s jedne baze na drugu.  Povezivanje gotovih dijelova ili aplikacija. Prototip se slaže od već gotovih dijelova. U tu svrhu moramo imati na raspolaganju dovoljan broj upotrebljivih gotovih dijelova te okvir ili mehanizam za povezivanje tih dijelova. Primjeri za ovakvu tehniku su Microsoft Visual Basic, gdje se prototip se razvija „vizualnim“ programiranjem, a okvir za povezivanje je prozor u kojeg se interaktivno ubacuju gotove komponente grafičkog sučelja poput tekstualnih polja, izbornika ili gumba. Daljnji primjeri su skriptni jezici poput Shell, Perl ili TCL/TK. Okvir za povezivanje je sama skripta: njene naredbe mogu biti komande kojima se pozivaju gotove aplikacije ili uključuju komponente grafičkog sučelja. Pokazalo se da je prototipiranje vrlo pogodna metoda za specificiranje korisničkog sučelja. Naime, zahtjeve na sučelje teško je opisati riječima, pogotovo kad se radi o grafičkom sučelju. Do pogodnog sučelja dolazi se eksperimentiranjem. Dovoljan je prototip koji implementira samo sučelje bez odgovarajuće funkcionalnosti – takozvani „čarobnjak iz Oza“. Pogodni alati za prototipiranje korisničkog sučelja su: jezici 4. generacije, Visual Basic, TCL/TK, alati za web stranice, i drugi. 2.2.4. Etnografski pristup U svom standardnom značenju, etnografija je znanost koja proučava i opisuje materijalnu, društvenu i duhovnu kulturu pojedinih naroda. Da bi proučio neko pleme, etnograf se uključuje u život tog plemena te bilježi sve ono što vidi i čuje oko sebe: odjeću, običaje, vjerovanja, plesove, pjesme, ... . U kontekstu softverskog inženjerstva, etnografija je metoda za otkrivanje zahtjeva, gdje softverski inženjer preuzima ulogu etnografa, a korisnici ulogu plemena. Dakle, softverski inženjer boravi na radnim mjestima korisnika te iz dana u dan promatra i bilježi njihove radne postupke. Na taj način otkrivaju se:  implicitni zahtjevi vezani uz dotičnu aplikacijsku domenu koje korisnici inače ne spominju jer ih smatraju očiglednima;  stvarni načini kako ljudi rade koji se mogu razlikovati od službeno proklamiranih načina;  suptilni detalji vezani uz socijalni i organizacijski kontekst u kojem bi budući sustav trebao raditi. Sve su ovo informacije do kojih je teško doći na primjer intervjuiranjem. Unatoč dobrim stranama, etnografija ima i svojih slabosti. Na primjer. 40


Softversko inženjerstvo - skripta  

Previše je usmjerena na krajnje korisnike, pa ne može otkriti zahtjeve vezane uz organizaciju kao cjelinu. Previše je zaokupljena sadašnjim načinom rada, pa ne može formulirati zahtjeve kojima bi novi sustav promijenio i poboljšao radne procese.

Fokusirana etnografija Početna etnografska analiza

Utvrđivanje nejasnoća u zahtjevima

Evaluacija prototipa Prototipiranje sustava

Slika 2.11: otkrivanje zahtjeva kombiniranjem etnografije i prototipiranja.

Zbog svih ovih razloga, etnografija najbolje funkcionira u kombinaciji s drugim pristupima, dakle kao njihov komplement. Na primjer, etnografija se dobro može povezati s prototipiranjem, kao što je ilustrirano na slici 2.11. Naime, u skladu sa slikom:  početna etnografska analiza omogućuje da odmah stvorimo dobar prototip i preskočimo nekoliko iteracija njegovog profinjavanja;  taj prototip daje se korisnicima, čime se mijenja njihova radna okolina;  nova radna okolina postaje predmetom nove etnografske analize. Cijeli ciklus ponavlja se nekoliko puta.

2.3.

Modeliranje sustava

Modeliranje je proces razvoja apstraktnih modela sustava. Obično se svodi na primjenu neke vrste grafičke notacije, dakle na crtanje dijagrama. U prošlosti su se koristile razne notacije, no danas je kao standard prihvaćen Unified Modeling Language – UML [8,9]. Modeli se koriste u raznim fazama razvoja softvera. Najprije se pojavljuju unutar utvrđivanja zahtjeva kao sastavni dio analize zahtjeva. Isti modeli dalje se profinjavaju tijekom oblikovanja i time se pretvaraju u opis sustava kojeg treba implementirati. Nakon implementacije, modeli dalje služe kao dokumentacija građe i načina rada sustava. U idućim odjeljcima najprije ćemo nabrojati razne vrste modela te načine njihove upotrebe. Zatim ćemo detaljnije govoriti o vrstama modela koji promatraju sustav iz perspektive konteksta, interakcije, strukture, odnosno ponašanja. Svi primjeri dijagrama bit će nacrtani u skladu s pravilima UML. 2.3.1. Vrste modela i načini njihove uporabe Kao prvo, razlikujemo dvije vrste modela ovisno o tome da li oni modeliraju postojeći sustav ili sustav koji tek treba razviti. PMF – Matematički odsjek

41

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

42


Softversko inženjerstvo - skripta 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 <>. 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.

<> Informacijski sustav Zavoda za statistiku

<> Registar zdravstvenog osiguranja <> Bolnički informacijski sustav

<> Sustav elektroničkih uputnica

<> Sustav elektroničkih recepata

Slika 2.12: primjer kontekstnog modela. Kontekstni model sa slike 2.12 ne objašnjava točnu prirodu veza između našeg sustava i njegove okoline. Više informacija o tim vezama dobivamo iz modela interakcije. UML nudi dva načina modeliranja interakcija. 1. Use case dijagrami. Imenuju takozvane slučajeve uporabe (use cases) dakle interakcije između aktera izvan sustava i samog sustava. 2. Sequence dijagrami. Detaljnije razrađuju interakcije između aktera izvan sustava i pojedinih objekata unutar sustava, ili međusobne interakcije između tih objekata. Use case dijagrame već smo upoznali u odjeljku 2.2.2. Jedan primjer već smo vidjeli na slici 2.9. Drugi, nešto jednostavniji primjer nalazi se na slici 2.13 – tu vidimo da medicinski recepcionar može pokrenuti transfer podataka iz našeg sustava u vanjski sustav.

Transfer podataka Medicinski recepcionar

Registar zdravstvenog osiguranja

Slika 2.13: drugi primjer use case dijagrama. PMF – Matematički odsjek

43

Robert Manger

Kao što smo već objašnjavali, use case dijagram sastoji se od imenovanih aktera koji su nacrtani kao čovječuljci, imenovanih slučajeva uporabe koji su nacrtani kao ovali te spojnica koje pokazuju sudjelovanje pojedinog aktera u pojedinom slučaju uporabe. Akter je korisnik ili vanjski sustav koji stupa u interakciju s našim sustavom. Slučaj uporabe je usluga koju naš sustav daje akteru ili funkcija koju je akter pokrenuo. Kad god je to moguće, svi slučajevi uporabe crtaju se na istom use case dijagramu. Takav dijagram osim interakcija također opisuje i kontekst. Naime, svi slučajevi uporabe (ovali) nalaze se unutar sustava, a akteri (čovječuljci) čine njegovu okolinu. Koji put se to naglašava tako da se ovali ograde od čovječuljaka okvirom koji predstavlja granicu sustava. Primijetimo da use case dijagram samo imenuje interakcije, no ne opisuje kako se te interakcija zaista odvijaju. Da bismo pojedini slučaj uporabe detaljnije opisali, služimo se strukturiranim tekstom nalik na onaj sa slike 2.8 ili se služimo sequence dijagramom. Slika 2.14 sadrži sequence dijagram koji razrađuje slučaj uporabe Pregled zapisa sa slike 2.9.

P: PacijentInfo

D: BolnickaDB

A: Autorizacija

Medicinska sestra Gledaj (PID) Report (Info, PID, UID) Autoriziraj (Info, UID) Autorizacija Alt

Zapis o pacijentu

[Autorizacija OK] [Autorizacija nije prošla]

Greška (nema ovlaštenja)

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

44


Softversko inženjerstvo - skripta 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


45

Robert Manger pacijent je upućen od točno jednog liječnika opće prakse. Slično, jedan pregled mogu obavljati najviše 4 bolnička liječnika zajedno. Liječnik specijalist 1 Upućen_prema 1..*

Stanje

0..*

1..*

Dijagnosticirano

Pacijent

1..*

1 Upućen_od

Liječnik opće prakse

1 Podvrgava_se 1..*

Pregled

1..*

0..* Propisuje

Lijek

1..* Sudjeluje_u 1..4

Bolnički liječnik

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

46



Bolnički liječnik IdentifikacijskiBroj Prezime Ime DatumRođenja Odjel Plaća Status …. Zaposli () Otpusti ( ) Umirovi () PromijeniPlaću () …..

Slika 2.16: primjer detaljnije razrađene klase. Običaj je da se na class dijagramu nadklasa crta iznad podklase. Da bi se veza generalizacije lakše prepoznala, UML uvodi posebnu notaciju u obliku trokutaste strelice. Slika 2.17 sadrži hijerarhiju klasa o liječnicima. Vidimo da liječnici opće prakse i bolnički liječnici predstavljaju podklase općenitije klase liječnika. Također, vidimo da ima više podvrsta bolničkih liječnika. Slika 2.18 prikazuje nasljeđivanje za tri klase iz hijerarhije predmeta u knjižnici. Atributi i operacije koji su definirani za klasu Publikacija primjenjivi su i na objekte iz podklase Knjiga odnosno Časopis. No vidimo da svaka od podklasa ima i svoje specifične atribute.

Liječnik

Liječnik opće prakse

Bolnički liječnik

Liječnik specijalist

Timski liječnik

Liječnik pripravnik

Kvalificirani liječnik

Slika 2.17: primjer generalizaciju i hijerarhiju klasa. PMF – Matematički odsjek

47

Robert Manger Publikacija Kataloški broj Naslov Izdavač Status Nabavi () Katalogiziraj () Otpiši () Posudi () Vrati ()

Knjiga

Časopis

Autor Izdanje Godina izdanja ISBN

Volumen Broj ISSN

Slika 2.18: primjer za nasljeđivanje atributa i operacija. Još jedna važna vrsta veza između klasa je agregacija. Ta veza kaže da objekt jedne klase sadrži objekte druge klase kao svoje sastavne dijelove. Na primjer, objekt iz klase Avion sadrži sva objekta iz klase Krilo i četiri objekta iz klase Motor.

Nastavni materijali 1

1

Udžbenik

1

1

1..*

Slajdovi

1..*

Zadaci za vježbu

Slika 2.19: primjer agregacije. Da bi se na class dijagramu veza agregacije lakše prepoznala, UML uvodi posebnu oznaku u obliku romba koji se stavlja na spojnicu uz složeniju klasu. Slika 1.19 prikazuje agregaciju vezanu uz predmet na fakultetu. Nastavni materijali za učenje sastoje se od udžbenika sa cjelovitim prikazom gradiva, slajdova koje nastavnik koristi u nastavi te dodatnih zadataka za vježbu.

48


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

49

Robert Manger

Senzor za šećer

Pročitaj vrijednost sa senzora

Podaci sa senzora

Izračunaj razinu šećera

Razina šećera u krvi Izračunaj potrebnu količinu inzulina

Inzulinska pumpa

Naredbe za upravljanje pumpom

Upravljaj pumpom

Generiraj naredbe za upravljanje pumpom

Potrebna količina inzulina

Slika 2.20: primjer activity dijagrama.

: Narudžba

: Budžet

:BazaNarudžbi Dobavljač

Službenik Ispuni () Provjeri ()

[Provjera OK] Ažuriraj (Iznos)

Spremi ( ) Pošalji ( )

Slika 2.21: primjer sequence dijagrama koji prikazuje obradu podataka. Modeli vođeni događajima (event driven models) prikazuju kako sustav odgovara na vanjske ili unutarnje događaje. Zasnovani su na pretpostavci da se sustav može naći u konačno mnogo stanja te da događaji služe kao podražaji koji potiču prijelaz iz jednog stanja u drugo.

50



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

Puna snaga

Puna snaga

Do: postavi snagu na 600 W Timer Pola snage

Čekanje Do: prikazuj vrijeme

Puna snaga

Znamenka

Postavi vrijeme

Rad

Do: učitaj znamenku Exit: postavi vrijeme

Do: upravljaj radom pećnice Vrata zatvorena

Start

Cancel

Timer Pola snage

Osposobljena

Do: postavi snagu na 300 W

Do: prikaži poruku "Spremna za rad"

Vrata otvorena

Čekanje Do: prikaži vrijeme Vrata otvorena

Vrata zatvorena Onesposobljena Do: prikaži poruku "Vrata otvorena"

Slika 2.22: primjer state machine dijagrama.

Na slici 2.22 vidi se primjer state machine dijagrama koji opisuje rad jednostavne mikrovalne pećnice. Ta pećnica ima sklopku za podešavanje grijanja punom snagom ili s pola snage, numeričku tipkovnicu za unos vremena pečenja, gumb start/cancel, alfanumerički displej za ispis poruka te zvono. Normalni redoslijed akcija je da se izabere jačina grijanja, upiše pomoću tipkovnice vrijeme pečenja te pritisne gumb za start. No zbog sigurnosnih razloga pećnica neće raditi ako su njena vrata otvorena. Detaljniji opis svih stanja i podražaja nalazi se na slici 2.23.


51

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



Rad

Provjera

Status ok

Pečenje Do: puštaj grijalicu da radi

Do: provjeri stanje Greška na obrtnoj platformi

Prošlo je vrijeme

Greška na emiteru Alarm

Gotovo

Do: ispiši poruku o događaju

Do: zvoni zvono 5 sekundi

Vrata otvorena Onesposobljena

Cancel Čekanje

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


53

Robert Manger

54



3. Oblikovanje i implementacija U ovom poglavlju bavimo se osnovnim aktivnostima koje u softverskom procesu obično slijede nakon utvrđivanja zahtjeva: to su oblikovanje i implementacija. Najprije ćemo reći nešto općenito o tim aktivnostima i pripadnim podaktivnostima, pristupima i trendovima. Zatim ćemo detaljnije obraditi pojedine izuzetno važne aspekte oblikovanja, kao što su oblikovanje arhitekture i objektni pristup oblikovanju. Na kraju ćemo se posvetiti specifičnostima razvoja danas vrlo raširenih distribuiranih odnosno uklopljenih sustava.

3.1.

Općenito o oblikovanju i implementaciji

Nakon što je specifikacija ustanovila što softverski sustav treba raditi, oblikovanje treba utvrditi kako će sustav raditi. Rezultat oblikovanja je dizajn sustava: precizni opis građe sustava, dijelova od kojih se on sastoji, sučelja između dijelova, korisničkog sučelja te eventualno struktura podataka i algoritama koji se koriste. Oblikovanje je iterativni postupak, to jest do dizajna se dolazi postepenim profinjavanjem i razradom kroz više iteracija. Nakon oblikovanja slijedi implementacija, to jest svi dijelovi predviđeni dizajnom realiziraju se uz pomoć pogodnog programskog jezika. Zadnje iteracije oblikovanja obično se preklapaju s implementacijom. Također, implementacija se donekle preklapa s verifikacijom (testiranjem), budući da se programeri odmah bave debuggiranjem. 3.1.1. Podaktivnosti unutar oblikovanja Oblikovanje je kreativna aktivnost koju je teško precizno opisati. Ipak, možemo reći da se oblikovanje sastoji od podaktivnosti u skladu sa slikom 3.1. Svaka od njih daje svoje izlazne rezultate.


Oblikovanje arhitekture

Apstraktno specificiranje

Oblikovanje sučelja

Oblikovanje dijelova sustava

Oblikovanje struktura podataka

Oblikovanje algoritama

Arhitektura sustava

Specifikacija softverskog dizajna

Opis sučelja

Opis dijelova sustava

Opis struktura podataka

Opis algoritama

Slika 3.1: proces i rezultati oblikovanja.


55

Robert Manger

Slijedi kratko objašnjenje za svaku od navedenih podaktivnosti.  U oblikovanju arhitekture uočavaju se i dokumentiraju podsustavi koji čine sustav te veze među tim podsustavima. Ova podaktivnost je od ključne važnosti budući da bitno određuje daljnji tijek oblikovanja i način kako će se cijeli posao dalje strukturirati. Opširniji prikaz nalazi se u potpoglavlju 3.2.  Unutar apstraktnog specificiranja, za svaki podsustav piše se specifikacija softverskog dizajna, dakle apstraktni i vrlo precizni opis zahtjeva. Ova podaktivnost predstavlja mjesto gdje se aktivnost oblikovanja donekle preklapa s utvrđivanjem zahtjeva i već smo je spominjali u potpoglavlju 2.1. Nije obavezna već se uključuje po potrebi, na primjer onda kad se služimo formalnim metodama razvoja softvera.  U sklopu oblikovanja sučelja, za svaki podsustav oblikuje se i dokumentira sučelje prema drugim podsustavima i prema korisniku. Ova podaktivnost važna je kod većih projekata jer ona omogućuje da se daljnjim razvojem podsustava paralelno bave nezavisni timovi.  Oblikovanje dijelova obavlja se tako da se svaki podsustav dalje rastavlja na sastavne dijelove: opisuje se svaki dio zasebno, a veći dijelovi se dalje rastavljaju na manje. Pritom se primjenjuje neki od pristupa za dekompoziciju većih dijelova u manje, kao što će biti opisano u sljedećem odjeljku.  U oblikovanju struktura podataka ili algoritama detaljno se oblikuju i opisuju složenije strukture podataka odnosno algoritmi koji se pojavljuju u sustavu. Ova podaktivnost isto nije obavezna već se uključuje onda kad očekujemo da će strukture podataka ili algoritmi biti presloženi da bi ih prepustili programerima. 3.1.2. Dekompozicija većih dijelova u manje Da bi izašli na kraj sa složenošću sustava koji treba oblikovati, softverski inženjeri obilato se služe principom „podijeli pa vladaj“. Dakle, oblikovanje se u velikoj mjeri svodi na dekompoziciju većih dijelova u manje te posebno razmatranje svakog od tih manjih dijelova. Najprije kod oblikovanja arhitekture, cijeli sustav rastavljamo na podsustave. Kasnije kod oblikovanja dijelova, svaki podsustav dalje rastavljamo na dijelove, pa te dijelove na još manje dijelove, i tako dalje. Sama dekompozicija može se obavljati u skladu sa sljedećim pristupima oblikovanju:  Funkcionalni pristup. Sustav se oblikuje sa stanovišta funkcija (procesa). Znači, dijelovi su moduli i pojedine funkcije. Budući da se kreće od procesa na najvišoj razini, pa ih se postepeno razgrađuje u sve manje procese, dobiva se hijerarhijski sustav koji je lako implementirati u klasičnim programskim jezicima (glavna funkcija, podfunkcija, podpodfunkcija i tako dalje). Stanje sustava prikazano je globalnim podacima koji su dostupni raznim funkcijama. Ovakav pristup danas je već pomalo zastario, no koristio se u klasičnim funkcionalno-orijentiranim metodama za razvoj softvera.  Objektni pristup. Sustav se oblikuje kao skup objekata koji međusobno komuniciraju. Znači, dijelovi su objekti odnosno klase. Građa sustava obično nije hijerarhijska, a može se promatrati iz perspektive nasljeđivanja, agregacije, odnosno korištenja operacija među klasama. Sustav se izravno može implementirati u objektno-orijentiranim programskim jezicima. Nema globalnih podataka, a stanje sustava je zbroj stanja pojedinih objekata. Ovakav pristup koristi se danas u aktualnim klasičnim no objektno-orijentiranim metodama za razvoj softvera. Detaljniji opis zajedno sa studijskim primjerom nalazi se u potpoglavlju 3.2.

56


Softversko inženjerstvo - skripta 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 .

Čitaj izdane fakture

Sve fakture

Faktura

Ustanovi je li faktura plaćena

Faktura [plaćena]

Izdaj račun

Račun

Sve uplate

Faktura [neplaćena]

Izdaj opomenu

Opomena

Slika 3.2: primjer sustava oblikovanog funkcionalnim pristupom.

Račun

Kupac idKupca ime adresa poček

Uplata idUplate datum iznos idKupca

Faktura idFakture datum iznos idKupca

idRačuna datum iznos idKupca

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

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 PMF – Matematički odsjek

57

Robert Manger podacima, što stvara potrebu za globalnim podacima. Takav dizajn moguće je dobiti primjenom funkcionalnog pristupa. U skladu s upravo izloženim zaključujemo da sadašnja popularnost objektnog pristupa zaista ima svoje opravdanje. Naime kod većine sustava glavno mjerilo kvalitete je baš mogućnost održavanja, dok efikasnost obično nije od presudne važnosti. S druge strane, vidimo da stariji funkcionalni pristup isto ima svojih prednosti i može se pokazati opravdanim na primjer kod uklopljenih sustava i sustava u realnom vremenu. 3.1.3. Modeliranje tijekom oblikovanja U prethodnom potpoglavlju 2.3 upoznali smo se s modeliranjem. Vidjeli smo da se tijekom analize zahtjeva stvaraju modeli sustava koji opisuju njegov kontekst, interakcije, strukturu i ponašanje. No modeliranje ne služi samo za analizu zahtjeva. Isti modeli dalje se profinjavaju i nadopunjuju tijekom oblikovanja. Na taj način modeli predstavljaju sponu koja povezuje osnovne aktivnosti unutar softverskog procesa. Način modeliranja tijekom oblikovanja bitno ovisi o pristupu u samom oblikovanju.  Kod starijeg funkcionalnog pristupa, glavno polazište bio je model toka podataka stvoren tijekom analize zahtjeva. Procesi iz tog modela shvaćali su se kao podsustavi ili moduli koje treba realizirati pomoću funkcija. Daljnjim profinjavanjem tih funkcija dolazilo se do takozvanog strukturalnog modela sustava koji je pokazivao kako se pojedina funkcija realizira pozivanjem podređenih funkcija. Strukturalni model crtao se kao dijagram, gdje su pravokutnici prikazivali funkcije (nadređena iznad podređene), a spojnice su označavale pozive.  Kod današnjeg objektnog pristupa, polazište su modeli strukture i ponašanja stvoreni tijekom analize zahtjeva, na primjer UML class i sequence dijagrami, koji put i state machine dijagrami. Ti modeli dalje se profinjavaju razradom postojećih klasa ili dodavanjem novih klasa. Po potrebi dodaju se i neki novi modeli koje nismo susretali u analizi zahtjeva, na primjer UML component ili timing dijagrami. Budući da se i analiza zahtjeva i oblikovanje oslanjaju na modeliranje, teško je postaviti jasnu granicu među njima. To jest, teško je odrediti gdje prestaje analiza a gdje počinje oblikovanje. To pogotovo vrijedi u slučaju objektnog pristupa, gdje se i u analizi i u oblikovanju koriste iste vrste UML dijagrama. Ipak postoje neke bitne razlike između modela koji se pojavljuju u jednoj odnosno drugoj aktivnosti.  Model na razini analize prikazuje sam problem (poslovni sustav) u terminima dotične poslovne domene. Razumljiv je korisnicima.  S druge strane, model na razini oblikovanja prikazuje rješenje problema (softverski sustav) i služi se informatičkim pojmovima. Namijenjen je softverskim inženjerima.  Model na razini analize jednostavan je i neformalan. On daje idealiziranu predodžbu o građi i ponašanju sustava te njegovoj interakciji s okolinom.  S druge strane, model na razini oblikovanja znatno je kompliciraniji jer sadrži sve tehničke detalje koji su potrebni za implementaciju tražene funkcionalnosti i uspostavljanje sučelja prema okolini. Razlike između modela iz analize odnosno modela iz oblikovanja najbolje se vide kad se usporedi slika 2.16 iz prethodnog poglavlja sa slikom 3.4 iz ovog poglavlja. U oba slučaja riječ je o specifikaciji jedne klase. Slika 2.16 primjerena je analizi zahtjeva, naime prikazana klasa spada u poslovnu domenu i definirana je na neformalan način. S druge strane, slika 3.4 58


Softversko inženjerstvo - skripta spada u oblikovanje. Naime prikazana klasa služi za implementaciju komunikacije korisnika putem e-mail-a i ne susreće se u poslovnoj domeni. Njezina definicija dovoljno je detaljna jer sadrži tipove atributa, signature operacija i oznake „vidljivosti“.

Inbox -InboxId : int -VlasnikID : int -Poruka: String[*] +dajInboxId() : int +dajVlasnikId() : int +dajPoruku(indeks : int) : String +nađiPoruku(obrazac : String) : int [*] +brisiPoruku (indeks : int) : void +posaljiPoruku (posiljateljId : int, primateljId : int, poruka : String) : void

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

59

Robert Manger istražuje i ideja grafičkog razvoja: pokazuje se da je na primjer iz UML dijagrama kao što su class, sequence odnosno state machine dijagrami moguće generirati upotrebljivi programski kod, no taj kod je obično nedovršen i treba ga ručno doraditi. U ovom trenutku najveće uštede u kodiranju postižu se primjenom razvoja usmjerenog na ponovnu upotrebu. Postoji više konkretnih tehnika takvog razvoja i one će detaljnije biti opisane u potpoglavljima 6.1 - 6.3. Osim spomenutih trendova koji teret implementacije prebacuju na oblikovanje ili specifikaciju, u najnovije vrijeme pojavom agilnih metoda jačaju i sasvim suprotni trendovi. Agilne metode poput XP ponovo etabliraju programiranje kao glavnu aktivnost unutar koje se implicitno obavlja i oblikovanje. Za razliku od grafičkog pristupa gdje se programski kod nastoji automatski generirati iz dijagrama, u XP se dijagrami automatski izvode iz programskog koda. Ipak, treba primijetiti da takvi suprotni trendovi za sada nisu dominantni. Naime, agilne metode imaju svoj krug pobornika, uspješne su kod malih sustava, no nisu se još dokazale u razvoju velikih sustava.

3.2.


Oblikovanje arhitekture sustava predstavlja početnu fazu oblikovanja. Sustav se dekomponira na nekoliko podsustava, od kojih svaki obavlja određeni skup zadataka. Okvirno se utvrđuje način komuniciranja podsustava te način njihove kontrole. Oblikovanje arhitekture često se preklapa s apstraktnim specificiranjem odnosno s izradom detaljne specifikacije softverskog dizajna. Idealno, specifikacija ne bi smjela sadržavati informacije o dizajnu. No u praksi je to gotovo nemoguće postići, osim za vrlo male sustave. Oblikovanje arhitekture je među ostalim nužno i zato da bi se bolje strukturirala sama specifikacija. Oblikovanje arhitekture dobro se uklapa u klasične metode razvoja softvera. No zanimljivo je napomenuti da potrebu za tom aktivnošću prepoznaju također i agilne metode. Na samom početku agilnog procesa postavlja se arhitektura sustava, a daljnji razvoj u obliku brzih iteracija najčešće ne mijenja tu arhitekturu. Refactoring programskog koda koji smo spominjali u metodi XP zapravo se odnosi na manje dijelove (module) a ne na cijelu arhitekturu. U nastavku ćemo najprije reći nešto općenito o podsustavima i odnosima među njima. Zatim ćemo detaljnije objasniti dvije podaktivnosti unutar oblikovanja arhitekture, a to su strukturiranje sustava odnosno modeliranje kontrole. 3.2.1. Podsustavi i odnosi među njima Podsustav definiramo kao relativno samostalnu cjelinu, čije funkcioniranje uglavnom ne ovisi o uslugama koje pružaju drugi podsustavi. Podsustav je sastavljen od svojih dijelova (komponente, moduli, objekti, … ). On ima definirano sučelje za komunikaciju s drugim podsustavima te se podvrgava određenim režimima kontrole. Da bi oblikovali arhitekturu nekog sustava, nije dovoljno samo definirati njegove podsustave, već također treba odrediti odnose između tih podsustava. Primijetimo da postoje dvije bitno različite vrste odnosa podsustava: međusobna komunikacija, odnosno međusobna kontrola. Zato se u sklopu oblikovanja arhitekture pojavljuju sljedeće dvije podaktivnosti. 60


Softversko inženjerstvo - skripta 

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

Pod-sustav za identificiranje predmeta

Upravljanje robotskom rukom

Upravljanje robotskom hvataljkom

Pod-sustav za odabir načina pakiranja

Upravljanje pokretnom trakom

Pod-sustav za pakiranje

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

Sklop s iglom

Pumpa

Sat

Senzor

Kontroler

Alarm

Displej 1

Displej 2

Slika 3.6: model strukture sustava za ubrizgavanje inzulina pacijentu. PMF – Matematički odsjek

61

Robert Manger

Primjeri na prethodnim slikama pokazuju kako se za svaki sustav može razviti specifična arhitektura. No postoje i uobičajeni modeli strukture koji su se pokazali upotrebljivi za razne sustave. U nastavku ćemo opisati četiri takva modela. Model s repozitorijom. Svi zajednički podaci čuvaju se u središnjoj bazi podataka (repozitoriju), kojem mogu pristupiti svi podsustavi. Komunikacija između podsustava odvija se tako da jedan podsustav zapiše podatke u bazu, a drugi podsustav pročita te podatke. Sam repozitorij također treba shvatiti kao jedan (specijalizirani) pod-sustav. Struktura je vidljiva na slici 3.7.

Pod-sustav 1

Pod-sustav 2

Repozitorij (baza podataka)

Pod-sustav 3

Pod-sustav 4

Slika 3.7: model za strukturu sustava s repozitorijom. Ovo je uobičajena struktura za sustave koji rade s velikim količinama podataka (na primjer: informacijski sustav banke ili poduzeća, CAD/CAM sustav, CASE alat). Konkretni primjer je CASE alat Visual Paradigm kojeg koristimo na vježbama, ili informacijski sustav ISVU. Slika 3.8 prikazuje strukturu zamišljenog lower-CASE alata.

Editori za UML

Generatori koda Editor za Javu

Prevoditelj dizajna

Projektni repozitorij Editor za Python Analizator dizajna

Generator izvještaja

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

62



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

Klijent 1

Klijent 2

Klijent 3

Mreža

Poslužitelj 1

Poslužitelj 2

Slika 3.9: model za strukturu sustava klijent - poslužitelj. Ovo je uobičajena struktura za mrežno-orijentirane sustave. Dobar primjer je world-wideweb, 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.


63

Robert Manger

Klijent 1

Klijent 2

Klijent 3

Širokopojasna mreža

Poslužitelj kataloga

Video poslužitelj

Audio poslužitelj

Posluž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 podsustava koji se zovu slojevi. Svaki sloj definira „apstraktni stroj“ čiji strojni jezik (ustvari skup usluga) služi za implementaciju idućeg sloja. Struktura je ilustrirana slikom 3.11.

Sloj 3

Sloj 2

Sloj 1

Slika 3.11: slojeviti model za strukturu sustava. Ovakva struktura pojavljuje se kod sustava gdje želimo ostvariti što veću neovisnost rješenja o hardverskoj platformi. Primjeri su: aplikacija stvorene u jeziku Java, grafičko sučelje izgrađeno pomoću biblioteka Motif/X-Toolkit/Xlib, OSI model za mrežne protokole sa 7 slojeva, Internetski model za mrežne protokole sa 4 sloja. Slika 3.12 prikazuje zamišljeni bibliotečni sustav sastavljen od 5 slojeva; on dozvoljava objedinjeni pristup znanstvenoj literaturi koja je pohranjena u nekoliko digitaliziranih sveučilišnih knjižnica. 64



Sučelje preko web preglednika

Upravljanje formularima i upitima

Login

Distribuirano pretraživanje

Upravljanje ispisom

Naplata usluge

Dohvat dokumenta

Objedinjeni katalog

Baza 1

Baza 2

Baza 3

Baza 4

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

ulazni podaci

Filter 1

transf podaci

Filter 2

transf podaci

Filter 3

izlazni podaci

Slika 3.13: model cjevovoda i filtra za strukturu sustava. PMF – Matematički odsjek

65

Robert Manger

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

Leksička analiza

Sintaktička analiza

Semantička analiza

Generiranje koda

Strojni kod

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


Softversko inženjerstvo - skripta dogodi negdje duboko u hijerarhiji, potrebno je više puta prebacivati kontrolu na više članove hijerarhije. Glavni program

Potprogram 1

Potprogram 1.1

Potprogram 2

Potprogram 1.2

Potprogram 3

Potprogram 3.1

Potprogram 3.2

Slika 3.15: model poziva i povratka za kontrolu. Model menadžera. Jedan podsustav, takozvani menadžer, kontrolira ostale tako što im šalje signale za početak, kraj, odnosno sinkronizaciju njihovog rada. Svi podsustavi u principu rade paralelno, makar je to moguće simulirati i u sekvencijalnom sustavu. Menadžer izvršava beskonačnu petlju u kojoj ispituje varijable stanja da bi ustanovio koje podsustave treba pokrenuti ili zaustaviti. Model je predočen slikom 3.16. Pod-sustav 1

Pod-sustav 2

Menadžer

Pod-sustav 4

Pod-sustav 3

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

67

Robert Manger Pod-sustav 1

Pod-sustav 2

Pod-sustav 3

(događaj) Event and message handler

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

Handler 1

Handler 2

Handler 3

Handler 4

Slika 3.18: model za kontrolu upravljan prekidom. Ovaj model koristi se na primjer za komunikaciju računala s periferijskim uređajima. Pisanje po tipkovnici izaziva prekid, a odgovarajući interrupt handler učitava utipkane znakove. Model upravljan prekidom ima sljedeću prednost.  Dobiva se najbrži mogući odgovor na odabrane događaje. No model ima i sljedeće mane.  Nepogodan je za testiranje, može dovesti do suptilnih grešaka, na primjer u situaciji kad se više prekida desi u otprilike isto vrijeme.  Otežana je nadogradnja ukoliko je broj prekida koje hardver podržava već potrošen. Tada se više događaja mora pridružiti istom prekidu, a odgovarajući handler tada mora ispitivati o kojem je događaju zapravo bila riječ. 68



3.3.

Objektni pristup oblikovanju

Nakon oblikovanja arhitekture sustava, dalje je potrebno zasebno oblikovati svaki od podsustava. U tu svrhu danas se obično koristi objektni pristup. Riječ je o takvom načinu oblikovanja gdje projektant prvenstveno razmišlja o objektima i pripadnim klasama, a tek onda o operacijama ili funkcijama. Pristup je postao popularan u 80-im u 90-im godinama 20. stoljeća, a ispočetka je bio motiviran razvojem grafičkih sučelja. U ovom potpoglavlju najprije navodimo svojstva softvera koji nastaje objektnim oblikovanjem. Zatim nabrajamo korake unutar objektnog oblikovanja i ilustriramo te korake na studijskom primjeru. Na kraju spominjemo obrasce za oblikovanje koji omogućuju dokumentiranje i ponovnu upotrebu dobrih dizajnerskih rješenja dobivenih objektnim pristupom. 3.3.1. Svojstva objektno oblikovanog softvera Konačni rezultat objektnog oblikovanja je objektno-oblikovani softver. On se sastoji od objekata koji su u međusobnoj interakciji, kao što je ilustrirano slikom 3.19. Svaki objekt pripada nekoj klasi. Interakcija objekata odvija se na način da jedan objekt (klijent) pokrene operaciju drugog objekta (poslužitelja). U tom smislu, operacije se mogu tumačiti kao usluge, a svaki objekt može se pojaviti u ulozi klijenta i u ulozi poslužitelja. Prilikom poziva operacija, objekti razmjenjuju podatke (parametre i rezultate). U objektno-oblikovanom softveru ne postoje globalne funkcije koje bi se izvršavale neovisno o objektima, već je funkcionalnost izražena isključivo u terminima operacija vezanih uz objekte. Slično, ne postoje globalne varijable, već se stanje promatranog dijela sustava dobiva kao zbroj stanja pojedinih objekata. Objekti unutar objektno-oblikovanog softvera u principu se izvršavaju paralelno. To daje mogućnost da se softver distribuira na više računala, ili da se istovremeni rad objekata simulira na jednom računalu.

o1:C1

o3:C3

o4:C4

stanje o1

stanje o3

stanje o4

operacije1()

operacije3()

operacije4()

o2:C2

o6:C1

o5:C5

stanje o2

stanje o6

stanje o5

operacije2()

operacije1()

operacije5()

Slika 3.19: objekti u međusobnoj interakciji. PMF – Matematički odsjek

69

Robert Manger Novi objektno-oblikovani sustavi mogu biti razvijeni uz upotrebu objekata koji su bili stvoreni za prethodne sustave. To smanjuje cijenu razvoja softvera i vodi ka upotrebi standardnih objekata. Ipak, pokazuje se da su za ponovnu upotrebu pogodnije veće cjeline od pojedinih objekata, takozvane komponente – o njima će biti riječi u potpoglavlju 6.2. Važno svojstvo objektno-oblikovanog softvera je da on omogućuje laganu evoluciju. Naime, softver se sastoji od objekata, dakle dijelova s jakom unutarnjom kohezijom i labavim vezama prema van. Evolucija će zahtijevati promjenu unutarnje građe pojedinog objekta ili dodavanje novih objekata - takvi zahvati nemaju značajnog učinka na ostatak softvera. Ovo svojstvo bit će ilustrirano na kraju primjera u odjeljku 3.3.3. 3.3.2. Koraci unutar objektnog oblikovanja Objektno-orijentirane metode za razvoj softvera donekle se razlikuju u detaljima. Ipak, sve se one slažu da je unutar objektnog oblikovanja potrebno izvršiti barem sljedeće korake.  Utvrđivanje konteksta (okoline) za promatrani dio softvera te interakcije softvera s njegovom okolinom.  Oblikovanje na najvišoj razini, dakle podjela promatranog dijela softvera na još manje sastavne dijelove.  Identificiranje svih klasa koje su potrebne za realizaciju predviđenih dijelova.  Razvoj profinjenih modela strukture i ponašanja za pojedine dijelove ili klase.  Detaljno specificiranje sučelja svih dijelova ili klasa. Ti koraci su u priličnoj mjeri isprepleteni, teško ih je obavljati u nekom fiksiranom redoslijedu, pa se stoga moraju ponavljati u više iteracija. Kontekst promatranog dijela softvera opisuje se modelima koje smo opisali u odjeljku 2.3.2, na primjer pomoću UML class ili package ili component dijagrama. Važno je utvrditi granicu našeg dijela softvera, identificirati druge podsustave ili komponente ili vanjske sustave koje se nalaze u njegovoj okolini te uočiti veze između našeg dijela i dijelova iz okoline. Sve interakcije našeg dijela softvera s okolinom modeliraju se UML use case dijagramom, dok za detaljno specificiranje jedne interakcije može poslužiti UML sequence dijagram ili strukturirani tekst. Oblikovanje na najvišoj razini opet se može dokumentirati pomoću UML class ili package ili component dijagrama. No na tim dijagramima promatrani dio softvera rastavljen je na manje sastavne dijelove. Također se označavaju veze između manjih dijelova, koje mogu značiti razmjenu podataka ili tok kontrole. Kod identifikacije klasa koji put je potrebno klase iz aplikacijske domene koje smo dobili analizom zahtjeva rastaviti na više jednostavnijih klasa. Također je potrebno dodati nove klase koje su nužne za implementaciju, na primjer one koje omogućuju komunikaciju preko mreže, pristup bazi podataka, grafičko korisničko sučelje i tako dalje. Sve skupa može se prikazati pomoću UML class dijagrama. Profinjeni modeli strukture i ponašanja dokumentiraju se UML class ili sequence ili state machine dijagramima. Dovoljno su detaljni da omogućuju implementaciju. UML class dijagrami precizno razrađuju veze među klasama. Tu može biti riječ o nasljeđivanju, agregaciji ili o vezi koja kaže da objekti jedne klase pozivaju operacije nad objektima druge klase. 70



Sučelje klase sastoji se od sučelja operacija koje će u objektima te klase biti dostupne drugim objektima. Precizno se definiraju se broj i tipovi parametara za svaku operaciju te tip rezultata operacije. Sve se to opet može dokumentirati razrađenim UML class dijagramima ili u nekom programskom jeziku poput Jave ili C++ ili C#. Osim sučelja pojedine klase, mogu se definirati i općenitija sučelja, na primjer za cijele komponente. 3.3.3. Primjer objektnog oblikovanja U ovom primjeru bavimo se oblikovanjem softvera za meteorološku stanicu. Ta stanica nalazi se negdje u prirodi i služi za skupljanje meteoroloških podataka. Postoji veći broj meteoroloških stanica i one su dio većeg sustava koji također sadrži središnji meteorološki informacijski podsustav i središnji kontrolni podsustav. Zadaća meteorološkog informacijskog podsustava je da skuplja i obrađuje podatke iz svih meteoroloških stanica. Zadaća kontrolnog podsustava je da prati stanje svih meteoroloških stanica te da ih po potrebi resetira, pali, gasi i rekonfigurira. Komunikacija između meteorološke stanice i meteorološkog informacijskog podsustava odnosno kontrolnog podsustava odvija se radio vezom preko satelita. Unutar jedne meteorološke stanice nalazi se nekoliko instrumenata koji mjere razne meteorološke veličine poput brzine i smjera vjetra, temperature tla i zraka, tlaka zraka te količine padalina po četvornom metru u 24 sata. Svaki od tih instrumenata nalazi se pod kontrolom softvera koji periodički očitava i bilježi izmjerene vrijednosti. Budući da je propusnost veze sa satelitom relativno uska, softver u meteorološkoj stanici lokalno obavlja djelomičnu obradu i sažimanje izmjerenih podataka. Zatim se ti sažeti podaci na zahtjev šalju preko satelita u meteorološki informacijski podsustav. Meteorološka stanica sasvim je nezavisna i napaja se baterijom koja se puni solarnim ćelijama. Ipak, zbog raznih utjecaja prirodnih sila, njezin rad može se narušiti. Kontrolni podsustav preko satelita povremeno provjerava stanje stanice te u slučaju neispravnog rada nastoji resetirati njene instrumente ili uključiti rezervne instrumente. Također, kontrolni podsustav može rekonfigurirati softver u stanici, dakle instalirati novu verziju tog softvera. U nastavku pratimo korake u objektnom oblikovanju softvera za meteorološku stanicu. Prvi korak zahtijeva da se odredi kontekst (okolina) za taj softver te njegova interakcija s okolinom. Kontekst je vidljiv iz UML class dijagrama na slici 3.20. Vidimo da je naša meteorološka stanica zapravo podsustav cijelog sustava. U okolini meteorološke stanice nalaze se još dva podsustava: informacijski i kontrolni. Četvrti podsustav je satelit koji omogućuje međusobnu komunikaciju ostalih podsustava. Iz kardinalnosti veza vidimo da postoji samo jedan informacijski podsustav, jedan kontrolni podsustav i jedan satelit, no meteoroloških stanica ima mnogo. Interakcija meteorološke stanice s okolinom vidljiva je na UML use case dijagramu na slici 3.21. Vidimo da se kao akteri pojavljuju dva vanjska podsustava: informacijski i kontrolni. Informacijski podsustav može na primjer od stanice zahtijevati da mu pošalje izvještaj sa sažetim vremenskim podacima. Kontrolni podsustav može na primjer resetirati određeni instrument unutar stanice. Slika 3.22 sadrži detaljnu specifikaciju jedne interakcije u obliku strukturiranog teksta. Drugi korak oblikovanja traži da se softver za meteorološku stanicu oblikuje na najvišoj razini, to jest da se odrede njegove komponente. Rješenje je prikazano UML package PMF – Matematički odsjek

71

Robert Manger dijagramom na slici 3.23. Vidimo da se meteorološka stanica sastoji od nekoliko sastavnih dijelova koji međusobno komuniciraju preko unutrašnje komunikacijske veze, na primjer sabirnice.

1

Kontrolni pod-sustav

1

Informacijski pod-sustav

1 1..n

1 1

1..n

1

Meteorološka stanica

1 1

Satelit

1..n 1

Slika 3.20: kontekst za meteorološku stanicu.

Izvještaj o vremenu

Informacijski pod-sustav

Izvještaj o stanju

Ponovno pokretanje

Gašenje

Kontrolni pod-sustav

Rekonfiguriranje

Upravljanje na daljinu

Slika 3.21: interakcije meteorološke stanice s okolinom.

72


Softversko inženjerstvo - skripta Podsustav Slučaj uporabe Akteri Opis

Podražaj Odgovor Komentari

Meteorološka stanica Izvještaj o vremenu Informacijski podsustav Meteorološka stanica šalje informacijskom podsustavu sažete podatke o vremenu koje je skupila pomoću svojih instrumenata u razdoblju od prethodnog slanja. Podaci koji se šalju su: maksimumi, minimumi i prosjeci za temperaturu tla temperaturu zraka, tlak zraka i brzinu vjetra, zatim iznos padalina po metru kvadratnom te smjerovi vjetra skupljeni u 5-minutnim intervalima. Informacijski podsustav uspostavlja komunikacijsku vezu s meteorološkom stanicom preko satelita i zahtijeva od stanice prijenos podataka. Meteorološka stanica šalje sažete podatke informacijskom podsustavu. 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

Upravljanje konfiguracijom

Upravljanje energijom

Unutrašnja komunikacija

Komunikacija preko satelita

Skupljanje podataka

Instrumenti

Slika 3.23: građa meteorološke stanice na najvišoj razini. U trećem koraku oblikovanja potrebno je definirati klase. Meteorološka stanica zahtijeva velik broj klasa. Slika 3.24 prikazuje samo neke od njih. Vidimo da neke klase odgovaraju mjernim instrumentima. Objekt iz klase MeteoroloskiPodaci služi za skupljanje izmjerenih podataka prije njihovog slanja u informacijski podsustav. Objekt iz klase MeteoroloskaStanica predstavlja cijelu meteorološku stanicu i implementira sučelje stanice prema okolini. Četvrti korak oblikovanja sastoji se od razrade profinjenih modela strukture i ponašanja. Takvih modela može biti mnogo, no mi ovdje prilažemo samo dva. Slika 2.25 sadrži UML sequence dijagram koji opisuje realizaciju slučaja uporabe Izvještaj o vremenu, dakle pokazuje kako meteorološka stanica šalje podatke informacijskom podsustavu. Na dijagramu se pojavljuju objekti iz klasa s prethodne slike, no također i dva nova objekta: prvi od njih enkapsulira komunikaciju stanice s vanjskim svijetom preko satelita, a drugi enkapsulira internu komunikaciju unutar stanice. Slika 3.26 prikazuje UML state machine dijagram za meteorološku stanicu. Vidimo stanja u kojima se stanica može naći te prijelaze iz stanja u stanje ovisno o podražajima izvana ili o unutrašnjim događajima. PMF – Matematički odsjek

73

Robert Manger

MeteoroloskaStanica

MeteoroloskiPodaci

Identifikator

temperatureZraka temperatureTla brzineVjetra smjeroviVjetra tlakovi padaline

izvjestajVrijeme () izvjestajStanje () daljinskoUpravljanje (naredbe) rekonfiguracija (naredbe) restart (instrumenti) shutdown (instrumenti)

skupi () obradi ()

TermometarTlo

Anemometar

Barometar

tt_identifikator temperatura

an_identifikator brzinaVjetra smjerVjetra

b_identifikator tlak visina

ocitaj () testiraj ()



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

:SatKomunikacija

: MeteoroloskaStanica

:UnutraKomunikacija

:MeteoroloskiPodaci

Informacijski pod-sustav zahtjev (izvjestaj) potvrda izvjestajVrijeme ( ) potvrda zahtjev (obrada ) obradi ( )

salji (izvjestaj) potvrda odgovor (izvjestaj) potvrda

Slika 3.25: slanje podataka iz meteorološke stanice u informacijski podsustav.

74


Softversko inženjerstvo - skripta Pod daljinskim upravljanjem

shutdown( )

daljinskoUpravljanje( ) izvjestajStanje( )

Ugašena

Radi

restart( )

Testira se slanje gotovo

rekonfiguracija( )

rekonfiguracija gotova

sat

skupljanje gotovo

testiranje gotovo izvjestajVrijeme()

Skuplja podatke

Konfigurira se

Šalje podatke

Obrađuje podatke

izvještaj gotov

Slika 3.26: stanja za meteorološku stanicu, prijelazi iz stanja u stanje. Kao ilustraciju zadnjeg koraka u oblikovanju, prilažemo sliku 3.27 na kojoj su definirana dva sučelja za meteorološku stanicu. Prvo sučelje tiče se izvještavanja, dakle slanja izmjerenih podataka i statusa u informacijski podsustav. Drugo sučelje služi za udaljeno upravljanje stanicom preko satelita. Primijetimo da između sučelja i klasa ne mora postojati odnos jedannaprama-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.

<> Izvjestavanje

<> DaljinskoUpravljanje

VremenskiIzvjestaj(MS-Ident): Vizvjestaj StatusniIzvjestaj(MS-Ident): Sizvjestaj

startInstrument (instrument): iStatus stopInstrument (instrument): iStatus skupiPodatke(instrument): iStatus unesiPodatke(instrument): string

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


75

Robert Manger

MeteoroloskaStanica

PodaciOZagadjenju

Identifikator

podaciNO podaciSmog podaciBenzen

izvjestajVrijeme () izvjestajZagadjenje () izvjestajStanje () daljinskoUpravljanje (naredbe) rekonfiguracija (naredbe) restart (instrumenti) shutdown (instrumenti)

skupi () obradi ()

MjeracNO

MjeracSmoga

MjeracBenzena

no_identifikator vrijednostNO

s_identifikator vrijednostSmog

bz_identifikator vrijednostBenzen




Slika 3.28: nove klase za praćenje zagađenja zraka. Da bi ilustrirali kako objektno-oblikovani softver lagano može evoluirati, pretpostavimo da se naknadno pojavio zahtjev da meteorološka stanica mora također mjeriti i zagađenost zraka. To zahtijeva sljedeće izmjene u dizajnu.  Dodaje se klasa PodaciOZagadjenju, na istoj razini kao MeteoroloskiPodaci, koja enkapsulira sažete podatke o zagađenosti.  U klasu MeteoroloskaStanica dodaje se operacija IzvjestajZagadjenje(), kojom se podaci o zagađenosti šalju u informacijski podsustav.  Dodaju se klase MjeracNO, MjeracSmoga i MjeracBenzena koje odgovaraju fizičkim instrumentima za mjerenje razine dušičnog oksida, smoga i benzena. Sve ove promjene prikazane su na slici 3.28. Dakle vidi se izmijenjena verzija klase MeteoroloskaStanica i četiri nove klase. Ove promjene nemaju nikakav učinak na funkcioniranje ostalih dijelova stanice. 3.3.4. Obrasci za oblikovanje U oblikovanju softvera često se dešava da se u različitim kontekstima pojavljuju otprilike isti dizajnerski problemi. Takve probleme ne bi trebalo iznova rješavati, već bi za njih trebalo primijeniti već poznata provjerena rješenja. Da bi se provjerena rješenja mogla ponovo upotrebljavati, ona moraju biti dokumentirana. Unutar objektnog pristupa oblikovanju razvio se posebni vid takvog dokumentiranja koji se zove obrasci za oblikovanje (design patterns).

76


Softversko inženjerstvo - skripta Jedan obrazac za oblikovanje sastoji se od opisa dizajnerskog problema koji se često pojavljuje te od opisa rješenja koje je dovoljno općenito da se može koristiti u raznim okolnostima. Obrazac nije detaljna specifikacija rješenja, prije bi ga se moglo opisati kao akumuliranu mudrost i iskustvo o tome kako da se neki česti problem riješi na provjereni način. Temelji obrazaca za oblikovanje bili su postavljeni u knjizi [30] autora Gamme i suradnika. Ta knjiga definira 30-ak najpoznatijih obrazaca. Drugi autori dalje su definirali dodatne obrasce, tako da ih se do danas skupilo više stotina. Obrasci su izvršili jak utjecaj na objektno oblikovanje softvera. Osim što daju provjerena rješenja za česte probleme, oni postaju i neka vrsta rječnika za razgovor o dizajnu. Jedan inženjer može drugom inženjeru objasniti svoj dizajn tako da navede obrasce koje je koristio. Prema Gammi i suradnicima i njihovoj knjizi [30], u dokumentaciji obrasca za oblikovanje moraju biti prisutna sljedeća četiri elementa.  Smisleno ime za obrazac.  Opis problema, iz kojeg je vidljivo kad se obrazac može primijeniti.  Opis rješenja, koji objašnjava dijelove predloženog dizajna te odnose između tih dijelova. Opis rješenja obično se naslanja na dijagram s klasama, nasljeđivanjem, agregacijama ili nekim drugim vrstama veza.  Opis posljedica, koji nabraja prednosti i mane primjene predloženog obrasca. Kao primjer korištenja obrazaca, promatrajmo situaciju sa slike 3.29. Riječ je o programu gdje se stanje jednog te istog objekta prikazuje na više načina. Dakle vrijednosti atributa A, B, C, D nacrtane su u obliku kružnog grafikona te također u obliku stupčastog grafikona. Pojavljuje se sljedeći problem: kako osigurati da bilo koja promjena stanja objekta odmah uzrokuje simultanu promjenu svih prikaza?

A 40%

B

25%

40

20% 15%

25 15

D

20

A B C D

C Subjekt

Promatrač 1

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

Promatrač 2

Slika 3.29: više grafičkih prikaza istih podataka.


77

Robert Manger

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

Slika 3.30: dokumentacija za obrazac Promatrač (Observer).

Subject

Attach (Observer) Detach (Observer) Notify ( )

Observer

Update ( ) for All o in observers o -> Update( )

ConcreteSubject

ConcreteObserver

subjectState

observerState

GetState ( )

return subjectState

Update ( )

observerState = subject -> GetState( )

Slika 3.31: UML class dijagram koji pobliže objašnjava obrazac Promatrač. 78



Rješenje ovog problema daje obrazac Promatrač (Observer) iz knjige [30], Dokumentacija tog obrasca nalazi se na slici 3.30, a njen sastavni dio je i UML class dijagram na slici 3.31. Vidimo da se predloženi dizajn sastoji od dvije apstraktne klase te od većeg broja konkretnih klasa koje ih nasljeđuju. Konkretne klase implementiraju apstraktne operacije za ažuriranje prikaza, uvodeći pritom polimorfizam.

3.4.

Oblikovanje distribuiranih sustava

Distribuirani sustav je sustav čiji dijelovi su raspoređeni na više umreženih računala. Svi današnji veliki sustavi su distribuirani pa je to razlog zašto njima treba posvetiti posebno potpoglavlje. Nekadašnja mainframe računala s izravno spojenim terminalima zamijenili su skupovi umreženih poslužiteljskih i osobnih računala. Umjesto privatnih mreža s posebnom namjenom, za komunikaciju se koriste javne mreže Internet tipa. Razvoj brzih bežičnih mreža omogućio je i uključivanje ručnih uređaja poput mobitela ili tableta. Na taj način nastali su i sve više prevladavaju „sveprisutni“ distribuirani sustavi. U prvom odjeljku ovog potpoglavlja najprije nabrajamo prednosti i mane distribuiranih sustava. U daljnjim odjeljcima bavimo se ključnim aspektom u oblikovanju distribuiranih sustava, a to je odabir modela za arhitekturu. Najprije ćemo obraditi generički model klijenata i poslužitelja - njega smo već spominjali u potpoglavlju 3.2, no sad ćemo ga razraditi na nekoliko podmodela. Zatim ćemo objasniti još tri modela koji se donekle razlikuju od klijenata i poslužitelja – to su model gospodar-rob, arhitektura s distribuiranim objektima te model ravnopravnih partnera. 3.4.1. Prednosti i mane distribuiranih sustava Poželjna svojstva, a ujedno i prednosti distribuiranih sustava su sljedeće.  Dijeljenje resursa. Moguće je s jednog računala koristiti hardverske ili softverske resurse koji pripadaju drugom računalu, na primjer disk, štampač, datoteku, softverski alat.  Otvorenost. Moguće je međusobno povezati hardver i softver različitih proizvođača. To zahtijeva poštivanje određenih standarda za komunikaciju.  Paralelnost. Više procesa može se istovremeno odvijati na različitim računalima te po potrebi međusobno komunicirati preko mreže. Time je moguće obaviti više poslova u isto vrijeme, ili jedan posao obaviti u kraćem vremenu.  Skalabilnost. Performanse sustava mogu se u principu povećati dodavanjem novih računala i preraspodjelom poslova.  Robusnost (fault tolerance). U slučaju kvara jednog računala u principu je moguće poslove preraspodijeliti na preostala računala, tako da sustav i dalje radi uz nešto oslabljene performanse.  Transparentnost. Korisniku se sustav može predočiti kao integrirana cjelina, dakle korisnik ne mora znati ni brinuti o tome gdje se fizički nalaze resursi koje on koristi. Mane distribuiranih sustava su sljedeće.  Složenost u odnosu na centralizirane sustave. Teško ih je testirati. Paralelni rad može dovesti do suptilnih grešaka. Koriste se složeni softveri za mrežnu komunikaciju.  Smanjena sigurnost. Podaci putuju mrežom pa ih je moguće „prisluškivati“ ili čak mijenjati. Napadač se može lažno predstaviti kao dio sustava. PMF – Matematički odsjek

79


Otežano upravljanje. Veći broj raznorodnih računala teže je održavati nego jedno računalo. Nepredvidivost kakvoće usluge. Brzina odziva ovisi o ukupnom opterećenju (obično javne) mreže na koje nemamo utjecaja.

3.4.2. Arhitekture s klijentima i poslužiteljima Model za strukturu sustava zasnovan na klijentima i poslužiteljima već smo ih spomenuli u potpoglavlju 3.2. U skladu s tim modelom, sustav se sastoji od klijenata i poslužitelja povezanih mrežom. Poslužitelji daju usluge, klijenti traže usluge. Dozvoljavamo da poslužitelj zatraži uslugu od drugog poslužitelja, no ne i od klijenta. Klijenti moraju biti svjesni postojanja poslužitelja, no ne moraju znati za druge klijente. I klijenti i poslužitelji shvaćeni su kao procesi (softverske komponente) koji se na različite načine mogu pridružiti procesorima (hardverskim komponentama). Slika 3.32 prikazuje sustav koji se sastoji od 12 klijenata i 4 poslužitelja. Na slici 3.33 vidi se razmještaj tih procesa na 8 računala, tako da jedno računalo izvodi više klijentskih odnosno poslužiteljskih procesa.

c2

c3

c4

c12 c11

c1

s1

s4 c10

c5 c9

s3

s2

Poslužiteljski proces

c6 c8

c7

Klijentski proces

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

c1

s1, s2

c2

c3, c4

cc1

sc2

cc2

cc3 Poslužiteljsko računalo

mreža

cc4

sc1

cc5

c5, c6, c7

s3, s4

c8, c9

cc6 c10, c11, c12

Klijentsko računalo

Slika 3.33: razmještaj klijenata i poslužitelja na računala. 80



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

Prezentacijski sloj (presentation layer) Sloj obrade (processing layer) Sloj upravljanja podacima (data management layer) Slika 3.34: podjela aplikacije na tri sloja. Jednostavni razmještaj slojeva na računala zove se dvoredni (two-tier), gdje je aplikacija raspoređena na jedno poslužiteljsko računalo i mnogo klijentskih računala. Pritom u skladu sa slikom 3.35 postoje dvije mogućnosti, budući da tri sloja treba smjestiti na dva računala.

Prezentacija

klijent

Poslužitelj

Prezentacija + obrada

Poslužitelj

Obrada, upravljanje podacima

klijent

Upravljanje podacima

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


81

Robert Manger

ATM

Poslužitelj računa

ATM

TeleBaza procesing korisničkih monitor računa

ATM

ATM

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

Poslužitelj

Poslužitelj

Obrada

Upravljanje podacima

klijent

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

Poslužitelj baze pod

Web poslužitelj

Klijent

Generiranje web stranica, aplikacijski servisi

SQL upit SQL

Baza korisničkih računa

Klijent

Klijent

Slika 3.38: sustav internetskog bankarstva s trorednim rasporedom.

82


Softversko inženjerstvo - skripta Slika 3.38 prikazuje sustav za internetsko bankarstvo. Korisnici ustvari gledaju web formulare pomoću običnog web preglednika. Te web formulare dinamički oblikuje web poslužitelj, služeći se podacima o bankovnim računima kojima upravlja poslužitelj baze podataka. Ako promet postane prevelik, dodaje se više web poslužitelja. 3.4.3. Druge distribuirane arhitekture Makar se većina distribuiranih sustava sastoji od klijenata i poslužitelja, postoje i sustavi koji slijede drukčije modele. U ovom odjeljku opisat ćemo tri takva alternativna modela. Oni naravno nisu međusobno isključivi, tako da su moguće i njihove razne kombinacije. Model gospodar – rob (master – slave). Riječ je o jednostavnom modelu gdje se sustav sastoji od jednog glavnog procesa koji zovemo gospodar i niza pomoćnih procesa koje zovemo robovi. Gospodar upravlja radom sustava tako da robovima dodjeljuje poslove. Robovi paralelno obavljaju poslove koje im je dodijelio gospodar. Model se često koristi u znanstvenom računanju, sa ciljem da se skrati vrijeme izvršavanja zahtjevnih proračuna. Da bi obavio zadani računski zadatak, gospodar ga najprije dijeli na više manjih nezavisnih podzadataka koje dodjeljuje robovima. Robovi paralelno rješavaju svoje podzadatke i svoja rješenja šalju gospodaru. Dobivena rješenja podzadataka gospodar objedinjuje u konačno rešenje cijelog zadatka. Ideja je ilustrirana slikom 3.39.

Rob

Gospodar Rob

Pod-zadatak

Rezultati rješavanja pod-zadatka

Rob

Slika 3.39: model gospodar – rob za distribuirano računanje. Na primjer, zamislimo da se računski zadatak sastoji od pronalaženje najmanjeg člana u nesortiranom nizu od 10 milijuna brojeva. Tada gospodar dijeli niz u 10 manjih nizova od po 1 milijun brojeva. Svaki od 10 robova paralelno pretražuje jedan od podnizova i dojavljuje gospodaru svoj minimum. Gospodar na kraju uspoređuje 10 dojavljenih vrijednosti i pronalazi konačni minimum. Postupak očito traje otprilike 10 puta kraće nego kad bi jedan proces pregledavao cijeli niz. Osim u znanstvenom računanju, model gospodar – rob također se koristi u sustavima u realnom vremenu (real-time sustavi) – vidi potpoglavlje 3.5, gdje postoje senzori i aktuatori. Sustav u realnom vremenu upravlja nekim tehnološkim procesom. Senzor su uređaji koji skupljaju podatke iz okoline procesa, a aktuatori su uređaji koji djeluju da bi mijenjali tu okolinu. Gospodar pojedinom robu dodjeljuje posao praćenja jednog ili više senzora ili posao kontroliranja jednog ili više aktuatora. PMF – Matematički odsjek

83

Robert Manger Procesor u kontrolnoj sobi

Proces za koordinaciju i prikaz situacije

Procesor za senzore

Gospodar

Proces koji kontrolira senzore

Proces za upravljanje semaforima Operatorove konzole

Rob

Rob

Slika 3.40: sustav za upravljanje prometom sagrađen po modelu gospodar – rob.

Kao primjer, pogledajmo sliku 3.40 koja prikazuje arhitekturu sustava u realnom vremenu za upravljanje prometom oblikovanu po modelu gospodar – rob. Gospodar od roba zaduženog za senzore prima podatke o intenzitetu prometa na pojedinim raskrižjima. Na osnovu tih podataka, gospodar bira način regulacije prometa. Rob zadužen za aktuatore zapravo pali i gasi semafore u skladu s načinom regulacije koji je dojavio gospodar. Arhitektura s distribuiranim objektima. Kod ovog modela za strukturu sustav se promatra kao skup objekata koji su raspoređeni na raznim računalima i koji međusobno komuniciraju preko mreže. Dakle građa izgleda otprilike kao na slici 3.19. Dijelovi sustava su objekti od kojih svaki daje sučelje na skup usluga koje on pruža. Isti objekt može tražiti jednu vrstu usluge a pružati drugu vrstu usluge. Fizički raspored objekata po računalima je irelevantan za funkcioniranje sustava.

Objekt 1

Objekt 2

Objekt 3

Usluge 1

Usluge 2

Usluge 3

middleware (softverska sabirnica)

Objekt 4

Objekt 5

Usluge 4

Usluge 5

Slika 3.41: distribuirani objekti i njihova komunikacija preko middleware-a. 84



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

85

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

Baza podataka 1 Integrator 1

Generator izvještaja

Vizualizator

Baza podataka 2

Integrator 2

Složeno sučelje

Baza podataka 3

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.

86


Softversko inženjerstvo - skripta Arhitektura ravnopravnih partnera ilustrirana je slikom 3.43. Čvorovi na slici predstavljaju partnere, a spojnice pokazuju tko je kome susjed. Na primjer, možemo zamišljati da je riječ o sustavu za pohranjivanje znanstvenih radova. Svaki znanstvenik pohranjuje radove na vlastitom računalu, no svoju zbirku stavlja na raspolaganje i drugima. Kad neki znanstvenik želi vidjeti neki rad, njegov partner najprije gleda da li ga ima na lokalnom disku, ako ga nema tada pita susjede, ako ga ni susjedi nemaju, oni pitaju svoje susjede, i tako dalje. Kad se konačno pronađe partner koji ima traženi rad, on stupa u neposrednu komunikaciju s polaznim partnerom te mu omogućuje uvid. Za vrijeme te komunikacije polazni partner igra ulogu klijenta, a pronađeni partner igra ulogu poslužitelja.

p5

p6

p4

p3

p1

p2

p7 p8

p9

p11 p10 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.


87

Robert Manger

Poslužitelj za pronalaženje (super-partner)

p5

p6

p3 p4 p2 p1

Slika 3.44: polucentralizirana arhitektura ravnopravnih partnera. U skladu sa slikom 3.44, polucentralizirana arhitektura osim običnih partnera uvodi i superpartnere 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. Superpartner dojavljuje koji su drugi partneri na raspolaganju. Čim su obični partneri otkrili jedan drugoga, oni uspostavljaju neposrednu komunikaciju, što je na slici označeno punim linijama. Ovakvo rješenje koristi se na primjer u internetskoj telefoniji, gdje takozvani media gateway controller služi kao neka vrsta telefonske centrale pretvarajući telefonske brojeve u IP adrese.

3.5.

Oblikovanje i implementacija uklopljenih sustava

Uklopljeni sustavi predstavljaju specifičnu no vrlo raširenu vrstu softvera. Makar ih često ne primjećujemo, oni se nalaze doslovce svuda oko nas: u perilicama rublja, telefonima, glazbenim linijama, mikrovalnim pećnicama, bojlerima, automobilima, avionima, ... . U prvom odjeljku ovog potpoglavlja navodimo osobine uklopljenih sustava, a u drugom odjeljku bavimo se modelima za njihovu arhitekturu. Treći odjeljak posvećen je važnom aspektu uklopljenih sustava, a to je ispravan timing njegovih procesa. Zadnji odjeljak govori o alatima koji omogućuju efikasnu implementaciju uklopljenih sustava. 3.5.1. Osobine uklopljenih sustava Uklopljeni sustav (embedded system) je softver koji je ugrađen u neki hardverski uređaj, neposredno je u interakciji s hardverom i osigurava njegovo ispravno funkcioniranje. Taj softver reagira na događaje koje mu dojavljuje hardver. Kao odgovor na događaje, on šalje kontrolne signale hardveru. Pritom odgovor mora biti dovoljno brz jer u protivnom cijeli hardversko-softverski sklop neće raditi kako treba. Pravovremeno odgovaranje na događaje ključna je osobina svih uklopljenih sustava. Zbog toga uklopljene sustave možemo otprilike poistovjetiti sa sustavima u realnom vremenu. Ipak, zahtjevi u pogledu brzine odziva nisu uvijek jednako strogi. Na primjer, softver u meteorološkoj stanici iz odjeljka 3.3.3 ne treba biti osobito brz. No ABS koji u automobilu kontrolira upotrebu kočnice mora reagirati na blokadu kotača unutar nekoliko milisekundi. 88


Softversko inženjerstvo - skripta Općenito, sustav u realnom vremenu (real-time system) je softver čiji ispravni rad ovisi ne samo o rezultatima koje on proizvodi nego i o vremenu u kojem su ti rezultati proizvedeni. „Meki“ sustav u realnom vremenu (soft real-time system) je sustav kod kojeg se kršenje zahtjeva o brzini stvaranja rezultata smatra degradacijom performansi. „Tvrdi“ sustav u realnom vremenu (hard real-time system) je takav sustav gdje se spora proizvodnja rezultata smatra neispravnim radom. Osim potrebe za odzivom u realnom vremenu, postoje još neke osobine po kojima se uklopljeni sustavi razlikuju od drugih vrsta softvera. Slijedi popis tih osobina.  Uklopljeni sustav kontinuirano radi od trenutka paljenja hardvera do trenutka gašenja. U slučaju greške on se mora „oporaviti“ i nastaviti rad.  Interakcije s okolinom su nepredvidive i ne mogu se kontrolirati. Uklopljeni sustav mora odgovarati na neočekivani događaj čim se taj događaj desi, a ne onda kad bi to njemu odgovaralo. To znači da se takav sustav mora sastojati od više paralelnih procesa.  Za hardverski uređaj mogu postojati fizička ograničenja, kao što su ograničenje na raspoloživu energiju ili ograničenje na predviđeni prostor. Zato uklopljeni sustav mora štedjeti energiju ili mora preuzeti funkciju nekih dijelova hardvera koji ne stanu u prostor.  Uklopljeni softver često stupa u neposrednu interakciju s hardverom, bez posredovanja driver-a ili operacijskog sustava. To je potrebno zbog boljih performansi ili zbog specifičnosti samog hardvera.  Za uklopljenog sustave izuzetno je važno da su oni pouzdani i sigurni. Naime, uklopljeni sustavi često upravljaju uređajima čiji krivi rad bi mogao ugroziti ljude ili stvoriti velike materijalne štete. To onda vodi do konzervativnog pristupa u razvoju, dakle do korištenja starijih no provjerenih metoda i alata. Uklopljeni sustav treba zamišljati kao reakcijski sustav, dakle sustav koji reagira na događaje iz svoje okoline brzinom te okoline. Tražena vremena odziva obično su određena zakonima fizike. To je drukčije nego kod standardnih vrsta softvera gdje sam softver upravlja brzinom interakcije. Zahtjevi na uklopljeni sustav zadaju se navođenjem sljedećih elemenata.  Popis svih podražaja (događaja) koje sustav prima.  Odgovor sustava na svaki od podražaja.  Vrijeme odziva u kojem sustav mora proizvesti odgovor na pojedini podražaj. Kao primjer, prilažemo sliku 3.45 – ona prikazuje podražaje i odgovore za sustav zaštite od provalnika koji je instaliran u nekoj zgradi. O pripadnim vremenima odziva raspravljat ćemo u odjeljku 3.5.3. Vidimo da u sustavu zaštite od provalnika postoje četiri vrste podražaja: pad napona, otvaranje vrata, otvaranje prozora te pokreti u sobi. Ovisno o kombinaciji podražaja, proizvode se neki od sljedećih odgovora: prebacivanje napajanja s električne mreže na akumulatorsku bateriju, aktiviranje alarma, paljenje svjetala, slanje sintetizirane glasovne poruke policiji preko telefona. Ponašanje uklopljenog sustava zorno se može modelirati UML state machine dijagramom. Naime podražaji (događaji) na koje sustav reagira obično uzrokuju prelazak sustava iz jednog stanja u drugo. U odjeljku 2.3.4 na slici 2.22 već smo imali dijagram koji prikazuje rad mikrovalne pećnice. Sad kao drugi primjer prilažemo Sliku 3.46 – na njoj je state machine dijagram za benzinsku pumpu. PMF – Matematički odsjek

89

Robert Manger

Podražaj

Odgovor

Otvorila su se jedna vrata ili prozor ili je opažen pokret u jednoj sobi.

Pokreni alarm, upali svjetlo na odgovarajućem mjestu u zgradi.

Otvaranje vrata, otvaranje prozora ili pokreti istovremeno na dva ili više mjesta u zgradi.

Pokreni alarm, upali svjetlo na odgovarajućem mjestu, pošalji sintetiziranu glasovnu poruku policiji telefonom.

Pad napona između 10% i 20%.

Prebaci napajanje na akumulatorsku bateriju.

Pad napona više od 20%

Prebaci napajanje na akumulatorsku bateriju, pokreni alarm, pošalji sintetiziranu glasovnu poruku policiji telefonom.

Slika 3.45: podražaji i odgovori za sustav zaštite od provalnika.

Timeout

Kartica utaknuta u čitač

Čekanje Do: prikazuj dobrodošlicu

Timeout

Čitanje

Inicijalizacija

Do: čitaj kreditnu karticu

Do: inicijaliziraj prikaz

Kartica izvađena

Cijev izvan držača

Cijev u držaču

Kartica ok Validacija Do: provjeri valjanost kreditne kartice

Točenje

Spremna Brizgalica aktivirana

Do: toči gorivo, ažuriraj prikaz Brizgalica deaktivirana

Neispravna kartica

Resetiranje

Brizgalica aktivirana

Zaustavljena

Do: prikaži poruku o greški Plaćanje Potvrda plaćanja

Do: tereti kreditnu karticu

Cijev u držaču

Slika 3.46: UML state machine dijagram za sustav koji upravlja benzinskom pumpom.

90


Softversko inženjerstvo - skripta Proces oblikovanja uklopljenog sustava drukčiji je nego za obične vrste softvera [14]. Prvi korak obično se sastoji od donošenja odluke koje od funkcionalnosti će se implementirati u softveru a koje u hardveru. Ograničenja na energiju i prostor prilično sužavaju projektantovu slobodu, tako da klasični proces dekompozicije većih dijelova u manje obično nije primjenjiv. Najopćenitiji model građe uklopljenog sustava zasniva se na činjenici da sustav na podražaje reagira odgovorima. Podražaji se detektiraju pomoću hardverskih sklopova koji se zovu senzori (na primjer termometar, tlakomjer, voltmetar, fotoćelija, ...). Odgovori se postižu djelovanjem drugih hardverskih sklopova koji se zovu aktuatori (na primjer ventil, sirena, grijač, displej, ...). Softver se treba sastojati od više paralelnih procesa: svaki od tih procesa prati jedan ili više senzora, odnosno upravlja s jednim ili s nekoliko aktuatora. Daljnji korak u oblikovanju uklopljenog sustava je određivanje načina pokretanja njegovih procesa.  Proces za praćenje senzora pokreće se ovisno o prirodi samog podražaja. - Ako je riječ o periodičkom ili kontinuiranom podražaju, tada se proces za praćenje odgovarajućeg senzora treba automatski pokretati određeni broj puta u sekundi. Na primjer, senzor temperature (termometar) u kotlu treba se očitavati svakih 50 ms. - Ako je riječ o aperiodičkom podražaju koji se pojavljuje na nepredvidljiv način, tada se reakcija sustava treba pokrenuti preko hardverskog prekidnog mehanizma (interrupt). Dakle proces za praćenje senzora zapravo je interrupt handler. Na primjer, otvaranje vrata na mikrovalnoj pećnici pokreće hardverski prekid.  Proces za upravljanje aktuatorom pokreće se onda kad je potrebno odgovoriti na podražaj.  Mogu postojati i procesi koji rade stalno u pozadini i koriste trenutke kad procesor nije zauzet drugim poslovima – to se na primjer koristi za samo-testiranje uređaja. 3.5.2. Arhitekture uklopljenih sustava Kao što smo već rekli, uklopljeni sustav sastoji se od više paralelnih procesa, svaki o njih prati jedan ili više senzora odnosno upravlja s jednim ili s nekoliko aktuatora. Općeniti model arhitekture prikazan je na slici 3.47. Veza između procesa koji odgovaraju jednom senzoru odnosno jednom aktuatoru detaljnije je prikazana na slici 3.48.

Praćenje senzora

Praćenje senzora

Praćenje senzora

Praćenje senzora

Uklopljeni sustav (sustav u realnom vremenu)

Praćenje senzora Podražaji

Odgovori Upravljanje aktuatorom

Upravljanje aktuatorom



Slika 3.47: najopćenitiji model arhitekture uklopljenog sustava. PMF – Matematički odsjek

91

Robert Manger

Senzor

Aktuator

Podražaj Praćenje senzora

Odgovor Obrada podataka


Slika 3.48: veza između procesa za senzor i procesa za aktuator Općenita arhitektura sa slike 3.47 dalje se može profiniti tako da bolje odgovara nekim posebnim vrstama uklopljenih sustava. U nastavku ćemo promatrati tri takva profinjenja. Promatranje i reagiranje. Koristi se za sustave čiji rad se uglavnom svodi na redovito praćenje senzora i prikazivanje očitanih vrijednosti. U iznimnim situacijama kad senzori pokažu neuobičajene vrijednosti pokreće se neki dodatni proces. Struktura je prikazana na slici 3.49. Prikaz

Senzori

Proces promatranja

Vrijednosti iz senzora

Proces alarmiranja

Alarm

Proces analize podataka

Vrijednosti za prikaz

Proces prikazivanja

Proces za poduzimanje akcije

Druga oprema

Slika 3.49: arhitektura promatranja i reagiranja.

Primjer uklopljenog sustava koji bi mogao koristiti ovakvu arhitekturu je prije spominjani sustav za zaštitu od provalnika. Jedna varijanta njegove građe bit će priokazana u sljedećem odjeljku na slici 3.55. Dakle, sustav prati nekoliko vrsta senzora koji bilježe pokrete u sobama, otvaranje vrata ili prozora, pad napona u električnoj mreži. Kad sustav posumnja na prisutnost provalnika, on automatski zove policiju, pali svjetla u sobama i svira alarm. U slučaju pada napona također se uključuje pomoćno napajanje iz akumulatora. Upravljanje okolinom. Koristi se za sustave koji upravljaju radom nekog uređaja na osnovi podražaja iz okoline tog uređaja. Struktura je vidljiva na slici 3.50.

92


Softversko inženjerstvo - skripta Prikaz

Senzori

Proces promatranja

Vrijednosti iz senzora


Upravljačke naredbe

Vrijednosti za prikaz

Proces prikazivanja

Stanje aktuatora Proces za nadgledanje aktuatora

Proces za upravljanje aktuatorom Aktuator

Slika 3.50: arhitektura za upravljanje okolinom. Primjer uklopljenog sustava građenog u skladu s ovom arhitekturom je anti-lock braking system – ABS). Ugrađuje se u automobile da bi spriječio blokiranje kotača prilikom kočenja. Preko senzora na svakom kotaču ABS registrira da li se kotač okreće ili je blokiran. U slučaju blokade on šalje brzi niz on/off signala odgovarajućoj kočnici, što omogućuje kotaču da se opet pokrene. Detaljna građa ABS-a prikazana je na slici 3.51.

Kočnica 1

Upravljanje kočnicom 1

Senzor pritiska na pedalu

Kočnica 2

Nadgledanje pedale kočnice




Kočnica 3


Nadgledanje kotača

Senzori na kotačima

Kočnica 3

Slika 3.51: struktura procesa za ABS. PMF – Matematički odsjek

93

Robert Manger

Cjevovod procesa. Koristi se za sustave koji skupljaju podatke iz okoline i zatim ih obrađuju ili transformiraju. Budući da podaci stižu velikom brzinom, obrada također mora biti brza, inače bi se dio podataka mogao izgubiti. Zato se obrada razbija u niz zasebnih transformacija. Svaku od tih transformacija obavlja posebni procesor ili procesorska jezgra, što znači da se pojedine faze obrade odvijaju paralelno. Arhitektura cjevovoda prikazana je na slici 3.52.

Proces proizvođač

Proizvedeni podaci

Proces međuspremnik

Podaci za potrošača

Proces potrošač

...

Slika 3.52: arhitektura u obliku cjevovoda procesa.

Prikaz

Senzori za neutronski fluks

A/D konverter

Identifikator senzora i vrijednost fluksa

Obrada sirovih vrijednosti fluksa

Pohranjivanje prosječnih razina

Međuspremnik za sirove vrijednosti Prosječne razine fluksa

Međuspremnik za prosječne razine

Slika 3.53: procesi za skupljanje i obradu podataka o neutronskom fluksu.

Primjer uklopljenog sustava koji bi mogao koristiti cjevovod procesa jest sustav za skupljanje podataka unutar nuklearnog reaktora. Skupljaju se podaci sa senzora koji mjere neutronski fluks (gustoću neutrona) u reaktoru. Podaci iz senzora skupljaju se u međuspremniku, pa se iz međuspremnika izdvajaju i obrađuju. Prosječna razina fluksa prikazuje se na operatorovom zaslonu i zatim se sprema za buduću obradu. Detaljniji prikaz građe vidi se na slici 3.53. 3.5.3. Analiza vremenskih ograničenja za procese Rekli smo da korektnost rada uklopljenog sustava ovisi o brzini njegovog odgovaranja na podražaje. Zato kod oblikovanja uklopljenog sustava posebnu pažnju treba posvetiti timing-u njegovih procesa. Dakle za svaki proces treba procijeniti njegovo trajanje te predložiti način i frekvenciju njegovog pokretanja. Analiza procijenjenih i predloženih vrijednosti treba pokazati da će sustav biti u stanju obraditi sve podražaje i proizvesti sve odgovore na vrijeme.

94


Softversko inženjerstvo - skripta Analiza timing-a posebno je složena kad sustav mora izlaziti na kraj s mješavinom periodičkih i aperiodičkih podražaja. Budući da su aperiodički podražaji nepredvidljivi, analiza mora počivati na pretpostavkama o vjerojatnosti njihovog pojavljivanja. Ako se te pretpostavke pokažu krive, performanse sustava možda neće biti zadovoljavajuće. Ipak, današnja računala su brza pa je postalo moguće većinu podražaja tretirati kao periodičke. Dakle umjesto da podražaj implementiramo kao hardverski prekid, služimo se brzim procesom koji opetovano u kratkim vremenskim razmacima ispituje da li je do podražaja došlo ili nije. Zato ćemo se u nastavku koncentrirati na vremenska ograničenja za periodičke procese. U analizi vremenskih zahtjeva i oblikovanju sustava koji ispunjava te zahtjeve promatramo sljedeće veličine.  Krajnji rok (deadline). Vrijeme u kojem sustav mora proizvesti odgovor na određeni podražaj, mjereno od trenutka nastanka tog podražaja, Ako sustav promaši taj rok, to se smatra greškom odnosno degradacijom usluge, ovisno o tome da li je riječ o „tvrdom“ ili „mekom“ sustavu.  Frekvencija. Broj koliko se puta u jedinici vremena određeni proces mora izvršavati tako da smo sigurni da će dostići rokove.  Vrijeme izvršavanja. Vrijeme koje određeni proces troši na jedno svoje izvršavanje, dakle od početka do kraja svojeg rada. Riječ je o veličini koja varira ovisno o ulaznim podacima. Kod „tvrdih“ sustava procjenjujemo vrijeme u najgorem slučaju, a kod „mekih“ sustava može poslužiti i vrijeme u prosječnom slučaju. Kao primjer vremenske analize promatrat ćemo opet sustav za zaštitu od provalnika. Popis podražaja i odgovora već smo vidjeli na slici 3.45. No sada prilažemo i sliku 3.54 gdje su navedeni zahtjevi vezani uz vremena odziva.

Podražaj / odgovor

Zahtjev u pogledu vremena

Pad napona.

Prebacivanje na akumulatorsku bateriju mora se dovršiti unutar krajnjeg roka od 50 ms.

Otvaranje vrata.

Svaki od senzora za vrata mora se provjeravati barem dvaput u sekundi.

Otvaranje prozora.

Svaki od senzora za prozor mora se provjeravati barem dvaput u sekundi.

Pokreti u prostorijama.

Svaki od senzora za pokrete mora se provjeravati barem dvaput u sekundi.

Zvučni alarm.

Alarm se mora uključiti unutar pola sekunde od trenutka pojave podražaja na senzoru.

Paljenje svjetla.

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

Komunikacija s policijom.

Poziv policiji mora biti upućen unutar dvije sekunde od trenutka pojave podražaja na senzorima.

Slika 3.54: zahtijevana vremena odziva sustava za zaštitu od provalnika. PMF – Matematički odsjek

95

Robert Manger

Jedan mogući rezultat oblikovanja sustava za zaštitu od provalnika u skladu sa zahtjevima sa slike 3.45 i 3.54 prikazan je na slici 3.55. Dakle predlaže se građa koja se sastoji od glavnog kontrolnog procesa, dva procesa za interakciju s korisnikom, procesa za samo-testiranje, nekoliko procesa koji prate senzore i otkrivaju podražaje te nekoliko procesa koji upravljaju aktuatorima dakle proizvode odgovore.

50 Hz (0,5 ms)

Proces za praćenje senzora vrata

50 Hz (0,5 ms)

Proces za praćenje senzora pokreta

250 Hz (0,5 ms)

Proces za praćenje napona

50 Hz (0,5 ms)

B

Proces za praćenje korisnikovih unosa

Proces za samotestiranje

250 Hz (1 ms) Glavni kontrolni proces

Proces za 50 Hz praćenje senzora (0,5 ms) prozora

Proces za prikaz informacija korisniku

50 Hz (1 ms)

Proces za upravljanje napajanjem

R (20 ms)

Proces za upravljanje zvučnim alarmom

Proces za upravljanje rasvjetom

Proces za slanje poruke preko telefona

R (5 ms)

R (5 ms)

R (10 ms)

Slika 3.55: građa sustava za zaštitu od provalnika, timing procesa. U zamišljenoj građi senzor za pad napona samo je jedan. No da bi sustav bio učinkovit, senzora za vrata, prozore odnosno pokrete mora biti više, na primjer do 20 od svake vrste, a oni moraju biti raspoređeni na raznim mjestima u zgradi. Proces zadužen za otkrivanje podražaja određene vrste redom prati sve odgovarajuće senzore, ali tako da pri jednom pokretanju gleda samo jedan senzor. Za svaki od procesa na slici 3.55 označen je način pokretanja. Proces za samo-testiranje označen je s B, što znači da se on stalno izvršava u pozadini (background), dakle onda kad procesor nema drugog posla. Procesi s oznakom R pokreću se onda kad se pojavila određena kombinacija podražaja, ili točnije njih pokreće glavni kontrolni proces nakon što su mu procesi za praćenje senzora dojavili podražaje. Svi ostali procesi su periodički, automatski ih pokreće operacijski sustav u pravilnim vremenskim razmacima, a navedena im je frekvencija u Hz (broj uzastopnih pokretanja u sekundi). Na slici 3.55 je za sve procese osim testnog također navedeno vrijeme jednog izvršavanja u najgorem slučaju. Procesi za praćenje senzora vrlo su jednostavni, svode se na čitanje i usporedbu jednog podatka, zato su njihova vremena vrlo kratka i iznose 0,5 ms. Glavni kontrolni proces ima nešto više posla jer mora provjeriti više podataka i donijeti odluke, zato je njegovo vrijeme 1ms. Procesi koji upravljaju aktuatorima još su zahtjevniji, pa traju 5, 10 ili čak 20 ms. Kod periodičkih procesa frekvencije su konzistentne s vremenima izvršavanja, dakle proces završava prije trenutka kad bi se ponovo morao pokrenuti. 96



Lako je provjeriti da sustav na slici 3.55 zadovoljava vremenske zahtjeve sa slike 3.54. Kao primjer, analizirat ćemo učestalost provjere vrata. Proces za praćenje senzora za vrata ima frekvenciju 50 Hz, što znači da se pokreće svakih 20 ms. No senzora za vrata ima do 20, pa se isti senzor ponovo gleda tek nakon 20 pokretanja procesa. Dakle između dvije provjere istih vrata može proteći 400 ms, no to je još uvijek manje od traženih 500 ms. Slična analiza vrijedi i za prozore i pokrete. Primijetimo da proces za praćenje napona ima vrlo visoku frekvenciju 250 Hz – to je nužno da bi se prebacivanje napajanja na bateriju stiglo izvesti u traženom roku od 50 ms. Zaista, frekvencija od 250 Hz znači da se napon provjerava svakih 4 ms. No da bi se otkrio pad napona potrebne su dvije provjere i usporedba izmjerenih vrijednosti, što traje 9,5 ms. Nakon tog otkrića treba pričekati da se pokrene i izvrši glavni kontrolni proces, što može potrošiti daljnjih 5 ms. Glavni kontrolni proces pokrenut će proces za prebacivanje napajanja koji traje 20 ms. Dakle odgovor sustava proizvest će se u 33,5 ms, a to je unutar traženih 50 ms. Kad bi proces za praćenje napona radio na sporijoj frekvenciji od 50 Hz, reakcija na pad napona bila bi prespora. Naime, tada bi dva mjerenja i usporedba vrijednosti trajala 40,5 ms, a rad glavnog kontrolnog procesa i procesa za prebacivanje napajanja zahtijevao bi daljnjih 25 ms, pa bi ukupno vrijeme odziva bilo barem 65,5 ms. 3.5.4. Implementacija uklopljenih sustava Da bi implementirali uklopljeni sustav, potrebno je implementirati svaki od njegovih procesa. Također je potrebno osigurati da se procesi na željeni način pokreću i istovremeno izvršavaju. Za implementaciju svakog pojedinog procesa koriste se programski jezici. Ako je riječ o „tvrdom“ sustavu u realnom vremenu ili baratanju sa specifičnim hardverskim uređajima, tada se programira u assembleru. Inače se također intenzivno koristi i (obični) C. Objektnoorijentirani programski jezici se izbjegavaju – naime oni u pravilu proizvode manje efikasan programski kod koji često nije u stanju zadovoljiti postavljene zahtjeve na brzinu odziva. Ipak, postoje i posebne verzije objektno-orijentiranih jezika koje su bolje prilagođene potrebama uklopljenih sustava. Primjer za to je Real-time Java [15] gdje je promijenjen mehanizam dretvi tako da automatski garbage collector ne može prekinuti ili usporiti rad dretvi. Real-time Java za sada se koristi na platformama s relativno dobrom procesorskom snagom i memorijskim kapacitetom kao što su mobiteli. Nakon što smo implementirali sve procese, njihov istovremeni rad i međusobna suradnja ostvaruju se uz pomoć real-time operacijskog sustava (RTOS) [16]. Za razliku od standardnog operacijskog sustava poput Linux-a ili Microsoft Windows-a, RTOS je manji i jednostavniji, no on omogućuje finiju kontrolu izvršavanja procesa. Za svaki proces moguće je zadati način kako se on pokreće te frekvenciju njegovog uzastopnog pokretanja – RTOS će nastojati izvršavati procese onako kako mu je zadano. Primjeri RTOS-a su Windows CE, VxWorks, QNX i RTLinux. Građa RTOS-a vidljiva je na slici 3.57. Dakle, RTOS se obično sastoji od sljedećih dijelova: 1. Sat koji mjeri realno vrijeme i daje informacije potrebne za periodičko pokretanje procesa. 2. Interrupt handler koji poslužuje aperiodičke zahtjeve za uslugama. PMF – Matematički odsjek

97

Robert Manger 3. Scheduler koji pregledava listu procesa i bira one koji su spremni za izvršavanje. 4. Resource manager koji alocira memoriju i procesor za proces koji je spreman za izvršavanje. 5. Dispatcher koji pokreće proces s već alociranom memorijom i procesorom.

Informacije o načinu i frekvenciji pokretanja procesa

Sat u realnom vremenu

Scheduler

Interrupt handler

Zahtjevi procesa za resursima

Procesi koji čekaju resurse

Resource manager

Spremni procesi Lista spremnih procesa

Lista dostupnih resursa

Oslobođeni resursi

Dispatcher

Lista procesora

Proces koji se izvršava

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

98



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. PMF – Matematički odsjek

99

Robert Manger 4.1.2. Mjesto verifikacije i validacije u softverskom procesu V&V se prvenstveno primjenjuju na programski kod, no poželjno je da se u što većoj mjeri primjenjuju i u ranijim fazama razvoja softvera, kao što je prikazano na slici 4.1. Vidimo da se statička provjera može obavljati u raznim fazama softverskog procesa, dok je testiranje primjenjivo samo na program odnosno prototip. Program se najprije provjerava statičkim metodama, a nakon toga se još podvrgava testiranju.

Statička V&V

Dizajn na visokoj razini

Zahtjevi

Detaljni dizajn

Formalna specifikacija

Program

Prototip

Testiranje

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


Specifikacija sustava

Plan za primopredajni test

Puštanje u rad

Oblikovanje sustava

Plan za test integracije sustava

Primopredajni test

Detaljno oblikovanje

Plan za test integracije pod-sustava

Test integracije sustava

Kodiranje i testiranje modula i manjih dijelova

Test integracije pod-sustava

Slika 4.2: nastanak planova za testiranje softvera. Da bi aktivnosti V&V dale očekivane efekte, planovi testiranja trebali bi nastati već u fazi specifikacije i oblikovanja sustava, kao što je prikazano na slici 4.2. Plan za testiranje softvera je dokument sa sljedećim dijelovima:  opis procesa testiranja,  popis zahtjeva koji će se testirati, 100


Softversko inženjerstvo - skripta     

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

Zahtjevi

Lociraj grešku

Oblikuj popravak greške

Test primjeri

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-ih, 80-ih i 90-ih godina 20. stoljeća. Riječ je o reguliranom procesu u kojem sudjeluje grupa ljudi sa strogo zadanim ulogama: PMF – Matematički odsjek

101

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.

Planiranje

Distribucija materijala

Individualna priprema

Sastanak inspekcije

Popravak programa

Nastavak

Slika 4.4: proces inspekcije programa. Vrsta greške Greške s podacima

Greške vezane uz tok kontrole

Greške s ulazom i izlazom Greške sa sučeljima

Greške vezane uz upravljanje memorijom Greške u upravljanju iznimkama

Inspekcijska provjera 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? 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? 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? 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? Postoje li neinicijalizirani 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 dealocirana onda kad se više ne koristi? Jesu li sva moguća stanja greške uzeta u obzir?

Slika 4.5: lista čestih programerskih grešaka.

102



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


103

Robert Manger Slika 4.6 prikazuje seansu analiziranja (malog i besmislenog) C programa pomoću standardnog UNIX alata za statičku analizu lint. U gornjem dijelu priloga vidi se sam C kod; zatim se vidi da prevodilac cc ne javlja nikakve greške; nakon toga poziva se lint; dalje se vide lint-ove poruke (upozorenja) - na primjer varijabla c odnosno i bila je korištena prije nego što je bila inicijalizirana, a funkcija printarray() bila je pozivana s krivim brojem ili tipom parametara. Nema sumnje da za jezike poput C statička analiza predstavlja efikasnu tehniku za otkrivanje programerskih grešaka. No u „strožim“ jezicima poput Jave samim pravilima jezika izbjegnute su neke konstrukcije koje lako dovode do greške, na primjer sve varijable moraju biti inicijalizirane, nema goto naredbi (pa je teže stvoriti nedostupni kod), upravljanje memorijom je automatsko (nema pokazivača). Takav pristup sprečavanja grešaka umjesto njihovog kasnijeg otkrivanja pokazuje se efikasnim načinom poboljšavanja pouzdanosti programa. Zato je statička analiza u slučaju Java programa manje isplativa nego u slučaju C programa. 4.2.3. Formalna verifikacija Formalna verifikacija svodi se na matematičko dokazivanje da je program konzistentan sa svojom specifikacijom. Moguća je pod sljedećim uvjetima:  semantika programskog jezika je formalno definirana;  postoji formalna specifikacija za program. Dokaz se provodi tako da se polazni uvjeti iz specifikacije i same naredbe iz programa uzmu kao činjenice, pa se iz njih izvode konačni uvjeti koji po specifikaciji moraju biti zadovoljeni nakon izvršenja programa. Formalna verifikacija je zahtjevna i mukotrpna aktivnost. Obično se provodi samo nad manjim dijelovima softvera, i to dijelovima koji su važni sa stanovišta sigurnosti ili pouzdanosti. Da bi se posao ubrzao, koriste se alati za automatsko dokazivanje, takozvani theorem prover-i. U praksi se ova tehnika često reducira na malo strožu inspekciju: razvijaju se strogi (no ne sasvim formalni) argumenti da program radi korektno. Primjer takvog pristupa koji uključuje strogu inspekciju je Cleanroom Software Development (IBM, 90-e godine 20. stoljeća, autor Mills i drugi). Idejom formalne verifikacije intenzivno su se bavila mnoga velika imena računarstva tijekom 70-ih godina 20. stoljeća (Hoare, Dijkstra, Wirth). Ipak, u to vrijeme nije se došlo dalje od malih akademskih primjera. Ideja se i dalje njeguje u krugovima pobornika formalnih metoda za razvoj softvera, predmet je intenzivnog istraživanja te polako postiže sve bolje rezultate. U posljednje vrijeme pažnju istraživača privlači varijanta formalne verifikacije koja se zove provjera modela (model checking). Kod model checking-a, softver koji želimo verificirati prikazuje se odgovarajućim matematičkim modelom, na primjer konačnim automatom ili logičkim izrazom. Zatim se dokazuje da taj model ima neko poželjno svojstvo. Dokazivanje se obično svodi na sistematsku provjeru svih mogućnosti, na primjer prolazak svih putova kroz konačni automat ili generiranje svih kombinacija vrijednosti varijabli u logičkom izrazu. Provjeru obavlja posebni alat, takozvani model checker. Rezultat provjere je ili potvrda da svojstvo vrijedi ili protuprimjer koji pokazuje da svojstvo ne vrijedi. Cijeli postupak ilustriran je slikom 4.7.

104



Gradnja modela

Model sustava

Dizajn ili program

Model checker Specifikacija svojstava

Poželjna svojstva sustava Potvrda ili kontraprimjeri

Slika 4.7: postupak provjere modela (model checking). Kao primjer model checking-a, zamislimo da za meteorološku stanicu koju smo proučavali u odjeljku 3.3.3 želimo dokazati da ona uvijek prije ili kasnije ulazi u stanje slanja podataka. Tada nam kao model može poslužiti UML state machine dijagram sa slike 3.26. Provjera svojstva svodi se na generiranje svih mogućih putova (svih mogućih nizova prijelaza) kroz dijagram. Ako svaki od tih putova sadrži stanje „Šalje podatke“, svojstvo je dokazano. Inače smo našli protuprimjer, dakle mogući niz prijelaza za koji svojstvo ne vrijedi. Primijetimo da se metodama model checking-a postiže samo parcijalna verifikacija softvera: provjeravaju se samo neka svojstva koja slijede iz specifikacije, a zanemaruju se ostala svojstva. Ključna stvar u model checking-u je stvaranje modela programa. Ako se model stvara ručno, to može zahtijevati previše vremena. Također, lako se može desiti da model ne odgovara u potpunosti programu. Zato je puno bolje ako se model stvara automatski iz izvornog teksta programa. Takvo automatsko stvaranje postoji na primjer u alatu Java Pathfinder kojeg je razvila NASA i koji služi za verifikaciju Java programa. Pobornici formalne verifikacije tvrde da ona vodi do pouzdanijeg i sigurnijeg softvera. Tvrdnja je velikom dijelom točna, no ne u potpunosti. Razlozi za to su sljedeći.  Specifikacija (čak i formalna) ne mora odražavati stvarne zahtjeve korisnika.  Dokaz korektnosti programa je velik i složen, pa može sadržavati i greške.  Korisnici će možda koristiti softver na način koji se razlikuje od onoga koji se pretpostavljao u dokazu korektnosti.

4.3.

Testiranje softvera

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

105

Robert Manger   

Razvojno testiranje provodi razvojni tim tijekom razvoja softvera. Testiranje izdanja obavlja posebni tim za testiranje unutar softverske kuće uoči isporuke novog izdanja softvera. Korisničkim testiranjem bave se sami korisnici tijekom isporuke softvera.

Testiranje

Razvojno testiranje (development testing) Statističko testiranje Testiranje u svrhu otkrivanja grešaka Testiranje dijelova Funkcionalno testiranje Strukturalno testiranje Testiranje po putovima Testiranje integracije Testiranje izdanja (release testing) Testiranje zahtjeva Testiranje scenarija Testiranje performansi Korisničko testiranje (user testing) Alfa testiranje Beta testiranje Primopredajno testiranje

Slika 4.8: klasifikacija raznih vrsta testiranja. 106



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

Testiranje dijelova Testiranje jedinki (funkcija, klasa)

Testiranje integracije

Testiranje modula

Testiranje pod-sustava

Testiranje sustava

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

Testiranje dijelova

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


107

Robert Manger 4.3.2. Testiranje dijelova softvera Da bi testiranje dijela softvera bilo uspješno, važno je znati odabrati test podatke. U nastavku ćemo promatrati nekoliko pristupa koji se razlikuju po načinu odabira test podataka. Funkcionalno testiranje (black-box testing). Test-primjeri izvode se isključivo iz specifikacije dotičnog dijela softvera. Ili, drukčije rečeno, softver se promatra kao „crna kutija“ o kojoj jedino znamo da bi ona (prema specifikaciji) za zadane ulaze trebala proizvesti zadane izlaze. Zbog postojanja grešaka, ulazi iz određenog (nepoznatog) skupa Ie izazvat će neispravno ponašanje, koje ćemo prepoznati po izlazima iz skupa Oe. To je sve prikazano na slici 4.11. U postupku testiranja nastojimo izabrati ulaze za koje postoji velika vjerojatnost da pripadaju skupu Ie. Izbor takvih test primjera najčešće se zasniva na iskustvu softverskog inženjera. Ipak, moguć je i sistematičniji pristup zasnovan na podjeli skupa svih mogućih ulaznih podataka (domene) na klase. Ovdje riječ „klasa“ nije upotrjebljena u smislu objektnoorijentiranog 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 testprimjer iz svake klase. Također je dobro isprobati „rubove“ klasa.

Ulazni podaci

Ie

Testirani dio softvera

Izlazni rezultati

Oe

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



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 Jedna vrijednost Jedna vrijednost Više od jedne vrijednosti Više od jedne vrijednosti Više od jedne vrijednosti Više od jedne vrijednosti

Traži se Element iz polja Element koji nije u polju Prvi element u polju Zadnji element u polju Srednji element u polju Element koji nije u polju

Slika 4.13: particija domene za funkcionalno testiranje.

Ulazno polje (T) 17 17 17, 29, 21, 23 41, 18, 9, 31, 30, 16, 45 17, 18, 21, 23, 29, 41, 38 21, 23, 29, 33, 38

Tražena vrijednost (Key) 17 0 17 45 23 25

Izlaz (Found, L) true, 1 false, ?? true, 1 true, 7 true, 4 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 PMF – Matematički odsjek

109

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) { int bottom = 0: 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. } } 1. 2.

Slika 4.15: implementacija procedure za traženje elementa u polju (binarno traženje).

Granice klasa ekvivalencije

Elementi < srednjeg

Elementi > srednjeg

Element na sredini

Slika 4.16: particija domene za strukturalno testiranje.

110



Ulazno polje (T) 17 17 17, 21, 23, 29 9, 16, 18, 30, 31, 41, 45 17, 18, 21, 23, 29, 38, 41 17, 28, 21, 23, 29, 33, 38 12, 18, 21, 23, 32 21, 23, 29, 33, 38

Tražena vrijednost (Key) 17 0 17 45 23 21 23 25

Izlaz (Found, L) true, 1 false, ?? true, 1 true, 7 true, 4 true, 3 true, 4 false, ??

Slika 4.17: test primjeri za strukturalno testiranje. Testiranje po putovima (path testing). Riječ je o posebnoj vrsti strukturalnog testiranja, gdje se test primjeri biraju tako da se isproba svaki „nezavisni put“ kroz dijagram toka kontrole testiranog dijela softvera. Dakle najprije se mora nacrtati dijagram toka kontrole dotičnog dijela softvera. Dijagram se crta tako da se naredbe while i if - then - else prikažu obrascima sa slike 4.18, a ostale naredbe se prikažu svaka po jednim čvorom. Uočavaju se čvorovi koji predstavljaju „početak“ i „kraj“ toka kontrole. Testiranje po putovima zahtijeva da se konstruiraju takvi test primjeri koji će isprobati svaki od nezavisnih putova kroz dijagram. Nezavisni put je onaj koji ide od „početka“ do „kraja“ i prolazi bar jednim novim lukom.

ne

Uvjet

Uvjet da

da

ne

True-grana

Tijelo

Nastavak

while

False-grana

Nastavak

if-then-else

Slika 4.18: obrasci za crtanje dijagrama toka kontrole. Za Java implementaciju binarnog traženja sa slike 4.15 odgovarajući dijagram toka kontrole vidi se na slici 4.19. Brojevi čvorova na dijagramu odgovaraju brojevima redaka u Java kodu. Početak toka kontrole je čvor 1 a kraj je čvor 14. Postoje 4 nezavisna puta, i to:  1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14;  1, 2, 3, 4, 5, 14;  1, 2, 3, 4, 5, 6, 7, 11, 12, 5, 6, 7, 8, 9, 10, 14;  1, 2, 3, 4, 5, 6, 7, 11, 13, 5, 6, 7, 8, 9, 10, 14 ; Ako se u test primjerima prođe svaki od ovih putova, tada smo sigurni da je:  svaka naredba bila izvršena bar jednom,  svako grananje bilo isprobano za slučaj istine i za slučaj laži. PMF – Matematički odsjek

111

Robert Manger 1

2

3

4 bottom > top

5

while bottom <= top

6 elemArray[mid] != key 7

11 elemArray[mid] > key

elemArray[mid] = key 8

12

elemArray[mid] < key 13

9

14

10

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



A

B

Test primjeri

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 testove koji koriste ekstremne vrijednosti parametara.  Ako se prenašaju pokazivači (pointer-i), isprobaj primjere s nul-pokazivačima. PMF – Matematički odsjek

113

Robert Manger 

Ako se razmjenjuju poruke, probaj stvoriti znatno više poruka nego što se očekuje u normalnim okolnostima. Ako se koristi zajednička memorija, variraj redoslijed aktiviranja dijelova softvera koji pristupaju toj memoriji.



Softverski sustavi obično sadrže nekoliko razina integracije. Na primjer: najmanje jedinke udružuju se u module, koji se spajaju u podsustave, koji čine sustav. Zbog više razina integracije, testiranje integracije mora se ponoviti više puta. Pritom redoslijed testiranja može biti jedan od sljedeća dva.  Top-down: najprije se testira integracija na najvišoj razini, zatim na nižoj razini, … , na kraju na najnižoj razini. Pritom se nepostojeći ili netestirani dijelovi s niže razine zamjenjuju s nadomjescima - takozvanim stub-ovima. Stub ima isto sučelje kao odgovarajući dio ali vrlo ograničenu funkcionalnost.  Bottom-up: najprije se testira integracija na najnižoj razini, zatim na idućoj višoj razini, …, na kraju na najvišoj razini. Nisu potrebni stub-ovi jer za svaku iduću razinu integracije već imamo implementirane i testirane sve sastavne dijelove. Ipak, potrebni su test driver-i koji pozivaju manje dijelove softvera i simuliraju njihovu okolinu. Dva redoslijeda testiranja integracije ilustrirana su na slikama 4.21 i 4.22.

Redoslijed testiranja

Razina 1

Umetci za razinu 2

Razina 2

...

Razina 1

Razina 2

Razina 2

Razina 2

Umetci za razinu 3

Slika 4.21: testiranje integracije u redoslijedu top-down.

Test driver-i

Razina N

Razina N

Razina N

Razina N

Razina N Redoslijed testiranja

Test driver-i

Razina N-1

Razina N-1

Razina N-1

Slika 4.22: testiranje integracije u redoslijedu bottom-up.

114


Softversko inženjerstvo - skripta Prednost top-down redoslijeda je da on ranije otkriva eventualne greške u arhitekturi. Također, psihološka prednost top-down-a je da se relativno rano dobiva sustav koji radi (doduše s ograničenom funkcionalnošću) i koji se može pokazivati. Mana top-down-a je da se troši vrijeme na izradu stub-ova. Prednost bottom-up redoslijeda je da se lakše uključuju gotove komponente. Također, prednost bottom-up-a je da arhitektura ne mora biti dovršena sve do zadnjeg časa. Mana bottom-up-a je da se troši vrijeme na izradu test driver-a. 4.3.4. Razvoj softvera vođen testiranjem Neki autori smatraju da je testiranje toliko važno da ono može voditi cijeli proces razvoja softvera. Ti autori formulirali su ideju razvoja vođenog testiranjem (test-driven development) [17]. Riječ je o pristupu gdje se testiranje isprepliće s razvojem programskog koda. Dakle kod se razvija na inkrementalan način zajedno s testovima za taj inkrement. Nema pomaka na idući inkrement sve dok trenutna verzija koda ne prođe test. Razvoj softvera vođen testiranjem sastavni je dio agilnih metoda poput XP [10] i tamo se zove test-first development. No isti pristup može se uklopiti i u klasične metode. Proces razvoja vođenog testiranjem ilustriran je slikom 4.23.

Identificiraj novu funkcionalnost

Napiši test

prošao

Izvrši test

nije prošao

Implementiraj funkcionalnost uz refactoring

Slika 4.23: razvoj softvera vođen testiranjem. Kao što vidimo na slici 4.23, razvoj vođen testiranjem sastoji se od sljedećih koraka. 1. Identificira se novi inkrement funkcionalnosti. On treba biti relativno mali, tako da se može implementirati u nekoliko desetaka redaka koda. 2. Piše se test za tu funkcionalnost te se taj test implementira pomoću CASE alata za automatsko testiranje. 3. Nad trenutnom verzijom softvera izvršava se novi test zajedno sa svim prijašnjim testovima koji su bili implementirani ranije. U prvom pokušaju novi test neće proći budući da nova funkcionalnost još nije bila implementirana. 4. Sad se tek implementira nova funkcionalnost i ponovo se izvršava test. Implementiranje može uključiti i refactoring postojećeg koda. 5. Nakon što novi testovi uspješno prođu, moguće je nastaviti s implementacijom idućeg komada funkcionalnosti. PMF – Matematički odsjek

115

Robert Manger

Da bi razvoj vođen testiranjem bio izvediv, neophodan je odgovarajući CASE-alat za automatsko testiranje. Primjer takvog alata je JUnit [18] – on služi za testiranje Java programa. JUnit radi tako da testove ugrađuje u posebni program. Taj program pokreće testove time što poziva sustav koji testiramo. Na taj način moguće je pokrenuti stotine pohranjenih testova u nekoliko sekundi. Prema mišljenju njegovih pobornika, razvoj vođen testiranjem ima sljedeće prednosti.  Bolje razumijevanje koda. Pisanjem testa programer bolje artikulira svoju ideju o tome što bi idući segment koda trebao raditi.  Bolja pokrivenost koda testovima. Osigurano je da za svaki komad koda postoji odgovarajući test. Sigurni smo da će se svi dijelovi koda izvršiti prilikom testiranja.  Testiranje unatrag. Skup testova postepeno se razvija zajedno sa sustavom. Nakon svake promjene programskog koda moguće je odmah izvesti sve stare testove i provjeriti da promjena nije narušila staru funkcionalnost.  Jednostavnije debuggiranje. Kad test ne prođe, očito je da se uzrok nalazi u novom dijelu koda – njega treba provjeriti i promijeniti. Nisu potrebni alati za debuggiranje.  Dokumentiranje sustava. Sami testovi služe kao vrsta dokumentacije koja opisuje što bi programski kod trebao raditi. Čitanje testova omogućuje lakše razumijevanje koda. S druge strane, primijećeno je da razvoj vođen testiranjem ima sljedeće nedostatke.  Nepogodan je ako upotrebljavamo velike dijelove tuđeg ili baštinjenog koda, pa moramo pisati testove za te velike dijelove.  Nije efikasan kod sustava s više dretvi. Naime, dretve se mogu drukčije ispreplesti pri različitim pokretanjima testa, što može stvoriti različite rezultate.  Nije primjenjiv za testiranje integracije ili testiranje performansi ili pouzdanosti cijelog sustava. Slično kao i agilne metode, razvoj vođen testiranjem za sada se pokazao uspješnim kod malih ili srednje velikih projekata.

116



5. Održavanje i evolucija Nakon puštanja u uporabu, softverski sustav mora se i dalje mijenjati. Promjene softvera nužne su da bi se držao korak s novim korisničkim zahtjevima, promjenama poslovnog okruženja, napretkom hardvera i tako dalje. U sljedećim potpoglavljima najprije govorimo općenito o dva osnovna načina mijenjanja softvera, a to su održavanje odnosno evolucija. Zatim detaljnije proučavamo organizirani proces održavanja koji se obično naziva upravljanje konfiguracijom. Na kraju se bavimo specifičnom problematikom mijenjanja zastarjelog (baštinjenog) softvera.

5.1.

Općenito o održavanju i evoluciji

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


117

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

118



sustav 1

Manje kvalitetan razvoj

sustav 2

Kvalitetniji razvoj

Skuplje održavanje

Jeftinije održavanje cijena

Slika 5.1: utjecaj kvalitete razvojnog procesa na cijenu održavanja softvera. U nastavku nastojimo popisati osnovne faktore koji utječu na cijenu održavanja. 1. Cjelovitost polazne specifikacije. Ukoliko odmah uključimo sve zahtjeve, kasnije će biti manje perfekcijskog održavanja. 2. Dobrota oblikovanja. Dobar dizajn je jeftiniji za održavanje. Smatra se da su sa stanovišta održavanja najbolji objektno-oblikovani sustavi, koji se sastoje od malih modula s jakom unutrašnjom kohezijom i labavim vezama prema van. 3. Način implementacije. Kod u „strožem“ programskom jeziku poput Jave lakše se održava nego kod u jeziku poput C-a. Strukturirani kod (if, while) sa smisleno imenovanim varijablama razumljiviji je od kompaktnog koda s mnogo goto naredbi. 4. Stupanj verificiranosti. Dobro verificirani softver ima manje grešaka pa će zahtijevati manje korekcijskog održavanja. 5. Stupanj dokumentiranosti. Uredna, dobro strukturirana i cjelovita dokumentacija olakšava razumijevanje softvera te na taj način pojeftinjuje održavanje. 6. Način upravljanja konfiguracijom. Ukoliko se primjenjuju metode, alati i organizacijska pravila upravljanja konfiguracijom, tada je održavanje na dugi rok jeftinije. 7. Starost softvera. Što je softver stariji, to je skuplji za održavanje, budući da mu se građa degradirala, ovisan je o zastarjelim razvojnim alatima, a dokumentacija mu je postala neažurna. 8. Svojstva aplikacijske domene. Ako je riječ o stabilnoj domeni gdje se poslovna pravila rijetko mijenjaju, tada će se rijetko pojavljivati potreba za perfekcijskim održavanjem u svrhu usklađivanja s novim pravilima. 9. Stabilnost razvojnog tima. Održavanje je jeftinije ako se njime bave originalni razvijači softvera, jer oni ne moraju trošiti vrijeme na upoznavanje sa softverom. 10. Stabilnost platforme. Ako smo softver implementirali na platformi koja će još dugo biti suvremena, tada neće trebati adaptacijsko održavanje. Na prvih šest faktora moguće je utjecati tijekom originalnog razvojnog procesa. 5.1.4. Održavanje unutar agilnih metoda Klasične metode razvoja prave jasnu razliku između originalnog razvoja softvera i njegovog kasnijeg održavanja. Kod agilnih metoda zapravo nema jasne razlike. Naime.  Razvoj se ionako promatra kao beskonačni niz iteracija u kojima se softver stalno mijenja i usklađuje sa zahtjevima.  Prve iteracije u tom nizu mogu se smatrati originalnim razvojem.  Kasnije iteracije odgovaraju održavanju. PMF – Matematički odsjek

119

Robert Manger

Najpoznatija agilna metoda XP odlikuje se raznim osobinama koje smo opisali u odjeljku 1.3.3. Neke od tih osobina posebno su zanimljive i korisne sa stanovišta održavanja. Zaista:  Korisničke priče, koje prvo služe za izražavanje početnih zahtjeva, kasnije mogu služiti za opis zahtjeva za promjenama.  Stalna uključenost korisnika u razvojni proces omogućuje da se ispravno odredi prioritet promjena tijekom održavanja.  Tehnika test-first development rezultira velikim brojem testova koji omogućuju automatsku provjeru ispravnosti softvera nakon svake promjene tijekom održavanja.  Reorganizacija programskog koda takozvanim refactoring-om može se shvatiti kao preventivno održavanje, dakle kao investicija u kvalitetu softvera u svrhu njegovog lakšeg kasnijeg mijenjanja. U skladu s agilnim metodama, održavanje nije ništa drugo nego nastavak agilnog razvojnog procesa. Ipak, poteškoće mogu nastupiti onda kad se originalnim razvojem softvera bavio jedan tim, a održavanje se prepušta nekom drugom timu. Postoje dvije problematične situacije. 1. Ako je razvojni tim koristio agilni pristup, a tim za održavanje nije tome vičan pa želi raditi na klasičan način. Timu za održavanje tada će nedostajati detaljna dokumentacija sustava. 2. Ako je razvojni tim koristio klasični pristup, no tim za održavanje preferira agilne metode. Tada tim za održavanje mora potrošiti dosta vremena za razvoj nedostajućih automatiziranih testova.

5.2.

Upravljanje konfiguracijom

Tijekom svog životnog vijeka softverski sustav se održava. Kao rezultat tog održavanja nastaju brojne verzije sustava. Svaka verzija može se promatrati kao nešto drukčija konfiguracija sastavnih dijelova. Da bismo mogli izaći na kraj sa svim tim konfiguracijama, potrebna nam je posebna aktivnost koji se naziva upravljanje konfiguracijom. U sljedećim odjeljcima najprije ćemo opisati svrhu upravljanja konfiguracijom te njegovu podjelu na podaktivnosti. Zatim ćemo detaljnije opisati svaku od podaktivnosti. 5.2.1. Svrha upravljanja konfiguracijom, podjela na podaktivnosti Upravljanje konfiguracijom (configuration management) je organizirani skup pravila, postupaka i alata kojima se kontrolira mijenjanje softvera i evidentiraju se njegove različite verzije. Upravljanje konfiguracijom potrebno je kod velikih sustava gdje postoji velik broj različitih verzija koje su istovremeno u razvoju ili u uporabi. Pojedine verzije implementiraju pojedine prijedloge za promjenama, popravke grešaka te prilagodbe različitim hardverima ili operacijskim sustavima. Kad se ne bi služili odgovarajućim pravilima, postupcima i alatima, lako bi nam se moglo desiti da izgubimo evidenciju o tome koje promjene ili dijelovi su bili ugrađeni u koju verziju sustava. Također bi nam se moglo desiti da počnemo mijenjati krivu verziju, ili da krivu verziju isporučimo korisnicima, ili da zaboravimo gdje je pohranjen izvorni kod za neku određenu komponentu. Osim evidencije o promjenama i verzijama, sustav za upravljanje konfiguracijom mora također omogućiti timski rad većeg broja (možda 120


Softversko inženjerstvo - skripta dislociranih) programera, tako da oni mogu raditi svoje promjene bez da jedan drugom smetaju. Upravljanje konfiguracijom je aktivnost koja u sebi uključuje sljedeće četiri podaktivnosti. 1. Upravljanje promjenama. Prate se zahtjevi za promjenama koje su postavili korisnici. Procjenjuju se troškovi i učinci tih promjena. Za svaku predloženu promjenu odlučuje se da li će se ona implementirati i kada će se implementirati. 2. Upravljanje verzijama. Identificiraju se različite verzije sustava i njegovih dijelova. Osigurava se da promjene koje rade različiti inženjeri ne interferiraju jedne s drugima, nego rezultiraju različitim verzijama. 3. Gradnja sustava. Za određenu verziju sustava pronalaze se odgovarajuće verzije dijelova programskog koda, podataka i biblioteka te se njihovim prevođenjem i spajanjem stvara izvršivi program. 4. Upravljanje izdanjima. Vodi se evidencija o izdanjima, dakle verzijama sustava koje su dane korisnicima na uporabu. Odlučuje se o objavi novog izdanja, pa se zatim softver priprema za isporuku korisnicima. Navedene četiri podaktivnosti u bliskoj su vezi i nemoguće ih je sasvim razdvojiti. To je ilustrirano slikom 5.2. Na primjer, kao rezultat upravljanja promjenama nastaju nove verzije sustava koje se evidentiraju unutar upravljanja verzijama. Da bi gradnja sustava ispravno sagradila novu verziju, potrebne su joj informacije iz domene upravljanja verzijama koje kažu od kojih se dijelova ta određena verzija sastoji. S obzirom da su izdanja sustava samo neke od verzija, upravljanje izdanjima opet se oslanja na upravljanje verzijama.

Zahtjevi za promjenama Gradnja sustava Upravljanje promjenama

Verzije sustava

Verzije dijelova

Upravljanje verzijama

Izdanja sustava

Upravljanje izdanjima

Slika 5.2: podaktivnosti unutar upravljanja konfiguracijom.

Rekli smo da se upravljanje konfiguracijom sastoji od pravila, postupaka i alata. Pravila i postupci definiraju na primjer način postavljanja zahtjeva za promjenama, način odlučivanja o promjenama, način baratanja s različitim verzijama sustava i njegovim dijelovima, ili način PMF – Matematički odsjek

121

Robert Manger distribuiranja novih izdanja korisnicima. Alati služe na primjer za bilježenje i pretraživanje zahtjeva za promjenama, pohranjivanje verzija svih dijelova, gradnju sustava iz tih dijelova, identificiranje svih verzija i izdanja. Može biti riječ o jednostavnim alatima koji podržavaju samo pojedini zadatak poput evidencije bug-ova, ili o složenim integriranim okolinama koje podržavaju i objedinjuju sve podaktivnosti unutar upravljanja konfiguracijom. Jasno je da je upravljanje konfiguracijom to važnije što je softverski sustav složeniji a njegove verzije koje se istovremeno moraju održavati brojnije. Veliki sustavi s mnogo verzija u pravilu nastaju primjenom klasičnih metoda razvoja. Kod malih sustava i agilnih metoda potreba za strogo organiziranim upravljanjem konfiguracijom znatno je manja. Naime, upravljanje se tada odvija na implicitan i neformalan način unutar samog agilnog procesa razvoja i održavanja. Zaista, u skladu s metodom XP, korisnici su neposredno uključeni u planiranje novih verzija, što predstavlja jedan vid neposrednog upravljanja promjenama. Također, naglasak je na stalnom mijenjanju više-manje samo jedne (zadnje) verzije sustava, što pojednostavnjuje upravljanje verzijama i gradnju sustava. Isto tako, korisnicima se redovito svaki tjedan isporučuje nova verzija sustava, što znači da nema potrebe za zasebnim upravljanjem izdanjima. 5.2.2. Upravljanje promjenama Upravljanje promjenama treba osigurati da se promjene sustava odvijaju na kontrolirani način te da se prioritet daje najhitnijim, najvažnijim i najisplativijim promjenama. Riječ je o procesu koji se bavi cost/benefit analizom predloženih promjena, odobravanjem promjena koje su svrsishodne te identificiranjem dijelova sustava koje treba promijeniti. Jedan od mogućih modela tog procesa prikazan je na slici 5.3. Upravljanje promjenama počinje kad korisnik ili član tima za podršku korisnicima pošalje zahtjev za promjenom. To na primjer može biti izvještaj o bug-u s opisom simptoma ili zahtjev za dodatnom funkcionalnošću. Zahtjev za promjenom obično se oblikuje ispunjavanjem predviđenog obrasca koji je danas obično u elektroničkom obliku. Korisnik ispunjava samo neka polja u tom obrascu, a u postupku obrade zahtjeva te donošenja odluke odgovorne osobe ispunjavaju dodatna polja. Na taj način u svakom trenutku je vidljivo trenutno stanje zahtjeva. Primjer djelomično ispunjenog obrasca vidi se na slici 5.4. Nakon što je zahtjev bio poslan, odgovorna osoba iz tima za podršku korisnicima provjerava je li on valjan. Provjera je potrebna zato što su mnogi zahtjevi takvi da ne zahtijevaju akciju. Na primjer, isti bug možda je već bio prijavljen. Ili je možda riječ o nesporazumu o tome što sustav treba raditi. Ili se zahtijeva funkcionalnost koja je već implementirana no korisnik to ne zna. U svim ovakvim slučajevima, zahtjev se zatvara s time da se u obrazac prethodno upisuje razlog zatvaranja. No ako je riječ o valjanom zahtjevu, on se stavlja na listu aktivnih neriješenih zahtjeva koji čekaju daljnju analizu. Sljedeća faza u obradi valjanog zahtjeva je tehnička procjena opsega i cijene tražene promjene. To obično radi tim za razvoj i održavanje softvera. Proučava se utjecaj promjene na ostatak sustava, to jest utvrđuje se koji sve dijelovi sustava su pogođeni promjenom. Ako jedna promjena zahtijeva i niz promjena na drugim mjestima, to će povećati njenu cijenu. Nakon tehničke procjene opsega i cijene, posebna grupa odgovornih osoba odlučuje je li promjena svrsishodna i isplativa s poslovnog stanovišta. Ta grupa obično se naziva change 122


Softversko inženjerstvo - skripta 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. Podrška korisnicima

Korisnik

Pošalji zahtjev

Provjeri zahtjev nevaljan Zahtjevi za promjenama

Zatvori zahtjev

valjan Registriraj zahtjev

Razvoj i održavanje

Analiza implementacije

Change Control Board

Poslovna procjena

Procjena opsega i cijene

Odobravanje promjene

Promjena softvera

odobreno

Testiranje softvera

nije odobreno Zatvori zahtjev

prošao Zatvori zahtjev

nije prošao

Slika 5.3: proces upravljanja promjenama.


123

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


Softversko inženjerstvo - skripta U agilnim metodama poput XP postupak upravljanja promjenama nije u tolikoj mjeri formaliziran. Naime, prema pravilima XP korisnici su neposredno uključeni u odlučivanje hoće li ili neće neka promjena biti implementirana te koji je prioritet pojedine promjene. Ipak, promjene koje se tiču poboljšanja strukture samog softvera, takozvani refactoring, prepuštene su isključivo programerima. Upravljanje promjenama obično je podržano specijaliziranim softverskim alatom. Primjer takvog alata je Bugzilla koja služi za prijavljivanje problema sa sustavima otvorenog koda. Također, koriste se i složeniji no općenitiji alati za praćenje tijeka dokumenata (workflow management tools). 5.2.3. Upravljanje verzijama Upravljanje verzijama je središnja podaktivnost unutar upravljanja konfiguracijom na koju se naslanjaju sve ostale podaktivnosti. Riječ je o evidentiranju i praćenju različitih verzija dijelova sustava te različitih verzija samog sustava. Upravljanje verzijama također omogućuje da više programera istovremeno mijenjaju isti softver a da pritom jedan drugom ne smetaju. Slika 5.6 ilustrira tipičnu situaciju gdje je potrebno pratiti više verzija sustava i njegovih dijelova. Slika također uvodi uobičajenu englesku terminologiju vezanu uz verzije sustava i dijelova. Codeline (A)

A

A1.1

Baseline – V1

A1.2

A1.3

B1.2

B1.3

Codeline (B)

B

B1.1

A

B1.2

C1.1

L1

L2

Ex1

Baseline – V2 Codeline (C)

C

C1.1

C1.2

C1.3

Biblioteke i vanjske komponente

L1

L2

Ex1

Ex2

A1.3

B1.2

C1.2

L1

L2

Ex2

Mainline

Slika 5.6: dijelovi sustava obuhvaćeni upravljanjem verzijama.

Niz verzija izvornog koda gdje su kasnije verzije izvedene iz prethodnih verzija naziva se codeline. Jedan codeline u pravilu odgovara jednom dijelu sustava (funkciji, klasi, modulu, komponenti, … ), što znači da za jedan te isti dio imamo više verzija. Skup verzija dijelova i pomoćnih biblioteka koje se mogu kombinirati u cjelovit sustav naziva se baseline. Jedan baseline dakle odgovara jednoj verziji sustava. Na slici se vidi da različiti baseline-i koriste različite verzije dijelova iz pojedinih codeline-a. Niz verzija sustava (dakle niz baseline-a) razvijenih iz nekog polaznog baseline-a naziva se mainline.


125

Robert Manger Baseline-i se dokumentiraju pomoću posebnog konfiguracijskog jezika. Riječ je o jeziku koji omogućuje da se za zadanu verziju sustava eksplicitno specificiraju uključeni dijelovi i verzije tih dijelova. Dokumentacija baseline-a je važna jer se pomoću nje naknadno može reproducirati neka starija verzija sustava koja je možda bila isporučena nekim specifičnim grupama korisnika. Upravljanje verzijama ostvaruje se uz pomoć posebnih alata koji se nazivaju version management tools ili version control systems. Najpoznatiji primjeri su CVS i Subversion [19, 20]. Alati za upravljanje verzijama obično imaju sljedeće mogućnosti.  Identifikacija verzija i izdanja. Svakoj verziji se prilikom njenog pohranjivanja u repozitorij alata pridružuje identifikator. Obično je riječ o imenu i brojevima. Na primjer, ButtonManager 1.3 znači treća verzija u codeline-u 1 za klasu ButtonManager. Neki alati dozvoljavaju i pridruživanje atributa verzijama te pretraživanje verzija po atributima.  Kompaktna pohrana. Da bi se uštedilo na prostoru, verzije istog dijela softvera koje se neznatno razlikuju pohranjuju se na kompaktan način. Umjesto da se čuva cjelovita kopija svake verzije, čuva se samo zadnja verzija te liste razlika (takozvane delte) između susjednih verzija. Primjenom tih razlika na zadnju verziju moguće je reproducirati bilo koju od starijih verzija. Ideja je ilustrirana na slici 5.7.  Bilježenje povijesti promjena. Bilježi se svaka promjena koju je netko napravio na nekom dijelu softvera. Te bilješke mogu služiti za pronalaženje određene verzije. Ili se za određeni dio softvera može ispisati povijest svih promjena.  Podrška za nezavisni razvoj. Više programera može istovremeno raditi nad istim dijelom softvera u isto vrijeme. Alat prati koji se dijelovi mijenjaju i osigurava da višestruke promjene neće smetati jedna drugoj.

Datum stvaranja Niz verzija Verzija 1.0

Verzija 1.1

Verzija 1.2

Verzija 1.3

D1

D2

D3

Izvorni tekst za V1.3

Način pohranjivanja

Slika 5.7: pohrana verzija pomoću delta. Stariji alati za upravljanje verzijama najviše su pažnje posvećivali kompaktnoj pohrani. Kod današnjih alata najvažnije je podržati nezavisni razvoj. Način na koji se omogućuje nesmetani istovremeni rad više programera prikazan je na slici 5.8. Kao što vidimo, alat za upravljanje verzijama sve verzije svih dijelova pohranjuje u zajednički repozitorij. Da bi izvršio neke promjene, programer mora „izvaditi“ (check-out) dijelove iz repozitorija i kopirati ih u svoj radni prostor. Nakon izvršenih promjena, programer „vraća“ (check-in) promijenjene dijelove iz svog radnog prostora u repozitorij. 126


Softversko inženjerstvo - skripta Radni prostor 2

Radni prostor 1

A

X

B

Y

Bob

Alice

C

C check_in

check_out

check_in

check_out

A1.1

B1.1

C1.1

Y

P

Q

A

B

C

Z

X

R

Sustav za upravljanje verzijama

Slika 5.8: rad s repozitorijem verzija dijelova softvera.

Slika 5.8. prikazuje konkretnu situaciju gdje dva programera Alice i Bob mijenjaju isti dio softvera C. Te istovremene promjene neće jedna drugoj smetati. Naime, prilikom vraćanja C-a u repozitorij, alat će ono što vraća Alice pretvoriti u novu verziju s novim identifikatorom, a ono što vraća Bob u još noviju verziju s još novijim identifikatorom. Tako će na kraju u repozitoriju postojati tri verzije za C (stara i dvije nove).

Codeline 2.1

V2.1.1

V2.1.2

Codeline 2

V2.0

V1.0

V1.1

V2.1 V2.2

V2.4

V2.3

V1.2

Codeline 1

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


127

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.

Ciljni sustav Izvršivi sustav

Razvojni sustav Razvojni alati

Ciljna platforma

Privatni radni prostor check_in check_out (co)

Sustav za upravljanje verzijama

co

Poslužitelj za gradnju

Upravljanje verzijama i gradnja

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

128


Softversko inženjerstvo - skripta Datoteke s izvornim kodom

Konfiguracijske datoteke

Izvršivi testovi

Datoteke s podacima

Automatizirani sustav za gradnju

Izvršivi ciljni sustav

Biblioteke

Prevoditelji i povezivači

Rezultati testova

Slika 5.11: rad alata za gradnju sustava. Od suvremenog alata za gradnju očekuje se da ima sljedeće osobine.  Rad sa skriptama za gradnju. Alat treba analizirati program koji se gradi, identificirati ovisnosti među dijelovima te koristiti ili čak automatski generirati skriptu za gradnju. Alat također treba podržati ručno stvaranje i editiranje skripte. Skriptni jezik trebao bi biti onaj isti konfiguracijski jezik koji je prije služio za opis baseline-a.  Suradnja s alatom za upravljanje verzijama. Alat za gradnju treba tražene verzije dijelova softvera izvaditi iz repozitorija alata za upravljanje verzijama.  Štedljivo prevođenje i povezivanje. Alat za gradnju treba prevesti sve dijelove sustava i povezati ih s bibliotekama u izvršivi program. Pritom treba izbjeći nepotrebna prevođenja dijelova koji se nisu mijenjali nakon zadnje gradnje.  Automatsko testiranje. Neki od alata za gradnju mogu automatski pokrenuti testove služeći se alatom za testiranje poput JUnit. Na taj način provjerava se je li sagrađeni program zaista ispravan ili je bio oštećen promjenama programskog koda.  Izvještavanje. Alat za gradnju treba stvoriti izvještaj o uspjehu ili neuspjehu postupka gradnje te o izvršenim testovima.  Stvaranje dokumentacije. Alat za gradnju mogao bi također biti u stanju automatski generirati release notes za izgrađeni program te stranice s uputama. Spomenuta mogućnost izbjegavanja nepotrebnog prevođenja zahtijeva ispravno uparivanje izvornih i object datoteka. Dakle alat treba biti u stanju odrediti da li za zadanu izvornu datoteku već postoji odgovarajuća (ažurna) object datoteka. Uparivanje se postiže tako da alat izvornim i object datotekama pridruži signature koje su u odgovarajućoj vezi. Pritom postoje dvije vrste signatura. 1. Vremenski žig (timestamp). Signatura bilo koje datoteke je datum i vrijeme njene zadnje promjene. Ako je izvorna datoteka mijenjana nakon stvaranja object datoteke, tada se ona mora ponovo prevesti, inače se object datoteka smatra ažurnom. Ovako je radio klasični make. 2. Kontrolni zbroj (checksum) za izvorni kod. Signatura za object datoteku računa se kao kontrolni zbroj koji uzima u obzir sve znakove iz izvorne datoteke. Smatra se da je object datoteka usklađena s izvornom ako je njena signatura jednaka ponovo izračunatom kontrolnom zbroju. Naime, bilo koja promjena izvornog koda izazvala bi promjenu kontrolnog zbroja. PMF – Matematički odsjek

129

Robert Manger Primijetimo da prva vrsta signature ne predviđa mogućnost da istovremeno postoji više verzija izvornih datoteka, to jest gradnja je moguća samo za zadnju verziju sustava. Druga vrsta signature podržava rad s više verzija izvornih datoteka i više verzija pripadnih object datoteka. Naime object datoteku uparujemo s odgovarajućom izvornom datotekom na osnovu podudaranja signature s kontrolnim zbrojem. 5.2.5. Upravljanje izdanjima Kod klasičnih metoda održavanja, mnoge od nastalih verzija sustava zapravo se ne isporučuju korisnicima budući da donose premalo promjena. Verzija koja se daje na uporabu korisnicima naziva se izdanje. Postoje dvije vrste izdanja. 1. Veliko izdanje (major release). Donosi značajnu novu funkcionalnost. Obično se naplaćuje korisnicima. 2. Malo izdanje (minor release). Popravlja greške iz prethodnog izdanja. Obično se šalje korisnicima kao update bez naplate. Upravljanje izdanjima uglavnom se sastoji od sljedećeg.  Donošenje odluke koja verzija sustava će se pretvoriti u veliko odnosno malo izdanje.  Priprema odabrane verzije za isporuku.  Isporuka pripremljenog izdanja korisnicima. Odluka o pretvaranju određene verzije sustava u izdanje važna je poslovna odluka. Nju donose menadžeri softverske kuće uzimajući u obzir sljedeće faktore.  Tehnička kvaliteta sustava. Ako u aktualnom izdanju postoje ozbiljne greške, potrebno je hitno objaviti novo ispravljeno izdanje.  Promjena u platformi. Ako se pojavilo novo izdanje operacijskog sustava, potrebno je i za aplikacijski sustav stvoriti novo prilagođeno izdanje.  Lehmanovi zakoni. Nakon izdanja s mnogo nove funkcionalnosti mora brzo slijediti izdanje koje popravlja greške i poboljšava performanse.  Držanje koraka s konkurencijom. Ako je konkurencija u svojem proizvodu uvela novu funkcionalnost, moramo našim korisnicima što prije ponuditi istu funkcionalnost.  Zahtjevi marketinga. Odjel marketinga može zahtijevati da se novo izdanje pojavi do određenog datuma, na primjer do Božića.  Korisnički zahtjevi. Kod sustava koji se rade po narudžbi, ako su korisnici postavili određene zahtjeve za promjenama i platili za njih, tada se novo izdanje s implementiranim promjenama mora isporučiti što prije.  Ritam izdavanja. Izdanja ne smiju biti ni prečesta ni prerijetka. Ako su prečesta, korisnici ih neće instalirati jer im to uzima vrijeme. Ako su prerijetka, korisnici bi mogli prijeći na konkurentske proizvode. Priprema izdanja za isporuku korisnicima sastoji se od opremanja samog softvera pratećim sadržajima te eventualnog snimanja na medije i pakiranja u kutije. Izdanje sustava nikad nije samo izvršivi program. Osim njega pojavljuju se sljedeći prateći sadržaji.  Konfiguracijske datoteke koje definiraju kao se dijelovi sustava trebaju instalirati na ciljanom hardveru ili operacijskom sustavu.  Datoteke s podacima, na primjer datoteka s porukama o greškama za odabrani jezik.  Program za instalaciju koji automatski instalira sustav na ciljanoj platformi.  Elektronička ili papirnata dokumentacija za korisnike koja opisuje rad sa sustavom.  Reklame i obavijesti o drugim proizvodima iste softverske kuće. 130



Novo izdanje sustava mora biti pripremljeno na dovoljno općenit način, tako da se može instalirati u svim predvidivim situacijama. Na primjer, zamislimo da imamo ovakav scenarij. 1. Prvo izdanje sustava bilo je distribuirano korisnicima i koristilo se neko vrijeme. 2. Drugo izdanje stvorilo je potrebu za instalacijom nove datoteke s podacima. 3. Treće izdanje zahtijeva datoteku instaliranu s drugim izdanjem. Tada postupak instalacije trećeg izdanja ne smije pretpostaviti da je datoteka s podacima već instalirana. Naime, neki korisnici možda su preskočili drugo izdanje te s prvog odmah prelaze na treće. Dakle, datoteka se mora ponovo distribuirati i instalirati s trećim izdanjem. Isporuka novog izdanja korisnicima izvodi se na razne načine ovisno o vrsti softvera i vrsti izdanja. Kompanije poput Microsoft, Adobe ili Apple velika izdanja svojih generičkih proizvoda prodaju u kutijama preko tradicionalnih trgovačkih kanala, a mala izdanja dostavljaju besplatno preko Interneta u obliku automatskih update-a. Isporuka specijaliziranih softverskih produkata teže se može automatizirati budući da su takvi produkti kod svakog korisnika konfigurirani na nešto drukčiji način.

5.3.

Baštinjeni softver i njegovo mijenjanje

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

131


Dugogodišnje održavanje pokvarilo je strukturu sustava, tako da ju je vrlo teško razumjeti. Izvorni kod pisan je s namjerom da se optimiziraju performanse ili smanje zahtjevi za memorijom, a ne s namjerom da kod bude razumljiv. To stvara poteškoće današnjim programerima koji su učili suvremene tehnike softverskog inženjerstva i nikad nisu vidjeli takav stil programiranja.

5.3.2. Softversko reinženjerstvo Cilj softverskog reinženjerstva je da se poboljša struktura sustava te da se ona dovede u oblik koji se može lakše razumjeti. Očekuje se da će se na taj način smanjiti cijena daljnjeg održavanja sustava. Razlika između „običnog“ softverskog inženjerstva i reinženjerstva vidi se na slici 5.12.

Specifikacija sustava

Oblikovanje i implementacija

Novi sustav

Postojeći sustav

Razumijevanje i transformacija

Bolje strukturirani i razumljiviji sustav

obično softversko inženjerstvo

softversko re-inženjerstvo

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



Originalni program

Dokumentacija programa

Modularizirani program

Reverzno inženjerstvo Modularizacija programa Prevođenje izvornog koda

Originalni podaci

Podatkovno re-inženjerstvo

Poboljšanje strukture programa Strukturirani program

Reorganizirani podaci

Slika 5.13: podaktivnosti unutar softverskog reinženjerstva. Kao primjer poboljšanja strukture programa pogledajmo sliku 5.14. Riječ je o nestrukturiranoj verziji kontrolera sustava za grijanje. Kod je gotovo nemoguće razumjeti zbog brojnih goto naredbi – to je takozvana „špageti logika“. Nakon reinženjerskog zahvata, dobili smo znatno razumljiviju verziju sa slike 5.15. Ovakav zahvat moguće je obaviti uz pomoć automatskog alata, koji najprije konstruira dijagram toka kontrole originalne „goto“ verzije, a zatim realizira taj dijagram uz pomoć if i while naredbi.

Start: Get (Time-on, Time-off, Time, Setting, Temp, Switch) if Switch = off goto off if Switch = on goto on goto Cntrld off: if Heating-status = on goto Sw-off goto loop on: if Heating-status = off goto Sw-on goto loop Cntrld: if Time = Time-on goto on if Time = Time-off goto off if Time < Time-on goto Start if Time > Time-off goto Start if Temp > Setting goto off if Temp < Setting goto on Sw-off: Heating-status := off goto Switch Sw-on: Heating-status := on Switch: Switch-heating Loop: goto Start

Slika 5.14: program sa „špageti“ logikom. PMF – Matematički odsjek

133

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

Slika 5.15: strukturirani program.

Program 1

Datoteka 1

Datoteka 2

Program 4

Program 3

Program 2

Datoteka 3

Program 5

Datoteka 4

Datoteka 5

Program 6

Datoteka 6

Program 7

postaje

Program 3

Program 2

Program 1

Program 4

Program 5

Program 6

Sustav za upravljanje bazom podataka

Slika 5.16: migracija podataka.

134


Program 7 Logički i fizički modeli podataka

Softversko inženjerstvo - skripta Slika 5.16 ilustrira ideju o zamjeni datoteka sa zajedničkom bazom podataka. Programi u polaznom sustavu koristili su klasične datoteke u kojima je postojala redundancija i nekonzistentnost, i od kojih je svaka bila optimizirana za jednu aplikaciju a nepogodna za druge. Nakon reinženjerskog zahvata imamo integriranu i konzistentnu bazu podataka koja osim postojećih aplikacija može podjednako dobro podržati i razne buduće aplikacije. Za ovakav zahvat potrebno je stvoriti logički model podataka, prepraviti sve programe tako da pristupaju bazi umjesto datotekama te prebaciti podatke iz datoteka u bazu. Softversko reinženjerstvo ima svoja ograničenja. Na primjer, sustav razvijen funkcionalnim pristupom nije moguće pretvoriti u objektni sustav. Nakon reinženjerstva softver je pogodniji za održavanje, no ipak se ne može tako dobro održavati kao novi softver. Podatkovno reinženjerstvo može biti izuzetno skupo. Menadžment treba procijeniti da li se reinženjerstvo uopće isplati, ili je bolje krenuti u razvoj sasvim novog sustava. 5.3.3. Arhitekturna transformacija Nakon reinženjerstva, baštinjeni softver obično se podvrgava arhitekturnoj transformaciji te se na taj način nastoji prilagoditi suvremenim tehnologijama. Tipični baštinjeni sustav je centralizirani sustav za rad na mainframe računalu i tekstualnim terminalima, prikazan na slici 5.17.

(terminali)

Baštinjeni sustav

(mainframe)

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.


135

Robert Manger (osobna računala na kojima radi korisničko sučelje i možda još neki dijelovi baštinjenog sustava) (mreža) Jezgra baštinjenog sustava

(mrežni poslužitelj)

Slika 5.18: transformirana arhitektura baštinjenog sustava. Kod planiranja arhitekturne transformacije, korisno je zamišljati da se naš polazni baštinjeni sustav sastoji od slojeva, kao što je prikazano na slici 5.19. Pojedini slojevi obavljaju sljedeće zadaće.  Prezentacijski sloj bavi se prikazom i organizacijom formulara za unos ili prikaz podataka.  Sloj za validaciju podataka provjerava ispravnost podataka koje korisnik unosi u formular.  Sloj za kontrolu interakcije upravlja redoslijedom korisnikovih operacija te redoslijedom formulara koji se prikazuju korisniku.  Sloj s aplikacijskim servisima obavlja obradu podataka i računanje.  Sloj s bazom podataka omogućuje pristup podacima koji su pohranjeni u bazi.

Prezentacija Validacija podataka

» korisničko sučelje

Kontrola interakcije Aplikacijski servisi Baza podataka

Slika 5.19: slojevi unutar baštinjenog sustava. Postoje razni načini distribuiranja sustava, koji se razlikuju po načinu kako su slojevi raspoređeni između poslužitelja i klijenata. Spektar mogućnosti ilustriran je slikom 5.20. Slojevi koji su prebačeni na klijenta u pravilu se moraju mijenjati jer u protivnom nećemo moći iskoristiti prednosti grafičkog sučelja. Zato distribucije gdje je sve veći broj slojeva prebačen na klijenta postaju sve skuplje. Najjeftinije rješenje prebacuje samo prezentaciju na klijenta, no time ne dobivamo mnogo jer se klijent tada ponaša kao emulator terminala, pa sučelje i dalje slijedi logiku tekstualnih formulara. Najskuplje rješenje je da se sve osim baze prebaci na klijenta - tada se poslužitelj svodi na poslužitelja baze podataka i možda se može zamijeniti komercijalnim DBMS-om, čime bi se cijeli baštinjeni sustav izbacio iz 136


Softversko inženjerstvo - skripta uporabe. Srednje rješenje je da na klijentu budu prezentacija, validacija i kontrola interakcije ta tri sloja zajedno mogu se na najbolji način zamijeniti novim grafičkim sučeljem koje više neće slijediti logiku tekstualnih formulara.

Klijent: prezentacija 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.

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

(mreža)

Wrapper (middleware)

Baštinjeni sustav

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

(mrežni poslužitelj)

Slika 5.21: transformirana arhitektura baštinjenog sustava s wrapper-om.


137

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.

138



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

6.1.

Općenito o ponovnoj upotrebi

U ovom potpoglavlju nabrojat ćemo razne tehnike koje su se s više ili manje uspjeha koristile kao način ponovne upotrebe softvera. Također ćemo uočiti neka bitna svojstva po kojima se te tehnike razlikuju. Raspravljat ćemo i o kriterijima za izbor pogodne tehnike ovisno o konkretnoj situaciji. 6.1.1. Svojstva i oblici ponovne upotrebe U posljednjih 30-ak godina razvijene su brojne metode i tehnike za ponovnu upotrebu. One se razlikuju po mnogim svojim svojstvima, na primjer po veličini dijelova softvera koji se ponovno upotrebljavaju, ili po samoj prirodi onoga što se upotrebljava. S obzirom na veličinu dijelova, razlikujemo tri vrste ponovne upotrebe. 1. Ponovna upotreba cijelog sustava. Postojeći sustav se nakon odgovarajuće konfiguracije i prilagodbe daje na uporabu novim korisnicima. Ili se ugradnjom manjih promjena stvara nova verzija postojećeg sustava koja je prilagođena potrebama novih korisnika. 2. Ponovna upotreba dijela sustava. Dio postojećeg sustava srednje veličine ugrađuje se u novi sustav. Također može biti riječ o upotrebi komponente koja je bila razvijena zato da bi se ponovno upotrebljavala, ili o korištenju web servisa opće namjene. 3. Ponovna upotreba funkcije ili klase. Manji dio postojećeg sustava, na primjer jedna funkcija ili klasa, ugrađuje se u novi sustav. Također može biti riječ o korištenju funkcije ili klase iz biblioteke opće namjene, na primjer iz biblioteke matematičkih funkcija. PMF – Matematički odsjek

139

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



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

6.2.

Neki tradicionalni oblici ponovne upotrebe

U ovom potpoglavlju opisujemo oblike ponovne upotrebe softvera koji se koriste već nekoliko desetljeća. Riječ je o aplikacijskim okvirima, produktnim linijama, odnosno upotrebi COTS produkata. Svaki od ovih oblika obrađen je u posebnom odjeljku. 6.2.1. Aplikacijski okviri Rani pobornici objektno-orijentiranog pristupa vjerovali su da je glavna prednost objekata u tome što se oni lagano mogu ponovno upotrijebiti. Ipak, vrijeme je pokazalo da su pojedine klase premale i suviše specijalizirane cjeline da bi omogućavale efikasnu ponovnu upotrebu. Danas prevladava mišljenje da objektno-orijentirana ponovna upotreba postaje zaista isplativa tek onda kad koristimo glomaznije strukture za ponovnu upotrebu. Takve strukture zovu se aplikacijski okviri (application frameworks). PMF – Matematički odsjek

141

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

GUI

Petlja događaja Callback

Klase koje su specifične za aplikaciju

Callback Baza podataka

Callback

Petlja događaja

Platforma

Petlja događaja

Slika 6.1: inverzija kontrole u okvirima.

142


Softversko inženjerstvo - skripta Makar je aplikacijski okvir dostupan u obliku izvornog programskog koda, programer koji ga koristi u pravilu ne mijenja taj kod. Umjesto toga programer radi nešto od sljedećeg.  On dodaje konkretne klase koje nasljeđuju apstraktne klase iz okvira.  On piše glavni program koji na osnovu zadanih klasa najprije stvara sve potrebne objekte, a zatim upravlja izvođenjem cijele aplikacije.  On definira takozvane callback–ove: to su metode koje se automatski pozivaju kao odgovor na događaje koje okvir prepoznaje. Na primjer, ako koristimo okvir za grafičko korisničko sučelje, tada sam okvir već definira klase koje odgovaraju elementima korisničkog sučelja, dakle prozorima, gumbima, izbornicima i tako dalje. Naš posao je da napišemo program koji će stvoriti objekte iz tih klasa i time sastaviti konkretno sučelje za našu aplikaciju. Također, naš posao je da napišemo callback–ove koji će se aktivirati onda kad korisnik klikne mišem na određeni gumb ili onda kad korisnik odabere određenu stavku s određenog izbornika. Dakle, naš posao je da okviru dodamo funkcionalnost koja je specifična za našu aplikaciju. To je ilustrirano na slici 6.1. 6.2.2. Produktne linije Produktna linija ili porodica aplikacija je skup srodnih aplikacija koje je u pravilu razvila ista softverska kuća i koje imaju zajedničku arhitekturu. Svaki član porodice je specijaliziran u nekom smislu. Zajednička jezgra svih članova ponovo se upotrebljava svaki put kad se pojavi potreba za novim članom. Razvoj novog člana sastoji se od pisanja dodatnih dijelova ili od prepravljanja postojećih dijelova u nekoj od starih aplikacija. Postoji nekoliko tipova specijalizacije jedne aplikacije unutar produktne linije.  Platformska specijalizacija. Razne verzije u biti iste aplikacije razvijaju se za različite platforme (na primjer Microsoft Windows, Linux, i tako dalje). Funkcionalnost u svim verzijama je ista, a promijenjeni su oni dijelovi koji komuniciraju s hardverom i operacijskim sustavom.  Konfiguracijska specijalizacija. Razne verzije aplikacije stvaraju se zato da bi rukovale s različitim vanjskim uređajima. Na primjer, sustav za dojavljivanje požara postoji u više verzija ovisno o tipu radio sustava. Funkcionalnost verzija varira s obzirom na drukčiju funkcionalnost vanjskih uređaja.  Funkcionalna specijalizacija. Razne verzije aplikacije stvaraju se za kupce s različitim zahtjevima. Na primjer, informacijski sustav knjižnice modificira se za gradsku, odnosno školsku, odnosno znanstvenu knjižnicu. Moguće je da će neki dijelovi biti promijenjeni te da će znanstvena knjižnica imati dodatne dijelove koji se odnose na znanstvene časopise. Kao primjer ponovne upotrebe softvera korištenjem produktne linije pogledajmo arhitekturu sustava za upravljanje inventarom na slici 6.2. Riječ je o slojevitoj arhitekturi. Prati se raspored nekih komada opreme unutar neke organizacije. Ukoliko je riječ o elektrani i njezinim generatorima i transformatorima, tada oprema u pravilu ne mijenja svoju lokaciju. Ukoliko isti sustav koristimo za praćenje opreme na fakultetu, morat ćemo dodati modul za premještanje na primjer računala iz jednog laboratorija u drugi, pa ćemo na taj način dobiti novog člana produktne linije. Slika 6.3 prikazuje značajnije promijenjenu verziju polazne aplikacije koja ovaj put služi za raspoređivanje vatrogasnih vozila ili vozila hitne pomoći; dodani su specifični moduli za planiranje rute vozila, za rad s kartama, za sučelje prema komunikacijskom sustavu, i tako dalje. Baza podataka je podijeljena u tri dijela koji se odnose na vozila, drugu opremu i karte. PMF – Matematički odsjek

143

Robert Manger

Interakcija Korisničko sučelje

Upravljanje ulazom i izlazom Autentikacija korisnika

Upravljanje upitima

Izvještavanje

Upravljanje inventarom Upravljanje pravilima za rad s inventarom

Praćenje inventara

Raspoređivanje inventara

Upravljanje bazom podataka Upravljanje transakcijama

Baza podataka o inventaru

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

Interakcija Sučelje za komunikacijski sustav

Sučelje za operatora

Upravljanje ulazom i izlazom Autentikacija Upravljanje Generator kartama i operatora planiranje ruta izvještaja

Upravljanje upitima

Upravljanje inventarom Praćenje Bilježenje Raspo- Upravljanje Lociranje statusa incidenata ređivanje opremom vozila u vozilima vozila vozila Upravljanje bazom podataka Upravljanje transakcijama

Baza podataka o 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. 144



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 je. 6.2.3. Upotreba COTS produkata Kratica COTS znači commercial off-the-shelf. COTS produkt je javno dostupni softverski sustav koje se može kupiti u dućanu ili dobiti besplatno i koji se može prilagoditi potrebama raznih korisnika bez da se mijenja njegov izvorni programski kod. Primjeri COTS produkata su: Microsoft Word ili Excel, WRI Mathematica, ERP sustavi poput SAP, DBMS-i poput Oracle ili MySQL. PMF – Matematički odsjek

145

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.

Nabava sirovina

Upravljanje proizvodnjom

Isporuka proizvoda

Upravljanje odnosima s kupcima

Procesi

Procesi

Procesi

Procesi

Poslovna pravila

Baza podataka

Slika 6.5: arhitektura ERP sustava. 146



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

Web preglednik

E-mail klijent

Poslužitelj

E-commerce sustav

Adapter

Sustav ureda za nabavu

E-mail sustav

Adapter

Slika 6.6: sustav za objedinjenu nabavu realiziran integracijom COTS produkata. Da bi se stvorio novi sustav, baštinjeni sustav se integrira s web aplikacijom za e-commerce te s e-mail sustavom koji će omogućiti komunikaciju sa zaposlenicima. Struktura konačnog sustava za nabavu ilustrirana je slikom 6.6. Vidimo da se nekoliko COTS produkata integrira s baštinjenim sustavom preko adaptera.

6.3.

Razvoj softvera zasnovan na komponentama

U ovom potpoglavlju bavimo se danas aktualnom i po svemu sudeći vrlo efikasnom tehnikom ponovne upotrebe koja se zasniva na takozvanim komponentama. Najprije govorimo općenito o komponentama i njihovom korištenju. Zatim opisujemo dva razvojna procesa koji su vezani uz komponente: prvi se odnosi na razvoj samih komponenti koje će se ponovo upotrebljavati, a drugi na razvoj novih aplikacija uz upotrebu komponenti. Na kraju proučavamo postupke međusobnog spajanja komponenti u svrhu izgradnje složenijih podsustava odnosno cijelih sustava.


147

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

148


Softversko inženjerstvo - skripta Traženo sučelje

Ponuđeno sučelje Print GetQueue

GetPDfile PrintService

Remove Transfer

PrinterInt

Register Unregister

Slika 6.7: komponenta koja upravlja štampanjem dokumenata na nekoliko štampača.

Slika 6.7 ujedno predstavlja i jednostavni primjer UML component dijagrama. Takvi dijagrami služe za prikaz građe sustava sastavljenog od komponenti. Vidimo da se po UMLovim pravilima komponenta crta kao pravokutnik s odgovarajućom ikonom. Ponuđeno sučelje obično se crta kao niz „utikača“, a traženo sučelje kao niz „utičnica“. Na složenijim component dijagramima pojavljuje se više komponenti. Situacija kad jedna komponenta daje uslugu a druga je prima crta se tako da odgovarajući utikač prve komponente bude utaknut u odgovarajuću utičnicu druge komponente. Primjeri takvih složenijih dijagrama pojavit će se na slikama 6.12 – 6.17. Iz svega što smo do sada rekli, jasno je da korištenje komponenti donosi bitne promjene u načinu kako se softver oblikuje, implementira i kasnije pokreće. Da bi neki sustav uspješno realizirali pomoću komponenti, nužno je da su ispunjeni sljedeći uvjeti.  Sam sustav mora biti oblikovan kao skup komponenti koje međusobno komuniciraju, dakle njegova građa treba biti prikazana pomoću UML component dijagrama.  Moramo imati dostupne odgovarajuće komponente koje imaju traženu funkcionalnost i koje se mogu instalirati na naša računala.  Sve odabrane komponente moraju biti kompatibilne u smislu da se pokoravaju istom modelu, dakle mogu raditi pod kontrolom istog middleware-a.  Na našim računalima moramo imati instaliran middleware koji implementira taj odabrani model i koji je u stanju integrirati sve odabrane komponente u cjelinu. Vidimo da nam za rad s komponentama treba posebna softverska podrška, takozvani middleware. Riječ je o istoj vrsti softvera koju smo već spominjali u odjeljku 3.4.3 kad smo govorili o arhitekturi s distribuiranim objektima. Zaista, osim što služe za ponovnu upotrebu, komponente se mogu promatrati i ako sredstvo za izgradnju distribuiranih sustava. Ideja o komponentama zapravo je proširenje ideje o distribuiranim objektima. Kao konkretan primjer middleware-a mogli bismo navesti bilo koji alat koji implementira otvoreni standard CORBA. No danas se mnogo više koriste „proprietary” softveri poput Microsoftovog .NET ili Sunovog Enterprise Java Beans. Rekli smo da je osnovna zadaća middleware-a da omogući međusobnu komunikaciju komponenti, bez obzira nalaze li se one na istom ili na različitim računalima. No današnji middleware-i obično omogućuju i više od toga. Slika 6.8 prikazuje uobičajene usluge koje middleware pruža.


149

Robert Manger Servisi za podršku Upravljanje komponentama

Upravljanje transakcijama

Upravljanje resursima

Istovremeni rad

Perzistentnost

Sigurnost

Platformski servisi Adresiranje

Definicija sučelja

Upravljanje iznimkama

Komunikacija komponenti

Slika 6.8: usluge koje pruža middleware. U donjem dijelu slike 6.8 nalaze se obavezne usluge koje se tiču interoperabilnosti komponenti u distribuiranoj okolini. Gornji dio slike navodi dodatne usluge koje mogu biti od koristi komponentama i koje olakšavaju razvoj aplikacija. Na primjer, mnogi middleware-i pružaju usluge vezane uz sigurnost. Ako neka komponenta zahtijeva autentikaciju korisnika, ona ne mora sama implementirati postupak autentikacije, već se može osloniti na mehanizam iz middleware-a. 6.3.2. Softverski procesi zasnovani na komponentama Pojavom komponenti nastala je posebna vrsta softverskog inženjerstva, takozvano softversko inženjerstvo zasnovano na komponentama (component based software engineering – CBSE). Unutar CBSE pojavljuje se nekoliko specifičnih procesa koji su prikazani na slici 6.9. CBSE za ponovnu upotrebu

CBSE uz ponovnu upotrebu

Nabava komponenti

Certificiranje komponenti

Upravljanje komponentama

Repozitorij komponenti

Slika 6.9: procesi unutar CBSE. 150


Vanjski izvor


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

151

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 komponentekandidate


Opet identificiraj komponentekandidate

Prilagodi zahtjeve u skladu s otkrivenim komponentama

Komponiraj komponente i tako stvori sustav

Slika 6.10: razvoj softvera uz ponovnu upotrebu komponenti. Neke od aktivnosti na slici 6.10, na primjer polazno otkrivanje korisničkih zahtjeva, odvijaju se na uobičajeni način. No uočavamo da na slici 6.10 u odnosu na konvencionalne softverske procese postoje sljedeće razlike. 1. Od korisnika se traži da budu što fleksibilniji kod definiranja zahtjeva, Naime, zahtjevi koji su jako specifični ograničavaju broj komponenti koje ih mogu zadovoljiti. 2. Zahtjevi se razrađuju i modificiraju u skladu s raspoloživim komponentama, Korisnici će rado pristati na kompromise ukoliko to povlači jeftiniju i bržu isporuku sustava.

152


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

Pretraživanje 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 koja je osnovna poteškoća kod validacije komponenti. Poteškoća je u tome što je komponenta bila razvijena unutar jedne okoline, a pokušava se upotrijebiti unutar drukčije okoline. Pretpostavke polazne okoline obično nisu u potpunosti dokumentirane, tako da je teško provjeriti da li one vrijede i u novoj okolini.


153

Robert Manger 6.3.3. Kompozicija komponenti Kompozicija je proces integriranja komponenti, ili međusobno ili s posebnim dijelovima „koda za lijepljenje“ – takozvanim adapterima. Na taj način stvara se nova složenija komponenta ili cijeli sustav. Postoji više načina komponiranja i oni su prikazani na slikama 6.12, 6.13 i 6.14.  Sekvencijalna kompozicija vidi se na slici 6.12. Iz dvije postojeće komponente A i B stvaramo novu komponentu tako da A i B zovemo jednu za drugom. Dakle poziva se usluga ponuđena od A, pa se rezultati vraćeni od A koriste kao parametri u pozivu usluge koju nudi B. Primijetimo da A i B ne zovu jedna drugu. Umjesto toga, potreban je adapter koji poziva usluge u ispravnom redoslijedu i osigurava da se rezultati od A pretvaraju u oblik koji je kompatibilan s ulazima koje očekuje B.  Hijerarhijska kompozicija vidi se na slici 6.13. Komponenta A neposredno poziva uslugu koju nudi komponenta B. To znači da ponuđeno sučelje od B mora u potpunosti biti kompatibilno (ustvari jednako) s traženim sučeljem od A. No ako postoji neka manja nekompatibilnost, ona se može riješiti posredstvom dodatno napisanog adaptera koji se umeće između A i B.  Aditivna kompozicija vidi se na slici 6.14. Komponente A i B spojene su u novu komponentu koja kombinira njihovu funkcionalnost. Ponuđeno odnosno traženo sučelje nove komponente je kombinacija odgovarajućih sučelja od A i B. Potrebna su dva adaptera koja služe kao vanjsko ponuđeno odnosno traženo sučelje nove komponente i koji koordiniraju pozive usluga. Pritom A i B ne ovise jedna o drugoj i ne pozivaju se međusobno.

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


Softversko inženjerstvo - skripta 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.


155

Robert Manger

string location (string pn) phoneDatabase (string command)

string owner (string pn)

addressFinder string propertyType (string pn)

displayMap (string streetName, string streetNo, int scale) mapDB (string command)

mapper

printMap (string streetName, string streetNo, int scale)

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

address = addressFinder.location(phonenumber); streetname = addressStripper.getStreetName(address); streetNo = addressStripper.getStreetNo(address); mapper.displayMap(streetName, streetNo, 10000); Slika 6.16: skica programskog koda za adapter koji će povezati komponente sa slike 6.15.

156


Softversko inženjerstvo - skripta Kao drugi primjer korištenja adaptera promatrajmo sliku 6.17. Riječ je o dijelu mogućeg rješenja za softver meteorološke stanice koju smo proučavali u odjeljku 3.3.3. Komponenta DataCollector ugrađuje se u meteorološku stanicu. Ona upravlja skupom senzora ugrađenih u stanicu (termometri, anemometri, barometri, ...) te skuplja i objedinjuje podatke koji stižu s tih senzora. Ponuđeno sučelje od DataCollector omogućuje korisniku da na posredan način pokrene ili zaustavi određeni senzor ili da dobije skupljene podatke od svih senzora. Traženo sučelje od DataCollector služi za njegovo povezivanje sa samim senzorima i sastoji se od dijela za upravljanje senzorom i dijela za očitavanje vrijednosti sa senzora. Komponenta Sensor na slici 6.17 predstavlja jedan od senzora – njegovo ponuđeno sučelje sastoji se operacija za pokretanje i zaustavljanje senzora te operacije za očitavanje vrijednosti.

addSensor removeSensor start

Sensor

sensorManagement

startSensor stopSensor

stop

Data Collector

Adapter getData sensorData

testSensor initialize report listAll

Slika 6.17: primjer hijerarhijskog povezivanja komponenti preko adaptera. Problem kod arhitekture na slici 6.17 je u tome što je DataCollector jedan, a Sensor-a ima mnogo. Svaki senzor ima malo drukčije ponuđeno sučelje, pa nije moguće traženo sučelje od DataCollector ujednačiti s ponuđenim sučeljima svih senzora. Rješenje problema postiže se primjenom adaptera koji posreduje između DataCollector-a i svakog pojedinog Sensor-a. Tražemo sučelje od DataCollector je generičko. Obje operacije iz tog sučelje koriste tekstualni parametar koji se interpretira kao naredba senzoru. Na primjer, da bi očitao vrijednost sa senzora, DataCollector generira poziv SensorData(˝collect˝), a da bi zaustavio senzor, DataCollector poziva SensorManagement(˝stop˝). S druge strane, konkretni senzor prikazan na slici 6.17 ne razumije ovakve naredbe jer se njegovo ponuđeno sučelje sastoji od besparametarskih operacija start(), stop() i getData(). No tu sad uskače adapter. Na primjer, kad adapter primi poziv SensorData(˝collect˝), on „parsira“ parametar s kojim je operacija pozvana i kad u njemu otklrije riječ ˝collect˝ on dalje senzoru upućuje poziv getData(), a dobivenu vrijednost prosljeđuje DataCollector-u kao odgovor na poziv SensorData(). Sličan postupak primjenjuje se i kod poziva SensorManagement(˝stop˝). Primijetimo da je situacija sa slike 6.17 primjer hijerarhijske kompozicije potpomognute adapterom. Kompozicija komponenti nije jednoznačan proces. Sustav sa traženom funkcionalnošću obično se može sastaviti na razne načine. U odabiru najpogodnije kompozicije trebamo se rukovoditi sljedećim pitanjima.


157

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 Management

Data Collection

Data Base

Report Generator

Report

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



6.4.

Razvoj aplikacija pomoću web servisa

U ovom potpoglavlju bavimo se još jednom aktualnom tehnikom ponovne upotrebe. Ona se zasniva na takozvanim web servisima. Riječ je o tehnici koja u konceptualnom pogledu ima sličnosti s razvojem zasnovanim na komponentama, no bitno se razlikuje u pogledu tehničke realizacije. U prvom odjeljku govorimo općenito o web servisima kao temelju nove arhitekture distribuiranih sustava. Drugi odjeljak nabraja standardne jezike i protokole koji omogućuju njihovu upotrebu. Treći odjeljak objašnjava zašto se oni mogu shvatiti kao oblik ponovne upotrebe te koje su sličnosti i razlike u odnosu na komponente. U četvrtom odjeljku proučavamo softverske procese koji su vezani uz web servise, dakle proces njihovog razvoja odnosno proces razvoja aplikacija koje ih koriste. 6.4.1. Web servisi kao temelj nove distribuirane arhitekture Pojava weba u 1990-im godinama donijela je revoluciju u mogućnostima razmjene podataka preko Interneta. No podaci i usluge s weba isprva su bili dostupni samo web preglednicima. Web servisi [22] predstavljaju nadogradnju klasične web tehnologije. Njime sadržaji s weba postaju dostupni i drugim programima. Točnije rečeno, web servis je resurs na webu, koji je prikazan na standardizirani način, i koji se može koristiti iz nekog drugog programa. To može biti podatkovni resurs, kao na primjer katalog proizvoda, ili računalni resurs, na primjer pretvarač slika iz jednog grafičkog formata u drugi, ili kombinacija jednog i drugog. Web servisi omogućuju novu vrstu arhitekture distribuiranih sustava koja se naziva arhitektura usmjerena na servise (Service Oriented Architecture – SOA) [23]. Prema SOA, aplikacija se gradi povezivanjem samostalnih servisa koji su dostupni na Internetu i izvršavaju se na geografski udaljenim računalima. Ideja SOA ilustrirana je na slici 6.19. Dobavljači usluga oblikuju i implementiraju servise te definiraju sučelja preko kojih se pristupa tim servisima. Također, oni objavljuju informacije o svojim servisima u nekom registru. Tražitelji usluga otkrivaju u registru specifikacije servisa koji ih zanimaju i lociraju dobavljače usluga. Nakon toga oni mogu povezati svoju aplikaciju s odabranim servisom i komunicirati s njime preko njegovog sučelja razmjenom poruka u skladu s predviđenim protokolom. Ovisno o modelu poslovanja, dobavljači svoje servise mogu učiniti dostupnima cijelom svijetu ili samo pripadnicima neke kompanije, a svoje usluge mogu naplaćivati ili davati besplatno.

Registar servisa otkrivanje

Tražitelj usluga

objavljivanje

povezivanje (SOAP)

Dobavljač usluga

Servis (WSDL)

Slika 6.19: arhitektura usmjerena na servise - SOA. PMF – Matematički odsjek

159

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.

160


Softversko inženjerstvo - skripta Informacije o prometu na cesti

Druge info

Info o vremenu

GPS koord

GPS koord

Lociranje ceste

Info o prometu

GPS koord

Prevoditelj Jezik, Informacije Prevedene Informacije

Mobilni info servis

Otkrivanje servisa

Objedinjuje informacije

Pronalazi dostupne servise

Naredba, Jezik, GPS koord

Primanje podataka

Slanje podataka

Prima informacije iz vanjskog servisa

Šalje GPS koordinate i zahtjev za informacijama vanjskom servisu

Radio

Lociranje

Pretvara digitalne informacije u radio signal

Otkriva GPS koordinate automobila

Korisničko sučelje Prima zahtjev od korisnika

Softverski sustav unutar automobila

Slika 6.20: informacijski sustav u automobilu zasnovan na web servisima.

6.4.2. Standardi vezani uz web servise Razvoj tehnologije web servisa bio je popraćen razvojem odgovarajućih standarda. Sve važne kompanije prihvatile su te standarde, pa su time osigurale kompatibilnost svojih rješenja. Na slici 6.21 prikazani su jezici i protokoli koji su od ključne važnosti za funkcioniranje web servisa. Svi oni zasnivaju se na XML-u. Kao što vidimo, riječ je o sljedećem. PMF – Matematički odsjek

161

Robert Manger 1. Service Oriented Architecture Protocol – SOAP. To je protokol za razmjenu poruka između web servisa. Definiraju se obavezni i opcionalni dijelovi poruka. 2. Web Service Definition language – WSDL. To je jezik za opisivanje sučelja web servisa. Omogućuje zadavanje imena operacija koje servis nudi, parametara i njihovih tipova, iznimki, adrese na webu gdje se servis nalazi te načina na koji se aplikacija treba povezati sa servisom. 3. Web Service – Business Process Execution Language – WS-BPEL. To je jezik za pisanje aplikacije koja poziva web servise i kombinira njihove ulaze i izlaze.

XML tehnologije (XML, XSD, XSLT, ...) Podrška (WS-Security, WS Addressing, ...) Proces (WS-BPEL) Definicija servisa (UDDI, WSDL) Razmjena poruka (SOAP)

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

Slika 6.21: standardi za web servise. Na slici 6.21 vidimo također da tehnologija web servisa predstavlja nadogradnju web tehnologije. Zaista, kao transportni protokol ispod SOAP-a u pravilu se koristi HTTP, a sam HTTP radi na vrhu stoga protokola TCP/IP. To znači da se komunikacija aplikacije i web servisa odvija posredstvom web poslužitelja. U nastavku ćemo reći nešto više o WSDL-u. Rekli smo da jedan dokument u WSDL-u služi kao opis sučelja jednog web servisa. Struktura takvog dokumenta prikazana je na slici 6.22. Nakon uvodnog dijela koji sadrži XML-ove deklaracije prostora imena (namespace), slijede dijelovi u kojima se definiraju tri stvari o web servisu: što on radi, kako on komunicira te gdje se on može naći. Odgovor na pitanje „što“ svodi se na opis operacija, parametara, tipova podataka, poruka i iznimki. Odgovor na „kako“, takozvani binding, specificira protokol za komunikaciju sa servisom - u pravilu to je SOAP no može se odabrati i neki drugi. Odgovor na „gdje“ određuje adresu na webu gdje je servis instaliran, dakle njegov Uniform Resource Identifier – URI. Zanimljivo je napomenuti da se uz spomenuta tri standarda SOAP, WSDL i WS-BPEL prije desetak godina predlagao i još jedan: 4. Universal Description, Discovery and Integration – UDDI. To je standard koji propisuje način na koji se servis treba dokumentirati tako da bi ga tražitelji usluga lako mogli naći. 162



WSDL definicija servisa Uvod

XML deklaracije za prostore imena

Apstraktno sučelje

Konkretna implementacija

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 [24]. 6.4.3. Usporedba web servisa i komponenti Web servisi očito predstavljaju jedan oblik ponovne upotrebe softvera. Zaista, kad veći broj aplikacija koristi isti servis, tada se ista implementacija dotične usluge upotrebljava mnogo puta. Štoviše, stječe se dojam da je riječ o vrlo djelotvornoj tehnici ponovne upotrebe. Naime, kad razvijamo aplikaciju, tada nam u pravilu stoji na raspolaganju obilje servisa diljem Interneta, pa je za očekivati da ćemo za svaku uslugu koja nam treba uspjeti pronaći odgovarajuću implementaciju. Web servisi su po mnogim karakteristikama usporedivi s komponentama o kojima smo govorili u potpoglavlju 6.3. Neki autori smatraju da je ustvari riječ o dvije inačice u osnovi istog pristupa. Mi ipak posebno obrađujemo svaku od tehnika, a u nastavku ovog odjeljka nabrojat ćemo njihove sličnosti i razlike. Sličnosti između komponenti i web servisa su sljedeće.  Obje tvorevine zasnivaju se na konceptu pružanja usluga.  Obe tvorevine koristimo preko (ponuđenog) sučelja koje se sastoje od operacija s parametrima. PMF – Matematički odsjek

163


U oba slučaja aplikaciju gradimo na sličan način, dakle kombiniranjem raspoloživih usluga, pretvorbom rezultata jedne usluge u ulaz za drugu uslugu, i tako dalje. Obje tehnike nagovještavaju nastanak nove softverske industrije, koja bi se umjesto razvojem aplikacija bavila isključivo razvojem ponovno upotrebljivih dijelova za aplikacije. Obje tehnike nastoje biti neovisne o programskom jeziku, to jest ne bi trebalo biti važno u kojem jeziku su razvijeni ponovno upotrebljivi dijelovi, a u kojem jeziku sama aplikacija.



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


Softversko inženjerstvo - skripta 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 servis

Specifikacija 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čelja zapisan u jeziku WSDL. Specifičnost oblikovanja sučelja web servisa je pisanje teksta u WSDL-u. WSDL je prilično složen jezik zasnovan na XML-u, a specifikacije u njemu obično su dugačke i detaljne. Zato se kod u WSDL-u obično ne piše ručno već se dobiva automatski primjenom posebnih alata, na primjer iz UML dijagrama koji prikazuje sučelje kao klase ili iz ekvivalentnog Java koda. Primjer opisa sučelja u WSDL-u vidi se na slici 6.24. Riječ je o sučelju za servis koji za zadani datum i ime grada vraća maksimalnu i minimalnu temperaturu na taj datum u tom gradu. Prikazan je samo dio teksta: vidimo specifikaciju samo jednog tipa podataka te specifikaciju samo jedne operacije s pripadnim ulaznom i izlaznom porukom i porukom o greški.


165

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. Definitions of MaxMinType and InDataFault here Now define the interface and its operations. In this case, there is only a single operation to return maximum and minimum temperatures.

Slika 6.24: dio opisa u WSDL-u za meteorološki web servis.

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

166


Softversko inženjerstvo - skripta 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 workflow

Lista servisa kandidata

Specifikacije izabranih servisa

Testiranje aplikacije

Stvaranje workflowprograma

Profinjenje workflow-a

Aplikacija koja je spremna za upotrebu

Izvršivi workflow

Profinjeni workflow

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


167

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

Kupi karte za let

Naruči renta-car ili taksi

Rezerviraj sobu u hotelu

Datum i vrijeme dolaska i odlaska

Pretraži informacije o predstavama

Kupi ulaznice za kazalište

Datumi, preferencije

Lokacija hotela

Slika 6.26: workflow aplikacije za organiziranje putovanja avionom.

Pokušaj ponovo

Nema soba

Hoteli DajZahtjeve

Hoteli NijeRaspoloživo

Hoteli ProvjeriRaspoloživost Ima soba

Hoteli RezervirajSobe

Hoteli PotvrdiRezervaciju

Kupac

Slika 6.27: fragment workflow-a za rezervaciju hotela. 168

Odustani



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.


169

Robert Manger

170



Literatura Općeniti udžbenici o softverskom inženjerstvu: 1. Sommerville I.: Software Engineering, 9-th Edition. Pearson Education Inc, Boston MA, USA, 2010. ISBN 0-13-705346-0. 2. Van Vliet H.: Software Engineering - Principles and Practice, 3-rd Edition. John Wiley and Sons, Chichester, England UK, 2008. ISBN 0-470-03146-8. 3. Pressman R.S.: Software Engineering - A Practitioner’s Approach, 7-th Edition. McGraw Hill, New York NY, USA, 2009. ISBN 0-07-337597-7. 4. Schach S.R.: Object Oriented and Classical Software Engineering, 8-th Edition. McGraw Hill, New York NY, USA, 2010. ISBN 0-07-337618-3. 5. Braude E.J., Bernstein M.E.: Software Engineering – Modern Approaches. John Wiley and Sons, New York NY, USA, 2010. ISBN 0-471-69208-5. 6. Pfleeger S.L, Atlee J.M.: Software Engineering - Theory and Practice, 4-th Edition. Prentice Hall, Englewood Cliffs NJ, USA, 2009. ISBN 0-13-606169-9. 7. Tsui F., Karam O., Bernal B.: Essentials of Software Engineering, 3-rd Edition. Jones & Bartlett Publishers, Sudbury MA, USA, 2013. ISBN 1-4496-9199-4. Udžbenici koji obrađuju pojedine metode ili alate softverskog inženjerstva: 8. Bruegge B., Dutoit A.H.: Object-Oriented Software Engineering Using UML, Patterns, and Java, 3-rd Edition. Prentice Hall, Englewood Cliffs NJ, USA, 2009. ISBN 0-13606125-7. 9. Arlow J., Neustadt I.: UML 2 and the Unified Process, 2-nd Edition. Addison-Wesley. Upper Saddle River NJ, USA, 2005. ISBN 0-321-32127-8. 10. Beck K., Andres C.: Extreme Programming Explained – Embrace Change, 2-nd Edition. Addison-Wesley, Upper Saddle River NJ, USA, 2004. ISBN 0-321-27865-8. 11. Visual Paradigm International: Korisnička dokumentacija za Visual Paradigm for UML. http://www.visual-paradigm.com/support/documents 12. Randolph N., Gardner D., Anderson C., Minutillo M.: Professional Visual Studio 2010. (Wrox Programmer to Programmer), Wiley Publishing Inc., Indianapolis IN, USA, 2010. ISBN: 0470548657. 13. Chatfield C., Johnson T.D.: Microsoft Project 2010 Step by Step. Microsoft Press, Redmond WA, USA, 2010. ISBN 0-7356-2695-2. 14. Cooling J.: Software Engineering for Real-Time Systems. Addison Wesley, Harlow UK, 2003. ISBN: 0201596202. 15. Burns A., Wellings A.: Real-Time Systems and Programming Languages – Ada, RealTime Java and C/Real-Time POSIX. Addison-Wesley, Boston MA, USA, 2009. ISBN: 0321417453. 16. Silberschatz A., Galvin P., Gagne G.: Operating Systems Concepts, 8-th Edition. John Wiley and Sons, New York NY, USA, 2008. ISBN: 0470128720. 17. Beck K: Test Driven Development – By Example. Addison-Wesley, Boston MA, USA, 2002. ISBN: 0-321-14653-0. 18. Massol V., Husted T.: JUnit in Action. 2-nd Edition. Manning Publications, Stamford CT, USA, 2010. ISBN: 1-935182-02-1. 19. Vesperman J.: Essential CVS. O’Reilly and Associates, Sebastopol CA, USA, 2003. ISBN: 0596004591.


171

Robert Manger 20. Pilato C.M., Collins-Sussman B., Fitzpatrick B.W.: Version Control with Subversion. 2nd Edition. O’Reilly and Associates, Sebastopol CA, USA, 2008. ISBN: 0596510330. 21. Szyperski, C.: Component Software – Beyond Object-oriented Programming. 2-nd edition. Addison-Wesley, Harlow UK, 2001. ISBN: 0-201-17888-5. 22. Newcomer E., Lomow G.: Understanding SOA with Web Services. Addison-Wesley, Boston MA, USA, 2005. ISBN: 0-321-18086-0. 23. Erl T.: Service-Oriented Architecture – Concepts, Technology and Design. Prentice Ha.., Upper Saddle River NJ, USA, 2005. ISBN: 0-13-185858-0. 24. Richardson L., Ruby S.: RESTful Web Services. O’Reilly media Inc, Sebastopol CA, USA, 2007. ISBN: 0-596-52926-0. 25. White S.A., Miers D.: BPMN Modeling and Reference Guide – Understanding and Using BPMN. Future Strategies Inc, Lighthouse Point FL, USA, 2008. ISBN: 0-9777527-2-0. Klasična djela i dodatni sadržaji vezani uz softversko inženjerstvo: 26. Brooks F.P.: The Mythical Man Month - Essays on Software Engineering, Anniversary Edition. Addison-Wesley, Reading MA, USA, 1995. ISBN 0-201-83595-9. 27. ACM and IEEE-CS Joint Task Force: Software Engineering Code of Ethics and Professional Practice (Version 5.2). http://www.acm.org/about/se-code 28. DeMarco T. Structured Analysis and System Specification. Yourdon Press, New York NY, USA, 1978. ISBN 0138543801. 29. Ward P., Mellor S.: Structured Development for Real-Time Systems. Volume I, II, III. Prentice Hall, Englewood Cliffs NJ, USA, 1986. ISBN: 0138547874, 0138547955, 013854803X. 30. Gamma E., Helm R., Johnson R., Vlissides J.: Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading MA, USA, 1995. ISBN: 0-20163361-2. 31. Warren I.E.: The Renaissance of Legacy Systems. Springer, London UK, 1998. ISBN: 1852330600. 32. Lehman M.M., Belady L.: Program Evolution – Processes of Software Change. Academic Press, London UK, 1985. ISBN: 0124424406. 33. Jacobson I., Griss M., Jonsson P.: Software Reuse. Addison-Wesley, Reading MA, USA, 1997. ISBN: 0-201-92476-5.

172


SI Skripta v2

Recommend Documents