POLITECHNIKA WARSZAWSKA - ee.pw.edu.pl

POLITECHNIKA WARSZAWSKA WYDZIAŁ ELEKTRYCZNY

Rozprawa doktorskaRozprawa doktorskaRozprawa doktorskaRozprawa doktorska

mgr inż. Kamil Jarosław Rybiński

Reprezentacja wiedzy dziedzinowej na potrzeby generacji kodu Reprezentacja wiedzy dziedzinowej na potrzeby generacji kodu Reprezentacja wiedzy dziedzinowej na potrzeby generacji kodu Reprezentacja wiedzy dziedzinowej na potrzeby generacji kodu

z poziomu wymagań oprogramowaniaz poziomu wymagań oprogramowaniaz poziomu wymagań oprogramowaniaz poziomu wymagań oprogramowania

Promotor

dr hab. inż. Michał Śmiałek

WARSZAWA 2019

iii

StreszczenieReprezentacja wiedzy dziedzinowej na potrzeby generacji kodu z poziomu wymagan

oprogramowania

Kamil Jarosław RYBINSKI

Praca przedstawia wyniki badan nad mozliwoscia zwiekszenia efektywnosci wytwarzania opro-

gramowania poprzez generacje kodu z poziomu opisu konceptualnego (specyfikacji wymagan).

Zawiera ona opis formalnie zdefiniowanego jezyka RSL-DL (Requirements Specification Lan-

guage - Domain Logic), słuzacego do tworzenia konceptualnych modeli dziedziny. Został on

zaprojektowany jako jezyk uniwersalny, deklaratywny i niezalezny od dziedzin zastosowan.

Jednoczesnie, modele opracowane dla konkretnej dziedziny moga byc wielokrotne wykorzysty-

wane do tworzenia róznorodnych systemów oprogramowania. Dla jezyka zdefiniowano: skład-

nie abstrakcyjna, składnie konkretna, oraz semantyke. Składnie abstrakcyjna okreslono w for-

mie meta-modelu zapisanego w jezyku MOF. Do okreslenia semantyki uzyto metody trans-

lacyjnej, polegajacej na mapowaniu konstrukcji jezyka RSL-DL na konstrukcje jezyka pro-

gramowania. W tym celu zdefiniowano zestaw reguł translacyjnych oraz dokonano ich imple-

mentacji. Implementacja powstała jako rozszerzenie systemu ReDSeeDS i stosowanego w nim

jezyka RSL. System ten umozliwia generacje warstw interfejsu uzytkownika i logiki aplika-

cji na podstawie specyfikacji wymagan funkcjonalnych. W celu dokonania oceny efektywnosci

tworzenia oprogramowania przy pomocy opracowanego podejscia, wykonano studium przy-

padku przy wykorzystaniu rozszerzonego narzedzia ReDSeeDS. W ramach studium stworzono

specyfikacje dziedzinowa i wygenerowano na jej podstawie funkcjonalny kod warstwy logiki

dziedzinowej. W rezultacie, uzyskano narzedzie generujace kod dla wszystkich warstw opro-

gramowania w architekturze trójwarstwowej.

Słowa kluczowe: wytwarzanie oprogramowania sterowane modelami, inzynieria wymagan, re-

prezentacja wiedzy, meta-modelowanie, semantyka translacyjna, generacja kodu

iv

AbstractReprezentacja wiedzy dziedzinowej na potrzeby generacji kodu z poziomu wymagan

oprogramowania

Kamil Jarosław RYBINSKI

This work presents the results of research on the increase of software development productivity

through code generation from the level of conceptual description (requirements specification).

It specifies a formally defined language called RSL-DL (Requirements Specification Language

- Domain Logic) that can serve creating conceptual domain models. It was designed as uni-

versal, declarative and domain-agnostic. At the same time, models for a specific domain can

be reused many times to define different software systems. The language was defined through

its abstract syntax, concrete syntax and semantics. The abstract syntax was specified through a

meta-model denoted in the MOF language. Translational method was used to specify seman-

tics, where RSL-DL constructs were mapped onto the constructs of a programming language.

A set of translational rules and their implementation were created for this purpose. The imple-

mentation was done as an extension to the existing ReDSeeDS system and the associated RSL

language. This system allows to generate the interface and application logic layers based on re-

quirements specifications. To assess effectiveness of software development with the presented

approach, a case study with the use of the extended ReDSeeDS tool was conducted. Within the

study, a domain specification was created and operational code of the domain logic layer was

generated. This resulted in establishing a code generation tool for all the layers of a three-tier

architecture.

Keywords: model-driven software development, requirements engineering, knowledge represen-

tation, meta-modelling, translational semantics, code generation

v

Spis tresci

Streszczenie iii

Abstract iv

1 Wprowadzenie i stan sztuki 1

1.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Zasady reprezentacji wiedzy . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Przeglad jezyków reprezentacji wiedzy . . . . . . . . . . . . . . . . . . . . . . 9

1.3.1 KIF i Ontolingua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3.2 KL-ONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3.3 FLogic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3.4 LOOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3.5 OCML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3.6 OWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.3.7 Prolog i A-Prolog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.3.8 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.3.9 Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.4 Analiza porównawcza jezyków reprezentacji wiedzy . . . . . . . . . . . . . . 25

1.5 Infrastruktura dla definiowania jezyków modelowania . . . . . . . . . . . . . . 31

1.6 Rozwiazania pokrewne w obszarze generacji kodu . . . . . . . . . . . . . . . 38

2 Jezyk RSL i system ReDSeeDS 41

2.1 Jezyk RSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.1.1 Przypadki uzycia i scenariusze . . . . . . . . . . . . . . . . . . . . . . 42

vi

2.1.2 Pojecia dziedzinowe i słownik . . . . . . . . . . . . . . . . . . . . . . 46

2.2 System ReDSeeDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3 Definicja jezyka RSL-DL 53

3.1 Załozenia i ogólna charakterystyka . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2 Podstawowa struktura: pakiet „Core” . . . . . . . . . . . . . . . . . . . . . . . 56

3.2.1 Składnia abstrakcyjna . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.2.2 Znaczenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.2.3 Składnia konkretna i przykłady . . . . . . . . . . . . . . . . . . . . . 62

3.3 Pojecia: pakiet „Notions” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65


3.3.2 Znaczenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


3.4 Relacje: pakiet „Relationships” . . . . . . . . . . . . . . . . . . . . . . . . . . 77


3.4.2 Znaczenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78


3.5 Wzory: pakiet „Patterns” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82


3.5.2 Znaczenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85


3.6 Zapytania do modelu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89


3.6.2 Znaczenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89


4 Semantyka translacyjna dla jezyka RSL-DL 91

4.1 Reguły transformacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.1.1 Docelowa architektura . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.1.2 Struktura klas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

vii

4.1.3 Metody realizujace zapytania . . . . . . . . . . . . . . . . . . . . . . 113

4.1.4 Generowanie kodu ze wzorów . . . . . . . . . . . . . . . . . . . . . . 120

4.2 Przykładowa implementacja . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

4.2.1 Struktura działania transformacji . . . . . . . . . . . . . . . . . . . . . 123

4.2.2 Silnik wnioskujacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

4.2.3 Generacja kodu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

5 Studium przypadku 133

5.1 Specyfikacja wymagan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

5.2 Rozszerzona specyfikacja dziedzinowa . . . . . . . . . . . . . . . . . . . . . . 143

5.3 Kod logiki dziedzinowej . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

6 Podsumowanie i wnioski 161

Bibliografia 165

1

Rozdział 1

Wprowadzenie i stan sztuki

1.1 Wprowadzenie

Faza formułowania wymagan funkcjonalnych dla systemów oprogramowania, nawet w kon-

tekscie wzrastajacej popularnosci metodyk zwinnych [15, 6], jest nadal jednym z kluczowych

elementów procesu wytwarzania oprogramowania. Niezaleznie od stosowanej metodyki ma ona

duzy wpływ na jego koncowy efekt [83, 13], zwłaszcza w przypadku bardziej złozonych sys-

temów. W jej trakcie powinny zostac okreslone i spisane faktyczne wymagania klienta co do

sposobu działania tworzonej aplikacji. W praktyce, wymagania stanowia wiekszosc niezalez-

nych od wykorzystywanej technologii, merytorycznych informacji koniecznych do powstania

systemu oprogramowania. W rezultacie, własciwe przeprowadzenie tej fazy ma istotny wpływ

na jakosc powstałej aplikacji, jak i równiez na sam fakt zakonczenia danego projektu powodze-

niem.

Poprawne przekształcenie wymagan w działajaca aplikacje stanowi zatem kluczowy ele-

ment kazdego projektu inzynierii oprogramowania. Obiecujacym podejsciem do tego problemu

jest próba automatyzacji tego przekształcenia, nazywana inzynieria wymagan sterowana mo-

delami (ang. Model-Driven Requirements Enginering – MDRE) [7, 98]. MDRE jest przedsta-

wicielem nurtu architektury sterowanej modelami (ang. Model-Driven Architecture – MDA)

[66, 65], zapoczatkowanego kilkanascie lat temu. MDA opiera sie na ominieciu wielokrotnego

wprowadzania tych samych informacji poprzez wykorzystanie zautomatyzowanych transfor-

macji do wygenerowania kolejnych artefaktów procesu wytwarzania oprogramowania, w tym

kodu. MDRE uscisla kontekst i proponuje generacje artefaktów projektowych na podstawie

2 Rozdział 1. Wprowadzenie i stan sztuki

specyfikacji wymagan utworzonej we wczesnych fazach projektu. Aby dana specyfikacja mo-

gła byc przetwarzana w sposób automatyczny, musi byc stworzona z zastosowaniem odpowied-

nich reguł. Reguły te zapewnia wymagany na potrzeby transformacji poziom jednoznacznosci

informacji zawartych w specyfikacji. Oznacza to zwiekszenie wysiłku na etapie specyfikowa-

nia wymagan. Mozna jednak przypuszczac, ze wysiłek ten zaowocuje zwiekszeniem jakosci

samej specyfikacji, jako ze jednoznacznosc jest jedna z posród najczesciej wymienianych miar

jej jakosci [23].

Zwiekszajac jednoznacznosc specyfikacji, inzynieria wymagan sterowana modelami dazy

równoczesnie do zminimalizowania tak zwanej złozonosci incydentalnej [12]. Oznacza to re-

dukcje udziału zadan pobocznych, zwiazanych z koniecznoscia uwzglednienia aspektów wyko-

rzystywanych technologii. Informacje konieczne do uwzglednienia złozonosci incydentalnej sa

bowiem zawarte w samej transformacji. MDRE skupia sie na esencji dziedziny, w ramach której

powstaje dane oprogramowanie. Próbuje ujac opis dziedziny, jak i dotyczacej tej dziedziny apli-

kacji, w forme jednoznacznej specyfikacji wymagan. Przybliza nas wiec do sytuacji, w której

do tworzenia oprogramowania bedzie wystarczała zdolnosc do zrozumienia i jednoznacznego

przedstawienia samego problemu, bez koniecznosci posiadania zaawansowanej wiedzy z dzie-

dziny inzynierii oprogramowania, czy jezyków programowania. Umozliwia równiez łatwiejsze

właczenie w proces wytwarzania oprogramowania zainteresowanych jego efektem osób o mniej

specjalistycznej wiedzy z zakresu informatyki, ułatwiajac im zrozumienie powstałych w tym

procesie artefaktów.

Przykładem narzedzia reprezentujacego paradygmat wytwarzania oprogramowania stero-

wanego wymaganiami jest system ReDSeeDS [99, 85]. Umozliwia on wygenerowanie kom-

pletnego kodu warstw widoku i logiki aplikacji zgodnych ze wzorcem MVP [84] na podstawie

specyfikacji wymagan opartej na scenariuszach przypadków uzycia [96, 97, 89]. Mozliwe jest

równiez wygenerowanie warstwy dostepu do bazy danych na tej samej podstawie [46]. System

ReDSeeDS nie umozliwiał jednak generacji kompletnej warstwy logiki dziedzinowej. Według

najlepszej wiedzy autora, nie istnieja równiez inne narzedzia oferujace taka mozliwosc. Wynika

to miedzy innymi z braku metod precyzyjnego zapisu logiki dziedzinowej opisanej na poziomie

specyfikacji wymagan i jej transformacji bezposrednio do kodu.

1.1. Wprowadzenie 3

Celem niniejszej pracy jest próba zapełnienia tej luki poprzez zbadanie mozliwosci gene-

racji kodu realizujacego logike dziedzinowa jedynie na podstawie informacji mozliwych do

okreslenia na etapie tworzenia specyfikacji funkcjonalnej. Celem jest równiez wstepne zba-

danie wpływu wykorzystania takiej mozliwosci na efektywnosc całego procesu wytwarzania

oprogramowania, w oparciu o wykonane studium przypadku. Mozna postawic hipoteze, ze za-

stapienie tradycyjnych sposobów reprezentacji danych oraz implementacji algorytmów prze-

twarzania danych przez reprezentacje logiki dziedzinowej na poziomie konceptualnym, moze

przyniesc istotne korzysci. Chcemy tutaj odzwierciedlic sama istote rozwiazywanych proble-

mów, w sposób jak najbardziej zblizony do naturalnego myslenia. Takie podejscie pozwoliłoby

zarówno uproscic sam proces wytwórczy, jak i ułatwic zaangazowanie w niego osób mniej wy-

kwalifikowanych w tworzeniu oprogramowania. W szczególnosci, uprosciłoby przekazywanie

wiedzy pomiedzy ekspertami dziedziny problemu a osobami odpowiedzialnymi za tworzenie

danego systemu. Mozna tez miec nadzieje, ze podobnie jak koniecznosc przedstawienia infor-

macji opisujacych same wymagania funkcjonalne w bardziej uporzadkowanej formie pomaga

lepiej zrozumiec tworzony system, tak koniecznosc uporzadkowania wiedzy dziedzinowej na

potrzeby generacji kodu moze przyczyniac sie do lepszego zrozumienia danej dziedziny.

Hipoteza badawcza. Generacja kodu aplikacji bezposrednio z konceptualnej specyfikacji lo-

giki dziedzinowej pozwala na zwiekszenie efektywnosci tworzenia oprogramowania.

W celu weryfikacji powyzszej hipotezy, w ramach niniejszej pracy wykonano rozszerze-

nie narzedzia ReDSeeDS o funkcjonalnosc specyfikowania logiki dziedzinowej na poziomie

konceptualnym oraz generowania na tej podstawie pełnego kodu warstwy logiki dziedzinowej.

W pierwszej kolejnosci przeanalizowano istniejace jezyki umozliwiajace reprezentacje wie-

dzy. Przeprowadzona analiza dotyczyła zastosowania tych jezyków do specyfikowania wyma-

gan oprogramowania. Wykazała ona niewystarczajace mozliwosci reprezentowania wszystkich

informacji niezbednych do wygenerowania kompletnego kodu logiki dziedzinowej. Ponadto,

zastosowana notacja czesto nie jest wystarczajaco przyjazna dla zwykłych uzytkowników. W


zwiazku z tym, podjeto decyzje o zaprojektowaniu własnego jezyka. Jezyk ten jest rozwinie-

ciem jezyka RSL (Requirements Specification Language) [44, 101], zastosowanego w systemie

ReDSeeDS. Rozwiazanie takie umozliwiło naturalna integracje z pozostałymi czesciami specy-

fikacji wymagan – w tym specyfikacja modelu przypadków uzycia. Kolejne etapy obejmowały

stworzenie edytora powstałego jezyka, zintegrowanie go z systemem ReDSeeDS oraz opraco-

wanie reguł i implementacja transformacji generujacej kod. Ostatnim krokiem było przepro-

wadzenie studium przypadku. W jego ramach przygotowano kompletna specyfikacje dziedziny

oraz wygenerowano w pełni funkcjonalny kod warstwy logiki dziedzinowej, zgodny z kodem

pozostałych warstw systemu. Studium to pozwala na dokonanie oceny wpływu opracowanego

podejscia na efektywnosc procesu tworzenia oprogramowania i walidacji postawionej wyzej

hipotezy.

W dalszej czesci biezacego rozdziału zawarto ogólne informacje dotyczace dziedziny pracy

jak i omówienie przeanalizowanych jezyków. Opisano w nim zarówno struktury elementów

wykorzystywanych do reprezentacji wiedzy w kazdym z rozwazanych jezyków, jak i krótko

scharakteryzowano cechy dla nich wszystkich wspólne. Wyjasniono takze podejscie, które be-

dzie stosowane do definiowania nowego jezyka i jego transformacji w dalszej czesci pracy oraz

opisano poszczególne jego elementy. Drugi rozdział zawiera omówienie systemu ReDSeeDS

i wykorzystywanego w nim jezyka RSL. Jako ze projektowany jezyk ma stanowic uzupełnie-

nie jezyka RSL, opis ten pozwala na zrozumienie kontekstu, w którym bedzie on wystepował.

Opisano zatem strukture scenariuszy przypadków uzycia, definiujaca logike aplikacji, w której

znajda sie odwołania do logiki dziedzinowej. Przedstawiono takze strukture słownika dziedzi-

nowego, z którym tworzony jezyk ma korespondowac. Trzeci rozdział omawia składnie tworzo-

nego jezyka: zarówno składnie abstrakcyjna w postaci meta-modelu, jak i składnie konkretna,

widoczna dla uzytkowników jezyka. Struktura rozdziału oparta została o podział definicji je-

zyka na pakiety, a poszczególne jego konstrukcje zostały zobrazowane prostymi przykładami.

Czwarty rozdział pokazuje zasady, na których opiera sie transformacja umozliwiajaca gene-

racje logiki dziedzinowej. Wymieniono w nim kolejne reguły okreslajace zaleznosc transla-

cyjna pomiedzy modelami w tworzonym jezyku, a generowanym kodem. Reguły zobrazowano

diagramami prezentujacymi mozliwe szczegóły ich zastosowania oraz podano przykłady ich

1.2. Zasady reprezentacji wiedzy 5

działania. W rozdziale tym zawarty jest takze opis implementacji przedstawionych reguł w na-

rzedziu zbudowanym w ramach niniejszej pracy. Zawiera on opis silnika wnioskujacego i zwia-

zanego z nim algorytmu, pomagajacego okreslic sposób zastosowania poszczególnych reguł

wystepujacych w specyfikacji, do generacji kodu. Opisano w nim równiez całokształt procesu

transformacji i istotne szczegóły techniczne z nim zwiazane. Wreszcie piaty rozdział omawia

przeprowadzone studium przypadku. Pokazana jest zarówno specyfikacja w jezyku RSL, jak

i jej rozwiniecie w jezyku RSL-DL. Zaprezentowano takze strukture wygenerowanego kodu i

omówiono bardziej interesujace jego fragmenty. Prace konczy podsumowanie, dyskusja oraz

wnioski dotyczace mozliwych kierunków dalszych prac.

Gwoli wyjasnienia nalezy równiez zaznaczyc, ze definicja jezyka RSL wykorzystywanego

w systemie ReDSeeDS jest sformułowana w jezyku angielskim. Dla zachowania spójnosci,

jego rozszerzenie zostało takze wykonane w jezyku angielskim. Oryginalne nazwy elementów

obydwu meta-modeli wystepuja zatem w pracy w formie anglojezycznej. Dodatkowo, jako ze

system ReDSeeDS jest dostosowany do pisania specyfikacji w jezyku angielskim, pokazane

przykłady i przeprowadzone studium przypadku takze uzywaja tego jezyka. Równiez w dalszej

czesci tego rozdziału, dla wielu terminów, oprócz polskich nazw, podano ich angielskie wersje.

Ma to miejsce zwłaszcza w sytuacjach, kiedy nie przyjeło sie jedno okreslone tłumaczenie

danego terminu na jezyk polski.

1.2 Zasady reprezentacji wiedzy

Przed przejsciem do opisu konkretnych, istniejacych rozwiazan zwiazanych z reprezentacja

wiedzy dziedzinowej i analiza ich przydatnosci do planowanego wykorzystania, konieczne jest

wyjasnienie paru ogólnych pojec dotyczacych tego obszaru. Umozliwi to stworzenie wspólnego

gruntu, na którym owe opisy i analize bedzie mozna oprzec. Podstawowym terminem uzywa-

nym w zwiazku z reprezentacja wiedzy jest pojecie ontologii. Wprowadzenie tego terminu do

powszechnego uzycia w informatyce przypisuje sie Tomowi Gruberowi [38], natomiast w ra-

mach definicji warto przywołac tłumaczenie jej bardziej dopracowanej i zwiezłej formy zapro-

ponowanej przez Feilmayra i Wößa [31] (tłumaczenie własne):


„Ontologia jest formalna, jednoznaczna specyfikacja wspólnej konceptualizacji,

charakteryzujaca sie wysokim poziomem ekspresji znaczeniowej koniecznej do od-

zwierciedlenia duzej złozonosci”.

Definicja ta okresla ontologie jako współdzielona konceptualizacje dziedziny, przez co –

jak bardziej szczegółowo wyjasniaja Studer et al. [104] – nalezy rozumiec abstrakcyjny model

danego zjawiska, identyfikujacy pojecia dla niego istotne. Dodatkowo, zwracaja oni uwage na

takie istotne jej cechy jak jednoznacznosc, oznaczajaca ze uzyte w opisie elementy sa precy-

zyjnie zdefiniowane, oraz formalnosc reprezentacji, oznaczajaca ze opis jest mozliwy do prze-

twarzania komputerowego. Zaznaczaja tez, ze owa konceptualizacja jest współdzielona, czyli

nie stanowi odzwierciedlenia pogladów pojedynczej osoby, a reprezentuje pewien konsensus

akceptowany przez pewna grupe. Ponadto, definicja ta podkresla istotnosc wysokiej ekspre-

sywnosci semantycznej, czyli zdolnosci do odzwierciedlenia skomplikowanych znaczen, która

jest konieczna do własciwego odwzorowania złozonych zagadnien.

Według Grubera [37] opis ontologii mozna sformalizowac za pomoca pieciu rodzajów ele-

mentów – konceptów, relacji, funkcji, aksjomatów i instancji. Bazujac na analizach porównu-

jacych rózne jezyki opisu ontologii i ich mozliwosci [20, 19, 93], otrzymujemy zblizony zbiór

elementów, z których typowo składaja sie ontologie.

Koncepty (Klasy) Przez koncepty nalezy rozumiec dowolne pojecia dziedzinowe, o których

dana ontologia cokolwiek wyraza, a precyzyjniej: pojecia opisujace pewne kategorie rze-

czy. Koncepty w ontologiach najczesciej uporzadkowane sa w forme taksonomii.

Relacje (Własciwosci/Role) Relacje opisuja zwiazki i zaleznosci pomiedzy konceptami. Re-

lacje, w których jeden z uczestniczacych w niej elementów wynika jednoznacznie z po-

zostałych, nazywamy funkcjami.

Instancje (Jednostki) Konkretnych przedstawicieli konceptów (oraz relacji, jesli jest to do-

puszczalne) okreslamy mianem instancji. Pojedyncze informacje na ich temat okreslamy

mianem faktów.

1.2. Zasady reprezentacji wiedzy 7

Aksjomaty Aksjomaty słuza definiowaniu stwierdzen, które powinny byc zawsze prawdziwe

i moga posłuzyc róznym celom, od okreslania ograniczen, po wyprowadzanie nowych

informacji (wnioskowanie). W zaleznosci od jezyka moga one byc czescia konceptów i

relacji, badz byc zapisywane niezaleznie od nich.

Przykładowo, jesli jako koncepty wyróznimy pojecia „pisarz” i „ksiazka”, to ich instan-

cjami moga byc odpowiednio „Henryk Sienkiewicz” i „Ogniem i mieczem”. Jako przykład

relacji mozna wtedy podac autorstwo ksiazki przez pisarza, gdzie faktem ich dotyczacym be-

dzie autorstwo „Ogniem i mieczem” przez Henryka Sienkiewicza. W innym przykładzie, jako

koncepty mozna wyróznic pojecia „liczba”, „liczba całkowita” i „liczba rzeczywista”. Mozna je

przedstawic w formie prostej taksonomii definiujacej, ze liczba rzeczywista jest szczególnym

przypadkiem liczby, a liczba całkowita szczególnym przypadkiem liczby rzeczywistej. Dalej

mozemy zdefiniowac „dodawanie” jako funkcje bedaca szczególnym rodzajem relacji miedzy

liczbami. Wreszcie za pomoca odpowiedniego aksjomatu mozna odzwierciedlic, ze instancja

liczby całkowitej jaka jest „zero” jest elementem neutralnym dodawania, to znaczy, ze funkcja

reprezentujaca to działanie dla dowolnej liczby i zera zawsze zwróci te dowolna liczbe.

W praktyce, poza wymienionymi czterema rodzajami elementów, niektóre ontologie moga

równiez zawierac procedury lub reguły powiazane z mechanizmami wnioskujacymi. Osobnego

omówienia wymaga równiez kwestia atrybutów, czyli cech opisujacych koncepty. W zaleznosci

od jezyka moga byc one przypisywane do konceptów lub tez reprezentowane niezaleznie od

nich. W wiekszosci przypadków sa one odwzorowywane za pomoca relacji łaczacych dany

koncept z innym go opisujacym. Przykładowo, w pierwszym z podanych wczesniej przykładów,

fakt posiadania przez autorów imion mozna odzwierciedlic w postaci relacji wiazacej koncept

„autor” z konceptem „imie”. Równiez w zaleznosci od jezyka, definicja tej relacji moze byc

zarówno czescia definicji autora jak i od niej niezalezna.

Szczególnie proste cechy sa tez w niektórych przypadkach odwzorowane w formie rela-

cji jednoelementowych. W drugim z podanych powyzej przykładów, pojecie liczb całkowitych

mozna w ten sposób rozszerzyc o pojecie liczb pierwszych. Mozna to reprezentowac za po-

moca jednoelementowej relacji dotyczacej tylko konceptu „liczba” (np. relacja o nazwie „liczba

pierwsza”) i nie łaczacej go z zadnymi dalszymi konceptami. Nastepnie, za pomoca odpowied-


niego aksjomatu mozna zdefiniowac fakt zachodzenie tej relacji tylko dla kazdej liczby bedacej

liczba pierwsza.

Historycznie mozemy wyróznic dwa główne paradygmaty jezyków słuzacych do opisu on-

tologii. Pierwszy z nich to jezyki bazujace na ramach (ang. frame). Jest to pojecie zblizone do

pojecia klasy w jezykach obiektowych, ale majace na celu przede wszystkim przedstawianie

wiedzy w sposób zblizony do tego, w jaki postrzega ja człowiek. Nie przykładana jest nato-

miast szczególna waga do tak istotnych cech w programowaniu obiektowym jak np. hermety-

zacja. Z kolei silnie wykorzystywane sa takie rzadko spotykane w programowaniu obiektowym

mechanizmy, jak dziedziczenie wielokrotne. Przez rame, czyli termin bedacy podstawa tego po-

dejscia, rozumiemy strukture zawierajaca wszystkie typowe i oczekiwane informacje, a takze

przypuszczenia, powiazane z danym konceptem. Idea ta wstepnie została wykorzystana na po-

trzeby rozumowania wizualnego i przetwarzania jezyka naturalnego przez Minskyego [69], a

zainspirowana została przez badania nad wykorzystywaniem przez ludzi posiadanej wiedzy w

nowych sytuacjach [4]. Stara sie ona odzwierciedlic zaobserwowana ludzka tendencje do ogra-

niczania zakresu, w którym poszukiwane sa rozwiazania napotkanych problemów. Kazda rama

powinna posiadac nazwe i zgodnie ze standardowym przedstawieniem zawierac opisujacy ja

zbiór tzw. klatek (ang. slot) reprezentujacych jej cechy, z których kazda równiez powinna byc

nazwana. Klatki zawieraja opisujace je tzw. fasety o okreslonych typach, które pozwalaja mie-

dzy innymi okreslic wartosc lub domyslna wartosc klatki, ograniczenia nałozone na nia, czy

procedury zwiazane ze zmiana tej wartosci. Same ramy sa z reguły uporzadkowane w takso-

nomie. Typowo, jezyki oparte o ramy wychodza z załozenia zamknietego swiata – wszystko,

czego nie wiemy jest domyslnie fałszywe.

Drugie podejscie do jezyków słuzacych do definiowania ontologii zwiazane jest z tak zwana

logika opisowa [3]. Pojecie to uzywane jest zarówno w odniesieniu do grupy jezyków opisu on-

tologii, jak i bazy teoretycznej za nimi stojacej. Podstawowe elementy, które składaja sie na

ontologie według tego paradygmatu to koncepty, role i jednostki, które sa opisywane za po-

moca aksjomatów, czyli logicznych zdan je okreslajacych. Stanowi to podstawowa róznice w

stosunku do paradygmatu opartego o ramy, gdzie wszystkie informacje na temat danego kon-

ceptu były zgrupowane w pojedynczy opis ramy. Zarówno koncepty, jak i relacje sa definiowane

1.3. Przeglad jezyków reprezentacji wiedzy 9

przez tak zwane koncepty atomowe i relacje atomowe, z których za pomoca takich operacji jak

na przykład koniunkcja, czy ograniczenia na dopuszczalne wartosci, tworzy sie koncepty i rela-

cje złozone. W logice opisowej ontologia dzieli sie na dwie czesci – „TBox” i „ABox”. Pierw-

sza z nich definiuje tak zwana terminologie, czyli ogólne, bardziej abstrakcyjne informacje o

dziedzinie, na przykład hierarchie i wzajemne zaleznosci miedzy konceptami. Druga zawiera

tak zwane asercje na temat swiata, czyli opisuje konkretne fakty dotyczace danej dziedziny,

takie jak umiejscowienie konkretnych jednostek w hierarchii konceptów, czy powiazania mie-

dzy nimi. Zazwyczaj jezyki oparte o logike opisowa wychodza z załozenia otwartego swiata –

prawdziwosc rzeczy, których nie znamy jest nieokreslona.

1.3 Przeglad jezyków reprezentacji wiedzy

Na potrzeby tej pracy, metody uzywane do reprezentacji wiedzy mozna umownie podzielic na

cztery generalne grupy. Pierwsza grupe stanowia klasyczne jezyki opisu ontologii. Druga grupe

stanowia technologie wspierajace idee sieci semantycznych (ang. Semantic Web) [8, 39, 91], a

trzecia grupe – jezyki programowania logicznego. Wreszcie, do ostatniej grupy mozna przypi-

sac jezyki modelowania, dla których podjeto próby ich zastosowania do reprezentacji wiedzy.

Ponizej zostanie omówione kilka klasycznych jezyków z pierwszej grupy, jezyk OWL jako

najpowszechniej uzywany przedstawiciel z pogranicza pierwszej i drugiej grupy, Prolog jako

przedstawiciel trzeciej, a takze jezyk UML [106, 88, 95] oraz notacje stosowane według zasad

podejscia Domain-Driven Design [28, 61] w ramach grupy czwartej. W opisach beda wykorzy-

stywane terminy omówione w poprzedniej czesci pracy, których nazwy beda dla wyróznienia

zapisywane kursywa.

1.3.1 KIF i Ontolingua

KIF [35] jest formatem opisu przeznaczonym do wymiany modeli pomiedzy róznymi syste-

mami wspierajacymi reprezentacje wiedzy, w oparciu o który powstał jezyk opisu ontologii

Ontolingua [29]. KIF umozliwia definiowanie obiektów, relacji i funkcji. Obiekty moga wy-

stepowac w jednym z dwóch typów – jako zbiory (ang. set) mogace posiadac przypisanych


RYSUNEK 1.1: Przykładowa definicja relacji w formacie KIF [35]

członków i jako jednostki nie majace takiej mozliwosci. W praktyce, pierwsze z tych pojec

ma znaczenie zblizone do konceptu, a drugie do instancji, gdzie powiazanie miedzy nimi od-

wzorowuje sie za pomoca członkostwa. Dodatkowo, kazdy z tych typów (zbiory i jednostki)

ma dwie wersje, które okreslaja, czy moze on byc obiektem przypisania jako członek. Pozwala

to uniknac pewnych paradoksów zwiazanych z teoria zbiorów. Same wyrazenia jezyka dziela

sie na cztery grupy – terminy (ang. terms), zdania (ang. sentences), reguły (ang. rules) i defi-

nicje (ang. definitions). Terminy wyszczególniaja obiekty wystepujace w opisywanej dziedzi-

nie. Zdania pozwalaja zapisac fakty na temat tej dziedziny. Reguły przedstawiaja dopuszczalne

kroki w procesie wnioskowania nowych informacji. Wreszcie definicje pozwalaja okreslic zda-

nia zawsze prawdziwe.

Domyslnie KIF wychodzi z załozenia otwartego swiata. Zawiera on natomiast specjalne

słowo kluczowe „consis”, pozwalajace okreslic wiedze domyslna, majaca zastosowanie w wy-

padku braku informacji wyrazonych za pomoca konkretnych elementów jezyka. Mechanizm

ten moze zatem zostac łatwo uzyty do odzwierciedlenia załozenia zamknietego swiata. Do je-

zyka KIF dołaczono w ramach nadbudowy, tzw. Frame-Ontology [37] umozliwiajaca specyfi-

kacje ontologii zgodnie z paradygmatem ram. Zawiera ona równiez dedykowane konstrukcje do

definiowania konceptów zwanych klasami (ang. class), instancji zwanych jednostkami (ang. in-

dividuals) czy wygodniejszego definiowania funkcji, a takze innych bardziej zaawansowanych

elementów, jak specjalizacji i kompozycji relacji, czy partycji klas. Jednakze, jako ze Frame-

Ontology jest mniej ekspresyjna niz pierwotny jezyk, Ontolingua umozliwia uzywanie jej jed-

noczesnie z wyrazeniami z jezyka KIF, dopuszczajac stosowanie zarówno osobno jednego jak i

drugiego jezyka oraz ich kombinacji.

Rysunek 1.1 pokazuje prosty przykład składni formatu KIF. Jak widac, jest to składnia czy-

sto tekstowa. Przykład definiuje jednoelementowa relacje bycia kawalerem jako koniunkcje jed-

noelementowych relacji bycia mezczyzna i nie bycia zonatym. Rysunek 1.2 pokazuje kolejny

przykład zapisany w składni formatu KIF, tym razem przedstawiajacy zdanie wykorzystujace

kwantyfikatory. Reprezentuje ono twierdzenie, ze kazdy autor jest niezrozumiany przez jakie-


RYSUNEK 1.2: Przykładowe zdanie w formacie KIF [37]

RYSUNEK 1.3: Przykładowa definicja klasy w jezyku Ontolingua [37]

gos czytelnika. Rozpoczyna sie od kwantyfikatora ogólnego przypisanego do zmiennej, która

pózniej okreslona jest jako autor. Nastepnie wystepuje implikacja i kwantyfikator szczegółowy

dla kolejnych dwóch zmiennych, reprezentujacych odpowiednio dokument i czytelnika. Wresz-

cie wystepuje suma zdan, które okreslaja, ze opisywany dokument jest napisany przez opisy-

wanego autora, a opisywany czytelnik czytał ów dokument i go nie zrozumiał.

Wykorzystanie składni KIF w obrebie jezyka Ontolingua zostało zaprezentowane na ry-

sunku 1.3. Przedstawia on wykorzystanie konstrukcji bedacych czescia Frame-Ontology do

zdefiniowania klasy reprezentujacej autora. Po nazwie klasy i jej opisie tekstowym wyszcze-

gólnione sa warunki, które kazdy autor musi spełniac. Musi on byc osoba, posiadac dokładnie

jedno imie typu „biblio-name”, które jest takie samo jak jego imie jako osoby oraz byc powia-

zany z co najmniej jednym dokumentem.

1.3.2 KL-ONE

KL-ONE [9, 109] jest jednym z jezyków majacych najwiekszy wpływ na pózniejszy rozwój

jezyków opisu ontologii. Bazuje on na paradygmacie opartym o ramy. Ontologie w tym jezyku


tworza koncepty opisywane za pomoca ról i opisów strukturalnych. Role okreslaja mozliwe

powiazania dotyczace instancji danego konceptu lub innych blisko powiazanych z nim koncep-

tów, takich jak na przykład te reprezentujace jego własciwosci lub czesci. Opisy strukturalne

okreslaja wzajemne zaleznosci pomiedzy rolami. Koncepty układaja sie w strukture oparta na

subsumcji – dany koncept subsumuje (ang. subsume) inny, jesli instancja pierwszego konceptu

jest zawsze instancja drugiego. Przykładowo, koncept „kot” subsumuje koncept „ssak”, ponie-

waz kazdy kot jest zawsze ssakiem. W praktyce tworzy sie w ten sposób odpowiednia takso-

nomia konceptów, a samo pojecie subsumcji zblizone jest do pojecia dziedziczenia w obiek-

towych jezykach programowania. Istotna cecha tej struktury jest jednak to, ze bardziej szcze-

gółowe koncepty zachowuja cała skomplikowana strukture powiazan konceptów ogólniejszych

– nie istnieje mozliwosc przedefiniowania tych relacji w bardziej szczegółowych konceptach.

Wymusza to precyzyjne konstruowanie ontologii i w razie potrzeby poleganie na wartosciach

domyslnych, zamiast na ograniczeniach mozliwych wartosci. O ile spodziewamy sie wartosci

domyslnych, o tyle w odróznieniu od ograniczen, moga istniec od nich wyjatki.

KL-ONE wyróznia wiele róznych rodzajów konceptów. Mamy wiec koncepty prymitywne

(ang. primitive), które nie sa w pełni zdefiniowane, oraz wywodzace sie z nich bardziej szcze-

gółowe koncepty okreslone (ang. defined), które juz posiadaja pełna definicje. Na przykład,

jesli potrzebujemy konceptu wielokata do definiowania bardziej szczegółowych figur, ale nie

chcemy wyszczególniac wszystkich wyrózniajacych go cech, mozemy go zdefiniowac jako

koncept prymitywny. Inny podział dzieli koncepty na koncepty ogólne (ang. generic) które

moga miec wiele instancji, oraz koncepty jednostkowe (ang. individual) uzywane do opisu po-

jedynczych jednostek, które moga posiadac tylko jedna instancje. Okreslone sa równiez reguły,

które musi spełniac dany koncept, aby byc uznanym za dobrze sformułowany – taki koncept

musi subsumowac wiecej niz jeden koncept, róznic sie od subsumowanego konceptu co naj-

mniej jednym ograniczeniem lub byc konceptem prymitywnym.

Jezyk KL-ONE uzywa wielu róznych notacji, zarówno graficznych jak i tekstowych, trak-

towanych jako odzwierciedlenie wspólnego abstrakcyjnego modelu. Rysunek 1.4 pokazuje za

pomoca jego notacji graficznej przykład okreslenia konceptu kobiety jako subsumujacego kon-

cept osoby z ograniczeniem na jedyna mozliwa przypisana płec jako zenska. Do reprezento-


RYSUNEK 1.4: Przykład dobrze zdefiniowanego konceptu w jezyku KL-ONE z[109]

wania konceptów wykorzystywane sa owale, a do reprezentowania roli wykorzystywane sa

kwadraty zawarte w kole. Koncepty łaczone sa ze zwiazanymi z nimi rolami przez proste linie,

natomiast strzałki prowadza od mniej do bardziej ogólnych elementów obydwu tych typów.

Wspomniana subsumcja jest wiec zaznaczona w przykładzie poprzez strzałke od owalu repre-

zentujacego koncept kobiety, do owalu reprezentujacego koncept osoby. Koncept kobiety jest

tez powiazany z kwadratem objetym kołem reprezentujacym role płec, który poprzez strzałke

ogranicza jej mozliwe wartosci do konceptu jednostkowego płci zenskiej reprezentowanego

przez kreskowany owal.

Kolejny, troche bardziej skomplikowany przykład, jest zaprezentowany na rysunku 1.5. Ko-

rzystajac z tej samej co poprzednio notacji, przedstawia on koncept osoby, której dzieci sa

doktorami. Koncept ten subsumuje koncept osoby posiadajacej dzieci, który z kolei subsumuje

koncept osoby. Koncept osoby posiadajacej dzieci jest opisany przez role dziecka opatrzona do-

datkowym zapisem, okreslajacym jej licznosc jako nie mniejsza niz jeden. Osoba, której dzieci

sa doktorami opisana jest natomiast przez szczególny przypadek tej roli, której wartosci ogra-

niczone sa tylko do doktorów.

1.3.3 FLogic

FLogic [48, 47, 2], którego nazwa jest skrótem od „Frame Logic”, jest jezykiem reprezentacji

wiedzy opartym na ramach. Pierwotnie został stworzony na potrzeby dedukcyjnych baz danych,


RYSUNEK 1.5: Przykład konceptu z ograniczeniem nałozonym na role w jezykuKL-ONE z [109]

ale pózniej znalazł szersze zastosowanie w reprezentacji wiedzy. Podstawowym elementem je-

zyka sa koncepty zwane obiektami, opisywane przez zmienne odnoszace sie do nastepnych

obiektów. FLogic nie wprowadza rozróznienia na poziomie typów miedzy konceptami a ich

instancjami. Kazdy obiekt moze miec instancje, a dziedziczenie reprezentuje sie traktujac klasy

potomne jako instancje rodziców. Nie wystepuje równiez rozróznienie pomiedzy relacjami a

konceptami, gdzie kazdy obiekt moze byc traktowany jako jedno lub drugie, zaleznie od sytu-

acji. FLogic umozliwia takze definiowanie aksjomatów w postaci zdan zwanych regułami, które

pozwalaja wyprowadzac nowe informacje.

Przykładowy fragment modelu w jezyku FLogic został przedstawiony na rysunku 1.6. Defi-

niuje on, uzywajac składni tekstowej, obiekt „pracownik naukowy”. Obiekt ten opisywany jest

przez przypisanego mu innego pracownika jako nadzorcy i przypisany mu jako wiek – wiek

sredni. Definiuje równiez, bedacy instancja poprzedniego obiektu obiekt „mary” o przypisanym

imieniu „Mary”, przypisanym wieku „30” i posiadajacy przypisanych jako przyjaciół obiekty

„bob” i „sally”.


RYSUNEK 1.6: Fragment modelu w jezyku FLogic [47]

RYSUNEK 1.7: Fragment modelu w jezyku FLogic - składnia alternatywna [2]

Kolejny przykład, wykorzystujacy nowsza wersje składni omawianego jezyka, został przed-

stawiony na rysunku 1.7. Rozpoczyna sie on od definicji mezczyzny jako instancji osoby. Na-

stepnie wystepuja definicje atrybutów syn i ojciec, przypisanych do obiektu osoby. Obydwa te

atrybuty sa typu mezczyzna, w dodatku pierwszy z nich ma okreslona dopuszczalna licznosc

od 0 do 1. Ostatnim elementem jest reguła mówiaca, ze jesli dany element jest ojcem drugiego

elementu o typie mezczyzna, to ten drugi element jest dla pierwszego synem.

1.3.4 LOOM

Loom [59, 57, 56] jest jezykiem reprezentacji wiedzy bazujacym zarówno na ramach, jak i lo-

gice opisowej. Jest on zaliczany do rodziny jezyków inspirowanych jezykiem KL-ONE. Zgod-

nie z paradygmatem logiki opisowej, wychodzi on z załozenia otwartego swiata i dzieli on prze-

strzen wiedzy na ABox i TBox. Dodatkowo wyróznione sa dwie przestrzenie – Universal Box

i Default Box. W jezyku Loom, przestrzen TBox powinna zawierac tylko takie informacje na

temat opisywanych rzeczy, które sa jednoczesnie konieczne i wystarczajace do ich zdefiniowa-

nia. Stad tez, Universal Box przeznaczony jest do wyrazania wszelkich pozostałych informacji

o terminologii. Przykładowo, mozemy w nim zdefiniowac, ze wszyscy zywi ludzie posiadaja

głowy, co jest warunkiem koniecznym, lecz niewystarczajacym do bycia człowiekiem. Mozemy

tez zdefiniowac, ze wszystkie dwunogi nie posiadajace piór to ludzie, co z kolei jest warunkiem

wystarczajacym, lecz nie jest warunkiem koniecznym.

Default Box natomiast okresla wszelkie domyslne informacje na temat instancji, czyli do-

myslne wartosci, które nalezy przyjac, jesli dana wartosc nie została zdefiniowana. Przykła-


RYSUNEK 1.8: Przykładowy kod w jezyku Loom [57]

dowo, mozemy zdefiniowac, ze typowa liczba konczyn dla ssaka to cztery. Pozwala to równiez

odzwierciedlic – w razie potrzeby – w ograniczonym stopniu załozenie zamknietego swiata.

Loom, podobnie jak jezyk KL-ONE silnie bazuje na mechanizmie subsumcji i zgodnie z para-

dygmatem opartym na ramach grupuje informacje na temat poszczególnych opisywanych rze-

czy. Podstawowymi elementami w jezyku sa koncepty, relacje i instancje. Loom wyróznia takze

pojecie roli, okreslajace relacje silnie powiazana z danym konceptem. Równiez, analogicznie

jak w jezyku KIF, koncepty dziela sie na prymitywne i okreslone.

Jezyk Loom wykorzystuje tekstowa składnie oparta o jezyk LISP [103, 92], opisujaca po-

szczególne elementy wystepujace w jezyku za pomoca szeregu ujetych w nawiasy polecen.

Dwa podstawowe z nich, słuzace definiowaniu elementów przypisanych do przestrzeni TBox,

jakimi sa koncepty i relacje, to odpowiednio „defconcept” i „defrelation”. Kazde z tych pole-

cen okresla nazwe opisywanego elementu oraz dodatkowo zawiera szereg dokładniej okresla-

jacych słów kluczowych poprzedzonych dwukropkami. Moga one równiez dodatkowo odnosic

sie do innych elementów lub wykorzystywac dalsze słowa kluczowe, w razie potrzeby zawarte

w nawiasach, gdy odnosza sie do wiekszej liczby elementów. Do specyfikowania konkretnych

informacji dotyczacych instancji w przestrzeni ABox stosuje sie natomiast polecenie „tell”, o

zblizonej strukturze do tych wczesniej opisanych.

Rysunek 1.8 pokazuje przykładowy prosty kod w jezyku Loom. Zaczyna sie on od definicji

z zakresu TBox, okreslajacych koncepty urzadzenia, mechanicznej reki oraz wreszcie robota

jako urzadzenia bedacego w relacji posiadania reki w stosunku do dwóch mechanicznych rak.

Definiuje równiez relacje posiadania reki, mogaca wystepowac pomiedzy robotem, a mecha-

niczna reka. Nastepnie przedstawione jest stwierdzenie z zakresu ABox okreslajace Robby’ego

jako urzadzenie, które jest w relacji posiadania reki z reka 1 i reka 2. W praktyce – jak wynika

z poprzednich reguł – mozemy wywnioskowac, ze jest to urzadzenie bedace robotem.


RYSUNEK 1.9: Przykładowy kod w jezyku Loom [56]

Kolejny przykładowy fragment kodu został przedstawiony na rysunku 1.9. Definiuje on

relacje rany („injuries”), okreslona jako charakterystyka i interpretowana na zasadach zamknie-

tego swiata. Nastepnie definiuje dwa szczególne przypadki tej relacji jakimi sa ciezkie rany

(„primary-injuries”) i lekkie rany („secondary-injuries”), okreslone poprzez odpowiednie za-

kresy wartosci. Wreszcie zdefiniowane sa dwa koncepty – rannej osoby („casualty”) jako osoby

posiadajacej co najmniej jedna rane i ciezko rannej osoby („critical-casualty”) jako osoby po-

siadajacej co najmniej jedna ciezka rane.

1.3.5 OCML

OCML [75, 53], którego nazwa jest skrótem od „Operational Concept Modelling Language”,

jest jezykiem opartym o ramy, kładacym duzy nacisk na wykonywalnosc powstałych modeli.

Umozliwia on okreslanie klas opisanych przez klatki zgodnie z tradycyjnym paradygmatem

opartym na ramach, jak równiez ich instancji oraz relacji i funkcji. Do odrózniania relacji i

funkcji jest przywiazywana szczególna waga ze wzgledu na rózne rodzaje operacji z nimi zwia-

zane. Relacje moga byc sprawdzane, badz moga byc wykonywane na ich podstawie zapytania,

natomiast na podstawie funkcji generuje sie ich wartosci. Mozliwe jest równiez definiowanie

procedur dla rzeczy, których nie da sie odzwierciedlic za pomoca funkcji, jak i reguł pozwa-

lajacych na wnioskowanie nowych informacji. Jezyk OCML jest wspierany przez srodowisko

TMDA [76], które wyróznia cztery rodzaje informacji – wiedze o zadaniu, wiedze o metodzie

rozwiazania problemu, wiedze domenowa i wiedze specyficzna dla aplikacji. W zwiazku z tym,

OCML umozliwia równiez specyfikowanie zadan i metod oraz mapowanie dotyczacych ich po-

jec na pojecia na poziomie opisu dziedziny. Ontologie w jezyku OCML budowane sa w oparciu

o bazowa ontologie OCML składajaca sie z dwunastu ontologii składowych. Okreslaja one

miedzy innymi podstawowe definicje reprezentujace podstawowe typy danych i wykonywane


RYSUNEK 1.10: Przykładowy kod klas i instancji w jezyku OCML [53]

RYSUNEK 1.11: Przykładowy kod procedury w jezyku OCML [75]

na nich operacje, a takze umozliwiaja reprezentacje klas w oparciu o ramy.

Składnia jezyka OCML ma forme tekstowa i oparta jest o makra w jezyku LISP. W ogólnym

zarysie przypomina opisana wczesniej składnie wykorzystywana przez jezyk Loom. Zawiera

jednak równiez sekwencje sterujace, takie jak petle, które moga byc wykorzystane podczas defi-

niowania procedur. Rysunek 1.10 przedstawia fragment przykładowego kodu w jezyku OCML.

Definiuje on na poczatku ogólna klase reprezentujaca uczestnika laboratorium YQT opisanego

przez szereg klatek, okreslajacych miedzy innymi, czy reprezentowana osoba jest palaczem, z

kim współpracuje, w jakich projektach uczestniczy i do jakich grup badawczych nalezy. Na-

stepnie jest zdefiniowana klasa badacza bedaca szczególnym przypadkiem uczestnika YQT. Na

koniec, zawarta jest definicja instancji badacza Harrego C., wraz z miedzy innymi okresleniem,

ze nie jest on palaczem, uczestniczy w projekcie Babylon i współpracuje z Jurgenem i Thoma-

sem.

Kod przykładowej procedury w jezyku OCML został natomiast przedstawiony na rysunku


1.11. Realizuje ona operacje nadania wartosci „v” klatce „s” dla instancji „i”. Na poczatku zade-

klarowany jest warunek, który musi byc spełniony, zeby procedura była mozliwa do wykonania

– klasa do której nalezy instancja „i” musi miec odpowiedni slot „s”. Dalej zadeklarowane sa juz

same działania składajace sie na procedure, czyli usuniecie wszelkich przypisanych wczesniej

do klatki wartosci i przypisanie do niej wartosci „v”.

1.3.6 OWL

OWL [40, 64, 5, 102], czyli Web Ontology Language, został stworzony z mysla o wdrozeniu

idei sieci semantycznych – wprowadzenia standardów opisywania informacji w sieci, który

umozliwiałby automatyczne ich przetwarzanie z uwzglednieniem ich znaczenia. Stanowi on

rozszerzenie standardu RDF [55, 50]. Standard ten słuzy opisywaniu zasobów za pomoca meta-

danych przedstawionych jako uporzadkowane trójki. Pierwszy element kazdej z trójek wskazuje

na opisywany podmiot, drugim jest predykat definiujacy opisywana ceche lub aspekt, a trzecim

– wartosc stanowiaca opis. Przykładowo, podmiot wskazujacy na artykuł „OWL: Web Ontology

Language” mógłby byc opisany predykatem „autor” i wartoscia „Sean Bechhofer”. RDF jest

typowo przechowywany w formacie XML [11].

OWL rozbudowuje opisany zapis, definiujac w oparciu o niego jezyk reprezentacji wiedzy,

umozliwiajacy budowanie pełnoprawnych ontologii. Zgodnie ze specyfikacja [74], składaja sie

na niego elementy trzech róznych typów – byty (ang. entities), wyrazenia (ang. expressions)

i aksjomaty. Byty obejmuja klasy, jednostki i własciwosci. Klasy standardowo reprezentuja

pewne kategorie rzeczy wyróznione na podstawie wspólnych cech, a jednostki konkretnych

ich przedstawicieli. Własciwosci sa uzywane do opisu klas i moga przyjac jedna z dwóch form

– własnosci obiektów (ang. object properties) i własnosci typów danych (ang. datatype pro-

perties). Pierwsze z nich reprezentuja powiazania miedzy poszczególnymi jednostkami, nato-

miast drugie wiaza z jednostkami wartosci o konkretnym typie danych, choc ta róznica lekko

sie zaciera w wersjach jezyka dopuszczajacych traktowanie wartosci jako jednostek. Dodat-

kowo, istotnym ograniczeniem zwiazanym z tym typem elementów w jezyku OWL, jest brak

mozliwosci odwzorowania relacji wieloelementowych. Wyrazenia pozwalaja odwzorowac bar-

dziej skomplikowane charakterystyki klas i własnosci. Dzieki nim mozna – miedzy innymi –


RYSUNEK 1.12: Przykładowy kod w jezyku OWL [40]

RYSUNEK 1.13: Przykładowy definicja klasy w jezyku OWL [102]

definiowac poszczególne klasy za pomoca innych klas, czy nałozyc ograniczenia na mozliwe

przypisania własnosci. Wreszcie aksjomaty słuza do definiowania twierdzen, które sa zawsze

prawdziwe w danej dziedzinie. Pozwalaja one wprost na okreslenie zarówno ogólnych zalezno-

sci miedzy klasami i własnosciami, jak i na zadeklarowanie konkretnych faktów o jednostkach.

Podsumowujac, opis jest w wiekszosci analogiczny do tych stosowanych w jezykach opisu on-

tologii nie powiazanych z sieciami semantycznymi. Mozna wrecz – mimo pewnych róznic w

terminologii – powiedziec, ze jezyk OWL jest przedstawicielem jezyków bazujacych na logice

opisowej. Natomiast cecha wyrózniajaca ten jezyk, zaczerpnieta z jezyka RDF, jest fakt, ze

wszystkie byty sa równiez dodatkowo identyfikowane za pomoca IRI (International Resource

Identifiers) [25]. Moga sie zatem odnosic do konkretnych zasobów w sieci Web.

Przykładowy kod jezyka OWL pokazany na rysunku 1.12 zawiera definicje dwóch klas.

Definicja po lewej stronie okresla przedstawicieli klasy bezdzietnych osób jako jednoczesnie

bedacych osoba i nie bedacych rodzicem. Definicja po prawej stronie okresla przedstawicieli

klasy „sierota”, jako spełniajacych warunek posiadania relacji bycia dzieckiem tylko w sto-

sunku do jednostek które sa martwe.

Kolejny przykład zaprezentowany na rysunku 1.13 przedstawia fragment definicji klasy

„wino”. Okreslona jest ona jako podklasa klasy „pitny płyn”. Dodatkowo nałozone jest na nia


ograniczenie odzwierciedlajace, ze kazde wino musi byc zrobione z co najmniej jednego wino-

grona, czyli kazda instancja tej klasy musi poprzez odpowiednia własciwosc byc powiazana z

co najmniej jedna instancja klasy reprezentujacej winogrona.

1.3.7 Prolog i A-Prolog

Prolog [17][10] jest jezykiem do programowania logicznego, czesto wykorzystywanym do za-

gadnien z pogranicza sztucznej inteligencji, w tym reprezentacji wiedzy. Programy w Prologu

składaja sie z opisu relacji reprezentowanych przez klauzule Horna [41], zapisane w formie

implikacji w zapisie odwrotnym, czyli przyjmujacych forme typu p← r∧q. Formuły logiczne

zarówno w poprzedniku jak i nastepniku implikacji zawieraja predykaty. Rozrózniane sa dwa

rodzaje klauzul w zaleznosci od zawartosci poprzednika implikacji. Klauzule z pustym poprzed-

nikiem nazywamy faktami, a posiadajace formuły logiczne w poprzedniku – regułami. Prolog

wychodzi z załozenia zamknietego swiata, co oznacza, ze predykatom w trakcie interpretacji

bedzie przypisana jedna z dwóch wartosci – prawda lub fałsz.

W praktyce oznacza to, ze programy w Prologu składaja sie z deklaracji dwóch typów. De-

klaracje pierwszego typu opisuja relacje uznane za prawdziwe i przyjmuja forme predykatów,

składajacych sie z nagłówka zawierajacego nazwe relacji i zawartych w nawiasie jej argumen-

tów. Argumentami w tego typu deklaracjach moga byc tylko stałe. Deklaracje drugiego typu

zawieraja dodatkowo po znaku „:-” zbiór warunków, okreslajacy, kiedy dana relacja jest praw-

dziwa. Zbiór ten składa sie typowo z predykatów połaczonych operatorami logicznymi. Argu-

menty w tego typu deklaracjach moga oprócz stałych zawierac równiez zmienne, pod które w

trakcie interpretacji podstawiane sa okreslone dowolnie stałe. Nazwy stałych w Prologu zapisy-

wane sa mała litera, a nazwy zmiennych – wielka. Opisany mechanizm pozwala na reprezento-

wanie wiedzy dziedzinowej, traktujac argumenty predykatów na zasadzie zblizonej do instancji

i reprezentujac przynaleznosc do konceptów za pomoca relacji.

Dla potrzeb reprezentacji wiedzy stosuje sie równiez tzw. A-Prolog lub AnsProlog [33, 34]

(skrót od „Answer Set Programming in Logic”). Jest to jezyk bazujacy na składni jezyka Prolog

i o zblizonej do niego czysto deklaratywnej semantyce, która jest jednak zdefiniowana nieza-

leznie od konkretnego mechanizmu wnioskujacego. Jezyk ten wychodzi z załozenia otwartego


RYSUNEK 1.14: Przykładowy kod w jezyku Prolog [10]

RYSUNEK 1.15: Przykładowy kod w jezyku A-Prolog [34]

swiata, dopuszczajac oprócz wartosci oznaczajacych prawde i fałsz, równiez zwracanie war-

tosci nieokreslonej – „unknown”. Słuzy on odzwierciedlaniu logiki niemonotonicznej, czyli

prowadzacej do tymczasowych wniosków, które moga ulegac zmianie na podstawie nowych

danych. Wprowadza mechanizm definiowania domyslnych cech, które sa wykorzystywane, je-

sli nie zostały zadeklarowane odpowiednie wyjatki. W tym celu dokonane jest rozróznienie

pomiedzy operatorem „-” oznaczajacym, ze dany predykat jest fałszywy, a operatorem „not”,

który obejmuje równiez brak informacji na temat prawdziwosci danego predykatu.

Przykładowy fragment kodu w jezyku Prolog przedstawiony jest na rysunku 1.14. Definiuje

on przechodnia relacje bycia przodkiem, za pomoca rekurencji i relacji bycia rodzicem. Podaje

tez dwa fakty dotyczace zachodzenia relacji bycia rodzicem, pomiedzy osobami reprezentowa-

nymi przez stałe „matthew”, „joshua” i „david”. Na tej podstawie mozna wyciagnac wnioski

o zachodzeniu relacji bycia przodkiem pomiedzy nimi, w oparciu o wspomniana definicje tej

relacji.

Przykładowy kod w jezyku A-Prolog przedstawiony jest natomiast na rysunku 1.15. Roz-

poczyna sie on od powiazania stałych „sam” i „bob” relacja „member” z elementem oznaczo-

nym jako „cs”. Reprezentowac ma to przypisanie nauczycieli akademickich o owych imionach

do wydziału informatyki (ang. Computer Science). Nastepne dwie linijki łacza stałe „java”

i „ai”, reprezentujace przedmioty, relacja „course” z tym samym wydziałem. Mamy równiez


zdefiniowane przypisanie Javy z Samem oraz AI z Bobem, za pomoca relacji „teaches”, repre-

zentujacej prowadzenie danego przedmiotu. Na koniec, wykorzystany jest charakterystyczny

dla A-Prologa opisany wczesniej mechanizm, umozliwiajacy okreslenie, ze zarówno relacja

„member”, jak i relacja „teaches” działaja według zamknietego swiata. Mozna to ujac w ten

sposób, ze jesli nie jest okreslone, ze ktos nalezy do danego wydziału – to do niego nie nalezy.

Natomiast, jesli nie jest okreslone, ze ktos prowadzi dany przedmiot – to go nie prowadzi.

1.3.8 UML

Jezyk UML [106, 88, 95] (ang. Unified Modeling Language) jest graficznym jezykiem mode-

lowania ogólnego przeznaczenia, powstałym jednak głównie z mysla o modelowaniu oprogra-

mowania. Oferuje on szereg diagramów pozwalajacych na przedstawienie zarówno aspektów

statycznych jak i dynamicznych modelowanych zagadnien. Miedzy innymi ze wzgledu na jego

duza popularnosc pojawiły sie równiez próby jego wykorzystywania do reprezentowania on-

tologii [21, 24]. Typowe sposoby realizacji tego zagadnienia obejmuja bezposrednie wykorzy-

stanie podzbioru elementów wystepujacych na diagramach klas lub tworzenie osobnych profili

jezyka UML przeznaczonych do tego celu. W obydwu przypadkach stosunkowo prosto jest

przedstawic koncepty za pomoca klas, czy instancje za pomoca obiektów, niezaleznie czy sto-

sujemy je bezposrednio, czy dostosowujemy je za pomoca odpowiednich stereotypów.

Pewien problem w jezyku UML sprawia odzwierciedlenie relacji. Jezyk UML zawiera wiele

elementów o zblizonym znaczeniu, wymieniajac chocby asocjacje, czy atrybuty. Jednakze za-

den z nich nie moze istniec lub byc reprezentowany niezaleznie od innych elementów, takich

jak klasy, co czesto jest cecha pozadana przy reprezentowaniu wiedzy. Co wiecej, jezyk UML

nie umozliwia okreslenia szczegółowych zasad rzadzacych takimi relacjami. Podobnie, nie ma

mozliwosci wyrazania informacji, typowo zapisywanych jako aksjomaty, czy tez definiowa-

nia innych niz dziedziczenie (specjalizacja) warunków, bardziej szczegółowo opisujacych kon-

cepty. Problemy te musza byc wiec rozwiazywane poprzez wprowadzanie nowych notacji w

obrebie profili lub uzupełnianie graficznych modeli jezyka UML o adnotacje w jezyku OCL

[107].


1.3.9 Domain-Driven Design

Domain-Driven Design [28, 61], okreslane skrótowo jako DDD, jest podejsciem do tworzenia

oprogramowania, ułatwiajacym projektowanie systemów w sytuacjach, kiedy dziedzina, której

system dotyczy, charakteryzuje sie duzym stopniem skomplikowania. Zakłada ono, ze struktura

i zachowanie elementów realizujacych logike dziedzinowa powinny wiernie odzwierciedlac te

wystepujace w rzeczywistosci. Z tego wzgledu, zestaw wzorców uzywanych do opisu dziedziny

w tym podejsciu mozna potraktowac jako swego rodzaju prosty jezyk reprezentacji wiedzy.

Podstawowymi wzorcami uzywanymi do opisu dziedziny według DDD sa byty (ang. entities),

obiekty reprezentujace wartosci (ang. value objects), serwisy (ang. services) i agregaty (ang.

aggregates). Byty reprezentuja obiekty posiadajace okreslona, unikalna tozsamosc, która pozo-

staje niezmienna w trakcie działania systemu. Obiekty reprezentujace wartosc odzwierciedlaja

natomiast elementy nie posiadajace tozsamosci i identyfikowane tylko na podstawie wartosci,

która reprezentuja. Przykładowo, jako byt mozna potraktowac pojecie osoby, natomiast jako

obiekt reprezentujacy wartosc – jej imie. Agregaty grupuja byty i obiekty reprezentujace war-

tosci w jednostki, traktowane jako całosc z punktu widzenia ich cyklu zycia. Kazdy agregat

posiada byt bedacy jego korzeniem. Do elementów przypisanych do agregatu mozna odwoły-

wac sie jedynie za posrednictwem jego korzenia. Przykładowo, dla pojecia osoby mozna by

stworzyc agregat, w którym to pojecie byłoby korzeniem. Agregat ten grupuje wszelkie dane

zwiazane z konkretna osoba, w tym jej imie. Warto równiez zauwazyc, ze agregaty moga za-

wierac inne agregaty.

Serwisy w podejsciu DDD odpowiadaja operacjom, których nie da sie przypisac do zadnego

pojedynczego bytu lub obiektu reprezentujacego wartosc. Ze wzgledu na dostosowanie DDD

do paradygmatu programowania obiektowego, sa one wyróznione jako osobne elementy, do

których owe operacje sa przypisane. Na przykład, jesli uwazamy, ze operacja wykonania prze-

lewu nie pasuje ani do konta docelowego, ani do konta zródłowego, mozemy ja przedstawic za

pomoca serwisu. Do podstawowych wzorców zalicza sie równiez repozytoria (ang. repository)

i fabryki (ang. factory), ale nie maja one w wiekszosci przypadków bezposredniego zastosowa-

nia w modelowaniu dziedziny. Dodatkowo, DDD wykorzystuje równiez szereg innych wzorców

uzywanych miedzy innymi do wyodrebniania algorytmów realizujacych istotne reguły bizne-

1.4. Analiza porównawcza jezyków reprezentacji wiedzy 25

sowe (polisa – ang. policy), odzwierciedlania złozonych kryteriów (specyfikacja – ang. spe-

cification) oraz reprezentowania istotnych zdarzen biznesowych (zdarzenie – ang. event), czy

całych złozonych procesów (saga). Jednak na poziomie odwzorowania dziedziny wzorce te

moga posłuzyc jedynie do wyróznienia istnienia takich elementów, jako ze DDD nie definiuje

sposobu reprezentowania reguł ich opisujacych. Warto podkreslic, ze istotnym mankamentem

dotyczacym wykorzystania DDD do reprezentowania wiedzy jest brak sformalizowanej składni

do przedstawiania elementów i zaleznosci miedzy nimi.

1.4 Analiza porównawcza jezyków reprezentacji wiedzy

Podsumowanie poszczególnych jezyków reprezentacji wiedzy w oparciu o opisane wczesniej

pojecia zostało przedstawione w tabeli 1.1. Pokazuje ona, w jaki sposób wymienione na po-

czatku elementy, z których typowo składaja sie ontologie reprezentowane sa w poszczególnych

omówionych jezykach. Aby jednak własciwie ocenic mozliwosc ich wykorzystania do repre-

zentacji wiedzy na poziomie specyfikacji wymagan i generacji z niej kodu, trzeba najpierw

zdefiniowac wymagania, jakie w tym celu powinny te jezyki spełniac. Mechanizmy automa-

tycznego wnioskowania powiazane z czescia jezyków sa z reguły trudne do bezposredniego

przełozenia na mechanizmy generacji kodu. Wymagania beda zatem dotyczyły głównie składni

wykorzystywanej do reprezentacji wiedzy. Istotna jest tutaj zarówno mozliwosc odzwierciedle-

nia poszczególnych rodzajów informacji opisujacych dziedzine, jak i cechy sprawiajace, ze opis

dziedziny jest mniej lub bardziej zrozumiały nawet dla osób nie posiadajacych specjalistycznej

wiedzy z zakresu inzynierii oprogramowania.

W pierwszej kolejnosci potrzebujemy, aby jezyk miał mozliwosc odwzorowania wszelkich

pojec wystepujacych w opisie dziedziny, wraz z opisujacymi je cechami i powiazaniami które

je łacza. Konieczna jest jednak równiez mozliwosc zdefiniowania reguł i ograniczen je opisu-

jacych oraz współzaleznosci miedzy nimi w taki sposób, aby było mozliwe ich automatyczne

przetwarzanie. Jezyk musi równiez pozwalac na odzwierciedlanie dynamicznych zaleznosci

miedzy pojeciami, w tym rozmaitych przekształcen, którym moga one podlegac. Wliczaja sie

w to równiez wszelkiego rodzaju algorytmy wykonujace operacje na danych lub obliczenia. Co


TABLICA 1.1: Reprezentacja poszczególnych rodzajów elementów w jezykachreprezentacji wiedzy

Koncepty Relacje Instancje AksjomatyKIF obiekty o typie

zbiorurelacje i funkcje obiekty o typie

jednostkidefinicje, reguły

KL-ONE koncepty role instancje -FLogic obiekty obiekty obiekty regułyLOOM koncepty relacje instancje (jako czesc

opisu innychelementów)

OCML klasy relacje i funkcje instancje regułyOWL klasy jednostki własciwosci aksjomatyProlog - relacje stałe predykatyUML klasy asocjacje (cze-

sciowo)obiekty -

DDD byty - - -

wiecej, nie wystarczy sama mozliwosc specyfikowania tego typu informacji. Powinny one byc

takze przedstawione w sposób, który w sposób przejrzysty odda rzadzace nimi zasady. Umoz-

liwi to uzgadnianie szczegółów ich dotyczacych z osobami dobrze znajacymi dziedzine, ale nie

posiadajacymi wykształcenia informatycznego. Oznacza to, ze składnia jezyka powinna przed-

stawiac zagadnienia w sposób oddajacy ich istote, a przy okazji jak najbardziej zrozumiały dla

zwykłych osób. Dodatkowym istotnym wymaganiem, jest załozenie, ze taki jezyk powinien

posiadac reprezentacje graficzna. Zwiazane to jest z tym, ze reprezentacja taka pozwala na bez-

posrednie odwzorowywanie bardziej złozonych powiazan. Ułatwia ona tworzenie reprezentacji

mentalnych rozwazanych zagadnien i sprzyja lepszemu zrozumieniu przez mniej doswiadczo-

nych uzytkowników [78, 54, 22].

Spełnienie powyzszych wymagan przez analizowane jezyki zostało przedstawione w tabeli

1.2. Dla ustalenia uwagi, w tabeli skupiono sie na ocenie reprezentacji poszczególnych ele-

mentów składowych jezyków. Jak mozna zaobserwowac, zaden z rozpatrywanych jezyków nie

spełnia wszystkich opisanych wymagan. Wszystkie jezyki specyfikowania ontologii pozwalaja

na definiowanie pojec i relacji oraz opisywanie ich w sposób, który umozliwi uwzglednianie

ich znaczenia. Natomiast, jedynie OCML i do pewnego stopnia LOOM umozliwiaja odwzo-

rowywanie bardziej skomplikowanych algorytmów. Nawet jednak w ich wypadku forma tego


TABLICA 1.2: Spełnianie wymagan przez analizowane jezyki

Definiowaniepojec i rela-cji

Przetwarzalnyopis pojec irelacji

Funkcjonalnyopis algoryt-mów

Koncepcyjnyopis algoryt-mów

Składniagraficzna

KIF + + - - -KL-ONE + + - - +/-FLogic + + - - -LOOM + + +/- - -OCML + + + - -OWL + + - - -Prolog +/- +/- +/- - -UML + - - + +DDD +/- - - - +/-

przedstawienia nie jest dostosowana do odzwierciedlania idei stojacych za algorytmami. W oby-

dwu wypadkach jezyki stosuja czysto tekstowa składnie oparta na jezyku programowania LISP,

która jest mało przyjazna dla mniej wykwalifikowanych uzytkowników. Jedynym jezykiem z

rozwazanej grupy, posiadajacym jakakolwiek reprezentacje graficzna jest jezyk KL-ONE. Jed-

nak nawet w jego przypadku, jak przyznaje nawet jeden z autorów [109], pełni ona role pomoc-

nicza. Staje sie ona szybko nieczytelna wraz ze wzrostem rozmiaru przedstawianego fragmentu

modelu. Sytuacja jezyka Prolog jest w zasadzie podobna do jezyków specyfikowania ontologii,

z tym, ze odwzorowanie poszczególnych elementów wymaga w nim dodatkowej pracy. Wynika

to z braku z góry zdefiniowanych bardziej złozonych struktur, które pozwoliłyby definiowac

nietrywialne elementy (np. pojecia z atrybutami) o okreslonym znaczeniu.

Dla odmiany, jezyk UML posiada graficzna składnie i pozwala przedstawiac zarówno po-

jecia i relacje, jak i koncepcje algorytmów. Problemem tutaj natomiast jest brak dostepnych w

jezyku mozliwosci zdefiniowania szczegółów opisujacych przedstawione elementy w sposób,

który umozliwiłby ich automatyczne przetwarzanie. Sytuacja jezyka wykorzystywanego w po-

dejsciu DDD jest w zasadzie zblizona. Mozna zauwazyc, ze poszczególne elementy modelu

dziedzinowego sa tutaj nieco lepiej doprecyzowane, niz w jezyku UML. Nadal nie ma jed-

nak mozliwosci okreslenia wielu istotnych informacji, mozliwych do przedstawienia jezykami

z poprzednich grup. Zakres mozliwych do przedstawienia elementów jest stosunkowo ogra-

niczony. Opis dziedziny w podejsciu DDD nie zawiera elementów, które nie przekładaja sie


bezposrednio na architekture aplikacji. Nie daje to mozliwosci odzwierciedlenia detali wielu

dynamicznych aspektów dziedziny. Równiez, jak było wspomniane przy okazji opisu tego po-

dejscia, choc typowo dziedzine na potrzeby DDD modeluje sie graficznie, to nie istnieje zaden

formalny standard zapisu.

Podsumowujac, mozna powiedziec, ze zaden z przedstawionych jezyków nie oferuje wy-

starczajacego przystosowania do reprezentacji wiedzy dziedzinowej na poziomie specyfikacji

wymagan dla systemu oprogramowania. Wynika to posrednio z róznicy miedzy charakterystyka

zadan dla których te jezyki były tworzone, a ta zwiazana z rozpatrywanym zagadnieniem. Ze-

stawienie tych róznic zostało przedstawione w tabeli 1.3. Celem jezyków specyfikacji ontologii

jest przedstawianie ludzkiej wiedzy w sposób, który bedzie zrozumiały dla systemów kompute-

rowych i dajacy mozliwosc wnioskowania na biezaco w oparciu o ta wiedze, podobnie jak czy-

nia to ludzie. Czytelnosc i zrozumiałosc takich jezyków jest brana pod uwage głównie z punktu

widzenia efektywnosci ich wykorzystania przez specjalistów od reprezentowania wiedzy, niz

przez ekspertów dziedzinowych. Ponadto, wszelkie konieczne do rozwiazania problemu dane

sa podawane w obrebie jezyka i z reguły nie ma potrzeby przetwarzania ich zaawansowanymi

algorytmami.

Jezyki modelowania słuza natomiast uproszczonemu przedstawianiu złozonych zagadnien,

wyrózniajac rzeczy istotne, a ignorujac nieistotne, co ułatwia zrozumienie owych zagadnien

przez ludzi. Posiadaja one z reguły ogólnie zrozumiała reprezentacje graficzna, ale systemy

komputerowe najczesciej posiadaja jedynie wiedze na temat poprawnosci ich składni, a nie se-

mantyki. Nawet w wypadku automatycznego przetwarzania takich jezyków w powiazaniu z

podejsciem MDA, zakres informacji interpretowanych w oparciu o ich znaczenie jest znacznie

mniejszy, niz w poprzedniej grupie. Modele w tych jezykach najczesciej abstrahuja od konkret-

nych danych, a wszelkie algorytmy przedstawiane sa w sposób, który umozliwia zrozumienie

ich przebiegu przez ludzi. Jest on jednak niewystarczajaco szczegółowy, zeby posłuzyc do prze-

twarzania automatycznego przez system komputerowy.

Wezmy teraz pod uwage wymagania dla specyfikowania wiedzy na potrzeby generacji kodu

(ostatnia koluman w tabeli 1.3). Mozna zauwazyc, ze sytuacja jest zarazem inna niz w obydwu

powyzszych grupach jezyków, jak i posiada wiele elementów z nimi wspólnych. Mozna wrecz


TABLICA 1.3: Porównanie podejsc zwiazanych z specyfikacja wiedzy

Jezyki modelowania Jezykispecyfikowaniaontologii

Wymagania dlajezyka

Natura Przyblizoneodzwierciedleniewybranego aspekturzeczywistosci

Formalnareprezentacjakonceptualizacjiwiedzy z wybranejdziedziny

Reprezentacja regułumozliwiajacychprzetwarzaniedanych

Cel Przedstawieniezłozonych zagadnienw sposóbzrozumiały dla ludzi

Przedstawieniewiedzy w sposóbzrozumiały dlasystemówkomputerowych

Przedstawieniewiedzy w sposóbzrozumiały zarównodla ludzi jak i dlasystemówkomputerowych

Zastosowanie Ułatwieniezrozumieniaskomplikowanychzagadnien

Wnioskowanie nabazie zgromadzonejwiedzy

Generacja kodurealizujacego logikedziedzinowamozliwego dozintegrowaniazreszta systemu

Przetwarzanie Opcjonalne W celuwygenerowaniaodpowiedzi

W celu okresleniasposobuotrzymywaniaodpowiedzi

Zrozumiałosc dlaludzi

Zrozumiałosc dlaekspertadziedzinowego (nieinformatyka)

Zrozumiałosc dlabiegłego wposługiwaniu siejezykiem

Zrozumiałosc dlaekspertadziedzinowego (nieinformatyka)

Zrozumiałosc dlasystemówkomputerowych

Główniesyntaktyczna

Semantyczna Semantyczna

Konkretne dane Z reguły nieprzedstawiane

Okreslane w jezyku Zawarte wzewnetrznychzródłach

Składnia Graficzna Z reguły tekstowa Graficzna

powiedziec, ze w wielu wypadkach wymaga swego rodzaju połaczenia obydwu podejsc. Tak

jak w wypadku jezyków specyfikowania ontologii, zalezy nam na przekazaniu wiedzy w kie-

runku od zywych osób do systemu komputerowego. Jednak równoczesnie, przekazana wiedza


definiowac ma działanie systemu oprogramowania i byc opisywana w istotnych dla niego kate-

goriach. Przedstawiamy zatem nie tyle ludzka wiedze w sposób zrozumiały dla komputerów, co

formalna wiedze na temat funkcjonowania systemu komputerowego w sposób zrozumiały dla

ludzi. Mozna zatem powiedziec, ze podejscie to wymaga odejscia od naleciałosci wynikłych z

przedstawiania istoty rzeczy, z mysla tylko o systemach komputerowych czy tylko o ludziach,

w celu znalezienia wspólnego gruntu. Jest to zwiazane z dazeniem do zastosowania bardziej

abstrakcyjnych przedstawien, które przypuszczalnie lepiej odzwierciedlaja istote rzeczy.

Jako ze opisywana wiedza słuzy nadaniu kształtu tworzonemu systemowi, nie jest ona prze-

twarzana w sposób bezposredni, lecz dopiero na jej podstawie zostaje wygenerowana gotowa

aplikacja. Zalezy nam jednak, tak jak w wypadku jezyków modelowania, zeby przedstawienie

wiedzy było zrozumiałe dla osób nie posiadajacych specjalistycznej wiedzy z zakresu inzynierii

oprogramowania. Umozliwi to właczenie tych osób w proces budowania logiki dziedzinowej.

Warto tez zauwazyc, ze konkretne dane (fakty), istotne dla działania powstajacego systemu,

na etapie tworzenia jego specyfikacji sa w wiekszosci nieznane, a w przyszłosci ulegaja cze-

stym zmianom. Dane te sa zatem zapisywane niezaleznie od specyfikacji i kodu systemu np. w

formie relacyjnej bazy danych. Czesto równiez zachodzi koniecznosc wykorzystania bardziej

zaawansowanych algorytmów przetwarzania owych danych, które musza byc w zwiazku z tym

odpowiednio precyzyjnie opisane.

W celu spełnienia przedstawionych na poczatku wymagan, potrzebny jest jezyk, który po-

zwoli połaczyc rozwiazania stosowane do reprezentacji wiedzy z tymi uzywanymi w jezykach

modelowania. Dopiero wykorzystanie tak skonstruowanego jezyka da szanse dokonania ade-

kwatnej oceny, w jakim stopniu przedstawienie wiedzy na poziomie konceptualnym moze po-

móc przy wytwarzaniu oprogramowania. W zwiazku z tym uznano stworzenie nowego jezyka

za najbardziej adekwatne i dogodne rozwiazanie. Takie rozwiazanie posiada tez te dodatkowa

zalete, ze umozliwia wieksze dostosowanie stworzonego rozwiazania do uzywanego w systemie

ReDSeeDS jezyka RSL. Dotyczy to zarówno współdziałania, jak i ogólnej spójnosci sposobu

opisu wymagan planowanego systemu. Warto jednak zwrócic uwage, ze wiele opisanych wy-

zej rozwiazan moze stanowic doskonałe odniesienie i zródło inspiracji podczas projektowania

nowego jezyka.

1.5. Infrastruktura dla definiowania jezyków modelowania 31

1.5 Infrastruktura dla definiowania jezyków modelowania

W celu stworzenia nowego jezyka nalezy zdefiniowac jego składnie i semantyke. Składnia je-

zyka definiuje forme, która przyjmuje dany jezyk i konstrukcje, które sa uwazane w nim za

poprawne. Semantyka jezyka okresla znaczenie stojace za tymi konstrukcjami. W wypadku je-

zyków programowania przekłada sie to z reguły na tzw. semantyke wykonawcza. Okresla ona

elementarne działania, których wykonanie powiazane jest z konstrukcjami składniowymi je-

zyka. Składnie jezyka dzielimy na składnie abstrakcyjna i konkretna. Składnia abstrakcyjna de-

finiuje logiczna strukture elementów jezyka w oderwaniu od formy uzytej do jej przedstawienia.

Składnia konkretna definiuje okreslony symboliczny (graficzny lub tekstowy) zapis uzywany do

przedstawienia napisów (np. programów) w danym jezyku. Dwie najczesciej spotykane metody

zapisu składni abstrakcyjnej jezyków formalnych to gramatyki bezkontekstowe i meta-modele.

Przez gramatyke bezkontekstowa [14] rozumiemy gramatyke opisujaca jezyk, w którym

znaczenie konkretnych elementów nie zalezy od kontekstu, w którym one wystepuja. Gramatyki

definiuje sie z pomoca reguł produkcji, które dokonuja przekształcen na symbolach reprezentu-

jacych mozliwe elementy jezyka. Wyrózniane sa dwa rodzaje symboli – symbole nieterminalne

i symbole terminalne. Symbole nieterminalne reprezentuja pewna uogólniona grupe symboli, i

moga zostac przekształcone za pomoca reguł na symbole bardziej szczegółowe. Symbole termi-

nalne reprezentuja faktyczne elementy jezyka i nie moga byc przekształcane dalej za pomoca

reguł. W gramatykach bezkontekstowych po lewej stronie reguły moze wystapic tylko poje-

dynczy symbol nieterminalny, co oznacza, ze nie da sie uzaleznic zastosowania reguły od jego

sasiadów (niezaleznosc od kontekstu). Typowym sposobem przedstawiania gramatyk bezkon-

tekstowych jest notacja BNF [77] (ang. Backus-Naur Form). Oznacza ona symbole nietermi-

nalne ostrokatnymi nawiasami (znaki „<” i „>”), dzieli lewa i prawa strone reguły znakiem „::=”

i dopuszcza uzywanie w prawej czesci reguły poza symbolami terminalnymi i nieterminalnymi

tylko znaku „|” symbolizujacego alternatywe rozłaczna. Przykładowo konstrukcja „<parameter

list> ::= <parameter> | <parameter list> , <parameter>” oznacza, ze symbolowi nieterminal-

nemu „parameter list” moze odpowiadac symbol nieterminalny „parameter” lub symbol nie-

terminalny „parameter list” po którym wystepuje symbol terminalny „ , ”, a nastepnie równiez


symbol nieterminalny „parameter”. Innymi słowy, konstrukcja ta definiuje, ze lista parametrów

moze składac sie z dowolnej, wiekszej od zera liczby parametrów rozdzielonych przecinkami.

Przez meta-model nalezy rozumiec model opisujacy modele. Odpowiednikiem pojecia klasy

w meta-modelu jest pojecie meta-klasy. Zaleznosc miedzy modelem a meta-modelem mozna

okreslic w ten sposób, ze modele stanowia instancje meta-modelu, a klasy instancje meta-klas.

Nalezy jednak zaznaczyc, ze taka definicja nie jest wystarczajaca. Zeby model modelu zasłu-

giwał na miano meta-modelu róznica w poziomie abstrakcji miedzy nimi musi miec charakter

jakosciowy, a nie tylko ilosciowy. Formalnie mozna to ujac tak, ze relacja łaczaca elementy

modelu i meta-modelu musi byc antyprzechodnia i acykliczna [52]. Antyprzechodniosc to sil-

niejsza wersja załozenia o nieprzechodniosci, która wymaga, zeby dana relacja nigdy nie była

przechodnia. Oznacza to, ze jesli jeden element jest meta-klasa dla drugiego, nie moze istniec

trzeci element bedacy meta-klasa dla nich obydwu. Acyklicznosc oznacza natomiast, ze relacja

nie powinna posiadac cykli o zadnej długosci (obejmuje wiec równiez załozenia przeciwzwrot-

nosci i przeciwsymetrycznosci). Innymi słowy, jesli jeden element jest meta-klasa dla drugiego,

to zarówno ten drugi element, jak i zaden z elementów, dla których on jest meta klasa i elemen-

tów lezacych jeszcze wczesniej w hierarchii bycia meta-klasami, nie moze byc meta-klasa dla

elementu pierwszego. Przykładowo wiec, wystepujaca w opisanym wczesniej jezyku FLogic

zaleznosc miedzy mniej a bardziej ogólnymi klasami reprezentowana za pomoca mechanizmu

bycia instancja nie sprawia, ze te bardziej ogólne sa meta-modelem tych mniej ogólnych. Dzieje

sie tak, mimo, ze jedne sa instancja drugich, gdyz jest to relacja przechodnia. Wraz z wykorzy-

staniem meta-modeli mozemy wyróznic co najmniej trzy warstwy abstrakcji na których rozpa-

trujemy dane zagadnienie – najbardziej ogólna warstwe zawierajaca meta-modele, warstwe ich

instancji zawierajaca modele i warstwe instancji modeli zawierajaca obiekty. W razie potrzeby

mozna równiez rozszerzac te strukture w góre, tworzac meta-meta-modele dla meta-modeli.

Jednym z popularniejszych rozwiazan stosowanych do zapisu meta-modeli jest jezyk MOF

[82], co stanowi skrót od „Meta-Object Facility”. Wystepuje on w dwóch wersjach: CMOF,

który stanowi skrót od „Complete MOF” (kompletny MOF) oraz uproszczona wersje – EMOF,

która stanowi skrót od „Essential MOF” (zasadniczy MOF) i nie zawiera miedzy innymi ge-

neralizacji wielokrotnej. W pewnym przyblizeniu mozna powiedziec, ze jezyk MOF przypo-


RYSUNEK 1.16: Przykładowy fragment meta-modelu w jezyku MOF

mina uproszczony model klas zapisany w jezyku UML. Nie definiuje on operacji klas, nie

okresla widocznosci poszczególnych elementów, czy tez nie rozróznia pomiedzy agregacjami

a kompozycjami. W jezyku tym wyrózniamy meta-klasy, które reprezentuja wystepujace w de-

finiowanym jezyku typy elementów. Graficznie przedstawione sa one w postaci prostokatów,

analogicznie do klas w jezyku UML, i moga byc opisane przez atrybuty odpowiadajace typom

prymitywnym lub enumeracjom, a takze byc zadeklarowane jako abstrakcyjne. Istnieje równiez

mozliwosc okreslania relacji specjalizacji pomiedzy meta-klasami oraz połaczenia ich asocja-

cjami z okreslonymi licznosciami i nazwanymi rolami. Asocjacje moga byc takze okreslone

jako nawigowalne, stanowic kompozycje lub byc uporzadkowane.

Przykładowy prosty fragment meta-modelu, przedstawiony za pomoca jezyka MOF, jest za-

prezentowany na rysunku 1.16. Zawiera on trzy meta-klasy – element („element”), relacje („re-

lationship”) i komentarz („comment”). Pierwsze dwie z nich sa okreslone jako abstrakcyjne,

na co wskazuja ich nazwy zapisane kursywa. Meta-klasa komentarza ma natomiast przypisany

atrybut o nazwie „body” i typie prymitywnym reprezentujacym ciag znakowy. Relacje generali-

zacji przedstawione w formie strzałek zakonczonych białym trójkatem wskazuja, ze meta-klasy

relacji i komentarza specjalizuja meta-klase elementu. Dodatkowo, w naszym przykładowym

meta-modelu wystepuja trzy asocjacje, równiez przedstawione w formie linii łaczacych ele-

menty. Asocjacja łaczaca klase „Element” z sama soba reprezentuje zawieranie sie elementów

w innych elementach. Wystepujacy na jednym z konców tej własnie relacji czarny romb wska-

zuje, ze została ona okreslona jako kompozycja. Ponadto, na podstawie odpowiednich licznosci


mozemy stwierdzic, ze o ile w danym elemencie moze zawierac sie dowolna liczba elementów,

to dany element moze zwierac sie tylko w jednym elemencie. Kolejna relacja łaczy relacje z

elementami. Grot znajdujacy sie na jednym z jej konców wskazuje, ze jest ona nawigowalna w

kierunku elementu. Na podstawie licznosci mozemy stwierdzic, ze kazda relacja musi byc po-

wiazana z co najmniej jednym elementem. Wreszcie ostatnia, równiez nawigowalna asocjacja

łaczy komentarze z elementami, które sa przez nie opisywane.

Do opisu semantyki jezyka równiez mozna podejsc na wiele sposobów. Jednak w wypadku

jezyków zdefiniowanych w oparciu o meta-modele dwa podstawowe podejscia to definiowanie

semantyki translacyjnej (ang. translational semantics) lub definiowanie semantyki operacyjnej

(ang. operational semantics) [49]. Metoda opierajaca sie o semantyke translacyjna wychodzi z

załozenia, ze semantyka danego jezyka moze byc zachowana przy przetłumaczeniu go na inny

jezyk. Semantyke jezyka definiuje sie poprzez okreslenie precyzyjnych reguł jego tłumaczenia

na struktury innego jezyka. Zeby tego typu działanie miało sens, jezyk na który tłumaczymy po-

winien dysponowac dobrze okreslona semantyka. Nalezy równiez zwrócic uwage na to, zeby w

tym drugim jezyku dało sie wyrazic wszystkie konstrukcje jezyka pierwotnego. Przykładowo,

dobrym sposobem na wyjasnienie semantyki jezyka Python osobom zaznajomionym z jezykiem

Java, jest pokazanie jakie struktury tego drugiego jezyka odpowiadaja strukturom tego pierw-

szego. Takie podejscie zostało równiez zastosowane przy okreslaniu semantyki jezyka RSL,

gdzie poszczególne jego konstrukcje przedstawione sa w kontekscie kodu, który jest wygene-

rowany na ich podstawie [98]. Zastosowanie metody opartej o semantyke operacyjna opiera

sie na zblizonych regułach, jednak nie majac jako odniesienia gotowego jezyka, trzeba precy-

zyjnie okreslic strukture i sposób funkcjonowania maszyny, na której działanie przekłada sie

struktury opisywanego jezyka. Przykładowo, dobrym sposobem wyjasniania działania jezyka

typu asembler jest wytłumaczenie architektury procesora i jego rejestrów oraz opisywanie, jak

poszczególne instrukcje asemblera wpływaja na jego stan i ich zawartosc.

Niezaleznie od stosowanego podejscia, do własciwego okreslenia semantyki konieczne jest

zapisanie pozwalajacych ja okreslic informacji w jednoznaczny sposób. Jako ze jezyk naturalny

nie jest dostatecznie precyzyjny, stosuje sie rózne metody o wiekszym lub mniejszym stopniu

formalizacji. Zakres wykorzystywanych rozwiazan rozciaga sie od wykorzystania matematycz-


nych formalizmów, po traktowanie implementacji kompilatora lub interpretatora danego jezyka

jako nieformalnej specyfikacji jego semantyki wykonawczej [94]. Istnieja wrecz takie jezyki,

które mozna okreslic jako samo-definiujace sie. Przykładem moze byc jezyk Prolog, który po-

siada interpreter napisany w jezyku Prolog, czy tez jezyk Lisp posiadajacy kompilator napisany

w jezyku Lisp.

W przypadku, kiedy mamy do czynienia z semantyka translacyjna, gdzie jezyk zródłowy

i docelowy posiadaja zdefiniowany meta-model, nasuwajacym sie rozwiazaniem do precyzyj-

nego okreslenia reguł translacyjnych jest wykorzystanie jednego z jezyków specjalnie stworzo-

nych do transformacji modeli. Przykładem takiego jezyka jest jezyk MOLA [45, 105], który

posiada te dodatkowa zalete, ze jest jezykiem graficznym, wykorzystujacym reprezentacje in-

spirowana jezykiem MOF. Bedac stosunkowo czytelnym dla osób zaznajomionych z modelo-

waniem i meta-modelowaniem, moze posłuzyc jako wygodny sposób do definiowania seman-

tyki translacyjnej, czy obrazowania realizujacych ja transformacji i algorytmów. Zostanie zatem

wykorzystany do tego celu w rozdziale 4 pracy.

Przykładowe elementy składni jezyka MOLA sa przedstawione na rysunku 1.17 w postaci

czterech rozłacznych fragmentów transformacji zaczerpnietych z podrecznika tego jezyka. Sa

one oparte na fragmencie meta-modelu w jezyku MOF, oznaczonym na rysunku 1.17 cyfra „0”.

Ten prosty meta-model przedstawia trzy meta-klasy – „Class” (klasa), „Property” (własciwosc)

i „Type” (typ). Pierwsza i druga z tych meta-klas sa połaczone meta-asocjacja, okreslajaca po-

wiazania miedzy klasa i jej własciwosciami. Podobnie, druga i trzecia meta-klasa łaczy meta-

relacja, która okresla mozliwosc posiadania okreslonego typu przez własciwosc. Dodatkowo,

meta-klasa „Type” posiada atrybut „name” (nazwa), którego typem jest ciag znaków.

Kolejny fragment oznaczony na rysunku 1.17 cyfra „1” przedstawia podstawowy element

jezyka MOLA, jakim jest reguła zawierajaca wzorzec. Na dopasowaniu tego typu wzorców ba-

zuje deklaratywny aspekt definiowania transformacji w tym jezyku. Reguła oznaczana jest jako

szary prostokat z zaokraglonymi rogami. Wzorzec jest zawarty wewnatrz reguły i składa sie z

instancji meta-klas w formie prostokatów powiazanych łacznikami reprezentujacymi instancje

meta-asocjacji. Reprezentacje instancji meta-klas składaja sie z trzech oddzielonych poziomymi

liniami czesci. Pierwsza z nich zawiera nazwe meta klasy poprzedzona przed dwukropkiem na-


RYSUNEK 1.17: Przykładowe elementy składni jezyka MOLA [105]

zwa samej instancji. Nazwa instancji moze byc poprzedzona znakiem „@”, i wtedy odwołuje

sie do elementu zadeklarowanego w innym miejscu. Druga czesc ikony instancji moze zawierac

warunki do sprawdzenia dla danej instancji, zawarte w nawiasach klamrowych. Trzecia czesc

ikony moze zawierac przypisania wartosci dla jej atrybutów – składnia takiego przypisania jest

identyczna, jak przedstawiona pózniej składnia przypisania wartosci do zmiennej. Same instan-

cje asocjacji musza miec podane role elementów (opisy konców relacji), których dotycza.

Po uruchomieniu transformacji, próbuje ona znalezc układ elementów odpowiadajacy ele-

mentom z czarnym obramowaniem wystepujacym we wzorcu i spełniajacych wszelkie doty-

czace ich warunki. W wypadku znalezienia takiego układu, dla elementów zawartych w regule

wykonywany jest szereg akcji, zaleznych od rodzaju elementów, reprezentowanego przez typ

ich obramowania. W pierwszej kolejnosci tworzone sa wszystkie elementy oznaczone czerwo-


nym przerywanym obramowaniem. Nastepnie, wszystkim elementom, które nie były okreslone

wczesniej, a zostały znalezione podczas dopasowania wzorca lub zostały stworzone, nadawane

sa nazwy, pod którymi one w regule wystepuja. Umozliwi to odwoływanie sie do nich za po-

moca tych nazw w dalszej czesci działan, a takze w przyszłych regułach. Kolejnym krokiem jest

wykonanie przypisan wartosci atrybutów według zawartych w elementach formuł. Na koniec,

usuwane sa wszystkie elementy z czarnym przerywanym obramowaniem. Wracajac do przy-

kładu z rysunku 1.17 (fragment nr 1), na podstawie powyzszych zasad mozemy okreslic dzia-

łanie podanej reguły. Sprawdza ona, czy okreslona wczesniej instancja „c” meta-klasy „Class”

jest połaczona z jakakolwiek instancja meta-klasy „Property”, która posiada atrybut „name”

o wartosci tekstowej „name”. Sprawdza takze, czy istnieje jakakolwiek instancja meta-klasy

„Type” posiadajaca atrybut „name” o wartosci tekstowej „String”. W wypadku zajscia obydwu

tych warunków, pomiedzy znaleziona instancja meta-klasy „Property” a znaleziona instancja

meta-klasy „Type” tworzony jest łacznik, zgodne z wczesniej przedstawionym meta-modelem.

Dodatkowo, pierwszej z tych meta-klas jest nadawana nazwa symboliczna „p”, a drugiej nazwa

symboliczna „t”.

Opisana reguła jest przykładem konstrukcji typu deklaratywnego, jako ze jedynie definiuje

oczekiwany rezultat, nie okreslajac szczegółów jego osiagniecia. Jezyk MOLA oprócz elemen-

tów deklaratywnych, zawiera takze te o charakterze imperatywnym, które pozwalaja uporzad-

kowac wykonanie deklaratywnie okreslonych działan w okreslona sekwencje i wpływac na jej

przebieg. Przykład takiej sekwencji został przedstawiony na fragmencie oznaczonym cyfra „2”.

Poczatek sekwencji reprezentowany jest przez czarna kropke, a jej koniec przez mniejsza czarna

kropke w okregu. Poszczególne elementy połaczone sa strzałkami wskazujacymi kolejnosc ich

wykonania. Oprócz reguł łaczone w ten sposób sa równiez miedzy innymi instrukcje tekstowe,

takie jak to przedstawione we fragmencie, oraz wywołania procedur. Dodatkowo, mozliwe sa

równiez przepływy oznaczone słowem kluczowym „ELSE” w nawiasach klamrowych, które

prowadza do elementów wykonywanych, gdy dana reguła czy warunek nie jest spełniony. Samo

wyrazenie tekstowe podzielone jest na dwie czesci, z których pierwsza moze zawierac spraw-

dzenia dowolnych warunków, a druga jest wykonywana w wypadku ich spełnienia. Dotyczy to

przypisania dowolnych atrybutów lub zmiennych prymitywnych. Nie przedstawione w przykła-


dowym fragmencie wywołania procedur przypominaja instrukcje tekstowe, z tym ze zamiast

dwóch wyróznionych czesci posiadaja tekst typowego dla dowolnego jezyka programowania

wywołania procedury, oraz sa oznaczone innym kolorem. Zaprezentowany fragment sprawdza

wiec wartosc zmiennej „i” i tak długo, jak ta wartosc jest wieksza od zera, dodaje jej wartosc

do zmiennej sum i zmniejsza ja o jeden. Jak mozna zaobserwowac, nazwy zmiennych w tresci

przypisan równiez poprzedzone sa znakiem „@”.

Fragment oznaczony cyfra „3” prezentuje petle. Petla oznaczona jest za pomoca pogrubio-

nego prostokata i musi zawierac regułe z elementem o pogrubionym obramowaniu, zwanym

głowa petli. Petla próbuje wykonac owa regułe (i w razie potrzeby kolejne po niej nastepujace)

dla wszystkich elementów spełniajacych regułe zawierajaca głowe petli. Zaprezentowany frag-

ment znajduje wszystkie instancje meta-klasy „Property” przypisane do podanej instancji „c”

meta-klasy „Class” jako „ownedAttribute” i nastepnie je usuwa. Warto zauwazyc, ze usuniecie

zostało przeniesione do osobnej reguły, jako ze nie mozna naraz oznaczyc elementu jako głowy

petli i go usunac. Warto równiez zauwazyc, ze nie jest mozliwe zdefiniowanie alternatywy

(przepływ ze słowem „ELSE”) od reguły zawierajacej głowe petli – elementy nie spełniajace

takiej reguły nie sa przetwarzane w obrebie petli.

Wreszcie ostatni element na rysunku 1.17 (cyfra „4”) przedstawia składnie parametrów i

zmiennych w jezyku MOLA. Pierwszy z elementów reprezentuje parametr wejsciowy proce-

dury i ma forme pieciokata przypominajacego strzałke skierowana w prawo. Oprócz nazwy

poprzedzonej znakiem „@” posiada on równiez po dwukropku zdefiniowany typ. Cyfra znajdu-

jaca sie w jego prawym dolnym rogu okresla natomiast jego pozycje w wywołaniu procedury.

Drugi z przedstawionych elementów w formie szesciokata reprezentuje parametr wyjsciowo-

wejsciowy. Wreszcie ostatni element reprezentuje zmienna lokalna. Oba te elementy opisywane

sa analogicznie do tego pierwszego, z tym ze zmienne nie posiadaja liczby porzadkowej.

1.6 Rozwiazania pokrewne w obszarze generacji kodu

Z analizy przeprowadzonej w sekcji 1.4 wynika, ze brak jest obecnie jezyków specyfikacji

wiedzy dziedzinowej, które pozwalaja na adekwatne odzwierciedlenie wszystkich informacji

1.6. Rozwiazania pokrewne w obszarze generacji kodu 39

potrzebnych do generacji pełnego kodu warstwy logiki dziedzinowej z poziomu specyfikacji

wymagan. Nalezało sie zatem spodziewac, ze nie istnieja narzedzia realizujace taka genera-

cje. Według najlepszej wiedzy autora popartej przegladem literatury faktycznie brak jest takich

rozwiazan. Niezaleznie od tego, ponizej przedstawiono krótka analize rozwiazan o cechach naj-

bardziej zblizonych do cech jezyka przedstawionego w niniejszej pracy.

Istnieje szereg narzedzi realizujacych paradygmat MDA, które pozwalaja na generacje kodu

aplikacji [60], a zatem równiez elementów logiki dziedzinowej. Wiele narzedzi do modelo-

wania obiektowego, jak np. Enterprise Architect [27] czy Modelio [70] umozliwia generacje

szkieletu kodu w wybranym jezyku na podstawie modeli klas. Poszczególne rozwiazania, jak

np. AndroMDA ida o krok dalej, generujac strukture całego systemu na podstawie szeregu dia-

gramów w jezyku UML. Te najbardziej zaawansowane jak np. Bluage [79], czy Integranova

[42] wykorzystuja diagramy UML uzupełnione o adnotacje w jezyku OCL [107] lub innych je-

zykach o zblizonej funkcjonalnosci, jak np. OASIS [58]. Umozliwia to nawet generacje w pełni

funkcjonalnego kodu. Jednakze rozwiazania te istotnie róznia sie charakterem od poszukiwa-

nego w tej pracy. Specyfikacje, na których bazuje generacja wykonywana przez te narzedzia

nie stanowia specyfikacji wymagan, ale zawieraja konkretne modele projektowe, nawet jesli

nie sa one zalezne od zadnej wybranej technologii. Sa one zatem znacznie bardziej rozbudo-

wane i szczegółowe, niz specyfikacja na poziomie wymagan, oraz wymagaja podania wiekszej

ilosci informacji. W zwiazku z tym ewentualne zawarte w nich informacje na temat wiedzy

dziedzinowej dotycza rozwiazania konkretnych problemów dotyczacych danego systemu. Nie

reprezentuja one w wystarczajacym stopniu wiedzy ogólnej, nadajacej sie do rozwiazywania

róznych problemów z danej dziedziny. Dodatkowo, specyfikacje wykorzystywane w tych bar-

dziej awansowanych rozwiazaniach posiadaja z reguły fragmenty mocno techniczne, utrudnia-

jace zrozumienie takich specyfikacji zwykłym uzytkownikom. Mozna powiedziec, ze zawarta

w nich złozonosc incydentalna w znacznym stopniu „ukrywa” złozonosc zasadnicza wyrazana

jako wiedza dziedzinowa (patrz sekcja 1.1).

41

Rozdział 2

Jezyk RSL i system ReDSeeDS

2.1 Jezyk RSL

Jezyk RSL [44, 101] powstał w celu umozliwienia specyfikowania wymagan funkcjonalnych w

sposób, który bedzie zrozumiały dla osób nie posiadajacych specjalistycznej wiedzy z zakresu

inzynierii wymagan, a jednoczesnie odpowiednio precyzyjny dla umozliwienia automatycznego

generowania artefaktów projektowych i kodu aplikacji. Korzysta on z wielu popularnych kon-

strukcji stosowanych m.in. w jezyku UML. Konstrukcje te zostały odpowiednio ujednolicone

i doprecyzowane, oraz nadano im jednoznaczna semantyke. Specyfikacja jezyka jest przedsta-

wiona w formie meta-modelu zapisanego za pomoca jezyka MOF. Wymagania funkcjonalne

reprezentowane sa głównie poprzez przypadki uzycia opisane za pomoca scenariuszy. Dodat-

kowo, terminy wystepujace w scenariuszach sa dokładniej objasniane za pomoca pojec zawar-

tych w słowniku dziedziny. Ten ostatni element jezyka RSL pozwala na czesciowa specyfikacje

wiedzy dziedzinowej. Rozszerzeniem notacji dla słownika dziedziny jest notacja przedstawiona

w niniejszej pracy.

Rysunek 2.1 przedstawia ogólna strukture specyfikacji zapisanej w jezyku RSL. Na specy-

fikacje („RequirementSpecification”) składaja sie wymagania reprezentowane przez meta-klase

„Requirement”, uporzadkowane w pakiety reprezentowane przez meta-klase „RequiementPac-

kage”. Dodatkowo, kazda specyfikacja wymagan zawiera specyfikacje dziedzinowa (słownik)

reprezentowana przez meta-klase „DomainSpecification”. Na specyfikacje dziedzinowa skła-

daja sie pakiety zawierajace aktorów („Actor”), pojecia („Notion”’) i elementy systemowe

(„SystemElement”). W kolejnych sekcjach niniejszego rozdziału przedstawiono wybrane szcze-

42 Rozdział 2. Jezyk RSL i system ReDSeeDS

RYSUNEK 2.1: Uproszczony meta-model struktury specyfikacji w jezyku RSL

gółowe elementy jezyka RSL, które maja zwiazek z elementami nowego jezyka, opisanego w

nastepnych rozdziałach.

2.1.1 Przypadki uzycia i scenariusze

Najwazniejszym rodzajem wymagan w jezyku RSL sa przypadki uzycia. Jezyk RSL zachowuje

nieformalna semantyke przypadków uzycia, która dobrze oddaje klasyczna definicja podana

przez Alistaira Cockburna: „Przypadek uzycia jest kolekcja mozliwych scenariuszy interakcji

miedzy rozwazanym systemem i jego zewnetrznymi aktorami, w zwiazku z okreslonym celem.”

[16] (tłum. własne). Oznacza to, ze kazdy przypadek uzycia posiada konkretny cel dla głównego

2.1. Jezyk RSL 43

RYSUNEK 2.2: Uproszczony meta-model elementów zwiazanych z przypadkamiuzycia

aktora, w odniesieniu do deklarowanych funkcjonalnosci systemu. Scenariusze przypadku uzy-

cia pokazuja jak owe cele moga zostac osiagniete lub jak dazenie do nich moze zakonczyc sie

niepowodzeniem. Podstawowe elementy meta-modelu powiazane z przypadkami uzycia przed-

stawione sa na rysunku 2.2. Zgodnie z podana składnia, kazdy przypadek uzycia („RSLUse-

Case”) powiazany jest z co najmniej jednym scenariuszem („ConstrainedLanguageScenario”),

składajacym sie z uporzadkowanych zdan w ograniczonym jezyku naturalnym („Constraine-

dLanguageSentence”).

Podstawowym rodzajem zdan wchodzacych w skład scenariusza sa tzw. zdania SVO, skła-

dajace sie z podmiotu (ang. Subject), orzeczenia (ang. Verb) i dopełnienia (ang.Object). Meta-

model jezyka RSL przedstawia te zdania w formie hierarchicznej. Rzeczowniki reprezentowane


RYSUNEK 2.3: Uproszczony meta-model elementów zwiazanych z zdaniamiSVO

meta-klasa „Noun” zostaja „opakowane” we frazy rzeczownikowe reprezentowane przez meta-

klase „NounPhrase”. Ponadto, czasowniki pełniace role orzeczenia sa grupowane z frazami

rzeczownikowymi pełniacymi role dopełnienia. Takie grupy nazywane sa frazami czasowni-

kowymi i reprezentowane przez meta-klasy specjalizujace z „VerbPhrase”. Dodatkowo, oprócz

zwykłych prostych fraz rzeczownikowych reprezentowanych przez meta-klase „SimpleVerbPh-

rase”, jezyk RSL dopuszcza równiez frazy bardziej złozone. Sa one rozwiniete o dodatkowe do-

pełnienie poprzedzone przyimkiem i reprezentowane przez meta-klase „ComplexVerbPhrase”.

Warto zauwazyc równiez, ze rzeczowniki, czasowniki i przyimki dziedzicza z abstrakcyjnej

meta-klasy „Term”, która umozliwia przypisanie im konkretnych znaczen. Struktura elemen-

tów zwiazanych z reprezentowaniem zdan jest przedstawiona na rysunku 2.3.

Oprócz zdan SVO, w jezyku RSL wystepuja równiez zdania sterujace („ControlSentence”).

Jednym z rodzajów takich zdan sa zdania wywołujace funkcjonalnosc innych przypadków uzy-

cia („InvocationSentence”). Inne tego typu zdania pozwalaja rozgałeziac przebieg scenariuszy

w oparciu o okreslone warunki, a nastepnie ponownie je łaczyc. Sa one reprezentowane odpo-

2.1. Jezyk RSL 45

RYSUNEK 2.4: Przykładowy model przypadków uzycia w jezyku RSL

wiednio przez meta-klasy „ConditionSentence” i „RejoinSentence”.

Przykładowy model przypadków uzycia w jezyku RSL przedstawiony jest na rysunku 2.4.

Jak widzimy, notacja graficzna czerpie z notacji jezyka UML. Aktorów przedstawiamy w for-

mie uproszczonych piktogramów ludzi, a przypadki uzycia reprezentujemy za pomoca elips.

Powiazania miedzy aktorami a przypadkami uzycia reprezentowane sa przy pomocy zwykłych

linii, oznaczajacych relacje „uzycia” (ang. usage). Powiazania miedzy przypadkami uzycia sa

natomiast przedstawiane za pomoca strzałek o przerywanych liniach, oznaczajacych relacje

„wywołania” (ang. invocation). Nalezy tutaj zauwazyc, ze w prezentowanym w pracy fragmen-

cie meta-modelu jezyka RSL pominieto meta-klasy „UsageRelationship” i „InvocatioRelation-

ship” definiujace składnie abstrakcyjna dla tych dwóch relacji.

W naszym przykładzie, pierwszy z aktorów – uzytkownik (ang. user) jest powiazany z przy-

padkiem uzycia logowania sie do systemu. Drugi aktor – administrator (ang. admin) ma nato-

miast do dyspozycji dwa przypadki uzycia – jest powiazany bezposrednio w przypadkiem uzy-

cia umozliwiajacym przejrzenie listy uzytkowników, a takze posrednio z przypadkiem uzycia

umozliwiajacym zmiane danych uzytkownika, który powiazany jest z tym poprzednim poprzez

relacje wywołania. Relacja ta odzwierciedla wystapienie wczesniej opisanego zdania „Invoca-

tionSentence” w scenariuszu dla przypadku uzycia przejrzenia listy uzytkowników.

Scenariusze przypadku uzycia odzwierciedlajacego logowanie sie do systemu („Log in”

na rysunku 2.4) przedstawione sa na rysunku 2.5. Poszczególne elementy zdan w formacie


RYSUNEK 2.5: Przykładowy scenariusz przypadku uzycia w jezyku RSL

podmiot-orzeczenie-dopełnienie oznaczone sa odpowiednimi kolorami. Jak wynika ze scena-

riusza, w celu zalogowania sie, uzytkownik wybiera odpowiedni przycisk („login button”),

który powoduje wyswietlenie sie formularza logowania („login form”). Po tym jak uzytkow-

nik wprowadzi i zatwierdzi swoje dane logowania („login data”), sa one weryfikowane („check

login data”). Jesli dane sa poprawne (pierwsze zdanie „cond”), to zgodnie z dalsza czescia sce-

nariusza formularz logowania jest zamykany, a uzytkownik autoryzowany i przenoszony do

głównego menu aplikacji. W przeciwnym wypadku (drugie zdanie „cond”), zgodnie ze sce-

nariuszem alternatywnym wyswietlany jest komunikat o niepoprawnych danych logowania i

uzytkownik cofany jest do ich ponownego wprowadzania (zdanie „rejoin”).

2.1.2 Pojecia dziedzinowe i słownik

Elementy zdan moga wystepowac w wielu róznych scenariuszach. Wobec tego, ich deklaracje

umieszczane sa w osobnej specyfikacji dziedziny – słowniku. Kazdemu rzeczownikowi wy-

stepujacemu w zdaniach SVO odpowiada element w specyfikacji dziedzinowej, której ogólna

2.1. Jezyk RSL 47

RYSUNEK 2.6: Uproszczony meta-model specyfikacji dziedzinowej w jezykuRSL

struktura przedstawiona jest na rysunku 2.6. Rzeczownikom wystepujacym w roli podmiotu

odpowiadaja aktorzy reprezentowani przez meta-klase „Actor” lub elementy systemowe repre-

zentowane przez meta-klase „SystemElement”. Pozostałym rzeczownikom odpowiadaja poje-

cia reprezentowane za pomoca meta-klasy „Notion”. Wszystkie te elementy maja przypisana

nazwe w postaci odpowiedniej frazy rzeczownikowej, oraz specjalizuja tzw. elementy dzie-

dzinowe (meta-klasa „DomainElement”). Te ostatnie umozliwiaja przypisywanie do elemen-

tów tzw. stwierdzen dziedzinowych reprezentowanych przez meta-klase „DomainStatement”.


Stwierdzenia dziedzinowe sa ogólnymi konstruktami zawierajacymi dowolne frazy. W prak-

tyce mozliwosc ta jest wykorzystywana jedynie dla pojec (a nie dla aktorów i elementów sys-

temowych). Jest to wykorzystywane w celu przypisania do poszczególnych pojec (np. „login

data”) wszystkich powiazanych z nimi fraz czasownikowych wystepujacych w scenariuszach

(np. „check login data”). Kazde pojecie moze równiez wystapic w roli atrybutu innego pojecia.

W takiej sytuacji, mozliwe jest takze przypisanie do pojecia, jednego z szesciu typów prymi-

tywnych („AttributeDataTypes”). Wszystkie elementy dziedzinowe moga byc łaczone ze soba

za pomoca relacji dziedzinowych reprezentowanych za pomoca meta-klasy „DomainElemen-

tRelationship”, choc ponownie mozliwosc ta jest w praktyce wykorzystywana tylko w wypadku

pojec.

Choc nie zostało to przedstawione na zamieszczonych wyzej uproszczonych fragmentach

meta-modelu, własciwie kazdy element meta-modelu ma mozliwosc przypisania do niego opisu.

Kazdemu elementowi jezyka RSL mozna równiez przypisac dowolna liczbe stereotypów o do-

wolnych nazwach. W nowszych wersjach narzedzia ReDSeeDS ten drugi mechanizm został

wykorzystany do uszczegółowienia semantyki specyfikacji wymagan w celu umozliwienia ge-

nerowania bardziej adekwatnego interfejsu uzytkownika [98].

Narzedzie ReDSeeDS definiuje trzy grupy stereotypów. Pierwsza z tych grup przypisana

jest do pojec, okreslajac bardziej precyzyjnie ich typ. Wyrózniamy pojecia typu „Concept” re-

prezentujace pojecia odpowiadajace istniejacym zbiorom danych wyróznionych na poziomie

koncepcyjnym. Mamy równiez typy „Simple View”, List View” i „Tree View” reprezentujace

dane pogrupowane na potrzeby wyswietlania i interakcji z nimi na poziomie działajacego sys-

temu. Pierwszy typ odpowiada danym dostepnym bezposrednio, a pozostałe dwa odpowiednio

– za posrednictwem listy, badz w strukturze drzewiastej. Został wyrózniony takze osobny typ

„Attribute”, słuzacy do wyrózniania atrybutów oraz odpowiednie typy dla elementów interfejsu

uzytkownika: „Screen”, „Trigger”, „Confirmation Dialog” i „Message”.

Druga z grup stereotypów jest równiez przypisywana do pojec i została wykorzystana do

rozszerzenia mozliwych dostepnych wartosci dla pojec oznaczonych za pomoca pierwszego

typu stereotypów. Oprócz dotychczas dostepnych pojec o typach „String”, „Integer”, „Bo-

olean”, „Date”’, „Time” i „Float” (pierwsze trzy zostały przemianowane na „Text”, „Number”,

2.1. Jezyk RSL 49

„True/False”, a ostatni na „Floating point number”), dodano typy „Description” i „Password”.

Ostatnia grupa stereotypów została przypisana do stwierdzen dziedzinowych zawierajacych

frazy czasownikowe, w celu okreslenia reprezentowanego przez nie rodzaju akcji. Przy tym,

dopuszczalne rodzaje akcji zaleza od typu pojecia, do którego twierdzenia dziedzinowe przy-

naleza. W wypadku pojec o typach „Concept”, „Simple View”, List View” i „Tree View” do-

puszczalne sa typy akcji „Create”, „Read”, „Update”, „Delete” i „Validate”. W wypadku pojec

o typach „Screen”, „Message” i „Confirmation Dialog” dopuszczalne sa natomiast typy akcji

„Show”, „Close” i „Refresh”. Z kolei twierdzeniom przypisanym do pojec o typie „Trigger”

przypisac mozna tylko jeden rodzaj akcji – „Select”.

Wraz z wyróznieniem róznych typów pojec (pierwsza grupa stereotypów powyzej), została

równiez nadana konkretna semantyka dla wybranych relacji dziedzinowych łaczacych takie

pojecia. Kazdy z tzw. widoków danych, czyli ”Simple View”, „List View” i „Tree View”, powi-

nien miec pojedyncza skierowana relacje łaczaca go z pojeciem o typie „Concept”. Wyznacza

ona główne pojecie, na którym ów widok bazuje. Skierowane relacje od widoków danych do

atrybutów przypisuja wybrane atrybuty pojec do tych widoków. Pomiedzy pojeciami o typie

„Screen” a widokami danych moze natomiast wystapic jedna z trzech relacji. Relacja skiero-

wana od widoku danych oznacza wyswietlanie danych, relacja skierowana do widoku danych

oznacza wprowadzanie danych, a relacja nieskierowana oznacza ich edycje. Dodatkowo, spe-

cjalne znaczenie maja równiez nieskierowane relacje od pojec o typie „Screen” do pojec o typie

„Trigger”. Oznaczaja one dostepnosc reprezentowanych przez ten drugi typ pojecia wyzwala-

czy, na oknach reprezentowanych przez ten pierwszy typ pojec. Skierowane relacje od pojec o

typie „Trigger” do widoków danych, oznaczaja udział odpowiadajacych widokom danych, w

akcjach zwiazanych z powiazanymi wyzwalaczami.

Warto zauwazyc, ze stwierdzenia dziedzinowe przypisane do pojec o typach „Concept”,

„Simple View”, „List View” i „Tree View” moga byc zwiazane ze zdaniami w scenariuszach,

w których podmiotem jest system. W takich sytuacjach, odpowiadaja one miejscom, w których

system powinien wykonywac okreslone operacje dziedzinowe. Co wiecej, mozliwe do przypi-

sania im rodzaje akcji definiuja w prostszych sytuacjach rodzaj tej operacji (np. odczyt, zapis

danych). W wypadku bardziej złozonego przetwarzania danych zaden z dostepnych w klasycz-


RYSUNEK 2.7: Przykładowy fragment modelu słownika w jezyku RSL

nej wersji jezyka RSL typów akcji nie bedzie jednak adekwatny i takie zdania nie beda miały

przypisanego typu akcji.

Jako przykład słownika dziedziny przedstawimy fragment odpowiadajacy wczesniej przed-

stawionym scenariuszom. Został on pokazany na rysunku 2.7. Pojecia przedstawione sa w for-

mie prostokatów przypominajacych klasy w jezyku UML, a łaczace je relacje dziedzinowe –

w postaci linii dla relacji nieskierowanych i odpowiednio zwróconych strzałek dla relacji skie-

rowanych. Przypisania atrybutów odzwierciedlane sa przez linie zakonczone rombem. Central-

nym elementem prezentowanego modelu jest prosty widok („Simple View”) danych logowania

(ang. login data). Strzałki prowadzace od niego do loginu uzytkownika (ang. user login) i ha-

sła (ang. password) wskazuja, ze zawiera on te dwie informacje. Sa one jednoczesnie atrybu-

tami pojecia danych autoryzacji (ang. authorization data). Kolejna strzałka okresla to pojecie

jako pojecie główne („main concept”), na którym bazuje widok danych logowania. Dodatkowo,

strzałka wiodaca od „formularza logowania” (ang. login form) do wspomnianego widoku da-

nych oznacza, ze formularz ten słuzy wprowadzaniu tych danych. Na diagramie znajduja sie

2.2. System ReDSeeDS 51

równiez wszystkie pozostałe pojecia wystepujace w scenariuszu z rysunku 2.5. Element o na-

zwie przycisk potwierdzenia (ang. confirmation button) jest powiazany poprzez dwie kolejne

relacje z dwoma innymi elementami. Pierwsza relacja definiuje, ze znajduje sie on na „for-

mularzu logowania”. Druga relacja okresla, ze uruchomienie przycisku powoduje przesłanie

„danych logowania”. Mamy tez zaznaczone powiazanie pomiedzy konceptami „danych auto-

ryzacji” i „uzytkownika” (ang. user), jednak zadne dalsze jego szczegóły nie sa precyzyjniej

zdefiniowane.

2.2 System ReDSeeDS

System ReDSeeDS [99, 85] jest narzedziem wspierajacym wytwarzanie oprogramowania stero-

wane modelami, bazujacym na jezyku RSL i opartym na platformie Eclipse [87, 18, 63]. Umoz-

liwia on tworzenie modeli przypadków uzycia, specyfikowania ich scenariuszy, a takze modeli

dziedzinowych. Tworzenie słownika wspierane jest przez automatyczne wyodrebnianie pojec

na podstawie uzytych w zdaniach scenariuszy fraz. Modele sa przechowywane w zgodnym z

meta-modelem jezyka RSL repozytorium zrealizowanym za pomoca biblioteki JGraLab [43].

Do generacji kodu wykorzystane sa transformacje napisane w jezyku MOLA. System ReDSe-

eDS posiada równiez wbudowane mechanizmy wspierajace ponowne wykorzystanie specyfika-

cji i kodu na podstawie porównywania podobienstwa specyfikacji w oparciu o przypisane do

nich znaczenia [108, 100] z serwera WordNet [68]. Dodatkowo, w ramach projektu REMICS

[71, 86] system rozbudowano o edytory graficzne wykonane w technologi GMF [73, 36], moz-

liwosc wykorzystania gotowych wzorców scenariuszy przypadków uzycia [1] i mechanizmy

wspierajace odzyskiwanie logiki aplikacji z zastanych systemów [90, 81].

Rysunek 2.8 przedstawia przykładowy podstawowy widok systemu ReDSeeDS. Po lewej

stronie znajduje sie drzewo projektu, które definiuje strukture specyfikacji wymagan – odpo-

wiedni podział na pakiety oraz umiejscowienie wymagan i pojec w pakietach. Po prawej stronie,

u góry okna programu pokazany jest jeden z diagramów przypadków uzycia. Po prawej stronie

na dole mamy natomiast pokazany edytor scenariuszy dla aktualnie wybranego przypadku uzy-

cia. Po zdefiniowaniu modelu wymagan, uzytkownik ma mozliwosc automatycznego wygene-


RYSUNEK 2.8: Podstawowy widok systemu ReDSeeDS

rowania modeli architektonicznych systemu zapisanych w jezyku UML oraz tresci wybranych

metod warstw interfejsu uzytkownika oraz logiki aplikacji. Modele oraz kod moga byc na-

stepnie przetwarzane odpowiednimi narzedziami zewnetrznymi – edytorami jezyka UML oraz

zintegrowanymi narzedziami programistycznymi. Wiecej informacji na temat sposobu działania

generatora kodu jezyka RSL, wbudowanego w narzedzie ReDSeeDS, zostało podane w ksiazce

Smiałka i Nowakowskiego [98]. W szczególnosci, podane sa tam przykłady kodu oraz elemen-

tów interfejsu uzytkownika, wygenerowanych bezposrednio ze specyfikacji podobnych do tej

przedstawionej w tym rozdziale.

53

Rozdział 3

Definicja jezyka RSL-DL

3.1 Załozenia i ogólna charakterystyka

Zgodnie z analiza dokonana w sekcji 1.4, zaden z omówionych tam jezyków nie okazał sie do-

statecznie dostosowany do wykorzystania w celu rozszerzenia systemu ReDSeeDS o mozliwosc

szczegółowego specyfikowania wiedzy dziedzinowej. Uwzgledniajac zatem potrzeby wynika-

jace z planowanej generacji kodu, podjeto decyzje o zaprojektowaniu nowego jezyka. Jezyk ten

nazwany został RSL-DL, czyli Requirements Specyfication Language - Domain Logic.

Projektujac jezyk przyjeto w stosunku do niego szereg załozen, w wiekszosci powiazanych

z wczesniej przedstawionymi wymaganiami i planowanym jego wykorzystaniem. Po pierwsze,

podobnie jak jezyk RSL, tworzony jezyk powinien byc w miare mozliwosci zrozumiały dla

osób nie posiadajacych profesjonalnej wiedzy z inzynierii oprogramowania. Ze wzgledu na

wymogi praktyczne zwiazane z generacja kodu, załozono tez, ze mozliwosc samodzielnego

tworzenia modeli przez nieprofesjonalistów nie bedzie traktowana jako priorytet. Powiazanym

z tym załozeniem, omówionym juz przy okazji omawiania wymagan, jest reprezentacja jezyka

za pomoca składni graficznej. Składania taka jest generalnie łatwiejszej do zrozumienia przez

osoby, które nie sa biegłe w tworzeniu opisów formalnych. Po drugie, załozono, ze modele w

jezyku RSL-DL powinny byc w jak najwiekszym stopniu niezalezne od konkretnej aplikacji,

dla której sa wykonywane. Dzieki temu powinno byc mozliwe ich wielokrotne zastosowanie

dla projektów z tego samego obszaru dziedzinowego. Po trzecie, załozono, ze gdzie to tylko

jest mozliwe jezyk powinien miec forme deklaratywna. Pominiecie informacji o szczegółach

sposobu realizacji konkretnych operacji, powinna pozwolic na zmniejszenie złozonosci modeli

54 Rozdział 3. Definicja jezyka RSL-DL

dziedziny i ułatwic posługiwanie sie projektowanym jezykiem.

Konstrukcje jezyka stworzono w oparciu o klasyfikacje rodzajów reguł, których mozna uzyc

do opisu logiki dziedzinowej. Wzieto tutaj pod uwage zarówno ich charakter, jak i pózniejsze

wykorzystanie. Ma to na celu stworzenie struktury, która dostarczy stosunkowo prosto przekła-

dalnych na kod pojedynczych reguł i wzorów. Ponadto, pozwala to na umieszczenie tych reguł

i wzorów w szerszym kontekscie, na podstawie którego da sie łatwo wywnioskowac sposób

ich uzycia oraz pozwoli na ich składanie w rozwiazania bardziej złozonych problemów. Formy

opisu tych reguł sa odpowiednio szczegółowo zdefiniowane, tak zeby umozliwiały wyrazenie

wszelkich niezbednych informacji potrzebnych do generacji na ich podstawie kodu. Powstała

struktura jest równiez w miare mozliwosci spójna z dotychczasowa forma reprezentacji pojec w

jezyku RSL. W ramach eksperymentu podjeta została równiez próba elastycznego odwzorowa-

nia w projektowanym jezyku hierarchii klas (konceptów). Chodzi tutaj o lepsze odwzorowanie

sposobu myslenia ludzi, poprzez uwzglednienie dynamicznej zmiany ról pełnionych przez po-

szczególne obiekty.

Proponowany jezyk słuzy uzupełnieniu opisanego w poprzednim rozdziale jezyka RSL i

stanowi rozwiniecie wybranych jego fragmentów. Naturalnym zatem jest, ze najbardziej ogólne

zasady definiujace strukture opisu dziedziny pozostaja takie same. Podobnie jak w przypadku

jezyka RSL, jezyk RSL-DL pozwala na definiowanie pojec dziedzinowych, i łaczenie ich od-

powiednimi relacjami, wskazujacymi na wystepujace miedzy nimi zaleznosci. Zakres stoso-

wanych pojec jest jednak nieco inny. Nie sa uwzgledniane elementy interfejsu uzytkownika, a

jedynie pojecia bezposrednio reprezentujace przetwarzane dane. Takich pojec wystepuje znacz-

nie wiecej niz w modelach tworzonych w jezyku RSL, gdyz utworzenia wymagaja takze pojecia

uzywane jedynie podczas przetwarzania danych, niedostepne dla uzytkownika koncowego. To

samo dotyczy relacji miedzy pojeciami. Uwzgledniane sa nie tylko strukturalne zaleznosci po-

miedzy danymi, ale równiez te o bardziej dynamicznym charakterze. Reprezentuja one bowiem

mozliwe sposoby przetwarzania danych i przekształcania jednych danych i inne. Szczegóło-

wosc opisu pojec i relacji jest takze zwiekszona, w celu umozliwienia okreslenia wszystkich

informacji niezbednych do automatycznego ich przetwarzania. Konieczne jest zwłaszcza do-

konanie zmian sposobu odzwierciedlania relacji na poziomie meta-modelu. Wynika to z tego,

3.1. Załozenia i ogólna charakterystyka 55

ze jezyk RSL nie umozliwia reprezentacji relacji wieloelementowych, które beda niezbedne do

adekwatnego odwzorowania wiedzy dziedzinowej.

Załozono, ze w stopniu, w jakim to bedzie mozliwe jezyk, RSL-DL bedzie korzystał ze

składni konkretnej analogicznej do tej wystepujacej w oryginalnym jezyku RSL. Przykładem

jest reprezentacja pojec, które w jezyku RSL-DL sa reprezentowane w bardzo podobny sposób.

Do przedstawiania nowych elementów i elementów wymagajacych zmiany formy (np. rela-

cje), zostały wykorzystane nowe reprezentacje. Formy tych reprezentacji zostały wybrane z

uwzglednieniem dystansu wizualnego miedzy nimi i prymatu kształtu w postrzeganiu przez

ludzi [72].

Załozono równiez, ze składnia tekstowych formuł uzywanych do definiowania reguł opisu-

jacych elementy modelu bedzie oparta o składnie stosowana przez biblioteke SymJa [51]. Ofe-

ruje ona intuicyjny zapis wzorów matematycznych, zblizony do formy uzywanej w wiekszosci

programów komputerowych. Zapis ten stosunkowo łatwo da sie rozwinac tak, zeby umozli-

wiał odzwierciedlanie pozostałych istotnych zaleznosci. Dodatkowo, pozwoli to zredukowac

potrzebe dokonywania konwersji wzorów podczas generacji kodu.

Specyfikacja jezyka została podzielona na cztery pakiety. Pakiet „Core” opisuje podsta-

wowe, najbardziej ogólne elementy jezyka i mozliwe zaleznosci miedzy nimi. Kolejne dwa pa-

kiety – „Notions” i „Relationships” definiuja szczegółowo rodzaje i sposób opisu pojec i relacji.

Wreszcie pakiet „Patterns” definiuje szczegóły przedstawiania wzorów uzytych w opisach po-

zostałych elementów, pozwalajacych wyznaczac i przekształcac poszczególne zwiazane z nimi

wartosci. Poza tymi czterema pakietami, istotnym elementem opisu jezyka RSL-DL jest skład-

nia dla zapytan przypisywanych do fraz jezyka RSL. Zapytania te umozliwiaja wyznaczanie

rodzaju generowanego na podstawie fraz kodu.

Całosc specyfikacji jezyka została zorganizowana w sposób wzorowany na specyfikacji

jezyka UML i innych podobnych jezyków. Dla kazdego pakietu przedstawiona została ko-

lejno składnia abstrakcyjna, nieformalny opis semantyki i przykłady prezentujace składnie kon-

kretna. Składnia abstrakcyjna zdefiniowana została za pomoca meta-modelu zapisanego w je-

zyku CMOF (wersja Complete MOF). Podczas opisu semantyki, pominieta została czesc ele-

mentów abstrakcyjnych. Elementy te zostały umieszczone w meta-modelu w celu poprawy jego


jakosci i uporzadkowania, lecz nie niosa same w sobie szczególnego znaczenia. Oprócz wstep-

nie zarysowanego opisu znaczenia elementów jezyka, jego semantyka jest równiez przedsta-

wiona w sposób formalny. Do tego celu uzyte zostało podejscie translacyjne, a odpowiednie

reguły zamieszczone w nastepnym rozdziale. Nalezy równiez zaznaczyc, ze przykłady składni

konkretnej nie beda podawane dla elementów abstrakcyjnych. Nie dotyczy to nielicznych wy-

jatków, kiedy wszystkie specjalizujace dany element abstrakcyjny elementy posiadaja powta-

rzajace sie elementy składni konkretnej.

3.2 Podstawowa struktura: pakiet „Core”

3.2.1 Składnia abstrakcyjna

Meta-model reprezentujacy zawartosc pakietu „Core” został przedstawiony na rysunku 3.1.

Podstawowe elementy jezyka w nim zawarte to relacje przedstawione za pomoca meta-klasy

„DLRelationship” i elementy mogace brac udział w tych relacjach przedstawione za pomoca

meta-klasy „DLRelationshipParticipant”. Powiazania miedzy jednymi a drugimi przedstawia

meta-klasa „DLRelationshipParticipation”, reprezentujaca uczestnictwo danego elementu w re-

lacji. Uczestnicy relacji dziela sie dalej na pojecia reprezentowane przez meta-klase „DLNo-

tion” i elementy podstawowe reprezentowane przez meta-klase „DLPrimitive”. Uczestnictwa w

relacji dziela sie z kolei na uczestnictwa standardowe reprezentowane przez meta-klase „DLStan-

dardRelationshipParticipation” i uczestnictwa pomocnicze reprezentowane przez meta klase

„DLAuxiliaryRelationshipParticipation”. Pojecia sa opisywane przez flage „derived” i typ roli,

który moze przyjac jedna z czterech wartosci – „identity”, „assigned_role”, „inferred_role” i

„template”. Dodatkowo, zarówno pojecia jak i relacje specjalizuja z elementu dziedzinowego

reprezentowanego przez meta-klase „DLDomainElement”. Pozwala to na ich przypisanie do

dziedzin reprezentowanych przez meta-klase „DLDomain”. Elementy dziedzinowe, elementy

podstawowe, jak równiez domeny posiadaja przypisane nazwy, a relacje posiadaja równiez

skrócona nazwe pozwalajaca na łatwiejsze odnoszenie sie do nich w innych fragmentach mo-

delu. Uczestnictwa w relacjach posiadaja nazwe poprzez specjalizacje meta-klasy „DLName-

3.2. Podstawowa struktura: pakiet „Core” 57

RYSUNEK 3.1: Meta-model dla podstawowej struktury jezyka RSL-DL (pakiet„Core”)

dLink”. Standardowe uczestnictwa w relacjach opisane sa przez skierowanie oraz licznosc.

Pomocnicze uczestnictwa posiadaja natomiast okreslony typ. Dodatkowo istnieje mozliwosc

przypisywania pomocniczych uczestnictw do uczestnictw standardowych i kazde uczestnic-

two pomocnicze musi posiadac co najmniej jedno takie przypisanie. Licznosc standardowego

uczestnictwa w relacji moze zostac okreslona jako pojedyncza („single”), mnoga („multiple”)

lub uporzadkowana mnoga („ordered multiple”). Skierowanie moze byc natomiast okreslone

jako zródło („source”), cel („target”), dwukierunkowe („bidirectional”) lub typu nieokreslo-


nego („undefined”). Typ pomocniczego uczestnictwa moze zostac okreslony jako wymagany

rodzic („required_parent”) lub przypisanie roli („role_attribution”).

3.2.2 Znaczenie

Relacja: DLRelationship

Relacje odzwierciedlaja dowolne powiazanie pomiedzy pojeciami lub elementami podstawo-

wymi, które moze zostac przełozone na funkcjonowanie kodu, badz strukture wykorzystywa-

nych danych. Semantyka konkretnej relacji zalezy od jej rodzaju i jej szczegóły zostana omó-

wione przy opisie poszczególnych typów relacji.

Uczestnictwo w relacji: DLRelationshipParticipation

Uczestnictwo w relacji słuzy do definiowania udziału w relacji poszczególnych elementów.

Umozliwia to precyzyjne okreslenie roli, jaka pełni kazdy z uczestników relacji. Standardowe

uczestnictwa okreslaja podstawowe informacje opisujace owa role, podczas gdy uczestnictwa

pomocnicze pozwalaja okreslic wszelakie dodatkowe zaleznosci z owa rola zwiazane.

Standardowe uczestnictwo w relacji: DLStandardRelationshipParticipation

Standardowe uczestnictwa w relacji definiuja podstawowe informacje o roli, która dany element

pełni w konkretnej relacji. Uczestnictwo tego typu przypisuje powiazanym elementom lokalne

nazwy, uzywane do odnoszenia sie do nich w obrebie opisu relacji. Rozwiazuje to problem

zwiazany z odzwierciedleniem sytuacji, gdy w danej relacji bierze udział wiele elementów tego

samego typu, wystepujacych jednak w róznych rolach. Uczestnictwa w relacji sa opisywane

przez skierowanie i licznosc. Licznosc okresla, czy w danej roli wystepuje pojedynczy element,

czy ich zbiór, a w wypadku zbioru, czy elementy posiadaja w nim okreslona kolejnosc. Ograni-

czono sie tylko do tych trzech wartosci, gdyz wieksza szczegółowosc nie przekłada sie na przy-

szła generacje kodu. Skierowanie moze równiez przyjac jedna z czterech wartosci. Okreslenie

danego elementu jako zródła oznacza, ze jest on wykorzystywany tylko do wyznaczania pozo-

stałych elementów i nie moze zostac na podstawie relacji wywnioskowany. Elementy okreslane


jako cel, odwrotnie, moga byc uzyskane na podstawie relacji, ale nie biora udziału w wyzna-

czaniu pozostałych elementów. Wreszcie elementy o nieokreslonym typie moga potencjalnie

zostac zarówno wyznaczone, jak i uzyte do wyznaczania pozostałych elementów, a elementy

dwukierunkowe beda wykorzystane do obydwu tych celów na raz.

Pomocnicze uczestnictwo w relacji: DLAuxiliaryRelationshipParticipation

Uczestnictwa pomocnicze w relacji sa przypisywane do uczestnictw standardowych i wskazuja

na wszelkie dodatkowe elementy zwiazane z opisywana przez nie rola. Ich konkretne znaczenie

zalezy od reprezentowanego przez nie typu. Pomocnicze uczestnictwo o typie „wymagany ro-

dzic” moze zostac przypisane do co najmniej dwóch standardowych uczestnictw wskazujacych

na atrybuty tego samego pojecia (patrz sekcja 3.3.2). W ten sposób wskazujemy, ze wszystkie

te atrybuty musza opisywac tego samego przedstawiciela danego pojecia. Przykładowo, jesli

chcemy obliczyc predkosc ciała na podstawie przebytej drogi i czasu, musimy zaznaczyc, ze

obydwie te wartosci musza opisywac ruch tego samego ciała, którego predkosc liczymy.

Pomocnicze uczestnictwo o typie „przypisanie roli” wykorzystujemy w sytuacji, kiedy wy-

znaczajac dany element na podstawie relacji, chcemy przypisac go do okreslonej roli reprezen-

towanej w postaci pojecia (patrz sekcja 3.2.2, nie mylic z rola pełniona w relacji). Kiedy ów

element jest wykorzystywany do wyznaczania innych elementów, moze byc do tej roli nie przy-

pisany, a zatem moze nie byc przedstawicielem tego pojecia. Nie mozemy wtedy odniesc sie

do pojecia reprezentujacego owa role w standardowym uczestnictwie. Uniemozliwiłoby to bo-

wiem wykorzystanie w relacji elementów nie bedacych jego przedstawicielami. Taka sytuacje

odzwierciedlamy za pomoca relacji pomocniczej wskazujacej na pojecie reprezentujace role,

która jest przypisana do uczestnictwa standardowego. Choc uczestnictwa pomocnicze tak samo

jak uczestnictwa standardowe przypisuja elementom lokalne nazwy, to pełnia one głównie po-

mocnicza role. Nazwy uczestnictw o typie „wymagany rodzic” nie powinny wystepowac we

wzorach, natomiast nazwy uczestnictw o typie „przypisanie roli” powinny byc identyczne do

nazw standardowych uczestnictw, z którymi sa one powiazane.


Pojecie: DLNotion

Pojecia reprezentuja dowolne elementy zwiazane z logika dziedzinowa, posiadajace co najmniej

jednego przedstawiciela. Przez przedstawiciela nalezy rozumiec element opisywany przez dana

dziedzine, którego pewne charakterystyki dane pojecie uogólnia. Tak długo wiec, jak ten ele-

ment bedzie posiadał owe charakterystyki mozemy powiedziec, ze bedzie on przypisany jako

przedstawiciel danego pojecia. W praktyce, pojecia moga zatem odpowiadac dowolnym by-

tom zwiazanym z opisywana dziedzina i wszelkim zbiorom opisujacych je danych. Generalnie

mozna powiedziec, ze pojecia sa równowazne konceptom uzywanym w jezykach opisu onto-

logii. Mozna równiez powiedziec, ze termin przedstawiciela pojecia odpowiada do jakiegos

stopnia terminowi instancji konceptu. W obydwu przypadkach mamy do czynienia z uogólnie-

niem w postaci konceptu, czy pojecia. Róznica jest jednak to, ze przedstawiciele pojec nie sa

w zaden bezposredni sposób opisywani przez jezyk RSL-DL. Ponadto, przypisanie konkret-

nego elementu jako przedstawiciela danego pojecia moze sie w pewnych wypadkach zmieniac.

Oznacza to, ze dany element moze w pewnych przypadkach byc przedstawicielem wielu róz-

nych pojec. Bardziej ogólne pojecia sa najczesciej równiez odpowiednikami pojec wystepuja-

cych w specyfikacji dziedzinowej jezyka RSL. W takim wypadku dane pojecie z jezyka RSL

powinno miec tylko jednego odpowiednika w jezyku RSL-DL. Przykładami pojec moga byc

„osoba”, „student”, „autor”, „imie”, „tytuł”, „ciało fizyczne” czy „masa spoczynkowa”.

Pojecia opisywane sa przez typ roli, który pełnia, zwiazany z momentem przypisania danego

pojecia do jego konkretnych przedstawicieli. Wyrózniamy cztery rodzaje typów pojec.

• Pojecia „identity”. Pojecia te definiuja tozsamosc swych przedstawicieli. Inaczej to ujmu-

jac, mozna powiedziec, ze uogólniaja one charakterystyki zwiazane z tozsamoscia. Tego

typu pojecia sa powiazane ze swoimi przedstawicielami od poczatku i na stałe. Mozna

powiedziec, ze kazdy opisywany przez dziedzine element powinien byc przedstawicie-

lem co najmniej jednego pojecia tego typu i bezposrednim przedstawicielem dokładnie

jednego pojecia tego typu. Nie dotyczy to tylko pojec, które dane pojecie specjalizuje.

Przykładami pojec o typie „identity” moga byc „osoba”, „zwierze” lub „figura geome-

tryczna”.


• Pojecia „assigned_role”. Pojecia te definiuja role, które moga byc w okreslonym mo-

mencie przypisywane do swoich przedstawicieli. Uogólniaja one charakterystyki, któ-

rych moment pojawienia sie (lub znikniecia) jest dobrze okreslony, a samo przejawianie

sie charakterystyk jest wzglednie stałe. W praktyce mozna zakładac, ze przypisanie tego

typu pojecia do przedstawiciela bedzie nadane (lub uniewaznione) w sposób jawny. Przy-

kładem pojecia o typie „assigned role” moze byc „student”. Zakładamy w tym wypadku,

ze istotne jest dla nas rozróznienie pomiedzy sytuacja osoby bedacej i nie bedacej studen-

tem, oraz mozliwosc zmiany jej statusu. Innymi przykładami takich pojec sa „absolwent

uczelni”, „lekarz” czy „zamknieta droga”.

• Pojecia „inferred_role”. Pojecia te definiuja role, których momentu przypisania do swo-

ich przedstawicieli nie da sie lub nie warto okreslac, a fakt jego istnienia interesuje nas

tylko w okreslonych sytuacjach. Okreslenie, czy dany element opisywany przez dziedzine

jest przedstawicielem tego typu pojecia bedzie wiec dokonywane na biezaco. Informacja

o tym przechowywana bedzie tylko tak długo, jak długo bedzie istotna, np. do czasu za-

konczenia konkretnych obliczen, czy operacji. Przykładem tego typu pojecia moga byc

„pasazer”, „kierowca” (w znaczeniu osoby aktualnie kierujacej pojazdem) lub „nieprze-

jezdna droga”. Specyficznym przykładem moze byc równiez pojecie „ciało fizyczne” w

kontekscie dziedziny obliczen wartosci fizycznych. Dzieki uzyciu typu „inferred role”

mozemy uniknac sytuacji, w której wszystkie elementy traktowane jako ciała fizyczne

musiałyby specjalizowac to pojecie o nadanym typie „identity”.

• Pojecia „template”. Pojecia te pełnia role zblizona do klas abstrakcyjnych w programowa-

niu, definiujac wzorce reprezentujace wspólne elementy innych pojec. Przedstawicielem

takiego pojecia mozna zostac tylko bedac lub zostajac przedstawicielem pojecia z niego

specjalizujacego. Przykładem takiego pojecia mógłby byc „pojazd”, w sytuacji w której

wyrózniamy równiez pojecia „samochód” i „pojazd nie bedacy samochodem”.

Dodatkowo, pojecia moga byc oznaczone jako „derived”. Oznacza to, ze zakwalifikowanie

przedstawiciela do danego pojecia jest zalezne od konkretnego wyprowadzenia. Oznaczenie to

dotyczy głównie pojec abstrakcyjnych w potocznym rozumieniu tego słowa.


RYSUNEK 3.2: Przykład pokazujacy składnie konkretna uczestnictwa w relacjibez skierowania

Dziedzina: DLDomain

Dziedzina reprezentuje pewien okreslony, wyodrebniony obszar wiedzy, do którego moga byc

przypisane pojecia i relacje. Jej istnienie pozwala na rozpatrywanie okreslonych problemów w

obrebie tylko fragmentu modelu. Warto zwrócic uwage, ze o ile dany element moze nalezec do

wielu dziedzin, to dwa tak samo nazwane elementy nie moga nalezec do tej samej dziedziny

(dotyczy to równiez skróconych nazw relacji). Dziedziny stanowia zatem przestrzenie nazw

dla elementów modelu. Nie przekładaja sie jednak na strukture, w jakiej model jest przecho-

wywany, czy sposób, w jaki jego elementy sa przedstawiane. Przykładami dziedzin moga byc

„rachunek rózniczkowy”, „instrumenty muzyczne” czy „mechanika klasyczna”.

Element podstawowy: DLPrimitive

Elementy podstawowe (prymitywy) reprezentujaca bardziej ogólne byty, których powiazanie

z konkretna dziedzina byłoby niewygodne lub niepotrzebne. Nie posiadaja one konkretnych

przedstawicieli i słuza uzyskaniu ogólnych informacji potrzebnych do realizacji logiki dzie-

dzinowej. Przykładem elementu podstawowego moze byc „aktualna data” lub „stała Eulera-

Mascheroniego”.

3.2.3 Składnia konkretna i przykłady

Standardowe uczestnictwo w relacjach: DLStandardRelationshipParticipation

Przykłady składni konkretnej dla uczestnictwa w relacji zostały zaprezentowane na rysunku 3.2.

Uczestnictwo reprezentowane jest za pomoca linii łaczacej relacje oznaczone szesciokatami


RYSUNEK 3.3: Przykład pokazujacy składnie konkretna uczestnictwa w relacjize skierowaniem

(patrz sekcja 3.4) i uczestników relacji oznaczonych prostokatami (patrz sekcja 3.3). Uczest-

nictwo w relacji moze byc wyposazone w grot. Grot wskazuje w kierunku relacji, jesli jest to

uczestnictwo typu zródło („source”) lub wskazuje w kierunku uczestnika relacji, jesli jest to

uczestnictwo typu cel („target”). Reprezentacja uczestnictw o nieokreslonym skierowaniu nie

posiada grotu, natomiast uczestnictwo o skierowaniu dwustronnym posiada groty w obydwu

kierunkach. Kazde uczestnictwo jest opisane równiez nazwa i licznoscia.

Opisana składnia została przedstawiona w oparciu o trzy proste przykłady. Pierwszy z nich

jest zaprezentowany na rysunku 3.2 i pokazuje uczestnictwo dzieła („work”) i autora („author”)

w relacji autorstwa („authorship”). Zadne z uczestnictw nie posiada grotów, jako ze zarówno

autor jak i dzieło moga byc zródłem badz celem relacji. Obydwa te elementy moga byc wy-

wiedzione nawzajem jeden z drugiego na podstawie relacji miedzy nimi (np. okreslenie autora

na podstawie jego dzieła). W drugim przykładzie, pokazanym na rysunku 3.3, mamy przedsta-

wione uczestnictwo imienia („name”) i nazwiska („surname”) danej osoby („person”, np. autor

z pierwszego przykładu) w relacji („extract initials”) pozwalajacej okreslic na ich podstawie

inicjały („initials”) tej osoby. Wywiedzenie to jest mozliwe tylko w jedna strone – na podstawie

imienia i nazwiska da sie uzyskac inicjały, natomiast nie da sie uzyskac imienia z nazwiska

lub inicjałów i nazwiska z inicjałów lub imienia. Zatem, uczestnictwo inicjałów okreslone jest

jako cel, a uczestnictwa imienia i nazwiska jako zródła. Trzeci przykład na rysunku 3.4 zawiera

uczestnictwo pojecia reprezentujacego nazwe („name”) w relacji przekształcenia zmieniajacego

jej zapis na notacje Camel Case („Camel Case Transition”). Jako ze uczestnictwo ma skierowa-


RYSUNEK 3.4: Przykład pokazujacy składnie konkretna uczestnictwa w relacjize skierowaniem dwustronnym

RYSUNEK 3.5: Przykład pokazujacy składnie konkretna pomocniczego uczest-nictwa w relacji

nie dwustronne, nalezy sie spodziewac ze podana nazwa zostanie zmodyfikowana. Nalezy tez

zwrócic uwage na to, ze w praktyce moga oczywiscie wystepowac o wiele bardziej skompliko-

wane kombinacje skierowania uczestnictw, niz w zaprezentowanych przykładach.

Pomocnicze uczestnictwo w relacji: DLAuxiliaryRelationshipParticipation

Przykład składni konkretnej dla pomocniczego uczestnictwa w relacji zawarty jest na rysunku

3.5. Przedstawia on relacje „escape velocity computation”, umozliwiajaca wyliczenie predkosci

ucieczki z danej planety („escape velocity from planet”) na podstawie jej masy („planet mass”)

i promienia („planet radius”). Pomocnicze uczestnictwo reprezentowane jest za pomoca prze-

rywanej linii. Tutaj słuzy ono do okreslenia wymogu, ze masa i promien musza dotyczyc tej

samej planety, dla której obliczamy predkosc ucieczki.

3.3. Pojecia: pakiet „Notions” 65

RYSUNEK 3.6: Przykład pokazujacy składnie konkretna elementu podstawowego

Element podstawowy: DLPrimitive

Przykład składni konkretnej dla elementu podstawowego został zaprezentowany na rysunku

3.6. Jak mozna zaobserwowac, element podstawowy reprezentowany jest przez owal zawie-

rajacy nazwe elementu, z umieszczonym nad nia słowem kluczowym „Primitive”. Przykład

przedstawia element podstawowy reprezentujacy wartosc zmiennej srodowiskowej zawieraja-

cej sciezke do katalogu domowego uzytkownika („HOME_PATH”). Element ten uczestniczy

w relacji („indicated home directory”), pozwalajacej zidentyfikowac wskazany przez sciezke

katalog („directory”).

3.3 Pojecia: pakiet „Notions”


Meta-model pokazujacy strukture elementów zawartych w pakiecie „Notions” przedstawiony

jest na rysunku 3.7. Zgodnie z tym meta-modelem pojecia („DLNotion”) dziela sie na byty

reprezentowane przez meta-klase „DLEntity” i własciwosci reprezentowane przez meta-klase

„DLProperty”. Własciwosci maja przypisany typ wartosci („valueType”), który reprezentuja.

W zakres mozliwych przypisan wchodza typy dostepne w jezyku RSL: tekst („string”), wartosc

logiczna („boolean”), liczba naturalna („integer”), liczba zmiennoprzecinkowa („float”) , data

(„date”) oraz czas („time”). Do tego, RSL-DL wprowadza nowe rodzaje wartosci: zbiór (,set”),

zbiór uporzadkowany („oredered_set”), typ wyliczeniowy („enumeration”), wartosc złozona


RYSUNEK 3.7: Meta-model dla pojec (pakiet „Notions”)

(„composite”) i wartosc odziedziczona („inherited”).

Pojecia opisywane sa przez cechy reprezentowane przez meta-klase „DLFeature”. Cechy

dalej dziela sie na przypisania atrybutów, wskazujace na własciwosci i reprezentowane przez

meta-klase „DLAttributeLink”, przypisania czesci wskazujace na powiazanie dereferencyjne

reprezentowane przez meta-klase „DLPartLink” oraz warunki reprezentowane przez meta-klase


„DLCondition”. Warunki dziela sie na warunki dziedziczenia reprezentowane przez meta-klase

„DLInheritanceCondition”, które wskazuja na inne pojecia, a takze warunki tozsamosci i wa-

runki poprawnosci reprezentowane kolejno przez meta-klasy „DLIdentityCondition” i „DLVa-

lidityCondition”. Te dwa ostatnie, dzieki specjalizacji meta-klasy „DLPatternCondition” moga

miec przypisane wzory warunków reprezentowane przez meta-klase „DLConditionPattern”.

Dodatkowo, zarówno przypisania atrybutów jak i warunki dziedziczenia posiadaja okreslony

typ, który moze przyjac jedna z dwóch wartosci. Kazdy z tych elementów moze byc dostarczany

(„provided”) lub wymagany („required”). Mozliwe jest takze definiowanie powiazan dereferen-

cyjnych reprezentowanych przez meta-klase „DLDereferenceLink”, opisanych przez licznosc i

tekst jej formuły. Takie powiazania sa składnikami dowolnych elementów dziedzinowych oraz

wskazuja na pojecia. Zarówno powiazania dereferencyjne jak i przypisania atrybutów maja

równiez nadane nazwy, dzieki specjalizacji meta-klasy „DLNamedLink”.

3.3.2 Znaczenie

Byt: DLEntity

Byty reprezentuja bardziej złozone, niezalezne pojecia nie powiazane z zadna konkretna war-

toscia. Sa to podstawowe elementy wykorzystywane do reprezentowania struktury pojec opi-

sujacych dana dziedzine. Byty o typie „identity” pod wieloma wzgledami przypominaja byty

według podejscia DDD – kazdy z nich zwiazany jest z tozsamoscia niezalezna od opisujacych

go danych. Rozróznienie pomiedzy bytami a własciwosciami mozna równiez w jakims stopniu

traktowac jako odzwierciedlajace podział na substancje (ang. substances) i jakosci (ang. quali-

ties) według Neuhausa ze współautorami [80]. To wyróznienie w postaci osobnych meta-klas

było czesciowo inspirowane tym podziałem. Przykładami bytów moga byc „osoba”, „student”,

„autor”, czy „ciało fizyczne”.

Własciwosc: DLProperty

Własciwosci odzwierciedlaja prostsze pojecia, które reprezentuja konkretne wartosci (lub ewen-

tualnie ich zbiory) i czesto sa uzywane do opisu bardziej złozonych pojec. Podobnie jak w


przypadku obiektów reprezentujacych wartosc w podejsciu DDD, tozsamosc własciwosci o ty-

pie „identity” zwiazana jest z wartoscia, która reprezentuje. Przykładami własciwosci moga

byc „imie” i „tytuł” reprezentowane jako tekst, czy „masa spoczynkowa” reprezentowana jako

liczba rzeczywista. Oprócz powszechnie spotykanych rodzajów danych, własciwosci moga rów-

niez reprezentowac zbiór złozony z przedstawicieli innych pojec, zarówno w formie uporzad-

kowanej („oredered_set”), jak i bez okreslonej kolejnosci elementów („set”). Wystepuja takze

własciwosci, których wartoscia jest zbiór wartosci wszystkich opisujacych je atrybutów (typ

„composed”). Szczególnym typem wartosci, który moze byc reprezentowany przez własciwo-

sci, jest dziedziczenie („inherited”). Wartosc tego typu własciwosci zalezy wtedy od innych

pojec – od tych, z których ona dziedziczy w wypadku typu „identity” lub od tych, do których

zostanie przypisana w wypadku typów „assigned_role” i „inferred_role”.

Przypisanie atrybutu: DLAttributeLink

Przypisania atrybutów pozwalaja uzyc innych pojec do opisu pojecia, które definiuja. Naste-

puje to poprzez powiazanie pojec pełniacych role atrybutów z innym pojeciem. Przypisania

atrybutów nadaja tez powiazanym elementom lokalne nazwy, uzywane do odnoszenia sie do

nich w obrebie opisu danego pojecia. Dodatkowo, sytuacja, w której pojecie przypisywane jako

atrybut jest oznaczone jako „derived” powoduje, ze jego wartosc jest na biezaco wyprowa-

dzana. Warto zauwazyc, ze zgodnie z meta-modelem, jedynie pojecia zwiazane z konkretna

wartoscia („DLProperty”) moga byc uzyte jako atrybuty, a zaleznosci pomiedzy bardziej złozo-

nymi pojeciami musza byc reprezentowane w formie relacji. Na przykład, pojecie „imie” moze

byc przypisane jako atrybut pojecia „osoba”, pojecie „masa spoczynkowa” jako atrybut „ciała

fizycznego”, badz „tytuł” jako atrybut „ksiazki”. Nie da sie natomiast za pomoca tego mecha-

nizmu odzwierciedlic powiazania pomiedzy złozonymi pojeciami jak „ksiazka” i „autor”.

Przypisanie pojecia jako atrybutu opisane jest dodatkowo poprzez typ tego przypisania

(„DLFeatureType”). Wartosc dostarczana („provided”) oznacza, ze istnienie danego atrybutu

jest czescia definicji danego pojecia. Z kolei, wartosc wymagana („required”), stosowana tylko

w wypadku pojec o typach „inferred_role” i „assigned_role” oznacza, ze posiadanie takiego

atrybutu jest warunkiem koniecznym do przypisania roli reprezentowanej przez to pojecie.


Przypisanie czesci: DLPartLink

Przypisania czesci pozwalaja zadeklarowac pojecia bedace składnikami (czesciami) innych po-

jec. Pozwala to traktowac dane z tak powiazanych pojec jako jedna całosc przy róznych opera-

cjach zwiazanych z ich przechowywaniem. Przykładem przypisania czesci moze byc okreslenie

pojecia „silnik”, jako czesci przypisanej do pojecia „samochód”. Przypisania czesci definiuje

sie za pomoca powiazan dereferencyjnych przypisanych do pojec.

Warunek dziedziczenia: DLInheritanceCondition

Warunki dziedziczenia słuza do definiowania relacji dziedziczenia pomiedzy pojeciami, czyli

zaleznosci pomiedzy bardziej ogólnymi pojeciami, a ich szczególnymi przypadkami. Jako ze

nie został zdefiniowany zaden sposób zastepowania odziedziczonych cech, odpowiada to rów-

niez zaleznosci subsumcji miedzy nimi (patrz sekcja 1.3.2). Konkretna interpretacja elementu

„DLInheritanceCondition” zalezy od rodzaju pojecia, do którego jest przypisany ten warunek.

Przedstawiciele pojec typu „identity” sa do nich przypisani od poczatku swojego cyklu zycia.

Zatem, musza oni byc tez od poczatku przedstawicielami odpowiednich ogólniejszych pojec.

W wypadku dwóch nastepnych typów pojec („assigned_role” i „inferred_role”), przynaleznosc

obiektu do danego pojecia moze zostac nabyta w trakcie jego cyklu zycia. W takim wypadku

przynaleznosc do bardziej ogólniejszych pojec moze byc zarówno z góry wymagana, zeby takie

nabycie było mozliwe, jak i moze byc nabywana razem z przynaleznoscia do bardziej szczegó-

łowego pojecia. Rozróznienie miedzy tymi dwiema ewentualnosciami jest dokonywane poprzez

oznaczenie danego warunku dziedziczenia odpowiednio jako „required” lub „provided”.

Przykładowo, załózmy, ze „student” jest pojeciem typu „assigned_role” dziedziczacym z

pojecia „osoba” poprzez warunek o typie „required”. W takiej sytuacji, aby móc przedstawiciela

przypisac do pojecia „student”, to musi on byc wczesniej przypisany jako przedstawiciel pojecia

„osoba”. Natomiast, w ramach kolejnego przykładu, jesli „recepcjonista” jest pojeciem typu

„assigned_role” dziedziczacym z pojecia „pracownik” przez warunek o typie „provided”, to

podczas przypisania do danego przedstawiciela roli recepcjonisty, zyskuje on tez wszystkie

cechy pracownika. Warto jednak zauwazyc, ze opisana interpretacje stosuje sie tylko wtedy,


kiedy jest ona mozliwa i ma sens. Na przykład, warunki dziedziczenia wskazujace na pojecia

typu „identity” zawsze musza byc typu „required”.

„DLInheritanceCondition” moze równiez wskazywac na wiecej niz jedno pojecie. Oznacza

to, ze dane pojecie moze byc szczególnym przypadkiem któregokolwiek z pojec, aczkolwiek

ma to sens tylko w wypadku pojec, do których przynaleznosc jest przypisywana. Natomiast

do odzwierciedlenia sytuacji odwrotnej, w której dane pojecie dziedziczy z wielu ogólniej-

szych pojec, nalezy uzyc „DLInheritanceCondition” wielokrotnie. Przykładowo do oznaczenia,

ze „celem łuczniczym” moze byc „jabłko” lub „słomiana tarcza” uzyjemy pojedynczego wa-

runku wskazujacego na obydwa te pojecia, natomiast dla pokazania, ze „pracujacy student”

musi byc zarówno „studentem” jak i „pracownikiem” uzyjemy dwóch warunków dziedzicze-

nia, z których jeden bedzie wskazywał na „pracownika”, a drugi na „studenta”. Warto równiez

zauwazyc, ze nie jest dopuszczone wystapienie zadnego ciagu dziedziczacych z siebie pojec, w

którym wystepuja własnosci powiazane z róznymi rodzajami wartosci.

Warunek tozsamosci: DLIdentityCondition

Warunki tozsamosci okreslaja warunki, które musza byc spełnione przez kazdego przedstawi-

ciela danego pojecia. Nie powinni istniec przedstawiciele danego pojecia nie spełniajacy tych

warunków, ani nie powinna byc mozliwa zmiana przedstawiciela w taki sposób, zeby przestał te

warunki spełniac. Dodatkowo, obiekty, które sa przypisywane w trakcie swego cyklu zycia do

danego pojecia musza spełniac zadane warunki tozsamosci, jesli przypisanie ma byc mozliwe.

Przykładowo, cecha numeru PESEL jest posiadanie jedenastu cyfr i nie powinno byc mozli-

wosci stworzenia numeru PESEL o innej liczbie cyfr, jak równiez uznania za numer PESEL

numeru składajacego sie z innej liczby cyfr. Podobnie cecha ciała fizycznego jest koniecznosc

posiadania niezerowej masy spoczynkowej.

Warunek poprawnosci: DLValidityCondition

Warunki poprawnosci okreslaja kryteria, które musza byc spełnione, zeby obiekt był uznany

za prawidłowego przedstawiciela danego pojecia. Oznacza to, ze obiekty nie spełniajace wa-

runków poprawnosci moga istniec, jednak beda uznane za nieprawidłowe. Taka sytuacja moze


miec znaczenie dla dalszego przetwarzania tych obiektów. Przykładowo, mozna załozyc, ze o

ile numer PESEL powinien miec własciwa sume kontrolna, to dopuszczamy istnienie w two-

rzonym systemie numerów z niepoprawna suma, które maja zostac w przyszłosci poprawione

przez uzytkownika.

Powiazanie dereferencyjne: DLDereferenceLink

Rola powiazan dereferencyjnych jest ułatwienie odnoszenia sie do powiazanych elementów,

wykorzystywanych podczas opisu danego elementu dziedzinowego; w szczególnosci podczas

definiowania opisujacych go warunków. Powiazania dereferencyjne pozwalaja na przypisanie

do wybranej nazwy w obrebie danego elementu, prostej formuły wskazujacej na inny powia-

zany element. Nazwa ta moze byc wtedy uzywana zamiast tej formuły. Konieczne jest jednak

równiez wskazanie pojecia bedacego elementem docelowym i jego licznosci. Przykładowo,

dla ksiazek mozna stworzyc powiazanie dereferencyjne o nazwie „imiona_autorów” wskazu-

jace na atrybut „imie” zawarty w pojeciu „autor”, powiazanym odpowiednia relacja z pojeciem

„ksiazka”.


Byt: DLEntity

Przykład składni konkretnej dla bytów został zaprezentowany na rysunku 3.8. Reprezentowane

sa one przez prostokat zawierajacy w górnej czesci nazwe danego bytu. Nad nazwa znajduje sie

zapisana kursywa nazwa typu roli, która dany byt jako pojecie pełni. Zaprezentowany przykład

zawiera piec elementów bedacych bytami, wraz z innymi pojeciami koniecznymi do sensow-

nego ich zdefiniowania. Mamy tu trzy byty reprezentujace rózne zawody w branzy medycznej,

które dana osoba moze wykonywac w ciagu swojego zycia. Sa to byty: lekarz („physician”),

pielegniarka („nurse”) i ratownik medyczny („paramedic”), stanowiace przypisywane role („as-

signed role”). Mamy tez byt pracownik („employee”), okreslajacy role wzorcowa („template”).

Byt ten reprezentuje wspólne cechy trzech poprzednich bytów, wystepujace z racji reprezen-

towania przez nie poszczególnych zawodów. Mamy wreszcie byt reprezentujacy osobe upraw-


RYSUNEK 3.8: Przykład pokazujacy składnie konkretna bytów

niona do podwyzki („entitled to raise”), stanowiacy role wnioskowana („inferred role”). Rola

ta zostanie automatycznie przypisana do osób które sie do niej kwalifikuja, co pozwoli na od-

noszenie sie do nich za pomoca tego pojecia. Posrednio obecny w przykładzie jest tez element

typu „identity”, w postaci odwołania dziedziczenia do bytu osoby („person”). Bycie przedsta-

wicielem tego bytu jest warunkiem koniecznym do bycia przypisanym jako przedstawiciel do

któregokolwiek z pojec reprezentujacych zawody.

Własciwosc: DLProperty

Przykład składni konkretnej dla własciwosci został zaprezentowany na rysunku 3.9. Podobnie

jak byty, własciwosci reprezentowane sa przez prostokaty zawierajace w górnej czesci nazwe

danej własciwosci. Nad nazwa znajduja sie – zapisane kursywa – nazwa typu roli, która dana

własciwosc jako pojecie pełni i nazwa typu, który ona reprezentuje. Nazwa typu jest zawarta

w nawiasie i poprzedzona słowem kluczowym „value”. Przykład zawiera szereg własciwosci


RYSUNEK 3.9: Przykład pokazujacy składnie konkretna własciwosci

RYSUNEK 3.10: Przykład pokazujacy składnie konkretna przypisan atrybutów

pełniacych swoja typowa funkcje, czyli opisujacych inne, bardziej złozone pojecia. Mamy tutaj

własciwosci reprezentujace tytuł („title”), nazwe gatunku literackiego („genre name”) i pseudo-

nim pisarski („pen name”) jako napisy, liczbe stron („number of pages”) jako liczbe całkowita

i date wydania („publication date”) jako date.

Przypisanie atrybutów: DLAttributeLink

Przykład składni konkretnej dla przypisan atrybutów został zaprezentowany na rysunku 3.10.

Tak samo jak w jezyku RSL (patrz sekcja 2.1.2), reprezentowane sa one za pomoca linii łacza-

cej pojecie reprezentujace atrybut z pojeciem przez niego opisywanym, zakonczonej rombem


RYSUNEK 3.11: Przykład pokazujacy składnie konkretna warunków dziedzicze-nia

od strony opisywanego pojecia. Dodatkowo, przypisania atrybutów opisane sa równiez przez

lokalna nazwe atrybutu. W przykładzie przedstawione sa trzy atrybuty opisujace osobe miesz-

kajaca w Polsce – date urodzenia („birth date”), płec („sex”) i numer PESEL („pesel number”).

Połaczone sa one z pojeciem osoby mieszkajacej w Polsce („resident of poland”) w opisany

wczesniej sposób. Lokalne nazwy atrybutów w tym przykładzie stanowia po prostu powtórze-

nie nazw odpowiednich pojec atrybutów, zapisanych w notacji Camel Case. Choc nie jest to

przedstawione w składni konkretnej, mozemy tez domyslac sie, ze numer PESEL jest atrybu-

tem typu „provided”. Wynika to z tego, ze nadanie tego numeru zwiazane jest z zamieszkaniem

na terenie Polski (urodzeniem, nadaniem obywatelstwa itp.). Z kolei, płec i rok urodzenia sa

atrybutami typu „required”. Ich posiadanie jest wymagane do przypisania wspomnianej roli do

osoby i nadania numeru PESEL.

Warunek dziedziczenia: DLInheritanceCondition

Przykład składni konkretnej dla warunków dziedziczenia został zaprezentowany na rysunku

3.11. Reprezentowane sa one przez prostokat o zaokraglonych rogach umieszczony wewnatrz

prostokata reprezentujacego pojecie, którego warunek dotyczy. Dodatkowo, w górnej czesci

prostokata warunku znajduje sie zapisane kursywa sformułowanie „inheritanceCondition”. W


RYSUNEK 3.12: Przykład pokazujacy składnie konkretna warunków tozsamosci

jego srodku umieszczona jest nazwa lub nazwy pojec, na które wskazuje ten warunek. Na-

zwa wskazywanego w warunku pojecia oznacza pojecie ogólne, po którym dziedziczy pojecie

z zawartym w nim danym warunkiem. Przedstawiony przykład pokazuje wykorzystanie tego

typu warunków do odzwierciedlenia taksonomii kilku wybranych figur geometrycznych. Na

rysunku widzimy pojecie wielokat („polygon”), którego szczególnymi przypadkami sa wielo-

kat foremny („regular polygon”) i czworokat („quadrilateral”). Mamy równiez przedstawiony

kwadrat („square”), który jest zarówno czworokatem, jak i wielokatem foremnym. Warto za-

uwazyc, ze nie ma potrzeby ponownego definiowania cech i atrybutów ogólniejszych pojec dla

pojec bardziej szczegółowych, gdyz ich przypisanie do tych pierwszych oznacza takze przypi-

sanie do tych drugich.

Warunek tozsamosci: DLIdentityCondition

Przykład składni konkretnej dla warunków tozsamosci został zaprezentowany na rysunku 3.12.

Reprezentowane sa one przez prostokat o zaokraglonych rogach umieszczony w srodku prosto-

kata reprezentujacego pojecie, którego warunek dotyczy. Dodatkowo, w górnej czesci pierw-

szego z prostokatów znajduje sie zapisane kursywa sformułowanie „identityCondition’. We-

wnatrz prostokata znajduje sie formuła warunku. Przykład ilustruje wymaganie posiadania do-


RYSUNEK 3.13: Przykład pokazujacy składnie konkretna warunków poprawno-sci

kładnie jedenastu cyfr dla numeru PESEL. Informacje na temat szczegółów składni wykorzy-

stanych formuł sa zamieszczone w sekcji 3.5.

Warunek poprawnosci: DLValidityCondition

Przykład składni konkretnej dla warunków poprawnosci został zaprezentowany na rysunku

3.13. Reprezentowane sa one przez prostokat o zaokraglonych rogach umieszczony w srodku

prostokata reprezentujacego pojecie, którego warunek dotyczy. Dodatkowo, w górnej czesci

pierwszego z prostokatów znajduje sie zapisane kursywa sformułowanie „validityCondition”.

Wewnatrz prostokata znajduje sie formuła warunku. Przykład ilustruje warunek poprawnosci

dla numeru PESEL, jakim jest posiadanie własciwej sumy kontrolnej. Informacje na temat

szczegółów składni wykorzystanych formuł sa zamieszczone w sekcji 3.5.

3.4. Relacje: pakiet „Relationships” 77

RYSUNEK 3.14: Reprezentacja relacji w meta-modelu

3.4 Relacje: pakiet „Relationships”


Rysunek 3.14 przedstawia meta-model obrazujacy strukture elementów pakietu „Relationships”.

Relacje dziela sie na odniesienia reprezentowane przez meta-klase „DLReference” i przekształ-

cenia reprezentowane przez meta-klase „DLTransition”. Odniesienia dziela sie dalej na odnie-

sienia oparte o wzory, reprezentowane przez meta-klase „DLPatternBasedReference” i odnie-

sienia oparte o dane, reprezentowane przez meta-klase „DLDataBasedReference”. Przekształ-

cenia równiez zostały dalej podzielone na przekształcenia oparte o wzory, reprezentowane przez

meta-klase „DLPatternBasedTransition” i przekształcenia algorytmiczne, reprezentowane przez

klase „DLAlghoritmicTransition”. Przekształcenia algorytmiczne maja przypisane sekwencje

kroków, reprezentowane przez listy przedstawicieli meta-klasy „DLAlghoritmicTransitionSe-


quenceElement”. Przekształcenia oparte o wzory maja przypisane wzory przekształcen, repre-

zentowane przez meta-klase „DLTransitionPattern”, a odniesienia oparte o wzory maja przy-

pisane wzory warunków, reprezentowane przez meta-klase „DLConditionPattern”. Szczegóły

składni formuł wykorzystywanych we wzorach sa opisane w sekcji 3.5.

3.4.2 Znaczenie

Odniesienie: DLReference

Odniesienia słuza do okreslania jakie sa poszczególne relacje miedzy pojeciami (jak pojecia

maja sie w stosunku do siebie). Wykorzystujac odniesienia, mozna na podstawie jednego po-

jecia znalezc zarówno inne juz istniejace pojecia spełniajace dana zaleznosc, jak i po prostu

sprawdzic zachodzenie danej zaleznosci dla okreslonych pojec. Ogólnie mozna powiedziec, ze

odniesienia odpowiadaja co najmniej dwuelementowym relacjom z jezyków opisu ontologii.

Przekształcenie: DLTransition

Przekształcenia słuza do okreslania jak na podstawie jednych pojec wyznaczyc inne, badz jak

przekształcac jedne z nich w drugie. W odróznieniu od odniesien pozwalaja one generowac

nowe elementy i wartosci.

Odniesienie oparte o wzory: DLPatternBasedReference

Odniesienia oparte o wzory słuza do odzwierciedlania sytuacji, w której zaleznosc pomiedzy

pojeciami da sie wyprowadzic na podstawie zbioru opisujacych ja reguł. Przykładem moze byc

tu relacja bycia rodzenstwem zdefiniowana jako zaleznosc pomiedzy dwoma róznymi osobami

posiadajacymi tych samych rodziców.

Odniesienie oparte o dane: DLDataBasedReference

Odniesienia oparte o dane stosuje sie je w wypadkach kiedy informacje o zaleznosciach sa

bezposrednio zdefiniowane, najczesciej poprzez zawarcie ich w jakichs zewnetrznych zbiorach


danych np. w relacyjnej bazie danych. Przykładem tego typu relacji moze byc powiazanie po-

miedzy autorem, a napisanymi przez niego ksiazkami.

Przekształcenie oparte o wzory: DLPatternBasedTransition

Przekształcenia oparte o wzory słuza do specyfikowania za pomoca wzorów pojedynczych

przekształcen, których kolejnosc zastosowania moze zostac automatycznie wywnioskowana.

Ogólnie mozna powiedziec, ze do jakiegos stopnia odpowiadaja one funkcjom z jezyków opisu

ontologii. Przy tym, na podstawie jednego przekształcenia mozna najczesciej uzyskac wiele

róznych funkcji zwracajacych poszczególne mozliwe do uzyskania na jego podstawie wartosci.

Jako przykład przekształcen opartych o wzory, moze posłuzyc obliczanie predkosci obiektu na

podstawie jego przesuniecia i czasu, w jakim ono trwało.

Przekształcenie algorytmiczne: DLAlgorithmicTransition

Przekształcenia algorytmiczne pozwalaja połaczyc szereg przekształcen w okreslona kolejnosc,

w razie potrzeby uzalezniona równiez od spełnienia okreslonych warunków. Warto zauwazyc,

ze o ile w wielu przypadkach modyfikacje obiektów da sie zapisac za pomoca czysto deklara-

tywnych w swojej naturze przekształcen opartych o wzory, o tyle modyfikacje o bardziej impe-

ratywnym charakterze znacznie wygodniej jest reprezentowac własnie za pomoca przekształcen

algorytmicznych. Warto zwrócic równiez uwage na pewne podobienstwo przekształcen algoryt-

micznych do procedur w jezyku OCML, słuzacych jako narzedzie do zapisywania modyfikacji,

których nie da sie wyrazic za pomoca funkcji. Jako przykład przekształcenia algorytmicznego

moze posłuzyc posortowanie listy za pomoca algorytmu sortowania babelkowego.


Odniesienie oparte o wzory: DLPatternBasedReference

Przykład składni konkretnej dla odniesien opartych o wzory został zaprezentowany na rysunku

3.15. Jak wszystkie relacje przedstawiane sa one w formie szesciokata zawierajacego na srodku

nazwe relacji. Dodatkowo, posiadaja równiez w górnej czesci zapisane kursywa sformułowanie


RYSUNEK 3.15: Przykład pokazujacy składnie konkretna odniesienia opartego owzory

„Pattern Based Reference”. Przykład przedstawia wspomniana wczesniej relacje bycia rodzen-

stwem jako relacje posiadania tej samej matki i ojca.

Odniesienie oparte o dane: DLDataBasedReference

Przykład składni konkretnej dla odniesien opartych o dane został zaprezentowany na rysunku

3.16. Jak wszystkie relacje, przedstawiane sa one w formie szesciokata zwierajacego na srodku

nazwe relacji. Dodatkowo posiadaja równiez w górnej czesci zapisane kursywa sformułowanie

„Data Based Reference”. Przykład zawiera dwa odniesienia oparte o wzory. Pierwsze z nich re-

prezentuje zawarty w danych zwiazek pomiedzy klientem („customer”), złozonym przez niego

zamówieniem („purchase”) i pozycjami tego zamówienia („purchase item”). Drugie odniesienie

wiaze pozycje zamówienia z rodzajem i liczba sztuk zakupionego towaru.


RYSUNEK 3.16: Przykład pokazujacy składnie konkretna odniesienia opartego odane

RYSUNEK 3.17: Przykład pokazujacy składnie konkretna przekształcenia opar-tego o wzór

Przekształcenie oparte o wzory: DLPatternBasedTransition

Przykład składni konkretnej dla przekształcen opartych o wzór został zaprezentowany na ry-

sunku 3.17. Jak wszystkie relacje, przedstawiane sa one w formie szesciokata zawierajacego

na srodku nazwe relacji. Dodatkowo posiadaja równiez w górnej czesci zapisane kursywa sfor-

mułowanie „Pattern Based Transition”. Przekształcenie zawarte w przykładzie wiaze dystans

danego ruchu i czas jaki zajeło jego pokonanie, pozwalajac okreslic na ich podstawie srednia


RYSUNEK 3.18: Przykład pokazujacy składnie konkretna przekształcenia algo-rytmicznego

predkosc.

Przekształcenie algorytmiczne: DLAlgorithmicTransition

Przykład składni konkretnej dla przekształcen algorytmicznych został zaprezentowany na ry-

sunku 3.18. Jak wszystkie relacje, przedstawiane sa one w formie szesciokata zawierajacego na

srodku nazwe relacji. Dodatkowo posiadaja równiez w górnej czesci zapisane kursywa sformu-

łowanie „Alghorithmic Transition”. Przykład przedstawia zastosowanie algorytmu sortowania

babelkowego do przekształcenia nieposortowanej listy w posortowana. Zawiera tez wykorzy-

stywana w nim referencje pozwalajaca porównac dwa elementy list.

3.5 Wzory: pakiet „Patterns”


Fragment meta-modelu dotyczacy wzorów jest pokazany na rysunku 3.19. Wzory reprezento-

wane przez meta-klase „DLPattern”, dziela sie na wzory warunków („DLConditionPattern”)

i wzory przekształcen („DLTransitionPattern”). Wszystkie elementy reprezentujace wzory po-

siadaja okreslone formuły zapisane w postaci tekstu, oraz opcjonalnie moga wskazywac na

3.5. Wzory: pakiet „Patterns” 83

RYSUNEK 3.19: Reprezentacja wzorów w meta-modelu

dowolny element specjalizujacy z meta-klasy „DLNamedLink” (uczestnictwo w relacji, przypi-

sanie atrybutu lub powiazanie dereferencyjne), jako na swój podmiot („subjectLink”). Obydwa

rodzaje wzorów maja tez okreslony typ zawartej formuły. Mozliwe rodzaje typów w obu przy-

padkach obejmuja wartosci „empty” i „simple”. Dodatkowo, typ formuły we wzorze warunków

moze przyjac wartosci „universal quantification”, „existential quantification” i „membership”,

a we wzorze przekształcen, wartosci „summation”, „multiplication”, „system”, „query”, „map-

ping”, „indirect” i „invocation”.

Ostatnim elementem nalezacym do pakietu sa elementy sekwencji przekształcen algoryt-

micznych definiowane przez meta-klase „DLAlghoritmicTransitionSequenceElement”. Tego


typu elementy moga byc układane w sekwencje, z których budujemy odpowiednie algorytmy.

Dziela sie one na kroki przekształcen algorytmicznych reprezentowane przez meta-klase „DLAl-

ghoritmicTransitionStep” oraz twierdzenia sterujace przepływem reprezentowane przez meta-

klase „DLControlFlowStatement”. Twierdzenia sterujace przepływem posiadaja okreslony kon-

kretny typ oraz maja dodatkowo przypisany kolejny element sekwencji przekształcenia algo-

rytmicznego w roli „sequence”. Wskazuje on na grupe elementów, której dane twierdzenie

dotyczy. Kroki przekształcen algorytmicznych moga miec opcjonalnie przypisany wzór wa-

runków oraz okreslone alternatywne do nich inne elementy sekwencji przekształcen algoryt-

micznych. Dziela sie one dalej na kroki dopasowywane „DLCustomAlghorithicTransitionStep”

i kroki ustalone „DLPredefinedAlghoritmicTransitionStep”. Pierwsze z nich posiadaja przypi-

sany wzór przekształcen, natomiast drugie posiadaja okreslony typ i zapisana tekstowo formułe.

Zgodnie z wczesniej omówionym załozeniem, opis formuł wzorów jest oparty o składnie

stosowana przez biblioteke SymJa. Biblioteka ta odpowiada zwyczajowo stosowanemu sposo-

bowi zapisu wzorów matematycznych w programach komputerowych. Konieczne jest jednak

uwzglednienie załozen, które umozliwia własciwe wyrazanie odwołan do atrybutów, relacji i

uczestników relacji w taki sposób, aby były one przez ta biblioteke w razie potrzeby poprawnie

przekształcane. Przyjeto, ze odwołania do poszczególnych uczestników relacji beda sie odby-

wały poprzez ich lokalne nazwy. Odwołania do atrybutów beda reprezentowane poprzez lokalna

nazwe rodzica zawarta w nawiasie, poprzedzona nazwa atrybutu. Odwołania do relacji poprzez

lokalne nazwy elementów bioracych udział w relacji (badz bardziej skomplikowane wyrazenia

do nich prowadzace) sa rozdzielone przecinkami i znajduja sie w nawiasie poprzedzonym skró-

tem nazwy relacji. Spowoduje to traktowanie tych odwołan przez biblioteke odpowiednio jako

zmienne i funkcje, a w rezultacie zapewni własciwe przekształcanie wzorów w celu wyznacza-

nia z nich poszczególnych wartosci. Z analogicznego zestawu powodów przyjeto równiez, ze w

wypadku formuł uzywanych do operowania na zbiorze elementów, odwołaniem do biezacego

elementu bedzie znak „$”. Dodatkowo, załozono takze mozliwosc stosowania lokalnych nazw

zwiazanych z powiazaniami dereferencyjnymi, przypisanymi do pojec w analogiczny sposób

jak odwołania do ich atrybutów. W ten sposób mozemy uzyskac uproszczenie niektórych wzo-

rów. W sytuacji kiedy jest to konieczne, mozliwe jest równiez poprzedzenie poszczególnych


elementów w wywołaniach relacji ich lokalna nazwa w obrebie tej relacji zakonczona symbo-

lem „=”. Pozwoli to jednoznacznie okreslic ich role, gdy dana relacja zawiera wiele uczestnictw

zwiazanych z elementami tego samego typu.

3.5.2 Znaczenie

Wzór warunku: DLConditionPattern

Wzory warunków słuza odzwierciedlaniu reguł, na podstawie których da sie otrzymac wartosc

logiczna. Wzory takie moga posłuzyc zarówno sprawdzeniu prawdziwosci okreslonych wa-

runków, jak i znalezieniu elementów, które te warunki spełniaja. Formuła przypisana do tego

rodzaju wzorów moze byc interpretowana na jeden z kilku sposobów, w zaleznosci od wartosci

zmiennej okreslajacej jej typ. Wzory oznaczone jako „simple” polegaja na zwykłym sprawdze-

niu podanego warunku. Wzory typu „universal quantification” sprawdzaja, czy warunek jest

spełniony przez wszystkie elementy wskazywane przez przypisany do wzoru podmiot. Wresz-

cie, wzory typu „existential quantification” sprawdzaja, czy chociaz jeden z tak okreslonych

elementów spełnia warunek. W celu odzwierciedlenia bardziej złozonych warunków, kazdy typ

formuły moze równiez zawierac odwołania do relacji. Dotyczy to równiez odniesien opartych o

wzory, które moga posłuzyc sprawdzeniu warunków czastkowych. Jest tez mozliwosc pozosta-

wienia formuły pustej, co symbolizuje wartosc „empty”. W procesie automatycznej generacji

kodu, taka formuła jest wtedy pomijana.

Warto zwrócic uwage, ze podmiot wzoru powinien byc zwiazany ze zbiorem, po którym

mozna iterowac. Sens maja zatem jedynie przypisania atrybutów do pojec reprezentujacych

typy „set”, lub „ordered set”, lub tez uczestnictwa w relacji i powiazania dereferencyjne z licz-

noscia inna niz pojedyncza. W wypadku wzorów opisujacych warunki przypisane do pojec,

nalezy wskazac atrybut pojecia. Jesli nie jest to atrybut bezposredni dla tego pojecia, nalezy

taki atrybut wskazac wykorzystujac element „DLDereferenceLink”. Wreszcie specjalny rodzaj

warunków stanowia te o typie „membership”. Słuza one sprawdzeniu, czy dany element jest

przedstawicielem wybranego pojecia i wykorzystywane sa głównie w celu umozliwienia od-

niesienia sie do takiej informacji w innych wzorach.


Wzór przekształcen: DLTransitionPattern

Wzory przekształcen słuza odzwierciedleniu reguł pozwalajacych uzyskac konkretna wartosc

lub obiekt. Formuła przypisana do tego rodzaju wzorów, tak jak w wypadku wzorów warunków,

równiez moze byc interpretowana na jeden z kilku sposobów. Zalezy to od wartosci zmiennej

okreslajacej jej typ. Wzory oznaczone jako „simple” reprezentuja prosta zaleznosc pomiedzy

elementami, która mozna wykorzystac do przekształcania jednych z nich w drugie. Wzory ta-

kie moga posłuzyc zarówno do odzwierciedlenia zaleznosci, z których da sie wyznaczyc kazdy

z elementów na podstawie podzbioru pozostałych, jak i takich, gdzie mozliwe jest wyznacze-

nie jedynie ich czesci lub tylko jednego. Wzory o typie „system” reprezentuja układ zaleznosci.

Poza forma zapisu róznia sie tylko tym od wzorów „simple”, ze mozemy oczekiwac, ze da sie na

ich podstawie zawsze wyznaczyc wiecej niz jedna wartosc. Wzory typu „summation” definiuja

dany element jako sume z wyrazen dla zbioru wskazanego przez przypisanie podmiotu wzoru,

a typu „multiplication” – analogicznie wyznaczonego iloczynu. Wzory o typie „query” pozwa-

laja na wykonanie zapytania do wybranego podzbioru modelu, natomiast te o typie „mapping”

pozwalaja na proste mapowanie elementów według okreslonych reguł. Wzory typu „mapping”

definiowane sa przez ciag rozdzielonych srednikiem prostych wzorów okreslajacych na prze-

mian warunek i odpowiadajaca jej wartosc. Ostatni w tym ciagu, opcjonalny niesparowany wzór

okresla wartosc odpowiadajaca wszystkim sytuacjom nie objetym przez wczesniejsze warunki.

Wzory o typie „indirect” zamiast okreslac sposób bezposredniego uzyskania danego ele-

mentu, definiuja szereg wzorów pozwalajacych otrzymac konieczne do jego uzyskania warto-

sci. W zaleznosci od tego, czy taki wzór posiada podmiot, wartosci te posłuza zmodyfikowaniu

istniejacego elementu, badz utworzeniu nowego. Wzory o typie „invocation” pozwalaja na wy-

wołanie gotowego kodu, co moze byc przydatne przy wykorzystywaniu gotowych bibliotek.

Mozliwe sa równiez wzory o typie „empty”, które pozwalaja pozostawic formułe pusta i nie

generowac dla niej w przyszłosci kodu. Podobnie jak w wypadku wzorów warunków moz-

liwe jest równiez odwoływanie sie do relacji. Majace sens wartosci podmiotu wzoru w typach

wzorów wykorzystujacych go do iteracji podlegaja tym samym ograniczeniom co w wypadku

wzorów warunków. W wypadku wzorów o typie „indirect” odwołania do relacji moga wska-

zywac tylko na jedno z uczestnictw relacji o typie „source”. Warto zwrócic uwage na to, ze o


ile przekształcenia zawierajace proste wzory przekształcen moga miec uczestnictwa w relacji o

prawie dowolnej kombinacji skierowan, o tyle w wypadku pozostałych nalezy sie spodziewac

pojedynczego celu i reszty uczestnictw oznaczonych jako zródła.

Element sekwencji przekształcen algorytmicznych: DLAlghoritmicTransitionSequence-

Element

Struktury zbudowane z elementów sekwencji przekształcen algorytmicznych pozwalaja okre-

slic z góry okreslona kolejnosc wykonania dla danego zbioru przekształcen. W ten sposób

umozliwiamy wprowadzenie elementów imperatywnych do jezyka RSL-DL, który jest general-

nie deklaratywny. Interpretacja danego elementu sekwencji zalezy od jego konkretnego rodzaju.

Kazdy z takich elementów moze miec przypisany kolejny element sekwencji, co wyznacza ko-

lejnosc wykonywanych przekształcen.

Twierdzenie sterujace przepływem: DLControlFlowStatement

Twierdzenia sterujace przepływem umozliwiaja wygodne definiowanie bardziej skomplikowa-

nych sposobów wykonywania wybranych sekwencji przekształcen. Przykładem moze byc chec

wykonywania danego ciagu operacji dopóki wywołuje on jakiekolwiek zmiany. Przypisany

twierdzeniu sterujacemu element sekwencji przekształcenia algorytmicznego rozpoczyna wy-

brana sekwencje, a typ twierdzenia okresla konkretny sposób jej wykonania.

Krok przekształcen algorytmicznych: DLAlghoritmicTransitionStep

Kroki przekształcen algorytmicznych zwiazane sa z wykonywaniem konkretnych przekształ-

cen. Jesli dany krok nie posiada wzoru warunków lub warunek wynikajacy z takiego wzoru

jest spełniony, podejmowana jest próba wykonania przekształcenia. Po jej zakonczeniu naste-

puje przejscie do kolejnego kroku, chyba, ze jest to juz ostatni krok w sekwencji. Jesli waru-

nek przekształcenia nie jest spełniony, nastepuje przejscie do elementu sekwencji przypisanego

jako alternatywny. W zaleznosci od rodzaju danego kroku, przekształcenie jest definiowane za

pomoca odpowiedniego wzoru przekształcenia algorytmicznego lub stanowi jedna ze z góry

wybranych operacji (np. zamiana dwóch wartosci).


RYSUNEK 3.20: Przykład wzoru warunków

RYSUNEK 3.21: Przykład wzoru przekształcen


Wzór warunków: DLConditionPattern

Rysunek 3.20 przedstawia przykład składni konkretnej dla wzoru warunków, zwiazany z wcze-

sniej zaprezentowanym przykładem dla odniesienia opartego o wzory (patrz rys. 3.15). Zawiera

on warunek okreslajacy, ze dwie osoby okreslane w nim jako „thisPerson” i „thatPerson” maja

oboje tych samych rodziców. Odniesienie do rodziców uzyskiwane jest za pomoca relacji „pa-

renthood”. Odwołanie sie do tej relacji dla wybranej osoby jak i wyprowadzenie z niej konkret-

nego rodzica przedstawione jest w składni za pomoca nawiasów. Wykorzystywane sa równiez

standardowe operatory logiczne, a porównaniu wartosci słuzy operator „==”. Z kolei operator

„=” jest wykorzystany do okreslenia roli, jaka pełni konkretny obiekt (tutaj: osoba) w zadanej

wzorem relacji. Jest to konieczne ze wzgledu na fakt, ze wszystkie biorace udział w przykłado-

wej relacji osoby beda przedstawicielami tego samego pojecia.

Wzory przekształcen: DLTransitionPattern

Rysunek 3.21 przedstawia przykład składni konkretnej dla wzoru przekształcen zwiazanego

z wczesniej zaprezentowanym przykładem dla przekształcenia opartego o wzory (patrz rys.

3.17). Jest to prosty wzór łaczacy wartosci odpowiadajace predkosci, zmianie połozenia i zmia-

nie czasu za pomoca operatora arytmetycznego dzielenia i operatora „==” oznaczajacego po-

równanie wartosci. W naszym przykładzie wzór ten odnosi sie do elementu „average speed

computation” oraz nazw odpowiednich uczestnictw relacji, odpowiadajacych trzem składnikom

wzoru.

3.6. Zapytania do modelu 89

RYSUNEK 3.22: Składnia zapytan do modelu

3.6 Zapytania do modelu


Jako ze składnia zapytan ma charakter tekstowy, zobrazowano ja za pomoca prostej gramatyki

w notacji BNF, przedstawionej na rysunku 3.22. Kazde zapytanie („query”) reprezentowane

jest w postaci uporzadkowanej dwójki lub trójki. Pierwszym elementem jest słowo kluczowe

okreslajace rodzaj wykonywanej operacji („action”). Dopuszczalnych jest siedem takich słów –

„Get”, „Transform to”, „Create”, „Read”, „Update”, „Delete” i „Validate”. Jako drugi element

wystepuje podmiot zapytania w postaci nazwy wskazujacej na pojecie dziedzinowe („subject”).

Trzeci, opcjonalny element stanowi nazwa dziedziny („domain”), poprzedzona sformułowa-

niem „based on”.

3.6.2 Znaczenie

Podstawowa rola zapytan jest powiazanie standardowej specyfikacji wymagan w jezyku RSL ze

specyfikacja wiedzy dziedzinowej zapisana w jezyku RSL-DL. Poprzez przypisanie zapytan do

twierdzen dziedzinowych, mozliwe jest definiowanie operacji zwiazanych z odpowiadajacymi

tym twierdzeniom zdaniom w scenariuszach przypadków uzycia. Zapytania zaczynajace sie

od sformułowania „Get” dotycza wyników automatycznego wnioskowania w oparciu o model

dziedziny. Zapytania zaczynajace sie od słów „Transform to” dotycza przypisywania nowych

przedstawicieli do pojec o typie „assigned_role”. Zapytania „Create”, „Read”, „Update” i „De-

lete” odpowiadaja kolejno tworzeniu, pobieraniu, zmianie i usuwaniu danych na temat pojec

(schemat CRUD). Zapytania rozpoczynajace sie od „Validate” odnosza sie do sprawdzenia wa-

runków poprawnosci przypisanych do danego pojecia.


RYSUNEK 3.23: Przykład zapytania do modelu

Samo pojecie, dla którego wykonywane jest zapytanie wskazywane jest przez drugi frag-

ment zapytania. W wypadku zapytan przypisanych do twierdzen dziedzinowych, takie pojecie

musi odpowiadac jednemu z dopełnien przypisanych do twierdzenia. Ostatnia czesc zapytania

okresla jego dziedzine, czyli podzbiór modelu, w oparciu o który zapytanie ma byc rozpatry-

wane. Odbywa sie to poprzez wskazanie nazwy odpowiedniej instancji meta-klasy „DLDo-

main”. W wypadku nie wybrania dziedziny, zapytanie zostanie rozpatrzone na podstawie ca-

łego modelu. Wskazanie dziedziny ma z reguły znaczenie tylko dla zapytan rozpoczynajacych

sie od słowa kluczowego „Get”. Wtedy taki wybór wpływa na zbiór reguł, który zostanie wy-

korzystany do automatycznego szukania rozwiazania. Z oczywistych powodów, aby zapytanie

zostało uznane za prawidłowe, musi byc mozliwe podjecie próby jego rozwiazania dla wskaza-

nego pojecia w oparciu o wskazana dziedzine.

Drugim mozliwym miejscem wykorzystania zapytan sa przekształcenia oparte o wzory o

typie „query”. W tym wypadku stosuje sie zapytania „Get” do odnoszenia sie do podzbiorów

modelu, innych niz ten, w którym odniesienie jest zawarte.


Reprezentacja przykładowego zapytania przedstawiona jest na rysunku 3.23. Okresla ono ko-

niecznosc automatycznego wygenerowania rozwiazania wyznaczajacego pojecie „predkosc” na

podstawie dziedziny „kinematyka”.

91

Rozdział 4

Semantyka translacyjna dla jezyka

RSL-DL

4.1 Reguły transformacji

W niniejszym rozdziale przedstawiono 16 reguł translacyjnych definiujacych semantyke jezyka

RSL-DL. Kazda reguła przedstawiona jest najpierw w postaci tekstu opisujacego w mniej for-

malny sposób zasady mapowania konkretnych konstrukcji jezyka RSL-DL w konkretne kon-

strukcje wyrazone w jezyku Java. Nastepnie, dla kazdej reguły podany jest jej formalny zapis w

postaci diagramu wyrazonego w jezyku MOLA (patrz sekcja 1.5). Zapis ten przedstawia pro-

cedure (lub procedury) translacji modelu zgodnego z meta-modelem jezyka RSL-DL w model

zgodny z meta-modelem jezyka UML, oraz powiazane z nim fragmenty kodu zapisanego zgod-

nie ze składnia jezyka Java. Warto podkreslic, ze przedstawione reguły, w zakresie struktury

klas i relacji miedzy nimi, zamiast składni jezyka Java wykorzystuja meta-model jezyka UML

[106]. Przekształcenie modelu w jezyku UML w kod w jezyku Java jest powszechnie stosowane

w wielu narzedziach i nie bedzie tutaj omawiane.

W sekcji 4.2 przedstawiono sposób implementacji przestawionych tutaj reguł translacyj-

nych. Z kolei, w rozdziale 5 zawarto przykłady ich realizacji. Pokazano tam przykładowy mo-

del zródłowy zapisany w jezyku RSL-DL oraz wygenerowany na jego podstawie kod zapisany

w jezyku Java. W ramach opisu wygenerowanego kodu podano tez reguły, które zostały zasto-

sowane podczas jego generacji.

92 Rozdział 4. Semantyka translacyjna dla jezyka RSL-DL

4.1.1 Docelowa architektura

W celu zdefiniowania semantyki translacyjnej nalezy zdefiniowac zasady tłumaczenia nowo

powstałego jezyka na struktury jezyka o dobrze okreslonej semantyce. Z uwagi na zastoso-

wanie projektowanego jezyka do generacji kodu, naturalnym jest wykorzystanie do tego celu

powszechnie stosowanego jezyka programowania trzeciej generacji. W niniejszej pracy posłu-

zono sie zatem jezykiem Java, którego semantyka jest dobrze okreslona i zaimplementowana w

wielu kompilatorach. Zgodnie z zasadami podejscia translacyjnego i wyjasnieniem podanym na

wstepie niniejszego rozdziału, biezacy rozdział zawiera zestaw reguł tłumaczacych konstrukcje

jezyka RSL-DL na konstrukcje jezyków UML i Java.

Kod wynikowy dla reguł translacyjnych spełnia zasady architektury Model-View-Presenter

(MVP) [84], co czyni go zgodnym z regułami translacyjnymi dla jezyka RSL [98]. Poniewaz

jezyk RSL-DL odzwierciedla jedynie logike dziedzinowa, opisane reguły dotycza generacji

kodu w warstwie modelu („Model”). Pozostałe warstwy – warstwa widoku („View”) i warstwa

prezentera („Presenter”) moga byc utworzone poprzez generacje modeli w jezyku RSL.

Podstawowa struktura kodu docelowego dla reguł translacyjnych składa sie z dwóch rodza-

jów klas w jezyku Java. Pierwszy z nich odzwierciedla struktury danych, na których operuje

program. Nazwy takich klas zaczynaja sie od przedrostka „M”. Kazda z nich posiada odpo-

wiadajacy sobie interfejs, który implementuje. Nazwa tego interfejsu odpowiada nazwie klasy,

dodatkowo poprzedzonej litera „I”. Atrybuty klas „M” sa prywatne i posiadaja zdefiniowane

metody dostepowe, które sa zadeklarowane równiez w odpowiadajacych im interfejsach. Hie-

rarchia dziedziczenia danych wyrazonych atrybutami jest odzwierciedlana na poziomie interfej-

sów. W połaczeniu z poprzednim załozeniem dotyczacym klas „M”, pozwala to na odzwiercie-

dlanie dziedziczenia wielokrotnego, które nie jest dostepne w jezyku Java na poziomie klas. W

zaleznosci od przypadku, klasy te moga posiadac takze kilka metod. Metoda „validate()” spraw-

dza poprawnosc danych, a metody „update()” i „delete()” odpowiednio aktualizuja lub usuwaja

dane zwiazane z obiektami klasy (np. w bazie danych). Dodatkowo, dostepny jest zbiór metod

o nazwach zaczynajacych sie od „get” pozwalajacych otrzymywac rózne wartosci pochodne

wyznaczone na podstawie wartosci atrybutów obiektów.

Drugi rodzaj klas słuzy do wykonywania operacji na danych reprezentowanych przez pierw-

4.1. Reguły transformacji 93

szy rodzaj. Nazwy tych klas zaczynaja sie od przedrostka „MS” i zawieraja jedynie metody

statyczne. Wsród tych klas wystepuja zarówno klasy powiazane z klasami pierwszego typu,

grupujace zwiazane z nimi operacje, jak i niezwiazane bezposrednio z zadna z takich klas i za-

wierajace operacje dotyczace wielu z nich. Klasy „MS” zwiazane z klasami „M” moga zawie-

rac równiez wszelkiego rodzaju metody pomocnicze, w tym np. metode pobierajaca wszystkich

przedstawicieli klasy „M” z bazy danych.

Przedstawiona struktura kodu została dodatkowo zmodyfikowana w celu zweryfikowania

bardziej dynamicznego podejscia do ról pełnionych przez poszczególne klasy. Klasy „M” roz-

szerzaja gotowa abstrakcyjna klase „DLClass”, a ich interfejsy rozszerzaja gotowy interfejs

„IDLClass”. Interfejs ten jest równiez implementowany przez wspomniana klase abstrakcyjna.

Dodatkowo, te sposród klas „MS”, które odpowiadaja konkretnym klasom „M”, rozszerzaja

abstrakcyjna klase „DLHelper”. Za pomoca tych klas zapewniony został mechanizm umozli-

wiajacy odzwierciedlenie dynamicznych zmian ról pełnionych przez klasy.

Struktura kodu docelowego dla reguł translacyjnych została zilustrowana na rysunku 4.1,

w postaci diagramu klas zapisanego w jezyku UML. Warto tutaj zwrócic uwage na zasy-

gnalizowany powyzej mechanizm dynamicznego przypisywania ról. W paradygmacie obiek-

towym, obiekty zasadniczo nie moga dynamicznie zmieniac swojego typu w czasie swojego

zycia. Przedstawiona struktura kodu pozwala jednak w pewnym stopniu obejsc to ograniczenie.

Kluczowa jest tutaj metoda operacji „treatAs()” zawartych w klasach specjalizujacych klase

„DLHelper”. Metoda ta przyjmuje parametr, jakim jest obiekt realizujacy interfejs pochodny

od interfejsu „IDLClass”. Ponadto, przyjmuje ona referencje do definicji okreslonej klasy. Re-

zultatem wykonania takiej metody jest obiekt klasy, podanej jako drugi parametr wywołania.

Przy tym, jest to de-facto ten sam obiekt, który został podany jako pierwszy parametr. W ten

sposób zmienilismy typ obiektu i mozemy odwoływac sie do metod zgodnych z jego nowym

typem.

W przykładzie na rysunku 4.1 mozemy załozyc chec zmiany typu obiektu „Obiekt1” na typ

„MPojecie2”. Dzieki temu, bedziemy mogli odwołac sie do metod dostepnych dla tego typu.

Kod pozwalajacy na taka zamiane typu mógłby wtedy wygladac nastepujaco:

MSPojecie1.treatAs(Obiekt1,MPojecie2).operation1();


RYSUNEK 4.1: Ilustracja struktury kodu docelowego dla reguł translacyjnych

Warto tutaj zauwazyc, ze zaproponowane rozwiazanie pozwala w stosunkowo łatwy sposób

wygenerowac kod dla modeli w jezyku RSL-DL, które uwzgledniaja dynamiczna zamiane i

łaczenie ról (np. konkretna osoba, która najpierw jest instancja pojecia „Student”, potem jed-

noczesnie – pojec „Student” i „Lekarz”, a na koniec tylko pojecia „Lekarz”). Wygenerowany

kod na pewno nie jest zbyt elegancki i czytelny dla ludzi, lecz nie to jest tutaj celem. Celem jest

mozliwosc odzwierciedlenie sposobu reprezentacji wiedzy dziedzinowej, zgodnej z typowym

sposobem myslenia ludzi, w kodzie zgodnym z paradygmatem obiektowym. Nalezy równiez


podkreslic, ze zaproponowane powyzej rozwiazanie dla dynamicznej zmiany ról nie jest przed-

miotem niniejszej pracy i zostało tutaj podane jedynie w zarysach. Wymaga ona dalszego dopra-

cowania i uszczegółowienia, co stanowi niewatpliwie ciekawa agende badawcza na przyszłosc.

W podanych dalej regułach jest ono wykorzystywane tylko poprzez odpowiednie powiazania

generowanych klas z klasami ogólnymi „DLHelper”, „DLClass” i interfejsem „IDLClass”.

4.1.2 Struktura klas

Podstawowym celem generowanego na podstawie wiedzy dziedzinowej kodu bedzie realizacja

operacji przetwarzania danych. Jest to reprezentowane poprzez przypisane zapytan w jezyku

RSL-DL do fraz w scenariuszach przypadków uzycia zapisanych w jezyku RSL. Docelowy kod

zapisany w jezyku Java, zachowuje oczywiscie paradygmat programowania obiektowego, co

powoduje koniecznosc utworzenia w pierwszej kolejnosci własciwej struktury klas. Struktura ta

odzwierciedla forme przetwarzanych danych, która bedzie uzupełniana o odpowiednie metody

w oparciu o kolejne reguły przetwarzania. Na poczatku przedstawione zostana zatem reguły

generujace taka strukture i deklarujace w niej odpowiednie metody, które w dalszych etapach

beda wypełnione trescia.

Pierwsza, podstawowa reguła ustala jednolita strukture kodu, poprzez utworzenie odpo-

wiednich klas.

Reguła 1. a) Dla kazdego pojecia, które bedzie brało udział w realizacji logiki dziedzinowej

i nie odpowiada tylko prostej wartosci, tworzony jest interfejs „IMPojecie”. Jesli poje-

cie nie jest typu „template”, to dodatkowo tworzona jest implementujaca ten interfejs

klasa „MPojecie”. Interfejs „IMPojecie” rozszerza interfejs IDLClass, a klasa „MPoje-

cie” rozszerza abstrakcyjna klase „DLClass”. b) Dla pojec o typie „identity” lub „assi-

gned_role”, pojec o typie „inferred_role” posiadajacych przypisane warunki tozsamosci,

a takze pojec o typie „template”, z których bezposrednio lub posrednio dziedzicza pojecia

o typie „identity” lub „assigned_role”, tworzona jest klasa „MSPojecie” rozszerzajaca

abstrakcyjna klase DLHelper. c) Dodatkowo, dla pojec typu „DLProperty” o przypisa-

nym typie danych „enumeration” tworzony jest typ wyliczeniowy „MPojecieValueEnum”


RYSUNEK 4.2: Formalny zapis reguły 1

reprezentujacy ich mozliwe wartosci.

Formalny zapis reguły przedstawiony jest na rysunku 4.2 w postaci procedury w jezyku

MOLA, która przetwarza zadane pojecie („pojecie: DLNotion”), podane jako jej parametr.

Warto zaznaczyc, ze niniejsza reguła powinna byc stosowana tylko do pojec bioracych udział

w wykonywaniu logiki dziedzinowej. Oznacza to pojecia, które albo wystepuja w zapytaniach,

albo powiazane z nimi klasy wystepuja w kodzie realizujacym zapytania dla innych pojec. Pro-

cedura rozpoczyna sie od wywołania gotowej procedury („isSimpleType”), która sprawdza, czy

dane pojecie nie odpowiada jedynie prostej wartosci. Przez pojecia podpadajace pod te katego-

rie, rozumiemy pojecia o typie „DLProperty” nie powiazane z zadnymi atrybutami, nie dziedzi-

czace z zadnych pojec, lub tez dziedziczace pojecia, które równiez nie posiadaja atrybutów i nie

dziedzicza z zadnych innych pojec. Pojecia takie moga byc reprezentowane przez wbudowane

typy jezyka Java i nie potrzebuja tworzenia osobnych klas. Dalszy ciag procedury jest zatem


wykonywany jedynie, jesli pojecie nie jest prosta wartoscia (przejscie oznaczone {ELSE}).

Nastepnie uzyskiwana jest odpowiednio sformatowana nazwa pojecia („toCamelCase”) i

na jej podstawie tworzony jest interfejs, który zgodnie z przedstawiona wczesniej architek-

tura rozszerza interfejs „IDLClass”. Jesli rozpatrywane pojecie jest innego typu niz „template”,

tworzona jest odpowiednia, implementujaca interfejs klasa, która rozszerza abstrakcyjna klase

„DLClass”. Ostatni etap procedury dotyczy tworzenia pomocniczych klas o nazwie poprzedzo-

nej przedrostkiem „MS” i dziedziczacych z klasy „DLHelper”, dla pojec które beda takich klas

potrzebowały. Przed ich utworzeniem sprawdzany jest zatem fakt zaistnienia któregokolwiek z

wymienionych w regule warunków wskazujacych na potrzebe wykonania tej czynnosci. Two-

rzenie typów wyliczeniowych zostało natomiast na powyzszym przedstawieniu pominiete, jako

mało skomplikowane w realizacji.

Po utworzeniu klas, kolejna reguła dotyczy stworzenia odpowiedniej struktury generaliza-

cji pomiedzy nimi, odzwierciedlajacej zaleznosci dziedziczenia pomiedzy pojeciami. Zgodnie

z załozeniami przedstawionymi przy prezentacji docelowej architektury, zostało to wykonane

na poziomie dziedziczenia pomiedzy interfejsami, które te klasy implementuja. Sytuacje, w

których dane pojecie moze byc szczególnym przypadkiem jednego z wielu innych pojec (nie

dotyczaca pojec o typie „identity”), wymagaja bardziej skomplikowanego obsłuzenia w postaci

kolejnych reguł. Reguła 2 obsługuje natomiast najprostsze sytuacje dziedziczenia.

Reguła 2. Jesli w dane pojecie posiada odwołanie w postaci „DLInheritanceCondition” do

pojedynczego innego pojecia, interfejs odpowiadajacy pierwszemu z tych pojec rozszerza

interfejs odpowiadajacy temu drugiemu.

Formalizacja tej reguły dla pojedynczego pojecia jest zobrazowana na rysunku 4.3. Proce-

dura ta opiera sie na pojedynczej, stosunkowo prostej petli. W petli tej znajdowane sa odpowied-

nie warunki dziedziczenia łaczace pojecie z jego „rodzicami”. Utworzenie relacji generalizacji

miedzy odpowiednimi interfejsami nastepuje jedynie, jesli nie istnieja (przejscie {ELSE}) inni

„rodzice” powiazani z danym warunkiem dziedziczenia.

Gdy mamy juz utworzona podstawe struktury klas, nalezy nastepnie uzupełnic ja o odpo-

wiednie atrybuty, wraz z metodami dostepowymi. W pierwszej kolejnosci nalezy uwzglednic

fakt, ze pojecia o typie „DLProperty” reprezentuja konkretne rodzaje wartosci.



Reguła 3. W kazdej klasie odpowiadajace pojeciom typu „DLProperty” tworzony jest dodat-

kowy atrybut „value” o typie zaleznym od wartosci parametru „dataType”. Dodatkowo,

w odpowiadajacym danemu pojeciu interfejsie deklarowane sa operacje „get” i „set”,

umozliwiajace zmiane wartosci temu atrybutowi. Tresc metod dla tych operacji umiesz-

czana jest we wspomnianej wyzej klasie. W wypadku pojec o typie „template”, które nie

maja odpowiadajacych im bezposrednio klas, tworzone sa tylko operacje w interfejsie.

Najistotniejsza czesc formalizacji tej reguły zobrazowana została na rysunku 4.4. Przedsta-

wia on procedure dodawania odpowiednich atrybutów i operacji dostepowych, do klas i inter-

fejsów odpowiadajacym pojeciom „DLProperty”. Do pełnej realizacji reguły wymagane jest

równiez, nie przedstawione na rysunku kopiowanie operacji z interfejsu do implementujacej go

klasy i wypełnienie ich odpowiednimi odwołaniami do atrybutów. Przedstawiony fragment for-

malizacji reguły pomija takze fakt, ze zwyczajowo dla operacji pobierajacych wartosci logiczne



stosuje sie nieco inna konwencje nazewnicza. Do osobnej, nie przedstawionej szczegółowo pro-

cedury, wyodrebniono mapowanie wartosci parametru „dataType”’ na typy jezyka Java. Nalezy

takze zwrócic uwage, ze opisana reguła ze wzgledu na swoja konstrukcje, stosuje sie tylko

do instancji meta-klasy „DLProperty”, dla których wygenerowano odpowiadajace im w kodzie

klasy.

Nastepnym elementem translacji jest uzupełnienie pozostałych atrybutów charakteryzuja-

cych kazda z klas. Czynimy to w oparciu o wystepujace w modelu dziedzinowym przypisania

odzwierciedlone za pomoca meta-klasy „DLAttributeLink”, a takze odniesienia oparte o dane

„DLDataBasedReference”.

Reguła 4. a) Dla kazdego pojecia o typie innym niz „template”, do którego istnieje odwołanie

w postaci „DLAttributeLink” o typie „provided” i umieszczone w innym pojeciu, two-

rzony jest odpowiadajacy pierwszemu pojeciu atrybut w klasie odpowiadajacej drugiemu

z nich. Odpowiednie operacje dostepowe sa deklarowane w powiazanym interfejsie i ich

metody tworzone w klasie. b) W wypadku kiedy pierwsze pojecie jest typu „template”,

metody sa jedynie deklarowane, a w wypadku kiedy jest oznaczone jako „derived”, me-

tody pobierajace wartosc tworzone sa bez zawartosci. c) W wypadku pojec o typie „iden-


tity” dodatkowo tworzone sa atrybuty bazujace na pojeciach przypisanych do pojec, z

których te klasy posrednio lub bezposrednio dziedzicza, a które to atrybuty nie maja od-

powiednika w biezacej klasie. Do klas odpowiadajacym pozostałym pojeciom, takie atry-

buty dodawane sa tylko, jesli ogólniejsza klasa odpowiada pojeciu o typie „template”.

d) Typ przypisany do kazdego atrybutu oraz zwracany lub podawany do powiazanych

z nim metod zalezy od pojecia, któremu ten atrybut odpowiada. W wypadku pojec po-

wiazanych jedynie z prosta wartoscia, odpowiada on rodzajowi danych, które to pojecie

reprezentuje. W pozostałych przypadkach wykorzystywany jest interfejs, który realizuje

klasa powiazana z pojeciem. e) Dla kazdego odniesienia opartego o dane, powiazanego

z rozwazanym pojeciem, tworzone sa w odpowiadajacej pojeciu klasie, zwiazane z tym

odniesieniem atrybuty i metody dostepowe. Jesli dane odniesienie łaczy rozwazane po-

jecie tylko z jednym innym pojeciem, typ atrybutu opiera sie na tym drugim pojeciu. W

przeciwnym wypadku odpowiada on klasie reprezentujacej całe odniesienie (patrz reguła

9). f) Podobnie jak w poprzednim przypadku, dla pojec o typie „template” tworzymy tylko

deklaracje operacji w interfejsie. g) W wypadku atrybutów reprezentujacych odniesienia

oparte o dane, konieczne jest równiez stworzenie atrybutów odzwierciedlajacych zbiory

danych i ich listy, w przypadku kiedy odpowiednie uczestnictwa tych relacji maja przypi-

sane licznosci „multiple” lub „ordered_multiple”.

Najwazniejsze elementy formalizacji tej reguły, dotyczace przypisan atrybutów, sa zobra-

zowane na rysunku 4.5. Przedstawiona tam procedura obejmuje prosta iteracje dla elementów

typu „DLProperty”, wykorzystanych jako atrybuty w pojeciu zadanym jako parametr. Głów-

nym zadaniem petli jest tworzenie odpowiednich deklaracji atrybutów w klasach i operacji w

interfejsach. Analogicznie jak w wypadku poprzedniej reguły, na rysunku pominieto kopio-

wanie operacji z interfejsów do klas i generowanie tresci metod, a uzyskiwanie typu dla two-

rzonych atrybutów wyciagnieto do osobnej procedury. Zawartosc metod wygenerowanych na

podstawie pojec oznaczonych jako „derived” na tym etapie pozostaje pusta. Zawartosc pozo-

stałych metod dostepowych odziedziczonych z implementowanych interfejsów, dla których nie

ma atrybutów w biezacej klasie, powinna zawierac odwołania do odpowiednich metod z inter-

fejsu „IDLClass”. Warto równiez zwrócic uwage na wywołanie procedury „AddAtributeFrom-


RYSUNEK 4.5: Pierwsza czesc formalnego zapisu reguły 4

ParentRec”, która nie została szczegółowo zaprezentowana. Procedura ta przetwarza w sposób

rekursywny atrybuty pojec, z których dane pojecie dziedziczy. Atrybuty te sa przekształcane

w atrybuty klasy zadanej jako parametr. Uwzglednia ona takze koniecznosc odzwierciedlenia

wartosci reprezentowanych przez dziedziczone pojecia, jesli któres z nich jest przedstawicielem

meta-klasy „DLProperty”.

Fragment formalizacji reguły 4, dotyczacy atrybutów powstałych na podstawie odniesien

opartych o dane, został zobrazowany na rysunku 4.6. Równiez jego realizacja oparta jest o

jedna rozbudowana iteracje, która przebiega po przedstawicielach meta-klasy „DLDataBase-

dReference”. W trakcie iteracji, zgodnie z warunkiem zawartym w regule, dodawane sa odpo-

wiednie atrybuty, bazujace badz na klasach reprezentujacych relacje wspomnianego typu, badz


RYSUNEK 4.6: Druga czesc formalnego zapisu reguły 4


na pojeciach przez nie wskazywanych. Ze wzgledu na czytelnosc, w omawianym przedstawie-

niu zostało zastosowane jednak pewne uproszczenie. Zwiazane jest ono z warunkiem rozdzie-

lajacym opisane dwa przypadki w oparciu o licznosc uczestników relacji. Nie pokazano tutaj

fragmentów sprawdzajacych wystepowanie par powiazanych ze soba zwykłych i pomocniczych

relacji, których nie nalezy traktowac oddzielnie.

Gdy mamy juz stworzone interfejsy z okreslonymi operacjami dostepowymi i implementu-

jace je klasy wraz z atrybutami, w nastepnej kolejnosci nalezy stworzyc odpowiednie konstruk-

tory dla wspomnianych klas.

Reguła 5. a) W klasach odpowiadajacych pojeciom o typie „identity” tworzone sa konstruk-

tory posiadajace parametry bazujace na atrybutach przypisanych do tych pojec oraz

do pojec, z których posrednio lub bezposrednio dziedzicza. W wypadku pojec o typie

„DLProperty”, dotyczy to równiez parametrów bazujacych na rodzaju wartosci, który te

pojecia reprezentuja. b) W klasach odpowiadajacych pojeciom o typie „assigned_role” i

„inferred_role, tworzone sa co najmniej po dwa konstruktory. Pierwszy konstruktor przyj-

muje interfejs odpowiadajacy pojeciu, do którego mozna je przypisac, a drugi konstruktor

– równiez parametry bazujace na atrybutach przypisanych do odpowiadajacego im poje-

cia (oraz odziedziczonych z pojec o typie „template”). W wypadku pojec o typie „DLPro-

perty” powstaja równiez parametry bazujace na rodzaju wartosci, który reprezentuja. W

przypadku, kiedy dane pojecie mozna przypisac do przedstawicieli wiecej niz jednego po-

jecia, tworzone jest odpowiednio wiecej wariantów konstruktorów odpowiadajacej mu

klasy.

Najwazniejsze fragmenty formalizacji reguły 5 zobrazowano na rysunku 4.7. Wykorzystano

tutaj fakt, ze klasy maja juz przypisane odpowiednie atrybuty, wiec mozna odwoływac sie do

nich bezposrednio. Niepotrzebny jest proces ich ustalania, widoczny w formalizacji poprzed-

nich dwóch reguł. Realizacja procedury moze przebiegac na dwa sposoby. Dla pojec o typie

„identity” wystarczy stworzyc konstruktor zawierajacy parametry odpowiadajace wszystkim

przypisanym do klasy atrybutom. Parametry te tworzone sa w prostej petli. Na rysunku pomi-

nieto samo generowanie kodu we wnetrzu konstruktora. Nie jest ono szczególnie skompliko-

wane, jako ze atrybuty i odpowiadajace im parametry wykorzystuja te same nazwy.


W wypadku pojec o typach „assigned_role” i „inferred_role” przebieg procesu jest troche

bardziej skomplikowany. Rozpoczyna sie on od sprawdzenia, czy dane pojecie posiada przy-

pisane jakies atrybuty, badz jest typu „DLProperty”. Dla tego typu pojec nalezy wygenerowac

dwukrotnie wiecej konstruktorów. Nastepnie przeprowadzana jest iteracja po wszystkich ele-

mentach, z których dane pojecie moze bezposrednio dziedziczyc. Dla kazdego z nich, według

wczesniejszego sprawdzenia tworzony jest jeden lub dwa konstruktory przyjmujace owe pojecie

z iteracji jako parametr. W wypadku, kiedy tworzony jest równiez drugi konstruktor, wykony-

wana jest jeszcze iteracja po atrybutach pojecia. Petla dodaje je jako parametry konstruktora

oraz w razie potrzeby dodawany jest równiez parametr odpowiadajacy reprezentowanej warto-

sci. Generowanie zawartosci kodu dla konstruktorów w tej sciezce zostało równiez pominiete

na rysunku. Tresc tych konstruktorów, oprócz ewentualnego przypisywania wartosci, wykorzy-

stuje mechanizmy z klasy „DLClass”, odzwierciedlajace przypisywanie nowych przedstawicieli

do pojec.

Posiadajac gotowa strukture klas, mozna przejsc do uzupełniania jej o metody nie zwiazane

z dostepem do atrybutów, poczynajac od tych, które da sie wygenerowac w oparciu o definicje

pojec. W pierwszej kolejnosci przedstawiona jest prosta reguła dotyczaca zawartych w poje-

ciach warunków „DLValidityCondition”:

Reguła 6. Jesli w danym pojeciu o typie innym niz „template” lub w dowolnym z pojec, z któ-

rych bezposrednio lub posrednio to pojecie dziedziczy, zdefiniowane sa warunki „DLVa-

lidityCondition”, deklarowana jest operacja „validate()” w odpowiadajacym mu inter-

fejsie i tworzona metoda w klasie. Kod metody zwraca koniunkcje wartosci sprawdzenia

prawdziwosci wszystkich reguł walidacji zawartych w „DLValidityCondition”, przypisa-

nych do danego pojecia, a takze reguł powiazanych z klasami, z których ono posrednio

lub bezposrednio dziedziczy, oraz reguł zwiazanych z jego atrybutami.

Formalizacja tej reguły została zobrazowana na rysunku 4.8. Na poczatek sprawdzany jest

typ pojecia i to, czy jest ono lub jego rodzic powiazane z co najmniej jednym warunkiem

dziedziczenia. Potem, w odpowiadajacych pojeciu interfejsie i klasie tworzona jest operacja

„validate()” sprawdzajaca jego poprawnosc. Nastepnie wykonywana jest iteracja po warun-

kach pojecia i generowany jest dla kazdego z nich odpowiedni kod. Kod ten jest uzywany do


okreslenia pojedynczej wartosci logicznej okreslajacej spełnienie wszystkich warunków. Kod

z warunków walidacji rodziców uzyskiwany jest przy pomocy osobnej rekurencyjnej proce-

dury („getValidateCodeFromParentsRec”). On równiez jest wykorzystywany do wyznaczania

koncowej wartosci walidacji. Nieco inaczej traktowane sa warunki atrybutów, które nie repre-

zentuja prostych wartosci. W tym wypadku, zamiast wykorzystywac pełen kod sprawdzajacy

dany warunek, mozna odwołac sie do odpowiedniej metody go zawierajacej. Metoda ta jest

uprzednio wygenerowana w klasie odpowiadajacej własciwosci uzytej jako atrybut. Generacja

kodu dla poszczególnych warunków została przedstawiona w postaci wywołan odpowiednich

procedur, jako ze zasady nia rzadzace sa stałe dla poszczególnych typów wzorów, które sa za-

warte w warunkach. Zostana one przedstawione przy okazji przedstawiania odpowiednich reguł

szczegółowych.

Kolejnym krokiem po wygenerowaniu metod sprawdzajacych poprawnosc pojec, jest od-

zwierciedlenie warunków okreslajacych dopuszczalnosc istnienia danych klas. Jako ze te wa-

runki czesto beda wymagały sprawdzenia przed utworzeniem instancji danej klasy, metody je

sprawdzajace zostana utworzone jako statyczne we wczesniej stworzonej pomocniczej klasie

typu „MS”.

Reguła 7. Jesli w danym pojeciu o typie innym niz „template” lub w dowolnym z pojec, z

których bezposrednio lub posrednio ono dziedziczy, zdefiniowane sa warunki „DLIden-

tityCondition”, w odpowiadajacej mu klasie typu „MS” tworzona jest dla kazdego kon-

struktora odpowiednia pod wzgledem parametrów statyczna metoda „checkPojecie()”

(gdzie „Pojecie” odpowiada nazwie klasy). Metoda ta pozwala sprawdzic, czy utworzenie

obiektu danej klasy jest zgodne z zadanymi warunkami. Kod metody zwraca koniunkcje

wartosci sprawdzenia prawdziwosci wszystkich reguł zawartych w warunku ,DLIdenti-

tyCondition”, przypisanych do danego pojecia, a takze reguł powiazanych z klasami, z

których ono posrednio lub bezposrednio dziedziczy.

Formalizacja tej reguły została zobrazowana na rysunku 4.9. Proces ten przebiega w spo-

sób zblizony do tego dla poprzedniej reguły. Na poczatku równiez sprawdzany jest typ pojecia,

a takze powiazanie jego lub jego rodziców z warunkami tozsamosci. Nastepnie, w klasie typu



„MS” tworzona jest osobna operacja dla kazdego konstruktora przypisanego do odpowiadajacej

pojeciu klasy. Operacja ta za pomoca odpowiedniej iteracji ma przypisywane takie same para-

metry. Zawartosc metod tych operacji opiera sie wyznaczeniu wartosci logicznej z wykorzysta-

niem kodu wygenerowanego dla warunków tozsamosci. W odróznieniu od poprzedniej reguły,

uwzglednione sa tylko warunki przypisane do danego pojecia i jego rodziców. W wypadku klas

o typie „assigned_role” lub „inferred_role” dodawany jest tez specjalny kod do sprawdzenia

wymaganych zaleznosci zwiazanych z przypisywaniem ról. Wykorzystuje on mechanizmy z

abstrakcyjnej klasy „DLHelper”. Analogicznie jak poprzednio, miejsca generacji kodu zostały

w wiekszosci tylko zaznaczone w formie procedur, gdyz szczegółowe zasady zostana przedsta-


wione w dalszej czesci.

Kolejnym elementem składowym klas powstałych z pojec sa metody pozwalajace na pod-

stawowe operacje zwiazane z przechowywaniem danych.

Reguła 8. Dla wszystkich pojec, w odpowiadajacym im interfejsach deklarowane sa operacje

„update()” i „delete()”. Dla pojec o typie innym niz „template” tworzone sa one rów-

niez w odpowiadajacych im klasach. Dodatkowo, w klasie typu „MS” odpowiadajacej

kazdemu pojeciu o typie innym niz „template”, tworzona jest statyczna metoda „getPoje-

cia()” (gdzie „Pojecia” zastapione sa nazwa odpowiedniego pojecia). Zwraca ona liste

obiektów implementujacych interfejs, odpowiadajacy temu pojeciu. Ta ostatnia metoda

tworzona jest tez w klasach typu „MS”, odpowiadajacym pojeciom o typie „template”,

z których bezposrednio lub posrednio dziedzicza pojecia o typie „identity” lub „assi-

gned_role”.

Formalizacja procesu tworzenia wynikłych z tej reguły operacji i metod jest przedstawiony

na rysunku 4.10. Ze wzgledu na swoja prostote nie wymaga on dokładniejszego omówienia. Do

pełnej realizacji reguły konieczne jest dodanie utworzonych operacji do odpowiednich interfej-

sów oraz implementujacych interfejsy klas, a takze uzupełnienie tresci metod. Warto zwrócic

uwage, ze tresc metod musi uwzgledniac zapisywanie i usuwanie powiazan wynikajacych z od-

niesien opartych o dane, powiazanych z danym pojeciem. Musi tez uwzgledniac koniecznosc

usuwania elementów, okreslonych jako jego czesci za pomoca przypisan czesci „DLPartLink”.

Oprócz wygenerowania i uzupełnienia klas oraz interfejsów zwiazanych z pojeciami, nalezy

równiez wygenerowac te odpowiadajace relacjom.

Reguła 9. a) Dla kazdej relacji bioracej udział w realizacji logiki dziedzinowej tworzona jest

klasa typu „MS”. Dla kazdego przypisanego do tej relacji standardowego uczestnictwa

o kierunku „target” badz „undefined”, nie powiazanego z uczestnictwem pomocniczym

o typie „role_attribution” i uczestnictw pomocniczych o typie „role_attribution”, two-

rzone sa w tej klasie statyczne metody pozwalajace pobrac obiekty zwiazane z pojeciami

przypisanymi do uczestnictw. Metody te przyjmuja jako parametry, elementy reprezentu-

jace pozostałe pojecia uczestniczace w relacji, potrzebne do uzyskania tych pierwszych.



b) W wypadku, kiedy z uczestnictwami prowadzacymi do tych potrzebnych pojec powia-

zane sa uczestnictwa pomocnicze o typie „required_parent”, wszystkie reprezentujace

je parametry zastepowane sa parametrem reprezentujacym pojecie powiazane z danym

uczestnictwem pomocniczym. c) Zwracane wartosci reprezentowane sa przez typy proste

lub odpowiednie interfejsy. W wypadku licznosci „multiple” tworzone sa one w formie

zbioru, a w wypadku licznosci „ordered multiple” – w formie listy. d) Dodatkowo, dla

kazdego odniesienia opartego o dane, posiadajacego wiecej niz dwa uczestnictwa, two-

rzona jest klasa typu „M”. Posiada ona atrybuty bazujace na wszystkich uczestnictwach

danego odniesienia, które nie maja przypisanego uczestnictwa pomocniczego o typie „re-

quired_parent”, oraz bazujace na uczestnictwach pomocniczych o tym typie. Klasa ta po-

siada tez odpowiednie metody dostepowe i konstruktor przyjmujacy wartosci wszystkich

jej atrybutów.

Formalizacja pierwszej czesci tej reguły zobrazowana jest na rysunku 4.11. Opiera sie ona

na iteracji przebiegajacej po uczestnictwach powiazanych z dana relacja, bedaca parametrem


RYSUNEK 4.11: Formalny zapis pierwszej czesci reguły 9

procedury. Dla kazdego takiego uczestnictwa tworzona jest odpowiednia statyczna metoda w

klasie typu „MS”. Do kazdej z tych metod dodawane sa równiez parametry bazujace na po-

zostałych potrzebnych uczestnictwach w relacji. Osobne petle przebiegaja po odpowiednich


uczestnictwach standardowych i pomocniczych. Podobnie jak poprzednio, zarówno kod, jak i

okreslanie typów zostało wyodrebnione do osobnych procedur, nie uwzglednionych na rysunku.

Nalezy jednak zwrócic uwage, ze wynik procedury ustalajacej typ zalezy równiez od wartosci

przyjmowanego parametru okreslajacego licznosc uczestnictwa w relacji. Warto równiez za-

uwazyc, ze w zwiazku z tym, ze elementy podstawowe sa dostepne globalnie, odnoszace sie do

nich uczestnictwa w relacji nie sa uwzgledniane przy ustalaniu parametrów dla procedur.

Druga czesc reguły, zwiazana z opcjonalnym tworzeniem klas reprezentujacych same re-

lacje, zobrazowana jest na rysunku 4.12. Dla kazdej relacji typu „DataBasedReference”, speł-

niajacej zawarte w regule warunki, tworzona jest odpowiednia klasa. Do tej klasy sa nastepnie

w sposób iteracyjny dodawane atrybuty, w oparciu o uczestnictwa przypisane do tej relacji.

Do pełnej realizacji tej czesci reguły konieczne jest oczywiscie równiez dodanie odpowiednich

metod dostepowych, które nie zostały juz zobrazowane. Dodatkowo, podobnie jak w wypadku

drugiej czesci reguły 4, przy obrazowaniu sprawdzania warunku pominieto odzwierciedlanie

sprawdzania wystapien powiazanych par relacji standardowych i pomocniczych.

Kolejnym elementem jest generowanie metod sprawdzajacych relacje dla odniesien.

Reguła 10. Dla relacji typu „DLReference”, w odpowiadajacej jej klasie tworzona jest metoda

„checkRelacja()”, przyjmujaca jako parametry elementy reprezentujace wszystkie poje-

cia uczestniczace w relacji i zwracajaca wartosc logiczna. Licznosci opisujace uczest-

nictwa na potrzeby okreslania parametrów dla tej metody, traktowane sa jako „single”,

niezaleznie od faktycznej wartosci. Wyjatkiem jest sytuacja, kiedy dane uczestnictwo jest

okreslone jako podmiot wzoru opisujacego relacje. W wypadku, kiedy z uczestnictwami

prowadzacymi do pojec bioracych udział w relacji, powiazane sa uczestnictwa pomoc-

nicze o typie „required_parent”, wszystkie reprezentujace je parametry zastepowane sa

parametrem reprezentujacym pojecie powiazane z danym uczestnictwem pomocniczym.

Przebieg formalizacji tej reguły zobrazowany jest na rysunku 4.13. Wykonanie tej procedury

bardzo przypomina to dla poprzedniej reguły. Tutaj jednak wystarczy utworzyc pojedyncza me-

tode oraz iteracyjnie dodac do niej parametry bazujace na wszystkich potrzebnych uczestnic-

twach w relacji, reprezentujacych pojecia. Podobnie jak poprzednio, iteracje realizowane sa w


RYSUNEK 4.12: Formalny zapis drugiej czesci reguły 9

osobnych petlach dla odpowiednich uczestnictw standardowych i pomocniczych. Dla uprosz-

czenia, na diagramie pominieto uwzglednianie oryginalnej licznosci w wypadku argumentów

tworzonych na podstawie uczestnictw bedacych podmiotem wzoru.

4.1.3 Metody realizujace zapytania

Dotychczas generowana struktura klas nie była praktycznie uzalezniona od specyfikacji wy-

magan zapisanej w jezyku RSL. Jedyna uwzgledniona zaleznoscia był wybór uwzglednianych



elementów. Aby jednak powiazac kod warstwy Modelu z kodem warstw Widoku i Prezentera,

konieczne jest równiez wygenerowanie metod realizujacych przypisane do scenariuszy przy-

padków uzycia zapytania. Sytuacja taka wystepuje szczególnie dla zapytan typu „get”, gdzie

dla uzyskania oczekiwanego wyniku, do wygenerowania kodu dodatkowo potrzebna jest zna-

jomosc własciwej kolejnosci wywoływania reguł wyprowadzen.

Na potrzeby formalizacji dalszych reguł, wykorzystano elementy pozwalajace odzwiercie-

dlic kolejnosc wykonywania reguł, przedstawione na rysunku 4.14. Opisuja one pojedyncze

reguły wyprowadzen („rule”) w sposób, który pozwoli połaczyc wiele z nich w odpowied-

nia strukture. Kazda z reguł wyprowadzen ma przypisane jedno pojecie („DLNotion”) w roli

wniosku („conclusion”). Ponadto, zawiera ono dowolna liczbe innych reguł wyprowadzen, re-

prezentujacych przesłanki („premises”), pozwalajace wyprowadzic ów przypisany wniosek. W


RYSUNEK 4.14: Struktura uzyta do przedstawiania kolejnosci wywołan

ten sposób, deklarujac jedne reguły wyprowadzen za pomoca przesłanek innych reguł, mozna

zdefiniowac okreslona ich sekwencje pozwalajaca uzyskac koncowy wniosek. Do tego celu,

dane wejsciowe nalezy przedstawic jako reguły wyprowadzen, posiadajace jedynie wniosek,

bez przesłanek. Zeby wykorzystanie takiej struktury miało sens, konieczne jest równiez okre-

slenie, w jaki sposób dane wyprowadzenie zostało uzyskane. Słuzy temu przypisanie do kaz-

dej reguły wnioskowania, elementu dziedzinowego („DLDomainElement”), na której sie ona

opiera. Reguły wnioskowania wykorzystane beda do odzwierciedlenia nie tylko wyprowadzen

powstałych na podstawie relacji, ale równiez zwiazanych z zaleznosciami pomiedzy pozosta-

łymi elementami modelu dziedzinowego.

W celu ułatwienia posługiwania sie struktura reguł wyprowadzen, ma ona zdefiniowane

dodatkowe opisujace ja atrybuty i relacje. Po pierwsze, kazda reguła wnioskowania ma przy-

pisany jeden z dostepnych typów okreslajacy rodzaj reprezentowanej przez nia operacji. Typ

„RELATIONSHIP” wskazuje na wykorzystanie relacji do uzyskania danego pojecia. Typ „AT-

TRIBUTE” wskazuje na pobranie atrybutu przypisanego do pojecia, a typ „CAST” na rzuto-

wanie pomiedzy dziedziczacymi z siebie pojeciami. Wyrózniono tez typ „INPUT” dla oznacza-


nia reguł wyprowadzen reprezentujacych z góry znane dane wejsciowe, których nie potrzeba

wyprowadzac. Wreszcie typ „MULTIPLE_USE” odpowiada regule odzwierciedlajacej wielo-

krotne wykorzystanie prostej relacji (pozwalajacej na uzyskanie wniosku o licznosci „single”

na podstawie pojedynczej przesłanki o licznosci „single”) dla całego zbioru danych. Po drugie,

reguła jest równiez opisana przez licznosc i nazwe, przechowujaca tego typu wartosci opisujace

uczestnictwo w relacji uzyskiwanego elementu. Wreszcie, dostepna jest równiez relacja, która

pozwala przypisac do danej reguły wyprowadzen wszystkie zawarte w strukturze przypisanych

do niej przesłanek dane wejsciowe, co pozwoli uniknac kazdorazowego ich odszukiwania.

Mechanizm uzyskiwania tak reprezentowanej kolejnosci i jego implementacja zostanie opi-

sany w nastepnej sekcji. Ponizsza reguła została napisana z załozeniem, ze taka kolejnosc

znamy, oraz ze wszelkie dane wejsciowe sa przypisane równiez do nadrzednych reguł wypro-

wadzen z uzyciem wspomnianej pomocniczej relacji.

Reguła 11. a) Dla kazdego zapytania o typie „get”, które wymaga do uzyskania odpowiedzi

wiecej niz jednego wywołania metody, w klasie odpowiadajacej ostatniemu elementowi

na którym wykonywana jest operacja, tworzona jest statyczna metoda zwracajaca wynik

zapytania. Metoda ta jako parametry posiada te z dostepnych w momencie jej wywoła-

nia elementów, które były potrzebne do uzyskania wyniku. Zwraca ona obiekt lub obiekty

klasy odpowiadajace pojeciu, które było przedmiotem zapytania. b) W tresci metody znaj-

duja sie umieszczone we własciwej kolejnosci wywołania metod pobierajacych elementy

na podstawie relacji i odnoszacych sie do wartosci atrybutów, a takze odpowiednie rzu-

towania elementów miedzy klasami. Wyniki tych wywołan sa przypisywane do lokalnych

atrybutów, tak, aby były dostepne dla pozostałych wywołan. c) Dodatkowo, jesli którekol-

wiek wywołanie powstało na podstawie reguły wyprowadzen o typie „MULTIPLE_USE”,

metoda wywołujaca wielokrotnie oryginalna metode dla kazdego elementu zbioru danych,

dodawana jest do klasy, w której oryginalna metoda sie znajdowała. d) Dla kazdego za-

pytania o typie „Transform to” tworzona jest osobna metoda. Przypisywana jest ona do

elementu podlegajacemu transformacji i opiera sie na konstruktorze docelowego obiektu

oraz pomocniczej metodzie zawartej w zwiazanej z nim klasie typu „MS”, sprawdzajacej

mozliwosc przypisania nowej roli.



Formalizacja czesci reguły, powiazanej z samym tworzeniem odpowiedniej metody zostało

przedstawione na rysunku 4.15. Na poczatku, w klasie odpowiadajacej przypisanemu elemen-

towi dziedzinowemu, tworzona jest operacja pobierajaca szukane pojecie lub pojecia. Nazwa

tej metody poprzedzone jest słowem „get”. Nastepnie, wywoływana jest procedura przypisu-

jaca do reguły wyprowadzen wszystkie zawarte w strukturze jej przesłanek dane wejsciowe.

Wykonywana jest tez iteracja przebiegajaca po tak przypisanych danych, która dodaje odpo-

wiadajace im parametry do stworzonej wczesniej metody. Na koniec, metoda jest uzupełniana

o odpowiedni kod.


RYSUNEK 4.16: Procedura generujaca kod ze struktury reguł wyprowadzen


Sam proces generacji kodu powyzszej metody został wyodrebniony do osobnej procedury,

która jest przedstawiona na rysunku 4.16. W pierwszej kolejnosci wywołuje ona rekurencyj-

nie sama siebie, dla wszystkich przesłanek zadanego elementu. Nastepnie, w zaleznosci od

tego, czy rozpatrywany element jest przesłanka dla innych, czy tez znajduje sie na samej górze

struktury, tworzona jest nowa zmienna lub generowane jest polecenie „return”. W pierwszym

z tych przypadków, rodzaj i nazwa zmiennej zaleza od pojecia przypisanego jako wniosek. W

obu natomiast przypadkach, kod, który zostanie wygenerowany w celu wykorzystania w po-

leceniu lub przypisania do zmiennej, zalezy od typu rozwazanego elementu. W wypadku typu

„CAST”, kod zawiera rzutowanie elementu bedacego przesłanka na element bedacy wnioskiem.

W dwóch pozostałych przypadkach, ze statycznej klasy odpowiadajacej elementowi dziedzino-

wemu wywoływana jest odpowiednia metoda „get” o nazwie pochodzacej od lokalnej nazwy

elementu przypisanego do reguły wyprowadzen. W wypadku elementów o typie „RELATION-

SHIP” metoda ta przyjmuje jako parametry, elementy zwiazane z przesłankami.

Tworzenie metod wielokrotnie wywołujacych te sama metode dla zbioru danych, nie zo-

stało tutaj przedstawione. Jest proste do zrealizowania, wykorzystujac w generowanym kodzie

odpowiednie petle. Sam nagłówek metody rózni sie tylko zastosowaniem zbiorów elementów,

zamiast ich pojedynczych przedstawicieli. Podobnie pominieto obrazowanie tworzenia metod

dla zapytan „transform to”.

Opisany mechanizm jest równiez wykorzystywany do generacji kodu uzyskujacego warto-

sci wyprowadzanych atrybutów. Reprezentuje to kolejna reguła.

Reguła 12. Dla kazdej metody dostepowej, stworzonej dla atrybutów odpowiadajacym po-

jeciom okreslonym jako „derived”, podejmowana jest próba wygenerowania kodu na

analogicznej zasadzie do generowania kodu dla zapytania. W tym przypadku, atrybut

traktowany jest jako przedmiot zapytania, a pojecie w którym sie znajduje – jako jedyne

znane dane.

Jako ze przebieg wykonania tej reguły jest w wiekszosci analogiczny do wykonania po-

przedniej, nie została ona osobno zobrazowana. Rózni sie jedynie tym, ze odpowiednia se-

kwencja wywołan jest tworzona na innej podstawie i nie moze sie w niej znalezc bezposrednie

pobranie wartosci szukanego atrybutu z klasy, do której jest on przypisany.


4.1.4 Generowanie kodu ze wzorów

Wiele elementów wystepujacych w specyfikacji dziedzinowej posiada przypisane wzory prze-

chowujace formuły, które zostana podczas generacji przetłumaczone na kod. Generalnie mozna

wyróznic trzy rózne przypadki, w których taka sytuacja zachodzi. W kazdej z nich obowia-

zuja te same reguły, według których kod jest generowany. Po pierwsze, w wypadku warunków

tozsamosci, warunków poprawnosci, odniesien opartych o wzory i czesci przekształcen algo-

rytmicznych potrzebujemy wygenerowac kod, który sprawdza okreslony warunek. Generacje

takiego kodu okresla kolejna reguła.

Reguła 13. W celu wygenerowania kodu sprawdzajacego dla wzorów warunkowych, nalezy

przekształcic zawarte w nich formuły na wykonujacy je kod. a) W wypadku wzorów o

typie „simple”, wyliczona wartosc wyrazenia jest zwracana poleceniem „return”. b) W

wypadku wzorów o typie „universal quantification” i „existential quantification” dekla-

rowana jest zmienna logiczna, a otrzymany kod wywoływany jest dla kazdego elementu

podczas iteracji po zbiorze wskazanym przez podmiot wzoru. Konieczna jest tez zamiana

znaku „$” w kodzie na zmienna wykorzystywana w przebiegu petli. Dla typów warun-

ków „universal quatification”, zmienna po skonczeniu iteracji powinna przyjac war-

tosc bedaca koniunkcja wyników owych wywołan. Dla typów „existential quantification,

zmienna przyjmuje wartosc alternatywy wyników wywołan. W obu wypadkach wartosc

zmiennej jest zwracana. c) W wypadku wzorów o typie „membership” generowany jest

kod wykorzystujacy operacje „getDLRoles()” interfejsu „IDLClass”. Kod ten sprawdza

istnienie przypisania do danego obiektu roli, odpowiadajacej pojeciom o typie „assi-

gned_role”. Generowany jest tez kod wykorzystujacy metode „checkPojecie()” z klasy

pomocniczej „MSPojecie” odpowiadajacej danemu pojeciu. Kod ten sprawdza przypisa-

nia do pojec o typie „inferred_role”. Na koniec, wykorzystana jest instrukcja Javy „in-

stanceof”, słuzaca do sprawdzenia przynaleznosci do klas odpowiadajacych pozostałym

typom pojec.

Drugim z omawianych przypadków jest sytuacja, w której musimy znalezc elementy da-

nego typu spełniajace podany warunek. Jest ona powiazana praktycznie tylko z odniesieniami.


Reprezentuje ja kolejna reguła.

Reguła 14. W celu wygenerowania kodu znajdujacego elementy dla wzorów warunkowych,

nalezy najpierw wygenerowac kod sprawdzajacy same warunki. Nastepnie wykonywana

jest iteracja po elementach o typie zgodnym z tym szukanym i dla kazdego z nich wywoły-

wana jest metoda zawierajaca kod sprawdzajacy. W sytuacji, kiedy licznosc uczestnictwa

w relacji powiazanego z odniesieniem i zawierajacego szukany element jest okreslona

jako „single”, biezacy element jest zwracany w wypadku jego pozytywnego sprawdzenia.

W wypadku licznosci „multiple” i „ordered multiple” biezacy element jest wstawiany do

zbioru lub do listy, które musza byc wczesniej zadeklarowane i po skonczeniu iteracji sa

zwracane.

Ostatnia sytuacja dotyczy wzorów uzywanych do przekształcania pojec jednych w drugie.

Najczesciej wystepuje ona w zwiazku z obliczeniami i wiaze sie z wykorzystaniem biblioteki

do obliczen symbolicznych, w celu uzyskania odpowiedniej formy wzorów. Powiazana jest ona

z wszelkimi przekształceniami, a jej przebieg opisuje kolejna reguła.

Reguła 15. W celu wygenerowania kodu dla wzorów przekształcen o typach „simple”, „sys-

tem”, „summation” i „multiplication” nalezy przekształcic zawarte w nich formuły na

wykonujacy je kod. a) W wypadku wzorów o typie „simple” i „system” formuły sa do-

datkowo wczesniej przekształcane do formy wyznaczajacej aktualnie wyprowadzane po-

jecie, a wynik obliczen jest zwracany poleceniem „return”. b) W wypadku wzorów o

typach „summation” i „multiplication” deklarowana jest zmienna logiczna, a otrzymany

kod wywoływany jest dla kazdego elementu podczas iteracji po zbiorze wskazanym przez

podmiot wzoru. Konieczne jest tez zastapienie znaku „$” w kodzie na zmienna wykorzy-

stywana w petli. W wypadku pierwszego z tych typów warunków, zmienna po zakonczeniu

iteracji powinna przyjac wartosc bedaca suma wyników owych wywołan. W wypadku

drugiego z warunków, zmienna powinna przyjac wartosc iloczynu wyników wywołan. W

obu wypadkach, wartosc zmiennej jest zwracana. c) Wzory o typie „query” rozpatrywane


sa jak odpowiednie zapytanie o typie „get”. d) Dla wzorów o typie „indirect”, nie posia-

dajacych przypisanego podmiotu, nalezy wygenerowac kod tworzacy nowy obiekt odpo-

wiadajacy wyprowadzanemu pojeciu. Nastepnie nalezy przekształcic zawarte we wzorze

poszczególne formuły na kod i wykorzystac je do inicjalizacji wartosci powiazanych z

tym obiektem. e) W wypadku wzorów „indirect’,’ posiadajacych podmiot, kod uzyskany z

przekształcenia poszczególnych formuł powinien zostac wykorzystany do zmiany obiektu

zwiazanego z uczestnictwem wskazanym przez podmiot. f) Wzory o typie „invocation” wy-

korzystuja jako kod bezposrednio sama tresc formuły. g) Wzory o typie „mapping” reali-

zowane sa w formie odpowiedniego zbioru konstrukcji „if-else”. Z pierwszego elementu

kazdej pary generowany jest kod traktujac go jak formułe wzoru warunków o typie „sim-

ple”. Drugi element jest zwracany, kiedy owo okreslone kodem sprawdzenie da wynik

pozytywny. h) Potencjalny ostatni niesparowany element przekształcenia jest zwracany,

jesli zaden z wczesniejszych elementów nie został zwrócony.

Sam proces tłumaczenia formuł na kod nie został szczegółowo opisany, gdyz rzadzace nim

zasady sa dosyc intuicyjne. W zwiazku z tym, ze wykorzystywany format zapisu formuł jest

zblizony do jezyka Java, w celu uzyskania funkcjonalnego kodu konieczna jest jedynie korekta

drobnych kwestii. Przykładem jest koniecznosc zamiany wykorzystania znaku potegi, na wy-

wołania odpowiednich funkcji z biblioteki „Math”. Konieczna jest tez oczywiscie zamiana wy-

wołan funkcji i odwołan do atrybutów zapisanych zgodnie ze składnia zapisana w poprzednim

rozdziale, na odpowiadajace im konstrukcje w jezyku Java.

Warto zwrócic uwage, ze wywołania funkcji, w zaleznosci od liczby parametrów, moga

oznaczac zarówno uzyskanie na jej podstawie wartosci, jak i sprawdzenie jej zachodzenia. W

wypadku odwołan do odniesien opartych o dane, wystepujacych we wzorach typu „indirect”,

oznaczaja wrecz dodanie nowego powiazania miedzy danymi. W tym ostatnim przypadku ko-

niecznosc dodania nowych powiazan moze byc tez przedstawiona za pomoca nadania wartosci

powiazaniom dereferencyjnym odwołujacym sie do uzyskania wartosci na podstawie relacji.

Nalezy tez odpowiednio interpretowac znak „==”, jako porównanie tozsamosci lub wartosci,

w zaleznosci od tego, czy operujemy na elementach bedacych bytami, czy własciwosciami. W

niektórych przypadkach wymaga to wnioskowania typu rezultatu dla wybranych fragmentów

4.2. Przykładowa implementacja 123

formuł.

W wypadku zwracania wartosci odpowiadajacym pojeciom o typie „inferred_role”, cze-

sto konieczne jest opakowanie otrzymanego wyniku w odpowiednia klase. Bardziej szczegól-

nego potraktowania wymagaja jedynie dwie specyficzne sytuacje. Pierwsza z nich zwiazana

jest z odnoszeniem sie do elementów wskazanych przez uczestnictwa, do których przypisane

sa uczestnictwa pomocnicze. Wykorzystywane w uzyskanych wyprowadzeniach odwołania do

uczestnictw powiazanych z uczestnictwem pomocniczym o typie „required_parent” nalezy przy

generacji kodu traktowac jak odwołania do odpowiednich atrybutów wskazanego przez uczest-

nictwo pojecia. Natomiast w sytuacji, kiedy z uczestnictwem wskazujacym na wyprowadzany

element powiazane jest uczestnictwo pomocnicze o typie „role_attribution”, nalezy wynik wy-

prowadzenia zwrócic w formie klasy reprezentujacej wskazana przez uczestnictwo pomocnicze

role. Druga sytuacja zwiazana jest z miedzy innymi wykorzystaniem elementów podstawowych

w regułach i została ujeta w ostatnia regułe translacyjna.

Reguła 16. W wypadku wzorów wykorzystujacych elementy podstawowe, na poczatku wyge-

nerowanych na ich podstawie metod nalezy dodac kod przypisujacy do odpowiednich

zmiennych wartosci uzyskane z kodu powiazanego z tymi elementami. W sytuacji, kiedy

dane odniesienie oparte o wzór nie ma podanego zbioru elementów, dla którego warunek

jest sprawdzany, nalezy dodac na poczatku wygenerowanej na jego podstawie metody,

kod przypisujacy do odpowiedniej zmiennej zbiór wszystkich elementów danego typu uzy-

skany z pomoca wywołania odpowiedniej metody.

4.2 Przykładowa implementacja

4.2.1 Struktura działania transformacji

W celu przeprowadzenia testów i sprawdzenia działania opracowanego podejscia w praktyce,

dokonano rozszerzenia systemu ReDSeeDS, realizujacego odpowiednia funkcjonalnosc dla je-

zyka RSL-DL. Stworzone rozwiazanie oparto o repozytorium wygenerowane za pomoca sro-

dowiska EMF [73, 26]. Umozliwiło to takze łatwe stworzenie edytora graficznego dla jezyka


RYSUNEK 4.17: Ogólny schemat generacji kodu

RSL-DL, poprzez wykorzystanie powiazanego srodowiska GMF [73, 36]. Z uwagi na ograni-

czenia oraz wydajnosc transformacji pisanych w jezyku MOLA, zdecydowano sie na wykona-

nie transformacji w jezyku Java. Transformacja ta operuje na obiektach dostepnych w repozy-

torium opartym na srodowisku EMF.

Powiazanie modelu w jezyku RSL-DL z oryginalna specyfikacja w jezyku RSL, zostało

wykonane poprzez uzupełnienie opisów stwierdzen dziedzinowych (patrz opis jezyka RSL) o

odpowiednie deklaracje zapisane w formacie XML. Zmodyfikowano równiez interfejs systemu

ReDSeeDS, tak aby mozna było korzystac z powstałego rozszerzania w powiazaniu z wczesniej

dostepnymi funkcjonalnosciami. Stworzono miedzy innymi odpowiednie formularze udostep-

niajace uzytkownikowi systemu wspomniana reprezentacje zapytan.

Ogólna idea działania generacji kodu w ramach zintegrowanego systemu ReDSeeDS została

przedstawiona na rysunku 4.17. W celu realizacji generatora dla jezyka RSL-DL zaimplemen-

towany został specjalny silnik wnioskujacy. Silnik ten operuje na zapytaniach umieszczonych

w ramach scenariuszy przypadków uzycia. Ustala on własciwa sekwencje wykorzystania reguł,

zawartych w konstrukcjach jezyka RSL-DL. Poszczególne wzory zapytan sa przekształcane do

odpowiedniej formy, wymaganej przez sekwencje reguł, za pomoca biblioteki do obliczen sym-

bolicznych (SymJa). Dopiero tak przekształcone reguły sa zamieniane na kod i umieszczane w


RYSUNEK 4.18: Struktura klas implementujacych transformacje

metodach klas, wygenerowanych na podstawie reszty specyfikacji dziedzinowej.

Kod wygenerowany z modelu dziedziny zapisanego w jezyku RSL-DL moze byc na koncu

połaczony z kodem wygenerowanym ze specyfikacji wymagan zapisanej w jezyku RSL. W

obecnej wersji systemu połaczenie to nie jest uzyskiwane automatycznie, lecz wymaga recz-

nego uzupełnienia kodu logiki aplikacji (warstwa prezentera) o odpowiednie wywołania metod

z warstwy logiki dziedzinowej (warstwa modelu). Pełna automatyzacja procesu wymaga prze-

prowadzenia dodatkowych prac i stanowi interesujacy element przyszłej agendy badawczej.

Struktura kodu słuzacego do zaimplementowania transformacji została zaprezentowana na

rysunku 4.18. Ze wzgledu na czytelnosc, nie pokazano na nim wszystkich szczegółów me-

tod zawartych w klasach. Ograniczono sie tylko do nazw wazniejszych metod publicznych.

Podstawe przedstawionej struktury stanowi klasa „DLTransformationEngine”. Definiuje ona


ogólny schemat implementacji transformacji i jest dalej rozszerzana przez klasy implemen-

tujace transformacje do poszczególnych jezyków docelowych. Na potrzeby niniejszej pracy

napisano transformacje generujaca kod w jezyku Java zawarta w klasie „JavaDLTransformatio-

nEngine”. Zaproponowana struktura klas pozwala jednak na łatwe rozszerzanie rozwiazania o

kolejne jezyki. Schemat implementacji opiera sie na wykorzystaniu klas zwiazanych z repozyto-

rium srodowiska EMF, dostepnych za posrednictwem klasy „DLRepository” oraz odwołaniach

do odpowiednio przykrytej biblioteki SymJa, realizujacej obliczenia symboliczne za pomoca

interfejsu „IDLSymbolicEngine”. Dodatkowo, dla klas realizujacych konkretne transformacje

dostepne sa trzy wspólne klasy z mozliwymi do wykorzystania przez nie operacjami niezalez-

nymi od docelowego jezyka. Pierwsza z nich, „DLInferenceEngine”, zawiera implementacje

silnika wnioskujacego. Dwie pozostałe pomocnicze klasy „SimpleTypesHelper” i „DLPartici-

pationsHelper” zawieraja natomiast metody ułatwiajace operacje zwiazane odpowiednio z wy-

stepujacym w regułach pojeciem typów prostych i z uzyskiwaniem odpowiednich uczestnictw

na podstawie relacji.

4.2.2 Silnik wnioskujacy

Jednym z najwazniejszych komponentów powstałej transformacji jest silnik wnioskujacy. Dla

relacji dziedzinowych okresla on własciwa kolejnosc ich stosowania, potrzebna do wykona-

nia akcji reprezentowanych przez zapytania o typie „get”. Jako dane wejsciowe przyjmuje on

zbiór pojec reprezentujacy dostepne dane, pojecie reprezentujace szukany element oraz opcjo-

nalnie nazwe dziedziny wskazujaca na odpowiedni podzbiór modelu. Przed przejsciem do sa-

mego wnioskowania, przygotowana jest baza reguł, na podstawie których bedzie ono przepro-

wadzone. W jej skład wliczane sa wszelkie mozliwe wyprowadzenia wynikajace z danej relacji.

Przy tym, silnik rozpatruje mozliwosc uzyskania kazdej z wartosci o typie „target” lub „unde-

fined” i dobiera do niej wszystkie potrzebne do jej uzyskania wartosci o typach „source” lub

„undefined”.

Konkretne reguły uwzgledniaja licznosci okreslone w uczestnictwach. Przy tym, w pro-

stych przypadkach uwzgledniana jest równiez mozliwosc wielokrotnego wywołania danej re-

guły dla całego zbioru. Jesli okreslona jest dziedzina, na podstawie której przeprowadzane jest


wnioskowanie, uwzgledniane sa tylko relacje nalezace do dziedziny (w tym odziedziczone z in-

nych dziedzin przez elementy znajdujace sie we wskazanej dziedzinie). Uwzgledniane sa takze

uczestnictwa pomocnicze. Wszystkie wartosci na wejsciu do reguł powiazane z danym uczest-

nictwem typu „required_parent” zastepowane sa wartoscia wynikajaca z owego uczestnictwa.

Podobnie, kazda wartosc na wyjsciu powiazana z uczestnictwem typu „role_attribution” jest za-

stepowana wartoscia z niego wynikajaca. Dodatkowo, mozliwosc wyznaczenia danego pojecia

na podstawie relacji zawierajacej wzór moze byc sprawdzona za pomoca biblioteki do obliczen

symbolicznych. Tworzone sa równiez reguły odzwierciedlajace wszelkie mozliwe przejscia po-

miedzy elementami. Dotyczy to wszystkich elementów z dziedziny, elementów reprezentuja-

cych dostepne dane i szukanego elementu, badz po prostu całego modelu, jesli dziedzina nie

jest wskazana. W skład tego typu przejsc wchodzi uzyskiwanie atrybutów z pojec, do których

sa one przypisane, rzutowanie pomiedzy dziedziczacymi z siebie pojeciami, czy w prostych

przypadkach – tworzenie pojec na podstawie zestawów danych ich reprezentujacych.

Nastepnie, wykorzystujac powstała baze, przeprowadzane jest wnioskowanie dazace do

uzyskania elementu szukanego, na podstawie elementów reprezentujacych dostepne dane. Prze-

bieg samego wnioskowania odbiega jednak od najbardziej typowych rozwiazan. Jego podstawa

nie jest sprawdzanie przesłanek i przyjmowanie wniosku reguły za prawdziwy w wypadku

jego spełnienia. Zamiast tego sprawdzane jest, czy dysponujemy informacjami potrzebnymi do

uzyskania danego elementu na podstawie danej reguły. Nalezy zwrócic uwage, ze podczas ta-

kiego sprawdzenia uwzgledniane sa równiez licznosci elementów. Informacja o regułach, które

zostały uznane za mozliwe do zastosowania, zapisywane sa z uwzglednieniem kontekstu, w

którym to nastapiło. Tworzona jest struktura drzewiasta, łaczaca uzyskany element z tymi, na

podstawie których został on wyprowadzony oraz zapisywana jest w niej wykorzystana reguła.

Realizacja tego mechanizmu została zaimplementowana zarówno w oparciu o wnioskowanie w

przód (Modus Ponendo Ponens), jak i w tył (Modus Tollendo Tollens) [30]. W obecnej im-

plementacji nie ma potrzeby stosowania pierwszej z tych wersji, dlatego tez dalej zostanie

szczegółowo omówiona tylko ta druga, jako bardziej optymalna. W przyszłosci mozna roz-

wazyc stworzenie transformacji na bazie pierwszej wersji wnioskowania, która tworzyłaby kod

logiki dziedzinowej o szerszym zakresie funkcjonalnosci, niz jest to potrzebne do zrealizowa-


nia specyfikacji wymagan. Potrzebne byłoby jednak wykonanie dodatkowej analizy zastosowan

takiego rozwiazania.

Stosujac wersje maszyny wnioskujacej w oparciu o wnioskowanie w tył rozpoczynamy od

szukanego elementu, który traktujemy jako korzen tworzonego drzewa. Nastepnie odnajdujemy

wszystkie reguły, które pozwalaja na jego wyprowadzenie. Po znalezieniu reguły, dodajemy wy-

magane przez nia elementy jako liscie do rozpatrywanego wezła (w korzeniu drzewa). Ponadto,

do tego wezła przypisujemy regułe, z której skorzystalismy. Jesli znaleziono wiecej niz jedna

pasujaca regułe, duplikujemy tworzona strukture na odpowiednia liczbe wersji i kazda z nich

rozwijamy wzgledem innej reguły. Dla kazdej struktury proces powtarzamy dla jej lisci, do

czasu, az wszystkie liscie beda reprezentowały elementy odpowiadajace danym wejsciowym,

badz nie znajdziemy reguł pozwalajacych na rozwiniecie któregokolwiek z lisci. Dodatkowo,

jesli zastosowanie jakiejkolwiek reguły miałoby spowodowac, ze na drodze od któregos z li-

sci do korzenia pojawiałby sie dwukrotnie ten sam element, nalezy ja pominac. Jako wynik

zwracamy strukture z najmniejsza liczba wezłów nie bedacych liscmi. Oznacza to strukture, do

której stworzenia zastosowano reguły najmniejsza liczbe razy, lub jeszcze lepiej – zawierajaca

najmniejsza liczbe unikalnych pod wzgledem przypisanej reguły wezłów. Sama implementacja

tego algorytmu moze byc dodatkowo zoptymalizowana poprzez wspólne rozpatrywanie czesci

struktur nie rózniacych sie pomiedzy kopiami struktury, oraz ponowne wykorzystanie wezłów

reprezentujacych wartosc, gdy były juz uzyte w innej czesci drzewa. Przy tym, ta druga zmiana

sprawia oczywiscie, ze struktura przestaje byc drzewem.

Warto zwrócic uwage, ze zaprezentowany mechanizm pozwala powiadamiac uzytkownika

o błedach w zupełnie inny sposób niz typowo spotykany dla jezyków programowania. System

nie informuje uzytkownika o wystapieniu błedu składniowego w konkretnym wierszu kodu, czy

tez o nieprawidłowym wykonaniu w danej metodzie. Zamiast tego otrzymamy np. informacje,

ze system nie wie w jaki sposób powiazac jedno z pojec reprezentowanych przez liscie drzewa

z danymi wejsciowymi. W rzeczywistosci zdarzaja sie jednak równiez sytuacje bardziej skom-

plikowane, gdy powstało zbyt wiele róznych duplikatów struktury oraz gdy brakuje powiazan

dla wiekszej liczby lisci.


RYSUNEK 4.19: Szczegółowy schemat generacji kodu dla zapytania

4.2.3 Generacja kodu

Proces generacji kodu skupia sie na dostarczaniu metod realizujacych kolejne zapytania za-

gniezdzone w specyfikacji zapisanej w jezyku RSL. Przy rozpatrywaniu kazdego z zapytan ge-

nerowane sa wszystkie niezbedne czesci kodu, które nie zostały juz wygenerowane przy okazji

poprzednio przetworzonych zapytan. W ten sposób, metoda przyrostowa, powstaje kod realizu-

jacy pełen wymagany zakres logiki dziedzinowej.

Ogólny schemat generowania kodu dla pojedynczego zapytania został przedstawiony na

rysunku 4.19. Kiedy przetwarzane zapytanie nie rozpoczyna sie od słowa kluczowego „get”,

sytuacja jest stosunkowo prosta. Na podstawie reguł transformacji od 1 do 8 przedstawionych

we wczesniejszej czesci tego rozdziału, tworzona jest odpowiednia struktura klas dla pojecia be-

dacego przedmiotem zapytania, a takze dla pojec z nim zwiazanych i wszelkich innych pojec,

które pojawiły sie przy okazji realizacji tych reguł. W szczególnosci, dotyczy to pojec, z któ-


rych przetwarzane pojecie dziedziczy, jego atrybutów, oraz pojec, z którymi jest ono powiazane

za pomoca odniesien opartych o dane. W przypadku kiedy zostanie napotkana podczas takiej

generacji sytuacja opisana w regule transformacji 12, jej wykonywanie jest realizowane analo-

gicznie do innych zapytan typu „get”. Pomijane sa wtedy jedynie niepotrzebne poczatkowe i

koncowe etapy.

Jesli zapytanie rozpoczyna sie od sformułowania „transform to”, to tworzona jest metoda

realizujaca odpowiednie przypisanie roli na podstawie ostatniej czesci reguły transformacji 11

i zwracany jest kod ja wywołujacy. W przeciwnym wypadku, znajdowana jest odpowiednia ist-

niejaca metoda i zwracany jest kod realizujacy do niej odwołanie, zaleznie od pierwszego słowa

kluczowego zapytania. Dla zapytan rozpoczynajacych sie od słowa „create” zwracane jest wy-

wołanie odpowiedniego konstruktora, a nastepnie dodawana instrukcja „pojecie.create();” od-

powiadajaca danemu pojeciu. Dla słowa „read” zwracany jest kod wywołujacy metode „MSPo-

jecie.getPojecia();”, natomiast dla słów „update”, „delete” i „validate” generowane sa odpo-

wiednio instrukcje „pojecie.update();”, „pojecie.delete();” lub „pojecie.validate();”. Dodatkowo,

dla słów „update”, „delete” i „validate”, w zwracanym kodzie wywoływane jest mapowanie

obiektów transferu danych wygenerowanych przez oryginalna transformacje systemu ReDSe-

eDS na klasy odpowiadajace pojeciom dziedzinowym. Z kolei, dla słowa „read” generowane

jest mapowanie odwrotne: klas na obiekty transferu danych.

W wypadku zapytan rozpoczynajacych sie od słowa kluczowego „get” proces jest nieco

bardziej skomplikowany. Przed przystapieniem do wykorzystania silnika wnioskujacego, ko-

nieczne jest ustalenie dostepnych danych, na podstawie których bedzie odbywało sie wniosko-

wanie. Znajdowane sa odpowiednie zdania w scenariuszach przypadków uzycia, w których wy-

stapiło sformułowanie zwiazane z twierdzeniem dziedzinowym i okreslane sa wszelkie pojecia

o typach „concept”, „simple view”, „list view” i „tree view”, które wystapiły wczesniej w bada-

nych scenariuszach. Nastepnie, na podstawie kazdej unikalnej tak ustalonej grupy pojec, silnik

wnioskujacy okresla sekwencje wywołan reguł prowadzace do uzyskania kodu realizujacego

zapytania. Jako dane wejsciowe traktuje on pojecia jezyka RSL-DL, odpowiadajace pojeciom

jezyka RSL ze wspomnianego wyzej zbioru. Kolejnym krokiem jest analogiczna do wczesniej

przedstawionej, generacja struktury klas dla wszelkich opisanych pojec. Dopiero wtedy, w ra-


zie potrzeby, zawarte w strukturze reguły sa na biezaco przekształcane do odpowiedniej formy

i generowany z nich kod w oparciu o reguły transformacji od 11 do 16. Ostatnim krokiem jest

zwrócenie mapy kodów realizujacych zapytanie dla danego zestawu danych wejsciowych. Klu-

czem sa tutaj identyfikatory scenariuszy, w których dany zestaw pojec wystapił.

Dla celów badawczych zaimplementowano powyzsze zasady dla pojec o typach „concept”,

„simple view” i „list view”. Dla pojec typu „tree view” zaimplementowane rozszerzenie na-

rzedzia ReDSeeDS dokonuje jedynie pobrania pojec do zbiorów, na których bazuja dane wej-

sciowe. Dla takich pojec nie została równiez zaimplementowana odpowiednia obsługa mapo-

wania na pojecia dziedzinowe oraz reprezentujace je klasy. Brak takiej implementacji nie ma

jednak znaczenia dla oceny mozliwosci generacji kodu logiki dziedzinowej i jedynie ogranicza

zakres mozliwych do obsłuzenia rodzajów elementów interfejsu uzytkownika.

133

Rozdział 5

Studium przypadku

5.1 Specyfikacja wymagan

W ramach studium przypadku został wykonany system wspierajacy obsługe wybranych funk-

cjonalnosci zwiazanych z dydaktyka dla hipotetycznej uczelni. Jego tworzenie rozpoczeto od

wykonania podstawowej specyfikacji w jezyku RSL. Wystepuje w niej trzech aktorów – stu-

dent, nauczyciel i pracownik dziekanatu. Specyfikacja składa sie z szesciu pakietów wymagan,

reprezentujacych podstawowe grupy funkcjonalnosci – zarzadzanie przedmiotami, zarzadzanie

wzorcami przedmiotów, zarzadzanie zapisami na przedmioty, zarzadzanie ocenami, zarzadza-

nie studentami i zarzadzanie nauczycielami. Zawiera ona równiez słownik pokazujacy strukture

i zaleznosci pomiedzy uzytymi terminami. Podczas bardziej szczegółowego przedstawiania tej

specyfikacji skupimy uwage na miejscach, gdzie funkcjonalnosc systemu powiazana jest z wie-

dza dziedzinowa, której nie dało sie wystarczajaco dokładnie opisac za pomoca jezyka RSL.

Dodatkowo na tym etapie tworzenia studium przypadku jedyna widoczna róznica w stosunku

do zwykłej specyfikacji w jezyku RSL, bedzie wykorzystanie dodatkowych typów akcji repre-

zentujacych operacje dziedzinowe. Wystepuja one w miejscach gdzie normalnie rodzaj akcji

zwiazanej z danym zdaniem byłby nieokreslony (patrz koniec sekcji 2.1.2).

Rysunek 5.1 przedstawia przypadki uzycia zawarte w dwóch sposród szesciu pakietów – za-

rzadzanie przedmiotami i zarzadzanie wzorcami przedmiotów. Oprócz prostych operacji CRUD

[62] zwiazanych z zarzadzaniem wzorcami przedmiotów i biezaco uruchomionymi przedmio-

tami, reprezentuja one takze mozliwosci przegladania listy wszystkich przedmiotów, przypisy-

wania nauczycieli do przedmiotów, czy masowego uruchamiania kolejnych edycji przedmiotów

134 Rozdział 5. Studium przypadku

RYSUNEK 5.1: Przypadki uzycia z pakietów zarzadzania przedmiotami i zarza-dzania wzorcami przedmiotów

RYSUNEK 5.2: Scenariusz przypadku uzycia „Show current courses list”

na nastepny semestr. Z punktu widzenia wiedzy dziedzinowej beda nas interesowały głównie

dwa z tych przypadków uzycia – pokazanie listy biezaco uruchomionych przedmiotów („Show

current courses”) i uruchomienie kolejnych edycji przedmiotów („Repeat courses”).

Scenariusz pierwszego z tych przypadków uzycia jest pokazany na rysunku 5.2. Po wy-

braniu odpowiedniej opcji przez uzytkownika, system ustala biezacy semestr, pobiera na jego

podstawie liste przedmiotów i wyswietla okno ja prezentujace. Zgodnie z wczesniej opisanymi

zasadami jezyka RSL pierwsze zdanie zostało okreslone jako „Actor to Trigger” o typie akcji

5.1. Specyfikacja wymagan 135

„Select”, trzecie jako „System to List View” o typie akcji ”Read”, a czwarte jako „System to

Screen” o typie „Show’. Na koncu scenariusza znajduje sie równiez szereg wywołan („invoke”),

sygnalizujacych dalsze mozliwe do bezposredniego wykonania przypadki uzycia, zgodnie z

relacjami wywołan na diagramie przypadków uzycia. Nowoscia jest tu natomiast oznaczenie

drugiego zdania jako „System to Concept” o typie „Query”. Okresla ono, ze mechanizm wyko-

nania tego kroku scenariusza bedzie automatycznie wywnioskowany w oparciu o informacje,

które powinny byc w tym momencie scenariusza znane. W tym konkretnym wypadku mozemy

wnioskowac, ze beda to jedynie domyslnie dostepne informacje. Wynika to stad, ze jedyne wy-

stepujace do tego momentu pojecie w scenariuszu jest typu „trigger” i scenariusz nie posiada

zadnych okreslonych parametrów w warunkach wstepnych („precondition”). Wiadomo tez, ze

podmiotem zapytania musi byc aktualny semestr („current semester”), jako ze jest to jedyne

dopełnienie w tym zdaniu.

Model pojec zwiazany z rozwazanym przypadkiem uzycia pokazany jest na rysunku 5.3.

Mozemy na nim zaobserwowac, ze wystepujace w scenariuszu okno „current courses list win-

dow” jest – jak nalezało oczekiwac – powiazane z lista przedmiotów („courses list”). Dodat-

kowo, kierunek łaczacej ich strzałki wskazuje, ze celem tego okna jest wyswietlanie wspo-

mnianej listy. Mozemy tez zauwazyc, ze poszczególne przedmioty sa reprezentowane na liscie

jedynie za pomoca swoich nazw. Jest to bowiem jedyny atrybut podłaczony do tego widoku

danych. Dla porzadku zaznaczone jest równiez umieszczenie wszystkich przycisków rozpoczy-

najacych wywoływane przypadki uzycia na oknie prezentujacym liste. Widzimy tez, ze czesc

z nich bedzie wykonana w oparciu o wybrana pozycje z listy przedmiotów. Model zawiera

takze wszelkie inne pojecia wystepujace w omawianym scenariuszu, w tym pojecie aktualnego

semestru („current semester”), aczkolwiek semantyczna zaleznosc pomiedzy nim, a pojeciem

przedmiotu nie jest mozliwa do odzwierciedlenia w tym modelu.

Scenariusz przypadku uzycia realizujacego uruchomienie kolejnych edycji przedmiotów

jest pokazany na rysunku 5.4. Zaczyna sie on analogicznie do tego poprzedniego. Po wybra-

niu odpowiedniej opcji przez uzytkownika, system okresla odpowiedni semestr (tym razem po-

przedni, a nie biezacy), pobiera dla niego liste przedmiotów i wyswietla okno ja prezentujace.

W odróznieniu od poprzedniego przypadku, uzytkownik nastepnie wybiera zbiór elementów z


RYSUNEK 5.3: Model pojec dla przypadku uzycia „Show current courses list”

RYSUNEK 5.4: Scenariusz przypadku uzycia „Repeat courses”


RYSUNEK 5.5: Model pojec przypadku uzycia „Repeat courses”

listy i zatwierdza go za pomoca odpowiedniego przycisku. Odzwierciedlone jest to przez dwa

kolejne zdania, pierwsze z nich oznaczone jako „Actor to List View”, a drugie jako „Actor to

Trigger” o typie „Select”. Po nich znowu wystepuje zdanie „System to Concept” typu „Query”,

które bedzie wymagało wykorzystania silnika wnioskujacego. Okresla ono, ze system powinien

utworzyc dla wybranych przedmiotów ich wersje na kolejny semestr. W szczegółach zapytania

bedzie wiec okreslone, ze jego podmiotem jest obiekt „course repetitions”. Wsród informacji

dostepnych podczas szukania sposobu realizacji tej operacji znajdowac sie bedzie oczywiscie

drugi podmiot rozwazanego zdania, czyli „set of courses”. Wreszcie na koniec, system zapi-

suje utworzone przedmioty i wyswietla informujacy o tym komunikat. Jest to odzwierciedlone

odpowiednio za pomoca zdan „System to Concept” o typie ”Create” i „System to Message” o

typie „Show”.

Rysunek 5.5 przedstawia model pojec dla tego przypadku uzycia. Zaznaczone jest w nim

oczywiscie wyswietlanie listy przedmiotów na oknie „courses to repeat selection window”.

Dodatkowo jednak, zawarta jest takze informacja, ze z wybraniem przycisku „create courses

repetitions” zwiazane jest przekazanie wybranych pozycji z listy przedmiotów. Symbolizuje to


RYSUNEK 5.6: Przypadki uzycia z pakietów zarzadzania ocenami i zarzadzaniazapisami na przedmioty

strzałka z etykieta „action param”. Jak w poprzednim wypadku, mamy równiez informacje o

rodzaju danych wyswietlanych na liscie i reprezentacje wszystkich pozostałych pojec wystepu-

jacych w scenariuszu. Tym razem jednak nie tylko brakuje nam mozliwosci odzwierciedlenia

zaleznosci pomiedzy poprzednim semestrem a przedmiotem, ale równiez pomiedzy przedmio-

tem a jego kolejna edycja.

Rysunek 5.6 przedstawia przypadki uzycia zawarte w pakietach zarzadzanie ocenami i za-

rzadzanie zapisami na zajecia. Obejmuja one zarówno te zwiazane z przegladaniem przez na-

uczyciela przypisanych mu zajec i zapisanych na nie studentów oraz wstawiania im ocen, jak i z

zapisywaniem sie studentów na kursy, z ustalaniem planu roku akademickiego, czy z podsumo-

waniem semestrów. Równiez tutaj beda nas interesowały głównie dwa przypadki – wystawienie

koncowej oceny („Add final grade”) i podsumowanie semestru („Summarize semester”).

Rysunek 5.7 przedstawia scenariusz przypadku uzycia wystawienia koncowej oceny. Stan-

dardowo zaczyna sie on od wybrania przez uzytkownika odpowiedniego przycisku inicjujacego.

Wyswietlenie odpowiedniego ekranu umozliwiajacego wstawienie owej oceny uczniowi nastapi

jednak dopiero w kroku czwartym. Wynika to z tego, ze system bedzie równiez podawał na tym


RYSUNEK 5.7: Scenariusz przypadku uzycia „Add final grade”

ekranie informacje o sredniej wazonej z ocen ucznia, która musi byc wczesniej odpowiednio

obliczona. Oznacza to, ze drugim krokiem bedzie pobranie wszystkich ocen danego ucznia z da-

nego przedmiotu, co odzwierciedla odpowiednie zdanie „System to List View” o typie „Query”.

Teoretycznie przy troche innej konstrukcji zdania mógłby w tym miejscu wystepowac zwykły

typ akcji „Read”. Jako ze jednak składnia RSL nie umozliwia napisania pojedynczego zdania

reprezentujacego pobieranie danych w oparciu o wiecej niz jedno pojecie (dostepne jest tylko

jedno dopełnienie dalsze), posłuzono sie w celu realizacji takiej funkcjonalnosci prostym zapy-

taniem z wykorzystaniem silnika wnioskujacego, które nie bedzie szerzej omawiane. Zapytanie

to spowoduje pobranie listy ocen czastkowych na podstawie jedynych aktualnie dostepnych

danych, czyli przedmiotu i studenta, wystepujacych jako parametry.

Nastepnie wystepuje zdanie „System to Simple View” równiez o typie „Query”, reprezentu-

jace koniecznosc wyznaczenia wartosci sredniej wazonej, w sposób, który zostanie automatycz-

nie okreslony na podstawie wiedzy dziedzinowej. Podmiotem zapytania bedzie tu oczywiscie

pojecie „weighted average grade data”. Nalezy sie tez spodziewac, ze przy szukaniu rozwia-

zania wykorzystane zostana wczesniej pobrane oceny. W odróznieniu jednak od poprzednich

zaprezentowanych przypadków, tym razem typem podmiotu zapytania nie jest koncept. Wynika

to z faktu, ze otrzymane z niego dane beda pózniej przedstawione uzytkownikowi, a zatem mu-

simy odpowiednio zdefiniowac forme w jakiej to nastapi. W tym wypadku uzywamy pojecia


RYSUNEK 5.8: Model pojec przypadku uzycia „Add final grade”

o typie „Simple View”. Majac juz obliczona srednia, mozemy w koncu wyswietlic odpowied-

nie okno, co odzwierciedla zdanie „System to Screen” o typie „Show”. Nastepnie uzytkownik

wprowadza ocene koncowa i zatwierdza ja odpowiednim przyciskiem. Reprezentuja to odpo-

wiednio zdania „User to Simple View” i „User to Trigger” o typie „Select”. Na koniec system

zapisuje ocene, wyswietla potwierdzajacy to komunikat i zamyka okno wprowadzania oceny, co

daje nam kolejne trzy zdania – „System to Simple View” o typie „Create”, System to Message”

o typie „Show” i „System to Screen” o typie „Close”. Jako ze oceny nie wymagaja skompliko-

wanej walidacji, przypadek uzycia nie ma scenariuszy alternatywnych.

Model pojec dla omówionego przypadku uzycia przedstawiono na rysunku 5.8. Jest on bar-

dziej skomplikowany, niz dwa poprzednie, gdyz zawiera odniesienia do az trzech widoków

danych – danych o sredniej wazonej „weighted average grade data”, danych o ocenie koncowej

„final grade data” i listy ocen czastkowych „partial grades list”. Ekran „add final grade form”

słuzy zarówno do wyswietlenia sredniej wazonej ocen jak i do wprowadzania oceny koncowej.


RYSUNEK 5.9: Scenariusz przypadku uzycia „Summarize semester”

Odpowiedni przycisk („save final grade”) jest zwiazany z parametrem słuzacym do przeka-

zania dalej tej drugiej informacji. W modelu mamy takze pokazana liste ocen czastkowych,

która zostanie wykorzystana do wyliczenia poszukiwanej sredniej. Niestety, choc model ten

odzwierciedla powiazanie głównych konceptów dla wszystkich widoków danych z konceptami

przedmiotu i studenta, to nie umozliwia okreslenia konkretnej zaleznosci pomiedzy srednia wa-

zona, a ocenami czastkowymi. W modelu wystepuja tez pozostałe wystepujace w scenariuszu

pojecia – przycisk go rozpoczynajacy i wiadomosc wyswietlana na zakonczenie.

Scenariusz ostatniego z interesujacych nas przypadków uzycia jest przedstawiony na ry-

sunku 5.9. Pokazuje on proces podsumowania danego semestru, przez co nalezy rozumiec ak-

tualizacje statusu studentów na kolejny semestr w oparciu o ich dotychczasowe wyniki. Rozpo-

czyna sie on od wybrania odpowiedniego przycisku przez uzytkownika i pobrania przez system

listy studentów, czemu odpowiadaja zdania „User to Trigger” o typie „Select” i „System to

List View” o typie „Read”. Nastepnie wystepuje zdanie „System to List View” o typie „Qu-

ery” wskazujace miejsce, w którym znowu konieczne bedzie wygenerowanie rozwiazania na

podstawie wiedzy dziedzinowej. Nalezy tez sie spodziewac, ze przy realizacji tego celu zosta-

nie wykorzystana wczesniej pobrana lista studentów. Stanowi ona bowiem jedyne wystepujace

wczesniej w scenariuszu pojecie o typie dopuszczalnym dla danych wejsciowych. Po uzyskaniu

danych podsumowujacych semestr, wyswietlane jest prezentujace je okno – zdanie „System to

Screen” o typie „Show”. Nastepnie uzytkownik wybiera przycisk – zdanie „User to Trigger”


RYSUNEK 5.10: Model pojec przypadku uzycia „Summarize semester”

o typie „Select”, co powoduje zamkniecie poprzedniego okna – zdanie „System to Screen” o

typie „Close”. Na koniec nastepuje zapisanie danych podsumowania semestru, aktualizujac sta-

tusy studentów – zdanie „System to List View” o typie „Update”. Na koniec wyswietlana jest

odpowiednia wiadomosc o powodzeniu operacji, co reprezentuje zdanie „System to Message”

o typie „Show”.

Model pojec odpowiadajacy ostatniemu z omówionych przypadków uzycia jest przedsta-

wiony na rysunku 5.10. Tak jak poprzednio, mamy w nim przedstawione okno prezentujace

dane wraz z przyciskiem je zatwierdzajacym. Podobnie jak w poprzednim przypadku mamy tez

wiecej niz jeden widok danych – liste studentów („students list”) reprezentujaca ich aktualny

stan i tworzone na jej podstawie dane podsumowujace semestr odzwierciadlajace ich statusy w

kolejnym semestrze. Zaleznosc pomiedzy jednym a drugim pojeciem znów jest niemozliwa do

przedstawienia z pomoca standardowego modelu w jezyku RSL. Jak w poprzednich przypad-

kach, model zawiera tez pozostałe pojecia wystepujace w scenariuszu.

5.2. Rozszerzona specyfikacja dziedzinowa 143

RYSUNEK 5.11: Zapytania dla rozwazanych przypadków uzycia

5.2 Rozszerzona specyfikacja dziedzinowa

Po utworzeniu podstawowej specyfikacji w jezyku RLS, kolejnym etapem bedzie rozszerzenie

jej o szczegółowe modele opisujace wiedze dziedzinowa. W przedstawionych wczesniej czte-

rech przypadkach uzycia wystapiło kilka sytuacji, w których standardowe diagramy jezyka RSL

nie pozwalaja na przekazanie wszystkich informacji potrzebnych do wygenerowania funkcjo-

nalnego kodu. Dotyczy to potrzeby okreslania biezacego lub poprzedniego semestru, tworzenia

duplikatów przedmiotów na kolejny semestr, obliczania sredniej wazonej i okreslania statusu

studentów na nastepny semestr. Kazdy z tych przypadków bedzie rozwiazany przez wykonanie

odpowiedniego zapytania do modelu zawierajacego reprezentacje wiedzy dziedzinowej.

Rysunek 5.11 przedstawia po kolei zapytania dla kazdego z wymienionych przypadków, tak

jak reprezentowane sa one w narzedziu. Zapytania okreslaja, które z dopełnien w danym zdaniu

bedzie podmiotem zapytania, oraz dziedzine, w oparciu o która ma byc ono rozwiazywane. W

przedstawionym przykładach wystepowac beda tylko dziedziny „University” i „Average Gra-

des”. Zaleta powyzszych pieciu zapytan jest objecie przez nie czterech podstawowych sytuacji,

w których wczesniej zdefiniowane relacje dziedzinowe sa wykorzystywane przez silnik wnio-

skujacy. Udzielenie na nie odpowiedzi wymaga – miedzy innymi – wyszukiwania elementów w

oparciu o odniesienie, tworzenia nowych elementów w oparciu o przekształcenie, dokonywania

obliczen w oparciu o przekształcenie i modyfikowania elementów w oparciu o przekształcenie.

Warto zwrócic uwage to to, ze czesc pojec wystepujacych w rozszerzonej specyfikacji dziedzi-

nowej odpowiada pojeciom o takich samych nazwach wystepujacych w podstawowej specyfi-


RYSUNEK 5.12: Rozszerzony model dziedzinowy przedstawiajacy wiedze na te-mat lat akademickich i semestrów

kacji dziedzinowej jezyka RSL i stanowi ich uszczegółowienie. W szczególnosci, wystepujace

w zapytaniach podmioty musza byc reprezentowane w obu specyfikacjach.

Model pozwalajacy wykonac pierwsze dwa z wymienionych zapytan został przedstawiony

na rysunku 5.12. W pierwszej kolejnosci nalezy zwrócic uwage, ze definiuje on pojecia roku

akademickiego („academic year”), sezonu („season”) i semestru („semester”). Rok akademicki

reprezentowany jest przez byt o typie „identity”, posiadajacy przypisane jako atrybuty trzy wła-


sciwosci reprezentujace kolejno date rozpoczecia danego roku akademickiego, date zmiany se-

mestru zimowego na letni i date konca roku akademickiego. Sezon jest własciwoscia o typie

„identity”, reprezentujaca enumeracje. Choc nie widac tego bezposrednio na diagramie, dwie

dopuszczalne w jego wypadku wartosci to zima i lato. Semestr jest przedstawiony jako byt

o typie „identity” powiazany z dwoma własciwosciami, z których pierwsza reprezentuje rok

przedstawiony w postaci liczby, a druga jest specjalnym przypadkiem sezonu.

Dla semestru zostały zdefiniowane równiez trzy pomocnicze przekształcenia oparte o wzory.

Pierwsze dwa z nich pozwalaja na podstawie semestru uzyskac wartosci roku oraz sezonu, ja-

kie bedzie miał semestr go poprzedzajacy. Trzecie przekształcenie pozwala uzyskac juz bez-

posrednio – poprzedzajacy semestr na podstawie danego semestru. Wreszcie, w oparciu o wy-

mienione elementy i element podstawowy „CURRENT_DATE”, pozwalajacy uzyskac biezaca

date, okreslono relacje pozwalajace uzyskac interesujace nas informacje. Odniesienie oparte o

wzory „current academic year” pozwala sprawdzic, czy dany rok akademicki jest tym aktual-

nym, a wiec w praktyce – znalezc taki rok. Dodatkowo zdefiniowany jest tak samo nazwany byt

o typie „inferred_role”, który odnosi sie do roku akademickiego spełniajacego taka zaleznosc.

W modelu wystepuja równiez dwa kolejne przekształcenia oparte o wzory – „current semester”

i „previous semester”. Pierwsze z nich pozwala uzyskac biezacy semestr na podstawie daty i

biezacego roku akademickiego, a drugie – semestr poprzedni na podstawie biezacego seme-

stru. Wynikiem obydwu z nich sa byty o typie „inferred_role” pozwalajace na wygodniejsze

odnoszenie sie do uzyskanych elementów. Podobnie jak poprzednio, sa one nazwane tak samo

jak generujace je przekształcenia. Wystepujace na diagramie odniesienia oparte o wzory i prze-

kształcenia posiadaja tez zdefiniowane odpowiednie wzory. Poniewaz nie sa one widoczne w

tym przedstawieniu, beda podawane na biezaco przy omawianiu wygenerowanego kodu.

Fragment modelu powiazany z trzecim zapytaniem został przedstawiony na rysunku 5.13.

Mamy tu zdefiniowany byt szablonu kursu („course template”) o typie „identity”. Opisany on

jest przez trzy atrybuty reprezentujace kolejno typ kursu jako wartosc enumeracji, semestr kursu

jako liczbe całkowita i nazwe kursu jako napis. Mamy równiez zdefiniowany byt reprezentujacy

sam kurs w postaci bytu „course” o typie „identity”. Zwiazek pomiedzy kursami a szablonami

kursów jest zalezny od danych, co przedstawia odpowiednie odniesienie oparte o dane – „co-


RYSUNEK 5.13: Rozszerzony model dziedzinowy przedstawiajacy wiedze zwia-zana z uruchamianiem kolejnych edycji przedmiotów

urse based on template”. Atrybuty kursu reprezentuja odpowiednio liczbe dostepnych miejsc

w postaci liczby całkowitej i edycje kursu bedaca specjalnym przypadkiem własciwosci se-

mestr, przedstawionej przy okazji modelu powiazanego z poprzednimi zapytaniami. Kurs po-

siada takze trzeci atrybut reprezentujacy pełna nazwe kursu w formie napisu – „course full

name”, oznaczony jako „derived” i wyprowadzany za pomoca odpowiedniego przekształcenia

opartego o wzór. Przekształcenie to przyjmuje dane wejsciowe w postaci edycji kursu i nazwy

kursu przypisanej do powiazanego z nim szablonu kursu. Wreszcie, model zawiera równiez byt

„course repetition” o typie „inferred_role” reprezentujacy kolejna edycje kursu i dziedziczacy

z odpowiadajacego mu bytu „course”. Jest on oznaczony jako „derived” i do jego uzyskania

słuzy odpowiednie przekształcenie oparte o wzór „repeat course”.

Model potrzebny do rozwiazania czwartego zapytania prezentuje rysunek 5.14. Elementy

na nim zawarte naleza do dziedziny „Aveage Grades”. Definiuje on byt ocena („grade”) o typie

„identity”, powiazany z własciwoscia wartosc oceny („grade value”) w postaci liczby zmien-

noprzecinkowej. Definiuje on równiez kolejny byt ocena wazona („weighted grade”), który

dziedziczy z tego poprzedniego. Byt ten posiada równiez typ „identity” oraz jest dodatkowo

powiazany z własciwoscia waga oceny („grade weight”) reprezentowana przez liczbe całko-

wita. W oparciu o te elementy utworzone sa dwa przekształcenia oparte o wzory. Ich celem


RYSUNEK 5.14: Rozszerzony model dziedzinowy przedstawiajacy wiedze po-trzebna do obliczenia sredniej wazonej

jest wyznaczenie wazonej sumy ocen („weighted grades sum”) i sumy wag („weights sum”).

Pierwsza z nich przedstawiona jest za pomoca własciwosci reprezentujacej liczbe zmiennoprze-

cinkowa, a druga – własciwosci reprezentujaca liczbe całkowita. Choc nie przekłada sie to na

reprezentacje graficzna, obydwie te własciwosci sa równiez oznaczone jako „derived”. Ostat-

nie przekształcenie oparte o wzór wyznacza na podstawie tych własnosci kolejna własnosc

reprezentujaca srednia wazona („weighted average grade”) jako liczbe zmiennoprzecinkowa i

równiez oznaczona jako „derived”.

Przedstawiony model został dla przykładu zdefiniowany w bardziej ogólnej formie i nie

zawiera bezposredniego odniesienia do pojecia oceny czastkowej („partial grade”). Najprost-

szym jednak sposobem wykorzystania go do rozwiazania czwartego zapytania jest zdefiniowa-

nie tego pojecia jako bytu o typie „identity”, dziedziczacego z bytu „weighted grade”. Taka

definicja została przedstawiona na rysunku 5.15 wraz z odpowiednim odniesieniem opartym o

dane łaczacym pojecie oceny czastkowej z pojeciami studenta „student” i przedmiotu „course”.


RYSUNEK 5.15: Rozszerzony model dziedzinowy przedstawiajacy definicjeoceny czastkowej w oparciu o pojecie oceny wazonej

Fragment modelu pozwalajacy rozwiazac piate zapytanie został przedstawiony na rysunku

5.16. Mamy tutaj trzy główne byty o typie „identity” – student („student”), przedmiot („course”)

i ocena koncowa („final grade”). Odpowiednie odniesienia oparte o dane okreslaja powiaza-

nie pomiedzy studentami a przedmiotami, na które sa zapisani. Wiaza one takze kazda ocene

koncowa z przedmiotem i studentem. Dodatkowo, student jest opisywany poprzez własciwosci

reprezentujace jego status i numer semestru, przypisane do niego jako jego atrybuty. Opisane

elementy posiadaja oczywiscie znacznie wiekszy zakres opisujacych je cech, ale w przedsta-

wionym fragmencie pominieto wiekszosc z nich, niezwiazanych z rozwazanym zapytaniem.

W modelu mamy tez szereg innych kluczowych elementów. Pierwsza grupe z nich stano-

wia byty „summarized student”, „accepted student” i „failed student” o typie „inferred_role”.

Reprezentuja one ogólnie studenta, którego dane uległy zmianie w wyniku podsumowania se-

mestru, jak i dwa szczególne przypadki wystapienia takiej sytuacji: studenta, któremu udało sie

zdobyc rejestracje na nastepny semestr i studenta, któremu to sie nie udało. Druga grupe stano-

wia przekształcenia oparte o wzory „summarize student after semester”, „accept student” i „fail

student”, definiujace szczegóły zmian, którym student moze podlegac. Pozwalaja one wywiesc

dla studenta jeden z trzech wczesniej opisanych stanów. Kolejnym elementem jest odniesie-

nie oparte o wzory „student to accept”, okreslajace warunki, które musi spełniac student, zeby

zdobyc rejestracje na kolejny semestr. Jak mozna sie spodziewac, przekształcenie „summarize

student” ma forme prostego mapowania, które w zaleznosci od spełnienia warunków opisa-

nych w odniesieniu „student to accept” stosuje do studenta przekształcenia „accept student” lub

5.3. Kod logiki dziedzinowej 149

RYSUNEK 5.16: Fragment rozszerzonego model dziedzinowego powiazany zpodsumowywaniem semestru

„fail student”. Pierwsze z nich modyfikuje atrybut zwiazany z aktualnym semestrem studenta

na semestr kolejny, pozostawiajac mu status aktywnego. Drugie natomiast zmienia jego status

na odzwierciedlajacy brak rejestracji na kolejny semestr, a zostawia niezmienione oznaczenie

semestru. Wreszcie ostatnim ze wspomnianych kluczowych elementów jest własciwosc „seme-

ster summarization data”, reprezentujac zbiór elementów „summarized student”. Jej istnienie

pozwala ustalic, ze poszukujac bedacego podmiotem zdania pojecia „semester summarization

data” tak naprawde poszukujemy zbioru elementów „summarized student”.

5.3 Kod logiki dziedzinowej

Na podstawie przedstawionych modeli, dla poszczególnych zapytan został wygenerowany kod

realizujacy zwiazane z nimi funkcjonalnosci. Generacja kodu odpowia wczesniej przedstawio-


nym regułom, a jego ogólna struktura odpowiada tej zaprezentowanej w sekcji 4.1.1.

Pierwsze dwa z rozwazanych zapytan wymagaja znalezienia aktualnego lub poprzedniego

semestru w oparciu o dziedzine „University”. W obydwu wypadkach, do momentu wystapienia

w scenariuszu zdania powiazanego z zapytaniem nie wystepuja zadne pojecia majace przeło-

zenie na dziedzine: dane wejsciowe beda zatem puste. Przedstawiony dalej bedzie drugi z tych

przypadków, jako nieco bardziej złozony. Przypomnijmy, ze celem jest tutaj uzyskanie poprzed-

niego semestru („previous semester”) korzystajac z dziedziny „Universty” i bez dostepnych da-

nych wejsciowych. Silnik wnioskujacy, bazujac na modelu dziedzinowym, którego adekwatny

fragment przedstawiony był wczesniej na rysunku 5.12, zwróci nam ciag informacji mówiacy

o tym, ze:

• poprzedni semestr („previous semester”) moze byc uzyskany na podstawie przekształ-

cenia opartego o wzory, równiez nazwanego „previous semester”, pod warunkiem, ze

dysponujemy biezacym semesterem „current semester”,

• bierzacy semestr („current semester”) moze byc uzyskany na podstawie przekształcenia

opartego o wzory, równiez nazwanego „current semester”, jesli dysponujemy biezacym

rokiem akademickim „current academic year” (oraz biezaca data „CURRENT_DATE”,

która jako element podstawowy jest zawsze dostepna),

• biezacy rok akademicki („current academic year”) wskazuje na odpowiedni rok akade-

mickich („academic year”) poprzez odniesienie oparte o wzory „current academic year”

(znowu konieczne jest wykorzystanie zawsze dostepnej biezacej daty „CURRENT_DATE”).

Przedstawiony powyzej ciag wyprowadzen stanowi podstawe do wygenerowania kodu po-

zwalajacego okreslic poprzedni semestr. Zgodnie z reguła 11 z sekcji 4.1, bedzie on umiesz-

czony w pomocniczej klasie odpowiadajacej ostatniemu z uzyskiwanych elementów (na po-

wyzszej liscie wystepujacemu jako pierwszy). Kod tej klasy przedstawiony jest na rysunku

5.17. Generalny przebieg uzyskiwania informacji o biezacym semestrze znajduje sie w meto-

dzie „getPreviousSemester()”. Zawiera ona po kolei wystepujace wywołania metod zgodnie z

powyzsza sekwencja. Poszczególne klasy i metody w nich sie znajdujace musza oczywiscie

zostac wczesniej wygenerowane zgodnie z regułami (odpowiednio) 9, 14 oraz 15.


RYSUNEK 5.17: Kod wygenerowanej klasy MSPreviousSemester

W klasie „MSPreviousSemester” znajduje sie równiez kod wygenerowany dla ostatniego

wywołania z poprzednio omawianej metody. Powstał on na podstawie przekształcenia opar-

tego o wzór „previous semester”, o tresci „previous == precedingSemester(current)”. Zgod-

nie z reguła 15, jako ze wzór jest typu „simple”, za pomoca biblioteki symbolicznej jest z

niego wyprowadzany wzór dla wartosci „previous”. Daje to w wyniku wzór „precedingSeme-

ster(current)”. Zauwazmy nastepnie, ze w pojeciu „current semester” wskazywanym przez na-

zwe swego uczestnictwa, nie jest zdefiniowany atrybut nazwany „precedingSemester”. Taka

forme przyjmuje natomiast skrócona nazwa przekształcenia „preceding semester”. W rezulta-

cie, w kodzie znajdzie sie odwołanie do metody zwiazanej z ta relacja. Na koniec, w zwiazku

z tym, ze zwracana wartosc jest typu „inferred_role”, wynik opakowywany jest w odpowiednia

klase.

Kod ze wspomniana relacja „preceding semester” przedstawiony jest na rysunku 5.18. Sta-

nowi on prosta realizacje wzoru przekształcen o typie „indirect”, okreslajacego, ze poprzedni

semestr musi miec wartosci atrybutów wynikajacych z zawartych w modelu przekształcen

„other semester season” i „preceding semester year”. Zrealizowany jest on za pomoca metod

pozwalajacych uzyskac te wartosci w odpowiadajacych tym relacjom klasach pomocniczych.

Do jego generacji znowu posłuzyły nam zasady opisane w regule 15 – dla wzoru „indirect”

tworzony jest nowy obiekt w oparciu o wyprowadzone wartosci.

W omawianej na poczatku bardziej ogólnej metodzie znajduja sie równiez dwa inne wywo-

łania, wykorzystujace biezaca date do znalezienia biezacego roku akademickiego i wygenero-

wania na jego podstawie obiektu reprezentujacego biezacy semestr. Klasa zawierajaca metode


RYSUNEK 5.18: Kod wygenerowanej klasy MSPrecedingSemester

RYSUNEK 5.19: Kod wygenerowanej klasy MSCurrentAcademicYear

zwiazana z pierwszym z tych wywołan została przedstawiona na rysunku 5.19. Na samym po-

czatku, zgodnie z reguła 16 znajduje sie kod pobierajacy zbiór wszystkich lat akademickich.

Nastepnie, zgodnie z reguła 14 znajduje sie iteracja sprawdzajaca zwiazany z odniesieniem wa-

runek za pomoca osobnej metody. W wypadku jego spełnienia, aktualny element iteracji jest

zwracany po opakowaniu w odpowiednia klase. Jest to zwiazane z faktem, ze „current acade-

mic year” jest okreslone jako pojecie o typie „inferred_role”. Sama metoda sprawdzajaca wa-

runek zaczyna sie, zgodnie z reguła 16, od kodu okreslajacego biezaca date. Nastepnie, zgodnie

z reguła 13 znajduje sie kod sprawdzajacy warunek: „beginingDate(currentYear) < date &&

endDate(currentYear) > date”. Poszczególne elementy wskazywane sa przez nazwy ich uczest-

nictw, a nazwy przed nawiasami odpowiadaja nazwom atrybutów pojecia „academic year”.

Konieczna była tez zmiana reprezentacji sprawdzenia mniejszosci i wiekszosci na własciwa dla

dat.

Przedstawione powyzej klasy powinny oczywiscie zawierac wiecej metod, zwłaszcza ze ze

wzgledu na takie same nazwy powiazanych pojec i relacji beda one miały wspólne klasy po-


mocnicze z przedrostkiem „MS”. Ze wzgledu na czytelnosc wiekszosc nadmiarowych metod

została jednak w powyzszym przedstawieniu pominieta, a klasy pokazane tak, jakby zostały

wygenerowane tylko na podstawie relacji. Podobne podejscie bedzie tez stosowane przy oma-

wianiu kodu dla kolejnych zapytan.

Nastepne, czyli trzecie z omawianych zapytan dotyczy uzyskiwania powtórzen kursów w

postaci listy („course repetitions list”) na nastepny semestr. Znowu operujemy w dziedzinie

„University”, natomiast tym razem dysponujemy wybranym przez uzytkownika zbiorem kur-

sów („set of curses”) oraz oczywiscie lista wszystkich kursów z poprzedniego semestru („list

of courses”) i poprzednim semestrem („previous semester”). Po uruchomieniu silnika wniosku-

jacego okaze sie, ze realizacja tego zadania bazuje na pojedynczym przekształceniu opartym o

wzór „repeat course”, przedstawionym we fragmencie modelu na rysunku 5.13. Choc dotyczy

ono przekształcenia pojedynczej pary elementów, zgodnie z wczesniejszym opisem z sekcji 4.2,

silnik wnioskujacy uwzglednia równiez mozliwosc grupowego jego zastosowania.

Klasa zawierajaca kod wygenerowany na podstawie powyzszego zapytania została przed-

stawiona na rysunku 5.20. Jako ze wykorzystana została tylko pojedyncza reguła, w odpowiedzi

na zapytanie zwrócona bedzie metoda bezposrednio ja realizujaca. Nie wymaga to konieczno-

sci tworzenia metody realizujacej potrzebna sekwencje wywołan. Wspomniane przekształcenie

zawiera wzór typu „indirect” o tresci „courseEdition(courseRepetition) == nextSemester (cour-

seEdition(course)); coursePlacesLimit(courseRepetition) == coursePlacesLimit(course); tem-

plate(courseRepetition) == template(course)” i bez okreslonego podmiotu. Zgodnie z reguła

15, kod wykonujacy przekształcenie dla pojedynczego elementu w oparciu o ten typ wzorów

rozpoczyna sie od stworzenia nowego obiektu odpowiadajacego szukanemu pojeciu. Nastep-

nie, pierwsza czesc wzoru zamieniona zostaje na kod realizujacy pobranie wartosci atrybutu i

przypisanie jej do atrybutu stworzonego obiektu. Wynika to z tego, ze nazwa wystepujaca przed

obydwoma nawiasami odpowiada owym atrybutom.

Przetłumaczenie na kod drugiej czesci wzoru zostało wykonane analogicznie. Dodatkowo,

przed przypisaniem wartosci do atrybutu szukanego pojecia („setCourseEdition”), wywołano

dla niej metode „getNext()”, realizujaca przekształcenie oparte o wzór „next semester” (patrz

rysunek 5.12). Dotyczy to tresci wzoru, który zawiera odniesienie do pojecia za pomoca jego


RYSUNEK 5.20: Kod wygenerowanej klasy MSRepeatCourse

skróconej nazwy. Kod metody jest mocno zblizony do omówionego wczesniej kodu dla prze-

kształcenia „preceding semester”, jako ze realizuje odwrotna do niego funkcjonalnosc. W zwiazku

z tym nie bedziemy tutaj szczegółowo go omawiac.

Trzecia czesc wzoru opiera sie na wykorzystaniu powiazania dereferencyjnego „template”,

przypisanego do pojecia kursu. Wskazywane przez to powiazanie odniesienie oparte o dane

„course based on template” (patrz rysunek 5.13), wiaze ze soba tylko dwa pojecia. Nie jest

ono zatem reprezentowane w kodzie jako osobna klasa. Informacje o nim przechowywane sa

wprost w jego uczestnikach. W zwiazku z tym, realizacja ostatniej czesci wzoru równiez polega

na wywołaniu odpowiednich metod dostepowych, tak jak w dwóch poprzednich przypadkach.

Na koniec, wynik jest opakowany w odpowiednia klase reprezentujaca pojecie o typie „infer-

red_role”. Zaprezentowana klasa zawiera równiez kod wykonujacy rozwazane przekształcenie

dla zbioru elementów, co odbywa sie poprzez wywołanie w petli omówionej metody dla wszyst-

kich elementów zbioru i zebranie jej wyników jako nowego zbioru.

Klasa MSRepeatCourse wykorzystuje interfejs „IMCourse” oraz implementujaca go klase

„MCourse”. Klasa ta jest dobrym przykładem klasy typu „M” i została wygenerowana na pod-

stawie reguły 1. Reprezentatywny fragment jej kodu jest przedstawiony na rysunku 5.21. Atry-

buty „coursePlacesLimit” oraz „courseEdition”, a takze odpowiadajace im metody dostepowe

(„get” i „set”) zostały wygenerowane na podstawie reguły 4, a konstruktor – na podstawie re-

guły 5. Szczególnym przypadkiem jest metoda dostepowa dla atrybutu „course full name” po-


RYSUNEK 5.21: Kod wygenerowanej klasy MCourse

jecia „course”. Wynika to z tego, ze atrybut ten w modelu dziedzinowym jest oznaczony jako

„derived”. W zwiazku z tym, nalezy tutaj zastosowac regułe 12, która wymaga rozwiazania

odpowiedniego zapytania. Przedmiotem zapytania jest szukany atrybut, a danymi bazowymi –

pojecie „course”. Na tej podstawie, silnik wnioskujacy okresla, ze rozwiazanie zapytania po-

wstanie przez zastosowanie przekształcenia „course full name” (patrz rys. 5.13). Wynikowy kod

metody powstaje poprzez zastosowanie reguły 11 (b) do tego przekształcenia.

Czwarte z przedstawionych zapytan zwiazane jest z wyliczaniem sredniej wazonej („we-

ighted average grade”) na podstawie ocen danego studenta. Tym razem, dziedzina, w oparciu o

która bedziemy rozwiazywali zapytanie bedzie „Average Grades”. Jako dane wyjsciowe moga

posłuzyc nam lista ocen czastkowych („partial grades list”), student („student”) i przedmiot

(„course”). Po uruchomieniu, silnik wnioskujacy, bazujac na fragmentach przedstawionych na

rysunkach 5.14 i 5.15 okresli nam, ze:

• srednia wazona („weighted average grade”) moze byc wyprowadzona na podstawie prze-

kształcenia „weighted average grade computation” z sumy wazonej ocen („weighted gra-


des sum”) i sumy wag („weights sum”),

• suma wazona ocen („weighted grades sum”) jest mozliwa do uzyskania na podstawie

przekształcenia „weighted grades summation” ze zbioru wazonych ocen („weighted gra-

des”),

• suma wag („weights sum”) jest mozliwa do uzyskania na podstawie przekształcenia „we-

ights summation” równiez ze zbioru wazonych ocen („weighted grades”),

• jako zbiór ocen wazonych („weighted grades”) moze zostac potraktowany zbiór ocen

czastkowych („partial grades”), jako ze drugie z tych pojec stanowi szczególny przypadek

pierwszego.

Warto zauwazyc, ze znalezienie rozwiazania jest mozliwe, mimo tego, ze zadne z danych

wejsciowych nie znajduja sie w rozpatrywanej dziedzinie. Sa one jednak z nia bezposrednio

powiazane. Silnik wnioskujacy mógłby takze bez problemu znalezc zaleznosc pomiedzy przed-

miotem i studentem, a ocenami czastkowymi. Potrzebowałby jednak dostepu do całej dzie-

dziny „University”. W celu pokazania w przykładzie zapytania ograniczonego do konkretnej

dziedziny, lista ocen czastkowych została wiec pobrana w poprzedzajacym zapytanie zdaniu

znajdujacym sie w scenariuszu.

W oparciu o przedstawiony ciag wyprowadzen został wygenerowany kod przedstawiony

na rysunku 5.22. Prezentowana klasa zawiera dwie metody „getWeightedAverageGrade” róz-

niace sie parametrami. Pierwsza z nich stanowi realizacje ostatniego kroku bedacego oparta o

regułe 15 prosta implementacja wzoru przekształcen „weightedAverageGrade == weightedGra-

desSum/weightSum” o typie „simple”. Druga z nich zawiera realizacje kroków z przedstawio-

nej sekwencji w oparciu o regułe 11.

Sekwencja z drugiej metody zawiera na koncu wywołanie pierwszej metody. Zawiera takze

proste rzutowanie oraz dwa nastepne wywołania metod, powstałych na podstawie kolejnych

przekształcen opartych o wzór i działajacych na zblizonej zasadzie. Zawartosc pierwszego z

nich, jako bardziej skomplikowanego, została przedstawiona na rysunku 5.23. Stanowi ona re-

alizacje wzoru przekształcen typu „summation” o tresci „gradeValue($)*gradeWeight($)” dla


RYSUNEK 5.22: Kod wygenerowanej klasy MSWeightedAverageGradeCompu-tation

RYSUNEK 5.23: Kod wygenerowanej klasy MSWeightedGradesSummation

elementu „subjectLink” typu „weightedGrade”. Jako ze obydwie nazwy wystepujace przed na-

wiasami odpowiadaja atrybutom wspomnianego pojecia, zostały zamienione na pobrania ich

wartosci. Sama metoda natomiast zgodnie z reguła 15 opiera sie o odpowiednia petle „for-

each”.

Ostatnie z przykładowych zapytan dotyczy przygotowywania danych podsumowujacych se-

mestr („semester summarization data”), czyli w praktyce – okreslania statusów poszczególnych

studentów po zakonczeniu semestru. Wrócilismy z powrotem do dziedziny „University”, na-

tomiast w ramach danych wejsciowych dysponujemy tylko lista studentów („students list”).

Tak samo, jak w drugim z omawianych przypadków, po wykorzystaniu silnika wnioskujacego

okaze sie, ze do okreslenia odpowiedzi dla tego zapytania bezposrednio potrzebne jest nam

tylko pojedyncze przekształcenie, oparte o wzór „summarize student after semester”. Musimy

jednak zastosowac wywołania dla całego zbioru studentów. Przekształcenie zdefiniowane jest

w oparciu o wzór przekształcen o typie „mapping”, o tresci „studentToAccept(student); accept-

Student(student); failStudent(student)”. Klasa zawierajaca kod odpowiadajaca temu wzorowi


RYSUNEK 5.24: Kod wygenerowanej klasy MSSummarizeStudentAfterSemester

RYSUNEK 5.25: Kod wygenerowanej klasy MSStudentToAccept

przedstawiona jest na rysunku 5.24. Zgodnie z reguła 15, w wypadku spełnienia warunku okre-

slonego przez pierwsza czesc wzoru, zwracana jest wartosc wynikajaca z jego drugiej czesci.

Natomiast w przeciwnym wypadku, zwracana jest ta wynikajaca z ostatniej jego czesci. W

obydwu wypadkach konieczne jest tez opakowanie wyniku w odpowiednia klase, ze wzgledu

na typ „inferred_role” pojecia reprezentujacego wynik. Jako ze jednak kazda z wspomnianych

czesci wzoru odpowiada wywołaniom kolejnych metod, zostana one dalej omówione bardziej

szczegółowo.

Klasa zawierajaca metode wywołana w pierwszej czesci poprzedniego wzoru została przed-

stawiona na rysunku 5.25. Metoda ta powstała na podstawie odniesienia opartego o wzór „stu-

dent to accept”, opisanego wzorem o typie „universal quantification” i tresci „gradeValue($)>=3”.


RYSUNEK 5.26: Kod wygenerowanej klasy MSAcceptStudent

Posiada ona równiez podmiot wzoru okreslony za pomoca powiazania dereferencyjnego o tresci

„finalGrading(student)”, pozwalajacy za pomoca relacji opartej o dane „final grading” pobrac

oceny koncowe studenta. Zgodnie z reguła 13, realizacja metody oparta jest o iteracje przebie-

gajaca po elementach wskazanych przez podmiot wzoru, czyli po ocenach. Zgodnie ze wzorem,

sprawdza ona, czy zadna z ocen nie jest mniejsza niz 3. Przedstawiona klasa zawiera równiez

metode powstała na podstawie reguły 14, pobierajaca wszystkie elementy spełniajace wspo-

mniany wzór. Nie bedzie nam jednak ona potrzebna przy okreslaniu odpowiedzi do biezacego

zapytania.

Metody wywołane w drugiej i trzeciej czesci poprzedniego wzoru sa do siebie mocno zbli-

zone, a zatem zostanie omówiona tylko pierwsza z nich. Klasa ja zawierajaca została przed-

stawiona na rysunku 5.26. Powstała ona na podstawie przekształcenia opartego o wzór „accept

student”, opisanego wzorem o typie „indirect” i tresci „studentSemester(acceptedStudent) ==

studentSemester(student)+1;studentStatus(acceptedStudent) == active”. Wzór ten jako podmiot

ma ustawione uczestnictwo o nazwie „student”. W zwiazku z tym, zgodnie z reguła 15 bedzie

odpowiadał modyfikacji istniejacego obiektu, a nie tworzeniu nowego. Kod metody zawiera

zatem jedynie modyfikacje wartosci odpowiednich atrybutów klasy odpowiadajacej pojeciu

studenta. Dodatkowo opakowuje on wynik w odpowiednia klase ze wzgledu na typ pojecia

reprezentujacego wynik („inferred_role”). Konieczne jest jednak ustalenie przez mechanizm

transformujacy, ze nazwa „active” odpowiada mozliwej wartosci typu wyliczeniowego opisuja-

cego jeden z atrybutów, a nie jest to odniesienie do jednego z uczestnictw w relacji.

161

Rozdział 6

Podsumowanie i wnioski

W ramach pracy został zaprojektowany jezyk umozliwiajacy specyfikowanie wiedzy dziedzi-

nowej na poziomie konceptualnym. Zaprojektowano równiez transformacje pozwalajaca gene-

rowac na podstawie modeli w tym jezyku kod dziedzinowy oraz opracowano jej przykładowa

implementacje. Jezyk i transformacja zostały opracowane tak, ze konkretna wiedza dziedzinowa

okreslana jest niezaleznie od kontekstu, w którym bedzie wykorzystywana. Pozwala to zmniej-

szyc ilosc wprowadzanych informacji, jako ze uzytkownik definiuje tylko same reguły opisujace

mechanizmy rzadzace dana dziedzin. Nie musi on natomiast okreslac konkretnego sposobu, w

jaki te informacje beda wykorzystywane. Pozwala to na pominiecie szczegółowego opisywania

przebiegu niektórych, czasem skomplikowanych algorytmów, których dokładny przebieg zo-

stanie pózniej okreslony przez maszyne wnioskujaca. Ta sama cecha sprawia równiez, ze raz

utworzona specyfikacja dziedzinowa, moze byc łatwiej wykorzystana w kolejnych projektach.

Zwiazane to jest z faktem, ze wymagane jest do tego celu jedynie pokrywanie sie opisanego

zakresu dziedziny, natomiast konkretne przeprowadzane na niej operacje moga sie róznic z pro-

jektu na projekt.

W ramach studium przypadku stworzono specyfikacje dziedzinowa dla nietrywialnej dzie-

dziny, zgodna z zaprojektowanym podejsciem. Specyfikacja ta jest kompatybilna ze specyfika-

cja wymagan w jezyku RSL, pozwalajac na zdefiniowanie dodatkowych informacji o dziedzi-

nie, których mozliwosci okreslenia brakowało w tej drugiej. Na podstawie specyfikacji został

wygenerowany funkcjonalny kod. System ReDSeeDS generujac kod w architekturze trójwar-

stwowej, przed rozszerzeniem generował tylko kod zawarty w dwóch górnych warstwach –

interfejsu uzytkownika i logiki aplikacji. Zdefiniowany był wiec kod odzwierciedlajacy wy-

162 Rozdział 6. Podsumowanie i wnioski

glad i zachowanie graficznego interfejsu uzytkownika oraz okreslajacy sekwencje jego uzycia

na potrzeby dazenia do konkretnych celów. Same metody wykonujace konkretne operacje na

danych, przynalezne do ostatniej warstwy pozostawały jednak puste. Wygenerowany ze specy-

fikacji dziedzinowej kod realizuje własnie te operacje przypisane do warstwy modelu. Stanowi

on zatem istotne uzupełnienie dla wczesniejszego rozwiazania. Co prawda, zawartosc metod

operujacych na bazie danych nie jest w aktualnej implementacji transformacji generowana, ale

tego typu rozwiazania dla systemu ReDSeeDS juz istnieja [46]. Jednym z kolejnych zadan na

przyszłosc powinna byc wiec miedzy innymi ich integracja z opracowana transformacja.

Poniewaz kod generowany jest automatycznie, a objetosc informacji koniecznych do de-

finiowania wiedzy dziedzinowej jest mniejsza niz objetosc wygenerowanego kodu, mozna sie

spodziewac, ze zastosowanie zaprezentowanego podejscia powinno pozwolic na usprawnienie

procesu tworzenia oprogramowania. Rozwazajac sposób zmierzenia korzysci wynikłych z jego

zastosowania, mozemy nieformalnie jako metryke potraktowac stosunek ilosci konstrukcji w

wygenerowanym kodzie do ilosci elementów w opracowanym jezyku, na podstawie których on

powstał. W ramach przykładu mozemy przeprowadzic takie obliczenia dla fragmentu modelu

dziedzinowego, który posłuzył do rozwiazania czwartego z zapytan przedstawionych w sek-

cji 5.2. Zapytanie to definiuje koniecznosc okreslenia „weighted average grade” w oparciu o

dziedzine „Average grades”. Interesujacy nas fragment modelu zawiera 22 elementy: 3 relacje,

7 pojec, 7 uczestnictw w relacji, 2 przypisania atrybutów i 3 wzory. Natomiast na jego pod-

stawie powstał kod, w którym mozemy wyróznic 35 konstrukcji: 5 klas, 2 pola, 4 metody, 2

konstruktory, 4 metody dostepowe, 2 petle i 16 innych wierszy kodu, zawierajacych wywoła-

nia lub przypisania. Daje nam to zysk w postaci zmniejszenia liczby elementów potrzebnych

do opisania problemu o około 1/3. Nalezy jednak zwrócic uwage, ze przy wykorzystaniu raz

utworzonej specyfikacji w kolejnych projektach, uzyskamy znowu zblizona ilosc nowych ele-

mentów. Jest to kosztem zaledwie pojedynczego nowego zapytania. Współczynnik ten ulegnie

w takim przypadku znaczacej poprawie.

Oczywiscie, kwestia pełnego wpływu opracowanego rozwiazania na efektywnosc wytwa-

rzania oprogramowania jest znacznie bardziej złozona i obejmuje wiele kwestii wychodzacych

poza zakres tej pracy. Dotyczy to przykładowo takich kwestii, jak łatwosc nauki powstałego

Rozdział 6. Podsumowanie i wnioski 163

jezyka, czy ocena sprawnosci posługiwania sie nim przez ewentualnych przyszłych uzytkow-

ników. Ocena takich aspektów powinna byc przedmiotem przyszłych dociekan, poprzez prze-

prowadzanie odpowiednich eksperymentów badajacych te cechy. Nalezy zatem zauwazyc, ze

niniejsza praca nie zawiera formalnego czy pełnego eksperymentalnego dowodu prawdziwosci

hipotezy badawczej przedstawionej w sekcji 1.1. Przeprowadzona implementacja jezyka RSL-

DL i generatora kodu oraz wykonane studium przypadku stanowia jednak istotna przesłanke

wskazujaca, ze mozna w istotny sposób poprawic efektywnosci procesu wytwarzania oprogra-

mowania przy uzyciu zaprezentowanego podejscia.

Przedstawiony jezyk stwarza wiele okazji do jego dalszego udoskonalania. Wskazane jest

przeprowadzenie dalszych studiów przypadku w celu okreslenia mozliwych obszarów rozwoju

jezyka RSL-DL. W szczególnosci, ciekawe byłoby uzyskanie wyników dotyczacych róznych

dziedzin zastosowan przy udziale ekspertów dziedzinowych. W tym samym celu mozna by

przeprowadzic porównanie jezyka z popularnymi jezykami specyficznymi dla dziedziny (ang.

Domain Specific Language – DSL) [67, 32, 49]. Jezyki te wychodza – do pewnego stopnia –

z podobnego załozenia, jak jezyk RSL-DL. Staraja sie one przedstawiac problemy w sposób

jak najbardziej zblizony do sposobu, w jaki mysla o nich ludzie. Natomiast, w odróznienia od

opracowanego jezyka, kazdy z nich powiazany jest z konkretna dziedzina. Umozliwia to sto-

sowanie wyspecjalizowanych konstrukcji dziedzinowych. Nie nalezy oczywiscie oczekiwac, ze

stworzone rozwiazanie bedzie mogło konkurowac z takimi jezykami w obszarach ich specjali-

zacji w kwestii efektywnosci. Moze natomiast okazac sie, ze niektóre z zastosowanych w nich

rozwiazan beda na tyle uniwersalne, ze moga posłuzyc jako wzór przy dalszym rozwoju. Cie-

kawym pomysłem byłaby tez próba zaimplementowania automatycznego mapowania owych

jezyków z grupy DLS na konstrukcje stworzonego jezyka.

Kolejna warta poruszenia kwestia jest fakt, ze wygenerowany kod nalezałoby poddac istot-

nej optymalizacji. Aktualna transformacja stanowi bezposrednia implementacje opisanych w

sekcji 4.1 reguł. Swoja struktura odpowiada strukturze wystepujacych w specyfikacji pojec.

Prowadzi to czasami do powstawania nadmiarowych metod lub klas. Mozna sie spodziewac, ze

tego typu niedociagniecia zostana zoptymalizowane przez kompilator docelowego jezyka. Nie-

mniej jednak, optymalizacja na etapie generacji mogłaby zwiekszyc przejrzystosc powstałego

164 Rozdział 6. Podsumowanie i wnioski

kodu. Wreszcie, w jezyku zaprojektowano nietypowe mechanizmy pozwalajace na dynamiczne

zmiany pełnionych ról. Pozwalaja one w razie potrzeby na odzwierciedlanie takich zmian jak

np. dodanie konkretnej osobie roli studenta w momencie rozpoczecia nauki na wyzszej uczelni

i reprezentowane sa przez pojecia o typie „assigned role”. Mechanizm ten nie został dokładniej

przetestowany i własciwie nie wystepuje w studium przypadku, w zwiazku z czym powinien

byc podany dalszym badaniom.

Warto równiez zauwazyc, ze opracowane rozwiazanie przy okazji adresuje niektóre ze spe-

cyficznych niedociagniec dotyczacych sposobu generacji kodu przez system ReDSeeDS. Istot-

nym zagadnieniem w wypadku generowania kodu ze specyfikacji wymagan, jest kwestia wpro-

wadzenia do niego zmian, w wypadku kiedy specyfikacja ulegnie zmianie. Typowym podej-

sciem stosowanym w przypadku systemu ReDSeeDS jest ponowna generacja kodu w opar-

ciu o uaktualniona specyfikacje. Jesli jednak kod został recznie uzupełniony, wszelkie zmiany

nalezy recznie przeniesc pomiedzy poszczególnymi wersjami kodu. Jedynym usprawnieniem,

które wprowadza w tej kwestii system ReDSeeDS jest mozliwosc sledzenia, na które fragmenty

kodu wpłyna poszczególne zmiany w specyfikacji. Stworzone rozszerzenie pozwala rozwiazac

ten problem dla warstwy modelu. Kod moze zostac wygenerowany automatycznie, co zmniej-

sza potrzebe jego recznego uzupełniania. Dodatkowo, nawet jesli zajdzie taka potrzeba, frag-

menty recznie napisanego kodu moga zostac opakowane w przekształcenia oparte o wzór o

typie wzoru „evocation”. Sprawi to, ze podczas generacji, automatycznie zostana one umiesz-

czone w odpowiednich miejscach.

165

Bibliografia

[1] Albert Ambroziewicz i Michał Smiałek. „Application Logic Patterns – Reusable Ele-

ments of User-System Interaction”. W: Lecture Notes in Computer Science 6394 (2010),

s. 241–255.

[2] Jürgen Angele, Michael Kifer i Georg Lausen. „Ontologies in F-logic”. W: Handbook

on Ontologies. Red. Steffen Staab i Rudi Studer. Springer Berlin Heidelberg, 2009,

s. 45–70.

[3] Franz Baader i in. The description logic handbook: Theory, implementation and appli-

cations. Cambridge University Press, 2003.

[4] Frederic Charles Bartlett i Cyril Burt. „Remembering: A study in experimental and

social psychology”. W: British Journal of Educational Psychology 3.2 (1933), s. 187–

192.

[5] Sean Bechhofer. „OWL: Web Ontology Language”. W: Encyclopedia of Database Sys-

tems. Red. Ling Liu i M. Tamer Özsu. Springer, 2009, s. 2008–2009.

[6] Kent Beck i in. The agile manifesto. http://agilemanifesto.org. 2001.

[7] Brian Berenbach. „A 25 year retrospective on model-driven requirements engineering”.

W: Model-Driven Requirements Engineering Workshop (MoDRE), 2012 IEEE. 2012,

s. 87–91.

[8] Tim Berners-Lee, James Hendler i Ora Lassila. „The semantic web”. W: Scientific ame-

rican 284.5 (2001), s. 34–43.

[9] Ronald J Brachman i James G Schmolze. „An Overview of the KL-ONE Knowledge

Representation System”. W: Readings in Artificial Intelligence and Databases. Else-

vier, 1988, s. 207–230.

http://agilemanifesto.org

166 Bibliografia

[10] Max Bramer. Logic Programming with Prolog. Springer London, 2013.

[11] Tim Bray i in. „Extensible Markup Language (XML) 1.0 (Fifth Edition)”. W: World

Wide Web Consortium (W3C) Recommendation (2008).

[12] Frederick P Brooks. No Silver Bullet: Essence and Accidents of Software Engineering.

T. 20. 4. 1987, s. 10–19.

[13] Lan Cao i Balasubramaniam Ramesh. „Agile Requirements Engineering Practices: An

Empirical Study”. W: IEEE Software 25.1 (2008), s. 60–67.

[14] Noam Chomsky. „Three models for the description of language”. W: IRE Transactions

on Information Theory 2.3 (1956), s. 113–124.

[15] Alistair Cockburn. Agile software development. Addison-Wesley Boston, 2002.

[16] Alistair Cockburn. „Structuring Use Cases with Goals”. W: Journal of Object-Oriented

Programming 10.5 (1997), s. 56–62.

[17] A Colmeraner i in. Un systeme de communication homme-machine en francais. Spraw.

tech. Universitè d’Aix-Marseille, 1973.

[18] Eclipse Consortium i in. Eclipse website. http://www.eclipse.org/.

[19] Oscar Corcho, Mariano Fernández-López i Asunción Gómez-Pérez. „Methodologies,

tools and languages for building ontologies. Where is their meeting point?” W: Data &

Knowledge Engineering 46.1 (2003), s. 41–64.

[20] Oscar Corcho i Asunción Gómez-Pérez. „Evaluating Knowledge Representation and

Reasoning Capabilites of Ontology Specification Languages”. W: Proceedings of the

ECAI’00 Workshop on Applications of Ontologies and Problem Solving Methods. 2000.

[21] Stephen Cranefield i Martin Kent Purvis. UML as an ontology modelling language.

Information Science Discussion Papers Series 99/01. University of Otago, 1999.

[22] Nancy Cunniff i Robert P Taylor. „Graphical vs. Textual Representation: An Empirical

Study of Novices’ Program Comprehension”. W: Empirical studies of programmers:

Second workshop. 1987.

http://www.eclipse.org/

Bibliografia 167

[23] Alan Davis i in. „Identifying and measuring quality in a software requirements specifi-

cation”. W: [1993] Proceedings First International Software Metrics Symposium. 1993,

s. 141–152.

[24] Dragan Djuric i in. „A UML Profile for OWL Ontologies”. W: Model Driven Architec-

ture. Red. Uwe Aßmann, Mehmet Aksit i Arend Rensink. Springer Berlin Heidelberg,

2005, s. 204–219.

[25] Martin Dürst i Michel Suignard. Internationalized resource identifiers (IRIs). RFC 3987.

2005.

[26] Eclipse Modeling Project. http://www.eclipse.org/modeling/emf/.

[27] Enterprise Architect website. http://sparxsystems.com/products/ea/.

[28] Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software.

Addison-Wesley, 2004.

[29] Adam Farquhar, Richard Fikes i James Rice. „The Ontolingua Server: a tool for colla-

borative ontology construction”. W: International Journal of Human-Computer Studies

46.6 (1997), s. 707–727.

[30] Edward Feigenbaum, Pamela McCorduck i H Penny Nii. The rise of the expert com-

pany. Times Books, 1988.

[31] Christina Feilmayr i Wolfram Wöß. „An analysis of ontologies and their success factors

for application to business”. W: Data & Knowledge Engineering 101 (2016), s. 1–23.

[32] Martin Fowler. Domain-specific languages. Addison-Wesley Professional, 2010.

[33] Michael Gelfond. „Representing knowledge in A-Prolog”. W: Computational Logic:

Logic Programming and Beyond: Essays in Honour of Robert A. Kowalski Part II. Red.

Antonis C. Kakas i Fariba Sadri. Springer Berlin Heidelberg, 2002, s. 413–451.

[34] Michael Gelfond i Nicola Leone. „Logic programming and knowledge representation -

the A-Prolog perspective”. W: Artificial Intelligence 138.1-2 (2002), s. 3–38.

http://www.eclipse.org/modeling/emf/

http://sparxsystems.com/products/ea/

168 Bibliografia

[35] Michael R Genesereth, Richard E Fikes i in. Knowledge interchange format-version 3.0:

reference manual. Computer Science Department, Stanford University San Francisco,

CA, 1992.

[36] Graphical Modeling Project. http://www.eclipse.org/modeling/gmp/.

[37] Thomas R Gruber. „A translation approach to portable ontology specifications”. W:

Knowledge Acquisition 5.2 (1993), s. 199–220.

[38] Thomas R Gruber. „Toward principles for the design of ontologies used for knowledge

sharing?” W: International Journal of Human-Computer Studies 43.5-6 (1995), s. 907–

928.

[39] Jeff Heflin i James Hendler. „A portrait of the Semantic Web in action”. W: IEEE Intel-

ligent Systems 16.2 (2001), s. 54–59.

[40] Pascal Hitzler i in. „OWL 2 Web Ontology Language Primer”. W: World Wide Web

Consortium (W3C) Recommendation (2012).

[41] Alfred Horn. „On sentences which are true of direct unions of algebras”. W: The Journal

of Symbolic Logic 16.1 (1951), s. 14–21.

[42] Integranova website. http://www.integranova.com.

[43] Steffen Kahle. „JGraLab: Konzeption, Entwurf und Implementierung einer Java-Klas-

senbibliothek für TGraphen”. Prac. mag. The University of Koblenz-Landau, 2006.

[44] Hermann Kaindl i in. Requirements Specification Language Definition. Project Delive-

rable D2.4.2. ReDSeeDS Project, 2009.

[45] Audris Kalnins, Janis Barzdins i Edgars Celms. „Model Transformation Language MO-

LA”. W: Lecture Notes in Computer Science 3599 (2004), s. 62–76.

[46] Nassima Yamouni Khelifi, Michał Smiałek i Rachida Mekki. „Generating database ac-

cess code from domain models”. W: 2015 Federated Conference on Computer Science

and Information Systems (FedCSIS). 2015, s. 991–996.

[47] Michael Kifer i Georg Lausen. „F-logic: A Higher-order Language for Reasoning About

Objects, Inheritance, and Scheme”. W: t. 18. 2. ACM, 1989, s. 134–146.

http://www.eclipse.org/modeling/gmp/

http://www.integranova.com

Bibliografia 169

[48] Michael Kifer, Georg Lausen i James Wu. „Logical Foundations of Object-oriented and

Frame-based Languages”. W: J. ACM 42.4 (1995), s. 741–843.

[49] Anneke Kleppe. Software Language Engineering: Creating Domain-Specific Langu-

ages Using Metamodels. 1 wyd. Addison-Wesley Professional, 2008.

[50] Graham Klyne i Jeremy J Carroll. „Resource Description Framework (RDF): Concepts

and Abstract Syntax”. W: World Wide Web Consortium (W3C) Recommendation (2004).

[51] Axel Kramer. Symja library-Java symbolic math system. 2010–2018.

[52] Thomas Kühne. „"Matters of (Meta-) Modeling”. W: Software & Systems Modeling 5.4

(2006), s. 369–385.

[53] Dave Lambert i Enrico Motta. Operational Concept Modeling Language. Spraw. tech.

2008.

[54] Jill H Larkin i Herbert A Simon. „Why a Diagram is (Sometimes) Worth Ten Thousand

Words”. W: Cognitive Science 11.1 (1987), s. 65–100.

[55] Ora Lassila i Ralph R Swick. „Resource Description Framework (RDF) Model and Syn-

tax Specification”. W: World Wide Web Consortium (W3C) Recommendation (1999).

[56] Loom courses materials. https://www.isi.edu/isd/LOOM/documentation/

loom-course/.

[57] Loom User’s Guide. Spraw. tech. ISX Corporation, 1991.

[58] Oscar Pastor Lopez, Fiona Hayes i Stephen Bear. „Oasis: An object-oriented specifica-

tion language”. W: Advanced Information Systems Engineering. Red. Pericles Louco-

poulos. Springer Berlin Heidelberg. 1992, s. 348–363.

[59] Robert MacGregor i Raymond Bates. The Loom Knowledge Representation Language.

Spraw. tech. University of Southern California Information Sciences Institute, 1987.

[60] Beatriz Marín i in. „Main Features for MDD Tools: An Exploratory Study”. W: Inter-

national Conference on Model-Driven Engineering and Software Development. Red.

Slimane Hammoudi i in. Springer International Publishing. 2014, s. 183–196.

https://www.isi.edu/isd/LOOM/documentation/loom-course/

https://www.isi.edu/isd/LOOM/documentation/loom-course/

170 Bibliografia

[61] Floyd Marinescu i Abel Avram. Domain-Driven Design Quickly. InfoQ : Enterprise

software development series. C4Media, 2007.

[62] James Martin. Managing the Data Base Environment. Savant Res. Inst., 1981.

[63] Jeff McAffer i Jean-Michel Lemieux. Eclipse Rich Client Platform: Designing, Coding

and Packaging Java Applications. 2006.

[64] Deborah L McGuinness i Frank Van Harmelen. „OWL web ontology language ove-

rview”. W: World Wide Web Consortium (W3C) Recommendation (2004).

[65] Stephen J Mellor i in. MDA Distilled: Principles of Model Driven Architecture. Addison-

Wesley, 2004.

[66] StephenJ. Mellor i in. „Model-Driven Architecture”. W: Advances in Object-Oriented

Information Systems. T. 2426. Lecture Notes in Computer Science. Springer, 2002,

s. 290–297.

[67] Marjan Mernik, Jan Heering i Anthony M. Sloane. „When and How to Develop Domain-

specific Languages”. W: ACM Comput. Surv. 37.4 (2005), s. 316–344.

[68] George A Miller. „WordNet: A Lexical Database for English”. W: Commun. ACM 38.11

(1995), s. 39–41.

[69] Marvin Minsky. A framework for representing knowledge. Spraw. tech. 1974.

[70] Modelio website. https://www.modelio.org.

[71] Parastoo Mohagheghi i in. „Migrating Legacy Applications to the Service Cloud Para-

digm: The REMICS Project”. W: European Research Activities in Cloud Computing.

Cambridge Scholars Publishing, 2012. Rozd. 4, s. 97–122.

[72] Daniel L Moody. „The “Physics” of Notations: Toward a Scientific Basis for Construc-

ting Visual Notations in Software Engineering”. W: IEEE Transactions on Software

Engineering 35.6 (2009), s. 756–779.

[73] Bill Moore. Eclipse Development: Using the Graphical Editing Framework and the

Eclipse Modeling Framework. IBM Corp., 2004.

https://www.modelio.org

Bibliografia 171

[74] Boris Motik i in. „OWL 2 Web Ontology Language Structural Specification and Functio-

nal - Style Syntax (Second Edition)”. W: World Wide Web Consortium (W3C) Recom-

mendation (2012).

[75] Enrico Motta. „An overview of the OCML modelling language”. W: The 8th Workshop

on Methods and Languages. 1998.

[76] Enrico Motta i Zdenek Zdrahal. „A library of problem-solving components based on the

integration of the search paradigm with task and method ontologies”. W: International

Journal of Human-Computer Studies 49.4 (1998), s. 437–470.

[77] Peter Naur i in. Revised report on the algorithmic language Algol 60. Association for

Computing Machinery, 1976.

[78] Raquel Navarro-Prieto i Jose J Cañas. „Are visual programming languages better? The

role of imagery in program comprehension”. W: International Journal of Human- Com-

puter Studies 54.6 (2001), s. 799–829.

[79] Netfective Blue Age website. http://www.bluage.com/en/.

[80] Fabian Neuhaus, Pierre Grenon i Barry Smith. „A Formal Theory of Substances, Quali-

ties, and Universals”. W: Formal ontology in information systems. 2004, s. 49–59.

[81] Wiktor Nowakowski i in. „Recovery and Migration of Application Logic from Legacy

Systems”. W: Model-Driven Engineering of Information Systems: Principles, Techni-

ques, and Practice (2014), s. 321–343.

[82] OMG Meta Object Facility (MOF) Core Specification, version 2.5.1, formal/2016-11-

01. Object Management Group. 2016.

[83] Frauke Paetsch, Armin Eberlein i Frank Maurer. „Requirements engineering and agile

software development”. W: WET ICE 2003. Proceedings. Twelfth IEEE Internatio-

nal Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises,

2003. 2003, s. 308–313.

[84] Mike Potel. MVP: Model-View-Presenter the Taligent programming model for C++

and Java. Spraw. tech. Taligent Inc., 1996.

http://www.bluage.com/en/

172 Bibliografia

[85] ReDSeeDS project home page. http://redseeds.eu/.

[86] REMICS Project website. http://www.remics.eu/.

[87] Dan Rubel. „The Heart of Eclipse”. W: Queue 4.8 (2006), s. 36–44.

[88] James Rumbaugh, Ivar Jacobson i Grady Booch. Unified Modeling Language Reference

Manual, The (2Nd Edition). Pearson Higher Education, 2004.

[89] Kamil Rybinski i in. „Generating Graphical User Interfaces from Precise Domain Spe-

cifications”. W: e-Informatica Software Engineering Journal 8.1 (2014), s. 39–52.

[90] Kamil Rybinski i in. „TALE: Tool for Application Logic Extraction”. W: 4th Interna-

tional workshop on Academic Software Development Tools and Techniques. 2013.

[91] Nigel Shadbolt, Tim Berners-Lee i Wendy Hall. „The semantic web revisited”. W: IEEE

intelligent systems 21.3 (2006), s. 96–101.

[92] Laurent Siklóssy. „LISP: An introduction and some great programs”. W: Behavior Re-

search Methods & Instrumentation 11.2 (1979), s. 225–228.

[93] Thabet Slimani. „Ontology development: A comparing study on tools, languages and

formalisms”. W: Indian Journal of Science and Technology 8.24 (2015), s. 1–12.

[94] Kenneth Slonneger i Barry L Kurtz. Formal Syntax and Semantics of Programming

Languages. Addison-Wesley, 1995.

[95] Michał Smiałek. Zrozumiec UML 2.0. Metody modelowania obiektowego. Helion, 2005.

[96] Michał Smiałek, Norbert Jarzebowski i Wiktor Nowakowski. „Runtime semantics of

use case stories”. W: Visual Languages and Human-Centric Computing (VL/HCC),

2012 IEEE Symposium on. IEEE. 2012, s. 159–162.

[97] Michał Smiałek, Norbert Jarzebowski i Wiktor Nowakowski. „Translation of Use Case

Scenarios to Java Code”. W: Computer Science 13.4 (2012), s. 35–52.

[98] Michał Smiałek i Wiktor Nowakowski. From Requirements to Java in a Snap: Model-

Driven Requirements Engineering in Practice. Springer, 2015.

http://redseeds.eu/

http://www.remics.eu/

Bibliografia 173

[99] Michał Smiałek i Tomasz Straszak. „Facilitating transition from requirements to code

with the ReDSeeDS tool”. W: Requirements Engineering Conference (RE), 2012 20th

IEEE International. IEEE. 2012, s. 321–322.

[100] Michał Smiałek i in. „Comprehensive System for Systematic Case-Driven Software

Reuse”. W: Lecture Notes in Computer Science 5901 (2010), s. 697–708.

[101] Michał Smiałek i in. „Introducing a unified Requirements Specification Language”. W:

Proc. CEE-SET’2007, Software Engineering in Progress. Red. Lech Madeyski i in. Na-

kom, 2007, s. 172–183.

[102] Michael K Smith, Chris Welty i Deborah L McGuinness. „OWL Web Ontology Langu-

age Guide”. W: World Wide Web Consortium (W3C) Recommendation (2004).

[103] Guy Steele. Common LISP: The Language. Elsevier, 1990.

[104] Rudi Studer, V Richard Benjamins i Dieter Fensel. „Knowledge engineering: Principles

and Methods”. W: Data & Knowledge Engineering 25.1-2 (1998), s. 161–197.

[105] The MOLA Language Reference Manual Version 2.0 final. 2007.

[106] Unified Modeling Language: Superstructure, version 2.2, formal/09-02-02. Object Ma-

nagement Group. 2009.

[107] Jos B Warmer i Anneke G Kleppe. „The Object Constraint Language: Precise Modeling

with UML”. W: Addison-Wesley Object Technology Series (1998).

[108] Katharina Wolter i in. „Reusing Terminology for Requirements Specifications from

WordNet”. W: 16th IEEE International Requirements Engineering Conference, RE 2008.

IEEE. 2008, s. 325–326.

[109] William A Woods i James G Schmolze. „The KL-ONE family”. W: Computers & Ma-

thematics with Applications 23.2-5 (1992), s. 133–177.

POLITECHNIKA WARSZAWSKA - ee.pw.edu.pl

Documents

Transcript of POLITECHNIKA WARSZAWSKA - ee.pw.edu.pl