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

Save this PDF as:
 WORD  PNG  TXT  JPG

Rozměr: px
Začít zobrazení ze stránky:

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

Transkript

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

2

3 Č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

4

5 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.

6

7 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

8 Č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.

9 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

10

11 Obsah Úvod 15 1 Specifikace cílů práce Vymezení cílů bakalářské práce Motivace Požadavky na produkt Hlavní části knihovny Základní pojmy a zkratky Ostatní podobná řešení Návrh řešení Formulář Metadata SkinPlugin Hlavní části navrhovaného řešení XML metadata Metadata parser Metadatový strom SkinPlugin API Form Builder Form SubForm ILabelComponent IInputComponent DataModel Popis struktury Shrnutí navrhovaného řešení Implementace XML Metadata

12 3.2 Formulářová aplikace Formulářové pohledy Formulářové podkomponentní pohledy Práce s databází Ladění a testování Testování Trasovací nástroje Unit testy Memory leaks Ruční ověření funkčnosti Realizace knihovny Návrhové prostředí Vývojové prostřední Skriptovací systém cmake Verzování zdrojového kódu Části distribučního balíku knihovny Použití Příklady použití Vytvořené demo příklady Metodika tvorby formulářových aplikací Příklad 1 - Adresář osob Příklad 2 - Agenda místností s výpočetní technikou Závěr 85 Literatura 87 A Obsah přiloženého CD 89 12

13 Seznam obrázků 2.1 Component diagram Hlavní komponenty knihovny Hierarchický strom entit Class diagram Metadatový strom Class diagram SkinPlugin API Class diagram FormBuilder Activity diagram Vytvoření formuláře z popisu v XML Class diagram FormWidget struktura Class diagram SubFormWidget struktura Class diagram ILabelComponent Class diagram IInputComponent Class diagram DataModel struktura Mřížkový pohled na XML strukturu metadat XML struktura - TrunkEntity - DataModel XML struktura - BranchEntity XML struktura BranchEntity DataModel XML struktura BranchEntity Relation XML struktura BranchEntity Ui Struktura LeafEntity Všechny entity u vzorových adres osob XML struktura - LeafEntity Ui XML struktura - LeafEntity Validation XML struktura - LeafEntity DataModel Deployment diagram Nasazení formulářové aplikace Stromový pohled Adresář osob Detailní pohled Adresář osob Formulářový podkomponent Seznamový pohled Formulářový podkomponent Detailní pohled Grafická vstupní pole Vstupní pole - Nápověda Vyhodnocení kontroly vstupních polí

14 Seznam obrázků 3.19 BPD diagram - Transakční zpracování BPD diagram - Zpracování v editačním pohledu QtCreator - GDB debugger Use case - Formulářová aplikace BPD diagram - Vytvoření formulářové aplikace ERD diagram - Adresář osob ERD diagram - Agenda místností s výpočetní technikou

15 Ú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

16

17 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

18 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

19 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 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 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í 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) 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

20 1. Specifikace cílů práce 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 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í 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 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 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 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

21 1.5. Základní pojmy a zkratky 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ů 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 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) 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 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í 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

22 1. Specifikace cílů práce 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ší 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 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 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 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 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

23 1.5. Základní pojmy a zkratky 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 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 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ě 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í 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

24 1. Specifikace cílů práce 1.6 Ostatní podobná řešení 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 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í 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

25 1.6. Ostatní podobná řešení 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 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

26

27 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

28 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

29 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 ové 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

30 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 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

31 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 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 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

32 2. Návrh řešení Obrázek 2.3: Class diagram Metadatový strom 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

33 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

34 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 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

35 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 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 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

36 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 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

37 2.9. Form Builder 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 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

38 2. Návrh řešení 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

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

40 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

41 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

42 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

43 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 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

44 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

45 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

46 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

47 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 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 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

48 3. Implementace Obrázek 3.1: Mřížkový pohled na XML strukturu metadat 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

49 3.1. XML Metadata Obrázek 3.2: XML struktura - TrunkEntity - DataModel 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

50 3. Implementace Obrázek 3.3: XML struktura - BranchEntity 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

51 3.1. XML Metadata Obrázek 3.4: XML struktura BranchEntity DataModel 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

52 3. Implementace Obrázek 3.5: XML struktura BranchEntity Relation Obrázek 3.6: XML struktura BranchEntity Ui 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 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

53 3.1. XML Metadata Obrázek 3.7: Struktura LeafEntity Všechny entity u vzorových adres osob 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

54 3. Implementace Obrázek 3.8: XML struktura - LeafEntity Ui 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

55 3.1. XML Metadata Obrázek 3.9: XML struktura - LeafEntity Validation Obrázek 3.10: XML struktura - LeafEntity DataModel 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 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

56 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 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ů 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

57 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

58 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 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 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

59 3.3. Formulářové pohledy Obrázek 3.12: Stromový pohled Adresář osob 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 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

60 3. Implementace Obrázek 3.13: Detailní pohled Adresář osob 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 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 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

61 3.4. Formulářové podkomponentní pohledy Obrázek 3.14: Formulářový podkomponent Seznamový pohled potvrzení odstraněny z databáze 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ě 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

62 3. Implementace Obrázek 3.15: Formulářový podkomponent Detailní pohled Obrázek 3.16: Grafická vstupní pole 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

