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

Transkript

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
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.
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
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
ř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.
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ý
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
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
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.
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.
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
čí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í.
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.
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
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
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
(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ů:
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…)
•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íč,
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
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é
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
•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
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
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
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é.
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
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.
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
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
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
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ů,
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
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
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]
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,
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]
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]
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.
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
Bezpečnost webových aplikacć – 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.
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.
Bezpečnost webových aplikací – 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ář:
<form method=”POST” action=”./login.php”>
Jméno: <input type=”text” name=”jmeno” id=”jmeno”>
Heslo: <input type=”password” name=”passwd” id=”passwd”>
<input type=”submit” value=”Přihlásit” name=”login”>
</form>
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’
Ú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
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á
Bezpečnost webových aplikací – 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:
<?php echo $_GET[‘jmeno’]; ?>
Ú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.’);</script>
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.’);</script> 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ěBezpečnost webových aplikací – 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.’);</script>
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.’);</script>
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
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řiBezpečnost webových aplika>í – 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,
ž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 HTTBezpečnost webových aplikací – 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
(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.
<img src=”http://www.aplikace.cz/uzivatel.php?akce=del&id=7” >
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.
<body onload=”document.forms[0].submit();”>
<form action=http://www.aplikace.cz/uzivatel.php“
method=“POST“>
… kopie formuláře s předvyplněnýma hodnotama …
</form>
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 proBezpečnost webových aplika>ć – 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é
Bezpečnost webových aplika>í – 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ě,
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
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í.
Bezpečnost webových aplika>ć – 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
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ů
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
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
•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.
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
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
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ů.
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
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
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
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.
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).
•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.
•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.
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
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í:
•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.
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].
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
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
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
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
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.
Ú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
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.
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)
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):
(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
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)
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:
(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
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í.
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].
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.
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,
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.
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
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ě
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
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é
•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
•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
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
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í
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
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.
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.
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
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
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.
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
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: <http://theses.
cz/id/80kg4w/>.
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
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
www.scientificpress.eu
isbn: 978-80-904741-3-0
scientific press

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

Transkript

Podobné dokumenty

PERSONALISTIKA A ŘÍZENÍ

PowerPlus 19 - O.K.SERVIS PLUS s.r.o.

KATALOGG ODBORNÝCH PUBLIKKACÍ NAKLADAATELSTVÍ AANAG

Přehled nástrojů CABE (modelování podniku) na tuzemském trhu

Novinky zahraniční knihovnické literatury

Šablona elektronického učebního textu

Zpravodaj Archa č. 43 *, 4160 kB

openMagazin 4/2009

LTE Advanced

najdete zde - Výuka na FAI UTB ve Zlíně

Uživatelská příručka Návod k použití

Vektorová a rastrová data

CLED PLUS - Polymerační lampa

management znalostí - Personalizace výuky prostřednictvím e

1 Vydávání karet v ČR Na trh bankovních karet působilo v r

Mřížkové kódování

Metodika k modulu 12 - část 2 - Vyšší odborná škola ekonomická a

BTC