poglavlje 5: održavanje i evolucijaweb.studenti.math.pmf.unizg.hr/~manger/si/si-5.pdf ·...

Poglavlje 5:

Održavanje i evolucija

Sastavio: Robert Manger

15.01.2021

Sveučilište u Zagrebu

PMF – Matematički odsjek

SOFTVERSKO INŽENJERSTVO

Predavanja 2020/2021

O čemu je riječ u Poglavlju 5

• Nakon puštanja u upotrebu, softverski sustav mora se i dalje mijenjati. Promjene su nužne da bi se držao korak s: – novim korisničkim zahtjevima,

– promjenama poslovnog okruženja,

– napretkom hardvera ...

• U sljedećim potpoglavljima: – govorimo općenito o dva osnovna načina mijenjanja

softvera (održavanje, evolucija).

– Detaljnije proučavamo organizirani proces održavanja (upravljanje konfiguracijom).

– Bavimo se specifičnom problematikom mijenjanja zastarjelog (baštinjenog) softvera.

SI-5 SOFTVERSKO INŽENJERSTVO 2

Sadržaj Poglavlja 5

5.1. Općenito o održavanju i evoluciji

5.2. Upravljanje konfiguracijom

5.3. Baštinjeni softver i njegovo mijenjanje


Općenito o održavanju i evoluciji


• Proces mijenjanja softvera nazivamo održavanje odnosno evolucija. - Održavanje je planirani rutinski dio procesa koji

se sastoji od manje radikalnih promjena,

- Evolucija je dio procesa s nepredvidivim elementima koji može dovesti do bitnih promjena u arhitekturi softvera i korištenoj tehnologiji.

• U odjeljcima koji slijede govorimo o:- Razlikama između pojedinih vidova mijenjanja

softvera.

- Vrstama i dinamici održavanja, cijeni održavanja.

- Održavanju unutar agilnih metoda razvoja softvera.

Strategije mijenjanja softvera (1)

• Prema autoru Warren-u postoje tri strategije:– Održavanje softvera. Promjene se rade zato da bi se

držao korak s (promijenjenim) zahtjevima.• Mijenja se funkcionalnost, no struktura uglavnom ostaje ista.

– Arhitekturna transformacija. Značajna promjena arhit. • Npr. sustav se iz mainframe arhitekture prebacuje u

distribuiranu arhitekturu s klijentima i poslužiteljima.

• Funkcionalnost se može ili ne mora promijeniti.

– Softversko reinženjerstvo. Sustav se transformira u

oblik koji se lakše može razumjeti i dokumentirati, te

obrađivati raspoloživim alatima. • Npr. programski kod se automatski prebacuje iz jednog

(zastarjelog) programskog jezika u drugi (suvremeni).

• Ne dodaje se nikakva nova funkcionalnost, nema velike

promjene u arhitekturi. SI-5 SOFTVERSKO INŽENJERSTVO 5


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



• Arhitekturna transformacija i softversko re-

inženjerstvo jednokratni su i radikalni zahvati.

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


Vrste i dinamika održavanja sw (1)

• Održavanje se sastoji od mijenjanja postojećih

dijelova softvera te dodavanja novih dijelova,

bez bitnog narušavanja postojeće arhitekture.

• S obzirom na karakter promjena razlikujemo:– Korekcijsko održavanje. Ispravljaju se uočene

pogreške.

– Adaptacijsko održavanje. Obavlja se prilagodba na

novu platformu.

– Perfekcijsko održavanje. Implementiraju se novi

funkcionalni ili ne-funkcionalni zahtjevi.

– Preventivno održavanje. Povećava se pouzdanost

softvera ili njegova prikladnost za daljnje održavanje.


Vrste i dinamika održavanja sw (2)

• Autori Lehman i Belady objavili su empirijska

istraživanja dinamike održavanja softvera. Ona

sugeriraju da vrijede Lehman-ovi „zakoni“.– Nužnost mijenjanja. Softver koji se zaista koristi u

stvarnom svijetu nužno se mora mijenjati jer u

protivnom ubrzo postaje neupotrebljiv.

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

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


Cijena održavanja softvera (1)

• Ukupna cijena održavanja softvera dostiže i prelazi cijenu njegovog polaznog razvoja.– Cijenu održavanja možemo smanjiti 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.


