Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií (charakteristika, vývoj, přehled trhu, trendy) Přednášející: doc. Ing. Václav Řepa, CSc. Seminární práce z předmětu 4IT450 CASE (Computer Aided System Engineering) Petr Burian Tomáš Gottwald Jan Přikryl Letní semestr 2006/2007

2 OBSAH 1 Metamodelování Co je to metamodelování? Využití metamodelování Aplikace metamodelu Přínosy metamodelování Přístupy k metamodelování COMMA GOPRR MOF Meta-CASE nástroje CASE vs. meta-case Přehled meta-case nástrojů Allfusion Component Modeler ConceptBase CBIva Graphical Editor GME Metaedit MetaEdit Workbench Definice konceptů Výběr pravidel Kreslení symbolů Tvorba generátorů MetaEdit+ Client Komunikace s ostatními programy Ceny [25] Zhodnocení OpenSoul Metamodeler (OSM) Meta Data Repository (MDR) Zhodnocení Závěr Použité zdroje z 31

3 1 METAMODELOVÁNÍ 1. 1 CO JE TO METAMODELOVÁNÍ? Předpona meta- je v souvislosti s informačními technologiemi v posledních letech více než hojně využívána. Neustále se zdůrazňuje nezbytnost používání metadat, používají se html metatagy, přinášející metainformace, zkrátka lidé, pracující v IT, se slovíčkům s magickou předponou meta nevyhnou. Ale nejen oni filosofové se od dob Aristotelových zabývají metafyzikou, což je filosofická disciplína, která se snaží poznat nikoliv jednotlivé věci, nýbrž věci co do jejich bytí. Rudolf Carnap, zkoumající problematiku jazyka vědy, označil jazyk, jímž je formulována teorie, za metajazyk [1]. Metamatematika je zase ta část matematiky, která zkoumá, čeho matematik může nebo nemůže dosáhnout, co podle ní lze nebo nelze rozhodnout [2], metakritika je kritika kritiky. Astronomové budou znát pojem metagalaxie, který označuje souhrn všech galaxií a dalších objektů dostupných dnešním dalekohledům. A takhle by šlo pokračovat velmi dlouho. K vymezení pojmu metamodelování je třeba definovat nejprve předponu meta- a slovo model. Výraz meta pochází z řečtiny a vyjadřuje: pře-, pes, za, po, mezi, vně (přenesení, přechod, změna, pozice za něčím, záměna) [3]. Meta- před slovem znamená o jeden stupeň abstrakce výše např. metadata jsou data popisující data [4]. Model je pak zjednodušením reality (nebo systému) za určitým účelem [5]. Jedná se o jakési schéma, soužící ke zkoumání a vysvětlení určitého předmětu nebo jevu. Pokud je předmětem informační systém, plní model i významnou úlohu komunikačního prostředku nejen uvnitř vývojového týmu. Metamodel je také modelem, jedná se vlastně o model modelu. Pokud aplikujeme definici platnou pro model, stává se metamodel zjednodušením modelu za určitým účelem. Metamodely lze dále vrstvit [5], protože i metamodel je potřeba nějakým způsobem definovat. V hierarchii metamodelování se pro to používá meta-metamodel. Další metavrstva modelů naštěstí není potřeba [6]. Vztah meta-metamodelu, metamodelu a modelu ukazuje následující obrázek. 3 z 31

4 Obr. 1 - Hierarchie modelování. Převzato z: [8]. Metamodelování je činnost, při které se vytváří model nebo schématický popis na vyšší úrovni abstrakce [7], v užším pojetí je metamodelování více či méně chápáno jako popisování jazyku a technologií používaných při vývoji IS/ICT, za účelem počítačového zpracování těchto informací [5]. Na tomto místě bychom si dovolili odbočit k filosofii, konkrétně do roviny ontologické. Když jsme se totiž zamýšleli nad modely a metamodely, napadla nás analogie se systémem ideí, který použil velký antický myslitel Platón v dialogu Ústava. Platón předpokládá, že pro každou třídu věcí existuje jedna idea. Například židle jsou různými řemeslníky různě zpracované, přesto nesou stejné jméno. Když řemeslník takovou židli vyrábí, má jako vzor ideu židle a pak vytváří každou jednotlivou židli. Nejprve si musí uvědomit, co je pro židli přirozené (např. že má nohy, opěradlo a slouží k sezení), pak přemýšlí o konkrétní podobě židle jím vyráběné a nakonec uvažuje z jakých materiálů a jakými technikami ji bude vytvářet. Takový postup by bylo možné přirovnat k cestě od metamodelu, přes model až ke konkrétní implementaci. Ale to jen na okraj 1. 2 VYUŽITÍ METAMODELOVÁNÍ Metamodelování se využívá zejména pro popis a tvorbu nových metodologií, při implementaci metodologií v CASE nástrojích, pro strukturování repositářů, při integraci systémů, při generování programů z modelů, generování reportů, a kontrole modelů. Znalost metamodelu lze také použít pro flexibilní návrh informačního systému pomocí generických modelů [4]. Vzhledem k tomu, že meta-case nástroje kromě tvorby modelu umožňují i modelovat 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 [9]. 4 z 31

