1 Detaily tvorby Windows aplikací

Transkript

1 1 Detaily tvorby Windows aplikací 1.1 Úvod Ačkoliv pod skupinou Windows desktopových aplikací rozumíme aplikace dvou typů (nezpracovávající nebo zpracovávající bázi dat), je většinou úsilí orientováno na vytvoření Windows desktopové aplikace typu klient server, kde klient je tlustý klient reprezentovaný Windows desktopovou aplikací a server je databázovým serverem. Na databázovém serveru je uložena báze dat, kterou může v síti podniku (síť LAN/WAN/INTERNET) využívat více uživatelů přes vytvořené aplikace, viz následující obrázek. tlustý klient 1 tlustý klient n Windows aplikace 1 Windows aplikace n počítač 1 počítač n síťová komunikace LAN/WAN/internet Databázový server BD Obrázek 1: Ilustrace postavení Windows destopových aplikací pro zpracování téže báze dat Oba typy aplikací se liší jen problematikou zpracování báze dat. Jeden typ zpracovává, jiný ne. Technologie pro zpracování BD mohou být různé ( např. technologie ADO.NET, ). Začneme proto vývojem GUI a později, v další přednášce, přidáme vývoj komunikace s bází dat. První kroky ve vývoji Windows desktopové aplikace Tvorba windows aplikace ve VB.NET se zdá ze začátku velmi jednoduchá. Ano, je to pravda díky tomu, že VB má velmi mocné nástroje realizující bez napsání kódu rozsáhlé aktivity, např. ve zpracování databázové informace. Pochopitelně, méně se již síla těchto prostředků projeví při tvorbě zastaralých souborových aplikací. Tyto silné prostředky jsou zabudovány v tzv. ovládacích prvcích (vestavěných, ze systémových a uživatelských knihoven), které dokážou organizovat nejen flexibilní spojení s různými typy BD, ale dokážou požadovaná data získat, vizualizovat a zpracovat. Vše je ovšem záležitostí platformy.net Framework. S vizualizací se setkáváme na všech úrovních tvořené aplikace. - 1

2 Základními prvky vizualizace jsou především formuláře a zmíněné vestavěné ovládací prvky GUI ( příkazová tlačítka, přepínače, zaškrtávací políčko, časovač, ), datové prvky ( textové pole, popisovač, seznamy, datové mřížky, ) a grafické prvky ( čáry, geometrické obrazce, obrázky, ). Souhrn těchto prvků ve vytvářené aplikaci potom formuje tzv. grafické rozhraní GUI ( Graphical User Interface ), které bude uživatel používat nejen pro ovládání aplikace, ale i pro zpracování dat. Pro zavedení ovládacích prvků na formuláře není potřeba psát žádný kód, stačí je na formuláře přenášet z dostupných panelů. Kód ale bude nutné psát pro zachycení reakcí na různé události ( událostní programování ), k nimž může u ovládacích prvků dojít ( např. Zápis nového textu do prvku textové pole, předznačení přepínače,.). Vedle toho se některé prvky (příkazová tlačítka, prvky menu, uživatelské panely a jejich ikony,...) použijí k řízení spuštění vybrané funkcionality v aplikaci. Hlavní roli potom hraje jejich událost Click a kód spouštěné funkcionality uložený v reakční proceduře na událost Click. Vytváření těchto událostních procedur, je ve VB.NET ale značně automatizováno. Vizualizační prvky GUI umožní i začátečníkovi rychle sestrojit aplikaci s hodnotnou vizualizací zpracování databázových dat. Postup tvorby aplikace Vycházejme z toho, že programátor má materiál Zadání pro programátora (jeden z výsledeků fáze Hrubý a detailní návrh strukturované metodiky) anebo si analýzu tvorby aplikace provedl sám a jen s použitím softwarové metodiky. Pokusme se teď vystihnout základní obecné úkoly při tvorbě jednoduché Windows aplikace (aplikace založená na zvláštních Windows formulářích). Tvorba takové aplikace spočívá ve splnění několika základních úkolů: 1. Zahájení tvorby aplikace. 2. Tvorba GUI rozhraní aplikace, které bude používat uživatel aplikace. 3. Nastavení vlastností použitých ovládacích prvků, tvorba událostního kódu. 4. Tvorba business kódu (vycházející z analýzy procesů podniku) a jeho členění mezi pro jednotlivé formuláře (přesněji kódové listy formulářů) a návrh systému řízení v aplikaci na základě přechodů mezi formuláři. 5. Uložení a ukončení tvorby aplikace. Zahájení tvorby aplikace Zahájení se provede založením projektu pro naši aplikaci. To ale již známe z předchozí přednášky 3 Vývojové prostředí VB.NET, detaily. Tvorba rozhraní aplikace Podstatou návrhu rozhraní je návrh jednotlivých formulářů a přechodů mezi nimi. Návrh formuláře spočívá v jeho osazení plánovanými ovládacími prvky a v jejich propojení do logického celku. Základem je technika přenášení ovládacích prvků z integrovaného panelu ToolBox do formuláře. Základy použití ovládacích prvků jsou uvedeny v dalším textu této přednášky. Nastavení vlastností ovládacích prvků Každý prvek na formuláři má svou osobitou roli. Může se podílet na GUI ( je to prvek GUI ), na vizualizaci a zpracování dat. Z role ovládacího prvku na formuláři pak vychází hodnoty jeho vlastností. Základní vlastnosti nejčastěji používaných ovládacích prvků jsou uvedeny v této přednášce. - 2

3 Uložení a ukončení tvorby aplikace Prvky aplikace jsou uloženy v souborech aplikace. Zabezpečíme tedy, aby soubory odpovídali poslednímu stavu tvorby aplikace ( příkaz File-Save... resp. File-SaveAll) a zakončíme projekt aplikace uzavřením sezení s VB ( ikona v Titulovém řádku pracovní plochy prostředí VB.NET ). V přednášce 2 jsme klasifikovali typy aplikací, které je možno sestrojit ve vývojovém prostředí VB.NET. Bylo také řečeno, že pro naše školní účely bude první nejvhodnější windows aplikace klikačka klasická neobjektová, dvouvrstvá aplikace zpracovávající relační bázi dat, sloužící výlučně pro jeden počítač. Na následujícím obrázku, jsou ilustrovány základní rysy takové aplikace. Prvky GUI 1. vrstva ADO prvky pro správu dat datové asociace, události události kód Aktivitní (business) procedury události kód Událostní procedury Poskytovatel spojení Data BD Tabulky 2. vrstva Databázový server Obrázek 1-1 : Dvouvrstvová struktura klasické neobjektové Windows aplikace zpracovávající relační bázi dat. Co je GUI? Z hlediska uživatele aplikace je rozhodující její GUI (Graphical User Interface), tj. uživatelského rozhraní aplikace (uživatelský interface aplikace). Proto bude v této kapitole praktické tvorbě uživatelského rozhraní aplikací věnována mimořádná pozornost. Uživatelské rozhraní má své složení, funkci a poslání - význam. Všechny tyto tři složky charakteristiky uživatelského rozhraní spolu souvisí, vzájemně se ovlivňují. Implementace GUI je náročná a zdlouhavá, často podléhá dodatečným změnám. Co je vlastně GUI? Spokojme se s následující, i když ne úplně exaktní definicí. - 3