Manje kvalitetan

razvoj

Jeftinije održavanje

Kvalitetniji razvoj

Skuplje održavanjesustav 1

sustav 2

cijena

Cijena održavanja softvera (2)

• Faktori koji utječu na cijenu održavanja.

1. Cjelovitost polazne specifikacije.

2. Dobrota oblikovanja.

3. Način implementacije.

4. Stupanj verificiranosti.

5. Stupanj dokumentiranosti.

6. Način upravljanja konfiguracijom.

7. Starost softvera.

8. Svojstva aplikacijske domene.

9. Stabilnost razvojnog tima.

10.Stabilnost platforme. SI-5 SOFTVERSKO INŽENJERSTVO 11

Održavanje unutar agilnih metoda (1)

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



• Metoda XP odlikuje se osobinama koje su

zanimljive i korisne sa stanovišta održavanja.– Korisničke priče, koje prvo služe za opis 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 daje velik broj 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.SI-5 SOFTVERSKO INŽENJERSTVO 13


• Poteškoće u agilnim metodama mogu nastupiti

onda kad se originalnim razvojem softvera bavio

jedan tim, a održavanje se prepušta nekom

drugom timu. Problematične situacije:

– Ako je razvojni tim koristio agilni pristup, a tim za

održavanje nije tome vičan pa želi raditi na klasičan

način. Tada će timu za održavanje nedostajati

detaljna dokumentacija sustava.

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


Upravljanje konfiguracijom

• Kao rezultat održavanja, nastaju brojne verzije

sustava.

• Svaka verzija može se promatrati kao nešto

drukčija konfiguracija sastavnih dijelova.

• Da bismo mogli izaći na kraj sa svim tim

konfiguracijama, potreban nam je posebna

aktivnost: upravljanje konfiguracijom.

• U ovom potpoglavlju:

– opisat ćemo svrhu upravljanja konfiguracijom te

njegovu podjelu na pod-aktivnosti.

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


Svrha upravljanja konfiguracijom (1)

• Upravljanje konfiguracijom (configuration

management) je organizirani skup pravila,

postupaka i alata kojima se kontrolira mijenjanje

softvera i evidentiraju se njegove različite verzije.

• Upravljanje konfiguracijom potrebno je kod velikih

sustava gdje postoji velik broj različitih verzija

koje su istovremeno u razvoju ili u upotrebi.

• Osim evidencije o promjenama i verzijama,

sustav za upravljanje konfiguracijom mora

također omogućiti timski rad (možda dislociranih)

programera, tako da oni mogu istovremeno raditi

svoje promjene bez da jedan drugom smetaju. SI-5 SOFTVERSKO INŽENJERSTVO 17

Svrha upravljanja konfiguracijom (2)

• Kad se u upravljanju konfiguracijom 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;

– počnemo mijenjati krivu verziju;

– krivu verziju isporučimo korisnicima;

– zaboravimo gdje je pohranjen izvorni kod za neku

određenu komponentu.


Pod-aktivnosti kod upravljanja konf (1)

• Upravljanje konfiguracijom uključuje sljedeće

pod-aktivnosti.

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

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



• Upravljanje konfiguracijom uključuje sljedeće

pod-aktivnosti (nastavak).

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

– Upravljanje izdanjima. Vodi se evidencija o

izdanjima, dakle verzijama sustava koje su dane

korisnicima na upotrebu. Odlučuje se o objavi novog

izdanja, pa se zatim softver priprema za isporuku

korisnicima.



• Pod-aktivnosti su u bliskoj vezi i nemoguće ih je

sasvim razdvojiti. 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 upravljanja

verzijama koje kažu od koji se dijelova ta određena

verzija sastoji.

– S obzirom da su izdanja sustava samo neke od

verzija, upravljanje izdanjima opet se oslanja na

upravljanje verzijama.



• Veze

između

pod-

aktivnosti:


Verzije dijelova

Zahtjevi za promjenama

Gradnja sustava

Upravljanje izdanjima

Upravljanje promjenama

Verzije sustava

Izdanja sustava

Upravljanje verzijama


• Kod velikih sustava, pod-aktivnosti se odvijaju na

strog i formalan način, uz pomoć odgovarajućih

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,

