Design and Analysis of Sport Information System

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV PO ˇ

C´ITA ˇ

COV ´

YCH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS

N ´

AVRH A ANAL ´

YZA SPORTOVN´IHO INFORMA ˇ

CN´IHO

SYST ´

EMU

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

JAROSLAV STRU ˇ

ZKA

AUTHOR

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV PO ˇ

C´ITA ˇ

COV ´

YCH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS

N ´

AVRH A ANAL ´

YZA SPORTOVN´IHO INFORMA ˇ

CN´IHO

SYST ´

EMU

DESIGN AND ANALYSIS OF SPORT INFORMATION SYSTEM

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

JAROSLAV STRU ˇ

ZKA

AUTHOR

VEDOUC´I PR ´

ACE

Ing. JI ˇ

R´I KRAJ´I ˇ

CEK

SUPERVISOR

Abstrakt

Tato bakal´aˇrsk´a pr´ace obsahuje popis anal´yzy, n´avrhu a n´asledn´e implementace informaˇcn´ıho syst´emu. Informaˇcn´ı syst´em je urˇcena pro z´aznam a zveˇrejˇnov´an´ı v´ysledk˚u z´apas˚u, tabulek skupin, informac´ı o t´ymech, hraˇc´ıch a tren´erech, statistik t´ym˚u a hr´aˇc˚u. Mimo v´ysledk˚u z´apas˚u syst´em eviduje tak´e podrobnˇejˇs´ı ud´alosti v z´apasu jako poˇcet div´ak˚u, autory bra-nek, udˇelen´e karty, proveden´a stˇr´ıd´an´ı a ˇcasy tˇechto ud´alost´ı. D´ale uchov´av´a informace o stadionech, na kter´ych se jednotliv´e z´apasy hraj´ı. Souˇc´ast´ı syst´emu m´a b´yt prvek umˇel´e inteligence. Ten dok´aˇze na z´akladˇe podm´ınek, kter´e popisuj´ı z´apas, pˇriˇradit sestavu roz-hodˇc´ıch k jednotliv´ym z´apas˚um.

Kl´ıˇ

cov´

a slova

Informaˇcn´ı syst´em, datab´aze, Mistrovstv´ı Evropy ve fotbale, ME 2008 ve fotbale, EURO 2008, n´avrh, anal´yza, n´avrhov´e vzory, softwarov´a architektura, diagram tˇrid, diagram pˇr´ıpad˚u uˇzit´ı, sekvenˇcn´ı diagram, diagram nasazen´ı, diagram aktivit, entita, entitn´ı mnoˇzina, atri-but, index, PHP, MySQL, CSS, JavaScript, XHTML, umˇel´a inteligence, administr´ator, uˇzivatelsk´a pr´ava, 3-vrstv´a architekura, MVC

Abstract

This bachelors thesis contains description fo analyze, design and futher implemantation of an information system. Information system is designed for evidence and publish scores of matches, group table, informations about teams, players and coaches, statistics of teams and players. Within the score system stores more detailed information about the game like number of viewers, authors of goals, number of cards, substitutions and times of theese acti-ons. It stores informations about stadiums, where are the matches played. Part of the system is item of artificail intelligence, which links referees to the matches that should by played.

Keywords

Information system, database, European footbal championship, EURO 2008, design, ana-lyze, design paterns, software architekture, class diagram, use case diagram, sequence di-agram, deployment didi-agram, activity didi-agram, entity, atribut, index, PHP, MySQL, CSS, JavaScript, XHTML, artificial inteligence, administrator, users rights, 3-level architecture, MVC

Citace

Jaroslav Struˇzka: N´avrh a anal´yza sportovn´ıho informaˇcn´ıho syst´emu, bakal´aˇrsk´a pr´ace, Brno, FIT VUT v Brnˇe, 2008

N´

avrh a anal´

yza sportovn´ıho informaˇ

cn´ıho syst´

emu

Prohl´

aˇ

sen´ı

Prohlaˇsuji, ˇze jsem tuto bakal´aˇrskou pr´aci vypracoval samostatnˇe pod veden´ım pana Ing. Jiˇr´ıho Kraj´ıˇcka Uvedl jsem vˇsechny liter´arn´ı prameny a publikace, ze kter´ych jsem ˇcerpal.

. . . . Jaroslav Struˇzka

11. kvˇetna 2008

Podˇ

ekov´

an´ı

Dˇekuj´ı panu Ing. Jiˇr´ımu Kraj´ıˇckovi za veden´ı a pomoc pˇri tvorbˇe t´eto bakal´aˇrsk´e pr´ace.

c

Jaroslav Struˇzka, 2008.

Tato pr´ace vznikla jako ˇskoln´ı d´ılo na Vysok´em uˇcen´ı technick´em v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Pr´ace je chr´anˇena autorsk´ym z´akonem a jej´ı uˇzit´ı bez udˇelen´ı opr´avnˇen´ı autorem je nez´akonn´e, s v´yjimkou z´akonem definovan´ych pˇr´ıpad˚u.

Obsah

1 Uvod´ 3

1.1 Struktura pr´ace . . . 4

2 Anal´yza poˇzadavk˚u na syst´em 5 2.1 Popis aplikace . . . 5

2.2 Role uˇzivatel˚u v syst´emu. . . 5

2.3 Anal´yza . . . 6 3 Objektov´y n´avrh 8 3.1 UML . . . 8 3.1.1 Z´akladn´ı pojmy. . . 8 3.1.2 Struktura jazyka . . . 9 3.2 Softwarov´a architektura . . . 11 3.2.1 Popis . . . 11 3.2.2 Typy architektur . . . 12 3.3 N´avrhov´e vzory . . . 13 3.3.1 Popis . . . 13

3.3.2 C´ˇasti n´avrhov´ych vzor˚u . . . 13

3.3.3 Z´akladn´ı rozdˇelen´ı . . . 14

3.4 Literatura . . . 15

4 N´avrh syst´emu 16 4.1 MVC architektura . . . 16 4.2 Diagramy . . . 17 4.2.1 Diagram aktivit. . . 17 4.2.2 Diagram tˇr´ıd . . . 17 4.2.3 Diagram sekvence . . . 18 4.2.4 Diagram komunikace . . . 19 4.2.5 Diagram nasazen´ı. . . 19 4.3 Vlastn´ı n´avrh . . . 19 4.4 Literatura . . . 20 5 Implementace 30 5.1 PHP . . . 30 5.1.1 O PHP . . . 30 5.1.2 Historie . . . 30

5.1.3 V´yhody a Nev´yhody . . . 31

5.3 MySQL . . . 32

5.4 CSS . . . 33

5.5 Pˇrehled syst´emu . . . 34

5.6 Literatura . . . 34

6 Z´avˇer 37 6.1 Splnˇen´ı poˇzadavk˚u zad´an´ı . . . 37

6.2 Srovn´an´ı s ostatn´ımy syst´emy . . . 37

6.3 Rozˇs´ıˇren´ı . . . 37

Kapitola 1

´

Uvod

V dneˇsn´ı dobˇe informaˇcn´ı syst´emy nab´yvaj´ı na v´yznamu. Jsou pouˇz´ıv´any st´ale ve vˇetˇs´ı a vˇetˇs´ı m´ıˇre. A to zejm´ena kv˚uli jejich v´ıcem´enˇe jednoduch´e obsluhovatelnosti, pˇrehlednosti a rozˇs´ıˇritelnosti. Dalˇs´ı nespornou v´yhodou je moˇznost propojit informaˇcn´ı syst´em s da-tab´azov´ym syst´emem, coˇz umoˇzˇnuje firm´am pˇrej´ıt ze sloˇzit´e pap´ırov´e agendy na podstatnˇe jednoduˇsˇs´ı elektronickou. A t´ım uˇsetˇr´ı nejen finanˇcn´ı prostˇredky, ale zejm´ena ˇcas a poˇcet lid´ı potˇrebn´y ke spr´avˇe.

V d˚usledku st´ale ˇcastˇejˇs´ıho uˇz´ıv´an´ı informaˇcn´ıch syst´em˚u se neust´ale zvyˇsuj´ı n´aroky na tvorbu tˇechto syst´em˚u. Je to zp˚usobeno zvl´aˇstˇe t´ım, ˇze jsou uˇzivatel´e zvykl´ı na urˇcit´y typ standardu, kter´y je zaloˇzen na pohodln´e obsluze a snadn´em pochopen´ı pˇri zaˇc´ın´an´ı s t´ımto syst´emem. Dalˇs´ım krit´eriem je jednoduchost zaveden´ı syst´emu do firmy a velice d˚uleˇzit´a je i moˇznost pozdˇejˇs´ıho rozˇs´ıˇren´ı syst´emu podle poˇzadavk˚u uˇzivatele.

Vytvoˇren´ı informaˇcn´ıho syst´emu nen´ı, jak tomu bylo dˇr´ıve v minulosti, jednoduchou z´aleˇzitost´ı. V minulosti byl v´yvoj postaven na Vodop´adov´em modelu. Ten patˇr´ı mezi prvn´ı ucelen´e metodiky v´yvoje. Z´akladn´ı f´aze tohoto modelu jsou definice probl´emu, anal´yza, n´avrh, implementace, testov´an´ı a provoz. Pro souˇcasn´e v´yvojov´e postupy se vˇsak uk´azal jako nepruˇzn´y a pˇr´ıliˇs tˇeˇzkop´adn´y. D´ale nebyla potˇreba pouˇz´ıvat objektovˇe orientovan´y n´avrh, nˇebot’ n´avrhov´e jazyky jako UML a implementaˇcn´ı jazyky tento druh n´avrhu nepod-porovaly, protoˇze byly procedur´aln´ı. Bohuˇzel ´udrˇzba takov´ehoto syst´emu byla noˇcn´ı m˚urou mnoha spr´avc˚u. Dnes je takov´yto pˇr´ıstup k tvorbˇe nemoˇzn´y. Z´akladem vzniku opravdu kvalitn´ıho syst´emu je pouˇzit´ı nov´ych n´avrhov´ych model˚u a v´yvojov´ych model˚u napˇr. agiln´ı v´yvojov´y model nebo testy ˇr´ızen´y v´yvoj.

S tˇemito modely souvis´ı relativnˇe nov´a vˇec, kter´a se na program´atorsk´em poli objevila. Objektovˇe orientovan´e programov´an´ı. Lze ˇr´ıci, ˇze nejprve se formuloval objektov´y jazyk a pozdˇeji pro nˇej vzniklo UML a metody n´avrhu, kter´e jsou mu blizk´e. Pokud se tedy rozhodneme pro implementaci touto metodou, n´avrh se st´av´a ned´ılnou souˇc´ast´ı tvorby syst´em˚u. Jakmile totiˇz v rukou drˇz´ıme diagram tˇr´ıd a sekvenˇcn´ı diagramy, implementace nen´ı sloˇzit´a. V tomto pˇr´ıpadˇe v˚ubec nez´aleˇz´ı na OO jazyku, zvolen´em pro implementaci syst´emu, protoˇze n´avrh napˇr. prosˇrednictv´ym modelovac´ıho jazyka UML je tvoˇren obecnˇe pro vˇsechny OO jazyky.

C´ılem t´eto pr´ace je nastudov´an´ı problematiky souvisej´ıc´ı s n´avrhem a anal´yzou in-formaˇcn´ıho syst´emu se zamˇeˇren´ım na vhodn´e pˇr´ıstupy objektov´eho n´avrhu (softwarov´a architektura, n´avrhov´e vzory, atd.). D´ale analyzovat poˇzadavky sportovn´ıho informaˇcn´ıho syst´emu Mistrovstv´ı Evroby ve fotbale 2008 a pomoc´ı jazyka UML prov´est detailn´ı n´avrh. Dalˇs´ı ˇc´ast´ı pr´ace je podle tohoto n´avrhu dan´y syst´em naimplementovat.

