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: ====
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 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
Kod w PROLOGu
Plik .dot ARD
Plik .dot TPH
=== Full ARD Model ===
ARD:
==== 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
Kod w PROLOGu
Plik .dot ARD
Plik .dot TPH
=== Full ARD Model ===
ARD:
==== 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
Kod w PROLOGu
Plik .dot ARD
Plik .dot TPH
http://student.agh.edu.pl/~makamin/MiW/Graph/biletomat/
=== Full ARD Model ===
ARD:
==== Refined Conceptual Design ====
===== Physical Attribute Specification =====
===== Structuralization =====
===== Logical design =====
==== V3 ====
Plik .dot XTT
XTT:
Plik HQED http://student.agh.edu.pl/~makamin/MiW/ARD%20XTT/biletomat/vendingmachine.svg
==== V1 ====
Plik .dot XTT
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 =====
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