Informační systém pro veterinární stanici

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Informační systém pro veterinární stanici Diplomová práce

Autor:

Bc. Jan Stárek Informační technologie a management

Vedoucí práce:

Praha

Ing. Vladimír Beneš

Duben 2012

Prohlášení:

Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze, dne 26 dubna 2012

jméno a příjmení autora

Poděkování:

Tímto bych chtěl poděkovat svému vedoucímu diplomové práce Ing. Vladimíru Benešovi za odborné vedení při vypracování této diplomové práce.

Anotace Cílem diplomové práce je návrh a implementace informačního systému pro veterinární stanici v prostředí Visual studio, C#. Práce popisuje projektování informačních systémů a pojednává o dostupných nástrojích pro týmovou práci při vývoji systému. V praktické části se práce zabývá vývojem informačního systému pro veterinární stanici, který poskytne základní funkce pro správu elektronické kartotéky klientů a jejich zvířat. Dále obsahuje analýzu a design informačního systému pro veterinární stanici založenou na objektově orientovaném principu a implementaci za pomoci objektově orientovaného jazyku C# a databázového systému MS SQL server.

Klíčová slova: informační systém, veterinární stanice, UML, objektově-orientované programování, C#, ASP, MS SQL

Annotation The primary goal of this thessis is design and implementation of information system for veterinary station in Visual Studio, C #. This work describes projecting of information systems and discusses the available tools for team work to develop the system. Practical part of the work deals with the development of an information system for veterinary station, which provides basic functions for managing the electronic file cabinet of clients and their animals. Also includes analysis and design of information system for veterinary station based on object-oriented approach and implementation using object-oriented language C # and database system MS SQL server.

Key words: information systém, veterinary station, UML, object-oriented programming, C#, ASP, MS SQL

Obsah

1

Zvolené metody zpracování................................................................................................ 9

2

Projektování informačních systémů ................................................................................. 10 2.1

3

Ţivotní cyklus SW ..................................................................................................... 11

2.1.1

Poţadavky........................................................................................................... 12

2.1.2

Analýza ............................................................................................................... 13

2.1.3

Návrh .................................................................................................................. 13

2.1.4

Implementace a testování ................................................................................... 14

2.1.5

Provoz a údrţba .................................................................................................. 14

2.2

Objektově-orientovaný koncept ................................................................................. 14

2.3

UML a CASE nástroje ............................................................................................... 16

Informační systém pro veterinární stanici ........................................................................ 18 3.1

Úvodní studie ............................................................................................................. 18

3.1.1

Základní cíle projektu ......................................................................................... 18

3.1.2

Analýza zákazníka a jeho prostředí .................................................................... 18

3.1.3

Poţadavky na hardware a software .................................................................... 19

3.1.4

Očekávané funkce .............................................................................................. 19

3.1.5

Charakteristika vstupů, výstupů a rozhranní systému ........................................ 19

3.2

Analýza poţadavků .................................................................................................... 20

3.3

Analýza ...................................................................................................................... 29

3.3.1

Use-case model ................................................................................................... 29

3.3.2

Model tříd objektů .............................................................................................. 47

3.3.3

Datový model ..................................................................................................... 52

3.3.4

Model objektové spolupráce............................................................................... 54

3.4

Design ........................................................................................................................ 59

3.5

Implementace prototypu 1 ......................................................................................... 61

3.5.1

Zaloţení nového projektu ve Visual studiu 2008 ............................................... 62

3.5.2

Tvorba tříd v C# ................................................................................................. 62

3.5.3

Tvorba Business Logic ....................................................................................... 65

3.5.4

Tvorba prezentační vrstvy GUI.WinForms ........................................................ 67

3.5.5

User controls ....................................................................................................... 68

3.5.6

Tvorba formulářů................................................................................................ 70

3.5.7

Tvorba databáze v MS SQL serveru .................................................................. 71

3.6


3.7


3.8

Instalace systému ....................................................................................................... 79

3.8.1

Tvorba databáze.................................................................................................. 80

3.8.2

Tvorba tabulek .................................................................................................... 80

3.8.3

Naplnění tabulek daty ......................................................................................... 81

3.8.4

Vytvoření storovaných procedur ........................................................................ 81

3.8.5

Problémy s vytvářecími skripty .......................................................................... 81

3.8.6

Spuštění systému ................................................................................................ 81

4

Závěr ................................................................................................................................. 82

5

Literatura .......................................................................................................................... 85

6

Seznam zkratek ................................................................................................................. 86

7

Seznam obrázků................................................................................................................ 87

8

Seznam Diagramů ............................................................................................................ 87

9

Seznam zdrojových kódů.................................................................................................. 88

10

Přílohy .............................................................................................................................. 89

Úvod Evoluční vývoj ţivočišných organizmů je proces, který poukazuje na vývoj ţivých organizmů na Zemi. Člověk prošel svým evolučním vývojem, který trval miliony let. Po celou tuto dobu byl člověk doprovázen rozličnými ţivočišnými druhy. Některá zvířata člověk lovil pro maso a koţešiny, jiná později domestikoval a pouţíval například na domácí práce. Některé vybrané ţivočišné druhy domestikovány člověkem změnily své postavení ve společnosti a povýšily na společníky lidí. Jako první kaţdého napadne například kočka nebo pes. Kočka se vyuţívala pro lov myší, pes jako pomocník při honech na divokou zvěř. V dnešní době si člověk pořizuje kočku nebo psa jako společníka, pro děti, nebo jen tak pro radost. Mezi takzvané domácí mazlíčky uţ nepatří jenom kočka, pes nebo ptactvo. Mezi oblíbené ţivočišné druhy například přicházejí v úvahu i zvířata jako pavouci a hadi. S posunem ţivočišných druhů na ţebříčku oblíbenosti se začalo více hledět na ţivot a zdraví domácích mazlíčků. S touto potřebou se začala rozvíjet disciplína zvaná veterinární lékařství. Za minulých časů například veterinář do vesnice přijíţděl jednou za rok, aby naočkoval zvířata proti vzteklině. Dnes jiţ moţná v této vesnici stojí malá veterinární stanice. Počty klientů veterinárních stanic rostly a tak ve větších městech vznikaly další veterinární stanice. Postupem času se do veterinárních stanic začaly zavádět informační systémy tak jako ve firmách, nemocnicích nebo obchodech. Hlavním cílem diplomové práce je návrh a implementace informačního systému pro veterinární stanici v prostředí Visual studio, C#. Diplomová práce je rozdělená do tří kapitol. První kapitola Zvolené metody zpracování obsahuje popis vybraných metod a technik zpracování vybrané problematiky. Druhá kapitola Projektování informačních systémů obsahuje podkapitoly Ţivotní cyklus, Objektově-orientovaný koncept a UML a CASE nástroje. V podkapitole Ţivotní cyklus jsou popsány vývojové fáze, kterými prochází softwarový produkt. Podkapitola objektově-orientovaný koncept uvádí vysvětlení pojmu objekt, abstrakce, zapouzdření, dědění a polymorfizmus. Podkapitola UML a CASE nástroje popisuje standard Unifed Modelling Language, uvádí funkci CASE nástrojů a jejich zapojení do analýzy softwaru. Třetí kapitola Informační systém pro veterinární stanici je praktickou částí diplomové práce. Kapitola obsahuje podkapitoly Úvodní studie, Analýza poţadavků, Analýza, Design, 7

Implementace prototypu 1, Implementace prototypu 2, Implementace prototypu 3 a Instalace systému. Podkapitola Úvodní studie obsahuje předběţný rozbor funkcí systému, hardwarové a softwarové nároky a analýzu zákazníka. Podkapitola Sběr poţadavků předkládá seznam identifikovaných

poţadavků.

Podkapitola

Analýza

obsahuje

systémovou

analýzu.

V podkapitole Design jsou uvedeny vybrané technologie pro implementaci a popis architektury systému. Podkapitoly Implementace prototypu 1 - 3 obsahují stěţejní části zdrojového kódu s popisem. Podkapitola Instalace systému obsahuje pokyny pro zprovoznění aplikace. Kapitola Závěr předkládá shrnutí zjištěných teoretických poznatků, závěry praktické části a návrhy a návrhy na zlepšení.

8

1 Zvolené metody zpracování Diplomová práce má za cíl návrh a implementaci informačního systému pro veterinární stanici. Téma diplomové práce je z velké části zaměřeno na praktickou část. Teoretická část je zaměřena na projektování informačních systémů a byla v ní vyuţita technika rešerše. Poţadavkem pro rešeršní činnost bylo proniknout do problematiky analýzy a designu softwarového produktu. Dalším cílem byl průzkum literatury zabývající se tématem UML, protoţe se jedná o světově uznávaný standard vyuţívaný v analýze a designu. Pro účely

implementace

byly

vybírány

tituly

zabývající

se

objektově-orientovaným

programováním v MS.NET Frameworku, C# a ASP. Praktická část je zpracována za pomoci objektově-orientované analýzy a návrhu. Pro účely zpracování analýzy a návrhu byla zvolena objektově-orientovaná metodika. Další moţností by mohlo být pouţití metodiky strukturované (klasické). Pouţití strukturované metodiky bylo zamítnuto z důvodů předem definovaného zadání diplomové práce. Pro implementaci systému byl zvolen objektově-orientovaný jazyk C#. Ve spojení MS.NET Frameworku, C# a ASP je moţné vytvořit sofistikované aplikace Winforms i webové aplikace.

9

2 Projektování informačních systémů Jelikoţ ţijeme v rychlé době, kde jsou nejdůleţitější kvalitní informace, rychlé reakce na náhlé podněty a svět si podmaňují nové technologie, dokáţeme si jen těţko představit běţný ţivot bez informačních technologií. Otázkou je, jak by si vedly velké korporace bez sofistikovaných informačních systémů, kamenné prodejny bez podpory e-shopů nebo nemocnice bez vyuţívání komplexních softwarů. Podnikatelské subjekty, ať uţ se jedná o výrobní nebo nevýrobní činnost, potřebují pro podporu podnikání informační systém. Jistě by se dalo namítnout, ţe některé podnikatelské subjekty nejsou na takové úrovni, ţe by informační systém potřebovaly. Z praxe však vyplývá, ţe je potřeba uchovávat kvalitní a důleţité informace. Řízení podniků je pak efektivní, náklady jsou niţší a úkony jsou rychleji provedené. Úvodem pojednání o projektování informačních systémů je dobré definovat termín systém. Systém je sada prvků, které mají ohraničené možnosti a společně vytváří přidanou hodnotu, aby uspokojily uživatelovy potřeby v předepsaném prostředí. Wasson [10] Slovo systém původem pochází z řečtiny. Obecný význam systému je zmírnění neuspořádanosti. Informační systém je mnoţina kompatibilních prvků, které získávají, zpracovávají a analyzují informace. Mezi systémové prvky patří software, hardware, lidé, databáze, dokumentace a postupy. Vytvářením softwarových produktů se zabývá disciplína zvaná softwarové inţenýrství. Stručná definice a popis softwarového inţenýrství viz níţe. Systémového

inženýrství

je

činnost,

obsahující

specifikaci,

návrh,

implementaci, ověřování, zavádění a udržování socia-technických systémů. Je to interdisciplinární činnost zahrnující mnoho oborů.

Sommerville [7]

Sommervill definuje, ţe do procesu softwarového inţenýrství zasahují vědní disciplíny, které mají pomáhat při vývoji softwarového díla. Softwarové inţenýrství je sadou doporučených postupů a přináší do vývoje softwarových produktů řád. Obsahuje aplikace analytických, matematických a vědeckých zásad, ale práce je zaměřena i na podnikání. Přináší

10

řešení, minimalizuje rizika a náklady na ţivotní cyklus softwarového produktu. Sommervillovu definici lze doplnit a upřesnit definicí Pressmana. Základními činnostmi softwarového inženýrství jsou stanovení role hardwaru, softwaru, lidí, databáze, postupů, identifikace systémových prvků a provozních požadavků, které jsou analyzovány a modelovány.

Pressman [5]

2.1 Životní cyklus SW Při vývoji softwaru je důleţité vytvořit projekt a jeho jednotlivé činnosti zkoordinovat a naplánovat tak, aby se dosáhlo konkrétního vytýčeného cílu. V tomto procesu jsou hlavní otázky: kdo, kdy a co. Softwarový produkt má svůj ţivotní cyklus. Životní cyklus softwaru se skládá z posloupnosti jednotlivých vývojových etap a modelu životního cyklu. Pro každou etapu vývoje definuje nutné činnosti, jejich vstupy a výstupy. Časově vynaložené úsilí na jednotlivé etapy: 

analýza a speciﬁkace požadavků (8%),



architektonický a podrobný návrh (7%),



implementace (12%),



integrace a testování (6%),



provoz a údržba (67%).

Křena, Kočí [2]

Příkladem modelu ţivotního cyklu je vodopádový model. Vodopádový model ţivotního cyklu je nejstarším modelem. Je jednoduchý a přirozený, protoţe jednotlivé etapy řadí za sebou. Vţdy po skončení etapy jedné následuje etapa další. Název je odvozen od vodopádu, kde voda dopadá z výše poloţeného bodu do bodu niţšího. Jednotlivými etapami se propadáme níţ a níţ, zpátky se však nevracíme. Zde je jádro problému vodopádového modelu. Pohyb zpět není zakázaný, je však obtíţný a provádění změn můţe celý projekt vykolejit ze stanoveného plánu. Při vývoji softwaru spolu komunikují zákazník, dodavatel a uţivatelé. Zákazník je osobou nebo společností, která kontaktuje dodavatele za účelem potřeby softwarového 11

produktu. Má určité poţadavky a představy o produktu. Dodavatel se snaţí uspokojit zákazníkovy potřeby a dodat mu produkt v určité kvalitě, který je zpracován na základě zjištěných poţadavků. Dodavatel poţadavky získává nejen od zákazníka, ale i od budoucích uţivatelů, zaměstnanců zákazníka. Roli můţe hrát špatná komunikace, nedostatečné zapojení uţivatelů nebo další problémy. Z tohoto důvodu není vodopádový model vhodný pro sloţité systémy nebo projekty s často měnícími se poţadavky. Vodopádový model je nahrazován V-modelem, který obsahuje zpětnovazebné smyčky pro kontrolu. Grafické znázornění vodopádového modelu viz Obrázek 1.

Obrázek 1: Vodopádový model životního cyklu

Zdroj: zpracováno dle http://suave_skola.varak.net/lectures_IUS/opora_IUS.pdf 2.1.1

Požadavky Ţivotní cyklus vývoje softwaru je uveden blokem poţadavky. Blok poţadavky

znázorňuje sběr a správu poţadavků. Poţadavek definuje, co by měl systém dělat. Je popisem určité funkce navrhovaného systému. Část poţadavků je vznášena ze strany zákazníka. Dále se do procesu získávání poţadavků zapojují budoucí uţivatelé systému, jak jiţ bylo řečeno výše. Dalším zdrojem poţadavků můţe být jiţ existující zastaralý systém zákazníka nebo hardwarové a softwarové prostředí zákazníka. Sběr poţadavků má svoji vlastní disciplínu zvanou Software requirements engineering. Proces obsahuje objevování, modelování a specifikaci poţadavků. Analýza poţadavků má za úkol, aby byly pochopeny a archivovány specifické poţadavky pro vybudování kvalitního softwaru. 12

2.1.2

Analýza Za blokem poţadavky následuje blok analýza. Analýza, respektive systémová analýza,