1.1

Struktura pr´

ace

Pr´ace je rozdˇelena do nˇekolika kapitol, v nichˇz jsou postupnˇe pops´any jednotliv´e ˇc´asti tvorby syst´emu.

V n´asleduj´ıc´ı kapitole bude provedena anal´yza syst´emu.

Ve tˇret´ı kapitole se budeme zab´yvat vhodn´ymi pˇr´ıstupy objektov´eho n´avrhu zejm´ena si pov´ıme o jazyku UML, navrhov´ych vzorech apod.

Ve ˇctvrt´e kapitole se zamˇeˇr´ıme podrobnˇeji na tˇr´ıvrstvou architekturu MVC. A bude zde proveden podrobn´y n´avrh syst´emu.

V pat´e kapitole se budeme zab´yvat provedenou implementac´ı. Sezn´am´ıme se s probl´emy, na kter´e bylo v pr˚ubˇehu implementace naraˇzeno.

V z´avˇereˇcn´e kapitole zhodnot´ıme dosaˇzen´e v´ysledky, porovn´ame syst´em s podobn´ymi syst´emy a pokus´ıme se navrhnout dalˇs´ı rozˇs´ıˇren´ı do budoucna.

Kapitola 2

Anal´

yza poˇ

zadavk˚

u na syst´

em

V t´eto ˇc´asti pr´ace se budeme vˇenovat anal´yze poˇzadavk˚u na IS. D´ıky anal´yze jsme schopni zjistit jednotliv´e probl´emy. Zp˚usob jejich ˇreˇsen´ı se provede v dalˇs´ıch kapitol´ach zejm´ena potom v kapitole zamˇeˇren´e na n´avrh.

2.1

Popis aplikace

Aplikace je urˇcena pro z´aznam a zveˇrejˇnov´an´ı v´ysledk˚u z´apas˚u, tabulek skupin, informac´ı o t´ymech (fotografie, seznamy hr´aˇc˚u apod.), hraˇc´ıch (fotografie, osobn´ı informace apod.) a tren´erech (ty sam´e informace jako u hr´aˇce), statistik t´ym˚u (poˇcet odehran´ych z´apas˚u, poˇcet vstˇrelen´ych a obdrˇzen´ych g´ol˚u, pr˚umˇer vstˇrelen´ych a obdrˇzen´ych gol˚u na z´apas) a hr´aˇc˚u (poˇcet odehran´ych minut, poˇcet odehran´ych z´apas˚u, poˇcet vstˇrelen´ych branek, pr˚umˇer vstˇrelen´ych branek na z´apas, poˇcet obdrˇzen´ych karet, pr˚umˇer obdrˇzen´ych karet na z´apas). Mimo v´ysledk˚u z´apas˚u syst´em eviduje tak´e podrobnˇejˇs´ı ud´alosti v z´apasu jako poˇcet div´ak˚u, autory branek, udˇelen´e karty, proveden´a stˇr´ıd´an´ı a ˇcasy tˇechto ud´alost´ı. D´ale uchov´av´a informace o stadionech, na kter´ych se jednotliv´e z´apasy hraj´ı.

Souˇc´ast´ı syst´emu m´a b´yt prvek umˇel´e inteligence. Ten dok´aˇze na z´akladˇe podm´ınek, kter´e popisuj´ı z´apas, pˇriˇradit sestavu rozhodˇc´ıch k jednotliv´ym z´apas˚um.

2.2

Role uˇ

zivatel˚

u v syst´

emu

Aplikace rozliˇsuje 4 druhy rol´ı, jimiˇz jsou administr´atoˇri, editoˇri, registrovan´ı n´avˇstˇevn´ıci a neregistrovan´ı n´avˇstˇevn´ıci. Kaˇzd´y z tˇechto uˇzivatel˚u m´a sv´a pr´ava, kter´a se hierarchicky zvyˇsuj´ı a dˇed´ı, tzn. ˇze uˇzivatel, kter´y je v´yˇse postaven´y m´a stejn´a pr´ava jako jeho pˇredch˚udce a z´ıskav´a dalˇs´ı pr´ava. Posloupnost od uˇzivatele s nejmenˇs´ımi opr´avnˇen´ımi po uˇzivatele s nejvyˇsˇs´ımi opr´avnˇen´ımi je n´asleduj´ıc´ı: neregistrovan´ı n´avˇstˇevn´ıci, registrovan´ı n´avˇstˇevn´ıci, editoˇri a administr´atoˇri.

Neregistrovan´ı n´avˇstˇevn´ıci maj´ı moˇznost prohl´ıˇzet str´anky (napˇr. v´ysledky, podrobnosti ze z´apasu, statistiku hr´aˇce atd.). Dalˇs´ı ˇc´ast syst´emu, do kter´e mohou vstoupit, je regis-trace uˇzivatele. Zde si po vyplnˇen´ı unik´atn´ıho pˇrihlaˇsovac´ıho jm´ena, hesla, jm´ena, pˇr´ıjmen´ı a kontrolniho ˇc´ısla (zabraˇnuje, aby se registrovali tzv. roboti a zahltily tak datab´azi ne-pouˇziteln´ymi daty) vytvoˇr´ı ´uˇcet a z´ıskaj´ı stejn´a pr´ava jako registrovan´ı n´avˇstˇevn´ıci.

Registrov´an´ı n´avˇstˇevn´ıci maj´ı stejn´e moˇznosti jako neregistrovan´ı a nav´ıc maj´ı moˇznost zmˇenit vzhled syst´emu. Mimo moˇznost´ı, kter´e m´a jiˇz zm´ınˇen´y neregistrovan´y n´avˇstˇevn´ık, tak´e moˇznost zmˇenit vzhled syst´emu. D´ıky sv´ym pr´av˚um maj´ı pˇr´ıstup do ˇc´asti Nastaveni,

kde si mohou vybrat z nˇekolika implementovan´ych CSS styl˚u, nastavit osloven´ı ˇci vybrat vlajku na pozad´ı. D´ale mohou zmˇenit sv´e heslo a odhl´asit se ze syst´emu.

Editoˇri jsou podstatnou ˇc´ast´ı syst´emu, protoˇze maj´ı pr´ava pˇrid´avat a mˇenit vetˇsinu informac´ı v syst´emu. Vytv´aˇrej´ı, edituj´ı a maˇzou z´apasy. Mohou mˇenit informace o t´ymu, hr´aˇci, tren´erovi a rozhodˇc´ıch; pˇrid´avat nebo odeb´ırat hr´aˇce do/z datab´aze. A tak´e maj´ı moˇznost pˇrid´av´an´ı fotografi´ı do fotogalerie. Jedinn´a moˇznost jak z´ıskat editorsk´a pr´ava je ta, ˇze jsou pˇridˇelena spr´avcem cel´eho syst´emu tzn. administr´atorem.

Administr´atoˇri maj´ı pˇrehled o vˇsech ostatn´ıch uˇzivatelsk´ych ´uˇctech. Maj´ı moˇznost pˇrid´avat, mazat a mˇenit vˇsechny ´uˇcty.

2.3

Anal´

yza

Na z´akladˇe uveden´ych poˇzadavk˚u a za pouˇzit´ı jazyka UML (jedn´a se o grafick´y jazyk pro vizualizaci, specifikaci, navrhov´an´ı a dokumentaci programov´ych syst´em˚u) doˇslo k vytvoˇren´ı diagramu pˇr´ıpadu uˇzit´ı (tzv. Use-case diagram) syst´emu. (2.1)

Pˇr´ıpady uˇzit´ı zachycuj´ı pˇresnˇe funkˇcnost, kter´a bude budouc´ım IS pokryta, a vyme-zuj´ı tak jednoznaˇcnˇe rozsah prac´ı. Diagram uˇzit´ı popisuje poˇzadovanou funkˇcnost syst´emu. Syst´em nebude tedy obsahovat nic jin´eho neˇz popisuj´ı pˇr´ıpady uˇzit´ı.

Rozloˇzen´ı na podprobl´emy (tzv. dekompozice) cel´eho ´ukolu bylo ned´ılnou souˇc´asti anal´yzy. Rozloˇzen´ı je zaloˇzeno na diagramu pˇr´ıpadu uˇzit´ı a bylo tvoˇreno v z´avislosti na imple-mentaˇcn´ı metody ˇreˇsen´ı jednotliv´ych probl´em˚u a na dalˇs´ı detailnˇejˇs´ı n´avrh pomoc´ı jazyka UML.

Kapitola 3

Objektov´

y n´

avrh

Jak jsme se jiˇz v ´uvodu dozvedˇeli, projekty nelze ˇreˇsit bez kvalitn´ıho n´avrhu. V t´eto kapitole se budeme vˇenovat vhodn´ym pˇr´ıstup˚um objektov´eho n´avrhu. S t´ım souvis´ı jazyk UML, softwarov´a architektura, n´avrhov´e vzory apod.

3.1

UML

Pro modelov´an´ı objektovˇe orientovan´ych softwarov´ych syst´em˚u se v souˇcasn´e dobˇe pouˇz´ıv´a jazyk UML (Unified Modeling Language). Je to otevˇren´y rozˇsiˇriteln´y pr˚umyslov´y standardn´ı vizu´aln´ı modelovac´ı jazyk uznan´y skupinou OMG. Prvn´ı verze jazyka pˇrijat´a OMG je z roku 1997, posledn´ı verze 2.0 je z roku 2005.

Dˇr´ıve neˇz se podrobnˇeji pod´ıv´ame na UML podrobnˇeji, zopakujeme si velice struˇcnˇe nˇekter´e z´akladn´ı pojmy objektovˇe orientovan´eho paradigmatu.

3.1.1 Z´akladn´ı pojmy

Objekt

Z´akladn´ım pojmem je objekt, ten budeme ch´apat jako ˇc´ast software, kter´a m´a stav, chov´an´ı a identitu. Stav objektu je urˇcen hodnotami jeho atribut˚u. Chov´an´ı objektu je definov´ano sluˇzbami(operacemi, t´eˇz zvan´e metody), kter´e m˚uˇze objekt prov´adˇet, kdyˇz je o to poˇz´ad´an jin´ymi objekty. Identita objektu (ObjectID) je specifick´a vlastnost objektu, podle jej´ıˇz hodnoty lze libovoln´e dva objekty syst´emu odliˇsit a to i tehdy, kdyˇz jsou hodnoty vˇsech atribut˚u obou objekt˚u stejn´e a oba sd´ıl´ı stejn´e operace.

Zapouzdˇren´ı

Objekty klasifikujeme do tˇr´ıd, tˇr´ıda tedy urˇcuje typ objektu – definuje, jak´e atributy ob-jekt m´a a jak´e operace m˚uˇze prov´adˇet. O objektu potom hovoˇr´ıme jako o instanci tˇr´ıdy. Kaˇzd´y objekt tˇr´ıdy nese konkr´etn´ı hodnoty atribut˚u definovan´ych tˇr´ıdou a poskytuje ope-race urˇcen´e tˇr´ıdou. Vlastnost objektu, ˇze ostatn´ı objekty mohou ovlivnit stav objektu pouze prostˇrednictv´ım tˇechto operac´ı, se naz´yv´a zapouzdˇren´ı.

Dˇediˇcnost

Dalˇs´ım d˚uleˇzit´ym pojmem je dˇediˇcnost. Jde o vztah mezi tˇr´ıdami, kdy jedna tˇr´ıda dˇed´ı vˇsechny vlastnosti (atributy, operace, atd.). Vlastnosti nadtˇr´ıdy m˚uˇze dˇedit nˇekolik podtˇr´ıd.

