Programsko inžinjerstvo

JURICA ŠEPAROVIĆ

Sadržaj 1 Dizajn arhitekture ....................................................................................................................................................... 1

1.1 Uvod............................................................................................................................................................................ 1

1.2 Prikaz arhitekture ............................................................................................................................................... 1

1.3 Arhitekturna apstrakcija ................................................................................................................................ 1

1.4 Korištenje modela arhitekture .................................................................................................................. 2

1.5 Odluke kod dizajna arhitekture................................................................................................................ 2

1.6 Pogledi arhitekture ........................................................................................................................................... 4

1.7 Obrasci arhitekture ........................................................................................................................................... 5

1.7.1 Model-View-Controller (MVC) obrazac .................................................................................... 5

1.7.2 Obrazac slojevite arhitekture ........................................................................................................... 6

1.7.3 Obrazac arhitekture repozitorija.................................................................................................... 6

1.7.4 Obrazac klijent-server arhitekture ................................................................................................ 7

1.7.5 Arhitektura cjevovoda ........................................................................................................................... 8

1.8 Vrste aplikacija ..................................................................................................................................................... 8

1.8.1 Sustavi za obradu transakcija........................................................................................................... 9

1.9 Informacijski sustavi ......................................................................................................................................... 9

1.9.1 Web bazirani informacijski sustavi ............................................................................................... 9

1.10 Sustavi za obradu jezika ........................................................................................................................ 10

2. Dizajn i implementacija........................................................................................................................................ 11

2.1 Uvod......................................................................................................................................................................... 11

2.2 Objektno orijentirani proces dizajna ................................................................................................. 11

2.2.1 Procesne faze objektno orijentiranog dizajna................................................................... 11

2.2.2 Definiranje modela konteksta i interakcije .......................................................................... 12

2.2.3 Dizajn arhitekture.................................................................................................................................. 12

2.2.4 Identificiranje najvažnijih objekata sustava ......................................................................... 12

2.2.5 Razvoj modela dizajna ....................................................................................................................... 12

2.2.6 Specifikacija sučelja objekta .......................................................................................................... 13

2.3 Obrasci dizajna [Design patternsi] ...................................................................................................... 13

2.4 Problemi dizajna .............................................................................................................................................. 13

2.5 Implementacija ................................................................................................................................................. 14

2.5.1 Ponovno korištenje (engl. Reuse) .............................................................................................. 14

2.5.2 Upravljanje konfiguracijom (engl. Configuration managment) ............................ 14

2.5.3 Host – target razvoj ............................................................................................................................. 15

2.6 Alati razvojnih platformi............................................................................................................................. 15

2.7 Faktori primjene komponenti/sustava ............................................................................................. 15

2.8 Open source razvoj........................................................................................................................................ 16

2.8.1 Licenciranje open source softvera ............................................................................................. 16

3. TESTIRANJE .............................................................................................. Error! Bookmark not defined.

3.1 Verifikacija i validacija .................................................................................................................................. 17

3.2 Inspekcije i testiranje .................................................................................................................................... 18

3.2.1 Prednosti inspekcija u odnosu na testiranje....................................................................... 18

3.3 Model testnog procesa............................................................................................................................... 18

3.4 Faze testiranja ................................................................................................................................................... 19

3.4.1 Razvojno testiranje............................................................................................................................... 19

3.4.2 Testiranje verzije za objavu ............................................................................................................ 24

3.4.3 Korisničko testiranje ............................................................................................................................ 25

1

1 Dizajn arhitekture

1.1 Uvod

Dizajn arhitekture je jedna od početnih faza u dizajnu sustava. Predstavlja vezu između

faze dizajna i specifikacije.

To je proces u kojemu se identificiraju :

- Pod-sustavi promatranog sustava

- Načini za kontrolu i međusobnu komunikaciju pod-sustava

Rezultat dizajna arhitekture je opis arhitekture softvera.

Drugim riječima procesom dizajna arhitekture identificiraju se osnovne komponente

sustava te njihova komunikacija.

Čak i kod agilnih procesa vrijedi da se rane faze razvojnog procesa bave određivanjem

općenite arhitekture sustava. Inkrementalni razvoj arhitekture obično nije uspješan.

Refaktoriranje dizajna arhitekture sustava je složeno i skupo (za razliku od komponenti)!

1.2 Prikaz arhitekture

Arhitektura sustava se često prikazuje jednostavnim blok dijagramima

Pri tome :

- Svaki pravokutnik predstavlja komponentu

- Pravokutnici unutar pravokutnika predstavljaju da se komponenta sastoji od pod-

komponenti.

- Strelice prikazuju da se podatci ili signali izmjenjuju među komponentama i

prikazuju smjer izmjene

Nedostatci : vrlo apstraktan – ne prikazuje prirodu odnosa među komponentama niti

vidljiva svojstva pod sustava.

1.3 Arhitekturna apstrakcija

Arhitektura sustava može se razvijati na dvije razine apstrakcije :

• Arhitektura u malo – odnosi se na arhitekturu pojedinih sustava ( programa).

Gleda se kako se taj pojedinačni program dijeli na komponente

• Arhitektura u veliko – odnosi se na arhitekturu složenih poslovnih sustava.

Oni uključuju druge sustave i programe. Ovakvi sustavi su distribuirani na

različitim računalima i mogu biti u vlasništvu različitih tvrtki

2

1.4 Prednosti jasno definirane arhitekture

1. Komunikacija među zainteresiranim stranama – ovdje se arhitektura koristi

kao apstrakcija višeg nivoa za komunikaciju među različitim zainteresiranim

stranama.

2. Analiza sustava – izrada dobre i kvalitetne arhitekture u ranoj fazi projekta

zahtjeva određene analize iz čega se može lako zaključiti hoće li sustav zadovoljiti

kritične zahtjeve kao performanse , pouzdanost ili jednostavnost održavanja.

3. Ponovno korištenje komponenti – iste komponente se mogu ponovno koristiti

kod sustava koji imaju iste ili slične zahtjeve.

1.5 Korištenje modela arhitekture

1. Za olakšavanje rasprave o dizajnu sustava – prikaz arhitekture sustava je koristan

