Praca dyplomowa magisterska

Politechnika Gdańska WYDZIAŁ ELEKTRONIKI, TELEKOMUNIKACJI I INFORMATYKI Katedra: Katedra Architektury Systemów Komputerowych Imię i nazwisko dyplomanta: Radosław Kleczkowski Nr albumu: 106317 Forma i poziom studiów: Stacjonarne jednolite studia magisterskie Kierunek studiów: Informatyka, Aplikacje rozproszone i systemy internetowe Praca dyplomowa magisterska Temat pracy: Integracja ontologii zapisanych w języku OWL Kierujący pracą: Konsultant pracy: dr inż. Piotr Szpryngier mgr inż. Tomasz Boiński Zakres pracy: Niniejsza praca magisterska poświęcona jest rozwinięciu edytora ontologicznego dla systemu OCS o funkcjonalność integracji ontologii. Gdańsk, 2010

Spis treści 1. Wstęp 5 1.1. Problematyka i jej znaczenie........................ 5 1.2. Cel i zakres pracy............................. 7 2. Przegląd dostępnych narzędzi ułatwiających integrację ontologii 9 2.1. Wprowadzenie............................... 9 2.2. Przedstawienie istniejących narzędzi.................... 9 2.2.1. Prompt............................... 9 2.2.2. OBO-Edit............................. 11 2.3. Przyjęta metodyka oceny......................... 13 2.4. Ocena narzędzi............................... 18 2.4.1. Prompt............................... 18 2.4.2. OBO-Edit............................. 19 2.5. Podsumowanie............................... 20 3. Specyfikacja wymagań i projekt rozszerzenia systemu OCS 21 3.1. Wprowadzenie............................... 21 3.2. Wymagania................................. 21 3.2.1. Wymagania funkcjonalne i niefunkcjonalne............ 21 3.2.2. Diagram przypadków użycia.................... 23 3.2.3. Architektura............................ 23 3.3. Analiza obiektowa............................. 25 3.4. Struktura plików projektu......................... 28 3.5. Harmonogram prac............................. 29 3.6. Analiza SWOT............................... 32 3.7. Projekt interfejsu użytkownika....................... 33 4. Implementacja 36 4.1. Wprowadzenie............................... 36 4.2. Metodologia projektowania i implementacji................ 36 4.3. Środowiska i narzędzia wspomagające................... 37 4.4. Główne problemy informatyczne...................... 38 4.5. Przykłady rozwiązań szczegółowych.................... 39 2

4.5.1. Struktura komponentów panelu integracji............. 39 4.5.2. Wybór zarządcy układu...................... 39 5. Podsumowanie 44 5.1. Ocena rozszerzenia............................. 44 5.2. Dalsze możliwości rozbudowy....................... 45 Literatura 46 Wykaz skrótów i symboli 48 A. Specyfikacja Wymagań systemowych 51 A.1. Przypadki użycia.............................. 51 A.1.1. Diagram przypadków użycia.................... 51 A.1.2. Opis przypadków użycia...................... 51 A.2. Cele systemu................................ 58 A.2.1. Cele biznesowe........................... 58 A.2.2. Cele funkcjonalne......................... 59 A.3. Otoczenie systemu............................. 60 A.3.1. Użytkownicy............................ 60 A.3.2. Systemy zewnętrzne........................ 60 A.4. Przewidywane komponenty systemu.................... 60 A.4.1. Podsystemy............................ 60 A.4.2. Komponenty sprzętowe...................... 60 A.4.3. Programowe............................ 61 A.5. Wymagania funkcjonalne.......................... 61 A.5.1. Wymagania w zakresie wizualizacji................ 66 A.6. Wymagania na dane............................ 66 A.7. Wymagania jakościowe........................... 66 A.7.1. Wymagania w zakresie wiarygodności............... 66 A.7.2. Wymagania w zakresie wydajności................. 67 A.7.3. Wymagania w zakresie elastyczności............... 67 A.7.4. Wymagania w zakresie użyteczności................ 68 A.8. Sytuacje wyjątkowe............................ 68 A.9. Dodatkowe wymagania........................... 68 A.9.1. Wymagania sprzętowe....................... 68 3

A.9.2. Wymagania programowe...................... 68 A.9.3. Inne wymagania.......................... 69 A.10.Kryteria akceptacyjne........................... 70 4

1. Wstęp 1.1. Problematyka i jej znaczenie Gwałtowny rozwój Internetu i upowszechnienie dostępu do komputerów spowodował, że obecnie w sieci internetowej znajdują się olbrzymie zasoby nieuporządkowanej wiedzy. Już kilkanaście lat temu naukowcy rozpoczęli próby opisania i ustrukturalizowania danych i informacji dostępnych w sieci WWW w taki sposób, aby komputery mogły je odczytać. Prace te dążą obecnie do realizacji idei sieci semantycznej (Semantic Web) stworzonej przez twórcę WWW, Tima Bernersa-Lee. Sieć Semantyczna jest rozszerzeniem istniejącej sieci WWW o mechanizmy semantyczne, tak aby informacje dostępne w tej sieci były dobrze zdefiniowane i umożliwiały lepszą współpracę komputerom i ludziom [1]. Na rysunku 1.1 pokazano sposób, w jaki zorganizowane są standardy stworzone na potrzeby Sieci Semantycznej. Tworzą one hierarchiczną strukturę języków, w której języki niższego poziomu są wykorzystywane do zbudowania języków wyższego poziomu. W środku tej struktury znajdują się języki RDF, RDFS oraz OWL, służące do opisu ontologii. Ontologie są kluczowe dla idei Sieci Semantycznej, gdyż to właśnie one mają umożliwić komputerom zrozumienie informacji zawartych w sieci internetowej, a także wnioskowanie z tych informacji. Rys. 1.1. Warstwy Sieci Semantycznej, czyli tzw. Tort Sieci Semantycznej (Semantic Web Layer Cake) [8]. Wg Grubera [4] ontologia to formalna specyfikacja pojęć i relacji pomiędzy nimi w pewnej dziedzinie wiedzy. Podstawowym fundamentem ontologii w Sieci Semantycznej są języki RDF oraz RDF Schema (RDFS). Zdefiniowany w 1999 roku język RDF pozwala opisywać zasoby sieci za pomocą tzw. trójek RDF (obiekt, właści- 5

wość, wartość). Elementami takiej trójki mogą być dowolne zasoby sieciowe, które są identyfikowane poprzez URI, lub wartości takie jak napisy, liczby, czy daty, o określonym poprzez URI typie danych. Co więcej, taka trójka również jest zasobem sieciowym, co oznacza że można ją wykorzystać do skonstruowania innych, bardziej złożonych trójek. RDF Schema to standard definiujący podstawowe pojęcia dla języka RDF, dzięki którym jest on w stanie opisać proste ontologie. Informacje opisane w języku RDF można zapisać m.in. jako graf lub plik XML. Składnia XML dla języka RDF jest określana jako RDF/XML. Rozwinięciem języka RDF oraz RDFS jest język OWL. Wprowadza on dodatkowe pojęcia oraz semantykę formalną, dzięki czemu można w nim zapisać nawet najbardziej złożoną ontologię. Istnieją trzy odmiany tego języka, z których każda następna jest rozszerzeniem poprzedniej: OWL Lite - dla użytkowników potrzebujących przede wszystkim hierarchicznej klasyfikacji oraz prostych ograniczeń, OWL DL - dla użytkowników potrzebujących największej możliwej ekspresji języka, zachowując jednocześnie jego rozstrzygalność, OWL Full - dla użytkowników potrzebujących największej możliwej ekspresji oraz wolności składniowej języka RDF. Ta odmiana nie daje żadnej gwarancji rozstrzygalności. Ze względu na brak możliwości praktycznego zastosowania odmiany OWL Full, najczęściej stosowana jest odmiana OWL DL. Zarówno XML jak i RDF, RDFS oraz OWL są otwartymi standardami zatwierdzonymi przez konsorcjum W3C, które sprawuje pieczę nad rozwojem sieci internetowej. Wielu badaczy i naukowców pracowało nad ontologiami w różnych dziedzinach nauki. Ich prace często były niezależne, dlatego też powstało mnóstwo ontologii, których obszary wiedzy zachodzą na siebie lub też nawet całkowicie się pokrywają. Przykładem mogą być ontologie stworzone przez Yahoo! (www.yahoo.com) oraz DOMOZ Open Directory (www.dmoz.org) [15]. Obie te ontologie kategoryzują informacje dostępne w sieci internetowej, a więc dotyczą tej samej dziedziny wiedzy. Mają też wiele różnic. Integracja kilku ontologii w jedną, może znacznie przyspieszyć pracę nad nowymi ontologiami, jednocześnie ułatwiając wymianę danych, pomiędzy rozproszonymi po całym świecie źródłami informacji. Jest to proces iteracyjny, w którym można wyróżnić następujące kroki [11]: 1. Wyszukanie miejsc, w których ontologie zachodzą na siebie. 2. Wprowadzenie relacji równoważności oraz hierarchii pomiędzy konceptami, które są sobie semantycznie bliskie. 3. Kontrola niesprzeczności, spójności oraz braku nadmiarowości. 6