Pokud podtˇr´ıda dˇed´ı vlastnosti jen jedn´e nadtˇr´ıdy, hovoˇr´ıme o dˇediˇcnosti jednoduch´e, m´a-li nadtˇr´ıd v´ıce, hovoˇr´ıme o dˇediˇcnosti v´ıcen´asobn´e.

Polymorfismus

Posledn´ım z´akladn´ım pojmem, kter´y si zopakujeme, je polymorfismus. T´yk´a se operac´ı. Pokud m´a jedna operace se stejnou hlaviˇckou nˇekolik implementac´ı, pak jde o polymorfn´ı operaci. M˚uˇze k tomu doj´ıt tak, ˇze nˇekolik podtˇr´ıd zdˇed´ı tut´eˇz abstraktn´ı operaci a do-definuje vlastn´ı implementaci nebo podtˇr´ıda redefinuje zdˇedˇenou konkr´etn´ı operaci. Pˇri poˇzadavku na proveden´ı operace se potom automaticky vybere implementace t´e tˇr´ıdy, na jej´ıˇz objekt se operace aplikuje.

3.1.2 Struktura jazyka

Pro pochopen´ı struktury je d˚uleˇzit´e jednak pro pochopen´ı jeho celkov´e filosofie a moˇznost´ı, kter´e n´am pro vizu´aln´ı modelov´an´ı nab´ız´ı. Filozofie dobr´eho n´avrhu je stejnˇe duleˇzit´a jako filozofie bojov´ych umˇen´ı. Bez jej´ıho pochopen´ı jde jen o pr´aci, formu bez obsahu. Podobnˇe jako se ruzn´e bojov´e styly liˇs´ı svou formou, z´akladni obsah je stejn´y. Podobnˇe i tak se metody n´avrhu mohou liˇsit, duleˇzit´a nen´ı vˇsak forma ale obsah.

Struktura jazyka je tvoˇrena:

• Stavebn´ımi bloky – jsou to z´akladn´ı modelovac´ı prvky jazyka, vztahy a diagramy. • Obecn´ymi mechanismy – obecn´e zp˚usoby, kter´e nab´ız´ı UML k dosaˇzen´ı konkr´etn´ıch

c´ıl˚u.

• Architektura - pohled jazyka UML na architekturu modelovan´eho syst´emu. Stavebn´ı bloky

Mezi stavebn´ı bloky UML patˇr´ı:

• Prvky – jsou to samotn´e modelovac´ı prvky jazyka. • Vztahy – slouˇz´ı k modelov´an´ı vazeb mezi prvky.

• Diagramy – pohledy do model˚u v UML. Pˇredstavuj´ı n´aˇs zp˚usob vizualizace toho, co syst´em bude dˇelat (diagramy ´urovnˇe anal´yzy) nebo jak to bude dˇelat (diagramy ´

urovnˇe n´avrhu)

Prvky Mezi prvky patˇr´ı modelovac´ı prvky, kter´e slouˇz´ı k modelov´an´ı struktury syst´emu (napˇr. tˇr´ıda, pˇr´ıpad pouˇzit´ı, komponenta), k modelov´an´ı chov´an´ı (napˇr. interakce, aktivita, stavov´y automat), k seskupov´an´ı prvk˚u (bal´ıˇcek (package)) a k okomentov´an´ı (pozn´amka).

Vztahy Vztah˚u existuje v UML nˇekolik typ˚u. Jako pˇr´ıklad m˚uˇzeme uv´est vztah z´avislosti, kter´y modeluje skuteˇcnost, ˇze nˇejak´y prvek z´avis´ı na prvku jin´em a m˚uˇze b´yt ovlivnˇen jeho zmˇenou.

Diagramy Diagramy UML lze rozdˇelit do dvou skupin - pro modelov´an´ı statick´e struktury (statick´y model) a pro modelov´an´ı dynamick´e struktury (dynamick´y model) syst´emu. Do prv´e skupiny patˇr´ı diagram tˇr´ıd, diagram objekt˚u, diagram bal´ıˇck˚u, diagram kom-ponent, diagram sloˇzen´e struktury a diagram nasazen´ı. Do druh´e skupiny potom di-agram pˇr´ıpad˚u pouˇzit´ı, diagramy interakce (diagram sekvence, diagram komunikace, pˇrehledov´y diagram interakce, diagram ˇcasov´an´ı), diagram stavov´eho automatu a di-agram aktivity.

Obecn´e mechanismy

Obecn´e mechanismy jazyka UML popisuj´ı ˇctyˇri strategie, kter´e se zde pouˇz´ıvaj´ı v r˚uzn´em kontextu.

Specifikace Jde o textov´e informace doplˇnuj´ıc´ı grafickou podobu modelu. Hovoˇr´ı se o gra-fick´e a textov´e dimenzi model˚u UML. Specifikace umoˇzˇnuj´ı vyj´adˇrit s´emantiku prvku modelu v kontextu ˇreˇsen´eho probl´emu. Typick´ym pˇr´ıkladem je specifikace pˇr´ıpadu pouˇzit´ı, kdy pouh´y diagram pˇr´ıpad˚u pouˇzit´ı bez jejich specifikace m´a velice malou vypov´ıdac´ı schopnost.

Doplˇnky V UML m´a kaˇzd´y modelovac´ı prvek pˇriˇrazen jednoduch´y grafick´y symbol, kter´y lze doplnit ˇradou doplˇnk˚u a tak uzp˚usobovat mnoˇzstv´ı prezentovan´e vizu´aln´ı infor-mace aktu´aln´ım potˇreb´am. Napˇr´ıklad u tˇr´ıdy lze zobrazovat jenom jej´ı jm´eno nebo i atributy, nebo i operace a podobnˇe.

Obecn´a dˇelen´ı Jde o zp˚usob uvaˇzov´an´ı o modelovan´em svˇetˇe. V UML jsou dvˇe obecn´a dˇelen´ı.

1. Klasifik´ator/instance – Zde klasifik´ator znaˇc´ı abstraktn´ı pojem - typ prvku a instance konkr´etn´ı v´yskyt. Napˇr´ıklad pˇri modelov´an´ı fakultn´ıho informaˇcn´ıho syst´emu m˚uˇze b´yt takov´ym abstraktn´ım pojmem student a jeho konkr´etn´ım v´yskytem student Jan Nov´ak. Jistˇe jste poznali, ˇze klasifik´atorem je v tomto pˇr´ıpadˇe tˇr´ıda a instanc´ı konkr´etn´ı objekt t´eto tˇr´ıdy. Tˇr´ıda ale nen´ı zdaleka je-din´ym klasifik´atorem v jazyce UML, patˇr´ı se tak´e pˇr´ıpad pouˇzit´ı, komponenta, akt´er, rozhran´ı a ˇrada dalˇs´ıch. V UML existuj´ı diagramy, ve kter´ych figuruj´ı kla-sifik´atory a jin´e obsahuj´ıc´ı instance. Instance maj´ı v UML obvykle stejn´y grafick´y symbol jako odpov´ıdaj´ıc´ı klasifik´ator, pouze jm´eno na symbolu je podtrˇzen´e. 2. Rozhran´ı/implementace – Podstatou je oddˇelit to, co nˇeco dˇel´a (jeho rozhran´ı),

od toho, jak to dˇel´a (jeho implementace). D´a se ˇr´ıci, ˇze rozhran´ı definuje ” kon-trakt“, kter´y konkr´etn´ı implementace garantuje dodrˇzet. Pˇritom zp˚usob˚u, jak implementovat dan´e rozhran´ı m˚uˇze b´yt cel´a ˇrada. Principu oddˇelen´ı rozhran´ı od implementace m´a u objektov´e orientace velk´y v´yznam a modern´ı programovac´ı jazyky, napˇr. Java, poskytuj´ı rozhran´ı jako samostatn´y konstrukt. Podobnˇe je tomu v UML.

Mechanismy rozˇsiˇritelnosti Autoˇri jazyka si uvˇedomili, ˇze nen´ı moˇzn´e navrhnout zcela univerz´aln´ı modelovac´ı jazyk, jehoˇz v´yrazov´e prostˇredky by pokryly vˇsechny souˇcasn´e i budouc´ı potˇreby. Proto do UML zahrnuli tˇri jednoduch´e mechanismy rozˇsiˇritelnosti. Tyto mechanismy rozˇsiˇritelnosti umoˇzˇnuj´ı vytv´aˇret tzv. profily seskupen´ım stereo-typ˚u, pˇripojen´ych hodnot a omezen´ı definovan´ych pro urˇcitou aplikaˇcn´ı oblast. Tak

jiˇz byly vytvoˇreny profily pro modelov´an´ı syst´em˚u pracuj´ıc´ıch v re´aln´em ˇcase, pro modelov´an´ı .NET aplikac´ı apod.

Vyuˇzit´ı mechanism˚u rozˇsiˇritelnosti ale vyˇzaduje pˇr´ısluˇsnou podporu modelovac´ıho n´astroje, kter´y n´am mus´ı umoˇznit vytv´aˇret stereotypy, definovat pˇripojen´e hodnoty a omezen´ı a umoˇznit pr´aci s nimi.

1. Omezeni – Doplˇnuj´ıc´ı textov´a informace, kter´a definuje nˇejakou podm´ınku nebo pravidlo vztahuj´ı se ke konkr´etn´ımu modelovac´ımu prvku v modelu, kter´e mus´ı b´yt dodrˇzeno. UML obsahuje ˇradu pˇreddefinovan´ych omezen´ı, ale uˇzivatel m˚uˇze libovolnˇe vytv´aˇret omezen´ı vlastn´ı. Pˇrestoˇze UML nevyˇzaduje z´apis omezen´ı v nˇejak´em konkr´etn´ım jazyce, definuje jako sv´e standardn´ı rozˇs´ıˇren´ı jazyk OCL (Object Constraint Language), kter´y je urˇcen i pro tyto ´uˇcely. Omezen´ı se p´ıˇs´ı v UML do sloˇzen´ych z´avorek.

2. Stereotypy – Jde o nov´e, uˇzivatelem definovan´e prvky, kter´e jsou odvozeny z exis-tuj´ıc´ıch modelovac´ıch prvk˚u jazyka UML modifikac´ı jejich v´yznamu. Samotn´y UML jiˇz obsahuje nˇekter´e pˇreddefinovan´e stereotypy (napˇr. podsyst´em jako ste-reotyp komponenty). Steste-reotypy se nejˇcastˇeji zobrazuj´ı pouˇzit´ım symbolu prvku, ze kter´eho je stereotyp odvozen, s uveden´ım n´azvu stereotypu ve dvojit´ych lo-men´ych z´avork´ach.

3. Pˇripojen´e hodnoty – Vˇetˇsina modelovac´ıch prvk˚u v UML m´a pˇreddefinov´any urˇcit´e vlastnosti, z nichˇz nˇekter´e se zobrazuj´ı v diagramu, jin´e ne. Uˇzivatel ale m˚uˇze definovat nov´e vlastnosti modelovac´ıch prvk˚u zaveden´ım kl´ıˇcov´ych slov pro nˇe. Ke konkr´etn´ımu prvku modelu jsou potom pˇripojeny hodnoty tˇechto vlast-nost´ı ve tvaru kl´ıˇcov´eSlovo1 = hodnota1, kl´ıˇcov´eSlovo2 = hodnota2, . . . Uˇzivatelem definovan´e pˇripojen´e hodnoty se uplatˇnuj´ı hlavnˇe u stereotyp˚u.

3.2

Softwarov´

a architektura

3.2.1 Popis

