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

Webová aplikace pro kreslení UML diagramů František Toman

Vedoucí práce: Ing. Jiří Hunka

17. května 2012

Poděkování Především bych chtěl poděkovat vedoucímu mé bakalářské práce Ing. Jiřímu Hunkovi za možnost pracovat na tomto projektu, za jeho trpělivost a cenné rady při psaní této práce. Dále bych chtěl poděkovat mé rodině a všem přátelům za podporu během mého studia.

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 17. května 2012

..................... 7

České vysoké učení technické v Praze Fakulta informačních technologií c 2012 František Toman. 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 František Toman. Webová aplikace pro kreslení UML diagramů: Bakalářská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract This bachelor thesis describes design and implementation of web application for creating UML diagrams. Among other things, simply describes UML modeling language, its history and tools supported modeling UML diagrams. Practical result of this work is functional prototype of web application for drawing UML diagrams. Keywords design, implementation, UML, web application, history of UML, open-source software

Abstrakt Obsahem této bakalářské práce je návrh a implementace webového nástroje pro tvorbu UML diagramů. Mimo jiné stručně popisuje jazyk UML, jeho historii a dostupné nástroje pro práci s tímto modelovacím jazykem. Výstupem praktické části práci je funkční prototyp nástroje určeného ke kreslení UML diagramů. Klíčová slova návrh, implementace, UML, webová aplikace, historie UML, otevřený software

9

Obsah Úvod

17

1 UML 19 1.1 Historie UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.2 Struktura UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2 Nástroje pro práci s UML, analýza 2.1 Komerční nástroje . . . . . . . . . 2.2 Nekomerční nástroje . . . . . . . . 2.3 Shrnutí . . . . . . . . . . . . . . .

konkurence 27 . . . . . . . . . . . . . . . . 27 . . . . . . . . . . . . . . . . 32 . . . . . . . . . . . . . . . . 35

3 Analýza aplikace 37 3.1 Vize projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2 Specifikace požadavků . . . . . . . . . . . . . . . . . . . . . . . 37 3.3 Analýza a výběr nástrojů pro návrh a realizaci . . . . . . . . . 39 4 Návrh 4.1 Architektura aplikace . . . 4.2 Serverová část aplikace . . . 4.3 Klientská část aplikace . . . 4.4 Komunikace mezi klientskou 4.5 Funkční balíčky . . . . . . .

. . . a .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . serverovou částí . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

49 49 49 52 54 54

5 Realizace 5.1 Jmenné prostory . . . . . . 5.2 Nastavení aplikace . . . . . 5.3 Nastavení routeru aplikace . 5.4 Presentery . . . . . . . . . . 5.5 Úprava knihovny JointJS . 5.6 Tvorba balíčků diagramů . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

57 57 57 58 58 59 60

11

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

5.7 5.8 5.9

Převod diagramů do obrázkových formátů . . . . . . . . . . . . Vyhledávání funkčních balíčků . . . . . . . . . . . . . . . . . . . Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62 63 64

6 Testování 65 6.1 Průběžné testování . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.2 Akceptační testování . . . . . . . . . . . . . . . . . . . . . . . . 65 6.3 Hodnocení uživatelů . . . . . . . . . . . . . . . . . . . . . . . . 66 Závěr 69 Další vývoj projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Literatura

71

A Seznam použitých zkratek

75

B Obsah přiloženého CD

79

C Analytický model

81

D Návrhový model

87

E Ukázky zdrojových kódů

97

F Instalační příručka F.1 Systémové požadavky . . . . . . . . . . . . . . . . . . . . . . . F.2 Instalace aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . F.3 Nastavení připojení k databázi . . . . . . . . . . . . . . . . . .

105 105 105 106

G Ukázky výsledné aplikace

107

12

Seznam obrázků 1.1 1.2

Struktura OOSE neboli Object-Oriented Software Engineering . . Hierarchie diagramu UML 2.0 . . . . . . . . . . . . . . . . . . . . .

22 25

2.1 2.2 2.3 2.4 2.5 2.6

Uživatelské Uživatelské Uživatelské Uživatelské Uživatelské Uživatelské

28 29 31 32 33 35

3.1

Model ajaxové komunikace ze článku „Ajax: A New Approach to Web Applications“ . . . . . . . . . . . . . . . . . . . . . . . . . . . Graf porovnání doby vykreslení v závislosti na počtu objektů . . . Graf porovnání doby vykreslení v závislosti na výšce vykreslovací plochy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

4.1

Balíček tříd serverové části . . . . . . . . . . . . . . . . . . . . . .

51

5.1 5.2

Nastavení velikosti elementu . . . . . . . . . . . . . . . . . . . . . . Adresářová struktura exporteru ExportToImage . . . . . . . . . . .

61 63

C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8

Zainteresovaní – uživatelské role . . . . . . . . . . . . . . Případ užití – registrace uživatele . . . . . . . . . . . . . . Případ užití – přihlášení do systému, odhlášení ze systému Případ užití – správa projektů . . . . . . . . . . . . . . . . Případ užití – správa diagramů projektu . . . . . . . . . . Případ užití – správa elementů diagramu . . . . . . . . . . Případ užití – správa uživatelských účtů . . . . . . . . . . Případ užití – správa balíčků . . . . . . . . . . . . . . . .

. . . . . . . .

81 81 82 82 83 84 85 85

D.1 Architektura serverové části aplikace . . . . . . . . . . . . . . . . .

87

3.2 3.3

rozhraní rozhraní rozhraní rozhraní rozhraní rozhraní

CASE nástroje Enterprise Architect . nástroje Visual Paradigm for UML 9.0 nástroje Gliffy . . . . . . . . . . . . . . nástroje Creately . . . . . . . . . . . . nástroje StarUML . . . . . . . . . . . nástroje Diagramly . . . . . . . . . . .

13

. . . . . . . .

. . . . . .

. . . . . . . .

. . . . . .

. . . . . . . .

. . . . . .

. . . . . . . .

. . . . . .

43 46

D.2 Architektura aplikace . . . . . . . . . . . . D.3 Balíček tříd klientské části . . . . . . . . . . D.4 Balíček presenterů . . . . . . . . . . . . . . D.5 Návrh tříd presenterů backendu aplikace . . D.6 Návrh tříd presenterů frontendu aplikace . D.7 Návrh tříd modelů aplikace . . . . . . . . . D.8 Diagram tříd datových entit . . . . . . . . . D.9 Návrh tříd jádra aplikace . . . . . . . . . . D.10 Návrh tříd widgetů . . . . . . . . . . . . . . D.11 Návrh tříd pro grafické uživatelské rozhraní

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

88 89 89 90 90 91 92 93 94 95

F.1 Diagram nasazení aplikace Brain Architect . . . . . . . . . . . . . 106 G.1 G.2 G.3 G.4

Úvodní obrazovka aplikace . . . . . . . . . . . . . . . . . . . . . . Dialogové okno aplikace pro vytvoření nového projektu . . . . . . . Ukázka editace diagramu . . . . . . . . . . . . . . . . . . . . . . . Ukázka uživatelského rozhraní exporteru pro převod diagramů do obrázkových formátů . . . . . . . . . . . . . . . . . . . . . . . . . . G.5 Administrační uživatelské rozhraní aplikace . . . . . . . . . . . . .

14

107 108 108 109 109

Seznam tabulek 2.1

Srovnání uživatelských účtů nástroje Gliffy . . . . . . . . . . . . .

30

6.1

Výsledky akceptačních testů . . . . . . . . . . . . . . . . . . . . . .

66

15

Úvod V dnešní době je UML, viz kapitola 1, jazykem, který je využíván nejen v rámci životního cyklu vývoje software. Obecně slouží k zachycení reality složené z objektů a interakce mezi nimi. Jazyk UML je ve své podstatě komunikační nástroj, který umožňuje popsat realitu pomocí grafické interpretace. Právě tato grafická interpretace je mnohem jednodušší pro pochopení řešeného problému pro obyčejného člověka. Na komerčním trhu je dostupná celá řada produktů podporující práci s UML. Tyto nástroje se vyznačují svojí komplexností a bývají označeny jako CASE nástroje. Mezi dodavatele desktopových komerčních nástrojů patří například Sparx Systems se svým CASE nástrojem Enterprise Architect či společnost IBM se sadou produktů Rational Rose. Komerční online nástroje, které poskytují tvorbu některých UML diagramů, se z větší části zaměřují pouze na kreslení diagramů. Proto jejich využití v reálné praxi má pouze malý potenciál. Naproti tomu existuje celá řada volně dostupných nástrojů ve formě opensource či freeware. Tyto nástroje ale nenabízejí takovou funkční sadu, kterou nabízejí nástroje komerční. U volně dostupných řešení převažuje forma desktopových aplikací nad aplikacemi webovými. Často také trpí grafickým designem a opomenutím dosáhnout, co nejkvalitnějšího User Experience (UX). Deficit kvalitního UX je jedním z podnětů tématu této bakalářské práce. Primárním cílem projektu je vytvořit open-source webovou aplikaci podporující tvorbu UML diagramů. Tento nástroj ponese název Brain Architect. Aplikace bude koncipována tak, aby mohla být jednoduše rozšiřitelné (škálovatelná) v rámci otevřené komunity (open-source) o nové typy diagramů a funkční vlastnosti (např. generátor kódu pro různé jazyky, apod.). Dalším cílem tohoto projektu je navržení, co nejkvalitnějšího UX. Tedy, aby byla aplikace pro uživatele jednoduchá a její používání bylo ve větší míře pohodlné a příjemné.

17

Kapitola

UML Unifikovaný modelovací jazyk neboli UML (Unified Modeling Language) je univerzální vizuální modelovací jazyk. Tento jazyk vznikl sjednocením několika významných metodik, nejlepších praktik a modelovacích technik pro podporu softwarového inženýrství a návrh objektově orientovaných softwarových systémů. Někdo se může domnívat, že UML je metodologie vývoje software. Ale není tomu tak. Jedná se, jednoduše řečeno, o grafický jazyk. V souvislosti k metodologiím vývoje SW je významnou výhodou UML nezávislost k žádné specifické metodologii nebo životnímu cyklu vývoje SW. UML může být využit jako podpůrný nástroj všemi existujícími metodologiemi. Mezi metodologie využívající UML jako základní modelovací syntax patří např. Unified Process, Rational Unified Process firmy IBM či Object-Oriented Process, Environment and Notation neboli OPEN. Přestože je tento jazyk nejčastěji spojován s modelováním objektově orientovaných softwarových systémů, tedy jako nástroj pro podporu softwarového inženýrství, má mnohem širší využití díky zabudovanému rozšiřovacímu mechanismu. UML je tedy možné využít i při modelování business procesů či modelování nesoftwarových systémů. Jelikož je UML grafickým modelovacím jazykem, nabízí výstup ve formě grafické interpretace modelovaných modelů. Výstupem jsou tedy diagramy, které jsou pro člověka mnohem snáze pochopitelné než několika set řádkové dlouhé texty. Od roku 1997 je UML otevřeným průmyslovým standardem objektově orientovaného vizuálního modelovacího jazyka, jenž byl přijat standardizační skupinou Object Management Group (19).

1.1

Historie UML

Důležitým milníkem v oblasti objektově orientovaného návrhu softwarových systémů v souvislosti s vizuálními modelovacími jazyky jsou léta 1994–1995. 19

1

1. UML Před rokem 1994 byly dostupné metodologie a vizuální modelovací jazyky, které se vyvíjely separátně. Od výše zmíněného milníku se snaha některých autorů těchto metodologií a vizuálních modelovacích jazyků přesunula do společného zájmu vytvořit sjednocený (unifikovaný) vizuální modelovací jazyk.

1.1.1

Předchůdci UML

Před rokem 1994 existovalo několik konkurenčních vizuálních modelovacích jazyků a metodologií vývoje objektově orientovaných softwarových systémů. Z hlediska vizuálních modelovacích jazyků patřil mezi nejvýraznější jednoznačně Grady Booch s Object-Oriented Design neboli OOD, viz kapitola 1.1.1.2, a James E. Rumbaugh s OMT neboli Object Modeling Technique, viz kapitola 1.1.1.1. Co se týče metodologií, mezi nejvýraznější osobnosti patřil Ivar Jacobson se svou metodologií OOSE neboli Object-Oriented Software Engineering, viz kapitola 1.1.1.3. 1.1.1.1

OMT

Jedním z předchůdců jazyka UML je OMT neboli Object Modeling Technique. Jedná se o modelovací jazyk určený k modelování a návrhu software. Tento modelovací jazyk byl publikován v roce 1991 a na jeho vzniku se podílel James E. Rumbaugh, Blaha, Premerlani, Eddy a Lorensen. Cílem bylo vytvořit metodiku pro vývoj objektově orientovaných systémů a pro podporu objektově orientovaného programování. Předpokladem OMT je objektově orientované myšlení. Tento způsob myšlení je, dle Rumbaugha, přirozenější a intuitivnější cestou k zachycení reality. Nicméně tento předpoklad byl vážně zpochybněn v roce 1993 Høydalsvikem a Sindrem 1993 a v roce 1994 Hansethem a Monteirem. Hlavním účelem modelování dle Rumbaugha jsou (31): • testování/simulace fyzických jednotek, před jejím vybudováním, • komunikace se zákazníky, • vizualizace jako alternativní podoba informací, • zjednodušení komplexního problému. K popisu systému využívá tato technika tři základní modely: • Objektový model (object model) popisuje statický pohled na systém. Využívá k popisu diagram podobný ER (entity-relationship) diagramu. Skládá se z tříd, které obsahují vlastnosti a operace, a vztahy mezi nimi. Mezi vztahy, které model využívá, patří asociace, agregace a dědění. • Dynamický model (dynamic model) využívá tzv. state transition diagram k popisu chování jednotlivých tříd z objektového modelu. Model 20

1.1. Historie UML se skládá ze stavů, přechodů mezi nimi a událostí, které tyto přechody mezi stavy vyvolávají. • Funkční model (functional model) nahlíží na systém z pohledu procesu. Je podobný diagramům toků dat a skládá se z procesů, datových úložišť, toků dat a uživatelských rolí. 1.1.1.2

The Booch Method - OOAD (Object-Oriented Analysis & Design)

V roce 1991 Grady Booch publikoval metodiku OOAD, která našla široké využití v objektově orientované analýze a návrhu. Tato metodika více než fázi analýzy zdůrazňuje fázi návrhu (designu). Proto je také známá pod zkratkou OOD neboli Object-oriented Design. Grady Booch navrhl několik různých pohledů k popsání objektově orientovaného systému. Jedná se o logický, fyzický, statický a dynamický model. Logický model se skládá ze struktury tříd a objektů. Zatímco diagram tříd popisuje statický model (statickou strukturu) systému, diagram objektů zachycuje chování systému, tedy vzájemnou interakci objektů. Fyzický model rozděluje struktury tříd a objektů do samostatných modulů a popisuje konkrétní hardwarové zařízení a vztahy mezi nimi s ohledem na softwarové komponenty. Tato metoda zahrnuje 6 typů diagramů. • Diagram tříd (class diagram), • objektový diagram (object diagram), • diagram stavů (state transition diagram), • diagram modulů (module diagram), • diagram procesů (process diagram), • a diagram interakce (interaction diagram). 1.1.1.3

OOSE (Object-Oriented Software Engineering)