4 GUI je vše co uživatel vidí na obrazovce aplikace a co může bezprostředně používat při využití aplikace k počítačové podpoře svých profesních aktivit. Vizualizace je tedy jádro každého uživatelského rozhraní. Do funkcionality GUI běžně patří: poskytnutí vizuálního přehledu o stavu aplikace -ilustrace toho, kde v aplikaci uživatel je, co se děje, kam může dál v aplikaci pokračovat, -indikace chybného stavu aplikace, jaká má být reakce uživatele, -upozornění uživatele na jeho chybný krok a jak pokračovat, obecná manipulace s aplikací a její vizualizace -úvodní poučení o aplikaci, -přechody mezi různými funkcemi aplikace, -ukončení aplikace, vizualizace veškerých individuálních a databázových dat prostřednictvím vhodné grafiky -prezentace zpracovávaných dat, -prezentace výstupních dat, -zadávání vstupních dat. Za poslání GUI považujeme to, že vytváří pro uživatele přístupné možnosti pro snadné pochopení a využití funkcí aplikace k počítačové podpoře jeho profesních aktivit. GUI je to jediné, co uživatel z aplikace vidí. Uživatel nemá žádnou představu o kvalitě nebo nedostatcích kódu. Ze zkušeností můžeme říct, že využitelnost aplikace přímo závisí na jejím rozhraní. Složení GUI se liší pro každé dvě aplikace. Můžeme ale obecně říci, jaké stavební prvky v něm mohou být. Dále je důležité vědět jaké metody, techniky a nástroje jsou k dispozici pro vlastní proces tvorby GUI. Stavebními kameny jsou tzv. elementární a kontejnerové prvky GUI. Metody, techniky a nástroje pro tvorbu GUI Uživatelské rozhraní je realizováno využitím souhrnu metod, technik a nástrojů. Metody, techniky a některé nástroje bývají v pozadí ( nejsou vidět ), ale jiné nástroje jsou vizuální a výsledky jejich použití přechází rovnou do GUI. VB.NET poskytuje pro konstrukci GUI následující metody, techniky a nástroje: metodu událostního programování a kód událostních procedur, metodu objektového programování, techniku tvorby reakčních procedur, techniky práce s prvky GUI, nástroje panely pro elementární prvky GUI a samotné prvky vestavěné ovládací prvky, formuláře. - 4

5 Nástroje bychom mohli členit následovně: Prvky a tvorba GUI -dialogová okna, -nabídka ( menu ) na formuláři, -uživatelské panely nástrojů ( tlačítka-ikony ), -kontextové nabídky, -bublinové informace u ovládacích prvků a tlačítek-ikon v panelech nástrojů, -nápověda a její kontextové možnosti, -informace o stavu aplikace ( stavové řádky, stavové grafy řízení ). Za prvky GUI považujeme : elementární prvky nekontejnerové ovládací prvky, informační bublinky strukturované prvky kontejnerové ovládací prvky ( formulář - Form, rámeček - Frame, obraz Picture ), nabídka menu, kontextová nabídka, horké klávesy, dialogová okna, uživatelské panely nástrojů, nápověda aplikace, stavový řádek. Souhra všech prostředků je pro výslednou podobu GUI rozhodující. Pomocí technik může zručný programátor konstruovat z elementárních prvků GUI poměrně složité grafické prvky. Následující obrázek ilustruje pohled na tvorbu GUI. Zadání pro programátora Zdroj Návrh GUI Implementace Zdroj Reálně fungující GUI aplikace Aplikace Metody, techniky a nástroje Obrázek 1-2: Celkový postup tvorby GUI. - 5

6 Role Zadání pro programátora Než programátor začne tvořit GUI, musí mít velmi podrobně prostudováno Zadání pro programátora. Tam se programátor dozví nejen charakteristiku problémové domény, ale i charakteristiku aplikace a uživatele. Zadání obvykle reaguje v hrubém a detailním návrhu GUI na vyspělost uživatele. Pro začátečníka musí být základní vlastností GUI jeho jednoduchost. Tomu musí odpovídat i ovládací prvky v GUI, jako nabídka menu, uživatelské panely nástrojů, Na základě Zadání pro programátora je programátor dostatečně informován, jestli se aplikace bude používat neustále nebo jen příležitostně, je-li určena individuálně pro jeden počítač nebo pro více počítačů v síti. Pochopitelně, Zadání je integrovaný seznam informace pro programátora a po jeho uplatnění dostává GUI zcela výraznou podobu. Na druhé straně, kvalita Zadání silně ovlivňuje programátorskou práci, nesmí ji znásilňovat, ani voluntarizovat. Proto by Zadání nemělo být doslovným předpisem co dělat a jak to dělat, nemělo by být ani úplně volné. Mělo by vyvolat kreativní přístup programátora. 1.2 Styly rozhraní Mnoho z programátorů má zkušenosti z používání aplikací zařazených do všeobecné počítačové gramotnosti. Patří sem i aplikace balíku Microsoft Office. Např. obrazovka aplikace Excel 2000 je okupována obrovským rodičovským oknem, ve kterém je řada dílčích dětských oken. Jsou to drobná okna pro hlavní řádek menu, okna pro panely nástrojů, okno pro řádek vzorců, okna pro dokumenty sešity tabulek a okno pro stavový řádek. Všechna tato okna jsou formuláře. Excel 2000 musí uživateli dát možnost přepínat se mezi okny a zejména mezi okny dokumentů. K tomu má speciální menu Okno / Window. Jedno z dětských oken Rodičovské okno Obrázek 1-3 : Rodičovské okno aplikace Excel 2000 a jeho dětská okna. - 6

