Tabela 1. Ogólne słowa kluczowe HAZOPu

Transkrypt

1 Wersja postprint artykułu opublikowanego na IV Krajowej Konferencji Inżynierii Oprogramowania, Tarnowo Podgórne k. Poznania, 5-8 października 2002, Poznań: Wydawnictwo Nakom 2002 str Wykrywanie anomalii w modelach obiektowych za pomocą metody UML-HAZOP Janusz Górski, Aleksander Jarzębowicz Katedra Zastosowań Informatyki Politechnika Gdańska jango@pg.gda.pl olek@digimer.pl Streszczenie Artykuł dotyczy metody wykrywania defektów w dokumentacji oprogramowania wykonywanego z zastosowaniem notacji UML. Metoda ta, nazwana UML-HAZOP, jest adaptacją metody HAZOP szeroko stosowanej w stosunku do systemów związanych z bezpieczeństwem. Metoda ta jest ukierunkowana na wykrywanie anomalii w dokumentacji projektowej na drodze analizy przepływów pomiędzy komponentami badanego systemu. Adaptacja metody do badania oprogramowania polega na nadaniu właściwej, ukierunkowanej na specyfikę wybranego poziomu dokumentowania oprogramowania, interpretacji przepływom oraz ich anomaliom. W obecnej postaci metoda UML-HAZOP koncentruje się na diagramach klas. Dalsze prace zmierzają do jej rozszerzenia na pozostałe modele związane z UML. W artykule przedstawiono metodę UML-HAZOP oraz wyniki eksperymentów związanych z jej zastosowaniem do dwóch rzeczywistych systemów: systemu bilingowego oraz systemu zarządzania firmą.. Wprowadzenie Jednym z najistotniejszych problemów dotyczących projektów informatycznych są defekty obecne w wytwarzanym oprogramowaniu. Ich identyfikacja i naprawa pochłania znaczne zasoby czasowe i finansowe, w wyniku czego możliwe jest przekroczenie zaplanowanego harmonogramu i budżetu. Jeszcze większe niebezpieczeństwo stanowią nie wykryte defekty, które pozostają w oprogramowaniu dostarczonym klientowi i w sposób oczywisty powodują obniżenie poziomu satysfakcji użytkowników. Defekty mogą być wprowadzane już w najwcześniejszych etapach wytwarzania oprogramowania np. podczas pozyskiwania wymagań lub w trakcie tworzenia analitycznego modelu systemu. Jeśli nie

2 zostaną w porę zauważone i skorygowane, przenoszą się na kolejne reprezentacje systemu, a koszty ich naprawy w każdej kolejnej fazie systematycznie rosną. Niniejsza praca dotyczy problemu defektów obecnych w modelach obiektowych, będących produktem faz analizy systemowej oraz ogólnego projektu systemu. Skoncentrowano się na modelach wyrażonych w notacji UML [] z uwagi na stopień jej rozpowszechnienia, czyniący z niej standard de facto. Analiza modeli UML pod kątem wykrywania w nich defektów nie jest zadaniem prostym. UML posiada częściowo sformalizowaną (graficzną) składnię, natomiast semantyka jest nieformalna i w znacznym stopniu zależna od interpretacji odbiorcy. Oznacza to, że analiza może być jedynie w ograniczonym zakresie zautomatyzowana, a ostateczne decyzje (co do tego co jest, a co nie jest defektem) będą należały do człowieka. Dodatkowy problem wynika ze znacznej złożoności tworzonych systemów i co za tym idzie złożoności związanych z nimi modeli. Nawet jeżeli zastosowano właściwe techniki redukcji złożoności (abstrakcja, dekompozycja), to w wielu wypadkach modele w całości są trudne do intelektualnego opanowania. Metody ich analizy powinny, w takim zakresie jak to jest możliwe, ograniczać rozpatrywany zakres modelu, redukując w ten sposób wysiłek intelektualny analityka. Metody takie nazwiemy metodami analizy częściowej. Przykładem analizy częściowej jest np. sprawdzenie czy każda nazwa klasy została wyspecyfikowana zgodnie z przyjętą konwencją wystarczy wtedy skoncentrować uwagę po kolei na każdej z klas, sprawdzając jej nazwę, bez potrzeby rozpatrywania jej roli w ramach całego systemu. Fakt, że bardziej zaawansowana analiza modeli UML wymaga znacznego udziału człowieka (chyba że semantyka tych modeli zostanie w znacznie większym niż obecnie stopniu sformalizowana, co raczej nie nastąpi w najbliższych latach) nie oznacza, że proces analizy powinien być realizowany ad hoc i nie ma podlegać sterowaniu. Oczywiste oczekiwania, formułowane w stosunku do metody analizy obejmują: Kompletność analiza jest prowadzona w sposób, który gwarantuje wykrywanie potencjalnie wszystkich defektów w przewidzianym dla niej zakresie; Systematyczność zalecana metoda postępowania powoduje, że uwaga analityka koncentrowana jest na fragmencie modelu odpowiednim do typu poszukiwanego defektu oraz prowadzi analityka poprzez wszystkie takie istotnie różne fragmenty; Uniwersalność - metoda może być zastosowana do jak najszerszej klasy systemów, bez ograniczeń związanych z ich przeznaczeniem lub środowiskiem, czy też z technologiami wykorzystywanymi do ich budowy; Wspomaganie metoda wspomaga analityka poprzez związane z nią wzorce, listy kontrolne, narzędzia itp. Jedną z dróg prowadzących do odkrycia nowej metody analizy jest zaadaptowanie metody już istniejącej, która potwierdziła swoją skuteczność w odniesieniu do innych obszarów problemowych. Takie właśnie podejście jest prezentowane w niniejszym artykule. Przedmiotem zainteresowania jest HAZOP (ang. Hazard and Operability Studies), metoda szeroko stosowana w analizie systemów związanych z bezpieczeństwem. HAZOP koncentruje się na połączeniach pomiędzy różnymi komponentami systemu i bada, czy i w jaki sposób odchylenia od prawidłowych wartości atrybutów tych połączeń mogą mieć wpływ na awarie w rozpatrywanym systemie. Odchylenia te są sugerowane

