VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

Transkript

1 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS INFORMAČNÍ SYSTÉM PRO LABORATOŘ KRMIV DIPLOMOVÁ PRÁCE MASTER S THESIS AUTOR PRÁCE AUTHOR Bc. VOJTĚCH MALÝ BRNO 2010

2 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS INFORMAČNÍ SYSTÉM PRO LABORATOŘ KRMIV INFORMATION SYSTÉM FOR A LABORATORY OF FEEDING STUFFS DIPLOMOVÁ PRÁCE MASTER S THESIS AUTOR PRÁCE AUTHOR VEDOUCÍ PRÁCE SUPERVISOR Bc. VOJTĚCH MALÝ Mgr. MAREK RYCHLÝ BRNO 2010

3 Abstrakt Tato práce se zabývá vývojem informačního systému pro laboratoř krmiv firmy NutriVet, s.r.o.. Definuje nezbytné pojmy spojené s problematikou výživy hospodářských zvířat a vývoje informačního systému. Zaměřuje se na analýzu požadavků laboratoře, návrh, implementaci a testování vhodného řešení. Abstract This work describes development of the Information system for the laboratory of feeding stuff, NutriVet Company, Ltd. It defines the essential concepts associated with problems of the livestock nutrition and information system development. It is focusing on requirements analysis, design, implementation and testing suitable solution. Klíčová slova Výživa hospodářských zvířat, krmivo, krmná směs, Informační systém pro laboratoř krmiv, UML, analýza požadavků, vývoj informačního systému, databáze, Hibernate, mapování, ORM, plánování projektu. Keywords Nutrition of livestock feed, compound feed, information system for a laboratory of feeding stufs, UML, requirements analysis, development of information system, database, Hibernate, mapping, ORM, project planning. Citace Malý Vojtěch: Informační systém pro laboratoř krmiv, diplomová práce, Brno, FIT VUT v Brně, 2010.

4 Informační systém pro laboratoř krmiv Prohlášení Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně pod vedením Mgr. Marka Rychlého. Další informace mi poskytl Ing. Václav Jambor, CSc. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal. Vojtěch Malý Poděkování Rád bych poděkoval především vedoucímu své diplomové práce, Mgr. Marku Rychlému, za užitečné rady a pomoc při tvorbě této práce. Také děkuji panu Ing. Václavu Jamborovi, CSc., za dodané informace z oblasti výživy hospodářských zvířat. Bc. Vojtěch Malý, 2010 Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů..

5 Obsah Obsah Úvod Výživa hospodářských zvířat Výživná hodnota krmiv Příprava vzorku k analýzám Produkční hodnocení krmiv Energetické hodnocení krmiv Systém hodnocení NL u přežvýkavců Stravitelnost organických živin Detergentní analýza (Cornellská analýza) Stanovení sušiny Stanovení dalších živin Krmné směsi Rozdělení krmných směsí Vývoj informačního systému Životní cyklus vývoje IS Modely životního cyklu Modelovací jazyk Historie UML Možnosti modelování v UML Podpůrné nástroje Typy databází Relační databáze Postrelační databáze Normální formy tabulek Plánování projektu Vývoj projektového plánu Plán projektu Rozpočtový plán Analýza požadavků Neformální specifikace Funkční požadavky Laboratorní program Zákaznický program

6 4.3 Nefunkční požadavky Rozsah vstupních dat Plán projektu Analýza rizik Diagram případů použití Návrh IS Konceptuální diagram tříd Návrh databáze ER diagram Diagram návaznosti obrazovek Implementace Popis objektů Základní objekty Objekt pro práci s databází Objekt pro práci s datovými kontejnery Hibernate Architektura Hibernate Mapování Příkazy pro práci s databází Tvorba GUI Zavádění IS Testování IS po 1. iteraci Výsledky testování Návrhy na zlepšení Další postup vývoje IS Závěr

7 1 Úvod Informační systémy (dále jen IS) jsou důležitou součástí téměř každé firmy. Používají se pro zadávání úkolů, ukládání a porovnávání různých dat, uchovávání dokumentů, rychlejší komunikaci a k mnoha dalším činnostem, které usnadňují práci. Tyto IS již nejsou doménou firem zabývajících se informačními technologiemi (dále jen IT). Stále častěji IS pronikají do dalších oblastí. Také IS pro tyto oblasti lidské činnosti musí splňovat základní požadavky, jako je efektivní předávání, sdílení a práce s daty. Takovou firmou je i NutriVet, s.r.o., která se zabývá rozbory krmiv a poradenstvím v oblasti výživy hospodářských zvířat. V současné době je na českém trhu několik produktů, které se zabývají problematikou výživy hospodářských zvířat. Často však nejsou vyhovující z hlediska práce s daty. Fungují jen na určitém operačním systému, data se musí zadávat ručně, jsou určeny buď jen pro laboratoř, nebo jen pro porovnání rozborů. Systém, který budu navrhovat by měl být nezávislý na operačním systému, mít optimálně navrhnutou databázovou strukturu (dále jen DB), protože počet údajů v jednotlivých rozborech nebude jednotný. IS bude umět zpracovat i částečné rozbory. Navíc je možné, že se změní metodika stanovení některých hodnot a s tím souvisí potřeba budoucích úprav programu. To znamená rozšíření o další výpočty a vstupní hodnoty. DB bude navržena tak, aby byla flexibilní a snadno upravitelná. IS by měl být intuitivní (aby ho mohl ovládat i chovatel, který nemá velké zkušenosti v oblasti výživy hospodářských zvířat ani v oblasti IT). Jeho jedinečnost bude v tom, že umožní spojit potřeby laboratoře, která zpracovává rozbory krmiv, a potřeby koncového uživatele, který chce ze svých rozborů sestavit optimální krmnou dávku pro svůj chov. Navrhovaný IS je určen pro firmu NutriVet, s.r.o., která jím chce nahradit původní program. Přínosem bude hlavně komplexnější práce s daty na straně zadavatele rozboru. Také chce mít možnost snadného rozšíření IS o nové metody výpočtu, upravit tiskové sestavy apod. Pro mě je tato diplomová práce přínosná hlavně v tom, že mám možnost navrhnout a implementovat IS, který bude nasazen do provozu a používán. Vyzkouším si tak v praxi znalosti získané během studia. Problematika, kterou bude IS postihovat, je pro mě zcela neznámá. Výživa hospodářských zvířat je poměrně vzdálena od oboru informatika. I z tohoto pohledu bude zajímavé řešit problémy spojené s komunikací mezi odborníkem na výživu a informatikem. 3

8 2 Výživa hospodářských zvířat Význam výživy hospodářských zvířat stále roste. Již nestačí zvířata pouze nasytit, je třeba jim dodat vyváženou krmnou dávku s odpovídající výživnou hodnotou podle jejich užitkového směru. Navíc se v zemědělství stále více používají doplňkové látky a různé konzervační přípravky, které mají pozitivní vliv na kvalitu krmiva. Pokud zemědělec vyrobí kvalitní krmivo, které přinese zvířatům vše, co jejich organismus potřebuje, potom jsou tato zvířata zdravá a produkují kvalitní, hygienicky nezávadné mléko nebo maso. Kvalitní produkty mohou získat certifikace kvality, jsou zárukou lepšího prodeje a tím i lepší ekonomiky chovu. Chovatel tak získá více prostředků, které může investovat do dalšího zlepšování chovu. Je-li v krmné dávce hospodářských zvířat trvale disbalance přijatých živin, které neodpovídají jejich potřebám, zhorší se zdraví zvířat, poklesne užitkovost a kvalita produkce. S tím se logicky sníží i ekonomika chovu. Aby mohl zemědělec efektivně řídit výživu svých zvířat podle užitkovosti, měl by znát nejen výživné složení vyrobených krmiv, ale i jejich hygienickou nezávadnost. Pro určení kvality krmiv použitých pro hospodářská zvířata v daném chovu si může chovatel nechat stanovit laboratorní rozbor. Rozbor krmiv mu slouží k určení kvality daného krmiva a následně pomocí krmivářského programu je možno stanovit optimální krmnou dávku pro daný užitkový směr. Laboratoř dokáže na základě různých chemických a fyzikálních metod stanovit nejen obsah živin v krmivu, ale také mnoho různých kvalitativních hodnot. S těmito hodnotami je potřeba dále pracovat. V současné době se ve většině laboratoří jako výstup používá předání protokolů o výsledku analýz. Takový rozbor má jistě určitou informační hodnotu, ale jen pro odborníka. Pokud takový rozbor dostane běžný chovatel, asi mu řada údajů bude připadat neznámá a nebude si s těmito informacemi vědět rady. Proto většina chovatelů spolupracuje se specialisty na výživu hospodářských zvířat, kteří ze zjištěných laboratorních hodnot krmiv dokáží stanovit optimální krmnou dávku pro daný chov. Stanovit však optimální poměr vyžaduje určitou zkušenost a znalost vzorců pro výpočet. Při zkoumání možností SW v této problematice jsem narazil spíše na zastaralé programy, do kterých musel uživatel zadat komplexní rozbor. To je však poměrně pracné, vzhledem k počtu sledovaných ukazatelů. Navíc se musely zadat všechny hodnoty, aby výpočet proběhl. V dnešní době zkoušet pracovat v programu dělaném pro operační systém MS-DOS nepřináší moc uživatelského pohodlí. Z výše uvedených důvodů chce firma NutriVet, s.r.o., vyvinout komplexní IS, který by postihoval laboratorní stanovení hodnot, ale také další práci s těmito daty. Laboratorní část IS by umožňovala zadat rozbor v rozsahu požadovaném zákazníkem. Tato data by pak mohl zákazník dále použít k sestavování optimálních krmných dávek. Tyto krmné dávky by se mohly skládat z různého počtu krmiv. Při sestavování krmných dávek narážíme na celou řadu problémů. Zákazník může požadovat neúplný rozbor, nechá si stanovit jen některé hodnoty. Pro sestavení krmných dávek je nutné znát 4

9 všechny výživné hodnoty krmiv, ze kterých se daná krmná dávka dá stanovit. Pokud nejsou některé hodnoty stanoveny přímo rozborem, lze je doplnit tabulkovými údaji podobných krmiv. Tabulkové hodnoty jsou stanovovány dlouhodobými průměry jednotlivých používaných druhů krmiv. Tyto průměrné hodnoty se mohou lišit dle typu krmiva a oblasti, odkud krmivo pochází. Když chovatel odebírá krmivo stále z jedné oblasti, pak některé hodnoty mohou mít stálou odchylku od tabulkové hodnoty. Program by měl umožňovat chovateli aktualizovat tabulkové hodnoty tak, aby odpovídaly skutečnosti. Dále je potřeba propočítat optimální poměr jednotlivých krmiv, aby vznikla požadovaná krmná dávka. To je pro zákazníka tím nejdůležitějším údajem, aby věděl, která krmiva v jakém poměru a množství použít v krmné dávce. V případě, že krmiva vyrobená chovatelem neodpovídají dané normě, musí chovatel nakoupit další doplňková krmiva, aby výsledná krmná dávka odpovídala požadavkům chovaných zvířat a jejich užitkovému směru. Zákazníci mohou být i ze vzdálenějších lokalit. Proto je vhodné databázi rozborů umístit na internet, aby tato data byla co nejdříve k dispozici. Například aby si program po zapnutí sám zkontroloval, zda pro daného zákazníka nejsou v DB nějaké nové rozbory. Pokud zjistí nový rozbor, automaticky si ho stáhne na lokální počítač a může s ním pracovat. Pokud dostane rozbory pouze ve formě protokolu, musí tyto údaje do počítače zadat sám. To bývá časově náročné a pracné. Naším cílem je tuto zbytečnou práci odbourat a docílit lepšího využití údajů získaných v laboratoři. Zákazník nemusí mít stálý přístup k internetu. V tom případě je třeba data dodat jiným způsobem. Například předat data na médiu. Zákazníci mohou používat různé operační systémy. Nejen tyto problémy je nutné vyřešit. Uživatelé mají různé znalosti práce s počítači, a proto je třeba IS navrhnout tak, aby při své komplexnosti zaručoval snadné a intuitivní ovládání a přitom byl schopen komplexně pracovat s rozbory. 2.1 Výživná hodnota krmiv Výživná hodnota krmiv je dána obsahem energie, obsahem organických živin a dalších látek v krmivu. Dále fyzikálními, chemickými a dietetickými vlastnostmi krmiva a také působením krmiva na organismus zvířete. Pro zjištění výše uvedených výživných hodnot krmiva existuje velké množství metod. Aby byla zachována jednotnost, jsou tyto metody upraveny vyhláškou č. 124/2001 Sb. [9], Základní metody zkoušení krmiv (ČSN Metody zkoušení krmiv). Metody na zjišťování kvality krmiva: Fyzikální metoda odrol lisovaných krmiv přes síto, stanovení zrnitosti, stanovení ferromagnetických příměsí magnetem - posouzení barvy, struktury a konzistence. Smyslové metody - posouzení barvy, struktury, konzistence a pachu krmiva. 5

10 Chemické metody stanovení dusíkatých látek (dále jen NL), tuku, vlákniny a dalších parametrů chemickou analýzou. Speciální metody mikroskopie krmiv, stanovení škůdců v krmných směsích. V našem případě, pro laboratoř krmiv firmy NutriVet, s.r.o., je podstatná hlavně metoda chemická. Jak tato metoda probíhá, jaké látky a k jakému účelu se při ní stanovují, popíšu stručně dále Příprava vzorku k analýzám Aby bylo co analyzovat, je třeba nejprve odebrat vzorek. Odběr vzorku krmiva Postup při odběru vzorku krmiv musí být správný a metodicky přesný. Správný odběr znamená, že vzorek nesmí být kontaminován dalšími látkami. Metodická přesnost zaručuje stejné zacházení u všech odebraných vzorků a tedy i možnost je později porovnat z hlediska kvality. Aby mohly být ze vzorku určeny jednotlivé složky, je třeba tento vzorek ještě upravit. Úprava spočívá hlavně v předsoušení, tím se ze vzorku vyloučí voda a vznikne tzv. sušina. Úprava konečných vzorků Konečný vzorek se promíchá na suché, hladké a čisté podložce, rozprostře se do nízké vrstvy a rozdělí se na dva stejné díly kvartací. Kvartace je proces získávání reprezentativního vzorku sypké povahy (půda, chemikálie apod.). [11] Dělíme stále na dva stejné díly tak dlouho, až jeden díl odpovídá hmotnosti pro zkušební vzorek minimálně 100 g sušiny. Zbytek konečného vzorku se vyčlení pro smyslové nebo fyzikální zkoušky. Případně pro mikroskopické vyšetření. Předsoušení konečného vzorku Předsoušení se používá u krmiv podléhajících zkáze a pokud vlhkost znemožňuje úpravu mletím. Z předsušeného vzorku se pak upraví zkušební vzorek. Předsouší se při teplotách ºC. Vlhkost se sníží tak, aby bylo možno vzorek pomlet (do drtitelné konzistence). Tím je vzorek připraven pro analýzu. Dle požadavků na hodnocení krmiva se stanovuje metoda hodnocení. 2.2 Produkční hodnocení krmiv Při produkčním hodnocení krmiv je vhodné zjišťovat, jaký účinek vyvolají živiny obsažené v krmivu v organismu zvířete. Pro produkci masa, mléka, vajec apod. má primární význam obsah energie v krmivu a obsah využitelných bílkovin, které poskytují stavební materiál organické hmoty aminokyseliny. Proto krmiva hodnotíme především na základě obsažené energie a na základě obsahu 6