je sloţitější činností a je svěřena systémovému analytikovi. Předmětem systémové analýzy je vytvoření modelu softwaru. Systémový analytik tedy převezme model poţadavků a vytvoří analytický model. Analytické modelování používá kombinaci textové a schematické formy k popsání požadavků na data, funkce a chování způsobem, který je poměrně snadné pochopit a přezkoumává správnost, úplnost a jednotnost.

Pressman [5]

Analytický model je jednou z částí spojovacího mostu mezi zjištěnými poţadavky zákazníka a implementací softwaru. Model lépe pomáhá pochopit doménu problematiky. Není to řešení, je to náčrt reality. Přínos modelu tkví i v moţnosti porovnání, zda model odpovídá poţadavkům zákazníka. Pokud by se software implementoval rovnou po zjištění poţadavků, tak by se mohly objevit nejednoznačnosti a duplicity. Model nezohledňuje hardware, databázi nebo programovací jazyk. 2.1.3

Návrh Zatímco analýza pojednávala o tom, co má systém dělat bez závislosti na konkrétních

technologiích, návrh klade důraz na koncepční řešení. Návrh se tedy zabývá tím, jak má být systémová funkcionalita poskytnuta za pomoci konkrétních technologií. Design je zaměřen na čtyři hlavní oblasti zájmu: datová struktura, architektura systému, reprezentace rozhraní a komponenty.

Pressman [5]

Návrh architektury obsahuje výběr vhodné architektury: Například je vybrána vrstvená architektura a rozhoduje se o počtu vrstev. Dále se rozhoduje o počtu zúčastněných strojích, na které se jednotlivé vrstvy rozdělí. Vybírají se technologie, které budou poţadovány na klientských počítačích. Systém se dekomponuje na jednotlivé subsystémy a návrh se zaměřuje na jejich komunikaci.

13

2.1.4

Implementace a testování Následující bloky implementace a testování obsahují realizaci navrhovaného softwaru

a jeho testování. Implementace neboli nasazení systému do provozu je proces vytváření zdrojových

kódů.

Implementace

se

provádí

za

pomoci

vybraných

technologií

a programovacích jazyků. Pokud je vygenerován zdrojový kód, je potřeba zjistit, zda software pracuje správně. Nastupuje testování. V rámci testování se software prověřuje dle předem vytvořených scénářů, které mají za úkol odhalit chyby. Příkladem testovací techniky je black-box test. Název black-box jiţ vypovídá o charakteru testu. Anglický překlad je černá skříňka, coţ charakterizuje, ţe vnitřní uskupení skříňky není známé. Černá skříňka poskytuje pouze vstupy a výstupy. Vnitřní charakteristika neboli zdrojový kód softwaru, není známá nebo není potřebná. Test vychází ze znalostí funkcionality komponenty. Test probíhá vloţením dat na vstup a očekáváním dat na výstupu podle známé funkcionality. Příkladem můţe být program kalkulačka, kde zadáme vstup a pokud je výstupem správný výsledek, black-box test prošel. 2.1.5

Provoz a údržba Naimplementovaný software, který prošel testy a nevykazuje chyby, je potřeba

podrobit akceptačním testům. Akceptační testování spočívá v otestování systému uživatelem. Na základě výsledku se rozhodne, zda bude systém převzat nebo bude pro nedostatky potřebná oprava.

Křena [2]

Pokud je software převzat, proběhne instalace. Nastává období provozu a údrţby. Toto období zabírá nejvíce úsilí z celkového času ţivotního cyklu softwaru.

2.2 Objektově-orientovaný koncept Softwarový produkt má svůj ţivotní cyklus a při jeho vývoji jsou vyuţívány metodiky. Obecný význam metodiky je postup při řešení určitého problému. Metodika předkládá řešiteli postup, aby mohl vývoj naplánovat a určit priority řešení. Metodika ve smyslu softwarová

14

metodika pokrývá celý ţivotní cyklus vývoje softwarového produktu. Metodika dodává doporučené praktiky a postupy. Evoluce softwarových metod a metodik zahrnují datové metody ze šedesátých let, strukturované metodiky ze sedmdesátých let a objektové metodiky z let osmdesátých. V objektově orientovaných metodikách se vše točí kolem objektů a tříd. V reálném světě existují ţivé a neţivé předměty a softwaroví inţenýři musí s některými předměty pracovat v rámci analýzy, návrhu a implementace. Musí provést takzvanou abstrakci reality. Abstrakce reality tyto předměty převádí do světa informatiky, kde jsou definovány a mají určité funkce a chování. Tyto předměty jsou i často zjednodušovány. Reprezentace takového předmětu z reálného světa je objekt. Objekt je konglomerát členských proměnných, vlastností, událostí a metod. Proměnné uchovávají vnitřní stav objektu. Metody představují operace, které objekt umí vykonávat. S pojmem objekt úzce souvisí třída, která označuje druh objektu a funguje jako šablona pro vytváření nových instancí.

Vystavěl [9]

Objektově-orientovaný koncept obsahuje kromě vlastnosti abstraction dále vlastnost encapsulation, inheritance a polymorhism. Vlastnost encapsulation neboli zapouzdření popisuje Vystavěl jako konglomeraci dílčích prvků. Objekt uzavírá do sebe atributy a metody, ke kterým se přistupuje pomocí rozhranní. Vlastnost inheritance popisuje dědění. Dědění je objektová implementace vztahu generalizace. Objektovým třídám je umoţněno sdílet charakteristiky. Dědičnost se vyuţívá například při opakování atributů. Příkladem můţe být rodičovská třída Člověk, od které dědí dceřiná třída Klient, Prodavač, Správce atributy Jméno a příjmení. Poslední vlastností je polymorhism. Polymorfizmus je definován ve slovníku cizích slov jako mnohotvárnost nebo různorodost. Polymorfismus znamená schopnost vzít na sebe mnoho podob. Je aplikován na objekty a operace. Využívány jsou obecné třídy, které jsou specificky poděděny. Stejným způsobem jsou specificky poděděny polymorfní metody.

Podeswa [4]

Polymorfizmus vyuţívá objektovou implementaci vztahu specializace. Specializace se od generalizace odlišuje tím, ţe z obecné třídy se dědí atributy a metody, které jsou v cílových třídách odlišně poděděny. Příkladem polymorfizmu je obecná třída Osoba, od které dědí třídy 15

FyzickáOsoba a PrávnickáOsoba. Oba dva subjekty platí daně, coţ je vyjádřeno metodou zaplať daně. Polymorfní metoda ZaplaťDaně má stejné označení, ale jinou implementaci.

2.3 UML a CASE nástroje Aby byla práce na projektu maximálně podporována, je za potřebí postupovat jednotně a vyuţívat stejné nástroje. Práci všech softwarových inţenýrů sjednocují zvolené metodiky, vyuţívané technologie a konkrétní vývojové nástroje. Standardem pro práci analytiků a designérů je Unified Modeling Language, zkráceně UML. UML je široce uznávaný standard zahrnující objektově-orientované koncepty, které vyvinuli Grady Booch, Jim Rumbaugh a Ivar Jacobsonyn. UML je niní ve vlastnictví Object Management Group. UML je standard zastřešující terminologickou a diagramovou konvenci.

Podeswa [4]

Je to grafický jazyk slouţící pro vizuální modelování. Předmětem UML je tvorba analytických a návrhových modelů. Vytvořené modely mezi sebou softwaroví inţenýři sdílí. Přehled UML diagramů viz Obrázek 2.

Obrázek 2: Diagramy UML verze 2.3

Zdroj: http://www.uml-diagrams.org/uml-23-diagrams.html 16

Kaţdý UML diagram zobrazuje popis navrhovaného systému z určitého pohledu. Jsou dvě větve pohledů na systém. Systém lze popsat z hlediska struktury pomocí diagramů struktury a z hlediska dynamiky pomocí behaviorálních diagramů. Jelikoţ by samotné diagramy zobrazené na papíře nebo jako jednoduchý obrázek v počítači ztratily význam, pouţívá se pro další práci s nimi modelovací nástroj. Modelovacím nástrojem pro práci s UML je CASE nástroj. CASE nástroj je zkratkou Computer Aided Software Engineering. CASE nástroj slouží pro podporu analýzy a návrhu aplikací vycházející z UML. Umožňuje propojit jednotlivé modely a zachycuje analytický návrh ve společné repository sdílené vývojáři.

Kanisová, Müller [1]

Repository je právě ta věc, která odděluje CASE nástroje od obyčejných grafických nástrojů pro jednoduché ztvárnění diagramů. Grafické nástroje jsou velice podobné, nedokáţí však dále pracovat s vytvořenými diagramy. Repository je centrální databáze nástroje pro uchování informací o všech objektech modelovaného systému. Díky repositury je moţné dále pracovat s vytvořeným modelem v CASE nástroji. Příkladem je forward engineering, kde se logický model databáze vytvořený v CASE nástroji převede na fyzický model. Repository prověřuje konsistenci a integritu, tj. při změně popisu se popis změní i v navazujících modelech. Další funkcí CASE nástrojů jsou tvorby výstupních reportů, dokumentace a generování kódu. Příkladem generování kódu programu je vygenerování skriptu pro tvorbu tabulek v SQL jazyce nebo vygenerování hlaviček metod z class diagramu. Příkladem CASE nástrojů jsou: Enterprise Architect od Sparx Systems, Select Architect od LBMS nebo Power Designer od Sybase.

17

3 Informační systém pro veterinární stanici Kapitola 3 Informační systém pro veterinární stanici je praktickou částí diplomové práce. Kapitola obsahuje podkapitoly: Úvodní studie, Analýza, Design, Implementace a Testování.

3.1 Úvodní studie 3.1.1

Základní cíle projektu Cílem projektu je vytvořit informační systém nabízející efektivní spolupráci mezi

veterinářem a jeho klienty. Informační systém veterináři umoţňuje zaznamenávat a spravovat informace o zvířatech a klientech. Klientovi systém umoţňuje snadnou registraci z domova a rezervaci termínů návštěv. Aplikace bude jednoduchá a intuitivní na ovládání. Informační systém se bude skládat z těţkého klienta, který bude na osobním počítači veterináře, a z tenkého klienta, který bude dostupný pomocí protokolu HTTP přes Internet. Aplikace bude fungovat na osobním počítači se systémem MS Windows XP a v aplikaci Firefox. 3.1.2

Analýza zákazníka a jeho prostředí Informační systém budou vyuţívat pouze registrovaní uţivatelé. Uţivatelé systému

jsou: veterinář a klienti. Schéma uţivatelů a IS zobrazuje obrázek 3.

Obrázek 3: Schéma uživatelů a IS

Zdroj: vlastní úprava 18

3.1.3

Požadavky na hardware a software Pro provoz aplikace tenkého klienta je potřeba zajistit doménu a webhosting

s moţností provozu ASP a MS.NET Frameworkem. Provoz tlustého klienta bude moţný na osobních počítačích se systémem MS Windows XP Home, případně Profesional edition s nainstalovaným MS.NET Frameworkem 3.5. Uţivatelé systému budou potřebovat k práci v IS osobní počítač se systémem MS Windows XP a webový prohlíţeč Firefox. 3.1.4

Očekávané funkce

Mezi funkce informačního systému patří: 

vytvoření uţivatelského účtu,



správa uţivatelského účtu,



vytvoření karty zvířete,



správa karty zvířete,



vytváření záznamů o návštěvách,



vytváření záznamů o provedených zákrocích a prodaných lécích v rámci návštěvy,



správa seznamů léků a zákroků,



rezervace termínů návštěv.

3.1.5

Charakteristika vstupů, výstupů a rozhranní systému

Veterinář: ← vkládání, mazání, modifikace záznamů o klientech ← vkládání, mazání, modifikace záznamů o zvířatech ← vkládání, mazání, modifikace záznamů o návštěvách ← vkládání, povolení/zamítnutí, modifikace rezervace termínů návštěv ← vkládání, mazání, modifikace ceníků léků a zákroků ← rezervace termínů návštěv → údaje o klientech → údaje o kartách zvířat 19

→ údaje o návštěvách → údaje o cenících léků a zákroků → údaje o rezervacích

Klient: ← vkládání, modifikace záznamů o klientech ← vkládání, modifikace záznamů o zvířatech ← vkládání rezervace termínů návštěv → údaje o klientech → údaje o kartách zvířat → údaje o rezervacích

3.2 Analýza požadavků Analýza poţadavků obsahuje sběr poţadavků, definici slovníku pojmů, definici funkčních a nefunkčních poţadavků a návrh uţivatelského rozhraní. Při sběru poţadavků je důleţité klást důraz na zapojení uţivatelů do tvorby poţadavků, protoţe kvalitní sběr poţadavků ovlivní úspěch celého projektu. Uţivatelé systému jsou veterinář a klienti. Veterinář je primárním uţivatelem systému a bude s ním pracovat kaţdý den. Poţadavky veterináře jsou získávány společnými konzultacemi. Za klienta je vybrán člen vývojového týmu, který reprezentuje klienta.

Slovník pojmů Klient Klient je konkrétní osoba, vlastník zvířete. Klient jedná s veterinářem, domlouvá s veterinářem termín návštěvy veterinární stanice a poţaduje konkrétní úkony od veterináře, které jsou na zvířeti prováděny.

20

Veterinář Veterinář je osoba pracující ve veterinární stanici. Veterinář jedná s klienty, domlouvá s klientem konkrétní termín návštěvy veterinární stanice, provádí poţadované úkony a prodává léky.

Klientský účet Klientský účet je elektronický účet konkrétního klienta. Na svůj klientský účet se klient přihlašuje a můţe vyuţívat klientských funkcí, například rezervace termínů návštěv.

Zvíře Zvíře je konkrétní zvířecí pacient veterinární stanice. Zvíře je majetkem klienta. Zvíře má své potřeby a zdravotní problémy, klient se zvířetem chodí k veterináři na návštěvy.

Karta zvířete Karta zvířete je záznam v databázi, který nahrazuje papírovou kartotéku.

Ţivočišný druh Ţivočišný druh je záznam v seznamu ţivočišných druhů zvířat, které veterinář ošetřuje.

Hrozba Hrozba představuje záznam, který má varovat před moţnými následky. Kaţdé zvíře můţe mít jiné problémy a při aplikaci určitých léků můţe například propuknout neţádoucí účinek. V jiném případě se zase nedoporučuje operovat, například z důvodů rizikovosti anestezie.

21

Návštěva Návštěva je pravidelná nebo nepravidelná docházka klienta se zvířetem do veterinární stanice. Při návštěvě klient poţaduje od veterináře konkrétní úkony, například prohlídka, zákrok nebo prodej léku.

Rezervace termínu návštěvy Rezervace je klientem navrţený termín návštěvy, který musí veterinář potvrdit. Na zamítnutý termín návštěvy nelze se zvířetem přijít.

Druh návštěvy Druh návštěvy je záznam, který popisuje charakter návštěvy. Druhem návštěvy můţe být například běţná prohlídka, provedení zákroku, předepsání léku nebo kompletní sluţba zahrnující operaci zvířete a prodej léků.

Ordinační doba Ordinační doba je záznam ze seznamu, podle kterého veterinář provozuje sluţbu ve veterinární stanici. Ordinační doba se skládá z konkrétních časových bloků určených pro rezervaci termínů a dnů.

Zákrok Zákrok je konkrétní úkon, který provádí veterinář na zvířeti. Příkladem zákroku je ostříhání drápků, čištění zubů, operace zlomenin a jiné.

Ceník zákroku Ceník zákroku je záznam v seznamu nabízených zákroků. Ceník zákroku obsahuje název zákroku, jeho popis a cenu, za kterou je zákrok veterinářem vykonán.

22

