System informatyczny wspomagający obsługę firmy prowadzącej gry losowe

Dokumentacja projektowa

Wersja pierwsza

Spis treści

Prowadzący: dr inż. Grzegorz Bliźniuk

Grupa laboratoryjna: I0Y3S1

Zespół wytwórczy 18/2012/GB

Nazwa roli	Nazwisko i imię
Zamawiający / Kierownik projektu	Skłodowski Radosław
Analityk / Projektant	Stuczyński Robert
Analityk / Tester akceptacyjny	Sobczak Michał
Projektant / Tester wewnętrzny	Sokołowski Michał
Tester akceptacyjny / Metodolog	Rudalski Rafał

Przydział zadań:

Skłodowski Radosław	Interfejsy użytkownika, Optymalizacja systemu, Protokoły komunikacyjne, Projekt bazy danych
Stuczyński Robert	Diagramy wdrożeniowe, Protokoły komunikacyjne, Optymalizacja systemu,
Sobczak Michał	Rozbudowany diagram klas, Optymalizacja systemu, Plan testów, Diagramy wdrożeniowe
Sokołowski Michał	Projekt bazy danych, Protokoły komunikacyjne, Plan testów, Interfejsy użytkownika
Rudalski Rafał	Harmonogram implementacji, Plan testów, Podsumowanie, Projekt bazy danych

1. Wstęp

Niniejszy dokument opisuje fazę projektową systemu informatycznego tworzonego dla firmy "G4mbler”. Celem tej fazy jest opracowanie szczegółowego opisu implementacji systemu. Rozstrzyga ona kwestie jak zbudowany ma być system, aby zrealizować wszystkie wymagania określone w fazach poprzedzających. W dokumencie opisane zostały wszystkie szczegóły, zwłaszcza szczegóły techniczne, o które wzbogacony został model systemu, tak aby był jak najbardziej wydajny, niezawodny i łatwy w konserwacji.

2. Diagram klas

Diagram klas fazy analizy przedstawiał bardzo uproszczony, poglądowy zbiór klas, na które składa się nasz system informatyczny. Diagram utworzony w fazie projektowania jest rozszerzeniem diagramu z fazy analizy. Nie tylko przedstawia relację pomiędzy klasami:

• Asocjacje

• Agregacje

• Kompozycje

• Generalizacje

ale także wszystkie potrzebne zmienne (atrybuty klas) oraz funkcje składowe (metody).

3. Projekt bazy danych

1. Model konceptualny

2. Definicje

Encje:

• Osoba: jest encją abstrakcyjną dziedziczą z niej encje klienta i pracownika oraz ich historie
  Zawiera podstawowe informacje dotyczące osoby takie jak: imię, nazwisko, adres,
  nr telefonu itp.

• Klient: jest uszczegółowieniem osoby, zawiera dodatkowe informacje o ilości gotówki na koncie klienta które może wykorzystać do swoich gier.

• Klient Historia: jest uszczegółowieniem osoby zawiera informację o tym kiedy klient został usunięty. Głównym celem tej encji jest przechowywanie przez określony czas usuniętych kont użytkowników aby można je było w szczególnym przypadku przywrócić oraz dla celów statystycznych.

• Pracownik: jest uszczegółowieniem osoby, zawiera dodatkowe informacje o jego zarobkach wyrażanych w PLN/godz., dacie zatrudnienia oraz numerze konta bankowego na który przelewana będzie jego wypłata.

• Pracownik Historia: analogicznie do Pracownika, zawiera dodatkowo informację o dacie jego zwolnienia. Dane zwolnionych/usuniętych pracowników przechowywane są do celów statystycznych lub w razie ewentualnego ich przywrócenia.

• Stanowisko: zawiera informacje o nazwie stanowiska, jego krótki opis a także 4 pola boolowskie określające dostęp do poszczególnych funkcji systemu. Takie rozwiązanie umożliwia tworzenie stanowisk posiadających różne uprawnienia.

• Obecności: encja przechowuje informacje o poszczególnych obecnościach pracownika w pracy, datę i godzinę rozpoczęcia pracy oraz zakończenia.

• Operacje Klient: przechowuje informacje o wszystkich operacjach wpłat i wypłat na konto klienta. Kwota może przyjmować wartości zarówno dodatnie(dla wpłat) jak i ujemne(dla wypłat) .

• Operacje KlientH: przechowuje operacje usuniętych klientów. Informacje te są przechowywane na wypadek przywrócenia klienta.

