Specyfikacja metody OB4RE (Ontology Building For Requirements Elicitation)

Projektowana metoda OB4RE (Ontology Building for Requirements Elicitation) zawiera obszary specyfikacji rozumiane w nomenklaturze EMF jako wzorce możliwości. Wzorce te informują o „procesach dla kluczowego obszaru zainteresowania, takiego jak dyscyplina lub najlepsza praktyka” [1]. Wymienia się wzorce możliwości, które na podstawie modelu ramowego OB4RE prezentowanego przez Rysunek 1 wchodzą we wzajemną interakcję. Kolejne punkty zawierają specyfikację następujących wzorców możliwości: dydaktyka, wymagania, analiza, projekt, implementacja, testowanie, wdrożenie.

Rysunek 1 Framework OB4RE

Przepływ pracy – dydaktyka

Interpretując specyfikację przepływu pracy – dydaktyka na rysunku 2, należy zauważyć na wstępie, że dopiero ostatni z kroków EAR wchodzi w bezpośrednią kooperację z kolejną dyscypliną OB4RE, tj. wymagania. Co zostało sprecyzowane głównie w przepływie pracy – wymagania oraz zadaniach tam wymienionych.

Poniższy opis zadań koncentruje się zasadniczo na specyfikacji EAR, odpowiedzialnościach tych zadań i wzajemnej interakcji. Istotne jest tu dostosowanie podstaw teoretycznych opisanych przez Sagora[2] do specyfiki i celu zastosowania metody OB4RE. W rezultacie wykonania zadań, zapewnione zostanie źródło dla wymagań wobec ontologii.

Rysunek 2 Przepływ pracy – dydaktyka

Wybór zagadnienia

Tablica ratingowa, jako że jest uzgodniona pomiędzy nauczycielami przedmiotu, stanowi kluczowy punkt odniesienia w wyborze zagadnienia. Wytwarzany przez nauczyciela dziennik refleksyjny bazuje na zawartych w tablicy ratingowej uzgodnieniach. Mianowicie przyjmuje się, że na przedmiotach informatycznych, tablica ratingowa kwalifikuje pracę studentów w skali 1 – 5. Przy czym najwyżej ceniona jest praca adekwatna do analogicznych stanowisk w projektach systemów informatycznych zarządzania. Dlatego też, nauczyciel zasadniczo dąży do wyboru takich zagadnień, które pozwolą osiągać studentom 5 poziom skali ratingowej. Podczas wyboru zagadnienia, nie mniej istotny w metodzie OB4RE jest wyodrębnienie tych stanowisk pracy, które odpowiadają za wymagania projektowe, np. analityka systemów informatycznych zarządzania.

Rysunek 3 Dostosowanie tablicy ratingowej do specyfiki metody OB4RE

Uściślenie teorii

Uściślenie teorii, względem sprecyzowanych potrzeb OB4RE, dotyczy tematów interesujących z jednej strony profesję osób odpowiedzialnych za wymagania, a z drugiej temat i dziedzinę projektu informatycznego.

Rysunek 4 Uściślenie teorii w OB4RE

Część wspólna zobrazowana przez Rysunek 4 ma niebagatelne znaczenie podczas uściślenia teorii gdyż uściślenie teorii z osobna dla każdego z wyszczególnionych obszarów mogłoby wpłynąć na inny przebieg wydarzeń. Owa dziedzina zastosowania rozwiązań informatycznych, niesie ze sobą pewną specyfikę pracy analitycznej (np. wykorzystywane w dziedzinie usługi przetwarzania w chmurze), w rezultacie wpływają na pracę rozumianą przez artefakty analityczne (np. wyszczególniając w specyfikacji przypadków użycia obszar dotyczący usług przetwarzania w chmurze).

Identyfikowanie pytań badawczych

Identyfikacja pytań badawczych, poza ogólnymi zaleceniami EAR, obliguje użytkownika OB4RE do zawężenia zakresu badań. Ten pierwotnie ogólny cel poświęcony weryfikacji zgodności postępu pracy dydaktycznej z potrzebami studentów wymaga doprecyzowania względem wybranych zagadnień teoretycznych w kroku poprzednim. Dodatkowo istotne jest tu zainwestowanie czasu w identyfikację tych pytań badawczych, które są adekwatne do wstępnie rozpoznanych obszarów wymagających poszerzenia wiedzy. W pracy przyjęto ścieżkę formułowania pytań badawczych prezentowaną przez Rysunek 5, która prowadzi do wytypowania pytań – celowych.

Rysunek 5 Ścieżka formułowania pytań badawczych

Z opisywanych przez Sagora[1] praktyk, wytypowane priorytety dydaktyczne w poprzednim kroku poświęconemu uściśleniu teorii - stanowią właściwy punkt odniesienia w tej identyfikacji pytań badawczych. Poniższy Rysunek 6 obrazuje szablonową rekonstrukcję graficzną obszarów teoretycznych wybranych w kroku poprzednim, spośród których, dla przykładu, jeden może wymagać pogłębionych badań i identyfikacji pytań. Wyszczególniony przez Rysunek 6 obszar mógłby dotyczyć np. wykorzystania funkcjonalności usług przetwarzania w chmurze.

Rysunek 6 Identyfikacja pytań badawczych

Gromadzenie danych

Czynność gromadzenia danych powinna cechować się jakością, przekładającą się na zapewnienie wartościowych danych. Na podstawie wytycznych Sagora[2] istotne jest gromadzenie danych z wielu niezależnych źródeł (tzw. triangulacja). Zapewnienie niezależnych źródeł podnosi bowiem wiarygodność danych, de facto wpływa na jakość tych danych. W środowisku akademickim istotne byłyby nie tylko dane z obserwacji (uczestniczącej i nieuczestniczącej[3]) i przekazywane pomiędzy studentami, ale dodatkowo np. pozyskiwanie danych poprzez ankietowanie czy też dodatkowe dyskusje. Perspektywa celu metody OB4RE, zwraca dodatkowo uwagę podczas gromadzenia danych na profesję analityka i wytwarzane artefakty projektowe. W rezultacie, przykładowym punktem odniesienia wobec gromadzenia danych mógłby być diagram przypadków użycia prezentowany przez Rysunek 7, względem którego istotne byłoby gromadzenie adekwatnych danych, np.:

- Kto jest użytkownikiem systemu informatycznego (aktorem)?

- Jakiej wartości oczekuje aktor od systemu (przypadek użycia bazowy)?

- Jakie usługi SaaS (Software as a Service) są adekwatne do oczekiwanej wartości (przypadek użycia zawierany)?

Rysunek 7 Szablon przykładowego diagramu przypadku użycia podczas gromadzenia danych

Analiza danych

Analiza danych EAR, pomimo sprecyzowanego znaczenia względem oczekiwań metody OB4RE, również wymaga odpowiedzi na pytania badawcze. W rezultacie analiza ta, powinna doprowadzić do zrozumienia stopnia wiedzy studentów, poświęconej artefaktom analitycznym w realizowanym projekcie związanym de facto z konkretnym przedmiotem. Także wymienione przykładowe pytanie związane z wykorzystywanymi usługami w chmurze, wymaga analizy względem zgromadzonych danych na temat projektów. Praktyki Sagor związane z tym, czy analiza jest realizowana samodzielnie czy też publicznie, zostały zobrazowane przez Rysunek 8.

Rysunek 8 Analiza danych OB4RE samodzielnie vs. publicznie

Wynika z tego, że niebagatelnym zadaniem jest kooperacja badaczy. Tym bardziej, kiedy wymaga współpracy w rozproszonym środowisku. Na pojawienie się trudności mogą mieć wpływ specyficzne informacje wynikające z procesu EAR.

Wymieniany przykład zastosowania usług przetwarzania w chmurze, pociągałby za sobą skorzystanie z doświadczeń w wykorzystaniu interfejsu API konkretnego dostawcy usług SaaS propagowanych w adekwatnym środowisku profesjonalistów np. linkedin.com, developers.google.com

Raportowanie rezultatów

Raportowanie rezultatów w metodzie OB4RE, nie odbiega od ogólnych zaleceń Sagor [2] wobec EAR. Natomiast ta ogólnie rozumiana odpowiedzialność dotycząca uzewnętrznienia wniosków z pracy badawczej, tutaj jest bardziej sprecyzowana. Bowiem to zawężenie zainteresowania wiedzą prowadzi do bardziej przewidywalnych wniosków, odnoszących się do potrzeb dydaktycznych związanych z wytwarzaniem artefaktów analitycznych. Wymieniany przykład wykorzystania usług przetwarzania w chmurze, wymagałby udostępnienia raportów pozwalających docelowo na podjęcie tzw. świadomych działań w pracy nauczyciela, pozwalających podjąć decyzje dydaktyczne wobec adekwatnego API, usług udostępnianych, technologii i ostatecznie potrzeb studentów. Raportowanie rezultatów, odnoszące się wprost do celu metody OB4RE, mogłoby uwypuklać odpowiedzi na przykładowe pytania:

1. Jakie role i odpowiedzialności przyjęli studenci?

2. Jakie artefakty projektowe dotyczą specyfikacji wymagań?

3. Jaki jest stan prac studentów dotyczących artefaktów projektowych?

Podejmowanie świadomych działań

Należy przede wszystkim zauważyć, że podejmowanie świadomych działań odbywa się w środowisku akademickim i podczas nauczania przedmiotów informatycznych. Powodzenie metody OB4RE wymaga uwzględnienia pewnych uwarunkowań środowiskowych, rozumianych przez regulamin obowiązujący na uczelni. Spośród różnych zapisów istotne są również ustalenia z kierownikiem katedry, czy też wykładowcą przedmiotu (począwszy do samych uzgodnień wobec skali ratingowej stosowanej w pierwszym z kroków EAR).

Z ogólnych wytycznych Sagor wynika, że planowanie świadomych działań powinno przede wszystkim unikać błędów z przeszłości. Uwzględnienie tego warunku w środowisku akademickim może w rzeczywistości być ułatwione przez ciągły proces dydaktyczny uniwersytetu. W tym przekazywanie wiedzy z semestru na semestr pomiędzy nauczycielami, aktualizacje sylabusa i materiałów dydaktycznych. Dodatkowo, istotne są tu także preferencje studentów związane z metodami nauczania, które są często „dziedziczone” pomiędzy przedmiotami (np. wypracowane metody w jednym roku akademickim, wykorzystywane w kolejnych latach i przedmiotach). Rysunek 9, oddający ogólny charakter badań interwencyjnych, wydaje się dobrze obrazować ten ustawiczny proces doskonalenia pracy nauczyciela. Powinien być uwzględniony w ostatnim z kroków EAR tj. podejmowanie świadomych działań. Scharakteryzowany przykład mógłby w tym kroku dotyczyć np. preferencji studentów wobec dydaktyki poświęconej wykorzystaniu usług SaaS, aktualizacji wykorzystywanych źródeł i bibliotek API, opracowywaniu i udostępnianiu adekwatnych do projektów źródeł typu „know how”.

Rysunek 9 Spirala badań interwencyjnych

Przepływ pracy – identyfikacja wymagań dla ontologii

Podstawy teoretyczne na temat przepływu pracy – identyfikacja wymagań dla ontologii wynikają ze specyfikacji metody UPON[4]. Natomiast poniższa specyfikacja koncentruje się nad uwzględnieniem wymagań wobec metody OB4RE.

Rysunek 10 Przepływ pracy celem identyfikacji wymagań dla ontologii

Koordynacja procesów

Podejście iteracyjno-przyrostowe wymaga zaplanowania i koordynacji. Specyfikacja metody OB4RE wskazuje na jednoczesną realizację jednego z zadań przepływu pracy dydaktyki, tj. świadomej dydaktyki oraz zadań dyscypliny wymagania. Powodzenie tej pracy może wymagać np. realizacji kilku iteracji w celu przekazania akceptowalnych efektów dydaktycznych do zadań poświęconych wymaganiom wobec ontologii. Owa akceptacja opatrzona jest warunkiem możliwości określenia dziedziny zainteresowania i jej zakresu. Charakteryzowane wcześniej zainteresowanie ogólnie rozumianymi usługami sieciowymi SaaS, wymagałoby ograniczenia zakresu do np. konkretnej funkcjonalności udostępnianej na urządzenia mobilne z systemem Android. Zorganizowanie tej pracy jest niezbędne, również ze względu na samą perspektywę czasu, gdyż realizacja zadania dydaktycznego pt. podejmowanie świadomych działań może trwać od kilku tygodniu do kilku miesięcy. Istotne są tu podzadania:

1. Określenie warunków akceptacji wykorzystania efektów dydaktycznych w dyscyplinie wymagań.

2. Uzgodnienie harmonogramu kooperacji przepływów pracy dyscyplin dydaktyki i wymagań w tym zazębianie się iteracji i wykorzystania kolejnych przyrostów.

3. Zarządzania zmianami.

Określenie dziedziny zainteresowania i zakresu

Teoretyczne podstawy określenia dziedzin zainteresowań i zakresu wyjaśnione w UPON[4] należy odnieść do metody OB4RE. Dlatego ogólne rozumienie w pierwszym pytaniu tj. fragmentu rzeczywistości, dotyczy de facto sprecyzowanej dziedziny dydaktycznej na przedmiotach informatycznych (np. interfejsu/ API Google dla urządzeń z systemem Android). Natomiast zobowiązanie ontologiczne, o którym mowa w kolejnym pytaniu wspierającym, pomimo że jest zawsze związane z celem metody, tj. ujawniania wymagań, wymaga każdorazowo uzgodnienia. Bowiem ten fragment rzeczywistości, nawet w tak wydawałoby się jednoznacznej dziedzinie, może się diametralnie różnić. Po pierwsze interesująca wybraną dziedzina – architektura, może dotyczyć zupełnie innych kategorii wymagań, które za pośrednictwem tej wybranej dziedziny będą ujawniane. Co oznacza, że zobowiązanie ontologiczne może chociażby w wymienianym przykładzie usług sieciowych dotyczyć czegoś innego. W jednym przypadku dotyczyć może wiedzy na temat środowiska uruchomienia interesującej funkcjonalności, a więc pozwalać na ujawnianie wymagań systemowych. Natomiast w innym przypadku - specyfikacji interfejsu w architekturze usług www REST i de facto ujawniać wymagania funkcjonalne wybranego usługodawcy usług sieciowych.

Zdefiniowanie celu biznesowego

Zdefiniowanie celu biznesowego, w stosunku do nieograniczonego postrzegania celu biznesowego w podstawach teoretycznych, odnosi się w OB4RE do celów wynikających z realizacji zajęć dydaktycznych wśród których kluczowe dotyczą celów użytkowników ontologii. Dlatego należy zaznaczyć, że najczęstszymi użytkownikami są nauczyciele oraz studenci podejmujący się roli analityków w projektach systemów informatycznych zarządzania. W rezultacie cele biznesowe, wynikają niejako z uzgodnień z wymienionymi użytkownikami. Niemniej jednak, na podstawie podstaw teoretycznych[4], istotne jest uzgodnienie powodu posiadania ontologii oraz jej zamierzonego zastosowania.

1. Powodem posiadania ontologii jest zaspokojenie potrzeb dydaktycznych, zawężonych do wypracowanej dziedziny i zakresu w poprzednim kroku przepływu wymagań.

2. Natomiast zamierzone zastosowanie ontologii, wynika niejako z odgórnych wytycznych metody tj. ujawniania wymagań w projektach systemów informatycznych zarządzania realizowanych przez studentów przedmiotów informatycznych.

Napisanie historii użytkowników

Historia użytkownika, pomimo że odnosi się do różnych użytkowników i może dotyczyć niezliczonych dziedzin, to na pewnym poziomie ogólności w każdym z projektów jest analogiczna. Względem ogólnych praktyk dotyczących wytwarzania oprogramowania w sposób zwinny,, a powszechnie identyfikowanych ze SCRUM[5], przyjmuje się tu następujący szablon historii użytkownika. Mianowicie:

Jako <analityk/ nauczyciel> chcę korzystać z ontologii <dziedzina>, żeby móc ujawniać te wymagania <kategoria wymagań>, które wynikają z przypadku użycia <nazwa>.

Stworzenie leksykonu aplikacji

Podstawy teoretyczne zwracają uwagę na niebagatelny wpływ procesu dydaktycznego na budowę leksykonu aplikacji. Zarówno terminologia wynikająca ze specyficznej dziedziny, jak i dokumenty dotyczące zastosowania aplikacji, pozwalają „wydobyć” terminologię podczas analizy historii użytkowników.

Dodatkowo istotne są praktyki[6] związane z wykorzystaniem standardów międzynarodowych ISO, W3C/ SKOS, FIBO/ FND, OMG. Stworzenie leksykonu aplikacji na podobieństwo innych zadań dotyczących nomenklatury w projektach wytwarzania ontologii (leksykon domenowy, leksykon referencyjny, szczególnie - słownik referencyjny), może zostać uregulowane względem adekwatnych międzynarodowych wytycznych. Projekty współdzielone, a szczególnie te międzynarodowe projekty - powinny uwzględniać standardy wyszczególnione przez Tabela 1.

Tabela 1 Definicje i źródła terminologii

Identyfikacja pytań kompetencyjnych

Jednym z głównych skutków metody OB4RE jest uspójnienie procesu dydaktycznego z dyscypliną wymagań. Co zasadniczo przyczynia się do sprecyzowania czynności pt. Identyfikacja pytań kompetencyjnych. W związku z czym, identyfikacja pytań kompetencyjnych opiera się głównie na wnioskach nauczyciela wyniesionych jeszcze z przepływu dydaktyki. Zważywszy na scharakteryzowany profil użytkowników ontologii i roli analityka w projekcie, można się spodziewać pytań kompetencyjnych wspierających pozyskiwanie wymagań, dla przykładu dotyczących m.in. wykorzystania usług sieciowych w projektach systemów informatycznych zarządzania. Takie podejście do identyfikacji pytań kompetencyjnych, znajduje również uzasadnienie w publikacji[3], gdzie znalazł się akapit nawiązujący ogólnie, do roli ontologa tj.: „Rola ontologa polega na aktywnym uczestnictwie w procesie gromadzenia wymagań, upewnieniu się, że autorzy przypadków zawierają informacje potrzebne do zadawania pytań kompetencyjnych wraz z przykładowymi odpowiedziami, aby zapewnić dobre zrozumienie”. Wobec tego, pytanie kompetencyjne mogłoby opierać na pewnym szablonie wynikającym ze specyfiki zastosowania metody OB4RE, tj.:

Jakie wymagania <kategoria wymagań> należy uwzględnić w specyfikacji przypadku użycia <nazwa przypadku użycia>?

Identyfikacja i priorytetyzacja przypadków użycia

Czynność identyfikacji i priorytetytyzacja przypadków użycia w metodzie OB4RE wymaga wyjaśnienia. W istotnych pracach[4], [6] poświęconych wykorzystaniu przypadków użycia podczas wytwarzania ontologii, autorzy podkreślają pozytywne znaczenie przypadków użycia. Dlatego, że przypadki użycia wraz z ich specyfikacją zapewniają znakomicie kontekst dla ontologii, z którego wynika zasadniczo, jak ta ontologia będzie wykorzystywana w ramach funkcjonalności oferowanej przez przypadki użycia.

W metodzie OB4RE rozróżnia się dwojakie zastosowanie przypadków użycia. Pierwsze standardowe znaczenie dotyczy niezmiennie specyfikacji funkcjonalnej projektowanego systemu. Dla przykładu, studenci wcielający się w rolę analityków systemów informatycznych zarządzania, specyfikują w ten sposób jeden z artefaktów analitycznych definiowany w bibliotece i frameworku OpenUP[7]. Kontynuując temat wykorzystania usług sieciowych w aplikacjach, przypadki użycia pozwoliłyby na specyfikację funkcjonalną przedstawioną przez Rysunek 7. Wynika z niej między innymi, że wywołanie usługi sieciowej zawiera się w przypadku nadrzędnym projektowanej aplikacji. Specyfikacja tych przypadków o podstawowym znaczeniu, ma kluczowe znaczenie w metodzie OB4RE, pozwala bowiem zrozumieć zarówno studentom, jak i nauczycielowi - co jest przedmiotem pracy analitycznej, projektowej i developerskiej.

Natomiast drugie znaczenie zastosowania przypadków użycia, należy identyfikować wprost z dwoma specyficznymi przypadkami użycia prezentowanymi przez Rysunek 11, tj.: Uzupełnij wiedzę oraz Ujawnij wymagania.

Rysunek 11 Przypadki użycia metody OB4RE

Przypadki prezentowane przez Rysunek 11 nawiązują zasadniczo do potrzeb użytkownika ontologii. Zarówno przypadek „Uzupełnij wiedzę”, jak i „Ujawnij wymagania” dotyczy wykorzystania ontologii, która powstała w wyniku zastosowania metody OB4RE.

Reasumując, zadanie opisywane w niniejszym punkcie dąży zasadniczo do zidentyfikowania tych przypadków użycia o podstawowym znaczeniu, które de facto zasilają wiedzę w przypadku o drugim znaczeniu tj. „Uzupełnij wiedzę”. Przypadek „Ujawnij wymagania” pozwoli bowiem docelowo ujawniać wymagania dla przypadków zidentyfikowanych w niniejszym zadaniu.

Weryfikacja AL, CQ, UC

Weryfikacja leksykonu aplikacji, pytań kompetencyjnych oraz przypadków użycia pozostaje zgodna co do podstaw teoretycznych UPON[4]. Należy przy tym uwzględnić specyfikację przepływu pracy – identyfikacja wymagań dla ontologii, z której zasadniczo wynika, że w sytuacji stwierdzenia nieprawidłowości przepływ należy powtórzyć. Ten punt decyzyjny, jakim jest weryfikacja, oddaje również i sam charakter iteracyjno-przyrostowy wskazujący na ewolucję pracy, w tym aktualizowanie artefaktów projektowych względem różnych potrzeb (tu dla przykładu, poprawy wynikającej z wykrytych nieprawidłowości w samej weryfikacji).

Przepływ pracy - analiza wymagań dla ontologii

Poniższa specyfikacja przepływu pracy – analiza wymagań dla ontologii, koncentruje się wyłącznie na specyfice metody OB4RE.

Rysunek 13 Przepływ pracy – analiza wymagań dla ontologii

Pozyskiwanie zasobów domenowych i budowanie leksykonu domenowego

Zadanie to, pomimo ewentualnych wielu scenariuszy, w metodzie OB4RE dotyczy zasadniczo źródeł internetowych. Dynamiczny charakter ewolucji istotnej tu wiedzy, obliguje de facto producentów i usługodawców do publikacji przede wszystkim za pośrednictwem Internetu. Dlatego pozyskiwanie zasobów domenowych i budowanie leksykonu domenowego opierają się głównie na adresach internetowych i wiedzy publikowanej w zasobach www. Dla przykładu, przytaczane wcześniej zainteresowanie usługami sieciowymi, dotyczyłoby publikacji on-line udostępnianych przez koncern Alphabet[8].

Budowanie leksykonu referencyjnego

Budowanie leksykonu referencyjnego w metodzie OB4RE, nie wymaga zmian w stosunku do podstaw teoretycznych metody UPON. Natomiast powszechne oprogramowanie biurowe, które może być z powodzeniem wykorzystane w przepływie pracy analiza wymagań dla ontologii, może tym samym wesprzeć budowę leksykonu referencyjnego. Szablon prezentowany przez Tabela 2, wskazuje, że leksykon referencyjny powstaje w wyniku ustalenia leksykonu aplikacji (LA) i leksykonu dziedzinowego (LD). Uzgodnienie terminów wspólnych LA, LD, pozwoli w dalszej części stworzyć słownik referencyjny.

Tabela 2 Szablon budowy leksykonu referencyjnego

Specyfikowanie przypadków użycia z wykorzystaniem UML