za komunikaciju sa klijentima i planiranje projekta, zbog svoje jednostavnosti i

visoke razine apstrakcije.

2. Kao način dokumentiranja arhitekture sustava – smisao ovog modela je napraviti

model kompletnog sustava koji pokazuje različite komponente, njihova sučelja i

njihove veze.

1.6 Odluke kod dizajna arhitekture

Dizajn arhitekture je kreativan proces u kojemu se pokušava organizirati sustav tako da

zadovolji sve funkcionalne i ne funkcionalne zahtjeve.

Dizajn arhitekture nikada nije isti proces već se uvijek treba donijeti niz odluka ovisno o

samim zahtjevima sustava.

Pri donošenju odluka treba voditi računa na koji način će određena rješenja utjecati na

ponašanje sustava kao cjeline.

Treba uzeti u obzir nekoliko pitanja o sustavu na koja će se dati i odgovore :

1. Postoji li kakva općenita arhitektura sustava koja se može koristiti kao

predložak u razvoju sustava

Iako je softverski sustav jedinstven, postoje sustavi iz iste domene koji imaju

sličnu arhitekturu. Aplikacije najčešće imaju istu osnovnu baznu arhitekturu , ali se

razlikuju po specifičnim potrebama korisnika.

Kada se dizajnira sustav treba vidjeti što sustav ima zajedničko sa sličnim

sustavima i iz njih pokušati iskoristiti neke predloške.

3

2. Kako će sustav biti distribuiran ?

Treba odrediti hoće li sustav biti distribuiran ili ne.

3. Koji se obrasci(patterns) arhitekture mogu koristiti ?

Pod stilovima arhitekture se podrazumijeva npr. Klijent-server arhitektura ili slojevita

arhitektura. Arhitektura sustava može se bazirati na jednom ili više obrazaca ( engl.

Patterns).

Obrazac opisuje osnovne funkcionalnosti i karakteristike arhitekture, koji se zatim

prilagođavaju konkretnim problemima.

Potrebno je biti svjestan koji sve obrasci postoje, kada se koriste , koje su njihove

prednosti i nedostatci kada se donose odluke o arhitekturi sustava.

4. Koji će se osnovni pristup koristiti za strukturiranje sustava ?

Potrebno je odabrati prikladniju strukturu ( klijent-server, slojevita ) koja će

omogućiti da se zadovolje zahtjevi.

5. Na koji način će se sustav razbiti na module(pod-sustave) ?

Potrebno je odrediti strategiju razdvajanja sustava na podsustave, ovisno o tome

mogu se implementirati različite arhitekture.

6. Koja kontrolna strategija će se koristiti za provjeru rada komponenti u

sustavu ?

Donosi se odluka na koji način se kontrolira rad komponenti u sustavu.

7. Koja organizacija arhitekture će biti najbolja za postizanje ne funkcionalnih

zahtjeva ?

S obzirom da je izbor arhitekture sustava u velikoj mjeri povezan sa ne funkcionalnim

zahtjevima, ovisno o zahtjevima treba odabrati odgovarajuću arhitekturu.

Npr. :

- Performanse – koristiti manje velikih komponenti i minimizirati komunikaciju

- Zaštita ( engl. Security) – koristiti slojevitu arhitekturu , pri čemu su kritične

komponente u unutarnjim slojevima

- Sigurnost (engl. Safety) – dijelovi sustava na koje se primjenjuju ista sigurnosna

ograničenja se trebaju nalaziti unutar istog podsustava ili unutar malog broja

podsustava

- Dostupnost – uključivanje redundantnih komponenti i drugih mehanizama kako

bi sustav bio što otporniji na greške.

- Održavanje – koristiti više malih zamjenjivih komponenti.

4

Ukoliko dolazi među konflikta u zahtjevima potrebno je pronaći kompromis ili se

može koristiti različita arhitektura za različite dijelove sustava.

8. Kako će se procijeniti kvaliteta dizajna arhitekture ?

Procjenjivanje dizajna arhitekture je jako teško jer pravi test predstavlja test koliko

dobro sustav zadovoljava funkcionalne i ne funkcionalne zahtjeve za vrijeme rada.

Neke provjere se mogu napraviti usporedbom arhitekture s nekom referentom

arhitekturom ili predloškom arhitekture.

9. Na koji način će se dokumentirati arhitektura ?

Krajnji produkt arhitekture dizajna je dokumentacija dizajna arhitekture. Treba

odrediti kako će se sve to zapisati.

1.7 Pogledi arhitekture

U ovom poglavlju opisati će se dva jako bitna pitanja vezana za dizajn arhitekture :

1. Koji pogledi ili perspektive su korisne kada se dizajnira i dokumentira

arhitektura sustava ?

2. Koji načini zapisa se trebaju koristiti za opisivanje modela arhitekture

Na jednom modelu arhitekture moguće je prikazati samo jednu perspektivu ili samo jedan

pogled sustava. Kod izrade dizajna i dokumentacije potrebno je prikazati više pogleda na

arhitekturu softvera.

4+1 MODEL POGLEDA ARHITEKTURE SOFTVERA

Logički pogled – prikazuje ključne apstrakcije u sustavu u obliku objekata ili klasa

objekata.

Procesni pogled - prikazuje od kojih procesa se sustav sastoji u trenutku izvršavanja, te

koji su procesi u interakciji.

Razvojni pogled – prikazuje na koji način je potrebno razdijeliti softver u manje dijelove

koji se mogu zasebno razvijati. Npr. sučelje , baza podataka …

Fizički pogled – koji prikazuje od kojih se hardverskih komponenti sastoji sustav , te

distribuciju softverskih komponenti po hardveru.

5

1.8 Obrasci arhitekture

Općenito obrasci (engl. Patterns) su načini dijeljenja i ponovnog korištenja znanja.

Obrazac arhitekture je uspješan i testiran u različitim okruženjima i može se ponovno

iskoristiti po potrebi.

1.8.1 Model-View-Controller (MVC) obrazac

MVC obrazac

Opis Dijeli prezentaciju i interakciju od podataka. Sustav se dijeli u tri logičke

