Fakulta informatiky a statistiky

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze Lucie Fryaufová Metodiky zjišťování požadavků uživatelů na webové prezentace Bakalářská práce 2010

Prohlášení Prohlašuji, že jsem bakalářskou práci na téma Metodiky zjišťování požadavků uživatelů na webové prezentace zpracovala samostatně a použila pouze zdrojů, které cituji a uvádím v seznamu použité literatury. V Praze dne:... podpis

Poděkování Na tomto místě bych chtěla velice poděkovat vedoucí mé bakalářské práce PhDr. Heleně Kučerové za poskytnuté konzultace, rady a připomínky během zpracování mé bakalářské práce. Dále bych ráda poděkovala své rodině a blízkým, kteří mi byli oporou při mém studiu.

Abstrakt Cílem bakalářské práce je analýza metodik z oblasti softwarového inženýrství. Práce se nejprve zabývá definováním pojmů metodiky a stručným popisem Webu, jeho vývojem a přínosem webových prezentací v dnešní době. Závěrečné kapitoly jsou zaměřeny na zjišťování požadavků na webové prezentace ve vybraných metodikách. Abstract The aim of bachelor thesis is the analysis methodologies in the part of software engineering. First this work discusses the definition of methodology and brief description of the Web, its evolution and the benefits of the website today. The final chapters are devoted to identifying the requirements for the website in the selected methodologies.

Obsah 1. Úvod... 7 2. Význam a vývoj metodik při vývoji softwaru... 8 2.1 Definice a obsah pojmů metodika, metodologie a metoda... 8 2.2 Vývoj a vznik metodik a životních cyklů... 10 2.2.1 Model napiš a oprav (Code and Fix Model)... 10 2.2.2 Stagewise model... 10 2.2.3 Vodopádový model... 10 2.2.4 Spirálový model... 13 2.3 Kategorizace metodik... 14 2.3.1 Agilní vs. rigorózní metodiky... 17 3. Web a webové prezentace... 18 3.1 Vývoj WWW... 18 3.1.1 Statické a dynamické webové stránky... 24 3.2 Webové prezentace... 25 3.2.1 Typy webových aplikací... 25 4. Specifikace požadavků na webové prezentace... 28 4.1 Rozdíly ve vývoji softwaru a internetové aplikace... 28 4.1.1 Webové inženýrství... 28 4.1.2 Vývojový tým... 29 4.1.3 Vývoj aplikace... 29 4.1.4 Cíl, vize a uživatelé... 31 4.2 Požadavky na webové aplikace... 33 4.2.1 Definice pojmů... 33 4.2.2 Typy požadavků... 34 4.2.3 Vývoj požadavků... 37 5. Vybrané metodiky zjišťování požadavků uživatelů na webové prezentace. 42 5.1.1 Metodika RUP... 42 5.1.2 Metodika Jennifer Fleming... 48 5.1.3 Metodika Web Modeling Language (WebML)... 50 5.1.4 Metodika UML-Based Web Engineering (UWE)... 54 6. Závěr... 56 7. Seznam zdrojů... 58 6

1. Úvod V dnešní době si málokdo dokáže svůj život představit bez Internetu. Tato stále se vyvíjející technologie nás provází každým dnem. Její rozmach byl hlavně díky službě World-Wide-Web. Hlavní přínos Webu spočívá ve využití jeho služeb. Uživatel může jednak z webových prezentací získávat velké množství informací, ale také může využívat aplikace, které zjednoduší jeho každodenní činnosti. Prezentace má také velký přínos pro firmy, a to z možnosti celosvětového zveřejnění. Pro vývoj webové prezentace je k dispozici celá řada metodik, které představují souhrn činností procesu. Cílem práce je analyzovat metodiky zjišťování uživatelských požadavků a zhodnotit jejich specifikaci požadavků uživatelů. Práce je rozdělena do čtyř kapitol. První kapitola se věnuje vývoji metodik a životních cyklů. Zaměřuje se na definici a porovnání s příbuznými pojmy metodologie a metoda. Popisuje také jednotlivé modely, které stály při počátku vzniku metodik. Druhá kapitola se týká webových prezentací a stručnou historií webu. Vysvětlím na jakých principech je postaven World-Wide-Web a objasním hlavní rozdíl mezi webovou prezentací a aplikací. Vývoj webové prezentace je dlouhý proces, který je rozdělen do několika fází. Zaměřím se hlavně na fázi specifikace a sběr požadavků. Vyberu nejčastější prostředky zjišťování požadavků. Na základě vybraných metodik, kterými jsou RUP (Rational Unified Process), metodika Jennifer Fleming, Web Modeling Language (WebML) a UML-Base Web Engineering (UWE), se zaměřím na fázi zjišťování požadavků a stručně popíšu jednotlivé fáze vývoje webové prezentace. 7