Ivar Jackobson, zakladatel společnosti Objectory AB, v roce 1992 zdokumentoval v knize Object-Oriented Software Engineering: A Use Case Driven Approach metodologii a objektový modelovací jazyk OOSE neboli Object-Oriented Software Engineering. Jedná se o jednodušší verzi metodologie Objectory s cílem pokrýt celý životní cyklus vývoje software. OOSE je první metodologie, která používala jako základní kámen procesu centrální případy užití neboli Use Cases, viz obrázek 1.1. Metodologie OOSE v sobě zahrnuje: • zachycení požadavků (requirements model), 21

1. UML

di agr amy př í paduuž i t í

Model pož adav k ů

Di agr am pr obl ému doménov ého obj ek t u

Anal y t i c k ýmodel

Náv r hov ýmodel

I mpl ement ač nímodel

di agr amys t av ov ý c h př ec hodů

di agr amyi nt er ak c e

Tes t ov ac ímodel

Anal y t i c k édi agr amy

di agr amy př í paduuž i t í

Obrázek 1.1: Struktura OOSE neboli Object-Oriented Software Engineering (27)

• analýzu (analyze model), • design (design model), • implementaci (implementation model), • a testovací model (test model).

1.1.2

Vznik UML

Počátky vývoje UML se vztahují k roku 1994, kdy začali společně Grady Booch a Jim Rumbaugh ve společnosti Rational Software spojovat své metodiky OOD a OMT. Výsledkem byla v roce 1995 metodika Unified Method 0.8 (z této metodiky později vzešla metodika UP neboli Unified Process). Tentýž rok koupila firma Rational Software firmu Objectory AB, jejíž zakladatelem a vlastníkem byl Ivar Jackobson. Ten se připojil ke dvojici Rumbaugh a Booch a vytvořili spolu legendární trojici zvanou Three Amigos nebo také Los Tres Buddies (21). Tato skupina následně po začlenění některých myšlenek z metodiky OOSE představila světu první verzi UML. Jednalo se o verzi UML 0.9 a 0.9.1. Po vydání těchto verzí se do práce zapojila řada významných společností, např. IBM, Microsoft, Texas Instrument, Oracle a další. 22

1.2. Struktura UML Velká podpora a zájem o tento modelovací jazyk vyústily k vytvoření verze 1.0. Tato verze byla představena v roce 1997. Tentýž rok byla verze UML 1.0 zaslána na žádost skupiny Object Management Group jako návrh standardu vizuálního modelovacího jazyka. Po vydání UML 1.1 byl tento vizuální modelovací jazyk přijat skupinou OMG jako otevřený průmyslový standard objektově orientovaného vizuálního modelovacího jazyka. Pod standardizovanou verzí UML 1.0 skupiny OMG se tedy skrývá verze UML 1.1. V letech 1998– 2001 došlo několika revizím v jazyce s cílem odstranit některé nedostatky a chyby. Od roku 2001 se začalo pracovat na nové verzi jazyka UML 2.0, která byla dokončena v roce 2005. V tentýž rok byla druhá verze jazyka také přijata za standard skupinou OMG. V této verzi došlo k relativně velkým změnám vizuální syntaxe. Část syntaxe byla úplně nová, reprezentovala nově přidanou sémantiku jazyka, a část z verze 1.x byla nahrazena. I přes tyto změny byly schopni modeláři přejít na novou verzi jazyka, jelikož většina změn se promítala do meta-modelu jazyka (9). Do verze jazyka UML 2.0 byly přidány nové typy diagramů. Jedná se o diagram objektů, diagram balíčků, diagram kompozitní struktury, diagram interakčního přehledu, diagram načasování a diagram profilu. Diagram kolaborace byl přejmenován na diagram komunikace. Od roku 2005 proběhlo několik menších revizí verze 2.x. Nejaktuálnější vydanou verzí jazyka UML je verze s označením 2.4.1, jenž byla vydána v srpnu roku 2011.

1.2

Struktura UML

Specifikace UML verze 2.0 je rozdělena do čtyř částí. • UML 2.0 Infrastructure definuje pomocí MOF (Meta-Object Facility) jádro metamodelu, na němž je postavená superstruktura. Popisuje syntax jazyka. Tato část specifikace je určená především vývojářům, kteří vytvářejí nástroje pro práci s UML. • UML 2.0 Superstructure popisuje strukturu jazyka z pohledu uživatele. Popisuje notaci a sémantiku diagramů a jejich elementů. Tato část specifikace je určená těm, kteří využívají UML jako podpůrný nástroj při procesu realizace systémů. • UML 2.0 OCL neboli Object Constraint Language je formální jazyk určený pro popis pravidel (vstupní/výstupní podmínky, invariant) aplikovaných na jednotlivých částech UML diagramů. • UML 2.0 Diagram Interchange definuje formát pro výměnu dat diagramů mezi nástroji pro práci s UML. 23

1. UML

1.2.1

Profily

Díky zabudovanému rozšiřovacímu mechanismu UML může být tento jazyk přizpůsoben pro specifické využití v určité oblasti. Toto rozšíření nazýváme profilem. Profil je tedy skupina rozšíření, která je aplikovatelná v rámci určité oblasti řešeného problému (20). Mezi profily, které jsou zároveň přijatým standardem skupiny OMG, patří například: • UML Profile for Enterprise Application Integration (EAI), • UML Profile for System on a Chip (SoC), • UML Profile for Systems Engineering (SysML).

1.2.2

Diagramy

Specifikace UML 2.0 definuje třináct základních diagramů, viz obrázek 1.2, rozdělených do tří základních skupin (18). • Diagramy struktur, jenž reprezentují statickou strukturu aplikace. • Diagramy chování reprezentující chování aplikace. • Diagramy interakce jsou podmnožinou diagramů chování a reprezentují různé aspekty interakce.

1.2.2.1

Diagramy struktur

Účelem těchto diagramů je zachycení statické struktury systému a jeho jednotlivých částí. Umožňuje zachytit strukturu na různé úrovni abstrakce a implementace a souvislosti mezi jednotlivými částmi diagramu. Mezi diagramy struktur patří následující diagramy. • Diagram balíčků (Package diagram) umožňuje rozdělit model do více skupin, tedy strukturovat jej do logických celků či je strukturovat za účelem lepší organizace. Umožňuje také zobrazit vztahy mezi těmito skupinami na vysoké úrovni abstrakce. • Diagram tříd (Class diagram) je statickým pohledem na strukturu systému. Zachycuje jednotlivé strukturální elementy systému neboli třídy, které jsou popsány atributy a operacemi. Dále popisuje vztahy mezi jednotlivými elementy. 24

1.2. Struktura UML

Di agr am

Di agr am s t r uk t ur

Di agr am t ř í d

Di agr am obj ek t ů

Di agr am k omponent

Di agr am bal í č k ů

Di agr am nas az ení

Di agr am s l ož ené s t r uk t ur y

Di agr am c hov ání

St av ov ý di agr am

Di agr am př í paduuž i t í

Di agr am ak t i v i t

Di agr am i nt er ak c e

Di agr am př ehl edu i nt er ak c e

Di agr am k omuni k ac e

Sek v enč ní di agr am

Di agr am č as ov ání

Obrázek 1.2: Hierarchie diagramu UML 2.0

• Diagram objektů (Object diagram) je speciálním případem diagramů tříd. V obou případech se jedná o statický pohled na systém, ale s tím rozdílem, že diagram tříd popisuje určitou abstrakci, zatímco diagram objektů konkretizuje diagram tříd v určitém časovém okamžiku. Diagram objektů reprezentuje instance tříd neboli zdůrazňuje vztahy mezi třídami a objekty v určitém časovém okamžiku.

• Diagram komponent (Component diagram) zachycuje modulární části neboli komponenty modelovaného systému a vztahy mezi nimi. Komponenty jsou autonomní a mají zapouzdřený obsah, jenž je přístupný přes určité rozhraní. Jedná se o statický pohled na vyšší úrovni než je např. class diagram.

• Diagram nasazení (Deployment diagram) reprezentuje nastavení fyzických (hardwarových) součástí systému, na které jsou nasazeny softwarové komponenty a popisuje vztahy mezi uzly a vztahy mezi komponentami.

• Diagram složených struktur (Composite structure diagram) zachycuje interní strukturu klasifikátorů včetně jejich interakčních bodů, skrze které komunikují s ostatními částmi systému. 25

1. UML 1.2.2.2

Diagramy chování

Tento typ diagramů popisuje dynamické chování objektů v systému a jejich vzájemné působení k dosažení požadované funkcionality systému. Mezi tyto diagramy patří následující diagramy. • Stavový diagram (State machine diagram) neboli automat zobrazuje stavy objektů, ve kterých se mohou nacházet, a přechody mezi jednotlivými stavy, které jsou vyvolány nějakými událostmi. • Diagram případu užití (Use case diagram) slouží k zachycení funkčních požadavků na systém. • Diagram aktivit (Activity diagram) se využívá k modelování business procesů a vnitřní logiky aplikace. Může být vztažen k případu užití či scénáři užití. Zachycuje sekvenci aktivit neboli workflow od počátečního (inicializačního) bodu k cílovému bodu. Alternativním diagramem je stavový diagram, jenž se primárně zaměřuje na stavy objektů, zatímco zaměření diagramu aktivit je orientováno na zachycení stavu procesu. 1.2.2.3

Diagramy interakce

Jedná se o podmnožinu diagramů chování. • Diagram přehledu interakce (Interaction overview diagram) je obdobou diagramu aktivit s tím rozdílem, že uzly diagramu nezachycují stavy objektu, ale reprezentují jednotlivé interakční diagramy (diagram komunikace, sekvenční diagram, diagram časování a diagram přehledu interakce). • Diagram komunikace (Communication diagram) zobrazuje komunikaci mezi jednotlivými objekty. V předchozích verzích UML je tento typ diagramu známý jako diagram kolaborace (collaboration diagram). Alternativou diagramu komunikace je sekvenční diagram. Rozdílem mezi těmito diagramy je zaměření. Zatímco diagram komunikace vyzdvihuje, jaké objekty spolu komunikují, sekvenční diagram se zaměřuje více na časovou posloupnost komunikace. • Sekvenční diagram (Sequence diagram) zachycuje časovou posloupnost zasílaných zpráv mezi jednotlivými objekty diagramu, tedy zachycuje komunikaci mezi objekty. Alternativou sekvenčního diagramu je diagram komunikace. Rozdíl mezi těmito diagramy viz diagram komunikace. • Diagram časování (Timing diagram) slouží k zachycení změn (stavů či hodnot) jednotlivých objektů v závislosti na čase.

26

Kapitola

Nástroje pro práci s UML, analýza konkurence V současnosti je na internetu k nalezení mnoho různých nástrojů pro práci s UML. Dostupné jsou jak desktopové, tak i online verze, které pracují přímo ve webovém prohlížeči. Online verze modelovacích nástrojů jsou povětšinou implementovány pomocí technologie Adobe Flash. Některý z těchto nástrojů jsou dostupné zdarma (open-source, freeware), či jsou určeny přímo pro komerční sféru. Rozdíl mezi komerčními a volně dostupnými řešeními je v jejich komplexnosti. Komerční nástroje jsou častěji více komplexnější než volně dostupná řešení, která se spíše zaměřují na určitou část UML, např. class diagramy.

2.1 2.1.1 2.1.1.1

Komerční nástroje Desktop řešení Enterprise Architect

Jedním z CASE nástrojů podporující UML patří Enterprise Architect od firmy Sparx System. Vzhledem k faktu, že tento nástroj není zaměřený pouze na UML, nabízí širokou škálu funkčních vlastností a nástrojů. Navíc tento nástroj může být integrován do vývojového prostředí Eclipse či Visual Studio. Výhodou je relativně nízká cena produktu, která se v profesionální edici pohybuje okolo 4.000 Kč. Pro modelování pomocí UML nabízí všechny typy diagramů specifikované standardem UML schválené skupinou OMG. Funkční sada pro podporu modelování UML diagramů nabízí funkční vlastnosti, jako jsou: • generátor obrázků diagramů, 27

2

2. Nástroje pro práci s UML, analýza konkurence

Obrázek 2.1: Uživatelské rozhraní CASE nástroje Enterprise Architect

