Vybrané aspekty návrhu webových informačních systémů

Vybrané aspekty návrhu webových informačních systémů

scientific press

Radek Šilhavý, Petr Šilhavý, Zdenka Prokopová Pavel Pokorný, Martin Sysel, Miroslav Matýsek Karel Vlček, Libuše Svobodová

Vybrané aspekty návrhu webových informačních systémů

scientific press

Copyright © 2013 Radek Šilhavý, Petr Šilhavý, Zdenka Prokopová, Pavel Pokorný, Martin Sysel, Miroslav Matýsek, Karel Vlček, Libuše Svobodová

Vydalo vydavatelství Šilhavý, s.r.o. Scientific Press ve Vsetíně roku 2013.

v

edici

Scientific Press Serie, svazek číslo 2/2013. Publikace byla recenzována nezávislými recenzenty a schválena vědeckou redakcí. Recenze jsou archivovány u vydavatele. Publikace neprošla jazykovou úpravou. www.scientificpress.eu ISBN: 978-80-904741-3-0

Citační záznam ŠILHAVÝ, Radek, Petr ŠILHAVÝ, Zdenka PROKOPOVÁ, Pavel POKORNÝ, Martin SYSEL, Miroslav MATÝSEK, Karel VLČEK a Libuše SVOBODOVÁ. Vybrané aspekty návrhu webových informačních systémů. první. Vsetín: Šilhavý s.r.o., 2013. Scientific Press, 2/2013. ISBN 978-80-904741-3-0. Dostupné z: www.scientificpress.eu

Předmluva

Dostává se vám do rukou kolektivní monografie, která si klade za cíl diskutovat základní aspekty návrhu webových informačních systémů. Autoři se domnívají, že uvedené oblasti jsou důležité a představují aktuální stav poznání v oblasti webových informačních systémů a snaží se také navrhnout základní postupy, které povedou k návrhu spolehlivých webových informačních systémů. V první kapitole Trendy a vývoj životního cyklu jsou sumarizovány poznatky z oblasti softwarového inženýrství a je navržen základní koncept metodologie, která přispěje k systematickému vývoji. V druhé kapitole Specifikace a analýza požadavků je navržena metodologie sběru požadavků, která je přizpůsobena problematice webových informačních systém nebo obecněji webových aplikací. Právě tato fáze vývojového cyklu je velmi důležitá pro úspěch projektu webového informačního systému. Ve třetí kapitole Datové modelování a návrh databáze jsou diskutovány aspekty datového modelování z pohledu vývoje webových informačních systémů. Jsou představeny klíčové faktory, které dle názoru autorů přispívají k vývoji spolehlivého webového informačního systému.

Ve čtvrté kapitole Grafické formáty pro WIS přinášíme diskusi důležitosti správné volby grafického formátu a nezbytná teoretická východiska, aby bylo možné volit správný formát obrázků pro návrh uživatelského rozhraní i obsahovaných obrázků. Správný výběr grafického formátu přispívá ke kvalitnímu rozhodnutí a návrhu systému. V páté kapitole Bezpečnosti webových aplikací jsou představeny základní bezpečnostní otázky a rizika, které mohou ovlivnit návrh webového informačního systému. Bez znalostí těchto základních bezpečnostních otázek není možné vytvořit spolehlivý a bezpečný informační systém. V šesté kapitole Technologie Internetu, základní pojmy a principy a v kapitole sedmé Teoretické principy přístupu k internetové síti jsou předkládány technické předpoklady a potřebné teoretické znalosti, jejichž osvojení vede k schopnosti návrhu webového informačního systému tak, aby nejen splňoval potřeby uživatelů, ale také respektoval potřeby technologií, které jsou vždy využívány. Bez těchto znalostí není možné provést dobrý návrh informačního systému. V osmé kapitole Případová studie internetové aplikace je předkládána případová studie, která ilustruje moderní využití webového informačního systému jako výukové pomůcky pro obchodování na finančních trzích. Uživatelé takových aplikací mohou absolvovat, bez nutnosti cestování, kurzy nebo se sami, dle svých možností, naučit obchodování. Právě tyto vlastnosti jsou klíčové pro současnou popularitu webových informačních systémů.

Věříme, že tato monografie bude přínosem každému, kdo se chce zdokonalit v oblasti návrhu webových informačních systémů. Autoři

Summary

The following monograph presents a discussion about perspective trends in web-based information system analysis. Authors believe that the topics mentioned in the book are significant for this problematic area. The selected topics play a key role in reliable system design. Chapter (1) Trends and Lifecycle Development, discusses software engineering knowledge and proposes a perspective methodology for the systematic development of web-based information systems. The next chapter (2) Requirements Analysis and Software Specification, is a discussion about requirements gathering methods. The authors propose a new approach for requirements analysis that brings improvements to the requirements gathering process. Data Modelling and Database Design has nearly the same importance and therefore the following chapter (3), discusses data modelling and the specific needs of the web-based information systems. The key elements of the modelling principles are presented herein; but only factors which are significant for a reliable web-based information system are presented. Web-based information systems are linked to a

graphical user interface and designers are asked to respect the rules for the graphics elements file formats. Chapter (4) Graphical Formats for WIS, is a discussion about the graphic file formats and tries to establish the set of questions which have to be solved before the graphical part of a web-based information system is designed. Chapter (5) Web Application Security, is a commented review of security issues which have to be kept in mind by the designers. A quality designed web-based information system is not possible without deep insight into security and risk analysis. Internet technology and theoretical principles are key topics in Chapters 6 and 7. A high-quality web information system design depends on an ability to respect technological background because users‘ needs are not the only important issue for system design. The final chapter (8) is a Case Study. The samples of web-based information systems or applications are described. The described applications are used for financial market trading; or, to be precise they are used for trading education or for training traders. The Authors believe that the monograph brings benefits to those, who are looking to improve themselves in web-based systems design.

Obsah Trendy a vývoj životního cyklu�������������������� 1

Softwarové procesy a jejich vhodnost������������������������� 2 Vodopádový model��������������������������������������������� 5 Iterační model ��������������������������������������������� 6 Spirálový model ��������������������������������������������� 7 Proces vývoje ����������������������������������������������� 9 Koncepce a strategie �������������������������������������� 10 Struktura a design ���������������������������������������� 10 Kódování a vývoj ������������������������������������������ 11 Testování a spuštění �������������������������������������� 11 Optimalizace a údržba �������������������������������������� 11 Shrnutí vývojového procesu���������������������������������� 12

Specifikace a analýza požadavků při návrhu ������� 13

Co má specifikace obsahovat �������������������������������� 15 Požadavky �������������������������������������������������� 15 Jaké metody sběru lze využít�������������������������������� 16 Průběh sběru požadavků�������������������������������������� 19

Datové modelování a návrh databáze��������������� 21

Proces návrhu databáze ������������������������������������ 22 Konceptuální datový model ���������������������������������� 26 Tvorba konceptuálního datového modelu ���������������������� 28 Logický datový model �������������������������������������� 38 Normalizace dat �������������������������������������������� 40 Fyzický datový model �������������������������������������� 43

Grafické formáty pro WIS�������������������������� 45

Počítačová grafika a reprezentace obrazových informací ������ 45 Vektorová grafika�������������������������������������������� 46 Rastrová grafika �������������������������������������������� 48 Stručná charakteristika vybraného grafického software�������� 50 Program pro vektorovou grafiku - Inkscape�������������������� 51 Program pro rastrovou grafiku - Gimp ������������������������ 53 Grafické formáty v prohlížečích www stránek������������������ 56 Grafický formát SVG������������������������������������������ 57 Grafický formát BMP������������������������������������������ 58 Grafický formát GIF������������������������������������������ 59

Grafický formát PNG������������������������������������������ 62 Grafický formát JPG������������������������������������������ 63 Shrnutí ���������������������������������������������������� 67

Bezpečnost webových aplikací��������������������� 68

Bezpečností rizika������������������������������������������ 69 Injection �������������������������������������������������� 72 Cross-Site Scripting (XSS)���������������������������������� 76 Narušená autentifikace a správa relace ���������������������� 79 Nezabezpečený přímý odkaz na objekt ������������������������ 82 Cross-Site request forgery (CSRF) �������������������������� 82 Nezabezpečené kryptografické úložiště������������������������ 85 Chybné zamezení přístupu ke konkrétním URL������������������ 86 Nezabezpečená síťová komunikace ���������������������������� 87 Neplatné přesměrování a předávání parametrů ���������������� 87 Závěr ������������������������������������������������������ 88

Technologie Internetu, základní pojmy a principy� 90 Internet versus internet������������������������������������ 90 Intranet versus extranet������������������������������������ 90 Typy sítí �������������������������������������������������� 91 Přenášená data���������������������������������������������� 91 Simplex, poloduplex a plný duplex �������������������������� 92 Přenosové rychlosti ���������������������������������������� 92 Metody komunikace ������������������������������������������ 93 Sítě s přepojováním paketů���������������������������������� 94 Dělení dle počtu rámců�������������������������������������� 94 Přenosová média �������������������������������������������� 95 Koaxiální kabel �������������������������������������������� 96 Kroucená dvojlinka������������������������������������������ 96 Optická vlákna���������������������������������������������� 98 Komunikace vzduchem ��������������������������������������� 101 Přístupové metody LAN ������������������������������������� 102 Normování počítačových sítí ������������������������������� 104 Síťové protokoly������������������������������������������� 105 LAN Ethernet����������������������������������������������� 108 Propojování počítačových sítí ����������������������������� 111

Teoretické principy přístupu k internetové síti  114

Rámec pro působení turbo ekvalizace ����������������������� 117

Případová studie internetové aplikace����������� 135 Aktivizace, motivace a konstruktivismus ������������������� 136 Kategorizace počítačových investičních her a simulátorů ��� 138 Vybrané investiční hry a simulátory ����������������������� 140 Patria Direct - Stock Market Challenge��������������������� 140 Shrnutí ��������������������������������������������������� 154

Literatura�������������������������������������� 156

Trendy a vývoj životního cyklu Radek Šilhavý

1

Webové informační systémy tvoří dnes významnou část používaných firemních aplikací. S webovými informačními systémy je možné se setkat v řadě odvětví. Přímá zaměnitelnost pojmů webová aplikace a internetová aplikace již neplatí. Webové aplikace nebo přesněji webové informační systémy jsou dnes součástí běžné firemní praxe. Setkáváme se tak s nimi v bankovním sektoru, maloobchodu či školství. Vývojový proces a z něj odvozené metodiky pro vývoj softwarových řešení nemusí splňovat nároky, které vývoj webových aplikací na své vývojáře klade. Návrh webových aplikací se od klasického návrhu softwaru liší v některých základních aspektech. Hlavním rozdílem je vyšší citlivost na odvětví, pro které webová aplikace či webový informační systém vzniká. Webové informační systémy lze rozdělit do základních oblastí: Intranetové aplikace. Slouží pro uzavřené prostředí organizace nebo instituce. Webové aplikace. Využívají se pro marketingové účely, řadíme sem obecně webové aplikace, které slouží pro komunikaci mimo rozsah organizace. Elektronické obchodování. Slouží jako prodejní kanál – přímý prodej zboží či služeb. Většinou je stále chápán jako náhrada za objednávkový

systém, doplněk klasických prodejních kanálů. Stále častěji však také jako jediný přímí prodejní kanál. Jak již bylo v  úvodu zmíněno, vývoj webových informačních systémů klade velký důraz na přístup k  vývoji a do jisté míry se od vývoje běžných softwarových aplikací liší. Odlišnosti lze spatřovat v celkovém určení aplikací. S výjimkou intranetových aplikací lze hlavní rozdíl spatřovat v tom, že není přesně známa skupina uživatelů, kteří budou s  webovým informačním systémem pracovat. Další důvody lze spatřovat v  odlišnosti manažerského přístupu. Při vývoj webového informačního systému dochází ke kooperacím mezi více subjekty, i když se může jednat o více oddělení v rámci jedné dodavatelské společnosti. Celkově lze uživatelské prostředí pro webové informační systémy a webové informační systémy charakterizovat jako systémy pro různorodé uživatele. Toto lze posuzovat z pohledu kulturního i geografického. Dále je potřeba počítat s tím, že není dopředu známa úroveň odborných schopností práce s informačními systémy a výpočetní technikou obecně. Vývoj jako takový je závislý a musí být podřízen běhovému prostředí, což je vždy počítačová síť postavená na protokolu http a službách world wide web.

Softwarové procesy a jejich vhodnost Model softwarového procesu [10] lze chápat, jako konceptuálně zjednodušený pohled na vý2 – Vybrané aspekty návrhu webových informačních systémů

voj, který obsahuje jednotlivé fáze vývoje, jejich zjednodušený popis, vzájemné vazby a způsob přechodu z jedné fáze do další fáze. Každá fáze modelu životního cyklu tedy i etapa vývoje umožňuje pohled na systém z daného úhlu pohledu. Softwarové procesy nebo přesněji modelování těchto procesů, je součástí disciplíny zvané softwarové inženýrství již od padesátých let [10] minulého století. Velký rozvoj však nastává po první konferenci nazvané Softwarové inženýrství [10]. V  modelu životního cyklu se obvykle setkáváme s těmito fázemi [39]. Plánování. Jedná se o fázi, kdy se rozhoduje o pořízení nového systému, plánuje se účel, jaké cíle má systém naplnit, případně o náhradu jakého řešení se jedná. Přičemž se může jednat o náhradu dříve používaného software či pouze obyčejné papírové evidence. Analýza požadavků. Analýza požadavků a specifikace. Během této fáze se budou sbírat a rozpracovává co bude systém řešit, jak má být výkonný či jaké zdroje budou potřeba. Dělení a výběr. Požadavky či jiná omezení jsou rozdělena na dílčí podsystémy, které tvoří dílčí části vytvářeného systému. Také probíhá první etapa rozhodování, do jaké míry bude potřeba pracovat na principech přímého zakázkové vývoje nebo do jaké míry je možné použít již dříve vytvořené části nebo je možné použít generická řešení. Návrh architektury. Během této etapy dochází k  návrhu, jak budou dílčí části systému inteTrendy a vývoj životního cyklu – 3

grovány, vytváříme tedy komunikační propojení a definujeme rozhraní. Na základě konkrétního návrhu pak vybíráme, jaký architektonický styl bude pro daný projekt ideální. Rozpracování komponent. Podrobně se věnujeme, jak konkrétně budou dílčí části systému – komponenty pracovat. Určujeme zpracování vstupů z rozhraní na výstup – tedy vstup do další komponenty. Programování, kódování. V této fázi se rozpracované komponenty zapisují ve formě programovacího jazyka, provádí se také základní ověření správné funkcionality. Integrace a testování. Jedná se o skládání systému a provádění testování. Mezi testování patří verifikační testy, kdy se zabýváme ověřením kvality z  pohledu zdrojového kódu a správného návrhu architektury. Provádí se také validační testování, kdy je cílem ověřit, jak a do jaké míry jsou naplněny požadavky vytvořené během analýzy požadavků. Nasazení a instalace. V  rámci této fáze jsou připravovány instrukce k  nasazení systému a také samotné nasazení systému. Provádí se také testování systému po nasazení. Školení a používání. Budoucí uživatelé musí být proškoleni, aby uměli systém řádně používat. Je potřeba se soustředit na možnosti systému, ale i na jeho limity. Údržba. Tato fáze pokrývá zejména dobu užívá4 – Vybrané aspekty návrhu webových informačních systémů

ní. Lze ji časově vymezit od začátku užívání až do konce životnosti. Během této fáze se řeší případné požadavky uživatelů na rozvoj systému nebo odstraňování případných technických nedostatků. Lze říci, že všechny modely životního cyklu softwarového procesu obsahují některé nebo všechny fáze.

Vodopádový model Vodopádový model se obvykle skládá z těchto fází [10]: Analýza požadavků, Návrh, Vývoj – Implementace, Testování, Instalace a Údržba.

Návrh

Implementace

Testování

Instalace

Obr. 1-1:Vodopádový model vývoje software

Vodopádový model patří mezi nejstarší příspěvky ke snaze o systematičnost při vývoji softwarových aplikací. Jeho autorem je Winston W. Royce Trendy a vývoj životního cyklu – 5

a model sám osobě je reakcí na jev zvaný softwarová krize, která je patrná koncem 60. let dvacátého století. Jak je vidět z fází modelu, tak je inspirován potřebami vývoje systémů. Základní stavební prvek modelu je sekvenční vykonávání aktivit a zejména setrvání v dané aktivitě tak dlouho, dokud není z pohledu autora zcela dokončena. Právě odsud plynou nedostatky tohoto přístupu. Je obtížné v  úvodních fázích – tedy při sběru požadavků a návrhu – přesně a dostatečně zpracovat koncepci systému tak, aby nebylo nutné se k  těmto činnostem v  budoucnu vracet. Vodopádový model není schopen provést potřebné změny a proto vede k časově náročnému a tím často i k finančně nákladnému vývoji. Pro vývoj webových informačních systémů se principy vodopádového modelu nehodí také proto, že neuvažují o zpětné vazbě od uživatelů a nepočítají s  možností prototypování systému. Dalším důvodem je potřeba specifikace ve fázi uzavírání kontraktu. Jakákoliv specifikace, která je uvedena přímo ve smlouvě – z pohledu funkčního může být vyžadována jednou nebo druhou smluvní stranou, což vede ke sporům. Ani jedna ze stran totiž není schopna vytvořit specifikaci tak, aby si byla jista, že pokrývá vše potřebné (na jedné straně) a vše je možno vytvořit a dodat (na druhé straně). Z  pohledu vývojového týmu je tento model nevýhodný, protože dochází k malému vytížení členů vývojového týmu. V každé fázi se totiž na řešení podílí pouze ten člen, který je specialistou na danou oblast.

Iterační model Iterační nebo přírůstkový model využívá ze sche6 – Vybrané aspekty návrhu webových informačních systémů

matického pohledu stejné fáze jako model vodopádový. Vše však probíhá cyklech – iteracích (přírůstcích). Mezi hlavní výhody patří výrazně kratší doba jednotlivých fází a tím je možné vydávat jednotlivá sestavení software k  validaci uživateli velmi často. Základní princip / citace/ tedy spočívá v  tom, že v  úvodních fázích vývoje – časového pohledu – existuje jen obecná dokumentace požadavků na vyšší úrovni bez podrobného rozpracování. Podrobnosti se doplňující během běhu vývoje v  rámci dalších a dalších přírůstků. Směr a celkový rozsah je tak uživatelem ovlivňován průběžně.

Spirálový model Zatímco předchozí dva modely patří mezi operační modely, tedy na vývoj se pohlíží jako na sekvenci činností. Spirálový model patří mezi neoperační modely. Model je založený na identifikaci rizik [10]. Riziky zde rozumíme vše co může mít negativní vliv na vyvíjený systém. Vyhodnocení

Plánování Obr. 1-2: Spirálový model vývoje software Trendy a vývoj životního cyklu – 7

Spirálový model byl původně navržen Boehem. Každá otáčka spirály znamená průběh jedné fáze vývoje daného softwarového produktu. Jedna otočka se zabývá proveditelností, druhá požadavky a podobně. V základu se spirála dělí na čtyři základní fáze [10]. V  první etapě se provede nastavení procesu, jsou nalezeny omezení pro proces či produkt. Provádí se zde také plánování nebo úprava plánu a identifikují se již zmíněná rizika. Druhá fáze se zabývá řešením nalezených rizik. Cílem je minimalizovat dopad každého nalezeného rizika na daný projekt. Například může být rozhodnuto, že pro lepší analýzu požadavků bude vyvinut prototyp systému. Ve třetí fázi se vybírá volba vhodné metodiky pro vývoj. Volba obecně záleží na účelu a typu vyvíjeného systému. Pro některé systémy je vhodný evoluční prototypový vývoj (tam, kde je důležité uživatelské rozhraní). Metodiky založené na vodopádu jsou pak vhodnější tam, kde je potřeba pracovat s dělením na subsystémy, které se pak mají integrovat. Modelů softwarových procesů vzniklo a dále vniká velké množství. Tyto tři patří dnes mezi ty nejčastěji využívané. V  českých podmínkách stále převažuje tendence využívat principy vodopádového modelu. Tento fakt vychází ze subjektivního hodnocení a není dosud podložen objektivním empirickým výzkumem, který by situaci objasnil. I když, jak bylo naznačeno, tak stále existují projekty, pro které je vodopádový 8 – Vybrané aspekty návrhu webových informačních systémů

přístup potřebný. Pro klasický vývoj webového informačního systému však příliš výhodný není. Proces vývoje webových informačních systémů je specifický svým založením. Lze na něj uplatnit základní pravidla práce známá z  uvedených generických modelů. Platí však, že vzhledem ke specifičnosti webového prostředí je potřeba základní přístupy modifikovat.

Proces vývoje Softwarový proces webových informačních systémů musí reflektovat specifika webových aplikací. Nyní se pokusíme navrhnout základní metodický rámec pro vývoj. Navržený přístup je založen na evolučním vývoji a vodopádovém přístupu. Základní fáze lze rozdělit do čtyř stupňů vodopádu: • Koncepce a strategie • Struktura a design • Kódování a vývoj • Testování a spuštění • Optimalizace a údržba Každý z těchto čtyř stupňů je pak dále rozpracováván pomocí principu evolučního vývoje. Základní použití vodopádu bylo zvoleno, protože přináší potřebnou posloupnost ve vývoji. Při vývoji webového informačního systému pracujeme ve dvou základních etapách – první je vývoj grafického uživatelského rozhraní a následně pak probíhá implementace daného uživatelského rozhraní. Když se na základní stupně podíváme podrobněji nacházíme tyto základní činnosti, které si nyní popíšeme.

Trendy a vývoj životního cyklu – 9

Koncepce a strategie Jedná se tedy o podrobné seznámení se s  řešeným systémem, sběrem a analýzou požadavků. U webových informačních systému se více soustředíme na modelové scénáře, které chápeme jako základní popis činnosti příslušného uživatele. V této fázi také stanovíme předpokládané uživatele. Vytváříme tzv. Osoby, které představují prototyp našeho uživatele, respektive více uživatelů. Stanovení osob je často výsledkem analýzy rolí a dostupných informací z marketingové strategie. Jako Osoba se označuje charakteristika uživatele, která v  sobě obsahuje soubor jeho vlastností – tedy sociální charakteristiky, typické nákupní chování a znalostní charakteristiky. Posledním bodem se rozumí schopnost dané Osoby pracovat s určitou technologií.

Struktura a design Návrh organizační struktury systému, tvorba prototypu uživatelského rozhraní a vytvoření uživatelského rozhraní. U webových informačních systémů je jednou z klíčových fází. Návrh struktury úzce navazuje na navržené Osoby a zejména na modelové scénáře. Hlavním cílem je navrhnout potřebou strukturu systému, což spočívá zejména v návrhu dat, které bude daný systém poskytovat nebo sbírat. Součástí struktury je tak i návrh obsahu, a to možná co nejvíce konkrétně. Právě zde je výrazný rozdíl mezi návrhem webových a klasických aplikací. Webové informační systémy či webové aplikace jsou vždy stavěny na daná data. Pokud je navržena struktura, tak se pokračuje návrhem designu. Designem zde rozumíme návrh uživatelského rozhraní a lze říci, že právě návrh uživatelského 10 – Vybrané aspekty návrhu webových informačních systémů

rozhraní tvoří významnou součást návrhu aplikace. Při návrhu uživatelského rozhraní se velmi využívají různé prototypy. Prototypování je velmi důležitá činnost při celém návrhu designu. Zpravidla se začíná drátěným modelem, který obsahuje pouze základní kompoziční řešení každé z  obrazovek. Jako obrazovka se označuje každá stránka, která je součástí modelového scénáře. Pomocí evolučního přístupu se pak modely rozvíjí a návrh uživatelského rozhraní zpřesňuje až do finální podoby.

Kódování a vývoj Do stupně kódování a vývoje vstupuje již finální podoba struktury aplikace a designu. Tento přístup vede k  tomu, že se v této fázi pouze implementují definované a validované modelové scénáře, kdy každý krok je již popsán v podobě prototypu uživatelského rozhraní.

Testování a spuštění V  rámci tohoto stupně se provádí uživatelské testování, testování struktury a kontinuity navigace, testování použitelnosti a akceptační testování. Testování – uživatelské testování je také součástí stupně Struktura a design, protože prototyp uživatelského rozhraní je testován uživateli.

Optimalizace a údržba Webové informační systémy či spíše webové aplikace jsou stavěny pro dopředu neznámý počet uživatelů. Proto je údržba velmi podstatnou částí. Mezi údržbu řadíme snahu o stálé zdokonalení systému, řešení nových uživatelských požadavků a řešení defektů. Mezi údržbu dále Trendy a vývoj životního cyklu – 11

řadíme i správu datového obsahu, což je také novým příspěvkem vývojového procesu. U běžných softwarových systémů tento aspekt odpadá.

Shrnutí vývojového procesu Vývoj webových informačních systémů musí být orientován na data a uživatelské rozhraní. Právě tento fakt celý proces výrazně odlišuje. Proto se u vývoje webových informačních systémů s  úspěchem uplatňuje popsaná metodika, která je založena na vodopádovém modelu, kde se však v rámci každého stupně vodopádu uplatňují přístupy evolučního vývoje. Tento přístup je také nutný, protože na vývoji webového informačního systému se uplatňuje dělení na subsystémy, které jsou vyvíjeny samostatnými dodavateli. Zejména ve fázích než je dokončeno uživatelské rozhraní se uplatňuje prototypování, které přispívá k dokonalém pochopení požadavků i koncepce systému jako takového.

12 – Vybrané aspekty návrhu webových informačních systémů

Specifikace a analýza požadavků při návrhu Petr Šilhavý

2

Každý softwarový projekt začíná tím, že vzniká potřeba či cíl, který má být vyřešen. Stále se setkáváme s  tím, že tyto potřeby jsou popsány velmi nejasně bez potřebné úrovně podrobnosti. Softwarové firmy – některé – stále věnují nedostatečný prostor úvodním fázím projektu či úvodním fázím projektových přírůstků. Tyto nedostatky pak vedou k tomu, že programátoři jsou nuceni o podobě a způsobech řešení rozhodovat přímo při psaní kódu. Je také pravdou, že mnohým tvůrcům kódu není tento způsob proti mysli. Toto tvrzení není podloženo žádným seriózním výzkumem, avšak vychází z  pozorování a zkušeností s českou komunitou programátorskou. Nabízí se paralela se stavebnictvím. Když se staví dům, také není úkolem zedníků rozhodovat o tom, jak vysoký dům bude, z jakého materiálu, kolik bude mít oken, jakou izolaci a podobně. Vývoj webového informačního systému samozřejmě není činnost sofistikovaná, tak jako stavebnictví, avšak aplikace vhodné úrovně systematičnosti nebo přesněji inženýrského přístupu je více než vhodná. Potřeba přesné analýzy a dokumentace není vždy stejná. Záleží na významnosti daného informačního systému a pak také na jeho zařazení z  pohledu tzv. kritičnosti aplikace. Jiné nároky je potřeba mít na běžný vnitrofiremní informační systém, jiné pak na systém elektronického bankovnictví.

Základním pojmem, kterým se budeme v této kapitole zabývat je požadavek, případně inženýrství požadavků. V této souvislosti se také často hovoří o specifikaci. Sběr požadavků neboli specifikace systému je podle celé řady autorů jednou z  hlavních fází, která se nejvíce podílí na selhání systémů nebo vzniku, již v úvodu zmíněných, potíží při dokončování projektů. Je potřeba však chápat, že dokumentace požadavků je vždy jen tak dobrá, jak dobrý – tedy zkušený, je její autor či autoři. Ještě lépe lze danou problematiku vystihnout tak, že dokumentace požadavků je dobrá tak, jak úspěšně ji lze pro návrh a následné programování daného informačního systému využít. Dobrá specifikace tedy bude popisovat funkcionalitu budoucího systému, která je zadavateli požadována. Návrhářům systému odpoví na otázky, které si budou klást při návrhu koncepce a architektury. Měla by také být základním časovým rozvrhem pro plánování jednotlivých iterací, pokud je pro vývoj využívána metodika na přírůstcích založená. Bylo však chybou vykládat specifikaci jako dogmatický dokument. Specifikace nemá za úkol potírat názory v týmu. Dobrá specifikace má také podporovat přemýšlivost v  týmu a snahu o návrh co nejvhodnějšího řešení. S tím souvisí také organizační struktura týmu, na specifikaci se má podílet celý budoucí tým, protože specifikace či lépe řečeno všechny úvodní fáze návrhu jsou založeny na diskusi se zadavateli nebo členy týmu. Analytik, který 14 – Vybrané aspekty návrhu webových informačních systémů