63 3.4. Formulářové podkomponentní pohledy 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 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 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 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 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

64 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 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 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

65 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 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 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

66 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 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 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

67 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

68 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

KAPITOLA 3. Architektura aplikací na frameworku Rails. V této kapitole: modely, pohledy, řadiče.

KAPITOLA 3. Architektura aplikací na frameworku Rails. V této kapitole: modely, pohledy, řadiče. KAPITOLA 3 Architektura aplikací na frameworku Rails V této kapitole: modely, pohledy, řadiče. 58 Část I: Začínáme Jedna ze zajímavých vlastností frameworku Rails spočívá v tom, že klade docela závažná

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

Komputerizace problémových domén

Komputerizace problémových domén Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 03 1/19 Komputerizace problémových domén Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

VYUŽITÍ REGIONÁLNÍCH FUNKCÍ A WWW ROZHRANÍ V INTEGROVANÉM KNIHOVNÍM SYSTÉMU KPWINSQL

VYUŽITÍ REGIONÁLNÍCH FUNKCÍ A WWW ROZHRANÍ V INTEGROVANÉM KNIHOVNÍM SYSTÉMU KPWINSQL VYUŽITÍ REGIONÁLNÍCH FUNKCÍ A WWW ROZHRANÍ V INTEGROVANÉM KNIHOVNÍM SYSTÉMU KPWINSQL Petr Štefan Václav Trunec, KP-sys, Čacké 155, Pardubice 1 Úvod Firma KP-SYS spol. s r. o. dodává na náš trh integrované

Více

Databázové systémy trocha teorie

Databázové systémy trocha teorie Databázové systémy trocha teorie Základní pojmy Historie vývoje zpracování dat: 50. Léta vše v programu nevýhody poměrně jasné Aplikace1 alg.1 Aplikace2 alg.2 typy1 data1 typy2 data2 vytvoření systémů

Více

Architektura aplikace

Architektura aplikace Architektura aplikace MARBES-JIRA plugin Tým: GRSS Členové: František Schneider Jaroslav Ráb Lukáš Gemela Jaromír Staněk Upravil Verze dokumentu Datum F. Schneider 1.0 25.3.2012 F. Schneider 2.0 25.4.2012

Více

RELAČNÍ DATABÁZOVÉ SYSTÉMY

RELAČNÍ DATABÁZOVÉ SYSTÉMY RELAČNÍ DATABÁZOVÉ SYSTÉMY VÝPIS KONTROLNÍCH OTÁZEK S ODPOVĚDMI: Základní pojmy databázové technologie: 1. Uveďte základní aspekty pro vymezení jednotlivých přístupů ke zpracování hromadných dat: Pro vymezení

Více

Architektura. Vedení sesterské dokumentace

Architektura. Vedení sesterské dokumentace Architektura Tým Lorem Ipsum Verze 1.1 29.3.2015 Obsah 1 Kontext...3 1.1 Cíle projektu...3 2 Technologie...3 2.1 Zvolená alternativa tvorby GUI...3 3 Datové schéma...4 4 Navržená architektura...5 4.1 Fyzický

Více

Novinky ve Visual Studio 2010. Tomáš Kroupa Tomas.Kroupa@hotmail.com

Novinky ve Visual Studio 2010. Tomáš Kroupa Tomas.Kroupa@hotmail.com Novinky ve Visual Studio 2010 Tomáš Kroupa Tomas.Kroupa@hotmail.com O čem si dnes řekneme Visual studio 2010 (beta 2) Jazyk C# 4.0 ASP.NET 4.0.NET 4.0 Visual Studio 2010 Beta 2 Jak získat Testovací verze

Více

Nástroje a frameworky pro automatizovaný vývoj. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Nástroje a frameworky pro automatizovaný vývoj. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nástroje a frameworky pro automatizovaný vývoj Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Proces vývoje webové aplikace Předepsaná adresářová struktura. Kompilace zdrojových kódů.

Více

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu VÝUKOVÝ MATERIÁL Identifikační údaje školy Vyšší odborná škola a Střední škola, Varnsdorf, příspěvková organizace Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

Microsoft Office 2003 Souhrnný technický dokument white paper

Microsoft Office 2003 Souhrnný technický dokument white paper Microsoft Office 2003 Souhrnný technický dokument white paper Přehled inteligentních klientských aplikací založených na sadě Microsoft Office 2003 System Publikováno: Duben 2003 Shrnutí: Inteligentní klienti

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

Práce s velkými sestavami

Práce s velkými sestavami Práce s velkými sestavami Číslo publikace spse01650 Práce s velkými sestavami Číslo publikace spse01650 Poznámky a omezení vlastnických práv Tento software a související dokumentace je majetkem společnosti

Více

Návrh programu v Black Box Component Builderu s využitím architektury Model View Controller

Návrh programu v Black Box Component Builderu s využitím architektury Model View Controller Návrh programu v Black Box Component Builderu s využitím architektury Model View Controller Gustav Hrudka Katedra měřicí a řídicí techniky, VŠB Technická univerzita v Ostravě, tř. 17. listopadu, 708 33

