Sem vložte zadání Vaší práce.

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Bakalářská práce Tvorba formulářů z popisu v XML s použitím knihovny Qt4 Marek Hakala Vedoucí práce: Ing. Josef Vogel, CSc. 21. května 2012

Poděkování Děkuji vedoucímu bakalářské práce Ing. Josefu Vogelovi za účinnou metodickou, pedagogickou a odbornou pomoc. Dále bych chtěl poděkovat MUDr. Janu Wolfovi za možnost realizace tématu a cenné připomínky při zpracování mé bakalářské práce.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 21. května 2012..................... 7

České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Marek Hakala. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Marek Hakala. Tvorba formulářů z popisu v XML s použitím knihovny Qt4: Bakalářská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract The thesis addresses design and an implementation of a framework for simple data visualisation. Primary goal of framework is build a forms application. And secondary goal is a data minding of data store. This is all based on technologies XML and Qt4. Keywords C++, Qt, XML, GUI, MVC, Rapid Development, Forms application, Object-relational mapping Abstrakt Bakalářský projekt se zabývá návrhem a realizací frameworku, který bude sloužit k jednoduché vizualizaci dat. Primárním cílem frameworku bude stavba formulářových aplikací. Druhořadým cílem je prezentování datových skladů, se kterými bude možné pracovat. K realizaci jsou využity technologie XML a Qt4. Klíčová slova C++, Qt, XML, GUI, MVC, Rapid Development, Formulářové aplikace, Objektové relační mapování 9

Obsah Úvod 15 1 Specifikace cílů práce 17 1.1 Vymezení cílů bakalářské práce.................. 17 1.2 Motivace............................... 18 1.3 Požadavky na produkt....................... 18 1.4 Hlavní části knihovny....................... 18 1.5 Základní pojmy a zkratky..................... 19 1.6 Ostatní podobná řešení...................... 24 2 Návrh řešení 27 2.1 Formulář.............................. 27 2.2 Metadata.............................. 28 2.3 SkinPlugin............................. 28 2.4 Hlavní části navrhovaného řešení................. 29 2.5 XML metadata........................... 29 2.6 Metadata parser.......................... 30 2.7 Metadatový strom......................... 31 2.8 SkinPlugin API........................... 35 2.9 Form Builder............................ 36 2.10 Form................................. 40 2.11 SubForm............................... 41 2.12 ILabelComponent.......................... 43 2.13 IInputComponent.......................... 43 2.14 DataModel............................. 44 2.15 Popis struktury........................... 45 2.16 Shrnutí navrhovaného řešení.................... 46 3 Implementace 47 3.1 XML Metadata........................... 47 11

3.2 Formulářová aplikace........................ 56 3.3 Formulářové pohledy........................ 58 3.4 Formulářové podkomponentní pohledy.............. 61 3.5 Práce s databází.......................... 65 4 Ladění a testování 67 4.1 Testování.............................. 67 4.2 Trasovací nástroje......................... 67 4.3 Unit testy.............................. 68 4.4 Memory leaks............................ 69 4.5 Ruční ověření funkčnosti...................... 69 5 Realizace knihovny 71 5.1 Návrhové prostředí......................... 71 5.2 Vývojové prostřední........................ 72 5.3 Skriptovací systém cmake..................... 72 5.4 Verzování zdrojového kódu..................... 73 5.5 Části distribučního balíku knihovny............... 73 5.6 Použití................................ 74 6 Příklady použití 75 6.1 Vytvořené demo příklady..................... 75 6.2 Metodika tvorby formulářových aplikací............. 76 6.3 Příklad 1 - Adresář osob...................... 78 6.4 Příklad 2 - Agenda místností s výpočetní technikou....... 81 Závěr 85 Literatura 87 A Obsah přiloženého CD 89 12

Seznam obrázků 2.1 Component diagram Hlavní komponenty knihovny........ 29 2.2 Hierarchický strom entit........................ 30 2.3 Class diagram Metadatový strom.................. 32 2.4 Class diagram SkinPlugin API................... 35 2.5 Class diagram FormBuilder..................... 36 2.6 Activity diagram Vytvoření formuláře z popisu v XML...... 39 2.7 Class diagram FormWidget struktura............... 41 2.8 Class diagram SubFormWidget struktura............. 42 2.9 Class diagram ILabelComponent.................. 43 2.10 Class diagram IInputComponent.................. 43 2.11 Class diagram DataModel struktura................ 45 3.1 Mřížkový pohled na XML strukturu metadat............ 48 3.2 XML struktura - TrunkEntity - DataModel............. 49 3.3 XML struktura - BranchEntity.................... 50 3.4 XML struktura BranchEntity DataModel............ 51 3.5 XML struktura BranchEntity Relation.............. 52 3.6 XML struktura BranchEntity Ui................. 52 3.7 Struktura LeafEntity Všechny entity u vzorových adres osob.. 53 3.8 XML struktura - LeafEntity Ui................... 54 3.9 XML struktura - LeafEntity Validation.............. 55 3.10 XML struktura - LeafEntity DataModel.............. 55 3.11 Deployment diagram Nasazení formulářové aplikace....... 57 3.12 Stromový pohled Adresář osob................... 59 3.13 Detailní pohled Adresář osob.................... 60 3.14 Formulářový podkomponent Seznamový pohled.......... 61 3.15 Formulářový podkomponent Detailní pohled........... 62 3.16 Grafická vstupní pole......................... 62 3.17 Vstupní pole - Nápověda........................ 64 3.18 Vyhodnocení kontroly vstupních polí................. 64 13

Seznam obrázků 3.19 BPD diagram - Transakční zpracování................ 65 3.20 BPD diagram - Zpracování v editačním pohledu.......... 66 4.1 QtCreator - GDB debugger...................... 68 5.1 Use case - Formulářová aplikace.................... 74 6.1 BPD diagram - Vytvoření formulářové aplikace........... 76 6.2 ERD diagram - Adresář osob..................... 78 6.3 ERD diagram - Agenda místností s výpočetní technikou...... 81 14

Úvod Práce pojednává o tvorbě nástroje pro programátory, který umožní navrhnout formulář pomocí zápisu v XML dokumentu. Formulář se skládá z několika komponentních prvků. Komponenty rozlišujeme jednoduché a složené. Mezi jednoduché prvky patří vstupní textová pole, výběrové seznamy, zaškrtávací pole, tlačítka a další. Složené prvky jsou složitější komponenty, které jsou tvořeny jednoduchými prvky a udávají konkrétní zobrazovací formu pro určitou oblast dat, například výpis osobních informací nebo informace o společnosti. Komponenty tvoří obecné vizuální rozhraní pro prezentování informací, ale neřeší, jak data získáme, zpracujeme a jak je budeme publikovat přes specifikované rozhraní formuláře. V práci budu vizuální část řešit pomocí jednoduchých komponentů dostupných v frameworku Qt4. Část práce bude spočívat v získávání dat. K těmto účelům ve světě programování se používá softwarová architektura MVC (Model-View- Control), kterou budu plně využívat. MVC rozděluje software na model, view a control. Model slouží k popisu dat a udává strukturu dat, která budeme prezentovat. View realizuje samotný pohled na data, v našem případě v kontextu formulářů se jedná o složené komponenty formuláře nebo celý formulář. Control zajišťuje interaktivitu formuláře, například změny, které provedeme, se uloží do datového skladu. Získávání dat bude popsáno pomocí XML dokumentu a poslouží jako popis formulářového okna. XML dokument bude sloužit jako šablona, kterou programátor vytvoří pro potřeby formuláře. Pro práci s XML bude využit nástroj Qt4. Klíčovou vlastností pro výběr Qt4 je multiplatformní podpora, která je zaručena na operačních systémech MS Windows a GNU/Linux. Samotná XML struktura popisuje pozici komponentů, datové zdroje a vazby. Pomocí těchto informací si program spojí souvislá data a bude je prezentovat. Při změně dat bude realizováno zpětné dekomponování a dojde k editování dat. Při každé editační operaci program zkontroluje integritu dat. 15

Kapitola 1 Specifikace cílů práce 1.1 Vymezení cílů bakalářské práce Hlavním cílem této práce je implementace knihovny, která bude schopna pomocí xml dokumentu sestavit plnohodnotnou formulářovou aplikaci. Od této aplikace očekávám, že bude pracovat s databází, která bude obsahovat relačně svázaná data a ta budou prezentována prostřednictvím formuláře. Primárním bodem je realizovat FormsBuilder knihovnu, použitelnou k tvorbě formulářové aplikace s pomocí frameworku Qt4 (1). Knihovna vytvoří formulářovou aplikaci včetně relačního propojení dat s databázovým zdrojem. Nastavení formuláře bude realizováno pomocí XML souboru. Sekundárním bodem bude vývoj datově orientovaných komponentů pro zobrazení složitějších datových kolekcí. Práce bude plně využívat návrhový koncept Model/View, který je standardně dostupný v Qt4 (8). Tento návrhový vzor vychází z velmi známého návrhového vzoru MVC (Model- View-Controller). Umožňuje velmi efektivně oddělit data a zobrazovací komponenty. Nespornou výhodou je možnost automatizovaného testování nad datovým modelem. Posledním bodem je použití knihovny na demonstračních příkladech. 17

1. Specifikace cílů práce 1.2 Motivace Důvodů pro výběr tohoto tématu bylo hned několik. Téma mě zaujalo, protože na běžné účetní formulářové aplikaci vidím zcela nepoužitelné, složité a těžce upravitelné uživatelské rozhraní. Projekt realizuji pro firmu Wolf and Danniel s.r.o., kde se v rámci čtyřčlenného týmového projektu snažíme vytvořit vlastní framework. Tento framework je zaměřený na řešení informačních systémů pro střední podniky a firmy. Bakalářský projekt se zabývá ve zkráceném rozsahu vizuální prezentací dat ve vyvíjeném frameworku. 1.3 Požadavky na produkt Validace XML metadata dokumentu. Vytvoření formuláře v Qt4 dle popisu v XML dokumentu. Možnost úpravy vzhledu a funkčnosti pomocí SkinPlugin knihovny. Propojení formuláře s relační databází PostgreSQL dle xml metadat. Poskytnutí formuláře pro práci s daty uloženými v databázi. 1.4 Hlavní části knihovny Metadata parser založený na DOM parseru vestavěném v Qt4. XML Schema definiční soubor pro validaci metadat v XML dokumentu. Sada obecných formulářových komponentů (View) a datových modelů (Model). SkinPlugin založený na Qt Plugins. FormsBuilder stavějící formuláře. 18