považuje specifikaci za jedinou danou věc, která vzniká proto, aby šířila jen jeden názor a přístup k  řešení je odsouzen k  zániku a jeho projekt k neúspěchu.

Co má specifikace obsahovat Softwarové inženýrství rozeznává celou řadu metodických přístupů. Jeden z  možných přístupů k návrhu byl navržen i v této knize, avšak to podstatné pro účely této kapitoly lze spatřovat v  tom, že každá z  metodik stanovuje svá individuální pravidla na to, co má být obsahem specifikace. V dobré specifikaci by vždy měly být zastoupeny následující části. Jejich kombinace je pak právě charakteristickým znakem pro každou z vývojových metodik.

Požadavky Požadavky je možné popsat jako popis funkce budoucího systému nebo podmínku jeho fungování, přičemž obě tyto entity jsou definovány zadavateli. Na požadavky je možné pohlížet z několika pohledů. Na sesbírané požadavky pohlížíme jako na tzv. hrubé požadavky [39]. O hrubých požadavcích hovoříme proto, že se jedná o požadavky dosud nijak nezpracované. Jejich cílem často bývá stanovení uživatelských cílů, které mají být dosaženy. Následnou analýzou požadavků se pak stanovuje jak dané cíle dosáhnout. Druhou skupinou jsou nefunkční požadavky. Jako nefunkční požadavky jsou charakterizovány všechny, které nepopisují přímo budoucí systém, ale lze je chápat tak, že jejich cílem je seznámit vývojový tým se situací v  problémové doméně a podmínkami, které se v rámci domény uplatňují. Specifikace a analýza požadavků při návrhu – 15

Patří sem požadavky na spolehlivost, výkonnost, bezpečnost nebo zabezpečení. Další skupinou jsou systémové charakteristiky. Zde se jedná o popis nežádoucí funkce systému. Tedy chování, které žadatelé nepožadují a nesmí k němu dojít. Toto je velmi dobrá metoda, jak popsat chování informačního systému. Při vývoji se lze totiž často mnohem rychleji dopátrat chování informačního systému, které žadatelé odmítají. Bývá na něm mnohem lepší shoda. Poslední skupinou, která se zpravidla vyčleňuje jsou požadavky na omezení. Lze říci, že úzce souvisí s charakteristikami. Omezení musí být platné, ať je zvolené řešení jakékoliv. O všech požadavcích musí platit, že jsou atomické, tedy dále nedělitelné. Toto je zárukou jednotného výkladu a popisuje jeden konkrétní aspekt specifikovaného systému.

Jaké metody sběru lze využít Pro sběr požadavků existuje celá řada metod. Nyní se podíváme na vybrané metody, které jsou pro sběr požadavků nejpoužívanější. Tyto lze najít v celé řadě metodik a lze říci, že se také často používají zcela intuitivně. Tyto metody často vycházejí z jiných oborů a oblastí a pro účely zpracování požadavků byly upraveny [40]. Rozhovor. Velmi častý způsob sběru a také velmi intuitivní. Používá se často ve všech oblastech softwarového nebo systémového inženýrství [10,40]. Rozhovor, neboli interview, je původně metoda práce adoptovaná ze sociálních věd, kde 16 – Vybrané aspekty návrhu webových informačních systémů

je to jeden z  hlavních způsobů sběru dat pro výzkum. Přes svou běžnost není rozhovor metodou jednoduchou. Rozhovor lze používat ve třech základních typech. Existuje rozhovor polo-strukturovaný, plně-strukturovaný a nestrukturovaný. Pro účely analýzy požadavků se jeví jako nejvíce užitečný rozhovor polo-strukturovaný. Toto je dáno tím, že rozhovor by měl být spíše diskusí. Od analytika se očekává schopnost vést rozhovor konstruktivně k danému cíli, avšak na druhé straně není vhodné příliš zadavatele omezovat úzkým rozsahem otázek. V  případě plně-strukturovaného rozhovoru se velmi jednoduše může stát, že dojde k opomenutí důležitého požadavku jen proto, že otázka nebyla formulována v dostatečné šíři. Dalším důvodem proč je vhodné se vyhnout plně-strukturovanému rozhovoru je snaha nevynechat skupinu otázek. Tyto otázky respektive jejich témata se analytikovi mohou jevit jako nepodstatné či dokonce s problémovou doménou nesouvisející. Braintorming. Metody brainstormingu jsou velmi vhodným prostředkem pro sběr požadavků. Často se využívají jako doplnění rozhovoru a to zejména v jeho polo-strukturované variantě [40]. Výhodou brainstormingu při sběru požadavků je možnost vzájemné diskuse zadavatelů a z ní plynoucí možnosti zaznamenat vzájemné podněty diskuse zadavatelů. Právě tento typ debaty je pro pochopení podstaty řešeného problému významný. Laddering. Najít plně odpovídající české pojmenování této techniky není snadné, avšak lze jej vykládat jako stupňovou technikou. Principem této techniky rozhovoru [40] je vytvářet určiSpecifikace a analýza požadavků při návrhu – 17

tou hierarchickou strukturu odpovědí, které na sebe vzájemně navazují a dochází tak k postupnému zpřesňování respektive objevování stále nových informací. Nejdříve se tedy otázky formulují obecněji, kdy je snahou získat přehled o celkových výstupních vlastnostech webové aplikace. Na základě těchto informací je v další debatě snaha o podchycení vzájemných souvislostí. Otázky se pak formulují tak, abychom dokázali více rozpracovat každou ze zjištěných základních vlastností. Zde mají velmi důležitou roli klíčová slova proč a proč právě takto. Těmito otázkami, které míří do hloubky problémové domény dochází k  zachycení řešené aplikace na všech úrovních abstrakce. Od celkového konceptu až do podrobností. Dotazníky. Dotazníky jsou považovány za nejvýznamnější metodu neosobní komunikace. Lze říci, že je vhodné je využívat v  přípravné fázi na některou z osobních metod sběru požadavků. Dotazník však nelze využít jako jediný zdroj informací. Selhává totiž v rozkrývání nových oblastí problémové domény navrhovaného systému. Také příprava dotazníku, aby poskytl alespoň informace pro přípravu brainstormingu nebo rozhovoru není snadná. Měl by ji vždy vykonávat analytik, který je zkušeným odborníkem na danou problémovou doménu. Analýza cílů a úkolů. Tato aktivita je založena dekompozici úkolů [41], kdy se provádí dekompozice dle úrovní abstrakce návrhovou metodou shora-dolů. Tím dochází k  nalezení všech potřebných požadavků. Jedná se přitom o uživatelské i systémové požadavky. Výsledné požadavky 18 – Vybrané aspekty návrhu webových informačních systémů

se zaznamenávají formou uživatelských nebo systémových scénářů, platí přitom, že každý požadavek může být reprezentován více jak jedním scénářem. Pozorování. Pozorování jako metoda sběru požadavků vychází z etnografie a jiných sociologických disciplín. V oblasti softwarového inženýrství se používá pro pozorování uživatelů, kteří plní své úkoly v  dané problémové doméně. Tato metoda se nejvíce využívá při návrhu uživatelsky orientovaných systémů a v případě webových aplikací je vhodná její kombinace s prototypováním. Pozorování vykazuje různé výsledky, pokud uživatel ví, že je pozorován a v případech, kdy neví, že je pozorován. Uživatelé vykazují jistou tendenci ke změně chování v případě, že je jejím známo, že jsou součástí pozorování. Prototypování. Prototypování je považováno za metodu sběru požadavků a právě u webových aplikací je jeho účel velmi podstatný. Jeho význam je však potřeba spatřovat v  dalších iteracích sběru požadavků, kdy je nutné požadavky nejen sbírat do větších podrobností, ale také ověřovat správnost pochopení dříve získaných požadavků.

Průběh sběru požadavků Sběr požadavků je komplexní proces, které lze popsat osmi základními fázemi: 1. Analýza aplikační domény. 2. Identifikace klíčových zadavatelů. 3. Vypracování uživatelských scénářů a systémových scénářů. 4. Realizace prototypu. Specifikace a analýza požadavků při návrhu – 19

5. Nalezení funkčních požadavků. 6. Nalezení nefunkčních požadavků. 7. Identifikace omezení pro každý z požadavků. 8. Klastrování požadavků. Analýza aplikační domény je důležitá fáze. Během této fáze dochází k  seznámení s  aplikační doménou. Další krok pak vede k  tomu, aby bylo možné najít všechny klíčové zástupce uživatelů webové aplikace, kteří budou mít klíčovou roli při sběru požadavků. Další krok spočívá v  sestavení scénářů, které popíší předpokládané činnosti, které budou uživatelé v navrhované aplikaci provádět. Tyto základní scénáře jsou přepracovány do podoby prototypu. Tento prototyp je velmi vhodným nástrojem pro sběr požadavků. Prototyp lze využívat pro nalezení všech základních požadavků, včetně identifikace omezení. Předpokladem je využití brainstormingu a s postupným směřováním od požadavků vyšší úrovně směrem k těm dále nedělitelným. Konečnou fázi inženýrství požadavků je klasterizace požadavků, která tvoří základ budoucí dekompozice systému na komponenty, respektive moduly.

20 – Vybrané aspekty návrhu webových informačních systémů

Datové modelování a návrh databáze Zdenka Prokopová

3

Po dokončení fáze analýzy, sběru a dokumentace požadavků na nový databázový systém jsme připravení k dalšímu kroku a tím je modelování a návrh databáze. Cílem datového modelování je navrhnout kvalitní datovou strukturu pro konkrétní aplikaci a databázový systém, který bude tato aplikace využívat k uložení dat. Jde vlastně o formalizaci a dokumentaci stávajících procesů a událostí, které se vyskytují při návrhu aplikačního softwaru. Datové modelování v softwarovém inženýrství je tedy proces vytvoření datového modelu informačního systému, za použití formálních modelovacích technik. Proces modelování dat zahrnuje na jedné straně profesionální datové modeláře úzce spolupracující s podnikatelskými subjekty a na straně druhé potenciální uživatele informačního systému. Modelování dat a návrh databáze jsou dvě odlišné činnosti. Jedním ze způsobů jak tyto dvě činnosti odlišit je položení otázky, na kterou hledáme odpověď: 1. U modelování dat zní otázka, na kterou se ptáme: Jak vypadá „svět“ který modelujeme? Hledáme zejména podobnosti mezi věcmi. Určíme si hlavní „typ” věci, která může mít podtypy – např. Právnické osoby

a Fyzické osoby. Pokud jsou dodavatelské kontakty koncepčně odlišné od zákaznických kontaktů, pak by měly být modelovány odděleně. Na druhou stranu, pokud jsou to pouze dílčí odlišnosti stejné věci, pak by se s nimi mnělo zacházet jako se stejnou věcí. 2. U návrhu databáze odpovídáme na otázku: Jak efektivně vytvořit databázi, která bude podporovat funkci navrhované aplikace nebo webové stránky? Hlavním úkolem je nalézt podobnosti mezi entitami (subjekty) tak, aby je bylo možné integrovat do jedné tabulky. Například tabulka Zákazník kombinuje všechny atributy právnických i fyzických osob zákazníků. Dá se říci, že datový model je pouze jednou částí celkového procesu návrhu databáze.

Proces návrhu databáze Pojem “návrh databáze” může popisovat mnoho různých částí návrhu celkového databázového systému. Principiálně je ho možné chápat jako logický návrh struktury základních údajů používaných pro ukládání dat. Návrh databáze však můžeme také použít pro označení celého procesu projektování, a to nejen základní datové struktury, ale i formulářů a dotazů používaných jako součást celkové databázové aplikace v komplexním systému pro správu databází. Správný návrh databáze může následně ušetřit čas při její tvorbě a také zajistit její dobrou funkčnost a spolehlivost.

22 – Vybrané aspekty návrhu webových informačních systémů

Proces návrhu databáze se skládá z fází a kroků, které vedou tvůrce (návrháře) správnými technikami používanými při plánování, správě a kontrole, co vede k vytvoření funkčního projektu. Jedna z nejčastěji používaných metodologií rozděluje návrh databáze do tří základních fází: • Konceptuální návrh databáze • Logický návrh databáze • Fyzický návrh databáze V první fázi tj. konceptuálním návrhu je vytvářen konceptuální model dat bez uvažování podrobností o datech. Ve druhé fázi, logickém návrhu, se převádí (mapuje) konceptuální model do množiny relačních tabulek. Tabulky jsou kontrolované na redundanci (pomocí normalizace) a schopnost podporovat transakce. Ve třetí fázi, fyzickém návrhu, se rozhoduje, jak se bude fyzicky implementovat logický návrh databáze. V dalších kapitolách se fázemi návrhu databáze resp. odpovídajícími datovými modely budeme zabývat podrobněji. Datové modely Jedním z největších problémů při navrhování databáze je skutečnost, že aktivní účastníci tohoto procesu tj. návrháři, vývojáři, programátoři a koncoví uživatelé vidí stejná data rozdílným způsobem. Aby byla jistota, že všichni přesně rozumí povaze dat a jejich používání, je pro komunikaci všech účastníků procesu návrhu databáze nutný model databáze. Z předem uvedených fází návrhu databáze plyne existence odpovídajících modelů: 1. Konceptuální datový model specifikuje poDatové modelování a návrh databáze – 23

žadavky na údaje. Jde v podstatě o sadu specifikací technologií nezávislých na datech. 2. Logický datový model navazuje na konceptuální datový model. Dokumentuje strukturu dat, která mohou být realizována v databázích. Provedení jednoho konceptuálního datového modelu může vyžadovat více logických datových modelů. 3. Fyzický datový model je datový model, který organizuje data do tabulek, určuje přístup, výkon a ukládání informací dle zvoleného systému řízení báze dat. Návrh databáze dokumentovaný pomocí těchto tří modelů pak může být použitý ke generování databáze pomocí jazyka DDL (Data Definition Language). Tvorba datových modelů tj. datové modelování definuje nejen datové prvky, ale i jejich struktury a vztahy mezi nimi. Pro všechny projekty, které vyžadují standardní způsob definování a analyzování dat, se důrazně doporučuje používání standardních modelovacích technik. Použití datového modelování se doporučuje např. v případech: • Tvorby databází / datových skladů • Spravování dat jako zdroje • Integrace informačních systémů Tvůrci datových modelů často používají více modelů pro zobrazení stejných dat z důvodu zajištění, že všechny procesy, osoby, vztahy a toky dat byly rozpoznány. Pro programátora a vývojáře aplikací je velmi důležité chápání základních prvků modelování dat, tak aby mohl nejen 24 – Vybrané aspekty návrhu webových informačních systémů

číst datové modely, ale také efektivně spolupracovat s administrátory, kteří jsou odpovědní za datově orientované aspekty projektu. Metodologie datového modelování I když existuje mnoho způsobů, jak vytvářet datové modely, podle [22], vynikají pouze dvě metody modelování: 1. Zdola nahoru – modely, které obvykle začínají z existujících formulářů, datových struktur, polí na obrazovkách aplikace nebo zpráv. Tyto modely jsou obvykle fyzikální, specifické pro danou aplikaci a neúplné z pohledu podniku. Nepodporují sdílení dat, zejména pokud jsou vytvořeny bez odkazů na jiné částí organizace. 2. Shora dolů – jde většinou o logické datové modely, které jsou vytvořeny abstraktním způsobem získávání informací od lidí, kteří znají danou oblast modelování. Systém nemůže specifikovat všechny subjekty v logickém modelu, model slouží jako referenční bod nebo šablona. Tato metoda je využívána i u konceptuálního modelování. Někdy se modely vytvářejí kombinací obou metod. Bohužel, v mnoha prostředích je rozdíl mezi logickým datovým modelem a fyzickým datovým modelem nejasný. Navíc, některé CASE systémy nedělají rozdíl mezi logickými a fyzickými datovými modely, co je často na škodu věci.

Datové modelování a návrh databáze – 25

Konceptuální datový model Konceptuální datový model může být chápán jako schéma nebo diagram, který znázorňuje vztahy mezi daty. Ačkoli zachytit všechny možné vztahy v datovém modelu může být časově velmi náročné, je to důležitý krok a neměl by být uspěchán. Dobře zdokumentované modely umožňují zúčastněným stranám identifikovat chyby a uskutečnit případné změny před každým napsáním programového kódu. Aktuálně používaný model je často nazýván “Entitně relační model“ (ERM), protože zobrazuje data z hlediska entit (subjektů) a vztahů mezi entitami (relacemi). Z toho plyne, že Entitně relační modelování je metoda používaná v softwarovém inženýrství k tvorbě konceptuálních datových modelů. ERM se používají v první fázi návrhu informačního systému, tj. v průběhu analýzy požadavků na informační systém nebo typu informací, které mají být v databázi uloženy. ERM je tedy možno chápat jako abstraktní konceptuální reprezentaci strukturovaných dat. Notace datového modelování Pro účely modelování dat pomocí ERM existuje několik různých způsobů zápisu datových záznamů, kterým se říká notace. Na Obr. 3-1 můžeme vidět syntaxi tří různých notací: Informační inženýrství, Barkerova notace a notace Unified Modeling Language (UML). Toto schéma není samozřejmě komplexní, jeho cílem je pouze poskytnout čitateli základní přehled a ukázky notací.

26 – Vybrané aspekty návrhu webových informačních systémů

Obr. 3-1: Vybrané typy notací datového modelování

 

UML je standardní notace pro modelování objektů reálného světa. Je následovníkem mnoha metod oběktově orientované analýzy a standardním modelovacím jazykem. Pro návrh datové struktury, která reprezentuje informace zpracovávané a prezentované v internetové aplikaci se často používá datový model WebML. Jedná se o konceptuální model, který je podobný ER diagramům, které se používají pro návrh struktury relačních databází nebo UML diagramům používaných v objektové analýze a návrhu. Datové modelování a návrh databáze – 27

CASE systémy CASE (Computer Aided Software Engineering) systémy jsou nástroje pro podporu analýzy a návrhu databázových systémů. Dnes je již zřejmé, že při návrhu rozsáhlejších informačních systémů se bez použití těchto nástrojů neobejdeme. Mezi známé a často používané CASE systémy patří naříklad: • CaseStudio • Oracle Designer • Power Designer • XTG Data Modeller CASE systém je profesionální software pro vizuální navrhování databázových struktur. Klíčové vlastnosti tohoto produktu zahrnují: • E R diagramy (Entity Relationship Diagrams) • P odporu pro různé databáze enerování SQL skriptů • G pětné načtení struktury (reverse engi• Z neering) • G enerování detailní HTML dokumentace enerování detailní RTF dokumentace • G xport do XML formátu • E Pro ukázku a porovnání uvádíme v tabulce Tab. 3-1. několik vybraných nástrojů pro datové modelování.

Tvorba konceptuálního datového modelu Tvorba Entitně relačního modelu má přesně stanovený postup. Obecně se nejdříve určí důležitá data (entity) a vztahy (relace mezi daty), kte28 – Vybrané aspekty návrhu webových informačních systémů

Tab. 3-1: Vybrané nástroje pro datové modeování

Produkt

Prodejce

Cena

Komentář

Argo UML

Tgris

Zdarma

Open Source vhodný pro modeování UML diagramů

Case Studio 2

CharonWare

Trial Zdarma

Podporuje velké množství DBS Firebird, MaDB, Postgress

Concept Draw

CS Odessa

Zdarma

Pro ERD, UML, ORM

DBDesigner 4

FabForce. net

Zdarma

Open-Source doporučeno pro MySQL

Dezign

Datamic

Zdarma

Podprouje 20 odlišných platforem

Dia

Sourceforge

Zdarma

Nástroj pro tvorbu diagramů

Google WWW SQL Designer

Ondrej Zara

Zdarma

Open-Source

mySQL Workench

mySQL

Zdarma

Vhodný pro mySQL

Open ModelSphere

Model Sphere

Zdarma

Vhodný pro UML

Oracle SQL Developer Data Modeler

Oracle

Zdarma

SQL

RevJ

Sourceforge

Zdarma

Open-Source

SQL Developer Diagram Editor

--

Zdarma

Nevhodný pro Oracle

Squirrel

Squirrel

Zdarma

Open-Source

Umbrello

Sourceforge

Zdarma

Open-Source, vhodný pro UML

Datové modelování a návrh databáze – 29

Produkt

Prodejce

Cena

Visio

Microsoft

PlaceCena závisí na ný, Trial verzi Zdarma

Komentář

XCase

Resolution Software

PlaceKompletní náný, Trial stroj pro návrh a Zdarma údržbu databází obsahující archivaci a porovnání modelů

ré je potřeba reprezentovat. Následně se postupuje k detailům, které je potřeba ohledně entit a relací zaznamenat. Konkrétněji lze postup popsat následujícími kroky (je potřeba ale zmínit, že postup se může mírně lišit v závislosti na použitém CASE systému): 1. Zvolíme jednu primární entitu ze specifikace požadavků. 2. Určíme atributy, jejichž hodnoty se mají pro tuto entitu zaznamenávat a označíme případné klíče (identifikátory). 3. Popíšeme slovně navrženou entitu, její atributy a klíče. 4. Prověříme funkční vztahy (závislosti) atributů a v případě potřeby entitu normalizujeme. 5. Prověříme atributy navržené entity (pokud možno ve spolupráci s uživatelem) a zjistíme, zda je třeba zaznamenávat informace o jednom či více atributech v nové samostatné entitě. 6. Je-li vhodné vytvořit další entitu, zaneseme ji do diagramu a vrátíme se na 30 – Vybrané aspekty návrhu webových informačních systémů

krok 2. 7. Spojíme entity vztahy, pokud existují a popište slovně vztahy mezi entitami z obou stran. 8. Prověříme seznam atributů a určíme, zda některé z nich potřebují být identifikovány prostřednictvím dvou (či více) entit. Pokud ano, umístíme atribut na příslušný vztah, který spojuje dané entity. 9. Prověříme, zda v diagramu nemáme „smyčky“, které mohou indikovat nadbytečné (odvozené) vztahy. Pokud je vztah skutečně redundantní, odstraníme ho. 10. Předvedeme navržený model (diagram i slovní popis) uživateli. Pokud je to třeba, upřesníme diagram. Základní koncepty ERM jsou entity, atributy a relace. Identifikace entity Entita reprezentuje libovolný existující objekt reálného světa (osoba, věc, jev). Jednotlivý výskyt entity se označuje jako instance entity. Ukázkovou entitou je například entita “Zákazník” s instancemi entity například “František Dobrota”, “Josef Novák” a další. Entita musí být odlišitelná od ostatních entit. Každá entita je charakterizovaná svým názvem a seznamem atributů. Atribut je vlastnost entity (údaj o objektu). Například entita Zákazník bude mít pravděpodobně atributy (jméno, příjmení, ulice, město, PSČ, email, telefon a další). Grafické zobrazení entity se může odlišovat dle použité notace. V některých případech bývá zobrazena jako obdélník s označením jména entity Datové modelování a návrh databáze – 31

(obvykle se používá podstatné jméno v jednotném čísle) nebo je entita zobrazená pomocí obdélníku, do kterého jsou vepsané název a atributy entity. Na Obr. 3-2 jsou zobrazené ukázkové grafické notace entity.

Obr. 3-2: Ukázkové zobrazení entity zákazník

Většina používaných CASE systémů umožňuje sestavovat ERM pomocí hierarchie entit. Znamená to, že nadřazená entita může mít své podřazené entity. Pro takové entity platí, že podřazená entita představuje speciální případ nadřazené entity, dědí od ní všechny vlastnosti (atributy) a také k nim můžou být přidané její vlastní-specifické atributy. Hierarchie entit se může vyskytovat ve více úrovních. Používání hierarchie entit je známé pod označením I-SA hierarchie (viz Obr. 3-3). Identifikace atributů Každá definovaná entita musí mít jeden nebo více datových atributů. Při modelování se můžeme setkat s několika typy atributů: 32 – Vybrané aspekty návrhu webových informačních systémů

Obr. 3-3: Ukázkový příklad I-SA hierarchie

• Jednoduchý atribut – skládá se z jedné komponenty • Složený (strukturovaný) atribut – skládá se z více komponent (např. složený atribut adresa by obsahoval složky ulice, město, PSČ) • Atribut s jednou hodnotou – obsahuje jednu hodnotu na výskyt entity • Atribut s více hodnotami – obsahuje více hodnot na výskyt entity (např. atribut telefon by obsahoval hodnoty číslo1, číslo2…) • Odvozený atribut – obsahuje hodnotu, kterou lze odvodit z jiného atributu. Každý z definovaných atributů entity bude mít následně přiřazen datový typ. Základní datové typy jsou: • Řetězec znaků (String, Char, Text…) • Číslo (Int, Float, Real, Decimal…) Datové modelování a návrh databáze – 33

• Datum a čas (Date, Time…) • Logická hodnota (True/False, 1/0…)

Ano/Ne,

Jsou-li datové typy navrhovány v ERM, pak jsou používány tak, aby nebyly přímo závislé na konkrétním systému řízení báze dat, ve kterém se databázový systém bude tvořit. Přiřazení klíčů Klíče se entitám přiřazují z důvodu jednoznačné identifikace jednotlivých výskytů entity tj. identifikace každé instance entity. Při datovém modelování můžou být definované různé klíče: • Super klíč – atribut nebo množina atributů, která jednoznačně identifikuje každý výskyt entity • Kandidátní klíč – super klíč, který obsahuje minimální počet atributů potřebných k jednoznačné identifikaci výskytu entity • Primární klíč – kandidátní klíč, který zvolíme pro jednoznačnou identifikaci entity • Alternativní klíč – kandidátní klíč, který nebyl zvolen jako primární klíč. Existují dvě základní strategie pro přiřazování klíčů. V první řadě jde o přiřazení přirozeného klíče, kterým je jeden atribut nebo seznam více existujících atributů, které jsou unikátní a tudíž se hodí pro jednoznačnou identifikaci. U entity Zákazník zobrazené na obrázku Obr. 3-2 by mohlo jít o kombinaci více atributů např. jméno, příjmení, ulice, město. Ve druhém případě je možno entitě přiřadit náhradní klíč, což je klíč, který se používá v případě, že v entitě neexistuje žádný přirozený primární klíč, 34 – Vybrané aspekty návrhu webových informačních systémů

Obr. 3-4: Ukázka přiřazení primárního klíče

nebo je takový primární klíč příliš složitý. Příkladem přirozeného primárního klíče v entitě Zákazník by mohlo být např. rodné číslo (pokud by zákazníkem mohla být pouze osoba) nebo IČ. Náhradním klíčem by mohlo být např. pořadové číslo. Identifikace vztahů V reálném světě mají subjekty vztahy s ostatními subjekty. V ERM se definují vazby mezi entitami, které vlastně představují logické vztahy mezi entitami. V datových modelech je možné definovat pouze vazby mezi dvěma entitami (tzv. binární vazby). Multiplicita binární vazby je daná kardinalitou vztahu a ta může nabývat hodnot: • 1 : 1 - každé entitě odpovídá maximálně jedna druhá entita • 1 : N - první entitě odpovídá více než jedna druhá entita, druhé entitě odpovídá maximálně jedna první entita • M : N - první entitě odpovídá více než jedna druhá entita, druhé entitě odpovídá více než jedna první entita Každou takovou vazbu je možné chápat jako „dvě vazby v opačném směru“. Jde o tzv. role, které představují pohled na danou vazbu od jedné entity ke druhé a obráceně. Například na vazbu mezi Datové modelování a návrh databáze – 35