Více

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např.

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např. 2 přednáška 2 října 2012 10:32 Souborově orientované uchování dat Slabý HW Není možné uchovávat "velká data" - maximálně řádově jednotky MB Na každou úlohu samostatná aplikace, která má samostatná data

Více

EXTRAKT z české technické normy

EXTRAKT z české technické normy EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním 03.220.01, 35.240.70 materiálem o normě. Inteligentní dopravní systémy Geografické datové soubory (GDF)

Více

Databázové systémy I. 1. přednáška

Databázové systémy I. 1. přednáška Databázové systémy I. 1. přednáška Vyučující a cvičení St 13:00 15:50 Q09 Pavel Turčínek St 16:00 18:50 Q09 Oldřich Faldík Čt 10:00 12:50 Q09 Jan Turčínek Pá 7:00 9:50 Q08 Pavel Turčínek Pá 10:00 12:50

Více

PŘÍRODOVĚDECKÁ FAKULTA UNIVERZITY PALACKÉHO KATEDRA INFORMATIKY BAKALÁŘSKÁ PRÁCE. Vytváření a evidence smluv. 2012 Petr Čulík

PŘÍRODOVĚDECKÁ FAKULTA UNIVERZITY PALACKÉHO KATEDRA INFORMATIKY BAKALÁŘSKÁ PRÁCE. Vytváření a evidence smluv. 2012 Petr Čulík PŘÍRODOVĚDECKÁ FAKULTA UNIVERZITY PALACKÉHO KATEDRA INFORMATIKY BAKALÁŘSKÁ PRÁCE Vytváření a evidence smluv 2012 Petr Čulík Anotace Aplikace slouží uživateli jako nástroj pro vytváření a evidenci jednorázových,

Více

Rozdílová dokumentace k ovládání IS KARAT.net

Rozdílová dokumentace k ovládání IS KARAT.net Dokumentace k IS KARAT.net Rozdílová dokumentace k ovládání IS KARAT.net programový modul: Rozdílová dokumentace k ovládání IS KARAT.net OBSAH: 1 ÚVOD... 3 2 PŘIHLAŠOVACÍ DIALOG... 4 3 NAVIGACE... 5 3.1

Více

TRANSFORMACE RELAČNÍHO DATOVÉHO MODELU NA OBJEKTOVÝ TRANSFORMATION OF RELATIONAL TO OBJECT DATA MODEL

TRANSFORMACE RELAČNÍHO DATOVÉHO MODELU NA OBJEKTOVÝ TRANSFORMATION OF RELATIONAL TO OBJECT DATA MODEL TRANSFORMACE RELAČNÍHO DATOVÉHO MODELU NA OBJEKTOVÝ TRANSFORMATION OF RELATIONAL TO OBJECT DATA MODEL Vít Holub Anotace Článek poskytne čtenáři základní přehled v datových modelech, ukáže výhody a nevýhody

Více

Kolaborativní aplikace

Kolaborativní aplikace Kolaborativní aplikace Michal Máčel Vema, a. s. Okružní 3a, 638 00 Brno - Lesná, macel@vema.cz Tomáš Hruška Fakulta informačních technologií Vysokého učení technického v Brně, Ústav informačních systémů,

Více

3D Vizualizace muzea vojenské výzbroje

3D Vizualizace muzea vojenské výzbroje 3D Vizualizace muzea vojenské výzbroje 3D visualization of the museum of military equipment Bc.Tomáš Kavecký STOČ 2011 UTB ve Zlíně, Fakulta aplikované informatiky, 2011 2 ABSTRAKT Cílem této práce je

Více

Statistica, kdo je kdo?

Statistica, kdo je kdo? Statistica, kdo je kdo? Newsletter Statistica ACADEMY Téma: Typy instalací Typ článku: Teorie Někteří z vás používají univerzitní licence, někteří síťové, podnikové atd. V tomto článku Vám představíme,

Více

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

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 Rezervační komponenta pro informační systém sportovního

Více

Metodika. Oznámení o vykonávání působností v agendě ve smyslu zákona č. 111/2009. Sb., o základních registrech. Verze 1.6

Metodika. Oznámení o vykonávání působností v agendě ve smyslu zákona č. 111/2009. Sb., o základních registrech. Verze 1.6 Metodika Oznámení o vykonávání působností v agendě ve smyslu zákona č. 111/2009 Sb., o základních registrech Verze 1.6 AIS RPP Působnostní určeno pro oznamovatele Oznámení o vykonávání působností č. 111/2009

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

Přehled systému Microsoft SQL Server. Komu je kniha určena Struktura knihy Nejvhodnější výchozí bod pro čtení knihy Konvence a struktura knihy

Přehled systému Microsoft SQL Server. Komu je kniha určena Struktura knihy Nejvhodnější výchozí bod pro čtení knihy Konvence a struktura knihy Komu je kniha určena Struktura knihy Nejvhodnější výchozí bod pro čtení knihy Konvence a struktura knihy Konvence Další prvky Požadavky na systém Ukázkové databáze Ukázky kódu Použití ukázek kódu Další

Více

MYBIZ - Řešení pro zpřístupnění dat ze stávajících aplikací na mobilních zařízeních (Mobilize your business!) Požadavky zákazníka.