1.5. Základní pojmy a zkratky 1.5 Základní pojmy a zkratky V této podkapitole jsou popsány základní pojmy a zkratky, které budou používány v rámci celé práce. 1.5.1 Jazyk C++ Jedná se o objektově orientovaný programovací jazyk. Tento jazyk byl vytvořen v Bellových laboratořích AT&T přepracováním stávajícího jazyka C. Autorem jazyka je Bjarne Stroustrup a kolektiv. Klíčovou vlastností jazyka je, že podporuje více programovacích stylů, a to procedurální programování, objektově orientované programování a generické programování. Nejedná se tedy o čistě objektový jazyk. V současnosti patří k nerozšířenějším programovacím jazykům. 1.5.2 UML Unified Modeling Language je jazyk určený k modelování jednoduchých i složitějších softwarových systémů pomocí diagramů. Diagramy podléhají notaci, která nabízí pestrou sémantiku a syntax usnadňující návrh a vizualizaci softwaru. Díky sjednoceným formám zápisu jsou diagramy čitelné pro všechny, kteří notaci znají. 1.5.3 Framework Ve světě programování je za framework považován nástroj, který nabízí obecně vyřešené programovací úlohy v softwarové kolekci knihoven. Hotová řešení jsou nabízena prostřednictvím definovaného rozhraní, které je označováno zkratkou API (7). 1.5.4 Qt4 Framework Qt4 je multiplatformní framework pro vývoj aplikací s grafickým uživatelským rozhraním. Qt knihovna je určena pro vývoj v programovacím jazyce C++ (10), ale nalezneme i různé neoficiální pokusy o podporu ostatních programovacích jazyků. Výhodou tohoto nástroje je, že programátorovi nabízí kompletní zázemí pro práci s uživatelským rozhraním, databázemi, zvukem, animacemi, datovými zdroji a dalšími technologiemi. V kombinaci s C++ je nad Qt možné vytvářet aplikace, které jsou multiplatformní, grafické a zároveň mohou využívat výhody C++. 19

1. Specifikace cílů práce 1.5.5 Qt Plugins Framework Qt nabízí jednoduché rozšíření aplikací prostřednictvím Qt Plugins frameworku. Umožňuje pomocí maker a loaderu velmi jednoduché načítání rozšíření, která jsou uložených ve formě systémové knihovny. Použití pluginu je realizováno prostřednictvím veřejného rozhraní, které zná aplikace i samotný plugin. 1.5.6 DLL knihovna Jde o dynamicky linkovanou sdílenou knihovnu určenou pro operační systémy Microsoft Windows. Tento soubor obsahuje spustitelný kód v binární formě. Kód je možné používat prostřednictvím veřejného rozhraní. 1.5.7 SO knihovna SO knihovna je obdobou dynamicky linkované knihovny DLL. Je zaměřena na unixové operační systémy. SO knihovna obsahuje binární kód ve spustitelné formě, obdobně jako DLL knihovna. Opět je zapotřebí znát veřejné rozhraní pro využívání funkcí knihovny. 1.5.8 XML Jedná se o značkovací jazyk zvaný XML, který používá formát zápisu čitelný pro lidi i pro strojové zpracování ve strukturované textové formě. Umožňuje jednoduchou rozšířitelnost strukturovaných dat. Používá se pro potřeby webových služeb, konfiguraci programů a pro další účely. V mé práci je XML jazyk využíván jako konfigurační soubor formuláře. Nespornou výhodou je, že XML je standardizováno konsorciem W3C. 1.5.9 BPD Diagram Business process diagram slouží k mapování procesů, které si přejeme zachytit. Tyto diagramy mají neomezené použití. Protože jsem potřeboval v práci znázornit několik procesů, které obsahovaly sofistikovanější rozhodování, použil jsem BPD diagram pro lepší názornost. 1.5.10 ERD Diagram V softwarovém inženýrství se Entity Relation Diagram rozumí diagram popisující relační model databázového skladu. ERD se rozděluje na typy : logický, konceptuální a fyzický. Všechny typy diagramu udávají databázový model, kde jsou prezentovány vztahy mezi entitami. Jednotlivé typy se liší v přiblížení ke konkrétní implementaci databáze. Práce je používá k vizualizaci databázových modelů, které jsou použity v ukázkových příkladech. 20

1.5. Základní pojmy a zkratky 1.5.11 Regulární výraz Regulárním výrazem rozumíme šablonový řetězec, který zahrnuje množinu textových řetězců. Množinu textových řetězců chápeme jako regulární jazyk. Podle tohoto šablonového řetězce jsme schopni určit, zda nějaký výraz patří do definovaného regulárního jazyka. Může sloužit k nahrazování šablonových řetězců i ke kontrole shody dvou výrazů. 1.5.12 Návrhové vzory Návrhový vzor je doporučení, které poskytuje řešení opakujících se problémů při návrhu softwaru. Nejedná se o knihovnu, ani o konkrétní zdrojový kód. Jde především o popis či šablonu, jak řešit různé situace. Objektové návrhové vzory udávají vztahy a chování mezi objekty, aniž by realizovaly implementaci třídního kódu. Algoritmy nepatří mezi návrhové vzory, protože neřeší návrh, ale početní problematiku. 1.5.13 DML a DDL Následující zkratky DML a DDL reprezentují množiny různých SQL příkazů. Data manipulation language (DML) jsou příkazy určené k manipulaci s daty. Data definition language (DDL) příkazy slouží k definování struktury databáze (nejčastěji pro definování tabulek). 1.5.14 Metadata Metadata v našem pojetí jsou strukturované informace o datech. Tyto informace nám podrobně vysvětlují, lokalizují a popisují použití a správu konkrétního datového zdroje. Tyto informace používáme k získávání dat z databáze a také k sestavení zobrazovacího formuláře. 1.5.15 Metadata a použití XML Nějakou dobou jsem váhal nad tím, jakým způsobem nejlépe metadata zapisovat. Nejdříve jsem se rozhodl vytvořit vlastní strukturu. Později jsem od toho rozhodnutí upustil a přešel k XML. Hlavním důvodem pro volbu XML byla čitelnost zápisu pro lidi a možnost strojového zpracování. 1.5.16 DOM Document Object Model je technologie pro zpracování XML souborů, kdy se dokumenty prezentují objektovou datovou strukturou. Můžeme přistupovat k libovolným uzlům nezávisle na aktuálním stavu čtecího procesu. Máme přístupný celý xml dokument v objektové prezentaci. Značnou nevýhodou jsou paměťové nároky na skladování dokumentu. 21

1. Specifikace cílů práce 1.5.17 XML Schema XML Schema je jazyk určený k validaci XML, explicitně nastavuje, jaké elementy mohou být uvnitř struktury elementů. Existují i alternativní technologie pro validaci např. DTD, Relax NG, Schematron a další. 1.5.18 MVC Model View Controller je konzistence tří objektů. Model je aplikačním objektem, View je zobrazovacím komponentem a Controller vyhodnocuje uživatelské podněty. Před definováním MVC bylo uživatelské rozhraní navrhováno jako jeden celek. MVC zavádí znovupoužitelnost jednotlivých objektů a možnost využití automatizovaného testování bez nutnosti GUI. 1.5.19 Model/View Architektura Model-View-Controller (MVC) je návrhový vzor určený pro použití v jazyce Smalltalk, kde je hlavně využíván k tvorbě uživatelského rozhraní. Pokud spojíme View a Controller objekt do jednoho celku, výsledkem bude právě Model/View architektura. Prezentovaná data máme v Model/View separována dle toho, jak je prezentujeme uživateli. Ve výsledku se jedná o jednodušší formu MVC při zachování stejného principu. 1.5.20 SQL Structured Query Language je programovací jazyk navržený pro manipulaci s daty relačních systémů správy báze. Je založen na základech relační algebry a relačního kalkulu, který zahrnuje datové vkládání, dotazování, upravování, mazání, vytváření a modifikování schémat databáze a také slouží ke správě databáze. 1.5.21 Relační databáze Relační databáze je databáze založená na relačním modelu. Nejčastěji se toto označení používá v oblasti softwarového inženýrství. Princip relačních databází je založen na systému tabulek, které obsahují záznamy, které jsou prezentovány jednotlivými řádky a případně některé sloupce plní význam takzvaného cizího klíče. Tyto cizí klíče si vykládáme jako informace o relacích mezi jednotlivými záznamy napříč tabulkami. 1.5.22 Datový model Pojem datový model ve světě softwarového inženýrství popisuje abstraktní model, který zavádí pravidla pro rozmístění a vztah entit v datově orientované aplikaci. 22

1.5. Základní pojmy a zkratky 1.5.23 Vztahy mezi entitami Vztahy rozdělujeme podle směru a množství entit na každé straně vztahu. Entity se rozdělují podle vazby na jednosměrné a obousměrné. Dělení podle množství entit se typicky realizuje v následujících relacích 1:1, 1:N a N:M. 1.5.24 Jednosměrné vazby Název napovídá, že se jedná o vztah ve směru od jedné entity k druhé, a to jednom směru, nikoliv v opačném směru. Můžeme si ho představit jako vztah osoby a telefonního čísla. Osoba se odkazuje na telefonní číslo, ale v obráceném směru vztah neexistuje. 1.5.25 Obousměrné vazby U obousměrných vazeb se jedná o použití jednosměrných vazeb z obou stran dvou vázaných entit. Představme si entitu firmy, která obsahuje odkaz na adresu. V entitě adresy existuje odkaz na firmu. Ve výsledku se můžeme dostat z libovolné entity v rámci vztahu na druhou entitu a také obráceně. 1.5.26 CRUD operace Zkratka CRUD je často používaná při práci s databázemi, kde provádíme práci s daty - vytváření, čtení, editování a mazání. 1.5.27 PostgreSQL PostgreSQL, zkráceně někdy také Postgres, je objektově-relační databázový systém. Tento databázový systém patří mezi tzv. svobodný software, kde celý software je vyvíjen v rámci komunity nadšenců, případně se do vývoje zapojují větší společnosti. Výsledné dílo je dostupné všem zájemcům. 23

