Vysoké učení technické v Brně
Fakulta elektrotechniky a komunikačních technologií
Ústav mikroelektroniky
Souhrnná analýza návrhů informačních systémů,
technologií a metodik
Diplomová práce
Brno 2002
Milan Beneš
2
3
Prohlášení:
Tímto prohlašuji, že jsem tuto práci zpracoval samostatně s využitím níže uvedené užité
literatury, sítě Internet a pomocných pracovních textů. Při přejímání informací jsem byl kvůli
přehlednosti občas nucen k doslovným citacím, aniž bych tyto v textu explicitně zdůrazňoval.
___________________
Milan Beneš
4
Poděkování:
Na tomto místě bych rád poděkoval všem, kteří mají zásluhu na tom, že tato práce byla
vypracována v termínu. Mé poděkování patří zejména Aničce Zahradníkové za korekci
draftového textu, Luďku Šandovi za zasvěcení do obsluhy užívaným programových
prostředků, Michalu Štrbovi a Petru Pavlatovi, kteří mě konečně naučili řádně psát ve
Wordu :) a samozřejmě paní Ing. Janě Trunkátové, CSc., bez jejíž nekonečné trpělivosti by
tato práce vůbec nemohla vzniknout.
___________________
Milan Beneš
5
Anotace k textu:
Jak již vyplývá z názvu, jedná se o práci zabývající se návrhem informačních systémů
a popisem metodik používaných při tomto návrhu. Práce je členěna na teoretickou
a praktickou část.
Teoretická část si neklade za cíl být detailní deskripcí veškerých metodik pro návrh
informačních systémů. Toto není možné zejména kvůli omezením v rozsahu. Jedná se spíše
o určitý ucelený souhrn základních poznatků v dané oblasti. Tato práce má šanci být
užitečným průvodcem člověka, který je schopen analytického myšlení, ale uvedené metodiky
zatím neovládá. Zvládnutí těchto metodik mu propůjčí nový pohled na běžně řešené problémy
- ať už z informační oblasti nebo úplně z jiné sféry života.
První praktická část ukazuje postup návrhu informačního systému pro specifické požadavky
jedné naší velké společnosti - PVT a. s. (projekt probíhal pod dikcí dodavatele hardwarové
části informačního systému - firmy Autocont a.s.). Z tohoto postupu je patrné, jak takový
návrh vlastně probíhá a jak je složité ho realizovat.
Druhá praktická část demonstruje běžně užívané programové prostředky i výstupy
z některých z nich. V této části byl autor poněkud omezen limitovanou licencí (tzv. trial
licencí čili časově a provozně omezenou) k programům ERwin, BPwin a Powersim Studio.
I přesto se zde podařila provést zajímavá „demonstrace síly" tohoto programového vybavení.
Summary:
As the name of this work reveal, the main topic of this work is information system design
and description of methodologies used in the design. The work is divided into two main parts
theoretic and practical.
It is not a goal of theoretic part to be detailed description of all methodologies used in the
design. This is simply not possible due to a range limitations of the work. Instead the theoretic
part can be the digest of the most important knowledge in this area. This work has a chance to
be a guide for anybody who is able to do an analysis but does not know all about these
methodologies. Mastering these methodologies will give him a good experience which can be
used either for solving problems with design of information system either for solving common
problems of everyday life.
The practical part is again divided into two subparts. The first shows us design of concrete
information system for specific requirements of the PVT corporation (the project was made
under the diction of the Autocont corporation.) From this part it is evident, how the design of
this type can proceed and how it is difficult to realize it.
The second subpart demonstrates the common used software for the design and the output
of this software. In this part the author was restricted by the limited trial license of the
programs ERwin, BPwin and Powersim Studio. In spite of this fact, this part shows us the
power of this program equipment.
____________________
Milan Beneš
6
Obsah:
strana
Teoretická část práce:
1.
Úvod do problematiky
9
2.
Návrh informačních systémů
11
3.
Model jednání
31
4.
Funkční model, modelování a analýza
36
5.
Databáze, jazyk SQL, datový model a datová analýza
44
6.
Objektové modelování
58
7.
Dynamické modelování
64
Praktická část práce:
8.
Návrh systému pro kontrolu oprávněnosti
70
9.
Program ERwin
95
10.
Program BPwin
100
11.
Program Powersim Studio
105
12.
Případové studie - simulace dynamických procesů
109
13.
Zhodnocení výsledků práce
118
14.
Užitá literatura
119
7
Poznámky čtenáře:
8
Poznámky čtenáře:
9
1. Úvod do problematiky
Informační systémy, informační technologie a metodiky návrhu v současné době pro moderní
hospodářský subjekt nabírají na významu. Jedním z hlavních producentů bohatství jsou dnes
informace a znalosti. Informace se staly cenným podnikovým zdrojem. Významnou
skutečností, která si vynucuje existenci kvalitního IS (informačního systému), je i zrychlující
se dynamika trhů a produkčních cyklů. I technologicky dokonalé výrobky se udržují na trhu
v nezměněné podobě stále kratší dobu. Klasickým příkladem je současný trh s výpočetní
technikou. Nový produkt se na tomto trhu udrží 3-5 měsíců než je vystřídán inovací. Další
důležitou skutečností je globalizace trhů. Firma tak má nyní mnohem více konkurentů než
kdykoli předtím v minulosti. Významné firmy nyní působí globálně tzn. snaží se optimálně
využívat zdroje v mnoha zemích světa a celosvětově nabízet svou produkci. Dochází rovněž
ke globalizaci na úrovni podnikového managementu tzn. je preferován jednotný koncept
řízení. Ke sjednocování postupů dochází i v ostatních oblastech. Když si toto uvědomíme,
zjistíme, že v takovéto situaci nám aplikovaný IS/IT (informační systém/informační
technologie) může výrazně pomoci zejména díky své schopnosti prosazovat jednotnost
procesů a řízení. Je-li daný proces automatizován, IS/IT de facto vnucuje jednotný způsob
chování, protože nestandardní postupy neakceptuje. I opačný trend od unifikace
k individualismu, který můžeme pozorovat na straně přístupu k zákazníkovi vyžaduje
podporu IT a mnohdy by bez nich ani nemohl být zajištěn. Dále se setkáváme s faktorem
obtížné predikovatelnosti vývoje, která vyžaduje vysokou adaptibilitu podniku. I zde nám IT
mohou velmi usnadnit řešení problémů s tímto spojených. Hlavním argumentem proč zavádět
IS/IT je však zejména potřeba informací, a to jak o okolí firmy, tak i o vnitropodnikových
procesech. IS/IT hrají v této oblasti stále významnější roli např. při realizaci „Just-in-Time"
dodávek, kdy dochází ke koordinaci všech dodávek. Dalším podmětem pro zavedení IS může
být třeba zavádění ISO norem. Z výše uvedeného je patrné, že zavedení IS/IT přináší
ve střednědobém horizontu významnou konkurenční výhodu.
Při realizaci návrhu nepostupujeme chaoticky nýbrž se držíme zavedených postupů a metodik,
které nám výrazně usnadňují celý návrh. Kdybychom takto nepostupovali, tak by náš návrh
nebyl kompletní, nebyl by přehledný a zejména by nebyl homogenní. Nekvalitně či zmatečně
navržený systém nám nejenom nepomůže, nýbrž může být i zdrojem nejrůznějších problémů
či bezpečnostních děr apod. Vzniká nám zde nová specializace lidí - analytiků, návrhářů, kteří
jsou odpovědní za kvalitní návrh systému. Právě postupy návrháře, které jsou prováděny
podle jednotlivých metodik v koordinaci s požadavky vedení dotyčné firmy, jsou hlavním
tématem této práce. Těžištěm práce jsou jednotlivé metodiky návrhu. Dále je zde rozebrán
celý postup návrhu od převzetí zadání až po cílovou implementaci. Tento postup je pak
demonstrován v praktické části práce.
Práce je rozčleněna na teoretickou část, která se zabývá popisem metodik a praktickou část,
která ukazuje vlastní návrh a recenzuje programy, které se obecně v této oblasti užívají.
Teoretická část (kapitoly 2-7) předchází praktickou. V kapitole 2 je popsán postup návrhu IS
od rozboru zadání po implementaci. Nejprve jsou zde vysvětleny základní pojmy, poté je
chronologicky popsán vlastní postup při návrhu ve všech jeho fázích. Během popisu návrhu
jsou průběžně vysvětlovány další užívané pojmy. Ve zbývajícím oddíle teoretické části
(kapitoly 3-7) jsou vysvětleny jednotlivé modely. Nejprve je v kapitole 3 nastíněn často
používaný Model jednání, u kterého je výhodné začít praktickou výstavbu IS. Tento model
totiž ve většině případů vytváříme přímo z tzv. podrobného zadání jako vůbec první model
návrhu. V kapitole 4 je přiblížen Funkční model, který nám slouží k algoritmizaci celého
10
řešeného problému. Zde se jedná o jednu ze dvou základních koncepcí modelových schémat.
Druhou základní koncepci nám rozebírá kapitola 5, která popisuje základy Datového modelu,
jako přístupu nastiňujícího informační potřeby. Je zde v základních souvislostech vylíčena
návaznost na databázové zpracování a jazyk SQL. Dále je v kapitole 6 čtenář seznámen
s Objektovým modelem, tedy s jakýmsi rozšířením stávajících modelů o v této souvislosti
přínosný objektový přístup. Tento typ modelu je výhodné použít v pokročilé fázi návrhu IS
jako hlavní oporu pro podrobný popis IS. V závěru teoretické části (kapitola 7) je rozebrán
Dynamický model, který nám umožňuje pochopit a analyzovat i složité dynamické systémy.
Obecně se dá říci, že existuje více přístupů, popisujících dynamiku systému. Rozebrány jsou
zde ty, které pro návrháře IS představují největší přínos.
Po této kapitole následuje praktická část práce (kapitoly 8-12). Kapitola 8 je stěžejní část
práce, která popisuje konkrétní návrh IS rovněž od rozboru zadání až po implementaci. Je
použit objektový přístup. Nejprve je hrubé zadání transformováno na zadání podrobné, poté je
aplikován Model jednání a následně Objektový model (přičemž během tohoto procesu jsou
postupně upřesňovány informační potřeby, datová struktura apod.). Na závěr je popsána
dynamika systému pomocí tzv. Grafických scénářů, což je jeden z možných přístupů
dynamického modelování. Systém byl navržen pro potřeby školícího střediska PVT a.s. a poté
byl i implementován v praxi a jeho posouzení zadavatelem (Autocont a.s.) je nedílnou
součástí této práce. Ve druhém oddílu praktické části (kapitoly 9-11) jsou pak recenzovány
hlavní programové prostředky, které se dnes užívají k analýze IS. Dá se říci, že se v tomto
případě jedná o obdobné recenze jako ty, které jsou publikovány v různých odborných
softwarových časopisech. Kromě hlavních přístupů a možností je zde čtenář seznámen
zejména s uživatelským prostředím jednotlivých programů. Závěrečná kapitola 12 ukazuje
zpracované simulace dynamických procesů vytvořené pomocí programu Powersim Studio.
Kromě výstupů těchto simulací jsou zde popsány jednotlivé diagramy znázorňující dané
procesy. Tato část ukazuje, že výše uvedené prostředky neslouží pouze k vlastnímu návrhu IS
nýbrž, že je lze použít i k řešení obecných problémů, což je v této kapitole hlavním záměrem
a sdělením autora.
11
2. Návrh informačních systémů
Základní teoretické aspekty projekčních postupů
Typy koncepcí k analýze prostředí
Funkční koncepce
Funkční přístup primárně vychází z požadavků na výstupní informace jako reakce na funkce
v systému a zaměřuje se především na možnosti, jak tyto informace ze systému získat.
Zaměřuje se proto především na algoritmy potřebné k získání těchto informací. Provádíme
tzv. funkční analýzu prostředí, ve kterém systém bude fungovat (čili popis procesů a jejich
rozklad v podprocesy). Nevýhodou tohoto přístupu je pomalá reakce na změny v realitě,
například na změny informačních potřeb uživatelů. [8]
Metody funkční analýzy se zaměřují na algoritmy, zajišťující uspokojování informačních
potřeb. Smyslem funkční analýzy je tedy specifikace algoritmu zpracování dat, který vychází
ze specifikace požadavků na služby informačních systémů a čerpá z existujících vstupních
dat. Funkční analýza se zaměřuje na stanovení cílů, které by měl nový systém splňovat.
Nástroji funkční analýzy jsou různé formy funkčních a procedurálních modelů, které
zpravidla vycházejí z globální specifikace požadavků na automatizovaný informační systém
a pomocí funkční dekompozice (neboli funkčního rozkladu) směřují k funkcím, které
uspokojují tyto požadavky.
Datová koncepce
Datový přístup se zaměřuje především na uspokojování informačních potřeb. Primárně se
proto orientuje na jejich analýzu, podstatou přístupu je konstrukce datového modelu reality.
Zde provádíme tzv. datovou analýzu. Metody datové analýzy se zaměřují na vymezení obsahu
datové základny, návrh její struktury a její realizaci. Centrem zájmu jsou tedy data, která jsou
stabilní a jsou datovým odrazem reálných prvků. Nástrojem datové analýzy jsou různé formy
datových modelů. Předmětem datového modelování jsou:
• reálné objekty (entity)
• vazby mezi entitami
• změny ve vazbách mezi entitami, tj. dynamická stránka reality, zohledňující časový
faktor
Cílem datového modelování je vymezení objektů v prostoru a čase. Při této analýze se
vychází buď z reálných objektů, procesů a událostí a hledání možností jejich optimálního
zobrazení v datové základně, nebo (a současně) z analýzy datových potřeb resp. dat jako
vstupů a výstupů ve vazbě na jednotlivé potřeby. [5]
Východiskem může být analýza reálných procesů a objektů resp. jejich chování a hledání
jejich optimálního zobrazení v datové základně. Předmětem takto pojaté analýzy jsou objekty,
jejich vazby, aktivace a deaktivace těchto vazeb jako výsledek událostí v realitě. Podstatou
tohoto přístupu je zaměření na tvorbu datového modelu reality, který je ve své podstatě
stabilnější než informační požadavky. Realitou rozumíme jak existující systém, tak
i představu budoucího projektovaného systému.
Nevýhodou funkčního přístupu je malá flexibilita, nevýhodou datového přístupu je možnost
nezahrnutí některých podstatných funkcí do výsledného řešení (což lze však minimalizovat
v počátečních fázích projektování).
Nejenom z důvodu těchto nejpodstatnějších omezení je nutné si uvědomit, že nelze
upřednostňovat jeden způsob před druhým a není možné přistoupit k řešení pouze z hlediska
funkcí nebo dat. Metody datové a funkční analýzy se vzájemně doplňuji a prolínají. Každá z
12
nich je zaměřena na jiné hledisko. Lze je v konkrétní situaci vzájemně nahrazovat, výsledky
dosažené jedním způsobem lze ověřovat druhým. Je proto vhodné účelně propojovat datovou
a funkční analýzu. Datová analýza by měla mít před funkční analýzou určitý předstih resp.
měla by modifikovat závěry funkční analýzy.
Principy tvorby informačních systémů
Postupy projektování
Při projektování informačních systémů rozlišujeme tři základní postupy: postup zdola-nahoru
(bottom-up) a postup shora-dolů (top-down) a postup kombinovaný (middle-out), který je
kombinací obou předchozích postupů. Postup zdola-nahoru je vhodné použít spíše v těch
případech, kdy se primárně zaměříme na uspokojení stávajících informačních požadavků
uživatelů. Postup shora-dolů následně v případech, kdy se spíše snažíme o podporu nové
kvality systému jako celku. Základem shora-dolů přístupu je přesné vymezení projektované
reality, postupná dekompozice celků na skupiny, až po nejnižší stupeň hierarchie. Lze
dekomponovat celky i datové objekty a toky. Základem zdola-nahoru přístupu je zkoumání
reálného světa a postupná definice entit a akcí. Teprve posléze se tyto poznatky převádějí do
strukturované podoby, vytváří se model a zkoumá jeho konzistentnost s reálným světem.
Ucelená metoda analýzy a projekce
Dřívější oddělené projektování jednotlivých subsystémů vedlo k velké nejednotnosti,
neúčelných duplicitám v datech a programech, nepřehlednosti a podpoře stávajícího stavu. Po
realizaci jednotlivých subsystémů se sice projevila nutnost jejich propojení, to však bylo
mnohdy umělé, a nebo vedlo ke změnám již hotových projektů. Každá aplikace používala své
údaje a i když se jednalo o stejné údaje, byly uloženy v jiné struktuře apod. Také některé
úlohy prováděné v různých aplikacích byly ve své podstatě stejné, zabezpečovaly je však
různé programy. Jakákoliv změna v organizaci firmy vyvolávala zásahy a změny
v programech i v datové základně. Systém nebyl otevřen pro svůj rozvoj.
Dobrý návrh systému vyžaduje komplexní přístup. Zvláště u distribuovaných informačních
systémů je nutné dodržovat určitá pravidla komplexního přístupu, při respektování samostatně
analyzovaných a navržených celků. Distribuovaný informační systém se musí skládat ze
samostatných částí - subsystémů, z nichž každý je natolik jednoduchý, aby mohl být
kompletně sám analyzován a efektivně navržen.
Zároveň však všechny subsystémy (SS) musejí tvořit ucelený systém. Těchto cílů lze
dosáhnout projektováním shora dolů v prvních fázích a teprve v dalších fázích kombinací
s postupem zdola nahoru.
Významné aspekty projektování
Projektování je činnost, kterou se vymezuje a dokumentuje vzájemný vztah činitelů (lidského,
technického a metodického) vstupujících do daného procesu a jejich působení směřující
k dosažení zadaných cílů. Vzájemný vztah a působení těchto činitelů se realizuje ve třech
rovinách: v čase, tj. v určité posloupnosti, v prostoru (dispozičně) a strukturálně
(odpovědnostně, kompetentně).
Těmto rovinám odpovídá i forma dokumentace, kterou se projekty vyjadřují. [19]
Projektování informačních systémů v sobě zahrnuje po určitém zjednodušení dva základní
okruhy: analýzu systému a návrh systému. Projektování informačních systémů dále
charakterizujeme jako posloupnost určitých činností, které lze dělit do tří základních okruhů:
Analýza a modelování
Při analýze a modelování zkoumáme daný podnik, firmu, mapujeme jeho strukturu a chování
13
po stránce funkční i datové. Výsledkem je vytvoření modelu dané části ekonomické reality,
který umožní plně obsáhnout a řešit zadanou problematiku, vzhledem k rozumné míře
abstrakce oproti složitosti reality.
Stanovení cílů
Specifikujeme cíle celé akce, provádíme jejich vyhodnocení, konkretizaci a realizaci. Řešitel
prostřednictvím své tvůrčí aktivity navrhuje na základě aktuálního stavu ekonomického
subjektu a specifikovaných cílů, takovou strukturu a náplň informačního systému, která by
naplnila specifikované cíle.
Komunikace
Komunikace mezi všemi zainteresovanými lidmi a odděleními je jedna z nejdůležitějších
charakteristik procesu projektování.
Hlavním cílem projektových prací je: zdokonalení řídících postupů, zajištění potřebných
informací na správném místě, zajištění potřebných informací ve správný časový okamžik,
získání nových zdrojů pro proces řízení, rozumnější organizaci řídících procesů, zlepšení
komunikace ve firmě, adekvátní technologické zabezpečení řídících procesů.
Fáze analýzy a návrhu systému
Klíčovou fází projekčního procesu je analýza systému, která předurčuje budoucí
charakteristiky a účinnosti projektovaného systému. Smyslem analýzy systému je poznání
a vyhodnocení struktury a chování firmy jako systému před zrcadlem nastíněných cílů.
Výsledkem je specifikace problémových oblastí k následnému řešení. Po fázi analýzy
následuje fáze návrhová, při které specifikujeme nové charakteristiky systému. Podstatné jsou
především :
• návrh nových struktur v systému řízení (prvků a vazeb),
• návrh nových řídících procesů v navrhovaných strukturách (toky dat, algoritmy
zpracování)
• návrh charakteristik řídících struktur a procesů
• návrh vztahů struktur a procesů
Princip informačních zdrojů
Podstatou tzv. zdrojově datového přístupu k projektování informačních systémů je chápání
dat jako potenciálních zdrojů (na stejné úrovni jako člověk, energie atd.), které umožňují
zabezpečit uspokojování informačních potřeb manažerů i běžných pracovníků včetně
potřebných vazeb.
Data jsou relativně stabilnější než požadavky na informace z dat odvoditelné. Typy prvků
které jsou objektem řízení se dramaticky nemění, pokud se nemění cílový stav nebo chování
objektu. Lze říci, že hodnoty datových prvků se mění, ale typy prvků a jejich vlastnosti se
nemění. Vhodně navržený model reality je tedy stabilnější než informační potřeby. Při tomto
způsobu bude splněn i požadavek, aby z potencionálních zdrojů informací - dat bylo možné
odvodit co nejširší varietu zpráv, hlášení atd. Projekční metody používané v klasických
systémech - bez prvků distribuce, které byly primárně zaměřeny na analýzu informačních
potřeb a způsobu transformace dat vedou k dlouhým časovým horizontům projekčního cyklu
a především k systémům které, jsou-li plně realizovány, vykazují značnou nepružnost, malou
flexibilitu vzhledem k měnícím se podmínkám.
V systémech s prvky distribuce je kladen důraz na vzájemnou komunikaci mezi jednotlivými
prvky řízení - na zajištění jejich informačních vazeb. K tomu je bezpodmínečně nutné, aby
jednotlivé prvky (tj. jediný uživatel a jeho osobní informační systém, skupina a její
informační systém, a konečně i informační systém pokrývající celou firmu), byly účelně
provázány a navenek působily jako integrovaný systém. Tato skutečnost vyžaduje zvýšený
důraz na globální uvažování a řešení systému jako celku. Jedná se nejenom o strategické
14
rozvrhování informačních zdrojů - prvků datové základny (tj. tvorba globální koncepce
informačních zdrojů) ale i o koncepci nákupu techniky, rozvoje systému atd. Proto je důležité
prioritně věnovat zvýšenou pozornost globální úrovni projekce. Špatně navržený globální
návrh již nelze zachránit sebelepší realizací na detailní úrovni. Navíc lze s trochou nadsázky
prohlásit, že detailní realizace, při současné úrovni dostupných programových prostředků není
již v současné době intelektuálně náročný problém - zde přechází těžiště spíše do rutinní
oblasti a sestavení konečného řešení stavebnicovým způsobem z dostupných modulů.
Důraz na globální úroveň souvisí i s potřebou neautomatizovat pouze stávající stav
tj. nekonzervovat stávající způsob řízení. V konkrétní rovině to znamená přenesení nebo
nepřenesení algoritmizovatelných činností na prostředky výpočetní techniky. Tvorba
informačního systému rozhodně nespočívá pouze v "naprogramování" nebo
"přeprogramování" stávajícího řešení.
Projektování by mělo být úzce svázáno s úvahou o možné změně - efektivnějším způsobu
řízení. Impulsy ke změnám mohou přicházet jak ze strany projektantů tak ze strany uživatelů
iniciovaných postupem projekce. Toto je další z argumentů ve prospěch globální koncepce
informačních zdrojů – na globální úrovni se projektant pohybuje převážně na vyšší úrovni
řízení a dochází tedy k výše uvedené interakci jako základu budoucích změn.
Globální úroveň projektování již svojí povahou umožňuje odstínit vrcholové manažery od
implementačních problémů, které je nezajímají a ani zajímat nemají a které by je odváděly od
řešení podstatných problémů a koncepčních úvah.
Chápání dat jako důležitých informačních zdrojů a preference globálního přístupu
k projektování umožňuje i realizaci technologie prototypů a tím volit strategii postupného
posunu vpřed s možností cyklických návratů při nutnosti revidovat navržené řešení. Tento
postup umožňuje ověřit si v praxi, byť jen na malém výseku reality a na relativně
nedokonalém řešení chování uživatele, koncepci dané části řešení a využít těchto zkušeností
při dalším postupu resp. iniciovat případné korekce. Kromě jiného přináší i možnost
postupného náběhu vědomí informační potřeby, postupné adaptace na nový způsob práce ale
i prohloubení informovanosti projektanta o požadavcích uživatele, které někdy nelze ani při
detailní analýze odhalit. [18]
Uživatel, zapojený do projekčních prací, si uvědomuje přítomnost a důležitost informačních
zdrojů, což samo o sobě racionalizuje jeho chování ve vztahu k informačnímu systému.
Typy a analýza informačních systémů organizací
V nejširším smyslu výkladu sestává každý systém z komponent, které spolupracují na
dosažení určitých cílů. Systémy existují všude okolo nás - jsme jimi obklopeni a jsme
v neustálé interakci s nimi. Firma je také systémem. Její jednotlivé části, často nazývané
subsystémy nebo agendy (marketing, výroba, odbyt, personalistika atd.) společně vytvářejí
zisk jako prospěch pro majitele, zaměstnance, akcionáře atd. Každý z těchto subsystému je
relativně samostatným systémem.
Každý firemní systém závisí na více či méně abstraktní entitě zvané informační systém.
Informační systém zajišťuje informační služby pro jednotlivé prvky firmy (jednotlivce,
oddělení, jednotlivé subsystémy atd.) takovým způsobem, aby tyto prvky fungovaly efektivně
směrem k vytčeným cílům. Informační systém je z tohoto pohledu "zajišťován" systémem
zpracování dat. [2]
Cílem systému zpracování dat je provádět vstup, uchování dat o firemních náležitostech
a cílem informačního systému je produkovat informace pro zajištění efektivního chodu firmy.
Systém zpracování dat sestává z částí (subsystémů), zahrnujících technické vybavení
hardware /HW/, programové vybavení - software /SW/, datové komponenty, postupy a lidský
prvek. Z těchto zdrojů informačního systému se vytvářejí jednotlivé aplikace. Tyto aplikace
15
slouží jednotlivým funkčním oblastem firmy - konkrétně pak jednotlivým organizačním
komponentám firmy - jednotlivcům, pracovním skupinám a firmě jako celku. [17]
Na počátku všech projekčních prací na tvorbě nebo inovaci informačního systému firmy musí
analytik poznat organizační systém firmy - její organizační strukturu - tj. počet a vazby
organizačních komponent a jejich roli v jednotlivých funkčních oblastech a posléze zkoumat
jednotlivé informační detaily. Jedinou pomůckou v první fázi prací při osvojování organizační
struktury je často pouze tzv. „pavouk" - organizační schéma. Toto schéma je použito k popisu
jednotlivých částí firmy - divizí, oddělení, útvarů atd. a specifikaci vztahů mezi nimi. Přestože
může toto schéma poměrně přesně (záleží zde hodně na straně uživatele) znázornit formální
vztahy mezi jednotlivými komponentami firmy, těžko může ukázat jak skutečně daný systém
- firma funguje.
Existuje mnoho důležitých detailů, které není možné precizně popsat srozumitelným
způsobem do schémat jako například:
• informační kanály - vztahy mezi osobami a odděleními (pokud nejsou
specifikovány v popisu postupů, v popisu práce. Důležitým aspektem je i existence
neformálních kanálů.
• vzájemné závislosti - na kterých odděleních, osobách jsou jednotlivé prvky
firemního systému závislé.
• klíčové osobnosti a funkce - které individuality a prvky systému jsou pro celý
systém prioritně důležité
• kritické komunikační linky - jak se informace a instrukce šíří tam i zpět mezi prvky
systému, jaké mají jednotlivé funkční oblasti mezi sebou vazby.
Výše uvedené lze považovat za nejdůležitější oblasti, na které je nutné zaměřit zkoumání
analytika v etapě analýzy stávajícího systému (kromě studia základních podkladových
dokumentů).
V kontrastu s etapou analýzy, ve fázi navrhování by měl být analytik-projektant odpovědný za
identifikování charakteristik nového systému. Specifikuje jak by systém a jeho části měly
pracovat, které práce vyžadují počítač, které mohou být udělány ručně. Analytik-projektant by
měl i specifikovat způsob opatřování informací jak pro manažery, tak zaměstnance firmy
a tím determinovat, zda-li bude daný systém fungovat efektivně.
Obecně řečeno - každá vyšší úroveň řízení vyžaduje i vyšší odpovídající úroveň sumarizace
poskytovaných informací. Na každé jednotlivé úrovni řízení se provádějí příslušné součty,
vyhodnocení a výsledky se postupují na vyšší úroveň.
Tyto informační potřeby by pro účely tvorby informačního systému měly být určitým
způsobem kategorizovány. Někteří uživatelé využívají počítač pouze jako kartotéku firemních
událostí a procesů a prostředek, který jim umožní pracovat s aktuálními daty o firmě. Někteří
používají počítač k porovnání očekávaných výsledků s aktuálním stavem fungování firmy.
Další skupina uživatelů pomocí matematického modelování simuluje budoucí chování firmy
a pomocí proměnných parametrů zkoumají vliv nejrůznějších aktivit na výsledné chování
firmy. Tyto tři základní kategorie informačních potřeb determinují výchozí kategorie
informačních systémů pro jejich konečnou klasifikaci. Jsou to :
• systém transakčního zpracování
• systém podpory řízení
• systém podpory rozhodování
Vědomosti o jednotlivých kategoriích informačních systémů resp. o službách, které mohou
poskytovat jsou potřebné pro uživatele i projektanty těchto systémů. Obě skupiny by měly mít
přehled o tom:
• co mohou od kterého typu informačního systému očekávat
• který typ bude nejlépe uspokojovat jejich požadavky
• kolik který systém přibližně stojí a jak dlouho může být tvořen
16
Výchozí typy informačních systémů
Nyní si pracovně definujme pět základních typů informačních systémů. Systém transakčního
zpracování /STZ/ podporuje operativní, každodenní aktivity firmy. Systém řízení operativy
/SŘO/ podporuje řízení operativy. Systémy podpory rozhodování /SPR/ jsou speciální
aplikace, které existují pro podporu řešení jednotlivých problémů a rozhodování
v nestandardních situacích. Systém podpory administrativy /SPA/ - podporuje veškeré
činnosti související s rutinní kancelářskou prací – příprava dokumentů, komunikace, termíny
atd. Systém pro podporu vrcholového managementu /SVM/ zajišťuje kontakt nejvyššího
vedení firmy, majitelů s firmou v odpovídající úrovni nadhledu a srozumitelnosti.
Každý z takto nastíněných systémů se vyznačuje svou charakteristikou a obecnou
architekturou.
Princip dekompozice informačních systémů organizací
Smyslem dekompozice je specifikace uživatelů informací resp. služeb informačního systému
a jejich specifické potřeby informačního zabezpečení na jednotlivých organizačních úrovních.
Předpokládáme, že jsou známy a definovány globální cíle a záměry firmy. Tím je odpovězeno
na otázku PROČ firma potřebuje nový nebo inovovaný informační systém. Známe-li odpověď
na otázku CO jsou prvky navrhovaného informačního systému, zbývá definovat JAK,
tj. jakým způsobem informační systém vytvořit a jakou cestou jej zavést. Dekompozice podle
organizačních úrovní odpovídá na otázku KDE, v kterém a jak strukturovaném prostředí,
bude informační systém tvořen. Dále uvedené členění můžeme nazvat například Organizační
úrovně členění informačního systému firmy.
Vnitřní struktura firem je tvořena jednotlivými organizačními celky, které se dělí na menší
útvary (například jednotlivé pobočky firmy se dále dělí na oddělení, skupiny apod.). Tyto
útvary jsou fyzicky představovány jednotlivými pracovníky. Z hlediska struktury jsou
i informační systémy firem (IS) založeny na podobném členění.
Na nejvyšší úrovni je to zpravidla firemní informační systém (FIS), který integruje aktivity
nižších celků, garantuje informační podporu při naplňování globálních cílů a může
i zajišťovat vazbu na okolí systému.
Na druhé úrovni se nachází skupinový informační systém (SIS), který obdobné jako FIS
integruje aktivity nižší úrovně tj. jednotlivých pracovníků v daném oddělení. Tato úroveň
informačních systémů pokrývá zpravidla jednu nebo více funkčních oblastí firemních aktivit,
samozřejmě slouží i ke komunikaci v rámci skupiny a většinou zajišťuje vazby na okolí firmy.
Nejnižší úrovní informačních systémů je osobní informační systém (OIS), který podporuje
práci jednotlivých pracovníků a slouží k jejich komunikaci v rámci vyšších celků, včetně
okolí firmy.
Výpočetní technika je nasazována na jednotlivých úrovních podle konkrétních potřeb
uživatelů informačních systémů, nebo slouží průřezově pro více úrovní (např. servery
počítačových sítí). Na bázi osobních počítačů jsou zpravidla skupinové a osobní informační
systémy, které využívají skupiny a jednotlivci k usnadnění své práce. Především osobní
informační systémy nalézáme dnes téměř ve všech oblastech ekonomických aktivit. Uživateli
OIS jsou například manažeři, techničtí pracovníci, obchodní zástupci, právníci, účetní
a mnoho dalších profesí jako politici, policisté apod.
Pohled na informační systémy jako na podporu aktivit organizace
Zdravě fungující firmy disponují značnou dynamikou ve svém chování. Tržní prostředí nutí
firmy k přizpůsobování se změnám v okolní ekonomické realitě (někdy i měnícím se
pravidlům hry - zákony, daně, ceny nemovitostí apod.). Firmy se neustále mění, rostou,
zmenšují se, mění své struktury a náplň činnosti.
17
Existuje mnoho dalších sil, které způsobují ono dynamické chování - vlastnické vztahy, trh
sám, výměny klíčových manažerů (zdaleka ne nepodstatný faktor při úvahách o tak důležité
součásti firmy jako je její informační systém). Firma může prožívat dramatický vzestup a pád
na základě nepředvídatelných nebo opomenutých skutečností. Všechny tyto faktory vytvářejí
potřebu průběžných organizačních změn. V kontrastu s touto neoddiskutovatelnou dynamikou
jsou informační systémy výrazně statického charakteru. Informační systém disponuje
strukturami a postupy, které reflektují potřeby odpovídají požadavkům firmy (na jakékoliv
úrovni), ale zaznamenaným v momentě (období), kdy daný informační systém byl navržen
(implementován).
Zatímco struktury a procesy informačního systému jsou relativně statické, firma je
v neustálém vývoji. Tím se informační systém dostává do konfliktu s firemními strukturami.
V některých případech je i sám informační systém impulsem pro změny. Výsledkem může
být situace, že systém se stává zastaralým v důsledku změn, které sám vyvolal. Čím je větší
rozsah změn, tím je těžší adaptace informačního systému. Stává se, že informační systém je
tím, kdo nutí firmu k úvahám o změnách.
Přínosy informačního systému na jednotlivých organizačních úrovních jsou podstatné
z hlediska požadavků na projektovaný systém. Každá z organizačních úrovní může být
podporována informačním systémem. Zatímco specifické potřeby se liší dle jednotlivých
úrovní, obecné funkce zabezpečované informačním systémem jsou stejné pro všechny úrovně.
Podle nejpovrchnější analýzy by informační systém měl zajišťovat „svému" majiteli uživateli výhodu v průběžně probíhajícím konkurenčním boji. Ale i u nevýdělečných,
servisních dotovaných firem je informační systém tím klíčem, který otvírá dveře
k poskytování kvalitnějších služeb ve větším množství.
Postupné kroky při vytváření informačních systémů
Proces tvorby informačních systémů je součástí nikdy nekončícího životního cyklu
informačního systému určité firmy. V tomto procesu jsou prvotními impulsy informační
potřeby ekonomického subjektu. Na tyto potřeby se reaguje v návrhu a vlastním budování
informačního systému. Výsledný informační systém se spolu s dalšími (vnějšími i vnitřními)
impulsy podílí na případných změnách ve struktuře a v chování dané firmy. Výsledkem jsou
nové nebo změněné informační potřeby. Na tyto změny se reaguje dalšími zásahy do
informačního systému tj. stále se opakujícím procesem budování informačního systému. Celý
koloběh se běžně v literatuře nazývá životním cyklem budování systémů.
Od nástupu počítačů do firemních sfér (resp. od prvního nasazení počítačů na komerční
aplikace) se objevily stovky nejrůznějších „zaručených" přístupů k návrhu a vývoji
informačních systémů pro typické ekonomické aktivity ekonomických subjektů.
Některé byly úspěšné, některé byly úspěšné částečně, některé byly úspěšnými až po tisících
zprvu neplánovaných člověkohodinách a dodatečných investicích. Některé z přístupů slavily
úspěch, resp. byly úspěšně aplikovány v mnoha firmách, některé pouze v několika, některé
pouze v jedné jediné firmě. Některé však také skončily nevyčíslitelnými škodami na prostředí,
ve kterém byly aplikovány. V čem tkví tak široké spektrum (ne-) úspěšnosti jednotlivých
přístupů? Lze se domnívat, že v samé podstatě filosofie většiny přístupů, které si činí (někdy
z čistě obchodních nebo prestižních důvodů) nárok být všezahrnující tj. obecně aplikovatelné.
Při bližším zkoumání vychází najevo, že většina „projekčních postupů" nevznikala na
tzv. zelené louce, nebo pouze „u stolu", ale že byla vyvíjena současně s konkrétní aplikací
postupu v určitém, konkrétním prostředí. To znamená, že daná metoda zjevně či skrytě
respektovala zjevná či skrytá specifika daného prostředí (struktura, osobnosti, chování,
neformální vazby atd.). A právě skrytá specifika konkrétního prostředí determinují (nebo
18
mohou determinovat) danou metodu, která se tím stává úspěšně aplikovatelnou pouze
v prostředí podobném tomu prostředí, na jehož „testovacím poli" byla metoda navržena.
Úmyslně je zde použito slovo „podobné" a ne slovo „stejné". Absolutní totožnost totiž
v reálném světě ekonomických subjektů neexistují. Doposud stále otevřeně nepřiznaný
neúspěch zastánců tzv. typových projekčních řešení (TPŘ) v případech větších firemních
celků a širším aplikačním záběru je dostatečným důkazem, že postup založený na typových
projekčních řešeních nemůže respektovat individualitu jednotlivých firem, individualitu jejich
částí a především individualitu jednotlivce jako základního článku všech skutečných systémů.
Typová projekční řešení jsou v základním rozporu s obecnou liberální filosofií, založenou na
individualitě jednotlivce, jeho svobodném rozhodování a kreativitě, na jeho specifickém
chování a na obdobných přístupech u vyšších organizačních celků. Například v oblasti
podniků zabývajících se zahraničním obchodem tj. v prostředích, zdánlivě velmi podobných
a na stejném základě budovaných organizačních struktur, se ukázalo být velmi obtížné,
v konečném důsledku někdy i neřešitelé, sladit při funkční a datové analýze odhalené a na
první pohled drobné a nepodstatné odlišnosti tak, aby konkrétní produkt byl použitelný byť
pouze v polovině podniků tohoto typu.
Při zpodrobňování analýzy a průběžném přizpůsobování jádra projektu (založeném na
cílových požadavcích) specifikám jednotlivých prostředí postupně vznikají moduly, které plní
roli jakýchsi můstků mezi typovým jádrem a konkrétním prostředím. Postupnou aplikací
typového řešení tyto moduly narůstají do těžko ovladatelných rozměrů a složitostí, které
mohou v některých případech blokovat chod jádra typových projekčních řešení. V mnoha
případech se komunikace s takto koncipovaným produktem stává neúnosnou ve smyslu
komplikovanosti a časové průchodnosti aplikací (doba odezvy atd.). Tento způsob přístupu
k projektování zdá se být z větší části v obecné poloze nepoužitelným, především pro
náročnost a nízkou efektivitu „přizpůsobovacích" prací. Výjimkou jsou samozřejmě systémy
aplikované v prostředích přísně identicky strukturovaných a v systémech s přesně
definovanými a dodržovanými pravomocemi a informačními toky (vojenské, policejní
prostředí).
Někde uprostřed mezi úspěšně a neúspěšně aplikovatelnými typovými projekčními řešeními
jsou aplikace v prostředí státní a místní správy, které jsou kompromisem mezi identitou
jednotlivých článků systému a nutností respektovat individualitu v jednotlivých lokalitách.
Rozdílné výsledky implementace systémů - od úspěšnosti až po totální krach nebyly vždy
determinovány použitým přístupem, výsledek může být také ovlivněn řadou nejrůznějších
faktorů (od zkušenosti projekčních týmů až po nezkušenost uživatelů).
Všechny projekty v sobě obsahují větší, či menší prvek rizika. V současném prostředí není nic
předem dané a stoprocentně jisté. Již sama jedna z charakteristik tržního prostředí – průběžná
proměnlivost parametrů ovlivňující daný subjekt způsobuje, že míra úspěšnosti / neúspěšnosti
daného subjektu je úzce svázána s úspěšností / neúspěšností dynamicky se měnícího prostředí.
Nárůst úspěšnosti však může být dramaticky zvýšen použitím určitých základních principů,
na kterých je založen dále popisovaný postup projektování.
Definování situace, cílů, požadavků a problémů
K velkým nejasnostem dochází již ve fázi samotného definování problému a stanovení cílů
celé akce. Často se úplně zapomíná na precizní definování problému, nebo si zainteresované
osoby myslí, že problém definovaly, ale ve skutečnosti však pouze popisují příznaky daného
problému. Další otázkami jsou otázky typu: „Co je cílem?“ „Jakými prostředky tohoto (nebo
těchto) cílů dosáhnout?“ „Co je problém?“
Problém je postřehnutelný rozdíl mezi tím, co je a tím, co by mělo být. Zde je určitou
komplikací vnímání. Každý člověk může vnímat realitu jiným způsobem - informační
19
systémy jsou občas zrcadlem názorů, vnímání jednoho, nebo malé skupiny lidí a nezobrazují
vnímání problému ostatními - třeba i taktéž budoucími uživateli.
Problémem může být i pouhé vnímání existence problému - někdy ani problém ve skutečnosti
nemusí existovat - existuje pouze ve vnímání určité osoby. Komplikací je i znalost rozdílu
mezi tím, co je a co by mělo být, bez porozumění skutečné, aktuální situaci. Toto porozumění
je však bezpodmínečně nutné. Je lákavé pronášet na toto téma požadavky jako „zvýšení
kvality výstupů", „vyšší produktivita", „více uspokojených zákazníků" atd., pokud tyto fráze
nemají hmotný obsah. Ten však musí být naprosto přesně specifikován.
Fáze ohodnocení proveditelnosti
Lze vytipovat pět základních parametrů proveditelnosti. Jsou to: cena, časový rozvrh,
technika a programy, reakce prostředí tj. vnitrofiremní „politická" atmosféra. Na co je
potřebné se v této fázi soustředit a nalézt uspokojivé odpovědi?
• Cenová průchodnost (je pravděpodobné, že informační systém bude fungovat za
cenově efektivních podmínek?, má plánovaná akce vůbec smysl?, ušetří se při
předběžně stanovených nákladech například pracovní hodiny zaměstnanců, technika
atd. a tím i peníze firmy?)
• Časový rozvrh (specifikace, zda jsou všechny akce na tvorbě systému uskutečnitelné
v přijatelném termínu)
• Technická uskutečnitelnost (je řešení problému technicky proveditelné?)
• Firemní prostředí (existují kulturní, věková, sociální omezení v daném prostředí?)
Fáze vytvoření předběžného realizačního plánu
V okamžiku, kdy je problém definován, reálnost uskutečnění odhadnuta, je dalším úkolem
v této etapě sestavení plánu realizace. Plán zde v tomto smyslu nezahrnuje pouze časovou
posloupnost a vymezení přesných intervalů (což v praxi lze velmi obtížně dodržet), ale spíše
by se ve smyslu rozvrhu projektu měly specifikovat odpovědi na otázky typu :
• kdo bude celou akci řídit, kdo bude mít hlavní odpovědnost ?
• jací lidé budou potřební, kdo se bude na celé akci podílet ?
• jaké úkoly jsou prioritní, nezbytné - kdo je zabezpečí ?
• jaký je hrubý časový plán celé akce ?
• jaké množství financí bude předběžně potřeba ?
• v kterých časových okamžicích budou tyto finance nutné ?
Hloubka podrobnosti jednotlivých odpovědí, rozpis kroků akce je determinována rozsahem
předpokládaného projektu - jiným způsobem se bude koncipovat projekt aplikace malého
rozsahu, bez podstatných vazeb na okolí, jinak aplikace s nezbytnou provázaností na celý
zbytek firmy.
Definování a zhodnocení požadavků na informační systém
Cílem této etapy je identifikace a dokumentace (v co nejkomplexnější podobě a v co největší
míře podrobnosti) všech požadavků na informační systém. Mají-li pak být tyto požadavky
použity v následných etapách k tvorbě systému, musí být specifikovány a dokumentovány co
se týká výčtu všech požadavků v co nejkompletnější formě (byť třeba pouze jako nástin co se
týká obsahu). Vznikne-li mezera v této etapě, vyvinutý systém nebude pomůckou, může
později ztroskotat, nebo bude vyžadovat dodatečné zdroje na přepracování.
20
Definování požadavků
Je nutné specifikovat, jaké výsledné informace budou vyžadovány, rozhodnout, jaká data
budou potřeba k produkování informací a s jakými omezeními na straně techniky, programů
a lidí se pravděpodobně řešitelé setkají. Nabízí se zde jednoduchá analogie s postupem
přípravy pokrmů - nejdříve specifikujeme CO hodláme připravit, poté z ČEHO se daný pokrm
bude skládat a konečně toto porovnáme s tím, co MÁME k dispozici a položíme si otázku,
zda daný postup nepřesahuje dovednosti, kterými disponujeme. Definujeme:
• specifikace výstupních požadavků (zprávy, grafy, soubory)
• specifikace potřebných vstupů a jejich zdrojů (ručně pořizovaná data, ostatní data)
• odhad rozsahu zpracování, velikosti systému (množství dat, nárůst dat, frekvence
změn, frekvence produkování výstupů)
• specifikace omezení (technika, programy, postupy - metody, lidé)
• specifikace požadovaných dokumentů projekčního postupu.
Zhodnocení požadavků
Cílem tohoto kroku je zvolit takovou strategii tvorby systému, která by nejlépe
korespondovala s definovanými požadavky. Nalézt soulad je velice obtížné, stoprocentní
řešení je spíše výjimkou, záleží zde na konkrétních interních podmínkách.
Při vyhodnocování jsou požadavky nejprve přezkoumány a je-li to rozumné, tak některé
i anulovány. Posléze je vhodné identifikovat hlavní alternativy řešení budoucího systému.
Tyto alternativy jsou opět vyhodnoceny a jedna z nich posléze vybrána.
Jsou-li požadavky rozumně dokumentovány, je možné je zkoumat. Občas se stane, že jeden
nebo více požadavků je zahrnut do schématu budoucího systému pouze proto, že zajišťuje
větší komplexnost systému, nebo je jeho realizace výrazně cenově výhodná. Při
vyhodnocování těchto požadavků je vhodné takovýmto požadavkům nastavit „zrcadlo reality"
a pečlivě je zkoumat v kontextu přiměřených možností celkového záměru, finančních
a ostatních omezeních atd.
Každý požadavek by měl být zkoumán ve světle skutečných globálních potřeb systému a ve
světle potencionálních nákladů. Vyvrcholením tohoto kroku je výčet odsouhlasených
požadavků. Tento výčet je posléze pomůckou pro stanovení kritérií při výběru, testování
a odsouhlasení konkrétních prvků systému.
Pro každý požadavek provádíme:
• verifikaci uskutečnitelnosti (cena, vývoj, technologie, prostředí)
• zkoumání vlivu požadavků na základní komponenty informačního systému (příklady
otázek: není některý požadavek nepřiměřeným břemenem pro systém jako celek? je
požadavek opravdu odůvodněný?
• prověřením požadavků s uživateli vyjasňujeme jakékoliv nejasně definované
požadavky.
Dále je třeba zvolit takovou strategii tvorby systému, která by nejlépe korespondovala
s definovanými požadavky. Jak již bylo řečeno výše, nalézt soulad je velice obtížné,
stoprocentní řešení je spíše výjimkou, záleží zde na konkrétních interních podmínkách.
Vyhodnocování a volba alternativ
K volbě alternativ lze z hlediska ekonomického, použít metod založených na porovnávání
nákladů a očekávaných přínosů. V praxi je však velice obtížné specifikovat právě tuto stránku
přínosů. I když se podaří jakýsi přesně-nepřesný odhad vypočítat, neřeší většinou otázku
volby alternativ. Většinou se všechny alternativy pohybují na podobné, akceptovatelné výši
a rozhodování se musí provést spíše na bázi vyhodnocování použitelnosti a přínosů finančně
nespecifikovaných.
Při vyhodnocování alternativ zohledňujeme následující kritéria:
21
• snadná rozšiřitelnost systému
• pozice dodavatele na trhu
• jednoduchost a snadnost provedení navrženého řešení
• použití moderních vývojových technologií
• vztah k dodavateli
• akceptovatelná míra spolehlivosti
• dostupnost a podpora servisu.
Projektování a návrh informačního systému na globální úrovni
Výchozí teze
Analýza systému je vždy nezbytným předpokladem řešení obecných úloh organizačního
zaměření. To platí samozřejmě i pro řešení úloh v ekonomice a zvlášť pro řešení úloh řízení.
Analýza sama však nejvýše upozorňuje na problémy, na stav minulý a současný. Při návrhu
a budování informačních systémů /IS/ je hlavním úkolem odhad a nastínění budoucích stavů
a příprava na ně. Pokud budeme v této souvislosti hovořit o metodách myšlení, budeme
zdůrazňovat kromě schopnosti analytického myšlení i schopnost myšlení tvůrčího.
Existuje mnoho postupů podporujících tvorbu informačních systémů. Základem filosofie zde
popisovaného postupu projektování je přístup založený na několika základních principech.
Globální dekompozice základních informačních zdrojů je metoda použitá k prvotnímu návrhu
architektury informačního systému a k případnému zásahu do firemních organizačních
struktur a postupů.
Detailní dekompozice je metoda, která pak blíže specifikuje základní charakteristiky a
potřeby, požadavky jednotlivých prvků, a to na jednotlivých úrovních „hierarchie" firemních
organizačních struktur. Následně pak návrh celého systému probíhá na základě detailní
analýzy jednotlivých částí systému a syntézy dílčích detailních specifikací.
Při tvorbě informačního systému je vhodné volit přístup respektující individualitu, samostatné
rozhodování, specifičnost jednotlivých prvků firemních organizačních struktur atd. Postup zde
popisovaný se toto snaží respektovat. Kromě návrhu globální architektury, kdy jsou prvky
individuality do jisté míry záměrně potlačeny vzhledem k nutnosti udržení potřebné úrovně
nadhledu, je kladen důraz především na respektování specifických charakteristik jednotlivých
subjektů. Těžiště respektování individuality je právě na detailní, spíše funkčně orientované
úrovni vývoje systému. Na globální úrovni, je možné definovat pouze nejobecnější rozvržení
datových zdrojů, vyznačit nejobecnější vazby mezi prvky systému a jejich informační potřeby
tj. stanovit předběžné interní hranice a to především za účelem udržení integrity budoucího
systému. Ale i z čistě pracovních a organizačních důvodů počet sledovaných skutečností
nesmí přesáhnout únosnou míru.
Na detailní úrovni analýzy systému je těžištěm v přístup založený na postupném zkoumání
způsobu chování, funkcí a potřeby informací. Toto zkoumání by mělo probíhat postupně
u všech jednotlivých prvků systému směrem od každého jednotlivce (s definovanou vazbou
na informační systém a s definovanou informační potřebou), přes pracovní skupiny až po
úroveň firmy jako celku. Vycházíme z předpokladu, že každý jednotlivec je obklopen resp.
pracuje s vlastním informačním systémem, který musí respektovat jeho individualitu,
specifický způsob práce, třídění požadavků atd..
Analogie individuálního přístupu platí pro jednotlivá oddělení, sekce apod. Koncepce
založená na prolínání globálního rozvrhování zdrojů a detailního přístupu zdola při výrazném
respektování individuálních charakteristik na jednotlivých úrovních má šanci stát se ne sice
přímo metodickým postupem, ale předpokladem pro výčet doporučení, dle kterých lze
22
postupovat tedy jakousi obecnou filosofií přístupu k návrhu a vývoji informačního systému.
Paralelně s návrhem globální architektury by měl probíhat vývoj dílčích - individuálních
informačních systémů s větším důrazem na funkční než datovou analýzu (při respektování
výsledků globální úrovně). Na rozdíl od návrhu globální architektury, při jehož tvorbě by měli
převažovat specialisté analytici, při vývoji individuálních systémů je jejich funkce spíše
poradní, konzultační - těžiště je na uživateli. V některých případech je uživatel navrhovatelem
i tvůrcem informačního systému, v některých případech pouze předává potřebné informace
speciálnímu týmu.
Tento postup by mohl být i pilotní strategií pro malé a střední firmy zabývající se dodávkou
„informačních systémů na klíč", případně konzultační a poradenskou činností. Vzhledem
k možnosti podrobného popisu návazností jednotlivých kroků v klíčových momentech cyklu,
lze postup využít i jako "kuchařku" pro firmy, které nedisponují informačními specialisty
a nehodlají využít služeb specializovaných firem.
Podmínky a předpoklady použití metody
Pro úspěšnou aplikaci jakéhokoliv postupu je vždy nezbytné vytvořit určité podmínky
a respektovat jisté předpoklady, jejichž existence je nezbytná pro úspěšnost aplikace. Zvlášť
důležitá je organizace postupu v případě projekčních prací, kde dochází k interakci většího
množství osob. [3]
Pro úspěšnou aplikaci metody je nutná existence osoby, disponující určitými znalostmi
principů metod a pokud možno i zkušenostmi z jejich aplikování (není nezbytně nutné).
Protože obvykle běžné firmy nedisponují odborníky na problematiku strategických návrhů, je
nutné vyhledat pomoc poradce. Úroveň odborné pomoci může být různá - od vysvětlení
principů až po spolupráci na řešení.
Jednou z krajních možností (většinou užívanou v případě menších firem, se zřetelnou
a relativně stabilní organizační strukturou) je úplné osvojení metody a její aplikace vlastními
silami. Druhou krajností (nedoporučuje se!) je předání úkolu poradci nebo firmě provádějící
tyto služby a čekání na výsledek. Tento výsledek by v tomto případě, kdy řešení není
ovlivněno vedením firmy, nemusel vždy odpovídat očekávaným představám. Optimální řešení
se nachází někde uprostřed mezi těmito krajními variantami. Doporučuje se ustanovení
zástupce firmy, který bude zajišťovat kontakt poradce s vedením firmy, která zadává řešení
projektu a zároveň bude i nenásilným způsobem ovlivňovat směr řešení.
Vlastní řešení by mělo být realizováno malým týmem s pevným vedením. Vedoucí týmu by
měl být totožný s výše uvedeným poradcem. V případě složitějších systémů je vhodná účast
specialisty na datovou analýzu. K zajištění kontaktu a pomoci ze strany budoucích uživatelů
(heslem je vtáhnout uživatele co nejvíce do řešení) je nutné vybrat z uživatelské strany
klíčové osobnosti (přednost mají osobnosti před hierarchií funkcí!), které by měly
spolupracovat s řešitelským týmem. Forma účasti těchto osob se liší podle složitosti
problému. Někdy stačí individuální pohovory, v jiných složitějších případech je tyto osoby
vhodné vyškolit ke kvalifikovanému dodávání informací z uživatelské strany tj. provádět
tzv. uživatelskou analýzu.
Metoda umožňuje široké zapojení těchto „uživatelských analytiků", kteří využívají znalosti
řídících a obchodních operací v prostředí vlastní firmy. Mimořádně důležité je pečlivé
vyjasnění pojmů, které nemusejí sice odpovídat normám (jejichž platnost je v našich
současných podmínkách diskutabilní a odpovídá spíše prosazovaným slovním představám
odborníků - teoretiků), ale musí být akceptované oběma stranami. Již samotný charakter
metody, která se vyznačuje širokým využitím srozumitelných formulářů, ji předurčuje
k rozsáhlému zapojení uživatelů do procesu projekce.
Přístup, který je v počátečních fázích založený na postupu shora-dolů by měl být řízen
i kontrolován jedinou osobou. V případě větších organizačních celků je toto realizováno
23
větším týmem, ale za celé řešení musí odpovídat jediná osoba a dostatečnými pravomocemi.
Tato osoba - někdy nazývaná informační manažer, by měla být na úrovni nejvyššího vedení
firmy (podřízena nebo zrovnoprávněna). Je známo, jak nebezpečný a křehký je právě tento
vztah, protože právě zde dochází k rozporům, zdržením a někdy i zastavení celého postupu
jako důsledek rozporů v tomto vztahu. Informační manažer musí být člověk s podrobnou
znalostí fungování a perspektiv firmy a musí být schopen rozhodnout, které datové zdroje (na
globální úrovni) firma opravdu potřebuje.
V konečných fázích projektování je nutná spolupráce se správcem dat (existuje-li tato
funkce), který by měl provádět podrobnou datovou analýzu a syntézu pro každou navrženou
databázi a zajistit i implementaci řešení v této oblasti.
Postup shora-dolů, uplatňovaný v počátečních fázích upřednostňuje fungování firmy jako
celku, zohledňuje její klíčové prvky. Postup zdola-nahoru by měl využívat jako vstup entity,
které jsou výstupem z globální datové analýzy a tyto dovést až do implementační fáze.
Role koncových uživatelů se mění v závislosti na růstu komplexnosti informačního systému.
Uživatel má podstatnou tvůrčí roli v osobním informačním systému. Na vývoji skupinového
informačního systému je uživatel typicky v roli řídící. To znamená podstatnou aktivitu
a spolupráci s dodavateli, s tvůrci nebo externími spolupracovníky. Musí umět definovat
potřeby a hlavně je musí umět těmto lidem srozumitelně naformulovat. Dále musí
pochopitelně mít základní znalosti o vývoji osobního informačního systému tak, aby
specialistům mohl být přiměřeným partnerem v procesu jeho tvorby.
Konečně pak na vývoji firemního informačního systému přebírá koncový uživatel roli člena
týmu, který tento systém vytváří. Zde musí vědět, jak nejlépe formulovat své potřeby
i potřeby ostatních a jak zajistit, aby těmto potřebám (často nejrůznějším) byla věnována
dostatečná pozornost. Musí mít také částečný přehled o problémech, se kterými se tvůrci
systému setkávají při budování informačního systému většího rozsahu. Pokud má o této
problematice alespoň částečný přehled, budou mu naopak potřeby a akce profesionálních
tvůrců daleko více jasnější, pochopitelnější a tím se kvalitativně mění komunikace mezi
koncovými uživateli a profesionály.
Obecný popis metody
Popsaný postup projektování představuje jeden z možných přístupů k této problematice
s cílem být metodickým návodem, který usnadní a urychlí práci na tvorbě informačních
systémů. Jedná se o postupy a metody, které umožňují realizovat návrh informačního systému
v podmínkách distribuovaného zpracování dat, tj. prostředí, které se v současnosti stává
převažujícím při budování většiny informačních systémů.
Metoda obsahuje tři (resp. čtyři) hlavní části podle návaznosti postupů analýzy a návrhu
systému:
• globální úroveň projektování - globální datová analýza a návrh architektury systému
• detailní úroveň projektování - detailní datová analýza a návrh subsystémů
• funkční analýza podle jednotlivých organizačních úrovních
• implementace.
Modulární, otevřený charakter metodiky umožňuje její aplikaci na prakticky jakékoliv
navrhované technické struktuře (tj. typu a základní koncepci umístění technických prostředků)
systému. Postup umožňuje přizpůsobení se reálným podmínkám, za kterých probíhá proces
návrhu informačního systému a které jsou charakterizovány například:
• nejasností v záměrech koncepce vybavení technickými a programovými prvky
• průběžnými změnami v technickém a programovém vybavení
• neúplnými nebo nadhodnocenými informacemi o možnostech technického
a programového vybavení
• poplatností stávající koncepci zpracování dat
24
• nepřipraveností uživatele na změny vyvolané zaváděním automatizace (například
nedořešená organizační struktura, nejasnosti v pracovních náplních a odpovědnostech)
• chaotickou situací vyvolanou postupným přechodem na novou koncepci
Nutnost poskytnout ucelený pohled na problematiku projektování distribuovaného systému
a rovněž i fakt, že otázky distribuce zasahují do většiny projekčních postupů, vede
k předložení celého postupu i s fázemi, které zdánlivě s distribucí nesouvisejí.
Cílem a tedy i zadáním pro vytvoření metodiky projektování informačního systému je
vytvořit formalizovaný postup, který umožňuje relativně rychle, snadno a s rozumnými
kapacitami navrhnout informační systém. Metodika projektování umožňuje rychlé
a dynamicky pružné zavádění informačního systému do užívání. Postup nevyžaduje vysokou
úroveň speciálních znalostí, je založen převážně na formalizovaných postupech, navazujících
krocích a využití navržených tabulek a formulářů.
Jak již bylo řečeno, metoda projektování je založena na chápání dat jako základních
potencionálních zdrojů, které zabezpečují uspokojení informačních potřeb uživatelů
informačních systémů. Tento tzv. zdrojově datový přístup vychází z předpokladu, že se data
analyzují jako potencionální zdroje informací, uložená data se průběžně aktualizují podle
změn v datové základně a z nich se pomocí vhodného programového vybavení zpracovávají
výstupní zprávy pro uspokojení dynamicky proměnných informačních potřeb uživatelů. [22]
Základní východisko projektování vychází tedy z dominantní úlohy dat (resp. datové
analýzy). Data jsou chápána jako informační odraz objektů, které jsou předmětem činnosti
firmy.
Proto při projektování musí docházet ke vzájemnému vztahu a ovlivňování datové a funkční
analýzy. Kvalitní návrh datové základny společné pro celý systém je předpokladem pro
efektivní realizaci programového zabezpečení. Při případných vnitřních změnách ve firmě se
mění úlohy, činnosti, organizační struktura, data však zůstávají obvykle stejná.
Je-li obraz reality v datové základně relativně úplný, jsou tím definovány a založeny datové
struktury, které budou případně využity až v budoucích aplikacích. Tyto potencionální
informace umožňují posléze rychlý rozvoj systému. To znamená, že data se nevytvářejí pouze
pro jednotlivé existující nebo vytvářené aplikace (taková data v souborech i aplikačních
bázích dat jsou totiž příliš závislá na stávající struktuře firmy i existujících úlohách). Snahou
je vytvořit báze dat, které jsou nezávislé na jednotlivých aplikacích. Data v nich jsou
navrhována a uchovávána nezávisle na funkci, pro kterou jsou použita. Mluvíme
o tzv. předmětných bázích dat, neboť se vztahují vždy k určitému předmětu činnosti, objektu.
Priorita návrhu systému shora dolů, důraz na datovou základnu a vytváření předmětných bází
dat jsou základními myšlenkami, na nichž je založen popisovaný postup projektování.
Postup musí být (ve smyslu předpokladů aplikace této metody) zahájen získáním podpory
nejvyššího vedení firmy a nejbližších podřízených. Čas věnovaný rozhovorům na této úrovni
se vrátí v následujících krocích. Další postup respektuje jejich pohled na organizaci řízení
firmy. I v dalších krocích bude většina podnětů pro práci projekčního týmu přicházet přímo
nebo nepřímo od těchto osob. Na druhé straně je nutné si uvědomit, že tyto rozhovory jsou
sice nezbytné, zvláště v počátečních fázích projektování, ale neposkytují dostatek informací
pro celý postup.
Na globální úrovni projektování provádíme rámcovou funkční a datovou analýzu,
syntetizujeme tyto poznatky a navrhujeme základní dělení systému na relativně samostatné
celky. Tyto celky - subsystémy jsou na této úrovni představovány po funkční stránce procesy,
po datové stránce předmětnými bázemi dat. Výsledky této prvotní analýzy (tj. funkční model,
specifikace vazeb dat a procesů) jsou použity ke globálnímu návrhu distribuce datové
základny.
25
Stanovení funkční náplně a vypracování funkčního modelu organizace
Vytvoření funkčního modelu firmy je první etapou práce na globální úrovni projektování.
Cílem je stanovení funkční náplně práce firmy na globální úrovni, tj. stanovení funkčních
oblastí a v nich probíhajících procesů, jejich seřazení podle tzv. životního cyklu a vyloučení
duplicit. Během této etapy vznikne hrubý přehled o tom, co se ve firmě provozuje - jaké
procesy zde probíhají. Podstatná pro tuto etapu je globální úroveň, tj. udržení určitého
nadhledu funkčního pohledu, oproštění od v této etapě nepodstatných detailů při současném
plošném pohledu na konkrétní systém.
Postup vytvoření funkčního modelu firmy:
• vytypovaní funkčních oblastí a definování procesů ve funkčních oblastech
• seřazení funkčních oblastí podle životního cyklu
• přiřazení procesů k organizační struktuře.
Funkční model firmy znázorňuje základní procesy, které ve firmě probíhají. Model musí
postihnout všechny procesy ve firmě a měl by pokud možno zahrnout i plánované změny
firmy.
Postup řešení probíhá v několika fázích. Nejprve získáváme přehled o hlavní náplni činnosti
firmy na nejkomplexnější úrovni - provádíme tzv. rámcovou analýzu činnosti firmy.
Partnerem projektanta je uživatel z hierarchicky vyšší úrovně řízení, který je schopen
definovat komplexní pohled na problematiku činnosti celé firmy a disponuje odpovídajícím
nadhledem. Neexistuje-li taková osoba, musí tyto informace zajistit projektant systému. Dále
zpřesňujeme informace o jednotlivých oblastech, využíváme partnerů z příslušné řídící
úrovně. Výsledky analýzy formulujeme do funkčního modelu, který odpovídá globální
úrovni.
Zmapování po datové stránce, navržení bází dat organizace
Návrh bází dat je druhou etapou práce na globální úrovni projektování. Cílem je zmapovat
konkrétní firmu po stránce datové, tj. specifikovat báze dat, které budou v budoucím systému
využívány. Podstatnou pro tuto etapu je opět globální úroveň, tj. udržení určitého nadhledu na
datové prvky, oproštění od (v této etapě) nepodstatných detailů (při současném plošném
pohledu na konkrétní systém). Podstatou této části řešení je návrh tzv. předmětných bází dat.
Předmětné báze dat jsou nezávislé na jednotlivých aplikacích, data v nich jsou navrhována
a uchovávána nezávisle na funkci, pro kterou budou použita. Předmětné báze dat se vztahují
vždy k určitému předmětu, objektu v firmě. Výhodou předmětných bází dat je především
značné urychlení tvorby a rozvoje aplikací a také relativně snadná realizace nových aplikací.
Předmětné báze dat by měly být navrhovány tak, aby byly co možná nejstabilnější,
představují totiž stabilitu informačních zdrojů firmy. S ohledem na výhody předmětných bází
dat je vhodné definovat báze dat vždy jako předmětné, i když ve fázi návrhu distribuce dat
mohou být předmětné báze dat realizovány jako aplikační báze dat, soubory atd. [7]
Ve firmě lze uvažovat v závislosti na její velikosti a složitosti zpravidla 10 - 30 bází dat.
Typické objekty, pro které jsou báze dat vytvářeny, jsou například v průmyslovém podniku
tyto: výrobky, odběratelé, objednávky, dodavatelé, pracovníci.
Předmětné báze dat lze zpravidla navrhnout bez konkrétní formální metody. Například
záznamy týkající se odběratelů, jsou v předmětné bázi dat "Odběratelé", záznamy týkající se
pacientů jsou v předmětné bázi dat "Pacienti", atd. Není to však úplně jednoduché, projektant
musí mít určitý nadhled a musí znát danou problémovou oblast, aby věděl, jaké předmětné
báze dat má vytvořit a jakými daty je naplnit. Pro návrh předmětných bází dat lze také použít
postup založený na zkoumání jednotlivých entit, vytvoření modelu entit a zjišťování těsnosti
vazeb a následném seskupení entit do předmětné báze dat. Analýza entit prováděná pro celý
26
systém najednou je však poměrně pracná a těžko lze udržet konzistenci projektu a celkový
pohled důležitý pro tuto globální úroveň. Proto je vhodnější použít následující postup
založený na specifikaci datových prvků souvisejících s jednotlivými procesy a následném
návrhu předmětných bází dat.
Tvorba globálního návrhu informačního systému a jeho architektury
Výsledkem dosavadních fází je rámcové zmapování činnosti firmy po stránce funkční
i datové. V tomto okamžiku je nadefinován funkční model firmy až do úrovně procesů
a datové prvky na úrovni bází dat. Cílem další části je tvorba hrubého (co do podrobnosti)
globálního návrhu informačního systému a jeho architektury. Dochází zde k rozčlenění
prvotního schématu na menší části - subsystémy.
Mezi dřívějšími projekčními postupy převažoval postup založený na definování subsystémů
postupně tak, jak se vytvářely jednotlivé aplikace, nebo pokud se vytvářel projekt systému
jako celku, rozdělení na subsystémy bylo většinou intuitivní. Nyní používané rozřazovací
metody nabízejí formální postup, jak identifikované procesy a báze dat seskupit do
subsystémů. Právě tato část řešení je nejdůležitější, neboť vytváří předpoklady pro návrh
distribuované datové základny. V následujících fázích specifikujeme, jakým způsobem bude
firma využívat stávající resp. plánované informační zdroje.
Postup návrhu globální architektury systému:
1. Přirazení bází dat k jednotlivým procesům
2. Specifikace subsystémů, vazeb mezi subsystémy
3. Návrh případných změn v organizační struktuře
Optimální rozložení datových zdrojů, navržení distribuce datové základny
V prvních fázích postupu projektování nebyl brán zřetel na možnost rozdělování - distribuce
dat. Cílem bylo sestavit základní koncepci - architekturu informačního systému. Ale již zde,
na globální úrovni návrhu systému je nutné navrhnout základní koncepci distribuce datové
základny za účelem dosažení optimálního rozložení datových zdrojů (tj. rozložení do míst
zpracování, minimalizace přenosů, odpovědnost za data atd.).
Faktory, podstatné při řešení problémů distribuce dat jsou však poměrně složité, některé
z nich jsou úzce spojeny s technickým vybavením, programovými a komunikačními
prostředky. Některé z faktorů se mohou průběžně po dobu tvorby projektu výrazně měnit
(například parametry komunikační sítě, ceny přenosů, ceny počítačů atd.). V některých
případech dochází i ke změnám v dislokaci jednotlivých útvarů firmy. Některé z těchto změn
mohou být vyvolány právě při návrhu architektury systému jako důsledek změn v řízení,
změn v odpovědnosti atd. Právě změny vyvolané nástupem nových technologií je nutné
respektovat a provést, neboť jsou projevem respektování algoritmizovaného myšlení
a uplatnění systémového přístupu v řídících postupech. [6]
Vycházíme-li z předpokladu, že distribuce datové základny má z obecného hlediska co
nejvíce odpovídat přirozené struktuře řízení a struktuře organizačních prvků firmy, je zřejmé,
že faktory distribuce datové základny a rovněž i faktory prvků programového vybavení se
mohou v čase podstatně měnit. Proto je nutné v této fázi řešení respektovat více logická
východiska pro distribuci než geografická, která jsou více spojena s měnícími se parametry.
Zpočátku proto vycházíme z existence tzv. logických uzlů koncových uživatelů /LU/.
V dalším průběhu řešení, při postupném zpřesňování jsou nahrazovány již přesněji
specifikovanými lokalitami (zpřesnění se týká především umístění a technicko programových
parametrů). Logické uzly koncových uživatelů mohou, ale nemusí být totožné s konkrétním
geografickým rozložením technických prostředků.
27
Navržená koncepce usnadní úvahy o volbě, umístění a typu vhodného technického
a programového zabezpečení pro jednotlivé skupiny uživatelů. Ale konkrétní řešení, do
kterého se promítnou nezbytná programová a technická omezení je předmětem konečného
návrhu v posledních realizačních fázích.
Je však nutné již zpočátku zahrnout do globálního (koncepčního) návrhu systému všechny
(i vzdálené) dislokované útvary a přesně stanovit, jaká část firmy bude podléhat centrálně
prováděnému projekčnímu řešení.
Distribuce datové základny představuje takový způsob rozmístění prvků datové základny, při
kterém je možné využít například již zmiňovaných a zde uvedených výhod distribuovaného
zpracování dat:
• zvyšuje se dostupnost dat
• existuje pružnější přístup k datům
• je možné zabezpečit vyšší spolehlivost systému
• data jsou v souladu s rozhodovacími pravomocemi
• funkce jsou v souladu s rozhodovacími pravomocemi
• data se nacházejí v místech s nejvyšší četnost užití
• zkracuje se doba odezvy systému na požadavky uživatele
• omezují se přenosy dat o velkých objemech, atd.
Hlavním cílem je dosažení stavu, kdy informační systém bude odpovídat přirozené struktuře
a cílovým funkcím systému řízení daného uživatele.
Dalšími cíli jsou:
• získání globální představy o potřebě datových prvků v jednotlivých lokalitách
(logických uzlech)
• rozhodnutí o centralizovaném nebo decentralizovaném způsobu uložení dat
a způsobu zpracování
• rozhodnutí o koncepci způsobu zpracování
• volba vhodného prostředí datové základny
• volba vhodné formy datové základny
• návrh globálního schématu rozvržení datové základny
• specifikace lokalit, v kterých budou uzly systému.
Můžeme tedy shrnout, že předmětem činnosti v této fázi projekčního postupu je globální
návrh (tj. na úrovni bází dat, procesů a pouze s nejpodstatnějšími technickými omezeními)
rozmístění jednotlivých bází dat a možné komunikace mezi uzly systému ve smyslu
požadavků na data.
Postup návrhu distribuce dat:
1. Definování lokalit a podle stavu prostředí i uzlů informačního systému a jejich
vazeb na procesy
2. Analýza potřeby dat v jednotlivých prvcích systému
3. Volba druhu a koncepce zpracování
Projektování a návrh subsystémů na detailní úrovni, implementace
Druhá část metodiky projektování je návodem pro postup projektování jednotlivých
subsystémů. Na této detailní úrovni je na základě datové a funkční analýzy v příslušné oblasti
navržena datová základna v podrobné specifikaci a dále jednotlivé funkce transformace dat.
(Transformací je zde myšleno vyjádření výstupní hodnoty jako funkce hodnot vstupních.)
Na tuto etapu navazuje poslední realizační část postupu, tj. implementace datového
a funkčního modelu.
Cílem dalšího postupu projektování je provedení funkční analýzy na základě prvotní globální
dekompozice a detailní datové analýzy na základě globálního rozvržení datových zdrojů
28
a vymezení podstatných prvků systému. Postupujeme přitom zdola nahoru po jednotlivých
úrovních systému a definujeme:
• jednotlivé „dílčí" informační systémy
• charakteristiky jednotlivých „dílčích" informačních systémů v rámci firmy
• jejich informační, technologické potřeby a vazby
• podmínky použití těchto informačních systémů.
Návrh, který je výstupem z globální úrovně nerespektuje, resp. nemůže respektovat detailní
specifika. Přihlížet ke skutečně detailním specifikám jednotlivých prvků a respektovat je,
tj. zohlednit jejich zvláštnosti, je reálné až v procesu detailního návrhu. Především na této
úrovni, kde pracovník je zároveň uživatelem, operátorem a často i tvůrcem informačních
systémů, lze na těchto pracovnících ponechat více aktivit při vývoji systému. Tím je možné
dosáhnout stavu, kdy mu výsledný systém bude co nejvíce vyhovovat. Podstatnou hranicí
však budou výsledky předchozích etap - dané globálním „rozvrhem" dat. Současné technicko
programové prostředky takovýto postup umožňují. Takto koncipovaný systém posléze spojuje
nutné systémové vazby v rámci vyšších celků i specifických vlastností jednotlivých řešení. [1]
Prvním krokem při tvorbě informačních systémů by měla být specifikace základních
charakteristik těchto systémů. Jejich porovnáním a zpřehledněním se kromě vlastního vývoje
jednotlivých částí informačních systémů vytvářejí i podklady pro realizaci prací na tvorbě
informačních systémů jako celků, resp. prací na konkretizaci globálního rozvržení datových
zdrojů.
Na detailní úrovni pracujeme již s pojmy entita a činnost. Funkční oblasti jsou
dekomponovány do procesů, a tyto do činností. Tyto činnosti jsou posléze programovány,
nebo zajištěny pomocí stávajícího programového vybavení. Problém je většinou ve
specifikaci konečného bodu rozkladu, tj. ve stanovení základních činností, které se dále
nerozkládají. Tyto problémy je nutné řešit intuitivně s ohledem na charakteristiku
problematiky a důležitost té které činnosti pro životní cyklus projektování. Opět platí, že
žádná analýza nemůže být provedena na 100 %. Vždy zůstanou činnosti, které nejsou detailně
prozkoumány, nebo činnosti, které se objeví až dodatečně.
Činnost je základní elementární operace, kterou vykonává člověk nebo počítač. Pro popis
činnosti stačí zpravidla jedna věta. Když je uživatel dotázán, co dělá, jeho odpověď je
většinou definicí činnosti, například „připravuji objednávky".
Při zkoumání činností se zároveň zabýváme i daty. Entitou rozumíme reálný nebo abstraktní
objekt, „něco" co je rozlišitelné, co je předmětem zájmu uživatele, něco, o čem se uchovávají
data. Entitou může být hmotný objekt (například pracovník, výrobek, odběratel, pacient),
nebo nehmotný objekt (například pojistný nárok). Entita je pojmenována (podstatným
jménem). Analýza entit se pokouší postupem shora-dolů identifikovat entity.
Při identifikaci entit narazíme na problém úrovně definice entit. Tutéž skutečnost lze popsat
různě, potom často záleží na subjektivním pojetí. Můžeme definovat například entitu OSOBA
nebo jednotlivé entity OTEC, DÍTĚ, UČITEL, VLASTNÍK. V počátečních stádiích analýzy
je často jednodušší definovat obecnější entity, které můžeme později dekomponovat.
Podrobná analýza příslušných problémových oblastí
Základem pro podrobný návrh datových struktur a jednotlivých „počítačem
zabezpečovaných" funkcí je detailní analýza příslušné problémové oblasti (subsystému). Při
analýze vycházíme z podkladů získaných z předcházejících fází.
Detailní analýza je podle této metodiky kombinací analýzy datové a funkční. Primárním
zdrojem pro identifikaci objektů a návrh datových struktur jsou události, při nichž objekty
vznikají, mění se a zanikají a činnosti, které jsou těmito událostmi vyvolané. Analýzu je třeba
provádět za součinnosti uživatelů, prostředkem jsou rozhovory s uživateli. Výsledky
29
rozhovorů se formalizují zápisem do navržených formulářů, které jsou podkladem pro tvorbu
datového modelu a pro specifikaci jednotlivých transformací. Mimo to lze těchto formulářů
využít jako podkladů pro založení metainformačního systému a pochopitelně i jako podkladů
pro dokumentaci informačního systému. [14]
Detailní analýza je velice náročnou fází projektování. Všeobecně lze říci, že je neocenitelným
pomocníkem počítačová podpora, což je podrobněji vysvětleno v recenzích používaného
softwarového vybavení. Uložíme-li do datové základny popisy činností a entit, můžeme
s nimi snadno pracovat, měnit je, tisknout přehledy, ohodnocovat vztahy mezi entitami
a automatizovaně vytvářet strukturní model dat.
Definice úloh pro zajištění činností
Obsahem této fáze je specifikace úloh (resp. transformací na nižší úrovni) nutných pro
zajištění jednotlivých činností. Jedná se především o ty činnosti, jejichž informační
zabezpečení si nemůže uživatel zajistit vlastními silami pomocí programových prostředků
vyšší úrovně (dotazovací jazyky apod.).
Transformace může být realizována pomocí programu v „klasické" formě nebo například
vhodným neprocedurálním prostředkem.
V této fázi se vychází ze specifikace činností v jednotlivých procesech. Předmětem zájmu
jednotlivých činností jsou objekty nebo skupiny objektů. V datové základně pracujeme
s jejich odrazem v datovém modelu - s entitami a atributy. Pro zajištění skupin činností se
navrhují jednotlivé úlohy, resp. dílčí transformace (zajišťující tvorbu, zpracování a aktualizaci
datových prvků).
Z navržených úloh, transformací vyplývají určité požadavky na data (například setřídění,
forma, uspořádání), která se promítnou do řešení v realizační fázi a zpětně mohou ovlivnit
návrh.
Na vyšší logické úrovni, tj. specifikaci úloh nebo skupin transformací, je vhodné použít
strukturovaného hierarchického návrhu, pro specifikaci jednotlivých transformací. Volbu
prostředků a úroveň přístupu přizpůsobujeme pružně konkrétní situaci a složitosti problému.
Upřesnění specifikace dislokace dat
Na základě vstupů z předchozích fází a dále uvedeného postupu upřesňujeme specifikaci
dislokace dat, s ohledem na:
• disponibilní technické a programové zdroje
• omezení a možné umístění technických a programových zdrojů
• minimalizaci výměny dat mezi jednotlivými uzly (nebezpečí vysoké spotřeby času
a kapacit na přenos dat a tím i růstu nákladů na provozování systému).
Při dobře navrženém distribuovaném systému má každý uzel relativně velkou samostatnost
a výměna dat mezi uzly je minimální.
V této fázi projekčního postupu pracujeme již výhradně s entitami v rámci jednotlivých
subsystémů. Jednotlivé aplikace - úlohy subsystémů, resp. v jednodušších případech
samostatné transformace, představují určité nároky na datové prvky, na jejich uspořádání,
dostupnost atd. Každá transformace může být uskutečněna na jiném místě, na více místech
současně, v určité periodicitě a s požadovanou dobou odezvy. Konkretizuje se množství dat,
které budou jednotlivé transakce vyžadovat. Analyzuje se, která data se budou nejvíce
využívat. Tyto úvahy jsou důležité pro konečný návrh distribuce datové základny a programů
systému, pro zpřesnění struktur bází dat atd.
30
Realizace celého návrhu
Detailní návrhy subsystémů považujeme za zadání pro realizaci, za souhrn požadavků, které
v této fázi projektování provádíme pomocí konkrétních programových prvků a fyzických
struktur dat.
V oblasti datové analýzy je zadáním pro implementaci:
• specifikace bází dat
• specifikace entit a atributů.
V oblasti funkční analýzy je zadáním specifikace algoritmů pro jednotlivé transformace (resp.
činnosti probíhající v jednotlivých procesech).
Nyní jsme si nastínili, jak takový postup návrhu informačních systémů vypadá.
V následujícím textu se zaměříme na popis jednotlivých modelů, modelování a analýz.
31
3. Model jednání
Cílem tohoto modelu je popsat komunikaci vytvářeného systému jako černé skřínky
a strukturalizovat okolí systému, které se systémem komunikuje, přičemž model jednání může
mít v procesu projekce tři hlavní úlohy:
-upřesnit zadání
-východisko dynamického modelu
-východisko pro tvorbu objektového modelu [12]
Základní prvky:
-aktor
-typ jednání
-scénář
-impuls
-reakce
-extenze
Výchozí etapa - základní model jednání
Je to model první etapy analýzy (startovní model). Slouží k jasnému oddělení vytvářeného
systému od jeho okolí a ke strukturalizaci tohoto okolí. Systém se zde chápe jako černá
skřínka, nevíme nic o jeho vnitřní struktuře (a také se v rámci modelu jednání o tuto vnitřní
strukturu nezajímáme). Grafické zobrazení viz obrázek.
Aktor je část okolí systému, která komunikuje s vytvářeným systémem. Aktor je role
uživatele, může to být cokoliv, jak člověk, tak jiný systém. Aktor není uživatel, aktor je role,
jeden člověk může působit (postupně) jako několik aktorů. Aktoři se mohou například lišit
právy (administrátor systému je jiná role než prostý uživatel), nebo způsobem zacházení
s daty (uživatel vkládající data je jiný aktor, než uživatel, který si data jen prohlíží). Aktoři
jsou nedeterminističtí. Aktora označujeme obdélníkem.
Typ jednání je kompaktní (logicky uzavřený) popis komunikace mezi aktorem a vytvářeným
systémem, přesněji řečeno, typ scénáře takové komunikace. Typ jednání ve svých důsledcích
určuje funkce modelu, tj. pomocí jejich popisu se definují funkční požadavky na vytvářený
systém. Jeden aktor může vést několik typů jednání, jeden typ jednání může být použitelný
několika aktory. Typ jednání je znázorněn oválem.
Scénář je podrobné rozepsání komunikace aktora se systémem. Je to posloupnost impulsů
aktorů a reakcísystému.
Impuls je komunikace směrem od uživatele k vytvářenému systému, je to požadavek
uživatele na systém nebo odpověď na dotaz systému.
Reakce je odpověď systému uživateli nebo požadavek na uživatele.
Extenze je typ jednání, který doplňuje nebo rozšiřuje jiný typ jednání.
obr. 1
32
Podstatou modelu jednání nejsou nakreslené obdélníky a ovály, jak je ukazují obrázky, ty
poskytují celkový přehled, podstatou modelu je rozčlenění uživatelů do skupin, rozlišení typů
komunikace mezi uživateli a systémem a jejich podrobný popis, tj. slovní scénáře styku mezi
uživatelem a systémem. K modelu náleží slovní popis jak aktorů, tak typů jednání. Právě
v popisu typu jednání, ve slovních scénářích je podstata modelu. Dobrý popis slovních
scénářů umožňuje odlišit akce uživatele od akcí systému. Slovní scénáře modelu jednání se
často používají jako východisko pro tvorbu slovních scénářů dynamického modelu. Slovní
a grafické scénáře dynamického modelu se liší hlavně tím, že zachycují i popis vnitřních akcí,
kdežto model jednání je pohled zvnějšku systému.
Prvky - aktoři
Identifikují uživatele systému, strukturalizují vnějšek systému. Aktor je cokoliv, co si
vyměňuje informace se systémem. Pomocí aktorů určujeme hranice systému, a to tím, že
oddělujeme aktory od typů jednání. Aktor je „třída", jejími instancemi jsou popisy chování,
charakteristiky konkrétních aktorů. Málokdy určíme všechny aktory najednou. Na začátku je
důležité, proč je systém navrhován, komu má systém pomoci. Přímí uživatelé (užívající
systém denně) se nazývají primární. Každý z nich má na systému svůj hlavní úkol. Kromě
nich jsou uživatelé, kteří na systém dohlížejí a udržují jej. Nazývají se sekundární aktoři.
Slouží k tomu, aby primární aktoři mohli používat systém. Je lehké určit lidské role jako
aktory, horší to je s jinými systémy nebo stroji.
Rozdělení na primární a sekundární aktory je dáno hlavním určením systému. Systém děláme
pro jeho hlavní použití, jeho udržování sice není vedlejší věc, promítá se ale až v designu, ne
v rozboru zadání. Obvykle neurčujeme jako aktory podřízené systémy (jako operační systém
nebo zdroj času), ale v nestandardních případech můžeme.
Prvky - typy jednání
Typ jednání je určitý způsob použití systému, který využívá část jeho funkcionality. Typ
jednání je posloupnost událostí iniciovaná uživatelem a specifikuje interakci mezi uživatelem
a systémem. Je to tedy dílčí posloupnost příbuzných transakcí prováděných v dialogu mezi
aktorem a systémem. Model jednání (souhrn všech typů jednání) určuje všechny možné
způsoby využití systému.
Můžeme to chápat tak, že typ jednání representuje přechodový diagram (celého systému). Typ
jednání je tedy posloupnost stavů. Ovšem tento přechodový diagram nevytváříme, pro určení
dynamiky systému používá dynamický model poněkud jiné prostředky.
Tím, že začínáme s aktory, usnadňujeme si identifikaci typů jednání. Projdeme všechny
aktory, pro každého určíme jeho typy jednání, a tím získáme přehled přes všechny funkce
systému.
Aktor nevyžaduje určitý typ jednání, více aktorů může mít tentýž typ jednání, jeden aktor
může vést několik různých typů jednání. Typy jednání mohou začínat stejně, nelze aktory od
sebe odlišit tím, jak začínají svou komunikaci, aktor inicializuje typ jednání a udržuje dialog.
Typy jednání se identifikují pomocí aktorů. I složitá posloupnost událostí je jeden typ jednání.
Při tvorbě typů jednání se vžíváme do role aktora. Pomohou nám otázky typu:
-Jaký je hlavní úkol aktora?
-Aktor čte (zapisuje / mění) data systému?
-Informuje aktor systém o změnách vně systému?
-Má být aktor informován o neočekávaných změnách?
Je na naší vůli, jestli máme jeden složitý typ jednání nebo několik jednoduchých. Typ jednání
má jeden hlavní proud a několik vedlejších, které obhospodařují chyby, výjimky ap.
Každý typ jednání popíšeme podrobně, tj. jako slovní scénář. Často tím objevíme nepřesnosti
v dřívější práci. Je to velmi podrobný popis systému. Tímto způsobem tedy popisujeme
33
celkovou funkcionalitu systému inkrementálním způsobem, po jednotlivých dílčích jednáních.
Může se tak stát, že popíšeme tatáž nebo podobná jednání v nezávislých typech jednání. Je
tedy dobré po tomto popisu pokusit se typy jednání zobecnit, tj. příbuzné typy spojit. Pak lze
rozdělit práci na vývoji systému mezi více lidí.
Zvýšení podrobnosti zavedením podrobného modelu jednání
Objektově orientovaný třídní přístup
V modelu jednání, stejně jako v celé metodice, se používá třídní přístup (objektově
orientovaný), a ne vždy se jedná o objekty v běžném smyslu slova. Použitý aktor je třída, typ
jednání je třída. Instancí aktora je vedení konkrétního dialogu. Instancí typu jednání je scénář.
Vztah mezi typem jednání a scénářem je stejný, jako mezi třídou a objektem, typ jednání je
abstraktní popis, který může být realizován jednotlivými konkrétními scénáři.
Plyne z toho dvojí popis typu jednání, jednak celková charakteristika typu jednání, jednak
podrobný popis ve formě scénáře. Popis typu jednání je popis abstrakce, kdežto scénář je
popis všech konkrétních forem jednání. Dvojí popis typu jednání plní dvě úlohy: prověrky
a rozvoje.
-Zdrojem charakteristiky typu jednání je uživatel a na začátku projekce je určitá
neujasněnost a nepřesnost. Rozpis typu jednání do scénáře je dobrý prostředek jak
určit, zdali uživatel souhlasí s tím, co říká, je to prověrka správnosti zadání.
-Charakteristika typu jednání je konstanta projekce. Po prověrce zadání a jeho přesné
formulaci se typy jednání mění vcelku výjimečně (i když nemožné nebo zakázané to
není). Co se ale bude měnit je hloubka našeho vniknutí do problémů vytvářeného
systému, úroveň znalostí konstruktéra a tedy podrobnosti popisu systému. Také
použití modelu jednání za různými účely vyžaduje jinou úroveň podrobností. Dvojí
popis typu jednání nám umožňuje neměnit charakteristiky typu jednání a měnit
(zpodobňovat) scénáře.
Při zvýšení úrovně podrobnosti nad určitou míru přestávají být scénáře srozumitelné a tento
postup není únosný. Je účelné využít třídních vlastností typu jednání (abstrakce) a popis
rozčlenit na několik úrovní. Jedná se o analogii s děděním a delegací v objektovém modelu,
zde se však používají spíše termíny vkládání a doplňování. Model jednání se rozšiřuje
o vkládané a rozšiřující typy jednání, kterým se také říká extenze viz obrázek. Model jednání
(jeho vývoj) tím nabývá inkrementální charakter.
obr. 2
Smysl zavedení podrobného modelu
Již bylo řečeno, že model jednání se používá pro dva hlavní účely, pro formulaci zadání (ve
spolupráci s uživateli a zadavatelem) a pro analytickou práci. Při formulaci zadání vznikne
model jednání a v této úrovni bude po celou dobu životního cyklu systému sloužit
k specifikaci funkcí systému a ke kontrole správnosti vytvářeného systému. Model jednání
34
můžeme také použít k tomu, aby s jeho pomocí vznikl analytický model, což ovšem
zadavatele příliš nezajímá.
Rozdíl mezi základním a podrobným modelem jednání není v tom, jestli byly nebo nebyly
použity extenze, ale v tom, jak jsou modely použity. Tedy: základní model je vytvořen pro
komunikaci s uživateli, podrobný model vychází ze základního (zjemňuje jej) a je určen po
analýzu.
Abstraktní typy jednání neboli extenze
Extenze mohou být jak abstrakce (v třídním smyslu), tak je lze chápat jako podčásti.
Extenze popisují, že může být jeden typ jednání vsunut do jiného typu jednání a ten tak
rozšířen (také mohou na sebe navazovat). To je snadná cesta ke změně funkcionality.
Znamená to, že popisy extenzí jsou součástí konkrétního (původního) typu jednání. Popis
konkrétního typu jednání pokračuje od určitého bodu popisem abstraktního typu jednání. Je to
určitý typ dědění, ale není to dědění v tom smyslu, jak se to chápe v objektově orientované
terminologii. Proto je použit i jiný název, říkáme, že konkrétní typ jednání užívá (uses)
abstraktní typ jednání. Jedná se o jakési podprogramy, to ale není přesná představa, protože
jestliže jeden konkrétní typ jednání využívá dvou abstraktních, tak popisuje, jak se jejich
chování prokládá. Rozšiřovaný typ musí mít úplný popis, tak, aby se rozšířením nic neměnilo.
Tento postup je hierarchický, tj. z extenzí můžeme vydělit jejich společné části a zavést
extenze další úrovně.
Zavedení extenzí (tedy vlastně abstraktních typů jednání) vede k úvahám o abstraktních
aktorech. Jestliže několik aktorů používá tytéž typy jednání, je možné zavést abstraktního
aktora, který používá tyto typy jednání, což od něj dědí konkrétní aktoři. Užitečnost tohoto
postupu je v tom, že se nalezne podobnost v jednání. Jiné užití je v definování práv přístupu.
Příklady použití extenzí:
-Nepovinné části typu jednání
-Alternativní cesta ve složitém typu jednání.
-Podčásti, které se provádějí za určitých okolností.
-Podčásti, které se provádějí u různých typů jednání.
-Popis případů, kdy může být několik různých typů jednání vsunuto na totéž místo.
Mohli bychom uvažovat i o takovém rozšířeném jednání, které lze vsunout na libovolné místo
nadřízeného typu (podobně jako přerušení).
Pro každý vsunutý (rozšiřující) typ jednání musí být přesně určeno místo, kam se
v rozšiřovaném typu jednání vsune. Toto místo je popsáno v rozšiřujícím typu, ne
v rozšiřovaném.
Model jednání rozšířený o třídy objektového modelu
V některých případech je užitečné vyjádřit vztah mezi typy jednání a konkrétními třídami
objektového modelu. Vztah mezi typem jednání a třídou vyjadřuje odpovědnost třídy za
vedení dialogu (realizaci scénáře), viz obrázek.
35
obr. 3
Nedoporučuje se odvozovat třídy přímo z typů jednání (tj. přímý přechod od modelu jednání
k rozšířenému modelu jednání), rozšířený model jednání slouží k pochopení vztahu již jinde
odvozených tříd (nebo subsystémů) k rozhraní systému. Rozšířený model jednání je většinou
prostředek pro porovnání dvou modelů.
36
4. Funkční model, modelování a analýza
Funkční model, účel a charakteristika
Tento model vytváří kontrolní pohled na vytvářený systém, identifikuje a popisuje algoritmy.
Jeho cílem je rovněž popsat vztahy mezi procesy a mezi procesy a daty.
Základní prvky:
- proces
- datový sklad
-datový tok
- terminátor (aktér)
Diagramy:
- kontextový diagram
- systémový diagram
- běžný diagram (DFD)
DFD = data flow diagram = diagram datových toků
Funkční model je totožný s modelem datových toků strukturálního přístupu. [8]
Funkční model se soustředí na popis navrhovaných procesů (výpočtů), na potřebná data
a hlavně na přístupnost dat k jednotlivým procesům. Jeho základním postupem je hierarchický
rozklad procesů v podprocesy. Abstrahuje od dynamické složky a od nositelů procesu.
Funkční model uvádí proces bez ohledu na to, kdo a kdy ho používá.
Má mnoho společného s OM. Z procesů plynou operace a akce. U úloh určitých typu přebírá
funkční model úlohu hlavního modelu celé projekce.
Přehled prvků modelu
Proces (označuje se také jako „funkce"). Obsahuje výpočet (algoritmus nebo jeho část) - je to
aktivní prvek systému (data jsou pasivním prvkem). Jeho vstupy a výstupy jsou datové toky.
Rozkládá se na síť podprocesů, tj. jeden proces lze podrobněji popsat pomocí sítě podprocesů
na samostatném běžném diagramu. Proces je zobrazen kolečkem (nebo oválem).
Procesy jsou implementovány jako metody složené z operaci objektů (tříd).
Hlavní úlohou procesu je popsat transformaci dat. U procesu se uvádějí všechny možné
vstupní a výstupní datové toky nezávisle na tom, kdy se přesuny dat provedou a nezávisle na
tom, jsou-li data potřebná vždy nebo jen někdy. Proces může mít vedlejší složky, jako sklady
dat nebo externí objekty. FM pouze ukazuje možné cesty, neurčuje, která cesta se právě
provádí.
Datový tok je zobrazen šipkou mezi vysílacím a přijímacím prvkem. Slova „datový tok"
gramaticky označují dynamický pojem, tj. předávání datových záznamů. V modelu však tato
slova (šipka v grafickém vyjádření) označují cestu pro předávaná data, tj. jen možnost data
předávat, neoznačují jen právě předávaná data. Datový tok representuje datový záznam
(záznamy nebo jejich zobecnění), který je vyměňován mezi procesy nebo mezi procesem
a datovým skladem.
Datový tok reprezentuje datovou hodnotu. Nemění ji. Může se větvit tak, že posílá totéž na
více míst nebo rozkládat data na komponenty. Slévání a větvení datových toků se mnohdy
používá proto, aby se snížil počet čar na výkresu.
Datové toky nereprezentují (nemusí reprezentovat) realitu.
37
Datový tok je generalizace předávaných dat, respektive předávaná data jsou instancí
datového toku, podobně jako třída je generalizací objektů a objekt instancí třídy
Datový sklad je úložiště dat (datová paměť). Je to pasivní prvek systému. Vstupní datové
toky přinášejí data určená k uložení, výstupní datové toky dávají uskladněná data k disposici
procesům. Datový sklad je zobrazen rovnoběžnými úsečkami (obdélníkem bez kratších stran).
Datový sklad většinou chápeme jako stejnorodý, tj. jako soubor nebo tabulku.
Pojmenováváme jej jménem záznamu nebo řádku, tj. jméno datového skladu je v jednotném
čísle, byť obsahuje více záznamů!
Vstupní tok mění obsah datového skladu, což zahrnuje přidání elementu, změnu hodnot,
výmaz elementu. Výstupní tok zahrnuje přenos celého elementu nebo jeho části. Konstantní
sklad dat je bez vstupu. Jestliže vstupní tok přidává (maže) element datového skladu nebo
jestliže výstupní tok přenáší všechny elementy datového skladu, pak není nutno datový tok
pojmenovat.
Objektově orientovaná je notace, kterou zavedl Rumbaugh. Je to zvláštní označení datového
toku, který generuje objekt jako cíl jiné operace, je to velká prázdná šipka (trojúhelníček).
Je nutno podotknout, že při objektově orientovaném použití funkčního modelu datové sklady
odpovídají třídám. Někdy bývá vhodné označit proces, který zapříčiní vznik nového objektu.
Zde to je označeno zvláštní šipkou mezi procesem, který konstruuje nový objekt, a třídou,
jejíž objekt je nově konstruován.
Terminátor (aktér) je část okolí vytvářeného systému, která s ním komunikuje
prostřednictvím datových toků. Terminátor je zobrazen obdélníkem.
Aktér je zdroj nebo nor datových toků, z aktéra vycházejí datové toky a v něm končí.
Tradiční název strukturovaného přístupu je terminátor - jsou to synonyma.
Aktéři i sklady dat odpovídají objektům. V implementaci není rozdíl, ale v chování ano. Sklad
dat může být také soubor (nebo databáze), aktér může být externí zařízení. Některé datové
toky jsou také objekty, většinou to ale jsou čisté hodnoty.
Přehled diagramů modelu
Kontextový diagram je v procesním hierarchickém rozkladu prvým (nejvyšším) diagramem,
kde jsou uvedeny terminátory a datové toky mezi nimi a vytvářeným systémem. Systém je
zobrazen jako jediný proces diagramu. (viz obrázek). Obdélníčky znázorňují entity okolí
navrhovaného systému, šipky pojmenovávají datové toky, které proudí do nebo ze systému.
Entity okolí se pojmenovávají jako terminátory (původní pojmenování) nebo jako aktéry
(objektové pojmenování). Kontextový diagram je zobrazení nulté úrovně, kde je pouze jeden
proces - celý navrhovaný systém. Proces „Navrhovaný systém" se rozloží diagramem první
úrovně na síť podprocesů atd.
38
obr. 4
Systémový diagram je diagram „nulté" úrovně, kde jsou uvedeny základní procesy, na které
se rozkládá vytvářený systém. Procesy jsou očíslovány a pojmenovány. Označujeme je
kruhem nebo oválem.
Běžný diagram se také nazývá „diagram datových toků" nebo DFD (Data Flow Diagram).
Běžný diagram je zjemnění (zpodrobnění) jednoho procesu jako síť procesů a datových
skladů komunikujících spolu prostřednictvím datových toků.
Každý proces je zpodrobněn právě na jednom diagramu. Každý diagram odpovídá jednomu
procesu. Procesy kterým nepřísluší diagram (nejsou zjemňovány) se nazývají listové procesy,
protože ve stromu hierarchického rozkladu procesů tvoří listy.
Pro vyšší přehlednost zápisu je možné použít agregované datové toky, které jedním grafickým
prvkem (šipkou) označují několik datových toků -ovšem s tímtéž producentem
a konzumentem. (Při dalším zjemnění mohou být tyto datové toky produkovány různými
podprocesy a/nebo přijímány různými podprocesy - to je náš případ, jak bylo zmíněno
v předchozím odstavci.) Datový sklad může být uveden na několika diagramech (i různé
hierarchické úrovně) i vícekrát v jednom diagramu, pokud to vyžaduje přehlednost zápisu.
Řídicí prvky. Někteří autoři zavádějí řídicí prvky - řídicí procesy (čárkované kružnice)
a řídicí toky (čárkované šipky).
Řídicí tok je přenos Booleovské hodnoty, která ovlivňuje proces. Řídicí prvky jsou někdy
užitečné, ale duplikují dynamický model.
Hranice mezi datovými a řídicími prvky je neostrá, každý proces je z části datový a z části
řídicí. Řídicí tok určuje přenos dat o velikosti jednoho bitu (s hodnotou Ano - Ne), podobné
jako předání dat nese sebou řídicí událost - že k tomuto předání došlo. Použití řídicích prvků
ve funkčním modelu je věcí osobního vkusu, obvykle se nedoporučuje míchat dva různé
pohledy v jednom diagramu.
Konvence zápisu běžného diagramu. Nezaznamenávají se producenti vstupních toků do
diagramu a konzumenti výstupních toků diagramu, takže tyto šipky jsou bez konců. Tento
způsob zápisu někdy mate, protože datové toky se často jmenují stejně (i když je záznam
různě zpracováván, jeho jméno se nemění). Proto se někdy používá způsob (pokud to CASE
dovolí), že se do běžného diagramu zaznamenávají producenti vstupních toků a konzumenti
výstupních toků.
Vnoření DFD. Podstatou funkčního modelu je to, že proces může být (a nemusí) rozložen
v poddiagram. Při práci s tímto modelem vzniká velké množství diagramů a je velmi žádoucí
udržet si o nich přehled. Obrázek níže ukazuje způsob záznamu hierarchie výkresů
(diagramů). Na nejnižší úrovni jsou jednoduché listové procesy (funkce), které slouží
v objektovém modelu ke specifikaci operací.
39
obr. 5
Textové popisy jednotlivých prvků
Textový popis je neoddělitelnou součástí grafického popisu modelu.
Textový popis datového skladu musí obsahovat informace o struktuře dat do té míry, aby se
dal porovnat s deklarací atributů odpovídající třídy.
Textový popis procesu by měl obsahovat následující složky:
-popis transformace,
-popis omezení,
-možnosti optimalizace.
Transformace definuje účinek operace, tj. výstupní hodnoty jako funkce vstupních hodnot
a vedlejší efekty na svůj objekt. Popis transformace nemusí být implementační, stačí takový
popis, aby byl zřejmý efekt transformace. Například: inverze matice A v B není nutno
definovat algoritmem, natož vymýšlet optimální algoritmus. Postačuje když je inverze
definována jako A*B=I. Z popisu musí být jasná transformace, ne její implementace.
K popisu lze použít nejrůznější prostředky, například:
-základní matematické funkce (sin),
-tabulky vstupů a výstupů,
-rovnosti (funkce obecně),
-pro- a post- podmínky,
-rozhodovací tabulka,
-pseudokód,
-přirozený jazyk.
Omezení omezuje platnost transformace na určitý definiční obor nebo podmiňuje
transformaci podmínkami. Omezení je stejně důležité jako samotný popis transformace, mimo
omezení totiž transformace nemusí platit.
Možnosti optimalizace. Při určování transformace a úvah o algoritmech je vhodné
poznamenat si poznatky o možnostech optimalizace. Má to samozřejmě smysl u transformací,
o kterých ze zkušenosti víme, že jsou časově nebo prostorové náročné. Tyto poznámky
usnadní pozdější volbu algoritmu.
40
Funkční modelování, cíl a postup
Toto modelování zachycuje procesní vztahy v úloze a popisuje vytvářený systém jako síť
procesů a skladů dat svázaných datovými toky.
Úlohou FM (funkčního modelu) je ukázat, jak se počítají hodnoty, bez ohledu na pořadí,
rozhodování a objektovou strukturu a určit přístupnost dat pro tyto procesy. FM ukazuje, jak
proces výpočtu závisí na vstupních hodnotách a datových skladech (pasivních úložištích dat).
Diagramy datových toků (DFD, tj. data flow diagram) tuto závislost vyjadřují. Procesy
(funkce) lze vyjádřit přirozenou řečí, matematicky nebo pseudokódem. [21]
Procesy v DFD odpovídají:
-operacím objektového modelu (OM) nebo
-aktivitám a akcím dynamických modelů (DM).
Datové sklady odpovídají atributům tříd objektového modelu (OM). Datové toky odpovídají
parametrům událostí dynamických modelů (DM).
Podle typu úlohy buď přebírá úlohu hlavního modelu pro konstrukci systému nebo slouží pro
ověření objektového modelu.
Kroky postupu jsou následující:
1. zachycení vstupů a výstupů systému – kontextový diagram,
2. konstrukce Data-Flow-Diagramů,
3. deklarativní nebo procedurální popis procesů,
4. identifikace vynucených meziobjektových vztahů,
5. zvolení hodnot, které mají být optimalizovány.
Zachycení vstupů a výstupů systému – kontextový diagram
Nejdříve je nutno zachytit všechny vstupy a výstupy systému a systém samotný zaznamenat
jako jeden obecný proces (černou skřínku), který budeme v další činnosti zjemňovat. Tomuto
prvému diagramu postupu říkáme kontextový diagram. Jeho důležitost je bezesporná.
Vstupní a výstupní hodnoty jsou parametry událostí mezi systémem a vnějším světem.
K identifikaci datových toků můžeme s výhodou použít slovních scénářů, podobných jako
v dynamickém modelu (lze uvažovat i o využití těchže scénářů pro obojí použití).
Konstrukce Data-Flow-Diagramů
Konstrukce DFD je postup, který lze dobře zvládnout intuicí. Právě proto je třeba zde vnést
řád. Funkční model popisuje proces na několika úrovních. Nejdříve je nutno vytvořit
kontextový diagram, který budeme v další činnosti zjemňovat. Na nejvyšší úrovni DFD musí
být jeden nebo jen několik procesů - každý z nich zpracovává údaje jednoho vnějšího činitele
(aktéra). Datové toky mezi těmito procesy obsahují výčet všech dat nutných pro zpracování.
Každý diagram (DFD) podrobněji rozepisuje jeden proces vyšší úrovně. Každý diagram musí
obsahovat tytéž vstupní a tytéž výstupní datové toky jako nadřízený proces, jehož je
zjemněním.
Výchozí situace pro vznik zjemnění procesu je tato:
-máme prázdný výkres,
-do kterého směřují vstupní datové toky,
-ze kterého vycházejí výstupní datové toky
-a máme popis zjemňovaného procesu, který máme rozepsat.
Vycházíme od výstupních hodnot a určujeme funkce (procesy), které je vypočtou. Tyto
procesy potřebují pro uskutečnění výpočtu určité vstupní hodnoty. Pokud nejsou tyto vstupní
hodnoty procesu i vstupními hodnotami diagramu, bereme tyto vstupní hodnoty jako
mezivýsledky a vytvoříme proces (popíšeme funkce), který je vypočte. Mezivýsledky
můžeme brát z datových skladů nebo jako výstupy jiných procesů na tomto diagramu. Tento
41
postup opakujeme, až vytvoříme algoritmické cesty mezi vstupními a výstupními daty.
Hierarchický funkční rozklad je velmi intuitivní, podrobné předpisy postupu nejsou v zásadě
zapotřebí. Na schematickém příkladě si ukážeme nejdůležitější konvence. Obrázek ukazuje
kontextový diagram tohoto schematického příkladu, od nějž se vše odvíjí.
obr. 6
obr. 7
Je samozřejmé, že nepracujeme s holými obrázky, ale že vše je doprovázeno popisy. Popisem
systému jako černé skřínky je vlastně celé zadání, proto se také kontextový diagram řadí spíše
do rozboru zadání než do vlastní analýzy. Na dalším obrázku vidíme rozpis procesu Systém.
Výkres je označen jménem rozepisovaného procesu (na obrázku vlevo nahoře), jsou zde
uvedeny jeho datové toky (dt1 a dt2). Datové toky musí být pojmenovány a popsány, nic nám
není platný i pojmenovaný datový tok, o němž nevíme, jaké položky popisuje.
Na obrázku jste si jistě všimli, že datové toky do datového skladu a z něj nejsou popsány.
Datový sklad se většinou považuje za homogenní, obsahuje množinu záznamů stejného typu.
To se vyjadřuje i tím, že datový sklad bývá pojmenován tímto typem (v jednotném čísle) - tak
se třeba jmenuje Kontakt (a ne Kontakty).
Jestliže datový tok popisuje předávání dat po celých záznamech, pak jej není nutno
pojmenovávat ani popisovat, protože jméno a popis datového toku by jen opisovaly jméno
a popis datového skladu.
Datové toky do datového skladu a z něj musí být popsány, jestliže popisují přenos jen částí
záznamů - nutnost popisu je zřejmá.
Na dalším obrázku je popsán fiktivní rozklad druhého procesu.
obr. 8
42
Můžeme si zde všimnout rozdílu mezi procesy a datovými sklady. Každý proces může být
pouze na jednom výkresu (jeho jméno se může ještě objevit ve jméně výkresu, který jej
podrobné rozepisuje).
S datovými sklady to je jiné. Ty se mohou objevovat na kterémkoliv výkresu, dokonce mohou
být i na jednom výkresu několikrát, pokud to z důvodů přehlednosti potřebujeme.
Druhou důležitou věcí je to, že funkční model znázorňuje datové toky a ne časovou návaznost
procesů. To si hned uvědomíme, když si všimneme, že Proces 2.1 a Proces 2.2 nejsou spojeny
datovým tokem. Nepředávají si totiž data přímo, ale pouze prostřednictvím Datového skladu
2. Pravděpodobně jsou spojeny řídícím tokem, není však obvyklé (a praktické), zaznamenávat
v DFD řídicí toky (i když výjimku udělat můžeme).
Výše uvedené příklady používají způsobu značení, který se používá v systémech CASE, které
jsou specialisovaný na funkční modely. Když však takový systém nemáme přístupný
a musíme používat obecné grafické prostředky, pak je užitečná konvence znázorněna na
dalším obrázku.
obr. 9
Je užitečné zobrazovat kontext podrobného DFD. Nevést datové toky z ničeho a do ničeho,
ale přikreslit do diagramu producenty nebo konzumenty dat. Samozřejmě je dobré graficky je
odlišit, aby nemátly. Tato konvence zvyšuje rychlost orientace v diagramu.
Zjišťování konsistence funkčního modelu obvykle spočívá v kontrole, zdali si odpovídají
datové toky (a jejich jména) mezi dvěma diagramy (u procesu a v diagramu, který je
rozepsáním tohoto procesu).
obr. 10
Jména datových toků nemusí být unikátní, protože proces může zpracovávat data aniž mění
jejich formát nebo tvar, viz obrázek.
Běžnou chybou (zvláště tehdy, jestliže model má mnoho diagramů) je to, že tytéž datové
sklady vystupují pod různými jmény a s trochu odlišnými popisy.
Chyby v návrhu modelu jsou indikovány nemožností vytvořit cestu pro přenos dat nebo
nepoužitými výstupními daty. Řešení těchto rozporů vede k iteraci tvorby FM nebo
i celkového modelu (OM, DM, FM).
Deklarativní nebo procedurální popis procesů
Každý proces na každé hierarchické úrovni musí být dostatečně popsán, tak aby bylo zřejmé,
co je úkolem transformace procesem prováděné. Zvláštní pozornost musíme věnovat listovým
funkcím (procesům), tj. těm, které již nejsou dále rozkládané.
Forma popisu je celkem libovolná, je nutno se soustředit na definici funkce (na to, co se má
udělat) a ne na její implementaci (na to, jak se to dělá). Popis může být deklarativní (popis
vstupních a výstupních hodnot) i procedurální (algoritmus). V tomto případě to je popisný
algoritmus, který definuje vstupy a výstupy, později bude zaměněn implementačním
43
algoritmem, který bude realizovat vyžadovanou optimalizaci. Dáváme přednost deklarativním
popisům funkcí.
Identifikace vynucených meziobjektových vztahů
Identifikujeme vynucené vztahy mezi objekty (sklady odpovídají objektům nebo jejich
částem, funkce metodám) a zařazujeme je do popisu. Jsou to vztahy, které musí být mezi
objekty, i když je nikdo nepožaduje. Například zbytek účtu nesmí být záporný, nebo uživatel
musí vždy dostat odpověď, i když jeho žádost nevyvolala žádnou reakci.
Zvolení hodnot, které mají být optimalizovány
Určíme hodnoty, které mají být co největší, co nejmenší nebo jinak optimalizované. Určujeme
co se má optimalizovat (nebo co lze optimalizovat), nikoli jak. Příklady: omezit počet zpráv
mezi objekty, minimalizovat čas rezervace dat. Častým předmětem optimalizace je výběr hledání ve větších seznamech.
44
5. Databáze, jazyk SQL, datový model a datová analýza
Používání databáze
Princip získávání informací
Abychom mohli začít pracovat s databázemi, musíme se nejprve seznámit se základními
pojmy a vysvětlit si jejich význam a použití. Práce s databázemi je totiž principiálně odlišná
od programů, se kterými jsme se setkali dříve. Jak v textovém editoru, tak i v tabulkovém
kalkulátoru pracujeme s určitým souborem, který postupně upravujeme do žádoucí podoby píšeme odstavce nebo opravujeme hodnoty v tabulce, zvýrazňuje důležité části atp. —
a nakonec jej vytiskneme na tiskárně. Oproti tomu je základní princip práce s databází jiný.
Nejčastějším případem je situace, kdy databáze obsahuje pro nás zajímavé informace a my se
je snažíme z databáze získat v pro nás přehledné formě. Postup je tedy následující: zadáme
„dotaz", kterým popíšeme informaci, kterou chceme získat, a po chvíli se na obrazovce objeví
„odpověď". Tato odpověď může být přesně tím, co jsme chtěli vědět, a naše práce končí.
Může se však stát, že náš dotaz byl špatně formulován nebo jsme nezískali přesně
požadovanou odpověď, a musíme tedy dotaz přeformulovat. Opravený dotaz znovu zadáme
do počítače a získáme novou odpověď. Postupně se tak dopracujeme až k požadované
informaci.
Databáze jako soubor dat
Vysvětleme si nyní, co vlastně databáze je a z čeho se skládá. Původní název používaný
v české literatuře byl databanka. Pod tímto názvem si většina z nás dokáže představit určitý
soubor informací (dat).
Může se jednat o databanku údajů o zákaznících velkoprodejny potravin. Informace o těchto
zákaznících může sloužit při různých reklamních akcích - například k rozesílání
blahopřejných dopisů k životním jubileím. Vlastní forma databanky - zda je uložena
v počítači nebo v papírové formě v pořadačích - není v této chvíli podstatná. Obě formy nám
dovolují zjistit údaje o vybrané osobě nebo osobách a využít je podle našich potřeb. A tento
způsob pohledu na databanku (nebo moderněji databázi) můžeme zachovat i při její existenci
v počítači. Dívejme se tedy na databázi jako na velkou skříň s pořadači, ve kterých je uloženo
obrovské množství informací. Počítače nám pouze umožňují pracovat s databází efektivněji,
to znamená rychleji vyhledat požadované informace nebo provádět různé sumarizace
a statistiky. [16]
Soubor uživatelských informací - datová základna
Soubor všech uživatelských dat uložených v databázi se nazývá datová základna.
Nebudeme brát v úvahu rozdíl mezi daty a informacemi. Budeme předpokládat, že veškerá
data jsou pro nás zároveň informacemi, protože je dokážeme interpretovat a přiřadit jim
smysl.
Využití možností a nástrojů pro práci s daty
Kromě rozčlenění do pořadačů máme k dispozici ještě nástroje pro efektivní vyhledávání
požadovaných informací. Mezi tyto nástroje patří štítky s počátečními písmeny na každé
zásuvce. Potom jsme schopni daleko rychleji nalézt požadovanou složku, aniž bychom museli
procházet celou skříň. Na data v elektronické podobě žádné štítky lepit nemusíme, ale na
druhou stranu mezi oběma způsoby uložení dat zůstává řada paralel.
45
Data a nástroje pro práci s nimi tvoří databázový systém
Databázový systém = data + nástroje pro práci s daty
Sloučením dat a nástrojů, pomocí kterých tato data vytváříme, aktualizujeme, vyhledáváme
a rušíme, získáme databázový systém. Každý databázový systém musí obsahovat nástroje pro:
• vytvoření, vyhledání, aktualizaci a rušení uživatelských dat,
• definici struktury dat,
• definici a zajištění integrity dat,
• zajištění fyzické a logické nezávislosti dat.
A případně nástroje pro:
• podporu práce více uživatelů (zejména definici transakci a přístupových práv),
• zálohování dat.
Nezávislost dat - fyzická
Fyzická nezávislost dat znamená oddělení způsobu fyzického uložení dat (například na disku)
od způsobu práce s nimi. Chceme-li pracovat s tabulkou zaměstnanců, odkážeme se na ni
pomocí jejího názvu (např. zam) a nemusíme se zabývat tím, kde je uložena na disku počítače
a jakým způsobem jsou fyzicky zaznamenána data v ní uložená.
Nezávislost dat - logická
O logické nezávislosti dat hovoříme tehdy, když změna logické struktury dat (její rozšíření
o další tabulky nebo sloupce v existující tabulce) nevyžaduje úpravu již existujících programů
nebo dotazů pracujících s daty.
Uložení dat v databázi
Data v databázových tabulkách
V textovém editoru pracujeme s textovými soubory, v tabulkovém kalkulátoru s tabulkovými
listy a v databázovém prostředí jsou to hlavně databázové tabulky. Databázová tabulka je
velmi podobná tabulce v tabulkovém kalkulátoru. Jedná se však o tu nejjednodušší formu
tabulky s jedním titulkovým řádkem a bez jakýchkoliv titulků u jednotlivých řádků. Všechny
ostatní hodnoty v tabulce jsou uživatelská data. Ukázku databázové tabulky, která obsahuje
údaje o několika zaměstnancích fiktivní firmy, vidíme níže.
Datum
Příjmení Jméno
narození
Výše platu v Kč
Novák
Adam
15.3.1956
6.000
Polesný František 25.11.1948
7.500
Drtina
Robert
1.4.1962
8.000
Veselá
Anna
4.5.1960
7.000
Smejkal Otakar
19.8.1959
8.000
tab. 1
Prvky tabulky
• sloupec
• řádek
• hodnota
Atributy neboli sloupce tabulky
Tato velmi jednoduchá tabulka obsahuje čtyři sloupce, kterým se také může říkat atributy.
Jsou to postupně Příjmení, Jméno, Datum narození a Výše platu. Každá tabulka musí
46
obsahovat alespoň jeden sloupec.
Záznamy neboli řádky tabulky
V tabulce vidíme celkem pět řádků obsahujících data. Řádky můžeme nazývat také záznamy.
V tabulce bývá obvykle mnoho řádků. Můžeme se setkat s tabulkami, které obsahují až
miliony řádků a na druhé straně jsou tabulky, ve kterých není řádek žádný -jsou prázdné.
Pouze celé řádky můžeme do tabulky přidávat nebo z ní mazat. Výsledkem našich dotazů
bude opět převážně řádek nebo více řádků.
Uživatelská data neboli hodnoty
V průsečíku každého řádku a sloupce je hodnota zadaná uživatelem. Tato hodnota
reprezentuje určitý vztah mezi řádkem a sloupcem. V průsečíku řádku popisujícího
zaměstnance Nováka se sloupcem Plat nalezneme výši platu pana Nováka apod.
Řádek tabulky je potom skupina hodnot, která obsahuje stejný počet prvků jako je počet
sloupců v tabulce. První řádek naší tabulky tedy je (Novák; Adam; 15. 3. 1956: 6000}, další
{Polesný; František; 25. 11. 1948; 7500} atd.
Druhy dat neboli datové typy
Již z naší velmi jednoduché tabulky vidíme, že data obsažená v různých sloupcích mohou být
různého druhu. Jsou zde hodnoty ve sloupci Datum narození, které jsou vždy zadány jako
datum a jako s datumem s nimi můžeme pracovat - můžeme zjistit den v týdnu, dvě hodnoty
můžeme od sebe odečíst a získáme počet roků, měsíců a dní mezi nimi apod. Dále jsou zde
hodnoty ve sloupci Výše platu, se kterými můžeme pracovat jako s čísly - můžeme je sčítat,
odčítat, násobit apod. Existují však i další druhy hodnot, které se mohou v tabulce vyskytovat.
Odborně se těmto druhům hodnot říká datové typy. Mezi základní datové typy patří Text,
Datum, Číslo a logická hodnota Ano/Ne. S těmito datovými typy jsme se mohli setkat již
v tabulkovém kalkulátoru. Pouze jsme explicitně nemuseli určovat typ pro každou vkládanou
hodnotu. Všimněme si však, že narozdíl od tabulkového kalkulátoru se v jednom sloupci
mohou vyskytovat pouze hodnoty stejného datového typu. Tento fakt vyplývá i z naší definice
databázové tabulky, která může mít titulkový pouze první řádek. Potom je zřejmé, že nemá
smysl požadovat např. vložení hodnoty typu Datum do sloupce Výše platu. Z těchto důvodů
hovoříme o datovém typu celého sloupce (nebo atributu) tabulky.
Několik základních datových typů
• Znak (text)
Jedná se o základní datový typ. Sloupec tohoto typu může obsahovat libovolné znaky a to jak
písmena, tak i čísla a některé další znaky jako čárky, pomlčky středníky, závorky atd. Používá
se zejména pro názvy (jako Příjmení a Jméno) a dále pro uložení všech hodnot, které není
možné zařadit do některého dalšího datového typu.
• Číslo
Číselný datový typ může obsahovat pouze číselné hodnoty určitého rozsahu. Rozlišujeme
několik druhů číselných datových typů. Mezi základní rozlišení patří, jestli se jedná o celé
nebo desetinné číslo. U celých čísel rozlišujeme jejich rozsah - např. od O do 255, od -32768
do 32767 apod. U desetinných pak maximální počet platných číslic celkem a za desetinnou
čárkou. Číselné rozsahy jednotlivých datových typů závisí na používaném databázovém
systému.
• Datum
Slouží pro uchování datumu v libovolném formátu (den-měsíc-rok, DD/MM/RRRR atp.) Ve
většině databázových systémů bývá do datumu zahrnut i čas.
47
• Dvoustavový typ Ano/Ne
Tento speciální datový typ slouží pro uchování logických hodnot Ano (pravda) a Ne
(nepravda). U každého zaměstnance bychom například mohli zaznamenávat, jestli je, nebo
není členem odborů.
Mimo těchto typů rozeznáváme i další např. typ Měna, typ Objekt atd. přičemž musíme
počítat i s tím, že v jednotlivých databázových prostředích mohou být použity odlišné názvy
pro jednotlivé datové typy.
Data ve více tabulkách a vazby mezi nimi
Zatím jsme se věnovali pouze jediné tabulce. V databázi však může být (a obvykle i je)
tabulek více. Hlavní význam databází spočívá právě ve větším počtu vzájemně provázaných
tabulek. Představme si nyní, že naše firma má několik oddělení, jejichž přehled je uveden
v následující tabulce:
Číslo oddělení Název oddělení
Obchodní
1
Účtárna
2
Reklamní
3
tab. 2
Vraťme se k naší jednoduché tabulce zaměstnanců. Pravděpodobně bychom chtěli vědět, do
kterého oddělení každý z těchto zaměstnanců patří. Musíme proto přidat další sloupec, který
bude obsahovat číslo oddělení:
Datum
Číslo
Příjmení Jméno
narození
Výše platu v Kč
oddělení
Novák
Adam
15.3.1956
6.000
1
Polesný František 25.11.1948
7.500
3
Drtina
Robert
1.4.1962
8.000
3
Veselá
Anna
4.5.1960
7.000
2
Smejkal Otakar
19.8.1959
8.000
1
tab. 3
Nebudeme se nyní zabývat způsobem, kterým bychom přidali nový sloupec do tabulky
v databázi a přejděme rovnou k výsledné podobě tabulky zaměstnanců - u každého
zaměstnance je uvedeno i číslo jeho oddělení.
Proč jsme použili čísla oddělení místo jejich názvů? Představme si, že by se z nějakých
důvodů název reklamního oddělení změnil na Marketing. Při způsobu, který jsme zvolili,
stačí opravit název oddělení na jediném místě v tabulce oddělení. Kdybychom měli u každého
zaměstnance uveden název oddělení, museli bychom změnit název oddělení jak v tabulce
oddělení, tak i v tabulce zaměstnanců. Museli bychom totiž provést změnu názvu oddělení
z Reklamní na Marketing u každého zaměstnance, který do tohoto oddělení patří. V našem
případě to jsou pouze dva - Polesný a Drtina, ale v reálné situaci to mohou desítky a stovky
záznamů. Z tohoto důvodu se pro popis vztahu mezi tabulkami používají tzv. identifikátory.
Jednoznačná identifikace pomocí identifikátorů řádků
Úkolem identifikátoru je jednoznačně identifikovat jeden řádek v tabulce. Identifikátor musí
být tedy v rámci jedné tabulky jedinečný - nesmí existovat dva řádky se stejnou hodnotou
identifikátoru.
48
Identifikátory ve formě čísel
Identifikátorem bývá většinou číslo, u kterého máme jistotu, že se nikdy nezmění. Například
u osob to bývá jejich rodné číslo, číslo pasu nebo číslo občanského průkazu.
Pokud bychom použili hodnotu, která se může měnit, museli bychom při každé její změně
nalézt v datech všechna místa, kde se tato hodnota použila jako identifikátor a nahradit ji
hodnotou novou. Je zřejmé, že to je činnost pracná a velice náchylná na zanesení chyb do
datové základny. Proto je vhodné volit jako identifikátory takové hodnoty, u kterých máme
relativní jistotu, že k jejich změně nedojde.
Důvodem pro použití čísel místo textových názvů bývá úspora místa a následně i zvýšení
rychlosti zpracování. Název oddělení totiž může být i Oddělení materiálně-technického
zásobování a ten zabere rozhodně více místa než číselné označení oddělení - např. 05.
Kdybychom používali názvy oddělení v tabulce zaměstnanců, byl by u každého zaměstnance
patřícího do tohoto oddělení tento dlouhý název. Podle počtu zaměstnanců v oddělení bychom
měli celý název uložen v databázi desetkrát nebo i stokrát. Rozdíl mezi místem zabraným
názvem a číslem se potom násobí počtem zaměstnanců v oddělení. V současné době přestává
být úspora místa kritickým faktorem, ale přesto není rozumné místem plýtvat. Rozhodně
můžeme použitím čísel místo názvů výrazně zrychlit pozdější zpracování našich dotazů. Při
vyhledávání všech zaměstnanců patřících do určitého oddělení nemusí být porovnávány velmi
dlouhé názvy, ale stačí porovnávat čísla. A to je výrazně rychlejší na jakémkoliv počítači.
Identifikace řádků podle více hodnot pomocí složených identifikátorů
V některých případech nestačí k jednoznačné identifikaci řádku pouze jedna hodnota.
Abychom přesně identifikovali daný řádek musíme znát hodnot více. V těchto případech
hovoříme o složených identifikátorech nebo o složených klíčích.
Příkladem existence složeného klíče je tabulka Výplaty obsahující výplaty všech
zaměstnanců za každý měsíc. Každý měsíc je vyplaceno tolik výplat, kolik je tou dobou
zaměstnanců ve firmě. Každý zaměstnanec dostává svoji výplatu každý měsíc po dobu trvání
pracovního poměru. Známe-li měsíc výplaty, musíme vybírat mezi více výplatami, které byly
tento měsíc vyplaceny. Známe-li zaměstnance, musíme opět vybírat tentokrát mezi více
měsíci, kdy výplatu dostal. Pouze v případě, že známe zaměstnance i měsíc výplaty, můžeme
jednoznačně určit, o kterou výplatu se jedná a případně její výši. Dvojice {rodné číslo; měsíc
výplaty} bude tvořit složený identifikátor v tabulce výplat.
Speciální případ identifikátoru řádku neboli primární klíč
Primární klíč je speciálním případem identifikátoru řádku. Kromě vlastnosti, že jednoznačně
identifikuje daný řádek, má zároveň minimální délku. Složeným identifikátorem řádku
z předchozího příkladu by mohla být i trojice {rodné číslo; měsíc; výše výplaty }, protože by
také jednoznačně určovala každý řádek. Přesto se nejedná o primární klíč, protože výši
výplaty můžeme vypustit a stále bude dvojice {rodné číslo; měsíc} jednoznačně identifikovat
každý řádek. Tato dvojice je zároveň i primárním klíčem v tabulce výplat, protože již
nemůžeme vypustit ani jeden z obou sloupců.
Použití primárního klíče cizí tabulky neboli cizí klíč
Primární klíče se používají v dalších tabulkách pro určení vazeb mezi tabulkami. U každé
výplaty v tabulce výplat musíme určit, kterému zaměstnanci byla vyplacena. V tabulce
zaměstnanců podobně určujeme, do kterého oddělení zaměstnanec patří. Jako odkaz
použijeme v tabulce výplat rodné číslo zaměstnance a v tabulce zaměstnanců číslo oddělení.
V obou případech se jedná o primární klíče v odkazovaných tabulkách, protože právě
u primárních klíčů máme jistotu, že jednoznačně identifikují jeden řádek v odkazované
tabulce. Použití primárního klíče cizí tabulky pro vytvoření odkazu se nazývá cizí klíč. Cizí
49
klíč jako zprostředkování vazby do jiné tabulky se bude vždy skládat ze stejných sloupců jako
primární klíč v odkazované tabulce. V případě, že bychom potřebovali vytvořit odkaz do
tabulky, ve které existuje složený primární klíč, museli bychom přidat tolik sloupců, kolik je
v odkazované tabulce sloupců v primárním klíči.
Udržení dat v konzistentním tvaru neboli datová integrita
Pod integritou nebo konzistencí dat rozumíme fakt, že data věrně zobrazují reálný stav, který
popisují. Základním předpokladem udržení dat v konzistentním tvaru je kvalitně navržená
datová základna. Nekonzistence mezi realitou a daty, které ji popisují, mohou dále vznikat
z těchto důvodů:
• Neaktuální data z důvodu nedostatečné aktualizace dat
Data se postupně stávají neaktuálními. Stává se tak v případě, že nedokážeme zajistit přidání
nových řádků do tabulek, opravu hodnot v existujících řádcích a rušení řádků o již
neexistujících objektech reálného světa. Přestože se jedná o triviální úkony, může udržování
datové základny v aktuálním stavu vyžadovat zejména u rozsáhlých aplikací nemalé úsilí, čas
a peníze.
• Aktuálnost odkazů neboli referenční integrita
Tím, že máme základní informace o zaměstnanci v jedné tabulce a údaje o výplatách
v tabulce další, musíme dbát na to, abychom při rušení zaměstnance vymazali nejen základní
informace o něm, ale i všechny jeho výplaty. Obecně řečeno, musíme vymazat všechny řádky
z ostatních tabulek, které se na tohoto zaměstnance odkazovaly. Pokud bychom zapomněli
vymazat některé odkazy, nebyli bychom později schopni určit, ke kterému zaměstnanci tyto
údaje patří, a datová základna by již nezobrazovala věrně stav reality.
Pomocné informace v databázi
Kromě vlastních dat, jako je jméno zaměstnance, výše jeho platu apod., jsou v databázi
uloženy i informace, které jsou pouze pomocné. Tyto informace slouží zejména pro zrychlení
zpracování našich požadavků.
Urychlení doby potřebné k získání informací pomocí indexů
Mezi nejvíce používané dodatečné informace patří tzv. indexy. S indexy se setkal každý z nás
- známe je například z veřejné knihovny. Místo toho, abychom museli procházet dlouhé
police a hledat požadovanou knížku, stačí prohledat malé kartičky v katalogu. Tyto kartičky
jsou seřazeny podle názvu knihy, což nám velmi ulehčuje vyhledávání. Jistě, podle názvu
mohou být seřazeny i knihy v policích, ale to má několik nevýhod:
• Manipulace s těžkými knihami je určitě náročnější než s malými kartičkami. Pokud
bychom chtěli přidat další knihu doprostřed police, museli bychom posunout všechny
následující knihy o jedno místo dál. Na konci police by už nemuselo být dostatečné
místo a my bychom museli přenášet poslední knihu do další police. Naproti tomu
vložení kartičky do katalogu na správné místo není nijak náročné. I v případě
nedostatku místa není problém přesunout několik posledních kartiček do jiné
přihrádky.
• Hlavní výhodou použití indexů však je, že jich můžeme vytvořit více pro jedna a ta
samá data. Můžeme mít jeden katalog seřazený podle názvů knih, druhý podle jmen
autorů a konečně třetí podle tematických okruhů. Při vyhledávání potom použijeme
ten, který se nejvíce hodí pro naše potřeby. Když budeme hledat všechny knihy
o zahradnictví, použijeme oborový katalog. Potřebujeme-li všechna díla napsaná
W. Shakespearem, použijeme katalog podle autorů.
Přestože jsme hovořili o knihovně a katalozích s papírovými kartičkami, platí uvedené
50
výhody a nevýhody i v případě použití počítačů a elektronických médií. I v počítači musí být
data umístěna na disku a jejich fyzické řazení do určitého pořadí a z toho vyplývající
přesouvání zabere nějaký čas. I když data vyhledává počítač, bude výsledek k dispozici dříve,
když bude „vědět", na kterém místě disku jsou uloženy všechny knihy s titulem začínajícím
na „T". V opačném případě by musel být postupně načítán řádek po řádku a kontrolován
název titulu. A konečně, každému je zřejmé, že ani v počítači nemohou být řádky v tabulce
seřazené najednou podle různých kritérií.
V současné chvíli není nutné, abychom znali přesnou strukturu indexů a způsob práce s nimi.
Stačí, když víme o jejich existenci a o tom, že mohou výrazně urychlit dobu potřebnou
k získání požadovaných informací.
Ostatní dodatečné informace
Kromě vlastních dat a indexů jsou v databázích uloženy informace popisující tato data.
V těchto „metadatech" (informacích o informacích) jsou zaznamenány názvy existujících
tabulek, počty a názvy jejich sloupců a další informace nutné k tomu, abychom mohli
s databází pracovat. Těmto pomocným informacím se někdy říká slovník dat.
Jazyk SQL
Přehled postupného vývoje
Vývoj databází a databázových systémů
Počátek databází a databázového zpracování dat můžeme nalézt v 60. letech, kdy firma IBM
vytvořila první databázový systém založený na hierarchickém modelu. Tento model
předpokládal hierarchické uspořádání dat, podobné jako organizační struktura organizace.
Datová základna byla tvořena stromy, které měly mezi nadřízeným a podřízeným uzlem vztah
l:n (jeden nadřízený uzel má jednoho nebo více následníků).
V 70. letech se začaly stromy v hierarchickém modelu propojovat a bylo možné popisovat
i složitější struktury než pouhé hierarchické vazby. Přesto se stále nedařilo popisovat všechna
data a vazby mezi nimi, jak se vyskytují v realitě. V polovině 70. let se proto začaly objevovat
zcela nové databázové systémy založené na relacích a relační algebře. 80. léta pak patří již
zcela relačním databázím a jazyku SQL, který se postupně stal jediným prostředkem pro práci
s tímto typem databázových systémů.
V současné době se vývoj ubírá směrem k objektovým databázím, jejichž hlavní výhoda
spočívá v možnosti uchovávání širokého spektra dat - od znakových, přes obrazová a zvuková
data až po video.
Zatím je možné pozorovat dva trendy v implementaci objektů v databázových systémech.
Jednak vznikají nové databázové systémy založené na objektových technologiích. Jejich
výhodou je logická čistota týkající se konzistentního objektového přístupu ke všem objektům
vyskytujících se v databázi. V druhém případě se tvůrci relačních databázových systémů snaží
implementovat objekty a objektový přístup do svých, již existujících produktů. V tomto
případě nemůže být zaručen striktně objektový přístup a k některým datům se stále používá
přístup relační. Nespornou výhodou je však zpětná kompatibilita těchto systémů s velkým
množstvím dříve napsaných programů a také jejich vyspělost díky dlouhé době jejich
používání.
Vývoj a standardizace jazyka SQL
V letech 1974 až 75 probíhal ve firmě IBM výzkum týkající se možnosti využití relačních
databází. Pro tento projekt bylo nutné vytvořit sadu příkazů, kterými by se relační databáze
51
ovládala. Vznikl tak jazyk SEQUEL (Structured English Query Language). Jak vypovídá jeho
název, bylo cílem tvůrců vytvořit jazyk, ve kterém by se příkazy tvořily syntakticky co
nejblíže běžnému jazyku (angličtině). Tento jazyk byl v upravené formě SE-QUEL/2 použit
v databázovém systému SYSTEM R v roce 1977.
Výhody relačního přístupu si uvědomily i další firmy. Tak v roce 1979 uvedla na trh firma
Relational Software, Inc. (nyní Oracle Corporation) svůj relační databázový systém s názvem
Oracle. Firma IBM nadále vylepšovala svůj systém a v roce 1981 uvedla nový systém
SQL/DS a později, v roce 1983, DB2. Vznikaly však i databázové systémy dalších firem např. Progress, Informix a SyBase.V těchto systémech se používaly různé verze jazyku
SEQUEL, který se přejmenoval na SQL (Structured Query Language).
Vzrůstající význam relačních databází si vyžádal nutnost standardizace jazyka pro jejich
používání. Americký standardizační institut (ANSI) původně zamýšlel vytvořit standard na
základě zcela nového jazyka RDL. V roce 1984 se však ukázalo, že jazyk se SQL stává
standardem de facto. Proto se nový standard založil na tomto jazyku a bývá označován jako
SQL86 podle roku 1986, ve kterém byl přijat.
V průběhu následujících let se ukázalo, že původní standard obsahuje některé nedostatky
a naopak v něm nejsou obsaženy některé důležité prvky týkající se zejména integrity dat.
Proto byl v roce 1992 přijat nový standard označovaný jako SQL-92 nebo pouze SQL2. Za
základní rozšíření je považováno přidání primárních klíčů a definice integritních omezení dat
v tabulkách. V současné době je stále ještě v návrhu verze standardu SQL3, která by měla
zejména reflektovat objektový přístup a objektové databáze obecně.
Obecným problémem standardů přijímaných de iure různými nadnárodními organizacemi je
zpoždění, které vznikne mezi potřebou standardu a jeho přijetím. Z důvodů zpětné
kompatibility dále jednotliví tvůrci databázových systémů ponechávají ve svých systémech
i prvky a konstrukce, které nejsou součástí standardu SQL. Naopak se ve standardu SQL
vyskytují požadavky, které žádný databázový systém nepodporuje. Proto se musíme smířit
s faktem, že existuje pouze určitá základní množina příkazů jazyka SQL a jejich syntaxe, se
kterou se můžeme setkat na všech databázových systémech. Mezi jednotlivými systémy se
však mohou vyskytovat odlišnosti, které velmi ztěžují možnost přenosu jednou napsaných
příkazů na jiný databázový systém.
Matematický základ pro SQL neboli relační model dat
Relační databázové systémy jsou založeny na relačním modelu dat a relační algebře. Přestože
tento model tvoří matematický základ pro jazyk SQL, není jeho naprosté pochopení nutným
předpokladem pro zadávání správných příkazů v jazyce SQL. [4]
Skupiny příkazů jazyka SQL a jejich zadávání
Příkazy jazyka SQL jsou členěny do několika skupin, z nichž je nejrozumnější se nejdříve
seznámit se skupinou příkazů pro manipulaci s daty. Manipulací rozumíme zejména
vyhledávání dat, ale také přidávání nových řádků do tabulek, aktualizaci hodnot v řádcích
nebo vymazání existujících řádků. Další skupiny příkazů umožňují vytváření a rušení tabulek,
indexů a jiných databázových objektů a nastavování parametrů databázového systému. Tyto
příkazy jsou určeny zejména pro zkušenější uživatele. [15]
Jazyk SQL byl navržen jako tzv. neprocedurální jazyk. V příkazech popisuje, „co" chceme
získat, a ne "jak" (postup, proceduru) to chceme získat. Liší se tak od většiny programovacích
jazyků, které jsou procedurální a ve kterých vždy popisujeme přesný postup toho, co se má
provést.
Při zadávání SQL příkazů není důležité na kolika řádcích jsou zadány. Je lhostejné, jestli se
jedná o jeden dlouhý řádek nebo více kratších řádků. Zvláště složitější příkazy je proto
vhodné rozdělit na více řádků, aby byly lépe čitelné.
52
Datový model, datová analýza, návrh datové základny
Počáteční analýza oblasti, popisované v databázovém prostředí
Návrh datové základny a její struktury by neměl být, zvláště u rozsáhlejších systémů,
živelným procesem postupně reagujícím na vzniklé požadavky. V současné době existují
historicky ověřené postupy a pravidla návrhu, která umožní a do jisté míry i zaručí vytvoření
kvalitní datové základny, která bude řádně zdokumentovaná, logicky konzistentní a bude
umožňovat relativně snadné zapracování skutečností vzniklých později.
Počáteční analýza oblasti, kterou chceme popsat v databázovém prostředí, předtím než
začneme vytvářet tabulky a dotazy pomocí jazyka SQL je velmi významná. Čím později totiž
odhalíme chyby v návrhu datové základny, tím větší námahu a tím i finanční prostředky
budeme muset obětovat na jejich nápravu.
Jednotlivé fáze návrhu
Jedním z možných přístupů je oddělení popisu oblasti našeho zájmu od vlastní implementace
na počítači. Způsob implementace může výrazně ovlivnit strukturu datové základny, ale
s oblastí, kterou datová základna popisuje, nemá nic společného. Rozdělíme tedy postup
návrhu datové základny na tři kroky, které si podrobně popíšeme.
Popis pomocí entit a vztahů neboli konceptuální fáze
V této fázi se snažíme popsat předmětnou oblast pomocí všech entit, které se v ní vyskytují,
a všech vztahů mezi těmito entitami. V žádném případě však nebereme v úvahu pozdější
způsob implementace a do jisté míry ani pozdější omezení technologického charakteru. Tím,
že neuvažujeme o pozdějším způsobu implementace v konkrétním databázovém systému,
můžeme věnovat veškerou energii na pochopení vlastního problému. Nakonec získáme
i obecně platný popis dané oblasti, který můžeme použít pro implementaci v odlišných
databázových systémech bez nutnosti opětovné analýzy.
Cíle konceptuálního modelu:
• vytvořit obraz reality ve formalizované podobě nezávislý na pozdějším způsobu
implementace;
• formalizovat požadavky uživatelů a dát návrhářům snadno pochopitelný prostředek
pro komunikaci s uživateli, kterému budou i uživatelé rozumět;
• vytvořit podklad pro návrh datové základny.
Entity-Relationship-Attribute diagramy
K formálnímu popisu reality slouží tzv. E-R diagramy z anglického Entity-Relationship (do
češtiny překládané jako diagramy entit a vztahů) nebo ERA diagramy z anglického EntityRelationship-Attribute. V ERA diagramech jsou navíc u každé entity uvedeny i její atributy.
Pro kreslení obou typů diagramů existuje velké množství notací, které se liší množstvím
značek vyjadřující vlastnosti popisované oblasti. Z praktických zkušeností vyplývá, že ani
nejvíce graficky bohaté notace nedokážou popsat všechny situace z reálného světa a je nutné
doplnit každý diagram slovním popisem. Velké množství značek používaných v diagramech
navíc činí tyto diagramy nepřehlednými a ztěžuje jejich pochopení. Z těchto důvodů se
omezíme pouze na základní notaci, se kterou se můžeme setkat s drobnými odlišnostmi téměř
ve všech produktech pro podporu návrhu datové základny.
53
Přehled prvků datových modelů:
• Entita
Významný prvek ve zkoumané oblasti. Entitou může být zaměstnanec, oddělení, výplata
apod. Entity se v diagramu vyznačují jako obdélníky s vepsaným názvem entity.
• Atribut
Vlastnost entity podstatná z hlediska zkoumané oblasti. Atributem entity Zaměstnanec bude
jeho jméno, výše platu apod. Atributy nemusíme v diagramu vyznačovat. Stačí, budou-li
uvedeny v textovém komentáři k tomuto diagramu.
• Vztah
Libovolný vztah, ve kterém mohou být dvě (nebo více) entit. Věta „Zaměstnanec pracuje
v oddělení" je vyjádřením vztahu pracuje v mezi entitami Zaměstnanec a Oddělení. Vztah
je vhodné pojmenovat, protože mezi dvěma entitami může existovat více různých vztahů.
Vztah je v diagramu vyznačen jako čára, která spojuje entity vystupující v tomto vztahu.
obr. 11
Tento velmi jednoduchý E-R diagram obsahuje dvě entity - Zaměstnanec a Oddělení.
Zároveň vyznačuje vztah mezi těmito entitami - pracovat v („Zaměstnanec pracuje
v oddělení").
Počet výskytů objektů entit neboli kardinalita vztahu
Všimněme si „vidličky" na straně zaměstnance ve vztahu s oddělením. Jejím smyslem je
vyjádřit tzv. kardinalitu vztahu zaměstnance a oddělení. Pod kardinalitou rozumíme počet
výskytů objektů obou entit, které se vztahu účastní. Víme, že v jednom oddělení pracuje
obvykle více zaměstnanců. Naproti tomu jeden zaměstnanec pracuje v jeden okamžik pouze
v jednom oddělení. Jedná se o příklad vztahu n:l (n zaměstnanců pracuje v jednom oddělení)
nebo opačně l:n (v jednom oddělení pracuje n zaměstnanců).
Možné typy kardinalit vztahů:
• 1:1
Vztah, ve kterém na obou stranách vystupuje pouze jeden objekt dané entity. Tyto vztahy se
v realitě vyskytují pouze zřídka a jejich existence v diagramu bývá někdy způsobena chybou
v popisu reality. Příkladem vztahu l:l může být vztah manželé mezi entitou Muž a entitou
Žena (v případě monogamní společnosti) nebo vztah třídní učitel mezi entitami Učitel
a Třída.
• 1:n
Na jedné straně je jediný objekt, který je ve vztahu s jedním nebo více objekty na straně
druhé. Jedná se typ vztahu, který se vyskytuje velmi často. Kromě již uvedeného vztahu
zaměstnance a oddělení to je například vztah nadřízený - podřízený, zaměstnanec - výplata,
ale také třída - žák.
• m:n
specifickým typem vztahu jsou vztahy, ve kterých vystupuje více objektů na obou stranách.
Ve vztahu zaměstnanec - úkol může více zaměstnanců řešit jeden úkol a zároveň může jeden
zaměstnanec zároveň řešit více úkolů.
obr. 12
54
Povinnost a volitelnost existence vztahu neboli parcialita vztahu
Kromě kardinality vztahu můžeme ještě rozlišovat povinnost a volitelnost jeho existence:
• je nutné, aby každý zaměstnanec byl zařazen do určitého oddělení? Nebo může existovat
zaměstnanec, který v současné době nepatří do žádného oddělení? Musí mít každý muž
manželku a žena manžela? Jak vidíme, mohou se vyskytovat typy vztahů, které nemusí
existovat u všech objektů dané entity - existují například svobodní muži i ženy. Parcialitu
nebo volitelnost vztahu můžeme také vyjadřovat v diagramech:
Prázdné kolečko vyjadřuje volitelnost na straně entity, která nemusí existovat. Parcialita ve
vztahu pracuje v znázorňuje fakt, že ne všichni zaměstnanci mají přidělené oddělení, ve
kterém by pracovali.
obr. 13
U vztahu l:n se většinou parcialita nevyjadřuje, protože se na straně n automaticky
předpokládá výskyt 0 až n objektů. Záleží pouze na konvencích, které si při návrhu datové
základny zvolíme, jestli budeme vztah l:n používat pouze pro výskyt l až n objektů a možnost
neexistence vztahu budeme vyjadřovat pomocí parciality.
Zjednodušení vztahů m:n
Vztah m:n je z hlediska další práce velmi komplexní a je nutné pokusit se o jeho
zjednodušení. Neděláme tak pouze kvůli jeho implementaci na další, logické úrovni návrhu,
ale i pro případ, že v tomto vztahu je „schována" další entita, která zatím naší pozornosti
unikla. Součástí této entity mohou být i atributy, o kterých jsme tušili, že existují, ale nevěděli
jsme, ke které entitě je přiřadit.
Zjednodušením (dekompozicí) vztahu m:n rozumíme vytvoření nové, tzv. vazební entity,
která bude mít vztahy typu n:l na obě původní entity vztahu m:n:
Nově vzniklá entita Řešitel úkolu vyjadřuje fakt, že zaměstnanec může být najednou
řešitelem více úkolů a jeden úkol může být řešen najednou více řešiteli.
Součástí této entity mohou být atributy, které nelze přiřadit žádné z entit Zaměstnanec
a Úkol. Příkladem je atribut popisující hodnocení zaměstnance za odvedenou práci na daném
úkolu. Protože zaměstnanec může pracovat na více úkolech a být hodnocen za každý jinak,
nemůže být tento atribut umístěn do entity Zaměstnanec. Zároveň nemůže být umístěn ani do
entity Úkol, protože na úkolu může pracovat více zaměstnanců. Jediným správným umístěním
atributu Hodnocení je entita Řešitel úkolu, protože se vztahuje vždy k dvojici
{zaměstnanec; úkol}.
obr. 14
55
Zvláštní typy vztahů - generalizace a specializace
Zvláštním typem vztahů mezi entitami je tzv. generalizace a specializace. Generalizací
rozumíme zobecnění některých vlastností různých entit, pomocí kterého dojde k jejich
splynutí v entitu jednu. Pomineme-li jistě důležité odlišnosti mezi koněm a oslem, můžeme
generalizovat, že se jedná o lichokopytníky. Ještě výše na pomyslné hierarchii můžeme
hovořit o savcích, dále o teplokrevných a úplně obecně o živočiších. Opačným postupem
bychom získávali více a více specializované živočichy a hovoříme tedy o specializaci.
Podobné hierarchické uspořádání můžeme nalézt i v jiných oblastech - osoba může být
zaměstnanec, důchodce nebo student. Zaměstnanec může být, v případě školy, učitel/ka,
sekretář/ka, studijní referent/ka nebo i uklízeč/ka. S problémy se setkáme v případě, že
chceme pracovat s entitou zaměstnanec - každý zaměstnanec dostává výplatu, může dostat
výpověď apod. - ale někdy potřebujeme vyjádřit vztah pouze s určitou specializací - např.
pouze učitel může být třídním učitelem v některé třídě. Jeden z možných způsobů znázornění
specializace v rámci entity zaměstnanec vidíme na následujícím diagramu:
obr. 15
Popis pomocí relačního schématu neboli tzv. logická fáze
Pro popis dat v tzv. logické fázi se v relačních databázích používá tzv. relační schéma.
Relační schéma obsahuje tabulky včetně všech jejich sloupců. Ve schématu jsou vyznačeny
primární klíče v tabulkách a dále i cizí klíče jako odkaz na primární klíč v jiné tabulce. Tento
odkaz je většinou vyznačen jako čára spojující sloupce ve dvou tabulkách. Součástí relačních
schémat mohou být i popisy integritních omezení tabulek a sloupců.
Pravidla převodu z konceptuálního modelu
Převod konceptuálního modelu dat na relační schéma lze téměř automatizovat pomocí
následujících pravidel:
A) Každá entita v konceptuálním modelu se stává samostatnou tabulkou.
B) Identifikátor entity se stává primárním klíčem.
C) Je-li součástí vztahu jeden nebo více atributů, je nutné vytvořit novou (vazební)
entitu podobně jako u vztahu m:n a z ní vytvořit tabulku. V některých případech
nemusíme u vztahu l:n tuto entitu vytvářet a všechny atributy lze přesunout do entity
na straně n v tomto vztahu.
D) U každého vztahu zvolíme tabulku, která bude obsahovat cizí klíč, jako odkaz do
druhé tabulky. Pro volbu tabulky použijeme tato pravidla:
1. Je-li vztah typu l:n, bude cizí klíč přidán do tabulky na straně n.
2. Jedná-li se o parciální vztah 1:1, bude cizí klíč přidán do tabulky, která se
vyskytuje ve vztahu nepovinně.
3. Jedná-li se o neparciální vztah 1:1, volíme tabulku, která je věcně
„podřízená" (například ve vztahu zaměstnanec - učitel to bude učitel, protože
je specializovanou formou zaměstnance).
4. Vztahy typu m:n nejprve dekomponujeme na dva vztahy l:n a potom
postupujeme podle pravidla pro tento typ vztahů.
E) Vyskytuje-li se v konceptuálním modelu specializace, máme některou z těchto
možností:
1. Vytvoříme jednu tabulku (například Zaměstnanci), která bude obsahovat
56
sloupce pro všechny atributy, včetně těch, které se vyskytují pouze
u specializovaných entit (například učitelů). Na každém řádku zůstanou
některé sloupce nevyplněny (budou obsahovat hodnotu NULL). Tento způsob
je nejméně náročný z hlediska tvorby dotazů, ale je nehospodárný místem,
které budou data zabírat, a zpracování dotazů nad takto vytvořenými tabulkami
bude trvat déle.
2. Vytvoříme zvláštní tabulku pro každou specializovanou entitu. Budeme tedy
mít tabulky Učitelé, Sekretářky, Studijní_Referentky atd. Nebudeme sice
plýtvat místem, ale bude nám činit potíže práce se všemi zaměstnanci najednou
- pouhé vypsání jmenného seznamu, zvýšení platu apod. Velice snadno se
může stát, že budeme nuceni přidat další tabulku (například Externisté)
a zapomeneme opravit některý z již vytvořených dotazů pracujících se všemi
zaměstnanci.
3. Vytvoříme tabulku Zaměstnanci, která bude obsahovat sloupce společné
pro všechny typy zaměstnanců. Pro každou specializovanou entitu pak
vytvoříme tabulku další, která bude obsahovat už jen sloupce specifické pro
tuto entitu. Tento způsob spojuje výhody obou předchozích. Musíme však
zajistit referenční integritu dat mezi specializovanými tabulkami a tabulkou
hlavní.
Následuje ukázka jednoduchého relačního schématu popisujícího tři tabulky - Zaměstnanci,
Výplaty a Oddělení - a jejich vzájemné vztahy.
obr. 16
Výběr databázového systému neboli implementační fáze
V implementační fázi vybíráme konkrétní databázový systém, ve kterém vytvoříme datovou
základnu. Po jeho výběru můžeme začít využívat i různých nestandardních funkcí zvoleného
prostředí. Jejich použití bychom však měli důkladně zvážit, zejména kvůli možnému
pozdějšímu přechodu na jiný databázový systém. Z hlediska jazyka SQL je nutné na této
úrovni vzít v úvahu i možné dílčí odlišnosti v příkazech, zejména ve skupině příkazů pro
definici dat (DDL).
Popis struktury všech objektů uložených v databázi neboli slovník dat
Slovník dat (z anglického „data dictionary") popisuje strukturu všech objektů uložených
v databázi. Jsou zde uloženy informace o existujících tabulkách a jejich sloupcích, popis
omezení pro data v tabulkách, popis definovaných indexů a další charakteristiky dat
používané pro zrychlení zpracovávání příkazů.
Jednou z podmínek relačních databázových systémů je, že i tyto informace jsou uloženy
v relačních tabulkách a jsou dosažitelné pomocí jazyka SQL. V každém databázovém systému
se proto můžeme setkat s různým počtem tzv. systémových tabulek. Z našeho hlediska se
jedná o normální tabulky a můžeme zjistit jejich obsah pomocí příkazu SELECT. Názvy
tabulek začínají ve většině případů předponou SYS. Například názvy a další charakteristiky
tabulek bývají uloženy v tabulce s názvem SYS_TABLES. Pomocí příkazu SELECT zjistíme
veškeré informace o existujících tabulkách v databázi: SELECT * FROM sys_tables
Podobně existují i tabulky obsahující názvy a typy datových sloupců, názvy uživatelů atd.
57
Všechny tyto informace můžeme zjistit za předpokladu, že známe názvy systémových
tabulek.
Systémové tabulky sice můžeme číst, ale bývá zakázáno v nich údaje měnit. Databázový
systém nám ani nedovolí provést příkaz INSERT, DELETE nebo UPDATE s těmito
tabulkami. Pokud se nějakým způsobem poruší data uložená v těchto tabulkách, ztratíme
celou databázi a všechna v ní uložená data.
Názvy systémových tabulek a jejich popis jsou součástí dokumentace ke každému
databázovému prostředí.
58
6. Objektové modelování
Tato metodika má za úkol zachytit statické vztahy úlohy a popsat vytvářený systém jako síť
tříd svázaných asociacemi.
Nejdůležitější je vytvořit na začátku celého modelování vyšší úroveň tříd a jejich asociací. Je
výhodné začít celé modelování objekty, protože statická struktura se lépe navrhuje, méně
závisí na implementačních detailech, je stabilnější a snáze se jí porozumí. [10]
Nejprve se určí třídy a asociace, protože ty určují celkovou strukturu a přístup k problému.
Pak se přidají atributy. Třídy se zkombinují do hierarchie. Pokusy začít hierarchii shora,
tj. bez nejnižších tříd a jejich atributů, často vedou k nesprávné apriorní představě. Operace
přidáváme později, jako výsledek FM (funkčního modelu) a DM (dynamického modelu).
Operace modifikují objekty. Lze je tedy určit, až pochopíme dynamiku a funkce.
Je dobré vše dát na papír (přesněji do nějakého CASE), aby se neztratily důležité podrobnosti,
a to nejen grafické zápisy modelů (výkresy), ale textově zachycovat i popisy a průběžně
dokumentovat i postup. [13]
Je rozumné postupovat v následujících krocích:
1. určení základních prvků - jednotlivých tříd a objektů,
2. postupná tvorba slovníku dat,
3. rozpoznání závislostí mezi třídami neboli asociací,
4. identifikace vlastností neboli atributů objektů,
5. tvorba celkového hierarchického rozvrstvení tříd objektů,
6. ověřování smysluplnosti modelu,
7. postupné inovování a iterace modelu,
8. roztřízení a seskupení tříd do logických celků tzv. modulů.
Přes toto doporučení nebývá tento postup v reálných případech striktně zachováván, hlavním
důvodem porušování jsou iterace. Modifikace postupu málokdy bývají toho charakteru, aby se
zaměnilo pořadí jednotlivých kroků, spíše se jedná o návraty a opakování již dříve
provedených kroků. [12]
obr. 17
Určení základních prvků - jednotlivých tříd a objektů
Třídy se určují na základě znalostí pojmového modelu, rozborem zadání, znalostí reality,
zkušeností, popřípadě rozborem textu zadání (podstatná jména jsou kandidáti na třídy).
Nejdříve určíme širší okruh a ten pak prověřujeme a omezujeme.
Vylučují se:
-Redundantní třídy - vyjadřující stejné informace. Použije se to jméno třídy, které je
popisnější.
-Irelevantní třídy - které mají málo nebo nic společného s problémem.
-Vágní třídy - příliš široké nebo neurčité. Někdy je vágnost pouze v pojmenování,
stačí zvolit vhodné jméno.
-Atributy - některá použitá jména jsou spíše atributy než třídy.
-Operace - jestliže podstatné jméno popisuje operaci, která je použita na objekty, ale
není iniciátorem manipulace, není to třída.
-Role - jméno třídy má vystihovat podstatné vlastnosti a ne roli („třída" ale je „role"
59
ve smyslu sociopsychologie). Jedna fyzická entita může odpovídat více třídám, např.
„Osoba" a „Zaměstnanec".
-Stavy - některá podstatná jména označují stavy objektů a ne názvy tříd. Tak třeba
„Nemocný" není zvláštní třída, ale stav třídy „Zaměstnanec".
-Implementační konstanty - co se vymyká z reálného světa nemá co dělat
v analytickém modelu (později se možná použije).
Postupná tvorba slovníku dat
Slovník dat zahájíme jednotlivými popisy tříd. Isolovaná slova nejsou jednoznačná, je
zapotřebí je jasně vysvětlit. U tříd popisujeme jejich odpovědnost, jejich rozsah, včetně
předpokládaných restrikcí (omezení) členů nebo jejich užití.
Slovník dat budeme průběžně doplňovat popisem asociací a dalších entit. Programové
prostředky pro podporu projekce (CASE) většinou usnadňují tvorbu slovníků tak, že
jednotlivé popisy různých entit (tříd, asociací ap.) jsou schopny organizovat do různých
výpisů. Musíme pouze dbát na to, abychom soustavně všechny entity popisovali. Při různých
prověrkách pak vytvoříme pracovní soubor s požadovaným slovníkem.
Slovníky termínů a jejich popisy mají tři důležité funkce:
-Umožňují se vrátit k problému i po letech a rychle porozumět řešení.
-Omezují posun významu termínu, občas se stane, že význam nějakého termínu je na
začátku práce jiný než na konci.
-Umožní pochopit skutečný obsah termínu.
Rozpoznání závislostí mezi třídami neboli asociací
Závislost mezi dvěma nebo více třídami je asociace. Reference z třídy na třídu může být
asociace (tj. asociace může označovat, že objekty jedné třídy volají metody objektů druhé
třídy). To, že objekty jedné třídy jsou částmi objektů druhé třídy, je asociace (agregace).
Atributy nemají ukazovat na třídy.
Asociace se většinou vyjadřují slovesy. Týkají se umístění (umístěn v, další, část něčeho),
přímých akcí (A řídí B), komunikace (mluví s), vlastnictví nebo splnění nějaké podmínky
(pracuje pro, ženatý s). Některé asociace závisí na znalostech reálného světa, musí být
verifikovány zadavatelem.
Můžeme pracovat tak, že ze sloves sestavíme seznam kandidátů na asociace a pak jej
probíráme a vylučujeme.
Jako agregace určujeme jen ty asociace, kde je vztah ,je částí" zcela jasný, nebo kde to
vyžadujeme. Tak jako tak se o agregacích definitivně rozhodne až v designu.
Vylučují se:
-Asociace mezi vyloučenými třídami.
-Irelevantní nebo implementační asociace - asociace mířící vně problémové oblasti
nebo implementační konstrukty.
-Akce - asociace popisují (statickou) strukturu problémové oblasti, ne události. Např.
„přijetí karty automatem" není asociace. Někdy ale popis akce vlastně popisuje
asociaci.
-Ternární asociace - mnoho vícenásobných asociací může být rozloženo na
jednoduché.
-Odvozené asociace - rozumíme tím odvozené z jiných asociací. Asociací také není
to, co vyplývá ze vztahu mezi atributy. Některé odvozené asociace jsou v reálném
60
světě důležité, vyjadřujeme je graficky odlišně (tečkovaně).
Upřesňují se:
-Špatně pojmenované asociace - např. existence asociace je dána popisem akce,
např. „počítač udržuje účet" přejmenujeme na „počítač obsahuje účet".
-Jména rolí - přidej jména rolí, kde to je vhodné. Jestliže má třída jen jednu asociaci,
pak může jméno role chybět. Jestliže je mezi třídami více asociací, je nutno je označit
jmény rolí.
Role asociací mají dva účely. Slouží jednak k lepšímu pochopení grafické
representace modelu, jednak ke kontrole. Jestliže totiž roli výstižně pojmenujeme
podle reality, pak z porovnání role a třídy můžeme posoudit, zdali je asociace
napojena na správnou třídu.
-Kvalifikovaná asociace. Někdy je asociace jednoznačná jen v nějakém kontextu.
-Kvantifikace. Během první iterace není třeba věnovat příliš námahy na určení
kvantifikací, během analýzy se kvantifikace mění.
-Chybějící asociace. Doplní se z porozumění problému. Každá třída musí být nějak
svázána (statickým) vztahem.
-Ovlivnění tříd. Soubory různých asociací na jednu třídu mohou znamenat, že se
jedná o více tříd.
Identifikace vlastností neboli atributů objektů
Atributy jsou vlastnosti individuí (jméno, váha, barva). Nejsou to objekty (jestli to jsou
objekty, pak se vážou asociací).
Identifikují se přídavnými jmény (přívlastky) u podstatných jmen.
Vylučují se:
-Objekty. Jestliže je důležitější nezávislá existence než hodnota, pak to je objekt
a ne atribut.
-Linky. Dají se spíše vyjádřit asociací.
-Kvalifikátory. Je-li hodnota atributu závislá na dílčím kontextu, je to kvalifikátor.
-Jména. Jména jsou většinou spíše kvalifikátory než atributy objektu.
-Identifikace. Normálně jsou atributy identifikovány svým objektem, není třeba
explicitně uvádět identifikaci v analýze.
-Linkové atributy. Jestliže vlastnost závisí na spojení (linku), pak to je atribut linku
a ne příslušného objektu. Linkové atributy obvykle řeší situaci M:N. Jsou skrytější
v relacích l :N a vyskytují se i u l: l.
-Vnitřní hodnoty. Jestliže je atribut zvenčí neviditelný, pak nepatří do analýzy.
-Jemné detaily, které neovlivňují operace.
-Rozporné atributy. Atribut, který je velmi odlišný od ostatních, může ukazovat, že
třídu je zapotřebí rozložit ve dvě různé. Třída má být jednoduchá a koherentní
(kompaktní). Třídy, které jsou nezaměřené, tj. nemají jasnou odpovědnost, vedou
k předčasným a zbytečným omezením implementace.
-Samozřejmé atributy. Doporučuje se mít u atributů (podobně i u operací) dvě
úrovně zápisu. Vyšší úroveň je do grafické representace třídy, nižší úroveň je do
popisu třídy. Do grafické representace třídy (objeví se jako atribut ve výkresu) se
zapisují atributy, které nějakým způsobem ovlivňují strukturu modelu nebo je
zapotřebí z jiných důvodů, aby byly viditelné. Samozřejmé atributy zapisujeme do
popisu třídy, odkud si je vyzvedne implementátor.
61
Tvorba celkového hierarchického rozvrstvení tříd objektů
Generalizace: Z objektů se odvozují třídy, z tříd nadtřídy. Podobné atributy, asociace
a operace vedou ke generalizaci. Rozumí se ovšem podobnost z hlediska aplikace. Jestliže se
tatáž asociace vyskytuje vícekrát, pokusíme se generalizovat. Mnohdy je generalizace
vyjádřena již ve slovníku problémové oblasti. Symetrie dědění může ukázat chybějící třídy.
Někdy je třeba třídy předefinovat, aby se daly úspěšně generalizovat - ale pozor na falešnou
generalizaci.
Specializace: Z tříd se odvozují podtřídy. Často je možnost specializace dána adjektivy.
Dáváme si ale pozor na přílišné zjemňování. Někdy je třeba třídy předefinovat, aby se mohly
zařadit do hierarchie. Atributy a asociace, které jsou přiřazeny určité třídě hierarchie dědění,
vždy mohou být přiřazeny obecnější třídě (je nutné určité přizpůsobení). Zase může symetrie
vyjasnit úlohu atributů rozlišujících třídy.
Násobné dědění: Realizuje se jím sdílení vlastností. Ne všechny implementační prostředky
připouštějí násobné dědění - lze nahradit delegací.
Ověřování smysluplnosti modelu
Procházíme cesty modelem a ověřujeme si, zda výsledky jsou smysluplné.
Jsou zde smysluplné dotazy, na které systém nedokáže odpovědět? Jestliže něco
jednoduchého v reálném světě se v modelu dělá složitě, pak zde něco chybí.
Postupné inovování a iterace modelu
Navrhnout dobře model hned na první pokus se povede zřídka. Celý postup návrhu je vlastně
stálá iterace - různé části modelu jsou často v různých stupních dohotovení. Zjistí-li se nějaký
nedostatek, je nutno se vrátit do předchozích kroků a napravit to. Některá upřesnění vyplynou
z dynamického nebo funkčního modelu.
Příznaky nesprávných nebo chybějících tříd:
-asymetrie v asociaci nebo generalizaci - přidání nové třídy podle analogie,
-nesoulad atributů a operací ve třídě - rozdělit třídu tak, aby části byly koherentní,
-těžkosti v generalizaci - jedna třída může hrát dvě role - rozdělit,
-operace nemá jasnou cílovou třídu - doplnit,
-duplikace asociací s tímtéž jménem a účelem. Generalizovat třídy v nadtřídu,
-role podstatně určují sémantiku třídy - mohou určovat samostatné třídy. Často to
znamená změnit asociaci v třídu.
-špatně umístěné asociace -jména rolí jsou příliš široká nebo úzká pro tuto třídu. Lze
posunout asociaci v hierarchii, případně přidat třídu (podtřídu, nadtřídu) do hierarchie.
-zbytečné třídy - chybí atributy, operace a asociace v třídě - je vůbec třída zapotřebí?
-chybějící asociace - chybí přístupová cesta pro operace
-zbytečné asociace - redundantní informace v asociaci. Buď asociaci vyhodit nebo
označit jako odvozenou. Zbytečnou asociaci identifikuje to, že chybí operace, které by
používaly cestu asociace. Když nejsou nutné operace, pak žádná cesta není nutná
(rozhodnutí je definitivní až po určení operací),
-špatně umístěný atribut - pokud je nutné přistupovat k jiné třídě jen pro jednu
hodnotu, může se jednat o špatně umístěný atribut. Zvlášť se to týká kvantifikovaných
asociací.
62
Roztřízení a seskupení tříd do logických celků tzv. modulů
Moduly vytváříme dle logiky a dle frekvence vazeb - s maximalizací soudržnosti
a minimalizací spřaženosti. [11]
Třídy do modulů seskupujeme v těchto případech:
-U modelů střední velikosti když je již analytický model ustálen, to znamená, když
nám již iterace nepřinášejí žádné změny. Třídy seskupujeme podle logických vazeb
s přihlédnutím na frekvence zpráv mezi nimi. Moduly jsou východiskem pro
systémový design, můžeme ale očekávat, že se v něm objeví další kritéria, která
mohou rozčlenění tříd změnit.
-U větších modelů tehdy, když model začíná být nepřehledný. Pokusíme se vytvořit
moduly a dále se v analýze zabývat hlavně vazbami mezi moduly.
Ve výše uvedeném druhém případě mohou nastat tyto možnosti:
-Seskupení do modulů je důvěryhodné, moduly jsou dosti logicky nezávislé
a je zřetelné, že komunikace uvnitř modulů je intensivní. Pak dokončíme
analýzu vazeb mezi moduly. Výsledkem analýzy jsou popisy protokolů mezi
moduly. Dále nepokračujeme systémovým designem, ale analýzou pro každý
modul zvlášť. Za zadání považujeme popis protokolů mezi moduly. Tímto
způsobem musíme zpracovávat příliš rozsáhlé úlohy.
-Jestliže hranice mezi moduly nejsou dosti ostré, nerozpracováváme je úplně
samostatně, ale přejdeme k nerovnoměrnému zpracování. Věnujeme se jedné
části (kandidátu na modul), pak přejdeme na sousední část, do které
promítneme změny ve vazbách. Tak projdeme celý model.
Většinu úloh lze apriori rozdělit na tři subsystémy: oblast rozhraní, věcnou oblast a oblast
datové základny.
Oblast rozhraní je odpovědná za komunikaci s uživateli. Konstrukce této oblasti je dobře
pokryta různými výkonnými technologiemi, takže její podrobná analýza je většinou neúčelná.
Většinou do věcné oblasti řadíme zajištění komunikace s živými lidmi, komunikaci
s technickými zařízeními (čidly) řadíme do datové základny nebo pro ni vytvoříme
samostatnou oblast.
Věcná oblast je vlastním předmětem analýzy, její vstupy a výstupy tvoří zadání pro analýzu.
V některých zvláštních případech lze v úloze vytypovat více věcných oblastí - v podstatě to
znamená existenci více úzce propojených systémů.
Oblast datové základny má odpovědnost za zajištění přístupu k datům. V úlohách
hybridního charakteru, kdy se návrh provádí objektově a data jsou uložena v relační databázi,
nabývá určité důležitosti. Při použití objektové databáze je skoro nulová.
Společná oblast je na pomezí mezi věcnou oblastí a oblastí datové základny. Jako společnou
oblast můžeme určit:
-Skupinu modulů, u kterých předpokládáme, že je bude možno využít u později
vytvářených systémů. Takové moduly navrhujeme obecněji, než potřebuje právě
vytvářený systém.
-Skupinu modulů, které byly vytvořeny v rámci jiného systému, u kterých se ale
předpokládá obecné využití ve více systémech.
-Systémy nebo jejich části, které nebyly vytvořeny pro použití právě
rozpracovávaným systémem.
Rozhraní mezi moduly. Rozhraní mezi moduly může být popisováno protokolem jako celek,
ve skutečnosti však je tvořeno nezávislými spoji mezi třídami těchto modulů.
63
obr. 18
Můžeme však použít i jiné přístupy, kdy je modul representován třídou. Můžeme použít dva
způsoby:
-Modul je representován jedinou třídou, každá komunikace s tímto modulem musí
projít touto třídou. (Tento přístup se používá u velmi velkých systémů, kde
representační třídy modulů vznikly analýzou prvé úrovně a moduly samotné vznikly
analýzou druhé úrovně.)
-Pro spojení s určitým modulem je určena zvláštní třída.
obr. 19
Representace modulu třídou vede k pružnějším systémům, ovšem na úkor efektivity, protože
zprávy procházejí více mezistanicemi.
64
7. Dynamické modelování
Toto modelování popisuje chování objektů a identifikuje a rozlišuje události a vytváří stavové
diagramy. Tento model nemusí být použit u všech typů úloh. Zcela určitě bude použit
u interakčních aplikací, nebude použit u úloh databázového charakteru. [23]
Postup dynamického modelování:
1. popis chování systému - tvorba slovních scénářů,
2. popis vnější interakce systému - tvorba grafických scénářů,
3. soustředění událostí do jednoho diagramu - tvorba mapy událostí,
4. kontrola konzistence grafických scénářů pomocí mapy událostí,
5. tvorba stavových diagramů pro jednotlivé třídy, určení chování objektů,
6. kontrola konsistence událostí a stavových diagramů,
7. postupné iterování při návrhu dynamického modelu.
Určit a navrhnout dynamické chování vytvářeného systému je podstatně obtížnější úloha, než
navrhnout statické vztahy (v objektovém modelu). Proto dynamické modelování není jen
vytvoření určitého modelu, ale je to vlastní dynamická analýza, která používá několik
podmodelů a k jejich vytvoření má vlastní postupy. [20]
Existují tyto možnosti:
-dynamický model nevytvářet,
-dynamický modem vytvořit jednoetapovým postupem,
-dynamický modem vytvořit dvouetapovým postupem.
Dynamický model nevytváříme
Dynamický model se nepoužije, jestliže chování objektů je přímočaré, tj. na stejný impuls je
vždy stejná reakce. Obvykle se jedná o úlohy s otevřeným cyklem, tj. systém slouží jen
k tomu, aby zpřístupnil informace - veškerá rozhodování jsou na uživateli systému.
Dynamický model tvoříme jednoetapovým postupem
Při použití jednoetapového postupu se celý systém popisuje jedním stavovým diagramem
(který je samozřejmě možno hierarchicky členit na poddiagramy). Zvláštností tohoto postupu
je nezávislost stavů a tříd - v tom smyslu, že jednomu stavu může odpovídat jedna třída,
skupině stavů může odpovídat jedna třída, ale jednomu stavu může odpovídat i několik tříd.
Jednoetapový postup se používá tehdy, jestliže chování systému má prvořadou důležitost
a systém není příliš rozsáhlý (respektive jeho datový obsah není příliš rozsáhlý) - typicky
u systémů v reálném čase.
Dynamický model tvoříme dvouetapovým postupem
Platí, že datový obsah i dynamické chování jsou v podstatě stejně důležité. Takové systémy
jsou obvykle příliš velké, než aby jednoetapový postup byl pohodlný. Navíc je vhodné
určitým způsobem preferovat statickou složku systému - a to proto, že méně podléhá změnám.
Je rozumné definovat odpovědnost tříd na základě statického modelu a modifikovat ji podle
dynamického modelu jen minimálně.
U systémů středního a velkého rozsahu je prakticky nemožné vytvořit dynamický model
celého systém jako celku.
Proto se úkol rozkládá do dvou vrstev (fází):
-meziobjektová dynamika celého systému,
-dynamika jednotlivých objektů.
65
Dynamika celého systému - meziobjektová fáze
Popis chování systému - tvorba slovních scénářů
Nejdříve se vytvoří slovní scénáře popisující chování systému jako celku. Tyto scénáře
převezmeme z modelu jednání nebo vytvoříme speciálně pro tento účel. Účelem je rozlišit
a identifikovat vnější události, tj. impulsy přicházející z vnějšku systému, a reakce systému na
ně (odpovědi systému). V objektovém modelu se později budou tyto události chápat jako
aktivity tříd, které zajišťují styk s vnějškem.
Zásady tvorby slovních scénářů
Při tvorbě modelu jednání se obvykle směřuje k co nejúplnějšímu vyjádření funkčnosti
systému pomocí typů jednání, jejich abstrakcí a extenzí. To vše se vyjadřuje ve slovních
scénářích. I v grafech objektové interakce jsou možnosti pro zachycení opakování a alternativ
- čili lze objektovou interakci naprogramovat.
Máme zejména za úkol rozlišit a evidovat všechny události mezi objekty.
Obvykle připravujeme scénáře v tomto pořadí:
1. Normální případy, bez chyb a překlepů obsluhy (uživatele) systému.
2. Speciální případy včetně chybových (vynechání údajů, údaje navíc, hraniční
hodnoty). Pro většinu interakčních (a nejen interakčních) aplikací je obhospodařování
chyb nejobtížnější prací.
3. Překryvné požadavky nad základní posloupností, jako je help nebo dotazy na stav
zpracování.
Slovní scénář je heslovitě vyjádřená posloupnost událostí.
Událost je to, že se vymění informace mezi objektem systému a vnějším činitelem, jako je
například uživatel, senzor nebo jiný systém (prvek systému). Vyměňované informace jsou
parametry událostí.
Určení vnějších signálů a podmětů neboli vnějších událostí
Vnější události jsou signály, podněty od uživatele nebo vnějšího zařízení. Použijeme scénář
(z modelu jednání), abychom je všechny identifikovali. Vnitřní (výpočetní) kroky nejsou
události, události jsou rozhodnutí, která závisí na vnějším světě. Nalézáme normální události,
nezapomínáme ovšem na chybové a výběrové.
Každé události se musí přidělit dvě objektové třídy, odesilatel a příjemce, tatáž událost je
u jednoho výstupní, u druhého vstupní. Je možné že odesilatel i příjemce je tentýž objekt.
Specifikace systémového rozhraní
Interakce mají dvě stránky - logiku a interface. Analýza se zabývá logikou. Pro tutéž logiku
mohou být různá rozhraní (příkazový řádek, soubor, tlačítko na panelu).
Popis vnější interakce systému - tvorba grafických scénářů
Slovní scénáře přepíšeme na grafické scénáře popisující vnější interakci systému. Jedná se
o mechanický přepis.
Grafický scénář vzniklý přepsáním slovního scénáře je odrazovým můstkem pro následující
určení dynamické struktury systému.
Dále již iteračně pracujeme s grafickými scénáři. Vycházíme z požadavku na zpracování,
který si sebou nese událost, a z odpovědnosti třídy. Pokud odpovědnost třídy nepokryje celý
požadavek, musí tato třída požádat o spolupráci jinou třídu, nebo musíme změnit její
odpovědnost. V rámci každého grafického scénáře takto určujeme meziobjektovou interakci.
Grafické scénáře (diagramy objektových interakcí) popisují v čase to, jak si jednotlivé objekty
66
postupně předávají události.
U normálních úloh tyto grafické scénáře nemohou být úplné, to je nad lidské síly, ale musíme
zajistit, abychom nic nepřehlédli, abychom všechny události rozlišili a evidovali.
Není tedy cílem úplně popsat všechny možné situace, cílem je popsat co nejrůznorodější
případy, abychom získali seznam všech událostí, které tvoří dynamiku systému.
obr. 20
Zajištění konsistence v meziobjektové fázi
Soustředění událostí do jednoho diagramu - tvorba mapy událostí
Po zpracování grafických scénářů soustředíme všechny události do jednoho diagramu vytvoříme mapu událostí. Mapa událostí se podobá objektovému modelu, uzly jsou třídy,
orientované spoje mezi nimi označují, že objekt (instance třídy) posílá událost objektu druhé
třídy.
Mapa událostí je velmi jednoduchý prostředek, ale velmi účinný. Sumarizuje události mezi
třídami bez ohledu na pořadí. Zahrneme do ní události ze všech scénářů včetně chybových.
Mapa událostí je dynamický protějšek objektového diagramu. Cesty v objektovém diagramu
ukazují možné informační toky, cesty v mapě událostí ukazují možné toky řízení.
Mapa událostí poskytuje dva důležité pohledy na dynamický model:
-globální pohled na všechny události,
-lokální pohled na všechny události jedné třídy (resp. objektů této třídy).
Souhrn všech událostí týkající se jedné třídy je vstupem pro tvorbu stavového diagramu.
U rozsáhlejších systémů pracujeme s třídami událostí, ne přímo s událostmi. To musíme mít
na paměti hlavně při tvorbě stavových diagramů - to co je v mapě jedna událost (třída), to
může být ve stavovém diagramu několik událostí (instancí).
Kontrola konzistence grafických scénářů pomocí mapy událostí
Na mapě událostí se kontroluje konsistence grafických scénářů. Prověří se cesty událostí pro
každý scénář. Tvorba grafických scénářů je typicky lokální proces. Vycházíme z typu jednání
(jednoho z mnoha) nebo jen z jeho části (u složitých úloh) a vymýšlíme, jaké služby jsou
zapotřebí a kdo je poskytne. Při této činnosti není možné udržet přehled přes popis celé
67
dynamiky systému. Právě mapa událostí poskytuje příležitost k zastavení se a obnovení
celkového přehledu.
Nejčastější opomenutí jsou těchto typů:
-události různých jmen vyžadují stejné služby,
-události stejných nebo velmi podobných jmen vyžadují rozdílné služby,
-vyžadované služby neodpovídají odpovědnosti tříd.
Tvorba grafických scénářů vede k hlubšímu pochopení vytvářeného systému, což samozřejmě
vede k jeho změnám. Výrazné změny, jako že v objektovém modelu chybí třída, ty potíže
nedělají. Nebezpečné jsou plíživé změny odpovědnosti tříd. Obvykle má konstruktér po
dokončení grafických scénářů jinou představu o odpovědnosti tříd, než měl na začátku.
K těmto změnám dochází pomalu, takže si je člověk nemusí ani uvědomit. A to je další úkol
pro prověrku konsistence - porovnat popis odpovědnosti tříd s vyžadovanými službami.
Kontroluje se tedy úplnost cest vzhledem k odpovědnosti jednotlivých tříd a jednoznačnost
jmen událostí.
Dynamika jednotlivých objektů - vnitroobjektová fáze
Tvorba stavových diagramů pro jednotlivé třídy, určení chování objektů
Pro jednotlivé třídy se vytvoří stavové diagramy. Pro každou třídu je z mapy událostí známo,
kterou událost přijímá a kterou vysílá.
Je to těžiště práce na dynamickém modelu. Stavové (přechodové) diagramy se vytvářejí jen
pro třídy s výrazným dynamickým chováním - které zpracovávají více přijímaných nebo
vysílaných událostí. Není nutno používat pouze stavové diagramy, je možná:
-tvorba stavového diagramu přímo, nebo
-tvorba stavové tabulky jako podpůrného prvku stavového diagramu, nebo
-tvorba strukturogramu s integrálním pohledem.
Obvyklé je použití stavového diagramu. Pro určení chování objektu máme k disposici
následující vstupy:
-seznam přijímaných událostí,
-seznam vysílaných událostí,
-seznam služeb vyžadovaných od objektů této třídy,
-seznam možných odpovědí na poskytnuté služby,
-seznam služeb vyžadovaných od jiných objektů,
-seznam možných odpovědí na vyžádané služby,
-grafické scénáře,
-popis odpovědnosti třídy.
Tvorba stavového diagramu přímo
Každý scénář nebo sled událostí odpovídá cestě stavovým diagramem. Každé větvení toku
řízení je representováno stavem s více výstupy.
Začínáme se sledem událostí, který se týká modelovaného objektu. Vybereme si typický
průběh a uvažujeme jen události, které se týkají modelovaného objektu. Zapíšeme události ve
formě pojmenovaných šipek. Mezi šipkami jsou stavy. Pojmenujeme tyto stavy. Počáteční
forma diagramu je řada událostí a stavů, pravidelně se střídají. Jestliže se scénář opakuje,
uzavřeme tuto řadu událostí do cyklu.
Nyní hledáme v diagramu cykly. Jestliže se posloupnost událostí stále opakuje, pak tvoří
cyklus. Nahradíme konečné opakování řady událostí cyklem, kde to je jen možné. V cyklu
musí být první a poslední stav totožný. Jestliže si objekt „pamatuje", že již cyklem prošel,
nejsou tyto dva stavy totožné a nelze použít jednoduchý cyklus. Minimálně jeden stav v cyklu
musí větvit řízení, aby to nebyl nekonečný cyklus. Vkládáme další scénáře do stavového
68
diagramu. Nalezneme bod, kde se nový scénář liší od již aplikovaných. Připojíme novou cestu
řízení k existujícím stavům. Také přemýšlíme o tom, které další události mohou ovlivnit stav.
Tyto přidáváme.
Závislost na datech můžeme odstranit zvětšením počtu stavů nebo rozdělením diagramu na
několik poddiagramů.
Po zpracování normálních událostí se věnujeme hraničním a speciálním případům. Například
událost přijde ve špatném čase, takže je třeba zrušit již zčásti provedené zpracování.
Například je na uživateli vyžadována promptní odpověď, tak musíme zavést událost „uplynul
časový interval" a zajistit, aby po tom, co ta událost nastala, byl obnoven počáteční stav
a provedené výpočty byly zneškodněny.
Zpracování chyb je pracné, vyžaduje hodně námahy a kódu. Zpracování chyb často
zkomplikuje jednoduchý a kompaktní stavový diagram, je však nutné. Odhaduje se, že
zpracování chyb je asi trojnásobně náročnější než vlastní výpočet. Je dobré si klást otázky
typu „Co když...", abychom prověřili úplnost zpracování chyb. Když máme složité interakce
s nezávislými vstupy, můžeme organizovat dynamický model jako vnořené diagramy,
většinou však vystačíme s jednou úrovní.
Tvorba stavové tabulky jako podpůrného prvku stavového diagramu
Stavová tabulka a stavový diagram jsou de facto záměnné a vedou v podstatě ke stejným
výsledkům. Liší se hlavně ve dvou bodech:
-v přístupu, v představách použitých při odvozování,
-stavová tabulka je přísnější, vyžaduje větší unifikaci a důslednější promýšlení
problému.
Při návrhu stavové tabulky se vychází z představy unifikovaného vstupu událostí. Událost
není cílena na určitý stav, ale všechny události přicházejí jednou branou, odkud je „přečte"
libovolný stav. Ve stavové tabulce přísluší sloupce událostem nebo skupinám událostí, řádky
přísluší stavům.
Políčko tabulky obsahuje tři prvky:
-akci, která zpracuje událost,
-„čtení" další události,
-přechod na další stav.
Akce je procedura, která provede příslušné zpracování. V případě, že sloupec přísluší skupině
událostí, může být akce realizována stavovou tabulkou další úrovně. U stavových tabulek se
obvykle nerozlišuje mezi akcí a aktivitou, lze však použít modifikaci, kdy je v jednom políčku
dovoleno více akcí.
„Čtení" další události je vlastně čekání, až nastane další událost. Tento prvek může chybět,
tj. událost pro přechod do dalšího stavu je tatáž.
Přechod na další stav realizuje větvení. Může to být i přechod na stávající stav, tj. stav může
cyklicky zpracovávat určité typy událostí.
Tvorba strukturogramu s integrálním pohledem
Konstrukce stavového diagramu i stavové tabulky primárně vychází ze seznamu vysílaných
a přijímaných událostí, popis odpovědnosti třídy slouží jako doplňková informace. Oproti
tomu u strukturogramu vycházíme primárně z představy o činnosti třídy a zpracování událostí
zahrnujeme do již načrtnutého strukturogramu. Strukturogram má velkou výhodu integrálního
pohledu.
Strukturogram má smysl použít v případech, kdy je velká závislost na datech, kdy poskytnutí
jedné služby závisí na již dříve poskytnutých službách, resp. na jejich průběhu.
Strukturogramem popisujeme celý životní cyklus objektu, tj. začínáme od jeho vzniku
(konstruktoru), popisujeme jeho práci a končíme zánikem objektu (destruktorem). Vycházíme
69
z představy o celkovém úkolu objektu, z toho, jak může plnit svou odpovědnost.
Kontrola konsistence událostí a stavových diagramů
Zkontroluje se konsistence událostí a stavových diagramů.
V zásadě se jedná o dvě věci, o úplnost popisu a o změnu modelu chování jako celku.
Podle mapy událostí porovnáme stavové diagramy a zpracovávané události.
Každá událost má svůj zdroj a svého příjemce. Zkontrolujeme to a prověříme. Zjistíme
především stavy bez předchůdce nebo následníka, události bez zdroje nebo příjemce.
Stavy bez předchůdce nebo následníka znamenají chybějící události. Z toho vyplývá chybějící
nebo chybný grafický scénář. Je nutno se vrátit do předchozí etapy.
Události bez zdroje nebo příjemce znamenají chybějící službu. Může to znamenat nejen
chybný grafický scénář, ale i chybějící třídu. V tomto případě je nutno upravit objektový
model.
Prověříme reakci na vstup - zdali odpovídá scénářům. Objekty ve své podstatě pracují
souběžně, prověříme zpracování chyb a dodržování časových limitů. Prověříme konsistenci
události, která se vyskytuje na více výkresech.
Nesrovnalosti vedou k iteraci postupu. Situace je podobná předchozí kontrole konsistence.
Tvorbou stavového diagramu jsme lépe porozuměli úlohám objektů, to může vést ke změnám
v celkovém modelu chování, i dosti podstatným - ke změně odpovědnosti tříd. To může vést
k iteracím vyšší úrovně - přes všechny modely.
Postupné iterování při návrhu dynamického modelu
Složité systémy nelze navrhnout najednou. Při provádění návrhu se často musíme vracet
k předchozímu bodu návrhu. Některé aktivity kontrolního charakteru je pak nutno provádět
opakovaně. Neměli bychom ale sklouznout k povrchnosti. Proto používáme následující
techniky:
-nerovnoměrné rozpracování (nevytváříme vše najednou, práci rozkládáme do více
iterací podle důležitosti),
-hierarchizaci (některé aktivity označíme a řešíme je později samostatně)
-povrchní a detailní rozpracování (některé diagramy vytváříme ve dvou fázích)
70
8. Návrh systému pro kontrolu oprávněnosti
Níže popsaný středně složitý systém byl navrhnut pomocí objektových modelovacích technik.
Jedná se o řešení, které poměrně striktně vychází z popsaných metodik.
Systém byl vytvářen na objednávku Autocont a.s., jakožto dodavatele hardware a software
pro vlastního zadavatele čili školící středisko PVT a.s., které je určeno zejména pro
vzdělávání početné skupiny zaměstnanců a dále je informačním zdrojem pro individuální
práci těchto zaměstnanců.
Použité značení tříd, typů jednání atd. bylo převzato z odborné literatury. [10, 11, 12]
Řešení tzv. autorizačních problémů má tu výhodu, že je už do značné míry typizováno a tedy
není třeba vytvářet nové „objevné“ metody, nýbrž je možno se držet zavedených postupů.
Celý text je rozdělen na dvě části. První částí je analýza celého systému. Druhou částí je pak
analýza programů, které jsou definovány v první části. Návrh je zveřejněn po dohodě s PVT
a.s. a na základě požadavků PVT jsou z něj odstraněny některé podružné i některé významné
prvky. Prezentované řešení je zjednodušeno. Např. v druhé části je analyzován jen program
Request Administrator. I tak je však patrné, jak se takový návrh provádí.
Dřívější stav provozu školícího střediska
Školící středisko je umístěno v jedné budově. V přízemí jsou studovny, do nichž mají
zaměstnanci přístup celý den a mohou zde individuálně pracovat na cca 70 počítačích.
V prvním a ve druhém patře jsou počítače rozmístěny vždy v jednotlivých učebnách po cca 20
počítačích. V těchto učebnách probíhají školení. V každém patře je vstup do prostoru
počítačových učeben či studoven možný vždy jen jedním vchodem, u kterého sedí pracovník
obsluhy.
Do studoven mají přístup zaměstnanci, školitelé a ostatní pracovníci. Do učeben mají povolen
vstup pouze ti zaměstnanci a školitelé, kteří zde mají školení. V případě, že některá učebna
není využita školením, mohou ji využít zaměstnanci pro svou individuální práci. Obsluha
u dveří musí zajistit uvolnění učebny před začátkem dalšího školení.
Při vstupu do studoven (resp. učeben) musí každý příchozí odevzdat svou identifikační kartu
s čárovým kódem) pracovníkovi obsluhy. Při odchodu si kartu u obsluhy vyzvedne. Od
povinnosti odevzdávat identifikační kartu jsou osvobozeni zaměstnanci, kteří jdou na školení.
Problémy spojené s tímto stavem
Z hlediska zaměstnance:
-nedostatečná kapacita,
-vzhledem k nevhodně rozloženému využití kapacit zůstávají někdy počítače
neobsazeny,
-velké fronty u vstupu do studoven,
-když poptávka po individuální práci na počítači prudce narůstá, zaměstnanci čekají až
l h před vchodem do studoven, než se pro ně uvolní místo u počítače,
-nepříjemná „byrokracie“,
-nutnost čekat na obsluhu, až vybere kartu (při příchodu) či až kartu vyhledá a vrátí
(při odchodu),
-nutnost opustit učebny ihned po skončení školení,
-školitel si odvádí zaměstnance do učebny sám.
Z hlediska školitelů:
-školitel ztrácí část vyučovacího času tím, že zjišťuje totožnost osazenstva (jestli patří
71
na školení).
Z hlediska pracovníků obsluhy:
-nepříjemná práce s identifikačními kartami - neustálé třídění či vyhledávání
identifikačních karet podle příjmení (už při počtu 100 karet je velmi zdlouhavé
a monotónní),
-střety se zaměstnanci, kteří nechtějí kartu odevzdat,
-celková monotónnost práce.
Z hlediska Výpočetního centra:
-vysoká fluktuace pracovníků obsluhy - kvůli nepříjemné práci,
-nedostatečná kontrola uživatelů.
Hrubé zadání
Je třeba vytvořit systém, který by měl následující efekty:
-přinutí uživatele počítačové sítě PVT prokázat se při vstupu do prostoru počítačových
učeben či studoven svou identifikační kartou bez toho, aby k tomu byli vyzváni
službou na počítačových učebnách,
-zkontroluje příslušnost zaměstnanců k jednotlivým školením, které probíhají na
počítačových učebnách, nepovolení přístupu těm, kteří na školení nepatří,
-zabrání pracovat v počítačové síti PVT těm osobám, které nejsou zaměstnanci PVT.
K dispozici jsou následující data:
-informace o protažených kartách u vchodu do prostoru počítačových učeben
a studoven (zajišťuje externí systém nazvaný Autorizační brána),
-data o rozvrhu školení na počítačových učebnách,
-soubor dat přiřazující každému zaměstnanci všechna školení, na která je zapsán,
-data přiřazující identifikační karty zaměstnancům.
Systém musí pracovat v maximální míře automaticky.
Podrobné zadání
Základní funkce, které je třeba zajistit:
-kontrola protažení identifikační karty,
-kontrola příslušnosti zaměstnance, který se přihlašuje do sítě PVT v případě, že na
dané učebně probíhá či bude probíhat školení, zda patří na toto školení (zda je na něj
zapsán). Pokud je na školení zapsán, práce v síti je mu umožněna, pokud zapsán není,
je mu přístup odepřen,
-pravidelná aktualizace některých dat,
-možnost editace databází, především možnost zapnutí či vypnutí prováděných testů
bez rizika ohrožení průběhu školení na počítačových učebnách,
-ochrana dat před zneužitím. [9]
Kontrola protažení identifikační karty
Každý oprávněný uživatel počítačové sítě PVT má platnou identifikační kartu. Pokud nějaká
osoba kartu nemá, pak není oprávněným uživatelem.
Data o protažených identifikačních kartách jsou ukládána na jeden ze serverů počítačové sítě
PVT. Je třeba zabezpečit chod systému i při výpadku tohoto serveru.
Je třeba zajistit přístup pro zaměstnance, kteří kartu ještě nemají (první ročníky, nebo ti, kteří
kartu ztratili). Pokud zaměstnanec nemá identifikační kartu, je mu vydáno „Dočasné
potvrzení", kterým se může prokazovat. Tyto dočasná potvrzení vydává oddělení
identifikačních karet. Dočasné potvrzení není možno protahovat čtečkou identifikačních karet.
72
Kontrola příslušnosti zaměstnance na školení
Musí existovat způsob, jak tuto kontrolu vypnout na určené učebně nezávisle na učebnách
ostatních. Musí být možno nastavit také čas, po který má být kontrola vypnuta. Vypnutí
kontroly musí být on-line, bez většího zpoždění mezi zadáním požadavků (obvykle od
školitele) a od skutečného vypnutí této kontroly.
Pravidelná aktualizace některých dat
Každá změna v centrální databázi zaměstnanců se musí v navrhovaném systému projevit do
24 hodin.
Možnost editace databází za chodu systému, možnost zapnutí či vypnutí prováděných
testů, bez rizika ohrožení průběhu školení na počítačových učebnách.
Je třeba, aby oprávněná osoba mohla měnit některé údaje v databázích. V některých situacích
je třeba změnit údaje v databázích okamžitě, za plného provozu.
Ochrana dat
Některá data, která jsou pro testy používána podléhají utajení (informace o zaměstnancích rodné číslo, zapsaná školení, číslo identifikační karty).
Jak se dá obecně postupovat
Pro tento případ byl zvolen následující postup:
1. Konzultace hrubého zadání se zadavatelem a společné vytvoření podrobného
zadání. (provedeno výše)
2. Analýza a design celého systému:
a) Tvorba Modelu jednání
b) Tvorba Objektového modelu
c) Tvorba Dynamického modelu
d) Systémový a objektový design
e) Zkoumání problémů při implementaci a uvádění do provozu
Mezi jednotlivými body si uvědomujeme vzájemné souvislosti (leckdy se
vracíme k předchozímu bodu – proces pak iteruje).
3. Analýza a design jednotlivých programů (zde program Request Administrator).
Postup je rámcově shodný s bodem 2.
2. Analýza a design celého systému
2. a) Vyhledání všech typů jednání - tvorba modelu jednání
Cílem tvorby modelu jednání je popsat dostatečně úplně chování všech typů uživatelů
v typech jednání, tj. určit pro každý typ uživatele všechny interakce mezi ním a navrhovaným
systémem a zajistit si tím pokud možno celistvý, konzistentní model chování uživatelů vůči
navrhovanému systému se všemi variantami.
Nejprve je třeba definovat všechny typy uživatelů (aktory) a poté jim přiřazovat jednotlivé
typy jednání.
Typy jednám se dají později dobře využít při výrobě manuálu k hotovým programům, mohou
posloužit jako hrubá osnova.
Generování interakcí či názvů typů jednání nemusí být úplné (tj. nemusí pokrýt veškeré
chování uživatele), postačí modelovat jen ty okamžiky, které jsou něčím významné.
Výhodným postupem se zdá být promítnutí „životního cyklu " pobytu jednoho typu uživatele
u systému během nějakého uceleného období (dne, roku, práce s počítačem, zapnutí počítače,
apod.) před „ vnitřním zrakem " a pátrat přitom po různých variantách chovám uživatele
73
i systému a hledat interakce, ke kterým mezi nimi dojde.
Zde se klade důraz především na dokonalou znalost konkrétního prostředí, v němž se bude
daný typ uživatele pohybovat a v němž bude pracovat navrhovaný systém.
Je třeba sledovat, co si budou při interakcích uživatel se systémem vyměňovat, nikoli jak to
bude vypadat.
Je vhodné zformulovat typy jednání tak, aby na sebe alespoň částečně navazovaly. Podrobné
a přesné provázaní jednotlivých typů jednání se provede později, až při tvorbě grafických
scénářů.
Mezi typy jednání patří také hraniční scénáře popisující mezní chování uživatelů. Lze využít
hraničních scénářů ze zadání. Jednotlivé hraniční scénáře je třeba přiřadit uživatelům. Tím se
hraniční scénáře zabudují do typů jednání.
Hraniční scénáře vznikají v průběhu všech etap.
2. a) I. Typy jednání pro autorizační systém
V interakcích označených (*) nekomunikuje uživatel přímo se systémem, ale spíše s jeho
okolím. Přesto považuji za užitečné tyto body uvádět, neboť dokreslují „životní cyklus"
kontaktu uživatele s navrhovaným systémem.
Symbol '>' znamená akci či reakci systému.
Typy jednáni u02 až u06 jsou Hraniční scénáře.
u01 Správné chování
Příchod do prostoru počítačových učeben(*)
Protažení karty čtečkou u vchodu (u02)
>Karta je akceptována
Příchod k volnému počítači s úvodním menu na učebně(*)
Zadání ID a Pwd
>ID OK
>Pwd OK
Kontrola oprávněnosti přístupu do poč. sítě PVT
>Přístup povolen (Přihlašovaný si protáhl svou identifikační kartu a patří na školení, pokud
v dané místnosti probíhá či v definované době začne probíhat školení.)
Spuštění uživatelského menu
u02 Protažení ID karty
Protažení karty čtečkou
buď
>Karta odmítnuta
>Zabavení karty obsluhou u vchodu
>Vykázaní uživatele z prostoru učeben
anebo:
>Karta v pořádku
>Vpuštění uživatele do prostoru poč. učeben
u03 Špatné ID
Zadání ID a Pwd
ID bad
>Zpět do úvodního menu
74
u04 Špatné Pwd
Zadání ID a Pwd
Bad Pwd
>Návrat do úvodního menu
u05 Neúspěšně protažení ID karty
Kontrola oprávněnosti přístupu
>Karta neúspěšně protažena čtečkou
>Návrat do úvodního menu
Uživatel opětovně protáhne kartu čtečkou nebo odejde(*)
u06 Uživatel nepatří na školení
Kontrola oprávněnosti přístupu (jen u zaměstnanců)
>Uživatel nepatří na školení
Návrat do úvodního menu
u07 Zrušení zákazu
Školitel požádá obsluhu o zrušeni zákazu
>Zákaz zrušen nebo
>Zákaz nebylo možno zrušit
u08 Mimořádná rezervace
Školitel požádá správce rozvrhů o rezervaci učebny
>Učebna rezervována, nebo
>Učebnu nebylo možno rezervovat
u11 Správa databází
Volba databáze, záznamu, položky, operace
Provedení databázové operace
Ukončení práce s databází, atp.
u12 Nastavení režimu práce
Vyvolání služby na změnu režimu
Volba režimu
Ukončení služby
75
Výše uvedené typy jednání bylo možno propojit v následujícím komplexním typu jednání:
u-top-mj Komplexní typ jednání - příchod, přihlášení uživ.
Protažení ID karty (u02)
Usednutí k volnému počítači se spuštěným programem Úvodní menu
Opakování:
{
Spuštění programu LOGIN
Získání ID a PWD od uživatele
Kontrola na serveru
Pokud chyba, pak:
Oznámení chyby (u03 "Špatné ID" či u04 "Špatné PWD")
Jinak:
{
Spuštění programu Brána
Kontrola karty a příslušnosti na školení systémem
Pokud chyba, pak:
Oznámení chyby (u05 "Neúspěšné prot…" či u06 "Uživatel nepatří…")
Jinak:
Oznámení úspěšného přihlášení
}
Konec LOGINu
Pokud přihlášení proběhlo dobře, pak:
Spuštění Uživatelského menu
Jinak:
Opět spuštění Úvodního menu
}
Dokud není přihlášení úspěšné
Práce uživatele na počítači
Výše uvedený program Brána sbírá data o přihlašovaném uživateli, zajišťuje jejich zpracování
ve formě kontroly oprávněnosti přístupu do sítě PVT a výsledek této kontroly oznámí
uživateli. Pokud uživatel není oprávněn pracovat v daném čase a místnosti na počítači, je
Brána odpovědná za to, že takový uživatel se do sítě skutečně nedostane.
2. a) II. Model jednání
Všechny výše uvedené typy jednání lze zobrazit v modelu jednání:
76
obr. 21 Model jednání
Typ jednání je znázorněn oválem, uživatel obdélníkem.
Na tomto obrázku jsou vidět dvě skupiny uživatelů - vnější (Zaměstnanec, Školitel a Vedoucí)
a vnitřní (Obsluha, Správce rozvrhů a Administrátor). Vnitřní uživatelé zpracovávají
požadavky vnějších uživatelů (typy jednání u-top-ex??) a komunikují s informačním
systémem. Z tohoto vyplývá, že „vnitřní uživatelé" jsou součástí celého navrhovaného
systému.
2. a) Tvorba základního, objektového modelu (OM)
2. a) I. Vlastní Objektový model
Objektového modelu je zapotřebí pro vytvoření celkové struktury navrhovaného systému.
Takto navržená struktura se využívá například při tvorbě grafických scénářů.
V předchozím kroku byly vytvořeny typy jednání, které na první pohled nemají žádnou
přímou souvislost s tímto krokem. Jejich tvorba však významně obohatí znalost problematiky,
odkryje v zadání nezmiňované, avšak často složitě řešitelné souvislosti mezi uživateli,
systémem a jejich okolím. Model jednání tak umožní lépe navrhnout strukturu objektového
modelu, především asociací.
77
Úvodní objektový model - objektový model první úrovně
V objektovém modelu první úrovně jsou shrnuty některé informace z modelu jednání - aktoři
jsou přeměněni na třídy (cLxx), typy jednám jsou představovány asociacemi.
Podrobný objektový model - objektový model druhé úrovně
Dalším krokem je detailnější rozpracování objektového modelu - rozčlenění třídy Informační
systém na části. Při návrhu tohoto systému bylo již v analýze zřejmé, že bude užito
architektury klient-server (požadavek na bezpečnost dat a také požadavek na maximální
rychlost obsluhy na ni jednoznačně ukazoval). Je pravda, že návrh architektury patří spíše do
systémového designu, ale pokud je již architektura dána, pak je nutno s ní počítat i v analýze
jako s omezující podmínkou. Typ použité architektury je současně zajímavou informací
a bylo by škoda nevyužít ji.
V následujících modelech bude architektura klient-server vidět. Serverem je třída Request
Administrator, klienty pak jsou programy, které budou spouštěny uživateli - program Brána
zasílá požadavky na test příslušnosti a program Informátor, který zasílá administrátorské
požadavky.
A2.2 Seskupení tříd do subsystémů
Neuspořádaný diagram je velmi nepřehledný. Třídy v následujícím diagramu jsou do
subsystémů seskupeny. Diagram je mnohem čitelnější, přestože se asociace kříží.
Účelem seskupení tříd do subsystémů je zpřehlednění složitějších objektových diagramů.
78
obr. 22 Objektový model
79
Dokumentované vztahy mezi třídami:
cL01 Zaměstnanec
-“-“-“-“-“cL03 Školitel
-“-“cL04 Vedoucí
cA03 Request adm.
-“-“cA01 Login
-“-“cP01 Počítač u čt.
-“-
cE06 Čtečka
cA01 Login
cA06 Úvodní menu
cA07 Uživatelské menu
cL02 Obsluha
cL05 Administrátor
cL02 Obsluha
cL08 Správce rozvrhu
cL05 Administrátor
cL05 Administrátor
cL05 Administrátor
cA04 Informátor
cA02 Brána
cA06 Úvodní menu
cA02 Brána
cE07 Aut. Server
cE06 Čtečka
cA05 Aut. brána
Protažení karty
Test hesla
Vložení ID jména
Vlastní práce s počítačem
Zabavení karty
Řešení problémů
Uvolnění učebny
Rezervace učebny
Řešení problémů
Statistiky
Komunikace
Komunikace
Ověření oprávnění
Transfer ID
Ověření oprávnění
Ověření oprávnění
Informace o prot. karty
Informace o prot. kartách
Ostatní vztahy jsou nekomentované
Subsystémy Vnější uživatelé, Vnitřní uživatelé a Systém
Z uvedených subsystémů jsou již tři známy Vnější uživatelé, Systém, „subsystém" Vnitřní
uživatelé. Asociace mezi třídami z těchto subsystémů byly zachovány. Nově přibyly
subsystémy Aplikace, Databáze, Hardware. Třídy z těchto subsystémů zabezpečují obsluhu
typů jednání definovaných pro Informační systém (viz model jednání).
Subsystém Aplikace
Nejdůležitější je subsystém Aplikace. Obsahuje třídy, které jsou představovány programy (ve
smyslu Windows), s nimiž komunikují vnější a vnitřní uživatelé. Popsány jsou také vztahy
programů mezi sebou.
Základem celého systému je program Request Administrator, který plní funkci serveru v dané
architektuře.
Klienty jsou programy Brána a Informátor.
Program Informátor zajišťuje systémové služby (tvorba rozvrhů pravidelných
i mimořádných, aktivace či deaktivace příznaku na kontrolu příslušnosti zaměstnance ke
školení v určené místnosti, údržba databází).
Informátor musí být schopen rozlišovat různé druhy uživatelů a smí jim nabízet jen služby
odpovídající jejich právům.
Program Brána zajišťuje základní funkci celého systému - sbírá data o uživateli, zasílá je
serveru – Request Administrator. Tento pak provádí testy a odpovídá Bráně, zda je uživateli
vstup do počítačové sítě povolen či odepřen (pokud je přístup odepřen, sdělí Request
Administrator také důvod). Program Brána není spouštěn přímo uživatelem, ale provádí se
v rámci systémového login skriptu, při přihlašování uživatelů do sítě. Celý postup při
přihlašování uživatele je popsán typem jednání u0l Správné chování.
V programu Hlavní menu si zaměstnanec zvolí volbu Přihlášení do sítě. Program Hlavní
menu na tento povel vyvolá program Login. Ten zajistí vlastní přihlášení a spustí program
Brána. Brána získá data (uživatelské jméno a doménu počítače), zašle je programu Request
Administrator a čeká na odpověď. Z odpovědi serveru vybere výsledky testů, oznámí je
80
uživateli a předá je také Loginu. Ten v případě, že testy proběhnou v pořádku, vyvolá spuštění
programu Uživatelské menu s nabídkou všech aplikací, které uživatelé potřebují ke školení či
práci. Jinak Login uživatele od sítě odhlásí a vyvolá zpět program Hlavní menu.
Posledním programem v subsystému Aplikace je Autorizační brána. Tento program
zabezpečuje kontrolu platnosti identifikačních karet protažených čtečkou. Čtečka je připojena
k počítači, na němž tento program běží.
Informace o čísle protažené identifikační karty jsou ukládány do databáze, z níž je poté čerpá
Request Administrator při testu protažení identifikační karty čtečkou přihlašovaným
uživatelem.
Subsystém Hardware
Subsystém Hardware obsahuje třídy představující technickou součást navrhovaného systému.
Je otázkou, zda tento subsystém nepatří spíše do systémového designu než do analýzy. Již při
zadáváni úlohy však bylo jasné, jaký bude použit hardware. Domnívám se, že je užitečné
použít a zobrazit všechny informace, které jsou k dispozici, a proto jsem výše zmíněné třídy
do analýzy zařadil.
Subsystém Databáze (předběžný návrh datové struktury)
Subsystém Databáze tvoří pouze jedna třída, která vlastní tabulky s daty potřebnými pro
zajištění funkčnosti systému. V této úrovni rozboru problému není nezbytné znát přesnou
strukturu tabulek, postačí jejich předběžný návrh. Zřízení a organizace číselníků apod. může
zatím zůstat nerozhodnuta. Tomu bude věnována pozornost později.
t01 TabProtažených karet
Datum
Čas
Rodné Číslo
Číslo karty
Status
ID
tab. 4
t02 Rozvrh
Ident školení
Datum
Čas
Číslo místnosti
tab. 5
t03 Info o zaměstnancích
ID
Rodné číslo
tab. 6
t04 Zaměstnanci na školení
ID
Ident školení
tab. 7
t07 Systémoví uživatelé
ID
Server
Práva
tab. 8
81
Popis tabulek:
Tabulka protažených karet - externí znakový soubor, pro kontrolu protažené karty je
významné Rodné číslo, dále obsahuje položky: Datum, Čas, Číslo karty a ID.
Tabulka Rozvrh - interní tabulka, obsahuje Ident školení, Datum, Čas a Číslo místnosti.
Tabulka Info o zaměstnancích - interní tabulka, obsahuje spárované informace: ID a Rodné
číslo.
Tabulka Zaměstnanci na školení - interní tabulka, obsahuje informace o všech školeních, ke
kterým jsou zaměstnanci přihlášeni. Položky: ID a Ident školení.
Tabulka Systémoví uživatelé - interní tabulka, obsahuje práva uživatelů v přístupu k datům
uloženým v systému. Položky: ID, Server a Práva.
Hierarchie tříd
Někdy je dobré zobrazit také hierarchie tříd. Na obrázku jsou zobrazeny hierarchické vztahy
tabulek a lidí.
Obdobně by bylo možno hierarchizovat třídy v subsystému Aplikace (všechny třídy uvnitř
tohoto subsystému jsou aplikacemi) či Hardware (všechny třídy mimo cE06 Čtečka jsou
počítače).
82
obr. 23 Hierarchie vybraných tříd
83
2. c) Dynamicky model - prověření objektového modelu
Po ustálení objektového modelu je možno přistoupit k tvorbě dynamického modelu.
Je dosti pravděpodobné, že se při tvorbě dynamického modelu po několika krocích objeví
chyba v objektovém modelu. V takovém případě je třeba přejít zpět do návrhu objektového
modelu, chybu či nepřesnost odstranit a pak opět pokračovat v práci na dynamickém modelu.
Toto zacyklení je přínosné, není chybou návrháře, naopak svědčí o jeho schopnosti vidět svou
práci kriticky. Přestože v textu již nebude na obdobné iterace v dalších krocích příliš
upozorňováno, je možno očekávat návrat do fáze tvorby objektového modelu v každém bodu
uvnitř této etapy i všech etap následujících.
2. c) I. Tvorba grafických scénářů
Zatímco model jednání popisoval tok událostí od uživatele k navrhovanému systému a zpět,
grafický scénář upřesňuje:
-která třída uvnitř navrhovaného systému vstupy od uživatele obdrží
-jaké následné události uvnitř systému vzniknou
-které vnitřní třídy systému si je budou posílat/přijímat
-v jakém pořadí budou události přijímány/vysílány
-která třída a co uživateli odpoví ve formě výstupu ze systému.
K získání takového popisuje zapotřebí znát vnitřní strukturu navrhovaného systému,
především třídy. Proto bylo nutno před tvorbou grafických scénářů udělat nejprve objektový
model, v němž byly třídy definovány.
Základní úlohou grafického scénáře je podrobné rozpracování jednoho typu jednání a jeho
doplnění tak, aby na něj navazovaly jiné grafické scénáře. Vedlejším efektem je vyhledání
událostí, které obíhají mezi třídami a dále prověření správného navržení asociací
v objektovém modelu.
Pro každý typ jednání lze vytvořit jeden či více grafických scénářů. Níže jsou pro demonstraci
tohoto postupu uvedeny některé z nich.
Grafické scénáře použité v Systému
Diagram u-top-02 Protažení ID karty popisuje předávání dat mezi jednotlivými třídami. Je zde
uveden jako příklad vnořeného grafického scénáře („podprogramu").
Diagram u-top-at Autorizace popisuje zadání uživatelského ID a Pwd a jejich ověřování.
Ostatní zde neuváděné diagramy byly konstruovány podobným způsobem.
84
obr. 24 Vybrané grafické scénáře
2. c) II.Tvorba mapy událostí
Mapa událostí ukazuje všechny události, které určitá třída přijímá či vysílá. Návrháři umožní
mapa událostí zvážit, zda daná třída není zbytečně složitá, zda by nebylo rozumnější rozdělit
ji na několik specializovanějších tříd apod. Na základě mapy událostí a grafických scénářů se
85
později vytváří stavové diagramy.
Mapa událostí v tomto případě není uvedena, neboť jí v tomto případě nebylo zapotřebí.
2. c) III.Tvorba stavových diagramů
Tyto diagramy nabízejí pohled na události z jiného úhlu. Zatím co v grafickém scénáři jsou
zobrazeny události, které se týkají nějakého procesu, ve stavových diagramech se pracuje se
všemi událostmi, které se týkají jednoho objektu. Je třeba rozhodnout, v jakém stavu daného
objektu může být ta která událost přijata či odeslána. Není nutné, aby stavové diagramy byly
vytvořeny u každé třídy, stačí je vytvářet jen u tříd dynamicky složitých.
Tvorba těchto diagramů je dosti pracná, blíží se implementační úrovni. Je důležité zvolit
správnou úroveň podrobnosti (nerozpracovávat obecné známé či jednoduché algoritmy). Po
vytvořeni stavových diagramů je již objektový model málo flexibilní, neboť při jeho změně je
nutno prověřit návazné stavové diagramy, a to představuje mnoho nepříjemné práce, do které
se obvykle návrháři nechce. Z tohoto důvodu se doporučuje vytvářet stavové diagramy jako
jedny z posledních.V tomto příkladu nebylo třeba žádného stavového diagramu.
2. d) I.Systémový design celého systému
Dle metodiky se v systémovém designu rozvrhuje analyzovaný systém na technické
prostředky. V případě návrhu tohoto systému bylo poněkud překvapující, že nebylo co řešit.
Všechna designérská rozhodnutí byla učiněna již v analýze. Přesněji - již v zadání bylo
jednoznačně určeno omezujícími podmínkami, jaké technické prostředky budou použity, bylo
jednoznačně určeno prostředí, v němž se bude systém nacházet.
Systémový design byl při návrhu systému uplatněn již v analýze.
Existence subsystému Hardware potvrzuje prolínáni analýzy a systémového designu.
2. d) II.Objektový design celého systému
Objektový design se snaží převést výsledek systémového designu do formy předpisu pro
programátora. Na úrovni celého systému jsou třídami lidé, počítače a programy. Těmto třídám
nelze definovat atributy a metody ve smyslu programovacích jazyků. Jde spíše o vymezení
chování tříd, o podrobný popis práv a povinností každé třídy.
Výsledkem objektového designu při této úrovni podrobnosti je v případě tohoto systému
předpis pro designéra dílčí části systému pro třídy typu Aplikace a také návrhy organizačních
opatřeni pro organizační jednotku, do níž patří lidé s funkcí Administrátora, Správce rozvrhů
a Obsluhy.
V případě tříd typu Aplikace je třeba provést celý postup návrhu systému od zadáni až po
implementaci pro každou třídu zvlášť.
V dalším textu je popsán postup návrhu třídy cA03 Request Administrator.
V případě organizačních opatření představuje objektový design přesnou formulaci provozního
řádu, práv zaměstnanců, školitelů, požadavků vedoucích atd.
2. e) I.Implementace celého systému
Implementací se rozumí obvykle programování. Systém byl implementován v jazyce C++. Na
této úrovni podrobnosti, obdobně jako v případě objektového designu, se ovšem jedná
i o následující:
-sepsání provozního řádu a jeho schválení nadřízenými,
-uzavření dohod s pracovníky jiných oddělení o způsobu předávání dat.
2. e) II.Uvedení celého systému do provozu
Samotnému uvedení celého systému do provozu musí předcházet testování všech programů
86
a příprava a školení pracovníků, kteří budou do celého systému zapojeni. Nezbytnou součástí
je jakási „informační kampaň" mezi budoucími uživateli systému která by jim sdělila
následující:
-proč je nový systém zaváděn,
-datum uvedení systému do provozu,
-pracovníka pro případně řešení nejasností (kancelář, čas,...),
-podstatné změny, které z toho všeho pro uživatele vyplývají, atd.)
3. Návrh programu Request Administrátor
Zadání třídy Request Administrator
Nyní máme za úkol vytvořit objekt cA03 Request Administrator. Jedná se nejdůležitější prvek
subsystému Aplikace. Základní úlohou programu Request Administrator je kontrola
oprávněnosti vstupu uživatele do sítě PVT, založená na testu protažení identifikační karty
uživatele čtečkou u vchodu do prostoru počítačových učeben a dále - v případě, že v místnosti
probíhá školení a nebo v definované době školení začne probíhat - na testu příslušnosti
uživatele k tomuto školení.
Request Administrator plní v celém systému roli serveru v architektuře klient-server. Klienty
jsou:
-program Brána, který zasílá požadavky na kontrolu oprávněnosti vstupu uživatele do
sítě PVT,
-program Informátor, který zasílá administrátorské povely.
Request Administrator může pracovat v několika základních režimech, které lze vzájemně
kombinovat:
-bez kontroly karet x s kontrolou karet,
-bez kontroly příslušnosti ke školení x s kontrolou příslušnosti ke školení.
Požadavky na kontrolu oprávnění vstupu přichází po síti v protokolu TCP/IP od klienta
Brána.
Administrátorské povely (především úpravy databází a nastavování režimu práce) přichází
bud' z konzole počítače, na němž je Request Administrator spuštěn a nebo po síti v protokolu
TCP/IP od klienta Informátor.
Data jsou kódována.
K dispozici budou následující data (v elektronické podobě):
-rozvrh školení na počítačových učebnách:
-obsah: ident školení, ident místnosti, čas školení,
-aktualizace: každou noc, přejímka dat automatizována,
-příslušnost zaměstnanců ke školením:
-obsah: ident školení, uživatelské jméno zaměstnance,
-aktualizace: každou noc, přejímka dat automatizována,
-informace o zaměstnancích:
-obsah: ID zaměstnance, rodné číslo,
-aktualizace: alespoň jedenkrát za rok, přejímka dat automatizována,
-informace o identifikačních kartách, protažených čtečkou u vchodu do
počítačových učeben:
-obsah: datum, čas, rodné číslo, číslo karty, status protažení (úspěšné,
neúspěšné),
-aktualizace: po každém protažení karty čtečkou, přejímka dat automatizována.
Request Administrator musí zajišťovat automatizovanou aktualizaci dat, pokud je možná.
87
Souhrn požadovaných funkcí:
-obsluha požadavků na kontrolu vstupu zaměstnance do sítě PVT (doba obsluhy pod
0,5 sec.),
-obsluha administračních požadavků od Informátora,
-automatizovaná aktualizace databází,
-obsluha požadavků z konzole počítače, na němž je spuštěn program Request
Administrator.
Obsluha konzole nesmí zdržovat obsluhu požadavků ze sítě. Ovládání programu
Request Administrator musí být shodné s ovládáním programu Informátor.
Analýza třídy Request Administrator
3. a) I. Tvorba modelu jednání
Typy jednání
Nejdůležitější typy jednání, které byly získány, jsou:
u-cA03-01 Požadavek na kontrolu vstupu uživatele
Úspěšné přijetí požadavku na kontrolu (s daty).
Pokud se má testovat karta, tak zahrnuje u-cA03-04 Kontrola karty
Pokud se má testovat probíhající školení, tak zahrnuje u-cA03-05 Kontrola školení
Odpověď klientovi
u-cA03-02 Databázové operace
Přijetí požadavku ze sítě či z konzole
Provedení požadované databázové operace (u-cA03-06,08,09,10)
Předání požadovaného výsledku.
u-cA03-03 Nastavování systémových proměnných
Příjem požadavku na změnu režimu ze sítě nebo z konzole.
Nastavení daného režimu.
Odeslání odpovědi.
u-cA03-04 Kontrola protažené karty
Získání rodného čísla k ID.
Zjištění, zda v určeném časovém limitu byla protažena čtečkou ID karta s vyhledaným
rodným číslem.
u-cA03-05 Kontrola příslušnosti na školení
Získání identu školení na dané učebně v daném a definovaném čase.
Pokud je učebna volná, pak kladná odpověď.
Pokud není volná, pak zjistit, zda uživatel patří na dané školení.
Pokus patří, pak kladná odpověď.
Jinak záporná odpověď.
u-cA03-16 Aktualizace dat
kontrola na změnu zdrojového souboru
Pokud zdrojový soubor změněn, pak zálohovat původní datový soubor, smazat původní
soubor, otevřít zdrojový soubor, provést konverzi.
88
u-cA03-17 Inicializace systému při startu
vytvoření databází,
nastavení režimu,
načtení parametrů z inicializačního souboru,
načtení a nastavení parametrů z příkazové řádky,
uložení záznamu o startu programu do „logu"
u-cA03-18 Ukončení aplikace
uzavření všech databází,
uložení záznamu o ukončení činnosti do „logu"
Propojením dílčích typů jednání vznikl tento komplexní typ jednání:
u-ca03-mj Komplexní typ jednání (pro třídu cA03 – Request Administrator)
Inicializace systému při startu (u-cA03-17)
Opakuj:
{
Čekání na přijetí požadavku
Požadavek přijat
Pokud je požadavek na provedení:
{
Kontroly, pak vykonat:
Požadavek na kontrolu vstupu uživatele (u-cA03-01)
Databázové operace, pak vykonat:
Databázové operace (u-cA03-02)
Nastavení režimu práce, pak vykonat:
Nastavení režimu práce (u-cA03-03)
Aktualizace dat, pak vykonat:
Aktualizace dat (u-cA03-16)
}
}
Dokud není požadavek na ukončení práce
Ukončení aplikace (u-cA03-18)
3. a) II. Model jednání
89
obr. 25 Model jednání
Administrátor může pracovat s programem Request Administrator buď přímo přes konzoli
počítače, na němž Request Administrator běží a nebo po síti z libovolného počítače, na němž
si spustí program Informátor.
Zaměstnanci přistupují ke programu Request Administrator jen přes program Brána.
Zaměstnanci nejsou v modelu jednání zahrnuti právě proto, že nekomunikují přímo
s programem Request Administrator.
Aktor Čas vyvolává proces denní aktualizace databází.
3. b) Tvorba objektového modelu
Po získání modelu jednání byl vytvořen objektový model programu Request Administrator.
V objektovém modelu jsou následující subsystémy:
-Lidé, subsystém nedoznal významných změn oproti OM celého systému
-Aplikace, subsystém nedoznal významných změn oproti OM celého systému
-Čas - nová třída, určuje režim práce třídy Request Administrator v závislosti na tom.
zda se daný časový okamžik nachází uvnitř pracovního týdne školícího střediska (pak
probíhá školení a je nutno provádět kontrolu příslušnosti) či zda již pracovní týden
školícího střediska skončil a následující ještě nezačal (pak se test na příslušnost
ke školení provádět nebude). Kromě toho po uplynutí zadaného časového kvanta je
90
vyvolána pravidelná aktualizace dat.
-Výkonné prvky - třída cA03 Request Administrator vlastní následující třídy:
-třídu KomTCP (zajišťuje spojení mezi klientem a aplikačním serverem
v protokolu TCP)
-třídu Status, která je schopna zobrazovat aktuální stav Request Administrator režim práce,
-několik databázových tabulek.
-Databáze (upřesnění předběžného návrhu datové struktury)
-původní tabulky:
-tabulka TabProtažených karet (cT01) - beze změny
-tabulka Rozvrh - rozpad na dvě části:
-tabulka Pravidelný rozvrh (cT02) - obsahuje pouze pravidelná
školení, položkami jsou: Ident školení, Datum, Čas a Číslo místnosti.
t02 Pravidelný rozvrh
Ident školení
Datum
Čas
Číslo místnosti
tab. 9
-tabulka Výjimky v rozvrhu (cT05) - obsahuje mimořádná školení,
testy a podobně. Položkami jsou: Ident výjimky, Datum, Čas a Číslo
místnosti.
t05 Výjimky v rozvrhu
Ident výjimky
Datum
Čas
Číslo místnosti
tab. 10
-tabulka Info o zaměstnancích (cT03) - beze změny
-tabulka Zaměstnanci na školení (cT04) - přidány položky: Ident výjimky
a Ident záznamu. Původní položky: ID, Ident školení jsou beze změny.
t04 Zaměstnanci na školení
ID
Ident školení
Ident výjimky
Ident záznamu
tab. 11
-tabulka Systémoví uživatelé (cT07) - beze změny
-nová tabulka:
-tabulka Log (cT06) - obsahuje záznamy o neobvyklých stavech. Položkami
jsou: Ident záznamu, Datum, Čas, Stupeň důležitosti a Událost.
t06 Log
Ident záznamu
Datum
Čas
Stupeň důležitosti
Událost
tab. 12
91
Datovou strukturu si nyní můžeme nastínit pomocí tohoto relačního schématu. (Jedná se
o první nástin – do implementace ještě můžeme očekávat výrazné změny.)
obr. 26 Předběžné relační schéma datové struktury
Uvedené informace si nyní můžeme shrnout v sestaveném objektovém modelu třídy Request
Administrátor.
V modelu zobrazenou třídu KomTCP vlastní také třídy cA02 Brána a cA04 Informátor. Tím
je zajištěna jednotná komunikace mezi klientem a serverem.
92
obr. 27 Objektový model
93
3. c) Tvorba dynamického modelu
3. c) I. Grafické scénáře
Pro ilustraci je zde uveden vnořený grafický scénář u-cA03-01 Kontrola vstupu:
Po přijetí požadavku na test údajů se podle režimu provedou či neprovedou testy.
Výsledek testů se zpracuje v tomto grafickém scénáři.
Ostatní zde neuváděné diagramy byly konstruovány podobným způsobem (jedná se zejména
o komplexní grafický scénář, o scénáře podrobného popisu testů atd.).
obr. 28 Vybraný grafický scénář
3. c) II. Mapa událostí, Přechodové diagramy
Žádného z těchto diagramů nebylo při analýze zapotřebí.
3. d) I. Systémový design třídy Request Administrator
Request Administrator je program, který je spuštěn na jednom počítači. Obsluhuje dva druhy
požadavků:
-požadavek na test oprávněnosti práce uživatele na počítači v dané místnosti
a v daném čase,
-administrátorské povely a dotazy.
Požadavky na test mohou přicházet pouze ze sítě, od instancí třídy Brána. Administrátorské
příkazy mohou přicházet buď z konzole počítače, na němž je Request Administrator spuštěn
a nebo od klienta Informátor.
Vzhledem ke korespondenci těchto tezí s objektovým modelem musíme konstatovat, že
systémový design byl uplatněn již v analýze.
3. d) II. Objektový design třídy Request Administrator
Výstup ze Systémového designu je takový, že již není nutno významněji upravovat modely.
3. e) Implementace třídy Request Administrator
Request Administrator byl jako ostatně celý systém implementován v programovacím jazyce
C++. Na celé implementaci systému pracovali dva týdny čtyři pracovníci PVT a. s.. V tomto
případě se jednalo o aplikaci, která komunikuje přes protokol TCP/IP a umí obsluhovat
94
databázové požadavky.
Použité programové vybavení – program SmartDraw
Přestože jsou v další část práce recenzovány simulační programy ERwin, BPwin a Powersim
Studio, pro tento návrh si zadavatel vymínil použití vlastního (jím licencovaného)
programového vybavení, a to zejména kvůli snadným pozdějším aktualizacím návrhu.
Podle názoru autora je to jeden z nejzdařilejších programů, určený k návrhu IS. Jedná se
o integrované návrhové prostředí SmartDraw.
obr. 29 Návrhové prostředí SmartDraw
Program je dostupný v mnoha verzích. V té základní funguje jen jako inteligentní kreslící
prostředí (čili vlastně jako jakýsi inteligentní poznámkový blok návrháře). Plně profesionální
verze pak obsahuje mnoho rozšiřujících tzv. plug-in modulů, které do programu přinášejí
možnost použití všech modelů a analýz popsaných v teoretické části této práce. Další
rozšiřující moduly nám poskytují nové funkce např. kontrolní mechanismy (kontrola
přebytečných „redundantních“ komponent modelu, kontrola neošetřených vazeb ap.).
Podrobná recenze tohoto programu přesahuje rámec této práce.
Závěr
Dostatečně provedená analýza problému se zhodnotila v rychlosti a pohodlnosti
implementace. Během celé implementace a uvádění do provozu nebyl zaznamenán žádný
podstatný problém. Celý systém byl před časem modernizován a funguje dodnes.
95
9. Program ERwin
Řešení správy informací.
Pomůcka pro vytvoření návrhu databáze snadno a rychle.
ERwin je návrhová pomůcka pro návrh databází, která zvýší úroveň vypovídací schopnosti
dat v transakčních systémech a systémech tzv. datových skladů. Program poskytuje nástroje
na návrh a implementaci databází pro transakční obchody, elektronický obchod a aplikace pro
"skladování dat", a to může pomoci organizaci udržet si svou konkurenceschopnost.
Pomocí programu jsou vytvářeny a udržovány grafické modely, které reprezentují databázi,
datové sklady a podnikové datové modely. Jedná se o modelovací platformu, kde podnikové
datové požadavky a související návrhy databáze mohou být snadno definovány, řízeny
a implementovány pro různé druhy databázových platforem.
Je zde spojeno grafické uživatelské rozhraní Windows se silnými nástroji pro sestavování ER
diagramů, s uživatelskými editory na definování fyzických databázových objektů,
průzkumníkem modelů pro textový pohled na objekty modelů a podporou pro SQL.
obr. 30 Prostředí ERwin
Implementace designu standardů pro podnikovou sféru
Proces vývoje aplikací je usměrňován a různým skupinám (správcům standardů, obchodním
analytikům, lidem vytvářejícím datové modely a ostatním) je umožněno vykonávat práci
nezávisle, při vzájemné spolupráci a synchronizaci. Tímto způsobem, mohou různé skupiny
současně pracovat na rozličných částech modelu nebo na různých druzích modelů.
Visuální uspořádaní informací
Jak již bylo řečeno, hlavní výhodou tohoto prostředí je, že se jedná o pomůcku pro návrh
databází, která spojuje výhody Windows s výkonnými nástroji pro konstrukci ER diagramů
a početnými inovačními rysy. Tyto rysy nám dovolí snadno tvořit a udržovat naši relační
databázi a logické a fyzické modely které ji popisují. Výsledně pak máme k dispozici takové
řešení designu, které nám pomůže vytvořit vizuální datový model pro naši organizaci.
96
obr. 31 Příklad vytvořeného schématu
Základní informace o užití
Tento program je mnohem víc než kreslicím nástrojem. Nejen že nám pomůže navrhnout
logický datový model, který zachycuje obchodní pravidla a související požadavky, ale také
podporuje design odpovídajícího fyzického datového modelu pro náš cílový server. Toto nám
umožňuje, abychom urychlili konstrukci tohoto fyzického datového modelu a automaticky
generovali fyzické databázové struktury.
Je podporována reverzní analýza existujících databází a můžeme zde využít fyzického
a logicko/fyzického datového modelu, takže můžeme udržovat existující databázi, nebo ji
transformovat z našeho nynějšího cílového serveru na jiný.
Navíc, průlomová celková srovnávací technologie automatizuje synchronizaci modelu
a databáze tím, že nám dovoluje srovnat model s databází a zobrazit a analyzovat rozdíly.
Toto nám umožňuje, abychom selektivně přenesli rozdíly do modelu nebo je vygenerovali do
databáze.
97
obr. 32 Vztah mezi datovým modelem a databází
Rozšíření a vylepšení
Když jsou databázoví návrháři a informační manažeři dotázáni na konkrétní důležité aspekty
týkající se požadavků na jejich řešení datového modelování, pak to co potřebují je nástroj,
který zahrnuje komplexní aplikační vývojový cyklus. Většinou, cyklus začíná shromážděním
pravidel obchodování a vytvářením logických konstrukcí a pokračuje ve fyzické fázi designu
následované implementací databáze s podporou jedné nebo více aplikací. Toto je zřetelně
iterační proces. Z tohoto důvodu, je požadován program, který je flexibilní a snadno
použitelný a který podporuje rozmanité platformy, opětovné použití objektů a schopnost
synchronizovat změny mezi datovými modely po celém podniku. Čili program, který přináší
maximální použitelnost a flexibilitu pro podporu aplikačního vývojového procesu v nových
dynamických podmínkách.
obr. 33 Cyklus vývoje aplikace
98
Inovace
Vylepšení pracovní plochy a uživatelského rozhraní zahrnuje pracovní oblast
s průzkumníkem modelů, vylepšené a dokovatelné panely nástrojů, pokročilé kreslení objektů
a inovované struktury menu. Podstatné jsou také zlepšené základní modelovací rysy jako jsou
postupná a zpětná analýza a komplexní srovnávání.
obr. 34 Popis prostředí ERwin
Okno schématu – graficky zobrazuje pohled na datový model.
Průzkumník modelu – poskytuje hierarchický pohled (ve formě textu) na datový model,
který je zobrazený v okně schématu. Kliknutím na záložku průzkumníka modelu, si můžeme
zobrazit různé typy pohledů na model.
Panely nástrojů – všechny lišty s nástroji jsou dokovatelné nebo plovoucí. Lišty s nástroji
obsahují tlačítka úloh, která můžeme použít jako zkratku na rychlé vykonání běžných úkonů.
Jednoduše ukážeme kurzorem nad každé tlačítko lišty nástrojů abychom zobrazili popis,
jakou akci vykonává.
Záložky displejů – předvoleně každý datový model zahrnuje jeden pohled na strukturu, který
je pojmenovaný "Displej 1". Můžeme ho samozřejmě přejmenovat a vytvářet další abychom
si přizpůsobili pohled na náš datový model.
Flexibilní podpora rozmanitých typů modelů
Program podporuje pro rozmanité typy modelů a dovoluje lidem pracujícími s datovými
modely pracovat s takovými modely, které jsou pro jejich potřebu nejvíce vhodné.
Jsou dostupné následující možnosti:
Logický – koncepční model, který obsahuje objekty jako entity, atributy a klíčové skupiny.
Fyzický – databázově-specifický model, který obsahuje objekty jako sloupce tabulek a datové
typy.
Logicko/fyzický – toto byl nejprve standardní model ERwin - jedná se o jednoduchý model,
který zahrnuje oba modely logický a fyzický.
99
Ukazatel typu modelu je umístěn na liště nástrojů a ukazuje zvolený typ modelu.
V logicko/fyzickém modelu, můžeme snadno přepínat mezi logickým modelem a fyzickým
modelem výběrem typu modelu ze menu "Options" na liště nástrojů.
Průzkumník modelu
Průzkumník modelu poskytuje organizovaný, textově orientovaný pohled na náš datový
model a jeho obsah. Metoda vytváření objektů je tudíž velice snadná (pouze jedno kliknutí).
Průzkumník modelu nám umožňuje vytvořit, zobrazit, procházet a modifikovat náš model
použitím předmětných oblastí nebo panelu domén.
obr. 35 Průzkumník modelu
Specifické objekty z našeho modelu se zobrazují pod obecným objektovým typem.
Pro přepnutí na jiný panel, stačí kliknout na záložku na spodní straně průzkumníka modelu.
Zde je znázorněn příklad každého panelu v průzkumníku modelů.
obr. 36 Možnosti průzkumníka modelu
100
10. Program BPwin
BPwin je komplexní obchodně-modelovací prostředí, které nám pomáhá si představit,
analyzovat a zlepšit obchodní procesy. Toto dopadá na náš konečný rozpočet snižováním
celkových nákladů a rizik spojených s přizpůsobením se operačním změnám. BPWIN nám
umožňuje, abychom:
-Ocenili nynější provozní činnosti,
-Formulovali a zhodnotili alternativní reakce na signály trhu,
-Prováděli operativní zásahy rychle a intuitivně.
Komplexní obchodní perspektivy
Modely tohoto programu můžeme použít na vytvoření konstrukce, která nám pomůže lépe
porozumět našim obchodním procesům a určit, jak tyto procesy působí společně s daty
protékající naší organizací. Používáním tohoto silného nástroje, jasně pochopíme
a analyzujeme proces, datový tok a pracovní tok.
Proč vlastně zlepšovat obchodní proces
V dnešním komplexním a stále se měnícím světě, se obchodní organizace potřebují soustředit
na proces jak uspokojit zákazníkovi potřeby. Ať už jsme v malé nebo velké organizaci, toto je
proces, kterým dodáváme zboží nebo služby, které znamenají kvalitu a nakonec i úspěch
z obchodní činnosti. Zlepšení obchodního procesu zahrnuje mapování a modelování
nesčetných interakcí uvnitř organizace kvůli lepšímu porozumění a zlepšení jeho fungování.
Můžeme zpětně analyzovat celou organizaci nebo určitou část organizace. Dále je možné
srovnat současné požadavky na systém v kontrastu s aktuálním výkonem stávajícího
informačního systému.
Modelování je jedna z nejefektivnějších technik pro porozumění pravidlům a procesům
obchodování. V procesním modelu, jsou eliminovány vedlejší detaily a důležité informace
jsou zvýrazněny, tím se snižuje složitost a zvyšuje přehlednost. Grafické znázornění (čili boxy
a šipky) jsou užívány pro zobrazení velké části celé struktury, což je právě tím důvodem, proč
si většina lidí představuje procesní modely jako jejich kreslené reprezentace. S procesním
modelováním můžeme zkoumat systém do požadované hloubky podrobnosti, takže složité
vztahy naší organizace mohou být analyzovány, pochopeny a sděleny ostatním.
Celkový pohled na metody modelování a sestavování diagramů
Modely programu poskytují ucelený obraz o tom, jak organizace funguje, a to od malých
oddělení po celou organizaci. Zde je jedno schéma typického modelu:
101
obr. 37 Prostředí BPwin
Stručný popis metod modelování a procesů použitých u BPwin:
Modely aktivit
Model aktivit představuje systém jako soubor činností, ve kterém každá aktivita přetváří
nějaký objekt nebo sadu objektů. Modely aktivit reprezentují činnosti ve formě boxů, obrazců,
nebo grafických map. Tyto prvky jsou pak označeny slovním popisem, aby znázorňovali, co
která aktivita koná. Pro další charakteristiku aktivit, jsou užity spojné šipky kvůli reprezentaci
rozhraní mezi aktivitou a okolím.
Úroveň detailů, zobrazená v schématu modelu aktivit se nazývá stupňovitě rozvrstvený
(hierachický) vztah. Například, hierarchie aktivit by mohla vypadat následovně:
Hierarchie aktivit produkce technického výrobku
1. Operativní výroba
1a. Plán produkce
-Vyhodnocení zásob součástí, objednávání
-Rozvržení produkce
-Naložení se zastaralými součástkami
1b. Sestavení produktu a transport
-Zpracování polotovaru
-Sestavení komponent
-Konfigurace
-Testování
-Opravy
-Logistika
102
IDEF0 - Metoda funkčního modelovaní
IDEF0 je technika, která modeluje celé systémy jako soubor souvisejících aktivit nebo funkcí.
Tímto způsobem mohou být funkce systému analyzovány nezávisle na objektech
vykonávající tyto funkce.
Předtím než se pustíme do stavby IDEF0 modelu, je rozumné poznat účel modelu, rozsah
modelu a je dobré své představy prezentovat. Je rovněž rozumné se na věc dívat z různých
úhlů pohledu (například: zákazník, dodavatel, majitel skladu, a editor) - to jsou různé
perspektivy, podle kterých bude vypracovávaný model odrážet systém.
IDEF0 model obsahuje dva grafické symboly – boxy a šipky. Tuto komponentu používáme
v počátečním stupni projektu pro pozdější analýzu metodou IDEF3.
IDEF3 - Popis procesu metodou zachycení
IDEF3 je technika navržená k tomu, aby poskytovala uspořádaný výsledek, kterým oborový
expert může popsat situaci jako daný sled událostí a může popsat jakýkoliv účastnický objekt
těchto událostí. Tuto komponentu používáme na modelování procesu, který ještě nemusí být
kompletní. Můžeme posoudit výkon metody analyzováním výsledku skrz simulaci.
Sestavování diagramů toků dat
Podobně jako IDEF0, sestavování diagramů datových toků modeluje systémy jako síť aktivit
spojených navzájem potrubími objektů. Dále, diagram datových toků také modeluje
rezervoáry nazývané datastory a externí entity, které reprezentují rozhraní s objekty vně
systému. Šipky užívané v DFD představují pohyb dat díky aktivitě. Sestavení DFD je široce
používáno v softwarovém designu.
Určení ceny a výkonu na základě aktivit
Je to technika pro zachycení a analyzování nákladů činností. Tato metoda je užívaná spolu
s výsledky ostatních systémových, objektových modelů a modelů aktivit. Tato metoda je
neocenitelná ke zjištění přesné kalkulace ceny produkce výrobku založené na ceně vykonání
všech aktivit spojených s jeho vytvořením.
Pohled na pracovní plochu BPWIN
Následující schéma znázorňuje prostředí ve kterém je vytvořen model:
103
obr. 38 Popis prostředí BPwin
Průzkumník modelu
Průzkumník modelu je silný nástroj, který můžeme použít ke globálnímu pohledu
a následnému přístupu k činnostem, schématům a objektům v jakémkoliv otevřeném modelu.
Při jednom nebo více otevřených modelech se můžeme podívat na všechna schémata, činnosti
a objekty ve formě grafických prvků v rozbalovací hierarchické stromové struktuře. Pro
jakoukoli metodologii co užíváme, nám průzkumník modelů poskytne úplné perspektivní
zobrazení celého modelu.
Můžeme kliknout na záložku činností nebo záložku schémat, abychom viděli hierarchii
činností nebo hierachii schémat (všechny činnosti a schémata v jakémkoliv otevřeném
modelu). V záložce činností pak můžeme otevřít dialogová okna vlastností činností, přidávat
a odebírat činnosti a vytvářet dekompozice uvnitř stejného modelu nebo i v různých
modelech. V záložce schémat se můžeme podívat na vlastnosti schémat pro všechny typy
schémat programu včetně stromu uzlů, FEO, scénáře IDEF3, plovoucích cest a organizačních
schémat.
Když klikneme na záložku objektů v průzkumníku modelů, můžeme se podívat na nepoužitá
jména (jména objektů ve schématech, která ve vlastním schématu nefigurují) a případně tato
přetáhnout myší do schématu jako objekty daného schématu. Například, jestliže máme ve
slovníku jméno činnosti "obdržet příkaz", můžeme toto jednoduše přetáhnout do schématu,
abychom v něm vytvořili činnost spolu se všemi dalšími vlastnostmi.
Pro zobrazení a skrytí průzkumníka modelů, klikneme na tlačítko průzkumník modelu na liště
s nástroji. Pokud je zapnut, pak je průzkumník modelu zobrazen v posuvné a zadokovatelné
výplni vlevo od nynějšího modelu schématu.
104
obr. 39 Průzkumník modelu
105
11. Program Powersim Studio
Simulace v Powersim Studiu jsou založené na simulování dynamických systémů. Simulace
dynamického systému je metodologie založená na počítačovém zpracování a vyvinutá
v Massachusettském technickém institutu (MIT) v 1950s jako nástroj pro manažery k analýze
složitých problémů.
Slovo "dynamický" naznačuje pokračující tendenci systému se měnit, a to je právě to, co
dynamické systémy dělají - postupně se mění.
Používání této metody simulace nám dovoluje vidět nejenom události, ale také zákonitosti
chování v čase. Chování systému často vyvstává z jeho struktury a toto chování se s časem
mění. Někdy se provádí zpětná simulace, abychom zjistili původní stavy nebo počáteční stav.
Většinou se ale simulace provádí směrem do budoucnosti, abychom mohli předpovídat možné
budoucí výsledky.
Pravidla dynamických systémů:
Příčina a následek
V programu můžeme tvořit schémata příčin a následků, abychom ilustrovali jejich vztahy.
V takových schématech pak užíváme šipky, abychom vztahy nastínili. Někdy je také zahrnuta
ve schématu informace o tom, jak vztah přesně funguje. Přidané "o" do schématu naznačuje
"změnu v opačném směru". Právě takovým vztahem je vztah mezi cenou a odbytem, kde
zvýšení ceny vede ke snížení odbytu. Vztah mezi narozenými a počtem obyvatel je jiného
charakteru. Když se zvýší porodnost, tak právě tak se zvýší počet obyvatel. Toto je situace,
kde určitá akce vede ke "změně ve stejném směru". Přidané "s" k šipce v schématu právě toto
signalizuje.
obr. 40 Schéma příčin a následků
Zpětná vazba
Zpětná vazba je vlastnost, kterou většina lidí spojuje s mikrofonem a reproduktory. Mikrofon
který není pořádně nastaven, zachytí zvuk přicházející z reproduktoru. Tento zvuk se zesílí,
bude vydáván reproduktory a pak znovu zachycen mikrofonem. Tento zesilující jev trvá tak
dlouho, až reproduktory vydávají tak hlasitý zvuk, jak mohou nebo až mikrofon přestane
registrovat další zvýšení hlasitosti. Toto je obecný princip zpětné vazby - že nějaké příčinné
kauzality působí společně tím způsobem, že účinek jednoho elementu ovlivňuje druhý
a naopak. Toto je velmi častá věc ve všech druzích systémů, ačkoli lidé si to často
neuvědomují.
Zpoždění
Často je vztah mezi příčinou a účinku zakrytý posunem účinku v čase. Je těžké porozumět
systému, když se důsledky bezprostředně neprojevují na chování systému. Dítě, které se
dotkne horkých kamen ihned pochopí důsledky svého omylu a pravděpodobně již chybu
106
nezopakuje. Naproti tomu mnoho rozhodnutí má důsledky, které se projeví za několik let
a tyto důsledky pravděpodobně nikdy nebudou spojeny např. s rannými chybnými
rozhodnutími.
Zpoždění může produkovat zajímavé a komplikované chování v systémech dokonce i tehdy,
když tyto systémy nemají žádnou zpětnou vazbu a pouze malou složitost vztahů příčin
a následků.
Prvky schémat
Z předchozího vyplývá, že Powersim Studio je modelovací prostředí založené na nauce
o dynamických systémech. Studio nám dovoluje modelovat systémy - se všemi vztahy příčin
a následků, zpětnými vazbami a zpožděními - v intuitivním grafickém prostředí. Symboly
reprezentují: proměnné s pamětí (v textu označované jako "úrovně" z anglického level) jedná se o postupně se akumulující proměnou, toky (z anglického flow) - jedná se o akci
provádějící změnu např. akumulaci a pomocné proměnné (v textu označované jako
"příslušenství" z anglického auxiliary). Tyto symboly jsou užívány pro vytváření grafických
znázornění systému v konstrukčních schématech. Toky a informační spoje představují
vzájemné vztahy a propojení. Celá struktura systému, bez ohledu na to jak je komplexní,
může být reprezentována použitím těchto typů symbolů a různých spojení.
Úrovně a toky
V systémových dynamických modelech je struktura systému reprezentovaná matematicky.
Úroveň je akumulace (nebo integrace) toků, které působí na tuto úroveň. Pozn.: Při
integrování funkce měříme oblast pod funkcí tím, že ji rozdělíme na ekvivalentní úseky
a potom sečteme jednotlivé oblasti všech úseků.
obr. 41 Integrace funkce
Když graficky vytváříme simulační model, spojování symbolů proměnných nám vytváří
rovnice. Každá proměnná v modelu je pak součástí rovnic podobně, jako jsou např. buňky
součástí tabulkového procesoru.
Ve Studiu, boxy reprezentují úrovně. Dvojité šipky reprezentují toky, přičemž tok je
kontrolován rychlostí toku. Rychlost toku je definovaná stejným způsobem jako prvky
tzv. příslušenství. Toto je jednoduchý model graficky vytvořený ve Studiu.
obr. 42 Příklad modelu
Zajímavý je symbol, který vypadá jako mrak - vlevo od prvního toku a vpravo od druhého
toku. Toto je zdroj a respektive nor struktury. Tento symbol signalizuje nekonečnost
a označuje hranici modelu. Například, v této jednoduché struktuře je úrovní ' pracovní síla'
měřená v lidech, která je navyšována tokem 'rychlostí náboru' a snižována tokem 'rychlostí
propouštění'. Symboly obláčku nám řeknou, že nás v tomto modelu nezajímá odkud se najatí
lidé berou nebo kam propuštění lidé odchází. Tato informace už je za hranicí modelu.
107
Kdybychom se zajímali i o tuto informaci, mohli bychom přidat další úroveň vlevo od
rychlosti náboru a vpravo od rychlosti propouštění a tím rozšířit hranice modelu. Toto je
uvedený rozšířený model, kde máme zahrnuty úrovně uchazečů a dřívějších pracovníků.
obr. 43 Rozšířený příklad modelu
Příslušenství
Zatímco je možné tvořit celý model s jen úrovněmi a toky, program má ještě další nástroje,
abychom do modelu zachytili skutečné úkazy. Pro dosažení určité úrovně detailů nebo jako
pomoc při formulaci rovnic rychlosti toku, je někdy nezbytné použít pomocné proměnné.
V programu, jsou reprezentovány kruhem.
Pomocné proměnné jsou užívány pro spojení nebo opětovnou formulaci informací. Nemají
žádnou předepsanou strukturu; je to vlastně algebraické dopočtení nějaké kombinace úrovní,
rychlostí toků nebo dalších příslušenství. Ačkoli se pomocné proměnné zdají být akumulací,
nemají narozdíl od úrovní žádnou paměť. Příslušenství je užíváno na modelovaní
informačních transferů (ne fyzického toku zboží), takže se mohou změnit bez prodlení
(okamžitě). Mohou být vstupy toků, ale nikdy nejsou napojeny přímo k úrovním, protože toky
jsou to jediné, co může měnit úrovně k nim přidružené. Nicméně úrovně, mohou být vstupy
k příslušenstvím. Platí, že rychlosti toků a příslušenství jsou definované přesně stejným
způsobem. Rozdíl je v tom, že rychlost toku je napojená na vlastní tok a tím ho ovládá přímo.
Konstanty
Konstanty jsou (narozdíl od obyčejných příslušenství), neměnné po celou dobu simulace. Jsou
označeny kosočtvercem.
Konstanta je definována počáteční hodnotou a tuto hodnotu si během simulace udržuje, pokud
uživatel nezmění hodnotu manuálně. Například, v jednoleté simulaci má společnost početně
stalý počet zaměstnanců, který může být reprezentován jako pomocná konstanta. Pokud
simulaci rozšíříme třeba na 20 let, pracovní síla se nejspíše stane proměnnou (úrovní) a bude
mít povoleno měnit se s časem. Ještě jednou se tedy vrátíme k důležité otázce definice
problému a hranic modelu. Bez rozumné transformace výchozího problému na model
nebudeme schopni nastavit řádné hranice.
Někdy nám není jasné, zda prvek systému by měl být přidán jako konstanta nebo proměnná.
V těchto situacích bychom se měli pokusit si znovu promyslet celý problém. Měli bychom
promyslet dobu simulace daného prvku a jeho chování v ní a zjistit, zda je možno očekávat
změnu hodnoty prvku během období. Potom se nám bude lépe rozhodovat, co bude konstanta
a co bude proměnná.
Informační spoje
Mezi konstantami, příslušenstvím a úrovněmi jsou vytvářena spojení přes tzv. informační
spoje. Tato spojení se objeví jako tenké spojky v konstrukčním schématu.
108
obr. 44 Znázornění informačních spojů
Informační spoje ukazují, jak jsou jednotlivé elementy systému dohromady strukturovány.
V jiném smyslu uzavírají smyčku zpětné vazby. Již bylo ukázáno, jak tok mění jednotlivé
úrovně jejich plněním nebo vyprazdňováním. Informační spoje mohou přenést hodnotu
směrem z úrovně zpět do toku, ukazujíc tak závislost toku na úrovni právě tak, jako zřejmou
závislost úrovně na toku.
obr. 45 Znázornění informačních spojů a toků
Aby bylo konstrukční schéma konzistentní, rovnice definující určitou proměnnou, musí
obsahovat všechny proměnné, které jsou s danou proměnnou spojeny.
109
12. Případové studie – simulace dynamických procesů
<použito Powersim Studio>
Půjčka s pevnou úrokovou sazbou
Tato simulace nám dovoluje experimentovat s různými platebními scénáři. Můžeme měnit
výši půjčky, úrokovou sazbu a velikost splátek. Simulace určí, jak dlouho budeme půjčku
platit a také spočítá úhrnnou částku, kterou musíme zaplatit.
obr. 46 Výstup případové studie
Schéma příčin a následků ukazuje vazby v procesu, který udává celkovou bilanci půjčky.
obr. 47 Schéma příčin a následků
110
R1 je pozitivní zpětná vazba znázorňující stav půjčky. Větší úhrn půjčených peněz znamená
větší úrok, který zase zvyšuje úhrn půjčených peněz.
Schéma příčin a následků neobsahuje vztah mezi bilancí půjčky a výší plateb, i když schéma
modelu toto naznačuje. Toto je způsobeno skutečností, že měsíční platby jsou každý měsíc
pevně dané a nejsou závislé na bilanci půjčky. Vazba B1 je proto v tomto schématu potlačena.
Vazba R1, o které jsme již hovořili, je klíčovou částí celé simulace. Toto je modelováno
použitím "úrovně" a toku a ve svém důsledku jde o poměrně jednoduchou strukturu.
Zbývající proměnné a toky jsou pouze "pomocné proměnné" na výpočet čísel, co budou
prezentována uživateli.
obr. 48 Grafické zpracování modelu
Simulace zásob
Tento jednoduchý model ilustruje některé z příčin (a rovněž navrhuje řešení) oscilace
množství komodit při řízení zásob. Jednou z možností jak otestovat stabilitu modelu, je
sledovat jeho reakci na podněty. Jsou zde použity určité časové funkce Powersim Studia na
stimulaci tohoto jednoduchého modelu zásob - se zajímavými výsledky. Přesněji řečeno,
vytváření vnějších rušivých vlivů prostřednictvím časových funkcí STEP, RAMP, PULSE
a SINWAVE produkuje různé oscilace v jinak stabilním (rovnovážném) systému.
111
obr. 49 Výstup případové studie
Schéma příčin a následků ukazuje vazby mezi procesy, které ovlivňují akumulaci zásob.
Schéma zahrnuje dvě pozitivní (posilující) a dvě negativní (vyrovnávací) vazby.
obr. 50 Schéma příčin a následků
112
Z ilustrace můžeme vidět, že se model velmi podobá schématu příčin a následků. Proměnná
Inventory je modelována pomocí "úrovně". Důležité jsou rovněž toky "Orders Received"
a "Shipment". Zbytek proměnných ze schématu příčin a následků je implementováno jako
"příslušenství".
obr. 51 Grafické zpracování modelu
Simulace životního cyklu výrobku
Modelovat životní cyklus výrobku, zvláště když vyrábíme rozmanité produkty, které mají tu
vlastnost, že si navzájem ubírají tržní podíl a odbyt, je možná jednou z nejtěžších zkoušek
manažera. Tuto simulaci je lepší provádět rozvětvením na několik tzv. "co-kdyby" scénářů,
kvůli lepšímu pochopení dynamiky a neodmyslitelných zpoždění v životních cyklech
produktů.
113
obr. 52 Výstup případové studie
Schéma příčin a následků ukazuje vazby mezi procesy, které udávají tzv. adaptační rychlost,
ovlivněnou placenou reklamou a známostí produktu. Schéma zahrnuje jednu posilující a jednu
vyrovnávací vazbu.
R1 je pozitivní vazba, ovlivňující rychlost adaptace díky známosti produktu.
B1 je vyrovnávací vazba, ovlivňující rychlost adaptace díky zákazníkům, kteří daný produkt
neužívají.
obr. 53 Schéma příčin a následků
114
Vazby R1 a B1 můžeme najít v celkovém modelu, odkud můžeme vyčíst vztahy mezi
rychlostí adaptace, známostí produktu a skupinami zákazníků, kteří užívají resp. neužívají
daný produkt.
obr. 54 Grafické zpracování modelu
Simulace nárůstu populace
Jsou známy nespočetné příklady měst a společenství, které prožívaly zlatý věk růstu a vývoje
ale poté pak prošly obdobím stagnace a rozkladu. Ačkoli k této stagnaci přispívají početné
faktory, jedním z důležitých faktorů je poptávka a nabídka bydlení. Toto je analyzováno tímto
modelem.
Tato simulace dokládá, že model může být rozčleněn na různé oblasti, kde každá oblast je
modelována v odděleném schématu. Také ukazuje, jak používat oba typy jednotek, základní
a odvozené.
115
obr. 55 Výstup případové studie
Schéma příčin a následků oblasti populace
Toto schéma ukazuje vazby mezi procesy, které určují počet obyvatel. Schéma obsahuje
dvě pozitivní a tři vyrovnávací vazby.
obr. 56 Schéma příčin a následků číslo 1
116
Schéma příčin a následků oblasti bydlení
Toto schéma ukazuje vazby mezi procesy, které ovlivňují počet obydlí. Schéma obsahuje
jednu pozitivní a tři vyrovnávací vazby.
obr. 57 Schéma příčin a následků číslo 2
Model je, jak již bylo dříve zmíněno, rozdělený na dvě oblasti. Každá z těchto oblastí je
znázorněna v odděleném schématu.
obr. 58 Grafické zpracování modelu číslo 1
117
obr. 59 Grafické zpracování modelu číslo 2
118
13. Zhodnocení výsledků práce
Provedený návrh autorizačního systému nám dává ucelenou představu o základních
postupech, kterými jsou jednotlivé metodiky realizovány. Je zřejmé, že celý proces návrhu
iteruje mezi jednotlivými body postupu, které se vzájemně všelijak ovlivňují, doplňují nebo
naopak omezují, takže je nutno se občas vrátit k předchozímu bodu postupu a již provedený
výstup inovovat v rámci nových požadavků, vylepšení a kolizí. Celkově se dá říci, že proces
návrhu je činnost odpovědná a náročná na čas. Výstup jednotlivých fází návrhů pro nás může
být důležitý i budoucnu, pokud se např. rozhodneme již navrhnutý systém aktualizovat.
V úplně první fází návrhu je pak především nutno zajistit koordinaci a zpětnou vazbu směrem
k organizaci, pro kterou tento návrh vytváříme. Jen tak můžeme zajistit naprostou shodu mezi
požadavky a cílovým řešením. Při návrhu je někdy dobré datovou strukturu popsat
v samostatném bodu postupu (pokud je navrhovaný systém takového charakteru, že
databázové prvky v něm hrají dominantní roli). Zde navrhovaný systém takový charakter
neměl – i když se jednalo o středně složitý systém, odsluhoval pouze pár tabulek a úplně tak
postačovala provedená analýza k nastínění datové struktury (výpis a popis používaných
tabulek ve dvou krocích, jejich hierarchizace a zobrazení relačním schématem). Pokud
bychom v tomto případě postupovali podrobněji, výsledný návrh by to nijak neovlivnilo. Po
implementaci systému, provozujeme tento nějakou určenou dobu v testovacím režimu, který
má za úkol odhalit chyby. V tomto režimu používání platí přísnější pravidla např. pro
zálohování dat apod. V našem případě činila testovací doba 14 dní a během této doby nebyly
objeveny žádné podstatné vady systému.
Pokud se týká popsaného programového vybavení, jedná se o velmi silné nástroje v dané
oblasti, které nám mohou uspořit spoustu času. Poslední verze programů již samozřejmě
podporují systémy na bázi Windows NT (tedy konkrétně Windows NT4, Windows 2000,
Windows XP a Windows NET). Všechny programy byly provozovány na testovací sestavě:
Athlon XP 1700+, 512MB RAM DDR 266MHz, 80+60GB HDD, OS Windows XP Prof.. Při
tomto provozu nedošlo k žádné neočekávané události.
Na závěr je tedy možno shrnout, že v této práci byl vypracován komplexní návrh
informačního systému pro konkrétního zadavatele a rovněž ucelený teoretický popis
používaných metodik. Tento systém pak byl v poměrně krátké době implementován, což lze
interpretovat jako přímý praktický dopad této práce. Pro podrobnější rozbor přínosu této
práce, je autorem přiloženo vyjádření zadavatele (jakožto odborníka z praxe), které je
nedílnou součástí této práce. Zadavatel v něm hodnotí celkový přínos, kvalitu návrhu
i pozdější rychlost implementace. Pokud se týká teoretické části, tak se tato práce má šanci
stát určitým vodítkem pro proces návrhu projektů obdobného typu. Je totiž zcela zřejmé, že
pokud jsou uvedené metodiky a postupy dodržovány, lze pak vlastní návrh provádět mnohem
efektivněji.
119
14. Užitá literatura
[1] Kritické faktory úspěchu informačního systému
J. Voříšek
[2] Informační služby v počítačových sítích
P. Bureš a kol.
[3] Strategie v informačních systémech
J. Voříšek, J. Pour
[4] Vytváříme relační databázové aplikace
R. M. Riordan
[5] Projektování datové základny
J. Gregor, V. Chvalovský
[6] Metody projektování distribuce v informačním systému
S. Horný, J. Jandoš
[7] Technologie zpracování dat
S. Horný, J. Jandoš, Z. Šedivá
[8] Informační a procesní analýza organizací
S. Horný, J. Jandoš
[9] Ochrana a zabezpečení procesu zpracování dat
S. Horný
[10] Object-Oriented Analysis
P. Coad, E. Yourdon
[11] Object-Oriented Design
P. Coad, E. Yourdon
[12] Objektově orientované metodiky a technologie
P. Drbal
[13] Computer-Aided Software Engineering
C. Gane
[14] Metainformační systém
V. Kopřiva
[15] SQL – Kompletní kapesní průvodce
M. Šimůnek
[16] Počítačové databáze
J. Pokorný
120
[17] Informační technologie
J. Pokorný
[18] Systémová integrace v praxi
J. Ryška, D. Konvička
[19] Projektování informačních systémů
S. Adamec, S. Horný, A. Rosický
[20] Základy analýzy a syntézy v ASŘ
J. Vlček
[21] Interaktivní systémy
J. Voříšek
[22] Informační technologie a systémová integrace
J. Voříšek
[23] Podnikové informační systémy
J. Basl
Download

diplomová práce s názvem - Ing. Milan Beneš, Ph.D.