7 Takové rozhraní, jaké má Excel 2000 se označuje zkratkou MDI ( Multiple Document Interface ). Toto rozhraní je náročné na udržování velikosti dětských oken a vztahů ( děti-rodič, děti-děti ). Pohyb dětských oken je jen v poli mateřského okna. Jednoduší aplikace jako WordPad, Malování,... mají v rozhraní jen okno jednoho dokumentu. Nebo jsou aplikace i s více okny na obrazovce, ale vztahy mezi nimi jsou v podstatě velmi volné. Je to rozhraní typu SDI ( Single Document Interface ). Styl SDI je rozšířenější. Jaké rozhraní pro aplikaci zvolit závisí od jejího charakteru, tj. charakteru ústředního dokumentu (-ů ) a počtu událostí a jejich transakcí na kterých se musí najednou pracovat. Bankovní makléř potřebuje pracovat najednou na více souvisících transakcí, ale finanční účetní stačí práce na jedné faktuře. S rozvojem aplikací typu "Browser prohlížeč" a "Explorer - průzkumník" dynamických stránek HTML nebo zdrojů systému, se objevují rozhraní typu "Explorer" a rozhraní typu "Browser". Tato rozhraní jsou často používána v některých atypických oknech ( okno diskůsložek-souborů, okno domovské stránky, ). Rozhraní MDI Toto rozhraní podporuje vytvářet aplikace s více dětskými formuláři v jednom rodičovském, který je jejich kontejnerem. Aplikace s MDI je schopna zobrazit najednou více formulářů se samostatnými dokumenty v každém okně. Rodičovské okno je pracovní plocha pro všechna dětská okna. Minimalizace dětského formuláře vede na umístění jeho ikony na dně rodičovského formuláře. Rodičovský formulář je MDI formulář a může být v aplikaci jen jeden. Vedle dětských formulářů může být v aplikaci i standardní formulář. Pracovní prostředí MDI Minimalizovaný Sešit 3 Obrázek 1-4 : Dětské formuláře, jeden z nich je minimalizovaný. - 7

8 Rozhraní SDI Toto rozhraní je častěji používáno a většina příkladových aplikací, jak v uveřejněných publikacích, tak v těchto skriptech, je sestrojena na jeho bázi. V tomto rozhraní žádný z formulářů nehraje roli rodičovského s více dětskými formuláři, které by se měli zobrazovat jen v rámci rodičovského okna. Z použitých formulářů je jeden obvykle úvodní, jeden řídící a ostatní služební. Přechody mezi formuláři jsou dány scénářem řízení, jenž je zakreslen ve tvaru orientovaného grafu. Uzly grafu jsou formuláře a na ohodnocenou hranu se obvykle píše událost, která vyžaduje přechod mezi formuláři. Pro přechody je možno použít techniky příkazových tlačítek. Příklad 7-1 : Aplikace Zájem o auto má čtyři formuláře frmúvodní, frmřídící, frmprohlíženíaut a frmvýběrauta. Aplikace umožní zákazníkovi prohlížení aut různých značek, jejich doplňků a nakonec i výběr auta s propočtením ceny podle vybraných doplňků. Pro přechody mezi formuláři jsou použity události Click na tlačítka Řízení, Prohlížení aut, Výběr auta a Návrat. Scénář řízení přechodů mezi formuláři je jednoduchý : frmúvodní S T A R T S T O P frmřídící frmprohlíženíaut frmvýběrauta tlačítko pro přechod Obrázek 1-5 : Scénář řízení v aplikaci Zájem o auto. 1.3 Struktura formulářové Windows aplikace Máme již připraven veškerý potřebný materiál o formulářích, ovládacích prvcích na nich a stylech GUI, založených na polohách a spolupráce formulářů. Můžeme teď pohovořit o struktuře aplikace ve formulářích a systému vnitřního řízení - přechodů mezi formuláři. Struktura aplikace Z praxe poznáme několik typů struktury aplikace. My se budeme orientovat na dva nejvýznamnější: 1. Začínající tzv. úvodním formulářem ( Splash Form ) a pokračující dalšími formuláři, jeden z formulářů je řídící ( Main Form ), START Úvodní formulář Řídící formulář STOP formuláře formuláře - 8

9 začínající speciální procedurou Main a pokračující na dalších formulářích včetně úvodního. Procedura Main Úvodní formulář START Řídící formulář STOP formuláře Obrázek 1-6: Dvě nejčastěji používané struktury aplikací. Úvodní formulář by měl být velmi působivý, aby uživatele maximálně zaujal a ne odradil od dalšího zájmu o aplikaci. Splní-li úvodní formulář svoji plánovanou roli, je uživatel nedočkavý co bude dál. Co by měl úvodní formulář obsahovat? Můžeme doporučit následující grafické prvky : výrazné logo tvůrce aplikace, název aplikace a stručný popis její funkcí, ukázka struktury přechodů mezi funkcemi aplikace, Pro návrh úvodního formuláře je potřebné mít jistý cit pro barvy, grafiku a reklamu. Ze začátku je dobré se tomu učit na úvodních formulářích profesionálně vytvořených aplikací ( pro Business problematiku, vývojová prostředí, ) od věhlasných firem jako Microsoft, Bourland,.( podívejte se na aplikace MSO, na samotné VISUAL STUDIO, DELPHI, ). Vnitřní řízení v aplikaci Vnitřní řízení v aplikaci je dáno pomocí přechodů mezi formuláři. To je ale velmi hrubá myšlenka. Pro objasnění řízení je nutno se vrátit k Zadání pro programátora. Zde je pro programátora uveden seznam řetězců událostí. Každý řetězec představuje začátek, průběh a konec užitné činnosti v problémové doméně. Řetězec je složen z prvků p 1, p 2,,p n, přičemž každý prvek p i je trojice [ událost, transakce/proces, formulář]. Základem trojice je formulář. Transakce/proces jsou zapsány v kódu na kódovém listě formuláře. p 1 p 2 p 5 p n - 9