• Kasa Kasyna: Przechowuje informacje o stanie kasy kasyna. Umożliwia przechowywanie wielu stanów które są identyfikowane poprzez datę która jest parametrem obowiązkowym.

• Urządzenie: zawiera podstawowe informacje o urządzeniu takie jak nazwa, producent, stan, lokacja, datę zakupu. Stan urządzenia określać może czy jest sprawne, uszkodzone, wyłączone itp. Lokacja określa położenie urządzenia na terenie kasyna.

• Urządzenie Historia: analogicznie do urządzenia. Zawiera dodatkowo informacje o dacie jego usunięcia, usunięto informację o stanie oraz jego lokacji. Informacje o stanie i lokacji są zbędne skoro urządzenia nie ma fizycznie w kasynie. Cel istnienia encji to dane statystyczne oraz możliwość późniejszego przywrócenia urządzenia.

• Typ Urządzenia: zawiera informacje dotyczące typów urządzeń takie jak nazwa oraz opis typu urządzenia.

• Gra: zawiera informacje o dacie rozpoczęcia gry a także o jej wyniku(jeżeli jest dodatni tzn. że klient wygrał grę, ujemna gdy przegrał). Encja jest w relacji z klientem i urządzeniem dlatego fizyczna tabele w bazie będzie przechowywać klucze obce klienta i urządzenia w celu zidentyfikowania kto i na jakim urządzeniu przeprowadzał grę.

Asocjacje

• Obsługa Urządzenia: jest asocjacją pomiędzy Urządzeniem a pracownikiem. Zawiera informacje dotyczące daty przeglądu oraz ewentualne uwagi.

Uwagi

• W przypadku usuniętych klientów bądź urządzeń, informacje o ich grach nadal są przechowywane w encji Gra. W bazie danych będzie istniał mechanizm(trigger) uniemożliwiający nadanie PESELU oraz IDUrządzenia nowym urządzeniom jeżeli należały one do wcześniej istniejących klientów lub urządzeń ( chyba że informacje o usuniętych klientach lub urządzeniach zostaną usunięte o czym mowa jest w następnym punkcie). Dzięki temu będzie można sprawdzić na jakim urządzeniu grał klient nawet jeżeli zostało ono usunięte.

• Historia klienta może zostać usunięte po określonym czasie określonym przez administratora lub na szczególną prośbę klienta. W przypadku jeżeli usunięta zostanie historia użytkowników wszystkie gry które on rozegrał zostają automatycznie usunięte z bazy danych.

4. Optymalizacja systemu

Naszą aplikację zdecydowaliśmy się pisać w języku C++, wykorzystując maksymalnie możliwości, jakie daje podejście obiektowe. Aby ograniczyć wykorzystanie zasobów sprzętu, na jakim aplikacja będzie uruchamiana, zwracaliśmy szczególną uwagę na wykorzystanie odpowiednio minimalistycznych typów danych. Możliwości języka są odpowiednie dla naszego celu, ponadto dodawanie nowych funkcjonalności w przyszłości będzie stosunkowo proste (nawet dodawanie modułów pisanych w innych językach). Co bardzo istotne, język C++ oferuje możliwość używania funkcji wplatanych, których wykorzystanie w zauważalny sposób wpływa na wydajność aplikacji. W każdym przypadku będzie używany algorytm o możliwie najniższej złożoności (wyłączając przypadki, gdzie bardziej złożony algorytm będzie znacznie bardziej odpowiedni dla konkretnego działania).

W kilku przypadkach postanowiliśmy wykorzystać język Assembler, ze względu na istotność tych konkretnych funkcji, ale przede wszystkim ze względu na znaczną różnicę w wydajności obu języków. Oczywiście fragmenty w tym języku nie będą zbyt obszerne, gdyż ich pisanie zajęłoby zbyt dużo czasu, a usuwanie ewentualnych błędów byłoby niezwykle trudne. Assembler zostanie więc zastosowany wyłącznie w krytycznych punktach projektu, gdzie istotnie można podnieść wydajność.

Ponieważ aplikacja korzysta z bazy danych, która sama w sobie nie jest rozwiązaniem idealnym, zastosujemy indeksy. Wspomagają one w znaczący sposób wyszukiwanie i przyspieszają je, szczególnie przy dużej liczbie rekordów w bazie.