• code engineering pro konverzi diagramů do podoby zdrojových kódu podporující více než 10 programovacích jazyků (např. C++, C#, Java, PHP, ...), • reverse engineering pro převod zdrojového kódu do podoby modelů, • documentation generator neboli generátor dokumentace. Aplikace disponuje poměrně kvalitním grafickým uživatelským rozhraním, viz obr. 2.1, ve kterém je uživatel se schopen vyznat v krátkém čase a působí příjemně i po delší době strávené u tohoto nástroje. 2.1.1.2

Visual Paradigm for UML 9.0

Společnost Visual Paradigm nabízí pro práci s UML nástroj Visual Paradigm for UML 9.0. Obdobně jako Enterprise architect nabízí pro práci s UML kompletní sadu diagramů specifikovaných standardem UML ve verzích 1.x a 2.x. Mezi další funkce tohoto software patří modelování bussines procesů, modelování ERD diagramů, modelování databáze a mnoho dalšího. Nově přibyla podpora modelování SysML. Vytvořené diagramy je možno exportovat do obrázkových formátů (JPG, PNG, SVG a EMF) a do formátu PDF. Umožňuje také kompletní či části projektu exportovat do formátu XML a také je importovat zpět. V neposlední řadě umožňuje z vytvořených diagramů generování zdrojových kódů 15 programovacích jazyků (např. C#, C++, Java, PHP, ...). 28

2.1. Komerční nástroje

Obrázek 2.2: Uživatelské rozhraní nástroje Visual Paradigm for UML 9.0

Visual Paradigm for UML 9.0 může být integrován do vývojového prostředí Eclipse, Visual Studio, NetBeans a IntelliJ IDEA. Tento produkt je nabízen v těcho edicích: • Modeler – umožňuje vizualizovat myšlenky a návrh pomocí UML a ER diagramů. Cena edice je $99. • Standard – rozšiřuje edici Modeler o možnost generování elektronické dokumentace a webových stránek. Cena edice je $299. • Professional – rozšiřuje edici Standard o možnost generování Javovského zdrojového kódu, databáze a mapování ORM Hibernate. Cena edice je $699. • Enterprise – je rozšířením edice Profesional a navíc umožňuje business modelování. Cena edice je $1,399. Tento software je také dostupný pod Community edicí, která je zdarma a slouží pouze k nekomerčním účelům. Provnáme-li grafické uživatelské rozhraní nástroje Enterprise Architect a Visual Paradigm 9.0, viz obr. 2.2, dojdeme k závěru, že se na vzhledu aplikace odráží GUI, které nabízí programovací jazyk JAVA. Dalším problémem je velké množství ikonek, které nepůsobí na první pohled příjemně. Výhodou je, že si uživatel může uživatelské rozhraní nastavit dle svých požadavků. 29

2. Nástroje pro práci s UML, analýza konkurence Tabulka 2.1: Srovnání uživatelských účtů nabízených nástrojem Gliffy typ účtu Standard Pro

2.1.2 2.1.2.1

# diagramů až do 200 neomezeno

prostor 200 MB neomezeno

# spolupracovníků neomezeno neomezeno

cena/měsíc $4.95 $9.95

Web-based řešení Gliffy

Tento nástroj není zaměřený pouze na modelování UML diagramů, ale na modelování diagramů obecně. V rámci UML umožňuje modelovat: • diagram případu užití, • diagram tříd, • diagram objektů, • diagram stavů, • diagram aktivit, • sekvenční diagram, • diagram komunikace, • diagram komponent, • diagram nasazení. Kromě výše zmíněné podpory modelování UML diagramů umožňuje například modelování grafů organizace, vennovy diagramy, SWOT analýzy a mnoho dalších diagramů. Veškeré diagramy, které má uživatel možnost v tomto nástroji modelovat, si může exportovat do obrázkových formátů SVG, PNG a JPG. Dále může tyto diagramy veřejně publikovat skrze rozhraní samotného nástroje či přizvat spolupracovníky k projektu. Bez registrace nemá uživatel možnost diagramy ukládat na server. Pokud se uživatel rozhodne si účet zaregistrovat, má možnost si vyzkoušet časově omezenou verzi (30 dní) a poté se případně rozhodnout, zdali si zakoupí některý typ účtu, viz tabulka 2.1. Nástroj disponuje na první pohled přívětivým a příjemným uživatelským rozhraním, viz obr. 2.3, ve kterém se uživatel velmi rychle zorientuje. Podrobnější informace o webové aplikaci Gliffy jsou uvedeny na domovské stránce nástroje dostupné na webové adrese http://www.gliffy.com. 30

2.1. Komerční nástroje

Obrázek 2.3: Uživatelské rozhraní nástroje Gliffy

2.1.2.2

Creately

Z hlediska využití UML nabízí nástroj opět pouze kreslení UML diagramů. Mezi podporované diagramy patří: • diagram stavů • diagram nasazení • diagram komponent • diagram kolaborace • diagram případu užití • diagram aktivit • sekvenční diagram • diagram tříd • diagram objektů Kromě podpory tvorby UML diagramů nástroj nabízí další diagramy, např. myšlenkové mapy, vennovy diagramy, organizační diagramy a další. Nakreslené diagramy je možno exportovat do obrázkových formátů PNG a JPG, do formátu PDF nebo diagram odeslat na email. 31

2. Nástroje pro práci s UML, analýza konkurence

Obrázek 2.4: Uživatelské rozhraní nástroje Creately

Vytvořené diagramy lze vkládat na webové stránky v podobě embed HTML elementu, na stránky vytvořené aplikací Google Sites v podobě gadgetu a Google Code Wiki pomocí tagu wiki:gadget. Diagramy lze také sdílet na sociálních sítích Facebook, Twitter a LinkedIn. V rámci týmové spolupráce umožňuje sdílet jednotlivé diagramy pro náhled a editaci, verzování diagramů a možnost diagramy komentovat. Aplikace disponuje příjemným grafický uživatelským rozhraním. Nicméně problémem je, že veškerá funkčnost je pomocí prvků uživatelského rozhraní rozmístěna okolo editoru. viz obr. 2.4. Nástroj je dostupný ve formě desktopové i webové aplikace a je možné jej integrovat do nástrojů Fogzbugz, Confluence a Jira. Nástroj je také možné získat jako Google aplikaci v internetovém obchodě Google Apps Marketplace, kde se cena odvíjí v závislosti na počtu uživatelů, kteří aplikaci budou využívat. Zde je možné aplikací získat od 49 dolarů do 350 dolarů. Detailnější informace týkající se nástroje Creately jsou uvedeny na domovské stránce nástroje na webové adrese http://www.creately.com.

2.2 2.2.1 2.2.1.1

Nekomerční nástroje Desktop řešení StarUML

Aplikace dříve známá pod názvem Plastic nebo Agora Plastic je dostupná jako open-source projekt distribuovaný pod licencí GPL (General Public Li32

2.2. Nekomerční nástroje

Obrázek 2.5: Uživatelské rozhraní nástroje StarUML

cense). První verze této aplikace vyšla v roce 1996, tedy před 16 lety. Cílovou platformou aplikace je operační systém Microsoft Windows. Cílem projektu StarUML je vybudovat modelovací nástroj a platformu, která bude schopna nahradit konkurenční komerční nástroje, jako je např. rodina produktů firmy IBM Rational Rose, produkt Together a další. Nástroj umožňuje modelovat následující typy diagramů. • Diagram nasazení, • diagram komponent, • diagram komunikace, • diagram případu užití, • diagram aktivit, • sekvenční diagram, • diagram tříd, • diagram složených struktur, • stavový diagram. Výhodou tohoto nástroje je podpora programovacích jazyků, pro které je možné vygenerovat zdrojový kód (code generation) nebo ze zdrojového kódu 33

2. Nástroje pro práci s UML, analýza konkurence vygenerovat diagramy (reverse engineering). Základní verze podporuje programovací jazyky Java, C++ a C#. Jednotlivé šablony generování kódu má uživatel možnost si sám nastavit. Další funkční vlastností tohoto nástroje je podpora generování Microsoft Office dokumentů, a to Word, Excel a Powerpoint. Aplikace také podporuje generování návrhových vzorů dle GoF, EJB nebo samotným uživatelem definované vzory. Vzhled aplikace je podobný vzhledu aplikací postavených na technologii .NET, viz obr. 2.5. Uživatele platformy Windows si tedy přijdou na své. Podrobnější informace o projektu jsou dostupné na webové stránce na adrese http://staruml.sourceforge.net.

2.2.2 2.2.2.1

Web-based řešení Diagramly

Aplikace v rámci UML nabízí pouze kreslení diagramů. K vykreslování diagramů využívá knihovnu mxGraph (viz http://www.jgraph.com/mxgraph.html) postavenou na jazyce HTML 5 a skriptovacím jazyce JavaScript. Aplikace, ostatně jako většina obdobných webových řešení, nabízí ke kreslení kromě UML diagramů více typů diagramů, např. vývojové diagramy nebo diagramy BPMN. V této aplikaci je možno kreslit následující UML diagramy. • Diagram objektů, • diagram tříd, • diagram tříd, • diagram komponent, • diagram nasazení, • diagram balíčku, • diagram případu užití, • diagram aktivit, • a sekvenční diagram. Aplikace neumožňuje diagramy ukládat přímo na server, ale formou XML souborů, které si uživatel musí uložit do svého počítače. Otevírání diagramů probíhá formou uploadu XML souboru na server. Vytvořené diagramy je možné exportovat do obrázkových formátů SVG, PNG, GIF a JPG nebo do formátu PDF. Uživatelské rozhraní aplikace je intuitivní, jednoduché a podobné uživatelskému rozhraní, které využívají aplikace společnosti Google, viz obr. 2.6. Aplikace je dostupná na webové adrese http://www.diagram.ly. 34

2.3. Shrnutí

Obrázek 2.6: Uživatelské rozhraní nástroje Cretely

2.3 2.3.1

Shrnutí Funkcionalita

Komerční desktopové nástroje disponují širokým spektrem funkčních vlastností. Většina těchto nástrojů neslouží pouze pro práci s UML, ale snaží se pokrýt větší oblast využití, např. BPMN, SysML, a mnoho dalšího. Využitelnost těchto nástrojů se pohybuje v oblasti návrhu enterprise architektur. Pro tyto účely bych doporučil Enterprise Architect od firmy Sparx Systems nebo některý z produktů Rational Rose firmy IBM. Komerční webové aplikace jsou pro „práci s UML“ doopravdy s uvozovkami. Problémem těchto aplikací je, že vesměs umožňují pouze kreslení diagramů a jejich export do obrázkových formátů, do PDF či jejich sdílení v rámci webu. Výstupem je však jen UML diagram. Deficitem těchto nástrojů je výstup v použitelné formě z implementačního pohledu, např. generování zdrojového kódu, generování databáze apod. Některé nekomerční desktopové aplikace jsou v rámci malých týmu nebo podniků dostatečně použitelné. Mezi takovýto nástroj patří například produkt StarUML, viz kapitola 2.2.1.1. Za zmínku jistě stojí i nástroj AgroUML, viz http://argouml.tigris.org, který nabízí podobné funkční vlastnosti jako produkt StarUML, ale je zaměřen pouze na práci s UML verze 1.4. Část nekomerčních nástrojů je postavena na platformě Eclipse, např. Papyrus, Modelio nebo Topcased. Práce s těmito nástroji je ale poněkud náročnější a než uživatel vymodeluje svůj první diagram, může strávit mnoho času nad čtením návodů, jak se k modelování vůbec dostat. 35

2. Nástroje pro práci s UML, analýza konkurence Nekomerční webové aplikace jsou téměř totožné s komerčními. Jediný zásadní rozdíl je, že neumožňují týmovou spolupráci na projektu v rámci samotné aplikace. Dalším podstatným rozdílem je cena. Tyto aplikace jsou spíše využitelné pro samostatné vývojáře, kteří si chtějí zpřehlednit práci, usnadnit vývoj a utřídit si své myšlenky. Další uplatnění nachází v komunikaci s klientem, kde dostatečně pokryjí základní upřesnění požadavků v podobě use case diagramů. Některé komerční produkty nabízejí volně dostupná řešení v podobě edic pro komunitu, které poskytují jen částečnou funkcionalitu oproti plným komerčním verzím. Tento způsob nabídky můžeme chápat jako marketingový tah, kdy si uživatel na prostředí zvykne a v případě nedostatků komunitní verze je ochoten si software zakoupit za požadovanou cenu, aby rozšířil funkcionalitu a mohl řešit patřičný problém. Seznam komerčních i nekomerčních nástrojů pro práci s UML je dostupný na adrese http://www.diagramming.org.

2.3.2

Uživatelské rozhraní

Většina komerčních nástrojů poskytuje široké funkční vlastnosti, které se odrážejí na komplexnosti uživatelského rozhraní. Uživateli může trvat delší dobu, než si na nástroj zvykne a často se může při hledání určité funkčnosti při práci v nástroji ztrácet. Nekomerční nástroje jsou vytvářeny jako univerzální editory diagramů. Velmi často v těchto editor je veškerá funkčnost rozmístěna viditelně okolo editoru. To nemusí na uživatele působit příjemně a může jej rozptylovat.

2.3.3

Brain Architect a konkurenční řešení

Cílem projektu Brain Architect je vytvořit volně dostupné řešení ve formě webové aplikace zaměřené pouze na oblast UML 2.0, nikoliv jako univerzální nástroj pro kreslení různých diagramů, jako je tomu u konkurence. Mezi další cíle patří vybudování uživatelské a vývojářské komunitu okolo projektu. Většina volně dostupných řešení ve formě webové aplikace neumožňuje stažení samotné aplikace a nasazení na serveru klienta. Tento nedostatek bude Brain Architect řešit nasazením zdrojového kódu na serveru GitHub, kde bude mít uživatel možnost si projekt stáhnout. Vývojáři se budou moci na tomto serveru připojit do vývojové větve a podpořit tak vývoj aplikace. Aby mohl projekt růst a vývojáři byli schopni projekt rozvíjet bude na domovské stránce k projektu zveřejněno aplikační rozhraní pro tvorbu modulů. V neposlední řadě se bude vývoj soustředit na vytvoření kvalitního uživatelského rozhraní a postupně řešit vlastní nedostatky z hlediska UX v závislosti na ohlasu uživatelské komunity.

36

Kapitola

Analýza aplikace 3.1

Vize projektu

Brain Architect bude open source řešení webové aplikace určené k tvorbě UML diagramů. Aplikace bude dostupná přes moderní webové prohlížeče a bude koncipována tak, aby uživatelům, nejen softwarovým inženýrům, nabízela, co nejkvalitnější UX (User Experience). Dále bude architektura aplikace nastavena tak, aby umožňovala v budoucnu rozšiřitelnost aplikace, např. o nové balíčky diagramů či funkční vlastnosti, jako jsou generátor kódu pro různé programovací jazyky, export do formátu pro výměnu dat XMI apod. První verze aplikace bude obsahovat pouze omezené množství diagramů. Bude se jednat o následující diagramy. • Diagram tříd, • diagram objektů, • diagram komponent, • diagram nasazení, • diagram aktivit, • a diagram případu užití.

3.2 3.2.1

Specifikace požadavků Zainteresovaní (uživatelské role)

• Anonymní uživatel bude mít možnost vytvářet projekty a kreslit diagramy bez možnosti jejich uložení na server. Dále bude mít uživatel možnost se zaregistrovat do systému či exportovat diagramy do obrázkového formátu a formátu XML, přičemž XML soubory bude možné nazpět importovat do systému. 37

3

3. Analýza aplikace • Registrovaný uživatel je uživatel, který vlastní uživatelský účet. Bude mít možnost vytváření projektů a diagramů s jejich uložením na server. Dále možnost importu a exportu projektu/diagramu do formátu XML a do obrázkového formátu. Exportované projekty/diagramy ve formátu XML bude mít možnost importovat zpět do systému. • Administrátor aplikace bude rozšířením uživatele registrovaného. Mezi rozšíření tohoto uživatele patří správa uživatelů, diagramů, projektů a nastavení jednotlivých funkčních vlastností pro jednotlivé balíčky diagramů.

3.2.2

Klíčové vlastnosti

• správa projektů • správa diagramů • správa uživatelů • škálovatelnost (rozšiřitelnost) aplikace

3.2.3

Požadavky na systém

3.2.3.1

Funkční požadavky

1. Pro anonymní uživatele (nepřihlášení do systému) bude systém nabízet možnost registrace uživatelského účtu. Po platné registraci bude uživateli zaslán informační email o registraci a aktivační klíč. Přes tento aktivační klíč uživatel zaregistrovaný účet aktivuje. 2. Uživatelé, kteří vlastní uživatelský účet, se budou přihlašovat do systému přes přihlašovací rozhraní. Uživatelé musí mít možnost se ze systému také odhlásit. 3. Anonymní uživatel bude mít omezená práva. Jeho možnosti budou následující. a) Vytváření projektů a jejich úprava. b) Uzavření upravovaného projektu. c) Export projektu do formátu XML a stažení do klientského počítače. d) Import projektu z formátu XML uploadem (nahráním) na server z klientského počítače. e) Vytváření a editace diagramů v rámci vytvořeného projektu. Tj. nastavovat vlastnosti diagramu, spravovat elementy a vztahy mezi nimi. 38

3.3. Analýza a výběr nástrojů pro návrh a realizaci f) Export vytvořených diagramů do formátu XML a stažení uživatelem do klientského počítače. g) Export diagramů do obrázkových formátů JPG a PNG. h) Import diagramů z formátu XML uploadem na server z klientského počítače. 4. Omezení anonymního uživatele spočívá v nemožnosti uložení projektů a diagramů přímo na server, kde bude aplikace provozována. 5. Registrovaný uživatel bude disponovat stejnými právy jako uživatel anonymní s tím rozdílem, že vytvářené projekty a diagramy si může ukládat na server a nastavovat vlastnosti uživatelského účtu. 6. Administrátor systému bude rozšířením uživatele registrovaného. Navíc tato uživatelská role bude nabízet: a) kompletní správu uživatelských účtů, tj. uživatelské účty vytvářet, upravovat a mazat, b) správu projektů, tzn. vytváření projektů, jejich úprava a mazání, c) správu funkčních balíčků, tj. přidávat, odebírat a nastavovat funkční balíčky. 4.2.3.2 Nefunkční požadavky • K systému se bude přistupovat přes moderní webové prohlížeče, tj. Mozilla Firefox a Google Chrome. • Zabezpečení systému bude formou obrany proti XSS (Cross site scripting) a SQL Injection. Hesla uložená v systému budou zahashovaná. • Pro implementaci serverové části budou využity volně dostupná řešení (open source). 1. Serverová část poběží na serveru podporující PHP verzi 5.3 a vyšší. b) Využití relační databáze MySQL jako úložný prostor. 2. Serverová část bude k návrhu architektury využívat MVP architekturu (Model-View-Presenter). • Klientská část aplikace bude implementována s využitím prpogramovacího jazyku JavaScript a značkovacího jazyka HTML 5.