Softwarov´a architektura programu nebo poˇc´ıtaˇcov´eho syst´emu je struktura syst´emu, kter´y se skl´ad´a ze softwarov´ych komponent, externˇe viditeln´ych ˇc´ast´ı tˇechto komponent a vztahu mezi nimi. Term´ın tak´e ud´av´a dokumentaci syst´emov´e architektury. Dokumentovan´a soft-warov´a architektura napom´ah´a komunikaci mezi analytiky a z´akazn´ıky. Dokumenty urych-luj´ı rozhodnut´ı o vysokolevelov´em n´avrhu a povoluj´ı znovupouˇzit´ı n´avrhov´ych komponent a vzor˚u mezi projekty.

Dˇr´ıvˇejˇs´ı probl´emy komplexnosti byly ˇreˇseny v´yvoj´aˇri v´ybˇerem spr´avn´ych datov´ych struk-tur, v´yvojov´ych algoritm˚u a aplikov´an´ım konceptu rozloˇzen´ı na podprobl´emy. Pˇresto je term´ın SW architektura v pr˚umyslu relativnˇe nov´y. Z´akladn´ı principy jiˇz byly sporadicky aplikov´any softwarov´ymi inˇzen´yry od poloviny 80t´ych let. Dˇr´ıvˇejˇs´ı pokusy o zachycen´ı a vysvˇetlen´ı softwarov´e architektury syst´emu byly vˇsak nepˇresn´e a zmaten´e. V pr˚ubˇehu 90t´ych let byla snaha definovat a utˇr´ıdit z´akladn´ı aspekty. Tehdy byly vyvinuty poˇc´ateˇcn´ı nastaven´ı n´avrhov´ych vzor˚u, styl˚u, nejlepˇs´ıch praktik, popisu jazyka a form´aln´ı logika.

Obor SW architektury je zaloˇzen na myˇslence zredukov´an´ı sloˇzitosti pomoc´ı abstrakce a rozdˇelen´ı na podprobl´emy. Dodnes ovˇsem st´ale neexistuje pˇresn´a definice term´ınu SW architektura.

Tento zraj´ıc´ı obor bez jasnˇe dan´ych pravidel a spr´avn´e cesty k vytoˇren´ı syst´emu a n´avrhu SW architektury je st´ale smˇes vˇedy a umˇen´ı. Aspekt umˇen´ı SW architektury podporuje

kv˚uli komerˇcn´ımu SW syst´emu nektˇer´e aspekty ´ukolu nebo poselstvi. Jak syst´em podporuje kl´ıˇcov´e informace k dosaˇzen´ı c´ıle, je pops´ano pomoc´ı sc´en´aˇr˚u jako nefunkˇcn´ıch poˇzadavk˚u na syst´em. Tak´e zn´am´e jako atributy kvality, kter´e rozhoduj´ı, jak se syst´em bude chovat. Kaˇzd´y syst´em je vyj´ımeˇcn´y kv˚uli povaze informac´ı, kter´ymi je specifikov´an – jako tolerance chyb, zpˇetn´a kompatibilita, rozˇsiˇritelnost, udrˇzovatlnost, bezpeˇcnost, pouˇzitelnost apod.

3.2.2 Typy architektur

Urˇcuje SW komponenty IS a jejich vz´ajemn´e vazby. Definuje vnitˇrn´ı strukturu SW kom-ponent - urˇcen´ı modul˚u, jejich vazby a charakteristiky. Je realizov´ana pomoc´ı monolitick´e, dvouvrstv´e nebo tˇr´ıvrstv´e architektury. (3.1).

Obr´azek 3.1: druhy architektur

Z tˇechto ˇctyˇr druh˚u jsou univerz´alnˇe pouˇziteln´e jen vrstven´a a s´ıt’ov´a architektura, zb´yvaj´ıc´ı dvˇe (line´arn´ı a hierarchick´a) lze pouˇz´ıt pouze pro specifick´e aplikace. S´ıt’ov´a ar-chitektura je preferov´ana, jestliˇze preferujeme n´ızk´e n´aklady provozu pˇred n´ızk´ymi n´aklady

na tvorbu, ´udrˇzbu a uˇzit´ı. V ostatn´ıch pˇr´ıpadech je vhodnˇejˇs´ı uˇz´ıt architekturu vrstvenou.

3.3

N´

avrhov´

e vzory

3.3.1 Popis

V SW inˇzen´yrstv´ı jsou n´avrhov´e vzory znovupouˇziteln´ym ˇreˇsen´ım obvykl´ych probl´em˚u. N´avhov´e vzory nejsou vytv´aˇreny tak, aby byly pˇr´ımo pˇrev´adˇeny na k´od, ale slouˇz´ı k popisu nebo jako ˇsablona pro ˇreˇsen´ı probl´em˚u v mnoha rozd´ıln´ych situac´ıch. Objektovˇe oriento-van´e n´avrhov´e vzory zn´azorˇnuj´ı vztahy a p˚usoben´ı mezi tˇr´ıdami a objekty bez specifikace koneˇcn´ych aplikaˇcn´ıch tˇr´ıd a objekt˚u, kter´e jsou zapojeny do ˇreˇsen´ı.

N´avrhov´e vzory mohou urychlit v´yvojov´y proces poskytov´an´ım otestovan´ych a dok´azan´ych v´yvojov´ych paradigmat. Efektivn´ı SW n´avrh vyˇzaduje zvaˇzov´an´ı probl´em˚u, kter´e by se nemˇely objevit aˇz pˇri pozdˇejˇs´ı implementaci. Znovupouˇzit´ı n´avrhov´ych vzor˚u pom´ah´a zabr´anit tomu, aby drobn´e probl´emy nezp˚usobovaly velk´e probl´emy. A z´aroveˇn vylepˇsuje ˇcitelnost k´odu pro ostatni program´atory a architekty, kteˇr´ı jsou s technikou vzor˚u obezn´ameni.

Lid´e ˇcasto rozumˇej´ı jen tomu, jak urˇcitou SW n´avrhovou techniku aplikovat na urˇcit´y probl´em. Tyto techniky jsou teˇzk´e pro aplikaci na probl´emy ˇsirˇs´ıho rozsahu. N´avrhov´e vzory poskytuj´ı celkov´e ˇreˇsen´ı doloˇzen´e ve form´atu, kter´y nepotˇrebuje specifikace v´azan´e na jednotliv´e probl´emy.

3.3.2 C´ˇasti n´avrhov´ych vzor˚u

Podle knihy ”Design paterns” od ”Gang of four” (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) se n´avrhov´e vzory skl´adaj´ı z nˇekolika ˇc´ast´ı:

Jm´eno vzoru a klasifikace - Popisuj´ıc´ı a unik´atn´ı jm´eno, kter´e pom´ah´a v identifikaci a odkazov´an´ı na vzor.

´

Uˇcel – Popis c´ıle n´avrhu a d˚uvod pro pouˇzit´ı. . .

Motivace – Sc´en´aˇr skl´adaj´ıc´ı se z probl´emu a kontextu, v kter´em lze tento vzor pouˇz´ıt. . . Aplikovatelnost – Situace, ve kter´ych je tento vzor pouˇziteln´y; kontext pro vzor. . . Struktura – Grafick´e vyjadˇren´ı vzoru. Za t´ımto ´uˇcelem se pouˇzivaj´ı Digramy tˇr´ıd a

Sek-venˇcn´ı diagramy. . . ´

Uˇcastn´ıci – Seznam pouˇzit´ych tˇr´ıd a objekt˚u a jejich ´uloha v n´avrhu. . .

Spolupr´ace – Popis, jak´ym zp˚usobem se pouˇzit´e tˇr´ıdy a objekty mezi sebou ovlivˇnuj´ı. . . D˚usledky – Popis v´ysledk˚u, vedlejˇs´ıch ´uˇcink˚u a vz´ajemn´ych porovn´an´ı zp˚usoben´ych pouˇzit´ım

n´avrhu. . .

Implemtace – Popis implementace n´avrhu; v´ysledn´a ˇc´ast n´avrhu. . .

Pˇr´ıklad k´odu – Ilustrace toho, jak m˚uˇze b´yt n´avrh pouˇzit v programovac´ım jazyce. . . Zn´am´a pouˇzit´ı – Pˇr´ıklady skuteˇcnho pouˇzit´ı n´avrhu. . .

Souvisej´ıc´ı vzory – Ostatn´ı vzory, kter´e maj´ı podobn´y vztah s n´avrhem, diskuze rozd´ıl˚u mezi vzory a podobn´e vzory. . .

3.3.3 Z´akladn´ı rozdˇelen´ı

Rozdˇelen´ı n´avrhov´ych vzor˚u vych´az´ı z GAM95. Autoˇri vymezili tˇri z´akladn´ı skupiny n´avrhov´ych vzor˚u, kter´e jsou st´ale uzn´avan´e.

• Creational Patterns (vytv´aˇrej´ıc´ı) • Structural Patterns (struktur´aln´ı) • Behavioral Patterns (chov´an´ı)

1. Creational Patterns ˇreˇs´ı probl´emy souvisej´ıc´ı s vytv´aˇren´ım objekt˚u v syst´emu. Snahou tˇechto n´avrhov´ych vzor˚u je popsat postup v´ybˇeru tˇr´ıdy nov´eho objektu a zajiˇstˇen´ı spr´avn´eho poˇctu tˇechto objekt˚u. Vˇetˇsinou se jedn´a o dynamick´a rozhodnut´ı uˇcinˇen´a za bˇehu programu. Mezi tyto n´avrhov´e vzory patˇr´ı:

• Factory Method Pattern

• Abstract Factory Method Pattern • Builder Pattern

• Prototype Pattern • Singleton Pattern

2. Structural Patterns pˇredstavuj´ı skupinu n´avrhov´ych vzor˚u, zamˇeˇruj´ıc´ıch se na moˇznosti uspoˇr´ad´an´ı jednotliv´ych tˇr´ıd nebo komponent v syst´emu. Snahou je zpˇrehlednit syst´em a vyuˇz´ıt moˇznosti strukturalizace k´odu. Mezi tyto n´avrhov´e vzory patˇr´ı:

• Adapter Pattern • Bridge Pattern • Composite Pattern • Decorator Pattern • Facade Pattern • Flyweight Pattern • Proxy Pattern

3. Behavioral Patterns se zaj´ımaj´ı o chov´an´ı syst´emu. Mohou b´yt zaloˇzeny na tˇr´ıd´ach nebo objektech. U tˇr´ıd vyuˇz´ıvaj´ı pˇri n´avrhu ˇreˇsen´ı pˇredevˇs´ım principu dˇediˇcnosti. V druh´em pˇr´ıstupu je ˇreˇsena spolupr´ace mezi objekty a skupinami objekt˚u, kter´a zajiˇst’uje dosaˇzen´ı poˇzadovan´eho v´ysledku. Mezi tento typ vzor˚u m˚uˇzeme zaˇradit:

• Chain Of Responsibility Pattern • Command Pattern • Interpreter Pattern • Iterator Pattern • Mediator Pattern • Memento Pattern • Observer Pattern

• State Pattern • Strategy Pattern • Template Pattern • Visitor Pattern

3.4

Literatura

V t´eto kapitole byly pouˇzity n´asleduj´ıc´ı publikace [12, AIS], [13, IDS], [4, IIS], [1, UML], [5, OOP], [2, Design patterns] [6, NZ] a webov´e str´anky [8, Objekty].

Kapitola 4

N´

avrh syst´

emu

V t´eto kapitole si provedeme podrobn´y n´avrh syst´emu pomoc´ı diagramu tˇr´ıd. Pˇribl´ıˇz´ıme si tˇr´ıvrvstvou architekturu MVC z kter´e vychaz´ı n´avrh.

