Společná aplikace pro uživatele různých komunitních sítí. Pavel Krayzel

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Společná aplikace pro uživatele různých komunitních sítí Pavel Krayzel

Vedoucí práce: Ing. Jaroslav Čech

Studĳní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 19. května 2010

iv

v

Poděkování Děkuji vedoucímu práce Ing. Jaroslavu Čechovi za odborné vedení při vývoji aplikace a za poskytnutí potřebného softwarového vybavení. Dále děkuji své rodině za podporu v průběhu mého dosavadního studia.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 19. května 2010

.............................................................

viii

Abstract Thesis deals with the development of a common application for users of different community networks, independent of the network where it runs. Firstly, the problem has been analyzed and appropriate portals for system deployment have been selected. Further, the special layer has been designed in order to separate application from various methods of user authentication on different social networks. To facilitate the distribution among users, they can play there some popular board games. The system has been implemented as a modular so as to be easily extended to other community networks and for a facile addition of the other board games in the future. The resultant application has been deployed in Facebook, MySpace and Friendster.

Abstrakt Práce se zabývá vytvořením jedné společné aplikace pro uživatele různých komunitních sítí, nezávisle na síti, ve které je spuštěna. Problematika je nejprve zanalyzována a poté jsou vybrána vhodná místa pro nasazení systému. Dále je navržena speciální vrstva pro odstínění od odlišného způsobu autorizace uživatelů na sociálních sítích. Pro snadnější šíření zde mohou uživatelé hrát některé oblíbené společenské hry. Systém je implementován modulárně pro snadné přidání na další komunitní sítě i pro jednoduché rozšíření o jiné společenské hry. Výsledná aplikace je nasazena na portály Facebook, MySpace a Friendster.

ix

x

Obsah 1 Úvod 1.1 Motivace projektu . . . . . . . . 1.2 Popis řešeného problému . . . . . 1.3 Vymezení cílů bakalářské práce . 1.4 Popis struktury bakalářské práce

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1 1 1 2 2

2 Předprojektová studie 2.1 Rešeršní zpracování existujících implementací . . . . . . . . . 2.1.1 Propojení komunitních webů a sociálních sítí . . . . . 2.1.2 Herní aplikace pro komunitní weby a sociální sítě . . . 2.2 Rešeršní analýza sociálních sítí a komunitních webů . . . . . 2.2.1 Kritéria pro výběr komunitních webů a sociálních sítí 2.2.2 Výběr konkrétních komunitních webů a sociálních sítí 2.3 Analýza vhodných společenských her . . . . . . . . . . . . . . 2.3.1 Kritéria pro výběr společenských her . . . . . . . . . . 2.3.2 Výběr konkrétních společenských her . . . . . . . . . . 2.4 Slovník pojmů . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

5 5 5 6 6 6 7 7 7 8 8

3 Specifikace požadavků 3.1 Katalog požadavků . . . . . . . 3.1.1 Nefunkční požadavky . 3.1.2 Funkční požadavky . . . 3.2 Aktéři . . . . . . . . . . . . . . 3.3 Případy užití . . . . . . . . . . 3.3.1 Diagramy případů užití 3.3.2 Specifikace případů užití

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

9 9 9 10 13 14 14 14

4 Analýza 4.1 Doménový model . . . . . . . . . . . . . . . . . 4.1.1 Uživatelé . . . . . . . . . . . . . . . . . 4.1.2 Společenské hry . . . . . . . . . . . . . . 4.2 Realizace případů užití . . . . . . . . . . . . . . 4.2.1 Otevřít herní místnost . . . . . . . . . . 4.2.2 Připojit se do existující herní místnosti

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

17 17 17 18 19 19 20

. . . . . . .

. . . . . . .

. . . . . . .

xi

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

xii

5 Návrh 5.1 Model 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.2 Model 5.2.1 5.3 Model 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 5.4 Model 5.4.1 5.4.2 5.5 Model 5.5.1 5.6 Model 5.6.1 5.6.2 5.6.3 5.6.4 5.6.5

OBSAH

architektury . . . . . . . . . . . . . . . . . . . . . Autorizační vrstva . . . . . . . . . . . . . . . . . Prezentační vrstva . . . . . . . . . . . . . . . . . Serverová vrstva . . . . . . . . . . . . . . . . . . Aplikační vrstva . . . . . . . . . . . . . . . . . . Databázová (datová) vrstva . . . . . . . . . . . . návrhových tříd . . . . . . . . . . . . . . . . . . . Aplikační vrstva (balíček businessLayer) . . . . . komunikace . . . . . . . . . . . . . . . . . . . . . Spuštění aplikace . . . . . . . . . . . . . . . . . . Zahájení interakce uživatelem . . . . . . . . . . . Instalace aplikace uživatelem . . . . . . . . . . . Zpracování údajů uživatele . . . . . . . . . . . . Určení vztahu uživatele k požadované místnosti . Načtení prezentační vrstvy . . . . . . . . . . . . stavových diagramů . . . . . . . . . . . . . . . . . Stavový automat herní místnosti . . . . . . . . . Stavový automat uživatelského rozhraní aplikace uživatelského rozhraní . . . . . . . . . . . . . . . Herní místnost . . . . . . . . . . . . . . . . . . . nasazení . . . . . . . . . . . . . . . . . . . . . . . Autorizační vrstva . . . . . . . . . . . . . . . . . Prezentační vrstva . . . . . . . . . . . . . . . . . Serverová vrstva . . . . . . . . . . . . . . . . . . Aplikační vrstva . . . . . . . . . . . . . . . . . . Databázová (datová) vrstva . . . . . . . . . . . .

6 Implementace 6.1 Databázová (datová) vrstva . . . . . . . . . . . 6.2 Aplikační vrstva . . . . . . . . . . . . . . . . . 6.3 Autorizační vrstva . . . . . . . . . . . . . . . . 6.3.1 Implementace pro různé komunitní sítě 6.3.2 Rozšiřitelnost na další komunitní sítě . . 6.3.3 Propojitelnost účtů komunitních sítí . . 6.4 Prezentační vrstva . . . . . . . . . . . . . . . . 6.5 Serverová vrstva . . . . . . . . . . . . . . . . . 7 Testování 7.1 Konfigurace testovacího PC . . . . . . 7.2 Testování jednotlivých vrstev aplikace 7.2.1 Databázová (datová) vrstva . . 7.2.2 Aplikační vrstva . . . . . . . . 7.2.3 Autorizační vrstva . . . . . . . 7.2.4 Prezentační vrstva . . . . . . . 7.2.5 Serverová vrstva . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

23 23 24 24 25 25 25 25 26 26 26 26 27 28 28 28 28 28 29 29 30 31 32 32 32 32 32

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

35 35 35 36 36 36 36 37 38

. . . . . . .

39 39 39 40 40 40 41 41

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

OBSAH

xiii

8 Závěr

43

Literatura

45

A Seznam použitých zkratek

47

B UML diagramy B.1 Případy užití . . . . . . . . . . . . . . . . . . . . . . . . B.2 Model komunikace . . . . . . . . . . . . . . . . . . . . . B.2.1 Spuštění aplikace . . . . . . . . . . . . . . . . . . B.2.2 Zpracování údajů uživatele . . . . . . . . . . . . B.3 Model uživatelského rozhraní . . . . . . . . . . . . . . . B.3.1 Administrační okno společenské hry pexeso . . . B.3.2 Standardní rozložení hrací plochy hry piškvorky

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

49 49 50 50 50 50 50 51

C Obrázky 55 C.1 Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 D Uživatelská příručka D.1 Identifikace herní místnosti . . . . . . . . . . . . . . . . . . . . . . D.1.1 Otevření vlastní herní místnosti . . . . . . . . . . . . . . . . D.1.2 Připojení se do cizí herní místnosti . . . . . . . . . . . . . . D.2 Spuštění aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.2.1 Spuštění aplikace na sociální síti Facebook . . . . . . . . . D.2.2 Spuštění aplikace na sociální síti MySpace . . . . . . . . . . D.2.3 Spuštění aplikace na sociální síti Friendster . . . . . . . . . D.3 Obrazovka herní místnosti . . . . . . . . . . . . . . . . . . . . . . . D.4 Obrazovka nastavení nové hry - piškvorky . . . . . . . . . . . . . . D.4.1 Obrazovka nastavení nové hry - piškvorky - odměny hráčů . D.5 Obrazovka probíhající hry - piškvorky . . . . . . . . . . . . . . . . E Obsah přiloženého CD

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

59 59 59 59 60 60 60 61 61 63 64 65 67

xiv

OBSAH

Seznam obrázků 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11

Rozdělení požadavků . . . . . . . . . . . . . . . . . . . . . . . . . . . Nefunkční požadavky na rozšiřitelnost implementovaného systému . Nefunkční požadavky na technologie implementovaného systému . . Funkční požadavky na uživatele systému . . . . . . . . . . . . . . . . Funkční požadavky na spuštění aplikace a celkovou koncepci systému Funkční požadavky na administraci konkrétní herní místnosti . . . . Funkční požadavky na administraci společenských her v místnosti . Funkční požadavky na společenské hry v místnosti . . . . . . . . . . Funkční požadavky na další činnost v místnosti . . . . . . . . . . . . Aktéři . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interakce systému s aktérem uživatel . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

9 10 10 11 11 11 12 13 13 14 14

4.1 4.2 4.3 4.4 4.5

Doménový model - rozdělení na balíčky . . . . . Doménový model - uživatelé . . . . . . . . . . . . Doménový model - společenské hry . . . . . . . . Sekvenční diagram - otevřít herní místnost . . . . Sekvenční diagram - připojit se do otevřené herní

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

17 18 20 21 21

5.1 5.2 5.3 5.4 5.5 5.6 5.7

Model Model Model Model Model Model Model

architektury aplikace . . . . . . . . . . . . . . . . . . . . . . . návrhových tříd - balíčky . . . . . . . . . . . . . . . . . . . . návrhových tříd - uživatelé . . . . . . . . . . . . . . . . . . . . statových automatů - stavový automat herní místnosti . . . . statových automatů - stavový automat uživatelského rozhraní uživatelského rozhraní - hlavní obrazovka aplikace . . . . . . nasazení systému . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

24 25 27 28 29 31 33

6.1

Snímek obrazovky z aplikace na sociální síti Facebook . . . . . . . . . . . . . 38

B.1 B.2 B.3 B.4 B.5 B.6

Interakce systému s aktérem administrátor . . . . . . . . . . . . . . . . . . . Interakce systému s aktérem návštěvník . . . . . . . . . . . . . . . . . . . . . Model komunikace - sekvenční diagram spuštění aplikace . . . . . . . . . . . . Model komunikace - sekvenční diagram zpracování údajů uživatele . . . . . . Model uživatelského rozhraní - administrační okno společenské hry pexeso . . Model uživatelského rozhraní - standardní rozložení hrací plochy hry piškvorky

. . . . . . . . . . . . . . . . . . . . . . . . místnosti

. . . . .

. . . . .

. . . . .

. . . . .

49 50 52 53 54 54

C.1 Snímek obrazovky z aplikace na sociální síti MySpace . . . . . . . . . . . . . 56

xv

xvi

SEZNAM OBRÁZKŮ

C.2 Snímek obrazovky z aplikace na sociální síti Friendster . . . . . . . . . . . . . 57 D.1 D.2 D.3 D.4 D.5 D.6

Obrazovka herní místnosti s popisky . . . . . . . . . . . . . . . . Okno s URL adresou herní místnosti . . . . . . . . . . . . . . . . Okno s herní statistikou uživatele - piškvorky . . . . . . . . . . . Modální okno pro nastavení nové hry - piškvorky . . . . . . . . . Modální okno pro nastavení nové hry - piškvorky - odměny hráčů Obrazovka probíhající hry - piškvorky . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

62 63 63 64 65 66

Seznam tabulek 2.1 2.2

Sociální sítě a komunitní weby, kritéria pro aplikaci . . . . . . . . . . . . . . . Slovník pojmů používaných v bakalářské práci . . . . . . . . . . . . . . . . . .

7 8

3.1 3.2 3.3

Specifikace případu užití - otevřít herní místnost . . . . . . . . . . . . . . . . 15 Specifikace případu užití - pozvat uživatele do herní místnosti . . . . . . . . . 15 Specifikace případu užití - připojit se do otevřené herní místnosti . . . . . . . 16