2. Význam a vývoj metodik při vývoji softwaru Na úvod své bakalářské práce, která je zaměřena popisem metod v oblasti vývoje webových prezentací, bych ráda stručně objasnila pojem metodika a s ním spojené pojmy jako životní cyklus a proces vývoje softwaru. V této kapitole se zaměřím na vysvětlení pojmu metodika, její vývoj a kategorizaci metodik. 2.1 Definice a obsah pojmů metodika, metodologie a metoda Pojem metodika bývá dost často zaměňován s dalšími pojmy, kterými jsou - metodologie a metoda. Ve skutečnosti není až takový rozdíl, používá-li se slova metodika či metodologie, avšak pro upřesnění bych uvedla hned několik definic. Obecné vysvětlení pojmu metodika definuje tento pojem jako pracovní postup nebo nauku. Metodika ve vývoji software představuje souhrn doporučených praktik a postupů, pokrývajících celý životní cyklus vytvářené aplikace. Pro řešení dílčích problémů mohou být v rámci nasazení metodiky uplatněny specifické postupy metody. [1] Metodika budování IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení. [2] Metodika se používá k označení komplexních postupů a návodů na vývoj softwarové aplikace. Skrývají se pod ní všechny etapy řešení (u vývoje softwarové aplikace tedy jde o všechny fáze životního cyklu). [3] 8

Metodologie je nejobecnější pojem a znamená ve své podstatě nauku o metodikách. Jinými slovy, pod pojmem metodologie se skrývá vědní disciplína, která nějakým způsobem rozebírá metodiky, definuje je apod. [3] Metoda je postup nebo návod, jak získávat správné poznatky, prostředek poznání. [4] Shrneme-li všechny tyto pojmy, které jsme si definovali, dospějeme k závěru, že metodika je proces, který se zabývá především popisem postupů a procesů činností spějících k dosažení určitého cíle. Metodika na všechny procesy nahlíží z výšky. Nezabývá se způsobem jak danou operaci provést, ale pomocí čeho ji provést. Metodika je tedy souhrn postupů a návodů, které popisují činnosti při návrhu, vývoji, analýze a nasazování software. Ke všem činnostem je potřeba prostředky, které umožní efektivně dosáhnout stanoveného cíle. Jsou jimi specifické nástroje, techniky, metody, souhrny etap, postupů či pravidel, dokumenty, role a další prostředky závisející na konkrétní metodice. V metodikách z oblasti softwarového inženýrství by měly být zahrnuty i prvky informačního systému pracovníci, software, hardware, data a organizační procedury. Metodologie je vědní disciplína, která se zabývá tvorbou a aplikací metod. Samotná metoda je označení konkrétního postupu, který vede k vyřešení jednotlivých problémů. V mé práci budu popisovat metodiky, které se zaměřují zejména na vývoj webových prezentací. 9