11 využitelných NL. Pro dosažení optimální produkce musí být tyto dvě složky v krmné dávce vždy v určitém požadovaném poměru Energetické hodnocení krmiv Obsah energie je důležitým ukazatelem výživné hodnoty krmiva. Energie je v krmivu uložena v energetických živinách (těmi jsou sacharidy, tuky, NL). Energetické živiny z krmiva se využívají v první řadě k uspokojení energetických potřeb organismu a až poté jsou dostupné pro další metabolické funkce. Všechny životní pochody v organismu zvířat vyžadují energii. Zvířata jí musí přijímat každý den určité množství, které je dané jejich energetickou potřebou. Celková potřeba energie se dělí na potřebu záchovnou (potřebná pro základní fyziologické funkce organismu) a na potřebu produkční (potřebná pro růst, produkci mléka, vajec, svalovou práci). Denní potřeba energie pro jednotlivé druhy a kategorie zvířat i způsoby jejího výpočtu jsou uvedeny v příslušných krmných normách. Energie se vyjadřuje v kilojoulech (kj), případně v megajoulech (MJ). Energetickou hodnotu krmiva je možné změřit v laboratoři na kalorimetru. Zde se energie stanoví jako spalné teplo, které se uvolní při spálení krmiva v kalorimetrické bombě. Tato energie se označuje jako brutto energie (BE) a představuje celkový obsah energie v krmivu. Její hodnota je vždy vyšší, než je množství energie, které krmivo zvířatům skutečně poskytne, protože během trávení a metabolických přeměn živin dochází v organismu k energetickým ztrátám. Rozdělení energie Brutto energie - hrubá neboli celková energie. Lze jí určit jako spalné teplo, získané spálením krmiva v kalorimetru. Lze jí také vypočítat pomocí tzv. regresních rovnic (vycházejí z obsahu energetických živin násobených příslušnými koeficienty, které jsou dané tabulkově). Stravitelná energie - je stanovena jako brutto energie zmenšená o celkový obsah energie vyloučené ve výkalech. Stanovuje se bilanční zkouškou. Metabolizovatelná energie (ME) - je rovna energii přijatého krmiva, která se nevyloučila výkaly, močí ani plynem. Metabolizovaná energie se používá k produkčnímu hodnocení krmiv u prasat, drůbeže a masožravců. Netto energie (NE) - je zbývající energie po odečtení všech metabolických ztrát. Tedy energie přijatého krmiva, která se nevyloučila výkaly, močí ani plynem ani ve formě tepelných ztrát. NE se používá k produkčnímu hodnocení krmiv u přežvýkavců, a to ve dvou formách podle typu produkce: o NEL mléčná produkce (jalovice na odchov, dojnice). Část energie krmiva, která je využita na záchovu, tvorbu mléka a přírůstek do 800g/den. 7

12 o NEV masná produkce (jalovice a býci na výkrm). Je to část energie krmiva, která je využita na záchovu a pro přírůstek nad 800g/den Systém hodnocení NL u přežvýkavců Jedná se o nový systém hodnocení. Používá metodu Protein Digestible Intestine (PDI), která určuje protein skutečně stravitelný v tenkém střevě. PDI zohledňuje mikrobiální fermentaci v bachoru, degradaci NL krmiva a respektuje rozdílný původ celkového proteinu, který vstupuje do tenkého střeva. Zdroje proteinu v tenkém střevě u přežvýkavců: mikrobiální protein (odumřelá těla bakterií a prvoků z předžaludku), nedegradovaný protein z krmiva, protein endogenního původu. Největší podíl tvoří mikrobiální protein, nejmenší protein endogenního původu. Vzájemný podíl mikrobiálního proteinu a nedegradovaného proteinu z krmiva je daný degradovatelností NL v bachoru. Degradovatelné NL z krmiva poskytují zdroj dusíku pro syntézu mikrobiálního proteinu, nedegradovatelné NL jsou přímým zdrojem aminokyselin v tenkém střevě. PDI se skládá ze dvou frakcí: PDIA PDI nedegradovatelné NL krmiva skutečně stravitelná v tenkém střevě. PDIM PDI mikrobiální bílkoviny skutečně stravitelné v tenkém střevě. Pro syntézu mikrobiálního proteinu v předžaludku jsou nezbytné: - degradovatelné NL z krmiva (PDIMN), - využitelná energie z krmiva (PDIME). Obě složky musí být v krmné dávce ve vzájemné rovnováze. V případě, že je v krmné dávce nedostatek některé z uvedených složek, tak se syntéza proteinu omezuje. Výsledná hodnota uváděná tabulkách se určí výpočtem: PDIN = PDIA + PDIMN PDIE = PDIA + PDIME Každé krmivo má v tabulkách přiřazeny dvě proteinové hodnoty (PDIN a PDIE). Menší z obou hodnot představuje skutečnou proteinovou hodnotu krmiva, tedy skutečnou PDI. Vyšší hodnota vyjadřuje ideální stav. Je hodnotou potenciální a může jí být dosaženo, je-li krmivo doplněno s vhodným komplementárním krmivem. 8

13 2.2.3 Stravitelnost organických živin Stravitelnost je jedním z faktorů, které určují výživnou hodnotu krmiv. Stanovuje obsah živin v krmivu zjištěný chemickou analýzou (tzv. hrubé živiny) a živiny, které se rozštěpily a vstřebaly přes stěnu GIT (gastro-intestinal tract), tedy stravitelné, čisté živiny. Běžně se zjišťuje bilanční (zdánlivá) stravitelnost, kdy za stravitelné považujeme všechny živiny, které se nevyloučily ve výkalech. Bilanční stravitelnost představuje rozdíl mezi přijatými hrubými živinami v krmivu a živinami vyloučenými ve výkalech: Bilančně stravitelná živina = živina v krmivu živina ve výkalech Výkaly obsahují kromě nestrávených živin z krmiva také živiny metabolického původu, které pocházejí z organismu. Například odloupaný epitel (vnitřní či vnější krycí tkáň orgánů) z GITu, trávící enzymy, žluč, atd. Skutečná stravitelnost je tedy poněkud vyšší než bilanční, protože živiny metabolického původu ve výkalech stravitelnost snižují. Při stanovení skutečné stravitelnosti se proto musí živiny metabolického původu odečíst od živin ve výkalech: Skutečně stravitelná živina = živina v krmivu (celková živina ve výkalech živina metabolického původu ve výkalech) Stravitelnost živin se stanoví nejpřesněji zkouškami na zvířatech (bilanční zkoušky). Tyto zkoušky náleží mezi biologické zkoušení krmiv, vyhláška č. 451/2000 Sb, viz [12]. Stravitelnost živin se vždy stanoví na více zvířatech. Čím vyšší počet zvířat, tím je výsledek přesnější. Do pokusu musí být zařazena jen zdravá zvířata bez nemocí či parazitů. Metody stanovení stravitelnosti Jsou rozděleny na dvě základní skupiny: In vivo In vitro In vivo In vivo je odborný termín pocházející z latiny, který se dá přeložit jako v živém. Označuje se tak výskyt organizmů (popř. jejich orgánů nebo jejich ještě jednodušších biologických složek a biologických látek), které jsou v případě tohoto označení pozorované přímo v přirozených podmínkách, tedy v orgánech, pletivech či buňkách, resp. celých organizmech. [13] Klasická bilanční metoda - nejstarší, pracná, finančně náročná, ale absolutně přesná metoda. Zjistí se přesně přijaté množství živin chemickým rozborem krmiva. Totéž se určí i ve vyloučených výkalech - určí se hmotnost přijatého krmiva i vyloučených výkalů. 9

14 Pozorované zvíře je umístěno do tzv. bilanční klece, aby bylo možné přesně stanovit, kolik krmiva příjme a jaké množství vyloučí. Indikátorová metoda - je jednodušší, zvířata nemusí být v bilanční kleci, mohou přijímat krmivo libovolně. Nemusí se sbírat všechny výkaly, odebírají se jen jejich vzorky. Zkouška má stejné fáze jako klasická, do zkoušeného krmiva se ale zamíchá inertní látka, která nepodléhá rozkladu ani se neváže chemicky při průchodu trávícím ústrojím. Absolutní množství indikátoru zůstává nezměněné, jeho koncentrace ve výkalech je proto vyšší než v krmivu. Čím vyšší je koncentrace indikátoru ve výkalech, tím vyšší je i koeficient stravitelnosti. Ve výkalech se vylučuje veškerý přijatý indikátor, zatímco z přijatých živin pouze živiny nestrávené. In vitro In vitro je odborný termín, používaný v medicíně, biologii a dalších příbuzných oborech pracujících s organizmy a jejich částmi v umělých podmínkách laboratoře, který se z latiny překládá jako ve skle. V přeneseném slova smyslu, to pak znamená ve zkumavce, Ehrlen-Mayerově baňce, Petriho miskách a dalším laboratorním skle, kde lze něco pěstovat či kultivovat. [14] Tento typ metod pro stanovení stravitelnosti je méně náročný, ale i méně přesný. Má spíše orientační funkci. Simuluje se prostředí GIT v laboratorních podmínkách. Může být založena na: Stanovení obsahu NL rozpustných - metoda je použitelná pro všechny obsahy a všechny druhy krmiv s výjimkou krmiv s aditivním obsahem močoviny a krmiv minerálních, nerozlišuje proteinový a neproteinový dusík. Stanovení stravitelnosti organické hmoty krmiva - organická hmota (OH) představuje veškeré organické látky krmiva: OH = sušina popel Metoda nylonových sáčků - sáčky z porézní tkaniny naplněné krmivem se vkládají do trávicího traktu a zjišťuje se úbytek sledovaných živin po průchodu určitým úsekem trávicího traktu. U menších zvířat (např. drůbež) se používají mikrosáčky, které se dají spolknout a zachycují se až po vykálení Detergentní analýza (Cornellská analýza) Využívá se při hodnocení krmiv u skotu, systém vypracoval kolektiv autorů z Cornellovy univerzity v USA (Ithaka, stát New York) Cornell net carbohydrate and protein system. V současné době je tento systém zaváděný i u nás, největší využití má v chovech vysokoprodukčních dojnic. Systém dělí dusíkaté látky a sacharidy v krmivu do několika frakcí podle rychlosti, kterou se degradují v bachoru. Při vlastní analýze se dělí živiny do jednotlivých frakcí podle rozpustnosti v různých detergentech. Tato rozpustnost odpovídá jejich degradovatelnosti v bachoru. 10

15 Využívání výsledků detergentních analýz krmiv poskytuje daleko lepší obraz o chování přijatých krmiv i celkové krmné dávky v trávicím traktu přežvýkavců než klasická analýza. Tím se umožňuje daleko přesnější vybilancování potřeb živin jak pro správnou funkci bachoru, tak pro zvíře samé. Cílem je sestavit krmnou dávku tak, aby svým zastoupením jednotlivých frakcí živin vytvořila optimální podmínky pro činnost bachorové mikroflóry a aby se v bachoru vytvořilo co nejvíce mikrobiálního proteinu. Tato metoda využívá k výpočtu proteinové frakce (NL) a sacharidové frakce. Významné výpočty použité i v programu RKS jsou například: Neutrálně detergentní vláknina - neutral detergent fiber (NDF), Acidodetergentní vláknina - acid detergent fiber (ADF), Acidodetergentní lignin - acid detergent lignin (ADL) Stanovení sušiny Abychom mohli stanovit množství jednotlivých látek obsažených ve vzorku krmiva, je třeba vzorek zbavit vody. Každý typ krmiva obsahuje jiné množství vody, a proto by se i určené hodnoty lišily. Například sena, sláma a jadrná krmiva mívají % sušiny. Zelená píce má % sušiny. Protože se voda při trávení vylučuje, je třeba vodu vyloučit ze vzorku krmiva ještě před tím, než začne samotná analýza vzorku. Vyloučením vody vznikne tzv. sušina (pevná část krmiva). Obsah sušiny v krmivu se stanovuje jako váhový úbytek vzorku krmiva po jeho vysušení. Obsah sušiny má vliv na příjem krmiva zvířaty. Ovlivňuje také skladovatelnost krmiva, kvalitu konzervačního procesu a u zelené píce je ukazatelem vegetační zralosti porostu. Sušin existuje více typů, záleží na způsobu sušení a další úpravě po sušení. Pro výpočty v navrhovaném systému to je hlavně: Sušina určuje koeficient přepočtu na původní hmotu, vzniká sušením 50 g původního vzorku (odebraný vzorek krmiva) při teplotě 105 ºC po dobu 12 hodin. Sušina laboratorní slouží pro stanovení koeficientu přepočtu na 100% sušinu, vzniká sušením 5 g suchého vzorku při 60 ºC po dobu 5 hodin. Rozpustná sušina sušina, která se rozpustí v enzymech. Vzorek 50 g se nechá louhovat 12 hodin a pak se přefiltruje a suší při teplotě 105 ºC po dobu 12 hodin. Dle uvedených koeficientů se pak určují hodnoty základních živin, fermentace a minerálních látek obsažených v krmivu. 11

16 2.2.6 Stanovení dalších živin Mezi další důležité živiny patří tuk, BNLV, popel, vláknina, cukry, škroby a minerální látky. Nebudu popisovat laboratorní postup, pouze stručně uvedu proč se tyto látky určují. Pro lepší orientaci v těchto látkách je uvedeno složení vzorku krmiva na obrázku č.1. Obrázek 1 - Složení vzorku krmiva Stanovení hrubé vlákniny Stanovení obsahu vlákniny probíhá pomocí hydrolýzy. Od hmotnosti nehydrolyzovaného zbytku se odečte hmotnost popela. Tím se získá hodnota hrubé vlákniny. Ta obsahuje tři základní složky celulózu (té je největší podíl ve vláknině), hemicelulózu a lignin. Zbytek se dále zpracovává, aby se mohly určit hodnoty ADF a NDF: ADF připravuje se louhováním v kyselině, obsahuje pouze celulózu a lignin. NDF připravuje se v neutrálním roztoku, obsahuje všechny tři složky. Stanovení obsahu tuku Tuk se stanoví na základě rozpustnosti v rozpouštědlech. Výsledek je v procentech sušiny a tato hodnota se přepočítává na základě výše zmíněných koeficientů. A to na 100% sušinu a na původní hmotu. Obsah tuku ve vzorku krmiva je důležitý pro výpočty stravitelnosti a energie. Stanovení BNLV Zkratka BNVL označuje bezdusíkaté látky výtažkové. Je to skupina látek, do níž patří škrob, cukr a laktóza (mléčný cukr). Hodnotu BNLV lze spočítat dopočtem po stanovení dusíkatých látek, tuku, popela a vlákniny (je to zbytek laboratorní sušiny po těchto látkách): BNVL = laboratorní sušina NL tuk vláknina popel Stanovení popela Popelem rozumíme anorganické látky obsažené v krmivu. Je to různé anorganické znečištění (například písek) a minerální látky. Obsah popela v krmivu se stanoví jako váhový zbytek hmoty po zpopelnění při 550 ºC. 12

