Webová aplikace pro organizaci bridžového turnaje. Miloslav Pojman

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

Bakalářská práce

Webová aplikace pro organizaci bridžového turnaje Miloslav Pojman

Vedoucí práce: Ing. Božena Mannová, Ph.D.

Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 25. května 2011

iv

v

Poděkování Na tomto místě bych rád poděkoval vedoucí mé práce Ing. Boženě Mannové, Ph.D. za vstřícný přístup, který mi pomohl dokončit tuto bakalářskou práci.

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 25. května 2011

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

viii

Abstract An event organization for a considerable number of persons requires to administer a significant amount of information. Web application developed within this thesis is an information system for international bridge tournament attended by several dozen of players. The application allows to book accommodation, maintain registration of tournament players and record list of invoices. Functionality is customized for a particular tournament but the application has an ambition to serve to organizers of other events too.

Abstrakt Organizace události, které se zúčastní větší množství osob, s sebou přináší nutnost spravovat nemalé množství informací. Webová aplikace vyvinutá v rámci této bakalářské práce je informačním systémem k organizaci mezinárodního bridžového turnaje pro několik desítek hráčů. Vytvořená aplikace umožňuje evidovat rezervace ubytovacích kapacit, přihlášky hráčů do soutěže a spravovat seznam požadovaných plateb. Funkcionalita je uzpůsobena konkrétnímu turnaji, aplikace má ale ambice sloužit i organizátorům dalších soutěží.

ix

x

Obsah 1 Úvod 1.1 Cíl práce . . 1.2 Alternativy 1.3 Potenciál . 1.4 Výhled . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1 1 1 2 2

2 Specifikace 2.1 Uživatelské rozhraní . . . . . . . 2.1.1 Uživatelé . . . . . . . . . 2.1.2 Jazyk . . . . . . . . . . . 2.1.3 Navigace . . . . . . . . . 2.2 Přehled požadavků . . . . . . . . 2.2.1 Nalezení volného pokoje . 2.2.2 Vytvoření rezervace . . . 2.2.3 Editace rezervace . . . . . 2.2.4 Smazání rezervace . . . . 2.2.5 Objednávka . . . . . . . . 2.2.6 Kontrola objednávek . . . 2.2.7 Změna stavu objednávky 2.2.8 Smazání objednávky . . . 2.2.9 Rozřazení do týmů . . . . 2.2.10 Export do Excelu . . . . . 2.3 Technické požadavky . . . . . . . 2.3.1 Znovupoužitelnost . . . . 2.3.2 Modularita . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 3 3 3 4 4 5 5 5 5 6 6 6 6 6 6 7 7 7

. . . . . . . .

9 9 9 9 10 10 10 10 10

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3 Analýza 3.1 Jádro aplikace . . . . . . . . . . . . 3.1.1 Události . . . . . . . . . . . . 3.1.2 Účastníci . . . . . . . . . . . 3.2 Ubytování . . . . . . . . . . . . . . . 3.2.1 Rezervace ubytování . . . . . 3.2.2 Cena pokojů . . . . . . . . . 3.2.3 Obsazenost pokojů . . . . . . 3.2.4 Vazba ubytování na přihlášky

xi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . do turnaje

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

xii

OBSAH

3.3

3.4

3.2.5 Vazba ubytování na správu plateb . . . . . Přihlášky do turnaje . . . . . . . . . . . . . . . . . 3.3.1 Přihlášky . . . . . . . . . . . . . . . . . . . 3.3.2 Startovné . . . . . . . . . . . . . . . . . . . 3.3.3 Abstrakce přihlášek . . . . . . . . . . . . . 3.3.4 Týmy . . . . . . . . . . . . . . . . . . . . . Objednávky a platby . . . . . . . . . . . . . . . . . 3.4.1 Objednávky . . . . . . . . . . . . . . . . . . 3.4.2 Stavy objednávky . . . . . . . . . . . . . . 3.4.3 Vazba objednávek na rezervace a přihlášky

4 Technologie 4.1 Software . . . . . . . . . . . . . . 4.1.1 Python a Django . . . . . 4.1.2 Použité knihovny a správa 4.1.3 Webový server a databáze 4.2 Hardware . . . . . . . . . . . . . 4.2.1 Hosting . . . . . . . . . . 4.3 Infrastruktura . . . . . . . . . . . 4.3.1 Vývojové prostředí . . . . 4.3.2 Správa verzí kódu . . . . 5 Návrh 5.1 Architektura . . . . . . . . . 5.1.1 Zpracování požadavků 5.2 Schéma databáze . . . . . . . 5.2.1 Objednávky a platby . 5.2.2 Ubytování . . . . . . . 5.2.3 Přihlášky do turnaje .

. . . . . .

. . . . . .

. . . . . . . . . . . . závislostí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

6 Implementace 6.1 Průběh implementace . . . . . . . . . . . 6.1.1 Harmonogram . . . . . . . . . . . 6.1.2 Fáze vývoje . . . . . . . . . . . . . 6.1.3 Konfrontace analýzy s realitou . . 6.1.4 Další analýza na základě předchozí 6.1.5 Využití prototypu . . . . . . . . . 6.2 Struktura aplikace . . . . . . . . . . . . . 6.2.1 Virtuální prostředí . . . . . . . . . 6.2.2 Kořen webu . . . . . . . . . . . . . 6.2.3 Zdrojové soubory . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

11 11 11 11 11 12 12 12 12 13

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

15 15 15 15 16 16 16 17 17 17

. . . . . .

19 19 19 19 19 21 23

. . . . . . . . . .

27 27 27 27 28 30 30 31 31 32 32

. . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . zkušenosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

7 Testování 35 7.1 Jednotkové testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.1.1 Nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.1.2 Pokrytí kódu testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

OBSAH

7.2

xiii

Systémové testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.2.1 Testy uživatelského rozhraní . . . . . . . . . . . . . . . . . . . . . . . . 35 7.2.2 Další testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8 Závěr 39 8.1 Implementované řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.2 Možnosti rozvoje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.3 Budoucí využití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 A Obsah přiloženého DVD

41

xiv

OBSAH

Seznam obrázků 2.1

Use case model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1

Stavy objednávky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.1 5.2 5.3 5.4

Sekvence zpracování formuláře . . . . . . Databázové schéma - Správa plateb . . . . Databázové schéma - Rezervace ubytování Databázové schéma - Startovné do turnaje

6.1 6.2 6.3

Vývoj počtu řádků kódu v čase . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Screenshot úvodní stránky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Screenshot rezervačního formuláře . . . . . . . . . . . . . . . . . . . . . . . . 29

xv

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

4

20 21 22 24

xvi

SEZNAM OBRÁZKŮ

Seznam tabulek 6.1 6.2

Adresářová struktura instalace . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Struktura zdrojových souborů . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.1

Test coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

A.1 Obsah přiloženého DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

xvii

xviii

SEZNAM TABULEK

Kapitola 1

Úvod 1.1

Cíl práce

Cílem této bakalářské práce je vytvořit webovou aplikaci pro podporu organizace bridžového turnaje. Konkrétně se jedná o čtvrtý ročník mezinárodního turnaje, který pořádá ve dnech 29. dubna až 1. května 2011 bridžový klub Chaos ve městě Slavonice1 . Na turnaj přijede něco mezi padesáti a stem účastníků, z nichž většina se zapojí do vlastní soutěže a menší část jede jen jako nehrající doprovod. Účastníci jsou ubytováni v pěti hotelích a rezervace ubytování v nich je nejdůležitější úloha aplikace. Kromě toho systém musí evidovat přihlášky do vlastního turnaje spolu s informací o startovném a rozřazení hráčů do týmů. Veškeré požadavky na ubytování spolu s přihláškami vyřizuje organizátor turnaje, který si předem zajistil rezervaci celých hotelů či jejich podstatné části. Účastníci tak platí ubytování a startovné právě organizátorovi. Proto je důležitou součástí aplikace flexibilní systém, který umožní rozdělovat jednotlivé rezervace do objednávek a u nich následně vést evidenci plateb. Celá aplikace funguje interně pro potřeby organizátora a přístup do ní mají pouze pověřené osoby – tzn. účastníci nezadávají do systému své požadavky na ubytování a start v turnaji přímo, nýbrž kontaktují organizátora elektronickou poštou či telefonem, který následně příslušný záznam do systému sám založí. Aplikace je vyvíjena na míru jedné konkrétní bridžové akci – má ale ambice být schopna po nevelkých úpravách sloužit i pro další bridžové a případně i nebridžové události. Psána je tak s ohledem na případný další rozvoj, neboť investice do vývoje by se nemohla vyplatit, pokud by aplikace byla nasazena jen v jednom konkrétním případě.

1.2

Alternativy

Rezervační systém – jakožto označení, která aplikaci asi vystihuje nejlépe – je nespočetněkrát řešená úloha. Existuje množství hotových rezervačních systémů, neboť prakticky každé 1

Více o turnaji na adrese

1

2

KAPITOLA 1. ÚVOD

ubytovací zařízení musí svoji kapacitu nějak spravovat. K dispozici je tak nepřeberně hotových komerčních i open source programů. Jistě také bylo vyvinuto a nasazeno nemálo jednoúčelových rezervačních systémů, napsaných pro konkrétní použití. Na druhou stranu se zdá, že pokud jde o rezervační systémy, stále nebylo nalezeno optimální řešení. Uvažujeme-li jiné rozšířené typy aplikací, jako jsou například elektronické obchody, redakční systémy, CRM, diskuzní fóra a další, zpravidla najdeme několik renomovaných a velmi rozšířených projektů. Ve srovnání s nimi ale v množství různých rezervačních systémů nelze najít jeden výjimečný, který by šlo označit za nadprůměrně kvalitní, rozšířený nebo snad standard.