4.1

MVC architektura

Model-View-Controller architektura je z´akladn´ım prvkem navrhovan´eho syst´emu i pˇresto, ˇ

ze realizace se odliˇsuje od jej´ıho klasick´eho ch´ap´an´ı. Tato architektura je ve velk´e m´ıˇre vyuˇz´ıv´ana pˇri vytv´aˇren´ı prezentaˇcnˇe orientovan´eho syst´em˚u a jiˇz je publikov´ana jako n´avrhov´y vzor. Jej´ım principem je rozdˇelen´ı syst´emu do tˇr´ı logick´ych ˇc´ast´ı:

• View – slouˇz´ı k vytvoˇren´ı grafick´eho rozhran´ı pro interakci s uˇzivatelem. Kaˇzd´y ucelen´y syst´em by mˇel obsahovat jednotn´e grafick´e ovl´ad´an´ı, kter´e plnˇe vyhovuje uˇzivatel˚um. Pˇri n´avrhu grafick´ych standard˚u pro vznikaj´ıc´ı syst´em je nutn´e br´at v ´

uvahu nejenom poˇzadavky uˇzivatel˚u, ale i standardy Internetu. ´Uˇcelem t´eto vrstvy je oddˇelen´ı prezentaˇcn´ı logiky od vˇecn´e a datov´e, coˇz zvyˇsuje jej´ı udrˇzovatelnost a umoˇzˇnuje jednoduˇsˇs´ı zapracov´an´ı zmˇen, kter´e se objevuj´ı ve vˇetˇs´ı m´ıˇre pr´avˇe v pre-zentaˇcn´ı vrstvˇe. Jestliˇze vyuˇz´ıv´ame J2EE technologii, je pro tuto vrstvu moˇzn´e vyuˇz´ıt servlety, JSP str´anky a transformace XML pomoc´ı XSL.

• Model – zapouzdˇruje vˇecnou a datovou logiku syst´emu. Jelikoˇz se vˇetˇsinou jedn´a o nejsloˇzitˇejˇs´ı vrstvu syst´emu, kter´a obsahuje mnoˇzstv´ı komponent, je vhodn´e po-skytnout pˇrehledn´y pˇr´ıstup k t´eto vrstvˇe pomoc´ı ucelen´e sady aplikaˇcn´ıch rozhran´ı (API). Z n´avrhov´ych vzor˚u, kter´e se hod´ı pro tento ´uˇcel, m˚uˇzeme pouˇz´ıt Facade ve spolupr´aci s Command vzorem. Model, dle doporuˇcen´ı tv˚urc˚u J2EE platformy, by mˇel b´yt realizov´an pomoc´ı EJB komponent. Podobn´e snahy m˚uˇzeme, ale nal´ezt i u rodiny jazyk˚u .NET. Tyto jsou vyuˇzity pˇredevˇs´ım v situac´ıch, kdy je kladen d˚uraz na bezpeˇcnost, transakˇcn´ı zpracov´an´ı, moˇznou rozˇsiˇritelnost. Snahou ovˇsem je celou logiku rozdˇelit do samostatn´ych komponent, kter´e tvoˇr´ı realizaci urˇcit´e ˇc´asti, kterou je moˇzn´e pˇresnˇe vymezit a ohraniˇcit. Vytvoˇren´ım sady komponent zvyˇsujeme moˇznosti jejich znovupouˇzit´ı a t´ım ´usporu pracnosti. Kaˇzd´a komponenta by mˇela pˇredstavovat zapouzdˇren´ı funkc´ı a dat v n´ı uloˇzen´ych. T´ımto m˚uˇzeme i uvaˇzovat o distribuo-van´em zpracov´an´ı nebo vyuˇzit´ı v´ıce datov´ych ´uloˇziˇst’. Komponenty jsou uspoˇr´ad´any do vˇetˇs´ıch celk˚u (modul˚u, subsyst´em˚u), kter´e prezentuj´ı logickou, samostatnˇe provo-zovatelnou ˇc´ast. Pˇr´ı n´avrhu je kladen d˚uraz na sn´ıˇzen´ı vz´ajemn´e prov´azanosti modul˚u, subsyst´emu i samotn´ych komponent.

• Controller – je vrstva mezi prezentaˇcn´ı (View) a vrstvou aplikaˇcn´ı (Model). Jej´ım ´

uˇcelem je zpracov´an´ı ud´alost´ı v prezentaˇcn´ı vrstvˇe a vyvol´an´ı metod objekt˚u tvoˇr´ıc´ıch Model. Controller vrstva redukuje z´avislost mezi vˇecnou a prezentaˇcn´ı logikou. Z´akladem vrstvy Controller je jeden servlet, kter´y slouˇz´ı jako jednotn´y pˇr´ıstup z prezentaˇcn´ı lo-giky. Na z´akladˇe vyhodnocen´ı pˇrijat´eho poˇzadavku doch´az´ı k rozhodnut´ı, kter´a ˇc´ast vˇecn´e logiky je odpovˇedn´a za jeho vyˇr´ızen´ı.

MVC architektura je ˇc´asteˇcnˇe postavena na principu n´avrhov´eho vzoru Observer. Model pˇredstavuje pozorovan´y objekt, ke kter´emu se jako pozorovatel´e pˇrihlaˇsuj´ı objekty z pre-zentaˇcn´ı vrstvy a Controller. Jestliˇze nastane zmˇena v Modelu (napˇr´ıklad zmˇena dat), je o t´eto skuteˇcnosti informov´an Controller i zaregistrovan´e prezentaˇcn´ı objekty pomoc´ı me-tody update(), kter´a je definov´ana v rozhran´ı Observer. Controller m˚uˇze vlastnit referenci na v´ıce komponent Modelu a i na v´ıce objekt˚u z prezentaˇcn´ı vrstvy. N´avrhov´y vzor MVC byl vytvoˇren pro technologii client–server. Probl´em tohoto vzoru v internetov´e technologii je nemoˇznost okamˇzit´e notifikace prezentaˇcn´ı logiky. Tato technologie pracuje na principu poˇzadavek-odpovˇed’, kdy zah´ajen´ı komunikace vˇzdy vych´az´ı z GUI. Proto je tato vrstva informov´ana o probˇehl´ych zmˇen´ach pouze pomoc´ı odpovˇed´ı na jej´ı poˇzadavky.

4.2

Diagramy

4.2.1 Diagram aktivit

ˇ

Casto se oznaˇcuj´ı jako

”objektovˇe orientovan´e v´yvojov´e diagramy“. Vych´az´ı z osvˇedˇcen´ych modelovac´ıch technik v´yvojov´ych diagram˚u, Petriho s´ıt´ı a modelov´an´ı workflow. ˇCasto se pouˇz´ıvaj´ı pro modelov´an´ı business proces˚u, workflow, datov´ych tok˚u a operac´ı. Aktivita, kterou modeluj´ı, ale m˚uˇze ukazovat i chov´an´ı pˇr´ıpadu pouˇzit´ı, skupiny pˇr´ıpad˚u pouˇzit´ı, tˇr´ıd, rozhran´ı nebo komponent. Ve srovn´an´ı s jin´ymi diagramy pro modelov´an´ı chov´an´ı, napˇr´ıklad diagramy interakce, maj´ı diagramy aktivit vlastnost, ˇze modeluj´ı chov´an´ı, aniˇz by bylo potˇreba specifikovat statickou strukturu tˇr´ıd a objekt˚u, kter´e aktivitu realizuj´ı. Toho lze s v´yhodou vyuˇz´ıt v poˇc´ateˇcn´ıch st´adi´ıch anal´yzy. Uk´azka viz Obr.(4.1)

4.2.2 Diagram tˇr´ıd

Z´akladn´ım diagramem UML pro modelov´an´ı logick´eho pohledu na statickou strukturu syst´emu je diagram tˇr´ıd, kter´y vizualizuje tˇr´ıdy a rozhran´ı, jejich intern´ı strukturu a vztahy k ostatn´ım tˇr´ıd´am.

Tˇr´ıda je v UML definov´ana jako popis mnoˇziny objekt˚u, kter´e sd´ılej´ı tyt´eˇz specifikace rys˚u, omezen´ı a s´emantiky. Rysy tˇr´ıdy jsou atributy a operace.

Vztahy v diagramu tˇr´ıd jsou v´yznamn´a spojen´ı tˇr´ıd (pˇr´ıpadnˇe rozhran´ı). Existuj´ı tˇri typy vztah˚u, kter´e pouˇz´ıv´ame v diagramu tˇr´ıd: asociace, agregace a generalizace.

• Asociace ve skuteˇcnosti reprezentuje vazby objekt˚u dan´ych tˇr´ıd, podobnˇe jako vztahy v ER diagramu. Nejˇcastˇejˇs´ım pˇr´ıpadem asociac´ı jsou bin´arn´ı asociace, coˇz jsou asoci-ace reprezentuj´ıc´ı vazby mezi dvojicemi objekt˚u, zpravidla dvou r˚uzn´ych tˇr´ıd. Jde-li o objekty t´eˇze tˇr´ıdy, naz´yv´a se asociace reflexivn´ı. V pˇr´ıpadˇe tˇr´ı objekt˚u hovoˇr´ıme o tern´arn´ı asociaci. U asociace m˚uˇzeme definovat jej´ı jm´eno, jm´eno role, n´asobnost a na-vigovatelnost. Posledn´ı tˇri vlastnosti se vztahuj´ı vˇzdy ke konkr´etn´ımu konci asociace. Viz Obr.(4.2)

• Agregace je v UML speci´aln´ı druh asociace modeluj´ıc´ı vztah celek – ˇc´ast, tj. kde instance jedn´e tˇr´ıdy (celek, agreg´at) obsahuje instance jin´e tˇr´ıdy (ˇc´asti). Na Obr.(4.3) je tˇr´ıda Tˇr´ıdaA celkem a tˇr´ıda Tˇr´ıdaB jeho ˇc´ast´ı. Vztah celku a ˇc´asti modelovan´y agregac´ı je voln´y. Pˇr´ıkladem m˚uˇze b´yt poˇc´ıtaˇc a periferie. Celek nˇekdy m˚uˇze existovat nez´avisle na ˇc´astech, jindy ne. Podobnˇe ˇc´asti mohou existovat nez´avisle na agreg´atu. U agregace m˚uˇze b´yt dokonce ˇc´ast sd´ılen´a v´ıce agreg´aty, tj. n´asobnost u celku m˚uˇze b´yt vˇetˇs´ı neˇz jedna.

V UML existuje silnˇejˇs´ı forma agregace, kter´a vyjadˇruje tˇesnˇejˇs´ı vazbu celku a ˇc´ast´ı. Naz´yv´a se kompozice viz Obr.(4.4). Graficky se liˇs´ı od agregace t´ım, ˇze symbol u celku je vybarven. U kompozice mohou ˇc´asti patˇrit vˇzdy jen jednomu celku, celek je zodpovˇedn´y za vytvoˇren´ı a zruˇsen´ı ˇc´ast´ı, a kdyˇz je zruˇsen´y celek, mus´ı b´yt zruˇseny vˇsechny jeho ˇc´asti. Je zˇrejm´e, ˇze s´emantika kompozice je velice podobn´a s´emantice atribut˚u a modeluje vlastnˇe tot´eˇz. Atribut bychom mˇeli pouˇz´ıt, jde-li o primitivn´ı typy nebo tˇr´ıdy, kter´e jsou souˇc´ast´ı jazyka nebo v pˇr´ıpadˇe, kdy nechceme tˇr´ıdu ex-plicitnˇe ukazovat v modelu. Z´akladn´ım pravidlem by mˇela b´yt jasnost, uˇziteˇcnost a srozumitelnost modelu.