Lék Lék je konkrétní přípravek, který veterinář prodává majiteli zvířete pro konečnou spotřebu zvířetem. Příkladem léku je přípravek proti blechám, očkování proti vzteklině, přípravek na výţivu kloubů.

Ceník léku Ceník zákroku je záznam v seznamu nabízených zákroků. Ceník zákroku obsahuje název zákroku, jeho popis a cenu, za kterou je zákrok veterinářem vykonán.

Funkční požadavky R 01. Registrace nového klienta Klient má dvě moţnosti registrace do IS. První moţností je registrace osobní. Klient podstoupí osobní návštěvu veterináře a poţádá o registraci. Druhou moţností je on-line registrace. Klient musí mít moţnost v jakémkoliv okamţiku provést svoji registraci na webové stránce veterinární stanice. Poţadavek registrace nového klienta slouţí pro podporu registrace nových klientů, kteří chtějí vyuţívat sluţeb veterinární stanice. Registrace probíhá vyplněním registračního formuláře v IS veterinární stanice. Ve formuláři je nutné vyplnit přihlašovací údaje a informace o klientovi. Přihlašovací údaje jsou přihlašovací jméno a heslo. Přihlašovací jméno je zároveň email na klienta. Informace o klientovi obsahují jméno a příjmení, místo bydliště a telefon. Registrace klienta on-line ušetří čas veterináři, který tak nemusí registraci provádět osobně.

R 02. Zaloţení karty zvířete Kartu zvířete je moţné zaloţit dvěma způsoby. První způsob zaloţení karty v IS je za pomoci veterináře, který kartu osobně zaloţí při návštěvě. Veterinář nejdříve klienta zaregistruje, poté vytvoří kartu zvířete. Druhý způsob je zaloţení karty on-line. Klient musí mít moţnost zaloţit kartu zvířete v jakýkoliv okamţik na webové stránce veterinární stanice.

23

Zaloţení karty zvířete on-line je podmíněno předchozí registrací klienta, například on-line registrace klienta. Klient můţe mít pod svým klientským účtem vedeno více karet zvířat. Poţadavek zaloţení karty zvířete slouţí pro podporu zakládání karet zvířat. Zaloţení probíhá vyplněním formuláře v IS veterinární stanice. Karta zvířete náleţí ke konkrétnímu klientskému účtu. V IS neexistuje karta zvířete bez klientského účtu. Ve formuláři je nutné vyplnit informace o zvířeti, jako jsou jméno, datum narození, identifikaci a ţivočišný druh. Zaloţení karty zvířete on-line šetří čas veterináře.

R 03. Rezervace termínu Rezervaci termínu je moţné provést dvěma způsoby. První moţností je rezervace osobní. Klient si termín zarezervuje na návštěvě veterinární stanice, kde veterináře poţádá o rezervaci termínu. Druhou moţností je rezervace on-line. Klient musí mít moţnost v jakémkoliv okamţiku provést rezervaci termínu na webové stránce veterinární stanice. Poţadavek rezervace termínu slouţí pro podporu rezervací termínu návštěv. Rezervace probíhá vyplněním formuláře v IS. Rezervace volného termínu spočívá ve výběru konkrétního termínu z nabídky moţných termínů. Obsazené termíny jsou vyřazeny ze seznamu. Rezervovaný termín náleţí ke konkrétní kartě zvířete. Pokud má klient více zvířat, se kterými chce současně navštívit veterináře, musí pro kaţdé zvíře zvlášť provést rezervaci termínu. Klienti, kteří si termín rezervují on-line, potřebují k dokončení rezervace potvrzení termínu veterinářem. Pokud má veterinář čas, termín potvrdí. Pokud veterinář nemá ve stanovený termín čas, termín zamítne. Při rezervaci termínu veterinářem (osobní rezervace) potvrzení není potřebné.

R 04. Zaznamenání návštěvy Zaznamenání návštěvy provádí výhradně veterinář. Záznamy o návštěvách jsou vedeny v rámci konkrétní karty zvířete. Rezervované a potvrzené termíny se ukládají mezi seznam návštěv a veterinář poté vyplňuje zbytek zprávy z návštěvy. Poţadavek zaznamenání návštěvy slouţí pro podporu zaznamenání návštěv. Zaznamenání probíhá vyplněním formuláře v IS. Ve formuláři je nutné vyplnit datum, druh návštěvy a popis návštěvy.

24

R 05. Zaznamenání zákroku Zaznamenání zákroku provádí výhradně veterinář. Zákroky se provádí v rámci návštěvy. Záznamy o zákrocích jsou vedeny v rámci konkrétní karty zvířete. Pod konkrétním záznamem o návštěvě jsou vedeny záznamy o proběhlých zákrocích. V rámci jedné návštěvy můţe být provedeno více zákroků. Poţadavek zaznamenání zákroku slouţí pro podporu zaznamenání zákroků, které se provedou na návštěvě veterinární stanice. Zaznamenání probíhá výběrem konkrétního zákroku v ceníku a doplnění detailu provedeného zákroku.

R 06. Zaznamenání hrozby Zaznamenání hrozby provádí výhradně veterinář. Záznamy o hrozbách jsou vedeny v rámci konkrétní karty zvířete. Poţadavek zaznamenání hrozby slouţí pro podporu zaznamenání zjištěných hrozeb, které mohou ohrozit zdravotní stav zvířete.

R 07. Zaznamenání prodeje léku Zaznamenání prodeje léků provádí výhradně veterinář. Prodej léků se provádí v rámci návštěvy. Záznamy o předepsaných lécích se vedou v rámci konkrétní karty zvířete. Pod konkrétním záznamem o návštěvě jsou vedeny záznamy o všech lécích, které veterinář během návštěvy prodal konkrétnímu klientovi. V rámci jedné návštěvy můţe být předepsáno více léků. Poţadavek zaznamenání prodeje léku slouţí pro podporu zaznamenání předepsaných léků v rámci návštěvy. Před prodejem léků veterinář zkontroluje případné hrozby, které mohou ovlivnit zdraví zvířete. Pokud je mezi hrozbami záznam o alergii na určitý lék nebo problém, který nedovoluje lék uţívat, veterinář prodej léku zamítne. Pokud je vše v pořádku a ţádná hrozba spjatá s uţíváním konkrétního léku neexistuje, veterinář lék prodá a prodej zaznamená.

25

R 08. Změna údajů Změnu údajů můţe provést veterinář i klient. Kaţdá ze zmíněných rolí můţe provádět úpravy s jinými právy. Poţadavek změna údajů slouţí pro podporu provádění úprav všemi uţivateli IS.

R 09. Deaktivace karty zvířete Deaktivovat kartu zvířete můţe veterinář. Kaţdá konkrétní karta patří k určitému klientskému účtu. Pro deaktivaci karty zvířete je potřeba vybrat konkrétní klientský účet, pod kterým je uchována karta zvířete a konkrétní kartu deaktivuje. Poţadavek deaktivace karty zvířete slouţí pro podporu deaktivace karet zvířat. Karta zvířete se stane neaktivní a nebude nadále figurovat v seznamu karet zvířat mezi ostatními zvířaty, které pravidelně chodí na prohlídky. Neaktivní (deaktivované) karty zvířat jsou v seznamu neaktivních karet. Pokud je zrušen klientský účet, ke kterému karta zvířete patřila, bude karta odstraněna z DB.

R 10. Deaktivace klientského účtu Deaktivování klientského účtu můţe provést veterinář. Poţadavek deaktivace klientského účtu slouţí pro podporu deaktivace klientských účtů těch klientů, kteří jiţ nebudou vyuţívat sluţeb veterinární stanice. Pro zrušení klientského účtu veterinář vybere konkrétní klientský účet a deaktivuje ho. Klientský účet se stane neaktivní a nebude figurovat v seznamu klientských účtů, které jsou aktivně vyuţívány. Neaktivní (deaktivovaný) klientský účet je v seznamu neaktivních účtů.

R 11. Správa číselníků Spravované číselníky v IS jsou: 

ceník léku,



ceník zákroku,



druh návštěvy,



ordinační doba,

26



Ţivočišný druh.

R 12. Smazání údajů Smazání údajů můţe provést pouze veterinář. Poţadavek změna údajů slouţí pro podporu provádění mazání.

R 13. Přihlášení klienta Poţadavek přihlášení klienta slouţí pro podporu přihlašování klientů do IS veterinární stanice. Pro úspěšné přihlášení musí existovat aktivní klientský účet a klient musí znát své přihlašovací údaje.

Nefunkční požadavky 1. Zabezpečení údajů proti zneuţití Poţadavek zabezpečení údajů proti zneuţití slouţí pro podporu zabezpečení klientských účtů a záznamů vztahujících se k nim. Poţadavek upravuje funkční poţadavek R 13. Přihlášení klienta. Přihlašovací údaj heslo bude zašifrováno za pomocí hašovací funkce MD5 (Message-Digest algorithm).

2. Pouţité technologie K provozu databáze bude pouţito databázového serveru MS SQL serveru 2005. Pro implementaci aplikační a business logic vrstvy bude pouţito Visual studio 2008 konkrétně objektově-orientovaného programovacího jazyku C#.

Uživatelské rozhranní Součástí sběru poţadavků je návrh uţivatelského rozhranní. Návrh slouţí pro vizuální náhled na formuláře pro práci se systémem. Náhled na navrţené formuláře viz obrázek 4: Formulář Klientský účet a obrázek 5: Formulář Karta zvířete. Ostatní navrţené formuláře uţivatelského rozhraní viz příloha 1 strana 1 aţ 3. 27

Obrázek 4: Formulář Klientský účet

Zdroj: vlastní úprava

Obrázek 5: Formulář Karta zvířete


3.3 Analýza Kapitola 3.3 Analýza popisuje výsledky systémové analýzy. Obsahuje use-case model, model tříd objektů, datový model (logický datový model, fyzický datový model) a model objektové spolupráce (sekvenční diagramy). 3.3.1

Use-case model Předloţené poţadavky byly zpracovány do use-case modelu. Z poţadavků byly

zjištěny dvě klíčové role uţivatelů a jejich aktivity.

Zpracované případy uţití 

UC 1: Registrace nového klienta



UC 2: Přihlášení klienta do systému



UC 3: Zaloţení karty zvířete



UC 4: Rezervace termínu



UC 5: Potvrzení termínu



UC 6: Zaznamenání návštěvy



UC 7: Zaznamenání hrozby



UC 8: Zaznamenání zákroku



UC 9: Zaznamenání prodeje léku



UC 10: Změna údajů



UC 11: Deaktivace karty zvířete



UC 12: Deaktivace klientského účtu



UC 13: Aktivace karty zvířete



UC 14: Aktivace klientského účtu



UC 15: Smazání údajů



UC 16: Vloţení ţivočišného druhu



UC 17: Vloţení druhu návštěvy 29



UC 18: Vloţení ceníku zákroku



UC 19: Vloţení ceníku léku



UC 20: Vloţení ordinační doby

UC 1: Registrace nového klienta (viz Diagram 1) Diagram 1: Uc 1 Registrace nového klienta uc 1: Registrace nov ého klie...

Veterinář (from Actors)

Registrace nov ého klienta

(from Use case)

Klient (from Actors)


Actor: Veterinář, Klient Vstupní podmínky: Veterinář spustil aplikaci IS veterinární stanice (osobní registrace). Klient spustí webový prohlíţeč a vstoupí na webovou stránku veterinární stanice (on-line registrace). Hlavní scénář: Veterinář spustí akci vloţení nového klienta do systému stisknutím tlačítka „Nový klient“. Veterinář získá údaje o klientovi a vloţí je do formuláře. Po stisknutí tlačítka „Vloţ klienta“ je klient zaregistrován. Alternativní scénář: Klient spustí akci vloţení nového klienta do systému stisknutím tlačítka „Registrace nového klienta“. 30

Klient vloţí své osobní údaje do webového formuláře. Po stisknutí tlačítka „Zaregistruj“ je klient zaregistrován.

UC 2: Přihlášení klienta do systému (viz Diagram 2) Diagram 2: Uc 2 Přihlášení klienta do systému uc 2: Přihlášení klienta do systému

Přihlášení klienta do systému Klient

(from Use case)

(from Actors)


Actor: Klient Vstupní podmínky: Klient spustí webový prohlíţeč a vstoupí na webovou stránku veterinární stanice. Hlavní scénář: Klient spustí akci přihlášení klienta do systému stisknutím tlačítka „Přihlášení do systému“ Klient vloţí přihlašovací údaje. Po stisknutí tlačítka „Přihlaš“ je klient přihlášen.

31

UC 3: Zaloţení karty zvířete (viz Diagram 3) Diagram 3: Uc 3 Založení karty zvířete


Actor: Veterinář, Klient Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice (osobní zaloţení). Klient spustí webový prohlíţeč, vstoupí na webovou stránku veterinární stanice a přihlásí se (on-line zaloţení). V IS existuje konkrétní klientský účet. Hlavní scénář: Veterinář vybere konkrétní klientský účet ze systému a spustí akci vloţení nové karty zvířete stisknutím tlačítka „Nová karta“. Veterinář získá údaje o zvířeti a vloţí je do formuláře. Po stisknutí tlačítka „Vloţ kartu“ je karta zvířete zaloţena. Alternativní scénář: Klient spustí akci vloţení nové karty do systému stisknutím tlačítka „Nová karta zvířete“. Klient vloţí údaje o zvířeti do webového formuláře. Po stisknutí tlačítka „Vloţ“ je karta zvířete zaloţena.

32

UC 4: Rezervace termínu (viz Diagram 4) Diagram 4: Uc 4 Rezervace termínu


Actor: Veterinář, Klient Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice (osobní rezervace). Klient spustí webový prohlíţeč, vstoupí na webovou stránku veterinární stanice a přihlásí se (on-line rezervace). V IS existuje konkrétní klientský účet a karta zvířete. Hlavní scénář: Veterinář vybere konkrétní klientský účet a poţadovanou kartu zvířete ze systému a spustí akci vloţení nové návštěvy zvířete stisknutím tlačítka „Nová návštěva“. Veterinář vybere datum rezervace z kalendáře, k němu vybere volný termín a druh návštěvy. Po stisknutí tlačítka „Vloţ návštěvu“ je termín zarezervován. Alternativní scénář: Klient vybere poţadovanou kartu zvířete a spustí akci vloţení nové návštěvy zvířete stisknutím tlačítka „Rezervuj nový termín“. Klient vybere datum rezervace z kalendáře, k němu vybere volný termín a druh návštěvy. 33

Po stisknutí tlačítka „Rezervuj“ je termín zarezervován. Následné podmínky: V případě on-line rezervace následuje UC 5 Potvrzení termínu.

UC 5: Potvrzení termínu (viz Diagram 5) Diagram 5: Uc 5 Potvrzení termínu


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. V IS existuje konkrétní klientský účet, karta zvířete a rezervace termínu. Hlavní scénář: Veterinář otevře seznam správy rezervací termínů stisknutím tlačítka „Správa rezervací termínů“. Veterinář vybere konkrétní rezervaci ze seznamu. Po stisknutí tlačítka „Potvrď rezervaci“ je termín návštěvy potvrzen. Alternativní scénář: Po stisknutí tlačítka „Zamítni rezervaci“ je termín návštěvy zamítnut.

34

UC 6: Zaznamenání návštěvy (viz Diagram 6) Diagram 6: Uc 6 Zaznamenání návštěvy


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. V IS existuje konkrétní klientský účet a karta zvířete. Hlavní scénář: Veterinář vybere konkrétní klientský účet a poţadovanou kartu zvířete ze systému a spustí akci vloţení nové návštěvy zvířete stisknutím tlačítka „Nová návštěva“. Veterinář vybere datum rezervace z kalendáře, k němu vybere volný termín a druh návštěvy. Veterinář vloţí údaje o návštěvě do formuláře. Po stisknutí tlačítka „Vloţ návštěvu“ je návštěva zaznamenána. Alternativní scénář: Veterinář vybere konkrétní rezervovaný termín ze systému. Veterinář vloţí údaje o návštěvě do formuláře. 35

