Projekt Kreslítko X36ASS

Transkript

1 Projekt Kreslítko X36ASS Petr Diviš a Zdeněk Papež ČVUT FEL Praha, listopad 2010 divispe2@fel.cvut.cz, papezzde@fel.cvut.cz Abstrakt Tato zpráva popisuje návrh, vývoj a porovnání dvou softwarových architektur pro předmět X36ASS na FEL ČVUT. Byly použity architektury MVC (Model-View-Controller) a PAC (Presentation-Abstraction-Control) na aplikaci jednoduchého grafického editoru. Aplikace byla v obou případech vyvinuta jako stand-alone aplikace v Javě. Projektový repozitář je k nalezení na adrese I. ÚVOD Jako problém, na který byly obě architektury implementovány, byl zvolen jednoduchý grafický editor. Hlavními funkčními požadavky na editor byly: vytváření a editace základních geometrických tvarů, možnost jejich seskupování a změna jejich pořadí v ose Z. Požadavky jsou zachyceny v use case diagramu (viz obrázek 1). Editor byl zvolen jako stand-alone aplikace v jazyce Java. A. Scénáře II. NÁVRH Základní uživatelská interakce je popsána následujícími scénáři. Editace objektu Cíl případu užití: Přesunout jeden objekt a zvětšit jeho velikost a jiný tvar odstranit. Aktéři: 1) uživatel 2) systém Vstupní podmínky: Na ploše je již vytvořeno několik objektů. Výstupní podmínky: První objekt je přemístěn a zvětšen, druhý objekt je odstraněn. Základní scénář: 1) Uživatel na ploše vybere objekt 2) Systém vybraný objekt zvýrazní 3) Uživatel objekt přesune 4) Systém objekt umístí na nové místo 5) Uživatel změní velikost objektu 6) Systém změní velikost objektu 7) Uživatel zruší označení 8) Systém vybraný objekt znevýrazní 9) Uživatel vybere objekt 10) Systém vybraný objekt zvýrazní 11) Uživatel smaže označený objekt 12) Systém objekt odstraní z kreslící plochy Seskupování objektů Cíl případu užití: Vytvoření nové skupiny objektů, změna její velikosti a pozice. Odstranění existující skupiny objektů. Aktéři: 1) uživatel 2) systém Vstupní podmínky: Na ploše je již vytvořeno několik objektů, některé z nich ve skupině. Výstupní podmínky: Několik objektů je seskupeno, přesunuto a jejich velikost je změněna. Zvolená skupina objektů je odstraněna. Základní scénář: 1) Uživatel na ploše vybere několik objektů 2) Systém jednotlivé objekty zvýrazňuje 3) Uživatel z označených objektů vytvoří novou skupinu objektů 4) Systém zvýrazní skupinu jako celek 5) Uživatel skupinu objektů přesune 6) Systém změní pozici všech objektů ve skupině 7) Uživatel změní velikost skupiny objektů 8) Systém změní velikost skupiny jako celku 9) Uživatel zruší označení 10) Systém skupinu znevýrazní 11) Uživatel vybere skupinu objektů 12) Systém zvýrazní celou skupinu jako celek 13) Uživatel smaže označenou skupinu objektů 14) Systém skupinu odstraní z kreslící plochy B. Funkční požadavky 1) Tvorba a editace základních geometrických objektů Program zvládne vytvořit několik typů geometrických obrazců, u kterých se může měnit jejich poloha a velikost. 2) Výběr barvy objektu Program dovolí volit barvy objektů, které bude uživatel kreslit. 3) Seskupování objektů

2 Obrázek 1. Use Case Diagram Program umožní seskupovat objekty do skupin. 4) Práce s pořadím v ose Z Program umožní přesouvat objekty do popředí nebo pozadí. C. Nefunkční požadavky 1) Aplikace napsaná v JAVĚ Aplikace bude naprogramována v programovacím jazyku Java v obou architektonických verzích. 2) OOP s použitím MVC a PAC Bude využito objektové programovací paradigma a architektonické návrhové vzory Model-View-Controller pro první verzi programu a Presenter-Abstraction- Controller pro druhou verzi programu. 3) Verze 1 - jedno okno První verze bude mít jen jedno okno s panely nástrojů umístěnými uvnitř. 4) Verze 2 - více oken Druhá verze bude mít více oken. Každé okno bude obsahovat jinou sadu nástrojů a okna budou navzájem spolupracovat. Okna mohou nebo nemusí být zobrazena. 5) Dobrá ovladatelnost Aplikace bude dobře ovladatelná pro neznalého uživatele. 6) Aplikace bude fungovat při představení Aplikace bude dobře fungovat, když ji budeme představovat při druhé prezentaci. D. Řešení pomocí MVC 1) MVC obecně: Obecnou architekturu MVC ukazuje schematicky obrázek 2. Model MVC je zaměřen na odstínění dat od uživatelské interakce a je dobře popsán například v [1]. Vzor MVC umožňuje například navázání několika pohledů (View) zároveň nad jedním společným modelem. V našem případě je pohledem kreslící plátno, které zobrazuje jednotlivé tvary, které mají své rozměry a souřadnice. Změna parametrů pohledu, jako jsou v našem případě změna zoomu nebo posunutí výřezu, který plátno zobrazuje, nemá žádný vliv na rozměry tvarů v modelu. V tomto případě se pouze uplatňuje zobrazovací transformace a pokud by existoval jiný pohled nad stejným modelem, ten by tímto zůstal neovlivněn. Obrázek 2. MVC Schéma[4] 2) Naše MVC řešení: Hlavní okno obsahuje panely, které mají společný model a controller. Panel kreslícího plátna a stavu aplikace sledují model a upravují své zobrazení v závislosti na událostech DrawingEvent, které se v modelu generují a rozesílají na všechny zaregistrované listenery DrawingListener. Screenshot výsledné aplikace je ukázán na 3. E. Datový model Obrázek 3. MVC Aplikace Námi navržená aplikace s architekturou MVC vznikla jako první a je postavena nad datovým modelem na obrázku 4.