3 analitykowi poprzez słowa kluczowe (ang. guide words), które w zestawieniu z konkretnymi atrybutami połączeń dają obraz specyficznych sytuacji, które należy wziąć pod uwagę. Prace nad przystosowaniem HAZOPu do analizy oprogramowania miały miejsce w pierwszej połowie lat 90, a ich podsumowaniem jest wydany przez brytyjskie ministerstwo obrony Interim Defense Standard [2]. Zawiera on opis organizacji procesu analizy oraz kryteria poszukiwania defektów w różnych reprezentacjach systemu. Kryteria te zostały określone dość ogólnie i odnosiły się do dawniej stosowanych notacji, które obecnie w większości wyszły z powszechnego użycia, zastąpione przez Unified Modelling Language. Problem przystosowania metody HAZOP do analizy reprezentacji systemu wyrażonych przy pomocy różnych notacji związanych z projektowaniem oprogramowania pojawiał się również w innych pracach ([3],[4]). Próbowano również modyfikować tę metodę dla potrzeb konkretnych problemów np. generowanie mutacji podstawowych wyrażeń składniowych języka JAVA [5], sformalizowana analiza bezpieczeństwa interfejsu użytkownika [6], analiza zabezpieczeń (ang. security) systemów [7]. W artykule przedstawiono wyniki prac zmierzających do adaptacji metody HAZOP do analizy modeli związanych z językiem UML. Adaptacja ta polega na nadaniu właściwych dla odpowiednich modeli UML interpretacji połączeniom w modelu, ich atrybutom oraz słowom kluczowym HAZOPu, zaproponowaniu sposobu postępowania w trakcie analizy (procesu analizy) oraz przeprowadzeniu eksperymentalnej walidacji zaproponowanego podejścia. Wyniki uzyskane w powyższych zakresach (interpretacja słów kluczowych, definicja procesu oraz eksperymentalna walidacja) przedstawiono w kolejnych rozdziałach niniejszego artykułu. 2. Metoda UML-HAZOP W dalszej części artykułu przyjmujemy, że te elementy modelu, które w wyniku analizy zostają uznane przez analityka za błędne lub budzące wątpliwości, określamy jako anomalie. Anomalię, która została potwierdzona przez niezależne źródło jako rzeczywisty błąd w rozpatrywanym modelu, nazwiemy defektem. Adaptacja HAZOPu do notacji UML polega na określeniu, jakie elementy poszczególnych diagramów UML interpretujemy jako połączenia i ich atrybuty oraz jakie anomalie modelu są sugerowane przez zastosowanie poszczególnych słów kluczowych do poszczególnych atrybutów. W wyniku otrzymujemy listy kontrolne, wyliczające anomalie, które mogą zachodzić w odniesieniu do rozpatrywanego elementu modelu. Zastosowano ogólny zestaw słów kluczowych zaproponowany w standardzie [2], który przedstawia Tabela. W dalszej części podano interpretacje tych słów kluczowych w zastosowaniu do diagramu klas UML. W diagramie klas, z połączeniem (w sensie HAZOPu) mamy do czynienia wtedy, gdy pomiędzy rozpatrywanymi klasami występuje zależność (ang. relationship). Według specyfikacji UML [] wyróżnia się następujące rodzaje zależności: zależność semantyczna pomiędzy klasami, (ang. association), zależność informująca o tym, że implementacja lub funkcjonowanie danej klasy lub klas wymaga obecności innej klasy lub klas, (ang. dependency),

