Vysoká škola ekonomická v Praze

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Nástroje meta-case (charakteristika, vývoj, přehled trhu, trendy) Přednášející: doc. Ing. Václav Řepa, CSc. Pavel Kubal (xkubp33) Ondřej Vávra (xvavo04) Roman Fischer (xfisr04) Letní semestr 2007/2008 1

2 Obsah 1. ÚVOD PRINCIP METAMODELOVÁNÍ VÝZNAM METAMODELOVÁNÍ PŘÍSTUPY K METAMODELOVÁNÍ MOF OPRR COCOA META-CASE NÁSTROJE PŘEHLED META-CASE NÁSTROJŮ CA ERwin Model Manager ConceptBase GME - The Generic Modeling Environment MetaEdit MetaEdit+ Workbench OpenSoul Metamodeler (OSM) VOLBA METACASE NÁSTROJE VÝHODY META-MODELOVÁNÍ PROČ JE META-MODELOVÁNÍ V SOUČASNOSTI PŘISUZOVÁN TAKOVÝ VÝZNAM Nastal čas Metamodelů Nástup matamodelových softwarových produktů Rostoucí dostupnost technologií a standardů zaloţených na metamodelování Potřeba růstu úrovně abstrakce VÝHODY METAMODELOVÁNÍ RIZIKA METAMODELOVÁNÍ JAK ROZEZNAT DOBRÝ META-MODEL OD ŠPATNÉHO? TRENDY DO BUDOUCNA ZÁVĚR LITERATURA

3 1. Úvod Tato práce se bude věnovat problematice metamodelování a metanástrojů. Dáváme si za cíl popsat oblast metamodelování a vysvětlist základní termíny. Práce bude navazovat na předchozí díla z minulých semestrů a cílem mimo jiné je aktualizovat jejich obsah a přinést opět něco nového. Práce je rozdělena na tři části, z nichţ první se věnuje úvodu do problematiky, druhá si klade za cíl zmapovat nabídku nástrojů umoţňujících pohodlné metamodelování a na závěr bychom chtěli zhodnotit vývoj této oblasti. 2. Princip metamodelování Hledat definici metamodelu či metamodelování je jako hledat jehlu v kupce sena. Ne, ţe by se literatura metamodelování nevěnovala, ale příliš se nesoustředí na nadefinovaní pojmu jako spíše na principy metamodelování. Nicméně při rozebrání pojmu metamodelování bychom měli začít u základu slova a tím je model. [6] definuje abstraktní model jako teoretickou konstrukci, která něco reprezentuje a obsahuje skupinu atributů a skupinu logických a kvantitativních vztahů mezi nimi. Model je tedy určitá abstrakce objektů z reálného světa, resp. model popisuje a obvykle zjednodušuje realitu. Pokud bychom k definici modelu připojili předponu meta, která pochází z řečtiny kde slovo znamená po nebo za dostáváme se ke slovu metamodel, který bychom mohli definovat jako model, který popisuje model. Jde tedy o určitou další úroveň abstrakce, která umoţňuje definovat jazyk pro tvorbu modelů. M. Pícka znázornil ve své práci [5] tři úrovně realita-model-metamodel (odspoda nahoru) pomocí UML diagramů, které v nejniţší úrovni reprezentují informace o objektech 3

4 reálného světa. Druhá úroveň modeluje objekty reálného světa pomocí typů, které obsahují atributy, jenţ objekty z reálného světa popisují. Nakonec třetí úroveň se snaţí zachytit jazyk pomocí něhoţ lze realitu modelovat na druhé úrovni. Na dvou příkladech byl vysvětlen princip a základy, na kterých staví metamodelování. Teď se znalostí metamodelování lze probrat jeho význam, kterému se věnuje následující kapitola. 4

5 3. Význam metamodelování Metamodelování je vyuţito při tvorbě metamodelů zvaných Meta Object Facility (MOF) [7]. MOF je Object Management Group (OMG) 1 standard vyuţitý k modelem řízenému inţenýrství. Díky metamodelování jsme schopni popisovat metodologie a hledat jejich společné vlastnosti a znaky. Popis těchto vlastností nám následně můţe umoţnit další vývoj směrem ke standardizaci a lepší kooperaci metodik. Vyšší moţnost abstrakce a popis modelů systémů nám můţe umoţnit vyšší schopnost integrace vzájemných systémů, coţ v dnešní době nespočetného mnoţství informačních systémů nabírá na důleţitosti. 4. Přístupy k metamodelování Stejně jako existuje několik jazyků pro tvorbu modelů, které se lyší jak zaměřením, tak také grafickou notací, tak existují přístupy k tvorbě metamodelů. Pro potřeby informačního a softwarového inţenýrství bylo vyvinuto několik přístupů mezi něţ patří zejména tyto COMMA, GOPRR, MOF, OPRR, CoCoA. Vzhledem k tomu, ţe předchozí práce se věnovali zejména prvním dvěma, tak my zaměříme svou pozornost na poslední tři MOF MOF je navrţeno jako čtyřvrstvá architektura. Jako vrchní vrstva je slouţí tzv. metameta model nazývaný vrstva M3. Tento M3 model je jazyk pouţitý v MOF pro vytváření metamodelů (M2 vrstva). Nejznámější příklad vrstvy 2 je tzv. UML metamodel, který popisuje UML jako celek. Tyto M2 modely popisují elementy M1 modelů, které jiţ dobře známe. Můţe se jednat o ERD, DFD, class či jiné typy diagramů. Nejníţe v hierarchii stojí model M0, který reprezentuje realitu. 1 Object Management Group je konsorcium původně zaměřené na stanovování standardů pro distribuované objektově orientované systémy a nyní je zaměřeno na modelování (programů, systémů a business procesů) a modely zaloţené na standardech. [8] 5