3 Obrázek 4. Datový model

4 F. Sekvenční diagram Na sekvenčním diagramu na obrázku 5 je znázorněna komunikace při přidání nového tvaru kliknutím uživatele na kreslící plochu. Nejprve controller komunikuje s modelem, aby zjistil, zda bylo kliknuto do prázdného místa (a nejedná se tedy o označení již existujícího objektu). Dalším krokem je vykonání připraveného příkazu typu AddCommand, který byl pro kontroler připraven panelem nástrojů. V poslední fázi je dobře patrné vykreslení tvarů pomocí vzoru Visitor (viz volání metod accept a visit). G. Řešení pomocí PAC 1) PAC obecně: Aplikace je rozdělená hierarchicky na samostatné agenty (jak jsou jednotlivé moduly hierarchické struktury PAC nazývány v [2]). Agenti mají podobnou strukturu jako MVC, jejich části se ovšem nazývají Presentation, Abstraction a Control. Schéma architektury znázorňuje obrázek 6. Někdy se také PAC nazývá, trochu nesprávně, hierarchickým MVC [3]. Příbuuznost mezi MVC a PAC vychází z přejmenování Modelu na Abstraction, View na Presenter a Controlleru na Control. V PAC ovšem dochází k podstatné změně - PAC striktně odděluje abstraction od presentation. Tyto dvě části spolu komunikují výhradně přes prostředníka, kterým je control. 2) Naše PAC řešení: Aplikaci tvoří samostatná okna s panely nástrojů a plochou na kreslení, obdobně jako je tomu u aplikace Gimp. Každé okno je samostatným agentem v rámci hierarchické PAC architektury. Výsledný vzhled uživatelského rozhraní našeho PAC řešení aplikace je zachycen na obrázku 7. Jednotliví agenti hierarchické struktury PAC spolu komunikují pomocí zasílání zpráv. Zprávy se posílají mezi částmi Control jednotlivých agentů. V rámci každého agenta se podle typu (MessageType) příchozí zprávy (PACMessage) rozhoduje, jakým způsobem se bude na zprávu reagovat, jak se upraví abstraction nebo presentation. Důležité pro toto přeposílání zpráv jsou metody sendmessage a receivemessage rozhraní PACAgent. Hierarchická PAC struktura, kterou jsme pro naši aplikaci navrhli je zobrazena v diagramu komponent na obrázku 8. H. Datový model Struktura modelu z MVC (tedy zejména třída Shape a její potomci) byla převzata i do naší implementace PAC, kde byla využita v části CanvasPresentation agenta CanvasAgent. I. Sekvenční diagramy Sekvenční diagramy pro architekturu PAC popisují přidání nového tvaru, podobně jako bylo uvedeno i pro MVC. Diagram na obrázku 9 popisuje téměř totožnou komunikaci, jež byla uvedena u MVC. Na tomto diagramu je ovšem dobře patrné striktní oddělení presentation a control. Dále je také patrné, že nedochází k přímé komunikaci mezi presentation a abstraction. Na závěr komunikace je dobré si povšimnout volání sendmessage, které zajistí rozšíření zprávy o aktuálním dění do zbytku stromu PAC hierarchie. Detailněji je šíření zprávy ve stromu agentů popsáno v diagramu na obrázku 10. Ze sekvencí je patrné, jak se o nově přidaném tvaru dozvědí i agenti StatusAgent a HistoryAgent, konkrétně jejich control části StatusBarControl a HistoryControl. A. Použité návrhové vzory III. DOPLNĚNÍ V našem projektu jsme použili následující návrhové vzory. 1) Composite: Strukturní vzor Composite umožňuje práci a jednotnou manipulaci s objekty, které jsou bud atomické nebo jsou rekurzivně složené z atomických a složených objektů. Toho bylo využito pro definici různých tvarů (Rect, Circle,...) a pro možnost jejich skládání do skupin, a také skládání skupin do skupin. Kompozitní třídou v našem návrhu je ShapeGroup a společnou nadtřídou je abstraktní třída Shape. 2) Visitor: Vzor chování Visitor byl využit pro vykreslování tvarů. Díky tomuto vzoru není třeba zasahovat zásadně do bussiness části kódu po přidání nového tvaru. Tento vzor odstraňuje nutnost zjišt ování, o jaký typ objektu se jedná, například pomocí instanceof. Použití tohoto vzoru nám navíc umožňuje snadné rozšíření, pokud bychom třeba chtěli tvary místo vykreslování na plochu exportovat v nějakém grafickém formátu do souboru. Takovéto rozšíření bychom zajistili pouhým přidáním nové třídy implementující rozhraní Visitor. Nový visitor by se poté sám postaral o export jednotlivých tvarů. Kromě typů tvarů v modelu by nebylo potřeba žádné další znalosti kódu. 3) Command: Vzor chování Command se velmi hodil pro aplikaci příkazů nad objekty na kreslící ploše. Díky němu lze implementovat volitelně i historii příkazů a případně se vracet zpět. Funkce undo nebyla implementována, ale při použití tohoto vzoru by se jednalo jen o přidání metody undo, která by pro každý zvláštní command vracela zpět věci vykonané stávající metodou execute. 4) Mediator: Vzor chování Mediator byl velmi důležitý při návrhu druhé verze aplikace. Sloužil pro komunikaci mezi panely aplikace a posílání zpráv mezi relevantními třídami. 5) Observer: Vzor chování Observer v aplikaci sleduje změny modelu a informuje třídy, kterých se změny na modelu týkají. V naší aplikaci je sledován model, u kterého se registrují třídy implementující rozhraní DrawingListener. A. Kvantitativní hodnocení IV. POROVNÁNÍ V této části je třeba zmínit, že i když obě verze aplikace mají stejnou funkčnost, jejich mohutnost je odlišná. Vzhledem ke své modularitě je PAC mohutnější a v naší implementaci má 36 tříd. MVC verze aplikace má jen 19 tříd. To je skoro o polovinu méně. Počet tříd jde ale logicky proti rozšiřitelnosti. B. Rozšiřitelnost Z hlediska rozšiřitelnosti si lze položit otázku - jak složité je přidat nový panel do každé verze aplikace?

