TECHNICKÁ UNIVERZITA V LIBERCI
Fakulta mechatroniky a mezioborových inženýrských studií
Studijní program: M2612 – Elektrotechnika a informatika Studijní obor: Automatické řízení a inženýrská informatika
Srovnání objektové a strukturální analýzy pro tvorbu a návrh informačních databázových
systémů
Comparison of object and structural analysis for design and development of database
systems
Diplomová práce
Autor: Vladislav Selinger
Vedoucí práce: RNDr. Klára Císařová
V Liberci 19. 5. 2006
Prohlášení
Byl jsem seznámen s tím, že na mou diplomovou práci se plně vztahuje zákon č. 121/2000 o právu autorském, zejména § 60 (školní dílo).
Beru na vědomí, že TUL má právo na uzavření licenční smlouvy o užití mé diplomové práce a prohlašuji, že souhlasím s případným užitím mé diplomové práce (prodej, zapůjčení apod.).
Jsem si vědom toho, že užít své diplomové práce či poskytnout licenci k jejímu využití mohu jen se souhlasem TUL, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených univerzitou na vytvoření díla (až do jejich skutečné výše).
Diplomovou práci jsem vypracoval samostatně s použitím uvedené literatury a na základě konzultací s vedoucím diplomové práce a konzultantem.
Datum: 19. 5. 2006
Podpis: ……….
Poděkování
Rád bych na tomto místě poděkoval vedoucí mé diplomové práce paní RNDr.
Kláře Císařové za odborné vedení, profesionální přístup a trpělivost během tvorby mé diplomové práce.
Anotace
Cílem této diplomové práce bylo porovnání strukturální a objektové analýzy pro návrh informačních databázových systémů (IDBS).
Byly prostudovány současné trendy v této problematice a zvláštní důraz byl kladen na konceptuální modelování na bázi jazyka UML.
Dále byly porovnány CASE systémy, které jsou založeny na jednotlivých metodách analýzy. Jako zástupce CASE systémů založených na strukturální analýze byl vybrán software CASE Studio. Jako zástupce CASE systémů s podporou objektové analýzy byl zvolen software Enterprise Architect.
Srovnání modelů a jejich vlivu na implementaci bylo provedeno na konkrétním IDBS. Jednalo se o realizaci kompletního softwarového řešení pro Oblastní charitu v Ústí nad Orlicí, která provozuje regionální půjčovnu zdravotnických a kompenzačních pomůcek pro tělesně postižené.
Abstract
The aim of this diploma thesis was to compare object and structural analysis for design and development of database systems.
The current trends were studied and much emphasis was placed on conceptual modeling based on Unified Modeling Language (UML).
CASE systems based on different methods of analysis were compared. CASE studio was chosen as an example of structural analysis method and Enterprise Architect software as an example of object analysis method.
The comparison of the models and their influence of implementation was performed on particular Information Database System. The complex software solution was realized for regional charity of Ústí nad Orlicí – regional lending office of sanitary
Zusammenfassung
Ziel dieser Diplomarbeit war es die Strukturanalyse mit der Objektanalyse bei der Projektierung der Informationsdatenbanksysteme zu vergleichen.
Es wurden derzeitige Trends in dieser Problematik durchstudiert und besondere Aufmerksamkeit wurde der Konzeptmodellierung auf der Basis von UML gewidmet.
Es wurden CASE Systeme vergleicht, die auf den einzelnen Analysemethoden basieren. Als Vertreter der CASE Systeme auf der Basis der Strukturanalyse wurde die Software CASE Studio ausgewählt und als Vertreter der Objektanalyse wurde die Software Enterprise Architect gewählt.
Der Vergleich der Modele und ihrer Auswirkung auf die Implementierung wurde auf einem konkreten Softwaresystem durchgeführt. Es handelte sich um die Realisation eines Datensystems für den Regionalcaritasverband in Ústí nad Orlicí, der ein Lokalverleih von Gesundheits- und Kompensationshilfsmitteln für Körperbehinderte betreibt.
Obsah
1. Úvod... 10
2. Informační databázové systémy... 11
2.1. Informační systém... 11
2.2. Databáze... 12
2.3. Relační model ... 12
2.4. Současné trendy ... 13
3. Modelování IDBS ... 14
3.1. Konceptuální modelování ... 14
3.2. Strukturální analýza... 15
3.3. Objektová analýza ... 16
3.4. Porovnání ... 17
4. UML: ... 18
4.1. Hierarchie procesů ... 19
4.2. Případy užití ... 19
4.3. Diagram aktivit... 21
4.4. Model tříd ... 22
5. CASE systémy: ... 23
5.1. CASE Studio ... 24
5.2. Enterprise Architect... 24
5.3. Porovnání ... 24
6. Praktický příklad ... 25
6.1. Použité prostředky ... 25
6.1.1. Delphi... 25
6.1.2. BDE ... 25
6.1.3. SQL... 26
6.2. Strukturální analýza... 27
6.3. Objektová analýza ... 29
6.3.1. Hierarchie procesů ... 29
6.3.2. Případy užití... 30
6.3.3. Diagram aktivit ... 32
6.3.4. Model tříd ... 33
6.4. Výsledné uložení dat ... 34
6.4.1. Správa Klientů: ... 34
6.4.2. Správa Půjček: ... 35
6.4.3. Správa Skladu (pomůcek): ... 36
6.5. Vlastní program... 37
6.5.1. Hlavní okno... 37
6.5.2. Klienti ... 37
6.5.3. Pomůcky ... 38
6.5.4. Půjčky ... 39
6.5.5. Přehledy ... 42
7. Závěr ... 43 8. Seznam použité literatury... 45 9. Přílohy:... 46
Seznam použitých zkratek
IDBS = Informační databázový systém IS = Informační systém
UML = Unified Modeling Language – unifikovaný modelovací jazyk
CASE = Computer Aided Software Engineering – nástroje pro analýzu a návrh CS = CASE Studio – software firmy Charonware
EA = Enterprise Architect – software firmy Sparxsystems ERD = Entity Relationship Diagram – entitě relační diagram DFD = Data Flow Diagram – diagram datových toků
SQL = Structured Query Language – strukturovaný dotazovací jazyk
1. Úvod
Databázové systémy již mají za sebou řadu let vývoje. Stěžejní pro vývoj databázových systémů byla hlavně 70. léta, kde se definovaly algoritmy, pojmy a metody, které umožnili oddělení aplikace od samotných dat. Byl tak umožněn rychlý vývoj aplikací, neboť tento přístup už nevyžadoval znalost uložení dat, či přístupu k nim.
V následujících letech mohli proto vzniknout velké softwarové firmy, které se zaměřily na vývoj databází a začaly udávat směr v tomto odvětví a určovat trendy.
Na databáze nelze pohlížet jen jako na strohá data, které program transformuje na požadované výstupy. Důležitým aspektem je také soubor metod návrhu databází, který umožňuje systematicky konstruovat databázi, dle předem daných kritérií. Vzhledem k tomu, že databáze jsou dnes součástí složitých informačních systémů, je potřeba toto zohlednit i při návrhu. Proto dnes vznikají komplexní softwarové nástroje, pomocí nichž je možné vývoj IDBS usnadnit, zpřehlednit a hlavně unifikovat.
V posledních 20 letech dominovali relační databáze. Zde bylo na data nahlíženo, jako na tabulky, které byly spolu v interakci pomocí relací. Tento přístup spolu s dobře navrženou matematickou teorií E. F. Coda pokrýval dostatečně potřeby a možnosti tehdejších IDBS.
Ovšem s rychlým rozvojem hardwaru v průběhu několika posledních let a jeho přístupnosti, se začaly databázové systémy masově prosazovat. Zároveň jsou dnes na tyto systémy kladeny stále vyšší nároky ze strany uživatelů. Proto se dnes ke slovu dostávají objektové přístupy. Tento pohled má blíže k reálnému světu, neboť člověk vnímá své okolí pomocí jednotlivých objektů, které mají své vlastnosti a komunikují se svým okolím.
Hlavní podmínkou pro dobře navržený IDBS se stává dobrá komunikace zadavatele a návrháře. Z toho důvodu dnes vznikají softwarové nástroje a postupy pro objektový přístup k návrhu a tvorbě IDBS, které toto zohledňují. Většina moderních
Náplní mé diplomové práce je porovnání staršího strukturálního přístupu s novým objektovým přístupem k analýze a návrhu IDBS. To jsem provedl jednak v obecné rovině a také na reálném příkladě. Tím bylo vytvoření kompletního softwarového řešení pro Oblastní charitu v Ústí nad Orlicí, která provozuje půjčovnu zdravotnických a kompenzačních pomůcek pro tělesně postižené. K tvorbě modelů a jejich porovnání jsem použil zástupce pomocných nástrojů, které jsem vybral po prozkoumání současné situace na trhu.
2. Informační databázové systémy
2.1. Informační systém
Informační systém lze chápat jako systém vzájemně propojených informací a procesů, které s těmito informacemi pracují. Přičemž pod pojmem procesy rozumíme funkce, které zpracovávají informace do systému vstupující a transformují je na informace ze systému vystupující. Zjednodušeně můžeme říci, že procesy jsou funkce zabezpečující sběr, přenos, uložení, zpracování a distribuci informací. Pod pojmem informace pak rozumíme data, která slouží zejména pro rozhodování a řízení v rozsáhlejším systému.
Do celkové funkce informačního systému se také promítá nezanedbatelná položka okolí. Okolí informačního systému tvoří veškeré objekty, které změnou svých vlastností ovlivňují samotný systém, a také objekty, které naopak mění své vlastnosti v závislosti na systému.
Celkově tedy můžeme říci, že dnes informační systém představuje softwarové vybavení firmy, které je schopné na základě zpracovávaných informací řídit procesy podniku nebo poskytovat tyto kvalifikované informace řídícím pracovníkům, tak aby byli schopni vykonávat řídící funkce, mezi které patří zejména plánování, koordinace a kontrola veškerých procesů firmy.
Informační systém je jedním z hlavních faktorů efektivnosti řízení podniku.
Potřeba kvalitního informačního systému roste s významem informace pro dnešní podniky.
2.2. Databáze
Databázi si lze představit jako uspořádanou kolekci dat používanou k modelování nějakého typu organizace nebo organizačního procesu. Cílem je zachytit vztahy mezi reálnými objekty.
V rámci správy databází se v zásadě používají dva typy databází: operační databáze a analytické databáze. Operační databáze jsou dnes páteří mnoha společností, organizací a institucí po celém světě. Tento typ databáze se používá především ke každodennímu sběru, změnám a správě dat. Ukládaná data jsou dynamického typu, což znamená, že se neustále mění a vždy odrážejí aktuální informace (např. obchody, nemocnice, nakladatelství).
Oproti tomu analytické databáze ukládají a sledují historická a časově závislá data. Analytická databáze je hodnotná při sledování trendů, zobrazování dlouhodobých statistik. Ukládaná data jsou statického typu, což znamená, že se tato data mění jen výjimečně (např. chemické a geologické laboratoře).
2.3. Relační model
Podle relačního modelu jsou data v relační databázi uložena v množinách typu relace, které jsou definovány relační algebrou jako podmnožina kartézského součinu konečného počtu množin. Tyto množiny můžeme chápat jako tabulky, ve kterých se nesmí vyskytovat dva stejné řádky. Toto je důsledkem matematické definice. Každý záznam je tvořen vektory souřadnic a atributy.
Tabulky jsou základními strukturami v databázi. Každá tabulka vždy představuje jediný, specifický subjekt – entitu. Logické pořadí záznamů a polí v tabulce nemá vůbec žádný význam. Každá tabulka obsahuje přinejmenším jedno pole, označované jako primární klíč, které jednoznačně identifikuje jednotlivé záznamy. V případě, že jediné pole pro tento účel nestačí, může být primární klíč tvořen několika poli. Z hlediska stability a optimalizace práce s databázemi je vhodnější v těchto případech vytvořit umělý klíč, kterým může být autoinkrementační typ, pokud to databázový systém podporuje. Tabulka může reprezentovat objekt, událost nebo představuje vazební entitu, která vzniká dekompozicí vztahu M:N mezi entitami.
2.4. Současné trendy
V současné době se začínají prosazovat objektové přístupy při návrhu IDBS. Trh se doposud objektovým technologiím vyhýbal a to z mnoha důvodů.
Za prvé to byla náročnost na systémové zdroje, která ovšem s rychlým rozvojem informačních technologií pominula. Za posledních deset let došlo k velkému pokroku ve výkonu hardwaru. Příchod víceprocesorových architektur, který dnes můžeme sledovat, nahrává objektovým technologiím.
Druhým problémem byla neochota přejít na novou technologii, pokud to není nezbytně nutné. Což je pochopitelné hlavně z finančních důvodů.
Poslední překážkou pro nástup objektových technologií byla rozšířenost malých informačních systémů, kde pro jednoduchou přehlednost nebylo zapotřebí objektového přístupu.
Jak ale situace na trhu dnes ukazuje, zákazníci zvyšují požadavky na informační systémy, tím roste i jejich náročnost z hlediska návrhu. Zároveň narostl počet firem, které se tvorbou těchto systémů zabývají. Firmy se snaží o stále komplexnějších systémy, aby obstáli v konkurenčním boji. Tento stav vede k robustnosti informačních systémů a je velmi obtížné udržet přehled při jejich návrhu.
Ve strukturální analýze, která se pro návrh informačních databázových systémů používala až do teď, je skoro nemožné udržet přehled při návrhu velkých robustních systémů. Zde se dostává ke slovu objektová analýza. Z praxe víme, že velké firmy, které udávají směr ve vývoji IDBS se začínají přeorientovávat na objektové technologie. Každý návrhář by se měl s touto technologií seznámit, protože v budoucnu se bez ní neobejde. Už dnes začínají shánět pracovní agentury pro firmy zaměstnance, kteří mají zkušenostmi s objektovým návrhem.
3. Modelování IDBS
Výsledkem modelování IDBS je databázový model, který vychází z nějakého přístupu či filozofie řešení. Jedná se o souhrn pojmů sloužících k modelování.
Databázovým modelem může být formální či matematický aparát.
Proč vlastně modelovat? Jedním z důvodů je komunikace se zákazníkem. Pouze úplné a správné pochopení požadavků zákazníka vede k realizaci dobře navrhnutého informačního systému. K tomu nám slouží standardizované postupy. Ty jsou výhodou pro snadnější komunikaci v týmu. Týmová práce je dnes nutností a to hlavně z hlediska složitosti analyzovaných systémů a procesů, které je nutné modelovat. Dalším přínosem je tvorba aktuální a kompletní dokumentace, udržení kontextu návrhu pro další kroky řešení, a to jak v návrhu, tak i v pozdější aktualizaci v průběhu životního cyklu projektu.
Bez perfektní analýzy a jejího výsledku, kterým je objektový nebo strukturální model, je to takřka nemožné.
3.1. Konceptuální modelování
Základním problémem byl popis uložených dat. Ze samotných dat většinou nelze odhadnout, jakou informaci tyto data interpretují. Proto byly počátkem 70. let zavedeny pojmy jako schéma a subschéma.
Schéma je celkový pohled na danou databázi, úplně popisuje všechny logické jednotky – entity, jejich jednotlivé části (atributy) a také příslušné vazby. Pro danou databázi existuje vždy jen jedno schéma. Bohužel výsledek je závislý na návrháři, jeho pohledu na věc a zkušenosti. Jiný autor by mohl daný problém řešit pomocí úplně jiného datového modelu.
Subschéma představuje uživatelský pohled na danou databázi. Popisuje jen položky potřebné pro daného uživatele nebo pro dané podtéma a je podmnožinou schématu. V rámci jedné databáze je počet subschémat neomezený a často je tento počet odvozený od požadované funkčnosti celého systému.
Konceptuální modelování je založené na vytvoření popisu dat, potřebných pro naplnění požadovaných funkcí budoucího IS, nezávisle na fyzickém uložení databáze.
Můžeme jej z hlediska přístupu rozdělit do dvou skupin na strukturální a objektovou analýzu.
3.2. Strukturální analýza
Strukturální analýza je postavena na funkční a datové analýze. Takto navržené struktury mají výhodu v jednoduchém uložení, ovšem za cenu menší přehlednosti a to hlavně pro zákazníka. Další nevýhodou je složité získání informace z uložených dat.
Výsledkem funkční analýzy je diagram datových toků (DFD = Data Flow Diagram). Tento diagram vychází z identifikace systémových funkcí a událostí.
Výsledkem datové analýzy je entitně relační diagram (ERD = Entity Relationship Diagram). Jeho základním kamenem jsou entity, které reprezentují objekty reálného světa. Relace definují vazby mezi entitami. Atributem pak rozumíme funkci, která přiřazuje entitám a vztahům hodnoty popisující jejich vlastnosti.
3.3. Objektová analýza
Objektový přístup je jeden ze způsobů vytváření programů a pro jeho použití hovoří řada výhod. Objektové chápání světa kolem nás je pro člověka mnohem přirozenější. Z podobnosti objektů a jejich vlastností můžeme v reálném světě rozdělovat nebo seskupovat objekty do tříd (kategorií). Tato vlastnost nám pomůže i při definici objektu při objektové analýze. Objekt, který simuluje realitu nebo její určitou část, je instancí (výskytem) třídy. Objekt má definované atributy (vlastnosti) a metody.
Protože je objekt modelem reálného světa, tak lze snadno odvodit jednoduchou závislost. Z které plyne, že čím více atributů a metod zahrneme do popisu našeho objektu, tím více bude objekt odpovídat modelované skutečnosti.
Třída neslouží jen ke kategorizaci objektů, ale zároveň slouží jako šablona pro vytváření nových objektů. To vede k zjednodušení samotné práce s objekty. Výhodou takového přístupu je opětovné použití, již napsaného programového kódu. Proto při první analýze navrhovaného systému je nutné provést abstrakci objektů, aby byl výsledný program co nejvíce optimalizován. Abstrakce představuje filtraci atributů a metod. V programu bychom měli vytvořit abstraktní třídu nadřazenou použitým objektům. Takto odvozený objekt přebírá všechny vlastnosti nadřazené třídy.
Dědičnost, jak tomuto stavu říkáme, je charakteristickým znakem objektového přístupu.
Dalším důležitým pojmem je polymorfismus, který chápeme jako vlastnost operace, která může mít více implementací. Konkrétní implementace se pak vybere v závislosti na konkrétním typu objektu, nad nímž se operace provádí. Polymorfismus umožňuje i překrytí konkrétní operace v odvozené třídě jinou implementací. Tato metoda je všeobecně uznávaná jako postup pro rozšíření chování operací nadřazených tříd. Máme–li několik podobných činností, které se v některých svých částech liší, nemusíme je odlišně pojmenovávat nebo provádět rozhodováni pomocí podmínky.
Objektový systém sám podle kontextu rozhodne, která metoda se provede.
Objekty podporují zapouzdření, které představuje uzavření všech objektů uvnitř třídy. Jednotlivé instance jsou na sobě nezávislé. Zapouzdření je mechanismus, který svazuje dohromady kód a data a zabezpečuje je před vnějšími zásahy či zneužitím.
Podle zásad objektově orientovaného přístupu je nepřípustné, aby s objekty manipuloval někdo jiný, než vlastní metody dané třídy. Z hlediska zabezpečení mohou být objekty tříd v jedné ze čtyř základních skupin. Veřejné (public) jsou objekty, které jsou volně přístupné a zajišťují komunikaci třídy s jejím okolím. Typicky jsou veřejné prvky objektu využity k zajištění řízeného rozhraní k privátním elementům objektu.
Zveřejněné (published) objekty se chovají jako veřejné s tím rozdílem, že navíc obsahují informace o běhu programu, které umožňují zobrazovat některé vlastnosti třídy. Jsou-li objekty označeny jako soukromé (private), tak se mohou používat v pouze v rámci jednotky, ve které jsou deklarovány. Pro sousední jednotky jsou „neviditelné“.
Nemohou k nim přistupovat. Chráněné (protected) objekty mohou používat jen metody vlastní nebo zděděné třídy. Pro ostatní se chovají jako soukromé.
3.4. Porovnání
Vývoj starších aplikací byl prováděn strukturální analýzou. Určujícím faktorem bylo rozdělení aplikace na funkční a datovou část. Data byla uložena buď souborově, nebo ve formě relačních databází. Velkým přínosem strukturovaného programování bylo psaní kódu přístupem shora dolů a vytváření funkcí. Tento přístup zpřehlednil programování a zavedl prvky, které bylo možné opakovaně použít. Složitost programů stále narůstala a analytické postupy používané při návrhu IS začaly narážet na problematické propojení a soudržnost datové a funkční vrstvy. Manipulace se stejnými daty se realizovala na mnoha místech programového kódu. Z hlediska další údržby bylo velmi složité provádět změny a další rozšiřování systému. Výše uvedené nedostatky značně omezovaly použití strukturální analýzy. Proto se začal používat objektově orientovaný přístup. Jedním z jeho hlavních cílů bylo zvýšení produktivity při analýze a návrhu.
Objektový přístup se dnes snaží mnohem více o opakované používání již existujících částí programu, které vede k úsporám při realizaci. Návrháři dnes mají k dispozici unifikovaný jazyk UML, který reprezentuje nejnovější přístup objektově orientovaného návrhu. Hlavní nevýhodou objektového přístupu je oproti strukturální analýze složité uložení dat. Výhodou je však rychlý přístup k těmto datům. Dostáváme se tedy do situace, kdy začíná zákazníkovi vadit, že je zdržován. Neboť zákazníka nezajímá jednoduché uložení dat (jednoduchá struktura), ale hlavně rychlost přístupu k datům. Tato nevýhoda spojená s časovou náročností v době analýzy a návrhu se kompenzuje s příchodem složitých systémů. Zde je nutné věnovat více času analýze, protože chyba odhalená na modelech při návrhu je jednoduše a levně odstranitelná.
Oproti tomu opravení chyby při provozu je u některých IS nejen složité, ale hlavně finančně náročné.
4. UML:
Modelovací jazyk UML (Unified Modeling Language) je výsledkem snažení analytiků a designérů, kteří v průběhu 80. a 90. let vytvářeli metody, jež by umožnily popsat objektově orientovanou analýzu a návrh.
V roce 1997 byla vytvořena první verze modelovacího jazyka UML, o kterou se nejvíce zasloužila firma Rational. Ta vytvořila souhrn metod, ze kterých se tento standard vyvinul. V současnosti existuje UML ve verzi 2.0.
Modelovací jazyk UML je souhrnem především grafických notací k vyjádření analytických a návrhových modelů. Umožňuje modelovat jednoduché i složité aplikace pomocí stejné formální syntaxe, a proto lze výsledky sdílet s ostatními návrháři.
Vybrané modely jsou snadno pochopitelné i pro zadavatele aplikace a umožňují lepší ujasnění požadavků uživatele na vytvářený systém. Žádný diagram nezachycuje navrhovaný systém jako celek, ale soustředí se vždy právě na jeden pohled na vyvíjený systém.
UML je také jazyk pro vizualizaci, specifikaci, stavbu a dokumentaci softwarových systémů obecně, tedy nejen pro databázové systémy.
Pro tvorbu IDBS byly standardizovány čtyři typy základních modelů, které by měli být vždy vytvořeny: hierarchie procesů, případy užití, diagramy aktivit a modely tříd.
4.1. Hierarchie procesů
Diagram hierarchie procesů (Process Hierarchy Diagram) řeší procesní dekompozici systému. Cílem je ujasnit si rozsah vyvíjeného informačního systému a pochopit vzájemné souvislosti procesů na nejvyšší úrovni. Proces reprezentuje aktivitu, která je prováděna jako odezva na událost v systému. Popisovaná událost zpravidla vzniká na jednom místě a v jednom čase. Souběžné události je nutné ošetřit paralelními procesy. Zde uvedené procesy a subprocesy budou dále popsány v případech užití.
4.2. Případy užití
První, kdo zavedl případy užití při tvorbě informačních systémů, byl Ivar Jacobson v roce 1992. Po té se případy užití staly základními stavebními prvky objektově orientovaného návrhu.
Případy užití (Use Case) nám reprezentují typové úlohy systému. Jedná se o typické interakce uživatelů se systémem. Tyto diagramy nám pomohou hlavně v komunikaci s uživatelem, aby byly dostatečně pochopeny jeho požadavky na navrhovaný systém. Zachycují přesně funkčnost, kterou systém pokryje a vymezují tak jednoznačně rozsah prací. Každý případ užití popisuje jeden ze způsobů použití systému. Je nutné věnovat případům užití velkou pozornost, protože právě zde definované funkce budeme programovat.
Základním prvkem případů užití je aktér. Jedná se o roli, ve které bude vystupovat uživatel v rámci komunikace se systémem. Lze jej také chápat jako externí objekt, který si vyměňuje informace se systémem. Uživatel může vystupovat vůči systému ve více rolích. Aktéři mohou provádět více případu užití a zároveň jeden případ užití může být prováděn více aktéry. Aktér je znázorněn v diagramu symbolem postavičky. Samotný případ užití je znázorněn elipsou. Spojnice mezi nimi, představovaná plnou čárou, má význam interakce. Rámečkem případně můžeme znázornit hranici systému s více případy užití. U složitějších systémů lze také využít předem sestaveného scénáře případu užití. Tato sekvence kroků interakcí mezi aktérem a systémem nám pomůže při návrhu případů užití.
Mezi případy užití lze definovat dva základní vztahy. Prvním z nich je relace začlenění (include), která vyčleňuje chování ze dvou či více případů užití do samostatného případu užití. Existující případ užití je zahrnut do nového. Je tak umožněno znovupoužití již existujícího případu užití. Druhým případem je relace rozšíření (extend). Ta přidává k existujícímu případu užití nový, který rozšiřuje jeho chování.
Obr. 1: Případ užití
4.3. Diagram aktivit
Diagramy aktivit (Activity Diagram) jsou nejnovějším přírůstkem v analýze modelů. Kombinují v sobě různé modelovací techniky. Jejich výhoda spočívá hlavně v tom, že dovolují popisovat chování, které má charakter paralelního zpracování.
Diagramy aktivit jsou v podstatě objektovou variantou stavového diagramu. Modelují procesy jako soubor aktivit s jejich přechody. Můžeme je přiřadit k libovolnému segmentu a popsat tak jeho chování. Měly by být dostatečně přehledné, neboť slouží ke komunikaci při vývoji mezi členy týmu.
Diagramy aktivit jsou postaveny na modelování akčních stavů (Action State). Za aktivitu považujeme stav, ve kterém dochází v systému k určité činnosti. Aktivity jsou dále nedělitelné a není možné je přerušit, mají jeden vstup a jeden výstup. V každém diagramu aktivit se objevují dva speciální stavy, které označují začátek a konec.
K přechodu na následující stav dochází ihned po dokončení předchozí aktivity. Dále můžeme použít rozvětvení (fork) a spojení (join). Rozvětvení má vždy jeden vstup a více výstupů, zároveň slouží jako podmínka pro výběr následující aktivity. Spojení je místo, kde dochází ke synchronizaci aktivit. Má tedy více vstupů a pouze jeden výstup.
4.4. Model tříd
V modelu tříd je naším cílem zachytit všechny objekty, které se vyskytují v našem systému a jejichž vlastnosti je potřeba uchovat. Objekt má svoji identitu, vlastnosti a chování. Vlastnosti představují atributy objektu a chování je realizováno jeho metodami. Model tříd zobrazuje strukturu a vztahy mezi navrhovanými třídami informačního systému.
Mezi jednotlivými třídami jsou zavedeny vazby. Máme čtyři základní vztahy mezi třídami. První z nich je vztah typu agregace. Tento vztah reprezentuje tu skutečnost, že jedna třída je částí druhé. Je to nejčastější vyskytující se případ vazby.
Speciálním typem je kompozice, u které nemůže závislá třída existovat bez nadřazené.
Vztah typu asociace představuje vztah mezi jednou či více třídami, které jsou abstrakcí množiny spojení mezi instancemi těchto tříd. Typicky realizují násobné vazby.
Posledním typem vazby je generalizace, protože je jedním ze základních kamenů objektového přístupu. Pomocí této vazby je realizována dědičnost, používá se hlavně z důvodu opakovaného použití, aby nebylo nutné opakovat společné prvky. Typickým příkladem je hierarchie. Následník (potomek) dědí od svého předka (rodiče) všechny jeho vlastnosti.
Ve starší verzi UML se po sestavení modelu tříd vytvářel ještě datový model, ten je v nové verzi UML 2.0 již zahrnut do modelu tříd. Chceme-li tedy použít relační databázi, musíme použít mapování tříd na tabulky. Při tomto procesu převedeme atributy třídy na sloupce tabulky. Instance objektů potom odpovídají řádkům tabulky.
Mapování atributů musí odpovídat konverzi datových typů mezi navrženými datovými typy tříd a formáty sloupců tabulek fyzické databáze. Protože každý databázový stroj má, kromě základních, implementovány různé datové typy, je nutné věnovat mapování patřičnou pozornost. Primární klíč v tabulce je většinou vybrán z atributů tříd. Dále musíme mapovat jednotlivé vztahy mezi objekty. Mapování vztahů 1:1 mezi třídami vede většinou na jednu výslednou tabulku s atributy obou tříd. Vztah M:N je nutné rozložit pomocí vazební tabulky.
5. CASE systémy:
CASE systémy jsou nástroje pro podporu analýzy a návrhu aplikací (Computer Aided Software Engineering). V současné době všechny ve světě rozšířené objektově orientované CASE nástroje vycházejí z modelovacího jazyka UML. Při dnešní složitosti navrhovaných systému je zřejmé, že se bez použití těchto nástrojů neobejdeme. CASE nástrojem umožňují propojení jednotlivých technik UML a sdílení modelů mezi členy týmu a tím i kvalitní týmovou práci.
Zástupci CASE systémů pro jednotlivé přístupy analýzy byli vybráni dle několika kritérií. První z nich byl rozsah nástrojů a služeb, tedy nabízené možnosti daného softwaru. Dále byla brána v úvahu jeho rozšířenost a obliba u uživatelů. Důležitým faktorem byla také jeho cena, tím pádem i jeho dostupnost.
Většina CASE systémů, které jsou nabízeny jako freeware, nedokázala svoji funkčností a škálou nabízených služeb konkurovat levnějším systémům. Systémy velkých firem naopak vyřadila s výběru jejich cena a někdy až zbytečná specializace na určitou část vývoje. Je ale pravdou, že většina dnes nabízených vývojových nástrojů obsahuje více či méně integrovaný CASE systém pro návrh modelů. Pokud by byl tedy již vývojový nástroj firmou zakoupen a vyhovoval by požadavkům analytika, pak by asi nemělo smysl kupovat další.
Jako zástupce CASE systémů založených na strukturální analýze byl vybrán program CASE Studio firmy Charonware. Jedná se o českou firmu, která se dokázala se svým produktem prosadit i na mezinárodním trhu.
Jako zástupce CASE systémů, které jsou založené na objektové analýze, byl zvolen software Enterprise Architect firmy Sparxsystems. Zde se jedná o nástroj, který je založen na plné podpoře jazyka UML. Vývojáři byli schopni reagovat rychle na nový standard UML 2.0 a jeho změny, a proto byli o krok napřed před konkurencí. Dále k jeho volbě, přispěl fakt, že podporuje tvorbu programového kódu pro většinu na trhu dostupných vývojových prostředí.
5.1. CASE Studio
CASE Studio je profesionální software pro vizuální navrhování databázových struktur. Tyto nástroje bývají v mezinárodní odborné literatuře označovány pojmy Database modeler nebo Database designer. Podporuje tvorbu ERD (Entity Relationship Diagram) a DFD (Data Flow Diagram), pomocí kterých můžeme zcela snadno vytvořit strukturu databáze, a nabízí nám přehledné zobrazení návrhu. Umožňuje provést Reverse Engineering (zpětné načtení struktury) rozsáhlé databáze, generovat SQL script či HTML/RTF reporty apod. Case Studio ve verzi 2.0 podporuje většinu dnes dostupných databází a umožňuje jednoduchou a přehlednou funkční a datovou analýzu návrhu databáze.
5.2. Enterprise Architect
Tento CASE systém je především založen na objektovém přístupu na bázi UML.
V poslední verzi plně podporuje všechny modely nového standardu UML 2.0. Jeho použití není omezeno jen na IDBS. Umožňuje generaci kódu pro nejrozšířenější vývojové prostředí. Tento kód je pak automaticky aktualizován s navrhovanými modely. Nabízí jednoduchou a přehlednou práci v týmu. Dále generuje SQL skript a umí Reverse Engineering.
5.3. Porovnání
CASE studio, jako zástupce strukturální analýzy, je nástroj zaměření pouze pro modelování databázových systémů. Oproti tomu Enterprise Architect, který je nástrojem objektově orientovaného přístupu, není omezen pouze na databázové systémy. Jde o software založený na UML a to mu umožňuje široké nasazení.
CASE Studio nám proto může vyhovovat pro malé projekty, kde nemusíme tolik času věnovat analýze. Enterprise Architect, vzhledem k jeho možnostem, využijeme až u větších systémů. Do budoucna je však perspektivnější, neboť jeho modely pokryjí
6. Praktický příklad
6.1. Použité prostředky
Při návrhu systému byl brán zřetel na přání uživatele, aby vše bylo podle jeho požadavků a představ. K tvorbě diagramů strukturální analýzy byl použit již zmíněný software CASE Studio a k tvorbě objektové analýzy systém Enterprise Architect.
6.1.1. Delphi
K vlastní tvorbě aplikace bylo využito vizuální vývojové prostředí Delphi. Mezi jeho hlavní rysy patří paleta komponent, které mohou být vkládány do formulářů.
Každá komponenta je objekt popsaný jako třída jazyka Object Pascal. Dalšími součástmi je Editor vlastností a editor událostí, ke kterým přistupujeme v okně Object Inspectoru. Ten slouží k přiřazení hodnot vlastností komponent a pro určení reakce na vzniklé události. Výhodou Delphi je automatické generování kódu a propracovaný systém nápovědy, pro usnadnění práce programátora.
Dnes aktuální verze Borland Delphi je zásadním a úplným vývojovým řešením pro platformu Windows. Podporuje jazyky Delphi a C#, platformy Microsoft .NET a Win32, umožňuje vývoj grafických uživatelských rozhraní, webových a databázových aplikací, obsahuje nástroje pro modelování a integruje nástroje pro řízení životního cyklu aplikací v jediném hyperproduktivním prostředí pro rychlý vývoj.
6.1.2. BDE
BDE (Borland Database Engine) je „databázový stroj“, dříve též známý pod zkratkou IDAPI (Integrated Database Application Programming Interface). Jeho princip spočívá na univerzálním databázovém jádru, které realizuje databázové operace společné všem databázovým systémům pomocí specifických ovladačů. Tyto ovladače převedou obecnou databázovou operaci na její konkrétní realizaci pro daný konkrétní databázový systém.
V praxi to znamená, že z hlediska programátora není podstatné, s jakou databází pracuje. Pokud nepoužijeme zrovna ty nejvíce specializované databázové funkce (jedinečné pro daný databázový systém), můžeme vytvořit univerzální aplikaci, která bude bez úprav kódu pracovat s obecnou databází.
BDE je základním kamenem práce s databázemi v Delphi. Jde o nástroj pro uživatele skrytý, neboť běží na pozadí. Zajišťuje jednotný a konzistentní přístup k různým databázovým systémům. Zabezpečuje současně dobrou přenositelnost aplikací lokálních databází na databáze typu Client/Server. Jedinou nevýhodou je instalace a konfigurace BDE do prostředí Windows uživatele při distribuci nové aplikace.
6.1.3. SQL
Strukturovaný dotazovací jazyk SQL (Structured Query Language) je obecný nástroj pro manipulaci, správu a organizaci dat uložených v databázi. Jeho hlavní výhodou je adaptace pro jakékoli prostředí. SQL není pouze dotazovací jazyk, ale s jeho pomocí lze také definovat data, strukturu tabulky, naplňovat pole záznamů tabulky daty a definovat vztahy a organizaci mezi položkami dat. Dále umožňuje řízení přístupu k datům, udělování a odebírání přístupových oprávnění na různých úrovních, čímž chrání data před náhodným nebo úmyslným zničením, neautorizovaným čtením nebo manipulací s nimi. Umožňuje také sdílené využívání dat a zajišťuje hladký průběh činností, přistupuje-li k datům více uživatelů současně.
SQL se používá k okamžitému řešení úloh, nejčastěji dotazů. Jedná se o neprocedurální standardizovaný jazyk s množinovým přístupem k datům. Výhodou je jeho srozumitelnost, protože pracuje s relačními databázemi a nahlíží na data jako na soustavu provázaných tabulek, což je snadno pochopitelné i pro běžné uživatele. Přístup k položkám se děje skrze relační maticovou algebru.
Jazyk SQL se používá také k vytváření náhledů. Náhledy umožňují vytvořit pro různé uživatele různé pohledy na strukturu tabulek a na samotné data. Každý uživatel tak vidí pouze ta data, která má vidět, a to opět v podobě jednoduché tabulky, i když ve skutečnosti se může jednat o data pocházející z různých tabulek. Zároveň jsou data zobrazovaná v náhledu dynamická. Změní-li se data v tabulkách, změní se také náhled z nich vytvořený. A naopak, pracujeme-li s aktualizačním náhledem (speciální typ náhledu, který umožňuje nejen data prohlížet, ale i přidávat a aktualizovat), změny v datech se promítnou do patřičných tabulek (databázových souborů).
6.2. Strukturální analýza
Funkční analýza hlavního procesu je sestavena jako ucelený pohled na celý informační systém. Jak je z modelu patrné, jsou zde zavedeny základní tři přístupy uživatelů. Základní roli v systému představuje zaměstnanec půjčovny, který bude vytvářet a spravovat jednak údaje o klientech půjčovny a zároveň půjčky samotné. Další je role skladu. Pracovníka, který je pověřen správou jednotlivých pomůcek a jejich evidencí v systému. Poslední rolí je vedení nebo vedoucího pracovníka, v našem případě ředitele půjčovny. Ten bude vykonávat funkci kontrolní nad všemi daty v systému, proto jsou pro něj informace k dispozici ve formě přehledů z každého procesu v systému.
Obr. 3: DFD hlavního procesu
Detail procesu půjčovny je vidět na druhém DFD. Jsou zde detailněji popsány funkce jednotlivých částí systému. Hlavní proces správy půjčovny je rozdělen na čtyři dílčí procesy. Prvním z nich je správa klientů, kde je možné provádět operace s daty klienta od jejich zadání, úpravu a vyhledávání až po odstranění dat klienta ze systému.
Dalším procesem je správa půjček, zde je k základním operacím s daty (zadání, úprava, vyhledání, rušení) přidána možnost tisku smlouvy. Dále následuje proces správy skladu, zde je ošetřeno zadání a zrušení samotné pomůcky. Posledním procesem je tvorba přehledů, která slouží ke zpracování statistických dat pro vedení půjčovny ke kontrole činnosti systému a k jeho snazšímu řízení.
Obr. 4: DFD procesu „Půjčovna“
Obr. 5: ERD – Entity Relationship Diagram
6.3. Objektová analýza 6.3.1. Hierarchie procesů
V diagramu hierarchie procesů je zobrazen rozklad celého informačního systému půjčovny na dílčí procesy. Prvním z nich je správa klientů, zde budeme pracovat s údaji klientů půjčovny. Druhým procesem je správa půjček, která bude zajišťovat manipulaci s daty samotných půjček. Třetím procesem je správa skladu, která bude zajišťovat operace s půjčovanými pomůckami. Posledním procesem je tvorba přehledů, která bude sloužit ke kontrolním a statistickým účelům.
Obr. 6: Hierarchie procesů
6.3.2. Případy užití
Jako první je zde zaveden případ užití z pohledu klienta. Zde bylo naší snahou zachytit všechny možné požadavky, které může klient, jako zákazník půjčovny, klást na informační systém.
Obr. 7: Případ užití – Klient půjčovny
Na dalším obrázku vidíme příklad užití z pohledu zaměstnance půjčovny. Zde je možné vidět, které úkoly musí daný pracovník plnit. Tyto úkoly musíme také zahrnout do našeho informačního systému.
Obr. 8: Případ užití – Zaměstnanec půjčovny
Následující případ užití popisuje aktéra s rolí skladníka, který má na starosti půjčované pomůcky.
Obr. 9: Případ užití – Zaměstnanec skladu
Poslední případ užití reprezentuje vedení půjčovny, v tomto případě zastoupené ředitelem půjčovny. Informace jsou k dispozici buď jako seznamy, nebo ve formě přehledných grafů. Na základě těchto informací může být půjčovna efektivně řízena a sponzorům lze doložit, jak bylo naloženo s jejich finančními dary.
Obr. 10: Případ užití – Vedení půjčovny
6.3.3. Diagram aktivit
Diagram aktivit na obrázku představuje nejdůležitější proces v systému. Tím je proces samotné půjčky. V diagramu je popsán celý proces od příchodu zákazníka až po tisk smlouvy a vydání půjčených pomůcek.
Obr. 11: Diagram aktivit – Proces půjčky
6.3.4. Model tříd
Byla zavedena abstraktní třída „Osoba“, která obsahuje obecné standardní údaje každého člověka (např. jméno, příjmení, adresa). Třída „Klient“ je pak rozšířením třídy
„Osoba“ o údaje, které potřebujeme evidovat u zákazníka půjčovny. Jedná se o specializaci na konkrétní třídu. Z názvu ostatních tříd je patrné, co představují, proto není nutné, zde vše znovu opakovat.
Z diagramu jsou patrné i vazby, které jsou zavedeny mezi objekty. Klient půjčovny nemusí mít žádnou, nebo může mít více půjček. Naopak půjčka musí mít vždy jen jednoho klienta. Půjčka obsahuje minimálně jednu pomůcku. Pomůcka se nemusí vyskytovat v žádné půjčce, nebo může být obsažena ve více z nich. Musí mít ale udaný typ pomůcky a ten existuje minimálně u jedné pomůcky. Pomůcka může být zapůjčena maximálně do jedné půjčovny.
Na diagramu dále vidíme datový model. Jednotlivé třídy jsou mapovány na relační tabulky. Atributy tříd jsou transformovány na datové typy zvolené databáze.
Instance těchto tříd pak odpovídají záznamům v tabulkách. Vazby mezi třídami jsou převedeny na vztahy mezi tabulkami. Důležitá je vazba M:N mezi půjčkami a pomůckami. Ta je řešena pomocí vazební tabulky.
6.4. Výsledné uložení dat
Význam struktury uchování dat v systému je vysvětlen v následujících tabulkách, které představují jednotlivé entity databáze. Pro jednotlivé atributy je většinou postačující popis v tabulce, pro ostatní případy je detailní informace uvedena pod příslušnou tabulkou.
6.4.1. Správa Klientů:
Tabulka „Klienti“
Klíč Název sloupce Datový typ Popis
PK ICK Character (6) Identifikační číslo klienta [K#####]
Jmeno Character (20) Jméno klienta
Prijmeni Character (20) Příjmení klienta
Adresa Character (20) Adresa klienta
PSC Character (6) Poštovní směrovací číslo [### ##]
Město Character (20) Město
Telefon Character (11) Telefon klienta [### ###
###]
COP Character (12) Číslo občanského průkazu klienta
Sleva Charakter (1) Jestli klient má právo na slevu [*A,N]
Poznamka Memo (240) Poznámka ke klientovi
Atribut „Sleva“ představuje informaci o tom, zda daný klient má právo na slevu.
Respektive dává informaci o tom, zda je klient stálým zákazníkem dané půjčovny, protože svým klientům poskytuje půjčovna slevu.
6.4.2. Správa Půjček:
Tabulka „Půjčky“
Klíč Název sloupce Datový typ Popis
PK Pujcka Character (9) Číslo půjčky (2005/0001) [####/####]
FK ICK Character (6) Identifikační číslo klienta (K00001)
[K#####]
DatumP Date Datum půjčky
[##.##.####]
PocetMesicu Short (Integer)
Počet měsíců, na které je půjčka
sjednána
DatumU Date Datum ukončení
půjčky [##.##.####]
Cena Money Celková cena
půjčky (půjčených pomůcek)
Platba Character (10) Způsob platby
Zaplaceno Money Zaplacená částka
Atribut „PocetMesicu“ nám dává informaci, na kolik měsíců byla pomůcka půjčena, neboť základní jednotkou je jeden měsíc.
Atribut „DatumU“ představuje datum ukončení půjčky, respektive navrácení pomůcky do půjčovny.
Atribut „Platba“ uchovává informaci o tom, zda klient zaplatil hotově či převodem z účtu.
Tabulka „Položky“
Klíč Název sloupce Datový typ Popis
PK Index Autoinc Pořadí položky (index)
FK Pujcka Character (9) Číslo půjčky (2005/0001) [####/####]
FK ICP Character (6) Identifikační číslo pomůcky (P00001)
[P#####]
CenaP Money Cena položky
Atribut „Pujcka“ obsahuje číslo půjčky, ke které daná položka patří.
Atribut „CenaP“ obsahuje cenu položky, respektive pomůcky, kde je brán ohled na to, zda klient je členem místní charity a má tudíž právo na slevu.
6.4.3. Správa Skladu (pomůcek):
Tabulka „Pomůcky“
Klíč Název sloupce Datový typ Popis
PK ICP Character (6) Identifikační číslo pomůcky
[P#####]
PFK ICT Character (4) Identifikační číslo typu
[T###]
PK Nazev Character (25) Název pomůcky
CenaB Money Cena bez slevy
CenaS Money Cena se slevou
Pujceno Character (1)
Jestli je pomůcka
půjčena [*A,N,P]
ICPU Character (4) Identifikační číslo půjčovny
[PU##]
Atribut „Pujceno“ představuje informaci, zda je pomůcka právě půjčena, či nikoliv a nebo zda není půjčena do jiné půjčovny (skladu).
Tabulka „Typy“
Klíč Název sloupce Datový typ Popis
PK ICT Character (4) Identifikační číslo typu
[T###]
Typ Character (25) Název typu
Tabulka „Půjčovny“
Klíč Název sloupce Datový typ Popis
PK ICPU Character (4) Identifikační číslo půjčovny
[PU##]
Pujcovna Character (25) Název půjčovny
6.5. Vlastní program 6.5.1. Hlavní okno
Obr. 13: Hlavní okno programu
Hlavní okno programu je navrženo tak, aby se z něj uživatel mohl dostat rychle na důležité procesy systému (správu klientů, správu pomůcek, správu půjček a tvorbu statistických přehledů).
6.5.2. Klienti
Správa klientů umožňuje základní funkce jako zadání nového klienta (Obr. 14), úpravu dat existujícího klienta a jejich zrušení. Dále je možné vyhledávat v databázi klientů dle všech položek, které systém spravuje.
Příklad SQL příkazu pro zadání nového klienta:
INSERT INTO klienti (ICK, Jmeno, Prijmeni, Adresa, PSC, Mesto, Telefon, COP, Sleva, Poznamka) VALUES ("K00005", "Jan", "Novák", "Nádražní 1624/13", "415 04", "Ústí nad Orlicí",
"777 111 333", "503ADP - 313", "A", "Poznámka ke klientovi.")
6.5.3. Pomůcky
Obr. 15: Pomůcky
Na obrázku je vidět úvodní formulář správy pomůcek. Opět nabízí základní operace s pomůckami (přidání nové, úpravu stávající a rušení pomůcky). Možnosti vyhledání jsou dle identifikačního čísla, typu a názvu pomůcky. Červeně jsou v seznamu označeny ty pomůcky, které jsou momentálně půjčené a nejsou momentálně na skladě k dispozici. Z okna formuláře pomůcek je možné se dostat do formuláře typů pomůcek (Obr. 16). Zobrazovaný typ pomůcky je vždy pro danou pomůcku načten z databáze typů. Do samotné databáze pomůcek se ukládá jen identifikační číslo typu, tím je typ jednoznačně identifikován a je tím dosaženo úspory místa pro ukládaná data.
Ve formuláři typů pomůcek lze opět provádět s typy základní operace (založit nový, upravit a smazat).
Obr. 16: Typy pomůcek
Ukázka SQL příkazu pro smazání typu pomůcky:
DELETE FROM typy WHERE ICT=”T004”
6.5.4. Půjčky
Správa půjček je nejdůležitějším procesem systému. Zde se spojují všechny předešlé databáze v jeden celek. Komplexní propojení je možné ilustrovat na procesu založení nové půjčky.
Nejdříve je vypočteno číslo nové půjčky v závislosti na datu vytvoření. Dále pak uživatel vybere z databáze klienta, který půjčku požaduje. Do databáze půjček je uloženo jen identifikační číslo klienta, které jej jednoznačně identifikuje a tím je dosažena úspora místa pro ukládání dat. Přes toto číslo je klient propojen s danou půjčkou. Následuje vybrání pomůcek, které danému klientovi budou zapůjčeny. Při přidání nové pomůcky půjčky je vytvořen záznam v databázi položek. Do něj se uloží číslo půjčky, ke které patří, identifikační číslo půjčené pomůcky a její cena. O té je rozhodnuto s údajů klienta. Tím je zajištěn dynamický počet pomůcek půjčovaný jednomu klientovi v jedné půjčce. Zároveň tato realizace přináší velkou úsporu kapacity
Z údajů klienta je dále určena cena půjčené pomůcky. Podle toho, zda má klient právo na slevu, je určena cena se slevou nebo bez slevy. V databázi pomůcek je vybraná pomůcka označena jako půjčená, aby nedošlo k opětovnému půjčení. V seznamu výběru půjčovaných pomůcek ze skladu jsou zobrazeny jen ty, které nejsou půjčeny a jsou na skladě. Dále je vybráno datum půjčky, od jakého data budou pomůcky klientovi půjčeny. Dále je nutno zadat počet měsíců, na které jsou pomůcky zapůjčeny. Měsíc byl stanoven, po konzultaci se zákazníkem, jako základní časová jednotka půjčky a zároveň jako minimální doba půjčky. Po té program vypočítá datum předpokládaného vrácení půjčky. Do tohoto data musí klient pomůcku vrátit nebo mu naskakuje penále a úměrně k překročené době se zvyšuje i cena půjčky. Při předčasném návratu je cena snížena o danou částku v přepočtu na dny. Dále zaměstnanec volí způsob platby klienta. Buď klient platí hotově, nebo převodem z účtu. Po výběru této položky ze seznamu je zobrazeno pole pro zadání čísla účtu. Poslední vyplňovanou položkou je údaj o zaplacené částce klientem.
Obr. 17: Úprava půjčky
Podobně je řešena úprava půjčky (Obr. 17). Zde je možnost upravit údaje půjčky, půjčené pomůcky, změnit klienta a zadat datum vrácení pomůcky, ukončení smlouvy.
Nejdříve je v databázi pomůcek daná pomůcka označena jako nepůjčená. A pak je smazán celý záznam v databázi položek. Před zrušení samotné půjčky dojde k načtení seznamu položek dané půjčky, zde je zjištěno, které pomůcky patří této půjčce a jsou označeny jako nepůjčené. Dále jsou smazány všechny záznamy v databázi položek patřící k dané půjčce. Nakonec je smazán záznam půjčky samotné.
Správa půjček umožňuje tisk smlouvy o půjčce, která byla sestavena spolu se zadavatelem (Obr. 18). Zde jsou načteny data ze systému a z nich vypočteny další údaje.
6.5.5. Přehledy
Pod tvorbou přehledů jsou k dispozici statistická data, která slouží jednak k řízení celé půjčovny a také mají za úkol doložit efektivnost vynaložených prostředků od sponzorů. Přehledy jsou realizovány výběrem požadovaných dat ze systému a zobrazeny ve buď formě seznamu, nebo pomocí přehledných grafů (Obr. 19).
Obr. 19: Přehled půjčených pomůcek
Hlavními požadavky zadavatele byli přehledy půjčených pomůcek za určité časové období rozdělené dle typu a celkový přehled pomůcek půjčovny. Dále přehled klientů, které nemají uhrazené pohledávky vůči půjčovně.
7. Závěr
Hlavním cílem mé diplomové práce bylo porovnání strukturální a objektové analýzy pro tvorbu a návrh informačních databázových systémů. Srovnání obou přístupů jsem provedl na praktickém příkladě. Tím bylo vytvoření kompletního softwarového řešení pro Oblastní charitu v Ústí nad Orlicí, která spravuje půjčovnu zdravotních a kompenzačních pomůcek pro tělesně postižené.
Strukturální přístup se ukázal dostačující jen pro velmi malé projekty, kde je jeho výhodou menší časová náročnost. Už u složitých projektů, jako je například informační systém půjčovny, je velmi obtížné udržet přehled v návrhu a orientaci při změnách v samotné implementaci. Objektový přístup sice vyžaduje více času při návrhu, ovšem dovoluje nám výrazné zlepšení komunikace se zákazníkem a případně i s členy vývojového týmu.
Pro analýzu realizovaného případu půjčovny, je tedy lepší použít objektový přístup založený na UML. Pomocí definovaných diagramů, je možné lépe zachytit požadavky zákazníka a vyvarovat se chyb už v době návrhu. Pozdější odstranění chyb za provozu je vždy finančně a časově náročné.
Srovnání CASE nástrojů vyznívá lépe pro Enterprise Architect. EA je obecným nástrojem pro modelování, využívá více modelů, a tím umožňuje přesnější popsání modelované reality. CASE studio je nástrojem zaměřeným jen na tvorbu databázových systémů a stejně jako strukturální analýza je vhodný spíše pro modelování malých projektů.
Strukturální analýza informačního systému byla provedena pomocí programu CASE Studio verze 2.22. Výsledkem funkční analýzy jsou výše uvedené diagramy datových toků (DFD). Výsledkem datové analýzy je entitně relační diagram (ERD), který popisuje strukturu dat.
Modely objektové analýzy byly vytvořeny v programu Enterprise Architect. Zde bylo využito modelovacího jazyka UML. Modely byly upraveny dle nejnovější specifikace standardu UML 2.0, aby byla zaručena jejich aktuálnost a zachycen současný trend při vývoji informačních databázových systémů. Pro uložení dat byla zvolena relační databáze, neboť ji drtivá většina systémů stále používá a v nejbližší době ji bude používat i nadále.
Informační systém byl dle požadavků zákazníka vytvořen tak, aby plně pokrýval jeho potřeby. Systém slouží pro správu třech nezávislých skladů zdravotních a kompenzačních pomůcek pro tělesně postižené. Propojení dílčích skladů v jeden systém nebylo možné, protože jednotlivé sklady jsou v různých městech a tyto pobočky nemají přístup na internet a ani nejsou mezi sebou nijak propojeny. V budoucnu je možné programy upravit a propojit jednotlivé systémy v jeden celek. Tím bude zlepšena operativnost a přehlednost celého informačního systému pro daný region.
Databáze je postavena na dnes standardním přístupu přes strukturovaný jazyk SQL. K jeho realizaci byl použit databázový systém paradox s přístupem přes BDE (Borland Database Engine) ve verzi 5.2. Volba databázového systému byla ovlivněna podmínkami zadavatele a jednoduchostí instalace u klienta. Dalším faktorem byla i univerzálnost přístupu k databázím, dále pak bohatá a typová výbava pro databáze typu paradox.
Pro program klientské části řešení bylo použito vizuální vývojové prostředí Delphi 7.0. Zvolené prostředí bylo vybráno pro jeho komplexnost a pro jeho dobré vlastnosti pro vývoj databázových aplikací.
8. Seznam použité literatury
[1] Pokorný J., Halaška I.: Databázové systémy, ČVUT, Praha 2004 [2] Pokorný J.: Konstrukce databázových systémů, ČVUT, Praha 2004 [3] Schmuller J.: Myslíme v jazyku UML, Grada, Praha 2001
[4] Janusová H., Müller M.: UML srozumitelně Computer Press, Brno 2004 [5] Cantú M.: Myslíme v jazyku Delphi 7, Grada, Praha2003
[6] Swan T.: Mistrovství v Delphi 4, Computer Press, Brno 1999 [7] Písek S.: Začínáme programovat v Delphi, Grada, Praha 2000
[8] Hernandez M. J., Viecas J. L.: Myslíme v jazyku SQL, Grada, Praha 2004 [9] Šimůnek M.: SQL – kompletní kapesní průvodce, Grada, Praha 1999
[10] Dürrschnabel F., Datenbankprogramienrung mit Delphi, Winklers, Darmstadt 2000
[11] The Object Management Group (OMG), On-line dokumentace UML 2.0:
http://www.omg.com
[12] Sparxsystems: On-line nápověda k programu EA http://www.sparxsystems.com.au/resources
[13] Charonware: On-line nápověda k programu CASE Studio, http://www.casestudio.com
9. Přílohy:
