Praca dyplomowa inżynierska

(1)

Wydział Informatyki i Zarządzania kierunek studiów: Informatyka

Praca dyplomowa – inżynierska

System webowy do tworzenia i rozgrywania paragrafowej gry detektywistycznej

Natalia Gałda Aldona Pieniążek

słowa kluczowe:

Detektywistyczna gra Aplikacja webowa

Paragrafowa krótkie streszczenie:

Paragrafowa gra detektywistyczna zrealizowana za pomocą aplikacji webowej.

Gracze mają możliwość nie tylko rozgrywania spraw detektywistycznych, ale również ich tworzenia. Celem gry jest rozwiązanie sprawy detektywistycznej z wykorzystaniem opisów odkrywanych komponentów oraz mechanizmu dedukcji. Kolejne komponenty odkrywane są poprzez wykonanie akcji o z góry określonym koszcie, wyrażonym za pomocą jednostki gry - Punktów Ruchu. Na rozwiązanie każdej sprawy gracz ma ograniczoną liczbę dni, a w ramach dnia ograniczoną liczbę Punktów Ruchu.

opiekun pracy dyplomowej

………. ... ...

Tytuł/stopień naukowy/imię i nazwisko ocena podpis

Ostateczna ocena za pracę dyplomową

Przewodniczący Komisji egzaminu

dyplomowego

...

Tytuł/stopień naukowy/imię i nazwisko

... ...

ocena podpis

Do celów archiwalnych pracę dyplomową zakwalifikowano do:*

a) kategorii A (akta wieczyste)

b) kategorii BE 50 (po 50 latach podlegające ekspertyzie)

* niepotrzebne skreślić

pieczątka wydziałowa

Wrocław

2020

(2)

Streszczenie

Celem pracy jest stworzenie systemu webowego umożliwiającego tworzenie i rozgrywanie paragrafowej gry detektywistycznej. Wytworzenie produktu wymagało zapoznania się z rynkiem gier detektywistycznych, stosowanych mechanik gier oraz przeglądu odpowiednich rozwiązań technologicznych. W pracy przedstawiono koncept rozgrywki oraz szczegółowy projekt aplikacji. Poruszono również wybrane aspekty implementacji, w tym uzyskane efekty i rozwiązane problemy. Zawarto także opis i wyniki przeprowadzonych testów użyteczności.

Przygotowane rozwiązanie zawiera podstawowe funkcjonalności zapewniające grywalność. W ramach realizowanego projektu nakreślono jednak szerokie plany rozwojowe.

Abstract

The main purpose of this engineer thesis was developing a web-based system for creating and playing a paragraph driven detective game. Creating the product required gaining knowledge about the field of detective games, mechanics used within games in general and technologies appropriate for the development. The paper describes the games concept and detailed application design. Encountered difficulties and the result of implementation were also presented. In addition, the description and results of tests of usability where shown. The solution prepared within this thesis consists of basic functionalities necessary for obtaining a satisfactory gameplay experience. However broad plans for growth of the product were outlined.

(3)

Spis treści

WSTĘP ... 1

1. ANALIZA RYNKU ... 2

1.1. UMIEJSCOWIENIE PRODUKTU NA RYNKU ... 2

1.2. PRZEGLĄD ISTNIEJĄCYCH ROZWIĄZAŃ ... 2

1.2.1. ROZWIĄZANIA CYFROWE ... 2

1.2.2. ROZWIĄZANIA PLANSZOWO-KOMIKSOWE ... 3

1.2.3. ROZWIĄZANIE HYBRYDOWE ... 3

2. PROJEKT ... 4

2.1. KONCEPT ROZGRYWKI ... 4

2.2. WYMAGANIA FUNKCJONALNE I NIEFUNKCJONALNE ... 5

2.3. DIAGRAM PRZYPADKÓW UŻYCIA ... 8

2.4. SPECYFIKACJA PRZYPADKÓW UŻYCIA ... 9

2.5. DIAGRAM KLAS [N.G.] ... 28

2.6. REGUŁY BIZNESOWE ... 30

2.7. ARCHITEKTURA SYSTEMU ... 30

2.7.1. DIAGRAM PAKIETÓW CZĘŚCI SERWEROWEJ [N.G.]... 31

2.7.2. DIAGRAM PAKIETÓW CZĘŚCI KLIENCKIEJ [A.P.]... 32

2.7.3. DIAGRAM ROZMIESZCZENIA ... 34

2.7.4. DIAGRAM ZWIĄZKÓW ENCJI ... 36

2.8. DIAGRAMY SEKWENCJI PRZYPADKÓW UŻYCIA... 42

2.9. INTERFEJS [A.P.] ... 42

3. INTERFEJS UŻYTKOWNIKA [A.P.] ... 51

3.1. CZĘŚĆ ROZGRYWKI ... 54

3.2. CZĘŚĆ TWORZENIA ... 58

4. INTERFEJS USŁUG SERWERA [N.G.] ... 62

5. IMPLEMENTACJA ... 64

5.1. ŚRODOWISKO I NARZĘDZIA PROGRAMISTYCZNE ... 64

5.2. UŻYTE BIBLIOTEKI ... 64

5.2.1. SERWER [N.G.] ... 64

5.2.2. KLIENT [A.P.] ... 65

5.3. WZORCE PROJEKTOWE I DOBRE PRAKTYKI PROGRAMISTYCZNE ... 66

5.3.1. SERWER [N.G.] ... 66

5.3.2. KLIENT [A.P.] ... 70

5.4. PROBLEMY IMPLEMENTACYJNE ... 72

5.4.1. SERWER [N.G.] ... 72

5.4.2. KLIENT [A.P.] ... 75

5.5. TESTOWANIE INTERFEJSU [A.P.] ... 80

5.6. PLANY ROZWOJU SYSTEMU ... 82

6. PODSUMOWANIE ... 84

BIBLIOGRAFIA ... 85

(4)

Spis pojęć

• Akcja – opcjonalna czynność, o określonym koszcie punktów ruchu, która może skutkować odkryciem komponentu

• Akcja początkowa – pierwsza akcja w sprawie; definiowana przez twórcę;

uruchamiana automatycznie przy rozpoczęciu rozgrywania sprawy

• API – „zbiór reguł ściśle opisujący, w jaki sposób programy lub podprogramy komunikują się ze sobą” [1]

• Gotowa sprawa – utworzona przez użytkownika sprawa, posiadająca status gotowej; inni gracze mogą rozegrać taką sprawę

• Grywalność – „ogół zasad i mechanizmów gry komputerowej, które wpływają na jakość i przyjemność z gry. Na grywalność składają się takie elementy, jak: fabuła, logiczny schemat powiązań elementów występujących w grze, zasady rozgrywki, liniowość rozgrywki” [2]

• Komponent – składowa sprawy; wyróżniamy następujące: przedmiot, osoba, miejsce, akcja

• Kreator Spraw – część aplikacji pozwalająca na tworzenie własnej sprawy detektywistycznej

• Następnik – komponent odkrywany w następstwie wykonywania akcji

• Punkty Ruchu – jednostka pozwalająca na wykonanie akcji, podróżowanie oraz badanie przedmiotów

• Punkty Stresu – jednostka reprezentująca punkty ujemne wpływające na wynik końcowy rozgrywania sprawy

• Sprawa – zbiór komponentów oraz powiązań między nimi, tworzący rozgrywkę i zakończony testem

• Tag – słowo lub fraza; dodawana w celu znalezienia i grupowania elementów

• Test końcowy – test jednokrotnego wyboru, będący ostatnim etapem gry

• Zakończona sprawa – sprawa dla której gracz rozwiązał test końcowy

(5)

1

Wstęp

Już od czasów starożytnych gry są obecne w kulturze. Jedną z najwcześniejszych znanych gier planszowych jest Senet [3], gra o charakterze wyścigowym, w którą grali starożytni Egipcjanie. Również oni, według Tristana Donovana, wierzyli, że rozgrywki o charakterze

„rytualnym” pozwalają przelotnie zobaczyć życie pozagrobowe [4]. Obecnie zaś, zarówno dzieci, jak i dorośli, grają w gry planszowe. Rozwijają one zdolność rozwiązywania problemów, strategicznego myślenia, a także pomagają zachować sprawną pamięć u starszych osób [5].