4 zależność pomiędzy dwiema wersjami obiektu lub obiektem i jego kopią, występuje w diagramach obiektów, (ang. flow), zależność uogólniania, związana z dziedziczeniem cech, (ang. generalization). Tabela. Ogólne słowa kluczowe HAZOPu Słowo kluczowe NO MORE LESS AS WELL AS PART OF REVERSE OTHER THAN EARLY LATE BEFORE AFTER Ogólna interpretacja Kompletny brak zamierzonego rezultatu, przy braku innych, zastępczych efektów Zbyt wysoka wartość parametru ilościowego Zbyt niska wartość parametru ilościowego Oprócz zamierzonego rezultatu otrzymano inny, dodatkowy Zamierzony rezultat został uzyskany tylko częściowo Otrzymano logiczne przeciwieństwo zamierzonego rezultatu Brak zamierzonego rezultatu, ale otrzymano inny, odmienny Zdarzenie zachodzi wcześniej niż zamierzono Zdarzenie zachodzi później niż zamierzono Zdarzenie zachodzi przed innym zdarzeniem, w stosunku do którego miało być późniejsze Zdarzenie zachodzi po innym zdarzeniu, w stosunku do którego miało być wcześniejsze W pracach nad metodą UML-HAZOP skoncentrowano się na najczęściej stosowanych typach zależności: Association i Generalization. Za atrybuty (w sensie HAZOPu) przyjmowane są zarówno same zależności (patrz tabela 2 i 8), jak również charakterystyki przypisane im w notacji UML (tabele 3-7). Charakterystyki te według specyfikacji UML wyglądają następująco: Charakterystyka zależności typu Association: name (nazwa związku) Charakterystyka zależności typu Association od strony jednej z uczestniczących w niej klas: AssociationEnd: aggregation (obecność relacji typu całość-część) changeability (możliwość modyfikacji przez klasę skojarzoną) ordering (uporządkowanie zbioru instancji klas) isnavigable (możliwość przejścia do klasy z punktu widzenia klasy skojarzonej)

5 multiplicity (liczność związku) name (nazwa roli klasy w związku) targetscope (czy związek dotyczy klasy czy jej instancji) visibility (widoczność klasy z punktu widzenia klasy skojarzonej) Charakterystyka zależności typu Generalization: discriminator (kryterium dziedziczenia) Interpretacje przypisane poszczególnym zestawieniom atrybutów ze słowami kluczowymi HAZOPu podano w tabelach zamieszczonych poniżej. W tabelach uwzględniono tylko te słowa kluczowe, które można powiązać z sensowną interpretacją anomalii w odniesieniu do rozpatrywanego atrybutu, pozostałe pominięto. Tabela 2. Interpretacje anomalii dla zależności Association Słowo kluczowe Interpretacja AS WELL AS OTHER THAN Rozpatrywane klasy nie pozostają ze sobą w związku, cały związek jest zbędny i powinien być usunięty Niewłaściwy rodzaj związku, powinien zostać zdefiniowany związek innego rodzaju np. Generalization zamiast Association PART OF Związek jest poprawny, ale oprócz niego pomiędzy rozpatrywanymi klasami należy zdefiniować dodatkowy związek lub związki Tabela 3. Interpretacje anomalii dla atrybutu Association.name Słowo kluczowe NO REVERSE OTHER THAN AS WELL AS PART OF Interpretacja Związek nie ma nazwy mimo, że powinien być nazwany Błędny kierunek odczytywania nazwy związku, w którym znajdują się klasy Nazwa związku jest nieprawidłowa i nie oddaje jego znaczenia; należy użyć innej nazwy Nazwa związku jest zbyt ogólna, należy ją uszczegółowić Nazwa oddaje jedynie częściowo istotę związku, należy ją uogólnić