Niestety realizacja tego procesu jest niezwykle skomplikowana zarówno dla człowieka jak i dla maszyn ze względu na liczne niezgodności językowe i znaczeniowe. Pomimo iż podjęto już próby opracowania rozwiązań całkowicie automatyzujących integrację, żadne z nich nie jest jeszcze na tyle rozwinięte, aby wyeliminować rolę człowieka w tym procesie. Konieczne jest zatem jak największe uproszczenie tego procesu poprzez specjalnie zaprojektowane do tego celu narzędzia wspomagające. 1.2. Cel i zakres pracy OCS (Ontology Creation System) to system powstający na Katedrze Architektury Systemów Komputerowych na Wydziale Elektroniki, Telekomunikacji i Informatyki Politechniki Gdańskiej. System służy do tworzenia, składowania i wersjonowania ontologii. W skład systemu wchodzi także edytor ontologiczny. Edytor ten wyróżnia się na tle innych poniższymi cechami [9]: kooperacyjna edycji ontologii, kontrola uprawnień do edycji ontologii oraz publikacji kolejnych jej wersji, integracja z systemem OCS, wsparcie dla wielojęzyczności, łatwa instalacja przez sieć WWW. Praca zespołowa, którą umożliwia edytor OCS, mogła by znacznie przyspieszyć skomplikowany proces integracji ontologii, jednak w obecnej wersji edytor nie jest w stanie obsługiwać więcej, niż jednej ontologii jednocześnie. Niniejsza praca magisterska poświęcona jest rozwinięciu edytora ontologicznego dla systemu OCS o funkcjonalność integracji ontologii. Należy zaznaczyć, iż głównym celem nie jest pełna automatyzacja procesu integracji, a jedynie opracowanie i implementacja prostego i czytelnego interfejsu, który umożliwiłby ręczne zintegrowanie dwóch ontologii w trzecią. Najistotniejsze dla tego projektu wymagania przedstawiono w punkcie 3.2.1 na stronie 22. W ramach pracy udało się zrealizować wszystkie najważniejsze wymagania funkcjonalne. Powstała także obszerna dokumentacja projektowa dla zmian zaimplementowanych w edytorze. Przeprowadzono również testy jednostkowe zaimplementowanych funkcjonalności. W pierszej części pracy przedstawiono i porównano istniejące narzędzia, umożliwiające zintegrowanie ontologii. Kolejny rozdział zawiera analizę wykonalności SWOT, omówienie wymagań oraz najważniejsze fragmenty z dokumentacji projektowej, powstałej w ramach prac nad rozszerzeniem. Następnie opisano metodykę 7

implementacji, wykorzystane narzędzia oraz najważniejsze problemy napotkane podczas prac implementacyjnych. Ostatni rozdział zawiera ocenę wyników projektu oraz opis dalszych perspektyw rozwoju systemu OCS. 8

2. Przegląd dostępnych narzędzi ułatwiających integrację ontologii 2.1. Wprowadzenie Poniższy rozdział prezentuje dwa istniejące rozwiązania w zakresie wspomagania integracji ontologii. Na początku rozdziału znajduje się opis obu rozwiązań, następnie opis przyjętej metodyki oraz ocena rozwiązań za pomocą tej metodyki. Końcowy wynik odzwierciedla stopień dostosowania danego rozwiązania do wymagań dla rozszerzenia edytora OCS przedstawionych w punkcie 3.2.1. Na końcu rozdziału znajduje się krótkie podsumowanie wyników. 2.2. Przedstawienie istniejących narzędzi 2.2.1. Prompt Prompt jest wtyczką dla edytora ontologii Protégé. Rys. 2.1. Interfejs Prompt - klasy. 9

Podobnie jak Protégé, wtyczka Prompt napisana jest w Javie i posiada całkowicie otwarty kod (licencja Mozilla Public License). Jej autorem jest Natasha Noy z uniwersytetu w Stanfordzie. Umożliwia ona zarządzanie wieloma ontologiami jednocześnie. Za jej pomocą, w edytorze Protégé można wykonywać następujące operacje [7]: porównywanie różnych wersji tej samej ontologii, przesuwanie elementów pomiędzy projektami załączonym i załączającym, scalanie dwóch ontologii w jedną, wydzielenie części ontologii. Podczas testowania programu skupiono się na funkcjonalności scalania ontologii. Rys. 2.2. Interfejs Prompt - lista dopasowań. Działa ona według następującego algorytmu [15]: 1. Utworzenie początkowej listy dopasowań na podstawie podobieństwa językowego nazw klas przez Prompt. 10

2. Uruchomienie kolejnej operacji przez użytkownika. 3. Wykonanie wybranej operacji, a następnie dokonanie automatycznej aktualizacji listy dopasowań w oparciu o strukturę integrowanych ontologii po dokonaniu zmian przez użytkownika. Powrót do punktu 2. Wtyczka wspomaga więc użytkownika, znajdując miejsca potencjalnie wymagające jego interwencji. Na rysunku 2.2 widoczna jest propozyjca scalenia dwóch elementów: pizzy LaReine oraz rozmiaru Large z ontolgii aminokwasów. Jest ona wynikiem działania tego mechanizmu podpowiedzi. Jak widać otrzymywane rezultaty nie zawsze są sensowne, mimo to mechanizm ten jest niewątpliwie zaletą ocenianego narzędzia. Niestety wtyczka nie jest kompatybilna z najnowszą wersją edytora Protégé 4.0.2 ze względu na zmiany w implementacji wtyczek. Do testów wykorzystano edytor Protégé 3.0 oraz wtyczkę Prompt w stabilnej wersji 2.3.2. 2.2.2. OBO-Edit OBO-Edit to otwarty edytor ontologii napisany w języku Java. Jest on zoptymalizowany pod format plików OBO reprezentujących ontologie biologiczne. Edytor został stworzony przez Gene Ontology Consortium i jest rozwijany w ramach Berkeley Bioinformatics and Ontologies Project [6]. Narzędzie to posiada dwie, interesujące z punktu widzenia integracji, funkcjonalności: klonowanie i scalanie klas, zarządzanie różnymi wersjami tej samej ontologii, niestety tylko w formacie OBO. W trakcie testów podjęta zostanie próba wykorzystania tych funkcjonalności do zintegrowania ontologii. Aby zintegrować 2 ontologie w edytorze OBO-Edit należy je najpierw przekształcić do formatu OBO. Następnie trzeba je scalić wskazując, jako wspólną wersję źródłową dla programu, pusty plik. W efekcie powstanie ontologia, zawierająca wszystkie elementy z obu scalanych ontologii, na której można pracować. Ontologię tą najlepiej zapisywać i przechowywać w formacie OBO. 11

Rys. 2.3. Interfejs Obo-Edit. W testach posłużono się najnowszą dostępną wersją edytora, 2.1-beta6. 12

2.3. Przyjęta metodyka oceny Przyjęta metodyka oceny narzędzi jest oparta o model oceny jakości oprogramowania zawarty w specyfikacji standardu międzynarodowego ISO/IEC 9126 [12]. Zakłada ona zdefiniowanie modelu jakości produktu programowego na podstawie ogólnego modelu oraz potrzeb biznesowych, a następnie wyznaczenie ilościowej oceny jakości produktu programowego w oparciu o zdefiniowany wcześniej model. Ogólny model jakości produktu programowego, zwany również drzewem jakości, ma następującą strukturę: Rys. 2.4. Ogólny model jakości produktu programowego [12]. Drzewo to składa się z sześciu charakterystyk, z których każda jest wyrażona poprzez kilka metryk. Ostateczną jakość produktu programowego wyznacza się ze wzoru [12]: J = i A i w i i w i (2.1) gdzie: A i - kolejna charakterystyka w i - waga charakterystyki J - jakość Do wyznaczenia wartości charakterystyk wykorzystuje się ich metryki [12]: A i = j M j w j j w j (2.2) gdzie: M j - kolejna metryka w j - waga metryki Aby wyznaczyć jakość analizowanych narzędzi, trzeba jeszcze wybrać interesujące z punktu widzenia projektu charakterystyki i metryki oraz określić ich wagi. Na 13

