Metoda estymacji długości kodu źródłowego na podstawie diagramów statycznych UML

Pełen tekst

(1)METODA ESTYMACJI DŁUGO CI KODU

(2) 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.

(3) 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.

(4) 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.

(5) 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.

(6) 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..

(7) 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.

(8) 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.

(9) 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..

(10) 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.

(11) 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..

(12) 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: mstachurski@wi.ps.pl http://www.wi.ps.pl/.

(13)