Projekt zakończony
Krzysztof Kluza (4AR) krzysztof.kluza@uj.edu.pl
Investigate how XTT could be modeled in UML
UML, ARD/XTT documentation
Sample XTT based rules modelled with UML.
Some docs: a sane CVS Howto, MarkD, CVS Manual.
export CVSROOT=:ext:charon.ia.agh.edu.pl/mnt/cvs/cvs-hekate export CVS_RSH=ssh
Naming convention for CVS modules:
p_papername_conferenceYYYY p_papername epp_name hexor_name mirella_name xtt_name ard_name
Checking out:
cvs -d :ext:charon.ia.agh.edu.pl/mnt/cvs/cvs-hekate co p_mypaper_fancyconferece2007
Updating:
cd p_mypaper_fancyconferece2007 cvs update -Pd
Commiting:
cd p_mypaper_fancyconferece2007 cvs commit
Importing (creating a new module):
cd p_otherpaper cvs -d :ext:charon.ia.agh.edu.pl/mnt/cvs/cvs-hekate import -m initial p_otherpaper hekate start
Hekate bibliography BibTeX database is available as hekatebib cvs module, to checkout type:
cvs -d :ext:charon.ia.agh.edu.pl/mnt/cvs/cvs-hekate co hekatebib
There is a main file called hekate.bib
.
Check it out within your paper directory.
DO NOT REMOVE any entries, please.
Warning: hekate.bib
is NOT in sync with bibliography for now
Hopefully one day will be as soon as we have a sane BibTeX plugin for dokuwiki
TODO
Próby modelowania diagramów XTT:
Dalsze próby modelowania diagramów XTT za pomocą diagramów stanów.
Propozycja hipotetycznego modelu diagramu ARD w UMLu.
Sforumułowanie algorytmu przejścia z diagramu XTT na diagram aktywności UML.
Po zapoznaniu się z ARD (sar, shi, sha) postanowiłem użyć jednak diagramów klas do ich przedstawienia:
Propozycja wykorzystania zależności trace i derive.
Opracowanie krótkiego opisu specyfikacji MOF i standardu XMI.
Zmodyfikowane podejście do problemu modelu ARD.
Podsumowanie projektu w części Sprawozdanie.
Niniejszy projekt przedstawia próbę zamodelowania zarówno diagramów XTT, jak i ARD przy pomocy języka UML.
Tabele decyzyjne diagramu XTT reprezentują pewne reguły, które posiadają tego samego rodzaju atrybuty, a reguły te są przetwarzane sekwencyjnie. Wobec tego nasuwa się uzasadniona chęć użycia diagramów, które nie tyle pokazują strukturę systemu, co jego zachowanie (dynamikę). Są to zatem diagramy tj. przypadków użycia (use case), aktywności [czynności] (activity) i stanów (state), a także diagramy interakcji (sam diagram interakcji to diagram abstrakcyjny, który może być reprezentowany przez kilka różnych diagramów).
Żaden z diagramów nie oddaje w pełni przetwarzania regułowego XTT.
Najlepszymi kandydatami są: diagram maszyny stanów oraz diagram aktywności.
Jednakże pomimo, iż możliwe jest wyrażenie w nich reguł i zdefiniowanie stanów systemu,
tego rodzaju diagramy powiększają się bardzo szybko w miarę rozwoju oprogramowania.
Takie diagramy mogą być efektywnie stosowane w przypadkach, gdy mamy do czynienia
tylko z kilkoma regułami. Nie są jednak odpowiednie dla rzeczywistych systemów regułowych. (gjn2007kese-keuml s. 7)
Diagramy aktywności i diagramy stanów są powiązane. Diagram aktywności skupia się na obiekcie
przechodzącym pewien proces (albo na procesie traktowanym jak obiekt), natomiast diagram stanów skupia się na
operacjach związanych z jednym procesem.
(http://www.borland.pl/tech/poradnik_uml.shtml#Diagramy_aktywnosci)
Pierwsze próby modelowania XTT prowadzone były na diagramach stanów. Przykładowe podejścia do zamodelowania jednej z reguł XTT:
Problem: we wszystkich trzech powyższych podejściach brak nazwy atrybutu wyjściowego, zaś by uzyskać nazwy atrybutów wejściowych należałoby wyszukiwać ich w warunkach dozoru.
Diagramy aktywności mają związek z diagramami przepływu i służą do ilustrowania działań zachodzących w systemie. (…)
W diagramach aktywności można zaprezentować zdarzenia zachodzące równolegle. (Graessle 2006, s. 66)
Rezultatem projektu jest poniższy algorytm przekształcania diagramów XTT na diagramy aktywności (czynności) UML:
Diagramy aktywności skonstruowane powyższym algorytmem dla termostatu będą wyglądały następująco:
Dla przejrzystości, modelując diagram całego termostatu, powyższe aktywności przedstawiamy jako zagnieżdżone (aktywność przedstawiona w postaci zagnieżdżonej odwołuje się do szeregu akcji tej aktywności, których jednak w celach przejrzystości nie przedstawia się bezpośrednio na danym diagramie).
Diagram ARD (Atribute Relationship Diagram) identyfikuje atrybuty systemu i ukazuje zależności funkcjonalne pomiędzy nimi.
Przykładowy diagram ARD na niskim poziomie dla termostatu:
<graphviz file=„hekate:therm-a8.dot”></graphviz>
W czasie procesu projektowania diagram ARD rozrasta się. Rozrost taki można przedstawić przy pomocy modelu hierarchicznego TPH (Transformation Process History). Dla powyższego diagramu, diagram TPH wygląda następująco:
<graphviz file=„hekate:therm-t8.dot”></graphviz>
Problem: Gdy zostanie np. ustalona tylko jedna z wartości today albo hour sterowanie zostałoby przekazane do operation. Takie rozwiązanie nie wydaje się zgodne z działaniem termostatu.
Problem: W tym wypadku przekazywanie sterowania byłoby zgodne z diagramem ARD. Występuje jednak znaczna różnica semantyczna: w diagramie UML aktywności reprezentują czynności, zaś na tym diagramie mają reprezentować cechy (atrybuty) systemu.
W proponowanym modelu zostały użyte następujące rodzaje powiązań:
Proponowany model diagramu ARD bazuje na diagramach komponentów. W części projektowej znajdują się diagramy dla całego termostatu. Poniżej prezentuję diagramy najbardziej szczegółowego poziomu:
diagram ARD | diagram TPH | model UML diagramu THP + ARD |
---|---|---|
<graphviz file=„hekate:therm-a8.dot”></graphviz> | <graphviz file=„hekate:therm-t8.dot”></graphviz> |
Zależność trace w naszym modelu zachodzi między elementami reprezentującymi tę samą abstrakcję na różnych poziomach szczegółowości np.
patrz nowe haslo o XMI.
może ja Pan rozbudować przy okazji, w tym też poczytać o MOF…
oba hasła na razie w brudnopisie, gdyż nie mam dostępu do przestrzeni hekate: XMI & MOF (08.04.15)