podstawie przygotowanej specyfikacji wymagań systemowych (punkt 3.2.1 na stronie 22) dla edytora OCS, utworzono następujący model jakości: Jakość Funkcjonalność Użyteczność Przenośność dopasowanie zabezpieczenie łatwość nauki łatwość użycia zgodność Rys. 2.5. Przyjęty model jakości. Składa się on z następujących charakterystyk oraz metryk: Tab. 2.1. Charakterystyki. Nazwa charakterystyki Waga Funkcjonalność 0.5 Użyteczność 0.3 Przenośność 0.2 Tab. 2.2. Metryki: Zabezpieczenie Nazwa metryki Zabezpieczenie Waga 0.2 Opis Określa stopień zabezpieczenia programu przed nieautoryzowanym dostępem do danych. Sposób pomiaru Przyznanie 1 punktu za twierdzącą odpowiedź na każde z poniższych pytań: 1. Czy możliwe jest ograniczenie dostępu do projektu/ontologii poprzez mechanizm logowania? 2. Czy możliwa jest kontrola i modyfikacja uprawnień do projektu/ontologii? 3. Czy uprawnienia do odczytu, modyfikacji oraz usunięcia są wydzielone? 14

Tab. 2.3. Metryki: Dopasowanie Nazwa metryki Dopasowanie Waga 0.8 Opis Określa dopasowanie programu do wymagań określonych w specyfikacji. Sposób pomiaru Przyznanie 1 punktu za twierdzącą odpowiedź na każde z poniższych pytań: 1. Czy podczas integracji możliwe jest scalenie dwóch elementów w jeden? 2. Czy podczas integracji możliwe jest dodawanie nowych elementów? 3. Czy podczas integracji możliwe jest usuwanie elementów? 4. Czy podczas integracji możliwa jest modyfikacja hierarchii elementów? 5. Czy podczas integracji możliwa jest modyfikacja nazw elementów? 6. Czy możliwy jest zapis procesu integracji na dysku oraz jego późniejsze wznowienie? 7. Czy możliwe jest utworzenie nowej ontologii poprzez import elementów? 8. Czy możliwe jest utworzenie nowej ontologii poprzez skopiowanie elementów? 9. Czy możliwe jest filtrowanie elementów ontologii wg ich typu? 10. Czy możliwe jest wyszukiwanie elementów ontologii po ich nazwie? 11. Czy podczas integracji dostępne są pewne sugestie, umożliwiające automatyczne rozwiązanie pewnych potencjalnych problemów integracyjnych wychwyconych przez edytor? 15

Tab. 2.4. Metryki: Łatwość nauki Nazwa metryki Łatwość nauki Waga 0.5 Opis Określa stopień dostępności pomocy, przyspieszającej naukę pracy z programem. Sposób pomiaru Przyznanie 1 punktu za twierdzącą odpowiedź na każde z poniższych pytań: 1. Czy istnieje instrukcja użytkownika? 2. Czy pomoc jest dostępna w trakcie korzystania z programu? 3. Czy istnieje pomoc kontekstowa? 4. Czy istnieje samouczek? 5. Czy interfejs użytkownika jest intuicyjny (podobny do stosowanych w innych programach)? Tab. 2.5. Metryki: Łatwość użycia Nazwa metryki Łatwość użycia Waga 0.5 Opis Określa atrakcyjność i czytelność interfejsu użytkownika. Sposób pomiaru Przyznanie 1 punktu za twierdzącą odpowiedź na każde z poniższych pytań: 1. Czy istnieje tekstowo-okienkowy interfejs użytkownika? 2. Czy istnieje graficzny interfejs użytkownika? 3. Czy interfejs jest konfigurowalny? 4. Czy są dostępne skróty klawiszowe? 5. Czy jest dostępne menu kontekstowe? 16

Tab. 2.6. Metryki: Zgodność Nazwa metryki Zgodność Waga 1 Opis Określa stopień zgodności programu ze standardami. Sposób pomiaru Przyznanie 1 punktu za twierdzącą odpowiedź na każde z poniższych pytań: 1. Czy możliwe jest poprawne odczytanie ontologii z formatu RDF/XML? 2. Czy możliwe jest poprawne zapisanie ontologii do formatu RDF/XML? 3. Czy możliwe jest poprawne odczytanie ontologii z formatu OWL? 4. Czy możliwe jest poprawne zapisanie ontologii do formatu OWL? 5. Czy możliwe jest poprawne odczytanie ontologii z formatu OWL DL? 6. Czy możliwe jest poprawne zapisanie ontologii do formatu OWL DL? 7. Czy możliwe jest poprawne odczytanie i zapisanie ontologii z/do innych formatów (poza RDF, OWL oraz OWL DL)? Wyznaczone atrybuty i metryki umożliwiają ocenę aplikacji do integracji ontologii, pod kątem dopasowania do potrzeb projektu. 17

2.4. Ocena narzędzi 2.4.1. Prompt Tab. 2.7. Ocena: Protégé + Prompt Nazwa metryki Dopasowanie Zabezpieczenie Łatwość nauki Łatwość użycia Zgodność Wynik Odpowiedź pozytywna na pytania: 1, 2, 3, 4, 5, 6, 8, 9, 10, 11; Odpowiedź negatywna na pytania: 7; Razem: 10 / 11 Odpowiedź pozytywna na pytania: -; Odpowiedź negatywna na pytania: 1, 2, 3; Razem: 0 / 3 Odpowiedź pozytywna na pytania: 1, 4; Odpowiedź negatywna na pytania: 2, 3, 5; Razem: 2 / 5 Odpowiedź pozytywna na pytania: 1; Odpowiedź negatywna na pytania: 2, 3, 4, 5; Razem: 1 / 5 Odpowiedź pozytywna na pytania: 1, 2, 3, 4, 5, 6, 7; Odpowiedź negatywna na pytania: -; Razem: 7 / 7 Integracja ontologii przy pomocy edytora Protégé z wtyczką Prompt daje duże możliwości. Jego największą zaletą jest czytelny interfejs pozwalający łatwo rozróżnić elementy integrowanych ontologii i ich typy, dzięki odpowiedniemu kolorowaniu, aliasom nadawanym integrowanym ontologiom oraz sufiksom dla wynikowych elementów, które można łatwo usunąć po zakończeniu prac. Niestety czytelność interfejsu nie idzie w parze z łatwością jego użycia. W programie najbardziej brakuje menu kontekstowego i skrótów klawiszowych. Proces integracji ontologii może być czasochłonny i skomplikowany, ze względu na ich potencjalnie duże rozmiary, dlatego też wtyczka Prompt posiada mechanizm podpowiedzi, który zwraca uwagę operatora na możliwe problemy związane z integracją. Pozwala ona także na zapisanie przekształcenia scalającego. Aby wznowić pracę, wystarczy wybrać scalane ontologie oraz przekształcenie. Wtyczka pozwala również na porównywanie różnych wersji tej samej ontologii, jednak funkcjonalność ta nie pozwala na prównanie różnych wersji pliku przekształceń. Korzystając ze wzorów na jakość (2.1, 2.2) uzyskujemy ostateczny wynik edytora Protégé z wtyczką Prompt, który wynosi w przybliżeniu 65%. 18

2.4.2. OBO-Edit Tab. 2.8. Ocena: OBO-Edit Nazwa metryki Dopasowanie Zabezpieczenie Łatwość nauki Łatwość użycia Zgodność Wynik Odpowiedź pozytywna na pytania: 1, 2, 3, 4, 5, 9, 10; Odpowiedź negatywna na pytania: 6, 7, 8, 11; Razem: 7 / 11 Odpowiedź pozytywna na pytania: -; Odpowiedź negatywna na pytania: 1, 2, 3; Razem: 0 / 3 Odpowiedź pozytywna na pytania: 1, 2; Odpowiedź negatywna na pytania: 3, 4, 5; Razem: 2 / 5 Odpowiedź pozytywna na pytania: 1, 3, 4, 5; Odpowiedź negatywna na pytania: 2; Razem: 4 / 5 Odpowiedź pozytywna na pytania: 7; Odpowiedź negatywna na pytania: 1, 2, 3, 4, 5, 6; Razem: 1 / 7 Edytor ontologiczny OBO-Edit jest przeznaczony do pracy z ontologiami biologicznymi. Mimo, iż posiada opcje wczytywania i zapisu w formacie OWL, nie są one całkowicie zgodne z tym standardem. Edytor nie posiada funkcji integrowania ontologii, jednak proces integracji jest możliwy poprzez funkcjonalność scalenia dwóch wersji tej samej ontologii. W trakcie edycji możemy scalać, dodawać, usuwać, kopiować i modyfikować wszystkie elementy. Niestety edytor nie ma możliwości rozróżnienia, z której ontologii pochodzą edytowane elementy, co może utrudnić proces integracji. Na dodatek, po wyeksportowaniu ontologii do formatu OWL, w miejscach nazw elementów pojawiają się numerki. W kontekście pracy zespołowej, OBO-Edit pozwala na zapisanie historii zmian wykonanych na ontologii operacji. Po wczytaniu pliku z historią, można wykonywać i cofać wszystkie zapisane w niej operacje. Poprzez opisaną powyżej funkcjonalność scalania można łatwo scalić pliki z historiami operacji, tak aby otrzymać scaloną wersję ontologii, edytowanej jednocześnie przez kilku użytkowników. Daje to podobne możliwości, co plik z przekształceniem scalającym w przypadku wtyczki Prompt. Wynik edytora OBO-Edit to w przybliżeniu 46%. 19