5 Metamodel, který definuje každou metodologii může být popsán formálně či neformálně. Neformální popis je možné najít např. v učebnicích metodologií. V knize o UML bychom tak mimo jiné mohli nalézt, že třídu reprezentuje obdélník se třemi poli, která obsahují název, atributy a metody třídy. Pro lepší pochopení a především pro případnou počítačovou podporu modelování je ale nutný formalizovaný popis metamodelu [4]. Metamodel jako takový je používán k popisování různých druhů dat. To znamená, že jde o abstraktní jazyk, tedy o jazyk bez konkrétní syntaxe a notace [11] APLIKACE METAMODELU Zdroj [5] uvádí několik aplikací metamodelu: jednotné uložiště metadat, lepší interoperabilita nástrojů, snažší přechod mezi technologiemi, snažší přechod mezi úrovněmi návrhu a sekundárních efektů: dotazy a vyhledávání, vizualizace a navigace, analýza dopadu změn, metriky, syntax coloring, automatické doplňování kódu, design patterns, management závislostí, podpora testování, synchronizace modelu a kódu, nástroje pro dokumentaci, sémantické diffy PŘÍNOSY METAMODELOVÁNÍ Mezi hlavní výhody metamodelování patří například [11]: Možnost upravit existující metody, nevázanost konkrétní metodikou. Možnost tvorby nového metamodelu, efektivní vývoj vlastních modelu. Rychlá tvorba nového modelu ve srovnání s novým CASE nástrojem, nižší náklady tvorby. Efektivní generování programového kódu. Podpora jakéhokoliv představitelného modelu. Inkrementální přidávání metadat do metamodelu. Podpora sdílení a výměny metadat a meta-metadat mezi meta-metamodely PŘÍSTUPY K METAMODELOVÁNÍ Metamodelovací metody definují rámec pro metamodelování, který obvykle obsahuje definici meta-metamodelu a metamodelovacího jazyku, pomocí kterého je definován metamodel. Pro potřeby metamodelování v informačním a softwarovém inženýrství bylo vyvinuto mnoho přístupů pro tvorbu metamodelu [4]: 5 z 31