1. Specifikace cílů práce 1.6 Ostatní podobná řešení 1.6.1 Koncept moderních formulářových aplikací Moderním trendem na poli formulářových aplikací je poskytnout programátorům flexibilní a jednoduché řešení návrhu uživatelského formuláře a jeho propojení s daty. Dnes existuje několik produktů, které řeší problematiku návrhu UI, logiky a propojení s databázovým kontextem různými cestami. Hlavní myšlenka všech těchto softwarových nástrojů je vždy téměř stejná. Snahou je nabídnout vývojáři rozhraní, které nabízí sofistikované nástroje pro rapid development. Typicky nabízí vizuální návrh vzhledu s rozmístěním formulářových komponentů a propojování jednotlivých prvků formuláře s datovým kontextem. U datového kontextu jsou samozřejmostí obousměrné datové vazby a především synchronizované zamykání/odemykání dat. 1.6.2 Dostupná řešení Rozsáhlá řešení nabízí společnosti Oracle, IBM, Microsoft a další. Vývojové platformy jsou cílené na společnosti, které provádí implementace převážně velkých informačních systémů. Vybral jsem následující platformy : Oracle Forms, IBM Lotus Forms a Microsoft LightSwitch. Tyto produkty si kladou jako prvořadý cíl zkrácení procesu vývoje a hlavně omezení programování na minimum. Druhořadou prioritou je možná vizuální úprava pohledů a výběru dat dle požadovaných kriterií. 1.6.3 Oracle Forms Oracle Forms je nástroj sloužící k jednoduché tvorbě formulářových aplikací UI, které pracují s databázovými sklady Oracle. Tento nástroj je distribuován v rámci produktu Oracle Developer Suite. Formulář vytvořený v Oracle Forms je UI. Data se zobrazí, editují a propojují s databází. Tato strategická funkčnost minimalizuje programování složitých operací (databázové dotazování, synchronizaci dat se zamykáním/odemykáním a realizace relací mezi daty). K rozšíření funkčnosti slouží programovací jazyk PL/SQL. K vytváření formuláře se používá nástroj zvaný Forms Builder. Cílovým produktem je zdrojový kód ve formě fmb souboru. Po zkompilování je vytvořen soubor fmx, který je spustitelný v rámci prostředí Forms Runtime. Od verze 9i je dokonce možné aplikace nasadit jako webové služby. 24

1.6. Ostatní podobná řešení 1.6.4 IBM Lotus Forms Produkt Lotus Forms nabízí řešení elektronických formulářových aplikací. Hlavní náplní IBM Lotus Forms je realizovat převod klasických formulářů do elektronické formy a jejich následný převod do databázového skladu. Produkt nabízí obousměrnou vazbu, ale primárně se snaží odbourat ve firmách papírové a statické elektronické formuláře. Zajišťuje lepší kolaboraci dat, v neposlední řadě umožňuje Workflow v dokumentech a formulářích. Jedná se o modul řešení zvaného IBM Lotus Notes, které je možné provozovat i samostatně. Řešení je určeno pro velké firemní informační systémy. Formulář vytvořený pomocí IBM Lotus Forms je UI, které se podobá webovému rozhraní. Je dokonce možné formuláře stylovat stejně jako webové stránky. Pro netechnické uživatele je zde možnost převodu pdf dokumentu do Forms podoby. Převod je proveden asistentem, který při špatném rozpoznání klade dotazy. Programování není kromě validací a speciálních filtrací téměř nutné. Nástroj sám zajistí svázání s daty. Je zde možné použít interní databáze, kterou Lotus Notes (NotesSQL) nabízí nebo využít databázového stroje IBM DB2. Aplikační a validační logiku může programátor psát hned v několika jazycích - Formula Script, Javascript, Java a další. Cílovým produktem je aplikace pro prostředí IBM Lotus Notes, kterou je možné provozovat v prostředí IBM Lotus Notes nebo ve webové verzi. 1.6.5 Microsoft LightSwitch Microsoft LightSwitch je vývojářský nástroj určený k velmi rychlé tvorbě databázových aplikací formou vizuálního návrhu s minimem programování. Je určen zejména k tvorbě efektivních databázových aplikací. Ty je možné provozovat v rámci firmy, veřejně na hostingu a nebo v rámci Microsoft Azure cloud řešení. Vývojářský nástroj je dodáván jako modul Microsoft Visual Studia. Významnou vlastností je možnost doprogramovávání funkcí v jazyce C# s použitím.net frameworku. Celý framework je postavený na technologiích C# /.NET frameworku a především frameworcích Windows Presentation Foundation a Windows Communication Foundation. Formulář se vytváří ve Visual Studiu, ve kterém je možné data zobrazovat, editovat a navázat na data pomocí data kontextu. To vše díky.net Frameworku. Návrhář nabízí stejnou paletu komponentů jako pro Windows Presentation Foundation. Výstupem je plnohodnotná desktopová aplikace. 25

Kapitola 2 Návrh řešení Tato kapitola se zabývá návrhem architektury řešení pomocí UML (5), které bude pokrývat základní potřeby pro sestavení formuláře. Dále řeší možnosti formulářů a propojení s databázovými kontexty. Návrh je realizován s použitím návrhových vzorů (6). 2.1 Formulář Úkolem bylo navrhnout systém pro tvorbu formulářů z popisu v XML. Celý problém jsem řešil následujícím způsobem. Máme nějakou hlavní datovou strukturu, v našem případě databázovou tabulku. Tato tabulka obsahuje záznamy, které si přejeme prezentovat ve formuláři. Konkrétně si můžeme pod tabulkou představit například seznam osob. Námi určená tabulka může obsahovat vztažená data k jiné databázové tabulce (kolekci vztažených záznamů). Danou vztaženou tabulku si znovu můžeme představit konkrétněji, tentokrát jako adresy, které se vztahují ke každé osobě. Cílem navrhovaného řešení je pro náš příklad prezentovat osoby, které bude možné přidávat, odstraňovat, editovat a prohlížet jednotlivě. Při zobrazení údajů o osobě budeme mít možnost stejných operací i nad vztaženými daty. Prohlížení bude možné v dvou základních režimech, a to v detailním a seznamovém. U detailního pohledu budeme pracovat např. s jedinou osobou, kdežto v seznamovém režimu budeme mít stromový výpis všech osob. Jednotlivé pohledy budou dostupné nad hlavní tabulkou a také nad relačně vztaženou tabulkou. V detailním pohledu budeme rozlišovat editační a prohlížecí režim. Při použití editačního režimu budou data po potvrzení změny zapsána přímo do databáze. Pro databázové operace budou použity definované CRUD operace v metadatech. Načítání a modifikování provádí datový model, který je realizován podle návrhového vzoru Model/View (2). Pro detailní návrh je každá část rozebrána do detailů v podkapitolách. 27

2. Návrh řešení 2.2 Metadata Metadatový popis formuláře se bude načítat z XML dokumentu. Pravidla pro zápis dokumentu realizujeme pomocí XML Schema dokumentu, který pevně určí povinné a volitelné informace. Před samotným čtením je nezbytné realizovat validaci dokumentu pomocí XML Schema dokumentu. XML dokument je zapotřebí přečíst a podle pravidel sestavit příslušný metadatový strom. Tímto práce s metadaty na úrovni XML končí. XML dokument slouží pouze jako konfigurační soubor. 2.3 SkinPlugin Knihovna bude obsahovat SkinPlugin rozhraní pro rozšíření a upravování formulářových komponentů. SkinPlugin rozhraní je postaveno na Qt Plugins rozhraní, které poskytuje komfortní práci s pluginy oproti definovanému a- plikačnímu rozhraní. Bude možné rozšířit funkčnost, ale také změnit vzhled zobrazovacích komponentů. Programátor bude rozhodovat přímo v xml, zda použije nově přidané formulářové komponenty nebo použije vestavěné. 28

2.4. Hlavní části navrhovaného řešení Obrázek 2.1: Component diagram Hlavní komponenty knihovny 2.4 Hlavní části navrhovaného řešení Produktem řešení je binární knihovna, která poskytne výše popsané vlastnosti. Knihovna se bude skládat z následujících komponentů : Metadata parser, Metadatový strom, SkinLoader, FormBuilder, Form, SubForm a DataModel. Celá implementace bude realizována nad technologickým zázemím C++ a Qt4 frameworkem. 2.5 XML metadata Entity (entitní elementy) budou v rámci xml dokumentu rozděleny na typy. Výhody, které plynou z tohoto rozdělení nám slouží k rozlišování popisovaných dat při vizualizaci ve formuláři. TrunkEntity entita slouží k formování formuláře. Udává, nad kterými daty budeme provádět vizuální pohled. V našem případě se budeme zabývat jednoduchým adresářem osob, který poslouží jako ukázkový datový zdroj. TrunkEntity entita v naší ukázce reprezentuje celý formulář, který pracuje se seznamem osob. V BranchEntity entitě budou obsaženy jednotlivé informace, které jsou vztaženy k dané osobě např. adresy, telefony a emailové kontakty. Nyní nám zbývají poslední, nejvíce zajímavé LeafEntity entity, které budou popisovat konkrétní informace např. v rámci adres, kde bude uvedeno, jaké údaje si přejeme o adrese zobrazovat, např. město, ulice, psč a další. 29

2. Návrh řešení Obrázek 2.2: Hierarchický strom entit TrunkEntity Hlavní datový zdroj, který budeme vizualizovat. Popisuje formulář. BranchEntity Svázaný datový zdroj, který je ve vztahu s hlavním datovým zdrojem. LeafEntity Konkrétní data, která jsou vybrána v rámci svázaného zdroje. 2.5.1 Použití XML pro popis Metadat formuláře Obecně můžeme XML metadata nazvat hierarchickým stromem formuláře. Jedná se o obecný popis pro propojení dat a vizuální rozložení formuláře. 2.6 Metadata parser Metadata parser se stará o jednosměrný převod XML dokumentu do objektového metadatového stromu. Čtení XML dokumentu je realizováno pomocí vnitřní implementace DOM parseru uvnitř Qt4. Při procesu čtení postupně parser prochází XML strukturu a reaguje na zapouzdřené informace, které převádí do objektových struktur. Pokud pro danou xml strukturu neexistuje speciální třída pro popis pomocí objektů, potom algoritmus použije generickou třídu, do které surová xml data naplní. Výhodou a účelem tohoto postupu je, že máme v rámci programu dostupná metadata v námi požadovaném formátu, ve kterém jsme schopni pracovat. Třídy implementují v rámci efektivity rozšířené funkce pro jednoduché získávání informací v entitách. 30

