--- pl:miw:miw08_ardcase_cs:winda [2008/05/19 21:32]
miw
+++ pl:miw:miw08_ardcase_cs:winda [2019/06/27 15:50] (aktualna)
@@ Linia 8: / Linia 8: @@
 P2: {{:pl:miw:miw08_ardcase_cs:download.zip|Very well documented Elevator Model (local copy)}}
-P3: [[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}}
+P3: {{:pl:miw:miw08_ardcase_cs:miw02-winda.pdf|Students MiW Project by J.Sysak, P.Zieliński <local copy>}}
-==== Uzasadnienie wyboru i porównanie ====
-Wybrany przykład - P1 jest bardzo dobrze zamodelowanym i udokumentowanym systemem. Tę cechę posiada również przykład P2, jednak w przypadku przykładu P2 mimo wielu diagramów analiza wydaje się zbyt uboga (m.in. tylko dwa use-case'y). Za bazowy uznaję przykład P1. Jeśli na etapie projektowania/prototypowania okaże się, iż w modelu brakuje ważnych z punktu widzenia realizowanego projektu informacji bądź schematów zostaną one zaczerpnięte z przykładu P2. Przykład P3 jako, że nie jest zamodelowany w języku UML może przydać się przy wyodrębnianiu artybutów/definiowaniu reguł.
-==== Próby modelowania ====
+==== Uzasadnienie wyboru i porównanie ====
-Na tym etapie na podstawie modelu następuje próba wyselekcjonowania wejść, wyjść, wyselekcjonowanie atrybutów (fizycznych i ogólnych), próba zamodelowania reguł panujących w systemie przy pomocy atrybutów.
+Wybrany przykład - P1 jest bardzo dobrze zamodelowanym i udokumentowanym systemem. Tę cechę posiada również przykład P2, jednak w przypadku przykładu P2 mimo wielu diagramów analiza wydaje się zbyt uboga (m.in. tylko dwa use-case'y). Za bazowy uznaję przykład P1. Jeśli na etapie projektowania/prototypowania okaże się, iż w modelu brakuje ważnych z punktu widzenia realizowanego projektu informacji bądź schematów zostaną one zaczerpnięte z przykładu P2. Przykład P3 jako, że nie jest zamodelowany w języku UML może przydać się przy wyodrębnianiu artybutów/definiowaniu reguł.
+Mimo powyższego jednak algorytm ruchu windy, mimo, iż diagramy UML - use-case i aktywności precyzują działanie windy sprowadza się ono jednak do zbioru reguł prezentowanego w P3, dlatego to on zostanie zaimplementowany.
+Wezwanie windy sprowadzić można do sprawdzenia czy wezwanie jest z nad windy czy z poniżej aktualnej pozycji windy, podobnie wezwania wewnętrzne (z przykładu P3 zostaną usunięte warunki i konkluzje dotyczące przeciążenia windy jako, że modele UML nie specyfikowały takiej funkcjonalności).
-Wejścia: wezwania windy z zewnątrz, wezwania windy z kabiny
-Wyjścia: określenie kierunku ruchu, oraz piętra na którym się zatrzymać (technicznie wypracowanie sterowania...) ; w pewnym sensie wyjścia to także wskaźniki w windzie i poza nią
-'Reguły:' tabela decyzyjna -> kierunek jazdy ; tabela decyzyjna + które piętro -> stop czy jazda dalej ; przyciski zewnątrz i wewnątrz -> zmiana w kontrolerze ; okresowo -> sprawdzanie tabeli prawdy względem tego jakie dane ma kontroler
-**// ToDo : Uściślić dokładniej co przyjmujemy za wejście i wyjście ; w kwestii logiki wejścia są to tylko wezwania, wyjścia to tylko zachowanie windy, czy uwzględniać wskaźniki etc. Na jakim etapie (potrzebne do modelowania przejść) wprowadzić takie rzeczy jak położenie kabiny i kierunek ruchu i czy robić to technicznie - enkodery etc. czy wystarczy koncepcyjnie <ogólnie kontrola położenia> ; czy reguły wstępnie OK**
+===== Description =====
+Przykład zakłada realizacje podstawowych funkcji windy jak przywołanie windy, wybranie piętra docelowego, wskazywanie położenia wewnątrz i na zewnątrz windy, wskazywanie kierunku jazdy, jazde windy między piętrami, wyliczanie na które piętro pojechać. W przeciwieństwie do innych przykładów działanie windy zależy w wielkim stopniu nie tylko od akcji podejmowanych przez pasażerów w danym momencie, ale także od "pamięci" windy (tj. wcześniejszych wezwań), aktualnego jej stanu - aktualnego kierunku jazdy etc.
-====== Analiza biletomatu i design ======
-==== Wybrany przykład: ====
-[[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|localcopy}}
-== Pozostałe przykłady ==
-Brak
-==== Uzasadnienie wyboru i porównanie ====
-Na tym etapie jest to jedyny znaleziony model. System jest dobrze zamodelowany nie tylko od strony logiki biznesowej klienta ale także serwisu i kontroli. Ze względu na brak innych modeli porównanie jest niemożliwe.
-===== Description =====
-W udostępnionym przykładzie zamodelowanym w UML możliwe jest jedynie kupowanie biletu, w niniejszym modelu rozważone będzie także doładowanie KKM (Krakowska Karta Miejska ; to lokalizuje rozwiązanie ale w skali światowej nie jest to bardzo innowacyjne rozwiązanie, więc można to zrobić bez straty ogólności)
-Użycie biletomatu polega na wybraniu opcji - zakup biletu bądz doładowanie karty okresowej. Po wybraniu opcji należy wrzucić odpowiednią ilość pieniędzy - jak w use-case. Jeśli przez zbyt długi czas użytkownik nie wpłaci pieniędzy aby sfinalizować transakcje przyjęte pieniądze są oddawane.
-Możliwe działania wynikowe biletomatu - drukowanie potwierdzenia, wydawanie pieniedzy, drukowanie biletu, zapisywanie danych na karcie
 ===== Conceptualization =====
-W niniejszym rozdziale następuje próba specyfikacji wejść, wyjść, atrybutów, oraz reguł w systemie
+Na tym etapie na podstawie modelu następuje próba wyselekcjonowania wejść, wyjść, wyselekcjonowanie atrybutów (fizycznych i ogólnych), próba zamodelowania reguł panujących w systemie przy pomocy atrybutów.
 ==== Vocabulary ====
-Wejścia: Decyzja odnośnie zakupu karta/bilet, jeśli karta to wybór linii i dat, jeśli bilet to wybór rodzaju
-Wyjście: Potwierdzenie/reszta/komunikat
+Wejścia: wezwania windy z zewnątrz, wezwania windy z kabiny
-Elementy wiedzy: Akcja wybrana przez użytkownika (dziedzina: bilet/karta), typ biletu/dane do karty, czy istnieje możliwość drukowania, czy biletomat może wydać resztę.
+Wyjścia: określenie kierunku ruchu, oraz piętra na którym się zatrzymać (technicznie wypracowanie sterowania...) ; w pewnym sensie wyjścia to także wskaźniki w windzie i poza nią
+Stany wewnętrzne: Aktualne położenie, aktualny kierunek ruchu
-==== Original Rules ====
-Reguły:
-- Jeśli akcją jest zakup biletu to należy wybrać typ biletu
+==== Original Rules ====
+Reguły:
-- Jeśli akcją jest doładowanie karty to należy podać dane
+tabela decyzyjna -> kierunek jazdy
-- Należy wpłacić pieniądze
+tabela decyzyjna + aktualne piętro -> stop czy jazda dalej
-- Jeśli wpłacono to drukowanie biletu/wydanie reszty, jeśli nie to po pewnym czasie zwrot pieniędzy
+przyciski zewnątrz i wewnątrz -> zmiana w kontrolerze
 ===== Analysis =====
 ===== Conceptual design =====
-Poziom 0: Biletomat
+Poziom 0: Winda
-Poziom 1: Finalizacja Biletomatu na: Czas, Pieniądze, Dostępność, Aktywność biletomatu
+Poziom 1: Finalizacja Windy na: Aktualny kierunek windy, Poprzedni kierunek windy, Czy jest żądanie jazdy w gorę z kabiny, Czy jest żądanie jazdy w dół z kabiny, Czy jest żądanie jazdy na aktualne piętro z kabiny, Czy są wezwania z wyższych pięter do jazy w górę, Czy są wezwania z wyższych pięter do jazdy w dół, Czy są wezwania z niższych pięter do jazdy w górę, Czy są wezwania z niższych pięter do jazdy w dół Czy są wezwania z aktualnego piętra do jazdy w górę, Czy są wezwania z aktualnego piętra do jazdy w dół, Decyzja gdzie jechać
-Poziom 2: Split: Czas -> Aktywność biletomatu, Pieniądze -> Aktywność biletomatu, Dostępność -> Aktywność biletomatu
+Poziom 2: Split: Aktualny kierunek windy -> Decyzja gdzie jechać, Poprzedni kierunek windy -> Decyzja gdzie jechać, Czy jest żądanie jazdy w gorę z kabiny -> Decyzja gdzie jechać, Czy jest żądanie jazdy w dół z kabiny -> Decyzja gdzie jechać, Czy jest żądanie jazdy na aktualne piętro z kabiny -> Decyzja gdzie jechać, Czy są wezwania z wyższych pięter do jazy w górę -> Decyzja gdzie jechać, Czy są wezwania z wyższych pięter do jazdy w dół -> Decyzja gdzie jechać, Czy są wezwania z niższych pięter do jazdy w górę -> Decyzja gdzie jechać, Czy są wezwania z niższych pięter do jazdy w dół -> Decyzja gdzie jechać, Czy są wezwania z aktualnego piętra do jazdy w górę -> Decyzja gdzie jechać, Czy są wezwania z aktualnego piętra do jazdy w dół -> Decyzja gdzie jechać
-Poziom 3: Finalizacja Czas na : Czas obecny, Czas rozpoczęcia, przekroczenie limitu czasu
+Poziom 3-13: Finalizacja każdego z atrybutów
-Poziom 4: Split: Czas obecny -> przekroczenie limitu czasu, Czas rozpoczęcia -> przekroczenie limitu czasu
-Poziom 5,6: Finalizacja Czas obecny -> czas obecny ; Czas rozpoczęcia -> czas rozpoczęcia
-Poziom 7: Finalizacja Dostępność na: Pieniądze w biletomacie, (znacznik) Wystarczająca ilość pieniędzy do wydania reszty
-Poziom 8: Split: Pieniądze w biletomacie -> Wystarczająca ilość pieniędzy do wydania reszty, Wystarczająca ilość pieniędzy do wydania reszty -> Aktywność biletomatu
-Poziom 9: Finalizacja Pieniądze na: Wpłacona kwota, Cena do zapłacenia, Reszta
-Poziom 10: Split: Cena do zapłacenia -> Reszta, Wpłacona kwota -> Reszta, Reszta -> Aktywność biletomatu
-Poziom 11: Finalizacja Cena do zapłacenia na: Wybrany produkt, Lista cen, Cena
-Poziom 12: Split: Wybrany produkt -> Cena, Lista cen -> Cena, Cena -> Reszta
-Poziom 13-20: Finalizacja Pieniądze w biletomacie -> pieniądze w bletomacie, Wybrany produkt -> wybrany produkt, Wpłacona kwota -> wpłacona kwota, Wystarczająca ilość pieniędzy do wydania reszty -> wystarczająca ilość pieniędzy do wydania reszty, Reszta -> reszta, Lista cen -> lista cen, Cena -> cena, Aktywność biletomatu -> aktywność biletomatu
-Poziom 21: Ręczne dodanie zależności pieniądze w biletomacie -> aktywność biletomatu (konieczne do wyznaczenia działania biletomatu)
-Poziom 22: Ręczne dodanie zależności reszta -> wystarczająca ilość pieniędzy do wydania reszty (konieczne do ustalenia czy mamy tyle pieniędzy)
-Poziom 23: Ręczne dodanie zależności pieniądze w biletomacie -> pieniądze w biletomacie (konieczne do pomniejszenia ilości pieniędzy po ich wydaniu)
-Poziom 21: Ręczne dodanie zależności cena -> pieniądze w biletomacie (konieczne do pomniejszenia ilości pieniędzy po ich wydaniu)
-Poziom 21: Ręczne dodanie zależności aktywność bilatomatu -> pieniądze w biletomacie (konieczne do pomniejszenia ilości pieniędzy po ich wydaniu)
 ==== General Conceptual Design ====
+==== V1 ====
-==== V3 ====
 ==== Directed Conceptual Design ====
@@ Linia 123: / Linia 74: @@
 Kody w PROOGu, kod .dot i rysunki ARD/TPH i XTT wygenerowane przez VARDA dostępne dodatkowo pod linkiem poniżej
-{{:pl:miw:miw08_ardcase_cs:vendingmachine_v3.pl|Kod w PROLOGu}}
+{{:pl:miw:miw08_ardcase_cs:elevator.pl|Kod w PROLOGu}}
-{{:pl:miw:miw08_ardcase_cs:vendimgmachine-ard_v3.dot|Plik .dot ARD}}
+{{:pl:miw:miw08_ardcase_cs:elevator-ard.dot|Plik .dot ARD}}
-{{:pl:miw:miw08_ardcase_cs:vendimgmachine-tph_v3.dot|Plik .dot TPH}}
+{{:pl:miw:miw08_ardcase_cs:elevator-tph.dot|Plik .dot TPH}}
 === Full ARD Model ===
@@ Linia 133: / Linia 84: @@
 ARD:
-<graphviz file="pl:miw:miw08_ardcase_cs:vendimgmachine-ard_v3.dot">
+<graphviz file="pl:miw:miw08_ardcase_cs:elevator-ard.dot">
 </graphviz>
 TPH:
-<graphviz file=":pl:miw:miw08_ardcase_cs:vendimgmachine-tph_v3.dot">
+<graphviz file="pl:miw:miw08_ardcase_cs:elevator-tph.dot">
 </graphviz>
-==== Refined Conceptual Design ====
-==== V2 ====
-==== Directed Conceptual Design ====
-Kody w PROOGu, kod .dot i rysunki ARD/TPH i XTT wygenerowane przez VARDA dostępne dodatkowo pod linkiem poniżej
-{{:pl:miw:miw08_ardcase_cs:vendingmachine_v2.pl|Kod w PROLOGu}}
-{{:pl:miw:miw08_ardcase_cs:vendingmachine-ard_v2.dot|Plik .dot ARD}}
-{{:pl:miw:miw08_ardcase_cs:vendingmachine-tph_v2.dot|Plik .dot TPH}}
-=== Full ARD Model ===
-ARD:
-<graphviz file="pl:miw:miw08_ardcase_cs:vendingmachine-ard_v2.dot">
-</graphviz>
-TPH:
-<graphviz file="pl:miw:miw08_ardcase_cs:vendingmachine-tph_v2.dot">
-</graphviz>
-==== Refined Conceptual Design ====
-==== V1 ====
-==== Directed Conceptual Design ====
-Kody w PROOGu, kod .dot i rysunki ARD/TPH i XTT wygenerowane przez VARDA dostępne dodatkowo pod linkiem poniżej
-{{:pl:miw:miw08_ardcase_cs:vendingmachine.pl|Kod w PROLOGu}}
-{{:pl:miw:miw08_ardcase_cs:vendingmachine-ard.dot|Plik .dot ARD}}
-{{:pl:miw:miw08_ardcase_cs:vendingmachine-tph.dot|Plik .dot TPH}}
-http://student.agh.edu.pl/~makamin/MiW/Graph/biletomat/
-=== Full ARD Model ===
-ARD:
-<graphviz file="pl:miw:miw08_ardcase_cs:vendingmachine-ard.dot">
-</graphviz>
-TPH:
-<graphviz file="pl:miw:miw08_ardcase_cs:vendingmachine-tph.dot">
-</graphviz>
 ==== Refined Conceptual Design ====
@@ Linia 206: / Linia 98: @@
 ===== Structuralization =====
@@ Linia 218: / Linia 105: @@
-==== V3 ====
-{{:pl:miw:miw08_ardcase_cs:vendimgmachine-xtt_v3.dot|Plik .dot XTT}}
-XTT:
-<graphviz file="pl:miw:miw08_ardcase_cs:vendimgmachine-xtt_v3.dot">
-</graphviz>
-Plik HQED http://student.agh.edu.pl/~makamin/MiW/XTTML/vendingmachine-xttml_v3.xttml
-==== V2 ====
-{{:pl:miw:miw08_ardcase_cs:vendingmachine-xtt_v2.dot|Plik .dot XTT}}
-XTT:
-<graphviz file="pl:miw:miw08_ardcase_cs:vendingmachine-xtt_v2.dot">
-</graphviz>
-Plik HQED http://student.agh.edu.pl/~makamin/MiW/ARD%20XTT/biletomat/vendingmachine.svg
@@ Linia 247: / Linia 110: @@
 ==== V1 ====
-{{:pl:miw:miw08_ardcase_cs:vendingmachine-xtt.dot|Plik .dot XTT}}
+{{:pl:miw:miw08_ardcase_cs:elevator-xtt.dot|Plik .dot XTT}}
-{{:pl:miw:miw08_ardcase_cs:miw-vendingmachine-xtt.pdf|Nieoficjalna (bez użycia HqEd) wersja XTT}}
 XTT:
-<graphviz file="pl:miw:miw08_ardcase_cs:vendingmachine-xtt.dot">
+<graphviz file="pl:miw:miw08_ardcase_cs:elevator-xtt.dot">
 </graphviz>
+Plik HQED {{:pl:miw:miw08_ardcase_cs:elevator-xttml.xttml|XTTML}}
-==== V0 - opis ogólny ====
-Wynikowe działanie biletomatu zależy od następujących rzeczy:
-- co zostało wybrane (jaka akcja)
-- czy wpłacono odpowiednią kwotę
-- fizyczna możliwość wypłaty (czy jest tusz do drukowania/pieniądze do wydania reszty)
 ===== Ostatnie zmiany =====
-.04.2008 - od poprzedniej wersji ARD/XTT (v1) przy użyciu nowej wersji VARDA wygenerowano poprawione ARD, a za pomocą HQed XTT (v2). Ważne - w wersji v1 w tabelach reguł występowały działania, które należało wyeliminować. W tym celu wprowadzono nowy atrybut - reszta. Po zmianach okazało się, iż aby wyliczyć, w jakiej kwocie należy wydać resztę należy odjąć atrybut - cena produktu (priceList[chosenProduct]), od atrybutu wpłacona przez klienta kwota (remittance). Reszta=wpłata-cena. Tak powstały atrybut należy dalej wykorzystać do sprawdzenia, czy biletomat posiada środki do wydania reszty. Powoduje to porównanie atribute2atribute, które może zostać zapisane niejednoznacznie tj. gdy fundsInMachine<change lub change>fundsInMachine atrybut enoughCashToChange jest prawdą, aby nie powodować reguł redundantnych koniecznym wydaje się przyjęcie jednolitej konwencji np w postaci ustalania jednego (np. skrajnie prawego w tabeli) jako dowolnego/stałego i dopasowywanie prawego jako większego/mniejszego niż prawy. Pytanie co stanie się przy większej ilości atrybutów
+.05.2008 - wersja końcowa, usunięcie linków zewnętrznych, dodanie kopii lokalnych
-.05.2008 - modyfikacja modelu, nowe ARD,XTT - na chwile obecna link do strony, wieczorem wklejenie localcopy etc
-.05.2008 - poprawa(uaktualnienie) opisu, dodanie kopii lokalnych plików, usunięcie starych uwag, dodanie nowych uwag do sprawozdania
+.05.2008 - Dopisanie / zmiana opisu, dodanie ARD/XTT

pl/miw/miw08_ardcase_cs/winda.1211225542.txt.gz · ostatnio zmienione: 2019/06/27 15:59 (edycja zewnętrzna)

Pokaż stronę Poprzednie wersje

Menadżer multimediów Do góry

AIwiki

Menu

Dla Studentów

Old specialized AI courses

SMaDA/SMaIDA/AIDA

Informatyka (EAIiIB)

Studia Dr

Inne materialy dydaktyczne

Archiwum

Dyplomanci

Geist Season of Code

HeKatE

Public

Różnice