komponente.

Model – upravlja podatcima u sustavu, kao i operacijama na tim

podacima.

View – definira i upravlja načinom prezentacije podataka korisniku

Kontroler - upravlja akcijama korisnika i prosljeđuje ih modelu i pogledu

Primjer

Upotreba Koristi se kada postoji više načina pregleda i interakcije s podacima.

Također se koristi kada su budući zahtjevi za interakciju i prezentaciju

podataka nepoznati.

Prednosti Na ovaj način moguća je promjena podataka neovisno o načinu

prezentacije i obrnuto. Odvaja elemente sustava i dozvoljava mijenjanje

jednog elementa neovisno o ostalima.

Nedostaci U slučaju jednostavnih modela podataka i jednostavnih interakcija može

uključivati više koda nego što je potrebno

6

1.8.2 Obrazac slojevite arhitekture

Slojevita arhitektura

Opis Organizira sustav u slojeve sa sličnim funkcionalnostima.

Sloj pruža usluge sloju iznad njega pa slojevi najniže razine predstavljaju

osnovne usluge koje će vjerojatno koristiti cijelom sustavu (npr.

Operacijski sustav)

Primjer Arhitektura android sustav

Upotreba Koristi se : -

- pri nadogradnji postojećih sustava

- kada je za razvoj odgovorno nekoliko timova , a svaki od njih je

odgovoran za određeni sloj.

- kada postoji potreba za više razine sigurnosti

Prednosti Moguće je kompletan sloj zamijeniti , a jedini uvjet je da se zadrži sučelje

prema susjednim slojevima

Nedostaci U praksi je često nemoguće ostvariti jasno odvajanje slojeva i često se

događa (npr. zbog brzine izvršavanja) da viši slojevi direktno

komuniciraju s nižim , a ne preko međuslojeva.

Problem mogu biti i performanse jer transfer zahtjeva od sloja do sloja (

s obradom na svakom nivou) traje

1.8.3 Obrazac arhitekture repozitorija

Repozitorij arhitektura

Opis Svi podatci u sustavu nalaze se u središnjem repozitoriju koji je dostupan

svim komponentama sustava. Komponente ne komuniciraju direktno već

samo preko repozitorija

Primjer Komandni i kontrolni sustavi , CAD sustavi , CASE alati , sustavi za

upravljanje informacijama …

Upotreba Repozitorij pattern koristi se kod sustava u kojem se generira velika

količina podataka i pohranjuje na dulje vrijeme

Prednosti Komponente sustava su neovisne i ne trebaju voditi računa o egzistenciji

ostalih komponenti.

S obzirom da se svi podatci nalaze na jednom mjestu pojednostavljeno

je njihovo upravljanje ( backup, kontrola pristupa ….)

Nedostaci Problem u repozitoriju utječe na čitav sustav. Distribucija repozitorija

preko više računala može biti komplicirana

7

1.8.4 Obrazac klijent-server arhitekture

Klijent - server

Opis Klijent server arhitektura sastoji se od :

Jednog ili više servera koji pružaju određene usluge

Jednog ili više klijenta koji koriste te usluge

Mreže koja omogućava pristup klijenta serveru

Klijenti moraju znati imena dostupnih servera i njihovih usluga, dok

serveri ne moraju imati nikakve informacije o klijentima.

Primjer Internet , biblioteka neka

Upotreba Koristi se kada postoji potreba da se podatcima u bazi pristupa sa

različitih lokacija.

Budući da se serveri mogu replicirati, također se mogu koristiti kada je

opterećenje sustava varijabilno.

Prednosti Osnovna prednost ovog modela jest da serveri mogu biti distribuirani

Nedostaci Svaki servis aplikacije je kritična točka u kojoj može doći do greške,

zlonamjernih napada , pada servera.

Performanse mogu biti nepredvidljive jer ovise o mreži isto kao i o

sustavu.

Može doći do problema ako su serveri u vlasništvu različitih organizacija.

8

1.8.5 Arhitektura cjevovoda

Cjevovod

Opis Sustav je organiziran preko niza komponenti koje obavljaju jednu vrstu

transformacije podataka.

Podatci teku kao u cijevi. Izlaz jedne komponente ide prema drugoj na

obradu

Primjer Sustav za obradu računa

Upotreba Koristi se u aplikacijama za obradu podataka u kojima se ulazni podatci

obrađuju kroz različite komponente kako bi se generirao odgovarajući

izlaz

Prednosti Jednostavan za razumijevanje i podržava ponovno korištenje

transformacija.

Sustavi se mogu jednostavno nadograditi dodavanjem novih

transformacija

Nedostaci Format prijenosa podataka mora biti dogovoren između komponenata

za obradu.

Svaka komponenta mora prebaciti ulazne podatke iz dogovorene forme

u oblik koji koristi , a zatim na kraju obrade , ponovno složiti izlazne

podatke u dogovorenu formu.

To povećava vrijeme obrade i može biti nemoguće ponovno koristiti

određene komponente koje koriste različiti format ulazni/izlaznih

podataka

1.9 Vrste aplikacija

• Aplikacije za obradu podataka - aplikacije koje pokreću podatci. Aplikacija obrađuje

velike količine podataka bez eksplicitne intervencije korisnika tijekom obrade. Npr.

sustav naplate , obrade plaća

• Aplikacije za obradu transakcija - aplikacije koje obrađuju korisničke zahtjeve i

ažuriraju podatke u bazi podataka (npr. sustav rezervacija ili prodaje preko interneta)

• Aplikacije za obradu događaja – aplikacije kod kojih se prate događaji i sukladno

tome se radi obrada. Npr. aplikacija za obradu teksta WORD.

• Aplikacije za obradu jezika – aplikacije kod kojih se zahtjevi korisnika specificiraju

formalnim jezikom , koje zatim sustav interpretira i obrađuje . Npr. interpretira

naredbi , prevodioci …

9

1.9.1 Sustavi za obradu transakcija

Sustavi koji obrađuju korisničke zahtjeve i ažuriraju ili dobavljaju podatke u bazi

podataka (npr. sustav rezervacija ili prodaje preko interneta).