4.1 4.2

Popis metod třídy SocialGamePlay a jejích potomků . . . . . . . . . . . . . . 19 Popis atributů třídy SocialGamePlay . . . . . . . . . . . . . . . . . . . . . . . 19

7.1 7.2 7.3

Hardwarová konfigurace testovacího počítače . . . . . . . . . . . . . . . . . . 39 Softwarové vybavení testovacího počítače . . . . . . . . . . . . . . . . . . . . 40 Použité testovací nástroje jednotlivých komunitních sítí . . . . . . . . . . . . 40

D.1 Facebook - důležité údaje pro spuštění aplikace . . . . . . . . . . . . . . . . . 60 D.2 MySpace - důležité údaje pro spuštění aplikace . . . . . . . . . . . . . . . . . 60 D.3 Friendster - důležité údaje pro spuštění aplikace . . . . . . . . . . . . . . . . . 61 E.1 Obsah přiloženého CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

xvii

xviii

SEZNAM TABULEK

Kapitola 1

Úvod 1.1

Motivace projektu

Časová přímka [11] úspěšného komunitního webu1 Facebook2 , který dosáhl v prosinci roku 2009 počtu 350 miliónů registrovaných uživatelů, dokazuje, že počet uživatelů sociálních sítí3 , komunitních portálů a podobných služeb roste v současné době (leden 2010) každým dnem. Internetové stránky těchto portálů se proto stávají vhodným a často vyhledávaným místem zejména pro marketingové účely. Autor bakalářské práce je zaměstnancem firmy iCORD International s.r.o.4 , která se zaměřuje na vývoj nejnovějších technologií pro on-line komunikaci. Jako součást marketingové strategie společnosti byla v roce 2009 vyvinuta aplikace5 pro prostředí komunitního webu Facebook, jejímž cílem byla propagace nejnovějších technologií v oblasti interaktivní komunikace. Problémem a hlavním nedostatkem projektu byla skutečnost, že byl k dispozici pouze pro uživatele zmíněného komunitního webu. Autora bakalářské práce později napadla myšlenka vytvoření aplikace, kterou by mohl stejným způsobem používat nejen uživatel ze sítě Facebook, ale i uživatel sítě MySpace6 či dalších portálů. Aplikace, která bude výsledkem bakalářské práce, bude toto kritérium splňovat tím, že vytvoří společné rozhraní pro zvolené sociální sítě a komunitní weby a umožní jednoduché přidavání na další místa. Z důvodu snažšího rozšíření mezi uživatele bude zvoleno téma společenských her7 .

1.2

Popis řešeného problému

Zadání bakalářské práce bylo vytvořeno ve spolupráci s externím zadavatelem - firmou iCORD International s.r.o. Výsledek práce bude sloužit zejména k propagaci existujících produktů společnosti a k možnosti jejich dalšího zdokonalení pomocí použitých postupů 1

Komunitní web je místo, na kterém jsou poskytovány určité služby pro specifickou skupinu uživatelů. Facebook patří mezi nejpopulárnější sociální sítě (viz statistika na [24]). 3 Sociální síť je společenská struktura lidí nebo organizací, vzájemně propojených podle určitých vazeb. 4 Stránky společnosti na http://www.icord.cz. 5 Aplikace Room45, http://apps.facebook.com/roomfourfive/. 6 Podle žebříčku na [24] patří MySpace k nejoblíbenějším komunitním webům. 7 Hry patří mezi nejpoužívanější aplikace na sociálních sítích - viz statistiky na [5] nebo [17]. 2

1

2

KAPITOLA 1. ÚVOD

a řešení. Problém, specifikovaný v sekci 1.1, byl objeven při analýze výsledků reálných projektů zadavatele bakalářské práce. Počet komunitních webů a sociálních sítí, které se vyskytují v prostředí internetu a nabízí možnost vyvíjet aplikace s využitím jejich API8 , je obrovský. Pokud je však programátor postaven před úkol vytvořit aplikaci společnou pro více takových portálů, narazí na poměrně závažné problémy - nejednotné autorizační standardy a často zcela odlišnou strukturu uživatelských údajů. Problém je ještě umocněn rychlostí, se kterou se internet a moderní technologie vyvíjí. Každým rokem se může objevit nový způsob autorizace uživatelů, případně mohou být existující standardy zrušeny. Řešením se zdá být navržení mezivrstvy, která aplikaci odstíní od externích autorizačních systémů a poskytne pro ně společné rozhraní. Podle statistiky nejpoužívanějších webových aplikací na komunitním webu Facebook [5] patří mezi nejoblíbenější hry a programy primárně určené pro zábavu. Zdají se být tím pravým nástrojem pro marketingové účely, a proto bude výsledná aplikace zaměřena na herní tématiku.

1.3

Vymezení cílů bakalářské práce

Detailní specifikace funkčností systému bude obsahem kapitoly 3, ve které bude provedena analýza funkčních i nefunkčních požadavků na implementovaný systém. Cíle bakalářské práce jsou však zřejmé již v tuto chvíli a lze je tedy vymezit. Hlavním cílem bakalářské práce je zanalyzovat, navrhnout a implementovat herní aplikaci, kterou budou moci používat uživatelé odlišných sociálních sítí a komunitních webů, a to i navzájem - např. uživatel ze sítě Facebook bude moci soupeřit s uživatelem z MySpace. Bude umožňěno jednoduché zavedení na další sociální sítě, aniž by se změnila funkčnost existujících řešení. Uživatelé implementovaného systému budou moci hrát různé druhy společenských her, které se jednoduchostí ovládání a dalšími vlastnostmi hodí pro počítačové zpracování. Aplikace bude umožňovat zaznamenávání výsledků jednotlivých her, soupeření mezi uživateli (např. formou bodového systému) a snadné modulární rozšíření o další společenské hry (bez nutnosti zásahu do zdrojového kódu stávajících her).

1.4

Popis struktury bakalářské práce

Struktura a rozdělení textu do jednotlivých kapitol přibližně odpovídá práci na pomezí návrhové a implementační, uvedené na [16] v sekci s pokyny pro psaní bakalářské práce. Je postupováno chronologicky od definování problému až po vytvoření funkční verze programu. Problém, definovaný v sekci 1.2, je srovnán s existujícími řešeními a implementacemi v části 2.1. Poté jsou vybrány komunitní weby a sociální sítě, na které bude aplikace primárně nasazena (2.2) a společenské hry, které budou moci uživatelé v aplikaci hrát (2.3). Na závěr kapitoly 2 je v sekci 2.4 definován slovník nejdůležitějších pojmů projektu. Kapitola 3 slouží pro vymezení funkčních i nefunkčních požadavků na implementovaný systém a vytvoření diagramů případů užití. Doménový model a realizace případů užití jsou uvedeny v kapitole 8

Application Programming Interface - rozhraní pro programování aplikací.

1.4. POPIS STRUKTURY BAKALÁŘSKÉ PRÁCE

3

4, po které následuje nejobsáhlejší kapitola - návrh aplikace (5). Obsahem části 6 je popis implementační fáze, v kapitole 7 je popsán způsob testování systému. Výstupy ze všech kapitol (včetně kompletního realizovaného programu) jsou k dispozici na přiloženém médiu, jež je přílohou k elektronickému odevzdání bakalářské práce. Více informací je uvedeno v dodatku (E).

4

KAPITOLA 1. ÚVOD

Kapitola 2

Předprojektová studie 2.1

Rešeršní zpracování existujících implementací

Rešerši existujících implementací jsem provedl ze dvou nezávislých pohledů - nejprve jsem hledal řešení, která se zaměřují na propojení různých komunitních webů a sociálních sítí, potom jsem se zabýval problematikou existujících herních aplikací pro oblast komunitních sítí.

2.1.1

Propojení komunitních webů a sociálních sítí

Přestože celá řada sociálních sítí umožňuje propojení s některou z dalších sítí ([26] nebo [6]), nejedná se o obecné řešení dané problematiky. Propojení je nejčastěji realizováno pomocí aplikace nasazené do prostředí konkurenční sociální sítě - jako je tomu i v případě aplikace [6] nebo [18].

Google OpenSocial API Problém společného rozhraní pro různé sociální sítě a komunitní weby se snaží po svém řešit společnost Google1 pomocí OpenSocial2 API. OpenSocial je definované jednotné rozhraní, implementované a poskytované sociálními sítěmi a komunitními weby, které se rozhodnou do projektu vstoupit. Přestože počet zapojených webů dosáhl podle [22] v lednu 2010 čísla 35, některé velké komunitní weby, jako je např. Facebook, do projektu zapojeny nejsou. Nutnost zásahů ze strany komunitních sítí je dle mého názoru hlavním nedostatkem tohoto řešení, a proto jsem se rozhodl OpenSocial v bakalářské práci nevyužít. V oblasti jedné společné aplikace, propojující uživatele různých komunitních webů a sociálních sítí, lze říci, že k bakalářské práci neexistuje ekvivalentní implementace. 1 2

Společnost, která vyvíjí nejpoužívanější internetový vyhledávač [23], http://www.google.com. OpenSocial definuje jednotné API pro některé komunitní weby a sociální sítě. Viz [15] nebo [21].

5

6

KAPITOLA 2. PŘEDPROJEKTOVÁ STUDIE

2.1.2

Herní aplikace pro komunitní weby a sociální sítě

Nejpoužívanější hry na sociálních sítích Konkurence na sociálních sítích a komunitních webech je v oblasti herních a zábavních aplikací obrovská. Jak dokazují statistiky na [8] a [17], patří v současné době (leden 2010) mezi nejúspěšnější vývojáře her pro komunitní weby společnosti Zynga Game Network Inc.3 a Playdom4 . Obě společnosti mají v první desítce několik her, které jsou k dispozici na nejoblíbenějších sítích. Nevýhodou jejich zpracování je fakt, že např. uživatel na MySpace může hrát pouze s uživateli tohoto komunitního webu a celkové hráčské pole je tak značně rozdělené. Společenské hry na sociálních sítích Na komunitních webech a sociálních sítích existuje celá řada aplikací, které nabízí hraní konkrétních her - např. zajímavé zpracování původní hry piškvorky na [9]. Nepodařilo se mi však nalézt aplikaci, ve které by bylo možné hraní více druhů společenských her najednou. Na poli her pro sociální sítě je sice veliká konkurence, ale aplikace, která bude výsledkem bakalářské práce, bude navržena jako jedno místo pro hraní různých druhů společenských her. V této oblasti k práci nebyla nalezena ekvivalentní implementace.

2.2

Rešeršní analýza sociálních sítí a komunitních webů

Před vymezením požadavků na implementovaný systém je nutné provést průzkum komunitních webů a sociálních sítí, na které lze aplikaci v současné době (leden 2010) nasadit. Pro usnadnění výběru budou definována kritéria, na která jsme narazili při realizaci projektu Room45 zmíněném v úvodní kapitole 1.

2.2.1

Kritéria pro výběr komunitních webů a sociálních sítí

1. poskytnutí zdokumentovaného API pro přístup k údajům přihlášeného uživatele, 2. přístup k aplikaci přes oficiální URL adresu sociální sítě nebo komunitního webu (URL složená např. z domény třetího řádu5 a názvu aplikace6 ), 3. umístění v žebříčku nejoblíbenějších sociálních sítí na [24] nebo [25], 4. poskytnutí zdokumentovaného API pro aktualizace stavu7 nebo publikování zprávy přihlášeného uživatele. 3

Zynga Game Network Inc. se zabývá vývojem online her pro sociální sítě, viz http://www.zynga.com. Playdom je firma zabývající se vývojem her pro sociální sítě a komunitní weby. 5 Doména třetího řádu je např. http://apps.facebook.com. 6 Příkladem URL je http://apps.facebook.com/worldobg/. 7 Stav nebo status je veřejná zpráva napsaná uživatelem sociální sítě, kterou vidí jím vybraní uživatelé. 4

2.3. ANALÝZA VHODNÝCH SPOLEČENSKÝCH HER Portál F acebook M ySpace F riendster

Kritérium 1 ano [12] ano [20] ano [13]

Kritérium 2 ano [7] ano [19] ano [13]

Kritérium 3 ano [24] i [25] ano [24] i [25] ano [24] i [25]

7 Kritérium 4 ano [12] ano [20] ano [13]

Tabulka 2.1: Sociální sítě a komunitní weby, kritéria pro aplikaci

