Opis

Projekt zakończony

Marcin Kamiński, makamin@student.agh.edu.pl

:!::!: Design ARD+, XTTv2: Control System Cases – A search for well documented Control System examples/designs, esp. robot control, autonomous robots etc.; evaluation of the existing cases; modelling selected examples with ARD+/XTT+(v2)

Spotkania

Projekt

Cele projektu - wyszukanie dobrze udokumentowanych systemów sterujących w języku UML, próba zamodelowania znalezionych przykładów w ARD/XTT.

Sprawozdanie

0. Zapoznanie sie z literatura z wiki dotyczącą ARD/XTT

Na tym etapie zapoznawałem się z ARD/XTT, ogólną ideą, przykładami, oraz narzędziami dla tych technologii

1. Wyszukanie case

W trakcie tego etapu wybrano cztery przykłady systemów sterujących bankomatu, biletomatu, pralki, oraz windy, oraz wyszukanie dla tych systemów modeli w języku UML.

2. Selekcja case, próby modelowania różnic i podobieństw w modelowaniu UML vs ARD/XTT:

Ze znalezionych przykładów wybrano najlepsze modele UML modelujące zachowanie systemu. Dla pralki okazało się to niemożliwe, ponieważ jedyny diagram UML jaki znalazłem to diagram stanów, który jest nieco zbyt ubogą reprezentacją, anu tylko na jego podstawie zrozumieć/próbować modelować cały system.

Modelowanie UML a modelowanie ARD/XTT, uwagi:

  • W zależności od systemu - zdarza się, iż dobrze zamodelowany w UML system przy użyciu DFD i Use-case pozwala łatwo wyodrębnić wejścia i wyjścia systemu co jest dobrym początkiem dla wyszukiwania atrybutów dla ARD. Np. dla biletomatu wejścia i wyjścia wynikają jasno z diagramów DFD i Use-case tj. z use-case można było rozpoznać możliwe akcje, a z diagramu DFD odczytać interesujące informacje. Dla windy use-case mówi niewiele, potrzebne od wyselekcjonowania atrybutów dane znaleźć za to można na diagramie klas (gorsze rozwiązanie) lub na diagramie współpracy. Maszyna stanów opisana w innym z przykładów jest bardzo łatwo przenaszalna do ARD/XTT, ogólnie systemy CS realizowane jako maszyny stanów można z powodzeniem dość prosto przenieść do tablic XTT (jak w przykładzie windy).
  • Diagramy stanów mogą być bardzo przydatne przy określaniu reguł. Tj. wiedząc, że system może przejść z jednego stanu do drugiego mamy już pewną regułę, więc pozostaje tylko (na diagramie współpracy, bądź DFD) uzupełnić przejście ze stanu o warunki jakie muszą zajść, aby to przejście miało miejsce (niestety w przypadku bardziej złożonych warunków przejścia tej informacji nie da się łatwo wywnioskować z UML).
  • Jeden przypadek użycia bądź aktywność na diagramach UML mogą mieć bardzo skomplikowaną budowę w ARD/XTT.
  • Często zdarza się, iż modele UML są zbyt ubogie, aby zamodelować system bez używania wiedzy spoza modelu UML, tymczasem system zamodelowany w ARD/XTT może być jednoznacznie zrealizowany, ponieważ model opisany przy użyciu ARD/XTT, aby był poprawny musi zawierać całkowitą definicje struktury systemu (np. brak finalizacji nie pozwoli na wygenerowanie wszystkich niezbędnych do dalszych etapów plików), oraz reguł w nim zachodzących, co jest osiągane przez zdefiniowanie składowych atrybutów (oraz ich dziedzin), oraz reguł, działań i zależności jakie między nimi zachodzą.

3. Wybór, implementacja ARD i XTT dla case bankomatu, biletomatu i windy (szczegóły na podstronach):

Control System Models

Elevator:

Cashpoint:

Washing-machine:

Vending Machine:

4. Ciekawe problemy napotkane w trakcie pracy

  • Porównanie atrybut do atrybutu - przykładowo PIN wpisany z PINem w bazie. Można zapisać to na dwa równoważne sposoby - PIN w bazie dowolny, a PIN wpisany równy PINowi w bazie ⇔ PIN wpisany dowolny, PIN w bazie równy wpisanemu (dwie reguły, ale równoważne) - w pracach zakładałem prawy atrybut jako dowolny a lewy jako porównywany w sytuacjach porównywania atrybutu z atrybutem. Przykład - w tabeli 1 przyjęto koncepcje, iż atrybut z prawej jest dowolny, a z prawej porównywany, w drugiej odwrotnie.
  • TBC: Co w przypadku porównywania większej ilości atrybutów
  • Należy unikać działań po stronie warunków, aby je wyeliminować należy wprowadzać dodatkowe atrybuty pojęciowe (conceptual attributes) - należy unikać zapisów jak w pierwszej tabeli Przykład (przykład jak nie powinno sie robić)
  • ARD nie specyfikuje struktur danych, więc może okazać się ciężkim zdefiniowanie danej pochodzącej z tablicy np. cena wybranego produktu z listy cen dlatego zapis jak w pierwszej tabeli jest niepoprawny Przykład (przykład jak nie powinno się robić)
  • Jeżeli na skutek działania reguły ma się zmienić wartość jednego z atrybutów biorących udział w odpaleniu reguły to należy go zdefiniować zarówno po stronie warunków jak i po stronie konkluzji
  • Odnośnie powyższego - często jeśli reguła/tabela ma mieć więcej niż jedną konkluzje lepiej zdefiniować dodatkową tabelę (w przykładzie Logical design można zauważyć, iż najpierw wyznaczana jest aktywność bankomatu, a następnie na tej podstawie uaktualniane są środki, którymi dysponuje bankomat (formalnie można by to było zrobić w jednej tabeli, ale pomimo prób nie udało mi się i otrzymywałem dwie tabele z identycznymi warunkami i innymi konkluzjami zamiast jednej tabeli z dwiema konkluzjami - Plik .pl więcej szczegółów tutaj

5. Uwagi do wiki,VARDA, HqEd

Wszystkie uwagi do wykorzystywanych narzędzi zostały zgłoszone przez system CVSTrac

Materiały

pl/miw/miw08_ardcase_cs.txt · ostatnio zmienione: 2019/06/27 15:50 (edycja zewnętrzna)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0