2.2 Vývoj a vznik metodik a životních cyklů Podle [3] patří metodiky vývoje aplikací k nejdůležitějším produktům softwarového inženýrství. Během vývoje se metodiky pokoušely přizpůsobit aktuální situaci, to znamená, že se přizpůsobovaly konkrétním požadavkům kladeným na software. Cílem metodik tedy bylo odstranit nedostatky vývoje aplikací. Dříve se metodiky specializovaly spíše na fáze analýz, specifikace testů atd. V dnešní době je důležité hlavně (agilní metodiky) dodání výsledného produktu co nejdříve. 2.2.1 Model napiš a oprav (Code and Fix Model) Tento model se používal v 50. letech minulého století. Jeho vznik byl zcela spontánní, dnes by se ale neprezentoval jako metodika. Činnost modelu se dala popsat následovně: Sepsání aplikace spuštění (zařazení do provozu) - opravování chyb. 2.2.2 Stagewise model Model životního cyklu založený na striktní posloupnosti fází byl uveden v roce 1957. Hlavní novinkou v tomto modelu bylo rozdělení vývoje softwaru na několik fází definice problému, specifikace požadavků, architektura a návrh, implementace, integrace, provoz. Nevýhoda tohoto modelu byla absence zpětné vazby. Znamenalo to tedy, že model nebyl schopen ověřit výsledky jednotlivých fází. Po skončení jedné fáze se hned pokračovalo v další. Chyběla možnost revize, hodnocení výsledků a hledání rizik. Jediná možnost návratu byla v samotném závěru, kdy po dodání aplikace následovala fáze revalidace. Zde bylo možné rozhodnout se, zda se vrátit zpět, nebo opětovně vstoupit do procesu. 2.2.3 Vodopádový model K charakteristice tohoto modelu bych na úvod citovala definici, kterou vyslovil roku 1970 Dr. Winston Royce: Máme-li být úplně korektní, musíme dodat, že model životního cyklu nerovná se metodice. Mezi metodikou a modelem životního cyklu není úplná shoda zatímco model životního cyklu popisuje pouze život aplikace a kroky prováděné při vývoji, metodika obvykle obsahuje i řadu dalších informací a podrobněji předepisuje, co se má v kterém okamžiku udělat. V současnosti je 10

k dispozici řada metodik, a tak se při vývoji více používají metodiky než holé modely životního cyklu; v minulosti však byla situace právě opačná, a proto při úvahách o metodikách nesmíme zapomenout ani na modely životních cyklů. [3] Jak už bylo zmíněno v definici, vodopádový model ztvárňuje životní cyklus. Tento cyklus má pevně daný postup vývoje. Důležitá je analýza a z ní vyplývající návrh systému. Oproti svému předchůdci (model stagewise) se vodopádový model liší přítomnou zpětnou vazbou. Model je tvořen z několika fází a na konci fáze dochází k jejímu vyhodnocení a následné opravě či přepracování. Pokud by po dokončení jednotlivých fází došlo k nějakému problému, je možné se vrátit k jádru problému (např. úprava specifikace problému, změna návrhu či zvolení jiných podmínek testů, atd.). Důležitým znakem, který charakterizuje tento model je rozdělení do postupně uspořádaných fází, které odpovídají jednotlivým vývojovým aktivitám (definice, analýza, atd.). To znamená, že po ukončení jedné fáze může být zahájena další fáze. Neexistuje možnost, aby bylo prováděno více fází najednou. Dalším charakteristickým znakem modelu je přesně definovaná posloupnost kroků a fází: [3] 1. definice problému a seznámení s cílovou oblastí 2. analýza a specifikace požadavků 3. návrh 4. implementace 5. integrace a testování 6. provoz a údržba 11

Vodopádový model byl vůbec prvním modelem, který použil posloupnost fází při vývoji softwaru. Na jednu stranu je výhodou, že model vyniká svojí jednoduchostí. Má přesně dané postupy, určující co se má v daném okamžiku udělat. Na druhou stranu má výhoda v jednoduchosti i svoji slabou stránku. Model je užitečný pouze pro malé projekty. Na rozsáhlejší a komplexnější projekty je tento model příliš jednoduchý. Ideálně se model hodí pro vedení firmy, neboť lze stanovit tzv. rámcový harmonogram. Uživatelé tak mohou kontrolovat, zda všechny etapy vývoje odpovídají časovému harmonogramu projektu, zda je plněna specifikace požadavků či není překročen rozpočet projektu. Nevýhodou modelu je jeho nepružnost na změny, kdy při jakékoliv změně v zadání dochází ke zdlouhavému procházení fází analýzy a návrhu, tvorba příslušné dokumentace a opětovnému schválení procesu. Také dodání produktu zákazníkovi nepatří mezi silné stránky. Dodání probíhá formou velkého třesku 1. Tím hrozí riziko odhalení chyb v návrhu, a proto je potřeba vrátit se zpět na začátek a opravit chyby. Vzniká tak zbytečné prodlužování a prodražování projektu. 1 Forma velkého třesku: Dodavatel zákazníka potřebuje pouze v úvodu projektu (specifikace požadavků) a poté na konci, kdy mu předává hotovou aplikaci. [3] 12

