To jest stara wersja strony!
Analiza biletomatu i design
Wybrany przykład:
Pozostałe przykłady
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
Stany wewnętrzne: ??
Elementy wiedzy: Akcja wybrana przez uzytkownika (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: Czas, DostepneSrodki(ile bankomat ma pieniedzy na reszte), WyborDzialania(bilet czy karta), WplaconeSrodki, FizycznaMozliwoscWyplaty(czy jest papier/tusz), Cennik, Dzialanie
Poziom 2: Czas + DostepneSrodki + WyborDzialania + WplaconeSrodki + FizycznaMozliwoscWyplaty + Cennik → Dzialanie
Poziom 3: finalizacje (TBC: nie wiem czemu nie zaszly?)
General Conceptual Design
V2
Directed Conceptual Design
Full ARD Model
Refined Conceptual Design
V1
Directed Conceptual Design
Full ARD Model
Refined Conceptual Design
Physical Attribute Specification
Structuralization
Logical design
Wynikowe dzialanie biletomatu zalezy od nastepujacych 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