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.