6 Tabela 4. Interpretacje anomalii dla atrybutu AssociationEnd.aggregation Słowo kluczowe NO AS WELL AS OTHER THAN MORE LESS Interpretacja Nie zaznaczono agregacji, która powinna wystąpić Zaznaczono agregację, która w rzeczywistości nie ma miejsca Zaznaczono niewłaściwy typ agregacji tzn. silną zamiast słabej lub odwrotnie Agregacja obejmuje zbyt wiele klas składowych, niektóre nie powinny wchodzić w jej skład Agregacja nie obejmuje niektórych klas (obecnych na diagramie lub też nie), które powinny wchodzić w jej skład Tabela 5. Interpretacje anomalii dla atrybutu AssociationEnd.ordering Słowo kluczowe NO AS WELL AS Interpretacja Brak uporządkowania mimo, że powinno występować Wprowadzono uporządkowanie, które nie powinno mieć miejsca Tabela 6. Interpretacje anomalii dla atrybutu AssociationEnd.multiplicity Słowo kluczowe MORE LESS Interpretacja Krotność związku jest zbyt duża (może to dotyczyć górnego lub dolnego zakresu liczności) Krotność związku jest zbyt mała (może to dotyczyć górnego lub dolnego zakresu liczności) Tabela 7. Interpretacje anomalii dla atrybutu AssociationEnd.name Słowo kluczowe NO OTHER THAN AS WELL AS PART OF Interpretacja Strona związku nie ma nazwy mimo, że powinna być nazwana Nazwa strony związku jest nieprawidłowa, powinna być zdefiniowana inna nazwa Nazwa strony związku jest zbyt ogólna, należy ją uszczegółowić Nazwa oddaje jedynie częściowo istotę strony związku, należy ją uogólnić

7 Tabela 8. Interpretacje anomalii dla zależności Generalization Słowo kluczowe AS WELL AS MORE LESS OTHER THAN Interpretacja Klasy nie pozostają ze sobą w związku dziedziczenia, cały związek jest zbędny i powinien być usunięty Zbyt wiele klas dziedziczących, niektóre są zbędne Zbyt mało klas dziedziczących, brak niektórych potrzebnych klas Zdefiniowany związek jest niepoprawny, powinien być zdefiniowany inny związek niż uogólnienie 3. Proces UML-HAZOP Proces analizy według metody UML-HAZOP został przedstawiony na rysunku. Proces ten obejmuje szereg aktywności wykonywanych w kolejnych krokach. Listy kontrolne diagramy UML Zgłoszenia zmian procesu Podsumowanie analizy Planowanie Przygotowanie Kontrola i Rejestracja Ocena Redakcja Audit redakcji Wyjście Plan Wykryte anomalie Zapis defektów i sugestie zmian Produkt wyjściowy Rysunek.. Struktura procesu analizy metodą UML-HAZOP. Pierwszym krokiem procesu jest planowanie. W ramach tego kroku podejmowana jest decyzja o przedmiocie i zakresie analizy, dobierane są odpowiednie listy kontrolne, wyznaczani uczestnicy oraz układany harmonogram dalszych działań. Przygotowanie obejmuje działania związane z zapoznaniem

8 uczestników z metodą oraz zapoznanie się ich (w niezbędnym zakresie) z przedmiotem analizy (badany system i jego modele). Krok kontroli i rejestracji polega na systematycznej analizie diagramów UML według przygotowanych wcześniej list kontrolnych. Wykryte anomalie są rejestrowane w przygotowanych wcześniej strukturach danych pokazanych w tabeli 9. Związek: <identyfikacja związku> Tabela 9. Struktura danych dla rejestracji wyników. Atrybut Słowo kluczowe Wynik <nazwa atrybutu> <słowo kluczowe HAZOPu> <opis > Przy wypełnianiu kolumny Wynik stosowana jest następująca konwencja: D zaobserwowano anomalię, którą wstępnie zaklasyfikowano jako defekt, Q pytanie, zaobserwowano niejasność wymagającą przedyskutowania, C poprawka (nanoszona w związku z wykryciem defektu w innym elemencie np. jeśli zmieniamy związek z agregacją na zwykły, powinniśmy nadać mu nazwę) N brak anomalii, element jest prawidłowy X nie analizowano Rejestrowane są wszystkie przeanalizowane przypadki, łącznie z tymi, gdzie dla danej kombinacji atrybutu ze słowem kluczowym nie stwierdzono żadnej anomalii. Krok oceny wiąże się z ustaleniem ostatecznej interpretacji wykrytych anomalii, zaklasyfikowaniem ich (w przypadku potwierdzenia zasadności) jako defektów w modelu oraz ustaleniem znaczenia tych defektów. Krok ten wymaga udziału ekspertów w zakresie ocenianego systemu i związanej z nim dziedziny. W wyniku powstaje lista wykrytych defektów wraz z kwalifikacją co do ich znaczenia w kontekście analizowanego systemu (np. pomijalne, znaczne, krytyczne). W kroku tym są również rejestrowane sugestie dotyczące zmian modelu w sposób eliminujący z niego wykryte defekty. Należy jednak podkreślić, że nie jest to zasadniczy cel dokonywanych analiz i sugestie te stanowią jedynie (pożądany) efekt uboczny procesu analizy. W kroku oceny pożądany jest udział autora analizowanego modelu. Jeżeli w kroku tym uczestniczy większa liczba osób należy zadbać o to, by spotkanie ich nie przerodziło się w jałową dyskusję i by szybko dążyło do ustalenia ostatecznych konkluzji. Techniki wspomagające osiąganie tych celów są poza zakresem niniejszego artykułu. Lista defektów stanowi punkt wyjścia w kroku redakcji, który ma na celu poprawę przeanalizowanych modeli. Krok ten jest realizowany przez autora (autorów) modelu. Po jego zakończeniu, dokonywany jest formalny przegląd mający na celu potwierdzenie, że wszystkie wykryte defekty zostały usunięte. Proces kończy się formalnym zamknięciem analizy oraz zebraniem i rejestracją danych, które ją podsumowują (pracochłonność, liczby wykrytych anomalii i defektów, metryki efektywności itp.). W trakcie procesu analizy, a w szczególności w krokach przygotowania, kontroli i rejestracji, oceny oraz redakcji mogą być formułowane i rejestrowane sugestie dotyczące poprawy procesu w celu

9 zwiększenia jego skuteczności i efektywności. Sugestie te stanowią dane wejściowe do podjęcia działań zmierzających do poprawy w dłuższym horyzoncie czasowym. 4. Eksperymentalna walidacja metody W celu oceny skuteczności metody UML-HAZOP zaplanowano serię eksperymentów. Podstawowym celem tych eksperymentów było stwierdzenie, na ile metoda ta jest skuteczna w wykrywaniu defektów w modelach UML tworzonych we wczesnych etapach rozwoju systemu. Koncentracja na wczesnych etapach rozwoju (analiza, projekt ogólny) wydaje się być szczególnie istotna ze względu na to, że defekty które wtedy powstają i pozostają nie wykryte, mogą okazać się szczególnie kosztowne podczas ich usuwania w etapach późniejszych. W wypadku potwierdzenia dużej skuteczności wykrywania, kolejnym celem eksperymentalnej walidacji będzie poszukiwanie takiej struktury procesu analizy, która minimalizuje relację nakładów do uzyskiwanych efektów. Do chwili obecnej zakończone zostały trzy eksperymenty; poniżej podano ich bliższą charakterystykę. 4. Eksperyment : System bilingowy ocena retrospektywna Analizie poddano system przeznaczony dla operatora niewielkiej sieci telefonicznej. Jego zadaniem jest naliczanie opłat telefonicznych w oparciu o dane dotyczące połączeń oraz obsługa wystawiania i regulowania rachunków. System przechowuje informacje o abonentach oraz związanych z nimi liniach telefonicznych, połączeniach i opłatach. Historia tego systemu liczy około 6 lat. System został wytworzony jako pomoc dydaktyczna przeznaczona dla Podyplomowego Studium Inżynierii Oprogramowania. Dokumentacja systemu stanowi zbiór rozwiązań wzorcowych, które są udostępniane słuchaczom Studium w celu porównania oraz wprowadzenia korekt we własnej dokumentacji, tak aby błędy pojedynczego etapu nie uniemożliwiły realizacji całego projektu. Modele, które poddano analizie były wielokrotnie przeglądane zarówno przez słuchaczy Studium, jak również przez ich autorów, w trakcie opracowywania kolejnych wydań systemu. Analizę UML-HAZOP wykonano w stosunku do dwóch dokumentów: modelu klas reprezentującego wynik analizy systemowej oraz dokumentu projektu szczegółowego. Analityk nie miał wglądu w pozostałą część dokumentacji, w tym w specyfikację wymagań. Istotne wyniki analizy dotyczyły diagramów klas i diagramów stanów. Dla diagramów przypadków użycia i diagramów sekwencji analiza nie przyniosła znaczących rezultatów (ponieważ badany system jest w znacznym stopniu statyczny, diagramy związane z jego dynamiką były znacznie zredukowane). Wyjściowy diagram klas systemu zawierał 7 klas oraz 4 związków. 4.2 Eksperyment 2: System zarządzania firmą SZ@Fir ocena retrospektywna Eksperyment ten został przeprowadzony w stosunku do modeli wytworzonych dla rzeczywistej aplikacji. System Sz@Fir stanowi zintegrowane, dostępne za pośrednictwem sieci narzędzie