• način 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.SI-5 SOFTVERSKO INŽENJERSTVO 23


• Kod malih sustava ili agilnih metoda, pod-

aktivnosti se mogu odvijati na implicitan ili manje

formalan način. Na primjer kod metode XP:

– Korisnici su neposredno uključeni u planiranje novih

verzija, što predstavlja jedan vid neposrednog

upravljanja promjenama.

– Naglasak je na stalnom mijenjanju više-manje samo

jedne (zadnje) verzije sustava, što pojednostavnjuje

upravljanje verzijama i gradnju sustava.

– Korisnicima se redovito svaki tjedan isporučuje nova

verzija sustava, što znači da nema potrebe za

zasebnim upravljanjem izdanjima.


Upravljanje promjenama (1)

• Upravljanje promjenama treba osigurati da se:

– promjene sustava odvijaju na kontrolirani način,

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

– identificiranjem dijelova sustava koje treba

promijeniti.


Upravljanje

promje-

nama (2)

• Jedan

od

mogućih

modela

tog

procesa


Pošalji zahtjev

valjan

Zahtjevi za

promjenama

Provjeri zahtjev

Zatvori zahtjev

Registriraj zahtjev

nevaljan

nije prošao

Testiranje softvera

Zatvori zahtjev

Promjena softvera

prošao

Procjena opsega i cijene

Analiza implemen-

tacije

odob-reno

Odobravanje promjene

Zatvori zahtjev

Poslovna procjena

nije odobreno

Podrška korisnicima

Razvoj i održavanje

Odbor za upravljanje promjenama

Korisnik


• Upravljanje promjenama počinje kad korisnik

pošalje zahtjev za promjenom, na primjer:

– izvještaj o bug-u s opisom simptoma, ili

– zahtjev za dodatnom funkcionalnošću.

• Zahtjev za promjenom oblikuje se

ispunjavanjem elektroničkog obrasca.

– Korisnik ispunjava samo neka polja.

– U postupku obrade zahtjeva te donošenja odluke

odgovorne osobe ispunjavaju dodatna polja.


Upra-

vljanje

promje-

nama

(4)

• Primjer

djelomično

ispunjenog

obrasca


Zahtjev za promjenom

Projekt: Središnji informacijski sustav visokih učilišta

Broj zahtjeva: 328/15

Osoba koja traži promjenu: R. Manger

Datum postavljanja zahtjeva: 19.06.2015.

Opis tražene promjene: Na listi nastavnika učilišta trebalo bi bolje biti uočljivo

zvanje nastavnika (docent, izvanredni profesor, redoviti profesor itd.).

Osoba koja je analizirala promjenu: M. Mauher

Datum analize: 21.06.2015.

Komponente koje promjena pogađa: NastavniciListaPrikaz, ZvanjeAzuriranje

Vezane komponente: ZaposleniciDB

Procjena opsega promjene: Može se relativno jednostavno implementirati

promjenom boje prikaza ovisno o zvanju nastavnika. Mora se dodati tablica koja

povezuje zvanje s bojom. Nisu potrebne promjene u vezanim komponentama.

Procjena cijene promjene: 3 radna sata programera

Odluka CCB: Promjena se prihvaća i treba biti implementira u Izdanju 1.2

Datum odluke CCB: 26.06.2015.

Prioritet promjene: Srednji

Osoba koja je implementirala promjenu:

Datum implementiranja:


• Nakon što je zahtjev bio poslan, 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 već je bio prijavljen.

• Riječ o nesporazumu o tome što sustav treba raditi.

• Zahtijeva funkcionalnost koja je već implementirana no

korisnik to ne zna.

U ovakvim slučajevima, zahtjev se zatvara, a u

obrazac se 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 zahtjeva je tehnička

procjena opsega i cijene tražene promjene. – To radi tim za razvoj i održavanje softvera.

– Proučava se utjecaj promjene na ostatak sustava.

– Ako jedna promjena zahtijeva i niz promjena na drugim

mjestima, to će povećati njezinu cijenu.

• Zatim posebna grupa odlučuje je li promjena

svrsishodna i isplativa s poslovnog stanovišta.

– Grupa se zove odbor za upravljanje promjenama (CCB);