5 Obrázek 5. Add Shape Interaction - MVC Sequence diagram Obrázek 6. PAC Schéma[3] MVC verze představuje složitější architekturu pro modifikování takovýmto způsobem, protože nový panel bude pravděpodobně sledovat i upravovat model. Dále je třeba znát body napojení, a proto musíme mít znalost stávajícího modelu. V poslední řadě je nutné znát zprávy, které model observerům posílá, aby bylo možné panel připojit a zajistit jeho reakce na změny v modelu. Modifikace PAC verze aplikace je jednodušší, protože hierarchická struktura architektury s rozšiřováním počítá. Proto je pouze nutné implementovat třídu PACAgent, která zajišt uje posílání a přijímání zpráv od vyšších vrstev architektury. Ještě je v naší implementaci nutné znát typy zpráv které se posílají a na ně poté PACAgent reaguje vlastní implementací. Sám agent si v reakci na zprávy upravuje abstraction a případně presentation. C. Srovnávací tabulka V. ZÁVĚR Obě architektury, které jsme pro implementaci našeho jednoduchého projektu použili, byly navrženy pro rozsáhlé projekty. My jsme jejich principy a struktury aplikovali na krátkém příkladu, kdy mohly některé věci být trochu vykonstruované, ale přesto byly funkční. Přestože byl náš projekt zjednodušený pouze na několik funkcí, měli jsme možnost si Tabulka I POROVNÁNÍ ARCHITEKTUR MVC PAC Škálovatelnost Špatná Výborná Rozšiřitelnost Špatná Dobrá Portabilita Dobrá Dobrá Low Coupling Horší Lepší High Cohesion Horší Lepší Možnost budování hierarchické struktury Ne Ano na něm architektury dobře vyzkoušet a pochopit jejich přínos pro přehlednost, strukturu či případné rozšiřování. REFERENCE [1] Fowler, M. et al., Patterns of Enterprise Application Architecture. Addison Wesley, November [2] Buschmann, F. et al., Pattern-Oriented Software Architecture, A System of Patterns. Vol.1, John Wiley & Sons, 2001, s [3] Wikipedia, Presentation-abstraction-control. November [4] Wikipedia, Model View Controller. view controller, November 2010.

6 Obrázek 7. PAC Aplikace Obrázek 8. PAC - Component Diagram

7 Obrázek 9. Add Shape Interaction PAC Sequence diagram Obrázek 10. Add Shape PAC Messages Sequence diagram