3.3

Analýza a výběr nástrojů pro návrh a realizaci

V této části kapitoly se zaměřím na vybrané technologie, nástroje a knihovny, na nichž bude postaven návrh aplikace a s nimiž aplikaci budu realizovat. Veškeré součásti aplikace poběží a budou stavěny na open-source řešeních. 39

3. Analýza aplikace

3.3.1

PHP 5

PHP neboli Hypertext Preprocessor je skriptovací jazyk, který je využíván převážně k vývoji dynamických webových aplikacích. Na domovské stránce tohoto skriptovacího jazyka, viz http://www.php.net/manual/en/intro-whatis.php, autoři uvádí: PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. PHP může být provozováno na většině operačních systémů, např. Linux, Unix, Microsoft Windows, Mac OS X a mnoho dalších. V dnešní době je PHP podporováno většinou webových serverů. Mezi takové servery patří např. Apache server či IIS neboli Internet Information Services. Tedy, je zde veliká svoboda při výběru operačního systému i webového serveru (22). Existuje i řada rozšíření pro PHP. Tato rozšíření jsou nabízeny ve dvou variantách, jimiž jsou: • PECL neboli PHP Extension Community Library jsou knihovny napsané v jazyce C a jsou instalovány jako rozšíření PHP na webový server administrátory. • PEAR neboli PHP Extension Application Repository jsou knihovny napsané v jazyce PHP. Tudíž jsou libovolně stahovány a užívány dle vlastní potřeby bez administrátorských práv. Tento skritovací jazyk umožňuje procedurální i objektově orientované programování a není náročný na naučení i pro úplně nováčky v programování. Hlavním důvodem, proč jsem tento skriptovací jazyk zvolil je fakt, že se jedná velice rozšířený skriptovací jazyk pro vývoj dynamických webových aplikací. Dalším důvodem je široká dostupnost webových hostingů, které nabízejí podporu PHP a jsou cenově v řádu sto korun. Mezi takové hostingy patří například Wedos, jehož aktuální nabídka je dostupná na webové adrese http://hosting.wedos.com.

3.3.2

PHP Framework

Pokud nechceme řešit v PHP rutinní problémy a chceme zefektivnit průběh naší práce, je na místě využití některého z dostupných frameworků. Tyto frameworky nám poskytují dostatečné aplikační rozhraní, knihovny a další funkce, které nám umožňují se soustředit pouze na námi řešený problém. V dnešní době pro platformu PHP existuje celá řada frameworků. Mezi ty nejnámější patří (28): 40

3.3. Analýza a výběr nástrojů pro návrh a realizaci • Zend framework, který je podporován samotnými vývojáři PHP, • Symphony, • CakePHP , • a Nette framework, který je českým produktem. S jediným frameworkem, se kterým mám praktické zkušenosti je Nette Framework, a proto jej využiji k vývoji. 3.3.2.1

Vlastnosti Nette frameworku

Nette Framework je postaven na čistě objektovém návrhu, jenž využívá vlastnosti skriptovacího jazyka PHP 5, komponent a událostmi řízené modelování. Dle nezávislého testu frameworků, který byl publikován na serveru root.cz, byl ohodnocen Nette Framework jedním z nejrychlejších (3). Velkou výhodou Nette jsou kvalitní ladící nástroje, které vývojářům ulehčují práci a hledání vzniklých chyb. To je řešeno například vizualizací výjimek, které zobrazují místo ve zdrojovém kódu, kde nastala chyba. Dále také poskytuje rozhraní pro propojení s ladícími nástroji Firebug a FireLogger, což nám umožňuje aplikaci ladit pomocí těchto nástrojů (14). Pro formátování výstupu využívá šablonovací systém Latte, který nabízí řadu maker (funkcí pro manipulaci s daty v šabloně), např. podmíněné výrazy, cykly či psaní čistého PHP přímo do šablony. Dalším podpůrným nástrojem Latte jsou helpery, které slouží k transformaci výstupních dat do určité podoby. Mezi helpery patří například funkce lower, která převede všechny písmena výstupu na písmena malá (16). Pro rutinní činnosti, jako je tvorba formulářů, poskytuje Nette framework rozhraní pro jejich tvorbu s nastavitelnými pravidly pro jednotlivé elementy (např. nastavení povinných vstupů, formát vstupu, atd.). Jelikož jsou webové stránky a webové aplikace potenciálním cílem kybernetických zločinců, poskytuje framework zabezpečení před útoky typu XSS, CSRF, URL attack, control codes, Session hijacking a další (17). Od oblíbenosti tohoto frameworku se odráží i komunita, která aktivně přispívá k vývoji, vytváří doplňky, různá rozšíření a přispívá do komunitního fóra. Právě v tomto fóru často vývojáři nacházejí řešení svých problémů. Pro využití a distribuci Nette Frameworku je třeba zvolit jednu ze dvou následujících softwarových licencí (15): • New BSD Licence neklade na využití téměř žádná omezení. Stačí jen zachovat původní copyright. Tato licence umožňuje i komerční využití. • GNU General Public License verze 2 a 3 je určena pro software, jenž je distribuován jako open-source. 41


3.3.3

JavaScript

Pro návrh a realizaci dynamické části aplikace na straně uživatele bude využit skriptovací jazyk JavaScript. Tento skriptovací jazyk byl navržen jako objektově orientovaný, tudíž jeho stavebními kameny jsou objekty. Silnou vlastností tohoto jazyka je referenční systém, který umožňuje odkazovat na objekty pomocí referencí. To nám nabízí velkou míru flexibility (25). V závislosti na sledování interakce uživatele umožňuje JavaScript odchytávání událostí. Pomocí sledování interakce můžeme mapovat na jednotlivé elementy objektového modelu dokumentu události, čímž jsme schopni vytvářet dynamiku aplikace.

3.3.4

AJAX

Termín AJAX byl poprvé uveden v článku „AJAX: A new Approach to Web Application“, jehož autorem je Jesse James Garrett. Zkratka AJAX, neboli Asynchronous Javascript and XML (asynchronní javascript a XML), je pojmenováním technik komunikace mezi klientem a serverem, které jsou využívány k vytváření dynamických webových aplikací (25). Abychom porozuměli tomu, jak funguje komunikace mezi klientem a serverem, je třeba si vysvětlit základní pojmy, které se v komunikaci vyskytují. Jedná se o následující pojmy. • HTTP neboli nebo Hypertext Transfer Protocol je internetový protokol pro přenos hypertextových dokumentů, tedy HTML a podobných souborů. • HTTP request je požadavek, který klient zasílá serveru. Tento požadavek obsahuje hlavičky (nastavení), které specifikují s kým komunikovat, jakým způsobem, jaká data chceme, apod. • Server response je odpověď serveru na požadavek klienta v podobě HTML a zdrojových souborů, které se k tomuto dokumentu vztahují, např. javascriptové soubory, soubory kaskádových stylů, obrázky a jiné. • XHR neboli XMLHttpRequest je aplikační rohraní, které využívají skriptovací jazyky podporované určitým prohlížečem ke komunikaci se serverem na pozadí stránky. K pochopení rozdílu mezi klasickým modelem komunikace a asynchronním modelem komunikace je třeba si vysvětlit, jak jednotlivé typy fungují. Běžná komunikace probíhá následujícím způsobem. 1. Klient otevře spojení k serveru. 2. Klient pošle HTTP request. 42

3.3. Analýza a výběr nástrojů pro návrh a realizaci

Obrázek 3.1: Model ajaxové komunikace ze článku „Ajax: A New Approach to Web Applications“

3. Server tento požadavek zpracuje a odpoví klientovi. 4. Klient přijme odpověď a zpracuje ji. Například, je-li serveru zaslán HTML dokument, celý jej zobrazí. 5. Spojení mezi klientem a serverem se uzavře. Zatímco AJAXová komunikace, zachycena na obrázku obr. 3.1, pracuje následovně. 1. Počáteční komunikace mezi klientem a serverem je totožná jako u synchronní komunikace. 2. Klient otevře spojení k serveru. 3. Klient pošle HTTP request. 4. Server tento požadavek zpracuje a odpoví klientovi. 5. Spojení mezi klientem a serverem se uzavře a server již o klientovi neví. 6. Aby mohla probíhat asynchronní komunikace, je třeba na straně klienta s pomocí JavaScriptu vytvořit XMLHttpRequest a odeslat jej serveru. 43

3. Analýza aplikace 7. Klient následně čeká na odpověď serveru. 8. Po získání odpovědi tuto odpověď zpracuje služba na straně klienta a dle svých potřeb s ním naloží. Např. obnoví některá data na stránce. Rozdíl mezi těmito dvěma přístupy je, že zatímco klasická komunikace vede vždy k načtení celé stránky, asynchronní komunikace vyžaduje načtení stránky pouze jednou a ostatní komunikace probíhá na pozadí stránky. 3.3.4.1

Formát pro výměnu dat

Odpovědí serveru je vždy nějaký formát dat. Takových formátů existuje celá řada, přičemž XMLHttpRequest reálně pracuje pouze s textovými datovými formáty. Základní čtyři formáty, které bývají ze serveru zasílány jsou (25): • XML, jenž jsou automaticky převedeny do dokumentů DOM (Document Object Model). • HTML, který obsahuje textový řetězec reprezentující úryvek HTML kódu. • JavaScript obsahující surový proveditelný JavaScriptový kód. • JSON neboli JavaScript Object Notation, v překladu JavaScriptový zápis objektů.

3.3.5

jQuery

Stejně jako v případě využití PHP frameworku je na místě využití JavaScriptové knihovny, která za nás vyřeší velkou část rutinních problémů. V tomto případě se jedná o JavaScriptovou knihovnu jQuery. Knihovna nabízí velkou řadu funkcí pro manipulaci s objektovým modelem dokumentu, tj. například přidávání, mazání, úpravu jednotlivých elementů či manipulaci s kaskádovými styly. Dále vázání a odchytávání událostí, práci s AJAXem a jiné. Navíc nabízí i rozhraní pro rozšíření, tj. tvorbu modulů, což umožňuje knihovnu škálovat. Knihovna je navržena jako cross-browser, tudíž je využitelná na všech majoritních prohlížečích, jmenovitě Google Chrome, Mozilla Firefox verze 3.6 a vyšší, Safari 5.0 a vyšší, Opera, Internet Explorer 6.0 a vyšší (10). O popularitě této knihovny svědčí její využití na webových stránkách společnosti Google, Dell, Bank of America a jiné (11). Dokumentace knihovny je dostupná na adrese http://docs.jquery.com. 44

3.3. Analýza a výběr nástrojů pro návrh a realizaci 3.3.5.1

jQuery UI

Rozšířením knihovny jQuery je knihovna jQuery UI, která nabízí nástroje pro práci s uživatelským rozhraním. V základní verzi nabízí řadu widgetů (např. datepicker – výběr data pomocí kalendáře), elementů uživatelského rozhraní (např. tlačíka, dialogy), interakce (např. drag & drop – umožňuje elementy posouvat pomocí myši) a vizuálních efektů. Veškeré možnosti této knihovny jsou dostupné na webové adrese http://jqueryui.com. Pro widgety si vývojáři či designeři mohou navrhnout i své vlastní téma (vzhled) pomocí nástroje Theme Roller, který je dostupný na stránkách projektu na adrese http://jqueryui.com/themeroller/. Knihovna je podporována prohlížeči IE 6.0+, Firefox 3+, Safari 3.1+, Opera 9.6+ a Google Chrome. Znaménko + vyjadřuje a vyšší verze. Podrobná dokumentace knihovny jQuery UI je dostupná na webové adrese http://jqueryui.com/demos/.

3.3.6

Knihovna pro vykreslování diagramů

Vzhledem k tomu, že by časová náročnost vytvoření vlastní knihovny na vykreslování diagramů pokryla samotnou bakalářskou práci, jsem se rozhodl využít volně dostupnou knihovnu pro vykreslování diagramů. 3.3.6.1

SVG vs. HTML 5 canvas

Základním rozdílem mezi SVG a HTML 5 canvas, dále jen canvas, je ve způsobu reprezentace dat. SVG je orientováno na práci s vektorovým formátem, který je reprezentován elementy objektového modelu dokumentu (DOM). Oproti tomu se canvas zaměřuje rastrový formát (dvourozměrné pole pixelů), tedy výstupem je vždy rastrový obrázek (29). Dalším rozdílem mezi těmito způsoby vykreslování webové grafiky je způsob odchytávání interakce uživatele v rámci plátna (plocha, kde jsou objekty vykreslovány). Vzhledem k faktu, že SVG využívá k vykreslování objektový model dokumentu, má možnost mapovat a odchytávat události pomocí JavaScriptu na jednotlivých elementech dokumentu. To v případě reprezentace dat canvasu nelze a je třeba tuto funkčnost samostatně implementovat. Dle nezávislého testu, který provedl Boris Smus, publikovaného 19. ledna roku 2009 na webové adrese http://smus.com/canvas-vs-svg-performance/, vyplývají následující výsledky. První test spočíval v testování závislosti doby vykreslení na počtu objektů. Z grafu, viz obrázek 3.2, je patrné, že s rostoucím počtem objektů formát SVG v prohlížeči Safari nabývá téměř exponenciální nárůstu vykreslovací doby. Zatímco v prohlížeči Mozilla Firefox je křivka lineární a v porovnání s vykreslovací dobou canvasu roste strměji. Výsledek se odráží od způsobu vykreslování objektů. Jelikož SVG vykresluje elementy objektové modelu dokumentu, musí držet veškeré reference na tyto objekty, aby je mohl vykreslit. Naproti tomu 45


Obrázek 3.2: Graf porovnání doby vykreslení v závislosti na počtu objektů (29)

výstup canvasu je vždy dvourozměrný obrázek o stejných rozměrech, tedy vždy je potřeba vykreslit stejný počet pixelů. Druhý test se zaměřil na dobu vykreslení v závislosti na výšce plátna, viz obrázek 3.3. Nejmenší dopad má velikost plátna na formát SVG, který udržuje téměř konstantní hladinu. Canvas s rostoucí výškou plátna v prohlížeči Safari roste strměji než v prohlížeči Firefox. V případě canvasu je tento jev dán nárůstem počtu pixelů, které je nutné překreslit. Z výše provedených testů vyplývá, že formát SVG v rámci webových aplikací nalézá využití spíše ve vykreslování menšího počtu objektů nezávisle na velikosti plátna a canvas naopak pro vykreslování většího počtu objektů na menších plátnech. V rámci tohoto projektu jsem se rozhodl použít k vykreslování diagramů formát SVG z následujících důvodů. 1. Možnost mapování událostí na jednotlivé elementy objektového modelu dokumentu pomocí JavaScriptu. 2. Dostupné řešení k vykreslování diagramů s využitím SVG. Knihovna JointJS viz kapitola 3.3.6.2. 3. Aplikace nebude určena pro vykreslování enormního počtu objektů. Do počtu 400 objektů by měla stále pracovat efektivně, viz testy výše. 46

