Use Case Diagram

Use case diagram se používá pro identifikování prvků a procesů, které formují systém. Primární prvky nazýváme:

• Use case – případ užití (funkce systému)

• Actors – účastníci (pracují se systémem)

• Relationship – vztahy (vazby mezi jednotlivými use case)

• Associations – asociace (vazby mezi actors a use case)

Diagram ukazuje, kteří actors (postavičky v diagramu) spolupracují s definovanými use case (ovály v diagramu) viz obr 3.17.

Obr. 3.17 Actor, association, use case

Dále nám vymezují hranice mezi systémem a okolím a jeho použití z pohledu uživatele.

Hranice systému jsou reprezentovány obdélníkem, do kterého se vkládají případy užití.

Případy užití související s daným systémem mohou být propojeny s účastníky, kteří systém ovlivňují zvenku (vkládají data, získávají data) viz obrázek 3.18. V Use case

diagramu lze nalézt jistou analogii s DFD nejvyšší úrovně.

Obr. 3.18 Use case diagram pro restaurace

Mezi případy použití mohou existovat vztahy (relationship):

• Include

• Extend

• Generalization

V první formě interakce zahrnuje (include) jeden případ použití druhý. Tato forma se reprezentuje pomocí čerchované šipky se stereotypem include. Ta směřuje k zahrnovanému případu použití.

Extend znamená v překladu rozšiřuje. Jeden případ použití rozšiřuje druhý.

Příklad může být následující. Pokud si student registruje předmět a zjistí, že je plně obsazen je nezbytné mu umožnit nahlédnout na jiné předměty. Use case Poskytnutí informací o předmětu rozšiřuje Use case Registrace. V modelu je to zobrazeno pomocí čerchované čáry se stereotypem extend.

Generalization je zevšeobecnění. Užívá se pro vztahy, kdy jeden případ použití je specializovanějším případem druhého. Kreslí se plnou čarou zakončenou nevyplněným trojúhelníkem (šipkou). Šipka směřuje od specializovaného k obecnějšímu případu použití.

Jednotlivé vztahy mezi use case jsou vymodelovány na obrázku 3.19.

Obr. 3.19 Relationships 3.3.3.2. Class Diagram

Pro konceptuální modelování databáze je důležitý Class Diagram. Modeluje entitní typy jako třídy, vazby jako asociace a vlastnosti objektů jako atributy. Třídy kreslíme jako obdélník rozdělený na tři části. V první části obdélníku deklarujeme název třídy a stereotyp. Stereotyp nám umožňuje lépe popsat význam třídy. Pokud se jedná o třídu, která bude uložena v SŘBD, používá se stereotyp table. Do druhé části obdélníku zaznamenáváme atributy třídy a do poslední metody (funkce), které je možné vykonávat nad třídou.

Každý atribut je specifikován pomocí pěti obecných vlastností:

• stereotype – význam atributu

