• Nie Znaleziono Wyników

Etapy budowy ontologii wspomagających dobór i ocenę COTS

4. ONTOLOGIE WSPOMAGAJĄCE PROCES DOBORU I OCENY SKŁADNIKÓW OPROGRAMOWANIA COTS

4.2. Etapy budowy ontologii wspomagających dobór i ocenę COTS

Ontologia dla COTS ma za zadanie zapewnić dowolność w procesie definiowania wymagań, jednocześnie dostarczając systematyzacji wiedzy na temat składników COTS i dostępnych metodyk warunkujących ich skuteczną ocenę i dobór. Stąd, dla każdej z grup rozwiązań: metod i technik wspomagających dobór i ocenę COTS, narzędzi informatycznych, frameworków oraz składników COTS ERP zostały zbudowane oddzielne ontologie.

Użytkownik na wejściu definiuje określone preferencje, jakie powinno posiadać pożądane przez niego rozwiązanie. Następnie przy użyciu mechanizmu wnioskującego na wyjściu decydent dostaje zbiór wybranych rozwiązań w postaci metod i technik wspomagających dobór i ocenę COTS, narzędzi informatycznych, frameworków oraz składników COTS ERP, które spełniają uprzednio zdefiniowane preferencje. W dalszym etapie użytkownik, który poszukiwał składników, może dobrać określone rozwiązania wspomagające ich dalszą ocenę w postaci metod i technik wspomagających dobór i ocenę COTS, narzędzi informatycznych oraz frameworków. Im wyższy poziom szczegółowości, tym liczba uzyskanych rezultatów będzie mniejsza381.

381 Konys A., Wątróbski J., 2010 r., A model of ontology supporting COTS component selection process in management information system domain, Konferencja „Advanced Information Technologies for Management AITM’2010”, Wroclaw University of Economics Research Papers, ISSN 1899-3192, 2010.

100 Rys. 4.2. Etapy budowy ontologii wspomagających dobór i ocenę COTS. Źródło: Opracowanie własne.

Dla wszystkich grup rozwiązań: metod i technik wspomagających dobór i ocenę COTS, narzędzi informatycznych, frameworków oraz składników COTS ERP przyjęto jednakową procedurę budowy ontologii. Bazując na zidentyfikowanych charakterystykach poszczególnych rozwiązań określony został zbiór kryteriów stanowiący podstawę do budowy taksonomii, a następnie ontologii poszczególnych rozwiązań382. Zdefiniowane zostały również klasy (ang.

Defined classes) wraz z przypisaniem do nich odpowiednich warunków koniecznych i wystarczających (ang. necessary and sufficient conditions). Pozwala to (w oparciu o mechanizm wnioskujący) na wybór rozwiązań w sposób zgodny z preferencjami decydenta.

Poniższy schemat przedstawia ogólną procedurę budowy ontologii wspomagających dobór i ocenę COTS wraz z jej głównymi etapami.

382 Konys A., Ontologies supporting COTS software components selection and evaluation, Konferencja „Advanced Information Technologies for Management AITM’2011”, Wroclaw University of Economics Research Papers, 2011.

101 Rys. 4.3. Budowa ontologii wspomagających dobór i ocenę składników COTS. Źródło: Opracowanie własne.

Podstawę dla budowy każdej z ontologii stanowiła szczegółowa analiza dostępnych rozwiązań, a następnie konstrukcja zbioru kryteriów oraz podkryteriów. Na ich bazie dokonano budowy taksonomii. W przypadku ontologii metod i technik wspomagających dobór i ocenę składników COTS oraz narzędzi i frameworków informatycznych dla COTS, zbiór kryteriów został opracowany opierając się na dostępnych charakterystykach poszczególnych metodyk.

Z kolei w przypadku składników COTS informacje na temat poszczególnych rozwiązań pochodzą ze specjalistycznych raportów tworzonych przez niezależnych ekspertów. Bazując na tych informacjach wybrane zostały poszczególne cechy składników COTS, stanowiące podstawę budowy zbioru kryteriów383.