17 Stanovení minerálních látek Metody na stanovení obsahu minerálních látek jsou různorodé. Většinou bývají náročné na přístrojové vybavení, protože obsah těchto látek ve vzorku bývá stopový. Látky se většinou stanovují z popela. Mezi zjišťované minerální látky patří fosfor, vápník, hořčík, sodík, draslík, síra a měď. 2.3 Krmné směsi Krmné směsi jsou směsi krmných surovin s přídavkem nebo bez přídavku doplňkových látek, které jsou určeny jako kompletní nebo doplňková krmiva ke krmení zvířat. Krmné suroviny - krmiva, která jsou určena pro přímé použití ke krmení zvířat v původním stavu nebo po úpravě, dále k výrobě krmných směsí nebo jako nosiče pro výrobu premixů. Doplňkové látky - látky nebo přípravky použité při výrobě krmiv nebo při výživě zvířat, které mají specifické účinky vedoucí k dosažení lepší užitkovosti, zdraví, vyšší kvality a biologické hodnoty živočišných produktů a zlepšení životního prostředí. Například vitamíny, stopové prvky, enzymy, stimulátory růstu a další Rozdělení krmných směsí Krmných směsí je celá řada. Jejich rozdělení a účel je nutný pro správný výpočet krmné dávky, která bude implementována v navrhovaném IS systému (viz kapitola Analýza požadavků). Kompletní krmiva Směsi, které svým složením zcela kryjí potřebu živin příslušného druhu a kategorie zvířat, zkrmují se bez dalších doplňků kromě vody. Stačí k zajištění plnohodnotné výživy zvířat, používají se ve velkochovech hospodářských zvířat. Doplňková krmiva Doplňková krmiva jsou určena k doplnění základní krmné dávky složené ze statkových nebo jiných krmiv. Používají se v malochovech či v chovech domácích zvířat (psi, kočky). Bílkovinné koncentráty Tyto bílkovinné směsi krmiv slouží k výrobě krmných směsí. Svým obsahem živin odpovídají požadavkům na doplnění především dusíkatých látek u konkrétního druhu a kategorie zvířat. Nesmí být zkrmovány samostatně. Základ tvoří většinou pokrutiny (zbytky semen rostlin po vylisování oleje, bohaté na bílkoviny a tuky) a extrahované šroty, případně bílkovinné úsušky pícnin (granule) a další. Řadí se mezi doplňková krmiva. 13

18 Premixy Směsi doplňkových látek s nosiči nebo bez nosičů, které jsou určeny k výrobě krmných směsí. Minerální krmné směsi Doplňková minerální krmiva jsou směsi minerálních látek určených pro výrobu krmných směsí, případně k přímému využití ve výživě zvířat. Používají se pro doplnění obsahu minerálních látek v krmné směsi. Melasová krmiva Krmiva obsahující více než 140 g/kg cukrů v sušině, vyjádřených jako sacharóza, k jejichž výrobě byla použita melasa. Mléčné krmné směsi Směsi obsahující více než 40 % mléčných výrobků, které jsou určené k výživě mláďat savců. Krmné směsi pro zvláštní účel výživy Jsou to tzv. dietní krmiva, mají specifický účinek na určitý druh, resp. kategorii zvířat. Jejich podávání by měl doporučit veterinární lékař. Musí být podávány pouze ve speciálních případech, pro které jsou určené. Do této skupiny patří i klinické diety pro psy a kočky (krmné směsi pro zvířata s určitým zdravotním problémem). Medikované krmné směsi Směsi medikovaných premixů nebo směsi veterinárních léčiv s krmivy, uváděné na trh v konečné úpravě. Jsou určené k přímému zkrmování bez dalších úprav. Jejich výroba a užití se řídí požadavky Zákona o léčivech a příslušné vyhlášky - ZÁKON č. 79/1997 Sb. o léčivech a vyhláška č. 96/2000 Sb., kterou se stanoví správná výrobní praxe, správná distribuční praxe a bližší podmínky povolování výroby a distribuce léčiv včetně medikovaných krmiv. Medikovaný premix Je to jakýkoliv hromadně vyráběný veterinární léčivý přípravek určený pro výrobu medikovaných krmných směsí. 14

19 3 Vývoj informačního systému Informační systém je složitý celek, a tedy i jeho vývoj je složitým procesem. Nejedná se pouze o programování, ale o celkový návrh systému. Je třeba zjistit rozsah vyvíjeného systému, požadavky na jeho funkčnost, správné rozvržení a naplánování postupu prací, zvolit vhodný implementační jazyk vzhledem k prostředí, v němž bude IS provozován, vhodné uživatelské rozhraní pro budoucí uživatele, zajistit nasazení IS do provozu, jeho údržbu a možné rozšíření v budoucnu. Problematikou vývoje IS se zabývá softwarové inženýrství. Lze ho definovat takto: Softwarové inženýrství je činnost zahrnující inženýrství, informatiku a management, jejímž cílem je návrh, tvorba a údržba počítačových programů. [5] Softwarové inženýrství začalo vznikat zhruba od poloviny 60. let minulého století. Nejprve to byly IS tvořené na míru pro určitý hardware (HW). Mnoho projektů se nepovedlo dokončit nebo se náklady na jejich vývoj neúnosně zvětšovaly. Proto začaly vznikat metody a postupy, které by zaručily zlepšení celkového procesu vývoje IS a zaručily jeho zdárné dokončení. Základní aspekty, které určují úspěch vývoje IS, jsou: Životní cyklus vývoje IS, Modelovací jazyk, Podpůrné nástroje, Plánování projektu, Řízení projektu. Tyto základní prvky budou popsány dále. 3.1 Životní cyklus vývoje IS Životní cyklus vývoje IS je podobný popisu životního cyklu u rostlin a živočichů. Zahrnuje fáze, ve kterých se tento systém postupně nachází. Od svého počátku (uvažování o IS), přes jeho návrh, implementaci, nasazení až po jeho vyřazení z používání. Základní fáze životního cyklu jsou: Analýza požadavků, Návrh systému, Implementace, Integrace a nasazení, Provoz a údržba. 15

20 Analýza požadavků Je prvním krokem ve vývoji IS a také jedním z nejtěžších úkolů. Je třeba od zákazníka (dále označovaný pouze jako uživatel) zjistit, co vše má navrhovaný IS splňovat. To nebývá snadné. Uživatel nemusí být schopen formulovat své požadavky jasně, může mít přehnané požadavky. Pokud je uživatelů více, tak si mohou vzájemně odporovat. V této fázi se proto používají různé diagramy a modely, které pomáhají upřesnit požadavky na IS. Jsou to hlavně UML diagramy, viz dále. Návrh systému Návrh IS vychází ze shromážděných požadavků. Popisuje strukturu systému, data která se budou v systému vyskytovat a návrh databázové struktury. V této fázi se neuvažuje o konkrétní implementaci, ale pouze o platformě, na které bude navrhovaný systém implementován. I v této fázi se používá UML, abychom mohli modelovat, jak bude výsledný systém vypadat a jak by se měl chovat. Tento návrh se pak konzultuje s uživatelem a případně ho ještě zpřesňujeme. Implementace Konkrétní implementace IS vychází z návrhu systému. V této fázi se převážně programuje. Ještě se mohou zpřesňovat některé detaily, které byly v návrhu popsány jen částečně (například konkrétní algoritmy, jak řešit některé výpočty). Implementace bývá nejdelší fází při vývoji IS. Je to dáno i tím, že se během programování mohou vyskytnou chyby. Čím dříve se odhalí a opraví, tím lépe pro celkový vývoj. Z uvedeného důvodu je v této fázi vhodné provádět testování a ladění. Pojem ladění kódu znamená odstraňování nalezených chyb, viz níže. Také je vhodné rozpracovaný IS konzultovat se zákazníkem, jestli odpovídá jeho představám. Testováním označujeme postupy, které pomohou odhalit chybu. Probíhá ve všech fázích vývoje IS. V prvních fázích, když ještě není k dispozici žádný zdrojový kód pro testování, se provádí testování posouzením, zda je návrh odpovídající rozsahu a účelu navrhovaného IS. Testovací postupy jsou: Implementace kvality zdrojového kódu posuzujeme kvalitu zdrojového kódu: o Procházení zdrojového kódu, o Inspekce zdrojového kódu. Testování spouštěním zdrojového kódu spouštíme určitou část zdrojového kódu a sledujeme, zda se chová tak, jak jsme předpokládali. To lze testovat dvěma způsoby: o Black-box testing (testování černé skříňky) - testování funkčnosti ze specifikace, tedy co má program umět. o White-Box testing (testování bílé skříňky) - testování založené na znalosti zdrojového kódu, testujeme strukturu zdrojového kódu. 16

21 Laďěním odstraňujeme chyby ze zdrojového kódu. Pokud jsou syntaktické či sémantické, často nám může pomoci vývojové prostředí. Buď na chyby poukáže, nebo je případně samo opraví. Chyby zjištěné testováním se musí odstraňovat úpravou zdrojového kódu. Integrace a nasazení Naprogramování, sestavení a zavedení IS u uživatele. Vhledem k rozsahu IS bývá tato fáze postupná, tedy že se nasazuje vždy určitá část systému k již nasazenému celku. I když jednotlivé části systému jsou funkční, není zaručeno, že budou správně fungovat jako součást celkového systému. Proto v této fázi probíhá integrační testování (testuje se nově přidaná část IS vzhledem k již nasazeným částem). Integrační testování lze provádět dvěma metodami: Shora dolů, Zdola nahoru. Při testování shora dolů nasazujeme postupně komponenty od kořene hierarchie. Je zde ovšem problém, že komponenty na vyšší úrovni využívají komponenty na nižší úrovni, které ještě nejsou zavedeny. Je tedy třeba za tyto nižší komponenty vytvořit náhražky, které poslouží k otestování. Mohou být realizovány jako výpis hodnot, načtení tabulky, ruční zadání hodnot apod. Testování zdola nahoru postupuje v hierarchii komponent od listů ke kořenu. Při tomto testování je třeba vytvořit náhradu, která by nasazovanou komponentu využívala tzv. driver. Nasazení IS probíhá také na etapy, stejně jako integrace. A to prostřednictvím verzí. Každá verze má přidanou nějakou funkčnost. Každá verze opět prochází testováním, v tomto případě hlavně systémovým a přejímacím testováním. Systémové testování zjišťuje výkonnost systému, bezpečnost atd. Přejímací testy ověřují, zda systém splňuje všechny požadavky uvedené v zadání. Provoz a údržba Jakmile je uveden nový IS do provozu, starý IS (pokud v dané firmě nějaký byl) se přestává používat. Může být ponechán pro případné zjišťování některých dat, která nebyla do nového IS převedena, nebo jako záložní systém, kdyby nový selhal. Údržbou se myslí případné úpravy, rozšiřování funkčnosti a udržování IS v provozu. Údržbu můžeme rozdělit na: Opravnou - odstranění chyb a nedostatků. Adaptivní - přizpůsobení změnám výpočetního nebo podnikatelského prostředí. Vylepšovací - přidání funkčnosti či zlepšení kvality. 17

22 3.1.1 Modely životního cyklu Modely životního cyklu vycházejí z fází a přidávají interakci mezi nimi. Tedy jak na sebe jednotlivé fáze navazují. Lze je rozdělit na dva typy: Vodopád se zpětnou vazbou, Iterativní s inkrementy. Volba modelu určuje, jakým způsobem bude IS vyvíjen. Použitý model může být upraven pro daný projekt tak, aby co nejlépe vyhovoval jeho potřebám. Model Vodopád Historicky nejstarší model životního cyklu. Snažil se do vývoje IS zavést systematičnost. Každá fáze může začít až po dokončení předchozí (viz obrázek číslo 2). Nelze se vrátit k předchozí fázi a celý cyklus končí nasazením IS do provozu a jeho údržbou. Uživatel je zapojen pouze ve fázi analýzy požadavků. Klade velký důraz na dokumentaci, ta se píše ke každé fázi životního cyklu. Tento model se již moc nepoužívá, ale vychází z něj mnoho dalších modelů. Například model Vodopád se zpětnou vazbou, Iterativní životní cyklus s přírůstky a další. Analýza požadavků Návrh systému Implementace Integrace a nasazení Provoz a údržba Obrázek 2 Model Vodopád Model Vodopád se zpětnou vazbou Tento model je upravený model Vodopád (obrázek č.3a). Je zde přidaná zpětná vazba, která umožňuje v případě potřeby vrátit se opakovaně k předchozí fázi. Po dokončení cyklu je možné vrátit se k analýze požadavků a projít celým cyklem znovu. Například pokud chceme k hotovému IS přidat nějakou novou funkčnost. Model Vodopád se zpětnou vazbou, překrývajícími se fázemi a prototypováním I tento model vychází z modelu Vodopád, resp. Vodopád se zpětnou vazbou (obrázek č.3b). Jednotlivé fáze se v tomto modelu překrývají. Tím je dosaženo větší vazby mezi fázemi a také vyšší 18

23 flexibility. Pokud je potřeba učinit změnu v předchozí fázi, lze jí snadno učinit. Další podstatnou změnou oproti původnímu modelu je prototypování. To znamená, že vytváříme část programu, která představuje možné řešení. Tento prototyp slouží pouze pro ujasnění dalších kroků. Po upřesnění problémů se již dále s prototypem nepracuje a ani se nepoužije v implementaci. a) Model Vodopád se zpětnou b) Model Vodopád se zpětnou vazbou, překrývajícími se fázemi a prototypováním Analýza požadavků Analýza požadavků Návrh systému Návrh systému Implementace Implementace Integrace a nasazení Integrace a nasazení Provoz a údržba Provoz a údržba Obrázek 3 Model Vodopád se zpětnou vazbou a model Vodopád se zpětnou vazbou, překrývajícími se fázemi a prototypováním Iterativní životní cyklus s přírůstky Je zobrazen na obrázku č. 4. Bývá označován jako evoluční či inkrementální. Každá iterace znamená opakovaný průchod fázemi životního cyklu a přidává novou funkčnost (přírůstek) ke stávajícímu programu. Jednotlivé iterace odpovídají modelu vodopád s překrývajícími se fázemi. Po dokončení iterace je vytvořena nová verze programu. 19

24 Iterativní životní cyklus s přírůstky 1. iterace přírůstek Analýza požadavků 2. iterace Analýza požadavků Návrh systému Návrh systému Implementace Implementace Integrace a nasazení Integrace a nasazení Provoz a údržba Provoz a údržba Obrázek 4 Iterativní životní cyklus s přírůstky Mezi další modely životního cyklu patří například Spirálový model životního cyklu, MDA životní cyklus, životní cyklus agilního vývoje a další. 3.2 Modelovací jazyk Pro lepší představu o rozsahu, funkčnosti a procesech v navrhovaném IS se používají modelovací jazyky. Lze je rozdělit na strukturované a objektově orientované. Strukturované modelovací jazyky jsou založené na postupné dekompozici (rozkladu) systému na množinu funkcí (tzv. funkční dekompozice). Mezi tyto modely patří například Modelování datových toků (označovaný jako DFD data flow diagram). Mezi objektově orientované modelovací jazyky patří jazyk UML a v praxi se nejvíce používá Historie UML UML (unified modeling language) je unifikovaný modelovací jazyk určený pro grafické znázornění komponent, specifikací, navrhování a dokumentaci SW systémů. Tento jazyk vznikl kombinací různých metodik používaných při vývoji SW. Jejich sjednocením (unifikací) vznikl jazyk s bohatou sémantikou a syntaxí. A navíc obsahuje mechanizmy podporující jeho další rozšíření o nové definice a deklarace elementů. 20