2.5. Podsumowanie Oba testowane narzędzia posiadają podobną funkcjonalność. Różnica w punktach, na korzyść edytora Protégé z wtyczką Prompt, wynika głównie z metryki zgodność, gdyż OBO-Edit jest rozwiązaniem dedykowanym dla formatu OBO. Niestety żadne z narzędzi nie zapewnia mechanizmu uwierzytelniania, ani kontroli wersji. Wymusza to konieczność stosowania narzędzi zewnętrznych (takich jak SVN, czy CVS), które najczęściej opierają się na porównywaniu tekstu. Ułatwieniem może być fakt, iż przy scalaniu wersji w obu narzędziach, wystarczy scalić jeden plik ze zmianami, zamiast całej ontologii. Znacznie prościej i wydajniej byłoby jednak pracować z narzędziem dedykowanym do pracy zespołowej z ontologiami. Właśnie takim narzędziem jest system OCS. Posiada on wbudowane mechanizmy uwierzytelniania i kontroli wersji, a w ramach niniejszej pracy magisterskiej zostanie rozszerzony o możliwość zintegrowania ontologii. Dalsze plany rozwoju edytora OCS zostały przedstawione w punkcie 5.2. 20

3. Specyfikacja wymagań i projekt rozszerzenia systemu OCS 3.1. Wprowadzenie Celem projektu jest wzbogacenie edytora ontologicznego systemu OCS o interfejs umożliwiający ręczne zintegrowanie dwóch ontologii w trzecią. Poniższy rozdział zawiera najistotniejsze fragmenty z dokumentacji, powstałej w trakcie prac nad rozszerzeniem dla edytora OCS. Pierwszą część rozdziału stanowi ekstrakt z dokumentu Specyfikacji Wymagań Systemowych oraz krótkie omówienie wymagań i istniejącej architektury systemu OCS. Dalej umieszczono najważniejsze fragmenty analizy obiektowej. Następnie omówiono strukturę plików projektu integracji. Kolejne podrozdziały zawierają plan prac implementacyjnych w postaci harmonogramu i analizę SWOT. Na końcu szczegółowo opisany jest projekt interfejsu użytkownika stanowiący istotną część implementacji rozszerzenia. 3.2. Wymagania 3.2.1. Wymagania funkcjonalne i niefunkcjonalne Poniżej znajduje się zestawienie wymagań funkcjonalnych oraz niefunkcjonalnych w formie dwóch tablic. Wymagania te są szczegółowo opisane w załączonej Specyfikacji Wymagań Systemowych. Dla zwiększenia czytelności posortowano je wg przyjętych priorytetów, zaczynając od najważniejszych: 21

Tab. 3.1. Wymagania funkcjonalne. Kod Nazwa Priorytet WF005 Utworzenie projektu integracji ontologii. bardzo ważne WF006 Dodawanie nowych elementów. bardzo ważne WF008 Zapisanie projektu integracji ontologii. bardzo ważne WF009 Wczytanie projektu integracji ontologii. bardzo ważne WF011 Utworzenie nowej ontologii poprzez import elementów. bardzo ważne WF012 Utworzenie nowej ontologii poprzez skopiowanie elementów. bardzo ważne WF015 Modyfikacja elementów. ważne WF007 Usuwanie elementów. ważne WF010 Wybór ontologii. średnio ważne WF013 Wizualizacja importowanych ontologii. średnio ważne WF014 Jednoczesna wizualizacja integrowanych ontologii średnio ważne WF003 Funkcja Zasugeruj. mało ważne Tab. 3.2. Wymagania niefunkcjonalne. Kod Nazwa Priorytet WD001 Obsługa obiektów OWL API. bardzo ważne WJ003 Obsługiwane wersje Javy. bardzo ważne WJ004 Obsługiwane wersje OWL API. bardzo ważne WU001 Tekstowo-okienkowy interfejs do integracji. bardzo ważne WI001 Dokumentacja w Javadoc. ważne WI003 Dokumentacja w języku polskim. ważne WI004 Nazwy zmiennych i funkcji w języku angielskim. ważne WU002 Graficzny interfejs do integracji. mało ważne WI002 Dokumentacja w języku angielskim. mało ważne Spełnienie wymagań określonych jako średnio i mało ważne, jest opcjonalne. Są wśród nich m.in. wymagania dotyczące wizualizacji oraz funkcja automatycznego podpowiadania przy tworzeniu powiązań. Funkcje te zostaną zrealizowane, jeżeli projekt zostanie zakończony przed czasem. 22

3.2.2. Diagram przypadków użycia Diagram ten przedstawia funkcjonalność wnoszoną lub zmienianą przez moduł do integracji. Nie zawiera on przypadków użycia, które nie będą modyfikowane przez moduł. Rys. 3.1. Diagram przypadków użycia. Z diagramu można odczytać trzy główne funkcjonalności, które muszą zostać zaimplementowane. Po pierwsze, musi istnieć możliwość utworzenia projektu integracji ontologii oraz jego zapisywania i wczytywania. Główną i najważniejszą funkcją będzie tryb edycji projektu integracji. Najczęściej będzie to dodawanie elementów opisujących wzajemne relacje pomiędzy integrowanymi ontologiami. Dodatkowo, przewidziano także możliwość modyfikacji i usunięcia istniejących elementów. Po zakończeniu prac, będzie można wyeksportować wynikową ontologię do pliku na dwa sposoby: poprzez import integrowanych ontologii lub poprzez skopiowanie wszystkich elementów do nowej przestrzeni nazw. 3.2.3. Architektura System OCS napisany jest w technologii J2EE. Na rysunku 3.2 pokazano jego obecną architekturę. 23

Rys. 3.2. Architektura systemu OCS [9]. Realizowany projekt ma na celu jedynie rozszerzenie edytora dla systemu OCS (zaznaczonego na rys. 3.2), dlatego też istniejąca architektura systemu OCS pozostanie bez zmian. Sam edytor jest aplikacją Java Web Start, działającą po stronie klienta. Takie rozwiązanie pozwala na łatwe pobranie aktualnej wersji edytora z serwera i jego późniejsze uruchamianie nawet bez połączenia internetowego. Prace implementacyjne obejmą refaktoryzację i rozszerzenie funkcjonalności kilku istniejących klas oraz utworzenie kilku nowych pakietów. 24

3.3. Analiza obiektowa W tym rozdziale, zostaną przedstawione najważniejsze diagramy klas, przedstawiające w jaki sposób komponenty interfejsu użytkownika zostaną rozszerzone i wykorzystane do budowy interfejsu zaprojektowanego w poprzednim rozdziale niniejszej pracy. Jest to jedynie fragment analizy obiektowej, która została stworzona na potrzeby tego projektu. Interfejs edytora ontologicznego OCS został wykonany przy użyciu biblioteki Swing, dlatego też wiele przedstawionych w tym rozdziale klas będzie rozszerzało lub korzystało w inny sposób z elementów tej biblioteki. Na rysunku 3.3 pokazano strukturę pakietu org.pg.eti.kask.ont.editor.tree.model. W pakiecie tym znajdują się klasy, odpowiedzialne za przechowywanie drzewiastych struktur poszczególnych rodzajów elementów ontologii. Rys. 3.3. Diagram DK004 - Klasy odpowiedzialne za modelowanie drzew elementów ontologii. Klasa BasicTreeNode reprezentuje element ontologii w drzewie. Zostanie ona rozszerzona o wewnętrzny obiekt typu wyliczeniowego TypeOfNode, który określa rodzaj reprezentowanego elementu, oraz o pole elementontologyalias przechowu- 25