MYBIZ - Řešení pro zpřístupnění dat ze stávajících aplikací na mobilních zařízeních (Mobilize your business!) Požadavky zákazníka. MYBIZ - Řešení pro zpřístupnění dat ze stávajících aplikací na mobilních zařízeních (Mobilize your business!) IT SYSTEMS a.s. Mnoho společností má implementovány aplikace, které byly vyvíjeny (případně

Více

MATURITNÍ PRÁCE dokumentace

MATURITNÍ PRÁCE dokumentace MATURITNÍ PRÁCE dokumentace Jídelníček SŠIEŘ pro Android Martin Bartoň školní rok: 2012/2013 obor: třída: Počítačové systémy PS4.A ABSTRAKT Práce je zaměřená na problematiku tvorby Android aplikací,

Více

InTouch 8.0 Subsystém distribuovaných alarmů

InTouch 8.0 Subsystém distribuovaných alarmů InTouch 8.0 Subsystém distribuovaných alarmů Pavel Průša Pantek (CS) s.r.o. Strana 2 Obsah Úvod Úvod Subsystém distribuovaných alarmů Ukládání alarmů do relační databáze Zobrazování, potvrzování a potlačování

Více

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE 2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE Studijní cíl Tento blok je věnován základní syntaxi příkazu SELECT, pojmům projekce a restrikce. Stručně zde budou představeny příkazy

Více

Ing. Jiří Fůsek. Základní informace. Pracovní zkušenosti. Vzdělání. 09/2015 - nyní Freelancer. 09/2008-06/2010 Univerzita Tomáše Bati ve Zlíně

Ing. Jiří Fůsek. Základní informace. Pracovní zkušenosti. Vzdělání. 09/2015 - nyní Freelancer. 09/2008-06/2010 Univerzita Tomáše Bati ve Zlíně Základní informace Pracovní zkušenosti Ing. Jiří Fůsek Mikulova 1573/11, 149 00 Praha +420 774 331 232 fusek.jiri@gmail.com http://www.jirifusek.net/ 09/2015 - nyní Freelancer Senior C#.NET vývojář - SW

Více

XML Š ABLONY A JEJICH INTEGRACE V LCMS XML TEMPLATES AND THEIN INTEGRATION IN LCMS

XML Š ABLONY A JEJICH INTEGRACE V LCMS XML TEMPLATES AND THEIN INTEGRATION IN LCMS XML Š ABLONY A JEJICH INTEGRACE V LCMS XML TEMPLATES AND THEIN INTEGRATION IN LCMS Roman MALO - Arnošt MOTYČKA This paper is oriented to discussion about using markup language XML and its features in LCMS

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Modelování obchodních procesů

Modelování obchodních procesů Modelování obchodních procesů Ing. Jiří Mlejnek Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze Jiří Mlejnek, 2011 jiri.mlejnek@fit.cvut.cz Softwarové

Více

Vývoj informačních systémů. Architektura, návrh Vzory: Doménová logika

Vývoj informačních systémů. Architektura, návrh Vzory: Doménová logika Vývoj informačních systémů Architektura, návrh Vzory: Doménová logika Zachman Framework Zdroje Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování. 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Business modelling, základní nástroje a metody business modelování.

Více

Modelování webových služeb v UML

Modelování webových služeb v UML Modelování webových služeb v UML Jaromír Šveřepa LBMS, s.r.o. Abstrakt: Tento příspěvek se zaměřuje na praktický postup pro identifikaci potřeby webové služby, modelování způsobu jejího použití, popřípadě

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

Databázové a informační systémy

Databázové a informační systémy Databázové a informační systémy doc. Ing. Miroslav Beneš, Ph.D. katedra informatiky FEI VŠB-TUO A-1007 / 597 324 213 http://www.cs.vsb.cz/benes Miroslav.Benes@vsb.cz Obsah Jak ukládat a efektivně zpracovávat

Více

Infrastruktura UML. Modelování struktury v UML. Superstruktura UML. Notace objektů. Diagramy objektů

Infrastruktura UML. Modelování struktury v UML. Superstruktura UML. Notace objektů. Diagramy objektů Infrastruktura UML v UML Karel Richta listopad 2011 Richta: B101TMM - v UML 2 Superstruktura UML Směr pohledu na systém dle UML Diagramy popisující strukturu diagramy tříd, objektů, kompozitní struktury,

Více

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette Kapitola 1 PHP framework Nette 1.1 Úvod Zkratka PHP (z anglického PHP: Hypertext Preprocessor) označuje populární skriptovací jazyk primárně navržený pro vývoj webových aplikací. Jeho oblíbenost vyplývá

Více

Manuál k aplikaci SDO PILOT v.0.2

Manuál k aplikaci SDO PILOT v.0.2 Manuál k aplikaci SDO PILOT v.0.2 Základní informace o aplikaci Aplikace slouží pro zjednodušené vytváření dokumentů Souhrnů doporučených opatření pro Evropsky významné lokality. Vznikala přírustkovým

Více

Workshop Exact Software CEE

Workshop Exact Software CEE Workshop Exact Software CEE (Exact Synergy Enterprise) Praha 11.12.2012 Martin Burian 2012 Exact Agenda Verze Synergy Enterprise Změny v systémových požadavcích Configurator + Validace a alokace (připojení)

Více

ELEKTRONICKÁ PORODNÍ KNIHA POPIS APLIKACE Michal Huptych, Petr Janků, Lenka Lhotská

ELEKTRONICKÁ PORODNÍ KNIHA POPIS APLIKACE Michal Huptych, Petr Janků, Lenka Lhotská ELEKTRONICKÁ PORODNÍ KNIHA POPIS APLIKACE Michal Huptych, Petr Janků, Lenka Lhotská Anotace Tento příspěvek popisuje aplikaci, která je převodem tzv. porodní knihy do elektronické podoby. Aplikace vzniká

Více

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Co je to UML Evoluce UML Diagram komponent Diagram odbavení Diagram tříd Aktivity diagram Stavový diagram Sekvenční diagram Diagram

Více

Architektura softwarových systémů

Architektura softwarových systémů Architektura softwarových systémů Ing. Jiří Mlejnek Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze Jiří Mlejnek, 2011 jiri.mlejnek@fit.cvut.cz Softwarové

Více

Předmětem části B) veřejné zakázky je dodávku existujícího licencovaného softwaru dle této technické specifikace.

