Jakub Turoboś jakub.turobos@gmail.com

• implementacja refactoring dla varda/gvarda/interactive_shell
• ocena przydatności: przyklady

• potencjalnie dobre rozwiązanie, jednak na chwilę obecną niestabilne
• konieczność zastąpienia użytej biblioteki do graficznej reprezentacji grafów (JGraph) inną
  pomimo poszukiwań wybór jest mocno okrojony, jedyną sensowną opcją wydaje się być JUNG
• ciężko ocenić czas potrzebny na wprowadzenie zmian, nie ma też gwarancji na to czy będzie to koniec problemów
• duża ilość klas, niejednokrotnie bardzo obszernych, jednak w większości dobrze okomentowanych

• rozwiązanie gotowe do rozbudowy
• stosunkowo mniejsza ilość kodu, jednak momentami nie tak łatwa w odbiorze jak kod języka Java

Podsumowując, preferowanym rożwiązaniem na chwilę obecną jest Varda. W zależności od postępu prac, rozwijane być może będą oba rozwiązania.

• GVARDA - błąd parsowania przy próbie finalizacji - stworzenia atrybutu o podobnej nazwie, np. dla atrybutu 'Dat' występuje błąd parsowania, gdy próbujemy stworzyć atrybut 'Data'

refactoring w teorii ARD+

Niezależnie od diagramu (ARD, TPH) oraz poziomu szczegółowości istnieją dwa przypadki, w zależności od edytowanej własności:

1. Complex Property (PC) - należy z niej wybrać jedną z zawartych w niej własności, po czym postępujemy jak w następnym przypadku
2. Simple Property (PS) - niezależnie od tego czy własność jest conceptual czy phisical następuje algorytm zmiany nazwy atrybutu opisany poniżej

Podobnie jak w poprzednim przypadku, istnieją tylko dwa przypadki, w zależności od usuwanej własności, niezależne od diagramu ani poziomu szczegółowości:

1. usuwanie jednego z atrybutów należących do własności (w przypadku PC)
2. usuwanie całej własności

niezależnie od przypadku następuje algorytm usuwania atrybutu opisany poniżej

Przy dodawaniu nowego atrybutu na poziomie niższym niż aktualny poziom szczegółowości istnieje tylko jedno rozwiązanie - użytkownik musi wybrać (na diagramie TPH) jedną z istniejących transformacji finalizacji i tam dodać nowy atrybut, a następnie tworzyć kolejne transformacje do momentu kiedy:

• osiągnięty zostanie najwyższy poziom szczegółowości
• dodany atrybut w wyniku kolejnych transformacji rozwinięty zostanie w atrybuty fizyczne należące do PS, czyli niemożliwe będzie zastosowanie kolejnych transformacji

Wersja minimalna - użytkownik musi wybrać (na diagramie TPH) jedną z istniejących transformacji finalizacji i tam dodać nowy atrybut, a następnie zdefiniować zależności funkcyjne związane z dodanym atrybutem na najbardziej szczegółowym poziomie. Tak dodany atrybut może być dalej rozwijany, jeżeli nie jest on atrybutem fizycznym.

Zależności funkcyjne dowolnego niższego od aktualnego poziomu szczegółowości wygenerować można wykorzystując diagram TPH oraz zależności funkcyjne zdefiniowane na aktualnym poziomie szczegółowości. Proces odwrotny natomiast, czyli wygenerowanie zależności funkcyjnych przy przejściu na wyższy poziom szczegółowości wymaga w przeważającej ilości przypadków ingerencji użytkownika. Dlatego też optymalnym rozwiązaniem wydaje się pozostawienie użytkownikowi swobody modyfikacji zależności funkcyjnych jedynie na najwyższym poziomie szczegółowości diagramu ARD.

Przy modyfikacji przydziału atrybutu do własności w ramach podziału danego PC mogą zajść następujące warianty:

• żadna z modyfikowanych własności pochodzących z podziału nie posiada pochodnych
• modyfikowane własności pochodzące z podziału posiadają pochodne
  • połączenie dwóch lub własności w pojedynczy PC
  • rozbicie PC na szereg PS
  • inne...

opisy algorytmów powyższych modyfikacji znajdują się poniżej.

Modyfikacja zależności funkcyjnej może polegać na jej:

• usunięciu
• dodaniu
• „przepięciu”

opisy algorytmów powyższych modyfikacji znajdują się poniżej.

• dodanie/usunięcie/zmiana nazwy - pokryte przez finalizację

1. rekurencyjne przeszukanie zbiorów P, D, V dla zadanej nazwy atrybutu
2. zmiana nazwy każdego ze znalezionych atrybutów; przerwanie w przeciwnym przypadku