jące informację o aliasie ontologii, z której element pochodzi. Pozostałe klasy rozszerzają klasę javax.swing.tree.defaulttreemodel, która przechowuje model wyświetlanego w komponentach javax.swing.jtree drzewa. Po rozszerzeniu uzyskały one nowy tryb działania, w którym są w stanie przechowywać dane o elementach trzech ontologii jednocześnie. Wyznacznikiem trybu działania tych struktur jest zmienna integrationpreview, która jest ustawiana w konstruktorze danej klasy. Na rysunku 3.4 widoczna jest struktura pakietu org.pg.eti.kask.ont.editor.tree. Rys. 3.4. Diagram DK003 - Klasy odpowiedzialne za obsługę drzew elementów ontologii. Jego główną klasą jest klasa EditableTree. Rozszerza ona klasę javax.swing.jtree umożliwiając dodawanie i usuwanie węzłów drzewa oraz pobranie zaznaczonych ele- 26

mentów drzewa w wygodnej formie. Na diagramie widoczne są również klasy reprezentujące dwa rodzaje paneli z pakietu org.pg.eti.kask.ont.editor.panels. Klasa ComponentRepositoryPanel reprezentuje główny panel, na którym widoczne są drzewa z elementami danego typu z wszystkich trzech integrowanych ontologii. Klasa IntegrationPanel reprezentuje panel stworzony specjalnie na potrzeby projektu integracji ontologii, opisany bardziej szczegółowo w dalszej części tego rozdziału. Pozostałe klasy rozszerzają klasę EditableTree dając możliwość zróżnicowania menu kontekstowego dla różnego rodzaju drzew. Na rysunku 3.5 pokazano strukturę klas panelu integracji. Rys. 3.5. Diagram DK002 - Diagram klas przedstawiający strukturę panelu integracji. Składa się on z dwóch drzew reprezentujących elementy scalanych ontologii. Przyciski operacji, umieszczone pomiędzy drzewami, obsługiwane są poprzez klasy typu Listener. W określeniu typu operacji pomagają specjalnie w tym celu utworzone typy wyliczeniowe. 27

3.4. Struktura plików projektu Zgodnie z wymaganiami WF008 oraz WF009 (tab. 3.1), musi istnieć możliwość zapisania projektu na dysku oraz wznowienia zapisanej w ten sposób pracy. Projekt integracji ontologii, oprócz danych które zawiera każdy projekt systemu OCS, musi zapisać szereg dodatkowych informacji. Przede wszystkim, konieczne jest zapisanie obu integrowanych ontologii oraz wszystkich utworzonych w procesie integracji elementów. Integrowane ontologie zostaną zapisane w plikach o nazwie będącej aliasem nadanym danej ontologii podczas tworzenia projektu integracji. Ponieważ elementy wynikowej ontologii pochodzące z ontologii integrowanych znajdą się w tych dwóch plikach, w pliku base.ont zostaną zapisane jedynie nowe elementy, utworzone podczas integracji. Do deskryptora projektu zostanie dodany nowy znacznik integration z atrybutem fileuri. Obecność tego znacznika w deskryptorze oznaczać będzie, że dany projekt jest projektem integracji ontologii, a atrybut fileuri będzie wskazywał ścieżkę do deskryptora integracji. Strukturę deskryptora integracji najlepiej zobrazuje przykład: <?xml version="1.0" encoding="utf-8"?> <integration> <ontologies> <ontology alias="amino-acid" fileuri="file:/home/infinity/ocs/acidpizza/amino-acid" /> <ontology alias="pizza" fileuri="file:/home/infinity/ocs/acidpizza/pizza" /> </ontologies> <newontology alias="acidpizza2" /> </integration> Zawiera on informacje o aliasach wszystkich trzech ontologii oraz o położeniu plików ontologii integrowanych. 28

3.5. Harmonogram prac Rozdział ten zawiera harmonogram prac w formie tablicy oraz dwóch wykresów Gantta. Rys. 3.6. Planowany harmonogram prac. 29

Rys. 3.7. Planowany harmonogram prac. 30

Rys. 3.8. Planowany harmonogram prac. 31

3.6. Analiza SWOT Celem analizy SWOT jest ocena wykonalności postawionego przed autorem niniejszej pracy zadania. W ramach przeprowadzonej analizy SWOT zidentyfikowano silne i słabe strony projektu rozszerzenia edytora OCS (czynniki wewnętrzne) oraz szanse i zagrożenia, które mogą się pojawić w trakcie realizacji projektu (czynniki zewnętrzne). Tab. 3.3. Czynniki zidentyfikowane w trakcie analizy SWOT Mocne strony znajomość języka OWL znajomość biblioteki OWL API Słabe strony brak dokumentacji projektowej dla istniejącej części edytora znajomość pakietu Swing Szanse napotkanie przystępnego, łatwo rozszerzalnego kodu przyspieszenie prac dzięki wysokiej dostępności klienta Zagrożenia napotkanie skomplikowanego, trudno rozszerzalnego kodu spowolnienie prac z powodu innych zajęć na uczelni Zidentyfikowane mocne strony projektu pozwolą częściowo zniwelować słabości oraz zagrożenie związane z koniecznością przeanalizowania istniejącego kodu edytora OCS. Największym zagrożeniem dla realizowanego projektu może się okazać po prostu brak czasu, który może spowodować znaczne opóźnienia. 32

3.7. Projekt interfejsu użytkownika Interfejs użytkownika jest kluczowym elementem edytora. Na rysunku 3.9 pokazano istniejący interfejs edytora służący do edycji pojedynczej ontologii. Rys. 3.9. Interfejs edytora OCS podczas edycji pojedynczej ontologii. Po lewej stronie widoczny jest panel główny edytora. Ontologia jest na nim prezentowana jako trzy drzewa: klas, właściwości i bytów. Wszystkie możliwe do wykonania na ontologii operacje są dostępne z menu kontekstowego na tym panelu. Większy panel po prawej stronie zawiera zakładki, prezentujące ontologię wizualnie w postaci różnych grafów. Do pracy z projektem integracji ontologii, konieczne jest zaprojektowanie nowego interfejsu, ponieważ użytkownik będzie pracował jednocześnie z trzema ontologiami: dwoma integrowanymi oraz wynikową. Wymusza to konieczność zaprezentowania trzech ontologii jednocześnie, najlepiej w tej samej lub zbliżonej formie. W ramach pracy skupiono się na stworzeniu interfejsu tekstowo-okienkowego. Stworzenie interfejsu graficznego, umożliwiającego integrowanie ontologii, a więc prezentującego kilka ontologii jednocześnie, jest tematem osobnej pracy magisterskiej. Na rysunku 3.10 pokazano projekt interfejsu użytkownika dla edycji projektu integracji ontologii. 33

Rys. 3.10. Interfejs edytora OCS podczas edycji projektu integracji ontologii. Dodatkowa funkcjonalność wymaga dużo miejsca i dlatego zostanie umieszczona na większym, prawym panelu. Posługiwanie się pełnym URI dla każdej z integrowanych ontologii byłoby kłopotliwe, ze względu na jego długość, dlatego też podczas tworzenia projektu integracji ontologii, użytkownik będzie zobowiązany do wprowadzenia aliasu dla każdej z trzech ontologii. Alias ten powinien być jak najkrótszym ciągiem znaków, różnym dla każdej z ontologii. Jednocześnie powinien on umożliwiać łatwe rozpoznanie ontologii, którą reprezentuje. Do prezentacji ontologii zdecydowano się wykorzystać istniejący już komponent drzewa znajdujący się na panelu głównym. Na rysunku przedstawione są przykładowe drzewa klas dla ontologii integrowanych (aliasy A oraz B ) oraz wynikowej (alias C ). Dzięki zastosowaniu aliasów, wiadomo będzie która ontologia jest prezentowana w danym drzewie. Elementy prezentowane w głównym drzewie ontologii wynikowej będą poprzedzone etykietami w zależności od ich pochodzenia. Widoczne na rysunku 3.1 etykiety, oznaczają: A, B lub C - widoczny element pochodzi z ontologii oznaczonej danym aliasem, A+B - widoczny element pochodzi z ontologii A i jednocześnie z B (jest zdefiniowany w obu ontologiach), Usunięto - widoczny element został usunięty i nie zostanie zapisany podczas eksportu. 34

Pomiędzy dwoma integrowanymi ontologiami znajdować się będą przyciski, umożliwiające szybkie dodanie lub usunięcie relacji wiążących elementy obu ontologii. Odpowiednie przyciski (dodawania lub usuwania relacji) będą włączane i wyłączane w zależności od istnienia danej relacji, pomiędzy zaznaczonymi w obu drzewach elementami. Dzięki takiemu rozwiązaniu, użytkownik będzie zawsze wiedział, czy zaznaczone elementy są w danym związku. Inne, bardziej złożone operacje, będzie można wykonać poprzez menu kontekstowe w głównym drzewie, w sposób identyczny jak podczas edycji pojedynczej ontologii. Możliwe jest też dalsze usprawnienie zaprojektowanego interfejsu, obejmujące następujące funkcje: implementacja wyświetlania elementów w postaci listy posortowanej alfabetycznie zamiast drzewa (widoczna na rys. 3.10), implementacja filtra umożliwiającego wyszukiwanie elementów za pomocą wyrażeń regularnych (widoczna na rys. 3.10). 35

