Both sides previous revision
Poprzednia wersja
Nowa wersja
|
Poprzednia wersja
Nowa wersja
Both sides next revision
|
pl:miw:miw08_ardcase_cs [2008/05/24 01:34] miw |
pl:miw:miw08_ardcase_cs [2008/06/11 16:55] gjn |
====== Opis ====== | ====== Opis ====== |
| __**Projekt zakończony**__ |
| |
Marcin Kamiński, <makamin@student.agh.edu.pl> | Marcin Kamiński, <makamin@student.agh.edu.pl> |
| |
| |
| |
| |
| |
:!::!: | :!::!: |
====== Projekt ====== | ====== Projekt ====== |
Cele projektu - wyszukanie dobrze udokumentowanych systemów sterujących w języku UML, próba zamodelowania znalezionych przykładów w ARD/XTT. | Cele projektu - wyszukanie dobrze udokumentowanych systemów sterujących w języku UML, próba zamodelowania znalezionych przykładów w ARD/XTT. |
| |
| |
| |
| |
| |
| |
| |
| |
** 1. Wyszukanie case** | ** 1. Wyszukanie case** |
| |
W trakcie tego etapu wybrano cztery przykłady systemów sterujących [[pl:miw:miw08_ardcase_cs:bankomat|bankomat]], [[pl:miw:miw08_ardcase_cs:bankomat|biletomat]], [[pl:miw:miw08_ardcase_cs:pralka|pralka]], oraz [[pl:miw:miw08_ardcase_cs:winda|winda]], oraz wyszukanie dla tych systemów modeli w języku UML. | 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:** | ** 2. Selekcja case, próby modelowania różnic i podobieństw w modelowaniu UML vs ARD/XTT:** |
Modelowanie UML a modelowanie ARD/XTT, uwagi: | 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 | * 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). | * 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 | * 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)** | |
| |
** 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]] | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| ** 3. Wybór, implementacja ARD i XTT dla case bankomatu, biletomatu i windy (szczegóły na podstronach):** |
| |
| |
[[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}} | [[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]] | 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]] |