Po stisknutí tlačítka „Vloţ návštěvu“ je návštěva zaznamenána.

UC 7: Zaznamenání hrozby (viz Diagram 7) Diagram 7: Uc 7 Zaznamenání hrozby uc 7: Zaznamenání hrozby

Zaznamenání hrozby Veterinář

(from Use case)

(from Actors)


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. V IS existuje konkrétní klientský účet a karta zvířete. Hlavní scénář: Veterinář vybere konkrétní klientský účet a poţadovanou kartu zvířete ze systému a spustí akci vloţení nové hrozby stisknutím tlačítka „Nová hrozba“. Veterinář vloţí údaje o hrozbě do formuláře. Po stisknutí tlačítka „Vloţ hrozbu“ je hrozba zaznamenána.

36

UC 8: Zaznamenání zákroku (viz Diagram 8) Diagram 8: Uc 8 Zaznamenání zákroku


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. V IS existuje konkrétní klientský účet, karta zvířete a záznam návštěvy. Hlavní scénář: Veterinář vybere konkrétní záznam návštěvy ze systému a spustí akci vloţení nového záznamu zákroku stisknutím tlačítka „Zaznamenání zákroku“. Veterinář vloţí údaje o zákroku do formuláře a nalezne v ceníku konkrétní zákrok. Po stisknutí tlačítka „Vloţ záznam zákroku“ je zákrok zaznamenán.

37

UC 9: Zaznamenání prodeje léku (viz Diagram 9) Diagram 9: Uc 9 Zaznamenání prodeje léku


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. V IS existuje konkrétní klientský účet, karta zvířete a záznam návštěvy. Hlavní scénář: Veterinář vybere konkrétní záznam návštěvy ze systému a spustí akci vloţení nového prodeje léku stisknutím tlačítka „Prodej léku“. Veterinář vloţí údaje o prodeji do formuláře a nalezne v ceníku konkrétní lék. Po stisknutí tlačítka „Vloţ prodej léku“ je prodej zaznamenán. Alternativní scénář: V případě zjištění hrozby je prodej léků zamítnut a záznam není proveden.

38

UC 10: Změna údajů (viz Diagram 10) Diagram 10: Uc 10 Změna údajů uc 10: Změna úda...

Veterinář (from Actors)

Změna údaj ů

(from Use case)

Klient (from Actors)


Actor: Veterinář, Klient Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. Klient spustí webový prohlíţeč, vstoupí na webovou stránku veterinární stanice a přihlásí se. Hlavní scénář: Veterinář/Klient vybere údaj k editaci a spustí akci změna údajů. Veterinář/Klient vloţí nové údaje do formuláře Po stisknutí tlačítka „Edituj“ jsou údaje změněny.

39

UC 11: Deaktivace karty zvířete (viz Diagram 11) Diagram 11: Uc 11 Deaktivace karty zvířete


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. V IS existuje konkrétní klientský účet a karta zvířete. Hlavní scénář: Veterinář vybere konkrétní klientský účet. Veterinář vybere poţadovanou kartu zvířete ze systému a spustí akci deaktivace karty zvířete stisknutím tlačítka „Deaktivace karty“. Po stisknutí tlačítka „Ano“ je karta deaktivována. Následné podmínky: Deaktivovaná karta zvířete je nadále v DB evidována jako neaktivní karta zvířete.

40

UC 12: Deaktivace klientského účtu (viz Diagram 12) Diagram 12: Uc 12 Deaktivace klienského účtu uc 12: Deaktiv ace klientského ú...

Deaktiv ace klientského účtu Veterinář (from Use case)

(from Actors)


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. V IS existuje konkrétní klientský účet. Hlavní scénář: Veterinář vybere konkrétní klientský účet a spustí akci deaktivace klientského účtu stisknutím tlačítka „Deaktivace účtu“. Po stisknutí tlačítka „Ano“ je účet deaktivován. Následné podmínky: Deaktivovaný klientský účet je nadále v DB evidován jako neaktivní klientský účet.

UC 13: Aktivace karty zvířete (viz Diagram 13) Diagram 13: Uc 13 Aktivace karty zvířete uc 13: Aktiv ace karty zv íř...

Aktiv ace karty zv ířete Klient

(from Use case)

(from Actors)


41

Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. V IS existuje konkrétní klientský účet a neaktivní karta zvířete. Hlavní scénář: Veterinář vybere konkrétní klientský účet. Veterinář vybere poţadovanou kartu zvířete ze systému a spustí akci aktivace karty zvířete stisknutím tlačítka „Aktivace karty“. Po stisknutí tlačítka „Ano“ je karta aktivována.

UC 14: Aktivace klientského účtu (viz Diagram 14) Diagram 14: UC 14 Aktivace klientského účtu uc 14: Aktiv ace klientského ú...

Aktiv ace klientského účtu Veterinář (from Use case)

(from Actors)


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. V IS existuje neaktivní klientský účet. Hlavní scénář: Veterinář vybere konkrétní klientský účet a spustí akci aktivace klientského účtu stisknutím tlačítka „Aktivace účtu“. Po stisknutí tlačítka „Ano“ je účet aktivován.

42

UC 15: Smazání údajů (viz Diagram 15) Diagram 15: Uc 15 Smazání údajů uc 15: Smazání úda...

Smazání údaj ů

Veterinář

(from Use case)

(from Actors)


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. Hlavní scénář: Veterinář vybere údaj ke smazání a spustí akci smazání údajů. Po stisknutí tlačítka „Ano“ jsou údaje smazány.

UC 16: Vloţení ţivočišného druhu (viz Diagram 16) Diagram 16: Uc 16 Vložení živočišného druhu uc 16: Vložení živ očišného dru...

Vložení živ očišného druhu Veterinář (from Use case)

(from Actors)


43

Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. Hlavní scénář: Vwterinář spustí akci vloţení nového ţivočišného druhu do systému stisknutím tlačítka „Nový ţivočišný druh“. Veterinář vloţí údaje o ţivočišném druhu do formuláře. Po stisknutí tlačítka „Vloţ ţivočišný druh“ je ţivočišný druh vloţen.

UC 17: Vloţení druhu návštěvy (viz Diagram 17) Diagram 17: Vložení druhu návštěvy uc 17: Vložení druhu náv ště...

Vložení druhu náv štěv y Veterinář

(from Use case)

(from Actors)


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. Hlavní scénář: Veterinář spustí akci vloţení nového druhu návštěvy do systému stisknutím tlačítka „Nový druh návštěvy“. Veterinář vloţí údaje o druhu návštěvy do formuláře. Po stisknutí tlačítka „Vloţ druh návštěvy“ je druh návštěvy vloţen.

44

UC 18: Vloţení ceníku zákroku (viz Diagram 18) Diagram 18: Uc 18 Vložení ceníku zázkroku uc 18: Vložení ceníku zákroku

Vložení ceníku zákroku Veterinář

(from Use case)

(from Actors)


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. Hlavní scénář: Veterinář spustí akci vloţení nového ceníku zákroku do systému stisknutím tlačítka „Nový ceník zákroku“. Veterinář vloţí údaje o ceníku zákroku do formuláře. Po stisknutí tlačítka „Vloţ ceník zákroku“ je ceník vloţen.

UC 19: Vloţení ceníku léku (viz Diagram 19) Diagram 19: Uc 19 Vložení ceníku léku uc 19: Vložení ceníku léku

Vložení ceníku léku Veterinář

(from Use case)

(from Actors)


45

Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. Hlavní scénář: Veterinář spustí akci vloţení nového ceníku léku do systému stisknutím tlačítka „Nový ceník léku“. Veterinář vloţí údaje o ceníku léku do formuláře. Po stisknutí tlačítka „Vloţ ceník léku“ je ceník vloţen.

UC 20: Vloţení ordinační doby (viz Diagram 20) Diagram 20: Uc 20 Vložení ordinační doby uc 20: Vložení ordinační doby

Vložení ordinační doby Veterinář (from Use case)

(from Actors)


Actor: Veterinář Vstupní podmínky: Veterinář spustí aplikaci IS veterinární stanice. Hlavní scénář: Veterinář spustí akci vloţení nové ordinační doby do systému stisknutím tlačítka „Nová ordinační doba“. Veterinář vloţí údaje o ordinační době do formuláře. Po stisknutí tlačítka „Vloţ ordinační dobu“ je ordinační doba vloţena.

46

3.3.2

Model tříd objektů Po zpracování use-case modelu bylo přistoupeno k tvorbě modelu tříd objektů.

Z předchozích modelů byly identifikovány tyto třídy: Účet, Klient, Karta, ŢivočišnýDruh, Hrozba, Návštěva, DruhNávštěvy, OrdinačníDoba, Lék, CeníkLéku, Zákrok a CeníkZákroku. Class diagram byl kvůli své velikosti rozdělen na dvě části do diagramu 21: Class diagram IS část 1 a diagramu 22: Class diagram IS část 2.

Diagram 21: Class diagram IS část 1.

Zdroj: Vlastní úprava

47

Třída Účet Je obecnou (rodičovskou) třídou pro účely dědění atributů potomky. Tato třída byla vytvořena za účelem moţného rozšíření systému. Potomkem je třída Klient. Dalšími potomky mohou být třída Veterinář nebo Správce.

Třída Klient Je potomkem třídy Účet. Třída obsahuje metody pro aktivaci, deaktivaci, editaci a smazání účtu dle ID klienta. Metoda VloţKlienta je návratového typu void a pracuje s daty objektu Klient, který je parametrem metody. Metoda VraťKlienta vrací konkrétního klienta dle ID. PřihlašKlienta je metoda totoţná s rozdílem, ţe vrací klienta dle parametrů Email a Heslo. Metody VraťAktivníKlienty a VraťNeaktivníKlienty vrací kolekci klientů dle atributu Příjmení, coţ slouţí jako filtr.

Třída Karta Mezi třídou Klient a Karta se vyskytuje vztah asociace. Třída obsahuje metody aktivaci, deaktivaci, editaci a smazání karty dle ID karty. VloţKartu je návratového typu void a pracuje s daty objektu Karta, který je parametrem metody. Metoda VraťKartu vrací konkrétní kartu dle ID. Metody VraťAktivníKarty a VraťNeaktivníKarty vrací kolekci karet dle atributu ID, coţ je ID klienta (majitele zvířete).

Třída ŢivočišnýDruh Mezi třídou Karta a ŢivočišnýDruh se vyskytuje vztah asociace. Třída ŢivočišnýDruh je číselníkem třídy Karta a obsahuje názvy a popisy ţivočišných druhů. Obsahuje metody editaci a smazání karty dle ID ţivočišného druhu. VloţŢivočišnýDruh je návratového typu void a pracuje s daty objektu ŢivočišnýDruh, který je parametrem metody. Metoda VraťŢivočišnýDruh vrací konkrétní ţivočišný druh dle ID a VraťŢivočišnéDruhy vrací kolekci všech ţivočišných druhů.

48

Třída Hrozba Mezi třídou Karta a Hrozba se vyskytuje vztah asociace. Třída obsahuje metody editaci a smazání hrozby dle ID hrozby. VloţHrozbu je návratového typu void a pracuje s daty objektu Hrozba, který je parametrem metody. Metoda VraťHrozbu vrací konkrétní hrozbu dle ID a VraťHrozby vrací kolekci hrozeb dle atributu ID, coţ je ID karty.

Diagram 22: Class diagram IS část 2.


49

Třída Návštěva Mezi třídou Karta a Návštěva se vyskytuje vztah asociace. Třída obsahuje metody editaci a smazání návštěvy dle ID návštěvy. VloţNávštěvu je návratového typu void a pracuje s daty objektu Návštěva, který je parametrem metody. Metoda VraťNávštěvu vrací konkrétní návštěvu dle ID a VraťNávštěvy vrací kolekci návštěv dle atributu ID, coţ je ID karty. Metody PotvrďRezervaci a ZamítniRezervaci slouţí pro potvrzení nebo zamítnutí rezervace dle ID návštěvy. VraťNovéRezervaceTermínů slouţí pro vrácení kolekce nových rezervací. VraťDnešníNávštěvy vrací kolekci návštěv dle parametru DatumRezervace.

Třída DruhNávštěvy Mezi třídou Návštěva a DruhNávštěvy se vyskytuje vztah asociace. Třída DruhNávštěvy je číselníkem třídy Návštěva a obsahuje názvy a popisy druhů návštěv. Obsahuje metody editaci a smazání druhu dle ID druhu návštěvy. VloţDruhNávštěvy je návratového typu void a pracuje s daty objektu DruhNávštěvy, který je parametrem metody. Metoda VraťDruhNávštěvy vrací konkrétní druh dle ID a VraťDruhyNávštěv vrací kolekci všech druhů.

Třída OrdinačníDoba Mezi třídou Návštěva a OrdinačníDoba se vyskytuje vztah asociace. Obsahuje metody editaci a smazání doby dle ID ordinační doby. VloţOrdinačníDobu je návratového typu void a pracuje s daty objektu OrdinačníDoba, který je parametrem metody. Metoda VraťOrdinačníDobu vrací konkrétní dobu dle ID a VraťOrdinačníDoby vrací kolekci všech ordinačních dob. Metoda VraťVolné termíny vrací kolekci volných termínů dle parametrů DatumRezervace a Den. VraťVolnéTermínyKlient je metoda podobná, která vrací volné termíny přístupné pro klienta.

Třída CeníkZákroku Obsahuje metody editaci a smazání ceníku dle ID ceníku zákroku. VloţCeníkZákroku je návratového typu void a pracuje s daty objektu CeníkZákroku, který je parametrem metody. 50

Metoda VraťCeníkZákroku vrací konkrétní ceník dle ID a VraťCeníkyNávštěv vrací kolekci všech ceníků.

Třída Zákrok Mezi třídami CeníkZákroku - Zákrok a Návštěva - Zákrok se vyskytují vztahy typu asociace. Obsahuje metody editaci a smazání zákroku dle ID zákroku. VloţZákrok je návratového typu void a pracuje s daty objektu Zákrok, který je parametrem metody. Metoda VraťZákrok vrací konkrétní zákrok dle ID a VraťZákroky vrací kolekci všech zákroků.

Třída CeníkLéku Obsahuje metody editaci a smazání ceníku dle ID ceníku léku. VloţCeníkLéku je návratového typu void a pracuje s daty objektu CeníkLéku, který je parametrem metody. Metoda VraťCeníkLéku vrací konkrétní ceník dle ID a VraťCeníkyLéků vrací kolekci všech ceníků.

Třída Lék Mezi třídami CeníkLéku - Lék a Návštěva - Lék se vyskytují vztahy typu asociace. Obsahuje metody editaci a smazání léku dle ID léku. VloţLék je návratového typu void a pracuje s daty objektu Lék, který je parametrem metody. Metoda VraťLék vrací konkrétní lék dle ID a VraťLéky vrací kolekci všech léků.

51

3.3.3

Datový model Dle předloţeného class diagramu byl vytvořen logický datový model s entitami

a vazbami. Logický datový model viz Diagram 23.

Diagram 23: Logický datový model IS


Kaţdá tabulka má svůj primární klíč ID. Vazební tabulky mají cizí klíč označen dle tabulky, se kterou mají vazbu (názevTabulkyID). Příklad označení cizího klíče u tabulky Karta s vazbou na tabulku Klient je KlientID.

