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: Ing. Vladimír Beneš Praha 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 Ţ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 3 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 Implementace prototypu 2... 73 3.7 Implementace prototypu 3... 77 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 specifikace 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 ošetřuje. Ţivočišný druh je záznam v seznamu ţivočišných druhů zvířat, které veterinář 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 Zdroj: vlastní úprava 28

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) Zdroj: vlastní úprava 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 Actors) (from Use case) Zdroj: vlastní úprava 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 Zdroj: vlastní úprava 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 Zdroj: vlastní úprava 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 Zdroj: vlastní úprava 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 Zdroj: vlastní úprava 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 Actors) (from Use case) Zdroj: vlastní úprava 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 Zdroj: vlastní úprava 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 Zdroj: vlastní úprava 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) Zdroj: vlastní úprava 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 Zdroj: vlastní úprava 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: Deaktivace klientského ú... Deaktiv ace klientského účtu Veterinář (from Actors) (from Use case) Zdroj: vlastní úprava 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: Aktivace karty zvíř... Aktiv ace karty zv ířete Klient (from Actors) (from Use case) Zdroj: vlastní úprava 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: Aktivace klientského ú... Aktiv ace klientského účtu Veterinář (from Actors) (from Use case) Zdroj: vlastní úprava 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 Actors) (from Use case) Zdroj: vlastní úprava 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í živočišného dru... Vložení živ očišného druhu Veterinář (from Actors) (from Use case) Zdroj: vlastní úprava 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 Actors) (from Use case) Zdroj: vlastní úprava 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 Actors) (from Use case) Zdroj: vlastní úprava 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 Actors) (from Use case) Zdroj: vlastní úprava 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 Actors) (from Use case) Zdroj: vlastní úprava 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. Zdroj: Vlastní úprava 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 Zdroj: vlastní úprava 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. Zdroj: Vlastní úprava 53

Diagram 25: Fyzický datový model IS část 2. Zdroj: vlastní úprava 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 Zdroj: vlastní úprava 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 Zdroj: vlastní úprava 56

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 Zdroj: vlastní úprava 57

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 Zdroj: vlastní úprava 58

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 Zdroj: vlastní úprava 59

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. Projekt Class Library Classes Tabulka 1: Části prototypu 1 Class Library Business Logic Třída Spojení Metody: GetConnection Čá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 Třída KlientBLL Metody: AktivujKlienta, DeaktivujKlienta, EditujKlienta, SmaţKlienta, VloţKlienta, VraťAktivníKlienty, VraťKlienta, VraťNeaktivníKlienty Třída KartaBLL Metody: AktivujKartu, DeaktivujKartu, EditujKartu, SmaţKartu, VloţKartu, VraťAktivníKarty, VraťKartu, VraťNeaktivníKarty Třída ŢivočišnýDruhBLL 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 Třída HrozbaBLL Metody: EditujHrozbu, SmaţHrozbu, VloţHrozbu, VraťHrozbu, VraťHrozby Windows Forms Aplication GUI.WinForms 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