Místa, která nesplní první kritérium, nebudou vůbec brána v potaz - aplikace bez informací o přihlášeném uživateli nemůže fungovat. Druhý požadavek je podstatný pro snadné nasazení aplikace a pro její důvěryhodnost vůči uživatelům sociálních sítí. Třetí a čtvrté kritérium mají vliv na rozšíření aplikace mezi uživatele, a jsou tedy klíčová pro splnění očekávání zadavatele.

2.2.2

Výběr konkrétních komunitních webů a sociálních sítí

Výběr vhodných míst jsem provedl postupnou rešerší podrobností o každé síti, uvedené v přehledu nejpoužívanějších sociálních sítí a komunitních webů v článcích [24] a [25]. Skvělým rozcestníkem byl sumarizační článek o webech, které poskytují API, na [1]. Každé místo bylo podrobeno analýze na základě vymezených kritérií - výstupem je tabulka 2.1, ve které jsou uvedeny odkazy na zdroje informací.

2.3

Analýza vhodných společenských her

Dalším důležitým krokem je zvolení společenských her, které budou v první verzi aplikace obsaženy. Aplikace bude navržena modulárně, takže bude umožněno průběžné přidávání dalších her. Nicméně je nutné vymezit obsah základní verze. Pro usnadnění výběru budou definována kritéria omezující výběr z několika různých hledisek.

2.3.1

Kritéria pro výběr společenských her

1. umístění v žebříčku nejhranějších her na [14], 2. složitost počítačového zpracování, 3. jednoduché ovládání realizovatelné pomocí myši nebo klávesnice, 4. existence stolní verze hry, 5. střídání hráčů po definovatelných tazích, 6. provedení pro dva a více hráčů.

8

KAPITOLA 2. PŘEDPROJEKTOVÁ STUDIE

2.3.2

Výběr konkrétních společenských her

Výběr jsem provedl vylučovací metodou, jejímž výstupem je následující seznam her: • lodě, • piškvorky, • pexeso, • šachy. Pro základní verzi systému jsem se nakonec rozhodl zprovoznit piškvorky a pexeso. Při konečné selekci jsem se (kromě složitosti tvorby počítačového zpracování) nechal ovlivnit také subjektivním postojem k jednotlivým hrám.

2.4

Slovník pojmů

Pro přesné porozumění termínům používaných v bakalářské práci jsem vymezil seznam základních pojmů (včetně používaných synonym) a jejich významu. Pojem Administrátor

Komunitní síť

Místnost

Návštěvník

Definice Uživatel připojený ve své místnosti s možností jejího spravování - odpojování uživatelů, spouštění her atd. Synonyma: Správce, administrátor místnosti, správce místnosti Homonyma: žádná Internetové stránky, na kterých jsou registrováni uživatelé a jsou jim poskytovány služby - např. používání aplikací. Synonyma: Komunitní web, sociální síť Homonyma: žádná Unikátně identifikované místo v systému, ve kterém lze vykonávat různé aktivity - např. hrát společenské hry, komunikovat apod. Synonyma: Herní místnost Homonyma: žádná Uživatel připojený v místnosti jiného uživatele. Synonyma: Návštěvník místnosti, připojený uživatel Homonyma: žádná Tabulka 2.2: Slovník pojmů používaných v bakalářské práci

Kapitola 3

Specifikace požadavků 3.1

Katalog požadavků

Některé základní požadavky na implementovaný systém byly zmíněny již v kapitole 1.3. Aktuální sekce slouží pro přesné vymezení funkčních (3.1.2) a nefunkčních (3.1.1) požadavků, potřeb a kritérií implementovaného systému. Požadavky jsem rozdělil do několika tématických skupin, které jsou znározněny na diagramu na obrázku 3.1. Diagramy požadavků, stejně jako veškeré ostatní diagramy v bakalářské práci, jsem vytvořil pomocí CASE nástroje Entreprise Architect od společnosti Sparx Systems1 . Na jednotlivých diagramech jsou použita barevná označení požadavků odpovídající popisu na [3]. Oranžová barva značí povinné kritérium plynoucí ze zadání práce nebo od zadavatele. Modrou barvou jsou rozlišeny související požadavky schválené vedoucím bakalářské práce. Jiné barvy nejsou v této fázi použity.

Obrázek 3.1: Rozdělení požadavků

3.1.1

Nefunkční požadavky

Nefunkční požadavky jsou rozděleny do dvou skupin - rozšiřitelnost a technologie. 1

http://www.sparxsystems.com/products/ea/index.html.

9

10

KAPITOLA 3. SPECIFIKACE POŽADAVKŮ

Rozšiřitelnost Požadavky na rozšiřitelnost byly zmíněny v kapitole 1.3 a vyplývají i ze zadání bakalářské práce.

Obrázek 3.2: Nefunkční požadavky na rozšiřitelnost implementovaného systému

Technologie Technologická kritéria jsem obdržel od zadavatele této práce a to z důvodu možného využití použitých řešení a postupů v jeho dalších projektech.

Obrázek 3.3: Nefunkční požadavky na technologie implementovaného systému

3.1.2

Funkční požadavky

Některé požadavky na funkčnost jsou zmíněny již v kapitole 1.3. Ke komplexnímu vymezení požadovaných funkcí systému slouží tato sekce. Pro větší přehlednost jsem vytvořil tématické okruhy požadavků, které odpovídají specifickým částem nebo potřebám aplikace.

Uživatelé systému Jak je uvedeno v zadání bakalářské práce, implementovaný systém je navrhován jako společná aplikace pro uživatele různých komunitních webů a sociálních sítí. Uživatelé míst, jež byla rešeršně vybrána v sekci 2.2.2, budou moci systém plně využívat - hrát v něm společenské hry, zaznamenávat jejich výsledky, sledovat průběh aktuální hry, atd.

3.1. KATALOG POŽADAVKŮ

11

Obrázek 3.4: Funkční požadavky na uživatele systému

Spuštění aplikace a celková koncepce systému Systém bude koncipován po unikátních herních místnostech. Každý uživatel aplikace bude mít k dispozici jednu, do které se mohou připojit i ostatní. Uživatel, připojený ve své vlastní místnosti, bude jejím administrátorem, ten, připojený v cizí místnosti, bude návštěvníkem. Aplikace umožní administrátorovi při připojení do místnosti notifikovat ostatní uživatele komunitních sítí (např. pomocí aktualizací stavu) a pozvat je do místnosti. Vymezené požadavky jsou zobrazeny na obrázku 3.5.

Obrázek 3.5: Funkční požadavky na spuštění aplikace a celkovou koncepci systému

Administrace konkrétní místnosti Systém umožní administrátorovi kompletní správu své herní místnosti, tedy spouštění společenských her (pro svou rozsáhlost je obsahem samostnatného okruhu), odpojování uživatelů, mazání obsahu chatu nebo i uzavření celé herní místnosti. Kromě vyjmenovaných činností bude moci administrátor místnosti dělat také vše, co běžný návštěvník.

Obrázek 3.6: Funkční požadavky na administraci konkrétní herní místnosti

Administrace her Systém bude administrátorovi místnosti umožňovat spuštění společenských her se zvoleným nastavením a pro vybrané hráče. Konkrétní možnosti nastavení (maximální počet uživa-

12


telů apod.) se mohou pro různé hry lišit a budou definovány například v databázi nebo v konfiguračních souborech. Po skončení hry nabídne aplikace administrátorovi možnost jejího opakování se stejným nastavením, pokud to budou podmínky dovolovat (např. pokud budou stále připojeni všichni hráči předchozí hry).

Obrázek 3.7: Funkční požadavky na administraci společenských her v místnosti

Společenské hry v místnosti Systém umožní návštěvníkům místnosti i jejímu administrátorovi hrát intuitivním způsobem společenské hry, které budou v aplikaci podporovány. Systém uchová statistiku odehraných her s umístěnín jednotlivých hráčů a na základě herních výsledků bude přerozdělovat body. K přerozdělování bodů bude využit systém ELO2 , upravený pro potřebu her o více než dvou hráčích (bodový systém nebude omezen počtem hráčů). Návštěvník nebo administrátor místnosti bude moci sledovat průběh aktuálně probíhající hry i v případě, že není jedním z hráčů. V případě, že se uživatel připojí až v průběhu hry, aplikace provede předchozí tahy v závislosti na konkrétním typu hry. Vymezené požadavky jsou znázorněny na diagramu na obrázku 3.8.

Další činnosti v místnosti Uživatelé systému budou moci v rámci herní místnosti komunikovat pomocí veřejného chatu. Systém umožní prohlížení herních statistik jednotlivých uživatelů místnosti libovolným připojeným uživatelem. 2

Autorem hodnotícího systému, používaného pro hru šachy, je Arpad Emrick Elo. Vysvětlení je na [4].

3.2. AKTÉŘI

13

Obrázek 3.8: Funkční požadavky na společenské hry v místnosti

Obrázek 3.9: Funkční požadavky na další činnost v místnosti

3.2

Aktéři

Nejobecnějším aktérem je uživatel, který představuje uživatele systému, kteří nejsou dosud připojeni v žádné místnosti. Aktéři návštěvník a administrátor vyplývají z požadavků na spuštění aplikace a z celkové koncepce systému a mají rozdílná práva vůči místnosti, ve které jsou připojeni. Vztahy mezi jednotlivými aktéry (viz diagram 3.10) byly navrženy tak, aby administrátor místnosti v systému vystupoval jako návštěvník své vlastní místnosti. Posledním aktérem je spolupracující systém komunitní síť, který je zmíněn ve specifikaci případu užití běžného uživatele. Interakce s ním jsou zachyceny na sekvenčním diagramu 4.4 v sekci 4.2.1.

14


Obrázek 3.10: Aktéři

Obrázek 3.11: Interakce systému s aktérem uživatel

3.3

Případy užití

V této sekci budou vymezeny případy užití systému jednotlivými aktéry z části 3.2. Případy užití (anglicky use cases) by měly zcela pokrývat funkční požadavky uvedené v kapitole 3.1.2. Pokrytí konkrétních požadavků je na diagramech znázorněno realizační šipkou (přerušovaná čára s bílým trojúhelníkem na konci) a bylo zkontrolováno pomocí matice vztahů (anglicky relationship matrix) v nástroji Entreprise Architect.

3.3.1

Diagramy případů užití

Diagramy případů užití jsem pro přehlednost rozdělil tak, aby každý diagram odpovídal interakci jednoho aktéra se systémem. V hlavním textu bude popsán pouze diagram interakce aktéra uživatel. Ostatní případy užití jsou přiloženy v dodatku B.1. Interakce systému s aktérem uživatel Diagram na obrázku 3.11 zobrazuje případy užití systému běžným uživatelem a je z něj patrné, jakým způsobem se z uživatele stane administrátor nebo návštěvník místnosti.

3.3.2

Specifikace případů užití

Kvůli nedostatku místa v hlavním textu uvádím pouze specifikaci případů užití systému aktérem uživatel. Specifikace ostatních případů užití, nezbytných pro správné pochopení funkčnosti aplikace, jsou k dispozici na CD přiloženém k elektronickému odevzdání bakalářské práce.

3.3. PŘÍPADY UŽITÍ

15

Případ užití: Otevřít herní místnost UC101 Uživatel se připojí do své herní místnosti (stane se administrátorem). Primární aktéři: Uživatel. Vedlejší aktéři: Žádní. Vstupní podmínky: Žádné. Hlavní scénář: ID: Stručný popis:

1. Uživatel otevře webovou stránku aplikace bez identifikace herní místnosti nebo s identifikací své vlastní místnosti. 2. IF Uživatel zvolí založit místnost s pozvánkou. 2.1 EXTEND: UC102 Pozvat uživatele do místnosti. 3. Systém připojí uživatele do místnosti a místnost otevře. Výstupní podmínky: Alternativní scénáře:

Uživatel je připojený ve své místnosti jako administrátor. Žádné.

Tabulka 3.1: Specifikace případu užití - otevřít herní místnost

Případ užití: Pozvat uživatele do herní místnosti ID: UC102 Stručný popis: Systém pošle pozvánku do místnosti do komunitní sítě uživatele. Primární aktéři: Uživatel. Vedlejší aktéři: Komunitní síť. Vstupní podmínky: Uživatel povolil aplikaci aktualizaci statusu na komunitní síti, ve které je aplikace spuštěna. Hlavní scénář: 1. Systém sestaví pozvánku, obsahující URL adresu místnosti uživatele. 2. Systém aktualizuje uživatelův status pozvánkou na komunitní síti. Výstupní podmínky: Alternativní scénáře:

Status uživatele na komunitní síti je aktualizován. Žádné.

Tabulka 3.2: Specifikace případu užití - pozvat uživatele do herní místnosti

16


Případ užití: Připojit se do otevřené herní místnosti ID: UC103 Stručný popis: Uživatel se připojí do herní místnosti jiného uživatele (stane se návštěvníkem). Primární aktéři: Uživatel. Vedlejší aktéři: Žádní. Vstupní podmínky: Herní místnost je otevřená. Hlavní scénář: 1. Uživatel otevře webovou stránku aplikace s parametrem identifikace cizí místnosti, do které se chce připojit. 2. Systém připojí uživatele do místnosti. Výstupní podmínky: Alternativní scénáře:

Uživatel je připojený v požadované místnosti jako návštěvník. Žádné.

Tabulka 3.3: Specifikace případu užití - připojit se do otevřené herní místnosti

Kapitola 4

Analýza 4.1

Doménový model

Dalším důležitým krokem je nalezení analytických tříd systému a sestavení doménového modelu. Jednotlivé analytické třídy jsem hledal pomocí metody analýzy podstatných jmen a sloves provedené nad katalogem požadavků a nad diagramy případů užití. Třídy jsem pro přehlednost rozdělil do dvou balíčků, které jsou znázorněny na obrázku 4.1. Detailní popisy jednotlivých tříd, včetně jejich atributů či operací, jsou k dispozici na CD (příloha elektronické verze bakalářské práce).

Obrázek 4.1: Doménový model - rozdělení na balíčky

4.1.1

Uživatelé

Balíček Users, jenž je zachycen na diagramu tříd (anglicky class diagram) na obrázku 4.2, obsahuje třídy týkající se uživatelů a jejich herních výsledků. Třída ApplicationUser představuje uživatele systému a kvůli možnosti připojení stejného uživatele z různých sociální sítí obsahuje vazby na třídu SocialNetworkUser. Ta obsahuje informace o uživateli na konkrétní komunitní síti - jméno a příjmení, přezdívku, fotografii a podobně. Třída byla navržena s ohledem na fakt, že se informace používané komunitními sítěmi mohou lišit. Za zmínku

17

18

KAPITOLA 4. ANALÝZA

dále stojí atributy dateRegistration a timeRegistration, které udržují datum a čas prvního přístupu uživatele do systému z dané komunitní sítě. Atributy dateLastActivity a timeLastActivity jsou použity pro uchování data a času posledního přístupu do systému z této sociální sítě. Třída SocialGameStatistics obsahuje statistiku herních výsledků a bodů uživatele pro konkrétní společenskou hru. Pro obecnost statistiky byla vytvořena třída SocialGameResult, která jednoduchým způsobem zajistí uchování statistiky umístění i pro hry s různým počtem hráčů.

Obrázek 4.2: Doménový model - uživatelé

4.1.2

Společenské hry

Balíček Games (obrázek 4.2) obsahuje třídy popisující společenské hry, jejich možná nastavení a jednotlivá herní klání konkrétních společenských her. Třída SocialGame představuje společenskou hru, která bude v systému implementována (jedná se např. o hru pexeso). Třída SocialGameMetaSetting pak její možná nastavení - např. minimální počet hráčů s množinou různých hodnot. Poměrně zajímavou třídou (z analytického hlediska) je SocialGamePlay, která uchovává informaci o proběhnuvším herním klání konkrétní společenské hry. Její jednotlivé metody jsou vysvětleny v tabulce 4.1, atributy potom v tabulce 4.2. Informace, které potřebujeme u jednotlivých společenských her uchovávat, se mohou lišit. Na diagramu je proto použita dědičnost. Dále je z diagramu patrné přepsání jednotlivých metod dětskými třídami, což umožňuje polymorfní počítání odměn či výsledků pro každou hru.

4.2. REALIZACE PŘÍPADŮ UŽITÍ Metoda calculateAwards

19

Popis Vypočte odměny pro jednotlivé hráče v závislosti na jejich umístění. Vypočte skutečné umístění hráčů podle průběhu dané hry.

calculatePlacing

Tabulka 4.1: Popis metod třídy SocialGamePlay a jejích potomků Atribut awards date, time players

settings placing onTurnPlayer disconnectedPlayers turns

Popis Změny bodů jednotlivých hráčů v závislosti na jejich pořadí v atributu placing Datum a čas hry. Hráči v pořadí, v jakém skutečně hrají (jejich počet zde není nĳak omezen - limitován bude pomocí nastavení konkrétní společenské hry). Konkrétní nastavení zvolená pro tuto hru z množiny definované pomocí objektů SocialGameMetaSetting. Hráči v pořadí určeném výsledkem dané hry. Hráč, který je právě na tahu. Hráči, kteří se v průběhu hry odpojili, v pořadí, v jakém k tomu došlo. Historie tahů dané hry (možnost rekonstrukce průběhu hry).

Tabulka 4.2: Popis atributů třídy SocialGamePlay

4.2

Realizace případů užití

Posledním krokem pro úspěšné dokončení analýzy systému je realizace případů užití, pro kterou jsem zvolil sekvenční diagramy. V této fázi jsem vytvořil pouze sekvenční diagramy případů užití běžného uživatele, které byly popsány a specifikovány v sekci 3.3.1. K ostatním případům užití nebyly v rámci analýzy sekvenční diagramy vytvořeny zejména z prostorových důvodů. V případě potřeby budou tyto sekvenční diagramy doplněny v kapitole 5 a budou k dispozici na CD přiloženém k elektronické verzi odevzdání bakalářské práce.

4.2.1

Otevřít herní místnost

Na obrázku 4.4 je pomocí sekvenčního diagramu znázorněn scénář případu užití UC101 Otevřít herní místnost, jehož specifikace byla vymezena v tabulce 3.1. Pro větší jednoduchost diagramu není v tuto chvíli uvažováno získání informací o přihlášeném uživateli z prostředí komunitní sítě, uložení získaných údajů do systému (vytvoření nového nebo aktualizace existujícího objektu ApplicationUser) a ani související automatické získání identifikace místnosti přihlášeného uživatele. Tomuto procesu se budu podrobněji věnovat v kapitole 5.

20


Obrázek 4.3: Doménový model - společenské hry

4.2.2

Připojit se do existující herní místnosti

Na obrázku 4.5 je zobrazen scénář případu užití UC103 Připojit se do otevřené herní místnosti, jenž byl definován v tabulce 3.3. Stejně jako u předchozího sekvenčního diagramu nebylo pro přehlednost diagramu uvažováno získání informací o přihlášeném uživateli z prostředí komunitní sítě, ani uložení získaných údajů do systému.

4.2. REALIZACE PŘÍPADŮ UŽITÍ

Obrázek 4.4: Sekvenční diagram - otevřít herní místnost

Obrázek 4.5: Sekvenční diagram - připojit se do otevřené herní místnosti

21

22


Kapitola 5

Návrh Obsahem kapitoly je podrobná specifikace způsobu, jakým budou implementovány požadované funkce systému, definované v kapitolách 3 a 4. Pro dosažení této specifikace jsou použity následující modely: • model architektury (5.1), • model návrhových tříd (5.2), • model komunikace (5.3), • model stavových diagramů (5.4), • model uživatelského rozhraní (5.5), • model nasazení (5.6).

5.1

Model architektury

Již v samotném zadání bakalářské práce je zmínka o vrstvách aplikace - konkrétně o vrstvě prezentační, aplikační, serverové a databázové. Architekturu aplikace jsem nakonec zvolil jako pětivrstvou. Přibyla vrstva autorizační, která zajišťuje odstínění aplikace od způsobu autorizace na jednotlivých komunitních sítích. Pro komunikaci mezi jednotlivými vrstvami jsou navržena rozhraní, díky kterým lze otestovat jednotlivé části systému samostatně. V případě potřeby to také umožňuje snadnou výměnu např. celé prezentační vrstvy bez nutnosti zásahu do jiných vrstev systému. Podrobnější popis metod jednotlivých navržených rozhraní je obsažen v interaktivní dokumentaci na přiloženém CD (viz E). Jedinou výjimku ve způsobu komunikace tvoří interakce mezi autorizační a prezentační vrstvou, která je zajištěna pomocí parametrů předaných do prezentační vrstvy (viz 5.3). Model architektury je zobrazen na přiloženém diagramu komponent 5.1, technologie, které byly zvoleny pro implementaci jednotlivých vrstev, jsou popsány v sekci 5.6.

23

24

KAPITOLA 5. NÁVRH

Obrázek 5.1: Model architektury aplikace

5.1.1

Autorizační vrstva

Autorizační vrstva odstiňuje zbytek aplikace od různých způsobů autorizace na konkrétních sociálních sítích. Komunikovat bude s aplikační vrstvou (kvůli vytvoření nebo aktualizaci údajů uživatele z dané komunitní sítě) přes rozhraní IUser a do prezentační vrstvy bude předávat parametry jako identifikátor uživatele a spouštěné herní místnosti. Komunikaci mezi komunitní sítí, autorizační a prezentační vrstvou aplikace je věnována kapitola 5.3.

5.1.2

Prezentační vrstva

Prezentační vrstva zajistí zobrazení prováděných činností v herní místnosti a interakci s uživatelem. Z autorizační vrstvy dostane předané parametry jako identifikaci uživatele a herní místnosti. Pro komunikaci se serverovou a aplikační vrstvou jsou navržena rozhraní. Návrhu prezentační vrstvy je věnována také kapitola 5.5.

5.2. MODEL NÁVRHOVÝCH TŘÍD

5.1.3

25

Serverová vrstva

Serverová vrstva zprostředkovává připojování uživatelů, rozesílání zpráv do chatu i herní logiku společenských her pro jednotný stav dané hry na všech připojených prezentačních vrstvách (klientech). Pro komunikaci s aplikační i prezentační vrstvou jsou navržena rozhraní znázorněná na obrázku 5.1.

5.1.4

Aplikační vrstva

Aplikační vrstva obsahuje třídy a komponenty, které realizují chování systému z pohledu obchodní logiky. Komunikuje s datovou (databázovou) vrstvou prostřednictvím definovaných rozhraní. Ostatním vrstvám systému zpřístupňuje rozhraní viz diagram na obrázku 5.1.

5.1.5

Databázová (datová) vrstva

Databázová vrstva zajišťuje ukládání datových objektů do perzistentního úložiště prostřednictvím metod specifikovaných rozhraními, která jsou zobrazena na obrázku 5.1.

5.2

Model návrhových tříd

Model návrhových tříd obsahuje statický popis systému a upřesňuje doménový model z kapitoly 4.1. Třídy a rozhraní jsou rozděleny do balíčků podle jednotlivých vrstev systému, což zobrazuje diagram na obrázku 5.2. Pro názvy všech balíčků jsou použity jmenné konvence umožňující přímé vygenerování kódu některých částí systému.

Obrázek 5.2: Model návrhových tříd - balíčky

Kvůli nedostatku prostoru v hlavním textu uvádím pouze nejzajímavější třídy z aplikační vrstvy, na kterých lze přímo pozorovat transformaci z analytického do návrhového modelu. Ostatní balíčky obsahují třídy, které vznikly až v době návrhu - jedná se převážně o třídy, rozhraní a výčty modelující způsob, jakým budou implementovány funkce systému. Všechny třídy a diagramy jsou k prohlédnutí v interaktivní dokumentaci, která je k dispozici na CD přiloženém k elektronickému odevzdání bakalářské práce (viz E). Tato interaktivní dokumentace byla vygenerována CASE nástrojem Entreprise Architect.

26

5.2.1

KAPITOLA 5. NÁVRH

Aplikační vrstva (balíček businessLayer)

Třídy v tomto balíčku byly vytvořeny iterativní specifikací analytických tříd z části 4.1 s ohledem na možnost automatického vygenerování kódu. Přechod od analýzy k návrhu popisuji pouze pro třídy uživatelů systému. Obdobným způsobem jsem transformaci provedl i pro třídy společenských her.