Fyzický datový model byl kvůli své velikosti rozdělen na dvě části do diagramu 24: Fyzický datový model IS část 1 a diagramu 25: Fyzický datový model IS část 2. Ve fyzickém modelu byly třídy mapovány na tabulky, atributy se staly sloupci a instance objektů odpovídají řádkům. V modelu se vyskytují dvě vazby M : N rozdělené na vazby 1 : N. Vazebné tabulky jsou tabulka Zákrok a tabulka Lék. Všechny vazby mezi tabulkami jsou typu 1 : N. 52

Diagram 24: Fyzický datový model IS část 1.


53

Diagram 25: Fyzický datový model IS část 2.


3.3.4

Model objektové spolupráce Model objektové spolupráce zobrazuje interakce objektů a pro jejich zobrazení byl

vybrán sekvenční diagram. Sekvenční diagramy byly sestaveny z pohledu veterináře. Diagram 26: Sekvenční diagram zaloţení karty zvířete vychází z UC 3: Zaloţení karty zvířete. Obsahuje entity třídy Klient, ŢivočišnýDruh a Karta. Control třída ControlZaloţKartu představuje business logiku. Boundary třídy jsou formuláře Veterinární stanice, Klientský 54

účet, Nová karta a MessageBox MsgKartaZaloţena.

Diagram 26: Sekvenční diagram založení karty zvířete


55

Diagram 27: Sekvenční diagram rezervace termínu vychází z UC 4: Rezervace termínu. Obsahuje entity třídy Karta, OrdinačníDoba, DruhNávštěvy a Návštěva. Control třída ControlRezervaceTermínu představuje business logiku. Boundary třídy jsou formuláře Klientský účet, Karta zvířete, Nová návštěva a MessageBox MsgRezervaceProvedena.

Diagram 27: Sekvenční diagram rezervace termínu


Diagram 28: Sekvenční diagram zaznamenání zákroku vychází z UC 8: Zaznamenání zákroku. Obsahuje entity třídy Návštěva, CeníkZákroku a Zákrok. Control třída ControlZaznamenáníZákroku představuje business logiku. Boundary třídy jsou formuláře Karta zvířete, Popis návštěvy, Nový záznam zákroku a MessageBox MsgZákrokZaznamenán.

Diagram 28: Sekvenční diagram zaznamenání zákroku


Diagram 29: Sekvenční diagram zaznamenání zákroku vychází z UC 9: Zaznamenání prodeje léku. Obsahuje entity třídy Návštěva, CeníkZákroku a Zákrok. Control třída ControlZaznamenáníProdejeLéku představuje business logiku. Boundary třídy jsou formuláře Karta zvířete, Popis návštěvy, Nový prodej léku a MessageBox MsgProdejLékuZaznamenán.

Diagram 29: Sekvenční diagram prodej léku


3.4 Design Předmětem designu je zaměření na design architektury a výběr konkrétních technologií. Softwarová architektura zobrazuje návrh informačního systému z hlediska komponent, ze kterých je postaven a zobrazuje vazby mezi těmito komponentami. Vazby jsou definovány vzájemným voláním a předáváním dat mezi moduly. Jednotlivé moduly jsou definovány funkcemi, vstupními a výstupními daty.

Voříšek [8]

V rámci softwarové architektury byl vybrán vrstvený model. Vrstvený model představuje stavbu informačního systému z jednotlivých vrstev, kde kaţdá vrstva poskytuje soubor sluţeb. Jako optimální byly zvoleny tři vrstvy: prezentační, business a datová. Návrh jednotlivých vrstev modelu viz Obrázek 6.

Pro účel implementace byly vybrány tyto technologie: 

Objektově-orientovaný jazyk C#,



MS.NET Framework 3.5,



Active server Pages,



ADO.NET,



MS SQL server.

Obrázek 6: Návrh vrstveného modelu


Prezentační vrstva představuje grafické ztvárnění rozhranní mezi uţivatelem a systémem. Je tvořena jednotlivými formuláři a zdrojovým kódem programu. Pro zjednodušení práce s formulářovými prvky jsou vytvořeny user controls. Návrh uţivatelského rozhranní viz kapitola 3.2.1 Sběr poţadavků - Uţivatelské rozhranní obrázek 4 a 5, dále příloha 1: Uţivatelské rozhranní strana 1 - 3. Tlustý klient bude vytvořen jako Winforms aplikace za pomoci MS.NET Frameworku, tenký klient jako webová aplikace vyuţívající ASP. Níţe jsou uvedeny definice jednotlivých technologií. MS.NET Framework slouží jak pro tvorbu webových aplikací a služeb, tak pro vytváření aplikací GUI. Winforms aplikace obsahuje okna, ovládací prvky a nabídky. Prosise [6] Druhou generací webového programování jsou webové formuláře. ASP je součástí MS.NET a obsahuje tento model webových formulářů. Webová aplikace vytvářená pomocí ASP obsahuje dynamické HTML, opakovatelně použité serverové ovládací prvky a skripty.

Prosise [6]

Business vrstva představuje logiku systému. Bude obsahovat třídy se spojením na databázi a definicí, s kterými storavanými procedurami se bude pracovat a jaké parametry jim budou zaslány. Třídy budou vyuţívat ADO.NET. Projekt Classes bude samostatný projekt obsahující objektové třídy. ADO.NET je databázové rozhranní API a je vystavěno jako sada tříd v .NET Frameworku.

Prosise [6]

Datová vrstva představuje reprezentaci databáze. Obsahem budou jednotlivé tabulky a storované procedury. Datová vrstva bude představována projektem v MS SQL serveru.

60

3.5 Implementace prototypu 1 Za účelem přehlednosti a správného postupu byla implementace rozdělena na tři fáze. Kaţdá fáze implementace má svůj konkrétní cíl přehledně rozepsaný do tabulek a jejich výstupem je funkční prototyp. Části prototypu 1 jsou viz tabulka 1.

Tabulka 1: Části prototypu 1

Projekt Class Library Classes Class Library Business Logic  Třída Spojení 

Třída KlientBLL



Třída KartaBLL



Třída ŢivočišnýDruhBLL



Třída HrozbaBLL



Windows Forms Aplication GUI.WinForms

Části projektu Třídy: Účet, Klient, Karta, ŢivočišnýDruh, Hrozba, Návštěva, DruhNávštěvy, OrdinačníDoba, Lék, CeníkLéku, Zákrok, CeníkZákroku Metody: GetConnection Metody: AktivujKlienta, DeaktivujKlienta, EditujKlienta, SmaţKlienta, VloţKlienta, VraťAktivníKlienty, VraťKlienta, VraťNeaktivníKlienty Metody: AktivujKartu, DeaktivujKartu, EditujKartu, SmaţKartu, VloţKartu, VraťAktivníKarty, VraťKartu, VraťNeaktivníKarty Metody: EditujŢivočišnýDruh, SmaţŢivočišnýDruh, VloţŢivočišnýDruh, VraťŢivočišnéDruhy, VraťŢivočišnýDruh Metody: EditujHrozbu, SmaţHrozbu, VloţHrozbu, VraťHrozbu, VraťHrozby Formuláře: VeterinárníStanice, NovýKlient, KlientskýÚčet, KartaNeaktivníhoZvířete, NeaktivníKarty, PopisHrozby, NovýKlient, NováKarta, NovýŢivočišnýDruh, NováHrozba, EditaceKlienta, EditaceKarty, EditaceŢivočišnéhoDruhu, EditaceHrozby, NeaktivníKlientskýÚčet, NeaktivníKlienti, SprávaŢivočišnýchDruhů, KartaZvířete, Controls: hrozbaControl, kartaControl, kartaControl2, klientControl, ţivočišnýDruhControl Zdroj: Vlastní úprava

61

3.5.1

Založení nového projektu ve Visual studiu 2008 Solution je koncepční kontejner řešení a projektů, který obsahuje širokou

škálu nástrojů, designérů, šablon a nastavení.

MSDN [3]

Obrázek 7: Solution ve Visual Studio

Zdroj: http://msdn.microsoft.com/en-us/library/df8st53z.aspx

Pro implementaci navrţeného systému je zapotřebí vytvořit nový Solution, který bude obsahovat jednotlivé projekty napsané v jazyce C#. Project type nového Solution je Windows a template je Empty project. Tím vznikne prázdný Solution, do kterého lze vkládat jednotlivé projekty. Grafické znázornění Solutionu viz Obrázek 7. 3.5.2

Tvorba tříd v C# Jako první projekt vloţený do nového Solution je Class Library. Jednotlivé třídy lze do

prázdného projektu vkládat za pomoci designeru nebo ručně psaného zdrojového kódu. Ve Visual studiu existuje nástroj Class diagram, který slouţí pro návrh tříd v designovém módu. Jednotlivé třídy byly navrţeny v analýze a zaznamenány v CASE nástroji. CASE nástroj lze vyuţít pro vygenerování hlaviček a atributů jednotlivých tříd. Pro tvorbu nových tříd v Class diagramu lze vyuţít metodu drag and drop pro přetaţení obrázku třídy do diagramu. V designeru lze v přehledné tabulce vytvářet jednotlivé atributy třídy a určovat jejich datový typ. Pro zjednodušení práce lze atributy překopírovat z vygenerovaných tříd z CASE nástroje.

62

Vygenerovaný výstup je poté nutné poupravit do formálního tvaru, se kterým pracuje jazyk C#. Náhled na upravený výstup z CASE nástroje viz Zdrojový kód 1: Třída Klient. Zdrojový kód 1: Objektová třída Klient

public class Klient : Účet { public int _ČísloUlice; public string _Město; public string _Obec; public string _Ulice; public int ČísloUlice { get { return _ČísloUlice; } set { _ČísloUlice = value; } } public string Město { get { return _Město; } set { _Město = value; } } public string Obec { get { return _Obec; } set { _Obec = value; } } public string Ulice { get { return _Ulice; } set { _Ulice = value; } } } Zdroj: vlastní úprava

Ve Zdrojovém kódu 1 je vidět, ţe tato třída dědí od třídy Účet. Poděděné atributy jsou ID, Aktivní, Jméno, Příjmení, Email, Heslo, Telefon a Titul. Zdrojový kód 2: Třída Karta zobrazuje třídu Karta, která je ve vztahu asociace s třídou Klient. Třídy, které mají mezi sebou vztahy, obsahují své vlastní atributy a jeden další atribut znázorňující vazbu. Atribut je datového typu asociované třídy. Ve vztahu Klient – Karta obsahuje třída Karta atribut _Klient datového typu Klient. Tato konstrukce funguje jako cizí klíč v databázích. V Class modelu však nefiguruje cizí klíč 63

v podobě čísla odkazující na primární klíč, ale třída obsahující všechny nadefinované atributy. Atribut _Klient tedy působí jako třída ve třídě a obsahuje jméno, příjmení, telefon a další atributy, které byly nadefinovány v třídě.

Zdrojový kód 2: Objektová třída Karta