1. utworzenie kolejki/listy lub kilku list własności/atrybutów, zależności oraz pochodnych do usunięcia lub akcji do wykonania (FILO)
2. znalezienie takiej pochodnej V = [P₁, P₂] w zbiorze V, gdzie usuwany atrybut X należy do P₂ i nie należy do P₁, czyli szukana jest finalizacja, z której pochodzi usuwany atrybut; przerwanie w przeciwnym przypadku
3. dopisanie atrybutu X z własności P₂ do listy
4. znalezienie takiej pochodnej V_X = [P₂, P_X] w zbiorze V, gdzie P_X jest PS, czyli szukana jest transformacja podziału dla własności P₂ i atrybutu X; przerwanie w przeciwnym przypadku
5. dopisanie własności P_X oraz pochodnej V_X do listy
6. znalezienie pochodnych V_N = [P_X, P_N] w zbiorze V
7. jeżeli w poprzednim kroku znaleziono pochodne, to dla każdej z nich:
   1. dopisać P_N oraz V_N do listy
   2. zastąpić własność P_X własnością P_N
   3. wrócić do kroku 6.
   • czy jeżeli istnieją zależności funkcyjne D_N,X oraz D_X,M, to czy można przy usuwaniu własności X stworzyć zależność D_N,M?
8. dla każdej z własności/atrybutu X znajdującego się na liście do usunięcia znaleźć w zbiorze D zależności fukcyjne
   D_N,X = [P_N, P_X] oraz D_X,M = [P_X, P_M], gdzie P_X zawiera X

Analiza istniejących rozwiązań - ewentualne ich wykorzystanie/modyfikacja

• żadna z modyfikowanych własności pochodzących z podziału nie posiada pochodnych - prosta edycja transformacji podziału, może być wykonana poprzez usunięcie edytowanej transformacji z zachowaniem atrybutów, a następnie dodanie nowej transformacji podziału z nowym przydziałem atrybutów, po czym może nastąpić ewentualna modyfikacja zależności funkcyjnych
• modyfikowane własności pochodzące z podziału posiadają pochodne
  • połączenie dwóch lub własności w pojedynczy PC (z wyłączeniem możliwości połączenia wszystkich) - wygenerowanie nowego PC, będącego sumą atrybutów własności łączonych, oraz transformacji podziału
  • rozbicie **PC** na szereg **PS**
  • inne...

• usunięcie zależności funkcyjnej:
  1. przeszukanie zbioru D
  2. usunięcie znalezionej zależności; przerwanie w przeciwnym przypadku
• dodanie zależności funkcyjnej - wykorzystanie istniejącego rozwiązania
• „przepięcie” zależności funkcyjnej:
  1. przeszukanie zbioru D
  2. zastąpienie pierwszego lub drugiego atrybutu znalezionej zależności; przerwanie w przeciwnym przypadku
     alternatywnie :
  3. usunięcie modyfikowanej zależności
  4. dodanie nowej, już zmodyfikowanej zależności

• HJED - czy przydatny? na 2.12.2009, decyzja ktore oprogramowanie rozwijac (gvarda/varda, czy hjed), JUNG – krotki raport, docelowo rozdzial/podrozdzial pracy, opis na 9/12/2009
• przeczytać: http://home.agh.edu.pl/~wojnicki/didactic/mgr-howto.txt
• bardziej szczegolowo scenariusze, przemyslec algorytmy modyfikacji bazy wiedzy odnosnie rafaktoringu 20.01.2010, on hold
• wstep i podst. teoretyczne: 10.02.2010

1. wstep (zgodnie z Howto jak_pisac_prace_dyplomowa
2. Podstawy teoretyczne
   1. atrybutowe systemy regułowe (prof.Ligeza, Logical Foundations for Rule-Based Systems)
   2. projektowanie syst. reg. (Mulawka, Systemy Ekspertowe)
   3. ARD http://winntbg.bg.agh.edu.pl/csl/csltr-1-2009.pdf
3. Projekt
   1. specyfikacja wymagań:
      • głóny cel,
      • porównanie technlogii (hjed, varda, gvarda),
      • przypadki użycia (scenariusze do każdego rodzaju refaktoringu)
   2. Projekt
      • Jakie technologie i dla czego (uzasadnienie wyboru, na podstawie analizay varda/gvarda/hjed)
      • predykaty
      • GUI
4. Implementacja
   • co zostało zaimplementowane: predykaty, GUI
   • Szczegóły implementacyjne
   • Problemy z implementacją
   • jak zostały spełnione wymagania.
5. Użycie/Testy
   • realizacja przypadkow użycia, zastosowanie predykatow, GUI w akcji, diagramy.
6. Podsumowanie

Termin obrony: czerwiec.