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.