6 4.2. OPRR OPPR (Object-Property-Relationship-Role) model byl vyvinut Welkem (1988) a Smolanderem (1992). OPRR model se od začátku zaměřuje na specifikaci jednotné modelovací techniky. Rozšiřuje převáţně nespecifikovaný pojem role z ER diagramu, aby vysvětlil způsob v jakém jednotlivé objekty v určitých vztazích vystupují. Jinými slovy, role definuje co představuje daný objekt v daném vztahu. OPRR vyuţívá pro reprezentaci stejná pravidla jako ER model a pro typ role pouţívá kruh. [9] Tento přístup je vyuţíván v metacase nástroji MetaEdit. Následující obrázek ukazuje diagram OPRR. Co se týče rozšíření ER modelu, tak přechod (Transition) má k sobě nyní navěšenou akci a stavy jsou identifikovány svými jmény (dvojitá elipsa). Je zde vyuţita i politika pro duplikaci stavů nemohou se vyskytovat dva stavy se stejným jménem. V modelování je moţné udělat kopii jednoho stavu, ale nově vzniklý stav musí mít nové jméno, přičemţ unikátnost stavů je to, oč zde jde CoCoA CoCoA (ComplexCoveringAggregation) bylo vyvinuto pro podporu konceptuálního a datového modelování komplexních problémových domén. Ostatně jak uţ vyjadřuje jméno modelu, jeho rozšíření se zabývají modelováním agregací, které pokrývají entity a pojmenované vztahy, n-entitní vztahy, tvorbu aliasů a kategorie entit (skrze pojmenované role v kterých participují). CoCoA bylo aplikováno také v metamodelování a integraci metod a je určeno pro pouţití jako metamodel pro modelovací nástroj. [9] 6

7 Podle CoCoA je kaţdý přechod (transition) vyjádřen nějakou akcí. Tyto akce jsou popsány jako operace a pokude nějaká akce není popsána jako operace, tak by neměla být moţná. 5. Meta-CASE nástroje Tradiční CASE nástroje jsou zaloţené na dvouúrovňové architektuře. V tomto případě jsou grafické návrhy systému uloţené v nějakém repositáři, ve kterém jsou tato schémata zkompilována do příslušného CASE nástroje. Vrstva kompilace však vymezuje, jaké druhy modelů mohou být uţity a jakým způsobem. Z čehoţ vyplývá důleţitý poznatek. Pouze výrobce nástroje můţe změnit metodu, protoţe ta je jako taková natvrdo uloţena ve zkompilovaném kódu. [10] MetaCASE nástroje odstraňují tuto limitaci svojí flexibilitou metod. Flexibilita je dosaţena přidáním třetí úrovně nad úroveň metod. [10] Rozdíl mezi CASE a MetaCASE nástroji je ilustrován na následujícím obrázku. Obrázek 1: CASE nástroje vs. MetaCASE nástroje [10] MetaCase nástroje jsou zaloţené na třívrstvé architektuře. Nejniţší vrstva vrstva model je podobná jako u CASE nástrojů. Obsahuje návrhy systému v podobě modelů. Prostřední vrstva zahrnuje model metod, čili metamodel. Metamodel zahrnuje koncepty, 7