25 Jazyk UML vznikal postupně. V roce 1994 přišli Grady Booch (OOSD - Object oriented software development) a Jim Rumbaugh (OMT - object modeling technique) do firmy Rational Software. Začali zde spojovat svoje metodiky na vývoj SW, aby dosáhli komplexní a kvalitní metodiky. V roce 1995 do firmy Rational Software vstoupil Ivar Jacobson s metodikou OOSE (object-oriented software engineering). Tím vznikl návrh UML verze 0.9 a metodika RUP (rational unified process). RUP popisuje fáze při vývoji SW, podle kterých by se mělo postupovat, aby byl návrh SW a jeho implementace úspěšná. V roce 1997 bylo UML 1.1 přijato jako standard pro vývoj SW. Postupně probíhaly další úpravy a rozšiřování jazyka. V dnešní době se používá UML verze 2.0 a pracuje se na další verzi Možnosti modelování v UML Jazyk UML má strukturu složenou ze tří částí stavebních bloků, obecných mechanismů a architektury. Stavební bloky představují základní modelovací prvky jazyka, vztahy a diagramy. Tyto bloky se skládají z prvků, vztahů (vazeb) mezi prvky a z diagramů. Diagramy zobrazují, co systém bude umět a jak této funkčnosti dosáhnout. Diagramy mohou modelovat statické a dynamické struktury. Statické struktury modelují nějaký stav. Mezi statické diagramy patří například diagram tříd, objektů, balíčků, komponent atd. Dynamické struktury modelují chování systému, jak systém bude reagovat a pracovat, pokud nastane nějaká událost. K vyjádření chování se používá například diagram případů použití, diagram stavového automatu, diagram sekvence a další. Obecné mechanismy jsou obecné způsoby, jak dosáhnout konkrétních modelů. Do těchto mechanizmů patří: Specifikace definuje, jak lze specifikovat modelovaný systém, tedy zaznamenat všechny vlastnosti navrhovaného IS. Specifikaci lze zapsat graficky nebo textově. Doplňky například zobrazení atributů. Mechanismus rozšiřitelnosti definuje omezení, stereotypy a připojené hodnoty. Obecná dělení definují pohled na modelovaný systém. Architektura systému je modelována diagramy. Pomocí nich můžeme modelovat strukturu databáze (dále jen DB), třídy a jejich dědění, případy použití, sekvenci nějaké činnosti apod. Každý z těchto diagramů modeluje odlišný pohled na systém a je součástí jednoho z pohledů na architekturu. Tyto pohledy se dělí podle koncepce 4+1, kterou zavedl Philippe Kruchten (viz obrázek č. 5), na pohledy: Logický zachycuje pojmy z problémové domény řešeného systému a jejich vzájemné vztahy. Procesní je doplňkem logického pohledu. Zabývá se chováním systému konkrétně jeho vnitřními procesy. 21

26 Implementační modeluje fyzické komponenty tvořící systém a jejich závislosti. Nasazení modeluje fyzické nasazení komponent na množinu výpočetních uzlů. Případů použití modeluje základní požadavky na navrhovaný systém. Obrázek 5 - Koncepce pohledu na architekturu 4+1 [1] Pro návrh IS jsem použil některé diagramy, které UML nabízí. Uvedu pouze stručný popis použitých diagramů. Diagram případů použití Případy použití (use case) jsou popisovány z pohledu zákazníka a modelují, jak rozsáhlý systém bude a co vše by měl umět z hlediska používání. Také definuje, kdo všechno bude systém používat a v jakém rozsahu, tedy definuje aktéry. Pojmem aktér rozumíme například uživatele, správce systému, administrátora apod. Případy použití je možné modelovat diagramem či slovně. Obecně se používá hlavně modelování pomocí diagramů, protože je přehlednější než slovní popis. 22

27 Diagram tříd Tento diagram slouží pro modelování tříd, dědičností mezi nimi a vazeb, které mezi nimi jsou. Také modeluje vnitřní strukturu třídy a její rozhraní. Používají se dvě varianty diagramů. Diagram tříd a konceptuální diagram tříd. Konceptuální diagram zobrazuje pouze základní třídy s jejich atributy a vazby mezi třídami. Nezobrazuje, jaké funkce budou tyto třídy mít. Diagram tříd obsahuje atributy i funkce. Dále může znázorňovat také třídy, které budou v systému zajišťovat automaticky nějakou funkci. Diagram případů použití Diagram případů použití modeluje, pro jaké úkony je systém navrhován. Co vše v něm zákazník bude dělat a jak požadované činnosti dosáhne. Také popisuje, kteří uživatelé budou systém používat. Dává nám první představu o rozsahu navrhovaného systému. Stavový diagram Diagram reprezentuje stavy a přechody mezi nimi. V podstatě popisuje konečný automat (má konečný počet stavů) a jeho funkci (přechody mezi stavy). Při návrhu systému tyto diagramy slouží pro zachycení stavů objektů (jejich atributů) a událostí, které vedou k jejich změnám. Často se používají například pro modelování obrazovek navrhovaného systému. Jednotlivé obrazovky pak představují stavy. Přechodem bývá nějaká akce uživatele, například změna parametru, stisknutí tlačítka či odkazu. ER diagram ER (entity relationship) diagram je určen k návrhu struktury DB. Popisuje entity, podle kterých se sestavují tabulky v DB a určuje vztahy mezi nimi (propojení tabulek přes jejich primární klíče), kardinalitu entit a vlastnosti atributů v entitách. Kardinalitou se rozumí násobnost mezi dvěma tabulkami a nabývají těchto hodnot: 1:1 Tato kardinalita znamená, že první tabulka se váže na druhou tabulku právě jednou a naopak. Pokud se tento vztah v návrhu DB vyskytne, je pravděpodobné, že lze tyto tabulky sloučit, aniž by došlo k porušení normální formy DB. 1:n První tabulka se může n-krát vázat na druhou tabulku, ale druhá tabulka je vázaná k první tabulce právě jednou. m:n První tabulka se může n-krát vázat na druhou tabulku. Druhá tabulka se na první může vázat m-krát. Za m, n lze dosadit i hodnoty 0..1, pokud vazba není nebo je právě jedna, případně 0..k (resp. 1..k), pokud je daná vazba žádná (resp. právě jedna) nebo k-násobná. 23

28 3.3 Podpůrné nástroje Podpůrnými nástroji při vývoji IS mohou být programy, nástroje, ale i kvalitní zázemí, motivace pracovníků, dobrá komunikace atd. Nástroji a programy je myšlen například programovací jazyk. I jeho výběr hraje důležitou roli. Pokud by se třeba zvolil programovací jazyk Pascal, pak by bylo poměrně obtížné sestavit kvalitní GUI (graphic user interface uživatelské rozhraní). S programovacím jazykem souvisí také volba vhodného vývojového prostředí. Některé nástroje jsou placené a nabízí velkou škálu funkcí, podporu apod. Pro jazyk C++ to je například vývojové prostředí Visual Studio od firmy Microsoft. Existují také volně šiřitelná vývojová prostředí třeba NetBeans IDE. Podpůrnými nástroji jsou i různá rozšíření, knihovny, frameworky (viz Hibernate). Umožňují nám využít již existující funkce a není třeba je znovu vymýšlet a programovat. Může to být například knihovna pro práci s hudebními soubory, pro práci s videem, pro snadnější přístup k databázi, zajímavé grafické komponenty atd. Jako podpůrný nástroj mohou sloužit také programy umožňující týmovou práci. Ty dovolují přistup na sdílený adresář, do kterého všichni členové týmu posílají svůj vytvořený zdrojový kód a také si z něho stahují zdrojový kód vytvořený dalšími členy týmu. Díky tomu mají k dispozici aktuální verzi vyvíjeného IS. Kromě uvedených nástrojů je důležitou podporou i kvalitní vedení týmu, jeho motivace a komunikace Typy databází Před samotným návrhem by bylo vhodné popsat základní typy Databází. V současné době existuje několik druhů databází. Každý typ je vhodný pro jiná data a přistupuje k nim odlišným způsobem. Základní rozdělení databází je následující: Relační databáze, Postrelační databáze Relační databáze Jsou nejstarší a dodnes velice hojně využívané databáze. Základním prvkem je tabulka (relace). Databáze obvykle obsahuje více tabulek, jež jsou mezi sebou provázány. Návaznost mezi tabulkami je řešena pomocí klíčů. Klíč (často uváděný jako ID) je jednoznačný identifikátor řádku v každé tabulce. Jak lze vidět na obrázku č. 6, tabulka Osoba se odkazuje na data v tabulce Přístup, tedy v tabulce Osoba, sloupci Přístup je uloženo ID určitého řádku z tabulky Přístup. ID je v tomto případě primární klíč. 24

29 Obrázek 6 - Relační databáze Relační databáze jsou relativně jednoduché a snadno pochopitelné. Jejich nevýhodou je, že pracují spíše s jednoduchými daty. Existuje hodně relačních databází od různých firem. Nejrozšířenější je MySQL, hlavně z toho důvodu, že je k dispozici zdarma. Tím je myšleno použití na vlastním serveru či domácím počítači. Jelikož mají být data z rozborů přístupná i zákazníkům firmy NutriVet, s.r.o., bude databáze umístěna u nějakého provozovatele. Ale i tak při porovnání nákladů vychází cena za používání MySQL velice příznivě. Tyto dva faktory, levné náklady a snadná možnost případné migrace na jiný komerční server, jsou hlavní důvody, proč byla pro budoucí IS zvolena relační databáze MySQL Postrelační databáze Postrelační databáze vychází z relačních databází. Ale oproti nim nabízejí podporu (specializaci) pro práci s daty na databázové úrovni. Databázový systém, který už nevystačí se základním relačním schématem a bez přímé podpory na implementační úrovni pro uvažovanou specializaci je zpracování jiných dat velmi neefektivní. [6] Postrelačních databází je dnes již celá řada. Například: Objektově orientované databáze mají rozšíření o objektový model a vztahy mezi objekty, umožňují lepší práci s daty při objektově-orientovaném programování. Temporální databáze pracují s temporální (časovou) logikou. Deduktivní databáze mají funkce pro analýzu dat, pomocí které dedukují skutečnosti z vložených dat. Prostorové databáze pracují s prostorovými objekty, využívají se v geodézii. Multimediální databáze mají funkce pro práci s multimediálním obsahem (archivy filmů, hudby, foto galerie). A další. Postrelační databáze jsou výhodné vzhledem k urychlení práce s daty. Jelikož se ale jedná o specializované databáze, bývají placené. Proto se začaly prosazovat různé nástavby, které by umožňovaly pracovat s relační databází jako by byla postrelační. Ovšem tyto nástavby zhoršují výkon databáze jako celku, protože musí s daty manipulovat a upravovat je ještě než výsledek odešlou. 25

30 3.3.4 Normální formy tabulek Ještě před samotným návrhem databáze se zmíním o normálních formách tabulek, protože jsou důležité pro samotný návrh. Mějme například v databázi uloženou adresu. Ta se skládá ze sloupců Ulice, Číslo popisné, Město, PSČ. Pokud bychom vytvořili jednu tabulku, už se dopouštíme porušení normálních forem a v databázi se nám budou ukládat duplicitní data. Jedno město má více PSČ, každé PSČ odpovídá určité čtvrti ve městě a v této čtvrti je více než jedna ulice, v každé ulici je více domů či vchodů tedy čísel popisných. Ideální by tedy bylo rozdělit každý sloupec do samostatné tabulky. Správně vytvořené tabulky by měly splňovat základní normální formy. 1NF 1. normální forma Všechny atributy jsou atomické, tedy dále nedělitelné. Například nelze do jednoho sloupce zapsat celou adresu (ulice, číslo popisné, město, PSČ). 2NF 2. normální forma Musí splňovat 1NF a navíc každý atribut, který není primárním klíčem, je na primárním klíči závislý. Primární klíč je jednoznačný identifikátor. Ve 2NF by nemělo docházet k redundanci dat. Pokud k ní dochází, je třeba návrh přehodnotit a upravit. 3NF 3. normální forma Tabulka je ve 3NF, pokud je ve 2NF a zároveň žádný atribut, který není primárním klíčem, není tranzitivně závislý na žádném klíči. BCNF Boyce-Coddova normální forma Tabulka splňuje BCNF, pokud splňuje 3NF a atributy, které jsou součástí primárního klíče, jsou vzájemně nezávislé. Ještě existuje 4. a 5. normální forma, ale v praxi se používají většinou pouze první tři normální formy. Ovšem normální formy nejsou jediným faktorem určujícím vzhled tabulek a celé databáze. Je třeba vzít v úvahu, s jakými daty budeme pracovat a podle toho tabulky optimalizovat. Pokud například budeme do databáze vkládat adresu hlavního nádraží v každém městě, pak nám stačí pro adresu jedna tabulka. Protože je jasné, že hlavní nádraží je v každém městě nejvýše jedno, a tedy tabulku není třeba dále rozdělovat. 26

31 3.4 Plánování projektu Každý projekt má určitý plán vývoje. Kdy se domluvit se zákazníkem na požadavcích, kdy se začne programovat, kdy bude k dispozici první funkční část, kdy bude vše hotové apod. Avšak jako se vyvíjí IS, je třeba vyvinout i plán projektu Vývoj projektového plánu Základem procesu plánování je tzv. Trojimperativ projektu - obrázek č.7. Má tři dimenze časovou (do kdy bude projekt hotový), věcnou (co se má udělat) a nákladovou (kolik bude stát). Uvedený Trojimperativ je obecný a může se od reálného lišit. Zákazník může požadovat nízkou cenu, což se odrazí na zhoršení kvality a delším čase vývoje. Nebo může chtít systém ve velice krátkém čase, což způsobí výrazný růst nákladů. Obrázek 7 - Projektový trojimperativ [1] Plánování však sleduje více ukazatelů než jen kvalitu, čas a náklady. To jsou pouze základní činitelé. Od nich se pak odvozuje, kolik úsilí a zdrojů je třeba na projekt nasadit. Mezi další významné činitele ovlivňující projekt patří například: Analýza rizik zkoumání, jaké nepříznivé situace mohou ohrozit či zdržet projekt. S analýzou rizik je spojena i tvorba protirizikových opatření, tedy jak se s možnou událostí vypořádat. Zajištění zdrojů pracovníci, vybavení, materiál, SW a HW potřebný k realizaci projektu. Kvalita produktu mezi kvalitativní charakteristiky patří funkčnost, přesnost, bezpečnost, spolehlivost, snadnost užívání, výkonnost, udržovatelnost, přenositelnost a další.. Velmi důležitý je co nejpřesnější odhad trvání a nákladů na jednotlivé fáze životního cyklu vývoje IS. Podle těchto odhadů pak lze provádět kontrolu, zda celý projekt probíhá podle plánu či zda se zdržuje oproti plánu. Tento odhad však není lehké určit. Na začátku není stanovena přesná specifikace toho, jak bude výsledný IS vypadat. Tato specifikace se stává přesnější až v pozdějších fázích. Proto se na 27

32 počátku počítá s finanční rezervou, v některých případech až čtyřnásobnou. Jak projekt pokračuje, začneme se blížit skutečné hodnotě nákladů Plán projektu Pro plán a jeho sledování je nutná tvorba časových plánů. Ty vytváří projektoví manažeři ze seznamu činností. Pro plánování se využívá Ganttův diagram, obrázek č. 8. Ten zaznamenává všechny dílčí činnosti, které se musí na projektu vykonat i jejich vzájemnou návaznost. V případě zaznamenaném na obrázku jsou tyto dílčí činnosti nazvány Subtask. Z těchto návazností pak vzniká tzv. kritická cesta. Je to posloupnost činností, které pokud se opozdí, opozdí dokončení celého projektu a naopak urychlení úkolů na kritické cestě urychlí dokončení celého projektu. Ganttův diagram není jediná možnost, jak plánovat činnosti. Lze použít například Úsečkový diagram nebo Plánování řízené úsilím. Jejich podrobný popis lze najít v literatuře [1]. Obrázek 8 - Ganttův diagram [1] Po sestavní plánu rozpočtu je třeba tento plán sledovat, abychom stále věděli, jak se daří plán plnit, zda nedochází ke zpožděním apod. Za tímto účelem se stanovuje režim sledování a frekvence kontrol (jakým způsobem kontrolovat a jak často) Rozpočtový plán Určit rozpočet projektu není jednoduché. Jak již bylo uvedeno, na začátku projektu není znám přesný rozsah budoucího systému a tudíž se odhad a reálná cena mohou značně lišit (až 4krát a to oběma směry). Pro určení rozpočtu existuje řada metod. Některé jsou založené na statistických údajích a výpočetních metodách, jiné spíše na úsudku experta. 28