10 zarządzania niewielką firmą i jest cały czas rozwijany o nowe funkcjonalności, podczas kolejnych przyrostów powstających w cyklu wytwarzania. Funkcjonalność obejmuje do tej pory m.in. gospodarkę magazynową, księgowość, logistykę i realizację sprzedaży, obsługę cenników, przekazywanie faktur. System jest wytwarzany przez firmę Prokom Software SA, która wyraziła zainteresowanie pracami nad metodą UML-HAZOP i udostępniła dla celów eksperymentu odpowiednie modele UML oraz część dokumentacji, obejmującą projekty koncepcyjne dwóch podsystemów zrealizowanych w ramach ostatniego przyrostu. Udostępnione modele nie stanowiły ostatecznych wersji, w oparciu o które zaimplementowano system i zawierały defekty, znane zespołowi projektowemu, wykryte w ramach dalszych kroków procesu wytwórczego. Informacje te nie były jednak znane analitykowi prowadzącemu analizę UML-HAZOP. W ramach eksperymentu analizie poddano diagramy klas. Były to dwa diagramy, główny i uzupełniający, ten drugi zawierał jedynie informacje dotyczące cenników. W sumie oba diagramy zawierały 56 klas oraz 79 związków. 4.3 Eksperyment 3: System zarządzania firmą SZ@Fir ocena bieżąca Eksperyment został przeprowadzony we współpracy z firmą Prokom Software S.A. i dotyczył kolejnego przyrostu opisanego wcześniej systemu zarządzania firmą, a różnił się od poprzednich tym, że analiza UML-HAZOP została wykonana bezpośrednio po wytworzeniu modeli UML, a przed ich dalszym wykorzystaniem w procesie wytwórczym. Druga istotna różnica dotyczyła jakości udostępnionych modeli tym razem był to model w postaci finalnej, po przejściu przez fazy uzgodnień z twórcami specyfikacji systemu oraz przeglądów. 5. Wyniki eksperymentów Wyniki ilościowe związane z poszczególnymi eksperymentami zostały przedstawione w osobnych tabelach (0,,3). W pozycji Liczba przeanalizowanych przypadków chodzi o przypadki, dla których konieczna była ocena dokonywana przez człowieka. Podana liczba nie obejmuje przypadków, które można automatycznie odrzucić np. dla związku bez nazwy sprawdzamy jedynie przypadek związek nie ma nazwy, mimo że powinien być nazwany, bez rozpatrywania pozostałych możliwych anomalii dotyczących trafności nazwy, kierunku jej odczytywania itp. Pozycja Liczba znaczących defektów określa liczbę defektów, które uznano za poważne (nie dotyczy to np. defektów związanych z nazewnictwem związków). 5. Eksperyment : System bilingowy Wyniki analizy zostały podsumowane w poniższej tabeli.

11 Tabela 0: Wyniki eksperymentu Liczba osób zaangażowanych w analizę Czas przygotowania list kontrolnych 2 roboczogodz. Czas przygotowania merytorycznego 4 roboczogodz. Czas kontroli 2,5 roboczogodz. Czas oceny 3,5 roboczogodz. Liczba przeanalizowanych przypadków ok. 70 Liczba wykrytych anomalii Liczba potwierdzonych defektów () 8 Liczba znaczących defektów 6 Poniżej zamieszczono przykładową tabelę zawierającą wyniki dokonanych analiz. Tabela : Przykład wyników kontroli diagramu klas Związek: is_part_of(charge,bill) Atrybut Słowo Wynik kluczowe Association AS WELL AS N Association OTHER THAN N Association PART OF N Association.name NO N Association.name REVERSE N Association.name OTHER THAN N Association.name AS WELL AS N Association.name PART OF N End - Charge AssociationEnd.aggregation NO N AssociationEnd.aggregation AS WELL AS N AssociationEnd.aggregation OTHER THAN N AssociationEnd.aggregation MORE N AssociationEnd.aggregation LESS N AssociationEnd.ordering NO D Pozycje rachunku informujące o opłatach za poszczególne linie powinny być uporządkowane. W przypadku dużej firmy dzierżawiącej wiele linii ma to znaczenie. () Anomalię uznano za potwierdzoną jako defekt, jeżeli co najmniej dwóch na trzech ekspertów uczestniczących w etapie oceny uznało, że jest to rzeczywiście błąd w modelu.