Struktura sustava za obradu transakcija :

1.10 Informacijski sustavi

Informacijski sustav baziran na transakcijama je sustav koji uključuje interakciju sa

„zajedničkom“ bazom podataka. (katalog knjižnice , raspored letova …)

Svi informacijski sustavi imaju istu generičku

arhitekturu koja je organizirana po slojevima.

Slojevi se sastoje od :

- Korisničkog sučelja

- Komunikacije sa korisnikom

- Dohvata i izmjene informacija

- Sistemske baze podataka

1.10.1 Web bazirani informacijski sustavi

Sustavi za upravljanje podatcima i resursima su danas obično bazirani na webu. Njihovo

korisničko sučelje implementirano je putem web preglednika.

Implementacija na serveru

Web bazirani sustavi su najčešće implementirani kao višeslojne klijent-server arhitekture.

Web server – odgovoran je za komunikaciju s korisnikom putem korisničkog sučelja koji

je implementiran koristeći web preglednik.

Aplikacijski server – odgovara za implementaciju specifične aplikacijske logike kao i za

pohranu podataka te dohvat zahtjeva.

Server baze podataka pomiče podatke u bazu ili iz baze podataka i obrađuje transakcije

10

1.11 Sustavi za obradu jezika

Sustavi kod kojih se zahtjevi korisnika specificiraju formalnim jezikom , koje zatim sustav

interpretira i obrađuje.

Sastoji se od :

• Naredbe – opisuju što treba napraviti.

• Prevodilac prevodi naredbe u neki interni format koji odgovara strojnim

naredbama strojnog jezika.

• Interpreter – dohvaća strojne naredbe i izvršava ih, a pri tome koristi ulazne

podatke. Kod većine prevodilaca interpreter je hardverska komponenta koja

obrađuje strojne naredbe. Kod Jave interpreter je softverska komponenta.

11

2. Dizajn i implementacija

2.1 Uvod

Dizajn i implementacija je jedna od faza u razvoju software čiji je rezultat gotov

proizvod. Dizajn i implementacija su neraskidivo povezani :

- Dizajnom se definiraju komponente sustava, njihova ponašanja i međusobna

komunikacija

- Implementacija je proces realizacije dizajna u obliku programskog koda tj.

programa

Prilikom početka implementacije treba odlučit o tome dali će se kupiti gotov software i

modificirati po potrebi ili će se raditi iz početka

2.2 Objektno orijentirani proces dizajna

Objektno orijentirani proces dizajna uključuje planiranje objekata , dizajn klasa i veza

među klasama.

Takav proces dizajna je mnogo prirodniji i jednostavniji od funkcionalnog dizajna zbog

toga što zapravo u većini slučajeva radimo sa nekim objektima (Korisnik, Recept …).

Definira se predložak za objekt (klasa) te ponašanje objekata (metode) i način

međusobne komunikacije sa drugim objektima. Mijenjanje jednog objekta ne smije

utjecati na druge objekte.

Ovakav princip je dobar kada u razvoju software sudjeluje više različitih grupa.

Za jednostavne sustave OOP model može zahtijevati dosta truda i biti neisplativ.

2.2.1 Procesne faze objektno orijentiranog dizajna

Kako bi bilo moguće razviti sustav tj. od ideje doći do kompletnog rješenja objektno

orijentiranog dizajna trebamo napraviti nekoliko stvari :

1. Definirati modele korištenja sustava

2. Dizajnirati arhitekturu sustava

3. Identificirati najvažnije objekte sustava

4. Razvoj modela dizajna

5. Specifikacija sučelja objekta

12

2.2.2 Definiranje modela konteksta i interakcije

Da bi znali kako osigurati tražene funkcionalnosti sustava moramo razumjeti vezu

između sustava koji se razvija i njegove okoline.

Kontekstni model - je model koji prikazuje druge sustave u okolini sustava koji se

razvija

Model interakcije – je model koji prikazuje iterakciju sustava s okolinom za vrijeme

korištenja

2.2.3 Dizajn arhitekture

Nakon što smo definirali sve komponente sustava i njihovu međusobnu iterakicju te

informacije se koriste za dizajn arhitekture sustava.

Dizajn arhitekture provodi se kroz nekoliko koraka :

1. Identificiranje komponenti sustava

2. Identificiranje ponašanja komponenti

3. Odabir nekog od stilova za razvoj arhitekture (slojeviti, client server …)

2.2.4 Identificiranje najvažnijih objekata sustava

Ovo je kompleksan zadatak koji nema striktne formule. To je iterativni proces.

Pristupi identifikaciji objekata :

• Korištenje gramatičkog pristupa koji je baziran na opisu sustava prirodnim

jezikom. Objekti i atributi su imenice , glagoli su operacije)

• Bazirati identifikaciju na „opipljive stvari“ (avion) , uloge (doktor,menadžer),

interakcije , lokacije (ured) …

• Koristiti analizu baziranu na scenarijima iz kojih možemo prepoznati objekte ,

atribute i metode.

2.2.5 Razvoj modela dizajna

Model dizajna prikazuje objekte i klase objekata te njihovu međusobnu komunikaciju.

Dvije osnovne grupe UML modela dizajna :

- Statički model – opisuje statičku strukturu sustava preko objekata i njihovih

veza.

- Dinamički model – prikazuje se način iterakcije među objektima

13

Najkorisniji modeli dizajna su :

• Model podsustava koji prikazuje logičko grupiranje objekata u pod-sustave

• Slijedni model prikazuju slijed interakcije objekata

• Dijagram prijelaza stanja – prikazuje kako objekti reagiraju na određene zahtjeve i

kako sukladno tome mijenjaju svoja stanja.

2.2.6 Specifikacija sučelja objekta

Kako bi na razvoju sustava mogli raditi više ljudi istovremeno moramo specificirati

sučelja objekata.

Sučelje objekta zapravo predstavlja metode koje će objekt imati.

2.3 Obrasci dizajna [Design patternsi]

Obrazac – je opsi problema i načina na koji se taj problem rješava. Obrasci omogućuju

da rješenje ponovno koristimo u različitim sutuacijama.