4. Implementacja 4.1. Wprowadzenie W rozdziale tym, opisano przebieg prac związanych z implementacją rozszerzenia edytora ontologicznego OCS. Na początku znajduje się opis metodyki wg której prowadzone były prace nad projektem. Następnie wymieniono i krótko opisano wykorzystywane do tych prac środowiska i narzędzia. Na końcu opisano najpoważniejsze problemy napotkane w trakcie prac oraz przedstawiono kilka szczegółowych przykładów zastosowanych w trakcie prac rozwiązań implementacyjnych. 4.2. Metodologia projektowania i implementacji Podczas prac nad rozszerzaniem edytora OCS posłużono się metodyką RUP. Definiuje ona iteracyjny proces wytwarzania oprogramowania, który może zostać odpowiednio dopasowany, w zależności od potrzeb konkretnego projektu. Projekt wykonywany w ramach niniejszej pracy magisterskiej jest specyficzny z dwóch powodów. Po pierwsze, jest to praca jednoosobowa, a więc nietypowa, jeżeli chodzi o projekty informatyczne. Po drugie, ma on na celu rozszerzenie funkcjonalności istniejącego już edytora dla systemu OCS. W związku z tym, dokumentacja wytwarzana w ramach przyjętej metodyki, została odpowiednio przycięta i dopasowana do specyfiki projektu. W szczególności, ze względu na brak komunikacji pomiędzy członkami zespołu (występuje jedynie komunikacja z klientem), możliwe było znaczne skrócenie czasu trwania pojedynczej iteracji. Dzięki temu, implementacja przebiegała małymi kroczkami, a klient miał lepszą kontrolę nad kierunkiem rozwoju edytora. Metodyka RUP dzieli proces wytwarzania oprogramowania na cztery fazy [2]: 1. Faza wstępna (Inception). 2. Faza opracowywania (Elaboration). 3. Faza konstrukcji (Construction). 4. Faza przejścia (Transition). Celem fazy wstępnej jest przede wszystkim wyznaczenie zakresu prac. W ramach tej fazy dokonano przeglądu literatury oraz istniejących narzędzi w temacie integracji ontologii. Następnie rozpoczęto prace nad Specyfikacją Wymagań Systemowych oraz sporządzono pierwsze wersje Diagramu Przypadków Użycia, określającego docelową funkcjonalność systemu. W kolejnych iteracjach tej fazy aktualizowano dokument SWS. 36

W fazie opracowania, wstępnie zapoznano się z architekturą oraz rozwiązaniami zastosowanymi w istniejącej wersji edytora OCS. Umożliwiło to uszczegółowienie wymagań i w konsekwencji utworzenie pełnego dokumentu SWS z dokładnym opisem przypadków użycia oraz wszystkich wymagań. W fazie tej zaprojektowano również interfejsy oraz architekturę rozszerzenia. W trakcie kolejnych iteracji tej fazy aktualizowano projekt interfejsu oraz analizę obiektową. Najbardziej czasochłonną fazą jest faza konstrukcji. W ramach tej fazy mieści się większość wykonanych prac implementacyjnych oraz testów wewnętrznych edytora OCS. Każda faza konstrukcji kończyła się utworzeniem kolejnej wersji edytora w repozytorium SVN. Ostatnią fazą jest faza przejścia. W trakcie tej fazy zaimplementowana w fazie konstrukcji funkcjonalność jest testowana przez klienta, mgr inż. Tomasza Boińskiego, który następnie akceptuje zmiany lub zgłasza do nich uwagi. Po otrzymaniu uwag od klienta, następuje kolejna iteracja. Podczas ostatniej iteracji zostały przeprowadzone gruntowne testy pełnej funkcjonalności edytora OCS, celem uzyskania ostatecznej akceptacji dla wszystkich wprowadzonych zmian. 4.3. Środowiska i narzędzia wspomagające Prace nad projektem były prowadzone w systemie Ubuntu 9.10. Podstawowym narzędziem pracy było środowisko NetBeans IDE 6.5. Jest to zintegrowane środowisko deweloperskie, które wspomaga prace nad kodem poprzez zaawansowane kolorowanie składni, podpowiedzi dopasowane do kontekstu oraz daje natychmiastowy dostęp do odpowiednich fragmentów dokumentacji w Javadoc. Środowisko to ma również wbudowanego klienta SVN oraz narzędzie do porównywania i scalania plików tekstowych. Przydatny był również wbudowany debugger, który można było podłączyć do uruchomionego edytora w dowolnej chwili. Narzędzie to posiada także wtyczkę, umożliwiającą interpretację i wykonywanie skryptów programu Ant, na których opiera się proces budowania i uruchamiania wszystkich komponentów systemu OCS, oraz wtyczkę umożliwiającą łatwe tworzenie modeli i diagramów w języku UML. Dokumentacja projektowa oraz treść niniejszej pracy została napisana w środowisku L A TEX. Harmonogram prac został utworzony za pomocą darmowego programu Gantt- Project. Projekt interfejsu użytkownika został wykonany za pomocą aplikacji Balsamiq Mockups. Narzędzie to w darmowej wersji pozwala na szybkie zaprojektowanie nawet najbardziej złożonego interfejsu użytkownika. Do przeszukiwania zasobów sieci internetowej wykorzystano przeglądarkę Google 37

Chrome w wersji przeznaczonej dla systemów linuksowych oraz strony www.google.pl i scholar.google.pl. 4.4. Główne problemy informatyczne Najprostszym sposobem zintegrowania ontologii jest utworzenie nowej, importującej ontologie integrowane. Taka ontologia zawierałaby jedynie deklaracje importu, reprezentowane w języku OWL za pomocą znacznika owl:imports i odwołujące się do importowanych ontologii poprzez ich URI, oraz elementy dodane w procesie integracji, zdefiniowane w ramach URI nowej ontologii. Takie rozwiązanie uniemożliwiałoby jednak dokonywanie jakichkolwiek zmian w importowanych ontologiach (wymagania WF007 oraz W013 w tab. 3.1). Dodatkowo, URI wcale nie musi wskazywać lokalizacji pliku z ontologią. W takim przypadku nie będzie można odczytać i przedstawić w edytorze zaimportowanych elementów. W związku z powyższymi problemami zdecydowano się na implementację eksportu ontologii na dwa sposoby. Pierwszy to zaimportowanie integrowanych ontologii oraz skopiowanie ich elementów z zachowaniem URI (wymaganie WF011 w tab. 3.1). Rozwiązanie to gwarantuje, że odczytanie zaimportowanych elementów będzie zawsze możliwe. Drugi sposób to skopiowanie elementów z integrowanych ontologii połączone ze zmianą ich URI na URI docelowej ontologii (wymaganie WF012 w tab. 3.1). Daje on możliwość edycji i usuwania wszystkich elementów znajdujących się w wynikowej ontologii, jednak aby eksport mógł się poprawnie zakończyć konieczne jest rozwiązanie wszystkich istniejących konfliktów nazw. W pierwszym rozwiązaniu elementy takie są rozróżniane poprzez ich URI, jednak w tym przypadku będzie ono jednakowe, co spowodowałoby przypadkowe scalenie elementów, które w rzeczywistości mogą oznaczać co innego. Kolejnym utrudnieniem w pracach nad projektem był fakt, iż system OCS nie posiadał szczegółowej dokumentacji ani nawet dokumentacji w Javadoc. Z tego powodu konieczne było poświęcenie kilku dni na mozolne czytanie kodu, celem zrozumienia sposobu działania edytora. Aby uniknąć tego typu sytuacji w przyszłości, w ramach prac projektowych dokumentację w Javadoc tworzono na bieżąco. Utworzono także dokument Analizy Obiektowej zawierający szczegółowe informacje o strukturze edytora ontologicznego. Co więcej, system OCS nie był zaprojektowany do pracy z kilkoma ontologiami jednocześnie. Dane jedynej edytowanej ontologii były zapisywane w pliku o nazwie base.ont, a w samej aplikacji trzymane jako pojedyncza zmienna w klasie będącej singletonem. Podobnie było w klasach odpowiedzialnych za przechowywanie modeli drzew elementów prezentowanej ontologii. Wszystkie te miejsca wymagały stosownej modyfikacji i usprawnień. 38