Předmětem části B) veřejné zakázky je dodávku existujícího licencovaného softwaru dle této technické specifikace. Příloha č. 2. - Detailní specifikace zakázky pro část B) Dodávka specializovaného softwaru 1. Obecná specifikace Předmětem části B) veřejné zakázky je dodávku existujícího licencovaného softwaru dle této

Více

7.6 Další diagramy UML

7.6 Další diagramy UML 7.6 Další diagramy UML 7.6.1 Moduly (balíčky - package) a kolaborace (collaboration) Jak rozložit rozsáhlý systém na menší? - seskupování tříd (prvků modelu) do jednotek vyšší úrovně (package v UML). UI

Více

Jádrem systému je modul GSFrameWork, který je poskytovatelem zejména těchto služeb:

Jádrem systému je modul GSFrameWork, který je poskytovatelem zejména těchto služeb: Technologie Marushka Základním konceptem technologie Marushka je použití jádra, které poskytuje přístup a jednotnou grafickou prezentaci geografických dat. Jádro je vyvíjeno na komponentním objektovém

Více

Servlety a JSP. Petr Adámek, petr.adamek@ibacz.eu

Servlety a JSP. Petr Adámek, petr.adamek@ibacz.eu Servlety a JSP Petr Adámek, petr.adamek@ibacz.eu Úvod Rekapitulace vstupních znalostí Standardy Nástroje (Běhové prostředí, nástroje pro vývoj) Servlety JSP JSP značky EL (Expression Language) Internacionalizace

Více

Kapitola 1: Co je Microsoft Access? 27 Kapitola 2: Mnoho tváří aplikace Microsoft Access 41 Kapitola 3: Návrh databázové aplikace 75

Kapitola 1: Co je Microsoft Access? 27 Kapitola 2: Mnoho tváří aplikace Microsoft Access 41 Kapitola 3: Návrh databázové aplikace 75 Stručný obsah Část 1 Základy aplikace Microsoft Access Kapitola 1: Co je Microsoft Access? 27 Kapitola 2: Mnoho tváří aplikace Microsoft Access 41 Kapitola 3: Návrh databázové aplikace 75 Část 2 Vytváření

Více

Databázové systémy úvod

Databázové systémy úvod Databázové systémy úvod Michal Valenta Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze c Michal Valenta, 2016 BI-DBS, LS 2015/16 https://edux.fit.cvut.cz/courses/bi-dbs/

Více

Návrh aplikace. Project Westpon. Inteligentní simulátor budov. Martin Mudra, Jan Smejkal, Onřej Macoszek, Marek Žehra, Jiří Slivárich

Návrh aplikace. Project Westpon. Inteligentní simulátor budov. Martin Mudra, Jan Smejkal, Onřej Macoszek, Marek Žehra, Jiří Slivárich Návrh aplikace Project Westpon Inteligentní simulátor budov Martin Mudra, Jan Smejkal, Onřej Macoszek, Marek Žehra, Jiří Slivárich . Úvod.. Účel dokumentu Tento dokument má za účel detailně popsat návrh

Více

Vývoj informačních systémů. Přehled témat a úkolů

Vývoj informačních systémů. Přehled témat a úkolů Vývoj informačních systémů Přehled témat a úkolů Organizace výuky doc. Mgr. Miloš Kudělka, Ph.D. EA 439, +420 597 325 877 homel.vsb.cz/~kud007 milos.kudelka@vsb.cz Přednáška Teorie Praxe Cvičení Diskuze

Více

RETAIL PROCESS TRACKER VIZUALIZACE OBCHODNÍCH PROCESŮ VAŠEHO INFORMAČNÍHO SYSTÉMU

RETAIL PROCESS TRACKER VIZUALIZACE OBCHODNÍCH PROCESŮ VAŠEHO INFORMAČNÍHO SYSTÉMU Váš IT partner pro retail, logistiku a distribuci RETAIL PROCESS TRACKER VIZUALIZACE OBCHODNÍCH PROCESŮ VAŠEHO INFORMAČNÍHO SYSTÉMU Miroslav Krupa 1.10.2009 IT pro U&SLUNO a.s. l SADOVÁ 28 l 702 00 OSTRAVA

Více