10 Z toho tedy plyne, že programátor musí : Obrázek 1-7 : Řetězec událostí a transakcí. 1. provést spuštění řetězce, 2. řídit potenciální přechody z předchozího na následující prvek a 3. zabezpečit ukončení řetězce. Ve VB.NET existují velmi příjemné techniky, jimiž je možno řízení každého řetězce zabezpečit. Spuštění řetězce je možno provést : použitím volby v menu, pomocí příkazových tlačítek, pomocí ikon umístěných v panelech. Technika zabezpečení přechodů mezi prvky řetězce závisí od techniky spouštění prvku řetězce. Např. spouští-li se jednotlivé prvky řetězce pomocí menu, tak programátor musí zabezpečit, aby v menu byly postupně přístupné jen volby pro spouštění prvků nastartovaného řetězce a žádné jiné. Stejnou zásadu je možno uplatnit na ikony panelů, nebo na příkazová tlačítka. Zanedbání této podmínky může vést k nekorektnímu zpracování informace nezkušeným uživatelem. 1.4 Filosofie návrhu uživatelského rozhraní Praxe ukazuje, že uživatelské rozhraní aplikace má značný vliv na úspěch aplikace v praxi. Mnohé softwarové firmy mají dnes již zkušenosti s návrhem rozhraní jimi vytvořených aplikací. Tyto zkušenosti se často stávají neprodejným majetkem jednotlivých firem, protože tvoří součást jejich Know-How pro produkci aplikací. Pokusíme se zde, ve formě tezí, dát drobné rady začínajícím tvůrcům aplikací. Měj neustále na mysli, že aplikace je pro uživatele a ne pro Tebe. Snaž se pochopit způsob přístupu uživatele k používání aplikace a dbej, aby všem doprovodným textům uživatel snadno porozuměl. Přesvěč uživatele, že může používat stejný pracovný postup a navíc s kvalitní podporou počítače pro jednotlivé obtížné operace. Nesnaž se udělat z rozhraní barevnou koroptev. Barvy používej přiměřeně, s ohledem na délku života barvy na obrazovce a s ohledem na jejich vhodné kombinace. Základní principy kompozice, skladby barev se vztahují stejně na obrazovku jako na papír. Zvaž umístění ovládacích prvků na formuláři, zejména těch, které se často používají, a zabezpeč jejich rychlé a pohodlné použití. Starej se o jednotný vzhled všech formulářů, použitím všech ovládacích prvků neprokazuješ své kvality Uprav formuláře tak, aby uživatel cítil jejich soulad po mnoha charakterových stránkách ( kompozice barev, velikosti, typy ovládacích prvků, pozice řídících ovládacích prvků, ). Nepoužívej širokou paletu ovládacích prvků. Umožni uživateli navyknout si rychle na používání typické, pro aplikaci vhodné skupiny. Dbej o to, aby byla funkce jednotlivých ovládacích prvků zcela viditelná a hned pochopitelná. Nadefinuj si předem styl formulářů a pak ho dodržuj v celé aplikaci. - 10

11 Neotálej s přiměřeným spestřením své aplikace Obrázky a ikony mohou vnést do rozhraní jistou pestrost. Dávej ale jen takové obrázky, které mají velký informační obsah, těsně souvisící s aktuální činností aplikace. Ikony navrhni tak, aby zcela jasně identifikovaly operace, které vyvolávají. Inspirace z prostředí aplikací jiných firem se vždy doporučuje. Rozhraní nenavrhneš za 10 minut Drž se Zadání pro programátora. Uvědom si, že po prvotním návrhu rozhraní nastává období jeho dalších vylepšování a dozrávání do finální podoby vhodné pro uživatele. Dej své rozhraní vyzkoušet několika skupinám uživatelů. Zpracuj jejich náměty, nepodceňuj je! Zvaž, jestli není potřeba brát v úvahu obsluhu aplikace atypickým uživatelem. Pochopitelně, těchto několik rad dává jen orientační představu o problémech spjatých s rozhraním aplikace. Proces učení se návrhům rozhraní je dlouhodobý. Závěr. Poměrně rozsáhlá přednáška dává základní poznatky o prvcích GUI aplikací, o postupu tvorby GUI a o jednotlivých stylech rozhraní. Formuláře jsou považovány za základ GUI a proto je jim věnována velká péče. Z toho důvodu je také podána filosofie použití prvků formulářů, zejména tlačítek, prvků menu a panelů. Je vysvětlena struktura aplikace a podstata vnitřního řízení. TEORIE O GUI APLIKACE TEORETICKÝ PŘÍSTUP K TVORBĚ UŽIVATELSKÉHO ROZHRANÍ SOFTWAROVÝCH SYSTÉMŮ A graphical user interface (GUI) of any web-based object or classical structural enterprise business software constantly hasn t lost its user importance. It really stays as a one of very relevant manners for a client communication with any contemporary developed software units (programs, applications, modules and Software Complex Systems). In addition to this mission, every GUI is regarded as a one of three considerable basic software unit layers. GUI units can be inherently positioned inside software units or we can separate them and construct a special GUI system over GUI units. Naturally, we have to define a manner of communication between software units and GUI units. This approach enables, on a system platform, to investigate not only structure and functionality of GUI units, but also relations among them. We can use the system platform on three levels, a theoretical level, a level of GUI modeling and a level of GUI development. Especially the theoretical investigation of the GUI system can bring for analysts and developers-programmers a new knowledge about the GUI units behavior and relations. It can equip them by very detailed information about formal tools concerning any GUI system functionality description and help them to improve a process of GUI system construction. GUI unit, GUI system, GUI resources, GUI modeling techniques, GUI functionality, GUI relations, GUI development techniques - 11

