docRafał WOJSZCZYK - Modele Inżynierii Teleinformatyki
download 
Reklamacja Transkrypt
Rafał WOJSZCZYK - Modele Inżynierii Teleinformatyki
RAFAŁ WOJSZCZYK [email protected] Katedra Inżynierii Komputerowej Wydział Elektroniki i Informatyki Politechnika Koszalińska PORÓWNANIE SPOSOBÓW REPREZENTACJI WZORCÓW PROJEKTOWYCH Streszczenie: Celem publikacji jest porównanie sposobów reprezentacji wzorców projektowych, które będą umożliwiały ich dalsze analizowanie. W pracy krótko przedstawiono historię wzorców projektowych, zawierając w tym wkład C. Alexandra oraz Bandy Czterech. Wyjaśnione są rodzaje wzorców, cel ich stosowania oraz korzyści z tego wynikające. Przedstawione zostały różne sposoby reprezentacji wzorców projektowych, w tym oparte na grafach i ontologiach. Następnie zostały teoretycznie porównane względem siebie, wraz ze wskazaniem najlepszego sposobu reprezentacji do analizowania wzorców projektowych. Słowa kluczowe: wzorce projektowe, GoF, grafy etykietowane, ontologie 1. Wprowadzenie Obecnie różnego rodzaju wzorce mają bardzo szerokie zastosowanie w wielu nie powiązanych ze sobą dziedzinach, przez co nie powinno utożsamiać się terminu "wzorzec" wyłącznie z informatyką. Przykładowym wzorcem są frazy melodyjne lub wzorce akompaniamentów pianistycznych (z ang. Piano Patterns) w muzyce. Są to wzory pewnych melodii lub akompaniamentów, możliwych do powtórzenia w różnych tonacjach a do tego gwarantujące ich dobre współbrzmienie z tą tonacją. Zapewne w większości przypadków celem użycia tego słowa jest wskazanie idei powtarzającego się problemu i możliwości ponownego użycia rozwiązania do tegoż problemu. Panuje przekonanie, że wspomnianą ideę pierwszy nazwał wzorcem Christopher Alexander w latach siedemdziesiątych XX wieku. 134 Rafał Wojszczyk Christopher Alexander zdefiniował wzorzec słowami: "Każdy wzorzec opisuje pewien regularnie napotykany problem i łączy go z ogólnym opisem jego rozwiązania w sposób, który pozwala stosować to rozwiązanie miliony razy, ale za każdym razem nieco inaczej" [6]. Słowa te dotyczyły budownictwa, lecz są na tyle uniwersalne, że można przenieść ich znaczenie do wielu innych dziedzin, w tym też do programowania. Prace Alexandra skupiały się na definiowaniu i klasyfikacji wzorców. Zaproponował również nieformalny sposób opisu wzorców, składający się z wyjaśnienia kontekstu, problemu i rozwiązania. 2. Wzorce w oprogramowaniu Prace Alexandra wywarły bardzo duży wpływ na informatykę, szczególnie na programowanie. Sam Christopher Alexander miał swój osobisty wkład w tematyce wzorców w informatyce [1]. W samej informatyce za bardzo ważne dzieło uważana jest publikacja E. Gammy i innych "WZORCE PROJEKTOWE Elementy oprogramowania obiektowego wielokrotnego użytku" [7] (tytuł oryginału: "Design Patterns: Elements of Reusable Object-oriented Software"), autorzy nazywani są często Bandą Czterech. Mimo upływu 20 lat od wydania tej pozycji, wciąż jest ona uważana za pewien standard i omawiana przez innych: [10, 11, 12]. Autorom [7] przypisywanych jest wiele zasług za rozpowszechnianie i popularyzację wzorców. Jednakże nie są oni twórcami samych wzorców, czy też zasad stosowania wzorców w programowaniu obiektowym. Ich zasadniczym wkładem jest zebranie i opisanie 23 wzorców. 2.1. Podział wzorców Wieloznaczeniowy charakter słowa wzorzec ma taką wadę, że używając tego słowa, nawet w kontekście programowania, można łatwo wprowadzić rozmówców w błąd. Dlatego warto przedstawić podział [11], bazujący na różnych poziomach abstrakcji i wyjaśnić ich znaczenie: wzorce architektury są to strategie o wysokim poziomie abstrakcji, opisujące poziom integracji komponentów. Do tej grupy zaliczają się między innymi Model-View-Controler oraz Model-View-Presenter. wzorce projektowe obejmują mniejszy zakres niż wzorce architektury, dotyczą poziomu interakcji między klasami lecz wciąż są abstrakcyjne, ponad poziomem implementacji. Do tej grupy zaliczają się między innymi wzorce przedstawione w [7]. Porównanie sposobów reprezentacji wzorców projektowych 135 wzorce implementacyjne, nazywane również idiomami, są to konstrukcje programistyczne używane w konkretnym paradygmacie programowania, są na najniższym poziomie abstrakcji. Do tej grupy zaliczają się między innymi proste instrukcje jak: inkrementacja wartości stałoprzecinkowej, nieskończone pętle. 2.2. Czym jest wzorzec projektowy? Odpowiadając wprost na pytanie z tytułu tego podrozdziału, można powiedzieć, że wzorzec projektowy jest to opis rozwiązania pewnego problemu, który jest powtarzalny. Łatwość przy tym jest taka, że rozwiązanie nie musi być ponownie opracowywane oraz osoba korzystająca z takiego rozwiązania nie musi rozumieć wszystkich jego aspektów, a jedynie wiedzieć jak z niego skorzystać. Oprócz tego wzorce projektowe są w pewnym sensie językiem komunikacji pomiędzy programistami, umożliwiają dzielenie się wiedzą oraz sposobem na udokumentowanie projektu. Poprzez stosowanie odpowiednich nazw bądź adnotacji, każdy nowy programista znający wzorce projektowe, łatwiej zrozumie kod programu, który widzi pierwszy raz. Stosowanie wzorców projektowych jest uznane wśród społeczności programistów za bardzo dobrą praktykę. Sama idea ponownego wykorzystania nie jest niczym nowym. Wiele lat wcześniej, przed popularyzacją wzorców projektowych przez [7], znane były techniki ponownego wykorzystania komponentów, czy po prostu klas. Warto też dodać, czym nie jest wzorzec projektowy - nie jest to gotowa biblioteka lub klasa, którą można bezpośrednio wykorzystać. Każdy wzorzec projektowy wymaga aby to programista wykorzystujący dany wzorzec odpowiednio go zaimplementował. Wzorce projektowe można nazwać "półproduktami". Ponadto nie w każdej sytuacji można zastosować znany wzorzec projektowy. Przyjęło się, że aby pewne rozwiązanie można było nazwać wzorcem musi spełnić regułę trzech. Co oznacza, że rozwiązanie musi zostać wykorzystane w przynajmniej trzech przypadkach bardzo podobnych problemów. 2.3. Klasyfikacja wzorców projektowych Jednym z najważniejszych dokonań Bandy Czterech jest klasyfikacja wzorców projektowych [7]. Klasyfikację tą przedstawia tabela 1. Wzorce konstrukcyjne dotyczą problemów związanych z tworzeniem obiektów. Wzorce strukturalne dotyczą problemów ze składaniem klas lub obiektów. Wzorce operacyjne dotyczą problemów ze współdziałaniem klas lub obiektów oraz podziałem zachowania między nimi. Rafał Wojszczyk 136 Tab. 1. Klasyfikacja wzorców projektowych na podstawie [GoF] Konstrukcyjne Metoda wytwórcza Fabryka abstrakcyjna Budowniczy Prototyp Singleton Strukturalne Adapter Most Kompozyt Dekorator Fasada Pyłek Pełnomocnik Operacyjne Interpreter Metoda szablonowa Łańcuch zobowiązań Polecenie Iterator Mediator Pamiątka Obserwator Stan Strategia Wizytator 3. Nieformalne sposoby reprezentacji wzorców projektowych Wzorce projektowe reprezentowane są bardzo często w sposób nieformalny, tzn. w postaci ogólnego opisu słownego, wzbogaconego diagramami w notacji UML. Takie podejście zostało wykorzystane w [7]. Christopher Alexander do opisu swoich wzorców również stosował sposób nieformalny. Sposób nieformalny zaproponowany przez [7] przedstawia tabela 2. Niewątpliwą zaletą takiego sposobu reprezentacji jest łatwość zrozumienia i przejrzystość. Tym bardziej, że dzieło [7] jest traktowane jako katalog wzorców projektowych. Niestety, zasadniczą wadą takiej reprezentacji jest brak możliwości interpretacji tego zapisu w sposób zrozumiały dla komputera. Jak też wynik przekształcenia zaimplementowanego wzorca projektowego w kodzie programu do reprezentacji nieformalnej, nie ma sensu i nie będzie mógł być poddany dalszej analizie. Oprócz wspomnianych sposobów [7] oraz Alexandra, istnieją też inne sposoby reprezentacji nieformalnej, np. przedstawiona w [6]. Cechą wspólną tych sposobów jest przede wszystkim nazwa, która powinna jednoznacznie nakreślać istotę rozwiązywanych problemów. Według [10] i [11] reprezentacje oparte w znacznym stopniu na języku UML klasyfikują się pomiędzy reprezentacjami nieformalnymi a formalnymi i uznawane są za półformalne. Opis w postaci diagramów klas UML jest jednym z elementów systemu nieformalnego opisanego wcześniej. Mimo wszystko Porównanie sposobów reprezentacji wzorców projektowych 137 taki opis może być niewystarczający do pełnego przedstawienia rozbudowanych wzorców projektowych. Dzieje się tak, ponieważ diagramy klas przedstawiają wyłącznie statyczną strukturę wzorców, podczas gdy wiele z nich charakteryzuje się wieloma właściwościami dynamicznymi. Tab. 2. Opis nieformalny według [7] Nazwa i klasyfikacja Przeznaczenie Inne nazwy Uzasadnienie Warunki stosowania Struktura Elementy Współdziałanie Konsekwencje Implementacja Przykładowy kod Znane zastosowania Powiązane wzorce Zwięzła nazwa określająca jego istotę oraz klasyfikacja zgodnie z podrozdziałem 2.3. niniejszej pracy. Krótkie określenie problemu jaki rozwiązuje dany wzorzec. Inne nazwy pod jakimi jest znany wzorzec. Scenariusz ilustrujący problem projektowy. Opis sytuacji w jakich można zastosować wzorzec. Graficzna reprezentacja wzorca, przeważnie w postaci diagramu klas UML (w [GoF] przedstawione w notacji OMT [GoF, s. 347]. Klasy i obiekty wchodzące w skład wzorca oraz ich wzajemne relacje. Opis współpracy pomiędzy elementami wzorca, w celu zrealizowania odpowiednich zadań. Rezultaty wykorzystania wzorca, problemy oraz konsekwencje z tego wynikające. Opis ważnych zagadnień podczas implementacji. Fragmenty kodu demonstrujące przykładową implementację wzorca. Znane i powielane zastosowania wzorca w istniejących systemach. Opis związków z innymi wzorcami, sugestie, z którymi powinno się stosować dany wzorzec. 4. Reprezentacje formalne Zasadniczą cechą reprezentacji formalnej jest fakt, że może ona zostać poddana analizie i przetwarzaniu komputerowemu. Cechą niekorzystną reprezentacji formalnej jest trudność wprowadzenia, zrozumienia i odczytania tego zapisu przez człowieka. W dalszej części zostały przedstawione reprezentacje formalne oparte na grafach oraz ontologiach. 138 Rafał Wojszczyk 4.1. Reprezentacja grafowa Wychodząc od popularnego opisu wzorców projektowych w postaci diagramu klas UML, można zauważyć, że jest to po prostu graf skierowany [8]. Podstawowym założeniem jest reprezentowanie klas jako wierzchołków a relacji jako krawędzi. Podejście grafowe zostało przedstawione w [SinR13] wraz z rozwinięciem w [13], oraz w [16]. Podstawowe podejście jak w [12] było znane już wcześniej. Elementy w oprogramowaniu przedstawione są jako wierzchołki, a relacje między tymi elementami jako krawędzie. Jak podaje [12] takie podejście jest wystarczające do opisania i rozpoznania niektórych wzorców, np. Fabryka abstrakcyjna. Bardzo mała ilość informacji zawarta w tym podejściu nie pozwala na zaawansowany opis wzorców projektowych. W [13] przedstawione jest rozszerzone podejście względem [12]. Rozszerzenie polega na odpowiednim etykietowaniu wierzchołków i krawędzi. Wierzchołki opisane są poprzez trzy parametry: ilość nadklas, ilość podklas, ilość powiązań. Poprzez ilość nadklas i podklas rozumiane są klasy, z których dziedziczy rozważana klasa oraz z klasy, które dziedziczą z rozważanej klasy. Etykiety krawędzi reprezentują rodzaj relacji pomiędzy klasami, autorzy [13] proponują: 1 - zależność, 2 - generalizacja, 3 - asocjacja skierowana, 4 - agregacja. Przykład takiego opisu przedstawia rysunek 1 i 2. Porównanie sposobów reprezentacji wzorców projektowych 139 Rys. 1. Diagram klas opisujący wzorzec Strategia. Źródło: opracowanie własne na podstawie [13] Rys. 2. Graf etykietowany opisujący wzorzec projektowy Strategia. Źródło: opracowanie własne na podstawie [13] W [16] szczególna uwaga została skupiona na reprezentacji relacji, przez co zakładają użycie większej liczby relacji niż [13]. Ponadto zauważają, że wiele wzorców projektowych ma wspólną cechę związaną z relacjami, tj. występują klasy lub interfejsy abstrakcyjne. W obu przedstawionych podejściach [13] i [16] znaczącą cechą wspólną jest możliwość łatwej transformacji grafu do postaci macierzy. Macierze są typowe dla zastosowań inżynierskich. W obu przypadkach dla każdego rodzaju relacji tworzona jest podobna macierz, a etykietami wierszy oraz kolumn są 140 Rafał Wojszczyk wierzchołki grafów. Wystąpienie danej relacji pomiędzy wierzchołkami grafu oznaczane jest w macierzy odpowiednią wartością (zależne od podejścia), co odpowiada istnieniu relacji pomiędzy elementami wzorca. Reprezentacja w postaci grafów ma swoje wady i zalety. Zaletą jest to, że taki zapis wynika z popularnych diagramów UML, a po odpowiednim przekształceniu informacje reprezentowane są w postaci macierzy. Wada wynikła w trakcie próby weryfikacji w [13], polegającej na wyszukaniu kilku wzorców w grafie. Przedstawione wyniki dla trzech przypadków: pełne dopasowanie, częściowe oraz brak dopasowania (szukany wzorzec nie został odnaleziony w grafie mimo, że występuje). Wystąpienie ostatniego przypadku oznacza, że taka reprezentacja może być niewystarczająca do analizowania komputerowego wzorców projektowych. 4.2. Reprezentacja ontologiczna Termin ontologia wywodzi się z filozofii, gdzie celem ontologii było określenie rzeczywistych bytów świata rzeczywistego [14]. Popularność ontologii w informatyce stale rośnie i jest wykorzystywana do formalnej reprezentacji wiedzy w postaci zbioru pojęć z danej dziedziny i relacji między tymi pojęciami. Podstawową korzyścią ontologii w informatyce jest założenie, że reprezentowana przez nie wiedza jest rozumiana przez komputery. Inną korzyścią jest możliwość łączenia ontologii ze sobą. Opiera się to na idei sieci semantycznych, które wprowadzają standaryzowane metadane służące do opisu danych [3]. Ontologie mogą być opisane za pomocą kilku języków: RDF (od ang. Resource Description Framework), RDFS (od ang. RDF Schema) oraz OWL (od ang. Web Ontology Language) [15]. Semantyka wszystkich wymienionych wywodzi się z języka XML, dzięki czemu są do siebie podobne. Języki te różnią się możliwościami. OWL występuje w trzech odmianach, OWL Full najbardziej ekspresywny (wyrazisty), DL mniej ekspresywny i bardziej wydajny w przetwarzaniu oraz Lite najmniej ekspresywny ale za to najbardziej wydajny w przetwarzaniu. W najgorszym przypadku przetwarzanie OWL Full może być nieskończone. Przez ostatnie lata ontologie zostały kilkukrotnie wykorzystane do reprezentacji wzorców projektowych np. w [2, 5, 9, 10, 11]. Cechami wspólnymi kilku z tych prac jest dostarczenie ontologii opisującej strukturę wzorców projektowych, w niektórych przypadkach również możliwość opisania dodatkowych niestatycznych cech: zachowania, sposób implementacji, wymagania kontekstu [10]. Opis wzorca projektowego Fabryka Abstrakcyjna w podejściu [5] przedstawia rysunek 3. W tym podejściu wykorzystany jest język OWL. Porównanie sposobów reprezentacji wzorców projektowych 141 Rys. 3. Graficzna reprezentacja wzorca projektowego Fabryka Abstrakcyjna opisanego za pomocą ontologii. Źródło: [5] Bardziej rozbudowane podejście przedstawione jest w [9]. Oprócz ontologii opisującej wzorce projektowe, autorzy wprowadzili również taksonomię, opisującą podstawowe elementy z paradygmatu programowania obiektowego: zmienne, stałe, pętle, typy danych i inne. Wprowadzają również ograniczenia opisujące w sposób formalny różne cechy charakterystyczne dla konkretnych wzorców. Możliwe jest następujące opisanie ograniczeń np. dla wzorca projektowego Singleton [9]: 1 - dopuszczalny jest tylko prywatny konstruktor; 2 musi być przynajmniej jedna publiczna metoda, która zwraca typ taki sam jak tworzony Singleton; 3 - publiczna metoda zawsze musi zwracać tą samą instancję obiektu. Oczywiście przytoczone restrykcje mogą, a nawet powinny być opisane w języku formalnym, zrozumiałym dla komputera. W tym przypadku jest to OWL abstract syntax [17]. Istnieją też repozytoria wiedzy o wzorcach projektowych, jak przedstawione w [10]. Celem takiego repozytorium jest szerzenie wiedzy o wzorcach projektowych, nauka i wsparcie w ich wykorzystaniu. Możliwy jest dialog pomiędzy użytkownikiem a systemem zaproponowanym w [10], na zasadzie pytanieodpowiedź (pytania są predefiniowane i istnieje możliwość rozszerzenia tej listy). W tym rozwiązaniu został wykorzystany język RDF, a baza wiedzy została zasilona z innych baz, dzięki możliwości przekształceń danych do RDF. 142 Rafał Wojszczyk 5. Porównanie W poniższej części zaprezentowano porównanie wymienionych wcześniej sposobów reprezentacji wzorców projektowych. Przedmiotem porównania jest reprezentacja nieformalna i formalna. W przypadku ostatniego sposobu zostanie on rozdzielony na dwa podtypy reprezentacji grafowej oraz ontologicznej. W obu przypadkach porównywane cechy będą rozważane dla całych rodzin z tych reprezentacji, ponieważ możliwe jest połączenie cech w celu stworzenia najkorzystniejszego rozwiązania. Porównywane cechy są związane z przedmiotem badań nad wzorcami projektowymi, dokładniej nad weryfikacją ich implementacji. Spełnienie cech w porównaniu zostało określone przez autora na podstawie przeprowadzonej wcześniej analizy reprezentacji wzorców projektowych. Wynik analizy przedstawia tabela 3. Stawiając za cel zautomatyzowane analizowanie wzorców projektowych, konieczne jest odrzucenie reprezentacji innych niż formalne, ponieważ wykorzystanie pozostałych to tego celu znacznie skomplikuje cały proces. Pozostając przy dwóch sposobach reprezentacji, grafowej oraz ontologicznej, należy uwzględnić zakres możliwej analizy. W przypadku wykorzystania reprezentacji grafowej zakres analizy ograniczy się jedynie do aspektów statycznych. Będzie to wystarczające to wykrycia i zweryfikowania (w podstawowym zakresie) przynajmniej kilku wzorców, w pozostałych przypadkach wynik może być niejednoznaczny lub błędny, jak przedstawiono w [12] i [13]. Korzyścią tego podejścia, po przekształceniu do macierzy, jest możliwość wykorzystania ogólnodostępnych programów do obliczeń inżynierskich. Rozważając wykorzystanie reprezentacji ontologicznej zakres analizy rozszerza się w stosunku do grafowej. Zasadniczą różnicą jest możliwość opisania w sposób formalny zachowania wzorców. Dzięki czemu analiza może mieć znacznie szerszy zakres i uwzględniać aspekty, którą są niedostępne przy czysto statycznym podejściu. Następną korzyścią, na rzecz ontologii, jest możliwość opisu w sposób formalny dowolnych aspektów związanych z rozpatrywaną dziedziną wiedzy. Niestety wymienione korzyści, mają też negatywny wydźwięk. Wymagają one prawidłowego opisania w jednym ze wspomnianych języków definiowania ontologii, co zdaje się być bardzo wymagającym zadaniem, aby osiągnąć owe korzyści. Porównanie sposobów reprezentacji wzorców projektowych 143 Tab. 3.Wyniki porównania Cecha\Sposób Nieformalne Grafy Ontologie Nie Tak Tak Nie dotyczy Zależna od ilości elementów W najgorszym przypadku nieskończona Możliwość zautomatyzowanego pozyskania danych na podstawie kodu źródłowego Nie Tak Tak Opis aspektów statycznych Tak Tak Tak Opis zachowania Tak Nie Tak Możliwość opisania charakterystycznych cech, np. występujących tylko w jednym wzorcu Tak Nie Tak Możliwość zautomatyzowanego przekształcenia do innej reprezentacji Nie Tak Tak Przydatność do nauki, łatwość czytania przez człowieka Duża Mała Mała Możliwość reprezentacji modelu referencyjnego Tak Tak Tak Możliwość opisu implementacji Nie Tak Tak Formalna standaryzacja podstawowych elementów Nie Tak, teoria grafów Tak, W3C Możliwość rozbudowy semantyki Tak Nie Tak Możliwość formalnego i spójnego łączenia z innymi zasobami wiedzy Nie Nie Tak Możliwość formalnego analizowania komputerowego Złożoność analizowania 6. Podsumowanie W pracy przedstawiono nieformalne oraz formalne sposoby reprezentacji wzorców projektowych. Następnie dokonano teoretycznej analizy, w oparciu o cechy związane z badaniem implementacji wzorców, a wyniki przedstawiono w postaci porównania. Wykonane porównanie nie wskazuje jednoznacznie najlepszego pod każdym względem sposobu reprezentacji wzorców projektowych. Do poznawania ich oraz nauki sprawdza się od wielu lat sposób nieformalny. Stawiając za cel wyszukiwanie, weryfikowanie czy też podpowiadanie wzorców projektowych, Rafał Wojszczyk 144 powinien zostać wykorzystany sposób formalny. W zależności od zakresu tych działań, należy wybrać pomiędzy reprezentacją grafową, gdy wystarczające będą aspekty statyczne, lub ontologiczną w pozostałych przypadkach. Obierając za cel możliwość pełnego analizowania oprogramowania, w tym weryfikację implementacji wzorców projektowych, pretendentem do takiego zastosowania staje się reprezentacja ontologiczna. Dzięki odpowiedniemu zaprojektowaniu ontologii, która uwzględniałaby cechy związane z paradygmatem programowania obiektowego, możliwe jest zastąpienie w ten sposób reprezentacji grafowej, z jednoczesnym dostarczeniem dodatkowych możliwości, jakie daje uniwersalność ontologii. Literatura 1. 2. 3. 4. 5. 6. 7. 8. Alexander C., The origins of pattern theory: the future of the theory, and the generation of a living world, Journal IEEE Software archive, Volume 16 Issue 5, IEEE Computer Society Press Los Alamitos, CA, USA, 1999 Alnusair A., Zhao T., Yan G., Rule-based detection of design patterns in program code, International Journal on Software Tools for Technology Transfer, Springer Berlin Heidelberg, 2013 Bilski J., Model systemu wieloagentowego korzystającego z danych Sieci semantycznej w projekcie Open Natura 2000, Modele inżynierii teleinformatyki, tom 8, X Krajowa Konferencja Studentów i Młodych Pracowników Nauki, 2013 Dae-kyoo Kim , Robert France , Sudipto Ghosh , Eunjee Song, A UMLBased Metamodeling Language to Specify Design Patterns, Patterns,” Proc. Workshop Software Model Eng. (WiSME) with Unified Modeling Language Conf. 2003 Dietrich J., Elgar C., A formal description of design patterns using OWL, Software Engineering Conference, Australian, 2005 Fowler M. i inni, Architektura systemów zarządzania przedsiębiorstwem – Wzorce projektowe, Helion, Gliwice, 2005 Gamma E. i inni, WZORCE PROJEKTOWE Elementy oprogramowania wielokrotnego użytku, Helion, Gliwice, 2010 Grzanek K., Realizacja systemu wyszukiwania wystąpień wzorców projektowych w oprogramowaniu przy zastosowaniu metod analizy statycznej kodu źródłowego, Dysertacja doktorska, Politechnika Częstochowska, Łódź, 2008 Porównanie sposobów reprezentacji wzorców projektowych 9. 10. 11. 12. 13. 14. 15. 16. 17. 145 Kirasić D., Basch D., Ontology-Based Design Pattern Recognition, Knowledge-Based Intelligent Information and Engineering Systems, Zagreb, Croatia, 2008 Pavlic L. i inni, Improving design pattern adoption with Ontology-Based Design Pattern Repository, Informatica An International Journal of Computing and Informatics, Vol 33, Ljubljana, Slovenia, 2009 Rosengard J.M., Ursu M.F., Ontological Representations of Software Patterns, Knowledge-Based Intelligent Information and Engineering Systems, pages 31-37, Springer Berlin Heidelberg, 2004 Singh Rao R., Gupta M., Design Pattern Detection by Sub Graph Isomorphism Technique, International Journal Of Engineering And Computer Science, Volume 2 Issue 11 Page No. 3101-3105, 2013 Singh Rao R., Gupta M., Design Pattern Detection by Greedy Algorithm Using Inexact Graph Matching, International Journal Of Engineering And Computer Science, Volume 2 Issue 10, 2013 Susłow W., Analiza I modelowanie konceptualne w inżynierii systemów oprogramowania – ujęcie humanistyczne, Wydawnictwo Uczelniane Politechniki Koszalińskiej, Koszalin, 2013 Szymczak M., Modelowanie przy pomocy technologii ontologicznych, Praca Magisterska, Uniwersytet im. Adama Mickiewicza w Poznaniu, 2006 Tsantalis N. i inni, Design Pattern Detection Using Similarity Scoring, IEEE Transactions on Software Engineering (Volume:32, Issue: 11), 2006 http://www.w3.org/TR/2004/REC-owl-semantics-20040210/syntax.html