Technologie Java. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Technologie Java. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Technologie Java Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Trocha historie Java vznikla v roce 1995 jak minimalistický programovací jazyk (211 tříd). Syntaxe vycházela z C/C++. V

Více

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů - 1.1 - Kapitola 1: Úvod Účel databázových systémů Pohled na data Modely dat Jazyk pro definici dat (Data Definition Language; DDL) Jazyk pro manipulaci s daty (Data Manipulation Language; DML) Správa

Více

VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika

VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika Napojení e-shopu na obchodní portál aukro.cz bakalářská práce Autor: Josef Vrbata Vedoucí práce: Ing.

Více

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Datová podpora na úrovni kontaktního pracoviště Úřadu práce pro státní sociální podporu Josef Hájek Bakalářská

Více

CineStar Černý Most Praha 31. 10. 2012

CineStar Černý Most Praha 31. 10. 2012 CineStar Černý Most Praha 31. 10. 2012 Stejná aplikace na více zařízeních Michael Juřek Microsoft s.r.o. Potřebné ingredience 1. Portable libraries 2. Návrhový vzor MVVM 3. XAML 4. Abstrakce platformy

Více

KIV/PIA Semestrální práce

KIV/PIA Semestrální práce KIV/PIA Semestrální práce Diskuzní fórum Tomáš Časta(A10N0057P) casta@students.zcu.cz 1. Architektura aplikace 1.1 MVC Model-view-controller (MVC) je softwarová architektura, která rozděluje datový model

Více

MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY

MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY Evidence filmových nahrávek Bakalářská práce Richard Karmazín 2005 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval

Více

KIV/PIA 2013 Jan Tichava

KIV/PIA 2013 Jan Tichava KIV/PIA 2013 Jan Tichava Java EE JSF, PrimeFaces Spring JPA, EclipseLink Java Platform, Enterprise Edition Persistence Zobrazovací vrstva Interakce aplikací Deployment Java Persistence API Enterprise

Více

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Martin Molhanec Katedra elektrotechnologie, ČVUT - Fakulta elektrotechnická, Technická 2, 166 21 PRAHA 6 e-mail: molhanec@fel.cvut.cz Abstrakt UML Unified Modeling Language

Více

Globální architektura ROS

Globální architektura ROS Verze: 1.1 Obsah: 1. Vymezení cílů dokumentu... 4 2. Pojmy a zkratky... 5 3. Procesní architektura...10 3.1. Upřesnění struktury dokumentu:...10 3.2. Postup tvorby a použité metodiky...10 3.3. Základní

Více

IMPLEMENTACE SYSTÉMU GROUPWISE NA PEF ČZU V PRAZE IMPLEMENTATION OF THE SYSTEM GROUPWISE ON THE PEF ČZU PRAGUE. Jiří Vaněk, Jan Jarolímek

IMPLEMENTACE SYSTÉMU GROUPWISE NA PEF ČZU V PRAZE IMPLEMENTATION OF THE SYSTEM GROUPWISE ON THE PEF ČZU PRAGUE. Jiří Vaněk, Jan Jarolímek IMPLEMENTACE SYSTÉMU GROUPWISE NA PEF ČZU V PRAZE IMPLEMENTATION OF THE SYSTEM GROUPWISE ON THE PEF ČZU PRAGUE Jiří Vaněk, Jan Jarolímek Anotace: Příspěvek se zabývá hlavními trendy rozvoje programů pro

Více

Nasazení EIS JASU CS v rezortu Ministerstva zdravotnictví ČR vč. všech podřízených OSS

Nasazení EIS JASU CS v rezortu Ministerstva zdravotnictví ČR vč. všech podřízených OSS P Ř Í P A D O V Á S T U D I E Nasazení EIS JASU CS v rezortu Ministerstva zdravotnictví ČR vč. všech podřízených OSS MÚZO Praha s. r. o. Politických vězňů 15 110 00 Praha 1 www.muzo.cz obchod@muzo.cz JASU

Více

EXTRAKT z technické specifikace ISO

EXTRAKT z technické specifikace ISO EXTRAKT z technické specifikace ISO Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě. Inteligentní dopravní systémy Dopravní a cestovní informace předávané prostřednictvím

Více

Práce se soubory opakování

Práce se soubory opakování Práce se soubory Práce se soubory opakování Nízko-úrovňové (C-čkové) API. fopen(), fread(), fwrite(), fclose() S daty se manipuluje přes řetězce. Manipulace s celým souborem najednou. fpassthru(), readfile()

Více

Analýza publikačního systému. KÚ Zlínského kraje

Analýza publikačního systému. KÚ Zlínského kraje Příloha č. 0806-12-P07 Analýza publikačního systému KÚ Zlínského kraje 2006 AutoCont CZ a.s. Veškerá práva vyhrazena. Tento dokument obsahuje informace důvěrného charakteru a informace v něm obsaţené jsou

Více

Správa a sledování SOA systémů v Oracle SOA Suite

Správa a sledování SOA systémů v Oracle SOA Suite Správa a sledování SOA systémů v Oracle SOA Suite Marek Rychlý Vysoké učení technické v Brně Fakulta informačních technologií Ústav informačních systémů Přednáška pro IOA 7. října 2014 Marek Rychlý Správa

Více

Knihovna QT4 a moºnosti jejího vyuºití