entitou Zákazník a Objednávka můžeme pohlížet z jedné strany tak, že se ptáme, jaké objednávky zákazník udělal, nebo se ptáme, který zákazník udělal danou objednávku. K jednotlivým rolím se přiřazuje kardinalita. Kardinalita (maximální kardinalita) je maximální počet vztahů daného typu, ve kterých může participovat jedna entita. Naproti tomu členství (minimální kardinalita) vyjadřuje minimální počet vztahů daného typu, ve kterých musí participovat jedna entita (0 – nepovinné členství ve vztahu, 1 - povinné členství ve vztahu). Kardinalita i členství představují omezení. Na obrázku Obr. 3-5 je zobrazená vazba “Zakaznik_Objednavka”, která vyjadřuje vztah mezi zákazníkem a objednávkou. Tuto vazbu popisují dvě role, ke kterým jsou přiřazeny kardinality.

Obr. 3-5: Ukázka příkladu binární vazby

Pokud vazbu čteme směrem od zakaznika k objednavce (zakaznik_objednal), tak se ptáme, kolik objednávek může zákazník vytvořit. Kardinalita (0, N) znamená, že zákazník může vytvořit žádnou objednávku nebo vytvořit N (teoreticky nekonečno) objednávek. Pokud vztah čteme z druhé 36 – Vybrané aspekty návrhu webových informačních systémů

strany (objednano_zakaznikem), zajímá nás, kolik zákazníků může vytvořit danou objednávku. Kardinalita (1,1) znamená, že konkrétní objednávku může vytvořit pouze jeden konkrétní zákazník. Pravidla návrhu správných ERM Při navrhování a modelování ERM bychom mněli dodržovat jistá pravidla, která do jisté míry zaručí jejich správnost: • Z obrazujeme pouze data a jejich vztahy, žádné procesy Každý atribut zobrazujeme pouze jednou, • cílem je strukturovat seznam atributů, nikoli znázorňovat propojení v relační databázi Zobrazujeme seskupení dat pro účely ulo• žení v databázi, nikoli pro účely výstupů kombinaci atributů z různých entit a případné duplicity realizují až pohledy (formuláře, sestavy) • Zobrazujeme pouze perzistentní (trvalé) datové objekty, data, jež hodláme vygenerovat výpočty a agregacemi, nemodelujeme Entity mají být normalizované (např. • atributy, mezi kterými je vztah 1 : N, nepatří do stejné entity) • Zobrazujeme pouze nezbytně nutné vztahy (tj. ty, které k něčemu využijeme – např. v dotazu) Pozor na tyto entity: • Entita bez atributů • Entita, která má pouze identifikátor a žádné další atributy Datové modelování a návrh databáze – 37

• Entita, u níž nastane pouze jeden výskyt • Entita, která obsahuje atributy patřící jiným entitám (tzv. cizí atributy) Nezobrazujeme: • Redundantní vztahy • Odvozené vztahy • Kruhové závislosti (smyčky) V praxi se často vyskytují případy, kdy má entita definovaný atribut, který není tvořen jen atomickou hodnotou, ale má také svou vnitřní strukturu - strukturovaný datový typ. S touto problematikou se ERM často vypořádávají pomocí takzvaných slabých entit. Princip spočívá v tom, že k hlavní entitě se vytvoří „pomocná“ entita, která nemůže existovat bez hlavní entity. Takto vytvořená entita se propojí s hlavní entitou pomocí vazby s potřebnou kardinalitou.

Logický datový model Převod konceptuálního modelu (ERM) do logického modelu (v našem případě relační model) je vlastně transformací definovaných entit, atributů a vztahů do množiny relačních tabulek. K transformaci (mapování) ERM na databázové schéma existuje více přístupů, které jsou popsané např. v [15]. Prvním krokem je vytvoření tabulek. Nejdříve se vytvoří pro každou entitu jedna tabulka. Do tabulky jsou přímo nakopírovány informace o atributech uloženými uvnitř entity. Také dochází k úpravě názvů atributů. Některé tabulky mohou být při převodu zrušeny. Kromě svých atributů můžou obsahovat identifikátory některých entit 38 – Vybrané aspekty návrhu webových informačních systémů

Obr. 3-6: Ukázka příkladu binární vazby

také identifikační atributy jiných entit. Reprezentace silné entity (entita identifikovatelná vlastním atributem) není problém, převede se na tabulku se stejnými atributy (kromě vícehodnotových) a z identifikátoru entity se stane klíč tabulky. Nepovinný atribut se vyřeší sloupcem, který může obsahovat hodnoty Null (nedefinované, prázdné hodnoty). V případě, že je některý atribut vícehodnotový, je nutno pro něj zřídit novou tabulku. Pokud by byla kardinalita vztahu mezi entitou a vícehodnotovým atributem M:N, pak by klíčem nové tabulky byli všechny její sloupce. Reprezentace slabé entity se řeší v rámci reprezentace vztahu s kardinalitou (0,N):(1,1) nebo (1,N):(1,1). V další části je třeba vyřešit všechny vztahy jeden po druhém. Reprezentace binárních vztahů se liší podle příslušných kardinalit. U kardinality (1,1):(1,1) nám pro převod stačí jediná tabulka pro obě entity. Dáme do ní všechny atributy obou entit a jejich vztahu. U kardinalit (0,1):(1,1) nebo (0,N):(1,1) definujeme dvě tabulky, pro každou entitu jednu tabulku, přičemž vztah dodefinujeme přidáním odpovídajících atributů z druhé entity. Pro převod binárního vztahu s kardinalitami (0,1):(0,1), (0,N):(0,1) nebo (0,N):(0,N) je Datové modelování a návrh databáze – 39

potřeba až tří tabulek - pro každou entitu jedna a třetí pro vztah. Dalším vhodným krokem je kontrola, zda má každá vytvořená tabulka vhodnou strukturu. Takováto kontrola tabulek se provádí pomocí normalizace. Mezi důležité kroky patří také kontrola integritních omezení. Integritní omezení (pravidla) jsou omezení plynoucí z reality reprezentované daty v dané databázi. Integritní pravidla zabraňují tomu, aby se databáze stala nekompletní nebo nekonzistentní. Mezi obecná integritní omezení patří: • Tabulka neobsahuje prázdné buňky - všechny hodnoty jsou definované • Rozsah hodnot atributu je dán datovým typem (doménou) • Neexistují 2 stejné řádky (unikátní identifikace entit) - každý řádek je identifikovatelný - klíč tabulky • Entitní integrita – primární klíč (žádná jeho část) nesmí obsahovat prázdnou hodnotu – hodnotu Null • Referenční integrita – tabulka nesmí obsahovat žádnou nesouhlasnou hodnotu cizího klíče Posledním krokem, který se doporučuje provést je kontrola a posouzení navrženého modelu uživateli.

Normalizace dat Normalizace je technika, která je využívána při kontrole struktury tabulek transformovaných z ERM, nebo přímo navržených při přístupu mode40 – Vybrané aspekty návrhu webových informačních systémů

lování „zdola nahoru“. Motivací k normalizaci jsou chybně navržené struktury tabulek, které můžou obsahovat redundantní data (stejné informace víckrát na různých místech) a tím způsobovat aktualizační anomálie při vkládání, aktualizaci, případně odstraňování dat (insert/ update/delete). Cílem normalizace dat je tedy snížit respektive eliminovat redundanci dat, co znamená minimalizovat nadbytečnost dat a tím snížit i jejich „prostorovou náročnost“. Dá se říci, že normalizace se obvykle provádí na tabulce jako řada testů, které kontrolují, zda jsou dodržena pravidla pro danou normální formu. Testy můžou být vykonávané ručně, ale častěji to bývá naprogramovaným algoritmem, který je součástí CASE systému. Nejsou-li normalizační pravidla dodržená, je potřeba tabulky dekomponovat. Dekompozice dat musí splňovat základní vlastnosti: • Odstranění opakování – redundance • Zachování závislostí - původní závislosti musí být zachovány • Bezztrátovost při zpětném spojení (spojením tabulek, které vznikli dekompozicí, musí dát přesně původní tabulku). Nejčastěji používané normální formy jsou první normální forma (1NF), druhá normální forma (2NF) a třetí normální forma (3NF). Existují i další (vyšší) normální formy, ke kterým patří Boyce-Coddova normální forma (BCNF), čtvrtá normální forma (4NF) a pátá normální forma (5NF). Vyšší normální formy se běžně nepoužívají, protože řeší specifické a málo se vyskytující problémy. Podrobné informace ohledně normálních forem Datové modelování a návrh databáze – 41

jsou popsané např. v [11]. První normální forma - 1NF Tabulka je v první normální formě, právě když všechny její atributy jsou atomické, tj. dále již nedělitelné. Tj. každý atribut je elementárního typu a je nestrukturovaný. 1NF je jedinou normální formou, která je kriticky důležitá při návrhu a vytvoření vhodných tabulek. 1NF je základní podmínkou „plochosti“ tj. tabulka je opravdu dvourozměrné pole (neobsahuje např. skrytý strom nebo graf). Druhá normální forma - 2NF Tabulka je ve druhé normální formě, právě když splňuje 1NF a všechny neklíčové atributy jsou plně funkčně závislé na celém (složeném) primárním klíči. Funkční závislost popisuje vztah mezi atributy A a B jedné tabulky, kde atribut A determinuje (předurčuje) atribut B ( ). Plná funkční závislost znamená, že atribut je funkčně závislý na celém složeném atributu a ne jen na některé jeho části. 2NF se týká jenom tabulek se složenými primárními klíči, tj. když volíme za primární klíč kombinaci atributů. Třetí normální forma - 3NF Tabulka je ve třetí normální formě, jestliže je v 2NF a všechny její atributy jsou přímo závislé pouze na primárním klíči - tj. všechny neklíčové atributy jsou navzájem nezávislé. 42 – Vybrané aspekty návrhu webových informačních systémů

K porušení tohoto požadavku dojde, jestliže v tabulce existují atributy, které jsou závislé na jiných atributech, které jsou dále závislé na primárním klíči - tranzitivní závislost. Tranzitivní závislost popisuje vztah mezi atributy A, B, C. Pokud atribut A determinuje B ( ) a atribut B determinuje C ( ), pak atribut C je tranzitivně závislý na A prostřednictvím atributu B (tj. C nezávisí na A přímo, ale prostřednictvím B).

Fyzický datový model Poslední fází návrhu databáze je převod logického modelu dat do modelu fyzického tj. převod navržených tabulek, jejich struktur a integritních omezení do cílového systému řízení báze dat. Pro správný návrh fyzického modelu je potřeba dobře znát funkčnost cílového systému řízení báze dat. Fyzický návrh databáze lze definovat jako popis implementace navržené databáze – podkladových tabulek, organizace souborů, použitých indexů a dalších integritních a bezpečnostních omezení. Velice důležitým krokem je návrh podkladových tabulek včetně datových domén a integritních omezení. Způsob jejich vytvoření závisí samozřejmě od použitého systému řízení báze dat. V některých případech je nutné kromě podkladových tabulek navrhnout také reprezentaci odvozených dat a dalších integritních omezení. Návrh a implementaci podkladových tabulek včetně dalších součástí je nutné detailně dokumentovat. Kromě popisu návrhu a implementace podkladových Datové modelování a návrh databáze – 43

tabulek musí být v dokumentaci uvedené i údaje o použitém systému řízení báze dat a operačním systému. Jedná se především o organizaci souborů, indexů a případných transakcí. Hlavním cílem je určit optimální resp. efektivní uložení dat tj. organizaci souborů. Některé systémy řízení báze dat nepodporují volbu organizace souborů, jiné ano. Pro případnou volbu organizace souborů, případně vytvoření indexů je potřebné, podobně jako pro návrh podkladových tabulek, vést podrobnou dokumentaci. Ve víceuživatelském systému řízení báze dat hrají důležitou úlohu (např. pro zajištění bezpečnosti) uživatelské pohledy. Pohledy se obvykle vytvářejí pomocí jazyka SQL jako „pojmenované dotazy“, ke kterým má přístup pouze specifikovaný uživatel resp. uživatelé. Posledním, ale o to důležitějším krokem, který zde zmíníme, je návrh zabezpečení databáze. Mechanizmus zabezpečení datových zdrojů se obvykle navrhuje dle požadavků uživatelů. Relační systémy řízení báze dat poskytují dva základní typy zabezpečení: zabezpečení systému a zabezpečení dat. Stručně řečeno, zabezpečení systému se provádí pomocí zavedení uživatelských jmen a hesel, zabezpečení dat pomocí uživatelských práv přístupu k objektům databáze. Jelikož otázka bezpečnosti dat je v současné době velice akruální a v centu pozornosti je potřeba se ji podrobně věnovat. Zabezpečení dat a bezpečnosti webového informačního systému obecně je věnovaná samostatná kapitola v této knize.

44 – Vybrané aspekty návrhu webových informačních systémů

Grafické formáty pro WIS Pavel Pokorný

4

Cílem této kapitoly je popsat teoretické poznatky moderní 2D počítačové grafiky, které nachází využití v oblasti přípravy a tvorby grafických prvků u www informačních systémů. Celá tato problematika je rozložena do tří částí. V první části jsou podrobně popsány způsoby reprezentací obrazových informací včetně jejich výhod, nevýhod a oblastí použití. Ve druhé části se nachází výčet a stručná charakteristika vybraných grafických programů, které se v současné době hojně používají. Pozornost je zaměřena především na nekomerční aplikace. Třetí část této kapitoly popisuje nejčastější grafické formáty, do kterých se obrazové informace ukládají, a které bývají podporovány www informačními systémy.

Počítačová grafika a reprezentace obrazových informací Počítačová grafika je oblast informatiky, která se dynamicky stále rozvíjí. Protože je velice úzce propojena s hardwarovým vybavením, tento rozvoj je dán zejména neustálým růstem výkonu a tím i možnostmi počítačů. V dnešní době si tak můžeme dovolit pracovat s obrazy ve vysokých rozlišeních a barevných hloubkách a provádět s nimi operace (velice často i v reálném čase), které dříve zrealizovat vůbec nešly nebo jen velice obtížně.

Oblast použití počítačové grafiky je značně široká. Do této oblasti patří například konstrukční a návrhářské systémy v oblasti strojírenství, architektury (CAD/CAM), příprava a tvorba publikací (DTP), nejrůznější grafy, ikony, diagramy a mapy, výukové trenažéry a vědecké aplikace, počítačové animace (tvorby filmů či úpravy již vytvořených animací) nebo zpracování obrazu (zejména úpravy fotografií a naskenovaných obrazů). Nejobecnější dělení počítačové grafiky z pohledu její reprezentace bývá na vektorovou a rastrovou. Přestože se často používají společně, jsou mezi nimi zásadní rozdíly, které si nyní blíže specifikujeme. [2]

Vektorová grafika Počítačová grafika, která je reprezentovaná vektorově, je dána ve formě matematického zápisu. Tento matematický zápis obsahuje definice čar a křivek, které jsou základními kameny všech grafických objektů, které příslušný obraz obsahuje. Těchto objektů může obraz obsahovat od jednotek až po tisíce a každý z nich má svůj vlastní popis a vlastnosti. Tyto popisy a vlastnosti pak můžeme dle potřeby měnit, tj. například u úsečky změnit polohu počátečního a koncového bodu, nastavit odlišný styl, tloušťku, barvu, apod. Hardwarové nároky počítačů pro práci s vektorovou grafikou bývají obvykle větší. Vše se odvíjí od toho, s jak náročnými obrazy se pracuje (tj. jaké množství vektorových prvků obrazy obsahují a případně jaké mají vlastnosti – především některé grafické efekty jsou velice náročné na 46 – Vybrané aspekty návrhu webových informačních systémů

výpočetní výkon). Proto zde logicky platí pravidlo, že čím náročnější obrazy jsou, tím je potřeba výkonnější počítač. Z výše uvedeného popisu vyplývají výhody a nevýhody vektorové reprezentace obrazu. Díky matematickému popisu je vektorová grafika přesná a ani při velkém zvětšení vektorového obrazu nedochází k žádnému rozostření. Ostré a přesné hrany čar, křivek i všech dalších grafických objektů zůstávají stále zachovány. Další výhodou je snadná změna vlastností každého z objektů. Ve vektorovém obraze se tak snadno provádějí zásadní změny od vyjmutí až po nejrůznější deformace a efekty.

Obr. 4-1: Ukázka vektorové grafiky [42]

Mezi nevýhody vektorové grafiky můžeme počítat již zmíněné stoupající hardwarové nároky s narůstajícím počtem objektů. Také některé typy grafických prvků se pomocí matematického aparátu mohou popisovat jen velice obtížně, například výplně ploch. Oblasti použití vektorové grafiky opět vychází její charakteristiky. Je to tedy především tam, Grafické formáty pro WIS – 47

kde je vyžadována přesnost a vysoká kvalita obrazu. Setkáme se s ní proto především v oblasti konstrukcí a návrhů (CAD/CAM), grafických a kartografických informačních systémů (GIS), tvorbě počítačových animací, v reklamních studiích a agenturách, která navrhují vizitky, loga, reklamní letáky, potisky, apod.

Rastrová grafika Obraz v rastrové (nazývané též bitmapové) grafice je složený z jednotlivých bodů, které jsou umístěny vedle sebe. Toto uspořádání se nejčastěji vyjadřuje pomocí matice, resp. mřížky (tj. obraz mívá obdélníkový nebo čtvercový tvar). Každý prvek této matice představuje bod výsledného obrazu, Každý z těchto bodů má pevně danou svoji polohu v obraze a barvu v některém z barevných modelů (RGB, CMYK, HLS apod.). Počty těchto bodů mohou být i miliony a lze z nich tak složit prakticky libovolný obraz. Hardwarové nároky rastrová grafiky bývají obvykle nižší než vektorové. Zde jsou tyto nároky dány rozlišením obrazu (tj. množstvím bodů) a barevnou hloubkou. Tyto dva parametry jsou stěžejní údaje vypovídající o možné kvalitě obrazu a zároveň také o spotřebě paměti počítače pro jeho uložení. Například nekomprimovaný obraz s rozlišením 800 x 600 bodů a barevnou hloubkou 256 barev v barevném režimu RGB potřebuje pro své uložení 800*600*1 = 480.000 bytů v paměti počítače (256 barev odpovídá 1 bytu pro každý bod a ve výpočtu neuvažujeme paměť pro uloženou barevnou paletu). Pokud bychom měli zmínit výhody a nevýhody ras48 – Vybrané aspekty návrhu webových informačních systémů

trové reprezentace obrazu, lze obecně říci, že jsou přesně opačné vzhledem k vektorové grafice. Obě reprezentace se tak vlastně vzájemně doplňují a často se používají společně. Mezi výhody rastrové reprezentace obrazu patří snadnost jeho získání (často pomocí skeneru nebo fotoaparátu). Takto zachycený obraz bývá opticky věrný a lze s ním (často v kombinaci s dalšími rastrovými obrazy) prostřednictvím různých grafických nástrojů provádět různé efekty, fotomontáže nebo koláže. K nevýhodám rastrové grafiky logicky patří nepřesnost. Její další nevýhoda je, že je nevhodná pro obrazy kde dochází ke zvyšování rozlišení (dochází ke znatelnému zhoršení obrazové kvality). Mezi nevýhody patří i složitější manipulace s obrazy, které mají velmi vysoké rozlišení.

Obr. 4-2: Ukázka diagoniální úsečky v rastru

Do oblasti použití spadá například archivace, protože získané digitální obrazy si uchovávají stálou kvalitu a nepodléhají stárnutí a poničení či úplnému zničení jako papírová forma dokumentů. Dále se s ní můžeme setkat v oblasti reklamy a propagace, kde fotografie a rastrové obrazy doplňují přesné vektorové kresby. Často se také používá v multimédiích a počítačových hrách (2D i 3D – zde především jako výplně či Grafické formáty pro WIS – 49

textury pro 3D objekty).

Stručná charakteristika vybraného grafického software 2D grafických programů existují desítky až stovky. Při hledání vhodného programu je třeba nejprve vybírat podle oblasti zaměření. Základní rozdělení grafických aplikací jsme si uvedli výše (rastrový či vektorový). Další kritéria, která rozhodují o výběru vhodného programu, jsou následující. Zaměření programu (zcela jistě se vybere jiný program pro tvorbu vizitek a propagačních materiálů a jiný program bude použit v oblasti strojírenských návrhů), množství grafických nástrojů, pro jaký operační systém byl vytvořen, uživatelská přívětivost (znalost prostředí) a cena programu. Na první pohled to vypadá, že čím více grafických nástrojů bude vybraný grafický program podporovat, tím lépe, protože se tak rozšiřuje oblast jeho působnosti. Ne vždy ale toto pravidlo platí. Například pokud potřebujeme vytvořit jednoduchou rastrovou kresbu, postačí obyčejné Malování, což je aplikace, která je součástí každého operačního systému Windows. V takových případech není třeba žádný program kupovat či stahovat z internetu. Navíc logicky platí obecné pravidlo, že čím komplexnější a složitější program na počítač nainstalujeme, tím větší mívá hardwarové a systémové požadavky pro svůj plynulý provoz. Dle zaměření této kapitoly zaměřme pozornost zejména na grafické aplikace, které se používají pro tvorbu a úpravu grafiky pro webové infor50 – Vybrané aspekty návrhu webových informačních systémů

mační systémy. Do této kategorie můžeme zařadit následující programy: Vektorové: Adobe Illustrator, CorelDraw, Zoner Callisto, Inkscape. Rastrové: Adobe Pro, Pixia.

Photoshop,

Gimp,

Paint

Shop

V obou kategoriích pochopitelně existuje programů mnohem více. Výběr byl proveden na základě obecně známé oblíbenosti uživatelů u profesionální i laické veřejnosti. Z výše uvedených výčtů stručně charakterizujeme dva programy – Inkscape a Gimp. Důvodem je, že jsou zcela zadarmo a přesto patří k nejlepším programům v dané oblasti. Vyzkoušet a používat je tedy může každý.

Obr. 4-3: Základní uživatelské rozhraní programu Inkscape

Program pro vektorovou grafiku - Inkscape Inkscape je open source vektorový grafický editor. Hlavním cílem tvůrců bylo vytvořit silný a schopný nástroj na kreslení plně kompatiGrafické formáty pro WIS – 51

bilní s XML, SVG a CSS standardy. Snahou také bylo a stále je pomocí otevřeného a komunitně orientovaného vývoje udržovat stále narůstající skupinu uživatelů a vývojářů. Inkscape je multiplatformní, tj. je dostupný pro operační systémy Linux, Mac OS X, Windows, SPARC a Sun Solaris. [3] Program je stažitelný z domovských stránek [3], ale bývá umístěn i na mnoha dalších serverech. Instalační soubor poslední verze (0.48.2) má velikost asi 40 MB, po instalaci je velikost celé aplikace přibližně 150 MB. Program obsahuje několik desítek jazykových lokalizací (nechybí ani čeština), pokud si je odpustíme a ponecháme si pouze angličtinu (tato volba se nachází na začátku instalace), velikost celé aplikace bude okolo 80 MB. Program Inkscape je poměrně intuitivní, komunikace s uživatelem probíhá standardně pomocí oken, dialogových boxů, ikon, příkazového menu apod., takže i neprofesionální uživatelé by s jeho ovládáním neměli mít problémy (jednotlivé příkazy a nástroje mají nápovědu, která se automaticky zobrazuje u kurzoru myši nebo ve stavovém řádku aplikace). Patrně pouze začátečníci, kteří s grafickými programy nemají příliš mnoho zkušeností, se zřejmě neobejdou bez příručky. Ukázka uživatelské rozhraní programu Inkscape je na obrázku 3. Otevřít je možné i více projektů, přičemž každý z nich má svoje vlastní okno nezávislé na ostatních. Inkscape nativně načítá/ukládá do vektorového formát SVG, ale podporuje i dalších 52 – Vybrané aspekty návrhu webových informačních systémů

cca 40-50 vektorových a rastrových grafických formátů, čímž je zaručen správný přenos vytvořených obrazů do jiných aplikací. K základním nástrojům, kterými Inkscape disponuje, patří kreslení objektů (ruční a pomocí křivek, rychlé kreslení uzavřených obrazců jako jsou elipsy, obdélníky, polygony) a vkládání rastrových obrazů. Se všemi objekty je možné manipulovat pomoci různých transformací, seskupovat je, vzájemně kombinovat pomocí booleovských operací a vkládat je do různých vrstev nebo aplikovat na ně standardní editační příkazy. Úsečkám, křivkám a obrysům objektů je možné dále upravovat a nastavovat potřebné tvary a styly. U výplní a obrysů lze nezávisle nastavovat barvy v různých barevných modelech, vyplňovat je možné různými vzory, barevnými přechody nebo rastrovými obrazy. Samozřejmá je i práce s průhledností. Inkscape podporuje i práce s texty, které je možné různě formátovat (například podle vybraného objektu) nebo je vkládat na křivku. Výše uvedený výčet nástrojů programu Inkscape samozřejmě nezahrnuje vše. K ověření možností programu vede nejspolehlivější cesta taková, že si tyto nástroje každý uživatel odzkouší sám. Množství a kvalita těchto nástrojů je na vysoké úrovni, proto se Inkscape řadí právem k předním programům v této oblasti.

Program pro rastrovou grafiku - Gimp Název Gimp představuje zkratku GNU Image Manipulation Program. To znamená, že jde program, který je zdarma včetně zdrojových kódů pod liGrafické formáty pro WIS – 53

cencí GPL. Tento rastrový grafický editor je velice rozšířený a používaný zejména pro grafické kresby, grafiky pro webové stránky, úpravy fotografií a tisk. Podobně jako Inkscape, je možné Gimp stáhnout z jeho vlastních domovských stránek [1] nebo mnoha dalších serverů na internetu. Standardně existují verze pro Linux, Windows a Mac OS X, ale díky přístupným zdrojovým kódům je možné jej zkompilovat i pro další platformy.

Obr. 4-4: Panel nástrojů a okno s obrázkem v programu Gimp

Nainstalovaný GIMP zabírá ve své poslední verzi (2.8.2) na disku okolo 250 MB. Tento údaj však nemusí být vůbec přesný. Gimp byl navržen tak, aby se dal dále snadno rozšiřovat o nové moduly nástrojů, palet, štětců a barevných přechodů. Jejich přidáním tato velikost logicky narůstá. Lokalizace Gimpu byla provedena do řady jazyků, 54 – Vybrané aspekty návrhu webových informačních systémů

mezi kterými nechybí ani čeština. Původně byl program Gimp navržen pro operační systém Unix. Proto se uživatelům jiných operačních systémů (zejména Windows) může jeho ovládání zdát nestandardní a mírně chaotické. Je to asi hlavní nevýhoda programu, která již odradila mnoho potenciálních uživatelů. Pravda je spíše taková, že jde především o zvyk, takže pokud má uživatel z Gimpu nepříznivý prvotní dojem a překoná jej, naučí se pracovat s velice kvalitním programem. Jednotlivé obrazy jsou otevírány v samostatných oknech, přičemž okna s jednotlivými příkazy a nástroji jsou pro všechna okna s obrazy společná. Práci s programem usnadňuje nápověda, která se zobrazuje u každého nástroje automaticky při umístění kurzoru myši na příslušném příkazu. Gimp používá svůj vlastní souborový formát XCF (který je doporučeno vždy používat, aby byly zachovány veškerá nastavení programu i samotného obrazu), ale lze provádět i importy/exporty do mnoha jiných grafických formátů (pochopitelně především rastrových). Gimp disponuje velkým množstvím ovládacích nástrojů a svými možnostmi předčí i mnohé komerční programy dané oblasti (navíc, jak jsme uvedli výše, další nástroje se tam dají poměrně snadno přidávat). Pokud zaměříme pozornost na ty hlavní, jsou jimi rozličné druhý výběrových nástrojů (včetně vektorového nástroje Cesta), ke kterým patří i jejich ukládání pro pozdější použití, řada kreslících nástrojů (tužka, štětec, guma, rozprašovač, kaligrafické pero) s Grafické formáty pro WIS – 55

mnoha nastaveními (režim, krytí, výběr stopy, velikost, barva), různé druhy výplní (jednobarevné, barevné přechody, vyplňování vzorky), řada jednoduchých i pokročilých transformací s vybranou částí či celým obrazem, propracovaný systém práce s vrstvami a nástroje pro úpravy fotografií od korekcí barev až po retušování. Bohatá řada filtrů (například rozmazání, zkreslování, práce s šumy, detekce hran či umělecké úpravy) pak umožňuje rychlou tvorbu nových nebo modifikaci stávajících obrazů.