ona razmatra netrivijalne promjene i postavlja 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.SI-5 SOFTVERSKO INŽENJERSTVO 30


• Faktori koje treba uzeti u obzir kod odobravanja

ili neodobravanja promjene:

– Posljedice neimplementiranja promjene.

– Korisnost od promjene.

– Broj korisnika kojih se tiče promjena.

– Cijena implementiranja promjene.

– Razdoblje proteklo od posljednjeg izdanja.

• Zadnji dio upravljanja promjenama je implemen-

tacija 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.SI-5 SOFTVERSKO INŽENJERSTVO 31


• Kad razvojni tim mijenja neki dio softvera,

potrebno je o tome voditi evidenciju.

– Uobičajeni način je povijest promjena u obliku

standardiziranog komentara na početku izvornog

programskog koda. Primjer:


// Sredisnji informacijski sustav visokih ucilista

//

// UCILISTE/ZaposleniciDB

//

// Klasa: NastavniciListaPrikaz

// Autor: M. Mauher

// Datum stvaranja: 13.11.2013

//

// Povijest promjena

// Verzija Programer Datum Promjena Razlog

// 1.0 Z. Culic 15.01.2014. Dodano zaglavlje Zahtjev 531/13

// 1.1 M. Mauher 03.09.2014. Novo polje Zahtjev 211/14


• U agilnim metodama poput XP, upravljanje

promjenama nije u tolikoj mjeri formalizirano. – Korisnici su uključeni u odlučivanje hoće li neka

promjena biti implementirana i s kojim prioritetom.

– 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: Bugzilla, služi za prijavljivanje problema sa

sustavima otvorenog koda.

– Koriste se i složeniji no općenitiji alati za praćenje

tijeka dokumenata (workflow management tools).SI-5 SOFTVERSKO INŽENJERSTVO 33

Upravljanje verzijama (1)

• Upravljanje verzijama je središnja pod-

aktivnost unutar upravljanja konfiguracijom

– Na nju se naslanjaju sve ostale pod-aktivnosti.

– Riječ je o evidentiranju i praćenju različitih

verzija dijelova sustava te različitih verzija

samog sustava.

– Omogućeno je da više programera istovremeno

mijenjaju isti softver a da pritom jedan drugom

ne smetaju.



• Uobičajena engleska terminologija vezana uz

verzije sustava i dijelova.– 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.

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.SI-5 SOFTVERSKO INŽENJERSTVO 35


• Primjer situacije gdje treba pamtiti

više verzija sustava i dijelova.


A

Codeline (A)

A1.1 A1.2 A1.3

B

Codeline (B)

B1.1 B1.2

C

Codeline (C)

C1.1 C1.2 C1.3

L1

Biblioteke i vanjske komponente

L2 L3 Ex1

A1.2 B1.1 C1.4

L1 L3 Ex1

Baseline – V1

A1.3 B1.2 C1.3

L2 L3 Ex2

Baseline – V2

Mainline

C1.4

Ex2


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

• Upravljanje verzijama ostvaruje se uz pomoć

alata koji se nazivaju version management

tools ili version control systems.

– Najpoznatiji primjeri su RCS, CVS, Subversion i Git.



• Alati obično imaju sljedeće mogućnosti.– Identifikacija verzija i izdanja. Svakoj verziji se kod

pohranjivanja u repozitorij alata pridružuje identifikator.

– Kompaktna pohrana. Da bi se uštedilo na prostoru,

verzije istog dijela softvera koje se neznatno razlikuju

pohranjuju se na kompaktan način.

– Bilježenje povijesti promjena. Bilježi se svaka

promjena na nekom dijelu softvera. Te bilješke služe

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.SI-5 SOFTVERSKO INŽENJERSTVO 38


• Primjer za kompaktnu pohranu verzija. – Umjesto da se čuva cjelovita kopija svake verzije,

čuva se samo zadnja verzija te liste razlika

(takozvane delte) između susjednih verzija.


Verzija 1.0 Verzija 1.1

Izvorni tekst za V1.3

Verzija 1.2 Verzija 1.3

D3D2D1

Niz verzija

Način pohranjivanja

Datum stvaranja


• Nesmetani istovremeni rad više programera.– Da bi izvršio promjene, programer „vadi“ (check-out)