• Generalizace je vztahem mezi obecnˇejˇs´ım prvkem a specielnˇejˇs´ım prvkem, kde spe-cielnˇejˇs´ı prvek je zcela konzistentn´ı s obecnˇejˇs´ım prvkem, ale obsahuje v´ıce informac´ı. Oba prvky se ˇr´ıd´ı principem nahraditelnosti. Ten znamen´a, ˇze m˚uˇzeme pouˇz´ıt spe-cielnˇejˇs´ı prvek vˇsude tam, kde je oˇcek´av´an prvek obecnˇejˇs´ı bez naruˇsen´ı syst´emu. V diagramu tˇr´ıd p˚ujde o vztah mezi tˇr´ıdami. Obecnˇejˇs´ı tˇr´ıda se naz´yv´a nadtˇr´ıdou a specielnˇejˇs´ı tˇr´ıda podtˇr´ıdou. Struktura vznikl´a uspoˇr´ad´an´ım tˇr´ıd podle vztahu ge-neralizace se naz´yv´a hierarchie generalizace. Urˇcitˇe si uvˇedomujete, ˇze z podstaty generalizace vypl´yv´a dˇediˇcnost - podtˇr´ıda dˇed´ı vˇsechny vlastnosti (atributy, operace, vztahy a omezen´ı vztahuj´ıc´ı se na objekty) sv´ych nadtˇr´ıd. Je rovnˇeˇz zˇrejm´e, ˇze jde o mnohem silnˇejˇs´ı vztah tˇr´ıd neˇz asociace. Z generalizace vypl´yv´a siln´a z´avislost obou tˇr´ıd. Na Obr.(4.5) tˇr´ıda Tˇr´ıdaA je nadtˇr´ıdou tˇr´ıdy Tˇr´ıdaB.

4.2.3 Diagram sekvence

Tak´e zn´am´y jako Sekvenˇcn´ı diagram, vizualizuje posloupnost zpr´av zas´ılan´ych mezi ´uˇcastn´ıky interakce. M˚uˇzeme v nˇem rozliˇsit dvˇe dimenze. Prvou (zleva doprava) je dimenze ´uˇcastn´ık˚u interakce. Jde o instance klasifik´ator˚u v UML, tedy typicky jde o instance akt´er˚u, tˇr´ıd, bal´ıˇck˚u nebo komponent. Graficky jsou zn´azornˇeny stejn´ym symbolem jako odpov´ıdaj´ıc´ı klasifik´ator (napˇr. u objektu tˇr´ıdy) a svislou ˇc´arkovanou ˇcarou. Ta je vlastn´ı

”ˇcarou ˇzivota“ ´

uˇcastn´ıka interakce. Na n´ı lze zn´azornit, kdy je instance aktivn´ı a kdy nevlastn´ı ˇz´adn´e vl´akno ˇr´ızen´ı. Druhou dimenz´ı (shora dol˚u) je ˇcas. Nen´ı vyj´adˇren explicitnˇe, ale zas´ılan´e zpr´avy se v diagramu zn´azorˇnuj´ı tak, jak jdou po sobˇe v ˇcase.

Zpr´avy reprezentuj´ı komunikaci mezi dvˇema ´uˇcastn´ıky interakce, kter´a m˚uˇze znamenat vol´an´ı metody, vytvoˇren´ı nebo zruˇsen´ı instance (´uˇcastn´ıka interakce) nebo zasl´an´ı sign´alu. Vyznaˇcuj´ı se horizont´aln´ımi ˇsipkami mezi ´uˇcastn´ıky. V pˇr´ıpadˇe vol´an´ı metody se st´av´a pˇrij´ımaj´ıc´ı ´uˇcastn´ık interakce aktivn´ı po dobu prov´adˇen´ı metody. Doba aktivace je vy-znaˇcena mal´ym obd´eln´ıkem na

”ˇc´aˇre ˇzivota“ ´uˇcastn´ıka. Diagram sekvence lze ale kres-lit i bez vyznaˇcen´ych aktivac´ı, resp. nˇekter´e n´astroje je ani nepodporuj´ı. Doporuˇcuje se zn´azorˇnovat aktivace pouze tehdy, kdyˇz nezp˚usob´ı menˇs´ı pˇrehlednost diagramu. Zp˚usob zn´azornˇen´ı ´uˇcastn´ık˚u interakce, zas´ıl´an´ı zpr´av jsou naznaˇceny na Obr.(4.6)

4.2.4 Diagram komunikace

Narozd´ıl od diagramu sekvence zd˚urazˇnuje statickou strukturu (propojen´ı objekt˚u), kter´a se vyuˇzije pˇri interakci k dosaˇzen´ı poˇzadovan´eho chov´an´ı, napˇr´ıklad definovan´eho nˇejak´ym pˇr´ıpadem pouˇzit´ı.Uk´azka viz Obr.(4.7)

Diagram komunikace m´a podobnou syntaxi jako diagram sekvence s t´ım rozd´ılem, ˇze nen´ı kreslen

”dvoudimenzion´alnˇe“. ´Uˇcastn´ıci interakce nemaj´ı ˇc´arkovan´e ˇc´ary pro ˇcasovou dimenzi. Proto je zde podstatn´e hierarchick´e ˇc´ıslov´an´ı zpr´av, kter´e definuje poˇrad´ı, vˇcetnˇe zanoˇren´ı. Vazby mezi ´uˇcastn´ıky interakce ukazuj´ı, jak odes´ılatel zpr´avy z´ısk´a

”kontakt“ na adres´ata. M˚uˇze to b´yt d´ıky asociaˇcn´ı vazbˇe, m˚uˇze j´ıt o glob´aln´ı ˇci lok´aln´ı objekt apod.

V diagramu lze vyj´adˇrit iterace i podm´ınky. Zejm´ena u podm´ınek je ale jejich praktick´e vyuˇzit´ı podstatnˇe menˇs´ı neˇz u diagram˚u sekvence, protoˇze podm´ınky se rozˇs´ıˇr´ı po cel´em diagramu a ten se brzy stane nepˇrehledn´y. Doporuˇcuje se proto na diagramu komunikace ukazovat jen velmi jednoduch´e vˇetven´ı. Mnohem jednoduˇsˇs´ı je uk´azat sloˇzit´a vˇetven´ı na diagramu sekvence.

Diagramy komunikace jsou velmi vhodn´e k prvotn´ımu rychl´emu naˇcrtnut´ı spolupr´ace objekt˚u a pˇri iterativn´ım modelov´an´ı metodou pokus˚u a omyl˚u. Proto jsou uˇziteˇcn´e pˇri diskuz´ıch a brainstormingu.

4.2.5 Diagram nasazen´ı

Ukazuje nasazen´ı softwarov´ych prvk˚u na fyzickou architekturu a d´ale ukazuje komunikaci (zpravidla na s´ıti) mezi fyzick´ymi prvky. Jin´ymi slovy, mapuje softwarovou architekturu, kter´a je v´ysledkem n´avrhu, na fyzickou architekturu syst´emu. V pˇr´ıpadˇe distribuovan´eho syst´emu modeluje distribuci software ve fyzick´ych uzlech. Diagram nasazen´ı je uˇziteˇcn´y pro komunikaci v´yvoj´aˇr˚u navz´ajem a se z´akazn´ıkem v z´aleˇzitostech t´ykaj´ıc´ıch se celkov´e (vˇcetnˇe hardware) architektury syst´emu. Uk´azka Obr.(4.8)

4.3

Vlastn´ı n´

avrh

Na z´akladˇe prostudov´an´ı materi´al˚u ke tvorbˇe n´avrhu syst´em˚u, vznikly n´asleduj´ıc´ı diagramy. Diagram aktivit Obr.(4.9), diagram tˇr´ıd Obr.(4.10), sekvenˇcn´ı diagramy Obr.(4.11a4.12), diagram komunikace Obr.(4.13) a diagram nasazen´ı Obr.(4.14).

• Diagram aktivit – Zde je navrˇzena pˇredstava fungov´an´ı SpravaZapasu. Moˇznosti co vˇse je moˇzn´e dˇelat se Z´apasem a akcemi v nˇem.

• Diagram tˇr´ıd – Tady uˇz je jasnˇe zˇreteln´a struktura cel´eho syst´emu. Rozvrˇzen´ı pomoc´ı architektury MVC.

• Sekvenˇcn´ı diagram – Na tˇechto dvou diagamech je patrn´e vol´an´ı zpr´av jednotliv´ych tˇr´ıd pˇri pˇrihlaˇsov´an´ı a pˇr´ıd´av´an´ı g´olu.

• Diagram komunikace – Zde je patrn´e chov´an´ı pˇri pˇrihlaˇsov´an´ı.

• Diagram nasazen´ı – Na tomto diagramu je uvedeno jak bude vypadat nasazen´ı syst´emu do provozu.

4.4

Literatura

Obr´azek 4.1: pˇr´ıklad diagramu aktivit

Obr´azek 4.2: pˇr´ıklad asociace

Obr´azek 4.4: pˇr´ıklad kompozice

Obr´azek 4.5: pˇr´ıklad generalizace

Obr´azek 4.7: pˇr´ıklad diagramu komunikace

Kapitola 5

Implementace

Tato kapitola se zab´yv´a demonstraˇcn´ı implementac´ı syst´emu. Rozebere si zde nˇekter´e vlast-nosti jazyka PHP. Pˇribl´ıˇz´ıme si JavaScript a MySQL. D´ale si zm´ın´ıme nˇektera pravidla tvorby uˇzivatelsk´ych rozhran´ıch.

5.1

PHP

5.1.1 O PHP

PHP (rekurzivn´ı zkratka PHP: Hypertext Preprocessor,

”PHP: Hypertextov´y preprocesor“, p˚uvodnˇe Personal Home Page) je skriptovac´ı programovac´ı jazyk, urˇcen´y pˇredevˇs´ım pro pro-gramov´an´ı dynamick´ych internetov´ych str´anek. Nejˇcastˇeji se zaˇcleˇnuje pˇr´ımo do struktury jazyka HTML, XHTML ˇci WML, coˇz je velmi v´yhodn´e pro tvorbu webov´ych aplikac´ı. PHP lze ovˇsem tak´e pouˇz´ıt i k tvorbˇe konzolov´ych a desktopov´ych aplikac´ı.

PHP skripty jsou prov´adˇeny na stranˇe serveru, k uˇzivateli je pˇren´aˇsen aˇz v´ysledek jejich ˇcinnosti. Syntaxe jazyka kombinuje hned nˇekolik programovac´ıch jazyk˚u (Perl, C, Pascal a Java). PHP je nez´avisl´y na platformˇe, skripty funguj´ı bez ´uprav na mnoha r˚uzn´ych operaˇcn´ıch syst´emech. Obsahuje rozs´ahl´e knihovny funkc´ı pro zpracov´an´ı textu, grafiky, pr´aci se soubory, pˇr´ıstup k vˇetˇsinˇe datab´azov´ych server˚u (mj. MySQL, ODBC, Oracle, PostgreSQL, MSSQL), podporu cel´e ˇrady internetov´ych protokol˚u (HTTP, SMTP, SNMP, FTP, IMAP, POP3, LDAP,. . . )

PHP se stalo velmi obl´ıben´ym pˇredevˇs´ım d´ıky jednoduchosti pouˇzit´ı a tomu, ˇze kom-binuje vlastnosti v´ıce programovac´ıch jazyk˚u a nech´av´a tak v´yvoj´aˇri ˇc´asteˇcnou svobodu v syntaxi. V kombinaci s datab´azov´ym serverem (pˇredevˇs´ım s MySQL nebo PostgreSQL) a webov´ym serverem Apache je ˇcasto vyuˇz´ıv´an k tvorbˇe webov´ych aplikac´ı. D´ıky velmi ˇ

