Aplikace pro vyřizování pohovorů
Bc. Marek Bařina
Diplomová práce
2017
beru na vědomí, že odevzdáním diplomové/bakalářské práce souhlasím se zveřejněním své práce podle zákona č. 111/1998 Sb. o vysokých školách a o změně a doplnění dalších zákonů (zákon o vysokých školách), ve znění pozdějších právních předpisů, bez ohledu na výsledek obhajoby;
beru na vědomí, že diplomová/bakalářská práce bude uložena v elektronické podobě v univerzitním informačním systému dostupná k prezenčnímu nahlédnutí, že jeden výtisk diplomové/bakalářské práce bude uložen v příruční knihovně Fakulty aplikované informatiky Univerzity Tomáše Bati ve Zlíně a jeden výtisk bude uložen u vedoucího práce;
byl/a jsem seznámen/a s tím, že na moji diplomovou/bakalářskou práci se plně vztahuje zákon č. 121/2000 Sb. o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon) ve znění pozdějších právních předpisů, zejm. § 35 odst. 3;
beru na vědomí, že podle § 60 odst. 1 autorského zákona má UTB ve Zlíně právo na uzavření licenční smlouvy o užití školního díla v rozsahu § 12 odst. 4 autorského zákona;
beru na vědomí, že podle § 60 odst. 2 a 3 autorského zákona mohu užít své dílo – diplomovou/bakalářskou práci nebo poskytnout licenci k jejímu využití jen připouští-li tak licenční smlouva uzavřená mezi mnou a Univerzitou Tomáše Bati ve Zlíně s tím, že vyrovnání případného přiměřeného příspěvku na úhradu nákladů, které byly Univerzitou Tomáše Bati ve Zlíně na vytvoření díla vynaloženy (až do jejich skutečné výše) bude rovněž předmětem této licenční smlouvy;
beru na vědomí, že pokud bylo k vypracování diplomové/bakalářské práce využito softwaru poskytnutého Univerzitou Tomáše Bati ve Zlíně nebo jinými subjekty pouze ke studijním a výzkumným účelům (tedy pouze k nekomerčnímu využití), nelze výsledky diplomové/bakalářské práce využít ke komerčním účelům;
beru na vědomí, že pokud je výstupem diplomové/bakalářské práce jakýkoliv softwarový produkt, považují se za součást práce rovněž i zdrojové kódy, popř. soubory, ze kterých se projekt skládá. Neodevzdání této součásti může být důvodem k neobhájení práce.
Prohlašuji,
že jsem na diplomové/bakalářské práci pracoval samostatně a použitou literaturu jsem citoval. V případě publikace výsledků budu uveden jako spoluautor.
že odevzdaná verze diplomové práce a verze elektronická nahraná do IS/STAG jsou totožné.
Ve Zlíně, dne ……….
podpis diplomanta
Cílem této práce byl vývoj aplikace pro vyřizování pohovorů. Analyzoval jsem funkční a nefunkční požadavky aplikace a sestavil návrh implementace včetně UML diagramů. Během tohoto vývoje jsem také porovnal nejběžnější používané technologie pro vývoj klientské a serverové části aplikací a vybral z nich technologie nejvhodnější pro použití v mém řešení.
Poté jsem navrženou aplikaci implementoval a popsal využité knihovny a zdrojový kód.
Klíčová slova: Vývoj softwaru, C#, .NET, Javascript, ReactJS, MS SQL
ABSTRACT
The aim of this thesis was the development of applications for interviews. I analyzed the functional and non-functional requirements of the application and prepare the implementa- tion design, including all diagrams. During this development, I also compared the most common technologies used to develop client-side and server-side applications, and chosed the most apropriate technologies which I used in my solution. I then implemented the appli- cation and described the used libraries and source code.
Keywords: Software development, C#, .NET, Javascript, ReactJS, MS SQL
možnost pracovat na tomto zajímavém tématu.
Prohlašuji, že odevzdaná verze bakalářské/diplomové práce a verze elektronická nahraná do IS/STAG jsou totožné.
„Kdo víno má a nepije, kdo hrozny má a nejí je, kdo ženu má a nelíbá, kdo zábavě se vyhýbá, na toho vemte bič a hůl, to není člověk, to je vůl.“
- Jan Werich
ÚVOD ... 9
I TEORETICKÁ ČÁST ... 10
1 ANALÝZA POŽADAVKŮ ... 11
1.1 ČINNOSTI A PROCESY VANALÝZE POŽADAVKŮ ... 12
1.1.1 Průzkum ... 12
1.1.2 Shromažďování informací ... 13
1.1.3 Analýza ... 14
1.1.4 Modelování ... 14
1.1.5 Validace ... 15
1.2 BLOKOVÉ SCHÉMA PROCESU ANALÝZY POŽADAVKŮ ... 15
1.3 TYPY POŽADAVKŮ ... 16
1.3.1 Funkční požadavky ... 16
1.3.2 Nefunkční požadavky ... 16
2 UML ... 18
2.1 USE CASE ... 18
2.2 MODEL PŘÍPADŮ UŽITÍ (USE CASE MODEL) ... 20
2.2.1 Aktér ... 20
2.2.2 Specifikace případů užití ... 21
2.3 DOMÉNOVÝ MODEL ... 23
2.3.1 Vztahy v doménovém modelu ... 24
3 TECHNOLOGIE PRO TVORBU KLIENTSKÉ ČÁSTI APLIKACÍ ... 27
3.1 WEBOVÝ KLIENTI ... 27
3.1.1 PHP ... 27
3.1.2 PERL ... 30
3.1.3 JavaScript ... 31
3.1.3.1 ReactJS ... 33
3.1.3.2 AngularJS ... 36
3.1.4 ASP.NET ... 38
3.1.4.1 ASP.NET WebForms ... 39
3.1.4.2 ASP.NET MVC ... 39
3.2 DESKTOPOVÝ KLIENTI ... 40
3.2.1 Java ... 40
3.2.1.1 Swing ... 41
3.2.1.2 SWT ... 41
3.2.2 C# (.Net) ... 42
3.2.2.1 .NET a jeho Historie ... 43
3.2.2.2 WinForm a WPF ... 48
4 TECHNOLOGIE PRO TVORBU SERVEROVÉ ČÁSTI APLIKACÍ ... 50
4.1.1 JavaScript ... 50
4.1.1.1 NodeJS ... 50
4.1.2 Java ... 51
4.1.2.1 Jersey ... 51
4.1.3 C# (.NET) ... 52
4.1.3.1 .NET Web API ... 52
5.1 POŽADAVKY ... 55
5.1.1 Funkční požadavky ... 55
5.1.2 Nefunkční požadavky ... 55
5.2 ANALÝZA A SPECIFIKACE IMPLEMENTACE ... 56
5.2.1 Výběr technologií pro klienta a serverovou část aplikace ... 57
5.2.2 Diagramy případů užití (Use Case) ... 58
5.2.3 Doménový model ... 63
5.2.4 Návrh GUI ... 64
6 IMPLEMENTACE ... 65
6.1 DATABÁZOVÝ MODEL ... 65
6.2 UKÁZKA IMPLEMENTACE KLIENTA ... 66
6.3 UKÁZKA IMPLEMENTACE SERVEROVÉ ČÁSTI WEB API ... 70
7 UKÁZKA APLIKACE ... 74
ZÁVĚR ... 77
SEZNAM POUŽITÉ LITERATURY ... 78
SEZNAM POUŽITÝCH SYMBOLŮ A ZKRATEK ... 81
SEZNAM OBRÁZKŮ ... 83
SEZNAM PŘÍLOH ... 84
ÚVOD
Téma této práce jsem si zvolil při příležitosti vývoje aplikace pro zefektivnění recruitment procesu ve firmě, ve které pracuji jako .Net developer. Tato aplikace dostala interní název InterviewMe. V této práci jsem popsal postup vývoje softwaru od analýzy požadavků až po implementaci. V teoretické části jsem se zaměřil na obecné věci týkající se analýzy, návrhu a vývoje softwaru a porovnal jsem běžně používané technologie pro implementaci serverové a klientské části aplikace. Toto rozdělení je hlavně z důvodu, že jeden z hlavních nefunkč- ních požadavků aplikace bylo kompletní oddělení těchto částí jakožto i udržitelnost kódu.
Nefunkční požadavky aplikace byly hlavním faktorem při výběru technologií a frameworků pro uživatelské rozhraní a serverovou část.
Funkcionální požadavky na aplikaci byli především správa kandidátů, vytváření testů, mož- nost testy přiřazovat ke kandidátům a hodnotit je, správa otevřených pozic, možnost aby kandidát mohl testy pomocí aplikace vyplňovat a další detailnější požadavky.
I. TEORETICKÁ ČÁST
1 ANALÝZA POŽADAVKŮ
Analýza požadavků je prvním stádiem v procesu systémového inženýrství a procesu softwa- rového vývoje. Je to inženýrská disciplína pro stanovení požadavků uživatelů a určení soft- warových systémů. Systematická analýza požadavků je spíše známa jako: „requirements en- gineering“ (RE). Někdy je také (špatně) pojmenovaná jako sběr požadavků, nebo specifi- kace požadavků. Pojem analýza požadavků může být také pokládán za analýzu v právem slova smyslu (jako příklad opaku k sběru nebo dokumentaci požadavku). Analýza poža- davků v systémovém a softwarovém inženýrství, pojímá ty úkoly, které vstupují do rozho- dování o potřebách a podmínkách, které jsou kladeny na nový, nebo změněný produkt. Také musí brát v úvahu různé protichůdné požadavky účastnících se stran tzv. stakeholderů jako uživatelů, nebo jiných účastníků využívajíc výsledných efektů.
Existuje mnoho definic analýzy požadavků, nicméně všechny sdílejí myšlenku, že poža- davky zahrnují zjištění toho, co lidé chtějí od počítačového systému a pochopení toho, co jejich požadavky znamenají z hlediska designu. Analýza požadavků úzce souvisí se softwa- rovým inženýrstvím, které se více zaměřuje na proces navrhování systému, který uživatelé chtějí. Možná nejsrozumitelnější shrnutí pochází od Barryho Boehma: "navrhování správné věci", na rozdíl od softwarového inženýrství "navrhovat věci správně" (Boehm, 1981).
Nuseibeh a Easterbrook (2000) poskytují komplexnější definici: „analýza požadavků soft- warových systémů je proces objevování účelu systému tím, že identifikujeme zúčastněné strany a jejich potřeby a dokumentujeme je ve formě, která je přístupná analýze, komunikaci a následné implementaci“ [1].
Analýza požadavků sdílí mnoho konceptů a technik interakce člověka s počítačem (HCI), zejména návrh orientovaný na uživatele, participační design a interakce. Rozlišuje se však od HCI vzhledem k rozsahu konstrukce. Například socio-technický design je zřídka zmíněn v analýze požadavků, kde organizační a lidská část systému je explicitním cílem požadavků a designu systému. Druhý rozdíl spočívá v tom, že se HCI soustředí na design jako takový a interakční návrh, kde jsou uživatelské požadavky považovány za součást procesu průzkumu návrhu, prototypování a dialogu s uživatelem o vyhodnocení, spíše než jako lineární proces
"Specifikovat-Navrhnout-Implementovat" upřednostňovaný v analýze požadavků. Nicméně v analýze požadavků se jistě přebírá iterativní návrh, prototypování a proces vyhodnocení (obvykle se používá termín validace v terminologii požadavků) [1].
Obrázek 1 – Zjednodušený proces analýzy požadavků a tvorby návrhu [2]
Analýza požadavků je kritická ve vztahu k úspěšnému dokončení vývoje systému. Požada- vek musí být proveditelný, měřitelný, testovatelný, musí se vztahovat ke konkrétnímu byz- nys požadavku, nebo příležitosti a také musí být definovaný dostatečné detailně pro účely návrhu systému.
1.1 Činnosti a procesy v analýze požadavků
Základními činnostmi v procesu analýzy požadavků jsou průzkum, shromažďování infor- mací (požadavků), analýza, modelování a validace.
1.1.1 Průzkum
Začátek procesu často začíná nejasným projevem záměru. Prvním problémem je stanovení hranice vyšetřování a mimo jiné rozsah zamýšleného systému. Bohužel je to zřídka snadný úkol, protože klienti často nevědí přesně co chtějí a znalosti o zamýšleném systému jsou nejasné. Průzkum má tendenci být iterační aktivitou, neboť hranice jsou jasnější se zvyšují- cím se pochopením oblasti sdílené všemi zainteresovanými stranami (stakeholdery). Tento proces je však špatně pochopen a jen málo výzkumu se přímo zabýval tímto obtížným pro- blémem [1].
Vezměte například systém, který by pomohl epidemiologům při jejich výzkumu. Zaintere- sované strany by mohly zahrnovat lékařské analytiky se zájmem o epidemiologii, stejně jako lékaře. Rozsah možných nástrojů pro podporu rozhodování by mohl zahrnovat sběr dat, pří- pravu dat, statistickou analýzu, vizualizaci, grafy, mapy a také skupinovou diskuzi o výsled- cích. Vlastník systémů a rozsah nebyly zřejmé, protože projekt byl zahájen v rámci programu
výzkumu elektronických věd podporovaného vládou Spojeného království, s uživateli, kteří byli akademickými výzkumníky epidemiologie a kteří také spolupracovali s lékaři z míst- ních nemocnic [1].
V obecné oblasti průzkumu poskytuje podnikatelské modelování (enterprise modeling) způ- sob popisu podnikatelského kontextu, aby se objevily požadavky ve velkém (tjn. všechny cíle, účely a politiky). Workshopy v metodě brainstormingu KJ, pojmenované podle jeho vynálezce Jiro Kawakita a „Rapid Applications Development“ jsou současným trendy v této oblasti. Obhajují používání seznamů a neformálních map problémového prostoru, i když tyto metody nabízejí jen málo systematické vedení. Podrobnější určení rozsahu průzkumu bylo zkoumáno Jacksonem a Zavem, kteří navrhli techniky pro stanovení hranice systému zkou- máním povinností a úkolů zamýšleného systému při reagování na události v reálném světě, ačkoli to nepomáhá omezovat vyšetřování, která začíná obecnými prohlášeními záměrů uži- vatelů [1].
Obrázek 2 – podnikatelské modelování [3]
Průzkumu je nejlépe dosaženo diskusí se všemi zainteresovanými stranami a zdokumento- váním cílů systému na vysoké úrovni. Vypracování rozsahu působnosti má tendenci soustře- dit pozornost uživatelů na to, kde by mělo ležet systémové vyšetřování, a pomáhá identifi- kovat alespoň počáteční prostor pro systém [1].
1.1.2 Shromažďování informací
Většina technik pro tuto činnost byla vypůjčena z analýzy systémů, např. Rozhovory, pozo- rování, dotazníky, analýza textu a dokumentů. Byly použity techniky získávání znalostí, jako jsou repertoární sítě a protokolová analýza, ale kromě předběžné studie Maiden a Rugga
(1994) nebyly systematicky zkoumány zásluhy různých technik zachycování faktů. Zajíma- vou vznikající oblastí je využití etnografických a spojených pozorovacích metod (Goguen
& Linde, 1993; Luff et al., 1993). Většina z nich však není schopna poskytnout explicitní návod k zachycení nebo analýze faktů, což vedou softwarové inženýry k tomu, aby navrhli své vlastní rychlé a špinavé přístupy [1].
1.1.3 Analýza
Analýza a modelování obecně vycházejí z přístupů shora dolů a soustředí se na rozklad cílů.
Analýza je často motivována základními otázkami, takzvaných pět "W" (z anglického ja- zyka):
Jaký je účel systému (cíle)?
Jaké objekty jsou zahrnuty?
Kde je systém umístěn?
Kdy by se měly věci dělat?
Proč je systém nezbytný (cíle nebo problémy, které hodlá řešit)?
Cílově orientovaná analýza používá scénáře k objevení překážek nebo potenciálních pro- blémů způsobených externími činiteli, s nimiž se systém musí vyrovnávat. Z překážek lze formulovat cíle pro udržení a vyvarovat se a opravám problémů. Jiné metody rozkladu cílů sledují taxonomický přístup a pokoušejí se analyzovat cíle v kontextu doménových modelů.
Pro analýzu problémů metodika měkkých systémů poskytuje prostředky neformálního mo- delování a analytického přístupu k objevování problémově orientovaných požadavků. Ne- formální diagramy a náčrty, které mohou být označovány jako doménové modely nebo bo- haté obrázky, se používají k dokumentaci analýzy v průběhu jejího postupu [1].
1.1.4 Modelování
Tato aktivita využívá výstup z analýzy, strukturuje fakta a reprezentuje je v notacích. Ana- lýza požadavků si pro tuto činnost vypůjčila metody strukturovaného vývoje systému a kon- ceptuální modelování. Neformální modelové notace, jako jsou diagramy datových toků, di- agramy případů užití a schémata vztahů mezi entitami jsou široce používány. Mnoho for- málních přístupů k modelování bylo převzato z softwarového inženýrství, ačkoli efektivnost těchto technik ještě nebyla prokázána v průmyslové praxi. Analýza a modelování jsou často prokládány pro vypracování požadavků, neboť prostřednictvím jejich zastoupení se zvyšuje porozuměním problematické oblasti [1].
1.1.5 Validace
Tato klíčová aktivita v analýze požadavků, ačkoli byla rozsáhle prozkoumána, je stále pro- blematická. Validace neboli ověření předpokládá, že uživatelé pochopí důsledky specifikace požadavků a poté souhlasí, tj. potvrdí, že přesně odrážejí jejich přání. Současným stavem techniky jsou techniky průzkumu, v nichž jsou v dílně designérů a uživatelů kritizovány polo-formální specifikace, jako jsou diagramy datových toků. Návody mají zásluhu na včasné validaci specifikací, zatímco prototypy jsou pravděpodobně silnější, protože uživa- telé silněji reagují na skutečný pracovní systém. Bohužel prototypy stále přinášejí náklady na výstavbu a špatně organizované používání prototypů může být škodlivé. Nicméně proto- typy v kombinaci s technikami pro shromažďování a vyhodnocování zpětné vazby uživatelů mohou být vysoce účinné. Celkově je proces validace špatně pochopen a vysvětlení je důle- žitou, přesto často opomíjenou složkou. Některý výzkum vysvětlující komplexní požadavky ukázal, že je nutná kombinace vizualizace, příkladů a simulace (Carroll et al., 1994; Maiden
& Sutcliffe, 1994). Scénářové reprezentace a animované simulace pomáhají uživatelům vi- dět důsledky chování systému a tím zlepšují validaci. Navíc prototypy se scénáři jsou silným prostředkem vyvolání zpětné vazby. Technika dotazovacího cyklu (Potts et al., 1994) přistu- puje k validaci porovnáním skriptů představovaného chování v reálném světě proti požado- vanému chování ve specifikaci. Validace je stále špatně pochopena a je zapotřebí dalšího výzkumu, aby se zjistilo, jak interagují vysvětlení, reprezentace a porozumění uživatelů se specifikacemi systému [1].
1.2 Blokové schéma procesu analýzy požadavků
Na obrázku níže můžeme vidět detailnější schéma procesu analýzy požadavků.
Obrázek 3 – schéma procesu analýzy požadavků [5]
1.3 Typy požadavků
Požadavky jsou zadání v přirozeném jazyce, příp. diagramy udávající požadované služby systému a omezení. Jsou vytvořeny na základě informace od zákazníka. Požadavky jsou kategorizované několika způsoby. Následující kategorizace požadavků je z technického po- hledu [2, 6].
Požadavky zákazníků: Specifikace požadavků a předpokladů, které určují očekávání od sys- tému vzhledem na sledované cíle, prostředí, omezení a metriky efektivnosti a vhodnosti (MOE / MOS). Zákazníci jsou ti, kteří vykonávají osm primárních funkcí systémového in- ženýrství, se zvláštním důrazem na operátora jako na klíčového zákazníka [6].
1.3.1 Funkční požadavky
Umožňují nám jako výrobci softwaru základní orientaci v potřebách zákazníka a představují jakýsi most mezi prostředím a terminologií zákazníka a prostředím vývoje software. Pokud má zákazník jasnější představu o způsobech použití budoucího software, popíšeme tzv. pří- pady užití (neboli Use cases) [7, 2].
1.3.2 Nefunkční požadavky
Definují vlastnosti a omezení systému jako celku a týkají se produktu i procesu vývoje (kva- lita, udržovatelnost atd). I tyto požadavky mají mnohdy kritický vliv na aplikaci, ale jejich samotným úkolem však není podpořit byznys cíle, ale vyvinout kvalitní stabilní aplikaci a její kvalitu měřit podle kritérií, kterých si u dané aplikace zákazník nejvíce cenní. Mezi zá- kladní požadavky patří výkon, škálovatelnost, spolehlivost, rozšiřitelnost, udržitelnost, spra- vovatelnost a bezpečnost. Při volbě požadavků, které jsou pro systém nejdůležitější, musejí architekt ve spolupráci se zákazníkem počítat s tím, že se jednotlivé požadavky vylučují navzájem. Chceme-li například navrhnout a realizovat systém, který si bude zakládat na vy- sokém výkonu, musíme obětovat požadavky, jako jsou udržitelnost a rozšiřitelnost. Musíme tedy počítat s tím, že rychlost naší aplikace bude vykoupena například tím, že v budoucnu budeme muset investovat více prostředků pro rozšíření dané aplikace o novou funkčnost [7, 8].
Typy nefunkčních požadavků [5]:
požadavky na produkt 1. na použitelnost 2. na efektivnost
a. výkonnostní b. prostorové 3. na spolehlivost 4. na přenositelnost
požadavky na proces 1. na dodání
2. na implementaci 3. na standardy
externí požadavky
1. na součinnost (interoperability) 2. etické
3. legislativní
a. ochrana soukromí b. bezpečnostní
Nefunkční požadavky musí být ověřitelné a měřitelné.
Rychlost: transakce/s, doba odezvy,
Velikost: kód, požadavky na diskový prostor, paměť RAM, Použitelnost: doba zaškolení, rozsah nápovědy,
Spolehlivost: střední doba bezporuchového provozu, pravděpodobnost nedostupnosti, čet- nost poruch a chyb,
Robustnost: doba obnovy po poruše, pravděpodobnost zničení dat při poruše, Přenositelnost: procento závislého kódu, počet cílových systémů.
2 UML
UML (Unified Modeling Language) je soubor grafických notací, který se používá pří vývoji softwaru. V oblasti analýzy a návrhu se stal standardem, a proto je pro programátory důle- žité, aby se v něm orientovali. UML je použito v mnoha materiálech, v dokumentacích a podobně. Hlavně nám ale může sloužit jako užitečný nástroj k usnadnění návrhu a vývoje informačního systému.
2.1 Use Case
V letech 1992-1997 se většina lidí, kteří psali o případech užívání, vyhýbala tomu, aby ří- kala, co je přesně. Nicméně prohlásili, jak užitečné jsou pro projekty. Přestože se zdálo, že nikdo nemůže říci, co to je, nebo pojmenovat rozdíl mezi případem použití a scénářem, zá- kladní a přitažlivý nápad zůstal [9]:
„Napište krátký textový popis toho, jak systém interaguje s okolím, když provádí jistou funkci pro jednoho z jeho uživatelů, a zachyťte, jak se má systém chovat, když se něco děje špatně.“ [9]
Tato myšlenka byla užitečná tehdy, a je stále užitečná, bez ohledu na to, jak formálně nebo neformálně by text mohl být napsán [9].
Mezi různými myšlenkami, které v té době rostly, navrhovali a doporučovali téměř všechny kombinace a permutace odpovědí na základní otázky [9]:
Je použití případu požadavkem nebo jen popisem činnosti?
Je scénář jen jiný název pro případ použití?
Je případ použití formální, polo-formální nebo neformální struktura?
Existuje propojovací struktura pro případy použití, nebo prostě přicházejí ve skupinách?
Pro některé lidi to byl pouze jiný název pro scénář, krátký popis někoho, kdo používal tento systém (Martin Fowler často říkal, "myslím, že případ použití musí být švédské označení pro scénář"). Podle této myšlenky, případ užití nemá žádnou vnitřní strukturu a případy užití jen sedí ve skupinách. Lidé, kteří takto popisovali případy užití, získali dobrou hodnotu za úsilí, které vynaložili, a mnoho z nich doporučuje psát takové neformální případy užití [9].
Jiní lidé, zejména výzkumní pracovníci a návrháři nástrojů CASE (Computer Assisted Soft- ware Engineering) považovali tyto neformální pracovní produkty za neúplné, potřebují ma- tematický základ a podporu v nástroji CASE. Vygenerovali jazyky, notace a nástroje, aby používaly případy "přesné". Tato myšlenková škola se tak dobře neoplatila. Lidé chtějí po- měrně neformální médium, v němž vyjadřují své počáteční myšlenky na systém. Prostě ne- budou používat formální nástroje. Nemají pocit, že se v průběhu projektu vyplácí další pra- covní síla [9].
Dalším problémem, se kterým se formalisté setkávají, je manipulace se všemi variantami, které musí systém zvládnout. Například: "Pro cukrářský stroj, jak specifikuji, že člověk může dát tři čtvrtiny nebo patnáct centů? Nebo čtvrtina následuje deset centů, nebo deset centů, za kterými následuje čtvrtina? Nebo některou z dalších desítek způsobů, jimiž může osoba vložit minci? ". Správná odpověď byla a je, "Jen napište, že ten člověk dává peníze."
Poté, co byli v různých časech lidé uvězněni v příliš hodně, a naopak příliš málo formálním zpracování, je vybrána prostřední cesta: polo-formální text sedící v polo-formální struktuře.
Pomocí těchto polo-formálních struktur, můžeme [9]:
Ujistit se, že případy použití jsou opravdu požadavky a potřebují základní strukturu
Umožnit lidem psát co chtějí, když potřebují.
Překvapením je, že druhý cíl je důležitější než první.
Strukturování případů užití s cíli
Jak můžeme vidět na ukázkovém obrázku níže, je případ užití textovým popisem činností aktérů. Velká otázka na počátku devadesátých let byla, jak tyto společné akce souvisí do- hromady [9].
Vysvětlení Ivara Jacobsona a jeho příklady, poskytují dvě rady. První a největší je, že případ užití popisuje aktéra, který se pokouší dosáhnout cíle pomocí systému. To znamená, že po- kud jmenujeme jednoho z aktérů jako primárního aktéra, pak všechny akce souvisejí s tím, že daný aktér dosáhl nějakého cíle, který byl jeho zájmem [9]
Spojení případů použití s cíli aktérů je velmi důležité, protože posunuje pozornost z funkč- ních seznamů, které se většina programátorů obává a vrací je zpět uživatelům no to co uži- vatelé skutečně chtějí dosáhnout se softwarem, a jaké jsou jejich cíle při používání Softwaru.
Pokud software podporuje tyto cíle, software přinese největší obchodní hodnotu [9].
Druhým radou je, že cíle někdy selhávají. Ať už získáte smlouvu, získáváte peníze z banko- matu, vložíte kartu ATM do čtečky karet nebo dokonce přesunete do dalšího pole při vypl- ňování online formuláře, může být jakýkoliv cíl neúspěšný. Přemýšlení a psaní o způsobu řešení selhání v dokumentu požadavků šetří projektovým týmům v průběhu projektu spoustu peněz [9].
Případy užití jsou proto strukturováno do dvou částí: sled akcí, kdy vše funguje dobře, ná- sledované různými malými sekvencemi popisujícími, a co se stane, když se různé cíle a sub- cíle nezdaří [9].
Dokonce i s těmito radami byl jeden neočekávaný důsledek práce s cílem. Cíle jsou v růz- ných velikostech. V jednom okamžiku můj cíl může být získání významné obchodní smlouvy. Okamžitějším cílem (zaměřeným na menší časový interval) je přijetí klienta na oběd. Dalším okamžitým cílem (s ještě menším časovým rozpětím) je dostat hotovost na oběd [9].
Pokud to shrneme je případ užití sada několika akcí, které vedou k dosažení určitého cíle.
Use Case může být přidání komentáře k článku, založení nového uživatele nebo např. vy- tisknutí dokumentu. Definuje tedy jednu funkcionalitu, kterou by měl navrhovaný systém umět. Ta v sobě obsahuje další akce, např. přidání komentáře bude obsahovat ověření uži- vatele, validaci zadaných dat, zápis do databáze a podobně. To v diagramu zachyceno již nebude. UML často hovoří o tzv. blackboxu (černé skříňce), kde skryjeme vnitřní logiku a pracujeme pouze s komponentami. Tento princip přesně využívá UC diagram [4].
2.2 Model případů užití (Use Case model)
Use Case Diagram (česky diagram případů užití) zobrazuje chování systému tak, jak ho vidí uživatel. Účelem diagramu je popsat funkcionalitu systému, tedy co od něj uživatel nebo my očekáváme. Diagram vypovídá o tom, co má systém umět, ale neříká, jak to bude dělat. Proto je to většinou první diagram, který při návrhu informačního systému vytváříme. Je důležité se nejprve shodnout na tom, co má náš systém (nebo aplikace, hra, cokoli) umět. Až potom má smysl se ptát, jak to vlastně uděláme [4, 9].
2.2.1 Aktér
Aktér je role, která komunikuje s jednotlivými případy užití. V této roli může být obsazen uživatel nebo externí systém. Aktérem tedy může být např. Uživatel, Administrátor, SMS
server nebo dokonce Čas. Aktér inicializuje nějaký případ užití (např. Uživatel vloží příspě- vek do fóra). Zde hovoříme o tom, že je aktér aktivní. Aktér sám však může být případem užití iniciován (např. externí SMS server je iniciován případem užití Poslat SMS). V tomto případě hovoříme o pasivním aktérovi a zakresluje ho v diagramu napravo [4, 9].
Aktéry znázorňujeme jako postavu z čar s názvem napsaným pod ní.
Obrázek 4 – Aktér [4]
2.2.2 Specifikace případů užití
Samotný UC diagram nám ukazuje, jaké funkcionality systém obsahuje a jak (kým) jsou spouštěny. Kromě názvů jednotlivých případů užití o nich však nevíme vůbec nic. Tento problém řeší Use Case Specifikace. Jedná se o doplňující dokument, který je k Use Case diagramu přiložen. Nemá žádnou pevně definovanou podobu, může být ve formě tabulky nebo prostého textu.Specifikace obsahuje jednotlivé případy užití, ke každému z nich defi- nuje několik bodů. Nejprve si je popíšeme, potom si zkusíme část specifikace k našemu modelu vytvořit. Vyjmenujme si tedy jednotlivé části specifikace pro jeden případ užití [4]:
1. Krátký popis (Brief Description)
V první části krátce popíšeme případ užití, stačí 1 až 2 věty. Měl by vysvětlovat, jakou má funkčnost pro uživatele přidanou hodnotu, proč ji uživatel spouští. Víme, že Use Case dia- gram popisoval funkčnost právě z pohledu uživatele. Toto pravidlo zachováme i v UC spe- cifikaci. Příkladem by mohl být popis: "Use Case umožňuje vytisknout vybraný dokument"
[4].
2. Aktéři (Actors)
Další část jmenuje aktéry, kteří se případu užití účastní. Příkladem mohou být Systém a Uži- vatel [4].
3. Podmínky pro spuštění
Každý případ užití může mít definované určité podmínky, které musí být pro jeho spuštění splněny. Ty můžeme uvést v této části jeho specifikace. Tyto podmínky můžeme také vyne- chat. Příkladem podmínek pro spuštění může být nainstalovaná tiskárna nebo internetové připojení. Bez těchto náležitostí nemá UC smysl a nebude ani spuštěn [4].
4. Základní tok
Konečně se dostáváme k základnímu toku. V jeho bodech je popsána interakce mezi aktéry a jednotlivými případy užití. Body zapisujeme jako scénář, ve kterém se střídají vždy aktér a systém. Opět máme na paměti, že popisujeme z pohledu uživatele a toho, jaký pro něj má případ užití význam. Častou chybou je popisovat co systém zobrazí, co uživatel zapíše do formuláře a podobně. Popis by měl však být úplně odstíněn od toho, jak systém vypadá, měl by se zaměřit na to, jak funguje. Základní tok neřeší možné chyby a předpokládá bezproblé- mový průběh, kde v posledním kroku dojde ke splnění cíle případu užití. Příklad si ukážeme dále [4].
5. Alternativní toky
Specifikace může obsahovat několik alternativních toků (scénářů), které umožňují reagovat na odchylky od scénáře hlavního. Jedná se o poruchy nebo chyby, ať již ze strany uživatele (špatně zadal heslo) nebo systému (nepodařilo se vytisknout dokument). Alternativní tok se vždy vztahuje k určitému bodu hlavního toku a řeší jeho nestandardní verzi. Většinou je na konci odkázán opět na nějaký bod hlavního toku, kde zas hlavní tok pokračuje dále [4].
6. Podmínky pro dokončení
Podobně, jako může mít případ užití podmínky přes spuštěním, může mít i podmínky pro dokončení. Podmínkami může být např. že vše proběhlo v pořádku nebo že chyby byly za- znamenány do chybového logu [4].
Obrázek 5 – ukázka diagramu případů užití [4]
2.3 Doménový model
Doménový model je formou class diagramu, tedy diagramu tříd. Třídy v doménovém mo- delu jsou však značně zjednodušené, neobsahují metody a mají pouze důležité atributy. Mo- del je tedy jakýsi náčrt základních entit systému a vztahů mezi nimi. Je platformě nezávislý (není určen pro konkrétní programovací jazyk) a atributy nemají datové typy [4].
Obrázek 6 – ukázka doménového modelu [4]
Při tvorbě doménového modelu vycházíme ze zadání klienta. Z něj identifikujeme klíčové entity a vztahy mezi nimi. Tyto entity zakreslíme do modelu jako třídy.
2.3.1 Vztahy v doménovém modelu
UML nabízí několik druhů vztahů, ty základní si vyjmenujeme.
Asociace (Association)
Asociace určuje základní vztah mezi dvěma entitami. Ty mohou existovat nezávisle na sobě.
Zakreslujeme ji jako jednoduchou plnou čáru. Příklad jednoduché asociace mezi dvěma en- titami může být Auto a Řidič. Vztah by se znázornil takto:
Obrázek 7 – asociace [4]
Jako výchozí je směr na obě strany, tedy že první entita má odkaz na druhou, a naopak druhá na první. Toto chování můžeme změnit přidáním jednoduché šipky, která směr specifikuje a způsobí, že odkaz si uchovává pouze ta instance, na kterou nesměřuje šipka. Je možné vytvořit asociaci i mezi třemi třídami, ale tím se nebudeme zabývat [4].
Agregace (Aggregation)
Agregace reprezentuje vztah typu celek - část. Znázorňuje se jako jednoduchá plná čára, zakončená na jedné straně prázdným kosočtvercem. Ten je umístěn u té entity, která repre- zentuje celek (např. sekce s články). Z hlediska implementace je to tak entita, která drží kolekci. Entita reprezentující část může existovat sama o sobě a být součástí i jiných kolekcí.
Příkladem agregace může být již zmíněná sekce, obsahující články. Čísla na konci vazby znamenají tzv. multiplicitu, přesněji, že sekce obsahuje libovolný počet článků a článek patří alespoň do 1 sekce [4].
Obrázek 8 – agregace [4]
Kompozice (Composition)
Kompozice je podobná agregaci, avšak reprezentuje silnější vztah. Entita části nemá bez celku smysl. Pokud zanikne celek, zanikají automaticky i jeho části. Kompozici zakreslu- jeme stejně jako agregaci, kosočtverec je ovšem plný. Tato vazba bývá matoucí a doporučil bych se jí spíše vyhýbat a nahradit ji agregací. U entity reprezentující celek musí být multi- plicita vždy 1. Příkladem může být Objednávka a Položka objednávky. Zatímco článek z minulého příkladu dává bez sekce ještě nějaký smysl, položka objednávky bez objednávky smysl nedává. Proto je zde použita kompozice [4].
Obrázek 9 – kompozice [4]
Generalizace (Generalization)
Posledním vztahem, který si zde uvedeme, je generazilizace. Z hlediska implementace se jedná o dědičnost. Jedna entita dědí vlastnosti a chování jiné. S touto vazbou jsme se již setkali u Use Case diagramu. Generalizaci zakreslujeme jako plnou čáru, zakončenou na jedné straně prázdnou uzavřenou šipkou (nebo chcete-li trojúhelníkem). Šipka je na straně entity, ze které se dědí. Příkladem může být třída Tvar, ze které dědí třídy Čtverec a Kruh [4].
Obrázek 10 – generalizace [4]
Multiplicita
Vraťme se ještě k multiplicitě (neboli násobnosti). Multiplicitu můžeme uvést u vazeb aso- ciace, agregace a kompozice (zde pouze z jedné strany).
Vraťme se k příkladu sekce-článek:
Multiplicitu zde čteme takto: Sekce může mít libovolný počet článků (to poznáme podle hvězdičky u třídy Článek). Článek patří do 1 až libovolně sekcí (to poznáme podle 1..* u Sekce). Pojďme si nyní uvést jednotlivé možné zápisy multiplicity [4]:
1 (číslo) - Označuje konkrétní hodnotu (zde právě 1).
(hvězdička) - Označuje libovolný počet (tedy i 0). Místo hvězdičky můžeme v ně- kterých materiálech nalézt symbol N.
1..* (interval) - Pomocí 2 teček můžeme označit interval. Do něj vkládáme nám již známé symboly, např.: 2..6 nebo 1..* nebo 0..1.
Zápisy můžeme dokonce i slučovat, např. takto: 1, 2, 3, 7..*. Tento zápis označuje multipli- citu 1, 2, 3 nebo 7 a více. Pokud není multiplicita uvedena, označuje to výchozí hodnotu 1 [4].
3 TECHNOLOGIE PRO TVORBU KLIENTSKÉ ČÁSTI APLIKACÍ
Rozdělení na technologie běžně používané zvlášť na klientskou část aplikace serverovou je především z důvodu jednoho z hlavních nefunkčních požadavků na tuto aplikaci, a to kom- pletní separace těchto částí. I když mnoho níže uvedených technologií by samozřejmě zvládlo obojí [4].
3.1 Webový klienti
3.1.1 PHP
PHP Hypertext Preprocessor je skriptovací jazyk běžící na straně serveru (server-side) spe- ciálně navržený pro potřeby webové stránky. Pro skriptování na straně klienta je používán JavaScript. Pomocí PHP jsme schopni vytvořit dynamické webové stránky pro uživatelské rozhraní zobrazené na straně prohlížeče jako HTML s CSS. Ale také k vytvoření celé logiky aplikace včetně databázového přístupu. PHP od verze 5.3 je velmi dobře objektově oriento- vaný jazyk a je Open Source. PHP byla původně zkratka pro „Personal Home Page“ neboli osobní domovská stránka.
Klady [10, 11, 12, 15]:
PHP je specializované na webové stránky.
Strmá křivka učení: Začít a pracovat s PHP je docela jednoduché. Vytváření webo- vých stránek je téměř příliš jednoduché. To je kvůli jeho původu jako nástroj pro vytváření osobních domovských stránek a tlumočení formulářů.
Funkcionální a objektově orientované programování: Oba způsoby jsou nyní dobře podporovány v aktuální verzi PHP s anonymními funkcemi, také známými jako lambda nebo uzávěry, které nyní získávají status prvotřídního objektu.
Obrovský ekosystém: Ekosystém kolem PHP je obrovský. Mnoho z toho je kvůli popularitě WordPress a Magento. Existují desítky bezplatných a placených online školicích míst pro PHP i lokální tréninková místa po celém světě.
Velká komunita softwaru s otevřeným zdrojovým kódem: S příchodem sklada- tele asi před pěti lety explodovala komunita OSS s více než 70 000 knihovnami s otevřeným zdrojovým kódem.
Poměrně slušná dokumentace.
Množství propojitelných frameworků: Po vzniku PHP Framework Interop Group před přibližně pěti lety komunita PHP konečně přijala interoperabilitu. To umožňuje psát kód pro jeden framework, který lze snadno přenést do jiného. To také znamená, že můžete použít mnoho stejných knihoven v rámci různých frameworků. Interope- rabilita také znamená sdílení jádrových komponent a je snazší vytvářet a udržovat framework, přičemž se zaměřuje spíše na případ použití pro váš framwork než na klíčové komponenty, které musí každý framework poskytovat. To vedlo k množství opravdu dobrých frameworků jako Symfony2, Laravel, Silex a zend-expressive, které sdílejí společné knihovny.
Automatizační nástroje: Je k dispozici poměrně dobrý systém automatizačních ná- strojů pro testování a nasazení PHP aplikací, které jsou napsány v PHP.
Ladění: díky službě Xdebug má PHP ladění první třídy včetně vzdáleného ladění, které se stává čím dál důležitější v souvislosti s rozvíjejícím se virtuálním strojem světa Vagrant a Docker, které se používají na vývojové pracovní stanici. Být schopen snadno ladit vzdáleně je obrovské plus.
Rozsáhlý soubor funkcí v základní knihovně PHP (přes pět a půl tisíce), další funkce v PECL.
Nativní podpora mnoha databázových systémů.
Multiplatformnost (zejména Linux a Microsoft Windows).
Možnost využití nativních funkcí operačního systému (možná nekompatibilita s ji- ným OS).
Obrovská podpora na hostingových službách – PHP je fakticky standardem, který najdeme všude.
Poměrně slušná dokumentace.
Velmi svobodná licence, která (v protikladu k např. GPL) neobsahuje copyleft.
Zápory [10, 11, 12, 15]:
Interpretovaný jazyk: Stejně jako Python a Ruby je to interpretovaný jazyk, který je kompilován do Opcode. To může být do jisté míry překonáno ukládáním do mezi- paměti Opcode, ale doba náběhu může být problematická.
Vláknové zpracování: I po příchodu správce procesů FastCGI (FPM) je to stále soubor vláknových spouštěčů. To představuje problémy se škálovatelností, které po- stihují všechny prostředí využívající vlákna jiných jazyků, jako jsou Java Servlets,
Python WSGI, Ruby Rack nebo Microsoft IIS. Každý podproces má vlastní paměť a máte konečné množství paměti, takže jste omezen pamětí na počet připojení, které můžete podporovat. Většina jazyků disponuje pevným asynchronním I / O řešením.
PHP má ReactPHP a Icicle, ale nemá významnou základnu.
Globální rozšíření: PHP vyžaduje rozšíření, mosty mezi kódem C a PHP musí být instalovány globálně do spustitelného souboru PHP. Vyžadují úpravy globálního konfiguračního souboru, aby byly přístupné. To vyžaduje, aby se při nasazování apli- kací podílel správce systému. To také ztěžuje používání rozšíření u hostovaných apli- kacích. Většina ostatních interpretovaných jazyků poskytuje podporu k instalacím rozšíření správce balíčků (package manager).
Malá podpora IoT: Většina interpretovaných jazyků, s výjímkou Node.js, mají mi- nimální komunitu internetu věcí (IoT), ale pro PHP se zdá, že neexistuje žádná. Po- kud existuje, skrývá se. To může být způsobeno chybějícím zavedeným asynchron- ním I / O frameworkem, který je potřebný pro správné zpracování I / O.
Nábor PHP vývojářů: Vzhledem k nižší bariéře vstupu a žádné skutečné představě o tom, co může být „Senior PHP Developer“, je opravdu těžké najít dobré talenty v PHP na úrovni seniorů. Najdete zde vývojáře nejvyšší úrovně, ale bude to mnohem těžší najít než jiné jazyky.
Vnímání Jazyka: Vzhledem k nízké bariéře vstupu a populárním, ale starším kódo- vým základům, jako je WordPress, má vnější svět tendenci sledovat PHP jako nejistý a začátečnický jazyk. Nemyslím si, že PHP se za deset let považuje za super a ino- vátorské. Toto vnímání může způsobit skutečné problémy pro vývojáře i firmy. V případě vývojářů na nejvyšší úrovni může být vaše hodnota a prodejnost jako vývo- jáře omezena, pokud váš životopis je silně orientován na PHP. Vývojáři zřídkakdy dostanou příležitost pracovat na něčem, co se objevuje, protože PHP je zřídkakdy jazykem, který se nejprve využívá pro vývoj rozvíjejících se technologií nebo pro- cesů. Podívejte se na koncept „IoT“ výše. Jako společnost může být vaše hodnota a důvěryhodnost negativně ovlivněna na základě vnímání PHP. Pokud se snažíte získat kapitál nebo prodat svou firmu, bude mít aplikace Node.js nebo Java s průměrnými vývojáři úrovně zřejmě více finančně životaschopné než mít tým nejlepších inženýrů PHP za stejnou cenu.
Jazyk PHP byl dlouho definován pouze svou implementací, oficiální specifikace ja- zyka byla oznámena na konci července 2014.
Nekonzistentní pojmenování funkcí, např.: strpos(), strchr(), ale str_replace(), str_pad().
Nejednotné názvosloví skupin funkcí, např.: mysql_XXXX, imap_XXXX, json_XXXX (s podtržítkem) versus imageXXXX, bcXXXX, gzXXXX (bez podtr- žítka).
Nejednotné pořadí parametrů, např.: array_map() vs. array_filter().
Ačkoliv jazyk podporuje výjimky, jeho knihovna je používá jen zřídka.
Slabší podpora Unicode, pouze přes PHP knihovnu (ve verzích po PHP 5 má být Unicode řetězec jako základní typ).
Ve standardní distribuci chybí ladící (debugovací) nástroj.
Po zpracování požadavku neudržuje kontext aplikace, vytváří jej vždy znovu (osla- buje výkon).
3.1.2 PERL
Perl je interpretovaný programovací jazyk vytvořený Larry Wallem v roce 1987. S rozvojem internetu se Perl stal velmi populárním nástrojem pro tvorbu CGI skriptů (v praxi používaný zejména na WWW serverech). Perl zahájil svou éru jako skriptovací jazyk, náhrada jazyka AWK a interpretru SH. Největšího rozšíření dosáhl ve verzi 4 z roku 1991. Verze 5 přinesla četná vylepšení, především výkonné datové struktury a možnost objektového programování.
V poslední době získal Perl oblibu mimo jiné v bioinformatice [15].
Umožňuje psát krátké programy jednoduše a rychle, a přitom nebrání v psaní těch složitých.
Jeden ze způsobů je přitom obvykle velmi stručný, takže Perl získal nezaslouženou pověst jazyka, ve kterém se tvoří nesrozumitelný a neudržovatelný kód. Tato kritika ale není opráv- něná, Perl je vhodný k řešení malých i velkých problémů. Schopnosti a nástroje, které se používají u velkých projektů, lze použít i v krátkých skriptech [15].
Výhody [15]:
Interpretovaný jazyk – rychlý vývoj bez nutnosti kompilace a linkování.
Přes 18 000 volně dostupných modulů třetích stran v CPAN (Comprehensive Perl Archive Network).
Pojmenování, kategorizace, dokumentace, testování a instalace modulů jsou standar- dizovány a zpřístupňují prakticky veškerá dostupná rozhraní a knihovny.
Efektivita programování.
Automatická práce s pamětí (není třeba explicitně alokovat a uvolňovat paměť).
Pokročilé datové typy např. asociativní pole neboli hash.
Svobodný software, licencován pod Artistic License či GNU.
Snadné spojování již hotových komponent (modulů).
Reference na statické, dynamické i anonymní datové struktury.
Umožňuje procedurální, funkcionální i objektově orientované programování.
Snadná práce s textem a značkovacími jazyky (XML, HTML…).
Perl podporuje znakovou sadu Unicode a je (byl) Y2K kompatibilní.
Stabilita – mnoho let vyvíjený programovací jazyk.
Perl umí zacházet se zakódovanými webovými daty, mezi něž patří např. transakce u elektronického obchodování.
Perl může být součástí web serverů, čímž může dojít ke zrychlení až o 2 000 %.
Modul umožňuje web serveru Apache vložení Perlu s výhodami, jako u PHP.
Rozsáhlá dokumentace a literatura, komunita kolem Perlu, konference, … Nevýhody [15]:
Nedisciplinovaný programátor může velmi snadno vytvářet nesrozumitelný kód.
Při některých aplikacích se může projevit neefektivnost dynamicky typovaného ja- zyka ve srovnání se staticky typovanými jazyky, zejména spotřeba paměti.
Kruhové odkazy a problematika jejich destrukce.
Mnozí tvrdí, že je to jazyk nevhodný pro výuku programování.
3.1.3 JavaScript
Vedle HTML a CSS je JavaScript (standardizovaný jako ECMAScript) považován za jednu z velkých tří hlavních komponent webových stránek. Zaměstnaný většinou webových strá- nek, JavaScript je skriptovací jazyk, který obvykle běží v prohlížeči a dělá webové stránky dynamické a interaktivní. Jeho syntaxe (zápis zdrojového textu) patří do rodiny jazyků C/C++/Java. Ale JavaScript je od těchto jazyků zásadně odlišný, sémanticky (vnitřně) jde o jiný jazyk. Slovo Java je součástí jeho názvu pouze z marketingových důvodů. Program v
JavaScriptu se obvykle spouští až po stažení WWW stránky z Internetu (tzv. na straně kli- enta), na rozdíl od ostatních jiných interpretovaných programovacích jazyků (např. PHP a ASP), které se spouštějí na straně serveru ještě před stažením z Internetu. Z toho plynou jistá bezpečností omezení, JavaScript např. nemůže pracovat se soubory, aby tím neohrozil soukromí uživatele.
Výhody [13, 14]:
Javascript je spuštěn na straně klienta: To znamená, že kód je spuštěn na uživa- telském procesoru namísto webového serveru, čímž se na webovém serveru šetří šířku pásma připojení k síti a zátěž procesoru i paměti.
Javascript je poměrně snadný jazyk: Jazyk Javascript je poměrně snadné se učit a obsahuje syntaxi, která je blízká angličtině. Používá model DOM, který poskytuje různým objektům spoustu předpřipravených funkcí, což vytváří možnost pro vytvo- ření skriptu k vyřešení vlastního cíle.
Javascript je pro koncového uživatele poměrně rychlý: Jelikož je kód spuštěn na počítači uživatele, zpracování výsledků je dokončeno téměř okamžitě v závislosti na operaci.
Snadné ladění a testování: kód JavaScriptu je interpretován řádek po řádku. Chyby jsou uvedeny spolu s číslem řádku. Je velmi snadné najít chybu v kódu, opravit ji a otestovat (pokud se nejedná o chybu sémantickou).
Programování založené na událostech: JavaScript je jazyk založený na událostech.
To znamená, že při výskytu určité události se provádí určitý segment kódu. Například segment kódu může být spuštěn, když uživatel klikne nebo přesune myš nad objekt atd.
Procedurální schopnosti: JavaScript poskytuje všechny možnosti procedurálního jazyka. Poskytuje kontrolu stavu, smyčky a větvičky, které lze provést na webové stránce.
Nezávislost platformy: JavaScript je jazyk nezávislý na platformě. Každý prohlížeč podporující jazyk JavaScript může chápat a interpretovat kód JavaScript. Jakýkoli kód jazyka JavaScript lze spustit na různých typech hardwaru.
Nevýhody [13, 14]:
Problémy s bezpečností: Úryvky jazyka Javascript, jakmile jsou připojeny k webo- vým stránkám, se okamžitě spustí na klientských serverech, a proto mohou být také
použity k zneužití uživatelského systému. Zatímco určitá omezení jsou stanovena moderními webovými standardy v prohlížečích, škodlivý kód může být stále vyko- náván v souladu s nastavenými omezeními.
Vykreslení jazyka Javascript se liší: Různé vykreslovací nástroje mohou způsobo- vat různé rozložení, což bude mít za následek nesrovnalost z hlediska funkčnosti a rozhraní. Zatímco nejnovější verze JavaScriptu, co se týče vykreslování, byly zamě- řeny na univerzální standard, některé varianty stále existují.
3.1.3.1 ReactJS
React je JavaScriptová knihovna pro vytváření webových komponent. V pomyslném MVC představuje "V" neboli view vrstvu a dal by se tak přirovnat například Latte v Nette.
React je však daleko více. Přináší totiž zásadní změnu paradigmatu. S Reactem už nepíšeme kód, který něco mění, ale kód, který popisuje, jak má vypadat výsledek, což je řádově snažší úloha. Dvojnásob to pak platí, pokud tím výsledkem je "těžká váha" v podobě DOMu [17].
React spatřil světlo světa v květnu 2013. Opensourcoval ho Facebook, který ho už několik let před tím sám interně používal a vylepšoval. Prvotní vydání se však dočkalo velkého vý- směchu. Odezva byla dokonce tak špatná, že Facebook chvíli uvažoval i o jeho stáhnutí.
Terčem kritiky se stalo především míchání "HTML a programování". Podobné obavy ne- dávno vyjádřili i někteří prominentní čeští webaři. Postupně se však ukázalo, že došlo k pouze nepochopení základního konceptu, a nejen FE vývojáři si začali rychle osvojovat a užívat nové fundamenty, které React přinesl [17].
K dnešnímu dni (květen 2016 má 6600 commitů, 41 000 stargazerů a 685 contributorů a je tak jedním z nejoblíbenějších a nejaktivnějších repozitářů na GitHubu. Facebook během této doby uvolnil i další JS projekty jako React Native (React pro iOS a Android) či Immutable.js (immutable kolekce). Zajímavou knihovnou je také GraphQL, což je dotazovací jazyk, kte- rým v komponentách popíšete, jaká data ze serveru potřebují. Doplňuje ho Relay, který GraphQL umí na straně webu zpracovat a je tak zajímavou alternativou pro datovou komu- nikaci server-client, která dnes představuje nejtěžší část webové aplikace [17].
Klasické server-side webovky jsou vcelku jednoduché. Server totiž nemusí udržovat žádný stav. Přijde mu požadavek od uživatele, poslepuje dohromady nějaké řetězce (část z nich načte třeba z databáze) a celé to pak pošle uživateli do prohlížeče, který to rozparsuje a sestaví DOM [17].
Jednosměrný datový tok
Vlastnosti, neboli sada nezměnitelných hodnot, jsou předávány vykreslovací funkci kompo- nenty jako vlastnosti v její značce HTML. Komponenta nemůže přímo měnit žádné vlast- nosti, které jí byly předány, ale může je předat callback funkci, která upraví tyto hodnoty.
Tento mechanismu je vyjádřen jako "data tečou dolů, akce nahoru" [19].
JSX
Komponenty v Reactu jsou typicky psány v JSX, což je syntaxe rozšíření jazyka JavaScript umožňující citovat HTML a používat syntaxi značek HTML k vykreslení sub-komponentů.
Toto je rozšíření gramatiky specifické pro React v jazyk JavaScript, jako je zaniklý E4X.
Syntaxe HTML je zpracována do volání JavaScriptu v rámci Reactu. Vývojáři mohou také psát v čistém jazyce JavaScript. JSX je podobná další syntaxi rozšíření vytvořené společností Facebook pro PHP a to XHP [19].
Co je DOM ?
Dokumentový model dokumentu DOM (W3C Document Object Model) je platformové a jazykově neutrální rozhraní, které umožňuje programům a skriptům dynamicky přistupovat a aktualizovat obsah, strukturu a styl dokumentu [18].
Po načtení webové stránky vytvoří prohlížeč objektový model dokumentu na stránce.
Model HTML DOM je vytvořen jako strom objektů:
Obrázek 11 - Model HTML DOM [18]
S objektovým modelem získává JavaScript veškerou potřebnou sílu k vytvoření dynamic- kého kódu HTML [18]:
může změnit všechny prvky HTML na stránce
může změnit všechny atributy HTML na stránce
může změnit všechny styly CSS na stránce
může odstranit stávající prvky HTML a atributy
může přidat nové prvky a atributy HTML
může reagovat na všechny stávající události HTML na stránce
může na stránce vytvářet nové události HTML
DOM je standardem W3C (World Wide Web Consortium). DOM definuje standard pro pří- stup k dokumentům. Objektový model dokumentu DOM (W3C Document Object Model) je platformové a jazykově neutrální rozhraní, které umožňuje programům a skriptům dyna- micky zpřístupňovat a aktualizovat obsah, strukturu a styl dokumentu [18].
Standard W3C DOM je rozdělen na 3 různé části [18]:
Core DOM - standardní model pro všechny typy dokumentů
XML DOM - standardní model pro XML dokumenty
HTML DOM - standardní model pro HTML dokumenty
Výhody ReactJS [17, 19, 20]:
Nejzřejmější výhoda pro začátečníka je ta, že React nás prakticky úplně odstíní od DOMu. V React komponentách pouze deklarativně zadefinujeme strukturu (HTML) skládáním JS funkcí. Jinými slovy, popíšeme, jak má vypadat výsledná stránka na základě příchozích dat.
Optimální renderování: React si z dodaých dat poskládá svůj vlastní virtuální DOM, který pak pomocí chytrých algoritmů porovnává s tím skutečným DOMem a když najde rozdíly, tak ho nejefektivnějším možným způsobem aktualizuje. V pro- hlížeči vždy uvidíte aktuální pohled vzhledem k dodaným datům.
Je snadné vědět, jak je každá komponenta vykreslena: Stačí se podívat na funkci vykreslení (což je jediná funkce každá komponenta musí mít definovanou).
Zajišťuje srozumitelnost a usnadňuje údržbu.
Můžete použít React s jakýmkoli frameworkem (Backbone.js, Angular.js), protože je to pouze zobrazovací vrstva.
Nyní je hodně poptávky po vývojářích se zkušeností s ReactJS.
Využití Flux architektury a její implementace React-Redux je poměrně jednoduché ale velmi užitečné při implementaci aplikace.
Velká a velmi se rozrůstající komunita stejně jako velké množství knihoven a hoto- vých komponent.
React-Bootstrap aneb obecně použitelné responzivní komponenty.
Testování je snadné testovat a můžete také integrovat některé nástroje, jako je Jest.
JSX usnadňuje čtení kódu vašich komponent. Je také velmi snadné vidět rozložení nebo jak jsou komponenty vzájemně spojeny.
Strmá křivka učení.
Za prvé, mnoho vývojářů přechází na ReactJS kvůli mnoha výhodám, které má v porovnání s ostatními UI frameworky. Je těžké vypsat nevýhody, protože s nimi existuje mnoho výhod [19].
Nevýhody ReactJS [19, 20]:
Knihovna samotná je poměrně velká.
Při porovnávání s monolitickým frameworkem, jako je AngularJS, zjistíte, že nee- xistuje předdefinovaný způsob, jak strukturu vaší aplikace (jako josu služby, řídicí jednotky a views v Angularu). To znamená, že je odpovědností developera, aby našel své vlastní způsoby, jak účinně spravovat několik částí aplikace bez předem defino- vané struktury. To může vést k významným režijním a dlouhým vývojovým časům, kdy navrhovaná struktura je špatná nebo neúčinná.
Je to jen zobrazovací vrstva, stále musíte připojit svůj kód pro požadavky Ajax, udá- losti a tak dále.
3.1.3.2 AngularJS
AngularJS je framework s otevřeným zdrojovým kódem, vyvíjený společností Google a ko- munitou programátorů. AngularJS je často považován za framework na tvorbu SPA pro- jektů. Tento framework implementuje architektonický vzor MVC. Ve frameworku se nachá- zejí šablony pohledu, které jsou reprezentovány kódem v jazyce HTML / HTML5. V šablo- nách se využívá deklarativní přístup programování, pomocí kterého se pohledy propojují s daty (modely). Deklarativní přístup programování je realizován pomocí tzv. direktiv. Pohled vzniká, když do šablony vložíme data z příslušného modelu.
Jinou logickou jednotkou v kontextu MVC architektury jsou kontrolery, které obsluhují ur- čitou část uživatelského rozhraní. Kontroler se tedy váže k určitému HTML elementu, při- čemž může být navázán i k více. V elementu je vytvořen kontext kontroleru, co v praxi znamená, že uvnitř elementu je možné využívat funkcionalitu kontroleru. V kontroleru se typicky nachází služba $scope, která reprezentuje daný kontext. Tento kontext je uložen do hierarchické struktury aplikace, a tedy máme jeden rodičovský kontext rootScope, pod kte- rým jsou následně jeho potomci. Modelem je objekt reprezentující datovou jednotku, zpra- vidla uloženou v kontextu kontroleru, pomocí které klientská část aplikace uchovává aktu- ální data [21].
Synchronizace mezi modelem a rozhraním je realizována pomocí techniky oboustranného provázání dat (Two Way Data-Binding). Obdoby tohoto mechanismu se nacházejí také ve frameworcích Ember.js a KnockouJS. První směr je z rozhraní do modelu. Toto zajišťuje automatický přenos dat z rozhraní do modelu. V praxi to znamená, že když změníme vstup na rozhraní, tato změna se promítne do modelu daného kontextu. Druhá, a tudíž opačná cesta je fakt, že po změně modelu se tato změna promítne do všech částí rozhraní, kde je model použitý [21].
Součástí frameworku je také systém na využití jednotlivých modulů. V praxi to funguje tak, že na tvorbu aplikace se využívá jádro frameworku AngularJS, a následně se přidávají po- třebné moduly, jako moduly na práci se směrováním, animacemi a podobně. Programátor si může vytvářet i moduly vlastní. AngularJS jako framework však poskytuje mnohem více než jen rozdělení kódu do logických vrstev, propojení vrstev, a tedy zjednodušení přístupu.
AngularJS poskytuje sadu užitečných funkcí, direktiv, služeb a podobně [21].
Výhody [21]:
Automatické obousměrné provázání rozhraní s modelem.
Velká komunita a výborná dokumentace.
Poskytuje velmi dobrou strukturu - kontrolery, direktivy, služby, moduly, filtry a po- dobně.
Jako šablona slouží jazyk HTML.
Vysoce dobrá testovatelnost kódu.
Synchronizace se serverem - modely mohou být provázány se serverem pomocí Rest- ful API.
Nevýhody [21]:
Komplexnost zápisu direktiv v HTML může být nepřehledná a vést k syntaktickým chybám.
Zavádění do stávajících projektů vyžaduje obvykle změnu struktury aplikace.
V případě velkého počtu interaktivních elementů na stránce je AngularJS pomalý (Potřeba neustálé synchronizace).
3.1.4 ASP.NET
ASP.NET je součást .NET Frameworku pro tvorbu webových aplikací. Je nástupcem tech- nologie ASP (Active Server Pages) a přímým konkurentem JSP (Java Server Pages). Ačko- liv název ASP.NET je odvozen od starší technologie pro vývoj webů ASP, obě technologie jsou velmi odlišné. ASP.NET je založen na CLR (Common Language Runtime), který je sdílen všemi aplikacemi postavenými na .NET Frameworku. Programátoři tak mohou reali- zovat své projekty v jakémkoliv jazyce podporujícím CLR, např. Visual Basic.NET, JScript.NET, C#, Managed C++, ale i mutace Perlu, Pythonu a další. Aplikace založené na ASP.NET jsou také rychlejší, neboť jsou před-kompilovány do jednoho či několika málo DLL souborů, na rozdíl od ryze skriptovacích jazyků, kde jsou stránky při každém přístupu znovu a znovu parsovány [15, 16].
Koncept ASP.NET WebForms ulehčuje programátorům přechod od programování klasic- kých aplikací pro Windows do prostředí webu: stránky jsou poskládány z objektů, ovláda- cích prvků (Controls), které jsou protějškem ovládacích prvků ve Windows. Při tvorbě we- bových stránek je možné používat ovládací prvky jako tlačítko (Button), nápis (Label) a další. Těmto prvkům lze přiřazovat určité vlastnosti, zachytávat na nich události atd. Tak, jako se ovládací prvky pro Windows samy kreslí do formulářů na obrazovku, webové ovlá- dací prvky produkují HTML kód, který tvoří část výsledné stránky. ASP.NET MVC je další oficiální framework postavený na technologii ASP.NET. Tento framework umožňuje snad- něji vyvíjet aplikace podle architektury Model-View-Controller [15, 16].
Výhody [15, 16]:
Vyšší rychlost aplikace (díky kompilovanému kódu).
Jednodušší odladění chyb při samotném vývoji.
Uživatelsky definované ovládací prvky lze použít jako šablony (redukce kódu).
Velké množství ovládacích prvků a knihoven tříd (rychlejší vývoj aplikací).
Možnost využít mnoha programovacích jazyků.
Schopnost cachovat celou stránku nebo její část.
Od verze 2 generuje ASP.NET validní HTML 4.0 / XHTML 1.0/1.1 a JavaScript.
Nevýhody [15, 16]:
Špatná rozšířenost mezi hostingy a vysoká cena za hostování.
Uzavřený kód ve vlastnictví Microsoftu.
Špatná, případně žádná podpora pod jiným operačním systémem než MS Windows.
Session jednotlivých verzí není kompatibilní.
Vysoká závislost na JavaScriptu.
3.1.4.1 ASP.NET WebForms
Ačkoliv webový protokol HTTP je sám o sobě bezstavový, událostmi řízené programování zachování stavu (uchování kontextu mezi jednotlivými požadavky) vyžaduje. ASP.NET tento problém řeší kombinací HTML a JavaScriptu pomocí dvou základních technik. Vie- wState uchovává informace mezi postbacky (opakovaným odesíláním formuláře na server) v zakódovaném tvaru ve skrytých formulářových polích. Jeho výhodou je, že využívá pouze HTML a nevyžaduje žádnou speciální podporu na straně serveru ani klienta. Nevýhodou je, že se mezi serverem a klientem přenáší větší objem dat, zejména je-li ViewState využíváno nesprávně [15, 16].
Session State oproti tomu ukládá veškeré informace na straně serveru a předává (typicky jako cookie nebo součást URL) pouze jednoznačný identifikátor. To sice zmenšuje objem přenášených dat, ale klade vyšší nároky na výkon serveru. Pokud se sessions používají ne- správně, může být server náchylný i k Denial of Service útokům. Oproti ASP umožňuje ASP.NET ukládání session state do samostatného procesu nebo na SQL server. To zjedno- dušuje použití session ve webových farmách, zvyšuje výkon a umožňuje stav zachovat i při restartu serveru [15, 16].
3.1.4.2 ASP.NET MVC
Na přelomu roku 2007 a 2008 ohlásila firma Microsoft plán na vývoj ASP.NET MVC fra- meworku. Tento framework umožňuje tvorbu webových aplikací podle softwarové archi- tektury Model-View-Controller. ASP.NET MVC má představovat alternativu oproti
WebForms. Narozdíl od WebForms aplikace vytvořené pomocí ASP.MVC nevyžadují Vie- wState a dají se snadněji testovat. V současné době se ASP.NET MVC nachází ve verzi 3 Beta (5. února 2011). Microsoft ujistil komunitu, že vydáním ASP.NET MVC nekončí vývoj WebForms (časem kdo ví) [15, 16].
3.2 Desktopový klienti
3.2.1 Java
Java je objektově orientovaný programovací jazyk, který vyvinula firma Sun Microsystems a představila 23. května 1995. Jde o jeden z nejpoužívanějších programovacích jazyků na světě. Podle TIOBE indexu je Java nejpopulárnější programovací jazyk. Díky své přenosi- telnosti je používán pro programy, které mají pracovat na různých systémech počínaje čipo- vými kartami (platforma JavaCard), přes mobilní telefony a různá zabudovaná zařízení (plat- forma Java ME), aplikace pro desktopové počítače (platforma Java SE) až po rozsáhlé dis- tribuované systémy pracující na řadě spolupracujících počítačů rozprostřené po celém světě (platforma Java EE). Tyto technologie se jako celek nazývají platforma Java. Dne 8. května 2007 Sun uvolnil zdrojové kódy Javy (cca 2,5 miliónů řádků kódu) a Java bude dále vyvíjena jako open source [23].
Výhody [22]:
Učení jazyka Java je snadné: Přestože toto prohlášení může podnítit mnoho proti- kladných názorů, zůstává to fakt. Dokonce i když člověk nemá programovací zázemí a nikdy se nenaučil úvodní programovací jazyky jako C ++, učením se konceptů Java to nebude překážkou. Bez nutnosti používat a chápat magické znaky, jako jsou „Ge- nerics Angle Brackets“ atd., podporuje Java anglickou syntaxi a příkazy. Po pocho- pení počátečních hodin se zbytek často stává jednodušším.
Používá koncepci OOP: Aplikace, které jsou vyvinuty pomocí konceptu Java OOP (Object Oriented Programming), jsou kompetentnější, protože jsou rozšiřitelné, šká- lovatelné a flexibilní. Má bohatou knihovnu standardních návrhových vzorů a dal- ších osvědčených postupů. Otevřené zdroje, jako je Spring, atd., Používají koncepty objektově orientovaného programování, což je ještě přizpůsobivější pro vývoj apli- kací v Javě.