public class Karta { public bool _Aktivní; private string _DatumNarození; private string _DatumUmrtí; private int _ID; private string _Identifikace; private string _Jméno; private Klient _Klient; private ŢivočišnýDruh _ŢivočišnýDruh; public bool Aktivní { //Metoda get a set } public string DatumNarození { //Metoda get a set } public string DatumUmrtí { //Metoda get a set } public int ID { //Metoda get a set } public string Identifikace { //Metoda get a set } public string Jméno { //Metoda get a set } public Klient Klient { //Metoda get a set } public ŢivočišnýDruh ŢivočišnýDruh { //Metoda get a set } } Zdroj: vlastní úprava

64

Třídy jsou konstruovány tak, aby splňovaly charakter objektově-orientovaného programování. Objekty jsou plně zapouzdřeny do rozhranní a přistupuje se k nim za pomoci vlastností (properties). Vlastnost je dvojice metod, která se navenek tváří jako proměnná. V případě dotazu se provede metoda get a při přiřazování metoda set. Tímto

způsobem

jsou

vytvořeny

všechny

analyzované

Vystavěl [9] třídy

předloţené

k implementaci, které jsou předmětem prototypu 1 - 3. 3.5.3

Tvorba Business Logic Pro započetí práce na BLL (Business Logic Layer) je nutné vloţit do Sloutionu nový

projekt. Vrstva Business Logic se programuje jako Class Library projekt. Do projektu se musí vloţit reference na projekt Classes, ve kterém jsou všechny potřebné třídy. Vkládání referencí na existující knihovny se provádí v konkrétním projektu výběrem nabídky Project → Add Reference → Project → Project Name / Componet Name. Pro spojení Business Logic s databází je za potřebí vloţit do vlastností projektu Connection String. Connection String string se vkládá do konkrétního projektu výběrem nabídky Project → BusinessLogic Properties. V nabídce Settings se vloţí property s názvem ConnectionString, typem string, scopem Application a value. Hodnota Connection Stringu má parametry Data Source, Initial katalog a Integrated security. Při práci s MS SQL serverem Express má Data Source implicitní tvar “název počítače/SQLXPRESS”, Initial Catalog “název databáze” a Integrated Security je nastaveno na True. S vloţením Connection Stringu se vloţí do projektu confing soubor, který je ve formě XML a obsahuje danou konfiguraci. Jako první třídu vloţíme do projektu třídu Spojení, která bude obsahovat metodu spojení s databází a odkazem na Connection String. Třída Spojení viz Zdrojový kód 3. Interakci s databází ADO.NET uskutečňuje pomocí objektu spojení Sql pro MS SQL server. Uvnitř objektu SqlConnection je ConnectionString, řetězec připojení. Prosise [6]

65

Zdrojový kód 3: Třída spojení

public class Spojení { public IDbConnection GetConnection() { IDbConnection Spojení = new SqlConnection(Settings.Default.ConnectionString); //ConnectionString vlozeny v Properties projektu; return Spojení; //metoda vraci connection na moji databazi } } Zdroj: vlastní úprava

Další třídou je třída KartaBLL. V této třídě jsou metody, které byly analyzovány v Class Diagramu. V této části implementace je nutné mít povědomí o struktuře databáze a jednotlivých SQL příkazů. V kaţdé metodě je vytvořena instance třídy Spojení pro vytvoření spojení s databází. Pro práci s databází se vyuţívají storované procedury, které obsahují SQL příkaz. Příkaz (viz Zdrojový kód 4) obsahuje jméno storované procedury a parametry. ADO.NET podporuje storované procedury. Storované procedury jsou definované příkazy, které jsou v databázi a jsou zkompilované. Kompilací se dosahuje výrazného zrychlení.

Prosise [6]

66

Zdrojový kód 4: Volání storované procedury

using (IDbCommand Příkaz = Spojení.CreateCommand()) { Příkaz.CommandText = "VraťAktivníKarty"; Příkaz.CommandType = CommandType.StoredProcedure; //Parametry storované procedury IDbDataParameter Parametr; Parametr = Příkaz.CreateParameter(); Parametr.DbType = DbType.Int32; Parametr.ParameterName = "@ID"; Parametr.Value = ID; Příkaz.Parameters.Add(Parametr); Spojení.Open(); using (IDataReader Čtení = Příkaz.ExecuteReader()) { while (Čtení.Read()) { //Naplnění hodnot ze selectu } } Zdroj: vlastní úprava

Před voláním storované procedury se vytvoří kolekce objektů typu Karta, která se poté v cyklu while postupně naplňuje do té doby, dokud jsou poskytována data k naplnění. Metoda VraťAktivníKarty je návratového typu List, coţ je zmíněná kolekce objektů. Tělo metody obsahuje příkaz return Karty, coţ je instance dané kolekce. Třídy business logiky obsahují různé metody, které jsou v základu stejné. Odlišují se jen storovanými procedurami, které volají. Některé storované procedury obsahují příkazy pro vloţení záznamu do tabulky, jiné z tabulky záznamy vybírají dle určitých kritérií a některé například řádky záznamů maţou. 3.5.4

Tvorba prezentační vrstvy GUI.WinForms Projekt GUI.WinForms tvoří prezentační vrstu ve zvolené architektuře. Do Solutionu

se vkládá jako Widows Forms Aplication. Do projektu se vloţí reference na BusinessLogic a Classes. V projektu figurují dva hlavní prvky. Jedním prvkem jsou formuláře, které plní úlohu uţivatelského rozhranní. Druhým prvkem jsou user controls.

67

3.5.5

User controls V prezentační vrstvě se vytváří jednotlivé formuláře určitého vzhledu, jejichţ funkce

obsahují podprogramy. Pro ulehčení designérské práce na formulářích a vyuţití moţnosti znovupouţití slouţí uţivatelský ovládací prvek user control. V designovém módu se do user controlu vloţí z Toolboxu Table Layout Panel. Table Layout Panel slouţí jako mříţka pro organizaci textových polí a popisků. Vyplnění textových polí kontroluje obsluţná metoda a Error Provider. User control se musí téţ naprogramovat. Vlastní kód user controlu obsahuje metody get a set. Příklad získávání dat z user controlu pomocí metody get viz Zdrojový kód 5. Metoda set slouţí pro vkládání dat do user controlu. V metodě get figuruje příkaz _Karta = value.

Zdrojový kód 5: User control metoda get

get{ _Karta.Aktivní = true; _Karta.Jméno = poleJméno.Text; _Karta.Identifikace = poleIdentifikace.Text; _Karta.DatumNarození = poleDatumNarození.Text; _Karta.DatumUmrtí = poleDatumÚmrtí.Text; ŢivočišnýDruh ŢivočišnýDruh = new ŢivočišnýDruh(); ŢivočišnýDruh.ID = (int) menuŢivočišnýDruh.SelectedValue; _Karta.ŢivočišnýDruh = ŢivočišnýDruh; Klient Klient = new Klient(); Klient.ID = IdKlienta; _Karta.Klient = Klient; return _Karta; } Zdroj: vlastní úprava

V user controlu se vyskytuje dropdown menu, které je naplněné vrácenými řádky z tabulky ŢivočišnýDruh. Naplnění menu se provede voláním metody VraťŢivočišnéDruhy z třídy ŢivočišnýDruhBLL. Aby se data zobrazila při spuštění formuláře, vyuţije se obsluţná metoda události Load. Tělo obsluţné metody Load viz Zdrojový kód 6.

68

Zdrojový kód 6: Tělo metody Load

List<ŢivočišnýDruh> ŢivočišnéDruhy = new List<ŢivočišnýDruh>(); ŢivočišnýDruhBLL ŢivočišnýDruhBLL = new ŢivočišnýDruhBLL(); ŢivočišnéDruhy = ŢivočišnýDruhBLL.VraťŢivočišnéDruhy(); menuŢivočišnýDruh.DataSource = ŢivočišnéDruhy; menuŢivočišnýDruh.DisplayMember = "NázevDruhu"; menuŢivočišnýDruh.ValueMember = "Id"; Zdroj: vlastní úprava

Tělo metody Load obsahuje vytvoření instance ŢivočišnýDruhBLL a vytvoření prázdné kolekce ŢivočišnéDruhy. Kolekce se naplní voláním metody VraťŢivočišnéDruhy. V menu se definuje datasource, coţ je daná kolekce a prvky display member a value member. Display member neboli prvek, který je vidět v menu je NázevDruhu a jeho hodnota, value member je ID. Při výběru konkrétního názvu je vybrána hodnota ID, podle které se najde v databázi konkrétní ţivočišný druh. V user controlu je validace prvků prováděna za pomocí ErrorProvideru a obsluţných metod. Při zjištění, ţe povinné pole nebylo vyplněno obsluţná metoda upozorní uţivatele varovným hlášením viz Zdrojový kód 7: Tělo metody poleJméno_onValidating. Poţadovanou úlohu nelze dokončit, dokud uţivatel nevyplní příslušné pole. Ve zdrojovém kódu metody figuruje parametr sender.

Zdrojový kód 7: Tělo metody poleJméno_onValidating

TextBox tb = sender as TextBox; //Sender - odkaz na ovládací prvek string msg = String.Empty; if (tb != null) { if (tb.Text.Length == 0) { e.Cancel = true; msg = "Prázdná hodnota, naplňte prosím políčko!"; } } errorProvider1.SetError(sender as Control, msg); //ErrorProvider kontroluje zda není pole prázdné Zdroj: vlastní úprava

69

Parametr sender je odkaz na ovládací prvek, který vyvolal událost. Sender se využívá v případech, kdy jedna metoda obsluhuje události více objektů. Vystavěl [9] 3.5.6

Tvorba formulářů Ve formulářích figurují tlačítka, textová pole nebo výběrové nabídky. Příkladem

formuláře je formulář KartaZvířete. Důleţitou částí zdrojového kódu je naplnění user controlu viz Zdrojový kód 8.

Zdrojový kód 8: Naplění user control karta

public Karta Karta { set { kartaControl21.Karta = value; } //Vlatnost (property) metodou set vloţí //data do control } Zdroj: vlastní zpracování

Formulář obsahuje dvě listbox menu, které zobrazují návštěvy a hrozby zvířete. Oba listboxy se plní v metodě Load vytvořením instancí Návštěva a Hrozba a voláním příslušných metod. Pro zobrazení dalších formulářů se volá obsluţná metoda Click příslušného tlačítka. Stisknutím tlačítka se spustí metoda, která zjistí vybranou hodnotu v listboxu seznamHrozeb podle value member, tedy ID. Formulář PopisHrozby se spouští metodou ShowDialog a jeho user control hrozbaControl se naplní voláním metody. V případě, ţe by uţivatel ve formuláři PopisHrozby hrozbu vymazal a jednalo se o poslední záznam, program by při opětovném stisknutí tlačítka havaroval. V případě prázdného listboxu je v metodě Load tlačítko zakázáno. Při smazání posledního záznamu je listbox prázdný, tlačítko je ale stále aktivní.

Z tohoto

důvodu

je

nutné

tlačítko

zakázat

i

v těle

metody

příkazem

tlačítkoZobrazHrozbu.Enabled = false. Při vkládání, mazání a editaci je nutné listbox refreshovat, coţ se provede opětovným voláním metody VraťHrozby a určením datasource listboxu. Náhled viz Zdrojový kód 9: Tělo metody zobrazHrozbu_Click.

70

Zdrojový kód 9: Tělo metody zobrazHrozbu_Click

int idHrozby = (int)seznamHrozeb.SelectedValue; //Vybraná hodnota v listboxu - ID hrozby using (PopisHrozby form = new PopisHrozby()) { Hrozba = HrozbaBLL.VraťHrozbu(idHrozby); form.Hrozba = Hrozba; //Získání hrozby dle ID, zaslání do //formuláře popis hrozby do objektu hrozba form.ShowDialog(); } Zdroj: vlastní zpracování

3.5.7

Tvorba databáze v MS SQL serveru Pro tvorbu databáze je moţné vyuţít MS SQL server management studiu Express, ve

kterém lze jednotlivé tabulky navrhnout pomocí designového módu, aniţ bychom měli znalosti SQL. V designovém módu tvorby tabulky se tabulka tvoří vkládáním názvů sloupců, jejich datového typu a vlastností jako PK (Primary Key) nebo Not NULL. Tvorba celé databáze tímto způsobem je pracná. Práci lze ulehčit vyuţitím funkce Geneterate DDL (Data Definition Language) v CASE nástroji, která vygeneruje skript DDL pro tvorbu tabulky. Náhled na vygenerovaný skript viz Zdrojový kód 10.

Zdrojový kód 10: Vytvářecí skript pro tabulku klient

CREATE TABLE Klient ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), Aktivní varchar(6) NOT NULL, Email varchar(50) NOT NULL, Heslo varchar(50) NOT NULL, Jméno varchar(50) NOT NULL, Příjmení varchar(50) NOT NULL, Telefon varchar(50) NOT NULL, Titul varchar(10), Ulice varchar(50) NOT NULL, ČísloUlice int NOT NULL, Město varchar(50) NOT NULL, Obec varchar(50) NOT NULL, ); Zdroj: vlastní úprava 71

Výstup z CASE nástroje lze vloţit do SQL serveru a potvrzením se tabulka vytvoří. Vytvořená tabulka musí mít určený PK, který bude AUTO_INCREMENT. V MS SQL serveru se nastavení AUTO_INCREMENT provádí za pomoci IDENTITY (Property). Pro nastavení automatického zvyšování hodnoty primárního klíče se používá vlastnost IDENTITY (seed, increment). Vlastnost Identity má dva argumenty. Seed je hodnota, která se nastaví prvnímu řádku vloženému do databázové tabulky. Increment je hodnota, o kterou se navýší hodnota primárního klíče dalšího vloženého řádku. MSDN [3] Definice PK ve vygenerovaném skriptu byla upravena do podoby: ID int NOT NULL PRIMARY KEY IDENTITY(1,1). Referenční integritu u tabulek s vazbou 1:N lze nastavit v CASE nástroji nebo manuálně v MS SQL serveru. Náhled na vygenerovaný skript s určením referenční integrity viz Zdrojový kód 11.

Zdrojový kód 11: Referenční integrita

ALTER TABLE Karta ADD CONSTRAINT FK_Karta_ŢivočišnýDruh FOREIGN KEY ([ŢivočišnýDruhID]) REFERENCES ŢivočišnýDruh ([ID]); ALTER TABLE Karta ADD CONSTRAINT FK_Karta_Klient FOREIGN KEY ([KlientID]) REFERENCES Klient ([ID]); Zdroj: vlastní úprava

Důleţité je, aby vygenerovaný skript fungoval správně, aby ho konkrétní aplikace vykonala. SM SQL server takto vygenerovaný skript nedokázal vykonat a skript musel být upraven. Výsledný řádek referenční integrity vypadá takto: ALTER TABLE Klient ADD CONSTRAINT FK_Klient_Role FOREIGN KEY ([RoleID]) REFERENCES Role ([ID]). Skript byl uveden do korektního stavu doplněním hranatým závorek u PK a FK (Foeign Key). Celý skript pro kompletní vytvoření všech tabulek a vztahů mezi nimu viz Příloha 2: Skript pro tvorbu tabulek databáze strana 1 aţ 4. Součátí tvorby databáze je tvorba storovaných procedur. Příkladem je Zdrojový kód 12: Storovaná procedura VraťAktivníKlienty.

72

Zdrojový kód 12: Storovaná procedura VraťAktivníKlienty

CREATE PROCEDURE VraťAktivníKlienty (@Příjmení varchar(50)) AS BEGIN SELECT ID, Jméno, Příjmení, Město, Ulice, ČísloUlice From Klient where (@Příjmení is null or Příjmení like @Příjmení + '%') AND Aktivní = 'true' order by Příjmení END Zdroj: vlastní úprava

3.6 Implementace prototypu 2 Prototyp 2 vychází z diagramu 22: Class diagram IS část 2. Části prototypu 2 jsou viz tabulka 2: Části prototypu 2.


Projekt Class Library Business Logic Třída NávštěvaBLL Třída DruhNávštěvyBLL Třída OrdinačníDobaBLL Třída CeníkZákrokuBLL Třída ZákrokBLL Třída CeníkLékuBLL Třída LékBLL Windows Forms Aplication GUI.WinForms

Části projektu Metody: EditujNávštěvu, PotvrďRezervaci, SmaţNávštěvu, VloţNávštěvu, VraťDnešníNávštěvy, VraťNávštěvu, VraťNávštěvy, VraťNovéRezervaceTermínů, ZamítniRezervaci Metody: EditujDruhNávštěvy, SmaţDruhNávštěvy, VloţDruhNávštěvy, VraťDruhNávštěvy, VraťDruhyNávštěv Metody: EditujOrdinačníDobu, SmaţOrdinačníDobu, VloţOrdinačníDobu, VraťOrdinačníDobu, VraťOrdinačníDoby, VraťVolnéTermíny Metody: EditujCeníkZákroku, SmaţCeníkZákroku, VloţCeníkZákroku, VraťCeníkyZákroků, VraťCeníkZákroku Metody: EditujZákrok, SmaţZákrok, VloţZákrok, VraťZákrok, VraťZákroky Metody: EditujCeníkLéku, SmaţCeníkLéku, VloţCeníkLéku, VraťCeníkLéku, VraťCeníkyLéků Metody: EditujLék, SmaţLék, VloţLék, VraťLék, VraťLéky Formuláře: DnešníNávštěvy, SprávaRezervacíTermínů, SprávaOrdinačníchDob, SprávaDruhůNávštěv, SprávaCeníkůLéků, SprávaCeníkůZákroků, PopisZákroku, PopisLéku, PopisNávštěvy, NováOrdinačníDoba, NováNávštěva, NovýCeníkLéku, NovýCeníkZákroku, NovýDruhNávštěvy, NovýZáznamZákroku, 73

Projekt Windows Forms Aplication GUI.WinForms

Části projektu NovýProdejLéku, EditaceOrdinačníDoby, EditaceNávštěvy, EditaceCeníkuLéku, EditaceCeníkuZákroku, EditaceDruhuNávštěvy, EditaceLéku, EditaceZákroku Controls: návštěvaControl, návštěvaControl2, DruhNávštěvyControl, ordinačníDobaControl, CeníkZákrokuControl, zákrokControl, zákrokControl2, ceníkLékuControl, lékControl, lékControl2 Zdroj: Vlastní úprava

Kapitola 3.6 Implementace prototypu 2 je zaměřena na popis řešení poţadavku rezervace návštěvy. V business logice se vytvoří třída NávštěvaBLL, která obsahuje metody pro práci s databází. Návštěva má atribut Potvrzeno, který můţe nabýt hodnot true, false a refuse (zamítnuto). S těmito hodnotami se pracuje ve formě stringu. Nově registrované návštěvy veterinářem jsou automaticky true a návštěvy registrované klientem jsou false. Návštěvu s atrubutem Potvrzeno = false je potřeba potvrdit, nebo zamítnout (hodnota refuse). Třída NávštěvaBLL spolupracuje se třídou OrdinačníDobaBLL. OrdinačníDobaBLL obsahuje logiku rozvrhu ordinačních hodin v závislosti na dnech v týdnu a blocích určených hodinovým rozpětím. Při rezervaci termínu návštěvy veterinář nebo klient vybírá konkrétní datum , ke kterému je nabídnut seznam volných termínů. Seznam volných termínů poskytuje metoda VraťVolnéTermíny. Systém pracuje s hodnotami dnů v týdnu ve formě: PO, ÚT, ST, ČT, PÁ, SO A NE. Příklad vloţení nového bloku: Den = “PO“ a Blok = “9:00 - 10:00“. Zobrazení volních termínů nabízí drop down menu menuOrdinačníDoba. Datum se vkládá pomocí ovládacího prvku kalendář. Po zvolení příslušného datumu nastane událost ValueChanged. Zdrojový kód 13 představuje tělo metody obsluhující tuto událost. Zjištěný den v týdnu se upraví do potřebné formy a spolu s datumem je předán metodě, která naplní kolekci volnými termíny. Pokud není vrácen ani jeden termín je zůstane menu prázdné. Při změně datumu v kalendáři jsou volné termíny platné k předchozímu datumu nahrazeny termíny novými (platné k nově vybranému datumu).

74

Zdrojový kód 13: Obslužná metoda menuDatumRezervace_ValueChanged

DayOfWeek DenVTýdnu = menuDatumRezervace.Value.DayOfWeek; ; switch (DenVTýdnu) { case DayOfWeek.Monday: Den = "PO"; break; case DayOfWeek.Tuesday: Den = "ÚT"; break; case DayOfWeek.Wednesday: Den = "ST"; break; case DayOfWeek.Thursday: Den = "ČT"; break; case DayOfWeek.Friday: Den = "PÁ"; break; case DayOfWeek.Saturday: Den = "SO"; break; case DayOfWeek.Sunday: Den = "NE"; break; } DatumRezervace = menuDatumRezervace.Value.Day.ToString() + "." + menuDatumRezervace.Value.Month.ToString() + "." + menuDatumRezervace.Value.Year; OrdinačníDobaBLL OrdinačníDobaBLL = new OrdinačníDobaBLL(); List VolnéTermíny = new List(); VolnéTermíny = OrdinačníDobaBLL.VraťVolnéTermíny(DatumRezervace, Den); menuOrdinačníDoba.DataSource = VolnéTermíny; menuOrdinačníDoba.DisplayMember = "Blok"; menuOrdinačníDoba.ValueMember = "ID"; if (VolnéTermíny.Count == 0) { menuOrdinačníDoba.DisplayMember = ""; menuOrdinačníDoba.ValueMember = ""; } menuOrdinačníDoba.Enabled = true; Zdroj: vlastní úprava

Nejsloţitější storovanou procedurou je procedura VraťVolnéTermíny. Procedura odečítá dvě mnoţiny záznamů. Od mnoţiny všech termínů se odečítá mnoţina schválených termínů, termínů čekajících na schválení a termínů neohlášené návštěvy. Rezervace zamítnuté jsou vyřazeny a konkrétní termín se vrací do seznamu. Náhled viz Zdrojový kód 14: Storovaná procedura VraťVolnéTermíny.

75

Zdrojový kód 14: Storovaná procedura VraťVolnéTermíny

CREATE PROCEDURE VraťVolnéTermíny @DatumRezervace varchar(50), @Den varchar (50) AS BEGIN SELECT OrdinačníDoba.ID, Den, Blok From OrdinačníDoba where OrdinačníDoba.Den = @Den Except SELECT OrdinačníDoba.ID, Den, Blok From OrdinačníDoba Left Join Návštěva ON (OrdinačníDoba.ID=Návštěva.OrdinačníDobaID) where (OrdinačníDoba.ID = Návštěva.OrdinačníDobaID) AND (Návštěva.DatumRezervace = @DatumRezervace) AND (OrdinačníDoba.Den = @Den) AND ((Návštěva.Potvrzeno = 'false') OR (Návštěva.Potvrzeno = 'true')) AND (OrdinačníDoba.Blok <> 'Neohlášená návštěva') order by Den END Zdroj: vlastní úprava

Obsazený termín se identifikuje zjištěním, zda mezi návštěvou a ordinační dobou existuje vazba (OrdinačníDoba.ID = Návštěva.OrdinačníDobaID) a současně zda se jedná o termín potvrzený nebo termín čekající na potvrzení ((Návštěva.Potvrzeno = 'false') OR (Návštěva.Potvrzeno = 'true')). Podmínka (OrdinačníDoba.Blok <> 'Neohlášená návštěva').

76

pro

vyřazení

neohlášených

návštěv je

3.7 Implementace prototypu 3 Prototyp 1 a 2 se zabývá vytvořením tlustého klienta jako Windows Forms Aplication. Prototyp 3 je zaměřen na tvorbu tenkého klienta přidáním projektu Web site do společného Solutionu. Části prototypu 3 jsou viz tabulka 3.


Projekt Class Library Business Logic  Třída KlientBLL

Části projektu

