Poglavlje 5: O državanje i evolucija Sastavio: Robert Manger 15.01.2021 Sveučilište u Zagrebu PMF – Matematički odsjek SOFTVERSKO INŽENJERSTVO Predavanja 2020/2021
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
SI-5 SOFTVERSKO INŽENJERSTVO 3
Općenito o održavanju i evoluciji
SI-5 SOFTVERSKO INŽENJERSTVO 4
• 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
Strategije mijenjanja softvera (2)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 6
Strategije mijenjanja softvera (3)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 7
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.
SI-5 SOFTVERSKO INŽENJERSTVO 8
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.
SI-5 SOFTVERSKO INŽENJERSTVO 9
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.
SI-5 SOFTVERSKO INŽENJERSTVO 10
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.
SI-5 SOFTVERSKO INŽENJERSTVO 12
Održavanje unutar agilnih metoda (2)
• 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
Održavanje unutar agilnih metoda (3)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 14
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
SI-5 SOFTVERSKO INŽENJERSTVO 15
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.
SI-5 SOFTVERSKO INŽENJERSTVO 16
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.
SI-5 SOFTVERSKO INŽENJERSTVO 18
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.
SI-5 SOFTVERSKO INŽENJERSTVO 19
Pod-aktivnosti kod upravljanja konf (2)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 20
Pod-aktivnosti kod upravljanja konf (3)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 21
Pod-aktivnosti kod upravljanja konf (4)
• Veze
između
pod-
aktivnosti:
SI-5 SOFTVERSKO INŽENJERSTVO 22
Verzije dijelova
Zahtjevi za promjenama
Gradnja sustava
Upravljanje izdanjima
Upravljanje promjenama
Verzije sustava
Izdanja sustava
Upravljanje verzijama
Pod-aktivnosti kod upravljanja konf (5)
• 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
Pod-aktivnosti kod upravljanja konf (6)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 24
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.
SI-5 SOFTVERSKO INŽENJERSTVO 25
Upravljanje
promje-
nama (2)
• Jedan
od
mogućih
modela
tog
procesa
SI-5 SOFTVERSKO INŽENJERSTVO 26
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 (3)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 27
Upra-
vljanje
promje-
nama
(4)
• Primjer
djelomično
ispunjenog
obrasca
SI-5 SOFTVERSKO INŽENJERSTVO 28
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:
Upravljanje promjenama (5)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 29
Upravljanje promjenama (6)
• 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
Upravljanje promjenama (7)
• 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
Upravljanje promjenama (8)
• 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:
SI-5 SOFTVERSKO INŽENJERSTVO 32
// 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
Upravljanje promjenama (9)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 34
Upravljanje verzijama (2)
• 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
Upravljanje verzijama (3)
• Primjer situacije gdje treba pamtiti
više verzija sustava i dijelova.
SI-5 SOFTVERSKO INŽENJERSTVO 36
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
Upravljanje verzijama (4)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 37
Upravljanje verzijama (5)
• 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
Upravljanje verzijama (6)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 39
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
Upravljanje verzijama (7)
• 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
SI-5 SOFTVERSKO INŽENJERSTVO 43
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
SI-5 SOFTVERSKO INŽENJERSTVO 45
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.
SI-5 SOFTVERSKO INŽENJERSTVO 46
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.
SI-5 SOFTVERSKO INŽENJERSTVO 47
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.
SI-5 SOFTVERSKO INŽENJERSTVO 48
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
Upravljanje izdanjima (2)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 50
Upravljanje izdanjima (3)
• 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
Upravljanje izdanjima (4)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 52
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
SI-5 SOFTVERSKO INŽENJERSTVO 53
Baštinjeni softver i njegovo mijenjanje
SI-5 SOFTVERSKO INŽENJERSTVO 54
• 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“.
SI-5 SOFTVERSKO INŽENJERSTVO 55
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.
SI-5 SOFTVERSKO INŽENJERSTVO 56
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ž:
SI-5 SOFTVERSKO INŽENJERSTVO 57
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
Softversko reinženjerstvo (2)
• 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
Softversko reinženjerstvo (3)
• Moguć slijed podaktivnosti unutar reinženjerstva:
SI-5 SOFTVERSKO INŽENJERSTVO 59
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
Softversko reinženjerstvo (4)
• Primjer
poboljšanja
strukture –
program sa
“špageti”
logikom:
SI-5 SOFTVERSKO INŽENJERSTVO 60
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
Softversko reinženjerstvo (5)
• Primjer
pobolj-
šanja
strukture –
struktu-
rirani
program
SI-5 SOFTVERSKO INŽENJERSTVO 61
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 ;
Softversko reinženjerstvo (6)
• Primjer
podat-
kovnog
reinže-
njerstva
SI-5 SOFTVERSKO INŽENJERSTVO 62
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.
SI-5 SOFTVERSKO INŽENJERSTVO 63
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.
Arhitekturna transformacija (2)
• Najčešći cilj arhitekturne transformacije je
prelazak na arhitekturu klijent-poslužitelj:
SI-5 SOFTVERSKO INŽENJERSTVO 64
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)
Arhitekturna transformacija (3)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 65
Arhitekturna transformacija (4)
• Kod planiranja arhitekturne transformacije,
korisno je zamišljati da se naš polazni
baštinjeni sustav sastoji od slojeva:
SI-5 SOFTVERSKO INŽENJERSTVO 66
Prezentacija
Validacija podataka
Kontrola interakcije
Aplikacijski servisi
Baza podataka
» korisničko sučelje
Arhitekturna transformacija (5)
• 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:
SI-5 SOFTVERSKO INŽENJERSTVO 67
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)
Arhitekturna transformacija (6)
• 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)
Arhitekturna transformacija (7)
• 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.
SI-5 SOFTVERSKO INŽENJERSTVO 69
Arhitekturna transformacija (8)
• 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