Grafické formáty v prohlížečích www stránek Formáty grafických souborů obsahují určitým způsobem organizovaná grafická data pro jejich opětovné obnovení. [4] Grafických formátů existuje velké množství (řádově desítky až stovky). Pro pochopení příčin existence tak velkého množství těchto formátů je potřeba je rozdělit podle jejich účelu. Patrně největší skupinou jsou grafické formáty specifikované výrobci pro jejich vlastní grafický program. A protože grafických programů existuje velké množství, existuje i velké množství takových formátů. Jsou jimi například BMP, PCX, IMG, TGA, PSP nebo XCF. Jinou skupinou jsou grafické formáty, které byly navrženy pro přenos grafických obrazů po síti – např. PNM nebo MIFF. Třetí skupinou jsou grafické formáty, které byly navrženy jako univerzální standardy pro širokou oblast použití. Příklady takových formátů jsou GIF, TIF, PNG nebo JPG nebo WebP. Níže jsou stručně popsány formáty, které se v moderních informačních systémech hojně používají, případně se staly často používanými formáty 56 – Vybrané aspekty návrhu webových informačních systémů

výrobci hardwarových zařízení, které pracují s grafickými obrazy – digitální fotoaparáty, DVD přehrávače, televizory, apod. Popsány jsou zde především rastrové grafické formáty. Důvodem je skutečnost, že se vektorová počítačová grafika se ve webových informačních systémech nepoužívá tak hojně (pokud ano, tak zpravidla bývá zpracovávána rozšiřujícími programovými technologiemi jako je java nebo flash). Z vektorových grafických formátů popíšeme SVG. Z rastrových grafických formátů uvedeme bližší popis BMP, GIF, PNG a JPG.

Grafický formát SVG Vektorový grafický formát SVG byl navržen především pro oblast 2D webové grafiky. Postupně se však stal obecně uznávaným standardem pro přenos vektorových grafických informací mezi různými platformami a aplikacemi. Důkazem jeho rozšíření je skutečnost, že je přímo podporován ve všech významných vektorových editorech a dokonce i v jazyku pro tvorbu www stránek HTML5. Protože bývá vektorová reprezentace náročnější na výkon, byly vytvořeny dvě varianty – SVG Basic a SVG Tiny. Varianta SVG Tiny je zjednodušená a neobsahuje všechny moduly, které má SVG Basic. Je tak primárně určena pro zařízení s omezeným výpočetním výkonem a menší kapacitou paměti. [6] Velkou výhodou formátu SVG je skutečnost, že se jedná o textový soubor, který je založen na jazyku XML. Tato skutečnost má dvě výhody. První výhodou je snadná tvorba a úprava výsledGrafické formáty pro WIS – 57

ného obrazu prostřednictvím programového kódu. Druhou výhodou je validita, tedy dá se velice snadno poznat, pokud je nějakým způsobem soubor poškozen. Ukázka obrazu ve formátu SVG s jeho zdrojovým kódem je na obrázku 5. Obecně je SVG plnohodnotný vektorový formát, který podporuje základní geometrické tvary, křivky, rastrové obrazy, texty, barevné profily a přechody, fonty, animace, apod. Navíc ale podporuje i interaktivitu, takže může reagovat na vstup od uživatele (například obrázek se změní po klepnutí myši). Lze jej tak například použít i pro tvorbu jednodušších www aplikací. Díky podpoře komprese je také možné snížit celkovou velikost souboru, což je velice přínosné u pomalejších síťových připojení.

Obr. 4-5: Obrázek a jeho zdrojový kód v souboru SVG

Grafický formát BMP Grafický formát BMP se v dnešní době aktivně již příliš nepoužívá. Především z historických důvodů však bývá drtivou většinou grafických programů hojně podporován. Má totiž výhody dobré definice struktury formátu, jednoduchou implementaci a rychlé načítání. Naopak hlavními ne58 – Vybrané aspekty návrhu webových informačních systémů

výhodami je velká spotřeba paměti, což je dáno tím, že nepoužívá žádnou kompresi nebo nejjednodušší varianty RLE komprese (čtyřbitová nebo osmibitová varianta). [4] Princip RLE komprese je založen na redukci opakovaných řetězců znaků. Takto opakovaný řetězce pak bývá zakódován do dvou bytů – první udává počet stejných znaků (barev) a druhý byte pak konkrétní hodnotu znaků v tomto řetězci. Z uvedeného vyplývá, že tato komprese je v obraze účinná, pokud obsahuje velké jednobarevné plochy. To ale v obrazech nebývá často. V opačných případech může dojít i k záporné kompresi. Z tohoto důvodu se běžně RLE komprese používá u formátu BMP pouze u obrazů s nižší barevnou hloubkou, neboť tam je pravděpodobnost výskytu stejných barev vyšší. Struktura formátu BMP je rozdělena do čtyř částí. První z nich je bitmapová hlavička, která kromě specifikace typu souboru (znaky „BM“) obsahuje také celkovou velikost souboru, a počáteční polohu obrazových dat v souboru. Druhou částí je informační hlavička, která obsahuje další doplňující informace o obrazu, jako je šířka a výška, barevná hloubka nebo zda je použita RLE komprese a jaká její varianta. Třetí částí je barevná paleta, která se však v souboru nemusí vyskytovat – vytváří se pouze pro obrazy s barevnou hloubkou 1, 2 nebo 8 bitů. Čtvrtým blokem jsou potom samotná obrazová data.

Grafický formát GIF Grafický formát GIF byl navržen pro záznam a přenos bitmapových obrazů. I přes dřívější proGrafické formáty pro WIS – 59

blémy s licenčními podmínkami (platnost posledního patentu vztahující se ke GIF vypršela v roce 2006) se tento grafický formát stal velice populární. Příčinami popularity byly dobré zdokumentování, poměrně rychlá a účinná LZW komprese, multiplatformnost, možnost užití průhlednosti, práce s rámci a použití prokládacího schématu. Pro tyto vlastnosti se GIF poměrně často používá i dnes i mimo webové informační systémy. [4] [6] Práce s rámci je založena na filosofii, že celý obraz není uložen v souboru jako celek, ale skládá se z dílčích obdélníkových bloků (rámců) libovolného počtu jedním společným pozadím, nazývaným též logická obrazovka. Každý rámec přitom můžeme chápat jako samostatný obrázek umístěný ve výsledném obrazu. Pozice a velikost všech rámců je v souboru uložena a každý rámec může také mít svoji barevnou paletu. Všechny rámce dohromady pak tvoří kompletní obraz, nazývaný též logická obrazovka – viz obrázek 6.

Obr. 4-6: Uspořádání rámců v grafickém formátu [5] 60 – Vybrané aspekty návrhu webových informačních systémů