2.2.4 Spirálový model Spirálový model byl uveden v roce 1985. Za jeho vznikem stojí Barry Boehmen. Řadí se stejně jako vodopádový model k životnímu cyklu vývoje softwaru. Vývoj aplikace probíhá v opakovaných krocích - iteracích, které byly hlavním přínosem ve vývoji tohoto modelu. Na úvod projektu jsou stanoveny pouze obecné požadavky, vnější funkčnost a architektura. Poté se vyvine část aplikace a následuje konzultace se zákazníkem, kde je možné podrobněji specifikovat konkrétní situaci a následně pokračovat dalším krokem. Na začátku každé iterace je prováděna analýza rizik 2. Jejím cílem je zjištění možných rizik v průběhu vývoje projektu. Hlavní výhodou tohoto modelu je jeho nezávislost. Model není závislý na speciálních metodikách či strategiích a proto je možné ho využít pro konkrétní postupy v závislosti na povahách projektů a zvláštnostech firmy. Model je možné využít i pro rozsáhlé projekty díky tomu, že klade velký důraz na plánování, ověřování a analýzu rizik. Pro vývoj webových aplikací se však tento model nehodí. Hlavní důvod je jeho zdlouhavý vývoj závislý na množství prováděných analýz a tvorby obsáhlé dokumentace. [3] 2 Analýza rizik: myslitelné situace nebo události, které mohou způsobit nesplnění cílů projektu [3] např. dodání aplikace ve stanovený termín, implementace všech požadovaných funkcí, vztahy k nákladům, legislativě, konkurenci, apod. 13

2.3 Kategorizace metodik V předchozí části jsem se věnovala obsahu pojmu metodika a životním procesům, které daly prvopočátky pro vznik a rozvoj dalších metodik a procesů při budování IS/ICT 3 či vývoji právě webových prezentací. Při budování jakékoliv webové prezentace nebo informačního systému je důležité použít tu správnou metodiku. Metodik existuje celá řada, nastává však otázka, jakou metodiku zvolit, aby měla právě takové vlastnosti, které charakterizují náš projekt. Proto jsem do kapitoly, která se zabývá metodikami, zahrnula i část, kde se budu věnovat rozdělování metodik do kategorií podle určitých kritérií. Vybrala bych pouze nejdůležitější kritéria a podle nich popsala základní členění. Jako hlavní zdroje pro tuto pasáž jsem použila publikaci [2], kterou můžu zároveň doporučit zájemcům, kteří se chtějí zabývat detailnějším popisem kategorizací metodik. Aby bylo možno metodiky dobře kategorizovat, je potřeba si nejprve stanovit důvody jejich existence. V díle uvádí autorka tzv. objektivní příčiny existence různých metodik. Musíme brát v potaz následující skutečnosti: Rozlišení technologií různé technologie vyžadují různé techniky a metody (datově orientované metodiky vyhovují pro vývoj datově orientovaných aplikací, objektově orientované metodiky se více hodí pro projekty využívající objektově orientované technologie). Analýza firemní kultury možnou příčinou selhávání metodik je právě to, že nepočítají s firemní kulturou. Jiná firemní kultura může mít kladný ale i záporný vliv na implementaci metodiky. Individualita jedinců a týmů důležitým faktorem při vývoji informačního systému jsou lidé. Každý jedinec má jiné charakteristické vlastnosti - schopnosti, dovednosti, znalosti a způsoby dosažení cílů, proto nelze vytvořit jedinou metodiku, která by vyhovovala všem, ale je potřeba přizpůsobit ji konkrétním lidem či týmu lidí. Různé vlastnosti projektů projekty můžeme rozlišovat podle velikosti týmu, důležitosti, postavení produktů na trhu či upřesnění vnějšího prostředí (např. projekty pro státní zakázky). 3 IS informační systém, ICT informační a komunikační technologie 14