1.3

Potenciál

Cílem této bakalářské práce není vyvinout obecný rezervační systém, ale specificky zaměřenou aplikaci na podporu organizace bridžového turnaje. Bridžová událost se ale mnoho neliší od akcí pořádaných v jiných sportech, a tak lze předpokládat, že podobnou aplikaci by mohly využít i jiné organizace při pořádání svých setkání. Požadavky na aplikaci lze zobecnit tak, že má pomáhat v organizaci setkání většího množství lidí na řádově jednotky dnů, pro které je třeba zajistit ubytování a v rámci akce se budou přihlašovat k účasti v nějakém organizovaném programu. Širší pohled je důležitý, pokud chceme uvažovat další využití aplikace. Turnaj ve Slavonicích je v bridžové obci výjimečný a je tak potřebný určitý nadhled při hledání dalších možností nasazení vyvinutého programu.

1.4

Výhled

Pohled do budoucnosti k dalším možným využitím aplikace je podstatný. V konkrétním případě turnaje ve Slavonicích, pro který je systém primárně vyvíjen, si organizátor po několik ročníků vystačil s jedním souborem v Excelu. I když budeme předpokládat různé výhody robustní webové aplikace oproti tabulkovému kalkulátoru, musí být zřejmé, že objem práce vynaložený na vývoj aplikace je větší než čas následně ušetřený při organizaci jednoho turnaje. Primárním cílem práce je vyvinout a nasadit systém pro slavonický bridžový turnaj, ale hned po té je třeba vyhlížet budoucí využití vyrobeného softwaru pro další bridžové a ideálně i nebridžové akce. Je prakticky nesplnitelný úkol vyvinout z nuly obecnou a multifunkční aplikaci, ovšem pokud vznikne solidní systém pro jeden konkrétní turnaj, dost možná najde využití i při pořádání dalších akcí. Jestliže návrh bude kvalitní, neměl by být problém aplikaci v budoucnu zobecnit. Energie je tak soustředěna do výroby co nejlepšího softwaru pro turnaj ve Slavonicích, ale s výhledem, že kvalitní produkt by neměl zůstat zapomenut.

Kapitola 2

Specifikace 2.1 2.1.1

Uživatelské rozhraní Uživatelé

Uživatelem aplikace je organizátor turnaje, případně několik málo jím pověřených osob. Pro práci s aplikací se uživatel musí autorizovat jménem a heslem, a aplikace je tak uzavřena cizím osobám. Vývoj pro velmi úzkou skupinu uživatelů znamená, že uživatelské rozhraní může, a mělo by být, uzpůsobeno této skupině. Organizátor turnaje má zavedené postupy, podle kterých si informace o plánované akci vede a udržuje. Uživatelské rozhraní by z těchto postupů mělo vycházet a umožnit tak vést evidenci k turnaji přesně tak, jak organizátor turnaje potřebuje. Malá skupina pravidelných uživatelů omezuje riziko, že uživatel aplikaci nepochopí, nebo se na webu ztratí. Navigace a struktura aplikace vychází z jeho konkrétních požadavků. Uživatel bude pracovat s aplikací opakovaně, takže ji bude dobře znát. Není úplně nutné, aby uživatelské rozhraní a fungování webu bylo novému uživateli zřejmé na první pohled. Na druhou stranu je důležité, aby aplikace při pravidelné práci nekladla překážky a umožňovala rychle dosáhnout chtěného cíle.

2.1.2

Jazyk

Uživatelské rozhraní je v angličtině. Aplikace je sice vyvíjena pro český bridžový klub, a tak její úzká skupina uživatelů bude nejspíše mluvit češtinou jako svým mateřským jazykem, nicméně pro žádného z nich není angličtina problém. Volba angličtiny je tak pragmatické rozhodnutí, které má ušetřit čas v případě, kdy by bylo nutno poskytnout přístup do systému uživateli, jenž nemluví českým jazykem. Například bridžový klub má v některých zemích kontaktní osobu, přes kterou jdou pak veškeré tamější přihlášky – a může se tak ukázat jako vhodné ji umožnit přístup do aplikace. Do budoucna by se mělo počítat s možností, že aplikaci bude třeba přeložit do dalších jazyků.

3

4

2.1.3

KAPITOLA 2. SPECIFIKACE

Navigace

První a nejdůležitější využití systému je rezervace ubytování. Z toho vyplývá i pohled, jakým se uživatel dívá na data, a chtěl by se po webu pohybovat. Primární navigace je po hotelích a následně po pokojích v nich. Pokud chce organizátor přidat do systému účastníka turnaje, nejdříve nalezne vhodný pokoj a následné tam vyplní účastníkovo jméno. V systému tak nejsou účastníci bez ubytování a pohled uživatele lze popsat jako „rezervace lůžka L na jméno O,“ nikoliv „osoba O si rezervuje lůžko L“. Může se to zdát jako nepatrný rozdíl. Projevuje se například tím, že v aplikaci není stránka se seznamem všech účastníků bez ohledu na ubytování či startovné v turnaji. Startovné do turnaje se vyplňuje spolu s rezervací ubytování. Uživatel tak nemusí na zvláštní stránku, kde by zapisoval hráče do turnaje, ale startovné vybere už ve chvíli, kdy vytváří rezervaci pokoje. Toto potvrzuje, že primární pohled je pohled na ubytování.

2.2

Přehled požadavků

Obrázek 2.1: Use case model

2.2. PŘEHLED POŽADAVKŮ

5

Use case model na obrázeku 2.2 shrnuje požadavky na aplikaci. Dále jsou jednotlivé případy použití podrobněji rozebrány.

2.2.1

Nalezení volného pokoje

Na úvodní stránce je možno si zvolit hotel, čímž se uživatel dostane na seznam jeho pokojů. V seznamu pokojů musí být na první pohled zřejmé, který pokoj je rezervován a který je stále dostupný. Po kliknutí na pokoj v seznamu se zobrazí detail se seznamem lůžek na pokoji a osobami, pro které jsou lůžka rezervována. Pokud jsou lůžka neobsazena, v seznamu se zobrazí prázdný řádek.

2.2.2

Vytvoření rezervace

Na stránce s detailem neobsazeného pokoje je odkaz pro vytvoření nové rezervace. Po kliknutí na tento odkaz se otevře formulář, jehož jednotlivé řádky odpovídají lůžkům v pokoji. Vyplněním jmen účastníků do příslušných řádku a odesláním formuláře je vytvořena rezervace pokoje. Datum příjezdu a odjezdu účastníků není pevně dáno a může být do formuláře zadáno. Většina účastníků bude přijíždět a odjíždět v den začátku respektive konce turnaje. V tomto nejčastějším případě není třeba do formuláře datum zadávat. Spolu s rezervací ubytování je ve formuláři možno vybrat startovné do turnaje. Pro nehrající účastníky se příslušné pole nechá prázdné.

2.2.3

Editace rezervace

V případě, že pokoj byl již rezervován, je na stránce s jeho detailem odkaz pro editaci rezervace. Kliknutí na odkaz otevře editační formulář obdobný tomu pro vytvoření rezervace. Jednotlivé řádky formuláře odpovídají lůžkům na pokoji. Vyplněním prázdného řádku a odesláním formuláře lze na pokoj přidat rezervaci pro další osobu. Editací stávajících řádků lze měnit existující rezervaci. Formulář taktéž obsahuje možnost zrušit rezervaci jedné nebo více konkrétních osob z pokoje. Editovat lze pouze rezervace, které zatím nebyly potvrzeny a přiřazeny objednávce. Viz dále.

2.2.4

Smazání rezervace

Vedle odkazu pro editaci rezervace je odkaz pro smazání rezervace. Odkaz vede na potvrzovací stránku, kde po potvrzení je rezervace zrušena. Smazat lze pouze rezervace, které zatím nebyly potvrzeny a přiřazeny objednávce. Víz dále.

6

2.2.5


Objednávka

Na detailu rezervovaného pokoje je možno kliknout na odkaz, který vede na stránku pro potvrzení rezervace. Potvrzení spočívá v přiřazení rezervace na jednu nebo více objednávek. Po přiřazení k objednávce není možno rezervaci dále měnit. Celá rezervace pokoje může být přiřazena na jednu objednávku nebo rozpočítána po osobách. Obdobně jako ubytování je na objednávky rozepsáno i startovné do turnaje. V případě, že v systému ještě není odpovídající objednávka, na stránce je odkaz pro vytvoření objednávky nové. Po vytvoření nové objednávky je uživatel vrácen na stránku s potvrzením rezervace. Položky mohou být přiřazeny pouze na nové objednávky – totiž ty, u kterých ještě nebyl změněn stav. Viz níže.

2.2.6

Kontrola objednávek

Uživatel musí mít přehled o provedených objednávkách a jejich stavu. Proto na úvodní stránce bude seznam objednávek spolu s jejich stavem. Objednávky budou řazeny dle stavu. Po kliknutí na objednávku se uživatel dostane na detail objednávky, kde jsou rozepsány položky na spolu s cenou.

2.2.7

Změna stavu objednávky

Na detailu objednávky mohou být tlačítka pro změnu stavu objednávky. Nově vytvořená objednávka je ve stavu NEW. Objednávku ve stavu NEW lze stiskem tlačítka přesunout do stavu SENT. Následně ve chvíli, kdy je objednávka potvrzena, její stav je změněn na CONFIRMED. Kromě toho objednávka ve stavech SENT a CONFIRMED může být stornována, čímž je stav změněn na CANCELED. V případě storna objednávky nejsou příslušné rezervace nadále považovány za potvrzené a je možno je opět měnit.