cast´emu nasazen´ı na serverech se vˇzila zkratka LAMP - tedy spojen´ı Linux, Apache, MySQL a PHP nebo Perl.

S verz´ı PHP 5 se v´yraznˇe zlepˇsil pˇr´ıstup k objektovˇe orientovan´emu programov´an´ı po-dobn´y Javˇe.

5.1.2 Historie

Od roku 1994 je PHP jedn´ım z nejpouˇz´ıvanˇejˇs´ıch zp˚usob˚u tvorby dynamicky generovan´ych WWW str´anek. Jeho tv˚urce (Rasmus Lerdorf) jej vytvoˇril pro svou osobn´ı potˇrebu pˇreps´an´ım z Perlu do jazyka C. Sada skript˚u byla vyd´ana jeˇstˇe v t´emˇze roce pod n´azvem Personal Home Page Tools, zkr´acenˇe PHP.

V polovinˇe roku se syst´em PHP spojil s programem Form Interpreter stejn´eho autora. Tak vzniklo PHP/FI 2.0. Zeev Suraski a Andi Gutmans v roce 1997 pˇrepsali parser a zformovali tak z´aklad PHP3. Souˇcasnˇe byl n´azev zmˇenˇen na dneˇsn´ı podobu PHP Hypertext Preprocessor. PHP3 vyˇslo v roce 1998, bylo rychlejˇs´ı, obsahovalo v´ıce funkc´ı. Tak´e bˇeˇzelo i pod operaˇcn´ım syst´emem Windows.

V roce 2000 vych´az´ı PHP verze 4, o ˇctyˇri roky pozdˇeji pak verze 5 s vylepˇsen´ym objek-tov´ym pˇr´ıstupem, podobn´ym jazyku Java.

5.1.3 V´yhody a Nev´yhody

V´yhody:

• PHP je relativnˇe jednoduch´e na pochopen´ı. . .

• PHP m´a syntaxi velmi podobnou jazyku C a je tedy vˇetˇsinˇe v´yvoj´aˇr˚u dost bl´ızk´y. . . • PHP podporuje ˇsirokou ˇradu souvisej´ıc´ıch technologi´ı, form´at˚u a standard˚u. . . • je to otevˇren´y projekt s rozs´ahlou podporou komunity. . .

• daj´ı se naj´ıt kvanta jiˇz hotov´eho k´odu k okamˇzit´emu pouˇzit´ı nebo funkˇcn´ı PHP apli-kace. Podstatn´a ˇc´ast z hotov´eho k´odu je ˇs´ıˇrena pod nˇejakou svobodnou licenc´ı a d´a se pouˇz´ıt ve vlastn´ıch projektech. . .

• PHP si dobˇre rozum´ı s webov´ym serverem Apache. . .

• PHP snadno komunikuje s datab´azemi, jako je MySQL, PostgreSQL a ˇrada dalˇs´ıch. . . • PHP je multiplatformn´ı a lze jej provozovat s vˇetˇsinou webov´ych server˚u a na vˇetˇsinˇe

dnes existuj´ıc´ıch operaˇcn´ıch syst´em˚u. . .

• PHP podporuje mnoho existuj´ıc´ıch poskytovatel˚u webhostingov´ych sluˇzeb. . . Nev´yhody:

• PHP je interpretovan´y, ne kompilovan´y jazyk. . .

• kdokoli m´a pˇr´ım´y pˇr´ıstup k serveru, m˚uˇze nahl´ednout do vaˇsich PHP skript˚u. . . • protoˇze je PHP aktivnˇe vyv´ıjen, v budouc´ıch verz´ıch jazyka se mohou nˇekter´e funkce

zmˇenit nebo se mohou chovat jinak neˇz dosud. . .

5.2

JavaScript

Jde o multiplatformn´ı, objektovˇe orientovan´y skriptovac´ı jazyk, jehoˇz autorem je Brendan Eich z tehdejˇs´ı spoleˇcnosti Netscape.

Nyn´ı se zpravidla pouˇz´ıv´a jako interpretovan´y programovac´ı jazyk pro WWW str´anky, ˇ

casto vkl´adan´y pˇr´ımo do HTML k´odu str´anky. Jsou j´ım obvykle ovl´ad´any r˚uzn´e interaktivn´ı prvky GUI (tlaˇc´ıtka, textov´a pol´ıˇcka) nebo tvoˇreny animace a efekty obr´azk˚u.

Jeho syntaxe patˇr´ı do rodiny jazyk˚u C/C++/Java. Slovo Java je vˇsak souˇc´ast´ı jeho n´azvu pouze s marketingov´ych d˚uvod˚u a s programovac´ım jazykem Java jej vedle n´azvu spojuje jen podobn´a syntaxe. JavaScript byl v ˇcervenci 1997 standardizov´an asociac´ı ECMA

(Europen Computer Manufacturers Association) a v srpnu 1998 ISO (International Or-ganization for Standardisation). Standardizovan´a verze JavaScriptu je pojmenov´ana jako ECMAScript a z n´ı byly odvozeny i dalˇs´ı implementace, jako je napˇr´ıklad ActionScript. Pouˇz´ıvan´y pˇri v´yvovoji Flash aplikac´ı v na´astroj´ıch od spoleˇcnosti Adobe.

JavaScript byl p˚uvodnˇe obchodn´ı n´azev implementace spoleˇcnosti Netscape, kde byl vyv´ıjen nejprve pod n´azvem Mocha, pozdˇeji LiveScript, ohl´aˇsen byl spoleˇcnˇe se spoleˇcnost´ı Sun Microsystems v prosinci 1995 jako doplnˇek k jazyk˚um HTML a Java. Pro verzi firmy Microsoft je pouˇzit n´azev JScript.

Program v JavaScriptu se obvykle spouˇst´ı aˇz po staˇzen´ı WWW str´anky z Internetu (tzv. na stranˇe klienta), na rozd´ıl od ostatn´ıch jin´ych interpretovan´ych programovac´ıch jazyk˚u (napˇr. PHP a ASP), kter´e se spouˇstˇej´ı na stranˇe serveru jeˇstˇe pˇred staˇzen´ım z Internetu. Z toho plynou jist´a bezpeˇcnost´ı omezen´ı, JavaScript napˇr. nem˚uˇze pracovat se soubory, aby t´ım neohrozil soukrom´ı uˇzivatele.

5.3

MySQL

S datab´azemi se samozˇrejmˇe setk´av´ame dennˇe. V nejˇsirˇs´ım slova smyslu je datab´aze i se-znam vˇec´ı, kter´e si m˚uˇzeme nakoupit k obˇedu, v´ypis z ´uˇctu nebo tˇrebas seznam uskuteˇcnˇen´ych telefonn´ıch hovor˚u. V poˇc´ıtaˇcov´em slova smyslu se pod v´yrazem

”datab´aze“ obvykle rozum´ı software, kter´y spravuje urˇcit´y

”bal´ık“ dat a umoˇzˇnuje uˇzivatel˚um tento ”bal´ık“ dat nˇejak rozumnˇe mˇenit a spravovat.

Datab´aze nen´ı jen prost´e shromaˇzdiˇstˇe, ´uloˇziˇstˇe dat, ale ˇze vˇetˇsinou slouˇz´ı z´aroveˇn k jejich organizaci, tˇr´ıdˇen´ı, prohled´av´an´ı, seskupov´an´ı a podobnˇe. K typick´e dneˇsn´ı datab´azi patˇr´ı rovnˇeˇz to, ˇze z´aroveˇn chce s daty pracovat v´ıce uˇzivatel˚u.

S t´ım souvis´ı jin´a d˚uleˇzit´a vˇec: S rozvojem s´ıt´ı a zejm´ena internetu se stalo obvykl´e, ˇ

ze datab´aze mohou b´yt pˇr´ıstupn´e vzd´alenˇe. Takov´a datab´aze um´ıstˇen´a centr´alnˇe m˚uˇze poskytovat data mnoha v´ıcem´enˇe nez´avisl´ym odbˇeratel˚um. Z cel´eho toho popisu bude pravdˇepodobnˇe vˇsem zˇrejm´e, ˇze datab´azov´e programy obecnˇe zaˇz´ıvaj´ı zlat´e ˇcasy a ˇze da-tab´az´ı bude existovat cel´a ˇrada.

Rozdˇelit datab´aze je kupodivu ˇc´ım d´al t´ım sloˇzitˇejˇs´ı, protoˇze jednotliv´a krit´eria se v posledn´ı dobˇe vz´ajemnˇe pˇrekr´yvaj´ı a mnoho datab´az´ı um´ı hodnˇe podobn´ych vˇec´ı. Nicm´enˇe, pokus´ıme se alespoˇn nast´ınit, jak r˚uznˇe se daj´ı datab´aze dˇelit.

• Objektov´e a relaˇcn´ı – tam se datab´aze liˇs´ı podle zp˚usobu, jak ukl´adaj´ı data. Dle datov´eho modelu. Relaˇcni sch´ema dat a objektov´y pohled na data. Ve svˇetˇe pˇrevl´ad´a relaˇcn´ı model. . .

• Jednouˇzivatelsk´e a v´ıceuˇzivatelsk´e – Podle toho, kolik uˇzivatel˚u se k datab´azi m˚uˇze pˇripojit. Pochopitelnˇe, v komerˇcn´ı sf´eˇre jednouˇzivatelsk´ym datab´az´ım prakticky od-zvonilo. Je ale uˇziteˇcn´e vˇedˇet, ˇze i v´ıceuˇzivatelskou datab´azi lze vˇetˇsinou nakonfiguro-vat jako jednouˇzivatelskou a ˇze to m˚uˇze m´ıt sv´e opodstatnˇen´ı. MySQL je v´ıceuˇzivatelsk´a datab´aze. . .

• Souborov´e a syst´emov´e – liˇs´ı se t´ım, zda pouˇzij´ı pro uloˇzen´ı dat jeden soubor, nebo zda je ´uloˇziˇstˇe dat nˇejak zabudov´ano do syst´emu. U souborov´ych datab´az´ı typicky staˇc´ı pˇr´ısluˇsn´y soubor pˇren´est na jin´y stroj a m˚uˇze b´yt ihned pouˇz´ıv´an, u syst´emov´ych da-tab´az´ı se mus´ı z´aloha a obnova dˇelat nˇejak jinak. V posledn´ı dobˇe toto dˇelen´ı ponˇekud ztratilo v´yznam, protoˇze vˇetˇsina datab´az´ı je syst´emov´ych. MySQL je syst´emov´a da-tab´aze. . .

• Podle licence a ceny – K´od datab´aze m˚uˇze b´yt uzavˇren´y nebo otevˇren´y, ˇs´ıˇren´ı software m˚uˇze b´yt svobodn´e nebo m˚uˇze podl´ehat nˇejak´ym podm´ınk´am, datab´aze se m˚uˇze vyuˇz´ıvat bez poplatk˚u nebo m˚uˇze j´ıt o placen´e software. Licence MySQL je du´aln´ı, je trochu sloˇzit´a a nebudeme se j´ı v t´eto pr´aci zab´yvat. . .

• Podle toho, kde je provozov´ana – na jednoplatformn´ı a multiplatformn´ı – Jednoplat-formn´ı pobˇeˇz´ı jen na nˇekter´em syst´emu (tˇreba na Windows), multiplatformn´ı na v´ıce syst´emech. MySQL je multiplatformn´ı datab´aze a bˇeˇz´ı na syst´emech GNU/Linux, Microsoft Windows, FreeBSD, Sun Solaris, IBM’s AIX, Mac OS X, HP-UX, AIX, QNX, Novell NetWare, SCO OpenUnix, SGI Irix, and Dec OSF. . .

