Návrhy webových internetových aplikací

Transkript

1 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: doc. Ing. Stanislav Horný, CSc. Praha Duben, 2010

2 Prohlášení: Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a s použitím uvedené literatury. V Praze, dne.... Jiří Nachtigall

3 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.

4 Obsah Úvod Analýza požadavků Požadavky Typy požadavků Dokumentace Use case analýza Realizace Popis Třídy analýzy Odpovědnosti Asociace Chování Popis atribut Use cases Zaměření Stupeň detailu Notace Šablony Omezení Use case diagramy Use case vztahy User stories Vytváření user story Příklady Použití Výhody Omezení Shrnutí user stories a use cases Design architektury Serverová řešení LAMP WINS... 28

5 2.2 Aplikační vrstva PHP Python Ruby Java Databáze MySQL Oracle PostgreSQL MS SQL Server Wireframe design Papírové prototypování Microsoft Office Visio Axure RP Pro Visual design Závěr Seznam použité literatury Seznam obrázků Seznam tabulek... 61

6 Ú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

7 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

8 Obrázek 1: Analýza požadavků je první etapa v procesu vývoje Typy požadavků Zdroj: 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 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

9 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 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 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ý 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 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

10 nebude pracovat jiná třída v systému. Odpovědnosti jednotlivých tříd by se neměly vzájemně překrývat 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: 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

11 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: 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

12 č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 UML 1 use case diagram. Use cases nejsou normalizovány žádným konsorciem na rozdíl od UML, které je normalizováno OMG 2. Historie use case se datuje do roku 1986, kdy Ivar Jacobson, pozdější důležitý přispěvatel k UML a RUP 3, 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é 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

13 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) 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

14 Ú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 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. SysML 4 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ů Š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

15 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

16 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

17 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

18 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 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

19 - 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

20 Obrázek 4: Příklad use case modelu restaurace Zdroj: 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 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

21 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

22 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í 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í 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 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

23 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 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 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

24 - 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

25 Pro složitější aplikace může být 3-vrstvé řešení nedostatečné a bude potřeba využít n- vrstvé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í 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

26 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 License 5. Samotné jméno Linux pochází z jádra systému napsaného Linusem Torvaldsem v roce 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

27 podpůrný software potřebný ke spuštění celého systému, jako jsou například nástroje a knihovny, X Window System 6, KDE 7 a GNOM 8 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

28 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é 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 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

29 instalace, nasazení a obnovení, vylepšená diagnostika a monitorování, protokolování událostí, nové bezpečnostní funkce jako je BitLocker 9 a ASLR 10, 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

30 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

31 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: 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

32 architektury tak dochází ke vzniku přehledných aplikací, jejichž části (objekty) lze znovu použít. Obrázek 6: Zobrazení architektury SOA Zdroj: 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 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

33 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 license 11. 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

34 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é CRUD 12 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 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

35 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, mixiny 13 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

36 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 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

37 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

38 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: 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

39 Tabulka 1: Příklad entity reprezentované tabulkou ID Jméno Adresa Typ účtu 1 Michal Novák Revoluční 5, Praha 2 běžný 2 Petr Veselý Luční 15, Hodonín spořicí 3 Jan Dvořák K Nemocnici 1, Hořovice 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

40 Obrázek 8: Příklad síťového modelu Zdroj: Č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

41 Obrázek 9: Příklad databáze odpovídající relačnímu modelu Zdroj: 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

42 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: 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

43 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 API 14 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

44 Obrázek 11: MySQL Workbench ve Windows zobrazující úvodní stránku Zdroj: 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