33 Mezi hlavní metody odhadu rozpočtu patří: Expertní odhad založen na zkušenostech experta. Odhady na základě analogie odhad dle obdobných realizovaných projektů. Odhad řízený plánem dle úkolů, použitých zdrojů a dalších fixních nákladů z plánu projektu se spočítá celková cena. Odhad založený na modelu/algoritmu například FPA, COCOMO a další. Také rozpočtový plán se musí pravidelně sledovat. Podobně jako u plánu projektu lze sledovat čerpání financí v průběhu projektu. Také se často používá analýza přidané hodnoty. Je podstatná pro vedení projektu, protože stručně a jasně informuje všechny zainteresované strany o tom, jestli projekt nepřekračuje stanovený rozpočet. Má k dispozici celou řadu měřítek rozpočtové náklady provedených prací, odchylka plánování, skutečné náklady provedených prací a další. Jejich výpis lze nalézt v literatuře [1]. 29

34 4 Analýza požadavků Pro správný návrh IS, který bude organizaci vyhovovat, je třeba zjistit, jaké požadavky na tento systém daná organizace má. V tomto případě jsou největší nároky kladeny na práci s daty. Je jich hodně a navíc se mohou početně lišit dle rozsahu rozboru. První zákazník může požadovat komplexní rozbor na všechny měřitelné a spočítatelné hodnoty, druhý zákazník může požadovat pouze několik základních hodnot. Dle rozsahu zadaného rozboru se bude měnit i formulář, který se zákazníkovi vytiskne (tisková sestava). Abych mohl všechny potřebné požadavky zjistit, zvolil jsem přímou konzultaci ve firmě NutriVet, s.r.o. s předvedením postupu při zapisování hodnot laboratorního rozboru do programu RKS (rozbor krmných směsí), používaného v současné době. 4.1 Neformální specifikace Navrhovaný IS by měl mít dva základní moduly: První modul bude určen pro laboratoř. Bude sloužit pro vkládání dat, uložení rozborů do DB, tisk a export rozborů. Vzhledově bude vycházet ze současného programu RKS, ale bude obsahovat další vstupní pole a funkce. Bude označován jako RKS2. Druhý modul bude určen pro koncového zákazníka. Ten do něj zadá své přístupové údaje a připojí se k DB, kde se mu vyhledají jeho rozbory. Z nich si pak bude moci sestavit optimální krmnou dávku. Program mu spočítá optimální poměr jednotlivých krmiv. Pokud uživatel nebude mít přístup na internet, tak může data do programu importovat z nějakého přenosného média. Oba programy by měly být platformě nezávislé. U zákaznického programu je třeba zajistit, aby jeho ovládání bylo intuitivní a jednoduché. Bude označován zkratkou OKD (optimální krmná dávka). 4.2 Funkční požadavky Vzhledem k tomu, že je požadováno, aby byla aplikace rozdělena na dva moduly, budou i funkční požadavky rozděleny na dvě části. Funkční požadavky na laboratorní program a zákaznický program Laboratorní program Zakázka Může obsahovat více rozborů. Bude možné editovat spočítané hodnoty. 30

35 Zadávání zákazníků, firem, chovů, farem, skladů, konzervantů, původní hmoty, druhů vzorků, krmiv. Rozbor Pokud některé hodnoty nebyly měřeny, měl by mít laborant možnost vložit do rozboru průměrné hodnoty. Rozbor bude obsahovat hodnoty pro 100% sušinu a pro původní hmotu. Tabulkové hodnoty Budou jen pro doplnění rozborů (některých hodnot, které se neměřily). Jedny tabulkové hodnoty pro potřeby laboratoře a další pro každého zákazníka (aby měl možnost vytvořit si vlastní tabulkové hodnoty). Databáze Data se budou uchovávat maximálně 5 let. Databáze bude přístupná přes internet. Každý rok se bude sestavovat sborník průměrné hodnoty všech krmiv. Optimalizovat DB tak, aby neobsahovala prázdné hodnoty (pokud zákazník hodnotu nechce stanovit). Tisková sestava, práce s daty V tiskové sestavě neuvádět hodnoty, které se neměřily. Možnost exportovat (příp. importovat) data s využitím XML Zákaznický program Rozbor Zákazník má v programu všechny své rozbory, po výběru určitého rozboru se zobrazí hodnoty. Může je kombinovat a sestavovat různé krmné dávky. Program dopočítá optimální poměry jednotlivých krmiv. Zákazník si bude volit z vlastních tabulkových hodnot nebo z hodnot laboratoře, pokud bude potřeba doplnit hodnoty, které se nestanovily laboratorně. Tisková sestava, práce s daty Zákazník si bude moci vytisknout sestavené kombinace krmných dávek. Sestavené kombinace krmných dávek lze uložit a případně znovu načíst. 31

36 Stanovené rozbory se automaticky stáhnou přes internet. Možnost importovat data z rozborů do programu OKD. 4.3 Nefunkční požadavky Laboratorní aplikace by měla být odolná proti špatně zadaným datům. Aplikace bude dále automaticky počítat hodnoty, pokud jsou zadány všechny potřebné, laboratorně určené, hodnoty pro tento výpočet. Zákaznický program by měl automaticky stahovat nové rozbory zákazníka přes internet. Pokud nebude možné se k DB připojit, bude automaticky prohledávat zadaný adresář, zda v něm není soubor s novým rozborem. 4.4 Rozsah vstupních dat Jelikož program bude pracovat s velkým množstvím vstupních dat, rozhodl jsem se použít grafickou šablonu pro zjištění, kolik dat bude rozbor obsahovat. Tento grafický návrh jsem pak konzultoval ve firmě NutriVet, s.r.o. s hlavní laborantkou a majitelem firmy. Ke každé hodnotě se vztahuje kategorie, do které hodnota patří, a měrná jednotka. Každá hodnota se také ukládá do DB ve dvou hodnotách, ve 100% sušině a v původní hmotě. Takto získané informace mi pomohly optimalizovat návrh databáze, který je uveden dále. Jelikož se v oboru výživy hospodářských zvířat objevují nové metody pro stanovení některých hodnot, je potřeba IS a vkládání dat do DB navrhnout tak, aby byly další možné úpravy snadno proveditelné. 4.5 Plán projektu Projekt bude rozdělen na 3 iterace s použitím přírůstků v každé iteraci. Je uvažováno předběžně ještě o 4. iteraci. Ta by zahrnovala rozšíření obou programů o optimalizaci pro další chovná zvířata (základní verze je optimalizovaná pouze pro skot). Rozšíření ovšem závisí na poptávce zákazníků firmy NutriVet, s.r.o., proto ho nebudu podrobněji rozepisovat. První iterace bude zahrnovat laboratorní program, který bude komunikovat s DB a bude moci editovat data v ní uložená. Také již bude mít připravena všechna pole pro zadávání vstupních dat (a jejich výpočet). Postup prací je na obrázku č. 9. Po ukončení první iterace proběhne testování, zda jsou výpočty správné, zda vyhovuje uživatelské rozhraní a ovládání. Také budou shromážděny případné připomínky a návrhy na vylepšení. 32

37 Obrázek 9 - Plán 1. iterace Druhá iterace rozšíří laboratorní program RKS2 o výpočty nad zadávanými daty, ukládání rozborů do DB, export/import rozborů a tisk protokolů. V závěrečné fázi pak bude RKS2 doplněn o nové výpočty a vstupní hodnoty (viz obrázek č. 10). Po druhé iteraci bude již laboratorní program plně funkční a po otestování bude nasazen do firmy NutriVet, s.r.o. Obrázek 10 - Plán 2. iterace Třetí iterace bude zahrnovat tvorbu zákaznického programu, od návrhu GUI až po tisk a ukládání vypočítané krmné dávky (viz obrázek č. 11). Testování této části bude komplikovanější, protože nebude možnost porovnat výsledky v jiném programu. Nejprve proběhne testování v laboratoři, pokud budou výsledky uspokojivé, budou osloveni někteří zákazníci firmy, aby program odzkoušeli Analýza rizik Obrázek 11 - Plán 3. Iterace Rizika ohledně tohoto projektu lze rozdělit do tří kategorií: Obecná rizika - ohrožují projekt jako celek. Rizika spojená s prvním modulem - laboratorní program RKS2. Rizika spojená s druhým modulem zákaznický program OKD. Rizika budou popsána pro každou oblast zvlášť. Nejprve uvedu riziko, pak jeho příčinu a možné ošetření vzniku tohoto rizika (pokud existuje). Obecná rizika Jsou uvedena v tabulce č. 1. Zde bych uvedl hlavně riziko zpožďování projektu. Jelikož celý IS navrhuji a implementuji sám, tak je toto riziko velmi reálné, protože jsem postrádal možnost konzultace s dalšími odborníky, kteří se programováním v zemědělství zabývají. Také budu používat pro mě nové technologie, budu muset reagovat na dodatečné požadavky na vyvíjený IS apod. 33

38 Obecná rizika Riziko Příčina Řešení vytížení na jiných projektech nelze ošetřit špatná komunikace s firmou NutriVet, s.r.o. lze předejít udržováním kontaktu, pravidelnými schůzkami Zpoždění projektu nečekané problémy ve firmě NutriVet, s.r.o. nové technologie, které se musím naučit (Hibernate) Dodatečné požadavky na projekt Tabulka 1 Obecná rizika nelze ošetřit nelze ošetřit lze minimalizovat testováním ve fázi implementace Rizika spojená s modulem RKS2 Tato rizika se týkají hlavně návrhu a implementace modulu RKS2, jsou uvedena v tabulce č. 2. Zde bych jako hlavní riziko označil zavádění nových výpočtů a výběr dat k tisku. Zavedení nových výpočtů je rizikové hlavně proto, že se bude hůře hledat chyba není možnost porovnání s původním programem. Tiskové sestavy se také změní, ale jejich podoba se bude teprve projednávat, což může znamenat zpoždění projektu. Rizika spojená s modulem RKS2 Riziko Příčina Řešení práce s velkým množstvím provázaných dělat kontrolní porovnání hodnot s původním programem chyby ve výpočtech zavádění nových výpočtů Zpoždění projektu chybné vzorce chybné tabulkové hodnoty chybné vzorce chybné tabulkové hodnoty tvorba tiskových sestav, výběr dat k tisku Tabulka 2 Rizika spojená s modulem RKS2 konzultace ve firmě NutriVet, s.r.o., hledání ve zdrojovém kódu původního programu konzultace ve firmě NutriVet, s.r.o., hledání ve zdrojovém kódu původního programu konzultace ve firmě NutriVet, s.r.o. konzultace ve firmě NutriVet, s.r.o. konzultace ve firmě NutriVet, s.r.o. Rizika spojená s modulem OKD Tato rizika jsou v tabulce č. 3. Některá rizika se v této tabulce opakují, ovšem při implementaci a testování modulu OKD bude třeba spolupracovat nejen s firmou NutriVet, s.r.o., ale i s jejími zákazníky zemědělci. Jak bylo uvedeno v požadavcích, program má být jednoduchý na ovládání. Navíc ho budou používat lidé nepříliš zkušení v používání počítače. To může vést ke zpožďování projektu. Lze to řešit tak, že při testování u zákazníka se mnou bude i zástupce z firmy NutriVet, s.r.o., ale ani to nemusí zaručit rychlou a efektivní komunikaci. Dalším velkým rizikem je to, že se bude tvořit zcela nové GUI i funkce. Nebude možnost srovnání, takže kontrola výpočtů bude muset probíhat ručními výpočty, což bude zdlouhavé. 34

39 Rizika spojená s modulem OKD Riziko Příčina Řešení práce s velkým množstvím provázaných průběžné testování chyby ve výpočtech hodnot chybné vzorce průběžné testování chybné tabulkové hodnoty průběžné testování nové výpočty chybné vzorce průběžné testování chybné tabulkové hodnoty průběžné testování špatná orientace v programu testování u vybraných zákazníků návrh GUI firmy NutriVet, s.r.o. Zpoždění projektu špatná komunikace se zákazníky testovat za přítomnosti zástupce z firmy NutriVet, s.r.o. stanovení optimální krmné dávky chybějící hodnoty (neúplné rozbory) grafické vyjádření Tabulka 3 Rizika spojená s modulem OKD přidání hodnot z tabulek testování u vybraných zákazníků firmy NutriVet, s.r.o. Uvedená rizika nejsou všechna. Je možné, že v průběhu projektu narazím na problémy, se kterými jsem nepočítal. Tato rizika se budou řešit operativně, až pokud se nějaká vyskytnou. 35

40 4.6 Diagram případů použití Diagram případů použití, na obrázku č. 12, reprezentuje případy použití laboratorního programu. Aktérem je Laborant. Laboratorní program je určen hlavně pro manipulaci s daty. Má umožňovat editovat (vytvářet, upravovat a mazat) data. Každý rozbor je zadán zákazníkem. Pod pojmem zákazník je myšlena nějaká firma, která má zadanou kontaktní osobu. V rozboru může být uvedena také farma a sklad. I tyto údaje je potřeba editovat. Dále je v rozboru zaznamenáno, o jaký druh vzorku se jedná, pro jaký chov je určen, zda byl použit nějaký konzervant a jakého je tento konzervant typu. Pokud jsou tyto údaje nastaveny, Laborant začne zapisovat hodnoty stanovené rozborem. Program by měl umožnit duplikaci existujícího rozboru, aby bylo možné pro jiný rozbor pouze upravit některé hodnoty a nemusely se všechny znovu zadávat. V editaci zákazníka bude ještě volba Povolení přístupu, která umožní zákazníkovi využít přístup k databázi a dále s jeho rozbory pracovat. Obrázek 12 - Případy použití laboratorního programu Zákaznický program bude pracovat s daty analýz. Jaké bude mít možnosti práce s programem ilustruje obrázek č. 13. Program si potřebná data (rozbory krmiv) stáhne automaticky z DB nebo, pokud nemá zákazník připojení k internetu, může si data do OKD importovat. Zákazník si bude moci data z rozborů prohlížet a v případě potřeby upravovat. Také může rozbor porovnávat se staršími rozbory, aby zjistil, jak kvalitní je krmivo v porovnání se staršími rozbory a zda bylo dosaženo lepších hodnot. Zákazník bude z rozborů krmiv sestavovat krmné dávky. Vypočítané krmné dávky si 36

41 může zákazník uložit a znovu načíst do programu. Tento program by měl být co nejjednodušší, aby práci s ním zvládl i člověk, který používá počítač pouze příležitostně. Obrázek 13 - Případy použití zákaznického program 37