2.2.8

Smazání objednávky

Na detailu objednávky je odkaz pro smazání. Smazat jdou pouze objednávky ve stavu NEW. Po smazání objednávky jsou příslušné rezervace zachovány, ale nejsou považovány za potvrzené a lze je opět měnit.

2.2.9

Rozřazení do týmů

V aplikaci je seznam týmů, který lze rozšiřovat a zkracovat o položky. Do týmů lze přiřadit účastníky, kteří si rezervovali startovné v turnaji.

2.2.10

Export do Excelu

Z aplikace je možno vyexportovat dokument pro MS Excel. Je třeba exportovat informace o ubytovaných na jednotlivých pokojích a dále pak seznam objednávek.

2.3. TECHNICKÉ POŽADAVKY

2.3 2.3.1

7

Technické požadavky Znovupoužitelnost

Aplikace je primárně vyvíjena pro jednu konkrétní bridžovou akci konanou ve Slavonicích v roce 2011, a tak i její funkcionalita je této akci uzpůsobena. Přesto je žádáno, aby aplikace mohla fungovat i pro další obdobné akce. Proto by měl být vyvíjena s ohledem na další znovupoužitelnost. Bohužel požadavky na znovupoužitelnost jdou z velké části proti požadavkům na uživatelské rozhraní. Uživatel aplikace oprávněně žádá rozhraní, které bude fungovat co nejlépe pro danou událost. Předpokládá přitom specifika konkrétní události, která ale často nelze zobecnit i pro případné další budoucí použití. Jako konkrétní příklad, kdy požadavky na znovupoužitelnost a uživatelské rozhraní si odporují, lze uvést pohled na aplikaci přes ubytovací kapacity. V případě turnaje ve Slavonicích se ukazuje jako nejvhodnější zadávat údaje po jednotlivých hotelích a pokojích. Informace o novém účastníkovi dané události vznikne prostřednictvím rezervace lůžka. Startovné do turnaje je vybráno spolu s rezervací pokoje. V obecném případě ale nelze předpokládat, že každý účastník si bude rezervovat ubytování prostřednictvím organizátora turnaje, takže model použitý pro slavonický turnaj lze pro další akce těžko použít. Můžeme se snažit se předvídat všechny možnosti budoucího použití, ale je prakticky nemožné, aby aplikace od první verze fungovala obecně pro všechny možné budoucí bridžové turnaje. Není vhodné upravovat uživatelské rozhraní první verze určené pro slavonický turnaj dle idei univerzální aplikace, a tak zhoršovat použitelnost při organizaci právě turnaje ve Slavonicích. Je třeba najít kompromis, který umožní další rozšiřování aplikace, přitom ale neomezí současného uživatele. Datový model by měl být navržen s ohledem na případné budoucí použití. Naopak prezentační vrstva může být velice konkrétní a uzpůsobena jednomu turnaji, s tím že v budoucnosti si dost možná vyžádá přepsání.

2.3.2

Modularita

Aplikaci lze logicky rozdělit na tři moduly. První modul obstarává rezervace ubytování v hotelích, zatímco druhý eviduje startovné do turnaje. Třetí modul pak na základě informací z předchozích spravuje objednávky a platby za ně. V konkrétním případě turnaje ve Slavonicích je rezervace ubytování prostřednictvím organizátora podmínkou pro vstup do turnaje. Toto omezení ale není u podobných akcí obvyklé, a v obecném případě by systém měl umožnit přihlášky do turnaje bez rezervace ubytování. A naopak – existují rekreačně zaměřené bridžové akce, kde vlastní hraní má neformální charakter, a není tak nutné se explicitně přihlašovat do žádného turnaje. Systém by tedy měl umožnit vést pouze rezervace ubytování bez informace o turnaji. Správa objednávek a plateb by neměla být omezena na platby za ubytování a startovné do turnaje. S případným dalším využitím aplikace lze očekávat nutnost evidovat objednávky dalších služeb, které by mělo být možno do aplikace doimplementovat.

8


Funkčnost požadovaná od jednotlivých modulů je vzájemně nezávislá, a tak by ani implementací neměly být svázány k sobě. Je žádoucí, aby jednotlivé moduly spolupracovaly a doplňovaly se ve prospěch aplikace jako celku, ale na úrovni kódu by mezi nimi měla být definovaná jasná hranice a jednotlivé moduly by tuto hranici měly co možná nejvíce dodržovat. Co moduly aplikace spojuje je bridžová událost, ke které vedou záznamy. O samotné akci není nutno vést mnoho informací, ale jednotlivé části aplikace potřebují přiřadit své záznamy ke konkrétní události. Informace o plánované události je tak pro aplikaci klíčová. Seznam událostí nepatří do žádného z výše jmenovaných modulů, protože každý z nich na něj může vázat svá data. Události je tedy vhodné vést v dalším, zvláštním modulu.

Kapitola 3

Analýza 3.1 3.1.1

Jádro aplikace Události

Informace o plánovaných událostech je klíčová pro ostatní části aplikace. Jak rezervaci ubytování, tak startovné do turnaje je nutno svázat s konkrétní bridžovou událostí. Správa plánovaných událostí ale nemůže být součástí ani modulu pro ubytování, ani modulu pro startovné v turnaji. V prvním případě by nebylo možné zúčastnit se turnaje bez rezervace ubytování, v druhém by systém neumožňoval rezervovat ubytování bez informace o turnaji. Proto pro události existuje samostatný modul, který lze chápat jako jádro systému. Ve středu aplikace pro organizaci bridžového turnaje je informace o plánované akci. Z důvodu znovupoužitelnosti může být turnajů v systému více. Ostatní moduly tak mohou toto jádro využívat a své záznamy svázat s konkrétní plánovanou akcí.

3.1.2

Účastníci

Účastník turnaje je společným jmenovatelem rezervace ubytování v hotelu a přihlášky do turnaje. Spojuje tak jinak nesouvisející data ve dvou modulech osobou jednoho člověka. Stejně jako v případě informací o plánovaných událostech není vhodné vést evidenci účastníků v žádném z jednotlivých modulů, protože aplikace by se pak na daném modulu stala závislá. Účastníky bude vhodné spravovat spolu s událostmi, kterých se účastní, v jádru aplikace. Účastníci jsou klíčovou entitou aplikace, kterou si ale uživatel systému nemusí vůbec uvědomit. Uživatel totiž jde založit rezervaci – do rezervace vepíše jméno osoby a z jeho pohledu tak vznikla rezervace lůžka. To, že aplikace na pozadí k dané události přidala dalšího účastníka, se uživatel vůbec nedozví.

9

10

3.2 3.2.1

KAPITOLA 3. ANALÝZA

Ubytování Rezervace ubytování

Rezervace ubytování je nejdůležitější součástí systému. Základem je databáze hotelů spolu se seznamy dostupných pokojů. U každého pokoje je třeba evidovat jeho kapacitu s rozlišením standardní kapacity a případných přistýlek. Veškerá kapacita hotelu je předem rezervována organizátorem. Přesto se ale stává, že majitel hotelu jeden z pokojů odřekne – v podobných případech je pak nutno příslušný pokoj skrýt ze seznamu.

3.2.2

Cena pokojů

Na základě rezervací je možno dále v systém vést správu plateb za ubytování, pro kterou je nutno znát cenu jednotlivých pokojů. Cena může být určena za celý pokoj či za každou osobu. V obou případech se cena uvádí za noc. Možnost volby mezi cenou za pokoj a cenou za osobu pokrývá většinu případů, které při výpočtu ceny nastanou. Přesto zůstávají řádově jednotky případů, kde je nutná další logika. Příkladem může být poplatek za jednu osobu na dvoulůžkovém pokoji, parkovné či poplatek za psa. Jelikož se jedná o výjimečné případy, zpravidla jedinečné, ošetřovat je programově by bylo zbytečně složité a vhodné řešení bude ruční editace částky k zaplacení. Uváděná cena je tak pouze orientační, závazná a platná částka je určena až při objednávce – což řeší modul objednávek a plateb.

3.2.3

Obsazenost pokojů

V seznamu pokojů musí být na první pohled zřejmé, který pokoj je již rezervován a který zůstal ještě dostupný. Po kliknutí na jméno pokoje se zobrazí detail pokoje. Detail pokoje obsahuje tabulku, kde jeden řádek odpovídá jednomu lůžku v pokoji. Pokud je lůžko rezervováno, v tabulce je příslušný řádek vyplněn, v opačném případě je řádek prázdný. Na první pohled je tak zřejmé, kdo má v daném pokoji rezervaci i kolik volných lůžek ještě zbývá. Po dalším kliknutí se otevře editační formulář, kde je možno osoby ve vybraném pokoji editovat.

3.2.4

Vazba ubytování na přihlášky do turnaje

Při editaci rezervace daného pokoje je možné spolu s rezervací lůžka jednotlivým účastníkům rovnou přiřadit i startovné do turnaje. Z uživatelského pohledu je podobná možnost velmi důležitá, neboť efektivně zkracuje čas potřebný k vložení jednoho účastníka do systému na polovinu. Zároveň před uživatelem skrývá dělení aplikace na moduly. Pokud uživatel zadává startovné do turnaje na jednom řádku spolu s ubytováním, vůbec si neuvědomuje, že zapisuje současně do dvou na sobě téměř nezávislých modulů. To může být i problém, protože pokud řádek s ubytováním smaže, není zřejmé, zda nechat v systému účastníka zapsaného v turnaji ale bez ubytování, nebo na pozadí smazat i zápis do turnaje.

3.3. PŘIHLÁŠKY DO TURNAJE

