Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování
Návrhy webových internetových aplikací Bakalářská práce
Autor:
Jiří Nachtigall Informační technologie, MPIS
Vedoucí práce:
Praha
doc. Ing. Stanislav Horný, CSc.
Duben, 2010
Prohlášení: Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a s použitím uvedené literatury.
V Praze, dne
…………..………….. Jiří Nachtigall
Anotace Tato práce se zaměřuje na oblast návrhu internetových aplikací. Podrobně popisuje celý proces návrhu počínaje analýzou za použití k tomu určených nástrojů jako je use case a user story. Další částí procesu je návrh technologického řešení, které se skládá z výběru serverového řešení, programovacích technik a databází. Jako poslední je zmíněn návrh uživatelského rozhraní pomocí drátěných modelů a návrh samotného designu internetové aplikace.
Annotation This work focuses on web application design. It describes whole process of design in detail. It starts with analysis using some tools especially created for this purpose like use case and user story. Next part of the process is technical design which consists from selection of server solution, programming language and database. And finally user interface prepared using wireframes is mentioned here alongside with graphical design of the web application.
Obsah Úvod ...................................................................................................................................... 6 1.
Analýza požadavků ....................................................................................................... 7 1.1
Požadavky ............................................................................................................... 7
1.1.1
Typy požadavků .............................................................................................. 8
1.1.2
Dokumentace ................................................................................................... 8
1.2
Use case analýza ..................................................................................................... 9
1.2.1
Realizace.......................................................................................................... 9
1.2.2
Popis ................................................................................................................ 9
1.2.3
Třídy analýzy ................................................................................................... 9
1.2.4
Odpovědnosti ................................................................................................... 9
1.2.5
Asociace ........................................................................................................ 10
1.2.6
Chování.......................................................................................................... 10
1.2.7
Popis atribut ................................................................................................... 11
1.3
Use cases ............................................................................................................... 11
1.3.1
Zaměření ........................................................................................................ 12
1.3.2
Stupeň detailu ................................................................................................ 13
1.3.3
Notace ............................................................................................................ 14
1.3.4
Šablony .......................................................................................................... 14
1.3.5
Omezení ......................................................................................................... 18
1.4
Use case diagramy ................................................................................................ 19
1.4.1 1.5
User stories ........................................................................................................... 21
1.5.1
Vytváření user story ...................................................................................... 22
1.5.2
Příklady.......................................................................................................... 22
1.5.3
Použití ............................................................................................................ 22
1.5.4
Výhody .......................................................................................................... 23
1.5.5
Omezení ......................................................................................................... 23
1.6 2.
Use case vztahy ............................................................................................. 20
Shrnutí user stories a use cases ............................................................................. 24
Design architektury...................................................................................................... 24 2.1
Serverová řešení .................................................................................................... 25
2.1.1
LAMP ............................................................................................................ 25
2.1.2
WINS ............................................................................................................. 28
2.2
2.2.1
PHP ................................................................................................................ 32
2.2.2
Python ............................................................................................................ 34
2.2.3
Ruby .............................................................................................................. 34
2.2.4
Java ................................................................................................................ 36
2.3
3.
4.
Aplikační vrstva .................................................................................................... 31
Databáze................................................................................................................ 37
2.3.1
MySQL .......................................................................................................... 43
2.3.2
Oracle ............................................................................................................ 45
2.3.3
PostgreSQL.................................................................................................... 46
2.3.4
MS SQL Server ............................................................................................. 48
Wireframe design ........................................................................................................ 49 3.1
Papírové prototypování ......................................................................................... 50
3.2
Microsoft Office Visio .......................................................................................... 51
3.3
Axure RP Pro ........................................................................................................ 52
Visual design ............................................................................................................... 53
Závěr .................................................................................................................................... 56 Seznam použité literatury .................................................................................................... 58 Seznam obrázků................................................................................................................... 61 Seznam tabulek .................................................................................................................... 61
Úvod Celosvětová síť Internet zažívá v posledním desetiletí velký rozmach. Není proto divu, že se spousta vývojářů softwarových aplikací začíná orientovat na vývoj internetových aplikací. Na samém počátku se vyvíjely pouze statické webové prezentace, které se postupně doplňovaly o nové prvky, až se postupem času dospělo k propracovaným a složitým aplikacím. Tyto aplikace těží z řady výhod, které běžným uživatelům poskytují. Jde především o možnost přístupu k takové aplikaci prakticky odkudkoliv bez nutnosti jakékoliv instalace. Zároveň ale umožňují chování velice podobné jako běžné aplikace instalované na konkrétním počítači. Průběžně tak vzniká velké množství technologií, nástrojů a platforem, které nabízí vývojářům široké možnosti využití. Hlavním omezujícím prvkem internetových aplikací je tak samotný internetový prohlížeč, přes který se k takovýmto aplikacím přistupuje. V praxi to pak vypadá tak, že aplikace je uživateli prezentována přes internetový prohlížeč pomocí základních technologií, jako jsou HTML, CSS, JavaScript a další. Samotná implementace aplikace však již není závislá na internetovém prohlížeči a jeho schopnostech, ale může být naprosto odlišná. Tato část aplikace je tvořená pomocí serverových technologií, jako jsou PHP, CGI skripty, databáze. Základní podmínkou však zůstává nutnost standardního výstupu, který je schopen internetový prohlížeč správně zobrazit. Hovoříme tak o architektuře klient/server, kde se jeden či více klientů připojují k serveru, na kterém běží potřebné služby a který poskytuje obsah. V poslední době se rozmáhá využívání nové technologie AJAX, která dovoluje klientu přistupovat pomocí dynamického generování přímo ke zdroji na serveru. Cílem mé bakalářské práce je seznámení s problematikou návrhu webových internetových aplikací, shrnutí možných nástrojů a technologií, které je možné využít pro jejich tvorbu. Díky velkému rozmachu internetu je takových technologií nepřeberné množství, proto jsem se rozhodl zaměřit vždy na danou oblast technologického řešení obecně a poté vybrat několik zástupců pro každou oblast a ty se pokusit podrobněji popsat.
6
1. Analýza požadavků Pojmy analýza a syntéza pochází z řečtiny, kde znamenají „rozebrat“, respektive „dát dohromady“. Tyto termíny se používají ve většině moderních vědeckých disciplín od matematiky a logiky po ekonomii a psychologii. Obecně je analýza definována jako postup, při kterém rozebíráme celek na jednotlivé části a komponenty. Vývoj informačního systému obecně často zahrnuje využití systémového analytika. Když je informační systém vyvíjen, systémová analýza se skládá z několika kroků. 1. Realizační studie určující, zda je projekt ekonomicky, sociálně, technologicky a organizačně proveditelný. 2. Shromažďování podkladů pro zjištění požadavků koncových uživatelů systému. 3. Posouzení jak budou koncoví uživatelé se systémem pracovat ve smyslu zkušeností s používáním, pro co bude systém využíván, atd.
1.1 Požadavky Požadavek je jednotlivě zdokumentovaná potřeba toho, co by měl produkt nebo služba vykonávat. Toto je běžně užíváno v softwarovém inženýrství. Můžeme říci, že je to prohlášení identifikující nutný atribut, schopnost, charakteristiku nebo kvalitu systému tak, aby to uživateli přinášelo hodnoty a bylo mu užitečné. Sada požadavků je užívána jako vstupy do návrhu etap vývoje produktu. Tyto požadavky jsou rovněž důležitý vstup do procesu ověřování, protože testy by se měly vracet ke specifickým požadavkům. Požadavky ukazují které elementy a funkce jsou nezbytné pro konkrétní projekt. Fáze požadavků může být rozdělena na odvozování, analýzu, specifikaci a ověřování.
7
Obrázek 1: Analýza požadavků je první etapa v procesu vývoje
Zdroj: http://en.wikipedia.org/wiki/File:SE_Process.jpg
1.1.1 Typy požadavků Požadavky jsou obvykle rozděleny do následujících kategorií. -
Funkční požadavky popisují funkcionalitu systému, kterou má systém vykonávat.
-
Nefunkční požadavky jsou ty, které vymezují řešení. Někdy jsou označovány za požadavky kvality. Mohou být dále klasifikovány na požadavky použitelnosti, vzhledu, účinnosti, udržovatelnosti, bezpečnosti, spolehlivosti, atd.
-
Omezující požadavky jsou ty, které vymezují řešení. Bez ohledu na to, jak je problém vyřešen, omezující požadavky musí být dodrženy.
V softwarovém inženýrství je však tato klasifikace zbytečná, protože mohou být implementovány pouze funkční požadavky.
1.1.2 Dokumentace Požadavky jsou obvykle psány jako prostředek komunikace mezi zúčastněnými stranami. To znamená, že by měly být srozumitelné jak pro běžné uživatele, tak i pro vývojáře. Jeden běžný způsob dokumentace je uvedení toho, co by měl systém dělat. Dalšími způsoby jsou Use cases a User stories.
8
1.2 Use case analýza Use case analýza je hlavní forma pro sběr uživatelských požadavků na nový software, systém nebo úkol, který je nutné splnit. Primárními cíly use case analýzy jsou: návrh systému z pohledu uživatele, komunikace chování systému podle uživatelských podmínek a popis veškerého externě viditelného chování. Dalším úkolem use case analýzy je komunikovat systémové požadavky, jak bude systém užíván, role uživatelů v systému, jak systém reaguje na uživatelské podněty, co uživatel od systému získá a jakou hodnotu uživatel od systému získá. Existuje mnoho variant jak vypracovat use case analýzu a nalezení správně metody může nějakou dobu trvat.
1.2.1 Realizace Realizace popisuje, jak je konkrétní use case realizován v rámci návrhu modelu, pokud jde o spolupráci objektů. Krok realizace nastavuje rámec, v němž je vznikající systém analyzován. Toto je místo, kde je dokumentován prvotní, nejobecnější nástin požadavků systému. To znamená hrubé rozdělení procesů, aktérů a dat požadovaných pro tento systém. Jedná se o to, co tvoří jednotlivé třídy analýzy.
1.2.2 Popis Jakmile je obecný nástin dokončen, následuje popis chování systému, které bude viditelné potencionálnímu uživateli systému. Celkovým cílem tohoto kroku je poskytnout dostatek informací k pochopení, které třídy budou pro tento systém vyžadovány. Příliš mnoho detailů může vést k tomu, že bude později systém obtížně změnitelný.
1.2.3 Třídy analýzy Tento krok zužuje seznam tříd na ty třídy, které jsou schopné vykonávat chování nutné k tomu, aby byl systém správně fungující. Neexistují-li žádné třídy pro tento systém, pak musí být vytvořeny, aby bylo možné tento krok dokončit. Třídy mohou být vytvořeny mnoha způsoby z mnoha zdrojů. Například se může jednat o předchozí podobné systémy, podnikové modely a data mining. Jakmile jsou třídy vytvořeny a list zúžen, musí se mezi nimi vytvořit relace, nyní nazývané třídy analýzy, které modelují úkol systému.
1.2.4 Odpovědnosti Pro každou, v předchozím kroku definovanou, třídu analýzy musí být detailně popsány odpovědnosti. To zajistí, že každá jednotlivá třída bude mít na starosti úkol, na kterém 9
nebude pracovat jiná třída v systému. Odpovědnosti jednotlivých tříd by se neměly vzájemně překrývat.
1.2.5 Asociace Po podrobném popisu odpovědností každé třídy analýzy musí být vyjasněny vztahy mezi třídami, což probíhá ve 4 krocích. 1. Identifikace tříd, které budou použity. 2. Identifikace možných vztahů mezi třídami. 3. Popis povahy vztahů takovýchto tříd. 4. Pokud je to možné, určit násobnost vztahu. To znamená zjistit, kolik jich z první třídy odpovídá jednomu objektu v druhé třídě tohoto vztahu. Na následujícím obrázku je diagram, kde každý box představuje třídu a spojnice mezi nimi znázorňují jejich vzájemné relace. Obrázek 2: Příklad asociace mezi třídami
Zdroj: http://en.wikipedia.org/wiki/File:Use_Case_Analysis_Relationships1.JPG
1.2.6 Chování Jakmile jsou vztahy mezi třídami vyjasněny, dalším postupem je podrobný popis chování tříd a způsobu jejich interakce s cílem dokončení systému. To znamená určit, jak třídy komunikují a posílají zprávy po časové ose vývoje systému. Toto je odvozeno z odpovědností dříve definovaných tříd. Definování, které třídě je zpráva určena, vyplývá z asociací nastavených v předchozím kroku. 10
1.2.7 Popis atribut Během use case analýzy se mohou objevit některé atributy tříd a objektů potřebných k dokončení jejich úkolů. Ty můžou být ve formě datových proměnných nebo funkcí. Některé z těchto atributů mohou být odvozené z předchozích kroků, zatímco ostatní jsou všeobecné předpoklady z obecných znalostí (např. všechny moderní počítače mají operační systém, procesor, vstupně výstupní zařízení). Obrázek 3: Příklad popsaných atributů navazující na obrázek 2
Zdroj: http://en.wikipedia.org/wiki/File:Use_Case_Analysis_Described1.JPG
1.3 Use cases Use case je popis chování systému reagujícího na požadavky přicházející z vně tohoto systému z pohledu uživatele. Popisují interakci mezi jedním nebo více aktéry a samotným systémem, reprezentovanou jako sekvence jednoduchých kroků. Aktéři jsou něco či někdo vně systému, kteří se podílí na sekvenci akcí v dialogu se systémem za účelem dosažení nějakého úkolu. Aktéři mohou být koncoví uživatelé, ostatní systémy nebo hardwarová zařízení. Každý use case je kompletní sada událostí popsaná z pohledu aktéra. Každý use case popisuje situaci, jak bude aktér komunikovat se systémem, aby dosáhl konkrétního cíle. Z use case může být vytvořen jeden či více scénářů odpovídající detailům každé možné cesty vedoucí k dosažení tohoto cíle. Při tom se vyhýbají technickému žargonu, místo toho preferují jazyk koncového uživatele či příslušného odborníka. Use cases jsou 11
často spoluautorským dílem systémových analytiků a koncových uživatelů. Pro grafické znázornění use case daného systému může být využit UML1 use case diagram. Use cases nejsou normalizovány žádným konsorciem na rozdíl od UML, které je normalizováno OMG2. Historie use case se datuje do roku 1986, kdy Ivar Jacobson, pozdější důležitý přispěvatel k UML a RUP3, formuloval vizuální modelovou techniku pro specifikování use cases. Mnoho dalších poté přispívalo k vylepšení této techniky. Během 90. let 20. století se use case stal jednou z nejběžnějších praktik pro zachycení funkčních požadavků. To se týká hlavně objektově-orientované komunity, kde vznikly, ale jejich použitelnost se neomezuje pouze na objektově-orientované systémy, protože use cases nejsou přirozeně objektově orientované.
1.3.1 Zaměření Každý use case se zaměřuje na popis toho, jak dosáhnout cíle nebo úkolu. Pro většinu projektů to znamená nutnost použití více, možná desítek, use cases pro definování rozsahu nového systému. Stupeň formálnosti konkrétního projektu a fáze projektu ovlivní úroveň detailů požadovaných v každém use case. Use cases by neměly být zaměňovány s funkcemi zmiňovaného systému. Use case může být spojen s jednou nebo více funkcemi a funkce může být spojena s jedním nebo více use cases. Use case definuje interakci mezi externím aktérem a uvažovaným systémem za účelem dosažení cíle. Aktér specifikuje roli hranou osobou nebo věcí interagující se systémem. Stejná osoba využívající systém může být reprezentována jako různí aktéři, protože hrají různé role. Use cases jednají se systémem jako s černým boxem a interakce se systémem, včetně systémových reakcí, jsou vnímány jako zvenčí systému. Jedná se o záměrný přístup, 1
Standardizovaný modelovací jazyk v oblasti softwarového inženýrství
2
Konsorcium původně zaměřené na tvorbu standardů pro distribuované objektově orientované systémy a
nyní zaměřené na modelování a modelově založené standardy 3
Framework vývojového procesu vytvořený divizí IBM
12
protože nutí autora soustředit se na to, co musí systém udělat a ne na to, jak to bude uděláno a vyhýbá se tím chybnému vytváření předpokladů o tom, jak bude funkcionalita vyřešena. Use cases mohou být popsány na abstraktní úrovni (business use case, někdy nazývaný základní use case), nebo na systémové úrovni (system use case). Rozdíl mezi nimi je v rozsahu. -
Business use case je popsán netechnologickou terminologií, která přistupuje k obchodním procesům jako černý box a popisuje obchodní proces, který je použit svým obchodním aktérem k dosažení svých cílů. Popisuje proces, který poskytuje nějakou hodnotu obchodnímu aktérovi a popisuje, co tento postup dělá. Business Process Mapping je další metoda pro tuto úroveň obchodního popisu.
-
System use case je zpravidla popsán na úrovni funkcionality systému a definuje funkci nebo službu, kterou systém uživateli poskytuje. Popisuje, co aktér svou interakcí se systémem získá. Z tohoto důvodu se doporučuje začít specifikaci slovesem (např. zvolit platbu, vytvořit objednávku, stornovat objednávku).
1.3.2 Stupeň detailu Alistair Cockburn, v Psaní efektivních use cases, identifikuje tři úrovně detailu v psaní use cases. -
Stručný use case se skládá z několika vět, které jej sumarizují. Může být snadno vložen do buňky tabulky a v dalších sloupcích tabulky mohou být definovány priorita, trvání, technická složitost, atd.
-
Příležitostný use case se skládá z několika odstavců textu, který jej sumarizuje.
-
Kompletní use case je formální dokument založený na detailní šabloně s políčky pro různé sekce a je to nejběžnější chápání významu use case.
Některé vývojové procesy nevyžadují nic víc, než jednoduché Use cases pro definování požadavků. Nicméně některé další vývojové procesy vyžadují detailní use cases pro definování požadavků. Čím větší a složitější projekt je, tím větší je pravděpodobnost nutnosti použití detailních use cases.
13
Úroveň detailu v use case se často liší v závislosti na pokročení projektu. První use cases mohou být stručné, ale jak se vývojový proces posunuje, use cases jsou více podrobnější. To odráží rozdílné požadavky na use case. Zpočátku stačí, aby byly stručné, protože pouze shrnují business požadavky z pohledu uživatelů. Nicméně později v procesu potřebují vývojáři mnohem konkrétnější a detailnější pokyny. Rational Unified Process vybízí vývojáře k psaní stručného popisu use case v use case diagramu s přibližným popisem jako komentář a detailní popis toku událostí v textové analýze.
1.3.3 Notace V UML jsou vztahy mezi všemi (nebo souborem několika) use cases a aktéry prezentovány v use case diagramech nebo diagramech založených na notaci Ivar Jacobson’s Objectory. SysML4 a UML profil používají na úrovni systémového bloku stejný zápis. Specifický způsob užití use cases ve vývojovém procesu závisí na vývojové metodice, která je použita. V některých vývojových metodikách je stručný use case průzkum vše, co je zapotřebí. V dalších vývojových metodikách se use cases rozvíjí ve složitosti a mění charakter podle potřeby vývojového procesu. V některých metodikách mohou začít jako stručné business use cases a poté se rozvíjí ve více podrobné systémové use cases a nakonec se vyvinou do podrobných a vyčerpávajících testů.
1.3.4 Šablony Neexistuje žádná standardní šablona pro dokumentování detailních use case. Existuje velké množství konkurenčních schémat a jednotlivci jsou nuceni používat ty šablony, které pro ně nebo pro projekt, na kterém pracují, fungují. Standardizace v rámci každého projektu je důležitější než detaily konkrétní šablony. Existuje však určitá dohoda o hlavních částech; za odlišnou terminologií a uspořádáním je ukrytá podobnost mezi většinou use cases. Rozdílné šablony mají často doplňující části, např. předpoklady, výjimky, doporučení, technické požadavky. Mohou zde být i průmyslově specifické sekce.
4
Modelovací jazyk pro aplikace systémového inženýrství.
14
Use case jméno – poskytuje jedinečný identifikátor pro use case. Mělo by být napsáno ve tvaru sloveso-podstatné jméno (např. vypůjčit knihy, vybrat peníze), popisovat dosažitelný cíl a být dostatečné pro koncového uživatele, aby pochopil, o čem daný use case je. Cílově zaměřená use case analýza pojmenovává use case podle aktérových cílů, čímž se zajistí, že jsou use cases silně zaměřené na uživatele. Verze – je často potřeba pro informování čtenáře o dosažené fázi use case. Počáteční use case vyvinutý pro business analýzu může být i hodně odlišný od pokročilejší verze tohoto use case v průběhu probíhajícího vývoje. Starší verze use case mohou být stále v aktuálních dokumentech, protože mohou být užitečné pro různé skupiny uživatelů. Cíl – bez cíle je use case k ničemu. Není potřeba žádného use case, když není pro žádného aktéra potřeba dosažení cíle. Cíl stručně popisuje to, co chce uživatel s tímto use case dosáhnout. Shrnutí – slouží k zachycení podstaty use case před dokončením hlavní části. Poskytuje rychlý přehled, který umožní čtenáři pochopit o čem daný use case je, aniž by musel číst kompletní obsah. V ideálním případě shrnutí je jen pár vět obsahujících cíl a hlavního aktéra. Aktéři – aktér je někdo nebo něco vně systému, kdo jedná se systémem – primární aktér, nebo s kým jedná systém – sekundární aktér. Aktér může být osoba, zařízení, jiný systém nebo subsystém, nebo čas. Aktéři představují různé role něčeho zvenčí ve vztahu se systémem, jehož funkční požadavky jsou specifikovány. Jedinec v reálném světě může být reprezentován několika aktéry, pokud mají více odlišných rolí a cílů ve vztahu k systému. Tyto reagují se systémem a na základě toho vykonávají akce. Účastníci – účastník je jednotlivec nebo oddělení ovlivněné výstupy use case. Jednotlivci jsou většinou agenti organizace nebo oddělení, pro které je use case vytvořen. Účastník může být vyzván k přispění, zpětné vazbě nebo autorizaci use case. Sekce účastníků může obsahovat stručný popis toho, které z těchto funkcí jsou přiřazeny účastníku k vyplnění. Počáteční podmínky – definují všechny podmínky, které musí být pravdivé (tj. popisují stav systému) pro trigger (viz. dále), aby smysluplně zahájil use case. To znamená, že
15
pokud systém není ve stavu podle počátečních podmínek, chování use case je neurčité. Počáteční podmínky nejsou stejná věc jako „trigger“, pouhá skutečnost, že jsou splněny počáteční podmínky, use case nezahájí. Triggery – sekce popisující událost, která způsobí zahájení use case. Tato událost může být externí nebo interní. Pokud trigger není jednoduchá pravdivá událost (např. zákazník stiskne tlačítko), ale soubor několika podmínek, které musí být splněny, tak musí být spuštěn proces, který nepřetržitě nebo periodicky běží a testuje, zda jsou spouštěcí podmínky splněny. Spouštěcí událost je signál z trigger procesu, že jsou splněny podmínky. V otázce jak popsat co dělat v případě, že dojde ke spuštění, ale počáteční podmínky nebyly splněny, existují různé postupy. -
Jednou možností je pracovat s chybou v rámci use case jako s výjimkou. Toto je logické, protože počáteční podmínky nyní nejsou pravdivé počáteční podmínky.
-
Další možností je umístit všechny počáteční podmínky do triggeru tak, aby use case nemohl být spuštěn, když nejsou splněny počáteční podmínky a vytvořit jiný use case řešící problém.
Základní průběh událostí – minimálně každý use case by měl obsahovat primární scénář nebo typický průběh událostí, také zvaný „základní tok“ nebo „normální tok“. Hlavní základní průběh událostí je často vyjádřen jako soubor obvykle číslovaných kroků. Například: 1. systém vyzve uživatele k přihlášení, 2. uživatel vloží své jméno a heslo, 3. systém ověří přihlašovací údaje, 4. systém přihlásí uživatele do systému. Alternativní cesty nebo rozšíření – use cases mohou obsahovat sekundární cesty nebo alternativní scénáře, které jsou variacemi na hlavní téma. Každé testované pravidlo může vést k alternativní cestě, a když existuje mnoho pravidel, permutace cest se rapidně
16
zvyšuje, což může vést k velmi složitým dokumentům. Někdy je k popisu use case s mnoha pravidly a podmínkami lepší použít podmíněnou logiku nebo diagramy aktivit. Výjimky nebo to, co se stane v momentě, kdy se něco pokazí na systémové úrovni, mohou být popsány nejen v sekci alternativní cesty, ale i ve své vlastní části. Alternativní cesty využívají číslování základního průběhu událostí k ukázání, v kterém bodě se odchylují od základního scénáře a případně kde se k němu opět vrací. Záměrem je zabránění zbytečnému opakování informací. Popis výjimky by měl uvádět, jak bude systém reagovat na chybový stav, nebo pokud možno jak se bude schopen z chybového stavu zotavit. Příkladem takové alternativní cesty může být: Systém rozpozná cookie na uživatelově počítači, přejdi na krok 4 (hlavní cesta). Příkladem výjimky může být: Systém nerozpozná uživatelovy přihlašovací údaje, přejdi na krok 1 (hlavní cesta). V samotné praxi mnoho use case designérů radši dává přednost umístění kompletní série kroků do alternativního toku než odkazování se zpět na kroky základního toku. Důvodem jsou testeři, kteří mohou dostat segmenty use case za účelem vytvoření testovacích případů. Ti ale nemusí mít vždy kompletní přehled všech sekvencí. Dalším důvodem tvorby alternativních toků je možnost jejich opakovaného používání. V oblasti kontroly a hlášení chyb může být alternativní cesta shodná ve všech aspektech kromě samotného chybového hlášení. Možnost opakovaného užití alternativní cesty tak může významně ušetřit konstrukční čas. A konečně, je mnohem jednodušší číst a sledovat alternativní cestu, když jsou všechny kroky přítomny, než přeskakovat mezi základní a alternativní cestou. Navzdory výše uvedenému existuje jen málo pravidel pro definování cest. Konečné stavy – v této části jsou popsány změny stavu systému po dokončení use case. U končených podmínek je po ukončení use case zaručena jejich pravdivost. Business pravidla – jsou to psaná i nepsaná pravidla a politiky které definují, jak společnost funguje s ohledem na use case. Obchodní pravidla jsou speciálním druhem požadavku. Mohou být specifická pro konkrétní use case nebo mohou být uplatňována ve všech use cases nebo v rámci celého obchodu. Use cases by se měly jasně odvolávat na obchodní pravidla, která jsou použitelná a kde jsou aplikována.
17
Obchodní pravidla by měla být kódována společně s use case logikou a jejich provedení může vést k různým konečným stavům. Například Pravidlo2, že výběr peněz vede k aktualizaci účtu a záznam transakcí vede ke konečnému stavu úspěšného výběru, ale jen v případě platného Pravidla1, které říká, že test dostatečných finančních prostředků musí být pravdivý. Poznámky – zkušenosti ukazují, že jakkoliv dobře navržená šablona use case je, vždy jsou nějaké důležité informace, které nepasují do žádné konkrétní části. Proto všechny dobré šablony obsahují poznámkovou část, která umožňuje zaznamenání hůře strukturovaných informací. Autor a datum – tato sekce by měla uvádět, kdy byla jaká verze use case vytvořená a kdo ji dokumentoval. Měla by také obsahovat všechny verze a data z předchozích stádií vývoje, které jsou stále aktuální dokumenty. Autor je tradičně uveden v dolní části, protože to není považováno za podstatnou informaci. Use cases jsou považovány za předmět spolupráce a měly by být společným vlastnictvím.
1.3.5 Omezení Use cases mají své limity a omezení. -
Use case toky nejsou příliš vhodné pro snadné zachycení neinteraktivních požadavků systému (jako jsou například algoritmy nebo matematické požadavky) nebo nefunkční požadavky (jako například platforma, výkon, načasování). Ty jsou lépe specifikovány deklarativně jinde.
-
Use case šablony automaticky nezajišťují srozumitelnost. Srozumitelnost závisí na schopnostech pisatele.
-
Existuje křivka osvojování znalostí ve správné interpretaci use cases, jak pro koncové uživatele, tak vývojáře. Jelikož neexistují žádné zcela standardní use case definice, každá skupina si musí postupně vyvinout svou vlastní interpretaci. Některé ze vztahů, které rozšiřují, nejsou jednoznačné v interpretaci a mohou být složité pro zúčastněné strany na porozumění.
-
Zastánci extrémního programování často pokládají use cases zbytečně dokumentcentrické, preferují používání jednoduššího přístupu v podobě user story.
18
-
Pro Use case vývojáře je často obtížené určit úroveň závislosti uživatelského rozhraní pro začlenění do use case. Zatímco use case teorie navrhuje, aby se uživatelské rozhraní nepromítalo v use case, vyjádření takového pohledu na návrh může být nešikovné, protože si lze takové use cases jen těžko představit. V rámci softwarového
inženýrství
je
tento
problém
řešen
použitím
požadavků
sledovatelnosti skrze matice sledovatelnosti. -
Use cases jsou zajímavé jako výchozí bod pro testování. Avšak některá use case literatura uvádí, že use case počáteční a konečné stavy by měly být aplikovány na všechny scénáře use case (tj. všechny možné cesty prostřednictvím use case), což je omezující z hlediska testování. Pokud jsou počáteční podmínky use case natolik obecné, aby byly platné pro všechny možné use case scénáře, je pravděpodobné, že nebudou užitečné jako základ specifikování očekávaného chování při testování. Například výstupy a finální stav neúspěšného pokusu o vybrání peněz z bankomatu nejsou stejné jako úspěšný výběr. Pokud toto vyjadřují konečné stavy, budou se rovněž lišit. Pokud toto nevyjadřují, pak nemohou být použity pro specifikování očekávaného chování testu.
1.4 Use case diagramy Use case diagramy jsou formálně součástí dvou modelovacích jazyků definovaných OMG. Oba UML a SysML standardy definují grafické notace pro modelování use case s diagramy. Obecně platí, že obě grafické notace a popisy jsou důležité, protože dokumentují use case a ukazují účel, pro který aktér systém užívá. Use case diagram ukazuje pozici a kontext jednoho use case mezi ostatními. Jako organizační mechanismus, sada konzistentních a logicky svázaných use cases představuje užitečný pohled na chování systému a společné porozumění mezi zákazníkem – vlastníkem – uživatelem a vývojovým týmem.
19
Obrázek 4: Příklad use case modelu restaurace
Zdroj: http://en.wikipedia.org/wiki/File:Use_case_restaurant_model.svg Diagram na obrázku 4 popisuje fungování jednoduchého systému restaurace. Use cases jsou reprezentovány ovály a aktéři jsou reprezentováni figurkami. Aktér Client může objednat jídlo (volitelně objednat víno), jíst jídlo (volitelně pít víno), platit za jídlo. Na některých use cases se podílí více aktérů. V takovém případě označení asociace mezi aktérem a use case popisuje příspěvek aktéra k use case. Rám označuje hranice systému restaurace, tj. zobrazené use cases jsou součástí modelovaného systému, aktéři nikoliv.
1.4.1 Use case vztahy V praxi se často mezi use cases používají 3 vztahy. Include – v jedné formě interakce daný use case může zahrnovat další. Include je řízený vztah mezi dvěma use cases, což znamená, že chování zahrnutého use case je vloženo do chování druhého use case. První use case často závisí na výsledku vloženého use case. To je užitečné pro získání běžného chování z vícero use cases do jednoduchého popisu. Notace je přerušovaná šipka od vkládajícího use case do vkládaného se značkou «include». Nejsou zde žádné parametry nebo zpětné hodnoty. Pro zadání umístění v toku událostí,
20
v jejichž případě základní use case zahrnuje chovaní jiného, se jednoduše napíše include následovaný jménem use case, který chceme vložit, jako v následujícím toku pro sledování pořadí. Extend – v další formě interakce může daný use case (rozšíření) rozšířit jiný. Tento vztah ukazuje, že chování rozšiřujícího use case může být vloženo do rozšiřovaného use case na základě daných podmínek. Notace je přerušovaná šipka od rozšíření k rozšiřovanému use case se značkou «extend». Poznámky nebo omezení mohou být spojeny s tímto vztahem k ilustraci podmínek, za nichž bude toto chování vykonáno. Modeláři používají extend vztah k označení volitelných use case ve vztahu k základnímu. V závislosti na modelářově přístupu „volitelný“ může znamenat potenciálně nespouštěný základním use case nebo nevyžadovaným pro dosažení cíle základního use case. Generalization – ve třetí formě vztahu mezi use cases existuje generalizace / specializace. Daný use case může mít společné chování, omezení a předpoklady jako obecný use case, jednou je popsat a nakládat s ním stejným způsobem s výjimkou detailů ve speciálních případech. Notace je plná čára končící prázdnou šipkou od specializovaného use case k obecnému.
1.5 User stories User story je systémový požadavek formulovaný jednou či více větami v běžném nebo obchodním jazyce uživatele. User stories jsou využívány v agilní metodice vývoje pro specifikaci požadavků (společně s akceptačními testy). Každá user story je omezena, neměla by být příliš dlouhá. User stories by měly být psány klientem dané aplikace a jsou jejich hlavním nástrojem k ovlivnění vývoje aplikace. User stories představují rychlý způsob práce s požadavky zákazníků bez nutnosti zpracovávání rozsáhlých a formálních dokumentací a bez nadměrného vykonávání administrativních úkolů spojených s jejich správou. Záměrem user story je možnost rychlé reakce při menší režii na rychle se měnící požadavky vycházející z reálného světa. User story je neformální prohlášení požadavku tak dlouho, dokud chybí patřičná procedura akceptačního testu. Předtím, než je user story implementována, musí být zákazníkem sestavena patřičná akceptační procedura, aby se pomocí testu nebo jinak zajistilo splnění 21
stanoveného cíle. Nakonec dojde i k jisté formalizaci, když vývojář přijímá user story a akceptační proceduru jako svou práci v určitém pořadí.
1.5.1 Vytváření user story Když nadejde čas pro tvorbu user stories, jeden z vývojářů se sejde se zástupcem zákazníka. Zákazník je zodpovědný za formulaci user stories. Vývojář může zákazníkovi s formulací pomoci řadou různých otázek, jako například dotazem, zda jsou potřeba některé konkrétní funkce. Musí si však dát pozor, aby jeho myšlenky při tvorbě user story nedominovaly. Jakmile získá zákazník představu o jednotlivých user stories, sepíšou se například na poznámkové karty s názvem a popisem, který zákazník zformuloval. Pokud vývojář se zákazníkem zjistí, že některá user story není ideální (příliš dlouhá, komplikovaná nebo nepřesná), tak je tato user story přepsána tak, aby byla uspokojivá. Nicméně v extrémním programování je zdůrazněno, že user story není ani po svém sepsání definitivní. Požadavky se totiž často v průběhu vývoje mění.
1.5.2 Příklady Nyní si uvedeme několik příkladů, jak může taková user story, například při definování funkčnosti elektronického bankovnictví, vypadat. „Jako existující zákazník chci mít možnost pomocí elektronického formuláře požádat o vytvoření spořícího účtu.“ „Jako existující zákazník chci mít možnost výpisu transakční historie jednotlivých bankovních účtů s možností volby datového rozpětí.“ „Jako existující zákazník chci mít možnost zapnutí zasílání SMS informací o pohybu na bankovním účtu.“
1.5.3 Použití Jako hlavní část mnoha agilních metodik vývoje user stories definují, co bude v projektu vyvinuto. User stories jsou zákazníkem sestaveny podle priorit, aby bylo zřejmé, které jsou pro systém důležité a ty budou dále rozděleny na jednotlivé úkoly, které budou vývojáři časově ohodnocené. 22
Když přijdou user stories ve vývoji na řadu, vývojáři by měli mít možnost promluvit si o nich se zákazníkem. Krátké user stories mohou být obtížně interpretovány, mohou vyžadovat nějaké podrobnější znalosti, nebo se požadavky mohly od sepsání user story změnit. Každá user story musí mít v nějakém bodě připojený jeden či více akceptačních testů, které umožňují vývojářům story, po jejím dokončení, otestovat. Bez přesné formulace požadavků mohou v době, kdy má být produkt dodán, vzniknout nekonstruktivní argumenty prodlužující dokončení produktu.
1.5.4 Výhody Extrémní programování a ostatní agilní metodiky upřednostňují komunikaci tváří v tvář před rozsáhlou dokumentací a rychlé přizpůsobení se změně namísto soustředění se na problém. User stories toho dosahují následujícími vlastnostmi. -
Jsou velmi krátké. Představují malé kousky obchodních hodnot, které mohou být implementovány v období dnů až týdnů.
-
Dovolují vývojáři a zástupci klienta konzultovat požadavky v průběhu životního cyklu projektu.
-
Jsou nenáročné na údržbu.
-
Jsou zvažovány až v momentě jejich použití.
-
Zachovávají blízký kontakt se zákazníkem.
-
Dovolují rozdělení projektu na menší kroky.
-
Jsou vhodné pro projekty, kde se požadavky často mění nebo jsou špatně srozumitelné. Opakovaná zjištění vedou k upřesnění.
-
Usnadňují časový odhad vývoje.
1.5.5 Omezení User stories mají krom řady výhod i některá omezení, která limitují jejich užití. -
Bez doprovodných akceptačních testů mohou být interpretovány různými způsoby, díky čemuž jsou těžko použitelné jako základ dohody.
-
Vyžadují úzký kontakt se zákazníkem v průběhu celého projektu, což může být v některých případech obtížné nebo může přinášet zvýšené režijní náklady.
23
-
Mohou mít problémy se škálovatelností velkých projektů.
-
Více spočívají na kompetentních vývojářích.
-
User stories jsou považovány za prostředky k započetí konverzace. Bohužel nemusí vždy zachytit konec konverzace a neplní tak funkci spolehlivé dokumentace systému.
1.6 Shrnutí user stories a use cases Zatímco user stories a use cases slouží jako prostředek k zachycení specifických uživatelských požadavků, v zachycení vzájemných akcí mezi uživatelem a systémem jsou mezi nimi značné rozdíly. User stories prezentují informace v malém měřítku a snadno použitelné. Jsou obecně formulovány v běžném jazyce uživatele a obsahují málo podrobností a zůstávají tak otevřené pro různé interpretace. Měly by čtenáři pomoci pochopit, čeho by měl systém dosáhnout. Use cases naopak detailně popisují proces a jeho kroky a mohou být formulovány s ohledem na formální model. Use case je určen k tomu, aby poskytoval dostatečně podrobné informace k tomu, aby byl pochopen sám o sobě. Use case byl popsán jako zobecněný popis interakcí mezi systémem a jedním nebo více aktéry, kde je aktér buď uživatel, nebo jiný systém.
2. Design architektury Aplikace jsou většinou rozděleny na několik logických částí nazývaných „vrstvy“, kde je každé přidělena určitá role. Klasické aplikace jsou tvořeny pouze jednou vrstvou, která je umístěna na klientském počítači, zatímco internetové aplikace mají tendenci využívat několika-vrstvé řešení. V úvahu přichází různá řešení, nejběžnějším je ale tří-vrstvá aplikace. V této nejpoužívanější formě jsou tyto vrstvy nazývány Prezentace, Aplikace a Úložiště. První, prezentační, vrstvu tvoří internetový prohlížeč, systém využívající dynamického generování webového obsahu, jako jsou např. ASP, CGI, ColdFusion, PHP, atd., tvoří prostřední vrstvu aplikační logiky a databáze je vrstva třetí, úložná. Vše funguje tak, že internetový prohlížeč posílá požadavky prostřední vrstvě, která je spravuje tím, že je převede na dotazy a aktualizace do databáze a generuje uživatelské rozhraní.
24
Pro složitější aplikace může být 3-vrstvé řešení nedostatečné a bude potřeba využít nvrstvého přístupu, jehož největší výhodou je oddělení obchodní logiky, která je umístěna v aplikační vrstvě. Nebo to lze řešit přidáním integrační vrstvy, která oddělí datovou vrstvu od zbytku vrstev použitím snadného rozhraní pro přístup k datům. Například pro přístup k datům klientů se využije funkce „list_clients()“ místo vytváření SQL dotazu přímo na tabulku klientů v databázi. To umožňuje výměnu databáze beze změn ostatních vrstev. Někteří vidí internetové aplikace jako 2-vrstvou architekturu. To může být spojení „chytrého“ klienta, který obstarává veškerou práci a dotazy, a „hloupého“ serveru s databází. Nebo to může být naopak, „hloupý“ klient spoléhající se na „chytrý“ server. To znamená, že klient by obstarával prezentační vrstvu, server by měl nestarosti databázi (úložnou vrstvu) a obchodní logika (aplikační vrstva) by byla na jednom z těchto dvou zařízení, nebo na obou. Zatímco toto zvyšuje škálovatelnost aplikací a odděluje zobrazení od databáze, stále to nedovoluje skutečnou specializace vrstev, takže většina aplikací toto řešení brzy přeroste.
2.1 Serverová řešení Sada řešení se v IT nazývá sada softwarových subsystémů nebo komponent potřebných k získání plně funkčního řešení – produktu nebo služby. Pro vývoj internetové aplikace vývojář potřebuje použít operační systém, webový server, databázi a programovací jazyk. Nyní si zde uvedeme dvě nejpoužívanější serverová řešení.
2.1.1 LAMP LAMP je zkratka pro sadu řešení složenou z free a open source softwaru, původně vytvořený z počátečních písmen operačního systému Linux, HTTP servereu Apache, MySQL databáze a programovacího jazyku PHP, Python nebo Perl, hlavních komponent potřebných k postavení životaschopného webového serveru. Přesná kombinace softwaru zahrnutého v LAMP balíku se může lišit, zejména s ohledem k webovému skriptovacímu software, kde PHP může být nahrazeno jazykem Pearl nebo Python. Podobné podmínky existují pro v podstatě stejný softwarový balík AMP běžící na různých operačních systémech, jako např. MS Windows (WAMP), Mac OS (MAMP), Solaris (SAMP) nebo OpenBSD (OAMP).
25
Ačkoliv původní autoři těchto programů je nenavrhovali speciálně pro vzájemnou spolupráci, filosofie vývoje a sady nástrojů jsou sdíleny a vyvíjeny v úzké spolupráci. Kombinace jednotlivého softwaru se stala populární díky tomu, že je zdarma, open source a tím snadno přizpůsobitelný, i vzhledem k rozšířenosti jednotlivých komponent, které jsou součástí většiny současných distribucí Linuxu. LAMP je v současné době zdaleka nejrozšířenějším serverovým řešením, protože vývojářům nabízí řadu výhod. -
Snadné kódování – umožňuje nováčkům velmi rychlé postavení a spuštění aplikace.
-
Jednoduchá instalace – vzhledem k tomu, že PHP je standardní modul Apache, je jeho nasazení jednoduché. Jakmile máte jednou spuštěné MySQL, stačí jen jednoduše nahrát .php soubory.
-
Lokální vývoj – je snadné sestavit LAMP na svém počítači, postavit aplikaci lokálně a poté ji nainstalovat na web.
-
Levný a všudypřítomný hosting – i ten nejlevnější webový hosting dovoluje spuštění PHP a MySQL.
Linux – obecný pojem odkazující se na UNIXové operační systémy založené na Linuxovém jádře. Jejich vývoj je jedním z nejvýznamnějších příkladů spolupráce free a open source softwaru – všechen zdrojový kód může být použit, volně upravován a dále rozšiřován a to jak komerčně tak nekomerčně kýmkoliv v rámci GNU General Public License5. Samotné jméno Linux pochází z jádra systému napsaného Linusem Torvaldsem v roce 1991. Linux může být instalován na široké spektrum počítačového hardware od malých zařízení typu mobilních telefonů, smartfonů až po sálové počítače a superpočítače. Linux se ale především proslavil svým použitím v serverech. Linux je typicky dodáván ve formátu linuxové distribuce pro stolní počítače nebo serverové použití. Linuxová distribuce obsahuje samotné jádro systému a všechen
5
Nejrozšířenější free software licence
26
podpůrný software potřebný ke spuštění celého systému, jako jsou například nástroje a knihovny, X Window System6, KDE7 a GNOM8 a HTTP server Apache. Apache – serverový software hrající klíčovou roli v počátečním růstu World Wide Webu. První verze webového serveru Apache byla vytvořena Robertem McCoolem. V roce 2009 se stal prvním serverovým softwarem, který překročil hranici 100 milionů webových stránek. Apache byl první alternativou k webovému serveru Netscape Communications Corporation, nyní známého jako Sun Java System Web Server. Od té doby se vyvíjí a soupeří s ostatními Unixovými webovými servery z hlediska funkcionality a výkonu. Většina webových serverů používajících Apache běží na Unixových operačních systémech. Apache je vyvíjen a spravován otevřenou komunitou vývojářů pod záštitou Apache Software Foundation. Aplikace je dostupná pro celou řadu operačních systémů zahrnující Unix, GNU, FreeBSD, Linux, Solaris, Novell NetWare, Mac OS X, Microsoft Windows, OS/2, TPF, a eComStation. Uvolněný pod licencí Apache, Apache je charakterizován jako open source software. Od dubna 1996 je Apache nejpopulárnější užívaný HTTP server software. K únoru 2010 obsluhoval Apache přes 54,46% všech webových stránek a přes 66% z milionu nejnavštěvovanějších. Apache podporuje řadu funkcí implementovaných jako kompilované moduly, které rozšiřují základní funkčnost. Některá běžná rozhraní podporují Perl, Python, Tcl a PHP. Populární kompresní metody v Apachi zahrnují externí rozšiřující modul gzip, implementovaný za účelem snížení velikosti webových stránek poskytovaných prostřednictvím HTTP. Virtuální hosting dovoluje jedné instalaci Apache obsluhovat více různých webových stránek. Je rovněž podporován řadou grafických uživatelských rozhraní.
6
Systém a síťový protokol poskytující grafické uživatelské rozhraní
7
Základní prostředí poskytující základní funkce a aplikace
8
Grafické uživatelské rozhraní běžící nad operačním systémem
27
Apache je primárně používán pro obsluhu jak statického, tak dynamického obsahu webových stránek. Mnoho webových aplikací je navrhováno s ohledem na prostředí a funkce, které Apache poskytuje. Apache je šířen jako součást různých balíčků zahrnujících Oracle Database a IBM WebSphere server. Mac OS X integruje Apache jako zabudovaný webový server a využívá jej jako podporu pro svůj WebObjects server. Apache je rovněž součástí systému Novell NetWare 6.5, kde je jako základní webový server. Apache je také součástí mnoha Linuxových distribucí. Programátoři vyvíjející webové aplikace často využívají lokálně nainstalované verze Apache za účelem náhledu a testování v průběhu vývoje. Microsoft Internet Information Services (IIS) je jeho hlavní konkurent, následovaný systémem Sun Microsystems' Sun Java System Web Server a řadou dalších aplikací, jako je například Zeus Web Server. Přestože hlavní cíl návrhu Apache není být nejrychlejším webovým serverem, je svou výkonností srovnatelný s ostatními vysoce výkonnostními webovými servery. Místo implementace jednoduché architektury poskytuje řadu multiprocessingových modulů (MPM), které umožňují Apachi běžet v procesním, hybridním (proces a vlákno) a eventhybridním módu, aby lépe odpovídal požadavkům každé infrastruktury. Z toho vyplývá, že volba správného MPM a správné nastavení je důležité.
2.1.2 WINS WINS je zkratka pro sadu řešení složenou z komerčního software založenou na technologiích společnosti Microsoft. Zkratka je vytvořena z původních počátečních písmen operačního systému Windows Server, webového serveru Internet Information Services (IIS), programovacího jazyka .NET a databáze SQL Server. Windows Server – webový server společnosti Microsoft. V současné době je na trhu jeho nejnovější verze Windows Server 2008, který navazuje na předchozí serverové operační systémy Windows Server 2003 a Windows 2000. Windows Server 2008 je postaven na stejném kódovém základu jako Windows Vista a proto sdílí mnoho stejných částí architektury a funkcionality. Vzhledem ke společnému kódu přichází jak s většinou technických a bezpečnostních funkcí, tak i se správou a řízením, která jsou nová ve Windows Vista. Jedná se například o přepsaný síťový protokol (obecné IPv6, obecné bezdrátové, rychlostní a bezpečnostní vylepšení), lepší grafická 28
instalace, nasazení a obnovení, vylepšená diagnostika a monitorování, protokolování událostí, nové bezpečnostní funkce jako je BitLocker9 a ASLR10, vylepšený Windows Firewall s bezpečným základním nastavením, .NET Framework 3.0 technologie, rozšíření paměti a souborového systému. Procesory a paměťové moduly jsou modelovány jako Plug and Play zařízení, aby umožňovaly zapojování za běhu. Windows Server 2008 obsahuje variantu instalace Server Core, což je výrazně omezená instalace bez nadstavby Windows Exploreru, veškerá konfigurace a správa tak probíhá přes příkazový řádek. Rovněž neobsahuje .NET Framework, Internet Explorer a řadu dalších funkcí, které nesouvisí s funkcemi hlavního jádra. Active Directory role je rozšířena identitou, certifikátem a službou správy práv. Active Directory dovoluje správcům sítě centrální správu připojených počítačů, nastavování politiky skupinám uživatelů a centrální instalaci nových aplikací na více počítačů. Identifikační a certifikační služby dovolují administrátorům spravovat uživatelské účty a digitální certifikáty, které jim umožňují přístup k určitým službám a systémům. Windows Server 2008 nabízí vysokou dostupnost služeb a aplikací prostřednictvím Failover Clustering. Většina serverových funkcí a rolí tak může být spuštěna s minimálními výpadky. Je to také první operační systém dodávaný s Windows PowerShell, novou rozšiřitelnou nadstavbou příkazového řádku a úkolově založenou skriptovací technologií. PowerShell je založen na objektově orientovaném programování a .NET Framework 2.0 a obsahuje více než 120 systémových administračních nástrojů. Mezi další funkce patří samo léčící NTFS. Zatímco v operačních systémech předcházejících Windows Vista při zjištění vadného disku byl tento disk označen za „špinavý“ a jeho oprava vyžadovala vypnutí, se samo léčícím NTFS vlákno pracující na pozadí provede lokalizovanou opravu poškozených datových struktur se znepřístupněním poškozených souborů a adresářů bez nutnosti uzamknutí celého disku a vypnutí serveru. Operační systém je nyní vybaven S.M.A.R.T. detekční technikou, která pomáhá určit, kdy může dojit k selhání pevného disku. Hyper-V je virtualizační systém tvořící hlavní část virtualizační strategie společnosti Microsoft. Virtualizuje servery na úrovní vrstev jádra operačního systému. Může to být považováno za rozdělení jednoho fyzického serveru na
9
Šifrovací funkce celého disku, jež je součástí podnikových verzí operačních systémů.
10
Počítačová bezpečnostní technika ztěžující útoky hackerů na systém.
29
více menších výpočetních oblastí. Windows System Resource Manager poskytuje řízení zdrojů a může být využit ke kontrole množství zdrojů, které může proces nebo uživatel využít na základě obchodních priorit. Internet Information Services – webový server a sada rozšiřujících funkčních modulů vytvořených společností Microsoft pro použití s Microsoft Windows. Je to druhý nejpopulárnější webový server na světě v počtu provozovaných webových stránek hned za vedoucím Apachem. K březnu 2010 obsluhoval 24,47% všech webových stránek. IIS 7 zahrnuje následující protokoly: FTP, FTPS, SMTP, NNTP a HTTP/HTTPS. IIS7 je postavený na modulární architektuře. Moduly, také nazývané rozšíření, mohou být individuálně přidávány nebo odebírány, takže mohou být nainstalovány jen moduly vyžadované pro konkrétní funkcionalitu. Obsahuje nativní moduly jako součást plné instalace. Tyto moduly jsou individuální funkce, které server využívá ke zpracování požadavků. -
HTTP moduly – slouží k vykonávání úkolů specifických pro HTTP v procesové frontě, jako jsou reakce na informace a dotazy zaslané v hlavičkách, vracení HTTP chyb a přesměrování požadavků.
-
Bezpečnostní moduly – slouží k vykonávání úkolů souvisejících s bezpečností v procesové frontě, jako jsou specifikace schémat ověřování, provádění URL autorizace a filtrování požadavků.
-
Moduly obsahu – slouží k vykonávání úkolů souvisejících s obsahem v procesové frontě, jako je zpracování žádostí pro statické soubory, vracení výchozí stránky když klient v žádosti neuvede zdroj a vypisuje obsah adresáře.
-
Komprimovací moduly – slouží k vykonávání úkolů souvisejících s komprimací v procesové frontě, jako je komprimace odpovědí, použití Gzip komprimace přenosového kódování na odpovědi a provádění před komprimování statického obsahu.
-
Kešovací moduly – slouží k vykonávání úkolů souvisejících s kešováním v procesové frontě, jako je ukládání zpracovávaných informací v paměti na serveru a používání kešovaného obsahu v následujících dotazech na stejné zdroje.
-
Přihlašovací a diagnostické moduly – slouží k vykonávání úkolů souvisejících s přihlašováním a diagnostikou v procesové frontě, jako je předávání informací a 30
zpracovávání statusu do HTTP.sys pro přihlašování, hlášení událostí a sledování požadavků momentálně vykonávaných v pracovních procesech.
2.2 Aplikační vrstva Aplikační vrstva může být postavena na řadě různých architektur a programovacích jazyků. Skloubením jednotlivých architektur a programovacích jazyků pak došlo k vytvoření řady frameworků, které se využívají pro samotný vývoj internetové aplikace. Někdy se o těchto frameworcích hovoří také jako o vývojových rámcích či platformách. Základem pro většinu takovýchto frameworků byla některá z následujících architektur: MVC, SOA a architektura komponent. Hodně frameworků jde cestou architektury Model View Controller (MVC) pro oddělení datového modelu, řídící logiky a uživatelského rozhraní do tří nezávislých komponent. Tím se dosáhne toho, že lze jednotlivé komponenty modifikovat tak, aniž by to mělo velký vliv na ostatní komponenty. Výsledkem tak jsou přehledné aplikace, které lze aplikovat na architekturu klient/server. Většina MVC frameworků volí push-based architekturu. Tyto frameworky používají akce vykonávající požadovaný úkon a potom předají data do zobrazovací vrstvy k zobrazení výsledků. Alternativou je takzvaná pull-based architektura. Tyto frameworky začínají se zobrazovací vrstvou, která si potom může vytahovat výsledky z více zdrojů podle toho, jak potřebuje. Obrázek 5: Zobrazení architektury MVC
Zdroj: http://commons.wikimedia.org/wiki/File:ModelViewControllerDiagram.svg Další v řadě je architektura SOA, neboli Service Oriented Architecture. V této architektuře je aplikace rozdělena na množství jednotlivých objektů, které jsou na sobě nezávislé a komunikují spolu pomocí zpráv a signálů. Každý takový objekt přijatou zprávu vyhodnotí a na jejím základě vykoná určitou akci, hovoříme tak o poskytování služby. Jako vhodným řešením k této architektuře se jeví objektově orientované programování. Využitím této 31
architektury tak dochází ke vzniku přehledných aplikací, jejichž části (objekty) lze znovu použít. Obrázek 6: Zobrazení architektury SOA
Zdroj: http://onjava.com/onjava/2005/01/26/graphics/Simple.jpg Poslední architektura komponent je rozdělena na dvě části. První část definuje jednotlivé komponenty, které jsou spouštěny určitou událostí, která je s patřičnou komponentou spojena. Druhou část tvoří definované funkce a metody aplikační logiky. Aplikace tvořené touto architekturou jsou poměrně snadné, definují se pouze jednotlivé komponenty a jejich chování a poté se naprogramuje samotná aplikační logika. V aplikační vrstvě se kromě samotné architektury volí i použití programovacího jazyka. Pro definici uživatelského rozhraní se využívá tagovacího jazyka, což je HTML. Pro programovací logiku se pak využívá již některý z konkrétních programovacích jazyků. Každý takový jazyk klade určité požadavky na server, je proto nutné vždy volbu jazyka důkladně zvážit. V následující části si představíme nejpoužívanější programovací jazyky a u každého z nich si uvedeme konkrétní příklad frameworku.
2.2.1 PHP PHP je poměrně mladý programovací jazyk vytvořený v roce 1994 programátorem Rasmusem Lerdorfem, který jej nazval Personal Home Page Tools, odtud zkratka PHP. Jedná se o skriptovací jazyk, který byl původně určen pro vývoj dynamických webových stránek. V současné době je však tento programovací jazyk využíván na straně serveru, tzv.
32
server-side. To znamená, že veškeré operace prováděné PHP probíhají na serveru, kde se poté generuje HTML výstup, který vidí uživatel. Je to tedy odlišná technologie od například běžně využívaného JavaScriptu, který běží výhradně na straně klienta. PHP není závislé na platformě ani na konkrétním serveru, může tedy běžet prakticky na většině operačních systémů a počítačových platformách. PHP je součástí nejpoužívanějšího serverového řešení LAMP. PHP je free software uvolněný pod PHP licencí, která si klade požadavek zákazu využívání jména PHP v propagaci produktů vzniklých z tohoto software bez předchozího písemného svolení. Tato podmínka je důvodem k tomu, proč není PHP šířeno pod GNU GPL. Na PHP je postavena rovněž řada frameworků využívaných pro tvorbu internetových aplikací, jako jsou například CakePHP, Symfony nebo Zend Framework. Symfony - zástupce frameworků napsaný v PHP, který je postaven na modelu MVC. Symfony je free software uvolněný pod MIT license11. Zaměřuje se na urychlení tvorby a správy webových aplikací a nahrazení opakujících se kódovacích úkolů. Pro svou instalaci vyžaduje jeden z operačních systémů Unix, Linux, Mac OS nebo Microsoft Windows s webovým serverem a nainstalovaným PHP ve verzi 5. Pokud Symfony běží v prostředí s podporou PHP urychlovače, tak jsou jeho výkonnostní požadavky nízké. Je potřeba zmínit, že pokud je Symfony provozováno na klasickém sdíleném hostingu, kde není technologie PHP urychlovače dostupná, může využívat svůj kešovací mechanismus k urychlení spouštěného kódu. Symfony je zaměřeno na stavbu robustních aplikací v podnikovém prostředí a má za cíl poskytnout vývojářům plnou kontrolu nad nastavením systému počínaje adresářovou strukturou až po cizí knihovny. Pro splnění vývojových požadavků podnikového řešení je Symfony dodáváno s řadou dalších nástrojů, které vývojářům pomáhají s testy, hledáním chyb a dokumentováním projektů. Symfony je využívána v mnoha aplikacích jako je například záložkový server Delicious.com nebo Yahoo! Bookmarks se svými 20 miliony uživatelů.
11
Licence pro free software založená na Massachusetts Institute of Technology.
33
2.2.2 Python Python je vyšší programovací jazyk, jehož filozofií je zdůraznění čitelnosti kódu. Kombinuje vysoký výkon s velmi čistou syntaxí a jeho standardní knihovna je velká a komplexní. Jeho použití odsazení pro blokové oddělovače je mezi populárními programovacími jazyky neobvyklé. Jako ostatní dynamické jazyky je Python často používán jako skriptovací jazyk, je ale rovněž používán v celé řadě neskriptových kontextů. Referenční implementace Pythonu je postavena na otevřeném, komunitním vývojovém modelu stejně jako většina jeho alternativních implementací. Python vznikal v roce 1989 podle návrhu Guida van Rossum, nyní je řízen neziskovou organizací Python Software Foundation. Python je standardní komponentou pro mnoho operačních systémů. Dodává se s většinou Linuxových distribucí, s NetBSD a OpenBSD, a s Mac OS X. Samotný programovací jazyk byl rovněž implementován do řady softwarových produktů, jako jsou třeba 3D modelovací a animační balíky Maya, MotionBuilder a Blender. Zároveň slouží jako základ řadě frameworků, jako je Django, Pylons, web2py a Zope. Django - framework napsaný v jazyce Python uvolněný pod licencí open source, který se drží modelu MVC. Jeho cílem je zjednodušení tvorby komplexních databázových webů. Django zdůrazňuje opakované použití jednotlivých komponent ve formě zásuvných modulů, rychlý vývoj a princip "Neopakuj se". Poskytuje také volitelné CRUD12 rozhraní, které je generováno dynamicky pomocí introspekce a konfigurovatelné pomocí administračních modelů. Framework Django se skládá z objektově-orientovaného mapperu, který zprostředkovává komunikaci mezi datovými modely a relační databází, systémem zpracování požadavků a systémem šablon. Django je využíván v mnoha aplikacích jako je například The Washington Post a RapidSMS framework pro SMS aplikace.
2.2.3 Ruby Ruby je dynamický objektově-orientovaný programovací jazyk, který kombinuje syntaxi inspirovanou programovacím jazykem Perl a Smalltalk. Ruby byl vyvinut v polovině 90. let 20. století japonským vývojářem Yukihiro "Matz" Matsumoto. Podporuje více 12
Create, Read, Update and Delete
34
programátorských vzorů včetně funkčního, objektově-orientovaného, příkazového a reflexivního. Má rovněž systém dynamických typů a automatickou správu paměti, proto je v mnoha ohledech podobný jazykům Python, Perl, Lisp a dalších. Ruby by se měl držet tzv. principu nejmenšího překvapení, což znamená, že by se měl jazyk chovat tak, aby minimalizoval zmatení zkušeného uživatele. Byl původně navržen pro usnadnění programátorské práce a snížení možného zmatení. Ruby podporuje dědění s dynamickým odesíláním, mixiny13 a unikátní metody náležející a definované spíše pro samostatné instance než pro celou třídu. Ačkoli Ruby nepodporuje vícenásobnou dědičnost, tak třídy mohou importovat moduly jako mixiny. Rovněž umožňuje procedurální programování (tzn. definování funkcí a proměnných mimo třídy jako část samotného objektu) s objektovou orientací (vše je objekt) nebo funkčním programováním (má anonymní funkce, ukončení a pokračování). Podporuje dynamické přetypování a parametrický polymorfismus. Ruby je dostupný pro mnoho operačních systémů, jako je Linux, Mac OS X, Microsoft Windows, Windows CE a většina Unixových systémů. Byl rovněž naportován pro Symbian OS 9.x. Na tomto programovacím jazyce je postaveno i několik frameworků, jako jsou například Camping, Merb nebo Ruby on Rails. Ruby on Rails - open source framework vyvinutý na programátorském jazyce Ruby se stal jedním z nejúspěšnějších frameworků pro tvorbu internetových aplikací, který vyvíjí Rails Core Team. Tento framework je postaven na modelu MVC a těží z výhod jazyka Ruby, který je oproti ostatním jazykům revoluční tím, jak je intuitivní a práce s ním, možno říci, až zábavná. Ruby on Rails obsahuje nástroje usnadňující běžné programátorské úkoly, jako je tzv. Scaffolding. Tento nástroj využívá neustálého opakování se určitých postupů, které byly zahrnuty do šablon a je tak možné je kdykoliv jednoduše do vyvíjené aplikace přidat a upravit si je podle konkrétních potřeb. Díky popularitě Ruby on Rails se objevilo mnoho přídavných modulů s množstvím dalších funkcí a šablon, které je možné do frameworku doinstalovat.
13
speciální třída poskytující umožňující dědění určité funkcionality podtřídou
35
Tento framework se řadí mezi jedny z nejlepších pro vývoj jednodušších internetových aplikací a dynamických webů. Nedoporučuje se ale používat pro vývoj náročnějších aplikací. Často je integrovaný s databázovým serverem MySQL a webovým serverem Apache. V praxi je jako největší úspěch považováno dodávání Ruby on Rails společně s operačním systémem Mac OS X v10.5 Leopard. Na tomto frameworku je postavena i řada známých webů a služeb jako je například Twitter, ecommerce řešení Shopify nebo BaseCamp.
2.2.4 Java Java je programovací jazyk vyvinutý Jamesem Goslingem v Sun Microsystems a byl vydán jako základní součást Java platformy. Většina syntaxe Javy pochází z jazyků C a C++, ale má jednodušší objektový model a méně nízko-úrovňových zařízení. Java aplikace jsou typicky kompilovány do byte kódu (souboru tříd), který může běžet pouze na Java Virtual Machine bez ohledu na architekturu počítače. Java je univerzální, objektověorientovaný programovací jazyk speciálně navržen tak, aby měl co nejméně implementačních závislostí, jak je to jen možné. Úmyslem bylo nechat vývojáře aplikací napsat aplikaci jednou a moci ji spouštět kdekoliv. Java je považována za nejvlivnější programovací jazyk 20. století a je široce využíván od softwarových aplikací po webové aplikace. V průběhu času byla většina technologií Javy přelicencována na GNU GPL. Jak už bylo řečeno, hlavní charakteristikou Javy je její přenositelnost, což znamená, že počítačové programy napsané v Javě musí běžet stejně na jakémkoliv podporovaném hardwaru nebo operačním systému. Toho je dosaženo kompilací Java kódu do takzvaného Java byte kódu místo kompilování do přímo platformou-specifického strojového kódu. Java byte kód je podobný strojovému kódu, ale je určen pro interpretaci ve virtuálním stroji napsaném speciálně pro daný hardware. Uživatelé běžně používají Java Runtime Environment instalovaný na jejich počítači pro spouštění samostatných Java aplikací, nebo internetový prohlížeč pro spouštění Java appletů. Výhoda přenositelnosti je ale vykoupena rychlostí běhu aplikací, většina Java aplikací tak běží pomaleji než programy kompilované přímo pro daný systém. Java tak utrpěla na pověsti díky špatnému výkonu. Tento rozdíl byl však díky řadě optimalizačních technik zmenšen. Sun Microsystems oficiálně licencuje Java Standard Edition platformu pro operační systémy Linux, Mac OS X a Solaris. V minulosti ji licencoval i pro Microsoft, ale licence 36
vypršela a nebyla dále obnovena. Prostřednictvím sítě prodejců a licencí třetí strany jsou alternativní Java prostředí k dispozici i pro tyto a další platformy. Na Javě je postavena řada frameworků, z nichž nejznámější jsou Apache Cocoon, Google Web Toolkit, JavaServer Faces a OpenLaszlo. Google Web Toolkit - open source sada nástrojů, která umožňuje webovým vývojářům vytvořit a spravovat složité front-end JavaScriptové aplikace v Javě. GWT zdůrazňuje možnost opakovaného použití, efektivní řešení opakujících se výzev AJAXu, konkrétně asynchronní vzdálené volání procedur, správu historie, záložky, internacionalizaci a přenositelnost mezi internetovými prohlížeči. Pomocí GWT mohou vývojáři rychle vyvíjet a ladit AJAX aplikace v jazyce Java použitím vývojových Java nástrojů dle vlastního výběru. Když je aplikace připravena k nasazení, GWT kompilátor přeloží Java aplikaci do samostatných JavaScriptových souborů, které jsou vysoce optimalizované. GWT se netočí jen kolem programování uživatelského rozhraní, je to totiž obecná sada nástrojů pro vytváření jakékoliv vysoce výkonné klientské JavaScriptové funkcionality. Zároveň je ale zdůrazňováno, že GWT není další AJAX knihovna, ale je to pouze sada nástrojů takovéto knihovny obsahující. GWT aplikace mohou běžet ve dvou módech. 1. Vývojový mód - aplikace běží jako Java byte kód v rámci JVM. Tento mód je typicky používán při vývoji a ladění aplikace. 2. Webový mód - aplikace běží jako čistý JavaScript a HTML kompilovaný z Java zdroje. Tento mód je typický pro nasazení aplikace.
2.3 Databáze Databáze je soubor dat k jednomu či vícero použití. Jeden způsob klasifikace databáze je podle typu obsahu, například bibliografický, full-text, číselný, obrázky. Druhá klasifikační metoda začíná zkoumáním datového modelu nebo databázové architektury. K prvnímu způsobu klasifikace databáze se dá všeobecně říci, že databáze slouží k popisu reálného světa (např. evidence klientů, sklad zboží, evidence knihovny). Jednotlivé prvky nazýváme entity, např. klient, produkt, kniha. Tyto entity jsou popsány charakteristikami, které nazýváme atributy, např. jméno, adresa, výrobce zboží, autor knihy. Mezi jednotlivými entitami vznikají vztahy, které mohou být typu 1:1, např. jeden klient má 37
jedny osobní údaje vedené v bance. Dalším možným typem je vazba 1:N, což je například jeden klient může vlastnit více kreditních karet, ale jedna kreditní karta nemůže být vlastněna více klienty, ale pouze jedním. Třetí a poslední typ vazby je M:N, kde není definováno žádné početní omezení, například jeden klient může mít založeny účty u více bank a zároveň jedna banka může mít více klientů. Databázový model byl zaveden jako prostředek sloužící k popisu databáze. Původně byly vytvořeny dva typy modelů. Prvním je hierarchický, který modeluje hierarchii mezi jednotlivými entitami a je organizován do stromové struktury. Tato struktura umožňuje opakování informací využitím vztahů rodič/potomek, kde každý rodič může mít více potomků, ale každý potomek může mít jen jednoho rodiče, jak je možné vidět na obrázku č. 7. Výhodou je rychlé získání dat, protože mezi tabulkami existuje přímé propojení. Další nespornou výhodou je referenční integrita zajišťující nutnost napojení potomků na existující záznamy rodiče. To znamená, že pokud dojde k odstranění záznamu v tabulce, tak budou smazány i propojené záznamy v tabulkách potomků. Obrázek 7: Příklad hierarchického modelu
Zdroj: http://ovis.ui.ac.id/wiki/File:Hierarchical_Model.jpg V databázi je každá entita reprezentována tabulkou, každý jednotlivý záznam tvoří řádku a atributy jsou sloupce. Entity jsou ve vzájemné vazbě typu 1:N. Nejznámější a nejvyužívanější hierarchické databáze jsou IMS vyvinuté společností IBM a Windows Registry vyvinuté společností Microsoft. 38
Tabulka 1: Příklad entity reprezentované tabulkou ID 1 2 3
Jméno Michal Novák Petr Veselý Jan Dvořák
Adresa Revoluční 5, Praha 2 Luční 15, Hodonín K Nemocnici 1, Hořovice
Typ účtu běžný spořicí běžný
Druhý model je síťový, který vychází z grafů, kde jednotlivé uzly představují entity a orientované hrany představují vztahy mezi nimi, viz. tabulka č. 1. Tento model je výsledkem snahy o vyřešení problémů hierarchického modelu. Uzel zde reprezentuje množinu záznamů a v jednoduché konstrukci vytváří vztah mezi dvěma uzly kde je jeden uzel vlastníkem a druhý prvkem. Toto značně vylepšuje vztah rodič/potomek u hierarchického modelu. Tato množinová struktura podporuje vztahy 1:N. Mezi jednotlivými uzly může být definováno jedno nebo více spojení a libovolný počet může být součástí dalších množin s jinými uzly v databázi. K datům v síťové databázi je možné přistupovat procházením odpovídajících množinových struktur a je možné přistupovat k datům z libovolného uzlu a procházet přidruženými množinami. Výhodou je stejně jako u hierarchického modelu rychlý přístup k datům, který umožňuje vytvářet mnohem komplexnější dotazy. Nevýhodou je nutnost znalosti struktury databáze, aby bylo možné pracovat s množinovými strukturami.
39
Obrázek 8: Příklad síťového modelu
Zdroj: http://en.wikipedia.org/wiki/File:Network_Model.jpg Časem se však ukázalo, že oba zmíněné modely jsou nedostatečné pro realizaci vazby typu M:N a tak došlo ke vzniku třetího, relačního modelu. Ten byl nakonec uznán jako standard a používá se dodnes. Relace je způsob propojení jednotlivých entit tak, aby mezi nimi mohla probíhat komunikace a aby tak došlo k propojení souvisejících dat. Mezi výhody patří relativní jednoduchost a pochopitelnost. Dále je to integrita dat, která je zabudovaná přímo v modelu na úrovni položek, čímž dochází k zajištění přesnosti dat. Zajišťuje, že data nejsou duplicitní a zároveň detekuje chybějící hodnoty primárních klíčů. Díky tomu jsou data konzistentní a přesná. Další výhodou je snadné získávání dat zadáním příkazu uživatelem. Data jsou následně získávána z jedné či libovolného počtu entit, jež jsou ve vzájemném vztahu. Tím se docílí možnosti zobrazení informací mnoha způsoby. Mezi nejznámější zástupce relačních databází patří MySQL, Oracle, PostgreSQL, MS SQL.
40
Obrázek 9: Příklad databáze odpovídající relačnímu modelu
Zdroj: http://en.wikipedia.org/wiki/File:Relational_Model_2.jpg Poté následoval objektově-orientovaný databázový systém (OODBMS). V tomto modelu jsou informace zastoupeny ve formě objektů stejně, jako je tomu v objektověorientovaném programování. Objektové databáze tvoří na trhu databází s dominujícím relačním databázovým systémem jen menší oblast. Přestože tyto databáze existují již od počátku 80. let, jejich dopad na hlavní komerční zpracování dat je minimální, i když existuje jejich využití ve specializovaných oblastech. Dnešní trend v programovacích jazycích je využití objektů, čímž se OODBMS stávají ideálním řešením pro objektově-orientované programátory, kteří tak mohou vytvořit produkt, uložit jej jako objekty a poté replikovat nebo upravit existující objekty a vytvořit tak nové objekty v rámci OODBMS. Informace v dnešní době netvoří pouhá data, ale je to i video, audio, grafy a fotky, což jsou složité datové typy. Relační databáze nejsou obecně schopné podporovat tyto komplexní formáty. Při použití objektově-orientovaného programování a OODBMS může probíhat správa takových to informací bez problémů,
41
protože obojí využívá stejný model prezentace dat. V relačním modelu by proto muselo dojít na rozdělení úkolů na databázový model a aplikaci. Obrázek 10: Příklad objektově-orientované databáze
Zdroj: http://en.wikipedia.org/wiki/File:Object-Oriented_Model.jpg Vývoj databázových systémů pokračoval dál a jako další stupeň se vytvořil objektověrelační databázový systém (ORDBMS), což je databázový systém podobný relační databázi, ale s objektově-orientovaným databázovým modelem: objekty, třídy a dědičnost jsou přímo podporovány v databázových schématech a v dotazovacím jazyce. Kromě toho podporuje rozšíření datového modelu o vlastní datové typy a metody. Příkladem takového systému je například PostgreSQL. Lze říci, že objektově-relační databáze je střední cesta mezi relačními databázemi a objektově-orientovanými databázemi. Přístup je zde stejný jako v relační databázi, data jsou uložena v databázi a je s nimi manipulováno pomocí dotazů v dotazovacím jazyce. Na druhou stranu úplně opačným přístupem je objektový přístup, v kterém je databáze trvalé objektové úložiště pro software napsaný v objektově-orientovaném programovacím jazyce s programovým API pro ukládání a načítání objektů a s malou nebo žádnou specifickou podporou pro dotazování.
42
2.3.1 MySQL MySQL je relační databázový systém (RDBMS), který běží jako multi-uživatelský přístup k řadě databází. Vývojový tým MySQL poskytl jeho zdrojový kód na základě podmínek GNU General Public License stejně jako podle řady majetkových dohod. MySQL je vlastněno a sponzorováno švédskou společností MySQL AB, nyní vlastněnou společností Oracle Corporation. Členové MySQL komunity v průběhu času vytvořili několik odnoží, jako je například Drizzle a MariaDB. Free softwarové projekty, které vyžadují plně vybavený databázový systém často používají právě MySQL. Mezi tyto projekty patří například WordPress, phpBB, Drupal a další software postavený na řešení LAMP. MySQL je rovněž používáno v mnoha známých a rozsáhlých produktech jako je Wikipedia, Google, Facebook, Flickr a YouTube. MySQL pracuje na mnoha různých systémových platformách včetně FreeBSD, HP-UX, Linux, Mac OS X, Novell NetWare, OpenBSD, OS/2 Warp, Solaris, Symbian, SunOS a Microsoft Windows. Všechny hlavní programovací jazyky se specifickým API14 obsahují knihovny pro přístup do MySQL databází. MySQL je v první řadě RDBMS a proto se dodává bez grafického uživatelského rozhraní pro správu databází a dat v nich obsažených. Uživatelé tak můžou využívat nástrojů příkazové řádky nebo si stáhnout grafickou nadstavbu třetích stran, které vyvinuly software a webové aplikace ke správě MySQL databází, tvorbě databázové struktury a samotné práce s datovými záznamy. Oficiální MySQL Workbench je bezplatné integrované prostředí vyvinuté MySQL AB, které umožňuje uživatelům grafickou správu databází a vizuální modelování databázové struktury. MySQL Workbench je dostupný ve dvou edicích. Jedna je běžná bezplatná open source edice, která může být stažena z webu MySQL. A druhá je placená standardní edice rozšiřující a vylepšující funkčnost základní edice.
14
Rozhraní pro programování aplikací.
43
Obrázek 11: MySQL Workbench ve Windows zobrazující úvodní stránku
Zdroj: http://en.wikipedia.org/wiki/File:Mysqlwb-homepage.png K dispozici je i řada placených i bezplatných grafických aplikačních rozhraní třetích stran, která jsou integrována s MySQL a umožňují uživatelům vizuální práci se strukturou databáze a se samotnými daty. Mezi nejznámější patří phpMyAdmin, který je poskytován bezplatně a hodně instalován web hostingy, protože je vyvinut v PHP a vyžaduje pouze LAMP řešení. Dalším je například Navicat, což je zástupce komerčního řešení vyvinutého pro Windows, Macintosh i Linux. Dále to jsou dbForge, Oracle SQL Developer, Toad, atd. MySQL může být nainstalováno ručně ze zdrojových kódů, což je značně náročné a proto je většinou instalováno z binárního balíčku, pokud není vyžadována zvláštní úprava. Na většině Linuxových distribucích může systém pro správu balíčků stáhnout a nainstalovat MySQL bez větší námahy, často je ale vyžadováno bezpečnostní a optimalizační nastavení. MySQL původně začínalo jako low-end alternativa k výkonnějším komerčním databázím, postupně se ale vyvinulo až k podpoře vyšších potřeb a nároků. Stále je ale nejvyužívanější pro malá a střední jedno-serverová řešení buď jako součást webové aplikace postavené na řešení LAMP nebo jako samostatný databázový server. Většinu z půvabu MySQL má na 44
svědomí jeho relativní jednoduchost a snadné použití, což je umožněno díky spolupráci s open-source nástroji jako je phpMyAdmin. Ve středně velkém nasazení může být MySQL škálováno nasazením na výkonnější hardware, jako jsou více-procesorové servery s gigabyty paměti. Existují ale hranice, jak daleko lze škálovat výkon na jednom serveru, takže ve větším měřítku jsou pro lepší výkon a spolehlivost vyžadována více-serverová řešení. Samotné MySQL AB poskytuje podporu prostřednictvím podnikového řešení MySQL, která zahrnuje 24/7 službu s reakční dobou 30 minut. Tým podpory má podle potřeby přímý přístup k vývojářům, aby s nimi mohl řešit vzniklé problémy. Navíc provozují fórum, e-mailové konference a často poskytují podporu i na mnoha IRC kanálech. Kromě oficiální podpory jsou zde i další společnosti, které nabízejí podporu a služby spojené s používáním MySQL. Mezi jejich služby patří správa databází, optimalizace, tréninkové kurzy a výroba oprav. Platící zákazníci podnikového řešení MySQL mají přístup k binárním souborům a softwaru certifikovanému pro jejich konkrétné operační systém včetně přístupu k měsíčním aktualizacím. Potencionální uživatelé si mohou nainstalovat MySQL Server jako free software pod GNU General Public License.
2.3.2 Oracle Databáze Oracle je relační databázový systém RDBMS vyvíjený a prodávaný společností Oracle Corporation. Tento databázový systém je dostupný v 63 jazykových verzích. Oracle Corporation zároveň poskytuje databázovým vývojářům nástroje a mechanismy pro tvorbu lokalizovaných databázových aplikací. Tento databázový produkt je dostupný pro více platforem, některé z podporovaných operačních systémů a hardwarových platforem jsou Apple Mac OS X Server: PoverPC; HP Tru64 UNIX: Alpha; IBM AIX5L: IBM POWER; Linux: x86, PowerPC, Itanium; Microsoft Windows: X86, Itanium; Sun Solarids: SPARC, x86. Na trhu relačních databází databáze Oracle soupeří s dalšími komerčními produkty, jako jsou například IBM DB2 UDB a Microsoft SQL Server. S IBM je to převážně v oblasti středně velkých databází na UNIX nebo Linux platformách, zatímco Microsoft dominuje na platformách Microsoft Windows. Avšak díky množství společných zákazníků mají Oracle i IBM tendenci vzájemně podporovat své produkty v mnoha kategoriích aplikací, jak jsou například WebSphere, PeopleSoft a Siebel Systems CRM. Mezi další konkurenty 45
patří Sybase nebo Informix. V poslední době databáze Oracle soupeří i s open source relačními databázemi a to zejména s PostgreSQL, Firebird či MySQL. Oracle převzal společnost Innobase, tvůrce InnoDB - úložného řešení pro MySQL, kvůli lepší konkurenceschopnosti na open source trhu a v roce 2010 převzal samotný Sun Microsystems, vlastníka MySQL. Mezi začínajícími uživateli má databáze Oracle pověst složitého systému pro instalaci na Linuxových systémech. Proto, aby se předešlo složitým instalačním procesům určeným odborníkům, se Oracle Corporation rozhodla připravit základní verze svého databázového systému pro populární Linuxové distribuce. Uživatelé, mající smlouvu o podpoře, mohou využívat webové stránky MetaLink, vytvořené společností Oracle Corporation. MetaLink poskytuje uživatelům Oracle produktů archív hlášených problémů, diagnostických skriptů a řešení. Rovněž poskytuje podpůrné nástroje, opravy a aktualizace. Uživatelé databází Oracle se odkazují na paměťovou strukturu SGA15 na straně serveru, která běžně obsahuje informace uložené v mezi-paměti, jako jsou například SQL příkazy a uživatelské informace. Databáze obsahuje i rekonstrukční záznamy, v kterých se uchovává historie všech operací. Procesy mohou přistupovat k těmto záznamům, což poskytuje základ pro obnovu dat i pro některé replikace dat. Pokud je do databáze implementován Oracle RAC16, pak je možné k hlavnímu úložišti dat připojit více instancí, které jsou obvykle na různých serverech. Toto řešení nabízí řadu výhod jako je lepší výkon, škálovatelnost a redundanci. Na druhou stranu je ale samotná podpora takového systému složitější a mnoho webů jej proto nevyužívá. U novějších verzí byl představen grid computing, což je sdílení zdrojů kdy jedna instance může využít procesorové zdroje z jiného uzlu nebo počítače v síti.
2.3.3 PostgreSQL PostgreSQL je objektově-relační databázový systém (ORDBMS) vyvíjený jako open source projekt. Jedná se o poměrně rychlou databázi s širokou podporou programovacích jazyků jako je PHP, Perl a ODBC a JDBC ovladačů, které usnadňují jeho použití v dalších jazycích jako je ASP, ASP.NET, ColdFusion a Java. PostgreSQL je často srovnáván s
15
Část paměti sdílená všemi procesy náležícími instanci databáze Oracle
16
Real Application Clusters – software pro clusterování a vysokou dostupnost v prostředí databáze Oracle
46
jednou z nejrychlejších databází - MySQL, kde jsou v rychlosti dotazování zhruba na stejné úrovni, ačkoliv některé studie ukázaly, že při velkém množství uživatelů je dokonce lepší než MySQL. Oproti MySQL ale nabízí rozšířenou funkcionalitu srovnatelnou s SQL Serverem. PostgreSQL není jen čistě relační databáze, ale je i objektově-relační. To znamená, že má některé objektově-orientované funkce jako je koncept dědičnosti a schopnost definování složitých datových typů se speciálními funkcemi. Obecně je ale hlavně relační databáze, vzhledem k tomu, že většina uživatelů objektově-orientovanou funkcionalitu nevyužívá. Přitom ale obsahuje takové funkce a vlastnosti, které nejsou dostupné ani u známých komerčních produktů. Jak už bylo řečeno, PostgreSQL podporuje řadu programovacích jazyků. Přímo obsahuje 4 Procedurální Jazyky (PL), které jsou obsažené ve zdroji PostgreSQL. Jsou to PL/pgsql, PL/Python, PL/Tcl a PL/Perl. Na zařazení dalších jazyků se stále pracuje. Mezi takové patří PL/Java. Procedurální jazyky umožňují přirozené psaní funkcí a procedur a jejich jednoduché propojení s knihovnou obsahující již kompilované funkce. Architektura databáze PostgreSQL dovoluje definování nových PL jazyků pomocí PL ovladačů. Toto dělá PostgreSQL velmi rozšiřitelným, například je možné vytvořit nový jazyk pravidel a poté jej nabídnout jako PL rozšíření. Toto je u databází velice neobvyklé, protože přidání nového jazyka běžně vyžaduje změnu architektury celého systému. Další významnou funkcí je dědičnosti tabulkových struktur. Tato funkcionalita představuje kompromis pro uživatele, kteří se poohlíží po objektově-orientované databázi, ale zároveň požadují jednoduchost a rychlost poskytovanou relačními databázemi. PostgreSQL navíc umožňuje dědit z více než jen jedné tabulky nebo dědit z jiné, již děděné tabulky. Tak lze dosáhnout jediného dědění stejně jako vícenásobné dědičnosti. PostgreSQL využívá ve svých projektech řada společností. Je to například Yahoo!, které vyjádřilo přání postavit největší datové úložiště na upravené verzi PostgreSQL. Dále je to MySpace, populární sociální síť, která využívá nCluster Database jako úložiště dat postavené na PostgreSQL. Z dalších jsou to BASF, Sony Online, Skype a další.
47
2.3.4 MS SQL Server Microsoft SQL Server je relační databázový systém RDBMS vyvíjený společností Microsoft, který je vhodný zejména pro podnikové řešení. SQL server běží na jazycích TSQL a ANSI SQL, sadě programovatelných rozšíření od Sybase a Microsoftu, které přidávají množství nových funkcí do standardního SQL včetně transakční kontroly, správy výjimek a chyb, zpracovávání řad a deklarování proměnných. Protokolová vrstva implementuje externí rozhraní do SQL Serveru. Všechny operace, které mohou být na SQL Serveru vyvolány, jsou sdělovány pomocí Microsoftem definovaného formátu nazývaného Tabular Data Stream. Jedná se o protokol aplikační vrstvy sloužící k přenosu dat mezi databázovým serverem a klientem. TDS balíčky mohou být vloženy i do jiných přenosových protokolů včetně TCP/IP, Named pipes17 a Shared memory18. V důsledku toho je přístup k SQL Serveru k dispozici pomocí těchto protokolů. Navíc je SQL Server API přístupné i přes webové služby. Hlavní jednotkou ukládání dat je databáze, která představuje sbírku tabulek s typizovanými sloupci. SQL Server podporuje různé datové typy včetně základních typů jako je Integer, Float, Decimal, Char a další. Rovněž povoluje uživatelsky definované typy, které mohou být nadefinovány a použity. To také zpřístupňuje statistiky serveru jako virtuální tabulky a pohledy. Kromě tabulek může databáze obsahovat i jiné objekty včetně pohledů, uložených procedur, indexů a omezení, spolu s protokolem operací. Hlavním způsobem získávání dat z databáze SQL Serveru je dotazování. Dotaz je vyjádřen pomocí T-SQL. Dotaz deklarativně specifikuje, co má být načteno. To je zpracováno pomocí dotazovacího procesu, který zajistí sled kroků potřebných k získání požadovaných dat. Sekvence akcí potřebných k provedení dotazu se nazývá plán dotazu. Pro zpracování stejného dotazu může existovat několik způsobů. SQL Server obsahuje dotazový optimalizátor, který se snaží optimalizovat náklady, pokud jde o prostředky potřebné na provedení dotazu. Při přijetí dotazu se optimalizátor dívá na schéma databáze, statistiku databáze a zatížení systému v daném okamžiku. Na základě získaných údajů rozhodne o
17
Jedna z metod mezi-procesní komunikace, rozšíření tradičního pipe konceptu na Unixových systémech.
18
Paměť, která může být současně přístupná více programům se záměrem poskytnutí komunikace mezi nimi
nebo předejití duplikovaný datům.
48
sekvenci potřebné pro přístup do tabulek uvedených v dotazu, o sekvenci pro vykonání operací a jakou přístupovou metodu použije pro přístup do tabulek. Dále se rozhodne, zda všechny části dotazovací sekvence spustí současně, což je více procesorově náročné, ale na druhou stranu rychlejší, protože dojde k rozdělení kroků různým procesorům. Po vygenerování kompletního plánu dotazu, je tento plán uložen ve vyrovnávací paměti pro případ, že by byl stejný dotaz volán znovu. Nevyužívané plány se po nějaké době z vyrovnávací paměti vymažou.
3. Wireframe design Wireframe, neboli drátěný model, webové stránky je základní vizuální průvodce návrhem uživatelského rozhraní pro nastínění struktury webové stránky a vztahů mezi jejími stránkami. Drátěný model je jednoduchá ilustrace vzhledu a rozmístění jednotlivých elementů na stránce. Běžně jsou drátěné modely připravovány před začátkem grafických prací. Umožňuje práci s variantami uspořádání a zachování soudržnosti celého webu. Je důležitou součástí počáteční fáze vývoje, protože vytváří očekávání uživatelů a napomáhá seznámení se s webem. Vytvoření sady drátěných modelů pro projekt vytváří jakousi komunikaci s klienty a zúčastněnými stranami, jako jsou tvůrci obsahu, inženýři a vývojáři. V průběhu projektu tvoří wireframing stabilní základ, na kterém se zvažují změny, různé uživatelské cesty a nové požadavky. Architekt a designér využívají drátěných modelů jako prostředek pro realizaci myšlenek a jako konkrétní pracovní dokumenty, na kterých se začne budovat jazyk, obsah a struktura interakcí, které budou mít uživatelé s konkrétní webovou stránkou nebo projektem. Vytvoření drátěného modelu také pomáhá s umístěním hlavní a vedlejší navigace na viditelné a intuitivní pozici, stejně jako poskytuje prostor pro praktický obsah, jako jsou užitečné informace a vyhledávací funkce. Obecně platí, že po vytvoření drátěného modelu je aplikován branding zajišťující komunikaci identity a personality webové stránky. Drátěné modely mohou vypadat jako jednoduché konstrukční kresby stránky, ale i jako věrná simulace navigace s pohyblivými prvky, funkčními odkazy a složitými interakcemi. Pro jednoduché kresby je nejčastější technikou papírové prototypování, ale stále častější je využívání softwaru pro složitější projekty. Mezi nejpoužívanější programy sloužící pro 49
tvorbu běžných drátěných modelů patří Visio, Balsamiq, InDesign, Illustrator, Photoshop a OmniGraffle. Profesionální, podnikové, softwary pro tvorbu drátěných modelů jsou například Axure, ProtoShare, Justinmind a Irise.
3.1 Papírové prototypování Ve vztahu člověk - počítač je papírové prototypování široce používanou metodou v procesu vývoje. Je to proces, který pomáhá vývojářům vytvořit software nebo aplikaci vyhovující očekáváním a potřebám uživatelů, v tomto případě hlavně pro design a testování uživatelského rozhraní. Zahrnuje tvorbu hrubých ručních kreseb rozhraní k použití jako prototypy nebo modely. I když tato metoda vypadá jednoduše, může tato metoda uživatelských testů poskytnout užitečnou zpětnou vazbu. Prototypování se začalo používat v polovině 80. let 20. století a rychle se stalo velmi populární, když jej začaly pro své projekty využívat společnosti IBM, Honeywell nebo Microsoft. Tato metoda šetří jak čas, tak i peníze, neboť umožňuje vývojářům testovat produktové rozhraní ještě před tím, než začnou psát kód nebo začnou se samotným vývojem. To také umožňuje snadné a levné změny existujících návrhů, což je velice užitečné v prvních fázích vývoje. Rovněž umožňuje zapojení celého kreativního týmu do procesu, což snižuje možnost, že někdo s důležitými informacemi nebude do vývoje zapojen. Další výhodou je to, že se uživatelé cítí pohodlněji při kritice takového modelu, protože nemá profesionální vzhled. Jedním z hlavních využití papírového prototypování je brainstorming vývojového týmu za účelem sběru a vizualizace nápadů jak by mohl interface vypadat. Interface je vytvářen krok po kroku tak, aby splňoval očekávání jednotlivých členů týmu. Pro vyzkoušení použitelnosti softwarového designu se může využít use case a díky tomu mohou být odhalena možná úskalí. Prototyp může být použit jako vizuální specifikace softwaru nebo aplikace. Papírové prototypování se často používá jako první krok v takzvaném rychlém prototypování, které představuje skupinu okolo čtyř designérů, kde každý z nich vytvoří vlastní papírový prototyp a otestuje jej na jednom uživateli. Poté si designéři sdělí své poznatky a nápady a na základě toho opět každý z nich vytvoří druhý prototyp, tentokrát už ale za použití některého jednoduchého počítačového nástroje, jako je třeba Microsoft 50
PowerPoint. Tentokrát už je vzhled blízko finálnímu produktu. Znovu každý prototyp projde testováním jednoho uživatele a designéři si sdělí poznatky. V tento moment již může být vytvořen aplikační nebo softwarový prototyp. Obvykle je po těchto krocích aktuální model na první pohled uživatelsky příjemný, což šetří cenný programátorský čas. Obrázek 12: Ukázka papírového prototypování
Zdroj: http://www.snyderconsulting.net/article_paperprototyping.htm
3.2 Microsoft Office Visio Microsoft Visio je diagramový program pro Microsoft Windows, který pro vytváření diagramů používá vektorovou grafiku. Tento nástroj je dostupný ve dvou verzích: Standard a Professional. Obě verze mají stejný interface, ale profesionální verze má navíc další šablony pro pokročilejší diagramy a schémata stejně jako unikátní funkcionalitu, která uživatelům usnadňuje propojení diagramů s datovými zdroji a zobrazení grafické informace. Microsoft získal společnost Visio Corporation v roce 2000. Nejnovější verze je Visio 2007. Společně s verzí 2002 vydal Microsoft sadu nástrojů Enterprise Network Tools. Tento doplňující produkt umožnil automatické vytváření diagramů sítí a adresářových služeb. Dále zveřejnil Visio Network Center, webové stránky, kde mohou uživatelé najít obsah nejnovější síťové dokumentace a přesné repliky 500 síťových tvarů předních výrobců. Tento web byl nakonec zrušen, ale možnost vyhledávání tvarů je nyní implementována přímo v samotném programu. 51
Obrázek 13: Visio 2007 - ukázka drátěného modelu
Zdroj: http://blogs.sharepointace.com/post/My-favorite-wire-framepage-mockup-tool-forSharePoint-Projects!.aspx
3.3 Axure RP Pro Axure RP Pro je wireframingový, rychle prototypovací a specifikační softwarový nástroj zaměřený na webové a desktopové aplikace. Nabízí možnosti typicky obsažené v diagramových nástrojích jako je drag and drop umisťování, změna velikostí a formátování grafických komponent (widgetů). Kromě toho má funkce pro anotaci grafických komponent a definování interakcí jako je propojování, podmíněné propojování, zobrazení/skrytí prvku atd. Obsahuje podporu pro středně pokročilé simulace Rich Internet Applications19. Axure RP může z diagramů generovat HTML prototypy a Microsoft Word specifikace. Standardně obsahuje řadu grafických komponent, které mohou být při tvorbě drátěných modelů využívány. Další grafické komponenty mohou být simulovány kombinací existujících komponent a přiřazením specifických akcí na události jako jsou OnClick, OnMouseOver a OnMouseOut. 19
Webové aplikace mající mnoho charakteristických prvků desktopových aplikací.
52
Obrázek 14: Axure RP Pro - ukázka drátěného modelu
Zdroj: http://www.axure.com/tourWireframe.aspx
4. Visual design Neméně podstatnou částí návrhu webových aplikací je grafický design. Je to totiž uživatelské rozhraní aplikace a její grafické ztvárnění, s kterým přichází uživatelé do styku. Špatný design je totiž jedním z hlavních příčin neúspěchu webových stránek a aplikací. Při návrhu grafického designu musí web designér vycházet z připravených drátěných modelů, které určují rozmístění jednotlivých prvků na stránce a návaznost mezi jednotlivými stránkami internetové aplikace. Je nezbytně nutné, aby měl designér k dispozici popis aplikace s její charakteristikou. Při volbě designu hraje roli mnoho faktorů, které je potřeba správně zodpovědět a určit. Jedním z těchto faktorů je účel dané internetové aplikace. Pokud by se jednalo například o herní či zábavní portál, design by měl být více kreativní s vysokou barevností, který na první pohled zaujme. Naopak například u zpravodajského portálu je kladen důraz na přehlednost a dobrou čitelnost textů, je tedy potřeba volit decentní, barevně vyváženou grafiku, která neodpoutá uživatele od obsahu. Dalším faktorem je cílová skupina uživatelů dané aplikace. Už jen zaměření na konkrétní pohlaví bude mít vliv na použitou barevnost. 53
Stejně tak bude-li určena cílová skupina věkem či profesí. Internetová aplikace určená pro mladé uživatele muže být opět zaměřena kreativním směrem a snažit se upoutat svou atraktivitou. Naopak aplikace internetového bankovnictví musí budit seriózní dojem, být maximálně přehledná, usnadňovat uživateli navigaci a práci s aplikací. Kromě těchto základních faktorů musí designér řešit i technické otázky. Jednou takovou otázkou je například přizpůsobení designu určitému rozlišení obrazovky. V současné době je škála velikostí zobrazovacích zařízení různá a tak část webu, kterou je uživatel schopen vidět, může být u každého jiná. Designér by se proto měl informovat jaký je současný trend, která rozlišení monitorů patří mezi běžně používaná a podle toho by měl přizpůsobit design, aby uživatelům s nejrozšířenějším rozlišením nabídl na viditelné části webu podstatné informace. Zároveň se může rozhodnout pro dynamické přizpůsobování šířky internetové aplikace. Pokud má uživatel vyšší rozlišení obrazovky, šířka webu se tak může automaticky přizpůsobit. Pro takový případ je třeba připravit grafiku takovým způsobem, aby při rozšíření nedošlo k narušení designu. Další důležitou věcí jsou použité fonty. Při návrhu designu je potřeba pamatovat na to, že v internetových aplikacích mohou být použity pouze standardní fonty, které jsou běžnou součástí operačních systémů. Nejčastěji se využívají fonty Arial a Verdana pro svou dobrou čitelnost na obrazovce. Při použití nestandardního fontu se designér vystavuje riziku, že při nenalezení správného fontu na počítači uživatele bude tento nahrazen standardním fontem a opět tak může dojít k narušení designu. Jedinou možností jak využít nestandardních fontů je jejich zakomponování do obrázků. Tím ale zase snižujeme hodnotu stránky pro vyhledávácí systémy, pro které je text v obrázku neviditelný. Toto ale již spadá spíše do SEO optimalizace pro vyhledávací služby, nicméně je dobré, aby byl s tímto grafik seznámen. Rovněž pro zachování konzistentnosti internetové aplikace by se nemělo používat více typů fontů. Další volbou je použití statické či dynamické grafiky. Statická grafika vychází z použití tagovacího jazyka HTML a obrázků. Pro obrázky jsou využívány 3 grafické formáty - gif, jpg a png. Gif je nejstarší ze jmenovaných formátů a také nejvíce omezující. Tento formát dovoluje použití pouhých 256 barev a průhlednost. Proto je tento formát hůře použitelný na grafiku s plynulými barevnými přechody, naopak jeho výhodou je malá velikost. Formát jpg již umožňuje použití 16 milionů barev, nenabízí ale průhlednost. Výhodou tohoto 54
formátu je možnost jeho komprese, lze tak dosáhnout malé velikosti souborů při zachování věrné barevnosti a kvality obrázku. Poslední formát png je nástupce formátu gif, u kterého je možné využít kompletní palety 16 milionů barev včetně možnosti průhlednosti. Rovněž tento formát je nenáročný, co se velikosti týče. Naproti tomu dynamická grafika vychází z možností nových technologií, jakými jsou například Flash, Shockwave nebo Silverlight. Jedná se o grafický formát, který může obsahovat animace i zvuky. Tento formát je založený na využívání vektorové grafiky, je tedy menší co do objemu dat, zato klade vyšší nároky na výpočetní výkon počítače, který případné animace či zvuky zpracovává v reálném čase. Tento grafický formát je často využíván na zpracování navigace či reklamních bannerů. Je ale potřeba pamatovat na to, že takovéto technologické prvky vyžadují přítomnost zásuvných modulů v prohlížeči, bez kterých nelze požadovanou grafiku zobrazit. Toto může být často překážka k používání internetové aplikace, například při využívání výpočetní techniky v zaměstnání, kde bývají instalovány pouze základní verze prohlížečů bez dodatečných modulů. Každá z obou představených technologií grafiky má svá pro a proti a každá technologie najde své uplatnění. Statická grafika bude vhodnější variantou pro využití například u zpravodajského portálu, kde je podstatný obsah zobrazovaných zpráv. Dynamická grafika by na takovéto internetové aplikaci působila spíše rušivým dojmem, odpoutávala by pozornost uživatele od obsahu. Dynamická grafika naopak najde uplatnění spíše u herního portálu či nějaké konkrétní úzce zaměřené prezentace, kde je důležité upoutat uživatele. Grafik by se měl snažit, aby byla výsledná grafika datově co nejmenší, aby velký objem dat nezpomaloval načítání internetových stránek. V dnešní době vysokorychlostního internetu toto sice není až tak důležité, pokud se ale uživatel připojuje pomocí mobilního internetu, pak toto může být zásadní problém znemožňující užívání dané internetové aplikace. Jak je vidět, vizuální návrh samotné aplikace není jen o vytvoření líbivé grafiky, ale práce a kombinování mnoha faktorů a technik pro vytvoření optimálního uživatelského rozhraní, které napomůže efektnímu využívání internetové aplikace, protože jak již bylo zmíněno na začátku této kapitoly, design a uživatelské rozhraní je to, s čím uživatel přichází do styku jako první a v případě špatného designu může být celá internetová aplikace odsouzena k neúspěchu. 55
Závěr Dnešní doba vysokorychlostního internetu, kde se internet stává běžným vybavením domácností, je ideálním prostředím pro tvorbu internetových aplikací poskytující nepřeberné množství služeb. Ačkoliv si to mnozí možná ani neuvědomují, internetové aplikace obklopují uživatele internetu na každém kroku, ať už jsou to zpravodajské servery, e-shopy, galerie fotografií, sociální sítě typu Facebook či aplikace internetového bankovnictví. Ve své práci jsem se snažil nastínit problematiku návrhu takovýchto internetových aplikací a poukázat na jednotlivé části, z kterých jsou tyto aplikace tvořeny. Základem pro úspěšný návrh a vývoj internetové aplikace je provedení důkladné analýzy, při které je nezbytně nutná těsná spolupráce se zadavatelem projektu. Je totiž potřeba získání detailní specifikace a požadavků na připravovanou aplikaci, aby se již od samého začátku navrhla potřebná funkčnost systému. Pozdější úpravy a změny požadavků pak můžou vést ke značnému zkomplikování vývoje, což se samozřejmě promítá do zvýšených nákladů na vývoj a posunování termínu dokončení. Při analýze lze využívat řadu procesů, které pomáhají oběma stranám s definicí požadavků. Mezi tyto nástroje patří use case a user story, které definují procesy obecně a v průběhu času se upřesňují. Je tedy potřeba této úvodní fázi návrhu věnovat dostatečnou pozornost. V momentě, kdy je hotová kompletní analýza a sepsány veškeré požadavky na internetovou aplikaci, přichází na řadu řešení technické části projektu. Zde se musí vývojáři rozhodnout, jakou zvolí platformu, na které vybudují požadovanou aplikaci. Při tomto rozhodování se musí vycházet z výsledků analýzy, kdy již lze odhadnout rozsah a náročnost aplikace. Některá technologická řešení jsou totiž vhodná pro menší projekty a vynikají svou extrémní rychlostí a obsluhou požadavků přicházejících od uživatelů, pokud by ale byla nasazena pro použití na náročné aplikaci, mohlo by tak snadno docházet k přetížení celého systému a tak snížení uživatelské hodnoty celého systému. Analogicky použití systémů dimenzovaných na náročné aplikace zabezpečí chod vysoce navštěvované a využívané aplikace, zatímco při použití u jednoduché aplikace nebude systém dosahovat potřebného výkonu díky své robustnosti.
56
Je zde potřeba dobře volit vhodnou kombinaci všech částí řešení. I zde totiž platí, že celý systém je tak silný, jak jeho nejslabší článek. Nemalou otázku při návrhu technologického řešení hrají i finanční prostředky. U menších projektů bude hrát prim serverové řešení LAMP, které je postaveno z open source a free softwaru, jsou tak značně sníženy náklady na provoz celého systému. Na druhé straně stojí řešení WIMP postavené na technologiích převážně společnosti Microsoft, které jsou licencované. Je k nim ale zase poskytována podpora, což může být vhodné pro různé komerční aplikace, kde je potřeba jistoty funkčnosti a v případě problémů profesionální pomoci. Po vyřešení technické stránky projektu přichází na řadu návrh uživatelského rozhraní. První fáze představuje návrh drátěného modelu aplikace, tzv. wireframe. Cílem této fáze je připravit rozmístění jednotlivých prvků a částí aplikace na stránce a navrhnout strukturu tohoto uživatelského rozhraní s. návazností na podstránky. Zde je již opět potřeba jisté komunikace se zadavatelem. Na řadu přichází i první testy použitelnosti Jako poslední pak přichází na řadu grafický návrh aplikace. Designér vychází z připravených drátěných modelů, na které navrhuje grafiku. Při tomto návrhu vychází z informací poskytnutých k tomuto projektu a snaží se navrhnout optimální design, který bude na uživatele příjemně působit, bude je podněcovat k využívání dané aplikace a podporovat hlavní účel této aplikace. Uživatelskému prostředí a designu je potřeba věnovat zvláštní pozornost, protože je to z celé aplikace to jediné, s čím přichází uživatel do kontaktu a může tak zásadně ovlivnit úspěšnost celého projektu. Pro každý krok jsem předložil základní informace k dané oblasti. Mou snahou bylo zmínit vždy nejdůležitější zástupce, kteří patří v současnosti mezi nejvyužívanější technologie. Mnoho zástupců tak zůstalo nezmíněno, protože není v možnostech této práce se zabývat všemi alternativami technologií, které lze při návrhu internetových aplikací využít. Pro čtenáře, které toto téma zaujalo, tak zůstává dostatečný prostor k dalšímu studiu této problematiky.
57
Seznam použité literatury [1] FOWLER, Susan, STANWICK, Victor. Web Application Design Handbook: Best Practices for Web-Based Software. 2004. ISBN 1-55860-752-8. [2] PURBA, Sanjiv. High-performance Web databases. 2001. ISBN 0-8493-0882-8. [3] PETERSEN, John V. Absolute Beginner’s Guide to Databases. 2002. ISBN 0-78972569-X. [4] PostgreSQL: An Open-Source Object Relational Database Management System (ORDBMS) [online]. 2002 [cit. 2010-03-30]. Text v angličtině. Dostupný z WWW:
. [5] Wikipedia : Django (web framework) [online]. 2010 [cit. 2010-04-02]. Text v angličtině. Dostupný z WWW: . [6] Wikipedia : Hierarchical Database Model [online]. 2010 [cit. 2010-03-29]. Text v angličtině. Dostupný z WWW: . [7] Wikipedia : LAMP (software bundle) [online]. 2010 [cit. 2010-01-10]. Text v angličtině. Dostupný z WWW: . [8] Wikipedia : LAMP Windows Server 2008 [online]. 2010 [cit. 2010-03-22]. Text v angličtině. Dostupný z WWW: . [9] Wikipedia: Microsoft SQL Server [online]. 2010 [cit. 2010-03-30]. Text v angličtině. Dostupný z WWW: . [10] Wikipedia : Microsoft Visio [online]. 2010 [cit. 2010-04-03]. Text v angličtině. Dostupný z WWW: . [11] Wikipedia : Model-view-controller [online]. 2010 [cit. 2010-04-01]. Text v angličtině. Dostupný z WWW: . 58
[12] Wikipedia : MySQL [online]. 2010 [cit. 2010-03-29]. Text v angličtině. Dostupný z WWW: . [13] Wikipedia : Oracle Database [online]. 2010 [cit. 2010-03-30]. Text v angličtině. Dostupný z WWW: . [14] Wikipedia : Paper prototyping [online]. 2010 [cit. 2010-04-03]. Text v angličtině. Dostupný z WWW: . [15] Wikipedia : Python (programming language) [online]. 2010 [cit. 2010-04-02]. Text v angličtině. Dostupný z WWW: . [16] Wikipedia : Requirements analysis [online]. 2010 [cit. 2010-01-10]. Text v angličtině. Dostupný z WWW: . [17] Wikipedia : Ruby (programming language) [online]. 2010 [cit. 2010-04-02]. Text v angličtině. Dostupný z WWW: . [18] Wikipedia : Ruby on Rails [online]. 2010 [cit. 2010-04-02]. Text v angličtině. Dostupný z WWW: . [19] Wikipedia : Service-oriented architecture [online]. 2010 [cit. 2010-04-01]. Text v angličtině. Dostupný z WWW: . [20] Wikipedia : Solution stack [online]. 2009 [cit. 2010-03-20]. Text v angličtině. Dostupný z WWW: . [21] Wikipedia : Symfony [online]. 2010 [cit. 2010-04-02]. Text v angličtině. Dostupný z WWW: . [22] Wikipedia : Use case [online]. 2010 [cit. 2010-01-10]. Text v angličtině. Dostupný z WWW: .
59
[23] Wikipedia : Use-case analysis [online]. 2010 [cit. 2010-01-10]. Text v angličtině. Dostupný z WWW: . [24] Wikipedia : Use case diagram [online]. 2010 [cit. 2010-01-10]. Text v angličtině. Dostupný z WWW: . [25] Wikipedia : Website Wireframe [online]. 2010 [cit. 2010-04-03]. Text v angličtině. Dostupný z WWW: .
60
Seznam obrázků Obrázek 1: Analýza požadavků je první etapa v procesu vývoje .......................................... 8 Obrázek 2: Příklad asociace mezi třídami ........................................................................... 10 Obrázek 3: Příklad popsaných atributů navazující na obrázek 2......................................... 11 Obrázek 4: Příklad use case modelu restaurace................................................................... 20 Obrázek 5: Zobrazení architektury MVC ............................................................................ 31 Obrázek 6: Zobrazení architektury SOA ............................................................................. 32 Obrázek 7: Příklad hierarchického modelu ......................................................................... 38 Obrázek 8: Příklad síťového modelu ................................................................................... 40 Obrázek 9: Příklad databáze odpovídající relačnímu modelu ............................................. 41 Obrázek 10: Příklad objektově-orientované databáze ......................................................... 42 Obrázek 11: MySQL Workbench ve Windows zobrazující úvodní stránku ....................... 44 Obrázek 12: Ukázka papírového prototypování .................................................................. 51 Obrázek 13: Visio 2007 - ukázka drátěného modelu .......................................................... 52 Obrázek 14: Axure RP Pro - ukázka drátěného modelu...................................................... 53
Seznam tabulek Tabulka 1: Příklad entity reprezentované tabulkou ............................................................. 39
61