3.3. Analýza a výběr nástrojů pro návrh a realizaci

Obrázek 3.3: Graf porovnání doby vykreslení v závislosti na výšce vykreslovací plochy (29)

3.3.6.2

JointJS

Časová náročnost vytvoření vlastní knihovny na vykreslování diagramů s využitím formátu SVG by pokryla samotnou bakalářkou práci. Z tohoto důvodu jsem se rozhodl využít volně dostupné řešení. Jedná se o knihovnu JointJS, jejíž autorem je David Durman. Knihovna, jak již bylo zmíněno, pracuje s formátem SVG. Základem této knihovny je knihovna RaphaelJS, jenž je určená k manipulaci s vektorovými formáty na webu, přesněji SVG a VML, viz webová adresa http://raphaeljs.com. Výhodou této knihovny je podpora majoritních webových prohlížečů. Na webové stránce projektu je uvedena podpora pro: • Google Chrome 3.0+, • Mozilla Firefox 3.0+, • Internet Exporer 6.0+, • Opera 9.5+, • Safari 3.0+. Podrobné informace o knihovně jsou dostupné na webové stránce projektu na adrese http://www.jointjs.com. 47

Kapitola

Návrh V této kapitole je popsán kompletní návrh pro realizaci aplikace. Vybrané technologie k návrhu a realizaci jsou upřesněny v předchozí kapitole, viz kapitola 3.3. Návrh aplikace je zaměřen na serverovou a klientskou část aplikace. Nejprve je popsána architektura společně a následně už separátně.

4.1

Architektura aplikace

Diagram, viz obrázek D.2, zachycuje kompletní architekturu aplikace, která je rozdělena na dvě základní části. Jedná se o část serverovou a část klientskou. Klientská část aplikace poběží na klientském počítači ve webovém prohlížeči. O logiku této části aplikace se bude starat knihovna Brain Architect Application (dále jen BAApplication). Bude implementována pomocí skriptovacího jazyka JavaScript. Stuktura této části je popsána v kapitole 4.3. Serverová část běží na cizí nebo vlastní serverové stanici, na které je dostupný webový server s podporou skriptovacího jazyka PHP 5.3. Jedná se o část, která je implementována v jazyce PHP. Návrh této části je popsán v kapitole 4.2.

4.2

Serverová část aplikace

Účelem serverové části aplikace je vytvoření vrstvy, která bude zpracovávat požadavky zasílané z klientské části aplikace a dále vytvořit administrační rozhraní, přes které budou zpracovávány jednotlivé části systému (uživatelé, diagramy, projekty, funkční balíčky) v rámci serveru. Architektura serverové části je zachycena na diagramu, viz obrázek přílohy. D.1.

4.2.1

MVC

Serverová část aplikace bude navržena s ohledem na vlastnosti Nette frameworku. Právě zvolený framework využívá softwarovou architekturu MVP 49

4

4. Návrh neboli Model-View-Presenter. Tato architektura vychází ze softwarové architektury MVC neboli Model-View-Controler, jejíž cílem je rozdělit jednotlivé vrstvy aplikace do disjunktních částí. Rozdíl mezi těmito architekturami je ve způsobu interakce. Zatímco vzor MVC zachycuje reakce uživatele v controlleru, vzor MPV reaguje na reakci uživatele skrze view, který požadavek následně deleguje ke zpracování na presenter (8). MVP Nette frameworku rozděluje aplikaci do tří základních částí, jimiž jsou Model, View a Presenter. Model reprezentuje logickou část aplikace, tedy tu část, která řeší doménový problém. V našem případě poslouží jako vrstva mezi presentery aplikace a vrstvou pro objektově relační mapování. View neboli pohled reprezentuje data předaná od presenteru. Pro realizaci view (pohled) využiji šablonovací systém Latte, který je integrován přímo v Nette frameworku. Tento šablonovací systém rozlišuje dvě základní šablony. 1. Layout, jenž určuje rozmístění prvků na stránce, tedy jejich strukturu. 2. Template má již specifičtější využití, a to reprezentaci částí, jenž jsou v kládány do layoutu. Účelem Presenterů je hned několik. Hlavním účelem je výběr pohledu v závislosti na zasílaných požadavcích, jenž jsou odesílány z pohledů v závislosti na interakci uživatele. Dalším posláním presenterů je přiřazování dat, např. z doménového modelu, do šablony, která se stará o jejich reprezentaci v prezentační vrstvě. (7)

4.2.2

Databáze a ORM

Pro databázovou vrstvu bude použita relační databáze MySQL. Pro odstínění datového a doménového modelu použijeme objektově relační mapování s využitím knihovny Doctrine 2. To nám zajistí, že doménový model aplikace bude pracovat nezávisle na znalosti implementace použitého datového modelu a databáze. Doménový model bude s datovým modelem spolupracovat pouze skrze rozhraní datového modelu. Framework Doctrine 2 pro datové modely využívá takzvané entity. Jednotlivé entity v sobě specifikují strukturu databázové vrstvy. V případě relační databáze odpovídá jedna entita jedné tabulce v použité databázi. Definice jednotlivých entity můžeme vytvářet ve formátu XML, YAML či přímo PHP (4). V našem případě využijeme přímo třídy skriptovacího jazyka PHP. K mapování dat na entity využívá framework návrhový vzor data mapper (5). ORM framework Doctrine 2 je koncipován tak, aby vývojářům usnadňoval práci s databázovou vrstvou. Výhodou tohoto frameworku je zaměnitelnost jednotlivých typů databáze. Tedy, pokud v budoucnu budeme chtít zaměnit databázi MySQL za PostgreSQL, stačí změnit v konfiguraci frameworku driver (řadič) a údaje o připojení k databázi. 50

4.2. Serverová část aplikace

Obrázek 4.1: Balíček tříd serverové části

4.2.3

Návrh tříd

Návrh serverové části aplikace je rozdělen do tří skupin, viz obrázek 4.1. Jedná se o třídy presenterů, modelů obsahující aplikační logiku a entit, které využívá ORM framework Doctrine2. 4.2.3.1

Presentery

Návrh tříd presenterů je rozdělen do dvou balíčků, viz obrázek přílohy D.4. Jedná se o administrační část aplikace (backend), viz obrázek přílohy D.5, a uživatelskou část aplikace (frontend), viz obrázek přílohy D.6. V případě uživatelské části se budou starat o zpracování požadavků zasílané z prezentační vrstvy (view) následující presentery. • AccountPresenter určený k obsluze registrací, aktivací a resetování hesel uživatelských účtů. • AuthPresenter neboli autentizační presenter určený k přihlašování uživatelů do systému a odhlašování uživatelů ze systému. • ImportPresenter a ExportPresenter pro práci s importery a expotery aplikace. • WorkspacePresenter k obsluze požadavků týkající se vytvářených projektů a diagramů. Návrh tříd administrační části je složitější než část uživatelská. Jelikož do této části systému budou mít přístup pouze administrátoři systému, je zde navržena třída presenteru SecuredPresenter. Ve které bude na začátku zpracování každého požadavku kontrolováno, zdali má uživatel potřebná přístupová práva, tedy zdali je administrátorem. 51

4. Návrh V této části systému se opakují veškeré rutinní činnosti, tj. vytváření, editace, čtení mazání záznamů, v případě správy uživatelů a balíčků jejich aktivace a deaktivace. Z tohoto důvodu vychází jednotliví potomci z abstraktní třídy CRUDPresenter, která bude poskytovat implementaci opakujících se částí. Vlastnost model třídy CRUDPresenter určuje model s nímž potomci pracují. Tento model bude v potomcích nastaven v metodě startup. Pro autentizační činnosti je zde třída AuthPresenter, která je určena k přihlašování do systému a odhlášení ze systému. 4.2.3.2

Modely

Navržené modely jsou zachyceny na diagramu tříd, viz obrázek přílohy D.7. Zde uvedená abstraktní třída AbstractDoctrineCRUD je předkem ostatních tříd (vyjímaje Exporter a Importer). Tato třída bude implementovat základní aplikační logiku, která spočívá v práci s datovými entitami. Vlastnost třídy entityName specifikuje v potomcích této třídy název entity, se kterou potomci pracují. Jednotliví potomci budou přepisovat metody create a update. Metoda create bude sloužit k vytváření nových instancí datových entit, k jejich naplnění daty a komunikaci s entity managerem ORM frameworku s cílem uložení těchto dat v relační databázi. Metoda update bude sloužit k aktualizaci dat dané entity. 4.2.3.3

Entity

Diagram tříd, viz obrázek přílohy D.8, zachycuje základní entity systému. ORM framework Doctrine 2 umožňuje vytvoření předka pro jednotlivé entity, kterého nazýváme superclass. V našem případě se jedná o abstraktní třídu BaseEntity. Účelem této entity je držet informace o identifikátoru entity a poskytnou rozhraní pro přístup k ní (metoda getId). Ostatní třídy uvedené na diagramu tříd jsou potomky třídy BaseEntity a jsou určeny k držení dat specifické domény, např. třída entity typu Package dřží informace o funkčním balíčku.

4.3

Klientská část aplikace

Na diagramu tříd, viz obrázek přílohy D.3, jsou rozděleny základní třídy klientské části do třech balíčků. • Core obsahující třídy problémové domény aplikace. • GUI popisujicí návrh vlastního řešení grafického uživatelského rozhraní. • Widget navrhující třídy Widgetů, které budou využívány v základní verzi aplikace. 52

4.3. Klientská část aplikace

4.3.1

Core (jádro aplikace)

Ústředním bodem této části je třída Application, jenž bude jádrem celé aplikace. Bude sloužit jako fasáda pro kompletní správu jednotlivých částí aplikace. Třída je navržena tak, aby podporovala správu projektů, jejich diagramů, správu widgetů, ajaxovou komunikaci, atd. Návrh třídy je zachycen na diagramu tříd, viz obrázek přílohy D.9. Třídy Project a Diagram reprezentují datové modely projektů a diagramů, které jsou v projektu vytvářeny. Třída Container bude sloužit k vytváření seznamů objektů.

4.3.2

GUI

Graphical User Interface neboli grafické uživatelské rozhraní aplikace bude z části využívat vlastní řešení a z části knihovny jQuery a jQuery UI. Návrhový model tříd je zachycen na obrázku, viz příloha D.11. Jelikož nám jQuery nabízí rozhraní pro manipulaci s objektovým modelem dokumentu (DOM), využijeme této možnosti k vytváření a zajištění dynamické části aplikace. Dynamickou částí aplikace je myšleno nastavování handlerů (obsluha událostí) na akce uživatele pro jednotlivé elementy aplikace. Mezi hlavní handlery eventů (odchytávání událostí), které využijeme jsou click (kliknutí myší) a hover (pozice myši nad elementem). Pro dynamické vytváření formulářů je v návrhu uvedena třída Form a pro reprezentaci prvků formuláře třída Control a její potomci.

4.3.3

Widgety

Abychom mohli editor jednoduše rozšiřovat, zajistíme podporu vytváření a správy widgetů. Widgety jsou samostatné jednotky vlastnící aplikační logiku nezávislou na okolí. V našem případě bude při registraci widgetu do aplikace předán odkaz na aplikaci. Tím zajistíme, že widget bude mít možnost manipulovat s aktuálními daty projektu. Dle diagramu, viz obrázek přílohy D.10, implementuje každý z widgetů následující metody. • Metoda init k inicializaci hodnot widgetu. • Create je určena k vytvoření HTML widgetu. • Open je určena k zobrazení widgetu. • Close je určena ke schování widgetu. • SetApplicationReference slouží k nastavení reference na objekt aplikace. • GetApplicationReference je určena k získání reference na objekt aplikace. 53

4. Návrh • Update aktualizace widgetu. Příkladem widgetu v základní verzi aplikace bude Toolbar (nástrojová lišta) či Diagram manager (správce diagramů). Toolbar neboli nástrojová lišta je určen k přidávání elementů do jednotlivých diagramů. Účelem správce diagramů je zobrazení aktuálních diagramů upravovaného projektu a manipulaci s nimi, tj. otevírání, zavírání, mazání a možnost zobrazení dialogu s nastavením diagramu.

4.3.4

Vykreslování diagramů

Jelikož knihovna JointJS v dostupné verzi umí pouze statickou definici elementů a vztahu mezi nimi, je třeba provést pár úprav, aby byla tato knihovna dynamičtější. Jedná se o následující úpravy. 1. Přidání nastavitelné obsluhy události double click (dvojklik myší) pro jednotlivé prvky (element, vztah) diagramu. 2. Přidání rozhraní pro nastavení výběru typu vztahu mezi elementy. 3. Přidání dynamického nastavení velikosti elementů.

4.4

Komunikace mezi klientskou a serverovou částí

Pro komunikaci mezi serverou a klientskou částí bude využito techniky asynchronního modelu komunikace. AJAX viz kapitola 3.3.4. Tento způsob nám umožní výměnu dat na pozadí klientské části aplikace s částí serverovou. Formát pro výměnu dat bude použit JSON, se kterým je schopen skriptovací jazyk Javascript manipulovat. Nette framework poskytuje rozhraní pro zpracování AJAXových požadavků na straně serveru a také je volně dostupné rozšíření jQuery Nette, jenž umožňuje zpracovávat odpovědi zasílané ze strany serveru v klientské části. Pro odesílání požadavků z klientské části bude použito rozhraní knihovny jQuery.

4.5

Funkční balíčky

Pro zajištění modulárnosti systému bude systém umožňovat správu jednotlivých funkčních balíčků. Tyto funkční balíčky jsou určené např. k definici nových diagramů, exporterů a importerů. Pro každý balíček bude vytvořen definiční soubor ve formátu XML a bude sloužit jako zdroj informací o balíčku. Tzn. že v tomto balíčku budou specifikovány následující informace. • Name specifikuje jméno balíčku, 54

4.5. Funkční balíčky • version identifikuje verzi balíčku, • author udává jméno autora, • type určuje typ funkčního balíčku, • description reprezentuje popis balíčku, • sources specifikuje zdrojové soubory (items) aplikační logiky implementované v skriptovacím jazyce JavaScript. Administrátor v administračním rozhraní bude mít možnost tyto balíčky načítat pomocí scannerů. Tyto scannery budou prozkoumávat file system (souborový systém) serverové části a vyhledávat definice balíčků definované v XML souborech. Tyto balíčky budou následně přidány do relační databáze aplikace. Administrátor je buď aktivuje nebo deaktivuje. Po každé provedené změně bude třeba přebudovat kompletní zdrojový soubor klientské části aplikace. Přebudováním je myšleno spojení souborů obsahujících aplikační logiku jednotlivých balíků a samotného jádra aplikace do jednoho souboru, který je přes protokol HTTP přenášen na klientskou část aplikace. Pro tuto činnost bude v administrační části aplikace obslužná metoda rebuild.

4.5.1

Definice diagramů