Uživatelé (balíček businessLayer.entities.users) V balíčku jsou obsaženy detailně rozpracované třídy uživatelů systému a jejich herních výsledků zanalyzované v kapitole 4.1.1. Při transformaci z analytického modelu do modelu návrhového byly upřesněny relace mezi jednotlivými třídami na vztah pomocí agregace a byla specifikována jednosměrná průchodnost všech těchto vztahů. Dále byly definovány datové typy všech atributů, parametrů metod i návratových typů metod. Návrhová podoba tříd je k vidění na obrázku 5.3. Z důvodu nedostatku prostoru byly v diagramu skryty přístupové metody atributů (tedy metody pro nastavení a vrácení hodnoty atributu). Tentýž diagram v době analýzy je k dispozici na obrázku 4.2.

5.3

Model komunikace

Kapitola popisuje přiřazení zodpovědnosti a interakci tříd při realizaci požadovaných funkčností. Zaměřuji se pouze na popisy spolupráce objektů, které jsou z pohledu objektově orientovaného návrhu zajímavé.

5.3.1

Spuštění aplikace

Nejzajímavějším diagramem této části je sekvenční diagram popisující spolupráci mezi uživatelem, komunitní sítí, autorizační a prezentační vrstvou při samotném spuštění aplikace. Jak je podrobněji popsáno v části 5.6, aplikace je realizována jako webová aplikace, což byl také jeden z požadavků zadavatele bakalářské práce. Spolupráce mezi zmíněnými subjekty při spuštění je znázorněna na diagramu B.3, umístěném v dodatku B.2.1. Tento diagram je modelován podle komunikace se sociální sítí MySpace. Na ostatních sociálních sítích, zvolených pro nasazení aplikace (viz 2.2), je proces podobný.

5.3.2

Zahájení interakce uživatelem

Interakce začíná při otevření URL adresy aplikace uživatelem na sociální síti, kde je aplikace nasazena. Komunitní síť předá autorizační vrstvě systému parametry s informacemi o uživateli, který aplikaci spouští, o aplikaci samotné a mnoho dalších. Typy a názvy parametrů závisí na konkrétní sociální síti. Z tohoto důvodu se autorizační vrstva skládá z několika tříd - každá třída zprostředkovává komunikaci s jednou sociální sítí.

5.3. MODEL KOMUNIKACE

5.3.3

27

Instalace aplikace uživatelem

Z předaných parametrů autorizační vrstva zjistí, zda má uživatel aplikaci na sociální síti nainstalovanou - zda si ji přidal do svého uživatelského profilu. Pokud ne, autorizační vrstva zavolá URL komunitní sítě pro instalaci aplikace, jejímž obsahem je i adresa pro přesměrování po zpracování požadavku. Další postup závisí na rozhodnutí uživatele, pokud si aplikaci nepřidá, proces zde končí. V opačném případě je po zpracování požadavku komunitní sítí znovu načtena autorizační vrstva, tentokrát s již nainstalovanou aplikací.

Obrázek 5.3: Model návrhových tříd - uživatelé

28

KAPITOLA 5. NÁVRH

5.3.4

Zpracování údajů uživatele

Zpracováním údajů uživatele se rozumí proces uložení informací o novém uživateli aplikace, případně aktualizace údajů již existujícího uživatele. Tyto kroky byly pro přehlednost přesunuty do diagramu user, který je k dispozici v dodatku B.4 a nepotřebuje bližší vysvětlení.

5.3.5

Určení vztahu uživatele k požadované místnosti

Dalším krokem nutným pro spuštění aplikace je určení vztahu uživatele k požadované herní místnosti. Pokud uživatel otevřel URL adresu aplikace bez parametru identifikace herní místnosti, je jako identifikátor použita identifikace jeho vlastní místnosti. V případě, že uživatel otevírá svou vlastní místnost, následuje proces podobný instalaci aplikace - dotaz na povolení změny statusu uživatele na komunitní síti, ovšem s tím rozdílem, že i bez povolení uživatelem lze pokračovat ve spuštění.

5.3.6

Načtení prezentační vrstvy

Posledním krokem, potřebným pro načtení aplikace, je předání parametrů prezentační vrstvě, konkrétně identifikátoru uživatele a identifikátoru požadované herní místnosti. Prezentační vrstva bude realizována pomocí technologie Adobe Flash (viz 5.5). Pro předání parametrů z autorizační vrstvy budou použity tzv. flashVars1 .

5.4

Model stavových diagramů

V kapitole jsou pomocí diagramů stavových automatů modelovány aspekty dynamického chování systému se zaměřením na nejzajímavější části aplikace.

5.4.1

Stavový automat herní místnosti

Nejzajímavější reaktivní objekt, na němž lze pomocí stavového automatu ukázat přechod mezi stavy v průběhu jeho životního cyklu, je konkrétní herní místnost. Diagram na obrázku 5.4 ukazuje dva stavy - uzavřenou a otevřenou herní místnost. Každá herní místnost je vždy právě v jednom z těchto stavů. Konkrétní stav závisí na faktu, zda je v místnosti připojen administrátor.

Obrázek 5.4: Model statových automatů - stavový automat herní místnosti

1

Parametry předané z webové stránky do Flashe (SWF souboru)

5.5. MODEL UŽIVATELSKÉHO ROZHRANÍ

5.4.2

29

Stavový automat uživatelského rozhraní aplikace

Druhý modelovaný diagram, který je zobrazen na obrázku 5.5, popisuje stavy a přechody pro uživatelské rozhraní aplikace. Informace o jednotlivých stavech (tedy obrazovkách systému) jsou uvedeny v části 5.5. S výjimkou odpojení uživatele nebo administrátora místnosti jsou všechny přechody mezi jednotlivými stavy prováděny automaticky, vždy v závislosti na konkrétním stavu místnosti a dalších okolnostech - např. selhání spojení se serverem apod. Z diagramu je zřejmé, že uživatel připojený k uzavřené herní místnosti má zobrazenu přihlašovací obrazovku, kde je o stavu místnosti informován. Pokud se ale administrátor místnosti připojí, bude tento uživatel automaticky přesměrován do herní místnosti (pokud ovšem aplikaci do té doby sám neukončí).

Obrázek 5.5: Model statových automatů - stavový automat uživatelského rozhraní

5.5

Model uživatelského rozhraní

Od zadavatele bakalářské práce vzešel požadavek na technologii použitou pro implementaci prezentační vrstvy aplikace - Adobe Flash2 - viz nefunkční požadavky na použité technologie v části 3.1.1. Technologie přináší několik zásadních výhod jako např. možnost změny vzhledu celé aplikace pomocí předkompilovaného externího CSS stylu (změnu vzhledu lze provést i dynamicky, za běhu aplikace), předpřipravené a snadno použitelné grafické efekty a samozřejmě možnost zkompilování všech použitých zdrojů do jednoho výsledného souboru ve formátu SWF3 . 2 3

http://www.adobe.com/products/flash/. Shockwave Flash http://www.adobe.com/devnet/swf/.

30

KAPITOLA 5. NÁVRH

Tato kapitola se věnuje návrhu aplikace z hlediska grafického uživatelského rozhraní. V CASE nástroji Entreprise Architect byl vytvořen prototyp uživatelského rozhraní herní místnosti. Grafický návrh vnitřku herní místnosti, který je zobrazen na obrázku 5.6, bere ohled na možná omezení šířky aplikace ze strany sociálních sítí - např. komunitní web Facebook povoluje šířku maximálně 760 pixelů. Návrh obrazovky, zobrazené v případě, že se uživatel připojí k uzavřené herní místnosti (její správce nebude připojen), stejně jako všechny další diagramy uživatelského rozhraní, jsou k dispozici v interaktivní dokumentaci na přiloženém CD (viz E).

5.5.1

Herní místnost

Celkový koncept herní místnosti je rozdělen do tří částí, jejichž některé prvky se liší pro administrátora a návštěvníka místnosti. Prototyp uživatelského rozhraní je na obrázku 5.6, jednotlivé oblasti jsou popsány dále v textu. Hlavní administrační panel Společnými prvky pro všechny uživatele místnosti jsou v této oblasti logo aplikace, zobrazené v levé částí horizontálního panelu, a identifikace správce místnosti, situovaná v části pravé. Obrázková tlačítka, umístěná napravo od loga aplikace, slouží pro zahájení nové společenské hry - tato funkce je přístupná pouze pro správce místnosti. Kliknutí na tlačítko konkrétní hry zobrazí modální okno s nastavením nové hry. Prototyp tohoto okna pro hru pexeso je přiložen v dodatku B.3.1. Hrací plocha Vzhled hrací plochy je společný pro všechny uživatele připojené v místnosti, liší se pouze možností provádění tahů. Přesněji řečeno kliknutí na konkrétní hrací pole vyvolá akci pouze pokud jej provedl uživatel, který je v dané hře právě na tahu. Standardní rozložení hrací plochy je zobrazeno na obrázku B.6 v dodatku B.3.2. Informační panel Vertikální panel v pravé části místnosti obsahuje seznam připojených uživatelů. Administrátor místnosti má u jednotlivých uživatelů zobrazené tlačítko pro jejich odpojení z místnosti. U každého uživatele je zobrazen počet jeho dosažených bodů pro každou implementovanou hru. Po najetí kurzorem myši se objeví statistika všech odehraných klání uživatele v dané společenské hře. V dolní polovině panelu je situován veřejný chat. Posílání zpráv bude implementováno kliknutím na tlačítko Odeslat, nebo stisknutím klávesy ENTER při aktivním textovém poli zprávy. Administrátor místnosti vidí navíc tlačítko pro smazání obsahu chatu. Pod chatem je prostor pro případné další logo. Kvůli omezení maximální šířky celé aplikace v prostředí sociálních sítí bude možné skrýt nebo opětovně zobrazit celý informační panel. Tím je dosaženo maximálního využití prostoru např. pro situace, kdy bude v místnosti probíhat herní klání.

5.6. MODEL NASAZENÍ

31

Obrázek 5.6: Model uživatelského rozhraní - hlavní obrazovka aplikace

5.6

Model nasazení

Kapitola popisuje nasazení aplikace a umístění jednotlivých jejích částí na fyzická zařízení. Na obrázku 5.7 je diagram nasazení systému, na kterém jsou znázorněny technologie zvolené pro jednotlivé části systému i pro počítač uživatele.

Celá aplikace bude koncipována jako webová aplikace a bude možné ji spouštět na osobním počítači, který obsahuje internetový prohlížeč a přehrávač Adobe Flash Player. Hlavní výhodou je fakt, že si uživatel na svůj počítač samotnou aplikaci nemusí instalovat.

32

KAPITOLA 5. NÁVRH

5.6.1


Autorizační vrstva bude nasazena na server s operačním systémem Microsoft Windows a prostředím pro spouštění realizované technologií Microsoft .NET4 . Autorizační vrstva bude realizována pomocí souborů ASPX5 , které umožňují oddělení funkční logiky od zobrazení pomocí přístupu code-behind model. To znamená, že vzhled stránky je deklarován v souboru s příponou .aspx a funkční logika těchto tříd potom v souboru ve formátu .aspx.cs. Jazykem zvoleným pro implementaci této části je robustní jazyk C#, který obsahuje řadu užitečných knihoven. Použití této technologie bylo také požadavkem zadavatele bakalářské práce.

5.6.2


Prezentační vrstva může být nasazena na server s libovolným operačním systémem. Jedná se pouze o umístění souboru ve formátu SWF. Jak již bylo zmíněno v sekci 5.5, prezentační vrstva bude realizována pomocí technologie Adobe Flash. Jazykem zvoleným pro implementaci je ActionScript 3.0, který se oproti předchozím verzím vyvinul na téměř plně objektově orientovaný jazyk - více informací o rozdílech viz článek na [2].

5.6.3

Serverová vrstva

Serverová vrstva může být nasazena na server s libovolným operačním systémem, kde je nainstalováno prostředí pro spouštění JRE6 a program Wowza Media Server. Ten byl zvolen hlavně díky možnosti implementace v jazyce Java a díky existujícímu IDE, se kterým bude vývoj serverové části o mnoho snazší.

5.6.4

Aplikační vrstva

Aplikační vrstva bude (stejně jako vrstva autorizační) nasazena na server s operačním systémem Microsoft Windows a prostředím pro spouštění Microsoft .NET. Realizována bude pomocí webových služeb (angl. web services) - tedy tříd, které umožňují volání metod přes protokol SOAP7 . Jeho hlavní výhodou je platformová nezávislost a také možnost zobrazení seznamu poskytovaných metod i s krátkými komentáři přes webový prohlížeč.