Zdefiniowany zbiór kryteriów stanowił podstawę do budowy taksonomii dla metod i technik wspomagających ocenę i dobór składników COTS, narzędzi wspomagających ocenę i dobór składników COTS, frameworków informatycznych wspomagających ocenę i dobór składników COTS, a także składników COTS ERP. Powstałe taksonomie stanowiły kolejno podstawę do budowy ontologii tych rozwiązań. Poszczególne ontologie były tworzone bazując na dostępnych informacjach dotyczących każdego z rozwiązań, dokonując w wybranych przypadkach uogólnienia nazw kryteriów w celu zmniejszenia ich łącznej liczby w projektowanej ontologii. Miało to na celu również poprawę szybkości obliczeń dokonywanych przez mechanizm wnioskujący.

Podczas procesu budowy ontologii przyjęto określony zbiór założeń. W celu zapewnienia poprawności działania projektowanych ontologii, dla każdej z projektowanych ontologii przyjęto ujednolicenie zapisu stosowanych nazw klas, własności obiektów oraz typów danych bez zastosowania polskich czcionek, spacji oraz znaków. Zastosowano również skróty dla bardziej rozbudowanych nazw, przy czym pełny zapis został zamieszczony w załączonych tabelach. Ponadto, nie stosowano powtórzeń w użytym nazewnictwie w przypadku nazw

383 Konys A., Ontologies supporting COTS software components selection and evaluation, Konferencja „Advanced Information Technologies for Management AITM’2011”, Wroclaw University of Economics Research Papers, 2011.

102 kryteriów w każdej z ontologii (dla większości zastosowano klasę Kryterium lub Kryteria). Dla każdej z klas pierwotnych oddzielono poszczególne indywidualności należące do danej klasy względem siebie (rozdzielenie klas względem siebie). Dla każdej z klas określono również atrybuty (ang. slots) oraz przypisano możliwe do przyjęcia wartości. Ponadto założono, że występuje dziedziczenie atrybutów z klas wyżej. Poszczególnym atrybutom określono typy wartości, a także dopuszczalne zbiory wartości, jakie mogą przyjmować, jak również sprecyzowano liczbę wystąpień. Ponadto, w każdej z budowanych ontologii dokonany został podział na ograniczenia egzystencjalne i uniwersalne w celu zdefiniowania charakterystyk poszczególnych składników COTS ERP, metod i technik, narzędzi oraz frameworków wspomagających dobór i ocenę COTS. Następnie dla każdej z budowanych ontologii utworzone zostały dwie hierarchie klas (ang. asserted and inferred hierarchy) – stanowiące odpowiednik hierarchii twierdzącej oraz wnioskującej. Pierwsza z nich – hierarchia twierdząca (ang. asserted hierarchy) jest tworzona przez projektującego ontologię bazując na uprzednio zdefiniowanych klasach podstawowych (ang. Primitive classes). Z kolei druga hierarchia (ang. inferred hierarchy) powstaje w wyniku zastosowania mechanizmu wnioskującego uwzględniając uprzednio określone klasy zdefiniowane (ang. Defined classes). Uruchomienie narzędzia Reasoner powoduje, że w efekcie użytkownik otrzymuje wyniki w postaci indywidualności przyporządkowanych do poszczególnych klas zdefiniowanych.

Dla każdej z utworzonych ontologii istnieje możliwość prezentacji graficznej zarówno całej ontologii, jak i jej poszczególnych fragmentów. Istnieje również możliwość zadawania konkretnych zapytań do danej ontologii wykorzystując w tym celu logikę opisową dostarczając tym samym konkretnej odpowiedzi na zadane przez użytkownika zapytanie. Możliwe jest uzyskanie przedstawienia graficznego zarówno w hierarchii twierdzącej jak i wnioskującej.

4.3. Ontologia metod i technik wspierających dobór i ocenę składników COTS