Projektując aplikację mamy na uwadze moc obliczeniową sprzętu, na jakim przyjdzie jej pracować, przy czym w każdym możliwym przypadku stawiamy na obniżenie złożoności obliczeniowej naszego kodu. Zdajemy sobie sprawę, że takie minimalistyczne podejście pozwoli na sprawne i szybkie działanie aplikacji, a ponadto pozostawi wolne zasoby na nieprzewidziane zdarzenia i przyszłe modyfikacje aplikacji.

5. Interfejs użytkownika

1. Okno logowania

Każdy z użytkowników zaczyna pracę od wprowadzenia swoich danych do logowania, przy czym może się ono odbywać poprzez wpisanie loginu i hasła lub też użycie karty pracowniczej wraz z hasłem. Zalecane jest używanie karty pracowniczej. W trosce o bezpieczeństwo hasło pojawia się w formie gwiazdek symbolizujących pojedynczy znak.

Gracz loguje się do systemu używając swojej karty na stanowisku z grą, z której aktualnie korzysta - wówczas zostaje zalogowany automatycznie.

W przypadku użycia karty, użytkownika wita następujący interfejs:

2. Interfejs pracownika

W przypadku identyfikacji użytkownika jako Pracownik, interfejs aplikacji wygląda następująco:

Z tego poziomu dostępne są wyłącznie opcje, do używania których uprawniony jest Pracownik. Dla maksymalizacji wygody i czytelności interfejsu zostały użyte zakładki.

Dostępne opcje, zgodnie z zakładanymi funkcjonalnościami:

• Przeglądanie graczy

• Edycja Graczy

• Dodawanie gracza ( z możliwością jednoczesnego wydania karty gracza)

• Usuwanie gracza

• Tworzenie karty gracza

• Usuwanie karty gracza z bazy

• Blokada karty

• Doładowanie karty gracza

• Pobór środków

1. Interfejs kierownika

Interfejs kierownika prezentuje się podobnie, jednakże zawiera inne opcje. Są to:

• Przeglądanie pracowników

• Edycja pracowników

• Dodawanie pracownika ( z możliwością jednoczesnego wydania karty pracownika)

• Usuwanie pracownika

• Zarządzanie listą obecności

• Podgląd kapitału

• Dodanie salda

• Generowanie raportu

• Generowanie zestawienia zysków

• Przegląd urządzeń

• Dodanie urządzenia

• Usunięcie urządzenia

• Edycja danych urządzenia

1. Interfejs właściciela

Właściciel ma dostęp do wszystkich funkcjonalności swoich pracowników, a ponadto ma możliwość oglądania generowanych dla niego raportów.

2. Okno pomocy

Każdy z użytkowników systemu ma dostęp do pliku pomocy, w którym znajdzie potrzebne informacje do szybkiego i sprawnego obsługiwania potrzebnych funkcji.

3. Przykładowy interfejs gracza

Ze względu na różnorodność gier oferowanych w kasynie, interfejs gracza dla poszczególnych stanowisk będzie różnorodny. Jednakże każde z nich oferuje podobne opcje (pomijając opcje charakterystyczne dla gry):

• Logowanie (odczyt danych karty)

• Wyświetl stan konta gracza

• Ustal stawkę

• Wyjście

6. Protokoły komunikacyjne

W celu zapewnienia wymiany danych i informacji w naszej sieci potrzebne są protokoły komunikacyjne. Ponieważ firmowa sieć komputerowa ma być wewnętrzna i nie posiadać dostępu do internetu, komunikacja będzie odbywać się głównie poprzez sieć LAN.

Aplikacja musi się komunikować z bazą danych, która zawiera prawie wszystkie istotne do działania informacje. Komunikacja z bazami Microsoft SQL Server / Oracle będzie odbywała się z wykorzystaniem protokołu OLE DB lub ODBC. Odpowiednie połączenia zostaną zestawione na etapie wdrażania projektu.

7. Diagramy wdrożeniowe

1. Diagram komponentów

1. Gracz

Gracz łączy się z panelem urządzenia wprowadzając do czytnika kart swoją kartę gracza. W panelu urządzenia znajdują się wszystkie ustawienia użytkownika, w tym możliwość ustawienia stawki, za jaką będzie grał. Zostaje nawiązana komunikacja z bazą danych w celu sprawdzenia, czy gracz posiada taką kwotę, oraz zmiana stanu konta w przypadku wygranej lub przegranej.

Diagram komponentów dla gracza:

b) Pracownik