8 pravidla a diagramové notace metod. Kupříkladu metamodel můţe specifikovat u konceptů typu třída a dědičnost jejich vzájemnou relaci či jak jsou reprezentovány. Místo toho aniţ by byla tato pravidla uloţena v kódu CASE nástroje, jsou uloţena jako data v repositáři. [10] Na rozdíl od CASE nástrojů, však MetaCASE nástroje povolují uţivateli měnit metamodel, právě protoţe jsou zaloţené na flexibilitě specifikací metod, pro jejichţ notaci je uţito speciálního metamodelovacího jazyka. [10] Všechny tři vrstvy jsou v těsné relaci: model je zaloţen na metamodelu, který dále vychází z metamodelovacího jazyka. Ţádné modelování není moţné bez patřičného metamodelu. Tato závislost je podobné té mezi objekty, třídami a metatřídami v objektově orientovaných jazycích. [10] Vzhledem k tomu, ţe MetaCASE nástroje kromě tvorby modelu umoţňují modelovat i samotnou metodu a pracovat s jejím metamodelem (např. doplňovat symboly a vazby) a kromě definování jejich grafické reprezentace i popisovat jejich chování (např. pomocí programovatelného generátoru výstupních sestav), bývají někdy také označovány jako CAME Computer Aided Method Engineering. [11] 5.1. Přehled Meta-CASE nástrojů Tato podkapitola je zaměřena na trh s MetaCase nástroji. Cílem této části seminární práce je ve stručnosti představit pět významných softwarových počinů v této oblasti CA ERwin Model Manager Jedná se o robustní modelovací nástroj zaloţený na standardu UML, který slouţí pro znázornění, navrhování, udrţování komponent a celkový vývoj informačních systémů pomocí objektového modelování. CA ERwin Model Manager (dřívější název Allfusion Component Modeler) částečně vychází z původního modelovacího nástroje Paradigm+, který byl vyvíjen firmou Platinum. Po jejím zakoupení společností CA vývoj produktu pokračoval, a v roce 2003 došlo k integraci s vlastním produktem CA pod názvem Allfusion Component Modeler. [2] Nástroj je součástí balíčku AllFusion Modeling Suite společnosti Computer Associates. Jedná se o skupinu nástrojů (AllFusion Modeling Suite) nabízejících integrované modelovací řešení, které zjednodušuje analýzu komplexního obchodního procesu a vývoj integrovaných podnikových aplikací. Současná verze podporuje práci s pokročilými daty, 8