11

V aplikaci je zvolena druhá možnost – spolu s ubytováním jsou smazány veškeré další zápisy o daném účastníkovi. Podobné mazání se může zdát jako příliš destruktivní přístup, ale z pohledu uživatele, který zadává do systému účastníky po hotelech a pokojích, se jeví rezervace lůžka jako hlavní entita. Existence účastníků v logice aplikace je mu úplně skryta a nedává smysl tak v systému nechávat osiřelé osoby.

3.2.5

Vazba ubytování na správu plateb

Modul pro rezervace ubytování řeší pouze rezervaci pokoje, nikoliv už závaznou objednávku či platbu za ni. Tuto zodpovědnost přebírá modul pro správu plateb. Přitom musí být zajištěno, aby po závazné objednávce již nešlo zadanou rezervaci měnit.

3.3 3.3.1

Přihlášky do turnaje Přihlášky

Přihlášky do turnaje jsou funkcionalita specifická bridžový turnaj a odlišují tak aplikaci od obecného rezervačního systému. V rámci jednoho víkendu ve Slavonicích se hrají dva nezávislé turnaje. Do hlavního turnaje je třeba podat přihlášku předem a účast v něm je tak evidována v aplikaci. Přihlášky do vedlejšího turnaje jsou přijímány na místě a turnaj v aplikaci veden není. Tento příklad ale i tak ukazuje, že aplikace by měla počítat s obecnou možností – totiž, že v rámci jedné události může být třeba vést evidenci pro několik turnajů zároveň.

3.3.2

Startovné

Jednotliví hráči se mohou, ale nemusí do turnaje přihlásit. Možností přihlášky do jednoho turnaje může být více a liší se především výší startovného. Podmínka pro nárok na konkrétní startovné může být věk hráče či datum přihlášky. Aplikace programově nekontroluje, zda konkrétní hráč má na dané startovné nárok. Věk hráče nelze z aplikace věrohodně ověřit. Datum přihlášky je sice možno teoreticky kontrolovat a následně dle něj určovat cenu, vedlo by to ale ke přílišné komplexitě a zbytečným omezením pro organizátora – uvažujme například situaci, kdy přihláška dojde den před termínem a organizátor se nedostane ihned k jejímu zadání do systému.

3.3.3

Abstrakce přihlášek

Pokud uvažujeme způsob, jakým přihlášky do turnaje fungují, docházíme k tomu, že nejsou specifické pro bridžový turnaj. Obdobně jako do bridžového soutěže se lze přihlásit i na odpolední turnaj v golfu či večerní bingo. Při další abstrakci docházíme k tomu, že vůbec nemusí jít o přihlášku do turnaje nebo soutěže. Funkcionalitu, která musí být implementována pro přihlášky do turnaje, lze stejně dobře využít pro objednávku degustace vína v místním sklípku či cokoliv jiného. Jelikož od aplikace není požadováno, aby bylo možno doobjednávat i další služby, předpokládáme zatím, že modul pro přihlášky do turnaje bude sloužit skutečně jen pro evidenci

12


hráčů v soutěži. Pokud by v budoucnu vznikl požadavek na rozšíření aplikace právě o doplňkové služby, jistě by bylo vhodné zamyslet se, zda podobná abstrakce od přihlášky do turnaje k obecné objednávce služeb není správná cesta.

3.3.4

Týmy

Ke každému turnaji, kromě seznamu přihlášených hráčů, je třeba vést i seznam přihlášených týmu. Přitom aplikace musí umožňovat dosud nezařazené hráče rozřadit do jednotlivých týmů. Správa týmů je nepovinná a aplikace musí umožňovat přihlášení hráče do turnaje bez toho, aby v systému nějaké týmy byly zadány.

3.4 3.4.1

Objednávky a platby Objednávky

Rezervace ubytování a přihlášky do turnaje vytvářejí pohledávky organizátora turnaje vůči účastníkům. Organizátor tak musí mít nástroj, jak tyto pohledávky spravovat. Základem modulu pro správu plateb je seznam objednávek, kde každá objednávka může mít jednu nebo více položek. Jiný pohled na objednávku je chápat ji jako fakturu. Objednávka nese jméno, na které je vydána, číslo, které lze využít jako variabilní symbol při platbě na účet a případné poznámky. Více informací není třeba, aplikace nemá ambice konkurovat účetním programům.

3.4.2

Stavy objednávky

Objednávka může nabývat několika stavů. Po vytvoření je objednávka ve stavu NEW. V tomto stavu je možno na objednávku přidávat nové položky a editovat existující, což efektivně mění celkovou částku na faktuře. Ve stavu NEW je možno objednávku kdykoliv smazat. Ve chvíli, kdy je objednávka kompletní a nepředpokládají se její další změny, je označena jako SENT a příslušnému účastníkovi je odeslán požadavek k zaplacení. Spolu s přepnutím do stavu SENT, jsou zakázány další změny částky na této objednávce a objednávka již nemůže být smazána. V okamžik proplacení objednávky organizátor označí objednávku jako CONFIRMED. Tento stav se liší od předchozího pouze sémanticky, z pohledu aplikace se nic nemění. Objednávku ve stavu SENT a CONFIRMED je možno stornovat, čímž se dostává do stavu CANCELED. Stornování objednávky je akce odlišná od jejího smazání. Smazaná objednávka je fyzicky odstraněna z databáze, zatímco stornovaná objednávka zůstává v seznamu a pouze se mění zobrazovaný stav. Stav CANCELED je stav konečný. Druhým konečným stavem je CLOSED, do kterého lze přesunout objednávku ze stavu CONFIRMED. Objednávky jsou uzavřeny přesunutím do stavu CLOSED po uskutečnění plnění – proběhnutí turnaje. Uzavřenou objednávku již nelze stornovat. Možné stavy objednávky a přechody mezi nimi znázorňuje obrázek 3.4.2.

3.4. OBJEDNÁVKY A PLATBY

13

Obrázek 3.1: Stavy objednávky

3.4.3

Vazba objednávek na rezervace a přihlášky

Objednávky jsou nezávislé na rezervaci ubytování či přihlášce do turnaje. Lze založit objednávku a její položky bez toho, aby v systému byl veden hotel nebo turnaj. Přes to u položek na objednávce, které vznikly jako platba za ubytování nebo startovné, je nutné tuto vazbu evidovat. Modul pro ubytování sám neřeší potvrzení rezervace. Rezervace je považována za potvrzenou, když je přiřazena k objednávce. Rezervaci ubytování může být přiřazena pouze k objednávce ve stavu NEW. A ve chvíli, kdy je faktura odeslána a objednávka přesunuta do stavu SENT, je příslušná rezervace uzamknuta pro další editaci. Stejný princip platí pro přihlášky do turnaje. Přiřazování rezervací k objednávkám musí být flexibilní. Musí být možné na jednu objednávku napsat rezervace několika pokojů a naopak rezervaci jednoho pokoje rozepsat na několik objednávek. Podstatné je, že modul správy plateb určuje platnou cenu objednávky. Až do vytvoření příslušné položky na objednávce se jedná pouze o rezervaci a žádná cena nebyla určena. Částka, kterou lze spočítat z ceny pokoje na noc, či inzerované startovné jsou pouze orientační ceny a nevytváří závaznou objednávku. Při vytváření objednávky, totiž zápisu položky na fakturu, je možno cenu ručně upravit a zadaná částka se již nemění – a to i pokud bude například v databázi upravena cena za pokoj.

14


Kapitola 4

Technologie 4.1 4.1.1

Software Python a Django

Aplikace je napsána v jazyce Python na webovém frameworku Django [6]. Použití frameworku pro podobnou aplikaci je téměř nutnost. V rámci implementace je třeba vyřešit i základní věci jako přihlašování do systému, validace formulářů, práce s databází a další. Framework poskytuje hotové řešení těchto nízkoúrovňových problémů a umožňuje tak soustředit se na vlastní přidanou funkcionalitu. Zřejmá výhoda využití frameworku je tak časová úspora spolu s kvalitou implementace základních kamenů. Volba jazyku Python a frameworku Django je dána především mojí vlastní zkušeností. Jednotlivé programovací jazyky či frameworky s sebou přinášejí různé výhody i nevýhody a objektivní srovnání je těžko možné. Praktický rozdíl bude nicméně zanedbatelný oproti tomu, že vývojář pracuje s infrastrukturou, se kterou má zkušenosti a je dobře obeznámen. Django je označován za „Rapid development framework.“ V praxi to znamená, že je možno velmi rychle vytvořit funkční prototyp, který se dále upravuje. Důležité ale je, že v průběhu celého vývoje je k dispozici fungující aplikace, do které se jen postupně zapracovávají jednotlivé požadavky. V tomto konkrétním případě je to velmi výhodné, neboť termín turnaje ve Slavonicích je neměnný a dodání aplikace se zpožděním by znamenalo, že nebude využita vůbec. Ve chvíli, kdy máme funkční aplikaci brzy k dispozici, je podobné riziko mnohem menší a zůstává jen otázka, kolik z požadované funkcionality stihneme do aplikace implementovat. Silnou stránkou frameworku Django je automaticky generovaná administrace, která je pro příležitostné úpravy obsahu dostačující. Díky tomu se vývoj může zaměřit na klíčovou funkcionalitu a uživatelské rozhraní pro nejčastější užití systému. Například ceny pokojů jsou jednorázově importovány a případné další editace jsou výjimečné, takže generovaná administrace pro ně dostačuje a není třeba ztrácet čas vlastní implementací.

4.1.2

Použité knihovny a správa závislostí