Rámce poskytují tři významné výhody. První výhoda je, že pomáhají v obraze odlišit místa, která se barevně příliš odlišují, a tím může docházet k účinnější kompresi. Druhým důvodem je, že se tyto rámce mohou také zobrazovat v časové závislosti, ve formátu GIF tedy může být uložena i animace. Třetí výhodou je, že každý rámec může mít maximálně 256 barev. Použijeme-li jich tedy více, je možné zvýšit celkové množství barev v celém obraze. Další výhoda - prokládací schéma, bylo navrženo s ohledem přenosu GIFu na pomalých sítích. Prokládání funguje tak, že se nejdříve přenese každý osmý řádek, posléze každý čtvrtý řádek (kromě těch přenesených), a tak dále do posledního kroku, ve kterém jsou přeneseny všechny ostatní, tj. sudé řádky. Uživatel si tak může utvořit představu o celém obrazu již při přenesení přibližně jedné osminy dat a přenos popř. přerušit. [5] LZW komprese patři v kategorii neztrátových kompresních algoritmů mezi nejúčinnější. Jejich princip je založen na tzv. slovníkovém kódování. Algoritmus si buduje pomocný slovník, do kterého ukládá posloupnosti dosud nekomprimovaných dat. Pokud se však při průchodu daty narazí na posloupnost, která se ve slovníku již nachází, na výstup se pouze zapíše zkrácený odkaz (fráze). [4] Struktura formátu GIF je rozložena do několika bloků. Prvním je hlavička o velikosti 6 bytů a slouží k identifikaci souboru (obsahuje řetězec „GIF87a“ nebo „GIF89a“. Za hlavičkou následuGrafické formáty pro WIS – 61

je popis hlavní (logické) obrazovky obsahující rozlišení obrázku, informace o paletě a barvě pozadí. Poté již následují bloky s rámci (každý z nich obsahuje popis daného bloku, obrazová data a paletu). Protože rámců může být více, za posledním z nich se nachází znak 3Bh, který slouží jako identifikátor úplného konce souboru.

Grafický formát PNG PNG je grafický formát, který vzniknul jako náhrada formátu GIF v době, kdy ještě byly platné jeho licenční podmínky, které jeho využití v aplikacích omezovaly. Oblast použití je tedy stejná jako u GIFU a navíc s sebou přinesl několik dalších vylepšení a výhod. Jimi jsou až 16-bitová barevná hloubka pro obrazy ve stupních šedi, až 16-bitová průhlednost a až 48-bitová barevná hloubka pro barevné obrazy. [4] Dalšími výhodami je, že nikdy nebyl zatížen žádnými licenčními poplatky, proti GIFu má rychlejší systém prokládaného zobrazení, podporuje předzpracování pixelů (tím lze dosáhnout ještě lepšího kompresního poměru), flexibilitu (struktura souboru je navržena tak, aby se mohla v budoucnu dále rozšiřovat) a robustnost (umožňuje úplnou kontrolu integrity souboru, takže je možné poznat, zda není soubor s obrazem poškozený). Do formátu PNG je také možné uložit informace o ICC profilu a gama faktoru zařízení, kde byl obrázek vytvořen, takže při jeho přenosu na jiné platformy by nemělo docházet ke zkreslení barev. Nevýhodu proti formátu GIF má pouze jednu – do jednoho souboru lze uložit jen jediný obraz, 62 – Vybrané aspekty návrhu webových informačních systémů

takže nepodporuje ani animace. V případě, že po obraze požadujeme, aby byla všechna data uchována (tj. nepoužila se ztrátová komprese) a nevadí-li nám tento zmíněný nedostatek, formát PNG bývá obvykle nejlepší volbou z rastrových grafických formátů. Struktura souboru PNG je následující. Na začátku se nachází 8-bytová identifikační signatura formátu a dále obvykle následují čtyři standardní bloky dat, které musí podporovat každá aplikace, jež formát PNG čte nebo do něj zapisuje. Prvním blokem je hlavička obsahující základní údaje o obrazu a druhým blokem je barevná paleta, která se však v souboru vyskytuje pouze tehdy, pokud obrazová data paletu využívají. Samotná obrazová jsou třetím blokem. Čtvrtým blokem je pata souboru, která bývá uložena až na jeho konci. V ní se nachází kontrolní součet, ze kterého lze poznat, zda soubor je nebo není poškozen.

Grafický formát JPG Nedostatek kompresních algoritmů RLE a LZW je, že nejsou příliš efektivní pro plně barevné obrazy s barevnými přechody. To znamená, že i velikost formátů grafických souborů popsaných výše, bývá veliká. Grafický formát JPG tento nedostatek odstraňuje pomocí ztrátovosti obrazových dat. V praxi se ukazuje, že snížení kvality na 75% je pro většinu uživatelů nepozorovatelné, přitom kompresní poměr v takovém případě může být 20:1 až 25:1. [8] Kompresní algoritmus využívá diskrétní kosinovou transformaci a byl navržený konsorciem Joint Photographic Experts Group. Jeho určení je zeGrafické formáty pro WIS – 63

jména pro fotografie či obrazy s velkou barevnou hloubkou, u obrazů s nižším barevným rozlišením se nepoužívá, neboť v nich vytváří vzory v podobě čtverců či pruhů. Optimálním vstupem je tak obraz s 24-bitovou barevnou hloubkou.

Obr. 4-7: Princip ztrátové komprese JPEG [7]

64 – Vybrané aspekty návrhu webových informačních systémů

Princip této komprese je založen na vlastnostech lidského oka. To je citlivé zejména na změny jasu, méně je však citlivé na rozdíly barev dvou sousedních obrazových bodů. A jak bylo uvedeno výše, právě to, na co je oko nejméně citlivé se z obrazu odstraní. Celý postup ztrátové komprese JPEG je patrný z obrázku 7. Nejprve se provede neztrátový převod současného barevného modelu (RGB, CMYK, atd.) do barevného modelu YCBCR (nebo YUV). Poté, co je jasová složka oddělena od barev může proběhnout redukce barevných složek na základě uživatelského nastavení. Provede se to zvýšenou periodou vzorkování obrazu a právě zde je první místo celého algoritmu, kde může dojít ke snížení objemu dat a tím pádem i k určité (často zanedbatelné) ztrátě obrazové informace. Další kroky se provádí odděleně pro jasovou a barevnou složku. Na bloky 8×8 hodnot je aplikována diskrétní kosinová transformace (DCT). Tato transformace je neztrátová a provádí převod obrazového signálu z časové oblasti do frekvenční. Důvod je takový, že právě ve frekvenční oblasti se dá snadno poznat, které oblasti obrazu obsahují dominantní informace (nižší frekvence) a naopak, které oblasti obsahují méně důležité obrazové informace (vyšší frekvence). Další fáze je proto klíčová pro ztrátovost, tedy výběr a odstranění částí obrazu s vysokými frekvencemi. To se provádí pomocí kvantování, resp. sestavené kvantovací matice. Kvantované DCT koeficienty se potom následně neztrátově komprimují pomocí Huffmanova či aritGrafické formáty pro WIS – 65

metického kódování. Posledním krokem zpracování je uložení vytvořených dat do souboru typu JFIF/ JPEG. V podstatě se jedná o „obalení“ vzniklého datového toku vhodnou hlavičkou, přidání dalších doplňujících informací a zakončení celého souboru patičkou. Dekomprese probíhá přesně opačným způsobem. [7] Formát JPEG se stal velice úspěšnou technologií a standardem používaným většinou fotoaparátů a multimediálních přehrávačů. Jeho nepříjemnou vlastností je dělení obrazů do čtverců 8×8, což může v určitých částech obrazu způsobit vznik makropixelů a zároveň je to překážka k dosažení ještě většího kompresního poměru. Proto vznikl formát JPEG 2000, který tento nedostatek odstraňuje, neboť bere obraz jako celek a podrobuje jej transformacím pomocí funkcí - tzv. vlnek. Opakované použité těchto transformací umožňuje uchovat obraz ve více rozlišeních, definovat v něm oblast, která je předmětem našeho zájmu a tuto oblast kódovat ve vyšší kvalitě, optimalizovat data pro přenos po síti a umožňuje použít ztrátovou a neztrátovou kompresi. [8]

66 – Vybrané aspekty návrhu webových informačních systémů

Shrnutí Tato kapitola shrnuje obecné poznatky o přípravě 2D grafických souborů pro použití v moderních www informačních systémech. Nejprve jsou vysvětleny a uvedeny podrobné charakteristiky dvou používaných druhů reprezentací obrazu – vektorová a rastrová. Tato část je sestavena především na základě dlouholetých zkušeností autora této kapitoly. Další část této kapitoly se věnuje popisu dvou vybraných grafických programů, které se v oblasti vektorové a rastrové počítačové grafiky velice často používají – Inkscape a Gimp. Výběr těchto programů byl založen na základě množství grafických nástrojů, které mají k dispozici a dále s ohledem na licenci jejich použití (v obou případech jde o GNU GPL, která říká, že lze programy bezplatně používat a dále šířit). Logickým krokem je pak závěrečná část kapitoly, která popisuje 2D grafické souborové formáty, do kterých se vytvořené grafické obrazy ukládají v současné době nejčastěji. Snahou přitom bylo, aby jejich charakteristika nebyla jen obecným popisem, ale aby z tohoto textu také vzešlo doporučení, kdy je vhodné který souborový formát v moderních www informačních systémech použít.

Grafické formáty pro WIS – 67

Bezpečnost webových aplikací Martin Sysel

5

Tvorba webových stránek patří mezi počítačové znalosti, které se lze naučit velmi snadno. Vytvořit svou první webovou stránku zvládne uživatel již za prvních pár minut studia. První vytvořené webové stránky jsou většinou statické a bohužel, většinou nejsou validní. Validní webové stránky jsou takové, které odpovídají standardům konsorcia W3C [23]. Později uživatel začíná vytvářet dynamické webové stránky s použitím některého z programovacích jazyků (PHP, ASP.NET, Python, Java). Tento kód je potom prováděn na straně serveru a umožňuje například přístup do databáze. Webová stránka může také obsahovat kód, který se provádí na straně klienta, nejčastěji JavaScript. Veškerý tento kód může být zdrojem potencionálního nebezpečí. Obvyklým omylem mnoha tvůrců webových stránek je, že se domnívají, že jejich stránky nejsou pro útočníka dostatečně zajímavé. Neobsahují přece nic důležitého, proč by je někdo měl chtít napadnout? Útočník ale napadá takové stránky proto, aby je použil jako odrazový můstek, například pro šíření škodlivého softwaru. Bezpečnostní chyby vznikají z  různých příčin, často to je z  důvodu neznalosti programátora nebo z důvodu nedostatku času a s tím souvisejícím odkládáním zabezpečení na pozdější dobu. Jestliže si programátor možné nebezpečí uvě-

domuje, tak musí v průběhu vývoje dávat pozor na velké množství problémů, které posléze můžou složit k napadení webových stránek, databáze, případně celého systému. Stačí jedno jediné malé opomenutí a již vzniká riziko napadení. Programátor webových aplikací musí brát v úvahu všechna slabá místa aplikace a musí věnovat maximum pozornosti jejich zabezpečení. Útočníkovi pak stačí objevit pouze jedno slabé místo a to potom využije k napadení. Výčet bezpečnostních chyb může být prakticky neomezený, proto se tato kapitola bude zabývat pouze nejběžnějšími bezpečnostními hrozbami, které ale mají také nejzávažnější dopad na zranitelnost webové aplikace a návrhem jejich řešení. K definování nejčastějších a nejvíce využívaných bezpečnostních chyb je využit žebříček deseti nejzávažnějších bezpečnostních hrozeb pro webové aplikace (OWASP Top 10) od nadace OWASP (Open Web Application Security Project) [25, 26]. Nadace OWASP již zveřejnila tři verze tohoto žebříčku (v letech 2004, 2007, 2010). Nová verze se očekává v roce 2013. Cílem celého projektu je zlepšit bezpečnost a zabezpečení webových aplikací, zvýšit informovanost webových programátorů ohledně bezpečnostních hrozeb.

Bezpečností rizika Poslední žebříček bezpečnostních rizik byl zveřejněn v roce 2010 [26]. Uvádí pořadí hrozeb a označuje je jako A1 – nejzávažnější až po A10 – méně závažná (častá). Jednotlivá rizika budou v  dalším textu podrobně rozebrána, budou prezentovány ukázky útoků a také způsoby Bezpečnost webových aplikacć – 69

obrany. V dalším textu bude využíván jazyk PHP a databáze MySQL, protože tato kombinace je mezi uživateli hojně rozšířena. Je však nutno zdůraznit, že popisovaná rizika se vyskytují obecně – nezáleží na použité databázi nebo programovacím jazyku. Tab. 5-1: Nejčastější bezpečnostní hrozby [26]

Kód

Chyba

A1

Injection Injekce (vsouvání)

A2

Cross-Site Scripting (XSS) Skriptování napříč stránkami

A3

Broken Authentication and Session Management Špatná autentizace a správa sessions

Chyba umožňující vsouvání neověřeného kódu do příkazu nebo dotazu (v operačních systémech, SQL, LDAP, …). Předaná data mohou přimět aplikaci k provedení nechtěných příkazů nebo pro přístup k neoprávněným datům. Chyba vznikající při odeslání nedůvěryhodných dat do internetového prohlížeče bez řádného ověření. Umožňuje útočníkovi spouštět vlastní skripty v prohlížeči klienta a tak například převzít uživatelskou relaci nebo přesměrovat uživatele na škodlivé stránky útočníka. Aplikační funkce pro ověřování uživatele a řízení relace jsou často špatně implementovány, což umožňuje útočníkovi napadnout hesla, bezpečnostní klíče nebo relace.

70 –  Vybrané aspekty návrhu webových informačních systémů

A4

Insecure Direct Object References Nebezpečný přímí odkaz na objekt

A5

Cross-Site Request Forgery (CSRF) Podvržení požadavku mezi různými stránkami

A6

Security Misconfiguration Špatná konfigurace

A7

Insecure Cryptographic Storage Nedostatečná ochrana citlivých dat

A8

Failure to Restrict URL Access Špatné omezení přístupu k určitým URL

Jestliže vývojář používá přímé odkazy na interní implementace objektu (soubor, adresář, přístup do database, …) bez kontroly řízení přístupu, může útočník využít tento odkaz pro přístup k neoprávněným datum. Odeslání upraveného HTTP požadavku z prohlížeče oběti bez jeho vědomí. Aplikace je následně mylně přesvědčena, že se jedná o oprávněné požadavky uživatele. Dobré zabezpečení vyžaduje bezpečné konfigurace u všech použitých součástí: server, webový server, databázový server, aplikační server, framework, … Předpokladem je i aplikace opravných balíčků. Bohužel u mnoha SW není výchozí konfigurace bezpečná. Mnoho aplikací nechrání dostatečně citlivá data (hesla, osobní informace, čísla kreditních karet). Tyto údaje lze získat a v případě, že nejsou chráněna vhodným šifrováním, může je útočník zneužít. Chyba vzniká nekontrolováním přístupových práv při každém přístupu na konkrétní URL adresu. Může to vest k obcházení přístupových práv stránky.

Bezpečnost webových aplikací – 71

A9

Insufficient Transport Layer Protection

Je důležité brát v úvahu bezpečnost informace při přenosu. Nešifrovaná data lze poměrně snadno odposlechnout a zneužít.

Nezabezpečená síťová komunikace A10

Unvalidated Redirects and Forwards Neověřená přesměrování a předávání

Stránky často přesměrovávají nebo předávají uživatele na jiné stránky nebo servery. Často jsou využívané nedůvěryhodné a neověřené údaje útočníka k určení cílové stránky.

Injection Chyba umožňující vsouvání neověřeného kódu do příkazu nebo dotazu. Tato chyba může nastat všude, kde někdo může zaslat nedůvěryhodná data. Za nedůvěryhodná data lze považovat vše, co přichází do systému z vnějšku. Předaná data mohou přimět aplikaci k provedení nechtěných příkazů nebo pro přístup k  neoprávněným datům. Typický útok začíná zasláním jednoduchého textového řetězce, který ale využívá syntaxi interpretru jinak, než původně zamýšlel programátor. V případě SQL injection se využívá nedostatečné kontroly vstupních dat aplikace [27]. SQL dotaz obsahuje řetězce, které zadává uživatel a právě toto je potencionálním zdrojem problémů, protože vývojář předpokládá, že uživatel nebude zadávat neplatná data. Ukázka útoku Útok na formulářová pole pro přihlašování uživatelů. Předpokládejme zjednodušený přihlašo72 –  Vybrané aspekty návrhu webových informačních systémů

vací formulář:

Jméno: Heslo:

Při jeho zpracování v souboru login.php je vytvořen SQL dotaz, který se pokusí vyhledat uživatele se shodným jménem a zároveň odpovídajícím heslem ve tvaru hashe SHA-1 (důvod uložení hesla ve tvaru hashe bude rozebrán později). Jestliže je takový uživatel nalezen, tak jsou SQL dotazem vráceny všechny uložené informace o daném uživateli a lze předpokládat, že uživatel existuje a může být přihlášen. $sql=”SELECT * FROM table WHERE user = ‘”.$_POST[‘jmeno’].”’ AND passwd = ‘”.sha1($_POST[‘passwd’]).”’”;

Toto ověření bude bez problémů fungovat do okamžiku, kdy uživatel začne místo svého jména a hesla zadávat speciální znaky. V  první ukázce uživatel do formulářového pole jmeno zadá řetězec „admin“ a formulářové pole pro heslo vůbec nevyplní. Uživateli (nyní již útočníkovi) se podařilo pomocí dvou pomlček ukončit SQL dotaz (vše za pomlčkami je považováno za poznámku). Aby byl SQL dotaz validní, musel být doplněn ještě ukončovací apostrof. Prováděný SQL dotaz tedy bude mít výsledný tvar pouze: SELECT * FROM table WHERE user = ‘admin’

Bezpečnost webových aplikacć – 73

Útočník předpokládá, že uživatel admin bude existovat a bude mít také pravděpodobně nejvyšší oprávnění. Velmi jednoduchým trikem by tedy získal oprávnění jiného uživatele. V druhé ukázce můžeme předpokládat, že útočník nezná žádné přihlašovací jméno. Do formulářového pole pro jméno zadá řetězec „‘ OR 1=1“ a formulářové pole pro heslo může zůstat opět prázdné. Výsledný prováděný SQL dotaz bude mít tvar

SELECT * FROM table WHERE user = ‘’ OR 1=1

SQL dotaz vrátí obsah celé tabulky, útočník může potom případně omezit počet vrácených záznamů pomocí klíčového slova LIMIT. Pro označení komentáře se v  SQL používá několik různých posloupností znaků: “--“, “#”, “//” a pro víceřádkové komentáře: “/* */” a “{ }”. V případě, že nelze komentáře využít, může útočník zadat do formulářového pole pro jméno „admin’ OR ‘a’=’b“.Prováděný SQL dotaz bude mít výsledný tvar SELECT * FROM table WHERE user = ‘admin’ OR ‘a’=’b’ AND passwd = ‘’

Tento typ útoku využívá prioritu operátorů. Operátor AND bude zpracován jako první a jeho výsledkem bude hodnota FALSE. Jako druhý v pořadí bude vyhodnocován operátor OR v  částečně vyhodnoceném dotazu SELECT * FROM table WHERE user = ‘admin’ OR FALSE 74 –  Vybrané aspekty návrhu webových informačních systémů

Pro operátor OR stačí, aby byla pravdivá pouze jedna část výrazu, což bude v případě existence uživatele admin splněno. Modifikace vstupních dat se nemusí omezovat pouze na formulářová pole. Velmi jednoduše lze například modifikovat dotazy typu GET přímo v adresním řádku a dostat se tímto způsobem k obsahu databáze, případně načíst nebo dokonce zapsat externí soubor. Z  předchozích ukázek útoků je zřejmé, že existuje nepřeberné množství různých útoků využívajících injection. Způsob obrany Pro vývojáře existuje několik způsobů jak řešit riziko napadení. Základem je kontrola datových typů a ošetření vstupů pomocí escapovaní speciálních znaků. Nedoporučuje se k  tomuto vytvářet vlastní funkce. PHP nabízí pro escapovaní SQL dotazů funkce vlastní. Konkrétně pro databází MySQL má funkce název mysql_real_escape_string(). Vytvářený SQL dotaz v kódu PHP by tedy měl tyto funkce využívat. $sql=”SELECT * FROM table WHERE user = ‘”.mysql_real_escape_string($_POST[‘jmeno’]).”’ AND passwd = ‘”.sha1(mysql_real_escape_string($_ POST[‘passwd’])).”’”;

Protože na použití těchto funkcí se často zapomíná, bývá doporučováno pro vývoj použít speciální databázovou vrstvu a framework, které minimalizují opomenutí bezpečnostních zásad. V  PHP

existuje

konfigurační

direktiva,

která

Bezpečnost webových aplikací – 75

způsobí, že v obsahu všech superglobálních polí $_POST a $_GET je před apostrofy doplněno zpětné lomítko. Toto řešení však může přinášet problémy na výstupu a navíc nelze zaručit dostupnost jejího nastavení na všech serverech. Její použití se v současnosti nedoporučuje.

Cross-Site Scripting (XSS) Chyba vznikající při odeslání nedůvěryhodných dat do internetového prohlížeče bez řádného ověření. Umožňuje útočníkovi spouštět vlastní skripty v prohlížeči klienta a tak například převzít uživatelskou relaci nebo přesměrovat uživatele na škodlivé stránky útočníka. Tento typ útoku je využitelný i na statických stránkách, kde může být přenesena proměnná z  URL adresy do JavaScriptu. Daleko častější je však předání obsahu do stránek s  aktivním obsahem, kde jsou zpracovány například pomocí PHP. Obsah nemusí být získán pouze z přímého vstupu uživatele (proměnné v  URL, formuláře, …), ale také například z databáze nebo podvrženého souboru. Pokud je modifikovaný kód zobrazen uživateli, dochází k nežádoucí úpravě obsahu, přesměrování stránky nebo odcizení cookies. Ukázka útoku Předpokládejme výskyt následujícího neošetřeného kódu:

Útočníkovi potom stačí v URL adrese předat svůj vlastní skript, který bude na stránce proveden http://URL/page.php?jmeno=<script>alert(‘XSS útok.’);

76 –  Vybrané aspekty návrhu webových informačních systémů

Analogicky lze provést útok i z formulářů v případě, že jsou data přenášena metodou POST. Například do vyhledávacího pole je zadán řetězec <script>alert(‘XSS útok.’); a při výpisu výsledků hledání je daný skript proveden. Někdy se může stát, že se zadaný skript přímo neprovede, ale z výpisu zdrojového kódu stránky je vidět, že na stránce je obsažen. Potom je nutno upravit vkládaný řetězec tak, aby odpovídal struktuře webové stránky, například ukončit formulářový prvek. Způsob obrany Opět zde platí, že nebezpečný je obecně jakýkoliv vstup dat do webové aplikace. Nejen přímo od uživatele získaný ze superglobálních proměnných $_GET a $_POST, ale i z dalších $_REQUEST, $_COOKIE, $_SERVER. V  úvahu je potřeba brát i další zdroje zobrazovaných dat, která jsou získána z databáze popřípadě z externích souborů. Ochrana spočívá v  důsledné kontrole výstupu. Jedná se hlavně o znaky, které mění kontext zpracování dat, jako například HTML a CSS tagy. Je nutno důsledně dodržovat pravidlo, že se neověřená data nesmí vkládat do aplikace bez provedení escapování tohoto nebezpečného kódu. Escapování se používá až na výstupu dat z aplikace. Funkce modifikující zdrojová data by neměly být využívány například při ukládání dat do databáze, protože se tím vytváří závislost mezi datovou a aplikační vrstvou, což způsobuje problémy při využití dat jinými aplikacemi. Programátor má k  dispozici několik možností, jak ošetřit výstup pomocí escapování. NejčastěBezpečnost webových aplikací – 77

ji je využívána funkce htmlspecialchars(), která provede konverzi speciálních znaků na HTML entity. V případě pokusu o vložení JavaScriptu do kódu aplikace je sice vkládaný kód zobrazen, ale protože je zapsán pomocí HTML entit, tak již není proveden. Řetězec vkládaný útočníkem: <script>alert(‘XSS útok.’);

Tento kód vložený do HTML stránky odesílaný do prohlížeče by byl spuštěn a uvedený kód by byl proveden. Jestliže bude řetězec konvertován na HTML entity, bude mít ve zdrojovém kódu HTML stránky následující podobu: <script>alert(‘XSS útok.’);

Zobrazen pro uživatele však bude normálně ve tvaru, jakým byl zadán. HTML entity jsou na výstupu převedeny na zobrazitelné znaky. Tímto postupem je však zabráněno spuštění kódu. Funkcí pro konvertování znaků na HTML entity je více, např. htmlentities(), ale použití funkce htmlspecialchars() je dostačující. V případě nutnosti zpětného převodu je možno použít funkci htmlspecialchars_decode(), která převede HTML entity zpět na znaky. Někteří programátoři si zvolili cestu modifikace zobrazených řetězců a přímo odstraňují všechny části kódu, které mohou být nebezpečné (HTML 78 –  Vybrané aspekty návrhu webových informačních systémů

a PHP tagy). Bohužel k  tomu zvolili nevhodný přístup, a to použití seznamu zakázaných řetězců (blacklist). Nebezpečný kód však lze různými způsoby zamaskovat a je tedy velmi obtížné udržovat seznam kompletní a aktuální. Daleko vhodnější je použití seznamu povolených hodnot (whitelist), který lze vždy v  případě potřeby doplnit. Většinou je velmi neefektivní (při nedostatku zkušeností i nebezpečné) vytvářet vlastní funkce, protože mohou být zdrojem neočekávaných problémů. PHP nabízí přímo funkci strip_tags(), která z řetězce odstraňuje HTML a PHP tagy. Pomocí nepovinného parametru je možno určit, které jsou povoleny (whitelist povolených tagů).

Narušená autentifikace a správa relace Webové aplikace většího rozsahu obsahu i část, která je přístupná pouze přihlášeným uživatelům, případně je pro přihlášené uživatele modifikován obsah (poskytován ve větším rozsahu a s  většími možnostmi). Uživatelé mají tedy vytvořeny své uživatelské účty, ke kterým je nutno se přihlásit. Existují tři základní kroky, které vedou k  úspěšném určení přihlašovaného uživatele a jeho práv [29]. V prvním řadě musí uživatel zadat své identifikační údaje, typicky se jedná o přihlašovací jméno a heslo, hovoříme tedy o identifikaci. Následuje ověření zadané identity, tento krok se nazývá autentizace. Ověřuje se skutečnost, zda je zadaná identita uživatele pravá. Uživatelská jména a hesla bývají většinou uloženy v databázi. Je možno využívat i jiných metod autentizace, případně jejich kombinací – vícefaktorová autentizační metoda. Velmi populární se stává požadavek zadání přiBezpečnost webových aplika>í – 79

hlašovacího jména, hesla a zároveň požadavek na přítomnost nějakého předmětu, například mobilního telefonu pro ověření přes SMS, USB tokenu nebo autentizačního kalkulátoru, který po zadání pinu vygeneruje heslo s ohledem na reálný čas. Nejvyšší stupeň zabezpečení zahrnuje ověření pomocí biometrických prvků, což bývá ale vzhledem pořizovací ceně využíváno pouze u kritických systémů. Jestliže autentizace proběhne úspěšně, následuje proces autorizace, tedy stanovení pravidel, co přihlášený uživatel smí a nesmí vykonávat. Většina aplikací má systém oprávnění definovaný rozdílným způsobem. Webové aplikace komunikují pomocí protokolu HTTP. Protokol funguje způsobem dotaz-odpověď. Uživatel pošle serveru dotaz ve formě formátovaného textu, který obsahuje označení požadovaných dat. Server následně odpoví pomocí několika řádků textu popisujících výsledek, za kterými následují samotná data. Protože se na serveru nerozlišuje, zda požadavky mezi sebou souvisí, hovoříme u tohoto typu komunikace o bezstavovém protokolu. Bezstavový protokol neumí zachovat stav komunikace mezi jednotlivými požadavky. Tato vlastnost je velmi nepříjemná. Relace (session) musí být tedy udržovány aplikačními programy, které vkládají nutné informace do přenášených dat (textových hlaviček, které jsou zasílány). Session dává webovému serveru možnost uložit si libovolné informace o jednotlivých uživatelích. Webový server si s  webovým prohlížečem vyměňuje identifikátor (session ID) a to jako HTTP cookie nebo přímo v  URL cílové stránky ve formě proměnné. Zabezpečení session funguje na tom, principu, 80 –  Vybrané aspekty návrhu webových informačních systémů

že přístup k proměnným konkrétního uživatele je možný přes jeho session ID v podobě dostatečně dlouhého, náhodně generovaného, a tedy neuhodnutelného klíče. Druhé specifikum je to, že session má poměrně krátkou dobu platnosti (implicitně bývá přibližně 24 minut, není-li nastaveno jinak). Samotné použití session ovšem automaticky nezaručuje, že se k datům pomocí nich uložených, dostane pouze uživatel, jemuž jsou určeny. Webové aplikace – pokud session využívají – by současně s ním měly zavést konkrétní principy, které riziko zneužití session minimalizují [30]. Identifikátor relace může být odcizen např. XSS útokem, proto je velmi důležité věnovat se zabezpečení aplikace komplexně. Základem je také nezveřejňovat identifikátor v  URL adrese jako parametr, protože případným zveřejněním odkazu by daná session byla kompromitována a útočník by k  ní získal přístup. Bohužel uvedení identifikátoru v  URL je jedná možnost jak udržovat relaci pro uživatele, kteří mají vypnuté HTTP cookies. Cookies neznamenají žádné nebezpečí pro počítač jako takový, pokud nezíská útočník přístup k počítači uživatele. Další chybou bývá použití příliš jednoduchého identifikátoru relace (snadno uhodnutelného) – jméno uživatele nebo IP adresa. Často také dochází k  tomu, že relace nebývá ukončena, ať už z  důvodu pouze zavření záložky v prohlížeči nebo prostě z důvodu chybějícího tlačítka odhlásit. Následují uživatel získává potom přístup k relaci. Nejvíce uvedených problémů řeší použití šifrované varianty protokolu HTTP - protokol HTTBezpečnost webových aplikací – 81

PS, který je zabezpečen proti odposlouchávání a podvržení dat. Bohužel šifrovaný protokol musí nabízet poskytovatel obsahu, uživatel musí přijmout to, co je mu nabízeno.

Nezabezpečený přímý odkaz na objekt K navigaci mezi webovými stránkami se využívají odkazy, které obsahují parametry. Tyto parametry jsou primární klíče databáze nebo někdy dokonce přímo jména souborů. Zde se pro útočníka otevírá možnost měnit tyto vstupní parametry k získání přístupu k dalším záznamům. Řešení tohoto problému spočívá v důsledné kontrole platnosti všech odkazů (nepřijímat neznámé a nepřípustné odkazy) a všech objektů, ke kterým se přistupuje, pomocí účinného mechanizmu pro řízení přístupu, který dostatečně ověří roli a privilegia uživatele. Nelze zde spoléhat na předchozí ověření uživatele. Vhodnou cestou je také vyhnout se použití přímého odkazu a nahradit ho odkazem nepřímým, který je snadno ověřitelný.

Cross-Site request forgery (CSRF) Nebezpečnost útoku CSRF (někdy označovaného jako XSRF) je hlavně v tom, že k napadení aplikace je využit její oprávněný uživatel. Po jeho autentizaci je skrytě proveden podvodný požadavek tak, že si toho uživatel vůbec nevšimne. Může být využita metoda GET i POST [28]. Ukázka útoku Útok využívá toho, že uživatel po autorizaci do aplikace přistoupí na stránku, která odešle aplikaci požadavek v  rámci session uživatele 82 –  Vybrané aspekty návrhu webových informačních systémů

(je zároveň odeslána i autorizační cookie). V případě využití metody GET jsou data odesílána v URL. Útočník může tedy využít, že při načítání obrázku se také generuje požadavek typu GET a vytvoří dotaz, který provede útok.

Tento podvodný obrázek umístí útočník na své stránky, kam potom pomocí sociálního inženýrství naláká uživatele nebo pomocí útoku XSS umístí obrázek například do diskuzního fóra, které potencionální oběti navštěvují. Využití metody POST není o mnoho složitější, pomocí JavaScriptu je odeslán požadavek ihned po načtení stránky. Formulář může být také umístěn na stránkách útočníka nebo vložen pomocí XSS na navštěvované stránky.

… kopie formuláře s předvyplněnýma hodnotama …

Jak vkládané podvodné obrázky, tak formuláře mohou být na stránce skryty pomocí kaskádových stylů, uživatel tedy nemusí jejich výskyt vizuálně vůbec zaznamenat. Způsob obrany Obrana proti CSRF je z velké části opět na proBezpečnost webových aplika>ć – 83

gramátorovi, ale i samotný uživatel se může bránit tomuto útoku dodržením určitých pravidel. Za dostačující obranu se považuje použití autorizačního tokenu, který je pro každý dotaz náhodně generován. Před zobrazením formuláře se vygeneruje token, který je uložen do session nebo do databáze a zároveň je odeslán jako skryté pole formuláře. Při zpracování dat jsou hodnoty porovnány, případná neshoda je potom vyhodnocena jako pokus o CSRF útok a požadavek není proveden. Existují i další metody, které však nejsou široce používány zejména z důvodu snížení uživatelského pohodlí. Jedná se například o opětovné vyžádání hesla před provedením nějaké kritické akce nebo žádost o zadání textového pole z náhodně generovaného obrázku – CAPTCHA. Kritické aplikace (například internetové bankovnictví) využívají zasílání tokenu pomocí SMS zpráv, tento přístup je však komplikovaný na implementaci a zvyšuje náklady na provoz aplikace. Uživatel se může tomuto typu útoku bránit částečně i sám. Řešením je po dobu platnosti session, kde je autentizován, nepřistupovat na jiné stránky. Nebezpečná konfigurace Bezpečnost webových aplikací ovlivňuje i bezpečnost služeb, které jsou nutné pro její fungování (Webový server, databázový server, operační systém, …). Špatná konfigurace nebo nedostatečné zabezpečení kterékoliv části může způsobit bez84 –  Vybrané aspekty návrhu webových informačních systémů

pečnostní problém. Výskyt takových chyb je poměrně častý, protože se jedná o velmi komplexní systémy. Konfiguraci takových systémů většinou programátor nemůže ovlivnit a musí spoléhat na administrátory těchto služeb. Důležitá je aplikace opravných balíčků na používané systémy, vypnutí všech služeb, které nejsou používány. Používání dostatečně silných hesel. Správné nakonfigurování všech částí a také vypnutí zobrazování chybových hlášek koncovému uživateli. Tyto výstupní informace by útočníkovi mohly jednoduše poskytnout mnoho informací týkající se běžící aplikace.

Nezabezpečené kryptografické úložiště Webové aplikace často uchovávají o uživatelích citlivé informace, které je nutno odpovídajícím způsobem chránit. Typickým příkladem špatného uchování dat je ukládání hesel v  textové podobě bez šifrování. Pokud se útočník k takové databázi dostane pomocí SQL injection útoku, tak získá přístup k účtům všech uživatelů. Šifrování citlivých údajů je nutnost, protože při zcizení těchto dat se tak velmi znesnadňuje jejich využití. Používat by se mely pokud možno nejsilnější algoritmy, avšak také s ohledem na povahu dat. Rozhodně se nedoporučuje vytvářet vlastní šifrovací algoritmy, jejich kvalita je velmi pochybná. Je nutno dbát na použití moderních algoritmů, protože některé starší jsou již slabé nebo dokonce již prolomené. Generování klíčů musí probíhat offline a je velmi důležité Bezpečnost webových aplika>í – 85

dbát na uložení privátních klíčů na bezpečném místě, které rozhodně nesmí být stejné jako šifrovaná data. Hesla je nutno zabezpečovat pouze jednosměrným šifrováním. Běžně se využívají hashovací funkce, které vytváří kryptografické kontrolní součty. Doporučované hashovací funkce rodiny SHA-2 (SHA224, SHA256, SHA384 a SHA512) vytváří ze vstupních dat řetězec o konstantní délce, s velmi malou pravděpodobností výskytu shodného otisku. V současné době se již nedoporučuje využívat hashovací funkci MD5, která již byla prolomena a navíc existují rainbow tabulky (databáze s  předpočítanými řetězci dat a jejich hashů), popřípadě SHA-1. Již při registraci uživatele je možno vyžadovat určitou složitost hesla. Pro zvýšení bezpečnosti hashe se navíc doporučuje využívat tzv. sůl. Jedná se o náhodný řetězec znaků, který se libovolným způsobem spojí s uživatelským heslem a teprve až z tohoto výsledného řetězce je spočítán kontrolní součet.

Chybné zamezení přístupu ke konkrétním URL Jedná se o případ, kdy webová aplikace nechrání stránky, které mají být přístupné pouze vybraným uživatelům, pomocí autorizace. Znepřístupnění stránek je realizováno pouze pomocí nezveřejnění jejich URL. Lze se tak velmi snadno dostat neoprávněně k datům. Obrana proti tomuto útoku je velmi jednoduchá a spočívá pouze na bedrech programátora. U každého přístupu je nutno na straně serveru dů86 –  Vybrané aspekty návrhu webových informačních systémů

sledně kontrolovat autorizaci uživatele a při neoprávněném pokusu přistoupit na zabezpečenou stránku zobrazit přihlašovací formulář. Testování takového zabezpečení spočívá v  kontrole všech odkazů z privátní části. Pro kontrolu lze využít roboty, které projdou web automaticky.

Nezabezpečená síťová komunikace Bezpečnost komunikace mezi klientem a serverem nelze v současné době zaručit bez využití SSL/ TLS (HTTPS - Hypertext Transfer Protocol Secure používá protokol HTTP, přičemž přenášená data jsou šifrována právě pomocí SSL nebo TLS). Nešifrovanou komunikaci lze poměrně snadno odposlechnout a data (např. přihlašovací údaje) následně zneužít. Nejjednodušší obranou je použití šifrovaného přenosu pro celý web, ale z důvodu výkonnostních dopadů na server se velmi často používá šifrovaného přenosu pouze pro přenos citlivých údajů, jako například pro přístup k privátní části webu nebo dokonce jen pro autentizaci uživatele. Veřejná část bývá dostupná bez šifrované komunikace.

Neplatné přesměrování a předávání parametrů Tento typ útoku využívá již dříve popsaných bezpečnostních chyb tím způsobem, že nezkontrolovaný vstup uživatele využije k  přesměrování na podvodnou stránku. Příkladem útoku může být případ, kdy aplikace používá skript na přesměrování na vlastní stránky. Do parametru je potom útočníkem vložen odkaz na podvodnou URL. http://www.example.com/redir.php?url=www.podvod.cz

Tento odkaz vypadá na první pohled důvěryhodně, Bezpečnost webových aplikacć – 87

protože pochází z  důvěryhodného serveru www. example.com, ale protože využívá chyby programátora, který nekontroluje vstupní data, dojde k přesměrování pomocí skriptu redir.php na podvodný server útočníka. Jestliže je grafická podoba podvodného serveru identická s originální webovou aplikací, může například dojít k odcizení přihlašovacích údajů. Základní obranou proti této chybě je nepoužívat v aplikaci přesměrování. Pokud přesměrování musí být použito, tak je nutno důsledně kontrolovat vstup uživatele například pomocí pomocí validace typu whitelist.

Závěr Bezpečnost bývá u webových aplikací velmi často opomíjena a přitom jejich dopad může být v  dnešní době obrovský. Kapitola se věnovala deseti hrozbám dle žebříčku organizace OWASP. Jednalo se o největší hrozby dle jejich výskytu a míry rizika. V žádném případě se však nejedná o kompletní popis dané problematiky. Běžné jsou i další rizika, která se vyskytují. Například automatizované získávání e-mailových adres z  webových stránek a jejich následné zneužití pro rozesílání spamu. Tento problém někteří programátoři obchází zveřejňováním e-mailové adresy pouze ve formě obrázku. Podstatně elegantnějším řešením je využít vlastních formulářů pro odeslání e-mailu, kde nemusí být cílová adresa viditelná, protože je e-mail odesílán na straně serveru. Následně se však může vyskytnout problém s  roboty, kteří automaticky plní formuláře na internetu a rozesílají například do internetových diskuzí nevyžádanou reklamu. I 88 –  Vybrané aspekty návrhu webových informačních systémů

tomuto typu útoku se však lze poměrně jednoduše bránit, ať už pomocí žádosti o zadání textového pole z náhodně generovaného obrázku – CAPTCHA, nebo vytvořením pro běžného uživatele skrytého vstupního pole, které však automat vyplní. Do budoucna je nutno problematiku bezpečnosti stále aktivně sledovat, protože je to oblast, která se stále velmi dynamicky vyvíjí. Nelze opomíjet nové bezpečnostní hrozby, které se objevují.

Bezpečnost webových aplika>ć – 89

Technologie Internetu, základní pojmy a principy Miroslav Matýsek

6

Pro neznalé problematiky počítačových sítí a technologie Internetu doporučuji se seznámit se základními pojmy v následujícím textu. Tyto základní pojmy jsou následně použity v dalších částech problematiky technologie Internetu.

Internet versus internet Internet je jméno jedné konkrétní soustavy vzájemně propojených počítačových sítí. Internet je pouze jeden, jako celek nemá žádného vlastníka, své vlastníky mají jen dílčí části Internetu. Na rozdíl od Internetu, internet (s malým i) chápeme jako soustavu vzájemně propojených sítí (např. i v jednom pokoji), internetů je velké množství a internet má vždy vlastníka (např. vnitřní síť firmy).

Intranet versus extranet Intranet tvoří příslušnou část sítě organizace, sloužící pro samotnou organizaci, poskytuje aplikace a služby uvnitř organizace. Extranet tvoří příslušnou část sítě organizace sloužící pro poskytování aplikací a služeb externím organizacím a uživatelům.

Typy sítí PAN (Personal Area Network): osobní počítačová síť, sloužící uživateli k propojení jeho elektronických zařízení navzájem (nootebok, mobil, tablet), ve většině případů v jedné místnosti, dnes povětšinou technologii Bluetooth. LAN (Local Area Network): lokální počítačová síť, je to síť sloužící k propojení jednotlivých síťových uzlů navzájem, typicky v rámci jedné budovy. CAN (Campus Area Network): areálová počítačová síť, propojující několik LAN v rámci areálu firmy s více budovami. MAN (Metropolitan Area Network): městská síť, síť propojující jednotlivé LAN ve městě nebo vesnici. WAN (Wide Area Network): rozlehlá počítačová síť, propojuje jednotlivé MAN a LAN v rámci celého státu, kontinentu, dříve celé zeměkoule. GAN (Global Area Network): síť v rámci celé zeměkoule, např. Internet.

Přenášená data Zpráva

Zpráva je logicky ucelený balík dat (mail, soubor, …), který přenášíme po síti. Zpráva má proměnnou délku dat. Zprávu na transportní vrstvě rozdělíme na segmenty nebo datagramy.

Technologie Internetu, základní pojmy a principy – 91

Segment, datagram, paket a rámec Segment, datagram, paket a rámec je balík dat o stanovené pevné délce na různých úrovních síťového SW a HW.

Simplex, poloduplex a plný duplex Simplexní přenos: Data jsou přenášená jen jedním směrem. Většina přenosů na optických vláknech (existují i složitější technologie, které umožňují na jednom optickém vlákně plně duplexní provoz). Poloduplexní přenos: Data jsou přenášena oběma směry, avšak v daném okamžiku jen jedním směrem (nikoliv současně). Příkladem může být Ethernet do 1 Gb/s. Plně duplexní přenos: Data jsou přenášena oběma směry současně, např. Ethernet 10 Gb/s.

Přenosové rychlosti U počítačových sítí se můžeme setkat s  dvěma rychlostmi, jedná se o přenosovou a modulační rychlost. Přenosová rychlost Přenosová rychlost v b/s, udává počet přenesených bitů za sekundu. U přenosových rychlostí se používají mocniny při základu 10, tedy dle jednotek SI kb/s, Mb/s, Gb/s a Tb/s. Modulační rychlost Modulační rychlost v Bd, udává počet přenesených signálových prvků za sekundu. Také můžeme říci, že se jedná a počet změn stavu nosné za 92 – Vybrané aspekty návrhu webových informačních systémů

sekundu.

Metody komunikace

Sítě s přepojováním okruhů a paketů V 70. letech vznikly první počítačové sítě, některé s přepojováním okruhů jiné s přepojováním paketů. Sítě s přepojováním okruhů Sítě s přepojováním okruhů můžeme charakterizovat následujícími vlastnostmi: • Rezervované spoje mezi dvěma uzly • Po celou dobu spojení máme pro sebe volný komunikační kanál • Nevýhodou je blokování celého kanálu po dobu spojení • Používají některé sítě s radiovým spojením a ISDN (Integrated Services Digital Network)

Obr. 6-1: Síť s přepojováním okruhů Technologie Internetu, základní pojmy a principy – 93

Sítě s přepojováním paketů Odlišné vlastnosti od sítí s přepojováním okruhů můžeme shrnout takto: • Pakety se posílají z uzlu na uzel, když je volný komunikační kanál, • Přepojovací uzly pracují systémem store and forward, • Použito např. v GAN Internet a navzájem propojených kancelářských lokálních sítích.

Obr. 6-2: Síť s přepojováním paketů

Dělení dle počtu rámců Dle počtu rámců šířící se v  daném okamžiku na komunikačním vedení dělíme sítě na rozlehlé a soustředěné. Rozlehlé sítě V  rozlehlé síti se šíří v  daném okamžiku na 94 – Vybrané aspekty návrhu webových informačních systémů

komunikačním vedení více jak jeden rámec, typickými zástupci jsou sítě WAN před nasazením optického Ethernetu do těchto sítí.

Obr. 6-3: Soustředná a rozlehlá síť

a ≤ 1 a > 1 Kde:

Soustředěná síť Rozlehlá síť



a = τ / t0 , v ≠ ∞ ,

τ = zpoždění signálu na komunikačním vedení, t0 = je střední doba potřebná k vyslání jednoho rámce při dané přenosové rychlosti. Soustředěná síť U soustředěných sítí se v daném okamžiku se na vedení může šířit pouze jeden rámec. Typickým příkladem je LAN Ethernet na metalickém vedení.

Přenosová média Jedná se o fyzická média, kterými jsou přenášena data na Fyzické vrstvě modelu OSI ke svému cíli. U počítačových sítí se používají nejčastěji tyto tři typy komunikačních medií: 1. elektrické vodiče (obvykle měděné) • koaxiální kabel Technologie Internetu, základní pojmy a principy – 95

• kroucená dvojlinka 2. optická vlákna 3. „vzduch“ (bezdrátový přenos)

Koaxiální kabel Vykazuje poměrně dobré parametry při frekvencích pod 1 GHz. Dříve se používal u LAN Ethernet na rychlosti 10  Mb/s s  charakteristickou impedancí 50 Ω a u LAN Arcnet s charakteristickou impedancí 93 Ω. Dnes se koaxiální kabel s charakteristickou impedancí 50  Ω používá jako propojka mezi anténou a radiomodemem u bezdrátových sítí (tzv. pigtail) a koaxiální kabel s charakteristickou impedancí 75  Ω na propojení účastnické zásuvky s kabelovým modemem u CATV (Cable Television). Koaxiální kabel se připojuje u Ethernetu k BNC konektorům RG58 krimpovacími kleštěmi nebo se na pájecí variantu konektorů připájí cínovou pájkou. U CATV se používají pro

Obr. 6-4: Koaxiální kabel

připojení kabelového modemu konektory F.

96 – Vybrané aspekty návrhu webových informačních systémů

Kroucená dvojlinka Je označovaná též jako TP (Twisted Pair). Může přenášet data s rychlostí až do 10 Gb/s na vzdálenost 100 m.. Dva vodiče jsou vždy vzájemně kolem sebe obtočeny, čímž se minimalizuje EMI (Electromagnetic Interference) a ztráty způsobené kapacitním odporem, tj. tendencí nevodiče uchovávat elektrický náboj a maximalizuje se EMS (Electromagnetic Susceptibility). Jedná se o symetrické přenosové médium, signál je přenášen jako rozdíl napětí mezi těmito dvěma vo-

Obr. 6-5: Kroucená dvojlinka

diči, což způsobuje menší náchylnost vedení k rušení a útlumu. Charakteristická impedance se pohybuje v rozmezí 100 ± 15 Ω. Kroucená dvojlinka se vyrábí ve třech základních variantách: • UTP (Unshielded TP) nestíněná kroucená dvojlinka • ScTP (Screened TP) částečně stíněná, jen celek • STP (Shielded Twisted Pair) stínění jedTechnologie Internetu, základní pojmy a principy – 97

notlivých páru i celku. Kroucenou dvojlinku je možné zařadit do některé ze 7 kategorii označených čísly 1 až 7. Pro některé kategorie byly vytvořeny i podkategorie označeny velkým písmenem za číslem kategorie. Příkladem mohou být podkategorie 5E a 6A. Čím vyšší kategorie, tím vyšší přenosové rychlosti je možné u kroucené dvojlinky použít. V počítačových sítích se v současné době používají kategorie 5 až 7, např. kategorie 5 je určena pro Ethernet do 100 Mb/s, kategorie 6 pro Ethernet do 1 Gb/s a kategorie 7 pro Ethernet do 10Gb/s. Podkategorii 5E je možné u Ethernetu použít do rychlosti 1 Gb/s a podkategorii 6A do 10 Gb/s. U kroucené dvojlinky se v kancelářských počítačových sítích sjednotili výrobci na konektoru RJ-45, který se adjustuje krimpovacími kleštěmi. Maximální délka vedení z kroucené dvojlinky u Ethernetu je stanovena na 100 m.

Optická vlákna Optická vlákna využívají pro přenos informací téměř dokonalých odrazu na rozhraní dvou materiálů s rozdílným indexem lomu. Optické vlákno se skládá z jádra, pláště světlovou a ochranného obalu. Jádro je vyrobeno ze skla nebo plastu. Plastové optické vlákna jsou levnější, ale mají mnohonásobně vyšší útlum. Jádrem se šíří optický paprsek v infračerveném spektru. Infračervené spektrum bylo zvoleno vzhledem k nejmenšímu útlumu paprsku v optickém vlákně. Jádrem se může šířit 98 – Vybrané aspekty návrhu webových informačních systémů

jeden paprsek jeden vid - jednovidové optické vlákno (singlemode) vytvořený laserovou diodou nebo více paprsků - mnohovidové optické vlákno (multimode) vytvořených led diodou s dírkovou clonkou. Typické průměry jádra u jednovidových vláken jsou 8 a 9 μm, u vícevidových 50 a 62,5 μm. Plášť světlovodu je vyroben taktéž ze skla nebo plastu a má nižší hodnotu indexu lomu než jádro. U optických vláken se skokovou změnou indexu lomu dochází na rozhraní jádro - plášť světlovou k  téměř dokonalým odrazům, čímž se optický paprsek udržuje v jádře. Plášť světlovou se vyrábí typicky s průměrem 125 μm. Ochranný obal je vyroben z neprůhledného plastu ve dvou vrstvách. Chrání optické vlákno proti mechanickému poškození, zvláště při ohybu. Jeho vnější průměr se pohybuje kolem 1 mm. Optická vlákna se vyrábějí ve třech variantách: • vícevidové se skokovou změnou indexu lomu (step index), • vícevidové s postupnou změnou indexu lomu (graded index), • jednovidové se skokovou změnou indexu lomu. Maximální délka vedení bez retranslace se  pohybuje u jednovidových vláken kolem 100  km, u vícevidových vláken díky vidové disperzi jen do několika set metrů. Optická vlákna se svařují nebo nouzově lepí na speciálních zařízeních. Optické konektory se ke kusům optických vláken připojují většinou ve výrobě. Bohužel se Technologie Internetu, základní pojmy a principy – 99

Obr. 6-6: Typy vláken: Step Index Multimode, Graded index Multimode, Step Index Singlemode (zleva)

standardizace v oblasti konektorů nedostala tak daleko, jako u kroucené dvojlinky nebo koaxiálního kabelu. Z  tohoto důvodu se u optických vláken používá více typů konektorů např. FC, SC, ST, E2000, MTRJ a další.

Obr. 6-7: Řez optickým kabelem

Optická vlákna se sdružují do optických kabelů. 100 – Vybrané aspekty návrhu webových informačních systémů

V  optickém kabelu mohou být i vlákna obojího typu, tedy část jednovidových a část vícevidových vláken. Řez typickým optickým kabelem je uveden na obrázku níže.

Komunikace vzduchem Pro komunikaci vzduchem pomocí radiových vln se používají licencovaná pásma 3,5 GHz, 26 a 28 GHz a „Bezlicenční pásma“ a tzv. Generální licencí 2,4 GHz, 5 a 10,5 GHz. Pásma jsou rozdělena na jednotlivé rádiové kanály. V  některých pásmech se rádiové kanály překrývají např. v  pásmu 2,4 GHz, v některých pásmech jsou navrženy bez překryvu – pásmo 5 GHz. Bezdrátové počítačové sítě jsou označeny jako WLAN (Wireless LAN), podskupinou jsou bezdrátové sítě popsány ve standardech IEEE 802.11 (Institute of Electrical and Electronics Engi-

Obr. 6-8: Členění WLAN a podmnožiny

neers) a podskupinou této podskupiny jsou sítě s  nálepkou vzájemné kompatibility Wi-Fi (Wireless Fidelity). Vztah mezi těmito skupinami Technologie Internetu, základní pojmy a principy – 101

zobrazuje následující obrázek. Vzhledem k použitým frekvencím se rádiové vlny téměř neohýbají. Energie rádiových vln mezi dvěma anténami se šíří v  prostorovém útvaru elipsoidu - Fresnelově zóně. 90 % energie se šíří v první Fresnelově zóně. Maximální poloměr první Fresnelovy zóny (uprostřed mezi anténami) lze vypočítat dle vztahu:

, kde je maximální poloměr první Fresnelovy zóny [m], D je vzdálenost mezi je frekvence [GHz]. anténami [km] a Poloměr první Fresnelovy zóny v libovolné vzdálenosti mezi anténami lze vypočítat ze vztahu:

, kde je poloměr první Fresnelovy zóny [m], je vlnová délka [m], d1 a d2 jsou vzdálenosti místa, pro které počítáme poloměr , kde od antén [m], pro které platí, že D je vzdálenost mezi anténami [km] jako v první rovnici. Pro úspěšnou komunikaci je třeba zajistit, aby první Fresnelova zóna nezasahovala pod povrch země a v  zóně se nevyskytovaly žádné předměty pohlcující nebo odrážející rádiové vlny – stavby, stromy, dopravní prostředky atd. Pokud není možné mezi anténami zajistit přímou viditelnost (v první Fresnelově zóně jsou např. železobetonové budovy), je nutné provést pasivní nebo 102 – Vybrané aspekty návrhu webových informačních systémů

aktivní retranslaci.

Přístupové metody LAN V současné době se u kancelářských LAN používají dvě přístupové varianty náhodného přístupu s příposlechem nosné CSMA (Carrier Sense Multiple Access). Varianta CD (Collission Detection) a varianta CA (Collission Avoidance). U obou variant posloucháme co se děje na společném komunikačním kanálu - CS (Carrier Sense), když je kanál volný, zahájíme vysílání dat. Problém je se vzdálenými stanicemi, které mohou zahájit

Obr. 6-9: Přístupové metody CSMA

vysílání současně v domnění, že je komunikační kanál volný. Odlišně se obě varianty chovají, pokud stanice, která má data k vysílání zjistí, že je komunikační kanál obsazený. Varianta CSMA/CD Pokud je po stanovenou dobu kanál volný zaháTechnologie Internetu, základní pojmy a principy – 103

jí stanice vysílání. Po detekci nosné stanice čeká, až právě vysílající stanice odvysílá data (prakticky nosnou testuje periodicky s pevně stanovenou délkou intervalu) a pak zahájí bezprostředně po uplynutí mezirámcové mezery vysílání (LAN Ethernet). Během vysílání porovnává vysílaná data s daty na komunikačním kanále. V případě detekce kolize, ukončí okamžitě vysílání a vyšle kolizní posloupnost - „jam“ k urychlení reakce sítě na kolizi. Po obdržení jamu se stanice odmlčí na náhodně stanovenou dobu. Odmlčí se analogicky i stanice, která jam vyslala. Varianta CSMA/CA Vzhledem k poloduplexnímu provozu rádiových rozhraní nemůže stanice vysílat a zároveň přijímat data k detekci kolize jako u metody CD. Je-li po stanovenou dobu kanál volný, zahájí stanice vysílání. Při bezchybném přijetí dat cílová stanice bezprostředně zašle potvrzení přijetí dat. Při neúspěšném pokusu o odvysílání (nedojde potvrzení o přijetí dat) stanice čeká náhodně stanovenou dobu, než začne opět testovat komunikační kanál. Po detekci nosné vzdá opět stanice pokus o vysílání na náhodně stanovenou dobu.

Normování počítačových sítí K  standardizaci počítačových sítí složí model OSI (Open System Interconection) organizace ISO (International Standards Organization) a doporučení 802 organizace IEEE. Model OSI/ISO 104 – Vybrané aspekty návrhu webových informačních systémů

Obr. 6-10: Model OSI

Tento sedmivrstvý model se v  praxi příliš neujal a slouží dnes především výukovým účelům. Doporučení IEEE 802 Doporučení IEEE 802 se na rozdíl od modelu OSI/ ISO v praxi uchytily a za krátkou dobu je výrobci převzaly jako průmyslové standardy. Základní skupina 802 (vznikla v  únoru 1980) popisující počítačové sítě se rozdělila do podskupin, řešících dílčí problematiku počítačových sítí např. podskupina 11. (802.11) řeší standardizaci bezdrátových LAN a MAN.

Síťové protokoly S rozšířením Internetu po celé zeměkouli vytlačil protokol TCP/IP (Transmission Control Protocol/Internet Protocol) bohužel i dokonalejší konkurenční protokoly např. IPX/SPX (Internet Packet Exchange/Sequenced Packet Exchange) a stal se nejrozšířenějším protokolem i v LAN. Technologie Internetu, základní pojmy a principy – 105

TCP/IP protokol Správně bychom měli mluvit o rodině protokolů TCP/IP, nikoliv jen o protokolu TCP a IP. Korelace mezi vrstvami modelu TCP/IP

modelu

Obr. 6-11: Model OSI a TCP/IP

OSI/ISO je znázorněna na následujícím obrázku. Zařazení jednotlivých protokolů z rodiny protokolů TCP/IP do vrstev modelu TCP/IP je uvedeno v následujících textu. Síťová vrstva • ARP (Address Resolution Protocol): k IP adrese získá MAC (Media Access Control) adresu síťového rozhraní, uchovává je v ARP cache (např. u Microsoft Windows 2 minuty, po opakovaném přístupu během 2 minut se interval zvyšuje na 10 minut). 106 – Vybrané aspekty návrhu webových informačních systémů

• RARP (Reverse ARP): opak ARP. Z MAC adresy síťového rozhraní získá IP adresu síťového rozhraní. • IP (Internet Protocol): datagramová nespojovaná, nepotvrzovaná služba. • ICMP (Internet Control Message Protocol): umožňuje směrovačům posílat chybové a řídící zprávy ostatním směrovačům i počítačům, je součástí protokolu IP. • IGMP (Internet Group Management Protocol): umožňuje skupinové adresování počítačů na úrovni Síťové vrstvy, je součástí IP • BootP (Boot Protocol): slouží k získání vlastní IP adresy a dalších informací, nutných pro práci v síti. • DHCP (Dynamic Host Configuration Protocol): totéž i dynamicky. • RIP, RIP2 (Routing Information Protocol): interní směrovací protokol směrovačů pracující algoritmem DVA (Distance Vector Algoritmus). • OSPF (Open Shortest Path First): totéž, na rozdíl od RIPu používá algoritmus LSA (Link State Algoritmus). • BGP (Border Gateway Protocol): externí směrovací protokol mezi autonomními systémy. Transportní vrstva • TCP (Transmission Control Protocol): spojovaná, potvrzovaná služba. • UDP (User Datagram Protocol): nespojovaná, nepotvrzovaná služba. Aplikační vrstva • SMTP (Simple Mail Transfer Protocol): odesílání elektronické pošty. Technologie Internetu, základní pojmy a principy – 107

• POP3/IMAP4 (Post Office Protocol/Internet Message Access Protocol): příjem elektronické pošty. • FTP (File Transfer Protocol): protokol pro přenos souborů mezi počítači pomocí počítačové sítě. • TFTP (Trivial FTP): jednoduchý protokol pro přenos souborů mezi počítači pomocí počítačové sítě, zavádění OS do bezdiskových stanic ze serveru, záloha konfigurace aktivních síťových prvků. • HTTP(S) (Hypertext Transfer Protocol (Secure)): přenos hypertextových stránek WWW (World Wide Web). • Telnet (Telecommunications Network): síťový virtuální terminál. • DNS (Domain Name Service): převod doménových jmen na IP adresy a naopak. • SNMP (Simple Network Management Protocol): vzdálení zpráva síťových prostředků. • NTP (Network Time Protocol): robustní synchronizace času mezi počítači. • LDAP (Lightweight Directory Access Protocol): přístup k datům na adresářovém serveru, např. vzdálený přístup do NDS (Novell Directory Services) Novellu.

LAN Ethernet Ethernet byl původně určen jen pro LAN, dnes je nasazen v MAN i WAN. Jedná se o soustředěnou síť pokrývající HW 1. a SW 2. vrstvu (podvrstvu MAC) modelu OSI, s přístupovou metodou CDMA/ CD. Běžné přenosové rychlosti jsou 10 Mb/s, 100 Mb/s, 1 Gb/s a 10 Gb/. V současné době je možné použít i rychlosti 40 a 100 Gb/s. Ethernet pou108 – Vybrané aspekty návrhu webových informačních systémů

žívá pro přenos dat nestíněnou a stíněnou dvojlinku nebo optické vlákno. Používá se fyzická topologie hvězda nebo strom, dříve i sběrnice. Logická topologie je jediná a to sběrnice. Na fyzické vrstvě jsou použity různé mechanizmy kódování v závislosti na přenosové rychlosti a použitém přenosovém médiu např. kódováni Manchester, 4B/5B a následně MLT-3, PAM, 8B/10B nebo NRZI. Historie Ethernet byl vyvinut společně firmami DEC, Intel a Xerox přijat v roce 1980 standard (DIX Ethernet). DIX předložila návrh podskupině IEEE 802.3, která po úpravách přijala Ethernet v roce 1983 jako standard IEEE 802.3 na bázi CSMA/CD. DIX reagovala na IEEE 802.3 zapracováním části změn od IEEE do DIX Ethernetu. Vznikl Ethernet II, který se ale již dále nevyvíjel. IEEE upravila původní rámec 802.3 v položce Lenght o možnost volby Lenght/Type, čímž umožnila používat tento rámec pod protokolem TCP/IP. Dnes

Obr. 6-12: Rámec IEEE 802.3

je to preferovaný typ rámce. Pro přehlednost uveďme vývoj rámce ještě jednou: DIX Ethernet » IEEE 802.3 » Ethernet II » upravený IEEE 802.3. Formát upraveného rámce IEEE 802.3 je zobrazen na následujícím obrázku. Technologie Internetu, základní pojmy a principy – 109

kde: Lenght/Type < 1536 (600H) = určuje délku části Data, ≥ 1536 (600H) = specifikuje protokol použitý na 3. vrstvě modelu OSI např. IP,

Obr. 6-13: Rámec IEEE 802.3 s identifikací VLAN

ARP a RARP. Pro VLAN (Virtual LAN) dle IEEE 802.1Q byly přidány 4 Bajty - tzv. tag, sloužící k  identifikaci virtuální lokální sítě při přenosu dat více VLAN přes jedno (trunkové vedení) mezi přepínači nebo mezi přepínačem a směrovačem. Přenosová rychlost Novější síťová rozhraní mají vestavěnu autodetekci maximální přenosové rychlosti. Pokud je autodetekce vypnuta, je nutné tyto parametry na navzájem propojených síťových rozhraních nastavit shodně. V případě, že autodetekce zmíněných parametrů selže, je vhodné na jednom síťovém rozhraní tuto autodetekci ponechat aktivní, zatímco na druhém síťovém rozhraní parametry nastavit ručně. Poloduplexní a plně duplexní provoz na kroucené dvojlince Starší síťová rozhraní neumožňovala pracovat v plně duplexním režimu. Z tohoto důvodu novější sítová rozhraní mají zabudovánu autodetekci tohoto parametru, popřípadě je možné tento parametr u nich nastavit ručně pro případ komu110 – Vybrané aspekty návrhu webových informačních systémů

nikace se starším síťovými rozhraními umožňujícím  jen poloduplexní typ provozu. O případné nutnosti vypnutí autodetekce tohoto parametru na jednom síťovém rozhraní platí totéž co v kapitole 7.2. Pozn.: u verze Etherneru na koaxiálním kabelu musela všechna síťová rozhraní pracovat v poloduplexním režimu vzhledem k jednomu společnému komunikačnímu kanálu. Křížení párů kroucené dvojlinky V současné době vzhledem k autodetekci křížení na síťových rozhraních není třeba tuto problematiku řešit a je tím pádem možné použít nekřížené zapojení kabelů. U starších síťových rozhraní bez autodetekce byla rozdělena síťová rozhraní do dvou skupin. V skupině 1 byl směrovač a PC, ve skupině 2 pak opakovač, rozbočovač, most a přepínač. K propojení mezi zařízení patřící do stejné skupiny sloužil křížený kabel, k propojení zařízení mezi skupinami kabel přímý (nekřížený). Optické spoje Ethernet je možné provozovat na jednovidových i vícevidových optických vláknech, většinou pomocí dvou vláken v  simplexním provozu. Přes jedno vlákno je možné paralerně přenášet jedním směrem i vícenásobná data na více vlnových délkách pomocí technologie WDM (Wavelength Division Multiplexing). Pomocí optických cirkulátorů je možný plně duplexní provoz na jednom vlákně.

Propojování počítačových sítí Se vznikem PC se podstatně zvýšil tlak na výrobce zařízení propojující jednotlivé LAN mezi sebou do větších celků nebo části jedné LAN Technologie Internetu, základní pojmy a principy – 111

navzájem. Než si popíšeme základní propojovací prvky sítí, definujme si Kolizní a Broadcastovou doménu. Kolizní doména Kolizní doména je část sítě, v které se šíří signál vyslaný síťovým rozhraním. V této části sítě může dojít ke kolizi se signálem vyslaným jiným síťovým rozhraním. Kolizní domény oddělují např. mosty (bridge), L2, L3 a L4 přepínače (switche) a směrovače (routery), tedy zařízení pracující na 2. a vyšší vrstvě modelu OSI. U Ethernetu může docházet ke kolizím u starých sítí s koaxiálním kabelem a v sítích s kroucenou dvojlinkou při použití rozbočovačů (hubů). Kolize u Ethernetu byly odstraněny nasazením kroucené dvojlinky s  přepínači a plně duplexním provozem všech síťových rozhraní. Z tohoto důvodu již nebyla přístupová metoda CSMA/CD u přenosových rychlostí 10 Gb/s a vyšších implementována. Broadcastová doména Broadcastová (všesměrová) doména je část sítě, v které se šíří rámec s MAC broadcastovou (všeobecnou) adresou. U Ethernetu je to adresa s  hodnotou FF-FF-FF-FF-FF-FFH, tedy adresu s binárními jedničkami na všech pozicích adresy. Broadcastové domény oddělují např. směrovače a L3 a L4 přepínače, tedy zařízení pracující na 3. a vyšší vrstvě modelu OSI. Zařízení sloužící k  propojování počítačových sítí Dle toho, na které vrstvě modelu OSI dochází k přenosu dat, dělíme propojovací zařízení: 112 – Vybrané aspekty návrhu webových informačních systémů

• Na 1. vrstvě: opakovače (repeatery), rozbočovače • Na 2. vrstvě: mosty a L2 přepínače • Na 3. vrstvě: směrovače a L3 přepínače • na 7. vrstvě: brány (gatewaye) bez udání úrovně • A obecně na N-té vrstvě: brány úrovně N, tedy např. směrovač je brána úrovně 3.

Technologie Internetu, základní pojmy a principy – 113

Teoretické principy přístupu k internetové síti Karel Vlček

7

Kapitola navazuje na výsledky a závěry publikované v [43], které se týkají dalšího využití techniky iterativního dekódování. Tento postup dekódování kódů s velkou minimální kódovou vzdáleností (řetězených kódů, k nimž patří i turbo kódy) otevřel cestu k novému využití: pro eliminaci nelinearit přenosového kanálu. Touto cestou je dosahováno další přiblížení se k teoretickému limitu, který popisuje druhá Shannonova věta. Rostoucí požadavky multimediálních telekomunikačních služeb si vynucují rychlosti přenosu dosahující 100Gbit/s. Při takových rychlostech přenosu informace je již i komunikace po optických vláknech zatěžována nelinearitami. Uplatňuje se zde polarizace a chromatická disperze. Ke zmírnění těchto vlivů na informační obsah zpráv mohou pomoci kódované modulace s  vysoce účinnými řetězenými kódy a následně iterativní metody používané při ekvalizaci symbolů zprávy. Numerické metody řešení diferenčních rovnic vycházejí ze široké nabídky metod zpracování číslicových signálů a digitální modulace. Metoda ekvalizace aplikovaná při příjmu zahrnuje odpovídající techniky zpracování číslicového signálu včetně číslicové filtrace. Cílem textu je analyzovat zlepšování vlastností komunikace na úrovni fyzické vrstvy.

Zlepšení vyhodnocování přijaté zprávy je založeno na zvětšení kódové vzdálenosti a tím i poměru nazývaného kódový zisk. Toho je možné dosáhnout řetězením kódů (a jejich iterativním dekódováním). Řetězením kódů je dosaženo dostatečně velké kódové vzdálenosti symbolů v kódové zprávě. Signál nese informaci, která je použitelná při  přenosu zprávy kanálem, jehož popis je proměnlivý v čase. Signál, který zprostředkovává přenos zprávy je popsán relací: . Zmíněný model kanálu popisuje přenosová funkce: . Tento popis modelovaného kanálu bude, při vhodné volbě koeficientů přenosové funkce, odpovídat vlastnostem kanálu s mnohacestným šířením nebo kanálu s omezeným kmitočtovým pásmem. Přijatý signál je pak popsán relací: (1) Různé přístupy k řešení zahrnují několik principů [45]: 1. Lineární ekvalizace s  pevně nastaveným filtrem tak, že „vypadá“ co . Ekvanejvíce jako přenášený signál lizační filtr může být navržený: jako „zero forcing“, který potlačuje vše, co se dostalo do signálu následkem interference, nebo s  kriteriem minimalizace kvadratické odchylky, který minimalizuje průměrnou energii interference. 2. Ekvalizace na základě zpětné vazby, technika používá rozhodování na základě Teoretické principy přístupu k internetové síti – 115

předchozích hodnot výstupu, které jsou vedeny zpětnou vazbou a ruší vliv kanálu na přijímaný signál. 3. Adaptivní lineární ekvalizace s  rozhodováním zpětnou vazbou, ve které přijímač adaptivně vyhodnocuje koeficienty pro příjem. 4. Ekvalizace na základě MLSE (Maximum Likelihood Sequence Estimation), při níž je kanál považovaný za určený předcházejícími bity, pro dekódování je použit Viterbiho dekódovací algoritmus. 5. Ekvalizace vycházející z MAP (Maximum à posteriori) dekódování, které je podobné MLSE, až na to, že je použit MAP nebo BCJR algoritmus. Poslední dvě metody jsou pochybně optimální, ale mohou být s výpočetními obtížemi spouštěny. 6. Suboptimální varianty a interpolace těchto způsobů řešení ekvalizace představují postupy reagující na skutečnost, že počet stavů roste exponenciálně s délkou L odezvy kanálu. Role, kterou sehrály iterativně řešené dekódovací postupy mohou být shrnuty do následujícího přehledu. V  roce 1993 byly objeveny turbo kódy [45]. V roce 1995 byl princip, který byl vyvinut pro turbo kódy, použit pro ekvalizaci [46]. Autoři formulovali ISI – příjem s mezisymbolovou interferencí – jako problém dekódování turbo kódu s poměrem 1 konvolučního kódu a druhým kódem je kódové zabezpečení. V roce 1997 autoři [47] ukázali, že v turbo ekvalizeru může být použit lineární ekvalizer. Tento objev činí turbo ekvalizaci efektivní, takže může být používána v mnoha aplikací [50]. 116 – Vybrané aspekty návrhu webových informačních systémů

Do nedávné doby vycházela většina prací z  nevysloveného separačního principu: že totiž dekódování kódového zabezpečení pro opravu chyb následovalo po ekvalizaci a detekci. Nicméně, příchod turbo dekódovacího algoritmu vedl k vývoji turbo ekvalizace, v níž se zhoršení kanálu a požadavek opravy chyb i v tomto zhoršeném kanálu podílejí na iterativních postupech.

Rámec pro působení turbo ekvalizace Klíčové pozorování je následující: jestliže kodér ve vysílači je doplněn prokladem, pak se konvoluční vztahy projevují jakoby překračovaly kanál a působí jako druhý konvoluční kodér, takže celkové uspořádání se chová jako sériově řetězený kód s  prokladem. Součástka nazývaná interleaver se přitom nachází mezi komponentními kodéry (constituent encoders). Tato situace umožňuje výslednou sekvenci podrobit iterativnímu dékodování [56]. Obr. 7-1 zobrazuje obecný rámec pro systém, který může být dekódován turbo dekodérem. (V další diskusi bude zdůvodněno, proč je zde jako turbo ekvalizer označeno schéma zařízení přijímače, které provádí ekvalizaci a dekódování jako jeden iterativní proces.) Proklad slouží pro operaci dekorelace mezi hodnotami, takže extrinzická informace je téměř nezávislá na vstupních hodnotách a může být použita jako apriorní informace. V  praxi bude délka prokladu závislá na délce odezvy přenosového kanálu. V turbo dekodéru je odezva kanálu nejdříve zpracována použitím MAP ekvalizeru, který vypočítává informaci o bitech ve formě logaritmu po Teoretické principy přístupu k internetové síti – 117

Obr. 7-1: Skupinové schéma přenosového řetězce s využitím principu turbo ekvalizace

měru pravděpodobností . Prvotní informace je odečtena, zůstávající extrinzická informace, která prošla prokladem přechází do konvolučního dekodéru, je použita jako apriorní informace. Označení ve schématu na Obr. 7-1 „měkký“ konvoluční dekodér odkazuje na proces dekódování, které bylo použito u turbo kódů. Podle toho je pak celý proces ekvalizace označován jako turbo ekvalizace. Výstup dekodéru je pak znovu (jako bit informace) zpracován ve formě logaritmu poměru pravděpodobností . Prvotní informace je následujícím kroku odečtena a výsledek je poslán zpět do ekvalizeru k další iteraci. Všechny prvky ekvalizeru jsou nyní známy, kromě MAP ekvalizeru, který je popsán pomocí příkladu. Předpokládejme, že -násobky bitů objevující se na výstupu konvolučního kodéru, jsou označeny jako , (kde je můžeme považovat za posloup118 – Vybrané aspekty návrhu webových informačních systémů

nost bitů bez ohledu na to, jestli se jedná o bity zprávy nebo zabezpečovací bity). Modulova. Předpokládejme, že kané bity jsou nál má vlastnosti popsané relací podle, ve které popisuje délku, takže přijatý signál může   .  být popsán jako Z tohoto popisu je zřejmé, že podle mřížky, ve které jsou zachyceny stavy kanálu délky  , budou výstup ovlivňovat předcházející bity . Pravděpodobnost zprávy v čase t , kdy na vstupu je

bude prav-

, děpodobnost popsána úvodním stavem v  čase t+1 bude na výstupu kanálu (bez šumu) . Pro stav bílý šum je vyjádřena pravděpodobnostní funkce . Na základě této relace je možné určit pravděpodobnost přechodu, jejíž vyjádření bude použitelné pro MAP algoritmus: . Tento výraz může být zjednodušen např. tím, že je vyjádřený v  logaritmické podobě. Výsledný dekodér pak vypočítává hodnotu logaritmu prav, ze které lze získat hodnoty děpodobnosti pravděpodobnosti extrinzické informace. Typickou hodnotou je zisk několika dB proti ekvalizeru bez použití tohoto výpočetního algoritmu, který tvoří jádro turbo ekvalizeru. Obr. 7-2, převzatý ze zdroje [49], srovnává systém s použitím sériově řetězeného turbo kódu, jehož skupinové schéma je v horní části Teoretické principy přístupu k internetové síti – 119

Obr. 7-2: Skupinová schémata sériového řetězení a principu turbo ekvalizace [49]

obrázku se systémem s turbo ekvalizací, jeho skupinové schéma je ve spodní části obrázku. Vysílací strana zde připravuje zprávu tak, aby vlastnosti kanálu, které zahrnují vlivy ISI (intersymbol interference), mohly být dekódovacím algoritmem sériově řetězených kódů vyhodnoceny. Turbo ekvalizaci tedy můžeme označit za iterativní ekvalizační a dekódovací technika pro přenos kódovaných dat. V digitálních komunikacích se pojmem turbo ekvalizer označuje typ přijímače, který je používán pro příjem zprávy, ve které jsou chyby označované jako mezisymbolová interference ISI (intersymbol interference). Jak vyplývá z předchozího textu, nejedná se pouze o zpracování zprávy na 120 – Vybrané aspekty návrhu webových informačních systémů

straně příjmu, ale vyslaná zpráva musí odpovídat předpokladům, které vytvářejí situaci, která je formálně podobná řetězení kódů, kdy za druhý kodér, ovlivňující vyslanou zprávu je považován přenosový kanál. Turbo ekvalizaci je možné popsat jako iterativní ekvalizační a dekódovací techniku, kterou se dosahuje skutečně mimořádných vlastností komunikačních systémů a přenosu dat komunikačním kanálem, který vyžaduje ekvalizaci, tedy takového komunikačního kanálu, který trpí mezi-symbolovým rušením ISI (Intersymbol Interference). V  tomto textu je vedena diskuse o turbo ekvalizaci, tedy o postupu, který se uplatňuje při přenosu dat ISI kanálem, s důrazem na základní myšlenky a některé praktické podrobnosti. Původní systém uvedený v [52] může být považován za rozšíření dekódovacího algoritmu turbo kódu při zahrnutí jevu, který nastává v ISI kanálu, jako další ochrana proti vzniku chyb, např. jako konvoluční kód s kódovým poměrem 1. Grafické modely turbo kódů a kódů s řídkými maticemi – LDPC (Low Density Parity Check) – kódů, spolu s různými iterativními algoritmy pro jejich dekódování, má zásadní dopad na dramatické zlepšení účinnosti kódových technik [45] – [47]. Pro přehled o grafických modelech kódů připomeňme i práci [47]. Množství výzkumných prací spojených s touto tématikou v posledním desetiletí byl příčinou toho, že bylo vytvořeno mnoho algoritmů pro komunikaci a zpracování signálů, které působily podobným účinkem na široký okruh problémů [49] – [57]. Původní systém uvedený v [46] se stal myšlenkou pro ekvalizaci Teoretické principy přístupu k internetové síti – 121

a dekódování. Snažíme se nalézt náhled na turbo ekvalizační postup s  algoritmickým popisem a intuitivním vysvětlením každého kroku používaného v návrhu takového komunikačního systému.

Obr. 7-3: Část a) popisuje kodér a blok prokladu na vysílací straně a ISI kanál (tučně) pro přenos zprávy. V části b) je uvedeno uspořádání vlastního jádra výpočtu turbo ekvalizace a dekódování přijaté zprávy.