Četiri osnovna elementa svakog predloška dizajna :

1. Naziv obrasca

2. Opis obrasca i problema – objašnjava u kojem slučaju se obrazac može primjeniti

3. Rješenje – način na koji se može implementirati obrazac.

4. Posljedice – opisuje rezultat i kompromis primjene obrasca.

2.4 Problemi dizajna

Kada naiđemo problem kod dizajna trebamo potražiti neki obrazac koji može pomoći.

• Obavijestiti nekoliko objekata da se stanje drugih objekata promjenilo (Observerattern)

• Povezati sučelja u odgovarjuće objekte koji se razvijaju inkrementalno (Facade pattern)

• Omogućiti standardan način pristupa elementima u kolekciji, bez obzira kako je kolekcija

implementirana (Iterrator pattern).

• Omogućiti mogućnost nadogradnje funkcionalnosti postojeće klase za vrijeme izvođenja

(decorator pattern).

14

2.5 Implementacija

Implementaciaja sustava je faza u kojoj se stvara prva verzija prgorama.

Važni aspekti implementacije koji se spominju u programskom inženjerstvu :

2.5.1 Ponovno korištenje (engl. Reuse)

Većina modernog softvera se izrađuje korištenjem postojećih komponenti ili sustava.

Kada se razvija softvare trebalo bi koristiti što više postojećeg koda.

Ponovno korištenje softvera je moguće na različitim nivoima :

- Apstraktni nivo : ponovno se koristi znanje o dizajnu softvera (predlošci dizajna i

arhitekture )

- Objektni nivo : ponovno korištenje objekta. Treba naći odgovarajuce.

- Nivo komponenti – komponenta je kolekcija objekata i klasa koje pružaju

određenu funkcionalnost

- Sistemski nivo – ponovno se koristi čitavi aplikacijski sutav.

Trošak ponovnog korištenja softvarea ?

- Vrijeme koje se provede u traženju postojećeg softverak oji se može iskoristiti.

- Nekada treba i kupit softver koji mislimo ponovno koristiti

- Trošak prilagodbe i integracije u vlastiti sustav

2.5.2 Upravljanje konfiguracijom (engl. Configuration managment)

Upravljanje konfiguracijom generalno označava proces upravljanja izmjenama softvera

koji se razvija.

Tri osnovne aktivnosti koji takav softver može pružiti su :

1. Upravljanje vezijama – pruža mogućnost praćenja različitih verzija komponenti

softvera koji se razvijaju. Podržava kordinaciju rada nekoliko programera.

2. Integracija sustava – služi razvojnom timu da definira koje su verzije komponenti

koršitene za kreiranje verzije sustava.

3. Praćenje problema – omogućava članovima razvojnog tima da prate probleme i vide

ko radi na kojem problemu i kada je on rješen. Također omogućava i kor isnicima prijavu

grešaka i drugih problema.

15

2.5.3 Host – target razvoj

Najčešće se softver razvija na jednom sustavu (tvz. Host), dok se izvršava na nekom

drugom (tvz. Target). Ova dva sustava mogu i nemoraju biti istog tipa.

Ukoliko se gleda još općenitije može se pričati o izvršnoj i razvnojoj platformi.

Ukoliko su razvojna i izvšna platforma različite (koriste različiti softver ili arhitekturu)

moguća rješenja su :

- Softver se testira tako da se instalira na izvršnoj platformi

- Na razvojnoj platformi je potrebno pokrenuti simulator izvšne platforme.

2.6 Alati razvojnih platformi

Platforme za razvoj softvera (razvojne platforme) imaju niz alata koji olakšavaju proces

programskog inženjerstva :

- IDE – integrira čitavu grupu razvojnih alata koji podržavaju različite aspekte

razvoja softvera. Najčešće se kreira kao podrška određenom programskom jeziku,

ali može biti i opće namjene s podrškom za određene jezike.

- Testne alate , npr phpUnit koji se automatksi pokrecu za sve verzije programa

- Alate za pdoršku projektu, koji omogućavaju organiziranje koda za različite

razvojne projekte

2.7 Faktori primjene komponenti/sustava

Kod ugradbnih sustava to najčešće nije problem jer je ciljani sustav jedno računalo.

Kod distribuiranih sustava potrebno je razmotriti slijedeće probleme :

- Hrdverski i softverski zahtjevi na komponente

- Zahtjevi na dostupnost sustava – ukoliko se zahjeva da je sustav stalno dostupan

može biti potrebno primijeniti sustav na različitim računalima (ako jedan umre ,

drugi je dostupan)

- Komunikacija komponenti – ako komponente komuniciraju ima ih smisla

primijeniti na istom računalu ili fizički bliskim ralunalima kako bi se minimiziralo

kašnjenje.

16

2.8 Open source razvoj

Open source razvoj je nalin razvoja softvera u kojem je izvorni kod javno objavljen i

dobrovoljnci su poznavi da sudjeluju u razvojnom procesu.

Open source razvoj dobiva važnost na internetu jer se u razvoj ukljućuje veliki broj

dobrovoljaca.

U teoriji , bilo koji sudionik open source projekta može dodavati nove funkcionalnosti ili

ispravljati greške. U praksi imamo jedan glavni razvojni tim koji kontrolira izmjene

softvera i zahtjeve za promjenama.

Poznati open source sustavi : linux, apache , mysql …

Zreli open source sustavi su vrlo pouzdani. Sve više kompanija koristi open source

pristup razvoju.

2.8.1 Licenciranje open source softvera

Onaj tko je napisao kod (firma ili pojedinac) prema zakonu je vlansik tog koda i može

staviti ograničenja na koji će se način kod koristiti.

Neki smatraju da ukoliko se koristi open soruce komponenta za razvoj novog sustava ,

tada i taj sustav treba biti open source. Drugi ne stavljaju takva ograničenja na svoj kod,

pa novi softver ne mora biti open source tipa.

Poznate open source licence :

- The GNU General Public Licence (GPL) – ukoliko se koristi softvare s ovom

licenctom tada rezultirani softver također treba biti open source

- THE GNU Lesser General Public License – u aplikaciji se mogu koristiti open source