Knihovna QT4 a moºnosti jejího vyuºití Fakulta jaderná a fyzikáln inºenýrská ƒeské vysoké u ení technické v Praze 2.6.2010 Osnova 1 Úvod 2 Seznámení s Qt4 3 Prost edí QtCreator 4 Vyuºití v praxi Problém Aplikace pro ovládání realtime PCR za

Více

HEIS VÚV V ROCE 2006 Jiří Picek Klíčová slova Hydroekologický informační systém VÚV T.G.M. (HEIS VÚV) je centrálním informačním systémem odborných sekcí ústavu. Jeho hlavním posláním je zajištění zpracování,

Více

8.2 Používání a tvorba databází

8.2 Používání a tvorba databází 8.2 Používání a tvorba databází Slide 1 8.2.1 Základní pojmy z oblasti relačních databází Slide 2 Databáze ~ Evidence lidí peněz věcí... výběry, výpisy, početní úkony Slide 3 Pojmy tabulka, pole, záznam

Více

Modelování procesů s využitím MS Visio.

Modelování procesů s využitím MS Visio. Modelování procesů s využitím MS Visio jan.matula@autocont.cz Co je to modelování procesů? Kreslení unifikovaných či standardizovaných symbolů, tvarů a grafů, které graficky znázorňují hlavní, řídící nebo

Více

Návrhové vzory. Jakub Klemsa, Jan Legerský. 30. října Objektově orientované programování.

Návrhové vzory. Jakub Klemsa, Jan Legerský. 30. října Objektově orientované programování. Jakub Klemsa Jan Legerský Objektově orientované programování klemsjak@fjfi.cvut.cz jan.legersky@gmail.com 30. října 2012 návrhový vzor (design pattern) obecné řešení problému, které se využívá při návrhu

Více

PV239/WP. Vývoj univerzálních Windows Store aplikací. Mgr. David Gešvindr MCSD: Windows Store MCSE: Data Platform MCT MSP gesvindr@mail.muni.

PV239/WP. Vývoj univerzálních Windows Store aplikací. Mgr. David Gešvindr MCSD: Windows Store MCSE: Data Platform MCT MSP gesvindr@mail.muni. PV239/WP Vývoj univerzálních Windows Store aplikací Mgr. David Gešvindr MCSD: Windows Store MCSE: Data Platform MCT MSP gesvindr@mail.muni.cz Cíle kurzu Osnova kurzu 1. Seznámení s platformou a nástroji

Více

D R U P A L V O J T Ě C H K U S Ý @ W O J T H A www.vojtechkusy.cz

D R U P A L V O J T Ě C H K U S Ý @ W O J T H A www.vojtechkusy.cz DRUPAL VOJTĚCH KUSÝ @WOJTHA www.vojtechkusy.cz KDO JSEM D R U P A L V Ý V O J Á Ř / E V A N G E L I Z Á T O R & P H D. S T U D E N T postgraduální studium na ČVUT FSV Katedra inženýrské informatiky Obor

Více

VÝVOJ INTERNETOVÝCH APLIKACÍ - VIA

VÝVOJ INTERNETOVÝCH APLIKACÍ - VIA Metodický list č. 1 Způsob zakončení : Úvod Technologie webových aplikací Protokol HTTP Po zvládnutí tématického celku bude student mít základní přehled o problematice programování internetových (webových)

Více

ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická. Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy

ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická. Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy Bc. Petr Pokorný Letní semestr 2009/2010 1 Obsah 1 Úvod... 3 2 Workflow... 3 3 Workflow

Více

Rozhraní pro práci s XML dokumenty. Roman Malo

Rozhraní pro práci s XML dokumenty. Roman Malo Rozhraní pro práci s XML dokumenty Roman Malo Práce s XML dokumenty Datově a dokumentově orientované XML dokumenty Problém preference elementů a atributů Strom elementů Strom uzlů Základní zpracování dokumentů

Více

Editor pro vizualizaci interiérů bytů

Editor pro vizualizaci interiérů bytů České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce Bakalářská práce Editor pro vizualizaci interiérů bytů Dominik Vondráček Vedoucí práce: Ing. David Sedláček

Více

Softwarový projekt Vyhodnocovač a zobrazovač meteorologických dat

Softwarový projekt Vyhodnocovač a zobrazovač meteorologických dat Softwarový projekt Vyhodnocovač a zobrazovač meteorologických dat Stručný popis: vyhodnocovač a zobrazovač environmentálních (převážně meteorologických) dat s webovým uživatelským rozhraním. Úvod Cílem

Více

VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika

VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika Šablonovací systémy a MVC architektura ve webových aplikacích bakalářská práce Autor: Michal Novotný

Více

Univerzita Karlova v Praze Matematicko-fyzikální fakulta BAKALÁŘSKÁ PRÁCE. Petr Vávro. Šablonovací systém pro generování textových dokumentů

Univerzita Karlova v Praze Matematicko-fyzikální fakulta BAKALÁŘSKÁ PRÁCE. Petr Vávro. Šablonovací systém pro generování textových dokumentů Univerzita Karlova v Praze Matematicko-fyzikální fakulta BAKALÁŘSKÁ PRÁCE Petr Vávro Šablonovací systém pro generování textových dokumentů Katedra softwarového inženýrství Vedoucí bakalářské práce: RNDr.