9 komponentami, modely obchodních procesů a vyznačuje se vysokou mírou výkonnosti a snadné ovladatelnosti. AllFusion Modeling Suite poskytuje integrované prostředí pro automatické navrhování procesů, synchronizačních datových modelů, architektonické problematiky a validace funkcionality koncových uţivatelů. Podporuje vývoj podnikových aplikací včetně transakčních systémů, datových trţišť a skladů. Souhrnné údaje o produktu Název Výrobce CA ERwin Model Manager (dříve Allfusion Component Modeler či Paradigm+) Computer Associates ( Verze R7.2, 2007 Cena $ Podporované prostředí Klíčové vlastnosti klient: Microsoft Windows 2000, XP, 2003 Server, Millennium Edition databázový server: Microsoft SQL Server, Oracle, Sybase Sdílená repository, podpora týmové spolupráce (verzování), dopředné i zpětné inţenýrství, dopadové analýzy, řízení terminologie ConceptBase ConceptBase je objektový manaţer, určený především pro účely konceptuálního modelování a pro koordinaci práce na velkých vývojářských projektech. Tento víceuţivatelský objektový manaţér vyuţívá syntaxe jazyka O-Telos, který v sobě slučuje výhody deduktivních a objektově-orientovaných jazyků. Reprezentuje veškeré informace bez ohledu na úroveň abstrakce, se kterou právě pracuje, v jednotné a jednoduché datové struktuře, ať uţ se jedná o pouhá data, třídy, metatřídy či metametatřídy. Silný deduktivní dotazovací jazyk je uceleně integrován do hierarchie tříd. Modelování je podporováno metatříděním, pravidly, omezeními, konceptem modulů a také historií databází, která umoţňuje zobrazit dřívější stavy databáze. Uţivatelské prostředí nabízí rozšiřitelnou paletu grafických, tabulkových a textových rozhraní, které jsou vyvinuty v Javě. Komunikace mezi operačním systémem a objektovou základnou je zajištěna pomocí klientserver architektury vyuţívající rodinu protokolů TCP/IP, přičemţ vzdálení klienti se mohou připojit pomocí technologie API. Architektura ConceptBase podporuje jazyky C++, Java, 9

10 TCL, Prolog a operační systémy Windows, Linux, Solaria, Mac OS-X. Předchozí a současné verze jsou instalovány na více neţ pěti stech místech po celém světě, včetně výzkumných projektů v Evropě a USA. Největší výhodou tohoto meta-case nástroje je jeho volná šiřitelnost pro nekomerční účely. Atuální verze ConceptBase V7.0, která vyšla , má tyto minimální HW poţadavky: SUN SPARC CPUs se systémem Solaris 8 nebo vyšším, i386 CPUs se systémem Solaris 8 nebo vyšším, i386 CPUs se systémem Linux Kernel 2.4 nebo vyšším, i64 (AMD64) CPUs se systémem Linux Kernel 2.4 nebo vyšším, i386 CPUs se systémem Microsoft Windows 2000/XP, PowerPC CPUs se systémem Mac OS-X. [2] Metamodelování je v ConceptBase zaloţeno na abstrakci typu OMG (M0=datová úroveň, M1=model nebo schéma, M2=meta úroveň, M3=meta meta úroveň, atd.). ConceptBase umoţňuje navrhovat modelovací jazyky (úroveň M2), zaloţené na předem definovaných pravidlech (úroveň M3), k vytváření samotných datových modelů (M1 level) a přesně znázorňovat samotná data (toky) na úrovni M0. [12] Následující obrázek ilustruje způsob modelování v ConceptBase. Jednotlivé objekty jsou instancí jiných objektů v metamodelu. Při horním rohu obrázku je meta metamodel, dole jsou pak znázorněny jednotlivé datové objekty. 10

11 Obrázek 2: Princip modelování v ConceptBase [12] 11

12 Souhrnné údaje o produktu Název Výrobce Verze Cena Podporované prostředí Klíčové vlastnosti ConceptBase Informatik V ( (released 4-Sep-2007) Zdarma pro nekomerční pouţití Microsoft Windows 2000/XP, Linux, Solaris, Mac OS-X. Přehledné grafické prostředí, neomezená rozšiřitelnost díky hierarchií meta tříd, deduktivní pravidla, referenční integrita jako atribut tříd, kontrola integrity, jednotná reprezentace objektů, logické výrazy, funkce (aritmetické funkce), analýzy, sémantické značení, metapravidla a omezení pro rozšíření axiomatického jazyka GME - The Generic Modeling Environment Nástroj The Generic Modeling Environment (GME) vyvinutý na Institutu softwarové integrace univerzity Vanderbilt je zaloţen na konfigurovatelném modelovacím prostředí. Konfigurovatelnosti je dosaţeno díky metamodelům, které jednoznačně specifikují modelovací vzory (modelovací jazyky či modelovací metodologii) aplikační vrstvy. Tyto modelovací vzory zahrnují veškeré sémantické, syntaktické a prezentační informace týkající se dané oblasti, jejichţ koncept je následně vyuţít ke konstrukci modelů, pravidel, vztahů. Modelovací vzory vytvářejí takovou rodinu modelů, které mohou být vytvářeny s vyuţitím konkrétního modelovacího prostředí. [13] GME má modulární, komponentově orientovanou architekturu, která je znázorněna na následujícím obrázku. 12

13 Obrázek 3: Architektura GME [13] Obrázek 4: GUI v GME [13] 13

14 Souhrnné údaje o produktu Název Výrobce Generic Modeling Environment Univerzita Vanderbilt ( Verze 6 (2001) Cena Podporované prostředí Klíčové vlastnosti Zdarma Microsoft Windows 2000 Podpora COM (C++, Visual Basic, C#, Python etc.), XML formátu, UDM (Unified Dimensional Model) Přehledné grafické prostředí (návrh a vizualizace modelů), zabudovaný debugger, rozšiřitelnost, podpora jmenných prostorů MetaEdit+ MetaEdit+ je nástroj vyvíjený společností Metacase a představuje absolutní špičku mezi MetaCASE nástroji, a proto mu bude věnována největší pozornost. MetaEdit+ můţe být vyuţíván i jako klasický CASE nástroj. Kombinuje v sobě tedy jednak výhody implementace nových metod, tak i výhody z jiţ předdefinovaných sad metod postihujících nejběţnější oblasti modelování. MetaEdit+ je repository-based aplikace, coţ znamená, ţe při spuštění této aplikace musí dojít k navázání spojení s úloţištěm (repository) a toto spojení musí být pak udrţováno po celou dobu práce s aplikací. [14] Nová metoda se v MetaEditu+ poměrně snadno implementuje pomocí definování jejího metamodelu, k němuţ se prostředky vizuálního programování přidají příslušné dialogy a vzhled a chování symbolů. MetaEdit+ je naprogramován nad objektově orientovanou databází. Informace uloţená v databázi je prezentovatelná a zpracovávatelná nejen v podobě grafů, ale i jako tabulky a matice a také přímo uvnitř databáze pomocí různých browserů. Součástí MetaEditu+ je i skriptový jazyk, ve kterém jsou předdefinovány různé výstupy ve formátu TXT, RTF, HTML, GIF a PCT. [15] Doménou nástroje je jeho otevřenost, tzn. ţe je moţné programovat další výstupní sestavy pro potřeby dokumentace. V prvním případě umoţňuje definici modelovacích metod 14

15 a generátorů kódů, v druhém případě je moţné tyto metody vyuţívat přímo jako CASE nástroj, přičemţ tvorba CASE nástrojů bude zautomatizována pomocí MetaEdit+. Tímto se ukazuje jedna z výhod MetaEdit+ - náklady na implementaci doménově specifického modelovacího nástroje odpadají. [3] Nástroj MetaEdit+ se skládá ze dvou dílčích editorů: a) MetaEdit+ Workbench, který plní funkci CAME nástroje, b) MetaEdit+ Modeler, jenţ slouţí jako CASE nástroj. Obrázek 5: Metaedit+ Workbench vs. Modeler [16] V sekci MetaEdit+ Workbench se navrhuje modelovací jazyk (metoda), zahrnující koncepty, pravidla, notifikace (symbolický zápis) a generátory kódu. Definice jazyka je pak uloţena jako metamodel v MetaEdit+ repositáři. Sekce MetaEdit+ Modeler poskytuje obdobnou funkcionalitu (grafický návrh tabulek, diagramů, matic, vztahů, filtrování, kontrola modelů, verzování, mutiuţivatelská podpora, dopadové analýzy, generování kódu) jako typický CASE nástroj. Automaticky navazuje na příslušnou definici modelového jazyka. 15

16 Architektura aplikace MetaEdit+ je znázorněna na následujícím obrázku. Obrázek 6: Architektura nástroje MetaEdit+ [14] Duší systému je objektové úloţiště (Object Repository), které obsahuje všechny informace o definicích modelovacích jazyků (elementy a atributy modelů), které jsou vytvářeny s pomocí editoru MetaEdit+ Workbench. MetaEdit+ pouţívá metody automaticky tím, ţe si je vyţádá právě z objektu Repository. Nejdůleţitější částí nástroje MetaEdit+ je v tomto případě MetaEngine, který 16

17 stanovuje rozhraní mezi moduly, a Object Repository, která zajišťuje konzistenci mezi jednotlivými nástroji. Moduly se dělí do čtyř skupin: Nástroje pro úpravu modelů (Editor diagramů, editor matic, editor tabulek), Vyhledávací a dotazovací nástroje (Prohlíţeč, generátor kódu a zpráv), Nástroje pro řízení metod (Method Tool, konektivita API & XML). K tomu se ještě řadí nástroje řízení metod v části Method Workbench (jako objektový a grafový nástroj, editor symbolů apod.). [3] Z pohledu zaměření této práce povaţujeme za účelné dále rozvést pouze tu část nástroje MetaEdit+, která je zaměřena na doménově specifické modelování editor MetaEdit+ Workbench MetaEdit+ Workbench Díky této komponentě můţe být klasický CASE nástroj v podobě MetaEdit+ Modeleru značně modifikován, upraven, kastomizován či rozšířen. MetaEdit+ Workbench umoţňuje nadefinovat odlišné modelovací jazyky/metody, jejich koncepty, grafickou podobu objektů, kódy či napojení na jiné jazyky apod. [14] Tato komponenta nám umoţňuje vytvářet vlastní modelovací nástroje a to bez psaní sloţitého kódu. Modelování probíhá z v plně grafickém prostředí a skládá se z několika kroků. [3] Doménově specifické modelování v podání nástroje MetaEdit+ obnáší: [17] Definici konceptů dle specifických potřeb modelování (GOPPRR metatypů objektů, vztahů, diagramů, vlastností objektů apod.) Definici pravidel (chování jednotlivých doménových konceptů mezi sebou navzájem, funkční rámec) Definici grafické vizualizace (grafické symboly jazyka, barvy) Definici generátoru kódu (jaká části grafického návrhu převádět do jakého kódu) 17

18 Obrázek 7: Definování konceptu [16] Obrázek 8: Editor symbolů [16] 18

19 Obrázek 9: Definování pravidel [16] Obrázek 10: Definování generátoru kódu [16] 19

20 Souhrnné údaje o produktu Název Výrobce MetaEdit+ Metacase corp. ( Verze MetaEdit+ 4.5 SR1, 2008 Cena Podporované prostředí Klíčové vlastnosti $ (MetaEdit+ Workbench) Windows XP, 2000, ME, 98*; Linux e.g. RedHat 6.2 or later; Mac OS X or later; Solaris 2.5 or later; HP-UX or later Sdílená repository, silná multiuţivatelská a multiprojektová podpora (verzování), robustní a všestranný nástroj pro vývoj modelovacího jazyka, kontrola modelů, garantovaná aplikační podpora, přehledné GUI, userfriendly OpenSoul Metamodeler (OSM) Pro zajímavost uvídíme také open source MetaCASE nástroj s názvem OpenSoul Metamodeler, který je zaloţený na MOF modelování a postavený na MDR (Netbeans Metadata Repository) a JGraphu a programovaný v jazyku Java. Nástroj byl vytvořen jako součást OpenSoul projektu, který se snaţí vytvořit framework pro sdílení modelů mezi komunitou zabývající se metamodelováním. Nyní se nachází od roku 2004 ve vývojové PreAlpha verzi a obsahuje více chyb neţ funkcí, ale je funkční. [3] OSM je vyvíjen studenty Vysoké školy Ekonomické v Praze a vychází z podobných existujících nástrojů jako například MetaEdit+, DOME, ArgoUML a dalších [18]. Na následujícím obrázku je znázorněna zamýšlená architektura nástroje OpenSoul. 20

21 Obrázek 11: OpenSoul project basic architecture [18] Meta Data Repository (MDR) je klíčovou komponenta celého programu. Slouţí jako úloţiště pro všechny modely a metamodely. Je také centrálním bodem dalších komponent programu. Pouţívá JMI standard pro přístup k objektům uloţených v repozitoři. MDR je open source repozitoř vyuţívající MOF, JMI a XMI standardy. [3] Hlavními znaky MDR jsou: [18] postaveno na Javě, MOF, JMI a XMI standardech plně popsaná architektura podpora MOF metamodelů XMI export, import repozitoř typu BTree, JDBC nebo Transient (pouze z testovacích důvodů) Proces modelování je zahájen vytvořením nové repozitory a volbou jejího typu, přičemţ nejjednodušší je pouţití BTree repozitory. Druhým krokem je vytvoření vlastního metamodelu, jeho popsání a nakreslení struktury. Metamodel musí být vytvořen pomocí MOF zápisu a poté je uloţen do repozitory. Zajímavou funkcionalitou je poté moţnost 21

22 vygenerování ukázkového modelu zaloţeného na našem vlastním metamodelu. V poslední fázi můţeme vytvořit finální model s pouţitím námi předdefinovaného metamodelu. [18] 5.2. Volba MetaCASE nástroje Volbu vhodného MetaCASE nástroje nelze jednoduše paušalizovat do nějaké sady kritérií. Vţdy budou důleţité individuální preference a celkový kontext poptávky po daném produktu. Pro velké společnosti budou zajímavými kritérii např. licenční politika, aplikační podpora, mutiuţivatelská podpora, či nezávislost na platformě. Pro fyzickou osobu bude rozhodující cena. Protoţe jsme nepopsali všechny dostupné nástroje, ale jen jejich podmnoţinu, tak se neodváţíme ani říci, který nástroj je ten nejlepší. Špatnou volbou ale rozhodně není nástroj MetaEdit+, který za rozumnou cenu nabízí širokou škálu funkcí a pokročilých moţností. Navíc jeho koupí nezískáte jen velmi kvalitní MetaCASE nástroj, ale i solidní a plně dostačující CASE nástroj. Dvě mouchy jednou ranou 6. Výhody meta-modelování 6.1. Proč je meta-modelování v současnosti přisuzován takový význam Nastal čas Metamodelů Metamodelování je známé přibliţně od konce 80 let 20. století, ale s příchodem Internetu a integrací jednotlivých business odvětví je datová integrace jasně prvotním zájmem. Metamodely jsou základem pro datovou integraci, i kdyţ nejsou vţdy stejně nazývány Nástup matamodelových softwarových produktů První metamodelové softwarové produkty byly samozřejmě CASE nástroje (jakoţto modelovací nástroje) s rozšiřitelným nebo plně konfigurovatelným metamodelem, z nichţ se pak v dalších obdobích postupně stávaly Meta-CASE nástroje. To samozřejmě s sebou přineslo moţnosti samostatného přizpůsobování metod softwarového vývoje či standardů. Nyní můţeme meta-modelové softwary nalézt jsou součást mnoha balíků, jako jsou například e-business integrační řešení. 22

23 Rostoucí dostupnost technologií a standardů založených na metamodelování Nejznámější příkladem je v tomto ohledu Unified Modeling Language (UML), který je z větší části definován jako metamodel. Před UML však ještě nacházíme CDIF (CASE nástroj zaloţený na Integrovaném Meta-modelu), PCTE a IRDS (oba standardizované), STEP (pro výměnu průmyslových informací) a další Potřeba růstu úrovně abstrakce Metamodely jsou velmi dobré v abstrahování od nízkoúrovňových detailů integrace a interoperability, pomáhají s rozdělováním problémů do sub-problémů, pomáhají při optimalizaci fyzických dat a v mnoha dalších oblastech konceptuálních příprav modelů. Metamodelování nachází své uplatnění především při popisu a tvorbě nových metodologií, při implementaci metodologií v CASE nástrojích, při integraci systémů, při generování programů z modelů a v neposlední řadě i při kontrole samotných modelů Výhody metamodelování Nástroje Meta-CASE jsou vyvíjeny v zásadě ze dvou hlavních důvodů. Jednak jako produkt pro cílového zákazníka a jednak jako interní vývojářská verze vlastního CASE nástroje. První důvod vývoje a existence Meta-CASE nástroje není příliš obvyklý a na trhu se s takovým softwarem příliš nesetkáváme, protoţe cílová skupina schopná vytvářet nové metodologie a upravovat staré metodologie je poměrně malá. I přesto je moţné takovou aplikaci získat. K nejznámějším z nich nejspíš patří jiţ zmiňovaný nástroj MetaEdit+. Druhý důvod je mnohem častější. Vývojáři CASE nástrojů často vyvíjí Meta-CASE nástroj, ale těsně před vydáním z něj vytvoří obvyklý CASE nástroj. Tím si zajistí lehnou rozšiřitelnost CASE nástroje a zvyšují tak prodejnost nových verzí. Inovace je tím pádem pro ně mnohem jednodušší a prováděné změny nemusí být zasazovány přímo do zdrojovém kódu. Stačí pouze změnit meta-model a nová verze je připravena k prodeji. Společné prvky, které obsahuje kaţdý z CASE nástrojů, mění (přidávají) jednotně. Tím dosahují vyšší produktivity a zároveň sniţují počet chyb. [19] 23

24 Vzhledem k výše zmíněnému bychom mohli definovat hlavní výhody metamodelování následovně. [4] 1. upravitelnost existujících meta/modelů 2. tvorba nového metamodelu a vývoj vlastních modelů 3. rychlejší vývoj nových CASE nástrojů a tím niţší pořizovací náklady 4. efektivní generování programového kódu 5. podpora jakéhokoliv modelu 6. přírůstkové přidávání metadat do metamodelu 7. podpora sdílení a výměny metadat a meta-metadat mezi meta-metamodely 7. Rizika metamodelování Jak rozeznat dobrý meta-model od špatného? Obecně lze doporučit pouţití následujících kritérií: Rozsah Určení rozsahu metamodelu je zpravidla komplikovaná záleţitost. Jednou moţností je vzít testovací data a aplikovat na ně popis samotného metamodelu. Existuje nám v metamodelu kaţdý potřebný popis? Lze data přesně popsat? Nebo je potřeba data změnit, aby bylo moţné metamodel aplikovat. A stejně tak obráceně. Je moţné odvodit zpětně metamodel, aniţ bychom ztratili jakékoliv informace? Toto lze snadno předvést na příkladu [20]. Například potřebujeme metamodel, který nám dovolí promítnout třídy do objektové analýzy a designu. Náš koncept metamodelu bude vypadat nejspíš následovně: třída, atribut, metoda a dědičnost. Pokud se podíváme na poţadavky, je zřejmé, ţe určitě se budou vyskytovat třídy, které budou mít atributy a metody. Je však dědičnost meta-třídou? Spíše se jedná o něco jako meta-vztah. A v tom právě tkví kvalita rozsahu meta-modelu. Pokud náš meta-model dokáţe promítnout i ty poţadavky, které se vyskytují řidčeji, případně jen občas, jedná se o model s dostatečným rozsahem. Jiným příkladem můţe být vytvoření metamodelu, následné vytvoření modelu reality podle tohoto modelu a následné předání celého projektu někomu úplně jinému, kdo nezná náš 24

25 způsob myšlení. Pokud tento člověk dokáţe správně interpretovat naše data, čili sémantiku ukrytou za modelem, vytvořili jsme prvotřídní meta-model. Technická kvalita meta-modelu Testování je základ úspěchu. I v případě metamodelu. Špatný vliv metamodelu je mnohem horší neţ špatný vliv samotného modelu. Kupříkladu v datovém modelování je mnohem horší špatná sémantika samotná, neţ špatná struktura dat či patné databázové schéma. Pokud je špatná sémantika, nelze jiţ vytvořit nic lepšího. Ani nejlepší analytik nemůţe v rámci daného metamodelu nic zlepšovat. Zlepšovat se pak dá jen metamodel samotný. Je zřejmé, ţe tento poţadavek vlastně doplňuje poţadavek na dostatečný rozsah metamodelu.. Rozšiřitelnost Na rozšiřitelnost bychom měli dbát především ze dvou důvodů. 1. Při torbě reálného softwaru se jistě setkáme se situacemi, kdy nám nebude ţádný metamodel dostačující. Vţdy se najdou situace, které daný metamodel neřeší. A právě v tuto chvíle je potřeba metamodel rozšiřovat a zvyšovat tak jeho rozsah i technickou kvalitu. 2. Samozřejmostí je pak rozšiřitelnost v případě vydavatelů metamodelů. Je naprosto nemoţné, aby byla kaţdá verze metamodelu zcela jiná neţ ta předchozí. Stejně jako v jiných oblastech, je potřebné dodrţovat také u metamodelování zpětnou kompatibilitu. Rozšiřitelnost je však sama o sobě velmi komplikovanou otázkou. Jakým způsobem rozšiřovat metamodel? Vytvářet nové koncepty a popisy? Rozdělovat koncepty a popis do dílčích částí? Spojovat je? Ať uţ se k rozšiřitelnosti postavíme jakýmkoliv způsobem, měl by metamodel zaručovat moţnost vkládání nových myšlenek a konceptů tak jak se mění oblast, kterou má popisovat. Kvalita definované dokumentace Stejně jako u většiny softwarových produktů, neexistuje pro metamodely ţádná unifikovaná implementace. To, co u metamodelu vidíme, je to, co dostaneme. A proto musí s kaţdým metamodelem jít ruku v ruce jeho přesná dokumentace, ať jiţ ve formě popisu nebo formálního vyjádření. V opačném případě jsme odkázáni na metodu pokus omyl. 25

26 8. Trendy do budoucna Jádro myšlenky vývoje zaloţeného na modelování (MDD Model Driven Development) je zvýšit úroveň abstrakce a tím dosáhnout zvýšení produktivity. Tomuto trendu odpovídá i posutp OMG (Object Management Group), jeţ spravuje specifikaci UML (Unified Modelling Language) a také MDA (Model Driven Architecture). Oba tyto standardy stále více prostupují vývoj zaloţený na modelování. Jedním z trendů posledních let Domain Specific Language (DSL). Tento trend se také vztahuje k vývoji zaloţeném na modelování. Jedná se o specifický modelovací jazyk, který je určen pro popis specifického problému určité domény (oblasti). Podle definice OMG toho lze dosáhnout buď rozšířením UML nebo definováním zvláštních UML profilů. Lze téţ vytvořit zcela vlastní metamodel. Tak k tomuto problému přistupuje například Microsoft vytvářením tzv. Model Factories., specifických matamodelových vzorů, jeţ slouţí k vytváření modelů v různých doménách (oblastech). [21] Vývoj zaloţený na modelování se zasazuje na rapidním nárůstu vývoje DSL (Domain Specific Language). Modely jsou důleţité, ale právě popisné jazyky vytváří základ jejich hodnoty. Do metamodelování bychom mohli zařadit celou škálu dalších oblastí, kde se snaţíme vytvořit schéma k popisu situací a problémů. Například sémantický web je téţ z velké části o metamodelování. Schéma pro popis modelů bychom objevili i v umělé inteligenci a dalších oblastech. A nemusí se jednat jen oblasti IT/ICT. Do budoucna lze předvídat, ţe metamodelování bude nacházet další a další uplatnění a bude docházet k mohutnějšímu rozšíření do dalších oblastí, kde model bude základem pro úspěšný vývoj. 9. Závěr V této práci jsme se snaţili přiblíţit problematiku meta-modelování, jednotlivých meta-nástrojů a definovat výhody a rizika meta-modelování. Snaţili jsme se popsat a vysvětlit základní termíny a techniky meta-modelování, detailně rozebrali jednotlivé meta-nástroje dostupné v současnosti na trhu a věnovali se rizikovým oblastem meta-modelování. V závěru jsme se snaţili zhodnotit dosavadní stav a předvídat trendy, které by nás měli v blízké době v oblasti meta-modelování potkat. 26

27 10. Literatura [1] István Balogh, Gabriel Jankó, Jozef Murín, Radim Ţilka, Nástroje meta-case (charakteristika, přehled trhu, trendy), prosinec 2005, [online] [2] Petr Burian, Tomáš Gottwald, Jan Přikryl, Nástroje meta-case (charakteristika, přehled trhu, trendy), letní semestr 2006/2007, [3] Jan Apfelthaler, Monika Burianová, Michal Cerman, Ondřej Cibulka, David Fořt, Ondřej Lorenc, Nástroje meta-case (charakteristika, přehled trhu, trendy), zimní semestr 2006/2007, [online] [4] Petr Tománek, Petra Hradecká, Metamodelování a problematika jeho nasazení a pouţití ve firemní praxi, zimní semestr 2007/2008, [online] [5] M. Pícka, Metamodeling and development of information systems, [online] [6] Wikipedia Model (abstract), [online] [7] Wikipedia Meta-Object Facility, [online] Object_Facility [8] Wikipedia Object Management Group, [online] [9] Jyväskylä: University of Jyväskylä, 1998, 301 p., Incremental Method Engineering with Modeling Tools: Theoretical Principles and Empirical Evidence, ISBN: , [online] [10] MetaCase corp. ABC to metacase technology, 2004, [online] [11] MERUNKA, Vojtěch. Objektově orientované technologie ve výuce projektování informačních systémů. Praha: PEF ČZU v Praze, Katedra informačního inženýrství. [online] pdf 27

28 [12] Jeusfeld, M. Meta Modeling with ConceptBase. Tilburg University. [online] [13] Akos Ledeczi, Miklos Maroti and team. The Generic Modeling Environment. Nashville, [online] [14] MetaCase corp. User s Guide MetaEdit Finsko. [online] [15] Merunka V., Polák J. BORM Business Object Relation Modeling. Praha, [online] [16] MetaCase corp. MetaCASE tool MetaEdit [online] [17] MetaCase corp. Workbench User s Guide MetaEdit Finsko. [online] [18] OpenSoul Projekt.VŠE. [online] [19] Bc. Pavel Jareš, Meta-CASE nástroj, [20] How do I tell a good metamodel from a bad one?, [21] Modelling, J.P.Nytun, Monday, August 27, 2007, [22] Why does metamodeling recently get so much attention?, 28