Definice diagramů bude vycházet z koncepce knihovny JointJS. Tedy jednotlivé elementy diagramů budou definovány jako JavaScriptové objekty. Tímto způsobem zajistíme vytvoření funkčního balíčku diagramu. Abychom tento balíček mohly v aplikaci využít, bude jej třeba do aplikace zaregistrovat pomocí metody registerDiagramType třídy Application. Parametry této metody jsou name (název) a javascriptový objekt obsahující title (titulek) a type (typ diagramu). Zaregistrované balíčky budou zobrazeny v navigační části uživatelského rozhraní, skrze které je bude mít uživatel možnost vytvářet.

4.5.2

Exportery a Importery

Abychom porozuměli, k čemu nám tyto funkční balíčky slouží, vysvětlím jejich význam. Exporter bude funkční balíček, jenž bude určen pro transformaci dat z aplikace např. do obrázkového formátu. Tedy exportery nám umožňují převod dat aplikace do nějaké jiného formátu, jenž je dále využíván mimo aplikaci. Zatímco importer je opakem. Slouží k transformaci z nějakého datového formátu do formátu, který je schopen využívat tato aplikace. Např. import z formátu XML, zdrojových kódu apod. 55

4. Návrh Tato část funkčních balíčků je rozdělena do dvou skupin. Tyto skupiny určují na jaká data se importer/exporter orientuje. Může se orientovat na data diagramů nebo data projektů. I tyto balíčky musí být zaregistrovány do aplikace, aby je mohli uživatelé využívat. Pro registraci jednotlivých typů importerů a exporterů bude třeba volat následující metody: • registerDiagramExporter zaregistruje exporter diagramů, • registerProjectExporter zaregistruje exporter projektů, • registerDiagramImporter zaregistruje importer diagramů, • registerProjectImporter zaregistruje importer projektů. Součástí těchto balíčků je vytvoření šablony, která je při volání exporteru zobrazena v klientské části a skrze kterou mohou uživatelé manipulovat s daným balíčkem. JavaScriptová část balíčků bude sloužit k zaregistrování balíčku, získávání dat projektů a diagramů a jejich odesílání na server ke zpracování. Část implementovaná v programovacím jazyce PHP bude sloužit k transformaci dat, které budou zasílány na server. Např. převod SVG formátu do formátu JPG, PNG a jiné. Výsledky exportů budou reprezentovány datovým formátem, který může být reprezentován ve výstupní HTML šabloně, či přesměrováním ke stažení vytvořeného souboru exportu. Jelikož komunikace bude probíhat pomocí asynchronního modelu komunikace, budou mít importery k dispozici metodu processAjaxResponse ve tříde Application. Pomocí této metody budou mít možnost zavolat některou ze zaregistrovaných obslužných metod pro zpracování odpovědí asynchronní komunikace. Tímto způsobem je zaručena možnost manipulace s daty v rámci klientské části aplikace.

56

Kapitola

5

Realizace 5.1

Jmenné prostory

Skriptovací jazyk PHP 5.3 podporuje práci se jmennými prostory. Díky této vlastnosti můžeme jednotlivé části systému strukturovat do logických celků (modulů). Aplikace má základní namespace pojmenovaný BrainArchitectModule. Kromě presenterů aplikace mají všechny části systému namespace BrainArchitect. Presentery jsou rozděleny do dalších základních modulů, a to: 1. FrontendModule obsahující uživatelskou část presenterů, 2. a BackendModule obsahující administrační část presetenterů.

5.2

Nastavení aplikace

Nette framework 2.0 umožňuje nastavení skrze konfigurační soubor config.neon. V rámci aplikace využitejeme konfigurační soubor k nastavení: 1. modelů obsahující aplikační logiku, 2. připojení k databázi, 3. a konfiguraci ORM frameworku (Doctrine 2). Nastavení modelů pomocí konfiguračního souboru nám umožní přistupovat k jednotlivým modelům přes kontext aplikace, tedy nebudeme muset vytvářet instance modelů ručně na všech místech, kde je budeme potřebovat, ale konfigurační soubor a dependency injection se nám o vytvoření postarají sámi. Pro konfiguraci ORM frameworku a vytvoření instance entityManageru (správce entit) využijeme další vlastnosti Nette. Jedná se o vytváření tzv. services (služeb), které jsou po spuštění aplikace přístupné přes její kontext. 57

5. Realizace

5.3

Nastavení routeru aplikace

Jednotlivé požadavky, které přicházejí od uživatele, musíme být schopni rozlišit a přesměrovat na presenter, jenž daný požadavek zpracuje. K tomuto účelu slouží routování. Segment zdrojového kódu, viz příloha E.1, ukazuje definici jedné routy. Je zde vidět instanční proměnná $container, která obsahuje nastavení aplikace, tedy i nastavení jednotlivých rout. K tomuto nastavení se přistupuje skrze vlastnost router. Pro nastavení nové routy je potřeba vytvořit novou instanci třídy Route, jejíž parametry jsou: 1. Formát URL – části, které jsou zapsány mezi znaky menší a větší umožňují dynamicky mapovat presentery a jejich akce. 2. Implicitní nastavení částí. • module – modul aplikace, ve které se presenter nachází, specifikuje jmenný prostor, který presenter využívá a adresář, ve kterém je soubor presenteru uložen. • presenter – určuje jaký presenter má být využit ke zpracování požadavku. • action – metoda presenteru, která má být zavolána. Například pokud přistoupíme na adresu http://addr.cz/admin/users/, bude pro zpracování tohoto požadavku použit presenter UserPresenter administrační části systému.

5.4

Presentery

Implementace presenterů v Nette frameworku probíhá dvěma způsoby. 1. Vlastní implementací rozhraní Nette\Application\IPresenter. 2. Vytvoření potomků třídy Nette\Application\UI\Presenter, která již veškerou potřebnou aplikační logiku implementuje za nás. Vzhledem k faktu, že používáme Nette framework, aby nám usnadnil, co nejvíce práce, využijeme druhou variantu. Tedy, budeme vytvářet potomky výše zmíněné třídy. Ke každému presenteru je potřeba vytvořit šablonu. Tato šablona je určena pro prezentaci dat, které jí jsou předány presenterem. Dalším účelem šablon je vykreslování komponent vytvořených v presenteru. Jméno šablony a její umístění je odvozeno od jména presenteru a akce, která je na presenteru volána. Např. budeme-li volat metodu actionDefault na presenteru AccountPresenter, je třeba mít vytvořenou šablonu default.latte v adresáři templates/Account. 58

5.5. Úprava knihovny JointJS Na ukázce zdrojového kódu, viz příloha E.2, je zobrazena konstrukce presenteru. V tomto případě se jedná o segment kódu presenteru starající se obsluhu uživatelských účtů v klientské části aplikace. Tento presenter v sobě obsahuje vytvoření komponenty aktivačního formuláře (řádek 12) pomocí metody createComponentActivationForm s parametrem name – prefix createComponent je identifikátorem metody pro vytvoření komponenty, tzv. tovární metody, a ActivationForm je název komponenty, která je vkládána do šablony. Abychom zobrazili vytvořenou komponentu v šabloně, musíme v ní zapsat macro (funkce šablony) {control ActivationForm}. Metoda createComponentActivationForm v sobě vytváří formulář. Důležitou částí tohoto kódu je řádek 24. Zde je nastavena obslužná funkce, která je v případě validity (požadovaný formát vstupu, např. číslo, email, atd.) vstupních dat volána. Tato metoda je na ukázce zdrojového, na řádce 36.

5.5

Úprava knihovny JointJS

Jak je uvedeno v předchozí kapitole, viz kapitola 4.3.4, bylo třeba provést několik úprav na této knihovně, aby byla dostatečně použitelná v rámci této práce.

5.5.1

Obsluha události double click elementů diagramu

Abychom mohli jednotlivé elementy upravovat, v našem případě pomocí dialogů obsahující editační formuláře, bylo třeba upravit třídu Joint.dia.Element. Úprava spočívala v nastavení obslužné funkce na událost dvojklik myší a při této události funkci zavolat. Do objektu Joint.dia.Element byla přidána proměnná dblClickCallback a metoda setDblClickCallback s parametrem callback, jenž určuje funkci, která má být při zachycení události volána. V případě, že pomocí této metody je nastavena v definici elementu diagramu nějaká metoda, je vždy po dvojkliku na element zavolána. V našem případě je vždy nastavena metoda otevírající dialog s editačním formulářem a nastavením patřičných vlastností a hodnot do formuláře. Pro získání informací o daném objektu musí funkce, která je nastavená na výše popsanou událost, obsahovat jeden parametr. Do tohoto parametru je při zavolání funkce vložena reference objektu, na němž byla událost provedena. Tímto způsobem můžeme dále s objektem manipulovat.

5.5.2

Nastavení typu a editace vztahů mezi elementy

Pro výběr typu vztahu mezi elementy a editace vztahu byly do objektu Joint přidány dvě proměnné. 59

5. Realizace 1. Proměnná connectionEditor drží objekt, pomocí kterého můžeme upravovat vlastnosti jednotlivých vztahů v diagramu. 2. Proměnná connectionTypeSelector který drží objekt, jehož účelem je výběr typu vztahu před jeho vytvořením v diagramu. Pro obě proměnné byly přidány getter a setter metody. Účelem setterů je nastavení objektů, které jsou určeny k výše popsané funkci. Getter metody zase k získání nastaveného objektu. V případě, že je nastaven objekt pro výběr typu vztahu, zavolá objekt Joint při přidání nového vztahu mezi elementy do diagramu metodu getSelectedType na nastaveném objektu. Tímto získá data nastaveného typu vztahu a ty následně aplikuje při na nově vytvoření vztah. Struktura vztahů je popsána v kapitole 5.6.2. Zavolání objektu editoru probíhá při odchycení události dvojklik (double click) myší na na vztah. V případě, že je nastaven nějaký objekt editoru v proměnné connectionEditor, je na tomto objektu zavolána metoda setReference, která nastavuje editoru objekt vztahu, nad kterým událost proběhla a následně metoda open, která editor otevře.

5.5.3

Dynamické nastavení velikosti elementu

Jelikož knihovna JointJS neumožňovala dynamické nastavení velikosti elementů, tj. manipulaci s velikostí objektu na plátně diagramu, bylo třeba tuto vlastnost elementů implementovat. Implementace spočívala v přidání grafického elementu obdélníku s osmi záchytnými body, viz obrázek 5.1. Každý ze záchytných bodů reprezentuje jeden ze stavů, jenž upřesňuje v jakém směru můžeme měnit velikost elementu. Na jednotlivé záchytné body jsou nastaveny obsluhy akce mouseDown (stistknuté tlačítko myši) a mouseMove (pohyb myši). V případě, že uživatel klikně myší na daný bod a zároveň pohybuje kurzorem, element mění velikost. Díky tomu může uživatel měnit velikost elementu v horizontálním i vertikálním směru.

5.6

Tvorba balíčků diagramů

Pro vytváření jednotlivých typů diagramů budeme vycházet z koncepce definice elementů diagramů, které nabízí knihovna JointJS a změnám, které jsem provedl v rámci úprav této knihovny.

5.6.1

Definice grafických elementů

Knihovna JointJS nabízí rozhraní pro rozšíření elementů. Nové elementy diagramů jsou definovány pomocí funkce extend objektu Element. Ukázková definice nového elementu je uvedena v příloze E.10. 60

5.6. Tvorba balíčků diagramů

Obrázek 5.1: Nastavení velikosti elementu

Do výše zmíněné funkce je předáván parametr ve formě objektu. Tento parametr má specifikovanou vlastnost object, která drží název elementu, vlastnost module, která specifikuje modul (typ diagramu), kterému daný element náleží, a obslužné metody. V rámci úprav knihovny JointJS přibyla vlastnost index, která specifikuje hloubku elementu v diagramu. Ta je využívána při dynamickém přidávání vztahů pro určení prioritního elementu, na který má být vztah aplikován. Čím vyšší číselnou hodnotu index nabývá, tím má nižší prioritu. Metoda init slouží k inicializaci elementu. Tj. nastavení implicitních hodnot daného objektu. V metodě od řádku 39 do řádku 52, viz zdrojový kód přílohy E.10, jsou přidány řádky, které jsou určeny k nastavení editačního dialogu elementu. Na řádku 39 je volána metoda create, která daný dialog vytvoří. Dále zde probíhá nastavení obslužné metody pro událost dvojklik myší. Tato metoda umožňuje nastavit hodnoty z elementů diagramů do vstupních elementů editačního formuláře a následně tento dialog otevřít. Tvorba editačních dialogů je popsána v sekci 5.6.3.

5.6.2

Definice vztahů

Definování typů vztahů mezi elementy spočívá ve vytváření javascriptových statických objektů. Vlastnost attrs je určena ke specifikaci grafické reprezentace vztahu. Title specifikuje titulek, který zobrazuje BAConnectionTypeSelector při výběru typu asociace. Při přidání nového vztahu v editaci diagramu je v některých případech (např. pro nastavení stereotypu vztahu) potřeba ihned manipulovat s daty daného vztahu. K tomu nám slouží vlastnost onSet. Této vlastnosti můžeme nastavit obslužnou funkci, která je při vytvoření vztahu v diagramu zavolána, přičemž do parametru funkce je přiřazena reference na nově vytvořený vztah. Tímto způsobem můžeme manipulovat s nově vytvářenými vztahy hned po jejich vytvoření. 61

5. Realizace Abychom mohli využívat definované vztahy, je třeba je do aplikace zaregistrovat. K tomu slouží objekt BAConnectionTypeSelector a jeho metoda addModule. První parametr specifikuje název typu diagramu, který může tyto vztahy využívat. Do druhého parametru vkládáme javascriptový objekt, který obsahuje název vztahu a referenci na objekt vztahu. Ukázkový zdrojový kód takové definice je uveden v příloze, viz zdrojový kód E.8

5.6.3

Editační dialogy

Pro editaci jednotlivých elementů je třeba vytvořit editační dialogy, které se skládají z vytvoření dialogového okna a formuláře, pomocí kterého je manipulováno s daty elementů. Dialogy reprezentuje javascriptový objekt Dialog. Tento objekt neimplementuje část vytváření dialogového okna v rámci objektového modelu dokumentu, ale využívá k tomu modul jQuery UI dialog. Při vytváření nové instance objektu jsou zadávány parametry: • name – název dialogu, • title – titulek dialogu, • content – obsah dialogu • properties – specifikace vlastností, které jsou aplikovány na modul knihovny jQuery UI Dialog. Pro tvorbu editačních formulářů je určen javascriptový objekt BAForm. Aby byl zobrazen ve vytvořeném dialogu vytvořený formulář, je potřeba zavolat metodu objektu BAForm render, která tento formulář vykreslí, tzn. vytvoří nové elementy objektového modelu dokumentu. Vykreslený formulář je předán na místo parametru specifikující obsah dialogového okna. Tím dosáhneme toho, že budemem mít v dialogovém okně vykreslen fomulář. Pro nastavení hodnot jednotlivých vstupů formuláře slouží metoda setValues a pro získání hodnot metoda getValues. Ukázka zdrojového kódu vytváření editačních dialogových oken je uveden v příloze, viz E.7.

5.7

Převod diagramů do obrázkových formátů

Na obrázku je 5.2 je uvedena hierarchie souborů exporteru pro převod diagramů do obrázkových formátů. Implementace tohoto exporteru se skládá z následujících částí. 62

5.8. Vyhledávání funkčních balíčků

Obrázek 5.2: Adresářová struktura exporteru ExportToImage