2.7. Metadatový strom 2.7 Metadatový strom Metadata v našem pojetí jsou strukturované informace o datech. Informace nám podrobně vysvětlují, lokalizují a popisují použití a správu konkrétního datového zdroje. V našem pojetí používáme tyto informace k získávání dat z databáze a také k sestavení zobrazovacího formuláře. Metadatový strom je definován pomocí návrhového vzoru Composite. Návrhový vzor composite nám umožňuje definovat rekurzivní stromové struktury, které jsou využívány v prezentaci metadat na úrovni běhu formulářové aplikace. 2.7.1 Návrhový vzor Composite Účelem návrhového vzoru Composite je pomocí komponentů a rozšířených kompozitních komponentů sestavit hierarchickou strukturu, která má vlastnosti n-árního stromu. Typickým použitím je přidávání, odebírání, zobrazení, hledání a přesouvání komponentů v rámci hierarchického uspořádání. Jedná se o rozšířenou implementaci tohoto vzoru, kdy rozlišujeme různé typy kompozitních komponentů podle zanoření v metadatech. 2.7.2 Metadata Entity Metadatovými entitami (dále jen entitami) rozumíme datové celky, které jsou schopny uchovávat popis kolekcí dat. Tyto entity popisují data nebo odkazují na jiné entity částečně nebo úplně. Entity definují datový zdroj, integritní omezení, datový filtr a umístění v rámci formulářové aplikace. Rozlišujeme základní tři typy, které jsou hierarchicky řazeny, a to TrunkEntity, BranchEntity a LeafEntity. Rozdělení na různé typy je zde zavedeno pro účely formuláře, kdy nám typ určuje možnost vizuální prezentace dat, a zda se jedná o jednoduchá nebo složená data. 31

2. Návrh řešení Obrázek 2.3: Class diagram Metadatový strom 2.7.3 Struktura Základem pro celou stromovou konstrukci jsou stavební prvky návrhového vzoru Composite, a to následující ComponentEntity a CompositeEntity. Každá metadatová entita obsahuje EntityInfo objekt. Tento objekt obsahuje rozšířené informace o entitě. Dále může, ale nemusí, obsahovat odkaz na informační objekty třídy PropertyInfo. Základní typy entit : ComponentEntity ComponentEntity je předkem všech entitních tříd a slouží jako obecné třídní rozhraní, které všechny entity přímo nebo nepřímo implementují. Tato entita nemůže a neobsahuje další entity, jedná se o listovou entitu stromu (nemůže mít potomky). CompositeEntity CompositeEntity entita dědí vlastnosti ComponentEntity a přidává kompozitní vlastnost, která nám umožňuje přidávat entitní potomky. 32

2.7. Metadatový strom PropertyInfo je třída, která dokáže uchovávat rozšiřující informace o entitách. V rámci návrhu byly vybrány 4 specializované typy. Typy PropertyInfo tříd : UiPropertyInfo Slouží k uchovávání vlastností o zobrazovacím komponentu. Může obsahovat následující položky : Typ zobrazovacího komponentu. Řádkovou a sloupcovou pozici. Indexovou pozici. Informaci, zda se jedná o řádkový nebo sloupcový výstup. DatamodelPropertyInfo Tato třída uchovává základní informace o datovém modelu. Obsahuje následující položky : Schéma databáze, se kterým budeme pracovat. Název databázové tabulky. Název sloupce, který slouží jako primární klíč. Pro účely LeafEntity může obsahovat název sloupce pro výběr dat. CRUDPropertyInfo Slouží ke skladování šablonových CRUD databázových dotazů, a to pro vytváření, čtení, upravování a mazání záznamů. RelationPropertyInfo Uchovává informace o dodržení násobnosti vztahů entit ve formuláři. 33

2. Návrh řešení A nyní se budeme zabývat rozšířením základních entit o vlastnosti, které nám přinesou rozlišení entit podle metadat na TrunkEntity, BranchEntity a LeafEntity. Rozdělení je důležité pro stavbu formuláře a navázání vztahu s databází. MetadataEntity Entita bude sloužit k skladování nejvyšších entit TrunkEntity. Celý metadatový strom nalezneme uvnitř této entity. Jedná se o přímého potomka CompositeEntity. TrunkEntity Tato entita bude popisovat jednotlivé formuláře, které jsou zapsány v xml. Obsahuje informace pro práci s daty pro hlavní formulářové záznamy. Třída BranchEntity je přímým potomkem CompositeEntity. BranchEntity Slouží k popisu formulářových podkomponentů podle popisu BranchEntity v xml. Obsahuje informace potřebné pro práci s relačně svázanými daty v formulářových podkomponentech. BranchEntity je přímým potomkem CompositeEntity. LeafEntity Entita je určena k specifikování konkrétních sloupcových dat a vstupních polí formuláře. LeafEntity je přímým potomkem ComponentEntity. 2.7.4 Shrnutí Metadatový strom je popisem v objektové formě. Strom obsahuje pravidla pro hierarchické uspořádání entit. Toto uspořádání slouží k lepšímu rozpoznávání vlastností zanoření. Objektový strom je pouhým přepisem našeho XML dokumentu do uspořádané struktury. Výhody, které uspořádání přináší, jsou důležité pro stavbu GUI (3) a propojení s databází. 34

2.8. SkinPlugin API Obrázek 2.4: Class diagram SkinPlugin API 2.8 SkinPlugin API Pro účely rozšíření základních vstupních komponentů knihovna obsahuje speciální SkinPlugin API. SkinPlugin využívá plugin rozhraní, které nabízí Qt framework. Celá myšlenka rozšířitelnosti je založena na možnosti přepsání vstupních GUI komponentů formuláře pomocí kódu, který bude dodán prostřednictvím externí dynamické knihovny. Přepsání je možné prostřednictvím dohodnutého rozhraní SkinPluginInterface. SkinPluginLoader objekt, který provede instanciování kódu externí knihovny, instanci bude obsluhovat prostřednictvím SkinPluginInterface rozhraní. Rozhraní nám poskytne tovární metody pro základní vstupní pole formuláře, továrny budou veřejně dostupné prostřednictvím SkinPluginFacade fasády. Možnosti SkinPluginFacade fasády využijeme ve FormBuilderu, který provede výběr továrny podle metadat při stavbě formuláře. 2.8.1 Návrhový vzor Facade Návrhový vzor Facade realizuje řešení, jak vytvořit jednoduchý vstup do uzavřeného systému. Výhodou tohoto vzoru je zjednodušení obecného rozhraní mezi systémy ve vytvářeném softwarovém díle. 2.8.2 Návrhový vzor Factory method Factory method vzor má za úkol definovat rozhraní pro vytváření nových instancí objektů. Umožňuje třídám odložit rozhodnutí, kterou konkrétní třídu instanciovat. Rozhodnutí nechává na aktuálním stavu nebo preferenci klientských tříd. 35

2. Návrh řešení Obrázek 2.5: Class diagram FormBuilder 2.9 Form Builder Úkolem Form Builderu je sestavení GUI z popisu v metadatovém stromu. Tento úkol zahrnuje geometrické rozmístění komponentů v rámci UI mřížky, výběr vstupních komponentů pro uživatelskou interakci a vytvoření celkového formuláře. K vytvoření samotného formuláře vede několik procesů, které jsou sekvenčně zřetězeny. Pro budoucí upravitelnost a znovupoužitelnost jsou tyto procesy dekomponovány na několik podprocesů, které jsou realizovány pomocí návrhového vzoru Builder. Konkrétně se jedná o procesy vytvoření formulářových komponentů a celého formuláře. 2.9.1 Návrhový vzor Builder Návrhový vzor Builder je založen na ředitelích a stavitelích. V implementaci tento vzor používá obecné rozhraní IBuilder, které slouží k nabízení služeb řediteli. Každá třída, která implementuje rozhraní stavitele, může být použita k stavbě pomocí ředitele. Ředitel prostřednictvím IBuilder rozhraní je schopen zadat požadovanou práci. Výsledkem práce stavitele je produkt. Ředitel má možnost k dokončení své práce využít více různých stavitelů a je tedy schopen výsledný produkt vytvořit z vícero produktů. Hlavní myšlenkou vzoru Builder je možnost dodání různých produktů prostřednictvím stejného rozhraní. 36

2.9. Form Builder 2.9.2 Použití návrhového vzoru ObjectPool Princip tohoto návrhového vzoru spočívá ve znovupoužitelnosti a omezení vzniku nových instancí daných tříd. Použití uvnitř FormBuilderu je jednoduché, máme zde několik typů grafických formulářových komponentů. V rámci jedné instance FormsPoolu omezíme počet instancí každého formuláře právě na jednu. Také provedeme načtení všech FormWidget komponentů podle metadat při vytvoření FormsPool fondu. 2.9.3 Komponenty Form Builderu Samotný formulář se skládá z více komponentů. Při abstraktním pohledu můžeme říci, že se jedná o následující komponenty FormsPool, FormWidget a SubFormWidget. FormsPool zastává roli kolekce FormWidget komponentů, které budou v aplikaci dostupné k použití. FormWidget je grafický komponent, k zobrazování ucelených formulářových informací. SubFormWidget patří mezi grafické komponenty, ze kterých je složen hlavní FormWidget komponent. Za vytvořením FormWidget komponentů stojí ředitel FormDirector. Tento ředitel zodpovídá za sestavení celého formuláře a používá k postavení FormWidget komponentů ředitele SubFormDirector a také stavitele IFormBuilder. Dále za stavbou SubFormWidget komponentů stojí SubFormDirector ředitel. Tento ředitel zařídí vytvoření zobrazovacích komponentů podformuláře. Výsledné Sub- FormWidget komponenty jsou FormDirector ředitelem vloženy do nadřízeného FormWidget komponentu. Na konci celého řetězce se nachází výstupní Form- Widget komponent, který může obsahovat 1 až n různých SubFormWidget komponentů. Takto vzniklý formulář je zařazen do FormsPool fondu. 37

