--- pl:miw:miw08_ardcase_cs:winda [2008/05/19 21:32]
miw
+++ pl:miw:miw08_ardcase_cs:winda [2008/05/24 13:31]
miw
@@ Linia 1: / Linia 1: @@
-====== Analiza różnych wind i design ======
-==== Wybrany przykład: ====
-P1: {{:pl:miw:miw08_ardcase_cs:elevator_example_in_uml.pdf|Example of elevator (local copy)}}
-== Pozostałe przykłady ==
-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}}
-==== 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 ====
-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.
-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**
-====== 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
-==== 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
-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ę.
-==== Original Rules ====
-Reguły:
-- Jeśli akcją jest zakup biletu to należy wybrać typ biletu
-- Jeśli akcją jest doładowanie karty to należy podać dane
-- Należy wpłacić pieniądze
-- Jeśli wpłacono to drukowanie biletu/wydanie reszty, jeśli nie to po pewnym czasie zwrot pieniędzy
-===== Analysis =====
-===== Conceptual design =====
-Poziom 0: Biletomat
-Poziom 1: Finalizacja Biletomatu na: Czas, Pieniądze, Dostępność, Aktywność biletomatu
-Poziom 2: Split: Czas -> Aktywność biletomatu, Pieniądze -> Aktywność biletomatu, Dostępność -> Aktywność biletomatu
-Poziom 3: Finalizacja Czas na : Czas obecny, Czas rozpoczęcia, przekroczenie limitu czasu
-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 ====
-==== V3 ====
-==== 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_v3.pl|Kod w PROLOGu}}
-{{:pl:miw:miw08_ardcase_cs:vendimgmachine-ard_v3.dot|Plik .dot ARD}}
-{{:pl:miw:miw08_ardcase_cs:vendimgmachine-tph_v3.dot|Plik .dot TPH}}
-=== Full ARD Model ===
-ARD:
-<graphviz file="pl:miw:miw08_ardcase_cs:vendimgmachine-ard_v3.dot">
-</graphviz>
-TPH:
-<graphviz file=":pl:miw:miw08_ardcase_cs:vendimgmachine-tph_v3.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 ====
-===== Physical Attribute Specification =====
-===== Structuralization =====
-===== Logical design =====
-==== 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
-==== V1 ====
-{{:pl:miw:miw08_ardcase_cs:vendingmachine-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>
-==== 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 - 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

pl/miw/miw08_ardcase_cs/winda.txt · ostatnio zmienione: 2019/06/27 15:50 (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