Krom Django frameworku aplikace využívá další knihovny. Knihovna xlwt [10] umožňuje exportovat soubory ve formátu XLS pro MS Excel a to i na unixovém stroji. Knihovna

15

16

KAPITOLA 4. TECHNOLOGIE

flup [14] pak zajišťuje komunikaci přes FastCGI rozhraní s webovým serverem. Některé knihovny jsou určeny pro použití v kombinaci s Django frameworkem. Knihovna django-html [15] je použita pro lepší vykreslování formulářových prvků. Pomocí mnou vytvořené knihovny django-urldecorators [13] je pak omezen přístup do systému nepřihlášeným uživatelům. Jednotlivé knihovny, na kterých aplikace závisí, nejsou zkopírovány do kódu aplikace, nýbrž jsou vždy instalovány v aktuální verzi z původního zdroje, což zjednodušuje sledování aktualizací. Znamená to ale, že je třeba proces instalace závislostí zautomatizovat, neboť opakovaná ruční instalace většího množství závislostí by jistě vedla k chybě. Knihovny, na kterých aplikace závisí, není vhodné instalovat přímo do systému, ale pouze pro danou aplikaci. Za prvé to nemusí být vůbec možné, v případě že instalujeme aplikaci na stroji, kde nemáme administrátorská oprávnění (uživatele root), a za druhé, i kdyby to možné bylo, vedlo by to k rychlému zaplevelení systému. Vytvořit nezávislé prostředí (konkrétně vlastní interpret Pythonu) pro danou aplikaci umožňuje knihovna virtualenv [5]. Závislosti aplikace jsou pak instalovány pomocí nástroje pip [12], který mimo jiné umožňuje načítat seznam knihoven k instalaci ze souboru – ve kterém tak může být jednoduše uveden seznam závislostí.

4.1.3

Webový server a databáze

Rozhraní WSGI [9] je standard pro webové aplikace napsané v Pythonu, a jelikož vyvíjená aplikace toto rozhraní implementuje, může fungovat s většinou webových serverů. Zátěž aplikace bude minimální, takže výběr webového serveru není nijak podstatný. Poskytovatel hostingu používá servery Apache 2, na kterém tak aplikace běží, ale může fungovat i na dalších serverech. Použitý Django framework nabízí vrstvu abstrakce od databáze, kterou aplikace využívá. Teoreticky tak může běžet oproti různým databázovým strojům. V produkci je nyní využita MySQL 5 databáze. Během vývoje je možno pro jednoduchost pracovat s SQLite databází. Napojení na jinou databázi by neměl být problém, v praxi to ale není vyzkoušeno. Aplikace běží při velmi malé zátěži, takže zatím není důvod věnovat výběru databáze větší pozornost.

4.2 4.2.1

Hardware Hosting

Aplikace není náročná na výkon, a tak výběr hardwaru není příliš podstatný. Aplikace běží na sdíleném hostingu Dreamhost [7]. Výběr hostingu určila především cena, neboť jmenovaný provozovatel umožňuje v rámci jednoho účtu provozovat větší množství různých webů. Jelikož tam již provozuji jiné projekty, byla zde možnost rozchodit aplikaci pro organizaci turnaji ve Slavonicích bez dalších nákladů.

4.3. INFRASTRUKTURA

4.3 4.3.1

17

Infrastruktura Vývojové prostředí

Zvolené technologie nejsou vázány na konkrétní vývojové prostředí. Existují různé možnosti a mnoho vývojářů v Pythonu preferuje například pracovat se zdrojovými kódy v editoru vim. Zvolil jsem IDE Eclipse s pluginem PyDev [1] pro Pythonu a pluginem Aptana Studio [2] pro HTML, CSS a JavaScript. Jedná se z mé strany o vyzkoušené řešení, které splňuje většinu požadavků na vývojové prostředí a nebyl tak důvod hledat jiné možnosti.

4.3.2

Správa verzí kódu

Správu verzí zdrojového kódu považuji za samozřejmost, a to i v případě projektu, který je vyvíjen jen jedním vývojářem. Zdrojové kódy aplikace jsou verzovány v GITu. Distribuovaný systém správy verzí jako GIT je výhodný (mimo jiné) pro podobný projekt, na kterém pracuje jeden vývojář. Udržovat centrální repositář v takovém případě není přirozené. Využití systému jako je GIT přímo vybízí k tomu lokálně commitovat každou drobnou změnu a udržovat tak pečlivou historii projektu. Synchronizace se vzdáleným serverem pak funguje pouze jako záloha.

18

KAPITOLA 4. TECHNOLOGIE

Kapitola 5

Návrh 5.1 5.1.1

Architektura Zpracování požadavků

Základní architektura je dána frameworkem Django, ve kterém je aplikace napsána, nebo obecněji protokolem HTTP, jelikož se jedná o webovou aplikaci. Prohlížeč uživatele odesílá HTTP požadavek, na který aplikace zpravidla odpovídá stránkou v jazyce HTML. Django framework zpracovává HTTP požadavky a na základě definovaných pravidel je předává tzv. view. V Django terminologii se nazývá view, co jiné webové frameworky zpravidla nazývají controller. Jednotlivá view nejsou nic jiného než funkce v jazyce Python, která zpracuje požadavek a vrátí odpověď. Na obrázku 5.1.1 je zachycen typický průběh interakce na stránce s formulářem. Webový prohlížeč uživatele odesílá GET požadavek na zobrazení formuláře. Příslušné view v aplikaci přes Django ORM vybírá objekty z databáze a pomocí šablonovacího systému vykresluje HTML stránku, kterou následné vrací uživateli. Poté, co uživatel formulář vyplní, je odeslán metodou POST na server. Požadavek zpracovává stejné view, který zpracovalo GET požadavek. Opět přes ORM vyhledá v databází příslušné objekty. O kontrolu dat od uživatele se pak stará formulářová vrstva. Ta data validuje, a v případě, že jsou platná, na jejich základě upraví objekty v databázi.

5.2 5.2.1

Schéma databáze Objednávky a platby

Schéma databáze pro správu plateb je zachyceno na obrázku 5.2.1. Klíčové jsou tabulky invoices_invoice a invoices_item. První reprezentuje objednávku, druhá pak položku na objednávce. U objednávky i položky si mimo jiné ukládáme, kdy byla vytvořena, naposledy upravena a kterým uživatelem. Možné stavy objednávky jsou pak uloženy v tabulce invoices_state a umožní přechody mezi stavy v tabulce invoices_state_transition. Proces vytvoření a potvrzení objednávky tak není zadrátován v kódu aplikace, ale lze ho upravovat v databázi.

19

20

KAPITOLA 5. NÁVRH

Obrázek 5.1: Sekvence zpracování formuláře

5.2. SCHÉMA DATABÁZE

21

Obrázek 5.2: Databázové schéma - Správa plateb

5.2.2

Ubytování

Obrázek 5.2.2 zachycuje databázové schéma modulu pro rezervaci ubytování. Kromě samotného modulu jsou ve schématu zachyceny také tabulky events_event a events_person z modulu událostí, na které se tabulky odkazují jakožto na jádro aplikace. Schéma také obsahuje tabulku invoices_item z modulu pro správu plateb. Návrh tabulek accomodation_hotel a accomodation_room je přímočarý. Obě tabulky obsahují základní informace o hotelu, respektive pokoji v něm. V případě pokoje jsou důležité sloupce, které udávají kapacitu pokoje a jeho cenu. Z tabulky hotelů směřuje cizí klíč do tabulky událostí, tzn. evidujeme pouze hotely pro konkrétní události a každý hotel je přiřazen právě k jedné události. Nabízí se implementovat obecné řešení, kdy mezi hotely a událostmi bude vazba m:n a jeden záznam v tabulce hotelů

22

KAPITOLA 5. NÁVRH

Obrázek 5.3: Databázové schéma - Rezervace ubytování


23

tak půjde využít pro více událostí (např. v dalších ročnících bude ubytování pravděpodobně zajištěno ve stejných hotelích). Tato obecnost by ale nepřinesla žádnou výhodu, naopak by bylo třeba řešit různé ceny nebo dostupnost pokojů mezi ročníky, a tak se zdá nejpraktičtější, při případném dalším ročníku, příslušné řádky jednoduše zkopírovat. Tabulky accommodation_reservation a accommodation_person_reservation udržují informace o již zadaných rezervacích. Tabulka accommodation_person_reservation obsahuje seznam rezervací jednotlivých osob a to prostřednictvím cizího klíče do tabulky účastníků. Cizí klíč tabulky z accommodation_person_reservation se odkazuje do tabulky accommodation_reservation, ve které jsou uloženy rezervace celých pokojů. Je na zvážení, zda je třeba vůbec tabulku rezervací celých pokojů vytvářet. Tabulka rezervací účastníků by mohla mít cizí klíč přímo do tabulky pokojů a informace, který pokoj je rezervován, by zůstala zachována. Přítomnost tabulky pro rezervaci celých pokojů v aplikaci ale zajišťuje, že každá rezervace pokoje musí být explicitně vytvořena a není závislá na seznamu ubytovaných. Význam rozdělení na rezervaci pokoje a rezervaci jednotlivých účastníků vyplyne, když uvažujeme uživatelská oprávnění, kdy uživatel může editovat pouze vlastní rezervace. V tu chvíli je třeba jasně identifikovat, kdo pokoj rezervoval. Tabulky accommodation_reservation a accommodation_person_reservation obsahují cizí klíč do tabulky invoices_item s položkami objednávky. Tento cizí klíč může být a ve výchozím stavu je nastaven na NULL. Nastavení hodnoty tohoto cizího klíče na nenulovou hodnotu značí, že příslušná rezervace byla potvrzena a závazně objednána.