komponente , bez da aplikacija bude open source, ali se sve izmjene u open

source komponentama moraju objaviti.

- The Berkley Standard Distribution – neme nikakve obaveze prema open source

kodu.

17

3. Testiranje

Testiranje je proces koji dokazuje da program radi ono za što je namijenjen, te pomaže

u otkrivanju propusta ili grešaka, koji su napravljeni u razvoju, prije nego se krene s

korištenjem programa. Test otkriva postojanje greške, a ne da je NEMA.

Ciljevi testiranja:

- Demonstrirati i razvojnom timu i korisnicima da softver odgovara zahtjevima

[VALIDACIJA i VERIFIKACIJA].

o Za softver po narudžbi bi trebao biti bar jedan test za svaki zahtjev,

o Za generički softver to znači da bi trebalo napraviti testove za svaku od

mogućnosti tog softvera.

- Otkriti u kojim situacijama se softver ne ponaša ispravno ili na način koji ne

odgovara specifikaciji [TESTIRANJE GREŠAKA].

o Testiranje grešaka (engl. defect testing) se koristi za pronalaženje grešaka u

smislu neželjenog ponašanja sustava (pad sustava), neželjenih interakcija s

drugim sustavima, neispravnih proračuna te narušavanja integriteta podataka.

3.1 Verifikacija i validacija

Verifikacija: Provjerava odgovara li softver specifikaciji zahtjeva, tj. funkcionalnim i

nefunkcionalnim zahtjevima.

Validacija: Provjerava odgovara li softver stvarnim potrebama korisnika.

Softver ne mora biti u potpunosti bez grešaka, a stupanj tolerancije na grešake ovisi o:

• Funkciji softvera – što je softver kritičniji to je važnije da bude pouzdan i stupanj

tolerancije na greške je manji.

• Očekivanju korisnika – korisnici mogu imati niska očekivanja zbog prethodnih

iskustava. Korisnici mogu tolerirati padove sustava zbog pogodnosti koji im taj

softver donosi i u tim situacijama nije potrebno provesti opsežno testiranje, ali

kako softver sazrijeva potrebno je proširiti opseg testova.

• Tržišnim uvjetima – objava produkta na tržištu može biti važnija nego

pronalaženje grešaka (objava verzije prije konkurencije, cijena koju su korisnici

spremni platiti, datum isporuke).

18

3.2 Inspekcije i testiranje

Testiranje softvera – dinamička provjera ponašanja sustava

- Sustav se izvršava s testnim podacima i promatra se njegov rad.

Inspekcija softvera – statička provjera ponašanja sustava koja se bavi analizom sustava

kako bi se otkrili problemi.

- Korištenjem alata za analizu koda.

Inspekcije softvera se fokusiraju na provjeravanje izvornog koda s ciljem otkrivanja

anomalija i grešaka. Mogu se fokusirati na bilo koji čitljivi dio (specifikacija zahtjeva,

dizajna, konfiguraciju, testne podatke, …)

3.2.1 Prednosti inspekcija u odnosu na testiranje

Inspekcije se koriste jako dugo vremena i postoje studije i eksperimenti koji pokazuju da

su inspekcije efikasnije u pronalaženju grešaka od testiranja.

- Za vrijeme testiranja neke greške mogu prikriti druge greške. S obzirom da su

inspekcije statički procesi ne treba voditi računa o interakciji među greškama i u jednoj

inspekciji je moguće pronaći više grešaka.

- Nedovršene verzije sustava se mogu provjeravati bez dodatnih troškova.

- Osim što inspekcija pronalazi greške u programu, mogu se promatrati i širi

aspekti programa kao kompatibilnost sa standardima, prenosivost i održavanje.

3.3 Model testnog procesa

Testni primjeri – specificiraju ulazne vrijednosti u testove, očekivani rezultat testa (izlazne

vrijednosti), te opis što se testira.

Testni podaci – ulazni parametri osmišljeni tako da testiraju sustav. U nekim slučajevima

se mogu generirati automatski ali češće su u to uključeni ljudi koji razumiju što bi sustav

trebao raditi.

19

3.4 Faze testiranja

1. RAZVOJNO TESTIRANJE – u fazi razvoja sustav se testira kako bi se otkrile grešk i

nepravilnosti, a u testiranju sudjeluju dizajneri i programeri.

2. TESTIRANJE VERZIJA ZA OBJAVU – odvojeni testni timovi testiraju gotove verzije

sustava prije nego se predaju korisnicima. Cilj je provjera da sustav odgovara

zahtjevima zainteresiranih strana.

3. KORISNIČKO TESTIRANJE – korisnici ili potencijalni korisnici testiraju sustav u

svojoj okolini.

3.4.1 Razvojno testiranje

Uključuje sve testne aktivnosti koje provodi razvojni tim za vrijeme izrade sustava.

- Test najčešće provodi programer koji radi na tom dijelu koda, ili u nekim

razvojnim procesima se koriste parovi programer/tester gdje svaki radi u suradnji

s jednim testerom koji razvija testove i pomaže u testnim procesima.

- Kod kritičnih sustava koristi se još formalniji pristup koji podrazumijeva

postojanje odvojene grupe za testiranje unutar razvojnog tima.

Postoje:

a) Jedinično testiranje – testiraju se pojedinačne cjeline programa ili klase objekata.

Fokus je postavljen na provjeru funkcionalnosti objekata ili metoda.

b) Testiranje komponenti – nekoliko pojedinačnih cjelina se integrira s ciljem

stvaranja komponenti. Cilj je testiranje sučelja komponenti.

c) Testiranje sustava – neke ili sve komponente sustava se integriraju u sustav i on

se testira kao cjelina. Testiranje se fokusira na interakciju komponenti.

20

3.4.1.1 Jedinično testiranje

Proces izoliranog testiranja pojedinačnih komponenti programa. Jedinice mogu biti:

- Pojedinačne funkcije ili metode unutar objekta

o Jedinični testovi pozivaju ove funkcije/metode s različitim ulaznim

parametrima i provjeravaju slažu li se stvaran i očekivani rezultat.