2. Návrh řešení 2.9.4 Vytvoření formuláře z popisu v XML Proces vytvoření formuláře začíná u vstupního XML dokumentu. Tento dokument obsahuje zmiňovaná metadata. Metadata parser převede xml dokument na metadatový objektový strom. Pokud v metadatech bude definována knihovna pro rozšíření vzhledu a funkčnosti, bude v následujícím kroku knihovna zpracována pomocí SkinPlugin. SkinPlugin načte a připraví nově přidané formulářové komponenty a zpřístupní je prostřednictvím Factory method k použití. Výběr nových komponentů provádí programátor v xml dokumentu. Dalším krokem bude využití grafických komponentů k sestavení formuláře. Tuto úlohu bude realizovat Form builder, který začíná proces stavby čtením MetadataEntity. Postupně si vybírá jednotlivé TrunkEntity. Pro každou entitu TrunkEntity je vytvořen formulářový FormWidget komponent. U entity TrunkEntity přistoupíme ke kolekci BranchEntity, kterou budeme interpretovat pomocí SubFormWidget komponentů. Vytvořené SubFormWidget komponenty přidáváme do rodičovského FormWidget komponentu. U každé BranchEntity provádíme další zanoření ke kolekci LeafEntity, kde pro každou LeafEntity vytvoříme popisek a vstupní pole pro editaci a čtení dat. Příslušné komponenty vložíme do nadřízeného SubFormWidget komponentu. Výstupní FormWidget, který odpovídá jedné entitě TrunkEntity, v posledním kroku vložíme do FormsPool fondu. Zde celý proces stavby končí. Sestavený FormWidget komponent je k dispozici pro použití v aplikaci. 38

2.9. Form Builder Obrázek 2.6: Activity diagram Vytvoření formuláře z popisu v XML. 39

2. Návrh řešení 2.10 Form Hlavní formulář FormWidget komponent se skládá z několika různých komponentů, které vcelku realizují zobrazovací formulář. Za poskládáním celého díla stojí dříve zmíněný formulářový stavitel. FormWidget komponent obsahuje FormContextWidget komponent, ve kterém nalezneme komponenty SwitchButtonsWidget, RecordInfoWidget a SwitchableFormContextWidget. SwitchButtonsWidget v GUI reprezentuje panel s ovládacími tlačítky formuláře. Panelová tlačítka umožní uživateli následující operace - přidání, editování, mazání a přepínání záznamů. Informace o aktuálním čísle záznamu a celkovém počtu záznamů se uživatel dozví z komponentu RecordInfoWidget. Přepínatelný obsah, který nabízí seznamový pohled nebo detailní pohled nad jedním záznamem, se nachází v komponentu SwitchableFormContextWidget. Obsah je možné měnit pomocí komponentů ListViewContextWidget a Grid- ViewContextWidget. Každý z těchto komponentů potřebuje datový zdroj, proto jsou oba komponenty vybaveny rozhraním pro nastavení datového modelu. Nastavení datového modelu je umožněno prostřednictvím rozhraní třídy FormWidget. První pohledový komponent ListViewContextWidget poskytne stromový pohled nad data, se kterými uživatel pracuje. Jedná se ve skutečnosti o seznam záznamů, který je možné na jednotlivých záznamech rozbalit a dosáhnout tak stromového pohledu nad relačně vztaženými daty. U druhého detailního pohledu v GridViewContextWidget komponentu se předpokládá, že uživatel preferuje pouze pohled nad jedním záznamem. U každého záznamu se budou zobrazovat relačně získaná data, která bude možné prohlížet pomocí SubFormWidget komponentu. Tyto SubFormWidget komponenty budou umístěny uvnitř grafické mřížky GridLayout, kde geometrické rozmístění bude pevně dáno pomocí metadat. Grafická mřížka GridLayout používá systém řádků a sloupců, kde není nutně vyžadováno, aby každý řádek měl stejný počet sloupců. Rozmístění realizuje autor formuláře libovolně pomocí metadat. 40

2.11. SubForm Obrázek 2.7: Class diagram FormWidget struktura 2.11 SubForm Komponenty typu SubFormWidget poslouží k zobrazení dat, která jsou získána pomocí relace nebo dat aktuálního záznamu. Velmi podstatnou informací je, že tento grafický komponent se používá pouze v detailním pohledu. Komponent vnitřně používá obecné rozhraní BaseFormComponent pro hlavní GUI komponent, protože je zapotřebí používat různé zobrazovací komponenty. Ve vestavěné výbavě jsou obsaženy TopicFormWidget a GroupFormWidget komponenty. Oba komponenty poskytují prostřednictvím rozhraní možnost připojení datového zdroje pomocí modelu. Rozhraní samotné Sub- FormWidget disponuje metodou pro nastavení datového modelu. Systém použije TopicFormWidget pro potřeby nadpisových zobrazení, kde nastává relace 1:1. Komponent bude schopen zobrazovat pouze záznamy v relaci 1:1. K práci s daty v relačním vztahu 1:N je přímo určen komponent GroupFormWidget, který nabízí stejně jako nadřazený komponent dva typy pohledů nad daty. GroupFormWidget a GridViewContextWidget obsahují informační komponenty RecordInfoWidget a specializovaný panel tlačítek SwitchButtonsGroupFormWidget. Panel tlačítek obsahuje základní ovládací prvky formuláře tj. přidávání, editování, mazání, posouvání a přepínání záznamů. Architektura je takřka úplně stejná jako u FormWidget komponentu. Máme uvnitř SwitchableContextWidget komponent, který umožňuje přepínání kontextových komponentů dle potřeby uživatele. 41

2. Návrh řešení Obrázek 2.8: Class diagram SubFormWidget struktura Je zde možnost přepínání mezi komponenty DetailViewContextWidget a List- ViewContextWidget, kde první komponent nabízí detailní pohled na jeden jediný podzáznam v rámci relace. Druhý komponent poskytuje seznamový pohled nad záznamy. Detailní pohled je rozlišen na editační a prohlížecí. V detailním pohledu bude popis dat zobrazen pomocí komponentního rozhraní ILabelComponent a konkrétní data prostřednictvím rozhraní IInput- Component. 42

2.12. ILabelComponent Obrázek 2.9: Class diagram ILabelComponent Obrázek 2.10: Class diagram IInputComponent 2.12 ILabelComponent ILabelComponent zde zastává roli uživatelského popisového komponentu. Toto komponentní rozhraní je využíváno v SubFormWidget komponentech pro návrhový popis dat v detailním pohledu. Knihovna musí být schopna postavit alespoň základní GUI, proto zde realizujeme jednoduchý komponent LabelComponent. Tento komponent umí zobrazit pouze popis. Podformulářový komponent je spojen s komponentem definovaným pomocí komponentního rozhraní IInputComponent. 2.13 IInputComponent Následující komponenty, které implementují komponentní rozhraní, zajišťují interakci mezi datovým modelem a samotným uživatelem. V navrhovaném řešení je základní sada nejdůležitějších vstupních komponentů, které bude mít programátor k dispozici prostřednictvím komponentního rozhraní IInputComponent. Jedná se o vstupní komponenty LineEditComponent, TextEditComponent, SpinBoxComponent, CheckBoxComponent a ComboBoxComponent. Každý komponent bude schopen provádět jednoduché validace dat pomocí specifikovaného regulárního výrazu v metadatech. 43

2. Návrh řešení 2.14 DataModel Stavbu samotného formuláře jsme si podrobně popsali, ale chybí nám stále mezičlánek pro práci s databází. Chybějícím mezičlánkem je datový model (Model), který zajišťuje mezivrstvu mezi zobrazovací (View) částí a samotnými daty. Datový model je realizován podle dříve zmíněného návrhového vzoru Model/View, který je doporučován vývojáři Qt. Je zde rozdíl v tom, že náš datový model obsahuje více modelů v porovnání s Model/View vzorem. Hlavní model (modelový strom) obsahuje hierarchii položek, které jsou strukturovány pomocí metadat. Tyto položky na jednotlivých úrovních obsahují datové modely, které jsou určeny pro použití v grafických komponentech postavených pomocí formulářového stavitele. GUI formulář je uzpůsoben pro nastavení jednoho hlavního modelového stromu. Následně po nastavení datových modelů jsou data načítána z databáze. Načtení se realizuje pomocí SQL dotazů v CRUD definicích, které jsou součástí metadat. Celá databázová komunikace probíhá formou SQL dotazů, které programátor nadefinuje v CRUD sekci prostřednictvím metadat. FormWidget komponent vytváří datový model po vyžádání dat. Hlavním úkolem modelu je práce s daty a jejich dočasné skladování ve vnitřních strukturách. Navrhované řešení vždy pracuje s hierarchicky definovaným datovým obsahem a tato vlastnost se promítne i do samotného datového modelu. Model obsahuje podle definice metadat stejnou entitní hierarchickou strukturu. Jednotlivé ModelItem položky jsou vytvořeny podle entit TrunkEntity, BranchEntity a LeafEntity. Novinkou je, že pro TrunkEntity a LeafEntity zavádíme speciální položku RowTrunkModelItem a LeafModel- Item, která prezentuje řádkové položky. Položky odpovídají jednomu záznamu, tedy jednomu řádku v seznamovém výstupu. 44