Díky objektivním příčinám, je zřejmé, že existuje celá řada metodik. Aby bylo možné metodiky klasifikovat, je potřeba stanovit si kritéria. V publikaci [2] jsou vedena následující kritéria: zaměření rozsah váha typ řešení doména přístup k řešení Pro upřesnění bych uvedla stručnou charakteristiku každého kritéria. Zaměření metodiky Toto kritérium definuje dvě kategorie metodik globální a projektové. Hlavní odlišnost těchto metodik je v jejich zaměření. Metodiky globální jsou zaměřené na vývoj, provoz a zavedení softwaru pro určitý subsystém, ale v rámci jednoho podniku. Kdežto metodiky projektové spadají do určité oblasti, ve které je implementován informační systém. Hlavním kritériem je určit, zda je metodika zaměřena na vývoj informačního systému celé organizace nebo jen na určitý projekt. Projektové metodiky jsou více publikované. Ke globálním metodikám patří např. MMDIS, CMM či MDA. 4 Rozsah metodiky Rozsah metodiky stanoví tři hlediska, která podrobněji specifikují budování systému. Při vývoji systému je potřeba vymezit, kde metodika začíná a kde končí. Prvním hlediskem jsou fáze životního cyklu, ke kterým patří strategie (globální, informační), úvodní studie, analýza a návrh, implementace, zavádění a v neposlední řadě provoz a údržba. Dalším hlediskem je spolupráce specialistů, a proto se na budování informačního systému podílí typové skupiny spolupracovníků. Třetím posledním bodem jsou dimenze, které zahrnují detailnější specifikaci vyvíjeného softwaru. Patří k nim dimenze pokrývající požadavky na hardware, software, datovou základnu, uživatelské rozhraní, atd. 4 MMDIS Multidimensional Management and Development of Information Systém; CMM Capability Maturity Model; MDA Model Driven Architecture [2] 15

Váha metodiky Podle váhy rozdělujeme metodiky na lehké a těžké. Těžké metodiky jsou označovány jako rigorózní a vyznačují se tím, že mají přesně definované činnosti, procesy či artefakty 5. Opakem jsou lehké metodiky neboli metodiky agilní. Jejich hlavní charakteristikou je rychlost a flexibilita vývoje aplikací. Vlastnosti metodik jsou definovány v pojmech - velikost, hustota a váha. Váha metodiky je potom shrnutí těchto pojmů. Typ řešení Typ řešení je kritérium, které podává informace o způsobu realizace řešení. Ve většině případů se nevyvíjí nový software, ale bývá implementován typový aplikační software. To může vést k rozdílnosti v metodice zavádění typového aplikačního softwaru a metodice vývoje softwaru. V současnosti jsou některé části informačních systémů zajišťovány externími specializovanými firmami, které se zabývají poskytováním aplikačních služeb. Doména Každý informační systém je vytvářen za podpory podnikových procesů. K podnikovým procesům se připojuje i řízení externích vztahů se zákazníky, dodavateli a ostatními partnery. Autorka publikace [2] uvádí, že specifikace domén pro účely kategorizace metodik vychází z aplikační architektury informačních systémů. Obecné schéma aplikační architektury zobrazuje jednotlivé části informačního systému. Jako příklady aplikační architektury bych uvedla např. Business Intelligence, SCM (Supply Chain Management), ERP (Enterprise Resource Planning), CRM (Customer Relationschip Management) atd. 6 Přístup k řešení Hlavním cílem kritéria je poukázat na základní paradigma metodiky. Vývoj softwaru je tedy charakterizován přístupy, jež definují hlavní vývojové etapy - analýza, návrh a implementace. Přístupy můžou být orientované na strukturovaný vývoj, rychlý vývoj či objektově orientovaný vývoj. 5 Artefakt je specifikace reálných objektů [10] 6 SCM řízení dodavatelských řetězců, ERP integrace podnikových aplikací, CRM řízení vztahů se zákazníky [2] 16