42 5 Návrh IS V návrhu IS pro rozbor laboratorních krmiv jsem použil konceptuální diagram tříd (nerozepisoval jsem funkce jednotlivých tříd). Z tohoto diagramu jsem vycházel při návrhu struktury DB a propojení jednotlivých tabulek. Dále jsem použil diagramy návaznosti obrazovek, vycházející z dříve uvedených případů použití. Navrhují, jaké obrazovky by měl IS obsahovat a jak mezi nimi lze přecházet. 5.1 Konceptuální diagram tříd Konceptuální diagram tříd (obrázek č. 14) je sestaven s ohledem na požadavky firmy, aby vytvořil vhodné třídy pro práci s daty. V systému nebude řešeno přihlašování (s výjimkou přístupu zákazníka k databázi). Také jednotlivé třídy pracují vždy s jinými daty. Proto v návrhu diagramu není případ dědění tříd. Při tvorbě rozboru je třeba uvést zadavatele rozboru a pak konkrétní hodnoty (laboratorně stanovené či dopočítané). Proto je vytvořena třída Rozbor. Tato třída je hlavní a nejdůležitější. Obsahuje základní informace o rozboru a pracuje s dalšími třídami. Zadavatelem rozboru bude nějaká firma. Třída Firma může vlastnit několik rozborů, má adresu a případně i fakturační adresu. Firma také může mít několik kontaktních osob, které jí zastupují. Každá osoba může mít povolený jeden přístup k databázi. Třída Adresa bude spojena s třídou Mesto. Třída Rozbor je propojena s třídami obsahujícími nejrůznější informace. Například chov, sklad, krmivo, konzervant atd. Z těchto tříd je pro nás nejzajímavější třída Hodnota. Ta bude pracovat s hodnotami rozborů. Tyto hodnoty jsou spojeny s názvem, kategorií a jednotkou, které jim náleží. 38

43 Obrázek 14 - Konceptuální diagram tříd 39

44 5.2 Návrh databáze ER diagram Návrh databáze (obrázek č. 15) vychází z konceptuálního diagramu tříd (obrázek č. 14). Zadavatelem rozboru je firma. U ní bývá uveden název, adresa a případně i fakturační adresa, pokud je odlišná od adresy firmy. Také je zde kontakt, který odkazuje na osobu, se kterou probíhá komunikace a které se předávají vyhotovené rozbory. Osoba může obsahovat příjmení, jméno, titul, , tel, fax a mobil. Může mít povolený přístup do DB. Přístup je pomocí ID a hesla. Bude časově omezený na určitou dobu, kterou stanoví firma. Adresa použitá u osoby a firmy se skládá z ulice, čísla popisného a PSČ. Poštovní směrovací číslo je unikátní, proto lze použít toto číslo jako index. K němu je přidaný název města. Jelikož většina zemědělských družstev sídlí na vesnici, není třeba oddělovat PSČ a název města či obce (nevznikne mnoho záznamů, které budou mít stejný název města, ale jiné směrovací číslo). DB bude obsahovat hlavně hodnoty z laboratorních rozborů. Proto jsou tabulky navržené tak, aby byly co nejvíce přizpůsobeny proměnnému objemu dat. Spojovací tabulkou pro tyto hodnoty je tabulka Rozbor. Ta obsahuje základní údaje, jaké firmě rozbor patří, datum přijetí a vyřízení rozboru, z jaké farmy a skladu vzorek krmiva pochází, typ chovu, typ použitého konzervantu, typ krmiva pdi (resp. vzorku), typ původní hmoty a typ pdi. Poslední uvedená tabulka obsahuje koeficienty pro dopočet některých hodnot. Tyto koeficienty tvoří celek, a proto jsou uvedeny v jedné tabulce. Dalšími tabulkami spojenými s rozborem může být poznámka a hodnota. Tato tabulka slouží k ukládání naměřených a vypočítaných hodnot rozboru. Tyto hodnoty se vždy uvádí ve 100% sušině a v původní hmotě (v původní sušině obsažené ve vzorku krmiva) a mohou mít různý název, kategorii a jednotku. Proto jsou tyto tři tabulky oddělené, aby nedocházelo ke zbytečné redundanci dat. 40

45 Obrázek 15 - ER diagram návrhu databáze 41

46 5.3 Diagram návaznosti obrazovek Obrázek č. 16 zobrazuje, jak by na sebe měly navazovat obrazovky laboratorního programu. Hlavní obrazovkou je Seznam rozborů. Z ní lze editovat (tedy smazat, upravit či přidat) chov, druh vzorku, typ konzervantu, typ původní hmoty a typ krmiva, adresu, firmu, osobu, statek či farmu. Pro práci s rozbory slouží obrazovky Založit rozbor a Duplikovat již vytvořený rozbor. Po založení nového rozboru (resp. jeho duplikaci) se zapisují hodnoty do Zadávání hodnot rozborů. Tato obrazovka reprezentuje celkem pět obrazovek Základní živiny, Stravitelnosti, Fermentace, Energie a Minerály/Mikrobiologie. Pokud se zvolí duplikovat rozbor, načtou se data, již existujícího rozboru, a ty lze upravit a uložit do DB s novým ID rozboru. Dále lze vybrat ze seznamu rozborů záznam, který se má smazat. Po této volbě program přejde na další obrazovku, kde se zeptá na potvrzení volby. Obrázek 16 - Diagram návaznosti obrazovek laboratorního programu 42

47 Diagram na obrázku č. 17 zobrazuje návaznost obrazovek v zákaznickém programu. I zde je hlavní obrazovkou Seznam rozborů. Tento seznam obsahuje pouze rozbory jednoho zákazníka. Ze seznamů lze zvolit libovolný rozbor a zobrazit si jeho detaily, které lze dále upravovat a změny uložit. Také lze vybrat několik seznamů a nechat program spočítat optimální krmnou dávku. Program obsahuje tabulkové hodnoty. I ty lze upravit podle potřeb každého zákazníka. Pro možnost nastavení importu dat do programu je zde obrazovka Nastavení. V této obrazovce se zadává přístup k databázi. Pokud nemá uživatel přístup k internetu, lze zadat adresář, ve kterém budou umístěny rozbory. Případně lze zvolit ruční import dat. Obrázek 17 - Diagram návaznosti obrazovek zákaznického programu 43

48 6 Implementace Implementace navrhovaného IS je časově nejdelší fází projektu vývoje IS, jak již bylo řečeno v dřívější kapitole. Ještě před jejím zahájením je třeba stanovit programovací jazyk a vývojové prostředí, případně podpůrné nástroje. Jelikož je požadováno, aby byl IS nezávislý na platformě, rozhodl jsem se pro jazyk Java. Ten tuto nezávislost splňuje a umožňuje objektové programování. Další výhodou je, že pro tento jazyk existuje framework Hibernate pro práci s databází, bude popsán v další kapitole. Jako vývojové prostředí jsem si zvolil NetBeans, konkrétně verzi Má již zabudovaný framework Hibernate, je lokalizován pro český jazyk a také má podporu tvorby GUI. 6.1 Popis objektů V této kapitole uvedu důležité objekty použité v IS RKS2. Jsou to objekty, které odpovídají návrhu a slouží pro mapování do databáze. Dále objekty sloužící k výpočtu a uchování hodnot. A pak objekty reprezentující GUI Základní objekty Základní objekty vychází z návrhu tříd. Jsou základními stavebními bloky celého IS. Každý z těchto objektů má přiřazený mapovací soubor pro Hibernate, který slouží pro překlad objektu na relační databázi a naopak. Mapování bude podrobněji popsáno dále, v kapitole Hibernate. Zmíněný mapovací soubor má stejné počáteční jméno jako základní objekt, pouze má jinou příponu hbm.xml. Jak název napovídá, je uložen ve formátu XML (extensible markup language). Základní objekty jsou v balíčku rks.tridydb. Obsahují atributy uvedené v návrhu a odpovídají sloupcům v příslušné tabulce databáze. Dále obsahují základní funkce pro práci s atributy - setatribut a getatribut (ulož hodnotu do atributu, vrať hodnotu atributu) Objekt pro práci s databází Komunikaci s databází obstarává objekt Databaze.java. Tento objekt obsahuje následující funkce pro práci s databází: zápis objektu funkce setobjekt(objekt) změna objektu funkce editobjekt(objekt) smazání objektu funkce deleteobjekt(objekt) vyhledání položky dle ID getobjekt(id) vyhledání položek v databázi getobjekty() 44

49 Objektem je myšlen název jakéhokoliv základního objektu. Je využit framework Hibernate, který umožňuje pracovat s objekty nad relační databází, viz kapitola Hibernate. Díky tomu lze ukládat, měnit, mazat a načítat přímo objekty, resp. kolekci objektů. To výrazně usnadňuje práci s daty Objekt pro práci s datovými kontejnery S objekty, resp. s daty v nich obsaženými, se pracuje po celou dobu běhu programu. Aby se nemusely objekty stále nahrávat z databáze, je vytvořena speciální třída RksSeznamy.java. Tato třída obsahuje datové kontejnery pro základní třídy. Datovým kontejnerem je List. Pro každý typ základního objektu jsou vytvořeny dva datové kontejnery. První z nich je určen pro objekty samotné. Například obsahuje objekty typu Adresa: List<Adresa> adresy Druhý datový kontejner obsahuje datový typ String a slouží pro slovní popis daného datového typu. Tedy pro uvedený objekt Adresa existuje datový kontejner: List<String> adresys Do tohoto kontejneru se po načtení všech objektů typu Adresa z databáze ukládá textový popis. Naplnění provádí funkce nactiobjekts(). Pro uvedený příklad kontejnerů objektů typu Adresa to je funkce nactiadresys(), která uloží do textového řetězce název ulice a číslo popisné. Druhý kontejner slouží pro naplnění ComboBoxů, viz návrh GUI, a následně k výběru požadované adresy při zadávání či editaci kontaktu pro daný rozbor. Hlavním účelem objektu RksSeznamy.java je načtení a uchování dat po celou dobu běhu aplikace. Data do příslušných datových kontejnerů se nahrají při zavolání funkce NactiSeznamy(). Kromě načtení dat tento objekt už s databází nekomunikuje. Data mohou používat ostatní objekty programu hlavní program a editační okna. Je samozřejmě nutné udržovat tato data konzistentní vzhledem k databázi. Proto se po úspěšné operaci nad databází (uložení, změna, smazání objektu) provede stejná operace i v příslušném datovém kontejneru. Tím je dosaženo zmenšení přenesených dat mezi databází a IS data se nahrají při startu IS a pak se provádí jen výše zmíněné operace manipulující v jednom okamžiku pouze s jedním objektem. 6.2 Hibernate Jak jsem uvedl již dříve, rozhodl jsem se pro IS firmy NutriVet, s.r.o. použít databázi MySQL a framework Hibernate z důvodu efektivní a snadné práce s daty. 45

50 6.2.1 Architektura Hibernate Hibernate je framework pro programovací jazyk Java. Framework je SW, který slouží jako podpora při programování a vývoji SW projektů. V případě Hibernate se uvedená podpora týká práce s objekty nad relační databází. Obrázek č. 19 zobrazuje architekturu aplikace s frameworkem Hibernate. Ten vytváří vrstvu mezi aplikací, která používá objekty, a databází, která používá relační tabulky. Obrázek 18 - Architektura aplikace [21] Pro správnou funkci je třeba nastavit konfigurační a mapovací soubory. Tyto soubory jsou zapsány v XML. Konfigurační soubor obsahuje nastavení připojení k databázi a uvádí, jaké třídě přísluší jaký mapovací soubor. Konfigurační soubor Hibernate je uveden v příloze. Mapovací soubor je popsán dále. Hibernate umožňuje Objektově-Relační mapování (ORM). To znamená, že používá relační databázi, ale programátor k této databázi přistupuje pomocí Hibernate, jako by byla objektová. Vkládá, upravuje a maže objekty. Nemusí vyhledávat vztahy mezi nimi. Také usnadňuje zachování dat z objektů i po ukončení běhu aplikace Mapování Aby mohl Hibernate mapovat (ukládat objekty do relační databáze a z relační databáze složit objekt), je třeba toto mapování nastavit v konfiguračním souboru a v dané třídě. Mějme například dva objekty, Mesto a Adresa. Jsou znázorněny na obrázku č. 20, odpovídají objektům z návrhu Konceptuálního diagramu tříd. Vidíme, že objekt Adresa také obsahuje atribut PSČ a Mesto (má tento atribut dokonce jako identifikátor místo ID). 46

51 Obrázek 19 - Vztah Města a Adresy Pomocí mapování lze tyto dva objekty navzájem provázat. Mapování se zadává do objektu a také do mapovacího souboru. V objektu se ke každému atributu přiřadí, jaký sloupec reprezentuje. Pro uvedené objekty je toto objektové mapování vidět na obrázku č. 21 atributy objektu Mesto a na obrázku č.23 atributy objektu Adresa. Lze vidět, že objekt Adresa má při mapování přímo třídu Mesto, místo toho, aby měl jen její ID, resp. PSČ. Avšak je třeba ještě nastavit mapovací soubory pro tyto dva objekty. Mapovací soubor pro objekt Adresa je na obrázku č.22 a mapovací soubor objektu Mesto je na obrázku č.24. Jak lze na obrázku č.22 vidět, mapovací soubory odpovídají zápisu atributů v daném objektu. Každému atributu přiřazuje, na jaký sloupec v tabulce se bude překládat. Obrázek 20 - Atributy objektu Mesto Obrázek 21 - Mapování třídy Mesto Zajímavější je již zápis v objektu Adresa (obrázek č. 23) a jeho mapovacím souboru (obrázek č. 24). U atributu PSČ v objektu Adresa je = psc ). Tato anotace 47

52 zajišťuje mapování přes klíč psc. Další určuje, v jakém vztahu bude objekt Adresa vzhledem k mapovanému objektu Mesto. Obrázek 22 - Atributy objektu Adresa Obrázek 23 - Mapování třídy Adresa Uvedený zápis nám umožní pracovat s objektem Adresa tak, že se již nemusíme starat o to, jaké Mesto bude v adrese obsaženo. Toto je pouze ukázka použití Hibernate ve vytvářeném IS. Hibernate umí vkládat nejen samotné objekty do jiných, ale může mapovat také kolekce, což se použije při práci s hodnotami z rozboru Příkazy pro práci s databází Jelikož Hibernate tvoří vrstvu mezi programem a databází, má svůj vlastní dotazovací jazyk HQL (hibernate query language), přes který lze zadávat příkazy. Je odvozen od SQL (structured query 48

53 language), který se používá v relačních databázích a je mu velice podobný. Například načtení všech objektů Adresa z databáze lze provést pomocí příkazu uvedeného na obrázku č. 25. Obrázek 24 - Načtení objektů Adresa z databáze Nejprve se vytvoří transakce. Pak do Query q zapíšeme dotaz a ten je okamžitě vykonán. Výsledek je obsažen v kolekci q.list(). Samozřejmě lze vyhledávat podle parametrů, jak tomu bylo u relační databáze. Obrázek č. 26 znázorňuje příkaz na načtení adresy s určitým ID. Obrázek 25 - Načtení objektů Adresa dle zadaného ID Další základní příkazy pro práci s databází: save(adresa) uloží objekt adresa do databáze. update(adresa) provede změnu v existujícím záznamu. delete(adresa) smaže zadaný objekt. commit() provede zadaný příkaz. 6.3 Tvorba GUI Při tvorbě GUI (graphic user interface grafické uživatelské rozhraní) je velmi žádoucí zapojit i zákazníka. Protože to je on, kdo bude pak program používat a pokud bude spokojený s ovládáním programu, bude spokojený i s programem jako celkem. Samozřejmě program musí splňovat funkční požadavky. Pokud program vychází z nějaké předlohy, předchozího IS firmy, tak mívá velkou část GUI shodnou s předlohou. Dochází jen k drobným úpravám, které mají vylepšit celkové ovládání. Pokud se jedná o tvorbu IS na zakázku, pak zákazník ví pouze to, co od navrhovaného IS požaduje. Je tedy na programátorovi, aby zvolil odpovídající grafický návrh celého IS. Vhodným návrhem je myšleno takové GUI, které je intuitivní a snadno ovladatelné (například zavedením klávesových zkratek, předvyplněním některých vstupních polí apod.). V případě návrhu GUI pro IS jsem vycházel částečně z původního programu RKS. Ten posloužil pro základní koncept rozvržení vstupních polí a grafickou podobu. Hlavně z důvodu snadného přechodu zaměstnanců na nový IS. I tak bylo učiněno několik zásadních změn, například na 49