Z perspektywy praktycznej, czynność specyfikacji przypadków użycia z wykorzystaniem UML, powinna zostać realizowana w tym samym narzędziu, które znajdzie zastosowanie w przepływie pracy – projektowanie.

Przy czym, podstawy teoretyczne, pozostawiają swego rodzaju swobodę w realizacji tej pracy. Należy tu również zauważyć, że twórcy UML’a (Grady Booch, James Rumbaugh, Ivar Jacobson) przewidzieli w przewodniku użytkownika[9], że specyfikacja przypadków użycia może odbywać się również poprzez scenariusze tekstowe a to zostało zaadaptowane w wielu metodykach (np. OpenUP). Tego rodzaju decyzje wynikają de facto z uzgodnień projektowych i potrzeb jego członków. W metodyce OB4RE dokonano modyfikacji szablonu specyfikacji przypadku użycia OpenUP. Uwzględniono w tym celu praktyki ontologów zawarte w szablonie przypadków użycia[3]. Poniższy szablon został wypracowany w ramach opisywanej metody.

Tabela 3 Szablon przypadku użycia

Budowanie słownika referencyjnego

Budowanie słownika referencyjnego, poświęcone jest stworzeniu definicji dla terminów wspólnych dla leksykonu aplikacji i leksykonu domenowego. Względem podstaw teoretycznych, istotne jest uwzględnienie dodatkowo w tej pracy norm międzynarodowych wyszczególnionych w Tabela 1. Z perspektywy zainteresowania dziedzinami przedmiotów informatycznych, na pracę będą miały wpływ międzynarodowe rozwiązania informatyczne i pojęcia propagowane w ten sposób za pośrednictwem różnych platform internetowych. Dla przykładu, w branży projektów systemów informatycznych zarządzania, przyjęło się pojęcie tzw. leadów, które w konsekwencji przełożyło się na implementacje adekwatnej funkcjonalności w oprogramowaniu klasy CRM. Co w rezultacie, względem wymienianych przykładów SaaS, doprowadziło do udostępnienia w API Bitrix24 adekwatnych usług w architekturze REST.

Weryfikacja RG

Weryfikacja słownika referencyjnego jest ostatnim zadaniem w fazie analizy. Istota tego zadania wynika z potrzeby wykluczenia ewentualnych pojęć błędnych w przepływie – projektowania. Podstawy teoretyczne pozostają bez zmian, przy czym nie bez znaczenia jest swego rodzaju pragmatyka towarzysząca realizacji tej pracy. Dlatego w sytuacji stwierdzenia błędów w słowniku referencyjnym, zalecany jest powrót do wcześniejszego przepływu – wymagania, gdzie według podstawowych zaleceń UPON, należy rozpocząć przegląd i ewentualne zmiany od zadania pt. tworzenie leksykonu aplikacji. W konsekwencji czego, znaczenia nabiera same repozytorium projektu i zagadnienia np. wersjonowanie poszczególnych artefaktów projektowych. Niemniej jednak, warto podczas weryfikacji słownika referencyjnego, sprawdzić podstawowe kwestie, takie jak:

1. Czy słownik referencyjny jest kompletny, tj. czy wszystkie z pojęć w leksykonie referencyjnym, zostały zdefiniowane w słowniku referencyjnym ?

2. Czy pojęcia w słowniku referencyjnym spełniają respektowane normy międzynarodowe, wyszczególnione w Tabela 1, począwszy od samej definicji pojęcia tj. „Jednostka wiedzy stworzona przez unikalną kombinację cech” ISO 1087-1:2000

Przepływ pracy – projektowanie ontologii

Podstawy teoretyczne na temat przepływu pracy – projektowanie ontologii wynikają ze specyfikacji metody UPON[4]. Poniższa specyfikacja koncentruje się wyłącznie na potrzebnych zmianach wprowadzonych przez metodę OB4RE.

Rysunek 14 Przepływ pracy – projektowanie ontologii

Modelowanie koncepcji

Modelowanie koncepcji w opisywanej metodzie bazuje na UOP. Profil OUP został opisany w ramach międzynarodowej specyfikacji ODM[10]. Przy czym, z perspektywy użytkownika nie mniej istotne jest samo oprogramowanie, które de facto pozwala modelować koncepcje ontologiczne w wymienionych standardach. Dlatego też, tak istotne było zaadaptowanie oprogramowania pozwalającego na realizację metody OB4RE. Wśród dostępnych na zasadzie Open Source rozwiązań, kluczowa okazała się implementacja w tym wybranym oprogramowaniu konkretnych bibliotek tzw. TwoUse opisanych w publikacji wydawnictwa IEEE Press i poświęconych scaleniu Semantic Web i Model-Driven Engineering[11], a znanych właśnie pod nazwą „The TwoUse Approach”. Jedynym oprogramowaniem dostępnym na zasadach Open Source i spełniającym te uwarunkowania w czasie pisania pracy naukowej - był Eclipse z rozszerzeniem poświęconym tworzeniu ontologii tj. UniversAAL platform. O samej implementacji podejścia TwoUse można znaleźć informacje na stronach github’a poświęconych platformie UniversAAl[12]. Pośród tych stron znajdują się również instrukcje dotyczące używania rozszerzenia Eclipse[13].

Modelowanie koncepcji ontologicznych w scharakteryzowanym oprogramowaniu, z perspektywy użytkownika dotyczy pojęć udostępnionych w tzw. toolbox UniversAAL platfom. Należy dodać, że domyślnie UniversAAl udostępnia projektantowi tzw. kluczowe koncepcje ontologiczne, które względem ewentualnych i specyficznych potrzeb można rozszerzyć. Pomimo pozostawienia koncepcji w zgodzie z Tabela 4, warto jednak tu zauważyć docelowe ujawnianie wymagań. Także projektanci ontologii, zważając na np. ODRE, będą projektowali z wykorzystaniem UOP, pożądane koncepcje ontologiczne.

Tabela 4 Modelowanie koncepcji ontologicznych w oprogramowaniu UniversAAL

Modelowanie hierarchii i relacji dla koncepcji