5.2.3

Přihlášky do turnaje

Databázové schéma modulu pro přihlášky do turnaje je na obrázku 5.2.3 a stejně jako v případě modulu pro ubytování jsou v něm zobrazeny i tabulky events_event a events_person z modulu událostí a tabulka invoices_item z modulu pro správu plateb. Struktura tabulek tournaments_tournament a tournaments_entry není složitá. První obsahuje uložen seznam turnajů, spolu s informací, v rámci jaké události se turnaj koná. Ve druhé pak lze dohledat dostupné startovné do konkrétního turnaje. Definice databázové tabulky tournaments_team, do které jsou vkládány informace o týmech v jednotlivých turnajích, je také přímočará. Za diskuzi stojí tabulka tournaments_person_entry. Účel této tabulky je zřejmý – je třeba evidovat hráče, kteří se účastní jednotlivých turnajů. Informace o osobě, která se turnaje zúčastní, je realizována cizím klíčem do tabulky účastníků z modulu událostí. Dále je třeba uložit informaci, o který turnaj se jedná. Cizí klíč do tabulky turnajů nestačí, protože aplikace musí také evidovat typ startovného. Pokud bychom do tabulky přidali kromě cizího klíče do tabulky turnajů i cizí klíč do tabulky dostupných startovných, může se snadno stát, že jejich hodnoty se rozejdou a v tabulce bude uvedena kombinace startovného a turnaje, která není přípustná – databáze se dostane do nekonzistentního stavu. Proto v tabulce tournaments_person_entry je cizí klíč pouze do tabulky tournaments_entry a nikoliv už do tabulky tournaments_tournament. Při tomto schématu nelze bohužel na úrovni databáze vynutit, aby se jedna osoba mohla zapsat do jednoho turnaje pouze jednou. Na druhou stranu to lze chápat i jako výhodu, pokud bychom se rozhodli například zneužít modul pro bridžové turnaje k prodeji losů do tomboly.

24

KAPITOLA 5. NÁVRH

Obrázek 5.4: Databázové schéma - Startovné do turnaje


25

Databázové schéma pro přihlášky do turnaje obsahuje nepříjemnou smyčku. Ve chvíli, kdy přidáme tabulku tournaments_team_person_entry, která má evidovat hráče v jednotlivých týmech, se uzavře pomyslný kruh. V databázi totiž máme uloženo do jakého turnaje se hráč přihlásil a stejně tak tam máme uloženo, jaký turnaj hraje který tým. Když přiřazujeme hráče do týmu a nedáme si pozor, můžeme databázi snadno dostat do nekonzistentního stavu. Teoreticky správné řešení by nejspíše bylo odebrat z tabulky týmů cizí klíč do tabulky turnajů – což by roztrhlo smyčku a přitom by stále bylo možno dohledat, kterého turnaje se tým zúčastní, a to přes jednotlivé hráče. Prakticky je to ale nepoužitelné řešení, protože aplikace potřebuje jednoznačně vědět, které týmy se zúčastní jakého turnaje. Tabulka tournaments_person_entry má cizí klíč do tabulky invoices_item s položkami objednávky. Význam tohoto klíče je obdobný jako u rezervací ubytování – když je nastaven na nenulovou hodnotu, je startovné v turnaji závazně objednáno.

26

KAPITOLA 5. NÁVRH

Kapitola 6

Implementace 6.1 6.1.1

Průběh implementace Harmonogram

Implementace probíhala ve dvou fázích. Na obrázku 6.1.1 je zachycen průběh vývoje jako množství neprázdných řádků kódu programu v čase. První fáze vývoje probíhala v prosinci roku 2010. Aplikace na konci této fáze plnila dva ze tří základních úkolů – vedla informace o rezervacích pokojů a přihláškách do turnaje, a její stav tou dobou tak lze považovat za funkční prototyp. Instance aplikace byla nainstalována na hosting, databáze naplněna údaji z loňského ročníku, a celý systém tak byl dostupný uživatelům k testování. Aplikace tou dobou neevidovala žádná data pro nadcházející turnaj. Další podstatná část vývoje pak probíhala na přelomu února a března 2011, což byl nejvyšší čas vzhledem k termínu turnaje. Klíčovou chybějící funkcionalitou byla správa objednávek a plateb. Na začátku března 2011 pak byla nasazena produkční verze a ihned naplněna ostrými daty. Jelikož část účastníků tou dobou již zažádala o své rezervace, během několika dnů od nasazení do ostrého provozu, byla evidovaná ubytovací kapacita z podstatné části zaplněna. Po nasazení aplikace do ostrého provozu na začátku března 2011 se v ní neobjevily podstatné chyby a nenastaly žádné nečekané komplikace. V první produkčně instalované verzi tak aplikace fungovala až do poloviny dubna a evidovala veškeré účastníky turnaje ve Slavonicích. Před samým začátkem turnaje bylo třeba ještě implementovat exporty pro MS Excel, které organizátor potřeboval k vyrovnání účtů s hotely a vůbec kontrolu účetnictví. Turnaj ve Slavonicích proběhl, jak bylo naplánováno, na přelomu dubna a května. Dorazilo na něj 16 týmů, což s několika dalšími nehrajícími účastníky dává necelých 80 osob, ke kterým nová aplikace evidovala potřebné údaje.

6.1.2

Fáze vývoje

První verze aplikace vznikla před koncem roku 2010. Pohled do statistiky počtu řádků programu říká, že vývoj byl ve své necelé polovině. Statistiku počtu řádků je samozřejmě

27

28

KAPITOLA 6. IMPLEMENTACE

Obrázek 6.1: Vývoj počtu řádků kódu v čase

nutno brát jako velmi nepřesné měřítko – i příklad toho projektu ukazuje, že se různé fáze vývoje diametrálně liší. Na první pohled se největší část aplikace mohla zdát po první fázi hotová, neboť bylo možno organizovat jak informace o rezervacích ubytování, tak o přihláškách do turnaje. Jediná chybějící podstatná funkcionalita tak byla správa objednávek a plateb. Implementace správy objednávek nicméně řádově posouvá složitost aplikace. Informace o rezervacích lůžek je veskrze statická bez složité logiky. Správa objednávek ovšem musí být přesně definovaný proces s pravidly, která aplikace musí dodržovat a vynucovat. Je třeba zajistit, aby veškeré postupy probíhaly jak je definováno a databáze se nedostala do nekonzistentního stavu.

6.1.3

Konfrontace analýzy s realitou

Při plánovaní implementace správy objednávek a plateb se ukázalo, že veškeré potenciální situace nejsou dobře podchyceny specifikací a chování systému v určitých případech není definováno. Kombinace možnosti rozepsat jednu rezervaci pokoje na několik různých objednávek a potenciálního následného storna nebyla v krajních případech dobře definována.

6.1. PRŮBĚH IMPLEMENTACE

Obrázek 6.2: Screenshot úvodní stránky

Obrázek 6.3: Screenshot rezervačního formuláře

29

30


Vyvstávala tak otázka co dělat, když jeden z účastníků stornuje svoji objednávku, což ovlivní jiného, který již zaplatil. Jako příklad lze uvést situaci, kdy účastník zruší objednávku ubytování, přitom ale startovné do turnaje již bylo zaplaceno – systém by neměl umožnit hrát neubytovaným, ale nelze zrušit jednou zaplacenou přihlášku. Na chybějící specifikaci v této fázi vývoje lze nahlížet dvěma způsoby. Buď jako pochybení, a to jednak ze strany zadavatele při formulaci požadavků, tak hlavně ze strany vývoje při analýze projektu. Každá problematická situace, která byla při analýze opomenuta, znamená navýšení času nutného na implementaci. Takové navýšení je nepříjemné, protože se neúměrně natahuje spuštění na první pohled skoro dokončeného projektu. Lze zaujmout i méně kritický pohled na věc. První verze aplikace byla naprogramována v relativně krátkém čase a je možné, že opravdu zevrubná analýza by zabrala více času než vytvoření a spuštění první verze, a pak i v případě velmi poctivé analýzy nelze zaručit, že nebude nic podstatného opomenuto. Na aplikaci v tomto stavu lze nahlížet jako na fungující prototyp, který umožňuje a pomáhá doladit nutné detaily.

6.1.4

Další analýza na základě předchozí zkušenosti

Po první fázi byla implementována podpora pro správu ubytovacích kapacit a přihlášky do turnaje a teprve byla plánována implementace objednávek a plateb. Zkušenost s již hotovu částí byla cenná při analýze a návrhu dalšího vývoje. Po zkušenosti s vývojem a testováním prototypu se ukázalo, že aplikace by neměla nastavovat přílišná omezení a svazovat uživateli ruce. Uživatel aplikace je zároveň organizátorem turnaje a nedává smysl ho příliš omezovat jeho vlastními pravidly. S ohledem na pružnost se ukázalo jako vhodné nastavit vazbu mezi rezervací a objednávkou co nejslabší. Toto zjištění odpovídá tomu, co je popsáno v analytické části této práce. Práce je strukturována od analýzy k implementaci, ale chronologické pořadí vývoje je odlišné. Nejdříve byla implementována jedna část a teprve následně podrobně analyzována a plánována část druhá.

6.1.5

Využití prototypu