54 první záložce. Také přibylo okno pro založení rozboru a několik editačních oken. Tato editační okna slouží pro úpravu základních dat v databázi (krmivo, chov, tabulkové hodnoty) a budou popsána dále. Vzhledem k velikosti obrázků RKS, resp. jednotlivých záložek, jsou tyto obrázky umístěny v příloze této práce. Popíšu pouze, co se ve které záložce vyskytuje a v případě funkčních prvků (tlačítko, ComboBox) popíšu, jaký mají význam na výpočet. Hlavní záložka Seznam rozborů Záložka zobrazuje seznam rozborů, hlavní informace o rozboru a tlačítka pro editaci rozboru (založení, duplikace, uložení a smazání). Tlačítko pro založení nového rozboru vyvolá okno, kde se zadají základní informace (bude popsáno dále). Vždy, pokud je vyvoláno nějaké pomocné okno pro editaci dat, tak je vyvolávající okno znepřístupněno až do doby, než je vyvolané okno ukončeno. Je to z důvodu, aby uživatel nevyvolal více stejných oken a aby byl nucen pomocné okno uzavřít dříve než bude pokračovat v práci. Základní živiny V základních živinách jsou pouze vstupní pole pro zadávání laboratorních hodnot. Vstupní pole, do kterých lze zapsat hodnotu, jsou označena oranžově a lze se mezi nimi přepínat pomocí klávesy Tab. Pole reagují na uvolnění klávesy. Na tuto událost se dopočítávají příslušné hodnoty závislé na vstupním poli. Podobně pole reagují i v ostatních záložkách. Stravitelnosti V některých případech se stravitelnost nepočítá. Z toho důvodu je v této záložce možnost zvolit dvě možnosti Proveď výpočet a Neprovádět výpočet včetně energií. Při volbě neprovádět výpočet se vstupní pole zamknou a nedovolí zapsat hodnoty. V případě, že požadujeme výpočet, lze si zvolit stravitelnost dle krmiva. K tomu slouží ComboBox v horní části této záložky. Dle zvoleného krmiva se dosadí tabulkové hodnoty do příslušných polí a zkopírují se i do vstupních polí pro analýzu. Většinou se tyto tabulkové i analyzované hodnoty shodují. V případě, že by se lišily, je možné hodnoty ve sloupci Analýza upravit. Fermentace Tato záložka obsahuje pouze vstupní pole a zbylá pole se dopočítávají. Výpočty nejsou závislé na jiných záložkách (kromě koeficientu přepočtu na původní hmotu). I zde se přepočítávají analyzované hodnoty na 100% sušinu a původní hmotu, ale počítají se odlišně. Energie 50

55 Výpočet energie závisí na typu krmiva PDI. Dle této volby se doplňují vstupní koeficienty pro výpočet energií. Volba typu původní hmoty slouží spíše pro budoucí statistické údaje vyplývající z rozborů (viz rozšíření). Po výběru krmiva a případné úpravě koeficientů se na stisknutí tlačítka Proveď výpočet dopočítají hodnoty energií. Minerály/Mikrobiologie Zde se počítají pouze přepočty na 100% sušinu a na původní hmotu, dle zadaných hodnot z chemické analýzy. Nový rozbor Při volbě Nového rozboru se zobrazí okno, kam se zadávají základní informace o rozboru. Těmito informacemi jsou: Druh vzorku, Popis vzorku, Místo odběru, Datum přijetí/odevzdání vzorku pro tuto volbu byla použita knihovna SwingX. Umožňuje zobrazit okno s kalendářem pro snadnou volbu data. Chov, Typ konzervantu, Konzervant, Zadavatel/Uživatel, Farma. Pro snadné zadání těchto informací jsou použity ComboBoxy. V případě, že by požadovaná položka nebyla uvedena v ComboBoxu, je možné vyvolat příslušné editační okno a zadat ji do seznamu. Menu Menu obsahuje v současné fázi vývoje čtyři hlavní položky. Je to Soubor, Editace, Nastavení a Nápověda. Většina editací je jednoduchých (viz editační okna). Mezi složitější editace patří Kontakt a Typ PDI. Editace budou popsány dále. Struktura menu, v závorce je uvedena klávesová zkratka (pokud byla přiřazena): Soubor o Ukončení programu (Ctrl+Q) Editace o Farma (Ctrl+F) o Chov (Ctrl+C) 51

56 o Kontakt (Ctrl+U) o Konzervant o Krmivo o Sklad (Ctrl+S) o Typ krmiva PDI o Typ PDI (Ctrl+P) o Typ původní hmoty Nastavení o Znovu načíst data Nápověda o O aplikaci Editační okna Slouží pro editaci položek vytvoření nové položky, úprava položky, smazání položky. Většina editačních oken je podobná, je v nich uveden jen popis (textový řetězec), viz obrázek č. 27. Tyto editace jsou jednoduché. Obrázek 26 - Jednoduchá editace Jednoduchá editace 52

57 Toto editační okno slouží pouze pro editaci textového řetězce. Je tedy poměrně jednoduché. Obsahuje tabulku hodnot, která vypisuje ID a textový záznam. Po vybrání položky v tabulce (kliknutí do tabulky) se aktivují tlačítka Změnit a Smazat. Pokud bude chtít uživatel přidat nový záznam, je zde vstupní pole. Na začátku obsahuje text..záznam... Do pole se zapíše nový text a uloží se pomocí tlačítka Přidat. Obdobná editace slouží i pro jiné hodnoty. Editace na obrázku č. 27 ukazuje jednoduché editační okno pro zadávání Chovu. 53

58 Editace kontaktu Editace kontaktu je již složitější (viz obrázek č. 28). Pracuje celkem s pěti základními objekty Mesto, Adresa, Osoba, Firma, Prístup. Obrázek 27 - Editace kontaktu Jak lze z obrázku č. 28 vidět, také toto editační okno obsahuje tabulku se základními údaji. Kromě této tabulky obsahuje vstupní pole a ComboBoxy (ty slouží pro výběr firmy a volbu data, do kterého bude platit přístup k rozborům). Přístup k rozborům je volitelný. Pokud vybereme, že editovaná osoba může přistupovat k rozborům, je třeba ještě zvolit datum, do kterého jí tento přístup povolíme a zadat heslo. Heslo lze zadat ručně nebo použít tlačítko generovat. 54

59 ComboBox Výběr firmy umožňuje vybrat dvě speciální zadání. První je Zadat firmu ručně. V tomto případě lze zadat název firmy a obě adresy. Druhou možností je prázdné pole, tedy není zadána firma. Editace Typu PDI Tato editace umožňuje zadávat a měnit tabulkové hodnoty typu PDI (viz obrázek č. 29). Tyto hodnoty slouží pro výpočet energií. Hodnoty jsou tabulkové, a proto se nepředpokládá častá editace ani mazání hodnot. Hodnoty lze pouze přidávat nebo měnit. upraven. Obrázek 28 - Editace typu PDI Uvedený návrh GUI je pouze předběžný. Bude konzultován ve firmě NutriVet, s.r.o. a případně 55

60 7 Zavádění IS Zaváděním IS do firmy je myšlen proces, při kterém se vyvíjený IS začne testovat přímo u zákazníka. Tedy na HW a v prostředí, kde bude po doladění nasazen do provozu. IS RKS2 je zaváděn po první iteraci, jak bylo uvedeno v plánu projektu. Již fungují výpočty, komunikace s databází a editace položek. Nyní je třeba IS otestovat, než bude jeho vývoj pokračovat. 7.1 Testování IS po 1. iteraci Testování bude probíhat v laboratoři firmy NutriVet, s.r.o., ve spolupráci s hlavní laborantkou. Pro testování jsem určil několik klíčových bodů, které je třeba prověřit: Správné načítání tabulkových hodnot, Přesnost a správnost výpočtu, GUI vzhled, ovládání o Celkový vzhled a ovládání aplikace o Nový rozbor o Editační okna Editační okna funkčnost. Správné načítání tabulkových hodnot Budu testovat, zda se načítají správné hodnoty. Průběh testu: 1. Vyberu určitou hodnotu ze seznamu. 2. Zkontroluji, že se zapsaly do textových polí všechny hodnoty a že odpovídají datům v databázi. 3. Porovnávám vypočítané hodnoty s hodnotami v rozboru. Přesnost a správnost výpočtu Tento test má za úkol odhalit možné chyby ve výpočtech. Průběh testu bude následující: 1. Vyberu nějaký rozbor z původního programu. 2. Do IS dosadím hodnoty stanovené analýzou. 3. Budu kontrolovat, zda vypočítané hodnoty souhlasí s hodnotami z původního programu. 4. Pokud bude objevena chyba, přejdu ke kontrole výpočtu a vstupních hodnot tohoto výpočtu. 56

61 Vzhled a ovládání Vzhled bude testován vizuálním posouzením hlavní laborantky. A to pro záložky RKS2, založení nového rozboru a editační okna. Ovládání bude testováno takto: 1. Předvedení ovládání. 2. Vyzkoušení ovládání hlavní laborantkou. 3. Sepsání nedostatků a návrhů na zlepšení. Funkčnost editačních oken Testování funkčnosti vstupní pole, tlačítka, tabulka, případně další prvky a ovládání editačních oken: 1. Vstupní pole pro zápis hodnot, 2. Funkčnost tlačítek, 3. Funkčnost tabulky, 4. Další interaktivní prvky v editačním oknu, 5. Návrhy na zlepšení. 7.2 Výsledky testování Testování proběhlo v laboratoři, za asistence hlavní laborantky. Bylo zjištěno několik nedostatků, hlavně ve výpočtech. Přesnost a správnost výpočtu Ve všech výpočtech byla zjištěna odchylka, v některých případech až 2% oproti předpokládané hodnotě. Tato odchylka vznikla zaokrouhlováním. V původním RKS se zaokrouhluje na čtyři desetinná místa, kdežto výpočty v IS budou bez zaokrouhlování. Tím byla odchylka způsobena. Avšak pro otestování správnosti hodnot bude dočasně zavedeno zaokrouhlování všech vypočtených hodnot. Vzhledem k tomuto problému bude testování opakováno po zavedení zaokrouhlování, aby byla ověřeno, zda výpočty souhlasí. Výsledky testování výpočtů v jednotlivých záložkách: Základní živiny chyba v přepočtu na původní hmotu. Chybná vstupní hodnota, vstupem není analyzovaná hodnota, ale hodnota přepočtená na 100% sušinu. Chyba při výpočtu OH, odečítat popel. Stravitelnosti výpočty jsou v pořádku. Fermentace výpočty jsou v pořádku. Energie chyba v načítání tabulkové hodnoty deg. Chyba ve výpočtech hodnoty PDIN a PDIE. 57

62 Minerály/Mikrobiologie výpočty jsou v pořádku. Vzhled a ovládání Ke vzhledu nebylo připomínek. Ovládání je dostatečné, ovšem byly vzneseny návrhy na vylepšení. Funkčnost editačních oken Funkčnost je vyhovující. Celkově bylo testování hodnoceno pozitivně. Drobné nedostatky při výpočtu se předpokládaly. Vzhled je vyhovující, ohledně ovládání bylo vzneseno několik návrhů na vylepšení. 7.3 Návrhy na zlepšení Návrhy na zlepšení byly spíše obecné a týkaly se ovládání programu: Přepínat mezi poli pomocí klávesy Enter. Nyní to lze pouze klávesou Tabulátor. Při zadávání čísel na numerické klávesnici by přepínání vstupních polí pomocí klávesy Enter bylo rychlejší. Výpočet rozpustné sušiny v záložce Základní živiny zrušit, bude se zadávat pouze ručně. Tabulkové hodnoty v záložce Stravitelnost zkopírovat také do analyzované hodnoty. Záložka Fermentace konstanty KVV, NH2 a NH3 jsou vždy stejné, zakázat editaci těchto vstupních polí. Záložka Fermentace faktory pro výpočet KVV, NH2 a NH3 jsou často podobné, předvyplnit vstupní pole, editaci ponechat. Výpis rozborů časově omezit. Zobrazovat pouze rozbory v aktuálním roce. Pro zobrazení starších rozborů přidat ovládací prvky. Bude vhodné použít komponentu kalendář a přidat tlačítko pro potvrzení časového výběru. 7.4 Další postup vývoje IS Úspěšným otestováním a zapracováním připomínek přejde projekt do 2. iterace vývoje. Bude implementována práce s rozborem uložení, duplikace a načtení rozboru, export dat, tisk a nové výpočty. Tiskové sestavy se budou tvořit zcela nové. Původní tiskové sestavy (uvedené v příloze) jsou již nevyhovující. Jsou nepřehledné a obsahují zbytečně mnoho hodnot, které se většinou nestanovují. Je zvažována také varianta, že by bylo vytvořeno více variant sestav k tisku. Dle typu původní hmoty 58

63 by se pak automaticky zvolila optimální varianta a ta se vytiskla. Vzhled tiskové sestavy je zatím v jednání. Pro vytvoření tiskové sestavy, která je prozatím podstatou komunikace se zákazníkem a archivace protokolů ve firmě NutriVet, s.r.o., chci zvolit knihovnu JasperReports, která je licencována jako opensource (volně využitelný SW). Umožňuje vytvářet sestavy pomocí technologie XML a sdružuje metody pro komunikaci s tiskovým rozhraním. Zároveň umožňuje export do formátů pdf a html, což by mohlo být vítaným rozšířením pro implementaci IS v další iteraci vývoje. Společnost, která vytvořila tuto knihovnu nabízí i program pro editaci tiskových sestav přes grafické rozhraní. Tato aplikace umožňuje jednoduchým způsobem vytvořit vzhled a napojení dat tiskové sestavy. V programové části se pak pomocí hashovací tabulky nebo pole objektů dá tisková sestava naplnit daty a odeslat k tisku. Knihovna by tak mohla být vítanou oporou pro správu tiskových dokumentů laboratoře, což byl nedostatek současného IS, který firma využívá. Tento systém umožňuje snadné rozšíření o nové hodnoty (resp. výpočty). I uživatel, který nemá zaměření v oboru informačních technologií, je schopen navrhnout vlastní sestavu pro tisk a vývojář pouze vytvoří nový datový kontejner pro předání požadovaných dat. Kromě tiskových sestav bude ještě RKS2 doplněn o nové výpočetní metody. Jelikož nebude možnost srovnání nově vypočítaných hodnot, bude třeba důkladného testování, spojeného s ručními výpočty. Toto testování bude probíhat v laboratoři. 59