2.15. Popis struktury Obrázek 2.11: Class diagram DataModel struktura 2.15 Popis struktury Hlavní modelový strom začíná TrunkModelItem položkou. Tato položka prezentuje kolekci RowTrunkModelItem položek. Kolekce slouží k uchovávání dočasných dat získaných z databáze. Záznamy, se kterými na této úrovni pracujeme, jsou hlavním předmětem našeho formuláře. Například v zmiňovaném adresáři osob budou pod těmito záznamy jednotlivé osoby adresáře. TrunkModel- Item dále obsahuje odkaz na model TrunkItemModel, který je uzpůsoben ke stromovému pohledu nad hlavními daty. Při nastavení hlavního stromového modelu formuláře, je TrunkItemModel propagován do FormWidget komponentu. Zde je nastaven model jako datový kontext pro hlavní formulářový komponent (View). Obdobně je navržen BranchItemModel model pro jednotlivé podformuláře (View), který nalezneme v položce BranchModelItem. Důvodem pro existenci tohoto modelu je, že si přejeme v SubFormWidget komponentech prohlížet data, která jsou získána pomocí relace a jsou ve vztahu 1:N. Nastavení modelu BranchItemModel nastává v případě, že je vybrán jeden konkrétní RowTrunkModelItem záznam. V okamžiku výběru jsou na všech SubForm- Widget komponentech modely vyměněny podle aktuálně prohlíženého hlavního záznamu. BranchItemModel poskytuje seznamový model, kde nahlížíme na kolekci RowLeafModelItem položek, se kterými pracujeme. Konkrétní data nalezneme uvnitř položek LeafModelItem. Na datové položky LeafModelItem odkazuje samotná RowLeafModelItem položka a LeafModelItem položky jsou indexovány podle jednotlivých sloupců. Pro jednodušší práci s položkami bylo navrženo rozhraní pojmenované BaseModelItem, které sjednocuje práci s položkami. Všechny položky implementují přímo nebo nepřímo zmíněné rozhraní BaseModelItem. 45

2. Návrh řešení 2.16 Shrnutí navrhovaného řešení Navrhované řešení poskytuje základní funkční prvky pro potřeby formulářových aplikací. Řešení je schopné přečíst předložený xml soubor, ověřit jeho validitu, načíst metadata, připojit SkinPlugin, sestavit formulář a v poslední řadě realizovat propojení s databází. V každé z oblastí je určitě prostor pro vylepšení a rozšíření, ale přesto si myslím, že aktuální návrh je v popisovaném rozsahu využitelný v praxi. 46

Kapitola 3 Implementace Následující kapitola popisuje metodiku a techniku, která byla použita při realizaci práce. Budu se zabývat více technickým řešením. 3.1 XML Metadata 3.1.1 Struktura XML dokumentu Prvním elementem ve struktuře je element Metadata. U tohoto elementu nalezneme veškeré potřebné informace o datové struktuře. Mimo tento element se žádné informace nenacházejí. Uvnitř elementu Metadata můžou být umístěny entity, které jsme pojmenovaly TrunkEntity entity. Na nejvyšší úrovni se tedy nacházejí entity, které definují formuláře. Zde může být jedna až neomezené množství entit. Vše záleží na preferenci a potřebách programátora, který bude formulář implementovat. 3.1.2 Validace vstupních souborů pomocí XML Schema Před samotným sestavením formuláře je zcela nezbytné, abychom provedli kontrolu správnosti vytvořeného xml metadatového souboru. Validace je v této práci realizována pomocí technologie XML Schema. Pro XML Schema (11) validaci v prostředí Qt frameworku existují třídy QXmlSchema a QXmlSchema- Validator. Třídy poskytují jednoduchá rozhraní pro načtení schématického souboru a provedení procesu validace u vybraného xml souboru. V případě nedodržení struktury, třída QxmlSchemaValidator obsahuje message handler, který poskytuje seznam chyb při validaci. Tento seznam neboli záznamový log bude aplikace vypisovat ve speciálním okně. V případě, kdy bude nalezena chyba struktury, bude proces sestavení formuláře ukončen. 47

3. Implementace Obrázek 3.1: Mřížkový pohled na XML strukturu metadat 3.1.3 Struktura TrunkEntity TrunkEntity element slouží k vytvoření struktury formuláře. Jedná se o nejvyšší možný druh elementu formuláře. Účelem elementu je uchovávání informací o formuláři a důležitých informací v zapouzdřených elementech. Title Popisový název formuláře. Může obsahovat text s mezerami. Name Pracovní název entity, pod kterým bude v kolekcích entit k vyhledání. Může obsahovat pouze číslice, malá a velká písmena. Nesmí obsahovat mezery. DataModel Uchovává informace o uložení dat v databázi. BranchEntity kolekce Kolekce BranchEntity, která patří pod TrunkEntity. 48

3.1. XML Metadata Obrázek 3.2: XML struktura - TrunkEntity - DataModel 3.1.4 TrunkEntity - DataModel DataModel element je informační strukturou o umístění dat v databázi. Specifikuje šablonové dotazy pro výběr, vytvoření, upravování a mazání. V elementu CRUD operaci je zcela nezbytné, abychom definovali vždy všechny čtyři typy operací. Dotazovací řetězce obsahující proměnné, u kterých název začíná znakem zavináče. Tyto proměnné jsou před vykonáním dotazu doplněny aktuálními hodnotami. Database Název databáze, se kterou bude definovaný formulář pracovat. Schema Název databázového schématu, ve kterém se nachází používaná databázová tabulka. Table Název tabulky v databázi. Columns Textový řetězec se seznamem všech sloupců, které si přejeme načítat a zobrazovat v záznamovém řádku. PrimaryKey Primární klíč slouží k manipulaci a vybírání dat. Zde se jedná o textový název sloupce pro primární klíč v databázové tabulce. CRUD Tento element je jedním z nejdůležitějších, definuje tzv. CRUD operace. Jedná se o množinu čtyř dotazů pro základní manipulaci s daty prostřednictvím výběru, vytvoření, aktualizování a mazání. Pro každou oblast přímo definuje šablonový SQL dotazovací řetězec. 49

3. Implementace Obrázek 3.3: XML struktura - BranchEntity 3.1.5 Struktura BranchEntity BranchEntity element je určen k specifikování relačních dat a definování zobrazovacích podkomponentů hlavního formuláře. Title Popisový název podkomponentů formuláře. Může obsahovat text s mezerami. Name Pracovní název entity, pod kterým bude v kolekcích entit k dohledání. Může obsahovat pouze číslice, malá a velká písmena. Ui Určení typu zobrazovacího komponentu a jeho geometrické umístění. Relation Obsahuje informace o povinnosti relací k nadřízené Trunk entitě. DataModel Obsahuje informace, které popisují uložení dat v databázi. LeafEntity kolekce Kolekce LeafEntity, která patří pod definovanou Trunk entitu. 50

3.1. XML Metadata Obrázek 3.4: XML struktura BranchEntity DataModel 3.1.6 Struktura BranchEntity - DataModel Element DataModel uvnitř entit BranchEntity umožňuje definovat stejné klíčové informace jako u TrunkEntity. Tentokrát slouží k definování informačních a pracovních operací s relačně svázanými daty. Operace jsou specifikovány pro výběr, vytvoření, upravování a mazání pomocí šablonových dotazů. Zde je oproti DataModelu v TrunkEntity podstatný rozdíl, v CRUD je možné definovat operace pro čtení i operace, které umožňují manipulovat s daty. Schema Název databázového schématu, ve kterém se nachází používaná databázová tabulka. Table Název tabulky, se kterou budeme v rámci BranchEntity pracovat v relaci s tabulkou TrunkEntity. PrimaryKey Primární klíč slouží k manipulaci a vybírání dat. Zde se jedná o textový název sloupce pro primární klíč v databázové tabulce. CRUD Definuje tzv. CRUD operace. Jedná se o množinu čtyř dotazů pro základní manipulaci s daty prostřednictvím výběru, vytvoření, aktualizování a mazání. Pro každou oblast se definuje šablonový SQL dotazovací řetězec. 51

3. Implementace Obrázek 3.5: XML struktura BranchEntity Relation Obrázek 3.6: XML struktura BranchEntity Ui 3.1.7 Struktura BranchEntity Relation Tento element udává násobnosti vztahů mezi TrunkEntity a LeafEntity. V praxi to znamená, že určujeme násobnost vztahu jednoho záznamu tabulky TrunkEntity k jednomu záznamu v tabulce LeafEntity. Child Udává násobnost vztahu LeafEntity k nadřízené TrunkEntity. 3.1.8 Struktura BranchEntity Ui Element Ui určuje jaký typ a v jaké formě budou podkomponenty formuláře zobrazovány. Implementace obsahuje dva typy zobrazovacích podkomponentů classic a topic. Komponent topic slouží k zobrazení hlavních informací o jednom záznamu, jedná se o vztah 1:1. U druhého komponentu classic očekáváme vztah 1:N. Dále obsahuje informace o geometrickém umístění podkomponentů formuláře. View Slouží k upřesnění zobrazení podkomponentů formuláře. Position Určuje geometrické rozmístění podkomponentů formuláře pomocí systému řádků a sloupců. 52

3.1. XML Metadata Obrázek 3.7: Struktura LeafEntity Všechny entity u vzorových adres osob 3.1.9 Struktura LeafEntity LeafEntity element je určen k specifikování konkrétních dat a definování zobrazovacích komponentů formulářového podkomponentu. Specifikuje jednotlivé sloupce neboli položky formuláře. Položkám je možné explicitně nastavit zobrazovací komponent, získání dat nebo konvertování nepřímého zdroje dat. Title Název entity, který bude zobrazen v GUI. Může obsahovat text s mezerami. Name Pracovní název entity, pod kterým bude v kolekcích entit k dohledání. Může obsahovat pouze číslice, malá a velká písmena. Type Určení typu zobrazovacího komponentu. Validation (volitelný) Element obsahující validační řetězec, pomocí, kterého je možné ověřit platnost nového záznamu. DataModel Obsahuje informace, které popisují uložení dat v databázi. 53

3. Implementace Obrázek 3.8: XML struktura - LeafEntity Ui 3.1.10 Struktura LeafEntity Ui Element Ui určuje typ zobrazovacího vstupního pole a zároveň udává pevné pořadí v nadřazeném komponentu. V elementu View můžeme použít vestavěné zobrazovací typy nebo použít vlastní, které dodává programátor v přiložené SkinPlugin knihovně. U vestavěných typů jsou k dispozici následující typy : lineedit, textedit, spinbox, checkbox a combobox. V případě, že se programátor rozhodne použít vlastní vstupní komponent, použije zápis ve formátu custom:názevkomponenty. Position Tento element striktně definuje pozici pomocí atributu index položky, neboli sloupce v datových schématech. View (volitelný) Určuje typ zobrazovacího vstupního políčka. Seznam zobrazovacích komponent a jejich typu v View elementu LineEditComponent [lineedit] Jednořádkové editační pole. TextEditComponent [textedit] Víceřádkové editační pole. SpinBoxComponent [spinbox] Jednořádkové číselné pole s inkrementačním a dekrementačním tlačítkem. CheckBoxComponent [checkbox] Zaškrtnutelné políčko. ComboBoxComponent [combobox] Výběrový seznam položek. 54