Podczas przesyłania danych aby zapewnić ich bezpieczeństwo wykorzystujemy szyfrowanie RSA. Baza danych są implementowane przez firmę Sybase i kompatybilne z bazą SQL Anywhere.

Przy aplikacji wyróżniono oddzielny komponent na graficzny interfejs użytkownika. GUI bowiem ma być niezależne od samej aplikacji. Dzięki temu obydwa komponenty będzie można rozwijać oddzielnie - zmiana jednego nie będzie pociągała za sobą zmiany drugiego. Ułatwia to modyfikowanie interfejsu zgodnie z oczekiwaniami osób korzystających z niego.

Pracownik ma specjalny komponent do zarządzania kartami graczy, który łączy się z bazą danych po wprowadzeniu karty gracza przy użyciu komponentu bazy danych, modyfikując ją o wprowadzone zmiany.

Diagram komponentów dla pracownika:

c) Kierownik

W diagramie komponentów dla kierowników są dodatkowo komponenty pracownik i raport. Generowany raport może być przeglądany bezpośrednio w aplikacji. Komponent pracownik daje możliwość zarządzania pracownikami. Posiada możliwość dodania, zmiany, usunięcia, bądź zlecenia wypłaty.

Również tutaj graficzny interfejs jest wydzielony z aplikacji.

Diagram komponentów dla kierownika:

1. Diagram rozlokowania

Diagramy rozlokowania zwane są też ogólnie diagramami wdrożeniowymi. Umożliwiają opis fizycznej alokacji poszczególnych komponentów aplikacji - na przykład w serwerowniach głównych, serwerowniach zapasowych, czy też miejscach użytkowania aplikacji na urządzeniach statycznych i urządzeniach mobilnych.

1. Gracz

Gracz łączy się z serwerem obsługi poprzez podanie karty do czytnika kart. Komunikacja między serwerami firmy odbywa się poprzez FastEthernet.

Serwer obsługi klienta łączy się z serwerem bazy danych przy prowadzaniu stawki, w celu sprawdzenia czy klient posiada taką kwotę, oraz przy rozpoczynaniu gry, aby wczytać ustawienia urządzenia. Ustawienia urządzeń tworzone są przez centralę. Wszystkie zmiany zapisywane są w bazie danych. Komputer centrali i serwer obsługi klienta są połączone z centralną bazą danych.

2. Pracownik

Pracownik doradztwa może łączyć się bazą danych centrali firmy poprzez zbiór protokołów TCP/IP. Może zarządzać kartami graczy (gracz wprowadza swoją kartę). Poprzez aplikację Klient.exe, Komputer pracownika łączy się z serwerem bazy danych, do DaneKlienta.db, oraz dokonuje modyfikacji.

100. Kierownik

Komputery zarządu stoją w siedzibie firmy, dlatego komunikacja odbywa się przez FastEthernet. Zarząd nie ma dostępu do systemu z zewnątrz. Komputer kierownika ma dostęp do baz danych raportów i pracowników serwera bazy danych.

8. Harmonogram implementacji

Budowa systemu informatycznego została podzielona na następujące etapy:

Implementacja bazy danych	Czerwiec 2012
Fizyczne lokowanie serwerów i łącz	Lipiec - Sierpień 2012
Implementacja klas systemowych	Sierpień - Wrzesień 2012
Implementacja pozostałych elementów systemu	Październik - Listopad 2012
Implementacja interfejsów użytkownika	Grudzień 2012
Testy wewnętrzne	Grudzień 2012
Wdrożenie	Styczeń 2013
Testy, zapełnianie bazy danych	Styczeń 2013
Start komercyjny	Luty 2013

9. Plan testów

a) Testowanie bazy danych

Tworzona baza danych zostanie przetestowana pod względem bezpieczeństwa oraz dbałości o niski poziom redundancji przechowywanych danych. Dostęp do wglądu w bazę danych powinien mieć tylko pracownik kasyna odpowiedzialny za daną sekcję, który ma również możliwość łatwej edycji zawartych w niej rekordów. W celu zabezpieczenia przed nieumyślnym skasowaniem danych sprawdzamy funkcjonalności odpowiedzialne za usuwanie danych z baz. Naszym zadaniem jest zbadanie wszystkich możliwości obejścia zabezpieczeń tego modułu oraz miejsc w poszczególnych aplikacjach, które łączą się z bazą danych, aby zapisane dane dostępowe do bazy były niedostępne do ewentualnego podglądu. Wykorzystane zostanie także narzędzie do automatyzowania procesu wykonywania zapytań testowych. W ten sposób system zarządzania bazą danych zostanie „zasypany” dużą liczbą zapytań. Dzięki temu zbadamy nie tylko poprawność, ale także odporność systemu na duży ruch.

