[[
✎ pl:miw:miw08_ardcase_cs:biletomat
]]
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ć.
====== Analiza biletomatu i design ====== ==== Wybrany przykład: ==== {{:pl:miw:miw08_ardcase_cs:tpa_b3osz_mmazur_-_automat.pdf|Well documented Vending Machine Model by T. Pałosz, M. Mazur (AiR IV) <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 24: Ręczne dodanie zależności cena -> pieniądze w biletomacie (konieczne do pomniejszenia ilości pieniędzy po ich wydaniu) Poziom 25: 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}} === 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 {{vendingmachine-xttml_v3.xttml|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 {{vendingmachine_v2.xttml|XTTML}} ==== 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 ===== 24.05.2008 - usunięcie linków zewnętrznych, dodane kopii lokalnych, drobne zmiany 28.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 18.05.2008 - modyfikacja modelu, nowe ARD,XTT - na chwile obecna link do strony, wieczorem wklejenie localcopy etc 19.05.2008 - poprawa(uaktualnienie) opisu, dodanie kopii lokalnych plików, usunięcie starych uwag, dodanie nowych uwag do sprawozdania
pl/miw/miw08_ardcase_cs/biletomat.txt
· ostatnio zmienione: 2019/06/27 15:50 (edycja zewnętrzna)
Pokaż stronę
Poprzednie wersje
Menadżer multimediów
Do góry