• Podle velikosti, v´ykonu a vhodnosti nasazen´ı – Datab´aze m´ıvaj´ı limity ve velikosti, poˇctu souˇcasnˇe pˇrihl´aˇsen´ych uˇzivatel˚u, poˇctu souˇcasnˇe prob´ıhaj´ıc´ıch proces˚u a po-dobnˇe. Je tˇeˇzk´e nˇekam zaˇradit MySQL. Obecnˇe je totiˇz obt´ıˇzn´e nˇejak rovnopr´avnˇe posoudit datab´aze. Diplomaticky m˚uˇzeme ˇr´ıci, ˇze MySQL je nˇekde uprostˇred pomy-sln´eho ˇzebˇr´ıˇcku vhodnosti nasazen´ı a ˇze v mal´ych aˇz stˇredn´ıch projektech ji rozhodnˇe pouˇz´ıt m˚uˇzete. . .

Datab´aze lze samozˇrejmˇe dˇelit i podle cel´e ˇrady dalˇs´ıch krit´eri´ı. Nejd˚uleˇzitˇejˇs´ı pˇritom je, co vˇsechno dan´a datab´aze

”um´ı“ s daty prov´adˇet.

MySQL je velmi popul´arn´ı datab´aze. Podle mnoha dostupn´ych studi´ı je to rovnˇeˇz velmi rychl´a datab´aze. Nem´a vˇsak tolik funkc´ı a moˇznost´ı jako nˇekter´e konkurenˇcn´ı datab´azov´e syst´emy. Vybrat si vhodnou datab´azi je tedy klasick´y kompromis mezi rychlost´ı softwaru a jeho schopnostmi. MySQL m´a samozˇrejmˇe sv´e zast´ance a odp˚urce. Odp˚urci napˇr´ıklad ˇcasto tvrd´ı, ˇze MySQL je tak rozˇs´ıˇren´a proto, ˇze webhostingov´e spoleˇcnosti ji ˇcasto nab´ızej´ı pro hostovan´e weby jako souˇc´ast portfolia sv´ych sluˇzeb. Kdyby se webhostingov´e spoleˇcnosti rozhodly upˇrednostnit jin´y software, popularita MySQL by podle jejich odp˚urc˚u podstatnˇe klesla.

Naproti tomu zast´anci MySQL tvrd´ı, ˇze webhostingov´e spoleˇcnosti nab´ızej´ı MySQL proto, ˇze je pro nab´ızen´e sluˇzby vhodn´a, a kdyby existovala lepˇs´ı datab´aze neˇz MySQL, byla by nab´ızena. Zast´anci MySQL prostˇe tvrd´ı, ˇze trh si MySQL vybral - a to podle nich jasnˇe poukazuje na jej´ı kvality.

5.4

CSS

HTML je znaˇckovac´ı jazyk, z toho vypl´yv´a, ˇze jednotliv´e znaˇcky maj´ı vyznaˇcovat v´yznam jednotliv´ych ˇc´ast´ı textu. Pˇresto se v HTML v pr˚ubˇehu let objevilo nˇekolik atribut˚u a ele-ment˚u, kter´e ovlivˇnuj´ı pouze grafick´y vzhled, a nˇekter´e z p˚uvodn´ıch tag˚u urˇcen´ych pro logisk´e ˇclenˇen´ı textu, je ˇcasto ´uˇcelovˇe vyuˇz´ıv´ano k dosaˇzen´ı urˇcit´ych grafick´ych efekt˚u. Aby se pˇredeˇslo tˇemto neˇsvar˚um, a bylo moˇzn´e jednoduˇse oddˇelit struktur´aln´ı form´atov´an´ı textu od grafick´eho form´atov´an´ı, definovalo v roce 1997 koncorsium W3C soubor metod pro gra-fickou ´upravu webov´ych str´anek. Tento soubor metod se jmenuje Cascading Style Sheets (CSS), ˇcesky

”kask´adov´e styly“.

Kask´adov´e styly umoˇzˇnuj´ı definovat zp˚usob zobrazen´ı (velikost a druh p´ısma, barvu, zarovn´an´ı, or´amov´an´ı, pozad´ı apod.) u kaˇzd´eho html elementu. Tento pˇredpis vzhledu nen´ı pˇr´ımo souˇc´ast´ı textu str´anky, a d´ıky tomu je z´apis str´anky pˇrehlednˇejˇs´ı a dobˇre strukturo-van´y. Nav´ıc styly umoˇzˇnuj´ı definovat jednotn´y vzhled konkr´etn´ıho elementu v cel´em doku-mentu jedn´ım z´apisem tzn. nemus´ı se opakovat u kaˇzd´eho elementu. Pokud styl uloˇz´ıme do extern´ıho souboru, m˚uˇze ho vyuˇz´ıvat v´ıce str´anek najednou. Definice vzhledu vˇsech str´anek

je uloˇzena na jednom m´ıstˇe. Pˇri poˇzadavku na zmˇenu vzhledu str´anek, staˇc´ı upravit styl na jednom m´ıstˇe, a zmˇeny se automaticky prom´ıtnou do vˇsech str´anek.

Jak je bˇeˇzn´e ve svˇetˇe webdesignu, i podpora kask´adov´ych styl˚u v jednotliv´ych prohl´ıˇzeˇc´ıch webov´ych str´anek je r˚uzn´a. Jednotliv´e prohl´ıˇzeˇce maj´ı vlastn´ı v´yklad ˇci pravidla CSS.

5.5

Pˇ

rehled syst´

emu

Zde si na nˇekolika screenshotech uk´aˇzeme vzhled syst´emu Obr.(5.1,5.2,5.3). A nektˇerou z naplnˇen´ych tabulek Obr.(5.4).

Obr´azek 5.1: vzhled syst´emu

5.6

Literatura

V t´eto kapitole byla pouˇzity tyto knihy [3, PHP] a webov´e str´anky [7, Linuxsoft], [11, interval], [9, phpNet].

Obr´azek 5.2: vzhled syst´emu

Kapitola 6

Z´

avˇ

er

V t´eto kapitole zhodnot´ıme dosaˇzen´e v´ysledky a budeme zde diskutovat moˇznosti rozˇs´ıˇren´ı.

6.1

Splnˇ

en´ı poˇ

zadavk˚

u zad´

an´ı

Na z´akladˇe zad´an´ı byl proveden detailn´ı n´avrh syst´emu. Ten je pops´an pomoc´ı diagram˚u v kapitole4.3. Diagramy byly zvoleny vhodnˇe na z´akladˇe prostudov´an´ı metod tvorby n´avrhu. Diagramy byly vytvoˇreny v programu Visual Paradigm (Community Edition). Pro-gram v mnoh´em pˇrevyˇsuje prostˇredky Rational Rose. Kter´y jsme pouˇz´ıvali v 1.roˇcn´ıku bakal´aˇrsk´eho studia. Visual Paradigm ma velmi prehledn´e uˇzivatelsk´e rozhran´ı. A dovo-luje tvorbu ˇsirok´e ˇsk´aly UML diagram˚u. Pokud se vytvoˇr´ı vˇsechny diagramy, tak dovoluje vygenerovat ˇc´ast k´odu.

C´ılem pr´ace bylo vytvoˇrit pouze demonstraˇcn´ı implementaci, kter´a bude demonstro-vat pouze z´akladn´ı funkˇcnost navrˇzen´eho syst´emu. Hlavn´ı implementovan´e funkce jsou pˇrihlaˇsov´an´ı, odhlaˇsov´an´ı, registrace uˇzivatele, prohliˇzen´ı t´ym˚u a hr´aˇc˚u, pˇrid´av´an´ı hr´aˇc˚u, vytvoˇren´ı tabulky skupin, v´ysledky z´apas˚u, spr´ava ´uˇct˚u a nastaven´ı.

Cel´y IS se bez probl´em˚u korektnˇe zobrazuje v dneˇsn´ı dobˇe v nejv´ıce rozˇs´ıˇren´ych webov´ych prohl´ıˇzeˇc´ıch, jimiˇz jsou Internet Explorer 6, Opera 9.0 a vyˇsˇs´ıch, Mozilla Firefox 2.0 a vyˇsˇs´ıch.

6.2

Srovn´

an´ı s ostatn´ımy syst´

emy

Celkov´e srovn´an´ı s jin´ymi webov´ymi syst´emy je prakticky nemoˇzn´e, protoˇze webov´ych syst´emu existuje pˇr´ıliˇs velk´y poˇcet, pˇriˇcemˇz jejich kvalita se v´yraznˇe liˇs´ı syst´em od syst´emu. Ovˇsem podstatn´e klady vytvoˇren´eho syst´emu jsou v tom, ˇze je validn´ı vzhledem k webov´ym standard˚um, snaˇz´ı se udrˇzovat dobrou pˇrehlednost a ovladatelnost, atd.

6.3

Rozˇ

s´ıˇ

ren´ı

Syst´em umoˇzˇnuje mnoho rozˇs´ıˇren´ı. A to skoro v kaˇzd´e ˇc´asti.

Jednou z moˇzn´ych rozˇs´ıˇren´ı je vytvoˇren´ı jednoducheho diskuzn´ıho f´ora k jednotliv´ym z´apas˚um, kde by mohli registrovan´ı uˇzivatel´e pˇripisovat sve n´azory, postˇrehy apod.

Dalˇs´ı moˇznost´ı je odes´ılan´ı SMS o pr˚ubˇehu aktu´aln´ıho z´apasu a v´ysledn´em stavu z´apasu. Samozˇrejme by zde musela b´yt urˇcit´a forma zabezpeˇcen´ı, aby d˚uvˇern´a data nebyly volnˇe pˇr´ıstupn´e pro ostatn´ı uˇzivatele tzn. ˇsifrovan´a komunikace mezi klientem a serverem.

Kromˇe moˇznost´ı ´upravy funkˇcnosti, lze tak´e upravit pomoc CSS vzhled syst´emu. Barvy, rozloˇzen´ı na str´ance apod.

6.4

Literatura

Literatura

[1] Jim Arlow. UML a unifikovan´y proces v´yvoje aplikac´ı. Computer Press, 2003. [2] Eric Freeman. Head First Design Patterns. 2004.

[3] Jason Gilmore. Velk´a kniha PHP 5 MySQL :kompendium znalost´ı pro zaˇc´ateˇcn´ıky i profesion´aly. Zoner Press, 2005.

[4] Tom´aˇs Hruˇska. Studijn´ı opora k pˇredmˇetu IIS. 2006.

[5] Brett McLaughlin. Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OOAD. 2006.

[6] R Pecinovsk´y. N´avrhov´e vzory. Computer Press, 2007.

[7] WWW str´anky. Mysql, javascript, php. http://www.linuxsoft.cz. [8] WWW str´anky. Objektov´a anal´yza, n´avrh a programov´an´ı.

http://www.objekty.vse.cz.

[9] WWW str´anky. Php. http://www.php.net/.

[10] WWW str´anky. Pokyny ke zpracov´an´ı diplomov´ych a roˇcn´ıkov´ych projekt˚u. http://www.fit.vutbr.cz/info/statnice/.

[11] WWW str´anky. Tvorba webov´ych str´anek. http://www.interval.cz. [12] Jaroslav Zendulka. Anal´yza a n´avrh informaˇcn´ıch syst´em˚u. 2006. [13] Jaroslav Zendulka. Studijn´ı opora k pˇredmˇetu IDS. 2006.