5.6.5


Databázová vrstva bude nasazena na server s operačním systémem Microsoft Windows a s nainstalovaným prostředím pro spouštění Microsoft SQL Server. Z diagramu 5.7 je patrné, že datová vrstva může běžet na jiném počítači než vrstva aplikační, přestože to není podmínkou. Databáze Microsoft SQL byla zvolena hlavně kvůli nástroji Microsoft SQL Server Management Studio a kvůli požadavku od zadavatele bakalářské práce. 4

Platforma Microsoft .NET viz http://www.microsoft.com/net/. Active Server Pages eXtension viz http://www.asp.net. 6 Java Runtime Environment viz http://www.sun.com/java/. 7 Simple Object Access Protocol je protokol pro výměnu zpráv založených na XML přes síť, pomocí HTML. 5

5.6. MODEL NASAZENÍ

33

Obrázek 5.7: Model nasazení systému

34

KAPITOLA 5. NÁVRH

Kapitola 6

Implementace Obsahem kapitoly je popis implementace systému se zaměřením na nejzajímavější použité principy a řešení. Pro přehlednost je kapitola rozdělena do částí, které přesně odpovídají jednotlivým vrstvám systému a které jsou seřazeny za sebou tak, jak byly ve skutečnosti implementovány. V závěru kapitoly je vložen snímek obrazovky z aplikace na sociální síti Facebook. Obrázky ze stejného herního klání na dalších komunitních sítích jsou k dispozici v dodatku C.1.

6.1


Skripty pro vytvoření tabulek byly automaticky vygenerovány přímo z modelů vytvořených ve fázi návrhu v CASE nástroji Entreprise Architect. Proces implementace databázové vrstvy tedy spočíval pouze v napsání skriptů uložených procedur a provedení všech skriptů nad perzistentním úložištěm.

6.2

Aplikační vrstva

Asi nejzajímavějším řešením v aplikační vrstvě je elegantní načítání a ukládání entitních tříd. V kapitole 5 bylo navrženo, že se každá entitní třída bude umět sama zkonstruovat z objektu SqlDataReader, který obsahuje data načtená z databázové vrstvy pomocí funkce SqlMappingGet. Při implementaci jsem si uvědomil, že když se objekt umí „přečíst“ z datového úložiště, měl by znát i způsob, jakým se uložit. K tomuto účelu byla vytvořena třída DatabaseObject, která obecně představuje třídu, která je v aplikaci ukládána do perzistentního úložiště. Od ní potom dědí kokrétní třídy, které polymorfním způsobem přepisují funkce GetStoredProcedureParameterNames a GetStoredProcedureParameterValues. Ty podle názvu požadované operace (uložení, načtení, atd.) vrací názvy parametrů a jejich hodnoty. Z těchto informací je ve funkci GetStoredProcedureInfo vytvořen objekt StoredProcedureInfo, ze kterého už je možné přímo konstruovat dotaz pro databázovou vrstvu.

35

36

KAPITOLA 6. IMPLEMENTACE

6.3 6.3.1

Autorizační vrstva Implementace pro různé komunitní sítě

Způsob implementace autorizační vrstvy se pro jednotlivé sociální sítě liší. Tento fakt byl hlavním důvodem, proč byla autorizační vrstva v aplikaci vůbec navržena. Vývoj tedy popíši pro každou sociální síť zvlášť. Facebook Díky rozšířenosti komunitní sítě Facebook je na internetu k dispozici celá řada hotových knihoven pro interakci s touto sítí na platformě .NET - viz přehled na [10]. Při implementaci jsem využil existující knihovny Facebook Developper Toolkit1 , která je volně k dispozici a jednoduchým způsobem umožňuje získání informací o přihlášeném uživateli i publikování zprávy do statusu. MySpace Pro interakci s komunitním webem MySpace jsem využil otevřeného protokolu OAuth2 . Princip OAuth zde nebudu podrobně popisovat, ve zkratce jsem na základě parametrů předaných do autorizační vrstvy z komunitní sítě vytvořil autorizovaný HTTP požadavek, se kterým již bylo možné přistupovat k API komunitní sítě a získat požadované informace o přihlášeném uživateli. Friendster Také pro sociální síť Friendster jsem využil protokolu OAuth. Implementace byla podobná jako pro komunitní web MySpace. Lišila se hlavně ve způsobu vytvoření autorizace HTTP požadavku protokolu OAuth a také strukturou uživatelských údajů v odpovědi na tento požadavek.

6.3.2

Rozšiřitelnost na další komunitní sítě

Při implementaci jsem si ověřil správnost návrhu autorizační vrstvy bakalářské práce. Díky tomu, že pro každou sociální síť je vytvořena samostatná třída, přidání aplikace na další místo neovlivní chování již implementovaného řešení. Lze tedy s jistotou říci, že jsem v tomto směru splnil zadání.

6.3.3

Propojitelnost účtů komunitních sítí

Aplikace byla navržena a implementována i s ohledem na fakt, že každý uživatel z jedné sociální sítě může mít účet i na dalších komunitních sítích, na které je aplikace nasazena, případně může mít pod jednou komunitní sítí více uživatelských účtů. Jelikož aplikace zaznamenává herní statistiky a výsledky jednotlivých uživatelů, je potřeba tomuto uživateli 1 2

Stránky projektu viz http://facebooktoolkit.codeplex.com. OAuth je otevřený protokol pro autorizaci proti API různých služeb (http://www.oauth.net).

6.4. PREZENTAČNÍ VRSTVA

37

umožnit přístup do aplikace i z různých komunitních sítí, případně z různých uživatelských účtů na jedné komunitní síti. Toto je realizováno pomocí vlastností socialNetworkUsers a currentSocialNetworkUser ve třídě ApplicationUser. Samotný proces propojení různých uživatelských účtů bude řešen samostatnou aplikací vždy na konkrétní komunitní síti a není součástí této práce.

6.4


Je třeba zmínit, že vývoj prezentační a serverové vrstvy probíhal v podstatě paralelně. Uvedené pořadí je v tomto případě spíše orientační. Nejprve jsem implementoval základní logiku uživatelského rozhraní herní místnosti, která je znázorněna ve stavovém diagramu 5.4 v části 5.4.1. Dále jsem postupně implementoval modul veřejného chatu, seznam uživatelů v místnosti s herní statistikou a nakonec také moduly jednotlivých společenských her. Při realizaci prezentační vrstvy byla použita poměrně zajímavá řešení, některá z nich byla zmíněna již v sekcích 4.1.2 a 5.5.

Modularita řešení Pro možnost snadného rozšíření aplikace o další společenské hry pracuje prezentační vrstva se speciální třídou ModuleLoader, která umožňuje načtení externího SWF souboru za běhu aplikace. Pro každou společenskou hru je vytvořem jeden SWF soubor pro založení nové hry a volbu jejího nastavení a jeden SWF soubor pro samotnou hru.

Znovupoužitelnost řešení Jednotlivé moduly společenských her (ale i modul veřejného chatu a další) byly implementovány jako nezávislé komponenty splňující definovaná rozhraní. Díky tomu lze tyto moduly využít i v jiných projektech, pokud jim bude poskytnuta zdokumentovaná funkcionalita. Toto je důležité zejména pro možnost využití vytvořených komponent zadavatelem bakalářské práce.

Konfigurovatelnost Pro možnost snadné konfigurace společenských her byla v kapitole 5 navržena třída SocialGameMetaSetting. Před založením společenské hry si prezentační vrstva dotazem na aplikační vrstvu zjistí všechna možná nastavení této hry - např. možné hodnoty počtu hráčů. Díky tomu lze bez zásahu do zdrojového kódu hotové aplikace změnit například minimální nebo maximální velikost hracího pole pro hru pexeso.

Skinovatelnost Jak již bylo zmíněno v části 5.5, aplikace využívá externího CSS stylu, který je zkompilován do SWF souboru. Díky načítání tohoto skinu za běhu aplikace lze bez zásahu do zdrojového kódu prezentační vrstvy pozměnit její vzhled.

38

KAPITOLA 6. IMPLEMENTACE

Obrázek 6.1: Snímek obrazovky z aplikace na sociální síti Facebook

6.5

Serverová vrstva

Hlavně díky dobře zvolené technologii pro serverovou vrstvu nebyl proces implementace příliš náročný. Využil jsem pro něj vývojové IDE přímo od tvůrců Wowza Media Server společnosti Wowza Media Systems3 . Použitím třídy ModuleBase jsem serverovou část rozdělil do několika nezávislých modulů. To je důležité zejména pro snadnou možnost rozšíření o další společenské hry, zmíněnou v zadání bakalářské práce.

3

Wowza Media Server IDE 2 - viz http://www.wowzamedia.com/usefuldownloads.html.

Kapitola 7

Testování Obsahem kapitoly je popis testování implementovaného systému, které jsem prováděl již v průběhu realizace. Pro větší přehlednost mu ale věnuji samostatnou kapitolu. Na jejím začátku je uvedena konfigurace počítače koncového uživatele, použitého pro testování celého systému. Dále následuje popis způsobu, jakým byla ověřena správná funkčnost jednotlivých vrstev systému. Tato část je členěna obdobně jako kapitola 6.

7.1

Konfigurace testovacího PC

Testování jsem prováděl již v průběhu realizace přímo na počítači, na kterém jsem aplikaci vyvíjel. Hardwarová konfigurace počítače (tabulka 7.1) hraje významnou roli pro serverové části aplikace, i tyto byly testovány na lokálním počítači. Softwarové vybavení je uvedeno v tabulce 7.2, ve které je také uvedena verze runtime prostředí Java, na kterém byla aplikace testována. Jak je zmíněno v sekci 5.6, toto je potřeba pouze pro serverovou vrstvu (aplikace bude uživateli fungovat i bez nainstalovaného prostředí Java). Název Operační paměť Procesor Disk Rychlost připojení (download) Rychlost připojení (upload)

Hodnota 4GB DDR2 RAM Intel Core i5 2 * 250 GB 7200 RPM 8192 kbps 8192 kbps

Tabulka 7.1: Hardwarová konfigurace testovacího počítače

7.2

Testování jednotlivých vrstev aplikace

Jednotlivé části jsou za sebou seřazany tak, jak byly ve skutečnosti implementovány a testovány (pořadí je tedy stejné jako v kapitole 6).

39

40

KAPITOLA 7. TESTOVÁNÍ Název Operační systém Runtime prostředí Adobe Flash Player Runtime prostředí Java Webový prohlížeč Firefox Webový prohlížeč Chrome Webový prohlížeč Internet Explorer

Verze Windows 7 Home Premium 64bit 10.0.45.2 6.20 3.6.3 4.1.249.1064 8.0.7600.16385IC

Tabulka 7.2: Softwarové vybavení testovacího počítače

7.2.1


Databázovou vrstvu jsem podrobil manuálnímu testování v programu Microsoft SQL Server Management Studio 20081 , ve kterém je možné spouštět uložené procedury s parametry a okamžitě zobrazit výsledek operace.

7.2.2

Aplikační vrstva

Ověření správné funkčnosti aplikační vrstvy jsem prováděl způsobem založeným na principu testování jednotek, anglicky unit testing. Aplikační vrstva je implementována pomocí webových služeb, jejichž operace s jednoduchými vstupními parametry lze na lokálním počítači testovat přímo z webového prohlížeče. Proto jsem vytvořil testovací metody pouze pro operace, které slouží pro ukládání objektů, které jsem pro možnost jednoduššího spouštění umístil přímo vedle testovaných metod a spouštěl také manuálně z webového prohlížeče.

7.2.3


Jelikož autorizační vrstva spolupracuje se službami třetích stran, bylo potřeba otestovat, zda se chovají očekávaným způsobem. S výjimkou sociální sítě Facebook jsem pro všechny komunitní sítě využil jimi poskytnuté testovací nástroje. Tyto jsou uvedeny v tabulce 7.3. Pro komunitní síť Facebook jsem využil knihovny Facebook Developer Kit, kterou jsem otestoval manuálně přímo v programu Microsoft Visual Studio 2008. Komunitní síť Friendster MySpace

Adresa testovací utility http://api.friendster.com/ http://developer.myspace.com/modules/apis/pages/ devtool.aspx