4.5. Przykłady rozwiązań szczegółowych 4.5.1. Struktura komponentów panelu integracji Panel integracji, widoczny na rys. 3.10 po prawej stronie, posiada sporo wbudowanych przycisków. Do ich obsługi konieczne było utworzenie nasłuchiwaczy (klas typu Listener), które asynchronicznie wykonają przypisane im zadania. W większości przypadków nasłuchiwacze implementowane są jako klasy wewnętrzne, jednak ich złożoność w projekcie znacznie obniżyła by czytelność kodu klasy IntegraionPanel. Przedstawiony na rys. 3.5 pakiet, oprócz klasy głównej, zawiera trzy rodzaje klas. Trzy klasy typu Actionlistener zawierają implementację obsługi akcji przycisków dostępnych z trzech zakładek panelu (przedstawiających klasy, właściwości oraz byty). Klasy typu SelectionChangeListener służą do włączania i wyłączania przycisków, w zależności od istnienia związanego z nimi związku pomiędzy wybranymi na panelu klasami. Ze względu na dużą liczbę zaimplementowanych na panelu integracji akcji, trzeba było im zapewnić łatwy i przejrzysty dostęp. Aby to osiągnąć, reprezentujące je ciągi znakowe zgrupowano w trzech typach wyliczeniowych Enum, po jednym dla każdej zakładki. 4.5.2. Wybór zarządcy układu Ważną częścią prac implementacyjnych były prace nad interfejsem. Został on w całości napisany za pomocą biblioteki Swing. W bibliotece tej do rozmieszczania i określania zachowania poszczególnych elementów wykorzystuje się zarządców układu, czyli klasy rozszerzające java.awt.layoutmanager. W samej bibliotece dostępnych jest kilka takich klas: BorderLayout, BoxLayout, CardLayout, FlowLayout, GridBagLayout, GridLayout, GroupLayout, SpringLayout. Każda z tych klas umożliwia rozmieszczenie elementów interfejsu w inny sposób. 39

Autor pierwszej implementacji edytora dla systemu OCS zdecydował się na wykorzystanie zarządcy GroupLayout. Zarządca ten był zaprojektowany dla narzędzi do graficznej edycji interfejsu użytkownika takich jak Mtisse, które jest częścią w środowiska NetBeans IDE. Aby mieć lepszą kontrolę, nad konstruowanym interfejsem użytkownika, został on jednak w całości napisany ręcznie. Aby skonstruować interfejs za pomocą tego zarządcy, trzeba zdefiniować dwa wymiary: poziomy i pionowy. Oznacza to, że definiując rozkład elementów wzdłuż jednej z osi, można zapomnieć o osi drugiej. Niestety wadą takiego rozwiązania jest fakt, iż każdy z elementów interfejsu musi być zadeklarowany zarówno w wymiarze poziomym jak i pionowym. Dodatkowo, kod powstający przy wykorzystaniu tego zarządcy jest nieczytelny i uniemożliwia szybkie określenie pozycji pojedynczego elementu, gdyż jest on zdefiniowany w dwóch miejscach. Poniżej znajduje się przykładowy fragment kodu tworzącego interfejs okienka zawierający pięć elementów wyciągnięty z edytora OCS: JPanel mainpanel = new JPanel(); GroupLayout layout = new GroupLayout(mainPanel); mainpanel.setlayout(layout); layout.setautocreatecontainergaps(true); layout.setautocreategaps(true); layout.sethorizontalgroup(layout.createsequentialgroup().addgroup(layout.createparallelgroup(grouplayout.alignment.leading).addcomponent(label).addgroup(layout.createsequentialgroup().addgroup(layout.createparallelgroup(grouplayout.alignment.trailing).addcomponent(domainclasseslistscrollpane).addgroup(layout.createsequentialgroup().addcomponent(okbutton).addcomponent(cancelbutton))).addgroup(layout.createparallelgroup(grouplayout.alignment.leading).addcomponent(addbutton).addcomponent(removebutton))) )); //pozniej pionowej layout.setverticalgroup(layout.createsequentialgroup().addcomponent(label).addgroup(layout.createparallelgroup(grouplayout.alignment.leading).addcomponent(domainclasseslistscrollpane) 40

.addgroup(layout.createsequentialgroup().addcomponent(addbutton).addcomponent(removebutton))).addgroup(layout.createparallelgroup().addcomponent(okbutton).addcomponent(cancelbutton))); layout.linksize(swingconstants.horizontal, okbutton, cancelbutton); layout.linksize(swingconstants.horizontal, removebutton, addbutton); W powyższym przykładzie nie zachowano tabulacji, która nieco ułatwia odszukiwanie nawiasów. Z powodu wymienionych wad, wykorzystywanie tego zarządcy do ręcznego tworzenia bardziej skomplikowanych interfejsów użytkownika nie jest zalecane. Wg [5], najbardziej elastycznym i konfigurowalnym zarządcą układu jest GridBagLayout. Umożliwia on rozmieszczanie komponentów interfejsu przy użyciu tablicy. Każdy komponent interfejsu rozmieszczany za pomocą tego zarządcy musi mieć zdefiniowane reguły, ograniczenia określające jego położenie. Zbiór takich ograniczeń stanowi klasa java.awt.gridbagconstraints. Obiekty tej klasy mogą być tworzone oddzielnie dla każdego komponentu, lecz mogą być także wykorzystywane wielokrotnie. Wielokrotne wykorzystywanie ograniczeń znacznie skraca kod oraz zwiększa jego czytelność, w przypadku rozmieszczania kolejnych komponentów (np. w jednej kolumnie). Poniższa lista przedstawia ograniczenia, które można nałożyć na komponent: gridx, gridy - Określają współrzędne komórki komponentu lub jego górnego lewego narożnika, jeżeli jest rozciągnięty (domyślnie 0, 0); gridwidth, gridheight - Określają szerokość i wysokość elementu w komórkach (domyślnie 1, 1); fill, weightx, weighty - Jeżeli komórka jest większa, niż zawarty w niej komponent, umożliwia ustawienie rozszerzania się komponentu w wybranym kierunku. Szybkość rozszerzania się można regulować za pomocą wag (domyślnie elementy nie są rozszerzane razem z komórkami); ipadx, ipady - Określają margines wewnętrzny komórki (domyślnie brak); insets - Obiekt określający zewnętrzny margines komponentu (domyślnie brak); anchor - Określa wyrównanie elementu w poziomie i w pionie. Ze względu na liczne zalety, podczas implementacji rozszerzenia zdecydowano się stosować zarządcę GridBagLayout. Poniższy fragment kodu przedstawia sposób w jaki 41

rozmieszczono główne panele interfejsu użytkownika, widocznego na rysunku 3.10 (prawy panel): // Panele edycji ontologii źródłowej treepanelc = new GridBagConstraints(); // gridx - różne numery kolumn: 0 i~2 treepanelc.gridx = GridBagConstraints.RELATIVE; treepanelc.gridy = 0; treepanelc.gridheight = 2; treepanelc.insets = new Insets(5, 5, 5, 5); treepanelc.anchor = GridBagConstraints.CENTER; treepanelc.fill = GridBagConstraints.BOTH; treepanelc.weightx = 0.5; treepanelc.weighty = 1.0; // Panel z~przyciskami operacji buttonpanelc = new GridBagConstraints(); buttonpanelc.gridx = 1; buttonpanelc.gridy = GridBagConstraints.RELATIVE; buttonpanelc.insets = new Insets(5, 2, 5, 2); buttonpanelc.anchor = GridBagConstraints.PAGE_START; buttonpanelc.fill = GridBagConstraints.VERTICAL; buttonpanelc.weighty = 1.0; // Pojedynczy element wewnętrzny singlec = new GridBagConstraints(); singlec.gridx = 0; singlec.gridy = 0; singlec.insets = new Insets(1, 1, 1, 1); singlec.anchor = GridBagConstraints.CENTER; singlec.fill = GridBagConstraints.BOTH; singlec.weightx = 1.0; singlec.weighty = 1.0;... /** * Obudowuje zadany komponent w~ramkę z~tytułem. * @param inner komponent do~obudowania * @param title tytuł dla ramki * @return panel z~komponentem w~zatytułowanej ramce */ private JPanel putintotitledframe(component inner, String title) 42

