====== 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) }} == 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: TPH: ==== 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: TPH: ==== 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: TPH: ==== Refined Conceptual Design ==== ===== Physical Attribute Specification ===== ===== Structuralization ===== ===== Logical design ===== ==== V3 ==== {{:pl:miw:miw08_ardcase_cs:vendimgmachine-xtt_v3.dot|Plik .dot XTT}} XTT: Plik HQED {{vendingmachine-xttml_v3.xttml|XTTML}} ==== V2 ==== {{:pl:miw:miw08_ardcase_cs:vendingmachine-xtt_v2.dot|Plik .dot XTT}} XTT: 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: ==== 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 fundsInMachinefundsInMachine 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