2.3.1 Agilní vs. rigorózní metodiky Dnešní doba je charakterizována neustálým vývojem prakticky na každém našem kroku. Je tomu tak i při vývoji softwaru. Tato část vývoje informačních technologií je brána jako jedna z nejvíce proměnlivých oblastí. Změny jsou nejen v technických možnostech, technologiích, vývojových nástrojích, ale také v dostupnosti výpočetní techniky z hlediska kvality. Tady jsou počátky sílící konkurence, která se objevuje na poli výrobců softwaru. Rozdělení metodik na rigorózní a agilní souvisí do jisté míry s kritériem Váha metodiky. Jak je uvedeno výše, rozděluje toto kritérium metodiky na lehké, k těm patří spíše metodiky agilní a k těžkým naopak rigorózní. [2] Rigorózní metodiky vycházejí z předpokladu získání všech potřebných požadavků na budování systému od zákazníků. Budování informačního systému tak vychází z původního vodopádového modelu, kde se dá přesně popsat a stanovit podrobná pravidla pro jeho plánování, řízení a měření. Probíhají zde jednotlivé fáze vývoje - plánování, analýza, návrh, implementace, zavedení. Metodika je tedy podrobně zaměřena na probíhající procesy ve vývoji softwaru. Předpokladem těchto podrobných procesů je dosažení kvalitního výsledku. S vývojem nových technologií, změnou požadavků na software a hlavně k urychlení vývoje systému, přestávaly rigorózní metodiky v těchto podmínkách vyhovovat. Bylo potřeba vytvořit metodiky, které umožnily řešit projekty pružně, rychle a dokázaly se okamžitě přizpůsobit měnícím se požadavkům. Tyto metodiky se nazývají agilní. Z hlediska významu slova agilní aktivní, jsou tyto metodiky určeny pro širokou škálu softwarových projektů, převážně však pro internetové aplikace. Agilní metodiky se zaměřují na zákazníky a na kvalitu vyvíjeného softwaru. Při vývoji webové aplikace hraje hlavní roli čas, resp. rychlost. Vyvíjíme-li web déle než půl roku, hrozí zde riziko, že konkurence už dávno spustila dva jiné. Cílem agilních metodik je vyvinout aplikaci co nejrychleji, předložit zákazníkovi a na základně jeho zpětné vazby ji upravovat. U internetových aplikací také platí, že funkčnost lze vytvářet za chodu aplikace. [2], [3] 17

3. Web a webové prezentace World-Wide-Web World-Wide-Web, často označován zkratkou WWW, Web či W3. Systém, který umožňuje uživateli přístup k různým typům informací v prostředí sítě Internet. V dnešní době si bez internetu většina lidí nedokáže svůj život ani představit. Internet se stává každodenní součástí našeho života. Kdo odejde ráno z domova, aniž by se předtím nepodíval, v kolik hodin mu jede tramvaj a do kolika mají otevřeno v jeho oblíbené restauraci? Člověk se s touto fenomenální službou sblížil tak rychle, že si ani nestačil uvědomit, jak ovlivňuje jeho sociální chování. Podle autorů publikace [6] stojí současný web na křižovatce vývoje na jedné straně narůstá množství informací na webu, na straně druhé narůstá i množství běžných uživatelů a tak současné technologie reprezentace a vyhledávání informací naráží na své limity. Aby tento problém mohl být vyřešen, je potřeba přenechat vyhledávání informací strojům a zajistit, aby komunikace s webem odpovídala přirozenému myšlení člověka. Uživatel WWW je tedy odkázán na práci s hypertextovými dokumenty. Hypertext je vlastně způsob pohledu na informace. Hypertextový dokument se skládá ze sítě uzlů, které představují části textových dokumentů, grafiku a tabulky a jsou mezi sebou propojeny vazbami. Z této definice můžeme pochopit význam slova web. Je to pavučina, která pomocí tenkých nitek přenosových cest umožní spojovat dokumenty po celém světě do jednoho celku. [7] 3.1 Vývoj WWW Původní myšlenka pro vznik WWW byla vytvoření jednotného globálního informačního prostoru. Znamenalo to vytvořit nějaké spojení, které by umožnilo počítačům sdílet informace. Tato myšlenka se zrodila v roce 1980 v Ženevě. Postupný vývoj tohoto propojení dal vzniku jedné z největších virtuálních sítí World Wide 18