{ } JPanel titledframe = new JPanel(); titledframe.setlayout(new GridBagLayout()); titledframe.setborder(borderfactory.createtitledborder(title)); titledframe.add(inner, singlec); return titledframe;... treepanelc.gridx = 0; classespanel.add( putintotitledframe(classesaddoperationspanel, messages.getstring("addaxiom.title") ), buttonpanelc); classespanel.add( putintotitledframe(classesremoveoperationspanel, messages.getstring("removeaxiom.title") ), buttonpanelc); treepanelc.gridx = 2; classespanel.add(putintotitledframe(scrollpaneb, aliasb), treepanelc); Trzy, zdefiniowane na początku przykładu, zestawy ograniczeń oraz funkcję wykorzystano także do utworzenia pozostałych zakładek edytora. Zastosowanie powyższej techniki podczas dalszego rozwoju interfejsu tekstowo-okienkowego w edytorze OCS może znacznie ułatwić dalsze prace nad jego rozwojem. 43

5. Podsumowanie 5.1. Ocena rozszerzenia W chwili obecnej prace nad rozszerzeniem są na ukończeniu. Na rysunku 5.1 pokazano interfejs edycji projektu integracji ontologii. Rys. 5.1. Interfejs edycji integracji ontologii. Zaimplementowana została znaczna większość wymaganych funkcjonalności (tab. 3.1) wraz ze stosowną dokumentacją (tab. 3.2). Wszystkie zaimplementowane funkcjonalności zostały przetestowane wewnętrznie oraz zaakceptowane przez klienta, mgr inż. Tomasza Boińskiego. Testy końcowe, obejmujące całą funkcjonalność rozszerzenia, zostaną przeprowadzone na podstawie, zdefiniowanych w specyfikacji wymagań funkcjonalnych, przypadków użycia. Niestety nie udało się zmieścić w zakładanym na semestr dziesiąty harmonogramie prac. Przyczyną takiego stanu rzeczy był m.in. stan zaawansowania edytora, który okazał się być mniejszy, niż oczekiwano. Jednocześnie nakład pracy do wykonania został niedoszacowany. Prace implementacyjne zajęły około trzykrotnie więcej czasu, niż planowano. W ramach tych prac powstało około pięciu tysięcy linii kodu w języku Java. Efekty tych prac można jednak śmiało uznać za sukces, o czym najlepiej świad- 44

czy zadowolenie klienta. W ich wyniku powstała kolejna funkcjonalność edytora, dająca mu nowe możliwości oraz zwiększająca jego atrakcyjność względem innych podobnych narzędzi. Dodatkowo powstała również pełna dokumentacja nowych oraz zmienianych fragmentów edytora, co ułatwi dalsze prace nad nim. 5.2. Dalsze możliwości rozbudowy Obecnie trwają intensywne prace nad rozwojem edytora ontologicznego dla systemu OCS. Zaimplementowany interfejs umożliwiający integrację ontologii, w przyszłości ma zostać uzupełniony o odpowiednią wizualizację na bazie biblioteki SOVA, stanowiącą jednocześnie interfejs graficzny, a także o moduł automatyzacji wyszukiwania i tworzenia powiązań pomiędzy podobnymi elementami obu integrowanych ontologii. Docelowo, projekt integracji ontologii, również można będzie przechowywać bezpośrednio w systemie OCS. Zaimplementowany ma również zostać mechanizm porównywania różnych wersji tej samej ontologii operujący bezpośrednio na ontologiach poprzez interfejs tekstowo-okienkowy oraz graficzny. Następnie mechanizm ten można będzie rozszerzyć tak, aby był w stanie porównać i scalić różne wersje projektu integracji ontologii. Jeżeli wyżej wymienione funkcjonalności zostaną zrealizowane, edytor OCS ma szansę stać się jednym z wiodących narzędzi do edycji ontologii. 45

Literatura [1] Tim Berners-Lee, James Hendler, Ora Lassila. The Semantic Web. Scientific American, 2001. [2] Rational Software Corporation. Rational Unified Process: Best Practices for Software development Teams. Rational Software White Paper TP026B, Rev 11/01, 2001. [3] Stephan Grimm, Pascal Hitzler, Andreas Abecker. Knowledge Representation and Ontologies. Springer, 2007. [4] Thomas R. Gruber. A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, 5(2), 1993. [5] http://download.oracle.com/javase/tutorial/uiswing/layout/index.html. The java tutorials - laying out components within a container. [6] http://oboedit.org. Strona domowa edytora obo-edit. [7] http://protege.stanford.edu/plugins/prompt/prompt.html. Strona domowa wtyczki prompt. [8] http://semanticweb.org. Strona sieci semantycznej. [9] Andrzej Jakowski. Platforma do edycji ontologii z dostępem przez WWW. Praca magisterska na Wydziale ETI Politechniki Gdańskiej, Gdańsk, 2008. [10] Ernesto Jimenez-Ruiz, Bernardo Cuenca Grau, Ian Horrocks, Rafael Berlanga. Ontology Integration Using Mappings: Towards Getting the Right Logical Consequences. 2008. [11] Katedra Architektury Systemów Komputerowych (KASK). Inżynieria ontologii i jej zastosowania. Politechnika Gdańska, Gdańsk, 2008. [12] Andrzej Kobyliński. ISO/IEC 9126 - Analiza modelu jakości produktów programowych. Konferencja Systemy Wspomagania Organizacji, 2003. [13] Hyunjang Kong, Myunggwon Hwang, Pankoo Kim. A New Methodology for Merging the Heterogeneous Domain Ontologies based on the WordNet. [14] Ling Liu, M. Tamer Özsu (Eds.). Encyclopedia of Database Systems. Springer- Verlag, 2009. [15] Natalya F. Noy, Mark A. Musen. The PROMPT Suite: Interactive Tools For Ontology Merging And Mapping. 2003. 46

[16] Helena Sofia Pinto, Joao P. Martins. Ontology Integration: How to perform the Process. [17] Steffen Staab, Michael Erdmann, Alexander Maedche, Stefan Decker. An Extensible Approach for Modeling Ontologies in RDF(S). ECDL 2000 Workshop on the Semantic Web, Lizbona, Portugalia, 2000. [18] Li Zhu, Qing Yang, Wei Chen. Research on Ontology Integration Combined with Machine learning. 2009. 47

Wykaz skrótów i symboli API CVS DL GPL IDE ISO OBO OCS OWL RDF RDFS Application Programming Interface - interfejs programu lub biblioteki, umożliwiający współpracę z innym oprogramowaniem. Concurrent Versions System - popularny system kontroli wersji udostępniany na licencji GPL. Description Logic - logika opisowa. GNU General Public License - licencja wolnego i otwartego oprogramowania. Integrated Development Environment - zintegrowane środowisko do wytwarzania oprogramowania. International Organization for Standardization - międzynarodowa organizacja standaryzacyjna. Open Biomedical Ontology format - język zapisu ontologii biomedycznych. Ontology Creation System - system do tworzenia, składowania i wersjonowania ontologii. Ontology Web Language - rodzina języków zapisu ontologii oparta o standard RDF/XML. Resource Description Framework - standardowy model wymiany danych w sieci WWW. Resource Description Framework Schema - rozszerzalny język reprezentacji wiedzy, dostarczający podstawych elementów do opisu ontologii. RDF/XML standard definiujący składnię XML dla RDF. RUP SOVA SVN Rational Unified Process - proces iteracyjnego wytwarzania oprogramowania opracowany przez firmę Rational Software Corporation. Simple Ontology Visualization API - biblioteka do wizualizacji ontologii, udostępniona również w postaci wtyczki do edytora Protégé. Subversion - system kontroli wersji, będący następcą CVS. 48

SWS URI W3C WWW XML Specyfikacja Wymagań Systemowych - dokument opisujący wymagania stawiane systemowi. Uniform Resource Identifier - ciąg znaków jednoznacznie identyfikujący nazwę lub zasób w sieci Internet. World Wide Web Consortium - międzynarodowa organizacja standaryzująca sieć WWW. World Wide Web - system informacyjny oparty na otwartych, publicznie dostępnych standardach. Extensible Markup Language - standard zapisu dokumentów w formie czytelnej dla maszyn, umożliwiający zapisanie dowolnych struktur danych. 49

Załączniki

A. Specyfikacja Wymagań systemowych A.1. Przypadki użycia A.1.1. Diagram przypadków użycia Poniższy diagram przedstawia funkcjonalność wnoszoną lub zmienianą przez moduł do integracji. Nie zawiera on przypadków użycia, które nie będą modyfikowane przez moduł. A.1.2. Opis przypadków użycia PU002 Aktorzy Streszczenie Zdarzenie inicjujące Warunki początkowe Eksport zintegrowanej ontologii z zachowaniem URI (import elementów) U001 Funkcja umożliwiająca utworzenie nowej ontologii poprzez zaimportowanie ontologii źródłowych do tej ontologii. Wybór opcji Eksport z zachowaniem URI z menu. Wczytany Projekt itegracjii ontologii. 51