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