6 CoCoA (Complex Covering Aggregation) COMMA (Common Object Metodology Metamodel Architecture) COOM (Co-operative Object Modelling) GOPRR (Graph-Object-Property-Role-Relationship) MOF (Meta Object Facility) NIAM (Nijssen's Information Analysis Metodology) OPRR (Object-Property-Role-Relationship) Přístupy COMMA a GOPRR byly velmi dobře popsány našimi předchůdci ([7]) i v jiné literatuře ([4]), proto budeme citovat. Naše práce se více zaměří na standard MOF COMMA Projekt COMMA se snažil identifikovat společné jádro všech objektově orientovaných metodologií, následně reprezentovat tyto základní pojmy pomocí metamodelu a vytvořit metamodely nejrozšířenějších objektově orientovaných metodologií. COMMA používá tyto základní pojmy: Pojem (Concept) má jméno a atributy, Dědění (Inheritance) vyjadřuje relaci specializace, Asociace (Association) vyjadřuje vztah mezi pojmy, Agregace (Aggregation) vyjadřuje skládání, je to speciální případ asociace, Role (Role) objevuje se, když objekt přijímá charakteristiky jiného objektu. Role je dočasná a objekt může mít i více rolí najednou. Hlavním výsledkem projektu COMMA je vytvoření velmi jednoduchého (ale mocného) objektově orientovaného metamodelovacího jazyku. Nevýhodou je, že tento projekt již skončil a neexistuje napojení na CASE nástroje GOPRR Metamodelovací jazyk GOPRR vznikl jako součást disertační práce rozšířením jazyka OPRR. Základními prvky metamodelovacího jazyka GOPRR, už podle názvu, jsou: Diagram (Graph) je kolekce objektů, vztahů a rolí, která definuje co a jak lze spojovat dohromady. Objekt (Object) definuje entitu, která může existovat sama o sobě. Vlastnost (Property) charakterizuje graf, objekt, roli nebo vztah. Role (Role) existuje mezi vztahem a objektem. Vztah (Relationship) existuje mezi dvěma a více objekty MOF MOF (Meta Object Facility) je standardem konsorcia OMG (Object Management Group) pro meta-metamodel. Společně s jazykem UML (Unified Modelling Language), sloužícím k tvorbě vizuálních reprezentací návrhových artefaktů a konverzním prostředkem XMI (XML Metadata Intercharge) tvoří tzv. modelem řízenou architekturu MDA (Model Driven Architecture) [13]. Vztah MOF a UML je hierarchický, to znamená, že MOF popisuje vrstvu meta-metamodelu a UML vrstvu metamodelu. XMI pak definuje mapování MOFu do XML a slouží k výměně metamodelů a jejich instancí [15]. MOF je jazyk pro vytváření konstruktů modelu, neboli metajazyk. Jedná se o jazyk abstraktní, to znamená, že nedefinuje svou gramatiku ani grafickou notaci. Používá se k popisu abstraktních syntaxí, nikoli gramatik [15]. Umožňuje vytvářet a spravovat technologicky nezávislé metamodely. MOF je samovysvětlující, tj. definuje sám sebe a neexistuje tedy žádný meta-metametamodel. 6 z 31

7 Meta Object Facility vychází z předpokladu, že systém je vyjádřen různými modely, a proto musí existovat různé modelovací jazyky. Kromě zmíněného UML mezi další modely, založené na MOFu a definované OMG, patří IDL (Interface Definition Language), CDW (Common Data Warehouse) a OCL (Object Constraint Language). První z nich je standard popisující objektová rozhraní tříd pro standard distribuovaných objektů CORBA, a jejich mapování do různých programovacích jazyků, metamodel CDW definuje architekturu datových skladů [4]. OCL je formalizovaný, výrazově (nikoli vizuálně) orientovaný jazyk, sloužící k popisu omezení (constraints) a podmínek (conditions) v UML modelech [16]. Tyto jazyky je však třeba popsat jednotným způsobem. Takovým univerzálním způsobem, jak popsat různé modelovací konstrukty, je právě MOF. Architektura MOF je tvořena 4 metaúrovněmi, jak ukazuje následující obrázek. Obr. 2 Čtyřvrstvá architektura MOF. Převzato z: [17] Úroveň M0 představuje vyvíjený systém. Vrstva M1 tvoří vyšší úroveň abstrakce, tedy model (schématické zjednodušení) vytvářeného systému. Pokud by pro modelování byl použit jazyk UML, tvořil by tuto vrstvu např. class diagram, use case diagram, collaboration diagram, atd. Úroveň M1 poskytuje vývojářům podklady pro tvorbu systému, dokumentuje ho a je významným komunikačním prostředkem. Každý model na úrovni M1 je instancí nějakého metamodelu úrovně M2. Poslední a nejvyšší vrstvou je M3, což je meta-metamodel, určující abstraktní syntaxi specifických modelovacích jazyků, jako je např. UML. V rámci MDA je definován jediný meta-metamodel, a sice MOF. Nejpřehledněji celou hierarchii popisuje níže uvedená tabulka. Úroveň Popis Příklad M3 = meta-metamodel Určuje pravidla pro tvorbu metamodelu. Množina konstruktů k definici jazyka pro MetaClass, MetaAttribute popis jazyků. Je instancí meta-metamodelu a definuje Class, Attribute M2 = metamodel pravidla pro tvorbu modelu. Popis jazyků/konstrukcí pro tvorbu modelů/tříd. Jedná se o metamodely definované pomocí konstruktů MOFu, např. UML, CWM, atd. M1 = model Je instancí modelu a definuje pravidla popisující informační doménu. Jedná se o popis struktury uživatelských objektů. Osoba M0 = uživatelské objekty Instancí modelu jsou uživatelská data, tedy Jan Novák konkrétní instance objektů. Tabulka 1 - Čtyřvrstvá architektura MOF [15], [18] 7 z 31

8 Obr. 3 - Model - Metamodel - Meta-metamodel. Převzato z: [6] Základní koncepty MOF [17]: Class (třída) - je určená pro definování typů různých metadat (tedy Class a Association v UML jsou instancí Class v MOFu). Instance od Class, narozdíl od instancí od DataTypes mají vlastní objektovou identitu. Class obsahuje Attributes, SuperTypes (dědičnost) a Abstract (Class definovaná jako Abstract nemůže mít instance). Attributes určují hodnotová místa, která náleží instanci Class. Obsahují jméno (name), typ (type) kterým může být buď Class nebo DataType a násobnost (multipicity). Association - slouží k definování binárních relací mezi Class. Association má právě dva Association End, z nichž každý má: jméno (name), typ (type) který je Class, násobnost (multiplicity) a agregaci (aggregation). DataTypes - jsou navrženy k určení typů metadat, která nemají objektouvou identitu. Metamodelář si tak může vybrat mezi modelováním metadat jako objekty nebo jako hodnoty. DataTypes ve verzi MOFu 1.3 odpovídají typům v CORBA 2.0 IDL, ve verzi 1.4 je typový systém MOFu kvůli snadnější implemetaci o něco chudší. Package - je určen pro modularizaci metamodelů. Ač obvykle je Package obvykle totožný s MOF metamodelem, mohou být Package znovu použity a kombinovány dohromady, čímž se dosáhne jednoduššího vytváření složitějších metamodelů. Constraint - Class, Association a DataType utváří jednoduchý model pro metadata. Constraint umožňuje omezit metadata tak, aby byla dobře formulovaná či sémanticky smysluplná. Constraint obsahuje: jméno (name), omezovaný element (constrained element) může jím být Class, Association, datatype, Parameter nebo Package, omezovací výraz (constraint expression) a vyhodnocovací metoda (evaluation policy) která může být buď okamžitá nebo odložená. Omezovací výraz může být vyjádřen v libovolném jazyku, ale doporučovaným je OCL, který je součástí UML. 8 z 31

9 Obr. 4 - Hlavní konstrukce MOFu. Převzato z: [15] Obr. 5 - Model statického jádra MOF. Převzato z: [17] 9 z 31

10 2 META-CASE NÁSTROJE 2. 1 CASE VS. META-CASE CASE nástroje jsou založeny na dvoustupňové architektuře. Návrhy, které vytvoříme, jsou uloženy v tzv. repozitoři, jejíž schéma je zkompilováno do CASE nástroje. Zde se určuje, jaké druhy modelů mohou být v CASE nástroji vytvořeny a jakým způsobem. Dále se zde udržují veškeré informace o projektu, např. také seznam všech provedených kroků. V případě využití CASE nástroje může tvůrce definovat a měnit pouze metody. Je to z toho důvodu, že jsou natvrdo uloženy ve zkompilovaném kódu [7]. Obr. 6 - Schéma CASE a meta-case nástroje. Převzato z: [8] Meta-CASE nástroje jsou založeny na třístupňové architektuře. Přidání jedné, vyšší, úrovně do hierarchie je odstraněna limitace ze strany fixně zkompilovaného kódu [7]. 10 z 31

11 2. 2 PŘEHLED META-CASE NÁSTROJŮ V současné době je na trhu k dispozici poměrně značné množství nástrojů: Alfabet ALLFUSION COMPONENT MODELER ArgoUML ConceptBase Coral GME IPSYS TOOLBUILDER MetaEdit+ Metamill MetaView OpenSoul Metamodeler Paradigm Plus Některé jsou již popsány v pracích našich předchůdců ([7], [11]). Vzhledem k tomu, že jsme toho názoru, že již dále není třeba uvádět výčet a stručný popis všech dostupných nástrojů, vybrali jsme pět z nich, kterým se budeme věnovat podrobněji Allfusion Component Modeler 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í. Allfusion Component Modeler částečně vychází z původního modelovacího nástroje Paradigm Plus, 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. 11 z 31

12 Produkt je integrován do skupiny nástrojů Allfusion Modeling Suite, které zvyšují produktivitu, zlepšují komunikaci, podporují týmovou práci, podněcují konzistenci a zajišťují provozní efektivitu. Mezi další nástroje toho balíku patří: AllFusion ERwin Data Modeler...pro efektivní a výkonné datové modelování a návrh databáze AllFusion Data Model Validator...ověřuje strukturální integritu databází, modelů, zvýrazňuje rozpory v návrhu a doporučuje přesná vylepšení AllFusion Component Modeler AllFusion Process Modeler...k analýze, dokumentování a zlepšování komplexních podnikových procesů (správa, kontrola verzí) AllFusion Model Manager...pro škálovatelné modelovací prostředí s více uživateli AllFusion Saphir Option...pro snadnou extrakci, objevování a analýzu metadat systémů SAP, PeopleSoft, Před začátkem modelování je nutné zvolit jeden z podporovaných přístupů k objektovému modelování, přičemž program podporuje metody Booch, Coad/Yourdon, Fusion (Hewlett- Packard), OOCL (Object-Oriented Change and Learning Method, from Arthur D. Little Inc.), Martin/Odell OOIE (Object-Oriented Information Engineering), OMT (Rumbaugh's Object Modeling Technique), Shlaer/Mellor, a pochopitelně dnes asi nejpoužívanější UML Unified Modeling Language [21]. 12 z 31

13 Dodržování standardů zajišťuje integrovaný validační nástroj Model Xpert Engine. Ve vnitřní repositoři se pak objekty ukládají v jednotném formátu, nezávisle na zvolené metodě. Program obsahuje skriptovací jazyk, který umožňuje generovat kód do jednotlivých jazyků. Uživatelé tedy mohou například Coad/Yourdon diagram uložit do repositoře a pak jej zpětně exportovat do jiného formátu a pak jej například vyobrazit pomocí OMT diagramu. Značné usnadnění představuje také funkce přímého generování dokumentace. Náročnější uživatelé si mohou navíc vytvořit vlastní modelovací metodu či upravit stávající, tak aby vyhovovala individuálním požadavkům uživatele. Samozřejmostí u všech tří produktů je možnost popisu každého modelu (autor, popis, název, projekt, datum, používaný prefix pro verzování atd.). Další užitečnou vlastností je možnost graficky upravit jednotlivé prvky diagramů. Lze nastavit barvu objektů, fonty popisků a jejich barvu. Dají se přidávat doplňující popisky a diagramy je pro větší přehlednost možno rozdělovat na subdiagramy. Týmovou práci podporuje společné sdílení repositoře. Pro každý projekt je nejdříve vytvořen Work Space, který uchovává společnou repositoř, a každý pracovník se k němu může připojit. Podporuje XML a XSL, čímž dovoluje snadné přenosy a ukládání dat a generování dokumentace v mnoha formátech vhodných rovněž pro ukládání na web. Pro snadnější orientaci v rozličných značkách jednotlivých modelovacích jazyků obsahuje každý projekt v Component Modeleru cheat sheet diagram, který funguje jako jakási legenda ke každému modelovacímu jazyku, jenž Component Modeler podporuje. 13 z 31

14 Jelikož výkon každého modelovacího nástroje a tedy i metamodelovacího nástroje stojí a padá na výkonu repositoře, jeví se jako značná výhoda elegantní objektově-orientovaná repositoř založená na systému OODBMS. Kromě zjevné přehlednosti, kterou objektověorientovaná repositoř poskytuje, přináší tento přístup i další výhody. Uživatel má přístup do OODBMS z příkazové řádky a tím i z jiných programů. Repositoř tak může být integrována do vývojářského procesu softwarových firem. Samotná integrace je ulehčena také nezávislostí repositoře na operačních systémech, stejná repositoř je pro Unix, OS/2 i pro Windows. Mezi další výhody systému OODBMS patří přímé ukládání objektů (persistence), jednodušší vazba na programovací jazyk, vazby mezi objekty (navigační model, vazby jsou rychlejší než u RDBMS), snadná rozšiřitelnost (dědičnost). 14 z 31

15 Důležitou vlastností je podpora verzování. Alternativou k verzování je pak možnost vypnutí automatické synchronizace, to znamená, že jakékoli změny nejsou bez přímého souhlasu uživatele zaznamenány do repositoře, nicméně tento přístup není zrovna bezpečný, protože tu existuje riziko kolapsu systému a tím i nenávratné ztráty průběžné práce. Většina dostupných příkazů, které se provádí při manipulaci s objekty, je implementována pomocí skriptů, přičemž uživatel má možnost tyto skripty přímo upravovat, popřípadě je přiřadit k jiným objektům. Skripty zahrnují přístupové funkce do repositoře a ke všem vytvořeným diagramům, přičemž pomocí skriptů může uživatel vytvářet či upravovat objekty v repositoři. Skriptovací jazyk disponuje veškerými základními rysy programovacích jazyků, jako například: proměnné, pole, práce se soubory, řízení toku Nicméně specifika metamodelování vedly vývojáře ze CA k zahrnutí mnoha nových funkcí do knihovny Component Modeleru. Component Modeler umožňuje 4 různé pohledy do repositoře. Kromě pro CASE nástroje běžného diagramového pohledu, nabízí možnost pohledu pomocí prohlížeče, tabulkového a maticového procesoru. Component Modeler podporuje dopředné i zpětné inženýrství (forvard and reverse engineering), které umožňuje přehledně zobrazit v modelu již existující entity a objekty. Component Modeler také značně usnadňuje práci databázovým specialistům. Především umožňuje automatické napojování relačních tabulek na jednotlivé objekty. Přiřazování však funguje i z druhé strany, neboť atributy objektů jsou přiřazovány přímo do sloupců tabulek. Toto obousměrné přiřazování pak značně usnadňuje komunikaci objektových programátorů s databázovými správci. Component Modeler dokáže také generovat SQL schémata 15 z 31

16 z datových modelů a podporuje spustitelné prvky Active X. Dovoluje načíst kódy programovacích jazyků Visual Basic, Java a C++. Po úpravě objektů lze opět automaticky vygenerovat kód v uvedených jazycích. Jako doplněk je možno nainstalovat rozšiřující komponentu, jež umožňuje exportovat class diagram do datového modelu, který je možno otevřít v programu ERwin, a naopak importovat hotový datový model z ERwinu. Jako přenosový formát jsou používány buď přímo soubory programu ERwin, nebo častěji XML. Podle počtu zakoupených nástrojů se odvíjí i cena, samotná licence celého balíku Allfusion Modeling Suite 7.1 je 6995 dolarů, cena licence s roční podporou 6995 dolarů, a licence s tříletou podporou stojí dolarů. Cena licence samotného Component Modeleru resp. Component Manageru 7.1 je 1595 dolarů. Nejnovější verze sady Allfusion Modeling Suite nese nové označení AllFusion Gen r7.5. CA jí uvedla na trh 8.dubna Nově obsahuje podporu UNIXu a z/os. Umožňuje převádění složitých modelů do zvolených jazyků (Java, C, COBOL, C#). Programátor tedy může střídat platformy, ať už je to mainframe, J2EE nebo.net. Component Modeler, který v nové verzi již nese název Component Manager, by měl rozumět nejnovějším verzím metamodelů (1,3,4) 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 meta-metatří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í klient-server 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, 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 [20]: 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. 16 z 31

17 Uživatelské rozhraní aplikace se skládá ze dvou hlavních částí: CBIva CBIva (nebo CBworkbench obsažený v předchozích verzích). Uživatelské rozhraní používá MDI (multiple document interface) model, který je založen na zobrazení všech oken v podobě podoken hlavního okna Graphical Editor Graphical Editor je kompletně vyvinut v Javě. A stejně jako v jiných CASE a meta-case nástrojích znázorňuje jednotlivé objekty a vztahy mezi nimi. Je to pokročily grafický modelovací nástroj, který umožňuje prohlížení a editování Telos modelů. Podporuje různé grafické typy. Uživatel si může zvolit vlastní grafický objekt pro vyjádření odlišných typů. Obě aplikace (CBworkbench a CB Editor) lze spustit rovněž jako Java applety ve webovém prohlížeči. 17 z 31

18 Obr. 7 - Tree browser zobrazuje super třídy, třídy a atributy objektů ve stromovém uspořádání. 18 z 31

19 GME Nástroj GME (Generic Modeling Environment) byl vyvinut na univerzitě ve Vanderbiltu. Je volně ke stažení. Jedná se o jedno z předních volně konfigurovatelných modelovacích prostředí. Zmíněné konfigurovatelnosti je dosaženo díky metamodelům, které jednoznačně specifikují modelovací vzory (modelovací jazyky či modelovací metodologii) aplikační sféry. 19 z 31

20 Zmíněné modelovací vzory zahrnují veškeré sémantické, syntaktické a prezentační informace týkající se dané oblasti a jejich koncept je následně využíván k vytváření modelů. Metamodelování je hlavní oblastí, na kterou se GME soustředí. Metamodelovací jazyk (konkrétně jeho syntaktická specifikace) vychází z notace diagramu tříd jazyka UML. Nicméně koncept modelovacího jazyka, vazby a atributy, které jsou s pomocí UML určeny, uživatelům neříkají mnoho o správném tvoření modelů. Proto samotné metamodely obsahují také OCL omezení, která jednoznačně vymezují sémantickou stránku modelovacího jazyka a uživatel se jimi musí řídit v každé součásti GME. Tato omezení spravuje Constraint Manager, který rozhoduje o jejich vyvolání. Například při porušení omezení s nejvyšší prioritou Constraint Manager vyvolá chybnou hlášku a zruší veškeré probíhající transakce. Služby Constraint Manageru může uživatel využít tak, že je přiřadí k právě editovaným událostem a nastaví, kdy musí být zkontrolovány. Porušení omezení s nižší prioritou vyústí pouze ve vyvolání chybné hlášky. GME obsahuje také interaktivní okno s náhledem do databáze veškerých omezení, přičemž uživatel si je jednoduše může vyvolat nebo je dočasně zrušit, může také přidat či odebrat vlastní omezení. Chybně nastavená omezení lze objevit s pomocí constraint debuggeru. Modelovací prostředí poskytuje několik různých druhů grafických rozhraní. Primární rozhraní zobrazuje modely jako oddělená okna, která obsahují objekty v podobě ikonek a čar. Rozmístění těchto objektů může být nahodilé a nezávislé na modelu, na druhou stranu rozmístění může být zautomatizováno pro lepší přehlednost rozsáhlých modelů. Dalším grafickým rozhraním je model browser, který využívá odlišný přístup založený na zobrazování stromové hierarchie modelu. Přičemž jednotlivé větve a uzly mohou být rozbalovány a zabalovány dle potřeby. Tento přístup pochopitelně zobrazuje daleko méně informací a neposkytuje tolik ovládacích možností, nicméně umožňuje nahlédnout na celkovou strukturu modelu. Třetí grafické rozhraní zobrazuje model v tabulkovém formátu a je podobné klasickému tabulkovému procesoru, což umožňuje hromadné editování a důslednou kontrolu. V hlavním editovacím okně probíhá základní tvorba a modifikace modelů. 20 z 31

21 Vizuální model se může nastavit, tak aby vyhovoval modelovací metodě, kterou chce uživatel využívat. Grafické navrhování a vizualizaci modelů zaštiťují takzvaní tapetáři (decorators), což jsou jednoduché softwarové komponenty, které jsou přidruženy ke každé operaci. Kdykoli je operace prováděna, editor GME musí zavolat tapetáře, který je přidružen k používanému modelovacímu jazyku. Tapetáři mají plný přístup k databázi modelu. Mezi další podpůrné metody umožňující konfiguraci GME patří překladače a další rozšiřující prvky. Překladače (interpreters) a rozšiřující prvky tvoří externí softwarové komponenty, které podporují/spolupracují s GME a rozšiřují tak jeho funkcionalitu (například automatické generování zdrojového kódu). Zatím poslední verze, kterou institut univerzity vypustil je GME 6. Mezi nové prvky oproti předchozím verzím patří podpora kompletně přestavěné knihovny a nově i podpora jmenných prostorů pro navrhování a skladbu metamodelů. Verze 6.0 také podporuje aktuální verze UDM a Great Metaedit + Nástroj vyvíjený firmou Metacase. MetaEdit+ může být využíván jako MetaCASE nástroj, ale také jako klasický CASE nástroj [7]. Znamená to, že obsahuje prostředky pro implementaci nových metod i předdefinované metody postihující nejpoužívanější oblasti využívající modelování. Aktuální verze programu je MetaEdit Nová metoda se v MetaEditu+ poměrně snadno implementuje pomocí definování jejího metamodelu, [24] 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. 21 z 31

22 Protože systém je otevřený, je možné programovat další výstupní sestavy pro potřeby dokumentace.v prvním případě umožňuje definici modelovacích metod 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í [7]. Editor od firmy Metacase se skládá ze dvou částí - MetaEdit+ Workbench a MetaEdit+ jako CASE nástroj. V části Method Workbench se definují modelovací metody/jazyk sestávající se z konceptů, pravidel, notací a kódového generátoru. Kromě vytvořených definic metod bude poté automaticky vytvořen CASE nástroj, a MetaEdit+ k němu vytvoří příslušné nástroje jako editor diagramů, generátory a prohlížeče jak můžeme vidět na následujícím obrázku. Obr. 8 - MetaEdit+ Workbench a MetaEdit MetaEdit Workbench Tato komponenta nám umožňuje vytvářet vlastní modelovací nástroje a to bez psaní složitého kódu [25]. Modelování probíhá z v plně grafickém prostředí a skládá se z několika kroků. Definice konceptů specifických pro naši modelovanou skutečnost Definice pravidel Nakreslení symbolů Tvorba generátorů 22 z 31

23 Definice konceptů Vývoj vlastního modelovacího jazyka začíná definicí pojetí jazyka. Pomocí Object Tool specifikujeme základní pojetí nového modelovacího jazyka a definujeme základní vlastnosti objektu. Obr. 9 - Object Tool Pomocí komponenty Property Tool poté nastavíme atributy které charakterizují modelovaný koncept. Atributy mohou být různých datových tipů jako například string, text, boolean a další. Další nástroje sloužící pro definici nového jazyka jsou Relationship Tool kde definujeme vztahy s okolím jako např. dědičnost, Port Tool pro definice různých způsobu získávání vstupních údajů (digitální vstup, magnetická karta, tlačítko) a Graph Tool pro definice způsobu modelování Výběr pravidel V druhém kroku definujeme pravidla pro vazby a atributy a tím vytvoříme funkční rámec nového modelovacího jazyka a propojíme jednotlivé komponenty mezi sebou. 23 z 31

24 Kreslení symbolů Posledním krokem je poté definice vhledu jednotlivých symbolů nového jazyka. Jejich grafické chování je poté automaticky poskytnuto programovým prostředím MetaEditu. Ke kreslení a editaci symbolů slouží nástroj Symbol Editor. Kreslení je jednoduché a intuitivní podobné jako u běžných grafických programů. Symboly jsou uloženy a mohou poté být využity při vlastním modelování. 24 z 31

25 Obr Kreslení symbolů Tvorba generátorů Další výhodou programu MetaEdit je snadná tvorba vlastních generátorů přesně podle potřeb projektu. Můžeme tak snadno testovat konzistentnost modelu, vytvářet různé reporty, generovat kód nebo dokumentaci. Obr Tvorba generátorů 25 z 31

26 MetaEdit+ Client Tato část programu slouží pro vlastní modelování a poskytuje plnou multiuživatelskou podporu na nejběžnějších platformách. Jedná se o standardní CASE nástroj nabízející možnosti modelování v mnoha přednastavených modelovacích jazycích. Hlavní předností je však možnost využívat vlastních modelů dříve definovaných pomocí MetaEdit Workbench. Nástroje které můžeme v MetaEdit+ používat a jejich vzájemné vztahy naznačuje následující obrázek: Diagram Editor slouží pro vlastní grafické modelování. Vkládáme zde jednotlivé symboly na pracovní plochu a definujeme vztahy mezi nimi. Stejná data si také můžeme prohlížet a editovat jako matici pomocí Matrix Editoru nebo jako tabulku v Table Editoru. Mezi těmito pohledy můžeme během modelování přepínat. 26 z 31

27 Komunikace s ostatními programy MetaEdit také výměnu dat a tím může spolupracovat s řadou externích aplikací. K programu můžeme přistupovat pomocí API rozhraní (to je však jako samostatná komponenta za příplatek), využívat import a export dat v XML formátu, program také umožňuje přístup pomocí příkazové řádky, kde se dá pomocí parametru automatizovat řada operací MetaEditu+. Nesmíme také zapomenout také na možnost uživatelsky definovaných reportů pomocí MetaEdit+ Workbench Ceny [25] MetaEdit+ licence Cena MetaEdit+ Workbench MetaEdit MetaEdit+ API MetaEdit+ Server (pro multiuživatelskou verzi) Akademická licence 150 Zkušební verze zdarma Zhodnocení Program je velmi všestranný, kromě možnosti metamodelování nabízí i klasický CASE nástroj při jeho pořízení tedy odpadá potřeba jiného modelovacího nástroje. Ovládání programu je intuitivní podle počítačových zvyklostí. Cena pro komerční použití je však poměrně vysoká. 27 z 31

28 OpenSoul Metamodeler (OSM) OpenSoul Metamodeler je založený na MOF modelování a postavený na MDR (Netbeans Metadata Repository) a JGraphu a programovaný v jazyku Java. 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 řadu chyb na nedodělků, ale je funkční. 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 [26] Meta Data Repository (MDR) MDR je klíčová 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. MDR hlavní znaky [26]: 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ů) Repozitoř může být vytvořena nebo otevřena pomocí tlačítka v hlavním menu programu nebo pomocí popup menu po stisknutí pravého tlačítka myši. Obr Prostředí OSM 28 z 31

29 Proces modelování je zahájen vytvořením nové repozitoře a volbou jejího typu přičemž nejjednodušší je použití BTree repozitoře. 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 je poté uložen do repozitoře. Zajímavou funkcionalitou je poté možnost 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 Zhodnocení Velkou předností programu jeho šíření pod open source licencí. Program je však stále ve fázi vývoje a plný nedodělků. Pokud by však autoři zapracovali na jeho dotažení tak má šanci stát se plnohodnotným metamodelovacím nástrojem Závěr Ověřili jsme, že nabídka programů pro metamodelování je opravdu bohatá. Dodavatelské firmy nabízejí širokou škálu funkčních řešení, často v kombinaci s plnohodnotným CASE nástrojem. Vysoká úroveň abstrakce metamodelování dovoluje vývojářům a analytikům tvořit modely šité na míru popisovaným skutečnostem pomocí nových metodik definovaným meta-case nástrojem. Vyšší úroveň abstrakce a pracnější tvorba ale zároveň brání k masivnějšímu nasazení meta-case nástrojů. Ty se používají spíše pro analýzu než pro vývoj softwaru. Trend je dle našeho názoru ve zjednodušování uživatelského rozraní, které vede usnadnění a zrychlení vývoje a také v rozšiřování funkcionality nástrojů. Můžeme také očekávat nárůst používání meta-case nástrojů pro tvorbu specifických modelů. 29 z 31

30 3 POUŽITÉ ZDROJE [1] STÖRIG, Hans Joachim. Malé dějiny filosofie. Miroslav Petříček, Petr Rezek, Karel Šprunk. 7. v KN 1. vyd. vyd. Kostelní Vydří : Karmelitánské nakladatelství, s. Orig.: Kleine Weltgeschichte der Philosophie. [2] SVRŠEK, Jiří. Století polemik o základech matematiky: podle článku Gregoryho Chaitina. 13 s. Dostupný z: [dokument ve formátu PDF] [3] PETRÁČKOVÁ, Věra, KRAUS, Jiří. Akademický slovník cizích slov. 1. dotisk vyd. Praha : Academia, s. ISBN [4] PÍCKA, Marek <picka@pef.czu.cz>. Metamodelování v praxi. PEF ČZU Praha: Katedra informačního inženýrství. 7 s. Dostupný z: [dokument ve formátu PDF] [5] HREBEJK, Petr, MATULA, Martin. Metamodelování. 8 s. Dostupný z: [dokument ve formátu PDF] [6] KLEMŠINSKÝ, Petr. Návrh systému pomocí MDA. Brno: Masarykova univerzita: Fakulta informatiky, Diplomová práce. 2007, 58 s. Dostupný z: [dokument ve formátu PDF] [7] APFELTHALER, Jan, BURIANOVÁ, Monika, CERMAN, Micha, CIBULKA, Ondřej, FOŘT, David, LORENC, Ondřej. (charakteristika, vývoj, přehled trhu, trendy). Praha: Vysoká škola ekonomická, Katedra informačních technologií. Seminární práce. 2006, 33 s.dostupný z: [dokument ve formátu PDF] [8] ZENTNER, Albert <a.zentner@aquasoft.cz>. Metatmodelování: OpenSoul Metamodeler, UML profily v EA. Dostupný z: [dokument ve formátu ppt] [9] MERUNKA, Vojtěch <merunka@pef.czu.cz>. 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í. 7 s. Dostupný z: [dokument ve formátu PDF] [10] OMG Unified Modeling Language Specification, verze 1.4. [www dokument].dostupný z: [11] BALOGH, Uštván, JANKÓ, Gabriel, MURÍN, Jozef, ŽILKA, Radim. (charakteristika, vývoj, přehled trhu, trendy). Praha: Vysoká škola ekonomická, Katedra informačních technologií. Seminární práce. 2005, 24 s.dostupný z: [dokument ve formátu PDF] [12] KOTZIAN, Jiří, SROVNAL, Vilém. Jazyk UML pro návrh řídicích systémů. Sdělovací technika: telekomunikace elektronika multimédia. č. 1, roč [www dokument]. Dostupné z: [cit ] 30 z 31

31 [13] LÉBL, Jan. Modelování aplikací nanovo: UML 2.0, MDA nebo někdo další? Connect!, únor Dostupné z: [dokument ve formátu PDF] [14] BUCHALCEVOVÁ, Alena. Model Driven Architecture jako nový přístup k vývoji i integraci aplikací, sborník konference SI 03. Dostupný z: [dokument ve formátu PDF] [15] ŘEPA, Václav. MDA, MOF. Prezentace ze semináře OpenSoul. Dostupný z: [dokument ve formátu PDF] [16] FILIP, Alois. OCL: Object Constraint Language. Praha: Vysoká škola ekonomická, Katedra informačních technologií. Seminární práce [www dokument]. Dostupný z: [17] WOKOUN, Michal. MOF: Meta Object Facility. Praha: Vysoká škola ekonomická, Katedra informačních technologií. Seminární práce [www dokument].dostupný z: [18] ] PÍCKA, Marek <picka@pef.czu.cz>. Metamodel BORMu jako rozšíření metamodelu UML. PEF ČZU Praha: Katedra informačního inženýrství. 12 s. Dostupný z: [dokument ve formátu PDF] [19] KEUFFEL, Warren. A Trio of Object-Modeling CASE Tools [online] The Intelligent Enterprise Weblog [cit ]. Dostupné z: [20] ConceptBase Team. ConceptBase [online] RWTH Aachen University, ConceptBase Team 2007 [cit ]. Dostupné z: [21] CA [www portál]. Dostupné z: [cit ]. Domovská stránka dodavatele software pro správu IT infrastruktury [22] ŘEPA, Václav. Programování ve velkém. Softwarové noviny. 2003, roč. XIV, č.5, s [23] B. Henderson-Sellers, A.P. Bulthuis, Rijswijk, Object-Oriented Metamethods, Springer Verlag 1997, ISBN [24] MetaCase. Domovská stránka firmy MetaCase. Dostupné z [25] OpenSoul MetaModeler. Domovská stránka nástroje OpenSoul MetaModeler. Dostupné z: [26] OpenSoul. Domovská stránka projektu OpenSoul. Dostupné z: 31 z 31