Mendelova univerzita v Brně Provozně ekonomická fakulta
Tvorba programové podpory manažerské hry pro předmět Strategický management Diplomová práce
Vedoucí práce: doc. Ing. Pavel Žufan, Ph.D.
Bc. Petr Hanák
Brno 2012
Místo této stránky je v tištěné verzi vloženo zadání práce.
Prohlašuji, že jsem diplomovou práci na téma Tvorba programové podpory manažerské hry pro předmět Strategický management vypracoval samostatně s použitím literatury a zdrojů uvedených v seznamu.
Abstract Hanák, P. Programming support for management game in Strategic management course. Diploma thesis. Brno, 2012 Diploma thesis deals with the project of web application for management game from Department of Management. It begins with description of the management game state after its creation. Thesis further consider of creation the new version of web application. In thesis I also describe the referred technology and procedures for the design and implementation and I evaluate the results. I finally describe the possibilites of further improvements of the computer support of this game.
Abstrakt Hanák, P. Tvorba programové podpory manažerské hry pro předmět Strategický management. Diplomová práce. Brno, 2012. Diplomová práce se zabývá projektem webové aplikace pro manažerskou hru Ústavu managementu. Začíná popisem stavu, ve kterém se tato hra nacházela po jejím vytvoření. Práce se dále zaměřuje na tvorbu nové verze webové aplikace. V práci též popisuji použité technologie a postupy pro návrh a implementaci a jsou zhodnoceny dosažené výsledky. Na závěr popisuji možnosti dalších zlepšení počítačových podpor této hry.
Je mojí milou povinností poděkovat těm, jejichž vliv na tuto práci byl pro mne zásadní. Děkuji vedoucímu mé práce doc. Ing. Pavlu Žufanovi, Ph.D. za veškeré rady a připomínky. Nesmím též zapomenout na svoji rodinu za neutuchající podporu při studiu na Provozně ekonomické fakultě. Lence Dresslerové pak děkuji především za neuvěřitelnou trpělivost.
E Provedené úpravy pravidel v rámci implementace nových podpor 89 F Návrhy pro nová pravidla hry F.1 Kritika současných pravidel . . . . . . . . . . . . . . . . . . . . . . F.1.1 Kritická analýza možných strategických rozhodnutí podle Portera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.1.2 Problém toku času v současném modelu . . . . . . . . . . . F.2 Možnosti zlepšení . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.1 Změna vnitřního toku času ze skokového na „plynulýÿ . . . F.2.2 Zvýšení komplexnosti pravidel . . . . . . . . . . . . . . . . .
92 . 92 . . . . .
92 93 94 94 94
G Efektivní vývoj a údržba aplikace v paralelních větvích
96
H Ukázka makra pro nástrojb SeleniumIDE
97
8
OBSAH
I
Základní statická analýza kódu pro verzi I.1 Výstup programu phploc . . . . . . . . . I.2 Výstup programu phpcpd . . . . . . . . I.3 Vizualizace metrik programem pdepend . I.4 Výstup programu phpmd . . . . . . . . .
R022 . . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
99 99 100 100 101
1
ÚVOD A CíL PRÁCE
1
9
Úvod a cíl práce
1.1
Úvod
Hra „Výroba nábytkuÿ je manažerská hra z odvětví výroby kancelářského nábytku. Jde o zjednodušenou simulaci vybraných procesů výrobního podniku a jeho působení na modelovaném trhu. Hra „Výroba nábytkuÿ je využívána na Provozně ekonomické fakultě, konkrétně v rámci předmětu Strategický management, pro výukové účely od akademického roku 2001/2002. V tomto roce byl dokončen vývoj její první funkční verze, ke kterému dala impuls nakonec neúspěšná spolupráce s holandskou firmou Rematch, b. v., již v roce 1994. Vývoj hry probíhal z vnitřních zdrojů Ústavu managementu, kde po hledání vhodného software bylo nakonec přistoupeno k pokusu realizovat hru prostřednictvím tabulkového procesoru. V tomto prostředí byla také hra dokončena. Manažerská hra dle svých tvůrců sledovala především následující výukové cíle pro hráče (studenty PEF): • Poznávání úkolů, funkcí a rolí vedoucího pracovníka. • Rozvoj analytických dovedností a strategického myšlení – sledování vývoje simulovaného prostředí a příprava vlastních rozhodnutí. • Poznání provázanosti podnikových funkcí. • Uvědomění si rozdílů mezi výnosy a příjmy, náklady a výdaji a jejich průmět do zisku a cash flow. • Vyzkoušení si rozhodování v kolektivu (díky nutné shodě členů týmu na jeho finálním rozhodnutí). • Poznání vlivu konkurence na podnikové aktivity a výsledky. • Praktická aplikace teorie studované v jiných předmětech. • Zajímavá a pro studenta přístupná forma poznatků podněcující aktivitu studentů. Současný stav však obsahuje jeden vážný problém. Při sehrávce hry v průběhu semestru zabírá tvorba výsledků pro hráče (studenty předmětu) velké množství času na straně vyučujících. Tvorba výsledků pro jeden modelovaný trh trvá vyučujícímu zhruba 15 minut. Na trhu soupeří obvykle pět herních firem, přičemž za firmu hraje tým složený ze dvou až čtyř studentů (obvykle právě tři) – s rostoucím počtem studentů předmětu logicky lineárně roste i časová náročnost tvorby výsledků pro jedno kolo. Též vzhledem k časové organizaci v rámci výuky předmětu není nikterak neobvyklé, že vyučující může začít vytvářet výsledky daného kola hry teprve v pátek odpoledne (po skončení posledního cvičení) a většinou i o víkendu, aby bylo možné výsledky zveřejnit hráčům, kteří mají cvičení v pondělí dopoledne. Navíc je veškerý běh hry závislý na osobě garanta předmětu, který je jako tvůrce aktuálně používaných pravidel hry také jediným, kdo dokáže výsledky vytvářet. V letech 2006 - 2011 byl průměrný počet firem 93, což odpovídá 19 trhům (díky pravidlu pět firem na jednom trhu). Je-li náročnost tvorby výsledků zhruba
1.2
Cíl práce
10
15 minut, tvorba výsledků v každém kole hry zabrala garantovi předmětu zhruba pět hodin. Při běžné sehrávce hry na osm kol pak garant předmětu strávil každý semestr téměř dva dny čistého času pouze tvorbou výsledků firem. Z tohoto důvodu též není uvažováno o jakémkoliv dalšímu rozvoji a zesložitění pravidel hry. Dříve byla časová náročnost pro vyučující ještě vyšší z důvodu nutnosti přepisovat rozhodnutí hráčů za firmu pro dané kolo hry z papírového formuláře do tabulkového procesoru. Tato situace byla již před několika lety odstraněna jednoduchým webovým rozhraním (vytvořeným též autorem této práce) umožňujícím přijmout rozhodnutí hráčů vyplněním HTML formuláře a uložit data do souboru formátu csv1 , který je možné dále zpracovávat v tabulkovém procesoru. Tím se odstranil časově nejnáročnější manuální proces náchylný na chyby. V současnosti je tedy oním nejnáročnějším manuálním krokem tvorba výsledků a vzniká logický požadavek i na jeho nahrazení za pomoci informačních technologií.
1.2
Cíl práce
S ohledem na stávající stav využití manažerské hry v předmětu Strategický management a budoucí plány vyučujících předmětu je třeba dosáhnout snížení časové náročnosti tvorby výsledků pro hráče. Hlavním cílem této práce je vytvoření nové webové aplikace pro manažerskou hru, aby mohl být nahrazen dosavadní způsob výpočtu výsledků náročný na čas a navíc náchylný k chybám. Východiskem bude poznání stávajícího stavu manažerské hry „Výroba nábytkuÿ a způsobu její organizace, zjištění její role v předmětu Strategický management, prostudování pravidel hry a zachycení procesů na straně hráčů i na straně vyučujících, vedoucích k úspěšné sehrávce hry. Z tohoto průzkumu je nutné extrahovat požadavky na budoucí systém a zvolit vhodné metodiky a technologie pro jeho vytvoření. Je též nutné patřičně vyzkoušet nový systém před uvedením do ostrého provozu. Dílčí cíle této práce jsou tedy následující: • • • •
Popsat výchozí stav manažerské hry a jejích podpor. Zvážení možnosti využití již vytvořeného prototypu, který dosud nebyl nasazen. Analyzovat požadavky na nový systém. Navrhnout a implementovat takový systém, který zlepší v současnosti používané podpory manažerské hry. • Ověřit praktickou použitelnost implementovaného systému a popsat možnosti jeho dalšího zlepšení. • Připravit systém co nejvíce pro praktické nasazení.
1
comma separated values
2
PŘEHLED LITERATURY
2
11
Přehled literatury
2.1
Životní cyklus projektu
Obecně se podle (Pezlar, 1999) softwarový projekt skládá z těchto kroků: • Úvodní studie – zaměřuje se především na cíle projektu, specifikaci problému, požadavky na technické a programové vybavení, podmínky personálních a materiálních podmínek, termíny a kritéria hodnocení úspěšnosti celého projektu. • Analýza problému a vytvoření logického modelu. • Návrh projektu, dekompozice na dílčí problémy, návrh metod řešení a podpůrných prostředků. • Realizace a implementace – návrh algoritmů, zápis kódu v syntaxi zvoleného programovacího jazyka, ladění programu. • Dokumentace projektu – dokumentace k algoritmům a kódům programů a aplikací, příručky pro užívání, smlouvy, předání výsledků, archivace. • Instalace a testování produktu – zavedení projektu do tzv. testovacího provozu, na malém množství uživatelů je provedena validace a verifikace produktu a jeho vlastností. • Provoz a údržba – závěrečná, ale nejdelší fáze projektu. V průběhu této fáze je prováděn další vývoj a údržba produktu, oprava chyb a je zajišťována bezpečnost dat. Každý úspěšný – tedy zavedený a prakticky používaný – projekt se žádnému z těmto kroků nevyhne. Je však více způsobů, jak k dokončení jednotlivých dílčích kroků přistupovat, každý se svými určitými výhodami a nevýhodami. V následujícím oddíle je proto uveden přehled základních metodik vývoje software, jejichž prostudování umožnilo volbu vlastního přístupu k projektu řešenému v rámci této diplomové práce, třebaže obecně softwarové metodiky předpokládají interakci celého týmu či dokonce několika týmů spolupracujících na softwarovém projektu.
2.2 2.2.1
Metodiky vývoje software Model vodopád
Jde o nejzákladnější a nejjednodušší metodu vývoje software. Projekt vyvíjený podle modelu vodopád postupuje v posloupnosti kroků, které začínají u prvotní myšlenky a končí u výsledného produktu. Na konci každého z kroků vývojový tým zhodnotí, jestli se může pustit do dalšího kroku, kdy jednotlivá fáze definuje přesná kritéria výstupu v podobě dokončených „softwarových artefaktůÿ (dokumentů specifikací, analýzy či návrhu, spustitelný kód, otestovaný kód atd.). Jednotlivé kroky jsou přitom diskrétní a nepřekrývají se. Způsob uvažování lze ilustrovat na fázích analýzy a designu, kdy cílem je ještě před napsáním prvního řádku programového kódu rozpracovat všechny neznámé a popsat všechny detaily. (Pressman, 2001, s. 28)
2.2
Metodiky vývoje software
12
Tento styl vývoje se často popisuje jako zcela překonaný a nejhorší možný. Má totiž zásadní nevýhodu — počítá s tím, že vše je po uzavření fáze neměnné. Přitom v rychle se měnícím a vysoce konkurenčním IT průmyslu je změna v průběhu vývoje (požadavků, návrhu, technologií atd.) naprosto běžná, ať už ze strany zákazníka, nebo vývojářského týmu vlivem lepšího porozumění systému, který je vyvíjen. Jde nicméně o jednoduchý a pochopitelný styl vývoje, kdy ostatní metodiky alespoň částečně jeho přístup používají. Iterativní metody ostatně svůj přístup nejjednodušeji popisují jako „sérii vodopádůÿ.
Obr. 1: Vodopádový model vývoje software
2.2.2
Spirálový model
Tento model zavedl Barry Boehm již v roce 1986 a s určitým nadhledem se používá de facto dodnes, pouze v různých variacích. Někteří ho ztotožňují s „iterativnímÿ vývojem, jiní popisují rozdíly – rozhodně se však jedná o zcela odlišný styl vývoje oproti modelu vodopádu. Základní myšlenka, na které je spirálový model postaven je ta, že ze začátku nelze vše definovat podrobně. Začne se proto s malou definicí těch nejdůležitějších funkcí, vyzkouší se, vyžádají se připomínky od zadavatele a
2.2
Metodiky vývoje software
13
poté přecházíme do nového cyklu vývoje. Celý proces se opakuje, dokud se nedojde k výslednému produktu. Zcela běžně po nasazení systému dochází k vzniku dalších požadavků od zákazníků na základě praktického používání a tak vývoj ve spirále plynule pokračuje dál.(Pressman, 2001, s. 36) Zákazníci pak díky pravidelnému vydávání produktu dříve vidí konkrétní stav aplikace, případně mohou už systém (byť omezeně) používat. Především je při použití této metodiky dříve a častěji zpětná vazba od zákazníků o vyvíjeném produktu. Též je menší tlak v zájmu dodržování plánu na zkracování či omezování fáze testování, jak tomu často bývá u projektů řízených vodopádovou metodikou s fixním termínem dodání.
Obr. 2: Spirálový model vývoje software
2.2.3
Unified Process
Jedná se o označení určitého abstraktního rámce vývoje softwaru, ze kterého jsou odvozena variantní řešení. Nejznámějším je komerční varianta Rational unified process s mnoha podpůrnými nástroji, nebo naopak odlehčený Agile unified process. Pro svoji otevřenost je též známa druhá svobodná varianta Open UP2 , blížeji viz obr. č. 4. Unified process je svým způsobem hybridní metodika vývoje softwaru – 2
viz např. epf.eclipse.org/wikis/openup/
2.2
Metodiky vývoje software
14
kombinuje jak sériový, ostře ohraničený vodopádový pohled na projekt, tak iterativní přístup v samotné tvorbě. Unified process dělí projekt na čtyři hlavní fáze: • Inception (Zahájení) – nejkratší fáze na počátku projektu, kdy se rozhoduje o hlavním smyslu projektu a kolik zdrojů je k dispozici na jeho dokončení. Pro přechod do dalších fází musí být dostatečně jasný důvod projektu a vyhodnocena jeho realizovatelnost, především z ekonomického hlediska. • Elaboration (Příprava) – na konci této fáze by měly být dostatečně zanalyzovány požadavky, identifikovány nejdůležitější funkcionality budoucího systému a jasná představa o celkové architektuře systému. Po této fázi by měla být nalezena a vyřešena největší rizika v projektu. Obvykle se nejproblematičtější záležitosti vývojový tým snaží pokrýt prototypy pro co nejpřesnější představu o vhodném způsobu řešení; protopy se buď využijí ve finálním produktu a nebo zahodí. • Construction (Konstrukce) – obvykle nejdelší fáze, iterativním způsobem je pokračováno v tvorbě systému (proto je hranice mezi touto a předchozí fází mnohdy nejasná a mlhavá). Na konci této fáze je dokončeno (naprogramováno, otestováno, zdokumentováno atd.) dostatek funcionalit k nasazení projektu. • Transition (Předávání) – tato fáze shrnuje aktivity po nasazení projektu, ty už obvykle iterativním způsobem nejsou prováděny, ač může jít též o časově náročné aktivity. Jde například o ostré nasazení do datových center, migrace dat z předchozí verze programu, zaškolování obsluhy, propagace a podobně. Tyto fáze odpovídají onomu sériovému pohledu na projekt. Jde o celkový pohled na projekt, na veškeré kroky jeho životním cyklu. Dílčí disciplíny softwarového inženýrství (analýza, návrh, kódování aj.) se pak provádějí v iteracích, blíže viz obr. č. 3. 2.2.4
Agilní metodiky vývoje
Pod tímto názvem se skrývá celá řada metodik a stylů vývoje, které sdílejí určité principy, definované v tzv. „manifestu agilního programováníÿ3 . Metodiky agilního programování tedy dle manifestu upřednostňují: • • • • •
Jednotlivce a interakce před procesy a nástroji. Fungující software před vyčerpávající dokumentací. Spolupráci se zákazníkem před vyjednáváním o smlouvě. Schopnost reagovat na změny před dodržováním plánu. Věci uvedené napravo nejsou bezcenné, ale věcí nalevo si ceníme víc.
Mezi nejznámější agilní metodiky vývoje podle (Highsmith, 2002) patří Scrum, Extrémní programování (XP), Crystal a Dynamic Systems Developement Method 3
http://www.agilemanifesto.org/iso/cs/
2.2
Metodiky vývoje software
15
Obr. 3: Metodika vývoje software „Unified processÿ
(DSDM). V poslední době pak seznam doplňuje velmi přímočará metodika vývoje Kanban. Agilní metodiky obecně vidí větší důležitost v lidech samotných a v jejich schopnostech, bez ohledu jaké metody a nástroje při vývoji používají — to je v přímém protikladu klasických metodik, které vidí lidi v jejich daných rolích spíše jako zaměnitelné zdroje a důraz kladou na metodiky a používané nástroje jako hlavní zdroj zvyšování produktivity. Největší síla agilních metodik se tak projevuje v malých týmech, kdy ještě lidé mají příležitost se fyzicky potkávat a usnadňuje se tak komunikace. Agilní metody vývoje též mají tendenci upřednostňovat ty softwarové artefakty, které jsou co nejblíže samotnému kódu implementace, resp. které podléhají stejné metodě a ideálně i nástroji řízení změn jako kód. Jako příklad lze uvést specifikaci požadavků – agilní metodiky vždy upřednostní stručnější specifikaci, v ideálním případě ve formě popisů spustitelných testů (bez ohledu na úroveň testů; jednotkových, integračních či akceptačních), před vyčerpávající dokumentací požadavků, která ale má v praxi tendenci zastarávat a neodpovídat verzi kódu po aplikovaných změnách4 . 4
Protože při fixním čase se logicky upřednostní kódování změny, pak testování změny a až poté se obvykle provedená změna dokumentuje. Nicméně test, který hlásí, že neprošel, má lepší šanci být aktualizován, než dokument popisující specifikaci do nejmenších podrobností.
2.3
Testování
16
Obr. 4: Celkový pohled na aktivity metodiku „Unified processÿ ve variantě OpenUP, zdroj epf.eclipse.org/wikis/openup/
Vzhledem k důrazu na reakci na změnu je zřejmé, že agilní metodiky vývoje vždy využívají iterativní a inkrementální styl vývoje softwaru. Změna (požadavků na systém) není pouze očekávána, je dokonce vítána, řeší-li lépe požadavky koncového uživatele, přesněji přináší-li mu další přidanou hodnotu; jde o jeden z dvanácti principů vyplývajících z manifestu agilního vývoje, které jsou popsány např. v (Shore, Warden, 2008, 11). Běžnou technikou je tak iterace plánovat po fixních dobách (tzv. „time boxingÿ), obvykle jeden až čtyři týdny, delší iterace by ztrácely svůj smysl. Pokud některá funkcionalita není dokončena v rámci naplánové iterace, posouvá se do další iterace — neposouvají se termíny vydání. Jde tedy o styl adaptivního plánování namísto striktně prediktivního plánování asociovaného s vodopádovovou metodou vývoje.
2.3
Testování
Důležitou oblastí v softwarovém projektu je testování, respektive kontrola kvality software. Jak uvádí (Pressman, 2001, s. 126), díky zvýšenému používání softwaru jako systémové komponenty a nákladům asociovaným s případním selháním soft-
2.3
Testování
17
waru, není nikterak neobvyklé, že vývojové týmy spotřebují třicet až čtyřicet procent zdrojů v projektu na testování. U extrémně důležitých systému (např. řízení letecké kontroly) mohou náklady pouze na testování překročit třikrát i pětkrát náklady na veškeré ostatní kroky softwarového inženýrství dohromady. Testování by tedy rozhodně nemělo být považováno za synonymum k ladění programu za pomoci debuggeru5 . Úplné otestování programu je pak považováno za nemožné, neboť i nejtriviálnější programy nelze otestovat pro veškeré možné vstupy, všechny vnitřní stavy a cesty v kódu, na veškerých možných prostředích a konfiguracích. Podle (Burnstein, 2003, s. 23) lze pojem „kvalita softwareÿ vysvětlit dvěma způsoby. Za prvé, jako relativní úroveň, do jaké systém, systémová komponenta nebo proces dosahuje stanovených požadavků (specifikace). Druhou variantou je pak úvaha, že jde o úroveň, do jaké systém, systémová komponenta nebo proces splňuje očekávání koncového uživatele, jeho reálné potřeby. Cíle testování jsou v literatuře popisovány různě, i když v zásadě se shodným úmyslem. Nejčastější uváděné cíle se shodují s popisem uvedeným v (Myers, 2004, s. 6), tedy „prokázání, že program dělá to, co je očekávánoÿ a „prokázání, že program neobsahuje chyby, tedy že nevykonává něco, co není očekávánoÿ; nepřímo pak testování definuje jako „proces hledání chyb v programuÿ, tedy očekávání existence chyb a snaha o jejich nalezení. Praxe nicméně ukazuje, že úkoly a cíle testování by měly přesahovat pouhou snahu o nacházení chyb resp. dokazování, že software funguje – ve vztahu ke kvalitě software je základním cílem testování snižování rizik v softwaru a jde tak o rovnocennou participaci na projektu jako celku ve vztahu se samotným vývojem softare i projektovým managementem. Způsoby testování lze rozdělit na dvě základní oblasti, manuální (vyžadující přítomnost člověka v procesu provedení jednotlivých kroků testového scénáře) a automatické (testové skripty apod.). Obdobně základní rozdělení je pak podle způsobu testování ve vztahu k testovanému systému – „black boxÿ testování uvažuje pouze o vstupech a výstupech systému bez znalosti vnitřních vazeb, zatímco „white boxÿ testování předpokládá možnost sledování všech změn vstupů na výstupy v systému.6 Provádění softwarového testování, speciálně u větších systémů, je obvykle prováděno na několika různých úrovních. Za obvyklé se uvádí tři nebo čtyři úrovně, například následující rozdělení, podle (Burnstein, 2003, s. 134). • Jednotkové testy (Unit tests). Za jednotku se považuje nejmenší možná softwarová komponenta, tedy nejčastěji třída, metoda nebo procedura. Jednotkové testy pak ověřují správnost chování této jednotky samostatně a izolovaně. Je-li daná jednotka obtížně testovatelná na této úrovni, jde obvykle o znak špatného 5
Proces ladění, „debuggingÿ totiž začíná až po nalezení chyby, zatímco metody testování se snaží chyby nacházet a částečně i jim předcházet – považujeme-li za chybu až nefunkční program, pak verifikace požadavků a návrhů testery může některé problémy odhalit i před samotným naprogramováním. 6 Praxe pak nejvíce odpovídá pojmu „gray boxÿ, tedy testování se znalostí vnitřního fungování systému, nicméně pouze do určité omezené míry.
2.3
Testování
18
návrhu (např. příliš komplexní, zavislost na příliš mnoha dalších částech systému, které jdou obtížně nahradit jejich náhradníky – tzv. „Mockyÿ a Stuby). • Integrační testy (Integration tests). V rámci integračního testování se kontroluje funkčnost několika jednotek dohromady v rámci definované skupiny (například chování celého modulu), případně několika subsystémů aplikace dohromady (např. aplikační kód, databáze a dané systémy třetích stran). Jednotky, které mohou být ověřeny jednotkovým testováním a stoprocentně funkční samy o sobě, mohou totiž vytvářet chyby až při jejich vzájemném propojení.7 • Systémové testy (System tests). Testování systému jako celku, tedy po úspěšné integraci všech dílčích modulů, se již nezaměřuje pouze na samotnou správnost chování (resp. hledání defektů), ale též na další charakteristiky systému, jako například výkonnost, použitelnost a uživatelská přivětivost, spolehlivost (ve vztahu k chování při zatěži ale i obnově po chybě), bezpečnost, testování konfigurace (použití softwaru v různém prostředí, např. rozdílné operační systémy, různé prohlížeče, různý hardware) aj. Pro tento typ testování jsou pak obvykle zapotřebí specializované nástroje. • Akceptační testy (Acceptance tests). I zde je ověřován systém jako celek, ale nyní již ve vztahu k specifikaci, k zákazníkovým požadavkům. Kromě ověřování splnění požadavků samotným vývojovým týmem je pak běžné využití tzv. „alfaÿ a „betaÿ testování – testování prováděné samotnými zákazníky. Alfa testování je prováděno v kontrolovaných podmínkách, v prostředí vývojářského týmu; jsou však detekovány praktické problémy při používání softwaru. Beta testování je pak prováděno v praktických podmínkách, často i bez (možnosti) přímé kontroly ze strany vývojového týmu a jde pak de facto o totožnou situaci jako při ostrém nasazení, pouze na menší skupině uživatelů. V rámci tohoto oddílu o testování je vhodné z mnoha technik a metod doplnit testování regrese. Regresní testování je znovuotestování systému po určité provedené změně, aby bylo ověřeno, že nová verze splňuje kritéria stejně správně, jako verze starší, a že nebyl do systému zaveden žádný defekt. Změnou může být jak přidání nové funkcionality tak například refactoring kódu. Testování regrese pak může být prováděno na jakékoliv výše popsané úrovni. Protože změny při vývoji ale i při následné údržbě po nasazení jsou běžné, regresní testování je důležitou náplní testování jako inženýrské disciplíny; automatické nástroje pak ulehčují tento časově velmi náročný proces. 7
Příkladem takového problému budiž „slavnáÿ chyba sondy NASA, kdy jedna část navigačního programu byla naprogramována s použitím metrického systému a druhá naopak počítala se vzdálenostmi ve stopách.
2.4
Technologie pro tvorbu webových aplikací
2.4 2.4.1
19
Technologie pro tvorbu webových aplikací Programovací jazyk a aplikační framework
Webové aplikace (a samozřejmě jakékoliv jiné) je možné tvořit za pomoci různých programovacích jazyků s rozdílnými silnými a slabými stránkami. Je tedy třeba zhodnotit vhodnost daného jazyka pro určitý projekt – nejen z pohledu samotného psaní nové funkcionality, ale též možné problémy při další údržbě aplikace a její nasazení do daného prostředí (jak úzce, již existujících serverů, tak obecněji v dané instituci). Navíc nejde pouze o výběr programovacího jazyka. Dá se říci, že v dnešní době je stejně důležité (ne-li důležitější) zvážit existující knihovny a frameworky; dostupnost již existujícího, znovupoužitelného kódu je obrovská (ať již komerčního nebo open–source) a tak část softwarového inženýrství, byť i malého projektu, je ve své podstatě tvorba správného propojení již existujících dílčích řešení určitého obecného problému. Rozdíl mezi pojmy framework a knihovna je v míře abstrakce. Například v diplomové práci též zaměřené na tvorbu webových aplikací (Tichý, 2004) je situace viděna tak, že framework vzniká vhodným poskládáním jednotlivých knihoven dohromady, jejich účelným provázáním. Vzájemnými interakcemi mezi nimi často získáme dodatečné funkčnosti, které se u izolovaných knihoven nemohou objevit. Tímto postupem se tedy vytvoří pevný rámec, framework, uvnitř kterého se pak vyvíjí výsledná aplikace. Naopak (Pressman, 2001, s. 346) vidí „frameworkÿ více abstraktněji jako jeden z modelů softwarové architektury, jako pohled na abstrakci návrhu a vyjmutí těch architekturálních vzorů či rámců („frameworkůÿ), které jsou znovupoužitelné v podobných typech aplikací. V některých případech jsou oba pojmy popsány takřka jako synonyma bez zvláštního rozdílu, jako příklad lze uvést (Hlavenka, 1997); zde se v případě knihovny jedná o skupinu účelově zaměřených funkcí a programů, které je možno používat jako stavební prvky pro vlastní programátorskou tvorbu, zatímco framework je popsán velmi podobně jako sada tříd v objektově orientovaných systémech, které jsou jakýmsi rámcem pro řešení řady podobných problémů. Programátorsky orientovaná literatura (spojená s určitým programovacím jazykem či metodikou) pak tyto pojmy ani nevysvětluje a očekává znalost rozdílu u čtenáře. Jak autor této práce soudí, je framework možné chápat jako určitou „kostru aplikaceÿ, komplexnější prvek než je pouhá knihovna. Knihovna obvykle řeší určitý specifický problém, použitelná je v různých typech aplikací a její výměna za jinou či jenom za novější verzi je často triviální záležitost8 . Framework se naopak snaží řešit více problémů současně, často spolu souvisejících volně a nepřímo, a zásadně proto ovlivňuje architekturu budované aplikace. Často i pouhé povýšení existujícího frameworku na vyšší, novější verzi je spojeno s výrazně větším množstvím úprav ve vlastní aplikaci a výměna jednoho frameworku za jiný se v podstatě často blíží znovunapsání celé aplikace. 8
Dodržuje-li tvůrce knihovny zpětnou kompatibilitu a obecně API knihovny.
2.4
Technologie pro tvorbu webových aplikací
20
Na druhou stranu se částečně rozdíl stírá snahou o tvorbu modulárních frameworků, kdy je možné použít framework jako celek a nebo jenom některé z jeho částí. U takto postavených frameworků se tedy části (moduly) z jednoho frameworku používají jako knihovny uvnitř frameworku jiného.9 V současnosti nejčastěji využívané programovací jazyky pro tvorbu webových aplikací s nejznámějšími frameworky pro daný jazyk: • • • •
Java (Spring) a jazyky JVM10 kompatibilní — Groovy (Grails), Scala (Lift). Python (Django). Ruby (Rails, Merb). PHP (Zend, Symfony).
2.4.2
Databázový systém
Obvykle má webová aplikace potřebu zpracovávat vzájemně provázáná data a je nutné zajistit jejich trvalé uložení (persistence). V rámci této práce se sice nabízí přímočará možnost využití již existující struktury souborů tabulkového procesoru, nicméně jde o velmi nevhodné řešení vzhledem k nutnosti zajištění integrity dat při paralelním přístupu k nim, běžném v prostředí webových aplikací. Ustáleným řešením obou těchto problémů je přitom využívání databázových systémů založených na relačním modelu dat. Relační datový model popsal již v roce 1970 Dr. E. F. Codd a řešil nedostatky v té době používaných hierarchických a síťových modelů. Je založen na teorii množin, kdy za relaci se označuje libovolná podmnožina kartézského součinu. Relace může být trvalá (například tabulka), odvozená (určitý pohled na relaci trvalou) nebo dočasná (pouze v paměti, například při spojování tabulek). Protože relace je zároveň množina, můžeme s relacemi provádět množinové operace – sjednocení, průnik, rozdíl a kartézský součin (Šimůnek, 1999, s. 30, 31). V letech 1974 až 75 probíhal ve firmě IBM výzkum týkající se možnosti využití relačního datového modelu a pro tento projekt bylo nutné vytvořit sadu příkazů, kterými by se relační databáze ovládala. Vznikl tak jazyk SEQUEL (Structured English Query language), který se později přejmenoval na SQL (Structured Query Language). V osmdesátých letech pak začaly být prakticky využívány první relační databáze, ač zpočátku se jako „relačníÿ spíše pouze označovaly, neboť při implementaci určitých klíčových částí Coddova modelu selhaly. Jak je uváděno v (Groff, Weinberg, 2005, s. 82), Dr. Codd pak v roce 1985 ve svém článku v Computerworldu definoval 12 pravidel, kterými se musí databáze řídit, aby bylo možné ji považovat 9
V případě frameworku Nette zvoleného autorem této práce, viz oddíl 4.2.1, se podle uživatelského fóra nejčastěji využívají v rámci jiných frameworků třídy pro lepší podporu ladění/logování chyb na produkčním prostředí, RobotLoader pro automatické vkládání tříd uvnitř skritpů a šablonovací systém Latte. 10 Java Virtual Machine — sada programů a struktur vytvářející tzv. virtuální stroj, schopný zpracovávat Java bytecode.
2.4
Technologie pro tvorbu webových aplikací
21
za skutečně relační. Jeho pravidla vycházejí z teoretických prací na relačním modelu a i když představují spíše ideální cíl než přesnou definici, stalo se jeho dvanáct pravidel definicí neoficiální. Vzrůstající význam relačních databází si vyžádal nutnost standardizace jazyka pro jejich používání a Americký standardizační institut (ANSI) ho hodlal vytvořit na základě zcela nového jazyka RDL. Ukázalo se však, že jazyk SQL se používá jako standard de facto a proto byl nový standard založen na tomto jazyku a je označován podle roku přijetí pod názvem SQL–86; ten byl následován upravenou verzí označovanou SQL–92. Jelikož jde o standard de iure, je nutné se smířit s tím, že mezi jednotlivými existujícími relačními databázovými systémy jsou implemetační odlišnosti ztěžující možnost přenosu na jiný databázový systém. Relační databázový systém tak dnes představuje stabilní, standardizovanou a mnoha roky a projekty prověřenou metodu k uchovávání dat. Relační databázové systémy, plně podporující tzv. ACID11 zpracování transakcí, se staly de facto standardem pro webové aplikace v průběhu devadesátých let, ale projevila se i jejich slabá místa, především při nasazeních v distribuovaných systémech, v systémech často měnících samotnou strukturu ukládáných dat nebo u nasazení při velké zátěži. Problémy vznikající v distribuovaných systémech popsal Eric Brewer tzv. CAP teorémem. Aktuální trendy dalšího vývoje v databázových systémech jsou souhrnně označovány pod názvem NoSQL, ať už jde o objektově orientované databáze, dokumentově či grafově orientované databáze a nebo ukládání dat na principu klíč–hodnota. Jejich existence je doplněna pro úplnost, požadavky na vytvářený systém nevyžadovaly využití některého NoSQL databázového systému, naopak byly využity možnosti integrity dat spojené s databázemi nad relačním modelem ukládání dat. 2.4.3
ERD
ERD (Entity Relationship diagram) je model pro návrh relačních databází. Vychází z práce Petera Chena z roku 1976, existuje nicméně více variant notací. V současné době převažuje notace „Crow’s Footÿ, která zjednodušuje Chenovu notaci kreslením vztahů přímo jako spojujících čar mezi entitami, přičemž symboly u obou entit vyjadřují kardinalitu vztahů.12 Diagram je tak hutnější a přehlednější, obvykle pak entita v této notaci odpovídá tabulce v databázi (zatímco u Chenovy notace je obvykle nutné prvky diagramu do jednotlivých tabulek shlukovat). Podrobnější popis viz (Pressman, 2001, s.302 – s.309). Základní prvky ERD jsou tedy tyto: • Entita (popř. Datový objekt) – jde o jednoznačně identifikovatelný prvek, obvykle jako podstatné jméno. • Atribut – popis určité vlastnosti entity. • Vztah (Relace) – spojení mezi dvěma entitami, obvykle jako sloveso. 11
Atomicity, Consistency, Isolation, Durability. Seznam vlastností, které musí transakce v databázovém systému splňovat, aby bylo možné považovat její zpracování za spolehlivé. 12 Autorem využívaný nástroj MySQL Workbench používá právě notaci „Crow’s Footÿ
2.4
Technologie pro tvorbu webových aplikací
22
Vztahy mezi entitami mohou mít následující četnosti, neboli kardinality: • 1:1 – právě jeden unikátní objekt entity má vztah k pouze jednomu unikátnímu objektu druhé entity. • 1:N – právě jeden unikátní objekt entity má vztah k jednomu nebo více unikátním objektům druhé entity. Obvyklý vztah u tzv. „číselníkůÿ. • M:N – vztah, kde k jednomu nebo více unikátním objektům entity má vztah jeden nebo více unikátních objektů druhé entity. Tento vztah je v relačních databázích nutno realizovat pomocí tzv. „spojovníkové tabulkyÿ. Kardinalita popisuje maximální možný počet entit ve vzájemném vztahu. Nepodává nicméně informaci o tom, zda daný datový objekt je povinen se participovat v relaci. Pro specifikaci této informace je třeba definovat tzv. modalitu ve vzahu ke každé entitě účastnící se relace. • 0 – modalita relace je nula, pokud vztah je volitelný, nemusí v některých případech vůbec nastat. • 1 – modalita relace je jedna, pokud jde o povinnost datového objektu.
2.4.4
UML
V době, kdy ještě UML neexistovalo, se metodiky softwarového inženýrství pro tvorbu objektově orientovaných programů lišily prezentačními technikami, metodickými postupy a dostupnými nástroji. To vedlo ke snaze vytvořit jednotný jazyk pro modelování objektově orientovaných systémů, podobně jako byl v předchozím oddíle 2.4.3 uveden ERD jako standard pro modelování dat v relační databázi. Přestože variant modelovacích jazyků vzniklo několik, jako standard se nakonec prosadil jazyk UML (Unified Modeling Language), který společně vypracovali inženýři Jacobson, Booch a Rumbaugh. UML používá různé diagramy, které lze použít k pohledům na modelovaný systém. Následující přehled je zpracován s využitím (Schmuller, 2001) a (Fowler, 2004). V jazyce UML (ve verzi 1.4) je definováno těchto osm modelů: • Activity diagram – diagram činností • Class diagram – diagram tříd • Collaboration diagram – diagram spolupráce • Component diagram – diagram komponent • Deployment diagram – diagram nasazení • Sequence diagram – sekvenční diagram • State diagram – stavový diagram • Use case diagram – diagram případů užití Aktuální verze UML byla upravena následujícím způsobem: • Object diagram – diagram objektů a Package diagram – diagram balíčků; tyto diagramy byly často používány, ale nebyly oficiální součástí UML
2.5
Systém správy verzí (Verzovací systém)
23
• Collaboration diagram byl přejmenován na Communication diagram • Byly přidány tři další diagramy: Interaction overview diagram, Timing diagram a Composite structure diagram. Jak uvádí (Fowler, 2004), UML je možné využívat za třemi různými účely – pro tvorbu zjednodušených skic vybraných částí systému, pro kompletní návrh systému, a jako programovací jazyk při využití kompilérů modelů. Vzhledem k zvolenému implementačnímu jazyku a možným nástrojům pro něj, jazyk UML v rámci této práce postačoval pouze pro účely tvorby dokumentace. Byl rovněž využit při zhodnocení využitelnosti předchozího prototypu popsaného v rámci (Stránský, 2008), který UML modely hojně využívá.
2.5
Systém správy verzí (Verzovací systém)
Systém správy verzí je podle (Goodliffe, 2006, s. 351) základní nástroj pro vývoj software. Některá literatura, např. (Pressman, 2001, 225) verzovací systém zařazuje jako nástroj v rámci formálně obecněji chápaného procesu SCM (Source Configuration Management). Jiní se zaměřují na praktické výhody, který verzovací systém přináší, viz (Shore, Warden, 2008, 168) či (Richardson, Gwaltney, 2006, 19). Připustíme-li pohled na softwarový projekt jako sérii změn v jednotlivých softwarových artefaktech (specifikace, návrh, zdrojový kód, testy), verzovací systém pak umožňuje udržení kontroly nad těmito změnami. Správa verzí je systém, který zaznamenává změny souboru nebo sady souborů v průběhu času a uživatel tak může kdykoli obnovit jeho/jejich konkrétní verzi (tzv. verzování). Dalším velkým problémem, s nímž se uživatelé potýkají, je potřeba spolupráce s dalšími pracovníky týmu. Verzovací systém umožňuje vrátit jednotlivé soubory nebo celý projekt do předchozího stavu, porovnávat změny provedené v průběhu času, zjistit, kdo naposledy upravil něco, co nyní možná způsobuje problémy, kdo vložil jakou verzi a kdy a mnoho dalšího. (Chacon, 2009, s. 17) Jedním z prvních systémů správy verzí byl již v sedmdesátých letech SCCS (Source Code Control System), který využíval principu striktního zámykání nad jednotlivými soubory, aby umožnil úpravy daného zdrojového kódu vždy jen jedné osobě. Programátoři přitom pracovali na jednom počítači a sdíleli tak jeho souborový systém. Verzovací systém pak zajišťoval nejenom zamykání a odemykání souborů, ale i historii všech provedených změn. Místo, kde se uchovává veškerá historie projektu, se v terminologii verzovacích systémů označuje jako repozitář (repository). Repozitář může být implementován souborově, databázově či kombinací obojího. Koncem osmdesátých a v průběhu devadesátých let systémy správy verzí byly obohaceny o koncepty klient–server architektury a optimistického zamykání, kdy soubory ve skutečnosti nejsou zamykány, ale při změnách téhož souboru je prováděno slučování těchto změn (operace merge). Tyto verzovací systémy se označují jako centralizované. Logicky je pak repozitář cetralizovaných systémů organizovaný jako orientovaný graf jednotlivých revizí, tedy obsahů či jinými slovy stavů jednotlivých
2.5
Systém správy verzí (Verzovací systém)
24
souborů (CVS) a nebo všech souborů (SVN) v daný okamžik (po odeslání změn pomocí operace commit). Základní styl práce s centralizovaným verzovacím systémem je následující: jednotliví programátoři si zkopírují (operace checkout) zdrojové kódy z dané revize (při běžném vývoji jde obvykle o nejnovější revizi) do svého lokálního pracovního adresáře (workplace). V pracováním adresáři jsou v některém textovém editoru či integrovaném vývojovém prostředí prováděny požadované změny zdrojového kódu vyvíjené aplikace. Jakmile je úprava dokončena (určitý programátorský úkol), změněné soubory jsou odeslány zpět na server (operace nazývaná commit) do repozitáře. V některé, byť několikrát revidované, literatuře je možné stále nalézt tyto zastaralejší verzovací systémy jako vhodné nástroje – příkladem takového archaismu je tvrzení v (Welling, Thomson, 2009, s. 543), že projekty PHP a Apache jsou verzovány v centralizovaném systému CVS.
Obr. 5: Schéma centralizovaného verzovacího systému
Současným trendem v systémech správy verzí jsou pak distribuované systémy. V nich uživatelé systému nestahují pouze danou revizi souborů do lokálního pracovního adresáře, ale získavají díky operaci klonování (clone) kompletní kopii repozitáře, tedy i kompletní historií změn. Architektura takovýchto systémů je pak místo na principu klient–server založena na principu peer–to–peer, kdy operace commit odesílá změny do lokálního repozitáře a dále je nutné využívat operací push a pull pro synchronizaci změn mezi repozitáři. Výhody distribuovaných systémů správy verzí oproti centralizovaným systémům jsou zřejmé. Je možné plnohodnotně pracovat i bez síťového připojení k centrálnímu serveru. Kompletní historie je distribuovaná mezi více lidí a v průběhu vývoje pravidelně aktualizována, tudíž každá lokální kopie je svým způsobem zálohou projektu — neexistuje jedno kritickém místo13 . Tímto způsobem se zvyšuje stabilita celého systému, přestože obvykle existuje určitý hlavní, centrální repozitář, 13
SPOF — Single Point Of Failure
2.5
Systém správy verzí (Verzovací systém)
25
Obr. 6: Schéma distribuovaného verzovacího systému
který se považuje za „základní zdroj pravdy pro ostatníÿ a obvyklý cíl synchronizací. Jde však o způsob v používání systému, nikoliv základ architektury. Jelikož interně jsou distribuované systémy obvykle postaveny na práci se změnami v souborech (changeset) a nikoliv na udržování revizí těchto souborů, daleko snadněji se v těchto systémech provádí slučování změn (merge) a v důsledku je snazší paralelní vývoj ve větvích (branch). Projevuje se to i v tom, že oba hlavní představitelé distribuovaných systémů, Mercurial i Git, mají slučování a paralelní vývoj v dokumentaci v počátečních kapitolách, jako jednoduchou a základní záležitost. Naopak v SVN jako typickém centralizovaném systému postaveném na revizích, je vývoj ve větvích uváděn v kapitolách pro pokročilé.14 Jednoduché slučování změn a peer–to–peer architekturu je pak možné s úspěchem využít například v situaci, kdy na jednom úkolu pracuje více programátorů na více počítačích, nechtějí ale svými změnami ovlivňovat práci ostatních. Synchronizují svoji práci mezi sebou a až teprve po dokončení úkolu jsou změny souborů zaslány do hlavního repozitáře celého týmu. Bez ohledu na typ konkrétního verzovacího systému 15 , samotné používání jakéhokoli verzovacího systému je v současné době považováno za jeden ze základních nástrojů pro jakýkoliv softwarový projekt a to v jakkoli velkém týmu. I při programování aplikace jedním programátorem je velkou výhodou správa historie změn zdrojových kódů a izolování úkolů vývojem ve 14
A praxe se mu pro jeho potenciální komplikovanost díky náchylnosti ke konflitům často vyhýbá a nevyužívá se tak plně potenciál verzovacího systému. 15 Autor této práce má za to, že distribuované systémy postupně převládnou nad centralizovanými. Praktické používaní obou druhů přesvědčilo o výhodách prvního druhu.
2.5
Systém správy verzí (Verzovací systém)
26
větvích. Verzovací systém je pak prakticky nutnou podmínkou pro další praktiky, nejvíce pro kontinuální integraci (vytvoření otestované, spustitelné podoby software z nejnovější verze) a refactoring (úprava zdrojového kódu za účelem lepší čitelnosti a udržitelnosti, bez změny chování programu).
3
ANALÝZA SOUČASNÉHO STAVU
3 3.1
27
Analýza současného stavu První webové rozhraní
Hra „Výroba nábytkuÿ probíhala za doby studia autora této práce následujícím způsobem. Obvykle tříčlenné týmy, znázorňující vedení jednotlivých firem, obdržely na počátku cvičení v papírové podobě výsledky z předchozího kola. Na konci cvičení se odevzdávala rozhodnutí pro aktuální kolo, přičemž průběh cvičení byl věnován volné diskuzi v týmu a tvorbě samotného rozhodnutí. Vzhledem k tomu, že cvičení měla samozřejmě i jinou náplň, sehrávky hry byly prováděny každé druhé cvičení, tedy v četnosti jedenkrát za čtrnáct dnů. I ve velice jednoduchém ekonomickém modelu hry „Výroba nábytkuÿ skutečně trvala tvorba rozhodnutí necelé dvě hodiny. Velké množství času zabrala diskuze, místy až konflikty, v daném týmu o celkové strategii na další kola hry a tedy o podobě daného rozhodnutí. Učebna též nedisponovala počítači a tak oporou mozku studenta byla obvykle pouze kalkulačka, tužka a papír. Mnoho času tedy zabíralo i vypočítání podkladů pro různé varianty rozhodnutí. Rozhodnutí jednotlivých hráčských týmů byla odevzdávána v podobě vyplněného papírového formuláře a vedoucí hry je následně vyplňovali do tabulky v programu Excel. Tento excelovský soubor, odpovídající trhu, na kterém soupeřilo vždy pět firem, sloužil jako vstupní soubor pro celý systém vzájemně provázaných excelovských souborů. V něm dochází k výpočtům průběhu modelované firmy na trhu a též k vytvoření formulářů výsledků herního kola pro jednotlivé firmy. Hra jako metoda výuky autora této práce zaujala a chtěl se podílet na jejím vylepšení. Po dohodě s tvůrci hry autor této práce vytvořil primitivní webové rozhraní. Bylo využito faktu, že oba instruktoři hry znají základy jazyka HTML a PHP. Funkcionality webového rozhraní byly následující: Elektronický formulář pro zadání rozhodnutí hráčů. Rozhodnutí se ukládá do souboru ve formátu csv (comma–separated values), kdy v jednom souboru jsou uložena rozhodnutí všech firem v daném kole hry. V případě opakovaného zadání rozhodnutí (neúmyslného či naopak jako forma opravy) je jako platné bráno poslední zadané rozhodnutí. Zadávání rozhodnutí je chráněno heslem, ověřovaným pro danou firmu (neřeší se, kdo z týmu data zadal). Soubor je po uzavření rozhodovacího období vedoucím hry stažen přes protokol FTP a importován do vstupního souboru pro tvorbu výsledků trhu. Rozhraní pro prezentaci výsledků. Po dokončení zpracování výsledků trhu instruktor nahrává vytvořené excelovské soubory přes FTP zpět na server do určeného adresáře. Soubory musí dodržovat určený formát názvu (název firmy, podtržítko, číslo kola, přípona). Po zadání hesla je hráčům z dané firmy zobrazen seznam odkazů k stažení souborů s výsledky. Řízení toku běhu hry. Modifikací PHP konstant v konfiguračním souboru instruktor ovlivňuje jaké je aktuální kolo hry a stav tohoto kola (rozhodovací, tržní, výsledkové období).
3.1
První webové rozhraní
28
Elektronická nástěnka hry. Přímou editací určeného HTML souboru má instruktor možnost poskytovat informace hráčům. Jde především o organizační záležitosti, jako například informace o tom, kolik kol se bude hrát, termíny odevzdání rozhodnutí aj. Webové rozhraní bylo otestováno a po odladění nasazeno do produkčního prostředí Provozně ekonomické fakulty na serveru Dahlia. Pro přiblížení reálného vzhledu je ukázka webového rozhraní v příloze A), diagram nasazení celého systému pak viz obr. č. 7. Už první oficiální běh hry s využitím tohoto rozhraní ukázal na jeho přínosy, které byly následující: • Oddělení sehrávky hry od náplně cvičení — zadávání rozhodnutí i získávání výsledků již není nutné dělat fyzicky na cvičeních předmětu Strategický management. To je zcela zásadní změna: – Dříve byla hra hrána pouze na čtyři kola v sehrávkách jednou za čtrnáct dní. V tak malém počtu kol se však dobrá či špatná rozhodnutí hráčů nedokázala naplno projevit. S webovým rozhraním se počet kol mohl zdvojnásobit aniž by byla ovlivněna výuka na cvičeních. – Naopak později po celofakultní změně rozsahů výuky na PEF a v důsledku snížení počtu cvičení (nejen) v předmětu Strategický management, mohla zůstat manažerská hra nezměněna a dále sehrávána na osm kol. Pouze první a poslední cvičení je věnováno této hře, tedy úvodní vysvětlení a závěrečné zhodnocení výsledků. Hráči zadávají rozhodnutí mimo cvičení. – Hráči získali více času na dohodu a promyšlení rozhodnutí v týmu, neboť přestali být limitováni dobou cvičení. Jelikož pro zadání rozhodnutí i získání výsledků je nutné použít počítač, automaticky tím též získávají možnost využít dalších pomůcek, zejména tabulkového kalkulátoru; učebny, ve kterých obvykle cvičení probíhají, nejsou vybaveny počítači. • Zrušení nutnosti přepisování papírových formulářů — vyučujícím se nasazením tohoto webové rozhraní odstranila nepříjemná a časově náročná povinnost. • Snížení chybovosti — do papírového formuláře je možno vepsat i neplatné hodnoty či některé zapomenout. Při ručním přepisování je pak možné omylem zapsat jinou hodnotu, než hráči zadali. Díky základním kontrolám na elektronickém formuláři a odstranění nutnosti přepisu byla příčina těchto omylů odstraněna. Nadále je však možné, aby hráči zadali chybné rozhodnutí ve smyslu nevhodného pro hru. Některé neplatné vstupy kontrolovány nejsou, protože webové rozhraní nemá přístup k datům dané firmy — je tak například možné zadat prodej většího počtu strojů než firma vlastní. • Snížení tiskových nákladů na ústavu managementu — zcela zřejmý důsledek, díky nasazení webového rozhraní se ušetřilo velké množství papíru a tiskových náplní. Samozřejmě, toto webové rozhraní obsahuje mnoho nedokonalostí. Některé jsou zřejmé z popisu funkcionalit, například stále velké množství ruční práce vedoucích či
3.2
Možné alternativy řešení
29
přímá editace souboru na serveru. Další jsou skryté, protože jsou na úrovni zdrojového kódu tohoto webového rozhraní. Klasický PHP anti–vzor kombinování HTML prezentační logiky a PHP aplikační logiky v rámci jedné webové stránky znamená, že ve zdrojovém kódu se nyní obtížně orientuje i sám autor. Též ukládání hesel nelze považovat za bezpečné. Toto webové rozhraní přesto slouží v prakticky nezměněné podobě dodnes. Zcela zásadním problémem však stále zůstává rozdělení na webové rozhraní a výpočet výsledků v tabulkovém procesoru se všemi důsledky z toho vyplývajícími. Pouhé přepsání tohoto rozhraní do lepšího kódu (refactoring) nepostačuje a je proto nutné vytvořit zcela novou webovou aplikaci.
3.2
Možné alternativy řešení
Vzhledem k tvorbě vlastních pravidel hry jako výukové metody na Ústavu managementu jsou možnosti alternativ k vytváření nové aplikace omezené. Vytvořením vlastní výukové pomůcky nelze najít již existujicí řešení naprosto shodného problému. Jediné alternativy pak mohou být hledány pouze za předpokladu odmítnutí celé hry „Výroba nábytkuÿ jako takové a hledání jiného způsobu naplnění výukových cílů, dosahovaných sehrávkou této hry. Jednou z možností je využít „konkurenčníÿ hru, využívanou v rámci výuky na Masarykově univerzitě v Brně. Podrobnější popis je možné nalézt nejlépe v (Smutný 2007). Je též určena pro studenty vysoké školy, snaží se dosáhnout podobných cílů. Jde však o stejně interně používaný projekt jako samotná hra „Výroba nábytkuÿ. Existuje v ní jistý fundamentální rozdíl – hráči mají v rámci sehrávky přiděleny různé role (majitel firmy, podřízení, investoři, bankéř atd.), čímž získávají jednotliví studenti odlišné zkušenosti v rámci hry; největších výukových cílů tak může potenciálně dosáhnout student hrající roli majitele firmy, který má velké rozhodovací pravomoci. Pochopitelně existuje více podobných výukových pomůcek z dalších univerzit, bylo by ovšem nutné je přeložit do češtiny. Další možností je využití některého z komerčně prodávaných podobných produktů, sloužících v rámci vzdělávání studentů a managementu. Jako příklad lze uvést hru MikesBikes firmy Smartsims, což je výuková hra řízení firmy zabývající se výrobou kol s webovým rozhraním. Rozhodnutí o nahrazení celé hry není v kompetenci autora této práce a Ústav managementu o tomto kroku ostatně ani neuvažuje. Především však základní problém nejsou pravidla hry samotná, ale časová náročnost samotné sehrávky hry. Lze tedy prohlásit, že tento problém nemá přímo dostupné jiné alternativy řešení než tvorbu nové webové aplikace.
3.2
Možné alternativy řešení
Obr. 7: Diagram nasazení pro první webové rozhraní hry Výroba nábytku
30
4
POUŽITÉ TECHNOLOGIE A METODIKY PRO IMPLEMENTACI
4
31
Použité technologie a metodiky pro implementaci
4.1
Programovací jazyk, databáze
Jako implementační jazyk byl autorem této práce zvolen PHP, především z důvodů jeho větší znalosti než v případě jazyků Python či Ruby. Java naopak byla přímo zamítnuta z důvodů větší náročnosti na zdroje, její použití v tomto projektu by nepřinášelo žádnou zjevnou výhodu a naopak by mohly vznikat komplikace spojené s nasazením a administrací aplikace na univerzitních serverech. Vyšší hardwarová náročnost by se negativně promítla též ve vývoji samotném, ve vyšších nárocích na hardware vývojového (osobní PC) a testového prostředí (webhosting). PHP je skriptovací jazyk, nasazený na straně serveru, a vytvořený za účelem dynamických webových stránek. Vznikl v roce 1994 a zpočátku se používal ve stylu popisovaném v úvodu knihy (Welling, Thomson, 2009); PHP kód se zapisoval do HTML stránek a byl spouštěn při každém načtení stránky. V současnosti se spíše preferuje postup opačný; píše se obvykle čistě PHP aplikace, která na daný požadavek (protokolu HTTP/HTTPS) generuje určitý výstup ve formě HTML stránek. Aktuální hlavní verze jazyka je 5.3 a je stále intenzivně vyvíjen, jde o open–source projekt. Jeho domovská stránka je pak www.php.net. Jako databázový systém byl autorem této práce zvolen MySQL, opět z důvodů větších osobních zkušeností s tímto systémem; nicméně stejně dobře by na jeho místě mohl být i systém PostgreSQL a v případě nasazení na PEF i komerční systém Oracle. Jak ostatně podotýká (Vrána, 2010, s.227), je vhodné používat ten databázový systém, který nejlépe ovládáme, pro který máme dobrou podporu (což vyloučilo komerční Oracle při vývoji aplikace na osobním počítači autora této práce) a který dokážeme spravovat. Volbou vhodné knihovny pro databázovou abstrakci (byla použita knihovna Dibi) je možné napsat aplikační kód, který půjde jednodušeji převést na jiný typ databázového úložiště. Zatímco přepsání této aplikace do jiného jazyka nepřináší zjevné přínosy, po praktických zkušenostech z vývoje si autor této práce dovede představit přechod z MySQL na PostgreSQL. MySQL totiž doposud chybí některé základní prostředky pro integritu dat, za všechny je možné uvést CHECK constraint pro definování omezení na úrovni sloupce. Je tedy nutno takovouto jednoduchou kontrolu řešit buď na úrovni aplikační logiky a nebo triggerem. Též je obtížnější pro tento databázový systém psát uložené procedury a triggery, zcela nemožné je pak definování vlastní chyby v rámci uložených procedur16 . Vytvářená aplikace je tak na tento hypotetický krok připravena. 16
Obvyklým postupem pro vytvoření vlastní chybové hlášky je vyvolání standardní chyby DUPLICATE ENTRY snahou o vložení do tabulky obsahující vlastní chybové kódy a text chyby, druhým běžně používaným postupem je snaha o získaní dat, tedy onen text chyby, z neexistující tabulky.
4.2
Vybrané PHP frameworky pro tvorbu webových aplikací
4.2
32
Vybrané PHP frameworky pro tvorbu webových aplikací
Pro PHP existuje velké množství knihoven i frameworků pro webové aplikace. V následujícím seznamu jsou uvedeny ty nejznámější. Liší se mezi sebou stářím, velikostí, množstvím funkcionalit, které pokrývají, i kvalitou dokumentace. Kromě frameworků uvedených v následujícím seznamu samozřejmě existuje celá řada méně známých, či dokonce vůbec nevydaných. Pro úplnost je vhodné uvést možnost využití jako základu vlastní webové aplikace některý z komplexnějších CMS17 , například Drupal, který se doplní vytvořením vlastních modulů pokrývajících požadované specifické úkoly. Seznam frameworků pro tvorbu webových aplikací v jazyce PHP: • Achievo ATK • Agavi • Agile Toolkit • Alloy • Akelos • Banshee • Casco • CakePHP • CodeIgniter • Doophp • Fat-Free • Horde • Jelix • Kajona • Kohana • Limonade • Lithium • NanoMVC • Nette • Prado • Rainframework • Qcodo • Seagull • Solar • Symfony • ThinPHP • Yii • Zend Framework • Zeta Components 17
Content management system — systémy pro správu obsahu
4.2
Vybrané PHP frameworky pro tvorbu webových aplikací
33
Výběr frameworku byl proveden praktickou zkouškou, snahou vytvořit jednoduchý prototyp budoucí vytvářené aplikace. Malý prototyp vždy tvořil formulář ukládající zadání do databáze, přičemž prototypová aplikace byla rozdělena do dvou chráněných sekcí — uživatelé s rolí „hráčÿ mohou zadat data formulářem, uživatelé s rolí „instruktorÿ mohou data zobrazit a editovat jednu položku z formuláře. Nebyl samozřejmě vyvářen prototyp pro každý z výše uvedených frameworků, ze seznamu byly vyřazeny frameworky určené pro malé, jednoduché stránky (např. Limonade). Dále byly ze seznamu již předem vyřazeny frameworky se zbytečně složitým způsobem konfigurace a tvorby základních prvků aplikace, či frameworky vynucující určitý styl práce s databází (používající povinně určité či dokonce vlastní ORM18 a obvykle s návrhovým vzorem Active Record). Pro tvorbu aplikace byl nakonec zvolen framework Nette. Oproti frameworkům Lithium či Kohana, které též vyhovovaly osobním požadavkům autora práce, mají především výhodu českého tvůrce a silné české komunity. Jak je z výše uvedeného seznamu zřejmé, je z čeho vybírat, přičemž situace se navíc průběžně mění.19 . Jako kritérium výběru byla tedy uvažována i snadnost, s jakou je možné se daný framework naučit, to v situaci kdy vytvářenou aplikaci bude udržovat a doplňovat o další funkcionalitu někdo jiný. 4.2.1
Nette framework
Nette framework Davida Grudla20 má ve verzi 0.9.6, která byla použita21 , velikost zhruba 700 kB, s obvyklým doplněním o knihovnu Dibi pro databázovou abstrakci od stejného autora se velikost zvýší o dalších 250 kB. To je dle názoru autora této práce velikost frameworku dostatečná na pokrytí i komplexních záležitostí, nicméně ne natolik velká, aby svou velikostí komplikovala vývoj nutností prostudovat značné množství podrobností.22 Nejužitečnější vlastnosti Nette frameworku (z pohledu autora této práce) jsou následující: • MVC, resp. MVP architektura frameworku, což jak podotýká (Vrána, 2010, s. 156) jasně odděluje tři relativně samostatné části webové aplikace: Model (aplikační logika, komunikace s uložišti dat, např. databází), View (prezentace dat uživateli, obvykle použitím šablonovacího systému) a Controller, resp. Presenter (zpracování požadavku, pomocí informování daného modelu a vybrání vhodného způsobu odpovědi, tedy předání výsledných dat určitému View). • Vlastní autoloader (třída RobotLoader), umožňující při vývoji ignorovat nutnost psaní PHP příkazu require once a výrazně zjednodušující budoucí re18
Object–relational mapping Například další velmi zajímavý framework Fuel v seznamu není uveden, protože byl uveřejněn později, v době sepisování této práce, nikoliv v době, kdy se autor o frameworku rozhodoval. 20 URL projektu: http://nette.org 21 Verze z podzimu 2010, aktuální stabilní verze je nedávno vydaná 2.0.3, po marketingovém přeskočení verze 1.0 stable 22 Což je například situace jazyka Java a frameworku Spring. 19
4.2
•
•
•
•
•
Vybrané PHP frameworky pro tvorbu webových aplikací
34
factoring (změna názvu třídy, změna umístění třídy v adresářové struktuře). Bonusem používání RobotLoaderu je detekce konfliktů názvů tříd. Podpora ladění, konkrétně třída Debug (efektivně nahrazující php funkci var dump) a základní třída Object (napravující nekonzistence generování chyb v PHP). Ladění též probíhá v závislosti na daném prostředí podle nastavení v konfiguračním souboru plus možnost autodetekce prostředí. Zatímco ve vývojovém prostředí zachycená chyba (ve smyslu direktivy php error reporting) generuje výpis detailů chyby s vylepšenou vizualizací detaiů chyby či výjimky i se stavem zásobníku (call stack), na produkčním serveru je tento výpis pochopitelně potlačen a vzniklá chyba zalogována do souboru (a navíc je odeslán mail o vzniku chyby). Třída Debug je natolik užitečná, že je často používána pro ladění aplikací tvořených i s využitím jiného frameworku než Nette, což poukazuje na dobrý modulární design tohoto frameworku. Zjednodušení práce s formuláři (třída Forms); jak jejich definice tak nastavení pravidel validací. Definicí pravidel nad danými prvky formuláře třída Forms generuje samotný validační kód, fungují s podporou Javascriptu i bez jeho podpory. Latte filter pro zápis šablon, řešící i kontextově senzitivní escapování (rozdíly v HTML, CSS, PHP a Javascriptu). Existence tzv. „blokůÿ a možnost jejich dědičnosti snižuje nutnost zbytečného opakování kódu na prezentační vrstvě. Vnitřní nezávislost vazeb mezi stránkami na konkrétních URL; vnitřní odkazy se tvoří s využitím příkazů link a plink (v šablonách), resp. $presenter->link() přímo v kódu presenteru. Odkaz směřuje v důsledku na konkrétní akci, která je reprezentována v nejjednodušší variantě pouze šablonou pro generování výsledné HTML stránky, případně jde o metody konkrétního presenteru (případně ještě v daném modulu). Odkazy je možné generovat jak relativně, tak absolutně, např. odkaz uvedený v šabloně Zobrazit seznam článků je absolutním odkazem na metodu actionShowAll() (případně pouze šablonu showAll.phtml při neexistenci presenteru) ve třídě ArticleListPresenter zařazené v modulu Admin. Akce a pohledy (šablony výsledných stránek) jsou od sebe též odděleny. V presenteru tak může být definována jedna akce, zatímco výsledných pohledů může být více a je vybrán dle aplikační logiky. Pod jednou akcí (a shodnou URL) se tedy v důsledku mohou vykreslit i diametrálně odlišné stránky například v závislosti na nějakém parametru či vnitřním stavu aplikace. Routování URL – díky způsobu vnitřního odkazování popsaném v předchozím bodě je aplikace vnitřně stále provázaná bez ohledu na možné změny tvaru URL pomocí změny nastavení routování adres. V jiných systémech má routování obrovských význam. Naopak v Nette se tvar URL (např. při snaze o SEO) může řešit dokonce i až je aplikace kompletně hotová. Navíc není problém kdykoliv úplně změnit veškeré cesty pouze přepsáním rout – je tomu tak, protože routování je obousměrné, slouží jak k parsování, tak ke generování cest. Není třeba
4.2
•
•
•
•
Vybrané PHP frameworky pro tvorbu webových aplikací
35
tedy zasahovat do aplikace, pokud v rámci například SEO optimalizace chceme vytvořit jinou podobu URL. Komponentový model vizuálních i nevizuálních komponent (inspirace z jazyku Delphi), podporující znovupoužitelnost kódu. Nette též základní architekturu MVC rozšiřuje možností definování tzv. „modulůÿ, tedy částí aplikace, které mají určitý význam samy o sobě a mohou být použity například v podobné aplikaci (vyšší úroveň znovupoužitelnosti než komponenta, která je v rámci určité stránky, resp. presenteru). Moduly, kromě znovupoužitelnosti, pak též mohou sloužit k určitému vnitřnímu oddělení částí aplikace, které jsou určeny pro různé použití. Bezpečnost vytvářené aplikace; podpora ochrany proti následujícím druhům útoků: XSS, CSRF, URL attack, control codes, invalid UTF-8, session hijacking, session stealing, session fixation. V kombinaci s knihovnou pro databázovou abstrakci Dibi je pak aplikace dostatečně zabezpečena i proti útoku typu SQL Injection. Podpůrné třídy zjednodušující práci pro obvyklé úkoly okolo webových aplikací; práce s e-maily (třída Mail), zjednodušení práce se session (třída Session), atomické operace nad soubory (třída SafeStream) a další. Silná česká komunita okolo frameworku, podporující další vývoj framewerku kromě samotného autora a poskytující výměnu zkušeností. V rámci komunity bylo vytvořeno velké množství znovupoužitelných komponent či například plugin podpory tohoto frameworku pro integrované vývojové prostředí Netbeans. Jsou též pořádána pravidelná měsíční setkávání uživatelů frameworku.
Po praktickém používání při vývoji je však na místě doplnit i některé pozorované, tedy ve své podstatě subjektivní, nedostatky tohoto frameworku. • Časté zpětně nekompatibilní zásahy. Framework značně ulehčuje vytvoření nové aplikace i její další údržbu, ale autor frameworku podle autora této práce až příliš často zavádí při dalším vývoji frameworku zpětně nekompatibilní zásahy do kódu, což je při poměrně živém vývoji celého frameworku zásadní problém. Je to jeden z důvodů, proč vytvářená aplikace se stále drží verze frameworku 0.9.6 – aktualizace na novou verzi 2 je zásadní refactoring, který koncovému uživateli aplikace nepřináší žádnou přímou přidanou hodnotu. • Validátory nejsou definovány na úrovni modelu. Nette má dobrý systém pro generování validačních pravidel pro kontrolu vstupu. Jeho slabinou však je, že je velmi těsně svázaný s třídou Form, tedy s výsledným HTML formulářem. Jednoduchým zapsáním pravidel na vstup je provedeno ošetření na chybné hodnoty jak na straně klienta (generovaný javascript) tak na straně serveru. Bohužel tím, že se pravidla definují na úrovni určitého formuláře je prakticky nemožné přesunout validaci na úroveň modelu (v MVC) a použít tak stejnou sadu pravidel bez ohledu na způsob vstupu. Například vložení jednoho záznamu v rámci HTML formuláře a dávkové přidání stejného typu záznamu v rámci importu csv souboru, spouštěného třeba v určený čas pomocí cronu a php přes příkazovou
4.3
Podpůrné nástroje pro kvalitu PHP projektů
36
řádku (php cli). V takové situaci musíme validační logiku duplikovat, přestože chceme kontrolovat, zda stejný typ záznamu splňuje stejnou sadu pravidel. • Dokumentace. V současné době je již situace znatelně lepší než zhruba před třemi lety, kdy dokumentace teprve začala vznikat. Nelze ji však stále srovnávat s úrovní vyzrálejších frameworků, jako například Zend a Symphony. Dokumentace je též především v českém jazyce, anglická zaostává a efektivně tak brání úspěšnému rozšíření frameworku dál než mezi české a slovenské programátory. Též dosud nevznikla žádná literatura pokrývající tento framework, ideálně přímo v anglickém vydání. • Antivzory „Feature creep.ÿ a „Reinvent the wheelÿ. Mezi verzí frameworku 2.0.3 a verzí 0.9.6 je znatelný rozdíl i mezi funkcionalitami. Jako příklad lze uvést změnu způsobu zápisu konfigurace aplikace ze známého a standardního ini formátu do nového typu formátu neon (upravený JSON). Tím se plynule dostáváme k druhému popsanému problému, kdy častým způsobem řešení některého z problémů není využití existujícího řešení, ale napsání vlastního. V některých případech to nevadí, v jiných jde dokonce o přínos. Nevyhnutelně však ignorování běžně používaných a zavedených postupů je někdy na škodu a komplikuje tvorbu PHP aplikace nad Nette při snaze využití existujících podpůrných nástojů, popsaných například v knize (Mitchell, Shafik, Turland 2011). Například v době zahájení implementace frameworku Nette dávno existovala stabilní třetí verze frameworku pro psaní automatických testů PHPUnit23 , nicméně autor Nette napsal testy v rámci vlastního kódu. To znamená, že až teprve komunita byla nucena řešit problémy vzniklé z ignorování ve firmách nejčastěji používaného nástroje na automatizované testování.
4.3
Podpůrné nástroje pro kvalitu PHP projektů
Zde budou shrnuty další užitečné nástroje podporující vývoj aplikací v PHP. Některé z nich jsou zmiňovány v (Mitchell, Shafik, Turland 2011), jiné ne, ačkoliv též řeší v této knize popisované problémy. Ne všechny se autorovi této práce podařilo využívat úspěšně, ať pro problémy s konfigurací v rámci autorem používaného operačního systému nebo ve vztahu s použitým frameworkem Nette (problém jiné než standardní PHP syntaxe), nicméně budou zmíněny pro jejich důležitost podpory výsledné kvality php projektů. Veškeré následující nástroje mají CLI interface, jsou tedy vhodné pro zařazení pod server kontinuální integrace. • PHPLoc – nástroj na utvoření si základního přehledu o komplexnosti (obvykle neznámého) projektu, případně jako nástroj dávající určitou představu o hlavních změnách v kódu mezi verzemi programu. • PHPUnit, obvykle rozšířená pomocí knihovny hamcrest-php. Framework primárně pro jednotkové testy (testy tříd), ale může pokrývat i potřeby integračního (testování databáze pomocí rozšíření DBUnit) a funkcionálního/akceptač23
viz www.phpunit.de
4.3
• •
• • • • •
•
•
•
•
Podpůrné nástroje pro kvalitu PHP projektů
37
ního testování (doplněk pro konekci k SeleniumRC). PHP CodeCoverage pak v kombinaci s nástroji PHPUnit a XDebug poskytuje informace o pokrytí kódu testy. Alternativní framework pro jednotkové testy je SimpleTest, PHPUnit je však de facto standard. Mutagenesis – nástroj pro možnost mutačního testování, tedy kontroly kvality samotných testů. Závisí na upraveném nástroji runkit. Behat, popř. PHPSpec – nástroj pro psaní testů ve stylu BDD (Behaviour Driven Developement), inspirující se v nástroji Cucombor z platformy Ruby. Ideální použití je jako nadstavba PHPUnit pro zápis testů vyšší úrovně (akceptačních). Zápis testů v podobě BDD stylu umožňuje vytvořit snadno popis testů pochopitelný i člověkem bez vzdělání v informačních technologiích a je tak možný pohled na akceptační testy jako na „spustitelnou specifikaciÿ. Xdebug – debugger, profiler i nástroj pro dynamickou analýzu php kódu. Druhý často používaný profiler pro PHP je xhprof. Mockery a nebo Phake, vhodné v případě, že podpora tvorby tzv. „mock objektůÿ v PHPUnit z jakéhokoliv důvodu nevyhovuje. phpRack – nástroj pro ověření správnosti nastavení produkčního prostředí a dostupnosti požadovaných služeb. PHP Depend – přehled o metrikách kódu, zejména z pohledu návrhu. PHP PMD – velmi dobře se doplňuje s PHP Depend, je ostatně na něm závislý. Zatímco ten dává přehledné a podrobné informace o metrikách, PHP PMD slouží pro kontrolu kódu proti definovaným pravidlům (např. délka názvů metod, tříd), s využitím některých těchto metrik. Padawan, PHP-sat, phantm, spikePHP – nástroje podléhající aktuálnímu vývoji s různým stavem dokončení a různými dalšími závislostmi. Účelem těchto nástrojů je nalézání možných chyb, bezpečnostních problémů a „antivzorůÿ. Vhodné spíše pro čistě php kód, menší použitelnost v aplikacích postavených nad frameworkem typu Nette. PHP CodeSniffer – též nástroj na statickou analýzu kódu, základní použití je kontrola jednoty stylu psaní kódu. Prochází nejenom PHP kód, ale je možno kontrolovat i CSS a Javascript. Existuje obecný PEAR standard, popsané jednotné standardy podoby kódu pak mají frameworky Zend, Symfony a Kohana. Na standardu frameworku Nette vytvořeném pro tento nástroj se aktuálně pracuje. Kromě kontroly jednoty stylu kódu je možné kontrolovat opět i výskyt možných chyb či potenciálních problémů výkonnosti. Další projekt podobného zaměření je PHPCheckstyle. phpcpd – vyhledává duplicity v php kódu, tedy potenciální místa pro refactoring. Opakování kódu je v drtivé většině případů špatným postupem komplikujícím budoucí údržbu (princip DRY - Don´t Repeat Yourself). phpCallGraph — generuje graf volání php kódu pomocí statické analýzy kódu. Xdebug je nicméně v této oblasti silnějším nástrojem, protože umožňuje zachytit dynamickou analýzou kódu veškerá volaní metod a funkcí (tzv. „function tracesÿ).
4.4
Selenium
38
• pfff – je celý balíček nástrojů pro statickou i dynamickou analýzu kódu a jeho vizualizaci. • PHP CodeBrowser je nástroj pro zobrazení php kódu se zvýrazněním syntaxe a s podporou vizualizace některých z výše uvedených nástrojů (PHPUnit, PHP CodeSniffer). Jeho použití je cíleno na nasazení v rámci kontinuální integrace. • PHPDocumentor, Docblox, Apigen, PHP UML (použitím výstupního formátu html a htmlnew), Doxygen - nástroje pro tvorbu programátorské dokumentace z kódu. Klíčové pro software, který používají další programátoři, tj. knihovny a frameworky, nicméně zápis dokumentačních komentářů je výhodný i pro aplikační třídy díky podpoře jejich zobrazení v moderních IDE v rámci daného kontextu (třídy, metody, atributu). • HipHop – je nástroj vyvinutý firmou Facebook pro převod php kódu do jazyka C++ a jeho následnou kompilaci, čímž je možné docílit vyššího výkonu po nasazení na server. Je možné ho též použít jako další z nástrojů statické analýzy kódu. • Phing – build systém pro php, reimplementace nástroje Ant pro Javu, často se však v PHP projektech používá i přímo Ant; to je velmi výhodné, je-li použit v Javě napsaný server pro kontinuální integraci (např. CruiseControl nebo Jenkins. Proces sestavení (build) je v případě PHP daleko jednodušší než například u projektu v jazyce Java, praktické použití bývá především v spouštění výše uvedených nástrojů pro testování a statickou či dynamickou analýzu kódu, společně s nahráním projektu do daného prostředí (vývojářské, testovací, produkční) včetně všech nezbytných kroků při nastavení aplikace na serveru (nastavení a migrace databáze, naplnění potřebnými daty aj.)
4.4
Selenium
Tento nástroj není spojen s jazykem PHP a naopak jde o nástroj akceptačního testování (viz oddíl 2.3) obecné webové aplikace, tedy napsané v jakémkoliv konkrétním implementačním jazyce. Selenium24 je open–source nástroj pro automatické testování, fungující na principu přímé kontroly webového prohlížeče a tedy provádění akcí co nejblíže reálnému provádění lidským uživatelem. Tím je možné kontrolovat nejenom správnou funkčnost webové aplikace jako takové, ale i například testování funkčnosti webové aplikace v různých prohlížečích, resp. v různých verzích stejného prohlížeče. Selenium je možné používat dvěma základními způsoby: • SeleniumIDE. Jde o doplněk (plugin) pro prohlížeč Firefox, který umožňuje nahrát chování uživatele v prohlížeči jako makro a přehrát seznam kroků i verifikaci výsledků. Jde o nástroj automatického testování typu „record&playÿ. 24
Url projektu: seleniumhg.org
4.5
IDE
39
Výhodou tohoto typu nástroje je jednoduchost a rychlost vytvoření testů, na úkor snadnosti následné udržby – po změně aplikace nesouvisející s testovanou funkčností (například v stromu navigace, id HTML elementů ) je většinou nutné vytvořit všechny náhle nefungující testy novým záznamem, neboť nahraná makra mají omezené možnosti znovupoužitelnosti kódu. Je též obtížnější nasazení testů v rámci nástrojů kontinuální integrace25 a výsledné reporty. Testové skripty jsou zapsány ve formě HTML tabulky s příkazy. Ukázka nástroje viz. obrázek č. 8. • SeleniumRC, neboli Selenium Remote Control. Jde o nástroj na principu klient– server, napsaný v jazyce Java, který dokáže spustit a ovládat webový prohlížeč, přičemž se očekává, že existuje test napsaný v kterémkoliv podporovaném jazyce. Testy je možné napsat v Javě, PHP, Ruby, Perlu (bez ohledu na jazyk testované aplikace) a i další programovací jazyky mají obvykle nějaký nástroj pro možnost integrace se SeleniumRC. SeleniumIDE pak má možnost exportu využívané HTML tabulky pro popis makra do výše uvedených jazyků a tak možnost zjednodušení migrace již existující sady testů. Protože pro všechny výše uvedené programovací jazyky existují hojně používané frameworky pro psaní testů a je možné psát znovupoužitelný kód, jde o ideální nástroj ve větším projektu či týmu. Selenium je díky své široké podpoře programovacích jazyků a prohlížečů velmi často využívaný nástroj pro automatické testy. Určitými alternativami k tomuto nástroji jsou pak například open–source projekty Canoo Webtest, HTMLUnit či komerční nástroj TestComplete firmy SmartBear.
4.5
IDE
Vynecháme-li komerční integrovaná vývojová prostředí (Zend studio, PHPStorm), pro tvorbu webových aplikací – tedy i podporou HTML, CSS a Javascriptu – v jazyce PHP je v současné době výběr poměrně jednoduchý. Hlavními tahouny jsou open– source IDE Eclipse a Netbeans. Obě IDE jsou napsány v jazyce Java a tak není problém je zprovoznit na prakticky jakémkoliv operačním systému. Obě jsou též primárně určeny pro vývoj v Javě, podpora pro PHP i další dynamické jazyky (Ruby, Python aj.) byla implementována později a tak oproti ní jsou podporované funkce menší (např. možnosti refactoringu; zde pochopitelně excelují komerční produkty). Ovšem výhodou kteréhokoliv z obou systému je množství již existujících rozšíření, a tak není problém podpořit „základníÿ funkce IDE stovkami dalších rozšíření26 . Přestože volba daného IDE je vděčným zdrojem rivality mezi programátory, pro autora této práce byla volba Netbeans jednoduchá, především díky existencí doplňku 25
Nicméně například hojně využívaný open–source CI server Jenkins má doplněk SeleniumAES umožňující spouštění těchto maker. Největší obtíž je skutečně horší udržba velkého počtu takto zapsaných testů 26 Netbeans má aktuálně 684 pluginů, viz http://plugins.netbeans.org/
4.6
Zvolená metodika vývoje
40
Obr. 8: Nástroj SeleniumIDE, převzato ze seleniumhg.org
vytvořeného komunitou pro podporu vývoje s Nette frameworkem27 . Netbeans též velmi dobře zvládá podporu pro autora této práce dvou nejdůležitějších nástrojů pro vývoj s IDE — testovací framework PHPUnit a verzovací systém Mercurial — a tak nebylo důvodu jej nevyužívat. Naopak Eclipse má velkou výhodu v doplňku Mylyn pro přímou konektivitu IDE do nástrojů pro správu požadavků (Bugzilla, Mantis, JIRA aj.), jehož ekvivalent pro Netbeans (CubeOn) nemá zatím takovou úroveň. V některých situacích nicméně bylo výhodnější použít prostého textového editoru se zvýrazňovačem syntaxe, to pro pomalé automatické kontroly validity v Netbeans IDE u velkého otevřeného souboru na autorově v dnešní době slabém PC. Typickým problémovým souborem byla stránka Simple Kanban (evidence úkolů a jejich stavu, HTML+CSS+Javascript), zde byly používány pro úpravu seznamu úkolů jednoduché textové editory jako gedit či Notepad++.
4.6
Zvolená metodika vývoje
Vzhledem k tomu, že autor této práce aplikaci vytvářel sám a jako „stakeholdersÿ, tedy zadavatelé a budoucí uživatelé, byli především dva lidé (doc. Ing. Pavel Žufan, Ph.D. a Ing. Tomáš Pyšný, Ph.D.), bylo možné používat celkem jednoduchý styl vývoje. Nebylo například nutné přímo koordinovat práci několika lidí současně v rámci vývojového týmu, k čemuž ostatně veškeré metodiky vývoje slouží především. 27
Základ v tomto projektu tvořil agilní přístup metodik Kanban a Extrémního programování pro jejich cílení na jednoduchost a účelnost v rámci implementace — ovšem na druhou stranu se autor snažil nezapomenout na celkový pohled problematiky tvorby softwaru, který poskytuje Unified Process i v jeho agilní variantě. Bylo nutné v rámci vývoje střídat určité role v rámci kroku dané iterace, což v důsledku více pomáhalo se soustředit na konkrétní činnost: plánování a jednání se „zákazníkyÿ, kódování, testování, dokumentování, nasazení verze na konci iterace. Čtyři fáze projektu podle metodiky Unified process pak autorovi pomáhaly nezapomenout na existenci závěrečné fáze Předávání a následnou údržbu aplikace — pravidelná refaktorizace, zápis poznámek k úpravám existující dokumentace pro hráče a psaní dokumentačních komentářů v kódu pro snažší orientaci po delším časovém odstupu jsou příklady činností, které je nutné dělat bez ohledu na zvolenou metodologii. Nejzákladnější prvky autorova osobního procesu vývoje však byly následující dva: • Plánování na čtrnáctidenní iterační cykly. Informování zadavatele o postupu na konci každé iterace a osobní schůzka s prezentací ne později než tři iterace od poslední prezentace, na začátku projektu pochopitelně častěji. • Izolování úkolů vývojem v paralelních větvích. Není-li daný úkol dokončen do termínu nasazení verze na konci iterace, zůstává v samostatné větvi a integrace tohoto kódu se přesouvá do iterace následující. Pro tento styl práce je velkou oporou verzovací systém umožňující ničím nerušený vývoj v paraleleních větvích. Pro autora této práce se jím stal Mercurial (Hg). Patří rovněž mezi distribuované verzovací systémy a využívají ho například projekty Mozilla Firefox, Netbeans IDE či jazyk Python.28 Většina implementace je napsána v jazyce Python, implementace binárního diffu je pak napsána v C. Vydání první verze též v roce 2005. Multiplatformní povaha implementačního jazyka znamená snadné používání tohoto verzovacího systému ve všech hlavních operačních systémech (Windows, Linux, Mac), jednoduchost i jednotlivé příkazy jsou pak velmi podobné svn, což umožňuje snazší přechod (je možné se lépe soustředit na zásadní rozdíly mezi centralizovaným a distribuovaným systémem). Grafická nadstavba TortoiseHG pak umožňuje snadné používání mimo příkazovou řádku, je však možné ho využívat ve všech nejznámějších integrovaných vývojových prostředích. Mercurial a Git, v součastnosti nejpopulárnější distribuované verzovací systémy, se vzájemně ovliňují ve svém vývoji, např. Git převzal z Mercurialu možnost vytvoření tzv bundle (soubor obsahující dané changesety, který je možné přenášet mimo protokol verzovacího systému), naopak Mercurial se inspiroval dvoufázovým commitem Gitu a je tak nyní možné i v Mercurialu v commitu vybrat jen určité změny na daném souboru, a nikoliv zaslat všechny změny v situaci, kdy spolu nesouvisejí ale byly provedeny současně. Volba mezi systémem Git a Mercurial je tak spíše otázkou osobních preferencí s ohledem na integraci s dalšími používanými nástroji. Osobně autorovi této práce 28
URL projektu: http://mercurial.selenic.com
4.6
Zvolená metodika vývoje
42
více vyhovuje přímočaře orientovaný přístup Mercurialu.29 Praktickou ukázku tohoto verzovacího systému viz obr č. 9. Velkým inspirativním zdrojem pak byl styl vývoje pro distribuované verzovací systémy Vincenta Driessena (uvedený na jeho blogu, který je však natolik úspěšný, že se velmi rychle rozšířil bez ohledu na konkrétní používaný verzovací systém), jehož diagram je v příloze G.
Obr. 9: Pohled na Hg repozitář vyvíjené aplikace s využitím programu TortoiseHg
Pro plánování i záznam o postupu pak byla využívána metodika kanban za pomoci nástroje Simple Kanban30 . Jedná se o jednoduchou HTML stránku s Ja29
Jak vytvářené aplikace, tak samozřejmě i zdrojových textů této práce pro sazební systém LATEX. 30 URL projektu: http://www.simple-kanban.com
4.6
Zvolená metodika vývoje
43
vascriptovou vizualizací seznamu úkolů a jejich stavů, viz obr. č. 10. Úkol evidovaný v kanbanu přitom mohl být i požadavek či chyba zaznamenaná v nástroji na evidenci chyb (byl použit nástroj Mantis). Za výhodu je možné považovat, že stav úkolů bylo možné nahrát na webový server společně s aktuální verzí aplikace ke shlédnutí vedoucím práce, a přitom neoddělovat záznam o postupu prací od práce samotné (změn v kódu) díky verzování tohoto jednoho souboru. Změny stavů úkolů a jejich dokončení tak bylo možné adekvátně sledovat i při paralelním vývoji ve větvích (viz příloha G).
Obr. 10: Ukázka použítí nástroje Simple Kanban
V týmu o větším množství zainteresovaných lidí by bylo nutné použít komplexnější webovou aplikaci pro projektové řízení. V ideálním případě by měl slučovat plánování projektu v duchu agilních metodik, evidenci požadavků (nových vlastností i chyb), projektovou nástěnku (ideálně jako wiki) a být schopen se integrovat s dalšími nástroji, především verzovacím systémem. Mezi open–source software s těmito vlastnostmi patří například Trac (Python), Agilefant (Java), Redmine (Ruby), nebo The Bug Genie (PHP), přičemž autor této práce by volil mezi posledními uvedenými. Díky intenzivní a přímočaré komunikaci nebylo nutné takový nástroj zavést. Pro podporu budoucího nasazení aplikace byla instalována v rámci testového pro-
4.6
Zvolená metodika vývoje
44
středí alespoň aplikace pro evidenci chyb (bugtracker) Mantis; ten sice byl dosud používán velmi sporadicky, po ostrém nasazení však lze očekávat odlišnou situaci. Nebylo zapomenuto ani na testování aplikace. V průběhu každé iterace autor práce střídal roli programátora a testera. Vždy tři dny v rámci čtrnáctidenní iterace byly rezervovány na manuální testování aplikace. Chyby byly zaznamenávány jako další úkoly v nástroji SimpleKanban a známé chyby byly součástí seznamu změn v dané verzi, předávaného vedoucímu práce. Většina testování na konci iterace byla provedena manuálně, ať už ověření, zda aktuálně dokončená funkcionalita splňuje požadavky, či naopak hledání možných chyb či přímo snaha o úmyslné zneužití aplikace (např. pomocí neplatných vstupů, editací URL, manipulací s daty formuláře ve formě HTTP POST požadavku atd.). Byly napsány i automatické testy ověřující klíčovou funkcionalitu tvorby výpočtů, za pomoci frameworku PHPUnit. V tomto konkrétním případě byla využita metoda vývoje TDD, tedy zapsat nejdříve test a pak teprve vlastní implementaci – bylo to výhodné, protože bylo velmi snadné ověřit, zda implementovaný kód dosahuje očekávaných výsledků. Použití frameworku PHPUnit v kombinaci s frameworkem Nette pak vyžadovalo vytvoření tzv. bootstrap souboru pro spustitelnost testů, z důvodu vlastního autoloaderu Nette a definici klíčových proměnných Nette aplikace. bootstrap + config.ini a prostředí Console Env v Nette require_once "PHPUnit/Framework.php";
Byly též zaznamenány akceptační testy v html formátu za pomoci nástroje Selenium IDE – tímto nástrojem bylo možné snadno pokrýt regresní testování na konci každé iterace. Příklad takového testu viz příloha H.
5
NÁVRH ŘEŠENí
5
45
Návrh řešení
5.1
Tok běhu hry
Jako „běh hryÿ se označuje sehrávka hry podle daných pravidel v jednom semestru. Běh hry logicky odpovídá sehrávce hry v rámci určitého semestru. V rámci běhu hry je nutno ze začátku definovat počet trhů a počet firem, které mohou být k trhu přiřazeny, poptávku po jednotlivých produktech v každém kole a ceny surovin v každém kole. Změny související s daným během hry se pak týkají tří oblastí. Pod pojmem workflow tak shrnuji: 1. Vytvoření nového běhu hry a změnu jeho stavu dle povolených přechodů a prerekvizit k dané změně. 2. Změnu aktuálního kola v běhu hry na následující kolo, jsou-li splněny prerekvizity ke změně. 3. Změnu stavu aktuálního kola, jsou-li splněny prerekvizity ke změně. V rámci běhu hry jsou definovány následující stavy běhu hry: • Příprava, kdy instruktor podle známého počtu studentů definuje počet trhů a může si předpřipravit parametry poptávek a cen surovin. • Zápis týmů, odpovídající prvnímu cvičení v předmětu. Hráčům je umožněno vytvořit herní tým. Každý student musí být členem nějakého týmu, a to pouze jednoho týmu v rámci běhu hry. Je však možná situace, že daný hráč opakuje předmět, může být proto členem jiného týmu v jiném běhu hry. • Tvorba firem. Hráčům již není dovoleno žádným způsobem manipulovat s týmy. Instruktor spuštěním tzv. „samoorganizaceÿ generuje pro každý tým jednu firmu, za kterou budou hrát, a přiřazuje náhodně k trhu, podle dříve definovaného počtu minimálního a maximálního množství firem na trhu. Podle počtu vzniklých týmů, který se může lišit od očekávaného, je pak možné pro instruktora upravit parametry trhů tak, aby každý tým měl přiřazenu právě jednu firmu. • Nastaven, kdy veškeré požadované údaje jsou zadány, ale instruktor ještě nechce hru zpřístupnit hráčům. Ví však, že běh hry v tomto stavu je sehratelný, protože byly provedeny validace pro možnost zahájení hry. • Hraje se, ve kterém dochází k většině aktivit. Hráči zadávájí rozhodnutí firmy v kole a poté vedoucí provede výpočet simulace. Teprve v tomto stavu běhu hry je též umožněno měnit aktuální kolo hry a též stav aktuálního kola. • Ukončen, kdy je po sehrávce, hráčům je stále umožněn přístup k datům jejich firmy, mají-li povolen přístup do systému. Stavový diagram přechodů viz obr. č. 11. Operace, které manipulují s daty daného běhu hry (poptávky, ceny surovin, rozhodnutí, výpočet výsledků) jsou obvykle povoleny pouze v určitém stavu běhu hry. Výjimkou jsou samozřejmě operace přímo
5.1
Tok běhu hry
46
související se změnou stavu běhu hry, změnou stavu kola a změnou aktuálního kola (což jsou též data daného běhu hry). Též operace instruktora související s Uživateli systému nejsou nijak závislé na běhu hry a tedy ani na jeho stavu.31 Rozdělení dané stavy též pokrývá rozdělení aktivit instruktorů a hráčů v rámci semestru – tedy stavy byly zvoleny i vzhledem k obvyklému harmonogramu sehrávky hry v rámci cvičení předmětu Strategický management.
Obr. 11: Stavový diagram pro běh hry
Dál je pak nutné provést analýzu kol. Kola se obecně rozdělují na dva druhy, herní a neherní; každé kolo má atribut „číslo kolaÿ, kola tak tvoří spojitou rostoucí sekvenci celých čísel. S daným kolem jsou pak spojeny téměř veškeré entity související se sehrávkou hry, tedy data trhu, rozhodnutí hráčů pro firmu atd. Herní kolo je takové, ve kterém je hráčům umožněno provést zadání rozhodnutí a instruktorům 31
Pozor, jde o obecně uživatele systému. Hráči pak tvoří v začátku sehrávky týmy, a ty již jsou v kontextu určitého běhu hry a tedy operace nad týmy jsou ovlivněny stavem běhu hry.
5.1
Tok běhu hry
47
výpočet výsledků. Počet herních kol určuje Instruktor při založení běhu hry, přičemž možnosti jsou omezené výčtem. Kromě herních kol je také nutno zavést i neherní kola, ve kterých je možné určitá data definovat, nicméně sehratelná nejsou. Pro výpočet výsledků v prvním herním kole je nutno znát stav ve firmě z předchozího kola (počáteční stav firem definovaný pravidly); tím se dostáváme k nutnosti odlišit počáteční neherní kolo od běžného herního kola. Počáteční neherní kolo tak musí být pouze jedno v rámci běhu hry. Koncová neherní kola existují z toho důvodu, že marketingové informace lze získavat až na čtyři kole dopředu, což musí být možné i v posledním herním kole; koncová neherní kola v rámci běhu hry tedy musí být právě čtyři. V rámci sehrávky daného běhu hry je vždy aktuální pouze jedno herní kolo. To prochází při sehrávce třemi obdobími, nazvanými podle pojmenování zavedeném na Ústavu managementu: • Rozhodovací období, ve kterém hráči mohou zadávat a upravovat rozhodnutí pro dané kolo hry. Pro přechod do dalšího období musí existovat rozhodnutí každé firmy. • Simulační období, ve kterém vedoucí hry provádí výpočet výsledků (což dříve určitý čas trvalo). Pro přechod do dalšího období musí být spočteny výsledky na všech trzích. • Výsledkové období, ve kterém hráči mohou vidět výsledky aktuálního kola. Výsledky předchozích kol mohou vidět nezávisle na stavu aktuálního kola. Herní kolo, které není aktuálním kolem, se může nacházet pouze v jednom z následujícíh dvou stavů: K sehrávce (ještě nebylo aktuálním kolem) a nebo Uzavřeno (již byla provedena sehrávka tohoto kola). Druhy kol, stavy kol a možné přechody mezi stavy zobrazuje obr. č. 12; je možné si všimnout, že neherní kola jsou definována jako konkrétní stavy. Tento návrh byl vytvořen pro účely snazšího návrhu struktury databáze. Herní kolo, které není aktuálním kolem, se může nacházet pouze v jednom z následujícíh dvou stavů: K sehrávce (ještě nebylo aktuálním kolem) a nebo Uzavřeno (již byla provedena sehrávka tohoto kola). Druhy kol, stavy kol a možné přechody mezi stavy zobrazuje obr. č. 12; je možné si všimnout, že neherní kola jsou definována jako konkrétní stavy. Tento návrh byl vytvořen pro účely snazšího návrhu struktury databáze. V rámci workflow je nutno ještě definovat určité prerekvizity pro změnu. Některé změny totiž mohou být provedeny až po splnění patřičných kritérií, což udržuje data běhu hry v očekávaném konzistentním stavu. Veškeré ostatní změny stavu kola či běhu hry (které nemají definované prerekvizity) je možné provádět kdykoliv Instruktor uzná za vhodné, tedy ve vztahu k harmonogramu sehrávky. Byly nalezeny následující prerekvizity: • Změna stavu běhu hry z Tvorba týmů do Nastaven. Stav Nastaven vznikl právě pro možnost kontroly prerekvizit, aby instruktor mohl ověřit, že je vše připraveno na sehrávku. Pro tuto změnu musí být totiž splněny následující tři podmínky:
5.1
Tok běhu hry
48
Obr. 12: Druhy kol, stavy kol a možné přechody mezi stavy
– Všechny trhy daného běhu hry mají definovány poptávky po výrobcích pro každé kolo. – Daný běh hry má definovány ceny surovin pro každé kolo. – Všechny týmy v daném běhu hry mají přiřazenu firmu, za kterou mohou hrát. • Změna stavu kola z Rozhodovacího na Simulační. Pro tuto změnu musí být splněna podmínka, že všechny firmy zadaly rozhodnutí pro dané kolo. • Změna stavu kola ze Simulačního na Výsledkové. Pro tuto změnu musí být splněna podmínka, že všem firmám byly vygenerovány výsledky pro dané kolo. • Změna aktuálního kola na kolo o číslo větší. Pro tuto změnu musí být splněny dvě podmínky; aktuální kolo musí být ve stavu Uzavřeno a následující kolo musí být ve stavu K sehrávce (tedy nesmí být neherním kolem.)
5.2
Požadavky na novou aplikaci
5.2
49
Požadavky na novou aplikaci
Požadavky pokryté dosud prvním webovým rozhraním a popsané v oddíle 3.1 zůstávají nezměněny. Pravidla hry se zásadním způsobem nezměnila a hra je stále organizovaná shodným způsobem. Novým požadavkem je nahrazení současného způsobu výpočtu výsledků daného trhu. Ukázka tohoto systému je v příloze D. Podkladem se nově staly soubory výpočtů ve formátu excel a též zápis rozhovorů se současnými instruktory hry o způsobu práce s těmito soubory, tedy co je nutno vykonávat v každé fázi průběhu hry. Požadavky na novou aplikaci, v souladu s agilním vývojem, byly tvořeny v průběhu iterací. Většina vznikla na počátku projektu, nicméně i požadavky samotné podléhaly změnám. Protože nejpozději po dvou iteracích byla provedena neformální předávka budoucím uživatelům, bylo možné požadavky korigovat. Některé požadavky se v průběhu času ukázaly jako nesprávné a byly přepsány či zrušeny. Číslování požadavků proto odráží chronologii jejich změn. Největší počet požadavků vznikl samozřejmě na začátku projektu. Zásadní změnou se ukázal požadavek na automatickou tvorbu firem a jejich přiřazování mezi týmy hráčů a trhy v rámci běhu hry (REQ-031 až REQ-041). Požadavky REQ-044 až REQ-046 vznikly teprve nedávno, při předávce verze na konci iterace 22 (alfa verze) budoucím uživatelům na Ústavu managementu. Seznam tzv. „User storiesÿ popisuje, co by měla nová aplikace dělat a proč. Popis User stories se pak snaží dodržovat přístup navržený v (Cohn, 2004), tedy podle vzoru „Jako [Role] chci použít [Funkci systému] abych dosáhl [Hodnotného cíle]ÿ. 5.2.1
User Stories obecného Uživatele systému (jak Hráče tak Instruktora)
• REQ-001: Jako Uživatel se chci přihlásit, abych mohl začít používat systém. • REQ-002: Jako Uživatel se chci odhlásit, abych měl jistotu nezneužití systému jinou osobou. • REQ-026: Jako Uživatel, který zapomněl své heslo, chci mít možnost nastavení nového hesla bezpečným způsobem, abych mohl opět používat systém.
5.2.2
User Stories Hráče
• REQ-031: Jako Hráč chci založit za sebe nový tým, abych měl možnost přidat své kolegy jako členy mého týmu. • REQ-032: Jako Hráč chci přidat do mého týmu další Hráče, abychom vytvořili kompletní tým nutný k sehrávce hry. • REQ-033: Jako Hráč chci mít možnost odebrat z týmu daného Hráče, abych mohl zrušit omylem přiřazeného hráče.
5.2
Požadavky na novou aplikaci
50
• REQ-034: Jako Hráč chci vidět členy týmu, jehož já jsem členem, abych věděl kdo se mnou vlastně hraje. • REQ-030: Jako Hráč chci mít možnost změnit název firmy, za kterou můj tým hraje, abych se mohl výrazněji odlišit a identifikovat s firmou. • REQ-014: Jako Hráč chci zadat rozhodnutí své firmy pro dané kolo podle pravidel hry, což je ostatně hlavní krok celé hry z mé strany. • REQ-015: Jako Hráč chci upravit rozhodnutí své firmy pro dané kolo podle pravidel hry, abych mohl opravit svoji chybu při zadávání rozhodnutí. • REQ-016: Jako Hráč chci vidět všechna svá rozhodnutí v jednotlivých kolech, abych mohl korigovat svůj další postup ve hře. • REQ-017: Jako Hráč chci vidět všechny své výsledky firmy za jednotlivá kola (Cash flow, VZZ, Rozvaha, Průzkumy trhu a další informace o průběhu sehrávky), abych byl seznámen s touto formou informací o firmě a mohl korigovat svůj další postup ve hře. • REQ-022: Jako Hráč chci mít možnost stáhnout reporty z výsledků daného kola, abych je mohl dále zpracovávat tabulkovým procesorem a mohl korigovat svůj další postup ve hře.
5.2.3
User Stories Instruktora
• REQ-003: Jako Instruktor chci přidat uživatele do systému, aby ho mohl využívat další člověk. • REQ-004: Jako Instruktor chci přidat seznam Hráčů do systému s ohledem na výstup seznamu studentů předmětu z UIS32 , abych nemusel přidávat několik desítek či stovek Hráčů postupně jednoho po druhém. • REQ-007: Jako Instruktor chci vidět přehled všech Běhů hry, abych je mohl dále spravovat. • REQ-008: Jako Instruktor chci být schopen vytvořit nový Běh hry, aby mohla být zahájena nová sehrávka hry. • REQ-009: Jako Instruktor chci vytvořit nový trh v rámci Běhu hry a stanovit kolik firem k němu může být přiřazeno, aby mohla být spuštěna sehrávka hry. • REQ-035: Jako Instruktor chci upravit kolik minimálně a maximálně firem k danému trhu může být přiřazeno, abych mohl opravit dřívejší nepřesný odhad kolik vznikne týmů. • REQ-010: Jako Instruktor chci přidat a upravovat tržní potenciály pro dané kolo a trh v rámci Běhu hry, aby bylo možné spustit hru. • REQ-011: Jako Instruktor chci přidat a upravovat ceny surovin pro dané kolo v rámci Běhu hry, aby bylo možné spustit hru. • REQ-036: Jako Instruktor chci vidět seznam týmu, které vznikly v rámci daného Běhu hry, abych mohl korigovat parametry trhu v rámci daného Běhu hry. 32
„Univerzitní informační systémÿ, akademický informační systém používaný na Mendelově univerzitě.
5.2
Požadavky na novou aplikaci
51
• REQ-038: Jako Instruktor chci vidět členy daného týmu, abych je mohl kontaktovat v případě jakéhokoliv problému. • REQ-037: Jako Instruktor chci vědět, kolik týmů nemá přiřazenu firmu, za kterou by mohli hrát, abych mohl korigovat parametry trhu v rámci daného Běhu hry. • REQ-040: Jako Instruktor chci vědět, kolik je k dispozici tzv. „volných slotůÿ na všech trzích v daném běhu, tedy kolik ještě může vzniknout firem s ohledem na minimální a maximální počty na trzích, abych mohl korigovat parametry trhu v rámci daného Běhu hry. • REQ-039: Jako Instruktor chci vědět, kolik trhů je bez minimálního nutného počtu přiřazených firem, abych mohl tuto situaci korigovat. • REQ-041: Jako Instruktor chci zrušit nadbytečný trh bez minimálního nutného počtu přiřazených firem, aby bylo možné spustit hru. • REQ-028: Jako Instruktor chci spustit Samoorganizaci Týmu a Trhu (vznik a spárování firem hráčů) v rámci daného Běhu hry, abych toto nemusel dělat ručně pro každý tým. • REQ-029: Jako Instruktor chci jednoduše vědět, k jakému trhu je daná firma přiřazena (přičemž přiřazení je neměnné v průběhu hry), abych poznal, které firmy (týmy) hrají na stejném trhu již podle názvu firem. • REQ-019: Jako Instruktor chci řídit změnu stavu daného Běhu hry s ohledem na nutné prerekvizity pro změnu do nového stavu, aby hra mohla být sehrávána tak, jak je očekáváno. • REQ-020: Jako Instruktor chci řídit změnu stavu aktuálního kola v rámci Běhu hry s ohledem na nutné prerekvizity pro změnu do nového stavu, aby hra mohla být sehrávána očekávaným způsobem. • REQ-021: Jako Instruktor chci nastavit aktuální kolo na následující kolo v rámci Běhu hry s ohledem na nutné prerekvizity, aby hra mohla být sehrávána očekávaným způsobem. • REQ-006: Jako Instruktor chci vědět, které týmy odevzdaly a které týmy naopak neodevzdaly svá Rozhodnutí, abych mohl případné neodevzdání dále řešit. • REQ-005: Jako Instruktor chci spustit výpočet generování výsledku aktuálního kola pro daný trh podle pravidel hry, ve kterém musí být zadána rozhodnutí pro všechny přiřazené firmy, abych to nemusel dělat ručně v tabulkovém procesoru. • REQ-018: Jako Instruktor chci vidět detaily dané firmy Hráče – rozhodnutí v daném kole, výsledky v daném kole – abych mohl nalézt případné nepřesnosti či vyloženě chybná rozhodnutí a upozornit na ně Hráče. • REQ-042: Jako Instruktor chci vidět souhrnnou statistiku za daný trh, abych měl co prezentovat na posledním kole Hráčům. • REQ-025: Jako Instruktor chci mít možnost upravit webové stránky týkající se manažerské hry Výroba nábytku, abych mohl aktualizovat informace týkající se organizace sehrávky hry.
5.3
Zhodnocení existujícího prototypu
52
• REQ-044: Jako Instruktor chci vědět, kteří hráči ještě nejsou členy žádného týmu, abych měl jistotu, že všichni studenti ve cvičení mají možnost zadávat rozhodnutí. • REQ-045: Jako Instruktor chci mít možnost založit běh hry „ jedním kliknutíÿ (importovat z csv nebo zkopírovat data z již existujícího běhu) i s dříve definovanými klíčovými daty (počet kol, poptávky v kolech a trzích, ceny surovin v kolech), abych nemusel každý semestr znovu zadávat ty samé hodnoty a netrvala mi příprava nového běhu hry zbytečně dlouho. • REQ-046: Jako Instruktor chci mít možnost zadat rozhodnutí za daný tým (firmu) aby v případě, že jeden tým tuto povinnost nesplní, nebyla blokována tvorba výsledků na celém trhu.
5.3
Zhodnocení existujícího prototypu
Webová aplikace vytvořená v rámci této práce není první, která se snaží zlepšit stávající stav. Před zahájeném tvorby nové webové aplikace bylo nutné se rozhodnout, zda pokračovat v již existujícím prototypu, který vytvořil Libor Stránský a popsal v (Stránský, 2008). Kód prototypu byl předán pracovníkům Ústavu managementu, vytvořený prototyp webové aplikace nicméně dokončen a nasazen nebyl. Jde o aplikaci napsanou v jazyce PHP, s využitím frameworku CodeIgniter a databázového systému MySQL. Po průzkumu kódu a zejména databázového schématu v porovnání s reálnými požadavky na ústavu managementu se autor této práce rozhodl napsat webovou aplikaci znovu. Prvním problémem je skutečnost, že tento prototyp se snaží pokrýt existující pravidla hry, má však i ambice pokrýt svým návrhem pravidla novější (o kterých se v té době mluvilo jako o možnosti, nicméně dodnes nejsou sepsána). Jak sám autor prototypu píše v (Stránský, 2008, s 57), „prototyp nevyniká kompletní funkčností, i když obsahuje její velkou část a i části a funkce, které jsou naplánovány do budoucích verzí pravidelÿ.33 Nová pravidla hry však zůstala v hypotetické rovině. Žádná nová, zcela přepracovaná pravidla, která by prototypovaná aplikace měla dalším rozšířením podporovat, dosud nevznikla a naopak se o nich přestalo uvažovat. Návrh datového modelu tak nadbytečně uvažuje o datech použitelných v různých verzích pravidel, přestože zcela neřeší proces změn související s daným během hry (který je dosud stále stejný, neboť se používají tytéž excelovské soubory shodným způsobem stejnou osobou). Entita Kolo hry má atributy zadavani od a zadavani do definováno období, kdy je možné zadávat rozhodnutí (pokryto Rozhodovací období). Kompletní rozdělení kola podle způsobu, jakým je hra sehrávána však chybí, tedy rozdělení na Rozho33
Na obhajobu kolegy Stránského je třeba uvést, že tento nevhodný nápad na podporu různých verzí pravidel v rámci jedné webové aplikace mu byl vnuknut autorem této diplomové práce. Na druhou stranu — autor prototypu tuto myšlenku nevyvrátil jako zbytečnou komplikaci, přestože je rovněž příznivcem agilního programování a tento požadavek jde přímo proti této metodice vývoje.
5.4
Analýza požadavků ve vztahu k již existujícím řešením (CMS)
53
dovací, Simulační a Výsledkové období; v každém období se přitom aplikace má chovat odlišným způsobem. Stejně tak chybí v ERD diagramu uložení podstatné informace o tom, které kolo je aktuálním kolem daného běhu hry. Stav kola je řešen v návaznosti na aktuální čas, což z pohledu testování není zrovna ideální řešení – v prototypu však též chybí kód, který by ošetřoval případné konfliktní situace, vzniklé nesplněním prerekvizit pro přechod do dalšího stavu kola případně stavu běhu hry. V důsledku je možné data uložená v takovémto schématu vykládat dvojím způsobem. Jako příklad lze uvést problém neuzavřeného Rozhodovacího období – aby mohly být provedeny výpočty trhu, musí zadat svá rozhodnutí všechny týmy hrající na daném trhu. Problém vzniká, když nejsou zadána všechna rozhodnutí a přitom aktuální čas je již po hodnotě „zadavani doÿ pro aktuální kolo. Nikterak též není pokryt fakt, že musí existovat i neherní kola, ve kterých musí existovat určitá data pro možnost výpočtu výsledků aktuálního kola, ale hráči již v těchto kolech nemají možnost zadávat rozhodnutí. Též řízení běhu hry jako takového není pokryto tím způsobem, jak instruktoři a hráči v průběhu sehrávky postupují. Implementačním problémem je například, podle názoru autora této práce, nevhodné použití úložiště MyISAM (tedy bez možnosti referenční integrity definicí cizích klíčů) v době, kdy bylo již možné použít úložiště typu InnoDB. Použití MyISAM, v kombinaci s vynecháním jakýchkoli dalších integritních omezení v databázi (např. zcela základní požadavek na unikátnost daného záznamu) a s aplikačním kódem, provádějícím volání úprav záznamů v průběhu výpočtu výsledků bez možnosti obalení tohoto seznamu úprav databázovou transakcí, znamená jediné — data uložená v databázi mohou být velice snadno nekonzistení. Výpočet výsledků přitom není dokončen, neodpovídá výstupu z podpor hry implementovaných v tabulkovém procesoru. Ani jeden z racionálních důvodů pro použití typu úložiště MyISAM (vyšší rychlost databázového systému a snadnější fulltextové vyhledávání v záznamech) není pro tuto aplikaci rozhodujícím důvodem, zvláště pak za cenu zhoršení možností pro definování integrity dat. Změna typu úložiště a přidání referenční integrity by sama o sobě nebyla složitým zásahem; zásadnější je nevhodnost schématu jako takového. Posledním zásadním problémem je též použitý framework Code Igniter ve verzi 1.6.1, který v současné době sice je stále udržován, ale do určité míry morálně zastaral. Vzhledem k veškerým uvedeným skutečnostem nepovažuje autor této práce za vhodné novou aplikaci tvořit pomocí úprav tohoto prototypu – nutných úprav je tolik, že v důsledku se jedná o znovunapsání aplikace.
5.4
Analýza požadavků ve vztahu k již existujícím řešením (CMS)
Při podrobnějším zkoumání seznamu požadavků je možné postřehnout problémovou oblast, která je obecnějšího charakteru a je možné vybírat z existujících aplikací a není tak nezbytně nutné vytvářet další kód. Jde o požadavek REQ-025: Jako In-
5.5
Datový model
54
struktor chci mít možnost upravit webové stránky týkající se hry Výroba nábytku, abych mohl aktualizovat informace týkající se organizace sehrávky hry. Na webových stránkách je aktuálně pouze stručný popis hry, informace o harmonogramu sehrávky hry, odkaz na součané jednoduché webové rozhraní hry a možnost stažení pravidel hry. Problém aktualizace těchto informací, jak bylo popsáno v oddíle 3.1, je aktuálně řešen ne zcela ideálním způsobem pomocí přímé editace HTML souborů na produkčním prostředí. Tento požadavek je možné rozdělit na podrobnější požadavky (založit stránku, editovat stránku, definovat pořadí stránek v hlavním menu atd.) a zjistíme, že popisujeme obecný systém typu CMS (content management system; systém správy obsahu). Zde není zapotřebí vyvíjet úsilí pro tvorbu vlastního řešení, je možné použít některý z mnoha již existujících systémů pro správu obsahu. Kritéria výběru konkrétního CMS byla následující: shodný implementační jazyk (PHP), úložiště MySQL nebo i čistě souborové řešení, otevřený zdrojový kód (open–source), snadnost používání pro údržbu velmi malého webu (do pěti stránek), možnost šablon resp. snadná úprava vzhledu, administrační rozhraní ideálně v češtině a pochopitelně odsouhlasení budoucími uživateli. Všeobecně známá CMS (např. Drupal, Joomla atd.) kritéria výběru odsunula do pozadí, neboť jejich plná síla se projevuje až při správě daleko komplikovanějšího obsahu a administrace je pro očekávané nasazení až zbytečně komplexní. Do užšího výběru se tak dostaly následující projekty: • Energine • Frog • GetSimple • Nanomus • Nors • ReloadCMS • SkyBlueCanvas Nejvýhodnějším se ukázal být CMS GetSimple, aktuálně ve verzi 3. Použitím CMS systému se dostáváme k modelu produkčního prostředí popsanému diagramem nasazení na obrázku č. 13 (srovnej se současným řešením popsaným na obr. č.7)
5.5
Datový model
Pro vytvářenou aplikaci je klíčové určení entit a vztahů mezi nimi. V tomto oddíle proto bude podrobněji rozebrána struktura dat. Při tvorbě ERD diagramu bylo snahou dosáhnout normalizovaného návrhu databázového systému, který bude splňovat alespoň 3. normální formu. Použit byl nástroj MySQL Workbench, což je open–source program přímo od tvůrců databázového systému Mysql. S ním je možno pracovat dvojím způsobem: definovat data právě pomocí ERD diagramu a nechat si skript pro tvorbu databáze vygenerovat a nebo naopak napsat SQL skript pro vytvoření databázové struktury ručně a použít MySQL Workbench pro vygenerování ERD diagramu a jeho další zkontrolování. Pro větší kontrolu nad podobou skriptu
5.5
Datový model
55
Obr. 13: Diagram nasazení nové podpory hry Výroba nábytku
pro tvorbu databáze se autor této práce rozhodl aplikovat druhou variantu použití tohoto nástroje. Pro doplnění je vhodné podotknout, že obvyklým postupem používaným v praxi při vývoji ve větším počtu programátorů je údržba tzv. migračních skriptů, tedy SQL příkazů měnících jak strukturu databáze (schéma) tak klíčová systémová data mezi jednotlivými verzemi aplikace.34 Logická úvaha je totiž taková, že kód se při vývoji i údržbě může měnit poměrně snadno ve verzovacím systému a nasazení nové verze do produkce je obvykle jednoduchá záležitost, nicméně po ostrém nasazení aplikace do produkčního prostředí v určité verzi již máme v databázi nějaká uživatelská data a ta ve většině případů nemůžeme „zahoditÿ a vytvořit databázovou strukturu znovu. Také je nutné udržet kontrolu nad změnami struktury v jednotlivých prostředích – vývojovém, testovacím a produkčním, zvláště pokud je tvoří více lidí současně. V případě tvorby nových podpor pro manažerskou hru „Výroba nábytkuÿ nebylo využití tohoto postupu nutné a autor této práce si mohl dovolit udržovat pouze jeden skript pro tvorbu databáze a druhý pro vložení klíčových systémových dat. Po nasazení nových podpor do produkčného prostředí však je vhodné výše uvedený postup začít využívat Schéma bylo vytvořeno takovým způsobem, že žádný atribut nemůže existovat bez přiřazené hodnoty – všechny mají klauzuli NOT NULL. Protože i schéma samotné podléhalo iterativnímu vývoji, některé detaily odráží odsouhlasené změny v pravidlech, které budou popsány dále v oddíle v příloze 6.3. Nejzásadnější změnou je volitelný počet firem na trhu – v sehrávkách s využitím současných podpor se po34
Vhodnými open–source nástroji pro tento úkol jsou pak například projekty Liquibase nebo Flyway.
5.5
Datový model
56
čítá s konstatním počtem firem přiřazených k trhu (pět). ERD diagram pro nově vzniklou aplikaci je možné vidět v příloze C.
5.5
Datový model
57
Tabulka c role uzivatele Tabulka, která obsahuje číselník možných rolí uživatele. Systémová tabulka, data jsou naplněna při nasazení a neočekává se jejich další změna. • id – primární klíč. • nazev role – hodnota číselníku, unikátní. („hracÿ a „instruktorÿ) Tabulka uzivatel Tabulka obsahující všechny uživatele systému. Sama o sobě slouží především k autentizaci a autorizaci, s autorizací je též spojena entita tokeny zmeny hesla uzivatele, která se na uživatele odkazuje. Uživatel je též ve vztahu s dalšími tabulkami rozhodnuti firmy v kole a s hrac v tymu v behu. Využití e-mailu jako přihlašovacího jména je jeden z tipů popsaných v (Vrána, 2010, s.379), zde autor knihy uvádí že „uživatel si tak nebude muset pamatovat další údaj a řešit případ, kdy bylo jeho oblíbené uživatelské jméno už zabranéÿ. V případě vytvářené aplikace je zamýšlené použití trochu jiné, uživatele totiž přidává instruktor a neexistuje možnost se registrovat samostatně ze strany hráčů35 . Obvykle přidává studenty, proto se počítá s možnými výstupy z univerzitního informačního systému. Seznam univerzitních e-mailů studentů předmětu Strategický management v daném semestru tak udává seznam hráčů, které je zapotřebí přidat před sehrávkou hry. Systém též musí počítat se situací že určitý student předmět opakuje. • id – primární klíč. • role – cizí klíč do tabulky c role uzivatele. • login email – přihlašovací jméno (login) uživatele, musí být unikátní. Očekáván e-mail, ve většině případů UIS, čímž je unikátnost nepřímo vynucena. • heslo – hash aktuálního hesla uživatele. • zalozen – čas založení uživatele. • aktivni – boolean atribut zda je povolen uživateli přístup do systému či ne. Tabulka tokeny zmeny hesla uzivatele Tabulka tokenů pro funkci změny hesla. Pokud uživatel zapomene heslo, může si nechat na svůj e-mail zaslat odkaz pro změnu hesla, obsahující token s omezenou platností. • token – primární klíč. • platnost do – do kdy je možné token použít na změnu hesla. • uzivatel – cizí klíč do tabulky uzivatel. Tabulka tym hracu Tato tabulka je na první pohled trochu zvláštní, protože obsahuje pouze primární klíč. Entita tým je totiž reálnou entitou systému, ale dosud nebyl identifikován žádný atribut související s týmem jako takovým. Tým je důležitý pro možnost definovat skupinu hráčů hrající za danou firmu – data související s týmem tak je nutné 35
A tedy nemůže hrát kdokoliv, kdo narazí na URL této aplikace. Instruktor naopak definuje „whitelistÿ, seznam lidí, kteří smí systém používat.
5.5
Datový model
58
hledat v navázaných spojovníkových tabulkách. Hráči se též identifikují především s firmou, není tedy například nutné ani tým pojmenovávat. • id – primární klíč. Tabulka s hrac v tymu v behu Spojovníková tabulka s vazbami na tři entity. Záznamy v této tabulce tvoří seznam hráčů daného týmů v daném běhu. Bylo zváženo několik variant, jak uložit tuto informaci a „trojspojovníkÿ byl zvolen pro možnost definování požadováných integritních omezení bez nutnosti uložených procedur. Hráč totiž může hrát pouze za jeden tým v rámci jednoho běhu hry. Toto omezení je implementováno následujícími dvěma složenými unikátními klíči. UNIQUE INDEX unique_uzivatel_prirazen_tymu (uzivatel ASC, tym ASC), -- daný hráč může být přiřazen k danému týmu pouze jedenkrát. UNIQUE INDEX unique_uzivatel_v_behu_hry (uzivatel ASC, v_behu_hry ASC) -- hráč může být přiřazen k týmu pouze jednou v rámci daného běhu hry. • id – primární klíč. Zde je vědomě a účelově porušena normalizace, neboť složený primární klíč ze tří atributů by bylo daleko složitější používat v aplikaci. • uzivatel – cizí klíč do tabulky uzivatel. Student může opakovat předmět, jde tedy o vazbu 1:N. • tym – cizí klíč do tabulky tym hracu. Hráč může být přiřazen pouze k jednomu týmu v rámci běhu hry. Zde jde tedy o vazbu 1:1. • v behu hry – cizí klíč do tabulky beh hry. V rámci jednoho běhu hry je pochopitelně více týmů, jde o vazbu 1:N, Tabulka c stav behu hry Číselník možných stavů běhu hry, tak jak byly popsány v oddíle 5.1. Systémová tabulka, data jsou naplněna při nasazení a neočekává se jejich další změna. • id – primární klíč. • stav – hodnota číselníku, unikátní. (priprava, zapis tymu, tvorba firem, nastaven, hraje se, ukoncen) Tabulka beh hry Tabulka udržující veškeré běhy hry. Je „cílemÿ relací ze strany následujících entit: „trojspojovníku hráče v týmu v běhuÿ, trhů, kol a též aktuálního kola. • id – primární klíč. • stav behu hry – cizí klíč do tabulky c stav behu hry. • semestr – cizí klíč do tabulky c semestr. • nazev – název běhu hry, který vyplní instruktor. • pocet kol – počet kol běhu hry. Údaj se vyplňuje při vzniku nového běhu hry, podle toho je v databázové transakci vytvořeno dané množství kol, dále již je tento atribut neměnitelný.
5.5
Datový model
59
Tabulka c stav kola Číselník možných stavů kola, tak jak byly popsány v oddíle 5.1. Systémová tabulka, data jsou naplněna při nasazení a neočekává se jejich další změna. • id – primární klíč. • stav – hodnota číselníku, unikátní. (poc neherni, konc neherni, k sehravce, rozhodovaci, simulacni, vysledkove, uzavreno) Tabulka kolo hry Tabulka všech kol v daném běhu hru. Tato entita je další častý „cílÿ relací, a to ze strany následujících entit: aktuální kolo, poptávka trhu v kole, ceny surovin. Totéž platí také pro entity, které jsou zcela zásadní pro sehrávku; stav firmy v kole, rozhodnutí firmy v kole a průběh výpočtu firmy v kole. • id – primární klíč. • v behu hry – cizí klíč do tabulky beh hry. • stav kola – cizí klíč do tabulky c stav kola. • cislo kola – kola jsou číslována vzestupnou sekvencí v rámci běhu hry. Tedy „kolikáté kolo je právě sehrávánoÿ. Tabulka aktualni kolo Tabulka je příklad ne zrovna ideálního návrhu, jehož změna je úkol pro refactoring. Tato informace by měla být lépe zachycena jako atribut běhu hry (které kolo je aktuální, formou cizího klíče). Vznikla nevhodnou úvahou o aktuálním kole jako samostatné entitě. Nevýhodou zvoleného řešení je totiž možnost vzniku nekonzistence dat, kdy kolo hry je definováno jako aktuální kolo v rámci jiného běhu, než v jakém je samo přiřazeno. Aktuální kolo může být logicky jen právě jedno pro každý běh hry. Toto omezení je implementováno dvěma unikátními klíči, nad atributy v behu hry a kolo. • id – primární klíč. • v behu hry – cizí klíč do tabulky beh hry. • kolo – cizí klíč do tabulky kolo hry. Tabulka c semestr Číselník semestrů, pro lepší organizaci běhů hry. • id – primární klíč. • nazev – typicky „LS 2009/2010ÿ • datum – časový údaj nějak identifikující semestr (typicky jeho začátek), pro možnost vytvoření logického řazení semestrů. Tabulka trh Trh je v rámci pravidel imaginární místo, kde firmy spolu soupeří v rámci sehrávky hry; tato informace je však zachycena až ve spojovníkové tabulce s firma na trhu. Trh jako entita tak slouží především pro funkcionalitu „samoorganizaceÿ, tedy vytváření firem vzhledem k počtu vzniklých týmů a ve vztahu k možným
5.5
Datový model
60
počtům firem definovaným ze strany instruktora. Hodnotu atributu min pocet firem lze snížit a max pocet firem zvýšit, pouze však pokud je stav běhu hry Příprava, Zápis týmů a nebo Tvorba firem. • id – primární klíč. • v behu hry – cizí klíč do tabulky beh hry. • cislo trhu – trhy jsou číslovány vzestupnou sekvencí v rámci běhu hry. Slouží k snazší orientaci instruktora při zadávání dat. Též firmy jsou pojmenovány pro instruktora tak, že je poznat k jakému trhu je firma přiřazena. • min pocet firem – kolik firem minimálně musí být přiřazeno k tomuto trhu. Lze snížit, pokud je týmů méně než se očekávalo. • max pocet firem – kolik firem maximálně může být přiřazeno k tomuto trhu. Lze zvýšit, pokud je týmů více než se očekávalo. Tabulka firma V této tabulce jsou uloženy firmy, za které hrají hráči. Pro tento účel je v relaci s rozhodnutími hráčů v kole, stavem firmy v kole a průběhem výpočtu firmy v kole. Dále pak k této tabulce existují vztahy od spojovníků, určující který tým za firmu hraje a na kterém trhu je firma zařazena. • id – primární klíč. • nazev hracu – název firmy, který mohou ovlivnit hráči. Při vytvoření je zvolen jako náhodný řetězec. • nazev instruktora – název firmy, který vidí pouze instruktoři. Při přiřazení firmy k trhu je upravena hodnota tohoto atributu a to na řetězec „T-x-F-yÿ, kdy x je číslo trhu kam je firma přiřazena a y je hodnota o kolikátou firmu na trhu se jedná. Tabulka rozhodnuti firmy v kole Tato tabulka odpovídá papírovému formuláři, popsaném v oddíle 3.1, resp. aktuálnímu webovému rozhraní (viz obr. č. 15). Jde tedy o nejdůležitější vstup od hráče v rámci sehrávky. Zadat či upravit rozhodnutí za danou firmu může kterýkoliv člen týmu, ke kterému je firma přiřazena. Struktura tabulky odpovídá požadavkům podpory současných pravidel. V jejich rámci víme, že firma prodává pouze dva produkty, vyrábí na jednom typu stroje a počet strojů je maximálně šest; proto v tuto chvíli není nutné vytvářet obecnější řešení, pokrývající libovolný počet produtků, typů strojů či nákup daného typu stroje do firmy. Změnu v kterémkoliv z těchto tří pravidel by již nicméně bylo vhodné řešit přesunem souvisejících atributů do samostatné tabulky, navázané na tuto. • id – primární klíč. • kolo – cizí klíč do tabulky kolo hry. • firma – cizí klíč do tabulky firma. • zadal – cizí klíč do tabulky uzivatel. • cas zadani – časová známka • marketing pot stoly pocet kol – viz kapitola pravidel hry Marketing a odbyt
marketing pot skrine pocet kol – viz kapitola pravidel hry Marketing a odbyt marketing pot stoly cena – viz kapitola pravidel Marketing a odbyt marketing pot skrine cena – viz kapitola pravidel hry Marketing a odbyt marketing cena kovu pocet kol – viz kapitola pravidel hry Marketing a odbyt marketing cena plastu pocet kol – viz kapitola pravidel hry Marketing a odbyt marketing prodejni ceny konkurentu – viz kapitola pravidel hry Marketing a odbyt odbyt cena stoly – viz kapitola pravidel hry Marketing a odbyt odbyt cena skrine - viz kapitola pravidel hry Marketing a odbyt odbyt podrzet stoly procenta – úprava stávajících pravidel, nový parametr odbyt podrzet skrine procenta – úprava stávajících pravidel, nový parametr vyroba stoly stroj 1 – viz kapitola pravidel hry Výroba vyroba stoly stroj 2 – viz kapitola pravidel hry Výroba vyroba stoly stroj 3 – viz kapitola pravidel hry Výroba vyroba stoly stroj 4 – viz kapitola pravidel hry Výroba vyroba stoly stroj 5 – viz kapitola pravidel hry Výroba vyroba stoly stroj 6 – viz kapitola pravidel hry Výroba vyroba skrine stroj 1 – viz kapitola pravidel hry Výroba vyroba skrine stroj 2 – viz kapitola pravidel hry Výroba vyroba skrine stroj 3 – viz kapitola pravidel hry Výroba vyroba skrine stroj 4 – viz kapitola pravidel hry Výroba vyroba skrine stroj 5 – viz kapitola pravidel hry Výroba vyroba skrine stroj 6 – viz kapitola pravidel hry Výroba nakup plast – viz kapitola pravidel hry Zásobování nakup kov – viz kapitola pravidel hry Zásobování investice zmena poctu stroju – viz kapitola pravidel hry Výroba rlz zmena mezd delniku – viz kapitola pravidel hry Řízení lidských zdrojů rlz zmena poctu zamestnancu – viz kapitola pravidel hry Řízení lidských zdrojů rlz skoleni – viz kapitola pravidel hry Řízení lidských zdrojů finance pozadovany uver – viz kapitola pravidel hry Finance
Tabulka stav firmy v kole V této tabulce je uložen stav klíčových proměnných modelu firmy, který odpovídá konci daného kola. Stav firmy v kole tedy vzniká provedením výpočtu střetu firem na trhu a vstupuje jako počáteční stav v kole následujícím. Pro první herní kolo je pak stav firmy shodný pro všechny hráče, je popsán v pravidlech hry a je uložen v počátečním neherním kole. • id – primární klíč. • kolo – cizí klíč do tabulky kolo hry. • firma – cizí klíč do tabulky firma. • pocet delniku – viz kapitola pravidel hry Řízení lidských zdrojů • mzdy delniku – viz kapitola pravidel hry Řízení lidských zdrojů • vzdelavani probehlo – viz kapitola pravidel hry Řízení lidských zdrojů
5.5
Datový model
62
• • • • • • • • •
pocet stroju – viz kapitola pravidel hry Výroba sklad plastu – viz kapitola pravidel hry Zásobování sklad kovu – viz kapitola pravidel hry Zásobování sklad stolu – viz kapitola pravidel hry Zásobování sklad skrinek – viz kapitola pravidel hry Zásobování pokladna – viz kapitola pravidel hry Finance investicni uver – viz kapitola pravidel hry Finance preklenovaci uver – viz kapitola pravidel hry Finance vzz cisty zisk – částečně viz kapitola pravidel hry Finance, částečně Výsledky; případná ztráta se přenáší do dalšího kola a snižuje základ daně. • pohledavka fu dane – úprava stávajících pravidel, nový parametr Tabulka prubeh simulace firmy v kole V této tabulce jsou uloženy některé mezivýpočty z tvorby nového stavu firmy v rámci výpočtu výsledků kola. Jsou ukládány ty údaje, které jsou nějakým způsobem dále zobrazovány hráčům. • id – primární klíč. • kolo – cizí klíč do tabulky kolo hry. • firma – cizí klíč do tabulky firma. • personalni index – viz kapitola pravidel hry Řízení lidských zdrojů • aktivni pracovnici – viz kapitola pravidel hry Řízení lidských zdrojů • vyrobene stoly – viz kapitola pravidel hry Výroba • vyrobene skrinky – viz kapitola pravidel hry Výroba • spotreba kov – viz kapitola pravidel hry Výroba • spotreba plast – viz kapitola pravidel hry Výroba • prubeh vyroby – viz kapitola pravidel hry Výroba (zda bylo nutné snižovat plán výroby) • poptavane stoly – viz kapitola pravidel hry Marketing a odbyt • poptavane skrinky – viz kapitola pravidel hry Marketing a odbyt • prodane stoly – viz kapitola pravidel hry Marketing a odbyt • prodane skrinky – viz kapitola pravidel hry Marketing a odbyt • akutni nakup kov – úprava stávajících pravidel, nový parametr (nákup při nedostatku suroviny ve skladech) • akutni nakup plast – úprava stávajících pravidel, nový parametr (nákup při nedostatku suroviny ve skladech) Tabulka s tym hraje za firmu Tento spojovník určuje, který tým může hrát za kterou firmu a nepřímo tedy kteří konkrétní uživatelé mají přístup k operacím s danou firmou. Jde o kardinalitu relace 1:1, jak atribut tým tak firma jsou unikátními. Protože entita tým vzniká daleko dříve než entita firma, není tato relace přímočaře uložena jako cizí klíč u firmy; bylo by nutné použít hodnotu NULL, čemuž
5.5
Datový model
63
se autor snažil v rámci zachování jednotného stylu schématu vyhnout. Dalším důvodem je možnost jednoduché odpovědi na dotaz na firmu ze strany týmu („ jsem členem daného týmu, za kterou firmu hraji?ÿ), který je velmi častý. Při uložení informace jako cizího klíče u entity tým opět musíme použít hodnotu NULL a naopak by se komplikovaně tvořil opačný dotaz ze strany firmy, tedy „ jsem jako hráč oprávněn provést danou operaci nad touto firmou?ÿ, který je též velmi častý. • id – primární klíč. • tym – cizí klíč do tabulky tym. • firma – cizí klíč do tabulky firma. Tabulka s firma na trhu Tento spojovník určuje, která firma je přiřazena ke kterému trhu. Jde o kardinalitu relace 1:N, více firem spolu soupeří na jednom trhu. Při podrobnějším prozkoumání ERD diagramu je možné vidět potenciál k vzniku nekonzistence dat. Existují tři spojovníky, vytvářející vazby mezi entitami tým, firma, trh a běh hry. Je tak teoreticky možné se dostat do neplatného stavu databáze, kdy určitý hráč je členem týmu v rámci běhy hry X, tým je přiřazen k firmě, firma je přiřazena k trhu a trh je přitom přiřazen k běhu hry Y. Toto riziko je možné snížit důkladným testováním, zavedením kontroly dat na aplikační vrstvě (PHP) a nebo posílením integritních omezení definováním uložené procedury ve formě triggeru. • id – primární klíč. • trh – cizí klíč do tabulky trh. • firma – cizí klíč do tabulky firma. Tabulka poptavka trhu v kole Tuto tabulku naplňuje instruktor před zahájením sehrávky hry. Velikost poptávky je závislá na počtu firem, které chce na tomto trhu instruktor umístit. • id – primární klíč. • trh – cizí klíč do tabulky trh. • kolo – cizí klíč do tabulky kolo hry. • poptavka stoly min cena – definice poptávkové křivky pro typ produktu stoly. • poptavka stoly max cena – definice poptávkové křivky pro typ produktu stoly. • poptavka skrinky min cena – definice poptávkové křivky pro typ produktu skříňky. • poptavka skrinky max cena – definice poptávkové křivky pro typ produktu skříňky. Tabulka ceny surovin Tuto tabulku naplňuje instruktor před zahájením sehrávky hry. Ceny surovin jsou podle pravidel „globálniÿ, platí pro všechny firmy na všech trzích v daném běhu a v daném kole.
5.5
• • • •
Datový model
id – primární klíč. kolo – cizí klíč do tabulky kolo hry. cena kov – viz kapitola pravidel hry Zásobování. cena plast – viz kapitola pravidel hry Zásobování.
64
6
VLASTNí PRÁCE
6
65
Vlastní práce
6.1 6.1.1
Implementace Celková struktura webové aplikace
Ve snaze o co nejmenší počet závislostí na dalších knihovnách je využit v aplikaci pouze framework Nette, knihovnu databázové abstrakce Dibi a komponenty pro Nette DataGrid, DependendSelectBox, Navigation a Logger. S výhodou bylo využito podporu Nette frameworku pro tvorbu modulů. Protože moduly mohou obsahovat i další submoduly, je za modul považován i „kořenový adresář aplikaceÿ. Webová aplikace byla rozdělena na následující čtyři moduly: • Modul „Gamerÿ, který obsahuje tu část aplikace, která slouží hráčům hry: práce s týmy, zadávání rozhodnutí a zobrazování výsledku firmy. Pouze uživatel s rolí „hráčÿ může používat tento modul. • Modul „Instructorÿ, ve kterém jsou funkcionality pro instruktora hry: správa uživatelů, zadávání dat pro běh hry, řízení toku běhu hry, spárování týmů a firem a spouštění výsledků. Pouze uživatel s rolí „Instruktorÿ může používat tento modul. • Modul „Simulÿ, který obsahuje pouze třídy související s výpočtem hry, tedy implementaci konkrétní verze pravidel simulační hry. Třídy v něm používají primárně instruktoři hry při spuštění výpočtu výsledků nad daným trhem. Okrajovým případem je volání ze strany hráčů, konkrétně pro výpočet průzkumů trhu pro tržní potenciál daného typu výrobku. • Kořenový modul aplikace (pod nímž jsou umístěny výše uvedené moduly), ve kterém jsou umístěny sdílené třídy (např. autorizační a autentizační model, komponenty používané ve všech modulech), pomocné adresáře pro Nette framework (temp,log) a který obsahuje i úvodní stránku webové aplikace, která ještě nepodléhá autorizačnímu mechanismu. V tomto kořenovém modulu jsou též vytvořeny základní abstraktní třídy BasePresenter a BaseModel, ze kterých dědí veškeré další presentery ze všech modulů a které jsou naopak potomky tříd z frameworku Nette. V tomtu modulu jsou též umístěny sdílené Nette komponenty. Závislosti mezi moduly, komponentami a knihovnami viz obr. č. 14. Tento UML package diagram je trochu „přiohnutÿ, protože jednak v PHP neexistuje něco jako package36 a také samotný koncept „modulůÿ a funkcionalit s nimi souvisejících definuje právě Nette framework, na kterém vše ostatní závisí. Aplikace psaná v Nette s využitím modulů, musí dodržovat určité předpoklady37 . Modul musí být adresářem, umístěným v adresáři aplikace (což je obvykle 36
Tak jak je známa např. z jazyka Java, organizující třídy určitým způsobem a navíc i s možností viditelnosti tříd pouze v rámci package. 37 V autorem této práce používané verzi frameworku 0.9.6.; pravidla pro konfiguraci a základní rozvržení aplikace se ve verzi frameworku 2.0 změnila.
6.1
Implementace
66
app, ale je možné to změnit v konfiguraci projektu) a adresář musí mít suffix „Moduleÿ – ve vytvářené aplikaci např. GamerModule. Třída presenteru, umístěná v daném modulu pak musí mít prefix názvu třídy shodný s názvem modulu, tedy např. Gamer DecisionPresenter; pozor, pouze název třídy, nikoliv název souboru. Toto omezení se týká pouze presenterů, protože jejich vyhledávání je součástí generování výsledku na URL. Šablony ani modely takto prefixovány být nemusí.
Obr. 14: Diagram závislostí nové aplikace.
V kořenovém adresáři celé vytvářené aplikace, jsou následující podadresáře. V adresáři „appÿ jsou umístěny třídy odpovídající MVP architektuře. Adresář „libsÿ obsahuje aplikací používané knihovny – nenajdeme v něm tedy například testovací PHPUnit, který je zvykem instalovat v rámci testovacího prostředí s využitím nástroje PEAR na jiné umístění a který především postrádá smysl v produkčním prostředí. Adresář „document rootÿ je pak kořenovým adresářem z pohledu nasazení na webový server (obvykle Apache); kromě souborů s obrázky, kaskádovými styly a skripty javascriptu, je v něm i soubor index.php o jednoduchém obsahu:
6.1
Implementace
67
Autorizace a autentizace
S rozdělením na moduly pak těsně souvisí řešení omezení přístupu uživatelů. Podrobnější popis této základní funkctionality představí styl práce s frameworkem Nette. Kompletní popis celé aplikace by kladl značné nároky na velikost této práce. Přihlášený uživatel má přidělenou roli, umožňující přístup pouze k presenterům a tedy i akcím ze „svéhoÿ modulu. Jedná se o staticky definovaný ACL (Access Control List, seznam pro řízení přístupu), který znemožňuje hráčům přístup k sekci pro instuktory hry (a vice versa). Statické definování ACL v konkrétní třídě SimulACL je postačující, daná oprávnění se totiž nemohou ani u jedné role měnit. Autentizace a autorizace38 je do vniřní logiky Nette frameworku vytvoření odpovědi na HTTP požadavek zapojena přes konfigurační soubor a to následujícími direktivami (příčemž Authenticator a SimulACL jsou autorem napsané třídy, implementující rozhraní definované v Nette): service.Nette-Security-IAuthenticator = Authenticator service.Nette-Security-IAuthorizator = SimulACL Implementace tříd pro autorizaci pak vypadá následovně: 1 final class Authenticator extends BaseModel implements IAuthenticator { 2 3 /** @var UsersRepos */ 4 private $usersRepos = NULL; 5 6 public function getModel() { 7 if (!isset($this->usersRepos)) 8 $this->usersRepos = new UsersRepos(); 9 10 return $this->usersRepos; 11 } 12 38
Autentizace je proces ověření identity. K tomu se obvykle používá přihlašovací jméno a heslo. Autorizace je ověření oprávnění k nějaké akci. (Vrána, 2010, s. 377)
6.1
13 14 15 16 17 18
public function authenticate(array $credentials) { $login_email = $credentials[self::USERNAME]; $row = $this->model->getUserByLoginEmail($login_email); if (!$row) { throw new AuthenticationException("Uživatel s emailem ’$login_email ’ nenalezen!", self::IDENTITY_NOT_FOUND); }
if ($row->heslo !== $password) { throw new AuthenticationException("Zadali ste nesprávné heslo!", self::INVALID_CREDENTIAL); }
29 30 31 32 33 34 35 36 37 38 39 }
68
Implementace
if ($row->aktivni != "TRUE") { throw new AuthenticationException("Tento uživatel již nemá povolen přístup do systému.", self::INVALID_CREDENTIAL); } return new Identity($row->login_email, $row->role);
}
Zdrojový kód 1: třída Authenticator Statický ACL je pak definovám v rámci následující třídy: 1 final class SimulACL extends Permission { 2 3 public function __construct() { 4 // roles 5 $this->addRole(’guest’); 6 $this->addRole(’hrac’, ’guest’); 7 $this->addRole(’instruktor’, ’guest’); 8 9 // resources 10 //GAMER MODULE 11 12 $this->addResource(’Gamer_DefaultPresenter’); 13 $this->addResource(’Gamer_DecisionPresenter’); 14 //... zkráceno 15 16 // INSTRUCTOR MODULE 17
Zdrojový kód 2: třída SimulACL Aplikace autorizace a autentizace, pokud uživatel není přihlášen (není tato informace v session proměnné), je pak volána na základních presenterech daného modulu, tedy Gamer SecuredPresenter, resp. Instructor SecuredPresenter. Metoda startup() přetěžuje metodu předka, v tomto případě přes abstraktní třídu BasePresenter39 přetěžujeme metodu třídy abstraktní třídy Presenter, která již patří do samotného frameworku. Tato metoda je volána na samotném počátku životního cyklu každého presenteru a tedy je zajištěno, že každou „stránkuÿ bude možné zobrazit pouze je-li uživatel přihlášen a má přiřazenu adekvátní roli. Třída Environment pak též patří k Nette frameworku. 1 abstract class Gamer_SecuredPresenter extends { 2 3 public function startup() { 4 parent::startup(); 5 $user = Environment::getUser(); 6 7 if (!$user->isLoggedIn()) { 8 if ($user->getLogoutReason() === User::INACTIVITY) { 9 $this->flashMessage(’Uplynula doba neaktivity! Systém vás z bezpečnostných důvodů odhlásil.’, ’warning’); 10 } 39
Existuje, aby v ní byly registrovány Nette komponenty.
6.1
11 12 13 14 15 16
70
Implementace
$backlink = $this->getApplication()->storeRequest(); $this->redirect(’:Auth:login’, array(’backlink’ => $backlink)); } else { if (!$user->isAllowed($this->reflection->name, $this->getAction())) { $this->flashMessage(’Na vstup do této sekce nemáte dostatečné oprávnění!’, ’warning’); $this->redirect(’:Gamer:Default:default’); } }
17 18 19 20 } 21 22 //... zkráceno 23 }
Zdrojový kód 3: soubor SecuredPresenter.php V případě, že uživatel nemá práva, případně vypršela session, je přesměrován (buď přímo, redirectem na sdílený presenter za vnitřní Nette adresou :Auth:login, a nebo oklikou přes :Gamer:Default:default) na autentizační presenter, zobrazující samotný formulář pro přihlášení. Ten je sdílený pro oba moduly, po úspěšném přihlášení uživatele totiž pokračuje na domovskou stránku modulu podle své role. V rámci autentizačního presenteru je pak možné vidět přímočarou práci s HTML formuláři při využití frameworku Nette. 1 final class AuthPresenter extends BasePresenter { 2 3 /** @persistent */ 4 public $backlink = ’’; 5 6 7 public function startup() { 8 parent::startup(); 9 } 10 11 protected function createComponentLoginForm($name) { 12 $form = new AppForm($this, $name); 13 14 $form->addText(’login_email’, ’Email:’) 15 ->addRule(Form::FILLED, ’Prosím zadejte svůj přihlašovací email .’); 16 17 $form->addPassword(’heslo’, ’Heslo:’) 18 ->addRule(Form::FILLED, ’Prosím zadejte heslo.’); 19 20 $form->addProtection(’Prosím odešlete přihlašovací údaje znovu ( vypršela platnost tzv. bezpečnostního tokenu).’); 21 $form->addSubmit(’send’, ’Přihlásit!’); 22 $form->onSubmit[] = array($this, ’loginFormSubmitted’); 23 }
public function loginFormSubmitted($form) { try { $user = Environment::getUser(); $user->login($form[’login_email’]->value, $form[’heslo’]->value); $this->getApplication()->restoreRequest($this->backlink); if ($user->isInRole(’hrac’)) { $this->redirect(’:Gamer:Default:default’); }; if ($user->isInRole(’ucitel’)) { $this->redirect(’:Teacher:Default:default’); };
// Neočekává se, že by uživatel měl mít rolí více. // Tedy podle role je přesměrován na tu část, která mu "patří". } catch (AuthenticationException $e) { $form->addError($e->getMessage()); } } public function actionLogout() { Environment::getUser()->logout(); $this->flashMessage(’Právě jste se odhlásili.’); $this->redirect(’Auth:login’); }
Zdrojový kód 4: soubor AuthPresenter.php Je možné si všimnout, že je sice volána akce presenteru „loginÿ, ale není zde uvedena žádná metoda „actionLoginÿ – zatímco „actionLogoutÿ existuje. Akce „loginÿ tohoto presenteru sice vnitřním odkazem Nette :Auth:login volána je, ale v tomto případě zde není žádná aplikační logika, pouze zobrazení formuláře pro přihlášení. Nette v rámci životního cyklu presenteru proto zobrazí šablonu login.phtml, s instancí formuláře definovaného v metodě createComponentLoginForm. 1 2 3 4 5
V šabloně je vidět použití jak čistého HTML kódu, tak šablonovacího jazyka Latte (Nette šablony). Řádek {widget loginForm} způsobí volání metody createComponentLoginForm, tedy vytvoření instance formuláře, který šablonovací systém umí zobrazit. Je zde též vidět, že kód související s přihlašovacím formulářem je definován v bloku (s názvem content). Díky vlastnosti šablonovacího jazyka Latte, dědičnosti šablon, je možné definovat základní šablonu (např. @layout), ve které je použita deklarace bloku {include #content} a na jeho místo se pak dosadí kód v bloku content z té které konkrétní šablony. Je tedy možné snadno izolovat znovupoužitelný kód i na úrovni presentační vrstvy. Šablona pro danou akci může tedy být velmi stručná, protože blok content je vložen do nadřízené šablony @layout.phtml, definující celou html stránku včetně hlavičky, menu, patičky atd. (zde byl využit css grid layout 96040 ). Po vyplnění jména a hesla a odeslání formuláře je pak uživatel přesměrován zpět na původní stránku (volání restoreRequest a hodnotě URL uložené v persistentním atributu backlink), kterou chtěl vidět a kde selhala autentizace a autorizace – nyní ale s novými údaji v session o tom, zda je daný uživatel přihlášen a jakou má roli. Authenticator opět ověří údaje ze session proti statickému ACL a pokud je uživatel autentizován a autorizován, je mu zobrazena požadovaná stránka. Další kontroly jsou pak již řešeny na úrovni konkrétního presenteru. Jde především o dotaz na stav běhu a kola (workflow běhu hry) pro mnoho akcí; u presenterů v modulu Gamer ještě navíc kontrolní dotaz zda hráč je k dané firmě či týmu přiřazen a může tak provádět danou akci (obrana proti jednoduché změně URL s cílem ovlivnění cizí firmy nebo týmu).
6.2
Výpočet výsledků
V tomto oddíle bude stručně popsán postup vytváření výpočtů. Ukázku v současnosti používaného řešení v tabulkovém procesoru je možné vidět na obrázku č. 19. Algortimus výpočtů jednotlivých kroků bylo nutné zjistit reverzním inženýrstvím z dodaných souborů a v některých případech přímou konzultací se zadavatelem. Na nejvyšší úrovni se tvorba výsledků firmy skládá z následujících kroků: 1. 2. 3. 4. 5. 6. 7.
Výpočet personálního indexu (PI) a vliv na absence pracovníků. Výpočet výroby s přihlédnutím k absencím pracovníků. Změna počtu strojů a pracovníků. Výpočet prodeje firmy na trhu. Změna stavu skladů (výroba, prodej). Výpočet informací pro Výkaz zisků a ztrát, účetnictví, výpočet daní. Výpočet informací pro Cash flow, účetnictví, stav pokladny.
Detaily výpočtů v této práci autor práce neuvádí, neboť jde o část manažerské hry, která není zveřejňována hráčům. Byla vytvořena třída Resolver, odpovída40
viz http://960.gs/
6.2
Výpočet výsledků
73
jící zpracování výsledků v tabulkovém procesoru a mající odpovědnost za provedení výpočtů výsledků jako celek (vstup dat, zpracování, výstup). Dílčí algoritmy výpočtů výsledků však deleguje další třídy. První je třída GameAlgoritms, která se skládá pouze ze statickým metod; byl zde proveden refactoring „extract methodÿ, popsaný například v (Trucchia, Romei, 2010, s. 85). Jednotlivé elementární výpočty je tak možné pokrýt automatickými jednotkovými testy za pomocí nástroje PHPUnit41 . Další třídy ProductionResolver a MarketResolver pak odpovídají za výpočet správné výroby firmy i v případě nedostatku pracovníků a výpočtu střetu herních firem na trhu. Ukázka použití automatických testů pro kontrolu správnosti výpočtů výsledků: 1 class GameAlgorithmsTest extends PHPUnit_Framework_TestCase 2 { 3 /** Test spravneho vypoctu nakladu (kontrola spravne slevy za hromadny nakup. 4 * Konstanty ktere ovlivnuji tento test 5 * CResolverAccounting::SLEVA_NAD_STO_TUN_PREDOBJEDNAVKY 6 * CResolverAccounting::MINIMALNI_OBJEM_PRO_SLEVU 7 * 8 * Spravne hodnoty spocteny mimo, takze po zmene techto dvou konstant bude test padat. 9 * 10 * @test 11 * @dataProvider providerFor_NakladyZaNakupSurovinPredobjednavkou 12 */ 13 public function testNakladyZaNakupSurovinPredobjednavkou($mnozstvi, $cena, $ocekavanyVysledek){ 14 $aktualniVysledek = GameAlgorithms:: nakladyZaNakupSurovinPredobjednavkou($mnozstvi, $cena); 15 $this->assertEquals($ocekavanyVysledek,$aktualniVysledek); 16 } 17 18 public static function providerFor_NakladyZaNakupSurovinPredobjednavkou(){ 19 return array( 20 21 array(10,2,20), objednavka mensi nez 100 tun) 22 array(100000,1,90000), presne za 100 tun. ocekavame slevu 10 procent 23 array(110200,2,198360), vetsi nez 100 tun , ocekavame slevu 10 procent 24 ); 25 } 26 }
Zdrojový kód 6: Jednotkový test třídy GameAlgoritms 41
Url projektu www.phpunit.de
6.3
6.3
Úprava existujících pravidel.
74
Úprava existujících pravidel.
Základní požadavek byl samozřejmě implementovat nové podpory podle aktuálních pravidel, popsaných v dokumentu pro hráče. V průběhu implementace však byly provedeny určité zlepšující úpravy v pravidlech hry, samozřejmě po schválení vedoucím práce, budoucím uživatelem systému. Seznam provedených změn je možné nálezt v příloze E. Některé změny se týkají spíše oblasti organizace sehrávky hry, jiné upravují základní herní mechanismy a v důsledku způsob výpočtu výsledků. Provedenými změnami se pak mírně zkomplikovala verifikace vytvořeného řešení. Označíme-li stávající pravidla za verzi pravidel 1.0, po odsouhlasení těchto změn dostáváme novou verzi pravidel 1.1. Při stejných vstupních údajích (data běhu hry a rozhodnutí hráčů) pak dostáváme rozdílné výsledky pro firmu ve starší a novější verzi pravidel, což je očekávaný výsledek. Pro kontrolu správnosti výsledků proto byly provedeny úpravy řešení v tabulkovém procesoru na straně budoucích uživatelů a zkontrolována jejich shoda s výsledky generovanými řešením popsaným v rámci této práce. V rámci předávky verze R021 bylo prakticky ověřeno, že nové podpory manažerské hry vytváří očekávaná výstupní data.
7
ZHODNOCENí VÝSLEDKŮ A DALŠí MOŽNÝ ROZVOJ
7 7.1
75
Zhodnocení výsledků a další možný rozvoj Vytvořená webová aplikace
Největší potíží stávajících podpor při zpracování výsledků je časová náročnost tohoto procesu. Tvorbou výsledků pro jeden trh stráví akademický pracovník zhruba patnáct minut času. Výpočet výsledků pro jeden trh v rámci této nové webové aplikace trvá dobu kratší než jedna sekunda. Úspora času je tedy značná, i když v současné podobě aplikace je možné spouštět výpočet pouze nad daným trhem. Tato úspora je pak hlavní výhodou nového systému podpor manažerské hry „Výroba nábytkuÿ. Protože došlo k převedení všech aktivit souvisejících se sehrávkou hry do vytvářené aplikace, je nutno porovnat časovou náročnost i souvisejících procesů. První zásadní časově náročný úkol je organizace hráčů na začátku hry. Ve stávajících podporách hry týmy vzniknou na cvičení a jsou evidovány nezávisle na hře samotné; důležité je pouze předání hesla danému týmu pro možnost zadávání rozhodnutí za určitou firmu. První verze nové aplikace se držely současného stylu přesně, na trhu tedy existovalo pět firem a bylo nutné přiřazovat hráče k jednotlivým firmám. To se ukázalo pochopitelně jako časově velmi náročné při běžných počtech studentů předmětu, byla proto provedena úprava chování nové aplikace do současné podoby: hráči vytvářejí týmy samostatně, instruktor definuje rozsah možného počtu firem na daném trhu a aplikace dokáže sama vytvářet firmy a přiřazovat je k týmům podle definovaného rozsahu. Instruktor tak řeší pouze vyjímečné stavy, které skutečně vyžadují lidský zásah. V této oblasti tedy k žádnému markatnímu nárustu časové náročnosti nedošlo. Časově nejnáročnějším procesem se tak v nových podporách hry stalo až samotné definování všech podkladových údajů pro běh hry – ostatně požadavek na zlepšení tohoto problému je identifikován jako REQ-045. Jelikož však toto je nutné dělat pouze jednou za semestr a navíc je možné data běhu hry zkopírovat z minulého semestru systémovým administrátorem na úrovni databáze, nejedná se o zásadní problém, bránící nasazení nových podpor. Jedinou nevýhodou přechodu do nově vytvořených podpor je tak reálná ztráta flexibility v podobě snadnosti úprav modelu simulace implementovaného v excelu. Například jednoduché nové pravidlo, množstevní slevy průzkumů trhů podle počtu kol, je možné doplnit do modelu v excelu prakticky okamžitě. Pro doplnění téhož pravidla do webové aplikace je zapotřebí jednak více času (programování, testování, nasazení nové verze) a jednak je zapotřebí zkušeností programátora.
7.2
Nedokončené požadavky
Některé z požadavků, popsaných v oddíle 5.2 nebyly v době psaní této práce implementovány, je však vhodné (požadavky instruktorů) případně přímo nutné (sekce pro hráče) jejich dokončení pro možnost beta testování na vzorku budoucích uži-
7.3
Nasazení aplikace
76
vatelů (tedy studentů–dobrovolníků) a následné ostré nasazení. Jde o následující požadavky: U sekce pro hráče není splněn požadavek REQ-017 – momentálně jsou zobrazovány výsledky pouze v „surovéÿ podobě. Je zapotřebí je upravit do očekávavané podoby účetních výkazů. REQ-022 pak přímo navazuje na předchozí uvedený nedokončený požadavek. Pro instruktory pak chybí implementace následujících požadavků. • REQ-041 – smazání trhu bylo identifikováno jako okrajový případ, který je možno vyřešit přímým zásahem databázového administrátora; přesto však by tato funkcionalita měla být zpřístupněna s patřičnými kontrolami na již existující data (přiřazené firmy). • REQ-042 – zde dosud nebylo ani dodáno jaké statistiky by vlastně měly být počítány; je nicméně možné je získat zprostředkovaně, použitím exportu dat z databáze do formátu vhodného pro zpracování tabulkovým procesorem. • REQ-044, REQ-045, REQ-046 – tyto požadavky jsou pak velmi „čerstvýmiÿ požadavky, byly identifikovány při předávce na konci iterace vedoucí k verzi R022 a jsou v době psaní této práce teprve analyzovány. Mimo zásadní identifikované požadavky jsou určité oblasti aplikace, které by zasloužily v podstatě zlepšující úpravy v určitých detailech. Za prvé, jde o úpravy za účelem lepšího vzhledu. Bylo by vhodné zlepšit uživatelskou přívětivost lepší strukturalizací odkazů v navigaci, přidáním ikon pro odkazy na jednotlivé akce apod. V sekci pro vedoucí by pak bylo vhodné přidat funkcionalitu pro spuštení generování výsledků pro všechny existující trhy v rámci běhu hry – tento požadavek zatím nevzniknul, lze ho ale očekávat při praktickém používání. Poptávka na trhu by pak měla být definována jako klesající křivka, nikoliv klesající přímka (jak je uvedeno v příloze E].
7.3
Nasazení aplikace
Vytvářená aplikace byla testována při nasazení na webhostingu autora této práce.42 V době psaní této práce není zřejmé kdy a na jaký server bude nasazena pro ostrý provoz, tedy k využití v rámci výuky předmětu Strategický management na Ústavu managementu. Pro ostré nasazení je pak nutné dokončit některé úkoly, popsané v předchozím oddíle 7.2, ale též aktualizovat popis pravidel hry pro studenty podle změn uvedených v příloze E. Nejbližší možné ostré nasazení je tedy možné vidět v rámci zimního semestru akademického roku 2012/2013, to za předpokladu, že bude v létě roku 2012 proveden betatesting na menší skupině (např. v rámci Ústavu managementu). 42
Verze shodná s popisovanou viz www.othersideworlds.eu/diplomka
7.4
Možnosti dalšího rozvoje
7.4 7.4.1
77
Možnosti dalšího rozvoje Automatické testy
V rámci omezeného množství času bylo preferováno manuální testování, zvláště vzhledem k častým změnám po průběžných ukázkách aplikace po konci iterací. Bezesporu by mělo být napsáno větší množství jednotkových testů, pokrývají pouze část aplikace a to ne zcela úplně. Po dokončení psaní jednotkových testů je vhodné začít měřit míru pokrytí testy (code coverage). Správnost těchto testů by pak též měla být ověřena pomocí mutačního testování.43 Integrační testování (ve vztahu k databázi, pomocí rozšíření DBunit pro framefork PHPUnit) též neodpovídá rozsahu projektu. V rámci posilování integritních omezení na databázi a právě ve vztahu s integračním testováním je vhodné zavčasu porovnat výhody a nevýhody přechodu z databázového systému MySQL na PostgreSQL. Co se týče akceptačního testování, použití nástroje SeleniumIDE je pak pouze krátkodobé řešení (získání pokrytí testy rychleji a s menší námahou než psaním vlastních testů), akceptační testy by měly být přepsány pro SeleniumRC pro lepší dlouhodobou udržovatelnost. Jelikož nebyl prakticky zapotřebí server kontinuální integrace (z důvodu vývoje jedním člověkem), úvahy o přepsaní testů pro SeleniumRC byly též odloženy, neboť s rozhodnutím o CI serveru úzce souvisí. Jako první možnost lze využít buď pouze frameworku PHPUnit (přimočaré využití PHP) případně v kombinaci s nástrojem Behat. Do projektu se tak sice kromě PHP objeví nutnost instalace Javy pro účely testování, nicméně samotný kód testů bude v PHP, stejně jako sama aplikace. V takovém případě pak má větší smysl využívat server kontinuální integrace též napsaný v jazyce PHP, jako například Xinc nebo Cintient, a pochopitelně build skripty psát s využitím Phingu. Toto rozhodnutí zjednoduší situaci, kdy projekt bude nucen udržovat a rozvíjet další programátor, neboť snižuje požadavky na něj kladené. Též klade menší nároky na servery pro podporu vývoje než druhá varianta. Druhou možností je totiž napsání akceptačních testů s využitím frameworku JUnit v jazyce Java nebo Groovy – přičemž Groovy je pro svoji povahu skriptovacího jazyka bližší logice použití jazyka PHP. Druhá možnost vyplývá z úvahy, že SeleniumRC je napsán v Javě a tím pádem zařazení Javy do projektu se není možné vyhnout. Použitím testů psaných v jazyce Groovy a frameworku JUnit (místo PHP a PHPUnit) je pak možné využívat další pokročilé nástroje z ekosystému platformy Java pro lepší akceptační testy webových aplikací – například Fitnesse či Concordion. Dalším zajímavým nástrojem na platformě Java je pak testování databáze pomocí nástroje DBSanity. Při silné pozici Javy v projektu by pak mělo smysl uva43
Mutační testování (mutation testing) se snaží ověřovat dobrou kvalitu automatických testů tím, že do testované aplikace zavádí úmyslné chyb, resp. malé změny kódu (nazývané mutacemi) a pozoruje jejich efekt na výsledky reportované testy. Příkladem jednoduché mutace je záměna operátoru sčítání na odčítání. Po takové změně by správně napsaný test měl zahlásit neúspěch a pokud tedy po změně testovaného systému stále prochází v pořádku, není napsát správně.
7.4
Možnosti dalšího rozvoje
78
žovat spíše o nasazení serveru kontinuální integrace Jenkins (který značně překonává oba výše zmíněné PHP CI servery) a build systému Ant. 7.4.2
Refactoring
Pod pojmem refactoring je myšlena úprava návrhu, architektury i samotného kódu ve smyslu úpravy vnitřní struktury programu, nicméně bez změny vnějšího chování (Trucchia, Romei, 2010, s. 25). Účelem takové změny je snížení nákladů na další rozvoj a udržbu software. V aktuální verzi R022 jsou známa místa v kódu, která by bylo vhodné přepsat do lepší podoby. Jde o místa označenená úkolovými komentáři (TODO, FIXME), kdy moderní IDE a nástroje statické analýzy kódu dokáží vygenerovat seznam úkolu s odkazy do kódu. Druhým známým místem pro refactoring je závislost presenterů na modelech, kdy v každém presenteru je vytváření tříd modelů stylem „Factory methodÿ – zde by bylo vhodné opakující se kód vyjmout do nové třídy a nebo zavést princip zvaný „Dependency injectionÿ. Právě znalost tohoto faktu vynutila zpřísnění kritérií pro statickou analýzu nástrojem phpcpd, jak je popsáno v příloze I, neboť v základním nastavení tyto známé duplicity nedetekoval. Zásadnějším refactoringem je pak v důsledku rozhodnutí o přechodu na novou stabilní verzi frameworku Nette a PHP 5.3. Tato úvaha však závisí na míře očekávaného dalšího rozvoje aplikace, tedy především rozsahu změn pravidel hry. Pokud bude aplikace pouze udržována ve smyslu výše popsaných drobných úprav a oprav případných chyb, je přínos takto zásadního refactoringu diskutabilní. Výhody aktualizace na nejnovější verze frameworku a jazyka se projeví spíše při intenzivnějším rozvoji aplikace. 7.4.3
Možný rozvoj aplikace v závislosti na rozvoji pravidel
Tato práce má jako hlavní cíl vytvoření lepších podpor manažerské hry, tedy současná pravidla bere jako pevné zadání (resp. pravidla hry nebyla změněna jinak než jak bylo popsáno v oddíle 6.3). V průběhu implementace nových podpor i studiem literatury však vzniklo velké množství nápadů na další zlepšování pravidel manažerské hry. Bližší popis identifikovaných problémů a návrhů na změnu viz příloha F. Další rozvoj aplikace pak přímo souvisí s rozhodnutím, zda vůbec dále upravovat pravidla hry a pokud ano, tak jakým způsobem
8
8
ZÁVĚR
79
Závěr
V úvodu této diplomové práce byly stanoveny cíle, kterých jsem chtěl dosáhnout. Hlavním cílem bylo vytvořit novou webovou aplikaci, která sníží časovou náročnost tvorby výsledků manažerské hry „Výroba nábytkuÿ, používané na Ústavu managementu. Při použití dosavadního způsobu trvá akademickým pracovníkům při nejčastějšímu počtu dvaceti trhů po pěti firmách tvorba výsledků jednoho kola hry zhruba pět hodin. Tvorba výsledků v totožné situaci při použití nově vytvořené webové aplikace je záležitostí maximálně na dvě minuty práce. Úspora času automatizací nezbytných kroků je tedy zřejmá. Troufám si proto tvrdit, že tohoto cíle jako celku se mi podařilo dosáhnout, i když určité dílčí funkcionality aplikace ještě zbývá dokončit pro možnost reálného použití. K dosažení tohoto cíle bylo použito reverzní inženýrství již existujících podpor manažerské hry, kdy na základě prozkoumání existujícího řešení byly identifikovány nutné požadavky na funkčnost a základní struktura datového modelu. Bylo též zváženo dokončení existujícího prototypu a tato varianta byla zavržena, přednost získala varianta tvorby zcela nové aplikace. Využitím existujícího open-source kódu (framework, komponenty, CMS GetSimple) i dalších podpůrných nástrojů pro vývoj bylo možné zefektivnit práci při programování i testování této aplikace a zkrátit dobu pro její vytvoření. Dílčí cíl ověření praktické použitelnosti pak byl proveden za účasti některých z budoucích uživatelů systému (doc. Ing. Pavel Žufan, Ph.D. a Ing. Tomáš Pyšný, Ph.D.). Bylo ověřeno, že výsledky vypočtené vytvořenou aplikací odpovídají stávajícímu řešení v tabulkovém procesoru (při zapracování popsaných úprav pravidel). Bylo též vyzkoušeno praktické použití v rámci celého životního cyklu sehrávky manažerské hry. Jmenovitě od vytvoření nového běhu hry a naplnění nezbytnými daty, přes tvorbu hráčských týmů, zahájení sehrávky, zadávání rozhodnutí hráči a tvorbu výsledků instruktory, až po uzavření posledního kola a ukončení běhu hry. Při dokončení nemnoha zbývajících funkcionalit je tedy možné opustit stávající řešení podpor této hry. Kromě naplnění v úvodu stanovených cílů mne osobně tvorba této práce obohatila o řadu zkušeností, které je možné dále využít při podobných projektech, ať už má role v rámci vývoje a údržbě určitého softwaru bude jakákoliv.
9
9
LITERATURA
80
Literatura
Beck, K., Andres, C. Extreme Programming Explained: Embrace Change, Second Edition. Addison-Wesley, 2004. 224 s. ISBN 0-321-27865-8. Burnstein, I. Practical Software Testing Springer-Verlag. 2003. 709 s. ISBN 0387-95131-8. Cohn, M. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004. 304 s. ISBN 978-0321205681. Fowler, M. UML distilled: a brief guide to the standard object modeling language, 3rd ed.. Pearson Education, 2004. 175 s. ISBN 0-321-19368-7. Goodliffe, P. Code craft: the practice of writing excellent code. No Starch Press, 2006. 580 s. ISBN 978-1-59327-119-0. Groff, J. R., Weinberg, P. N. SQL Kompletní průvodce CP Books. 2005. 936 s. ISBN 80-251-0369-2. Highsmith, J. Agile Software Developement Ecosystems. Addison Wesley, 2002. 448 s. ISBN 0-201-76043-6 . Hlavenka, J. a kol. Výkladový slovník výpočetní techniky a komunikací. Computer Press, 1997. 452 s. ISBN 80-7226-023-5. Chacon, S. Pro Git. CZ.NIC 2009. 263 s. ISBN 978-80-904248-1-4. Johnson, G., Scholes, K. Cesty k úspěšnému podniku. Computer Press. 2000. 801 s. ISBN 80-7226-220-3. Mitchell, L., Shafik, D., Turland, M. EPHP Master: Write Cutting-edge Code. SitePoint Pty. Ltd., 2011. 375 s. ISBN 978-0-9870908-7-4. Myers, G. J. The Art of Software Testing John Wiley & Sons. 2004. 234 s. ISBN 0-471-46912-2. Pressman, Roger S. Software Engineering: a practicioner´s approach McGrawHill. 2001. 854 s. ISBN 0-07-365578-3. Pezlar, Z. Systémové inženýrství Konvoj. 1999. 35 s. ISBN 80-85615-88-6. Richardson, J. R., Gwaltney, W. A. Ship It! A Practical Guide to Successful Software Projects. The Pragmatic Programmers LLC, 2006. 186 s. ISBN 09745140-4-7. Schmuller, J. Myslíme v jazyce UML. Grada, 2001. 359 s. ISBN 80-247-0029-8. Shore, J., Warden, S. The Art of Agile Development. OŔeilly Media, Inc., 2008. 409 s. ISBN 978-0-596-52767-9. Smutný P. Simulační hry jako nástroj zvyšování kvality lidského kapitálu podniku. Disertační práce. Brno, 2007. 174 s. Stránský, L. Analýza a návrh simulační hry Ústavu managementu PEF MZLU v Brně. Diplomová práce. Brno, 2008. 60 s. Šimůnek, M. SQL Kompletní kapesní průvodce. Grada, 1999. 248 s. ISBN 80-7169692-7. Tichý, J. Programová podpora tvorby webových aplikací. Diplomová práce. Praha, 2004. 66 s.
9
LITERATURA
81
Trucchia, F., Romei, J. Pro PHP Refactoring Apress. 2010. 335 s. ISBN 978-14302-2727-4. Vrána, J. 1001 tipů a triků pro PHP Computer Press. 2010. 456 s. ISBN 978-80251-2940-1. Welling, L., Thomson, L. PHP and MySQL Web Development. Addison-Wesley, 2009. 968 s. ISBN 978-0-672-32916-6.
Přílohy
A
A
STÁVAJíCí WEBOVÉ ROZHRANí
Stávající webové rozhraní
Obr. 15: Stávající webové rozhraní — formulář pro zadání rozhodnutí firmy
83
B
B
NÁVRH DATABÁZOVÉHO SCHÉMATU V PRVNíM PROTOTYPU
84
Návrh databázového schématu v prvním prototypu
Obr. 16: Návrh databázového schématu v prvním prototypu. Zdroj (Stránský, 2008, s. 45)
C
C
NÁVRH DATABÁZOVÉHO SCHÉMATU V PRVNíM PROTOTYPU
85
Návrh databázového schématu v prvním prototypu
Obr. 17: Relační schéma pro aplikaci Výroba nábytku ve verzi R022
D
D
UKÁZKA STÁVAJíCíHO ŘEŠENí TVORBY VÝSLEDKŮ
Ukázka stávajícího řešení tvorby výsledků
Obr. 18: Systém souborů tabulkového procesoru pro jeden běh hry
86
D
UKÁZKA STÁVAJíCíHO ŘEŠENí TVORBY VÝSLEDKŮ
Obr. 19: Ukázka zpracování výsledků pro daný trh a kolo
Obr. 20: Výsledky kola pro hráče - část č. 1
87
D
UKÁZKA STÁVAJíCíHO ŘEŠENí TVORBY VÝSLEDKŮ
Obr. 21: Výsledky kola pro hráče - část č. 2
88
E
E
PROVEDENÉ ÚPRAVY PRAVIDEL V RÁMCI IMPLEMENTACE NOVÝCH PODPOR
89
Provedené úpravy pravidel v rámci implementace nových podpor
Akutní nákup surovin. Výroba bude více realističtější, když se ve výpočtu vyrobených kusů plán nebude zpětně přizpůsobovat realitě, ale když bude realita nezávislá na plánu. V současných pravidlech nákup surovin ovlivňuje plán výroby, hráči ale spíše chybně spočítají nákup surovin než určí kolik chtějí vyrobit kusů kterého výrobku. V nových podporách je tedy možné vyrábět i s prázdnými sklady surovin a nakupovat suroviny „akutněÿ, s příplatkem. Plán výroby se redukuje pouze při nedostatku pracovníků, nyní již není možnost vzniku situace s nedostatkem surovin. Odstranit zpoždění v prodeji výrobků. V současných pravidlech platí, že je možné prodávat výrobky nejdříve v následujícím kole. Vzhledem k tomu, že ve hře odpovídá jedno kolo čvrtletí, bylo dohodnuto, že výrobky mohou jít do prodeje na trhu již v kole, ve kterém byly vyrobeny. Tato úprava ovlivňuje jak tržby, tak výpočet skladovacích nákladů v daném kole. Poptávka na trhu definována poptávkovou křivkou. Ve výpočtu pomocí tabulkového procesoru je poptávka popsána hodnotami v deseti bodech (cena) a interpolována pro hodnoty mezi nimi. Tento způsob zápisu byl převeden na definici poptávky pomocí poptávkové křivky. V době psaní této práce je použito definování dvěma body (tedy poptávková přímka) z důvodů jednoduší verifikace nových podpor proti upravenému stávajícímu řešení. Jedním z návrhů dalších zlepšení aplikace je přidání možnosti definovat poptávku třemi body, jako skutečnou křivku poptávky, společně s vizualizací dat pomocí grafu. „Prodej daného počtu kusůÿ upraven na „podržet procento na skladechÿ . Aktuálně hráči určují jak prodejní cenu daného druhu výrobku, tak množství, které nabízí na trh. Mechanismus určení prodejního množství umožňuje hráčům si připravit výrobky „do zásobyÿ, pokud se rozhodnou, že je to výhodná strategie vzhledem k provedeným průzkumům trhu. Problém však je, že hráči podléhají fundamentální nejistotě kolik se vlastně vyrobí kusů (mohou být absence pracovníků, ovlivňující vyrobené množství), ale prodejní množství se uvádí přesně. Obvyklejší způsob uvažování bývá „chci prodat všeÿ nebo „chci udržet polovinu na skladech na pozdějiÿ. V nových podporách se tak množství nabízené na trh spočítá nepřímo, neboť hráč uvádí v rozhodnutí procento výrobků (již ve skladech plus vyrobených v aktuálním kole), které chce podržet na skladech. Byl zásadně změněn algoritmus střetu firem na trhu. Model střetu firem na trhu je popsán ve stávajícím řešení v tabulkovém procesoru pomocí algoritmu počítajícího s průměrnou cenou a odchylkami jednotlivých firem od ní a zároveň uvažuje
E
PROVEDENÉ ÚPRAVY PRAVIDEL V RÁMCI IMPLEMENTACE NOVÝCH PODPOR
90
jak moc je která firma „silnáÿ, tedy jaký má podíl na trhu. Toto řešení má jednu zásadní nevýhodu. Při průzkumu testovacích scénářů byl objeven fakt, že ve výpočtu nedochází ke střetu poptávky a nabídky, ale že poptávka je ovlivněna nabídkou. Například v situaci naprosto shodných prodejních cen, vyrobí-li firmy objem produkce převyšující definovanou poptávku při dané ceně, poptávka se ve výpočtu v důsledku posune a firmy prodají objem v součtu převyšující právě onu instruktorem definovanou poptávku při dané ceně; tím se narušuje smysl definování poptávky jako omezení na daném trhu. Bohužel v situaci, kdy existuje poptávková křivka, ale nabídka je tvořena firmami, kdy každá nabízí individuální množství a cenu, neexistuje jednoznačné řešení střetu poptávky a nabídky v rámci základní mikroekonomické teorie. Vzhledem k procesu validace nových podpor byl navrhnut jiný algoritmus výpočtu střetu na trhu, nicméně jednoduše implementovatelný i v tabukovém procesoru. Je využito faktu, že díky rozdílné prodejní ceně se situace na trhu přibližuje k monopolistické konkurenci, neboť cena je v současných pravidlech hry jediný faktor střetu firem na trhu daného výrobku. Cenový vůdce (který není určen pouze na základně nejnižší ceny, ale též musí splnit podmínku minimálního podílu objemu produkce na trhu) pak určuje velikost konkrétní poptávky pro všechny firmy na trhu (z poptávkové křivky pro trh). Neboli situace jako kdyby daný počet lidí byl zlákán cenovou nabídkou vůdce a logicky by chtěli koupit za danou cenu. Konkrétní velikost poptávky pro všechny firmy na trhu je pak dále upravována podle cen jednotlivých firem (vliv konkurence), čímž vznikají individuální poptávky po nabídce dané firmy. Tato oblast by si zajisté zasloužila podrobnější popis, ale jedná se o část hry, která není zveřejňována hráčům. Upraven výpočet skladovacích nákladů. Zvýšení skladovacích nákladů změnou jejich výpočtu — nikoliv dle stavu na konci kola, ale dle průměrného stavu skladů (dle základního modelu teorie zásob EOQ). To velmi neodpovídá uvažované situaci, že v daném kole se vyrábí a prodává, přičemž firma platí skladovací náklady za průběh tohoto období. V současném výpočtu výsledků se uvažuje pouze koncový stav skladů pro určení skladovacích nákladů. Podle modelu EOQ se v nových podporách počítá s průměrným stavem skladů, neboli počáteční stav, plus výroba, mínus polovina prodeje. Ceny surovin upraveny na celočíselné. Protože ceny surovin byly jediné proměnné v pravidlech, které mohly nabývat desetinných čísel (9 korun a 20 haléřů), bylo odsouhlasena změna na celočíselné. Tato úprava značně zjednodušila návrh databázového schématu pro data související s tvorbou finančních výkazů. Daň státu bude placena v každém kole, čtvrtletní odchozí platby. V rámci aktuálních pravidel se daně platí až za celý rok, jsou tedy spočteny a placeny pouze v každém čvrtém herním kole; byla však odsouhlasena změna na platbu daní v každém kole. K této změně existuje více důvodů. Hráči začínají s firmou s daným
E
PROVEDENÉ ÚPRAVY PRAVIDEL V RÁMCI IMPLEMENTACE NOVÝCH PODPOR
91
počátečním stavem, tj. s poměrně velkým stavem hotovosti, ale též se značnými daněmi k zaplacení. Musí ale postřehnout jednu větu v pravidlech, která toto zmiňuje. Placení daní ve smyslu čvrtletních odvodů je přitom lépe pochopitelné, více odpovídá realitě a nevytváří značné výkyvy v cash flow. Daň v nových podporách je tedy spočtena v rámci výsledků daného kola jako pohledávka finančního úřadu a je zaplacena v rámci kola následujícího. Volitelný počet firem na trhu Stávající pravidla hry očekávala konstantní počet pěti firem přiřazených k danému trhu. V praxi tak docházelo k situaci, že k již tak velké časové náročnosti pro instruktory se ještě přidávala nutnost vytvářet rozhodnutí za iluzorní firmy, protože ne vždy je počet firem dělitelný pěti. Vzhledem k příchozímu požadavku na vytvoření funkcionality samoorganizace firem byla implementace vytvořena s flexibilnějším přístupem, kdy počet firem u trhu je možno definovat rozsahem od-do, a to pro každý trh zvlášť. To efektivně řeší dřívější situaci „nedělitelnosti pětkouÿ. Upraveny některé konstanty hry. Jde o úpravu hodnot konstant vzhledem k dříve uvedeným úpravám. Jde například o snížení spotřeby surovin ve výrobě, sazba daně, skladovací náklady, slevy za nákup nad sto tun atd. Jelikož veškeré takovéto hodnoty jsou implementovány v PHP jako konstanty, je jejich případná další korekce triviální záležitostí.
F
NÁVRHY PRO NOVÁ PRAVIDLA HRY
F F.1 F.1.1
92
Návrhy pro nová pravidla hry Kritika současných pravidel Kritická analýza možných strategických rozhodnutí podle Portera
Manažerská hra „Výroba nábytkuÿ je využívána v rámci výuky předmětu Strategický managament. Jedním z nástrojů strategické analýzy je Porterův diagram pěti sil. Použiji ho v rozšířené podobě jako nástroj na otestování této hry, v podobném duchu jako se v matematické analýze koná důkaz sporem. Nakolik je totiž jeden ze základních analytických nástrojů na tento model použitelný bude dávat představu o strategických možnostech v rámci těchto pravidel a tedy o kvalitě hry pro účely výuky. Tato metoda strategické analýzy byla zvolena z toho důvodu, že se vyhodnocuje těsné okolí firmy na trhu a rizika vyplývající z těchto směrů — a tyto síly v rámci modelu hry existují, třebaže v redukované podobě. Konkurenční prostředí se podle Porterova diagram pěti sil se pak podle (Johnson, Kevan, 2000, s. 100) skládá z následujícího: Dodavatelé Na trhu je jenom jeden dodavatel s neomezenou kapacitou, společný pro všechny hráčské firmy. Jediná hrozba z této strany je možná fluktuace cen surovin, které ovšem všichni podléhají stejně. Vemi mírné riziko je pouze v případě, že se hráči rozhodnou nezjistit ceny surovin na další herní kola a přijdou tak o možnost vytvořit si dostatečnou zásobu surovin za nižší cenu. Je na instruktorech hry, jak velké fluktuace cen surovin budou. Potencionální konkurenti Nulové riziko, neboť nové firmy v průběhu hry na trh přicházet ani nemohou. Na trhu existují pouze hráčské firmy a dělí se spolu o celý trh. Substituty, Komplementy Na trhu se prodávají pouze dva typy výrobků, oba v možnostech výroby každé firmy. Neexistují žádné jiné produkty jako substituty ani žádné další produkty na jiných trzích nejsou komplementí, aby firmu mohla ohrozit změna ceny nějakého jiného produktu. Strategické možnosti jsou tím pádem omezeny tím, k jakému trhu je přiřazena – nemá oproti realitě možnost zkusit prodávat na trhu, který je méně zaplněn. Odběratelé, Zákazníci Je tu určitá síla tohoto faktoru, protože je difinován potenciál trhu pro oba produkty při určité ceně, a tento potenciál trhu v čase podléhá změnám. Firmám je přímým vstupem pro rozhodnutí o velikosti výroby a prodejní ceně a tvoří tak klíčovou hodnotu, kterou hráči obvykle sledují. Instruktoři definují průběh (trend) potenciálu v průběhu hry pro jednotlivá kola a nutí tak při plných informacích hráče rozvažovat o dlouhodobém plánu výroby. Změna potenciálu trhu v průběhu sehrávky po provedeném průzkumu trhu, tedy ve smyslu nečekané fluktuace na trhu, není řešena. Je to naopak faktor s možná až příliš velkou silou, protože na firmy má přímo zásadní vliv, firmy však nemají jinou možnost než ho přijmout a v rámci omezených možností výrobní struktury na něj reagovat. Není možné se přesunout na jiný trh, není
F.1
Kritika současných pravidel
93
možné otevřít nový trh vývojem nových výrobků, nelze bojovat o zákazníka jinak než cenově. Stávající konkurenti Ti jsou jedinou další silou, se kterou je nutné při rozhodování uvažovat. Vzhledem k omezeným možnostem modelu se však všichni konkurenti stávají prakticky zaměnitelnými a tím každá firma o ostatních konkurentech uvažuje, nemá však možnost riziko snížit nějakou další analýzou. Je sice možné získat informace o prodejních cenách ostatních firem na trhu, jenže praktická použitelnost těchto informací je poměrně malá, právě proto, že výrobci se od sebe nemohou více odlišit než právě cenou. Častou chybou hráčů je pak prodej za nižší cenu, než jsou jednotkové náklady. Existují též analytické nástroje, které jsou v rámci současného modelu hry naprosto nepoužitelné – například analýzu prostředí (PEST, blížeji viz (Johnson, Kevan, 2000, s. 87)) je určitě zbytečné vykonávat, protože většina atributů makroekonomického okolí firmy je v modelu ignorována. Též známá matice BCG (analýza portfolia, popsaná v (Johnson, Kevan, 2000, s. 158)), rozdělující produkty na Hvězdy, Dojné krávy, Otazníky a Psy podle míry růstu a podílu na trhu, nemá smysl pro analýzu simulované firmy používat — pouhé dva výrobky neumožňují výraznější diferenciaci, poptávka se naopak nechová tak, aby mohla vykazovat nějakou míru růstu (je ve své podstatě deterministická pro každé kolo zvlášť v závislosti na ceně a vlivu konkurence). Už to vypovídá o míře zjednodušení současných pravidel hry. Lze tedy prohlásit, že v rámci aktuálně používaných pravidel hry není možné aplikovat nástroje strategické analýzy. F.1.2
Problém toku času v současném modelu
Dalším problémem je tok času v manažerské hře „Výroba nábytkuÿ, který probíhá v čvrtletních skocích. Nejenom samotné plánování, ale i vnitřní výpočet jakéhokoliv procesu v ekonomickém modelu firmy je definován jako změna za čvrtletí. To potenciálně vede k velmi špatnému návyku, že doba pro plánování odpovídá době pro realizaci, že v tomto období nemá top management reagovat na změny a ani důvod k sledování oné realizace. Též to v průběhu hry vede k určitému myšlenkovému vzoru, že co naplánujeme, to se vždy podaří a jen občas je něco jinak než podle plánu. Tok času formou čvrtletních skoků totiž značně omezuje úpravu pravidel, neboť v takovémto systému musí být mnoho korekcí při nesplnění podmínek daných těmito pravidly prováděno zpětně v retrospektivě, místo aby bylo možné provádět průběžnou výrobu a vytvářet reakce teprve v případě mimořádné události. Například zjištění nesplnitelnosti výroby z nedostatku surovin nutí přepočítávat plán výroby tak, aby byl vyrobitelný, tedy pravidla jsou vždy implementována v čase tak, že vytváříme stav na konci čvrtletí a když něco nevychází, musíme upravovat realitu směrěm zpět do minulosti – lze si snadno představit, jak narůstají komplikace při současném konfliktu více pravidel. Přitom je samozřejmě logičtější, aby výroba byla prováděna postupně podle plánu, dokud se něco nestane. Z takovéhoto důvodu se v simulaci prakticky
F.2
Možnosti zlepšení
94
nestávají „běžné provozní událostiÿ, které denně musí řešit někdo na úrovni mistra směny či operačního manažera – zasekne se jeden stroj a je nutné ho odstavit do opravy, nepřijede dodávka surovin kvůli náledí, zaměstnanec je nemocný, stroj je zapotřebí přenastavit na jiný druh výrobku a podobně. Skutečnost při takovýchto nepředvítatelných událostech pak vždy neodpovídá plánu, resp. plánování musí být průběžně aktualizovaný proces.
F.2 F.2.1
Možnosti zlepšení Změna vnitřního toku času ze skokového na „plynulýÿ
Jako možnou úpravu nastavení toku času lze navrhnout následující styl práce. Ponechání čvrtletního strategického plánování v rámci jednoho kola hry. Výpočet výsledků firmy bude probíhat v jednom kole v intervalu jednoho měsíce, tedy třikrát, případně i častěji. Aktivnější hráči budou mít možnost zobrazení aktuálního stavu po každém měsíci a samozřejmě možnost úprav, ti méně aktivní se spokojí s čvrtletními výsledky. Vnitřní „taktÿ výpočtů pak bude probíhat po čvrthodinových skocích, což například umožní plynulejší modelování výrobního procesu s možnostmi jeho přerušení z nejrůznějších příčin. V prvním kroku je zapotřebí popsat současná pravidla v tomto jemnějším běhu času, teprve později komplikovat dalšími pravidly. Jde o velmi důležitý krok, umožňující vyšší úroveň složitosti modelu. Zcela zásadně by pak bylo nutné přepracovat způsob plánování ve firmě, především plánování výroby – v důsledku tedy zadávání rozhodnutí hráčů ohledně výroby. F.2.2
Zvýšení komplexnosti pravidel
Pravidla hry v současném ekonomickém modelu firmy a jejího okolí je možné zkomplikovat celou řadou možností, mimo jiné řešící problémy popsané v oddíle F.1. Firmy by měly mít možnost výrabět více než dva výrobky s použitím více než jednoho druhu stroje. Stroje se mohou lišit jak výkonností (počet vyrobených kusů), tak spotřebou surovin (odpadovost). Počet surovin je též možné zvýšit (např. spotřeba elektrického proudu, barvy a laky, dřevo), přičemž určité stroje dokáží opracovávat výrobek pouze určitým způsobem (definování polotovarů a procesu výroby). Stroje též mohou mít atribut opotřebení, což do modelu zavádí nutnost údržby strojů, jejich možnou zmetkovitost a reakci trhu na horší kvalitu výrobků. Komplikovanější stroje kladou vyšší nároky na zkušnosti údržby, což komplikuje personalistiku (školení, nábor, mzdové ohodnocení). Firma by měla mít možnost inovací, ať už ve formě zlepšování výsledných produktů, či snižování nákladovosti výroby. Trh by mohl být v důsledku více segmentovatelný (vliv rozdílných druhů výrobků, většího množství vstupních surovin, rozdílné výsledné kvality atd.). Zvýšit realističnost modelu nejenom na straně nabídky (firmy a výroba), ale i na straně poptávky zapojením metod umělé inteligence, například implementací nákupů spotřebitelů multiagentním systémem s různými preferencemi
F.2
Možnosti zlepšení
95
jednotlivců a možnost marketingového průzkumu těchto preferencí pro možnost cíleného zaměření se firmy na určitý segment trhu. Zároveň chápat trh jako konkrétní místo (či stát), tedy přidat do modelu základní principy logistiky, náklady za dopravu a čas dopravy. Firma pak pochopitelně může prodávat na více než jednom trhu. Firma by též měla mít možnost založení více než jednoho výrobního místa. Existence výběrových řízení může zajistit firmě trvalejší odbyt za danou cenu. Aktivní marketing, budování značky, reklama. Též možnost vytvoření odlišných startovních podmínek firem, kdy volbou strategie bude již volba počátečních podmínek (zakoupit existující firmu na určitém místě v určitém stavu, pokusit se vybudovat novou s časovým zpožděním atd.). Je též vhodné zvýšení míry rizika v rozhodování, přiblížit se více situaci fundamentální nejistoty. Nejenom nepředvídané události (umožněné úpravou popsanou v předchozím bodě), ale i cílené vytvoření šumu prezentovaných hodnot poskytuje realističtější obraz, nutící hráče pracovat s intervalem namísto s přesnou hodnotou. Čísla mohou být nepřesná, podle míry zkušeností zaměstnanců, podle ceny za průzkum trhu, úrovní procesu inventarizace (či existence evidenčního systému) ve skladech, vlivem přirozené statistické chyby atd. Největší a nejzásadnější změny je možné vykonat na úrovni samotné organizace hry mezi hráči. Zvětšit míru sociálních vazeb mezi hráči, zavést nutnost interakce nejenom uvnitř týmu, ale i mezi týmy navzájem, přivést do hry kromě principu vzájemné konkurence i principy spolupráce, kooperace, delegování a vyjednávání. Větší míry realističnosti hry je tak možné dosáhnout uznáním, že problémy vznikají nejčastěji u lidé, lidé je řeší a lidé jsou nejčastěji i největší komplikací při snaze o nalezení řešení. Největší komplikace si tak mohou přivodit sami hráči. První variantou je vytvořit dodavatelsko–odběratelské vztahy mezi týmy v rámci jednoho běhu hry, což vynucuje vyjednávání. Druhou, komplikovanější možností je rozložení odpovědností a pravomocí ve firmě mezi několik týmů, v složitější variantě i napříč předměty vyučovanými ústavem managementu. Pokud nejrealističtější částí modelu bude oblast výrobního procesu a jeho plánování, je možné například tuto část nechat zpracovávát týmy studentů v předmětu Operační management na bakalářském stupni, zatímco celkovou strategii budou definovat studenti předmětu Strategický management na magisterském stupni a budou nuceni co nejpřesněji vyjádřit své cíle, protože plán výroby dodaný jinými studenty nebudou mít možnost změnit (například pouze si vybrat z několika „variantÿ). Možnosti zlepšování pravidel hry formou zvětšování komplexnosti modelu naráží na dva limity. Prvním je limit času — manažerská hra je hrána na osm kol, v rámci jednoho semestru, bez možnosti jejího opakování (vynechám-li případ opakování předmětu). Například běžné strategické počítačové hry mají daleko složitější vnitřní model, hráčům je však umožněno opakování hry a mají tak možnost se zlepšovat a zkoumat lepší strategie. Druhým limitem je existence umělých hranic v modelované realitě, formou seznamu činností, které firma provádí, výrobků, které může vyrábět, inovací, které je možné zavést.
G
G
EFEKTIVNí VÝVOJ A ÚDRŽBA APLIKACE V PARALELNíCH VĚTVíCH
96
Efektivní vývoj a údržba aplikace v paralelních větvích
Obr. 22: Efektivní vývoj a údržba aplikace v paralelních větvích, podle http://nvie.com/ posts/a-successful-git-branching-model
H
H
UKÁZKA MAKRA PRO NÁSTROJB SELENIUMIDE
97
Ukázka makra pro nástrojb SeleniumIDE
Následující ukázkový test ověřuje, že je možné úspěšně vytvořit nový běh hry. Jako prerekvizitu očekává, že je v aplikaci uživatel přihlášen a že jde o uživatele s přiřazenou rolí „instruktorÿ. Tento krok byl obvykle činěn manuálně – přihlásit se jako testový uživatel a nechat otestovat funkcionality instruktora (a totéž pro hráče).
Výstup statické analýzy kódu byl proveden na čistém kódu aplikace vytvořené autorem této práce. V metrikách je tedy ignorován kód patřící frameworku Nette, knihovně Dibi a Nette komponentám. Statická analýza má za úkol ukázat základní přehled projektu. Byly vybrány ty nástroje, které nejsou příliš závislé na použité konfiguraci.
I.1
Výstup programu phploc
phploc 1.6.4 by Sebastian Bergmann. Directories: Files: Lines of Code (LOC): Cyclomatic Complexity / Lines of Code: Comment Lines of Code (CLOC): Non-Comment Lines of Code (NCLOC): Namespaces: Interfaces: Classes: Abstract: Concrete: Average Class Length (NCLOC): Methods: Scope: Non-Static: Static: Visibility: Public: Non-Public: Average Method Length (NCLOC): Cyclomatic Complexity / Number of Methods: Anonymous Functions: Functions: Constants: Global constants: Class constants:
Pro detekci duplicit bylo použito následující nastavení (striktnější, než základní nastavení programu) – --min-lines 2 --min-tokens 20. Tím byla zjištěna míra opakování kódu v projektu.
phpcpd 1.3.5 by Sebastian Bergmann. Found 69 exact clones with 620 duplicated lines in 41 files. 3.73% duplicated lines out of 16627 total lines of code. Time: 0 seconds, Memory: 9.50Mb
I.3
Vizualizace metrik programem pdepend
Obr. 23: Vizualizace metrik – graf
I.4
Výstup programu phpmd
101
Obr. 24: Vizualizace metrik – pyramida
I.4
Výstup programu phpmd
Statická analýza kódu byla provedena v základním nastavení pro tento nástroj, příkazem phpmd.bat build-mycode html codesize,unusedcode,naming,design --reportfile messdetector.html. Jde však o příklad nástroje, který je nutné více konfigurovat vzhledem k reálným potřebám pro daný projekt. Výsledný report detekuje 221 porušení základních pravidel; nebude proto uváděn kompletní. Nejčastejší reportované problémy se totiž týkají příliš krátkých a příliš dlouhých názvů proměnných, což je jedna z prvních úprav konfigurace na nástroji, která se doporučuje. Příliš krátkou proměnnou je název proměnné $id, který je často používán jako parametr určité akce presenteru. Za minimum považuje phpmd tři znaky. Naopak maximální délka proměnné je v základní konfiguraci dvacet znaků, nicméně v projektu jsou používány proměnné tak, že tento limit by měl být zvýšen na třicet znaků (např. $pocetZadanychRozhodnuti, $skoleniProvedenoMinuleKolo, $odchodnePropustenychDelniku aj.). Dalším často detekovaným problémem je velký počet dědiců určité třídy, což ale vyplývá ze stylu použití Nette frameworku (např. „The class BasePresenter has 25 childrenÿ), což je problém, který je možné ignorovat. Příklady detekovaných problémů, které je naopak zapotřebí řešit jinak než prostou změnou limitu v konfiguraci, jsou pak tyto (výstup z programu phpmd, pouze problém samotný, bez identifikace řádku zdrojového kódu): The class Gamer_DecisionPresenter has an overall complexity of 54. The configured complexity threshold is 50. The method transformModelValuesForForm() has an NPath
I.4
Výstup programu phpmd
complexity of 1024. The configured NPath complexity threshold is 200. Avoid unused local variables such as ’$idGameRun’.