Práce s prototypem pomohla vyjasnit nejrůznější detaily a také ukázat na několik omylů, kterých se nepodařilo vyvarovat. Organizátor turnaje po práci s prototypem částečně upravil své zadaní. Naopak z pohledu vývoje se podařilo objevit detaily, které je nutno dospecifikovat. Veškeré nejasnosti, které nastaly, ať už z důvodu rozdílů v chápání či detailů opomenutých v analýze, lze označit za marginální z důvodu minimální pravděpodobnosti. Například výše nastíněná potenciálně problémová situace (dva účastníci bydlí spolu na pokoji, platba za ubytování je dohromady na jedné objednávce, startovné si ale platní každý hráč zvlášť) snad vůbec nenastala. Vezme-li navíc v úvahu, že storen jsou řádově jednotky ročně a zpravidla ruší objednávku oba z páru zároveň, tak šance, že by jeden účastník zrušil ubytování jinému je zanedbatelná. V praxi naopak nastaly různé situace, na které předem nikdo nepomyslel, a v aplikaci tak nebyly postihnuty. Například se ukázalo, že jeden z hotelů výrazně snížil ceny a pořadatel tak

6.2. STRUKTURA APLIKACE

Adresář/Soubor bootstrap.py setup.py doc/ requirements.txt env/ src/ chaosbridge/ www/ .htaccess dispatch.fcgi static/

31

Význam skript pro vytvoření virtuálního prostředí instalační skript adresář s dokumentací soubor se seznam závislostí virtuálního prostředí zdrojové kódy aplikace Python modul s aplikací DocumentRoot pro server Apache konfigurace webového serveru FastCGI vstupní bod aplikace adresář se statickými soubory

Tabulka 6.1: Adresářová struktura instalace

následně chtěl vrátit část již realizovaných plateb za ubytování. Dalším příkladem může být rezervace pokoje, který byl teoreticky vyhrazen organizátorovi turnaje a veden v aplikaci, v praxi ho ale majitel hotelu již pronajal, aniž by o tom informoval. Nestandardní situace je často nutno řešit ad hoc a je třeba hledat východisko pro každý jeden konkrétní problém zvlášť. Žádný systém nemůže dopředu postihnout všechny potenciální případy. Aplikace pro organizaci bridžového turnaje, která vznikla v rámci této bakalářské práce, funguje tedy tak, aby svého uživatele zbytečně nesvazovala a on mohl pružně reagovat na nastalé situace.

6.2 6.2.1

Struktura aplikace Virtuální prostředí

Tabulka 6.1 zachycuje typickou instalaci aplikace. Jelikož je produkční prostředí vytvořeno na sdíleném hostingu, není tak k dispozici administrátorský (root) účet a nelze instalovat přímo do systému. Z tohoto důvodu se vytváří virtuální prostředí nástrojem virtualenv [5]. V kořeni adresářové struktury je umístěn k tomu určený skript bootstrap.py. Jedná se vlastně jen o kopii nástroje virtualenv. Prostředí pro běh aplikace je typicky vytvořeno v podadresáři env. Dále je přítomen adresář s dokumentací (zatím dokumentace obsahuje pouze instalační pokyny), ve kterém lze nalézt soubor requirements.txt se seznamem všech závislostí. Seznam je ve formátu, kterému rozumí instalační nástroj pip [12], díky čemuž je možno nainstalovat veškeré závislosti jedním příkazem. Vlastní aplikace pak obsahuje standardní instalační skript setup.py využívající oblíbené setuptools [8], kterým je možno aplikaci do vytvořeného prostředí nainstalovat.

32


Adresář/Soubor chaosbridge/ accommodation/ accounts/ events/ invoices/ settings/ static/ templates/ tournaments/ __init__.py manage.py urls.py

Význam balíček s aplikací modul pro ubytování podpora pro uživatelské účty modul s jádrem aplikace modul pro objednávky a platby konfigurace statické soubory HTML šablony modul pro přihlášky do turnaje prázdný skript pro ovládání aplikace definice URL webu

Tabulka 6.2: Struktura zdrojových souborů

6.2.2

Kořen webu

Kořen webu dostupný přes webové rozhraní (DocumentRoot) je umístěn v podadresáři www, což je důležité mimo jiné pro bezpečnost aplikace – uživatel by se neměl dostat ke zdrojovému kódu nebo konfiguraci. Jelikož jsou veškeré aplikační soubory mimo adresář dostupný z webu, tak i v případě špatného nastavení uživatelských oprávnění zůstanou všechny potenciálně citlivé soubory skryty. Webový server komunikuje s aplikací přes FastCGI rozhraní. Příslušný skript se nachází v souboru dispatch.fcgi. Pro Apache je pak připravena konfigurace v .htaccess, která ho na příslušný FastCGI skript odkáže. Kořen webu je jinak skoro prázdný, neboť většina požadavků je předávána aplikaci napsané v Pythonu. Statické soubory, jako jsou obrázky, CSS či Java Script, jsou přítomny přímo v kořeni webu, neboť není důvod, aby požadavky na ně zatěžovaly aplikaci, a takto je může servírovat přímo webový server. Ve zdrojových souborech bychom ovšem statické soubory v kořeni webu hledali marně. Důvod je ten, že část statických souborů není přímo v aplikaci, ale je součástí některé ze závislostí. Statické soubory jsou do kořene webu kopírovány až během instalace, díky čemuž je vždy vybrána aktuální verze souboru odpovídající nainstalované verzi závislosti.

6.2.3

Zdrojové soubory

Veškeré zdrojové soubory se nacházejí v podadresáři src v Python balíčku chaosbridge1 . V tabulce Tabulka 6.2 je možno vidět obsah balíčku s aplikací. Dělí se na moduly odpovídající logické struktuře popsané v analytické části tohoto dokumentu. Modul events lze považovat za jádro aplikace. Moduly accommodation, tournaments a invoices pak odpovídají třem hlavním účelům aplikace – rezervace ubytování, přihlášky do turnaje a správa 1

Názvu chaosbridge byl zvolen dle jména bridžového klubu

6.2. STRUKTURA APLIKACE

33

objednávek a plateb. V modulu accounts je přetížena a rozšířena část funkcionality Django frameworku pro podporu uživatelských účtů, jako je přihlašování do systému či změna hesla. Kromě jmenovaných modulů jsou přítomny i tři soubory typické pro aplikace napsané v Djangu. Soubor __init__.py je prázdný, je vyžadován jazykem Python, aby adresář považoval za balíček, který lze importovat. V souboru urls.py je definice struktury URL webu. Nejzajímavější je asi skript manage.py, který umožňuje ovládat aplikaci z příkazového řádku. Po instalaci aplikace může být puštěn odkudkoliv pod aliasem chaos-admin. Vedle programu v jazyce Python, jsou v adresáři templates přítomny HTML šablony a v adresáři static jsou umístěny statické soubory jako obrázky, CSS nebo Java Script. Jak bylo zmíněno, statické soubory jsou během instalace kopírovány (nebo případně symlinkovány) do kořene webu. Struktura jednotlivých modulů je také typická pro aplikace napsané v Djangu. Takže obsahují soubory jako models.py, views.py, urls.py nebo forms.py. V models.py je definován databázový model a ve views.py lze nalézt funkce zpracovávající jednotlivé HTTP požadavky. Která funkce bude volána pro jakou URL je určeno v urls.py. V souborech forms.py lze nalézt důležité části logiky aplikace – ve formulářích jsou zpracovávána data zadaná uživatelem do modelu definovaného aplikací.

34


Kapitola 7

Testování 7.1 7.1.1

Jednotkové testy Nástroje

Jazyk Python obsahuje ve své standardní knihovně modul pro psaní jednotkových testů a framework Django ho dále vhodně rozšiřuje. Tato infrastruktura je tak zřejmá volba pro testování vyvíjené aplikace. Pro výpočet pokrytí aplikace testy je pak využit nástroj coverage.py [4] v kombinaci s knihovnou nose [11]. Integraci těchto nástrojů do Django frameworku zajišťuje knihovna django-nose [3].

7.1.2

Pokrytí kódu testy

Jednotkové testy jsou velmi podstatnou součástí aplikace. Během procesu rezervace a následné objednávky je třeba zajistit dodržení pravidel a omezení podle zadání. Pečlivé psaní testů kontrolující jednotlivé požadavky na aplikaci při práci s formuláři značně snižuje riziko, že špatným zásahem do kódu vznikne chyba, která pak v důsledku bude vést k chybným informacím o plánovaném bridžovém turnaji. Pokrytí kódu aplikace testy činí 84%1 . Do výpočtu jsou zahrnuty veškeré příkazy aplikace s výjimkou kódu vlastních testů. Nejsou tak započítávány importované knihovny ani vlastní framework. V tabulce 7.1 je pak rozepsáno pokrytí jednotlivých modulů. Tohoto pokrytí je dosaženo celkem 116 jednotkovými testy. Samotný Django framework se pyšní množstvím testů a využívané knihovny jsou zpravidla také testy dobře pokryty.

7.2 7.2.1

Systémové testování Testy uživatelského rozhraní

Jedním ze specifik webových aplikací je, že uživatelé mohou použít kterýkoliv ze širokého výběru internetových prohlížečů. Z tohoto důvodu bylo testováno korektní zobrazování vzor1

Veškeré uvedené udaje o testech byly měřeny a počítány ke dni 16.5.

35

36

KAPITOLA 7. TESTOVÁNÍ