• definition.xml – obsahuje definici exporteru, která je načítána pomocí scannerů (viz kapitola 5.8). Ukázka definičního souboru je uvedena v příloze, viz E.3. • Exporter.php – obsahuje aplikační logiku transformace. Ukázka zdrojového kódu exporteru, viz příloha E.4. • ExporterWidget.php – obsahuje definici třídy, která vytváří widget, jenž je reprezentován v klientské části aplikace. Ukázka zdrojového kódu je uvedena v příloze, viz E.5. • default.latte – obsahuje šablonu widgetu. • register.js – javascriptový soubor obsahující registraci do aplikace. Zdrojový kód je uveden v příloze, viz E.6.

5.8

Vyhledávání funkčních balíčků

Tato část systému je určena k vyhledávání a poskytování informací o funkčních balíčcích, které se nalézají na serveru v adresáři ./app/packages/. Za tímto účelem je vytvořena třída PackageScanner. Pro vyhledávání těchto definic je použit nástroj Finder Nette Frameworku. Pro manipulaci s tímto nástrojem je poskytováno následující rozhraní: • findFiles($mask) – vyhledá soubory dle parametru metody. V případě této aplikace bude vkládán jako parametr řetězec definition.xml. • in – určuje složku, ve které mají být soubory vyhledávány. Vyhledává se pouze v úrovni dané složky. • from – je stejný případ jako metoda in, s tím rozdílem, že je zde využito rekurzivního vyhledávání. Pro čtení informací o funkčních balíčcích je použita třída SimpleXML, která umožňuje jednoduše číst informace z XML souborů. 63

5. Realizace

5.9

Shrnutí

Implementace probíhala v návaznosti na vytvořeném návrhu aplikace. Časově nejnáročnější částí byla implementace grafického uživatelského rozhraní v programovacím jazyce JavaScript a úprava knihovny JointJS. Implementace serverové části aplikace byla rutinní a nenáročná. Převážně se jednalo o komunikaci s databází pomocí implementovaných modelů a předdefinovaných datových entit. O zbylé funkční vlastnosti a logiku se za nás postaral framework Nette. Jako podpůrné nástroje pro ladění aplikace byl využit přídavný modul Firebug a FireLogger pro webový prohlížeč Mozilla Firefox. Díky těmto nástrojům bylo možné rychleji napravit vzniklé chyby.

64

Kapitola

Testování Abychom zaručili, že aplikace bude spolehlivě pracovat, je testování aplikace nedílnou součástí vývojového cyklu software. Testováním docílíme snížení pravděpodobnosti výskytu chyb, na které může uživatel při používání softwaru narazit.

6.1

Průběžné testování

Pro průběžné testování funkčních požadavků specifikovaných v analytické části práce, viz kapitola 3, probíhalo testování již ve fázi implementace. Veškerá implementace byla ručně otestována ihned po jejím vytvoření či po jakékoliv provedené změně. Využitím tohoto způsobu testování bylo umožněno včasné nalezení vznikajících chyb, které by bylo mnohem složitější hledat v době, kdy projekt začínal nabývat větších rozměrů. Pro účely průběžného testování byly využity přídavné moduly Firebug a FireLogger pro webový prohlížeč Mozilla Firefox. Pomocí nástroje FireLogger bylo možné kontrolovat přímo v prohlížeči data, která jsme odesílali na server, průběh jejich zpracování a výsledky. Nástroj Firebug byl užitečný pro kontrolu dat nacházející se v klientské části aplikace.

6.2

Akceptační testování

Po nasazení aplikace na produkční server byly provedeny akceptační testy, které pokrývají otestování funkčních požadavků. Tyto požadavky byly specifikovány v kapitole 3. Jednotlivé testy a jejich výsledky jsou zachyceny v tabulce 6.1. 65

6

6. Testování Tabulka 6.1: Výsledky akceptačních testů Požadavek Pro anonymní uživatele (nepřihlášení do systému) bude systém nabízet možnost registrace uživatelského účtu. Po platné registraci bude uživateli zaslán informační email o registraci a aktivační klíč. Přes tento aktivační klíč uživatel zaregistrovaný účet aktivuje. Přihlášení do systému. Odhlášení ze systému. Vytvoření projektu a jeho editace. Uzavření upravovaného projektu. Export projektu do formátu XML. Export diagramu do formátu XML. Export diagramu do formátu JPG a PNG. Vytvoření diagramu a jeho editace, tj. nastavení vlastností diagramu, správa elementů a vztahů mezi nimi. Import projektu z formátu XML. Import diagramu z formátu XML. Uložení diagramu na server. Uložení projektu na server. Administrace – správa uživatelských účtů, tj. vytvoření, úprava a smazání účtu. Administrace – správa projektů, tj. vytvoření, úprava a smazání projektu. Administrace – správa balíčků aplikace, tj. přidávání, odebírání a nastavení balíčků.

6.3

Splněno Ano

Ano Ano Ano Ano Ano Ano Ano Ano Ano Ano Ano Ano Ano Ano

Hodnocení uživatelů

K získání subjektivních názorů od uživatelů na aplikaci bylo využito vytvoření elektronického dotazníku pomocí služby Google Docs. Otázky dotazníku se převážně týkaly grafického uživatelského rozhraní a celkového dojmu, jenž aplikace evokovala v uživatelích při používání nástroje. V dotazníku byly uživatelům položeny následující otázky. 1. Jak hodnotíte grafické uživatelské rozhraní aplikace? a) pěkné b) průměrné c) nelíbí se mi 2. Užívání aplikace je a) intuitivní, 66

6.3. Hodnocení uživatelů b) celkem intuitivní, c) neintuitivní, vůbec se v tom nevyznám. 3. Co byste změnili, či co Vás na editoru mate? 4. Jaký používáte prohlížeč? a) Firefox b) Chrome c) Opera d) Safari e) IE 5. Celkové hodnocení aplikace na stupnici 1–5. Známkování jako ve škole. Nejlépe uživatelé hodnotili grafické uživatelské rozhraní, kde jej 93 % označilo za pěkné a pouhých 7 % za průměrné. Dále aplikace byla ohodnocena jako intuitivní od 40 % hodnotících uživatelů. Stejné procento uživatelů hodnotilo aplikaci jako celkem intuitivní a zbylých 20 % uživatelů hodnotilo aplikaci jako neintuitivní. V celkovém hodnocení aplikace na stupnici 1–5 dosáhla aplikace v průměru známky 1,93.

67

Závěr Cílem této bakalářské práce byl návrh a implementace webové aplikace pro tvorbu UML diagramů. Na prvním prototypu této aplikace jsem pracoval se dvěma dalšími studenty v rámci předmětu Softwarový projekt I a II. Díky tomuto prototypu jsem měl v pokračování jasnější cíle a představy o tom, jak by aplikace měla fungovat a vypadat. V první řadě jsem se zaměřil na stručný popis a historii vizuálního modelovacího jazyka UML a analýzu nástrojů, které podporují práci s tímto jazykem. Z analýzy konkurence jsem získal základní přehled o stavu aktuálně dostupných řešení, ze kterého jsem dále mohl čerpat inspiraci a snažit se vyvarovat nedostatkům, které nástroje obsahují. V analytické části aplikace jsem se soustředil na popis vize projektu, sepsání funkčních požadavků a stručný popis nástrojů zvolených pro návrh a realizaci aplikace. Jak již bylo zmíněno v prvním odstavci, byl v dřívější době vytvořen první prototyp aplikace. V rámci bakalářské práce jsem aplikaci od základu přebudoval. Jak návrh, tak implementaci. To se projevilo časově náročnější, než jsem předpokládal. Nicméně se mi podařilo veškeré funkční vlastnosti aplikace implementovat. Nepodařilo se mi implementovat pouze některé typy diagramů. Momentálně aplikace umožňuje vytvářet pouze dva typy, a to diagramy případu užití a diagramy tříd. Aplikace byla testována průběžně při implementaci a na závěr ve formě akceptačních testů. Způsob a popis testování je uveden v kapitole 6. Mimo definované požadavky jsem pro nástroj zaregistroval doménu a vytvořil webovou stránku, která je momentálně dostupná na webové adrese http://www.brainarchitect.net.Zde budou, kromě základních informací o nástroji, postupně doplňovány informace pro vývojáře a novinky z vývoje. Kromě webové prezentace nástroje jsem také zaregistroval účty na sociálních sítích Twitter a Facebook, skrze které je možné nástroj propagovat. Osobním přínosem této práce hodnotím získání přehledu o jednotlivých konkurenčních produktech, jejich nedostatcích a nedostatcích mého nástroje, 69

Závěr které mi jsou motivací do budoucna. Dalším přínosem práce bylo studium literatury zabývající se vizuálním modelovacím jazykem UML a v neposlední řadě praktická zkušenost s návrhem a implementací webové aplikace. Ze subjektivního hlediska hodnotím kladně vytvořené uživatelské rozhraní aplikace, které bylo též součástí mých cílů při započetí práce na projektu. Co nehodnotím kladně je praktický výsledek. Přestože jsem dosáhl požadovaných cílů, jsem nespokojen, jelikož by aplikace mohla být navržena a implementována lépe.

Další vývoj projektu Vývoj tohoto webového nástroje ukončením bakalářské práce nekončí. Aplikace se stala ve svém průběhu implementace terčem určitých firem, které by produkt rády využívaly. Proto je v budoucnosti třeba projekt dále rozvíjet. Hlavními cíli do budoucna jsou: • vybudování uživatelské a vývojářské komunity, • vytvoření vlastní knihovny pro vykreslování diagramů, • doplnění zbylých diagramů, které vůči specifikaci UML 2.0 chybí. V neposlední řadě bude třeba zapracovat na uživatelském rozhraní v závislosti na odezvě uživatelské komunity. Právě samotní uživatelé by měli mít na vývoj projektu v budoucnosti největší vliv.

70

Literatura (1) Ambler, S. W.: UML 2 Use Case Diagrams. Dostupné z WWW: (2) Beneš, M.: Přehled OO notací a metodik. Dostupné z WWW: (3) Daněk, P.: Velký test PHP frameworků: Zend, Nette, PHP a RoR. 9 2008. Dostupné z WWW: (4) The Doctrine Project: 4. Basic Mapping - Doctrine 2 ORM 2.2 documentation. Dostupné z WWW: (5) The Doctrine Project: Getting Started - Doctrine 2 ORM 2.2 documentation. Dostupné z WWW: (6) Frost, S.: Rumbaugh’s OMT - The method behind C++ Designer. 1 1993. Dostupné z WWW: (7) Grudl, D.: Nette Framework: MVC & MVP. 3 2009. Dostupné z WWW: (8) Grudl, D.: Prezentační vzory z rodiny MVC. 5 2009. Dostupné z WWW: (9) Jim Arlow, I. N.: UML 2 a unifikovaný proces vývoje aplikací: Objektově orientovaná analýza a návrh prakticky. Brno: Computer Press, a.s., 2007, ISBN 978-80-251-1503-9. 71

Literatura (10) The jQuery Project: Browser Compatibility. Dostupné z WWW: (11) The jQuery Project: The Write Less, Do More, JavaScript Library. Dostupné z WWW: (12) Massimo Marino, J. W.: The Booch Method of Object-Oriented Analysis & Design. 1 2001. Dostupné z WWW: (13) Massimo Marino, J. W.: The Booch Models. 1 2001. Dostupné z WWW: (14) Nette Foundation: Debugování a zpracování chyb. Dostupné z WWW: (15) Nette Foundation: Licenční politika. Dostupné z WWW: (16) Nette Foundation: Šablony. Dostupné z WWW: (17) Nette Foundation: Zabezpečení před zranitelnostmi. Dostupné z WWW: (18) Object Management Group, I.: Introduction to OMG’s Unified Modeling Language (UML). 3 2011. Dostupné z WWW: (19) Object Management Group, I.: Object Management Group - UML. 7 2011. Dostupné z WWW: (20) Object Management Group, I.: Object Management Group - UML. 7 2011. Dostupné z WWW: (21) Pavus: UML : úvod a historie. Červen 2005. Dostupné z WWW: (22) The PHP Group: PHP: What can PHP do? - Manual. Dostupné z WWW: (23) The PHP Group: PHP: What is PHP? - Manual. Dostupné z WWW: (24) Rejnková, P.: Příklady použití diagraml UML 2.0. 2009. Dostupné z WWW: 72

Literatura (25) Resig, J.: JavaScript a Ajax: Moderní programování webových aplikací. Brno: Computer Press, a.s., 2007, ISBN 978-80-251-1824-5. (26) Sabrina Schönhart, A. M.: The Booch Method - OOD. Dostupné z WWW: (27) Sabrina Schönhart, A. M.: Object-Oriented Software Engineering OOSE. Dostupné z WWW: (28) Stoupa, V.: Přehled a vývoj PHP frameworků. 8 2008. Dostupné z WWW: (29) Sucan, M.: SVG or Canvas? Choosing between the two. 6 2010. Dostupné z WWW: (30) Systems, S.: UML Tutorial - Part 2. Dostupné z WWW: (31) Totland, T.: Object Modeling Technique. 8 2007. Dostupné z WWW: (32) TutorialsPoint.COM: UML Object Diagram. Dostupné z WWW:

73

Příloha

Seznam použitých zkratek BA Brain Architect BPMN Asynchronous javascript and XML BPMN Business process model and notation BSD Berkeley software distribution CASE Computer aided software engineering CPU Central processing unit CRUD Create, read, update, delete CSFR Cross-site request forgery DOM Document object model EMF Enhanced metafile ER Entity-relationship ERD Entity-relationship diagram EJB Enterprise JavaBeans GUI Graphical user interface GoF Gang of four GPL General public license HP Hewlet Packard HTML Hypertext markup language HTTP Hypertext transfer protocol 75

A

A. Seznam použitých zkratek IBM International Business Machines IIS Internet information services JPEG Joint photographic experts group JS Javascript JSON Javascript object notation MOF Meta-object facility MVC Model-view-controller MVP Model-view-presenter OO Object-oriented, objektově orientovaný OS Operační systém OOD Object-oriented design OOAD Object-oriented analysis and design OOSE Object-oriented software enginnering OMG Object management group OMT Object modeling technique OPEN Object-oriented process, environment and notation ORM Object-relational mapping PDF Portable document format PHP Hypertext Preprocessor, původně Personal home page PNG Portable network graphics SW Software SysML Systems modeling language SQL Structured query language SVG Scalable vector graphics UML Unified modeling language URL Uniform resource locator UI User interface 76

UP Unified process UX User experience VB Visual basic VML Vector markup language XHR XMLHttpRequest XML Extensible markup language XMI XML metadata onterchange XSS Cross-site scripting YAML YAML ain’t markup language

77

Příloha

Obsah přiloženého CD

readme.txt...................................stručný popis obsahu CD exe ....................... adresář se spustitelnou formou implementace src impl...................................zdrojové kódy implementace thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce thesis.pdf ............................. text práce ve formátu PDF thesis.ps ................................ text práce ve formátu PS 79

B

Příloha

Analytický model

Obrázek C.1: Zainteresovaní – uživatelské role

Obrázek C.2: Případ užití – registrace uživatele 81

C

C. Analytický model

Obrázek C.3: Případ užití – přihlášení do systému, odhlášení ze systému

Obrázek C.4: Případ užití – správa projektů

82

Obrázek C.5: Případ užití – správa diagramů projektu