Více

Metody popisu systému, základy UML

Metody popisu systému, základy UML Metody popisu systému, základy UML Strukturovaný přístup Klasickou metodou analýzy a návrhu informačních systémů je strukturovaný přístup, navržený v 70. letech (Tom DeMarco, Ken Orr, Larry Constantine,

Více

(Enterprise) JavaBeans. Lekce 7

(Enterprise) JavaBeans. Lekce 7 (Enterprise) JavaBeans Lekce 7 JavaBeans vs. Enterprise JavaBeans (EJB) JavaBeans technologie: jedná se o tzv. komponentní architekturu určenou pro JSE platformu určená pro tvorbu JSE GUI programů pomocí

Více

Optimalizace podnikových procesů fakultní nemocnice

Optimalizace podnikových procesů fakultní nemocnice Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií Optimalizace podnikových procesů fakultní nemocnice diplomová práce Autor: David Lísal BIVŠ ITMK Informační

Více

Katalog služeb a podmínky poskytování provozu

Katalog služeb a podmínky poskytování provozu Příloha č. 1 Servisní smlouvy Katalog služeb a podmínky poskytování provozu Část P2_1 P2_1_Katalog služeb a podmínky poskytování provozu 1 Obsah 1 OBSAH... 2 2 DEFINICE POJMŮ... 3 3 DEFINICE SLUŽEB, KOMPONENT

Více

SYSTÉM PRO KONFIGURACI KOMUNIKAČNÍCH TERMINÁLŮ A VIZUALIZACI STAVOVÝCH DAT Z KOLEJOVÝCH VOZIDEL

SYSTÉM PRO KONFIGURACI KOMUNIKAČNÍCH TERMINÁLŮ A VIZUALIZACI STAVOVÝCH DAT Z KOLEJOVÝCH VOZIDEL SYSTÉM PRO KONFIGURACI KOMUNIKAČNÍCH TERMINÁLŮ A VIZUALIZACI STAVOVÝCH DAT Z KOLEJOVÝCH VOZIDEL SYSTEM FOR CONFIGURATION OF COMMUNICATION TERMINALS AND VISUALIZATION OF STATE INFORMATION FROM RAIL VEHICLES

Více

ZÁVAZNÉ POKYNY PRO VYPRACOVÁNÍ BAKALÁŘSKÉ, DIPLOMOVÉ A DISERTAČNÍ PRÁCE

ZÁVAZNÉ POKYNY PRO VYPRACOVÁNÍ BAKALÁŘSKÉ, DIPLOMOVÉ A DISERTAČNÍ PRÁCE ZÁVAZNÉ POKYNY PRO VYPRACOVÁNÍ BAKALÁŘSKÉ, DIPLOMOVÉ A DISERTAČNÍ PRÁCE Bakalářskou/diplomovou prací se ověřují vědomosti a dovednosti, které student získal během studia a jeho schopnosti využívat je při

Více

Využití modelovacích nástrojů ve vývojářské firmě

Využití modelovacích nástrojů ve vývojářské firmě Vysoká škola ekonomická v Praze IT_572 Prostředky CASE a jejich využití při tvorbě IS Využití modelovacích nástrojů ve vývojářské firmě 11. prosince 2005 Jiří Pelc Petr Medřický Michal Pešička 1.Obsah

Více

ADMINISTRACE POČÍTAČOVÝCH SÍTÍ. OPC Server

ADMINISTRACE POČÍTAČOVÝCH SÍTÍ. OPC Server ADMINISTRACE POČÍTAČOVÝCH SÍTÍ OPC Server Funkce a využití v průmyslové automatizaci Jiří NOSEK 2011 Co je OPC Server? OPC = Open Process Control (původně OLE for Process Control) sada specifikací průmyslového

Více

Naučit se, jak co nejsnadněji přejít od verze TopoLu pro Windows k verzi TopoL xt. Cílem není vysvětlení všech možností programu.

Naučit se, jak co nejsnadněji přejít od verze TopoLu pro Windows k verzi TopoL xt. Cílem není vysvětlení všech možností programu. Školení programu TopoL xt Přechod na TopoL xt z programu TopoL pro Windows Cíl: Obsah: Naučit se, jak co nejsnadněji přejít od verze TopoLu pro Windows k verzi TopoL xt. Cílem není vysvětlení všech možností

Více

BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS STANISLAV SEHNAL

BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS STANISLAV SEHNAL 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 WEBOVÉ ROZHRANÍ

Více

Obsah. Položkování 1: Prefix dřívějších osamocených dílů se zachovává...23 Položkování 2: Editace předběžných čísel...23

Obsah. Položkování 1: Prefix dřívějších osamocených dílů se zachovává...23 Položkování 2: Editace předběžných čísel...23 Obsah VÍTEJTE V ADVANCE STEEL 2013, ČÁSTÍ ŘEŠENÍ GRAITEC BIM... 5 ADVANCE CAD DOSTUPNÁ 64BITOVÁ PLATFORMA... 6 VYLEPŠENÍ PLATFORMY ADVANCE CAD 2013... 7 NOVÁ PALETA NÁSTROJŮ... 8 MODELOVÁNÍ... 9 Modelování

Více