3.1. XML Metadata Obrázek 3.9: XML struktura - LeafEntity Validation Obrázek 3.10: XML struktura - LeafEntity DataModel 3.1.11 Struktura LeafEntity Validation Element Validation uvnitř LeafEntity slouží k nastavení kontrolního řetězce, který vstupní pole obohacuje o možnost kontroly. Kontrolním řetězcem se v kontextu této práce rozumí regulární validační výraz. Pattern (volitelný) Obsahuje regulární výraz, který vytvoří programátor. Required (volitelný) Určuje, zda bude pole vyžadováno. Může obsahovat boolean hodnotu true nebo false. Help (volitelný) Obsahuje informační řetězec pro uživatele. 3.1.12 Struktura LeafEntity DataModel Element DataModel uvnitř LeafEntity umožňuje definovat název položky v databázové tabulce. V případě, že se jedná o položku, která vychází z nějakého číselníku, může obsahovat konvertor na převod číselníkové tabulky do zobrazovacího komponentu. Field Název sloupce v databázové tabulce. Convertor (volitelný) Schema Název databázového schématu, ve kterém se nachází používaná databázová tabulka. 55

3. Implementace Table Název tabulky, se kterou budeme v rámci konvertoru pracovat. DataSource Obsahuje šablonový SQL dotaz, pomocí, kterého bude naplněn výběrový seznam položek. 3.2 Formulářová aplikace 3.2.1 Formulář Knihovna plní roli stavitele formuláře, kde hlavním cílem je sestavení formulářového komponentu a uvedení do provozu nad datovým skladem. K těmto účelům slouží metodika a technologie popsaná dříve. Zaměříme se na grafické rozmístění jednotlivých prvků, na vlastnosti uživatelského rozhraní, připojení k databázi a zpracování SQL dotazů. 3.2.2 Vytvoření formulářové aplikace Předpokládejme, že máme vytvořený metadatový xml soubor a v případě potřeby i sestavený SkinPlugin. Soubory musí být pojmenovány stejně, jen souborové přípony jsou rozdílné. SkinPlugin není povinnou součástí. Ve vytvářené aplikaci je zapotřebí přidat reference na vytvořenou knihovnu a Qt framework knihovnu. V kódu začneme vytvořením připojovacího profilu do databáze, který pojmenujeme vhodným jménem. K vytvoření profilu použijeme třídu QsqlDatabase, která vlastní statickou metodu zvanou adddatabase(). Metoda má dva vstupní parametry - název profilu a název databázového ovladače. Protože v rámci práce pracujeme s PostgreSQL, použijeme ovladač nazývaný QPSQL. Vytvořené profily jsou přidávány v Qt do databázového fondu spojení. V tomto fondu spojení formulářové třídy umí automaticky profil vyhledat a použít. Než začneme s formulářem pracovat, musíme sestavit metadatový strom pomocí MetadataParser třídy. Tato třída očekává v konstruktoru celkem dva parametry - název souboru i s cestou a název databázového profilu, pod kterým budou formuláře přistupovat do databáze. Po inicializování je objekt třídy MetadataParser připraven k parsovacímu procesu. Parsování je zapotřebí vyvolat pomocí metody processxmldocument(). Když proces proběhne správně, můžeme pomocí metody getmetadata() odebrat funkční strom metadat. V případě nesprávně zapsaných xml metadat, parser vyhodí výjimku, kterou můžeme zachytit a ošetřit. 56

3.2. Formulářová aplikace Obrázek 3.11: Deployment diagram Nasazení formulářové aplikace Vytvořené metadatové stromy je možné vkládat do FormsPool fondu, který zajistí sestavení a umístění FormWidget komponentu do fondu formulářů. Fond FormsPool je implementován jako singleton. Při vkládání použijeme na vstupu metadatový strom a zadáváme název kolekce, pod kterou budou formuláře vytvořené pomocí metadat k dohledání. Dalším krokem vedoucímu k nasazení formuláře je vybrání požadované formuláře z fondu. Výběr je možné realizovat pomocí metody getformfrom- Pool(), která vyžaduje dva vstupní parametry a na výstupu vrací grafický komponent FormWidget. Formulářový komponent umístíme na požadované místo a nyní zbývá pouze naplnit formulářový komponent daty. To provedeme 57

3. Implementace zavoláním metody loaddata(). Zobrazovaný komponent umožňuje plnohodnotnou práci s daty podle popisu v xml metadatech. 3.3 Formulářové pohledy Formulářový komponent nabízí uživateli dva různé typy pohledů. V prvním pohledu uživatel může na data nahlížet prostřednictvím seznamu záznamů, kde je možnost u každého záznamu rozbalit detailní informace. Další možností je prohlížení detailních informací. V detailním pohledu je uživateli zpřístupněn pouze jeden záznam, který je hlavní pro všechny zobrazovací podkomponenty. Podkomponenty zde zobrazují relačně vztažená data v příslušných formulářových podkomponentech. Tyto podkomponenty jsme v návrhu nazývali SubFormWidget komponentem. Zobrazovací podkomponent rovněž nabízí obdobnou formu možných pohledů nad relačními daty. Nalezneme zde možnost seznamového i detailního pohledu. V detailním pohledu není možné provádět změny. K těmto účelům je zapotřebí přepnout do rozšířeného editačního pohledu. Při veškerých operacích, které upravují, přidávají nebo odstraňují záznamy, jsou používany transakce na straně datového modelu. 3.3.1 Stromový pohled Slouží k hromadnému prohlížení všech záznamů hlavní databázové tabulky, se kterou v TrunkEntity pracujeme. Pohled nám umožňuje u každého řádkového záznamu zobrazit stromově jednotlivé podzáznamy. Tento pohled se uživateli hodí především v situacích, kdy si přeje prohlížet podzáznamy více různých osob zároveň. Jedná se o režim pro čtení a mazání. V případě, kdy zvolíme možnost přidání nového záznamu nebo dvojkliknutím vybereme záznam pro editování, bude uživatel přepnut do detailního pohledu. Nastává transakce, v rámci, které bude formulář kontrolovat násobnost jednotlivých vztahových záznamů. Po poslední úpravě uživatel vybere tlačítko uložit, které provede zmíněnou kontrolu. V případě neporušení integrity dat, jsou záznamy uloženy a uživatel je vrácen zpět do stromového pohledu. 3.3.2 Popis zobrazované struktury Při prvním pohledu si můžeme všimnout, že se jedná o strom, který má dva sloupce. V prvním sloupci jsou zobrazeny indexy jednotlivých záznamů nebo popis informací. V pravém sloupci se nachází data z databáze. Při pohledu na vypsaný strom zjistíme, že je využito strukturování dat podle metadat. První hierarchickou položkou jsou řádky TrunkEntity, na další úrovni se nachází kolekce BranchEntity a pod každou kolekcí najdeme jednotlivé záznamy LeafEntity. 58

3.3. Formulářové pohledy Obrázek 3.12: Stromový pohled Adresář osob 3.3.3 Detailní pohled Tento typ pohledu nabízí uživateli kompletní přehled položkových kolekcí, které se vztahují k jednomu konkrétnímu hlavnímu záznamu. Hlavním záznamem se myslí jeden záznam v stromovém pohledu, který si uživatel vybral. Tento pohledový režim slouží k prohlížení záznamu s možností editace nebo pro přidávání nového hlavního záznamu. 3.3.4 Popis zobrazované struktury Pozorovatel si při prvním pohledu všimne různě rozmístěných grafických komponentů, které tvoří grafickou podobu formuláře. Tato zobrazovací plocha je postavena na systému řádků a sloupců, kde každý podkomponent formuláře má pevně dané umístění. Tyto podkomponenty jsou dříve zmiňované SubFormWidget komponenty, uvnitř každého podkomponentu jsou zobrazena relačně vztažená data. V tomto režimu můžeme provádět editování vztažených dat nebo mazání hlavního záznamu. Při přepnutí na stromový pohled, bude provedena kontrola násobností vztahů. Když dojde k poškození integrity dat, uživatel má možnost násobnost opravit nebo změny zrušit. 59

3. Implementace Obrázek 3.13: Detailní pohled Adresář osob 3.3.5 Přidávání nových záznamů Při přidávání záznamu vzniká transakce v datovém modelu a uživatelské rozhraní je přepnuto do detailního pohledu na nově vzniklý záznam. V rámci této transakce uživatel musí splnit podmínky násobnosti vztahů, jinak není možné data uložit do databáze. Na porušení integritních omezení je uživatel upozorněn prostřednictvím výpisu nesplněných podmínek. Splněním kontrolních podmínek nebo odmítnutím uložení proces přidávání končí a uživatel je navrácen do stromového pohledu. 3.3.6 Upravování záznamů Proces úpravy záznamu funguje téměř stejně jako u procesu přidávání nového záznamu. Znovu se zde objevuje transakční zpracování a kontrola integritních podmínek. V případě porušení a odmítnutí uložení bude provedeno navracení dat do původního stavu. 3.3.7 Mazání záznamů Mazání záznamu nepodléhá žádné kontrole, uživatel je pouze vyzván k zvážení svého rozhodnutí. Hlavní záznam a relačně vztažené záznamy jsou po 60