 Třída OrdinačníDobaBLL Web site GUI.Web

Metody: VraťVolnéTermínyKlient

Metody: PřihlašKlienta

Webové formuláře: Index, ÚčetKlienta, Přihlášení, NovýKlient, KartaZvířete, EditaceKlienta, EditaceKarty, NováNávštěva Controls: klientControl, kartaControl, návštěvaControl Ostatní: CSS styleSheet, Masterpage Zdroj: Vlastní úprava

Kapitola 3.7 je zaměřena na popis tvorby projektu GUI.Web. Projekt GUI.Web tvoří prezentační vrstvu ve zvolené architektuře ve formě tenkého klienta. Do projektu se vloţí reference na BusinessLogic a Classes. Projekt obsahuje webové formuláře, webové user controls, masterpage a stylesheetu pro CSS (Cascade style sheets). Masterpage umožňuje vytvářet konzistentní rozložení stránky v aplikaci. Definuje vzhled a chování, použité pro všechny stránky.

MSDN [3]

Pro Vzhled webových stránek byla vytvořena masterpage, jejíţ design byl vytvořen za pomocí kaskádových stylů definovaných ve stylesheetu. Masterpage obsahuje menu s moţností přihlášení/odhlášení nebo registrace nového klienta. Obsah stránek, které mají styl definovaný pomocí masterpage, se objevuje v části zvané contet place holder. Webová aplikace slouţí pro klienty, aby se mohli z domova zaregistrovat do systému a rezervovat si termín pro návštěvu. Přihlašovací heslo klienta je šifrováno hašovací funkcíMD5. Zdrojový kód 15: Přihlášení klienta obsahuje náhled na kontrolu hesla. 77

Zdrojový kód 15: Přihlášení klienta

protected void tlačítkoPřihlašKlienta_Click(object sender, EventArgs e) { KlientBLL KlientBLL = new KlientBLL(); Klient Klient = new Klient(); MD5 md5Hash = MD5.Create(); string Heslo = MD5Hash(md5Hash, poleHeslo.Text); //Vytvoření Hashe ze vstupu Klient = KlientBLL.PřihlašKlienta(poleEmail.Text, Heslo); //Volání metody PřihlašKlienta if (Klient.ID == 0) { lblInfo.Visible = true; } else { Session["klientID"] = Klient.ID; Response.Redirect("ÚčetKlienta.aspx"); //vytvoření session a přesměrování } } static string MD5Hash(MD5 md5Hash, string Vstup) { byte[] data = md5Hash.ComputeHash Encoding.UTF8.GetBytes(Vstup)); //změní vstup (string) na byte array StringBuilder sBuilder = new StringBuilder(); for (int i = 0; i < data.Length; i++) { sBuilder.Append(data[i].ToString("x2")); } //cyklus pro kazdy byte z pole, sformatuje se na hexadecimal return sBuilder.ToString(); //vrati hexadecimalni string } Zdroj: vlastní úprava

78

Kontrola funguje tak, ţe se vstup z textového pole předá metodě MD5Hash, která vytvoří hexadecimální řetězec. Ten je pak předán spolu s přihlašovacím jménem metodě PřihlašKlienta, která údaje kontroluje v databázi.

3.8 Instalace systému Před započetím instalace systému je nutné přejmenovat název počítače na „PC“. Tento krok je nutný z důvodů práce s databází. SQL server vytváří název serveru dle názvu počítače. Ve Visual studiu se zadává Connection String, který obsahuje název serveru a název konkrétní databáze. Connection String je uchován v XML souboru. Connection String se po kompilaci aplikace nedá změnit manuálně v XML souboru. Změna názvu počítače a správně zadaný název databáze umoţní komunikaci systému s vytvořenou databází v MS SQL serveru. Pokud není moţná změna názvu počítače, je potřeba Solution systému otevřít ve Visual Studiu, kde se Connection String přepíše v nastavení projektu BusinessLogic (BusinessLogic - Properties - Settings). Solution je nutné poté zkompilovat. K diplomové práci jsou přiloţeny na CD (viz příloha 3) instalační programy pro MS.NET Framework 3.5, MS.SQL server 2005 Express, MS SQL server management studio a vytvářecí skripty.

Změna názvu počítače Tento počítač - Vlastnosti - Název počítače - tlačítko Změnit - Formulář změny názvu počítače (zde lze změnit jméno počítače)

Instalace MS.NET Frameworku 3.5 (soubor dotNetFx35setup.exe) Instalace MS.NET Frameworku je řízena dle pokynů instalátoru. Pokud je na PC nainstalovaný MS Framework 3.5 a vyšší, instalace není potřebná.

79

Instalace MS SQL serveru 2005 Express (soubor SQLEXPR32.EXE) Pokyny k instalaci MS SQL serveru: 

feature selection (výchozí nastavení),



authentication model (Windows authentication mode),



contiguration options (výchozí nastavení),



error and usage report settings (výchozí nastavení).

Instalace MS SQL server management studio (soubor SQLServer2005_SSMSEE.msi) Při instalaci MS SQL serveru managment studia se postupuje dle pokynů instalátoru.

3.8.1

Tvorba databáze Databáze se vytváří v MS SQL server management studiu. Cesta ke spuštění programu

je následující: nabídka Start - Všechny programy - Microsoft SQL server 2005 - SQL server Management Studio Express. V management studiu je potřeba se přihlásit s uvedenými údaji: server type = Database Engine, server name = PC\SQLEXPRESS, Authentication = Windows Authentication. Postup pro vytvoření databáze je následující: Object explorer - Database - New Database. Pokud však není v nabídce zobrazen nástroj object explorer, zobrazí se výběrem View - Object explorer (F8). Jméno databáze je třeba nastavit na „Veterinární stanice“. 3.8.2

Tvorba tabulek Tabulky se vytváří za pomoci skriptu. Skript se vkládá jako nový dotaz. Postup pro

nový dotaz je následující: Object explorer - Database - Veterinární Stanice - New Query. Nyní je potřeba vloţit text ze souboru Skript-tabulky.txt a vykonat vytvoření tabulek Query Execute (F5).

80

3.8.3

Naplnění tabulek daty Tabulky se naplní daty za pomoci skriptu. Skript se vkládá jako nový dotaz. Do

dotazu se vloţí text ze souboru Skript-data.txt a vykonat vloţení dat Query - Execute (F5). 3.8.4

Vytvoření storovaných procedur Storované procedury se vytvoří za pomoci skriptu. Do dotazu je potřeba vloţit text ze

souboru Skript-storovane_procedury.txt a vykonat vytvoření procedur Query - Execute (F5). 3.8.5

Problémy s vytvářecími skripty Vytvářecí skripty jsou dodány ve formě textového souboru. Problémy, které se u

vytvářecích skriptů objevovaly, jsou zapříčiněny háčky ve slovech. Při kopírování z management studia do textového dokumentu nebyly háčky správně převedeny a SQL příkazy pozbyly správnosti. Vytvářecí skripry byly kontrolovány a chyby s háčky odstraněny. 3.8.6

Spuštění systému K diplomové práci je přiloţen zdrojový kód systému ve sloţce Zdrojový kód. Cesta ke

spustitelnému exe souboru je Zdrojový kód je: GUI.WinForms - Bin - Debug GUI.WinForms.exe. Příloha obsahuje přehled hlavních formulářů a označení orientace. Webovou aplikaci nelze lokálně spustit tak jako Winforms aplikaci. Pro spuštění je zapotřebí vlastnit ASP doménu. Aplikaci lze případně spustit za pomoci Visual studia a lokální databáze vytvořené v MS SQL serveru viz návod výše.

81

4 Závěr Informační systémy slouţí pro získávání, zpracování a analýzu informací. Jsou sadou prvků, mezi které patří například software, hardware, lidé, databáze a postupy. Vědní disciplína, která se zabývá vytvářením softwarových produktů se nazývá softwarové inţenýrství. Softwarové inţenýrství obsahuje aplikace analytických, matematických a vědeckých zásad. Svou roli má v softwarovém inţenýrství i podnikání ve formě minimalizace rizik a nákladů. Projekt softwarového produktu prochází svým ţivotním cyklem. Ţivotní cyklus softwaru se skládá z posloupnosti jednotlivých etap. Jedná se o tyto etapy: analýza poţadavků, systémová analýza, návrh, implementace, testování, provoz a údrţba. Při vývoji softwarových produktů je postup řízen za pomoci metodiky. Objektověorientovaný koncept obsahuje vlastnosti abstrakce, zapouzdření, dědičnost a polymorfizmus. Pro maximální podporu při vývoji aplikací se vyuţívají standardy a nástroje pro sjednocení práce členů vývojového týmu. Jako široce uznávaný standard je vyuţíván UML, coţ je grafický nástroj pro vizuální modelování. Nástroj pro práci s UML je CASE nástroj. CASE nástroj má repository, coţ je centrální databáze nástroje pro uchování informací o všech objektech modelovaného systému. Příkladem CASE nástrojů jsou Enterprise Architect od Spark Systems, Select architect od LBMS a Power Designer od Sybase.

Hlavním cíle diplomové práce byl návrh a implementace informačního systém pro veterinární stanici v prostředí Visual studio, C#. První kapitola praktické části diplomové práce je úvodní dtudie, která popisuje základní cíle projektu, analýzu zákazníka a jeho prostředí, poţadavky na hardware a software, očekávané funkce a analýzu vstupů a výstupů. Při sběru poţadavků byl definován slovník pojmů, funkční a nefunkční poţadavky a návrh uţivatelského rozhranní. Slovník pojmů definuje všechny klíčové pojmy. Funkční poţadavky popisují funkcionalitu systému. Mezi nefunkční poţadavky byly identifikovány například poţadavek ochrany přihlašovacího údaje za pomoci hašovací funkce MD5. Byl předán téţ návrh formulářů s rozmístěním ovládacích prvků. Identifikované poţadavky byly předány k vytvoření analytického modelu. Byly vytvořeny use-case diagramy, které jsou očíslovány. Kaţdý use-case je textově popsán a representován grafickým znázorněním. Dále byl vytvořen model objektových tříd a datový model. Byly identifikovány atributy tříd a jejich metody. Pro zobrazení dynamického pohledu na systém byly sestaveny sekvenční diagramy. V designu byl 82

zvolen v rámci softwarové architektury vrstvený model, konkrétně třívrstvý. Presentační vrstvu tvoří Winforms aplikace a webová aplikace. Business vrstvu tvoří třídy pro práci s databází. V datové vrstvě byly vytvořeny tabulky a storované procedury. Pro účely implementace byly zvoleny technologie MS. NET Framework 3.5, ASP.NET, ADO.NET, MS SQL server a jazyk C#. Implementace systému byla rozdělena do tří fází. K diplomové práci je přiloţen prototyp 3, který obsahuje funkcionalitu stanovenou v analýze. Práce předkládá detailně zpracovanou analýzu a implementovaný systém.

V diplomové práci nebylo řešeno testování implementovaného systému. Systém by mohl být testován za pomoci black-box testu a white-box testu. Black-box testem by mohlo být kontrolováno vkládání do databáze, například vkládání nového klienta a zvířete. White-box testem by mohlo být kontrolováno vytvoření nové rezervace. White-box test by zobrazoval trasu od vstupu datumu, kde by se kontrolovalo vrácení volných termínů včetně neohlášené návštěvy. Pro detailní testování by mohl být vyuţit test-case.

Při řešení implementace systému se vyskytovaly problémy, které byly následně po odhalení řešeny. Popis problémů a jejich řešení viz níţe. Při generování kódu z Enterprise Architectu byla potřeba zdrojový kód upravit, protoţe s ním MS SQL server nedokázal správně pracovat. Při vytváření referenční integrity musely být primární klíč a cizí klíč v hranatých závorkách. Pro automatické zvyšování hodnoty primárního klíče byla vloţena vlastnost IDENTITY (seed, increment). Při smazání posledního údaje, respektive deaktivaci, bylo menu listboxu prázdné a při stisknutí tlačítka pro zobrazení záznamu nastal pád systému. Z toho důvodu bylo v obsluţné metodě pro událost Click nutné tlačítko vyřadit z provozu. Při nové rezervaci termínu se při změně datumu zobrazovaly předchozí (neplatné) termíny, popřípadě se zobrazovaly vícekrát v závislosti na události value changed kalendářového menu. Pro odstranění duplicitních a neplatných záznamů byl v těle metody proveden refresh. Pokud nebyl nabídnut volný termín, bylo menu v metodě smazáno, čímţ byly odstraněny staré záznamy.

83

Při tvorbě webové aplikace nastaly problémy s editací klienta a karty. Při editaci se uţivateli zobrazil formulář s přednastavenými hodnotami (stávající hodnoty z databáze), které uţivatel mohl přepsat hodnotami novými. Po vloţení nových dat zůstala v databázi data původní, kromě hesla, které bylo nahrazeno prázdným znakem. V případě, ţe byl uţivateli předán prázdný formulář, nově vloţená data se úspěšně vloţila do databáze. Tento problém se ve Winforms aplikaci nevyskytoval, z důvodů stavby na principu událostního zpracování. Problém byl částečně řešen zakázáním editace některých atributů. Uţivatel při změně atributu musí vyplnit prázdné pole bez zobrazení staré hodnoty atributu.

Hlavním cílem diplomové práce bylo odevzdání funkčního informačního systému pro veterinární stanici. Tento cíl byl splněn. Informační systém obsahuje aplikaci Winforms, kterou lze dle návodu zprovoznit na jakémkoliv počítači se systémem MS Windows XP, MS Frameworkem 3.5 a MS SQL serveru. Dále obsahuje webovou aplikaci, kterou však nelze spustit z důvodů potřeby ASP domény. Webový projekt lze spustit za pomocí Visual studia, ve kterém byl naprogramován. Práce byla zaměřena na praktickou činnost.

Vlastním přínosem je prokázání schopnosti vytvořit přehlednou analýzu, jednoduchý návrh systému s výběrem softwarové architektury a implementaci systému. Implementovaný systém obsahuje analyzovanou funkcionalitu a je jednoduchý pro ovládání.

Do budoucna lze práci zaměřit na zdokonalování systému. Systém by mohl být zdokonalen například zavedením dalších filtrů pro hledání klienta, dle bydliště. Dále by systém mohl být vylepšen implementací funkcionality pro tvorbu tisknutelných sestav, například faktura prodeje léku nebo výpis provedeného zákroku

84

5 Literatura [1]

KANISOVÁ, Hana.; MÜLLER, Miroslav. 2007. UML srozumitelně. 2. vydaní. Brno : Computer press, 2007. 176 s. ISBN 80-251-1083-4.

[2]

KŘENA, Bohuslav.; KOČÍ, Radek. 2006. Úvod do softwarového inţenýrství IUS. [Online] 2006. [Cit. 2012-03-20]. s 99. Dostupný z: http://suave_skola.varak.net/lectures_IUS/opora_IUS.pdf.

[3]

MSDN. MSDN Library. [Online] Microsofs. [Cit. 2012-02-12]. Dostupný z: http://msdn.microsoft.com/library/default.aspx.

[4]

PODESWA, Howard. 2009. UML for IT business analysis. 2. vydaní. Boston : Course Technology, 2009. s 372. ISBN 978-1-59863-868-4.

[5]

PRESSMAN, Roger. 2001. Software Engineering. 5. vydaní. New York : McGrawHill Higher Education, 2001. s 854. ISBN 978-0-07-365578-3.

[6]

PROSISE, Jeff. 2003. Programování v Microsoft.NET. Brno : Computer press, 2003. s 711. ISBN 80-7226-879-1.

[7]

SOMMERVILLE, Ian. 2007. Software Engineering. 8. vydaní. Harlow : Addison Wesley, 2007. s 837. ISBN 978-0-321-31379-9.

[8]

VOŘÍŠEK, Jiří. 2007. Informační systémy a jejich řízení. 3. vydaní. Praha : Bankovní institut vysoká škola, 2007. s 278. ISBN 978-80-7265-100-9.

[9]

VYSTAVĚL, Radek. 2008. Moderní programování: pro středně pokročilé. 1. vydaní. Ondřejov : moderníProgramování s.r.o., 2008. s 191. ISBN 978-80-903951-2-1.

[10]

WASSON, Charles. 2006. System Analysis, Design, and Development Concepts, Principles, and Practices. New Jersey : Wiley & Sons, 2006. s 817. ISBN 978-0-471-39333-7.

85

6 Seznam zkratek ADO.NET - ActiveX data object for .NET API - Application programming interface ASP.NET - Actice server pages for .NET BLL - Business logic Layer CASE - Computer aided software engineering CSS - Cascade style sheets DB - Data base FK - Foreign key GUI - Graphical user interface HTTP - Hypertext tranfer protocol ID - Identity IS -Information systém MD5 - Message diggest algorithm MS - Microsoft PK - Primary key SQL - Structured query language SW - Software UC - Use-case UML - Unified modelling langure XML - Extensible markup language

86

7 Seznam obrázků Obrázek 1: Vodopádový model ţivotního cyklu ...................................................................... 12 Obrázek 2: Diagramy UML verze 2.3 ...................................................................................... 16 Obrázek 3: Schéma uţivatelů a IS ............................................................................................ 18 Obrázek 4: Formulář Klientský účet ........................................................................................ 28 Obrázek 5: Formulář Karta zvířete ........................................................................................... 28 Obrázek 6: Návrh vrstveného modelu ...................................................................................... 59 Obrázek 7: Solution ve Visual Studio ...................................................................................... 62

8 Seznam Diagramů Diagram 1: Uc 1 Registrace nového klienta ............................................................................. 30 Diagram 2: Uc 2 Přihlášení klienta do systému ....................................................................... 31 Diagram 3: Uc 3 Zaloţení karty zvířete ................................................................................... 32 Diagram 4: Uc 4 Rezervace termínu ........................................................................................ 33 Diagram 5: Uc 5 Potvrzení termínu .......................................................................................... 34 Diagram 6: Uc 6 Zaznamenání návštěvy .................................................................................. 35 Diagram 7: Uc 7 Zaznamenání hrozby ..................................................................................... 36 Diagram 8: Uc 8 Zaznamenání zákroku ................................................................................... 37 Diagram 9: Uc 9 Zaznamenání prodeje léku ............................................................................ 38 Diagram 10: Uc 10 Změna údajů ............................................................................................. 39 Diagram 11: Uc 11 Deaktivace karty zvířete ........................................................................... 40 Diagram 12: Uc 12 Deaktivace klienského účtu ...................................................................... 41 87

Diagram 13: Uc 13 Aktivace karty zvířete ............................................................................... 41 Diagram 14: UC 14 Aktivace klientského účtu ........................................................................ 42 Diagram 15: Uc 15 Smazání údajů ........................................................................................... 43 Diagram 16: Uc 16 Vloţení ţivočišného druhu ....................................................................... 43 Diagram 17: Vloţení druhu návštěvy ....................................................................................... 44 Diagram 18: Uc 18 Vloţení ceníku zázkroku .......................................................................... 45 Diagram 19: Uc 19 Vloţení ceníku léku .................................................................................. 45 Diagram 20: Uc 20 Vloţení ordinační doby ............................................................................. 46 Diagram 21: Class diagram IS část 1........................................................................................ 47 Diagram 22: Class diagram IS část 2........................................................................................ 49 Diagram 23: Logický datový model IS .................................................................................... 52 Diagram 24: Fyzický datový model IS část 1........................................................................... 53 Diagram 25: Fyzický datový model IS část 2........................................................................... 54 Diagram 26: Sekvenční diagram zaloţení karty zvířete ........................................................... 55 Diagram 27: Sekvenční diagram rezervace termínu................................................................. 56 Diagram 28: Sekvenční diagram zaznamenání zákroku........................................................... 57 Diagram 29: Sekvenční diagram prodej léku ........................................................................... 58

9 Seznam zdrojových kódů Zdrojový kód 1: Objektová třída Klient ................................................................................... 63 Zdrojový kód 2: Objektová třída Karta .................................................................................... 64 Zdrojový kód 3: Třída spojení .................................................................................................. 66 Zdrojový kód 4: Volání storované procedury........................................................................... 67 Zdrojový kód 5: User control metoda get ................................................................................. 68 88

Zdrojový kód 6: Tělo metody Load.......................................................................................... 69 Zdrojový kód 7: Tělo metody poleJméno_onValidating .......................................................... 69 Zdrojový kód 8: Naplění user control karta ............................................................................. 70 Zdrojový kód 9: Tělo metody zobrazHrozbu_Click................................................................. 71 Zdrojový kód 10: Vytvářecí skript pro tabulku klient .............................................................. 71 Zdrojový kód 11: Referenční integrita ..................................................................................... 72 Zdrojový kód 12: Storovaná procedura VraťAktivníKlienty ................................................... 73 Zdrojový kód 13: Obsluţná metoda menuDatumRezervace_ValueChanged .......................... 75 Zdrojový kód 14: Storovaná procedura VraťVolnéTermíny .................................................... 76 Zdrojový kód 15: Přihlášení klienta ......................................................................................... 78

10 Přílohy Příloha 1: Uţivatelské rozhranní………………………………………………………... 1 - 3 Příloha 2: Skript pro tvorbu tabulek databáze.……………………..…………………… 1 - 4 Příloha 3: CD.....................................................................................................

89

nosič CD

Příloha 1 Uživatelské rozhranní

Formulář Veterinární stanice

1

Formulář Nová karta

Formulář Nový klient

2

Formulář Popis návštěvy

3

Příloha 2 Skript pro tvorbu tabulek databáze

CREATE TABLE Správce ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), Aktivní varchar(5) NOT NULL, Email varchar(50) NOT NULL, Heslo varchar(50) NOT NULL, Jméno varchar(50) NOT NULL, Příjmení varchar(50) NOT NULL, Telefon varchar(50) NOT NULL, Titul varchar(10), ); CREATE TABLE Veterinář ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), Aktivní varchar(5) NOT NULL, Email varchar(50) NOT NULL, Heslo varchar(50) NOT NULL, Jméno varchar(50) NOT NULL, Příjmení varchar(50) NOT NULL, Telefon varchar(50) NOT NULL, Titul varchar(10), ); CREATE TABLE Klient ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), Aktivní varchar(5) NOT NULL, Email varchar(50), Heslo varchar(50), Jméno varchar(50) NOT NULL, Příjmení varchar(50) NOT NULL, Telefon varchar(50), Titul varchar(10), Ulice varchar(50) NOT NULL, ČísloUlice int NOT NULL, Město varchar(50) NOT NULL, Obec varchar(50) NOT NULL, ); CREATE TABLE ŢivočišnýDruh ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), NázevDruhu varchar(50) NOT NULL, PopisDruhu varchar(250) ); 1