dijelove iz repozitorija i kopira ih u svoj radni prostor.

– Nakon promjena, programer „vraća“ (check-in)

promijenjene dijelove iz svog prostora u repozitorij.

SI-5 40

check_in

X Y

C

Radni prostor 2

C1.2

X Y Z

check_out

Sustav za upravljanje verzijama

C1.1

A B C

A B

C

Radni prostor 1

check_incheck_out

Ana Branko

Upravljanje verzijama (8)• Posljedica nezavisnog mijenjanja istog dijela softvera je

da se codeline može granati i spajati. – Umjesto linearnog niza verzija postoji više grana.

– Koji put je potrebno napraviti naknadno spajanje grana, to jest

stvoriti novu verziju koja uključuje sve promjene.

– Spajanje se obično ne može napraviti automatski već programer

mora ručno prilagoditi obje verzije.

SI-5 41

Codeline 3

V3.0 V3.1

V2.0

Codeline 2

V2.1

V1.5

<branch>

V2.2

V2.3

V1.0

Codeline 1

V1.1 V1.2

<merge>

<branch>

V1.3 V1.4

V3.2

Gradnja sustava (1)

• Gradnja je proces prevođenja i povezivanja

dijelova sustava, biblioteka i konfiguracijskih dat.

• 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. Pritom on

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

– Za pronalaženje tih verzija koristi se ista specifikacija

pisana u konfiguracijskom jeziku koje je prije služila za

opis i identifikaciju odgovarajućeg baseline-a. SI-5 SOFTVERSKO INŽENJERSTVO 42

Gradnja sustava (2)

• Suradnja alata za gradnju i alata za upravljanje

verzijama


check_in

Izvršivi sustav

Ciljna platforma

Upravljanje verzijama i gradnja

Sustav za upravljanje verzijama

Poslužitelj za gradnju

Razvojni alati

Privatni radni prostor

Razvojni sustav Ciljni sustav

check_outcheck_out

Gradnja sustava (3)• Gradnja sustava složeni je proces budući da su u

njega uključene tri platforme.– Platforma za razvoj na kojoj programer mijenja i testira

programski kod (obično radna stanica).

– Platforma na kojoj rade alat za upravljanje verzijama i

alat za gradnju (obično mrežni poslužitelj).

– Ciljna platforma na kojoj će se izvršavati izgrađeni

sustav (na primjer mobitel ili procesor u perilici rublja).

• Za gradnju nije dovoljan samo izvorni kod

programa, nego su također potrebne:– biblioteke potprograma,

– datoteke s podacima, konfiguracijske datoteke,

– zbirke testova,

– prevodioci (compiler-i) i povezivači (linker-i).SI-5 SOFTVERSKO INŽENJERSTVO 44

Gradnja sustava (4)

• Detaljniji prikaz rada alata za gradnju


Datoteke s podatcima

Biblioteke

Automatizirani sustav za gradnju

Prevoditelji i povezivači

Izvršivi ciljni sustav

Rezultati testova

Datoteke s izvornim kodom

Konfigu-racijske datoteke

Izvršivi testovi

Gradnja sustava (5)• Od suvremenog alata za gradnju očekuje se da

ima sljedeće osobine.– Rad s konfiguracijskim datotekama. Konfiguracijski jezik

treba biti onaj isti koji je služio za opis baseline-a.

– Suradnja s alatom za upravljanje verzijama. Tražene

verzije dijelova vade se iz repozitorija alata za verzije.

– Štedljivo prevođenje i povezivanje. Izbjegavaju se pre-

vođenja dijelova koji se nisu mijenjali od zadnje gradnje.

– Automatsko testiranje. Ispravnost sagrađenog programa

provjerava se pokretanjem alata za testiranje.

– Izvještavanje. Stvara se izvještaj o uspjehu ili neuspjehu

postupka gradnje, te o izvršenim testovima.

– Stvaranje dokumentacije. Generiraju se release notes

za izgrađeni program te stranice s uputama.


Gradnja sustava (6)

• Izbjegavanje nepotrebnog prevođenja zahtijeva

ispravno uparivanje izvornih i object datoteka.

– Alat treba 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. Postoje dvije vrste signatura.

– Vremenski žig (timestamp). Signatura bilo koje

datoteke je datum i vrijeme njene zadnje promjene.

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


Gradnja sustava (7)

• Signatura zasnovana na kontrolnom zbroju

podržava rad s više verzija izvornih datoteka i

više verzija pripadnih object datoteka.

• Konkretni primjeri alata za gradnju.– UNIX-ov make.

• Koristi skripte za gradnju koje se zovu make-files.

• Izbjegava nepotrebna prevođenja (vremenski žigovi).

• Ne može odjednom raditi s više verzija.

• Po današnjim kriterijima već je zastario.

– Neki od novijih alata:• Apache Ant,

• MS Build,

• Rational ClearMake.


Upravljanje izdanjima (1)

• Verzija sustava koja se daje korisnicima naziva

se izdanje. Postoje dvije vrste izdanja.

– Veliko izdanje (major release). Donosi značajnu novu

funkcionalnost. Obično se naplaćuje korisnicima.

– Malo izdanje (minor release). Popravlja greške iz

prethodnog izdanja. Obično se šalje korisnicima kao

update bez naplate.

• Upravljanje izdanjima sastoji se 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.SI-5 SOFTVERSKO INŽENJERSTVO 49


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

– Promjena u platformi.

– Lehmanovi zakoni.

– Držanje koraka s konkurencijom.

– Zahtjevi marketinga.

– Korisnički zahtjevi.

– Ritam izdavanja.



• Priprema izdanja za isporuku korisnicima sastoji

se od opremanja softvera pratećim sadržajima.

Osim samog izvršivog programa, u izdanju se

pojavljuju se sljedeći prateći sadržaji.– Konfiguracijske datoteke koje definiraju kako se

dijelovi sustava trebaju instalirati na ciljanoj platformi.

– Datoteke s podatcima, 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.SI-5 SOFTVERSKO INŽENJERSTVO 51


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


Baštinjeni softver i njegovo mijenjanje


• U velikim organizacijama postoje takozvani baštinjeni (legacy) sustavi.

− To je softver koji je u tehnološkom smislu zastario.

− Održavanje mu je izuzetno skupo, koji put i nemoguće.

− No organizacija ga se ne može tek tako odreći jer joj je on neophodan za svakodnevno funkcioniranje.

• Izlaz iz ove situacije nastoji se pronaći u jednokratnim radikalnim zahvatima:

− softversko reinženjerstvo,

− arhitekturna transformacija.

• U nastavku opisujemo osobine baštinjenog softvera, a zatim govorimo o radikalnim zahvatima.

Građa i osobine baštinjenog sust (1)

• Razvijen je prije 20-30 godina, kasnije je mijenjan.

• U originalnom razvoju koristila se neka od

funkcionalno-orijentiranih metoda.

• Sastoji se od više programa i zajedničkih

podataka. Podaci se čuvaju u datotekama.

• Program unutar sustava sastoji se od funkcija koje

komuniciraju preko parametara i globalnih varijab.

• Opća organizacija je s skladu s modelom „ulaz-

obrada-izlaz“.


Građa i osobine baštinjenog sust (2)

• Implementiran je u zastarjelom programskom

jeziku koji današnji programeri ne razumiju te za

koji više nema prevoditelja.

• Dokumentacija je dijelom izgubljena ili neažurna.

Jedina dokumentacija je izvorni kod. Ili je čak i

izvorni kod izgubljen ali postoji izvršiva verzija.

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


Softversko reinženjerstvo (1)

• Cilj je poboljšati strukturu sustava te ga dovesti u

oblik koji je suvremeniji i razumljiviji.

• Time se smanjuje cijena daljnjeg održavanja.

• Razlika u odnosu na „obično“ softversko inž:


Specifikacija sustava

Bolje strukturirani i razumljiviji

sustav

Novi sustavOblikovanje i

implementacija

Razumijevanje i transformacija

Postojeći sustav

obično softversko inženjerstvo

softversko re-inženjerstvo


• Reinženjerstvo uključuje sljedeće podaktivnosti.

– Prevođenje izvornog koda. Automatska (uglavnom)

konverzija programa iz zastarjelog u suvremeni jezik.

– Reverzno inženjerstvo. Reproduciranje dizajna i

specifikacije sustava na osnovi programskog koda.

