Podejście obiektowe w budowie dowodu

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. 369-378.
J. GÓRSKI, A. JARZĘBOWICZ, R. LESZCZYNA,
J. MILER, M. OLSZEWSKI
Katedra Zastosowań Informatyki
Wydział Elektroniki, Telekomunikacji i Informatyki
Politechnika Gdańska
PODEJŚCIE OBIEKTOWE W BUDOWIE DOWODU
ZAUFANIA DO SYSTEMÓW INFORMATYCZNYCH
Niniejszy artykuł prezentuje obiektowe podejście w budowie dowodów zaufania dla
systemów informatycznych. Przedstawiono strukturę koncepcyjną takiego dowodu,
omówiono sposób konstrukcji drzewa dowodowego wykorzystujący analizę modeli
obiektowych badanego systemu. W artykule zaproponowano sposób tworzenia obiektowych modeli kontekstu dla rozpatrywanych żądań oraz podkreślono wagę precyzyjnego wyrażenia tego kontekstu. Ponadto omówiono zastosowanie metodologii obiektowej do opisu elementów drzewa dowodu zaufania. Na zakończenie podsumowano
praktyczne zastosowanie proponowanej metody w projekcie IST-DRIVE 5. Programu
Ramowego Unii Europejskiej.
1. WPROWADZENIE
Współczesne systemy komputerowe wspomagają człowieka w różnych obszarach jego
działalności. W skrajnych przypadkach, wady oprogramowania wykorzystanego w takich
systemach mogą doprowadzić do niepożądanych, czasem wręcz katastrofalnych skutków.
Stąd w wielu obszarach zastosowań informatyki kluczowe znaczenie ma zapewnienie wiarygodności systemu – zagwarantowanie, że projektowany system nie doprowadzi (często
pośrednio, poprzez długi łańcuch zdarzeń) do wypadku. Jedną z metod tworzenia takiej
gwarancji jest tzw. Dowód Zaufania (ang. Trust Case), którego zadaniem jest dostarczenie
kompletnego i przekonującego argumentu uzasadniającego zaufanie do danego systemu
informatycznego. Metodyka budowania oraz reprezentacji takich dowodów nie została
jeszcze dobrze opracowana i stanowi wciąż obszar aktywnych badań [2, 10, 11, 12]. Obiecującym rozwiązaniem jest wykorzystanie podejścia obiektowego.
Metodyka obiektowa pozwala tworzyć modele rzeczywistości posługując sie zestawem dobrze określonych pojęć. Dzięki ścisłej definicji używanych do tego konstrukcji
językowych (jak powiązania, klasy, obiekty itp.) możliwość niejednoznacznej interpretacji
modeli sprowadzona została do znacząco niskiego poziomu, zachowując przy tym ich dużą
przejrzystość i czytelność. W ostatnich latach metodyka obiektowa i zwiazany z nią jezyk
UML znacznie się upowszechniły, co powoduje, że znaczenie pojęć oraz zasad budowy
modeli UML staje się coraz bardziej zrozumiałe dla osób bezpośrednio zaangażowanych w
2
J. Górski, A. Jarzębowicz, R. Leszczyna, J. Miler, M. Olszewski
projektowanie oraz użytkowanie systemów będących przedmiotem modelowania. Dzięki
temu mozna również oczekiwać, że dowody zaufania wykorzystujące język UML będą
czytelne dla szerokiego grona osób zainteresowanych.
W artykule zaprezentowano strukturę koncepcyjną dowodu zaufania budowanego na
bazie metodyki obiektowej, obejmującą powiązane ściśle zdefiniowanymi relacjami żądania, argumenty, fakty oraz założenia. Następnie przedstawiono sposób konstrukcji drzewa
dowodowego wykorzystujący analizę modeli obiektowych badanego systemu. Zaproponowano nową metodę tworzenia obiektowych modeli kontekstu dla rozpatrywanych żądań
oraz podkreślono wagę precyzyjnego wyrażenia tego kontekstu. Dla uzyskania jednoznaczności i precyzji wprowadzono nowy, półformalny język służący formułowaniu żądań i
własności kontekstu nazwany CDL (Claim Definition Language), który częściowo wywodzi się z UML. Ponadto omówiono zastosowanie metodyki obiektowej do opisu elementów
drzewa dowodu zaufania. Artykuł kończy się opisem zastosowania proponowanej metody
w praktyce.
2. STRUKTURA DOWODU ZAUFANIA
Tworzenie dowodu zaufania polega na precyzyjnym określeniu oczekiwań dotyczących wiarygodności analizowanego systemu oraz dostarczeniu materiału dowodowego
potwierdzającego ich spełnienie. Oczekiwania formułowane są w postaci tzw. żądań (ang.
claims). Stopień spełnienia żądań świadczy o wiarygodności systemu. Model UML opisujący elementy dowodu zaufania oraz relacje między nimi pokazany jest na Rys. 1 (strzałki
wskazują kierunek związków). Model bazuje na koncepcjach projektu UE SHIP [1].
Żądanie
< wspiera
używa >
Argument
Reguła wnioskowania
przywołuje >
Mat. dowodowy
Założenie
Fakt
udokumentowane w >
Mat. źródłowy
Rys. 1. Model pojęciowy dowodu zaufania
Materiał dowodowy zawiera następujące elementy:
 Fakty, np. w postaci udokumentowanych decyzji projektowych czy wyników dodatkowych analiz,
 Założenia, używane w toku argumentacji i niewymagające jawnego dowodzenia