b) Testowanie aplikacji przeznaczonych dla pracowników

Dzięki aplikacji przeznaczonej dla pracownika, ma on możliwość dodania, usunięcia oraz przeglądania danych zawartych w bazach oraz generacji raportów i operacji pieniężnych. Testując sprawdzamy odporność formularzy na wprowadzane dane. Ewentualne błędy, przy zapisie do bazy danych, mogłyby spowodować duże konsekwencje. Badamy odporność na wprowadzanie danych specyficznych, bądź danych, które w dane pole wprowadzone być nie powinny. Tego typu testy dotyczą każdej aplikacji. Należy ponadto sprawdzić, czy dane przesyłane między poszczególnymi stanowiskami pracowniczymi nie ulegają zniekształceniu bądź przekłamaniu.

c) Testowanie aplikacji dla klientów

Klient ma możliwość podejrzenia i edycji środków na swojej karcie gracza. Jest to aplikacja najbardziej narażona na ataki z zewnątrz, ponieważ jest dostępna dla praktycznie wszystkich użytkowników. Podobnie jak przy aplikacji pracowniczej sprawdzaliśmy aplikację w przypadkach wprowadzania złośliwych danych, które mogą spowodować incydenty bezpieczeństwa. Aplikacja jest narażona na specyficzne ataki, chociażby podrobienia id bądź hasła i wyczyszczenia środków na karcie. Sprawdzając każde pole formularza zabezpieczamy klientów przez kradzieżą tożsamości, a nawet danych dotyczących karty płatniczej, której używa. Trzeba sprawdzić mechanizm potwierdzeń przy operacjach. Na przetestowanie aplikacji należy przeznaczyć wiele czasu i możliwości. Trzeba wykorzystać narzędzia wspomagające testy i automatyzujące tworzenie szkodliwych żądań. Ponadto trzeba się upewnić, że wszystkie pliki, które nie mają być bezpośrednio dostępne dla użytkownika znajdują się poza katalogiem serwera odpowiadającym za przechowywanie ich danych.

d) Testowanie modułu przelewów

Moduł przelewów jest jedną ze składowych aplikacji przeznaczonej dla klientów oraz pracowników. Naszym zadaniem w tej fazie testów jest przetestowanie zabezpieczeń oraz reakcje na różne dane, które zostaną wpisane nieprawidłowo. Należy także sprawdzić, czy system banku prawidłowo reaguje na żądania projektowanego systemu, czy nie ma przekłamań w kwotach przelewów ani przy rozpoznawaniu użytkownika zlecającego przelew.

f) Testowanie systemu pomocy.

System pomocy zawiera zbiór pytań umożliwiających zidentyfikowanie problemu użytkownika oraz doradzenie mu odpowiedniego rozwiązania. Należy więc sprawdzić sposób doboru reguł przez mechanizm wnioskowania oraz działanie każdej reguły w różnych konkretnych przypadkach wymagających decyzji, rady czy opinii. Mechanizm należy przetestować pod względem łatwości obsługi oraz jednoznaczności odpowiedzi, tak aby użytkownik słabo zaznajomiony z systemem nie miał problemu z ustaleniem odpowiedzi na poszczególne pytania. Zmniejszy to możliwość przekazania do osoby zajmującej się konserwacją systemu problemu, który mógłby zostać rozwiązany za pomocą systemu pomocy.

10. Podsumowanie

Niniejszy dokument podsumowuje wszelkie aspekty dotyczące projektowania systemu i wszelkich innych czynności koniecznych do wykonania przed jego wdrożeniem. Przedstawione zostały kwestie dotyczące technicznej i wizualnej strony projektu. Dokument zawiera graficzne przedstawienie zbioru klas systemu oraz budowy baz danych. Ukazany został i opisany interfejs systemu dostępny dla poszczególnych jego użytkowników. Poruszone zostały zagadnienia dotyczące optymalizacji systemu, protokołów komunikacyjnych oraz testów poszczególnych modułów, wchodzących w skład projektowanego systemu. Dzięki temu system jest gotowy do implementacji nie pozostawiając wątpliwości co do budowy i wymagań funkcjonalnych.

[Dokumentacja analityczna systemu informatycznego]

Warszawa 2012

---