- Klase objekata s nekoliko atributa i metoda

o Testirati sve operacije povezane s objektom: postaviti i provjeriti vrijednosti

svih atributa povezanih s objektom, postaviti objekt u sva moguća stanja,

što znači da treba simulirati sve događaje koji uzrokuju promjenu stanja

Vrste jediničnih testova:

- Testovi koji provjeravaju normalno ponašanje sustava – testovi pokazuju da

komponenta koja se testira kada se koristi na ispravan način radi ono što se od nje

očekuje

- Testovi koji provjeravaju problematično ponašanje sustava – testovi koriste

neispravne ulazne podatke i provjeravaju vode li oni do pada komponente ili su

ispravno obrađeni.

Komponente automatiziranih testova :

1. Inicijalizacijski dio – sustav se inicijalizira s testnim podatcima ( definiraju se ulazne

vrijednosti i očekivani rezultati testova)

2. Pozivni dio – dio u kojem se poziva očekivani objekt ili metoda koji se testiraju

3. Dio tvrdnje - (assertion) – u kojemu se usoređuje rezultat s očekivanim rezultatom.

Ukoliko je rezultat tvrdnje istinit test je prošao.

Testne strategije:

- Testiranje particija (grupa)– identificiraju se grupe ulaznih podataka koje imaju

zajedničke karakteristike i svi elementi grupe se obrađuju na isti način.

- Testiranje bazirano na uputama – odabir testova se radi prema uputama. Upute su

nastale kao rezultat prethodnih iskustava. Kod testiranja programa koji uključuju

nizove ili liste upute bi bile:

o Testiraj program s nizovima koji imaju jednu vrijednost,

o Odabrati ulazne vrijednosti tako da generiraju poruke o grešci

21

3.4.1.2 Testiranje komponenti

Softverska komponenta se najčešće sastoji od nekoliko objekata u interakciji.

Funkcionalnostima tih objekata se pristupa preko definiranog sučelja, pa se testiranje u

biti svodi na testiranje ponaša li se sučelje komponente prema specifikaciji.

Testiranje sučelja – cilj je otkriti greške koje nastaju kao rezultat grešaka sučelja ili krivih

pretpostavki o sučeljima.

Moguće grešaka sučelja razlikuju se ovisno o vrstama sučelja:

- Parametarska sučelja – sučelja kod kojih se podaci prebacuju iz jedne

komponente u drugu. (Metode objekta imaju parametarsko sučelje.)

- Sučelja zajedničke/dijeljene memorije – sučelja u kojima komponente dijele dio

memorije. Jedan podsustav smješta podatke u memoriju, a drugi im pristupa na

toj memorijskoj lokaciji.

- Sučelja procedura – jedan podsustav obuhvaća niz procedura, koje onda mogu

pozivati drugi podsustavi.

- Sučelja za prosljeđivanje poruka – sučelje kod kojeg jedna komponenta traži servis

od druge na način da joj proslijedi poruku

Moguće greške sučelja:

- Zloupotreba sučelja – Korištena komponenta poziva drugu komponentu i pri

tome koristi sučelje na krivi način. Česta je kod parametarskih sučelja (šalju se

parametri neispravnog tipa, u neispravnom rasporedu, neispravan broj

parametara).

- Nesporazum kod korištenja sučelja – Pozvana komponenta se ne ponaša na

očekivani način, što uzrokuje nepredvidivo ponašanje komponente koja ju je

pozvala. Npr. metoda za binarno pretraživanje očekuje da će dobiti sortirani niz,

ukoliko niz nije sortiran algoritam daje neočekivane rezultate.

- Greške zbog vremenske neusklađenosti – Komponenta koja poziva i pozvana

komponenta rade različitom brzinom zbog čega neka od njih pristupa zastarjelim

informacijama. Događaju se kod sustava za rad u realnom vremenu.

Upute za testiranje sučelja:

- Dizajnirati testove koji će uzrokovati grešku.

- Korištenje stres testova kod sustava koji izmjenjuju poruke. Dizajnirati testove tako da generiraju

mnogo više poruka među komponentama nego što će to biti slučaj u praksi.

22

3.4.1.3 Testiranje sustava

Uključuje integraciju komponenti u neku od izvršnih verzija sustava i zatim testiranje

integriranog sustava.

"Use-case" testiranje – "Use case" scenariji razvijeni u fazi specifikacije zahtjeva i dizajna

identificiraju interakcije među dijelovima sustava i mogu se koristiti kao osnova za

testiranje. Svaki "use case" obično uključuje nekoliko komponenti sustava pa testiranje

nekog "use case-a" forsira sve te interakcije. Slijedni dijagram koji je dio "use case-a" daje

vezu između komponenti i interakcija koje se testiraju.

Razvoj upravljan testiranjem – pristup razvoja programa u kojem su testiranje i

programiranje usko povezani. TDD se pojavio kao dio Agilnih metoda (XP), ali može se

koristiti i kao dio razvojnog procesa baziranog na planiranju. Testovi se pišu prije koda i

prolazak testa je cilj razvoja.

Procesne aktivnosti TDD-a:

- U proces se kreće identifikacijom inkrementa potrebnih funkcionalnosti. Pri tome

svaki inkrement bi trebao biti dovoljno mal da se može napisati s nekoliko linija

koda.

- Piše se test za tu funkcionalnost i implementira u obliku automatiziranog testa.

- Pokreću se svi testovi, pri tome pošto funkcionalnost još nije implementirana

testovi ne prolaze.

- Implementira se funkcionalnost i ponovno pokreće test. Ovaj korak može

uključivati procjenjivanje postojećeg koda s ciljem poboljšanja i dodavanje novog

koda.

- Jednom kada se svi testovi uspješno izvrše, ide se na implementaciju slijedećeg

djelića funkcionalnosti.

23

Prednosti TDD razvoja:

- Pokrivenost koda – svaki napisani djelić koda bi trebao imati bar jedan pridruženi

test.

- Regresijsko testiranje – testni paket se razvija inkrementalno s programom i uvijek

se provode svi testovi kako bi se provjerilo da neke izmjene u programu nisu

uzrokovale greške.