CREATE TABLE Karta ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), Aktivní varchar(5) NOT NULL, DatumNarození varchar(10) NOT NULL, DatumÚmrtí varchar(10), Identifikace varchar(50), Jméno varchar (50) NOT NULL, KlientID int NOT NULL, ŢivočišnýDruhID int NOT NULL ); ALTER TABLE Karta ADD CONSTRAINT FK_Karta_ŢivočišnýDruh FOREIGN KEY ([ŢivočišnýDruhID]) REFERENCES ŢivočišnýDruh ([ID]) ON DELETE CASCADE; ALTER TABLE Karta ADD CONSTRAINT FK_Karta_Klient FOREIGN KEY ([KlientID]) REFERENCES Klient ([ID]) ON DELETE CASCADE; CREATE TABLE Hrozba ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), NázevHrozby varchar(50) NOT NULL, PopisHrozby varchar(250), KartaID int NOT NULL ); ALTER TABLE Hrozba ADD CONSTRAINT FK_Hrozba_Karta FOREIGN KEY ([KartaID]) REFERENCES Karta ([ID]) ON DELETE CASCADE; CREATE TABLE DruhNávštěvy ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), NázevDruhuNávštěvy varchar(50) NOT NULL, PopisDruhuNávštěvy varchar(250) ); CREATE TABLE OrdinačníDoba ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), Blok varchar(50) NOT NULL, Den varchar(10) NOT NULL ); CREATE TABLE Návštěva ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), DatumRezervace varchar(10) NOT NULL, DruhNávštěvyID int NOT NULL, KartaID int NOT NULL, PopisNávštěvy varchar(250), Potvrzeno varchar(6) NOT NULL, OrdinačníDobaID int NOT NULL ); 2

ALTER TABLE Návštěva ADD CONSTRAINT FK_Návštěva_DruhNávštěvy FOREIGN KEY ([DruhNávštěvyID]) REFERENCES DruhNávštěvy ([ID]) ON DELETE CASCADE; ALTER TABLE Návštěva ADD CONSTRAINT FK_Návštěva_Karta FOREIGN KEY ([KartaID]) REFERENCES Karta ([ID]) ON DELETE CASCADE; ALTER TABLE Návštěva ADD CONSTRAINT FK_Návštěva_OrdinačníDoba FOREIGN KEY ([OrdinačníDobaID]) REFERENCES OrdinačníDoba ([ID]) ON DELETE CASCADE; CREATE TABLE CeníkLéku ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), CenaLéku int NOT NULL, NázevLéku varchar(50) NOT NULL, PopisLéku varchar(250) ); CREATE TABLE Lék ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), CeníkLékuID int NOT NULL, DetailyProdejeLéku varchar(250), NávštěvaID int NOT NULL ); ALTER TABLE Lék ADD CONSTRAINT FK_Lék_CeníkLéku FOREIGN KEY ([CeníkLékuID]) REFERENCES CeníkLéku ([ID]) ON DELETE CASCADE; ALTER TABLE Lék ADD CONSTRAINT FK_Lék_Návštěva FOREIGN KEY ([NávštěvaID]) REFERENCES Návštěva ([ID]) ON DELETE CASCADE; CREATE TABLE CeníkZákroku ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), CenaZákroku int NOT NULL, NázevZákroku varchar(50) NOT NULL, PopisZákroku varchar(250) ); CREATE TABLE Zákrok ( ID int NOT NULL PRIMARY KEY IDENTITY(1,1), CeníkZákrokuID int NOT NULL, DetailyProvedenéhoZákroku varchar(250), NávštěvaID int NOT NULL, StavZákroku varchar(250) NOT NULL );

3

ALTER TABLE Zákrok ADD CONSTRAINT FK_Zákrok_CeníkZákroku FOREIGN KEY ([CeníkZákrokuID]) REFERENCES CeníkZákroku ([ID]) ON DELETE CASCADE; ALTER TABLE Zákrok ADD CONSTRAINT FK_Zákrok_Návštěva FOREIGN KEY ([NávštěvaID]) REFERENCES Návštěva ([ID]) ON DELETE CASCADE;

4

Příloha 3 CD Obsah nosiče CD Zdrojový kód informačního systému - sloţka Zdrojový kód Zpracovaná analýza v CASE nástroji - Veterinární stanice.eap Vytvářecí skript pro tabulky - Skript-tabulky.txt Vytvářecí skript pro storované procedury - Skript-storovane_procedury.txt Plnící skript - Skript-data.txt Instalátor MS.NET Frameworku 3.5 - dotNetFx35setup.exe Instalátor MS SQL serveru 2005 - SQLEXPR32.EXE Instalátor MS SQL server management studia - SQLServer2005_SSMSEE.msi

1

Informační systém pro veterinární stanici

Recommend Documents