Web. Původně byl tento systém zamýšlen jako nástroj pro sdílení informací a dokumentů mezi vědci a vědeckými institucemi. [11] Jak už jsem se zmínila v předchozí kapitole, systém WWW je univerzální metoda, založena na principu hypertextu, který je charakterizován jako celek informací propojený systémem odkazů. Díky odkazům se pouhým klikem dostaneme z jedné stránky k další. Uživatel pomocí internetu má možnost získávat spoustu nových informací. Velká výhoda webu je jeho nezávislost na platformě. Stránku si můžeme prohlížet na počítači s jakýmkoliv operačním systémem. Celá tato nezávislost je postavena na standardech (normách). Tyto standardy jsou v oblasti Internetu popsány v tzv. RFC dokumentech. Představují dokumenty, které definují oficiální fungování Internetu. Zabývají se tedy nejrůznějšími aspekty fungování Internetu, jako např. komunikace v rámci Internetu, formáty používaných datových struktur a také protokolů TCP/IP 7. Standardy jsou volně šiřitelné a bezplatné, nevážou se na specifické vlastnosti daného operačního systému, takže se dají bez problému implementovat na všechny používaného platformy. [12], [15] Co bylo dále potřeba k tomu, aby Web mohl fungovat a čtenáři si tak mohli pročítat informace na internetu? Hypertext Markup Language (HTML), z anglického překladu se jedná o tzv. značkovací jazyk, který popisuje obsah webové stránky. Původní verze tohoto jazyka umožňovala rozčlenění textu do několika logických úrovní, použití prostředků pro zvýraznění textu a také možnost zařadit do textu odkazy a obrázky. Postupem času pronikala do internetu čím dál víc komerční sféra a tak bylo potřeba obohacovat tento jazyk o nové a lepší formátovací prvky (např. skriptovací jazyk (JavaScript), kaskádové styly 8, apod.). [12] Pro dokonalé vysvětlení HTML jazyka nám ještě zbývá stručně objasnit pojmy SGML (Standard Generalized Markup Language) a DTD (Document Type Definition). SGML je metajazyk potřebný k definici různých značkovacích jazyků. Tento typ 7 TCP/IP protokoly zabezpečující základní komunikaci v systému [13] 8 CSS Cascading Style Sheet kolekce metod pro grafickou úpravu stránek [14] 19

dokumentu, ve kterém je definice, se nazývá DTD (Document Type Definition). Definice DTD nás informuje, které elementy a atributy (syntaxe) můžeme v dokumentu použít. Jednodušeji řečeno, SGML je programovací jazyk, který je v DTD zapsaný. S těmito pojmy souvisí i tzv. parsování. Programy parsery jsou vytvořeny k tomu, aby kontrolovaly, zda dokument SGML vyhovuje DTD. Vyhověno je pouze v tom případě, že elementy, atributy a přípustné vztahy mezi elementy jsou nadefinovány v dokumentu DTD. Dokument je zkontrolován právě tehdy, pokud je parser správně nakonfigurován a nalezne k němu odpovídající HTML. Postupem času, kdy se technologie webu zdokonaluje, bylo potřeba použít efektivnějších metod jazyka HTML. Tím mám na mysli vytvoření části textu s dynamickým významem (zvýraznění nadpisů, označení jednotlivých úseků, tabulek, atd.). Pomocí jazyka SGML si můžeme sice definovat vlastní sadu značek a docílit tak výstižnějšího označení jednotlivých částí textu. Avšak implementace SGML v programech bývá časově i finančně náročná. Proto bylo opět potřeba vytvořit jazyk, dostupný nejen velkým a finančně zajištěným firmám, ale i běžným uživatelům Webu. Členové konsorcia W3C 9 tak vytvořili nový jazyk XML (extensible Markup Language), který je zjednodušenou verzí SGML. XML, stejně tak jako jeho předchůdci, patří mezi značkovací jazyky. Jelikož jazyk XML řadíme mezi standardy, můžeme pomocí něj generovat jazyky definované jednotnou cestou. [12] Spolu s jazykem bylo potřeba vytvořit program, který zformátuje daný text a zobrazí ho jako webovou stránku. Tímto pomocníkem mám na mysli webový prohlížeč (browser). Tento program komunikuje s HTTP serverem a zpracovává přijatý kód v daném jazyce. Vůbec prvním prohlížečem v historii byl WorldWideWeb, později přejmenován na Nexus. [16] V dnešní době se nám nabízí dostatek prohlížečů, které můžeme používat. Stačí si jen vybrat podle referencí či podle našich požadavků. Já osobně dávám přednost rychlým a bezpečným prohlížečům. 9 W3C mezinárodní webové konsorcium vyvíjející webové standardy pro World Wide Web, přeloženo z [17] 20

