Wspomaganie wykrywania defektów w modelach obiektowych
Transkrypt
Wspomaganie wykrywania defektów w modelach obiektowych
Wersja postprint artykułu zaprezentowanego na I Krajowej Konferencji Technologie Informacyjne 2003 i opublikowanego w Zeszytach Naukowych Wydz. ETI Politechniki Gdańskiej: Technologie Informacyjne nr 2, s. 379-390. J. GÓRSKI, A. JARZĘBOWICZ, R. LESZCZYNA, J. MILER, M. OLSZEWSKI Katedra Zastosowań Informatyki Wydział Elektroniki, Telekomunikacji i Informatyki Politechnika Gdańska WSPOMAGANIE WYKRYWANIA DEFEKTÓW W MODELACH OBIEKTOWYCH Modelowanie z zastosowaniem metodyki obiektowej jest powszechnie wykorzystywane w projektach informatycznych i stanowi jeden z kluczowych etapów procesu wytwarzania oprogramowania. Problemem związanym z modelowaniem jest łatwość wprowadzenia do modeli obiektowych defektów wynikających np. ze złego rozpoznania dziedziny problemowej, przyjmowania nieświadomych założeń lub zwykłych pomyłek edycyjnych. Istotne jest szybkie wykrycie i poprawienie jak największej liczby defektów modelu, zanim zostaną na jego podstawie stworzone kolejne reprezentacje systemu. Zapewnienie skuteczności procesu wykrywania defektów wymaga opracowania odpowiednich metod analizy, natomiast potrzeba zmniejszenia pracochłonności procesu sugeruje jak najszersze zastosowanie narzędzi wspomagających. Artykuł wyjaśnia najważniejsze pojęcia i zasady działania nowej metody analitycznej o nazwie UML-HAZOP oraz prezentuje narzędzie wspomagające stosowanie tej metody. 1. WPROWADZENIE Rezultatem projektu informatycznego jest pewna liczba produktów, wśród których znajduje się, poza samym kodem, dokumentacja dotycząca wytworzonego systemu a także procesu wytwórczego. W zależności od przyjętego cyklu wytwarzania, ustaleń organizacyjnych, standardów, wykorzystywanych narzędzi itp. dokumentacja taka będzie mocno zróżnicowana, zarówno pod względem zakresu i zawartości, jak również formy poszczególnych wchodzących w jej skład dokumentów. Istnieją jednak pewne produkty charakterystyczne dla wszystkich (lub prawie wszystkich) projektów. Można do nich zaliczyć przede wszystkim kolejne reprezentacje systemu, poczynając od specyfikacji wymagań, a kończąc na kodzie. Jedną z takich powszechnie stosowanych reprezentacji pośrednich stanowią modele systemu (biznesowe, analityczne, projektowe) tworzone obecnie głównie za pomocą metodyki obiektowej. 2 J. Górski i inni Jednym z najistotniejszych problemów związanych z przedsięwzięciami informatycznymi jest obecność defektów w wytworzonych produktach. Problem ten nie ogranicza się bynajmniej jedynie do ostatecznej reprezentacji systemu czyli kodu. Doświadczenia wskazują, że defekty oprogramowania powstają w różnych etapach przedsięwzięcia informatycznego i występują w produktach wynikających z tych etapów. Defekty nie wykryte na danym etapie zostają przeniesione do produktów kolejnych etapów. Jako typowy przykład takiego defektu i jego propagacji można przytoczyć błąd w specyfikowaniu wymagań. Obserwowana jest prawidłowość, że im później dany defekt zostanie wykryty i usunięty w stosunku do etapu, w ramach którego powstał, tym większe są związane z tym koszty i nakłady pracy. Stanowi to silną motywację do „wzmacniania” działań analitycznych, ukierunkowanych na wykrywanie defektów w tych reprezentacjach tworzonego oprogramowania, które powstają najwcześniej w ramach cyklu wytwórczego. Za taką reprezentację można z całą pewnością uznać obiektowy model systemu. Modele obiektowe stanowią interesujący przedmiot badań dotyczących metod wykrywania defektów. Przyczyną jest fakt stosowania do ich tworzenia języków modelowania o graficznej, częściowo sformalizowanej składni. Możliwe jest zatem precyzyjniejsze określenie kryteriów i zasad analizy, niż ma to miejsce w przypadku czystego lub częściowo ustrukturalizowanego tekstu, jaki występuje w większości dokumentów projektowych. Dodatkowym, silnym argumentem za podjęciem badań w tym kierunku jest fakt szerokiego rozpowszechnienia notacji Unified Modeling Language (UML), którą można obecnie określić mianem nieformalnego standardu. Stwarza to sytuację, w której modele tworzone w ramach niemal każdego projektu informatycznego są jednorodne pod względem zastosowanych środków modelowania. Wśród technik stosowanych w celu wykrywania defektów w dokumentacji można wymienić szeroką gamę przeglądów, różniących się pomiędzy sobą sposobem organizacji i stopniem sformalizowania. W przypadku analizy modeli obiektowych najlepszym rozwiązaniem wydaje się zastosowanie przeglądu sformalizowanego, z wykorzystaniem list kontrolnych - czyli inspekcji. Jest to uwarunkowane, z jednej strony, trudnością przeanalizowania skomplikowanego modelu o dużej liczbie powiązań w sytuacji braku określonych (w postaci list kontrolnych) kryteriów analizy i braku narzuconej systematyki procesu. Z drugiej strony, wobec omówionego już faktu stosowania wspólnego języka modelowania, listy kontrolne „pokrywające” typowe defekty są rozwiązaniem, które wręcz narzuca się samo. Wychodząc z powyższych rozważań, opracowano nową metodę analizy nazwaną UML-HAZOP, której skrótowy opis znajduje się w rozdziale 2 niniejszego artykułu. Analiza modeli pod kątem wykrywania defektów stanowi kosztowny proces wymagający udziału ludzi i pochłaniający znaczne zasoby. Dlatego też rzeczą bardzo pożądaną jest wprowadzenie automatyzacji niektórych działań, w takim zakresie jak to tylko możliwe. Dyskusję możliwego zakresu wspomagania przeprowadzono w rozdziale 3. Opierając się na jej wynikach, zaprojektowano i zaimplementowano narzędzie wspomagające prowadzenie analiz metodą UML-HAZOP. Artykuł przedstawia narzędzie zarówno od strony funkcjonalności oraz zakresu wspierania poszczególnych obszarów metody (rozdział 4), jak też od strony architektury i technologii użytych do jego budowy (rozdział 5). 2. METODA UML-HAZOP Podczas tworzenia obiektowego modelu systemu nietrudno jest wprowadzić do niego różnego rodzaju defekty. Należy tu podkreślić, że najistotniejsza w tym przypadku klasa Wspomaganie wykrywania defektów w modelach obiektowych 3 defektów wiąże się z błędnym odwzorowaniem modelowanej rzeczywistości (wynikającym np. ze złego rozpoznania dziedziny problemowej, przyjmowania nieświadomych założeń lub pomyłek analityka). Możliwe są oczywiście również defekty związane jedynie ze składnią, jednak ich wykrywanie lub zapobieganie im (np. przez odpowiednie funkcje środowiska CASE) jest dużo łatwiejsze, przez co stanowią one zdecydowanie mniej interesujący temat. Tak więc w analizie należy przede wszystkim zwracać uwagę na semantykę a mniej na składnię modelu. Istotą modelowania jest wyrażenie pewnego wycinka rzeczywistości za pomocą elementów określonej notacji. Możliwa jest wobec tego analiza poprawności modelu poprzez ocenę tego, na ile prawidłowe (w sensie właściwego odwzorowania rzeczywistości) jest użycie poszczególnych elementów modelu. Analityczna metoda wykrywania defektów powinna zatem w wyraźny sposób odnosić się do notacji, w której tworzone są modele. Opracowując metodę zorientowaną na konkretną notację można skonstruować listy kontrolne zawierające potencjalne defekty związane ze stosowaniem poszczególnych elementów notacji. Utworzenie takich list nie jest jednak zadaniem prostym. W proponowanym przez autorów podejściu zdecydowano się sięgnąć do stosowanej w wielu obszarach problemowych metody HAZOP (ang. Hazard and Operability Studies). Metoda ta wywodzi się z przemysłu chemicznego, natomiast na początku lat 90 została również przystosowana do potrzeb inżynierii oprogramowania [4]. Metoda koncentruje się (w swojej pierwotnej propozycji) na systematycznym badaniu połączeń występujących w modelu systemu. W przypadku przemysłu chemicznego takimi połączeniami są po prostu rury wchodzące w skład instalacji chemicznych. W dziedzinie oprogramowania pojęcie może mieć różne interpretacje – mogą to być np. fizyczne kanały komunikacji, ale również pewne połączenia logiczne np. związek na diagramie klas bądź tranzycja na diagramie stanów. Sama idea metody jest bardzo prosta. Wykorzystywany jest zestaw słów kluczowych mających za zadanie w sposób ogólny sugerować wszelkie możliwe błędy i odchylenia od prawidłowego stanu, np. NO, LESS, OTHER THAN, LATE. W każdym badanym połączeniu wyróżniane są pewne jego atrybuty – możliwie atomowe, dobrze określone fragmenty lub własności. Zestawienie poszczególnych słów kluczowych z poszczególnymi atrybutami daje listę potencjalnych dewiacji związanych z danym połączeniem. Metoda HAZOP była i wciąż jest z powodzeniem stosowana w różnych dziedzinach inżynierskich, w tym w inżynierii oprogramowania, choć do tej pory nastawiona była głównie na wykrywanie zagrożeń w ramach analizy bezpieczeństwa (ang. safety) systemu. Metoda UML-HAZOP stanowi adaptację HAZOPu do analizy modeli wyrażonych w notacji UML. W chwili obecnej ukończone zostały prace nad analizą diagramów klas, dalsze prace zmierzają do rozszerzenia metody na pozostałe diagramy UML. W analizie diagramów klas, uwaga koncentrowana jest na występujących w nich połączeniach czyli związkach (ang. relationship), w szczególności związkach typu Association i Generalization. Związki te posiadają pewne atrybuty np. aggregation, name, multiplicity itd. Do związków i ich poszczególnych atrybutów odnoszone są słowa kluczowe z zestawu prezentowanego w tablicy 1. Nie wszystkie takie zestawienia dają sensowny rezultat, jednak niektóre po nadaniu odpowiedniej interpretacji sugerują potencjalne defekty. Przykładowe interpretacje dotyczące atrybutu aggregation podano w tablicy 2. Wszystkie sensowne interpretacje (dla tych atrybutów, które chcemy rozpatrywać) tworzą listę kontrolną (tzw. tabelę HAZOP) dla związku danego typu np. Association. Analiza diagramu polega na zastosowaniu do każdego związku obecnego na diagramie odpowiedniej dla jego typu listy 4 J. Górski i inni kontrolnej i odnotowaniu, czy defekty sugerowane przez poszczególne pozycje listy rzeczywiście mają miejsce dla tego konkretnego związku. Tablica 1 Ogólne słowa kluczowe HAZOPu Słowo kluczowe Ogólna interpretacja NO Kompletny brak zamierzonego rezultatu, przy braku innych efektów MORE Zbyt wysoka wartość parametru ilościowego LESS Zbyt niska wartość parametru ilościowego AS WELL AS Oprócz zamierzonego rezultatu otrzymano inny, dodatkowy PART OF Zamierzony rezultat został uzyskany tylko częściowo REVERSE Otrzymano logiczne przeciwieństwo zamierzonego rezultatu OTHER THAN Brak zamierzonego rezultatu, ale otrzymano inny, odmienny EARLY Zdarzenie zachodzi wcześniej niż zamierzono LATE Zdarzenie zachodzi później niż zamierzono BEFORE Zdarzenie zachodzi przed innym zdarzeniem, w stosunku do którego miało być późniejsze AFTER Zdarzenie zachodzi po innym zdarzeniu, w stosunku do którego miało być wcześniejsze Tablica 2 Interpretacje dla atrybutu AssociationEnd.aggregation Słowo kluczowe Interpretacja NO Nie zaznaczono agregacji, która powinna wystąpić AS WELL AS Zaznaczono agregację, która w rzeczywistości nie ma miejsca OTHER THAN Zaznaczono niewłaściwy typ agregacji tzn. silną zamiast słabej lub odwrotnie MORE Agregacja obejmuje zbyt wiele klas składowych, niektóre nie powinny wchodzić w jej skład LESS Agregacja nie obejmuje niektórych klas (obecnych na diagramie lub też nie), które powinny wchodzić w jej skład Metoda UML-HAZOP jest realizowana w ramach zdefiniowanego i podlegajacego zarzadzaniu procesu. Struktura tego procesu została przedstawiona na rysunku 1. Wspomaganie wykrywania defektów w modelach obiektowych Planowanie Przygotowanie Analiza Weryfikacja Korekta Audyt korekty 5 Zakończenie ZARZĄDZANIE Rys. 1. Struktura procesu analizy UML-HAZOP Proces rozpoczyna się w chwili, gdy podjęta zostaje decyzja o potrzebie przeprowadzenia analizy ukończonych modeli obiektowych. Pierwszym krokiem jest planowanie całego procesu, w ramach którego tworzony jest harmonogram, wyznaczani uczestnicy i dobierane odpowiednie listy kontrolne. Etap przygotowania polega na zapoznaniu się analityków w niezbędnym zakresie z dokumentacją projektową, a także z metodą analizy (jeśli nie jest znana). W etapie analizy następuje systematyczna kontrola modelu z wykorzystaniem list kontrolnych i rejestracja wszystkich wykrytych defektów. Lista defektów trafia następnie do autora modelu, który dokonuje ich weryfikacji – potwierdza lub zaprzecza ich zasadności. Potwierdzone defekty są poprawiane przez autora w etapie korekty, po zakończeniu którego następuje audyt mający na celu sprawdzenie, czy na pewno wszystkie defekty zostały usunięte. Przy zakończeniu procesu następuje jego formalne zamknięcie, przekazanie końcowego produktu (poprawionego modelu) oraz zebranie danych podsumowujących (liczby wykrytych defektów, pracochłonność itp.). Z uwagi na fakt, iż w procesie uczestniczy kilka osób i pochłania on pewne zasoby, musi on podlegać zarządzaniu przez wyznaczoną do tego celu osobę. Z uwagi na ograniczoną objętość artykułu powyższy opis metody jest bardzo skrótowy. Dokładny opis metody oraz jej wyników eksperymentalnych można znaleźć w [2, 3]. 3. DYSKUSJA ZAKRESU AUTOMATYZACJI Automatyzacja analiz UML-HAZOP poprzez wykorzystanie narzędzia wspomagającego jest możliwa jedynie w ograniczonym zakresie. Podjęcie decyzji odnośnie tego, czy dany defekt sugerowany w liście kontrolnej rzeczywiście występuje w analizowanym połączeniu często wymaga odwołania sie do wiedzy, która nie jest jawnie reprezentowana w modelu i która musi byc interpretowana przez analityka. Automatyzacja takich analiz byłaby możliwa jedynie w bardzo ograniczonym zakresie i w przypadkach stosunkowo prostych, majacych jednoznaczną interpretację. Dzięki temu właśnie możliwe stało się zautomatyzowanie stosowania metody HAZOP w przemyśle chemicznym [6]. Metoda UMLHAZOP nie czyni jednak żadnych założeń co do rodzaju analizowanych systemów ani elementów wchodzących w ich skład. Koncepcja metody opiera się na właściwościach notacji UML, za pomocą której modelowane mogą być dowolne systemy. Stąd decyzja odnośnie tego co jest, a co nie jest defektem wymaga udziału człowieka. Wspomaganie narzędziowe może jednak dotyczyć pewnych wybranych obszarów metody. Podstawowym obszarem procesu analizy, z którego warto wyłączyć człowieka jest przygotowanie tabel HAZOP. Jest to czynność typowo mechaniczna, a przy tym żmudna i w pewnym stopniu podatna na błędy (np. pominięcie jakiegoś połączenia). Stworzenie narzędzia generującego tabele HAZOP na podstawie modelu wykonanego za pomocą systemu wspomagającego modelowanie (CASE) pozwoliłoby zaoszczędzić sporo czasu i wy- 6 J. Górski i inni siłku, a ponadto zapewniłoby kompletność tabel i brak w nich błędów. Co więcej, za pomocą prostego algorytmu można eliminować zbędne wiersze tabel HAZOP, które dla danego konkretnego połączenia sugerują defekty, które po prostu nie mogą mieć miejsca. Na przykład, jeśli projektant nie zaznaczył agregacji na końcu związku typu Association, nie warto rozważać potencjalnego defektu polegającego na błędnym rodzaju tejże agregacji (czy powinna być słaba czy silna). Przy ręcznym sporządzaniu tabel HAZOP nie dokonuje się takiej eliminacji, gdyż jest to nieopłacalne z punktu widzenia wydajności; po prostu kopiowane są całe tabele z wszystkimi możliwymi wierszami. System wspomagający może również wspomagać prowadzenie analiz (wprowadzanie decyzji co do zasadności poszczególnych sugestii defektów, wprowadzanie komentarzy). Informacje te są przechowywane w bazie danych systemu, możliwe jest również sporządzanie na ich podstawie różnego rodzaju statystyk. Ważnym zadaniem jest również wspomaganie przez system pracy grupowej. Do tego celu tworzony system powinien być narzędziem sieciowym. Umożliwia to komunikację i wymianę informacji pomiędzy różnymi członkami zespołu (uczestnikami analiz) bez konieczności przebywania w jednym miejscu. 4. FUNKCJONALNOŚĆ NARZĘDZIA 4.1. Zakres funkcjonalności Powyższe wnioski zostały uwzględnione przy określaniu zakresu funkcjonalności narzędzia. Odnosząc funkcjonalność narzędzia do procesu analiz UML-HAZOP przedstawionego w rozdziale 2 można zauważyć, że wspomaganie dotyczy obszarów: planowania, analizy, weryfikacji a także zarządzania procesem. W etapie planowania narzędzie umożliwia stworzenie nowego projektu, wczytanie w ramach projektu diagramów mających być obiektami analizy i utworzenie dla nich w sposób automatyczny tabel HAZOP. Ponadto możliwe jest przydzielenie do projektu wybranych użytkowników i nadanie im określonych ról. Analiza i weryfikacja prowadzone są praktycznie w całości z wykorzystaniem narzędzia. Decyzje dotyczące defektów są wprowadzane przez użytkowników do systemu i w nim przechowywane. W zakresie zarządzania procesem analizy narzędzie umożliwia zarządzanie uczestnikami procesu (przydział do projektu, wykluczenie, zmiana ról) a także zarządzanie projektami i diagramami. 4.2. Użytkownicy i role System jest dostepny jedynie dla zarejestrowanych użytkowników. Przed rozpoczęciem pracy następuje identyfikacja użytkownika za pomocą hasła. Zakładaniem i utrzymaniem kont w systemie zajmuje się administrator, dla którego jest to jedyny obszar pracy z systemem (nie uczestniczy on w procesie analizy ani nie ma wglądu w żadne dane). W związku ze zróżnicowaniem obowiązków, jakie pełnią uczestnicy procesu analiz, w narzędziu wprowadzono kilka predefiniowanych ról, do których mogą być przypisani użytkownicy: • Menedżer - osoba odpowiadająca za całość analiz dokumentacji określonego projektu. Użytkownik ten otwiera i zamyka cały projekt oraz decyduje o udostępnieniu jego Wspomaganie wykrywania defektów w modelach obiektowych • • • 7 zawartości innym użytkownikom. Zawartość ta może być udostępniana z możliwością wprowadzania danych (dla Analityka i Projektanta) lub tylko do odczytu (dla Obserwatora). Analityk - Użytkownik dokonujący analizy i dokumentujący wyniki w tabeli HAZOP. Projektant - Autor modeli poddawanych analizie. Jego zadaniem jest weryfikacja wyników analizy i uwzględnienie ich w modelach. Obserwator - Użytkownik, który przegląda wyniki analiz w celach np. szkoleniowych lub kontrolnych, ale nie uczestniczy bezpośrednio w analizach. Nie wprowadza żadnych informacji do systemu. Użytkownikowi przydzielana jest rola w ramach danego projektu, nie całego systemu. W ramach projektu możliwe jest przydzielenie użytkownikowi wielu ról (np. Menedżer i Analityk) a także przydzielenie wielu użytkowników do danej roli (z wyjątkiem Menedżera, który jest z założenia tylko jeden). Przydział ról jest dokonywany po raz pierwszy w chwili utworzenia nowego projektu, ale może być potem w dowolnej chwili zmieniony przez Menedżera. 4.3. Zarządzanie projektami i diagramami Struktura przechowywanych w systemie informacji została zaprojektowana wielopoziomowo. Odrębny proces analizy UML-HAZOP realizowany w danym projekcie informatycznym jest w systemie utożsamiany z pojęciem projektu. Projekt ma określonego Menedżera i przydzielonych innych użytkowników. „Wewnątrz” projektu przechowywane są diagramy (może ich być wiele). Diagram to struktura danych reprezentująca pojedynczy diagram obiektowy wykonany przez określonego Projektanta. Z kolei „wewnątrz” diagramu znajdują się wygenerowane automatycznie tabele HAZOP dotyczące tego diagramu, w których zapisywane są następnie rezultaty analizy i weryfikacji. Utworzenie nowego projektu jest realizowane przez Menedżera i może być utożsamiane z rozpoczęciem nowego procesu analizy. Utworzenie w systemie diagramu polega na zaimportowaniu danych diagramu z pliku utworzonego przez środowisko CASE i wygenerowaniu na ich podstawie tabel HAZOP (patrz rozdział 4.4). Zarówno projekty, jak i diagramy mogą być usuwane wraz z całą zawartością. Możliwe jest również ich zablokowanie oraz odblokowanie. Zablokowany diagram czy projekt pozostaje w systemie i jest w dalszym ciągu widoczny, ale nie można wprowadzać do niego żadnych zmian – jest to swego rodzaju zamrożenie stanu prac w danym momencie. 4.4 Importowanie danych z narzędzia CASE Danymi wejściowymi do analizy UML-HAZOP są modele UML utworzone w ramach projektu podlegającego inspekcji. Import modelu ze środowiska CASE (konkretnie Rational Rose) został rozwiązany poprzez pobranie pliku zawierającego ten model. Projektant tworząc nowy diagram podaje ścieżkę do pliku MDL, w którym Rose przechowuje komplet danych o modelu. Po odczytaniu pliku następuje jego automatyczna interpretacja i wydobycie kompletnej listy zawartych w nim diagramów UML. System wyświetla użytkownikowi zestawienie zawierające tytuł każdego diagramu, informację o jego typie oraz nazwę pakietu w jakim został umieszczony, dając możliwość wyboru, które z nich mają zostać przetworzone na tabele HAZOP. Narzędzie UML-HAZOP w obecnej postaci wspiera jedynie analizę diagramów klas i jedynie te diagramy użytkownik zobaczy na liście wyboru. 8 J. Górski i inni Istnieje też możliwość nadania diagramom własnych nazw, w przeciwnym wypadku pozostawione zostaną oryginalne (nie zawsze jednoznaczne) tytuły wydobyte z dokumentu Rose. Dalsze przetwarzanie danych z diagramów odbywa się już całkowicie automatycznie. System odczytuje z analizowanego dokumentu zawartość przetwarzanego diagramu, w szczególności listę wszystkich przedstawionych na nim związków. Następnie za pomocą wbudowanej listy możliwych defektów, dla każdego związku generowana jest osobna tabela HAZOP. Przypadki zbędnych wierszy tabeli, dotyczących defektów, które nie mogą wystąpić w związku są rozpoznawane przez narzędzie, tak więc w rezultacie użytkownik otrzymuje zestaw minimalnych tabel HAZOP gotowych do analizy. 4.5. Analiza i weryfikacja tabel HAZOP Tabele HAZOP wygenerowane przez narzędzie mogą być poddane analizie. Użytkownik posiadający w projekcie uprawnienia Analityka wybiera jeden z diagramów utworzonych uprzednio przez Projektanta, otrzymując listę tabel utworzoną dla tego diagramu. Każda z tabel reprezentuje jeden ze związków i oznaczona jest jego nazwą a także nazwami elementów (klas, obiektów itp.) które on łączy. Dzięki temu można w łatwy sposób odnieść rozpatrywaną tabelę do konkretnego fragmentu badanego diagramu. Dla każdego wiersza tabeli HAZOP, zadaniem analityka jest podjęcie decyzji co do tego, czy reprezentowana przez ten wiersz sugestia defektu jest uzasadniona (czy jego zdaniem diagram zawiera defekt). W tym celu Analityk ma do dyspozycji dwa przyciski; nie wybranie żadnego z nich oznacza brak decyzji i de facto nie ukończoną inspekcję. Przeanalizowany wiersz jest także oznaczany kolorem zależnym od podjętej decyzji – po pierwsze ułatwia to zorientowanie się, na które wiersze Analityk zakwalifikował jako potencjalne defekty, a po drugie pomaga zauważyć wiersze jeszcze nie zanalizowane. Każdy zbadany wiersz Analityk może również opatrzyć komentarzem wyjaśniającym naturę jego wątpliwości. Adresatem owych komentarzy jest najczęściej Projektant, do którego będzie następnie należało zweryfikowanie wyników analizy. Domyślnie Projektant jest autorem modelu poddawanego inspekcji i do niego należy potwierdzenie podejrzeń Analityka lub ich obalenie. Interfejs pozostający do dyspozycji Projektanta jest niemal identyczny z tym używanym przy analizie diagramów. Dla każdego zidentyfikowanego jako potencjalny defekt wiersza tabeli należy podjąć decyzję, czy defekt w istocie istnieje, czy też wątpliwości Analityka nie były uzasadnione. Projektant nie rozważa już wierszy oznaczonych w fazie analizy jako poprawne. I tutaj również narzędzie używa kolorów do odróżnienia wierszy z potwierdzonymi defektami od tych uznanych jednak za nieuzasadnione. Po podjęciu decyzji Projektant może zweryfikowany wiersz dodatkowo skomentować np. aby sprecyzować naturę defektu lub wyjaśnić wątpliwości Analityka. Komentarze Projektanta są wyświetlane razem z tymi wprowadzonymi przez Analityka, tworząc zapis dyskusji nad projektem poddawanym inspekcji. Do momentu przeprowadzenia weryfikacji przez Projektanta, Analityk może dowolnie zmieniać swoją decyzję oraz treść komentarzy. Podobnie weryfikujący ma możliwość edycji swoich zmian w tabelach HAZOP do chwili ich zamknięcia w narzędziu, co jest równoważne zakończeniu inspekcji i zamrożeniu wyników. Przez cały czas trwania inspekcji użytkownicy z uprawnieniami Obserwatora mają możliwość wglądu w bieżący stan tabel HAZOP posługując się jednorodnym interfejsem, podobnym do używanego przez strony bezpośrednio przeprowadzające analizę. Wspomaganie wykrywania defektów w modelach obiektowych 9 5. OPIS ARCHITEKTURY Narzędzie UML-HAZOP jest aplikacją internetową skonstruowaną w oparciu o model przetwarzania klient – serwer. Wzorując się na koncepcjach wypracowanych dla systemu zarządzania ryzykiem RiskGuide [5], określono wyraźny podział funkcjonalności systemu pomiędzy obie strony. Strona serwera odpowiada za odbiór, przetwarzanie oraz przechowywanie danych a także za zapewnienie współbieżnego dostępu do usług. Po stronie klienta natomiast realizowana jest jedynie interakcja z użytkownikiem. Ważną cechą systemu jest integracja ze środowiskiem CASE jako źródłem danych o diagramach UML składających się wspólnie na dokumentację podlegającą inspekcji. Aktualnie eksploatowana wersja pilotażowa systemu współpracuje jedynie z narzędziem CASE Rational Rose. Stacja robocza, której używa indywidualny użytkownik aby uzyskać zdalny dostęp do narzędzia UML-HAZOP, musi być przede wszystkim wyposażona w przeglądarkę internetową oraz dostęp do Internetu. Nie jest używane żadne dedykowane oprogramowanie po stronie klienta. Dzięki takiemu podejściu zapewniono szerokie możliwości współpracy z narzędziem UML-HAZOP z praktycznie dowolnej współczesnej platformy systemowej bez potrzeby instalacji dodatkowego oprogramowania. Wejściowe dane do analizy UMLHAZOP przybierają postać plików MDL narzędzia Rational Rose. Dokumenty Rose przygotowane przez użytkownika są wysyłane w postaci oryginalnej lub po kompresji w formacie ZIP do serwera, który następnie zajmuje się ich przetwarzaniem na właściwe dane do analizy. Narzędzie Rational Rose nie jest wprawdzie bezpośrednio używane w procesie inspekcji i nie jest wymagane do pracy z systemem UML-HAZOP, jednak może okazać się przydatne do przeglądania diagramów i modeli w trakcie analizy. Rysunek 2 przedstawia konfigurację komputera współpracującego z narzędziem oraz schemat komunikacji klienta z serwerem. Rys. 2. Architektura systemu UML-HAZOP widziana z perspektywy klienta Dane z dokumentu Rose są przetwarzane i przechowywane w całości na serwerze UML-HAZOP, którego konfiguracja przedstawiona została na rysunku 3. Centralnym elementem systemu jest serwer WWW przetwarzający zapytania użytkowników. Dla zapewnienia bezpieczeństwa komunikacji, odbywa się ona wyłącznie za pośrednictwem protokołu HTTPS. Możliwości wielowątkowej pracy serwera WWW pozwalają wielu użytkownikom na współbieżną pracę z narzędziem. Logika biznesowa aplikacji UML-HAZOP jest 10 J. Górski i inni obsługiwana przez skrypty Active Server Pages (ASP) współpracujące z komponentami ActiveX i klasami Javy. Wyniki zapytań użytkownika są zwracane przez skrypty ASP jako strony HTML i wysyłane przez serwer WWW do komputera klienta. Aby zapewnić trwałe i niezawodne przechowywanie danych użyto transakcyjnego systemu DBMS (SQL Server). Procedury wbudowane hermetyzują wewnętrzną strukturę danych tak, że jedynym sposobem uzyskania dostępu do danych jest skorzystanie ze zdefiniowanych interfejsów. Rys. 3. Architektura systemu UML-HAZOP widziana z perspektywy serwera Wewnętrzne mechanizmy systemu UML-HAZOP zilustrowane są na rysunku 4. Dokumenty Rational Rose, które użytkownik wysyła do serwera UML-HAZOP, zawierają dane o modelach i diagramach UML w zamkniętym formacie, charakterystycznym jedynie dla produktu firmy Rational. Aby w przyszłości umożliwić integrację z pakietami CASE innych producentów należało wprowadzić wewnętrzny format pośredni jako interfejs między dokumentami lub repozytoriami o różnej strukturze a podsystemami narzędzia UMLHAZOP zajmującymi się właściwym przetwarzaniem danych. Możliwości jednoznacznej reprezentacji modeli UML dostarczył język XML, a właściwie jego odmiana – XMI. Przetwarzanie dokumentów XML umożliwiają pewne pakiety Javy, charakteryzujące się w opinii autorów artykułu bardzo dobrą użytecznością. W związku z tym podjęta została również decyzja o poszerzeniu zakresu użycia technologii XML w systemie. Poza przechowywaniem danych o modelach UML jest ona również wykorzystywana do obsługi większości wewnętrznych interfejsów między poszczególnymi podsystemami. Informacje o modelach, które mają zostać poddane analizie, już po przekształceniu do pośredniego formatu XMI, zostają przetworzone do postaci tabel HAZOP i zapisane w bazie danych. Użytkownik w procesie inspekcji komunikuje się za pomocą przeglądarki z serwerem WWW, otrzymując wizualizację aktualnego stanu analizy w postaci stron HTML. Polecenia użytkownika odebrane przez serwer jako zapytania HTTP są tłumaczone przez skrypty Active Server Pages uaktualniające w razie potrzeby stan bazy danych. Informacje te przechowywane są w sposób trwały i mogą być wykorzystane w dowolnym momencie w przyszłości, a także udostępnione innym użytkownikom na przykład w celu zapoznania się z wynikami analiz. Wspomaganie wykrywania defektów w modelach obiektowych 11 Rys 4. Wewnętrzne przetwarzanie danych w systemie UML-HAZOP 6. PODSUMOWANIE System UML-HAZOP został opracowany w Katedrze Zastosowań Informatyki w okresie od maja do grudnia 2002 roku. Prace nad nim stanowiły część udziału Katedry w projekcie 5. Programu Ramowego Unii Europejskiej IST-DRIVE 1999-12040 [1] dotyczącym zastosowań technologii informacyjnych w procesie dystrybucji leków. System został wykorzystany przy tworzeniu dowodu zaufania (ang. trust case) dla rozwiązań proponowanych w projekcie DRIVE. Wykorzystanie to polegało na przeprowadzeniu analiz modeli niektórych kluczowych rozwiązań (np. elektronicznej karty pacjenta) w celu oceny ich poprawności i włączeniu wyników analizy do argumentacji dowodu zaufania. Prezentowane narzędzie spełniło formułowane wobec niego oczekiwania. Jego wykorzystanie pozwoliło na zmniejszenie pracochłonności związanej z procesem analizy. Nastąpiła praktycznie całkowita redukcja nakładów pracy związanych z przygotowaniem tabel HAZOP. Osiągnieto również poprawę w obszarach analizy i weryfikacji, poprzez automatyczną eliminację części wierszy tabel HAZOP oraz zastosowanie odpowiedniego interfejsu wspomagającego pracę użytkownika. Zastosowanie architektury klient – serwer i rozwiązań internetowych pozwala na pracę z narzędziem niezależnie od miejsca pobytu użytkownika. Efektem jest poszerzenie możliwości współpracy i wymiany informacji, co jest szczególnie istotne jeśli chodzi o projekty rozproszone, realizowane przez wielu partnerów. Dzięki tym rozwiązaniom możliwe było, w naszym przypadku, wykonanie części analiz podczas pobytu w Hospitale San Raffaele w Mediolanie (instytucji koordynującej realizację projektu DRIVE). Inne analizy prowadzone były równolegle przez pozostałą część zespołu przebywającą w Polsce. Narzędzie UML-HAZOP pozwoliło na wymianę informacji w tym zakresie pomiędzy obiema grupami. W przyszłości planowane jest rozwijanie narzędzia wraz z postępem badań nad samą metodą. Dotyczy to przede wszystkim możliwości analizy innych typów diagramów UML, poza omawianymi diagramami klas. Możliwa jest także integracja narzędzia z innymi środowiskami CASE. W docelowej, pełnej wersji planowane jest również umożliwienie prowadzenia analiz według innych kryteriów (inny dobór atrybutów i słów kluczowych, formułowanie innych interpretacji) Kryteria takie mogłyby pochodzić z innych metod wywodzących się z HAZOPu np. [7], bądź też być definiowane bezpośrednio przez użytkownika. 12 J. Górski i inni BIBLIOGRAFIA [1] DRug In Virtual Enterprise, EU IST-DRIVE 1999-12040 research project, http://www.e-mathesis.it/Drive. [2] Górski J., Jarzębowicz A., Wykrywanie anomalii w modelach obiektowych za pomocą metody UML-HAZOP, w mat. IV Krajowej Konferencji Inżynierii Oprogramowania, Poznań 2002. [3] Górski J., Jarzębowicz A., Detecting defects in object-oriented diagrams using UML-HAZOP, Foundations of Computing and Decision Sciences, vol. 27 (2002) no. 4. [4] HAZOP Studies on Systems Containing Programmable Electronics, MoD Defence Standard 0058, issue 2, 2000. [5] Miler J., Górski J., Implementing risk management in software projects, w mat. III Krajowej Konferencji Inżynierii Oprogramowania, Otwock, 2001. [6] Venkatasurbramanian V., Zhao J., Viswanathan S., Intelligent systems for HAZOP analysis of complex process plants, Computers and chemical engineering 24 (2000). [7] Winther R., Johnsen O., Gran B., Security assessments of safety critical systems using HAZOPs, Proceedings of Computer Safety, Reliability and Security, 20th International Conference SAFECOMP 2001, Springer Lecture Notes in Computer Science 2187.