12 AssociationEnd.ordering AS WELL AS N AssociationEnd.multiplicity MORE N AssociationEnd.multiplicity LESS D Powinna być liczność... W każdym rachunku będzie przynajmniej opłata za linię (lub więcej jeśli abonent ma więcej linii). AssociationEnd.name NO N AssociationEnd.name OTHER THAN N AssociationEnd.name AS WELL AS N AssociationEnd.name PART OF N End 2 - Bill AssociationEnd.aggregation NO N AssociationEnd.aggregation AS WELL AS N AssociationEnd.aggregation OTHER THAN D Opłata wchodzi w skład tylko jednego rachunku, powinna tu być zaznaczona kompozycja. AssociationEnd.aggregation MORE N AssociationEnd.aggregation LESS N AssociationEnd.ordering NO N AssociationEnd.ordering AS WELL AS N AssociationEnd.multiplicity MORE N AssociationEnd.multiplicity LESS N AssociationEnd.name NO N AssociationEnd.name OTHER THAN N AssociationEnd.name AS WELL AS N AssociationEnd.name PART OF N Na rysunku 2 pokazano analizowany diagram klas z zaznaczonymi okręgiem miejscami, w których wykryto anomalie potwierdzone jako defekty.

13 ::Portion_of_data month year read_in ::Billing_data caller_no dialed_no trunk_line start_time end_time duration count_call ::Prefix number get_time_tab ::Time_tab calculate_pulses D points_to selects generated_by ::Line number counter get_line_subs set_billing_data D2 ::Subscriber name address pay_status select_lines get_last_bill sel_subs update_pay_status date text leases ::Reminder issued_for based_on concerns ::Detailed_bill year month /total /sum count_detailed_bill ptint_detailed_bill issued_for concerns D3 D5 ::Charge counter_state no_of_pulses sum count_charges_subs count_line ::Bill bill_id month year fixed_charge var_rate debt /total /sum print_date pay_date count_bill print_bills_subs prepare_bill print_all_bills D7 D4 ::Penalty D6 ::T_t_fixed frequency get_frequency ::T_t_flex 2 ::Sub_t_t frequency beg_time end_time get_values D8 ::Authorization ::Parameters ::Main from data to_data capital /value payed_prec count_penalty Rysunek 2. Diagram klas z etapu analizy Opis defektów zaznaczonych na diagramie: D - Zaznaczono agregację, powinna być kompozycja. D2 - Powinna być liczność 0.., mogą występować linie wolne, bez abonenta. D3 - Pozycje rachunku informujące o opłatach za poszczególne linie powinny być uporządkowane. D4 - Powinna być liczność... W każdym rachunku będzie przynajmniej opłata za linię (lub więcej jeśli abonent ma więcej linii). D5 - Rachunki widziane ze strony abonenta powinny być uporządkowane wg kolejności czasowej. D6 - Opłata wchodzi w skład tylko jednego rachunku, powinna tu być zaznaczona kompozycja. D7 - W skład rachunku wchodzi najwyżej kara dotycząca rachunku z poprzedniego miesiąca. Związek powinien mieć liczność 0...

14 D8 - Nie ma uzasadnienia liczność 2, powinna być. 5.2 Eksperyment 2: System zarządzania firmą Wyniki analizy zostały podsumowane w poniższej tabeli. Liczba osób zaangażowanych w analizę Czas przygotowania list kontrolnych Czas przygotowania merytorycznego (studiowanie celów i zakresu systemu) Czas kontroli Czas oceny Tabela 2: Wyniki eksperymentu 2 4,5 roboczogodz. 6 roboczogodz. 8,5 roboczogodz. 6 roboczogodz. Diagram Faktury Liczba przeanalizowanych przypadków ok. 750 Liczba wykrytych anomalii 94 Liczba potwierdzonych defektów () 7 Liczba znaczących defektów 35 Diagram Cenniki Liczba przeanalizowanych przypadków ok. 40 Liczba wykrytych anomalii 0 Liczba potwierdzonych defektów () 9 Liczba znaczących defektów Eksperyment 3: System zarządzania firmą ocena bieżąca Wyniki analizy zostały podsumowane w poniższej tabeli. () Wyniki analizy były weryfikowane przez członków zespołu projektowego, którzy opracowywali analizowany model