Modelowanie hierarchii i relacji, dotyczy domyślnie w przyjętym środowisku - specyfikowania asocjacji i generalizacji pomiędzy koncepcjami ontologicznymi. Przedstawienie tych relacji pomiędzy koncepcjami, jest kluczowe względem celu wykorzystania metody OB4RE. Ujawnienia wymagań jest możliwe de facto, właśnie na podstawie modelu ontologii zawierającego te relacje pomiędzy koncepcjami ontologicznymi. Tabela 5 prezentuje definicje asocjacji i generalizacji zawarte w dokumentacji UniversAAL platform.

Tabela 5 Modelowanie hierarchii w oprogramowaniu UniversAAL [11], [12], [13],[14]

Weryfikacja projektu

Weryfikacja projektu obejmuje podstawowe kwestie, ale mające wpływ na implementację ontologii. Opisywana metoda bazuje na funkcjonalności oprogramowania UniversAAL platform. W konsekwencji użycia funkcjonalności weryfikacji otrzymywany jest raport z weryfikacji projektu ontologii, z którego wynika czy ontologia nie zawiera następujących błędów:

1. Brakujących nazw (klas i właściwości)

2. Duplikujących się nazw (klas i właściwości)

3. Okrężnej generalizacji

4. Klas bez bezpośredniego lub pośredniego powiązania z klasą ontologii wyższego poziomu

5. Brakujących właściwości klas

6. Wielokrotności generalizacji

Należy nadmienić, że pozostałe aspekty weryfikacji jak np. spójność ontologii, będą weryfikowane w późniejszym etapie projektu (spójność na podstawie zakodowanej ontologii).

Przepływ pracy – implementacja ontologii

Podstawy teoretyczne na temat przepływu pracy – implementacja wynikają ze specyfikacji metody UPON[4]. Poniższa specyfikacja koncentruje się wyłącznie na wyjaśnieniu czynności składowych tego procesu.

Rysunek 15 Przepływ pracy – implementacja ontologii

Wybór języka formalnego

Wybór języka formalnego, tj. OWL, w opisywanej metodzie jest skutkiem zaadaptowania w metodzie warsztatu metodyczno-narzędziowego kompatybilnego z MDE. Innymi słowy, uzasadnia się wybór języka względem jego obecności w wybranym środowisku projektowo-developerskim. Podstawową i kluczową rolę odgrywają tu rozwiązania organizacji standaryzujących tj. W3C i OMG. Natomiast z perspektywy użytecznej istotna była fundacja Eclipse, która stworzyła oprogramowanie otwarte na pluginy tzn. Papyrus i UniversAAL. Samo uzasadnienie wyboru języka OWL powiązane jest również z docelowym wykorzystaniem jednej z usług ontologicznych tj. wnioskowania. Dlatego, że ontologia zakodowana w OWL zostanie docelowo wykorzystana do ujawniania wymagań. Do czego wykorzystano oprogramowanie Pellet, które notabene stanowi plugin do oprogramowania wyszczególnionego w przepływie wdrożenia tj. Protege.

Sformalizowanie ontologii

Sformalizowanie ontologii w opisywanej metodzie, jest wynikiem transformacji UML do JAVA, następnie JAVA do OWL. Co nie byłoby możliwe bez ODM i wzajemnie kompatybilnych standardów OMG i W3C. Wykorzystano w pracy możliwości wynikające z architektury MDA (Model Driven Architecture), w tym właściwe dla tej architektury metamodele oparte o MOF (Meta Object Facility)[15]. Funkcjonalność ta dostępna jest w oprogramowaniu UniversAAL i stanowi rezultat implementacji w oprogramowaniu podejścia TwoUse[11]. O samym podejściu TwoUse, scharakteryzowanym w poniższych czynnościach transformacji, w literaturze pisze się następująco „TwoUse Approach integruje uznane praktyki współczesnych projektantów oprogramowania z najnowszą technologią rozumowania nad dużymi i złożonymi modelami tj. technologią ontologiczną”[16]. Niemniej jednak zasadniczą korzyścią wykorzystywanego oprogramowania jest częściowe automatyzowanie pracy nad implementacją.

Sformalizowanie ontologii w platformie UniversAAL jest osiągane poprzez realizację dwóch poniżej scharakteryzowanych kroków.

1. Transformacja UML do JAVA

W rezultacie transformacji UML do JAVA, generowane są pliki .java o następującym przeznaczeniu oraz strukturze.

Activator.java

Klasa activator udostępnia i pozwala zarządzać ontologią w systemie. Poza wskazaniem samej nazwy ontologii, dostarcza metod zarządzania ontologią. Mianowicie: rejestrowanie i wyrejestrowanie ontologii, pozyskanie URIs wszystkich lub wybranych ontologii.

Listing 1 Klasa Activator

Factory.java

Wygenerowanie koncepcji ontologicznych wymaga utworzenia pliku Factory.java. Strukturę factory.java prezentuje poniższy szablon kodu źródłowego JAVA.

Listing 2 Klasa MyFactor

Ontology.java

Plik ontology dostarcza metody do tworzenia RDFClassInfo i OWLClassInfo które będą przechowywać informacje o modelu (odpowiednio klasy RDF (Resource Description Framework) i klasy OWL). W celu utworzenia klas, plik ontologii dostarcza metody, prezentowane również przez Rysunek 16.

Rysunek 16 Struktura rdf

nazwaKlasy.java

Klasy Java odpowiadają pośrednio za implementację klas OWL. Poniższa struktura szablonu kodu źródłowego Java, wskazuje przy tym, że koncepcje ontologiczne będą podklasami ManageIndividual. Klasa ta zapewnia zgodność ze środowiskiem UniversAAL, zintegrowanego z wytwarzaniem oprogramowania. Klasa ManageIndividual pojawia się wcześniej w opisywanej metodzie tj. jeszcze podczas modelowania koncepcji ontologicznych w przepływie projektowania.

W rezultacie, każda podklasa ManagedIndividual musi nadpisać metodę getClassURI(), która zwraca URI tej klasy ontologicznej (zazwyczaj ten URI jest również zdefiniowany jako statyczny, string w klasie Java dla łatwego odwoływania się)