(jakkolwiek, później mogą zostać przekształcone w żądania i poparte dalszą argumentacją)
 Pod-żądania, rozwijane w dalszej części argumentacji poprzez udostępnianie argumentów je wspierających
Podejście obiektowe w budowie dowodu zaufania...
3
Fakty i założenia połączone są z odwołaniami do dokumentów, raportów, danych,
modeli, itp., umieszczanymi w dowodzie zaufania.
Elementami łączącymi żądania z odnoszącym się do nich materiałem dowodowym są
argumenty. Argumenty pozwalają określić sposób dowodzenia realizacji postulatów sformułowanych w żądaniach m.in. poprzez zdefiniowanie reguł wnioskowania [2].
Jak pokazano na rys 2. dowód zaufania przybiera strukturę drzewiastą (lub tworzy las
- w przypadku sformułowania wielu celów związanych z zaufaniem do systemu) o nieustalonej wysokości i kończy się w momencie, gdy wszystkie liście reprezentują fakty bądź
założenia. W przypadku, gdy w kilku miejscach dowodu pojawia się potrzeba odniesienia
do tej samej argumentacji tworzone są odwołania pozwalające uniknąć niepotrzebnej nadmiarowości treści.
cel zaufania
arg.
żądanie
zał.
żądanie
arg.
źród.
arg.
żądanie
fakt
zał.
żądanie
arg.
źród.
źród.
arg.
zał.
fakt
fakt
zał.
źród.
źród.
źród.
źród.
Rys. 2. Struktura prostego dowodu zaufania
3. KONSTRUOWANIE DOWODÓW ZAUFANIA
Konstruowanie dowodu zaufania rozpoczyna się jest od sformułowania ogólnego żądania do systemu - tzw. żądania docelowego. Dalej, tak postawione żądanie docelowe,
dekomponowane jest na bardziej szczegółowe żądania odpowiadające tzw. celom zaufania
(bezpieczeństwo, prywatność, dostępność itp.). Następnie, w toku dalszych analiz określane
są żądania w stosunku do odpowiednich, coraz bardziej szczegółowych, elementów systemu oraz pozyskiwany jest materiał dowodowy potwierdzajacy zasadność tych żądań.
Rozwiązania informatyczne będące przedmiotem analiz w dowodach zaufania są coraz
częściej budowane zgodnie z podejściem obiektowym i wyrażone w postaci modeli obiektowych (np. w języku UML) oraz kodu źródłowego oprogramowania. Dzięki temu, prezentowane podejście konstruowania argumentacji techniką z góry na dół staje się bardziej
wygodne, ze względu na hierarchiczny układ modeli obiektowych, w którym kolejne stanowią uściślenie poprzednich (rys. 3). Dowód zaufania uzyskuje w ten sposób bardziej
przejrzystą strukturę i odzwierciedla poziomy abstrakcji rozpatrywanych modeli obiektowych. Jako źródło faktów służą kolejno model biznesowy, model analityczny, model projektowy, model implementacyjny i wreszcie kod źródłowy uzupełniony o raporty z jego
4
J. Górski, A. Jarzębowicz, R. Leszczyna, J. Miler, M. Olszewski
testowania. Fakty pozyskane na podstawie modeli obiektowych są ponadto bardziej wiarygodne, gdyż cechuje je większa precyzja i jednoznaczność niż w wypadku gdy dokumentacja projektowa jest w mniejszym stopniu sformalizowana.
Model biznesowy
Model analityczny
Model projektowy
Model implementacyjny
Kod źródłowy
Rys. 3. Analiza hierarchicznych modeli obiektowych podczas budowy dowodu zaufania
Każde żądanie formułowane względem elementu systemu wyraża postulowane własności tego elementu jak również jego relacje z innymi elementami. Zbiór tych elementów
systemu (wraz z relacjami między nimi), na które powołuje się żądanie stanowi kontekst
tego żądania. Kontekst żądania definiowany jest przez przytoczone dla żądania fakty i
założenia, a eksplorowany jest poprzez formułowanie kolejnych pod-żądań.
Fakty są najczęściej formułowane w języku naturalnym. Możliwe jednak jest użycie
różnych języków modelowania wizualnego, a nawet języków formalnych. W każdym przypadku istotne jest jawne i precyzyjne określanie kontekstów żądań, ponieważ pozwala to
sterować budową dowodu zaufania oraz kontrolować zakres poszczególnych argumentów.
Nawet, kiedy fakty przywołują modele obiektowe i kontekst jest już częściowo wyrażony
obiektowo (a zatem jednoznacznie), nadal może on zawierać wieloznaczne pojęcia w języku naturalnym.
Autorzy proponują wykorzystanie podejścia obiektowego do jawnej reprezentacji kontekstów żądań poprzez budowę obiektowych modeli kontekstu. Przyjmując za bazę pojęciową byty zdefiniowane przez kontekst obiektowy, możliwe jest ponadto bardziej ścisłe
wypowiedzenie samych żądań wobec tego kontekstu. Uniwersalizm podejścia obiektowego
pozwala na objęcie nim nawet samej struktury dowodu zaufania. Proponowane metodyka
zostanie omówiona w kolejnych rozdziałach.
4. JĘZYK DEFINIOWANIA ŻĄDAŃ
Tworząc dowód zaufania, konieczne jest użycie określonego języka. Najczęściej jest
nim język naturalny (np. polski). Posłużenie się językiem naturalnym może jednak prowadzić do niepoprawnych interpretacji dowodu, wynikających z braku precyzji i jednoznaczności konstrukcji językowych. Innym problemem jest trudność kontrolowania zakresu oraz
możliwość mieszania poziomów abstrakcji, co negatywnie wpływa na rzetelność argumentacji.
Podejście obiektowe w budowie dowodu zaufania...
5
Rozwiązaniem problemu może być użycie języka formalnego (np. CSP, Z), jednak
wiąże się to ze skomplikowaniem wywodu oraz znacznym przyrostem jego objętości. Rozsądnym kompromisem byłoby znalezienie metodyki umiejscowionej mniej więcej po środku, między językami formalnymi i językiem naturalnym. Interesującym rozwiązaniem jest
wykorzystanie podejścia obiektowego, w szczególności jezyka UML [3].
UML pozwala tworzyć modele rzeczywistości według określonych zasad modelowania obiektowego. Dzięki ścisłej definicji używanych do tego konstrukcji językowych (jak
relacje, klasy, obiekty itp.) możliwość niejednoznacznej interpretacji modeli sprowadzona
została do znacznie niższego poziomu w porównaniu z językiem naturalnym. Jednocześnie
nadal udało się zachować czytelność i przejrzystość modeli.
Mimo tego iż pojęcia UML należą do pojęć ścisłych, ich znaczenie, dzięki dużemu
upowszechnieniu metodyki, jest intuicyjne i zrozumiałe dla osób bezpośrednio zaangażowanych w projektowanie oraz użytkowanie systemów będących przedmiotem modelowania.
Dlatego, w celu uściślenia treści kluczowych elementów dowodu zaufania, jakimi są
żądania, w opisywanym rozwiązaniu wykorzystano konstrukcje metodyki obiektowej. Aby
zaadaptować je do dziedziny zaufania wprowadzono tzw. Język Definiowania Żądań (ang.
Claim Definition Language – CDL). CDL jest językiem graficznym, wzbogacającym język
pisany o system znaków graficznych i diagramów, oraz o metodę ich stosowania. Wykorzystano pojęcia pierwotne języka UML takie jak obiekt, stan, związek, etc., które posłużyły do wywiedzenia dalszych pojęć języka CDL. Bezpośrednio użyto symbole i znaki graficzne UML. Struktura CDL przedstawiona jest na rys. 4.
CDL – język graficzny
Język pisany
naturalny
Modele żądań
formalny
Modele kontekstu
statyczne
dynamiczne
Rys. 4. Struktura języka CDL
Na język CDL składają się:
 System graficzny służący do tworzenia modeli kontekstu żądań (ang. context models). Modele kontekstu ukazują wszystkie (fizyczne i logiczne) obiekty, do których odwołuje się żądanie oraz relacje między nimi. Aby zmniejszyć możliwość