V tomto textu je uveden přehled turbo ekvalizace s důrazem na koncepční uspořádání i na zpoždění způsobené výpočetní náročností (algoritmů), které budou rozebírány v následujícím textu. Výklad se bude soustředit na komunikační spoj. Jeho uspořádání ukazuje Obr. 7-3, v němž je uvedena konfigurace digitálního vysílače jako část komunikačního spoje. Tyto základní části jsou obsaženy v komunikačních systémech jako nedílná součást jak vysílací, tak přijímací strany spoje a jsou zařazeny jako podmínka použití turbo ekvalizace v přijímači. 122 – Vybrané aspekty návrhu webových informačních systémů

Úloha kodéru, který je prvním blokem skupinového schématu na Obr. 7-3), je převést (zakódovat) sekvenci binárních dat do podoby schopné přenosu kanálem, který je zdrojem rušení. Data, která jsou na výstupu kodéru obsahují kromě původních dat také přídavné redundantní informace, které mohou být využité pro ochranu informace ve zprávě, pokud došlo k výskytu chyby v průběhu přenosu. Existuje mnoho prakticky použitelných metod pro výpočet těchto redundantních informací ve formě předpisů pro kódovou ochranu zpráv ECC (Error Control Code). Metoda se uvádí také pod názvem FEC – Forward Error Correction. Kódování provádí kodér konvolučního kódu, který se v praxi pro tento účel používá. Úlohou FEC tedy je chránit data před náhodnými jednobitovými chybami nebo před krátkými shlukovými chybami, které se mohou vyskytnout v datovém toku jako výsledek aditivního šumu, který má původ v přenosovém kanále nebo v přijímači. Aby bylo zajištěno, že se nejedná o dlouhé shlukové chyby, je použit blok prokladu, který zajistí náhodné rozmístění chyb ve zprávě. Proklad je proveden před odesláním zprávy. Tento proces je plně reversibilní a jednoduše realizovatelný i v přijímači. Nakonec jsou permutované bity převedeny do úrovní elektrických signálů, které mohou být modulovány buď v základním pásmu nebo na příslušnou nosnou pro přenos kanálem s pásmovým omezením kmitočtů. Tradiční metody ochrany dat používané v ECC nepracují uspokojivě, pokud přenosový kanál působí zkreslení označované jako ISI (Intersymbol Interference). Pro ekvalizaci jsou zpravidla Teoretické principy přístupu k internetové síti – 123

