To jest stara wersja strony!


Analiza biletomatu i design

Wybrany przykład:

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: 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

V3

Directed Conceptual Design

Full ARD Model

Refined Conceptual Design

V2

Directed Conceptual Design

Chwilowo spakowane kody tutaj: http://student.agh.edu.pl/~makamin/MiW/ARD%20XTT/ jeśli będą dobrze to upload na wiki, żeby nie smiecić

TBC: JAK ZAPISAC zmienna++ w tabelach XTT? Czy trzeba wtedy inkrametowany atrybut dawać po obu stronach tabeli? Jak zrobić z autoryzacja, bo mam wrażenie, że tak jak teraz jest nie koniecznie jest dobrze ; Co z czerwonymi polami ; Jak sie definiuje dziedziny dla atrybutów

Full ARD Model

ARD:

XTT:

TPH:

XTT:

Wstępna wersja xtt (nie wrzucana na wiki, ponieważ jest wstępna) tutaj: http://student.agh.edu.pl/~makamin/MiW/Graph/biletomat/MiW-vendingmachine-xtt.pdf

Refined Conceptual Design

Physical Attribute Specification

Structuralization

Logical design

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

pl/miw/miw08_ardcase_cs/biletomat.1211217795.txt.gz · ostatnio zmienione: 2019/06/27 15:59 (edycja zewnętrzna)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0