Nejvíce používaný webový prohlížeč Internet Explorer, vyvíjený firmou Microsoft, se dostal na trh až v roce 1995 spolu s novým operačním systémem Windows 95. V současnosti je na trhu dostupná nejnovější verze Internet Explorer 8. [19] Pro zajímavost bych uvedla dva grafy nejpoužívanějších prohlížečů. K vybraným prohlížečům jsem zařadila Internet Explorer, Firefox, Safari a Google Chrome. Pro porovnání jsem vybrala grafy z let 2008 a 2010. Je možné zaznamenat rozdíly v procentuálním zastoupení používání webových prohlížečů v období těchto dvou let. Tyto data jsem čerpala ze serveru NetMarketShare. Název prohlížeče Používání % prosinec 2008 březen 2010 MS Internet Explorer 74,65 55,27 Firefox 18,15 20,53 Safari 1,39 3,77 Chrome 0,40 5,93 21

(%*'& )! (! '! 56789:2,92:7;<=/-,2, &! >?,2@-< %! 6A@A,? ")*"& $! B.,-C2 #! "*$4!*% "!! +,-./0123 F#5G()(;(H&I.,?JB/5ADIKB(.#,L2BJ&M&(/ H&I.,?JB/5ADIKB(.#,L2BJ&M&(/(#,C&(:NNE3(%.#5C,/$A,(A5(%$'25-D(.,@'O6A?60CL(-56(%( %.#5C,/$A,(A5(%$'25-D(.,@'O6A?60CL(-56(%((7)E9( '! &&*#( &! %! 56789:2,92:7;<=/-,2, $! >?,2@-< #!*&$ B.,-Ce #! 6A@A,? "! &*4$ $*((! +,-./0123 F#5G(:(*((H&I.,?JB/5ADIKB(.#,L2BJ&M&(/ B/5ADIKB(.#,L2BJ&M&(/(#,C&(:N)N3(%.#5C,/$A,(A5(%$'25-D(.,@'O6A?60CL(-56(% #,C&(:N)N3(%.#5C,/$A,(A5(%$'25-D(.,@'O6A?60CL(-56(%(7)E9( 22

Ale vraťme se zpátky k webu. Principy systému WWW jsou založeny na architektuře klient/server 10. Ve vztahu k webovým aplikacím je klientem myšlen právě webový prohlížeč. Základem tohoto modelu je vzájemná komunikace mezi uživatelem, klientem a serverem, zpracování dat a prezentace výsledků uživateli. Data jsou uložená na webovém serveru, kde také probíhá zpracování určitého požadavku od uživatele. Server poté odešle výsledky klientovi, který zobrazí stánku s požadovanými výsledky. Aby tato komunikace mohla probíhat, je potřeba si ještě definovat prostředky, na kterých je systém WWW postaven. V systému WWW se jedná o URL, HTTP, HTML a CGI. [7] V následujícím odstavci se zaměřím na charakteristiku pouze prvků URL, HTTP a CGI. Popis jazyka HTML byl popsán již v předchozí kapitole. URL (Uniform Resource Locator) je lokátor, který specifikuje zdroje na Internetu. Můžeme ho blíže charakterizovat jako synonymum internetové adresy, např. http: //www.seznam.cz URL, které odkazuje na stránku Seznamu. [14] HTTP (HyperText Transfer Protocol) je protokol, díky kterému probíhá komunikace mezi klientem a serverem. Klient je internetový prohlížeč (Mozilla, Explorer) a HTTP server je program, který běží na jiném počítači (server), programem může být např. Apache. Celý proces se skládá ze dvou činností klient zašle požadavek a tím navazuje vztah se serverem a server posílá odpověď klientovi na jeho požadavek. [7], [12] CGI (Common Gateway Interface) technologie umožňující komunikaci s jakýmkoli programem. Definuje rozhraní, které umožní spuštění programů. V současnosti se ale používají dokonalejší technologie např. PHP 11, J2EE 12 nebo nejnovější technologie tvorby webových aplikací Ajax 13. [6], [12] 10 model klient/server je určitá forma distribuovaného zpracování, kdy klient komunikuje se serverem s cílem vyměnit si informace mezi sebou. V našem případě chápeme tuto formu komunikace ve smyslu výpočetního modelu (softwarového). [7] 11 PHP Personal Home Page programovací jazyk pro tvorbu webové aplikace. [6] 23