Tabulka 7.3: Použité testovací nástroje jednotlivých komunitních sítí Při testování jednotlivých tříd autorizační vrstvy jsem využil možnosti nastavit hodnotu Callback URL2 na komunitní sítích na adresu lokálního serveru. Díky tomu jsem mohl již při 1 2

Více informací viz http://msdn.microsoft.com/library/ms174173.aspx. Adresa, které jsou předány parametry při spuštění aplikace v prostředí komunitní sítě.

7.2. TESTOVÁNÍ JEDNOTLIVÝCH VRSTEV APLIKACE

41

implementaci testovat odpovědi API na zasílané požadavky v reálném čase přímo v nástroji Microsoft Visual Studio 2008.

7.2.4


Jak již bylo zmíněno v části 6.4, vývoj prezentační vrstvy probíhal po jednotlivých funkčních komponentách. Před začátkem další vývoje další jednotky byla předchozí realizovaná vždy manuálně otestována přímo ve vývojovém prostředí Adobe Flash Builder 4.

7.2.5

Serverová vrstva

Testování serverové vrstvy bylo úzce provázáno s testováním vrstvy prezentační. Prováděl jsem jej manuálně ve vývojovém prostředí Wowza Media Server IDE 2. V jeho průběhu jsem objevil nepříjemnou skutečnost - objekty přenášené mezi serverovou a prezentační vrstvou nelze automaticky serializovat. Vytvoření transportních objektů a jejich konverzi na třídy z aplikační vrstvy jsem nakonec musel realizovat ručně v obou vrstvách aplikace. Zátěžové testování Maximální počet současně připojených uživatelů k aplikaci nelze přesně stanovit, nicméně bylo provedeno zátěžové testování pro 10 paralelně provedených spojení. Počítač, na kterém je nainstalován Wowza Media Server svou hardwarovou konfigurací odpovídá minimálním požadavkům uvedeným na [27] a aplikace by tedy měla „přiměřený“ nápor uživatelů vydržet. V případě extrémního rozšíření (odhadováno na 1000 uživatelů současně a více) bude toto řešeno pořízením dalších serverů a tzv. clusteringem3 .

3

Princip, kdy je více fyzických zařízení (počítačů) spojeno pomocí software v jedno výkonnější zařízení.

42

KAPITOLA 7. TESTOVÁNÍ

Kapitola 8

Závěr Hlavním cílem bakalářské práce bylo zanalyzovat, navrhnout a implementovat společnou aplikaci pro různé komunitní sítě, nezávislou na komunitní síti, ve které bude spuštěna. V teoretické části práce byly nejprve vybrány vhodné komunitní sítě pro vývoj aplikace a byla navržena speciální autorizační vrstva, která ostatní vrstvy aplikace odstínila od různorodého způsobu autorizace na sociálních sítích. V praktické části bakalářské práce byla autorizační vrstva pro vybrané sociální sítě implementována a také otestována. Dalším cílem bakalářské práce bylo umožnit hraní zvolených společenských her mezi jednotlivými uživateli aplikace a zaznamenání jejich výsledků. V teoretické části bakalářské práce byly zvoleny společenské hry hodící se pro počítačové zpracování. Dále byl navržen obecný způsob uchovávání herních výsledků pro všechny společenské hry, nezávisle na počtu hráčů jednotlivých herních klání. V praktické části bakalářské práce byla implementována a otestována databázová (datová), aplikační, prezentační i serverová vrstva pro zvolené společenské hry. V neposlední řadě byl cílem práce modulární návrh aplikace, aby ji bylo možné rozšiřovat o další společenské hry a implementace prezentační, aplikační, serverové i databázové vrstvy. V teoretické části bakalářské práce byla navržena architektura aplikace, skládající se z jednotlivých vrstev a komponent. Komponenty společenských her byly v praktické části realizovány jako funkční celky, které lze pomocí konfigurace v databázové vrstvě do aplikace dynamicky načítat. Všechny zmíněné vrstvy byly implementovány moderními technologiemi, jejichž výběr byl konzultován se zadavatelem bakalářské práce, společností iCORD International s.r.o. Bakalářská práce splnila všechny popsané cíle a zmíněná aplikace již byla úspěšně nasazena na všechny zvolené sociální sítě, kde je jejich uživatelům plně k dispozici. Některé použité postupy a řešení, blíže popsané v kapitole 6, byly integrovány do nových projektů zadavatele bakalářské práce, což bylo jedním z hlavních důvodů spolupráce. Lze tedy říci, že i tato očekávání bakalářská práce naplnila.

Možné pokračování práce Bakalářskou práci je možné rozšířit na další komunitní sítě a místa, která v budoucnosti splní kritéria definovaná v kapitole 2.2.1. Je také možné zvážit její napojení na jiné autorizační

43

44

KAPITOLA 8. ZÁVĚR

protokoly, například na protokol LDAP1 . Díky modulárnímu návrhu aplikace je kdykoliv možné její rozšíření o další společenské hry.

1

Protokol pro ukládání a přístup k datům na adresářovém serveru.

Literatura [1] Seznam stránek v internetu s možností přístupu přes API. http://www.programmableweb.com/apis/directory, stav z 9. 1. 2010. [2] Tips for learning ActionScript 3.0. http://www.adobe.com/devnet/actionscript/articles/ actionscript_tips.html, stav ze 12. 3. 2010. [3] Entreprise Architect Status Types. http://www.sparxsystems.com/uml_tool_guide/ uml_model_management/statustypes.html, stav z 13. 1. 2010. [4] Chess Elo Rating. http://www.chesselo.com/, stav z 11. 1. 2010. [5] Statistika nejpoužívanějších aplikací na komunitním webu Facebook. http://statistics.allfacebook.com/applications/ leaderboard/, stav z 8. 1. 2010. [6] Propojení sociálních sítí Facebook a Twitter. http://www.facebook.com/twitter/, stav z 13. 1. 2010. [7] Facebook - nová aplikace. http://www.facebook.com/\#/developers/createapp.php, stav z 9. 1. 2010. [8] Statistika nejúspěšnějších vývojářů na komunitním webu Facebook. http://statistics.allfacebook.com/developers/leaderboard/, stav z 8. 1. 2010. [9] Hra piškvorky na sociální síti Facebook. http://apps.facebook.com/playfourinarow/, stav z 13. 1. 2010. [10] List of Facebook SDKs for .NET). http://www.marketing-ninja.com/old-stuff/list -of-facebook-sdks-for-net/,stav ze 28. 4. 2010. [11] Facebook - časová přímka firmy. http://www.facebook.com/press/info.php?timeline, stav ze 4. 1. 2010. [12] Facebook Developer Wiki - API. http://wiki.developers.facebook.com/index.php/API, stav z 9. 1. 2010.

45

46

LITERATURA

[13] Friendster Developer Platform API. http://www.friendster.com/developer, stav z 9. 1. 2010. [14] Hry - Centrum. http://hry.centrum.cz/, stav z 11. 1. 2010. [15] OpenSocial API - Google Code. http://code.google.com/intl/cs/apis/opensocial/, stav z 9. 1. 2010. [16] K336 info o závěřečných pracích. https://info336.felk.cvut.cz/, stav z 8. 1. 2010. [17] Statistika nejpoužívanějších aplikací na komunitním webu MySpace. http://apps.myspace.com/Modules/AppGallery/Pages/ index.aspx?lang=en-US\&st=totalinstalls, stav z 8. 1. 2010. [18] Propojení sociálních sítí MySpace a Twitter. http://www.myspace.com/apptweet/, stav z 13. 1. 2010. [19] MySpace - nová aplikace. http://developer.myspace.com/modules/ apps/pages/CreateAppAccount.aspx, stav z 9. 1. 2010. [20] MySpace Wiki - API. http://wiki.developer.myspace.com /index.php?title=Category:MySpace_API, stav z 9. 1. 2010. [21] Oficiální stránky projektu OpenSocial. http://www.opensocial.org/, stav z 9. 1. 2010. [22] OpenSocial - přehled webů zapojených do projektu. http://wiki.opensocial.org/index.php?title=Containers, stav z 9. 1. 2010. [23] Top Ten Search Engines. http://www.seoconsultants.com/search-engines/, stav z 9. 1. 2010. [24] Top 20 Most Popular Social Networking Websites. http://www.ebizmba.com/articles/social-networking -websites, stav ze 4. 1. 2010. [25] Social Networking Websites Review 2010. http://social-networking-websites-review .toptenreviews.com/, stav ze 10. 1. 2010. [26] Propojení sociálních sítí Twitter a LinkedIn. http://www.itbiz.cz/propojeni-twitter-linkedin/, stav z 13. 1. 2010. [27] Wowza Media Server Specifications. http://www.wowzamedia.com/specs.html, stav ze 26. 4. 2010.

Dodatek A

Seznam použitých zkratek API Application Programming Interface ASPX Active Server Pages Extension AS3 ActionScript 3 CASE Computer-Aided Software Engineering CD Compact Disc CSS Cascading Style Sheet C# C Sharp DAO Data Access Objects DB DataBase DDR2 Double Data Rate 2 GB Gigabyte GUI Graphical User Interface HTML HyperText Markup Language HTTP HyperText Transfer Protocol IDE Integrated Development Environment JRE Java Runtime Environment kbps kilobits per second LDAP Lightweight Directory Access Protocol PC Personal Computer PDF Portable Document Format

47

48

DODATEK A. SEZNAM POUŽITÝCH ZKRATEK

RAM Random Access Memory RPM Revolutions Per Minute SOAP Simple Object Access Protocol SDK Software Developer’s Kit SQL Structured Query Language SWF Shockwave File TCP/IP Transmission Control Protocol / Internet Protocol UDP User Datagram Protocol UML Unified Modeling Language URL Uniform Resource Locator XML Extensible Markup Language

Dodatek B

UML diagramy V dodatku se nacházejí UML diagramy, které nebyli kvůli přehlednosti zařazeny do hlavního textu.

B.1

Případy užití

Diagramy případů užití interakce administrátora B.1 a návštěvníka místnosti B.2 slouží jako doplněk kapitoly 3.3.

Obrázek B.1: Interakce systému s aktérem administrátor

49

50

DODATEK B. UML DIAGRAMY

Obrázek B.2: Interakce systému s aktérem návštěvník

B.2 B.2.1

Model komunikace Spuštění aplikace

Sekvenční diagram interakce mezi uživatelem, komunitní sítí, autorizační a prezentační vrstvou aplikace při jejím spuštění je na obrázku B.3 pro doplnění kapitoly 5.3.1.

B.2.2

Zpracování údajů uživatele

Sekvenční diagram interakce mezi autorizační a aplikační vrstvou při zpracování uživatelských údajů je na obrázku B.4 pro doplnění kapitoly 5.3.4.

B.3 B.3.1

Model uživatelského rozhraní Administrační okno společenské hry pexeso

Prototyp administračního okna pro volbu nastavení společenské hry pexeso je k dispozici na obrázku B.5 a je zde pro doplnění kapitoly 5.5.

B.3. MODEL UŽIVATELSKÉHO ROZHRANÍ

B.3.2

51

Standardní rozložení hrací plochy hry piškvorky

Prototyp standardního rozložení hrací plochy pro všechny hry, které mají jednu společnou hrací desku pro všechny uživatele. Diagram uživatelského rozhraní je zobrazen na obrázku B.6, pro hru pexeso bude podobný.

52


Obrázek B.3: Model komunikace - sekvenční diagram spuštění aplikace

B.3. MODEL UŽIVATELSKÉHO ROZHRANÍ

Obrázek B.4: Model komunikace - sekvenční diagram zpracování údajů uživatele

53

54


Obrázek B.5: Model uživatelského rozhraní - administrační okno společenské hry pexeso

Obrázek B.6: Model uživatelského rozhraní - standardní rozložení hrací plochy hry piškvorky

Dodatek C

Obrázky V dodatku se nacházejí obrázky, které nebyly kvůli přehlednosti zařazeny do hlavního textu.

C.1

Implementace

Následující dva obrázky jsou snímky obrazovky z aplikace na sociální síti MySpace (C.1) a Friendster (C.2). Slouží jako doplněk kapitoly 6.

55

56

DODATEK C. OBRÁZKY

Obrázek C.1: Snímek obrazovky z aplikace na sociální síti MySpace

C.1. IMPLEMENTACE