3.4. Formulářové podkomponentní pohledy Obrázek 3.14: Formulářový podkomponent Seznamový pohled potvrzení odstraněny z databáze. 3.3.8 Kontrola integrity při editování hlavního záznamu Když uživatel požádá o uložení změn, bude provedena kontrola integrity dat. Dojde k kontrole násobnosti a povinnosti vztahů a při nesplnění je na tuto souvislost uživatel upozorněn. Je zde možnost opravy a zrušení změn. 3.4 Formulářové podkomponentní pohledy Formulář i podformulář umožňuje přepínat mezi různými pohledy. Podformulář nabízí 3 typy pracovních režimů - seznamový, detailní a editační. Přepínání je umožněno pomocí dvojkliknutí na vybraný záznam v seznamovém pohledu nebo pomocí tlačítka v operační liště. 3.4.1 Seznamový pohled Tento druh pohledu nabízí uživateli rozsáhlý seznam relačně vztažených dat. Slouží k prohlížení a mazání. V případě, že chceme provádět editační nebo vytvářecí úkony, je nezbytné přepnout do detailního režimu s editačním rozšířením. K těmto účelům slouží grafický komponent, který nabízí operační lištu s tlačítky. 61

3. Implementace Obrázek 3.15: Formulářový podkomponent Detailní pohled Obrázek 3.16: Grafická vstupní pole 3.4.2 Detailní pohled Detailní pohled umožní uživateli si prohlédnout konkrétní relačně svázaný záznam zobrazený ve vstupních polích, řazených pod sebou dle indexů v metadatech. Pohled nabízí možnost rotování nad záznamy. Záznamy je možné posouvat pomocí šipek, které se nacházejí na operační liště obsahující tlačítka. O číselném zařazení záznamu, je uživatel informován prostřednictvím informační lišty. Zde uživatel nalezne číslo aktuálního záznamu a celkový počet záznamů. Tento režim se hodí zejména, když uživatel chce číst jednotlivé záznamy postupně a nepřeje si být zahlcován informacemi. 62

3.4. Formulářové podkomponentní pohledy 3.4.3 Přidání nového záznamu Při přidávání nového záznamu je detailní pohled přepnut na nový záznam.uživateli je záznam zpřístupněn a očekává se vyplnění vstupního podformuláře. Po vyplnění informací uživatel použije funkci uložit. Tato operace provede kontrolu správnosti vstupních údajů podle regulárních výrazů, které programátor nadefinoval v metadatech. Při bezchybném průchodu jsou data uložena do datového modelu. Zápis do databáze spouští hlavní formulář při operaci u- kládání. Operaci zápisu realizuje v případě dodržení všech nezbytných vztahů. Při nesprávném zápisu dat ve vstupních polích bude na tuto souvislost uživatel upozorněn v průběhu ukládání. Nebude možné dokončit proces uložení. Uživateli bude nabídnuta možnost opravy nebo zrušení přidávaného záznamu. 3.4.4 Editování záznamu V případě zájmu má uživatel možnost přepnout detailní režim do rozšířeného editačního pohledu, kdy je provedeno odemknutí vstupních políček a je možné provádět změny. Pro uložení změn platí úplně stejná pravidla, jako tomu bylo u přidávání nového záznamu. Při nesplnění kontrolních podmínek nedochází ke smazání dat, ale k obnovení původního stavu. 3.4.5 Mazání záznamu Při mazání jsou záznamy označeny a přidány do seznamu operací v rámci transakce. Samotné smazání proběhne až při ukládání hlavního záznamu. 3.4.6 Popis k vstupnímu poli formuláře Podkomponenty formuláře obsahují v detailním pohledu záznamy zobrazené na řádku, kde zobrazujeme popis a příslušná data v tzv. vstupním poli. Popisové pole je možné nahradit prostřednictvím vestavěného SkinPlugin rozhraní, které umožňuje naprogramování vlastních popisových komponentů pomocí rozhraní ILabelComponent. Vlastní vytvořený komponent je také možné dodat v přídavném pluginu, který bude vytvořen s xml souborem. V xml je nutné říci, jaké vlastní popisové komponenty, na kterých místech programátor použije. 3.4.7 Vstupní pole formuláře V rámci práce jsou implementovány 4 základní typy možných vstupních polí LineEditComponent, TextBoxComponent, CheckBoxComponent, ComboBox- Component a SpinBoxComponent. Je možné tyto typy komponentů rozšířit nebo vytvořit úplně nové pomocí SkinPlugin API rozhraní. Programátor k vytvořenému xml souboru dodá SkinPlugin, který bude obsahovat imple- 63

3. Implementace Obrázek 3.17: Vstupní pole - Nápověda Obrázek 3.18: Vyhodnocení kontroly vstupních polí mentaci nového vstupního pole. Podmínkou pro fungování je dodržení stanoveného komponentního rozhraní IInputComponent. 3.4.8 Kontrola vstupních polí Každé vstupní pole může obsahovat povinnost vyplnění a řetězec pro ověření vstupu. Tyto informace jsou brány z XML metadat, kde programátor má možnost definovat ověřovací řetězec, nápovědu a povinnost vyplnění. Informace jsou uživateli předány ve formuláři pomocí speciálního označení. Uživatel nalezne informaci v popisu položky nebo při umístění kurzoru na vstupní pole. V popisu jsou povinně vyplnitelné údaje zapsány tučným písmem. Pole, které podléhá kontrole ověřovacím regulárním výrazem je vyznačeno podtržením. Obdobné informace v textové podobě uživatel nalezne v zobrazované nápovědě při umístění kurzoru myši na vstupní pole. 3.4.9 Vyhodnocení kontroly vstupních polí Při žádosti o uložení změn je provedena kontrola, která odhalí případné nedostatky. Upozorní na nesplnění podmínek a nabídne možnost opravy a zrušení změn. U položky Ulice vidíme, že je prováděna kontrola regulárním výrazem a u položky Země jde jen o vyplnění údajů bez kontroly. 64

3.5. Práce s databází Obrázek 3.19: BPD diagram - Transakční zpracování 3.5 Práce s databází Práce s databázovým serverem je realizována pomocí Qt SQL modulu. Tento modul nabízí pestrou podporu různých databázových aplikačních serverů, které jsou v modulu zpřístupňovány pomocí tzv. databázových ovladačů. V základní výbavě Qt frameworku je dostupný pouze ovladač pro databázový systém SQLite a obecný ovladač ODBC. Pro potřeby bakalářské práce je nezbytné doinstalovat ovladač pro systém PostgreSQL. Postup a návod pro instalaci je k dispozici v dokumentaci, která je standardně dostupná ke každé verzi Qt Frameworku. 3.5.1 Dotazování Veškeré požadavky, které jsou prováděny s databází, používají jazyk SQL. Využívá se dotazovacích šablon, které programátor definoval v metadatech. 3.5.2 Transakce Komunikace s databází je realizována formou transakcí, které nabízí Qt framework v databázovém modulu. Transakce funguje tak, že databázový ovladač požádáme o zahajení transakce pomocí funkce transaction(). V rámci této transakce jsou všechny databázové dotazy shromažďovány a k jejich provedení dojde až v okamžiku, kdy použijeme funkci commit(). Jedná se o klasickou implementaci známých databázových transakcí. V případě, že si nepřejeme, aby byly změny provedeny, můžeme je zrušit pomocí tzv. rollbacku. Při rollbacku dochází k navrácení dat do původního stavu. 65

3. Implementace Obrázek 3.20: BPD diagram - Zpracování v editačním pohledu Transakční zpracování je dostupné i v datovém modelu, který byl vytvořen pro skladování dat podle metadat. 3.5.3 Transakce ve formuláři Při vytvoření nového záznamu nebo výběru jednoho hlavního záznamu v stromovém pohledu dochází k přepnutí do detailního pohledu. V tomto okamžiku je vytvořena transakce. Při editování v detailním pohledu vidíme změny provedené v subkomponentech. Změny jsou k vidění okamžitě, protože data se zobrazují prostřednictvím datového modelu. Veškeré změny provedené v subkomponentech jsou realizovány pouze v datovém modelu. K operacím commit nebo rollback dochází při procesu ukládání podle situace a rozhodnutí uživatele. 3.5.4 Manipulace s daty v formulářových subkomponentech Při manipulaci ve formulářových subkomponentech se změny provádí pouze v datovém modelu a sql dotazy jsou přidávány do otevřené transakce. Při vstupu do transakce se v datovém modelu u každé BranchEntity provede zkopírování datových modelů. Veškeré změny jsou realizovány nad novým datovým modelem. Pokud dojde ke commitu, starý model je zahozen a nahrazen novým. V případě, že nastane rollback, nově vzniklý model je smazán a nahrazen původním. 66

Kapitola 4 Ladění a testování Ladění a testování softwarového díla patří mezi nejdůležitější práci při vývoji. V kapitole budou shrnuty metodiky, které sloužily k úspěšnému ladění výstupní knihovny. 4.1 Testování Testování vytvořeného softwarového díla patří k důležitým částem životního cyklu softwaru. Při programování se v aplikaci vyskytují snadno i těžko odhalitelné chyby. Snahou testování a ladění je odstranění nežádoucích jevů a problémů. 4.2 Trasovací nástroje V případě ladění existují speciální trasovací nástroje, které umožňují programátorovi sledovat běh programu v reálném čase. Při tomto sledování má možnost programátor běh zastavit a realizovat výpis proměnných nebo určit místo ke kontrole programu. Nástroj je silným pomocníkem při ladění složitých procesů, které na sebe navazují. Při vývoji formulářové knihovny jsem tuto metodiku používal dost často, a to při ladění metadatového objektového stromu, datového modelu a při stavbě formulářových komponentů. Používal jsem možnosti zastavení programu na konkrétním řádku kódu, skokové procházení programu a také zastavení dle podmínky v určené části programu. Nástroj GNU GDB, který je integrován ve vývojovém prostředí QtCreator, mi umožnil ladění formou trasování. 67

4. Ladění a testování Obrázek 4.1: QtCreator - GDB debugger 4.3 Unit testy Unit testy neboli jednotkové testy jsou jednoúčelové malé testovací programy. Mohou kontrolovat vlastnosti a chování aplikace ve vytvořených scénářích určených programátorem. Používají se převážně automatizovaně. Při rozsáhlých změnách se používají k ověření funkčnosti dříve funkčního kódu. Jednotkové testování není aplikovatelné na vše v programu. Je nutné vždy vybrat, co budeme testovat a hlavně, s jakými referenčními daty budeme provádět kontrolu. Účinnost spočívá v porovnávání hodnot s předpokládanými. Jednotkové testování bylo v práci použito k testování metadatového objektového stromu, kdy jsou testovány všechny položky xml dokumentu. 68