Systém pro zubní laboratoř Bakalářská práce
2008
Jaroslav Bělehrad
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Poděkování Děkuji svému vedoucímu RNDr. Radkovi Ošlejškovi, Ph.D za cenné rady a především trpělivost, kterou měl při odborném vedení této práce.
ii
Shrnutí Práce se zabývá objektově orientovanou analýzou a návrhem systému pro zubní laboratoře a využitím modelovacího jazyka UML při jeho vývoji. Praktická část obsahuje objektový návrh systému a návrh grafického uživatelského prostředí včetně jeho implementace.
iii
Klíčová slova Sytém pro zubní laboratoř, UML, objektově orientovaná analýza a návrh, diagram, grafické uživatelské prostředí – GUI, návrh GUI
iv
Obsah 1
Úvod ................................................................................................................................... 1 1.1 Cíl projektu ............................................................................................................ 1 1.2 Systémy s obdobným zaměřením .......................................................................... 1 1.2.1 Program Laboratoř......................................................................................... 1 1.2.2 Program Dent................................................................................................. 2 2 UML ................................................................................................................................... 4 2.1 Historie UML ........................................................................................................ 4 2.2 Diagramy v UML .................................................................................................. 4 2.2.1 Diagram případů užití .................................................................................... 5 2.2.2 Diagram tříd................................................................................................... 5 2.2.3 Diagram balíků .............................................................................................. 6 3 Grafické uživatelské prostředí (GUI) ............................................................................. 7 3.1 Návrh GUI ............................................................................................................. 7 3.1.1 Tvorba dotazníku ........................................................................................... 7 3.1.2 Nasazení dotazníků ........................................................................................ 8 3.1.3 Vyhodnocení dotazníků ................................................................................. 9 4 Návrh systému ................................................................................................................ 11 4.1 Specifikace systému pro zubní laboratoře ........................................................... 11 4.2 Diagram případů užití .......................................................................................... 11 4.3 Textové specifikace případů užití ........................................................................ 13 4.4 Analytický model systému .................................................................................. 15 4.5 Návrhový model systému .................................................................................... 17 4.5.1 Diagram balíků ............................................................................................ 19 4.6 Datový model ...................................................................................................... 20 4.6.1 Databázové modely ..................................................................................... 20 4.6.2 Relační model .............................................................................................. 20 4.6.3 ERD ............................................................................................................. 20 4.7 Tvorba uživatelského prostředí ........................................................................... 21 5 Závěr ................................................................................................................................ 23 Literatura ................................................................................................................................ 24 Příloha A : Textové specifikace případů užití ...................................................................... 25 Příloha B: Záznamy dotazníků ............................................................................................. 35 Příloha C: Obsah přiloženého CD ........................................................................................ 45
v
1 Úvod 1.1 Cíl projektu Cílem projektu je navrhnout nekomerční software pro evidenci zakázek, fakturace a základní administrativní úkony spojené s vedením stomatologické laboratoře. K návrhu tohoto systému mě vedl fakt, že již jeden z níže jmenovaných využívám při administrativní práci pro laboratoř mé sestry a nejsem s ním zcela spokojen. Také k tomu přispívá skutečnost, že na trhu je velmi omezená nabídka programů s podobným zaměřením. Systém by měl pokrýt nejčastěji využívané a nejzákladnější funkce potřebné pro vedení laboratoře. Měl by se vyhnout zbytečným funkčnostem, které s největší pravděpodobností nenajdou využití v praxi. Velký důraz je kladen na jednoduchost a intuitivní ovládání celého systému.
1.2 Systémy s obdobným zaměřením Přes velké množství programů pro stomatology a lékaře obecně je nabídka pro zubní laboratoře velmi strohá. Na internetu lze nalézt pouze dva systémy a to jeden z dílny firmy Hobosoft s příhodným názvem Laboratoř, se kterým mám bohaté zkušenosti a program Dent firmy VAP, který jsem vyzkoušel pouze v demoverzi.
1.2.1
Program Laboratoř
Jak jsem již výše uvedl, s tímto systémem mám nemalé zkušenosti vzhledem k faktu, že jej již téměř dva roky používám na administrativní práci v laboratoři. Program obsahuje veškeré nutné funkce pro vedení účetnictví. Dle vlastních zkušeností z prostředí zubních laboratoří se domnívám, že většina majitelů využívá systém pouze k vedení knihy zakázek, lékařů, laborantů a materiálů, tisku faktur a eventuální agendu skladového hospodářství. Součástí programu jsou navíc například evidence majetku a deník jízd. Celkové rozvržení uživatelského prostředí bych označil za poněkud nepřehledné, i když musím podotknout, že je na tom lépe než konkurenční program Dent. Nalezení některých nastavení, nebo funkcí, může být i pro zdatného uživatele nelehkým úkolem. Příkladem může být nastavení výchozí tiskárny, které jednak nekoresponduje s nastavením operačního systému, a v druhé řadě jeho změna přímo v programu vyžaduje notnou dávku štěstí a trpělivosti, nebo zavolání na uživatelskou podporu. Celkem je při této změně nutné projít přes pět navazujících oken, z nichž tři jsou pojmenovány „vzhled stránky“. Na obrázku č. 1 je možno nalézt ukázku z tohoto programu. Program Laboratoř je komerčním softwarem a je dodáván ve dvou verzích, a to limited pro jediného technika, a standart pro více techniků. K programu je nutné navíc platit každoroční podporu, protože systém je ošetřen tak, aby bez aktualizace, která je poskytována v rámci podpory, nepřešel do dalšího kalendářního roku. [1]
1
Obrázek 1 - Detail zakázky v programu Laboratoř
1.2.2
Program Dent
S tímto programem jsem se seznámil až při psaní bakalářské práce a to v jeho demoverzi, kterou je možno stáhnout na stránkách výrobce. Ten o svém systému přímo uvádí, že se jedná o „ucelený počítačový systém pro evidenci zakázek, výrobků, materiálů zvlášť účtovaných lékařům či pacientům, kalkulaci cen, fakturaci předaných zakázek, výpočty podílových mezd techniků a pro další činnosti související s vedením agendy laboratoře.“ [2] Skutečností je, že program se striktně zaměřuje na problémovou oblast a nesnaží se nahradit účetní systémy. Evidence zakázek poskytuje velké množství operací, které jsou ovšem na první pohled poměrně nejasné a bez zaškolení mohou být pro nezkušeného uživatele matoucí. Ke každé zakázce a její položce je možné vést spoustu dodatečných informací, jako jsou provize pro laboranta nebo procentuální či paušální slevy. Zvláštností je, že systém umožňuje dvojí otevření zakázky, takzvané rychlé a normální. V rychlém otevření jsou kódy zapisovány přímo v okně s otevřenou zakázkou, oproti tomu v normálním režimu je pro zápis otevřeno další dialogové okno s možností zaznamenání dalších detailů. Za slabinu celého systému považuji API, které je dáno použitým vývojovým prostředím 4th Dimension. Náhled uživatelského prostředí je patrný na obrázku č. 2. Dle výrobce je prostředí přehledné, s čímž se bohužel nemohu ztotožnit. Funkce některých ovládacích prvků je nejasná díky absenci popisků a nebo alespoň tzv. tooltip nápovědy.
2
Jedná se opět o komerční software jako u předchozího produktu. Je dodáván celkem ve třech variantách, a to ve verzi s označením Z bez možnosti vedení skladové evidence, verzi S s jedním skladem a poslední verzi M s možností vedení více skladů bez omezení. Další příplatky jsou pouze za nové verze, které ovšem není nutné kupovat. K produktu je poskytována zdarma telefonická podpora, jež není podmíněna nákupem nových verzí. [2]
Obrázek 2 - Detail zakázky při zrychleném otevření v programu Dent
3
2 UML „Jazyk UML (Unified Modeling Language, unifikovaný modelovací jazyk) je univerzální jazyk pro vizuální modelování systémů. Přestože je nejčastěji spojován s modelováním objektově orientovaných softwarových systémů, má mnohem širší využití, což vyplývá z jeho zabudovaných rozšiřovacích mechanismů.“ [3] Je důležité si uvědomit, že jazyk UML není metodika, ale pouze jazyk pro vizuální modelování a byl navržen proto, aby spojil ty nejlepší postupy z modelovacích technik a softwarového inženýrství. Je také koncipován tak, aby jej byly schopny implementovat všechny nástroje CASE (computer-aided software engineering).
2.1 Historie UML Historie UML sahá do roku 1994 kdy se Grady Booch (metodika Booch) a Jim Rumbaugh (OMT – Object Modeling Technique) spojili ve firmě Rational Software (nyní součást IBM) a tím získali majoritní podíl na trhu s metodikami. V roce 1995 na konferenci OOPSLA `95 (ObjectOriented Programming Systems, Languages and Applications) představili pod názvem Unified Metod v.0.8 první výsledky svojí spolupráce. Na sklonku roku 1995 se do týmu přidal Ivar Jacobson (OOSE – Object-Oriented Software Engeneering) z firmy Objectory. Poté následovaly verze 9.0 a 9.1. Zásadní se stala verze 1.0, kdy také došlo ke změně názvu z Unified Method na Unified Modeling Language. V této verzi bylo UML přeloženo konsorciu OMG (Object Management Group) a to jej v roce 1997 adoptovalo jako verzi 1.1. Dále bylo provedeno několik revizí 1.2 (1998), 1.3 (1999), 1.4 (2001) a 1.5 (2002). Vzhledem k tomu, že UML ve verzích 1.x obsahuje nedostatky, přistoupilo konsorcium OMG v roce 2001 k vývoji verze 2.0. Schváleno bylo v červenci roku 2005. Aktuální verze je z listopadu roku 2007 a nese označení 2.1.2. [4]
2.2 Diagramy v UML V UML je celkem 13 diagramů dělících se do dvou skupin – na diagramy struktury a diagramy chování. Diagramy struktury jsou: • diagram tříd (Class Diagram) • diagram složené struktury (Composite Structure Diagram ) • diagram komponent (Component Diagram) • diagram nasazení (Deployment Diagram) • diagram objektů (Object Diagram) • diagram balíčku (Package Diagram)
4
Diagramy schování jsou: • diagram aktivit (Activity Diagram) • diagram případů užití (Use Case Diagram) • diagram stavového automatu (State Machine Diagram) • diagramy interakce (Interaction Diagram) o sekvenční diagram (Sequence Diagram) o diagram komunikace (Communication Diagram) o stručný diagram interakce (Interaction Overview Diagram) o diagram časování (UML Timing Diagram) Při návrhu jsou využity pouze tři typy diagramů, a to diagram případu užití, tříd a diagram balíků, proto jsem se rozhodl je blíže popsat.
2.2.1
Diagram případů užití
Případ užití je souborem scénářů pro používání systému. Každý scénář popisuje jednu funkci systému a tímto způsobem popisuje celý systém. V diagramu vystupuje aktér, který inicializuje každý případ užití. Aktérem je libovolný uživatel systému, který s ním interaguje (například osoba, instituce, jiný informační systém, hardware, čas). Není jím konkrétní osoba, ale role, kterou zastupuje. To znamená, že v jedné roli může vystupovat několik osob a naopak jedna osoba může mít několik rolí. Diagram případů užití je tedy jakýmsi pohledem na funkce systému ze strany uživatele, podává představu o rozsahu projektu a jasně definuje hranice systému. Každý případ užití musí mít také svoji textovou specifikaci. Bohužel k jejich zápisu neexistuje v UML žádný standart. Lze ovšem nalézt spoustu schémat a doporučení jak tyto specifikace psát.
2.2.2
Diagram tříd
Tento diagram zobrazuje pohled na statickou strukturu systému. Popisuje třídy a pomocí vazeb jednotlivé vztahy mezi nimi. Diagram tříd může obsahovat také balíčky. Asociace (association) mezi třídami se zobrazuje plnou čarou a je obousměrná, pokud není šipkou určen směr vazby. Měla by být pojmenována a v tomto případě směr šipky u jména určuje směr čtení. Násobnost u asociace určuje počet objektů ve vztahu. Dalším typem vazby je agregace (aggregation), která je v podstatě speciálním případem asociace pro vztah celek-část. V diagramu se označuje symbolem prázdného diamantu. Tato vazba je asymetrická a tranzitivní, z čehož plyne, že pokud je A součástí B a B je součástí C, pak také A je součástí C, ovšem C nemůže být součástí B. V případě agregace mohou součásti existovat nezávisle na celku a mohou být sdíleny více celky. Existuje ale ještě silnější forma agregace, která je nazývána kompozice (composition). Ta se značí symbolem plného diamantu a je také asymetrická a tranzitivní. Na rozdíl od agregace nemůže součást existovat vně celku a nemůže být sdílena více celky. Pokud je celek zničen, musí zničit i svoje součásti, nebo převést zodpovědnost na jiný objekt. [5]
5
Další vazbou, která se objevuje v diagramu tříd, je generalizace. Ta slouží k zobrazení vztahu mezi obecným a specifičtějším elementem. V diagramu se označuje plnou čarou s nevyplněným trojúhelníkem směřujícím od potomka k předkovi. Poslední a nejobecnější vazbou je závislost (dependency). V diagramu se značí přerušovanou šipkou mezi dvěma elementy a značí, že změna v cílovém elementu může vyžadovat změnu u elementu počátečního. Tento vztah platí pouze ve směru šipky, nikoli naopak.
2.2.3
Diagram balíků
Balíček je element seskupující objekty s velmi těsnými vazbami a vytváří sémantické hranice uvnitř modelu. Poskytují zapouzdřené jmenné prostory, v nichž musí být jedinečné názvy prvků. Chceme-li používat prvek z jiného jmenného prostoru, nestačí pouze určit jeho název, ale je třeba definovat také název jmenného prostoru, ve kterém se nachází. Balíčky mohou být do sebe vnořené. V takovém případě má vnitřní balíček přístup ke všem veřejným prvkům vnějšího balíčku. Oproti tomu vnější balíček nevidí žádné členy balíčku vnitřního, pokud však na nich není explicitně závislý. Mezi balíčky v diagramu mohou existovat některé stejné vazby jako mezi třídami. Jsou jimi generalizace, agregace a závislost. [3]
6
3 Grafické uživatelské prostředí (GUI) Pomineme-li éru děrných štítků, dávkového zadávání příkazů a pozdější nástup příkazového řádku, dostaneme se do roku 1981, kdy v laboratořích firmy Xerox vzniklo první grafické uživatelské prostředí vystavěné na konceptu WIMP (Windows Icons Menus and Pointers). Experimentálně bylo použito na počítači Xerox Alto a později pro komerční účely na strojích Xerox 8010 Star.
3.1 Návrh GUI Vzhledem ke skutečnosti, že většina uživatelů očekává od programu přehlednost a uživatelskou „přítulnost“, rozhodl jsem se této části věnovat zvláštní pozornost. Při návrhu uživatelského prostředí jsem bohužel nenašel žádnou dokumentovanou metodiku, a proto jsem se rozhodl postupovat experimentálně. V průběhu práce jsem se obrátil na potencionální uživatele a osoby se zkušenostmi s podobnými systémy, se kterými jsem grafický návrh konzultoval. Také jsem si připravil dotazník, který jsem při konzultaci využil a sám odpovědi zaznamenával. V úvodní fázi návrhu jsem postupoval pouze dle vlastního uvážení a vytvořil první verzi uživatelského prostředí, která obsahovala mnohé nedostatky. Tuto maketu systému jsem později použil při testování s uživateli a dle jejich připomínek následně přepracoval.
3.1.1
Tvorba dotazníku
Při tvorbě dotazníku jsem se snažil, aby získané informace vedly ke zlepšení a zpřehlednění uživatelského prostředí. Za důležitý prvek považuji intuitivní rozložení a pojmenování prvků v menu. Z toho důvodu jsem si připravil lístky s jednotlivými položkami menu, které jsem při dotazování každému předkládal s úkolem roztřídění do skupin podle vlastního uvážení. Na kartičkách se objevily tyto pojmy: Ceníky Četnosti kódů Dodavatelé Fakturace Kniha zakázek Laboranti Lékaři Materiály Nápověda O programu Obnova/záloha dat Protetické práce Vystavené doklady
7
Co se týká obsahu dotazníku, byl jsem jej nucen po prvním využití částečně přepracovat z důvodu záhy zjištěných různých nedostatků. Původní dotazník byl doplněn o dvě nové otázky a naopak dvě jsem vypustil. Tyto vady lze ovšem nejlépe odhalit až při dotazování. Veškeré pozměňující údaje jsem zaznamenával již během vyplňování, takže jsou všechny informace úplné. Dotazník obsahoval následující úkoly a otázky s případným výběrem odpovědí: Osobní informace: Pohlaví: □ muž □ žena Používáte nějaký program pro vedení administrativy? □ ano □ ne Pokud ano, jaký? Využíváte (znáte) všechny jeho funkce? □ ano □ ne Jste s ním spokojen? □ ano □ ano s výhradami □ ne Otázky a úkoly: Jaké vlastnosti a funkce očekáváte od programu pro stomatologické laboratoře? Rozdělte lístečky do skupin dle vlastního logického uvážení, jak si myslíte, že k sobě patří a skupiny pojmenujte. Jsou vám pojmy jasné? □ ano, všechny □ ano, ale pouze některé □ ne Uveďte případné nejasnosti Orientace v programu: Zdá se vám okno knihy zakázek na první pohled přehledné a jasné? □ ano □ ne Založení nové zakázky považujete za: □ snadné □ snadné po zaškolení □ nejasné i po zaškolení Vyhledání vytvořené zakázky považujete za: □ snadné □ snadné po zaškolení □ nejasné i po zaškolení Je něco, co vám v knize zakázek chybí? □ ne □ ano (uveďte co) Máte ke knize zakázek nějaké výhrady? □ ne □ ano (uveďte jaké) Práce s programem je podle vás: □ snadná □ snadná po zaškolení □ nemožná i po zaškolení Máte k některé z položek (kromě knihy zakázek) nějaké výhrady? □ ne □ ano (uveďte jaké) Chybí vám něco v programu? □ ne □ ano (uveďte co)
3.1.2
Nasazení dotazníků
Vzhledem k nedostatku zubních laborantů v mém okolí není skupina dotazovaných příliš početná a je poněkud různorodá. Celkem jsem oslovil 10 osob a z toho pouze polovina byla z oboru, na který je projekt zaměřen. Před položením otázek jsem se pokusil každého uvést do problému, který zpracovávám, a ujistil se, že bude mít dostatek času na zodpovězení všech otázek, splnění úkolů a představení systému.
8
Po vyplnění první části s osobními údaji jsem každému rozdal lístečky s pojmy a požádal o jejich rozdělení do skupin. Na pořadí zařazení ve skupinách nezáleželo. Zajímavostí bylo, že u osob s minimální znalostí podobných systémů a počítačů obecně se objevovaly stejné problémy. Typickým příkladem bylo nepochopení pojmu obnova/záloha dat, což vedlo k chybnému, nebo přinejmenším nepříliš vhodnému umístění této položky. Nejčastěji byla začleněna k pojmům nápověda a o programu. Tyto položky byly většinou zařazeny jako poslední, z čehož lze soudit, že i jejich určení činilo některým dotazovaným problémy. Po rozřazení následovalo pojmenování jednotlivých skupin pojmů. Při tomto kroku jsem bohužel musel mnohým pomoci s návrhem možných označení. U některých skupin jsem byl nucen je pojmenovat zcela sám. Při dotazu na vyjasnění termínů se objevovaly problémy u stále stejných položek. Byly jimi již výše jmenovaná obnova/záloha dat, četnosti kódů a ceníky. U poslední jmenované bylo ihned po vyplnění prvních dotazníků jasné, že bude muset být přejmenována vhodnějším způsobem na Tisk ceníku. Bez zajímavosti nezůstává skutečnost, že s tímto pojmenováním měl problém úplně každý a dokonce navrhoval i stejné přejmenování. Někteří z dotázaných měli při této příležitosti i několik praktických připomínek, jako například dotaz na zálohu dat před ukončením programu. V další části již přišla na řadu orientace v samotném programu. Pro tuto příležitost jsem měl přichystaný notebook s první vytvořenou verzí uživatelského prostředí. Každému z dotázaných jsem otevřel knihu zakázek a požádal ho, aby naznačil, jakým způsobem by založil novou zakázku a posléze vybral a upravil jednu z dříve vytvořených. V tomto kroku se drtivá většina shodla, že jak vytvoření, tak vyhledání zakázky je snadné v nejhorším případě po zaškolení. Okno bylo všemi označeno za přehledné, nikomu nechyběla žádná funkčnost a celkově zůstala kniha zakázek bez výhrad. Poté jsem s každým prošel všechna okna a zhruba popsal funkce, které by měly být implementovány. Odpovědi na zbývající otázky byly již u všech uživatelů téměř shodné. Práci s programem většina označila za snadnou po zaškolení a v programu nikomu žádná funkčnost nechyběla. K položkám, mimo knihu zakázek, byla jen jediná výhrada a sice ta, že u nestandardních funkcí je nutný podrobnější popis. V závěru jsem ještě chvíli diskutoval o možnostech vylepšení, ale tyto připomínky jsem již do dotazníků nezaznamenával.
3.1.3
Vyhodnocení dotazníků
Celkem se průzkumu účastnilo deset osob, z toho 4 muži a 6 žen. Pouze polovina dotazovaných byla z oboru, na který je systém zaměřen. Čtyři osoby měly praktické zkušenosti s podobnými systémy, ale pouze jedna měla k využívanému systému výhrady. Častým požadavkem na systém byla uživatelská přítulnost a intuitivní ovládání. Velmi často se také objevoval požadavek na vedení skladu. Skladová agenda byla při návrhu zvažována, ovšem nakonec byla implementována pouze evidence materiálů, která je dána zákonnou povinností. Dle vyjádření české obchodní inspekce může být při kontrole požadován seznam materiálů a jejich dodavatelů přímo se podílejících na protetickém výrobku.[6] Problém skladu u zubních laboratoří tkví v tom, že nelze určit přesné množství spotřeby jednotlivých materiálů při vyhotovení zakázky. Nákupy materiálů se uskutečňují po velkých baleních, které se po přijmutí většinou ihned otevírají a zůstávají pak ve spotřebě několik měsíců. Tím
9
by docházelo k přijmutí nové položky na sklad a k jejímu okamžitému vydání a tudíž nadbytečné administrativě, která by neměla odpovídající přínos. Důležitým faktorem pro ovládání a orientaci v programu je uspořádání menu. Na tento problém byl zaměřen úkol s roztříděním lístečků s pojmy. Po vyhodnocení dotazníků jsem se rozhodl přepracovat strukturu menu do podoby, která je znázorněna na obrázku č. 3.
Obrázek 3 - struktura menu
Skupiny obsahují i další položky, které nebyly v průběhu tvorby dotazníku v systému zařazeny, což je dáno skutečností, že některé pojmy, jako jsou výkazy, byly přidány až po vyhodnocení odpovědí, nebo se na ně při původním návrhu zapomnělo, jako tomu je u položky uživatel a nastavení. Okno knihy zakázek doznalo pouze kosmetických změn a to v podobě přejmenování popisů dvou textových polí. Další změny byly provedeny u již dříve zmiňované položky Ceníky, která byla nově přejmenována na Tisk ceníku. Při představní programu všichni z dotázaných odpověděli, že Okno knihy zakázek je přehledné a nic v něm dle jejich názoru nechybí. Drtivá většina oslovených osob by potřebovala pro práci s programem zaškolení, které by však podle vyjádření nemuselo být nijak rozsáhlé. Záznamy odpovědí ze všech dotazníků jsou k dispozici v příloze B. Informace získané z průzkumu byly použity v návrhu GUI finálního prototypu.
10
4 Návrh systému 4.1 Specifikace systému pro zubní laboratoře Systém je určen pro zubní laboratoře s jedním nebo více techniky, jimž by měl umožnit efektivní správu zakázek, lékařů a materiálů. Dále umožnit tvorbu a tisk faktur, štítků k jednotlivým zakázkám, výpočet pracovního výkazu za libovolné období, tisk ceníku protetických prací a funkci pro výpočet spotřeby kovů a statistiky výroby. V programu vystupují celkem tři uživatelské role, které ovšem bude nejspíše zastupovat pouze jeden konkrétní uživatel.
4.2 Diagram případů užití Hlavním aktérem celého systému je vedoucí laboratoře, který má oprávnění spouštět všechny případy užití. V návrhu jsou ještě role účetní a laborant, které jsou specializací aktéra vedoucí laboratoře. Pokud je k systému přihlášen uživatel s oprávněním aktéra laborant, má dovoleno spouštět pouze jediný případ užití a to Změnit zakázku. Účetní se účastní případů užití Tisknout ceník, Prohlížet vystavené faktury, Vytvořit fakturu a Tisknout výkaz. Diagram případů užití zubní laboratoře je na obrázku č. 4. Změnit zakázku – tento případ užití popisuje pouze změnu zakázky ve smyslu přidání, odebrání nebo úpravy položek. Na změnu údajů o pacientovi, identifikace lékaře, který zakázku zadal a laboranta, kterému byla přidělena, nemá aktér oprávnění. Evidovat zakázky – tento případ užití popisuje založení, úpravu nebo vymazání zakázky z knihy zakázek. Součástí tohoto případu užití je případ užití Změnit zakázku. Evidovat lékaře – jde o případ užití, který popisuje tok událostí při vytváření, úpravě a případném vymazání lékaře v navrhovaném systému. Evidovat laboranty – tento případ užití je shodný s předchozím, s tím rozdílem, že na místo lékaře se jedná o záznam laboranta. Evidovat dodavatele – je shodný s předchozími dvěma případy užití, pouze lékař (laborant) je nahrazen objektem dodavatele. Obnovit data – popisuje postup a průběh obnovy dat z dříve provedené zálohy systému. Zálohovat data – popisuje provedení a průběh zálohy dat systému na uživatelem definované umístění. Tisknout ceník – případ užití popisuje uživatelské akce a odezvy systému při tisku ceníku protetických prací. Uživatel má kromě tisku možnost náhledu výstupu. Prohlížet vystavené faktury – jde o případ užití, který popisuje toky událostí při prohlížení vystavených dokladů. Uživatel má možnost nechat zobrazit zakázky obsažené na faktuře v knize zakázek, zadat datum uhrazení, zobrazit náhled dokladu a nebo jej tisknout. Vytvořit fakturu – popisuje vytvoření faktury na dokončené zakázky pro libovolného lékaře.
11
Tisknout výkaz – tento případ užití popisuje tisk pracovního výkazu pro libovolného laboranta za zvolené časové období. Mimo tisku má aktér možnost zobrazit náhled výstupu pro tisk.
Obrázek 4 - Diagram případů užití
12
4.3 Textové specifikace případů užití Ke každému případu užití musí existovat jeho textová specifikace, která by měla obsahovat název případu užití, vstupní podmínky, tok událostí a následné podmínky. Může také obsahovat alternativní toky událostí, které slouží k popisu událostí, jež mohou nastat v různých okamžicích. Každý alternativní tok má své následné podmínky, které nemohou být přidány k následným podmínkám hlavního toku, protože alternativní tok nemusí být vůbec vykonán. Všechny textové specifikace případů užití jsou k dispozici v Příloze A. Zde jsou jen pro příklad uvedeny textové specifikace pro případy užití Změnit zakázku, Evidovat zakázky a Evidovat lékaře. Případ užití: Změnit zakázku Účastníci: Laborant Vstupní podmínky: K systému je přihlášen laborant, je otevřena kniha zakázek Tok událostí: 1. Případ užití začíná, když uživatel zvolí v knize zakázek konkrétní záznam 2. Systém načte a zobrazí detailní informace o zakázce 3. KDYŽ uživatel zvolí na panelu detail položku nový 3.1.
Systém vytvoří novou položku zakázky
3.2.
Uživatel vyplní kód protetické práce
3.3.
POKUD nesouhlasí s žádnou protetickou prací, systém upozorní uživatele
3.4.
JINAK systém načte informace o protetické práci a zobrazí prodejní cenu a název
3.5.
Uživatel vyplní ostatní pole a zvolí položku Nový, NEBO uložit
3.6.
Systém v případě nové položky uloží předchozí a pokračuje od kroku 5.1, NEBO v případě položky uložit uloží změny
4. Uživatel označí v seznamu na panelu detail jednu z položek 5. Systém načte a zobrazí informace o položce 6. KDYŽ Uživatel zvolí Smazat 6.1.
Systém smaže označenou položku zakázky, případ užití končí nebo pokračuje od 3.
7. Uživatel změní údaje na položce zakázky a zvolí uložit 8. Systém uloží změněné údaje 9. Uživatel zavře okno a případ užití končí Následné podmínky: Zakázky byly aktualizovány Alternativní tok: Okno Knihy zakázek může být kdykoli uzavřeno Následné podmínky: Neuložené informace budou ztraceny
13
Případ užití: Evidovat zakázky Účastníci: Vedoucí laboratoře Vstupní podmínky: K systému je přihlášen vedoucí laboratoře Tok událostí: 1. Případ užití začíná zvolením položky Kniha zakázek z financí 2. Systém zobrazí okno s knihou zakázek 3. KDYŽ uživatel zvolí Nová pro vytvoření nové zakázky 3.1.
Systém vytvoří novou zakázku a zobrazí novou položku v seznamu zakázek s navazujícím číslem
4. KDYŽ Uživatel zvolí položku Hledání 4.1.
Systém zobrazí dialog hledání
4.2.
Uživatel zadá klíčové slovo a zvolí hledat
4.3.
Systém prohledá databázi zakázek a zobrazí záznamy odpovídající hledanému výrazu
5. Uživatel zvolí v seznamu zakázek konkrétní záznam 6. Systém načte a zobrazí detailní informace 7. KDYŽ Uživatel zvolí Smazat 7.1.
systém se dotáže uživatele, zda chce opravdu záznam smazat
7.2.
POKUD uživatel volbu potvrdí systém smaže zakázku případ užití pokračuje bodem 3.
7.3.
JINAK zakázka zůstává beze změn, případ užití pokračuje
8. Zahrnout (Změnit zakázku) 9. Uživatel změní na katě detaily informace o zakázce a zvolí uložit 10. Systém uloží změněné informace 11. Uživatel zavře okno a případ užití končí, NEBO může pokračovat znovu od bodu 3. Následné podmínky: Zakázky byly aktualizovány Alternativní tok 1: Okno Knihy zakázek může být kdykoli uzavřeno Následné podmínky: Neuložené informace budou ztraceny Alternativní tok 2: V okně knihy zakázek na panelu Zobrazení mohou být kdykoli vybrány omezující parametry zobrazení seznamu zakázek Následné podmínky: Seznam zakázek bude aktualizován dle zadaných kritérií
Případ užití: Evidovat lékaře Účastníci: Vedoucí laboratoře
14
Vstupní podmínky: K systému je přihlášen vedoucí laboratoře, je otevřeno okno Lékaři Tok událostí: 1. Případ užití začíná zvolením položky Lékaři z adresáře 2. Systém zobrazí okno s evidencí lékařů 3. KDYŽ Uživatel zvolí položku Nový pro vytvoření nového lékaře 3.1.
Systém vytvoří nového lékaře a zobrazí novou položku v seznamu lékařů s navazujícím číslem
1. KDYŽ Uživatel zvolí položku Hledání 1.1.
Systém zobrazí dialog hledání
1.2.
Uživatel zadá klíčové slovo a zvolí hledat
1.3.
Systém prohledá databázi lékařů a zobrazí záznamy odpovídající hledanému výrazu
2. Uživatel zvolí v seznamu lékařů konkrétní záznam 3. Systém načte a zobrazí detailní informace 4. KDYŽ Uživatel zvolí Smazat 4.1.
Systém smaže záznam lékaře, případ užití pokračuje bodem 10
5. Uživatel změní údaje v panelu detaily a zvolí Uložit 6. Systém uloží změněné informace 7. Uživatel zavře okno a případ užití končí, NEBO může pokračovat znovu od bodu 3. Následné podmínky: Databáze lékařů byla aktualizována Alternativní tok: Okno Lékaři může být kdykoli uzavřeno Následné podmínky: Neuložené informace budou ztraceny
4.4 Analytický model systému Při vytváření analytického modelu bylo nutné identifikovat jednotlivé základní třídy, určit jejich atributy, základní operace a zobrazit, jak budou vypadat vazby mezi nimi. Po prozkoumání problémové domény byly nalezeny následující třídy: Zakázka (Order), Protetická práce (Prothetic), Faktura (Invoice), Materiál (Material) a třída Osoba (Person), která je dále specializována na třídy Laborant (Technician), Lékař (Dentist) a Dodavatel (Supplier). U každé zakázky je vedeno datum, kdy byla přijata a datum dokončení. Dále informace o pacientovi, identifikace laboranta, kterému byla práce přidělena, lékaře, který práci zadal, kódy jednotlivých protetických prací a případně kód a množství spotřebovaného kovu. U položek zakázky je nutné vzít v úvahu možnost výskytu duplicit a to z důvodu, že pojišťovny předepisují u některých kódů maximální možné množství (počet měrných jednotek) vykázané na řádku a lékaři se tímto drží i při komunikaci s laboratoří.
15
Každá protetická práce a kov má svůj jednoznačný kód, který si určuje laboratoř, ovšem pro zjednodušení práce a komunikace se stomatology jsou používány číselníky poskytované zdravotní pojišťovnou. Tyto seznamy kódů jsou vydávány pro potřeby zubních lékařů, nikoli však stomatologických laboratoří. To je způsobeno skutečností, že laboratoře nejsou, na rozdíl od stomatologů, smluvními partnery pojišťoven. [7] V číselníku jsou uvedeny všechny potřebné informace o daném protetickém výrobku, jako jsou název, způsob a výše úhrady zdravotní pojišťovnou, typ kódu a mnoho dalších, pro využití laboratoře již nepodstatných údajů. Z pohledu návrhu a implementace je vhodné poznamenat, že číselníky jsou vydávány pravidelně, jsou k dispozici v elektronické podobě na stránkách VZP a mají přesně danou a dokumentovanou strukturu, čehož lze s výhodou využít. U každé protetické práce musí být také vedena kalkulovaná cena, která vychází z průměrné materiálové spotřeby a časových nároků na výrobu. Tyto kalkulace většinou provádí specializované firmy. U každého materiálu je uvedeno kódové označení, název, jednotka, množství v balení, katalogová cena a dodavatel. Evidence materiálů a jejich dodavatelů je ve stávajícím systému pouze z toho důvodu, že každá laboratoř má zákonnou povinnost vést tyto informace. Toto je ošetřeno nařízením vlády č. 336/2008 sb. Později může být tato agenda rozšířena v plnohodnotný sklad materiálů.[6] U každého dodavatele, lékaře nebo laboranta jsou vedeny pouze základní údaje, jako jsou jméno, popřípadě název firmy, adresa, IČO (identifikační číslo organizace) a číslo účtu. Diagram analytického návrhu tříd je patrný na obrázku č. 5.
Obrázek 5 - Analytický model systému
16
4.5 Návrhový model systému Při návrhu systému jsem se snažil striktně oddělit třídy pro manipulaci s daty, které mají přístup do databáze, od tříd obstarávající operační logiku celého systému a tříd, které implementují uživatelské prostředí. Tím systém vyhovuje třívrstvému modelu architektury aplikací, který rozlišuje následující vrstvy:
Prezentační vrstva – obsahuje funkce uživatelského rozhraní. Těchto vrstev může být v sytému více pro různá prostředí nebo platformy. Tuto vrstvu představují v modelu třídy se stereotypem <
> Aplikační vrstva – tvoří prostředníka mezi datovou a prezentační vrstvou. Obsahuje aplikační logiku celého systému a má na starosti transformaci dat mezi vstupně/výstupními požadavky a datovou vrstvou. V systému je zastoupena třídami se stereotypem <<Business>> Datová vrstva – je nejnižší vrstvou celého modelu a obsahuje funkce pro přístup k datovému úložišti, které je v tomto systému zastoupeno relační databází. Třídy této vrstvy jsou na diagramu označeny stereotypem <>
Datová a prezentační vrstva jsou striktně odděleny a data mezi nimi procházejí výhradně přes aplikační vrstvu. Výhodou tohoto modelu je, že vrstvy mezi sebou komunikují přes určité rozhraní, proto není například problém změnit typ datového úložiště. [8] Návrhový model systému vznikl upřesněním analytického modelu. Vazba mezi třídami Order a Prothetic byla rozvinuta pomocí dalšího objektu s názvem Item (položka), která je spojena silnou vazbou s objektem zakázky. Oproti analytickému modelu přibyly manažerské třídy, které vytvářejí v systému aplikační vrstvu. Tyto objekty jsou využívány třídami z prezentační vrstvy, které zastupují jednotlivá okna uvnitř uživatelského prostředí. U každé třídy z datové vrstvy by měly být pro všechny její atributy přidané metody set a get. Ty jsou kvůli přehlednosti a kompaktnosti zobrazení modelovaných tříd vypuštěny. Na obrázku č. 6 je k nahlédnutí návrhový diagram tříd. Vzhledem ke špatné čitelnosti je obrázek diagramu, stejně jako obrázky všech ostatních diagramů z této kapitoly, k nahlédnutí na přiloženém CD v adresáři Obrázky.
17
Obrázek 6 – Návrhový diagram tříd
18
4.5.1
Diagram balíků
Diagram balíků na obrázku č. 7 ukazuje sémantické rozdělení systému na jednotlivé části. Balík personal zastupuje třídy obstarávající evidenci laborantů, techniků a dodavatelů v systému. V balíku finance se nachází hlavní část celého programu, kterou je kniha zakázek, a operační logika nad ní. Poslední balíček balíku domain problem s názvem prosthesis obsahuje třídy reprezentující evidenci protetických prací a materiálů. Balík Java v diagramu zastupuje základní skupinu balíčků Java Core API. Celý systém využívá JDBC API, které obsahuje rozhraní pro přístup k databázím. Jeho základem je JDBC ovladač, který překládá dotazy do nativního volání databáze, a je obvykle poskytován výrobcem databázového systému. Balík GUI obsahuje implementovanou část systému a je závislý na balíčku javax.swing, který poskytuje potřebné komponenty pro tvorbu grafického uživatelského prostředí.
Obrázek 7 - Diagram balíků
19
4.6 Datový model Přestože se jedná o objektově orientovaný návrh, v systému by měla být data ukládána do relační databáze. Pro potřebu jejího popsání byl vytvořen relačně-vztahový diagram, který je zobrazen na obrázku 8.
4.6.1
Databázové modely
Databáze lze dělit podle způsobu reprezentace a ukládání dat a vazeb mezi nimi na několik modelů: hierarchický model (Hierarchival model) síťový model (Network model) relační model (Relation model) objektový model (Object database model) objektově relační model (Post-relational database model) Vzhledem k tomu, že při návrhu je použit relační model, budu se dále věnovat pouze jemu.
4.6.2
Relační model
Relační databázový model je založen na predikátové logice a relačních množinách. Relace v názvu ovšem neznamená vztah mezi daty, ale vychází z matematického chápání relací. Základní datovou strukturou v relačním modelu je tabulka, která má jednoznačně stanovené sloupce (atributy) a každý sloupec má jednoznačně definovaný typ, rozsah a název (doménu). Každý záznam je jedním řádkem (n-ticí) tabulky. S relačním modelem a relačními databázemi je také úzce spojen dotazovací jazyk SQL (Structured Query Language), který je používán pro definice a práci s daty. Je obecně použitelný ve všech databázových systémech a většinou je ještě obohacen o lokální rozšíření. Relační databáze a její vztahy lze popsat takzvaným ERD (Entity Relationship Diagram), ve kterém jsou uvedeny všechny podstatné informace. Komponentami diagramu jsou entity, vztahy, indikátory vztažných entit a indikátory nadtypů a podtypů. [9]
4.6.3
ERD
Diagram popisuje rozsah jednotlivých entit a vazby mezi nimi. Nenavázání entity Material na zbytek systému není chybou, ale jak bylo již dříve uvedeno, tato agenda je do systému začleněna pouze ze zákonné povinnosti vést evidenci materiálů a jejich dodavatelů. Relace mezi entitami Order, Item a Prothetic jsou neidentifikační z důvodu možného výskytu záznamů v jedné zakázce se stejnou protetickou prací, který byl již dříve také vysvětlen. Z tohoto důvodu je každé položce přiřazen identifikátor, který je primárním klíčem tabulky.
20
Obrázek 8 - ERD systému
4.7 Tvorba uživatelského prostředí Při implementaci byla využita aplikace NetBeans a její vestavěný GUI builder. Program bez aplikační logiky, tedy jen samotné uživatelské prostředí, je generován v jazyce Java. Při jeho tvorbě byly využity komponenty (okna, panely, tlačítka, textová pole a další) definované v knihovně javax.swing. Na obrázcích č. 9 a 10 je náhled výsledného uživatelského prostředí.
21
Obrázek 9 - Okno knihy zakázek v navrhovaném systému
Obrázek 10 - Náhled uživatelského prostředí navrhovaného systému
22
5 Závěr V rámci této bakalářské práce jsem měl za úkol prozkoumat metody objektové analýzy a návrhu a s jejich pomocí následně navrhnout systém pro zubní laboratoře. Součástí realizace se měl stát také návrh grafického uživatelského prostředí. V úvodu práce byla vytýčena problémová oblast, na kterou by se měl navrhovaný systém zaměřit, a byly popsány programy se zaměřením na stomatologické laboratoře. V navazující teoretické části práce je přiblížen jazyk UML a jsou popsány některé jeho modely. Dále následuje popis návrhu GUI, při kterém byli osloveni mimo jiné i potencionální uživatelé programu formou dotazníku. Získaná zpětná vazba byla zhodnocena jak při implementaci uživatelského prostředí, tak při analýze požadavků a návrhu systému. Hlavní částí práce je objektově orientovaná analýza, při které byl kladen důraz na možnou rozšiřitelnost a především maximální využitelnost systému. Návrh se striktně drží vytýčené problémové oblasti a nesnaží se zavádět nadbytečnou funkcionalitu. Výsledky práce mohou být do budoucna nápomocné při implementaci systému, popřípadě pouze jeho operační logiky do již vytvořeného uživatelského prostředí.
23
Literatura [1] Hobosoft: Ceník produktů a služeb, 1.1.2008. Dokument dostupný z URL: http://hobosoft.cz/ (22.5.2008) [2] VAP s.r.o.: Software pro zubní laboratoře – Dent. Dokument dostupný na URL: http://vap.cz/dent.php (22.5.2008) [3] Arlow, Jim: UML 2 a unifikovaný proces vývoje aplikací, 2, Brno, Computer press, 2007. 568 s. [4] Zubíček, Jan: Novinky ve specifikaci UML 2, 2006. Dokument dostupný z URL: http://zubicek.eu/skola/novinky-ve-specifikaci-uml2/ (22.5.2008) [5] Ošlejšek, R., Sochor, J.: UML (2) diagramy statické struktury, [skripta], Brno, FI MU, 2006 [6] Rada UZT ČR: Informace z jednání České obchodní inspekce se zástupci zubních techniků, 17.3.2006. Dokument dostupný z URL: http://www.zubnitechnik.cz/index.php?clanek=156 (22.5.2008) [7] Rada UZT ČR: Jak je to s kódy výrobků zubní laboratoře?, 19.7.2005, Dokument dostupný z URL: http://www.zubnitechnik.cz/index.php?clanek=145 (22.5.2008) [8] ITExpert: Třívrstvá architektura. Dokument dostupný z URL: http://www.itexpert.cz/trivrstva-architektura/ [9] Ráček, J., Sochor, J.: Modelování dat, [skripta], Brno, FI MU, 2006 [10] Schmuller, Joseph: Myslíme v jazyku UML, 1, Praha, Grada, 2001. 360 s.
24
Příloha A : Textové specifikace případů užití Případ užití: Změnit zakázku Účastníci: Laborant Vstupní podmínky: K systému je přihlášen laborant, je otevřena kniha zakázek Tok událostí: 1. případ užití začíná, když uživatel zvolí v knize zakázek konkrétní záznam 2. Systém načte a zobrazí detailní informace o zakázce 3. KDYŽ uživatel zvolí na panelu detail položku nový 3.1.
Systém vytvoří novou položku zakázky
3.2.
Uživatel vyplní kód protetické práce
3.3.
POKUD nesouhlasí s žádnou protetickou prací, systém upozorní uživatele
3.4.
JINAK systém načte informace o protetické práci a zobrazí prodejní cenu a název
3.5.
Uživatel vyplní ostatní pole a zvolí položku Nový, NEBO uložit
3.6.
Systém v případě nové položky uloží předchozí a pokračuje od kroku 5.1, NEBO v případě položky uložit uloží změny
4. Uživatel označí v seznamu na panelu detail jednu z položek 5. Systém načte a zobrazí informace o položce 6. KDYŽ Uživatel zvolí Smazat 6.1.
Systém smaže označenou položku zakázky, případ užití končí nebo pokračuje od 3.
7. Uživatel změní údaje na položce zakázky a zvolí uložit 8. Systém uloží změněné údaje 9. Uživatel zavře okno a případ užití končí Následné podmínky: Zakázky byly aktualizovány Alternativní tok: Okno Knihy zakázek může být kdykoli uzavřeno Následné podmínky: Neuložené informace budou ztraceny Případ užití: Evidovat zakázky Účastníci: Vedoucí laboratoře Vstupní podmínky: K systému je přihlášen vedoucí laboratoře Tok událostí: 1. Případ užití začíná zvolením položky Kniha zakázek z financí 2. Systém zobrazí okno s knihou zakázek
25
3. KDYŽ uživatel zvolí Nová pro vytvoření nové zakázky 3.1.
Systém vytvoří novou zakázku a zobrazí novou položku v seznamu zakázek s navazujícím číslem
4. KDYŽ Uživatel zvolí položku Hledání 4.1.
Systém zobrazí dialog hledání
4.2.
Uživatel zadá klíčové slovo a zvolí hledat
4.3.
Systém prohledá databázi zakázek a zobrazí záznamy odpovídající hledanému výrazu
5. Uživatel zvolí v seznamu zakázek konkrétní záznam 6. Systém načte a zobrazí detailní informace 7. KDYŽ Uživatel zvolí Smazat 7.1.
systém se dotáže uživatele, zda chce opravdu záznam smazat
7.2.
POKUD uživatel volbu potvrdí systém smaže zakázku případ užití pokračuje bodem 3.
7.3.
JINAK zakázka zůstává beze změn, případ užití pokračuje
8. Zahrnout (Změnit zakázku) 9. Uživatel změní na katě detaily informace o zakázce a zvolí uložit 10. Systém uloží změněné informace 11. Uživatel zavře okno a případ užití končí, NEBO může pokračovat znovu od bodu 3. Následné podmínky: Zakázky byly aktualizovány Alternativní tok 1: Okno Knihy zakázek může být kdykoli uzavřeno Následné podmínky: Neuložené informace budou ztraceny Alternativní tok 2: V okně knihy zakázek na panelu Zobrazení mohou být kdykoli vybrány omezující parametry zobrazení seznamu zakázek Následné podmínky: Seznam zakázek bude aktualizován dle zadaných kritérií
Případ užití: Evidovat lékaře Účastníci: Vedoucí laboratoře Vstupní podmínky: K systému je přihlášen vedoucí laboratoře, je otevřeno okno Lékaři Tok událostí: 1. Případ užití začíná zvolením položky Lékaři z adresáře 2. Systém zobrazí okno s evidencí lékařů 3. KDYŽ Uživatel zvolí položku Nový pro vytvoření nového lékaře
26
3.1.
Systém vytvoří nového lékaře a zobrazí novou položku v seznamu lékařů s navazujícím číslem
4. KDYŽ Uživatel zvolí položku Hledání 4.1.
Systém zobrazí dialog hledání
4.2.
Uživatel zadá klíčové slovo a zvolí hledat
4.3.
Systém prohledá databázi lékařů a zobrazí záznamy odpovídající hledanému výrazu
5. Uživatel zvolí v seznamu lékařů konkrétní záznam 6. Systém načte a zobrazí detailní informace 7. KDYŽ Uživatel zvolí Smazat 7.1.
Systém smaže záznam lékaře, případ užití pokračuje bodem 10
8. Uživatel změní údaje v panelu detaily a zvolí Uložit 9. Systém uloží změněné informace 10. Uživatel zavře okno a případ užití končí, NEBO může pokračovat znovu od bodu 3. Následné podmínky: Databáze lékařů byla aktualizována Alternativní tok: Okno Lékaři může být kdykoli uzavřeno Následné podmínky: Neuložené informace budou ztraceny Případ užití: Evidovat laboranty Účastníci: Vedoucí laboratoře Vstupní podmínky: K systému je přihlášen vedoucí laboratoře Tok událostí: 1. Případ užití začíná zvolením položky Laboranti z adresáře 2. Systém zobrazí okno s evidencí laborantů 3. KDYŽ Uživatel zvolí položku Nový pro vytvoření nového laboranta 3.1.
Systém vytvoří novou položku v seznamu laborantů s navazujícím číslem
4. KDYŽ Uživatel zvolí položku Hledání 4.1.
Systém zobrazí dialog hledání
4.2.
Uživatel zadá klíčové slovo a zvolí hledat
4.3.
Systém prohledá databázi laborantů a zobrazí záznamy odpovídající hledanému výrazu
5. Uživatel zvolí v seznamu laborantů konkrétní záznam 6. Systém načte a zobrazí detailní informace 7. KDYŽ Uživatel zvolí Smazat 7.1.
Systém smaže záznam laboranta, případ užití pokračuje bodem 10
27
8. Uživatel změní údaje v panelu detaily a zvolí Uložit 9. Systém uloží změněné informace 10. Uživatel zavře okno a případ užití končí, NEBO může pokračovat znovu od bodu 3. Následné podmínky: Databáze laborantů byla aktualizována Alternativní tok: Okno Laboranti může být kdykoli uzavřeno Následné podmínky: Neuložené informace budou ztraceny Případ užití: Evidovat dodavatele Účastníci: Vedoucí laboratoře Vstupní podmínky: K systému je přihlášen vedoucí laboratoře Tok událostí: 1. Případ užití začíná zvolením položky Dodavatelé z adresáře 2. Systém zobrazí okno s evidencí dodavatelů 3. KDYŽ Uživatel zvolí položku Nový pro vytvoření nového dodavatele 3.1.
Systém vytvoří novou položku v seznamu dodavatelů s navazujícím číslem
4. KDYŽ Uživatel zvolí položku Hledání 4.1.
Systém zobrazí dialog hledání
4.2.
Uživatel zadá klíčové slovo a zvolí hledat
4.3.
Systém prohledá databázi dodavatelů a zobrazí záznamy odpovídající hledanému výrazu
5. Uživatel zvolí v seznamu dodavatelů konkrétní záznam 6. Systém načte a zobrazí detailní informace 7. KDYŽ Uživatel zvolí Smazat 7.1.
Systém smaže záznam dodavatele, případ užití pokračuje bodem 10
8. Uživatel změní údaje v panelu detaily a zvolí Uložit 9. Systém uloží změněné informace 10. Uživatel zavře okno a případ užití končí, NEBO může pokračovat znovu od bodu 3. Následné podmínky: Databáze dodavatelů byla aktualizována Alternativní tok: Okno Dodavatelé může být kdykoli uzavřeno Následné podmínky: Neuložené informace budou ztraceny Případ užití: Evidovat materiály
28
Účastníci: Vedoucí laboratoře Vstupní podmínky: K systému je přihlášen vedoucí laboratoře Tok událostí: 1. Případ užití začíná zvolením položky Materiály z protetiky 2. Systém zobrazí okno s evidencí materiálů 3. KDYŽ Uživatel zvolí položku Nový pro přidání nového materiálu 3.1.
Systém se dotáže na identifikační číslo materiálu
3.2.
Uživatel vyplní číslo
3.3.
POKUD materiál s tímto číslem existuje, systém na to upozorní
3.4.
JINAK systém přidá nový materiál se zadaným číslem do seznamu
4. KDYŽ Uživatel zvolí položku Hledání 4.1.
Systém zobrazí dialog hledání
4.2.
Uživatel zadá klíčové slovo a zvolí hledat
4.3.
Systém prohledá databázi materiálů a zobrazí záznamy odpovídající hledanému výrazu
5. Uživatel zvolí v seznamu materiálů konkrétní záznam 6. Systém načte a zobrazí detailní informace 7. KDYŽ Uživatel zvolí Smazat 7.1.
Systém smaže záznam materiálu, případ užití pokračuje bodem 10.
8. Uživatel změní v panelu detaily údaje a zvolí Uložit 9. Systém uloží změněné informace 10. Uživatel okno uzavře a případ užití končí, NEBO pokračuje znova od bodu 3 Následné podmínky: Databáze materiálů byla aktualizována Alternativní tok 1: Okno Lékaři může být kdykoli uzavřeno Následné podmínky: Neuložené informace budou ztraceny Alternativní tok 2: Kdykoli v průběhu případu užití může být zvolen konkrétní dodavatel Následné podmínky: V seznamu materiálů budou zobrazeny pouze materiály od zvoleného dodavatele
Případ užití: Evidovat protetické práce Účastníci: Vedoucí laboratoře Vstupní podmínky: K systému je přihlášen vedoucí laboratoře Tok událostí: 1. Případ užití začíná zvolením položky Protetické práce z protetiky
29
2. Systém zobrazí okno s evidencí protetických prací 3. KDYŽ Uživatel zvolí položku Nový pro přidání nové protetické práce 3.1.
Systém se dotáže na identifikační číslo práce
3.2.
Uživatel vyplní číslo
3.3.
POKUD položka s tímto číslem existuje, systém na to upozorní
3.4.
JINAK systém přidá novu práci se zadaným číslem do seznamu
4. KDYŽ Uživatel zvolí položku Hledání 4.1.
Systém zobrazí dialog hledání
4.2.
Uživatel zadá klíčové slovo a zvolí hledat
4.3.
Systém prohledá databázi protetických prací a zobrazí záznamy odpovídající hledanému výrazu
5. Uživatel zvolí v seznamu prací konkrétní záznam 6. Systém načte a zobrazí detailní informace 7. KDYŽ Uživatel zvolí Smazat 7.1.
Systém smaže záznam protetické práce, případ užití pokračuje bodem 10.
8. Uživatel změní v panelu detaily údaje a zvolí Uložit 9. Systém uloží změněné informace 10. Uživatel okno uzavře a případ užití končí, NEBO pokračuje znova od bodu 3 Následné podmínky: Databáze protetických prací byla aktualizována Alternativní tok: Okno Protetické práce může být kdykoli uzavřeno Následné podmínky: Neuložené informace budou ztraceny Případ užití: Tisknout ceník Účastníci: Účetní Vstupní podmínky: K systému je přihlášen účetní Tok událostí: 1. Případ užití začíná zvolením položky Tisk ceníku z financí 2. Systém zobrazí okno s nastavením parametrů tisku 3. Uživatel zvolí rozsah tisku ceníku, detaily a platnost 4. Systém připraví data na výstup 5. Uživatel zvolí tisk 6. Systém zavolá tiskového agenta systému 7. Uživatel vybere tiskárnu, počet kopií a zvolí Ok
30
8. Systém odešle data pro tisk 9. Uživatel uzavře okno Tisk ceníku, případ užití končí, NEBO pokračuje znovu od bodu 3. Následné podmínky: Byl vytištěn ceník protetických prací Alternativní tok 1: Okno může být kdykoli před zvolením položky tisk uzavřeno, případ užití skončí Následné podmínky: Alternativní tok 2: Kdykoli může uživatel zvolit náhled, systém zobrazí okno s náhledem výstupu pro tisk Následné podmínky: Případ užití: Vytvořit fakturu Účastníci: Účetní Vstupní podmínky: K systému je přihlášen účetní Tok událostí: 1. Případ užití začíná zvolením položky Fakturace z financí 2. Systém zobrazí okno fakturace 3. Uživatel vybere lékaře, kterému chce vytvořit fakturu 4. Systém načte dokončené zakázky daného lékaře a zobrazí je v seznamu 5. Uživatel vybere rozsah fakturace 5.1.
KDYŽ zvolí jednu zakázku, označí konkrétní zakázku v seznamu
5.2.
KDYŽ zvolí výběr zakázek, označí vybrané zakázky v seznamu
5.3.
KDYŽ zvolí sběrnou fakturaci, budou vybrány všechny zakázky automaticky
6. Systém vypočítá částku za všechny položky na faktuře a zobrazí v kolonce částka 7. Uživatel zvolí úroveň detailů na dokladu 8. Uživatel počet dní na splatnost faktury, NEBO nastaví datum splatnosti 9. KDYŽ uživatel zvolí Uložit fakturu 9.1.
Systém uloží fakturu a případ užití končí
10. KDYŽ uživatel zvolí Uložit a tisknout 10.1.
Systém uloží fakturu
10.2.
Systém zavolá tiskový dialog operačního systému
10.3.
Uživatel vybere tiskárnu, počet kopií a zvolí Ok
10.4.
Systém odešle data pro tisk, případ užití končí
Následné podmínky: Byla vytvořena a popřípadě vytištěna faktura pro daného lékaře za zvolené zakázky Alternativní tok 1: Okno může být kdykoli uzavřeno, případ užití skončí Následné podmínky:
31
Neuložené faktury nebudou vytvořeny, zakázky zůstávají nezměněny Alternativní tok 2: Kdykoli může uživatel zvolit náhled, systém zobrazí okno s náhledem výstupu pro tisk Následné podmínky: Případ užití: Tisknout výkaz Účastníci: Účetní Vstupní podmínky: K systému je přihlášen účetní Tok událostí: 1. Případ užití začíná zvolením položky Tisk výkazu z financí 2. Systém zobrazí okno s nastavením parametrů tisku 3. Uživatel laboranta pro kterého má tisknout výkaz, časové rozmezí, za které má být výkaz vypočítán a detaily výstupu 4. Systém připraví data na výstup, vypočítá částku za práce na výkazu a zobrazí ji v položce částka 5. Uživatel zvolí tisk 6. Systém zavolá tiskového agenta systému 7. Uživatel vybere tiskárnu, počet kopií a zvolí Ok 8. Systém odešle data pro tisk 9. Uživatel uzavře okno Tisk ceníku, případ užití končí, NEBO pokračuje znovu od bodu 3. Následné podmínky: Byl vytištěn výkaz Alternativní tok 1: Okno může být kdykoli před zvolením položky tisk uzavřeno, případ užití skončí Následné podmínky: Alternativní tok 2: Kdykoli může uživatel zvolit náhled, systém zobrazí okno s náhledem výstupu pro tisk Následné podmínky: Případ užití: Zjistit četnosti kódů Účastníci: Účetní Vstupní podmínky: K systému je přihlášen účetní Tok událostí: 1. Případ užití začíná zvolením položky Četnosti kódů z protetiky 2. Systém zobrazí okno pro výpočet četnosti kódů 3. Uživatel nastaví parametry a rozsah výpočtu a výstupu, časový interval a zadá část a nebo celý kód pro který se má výpočet provést 4. Uživatel zvolí Vyhledat
32
5. Systém podle zadaných údajů provede výpočet a dle nastavení zformátuje výstup, který zobrazí v novém okně 6. Uživatel uzavře okno s výsledky 7. Uživatel uzavře okno Četnosti kódů, případ užití končí, NEBO pokračuje od bodu 3. Následné podmínky: Alternativní tok: Okno může být kdykoli před zvolením položky Vyhledat uzavřeno, případ užití končí Následné podmínky: Případ užití: Zálohovat data Účastníci: Vedoucí laboratoře Vstupní podmínky: K systému je přihlášen vedoucí laboratoře Tok událostí: 1. Případ užití začíná zvolením položky Záloha dat 2. Systém zobrazí okno s dialogem pro zálohu dat 3. Uživatel vyplní cestu, kam se mají soubory zálohy uložit, NEBO zvolí procházet a určí cestu s pomocí dialogového okna procházení 4. Systém zobrazí dialogové okno s průběhem zálohy, které se po dokončení uzavře 5. Po provedení zálohy případ užití končí Následné podmínky: Byla provedena záloha dat Alternativní tok: Okno může být kdykoli před zvolením položky Zálohovat data uzavřeno, případ užití končí Následné podmínky: Záloha nebyla provedena Případ užití: Obnovit data Účastníci: Vedoucí laboratoře Vstupní podmínky: K systému je přihlášen účetní Tok událostí: 1. Případ užití začíná zvolením položky Obnova dat 2. Systém zobrazí okno s dialogem pro obnovu dat 3. Uživatel vyplní cestu, kde jdou soubory se zálohou, NEBO zvolí procházet a určí cestu s pomocí dialogového okna procházení 4. Systém zobrazí dialogové okno s průběhem obnovování dat, které se po dokončení uzavře 5. Po provedení zálohy případ užití končí Následné podmínky: Byla provedena obnova dat Alternativní tok:
33
Okno může být kdykoli před zvolením položky Obnovit data uzavřeno, případ užití končí Následné podmínky: Žádná data nebyla obnovena Případ užití: Prohlížet vystavené faktury Účastníci: Účetní Vstupní podmínky: K systému je přihlášen účetní Tok událostí: 1. Případ užití začíná zvolením položky Vystavené doklady z financí 2. Systém zobrazí okno se seznamem vystavených dokladů a přehledem financí 3. Uživatel zvolí doklad v seznamu a vyplní datum zaplacení 4. Systém přepočítá finance a zobrazí bilanci Následné podmínky: Alternativní tok 1: Okno může být kdykoli uzavřeno, případ užití skončí Následné podmínky: Alternativní tok 2: Kdykoli může uživatel zvolený doklad tisknout Následné podmínky: Byla vytištěna faktura Alternativní tok 3: Kdykoli může uživatel zakázky ze zvolené faktury zobrazit v knize zakázek Následné podmínky: Bylo otevřeno okno knihy zakázek a zobrazeny zakázky z daného dokladu
34
Příloha B: Záznamy dotazníků Dotazník č. 1 Osobní: Žena Zubní laborantka Ano (je obsluhován jinou osobou - manželem) Pohoda, pouze na vytváření faktur Ne Ano Otázky a úkoly: Zjednodušení práce s vedením zakázek, protetických prací a materiálů, přehlednost, uživatelská přítulnost Materiály – materiály, dodavatelé Protetika – protetické práce, kniha zakázek, četnosti kódů Finance – fakturace, vystavené doklady, ceníky Adresář – laboranti, lékaři Nápověda – nápověda, o programu, obnova/záloha dat Téměř všechny pojmy OK. Ceníky si plete s protetickými pracemi. Četnosti kódů částečně pochopeny. Neporozumění pojmu obnova/záloha dat a proto také poněkud nesmyslné umístění. Problém s umístěním položky fakturace. Původně umístěna do skupiny protetika. Orientace v programu: Ano Snadné po zaškolení. Snadné po zaškolení. V KZ nechybí nic. Práce snadná po zaškolení. Bez výhrad. V programu nechybí nic.
35
Dotazník č. 2 Osobní: Žena Studentka LF Ne Otázky a úkoly: Jednoduché vedení zakázek, intuitivní ovládání, uživatelská přítulnost Protetika – materiály, protetické práce Speciální – obnova/záloha dat, četnosti kódů Finance – kniha zakázek, fakturace, vystavené doklady, ceníky Adresář (seznam) – laboranti, lékaři, dodavatelé Nápověda – nápověda, o programu Téměř všechny pojmy OK. Ceníky nepřesně pochopeny (přejmenování na Tisk ceníku). Orientace v programu: Ano Snadné Snadné po zaškolení. V KZ nechybí nic. Výhrady k rodnému číslu (určit, že se vztahuje k pacientovi) Práce snadná Bez výhrad. V programu nechybí nic.
36
Dotazník č. 3 Osobní: Žena Zubní laborantka Ne Otázky a úkoly: Jednoduché vedení zakázek, intuitivní ovládání Ano – sklad Číselníky – materiály, protetické práce, četnosti kódů Finance – kniha zakázek, fakturace, vystavené doklady, ceníky Adresář – laboranti, lékaři, dodavatelé Nápověda – nápověda, o programu, obnova/záloha dat Téměř všechny pojmy OK. Ceníky nepřesně pochopeny (přejmenování na Tisk ceníku). Nepochopen pojem obnova/záloha dat (nemá zkušenosti s PC) a proto také špatné umístění. Neporozumění četnosti kódů. Orientace v programu: Ano Snadné Snadné po zaškolení. V KZ nechybí nic. Výhrady k popisku název (přejmenovat na název práce) Práce snadná po zaškolení Bez výhrad. V programu nechybí nic.
37
Dotazník č. 4 Osobní: Muž Stolař – majitel firmy, vede si účetnictví Ano Kalkul Ne Ano Otázky a úkoly: Kniha zakázek, vedení zaměstnanců, odběratelů (lékařů), dodavatelů, fakturace Ano – sklad, mzdy Číselníky – materiály, protetické práce, ceníky Speciální – obnova/záloha dat, četnosti kódů, nápověda, o programu Finance – kniha zakázek, fakturace, vystavené doklady Adresář – laboranti, lékaři, dodavatelé Téměř všechny pojmy OK. Ceníky nepřesně pochopeny (přejmenování na Tisk ceníku). U položky Obnova/záloha dat podotkl, že by se měl program dotazovat před ukončením. Orientace v programu: Ano Snadné Snadné V KZ nechybí nic Práce snadná Bez výhrad. V programu nechybí nic.
38
Dotazník č. 5 Osobní: Muž Soukromý podnikatel – vede si účetnictví Ano Kalkul – verze pro DOS Ano, nevyužívá všechny Ano Otázky a úkoly: Kniha zakázek, vedení zaměstnanců, skladové hospodářství Protetika – protetické práce, ceníky Speciální – obnova/záloha dat, četnosti kódů Sklad – materiály, dodavatelé Finance – kniha zakázek, fakturace, vystavené doklady Adresář – laboranti, lékaři Nápověda – nápověda, o programu Téměř všechny pojmy OK. Ceníky nepřesně pochopeny (přejmenování na Tisk ceníku). Orientace v programu: Ano Snadné Snadné V KZ nechybí nic Práce snadná po zaškolení Bez výhrad. V programu nechybí nic.
39
Dotazník č. 6 Osobní: Žena Zubní laborantka Ano Laboratoř firmy Hobosoft Ne Ano, s výhradami Otázky a úkoly: Zjednodušení vedení knihy zakázek, přehlednost a intuitivní ovládání Ne Protetika – materiály, protetické práce Finance – kniha zakázek, fakturace, vystavené doklady, ceníky Adresář – laboranti, lékaři, dodavatelé Nápověda – nápověda, o programu Speciální – obnova/záloha dat, četnosti kódů Téměř všechny pojmy OK. Vzhledem ke zkušenostem s jiným programem nečinily pojmy problémy, s výjimkou ceníků. Orientace v programu: Ano Snadné po zaškolení Snadné po zaškolení. V KZ nechybí nic. Práce snadná po zaškolení Bez výhrad. V programu nechybí nic.
40
Dotazník č. 7 Osobní: Žena Zubní laborantka Ne Otázky a úkoly: Vedení zakázek, kódové označení protetických prací, případně skladové hospodářství Protetika – materiály, protetické práce, ceníky Finance – kniha zakázek, fakturace, vystavené doklady Adresář – laboranti, lékaři, dodavatelé Nápověda – nápověda, o programu, obnova/záloha dat, četnosti kódů Téměř všechny pojmy OK. Opět problém s položkou ceník (přejmenování na Tisk ceníku problém řeší). S pojmy obnova/záloha dat a četnosti kódů problém, proto opět nejisté zařazení. Orientace v programu: Ano Snadné po zaškolení Snadné po zaškolení. V KZ nechybí nic. Práce snadná po zaškolení Pro neznalého uživatele nutnost vysvětlení některých nestandardních funkcí. V programu nechybí nic.
41
Dotazník č. 8 Osobní: Žena Bez zaměstnání Ne Otázky a úkoly: Jednoduché vedení knihy zakázek, přehledné ovládání, sklad materiálů Protetika – protetické práce, četnosti kódů Finance –fakturace, vystavené doklady, kniha zakázek, ceníky Adresář –lékaři, laboranti Ostatní – nápověda, o programu, obnova/záloha dat Sklad – materiály, dodavatelé Téměř všechny pojmy OK. Problém ceník (Tisk ceníku). Obnova/záloha dat nepochopena. Byly vysvětleny četnosti kódů, proto zařazeny do protetiky (předtím Ostatní). Orientace v programu: Ano Snadné po zaškolení Snadné po zaškolení. V KZ nechybí nic. Práce snadná po zaškolení Bez výhrad. V programu nechybí nic.
42
Dotazník č. 9 Osobní: Muž Řidič z povolání Ne Otázky a úkoly: přehledné ovládání, uživatelská přítulnost, zjednodušení administrativních úkonů Materiály – materiály, dodavatelé Protetika – protetické práce, ceníky Nápověda – nápověda, o programu Ostatní – obnova/záloha dat, četnosti kódů Finance – fakturace, vystavené doklady, kniha zakázek Adresář – lékaři, laboranti Téměř všechny pojmy OK. Neustálý problém s ceníky (přejmenovat na Tisk ceníku). Obnova/záloha dat pochopena, ale problém s četností kódů. Orientace v programu: Ano Snadné po zaškolení Snadné po zaškolení. V KZ nechybí nic. Práce snadná po zaškolení Bez výhrad. V programu nechybí nic.
43
Dotazník č. 10 Osobní: Muž Zubní laborant – nyní pracuje mimo obor Ne Otázky a úkoly: Jednoduché vedení zakázek, protetických prací a skladu, přehlednost Materiály – materiály, dodavatelé Protetika – protetické práce, kniha zakázek, ceníky Nápověda – nápověda, o programu Ostatní – obnova/záloha dat, četnosti kódů Finance – fakturace, vystavené doklady Adresář – lékaři, laboranti Téměř všechny pojmy OK. Zase problém ceník (Tisk ceníku). Ostatní položky kromě četnosti kódů bez problémů. Po vysvětlení vše pochopeno. Orientace v programu: Ano Snadné Snadné po zaškolení. V KZ nechybí nic. Práce snadná po zaškolení Bez výhrad. V programu nechybí nic.
44
Příloha C: Obsah přiloženého CD Na přiloženém CD se nachází následující adresářová struktura: Laboratoř – tento adresář obsahuje spustitelný JAR archív implementovaného GUI Obrázky – v tomto adresáři jsou k nahlédnutí všechny diagramy ze 4. kapitoly Text – v tomto adresáři se nachází tento text ve formátu PDF Projekt – tento adresář obsahuje projekt z programu NetBeans
45