doporučovány metody používané pro odstraňování nedostatků přenosového kanálu. Dokonce když použité přenosové prostředí není přirozeně rozptylující tedy dispersní, může být prospěšné použít filtrace – tedy úpravy kmitočtového pásma, v prakticky použitém komunikačním systému, kde je ISI se stává ekvalizace nezbytým krokem komplexního řešení. Pozoruhodný účinek turbo kódů se dá vysvětlit tím, že tok informace je potřebný nejenom v jednom směru. Dekódování kódového zabezpečení působí, že se generuje vlastní relativní pravděpodobnost přenášených bitů. Tato „soft“ informace z dekodéru může pak být proložena a vzata v úvahu v ekvalizačním procesu, vytvořením zpětné vazby mezi ekvalizerem a dekodérem, v níž je vzata v úvahu relativní pravděpodobnost každého bitu s ohledem na jeho hodnotu. Tento proces je možné nazvat například „přenos naděje“ nebo „průchodnost zprávy“ a má mnoho důležitých styčných bodů s metodami umělé inteligence, statistického odvozování a teorií grafů. Zpětnovazební struktura, popisovaná zde, je zobrazená na obr. 3 b) a je podstatnou podmínkou uskutečnění turbo ekvalizace. Dekódovací algoritmus je jednoduchý a rychlý jak pro ekvalizer, tak i pro dekodér. Zpětnovazební smyčka má v celém procesu délku dva kroky: ekvalizer informuje dekodér o daném jednotlivém bitu a následně dekodér informuje ekvalizer, že už to ví. Aby se zabránilo krátkým cyklům ve zpětné vazbě a aby nebyla nalézána lokální minima a limitní cykly chování v tomto procesu, je vyhodnocování vztaženo vždy k jinému bitu. 124 – Vybrané aspekty návrhu webových informačních systémů

Vyžaduje to tedy, aby oba procesy byly odděleny blokem prokladu (interleaver) a blokem zpětného prokladu (deinteleaver). Úlohou přijímače je, aby vyhodnotil data, která byla přenesena. Použije k tomu informace o tom, jak je kanál zatížen šumem a také informace o vybavení přenášených dat redundancí, která byla zanesena do dat ve formě kódového zabezpečení ECC (Error Control Code), aby je před šumem ochránila. Zatímco ECC samotné bude chránit data před vlivem (nezávislého) aditivního šumu, bude mezisymbolová interference ISI (Intersymbol Interference) působit tak, jako by docházelo ke vzájemnému ovlivňování jednotlivých symbolů (zprávy), jako by se zaváděla vzájemná závislost mezi symboly. Z důvodu složitosti byly tyto činnosti prováděny odděleně s tím, že docházelo k omezení vzájemného ovlivňování mezi těmito bloky činností. Tím se ovšem podstatně snižovala účinnost těchto činností, které vlastně vzájemně souvisejí. Hlavním přínosem většiny prací o turbo ekvalizaci je jejich proveditelnost v podobě, při níž nejsou oddělenými činnostmi. Výsledkem je tedy překonání rozdílu ve výkonnosti algoritmů prováděných odděleně a algoritmů, které umožňují působení založené na výměně informací při jejich souběžném provádění. Toto optimální spojení činností, které jsme si zvykli chápat odděleně totiž ekvalizace a dekódování tedy přináší překonání této (uměle vytvořené) mezery a možnost přiblížit se tzv. Shannonově limitu. Toto přiblížení umožní v budoucnu doTeoretické principy přístupu k internetové síti – 125

sáhnout hodnoty . Tuto hodnotu známe již dnes, ale dosud nebyla v praxi dosažena. Pro digitální komunikaci, kde je M-ární diskrétní kanál realizován přenosem M-árně modulovaného signálu, lze vyslovit důležitý závěr: Je-li kapacita sdělovacího kanálu menší, než informační rychlost, nelze žádným modulačním způsobem dosáhnout nižší pravděpodobnosti chyby symbolu, než je určitá nenulová hodnota dolní meze. A naopak, nutnou podmínkou snížení pravděpodobnosti chyby symbolu na libovolně malou hodnotu je, aby kapacita kanálu byla větší, než informační rychlost vysílaných symbolů. Přirozeným začátkem pro odvozování v tomto textu je optimální příjem, který může být popsán tím, že je dosahováno minimální hodnoty pravděpodobnosti chyby pro každý bit dat . Je dobře známo, že tohoto stavu je dosaženo na hodnotu , při které je nastavením maximální à posteriorní pravděpodobnost (APP) přijaté posloupnosti y, tedy: (2) Protože binární složky vektorů jsou soustředěné jako bity , je obvyklé pracovat s logaritmicky vyjádřenými poměrnými veličinami log-likelihood ratios (LLRs) spíše než s pravděpodobnostmi. Veličiny LLR jsou pro binární proměnnou veličidefinovány výrazem: nu (3)

126 – Vybrané aspekty návrhu webových informačních systémů

Veličiny LLR obsahují stejné informace jako odpovídající dvě pravděpodobnosti . Jejich poměr, (tedy to zda je větší nebo menší než vyjádřený jako logaritmus) je výhodný proto, že se liší znaménkem. Ve speciálním případě, kdy , bude . Podobně můžeme definovat podmíněné LLR binární veličiny pro danou veličinu : (4) Rozhodovací pravidlo tak může být podle (2) zapsáno jako:

<

(5)

Hlavním problémem při výpočtu MAP zůstává, že výpočet APP je náročný na výpočetní čas, jestliže y je závislé na vstupní posloupnosti datových bitů při definování podle následujícího výrazu: (6) je à priorní pravděpodobPravděpodobnost nost posloupnosti , která může být použita v relaci (6) včetně znalosti zdroje, který vytváří bity . Obvykle jsou bity považovány za nezávislé, to znamená, že společná pravděje vypočítána jako . Popodobnost užitím APP rozkladu ve výrazu (6) a vyjádření dostáváme následující relaci (7): Teoretické principy přístupu k internetové síti – 127

(7)

Veličina je extrinzická informace o poobsažená ve výstupním přijatém y. sloupnosti Je to à priorní informace o . Extrinzická LLR hraje klíčovou roli při vyhodnocování soustavy rovnic turbo ekvalizace. Jestliže bity jsou obvykle považovány za bity s normálním rozdělením, znamená to, že nabývají hodnot 0 nebo 1 tak, že . Jak plyne z (6) přijímač se v praxi málo uplatní, protože musí mít velké délky bloku dat K. Veličina . Ve totiž exponenciálně roste ve výrazu speciálních případech, v nichž paměť použitá při prokladu bude pouze střední velikosti, bude možné uspořádat výpočty tak, aby byly účinnější. Uvažujme dvě různá vyjádření algoritmy při úloze ekvalizace, zejména mřížkové metody a ekvalizační metody založené na lineární filtraci. Typickou úlohou při použití mřížkové metody je řešení detekce symbolů algoritmem MAP [47] a detekce symbolů algoritmem maximum-likelihood (ML) [45]. Detekce symbolů algoritmem MAP jednoduše použije relace (2), přičemž se zanedbává působení kódu. Stanovuje se tedy hodnota 128 – Vybrané aspekty návrhu webových informačních systémů

symbolu z intervalu tak, aby byla maximální à posteriorní pravděpodobnost (APP) . relace Popis mřížkou (Trellis Diagram) odstraňuje slo. Podobný přístup, tožitost výpočtů APP tiž oddělení ekvalizace a dekódování, lze použít, jestliže pracujeme s náhodnými veličinami , které jsou IID (Independent and Identicave výrazu lly Distributed). To znamená, že nabývají hodnot +1 a -1 pro všechna k. Pro odvození efektivního algoritmu pro výzačneme výpočtem pravděpodobnosti, počet se kterou se přenese posloupnost cestou v mřížce obsahující větev popsanou čtveřicí . Tento APP může v čase k, to je být vypočítán efektivně pomocí dopředního/zpětného algoritmu [47], který je založen na vhodném rozkladu společného rozdělení , . Poto je dáno relací sloupnost může být zapsána jako . Použitím pravidla řetězení (chain rule) pro společné pravděna tento výraz, obpodobnosti držíme následující rozklad pro : (8) Výraz

může být vypočítán rekursí:

(9)

Teoretické principy přístupu k internetové síti – 129

s počáteční hodnotou lení stavů v čase k = 0. Výraz vypočítáván rekursí:

při rozděmůže být (10)

s počáteční hodnotou pro všechna Výraz může být dále rozložen na:

. (11)

pravděpodobnost přechodu je nulová jestliže indexový pár není v . Pro páry , které jsou v , je symbol řízen (ovládán) příslušným symbolem a pravděpodobnost je řízena odpovídajícím výstupním symbolem , tedy: (12) , Například výraz ale výraz je nula. Z relace (1) popisua z rozložení šumu jící kanál, tedy plyne, že

Dále

sestavíme

,

tři pravděpodobnosti abychom obdrželi APP

. Vše, co nyní potřebujeme je to, že máme dokončit tuto úlohu sečtením pravděpodob, které odpovíností všech větví APP dají symbolu , tedy: 130 – Vybrané aspekty návrhu webových informačních systémů

(13) Ve srovnání s tím, MAP ekvalizace vystačí s jednoduššími operacemi lineární filtrace na přijatých symbolech, které jsou obvykle aplikovány postupně na podmnožinu z pozorovaných symbolů . Je zde zřejmé zlepšení o 2dB parametru SNR pro případ použití „měkké“ informace. Naneštěstí i nejlepší vyhodnocení (MAP detekce a dekódování symbolů) je stále 7,7 dB vzdáleno od Shannonova limitu -1,6 dB SNR při četnosti chyb BER = 10-5. Nevýrazný nárůst zisku při oddělených činnostech ekvalizace a dekódování je způsobený velkým počtem nezávislých předpokladů při výměně „měkké“ informace. Modelem výpočtu je IID mopracudel. Při detailním výpočtu APP jeme s předpokladem symbolu z množiny všech možných symbolů, kterých je , jako množiny posloupností vektoru , tedy s předpokla. Nicméně dem pravděpodobnosti vektoru existuje pouze platných sekvencí vektoru , z nichž každá přísluší platnému slovu . Ekvalizer tedy vypočítává APP následovně: (14) kde . Při použití tohoto postupu by byl zisk značně lepší, zato výpočet bude mnohem komplikovanější za předpokladu, že bychom nepoužili dopředního/zpětného algoritmu založeného na zobrazení mřížkového diagramu a Teoretické principy přístupu k internetové síti – 131

museli bychom provést úplné vyhledávání. Výkonnost dopředního/zpětného algoritmu může být podstatně zlepšena, je-li k dispozici dobrá à priorní informace. Máme-li tedy dva dopřední/ zpětné algoritmy, jeden pro ekvalizaci a druhý pro dekódování, přirozeně nám napadne, vkládat do zpětné vazby APP hodnoty jednotlivých bitů, které obdržíme jedním dopředním/zpětným algoritmem aplikovaným na výpočet jednotlivých bitů jako apriorní informaci následujícího bitu. Toto je hlavní myšlenka turbo ekvalizace. Musíme zabránit vytvoření příliš silné zpětné vazby. Tento poznatek nás vede k představě extrinzické (nevlastní) a intrinzické (vlastní) informace. Je zřejmé, že podmíněná LLR bitu daná pozorováním se štěpí do extrinzické LLR symbolu obsažené v a intrinzické LLR . Z relace (7) plyne, že není . závislé na V tom případě můžeme použít dopřední/zpětný algoritmus ekvalizace tak, aby výstupy byly popsány stejnou relací, která štěpí do extrinzické informace . Při turbo ekvalia intrinzické informace zaci, jakož i při turbo dekódování obecně, je zpětnou vazbou vedena pouze extrinzická informace. Zavedení intrinzické informace (kte) do zpětné vazby, by vyrá je obsažena v tvořilo kladnou zpětnou vazbu, která by vedla k rychlé konvergenci, ačkoliv výsledek bude zpravidla daleko od globálního optimálního řešení. 132 – Vybrané aspekty návrhu webových informačních systémů

Proto jsou do iterativní smyčky vkládány bloky prokladu (interleavers), obnovovací smyčky pro podporu rozptylování účinků přímé zpětné vazby. Zvláště proto, že dopřední/zpětný algoritmus vytváří výstup, který je vysoce korelovaný s okolím zpracovávaného symbolu. Zatímco tato formulace turbo ekvalizačního algoritmu je založena na dvou dopředních/zpětných algoritmech, jakákoliv dvojice ekvalizačních a dekódovacích algoritmů může těžit z výpočtu „měkké“ informace tím, že tato veličina je základní pro turbo ekvalizer. Jednoduchým

nahrazením

operace jinou operací , ve které je ekvalizační algoritmus, který má přiřazeny přijaté symboly a „měkké“ hodnoty vstupů z dekodéru a převádí je do „měkkých“ hodnot výstupů, aby mohly být zavedeny zpět do dekodéru.

Například lineární MMSE ekvalizer může využít výhody hodnoty apriorní LLR , která je interpretována jako pravděpodobnost přenášeného symbolu . Právě proto, že algoritmus dopřední/zpětné ekvalizace, ve kterém je zabráněno krátkým zpětnovazebním cyklům, jsou výpočty tynení funkcí pické tím, že akceptují, že při stejném indexu . Tato skutečnost je ekvivalentní operace extrakce extrinzické části informace při iterativním procesu. Rovněž poznamenejme, že existuje několik jednodušších způsobů opakovaného odhadu [50]. Teoretické principy přístupu k internetové síti – 133

Turbo ekvalizace přináší spolehlivou dnes již technologicky zvládnutou a poměrně jednoduše realizovatelnou metodu komunikace ISI kanálem [48]. Metoda je úzce spjata s posledními pracemi o turbo kódech, kódech s řídkou kontrolní maticí a iterativními dekódovacími algoritmy. Zřejmý je přínos i v oblasti přenosu zpráv pomocí optických vláknových spojů, které pracují s nejvyššími dosažitelnými rychlostmi přenosu zpráv [51 – 55]. Požadavky služeb multimediálních komunikací ovšem přinášejí stále nové nabídky, například 3D video apod.

134 – Vybrané aspekty návrhu webových informačních systémů

Případová studie internetové aplikace Libuše Svobodovová

8

V současné turbulentní době stále vznikají nové možnosti ve všech oborech. Společnost a prostředí se neustále mění a vyvíjí. V posledních patnácti letech došlo v České republice k masivnímu rozvoji a využívání webových aplikacínejen v podnikové sféře, ale i v běžném životě občanů. Tyto změny se projevily i v oblasti her a simulátorů. Důležitost hraní her a hry samotné však zůstávají. Co se však mění je forma a nástroje, které jsou ke hrám využívány. Dříve byly hrány nejvíce hry face to face. Ty jsou stále více a více hrány na osobních počítačích, v mobilních telefonech, pomocí tabletů či herních konzolí a dalších vyspělých technologií. Jak bude uvedeno dále, hry můžeme různě kategorizovat, např. dle úrovně vzdělání, vstupních znalostí, organizovanosti a vymezeného času na hraní, dle počtu uživatelů, jazykových mutací a další. V  této kapitole se zaměříme především na typ her a simulátorů, které mají za cíl vzdělávat v  oblasti financí a k  jejichž hraní využíváme webové aplikace. Konkrétně se budeme věnovat aplikacím z  investiční oblasti, tedy investování do cenných papírů, komodit, indexů či obchodování s měnami. Vzhledem k neustálému vývoji na finančních trzích využívají zkušenější investoři k monitorování vývoje i tablety a mobilní telefony. Pro ty, kteří s obchodováním teprve začínají, jsou informace přehlednější na počítačích, a proto bylo při testování jednot-

livých aplikací využíváno počítačů.

Aktivizace, motivace a konstruktivismus Pomocí aktivního přístupu při investování bývají investoři často motivováni k získání dalších informací a ke zkoušení různých variant investování. Aktivizace a motivace jsou jednou z nejdůležitějších složek vzdělávání a získávání znalostí a schopností. Jednou z možností aktivizace může být i hraní her, které mají za cíl vytvářet radost či působit relaxačně, ale také rozvíjet a vzdělávat. Tak, jak se vyvíjela společnost a jak se mění globální svět, se vyvíjí i hry. Zatímco počítače byly vyvinuty pro potřeby armády, jejich role a možnosti se stále rozrůstají a vývoj technologií zasáhl i do oblasti her. Smyslem vývoje počítačových her tak není pouze zábava a vzdělávání, ale i demonstrace technických možností doby. Počítačové hry a simulátory mohou pozitivně stimulovat různé lidské schopnosti a osobnostní rozvoj. Tak jako většina věcí však mají své klady i zápory. Pozitiva v sobě skrývají rozvoj představivosti, logického uvažování, matematických, strategických, ekonomických a dalších schopností. Mezi výhody můžeme také řadit používání v domácí přípravě na výuku, obsah motivačních prvků či např. umožnění aktivní práce hráčů s informacemi. Negativy pak mohou být závislost na počítačových hrách, odtržení od reality a uzavření se, zhoršení komunikačních schopností face to face, agresivita a další. Hraní her často zvyšuje motivaci k pochopení složitější problematiky, pomáhají lépe zafixovat znalosti a podporují rozhodovací procesy. Hráči poté často touží poznat více a více v dané oblasti, 136 – Vybrané aspekty návrhu webových informačních systémů

aby dosáhli kýžené mety. Sami poté často dobrovolně sledují danou oblast a pronikají hlouběji k jednotlivým tématům. Nejen skvělé výsledky, ale naopak i ty špatné a prohry vedou k dalšímu poznávání. Některé mohou sice odradit, ale mnohem častěji motivují k tomu, aby hráči získali lepší výsledky. Hry a simulátory mohou být využívány při vzdělávání ve školách, ale i při sebevzdělávání a při volnočasových aktivitách. S hraním her a výukovým software se tak můžeme setkat nejen ve školních lavicích, ale stále častěji i mimo školu a i u stále mladších jedinců. Podle toho, pro jakou cílovou skupinu jsou určeny, zahrnují více či méně vzdělávacích prvků. Zatímco malé děti mohou nalézt zábavu a rozvoj jejich osobnosti v dominu či v pexesu, děti základní školy v plnění úkolů, které je např. posunou do vyššího levelu ke složitějším úlohám, studenti středních či vysokých škol v  řešení složitějších úloh a situací. Hry mohou být využívány i při rozvoji a vzdělávání či při odpočinku dospělých. K  tomu mohou sloužit různé simulátory či trenažéry a i hry, kde se např. střílí, mohou přinést svůj užitek. Jak bylo uvedeno v Úvodu, v této kapitole se zaměříme na webové aplikace, které simulují investování do cenných papírů, komodit, indexů či obchodování s měnami. Investoři mohou díky simulovanému prostředí, které kopíruje to reálné, pochopit základní vazby, na kterých stojí principy ekonomiky a investování. Přínosným bývá i zkoušení různých možností, které by člověk v reálném investování nevyzkoušel, protože by nepodstupoval takové riziko. Díky fiktivním penězům, které má uživaPřípadová studie internetové aplikace - 137

tel k dispozici, může vyzkoušet různé varianty investování bez obav o ztrátu skutečných peněz. Při vzdělávání a hraní investičních her jsou obvykle používány prvky konstruktivismu. Je podněcována aktivita, je pracováno s předchozími zkušenostmi, je uplatňováno zkušenostní učení a je zajištěno propojení s praxí. Dále jsou používány heuristické metody (např. pokus a omyl), je uplatňován princip postupné podpory a samostatná práce. V neposlední řadě jsou rozvíjeny kooperativní formy učení, jsou podpořena myšlení investorů problémovým zadáním a často je používána i diskuse. Jsou podporovány primární zdroje a jsou rozvíjena rozmanitá hlediska. V neposlední řadě je podporována i reflexe procesu učení a je pracováno s chybou, díky čemuž se mohou investoři lépe rozvíjet.

Kategorizace počítačových investičních her a simulátorů Volba vhodné didaktické počítačové hry či simulátoru v sobě skrývá jak volbu výukového cíle, kterého má být při vzdělávání dosaženo, tak věk a úroveň psychického vývoje hráčů či např. schopnosti vyučujícího integrovat hry do výuky či volného času či podmínky realizace, pod kterými se skrývá potřebné HW a SW vybavení a další. Existuje velká škála kritérií, podle kterých můžeme kategorizovat počítačové hry. Níže jsou uvedeny ty nejpodstatnější pro investiční hry a simulátory.

138 – Vybrané aspekty návrhu webových informačních systémů

Dle úrovně vzdělávání: • Střední školy • Vysoké školy • Celoživotní vzdělávání Dle vstupních znalostí: • Stačí základní znalosti • Jsou vyžadovány hlubší znalosti z dané problematiky Dle organizovanosti vzdělávání: • Výuka ve škole • Samostudium Dle dostupnosti internetu a potřeby instalace dalších aplikací: • On-line, přímo ve webovém prohlížeči • Je třeba nainstalovat program, který je propojen s on-line verzí Dle vymezeného času na hraní: • Možno spustit kdykoliv bez návaznosti na další skutečnosti • Předem vymezený čas (např. různé soutěže) Dle počtu uživatelů: • Pro jednoho hráče • Pro více hráčů Dle jazykových mutací: • Jednojazyčné • Vícejazyčné

Případová studie internetové aplikace - 139

Dle složitosti prostředí: • Rychlé, jednoduché a intuitivní pochopení • Složité ovládání a proniknutí do všech možností Aplikace nebudou porovnávány dle finanční náročnosti, protože jsou všechny zdarma. I přesto, že se ve všech případech jedná o zkušební verze, vše vypadá jako reálné. V neposlední řadě nebylo porovnáváno poskytování zpětné vazby, protože u všech investic je přehledně zobrazen jejich vývoj a jsou přehledně patrné změny hodnoty a naše výsledky.

Vybrané investiční hry a simulátory Na současném trhu (Analýza byla prováděn v roce 2012, pozn. red.)je k dispozici mnoho her, které mohou být využívány k investování do cenných papírů. Do této kapitoly jsou vybrány ty, které jsou nejvíce známy a rozšířeny: • Patria Direct – Stock Market Challenge • Patria Forex • Fio banka + RM systém – Student Broker • Fio banka – e-Broker • Citfin – Investiční online hra • Plus500

Patria Direct - Stock Market Challenge

Od 15. října do 7. prosince 2012 se mohli začínající i zkušení investoři zapojit do sedmého kola soutěže Stock Market Challenge, v níž jde o co nejvyšší zhodnocení portfolia pomocí vlastního brokerského účtu na platformě Stock Trak. Hra je otevírána již čtvrtým rokem – vždy na jaře a na podzim. Někteří investoři se zapo140 – Vybrané aspekty návrhu webových informačních systémů

jují více kol po sobě a snaží se využít jejich znalosti z kol předchozích. Výherci soutěže se mohou stát pouze studenti vysokých škol v České republice. Při registraci však ke kontrole nedochází, a tak si investování a soutěžení může vyzkoušet i ten, kdo není studentem vysoké školy (tedy studenti středních škol či další). Ti, kteří se nechtějí porovnávat s ostatními či chtějí vyzkoušet investování mimo předem vymezený čas, mohou využít obchodní platformu Patria Forex, která bude popsána v další části. Webová platforma není využívána pouze v České republice, ale i v dalších zemích. Portfolio může být složeno z akcií či z opcí. Investoři na začátku obdrží virtuální částku 100.000 EUR. K dispozici mají obchodování s cennými papíry na burzách v Evropě a v Severní Americe do mnoha akciových titulů a jiných instrumentů v jejich reálných časových cenových poptávkách. V důsledku burzovních pravidel webové stránky zobrazují opožděný odhad ceny po uplynutí 15 – 20 minut, ale příkaz je prováděn v reálném čase nabídky či poptávky. Jak bylo uvedeno výše, jedná se o soutěž, a tak jsou hráči motivováni k co nejlepším výsledkům. „Účelem hry není dosáhnout krátkodobého zisku, ale svědomitě se starat o svěřené prostředky po dobu dvou měsíců. Vítězem soutěže je hráč s nejvyšším zhodnocením portfolia na konci hracího období. Vyhrát lze také dílčí ocenění za nejlepší zhodnocení během některého ze 14-denních úseků.“ Hráči mohou neustále hodnotit, jak si vedou jejich akcie či sledovat pokrok oproti ostatním investorům. Jsou zveřejňováni Případová studie internetové aplikace - 141