pojawienia się niejednoznaczności wykonano również pracę w kierunku formalizacji znaczenia tychże relacji.
 Formalny język pisany pozwalający precyzyjnie definiować żądania, stanowiący
uzupełnienie języka naturalnego, w którym formułowane są wszystkie żądania,
argumenty, fakty i założenia dowodu zaufania.
 System graficzny służący do reprezentacji żądań, argumentów, faktów i założeń
wraz z regułą etykietowania pozwalającą jednoznacznie identyfikować elementy
dowodu. Każde żądanie powiązane jest z modelem żądania (ang. claim model)
przedstawiającym dane żądanie wraz z towarzyszącym mu argumentem oraz pełnym materiałem dowodowym będącym z nim w bezpośrednim związku.
6
J. Górski, A. Jarzębowicz, R. Leszczyna, J. Miler, M. Olszewski
5. OBIEKTOWE MODELOWANIE KONTEKSTU
Modele kontekstu służą do uściślania opisu żądań poprzez prezentację jedynie tych
obiektów systemu, do których żądanie bezpośrednio się odwołuje.
Dzięki przeprowadzonym w ostatnich latach próbom rozszerzenia UML o procesy
biznesowe (np. [4]) możliwe stało się pokrycie zarówno warstwy architektonicznej i jak
biznesowej. Pozwala to modelować kontekst nie tylko systemu i jego środowiska docelowego (statyczne modele kontekstu) - ale również – procesów (dynamiczne modele kontekstu). Dotyczy to szczególnie tych procesów, na których opiera się zaufanie do systemu (np.
proces implementacji, pielęgnacji, instalacji itd.). W ten sposób działanie analityczne związane z budowaniem dowodu zaufania udało się umieścić w uniwersalnej i silnie ukonstytuowanej platformie modelowania.
Dodatkowo, oprócz standardowych pojęć oferowanych przez UML, wprowadzono
zbiór stereotypów klas, służących do reprezentacji typowych obiektów występujących w
modelach kontekstu. Okazują się one szczególnie przydatne podczas pracy z żądaniami
wysokiego poziomu (bezpośrednie formuły oczekiwań wobec systemu, definiowanie celów
zaufania), dla których najczęściej nie istnieją modele opracowane przez projektantów systemu. Stereotypy zdefiniowane dla potrzeb projektu DRIVE [5] przedstawiono na rys. 5.
<<problem solution>>
<<process>>
<<goal>>
<<person>>
<<process>>
«goal»
goal
«person»
HP
<<physical>>
<<information>>
<<device>>
<<program>>
«physical»
dr
«information»
inf
«device»
dev
«program»
prog
«problem solution»
PR
Rys. 5. Stereotypy używane w modelach kontekstowych
Przykład statycznego modelu kontekstowego [6] pokazano na rys. 6.
represents
«information»
Patient Record
1:1
includes
«information»
Therapy Sheet
includes
has a -->
«person»
Patient
<-- includes
«information»
Patient ID
includes
includes
«information»
Preparation Data
«information»
Prescription Data
«information»
Validation Data
includes
identifies
«information»
Therapy Administration Order
represents
«physical»
Therapy
identifies
identifies
includes
«physical»
Drug
1:1
«physical»
Wristband Label
«physical»
Drug Label
Rys. 6. Przykład statycznego modelu kontekstowego
Podejście obiektowe w budowie dowodu zaufania...
7
Powyższy model kontekstu pochodzi z dowodu zaufania skonstruowanego dla [5] i pokazuje relacje między pacjentami, lekami, fizycznymi identyfikatorami oraz powiązanymi z
nimi bytami logicznymi (informacyjnymi). Zaprezentowane są klasy obiektów oraz związki
między nimi, co dostarcza kontekstu pojęciowego użytego w przy wyrażaniu żądania [6]:
CL_0.1.1.6
Drug Labels of the Drugs applied to Patient are consistent with the Prescription Data in
the corresponding Patient Record identified by the Patient’s Wristband Label.
Należy zauważyć, że powyższe żądanie odnosi się wyłacznie do obiektów klas przedstawionych w modelu kontekstu. Słowa wytłuszczone wskazują relacje między obiektami.
Jakkolwiek obiekty przytoczone w żądaniu są precyzyjnie wyspecyfikowane, relacje w
dalszym ciągu mogą być powodem nieścisłości. Rozwiązanie problemu polega na sformalizowaniu języka pisanego.
6. FORMALIZACJA JĘZYKA PISANEGO
Treść żądań, argumentów, założeń i faktów występujących w dowodzie zaufania formułowana jest w języku naturalnym. Dzięki odwoływaniu się wyłącznie do obiektów klas
przedstawionych w powiązanym modelu kontekstowym, możliwe stało się jej uściślenie,
jednakże użycie konstrukcji języka naturalnego może nadal prowadzić do błędnych interpretacji. Dlatego celowe okazało się wykonanie pracy dążącej do formalizacji języka pisanego używanego przy definiowaniu żądań.
Przykład formalizacji żądania CL_0.1.1.6 dla [6] pokazany jest poniżej:
If
d:Drug<physical> is applied to p:Patient<person>
then exist dl:Drug Label<physical&information>, tao:Therapy Administration
Order<information>, pd:Prescription Data<information>, ts:Therapy
Sheet<information>, pr:Patient Record<information>, pwl:Patient Wristband
Label<physical&information>, pr:Patient Record<information> such that
d(1:1)dl and pwl(1:1)p and tao(includes)pd(includes)ts(includes)pr and
pr(represents)p and tao(identifies)dl and pwl(uniquely identifies)pr
Taka postać żądania wprowadza ograniczenia dla każdego zbioru obiektów będących
instancjami klas na modelu kontekstu i bezpośrednio do niego się odwołuje. Wyspecyfikowane są stereotypy (kursywą, w nawiasach ostrych) oraz terminy (w treści powyżej – podkreślonych), które są przejrzyście zdefiniowane w Słowniku CDL (ang. CDL Dictionary).
Znaczący wkład w budowę Słownika CDL wniosły definicje i pojęcia podstawowe UML.
Dzięki ich jasnemu znaczeniu zdefiniowano na ich podstawie nowe pojęcia, powiązane z
dziedziną zaufania. Poniżej przytoczono definicje terminów, które występują w powyższej,
sformalizowanej specyfikacji (symbol “==” oznacza „jest definiowane jako”). W tym przypadku pojęciem zaczerpniętym z terminologii UML jest pojęcie stanu obiektu.
Resource1 is applied to Resource2 == Resource1 is consumed and its State is used to update
State of Resource2
Resource1 identifies Resource2 == Identity of Resource2 can be derived from Attributes of
Resource1
Resource1 uniquely identifies Resource2 == Resource1 identifies Resource2 and if exists
Resource3 such that Class(Resource2) = Class(Resource3) then Resource3 = Resource2
8
J. Górski, A. Jarzębowicz, R. Leszczyna, J. Miler, M. Olszewski
consume== to read the Resource State and to delete the Resource
update== to read and write the Resource State
7. OBIEKTOWE MODELE ŻĄDAŃ
Model żądania wykorzystywany jest w budowie dowodu zaufania do reprezentacji
powiązania między żądaniem, wspierającym je argumentem oraz materiałem dowodowym,
do którego dany argument bezpośrednio się odwołuje. Elementy użyte do definiowania
modeli żądań dla [6] pokazane są na rys. 7.
<<claim>>
<<argument>>
<<fact>>
<<assumption>>
«claim»
CL
«argument»
ARG
«fact»
F
«assumption»
A
Rys. 7. Elementy modelu żądania
Wszystkie elementy modelu żądania definiowane są jako stereotypy w języku UML.
Pozwala to wygodnie zarządzać strukturą budowanego dowodu zaufania przy użyciu narzędzia graficznego wspierającego metodykę UML, np. Microsoft Visio 2002 [7]. Budowany dowód staje się wtedy obiektowym modelem UML. Przykładowy model żądania
pokazano na rys. 8.
«claim»
CL_0.1.1.5
«argument»
ARG_0.1.1.5
«claim»
CL_0.1.1.5.1
«claim»
CL_0.1.1.5.3
«claim»
CL_0.1.1.5.2
«assumption»
A_0.1.1.5.1
«fact»
F_0.1.1.5.1
«claim»
CL_0.1.1.5.4
«fact»
F_0.1.1.5.3
«fact»
F_0.1.1.5.2
«fact»
F_0.1.1.5.4
Rys. 8. Przykładowy model żądania
Odcienie używane są do odróżnienia typów elementów (żądania, argumenty, fakty, założenia). Każdy element modelu posiada swój własny identyfikator, na który składa się
identyfikator liczbowy poprzedzony przedrostkiem określającym typ elementu. Identyfikator elementu jednoznacznie ustala położenie danego elementu w całym dowodzie zaufania.
Zgodnie z metodyką budowy dowodów zaufania żądania strukturalizowane są w modelu
UML wertykalnie (żądania wyjaśniające żądania wyższego poziomu) oraz horyzontalnie
(żądania wzajemnie się uzupełniające, używane w tym samym argumencie).
8. DOWÓD ZAUFANIA DLA ROZWIĄZANIA DRIVE
Przedstawione w artykule obiektowe podejście do budowy dowodu zaufania znalazło
zastosowanie w projekcie UE DRIVE [5]. Projekt badawczo-rozwojowy IST-DRIVE prowadzony był w ramach 5. Programu Ramowego Unii Europejskiej w latach 2000-2003.
Angażował on konsorcjum partnerów akademickich i przemysłowych z całej Europy (m.in.
Podejście obiektowe w budowie dowodu zaufania...
9
z Włoch, Francji, Hiszpanii, Szwecji i Polski) w celu wypracowania bezpiecznego i ekonomicznego systemu dystrybucji leków szpitalnych przy użyciu najnowszych rozwiązań
informatycznych. W projekcie DRIVE problem dystrybucji leków potraktowano kompleksowo począwszy od producentów poprzez dystrybutorów, magazyn szpitala aż do łóżka
pacjenta dążąc do obniżenia ryzyka błędu medycznego w przepisaniu i podaniu leku przy
równoczesnym obniżeniu kosztów logistycznych.
Rozwiązanie DRIVE cechuje się wysokim stopniem złożoności oraz bardzo dużymi
wymaganiami udziałowców w kwestii zaufania. Ponadto obszar zastosowań medycznych
silnie łączy wymogi bezpieczeństwa (ang. safety) oraz zabezpieczeń (ang. security). Uznając potrzebę uzyskania niezależnej oceny zaprojektowanej infrastruktury organizacyjnotechnicznej, zdecydowano się na opracowanie jawnego dowodu zaufania. Zadanie to zostało zrealizowane w Katedrze Zastosowań Informatyki Politechniki Gdańskiej w okresie
lipiec 2002 – styczeń 2003.
W dowodzie zaufania dla rozwiązania DRIVE wyróżniono cztery podstawowe cele
dowodowe: bezpieczeństwo pacjenta, prywatność pacjenta, prywatność pracownika szpitala
oraz śladowość działań medycznych. Ze względu na ograniczenia zasobów i ustalone priorytety celów zbudowany dowód objął głównie obszar bezpieczeństwa pacjenta. Ponadto z
powodu braku dostępnego materiału źródłowego w swej szczegółowości sięgnął on decyzji
projektowych na poziomie architektury tj. poszczególnych stacji roboczych wraz z ich
usługami oraz komponentów programowych i ich funkcjonalności reprezentujących logikę
biznesową. Żądania najniższego poziomu postulowały zgodną ze specyfikacją implementację elementów architektury i były zamykane poprzez zamianę na założenia.
W celu pozyskana materiału dowodowego przeanalizowano dokumentację projektową
rozwiązania DRIVE oraz przeprowadzono wywiady z projektantami systemu. Ponadto
niektóre diagramy projektowe poddano inspekcji metodą UML-HAZOP [8] przy wsparciu
dedykowanego narzędzia [9]. Rezultaty analiz [9] włączono do dowodu w postaci faktów
potwierdzających słuszność podjętych decyzji projektowych bądź wskazujących błędne
koncepcje.
W całości opracowanego dowodu zaufania wykorzystano przedstawione w artykule
podejście obiektowe i wyrażono go w języku CDL. Wszystkie elementy dowodu podano w
języku naturalnym, a żądania i założenia dodatkowo uzupełniono postacią sformalizowaną.
Zarówno modele kontekstu jak i modele żądań były tworzone i zarządzane przy użyciu
narzędzia Microsoft Visio 2002 [7]. W sumie opracowano 54 obiektowe modele kontekstowe, w tym również ogólne modele dziedzinowe nieistniejące wcześniej w dokumentacji
projektu DRIVE. Dowód zaufania ostatecznie obejmował 97 żądań, 92 argumenty, 234
fakty i 121 założeń. Liczba argumentów nie pokrywa się z liczbą żądań, gdyż z powodu
ograniczeń czasowych nie wszystkie cele zaufania zostały zamknięte. Duża liczba założeń
wynika z braku odpowiednio szczegółowego materiału źródłowego.
9. WNIOSKI
Artykuł przedstawił podejście obiektowe do budowy dowodu zaufania dla systemów
informatycznych. W omawianym podejściu wykorzystano język UML jako uniwersalną
platformę dla dokumentowania dowodu zaufania oraz modelowania budowanego systemu i
dziedziny aplikacyjnej. Dzięki mechanizmowi stereotypowania dostepnemu w języku UML
opracowano dedykowany język specyfikowania żądań CDL. Pozwala on elastycznie modelować kontekst żądań definiując różne rodzaje bytów (informacja, byt fizyczny, osoba,
10
J. Górski, A. Jarzębowicz, R. Leszczyna, J. Miler, M. Olszewski
urządzenie, oprogramowanie) oraz związki między nimi (np. „zawiera”, „identyfikuje”,
„reprezentuje”). Ponadto CDL obejmuje formalny język wyrażania żądań wobec bytów
kontekstu oraz środki modelowania samej struktury dowodu zaufania.
Zastosowanie podejścia obiektowego i języka CDL pozwoliło znacznie zwiększyć
jednoznaczność i komunikatywność wywodu oraz kontrolować jego zakres, co zostało
docenione podczas grupowej pracy nad dowodem oraz niezależnych inspekcji. Dzięki
wsparciu narzędziowemu w znacznym stopniu rozwiązano problem spójności strukturalnej
modeli żądań i modeli kontekstowych.
Przyjęcie języka UML za platformę bazową, użycie obiektowych modeli kontekstu
oraz formalizacja żądań objęte opracowanym językiem CDL to, według autorów, najważniejsze cechy omawianego podejścia, które odróżniają je od innych prac [10, 11, 12]. Dodatkowo, użyte w prezentowanym podejściu pojęcia „zaufania” pozwala w sposób jednorodny potraktować różne aspekty jakości oprogramowania (np. bezpieczeństwo, prywatność, śladowość, dostępność), które dotychczas były rozpatrywane oddzielnie.
Autorzy oceniają obiektowe podejście do budowy dowodów zaufania jako obiecujące
i planują dalsze prace badawcze oraz eksperymentalne w tym obszarze. Plany badawcze
obejmują: rozszerzenie zakresu dowodu zaufania m.in. o działania pielęgnacyjne, rozważanie wpływu informacji zwrotnej z analiz w dowodzie zaufania na proces projektowy, zapewnienie spójności wewnętrznej dowodu w przypadku konfliktu celów zaufania oraz
jawną reprezentację siły argumentu w zależności od wagi przytoczonego materiału dowodowego. Kontynuowane będą ponadto prace nad językiem CDL, w szczególności w obszarze formalnego specyfikowania żądań, a także analizie zostanie poddana możliwość lepszego wsparcia narzędziowego.
BIBLIOGRAFIA
[1] SHIP: Projekt UE EUREKA SHIP (Safety of Hazardous Industrial Processes)
http://www.csr.city.ac.uk/csr_city/projects/ship/ship.html
[2] Górski J.: Developing Safety Cases for Software Intensive Systems, mat. konf. Analiza Ryzyka
i Zarządzanie Bezpieczeństwem w Systemach Technicznych, Gdańsk, 25-27 czerwca 2001, pp.
111-120
[3] OMG Unified Modeling Language Specification version 1.4, Object Management Group, 2001
[4] Eriksson H.-E., Penker M.: Business Modeling with UML, J Wiley, 2000
[5] DRIVE: Projekt UE DRIVE (DRug In Virtual Enterprise) http://www.e-mathesis.it/drive
[6] DRIVE: D11.1-3 – Trust Case for DRIVE, D11.1-3, wersja 1.1, styczeń 2003
[7] Microsoft Visio 2002 Professional, Microsoft Corp., 2002
[8] Górski J., Jarzębowicz A.: Detecting defects in object-oriented diagrams using UML-HAZOP,
Found. of Comp. and Decision Sciences, vol. 27, no. 4, 2002
[9] DRIVE: D11.4 – UML-HAZOP, D11.4, wersja 1.1, styczeń 2003
[10] Wilson S. P., Kelly T. P., McDermid J. A.: Safety Case Development: Current Practice, Future
Prospects
[11] Adelard Safety Case Development Manual, Adelard, 1998
[12] Kelly, T.: Arguing Safety A Systematic Approach to Managing Safety Cases, rozpr. dokt.,
University of York, UK, 1998, YCST 99/05, http://www.cs.york.ac.uk/ftpdir/reports/YCST-9905.ps.gz