Wraz z rozwojem technologii zaczęły powstawać pierwsze gry komputerowe. Pierwszą rozpowszechnioną grą był Pong, prosta gra polegająca na odbijaniu piłki [6]. Zapoczątkowało to powstanie różnego typu automatów i konsol, a następnie komputerów osobistych. Z czasem stawały się one coraz bardziej złożone. Wprowadzono stale ewoluującą grafikę trójwymiarową, dzięki czemu jeszcze bardziej zyskały na popularności.

Gry planszowe również skorzystały z rozwoju technologii. Wiele z obecnych na rynku gier korzysta z aplikacji mobilnych, desktopowych czy webowych jako wsparcie dla gracza. W grze Alchemicy, której autorem jest Matúš Kotry, gracze mogą używać aplikacji mobilnej do sprawdzania wyniku uwarzonej mikstury. Aplikacja nie jest konieczna do rozgrywki, natomiast w takim wypadku jeden z graczy nie bierze czynnego udziału w grze.

Niektórzy projektanci gier planszowych poszli o krok dalej i zaczęli wydawać gry, do których aplikacja webowa czy mobilna jest niezbędna do rozgrywki. Jedna z takich gier stała się inspiracją do stworzenia opisywanego w niniejszej pracy systemu. Zdecydowano się jednak całkowicie przenieść ją do świata wirtualnego.

Celem pracy jest stworzenie systemu webowego umożliwiającego tworzenie i rozgrywanie paragrafowej gry detektywistycznej.

Zakres pracy obejmuje projekt części klienckiej i serwerowej systemu oraz bazy danych, opracowanie mechaniki gry oraz implementację serwera i klienta webowego, zapewniających swobodę przy tworzeniu własnych scenariuszy i ich pełną grywalność.

Rozdział pierwszy poświęcony jest analizie rynku i określeniem głównych cech produktu, w celu umiejscowienia go na rynku gier. W kolejnym rozdziale zdefiniowano wymagania użytkowników i przedstawiono projekt systemu obejmujący koncept mechaniki gry, architekturę systemu i jego projekt wizualny. Rozdział trzeci przedstawia zaimplementowany na podstawie projektu interfejs użytkownika. Poruszony został także temat responsywności aplikacji. Następny rozdział opisuje komunikację między częścią serwerową, a kliencką systemu. W rozdziale piątym opisano implementację systemu – użyte narzędzia i biblioteki, wykorzystane wzorce projektowe. Przedstawiono problemy, z jakimi zetknięto się w trakcie implementacji oraz opisano plany rozwoju aplikacji. Rozdział szósty stanowi podsumowanie całej pracy.

Niniejsza praca jest autorstwa dwóch osób. W związku z tym, rozdziały i podrozdziały mogą być oznaczone przypisem [N.G.] lub [A.P.], wskazującym na autora oznaczonej części.

[N.G.] – Natalia Gałda [A.P.] – Aldona Pieniążek

Brak przypisu wskazuje na dwóch autorów.

(6)

2

1. Analiza rynku

We wstępie pracy przedstawiono gry planszowe jako formę rozrywki, pozwalającą wspólnie spędzić czas. Nawet w przypadku, w którym podczas rozgrywki korzystamy ze wsparcia aplikacji webowych czy mobilnych, najistotniejszy jest fakt bezpośredniego kontaktu ze współgraczami.

Niektóre gry karciane błędnie nazywa się grami planszowymi. Wynika to z faktu braku odpowiedniego terminu w języku polskim (używane jest określenie gier bez prądu, natomiast, jak zostanie to przedstawione w tym rozdziale, dalej nie obejmuje ono wszystkich możliwych gier). W języku angielskim istnieje termin „tabletop games”, co w tłumaczeniu na język polski może oznaczać „gry stołowe”. Obejmuje on więc gry, w trakcie których gracze (głównie) siedzą przy jednym stole, tzn. gry planszowe, karciane, bitewne, RPG.

1.1. Umiejscowienie produktu na rynku

Produkt, mimo całkowitej cyfryzacji, zakwalifikowano do typu „tabletop games”. Nic nie stoi na przeszkodzie, aby użytkownicy grali w nią samotnie, natomiast grupą docelową produktu są osoby zaznajomione z grami planszowymi i chętne do przeniesienia „planszy” do świata wirtualnego. Podobny zabieg zastosowano w grach przedstawionych w przeglądzie istniejących rozwiązań w kategorii rozwiązań hybrydowych. Ważnym aspektem produktu jest jego charakter dedukcyjny. Rozwiązanie zagadki będzie wymagało od graczy łączenia faktów.

1.2. Przegląd istniejących rozwiązań

Na rynku istnieje wiele gier paragrafowych, wiele gier detektywistycznych oraz, już nie tak wiele, paragrafowych gier detektywistycznych. W przeglądzie pominięte zostały gry tylko paragrafowe. Ze względu na liczbę istniejących rozwiązań podzielono je na trzy kategorie:

cyfrowe, planszowo-komiksowe i hybrydowe (łączące cechy dwóch pierwszych typów).

1.2.1. Rozwiązania cyfrowe

Gry detektywistyczne jako rozwiązania cyfrowe to głównie gry typu point-and-click.

Znaleziono natomiast dwa rozwiązania bliższe grom paragrafowym. Oba rozwiązania pozwalają również na tworzenie własnych zagadek i są to:

• 5 Minute Mystery (dostępna pod adresem https://www.5minutemystery.com/) – aplikacja webowa udostępniająca możliwość rozgrywania i tworzenia gry tekstowej.

Każda rozgrywka oparta jest na tekście wyświetlonym w całości przy rozpoczęciu rozgrywki. Gracz zdobywa punkty poprzez wskazanie sprawcy zbrodni oraz zaznaczenie inkryminujących go fragmentów tekstu.

• Text adventures (dostępna pod adresem http://textadventures.co.uk/) – aplikacja webowa umożliwiająca tworzenie i rozgrywanie interaktywnych gier tekstowych.

(7)

3 Rozgrywka oparta jest na fragmentach tekstu i opcjach wyboru. Gry dostępne w zakładce „Mystery” posiadają również aspekty dedukcyjne.

Ponadto, natrafiono również na wpis na blogu bespokeclassroom.com, tłumaczący budowanie wirtualnego pokoju zagadek, wykorzystując Google Forms [7]. Świadczy to o istniejącej potrzebie narzędzi umożliwiających tworzenie własnych zagadek czy historii.

1.2.2. Rozwiązania planszowo-komiksowe

Drugą kategorią istniejących rozwiązań są rozwiązania, które nie wymagają żadnego urządzenia elektronicznego do gry. Wyróżniono z nich gry typu „tabletop” oraz komiksy paragrafowe:

• EXIT - Śmierć w Orient Expressie – gra należąca do popularnej serii EXIT, nazywanej w środowisku graczy pudełkowym „escape roomem”. Ukończenie gry wymaga rozwiązania serii mniej lub bardziej skomplikowanych zagadek. Seria EXIT zawiera wiele gier w swoim portfolio, natomiast ta konkretna część, poza standardowymi zagadkami, stawia graczy przed problemem wskazania winnego zbrodni.

• Sherlock Holmes - Detektyw Doradczy – gra planszowa przenosząca graczy do Londynu w czasach wiktoriańskich [8] w celu przeprowadzenia śledztwa. Gracze mają do dyspozycji takie rzeczy jak mapa Londynu, książka adresową czy lokalne gazety.

• Sherlock Holmes. Pojedynek z Irene Adler oraz Cztery śledztwa Sherlocka Holmesa – komiksy paragrafowe, w których czytelnik wciela się w Sherlocka Holmesa bądź Irene Adler i stara się rozwiązać sprawę zabójstwa, decydując o losach swojej postaci.

1.2.3. Rozwiązania hybrydowe

Połączenie dwóch poprzednich kategorii nazwano rozwiązaniami hybrydowymi. Są to gry posiadające jakieś elementy fizyczne (plansza, karty, znaczniki, żetony), w których do gry wymagana jest jednak aplikacja mobilna czy webowa. Znaleziono dwa takie rozwiązania:

• Kroniki Zbrodni – „innowacyjne połączenie gry planszowej, aplikacji i wirtualnej rzeczywistości” [9], w której karty mają nadrukowany kod QR, a aplikacja webowa służy do ich odczytywania. Możliwe jest również przyglądanie się miejscu zbrodni w wirtualnej rzeczywistości.

• Detektyw: Kryminalna Gra Planszowa – wymagająca gra, w której gracze wcielają się w śledczych, którzy do rozwiązania sprawy mają do dyspozycji bazę danych Antares (część elektroniczna). Elementy fizyczne gry to plansza, karty oraz znaczniki.

Pierwotna koncepcja systemu opisywanego w niniejszej pracy zakładała prawie całkowite odwzorowanie mechaniki gry Detektyw. Na etapie projektowania systemu stworzono osobną mechanikę inspirowaną wymienioną grą. Kluczowy aspekt gry – paragrafy w formie kart – został zachowany i przerobiony jako akcje w systemie.

(8)

4

2. Projekt

Pracę nad tworzeniem systemu rozpoczęto od przygotowania jego projektu. Podczas tego etapu poruszono problematykę samej mechaniki tworzonej gry, utworzono projekt wizualny aplikacji oraz podjęto decyzję o rozwiązaniach technicznych.

2.1. Koncept rozgrywki

Gra nie jest oparta na tradycyjnej mechanice, do jakiej przyzwyczajona jest większość graczy komputerowych. Gry komputerowe utożsamiamy z jej popularnymi gatunkami takimi jak FPS, MOBA czy gry platformowe. Jeśli mielibyśmy się odnieść do gier popularnych na obecnym rynku, tworzonemu produktowi najbliżej do gier typu point-and-click (tłum.. Wskaż i wybierz), w których za pomocą wskaźnika, gracz wskazuje kolejne akcje. Jednak w latach 80.

w Polsce fenomenem był inny rodzaj gier - gry paragrafowe [10]. Gry te, dostępne wówczas w formie książek, pozwalały odbiorcy decydować o losie swojego bohatera, oferując literacką przygodę. Koncept rozgrywki w tworzonym produkcie oparty jest właśnie na tym literackim eksperymencie.

Silnikiem rozgrywki w opisywanym systemie są paragrafy, rozumiane dosłownie jako

„fragment tekstu stanowiący pewną całość” [11]. Te fragmenty przedstawiane są graczowi jako opis kolejnych odkrywanych elementów rozgrywki. Opis ten może zawierać transkrypt rozmowy, opis subiektywnych odczuć detektywa, czy też dotyczyć martwej natury – ograniczeniem jest tu jedynie kreatywność twórcy. Jako komponenty gry rozumiemy: akcje, osoby, miejsca oraz przedmioty. Są one powiązane ze sobą, tworząc strukturę drzewiastą.

Podobny mechanizm wykorzystywany jest niekiedy we współczesnych komputerowych grach decyzyjnych, takich jak Detroit: Become Human (Rys. 1) czy Life is Strange.

Rysunek 1 Drzewo decyzji w grze Detroit: Become Human

(źródło: https://www.playstation.com/en-us/games/detroit-become-human-ps4/)

(9)

5 Tworzona gra jest grą detektywistyczną, więc celem rozgrywki jest rozwikłanie zagadki.

Grający wcielą się w rolę detektywów i na podstawie zdobywanych informacji oraz dedukcji będą podejmować decyzje, aby posuwać się do przodu w sprawie. Podejmowane decyzje będą prowadzić do okrywania nowych komponentów.

Detektywi pracują jednak w określonych dniach i o określonych porach, więc na rozwiązanie pojedynczej sprawy gracze będą mieli ograniczony czas, reprezentowany w grze przez Punkty Ruchu. To ograniczenie sprawia, że będą oni musieli podejmować decyzje uważnie - nie będzie czasu na zbadanie każdego tropu! Brak roztropności może prowadzić do nadgodzin reprezentowanych przez Punkty Stresu, a ich posiadanie wpływa negatywnie na wynik końcowy.

Podstawowym komponentem gry jest akcja. Wykonanie akcji wiąże się z kosztem w postaci Punktów Ruchu. Koszt akcji nie jest znany przed jej wykonaniem. Tylko wykonanie akcji może odsłonić nam kolejne komponenty: miejsca, osoby, przedmioty, a także nowe akcje.

Niektóre akcje posiadają ograniczenia co do miejsca w jakim mogą zostać wykonywane.

W każdym momencie rozgrywki gracze przebywają w jakiejś lokalizacji (rozgrywka rozpoczyna się w miejscu startowym zdefiniowanym przez twórcę). Niekiedy wykonanie akcji będzie wymagało od graczy zmiany lokalizacji – podróży. Ona również posiada koszt wyrażony w Punktach Ruchu, reprezentujący czas jazdy.

Kolejnym komponentem posiadającym ciekawą właściwość są przedmioty. Jako detektywi gracze mają do dyspozycji laboratorium. Można w nim zbadać każdy ze znalezionych przedmiotów. Oczekiwanie na wyniki kosztuje jednak cenne Punkty Ruchu, ale niekiedy pozwala graczom odkryć dodatkowe informacje o przedmiocie.

Kiedy graczowi skończą się Punkty Ruchu w danym dniu, może on rozpocząć kolejny.

Kiedy zaś skończą się dostępne dni, zmuszony jest podjąć próbę rozwiązania zagadki.

2.2. Wymagania funkcjonalne i niefunkcjonalne

Na wstępnym etapie projektowania systemu zgromadzono wymagania użytkowników w formie historyjek (tłum. user stories). Zbiór takich wymagań pozwolił określić funkcjonalności produktu oraz wyróżnić w systemie czterech aktorów:

• Gracz - użytkownik zalogowany w celu rozgrywania sprawy,

• Twórca - użytkownik zalogowany w celu tworzenia lub edycji sprawy,

• Gość - osoba niezalogowana,

• Użytkownik - osoba zalogowana.

Historyjki użytkowników opisano zgodnie ze schematem:

Jako [nazwa aktora] chcę [co?].

(10)

6

Wymagania funkcjonalne:

• Jako gość chcę się zalogować.

• Jako gość chcę się zarejestrować.

• Jako gość chcę przeczytać instrukcję gry.

• Jako użytkownik chcę się wylogować.

• Jako użytkownik chcę przeczytać instrukcję gry.

• Jako gracz chcę robić notatki.

• Jako gracz chcę aby moje postępy w sprawie zapisywane były automatycznie.

• Jako gracz chcę wczytać swój postęp w sprawie.

• Jako gracz chcę rozpocząć nową grę.

• Jako gracz chcę przeglądać dostępne i wykonane akcje.

• Jako gracz chcę przeglądać osoby.

• Jako gracz chcę przeglądać przedmioty.

• Jako gracz chcę przeglądać miejsca.

• Jako gracz chcę przemieszczać się między miejscami.

• Jako gracz chcę wykonywać dostępne akcje.

• Jako gracz chcę widzieć stan swoich Punktów Ruchu.

• Jako gracz chcę widzieć stan swoich Punktów Stresu.

• Jako gracz chcę rozwiązać test końcowy.

• Jako gracz chcę zbadać przedmiot.

• Jako gracz chcę dodawać tagi do komponentów.

• Jako gracz chcę sprawdzić swój wynik rozwiązanych przeze mnie spraw.

• Jako gracz chcę porównać swój wynik z innymi graczami.

• Jako gracz chcę oceniać stworzone przez twórców sprawy.

• Jako gracz chcę znać najlepiej oceniane przez graczy sprawy.

• Jako twórca chcę tworzyć nowe sprawy.

• Jako twórca chcę dodawać akcje.

• Jako twórca chcę dodawać osoby.

(11)

7

• Jako twórca chcę dodawać przedmioty.

• Jako twórca chcę dodawać miejsca.

• Jako twórca chcę tworzyć powiązania między komponentami.

• Jako twórca chcę edytować stworzone sprawy.

• Jako twórca chcę edytować akcje.

• Jako twórca chcę edytować osoby.

• Jako twórca chcę edytować przedmioty.

• Jako twórca chcę edytować miejsca.

• Jako twórca chcę edytować powiązania między komponentami.

• Jako twórca chcę usuwać sprawy.

• Jako twórca chcę usuwać osoby.

• Jako twórca chcę usuwać przedmioty.

• Jako twórca chcę usuwać miejsca.

• Jako twórca chcę usuwać powiązania między komponentami.

• Jako twórca chcę przeglądać tworzoną sprawę.

• Jako twórca chcę oznaczyć przedmiot jako dowód zbrodni.

• Jako twórca chcę dodawać pytania i odpowiedzi do testu końcowego.

• Jako twórca chcę edytować pytania i odpowiedzi do testu końcowego.

• Jako twórca chcę usuwać pytania i odpowiedzi do testu końcowego.

• Jako twórca chcę widzieć jak gracze ocenili moją sprawę.

• Jako twórca chcę widzieć wyniki, jakie gracze uzyskali grając w moją sprawę.

Oprócz wymagań użytkowników dotyczących funkcjonalności produktu, zgromadzono również wymagania niefunkcjonalne, opisujące właściwości części klienckiej i serwerowej systemu.

Wymagania niefunkcjonalne:

• wersja systemu zarządzania bazą danych: MySQL 4.1 i wyżej,

• responsywność części klienckiej systemu,

• przejrzysty, spójny i czytelny interfejs,

• grywalność,

• zagwarantowanie działania w przeglądarkach: Google Chrome, Firefox, Safari, Opera, Microsoft Edge.

(12)

8

2.3. Diagram przypadków użycia

Na podstawie historyjek użytkowników oraz aktorów przedstawionych w rozdziale 2.2 przygotowano diagram przypadków użycia (Rys. 2). Prezentuje on funkcjonalności, jakie będzie zawierać pierwsza wersja produktu. Pominięte funkcjonalności, względem wymagań funkcjonalnych, opisane zostały w rozdziale 5.6, dotyczącym planów rozwoju aplikacji.

Rysunek 2 Diagram przypadków użycia

(13)

9 2.4. Specyfikacja przypadków użycia

W celu doprecyzowania szczegółów wymagań funkcjonalnych, dla każdego przypadku użycia przygotowano jego specyfikację. Ułatwiło to fazę implementacji - pozwoliło utworzyć kryteria akceptacyjne funkcjonalności oraz przygotować przypadki testowe.

Tabela 1 Specyfikacja przypadku użycia PU_01

Identyfikator PU_01

Przypadek użycia Zarejestruj

Aktor Gość

Cel Utworzenie konta użytkownika w systemie

Wyzwalacz Kliknięcie przycisku zarejestruj w widoku aplikacji Warunek początkowy -

Główny scenariusz powodzenia

1. Aktor wybiera zakładkę „Rejestracja”

2. Aktor wprowadza dane 3. System tworzy konto

4. System informuje aktora o prawidłowej rejestracji Scenariusze

alternatywne

1. Adres e-mail już zarejestrowany

3.1 Podany przez aktora adres e-mail nie przechodzi weryfikacji

4.1 System informuje, że adres e-mail jest już zarejestrowany

5.1 Użytkownik wprowadza inny adres e-mail 6.1 System tworzy konto

7.1 System informuje aktora o prawidłowej rejestracji

2. Dane nie przechodzą walidacji (np. za mała liczba znaków, nieprawidłowy format)

3.2 Podane przez aktora dane nie przechodzą walidacji 4.2 System informuje, że dane nie przechodzą walidacji 5.2 Użytkownik wprowadza prawidłowe dane

6.2 System tworzy konto

7.2 System informuje aktora o prawidłowej rejestracji

Rozszerzenia -

(14)

10

Przypadek użycia Zaloguj

Aktor Gość

Cel Zalogowanie użytkownika w systemie

Wyzwalacz Kliknięcie przycisku zaloguj w widoku aplikacji Warunek początkowy Użytkownik posiada konto w systemie

1. Aktor wybiera zakładkę „Logowanie”

2. Aktor wprowadza dane 3. System loguje użytkownika

4. System informuje aktora o zalogowaniu Scenariusze alternatywne 1. Podano nieprawidłowe dane

3.1 Podane przez aktora dane nie przechodzą walidacji (np.

brak użytkownika w systemie, nieprawidłowe hasło) 4.1 System informuje, że dane nie przechodzą walidacji 5.1 Użytkownik wprowadza prawidłowe dane

6.1 System loguje użytkownika

7.1 System informuje aktora o zalogowaniu

Rozszerzenia -

Przypadek użycia Wyloguj

Aktor Użytkownik

Cel Wylogowanie użytkownika z systemu

Wyzwalacz Kliknięcie przycisku wyloguj w widoku aplikacji Warunek początkowy Użytkownik posiada konto w systemie

Użytkownik jest zalogowany Główny scenariusz

powodzenia

1. Aktor wybiera możliwość wylogowania 2. System wylogowuje użytkownika

3. System przenosi aktora do widoku logowania Scenariusze alternatywne -

Rozszerzenia -

(15)

11 Tabela 4 Specyfikacja przypadku użycia PU_04

Przypadek użycia Przeczytaj instrukcję

Aktor Gość, Użytkownik

Cel Zapoznanie się przez aktora z instrukcją gry

Wyzwalacz Kliknięcie przycisku dowiedz się więcej na stronie głównej Warunek początkowy -

1. Aktor wybiera możliwość dowiedzenia się więcej o grze 2. System wyświetla instrukcję gry

Scenariusze alternatywne -

Rozszerzenia -

Przypadek użycia Przeglądaj utworzone sprawy

Aktor Twórca

Cel Przejrzenie przez aktora utworzonych przez niego spraw Wyzwalacz Przejście na dashboard

Warunek początkowy Użytkownik jest zalogowany Główny scenariusz

powodzenia

1. System wyświetla sprawy utworzone przez aktora

Scenariusze alternatywne 1.Aktor nie posiada utworzonych spraw

1.1.System wyświetla komunikat, że aktor nie posiada utworzonych spraw

Rozszerzenia Edytuj sprawę

Przypadek użycia Utwórz nową sprawę

Aktor Twórca

(16)

12

Cel Utworzenie nowej sprawy przez aktora

Wyzwalacz Kliknięcie przycisku Stwórz własną sprawę w widoku aplikacji

powodzenia

1. Użytkownik wprowadza nazwę sprawy i jej krótki opis 2. System tworzy nową sprawę

3. System wyświetla nowoutworzoną sprawę w widoku utworzonych spraw

Scenariusze alternatywne 1. Nie udaje się stworzyć sprawy

2.1 Tworzenie nowej sprawy przez system kończy się niepowodzeniem

3.1 System informuje użytkownika o niepowodzeniu Rozszerzenia Edytuj sprawę

Przypadek użycia Przejdź do edycji sprawy

Aktor Twórca

Cel Przejście do widoku edycji sprawy

Wyzwalacz Wybór sprawy z widoku utworzonych spraw Warunek początkowy Użytkownik jest zalogowany

Sprawa jest utworzona Główny scenariusz

powodzenia

1. Użytkownik wchodzi w widok edycji sprawy 2. System wyświetla widok edycji sprawy Scenariusze alternatywne -

Rozszerzenia Edytuj ustawienia scenariusza Edytuj akcję

Edytuj miejsca Edytuj osoby Edytuj przedmioty Edytuj test końcowy Oznacz jako gotową

(17)

Przypadek użycia Edytuj ustawienia scenariusza

Aktor Twórca

Cel Edycja ustawień scenariusza

Wyzwalacz Kliknięcie przycisku Opcje w widoku edycji sprawy Warunek początkowy Użytkownik jest zalogowany

Sprawa jest utworzona

Użytkownik jest w widoku edycji sprawy Główny scenariusz

powodzenia

1. Użytkownik wchodzi w widok edycji ustawień scenariusza 2. System wyświetla widok edycji ustawień scenariusza 3. Użytkownik uzupełnia ustawienia scenariusza

4. Użytkownik wybiera przycisk zatwierdź

5. System zapisuje zmiany w ustawieniach scenariusza 6. System aktualizuje widok edycji sprawy

Scenariusze alternatywne 1. Nie udaje się zapisać zmian

5.1 Zapisanie zmian przez system kończy się niepowodzeniem

6.1 System wyświetla informację o niepowodzeniu

Rozszerzenia -

Przypadek użycia Edytuj osoby

Aktor Twórca

Cel Edycja lub dodanie nowej osoby do sprawy

Wyzwalacz Kliknięcie przycisku Osoby w widoku edycji sprawy Warunek początkowy Użytkownik jest zalogowany

powodzenia

1. Użytkownik wchodzi w widok edycji osób 2. System wyświetla widok edycji osób 3. Użytkownik wybiera dodanie nowej osoby 4. Użytkownik uzupełnia dane osoby

5. Użytkownik wybiera przycisk zatwierdź

(18)

14

6. System zapisuje nową osobę

7. System aktualizuje widok edycji sprawy Scenariusze alternatywne 1. Edycja osoby

3.1 Użytkownik wybiera osobę do edycji z listy Stworzone osoby

4.1 Użytkownik zmienia dane osoby

5.1 Użytkownik wybiera przycisk zatwierdź 6.1 System zapisuje zmiany osoby

7.1 System aktualizuje widok edycji sprawy 2. Usunięcie osoby

3.2 Użytkownik wybiera opcję usuń przy osobie z listy Stworzone osoby

4.2 System usuwa osobę

5.2 System aktualizuje widok edycji sprawy 3. Nie udaje się zapisać zmian

Rozszerzenia -

Przypadek użycia Edytuj przedmioty

Aktor Twórca

Cel Edycja lub dodanie nowego przedmiotu do sprawy

Wyzwalacz Kliknięcie przycisku Przedmioty w widoku edycji sprawy Warunek początkowy Użytkownik jest zalogowany

powodzenia

1. Użytkownik wchodzi w widok edycji przedmiotów 2. System wyświetla widok edycji przedmiotów 3. Użytkownik wybiera dodanie nowego przedmiotu 4. Użytkownik uzupełnia dane przedmiotu

5. Użytkownik wybiera przycisk zatwierdź 6. System zapisuje nowy przedmiot

7. System aktualizuje widok edycji sprawy Scenariusze alternatywne 1. Edycja przedmiotu

3.1 Użytkownik wybiera przedmiot do edycji z listy Stworzone przedmioty

4.1 Użytkownik zmienia dane przedmiotu

(19)

15 5.1 Użytkownik wybiera przycisk zatwierdź

6.1 System zapisuje zmiany przedmiotu 7.1 System aktualizuje widok edycji sprawy 2. Usunięcie przedmiotu

3.2 Użytkownik wybiera opcję usuń przy przedmiocie z listy Stworzone przedmioty

4.2 System usuwa przedmiot

6.3 Zapisanie zmian przez system kończy się niepowodzeniem 7.3 System wyświetla informację o niepowodzeniu

Rozszerzenia -

Przypadek użycia Edytuj test końcowy

Aktor Twórca

Cel Edycja testu końcowego tworzonej sprawy

Wyzwalacz Kliknięcie przycisku Test końcowy w widoku edycji sprawy Warunek początkowy Użytkownik jest zalogowany i jest w widoku sprawy

Sprawa jest utworzona Główny scenariusz

powodzenia

1. Użytkownik wchodzi w widok edycji testu końcowego 2. System wyświetla widok edycji testu końcowego 3. Użytkownik wybiera dodanie nowego pytania 4. Użytkownik uzupełnia treść pytania

5. Użytkownik uzupełnia treść odpowiedzi 6. Użytkownik wybiera prawidłową odpowiedź

6. System zapisuje nowe pytanie wraz z odpowiedziami 7. System aktualizuje widok edycji sprawy

Scenariusze alternatywne 1. Edycja pytania

3.1 Użytkownik wybiera pytanie do edycji z listy Stworzone pytania

4.1 Użytkownik zmienia treść pytania 5.1 Użytkownik wybiera przycisk zatwierdź 6.1 System zapisuje zmiany w pytaniu 7.1 System aktualizuje widok edycji sprawy 2. Usunięcie pytania

3.2 Użytkownik wybiera opcję usuń przy pytaniu z listy Stworzone pytania

4.2 System usuwa pytanie

5.2 System aktualizuje widok edycji sprawy

(20)

16

3. Dodanie odpowiedzi

4.3 Użytkownik wybiera opcję Dodaj odpowiedź 5.3 Użytkownik wprowadza treść odpowiedzi 6.3 Użytkownik wybiera przycisk zatwierdź 7.3 System zapisuje zmiany w pytaniu 8.3 System aktualizuje widok edycji sprawy 4. Usunięcie odpowiedzi

4.4 Użytkownik wybiera opcję usuń przy wybranej odpowiedzi

5.4 System zapisuje zmiany w pytaniu 6.4 System aktualizuje widok edycji sprawy 5. Nie udaje się zapisać zmian

Rozszerzenia -

Przypadek użycia Edytuj miejsca

Aktor Twórca

Cel Edycja lub dodanie nowego miejsca do sprawy

Wyzwalacz Kliknięcie przycisku Miejsca w widoku edycji sprawy Warunek początkowy Użytkownik jest zalogowany

powodzenia

1. Użytkownik wchodzi w widok edycji miejsc 2. System wyświetla widok edycji miejsc

3. Użytkownik wybiera dodanie nowego miejsca 4. Użytkownik uzupełnia dane miejsca

5. Użytkownik wybiera przycisk zatwierdź 6. System zapisuje nowe miejsce

7. System aktualizuje widok edycji sprawy Scenariusze alternatywne 1. Edycja miejsca

3.1 Użytkownik wybiera miejsce do edycji z listy Stworzone miejsca

4.1 Użytkownik zmienia dane miejsca

(21)

17 5.1 Użytkownik wybiera przycisk zatwierdź

6.1 System zapisuje zmiany miejsca

7.1 System aktualizuje widok edycji sprawy 2. Usunięcie miejsca

3.2 Użytkownik wybiera opcję usuń przy miejscu z listy Stworzone miejsca

4.2 System usuwa miejsce

7.3 System wyświetla informację o niepowodzeniu Rozszerzenia Edytuj połączenia

Przypadek użycia Edytuj połączenia

Aktor Twórca

Cel Edycja lub dodanie nowego połączenia pomiędzy miejscami Wyzwalacz Kliknięcie przycisku dodaj połączenie w widoku edycji

sprawy

Warunek początkowy Użytkownik jest zalogowany Sprawa jest utworzona

Użytkownik jest w widoku edycji miejsc Główny scenariusz

powodzenia

1. Użytkownik wybiera dodanie nowego połączenia 2. Użytkownik uzupełnia dane połączenia

3. Użytkownik wybiera przycisk zatwierdź 4. System zapisuje nowe połączenie 5. System aktualizuje widok edycji sprawy Scenariusze alternatywne 1. Edycja połączenia

1.1 Użytkownik wybiera połączenie do edycji z listy Stworzone połączenia

2.1 Użytkownik zmienia dane połączenia 3.1 Użytkownik wybiera przycisk zatwierdź 4.1 System zapisuje zmiany połączenia 5.1 System aktualizuje widok edycji sprawy 2. Usunięcie połączenia

1.2 Użytkownik wybiera opcję usuń przy połączeniu z listy Stworzone połączenia

2.2 System usuwa połączenie

3.2 System aktualizuje widok edycji sprawy

(22)

18

3. Nie udaje się zapisać zmian

Rozszerzenia -

Przypadek użycia Edytuj akcję

Aktor Twórca

Cel Edycja lub dodanie nowej akcji do sprawy

Wyzwalacz Kliknięcie przycisku Akcje w widoku edycji sprawy Warunek początkowy Użytkownik jest zalogowany

powodzenia

1. Użytkownik wchodzi w widok edycji akcji 2. System wyświetla widok edycji akcji 3. Użytkownik wybiera dodanie nowej akcji 4. Użytkownik uzupełnia dane akcji

5. Użytkownik wybiera przycisk zatwierdź 6. System zapisuje nową akcję

7. System aktualizuje widok edycji sprawy Scenariusze alternatywne 1. Edycja akcji

3.1 Użytkownik wybiera akcję do edycji z listy Stworzone akcje

4.1 Użytkownik zmienia dane akcji

5.1 Użytkownik wybiera przycisk zatwierdź 6.1 System zapisuje zmiany akcji

7.1 System aktualizuje widok edycji sprawy 2. Usunięcie akcji

3.2 Użytkownik wybiera opcję usuń przy miejscu z listy Stworzone akcje

4.2 System usuwa akcję

7.3 System wyświetla informację o niepowodzeniu Rozszerzenia Edytuj następniki

(23)

Przypadek użycia Edytuj następniki

Aktor Twórca

Cel Edycja lub dodanie nowego następnika akcji

Wyzwalacz Kliknięcie przycisku dodaj następnik w widoku edycji sprawy

Użytkownik jest w widoku edycji akcji Główny scenariusz

powodzenia

1. Użytkownik wybiera dodanie nowego następnika 2. Użytkownik wybiera następnik

3. Użytkownik wybiera przycisk zatwierdź 4. System zapisuje nowy następnik

5. System aktualizuje widok edycji sprawy Scenariusze alternatywne 1. Usunięcie następnika

1.1 Użytkownik wybiera opcję usuń przy następniku z listy Następniki

2.1 System usuwa połączenie

Rozszerzenia -

Przypadek użycia Oznacz jako gotową

Aktor Twórca

Cel Umożliwienie graczom rozgrywanie twojej sprawy

Wyzwalacz Kliknięcie przycisku oznacz jako gotową w widoku edycji sprawy

(24)

20

Użytkownik jest w widoku edycji akcji Główny scenariusz

powodzenia

1. Użytkownik wybiera oznaczenie sprawy jako gotową 2. System uruchamia walidację reguł

3. Sprawa przechodzi pozytywnie weryfikację 4. System zapisuje sprawę jako gotową do rozgrywki 5. System aktualizuje widok edycji sprawy

Scenariusze alternatywne 1. Sprawa nie przechodzi weryfikacji 3.1 Sprawa nie przechodzi weryfikacji

4.1 System wyświetla użytkownikowi reguły, które zablokowały weryfikację

5.1 System nie zapisuję zmiany gotowości do rozgrywki 2. Nie udaje się zapisać zmian

Rozszerzenia -

Przypadek użycia Przejdź do przeglądania spraw

Aktor Gracz

Cel Przejście do dashboardu gracza

Wyzwalacz Kliknięcie przycisku przenoszącego do dashboardu gracza przez aktora

powodzenia

1. Użytkownik wchodzi w widok dashboardu gracza 2. System wyświetla widok przeglądania spraw Scenariusze alternatywne -

Rozszerzenia Przeglądaj ukończone sprawy Przeglądaj gotowe sprawy Przeglądaj rozpoczęte sprawy

Przypadek użycia Przeglądaj zakończone sprawy

(25)

21

Aktor Gracz

Cel Przejrzenie przez aktora zakończonych przez niego spraw Wyzwalacz Przejście na dashboard

powodzenia

1. System wyświetla sprawy zakończone przez aktora

Scenariusze alternatywne 1.Aktor nie posiada skończonych spraw

1.1.System wyświetla komunikat, że aktor nie posiada zakończonych spraw

Rozszerzenia -

Przypadek użycia Przeglądaj gotowe sprawy

Aktor Gracz

Cel Przejrzenie przez aktora gotowych do rozegrania przez niego spraw

Wyzwalacz Przejście na dashboard Warunek początkowy Użytkownik jest zalogowany Główny scenariusz

powodzenia

1. System wyświetla sprawy gotowe do rozegrania przez aktora

Scenariusze alternatywne

1.System nie posiada gotowych spraw

1.1.System wyświetla komunikat, że nie ma aktualnie spraw gotowych do rozegrania

Rozszerzenia Przejdź do rozgrywania sprawy

Przypadek użycia Przeglądaj rozpoczęte sprawy

Aktor Gracz

Cel Przejrzenie przez aktora rozpoczętych przez niego spraw

(26)

22

Wyzwalacz Przejście na dashboard Warunek początkowy Użytkownik jest zalogowany Główny scenariusz

powodzenia

1. System wyświetla sprawy rozpoczęte przez aktora

Scenariusze alternatywne 1.Aktor nie posiada rozpoczętych spraw

1.1.System wyświetla komunikat, że aktor nie ma rozpoczętych spraw

Rozszerzenia Przejdź do rozgrywania sprawy

Przypadek użycia Przejdź do rozgrywania sprawy

Aktor Gracz

Cel Przejście do widoku rozgrywania sprawy

Wyzwalacz Wybór sprawy z widoku gotowych spraw Wybór sprawy z widoku rozpoczętych spraw Warunek początkowy Użytkownik jest zalogowany

Istnieje gotowa do rozegrania sprawa Główny scenariusz

powodzenia

1. Użytkownik wchodzi w widok rozgrywania sprawy 2. System wyświetla widok rozgrywania sprawy Scenariusze alternatywne 1. Pierwsze przejście do widoku rozgrywania wybranej

sprawy

2.1 System wyświetla treść pierwszej akcji 3.1 System wyświetla widok rozgrywania sprawy Rozszerzenia Przeglądaj akcje

Przeglądaj miejsca Przeglądaj osoby Przeglądaj przedmioty Wypełnij test końcowy Zakończ dzień

Przypadek użycia Przeglądaj osoby

(27)

23

Aktor Gracz

Cel Przejrzenie informacji o odkrytych osobach

Wyzwalacz Kliknięcie przycisku Osoby w widoku rozgrywania sprawy Kliknięcie w daną osobę w dashboardzie sprawy

Warunek początkowy Użytkownik jest zalogowany

powodzenia

1. Użytkownik wchodzi w widok Osoby 2. System wyświetla widok Osoby

3. Użytkownik wybiera osobę, o której chce zobaczyć informację z listy osób

4. System wyświetla informację o wybranej osobie Scenariusze alternatywne -

Rozszerzenia -

Przypadek użycia Przeglądaj przedmioty

Aktor Gracz

Cel Przejrzenie informacji o odkrytych przedmiotach

Wyzwalacz Kliknięcie przycisku Przedmioty w widoku rozgrywania sprawy

Kliknięcie w dany przedmiot w dashboardzie sprawy Warunek początkowy Użytkownik jest zalogowany

powodzenia

1. Użytkownik wchodzi w widok Przedmioty 2. System wyświetla widok Przedmioty

3. Użytkownik wybiera przedmiot, o którym chce zobaczyć informację z listy przedmiotów

4. System wyświetla informację o wybranym przedmiocie Scenariusze alternatywne -

Rozszerzenia Badaj

(28)

24

Przypadek użycia Zbadaj

Aktor Gracz

Cel Odkrycie dodatkowych informacji o wybranym przedmiocie Wyzwalacz Kliknięcie przycisku Zbadaj przy wybranym przedmiocie Warunek początkowy Użytkownik jest zalogowany

Istnieje gotowa do rozegrania sprawa Użytkownik jest w widoku Przedmioty Główny scenariusz

powodzenia

1. Użytkownik wybiera przedmiot, o którym chcę odkryć więcej informacji

2. Użytkownik wybiera przycisk zbadaj

3. System odejmuje PR równe kosztowi zbadania od puli PR 4. System wyświetla informację odkryte przez aktora poprzez zbadanie

Scenariusze alternatywne 1. Brak nowych informacji po zbadaniu

4.1 System wyświetla informację, że zbadanie nie odkryło nowych informacji

Rozszerzenia -

Przypadek użycia Zakończ dzień

Aktor Gracz

Cel Rozpoczęcie nowego dnia rozgrywania sprawy

Wyzwalacz Kliknięcie przycisku Zakończ dzień Warunek początkowy Użytkownik jest zalogowany

Istnieje gotowa do rozegrania sprawa

Użytkownik jest w widoku dashboardu sprawy Główny scenariusz

powodzenia

1. Użytkownik wybiera przycisk Zakończ dzień

2. System sprawdza czy nie wyczerpano liczby dostępnych w ramach sprawy dni

3. System odświeża liczbę dostępnych Punktów Ruchu na dany dzień

4. System wyświetla informację o rozpoczęciu nowego dnia

(29)

25 Scenariusze alternatywne 1. Wyczerpano liczbę dostępnych w ramach sprawy dni

3.1 System wyświetla informację, że nie można rozpocząć nowego dnia, ponieważ wyczerpano liczbę dostępnych w ramach sprawy dni

Rozszerzenia -

Przypadek użycia Przeglądaj miejsca

Aktor Gracz

Cel Przejrzenie informacji o odkrytych miejscach

Wyzwalacz Kliknięcie przycisku Miejsca w widoku rozgrywania sprawy Kliknięcie w dane miejsce w dashboardzie sprawy

Warunek początkowy Użytkownik jest zalogowany

powodzenia

1. Użytkownik wchodzi w widok Miejsca 2. System wyświetla widok Miejsca

3. Użytkownik wybiera miejsce, o którym chce zobaczyć informację z listy miejsc

4. System wyświetla informację o wybranym miejscu Scenariusze alternatywne -

Rozszerzenia Podróżuj

Przypadek użycia Podróżuj

Aktor Gracz

Cel Wykonanie akcji dostępnej do wykonania w innym miejscu niż obecna lokalizacja gracza

Wyzwalacz Kliknięcie przycisku Podróżuj przy wybranej lokalizacji Warunek początkowy Użytkownik jest zalogowany

Istnieje gotowa do rozegrania sprawa Użytkownik jest w widoku Miejsca

(30)

26

1. Użytkownik wybiera przycisk podróżuj przy miejscu, do którego chce się przemieścić

2. System wybiera najkrótszą (o najniższym koszcie PR) możliwą ścieżkę podróży do danego miejsca

3. System sprawdza czy użytkownik ma wystarczającą liczbę PR, aby podróżować do danego miejsca

4. System odejmuje PR równe kosztowi podróży od puli PR 5. System zmienia lokalizację aktora

Scenariusze alternatywne 1. Aktor nie posiada wystarczającej liczby PR w danym dniu, aby wykonać podróż

4.1 System wyświetla informację, że aktora nie posiada wystarczającej liczby PR w danym dniu

Rozszerzenia -

Przypadek użycia Wypełnij test końcowy

Aktor Gracz

Cel Zakończenie sprawy

Wyzwalacz Kliknięcie przycisku Rozwiąż test końcowy Warunek początkowy Użytkownik jest zalogowany

powodzenia

1. Aktor wybiera przycisk rozwiąż test końcowy 2. System wyświetla aktorowi kolejne pytania 3. Aktor wybiera jedną z dostępnych odpowiedzi

4. Aktor wybiera przycisk Dalej po udzieleniu odpowiedzi na każde z kolejnych pytań

5. System oblicza ilość zdobytych punktów ze sprawy 6. System wyświetla informację o liczbie zdobytych przez aktora punktów

7. System przenosi użytkownika do dashboardu gracza Scenariusze

alternatywne

-

Rozszerzenia -

(31)

Przypadek użycia Przejdź do przeglądania akcji

Aktor Gracz

Cel Przejście do przeglądania akcji

Wyzwalacz Kliknięcie przycisku Akcje gracza przez aktora Warunek początkowy Użytkownik jest zalogowany

powodzenia

1. Aktor wybiera przycisk akcje

2. System wyświetla widok przeglądania akcji Scenariusze alternatywne -

Rozszerzenia Przeglądaj wykonane akcje Wykonaj akcję

Przypadek użycia Przeglądaj wykonane akcje

Aktor Gracz

Cel Przejrzenie informacji o wykonanych akcjach

Wyzwalacz Kliknięcie przycisku Akcje w widoku rozgrywania sprawy Warunek początkowy Użytkownik jest zalogowany

Istnieje gotowa do rozegrania sprawa Użytkownik jest w widoku akcji Główny scenariusz

powodzenia

1. System wyświetla listę wykonanych akcji

2. Użytkownik wybiera wykonaną akcję, o którym chce zobaczyć informację z listy miejsc

4. System wyświetla informację o wykonanej akcji, w tym o jej następnikach

Rozszerzenia -

(32)

28

Przypadek użycia Wykonaj akcję

Aktor Gracz

Cel Wykonanie akcji. Przybliżenie się do rozwiązania sprawy.

Wyzwalacz Wybranie akcji z widoku dostępnych akcji Warunek początkowy Użytkownik jest zalogowany

Istnieje gotowa do rozegrania sprawa Użytkownik jest w widoku akcji Główny scenariusz

powodzenia

1. System wyświetla listę dostępnych akcji

2. Użytkownik wybiera dostępną akcję, którą chce wykonać 3. System sprawdza czy użytkownik nie ma

3. System odejmuje PR równe kosztowi wykonania akcji do puli PR

4. System dolicza ewentualne Punkty Stresu 5. System odkrywa następniki akcji

5. System wyświetla informację o wykonanej akcji, w tym o jej następnikach

Rozszerzenia -

2.5. Diagram klas [N.G.]

Ze względu na rozmiar projektu przedstawiono diagram klas podzielony na pakiety lub funkcjonalności systemu. Podział taki ma na celu zapewnienie czytelności podczas omawiania kolejnych elementów systemu. Diagramy klas opisują tutaj model domenowy - koncepcyjny.

Rysunek 3 Model domenowy pakietu controller

(33)

29 Pakiet na rysunku 3 jest charakterystyczny dla aplikacji tworzonych w architekturze MVC. Gromadzi klasy typu Controller (tłum. kontrolery), czyli “komponenty przechwytujące żądania użytkowników i odwzorowujące je w wywołania metod komponentów typu Model”

[12].

Kontrolery zostały podzielone zgodnie z funkcjonalnościami jakie mają spełniać:

• AuthController odpowiedzialny będzie za żądania związane z autoryzacją użytkownika.

• UserController będzie zawierał funkcjonalności związane z konkretnych użytkownikiem, jak np. profil użytkownika.

• CreationController odpowiedzialny jest za funkcjonalności związane z tworzeniem nowej sprawy

• GameplayController za funkcjonalności związane z rozgrywaniem sprawy

• DashboardController dostarczał będzie natomiast funkcjonalności które widoczne są dla każdego użytkownika (również gościa)

Odzwierciedlenie podziału kontrolerów widoczne jest w podziale interfejsu użytkownika w rozdziale 2.9.

Część serwerowa aplikacji odpowiedzialna jest za komunikację z bazą danych. W związku z tym w jednym z jej pakietów znajdują się klasy będące odzwierciedleniem tabel bazodanowych. Pakiet ten przedstawiono na rysunku 4. W przypadku tabel posiadających klucze złożone wyodrębniono klasę będącą kluczem.

Rysunek 4 Diagram klas pakietu DAO

(34)

30

2.6. Reguły biznesowe

Opisywana aplikacja umożliwia użytkownikom tworzenie własnych spraw. W celu zapewnienia grywalności zdefiniowano reguły, jakie sprawa musi spełniać, aby została oznaczona jako gotowa.

Zdefiniowane reguły podzielone zostały na dwie kategorie: reguły blokujące oraz nieblokujące. Reguły blokujące uniemożliwiają oznaczenie sprawy jako gotowej. Reguły nieblokujące służą jedynie jako zalecenia, utworzone zostały w celu podniesienia doświadczenia użytkownika – zarówno gracza, jak i twórcy.

Reguły blokujące:

1. Sprawa musi posiadać lokację startową.

2. Sprawa nie może posiadać, więcej niż jedną lokację startową.

3. Sprawa musi posiadać test końcowy.

4. Sprawa musi posiadać lokację.

5. Pytanie musi mieć odpowiedź.

6. Pytanie musi mieć prawidłową odpowiedź.

7. Pytanie musi mieć jedną prawidłową odpowiedź.

Reguły nieblokujące:

1. Powinna być możliwość podróży do lokacji.

2. Powinna być możliwość odkrycia lokacji.

3. Powinna być możliwość odkrycia akcji.

4. Powinna być możliwość odkrycia osoby.

5. Powinna być możliwość odkrycia przedmiotu.

2.7. Architektura systemu

Architektura systemu oparta jest na architekturze trójwarstwowej. W związku z tym, system składa się z trzech głównych części: klienckiej, serwerowej i bazodanowej. W klasycznej wersji reprezentują one kolejno warstwy: prezentacji, logiki biznesowej i danych.

W tworzonej aplikacji zdecydowano się umieścić silnik gry po stronie klienckiej. W części klienckiej zachowano jednak podział na warstwę prezentacji i warstwę silnika gry, co widoczne jest w rozdziale 2.7.2 prezentującym diagram pakietów części klienckiej.

Zdecydowano się na zastosowanie architektury wielowarstwowej ze względu na jej liczne zalety, między innymi: pozwala na skupienie się na pojedynczych elementach podczas

(35)

31 implementacji i ułatwia testowanie kodu (testując pojedynczą warstwę możemy pominąć pozostałe) [13].

2.7.1. Diagram pakietów części serwerowej [N.G.]

Diagram pakietów na rysunku 5 przedstawia strukturę folderów dla części serwerowej aplikacji. Zastosowanie poszczególnych pakietów opisano poniżej:

resources - zasoby

meta-inf - pliki przechowujące właściwości aplikacji

rules - pliki przechowujące implementację reguł biznesowych dla silnika reguł java::pl::detectivegame - folder opakowujący implementację aplikacji

config - pliki konfiguracyjne

security - pliki konfiguracyjne autoryzacji i autentykacji

payload - pliki reprezentujące żądania i odpowiedzi do API aplikacji serwerowej. Podział w pakietach podporządkowanych pakietowi payload odzwierciedla podział opisany w rozdziale diagram klas pakietu controller.

exception - pliki reprezentujące odpowiedzi API w przypadku wystąpienia błędu controller - pliki obsługujące przychodzące żądania

service - pliki wykonujące logikę biznesową aplikacji repository - pliki wykonujące połączenia do bazy danych util - pliki zawierające elementy pomocnicze

model - pliki reprezentujące modele obiektów aplikacji

DAO - pliki będące odzwierciedleniem wyników zapytań do bazy danych

DTO - pliki reprezentujące obiekty będące składowymi odpowiedzi API aplikacji

(36)

32

Rysunek 5 Diagram pakietów części serwerowej

(37)

33 2.7.2. Diagram pakietów części klienckiej [A.P.]

Część kliencka systemu podzielona jest na trzy moduły aplikacji: moduł główny – przeznaczony dla gościa i użytkownika, moduł rozgrywki – przeznaczony dla gracza i moduł kreatora – przeznaczony dla kreatora. Diagram pakietów na rysunku 6 przedstawia opisany podział. Komponent AppRouter (zaznaczony zielonym kolorem na rysunku) na podstawie URL zarządza do jakiego modułu aplikacji użytkownik powinien zostać przekierowany, a następnie moduł importuje odpowiadający mu router. Przedstawione na diagramie pakiety są częścią pakietu src, a przerywane linie wskazują na import.

Należy zwrócić uwagę, że pages::creator oraz pages::gameplay, jak nazwa wskazuje, są częścią pakietu pages. Celowo zastosowano taki zabieg, aby zachować czytelność diagramu i podkreślić podział aplikacji klienckiej na moduły. Z tego samego powodu, dla pakietu routers dodatkowo przedstawiono niektóre jego komponenty. Co więcej, pakiety, które importuje pages, również są importowane przez pakiety pages::creator i pages::gameplay.

Opis zawartości zewnętrznych pakietów na diagramie:

routers – routing aplikacji,

pages – widoki aplikacji, uporządkowane w hierarchii odpowiadającej rzeczywistej nawigacji strony, zawiera pakiet creator i gameplay,

pages::creator – widok kreatora, pages::gameplay – widok rozgrywki,

layout – układ strony, inny dla każdego modułu, components – komponenty wielokrotnego użytku, constants – stałe komunikaty i wartości,

context – zarządzanie kontekstem aplikacji; silnik gry, utils – funkcje wspierające działanie aplikacji,

api - komunikacja z częścią serwerową.

(38)

34

Rysunek 6 Diagram pakietów części klienckiej

(39)

35 2.7.3. Diagram rozmieszczenia

Na rysunku 7 przedstawiono rozmieszczenie komponentów aplikacji. Widoczne jest tu oddzielenie części klienta od bazy danych. W celu zapewnienia bezpieczeństwa w połączeniach zawsze pośredniczy aplikacja serwerowa.

Rysunek 7 Diagram rozmieszczenia

Opis węzłów i artefaktów przedstawionych na diagramie rozmieszczenia:

UserClient - komputer użytkownika, bądź inne urządzenie pozwalające na przeglądanie Internetu

Browser - przeglądarka internetowa, pobiera statyczne pliki interfejsu użytkownika z serwera oraz wysyła żądania do interfejsu serwera

JS - JavaScript; odpowiada za przetwarzanie interfejsu użytkownika, jego wersja zależy od przeglądarki

HTML5 - odpowiada za wizualizację interfejsu użytkownika WebServer - serwer fizyczny z odpowiednią specyfikacją Apache Tomcat - kontener aplikacji webowych

Website - aplikacja webowa odpowiadająca za interfejs użytkownika i jego komunikację z interfejsem serwera

detectiveGame.jar - aplikacja serwerowa, archiwum w formacie zip zawierające pliki klas języka Java i powiązane z nimi metadane.

DatabaseServer - serwer bazy danych MySQL - baza danych

(40)

36

2.7.4. Diagram związków encji

W opisywanym produkcie wykorzystano relacyjną bazę danych. Diagram związków utworzonych encji widoczny jest na rysunku 8. Relacje wiele do wielu rozbito z wykorzystaniem tabeli pośredniczących. W bazie danych przechowywane są sprawy tworzone przez graczy, zapisy rozgrywek oraz informację o użytkownikach. Poniżej znajduje się szczegółowy opis encji oraz zastosowanie ich poszczególnych atrybutów.

(41)

37 Rysunek 8 Diagram związków encji

(42)

38

Encje roles, user_roles i users służą do przechowywania danych użytkownika. Struktura tych tabel jest klasyczną strukturą rekomendowaną przy wykorzystaniu projektu javowego Spring Security (rozdział 5.2). Są one istotne dla zabezpieczenia aplikacji oraz identyfikowania tworzonych, czy rozgrywanych przez danego użytkownika spraw.

Tabela 32 Opis atrybutów encji roles

atrybut tabeli opis

id identyfikator roli użytkownika

name nazwa roli użytkownika

Tabela 33 Opis atrybutów encji user_roles

user_id identyfikator użytkownika role_id identyfikator roli użytkownika

Tabela 34 Opis atrybutów encji users

id identyfikator użytkownika

email adres email

created data utworzenia

modified data modyfikacji

name imię

password zaszyfrowane hasło username nazwa użytkownika

Centralną encją rozgrywki jest encja detective_case, która reprezentuje sprawę detektywistyczną. Tabele powiązane z tabelą detective_case - action, action_action, action_location, location, location_connection, action_item, item, question oraz answer są składowymi sprawy detektywistycznej. Informację z nich zostają pobierane, gdy rozpoczynana jest rozgrywka wybranej sprawy.

Tabela 35 Opis atrybutów encji detective_case

id identyfikator sprawy detektywistycznej

(43)

39 creator identyfikator twórcy sprawy

name nazwa sprawy

description opis sprawy

created data utworzenia

modified data modyfikacji

image adres url będący odnośnikiem do obrazu ready czy sprawa gotowa do rozgrywki

max_days maksymalna liczba dni w sprawie

mp_per_days maksymalna liczba Punktów Ruchu na każdy dzień frst_action_id identyfikator pierwszej akcji

Tabele question oraz answer reprezentują test końcowy sprawy.

Tabela 36 Opis atrybutów encji question

question_id identyfikator pytania

case_id identyfikator sprawy, której dotyczy pytanie

content treść pytania

Tabela 37 Opis atrybutów encji answer

answer_id identyfikator odpowiedzi question_id identyfikator pytania content treść odpowiedzi

correct czy odpowiedź jest poprawna

W tabeli item przechowywane są zarówno przedmioty, jak i osoby. Opis oraz powód zastosowania takiego rozwiązania opisano w rozdziale 5.4.