15 Tabela 3: Wyniki eksperymentu 3 Liczba osób zaangażowanych w analizę Czas przygotowania list kontrolnych,25 roboczogodz. Czas przygotowania merytorycznego 9 roboczogodz. Czas kontroli 3,75 roboczogodz. Czas oceny 7 roboczogodz. Liczba przeanalizowanych przypadków ok. 360 Liczba wykrytych anomalii 44 Liczba potwierdzonych defektów () 40 Liczba znaczących defektów 5 6. Podsumowanie Uzyskane wyniki eksperymentalne wskazują na znaczny potencjał metody UML-HAZOP w zastosowaniach praktycznych. Jest to szczególnie widoczne, jeżeli zauważymy, że analizy są w stanie wykryć defekty nawet w modelach poddawanych wcześniej weryfikacji i wykorzystanych w rzeczywistych aplikacjach. Uderzający jest stosunkowo nieduży nakład prac, które nie poddają się mechanizacji, a więc nakładów na przygotowanie merytoryczne, kontrolę i rejestrację oraz ocenę. W wypadku Eksperymentu nakłady te wyniosły łącznie 0 roboczogodzin, co przy 8 potwierdzonych defektach daje nakład,25 roboczogodzin na wykrycie jednego defektu. Przy założeniu, że koszt usunięcia defektu w etapach późniejszych wynosi 0 roboczogodzin (w świetle danych publikowanych np. w [9] jest to założenie stosunkowo łagodne) oznacza to, że efektywność metody wyniosła w tym wypadku 8. Efektywność rozumiemy jako stosunek pracy zaoszczędzonej do pracy wydatkowanej. W wypadku Eksperymentu 2, gdzie analizie poddano modele nie podlegające wcześniejszej weryfikacji, efektywność metody wyniosła 9,75 (80 potwierdzonych defektów przy nakładzie pracy 40,5 roboczogodzin). Z kolei w Eksperymencie 3, dotyczącym modelu poddanego uprzednio zabiegom weryfikacyjnym, wykrytych zostało 40 defektów przy nakładzie 2 roboczogodzin, co oznacza efektywność 9,05. Uzyskane wyniki dotyczące liczby wykrytych defektów wyglądają bardzo interesująco jeżeli zauważymy, że modele badane w Eksperymentach i 3 były wcześniej poddane weryfikacji i uznane za zakończone. Odnosi się to szczególnie do systemu bilingowego, ze względu na długi okres jego użytkowania i liczbę osób zaangażowanych w czytanie modeli. Metoda UML-HAZOP jest metodą analizy częściowej, tzn. koncentruje uwagę analityka na wybranych fragmentach modelu i nie jest nastawiona na wykrywanie wszystkich defektów. Nie może być w () Wyniki analizy były weryfikowane przez członków zespołu projektowego, którzy opracowywali analizowany model

16 związku z tym traktowana jako jedyna metoda analizy i powinna być stosowana w połączeniu z innymi metodami. Dzięki ograniczeniu zakresu jest to jednak metoda, która nie wymaga znacznych nakładów na przygotowanie analityka do pracy i może być stosowana nawet wtedy, gdy analityk nie panuje intelektualnie nad całym modelem, a jedynie koncentruje się na jego fragmentach (zgodnie z listami kontrolnymi UML-HAZOP). Dzięki temu nakłady związane z realizacją metody UML-HAZOP mogą być utrzymane na stosunkowo niskim poziomie i nie będą nieproporcjonalnie szybko rosły wraz ze wzrostem rozmiaru badanych modeli. Są to jednak w chwili obecnej jedynie hipotezy, których potwierdzenie wymaga dalszych badań eksperymentalnych. Warto również zauważyć, że pracochłonność związana z opracowaniem list kontrolnych może zastać prawie w całości przerzucona na narzędzia wspomagające zastosowanie metody. Przy założeniu, że analizowane modele są przechowywane w repozytorium elektronicznym (co w obecnej sytuacji jest normalne) łatwo można opracować program, który automatycznie wygeneruje listy kontrolne dotyczące połączeń w modelu. Takie właśnie narzędzie wspomagające jest obecnie w planie dalszych prac nad rozwojem metody UML-HAZOP. Bibliografia [] Object Management Group, OMG Unified Modeling Language Specification, Version.4, September 200 [2] Interim Defense Standard 00-58, HAZOP Studies on System Containing Programmable Electronics, UK Ministry of Defense 996. [3] McDermid J., Pumfrey D., Development of hazard analysis to aid software design, COMPASS 94: Proceedings of the Ninth Annual Conference on Computer Assurance, pp [4] Fencott C., Hebbron B., The application of HAZOP studies to integrated requirements models for control systems Proceedings of Computer Safety, Reliability and Security, 3 th International Conference SAFECOMP 994. [5] Kim S., Clark J., McDermid J., The rigorous generation of JAVA mutation operators using HAZOP, 2 th International Conference Software and Systems Engineering and their Applications (ICSSEA 94). [6] Hussey A., Safety analysis of the Druide user-interface, SVRC DCS, The University of Queensland, Technical Report No. 99-3, March 999. [7] Winther R., Johnsen O., Gran B., Security assessments of safety critical systems using HAZOPs, Proceedings of Computer Safety, Reliability and Security, 20 th International Conference SAFECOMP 200, Springer Lecture Notes in Computer Science 287, pp [8] Katedra Zastosowań Informatyki Politechniki Gdańskiej, The billing system for a telephone exchange (STACT) UML Model, raport wewnętrzny, [9] Case Study II: Finding Defects Earlier Saves Big $$$, (strona odwiedzona ).