Pobierz artykuł PDF

METODA ESTYMACJI DŁUGO
CI KODU RÓDŁOWEGO NA PODSTAWIE
DIAGRAMÓW STATYCZNYCH UML
MACIEJ STACHURSKI
Politechnika Szczeciska
Streszczenie
Coraz wiksze zapotrzebowanie na coraz bardziej skomplikowane systemy informatyczne sprawia, e potrzeba ich sprawnego wytwarzania staje si coraz waniejszym problemem dla firm realizujcych oprogramowanie. Sporód wielu problemów zarzdzania procesem wytwarzania systemów informatycznych szczególne
znaczenie ma szacowanie, bdce czci planowania. Artykuł ten prezentuje metod
szacowania rozmiaru systemu informatycznego, która moe stanowi doskonałe uzupełnienie istniejcych ju metod, szczególnie tych szacujcych na wyszym poziomie
abstrakcji.
Słowa kluczowe: estymacja rozmiaru systemu informatycznego, estymacja długoci kodu ródłowego, diagramy UML, diagramy klas
1. Wprowadzenie
Cywilizacja ludzka naszych czasów w coraz wikszym stopniu opiera si na rozwizaniach
informatycznych. Stanowi one niemal niewidzialn osnow na której konstruowanie s nierzadko
skomplikowane systemy wspomagajce wszelkie przejawy działalnoci człowieka. Trudno dzisiaj
wyobrazi
sobie sprawne działanie w tak odległych pojciowo od siebie dziedzinach jak medycyna
i bankowo
czy giełda i produkcja samochodów w sytuacji, gdyby nie było rozwiza
informatycznych wspierajcych prac człowieka. Komputery wraz z działajcym na nim
oprogramowaniem wyrczaj nas w tych działaniach, które z natury jest nam, ludziom, najtrudniej
wykonywa
: zadaniach powtarzalnych i mudnych, bo komputer si nie mczy i jest zawsze tak
samo dokładny. W tym kontekcie pojawia si potrzeba, aby konstruowane rozwizania
informatyczne jak najbardziej ułatwiały codzienn prac człowieka w dowolnej dziedzinie ycia.
Zadanie to jest jednym z celów informatyki (ang. computer science), dziedziny nauki i techniki
zajmujcej si przetwarzaniem informacji, w tym technologiami wytwarzania systemów
przetwarzajcych informacje i ich aplikowaniem na platform sprztow jak jest komputer.
cile powizana z informatyk jest inynieria oprogramowania (ang. software engineering) –
dziedzina inynierii systemów zajmujca si wszelkimi aspektami produkcji oprogramowania.
Według innych ródeł inynieria oprogramowania to stosowanie systematycznego,
zdyscyplinowanego i kwantyfikowalnego podejcia do wszelkich aspektów wytwarzania
oprogramowania. Potrzeba zdyscyplinowanego podejcia do procesu wytwarzania
oprogramowania pojawiła si jako rezultat wielu niepowodze na tym polu. Zgodnie z danymi
opublikowanymi przez The Standish Group [1] w roku 2000 tylko 28% projektów
informatycznych zostało zakoczonych pełnym sukcesem. Realizacja pozostałych projektów
oprogramowania została albo zawieszona (23% ogółu) albo została zrealizowana z przekroczeniem
budetu, zaplanowanego czasu realizacji lub z niepełnym zestawem funkcjonalnoci (49%). Mona
148
Maciej Stachurski
Metoda estymacji długoci kodu ródłowego na podstawie diagramów statycznych UML
tutaj zaobserwowa
pewn tendencj wzrostow na przestrzeni ostatnich lat, wykazujc popraw
na polu pełnej realizacji projektów oprogramowania: jest ona interpretowana przez twórców
raportu jako rezultat coraz szerszego stosowania zdyscyplinowanych metod zarzdzania procesem
wytwarzania oprogramowania.
2. Pojcie rozmiaru systemu informatycznego
Pierwszym zadaniem w sekwencji składajcej si na cało
procesu zarzdzania jest
planowanie. Polega ono na decydowaniu o podjciu działa zorientowanych na wywołanie
zjawisk, które nie zaistniałyby samoistnie. Działania te obejmuj midzy innymi proces
wyznaczania oszacowa cech realizowanego przedsiwzicia, takich jak koszt, nakład pracy, czas
realizacji czy charakterystyka wymaganych zasobów. Jedn z kluczowych cech przedsiwzicia
niezalenie od jego charakterystyki jest rozmiar. Właciwie niezalenie od dziedziny dowolna
cecha kadego przedsiwzicia jest w jaki sposób zalena od rozmiaru. Tak te jest w przypadku
realizacji systemów informatycznych: im wikszy jest rozmiar planowanego systemu
informatycznego tym wiksze bd zasoby potrzebne na jego realizacj. Dlatego te jak
najwierniejsze przewidywanie rozmiaru realizowanego systemu informatycznego jest kluczem do
sukcesu jego realizacji.
Oprogramowanie realizujce funkcjonalno
systemów informatycznych jest bytem
abstrakcyjnym i jako takie nie moe by
charakteryzowane przez cechy fizyczne uywane do
opisywania wiata rzeczywistego. Dlatego te ju u zarania informatyki pojawił si problem
definicji rozmiaru oprogramowania. Obecnie uznaje si, e rozmiar oprogramowania ma trzy
podstawowe aspekty [2]:
• aspekt funkcjonalnoci
• aspekt złoonoci
• aspekt długoci
Metryki wyraajce rozmiar oprogramowania w ujciu funkcjonalnym s metrykami
porednimi i abstrakcyjnymi, w przeciwiestwie do linii kodu ródłowego, które s wartociami
bezporednio mierzalnymi (na podstawie analizy kodu ródłowego) i fizycznymi (da si je łatwo
rozpoznawa
). Metryki funkcjonalne s cile powizane z metodami estymacji rozmiaru
funkcjonalnego oprogramowania. We wszystkich metodach s one rozumiane jako liczby, które
odnosz si do zakresu funkcjonalnoci zrealizowanego w ramach systemu informatycznego
bdcego przedmiotem badania. Najpopularniejsz metryk rozmiaru w aspekcie funkcjonalnym s
punkty funkcyjne.
Złoono
jest jednym z podstawowych problemów z jakim musz sobie radzi
niemal
wszystkie systemy informatyczne. Wzrost złoonoci niesie ze sob duo problemów, midzy
innymi utrudnienie percepcji struktury i zachowania systemu, a co za tym idzie wzrost awaryjnoci
i zmniejszenie produktywnoci programistów. Złoono
mona rozpatrywa
w kategoriach
stopnia skomplikowania algorytmów przetwarzania danych (np. liczba cyklomatyczna McCabe’a,
metryki przepływu informacji) i stopnia skomplikowania struktury systemu informatycznego (np.
pakiet metryk obiektowych Chidambera i Kemerera).
Długo
kodu ródłowego jest najprostsz miar rozmiaru oprogramowania widzianego z
punktu widzenia jego twórców. Jest to po prostu całkowita ilo
kodu ródłowego napisanego w
jzykach programowania implementujca funkcjonalno
realizowanego systemu informatycznego.
Najczciej stosowane miary tego aspektu rozmiaru systemu informatycznego to ilo
rónorako
POLSKIE STOWARZYSZENIE ZARZDZANIA WIEDZ
Seria: Studia i Materiały, nr 17, 2008
149
rozumianych linii kodu, metryki Halsteada, liczba tokenów (najmniejszych jednoznacznych
elementów jzyka).
Wanym ródłem danych do metryk stały si diagramy UML. UML (ang. Unified Modeling
Language – zunifikowany jzyk modelowania) to notacja pozwalajca prezentowa
rozmaite
aspekty tworzonego systemu informatycznego w postaci graficznej [6]:
• aspekt struktury (diagramy klas, komponentów, struktur połczonych, obiektów, pakietów)
• aspekt czynnociowy (diagramy przypadków uycia, stanu, czynnoci)
• aspekt interakcji (diagramy sekwencji, komunikacji, przegldu interakcji, uwarunkowa
czasowych)
Diagramy UML s coraz czciej baz z której korzystaj rozmaite metody estymacji rozmiaru
systemu informatycznego przede wszystkim ze wzgldu na ich rozpowszechnienie i coraz
powszechn akceptacj przez organizacje zajmujce si wytwarzaniem oprogramowania
komputerowego. W dzisiejszych czasach diagramy UML s coraz bardziej nieodzownym
elementem wiedzy zespołów projektancko-programistycznych, a szczególnie tych, które tworz
oprogramowanie z wykorzystaniem paradygmatu obiektowego.
3. Metody estymacji rozmiaru systemu informatycznego
Metody estymacji rozmiaru systemu informatycznego mona w ogólnoci podzieli
na dwie
podstawowe grupy:
• metody szacujce w ujciu deklaratywnym
• metody szacujce w ujciu imperatywnym
Pierwsza grupa metod estymacji traktuje system informatyczny jako czarn skrzynk – za
znaczce uwaa tylko te jego elementy, które s widoczne z zewntrz, czyli z punktu widzenia
docelowego uytkownika systemu. Oznacza to, e rozmiar systemu informatycznego oceniany jest
tylko w aspekcie jego funkcjonalnoci. Metody szacujce aspekt funkcjonalny systemu
informatycznego to przede wszystkim wszelkiego rodzaju metody bazujce na koncepcji punktów
funkcyjnych (np. oryginalna metoda punktów funkcyjnych IFPUG, metoda pełnych punktów
funkcyjnych COSMIC-FFP, oparta na diagramach przypadków uycia metoda Karnera),
Przeciwiestwem, a jednoczenie uzupełnieniem ujcia deklaratywnego jest ujcie
imperatywne, według którego system informatyczny charakteryzuje si z punktu widzenia jego
realizacji i struktury wewntrznej. Oznacza to, e w tym ujciu waniejsze s aspekty złoonoci
i długoci kodu ródłowego implementacji systemu informatycznego. Przykładami metod
szacujcych w ujciu imperatywnym s metoda PROBE z Personal Software Process, metoda
Fast&&Serious, metoda Predictive Object Points.
Podział metod estymacji rozmiaru na deklaratywne i imperatywne wie si z ich dostpnoci
w trakcie cyklu ycia systemu informatycznego oraz ze skutecznoci uzyskiwanych przy ich
pomocy oszacowa. Zakładajc wykorzystanie kaskadowego modelu cyklu ycia systemu
informatycznego składajcego si z etapów specyfikowania wymaga, analizy, projektowania,
implementacji i testowania [3], metody deklaratywne, a wic bazujce na opisie funkcjonalnoci,
mona wykorzystywa
poczwszy od etapu analizy. Podczas analizy rozpoczyna si
przygotowywanie szczegółowego opisu funkcjonalnoci na podstawie którego mona dokonywa
wstpnych oszacowa. Rozmaite metody punktów funkcyjnych korzystaj z wyników
150
Maciej Stachurski
Metoda estymacji długoci kodu ródłowego na podstawie diagramów statycznych UML
uzyskiwanych podczas tej fazy pozwalajc na oszacowanie rozmiaru systemu informatycznego na
podstawie iloci i charakteru wej
i wyj
danych, iloci i charakterystyki wewntrznych
i zewntrznych zbiorów danych [4]. Równie na etapie analizy tworzy si diagramy UML
opisujce system w aspekcie funkcjonalnym. S to przede wszystkim diagramy przypadków
uycia, które to w metodzie Karnera wykorzystane s jako podstawowe predyktory pozwalajce na
szacowanie rozmiaru systemu informatycznego w ujciu funkcjonalnym.
Podsumowujc, podstawow zalet deklaratywnych metod estymacji rozmiaru jest to, e mog
by
wykorzystane bardzo wczenie w trakcie cyklu ycia systemu informatycznego. Jest to o tyle
istotne, e skuteczne oszacowania s jednymi z najwaniejszych i najbardziej znaczcych danych
wejciowych dla procesu planowania. Jednoczenie stosowanie metod deklaratywnych jest
potencjalnie ryzykowne, bo ich rezultaty bazuj na niepełnych danych o systemie informatycznym.
Sam opis funkcjonalnoci na pewno stanowi dobr podstaw do oszacowa, ale jest
niewystarczajcy, aby uzyskiwa
dokładne wyniki. Luk t uzupełniaj metody szacujce w ujciu
imperatywnym.
Zakres wykorzystania metod imperatywnych, a wic bazujcych na opisie wewntrznej
struktury systemu informatycznego oraz stosowanych w jego ramach mechanizmów przetwarzania
danych jest wszy ni jest to w przypadku metod deklaratywnych. Szacowanie rozmiaru na
podstawie wewntrznej budowy systemu moliwe jest dopiero podczas etapów zaawansowanej
analizy oraz projektowania. Wynika z tego to, e oszacowania uzyskiwane w wyniku zastosowania
metod imperatywnych mog by
nieco spónione w stosunku do typowych oczekiwa
kierownictwa dotyczcych fundamentalnych kwestii oceny globalnych zasobów potrzebnych do
realizacji całego systemu. Z drugiej jednak strony wyniki działania metod imperatywnych mog
stanowi
znaczce ródło danych dla estymacji zasobów w sensie lokalnym (np. do oszacowania
nakładu pracy potrzebnej na implementacj okrelonego modułu systemu czy te jego cechy).
Metody imperatywne bazuj na pewnym opisie systemu informatycznego cechujcym si
odpowiednim poziomem szczegółowoci. W zalenoci od metody moe to by
albo ogólna
koncepcja systemu informatycznego z wyrónionymi podstawowymi modułami (czste dane
wejciowe dla rozmaitych mniej lub bardziej sformalizowanych metod szacowania bazujcego na
wiedzy eksperta) lub bardziej uszczegółowiony schemat komponentów (np. diagramy klas dla
metod Predictive Object Points i diagramy klas, przypadków uycia, współdziałania, stanów dla
metody Fast&&Serious).
Podsumowujc, metody deklaratywne uzupełnione o metody imperatywne stanowi klucz do
sukcesu wiarygodnych i zgodnych z rzeczywistoci oszacowa, szczególnie jeli spojrzy si na
realizacj systemu informatycznego jako na proces stopniowego uszczegóławiania [5].
4. Załoenia metody estymacji długoci kodu ródłowego
Nowa metoda estymacji rozmiaru systemu informatycznego w aspekcie długoci kodu ródłowego stanowicego jego implementacj powinna spełnia
nastpujce załoenia:
•
•
•
metoda moe by
stosowana tylko do systemów informatycznych realizowanych z wykorzystaniem paradygmatu obiektowego
ródłem danych na podstawie których działa metoda s diagramy UML obrazujce statyczn (strukturaln) stron systemu informatycznego
jednostka oszacowa długoci kodu ródłowego powinna by
jak najbardziej obiektywna
POLSKIE STOWARZYSZENIE ZARZDZANIA WIEDZ
Seria: Studia i Materiały, nr 17, 2008
151
• metoda powinna minimalizowa
udział elementów ocenianych w sposób subiektywny
• uzyskiwane oszacowania powinny cechowa
si błdem wzgldnym ni ±20%
Paradygmat obiektowy jest obecnie jedn z najpopularniejszych koncepcji na których
podstawie budowane jest oprogramowanie. Połczenie cech i zachowa w jeden byt sprawia, e
modelowanie elementów wiata rzeczywistego jest spójniejsze i bardziej naturalne. Cecha ta
sprawiła, e pojawiła si pewna grupa jzyków programowania, które s dedykowane do uycia
z koncepcj obiektowoci (np. Java, C#).
Wymaganie co do uycia diagramów UML jako ródła danych dla modelu szacujcego jest po
czci rezultatem popularnoci modelowania systemów informatycznych z wykorzystaniem
obiektowoci. Diagramy UML zostały stworzone w celu wspomagania procesu tworzenia
oprogramowania w paradygmacie obiektowym, dajc moliwo
zamodelowania go z niemal
kadej perspektywy. Niestety w praktyce okazuje si, e diagramy UML rzadko kiedy s
wykorzystywane w sposób kompletny (tzn. opisujcy cało
systemu informatycznego) i spójny.
Najczstszym sposobem wykorzystania diagramów UML jest ich przygotowanie dla najbardziej
skomplikowanych fragmentów tworzonego systemu informatycznego. Rzadko kiedy wykorzystuje
si równie wszystkie diagramy, zwykle ograniczajc si do diagramów przypadków uycia i klas,
co znaczco ogranicza liczb danych na temat tworzonego systemu jakie mogłyby by
wykorzystane na potrzeby szacowania.
Jednostka miary długoci kodu ródłowego powinna mie
przede wszystkim jasn i spójn
definicj. Nie mona tego powiedzie
np. o iloci linii kodu (LOC – Lines of Code),
najpopularniejszej mierze długoci kodu ródłowego, która w rzeczywistoci mierzy ilo
znaków
koca linii w zbiorze znaków (pliku), która moe by
zupełnie niezalena od długoci kodu
ródłowego. Dlatego te powstały liczne dodatkowe zasady pozwalajce zaklasyfikowa
dany
wiersz znaków jako lini kodu ródłowego (np. wymaganie non-commented, non-blank – niepusta
linia niebdca komentarzem). Dobrym przykładem miary długoci kodu ródłowego o cisłej
definicji moe by
token. Token to pojcie wywodzce si z analizy leksykalnej i oznaczajce
najmniejsz jednostk leksykaln posiadajc okrelone znaczenie. Przykładem tokena jest w
jzykach programowania np. operator przypisania, nawias, identyfikator zmiennej, stała liczbowa,
słowo kluczowe. Token jest jednostk cile zdefiniowan, nie ma tu swobody interpretacji jak to
było w przypadku linii kodu ródłowego LOC. Jednak token jest do pewnego stopnia zaleny od
jzyka programowania, np. połczony operator przypisania i dodawania ‘+=’ jest zdefiniowany w
jzykach C i Java, nie ma go natomiast w jzyku Pascal. Z drugiej jednak strony wikszo
współczenie stosowanych jzyków programowania ma bardzo podobny zestaw podstawowych
tokenów, przynajmniej w sensie znaczeniowym, zatem zaleno
tokena jako miary rozmiaru
systemu informatycznego od jzyka programowania nie jest bardzo dua.
Porównanie skutecznoci liczby linii kodu ródłowego i liczby tokenów jako miary długoci
kodu ródłowego znajduje si poniej.
152
Maciej Stachurski
Metoda estymacji długoci kodu ródłowego na podstawie diagramów statycznych UML
kod ródłowy
for
( int i = 0 ; i < 10 ; ++ i ) {
System . out . println ( i ) ;
długo kodu
[LOC]
długo linii
[token]
długo kodu
[token]
3
15
9
1
25
}
14
1
4
25
System . out . println ( i ) ;
9
}
1
int
i = 0 ;
5
for ( ; i < 10 ; ++ i )
10
{
5
1
26
System . out . println ( i ) ;
9
}
1
Wymaganie dotyczce wyeliminowania elementów subiektywnych jest podyktowana
zamierzeniem wykorzystania metody do automatycznej estymacji długoci kodu ródłowego w
pakietach modelowania UML.
Graniczna warto
błdu wzgldnego na poziomie ±20% została dobrana zgodnie
z panujcymi obecnie standardami w ocenie metod estymacji rozmiaru systemów informatycznych
[9].
for
{
( int
i =0 ;
i < 10 ;
++ i )
5. Propozycja metody estymacji długoci kodu ródłowego
Oprogramowanie budowane z uyciem paradygmatu obiektowego jest konstruowane
z podstawowych elementów konstrukcyjnych, jakim s klasy. Klasa to rodzaj kontenera, łczcy
opis swego stanu (przy pomocy danych zapisanych w atrybutach) oraz opis dozwolonego
zachowaniu (poprzez algorytmy realizujce zmiany tego stanu w ramach metod). Przetwarzanie w
rodowisku obiektowym to cig wywoła metod działajcych w rodowisku definiowanym przez
klas do której metoda naley oraz dostpnych metod innych klas. Uruchomienie metody jest
równoznaczne z rozpoczciem procesu przetwarzania zgodnie z zaimplementowanym w jej ramach
algorytmem. Algorytm wykonuje operacje na danych pochodzcych z nastpujcych ródeł:
• parametrów wywołania metody
• dostpnych atrybutów statycznych i niestatecznych klasy (oraz jej przodków w drzewie
dziedziczenia) do której metoda naley
• rezultatów działania dostpnych metod (z klasy macierzystej, jej przodków oraz dostpnych klas zewntrznych) wywołanych w trakcie procesu przetwarzania
Wyniki działania algorytmu zaimplementowanego w metodzie mog by
zapisywane
w nastpujcych lokalizacjach:
• rezultatach wywołania metody
• dostpnych atrybutach statycznych i niestatecznych klasy (oraz jej przodków w drzewie
dziedziczenia) do której metoda naley
• parametrach dowolnych dostpnych metod (z klasy macierzystej, jej przodków lub dostpnych klas zewntrznych) wywołanych w trakcie procesu przetwarzania
POLSKIE STOWARZYSZENIE ZARZDZANIA WIEDZ
Seria: Studia i Materiały, nr 17, 2008
153
Kada metoda implementuje algorytm realizujcy pewn okrelon funkcjonalno
. Na
poziomie lokalnym klasy czsto okazuje si, e cz
metod realizuje typowe zadania, takie jak
pobieranie czy ustawiania wartoci atrybutu klasy. Spostrzeenie to zaowocowało kategoryzacj
metod w zalenoci od ich zada (funkcjonalnoci) [7]. Powstały koncepcje [8], które nakazywały
programistom oznaczanie metod jako przynalecych do okrelonych kategorii funkcjonalnoci.
Niestety, w praktyce takie oznaczenia s rzadko stosowane.
Wanym elementem metody jest jej nazwa. O ile jzyki programowania pozwalaj na szerok
dowolno
nazewnictwa to ludzie maj tendencj do nazywania bytów w sposób odpowiadajcy
jego znaczeniu w wiecie rzeczywistym. Jest to najzupełniej zrozumiałe, gdy zabiegi takie
zwikszaj czytelno
kodu ródłowego. W przypadku metod ma to znaczenie szczególne: mona
przyj
załoenie, e nazwa metody w pewnym stopniu odzwierciedla jej funkcjonalno
i dokonywa
klasyfikacji funkcjonalnej na podstawie wyników analizy nazwy metody. Analiza ta
moe opiera
si na wyszukiwaniu czasowników i przyimków jzyka angielskiego (zakładajc e
ten jzyk jest uyty do tworzenia identyfikatorów), które mona połczy
z okrelonymi
kategoriami funkcjonalnymi, np.:
• getter (metoda pobierajca dane): is, get, has, can, …
• setter (metoda ustawiajca dane): set, enable, assign, …
• comparator (metoda porównujca): compare, equal, less, …
• converter (metoda konwertujca): convert, to, as, …
• finder (metoda wyszukujca): choose, find, …
Analiza danych eksperymentalnych wykazała nastpujce licznoci niektórych kategorii
funkcjonalnych metod:
• konstruktory (metody inicjalizujce stan obiektu): 10,51%
• getter: 28,16%
• setter: 11,09%
Proponowana metoda estymacji długoci kodu ródłowego jako wejcie przyjmuje
nastpujce metryki wywiedzione z analizy danych dostpnych w ramach diagramów klas UML:
• ilo
metod w klasie
• ilo
statycznych i niestatycznych atrybutów prostych 0-wymiarowych oraz 1- i wielowymiarowych
• ilo
statycznych i niestatycznych atrybutów złoonych 0-wymiarowych oraz 1- i wielowymiarowych
• ilo
parametrów prostych 0-wymiarowych oraz 1- i wielowymiarowych metod statycznych i niestatecznych w zalenoci od kategorii funkcjonalnej
• ilo
parametrów złoonych 0-wymiarowych oraz 1- i wielowymiarowych metod statycznych i niestatycznych w zalenoci od kategorii funkcjonalnej
• ilo
rezultatów prostych 0-wymiarowych oraz 1- i wielowymiarowych metod statycznych
i niestatycznych w zalenoci od kategorii funkcjonalnej
• ilo
rezultatów złoonych 0-wymiarowych oraz 1- i wielowymiarowych metod statycznych i niestatycznych w zalenoci od kategorii funkcjonalnej
154
Maciej Stachurski
Metoda estymacji długoci kodu ródłowego na podstawie diagramów statycznych UML
Dokładne definicje poszczególnych metryk zostały tutaj pominite ze wzgldu na wymagan
zwizło
niniejszego artykułu.
Na potrzeby metody szacujcej stworzono trzy modele estymujce rozmiar systemu
informatycznego na podstawie metryk obiektowych pochodzcych z diagramów klas UML.
Zostały one stworzone za pomoc:
• klasycznej regresji wielorakiej (metoda najmniejszych kwadratów)
• regresji odpornej (metoda najmniejszych kwadratów z wielokrotnym waeniem)
• regresji medianowej (metoda minimalizujca moduł odchyle od mediany)
Modele tworzono za pomoc pakietu statystycznego Stata w wersji 10.0.
Do oceny sprawnoci poszczególnych modeli estymacji wykorzystano nastpujce mierniki:
• moduł błdu wzgldnego (MRE – ang: Magnitude of Relative Error), oceniajcy dla kadego przypadku o ile procent oszacowanie róni si od wartoci rzeczywistej
•
rednia modułów błdu wzgldnego (MMRE – ang: Mean Magnitude of Relative Error),
oceniajcy szacowania sprawno
dla zespołu przypadków
•
współczynnik predykcji PRED(p) oceniajcy ile przypadków zostało oszacowanym z modułem błdu wzgldnego nie wikszym ni p
Oczekiwane wartoci graniczne parametrów oceniajcych to nie wicej ni 20% dla redniej
modułu błdu wzgldnego oraz ponad 75% dla współczynnika predykcji PRED(25%).
Eksperyment polegajcy na oszacowaniu rozmiaru 56 systemów informatycznych przyniósł
nastpujce rezultaty:
klasyczna regresja wieloraka
regresja odporna
regresja medianowa
MMRE PRED(25%)
18,70%
76,79%
19,94%
67,86%
21,70%
64,29%
Uzyskane wyniki s w pełni satysfakcjonujce tylko w przypadku regresji wielorakiej.
Modele stworzone za pomoc pozostałych wariantów regresyjnych nie spełniaj co najmniej
jednego kryterium.
6. Przykład zastosowania proponowanej metody estymacji
Proponowana metoda estymacji słuy do szacowania podstawowych jednostek modelu obiektowego, a mianowicie klas. Poniej znajduje si przykładowy diagram klasy, w oparciu o który
przedstawiony bdzie proces estymacji rozmiaru kodu ródłowego słucego do implementacji
niniejszej klasy.
POLSKIE STOWARZYSZENIE ZARZDZANIA WIEDZ
Seria: Studia i Materiały, nr 17, 2008
155
ExtFulltext
+signature: FunctionSignature
#path: PathExpr
#searchTerm: Expression = null
#type: int = Constants.FULLTEXT_AND
#cached: CachedResult = null
-contextStep: LocationStep = null
#contextQName: QName = null
#axis: int = Constants.UNKNOWN_AXIS
#optimizeSelf: boolean = false
#preselectResult: NodeSet = null
<<create>>+ExtFulltext(context: XQueryContext, type: int)
+addTerm(term: Expression)
+analyze(contextInfo: AnalyzeContextInfo)
+canOptimize(contextSequence: Sequence): boolean
+optimizeOnSelf(): boolean
+getOptimizeAxis(): int
+preSelect(contextSequence: Sequence, useContext: boolean): NodeSet
+eval(contextSequence: Sequence, contextItem: Item): Sequence
-checkForQNameIndex(contextSequence: Sequence): boolean
#evalQuery(searchArg: String, nodes: NodeSet): Sequence
+toString(): String
+dump(dumper: ExpressionDumper)
+getDependencies(): int
#getSearchTerms(searchString: String): String
#processQuery(terms: String, contextSet: NodeSet): NodeSet
#getMatches(docs: DocumentSet, contextSet: NodeSet, axis: int, qname: QName, terms: String): NodeSet
+returnsType(): int
+setPath(path: PathExpr)
+setContextDocSet(contextSet: DocumentSet)
+resetState()
+accept(visitor: ExpressionVisitor)
Na podstawie analizy diagramu klasy mona wyznaczy
nastpujce parametry j opisujce:
Nazwa parametru klasy
liczba metod
liczba atrybutów statycznych złoonych
liczba atrybutów złoonych
liczba atrybutów prostych
liczba parametrów złoonych metod typu konstruktor
liczba parametrów złoonych metod typu getter
liczba parametrów złoonych metod niezidentyfikowanych
liczba parametrów złoonych metod typu setter
liczba parametrów prostych metod typu getter
liczba parametrów prostych metod niezidentyfikowanych
liczba rezultatów złoonych metod typu getter
liczba rezultatów złoonych metod niezidentyfikowanych
liczba rezultatów prostych metod typu getter
liczba rezultatów prostych metod niezidentyfikowanych
Warto
21
1
6
3
1
5
11
2
1
1
2
10
3
3
156
Maciej Stachurski
Metoda estymacji długoci kodu ródłowego na podstawie diagramów statycznych UML
W rzeczywistoci wyznaczanych jest wicej parametrów klasy (w metodzie bazujcej na
regresji wielorakiej jest ich 48). W zaprezentowanym przykładzie zostały one pominite ze
wzgldu na ich zerow warto
.
Podstawiajc tak uzyskane rezultaty do równania modelu estymujcego bazujcego na regresji
wielorakiej uzyskano rozmiar klasy równy 2015,2489 tokenów. Rzeczywisty rozmiar klasy wynosi
1909 tokenów. Oznacza to, e proponowana metoda estymacji przeszacowała rozmiar badanej
klasy o 5,57%, co moe by
uznane za wynik satysfakcjonujcy.
7. Wnioski
Przedstawiona metoda szacowania rozmiaru systemu informatycznego w aspekcie długoci
kodu ródłowego implementujcego jego funkcjonalno
stanowi uzupełnienie istniejcych metod
estymacji działajcych na wczesnych etapach realizacji. Rezultaty metod szacujcych rozmiar w
aspekcie funkcjonalnoci mog by
doprecyzowywane przy pomocy takich metod jak ta opisana w
niniejszym artykule. Metoda ta moe by
w duym stopniu automatyzowana pozwalajc na
zastosowanie jej w edytorach UML dla wsparcia pracy projektantów systemów informatycznych.
Bibliografia
1.
2.
3.
4.
5.
6.
7.
8.
9.
The Standish Group International, Inc.: Extreme Chaos, 2001.
Fenton N., Neil M.: The Future of Software Engineering. W Finkelstein A.: The Future of
Software Engineering, ACM Press, Limerick 2000.
Górski J.: Inynieria oprogramowania w projekcie informatycznym, Wydawnictwo Informatyki MIKOM, Warszawa 2000.
Longstreet D.: Function Points Analysis Training Course, Longstreet Consulting Inc.,
2004.
McConnell S.: Rapid Development. Taming Wild Software Schedules, Microsoft Press,
Redmond 1996.
Fowler M., Scott K.: UML w kropelce, Oficyna Wydawnicza LTP, Warszawa 2000.
Dragan N., Collard M., Maletic J.: Reverse Engineering Method Stereotypes.
W Proceedings of the 22nd IEEE International Conference on Software Maintenance,
IEEE Computer Society, Washington 2006.
Riehle D.: Metod Types In Java, Java Report 2/2000.
Conte, S., Dunsmore H., Shen V.: Software Engineering Metrics and Models, Benjamin
Cummings Publishings, Menlo Park 1986.
POLSKIE STOWARZYSZENIE ZARZDZANIA WIEDZ
Seria: Studia i Materiały, nr 17, 2008
157
A METHOD OF SOURCE CODE LENGTH ESTIMATION WITH USE OF STATIC UML
DIAGRAMS
Summary
Constantly growing demand on complex information systems requires that software must be developed as efficiently as possible. Among many problems of software
development management a special meaning has estimation, which is part of planning. This article presents a method allowing to estimate size of information system
using data available in UML diagrams, which complement already existing methods
with more detailed results, especially those which operate on higher level of abstraction.
Keywords: software project size estimation, source code size estimation, UML diagrams, class
diagrams
Maciej Stachurski
Wydział Informatyki
Politechnika Szczeciska
Szczecin, ul. ołnierska 49
e-mail: [email protected]
http://www.wi.ps.pl/