Modul chaosbridge chaosbridge.accommodation chaosbridge.accommodation.admin chaosbridge.accommodation.exports chaosbridge.accommodation.forms chaosbridge.accommodation.managers chaosbridge.accommodation.models chaosbridge.accommodation.permissions chaosbridge.accommodation.prices chaosbridge.accommodation.urls chaosbridge.accommodation.views chaosbridge.accounts chaosbridge.accounts.models chaosbridge.accounts.urls chaosbridge.accounts.views chaosbridge.events chaosbridge.events.admin chaosbridge.events.models chaosbridge.events.urls chaosbridge.events.views chaosbridge.invoices chaosbridge.invoices.admin chaosbridge.invoices.exports chaosbridge.invoices.forms chaosbridge.invoices.managers chaosbridge.invoices.models chaosbridge.invoices.permissions chaosbridge.invoices.urls chaosbridge.invoices.views chaosbridge.manage chaosbridge.settings chaosbridge.settings.base chaosbridge.settings.devel chaosbridge.settings.local chaosbridge.tournaments chaosbridge.tournaments.admin chaosbridge.tournaments.forms chaosbridge.tournaments.models chaosbridge.tournaments.urls chaosbridge.tournaments.views chaosbridge.urls chaosbridge.utils chaosbridge.utils.forms chaosbridge.utils.shortcuts CELKEM

Stmts 0 0 7 31 167 10 121 20 16 2 100 0 0 2 31 0 5 29 2 34 0 13 22 76 4 80 16 2 88 7 2 26 5 6 0 7 72 73 2 73 9 0 83 13 1256

Tabulka 7.1: Test coverage

Miss 0 0 0 3 3 2 5 1 5 0 34 0 0 0 21 0 0 2 0 19 0 0 4 1 0 4 0 0 12 2 0 0 0 0 0 0 19 7 0 58 0 0 3 0 205

Cover 100% 100% 100% 90% 98% 80% 96% 95% 69% 100% 66% 100% 100% 100% 32% 100% 100% 93% 100% 44% 100% 100% 82% 99% 100% 95% 100% 100% 86% 71% 100% 100% 100% 100% 100% 100% 74% 90% 100% 21% 100% 100% 96% 100% 84%

7.2. SYSTÉMOVÉ TESTOVÁNÍ

37

kem nejpoužívanějších prohlížečů. Aplikace byla testována v prohlížečích Internet Explorer ve verzích 6, 7 a 8, Mozilla Firefox ve verzích 3.6 a 4.0, Google Chrome ve verzi 11 a Opera ve verzi 11. Výstup z aplikace byl kontrolován na validitu HTML kódu a veškeré stránky odpovídají specifikaci.

7.2.2

Další testy

Možnosti systematického testování aplikace jsou omezené vzhledem k povaze projektu, která neumožňuje do testování výrazněji investovat. Lze tak konstatovat, že většina systémového testování byla provedena zadavatelem a aplikace byla prověřena především ostrým provozem. Například uživatelské testování by jistě přineslo zajímavé výsledky, ovšem jelikož aplikaci používá víceméně jen jedna osoba organizátora turnaje, investice do takového testu by byla nevýhodná. Testovat výkon či škálovatelnost také nedává valný smysl, neboť aplikace je instalována na levném nevýkonném hostingu za oceánem, a případný test by tak neprověřoval aplikaci samotnou, ale hosting a kvalitu připojení. Jelikož cílem je využití hotové aplikace i pro další pořádané bridžové a nebridžové akce, lepší testování systému je nevyhnutelné, pokud chceme tento cíl naplnit. Systematické testování je jasnou výzvou do budoucna.

38

KAPITOLA 7. TESTOVÁNÍ

Kapitola 8

Závěr 8.1

Implementované řešení

Aplikace, která byla implementována v rámci předkládané bakalářské práce, prokázala svoji funkčnost při organizaci čtvrtého ročníku mezinárodního bridžového turnaje ve Slavonicích. Během příprav na turnaj byly v aplikaci vedeny rezervace ubytování, přihlášky účastníků do turnaje a systém evidoval závazné objednávky spolu s požadovanými platbami. Uživatelské rozhraní je uzpůsobeno tak, aby často prováděné úkony, zabíraly organizátorovi turnaje co možná nejkratší čas. Jelikož do aplikace mají přístup pouze vybrané osoby, bylo možno dát uživatelům relativně široké možnosti nakládání s daty, což jim umožňuje efektivně reagovat na nestandardní situace při organizaci turnaje. Data ze systému lze exportovat do souborů pro MS Excel. Tyto exporty pak lze předat jako podklady jednotlivým hotelům a organizátor může na jejich základě zkontrolovat a uzavřít učetnictví turnaje.

8.2

Možnosti rozvoje

Implementovaný rezervační systém byl postaven na solidních základech, které by měly umožnit další rozvoj aplikace. Ta byla navržena modulárně tak, aby v budoucnu šlo rozšiřovat funkcionalitu novými moduly. Relativně drobné změny či trocha další práce mohou řádově rozšířit současné možnosti aplikace. Již ve stávající implementaci lze nalézt odpovědi na případné budoucí požadavky. Kombinace využitého frameworku v pozadí, robustního návrhu a poctivé implementace nabízí funkcionalitu, která pro turnaj ve Slavonicích nebyla třeba, ale potenciálně může být využita. Například uživatelská oprávnění jsou kontrolována na dvou úrovních. Nejdříve je vyžadován účet ke vstupu do aplikace a před každou akcí je kontrolováno oprávnění příslušnou změnu provést. Django framework obsahuje knihovnu pro správu uživatelských oprávnění a aplikace ji využívá. Takže již současná implementace umožňuje zařídit omezené uživatelské účty s oprávněním zadávat rezervace, ale bez možnosti vytvořit či potvrdit objednávku. V případě, že bychom umožnili registraci nových uživatelů (na což lze použít existující knihovny) účastníci by si mohli rezervovat ubytování přímo.

39

40

KAPITOLA 8. ZÁVĚR

Podobná funkcionalita nebyla pro turnaj ve Slavonicích požadována a proto není ani dokumentována. V případě reálné potřeby bude velmi důležitá analýza procesu objednávky, do kterého mohou vstupovat cizí osoby, dokumentace a pečlivé testování, samotná implementace je hotova nebo relativně triviální. Otevření systému dalším osobám s sebou přináší nemalé množství komplikací, které je třeba dobře rozmyslet, ale vlastní programování je nejmenší problém.

8.3

Budoucí využití

Aplikace byla vyvíjena s ohledem na další možné využití. Do databáze lze vložit informace o příštím turnaji, k němuž tak beze změn v kódu programu současná instalace umožní vést informace, a bude tak napomáhat v jeho organizaci. Zřejmé další využití je organizace budoucích turnajů pořádaných bridžovým klubem Chaos, který stojí za turnajem ve Slavonicích. Současná implementace počítá s některými specifiky turnaje ve Slavonicích, jako je například povinnost rezervace ubytování všemi hráči, díky čemuž bylo možno zefektivnit práci s uživatelským rozhraním. V případě požadavku na nasazení aplikace pro jinou bridžovou událost tak ale bude pravděpodobně třeba zásah do kódu programu a jeho zobecnění. Návrh aplikace již se zobecněním počítá, funkcionalita specifická pro slavonický turnaj je implementována pouze v prezentační vrstvě, takže úpravy nutné pro další bridžové akce by neměly být nijak složité. Další využití lze hledat i mimo bridžovou obec. Stejný systém může fungovat i pro organizaci turnajů v jiných sportech a aplikaci tak mohou využít další organizace. Pokud jde o rezervační systémy, nenalezl jsem žádné renomované či široce rozšířené řešení. Navíc rezervace kapacit ke konkrétní události funguje v mnohém jinak než standardní rezervační systém. Zde je možné vidět prostor na trhu, který by systém postavený na vyvinuté aplikaci mohl zaplnit. Znamenalo by to ale další a dlouhodobý vývoj, který řádově přesahuje rozsah této bakalářské práce.

Příloha A

Obsah přiloženého DVD Adresář/Soubor data/ code/ chaosbridge/ django-xl/ README.txt bakalarska-prace.pdf

Obsah Zdrojové soubory k této práci (latex, ...) Zdrojové soubory programu Vlastní aplikace Knihovna pro export do formátu XLS Instrukce k instalaci Bakalářská práce v pdf formátu

Tabulka A.1: Obsah přiloženého DVD

41

42

PŘÍLOHA A. OBSAH PŘILOŽENÉHO DVD

Literatura [1] Appcelerator, Inc. PyDev [online]. [cit. 16. 5. 2011]. Dostupné z: . [2] APTANA, I. Aptana Studio [online]. [cit. 16. 5. 2011]. Dostupné z: . [3] BALOGH, J. django-nose [online]. [cit. 16. 5. 2011]. Dostupné z: . [4] BATCHELDER, N. coverage.py [online]. [cit. 16. 5. 2011]. Dostupné z: . [5] BICKING, I. virtualenv [online]. [cit. 16. 5. 2011]. Dostupné z: . [6] Django Software Foundation. Django [online]. [cit. 16. 5. 2011]. Dostupné z: . [7] DREAMHOST. Dreamhost [online]. [cit. 16. 5. 2011]. Dostupné z: . [8] EBY, P. J. setuptools 0.6c11 [online]. [cit. 19. 5. 2011]. Dostupné z: . [9] EBY, P. J. PEP 333 – Python Web Server Gateway Interface v1.0 [online]. [cit. 16. 5. 2011]. Dostupné z: . [10] MACHIN, J. xlwt [online]. [cit. 16. 5. 2011]. Dostupné z: . [11] PELLERIN, J. nose [online]. [cit. 16. 5. 2011]. Dostupné z: . [12] pip developers. pip [online]. [cit. 16. 5. 2011]. Dostupné z: . [13] POJMAN, M. django-urldecorators [online]. [cit. 16. 5. 2011]. Dostupné z: .

43

44

[14] SADDI, A. flup [online]. [cit. 16. 5. 2011]. Dostupné z: . [15] WILLISON, S. django-html [online]. [cit. 16. 5. 2011]. Dostupné z: .

LITERATURA

Webová aplikace pro organizaci bridžového turnaje. Miloslav Pojman

Recommend Documents