64 8 Závěr Diplomová práce měla navrhnout, implementovat a nasadit IS pro laboratoř krmiv. To vše pro firmu NutriVet, s.r.o., která se touto problematikou zabývá. Práce pro mě byla přínosná hlavně v tom, že jsem si mohl vyzkoušet teoretické znalosti v praxi. Navrhování a implementování IS pro zákazníka je až kriticky závislé na komunikaci. V případě této práce byla komunikace se zadavatelem bezproblémová. I přesto nastala prodleva při dojednávání podstatných detailů IS. Problémy nastaly hlavně při řešení některých nejasností implementace. Například se vyskytl problém ve výpočtech. Původní program zaokrouhloval na čtyři desetinná místa. Nový IS nezaokrouhloval výpočty (pracoval s číslem na sedm desetinných míst) a tudíž bylo dosaženo větší přesnosti. To způsobilo rozdíl v některých hodnotách až 2 %. Tento problém způsobil určité zdržení projektu, protože bylo nutné testování přesnosti výpočtů opakovat. Ve druhé iteraci měly být implementovány tiskové sestavy a nové výpočty. Vzhledem k tomu, že zatím nebyla určena přesná podoba tiskových sestav, nemohl jsem řešit tisk. Jaké výpočty se budou implementovat je již určeno, avšak nastalo zdržení s dodáním vzorců pro výpočet. Tyto nové výpočty pochází z univerzity Wisconsin, USA. Jelikož nemám prozatím potřebné vzorce k dispozici, nemohl jsem je implementovat do IS. Pro RKS2 není potřeba řešit víceuživatelský přístup, protože rozbory bude zadávat pouze hlavní laborantka. Víceuživatelský systém bude implementován až na modulu OKD. Původně byla zvažována varianta, že se použije již existující program (Fabermatica), a do RKS2 se přidá jen export potřebných dat ve formátu přijatelném pro tento program. Jelikož se dohoda ohledně využití tohoto programu nepodařila, bylo rozhodnuto, že i uživatelský modul OKD se bude programovat. Při každém vývoji většího IS se vyskytnou problémy. Nejzávažnější problémy, které se vyskytly během vývoje IS, byly spojeny s dobou jejich řešení. Při řešení problémů či nejasností během práce na určitém školním projektu je možné sjednat schůzku všech členů během několika dnů. Avšak pokud se jedná s majitelem firmy, je toto složitější. Majitel nemá vždy čas, musí se věnovat zákazníkům, partnerům apod. Tato skutečnost může zpozdit jednání až o několik týdnů. V návrhu a plánu projektu jsem tuto skutečnost podcenil a výsledkem je, že jsem nestihl implementovat všechny iterace návrhu. I přes to, zadavatel trvá na dokončení projektu. Práce bude pokračovat dokud nebude kompletně předán celý IS zadavateli. Věřím, že se mi podaří naplnit nejen všechny body zadání, ale i plánovaná rozšíření projektu. Po dokončení IS je uvažováno o implementaci Banky dat. To se bude týkat práce nad daty získaných z rozborů. Bohužel se to nepovede do obhajoby projektu. I přes to osobně hodnotím tento diplomový projekt jako velmi přínosný. V této diplomové práci jsem využil znalostí získaných na Fakultě informačních technologií na Vysokém učení technickém v Brně (hlavně z předmětu AIS, PIS a GJA). 60

65 Při vývoji projektu jsem postrádal možnost týmové porady při řešení nějakého konfliktu. Například při rozhodování jak implementovat práci nad DB, seznamy atd. Na druhou stranu jsem prozkoumal nové technologie, komunikoval se zákazníkem a řešil problémy, které se v průběhu projektu vyskytly, což pro mě bylo velmi přínosné. Budoucnost tohoto IS je v tom, že poskytuje komfort při práci s rozbory zákazníkovi i firmě NutriVet, s.r.o., což bylo hlavní ideou projektu. 61

66 Literatura [1] ZENDULKA, Jaroslav; BARTÍK, Vladimír; KVĚTOŇOVÁ, Šárka. Analýza a návrh informačních systémů. Brno: FIT VUT v Brně, s. [2] Wikipedia, the free encyclopedia [online] [cit ]. Unified Modeling Language - Wikipedia, the free encyclopedia. Dostupné z WWW: < [3] STEIN, René. Interval.cz [online] [cit ]. Návrh aplikací v jazyce UML - Unified Modeling Language Interval.cz. Dostupné z WWW: < [4] Object Management Group - UML [online] [cit ]. Object Management Group - UML. Dostupné z WWW: < [5] Wikipedie, otevřená encyklopedie [online] [cit ]. Softwarové inženýrství. Dostupné z WWW: < _in%c5%been%c3%bdrstv%c3%ad>. [6] KOLÁŘ, Dušan. Pokročilé databázové systémy. VUT Brno, FIT, s. Přednášky. VUT Brno, FIT. Dostupné z WWW: < [7] Wikipedie, otevřená encyklopedie [online] v 05:03. [cit ]. Hibernate - Wikipedie, otevřená encyklopedie. Dostupné z WWW: < [8] Hibernate - JBoss Community [online] [cit ]. Dostupné z WWW: < [9] Účetnictví, daně, právo - Sagit [online]. 23. března 2001 [cit ]. SBÍRKA ZÁKONŮ - VYHLÁŠKA Ministerstva zemědělství ze dne 23. března 2001, kterou se stanoví požadavky na odběr vzorků a principy metod laboratorního zkoušení krmiv, doplňkových látek a premixů a způsob uchovávání vzorků - Sbírka zákonů - Sagit. Dostupné z WWW: < [10] ŠÍMA, RNDr. Pavel, et al. Postupy laboratorního zkoušení krmiv, doplňkových látek a premixů - I. 2., opravené a doplněné, Brno : Ústřední kontrolní a zkušební ústav zemědělský v Brně, s. ISBN [11] Wikipedie, otevřená encyklopedie [online] [cit ]. Kvartace - Wikipedie, otevřená encyklopedie. Dostupné z WWW : < [12] Účetnictví, daně, právo - Sagit [online]. 11. prosince 2000 [cit ]. SBÍRKA ZÁKONŮ - VYHLÁŠKA Ministerstva zemědělství ze dne 11. prosince 2000, kterou se provádí zákon č. 91/1996 Sb., o krmivech, ve znění zákona č. 244/2000 Sb. - Sbírka zákonů 62

67 - Sagit. Dostupné z WWW: < [13] Wikipedie, otevřená encyklopedie [online] [cit ]. In vivo - Wikipedie, otevřená encyklopedie. Dostupné z WWW : < [14] Wikipedie, otevřená encyklopedie [online] [cit ]. In vitro - Wikipedie, otevřená encyklopedie. Dostupné z WWW : < [15] SCHNEIDER, Robert D.. MySQL Oficiální průvodce tvorbou, správou a laděním databáze. Praha : Grada Publishing, a.s., s. ISBN [16] PUGH, Eric; GRADECKI, Joseph D. Professional Hibernate. Indianapolis (Indiana) : Wiley Oublishing, Inc., s. ISBN [17] NOVOTNÝ, Róbert. Novotnyr@ics :: Wiki Main / Róbert Novotný [online] [cit ]. Novotnyr@ics :: Wiki Java / Tutoriál k Hibernate. Dostupné z WWW: < [18] Java Tutorial [online] [cit ]. Hibernate << Java Tutorial. Dostupné z WWW: < Hibernate/Catalog0350 Hibernate.htm>. [19] MoroSystems - úspěšné webové aplikace a outsourcing vývoje software nad platformou Java / J2EE [online] [cit ]. Kapitola 6 - ORM nástroj Hibernate. Dostupné z WWW: < [20] PICHLÍK, Roman. Dagblog [online] [cit ]. Dagblog: 9/09/2005-9/09/2005. Dostupné z WWW: < [21] BĚHÁLEK, Marek. Java [online] [cit ]. Hibernate. Dostupné z WWW: < [22] JasperForge: JasperReports Project Home [online] [cit ]. JasperForge: JasperReports Project Home. Dostupné z WWW: < [23] Vlastův blog [online]. 12. Červen 2007 [cit ]. Dynamické PDF pomocí JasperReports, ireport a Spring Frameworku Vlastův blog. Dostupné z WWW: < [24] PROCHÁZKA, Tomáš. Výukový kurz použití JasperReports frameworku. Semestrální projekt [online]. 2006, [cit ]. Dostupný z WWW: < [25] JEŽEK, Kamil. Java portál [online] [cit ]. Java portál. Dostupné z WWW: < 63

68 Seznam zkratek ADF ADL BE BNVL COCOMO DB DFD ER FPA GIT GUI HQL HW IS IT kj NL MDA ME MJ NDF NE NEL NEV OH OKD OMT ORM OOSE PDI PDIA PDIE PDIM PDIMN PDIME PDIN RKS SQL SW UML XML acido-detergent fiber (kysele detergentní vláknina) acido-detergent lignin (kysele detergentní lignin) brutto energy (hrubá energie) bezdusíkaté složky constructive cost model databáze data flow diagram entity relationship functional point analysis gastro-intestial tract graphic user interface hibernate query language hardware informační systém informační technologie kilojoul dusíkaté látky model driven architecture metabolic energy (metabolizovaná energie) megajoul neutral-detergent fiber (neutrálně detergentní vláknina) netto energy (čistá energie) NE pro mléčnou produkci NE pro masnou produkci organická hmota optimální krmná dávka object modeling technique object-relation mapping object-oriented software engineering protein digestible index (index trávení proteinů) PDI nedegradovatelné proteinová hodnota PDI mikrobiální vlákniny degradovatelné NL z krmiva využitelná energie z krmiva proteinová hodnota rozbor krmných směsí structured query language software united modeling language extensible markup language 64

69 Seznam příloh Příloha 1. GUI modulu RKS2 Příloha 2. GUI pro editace Příloha 3. Tisková sestava Příloha 4. Konfigurační soubor Hibernate Příloha 5. DVD 65

70 Příloha 1. GUI modulu RKS2 Modul RKS2 obsahuje celkem šest záložek Seznam rozborů, Základní živiny, Stravitelnosti, Fermentace, Energie, Minerály/Mikrobiologie. U každé z nich uvedu stručný popis a obrázek. Seznam rozborů Toto je hlavní záložka modulu (obrázek č. 30). Zobrazuje základní popis rozborů, které jsou v DB. Při výběru rozboru se zobrazí podrobnější informace. Také jsou zde ovládací tlačítka pro práci s rozborem. V horní části je menu s položkami Soubor, Editace, Nastavení a Nápověda. Menu soubor zatím obsahuje pouze položku Ukončit. Menu Editace obsahuje editace různých dat. Pro některé položky byla zavedena klávesová zkratka, aby bylo jejich vyvolání snadnější. V Nastavení je momentálně pouze volba Znovu načíst data. Tato volba nahraje data z DB do seznamu. Nápověda obsahuje informace o programu. Obrázek 29 - Seznam rozborů 66

71 Základní živiny Obsahují vstupní pole pro zadání analyzovaných hodnot. Na základě těchto hodnot se dopočítají další hodnoty na zadané hodnotě závislé. Nejdůležitější jsou koeficienty pro přepočet na 100% sušinu a na původní hmotu. Pomocí těchto koeficientů se analyzované hodnoty přepočítávají. Tyto koeficienty jsou v horní části obrázku č. 31. Všechna vstupní pole jsou barevně zvýrazněna, pro snadnější orientaci. Obrázek 30 - Základní živiny 67

72 Stravitelnosti V této záložce se počítají stravitelnosti na základě typu krmiva. Pro výběr krmiva slouží ComboBox v horní části záložky. Po výběru se automaticky doplní tabulkové i analyzované hodnoty. Analyzované hodnoty lze dále upravovat, vyplní se z toho důvodu, že bývají často shodné s tabulkovými. Stravitelnosti se počítat nemusí lze zvolit neprovádět výpočet. Při této volbě se zakáže editace vstupních polí i ComboBoxu. Obrázek 31 Stravitelnosti 68

73 Fermentace Záložka fermentace (obrázek č. 33) je pouze výpočetní. Na základě analyzovaných hodnot se doplní přepočty, případně se vypočítají hodnoty (KVV, NH2, NH3, Proteolýza, Sumy kyselin). Obrázek 32 - Fermentace 69

74 Energie Výpočet energie je závislý na typu krmiva PDI a typu původní hmoty. Oba parametry se vybírají pomocí ComboBoxu. V případě, že požadovaný typ není uveden, lze ho přidat. Tlačítka vedle ComboBoxu zobrazí příslušné editační okno. Samotný výpočet proběhne po stisku tlačítka Proveď výpočet. Obrázek 33 Energie 70

75 Minerály/Mikrobiologie Poslední záložka (obrázek č. 35) pracuje s minerálními prvky a mikrobiologickými hodnotami. Analyzované hodnoty se opět přepočítávají na 100%sušinu a původní hmotu. Mikrobiologické hodnoty se pouze doplní a již se s těmito hodnotami neprovádí další výpočty. Obrázek 34 - Minerály/Mikrobiologie 71

76 Příloha 2. GUI pro editaci Některá GUI pro editaci byla uvedena již v kapitole Tvorba GUI. Uvedu proto pouze editační okna, která ještě uvedena nebyla. Jedná se hlavně o ostatní jednoduché editace (jednoduché protože editují pouze textový řetězec). Také zde uvedu editační okno pro adresu. Editace adresy Editace adresy (obrázek č. 36) používá dva ComboBoxy a dvě vstupní pole. ComboBoxem lze vybrat město a PSČ. Dle tohoto výběru se zobrazí ulice a číslo popisné v příslušném poli. Pokud chceme zadat nové hodnoty, tak zatrhněme Nové město, resp. Nové PSČ. Tím se ComboBox stane editovatelný a lze do něho zapsat nové údaje. Pro trvalé změny potvrdíme příslušném tlačítkem. Obrázek 35 - Editace adresy 72

77 Jednoduché editace Obrázek č. 37 -editace Chovu, Farmy, Krmiva, Skladu, Typu krmiva a Typu původní hmoty. Obrázek 36 - Jednoduché editace 73

78 Příloha 3 Tisková sestava Tisková sestava je řešena pomocí knihovny JasperReports. Tato knihovna obsahuje editor (obrázek č. 38) ve kterém se sestava snadno připraví, případně upraví. Zadají se názvy a proměnně, přes které se při tisku do sestavy zapíší konkrétní hodnoty. Obrázek č. 39 zobrazuje jak vypadá vytištěná sestava (předání hodnot není ještě implementováno, proto se místo hodnot zobrazilo null). Obrázek 37 - Editor tiskové sestavy Mezi další přednosti této knihovny patří také to, že lze tiskové sestavy posílat nejen na tiskárnu, ale i do PDF souboru, html souboru apod. 74

79 Obrázek 38 - Vytištěná sestava rozboru 75

80 Příloha 4 Konfigurační soubor Hibernate Jak bylo uvedeno v kapitole Hibernate, pro správnou činnost framework je potřeba konfigurační soubor a mapování třídy která se bude ukládat, resp. načítat z DB. Ukázka mapování je již ve výše zmíněné kapitole. Pro úplnost uvádím ještě konfigurační soubor, obrázek č. 40. Tento konfigurační soubor obsahuje parametry pro připojení k DB ovladač a typ DB, umístění DB, přístupové údaje. Kromě těchto parametrů obsahuje mapování tříd a konkrétních mapovacích souborů pro tyto třídy. V mapovacím souboru třídy se pak nachází již konkrétní atributy třídy a sloupce v DB na které se tyto atributy mapují. Obrázek 39 - Konfigurační soubor Hibernate 76