Analiza bankomatu i design
Introduction
Celem niniejszego opracowania jest próba zamodelowania bankomatu w ARD/XTT bazując na wiedzy ogólnej na temat budowy i zasady działania, oraz korzystania z bankomatu, dostępnych dokumentacjach, a przede wszystkim modelach UML systemu. Do stworzenia modelu, należy bazując na modelu UML wyszczególnić iterakcje pomiędzy zewnętrzem, a modelowanym systemem, wyodrębnienić wejścia i wyjścia modelowanego systemu (IMHO może to być zależne od przypadku użycia), następnie próba specyfikacji elementów wiedzy (w postaci atrybutów), na podstawie której działa system, oraz odnalezienia i opisania za pomocą zdefiniowanych atrybutów reguł według jakich działa system.
Wybrany przykład:
Pozostałe przykłady
Uzasadnienie wyboru i porównanie
Wybrałem przykład P1 ponieważ zawiera stosunkowo najwięcej opisu UML i jest merytorycznie najlepszy. Przykład P2 zawiera mniej diagramów UML, mniej danych o systemie, a przedstawione diagramy w mniejszym stopniu oddają specyfikę systemu. Przykład P3 zawiera diagramy UML, ale przedstawione tam diagramy wydają się być niekompletne i dobrane tak, aby tłumaczyć myśl główną zawartą w dokumencie tj. testowanie systemów.
Description
W przypadku podstawowym w bankomacie wyróżnić możemy dwa podstawowe przypadki użycia:
1. Zapytanie o saldo
2. Wypłata pieniędzy
Użycie bankomatu ogranicza się do dwóch akcji prezentowanych na use-case. Może to być zapytanie o saldo lub wypłata środków. Dla każdej z akcji trzeba się uwierzytelnić poprzez podanie PINu. PIN jest sprawdzany w bazie, jeśli jest poprawny praca jest kontynuowana, jeśli nie to następują kolejne próby, jeśli są udane - dalsza praca, jeśli nie karta jest zatrzymywana.
Dalsza praca polega na :
- dla zapytania o saldo na wypisaniu komunikatu
- dla wypłaty pieniędzy wybraniu z dostępnych lub podaniu niestandardowej kwoty, następnie sprawdzana jest ilość środków na koncie i jeśli są wolne środki lub limit kredytowy to sprawdzane jest, czy bankomat posiada środki, jeśli wszystko OK to wypłata i potwierdzenie, jeśli nie, to odpowiedni komunikat.
Możliwe działania wynikowe bankomatu - drukowanie potwierdzenia, wydawanie pieniędzy, zabranie karty, prośba o ponowne wprowadzenie PINu
Conceptualization
W niniejszym rozdziale następuje próba specyfikacji wejść, wyjść, atrybutów, oraz reguł w systemie
Vocabulary
Wejścia: PIN, decyzje podejmowane przez użytkownika na kolejnych ekranach (akcja, pożadana kwota)
Wyjście: Potwierdzenie/pieniądze/komunikat
Stany wewnętrzne: Uwierzytelnienie (jeśli wpisany PIN jest zgodny z PINem w bazie), Saldo (kwota wolnych środków na koncie klienta), Możliwość wypłaty(czy bankomat ma pożądana kwotę/banknoty)
Elementy wiedzy: Akcja wybrana przez użytkownika (dziedzina: saldo/wyplata), wpisany pin (dziedzina 0000-9999), uwierzytelnianie, saldo, pożądana kwota, czy istnieje możliwość wypłaty, czy bankomat posiada środki.
Original Rules
Reguły: Z wybranej akcji wynika jakie reguły stosować dalej.
Jeśli akcją jest zapytanie o saldo to najpierw należy się uwierzytelnić, po uwierzytelnieniu dla tej akcji następuje wypisanie na ekranie stanu konta, w przypadku błędnej autentyfikacji podejmowane mogą być kolejne próby, jednak po trzeciej nieudanej próbie karta jest zatrzymywana przez bankomat.
Jeśli akcją jest wypłata to pozostałe reguły.
Jeśli dobry PIN → kontynuacja
Jeśli zły → druga próba ; Jeśli dobry → Kontynuacja ; Jeśli zły → zabranie karty
Jeśli stan konta (+ ew.prowizja) lub karta debetowa → (autoryzowany użytkownik posiadający środki) możliwość wypłaty
Jeśli są pieniądze i możliwość wypłaty → wyplata pieniędzy/drukowanie potwierdzenia lub stan konta dla akcji sprawdzania konta
Po wypłacie należy zaktualizować ilość pieniędzy w bankomacie
Analysis
Conceptual design
Poziom 0: Bankomat
Poziom 1: Finalizacja Bankomatu na: Opcja menu, Autentyfikaja, Czy klient dysponuje środkami, Czy bankomat posiada środki, Aktywność bankomatu
Poziom 2: Split (ustalenie zależności): Opcja menu → Aktywność bankomatu,
Opcja menu → Aktywność bankomatu, Autentyfikaja → Aktywność bankomatu, Czy klient dysponuje środkami → Aktywność bankomatu, Czy bankomat posiada środki → Aktywność bankomatu
Poziom 3: Finalizacja Autentyfikacji: Podany PIN, PINwBanku, Ilość nieudanych prób, uwierzytelnienie
Poziom 4: Split (ustalenie zależności): Podany PIN → uwierzytelnienie , PINwBanku → uwierzytelnienie , Ilość nieudanych prób → uwierzytelnienie, Podany PIN → Ilość nieudanych prób, PINwBanku → Ilość nieudanych prób, uwierzytelnienie → Aktywność bankomatu, Ilość nieudanych prób→ Aktywność bankomatu
Poziom 5: Finalizacja Czy klient dysponuje środkami na: Pożądana kwota, Wolne środki, czy klient dysponuje środkami
Poziom 6: Split: Pożądana kwota → czy klient dysponuje środkami, Wolne środki → czy klient dysponuje środkami, czy klient dysponuje środkami → Aktywność bankomatu
Poziom 7: Finalizacja Aktywność bankomatu → aktywność bankomatu
Poziom 8: Finalizacja Czy bankomat posiada środki na: Ilość pieniędzy w bankomacie, (znacznik) Czy bankomat ma dostatecznie dużo środków
Poziom 9: Split: Ilość pieniędzy → Czy bankomat ma dostatecznie dużo środków, Czy bankomat ma dostatecznie dużo środków → Aktywność bankomatu
Poziom 10-17: Finalizacja Ilość pieniędzy → ilość pieniędzy, Czy bankomat ma dostatecznie dużo środków → czy bankomat ma dostatecznie dużo środków, Opcja menu → opcja menu, Pożądana kwota → pożądana kwota, Podany PIN → podany PIN, Wolne środki → wolne środki, PIN w bazie → PIN w bazie, Ilość nieudanych prób → ilość nieudanych prób
Poziom 18: Ręczne dodanie zależności (do poziomu 9) pożądana kwota → czy bankomat ma dostatecznie dużo środków
General Conceptual Design
V4
Directed Conceptual Design
Full ARD Model
ARD:
Refined Conceptual Design
V3
Directed Conceptual Design
Full ARD Model
ARD:
Refined Conceptual Design
V2
Directed Conceptual Design
Full ARD Model
ARD:
Refined Conceptual Design
V1
Directed Conceptual Design
Full ARD Model
Refined Conceptual Design
Physical Attribute Specification
Structuralization
Logical design
V4
V2
V0 - opis ogólny
Wynikowe działanie bankomatu zależy od następujących rzeczy:
- czy klient podał prawidłowy PIN (uwierzytelnienie)
- czy środki na koncie klienta są w stanie pokryć koszty transakcji (klient dysponuje środkami)
- życzenie klienta (wybrana akcja)
- fizyczna możliwość wypłaty (czy bankomat dysponuje pożądaną kwotą/odpowiednimi banknotami)
Uwierzytelnienie zależy od PINu zapisanego na karcie/w bazie banku, oraz PINu podanego przez klienta
To czy klient dysponuje środkami zależy od pożądanej przez klienta kwoty, oraz stanu jego konta
Tak powstałe reguły powinny być opisane w taki sposób aby otrzymane tabele były zupełne
CASE
Ze względów projektowych trzeba było dodawać zależności ręcznie (abstrahując, że i tak koncepcja później została zmieniona) pojawiły się dwie tabele o identycznych warunkach (czemu nie zostały połączone?). Fakt nie były od początku projektowane jako jedna tabela o danych warunkach i dwóch konkluzjach (ale wynikło to z projektu, gdzie jedna z konkluzji była wywiedziona od innego atrybutu)
Kod w PROLOGu
Plik .dot ARD
Plik .dot TPH
Plik .dot XTT
Plik .dot XTTML
<graphviz file=„pl:miw:miw08_ardcase_cs:cashpoint_case-xtt.dot”>
</graphviz>
Ostatnie zmiany
26.05.2008 - dodanie case opisywanego w sprawozdaniu ; dodanie v4 - podczas dogrywania case autor zauważył brak uaktualniania atrybutu numberOfBills (o nieco mylącej nazwie - reprezentującego ilość pieniędzy w banknotach w bankomacie), zostało to poprawione w wersji v4
24.05.2008 - uporządkowanie, usunięcie linków zewnętrznych i zastąpienie lokalnymi, drobne zmiany
28.04.2008 - drobne modyfikacje modelu, użycie nowej wersji VARDA, oraz użycie HQED
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