12 Uživatelské rozhraní představuje jednu ze základních vrstev každého složitého programového vybavení, tedy rovněž business software podnikového informačního systému (PIS). Mluví se o tom, že mnohé z jednotek GUI (GUI units) jsou asociovány s jistými podnikovými procesy/službami, z jejichž funkcionalit vycházejí. Pochopitelně, existují rovněž jednotky GUI asociované s nepodnikovými procesy/službami. Informační a Softwarové inženýrství poskytují ve svých metodikách rovněž metody, techniky a nástroje pro modelování a implementaci uživatelského rozhraní. Problematiku GUI můžeme vedle rovin modelování a implementace zkoumat rovněž v teoretické systémové rovině a doplnit obě zmíněné roviny o cenné obecné poznatky. Uvedené roviny sledují zejména následující cíle: 1. Rovina teoretická systémová. V této rovině je GUI složitého business software chápáno především jako systém, postavený na tzv. jednotkách GUI, které jsou svázány jistými interními vazbami relacemi. Systém GUI jednotek (GUI System) má okolí, ve kterém jsou podnikové procesy nebo podnikové služby a klienti informačního systému. Vedle již zmíněných interních vazeb potom existují rovněž vazby externí na prvky v okolí. Systém GUI jednotek je cílevědomě analyzován poznáván, určuje se jeho struktura (prvky a vazby) a jeho funkcionalita. Cílem uplatnění systémové roviny je tedy oddělení jednotek GUI od zdrojových podnikových procesů/služeb, z nichž vycházejí a analýza jejich interních a externích vazeb. Formalizace zmíněných vazeb a jejich grafická vizualizace může vést k modelu, který je výchozím pro rovinu modelování a odrazí se rovněž v rovině implementační. Jinými slovy, výsledky teoretické roviny by měly ovlivňovat obě dvě zbývající roviny. 2. Rovina modelování reálného systému GUI. Tato rovina zahrnuje analýzu návrhu jednotek GUI, které vycházejí z podnikových procesů/služeb. Výchozí jsou výsledky předchozí systémové roviny. Analytik, který pochopil podnikové a nepodnikové procesy/služby, využije současných metod, technik a nástrojů pro vytvoření modelu systému GUI. Vzniklý model v UML jazyku je potom základem pro implementační rovinu. 3. Rovina implementační. Je to rovina fyzického návrhu GUI a jeho realizace s ohledem na plánovanou architekturu podnikového aplikačního software (business software). Implementace probíhá buď výlučně na platformě jednoho ze známých modelovacích a implementačních paradigmat (strukturovaný klasický přístup, objektový přístup), anebo je smíšená. V souvislosti s vybraným paradigmatem se rovněž vybírá konzistentní vývojové prostředí pro software PIS a jeho GUI. Vývoj GUI systému je týmová záležitost, ale rozhodující roli hrají systémový architekt PIS (System Architect), systémový analytik (System Analyst), business analytik (Business Analyst) a implementační vývojář (Developer). Obr. 1 dokumentuje vztah členů týmu a jednotlivých rovin zkoumání problematiky GUI. System architect System analyst Business analyst Developer Theoretical - system level GUI modeling level Implementation level 1: Účast v jednotlivých rovinách vývoje GUI - 12

13 Ačkoliv jednotky GUI vystupují v GUI systému jako nedělitelné celky, přesto je v implementační rovině významná jejich výstavba pomocí tzv. elementárních jednotek GUI (tlačítko, textové políčko, seznam,...) a rovněž je významná vnitřní struktura a vazby mezi elementárními jednotkami. Stavební elementární GUI jednotky jsou v mnoha vývojových prostředích instancemi vestavěných objektových tříd a mohou se standardně používat. GUI jednotky potom působí jako ucelené kontejnery vzájemně svázaných instancí elementárních jednotek GUI, přičemž tato struktura a vazby ovlivňují strukturu komunikačního interface každé jednotky GUI. Tato problematika není v příspěvku rozebírána. Pokusme se teď dát odpovědi na dvě otázky: 1. Co vše má vliv na vyvíjené GUI jednotky business software? 2. Co vše ovlivňuje vývoj GUI jednotek? Vyvíjené GUI jednotky jsou ovlivňovány: architekturou business software PIS podnikovými/nepodnikovými procesy/službami interními vazbami mezi jednotkami GUI a externími vazbami mezi jednotkami GUI a procesy/podnikovými službami rozsahem stavebních elementárních jednotek GUI vývojového prostředí. Mezi vlivy na vývoj GUI jednotek musíme řadit: teoreticko systémové poznatky techniky a nástroje modelování použité vývojové paradigma a jeho metody, techniky a nástroje. Problematiku obou odpovědí rozvineme v následujících kapitolách. MATERIÁL A METODY Současný podnikový business software je postaven na jedné z dvou architektur: aplikační architektuře (AA) nebo servisně orientované architektuře (SOA). Architektura AA používá jako nejnižší programovou jednotku klasickou softwarovou aplikaci. Vyšší jednotky balíky a nižší balíčky aplikací jsou vystavěny na aplikacích náležejících k témuž procesnímu setu (ERP, SCM, CRM, BI,...), resp. procesnímu subsetu. Podnikový aplikační software je potom popisován skupinou symbolických rovnic: BS = PA ERP PA SCM PA CRM PA BI hlavní strukturální rovnice, PA ( i ) = PCA 1 ( i ) PCA 2 ( i )... PCA k ( i )... rovnice struktury balíků BS... označení business software PA (i)... označení aplikací pro libovolný procesní set PCA (i)... balíček aplikací pro jeden procesní subset. Dále, i {ERP, SCM, CRM, BI,...}, k N, k 1 Pro vývoj GUI jednotek se používají vestavěné grafické editory a klasické skriptové programování. Elementární stavební GUI jednotky mají ovšem objektovou povahu a vznikají jako instance vestavěných objektových tříd ve vývojovém prostředí. U architektury AA jsou - 13

14 GUI jednotky pevně spjaté s podnikovými procesy, nemají samostatnou povahu a jejich modifikace je náročnější než v architektuře SOA. Pro servisně orientovanou architekturu je zdrojem tzv. servisně orientovaná architektura podniku (SOE Service Oriented Enterprise) postavená na podnikových službách. Každá podniková služba může obsahovat transakci nebo jeden a více podnikových procesů spojených na základě výsledku work-flow analýzy. Podnikový business software je potom založen na volání komputerizovaných podnikových služeb, které mohou být interní (podnikové) a externí (podniku poskytované). Obecně je možné realizovat zabalení odkazů na komputerizované podnikové služby opět do aplikací a shromáždit aplikace do balíčků a balíků podle procesních subsetů a setů. Podnikový business software je potom popisován následující skupinou symbolických rovnic: BS = PS ERP PS SCM PS CRM PS BI hlavní strukturální rovnice PS ( i ) = PCS 1 ( i ) PCS 2 ( i )... PCS k ( i ) rovnice struktury balíků PS (i)... balík aplikací pro podnikové služby jednoho procesního setu PCS (i)... balíček aplikací pro podnikové služby jednoho procesního subsetu. Servisně orientovaná architektura podnikového business software je založena na webové platformě a objektovém paradigmatu. Objektové paradigma plně ovlivňuje rovněž implementaci každé GUI jednotky, která je asociovaná s jistou podnikovou službou a spolupracuje s ní na základě komunikačního protokolu a je od ní oddělena. Tedy, nejen pro každou komputerizovanou podnikovou službu se deklaruje jistá třída, ale podobně to bude i pro každou jednotku GUI. Pro další úvahy, týkající se implementační roviny, budeme zásadně uvažovat jen SOE a implementační SOA architekturu. To nám umožní zavést implementační třídy a instance pro jednotlivé podnikové služby a totéž pro jednotky GUI. Tím se rovněž v implementační rovině, a nejen v teoretické a rovině modelování, oddělí podnikové služby od asociovaných jednotek GUI. Filozofie GUI systému Vysoká společenská poptávka na komputerizaci reálných procesů ve společnosti, školách, podnicích apod. silně evokuje snahy informatiků urychlit a zkvalitnit vývoj software a přinést do směru RAD (Rapid Application Development) nové metody, techniky a nástroje. Současné dva směry, zahrnuté v RAD, mají odlišnou orientaci. První se orientuje na tvorbu nových metodik pro vývoj software a jeho řízení, kdežto druhý se orientuje na metody, techniky a nástroje urychlující a zkvalitňující vývoj základních vrstev software. To se pochopitelně týká i vrstvy prezentační, jejíž základem je GUI. Pokusíme se proto analyzovat situaci vztahu business software a z něj vyděleného GUI, založeného na GUI jednotkách asociovaných s podnikovými aktivitami, přesněji podnikovými službami, které jsou základem již zmíněné softwarové architektury SOA. Formální pohled na GUI systém Hlavním zdrojem GUI podnikového business software s architekturou SOA jsou podnikové a nepodnikové služby, vytvořené z podnikových a nepodnikových procesů nebo transakcí. Mnoho nepodnikových služeb vznikne právě v době návrhu business software. - 14

