Różnice

Różnice między wybraną wersją a wersją aktualną.

Odnośnik do tego porównania

pl:miw:miw08_ardcase_cs [2008/06/11 16:55]
gjn
pl:miw:miw08_ardcase_cs [2019/06/27 15:50]
Linia 1: Linia 1:
-====== 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 ====== 
-[[pl:​miw:​miw08_ardcase_cs:​spotkania|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 [[pl:​miw:​miw08_ardcase_cs:​bankomat|bankomatu]],​ [[pl:​miw:​miw08_ardcase_cs:​biletomat|biletomatu]],​ [[pl:​miw:​miw08_ardcase_cs:​pralka|pralki]],​ oraz [[pl:​miw:​miw08_ardcase_cs:​winda|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: === 
- 
- 
-[[http://​www.soi.wide.ad.jp/​class/​20040034/​slides/​07/​|Very well documented Elevator Model slide I (7)]] {{:​pl:​miw:​miw08_ardcase_cs:​download.zip|local copy}} 
- 
-[[http://​www.soi.wide.ad.jp/​class/​20040034/​slides/​08/​|Very well documented Elevator Model slide II (8)]] {{:​pl:​miw:​miw08_ardcase_cs:​download.zip|local copy}} 
- 
-[[http://​www.soi.wide.ad.jp/​class/​20040034/​slides/​09/​|Very well documented Elevator Model slide III (9)]] {{:​pl:​miw:​miw08_ardcase_cs:​download.zip|local copy}} 
- 
-[[http://​www.soi.wide.ad.jp/​class/​20040034/​slides/​10/​|Very well documented Elevator Model slide IV (10)]] {{:​pl:​miw:​miw08_ardcase_cs:​download.zip|local copy}} 
- 
-[[http://​www.soi.wide.ad.jp/​class/​20040034/​slides/​12/​|Very well documented Elevator Model slide V (12)]] {{:​pl:​miw:​miw08_ardcase_cs:​download.zip|local copy}} 
- 
-[[http://​regulus.ia.agh.edu.pl/​gjn-Regulus-WWW/​miw2002/​MIW02-projekty/​MIW02-Winda.pdf|Students MiW Project by J.Sysak, P.Zieliński]] {{:​pl:​miw:​miw08_ardcase_cs:​miw02-winda.pdf|local copy}} 
- 
-{{:​pl:​miw:​miw08_ardcase_cs:​elevator_example_in_uml.pdf|Example of elevator (local copy)}} 
- 
-Wybór, analiza i porownanie [[pl:​miw:​miw08_ardcase_cs:​winda|tutaj]] 
- 
-=== Cashpoint: === 
- 
- 
-[[http://​cis.paisley.ac.uk/​mcmo-ci0/​SoftDev/​Text/​UML%20QuickGuide.pdf|Quite good documented Cashpoint Model]] {{:​pl:​miw:​miw08_ardcase_cs:​uml_quickguide.pdf|local copy}} 
- 
-[[http://​www.emn.fr/​x-info/​jroyer/​cashpoint.pdf|Another quite good documented Cashpoint Model]] {{:​pl:​miw:​miw08_ardcase_cs:​cashpoint.pdf|local copy}} 
- 
-[[http://​www4.in.tum.de/​lehre/​da/​DA_Wimmel.ps.gz|One more Cashpoint Model]] {{:​pl:​miw:​miw08_ardcase_cs:​da_wimmel.ps.ps|local copy}} 
- 
-Wybór, analiza i porownanie [[pl:​miw:​miw08_ardcase_cs:​bankomat|tutaj]] 
- 
-=== Washing-machine:​ === 
- 
- 
- 
-[[ftp://​ftp.elteknik.chalmers.se/​Publications/​MSc/​Hedin&​LundstromMSc.pdf|Very good, technical model of Washing-machine with controller in Simulink languare (too technical, can be useless?)]] {{:​pl:​miw:​miw08_ardcase_cs:​hedin_lundstrommsc.pdf|local copy}} 
- 
-[[http://​cserg0.site.uottawa.ca/​seg/​bin/​viewfile/​SEG3201/​WebHome?​rev=1;​filename=UML_2_State_Machine_Diagrams.ppt#​263,​8,​ State Machine Diagrams|Examples of State Machine Diagrams (also example of Washing-machine)]] {{:​pl:​miw:​miw08_ardcase_cs:​uml_2_state_machine_diagrams.ppt|local copy}} 
- 
-Wybór, analiza i porownanie [[pl:​miw:​miw08_ardcase_cs:​pralka|tutaj]] 
- 
-=== Vending Machine: === 
- 
- 
-[[http://​student.agh.edu.pl/​~makamin/​MiW/​TPa%b3osz,​MMazur%20-%20Automat.pdf|Well documented Vending Machine Model by T. Pałosz, M. Mazur (AiR IV)]] {{:​pl:​miw:​miw08_ardcase_cs:​tpa_b3osz_mmazur_-_automat.pdf|local copy}} 
- 
-Wybór, analiza i porownanie [[pl:​miw:​miw08_ardcase_cs:​biletomat|tutaj]] 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
-====== ====== 
- 
- 
-**   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. {{pl:​miw:​miw08_ardcase_cs:​miw-cashpoint-xtt.pdf|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 {{pl:​miw:​miw08_ardcase_cs:​miw-vendingmachine-xtt.pdf|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 {{pl:​miw:​miw08_ardcase_cs:​miw-vendingmachine-xtt.pdf|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 [[pl:​miw:​miw08_ardcase_cs:​bankomat#​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 - {{:​pl:​miw:​miw08_ardcase_cs:​cashpoint_case.pl|Plik .pl}} więcej szczegółów [[pl:​miw:​miw08_ardcase_cs:​bankomat#​case|tutaj]] ​ 
-**   5. Uwagi do wiki,VARDA, HqEd** 
- 
- ​Wszystkie uwagi do wykorzystywanych narzędzi zostały zgłoszone przez system [[hekate:​hqed#​report_bugs'​|CVSTrac]] 
- 
-====== Materiały ====== 
-[[pl:​miw:​miw08_ardcase_cs:​matrialy|Materialy]] 
  
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