Obrázek C.2: Snímek obrazovky z aplikace na sociální síti Friendster

57

58

DODATEK C. OBRÁZKY

Dodatek D

Uživatelská příručka Jak již bylo zmíněno v sekci 5.6, systém je implementován jako webová aplikace a na počítači uživatele tedy není nutné aplikaci instalovat. Pro správné spuštění aplikace je ale třeba mít nainstalovaný Adobe Flash Player verze 101 a mít uživatelský účet na sociální síti Facebook, MySpace nebo Friendster. Pro potřeby testování i odevzdání jsem na zmíněných komunitních sítích vytvořil uživatelské účty, které lze pro vyzkoušení aplikace využít. Tyto jsou uvedeny u popisu spuštění aplikace na konkrétní sociální síti (D.2).

D.1

Identifikace herní místnosti

Aplikace je koncipována po herních místnostech, každý uživatel aplikace má k dispozici svou vlastní. Uživatel připojený ve své vlastní herní místnosti je jejím administrátorem a může například spouštět společenské hry. Uživatel připojený v cizí herní místnosti je její návštěvník. Identifikace herní místnosti se do aplikace předává pomocí GET parametru roomID.

D.1.1

Otevření vlastní herní místnosti

Pro otevření své vlastní herní místnosti stačí spustit aplikaci na konkrétní komunitní síti bez GET parametru roomID. Například otevření adresy http://apps.facebook.com/worldobg/ otevře herní místnost pro přihlášeného uživatele na síti Facebook.

D.1.2

Připojení se do cizí herní místnosti

Pro připojení se do cizí herní místnosti je třeba spustit aplikaci na konkrétní komunitní síti s GET parametrem roomID nastaveným na hodnotu požadované herní místnosti. Například otevření adresy http://apps.facebook.com/worldobg/?roomID=WOBG5 otevře herní místnost s identifikací WOBG5 pro přihlášeného uživatele na síti Facebook. Adresu herní místnosti s identifikací Vám poskytne její administrátor. Postup jakým ji zjistí je uveden v sekci D.3 v číslovaném seznamu u položky 8. 1

Program je zdarma ke stažení na stránkách společnosti Adobe - viz http://www.adobe.com/.

59

60

DODATEK D. UŽIVATELSKÁ PŘÍRUČKA

D.2

Spuštění aplikace

Nyní popíši spuštění aplikace pro vytvořené testovací uživatele na zmíněných komunitních sítích. Popsaný postup zařídí, aby všichni tři uživatelé byli připojeni v jedné herní místnosti, konkrétně v herní místnosti uživatele Lenka Nejedlá.

D.2.1

Spuštění aplikace na sociální síti Facebook

1. V internetovém prohlížeči otevřete URL adresu komunitní sítě, která je uvedená v tabulce D.1 a přihlaste se s uvedeným uživatelským jménem a heslem. 2. V internetovém prohlížeči otevřete URL adresu herní místnosti, která je uvedená v tabulce D.1 Název Adresa komunitní sítě Jméno uživatele Uživatelské jméno Heslo Adresa herní místnosti

Hodnota http://www.facebook.com Lenka Nejedlá [email protected] Abcd1234 http://apps.facebook.com/worldobg/?roomID=WOBG17

Tabulka D.1: Facebook - důležité údaje pro spuštění aplikace

D.2.2

Spuštění aplikace na sociální síti MySpace

1. V internetovém prohlížeči otevřete URL adresu komunitní sítě, která je uvedená v tabulce D.2 a přihlaste se s uvedeným uživatelským jménem a heslem. 2. V internetovém prohlížeči otevřete URL adresu herní místnosti uživatele Lenka Nejedlá, která je uvedená v tabulce D.2

Název Adresa komunitní sítě Jméno uživatele Uživatelské jméno Heslo Adresa herní místnosti Adresa herní místnosti Lenky Nejedlé

Hodnota http://www.myspace.com Petr Vomáčka [email protected] Abcd1234 http://profile.myspace.com/Modules/Applications/ Pages/Canvas.aspx?appId=182553 http://profile.myspace.com/Modules/Applications/ Pages/Canvas.aspx?appId=182553&appParams=roomID= WOBG17

Tabulka D.2: MySpace - důležité údaje pro spuštění aplikace

D.3. OBRAZOVKA HERNÍ MÍSTNOSTI

D.2.3

61

Spuštění aplikace na sociální síti Friendster

1. V internetovém prohlížeči otevřete URL adresu komunitní sítě, která je uvedená v tabulce D.3 a přihlaste se s uvedeným uživatelským jménem a heslem. 2. V internetovém prohlížeči otevřete URL adresu herní místnosti uživatele Lenka Nejedlá, která je uvedená v tabulce D.3 Název Adresa komunitní sítě Jméno uživatele Uživatelské jméno Heslo Adresa herní místnosti Adresa herní místnosti Lenky Nejedlé

Hodnota http://www.friendster.com Jan Novák [email protected] Abcd1234 http://apps.friendster.com/worldobg/ http://apps.friendster.com/worldobg/?roomID= WOBG17

Tabulka D.3: Friendster - důležité údaje pro spuštění aplikace

D.3

Obrazovka herní místnosti

Prototyp rozložení herní místnosti byl vytvořen a popsán již v části 5.5. Tento návrh byl dodržen a skutečný snímek obrazovky z herní místnosti je na obrázku D.1. U důležitých ovládacích prvků jsou umístěna čísla, která jsou vysvětlena v následujícím číslovaném seznamu. 1. Po kliknutí na ikonu správcem místnosti se zobrazí modální okno, ve kterém lze zvolit nastavení pro novou hru piškvorky. Toto okno je podrobně popsáno v části D.4. 2. Po kliknutí na ikonu správcem místnosti se zobrazí modální okno, ve kterém lze zvolit nastavení pro novou hru pexeso. Proces je analogický jako pro hru piškvorky. 3. Po kliknutí na křížek u konkrétního uživatele, bude tento odpojen z herní místnosti. Křížek je viditelný pouze pro správce místnosti - nevidí jej ale u svého uživatele v seznamu. 4. Textové pole pro zprávu do veřejného chatu. Pokud je toto pole aktivní, stisknutí klávesy ENTER zprávu odešle. 5. Tlačítko pro odeslání zprávy, které je povolené jen pokud obsah textového pole není prázdný. 6. Tlačítko pro smazání obsahu veřejného chatu, které je viditelné pouze pro správce místnosti. 7. Rozevírací seznam pro výběr jazyka aplikace. K dispozici je čeština a angličtina.

62


Obrázek D.1: Obrazovka herní místnosti s popisky

8. Popisek se jménem správce místnosti. Po najetí myší se zobrazí okno s URL adresou pro připojení do této herní místnosti, na komunitní síti přihlášeného uživatele. Dvojitý klik myší zkopíruje tuto adresu do schránky. Okno je zobrazeno na obrázku D.2. 9. Po kliknutí na ikonu se vyčistí obsah hrací plochy a aktuální hra bude ukončena jako remíza (hráčům nebudou změněny body). Ikona je viditelná pouze pro správce místnosti. 10. Počet bodů konkrétního uživatele ve všech implementovaných hrách. Po najetí myší na konkrétní počet bodů se zobrazí okno s podrobnou statistikou herních výsledků. Snímek je přiložen na obrázku D.3.

D.4. OBRAZOVKA NASTAVENÍ NOVÉ HRY - PIŠKVORKY

63

Obrázek D.2: Okno s URL adresou herní místnosti

Obrázek D.3: Okno s herní statistikou uživatele - piškvorky

D.4

Obrazovka nastavení nové hry - piškvorky

Na obrázku D.4 je přiložen snímek obrazovky v okamžiku volby nastavení pro novou hru piškvorky. Důležité ovládací prvky jsou opět označeny a popsány v následujícím seznamu. 1. Různé formulářové prvky pro volbu nastavení společenské hry piškvorky. Pro piškvorky lze zvolit velikost hracího pole (počet řádků a počet sloupců) i počet tahů potřebných k vítězství. 2. Seznam hráčů nové hry (uprostřed) a seznam uživatelů připojených v místnosti (vpravo). Mezi oběma seznamy se uživatelé přetahují metodou táhni a pusť (angl. drag and drop). Hráči hrají v pořadí v jakém jsou v seznamu uvedeni, pořadí se mění stejným způsobem. 3. Seznam ikon pro jednotlivé hráče. Každý hráč má přiřazenu ikonu, která je na stejném řádku jako on sám. Pořadí jednotlivých položek lze měnit metodou táhni a pusť v rámci seznamu všech ikon.

64


4. Tlačítko pro spočítání odměn a trestů pro zvolené hráče. Tlačítko je povoleno pouze pokud je vybrán minimální počet hráčů pro danou hru. Stav aktuálního okna po kliknutí na tlačítko je zobrazen na obrázku D.5 a popsán v části D.4.1. 5. Tlačítko pro založení nové hry se zvoleným nastavením. Je povolené pouze pokud jsou všechna formulářová pole správně vyplněna (viz položka číslo 6). 6. Pokud není libovolné formulářové pole validní (neobsahuje správnou hodnotu), je jeho popisek označen červenou barvou a po najetí myší se zobrazí vysvětlení, co je špatně.

Obrázek D.4: Modální okno pro nastavení nové hry - piškvorky

D.4.1

Obrazovka nastavení nové hry - piškvorky - odměny hráčů

Snímek na obrázku D.5 zobrazuje stav modálního okna pro nastavení nové hry piškvorky po kliknutí na tlačítko pro počítání odměn hráčů. Důležité ovládací prvky, které do okna přibyly, jsou opět označeny a vysvětleny v následujícím seznamu. 1. Tlačítko pro skrytí seznamu odměn a trestů pro jednotlivé hráče. Stav okna se po kliknutí vrátí zpět do původní podoby popsané v části D.4 a zobrazené na obrázku D.4.

D.5. OBRAZOVKA PROBÍHAJÍCÍ HRY - PIŠKVORKY

65

2. V seznamu jsou zobrazeny změny bodů jednotlivých hráčů nové hry v nejlepším a nejhorším případě. Skutečné odměny nebo tresty budou vypočítány až podle výsledku hry, ale budou v rozmezí této množiny. Toto opatření je kvůli složitosti počítání i zobrazování pro hry s větším počtem hráčů.

Obrázek D.5: Modální okno pro nastavení nové hry - piškvorky - odměny hráčů

D.5

Obrazovka probíhající hry - piškvorky

Na snímku obrazovky D.6 je zobrazena herní místnost po založení nové hry piškvorky. Pro přehlednost byla do obrázku opět vložena čísla, vysvětlená v následujícím seznamu. 1. Hrací pole právě probíhající hry. Uživatel, který je právě na tahu (viz číslo 4), může kliknutím na prázdné políčko toto obsadit. Všichni připojení uživatelé vidí hrací plochu ve stejném stavu, liší se pouze možností na políčka kliknout. 2. Seznam veškerých nastavení aktuální hry. 3. Seznam hráčů spolu s ikonami, se kterými hrají.

66


4. Hráč, který je právě na tahu, je v seznamu označen červeně. Hráč, který ve hře zvítězil, je odlišen žlutou barvou (po skončení hry).

Obrázek D.6: Obrazovka probíhající hry - piškvorky

Dodatek E

Obsah přiloženého CD Obsah CD, přiloženého k elektronické verzi je zobrazen v tabulce E.1. Název index.html text text/thesis thesis_sin thesis_sin/analysis thesis_sin/design thesis_sin/implementation thesis_src

Popis výchozí HTML stránka projektu s odkazy na další soubory adresář s textem bakalářské práce ve formátu PDF adresář se zdrojovými kódy k textu bakalářské práce adresář s automaticky generovanými výstupy z programu Entreprise Architect adresář s analytickou dokumentací k projektu adresář s návrhovou dokumentací k projektu adresář s implementační dokumentací k metodám, třídám a balíčkům všech vrstev projektu1 adresář se zdrojovými kódy ke všem vrstvám aplikace

Tabulka E.1: Obsah přiloženého CD

1 Kvůli možnosti jednotného vzhledu dokumentace pro rozdílné technologie jsem využil možnosti importu existujících zdrojových kódů do programu Entreprise Architect. Následně jsem vygeneroval interaktivní dokumentaci i s použitými komentáři.

67

Společná aplikace pro uživatele různých komunitních sítí. Pavel Krayzel

Recommend Documents