Listing 3 Klasa MyClass rozszerza klasę ManagedIndividual

2. Transformacja JAVA do OWL

Transformacja klas Java do OWL, odbywa się z wykorzystaniem interfejsu Eclipse – UniversAAL. W rezultacie wcześniej wykonanej transformacji UML do Java, w jednym z pakietów tj. creator, powstaje klasa o nazwie creator.java. Poniżej zamieszczono przykładowy kod źródłowy klasy creator.

Listing 4 Kod źródłowy klasy Creator

Natomiast z perspektywy użytkownika interfejsu Eclipse – UniversAAL kluczowe jest samo uruchomienie klasy creator.java. W rezultacie czego, generowany jest plik z rozszerzeniem owl. Przykładowy plik owl, powstały w wyniku transformacji Java do OWL, prezentuje poniższy wydruk. Poniższy plik OWL jest rezultatem uruchomienia powyżej prezentowanego pliku creator.java.

Listing 5 Kod pliku owl

Przepływ pracy – testowanie ontologii

Podstawy teoretyczne na temat przepływu pracy – testowanie ontologii wynikają ze specyfikacji metody UPON[4]. Poniższa specyfikacja koncentruje się na wyjaśnieniu czynności składowych tego procesu w rozumieniu odpowiedzialności metody OB4RE.

Rysunek 17 Przepływ pracy – testowanie ontologii

Sprawdzanie spójności

Sprawdzanie spójności, z perspektywy użytkownika opisywanej metody, dotyczy de facto wykorzystania funkcjonalności poświęconej wnioskowaniu. W niniejszej pracy, powołując się na zalecenia w samej źródłowej pracy dotyczącej UPON [4], wykorzystano w tym celu tzw. Pellet (OWL-DL reasoner). Oprogramowanie to stanowi plug-in do Protege, i poza sprawdzaniem spójności, oferuje znacznie więcej usług jak np. spełnialność pojęć, klasyfikację, realizację[2]. Zastosowanie Pellet w metodzie wymagało zaimportowania zakodowanej ontologii w poprzednim przepływie implementacji do Protege.

Poza opisanymi podstawami teoretycznymi w rozdziale 1, należy zauważyć, iż w literaturze przedmiotu podkreśla się fakt kompletności Pellet jako oprogramowania sprawdzającego OWL-DL. Formalna definicja poświęcona temu, jak Pellet sprawdza spójność zamieszczona jest bezpośrednio na stronie organizacji W3C [17]. Ujmując jednak ogólnie tą funkcjonalność, istotne jest aby Pellet sprawdził, czy ABox respektuje TBox.

Tabela 6 Znaczenie terminów wykorzystywanych w sprawdzania spójności ontologii

Weryfikacja pokrycia & odpowiadanie na pytania kompetencyjne

Czynność weryfikacji pokrycia, pozwala przetestować możliwość udzielenia odpowiedzi na pytania kompetencyjne zdefiniowane jeszcze w przepływie pracy – identyfikacja wymagań dla ontologii, tzn.:

Jakie wymagania <kategoria wymagań> należy uwzględnić w specyfikacji przypadku użycia <nazwa przypadku użycia>?

Wobec powyższego, realizacja tej pracy wymaga zarówno bazy wiedzy jak i kompetencji użytkownika metody. Pozwalających w rezultacie podjąć decyzję, czy dopuścić rezultaty dotychczasowej pracy do kolejnego przepływu pracy – wdrożenie. Z perspektywy praktycznej znaczenie ma również charakter prac, tj. iteracyjno-przyrostowy. Co wymagało weryfikowania pokrycia i odpowiadania na pytania kompetencyjne po każdej z iteracji.

Przepływ pracy – wdrożenie ontologii

Specyfikacja przepływu pracy – wdrożenie ontologii, bazuje na założeniach teoretycznych opisanych w rozdziałach wcześniejszych. Dlatego też, zadania specyfikowane w przepływie pracy wdrożenie ontologii koncentrują się stricte nad zaspokojeniem potrzeb projektów realizowanych na zajęciach. Wspomagając tym samym pracę nauczyciela i studentów.

Rysunek 18 Przepływ pracy – wdrożenie ontologii

Opracowanie wytycznych zastosowania ontologii

Opracowanie wytycznych zastosowania ontologii, w świetle całej metody OB4RE, wydaje się kluczowe dla osiągnięcia jej celu. Dlatego, że ujawnianie wymagań, którego ta metoda dotyczy, nie mogłoby spotkać się z uznaniem, gdyby nie została uwzględniona specyfika projektu wykorzystującego te wymagania. Przy czym istotne są zależności wynikające z tzw. warstw inżynierii oprogramowania wymienianych przez Pressmana[18], czy też samego autora metody OB4RE[19]. Z czego m.in. wynika, że np. proces wytwórczy zależy od dbania o jakość, a ta z kolei od samej filozofii zarządzania. Co ma niebagatelne znaczenie właśnie podczas opracowania wytycznych zastosowania ontologii. Dlatego kluczowe jest ustalenie odpowiedzi na pytania:

1. Jaka jest specyfika projektu informatycznego? Przede wszystkim, jaki jest proces wytwórczy i jakie obowiązują artefakty projektowe? (nawet jeżeli to jest projekt Agile)

2. Jaki jest harmonogram prac, w tym jakie są terminy dla poszczególnych zadań?

3. Kto odpowiada za ujawnianie wymagań w projekcie i jakie są kompetencje użytkownika metody?

Należy tu jeszcze dodać, że równie istotne są swego rodzaju ramy wytypowane jeszcze podczas przepływu pracy – dydaktyka. Realizowane tam badania interwencyjne w dydaktyce, pozwalają bowiem w ostatnim z kroków podjąć świadome działania w dydaktyce. Co w rzeczywistości pozwala uwzględnić zdefiniowane potrzeby dydaktyczne i dostosować pracę dydaktyczną do specyfiki projektowej. Pozwala to m.in. skupić się na dydaktyce osób odpowiedzialnych za wymagania projektowe. De facto zaadaptować w tej pracy analitycznej ontologię i usługę wnioskowania.

Ujawnianie wymagań