- Pojednostavljeno uklanjanje grešaka – kada test javi grešku, jasno je gdje je greška

nastala .

- Dokumentacija sustava – testovi su sami po sebi oblik dokumentacije koji opisuju

što bi kod trebao raditi.

24

3.4.2 Testiranje verzije za objavu

Proces testiranja verzije programa koja se namjerava koristiti van razvojnog tima (najčešće

za korisnike). Primarni cilj je uvjeriti naručioca da je sustav dovoljno dobar za upotrebu.

Najčešće se radi o black-box testiranju gdje se testovi izvode iz specifikacije sustava.

Testiranje verzije za objavu je dio testiranja sustava, a važne razlike su:

- Odvojeni tim koji nije bio uključen u razvoj sustava bi trebao provesti testiranje za

objavu.

- Testiranje sustava koje provodi razvojni tim bi se trebalo fokusirati na pronalaženje

grešaka, dok testiranje verzije za objavu provjerava da sustav odgovara zahtjevima

i dovoljno je dobar za upotrebu (validacijsko testiranje).

Testiranje verzije za objavu će se baviti testiranjem:

- Funkcionalnosti (bazirano na zahtjevima i scenarijima), Performansi.

Vrste:

- Testiranje bazirano na zahtjevima – zahtjevi bi trebali biti napisani tako da ih je lako

testirati, uključuje razmatranje svih zahtjeva i pisanje jednog ili više testova koji

provjeravaju je li zahtjev zadovoljen ili ne. Ovdje se radi više o validaciji sustava, a

ne uklanjanju grešaka.

- Testiranje bazirano na scenarijima – pristup testiranju verzije sustava za objavu kod

koje se smišlja tipičan scenarij korištenja sustava i on se koristi za izradu testnih

primjera. Npr.:

o Identifikacija korisnika prijavom u sustav.

o Prebacivanje podataka o pacijentima na prijenosno računalo.

o Ispis rasporeda kućnih posjeta.

o Dohvat i izmjena podataka u kartonu...

- Testiranje performansi – kada se sustav u potpunosti integrira moguće je testirati

izranjajuća svojstva poput performansi i pouzdanosti. Moraju biti dizajnirani tako

da pokažu da sustav radi zadatke u predviđenom vremenu. Testno opterećenje

sustava bi trebalo što više nalikovati stvarnom. Stress testing je vrsta testiranja

performansi kada se sustav namjerno preoptereti kako bi se testiralo ponašanje u

slučaju greške.

25

3.4.3 Korisničko testiranje

Faza u testnim procesima u kojoj korisnik sudjeluje i daje savjete o testiranju sustava.

Korisničko testiranje je neophodno čak i kada se provede opsežno testiranje sustava i

verzije za objavu. Utjecaji stvarne radne okoline korisnika imaju velik efekt na pouzdanost,

performanse, iskoristivost i robusnost sustava a to se ne može replicirati u testnoj okolini.

Vrste korisničkog testiranja:

- Alfa testiranje – Korisnici softvera rade s razvojnim timom kako bi testirali sustav

tamo gdje se on razvija.

o Korisnici upućuju na probleme koji su promakli razvojnom timu.

o Koristi se kod razvoja softvera koji se prodaje na CD ili DVD-u.

- Beta testiranje – Korisnici softvera eksperimentiraju s objavljenom verzijom i

prijavljuju probleme razvojnom timu.

o Najčešće se koristi za produkte koji se koriste u različitim okolinama, jer

razvojni tim ne može testirati sve moguće slučajeve.

- Test prihvaćanja – Korisnici testiraju sustav kako bi vidjeli zadovoljava li njihove

potrebe i mogu li ga primijeniti u svojoj okolini. Uglavnom se radi za sustave po

narudžbi.

Proces testa prihvaćanja

Postoji šest faza u procesu testa prihvaćanja:

- Definiranje kriterija za prihvat – Ova faza bi se trebala dogoditi rano u procesu prije

nego se potpiše ugovor. Trebaju biti dio ugovora, što nije uvijek moguće u praksi

jer možda ne postoji detaljna specifikacija zahtjeva ili je došlo do velike promjene

zahtjeva u toku razvoja.

- Planiranje – Donosi se odluka o resursima, vremenu i budžetu namijenjenom za

test. Pravi se raspored testiranja. Definiraju se rizici u procesu testiranja (pad

sustava, loše performanse).

- Stvaranje – Kada se definiraju kriteriji za prihvat rade se testovi koji ih provjeravaju.

Cilj je provjera svih funkcionalnih i ne-funkcionalnih ali je u praksi teško definirati

objektivne kriterije prolaznosti testa.

- Pokretanje– Dogovoreni testovi prihvaćanja se pokreću na sustavu (idealno u

stvarnoj radnoj okolini). Najčešće se ne može automatizirati jer u testiranju

sudjeluju i krajnji korisnici (može biti potrebna njihova obuka).

26

- Pregovor o rezultatima testa – Malo je vjerojatno da će svi definirani testovi proći i

da neće biti nikakvih problema. Ttada razvojni tim i kupac trebaju donijeti odluku

je li sustav dovoljno dobar da se krene s korištenjem i što napraviti u vezi otkrivenih

problema.

- Odbijanje/prihvat sustava – Sastanak razvojnog tima i kupca na kojem se donosi

odluka prihvaća li se sustav ili ne. Ukoliko sustav nije dovoljno dobar, razvojni tim

ispravlja identificirane probleme. Test prihvaćanja se u tom slučaju ponovo

ponavlja.

Agilne metode i testiranje prihvaćanja

Kod Agilnih metoda ko što je XP test prihvaćanja ima potpuno drugo značenje. Korisnik

je dio razvojnog tima (radi kao alfa tester) i kreira zahtjeve u obliku korisničkih priča,

definira testove na osnovu kojih se donosi odluka podržava li sustav korisničke priče.

Testovi su automatizirani i razvoj ide dalje tek kada prođu svi testovi. Ne postoji odvojeni

proces testa prihvaćanja. Glavni problem je koliko kvalitetno obavlja posao predstavnik

klijenata koji pomaže u radu razvojnom timu.