nejlepší investoři po týdnech, měsících a za celou dobu trvání soutěže. Po 40 dnech se do hry zapojilo takřka 500 investorů. Hra má i svá omezení: Stock Market Challenge chce podporovat racionální způsob investování. Na portfolia fiktivních portfolio manažerů proto kladou následující podmínky: • Hodnota jedné akcie nesmí přesáhnout 25 % hodnoty portfolia • Maximální počet provedených transakcí je 200 za celou dobu hry • Minimální cena akcie pro prodej je 5 EUR • Minimální cena pro prodej na krátko (short sell) je 3 EUR Součástí webové platformy je přehledný herní manuál, kde jsou uvedeny základní informace ke hře, základní tipy k investování, ale i podmínky, které musí hráč splňovat. Vedle herního manuálu jsou k dispozici pravidla, která obsahují základní pojmy z oblasti investování. Investory zde mohou zmást data ke hraní (uvádí registrační období z roku 2011 – tedy od 17. října do 9. prosince 2011). Investorům jsou k dispozici i čtyři modelová portfolia. Do webové platformy je od předchozí verze začleněno i on-line propojení na reálná zpravodajství z trhů Patria Online a na monitoring reálných investičních doporučení. Pro ty, kteří se dříve nesetkali s touto problematikou, mohou nejdříve využít teoretického zázemí v Investiční akademii, kde je řešen úvod do investování, analýza a strategie investice, money management a tipy k investo142 – Vybrané aspekty návrhu webových informačních systémů

vání a další vzdělávací články. Díky tomu si mohou hráči doplnit jejich investiční vzdělání online. Na stránkách nechybí odkazy na semináře, které jsou pro všechny přihlášené účastníky zdarma. Pro ty, kteří se chtějí dozvědět více, je uveden i dostatek odborné literatury. Investování může probíhat jak v jazyce českém, tak je možné kdykoliv přepnout na verzi anglickou. Díky tomu si mohou investoři ověřovat či získávat terminologii i v jazyce anglickém. Prostředí je přehledné a intuitivní. K obchodování je však třeba znát základní terminologii a

Obr. 8-1: Prostředí Stock Market Challenge - seznam otevřených investic

podmínky investování. Tvůrci se snaží sledovat aktuální trendy a potřeby cílové skupiny. Hra je propojena s Facebookem, kde jsou pravidelně Případová studie internetové aplikace - 143

zveřejňovány informace. Nevýhodou této aplikace může být skutečnost, že hra má přesně vymezené časy pro investování, pouze dvakrát v roce na necelé dva měsíce. Společnost Patria Direct připravuje novou webovou aplikaci pro obchodování s  cennými papíry (demo verzi), která bude dostupná pro všechny investory bez jakýchkoliv dalších omezení.

Obr. 8-2: Patria Forex - zobrazení podkladů k nákupu či prodeji

Patria Forex Pro ty, kteří si chtějí zdarma a bez rizika vyzkoušet obchodování s měnovými páry, komoditami a akciovými indexy, slouží moderní obchodní platforma Patria Forex. Po rychlé registraci mohou investoři využívat demo účet po dobu 30 144 – Vybrané aspekty návrhu webových informačních systémů

dní s 50.000 USD. Při každém spouštění aplikace je možnost spustit demo či „real“ verzi. Obchodní platforma může být využívána na PC, v chytrých mobilních telefonech i v tabletech. Před začátkem užívání je třeba nainstalovat aplikaci do počítače, mobilního telefonu či tabletu. Při ztrátě internetového spojení nelze obchody uskutečňovat. Uživatel si může vybrat dvě verze – českou a anglickou. V aplikaci je patrné, že lze nainstalovat i jiné jazyky. Může tak být využívána v sedmnácti jazykových mutacích. Nedílnou součástí webové aplikace je i záložka vzdělávání, která obsahuje komplexní informace potřebné k obchodování. Jsou zde zveřejněny semináře, základní terminologie a slovník, ale i velmi detailní studijní materiály, rady pro investory, akademie, přehledný videoprůvodce a odkazy na další odbornou literaturu. Samotné prostředí je přehledné. Obchodování napomáhají i grafy přímo v aplikaci či v propojení na aplikaci Marketscope 2.0, kde lze přímo v grafech také uskutečňovat obchody. Finanční skupina Fio a RM-SYSTÉM, česká burza cenných papírů a.s. - program StudentBroker RM-SYSTÉM, česká burza cenných papírů a Fio, burzovní společnost, největší tuzemský on-line broker připravili studijní interaktivní program, který může být využíván při výuce na českých vysokých školách s ekonomickým zaměřením. Aplikace je přístupná pouze zapojeným školám a jejich studentům. Každá škola má svého adPřípadová studie internetové aplikace - 145

ministrátora (vyučujícího), který může vytvářet skupiny pro studenty a sledovat je. Jeden subjekt může vytvořit i více skupin a sledovat tak aktivitu a výsledky studentů např. dle studijních oborů. Každý student má k dispozici virtuální 1 mil. Kč, který může investovat do českých i zahraničních akcií a v rámci části školního semestru co nejefektivněji budovat své portfolio cenných papírů dle osnov příslušné univerzity. V druhé části investiční platformy je připraveno 50.000 USD, se kterými investoři mohou vyzkoušet obchody s komoditními deriváty US futures. Konkrétními investičními nástroji v aplikaci jsou vybrané české, německé, polské a americké akcie a osm derivátů. Každá hra trvá předem vymezené časové období a investoři jsou mezi sebou srovnáváni – zvlášť dle akcií a dle derivátů. Ve webové aplikaci nechybí ani Manuál a principy aplikace, kde jsou vysvětleny základní podmínky pro přihlášení a zároveň základní podmínky pro investování. Dále jsou v prostředí řešeny FAQ (často řešené otázky). V listopadu 2012 bylo do partnerského programu zařazeno 17 institucí: • Bankovní institut vysoká škola • Česká zemědělská univerzita, Provozně ekonomická fakulta • Jihočeská univerzita v Českých Budějovicích - Ekonomická fakulta • Masarykova univerzita, Ekonomicko-správní fakulta • Mendelova univerzita v Brně • Moravská vysoká škola Olomouc • Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné 146 – Vybrané aspekty návrhu webových informačních systémů

• Technická univerzita v Liberci, Ekonomická fakulta • Univerzita Hradec Králové, Fakulta informatiky a managementu • Univerzita Jana Evangelisty Purkyně v Ústí nad Labem • Univerzita Karlova v Praze (FSV) - Institut ekonomických studií • Univerzita Pardubice, Fakulta ekonomic-

Obr. 8-3: Prostředí Student broker - nákup akcií

ko-správní • Univerzita Tomáše Bati ve Zlíně, Fakulta managementu a ekonomiky • Vysoká škola báňská - Technická univerzita Ostrava • Vysoká škola ekonomická v Praze, Fakulta podnikohospodářská • Vysoká škola technická a ekonomická v Českých Budějovicích Případová studie internetové aplikace - 147

• Vysoké učení technické v Brně Výhodou aplikace StudentBroker oproti dříve popisované soutěži Stock Market Challenge je snazší sledování studentů a hodnocení jejich úsilí včetně porovnávání výsledků mezi jednotlivými institucemi. V  současné době v  ní však není zapojeno zdaleka tolik investorů, co v uvedené konkurenční soutěži.

Obr. 8-4: e-Broker - ukázka vývoje akcií společnosti ČEZ

Fio - e-Broker Webová aplikace e-Broker umožňuje nákup a prodej akcií, derivátů nebo ETF. Investoři si mohou sestavit vlastní portfolio cenných papírů, které odpovídá jejich nastavené investiční strategii. Nevýhodou je platnost účtu. Aplikaci je možno využívat 30 dní. V demoverzi nelze využívat všechny nástroje, jako při reálném obchodování. V aplikaci lze provádět fiktivní vklady vybraných cenných papírů do portfolia a fiktivní výběry z portfolia. Aplikace je dostupná v pěti jazykových muta148 – Vybrané aspekty návrhu webových informačních systémů

cích (jazyk český, slovenský, anglický, polský a maďarský). Prostředí je přehledné. Při rozhodování o investici mohou napomoci i grafy jednotlivých akcií, popis společnosti a základní informace o jejím vývoji. V prostředí se zobrazují Zprávy, které se týkají aktuálního vývoje společností. Součástí nabídky jsou i vzdělávací semináře po celé republice zdarma. Na stránkách nechybí vysvětlivky pro začátek investování, vysvětlení základních pojmů z oblasti investování i podrobné informace z dané oblasti. Citfin – Investiční hra Investiční hra od společnosti Citfin umožní vyzkoušet schopnosti při investování na devizovém trhu, tedy obchodování s cizími měnami. I přes-

Obr. 8-5: Citfin - portfolio a informace o hře

to, že se jedná o hru, podmínky při obchodování vycházejí z reálných podmínek na trhu. Kotace směnných kurzů jsou skutečné kurzy aktuální v Případová studie internetové aplikace - 149

danou chvíli na devizovém trhu (v rámci zjednodušení používá hra pouze středové kurzy). Ve hře je používán tzv. pákový efekt, který reálně simuluje způsob spekulativních obchodů na devizovém trhu, tzn. k pokrytí obchodu stačí část jeho hodnoty, která má za cíl krýt potenciální ztrátu. Webová aplikace opět sleduje aktuální trendy a je propojena i se sociálními sítěmi Facebook, Twitter a LinkedIn. Výhodou je, že stačí základní znalost z oblasti investic. To však vychází ze zaměření hry – neobchoduje se s akciemi, akciovými indexy, komoditami apod., k čemuž jsou třeba hlubší předchozí znalosti. Díky webové platformě je možno hru spouštět z jakéhokoliv počítače (či mobilního telefonu či tabletu) se spojením na internet. Na začátku obdrží každý hráč fiktivních 200.000 CZK. Daný obnos může libovolně investovat do nabízených měn v aktuálním kurzu na libovolně dlouhou dobu. Hra tedy nemá žádné časové omezení. Hra může být ukončena dvěma způsoby. Hráč může hru ukončit sám či druhou variantou pro ukončení hry je záporný zůstatek na účtu. Nedílnou součástí je i nápověda, kde jsou uvedeny základní pokyny k investování při obchodování s měnami. Novinkou je možnost soutěžení ve skupinách, kdy hráči mohou vytvořit vlastní skupinu a v rámci ní mezi sebou soutěžit o co nejlepší výsledky. I bez zařazení do skupiny lze přes nástroj Statistiky sledovat rentabilitu investic za námi zadaná časová období za všechny hráče. K 23.11.2012 je spuštěno 1.132 aktivních her. Plus500 150 – Vybrané aspekty návrhu webových informačních systémů

Obchodování na platformě může být prováděno buď pomocí webové aplikace či je umožněno stáhnout bezplatný software, který je s internetem propojen. K investování je třeba zaregistrovat se a otevřít si účet. Dále je možno začít obchodovat s 300.000 CZK demo penězi. Webová aplikace umožnuje nastavení třiceti sedmi jazyků.

Obr. 8-6: Plus500 – vývoj společnosti G. Electric a informace k demo účtu

Investice mohou být velmi rozmanité. Možnostmi pro investování jsou: • Měny (forex hlavní, hlavní II, vedlejší) • Komodity (ropa, zlato, zemní plyn, stříbro, měď, topný olej a další) • Indexy (Česká 15, USA 30, Řecko 20, Evropa 50, Itálie 40, Německo 30 a další) • Akcie (populární, české, dále seřazeno dle zemí) Jedná se tedy o jedno z nejkomplexnějších proPřípadová studie internetové aplikace - 151

středí pro vyzkoušení obchodování. Pro demo účet není stanoven časový limit pro investování. Všechno je stejné jako za skutečných obchodních podmínek. V demo účtu je možno kdykoliv přepnout na skutečné peníze a přejít na reálné obchodování. Investoři mohou vyzkoušet nastavení, kontrolu a mohou simulovat obchodní strategie včetně pákového obchodování. K dispozici je možno kdykoliv využít online nápovědu a podpůrný tým. Jak bylo uvedeno dříve, nejedná se o komplexní výčet všech dostupných simulátorů v českém jaTab. 8-1: Celkové srovnání aplikací, část I.

Stock Market Patria Forex Challenge

Student Broker

Úroveň vzdělávání

Vysoké školy Střední školy

Vysoké školy

Organi­ zovanost vzdělávání a počet uživatelů

Soutěž

Samostudium

Soutěž

Dostupnost internetu

On-line verze

Stáhnutí aplikace

On-line verze

Vstupní znalosti

Vhodné znát Vhodné znát základní základní terminologii terminologii

Vhodné znát základní terminologii

Jazykové mutace

Český a an- 17 jazyků glický jazyk včetně českého

Český jazyk

Sociální sítě

Ano

Ne

Ne

Složitost prostředí

Přehledné a intuitivní, ale více možností

Přehledné a intuitivní, ale mnoho možností

Přehledné a intuitivní, ale mnoho možností

152 – Vybrané aspekty návrhu webových informačních systémů

Tab. 8-2: Celkové srovnání aplikací, část II.

e-Broker

Citfin

Plus500

Úroveň vzdělávání

Střední školy

Střední školy

Střední školy

Organi­ zovanost vzdělávání a počet uživatelů

Samostudium

Samostudium i možnost soutěže

Samostudium

Dostupnost internetu

On-line verze

On-line verze

On-line verze, možno stáhnout aplikaci

Vstupní znalosti

Vhodné znát základní terminologii

Nejsou třeba velké předchozí znalosti

Vhodné znát základní terminologii

Jazykové mutace

5 jazyků včetně českého

Český jazyk

37 jazyků včetně českého

Sociální sítě

Ne

Ano

Ne

Složitost prostředí

Přehledné a intuitivní, ale mnoho možností

Lehké

Přehledné, intuitivní, nejsložitější

zyce. K dispozici je také např. obchodní platforma Brokerjet ProTrader, která je součástí České spořitelny a která je členem bankovní skupiny Erste Group. Další využívanou platformou Případová studie internetové aplikace - 153

je např. aplikace od instituce X-Trade Brokers, která je dostupná kdykoliv či jejich pravidelné soutěže – např. XTB Trading Cup, kdy dochází k  porovnání investorů z  jedenácti evropských zemí či jimi pořádané soutěže pro juniory. Předchozí popisy jednotlivých aplikací pro investování shrnují tabulky Tab. 8-1 a Tab. 8-2.

Shrnutí V kapitole jsme se věnovali aplikacím, které mohou být mnohými vnímány buď jako simulátory nebo jako hry a soutěže. Tyto aplikace napomáhají k lepšímu pochopení teorie, kterou mnozí získávají z dostupné literatury. Při porovnání a popisu byly vybrány ty simulátory, které řeší různé oblasti investování. Dalším hlediskem byl z  důvodu organizování soutěží mezi investory např. čas vymezený pro investování. Vzhledem k  tomu, že Stock Market Challenge a Student Broker jsou určeny studentům vysokých škol a jedná se o soutěže, jsou zařazeny do kategorie pro vysoké školy. U všech ostatních je uvedena střední škola a výše z toho důvodu, že i studenti obchodních akademií či jiného zaměření si mohou chtít vyzkoušet obchodování s cennými papíry. U Investiční hry Citfin může být pomocí nástroje Skupiny také použita soutěž a přihlášení investoři mohou mezi sebou v rámci skupiny soutěžit. Někteří investoři mohou upřednostnit použití cizích jazyků a získání základní terminologie z investiční oblasti. Pouze Investiční hra od instituce Citfin a soutěž Student Broker neobsahují možnost přepnutí do cizího jazyka. Všechny ostatní nabízejí minimálně jazyk an154 – Vybrané aspekty návrhu webových informačních systémů

glický. Aplikace Plus500 umožňuje obchodování v třiceti sedmi jazycích světa. U všech simulátorů je třeba připojení k  internetu. U Patria Forex je třeba stáhnout aplikaci. U Plus500 si může investor vybrat mezi instalací aplikace či webovou platformou. Všechna prostředí jsou intuitivní, přehledná, obsahují grafy a tabulky. Vzhledem ke složitosti obchodování je nejjednodušší Investiční hra od instituce Citfin, protože umožňuje pouze nákup a prodej měn. Všechny ostatní umožňují i investice do akcií či komodit či derivátů či indexů. Z toho důvodu je jejich prostředí složitější a investoři by měli mít předchozí hlubší znalosti z investiční oblasti. Pokud tomu tak není, investoři si mohou postupem pokus x omyl osvojit investování. Znalosti si mohou investoři doplnit i na webových stránkách všech simulátorů, které obsahují studijní materiály, diskuse, aktuální informace z trhů i pozvánky na bezplatné semináře či webináře. Pouze Stock Market Challenge a Investiční hra od Citfin jsou napojeny na sociální sítě. Po provedeném výzkumu a analýze her a simulátorů (Analýza byla prováděna v roce 2012, pozn. red.) lze říci, že máme v českém prostředí dostatečné množství možností, jak bezplatně a bez rizika otestovat naše schopnosti v  investiční oblasti.

Případová studie internetové aplikace - 155

Literatura

1. GIMP.ORG. GIMP-The GNU Image Manipulation Program. Gimp.org [online]. 2012 [cit. 2013-10-31]. Dostupné z: http://www.gimp. org/ 2. CHASTAIN, Sue. Vector and Bitmap Images. About.com [online]. ©2012 [cit. 2012-0930]. Dostupné z: http://graphicssoft.about. com/od/aboutgraphics/a/ 3. BitMapVector [online]. 2013 [cit. 2013-1031]. Dostupné z: bitmapvector.htm 4. INKSCAPE.ORG. Inkscape. Kreslete svobodně. Inkscape.org [online]. ©2012 [cit. 2013-1031]. Dostupné z: http://inkscape.org/ 5. MURRAY, James D. a William VANRYPER. Encyklopedie grafických formátů. Praha: Computer Press, a.s., 1997. ISBN 80-7226-033-2. 6. TIŠNOVSKÝ, Pavel. Seriál Grafický formát GIF-Root.cz. Root.cz [online]. ©1998-2012 [cit. 2013-10-31]. Dostupné z: http://www. root.cz/serialy/graficky-format-gif/ 7. TIŠNOVSKÝ, Pavel. Vektorový grafický formát SVG. Root.cz [online]. ©1998-2012 [cit. 2013-10-31]. Dostupné z: http://www.root.

cz/clanky/vektorovy-graficky-format-svg/ 8. TIŠNOVSKÝ, Pavel. Ztrátová komprese obrazových dat pomocí JPEG. Root.cz [online]. 1998-2012 [cit. 2013-10-31]. Dostupné z: http://www.root.cz/clanky/ztratova-komprese-obrazovych-dat-pomoci-jpeg/ 9. ŽÁRA, J., B. BENEŠ, J. SOCHOR a P. FELKEL. Moderní počítačová grafika. Praha: Computer Press, a.s., 2010. ISBN 80-251-0454-0. 10. SOMMERVILLE, Ian. Software Engineering. Eight Edition. Harlow : Pearson Education Limited, 2007. 824 s. ISBN 978-0-321-31379-9. 11. CONNOLLY, T., BEGG, C., HOLOWCZAK, R. Databáze – Profesionální průvodce tvorbou efektivních databází. Computer Press, 2009. ISBN 978-80-251-2328-7. 12. ELMASRI R. and S. B. NAVATHE. Fundamentals of Database Systems. Addison Wesley, 2000. ISBN 0-8053-1755-4. 13. HERNANDEZ Michael. Návrh databází. Grada, 2005. ISBN 80-247-0900-7. 14. CHMURA, Alan and J. Mark HEUMANN. Logical Data Modeling: What it is and How to do it. Springer, 2004. ISBN 978-0387229508. MANNILA, H. and K. J. RAIHA. The design of 15. relational databases, Addison Wesley, 1994. 16. REINGRUBER, Michael C. and Wiliam W. GRELiteratura – 157

GORY. The Data Modeling Handbook: A Best Practice Approach to Building Quality Data Models. Wiley, 1994. ISBN 978-0471052906. 17. RIORDAN, Rebecca M.: Vytváříme relační databázové aplikace. Computer Press, 2000. ISBN 978-8072263608. 18. ROB, P. and C. CORONEL. Database Systems. Design, Implementation & Management. Thomson Course Technology, 2004. ISBN 0-61921372-8. 19. SCHMIDT, Bob. Data Modeling for Information Professionals. Prentice Hall, 1998. ISBN 978-0130804501. 20. SIMISON, Graeme. C. and Graham. C. WITT. Data Modeling Essentials. 3rd Edition. Morgan Kauffman Publishers, 2005. ISBN 0-12644551-6. 21. WHITTEN, Jeffrey L. and Lonnie D. BENTLEY. Systems Analysis and Design Methods. McGraw-Hill, 2005. ISBN 978-0073052335. 22. SILVERSTON, Len, W. H. INMON and Kent GRAZIANO. The Data Model Resource Book. Wiley, 1997. ISBN 978-471153641. 23. W3C. World Wide Web Consortium [online]. 2012 [cit. 2013-10-31]. Dostupné z: http:// www.w3.org/ WIKIPEDIA. Wikipedie: Otevřená encyklopedie 24. [online]. 2012 [cit. 2013-10-31]. Dostupné 158 – Moderní metody návrhu webového informačního systému

z: http://cs.wikipedia.org/ 25. OWASP. OWASP: The Open Web Application Security Project [online]. 2012 [cit. 201310-31]. Dostupné z: https://www.owasp.org/ 26. OWASP. OWASP: Top 10 2010 [online]. 2010 [cit. 2013-01-31]. Dostupné z: https://www. owasp.org/index.php/Top_10_2010 27. Security-portal.cz [online]. 2012 [cit. 2013-10-31]. Dostupné z: http://security-portal.cz/ 28. VRÁNA, J. PHP triky: Weblog o elegantním programování v PHP pro mírně pokročilé [online]. 2012 [cit. 2013-10-31]. Dostupné z: http://php.vrana.cz/ 29. POKORNÝ, J. Návrh a realizace autentizační metody pro přístup k webové službě v jazyce PHP. Brno, Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, 2010. 47 s. Vedoucí bakalářské práce Ing. Stanislav Uchytil, Ph.D. Dostupné z: http://www.vutbr.cz/www_base/ zav_prace_soubor_verejne.php?file_id=30729 30. ZEMEK, L. Bezpečnost webových aplikací. Praha, Univerzita Tomáše Bati ve Zlíně, Fakulta aplikované informatiky, 2012. 68 s. Vedoucí bakalářské práce doc. Ing. Martin Sysel, Ph.D. Brokerjet Online. Brokerjet [online]. 2013 31. [cit. 2013-10-31]. Dostupné z: https://www. Literatura – 159

brokerjet.cz/products/platforms/protrader/ demo/ 32. PatriaDirect Stock Market Challenge. Patria Forex [online]. 2013 [cit. 2013-10-31]. Dostupné z: http://campuschallenge.stocktrak. com/home.aspx# 33. CitFin. Citfin [online]. 2013 [cit. 201310-31]. Dostupné z: http://www.citfin.cz/ cz/homepage.html 34. Fio banka. Fio banka [online]. 2013 [cit. 2013-10-31]. Dostupné z: http://www.fio.cz/ 35. StudentBroker. Student Broker [online]. 2013 [cit. 2013-10-31]. Dostupné z: http:// www.studentbroker.cz/ 36. Patria Forex. Patria Forex [online]. 2013 [cit. 2013-10-31]. Dostupné z: https://www. patria-forex.cz 37. Webový obchodník Plus500. Plus500 [online]. 2013 [cit. 2013-10-31]. Dostupné z: https://trade.plus500.com/ 38. XTB Online. X-Trade Brokers [online]. 2013 [cit. 2013-10-31]. Dostupné z: http://www. xtb.cz/ 39. SILHAVY, Radek; SILHAVY, Petr; PROKOPOVA, Zdenka. Clustered Requirements in System Engineering Project Estimation. International Journal of Mathematical Models and Methods in Applied Sciences. 2011, 5, 6, s. 160 – Moderní metody návrhu webového informačního systému

1052-1059. ISSN 1998-0140. 40. Zowgi et al. Requirements Elicitation: A Survey of Techniques, Approaches, and Tools, pp. 19-49. ISBN 978-3-540-28244-0 41. Carlshamre P, Karlsson J.A usability-oriented approach to requirements engineering. In: Proceedings of the 2nd International conference on Requirements Engineer-ing, April 15–18, Colorado Springs, CO. 1996 42. CorelDRAW: Tučňák Linux. Grafika.cz - vše o počítačové grafice [online]. 2011, 13.7.2011 [cit. 2013-10-31]. Dostupné z: http://www. grafika.cz/rubriky/software/coreldraw-tucnak-linux-138646cz 43. KETTNER, Jakub. Kódování {--} Turbo kódy [online]. 2010 [cit. 2013-10-31]. Diplomová práce. Tomas Bata University in Zlín, Faculty of Applied Informatics. Vedoucí práce Miloš Krčmář. Dostupné z: . 44. Proakis, J.G.: Digital Communications, McGraw-Hill Series in Electrical Engineering, 2nd Edition, 1989 45. Berrou, C., Glavieux, A., Thitimajshima, P.: Near Shannon limit error correcting coding and decoding: Turbo-codes, in Proc. ICC‘93, pp. 1064-1070, Geneva, May 1993. 46. Douillard, C., Jezequel, M., Berrou, C., et al.: Iterative Correction of IntersymLiteratura – 161

bol Interference: Turbo Equalization, ETT, vol. 6, no. 5, (1995) Koetter, R., Singer, A.C., Tüchler, M.: 47. Turbo Equalization, IEEE Signal Processing Magazine, Jan. (2004), pp. 67 – 80. Lampinen, M., Haikola, V.: HSDPA MIMO Per48. formance with Turbo Equalizer, IEEE PIMRC‚06. 49. Otnes, R., Tüchler, M.: Iterative Channel Estimation for Turbo Equalization of Time-Varying Frequency-Selective Channels, IEEE Transactions on wireless communications, vol. 3, no. 6, November 2004, pp. 1918 – 1923. 50. Tüchler, M., Singer, A. C.: Turbo Equalization: An Overview, IEEE Transactions on Information Theory, vol. 57, no.2 February 2011. 51. Raghavendra, M. V., Prasad, V.: Information Capacity of Direct Detection Fiber-Optic Communication, IEEE Journal Sel. Areas Comm., Optical Comm. and Networks, vol. 26, no. 6, pp. 73 – 83, Aug. 2008. 52. Hellebrand, S., Hanik N.: Polarization-Diversity Turbo-Equalization of Polarization Mode Dispersion, JLT, vol. 25, no. 3 (2007) Djordjevic, I. B.: Mitigatition of Linear 53. and Nonlinear Impairments in High-Speed Optical Networks by Using LDPC-Coded Turbo 162 – Moderní metody návrhu webového informačního systému

Equalization, IEEE J. 2008. 54. Kurorski, B. M, Yamaguchi, K., Kobayashi, K.: On BCJR State Metric Quantization for Turbo Equalization, IEEE J. 2005. 55. Wymeersch, H., Win, M. Z.: Soft Electrical Equalization for Optical Channels, In IEEE Proc. ICC 2008, pp 548-552. 56. Moon, T. K: Error Correcting Coding, J. Wiley & Sons, Inc., ISBN 0-471-64800-0, New Jersey, (2005). 57. Dobeš J., Žalud, V.: Moderní radiotechnika, BEN tech. literatura, ISBN 80-7300-132-2, Praha (2006).

Literatura – 163

164 – Moderní metody návrhu webového informačního systému

www.scientificpress.eu isbn: 978-80-904741-3-0

scientific press