15 Každá GUI jednotka je potom asociovaná alespoň s jednou podnikovou nebo nepodnikovou službou. Proč chceme mluvit o GUI systému? Jsou pro to některé relevantní důvody? Ano, jsou. Např. jimi mohou být následující důvody: 1. GUI jednotky jsou celky, které můžeme považovat za prvky jistého systému a na těchto prvcích definovat strukturu systému. 2. GUI jednotky mají vzájemné vazby relace, dále mají vazby na okolí GUI systému ve kterém jsou podnikové služby a klienti služeb. 3. GUI jednotky lze využívat různými podnikovými/nepodnikovými službami a tak pro ně zabezpečit vizualizaci zpracování dat a komunikaci s klienty. 4. U GUI jednotek můžeme mluvit o vlastnostech, struktuře, operacích, událostech a stavech. V systémové rovině jsou relevantní zejména důvody 1, 2 a 3. Označme libovolnou podnikovou/nepodnikovou službu symbolem s a libovolnou GUI jednotku symbolem g. Konečnou množinu podnikových a nepodnikových služeb označme symbolem S a konečnou množinu všech GUI jednotek symbolem G. GUI systém je definován notací S GUI = (G, R, R'), kde R G x G a R' G x S. Množina R je množinou vnitřních vazeb a R' zase vnějších vazeb. Prvky množiny S, tj. služby, jsou umístěné v okolí systému GUI, což rovněž ilustruje obr. 2. Povahy vazeb, reprezentovaných společnou neorientovanou tečkovanou spojnicí, jsou upřesněny v dalším textu. s 1 s 2 s 3 g 1 g 2 s 5 s 6 g 3 g 4 GUI systém Legenda: je ikona služby ikona GUI jednotky symbol vazby hranice systému GUI. s 4 2: Ukázka vazeb mezi GUI jednotkami a okolím GUI systému Dále budeme předpokládat, že každá GUI jednotka g nebo podniková služba s mají vstupní datový protokol Input, vnitřní paměť Mem (memory) a výstupní datový protokol Output a množinu operací Oper (operations). Příslušnost protokolů a pamětí určujeme indexy, tj. jmény podnikových služeb nebo GUI jednotek, např. Input g, Mem g, Output g, Oper g. Systémovou spolupráci mezi podnikovými službami a GUI jednotkami a mezi GUI jednotkami samotnými potom můžeme formalizovat prostřednictvím operací z množiny Oper g, které zmíněné protokoly zpracovávají. Binární relace v GUI systému Mezi GUI jednotkami a službami je relace vzájemné funkcionální asociace. Tato relace naznačuje nejen to, že podstata GUI jednotky vychází z funkcionality dané služby, ale také to, že touto službou může být jednotka GUI spouštěna. Označme symbolem relaci - 15

16 funkcionálního spojení GUI jednotky g se službou s a existenci této relace zapíšeme notací s g. Pochopitelně platí, že S x G. Je tedy prvotním úkolem systémové analýzy konstruovat dvojice (s, g). Buďte m, n přirozená čísla. V praxi se často setkáváme s případem, kdy platí (s 1 g) (s 2 g)... (s m g) (S x G), ale obrácená situace (s g 1 )... (s g n ), kdy jedna služba je asociovaná s více GUI jednotkami, je používána rovněž. Nechť R je libovolná vazba mezi GUI jednotkami, R' vazba mezi podnikovými službami a GUI jednotkami a R'' je inverzní k R'. Potom můžeme tuto domluvu formalizovat notacemi tvaru R (G x G), R' (S x G) a R'' (G x S). Vazby (S x S) nejsou pro GUI systém významné, protože jsou v jeho okolí a patří do problematiky work-flow analýzy podniku. Uveďme teď významy zbývajících relací z množiny {,,,,, Θ }, tj. dalších relevantních vazeb v GUI systému a jeho vazby na okolí: relace "spuštění"... symbol R 1 : GUI jednotka g spouští GUI jednotku g', tedy g g', interní vazba mezi GUI jednotkami R 2 : GUI jednotka g spouští službu s, tedy g s, výstupní vazba do okolí GUI systému R 3 : Služba s spouští GUI jednotku g, tedy s g, vstupní vazba z okolí GUI systému. Jestliže mezi službou s a GUI jednotkou g platí relace (s g), potom relace implikuje relaci. Jinými slovy, jednotku g lze z této služby vždy spouštět. R 4 : relace "synchronizace"... symboly a GUI jednotka g vyžaduje, aby na pracovní ploše byla rovněž přítomná GUI jednotka g', tedy g g'. GUI jednotka g vyžaduje, aby na pracovní ploše byly rovněž přítomné části a 1, a 2,..., a k GUI jednotky g', tedy g g'/ a 1, a 2,..., a k. Pochopitelně, relace implikuje relaci, tj. jestliže platí potom platí rovněž. Na základě obou uvedených relací lze vytvářet konečné řetězce synchronizovaných jednotek GUI. R 5 : relace "čtení a změny"... symbol GUI jednotka g může číst a přepisovat paměť Mem g' jednotky g', která musí být synchronizovaná s GUI jednotkou g, tedy g g'. Každá jednotka g může číst a měnit svou paměť, tedy g g. R 6 : relace "čtení"... symbol GUI jednotka g může pouze číst paměť Mem g' jednotky g', která musí být synchronizovaná s GUI jednotkou g, tedy g g'. Každá jednotka g může číst svou paměť, tedy g g. Jednak platí, že relace implikuje relaci a potom rovněž platí, že nutnou podmínkou pro obě relace je platnost relace. - 16

17 R 7 : relace "nezávislosti"... symbol Θ Jednotky g a g' nejsou v žádné jiné relaci v než relaci nezávislosti, tedy g Θ g'. Pomocí zavedených relací můžeme připravit vztahový ohodnocený graf mezi prvky GUI systému a mezi GUI systémem a okolím. Tento graf relací v GUI systému je obecně nesouvislý. Vznikne z obr. 2, ve kterém vynecháme hranici GUI systému a na neorientované hrany napíšeme specifická relační ohodnocení. s 1 g 1 g 2 s 5 s 2 g 5 s 6 s 3 g 3 g 4 s 4 3: Ukázka grafu relací mezi GUI jednotkami a okolím GUI systému Poznámka 1 1. Graf relací z obr. 3 poskytuje vývojáři informaci o vazbách v systému GUI. Např. GUI jednotky g 3 a g 4 jsou nezávislé, GUI jednotky g 1, g 2, a g 4 jsou na pracovní ploše najednou apod. 2. Pochopitelně, u každé z relací R 1 až R 7 můžeme zkoumat její vlastnosti (reflexivnost, symetričnost, tranzitivnost a dichotomii). Např. relace je tranzitivní, protože platí implikace (g g' g'') g g''. Takovou ovšem není relace. Relace, jsou zase reflexivní. Tento směr zkoumání relací mezi GUI jednotkami ponecháme stranou. Rovněž není uskutečněno důsledné zkoumání vzájemných souvislostí jednotlivých relací. 3. Nad mnoha relacemi můžeme vytvářet řetězce, které jsou výsledkem GUI work-flow analýzy (implementace work-flow analýzy na GUI systém). 4. Přehled relací v GUI systému není úplný, množinu relací lze jistě rozšířit. Operace nad GUI jednotkami V našich úvahách byla GUI jednotka povýšena na samostatný prvek a podle toho s ní musíme manipulovat. Každou GUI jednotku, prvek systému GUI, můžeme potom vyšetřovat alespoň ze čtyř relevantních hledisek: struktury, vlastností, funkcionality, událostí a stavů. Z těchto hledisek budeme diskutovat jen první tři. Struktura GUI jednotky je postavena na vnořených elementárních stavebních jednotkách GUI a jiných GUI jednotkách a vazbách mezi nimi. Pojetí struktury lze rozvinout až ke strukturálním vzorům, tj. opakovaně se vyskytujícím GUI jednotkám se stejnou strukturou. Struktura GUI jednotky vychází z nároků na vizualizaci zpracování dat nebo nároků komunikace s klientem v dané podnikové službě, s níž je GUI jednotka funkcionálně spojena. V dalších úvahách budeme každou GUI jednotku považovat za nedělitelný celek. Vlastnosti GUI jednotky g představují její deskripce, podobné následujícím: - 17

18 poloha na pracovní ploše a parametry velikost obrysového rámce elementární GUI jednotka, která získá aktivitu po oživení vnitřní paměť Mem g a její členění vstupní protokol Input g výstupní protokol Output g, viditelnost/neviditelnost Uvažujme symbol jako operátor ukládání. Do funkcionality GUI jednotky g často řadíme např. následující operace, základ množiny Oper g : o 1 Oživení GUI jednotky. Oživení proběhne podle typu jednotky. Např. pro grafický typ se zobrazí grafická podoba GUI jednotky g na pracovní ploše a oživí se "fokusová" elementární GUI jednotka (operace je předznačena ve volání od asociované služby s nebo od jiné GUI jednotky g'). Vždy se zobrazí paměť Mem g rozprostřená na elementární GUI jednotky. o 2 Umrtvení GUI jednotky. GUI jednotka g se odstraní z pracovní plochy. Operace může být vyvolána ze služby s nebo z jiné GUI jednotky g', která je rovněž na pracovní ploše. Paměť Mem g se zachovává. o 3 Převzetí komunikačního protokolu. Jednotka g musí být živá. Vstupní protokol Input g se převezme a uloží do paměti Mem g jednotky g. Tedy Output s,g' Input g Mem g. Paměť Mem g se zobrazí. o 4 Množina specifických operací. Operace se provádí nad pamětí Mem g. Jsou to operace, které jednoznačně vycházejí z funkcionality asociované podnikové služby. Tedy, Mem g Mem g, kde je nespecifikovaná unární operace. Zobrazení paměti Mem g závisí od dané operace. o 5 Množina modifikačních operací GUI jednotky. Je možno měnit vlastnosti, strukturu, apod. GUI jednotky g. o 6 Operace pro modifikační efekty. Jde převážně o nastavování událostí GUI jednotky g. o 7 Reakce na události. Jsou to operace specificky reagující na každou zachycenou událost GUI jednotky g. o 8 Předání komunikačního protokolu. Jednotka g předá aktuální stav své paměti Mem g jako komunikační protokol Output g, když spouští službu s nebo jinou GUI jednotku g'. Tedy, Mem g Output g Input g',s. Na základě uvedených operací a symbolu pro kooperaci podnikových služeb a GUI jednotek můžeme pro vývojáře sestavit množinu kooperačních diagramů, které jsou konzistentní s grafem relací v GUI systému. Hrany kooperačních diagramů mají tvar o s, g g'. Nad symbolem kooperace potom píšeme operaci, o jejíž provedení kooperace GUI jednotku g' žádá. Dokonce lze oba zmíněné diagramy sloučit v jeden relačně-kooperační diagram. Poznámka 2 Vedle GUI jednotek, které jsou asociovány s podnikovými službami, existují rovněž GUI jednotky asociované s nepodnikovými službami. Mnoho takových služeb vzniká ve fázi hrubého a detailního návrhu business software PIS. Naše úvahy platí i pro tyto služby a s nimi asociované GUI jednotky. - 18

19 Modelování GUI systému K modelování GUI systému můžeme použít běžných diagramů používaných v objektovém paradigmatu. Je to cesta jednotného přístupu prostřednictvím objektového paradigmatu ke zdrojům GUI a samotným jednotkám GUI. To znamená, že podobně jak navrhneme třídy (business třídy) pro podnikové služby, navrhneme i třídy pro jejich jednotky GUI. Sestrojíme dva kooperující anebo jeden jednotný model pro oba typy tříd. Model tříd GUI jednotek bude obsahovat jejich požadované dědičnosti a relace (informační asociace, agregace, ). Dále, podobně jako jsme modelovali spolupráci mezi podnikovými službami, budeme modelovat i jejich spolupráci s jednotkami GUI a spolupráci GUI jednotek navzájem. Spolupráci podnikových služeb a GUI jednotek, GUI jednotek mezi sebou navzájem můžeme modelovat pomocí UML diagramů objektové spolupráce a sekvenčních diagramů na základě zasílání a přijímaní zpráv. Diagram vzájemné objektové spolupráce GUI jednotek je potom vlastně GUI navigačním diagramem (GUI Navigation Diagram). Vedle těchto velmi důležitých diagramů se nevyhneme diagramu struktury GUI jednotek (GUI Layout Diagram). Tento diagram načrtne business analytik pro každou GUI jednotku jednotlivě, vycházeje z funkcionálních požadavků a požadavků vizualizace a komunikace s klientem dané asociované podnikové/nepodnikové služby. Všechny uvedené diagramy, tj. diagram tříd pro podnikové služby, diagram tříd pro jednotky GUI, diagram objektové spolupráce služeb a GUI jednotek, diagram struktury GUI, těsně souvisejí a prezentují jednotný pohled na zdroje GUI a GUI samotné. Business software a vývoj jeho GUI systému Implementace rozhraní aplikací prošla rychlým vývojem. Na jedné straně klasické programování těsně svázalo GUI se zdrojem aktivit v aplikacích a našlo efektivní prostředky pro jeho modelování a implementaci, na druhé straně se dnes žádá relativní nezávislost zdrojů a z nich vycházejících GUI jednotek. O důvodech této snahy jsme se již zmínili. Současný stav, kdy se do popředí dostávají webové objektové aplikace, představuje objektové paradigma velmi výhodný přístup k implementaci GUI zmíněných aplikací (Page Jones, 2001). Objektové paradigma umožňuje podnikové služby relativně oddělit od s nimi svázaného GUI. Tak se podnikové služby a GUI jednotky dostávají na stejnou realizační platformu. Je to konzistentnost implementačního přístupu ke GUI a jeho zdrojům. SOUHRN Metoda vydělení GUI z podnikových služeb a vytvoření GUI systému má reálné opodstatnění v požadavku flexibility možných změn služeb a asociovaného GUI. Na druhé straně se ale stěžuje samotná komunikace mezi podnikovými službami a vydělenými GUI jednotkami. Obě skutečnosti předkládaný příspěvek plně potvrzuje. Výsledky z teoretické a systémové roviny byly rovněž diskutovány v rovinách modelování a implementace. V mnoha směrech příspěvek ale nevyčerpal pro GUI systém všechny možnosti uplatnění teorie systémů. Na úrovni rovin modelování a implementace bylo ukázáno, že teoretický a systémový přístup jsou v obou rovinách akceptovatelné a zvládnutelné v objektovém paradigmatu vývoje software. Rozhodně není nevhodná poznámka o tom, že GUI je poměrně široká záležitost a jeden příspěvek nemůže diskutovat všechny známé problémy spojené s jeho vývojem. - 19

20 Příspěvek je zaměřen na uplatnění systémového pohledu na vazby podnikových služeb a s nimi asociovaného GUI. Tato asociace je specifikována jako jedna z relací v GUI systému. Obvykle je GUI podnikové služby považováno za její přirozenou součást. Příspěvek se, oproti této myšlence, pokouší vydělit jednotlivé celky GUI z daných služeb a vytvořit z nich samostatné GUI jednotky, prvky GUI systému. Podstatou příspěvku je ukázat, kam může vést důsledné uplatnění teorie systémů. Systémová analýza vedla ke specifikaci samotných GUI jednotek a povahy vazeb mezi GUI jednotkami a GUI systémem a podnikovými službami z jeho okolí. Byla navržena množina relací, které reprezentují v praktické práci s GUI často se vyskytující souvislosti. Pro reprezentaci vazeb v GUI systému byl navržen relační graf, který by měl dát vývojáři-programátorovi potřebné informace o jejich povaze. Tento graf nahrazuje často velmi obšírnou verbální deskripci zmíněných vazeb. GUI jednotka, GUI systém, GUI zdroje, modelovací techniky pro GUI, funkcionalita GUI, vazby mezi jednotkami GUI, vývojové techniky pro GUI SUMMARY The methods for GUI separation from enterprise services and System GUI creation have foundation concerning requirement flexibility of possible service changes and associated GUI. On the other hand, the communication between enterprise services and separated GUI units is harder. The submitted article fully confirms these possibilities. The results from theoretical level were also discussed in modeling and implementation levels. The article has not exhausted all possibilities for system theory implementation over GUI in all directions. On the level of modeling and implementation there were showed that theoretical and system approach is acceptable in object paradigm for software development. Anyway, the GUI area is too large and one article cannot discuss all problems connected with its development. This article is oriented to a system approach implementation on enterprise services and with them associated GUI. This association is specified as a one relation in the GUI system. Usually the enterprise service GUI unit is regarded as a natural component of a mentioned enterprise service. Against this idea, the article tries to separate GUI parts from their enterprise services and construct from them GUI units and a GUI system altogether. The main purpose of the article leads to showing what we can achieve by thorough system theory implementation. The system analysis leads to GUI unit specifications and nature of relations between GUI units and enterprise services from GUI system environment. Some set of relations were suggested that represent in practice very often existing associations between GUI units. Some relation graph was introduced for representation of GUI unit relations that should provide to developers-programmers all needed information about them. This graph can replace very often used verbal description of mentioned relations. LITERATURA PAGE JONES, M., 2001: Základy objektově orientovaného návrhu v UML. Praha, Grada Publishing. ISBN X. ARLOW, J., NEUSTADT, I., 2003: UML a unifikovaný proces vývoje aplikací. Praha, Česká republika, Computer Press. ISBN

21 TIDWELL, J., 2005: Designing Interfaces. Patterns for Effective Interaction Design. Tokyo: O'REILLY. ISBN MIŠOVIČ, M., 2007: Podnikový informační systém a GUI jeho aplikačního software. In: Sborník prací z mezinárodní vědecké konference Agrární perspektivy XVI. Praha, Česká zemědělská univerzita v Praze, str ISBN