Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
1
In
Ŝ
ynieria oprogramowania
Ewolucja oprogramowania i refaktoryzacja
Prowadz
ą
cy:
Bartosz Walter
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
1
In
Ŝ
ynieria oprogramowania
Ewolucja oprogramowania i refaktoryzacja
Prowadz
ą
cy:
Bartosz Walter
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
2
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (2)
Plan wykładów
Zasady skutecznego działania
Specyfikacja wymagań (przypadki uŜycia)
Przeglądy artefaktów (inspekcje Fagana)
Język UML, cz. I
Język UML, cz. II
Metody formalne (sieci Petriego)
Wzorce projektowe
Zarządzanie konfiguracją (CVS)
Wprowadzenie do testowania
Automatyzacja wykonywania testów (jUnit)
Programowanie Ekstremalne
Ewolucja oprogramowania i refaktoryzacja
Wykład dotycz
ą
cy ewolucji oprogramowania i refaktoryzacji jest ostatnim z
cyklu wykładów po
ś
wi
ę
conych in
Ŝ
ynierii oprogramowania. Przedstawia
przyczyn
ę
ci
ą
głe ewolucji oprogramowania, czynników wpływaj
ą
cych na
jej post
ę
p, sposoby piel
ę
gnacji oprogramowania i omawia zwi
ą
zane z ni
ą
koszty.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
3
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (3)
Agenda
1.Geneza ewolucji oprogramowania
2.Prawa Lehmana
3.Rozwój jądra systemu Linux
4.Koszty pielęgnacji
5.Proces pielęgnacji oprogramowania
6.Refaktoryzacja oprogramowania
W trakcie wykładu zostan
ą
omówione nast
ę
puj
ą
ce zagadnienia
•przyczyny ewolucji oprogramowania, z uwzgl
ę
dnieniem czynników
maj
ą
cych na ni
ą
wpływ
•prawa Lehmana, b
ę
d
ą
ce obserwacjami dotycz
ą
cymi sposobów, w jaki
systemy ewoluuj
ą
•rozwój j
ą
dra systemu Linux, które jest kontrprzykładem dla praw
Lehmana, wraz z wyja
ś
nieniem przyczyny ró
Ŝ
nic pomi
ę
dzy nimi
•czynniki wpływaj
ą
ce na koszt piel
ę
gnacji oprogramowania
•typowy proces piel
ę
gnacji oprogramowania
•refaktoryzacja, jako technika obni
Ŝ
enia kosztów piel
ę
gnacji w niektórych
modelach cyklu
Ŝ
ycia programu.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
4
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (4)
Geneza ewolucji oprogramowania
Zmiana
wymaga
ń
Zmiana
ś
rodowiska
Usuwanie
bł
ę
dów
Potrzeba
ulepszania
Zmiana
jest naturalnym procesem
w cyklu rozwojowym oprogramowania i nie mo
Ŝ
na jej unikn
ąć
Zmiana jest naturalnym elementem
ś
wiata – ka
Ŝ
dy jego element ulega
ewolucji. Podobnie jest z oprogramowaniem: w trakcie swojego
Ŝ
ycia
program ewoluuje w odpowiedzi na ró
Ŝ
ne bod
ź
ce i siły, które na niego
wpływaj
ą
:
•wpływ
ś
rodowiska jest najwa
Ŝ
niejsz
ą
sił
ą
, poniewa
Ŝ
program istnieje w
kontek
ś
cie
ś
rodowiska. Ka
Ŝ
da zmiana w
ś
rodowisku wywołuje potrzeb
ę
zmiany oprogramowania
•zmiana wymaga
ń
jest cz
ęś
ciowo powi
ą
zana ze
ś
rodowiskiem, ale tak
Ŝ
e
z niemo
Ŝ
no
ś
ci
ą
pełnego opisania funkcjonalno
ś
ci oprogramowania zanim
ono powstanie i zostanie wdro
Ŝ
one. Dlatego pocz
ą
tkowe wymagania
zmieniaj
ą
si
ę
, a w odpowiedzi na nie – tak
Ŝ
e program
•usuwanie bł
ę
dów jest oczywist
ą
składow
ą
cyklu
Ŝ
ycia ka
Ŝ
dego programu.
Bł
ę
dy maj
ą
ró
Ŝ
n
ą
przyczyn
ę
, od nie
ś
cisło
ś
ci w specyfikacji wymaga
ń
po
bł
ę
dy implementacyjne, ale zawsze skutkuj
ą
ni
Ŝ
sz
ą
postrzegan
ą
jako
ś
ci
ą
programu
•potrzeba ulepszania programu jest niejako wewn
ę
trznym d
ąŜ
eniem do
doskonało
ś
ci. Ulepszanie nie oznacza tutaj poprawy funkcjonalno
ś
ci, ale
wła
ś
nie pozafunkcjonalnych atrybutów systemu.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
5
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (5)
Waga piel
ę
gnacji oprogramowania
0%
10%
20%
30%
40%
50%
60%
70%
1950
1960
1970
1980
1990
2000
2010
2020
Rok
U
d
z
ia
ł
p
ro
je
k
tó
w
p
ie
l
ę
g
n
a
c
y
jn
y
c
h
Capers Jones (1998)
Aby uzmysłowi
ć
sobie istot
ę
procesu piel
ę
gnacji oprogramowania, warto
przeanalizowa
ć
powy
Ŝ
szy wykres, przedstawiaj
ą
cy dotychczasowy i
prognozowany udział przedsi
ę
wzi
ęć
piel
ę
gnacyjnych w stosunku do
wszystkich przedsi
ę
wzi
ęć
zwi
ą
zanych z oprogramowaniem. Wynika z
niego,
Ŝ
e udział liczby przedsi
ę
wzi
ęć
informatycznych, które dotycz
ą
jedynie piel
ę
gnacji istniej
ą
cego oprogramowania, stale ro
ś
nie, z ok. 10%
w latach 50-tych, do ok. 60% obecnie. Trend ten, cho
ć
w mniejszym
nasileniu, zostanie utrzymany w najbli
Ŝ
szych latach i w roku 2020
osi
ą
gnie ok 67%
Wykres mo
Ŝ
na interpretowa
ć
w ten sposób,
Ŝ
e obecnie rozwój nowego
oprogramowania wymaga znacznie mniejszych nakładów, ni
Ŝ
piel
ę
gnacja
ju
Ŝ
istniej
ą
cego. Wskazuje to na rosn
ą
c
ą
wag
ę
piel
ę
gnacji jako fazy w
cyklu
Ŝ
ycia programu.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
6
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (6)
Waga piel
ę
gnacji oprogramowania cd.
Prawo Moore'a
wydajno
ść
procesora
zwi
ę
ksza si
ę
wykładniczo
Oprogramowanie nie
osi
ą
ga nawet liniowego
wzrostu..
Kolejny przykład dowodz
ą
cy wzrostu wagi piel
ę
gnacji programów dotyczy
znanego prawa Moore'a, które mówi,
Ŝ
e wydajno
ść
procesorów
dost
ę
pnych na rynku podwaja si
ę
ś
rednio co osiemna
ś
cie miesi
ę
cy. Ta
wykładnicza zale
Ŝ
no
ść
w zasadzie sprawdza si
ę
od dłu
Ŝ
szego czasu,
cho
ć
mówi si
ę
tak
Ŝ
e o kresie mo
Ŝ
liwo
ś
ci technologii opartych na krzemie,
który zmieni t
ę
zasad
ę
.
Jednak tworzenie oprogramowania o zło
Ŝ
ono
ś
ci wzrastaj
ą
cej w
podobnym tempie jest niemo
Ŝ
liwe; co wi
ę
cej, nawet znacznie mniej
ambitny cel, jakim jest liniowy wzrost rozmiaru programów, tak
Ŝ
e nie
został osi
ą
gni
ę
ty. To oznacza,
Ŝ
e oprogramowanie w swoim rozwoju
napotyka na istotn
ą
przeszkod
ę
, która nie istnieje w przypadku sprz
ę
tu.
T
ą
przeszkod
ą
jest problem z zarz
ą
dzaniem zło
Ŝ
ono
ś
ci
ą
i procesami
starzenia si
ę
oprogramowania.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
7
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (7)
Ewolucja a piel
ę
gnacja
Ewolucja oprogramowania
(ang. software evolution) to
proces zmian zachodz
ą
cych w oprogramowaniu w czasie
jego
Ŝ
ycia.
Piel
ę
gnacja oprogramowania
(ang. software
maintenance) to czynno
ś
ci modyfikuj
ą
ce program
po jego
dostarczeniu i wdro
Ŝ
eniu
. Cele:
• poprawa bł
ę
dów
• poprawa wydajno
ś
ci lub innych atrybutów programu
• adaptacja produktu do zmian w
ś
rodowisku operac.
IEEE Standard for Software Maintenance No. 1219 (1993)
Poniewa
Ŝ
dot
ą
d zamiennie pojawiały si
ę
poj
ę
cia ewolucji oprogramowania
i jego piel
ę
gnacji, dlatego warto bli
Ŝ
ej im si
ę
przyjrze
ć
i okre
ś
li
ć
je
precyzyjniej.
Ewolucja oprogramowania jest procesem jego rozwoju sterowanym
zmianami wymaga
ń
, popraw
ą
bł
ę
dów czy te
Ŝ
rozwojem sprz
ę
tu. Ewolucja
jest nieunikniona: oprogramowanie ewoluuje, poniewa
Ŝ
to le
Ŝ
y w jego
naturze.
Natomiast piel
ę
gnacja to zaplanowany proces, który słu
Ŝ
y do
kontrolowania ewolucji i czynników, które na ni
ą
wpływaj
ą
. Piel
ę
gnacja ma
na celu wykrywanie i usuwanie bł
ę
dów, popraw
ę
atrybutów jako
ś
ciowych
działania programu oraz adaptacj
ę
do zmian w nim zachodz
ą
cych.
Poniewa
Ŝ
jednak, w kontek
ś
cie oprogramowania, ewolucja zawsze
wymaga jakiej
ś
formy piel
ę
gnacji, dlatego poj
ę
cia te czasem stosuje si
ę
zamiennie.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
8
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (8)
Piel
ę
gnacja w modelu kaskadowym
wymagania
projektowanie
implementacja
weryfikacja
piel
ę
gnacja
...
dostawca
u
Ŝ
ytkownik
Model kaskadowy rozwoju oprogramowania zakłada,
Ŝ
e kolejne fazy s
ą
realizowane przez dostawc
ę
(producenta) do momentu wdro
Ŝ
enia,
natomiast piel
ę
gnacja programu zaczyna si
ę
wraz z przekazaniem go
u
Ŝ
ytkownikowi. Takie zało
Ŝ
enie bardzo utrudnia przepływ informacji
zwrotnej mi
ę
dzy u
Ŝ
ytkownikiem a dostawc
ą
. W efekcie program przestaje
odpowiada
ć
potrzebom i oczekiwaniom u
Ŝ
ytkownika, natomiast dostawca
nie jest o nich powiadamiany, poniewa
Ŝ
u
Ŝ
ytkownik jest zainteresowany
utrzymaniem systemu w ruchu, nawet za cen
ę
jego piel
ę
gnacji.
Powoduje to mał
ą
efektywno
ść
piel
ę
gnacji realizowanej w modelu
kaskadowym.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
9
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (9)
Klasyfikacja programów a ewolucja
Program typu S (oparty na Specyfikacji)
•
zało
Ŝ
enia: dost
ę
pna jest pełna specyfikacja systemu
•
kryterium jako
ś
ci: zgodno
ść
ze specyfikacj
ą
•
ewolucja: brak (modyfikacja
nowy problem
nowy program)
Program typu P (rozwi
ą
zuj
ą
cy Problem)
•
zało
Ŝ
enia: system w przybli
Ŝ
eniu odtwarza rzeczywisto
ść
•
kryterium jako
ś
ci: akceptowalne rozwi
ą
zanie problemu
•
ewolucja: prawdopodobna – poprawa programu, ewolucja
ś
rodowiska
Program typu E (osadzony w rzEczywisto
ś
ci)
•
zało
Ŝ
enia: system funkcjonuje w rzeczywistym
ś
wiecie
•
kryterium jako
ś
ci: subiektywna ocena u
Ŝ
ytkownika
•
ewolucja: nieunikniona, program i jego
ś
rodowisko nieustannie
oddziałuj
ą
na siebie
W kontek
ś
cie piel
ę
gnacji oprogramowania, Lehman wprowadził prosty
podział programów na trzy kategorie:
•programy typu S, które s
ą
oparte w cało
ś
ci na formalnej specyfikacji i
dlatego nie podlegaj
ą
ewolucji
•programy typu P, które reaguj
ą
na zmiany w
ś
rodowisku i w
akceptowalny sposób dostarczaj
ą
ś
rodków do interakcji z nim
•programy typu E, które s
ą
osadzone w
ś
rodowisku i nieustannie z nim
oddziałuj
ą
, co powoduje potrzeb
ę
ci
ą
głych zmian
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
10
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (10)
Programy typu S
specyfikacja
PROGRAM
rozwiązanie
świat
• pełna i kompletna
specyfikacja
• poprawno
ść
programu
wzgl
ę
dem specyfikacji
• niezale
Ŝ
no
ść
od
ś
rodowiska
• brak ewolucji
• modyfikacja specyfikacji
= nowy problem
zmiana
Programy typu S reprezentuj
ą
teoretyczn
ą
gał
ąź
rozwoju in
Ŝ
ynierii
oprogramowania. Wobec nich zakłada si
ę
,
Ŝ
e powstały na podstawie
pełnej i kompletnej specyfikacji, w której zawarto wszystkie niezb
ę
dne
informacje w sposób jednoznaczny i niesprzeczny. Przyjmuje si
ę
zało
Ŝ
enie,
Ŝ
e specyfikacja odpowiada niezmiennym potrzebom
u
Ŝ
ytkownika, a zatem jego udział w pracach nad systemem nie jest
konieczny. Jedyn
ą
podstaw
ą
do tworzenia programu, a nast
ę
pnie jego
weryfikacji jest wła
ś
nie specyfikacja. Wszelkie cechy, które
oprogramowanie posiada, a które nie zostały uwzgl
ę
dnione w specyfikacji,
s
ą
ignorowane, poniewa
Ŝ
z punktu widzenia specyfikacji nie istniej
ą
.
W takim modelu proces ewolucyjny w zasadzie nie wyst
ę
puje, poniewa
Ŝ
wszelkie
Ŝą
dania zmian w oprogramowaniu, niezale
Ŝ
nie od ich natury i
ź
ródła, powoduj
ą
stworzenie nowej specyfikacji, której implementacj
ą
jest
zupełnie nowy program.
Oczywi
ś
cie, model ten jest rzadko spotykany w praktyce: ju
Ŝ
zało
Ŝ
enie o
kompletno
ś
ci i niespójno
ś
ci specyfikacji ogranicza jego stosowalno
ść
jedynie do bardzo małych problemów, zwykle o znaczeniu teoretycznym.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
11
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (11)
Programy typu P
specyfikacja
PROGRAM
rozwiązanie
świat
zmiana
model
• model w przybli
Ŝ
eniu
odtwarza
ś
rodowisko
• produkuj
ą
akceptowalne
rozwi
ą
zanie problemu
• zmiany w
ś
rodowisku
wpływaj
ą
na model
• program ulega ewolucji
naprawczej
Kategori
ą
programów, która w wi
ę
kszym stopniu nawi
ą
zuje do
rzeczywisto
ś
ci rozwoju i ewolucji oprogramowania, s
ą
programy typu P.
Model budowany na podstawie obrazu
ś
rodowiska (
ś
wiata rzeczywistego)
na
ś
laduje pewne cechy tego
ś
rodowiska, ale z natury jest niekompletny.
Niepełno
ść
modelu jednak jest po
Ŝą
dan
ą
cech
ą
, poniewa
Ŝ
pozwala
pomija
ć
nieistotne elementy
ś
rodowiska, a co za tym idzie – stosowa
ć
to
podej
ś
cie do wi
ę
kszych i bardziej zło
Ŝ
onych zada
ń
ni
Ŝ
w przypadku
programów typu S. Na podstawie modelu powstaje specyfikacja (równie
Ŝ
niepełna, z mo
Ŝ
liwymi sprzeczno
ś
ciami), a nast
ę
pnie program. Je
Ŝ
eli w
ś
rodowisku zachodzi zmiana, która wymaga odzwierciedlenia w
programie, wówczas program podlega modyfikacji.
W przypadku programów nale
Ŝą
cych do tej kategorii
ś
rodowisko posiada
wpływ na ewolucj
ę
programu, a sam program jest z natury ułomnym
narz
ę
dziem pozwalaj
ą
cym w przybli
Ŝ
eniu rozwi
ą
zywa
ć
postawiony
problem. Program jest uwa
Ŝ
any za poprawny, je
Ŝ
eli produkuje
akceptowalne (z subiektywnego punktu widzenia u
Ŝ
ytkownika)
rozwi
ą
zania. Zachowanie programu powoduj
ą
ce stworzenie
nieakceptowalnego (z powodu bł
ę
du lub zbyt ubogiej funkcjonalno
ś
ci)
rozwi
ą
zania stanowi podstaw
ę
ewolucji takiego programu.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
12
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (12)
Programy typu E
specyfikacja
PROGRAM
świat
zmiana
model
• system osadzony i
pracuj
ą
cy w
ś
rodowisku
• specyfikacja na podstawie
niedoskonałego modelu
• ci
ą
gła informacja zwrotna
od u
Ŝ
ytkowników
•
ś
wiat i program podlegaj
ą
zmianom wskutek
interakcji mi
ę
dzy sob
ą
Programy typu E odpowiadaj
ą
du
Ŝ
ej grupie rzeczywistych programów,
osadzonych i pracuj
ą
cych przez długi czas w
ś
rodowisku, dla którego
powstały. S
ą
to zwykle du
Ŝ
e systemy, tworzone na zamówienie przez
du
Ŝ
e organizacje wytwarzaj
ą
ce oprogramowanie. Specyfikacja i model s
ą
– podobnie jak w przypadku programów typu P – z natury niepełne i mog
ą
posiada
ć
bł
ę
dy lub luki. Jednak najwi
ę
ksza ró
Ŝ
nica polega na integracji
programu ze
ś
rodowiskiem, co oznacza,
Ŝ
e oba elementy na siebie
nieustannie oddziałuj
ą
. W ten sposób zmiana w
ś
rodowisku natychmiast
oddziałuje na program, wywieraj
ą
c potrzeb
ę
zmiany tak
Ŝ
e w nim.
Powoduje to niemal nieustanny napływ informacji zwrotnej od
u
Ŝ
ytkowników systemu, co pozwala na wprowadzanie zmian
najistotniejszych z ich punktu widzenia.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
13
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (13)
"Prawa" Lehmana
"Prawa" Lehmana
1.
Prawo nieustannej zmiany
2.
Prawo wzrastaj
ą
cej
zło
Ŝ
ono
ś
ci
3.
Prawo samoregulacji
4.
Prawo organizacyjnej
stabilno
ś
ci
5.
Prawo zachowania
przyzwyczaje
ń
6.
Prawo ci
ą
głego wzrostu
7.
Prawo spadku jako
ś
ci
8.
Prawo przyrostowego
rozwoju
•
Oparte na obserwacjach rozwoju
kilku du
Ŝ
ych systemów (m.in. IBM
OS/360)
•
Dotycz
ą
du
Ŝ
ych systemów (typu E)
tworzonych na zamówienie w
du
Ŝ
ych organizacjach
•
Obserwacje cz
ęś
ciowo
potwierdzone przez wyniki projektów
z serii FEAST
•
Niesprawdzone w innych typach
oprogramowania (S i P)
•
Raczej obserwacje lub hipotezy ni
Ŝ
prawa
Na podstawie tej klasyfikacji M. Lehman, pocz
ą
wszy od roku 1968,
zaproponował osiem praw dotycz
ą
cych natury ewolucji oprogramowania.
Kolejne prawa pojawiały si
ę
w dłu
Ŝ
szych odst
ę
pach czasu, a
Ŝ
do lat 90-
tych XX wieku. Prawa te zostały opracowane nie na podstawie analizy
statystycznej czy metod formalnego dowodzenia, lecz na podstawie
obserwacji ewolucji kilku du
Ŝ
ych systemów informatycznych (klasycznym
przykładem był IBM OS/360). To spowodowało krytyk
ę
u
Ŝ
ytego przez
Lehmana poj
ę
cia 'prawo', skoro jego obserwacje dotyczyły kilku arbitralnie
wybranych systemów. Wyniki te zostały ponownie zbadane w serii
projektów FEAST, i nazwa 'prawa Lehmana' utrzymała si
ę
.
Warto pami
ę
ta
ć
,
Ŝ
e prawa Lehmana dotycz
ą
programów typu E – du
Ŝ
ych,
wielokrotnie modyfikowanych systemów, które ewoluuj
ą
przez dłu
Ŝ
szy
okres czasu. Jak dot
ą
d brak jest potwierdzenia stosowalno
ś
ci tych praw
dla innych typów programów.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
14
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (14)
Prawo nieustannej zmiany
Program stosowany w rzeczywistym
ś
rodowisku musi by
ć
stale do niego adaptowany
. W przeciwnym przypadku
b
ę
dzie stopniowo coraz mniej u
Ŝ
yteczny.
Prawo to przypomina zasady rz
ą
dz
ą
ce
ś
wiatem natury: organizm
umieszczony w okre
ś
lonym
ś
rodowisku dostosowuje si
ę
do niego lub
ginie. W przypadku oprogramowania sytuacja jest nieco bardziej zło
Ŝ
ona:
potrzeba zmian wynika nie z samego programu, ale z informacji zwrotnej
pochodz
ą
cej z samego
ś
rodowiska. To
Ŝą
dania zmian funkcjonalnych
powoduj
ą
konieczno
ść
modyfikacji (poprawy bł
ę
du, rozszerzenia
funkcjonalnego etc.) oprogramowania.
Istnieje te
Ŝ
dodatkowy czynnik: program posługuje si
ę
pewnym modelem
rzeczywisto
ś
ci, z któr
ą
współpracuje. Im bardziej model ten nie odpowiada
faktycznemu stanowi, tym bardziej konieczne staje si
ę
dostosowanie
modelu do zmieniaj
ą
cej si
ę
rzeczywisto
ś
ci.
Je
Ŝ
eli d
ąŜ
enie do zmian zostanie w pewien sposób zahamowane,
wówczas w miar
ę
upływu czasu oprogramowanie b
ę
dzie w coraz
mniejszym stopniu odpowiadało potrzebom
ś
rodowiska, a co za tym idzie
- postrzegane jako coraz mniej u
Ŝ
yteczne.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
15
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (15)
Prawo wzrastaj
ą
cej zło
Ŝ
ono
ś
ci
Wraz z ewolucj
ą
oprogramowania jego
struktura staje
si
ę
coraz bardziej zło
Ŝ
ona
.
Piel
ę
gnacja i upraszczanie struktury wymagaj
ą
dodatkowych nakładów.
Drugie prawo Lehmana opisuje zjawisko znane w wielu dziedzinach fizyki:
zwi
ę
kszanie nieuporz
ą
dkowania (entropii) w miar
ę
upływu czasu.
Wprowadzanie zmian do oprogramowania (nazywanych cz
ę
sto
progresywnymi) zwykle narusza pierwotn
ą
struktur
ę
programu, a
kumulacja zmian tylko ten proces nasila. Liczba powi
ą
za
ń
i interakcji
pomi
ę
dzy ró
Ŝ
nymi modułami w systemie zwi
ę
ksza si
ę
, co utrudnia
zrozumienie go, a tak
Ŝ
e jego dalsze modyfikacje.
Alternatyw
ą
jest poniesienie dodatkowych nakładów w trakcie piel
ę
gnacji,
po
ś
wi
ę
conych na czynno
ś
ci antyregresywne: upraszczanie struktury i
lepsze wkomponowanie wprowadzanych zmian w istniej
ą
ce
oprogramowanie.
Równowaga pomi
ę
dzy czynno
ś
ciami progresywnymi a regresywnymi
zale
Ŝ
y od ilo
ś
ci i rodzaju informacji zwrotnej płyn
ą
cej ze
ś
rodowiska:
inaczej s
ą
obsługiwane
Ŝą
dania zwi
ą
zane z napraw
ą
bł
ę
dów, a inaczej z
rozszerzeniami funkcjonalnymi.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
16
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (16)
Prawo samoregulacji
Ewolucja oprogramowania jest samoreguluj
ą
cym
procesem
o rozkładzie atrybutów procesu i produktu
bliskim rozkładowi normalnemu.
Podstawowe
atrybuty procesu ewolucji pozostaj
ą
stałe
dla ka
Ŝ
dego wydania.
Proces ewolucji jest wypadkow
ą
sił obecnych w
ś
rodowisku oraz reakcji
na nie. Z uwagi na liczno
ść
tych sił, na ró
Ŝ
nym poziomie i o ró
Ŝ
nym
nat
ęŜ
eniu, wiele obserwacji dokonanych na istniej
ą
cym oprogramowaniu
wskazuje,
Ŝ
e ich suma posiada rozkład normalny. Oznacza to,
Ŝ
e taki
system sterowany informacj
ą
zwrotn
ą
płyn
ą
c
ą
ze
ś
rodowiska ma
wła
ś
ciwo
ś
ci samoreguluj
ą
ce.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
17
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (17)
Rozwój IBM OS/360
0
2000
4000
6000
8000
0
5
10
15
20
25
30
wydanie
lic
z
b
a
m
o
d
u
łó
w
Prawo organizacyjnej stabilno
ś
ci
Tempo rozwoju oprogramowania
w całym jego cyklu
Ŝ
ycia jest
stałe
, bez wzgl
ę
du na dost
ę
pno
ść
zasobów,
je
Ŝ
eli podczas jego piel
ę
gnacji nie wykorzystano
wła
ś
ciwie informacji zwrotnej.
Lehman (1968)
Prawo to jest szczególne, poniewa
Ŝ
opisuje obserwacj
ę
sprzeczn
ą
z
intuicj
ą
. Powszechnie przyjmuje si
ę
,
Ŝ
e wydajno
ść
pracy zale
Ŝ
y od jej
organizacji i decyzji zarz
ą
dczych na ró
Ŝ
nych szczeblach.
Tymczasem w przypadku oprogramowania (typu E) tempo jego rozwoju w
fazie piel
ę
gnacji jest w przybli
Ŝ
eniu stałe i nie jest zwi
ą
zane z ilo
ś
ci
ą
dost
ę
pnych zasobów. Brooks w swojej ksi
ąŜ
ce "Mityczny osobomi
ę
si
ą
c"
wskazuje nawet przykłady przedsi
ę
wzi
ęć
programistycznych, w których
zwi
ę
kszanie zasobów prowadzi do zmniejszenia wydajno
ś
ci i wydłu
Ŝ
enia
harmonogramu prac z uwagi na bardziej zło
Ŝ
on
ą
komunikacj
ę
.
Dane zebrane przez Lehmana wskazuj
ą
,
Ŝ
e tempo rozwoju ka
Ŝ
dego
systemu na pewnym etapie stabilizuje si
ę
na stałym poziomie. Wykres
przedstawia najbardziej znany przykład, na podstawie którego Lehman
sformułował swoje prawa: tempo rozwoju systemu IBM OS/360. Do
wydania 19 tempo wzrostu jest w przybli
Ŝ
eniu stałe, natomiast chaotyczne
zachowanie w ostatnich wydaniach jest interpretowane jako efekt zbyt
du
Ŝ
ej ilo
ś
ci informacji zwrotnej wprowadzonej do wydania 20.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
18
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (18)
Prawo zachowania przyzwyczaje
ń
W dłu
Ŝ
szej perspektywie,
rozmiar kolejnych wyda
ń
systemu jest statystycznie niezmienny
. Przyswojenie
nowych funkcji systemu wymaga czasu.
Znajomo
ść
celów realizowanych przez oprogramowanie jest jednym z
czynników wpływaj
ą
cych na jego rozwój. Zbyt du
Ŝ
a liczba zmian
zawartych w wydaniu powoduje,
Ŝ
e u
Ŝ
ytkownicy nie s
ą
w stanie tych
zmian przyswoi
ć
i opanowa
ć
, czyli w praktyce nie korzystaj
ą
z dodanej
funkcjonalno
ś
ci. Powoduje to poczucie chaosu i nadmiaru informacji. Im
wi
ę
ksza funkcjonalno
ść
jest zwi
ą
zana z kolejnymi wydaniami programu,
tym trudniej jego odbiorcom zapozna
ć
si
ę
ze zmianami i wykorzysta
ć
je.
W ten sposób tempo rozwoju zale
Ŝ
y od stopnia przyswojenia wiedzy o
wprowadzonych zmianach przez ka
Ŝ
dego z u
Ŝ
ytkowników.
Ponadto, du
Ŝ
a liczba zmian to du
Ŝ
a liczba potencjalnych bł
ę
dów, które
nast
ę
pnie b
ę
d
ą
wymagały kolejnego, czysto naprawczego wydania
programu.
Dane zgromadzone przez Lehmana wskazuj
ą
,
Ŝ
e zale
Ŝ
no
ść
mi
ę
dzy liczb
ą
nowych funkcji a czasem potrzebnym do ich przyswojenia nie jest liniowa.
Prawdopodobnie istniej
ą
pewne progi funkcjonalno
ś
ci dostarczanej w
ka
Ŝ
dym wydaniu, powy
Ŝ
ej których konieczne staje si
ę
zmodyfikowanie
zachowania programu.
Prawo to nazywa si
ę
prawem zachowania przyzwyczaje
ń
, poniewa
Ŝ
nawyki zwi
ą
zane z obsług
ą
oprogramowania stanowi
ą
bardzo wyrazisty i
intuicyjny przykład czynnika ograniczaj
ą
cego tempo rozwoju
oprogramowania.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
19
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (19)
Prawo ci
ą
głego wzrostu
Funkcjonalno
ść
oprogramowania musi
rosn
ąć
, aby
satysfakcja
odbiorców systemu pozostała
na tym
samym poziomie
Prawo szóste jest zbli
Ŝ
one do prawa pierwszego, cho
ć
dotycz
ą
one nieco
innego zjawiska. Opisuje ono nowe, niezale
Ŝ
ne
ź
ródło zmian w
oprogramowaniu.
Zakłada si
ę
zwykle,
Ŝ
e w momencie powstawania programu jego
specyfikacja zawiera definicje wszystkich wymaga
ń
. W trakcie rozwoju, z
powodu ogranicze
ń
bud
Ŝ
etowych i organizacyjnych, s
ą
ograniczane one
do pewnego ich podzbioru. Wymagania, które nie zostały zawarte w tym
podzbiorze, s
ą
wykluczane z dalszych prac lub odraczane na przyszło
ść
.
Jednak w pewnym momencie funkcje, które nie zostały
zaimplementowane, stan
ą
si
ę
utrudnieniem w pracy z systemem,
zmniejszaj
ą
c jego u
Ŝ
yteczno
ść
. W ten sposób powstaje potrzeba zmian
funkcjonalnych obejmuj
ą
cych wymagania pomini
ę
te we wcze
ś
niejszych
fazach. Implementacja tych wymaga
ń
ma za zadanie utrzyma
ć
poziom
satysfakcji u
Ŝ
ytkowników z systemu na dotychczasowym poziomie.
Piel
ę
gnacja oprogramowania zakłada wi
ę
c nieustanny rozwój
funkcjonalny. Co ciekawe, w innych dziedzinach in
Ŝ
ynierii, np.
budownictwie l
ą
dowym, sytuacja taka nie wyst
ę
puje lub jej waga jest
znacznie mniejsza: od mostu nikt nie wymaga, aby w miar
ę
upływu czasu
był on wyposa
Ŝ
ony w dodatkowe mo
Ŝ
liwo
ś
ci, np. podnoszenie i
opuszczanie prz
ę
sła w celu przepuszczenia ruchu wodnego lub
zwi
ę
kszenie no
ś
no
ś
ci.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
20
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (20)
Prawo spadku jako
ś
ci
Jako
ść
oprogramowania spada
, o ile nie jest ono
dostosowywane do zmian zachodz
ą
cych w swoim
ś
rodowisku operacyjnym.
Jako
ść
oprogramowania jest postrzegana z dwóch punktów widzenia: z
zewn
ą
trz, przez u
Ŝ
ytkownika, i z wewn
ą
trz, przez programist
ę
. Oba
punkty widzenia dotycz
ą
innych problemów: u
Ŝ
ytkownika interesuj
ą
bł
ę
dy
i funkcjonalno
ść
, natomiast programist
ę
tak
Ŝ
e wewn
ę
trzna struktura
programu. Jako
ść
w obu tych aspektach ulega degradacji w miar
ę
upływu
czasu.
Jako
ść
zewn
ę
trzna dotyczy liczby i rodzaju znajdowanych bł
ę
dów oraz
funkcji oferowanych przez system. System pracuj
ą
cy w satysfakcjonuj
ą
cy
sposób przez dłu
Ŝ
szy czas tak
Ŝ
e jest nara
Ŝ
ony na wykrycie w nim bł
ę
du.
W
ś
ród innych powodów mo
Ŝ
na wymieni
ć
zwi
ę
kszaj
ą
ce si
ę
z upływem
czasu potrzeby i oczekiwania u
Ŝ
ytkowników, ich przyzwyczajenia, a tak
Ŝ
e
ewoluuj
ą
ce standardy jako
ś
ciowe oprogramowania, szczególnie przy
pojawiaj
ą
cej si
ę
na rynku konkurencji. W oczach u
Ŝ
ytkownika program,
który nie nad
ąŜ
a za post
ę
pem, staje si
ę
przestarzały i mniej u
Ŝ
yteczny,
nawet je
Ŝ
eli jego funkcjonalno
ść
nie ulega zmianie.
Jako
ść
wewn
ę
trzna jest bardziej obiektywn
ą
miar
ą
zło
Ŝ
ono
ś
ci struktury
programu. Pokazuje ona po
ś
rednio, jaka jest zdolno
ść
programu do
piel
ę
gnacji. Zmiany, wprowadzane wraz z ewolucj
ą
, zwykle nie s
ą
prawidłowo integrowane z istniej
ą
c
ą
struktur
ą
i j
ą
pogarszaj
ą
.
Lehman wskazuje,
Ŝ
e jedynie rygorystyczna piel
ę
gnacja jest w stanie
zapobiec spadkowi jako
ś
ci oprogramowania w miar
ę
upływu czasu.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
21
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (21)
Prawo przyrostowego rozwoju
Procesy ewolucyjne oprogramowania s
ą
wielopoziomowe, posiadaj
ą
natur
ę
iteracyjn
ą
i wymagaj
ą
informacji z wielu punktów widzenia
.
Wykorzystanie informacji zwrotnej pozwala osi
ą
gn
ąć
istotn
ą
popraw
ę
procesu ewolucji.
Rozwój IBM OS/360
0
2000
4000
6000
8000
0
5
10
15
20
25
30
wydanie
lic
z
b
a
m
o
d
u
łó
w
Prawo to jest uogólnieniem i podsumowaniem pozostałych praw, i nie jest
oparte na nowych obserwacjach, a raczej dostarcza nowych wniosków
wynikaj
ą
cych ze znanych ju
Ŝ
faktów. Stwierdza,
Ŝ
e ewolucja
oprogramowania jest zło
Ŝ
onym, wielopoziomowym i uwzgl
ę
dniaj
ą
cym
wiele punktów widzenia systemem z informacj
ą
zwrotn
ą
. Przykładem tego
wniosku jest analiza przedstawionego wcze
ś
niej wykresu prezentuj
ą
cego
rozwój systemu IBM OS/360. Stabilny rozwój w pocz
ą
tkowym okresie
wynika ze stabilnej pracy systemu sterowanego informacj
ą
zwrotn
ą
.
Załamanie i niestabilno
ść
wzrostu po 19 wydaniu wynikała z próby
nadmiernego rozwoju systemu w wydaniu 20, co spowodowało
konieczno
ść
wprowadzenia poprawek w kolejnych wydaniach. Zaburzyło
to trend wzrostu systemu.
Rola informacji zwrotnej znana była ju
Ŝ
wcze
ś
niej, jednak dopiero teraz
została ona wyra
Ŝ
ona tak dobitnie. Lehman podkre
ś
la,
Ŝ
e zaskakuj
ą
cy dla
niego jest fakt, i
Ŝ
została ona zinterpretowana w ten sposób dopiero po
kilkunastu latach bada
ń
.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
22
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (22)
Wnioski z praw Lehmana
• Oprogramowanie, aby pozostało u
Ŝ
yteczne, musi
ewoluowa
ć
• Jako
ść
oprogramowania (zdolno
ść
do ewolucji)
pogarsza si
ę
z upływem czasu
• Rosn
ą
ca zło
Ŝ
ono
ść
oprogramowania w pewnym
momencie znacznie utrudnia dalszy rozwój systemu
• Tempo rozwoju oprogramowania jest w najlepszym
przypadku stałe i nie zale
Ŝ
y od sposobu zarz
ą
dzania
Prawa Lehmana pokazuj
ą
,
Ŝ
e oprogramowanie, które ma by
ć
u
Ŝ
yteczne
przez dłu
Ŝ
szy czas, musi ewoluowa
ć
. W przeciwnym razie jego jako
ść
wewn
ę
trzna (struktura kodu) oraz zewn
ę
trzna (postrzegana przez
u
Ŝ
ytkowników) pogarsza si
ę
, a
Ŝ
oprogramowanie ulega wyparciu z rynku.
Istotnym problemem jest wzrost zło
Ŝ
ono
ś
ci oprogramowania w miar
ę
rozwoju programu. Istnieje punkt nasycenia, poza którym dalszy rozwój
jest bardzo trudny lub nawet niemo
Ŝ
liwy, o ile nie wcze
ś
niej stosowano
technik zarz
ą
dzania zło
Ŝ
ono
ś
ci
ą
i nie restrukturyzowano programu na
bie
Ŝą
co.
Jednym z silniejszych twierdze
ń
Lehmana jest ograniczenie tempa
rozwoju i wskazanie,
Ŝ
e nie zale
Ŝ
y ono od podejmowanych decyzji
zarz
ą
dczych.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
23
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (23)
Rozwój j
ą
dra Linuxa
0
200 000
400 000
600 000
800 000
1 000 000
1 200 000
1 400 000
1 600 000
1 800 000
01 1993
06 1994
10 1995
03 1997
07 1998
12 1999
04 2001
L
O
C
LOC, wersja rozwojowa
LOC, wersja stabilna
Godfrey (2000)
Prawa Lehmana nie dotycz
ą
jednak wszystkich rodzajów
oprogramowania.
Na wykresie przedstawiono rozwój j
ą
dra systemu Linux. Pierwsza wersja,
udost
ę
pniona w marcu 1994 roku, składała si
ę
z 487 plików o ł
ą
cznej
długo
ś
ci 165 KLOC. Wersja 2.3.39, opublikowana w styczniu 2000 roku,
obejmowała ju
Ŝ
4854 pliki o ł
ą
cznej długo
ś
ci 2.2 MLOC. Warto jednak
zauwa
Ŝ
y
ć
,
Ŝ
e rozwój systemu, szczególnie w tzw. wersji rozwojowej
nast
ę
pował w tempie szybszym od liniowego, co stanowi zaprzeczenie
czwartego prawa Lehmana. Zatem istnieje mo
Ŝ
liwo
ść
rozwoju systemu
szybszego ni
Ŝ
przewidział to Lehman.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
24
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (24)
Czynniki sukcesu rozwoju j
ą
dra Linuxa
• Proces sterowany informacj
ą
zwrotn
ą
• Modularna architektura (podsystemy, sterowniki)
• Znaczne nakłady na piel
ę
gnacj
ę
kodu i refaktoryzacj
ę
• Zrównoleglony rozwój wielu elementów systemu
• Efekt wzrastaj
ą
cej popularno
ś
ci
• Eksperymentalne cechy a wydania stabilne
• Kultura open source
Jakie czynniki wpływaj
ą
na t
ę
wła
ś
ciwo
ść
Linuxa?
Jest to produkt open source, tworzony jednocze
ś
nie w sposób równoległy
przez wielu programistów. Wymagania s
ą
definiowane na bie
Ŝą
co i
szeregowane wg priorytetów do implementacji w kolejnych wersjach.
Wyst
ę
puje zatem p
ę
tla sprz
ęŜ
enia zwrotnego: program jest rozwijany na
bie
Ŝą
co, zgodnie ze zmianami
ś
rodowiska (jest to potwierdzenie
pierwszego prawa Lehmana). Ponadto znaczne nakłady s
ą
inwestowane
w bie
Ŝą
c
ą
restrukturyzacj
ę
kodu, co pozwala zaoszcz
ę
dzi
ć
znaczne
ś
rodki w pó
ź
niejszych fazach.
Linux jest te
Ŝ
zorganizowany w sposób modularny, dzi
ę
ki czemu mo
Ŝ
liwe
jest tak szerokie zrównoleglenie prac. Znaczna cz
ęść
funkcjonalno
ś
ci jest
zaimplementowana w sterownikach, które s
ą
niezale
Ŝ
ne od samego j
ą
dra.
Linux posiada dwie zasadnicze gał
ę
zie konfiguracji: stabiln
ą
, na której
znajduj
ą
si
ę
elementy przetestowane, o wysokiej wiarygodno
ś
ci, oraz
rozwojow
ą
, zawieraj
ą
c
ą
wszystkie elementy, tak
Ŝ
e te nie do ko
ń
ca
przetestowane. Sukcesywnie elementy z tej ostatniej s
ą
testowane i
przenoszone na gał
ąź
główn
ą
. To rozwój gał
ę
zi rozwojowej –
wielokierunkowy,
Ŝ
ywiołowy – charakteryzuje si
ę
ponadliniowym
wzrostem.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
25
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (25)
Piel
ę
gnacja w modelu spiralnym
wymagania
implementacja
weryfikacja
piel
ę
gnacja
wdro
Ŝ
enie
W modelu spiralnym, odzwierciedlaj
ą
cym ewolucyjn
ą
natur
ę
tworzenia
oprogramowania, piel
ę
gnacja nie jest faz
ą
ko
ń
cz
ą
c
ą
cykl
Ŝ
ycia programu
– jest elementem ka
Ŝ
dego przyrostu funkcjonalnego. Pozwala ona na
lepsze zaimplementowanie nowych wymaga
ń
bez degradacji istniej
ą
cej
struktury oprogramowania.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
26
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (26)
Modele piel
ę
gnacji oprogramowania
•
ostro
Ŝ
ne planowanie i
zarz
ą
dzanie
•
wyczerpuj
ą
ca weryfikacja wersji
•
powolna ewolucja
•
Ŝ
ywiołowy, wielokierunkowy
rozwój
•
du
Ŝ
a liczba poprawek
•
okresowa refaktoryzacja
Raymond (2000)
Zatem mo
Ŝ
na wyró
Ŝ
ni
ć
tak
Ŝ
e inn
ą
klasyfikacj
ę
modeli piel
ę
gnacji
oprogramowania, opart
ą
na obserwacjach E. Raymonda dotycz
ą
cych
metod open source:
•styl budowy katedry: szczegółowo zaplanowany, nie ulegaj
ą
cy łatwo
zmianom i ewolucji, oraz
•styl bazaru,
Ŝ
ywiołowo rozwijaj
ą
cego si
ę
w wielu kierunkach,
charakteryzuj
ą
cy si
ę
wieloma wydaniami i konieczno
ś
ci
ą
okresowej
restrukturyzacji
Szczególnie interesuj
ą
cy jest ten drugi model, reprezentowany m.in. przez
Linuxa, w którym system nieustannie znajduje si
ę
w fazie piel
ę
gnacji.
Wa
Ŝ
ne jest to,
Ŝ
e charakteryzuje si
ę
on wi
ę
kszym tempem wzrostu ni
Ŝ
przewidziane prawami Lehmana, charakterystycznymi dla stylu budowy
katedry. Zatem model ci
ą
głego, wielokierunkowego rozwoju okazuje si
ę
skuteczniejszy ni
Ŝ
model planowanego rozwoju.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
27
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (27)
Pracochłonno
ść
piel
ę
gnacji
Prewencyjna
5%
Naprawcza
20%
Doskonal
ą
ca
50%
Adaptacyjna
25%
Lientz, Swanson (1980)
usuwanie bł
ę
dów
dostosowanie
oprogramowania
do
zmieniaj
ą
cego
si
ę
ś
rodowiska
bez zmiany
funkcjonalno
ś
ci
implementacja
nowych wymaga
ń
inwestycja w
piel
ę
gnowalno
ść
Na piel
ę
gnacj
ę
oprogramowania składaj
ą
si
ę
cztery ró
Ŝ
ne rodzaje
aktywno
ś
ci
•piel
ę
gnacji doskonal
ą
cej (ok. 50%), która ma na celu implementacj
ę
nowych lub zmienionych wymaga
ń
funkcjonalnych
•piel
ę
gnacji adaptacyjnej (ok. 25%), która dostosowuje program do zmian
zachodz
ą
cych w
ś
rodowisku
•piel
ę
gnacji naprawczej (ok. 20%), która słu
Ŝ
y usuwaniu bł
ę
dów z
programu
•piel
ę
gnacji prewencyjnej (ok. 5%), która polega na wewn
ę
trznej
restrukturyzacji programu, co pozwala zmniejszy
ć
koszty piel
ę
gnacji w
przyszło
ś
ci
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
28
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (28)
Koszt piel
ę
gnacji oprogramowania
• Koszt piel
ę
gnacji zwykle jest
wy
Ŝ
szy
od kosztu stworzenia
oprogramowania
– koszt linii kodu w Boeingu: $30, piel
ę
gnacji: $4000 (Boehm, 1985)
• Koszt piel
ę
gnacji
ro
ś
nie
wraz z okresem piel
ę
gnacji
0
50
100
150
200
250
300
Produkt B
Produkt A
Jak ju
Ŝ
wskazano na wst
ę
pie, piel
ę
gnacja jest procesem wymagaj
ą
cym
coraz wi
ę
cej wysiłku i po
ś
wi
ę
cenia wi
ę
kszych zasobów ni
Ŝ
w tworzenie
oprogramowania. Przyjmuje si
ę
,
Ŝ
e koszt piel
ę
gnacji w ka
Ŝ
dym systemie
mo
Ŝ
e by
ć
porównywalny lub wy
Ŝ
szy od kosztu jego stworzenia, w
zale
Ŝ
no
ś
ci od czasu jego piel
ę
gnacji i innych, wymienionych wcze
ś
niej,
czynników. Skrajnym przykładem jest dysproporcja kosztu stworzenia i
piel
ę
gnacji jednej linii kodu w systemie tworzonym przez Boeinga dla Sił
Powietrznych USA: napisanie kosztowało $30, natomiast piel
ę
gnacja
ponad stukrotnie wi
ę
cej! Wynika to z obserwacji,
Ŝ
e roczny koszt
piel
ę
gnacji ro
ś
nie wraz z okresem jej trwania.
Na wykresie przedstawiono przykład dwóch produktów, ró
Ŝ
ni
ą
cych si
ę
kosztem wytworzenia i piel
ę
gnacji. W przypadku produktu A koszt
produkcji był wy
Ŝ
szy ni
Ŝ
produktu B, jednak pozwoliło to ograniczy
ć
koszt
piel
ę
gnacji i w sumie całkowity koszt zwi
ą
zany z programem (ang. total
cost of ownership, TCO).
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
29
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (29)
Model kosztowy Boehma
Przykład
AME = 1.0 x 10% x 125 PM = 12.5 PM
AME = 1.0 x ACT x SDT
AME – roczna pracochłonno
ść
zw. z piel
ę
gnacj
ą
[PM]
ACT – rzeczywista wzgl
ę
dna liczba zmian [%]
SDT – pracochłonno
ść
rozwoju oprogramowania [PM]
Boehm (1981)
pracochłonno
ść
rozwoju
oprogramowania:
125 osobomiesi
ę
cy
rozmiar zmian:
10% kodu
Zaproponowany przez Boehma prosty model kosztowy przewiduje,
Ŝ
e
piel
ę
gnacja oprogramowania jest zwi
ą
zana z wysiłkiem proporcjonalnym
do rozmiaru modyfikowanego kodu. Oznacza to,
Ŝ
e piel
ę
gnacja systemu,
którego koszt budowy wyniósł np. 125 osobomiesi
ę
cy, wyniesie rocznie
tak
ą
cz
ęść
tego kosztu, jaka uległa zmianie w tym okresie (np. dla 10%
b
ę
dzie to 12.5 osobomiesi
ą
ca).
Model ten, wzorowany na COCOMO, mo
Ŝ
e zosta
ć
rozszerzony tak
Ŝ
e o
inne czynniki wpływaj
ą
ce na wysoko
ść
oszacowania. W takim przypadku
czynniki te s
ą
mno
Ŝ
one przez otrzymany wynik.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
30
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (30)
Czynniki wpływaj
ą
ce na koszt piel
ę
gnacji
Czynniki wpływaj
ą
ce na koszt piel
ę
gnacji
• Dziedzina zastosowa
ń
systemu
• Stabilno
ść
personelu piel
ę
gnacyjnego
• Czas
Ŝ
ycia oprogramowania
• Stabilno
ść
sprz
ę
tu
• Jako
ść
kodu i dokumentacji
Czynniki nie wpływaj
ą
ce na koszt piel
ę
gnacji
• Metoda zarz
ą
dzania przedsi
ę
wzi
ę
ciem
• Dost
ę
pno
ść
zasobów
Na koszt piel
ę
gnacji ma wpływ wiele czynników technicznych i
pozatechnicznych.
•Pierwszym z nich jest dziedzina systemu: w przypadku obszarów dobrze
zdefiniowanych, o intuicyjnych wymaganiach, koszt b
ę
dzie ni
Ŝ
szy; w
przypadku dziedzin o wysokiej zmienno
ś
ci wymaga
ń
koszt b
ę
dzie wy
Ŝ
szy.
•Podobny wpływ ma stało
ść
personelu. Szybka rotacja pracowników
powoduje,
Ŝ
e twórca oprogramowania nie zajmuje si
ę
pó
ź
niej jego
piel
ę
gnacj
ą
. Wi
ąŜ
e si
ę
to z dodatkowym kosztem zrozumienia
oprogramowania przez nowego pracownika.
•Wiek oprogramowania równie
Ŝ
obci
ąŜ
a koszt piel
ę
gnacji. Wynika to z
kosztów piel
ę
gnacji sprz
ę
tu, na którym system jest uruchamiany, a tak
Ŝ
e
dotychczasowych zabiegów piel
ę
gnacyjnych, które utrudniaj
ą
wprowadzanie kolejnych zmian. W momencie, gdy koszt piel
ę
gnacji
przekracza koszt stworzenia nowego systemu, dalsza ewolucja jest
ekonomicznie nieuzasadniona.
•Szybki rozwój sprz
ę
tu komputerowego sprzyja potrzebie zmian w
oprogramowaniu. Nowe mo
Ŝ
liwo
ś
ci procesorów s
ą
wykorzystywane przez
nowe aplikacje, wobec czego starsze musz
ą
by
ć
modyfikowane w celu
utrzymania si
ę
na rynku.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
31
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (31)
Czynniki wpływaj
ą
ce na koszt piel
ę
gnacji
Czynniki wpływaj
ą
ce na koszt piel
ę
gnacji
• Dziedzina zastosowa
ń
systemu
• Stabilno
ść
personelu piel
ę
gnacyjnego
• Czas
Ŝ
ycia oprogramowania
• Stabilno
ść
sprz
ę
tu
• Jako
ść
kodu i dokumentacji
Czynniki nie wpływaj
ą
ce na koszt piel
ę
gnacji
• Metoda zarz
ą
dzania przedsi
ę
wzi
ę
ciem
• Dost
ę
pno
ść
zasobów
•Wreszcie, ostatnim czynnikiem jest wewn
ę
trzna jako
ść
oprogramowania
oraz dokumentacji. Program podzielony na moduły, o niewielkiej liczbie
powi
ą
za
ń
, mo
Ŝ
e by
ć
modyfikowany cz
ęś
ciami, bez potrzeby zmiany
pozostałych modułów. Tak
Ŝ
e j
ę
zyk programowania wpływa na koszt
piel
ę
gnacji: j
ę
zyki wysokiego poziomu s
ą
pod tym wzgl
ę
dem ta
ń
sze.
Wyczerpuj
ą
co przetestowany system posiada mniej bł
ę
dów, a co za tym
idzie – wymaga mniejszych nakładów z tym zwi
ą
zanych. Natomiast
aktualna i pełna dokumentacja pozwala cz
ęś
ciowo zrekompensowa
ć
koszty zwi
ą
zane z rotacj
ą
pracowników i szybciej identyfikowa
ć
obszary
wymagaj
ą
ce zmian.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
32
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (32)
In
Ŝ
ynieria ponowna
In
Ŝ
ynieria ponowna (ang. re-engineering)
• proces transformacji istniej
ą
cego
oprogramowania (ang. legacy software) w celu
poprawy jego piel
ę
gnowalno
ś
ci
• ni
Ŝ
sze ryzyko ni
Ŝ
w przypadku budowy nowego
systemu
• opłacalne, je
Ŝ
eli koszt jest ni
Ŝ
szy od kosztu
stworzenia nowego systemu
• stosowane w przypadku cz
ę
sto ewoluuj
ą
cych
fragmentów systemu
In
Ŝ
ynieria ponowna (czyli re-in
Ŝ
ynieria) jest poj
ę
ciem stosowanym w
odniesieniu do piel
ę
gnacji istniej
ą
cych systemów o słabej
piel
ę
gnowalno
ś
ci. Celem jest zwi
ę
kszenie tej zdolno
ś
ci przez zmian
ę
jego
wewn
ę
trznej struktury, aktualizacj
ę
dokumentacji etc. Stosowanie jej
pozwala ograniczy
ć
koszty zwi
ą
zane z piel
ę
gnacj
ą
, a tak
Ŝ
e ryzyko
zwi
ą
zane ze stworzeniem całkowicie nowego oprogramowania.
Oczywi
ś
cie, wi
ąŜ
e si
ę
z tym dodatkowy koszt, jaki nale
Ŝ
y ponie
ść
w fazie
tworzenia programu, jednak jest on rodzajem inwestycji zwracaj
ą
cej si
ę
podczas piel
ę
gnacji. Z uwagi na koszty, warto stosowa
ć
in
Ŝ
ynieri
ę
ponown
ą
, szczególnie w tych fragmentach systemu, które cz
ę
sto
ewoluuj
ą
.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
33
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (33)
Refaktoryzacja
Refaktoryzacja to:
• zmiana wewn
ę
trznej struktury kodu programu
• która zwi
ę
ksza jego czytelno
ść
i obni
Ŝ
a koszt
piel
ę
gnacji
• ale nie zmienia jego obserwowalnego zachowania
void doSth()
void doSth()
Szczególnym przypadkiem in
Ŝ
ynierii ponownej jest refaktoryzacja.
Dotyczy ona tylko zmian zachodz
ą
cych w kodzie programu, a wi
ę
c na
najni
Ŝ
szym poziomie restrukturyzacji.
Poj
ę
cie wywodzi si
ę
od faktoryzacji, czyli przydziału odpowiedzialno
ś
ci do
obiektów. Refaktoryzacja jest zatem ponownym podziałem systemu na
obiekty. Wynika z tego,
Ŝ
e dotyczy głównie paradygmatu obiektowego,
cho
ć
poj
ę
cia tego u
Ŝ
ywa si
ę
tak
Ŝ
e w stosunku do j
ę
zyków strukturalnych
(np. C).
Spo
ś
ród własno
ś
ci refaktoryzacji warto wspomnie
ć
o dwóch
najwa
Ŝ
niejszych: jej celem jest poprawa jako
ś
ci wewn
ę
trznej struktury
kodu, a jednocze
ś
nie nie mo
Ŝ
e ona zmienia
ć
zachowania programu (tzn.
program po przekształceniu zachowuje si
ę
identycznie jak przed zmian
ą
).
Zapewnienie tej ostatniej własno
ś
ci jest najtrudniejszym krokiem
refaktoryzacji.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
34
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (34)
Koszt refaktoryzacji
Refaktoryzacja nie zwi
ę
ksza funkcjonalno
ś
ci
programu, ale kosztuje
• identyfikacja problemu
• przekształcenie kodu
• weryfikacja poprawno
ś
ci
Koszt zale
Ŝ
y od:
• własno
ś
ci j
ę
zyka programowania
• wsparcia ze strony narz
ę
dzi CASE
• natury wykonywanego przekształcenia
• liczby i jako
ś
ci posiadanych testów
Z refaktoryzacj
ą
, podobnie, jak z ka
Ŝ
d
ą
czynno
ś
ci
ą
in
Ŝ
ynierii ponownej,
zwi
ą
zany jest dodatkowy koszt, który nie powoduje wzrostu
funkcjonalno
ś
ci systemu. Dlatego konieczne jest jego ograniczenie
poprzez automatyzacj
ę
lub cz
ęś
ciow
ą
automatyzacj
ę
niektórych
czynno
ś
ci: identyfikacji obszarów kodu wymagaj
ą
cych refaktoryzacji,
samego wykonania przekształcenia, a na ko
ń
cu, weryfikacji jego
poprawno
ś
ci. Nakład ten zale
Ŝ
y od
ś
rodowiska, w którym dokonywana
jest refaktoryzacja: j
ę
zyka programowania, narz
ę
dzi, a tak
Ŝ
e samego
przekształcenia oraz istnienia testów jednostkowych (JUnit), które
ułatwiaj
ą
weryfikacj
ę
poprawno
ś
ci.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
35
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (35)
Przykład
Wył
ą
czenie metody
void scalarProduct(String[] params) {
int[] x = prepareX(params);
int[] y = prepareY(params);
int[] product = computeXY(x, y);
// ...
for (i = 0; i < x.length; i++) {
out.println("X = " + x[i]);
out.println("Y = " + y[i]);
out.println("X * Y = " + product[i]);
}
}
void scalarProduct(String[] params) {
int[] x = prepareX(params);
int[] y = prepareY(params);
int[] product = computeXY(x, y);
// ...
printScalarProduct(x, y, product);
}
void printScalarProduct(int[] x, int[]y,
int[] product) {
for (i = 0; i < x.length; i++) {
out.println("X = " + x[i]);
out.println("Y = " + y[i]);
out.println("X * Y = " + product[i]);
}
}
Przykładem refaktoryzacji jest najprostsze przekształcenie: wył
ą
czenie
metody z kodu. Metoda scalarProduct() wykonuje dwie funkcje: obliczenie
pewnych warto
ś
ci, a nast
ę
pnie ich wy
ś
wietlenie. Celem refaktoryzacji jest
zatem zmniejszenie jej zło
Ŝ
ono
ś
ci poprzez podział. W efekcie, z metody
zostaje wył
ą
czona nowa metoda printScalarProduct(), która zawiera kod
odpowiedzialny za wy
ś
wietlanie wyników. Jest ona wywoływana z
oryginalnej funkcji, przez co wywołanie tej ostatniej powoduje dokładnie te
same efekty co poprzednio.
Analizuj
ą
c to przekształcenie warto zastanowi
ć
si
ę
nad warunkami jego
poprawno
ś
ci. Aby istniała mo
Ŝ
liwo
ść
utworzenia nowej metody, inna o
takiej nazwie nie mo
Ŝ
e ju
Ŝ
istnie
ć
(taki bł
ą
d wykryłby kompilator) ani nie
mo
Ŝ
e by
ć
odziedziczona, co spowodowałoby zmian
ę
zachowania
programu (taki bł
ą
d jest znacznie trudniejszy do wykrycia). Oba te warunki
mo
Ŝ
na zweryfikowa
ć
bez konieczno
ś
ci uruchamiania programu, jedynie
na podstawie analizy jego kodu
ź
ródłowego.
Bartosz Walter
Ewolucja oprogramowania i refaktoryzacja
36
In
Ŝ
ynieria oprogramowania
Ewolucja i refaktoryzacja oprogramowania (36)
Podsumowanie
• Ewolucja oprogramowania jest naturalnym
procesem jego rozwoju
• Istniej
ą
3 typy oprogramowania z punktu widzenia
piel
ę
gnacji
• Prawa Lehmana opisuj
ą
natur
ę
ewolucji
oprogramowania typu E
• Model spiralny i zwinno
ść
pozwalaj
ą
łatwiej
piel
ę
gnowa
ć
oprogramowanie
• Zarz
ą
dzanie zło
Ŝ
ono
ś
ci
ą
poprzez okresow
ą
restrukturyzacj
ę
wspomaga piel
ę
gnacj
ę
• Refaktoryzacja jest inwestycj
ą
pozwalaj
ą
c
ą
ograniczy
ć
koszt piel
ę
gnacji
Podczas wykładu zaprezentowano podstawowe zagadnienia zwi
ą
zane z
ewolucj
ą
i piel
ę
gnacj
ą
oprogramowania. Ewolucja jest procesem
naturalnym i w praktycznych zastosowaniach nie da si
ę
jej unikn
ąć
. Prawa
Lehmana, opisuj
ą
ce natur
ę
ewolucji jednej z kategorii oprogramowania,
pokazuj
ą
,
Ŝ
e programy, które nie ewoluuj
ą
, staj
ą
si
ę
coraz mniej
u
Ŝ
yteczne. Czynnikiem wspomagaj
ą
cym piel
ę
gnacj
ę
jest sterowanie
ewolucj
ą
poprzez informacj
ę
zwrotn
ą
płyn
ą
c
ą
ze
ś
rodowiska. Dlatego
cyklem
Ŝ
ycia szczególnie dobrze wspomagaj
ą
cym t
ę
faz
ę
rozwoju
oprogramowania jest model spiralny.
Koszt zwi
ą
zany z piel
ę
gnacj
ą
zwykle przekracza koszt stworzenia
oprogramowania. Dlatego stosowanie cyklicznej restrukturyzacji pozwala
ograniczy
ć
ten koszt, za cen
ę
dodatkowych nakładów w fazie rozwoju.