– Poboljšanje strukture programa. Npr. zamjena kontrolnih konstrukcija poput goto s ekvivalentnim while i if.

– Modularizacija programa. Reorganizacija izvornog koda,

tako da dijelovi koji su u međusobnoj vezi budu zajedno.

– Podatkovno reinženjerstvo. Npr. modifikacija svih

programa tako da umjesto vlastitih datoteka koriste

zajedničku bazu podataka.SI-5 SOFTVERSKO INŽENJERSTVO 58


• Moguć slijed podaktivnosti unutar reinženjerstva:


Originalni program

Strukturirani program

Dokumentacija programa

Reverzno inženjerstvo

Podatkovno re-inženjerstvo

Modularizacija programa

Reorganizirani podaci

Modularizirani program

Originalni podaci

Prevođenje izvornog koda

Poboljšanje strukture programa


• Primjer

poboljšanja

strukture –

program sa

“špageti”

logikom:


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


• Primjer

pobolj-

šanja

strukture –

struktu-

rirani

program


Loop

-- Naredba Get unosi vrijednosti za zadane varijable iz

-- okoline sustava

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 ;


• Primjer

podat-

kovnog

reinže-

njerstva


Datoteka

1

Datoteka

2Datoteka

3

Datoteka

4Datoteka

5

Datoteka

6

Program 1 Program 2 Program 3

Program 4 Program 5 Program 6 Program 7

Sustav za

upravljanje

bazom

podataka

Program 3 Program 4 Program 5 Program 6

Program 2

Program 1

Program 7

Logički i

fizički modeli

podataka

postaje

Arhitekturna transformacija (1)

• Nakon reinženjerstva, baštinjeni softver obično

se dalje podvrgava arhitekturnoj transformaciji.


Baštinjeni

sustav(središnje računalo)

(terminali)

• Tipični

baštinjeni

sustav je

centralizirani

sustav za rad

na mainframe

računalu i

tekstualnim

terminalima.


• Najčešći cilj arhitekturne transformacije je

prelazak na arhitekturu klijent-poslužitelj:


Jezgra

baštinjenog

sustava

(mrežni poslužitelj)

(mreža)

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

dijelovi baštinjenog sustava)


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

danas očekuju grafičko sučelje i laganu interakciju

sa sustavom.

– Distribuirani pristup sustavu. Organizacije su sve

više fizički distribuirane, pa računalni sustavi moraju

biti dostupni s raznih mjesta i s raznih vrsta opreme.



• Kod planiranja arhitekturne transformacije,

korisno je zamišljati da se naš polazni

baštinjeni sustav sastoji od slojeva:


Prezentacija

Validacija podataka

Kontrola interakcije

Aplikacijski servisi

Baza podataka

» korisničko sučelje


• Postoje razni načini distribuiranja sustava, razlikuju

se po načinu kako su slojevi raspoređeni između

poslužitelja i klijenata.

• Spektar mogućnosti:


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)


• Ako polazni sustav nema jasno odijeljene slojeve,

tada se pribjegava ovakvoj transformaciji:

SI-5 68

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

(mreža)

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

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


• 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 „omotač” (wrapper), koji prevodi

zahtjeve klijenata u interakcije s baštinjenim sustavom.

• Iz perspektive klijenta, omotač izgleda kao poslužitelj.

• Iz perspektive baštinjenog sustava, omotač izgleda kao skup

tekstualnih terminala.



• Arhitektura s omotačem opet dozvoljava razne

varijante:

– Klijent je off-the-shelf emulator terminala. Omotač je

tada nepotreban ili vrlo jednostavan.

– Klijent je web preglednik poput MS IE. Omotač je tada

web server poput Apache, nadopunjen servlet-ima koji

komuniciraju s baštinjenim sustavom i dinamički

generiraju web stranice za klijenta.

– Klijent je program razvijen nekim od alata za razvoj PC

aplikacija, koji koristi sve mogućnosti grafičkog sučelja

na osobnim računalima. Omotač je posebno razvijeni

program.SI-5 SOFTVERSKO INŽENJERSTVO 70

poglavlje 5: održavanje i evolucijaweb.studenti.math.pmf.unizg.hr/~manger/si/si-5.pdf ·...

Documents