83

C. Analytický model

Obrázek C.6: Případ užití – správa elementů diagramu

84

Obrázek C.7: Případ užití – správa uživatelských účtů

Obrázek C.8: Případ užití – správa balíčků

85

Příloha

Návrhový model

Obrázek D.1: Architektura serverové části aplikace

87

D

D. Návrhový model

Obrázek D.2: Architektura aplikace

88

Obrázek D.3: Balíček tříd klientské části

Obrázek D.4: Balíček presenterů

89

D. Návrhový model

Obrázek D.5: Návrh tříd presenterů backendu aplikace

Obrázek D.6: Návrh tříd presenterů frontendu aplikace

90

Obrázek D.7: Návrh tříd modelů aplikace

91

D. Návrhový model

Obrázek D.8: Diagram tříd datových entit

92

Obrázek D.9: Návrh tříd jádra aplikace klientské části

93

D. Návrhový model

Obrázek D.10: Návrh tříd widgetů

94

Obrázek D.11: Návrh tříd pro grafické uživatelské rozhraní

95

Příloha

E

Ukázky zdrojových kódů Listing E.1: Nastavení routeru 1 2 3 4 5 6 7

$ c o n t a i n e r −>r o u t e r [ ] = new Route ( ’ admin/< p r e s e n t e r >/ ’ , array ( ’ module ’ => ’ B r a i n A r c h i t e c t : Backend ’ , ’ p r e s e n t e r ’ => ’ D e f a u l t ’ , ’ a c t i o n ’ => ’ d e f a u l t ’ ) );

Listing E.2: Descriptive Caption Text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

namespace B r a i n A r c h i t e c t M o d u l e \ FrontendModule ; c l a s s A c c o u n t P r e s e n t e r extends B a s e P r e s e n t e r { ... /∗ ∗ ∗ A c t i v a t i o n form component ∗ @param t y p e $name ∗/ public f u n c t i o n createComponentActivationForm ( $name ) { $ a c t i v a t i o n F o r m = new Form ( ) ; $ a c t i v a t i o n F o r m −>addText ( ’ e m a i l ’ , ’ ’ ) −>s e t R e q u i r e d ( ’ P l e a s e ␣ f i l l ␣ your ␣name . ’ ) ; $ a c t i v a t i o n F o r m −>addText ( ’ a c t i v a t i o n _ c o d e ’ , ’ ’ ) −>s e t R e q u i r e d ( ’ P l e a s e ␣ f i l l ␣ your ␣ a c t i v a t i o n ␣ code . ’ ) −>s e t A t t r i b u t e ( ’ p l a c e h o l d e r ’ , ’ A c t i v a t i o n ␣ code ’ ) ; $ a c t i o v a t i o n F o r m −>addSubmit ( ’ s a v e ’ , ’ A c t i v a t e ␣ a c c o u n t ’ ) ;

97

E. Ukázky zdrojových kódů 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61

$ a c t i o v a t i o n F o r m −>o n S u c c e s s [ ] = c a l l b a c k ( $this , ’ activationFormSubmitted ’ ) ; $ t h i s −>addComponent ( $ r e g i s t e r F o r m , $name ) ; } /∗ ∗ ∗ A c t i v a t i o n form h a n d l e s u b m i t t e d ∗ @param Form $form ∗ @throws E n t i t y E x i s t s E x c e p t i o n ∗/ public f u n c t i o n a c t i v a t i o n F o r m S u b m i t t e d ( Form $form ) { try { $ v a l u e s = $form−>g e t V a l u e s ( ) ; $ u s e r = $ t h i s −>c o n t e x t −>userModel −>findOneBy ( Array ( " e m a i l " => $ v a l u e s −>e m a i l ) ) ; $ t h i s −>c o n t e x t −>userModel −>a c t i v a t e ( $ u s e r −>g e t I d ( ) ) ; $ t h i s −>c o n t e x t −>userModel −>s e n d A c t i v a t i o n E m a i l ( $ u s e r −>g e t I d ( ) ) ; $ t h i s −>r e d i r e c t ( ’ a c t i v a t e d ’ ) ; } catch ( E n t i t y E x i s t s E x c e p t i o n $e ) { $ t h i s −>f l a s h M e s s a g e ( $e−>getMessage ( ) , } catch ( BadActivationCodeException $e ) { $ t h i s −>f l a s h M e s s a g e ( $e−>getMessage ( ) , } catch ( U s e r A c c o u n t A c t i v a t e d E x c e p t i o n $e ) $ t h i s −>f l a s h M e s s a g e ( $e−>getMessage ( ) , }

’ error ’ ); ’ error ’ ); { ’ error ’ );

} ... }

Listing E.3: XML definice funkčního balíčku 1 2 3 <package> 4 ExportToImage 5 Diagram e x p o r t e r 6 Brain A r c h i t e c t Team 7 Package i s used t o t r a n s f o r m diagram 8 t o image f o r m a t s JPG and PNG

98

9 1 . 0 10 <s o u r c e s> 11 12 13

Listing E.4: Datový exporter 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

namespace B r a i n A r c h i t e c t \ E x p o r t e r s \ ExportToImage ; c l a s s Exporter extends \ BrainArchitect \ Exporters \ AbstractExporter { public function export () { $data = $ t h i s −>getData ( ) ; $svg = $data [ ’ svg ’ ] ; $format = $data [ ’ format ’ ] ; i f ( $svg == ’ ’ ) { r e t u r n ’ ’ ; } $im = new \ Imagick ( ) ; $im−>r e a d i m a g e b l o b ( ’ ’ . $svg ) ; $im−>borderImage ( ’ b l a c k ’ , 1 , 1 ) ; $im−>s e t i m a g e f o r m a t ( $format ) ; $im−>drawimage ( $frame ) ; r e t u r n $im ; } }

Listing E.5: Widget datového exporteru 1 2 3 4 5 6 7 8 9 10 11 12 13 14

use \ BrainArchitect \ Exporters ; namespace B r a i n A r c h i t e c t \ E x p o r t e r s \ ExportToImage ; c l a s s ExporterWidget e x t e n d s \ BrainArchitect \ Exporters \ AbstractExporterWidget { p u b l i c f u n c t i o n handleExport ( ) { $ p o s t = $ t h i s −>g e t P r e s e n t e r ( ) −>g e t R e q u e s t ()−> g e t P o s t ( ) ; $format = $ t h i s −>getParam ( ’ format ’ ) ;

99

E. Ukázky zdrojových kódů 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

$ e x p o r t e r = new E x p o r t e r ( ) ; $ e x p o r t e r −>s e t D a t a ( Array ( " svg " => $ p o s t [ ’ data ’ ] , " format " => $format )); $ r e s u l t = $ e x p o r t e r −>e x p o r t ( ) ; $ r e s u l t = ’ data : image / ’ . $format . ’ ; base64 , ’ . base64_encode ( $ r e s u l t ) ; $ t h i s −>template −>r e s u l t = $ r e s u l t ; } public function render () { $ t e m p l a t e = $ t h i s −>t e m p l a t e ; $template −>s e t F i l e ( dirname (__FILE__) . ’ / templates / default . l a t t e ’ ) ; $template −>r e n d e r ( ) ; } }

Listing E.6: Zdrojový kód souboru register.js exporteru diagramů do obrázkových formátů 1 2 App . r e g i s t e r D i a g r a m E x p o r t e r ( 3 ’ ExportToImage ’ , 4 ’ To␣ image ’ , 5 ’ Export ␣ diagram ␣ t o ␣ image ’ ) ;

Listing E.7: Vytváření editačních dialogů 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

var useCaseActorEditForm = new BAForm( diagramTypeName + ’−a c t o r −e d i t ’ ) ; var useCaseActorGeneralTab = useCaseActorEditForm . addTab ( ’ g e n e r a l ’ , ’ G e n e r a l ’ ) ; useCaseActorGeneralTab . addText ( ’ name ’ , ’Name ’ ) ; var u s e C a s e A c t o r E d i t D i a l o g = new D i a l o g ( diagramTypeName + ’−a c t o r −e d i t ’ , ’ Edi t ␣ a c t o r ’ , useCaseActorEditForm . r e n d e r ( ) , { modal : true , form : useCaseActorEditForm , buttons : {

100

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

"Ok" : f u n c t i o n ( ) { var r e f e r e n c e = $ ( this ) . d i a l o g ( ’ option ’ , ’ r e f e r e n c e ’ ) ; var form = $ ( t h i s ) . d i a l o g ( ’ o p t i o n ’ , ’ form ’ ) ; var v a l u e s = form . g e t V a l u e s ( ) ; r e f e r e n c e . setName ( v a l u e s . g e n e r a l . name ) ; r e f e r e n c e . update ( ) ; form . r e s e t V a l u e s ( ) ; $ ( this ) . d i a l o g ( ’ c l o s e ’ ) ; }, " Cancel " : f u n c t i o n ( ) { $ ( this ) . d i a l o g ( ’ c l o s e ’ ) ; } } });

Listing E.8: Vytváření typů vztahů pro elementy diagramu 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

IncludeRelationship = { attrs : { a t t r s : { ’ s t r o k e −d a s h a r r a y ’ : ’−− ’ } , endArrow : { type : " s i m p l e a r r o w " , s i z e : 4} }, t i t l e : ’ Include ’ , type : ’ i n c l u d e ’ , onSet : f u n c t i o n ( r e f ) { ref . setStereotype ( ’ include ’ ) ; } }; BAConnectionTypeSelector . addModule ( ’ u s e c a s e ’ , { ’ include ’ : IncludeRelationship });

Listing E.9: Registrace typu diagramu do aplikace 1 2 3 4

App . r e g i s t e r D i a g r a m T y p e ( diagramTypeName , { t i t l e : ’ Use ␣ Case ’ , type : diagramTypeName } ) ;

Listing E.10: Definice grafického elementu diagramu 1

101

E. Ukázky zdrojových kódů 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

u s e c a s e . Boundary = Element . extend ( { o b j e c t : ’ Boundary ’ , module : diagramTypeName , index : 0 , i n i t : f u n c t i o n ( p r o p e r t i e s ){ var p = J o i n t . DeepSupplement ( this . properties , properties , { // a t t r s : { f i l l : ’ none ’ , s t r o k e : ’ none ’ } , attrs : { s t r o k e : ’ #000000 ’ }, l ab e lO f f se t X : 10 , l ab e lO f f se t Y : 10 , view : { name : { a t t r s : { f i l l : ’ black ’ } , o f f s e t Y : 10 } } }); t h i s . setName ( ’ System ’ ) ; // wrapper t h i s . setWrapper (w = t h i s . paper . r e c t ( p . r e c t . x , p . r e c t . y , p . r e c t . width , p . rect . height ) . attr (p . attrs ) ) ; t h i s . addInner ( t h i s . getNameElement ( ) ) ; // boundary d i a l o g useCaseBoundaryEditDialog . c r e a t e ( ) ; this . setDblClickCallback ( f u n c t i o n ( r e f e r e n c e ){ var form = useCaseBoundaryEditDialog . g e t O p t i o n ( ’ form ’ ) ; form . s e t V a l u e s ( { g e n e r a l : r e f e r e n c e . getName ( ) }); useCaseBoundaryEditDialog . s e t O p t i o n s ( { reference : reference });

102

51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86

useCaseBoundaryEditDialog . open ( ) ; }); }, /∗ r e t u r n s t e x t e l e m e n t c o n t a i n s name o f e l e m e n t ∗/ getNameElement : f u n c t i o n ( ) { var p = t h i s . p r o p e r t i e s , bb = t h i s . getBBox ( ) ; var t e x t = t h i s . paper . t e x t ( bb . x + bb . width / 2 , bb . y + p . view . name . o f f s e t Y , t h i s . getName ( ) ) . a t t r ( p . view . name . a t t r s ) ; return t e x t ; }, /∗ u p d a t e e l e m e n t ∗/ update : f u n c t i o n ( ) { t h i s . i n n e r [ 0 ] . remove ( ) ; t h i s . i n n e r [ 0 ] = t h i s . getNameElement ( ) ; t h i s . i n n e r [ 0 ] . wholeShape = t h i s ; t h i s . i n n e r [ 0 ] . parentElement = t h i s ; i f ( t h i s . i n n e r [ 0 ] . _isElement ) t h i s . i n n e r [ 0 ] . p r o p e r t i e s . parent = this . euid ( ) ; i f ( ! t h i s . i n n e r [ 0 ] . _isElement && t h i s . _opt && t h i s . _opt . d r a g g a b l e ) { t h i s . i n n e r [ 0 ] . mousedown ( t h i s . d r a g g e r ) ; t h i s . i n n e r [ 0 ] . node . s t y l e . c u r s o r = " move " ; } } });

103

Příloha

F

Instalační příručka Kompletní aplikace je dostupná ke stažení na serveru GitHub na adrese https://github.com/BrainArchitectTeam/BrainArchitect nebo na webové stránce projektu http://www.brainarchitect.net/downloads.

F.1

Systémové požadavky

1. Operační systém Linux (doporučeno) či Windows, 2. webový server Apache 2 (doporučeno) či IIS, 3. podpora PHP 5.3 a modulu mod_rewrite, 4. databáze MySQL (doporučeno) či jiné podporované databáze ORM frameworkem Doctrine 2, viz kapitola F.3. Na diagramu nasazení, viz obrázek F.1, jsou zachyceny jednotlivé části běhového prostředí, které je doporučeno pro provoz aplikace. Na těchto uvedených částech byla aplikace vyvíjena a otestována.

F.2

Instalace aplikace

1. Stáhněte aplikaci ze serveru GitHub či z webové prezentace projektu. 2. Rozbalte aplikaci pomocí dekomprimačního programu např. UnZip či WinRar. 3. Obsah rozbaleného staženého souboru nakopírujte na cílový server, např. pomocí FTP manažeru Total Commander. 4. V kořenovém adresáři aplikace nastavte v souboru .htaccess odpovídající RewriteBase. 105

F. Instalační příručka

Obrázek F.1: Diagram nasazení aplikace Brain Architect

5. Nastavení připojení k databázi, viz kapitola F.3. 6. Importujte schéma relační databáze pomocí administračního rozhraní databáze. Například. phpMyAdmin nebo Adminer. Toto schéma je uloženo v souboru ba_database.sql a je určeno pro relační databázi MySQL. 7. Spusťte aplikace na vámi určené webové adrese.

F.3

Nastavení připojení k databázi

Konfigurační config.neon naleznete ve složce app/config. Zde je třeba nastavit připojení k databázi. Jedná se o následující položky: • hostname – adresa databázového serveru, • user – uživatelské jméno, • password – heslo, • dbname – název databáze. Položku driver nastavujte v případě využití jiné databáze než je MySQL. Databázové drivery, které jsou ORM frameworkem podporovány naleznete na adrese: http://goo.gl/OEQhr. 106

Příloha

Ukázky výsledné aplikace

Obrázek G.1: Úvodní obrazovka aplikace

107

G

G. Ukázky výsledné aplikace

Obrázek G.2: Dialogové okno aplikace pro vytvoření nového projektu

Obrázek G.3: Ukázka editace diagramu

108

Obrázek G.4: Ukázka uživatelského rozhraní exporteru pro převod diagramů do obrázkových formátů

Obrázek G.5: Administrační uživatelské rozhraní aplikace

109

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

Recommend Documents