[[
✎ pl:miw:miw08_ardcase_cs
]]
aiWiki
Pokaż stronę
Ostatnie zmiany
Indeks
Zaloguj
Ta strona jest tylko do odczytu. Możesz wyświetlić źródła tej strony ale nie możesz ich zmienić.
====== Opis ====== 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** ** 1. Wyszukanie case** ** 2. Selekcja case, próby modelowania różnic i podobieństw w modelowaniu UML vs ARD/XTT:** 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 * 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 ** 3. Wybór, implementacja ARD i XTT dla case bankomatu, biletomatu i windy (szczegóły na podstronach)** ** 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 {{:miw:miw08_ardcase_cs:bankomat}} Logical design v3) 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) ** 5. Uwagi do wiki,VARDA, HqEd** * HqEd: Problemy z typami danych - dwie dane typu integer czasem (nie wiadomo czemu) nie mogą być porównywane * HqEd: Problemy z typami danych - dla typów wyliczeniowych zdarza się, iż poprawna wartość jest identyikowana jako błąd * HqEd: Problemy z zapisem typów tablicowych - cena=lista[produkt] - jak to zapisać, czy tak jak w [[pl:miw:miw08_ardcase_cs:biletomat]] Logical design v3 jest OK? * HqEd: Tabele bardzo gonią, a przy większych tabelach może to uniemożliwiać pracę * HqEd: Jeśli istnieje wiele podobnych atrybutów to początkowo otrzymują one takie same akronimy i na etapie dodefiniowywania/zmiany typu pojawiają się błędy * VARDA: W przypadku gdy po stronie decyzji maja się zmienić dwa atrybuty czasem ciężko zrobić odpowiednią tabele bez ręcznego dodawania zależności * VARDA: Należy zwracać uwagę, aby po każdym użyciu usuwać fakty lub restartować prolog i VARDE, ponieważ czasem poprawy kod nie może zostać uzgodniony * wiki: Integracja Graphviza z wiki bardzo udana! ====== Materiały ====== [[pl:miw:miw08_ardcase_cs:matrialy|Materialy]] ===== 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}} Analiza [[pl:miw:miw08_ardcase_cs:biletomat|tutaj]]
pl/miw/miw08_ardcase_cs.1211584966.txt.gz
· ostatnio zmienione: 2019/06/27 15:58 (edycja zewnętrzna)
Pokaż stronę
Poprzednie wersje
Menadżer multimediów
Do góry