• visibility – (používá + pro public, # pro protected, - pro private)

• atribute name – jméno atributu

• multiplicity – označuje vícehodnotový atribut

• / – označuje odvozený atribut

Každá metoda je specifikována pomocí pěti obecných vlastností:

• stereotype – význam metody

• visibility – stejné jako u atributu

• parameters – seznam parametrů oddělený tečkami

• methodName – název metody

• returnType – návratová hodnota metody

UML neobsahuje označení pro klíčový atribut, proto se tento nedostatek řeší pomocí poznámek. Poznámky se dají využívat pro přesnější a výstižnější popsání.

Příklad vymodelované třídy je na obrázku 3.20.

Obr. 3.20 Model třídy v UML

Vazby v UML nazýváme asociace a značíme je hranou mezi třídami. Asociace je definována názvem rolí a násobností. Násobnost nám udává, kolik instancí jedné třídy je ve vztahu s instancí druhé třídy. Příklad asociace dvou tříd je na obrázku 3.21.

Obr. 3.21 Asociace dvou tříd

V UML se dají použít tři jedinečné asociace – agregace, kompozice a generalizace. Generalizace je typ vztahu, kdy jedna třída je zobecněním vlastností jiné třídy. Kompozice je silnější druh agregace. Část zaniká zároveň s celkem a je závislá pouze na jednom celku.

Pro modelování databází je nejdůležitější asociace agregace. Agregaci se někdy říká skládá se z. Jedna třída má funkci celku a její instance se skládá z více instancí druhé třídy. Agregace se označuje vyplněným kosodélníkem na straně celku, viz obrázek 3.22.

Obr. 3.22 Agregace

Pro speciální případy asociace v databázích se používá typicky objektová vlastnost a tou je dědičnost. Jelikož je konceptuální model nezávislý na SŘBD, lze tuto čistě objektovou vlastnost použít i v relačním modelu. Podtřída dědí atributy i metody.

Příklad je na obrázku 3.23.

Obr. 3.23 Dědičnost

3.3.3.3. Deployment Diagram

Deployment diagram, nebo-li diagram nasazení, je poslední z nezbytných diagramů pro tvorbu databázového informačního systému. Hlavním přínosem deployment diagramu je, že popisuje fyzické rozmístění elementů systému. Zobrazuje skutečné vztahy mezi částmi systému po jeho spuštění (fyzická architektura systému).

Jednotlivé SW komponenty se zobrazují na HW zdrojích (výpočetní uzly) a pomocí hran (většinou síťové spojení) se naznačuje jejich vzájemná spolupráce. Dále se dá vymodelovat topologie sítě nebo použitý protokol pro komunikaci.

Hlavní prvky tohoto diagramu jsou uzly. Mohou být dvojího druhu:

• zařízení – fyzické zařízení pro zpracování dat, jako jsou mobilní telefony, PC, servery..

• EEN – SW jednotka, která běží na fyzickém zařízení (uzlu), poskytuje služby dalším SW elementům, na jednom fyzickém uzlu může být spuštěno více EEN, příkladem EEN jsou:

¾ Virtual Machine

¾ Operační systém (windows, linux, unix..)

¾ Web browser

¾ DB stroj

¾ Servlet container

¾ Workflow engine

Příklad jednoduchého deployment diagramu je obrázek 3.24.

Obr. 3.24 Deployment diagram 3.3.4. XML

V oblasti zpracování textu bylo potřeba označit význam jednotlivých částí. Proto v 80. letech byl standardizován jazyk GML. Pravděpodobně první značkovací jazyk vůbec, který vytvořili pánové Goldfarb, Mosher, Lorie. V roce 1986 se z GML vytvořil nový značkovací jazyk SGML. Umožňoval definici vlastních značkovacích jazyků (sad značek) pomocí DTD. Asi nejznámější aplikací SGML je jazyk používaný pro tvorbu webových stránek HTML. Nevýhodou SGML je přílišná komplexnost a tudíž obtížná implementace. Proto se vzala nejdůležitější a nejvíce používaná podmožina SGML a vytvořil se nový jazyk XML.

XML je značkovací jazyk vyvinutý konsorciem W3C. Na rozdíl od SGML jsou délka názvů značek, použité oddělovače a speciální znaky předem definované a nelze je měnit. Lepší označení pro XML je metajazyk, neboť pomocí DTD lze vytvářet vlastní jazyk s vlastními značkami. Takto vznikl například XHTML – kombinace HTML a XML.

XML se dnes používá pro snadnou výměnu informací. Obecně se dá říci, že slouží pro popis dat. Tudíž ho lze využít i pro strukturovaný popis dat uvnitř databáze.

Komunikace je nezávislá na platformě a aplikaci. Další výhodou je podpora všech světových jazyků, malá velikost dokumentu a jednoduchý převod na jiné formáty.

Každý XML dokument se skládá z elementů a těm zase náleží atributy. Element má své jméno a je uvozen mezi počáteční značku (start tag) a koncovou značku (end tag). Mezi počátečním a koncovým tagem je obsah elementu. Příklad je na obrázku 3.25.

Obr. 3.25 XML dokument

Příklad na obrázku 3.25 se skládá z jednoho elementu books a dvou podelementů book. Element book obsahuje dva dětské elementy title, author a atribut id.

Na rozdíl od relačního datového modelu se v XML rozlišuje pořadí elementů.

Obsah tabulky z relační databáze popsaný pomocí XML je na obrázku 3.26.

Obr. 3.26 Zobrazení databázových dat pomocí XML

3.3.4.1. DOM

Rozhraní DOM slouží pro schématické zobrazení XML dat. Dokument je zobrazen v hierarchicky stromové struktuře. Každému elementu, podelementu i atributu ve schématu odpovídá jeden uzel. Vztah mezi nimi zobrazujeme hranou, viz obrázek 3.27.

Obr. 3.27 Stromové schéma XML dokumentu z obrázku 3.25 3.4. SQL

Prvopočátky jazyka SQL spadají do roku 1974. V tomto roce uveřejnil své revoluční myšlenky o relačním databázovém modelu Dr. Codd. První prototypová implementace se jmenoval SEQUEL a vznikla v laboratoři IBM v San Jose v Kalifornii.

Postupně si většina firem, zabývajících se databázovými informačními systémy (Oracle, SyBase, Informix..), uvědomila obrovský přínos standardizovaného jazyka pro správu databáze a přidaly se k vývoji. Tak vznikl „nepsaný standard“ databázového jazyka SQL. V roce 1986 přijímá SQL jako standard organizace ANSI a o rok později ISO.

Tato verze se nazývá podle roku přijetí SQL86. Rozšířená verze o možnost definovat integritní omezení se nazývá SQL89. V roce 1992 přišla verze SQL2/SQL92, která nabízela například lepší podporu transakcí. Jeden z posledních standardů je SQL3, který je objektově orientovaný (1996). Jazyk SQL je implementován v řadě komerčních SŘBD (obvykle na úrovní SQL92).

SQL je více než dotazovací jazyk. Umožňuje definovat data a uživatelská práva přístupu k relacím. Dále nabízí možnost tvorby pohledů (virtuální relace). Pro rychlejší přístup k prvkům relací při zpracování uživatelského požadavku nabízí možnost tvorby

indexů. Od verze SQL89 definovat integritní omezení. Dále je to řízení transakcí (příkazy pro začátek a konec transakce) od verze SQL2/SQL92.

SQL se v relačních SŘBD vyskytuje obvykle ve dvou verzích současně – interakční a hostitelská. V interakční verzi se dají používat příkazy samostatně v režimu online - pomocí příkazového řádku (psaní SQL dotazů) nebo grafického nástroje, který umožní vytvářet dotazy pomocí grafických ovládacích prvků. V hostitelské verzi se příkazy SQL stávají součástí hostitelského jazyka, jako například Java, Delphi, C++

apod. To znamená naprogramovat GUI pro předem definované úkony. Cílovému uživateli neumožním vytvářet dotazy do databáze, ale umožním mu používat před-programované funkce, které ke své práci bude potřebovat. V hostitelské verzi je nutné vhodně realizovat vazby mezi proměnnými programovacího jazyka a výsledky dotazů v SQL. Dotazy jsou součástí zdrojového kódu programu, proto je nutné je oddělit od ostatních příkazů daného jazyka.

Jazyk SQL můžeme rozdělit na dvě základní podmnožiny DDL, DML [9]. DDL umožňuje vytvářet, rušit nebo měnit struktury objektů (tabulky, indexy, pohledy..) v databázi. Příklady příkazů spadajících do skupiny DDL jsou CREATE TABLE, CREATE DATABASE, DROP TABLE, CREATE VIEW...

Pro manipulace s daty je důležitá podmnožina DML, která obsahuje 4 základní příkazy:

• Select

• Insert

• Update

• Delete

Kromě těchto dvou hlavních podmnožin můžeme některé příkazy jazyka SQL zařadit do podmnožiny řídících příkazů DCL [9]. Podmnožina DCL obsahuje speciální příkazy pro řízení provozu a údržbu databáze, jako je např. CREATE USER, GRANT, REVOKE...

Podmnožina příkazů pro řízení transakcí TCC [9].TCC je určená pro řízení

transakcí např. SET TRANSACTION, COMMIT, SAVEPOINT...

Standardní SQL podporuje koncepci transakce v rámci hostitelského jazyka.

Transakce je definována jako posloupnost příkazů SQL formující jednotku zotavení z chyb a souběžného zpracování. Transakce jsou implicitní v tom smyslu, že první příkaz SQL znamená počátek transakce. Každá transakce končí vyvoláním bud' příkazu COMMIT WORK (potvrzuje platnost transakce) nebo ROLLBACK WORK (zruší všechny změny, které dosud v průběhu transakce proběhly). Příkladem transakce je převod finanční částky z jednoho účtu na druhý.

Hlavním omezením jazyka SQL je fakt, že se jedná o neprocedurální jazyk.

Příkazy jsou zpracovány sekvenčně bez použití klasických programátorských konstrukcí jako jsou cykly, podmínky, funkce a procedury. Proto každý moderní SŘBD obsahuje implementaci procedurálního rozšíření jazyka SQL. Příkladem je platforma Oracle, která implementuje procedurální jazyk PL/SQL nebo Microsoft SQL Server 2000 nabízí Transact SQL (T-SQL).

4. Vlastní návrh IS

Zadáním naší práce bylo vytvořit databázový informační systém pro podporu procesu neustálého zlepšování. Tento úkol se skládal z několika částí. V první řadě to bylo vytvořit datový a funkční model. Dále vytvořit databázi a naprogramovat grafické uživatelské rozhraní. Tyto vyjmenované kroky budou postupně, jak zde byly uvedeny, popsány v následujících kapitolách.

Pro vymodelování naší databáze jsme vybrali nástroj CASE Studio 2.23.1 Tento SW nabízí nejenom tvorbu datového modelu ERD, ale také funkčního modelu DFD.

Pro tvorbu databáze jsme si vybrali databázový systém Oracle 10g Express Edition. A pro tvorbu uživatelského rozhraní Java 2 Platform Standard Edition Development Kit 6.0 a NetBeans IDE 5.5 vývojové prostředí.

Před vlastní tvorbou modelů bylo nutné absolvovat několik pohovorů, které nám pomohly určit předběžný seznam atributů a typů entit. Dále určit operace, které se budou provádět s daty a kdo s nimi bude pracovat. Návod na korektní vedení takovýchto pohovorů je popsán v kapitole 3.2.

4.1. ERD

Tvorba ER modelu byla podrobně popsána v kapitole 3.3.1.1. Proto se nebudeme více věnovat teoretickému popisu ERD a raději popíšeme námi navržené schéma.

V prvé řadě jsme museli zvolit metodologii logického návrhu databáze.

Nejvhodnější se nám zdála metodologie uvedená v kapitole 3.3.1 strana 24 obrázek 3.2.

Pro tvorbu konceptuálního schématu jsme zvolili strategii zdola nahoru.

Pomocí této strategie jsme získali 21 entitních typů. Konkrétně to jsou: ZAVOD, PROVOZ, HALA, LINKA, USEK, TAKT, PRACOVISTE, OPERACE, VSTUP, WS, SCHUZKA, CLEN_WS, CLEN, SEF, POVERENI, PROBLEM, OPATRENI, PREDP_USPORA, NASAZENI, ZAMESTNANEC, USPORA.

Mezi nově vzniklými entitními typy jsme museli najít typy vztahů, určit jejich IO a zvolit identifikační klíče. Pro větší přehlednost jsme celkové schéma rozdělili na 3 části. Hlavní část našeho schématu je vidět na obrázku 4.1. Ukazuje nejdůležitější aspekty pro proces neustálého zlepšování. Na každou operaci bude udělán minimálně jeden workshop. Členové týmu budou odhalovat problémy, které jsou potřeba odstranit z průběhu operace, na pracovních schůzkách.

Obr. 4.1 Hlavní část KVP schématu

Mezi jednotlivými entitními typy jsme nalezli typy vztahů. Například u dvojice OPERACE a WS to je typ vztahu ZLEPSUJE, kardinalita vztahu 1:N, povinný typ účasti na obou stranách. Dále je patrné, že oba entitní typy jsou regulární (silné). Další typ vztahu je NALEZA mezi entitními typy WS a PROBLEM. Je zde opět kardinalita 1:N. Členství ve vztahu entitního typu WS je volitelné a entitního typu PROBLEM je povinné. Důvod je prostý, mohou se objevovat operace, které nebudou potřebovat vylepšovat (nemají žádný problém), ale k takovému závěru lze dojít až na základě workshopu (WS). Opět jsou oba entitní typy regulární. V další části našeho výseku jsou dva vztahové typy (JE, MA) a tři entitní typy (WS, CLEN_WS, CLEN). Ve skutečnosti to jsou pouze dva entitní typy s kardinalitou M:N. V konceptuálním schématu se kardinality M:N dvou entitních typů dekomponují pomocí vazební entity (CLEN_WS) na dva vztahy typu 1:N. Entitní typ SEF je svázán s entitním typem CLEN s kardinalitou 1:N. V našem případě nelze použít self-relaci, neboť u členů týmu musíme uchovávat více informací (role, důležitost) než u jeho nadřízeného. V entitním typu SEF jsou uloženy pouze základní informace o nadřízeném člena workshopu, a to z důvodu, že nadřízený by měl uvolnit člena týmu v termínech, kdy probíhá workshop.

Do entitního typu POVERENI může jakýkoliv člen týmu zadat informace o člověku, který převezme jeho roli. Entitní typ POVERENY je svázán s vazební entitou CLEN_WS, aby bylo možné pověřovat lidi dle výběru člena týmu bez jakýchkoli omezení. Na hlavním výseku KVP schématu je typ vztahu VSTUPUJE mezi entitními typy OPERACE a VSTUP s kardinalitou 1:1. Zde se ukládají informace o materiálu, nářadí, normě obsluhy.. , které vstupují do operace.

Druhou část schématu lze nazvat identifikační, protože přesně určuje a popisuje konkrétní operaci, viz obrázek 4.2.

Obr. 4.2 Identifikační část KVP schématu

V této části schématu je uložena hierarchie fabriky. V jednotlivých entitách jsou uloženy informace potřebné pro průběh workshopu. Například na jakém pracovišti je prováděna operace, kdo ji provádí, kde je pracoviště umístěno a kdo je zde mistrem..

Zajímavostí je entitní typ PROVOZ, který je oproti ostatním slabý. Mezi entitním typem ZÁVOD a PROVOZ je identifikační typ vztahu. Identifikační klíč entitního typu ZÁVOD se stává částí identifikačního klíče entitního typu PROVOZ.

Poslední část schématu lze nazvat zlepšování. Zde jsou uloženy poznatky, které pomohou zdokonalit operaci. Tato část schématu je na obrázku 4.3.

Obr. 4.3 Část zlepšování ze schématu KVP

Na obrázku 4.3 je vidět průběh workshopu. Nejprve jsou určovány problémy a poté je navrženo opatření. Mezi entitním typem PROBLEM a OPATRENI je kardinalita 1:N, jelikož může existovat více řešení, která mohou vést k odstranění problému. U každého opatření je nezbytné definovat předpokládanou úsporu. Opatření má pouze jednu předpokládanou úsporu, proto kardinalita 1:1. Je nezbytné tuto předpokládanou úsporu vyčíslit, proto je účast ve vztahu povinná. Následně se vybere to nejlepší opatření (většinou největší předpokládaná úspora) a to je nasazeno. Tím je pověřen odpovědný zaměstnanec nebo více zaměstnanců, v závislosti na složitosti nasazení. Po jisté době, kdy je opatření využíváno, je vyhodnocena reálná úspora. Vyhodnocením úspory končí workshop a tým se již nadále neschází.

4.2. DFD

Stejně jako ERD i teorie DFD byla podrobně vysvětlena v kapitole 3.3.2.2.

Tudíž se jí nebudeme více věnovat.

Pro tvorbu DFD jsme zvolili strategii shora dolů. Na nejvyšší úrovni našeho modelu je hlavní proces KVP. Jelikož jsme zvolili strategii shora dolů, budeme tento proces dále zjemňovat. Postupnou dekompozicí rozložíme náš hlavní proces na pod-procesy. Procesy jsou značeny oválem s názvem uvnitř. Jednotlivé procesy se propojují datovými toky (šipky) v pořadí v jakém se reálně vykonávají. Dále musíme propojovat procesy s data story (dvě plné čáry s názvem uprostřed), abychom vymodelovali ukládání a načítání dat. Pokud šipka datového toku směřuje k data store, jedná se o ukládání dat. Pokud směřuje od data store k procesu, jedná se o načítání dat. Poslední prvek v našem modelu je vstupně/výstupní rozhraní (obdélníky s názvem uvnitř).

Obr. 4.4 Kontextový diagram

Diagramu na nejvyšší úrovni se říká kontextový. Na obrázku 4.4 je zobrazen náš kontextový diagram. Zde je vidět hlavní proces s názvem KVP. Tento proces ovlivňuje (zadává a načítá data) několik vstupně/výstupních rozhraní. Hlavní úlohu zaujímá klíčový uživatel s názvem ADMIN_KVP, který nezasahuje přímo do průběhu procesu neustálého zlepšování. Spravuje jednotlivé uživatele a přiděluje jim požadovaně role.

Také může upravovat všechny tabulky ve schématu KVP. Ostatní vstupně/výstupní rozhraní budou popsány v následujících odstavcích.

Dekompozicí procesu KVP nám vzniklo 8 procesů: OVERENI HESLA A ID, SPUSTENI APLIKACE A PRIPOJENI SE K DATABAZI, SPRAVA UZIVATELU, SPRAVA SCHEMATU, ZALOZENI WS, EDITACE WS (PROCES ZLEPSOVANI), POSKYTNUTI PRAV, PROHLIZENI WS.

Do prvního procesu OVERENI HESLA A ID nám vstupuje rozhraní s názvem ZAMESTNANEC FIRMY SKODA a data store s názvem USER_SYS. USER_SYS je systémová tabulka, v které jsou uchovávána data o uživatelích (heslo a uživatelské jméno). Heslo a uživatelské jméno je porovnáno s daty načtenými ze systémové tabulky USER_SYS. Na obrázku 4.5 je vidět průběh ověření.

Pokud je heslo a uživatelské jméno zadáno správně, je spuštěna aplikace a naváže se spojení s databází. Každý uživatel kromě ADMINA_KVP (ten má veškerá objektová oprávnění na celé schéma KVP) má přidělenou jistou roli, podle toho jaká má objektová oprávnění. Konkrétně to jsou MODERATOR, CO-MODERATOR, CLEN_WS, UZIVATEL. Na následujícím obrázku budou zobrazeny jako rozhraní. Na obrázku 4.5 je vidět, že nejvíce objektových oprávnění má klíčový uživatel ADMIN_KVP a role MODERATOR a CO-MODERATOR.

Jak bylo uvedeno výše ADMIN_KVP nezasahuje přímo do procesu neustálého zlepšování. Pouze vytváří nové účty uživatelům systému, ruší uživatele, přiděluje, odebírá role a mění hesla. Tuto činnost reprezentuje proces s názvem SPRAVA UZIVATELU na obrázku 4.5. Veškerá objektová oprávnění na celé schéma KVP má z důvodu řešení možných chyb způsobených uživateli. Nápravu těchto chyb symbolizuje proces s názvem SPRAVA SCHEMATU viz obrázek 4.5.

Obr. 4.5 Průběh KVP

Pouze uživatelé s rolí MODERATOR nebo CO-MODERATOR mají právo založit workshop. Proces ZALOZENI WS se dále dělí na dílčí pod-procesy (IDENTIFIKACE WS, URCENI TYMU A SCHUZEK). Po založení workshopu následuje fáze zlepšování. Reprezentuje ji proces EDITACE WS (PROCES ZLEPSOVANI). Tento proces se opět dále dělí na dílčí pod-procesy např.

STANOVENI OPATRENI, STANOVENI NASAZENI, VYHODNOCENI WS… Do této fáze zasahují i uživatelé s rolí CLEN_WS. Proces POSKYTNUTI PRAV slouží pro uložení informací o uživateli, který převezme plnění úkolů po členovi workshopu. Data jsou uložena v data storu s názvem POVERENI. Poslední část je reprezentována procesem PROHLIZENI WS. Zde dochází k získávání a porovnávání dat ze všech data storů (entit) v našem schématu KVP. Prohlížet vytvořené workshopy mohou všechny tři

STANOVENI OPATRENI, STANOVENI NASAZENI, VYHODNOCENI WS… Do této fáze zasahují i uživatelé s rolí CLEN_WS. Proces POSKYTNUTI PRAV slouží pro uložení informací o uživateli, který převezme plnění úkolů po členovi workshopu. Data jsou uložena v data storu s názvem POVERENI. Poslední část je reprezentována procesem PROHLIZENI WS. Zde dochází k získávání a porovnávání dat ze všech data storů (entit) v našem schématu KVP. Prohlížet vytvořené workshopy mohou všechny tři