Ujawnianie wymagań w metodzie OB4RE bazuje na usłudze ontologicznej – wnioskowania. Wykorzystano w tym celu oprogramowanie Protege, wraz z pluginem Pellet, które oferuje syntaktykę tzw. Manchaster OWL opisaną m.in. w dokumentacji oprogramowania Protege[21]. Poniższa Tabela 7 wyszczególnia same konstruktory stosowanej syntaktyki, poprzez wykorzystanie których budowane są pytania pozwalające na ujawnianie wymagań. Pełna specyfikacja syntaktyki Manchester znajduje się na stronach organizacji W3C [20].

Tabela 6 Składnia wyrażeń klasowych w syntaktyce Manchester

Wykorzystanie wymagań w procesie wytwarzania oprogramowania

Zarządzanie wymaganiami, w tym ujawnianie wymagań, zależy m.in. od wybranego procesu wytwórczego, specyfiki konkretnego projektu i ostatecznych decyzji zarządczych. Dla przykładu, wg. OpenUP czy też SCRUM, wymagania postrzega się z perspektywy przyszłego użytkownika i podporządkowuje kolejno: przypadkom użycia oraz historiom użytkownika. Jednocześnie zwracając uwagę kierowników projektów na istotę zarządzania zmianami projektowymi podyktowanymi często modyfikacjami wymagań projektowych. Dlatego ostateczne decyzje poświęcone wykorzystaniu wymagań w procesie wytwarzania oprogramowania – powinny należeć do decydentów projektowych.

Niemniej jednak, należy zwrócić uwagę, że zakłada się w metodzie OB4RE możliwie elastyczny stosunek względem samego procesu produkcji oprogramowania. Tym bardziej, że rezultaty jej wykorzystania z tej perspektywy produkcji oprogramowania są osadzone w procesie inżynierii wymagań jeszcze na etapie tzw. wczesnej inżynierii wymagań (Early Requirements Engineering). Poniższy Rysunek 19 obrazuje jednak tę koncepcje w najbliższym, z perspektywy literatury przedmiotu, otoczeniu, tj. Ontology Driven Requirements Engineering. Rozszerzając tym samym model ogólny pracy poświęconej OntoReq(Ontology Requirements)[22] o odpowiedzialność metody OB4RE tj. wytwarzanie ontologii dziedzinowych i ujawnianie wymagań.

Rysunek 19 Wykorzystanie OB4RE w inżynierii wymagań

Reasumując wyszczególnia się w ramach metody OB4RE zagadnienia:

- Wytwarzanie ontologii,

- Ujawnianie wymagań,

Natomiast w ramach OntoReq:

- Analizę wymagań,

- Specyfikację wymagań,

- Walidację wymagań.

Bibliografia

[1] Tuft B., Eclipse Process Framework (EPF) Composer. Installation, Introduction, Tutorial and Manual, Eclipse Public License v1.0 2010.

[2] Sagor R., Guiding school improvement with action research, ASCD, Association for Supervision and Curriculum Development, Alexandria, USA 2000.

[3] J. Czekaj, Podstawy zarządzania informacją, Wydawnictwo Uniwersytetu Ekonomicznego w Krakowie, Kraków 2012.

[4] A. De Nicola, M. Missikoff, and R. Navigli, A Proposal for a Unified Process for Ontology Building: UPON, „Database and Expert Systems Applications, 16th International Conference, DEXA 2005”, Copenhagen 2005.

[5] K. Schwaber and J. Sutherland, Przewodnik po Scrumie, Ken Schwaber and Jeff Sutherland 2020, Listopad 2.

[6] Kendall E.F., and McGuinness D.L., Ontology Engineering, Morgan and Claypool 2019.

[7] Eclipse, Biblioteka OpenUP, 2012, https://download.eclipse.org/technology/epf/OpenUP/published/openup_published_1.5.1.5_20121212/openup/index.htm, 24.09.2020.

[8] Google, Wprowadzenie do usług sieciowych Google Play, 2021, https://developers.google.com/android/guides/overview.

[9] G. Booch, J. Rumbaugh, and I. Jacobson, UML przewodnik użytkownika, WNT 2001.

[10] OMG, Metamodel definicji ontologii, 2014, https://www.omg.org/spec/ODM/1.1/PDF

[11] F.S. Parreiras, Semantic Web and Model Driven Engineering, John Wiley&Sons, Inc.; Institute of Electrical and Electronics Engineers IEEE, New Jersey 2012.

[12] C. Stocklöw, Modelowanie ontologii w UniversAAL, 2018, https://github.com/universAAL/tools.eclipse-plugins/wiki/Ontology-modelling.

[13] C. Stocklöw, Ontologie na platformie universaal, 2018, https://github.com/universAAL/platform/wiki/Ontologies-%28Quick%29.

[14] C. Stocklöw, Reprezentowanie danych w UniversAAL, 2018, https://github.com/universAAL/middleware/wiki/Data-Representation#OWL_classes.

[15] OMG, Meta Object Facility MOF Core Specification, 2006.

[16] Pan, Staab, Aßmann, Ebert, and Zhao, Ontology-Driven Software Development, Springer-Verlag Berlin Heidelberg 2013.

[17] W3C, OWL 2 (Web Ontology Language), wydanie 2, 2012, https://www.w3.org/TR/owl2-overview/.

[18] Pressman R.S., Praktyczne podejście do inżynierii oprogramowania, Wydawnictwa Naukowo-Techniczne Warszawa 2004.

[19] A. Machura, Reconciling the Expectations of Ontology Engineering to the Process of Requirements Elicitation, „BIR 2019. 18th International Conference on Perspectives in Business Informatics Research”, CEUR-WS 2019.

[20] W3C, OWL 2 Syntaktyka Manchester (wydanie 2), 2012, https://www.w3.org/TR/owl2-manchester-syntax/.

[21] Dokumentacja Protege 5, 2012, http://protegeproject.github.io/protege/class-expression-syntax/.

[22] Siegemund K., Contributions To Ontology-Driven Requirements Engineering, Technischen Universität Dresden 2014.

Page updated

Google Sites

Report abuse