VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE

Transkript

1 VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE Fakulta informatiky a statistiky Katedra informačních technologií Semestrální práce metacase nástroje CASE (Computer Aided Software Engineering) 4IT450 Vypracovali: LS 2010/2011 Dvořák Jan Heideker Petr Krug Jan Nejtek Petr Remta Daniel Vojtková Erika 1

2 Obsah 1. Úvod Co je to meta-model Vývoj CASE nástrojů CASE vs metacase Silné stránky metacase Slabé stránky metacase Metamodelovací prostředky GOPRR (5) MOF (Meta-ObjectFacility) (7) COMMA (Common Object Methodology Metamodel Architecture) (3) NIAM (Nijssen s Information Analysis Method) (8) DSM (DomainSpecific Modeling) (9) Případová studie Nokia MetaEdit+ přinesl revoluci do vývoje software pro mobilní telefony Nokia Nástroje Meta-CASE Actifsource Práca s Actifsource Meta Programming System MPS AToM KOGGE JKOGGE Argo UML Concept Base Coral GME OpenSoul Metamodeler

3 4.11. MetaView MetaEdit GEMS GME (Generic Modeling Environment) Licence a aktuální verze Architektura Základní prvky v GME Vyjadřování vztahů v GME Spojení Odkazování Sestavování (Set) Možnosti rozšíření GME MetaGME Omezení Užívání Metamodelů Přídavné GME nástroje a utility Závěr Citovaná literatura

4 1. Úvod Tato práce se zaměřuje na problematiku metacase nástrojů a možnosti jejich využití v oblasti meta-modelování. Cílem této práce je vysvětlit základní terminologii v oblasti metamodelování a popis některých metacase nástrojů, které jsou v současnosti na trhu dostupné. První část práce se zabývá představením oblasti meta-modelování a jejím významem, vysvětlením základních pojmů z oblasti meta-modelování a popisem základních druhů metamodelů. Druhá část práce se soustředí především na přehled a porovnání některých metacase nástrojů a na úvahu očekávaného vývoje v této oblasti do budoucnosti Co je to meta-model Termín metamodel vychází ze slova model a je tedy vhodné vysvětlit nejprve co znamená termín model. Slovo model se používá v mnoha vědních oborech, ale většinou se pod pojmem model rozumí reprezentace nějakého objektu, nebo popis skutečnosti v reálném světě. Model tedy obvykle slouží pro popis anebo zjednodušení reality. Předpona "meta" bývá používána v souvislosti se zvýšením úrovně abstrakce u významu některých slov. Například pojem metadata je velmi známý a v krátkosti se definuje jako data o datech. V praxi to znamená, že například metadata u digitální fotografie zaznamenávají další detaily a data související s touto fotografií. Například čas pořízení fotografie, rozlišení, ohniskovou vzdálenost apod. Metadata tedy pracují s vyšší vrstvou abstrakce dat samotných. V našem případě jsou data reprezentována fotografií a metadata jsou reprezentována údaji, které slouží k identifikaci podmínek a nastavení, za kterých byla digitální fotografie pořízena. Metamodel je analogií k metadatům, kdy lze v této souvislosti zjednodušeně říci, že metamodel je model popisující jiný model. V našem případě jsou tedy modely CASE nástrojů popisovány modely metacase nástrojů Vývoj CASE nástrojů Od počátku vývoje aplikací bylo snahou vývojářů vytvořit a používat nástroj, který by jim pomohl při návrhu aplikace. Čím byly aplikace složitější, tím více bylo potřeba vytvořit model aplikace, který by pomohl vývojářům v počáteční fázi vývoje a umožnil jim přehledný náhled na strukturu aplikace, kterou chtějí vyvíjet. Nejprve se začali objevovat první 4

5 metodiky, které se snažily standardizovat, zjednodušit a zpřehlednit vývoj nových aplikací (1). V té době byly vytvořeny první CASE nástroje, které využívaly dostupné metodiky a umožňovaly rychlejší návrh modelu nové aplikace. CASE nástroje také umožnily automaticky vygenerovat kód z modelu, který byl v nástroji vytvořen a později bylo možné generovat dokonce funkční části aplikace, či celou aplikaci na základě vytvořeného modelu v CASE nástroji. CASE nástroje tedy zjednodušily vytváření modelů aplikací a znatelně tak zrychlily vývoj aplikací a zároveň i redukovaly chyby, které mohou v rámci vývoje aplikací nastat. S rostoucím počtem vyvíjených aplikací a s vyššími požadavky na vytváření modelu a rostoucí variabilitě platforem, pro které se aplikace začaly vyvíjet, se začaly objevovat také první nedostatky CASE nástrojů, které často nedostačovaly nárokům, které na ně vývojáři měli. Z důvodu velké variability v oblasti modelování a z důvodu potřeby vytvořit individuální CASE nástroj, který bude splňovat všechny požadavky, které na něj vývojáři mají, vznikla oblast metacase nástrojů, které odstraňují nedostatky CASE nástrojů a jejich omezenou možnost přizpůsobení individuálním nárokům a zároveň se používají při návrhu a vývoji nových CASE nástrojů CASE vs metacase Case nástroje jsou tedy určeny pro vývoj nových aplikací a jsou svázány s určitým typem modelování a notací což je do určité míry omezuje a snižuje jejich oblast využití. Case nástroj tedy umí pouze jazyk, pro který je vytvořen a snižuje to možnost jeho využití u jiných modelů. Case nástroje jsou totiž založeny na dvoustupňové architektuře, která neumožňuje dostatečnou variabilitu pro všechny uživatele. Tato architektura disponuje nemodifikovatelnou definicí modelu s omezenými možnostmi využití. 5

6 Obrázek 1: Rozdíl mezi CASE a metacase (2) Jak je vidět na obrázku 1, tak CASE nástroje mají dvoustupňovou architekturu, zatímco metacase nástroje disponují třístupňovou architekturou. Třístupňová architektura metacase nástrojů odstraňuje omezení CASE nástrojů což je fixně zkompilovaný kód. Všechny tři vrstvy jsou v rámci metacase vzájemně propojené a vyšší vrstva umožňuje vytvářet metodiku pro nižší vrstvu. Nejvyšší vrstva zahrnuje metamodelovací jazyk, který slouží ke specifikaci metamodelu. To poskytuje větší svobodu při tvorbě individuálního CASE nástroje, který poskytuje vhodnější a přizpůsobitelnou funkcionalitu kterou požaduje odběratel Silné stránky metacase Jednou ze silných stránek metacase nástrojů je například svoboda volby metody, kdy v rámci metacase je možno volit metodu, která bude při vývoji použita, což poskytuje větší variabilitu v oblasti vývoje a návrhu specifických řešení. Další silnou stránkou je rychlejší a přehledný vývoj specifických řešení, která jsou požadována odběratelem, což umožňuje vyšší míru customizace u vytvořených nástrojů a 6

7 přizpůsobení dalším specifickým požadavkům odběratele. Většinou jsou také potřeba nižší náklady na tvorbu nového modelu. Jedním z přínosů metamodelování je také možnost upravit již existující metody, jelikož prostředí metacase není vázané žádnou metodikou. V souvislosti s tím je také možné přidávat další metadata do metamodelu, což zvyšuje přehlednost a rozšiřuje to možnosti vývojářů. Shrňme si tedy silné stránky meta-case nástrojů. Nástroje meta-case nabízejí nové možnosti užití nástrojů CASE. Analytikům, vývojářům a systémovým integrátorům dávají příležitosti nastavit si metody způsobilé přímo na jejich unikátní životní cyklus softwaru umožňují vyvinout metody a prostředky, které nemohou současné nástroje nabídnout a ani nemohou být rozšířeny dodavateli (vývojáři). Poskytují příležitost k obohacení a zlepšení již existujících metod tak, aby lépe pasovaly do životního cyklu vývoje softwaru Při správné specifikaci požadavků na meta-case nástroj získá klient nástroj, který umožňuje efektivně generovat programový kód či nový model. Výhodou je možnost inkrementálního dodávání metadat do metamodelů a samozřejmě podpora sdílení metadat spolu s meta-metadaty mezi meta-metamodely (3) 1.4. Slabé stránky metacase Na druhou stranu metacase má několik slabých stránek, které vyplývají z podstaty samotného vývojového prostředí. Vytvoření modelu v rámci metacase je totiž relativně pracné a je třeba uvažovat se spoustou prvků, které budou mít na výsledek vliv a které je třeba zvážit v rámci procesu vývoje. Vzhledem k tomu, že požadovaný výstup je často dělaný pro specifické použití, je nutná hlubší úvaha o používání výstupů v rámci metacase, což je velmi pracné. MetaCASE se také nehodí pro řešení "standardních" problémů, které mohou být vyřešeny CASE nástrojem. MetaCASE je vhodný především pro specializované použití a je vhodné předem zvážit, zda je opravdu potřeba použít metacase nástroj, nebo zda by 7

8 nestačilo použít jeden z CASE nástrojů, které sice neumožňují tak vysokou míru volnosti, ale na druhou stranu je snazší držet se vytyčeného směru, který CASE nástroje umožňují. 2. Metamodelovací prostředky Metamodelovací metody definují rámec pro metamodelování, který obvykle obsahuje definici metamodelu a metamodelovacího jazyku. Pomocí tohoto metamodelovacího jazyku je definován metamodel. Pro potřeby metamodelování bylo vyvinuto a samozřejmě je i do budoucna vyvíjeno mnoho přístupů pro tvorbu metamodelu. Jmenovat můžeme například COMMA, GOPRR, MOF, OPRR, CoCoA, NIAM, COOM atd. (4) V této práci si blíže popíšeme několik z nich. Většina z dnešních metamodelovacích jazyků vychází z ER modelu (Entity-Relationship). Jedná se o zobrazení nadefinovaných entit a vzájemných vztahů, které jsou mezi těmito entitami GOPRR (5) Metamodelovací jazyk GOPRR (GraphObjectProperty Role Relationship) vznikl jako součást disertační práce Stevena Kellyho. Rozšířil pro své potřeby jazyk OPRR. Základní prvky modelu GOPRR: Graph (diagram) jedná se o kolekci objektů, vztahů a rolí, která definuje, co je možné a jak spojovat dohromady. Objects (Objekty)- Definují entitu, která může existovat sama o sobě. Jedná se o abstrakci reality, kdy vybereme objekt a přiřadíme mu určité vlastnosti (Properties), které považujeme za důležité. Properties (Vlastnosti) jedná se o vlastnosti, atributy objektů. Mohou být zpřístupněny jako části objektů nebo vztahů. Charakterizují objekt, graf, roli nebo vztah. Relationships (Vztahy) existuje mezi dvěma anebo více objekty Roles (Role) existuje mezi vztahem a objektem (6) Podporované datové typy modelu GOPRR: Number 8

9 String Boolean Text VectorGraphics Collectionofitems Non-property (5) Obrázek 1 - Metamodel stavového modelu pomocí GOPRR (6) 2.2. MOF (Meta-ObjectFacility) (7) Meta.ObjectFacility (MOF) je standardem od OMG (Object Management Group) pro MDE (Model-DrivenEngineering). Standardy OMG jsou založené na čtyřvrstvé architektuře. Jedná se o klasický rámec pro metamodelování. Tyto vrstvy jsou dle různých zdrojů popisovány přibližně takto: M0 - Informační (datová) vrstva zahrnuje popisovaná data. Konkrétní realizaci nějakého prvku z okolního světa. M1 Vrstva modelu zahrnuje metadata, která popisují data v informační vrstvě. M2 Vrstva metamodelu popisuje strukturu a sémantiku metadat. Z metametadat jsou utvářeny modely, které jsou abstraktním jazykem pro popis různých druhů dat. Do této vrstvy můžeme zařadit například UML. M3 Vrstva meta-metamodelu Popisuje metamodel a definuje sémantiku a strukturu meta-metadat. (4) 9

10 Obrázek 2 - Čtyřvrstvá architektura dle OMG (7) Standard MOF popisuje vrstvu meta-metamodelu na obrázku M3. MOF původně vznikl, protože OMG potřebovalo metamodelovací architekturu pro definici jazyka UML. OMG definovalo několik různých metamodelů, které jsou založené na MOF: Metamodel UML (Unified Modeling Language) Standardy pro objektové modelovací jazyky. Metamodel IDL (Interface DefinitionLanguage) Jedná se o standard popisující rozhraní softwarových komponent. Metamodel CDW (Common Data Warehouse) Standard popisující architekturu datových skladů. Data mezi jednotlivými modely lze vyměňovat pomocí formátu XMI (XML MetadataInterchange), který je rovněž standardem OMG. Základními koncepty MOF jsou: Třída (Class) pro modelování metaobjektů Asociace (Assotiation) modelují binární relace mezi metaobjekty Datové typy (Data Type) pro modelování primitivních dat Balíček (Package) je určen pro modularizaci modelu. 10

11 MOF jako mezinárodní standard MOF je mezinárodním standardem: ISO/IEC 19502:2005 Information technology -- Meta ObjectFacility (MOF) Na MOF lze pohlížet jako na standard pro psaní metamodelů, například modelů abstraktní syntaxe DSL. Pro manipulaci s MOF modely bylo definováno rozhraní Java API, které se jmenuje JMI 1 (7) 2.3. COMMA (Common Object Methodology Metamodel Architecture) (3) Tento přístup v dnešní době již není vyvíjen, jelikož byl tento projekt ukončen. Můžeme se s ním setkat pouze u starších nástrojů. Popíšeme si jej tedy jen okrajově, aby byl výčet zde uvedený kompletní. Pro přístup bylo složité nalézt jakékoliv oficiální materiály, proto jsme vycházeli pouze ze zdroje č. (3) Přístup COMMA se snažil vybrat společné prvky, které mají všechny objektově orientované metodiky. Tyto společné prvky byly posléze ustanoveny jako základní pojmy meta-modelu. Přístup COMMA tedy prezentoval meta-modely nejrozšířenějších objektově orientovaných metodik. Jednalo se o velmi výkonný objektově orientovaný metamodelovací jazyk. Mezi základní prvky patří: Pojem (concept) je pojmenován a obsahuje atributy Asociace (association) asociace je vyjádřením vztahu mezi pojmy Dědění (inheritance) dědění vyjadřuje relaci specializace Agregace (aggregation) jedná se o speciální případ asociace, kdy dochází ke skládání. 1 Více informací na: 11

12 Role (role) používá se v případech, kdy objekt přijímá charakteristiky jiného objektu. Role je dočasná a objekt nemusí mít přidělenu jen jednu, přiděleno může mít nekonečně mnoho rolí. (3) 2.4. NIAM (Nijssen s Information Analysis Method) (8) NIAM byl původně navržen pro informační analýzu, ale později se použil v několika meta-modelovacích technikách. Základní prvky NIAM jsou: stav (state) přechod (transition) třída (class) atribut (attribute) operace (operation) Model NIAMM je vhodný zejména pro tvorbu stavového modelu. (6) (8) Obrázek 3 - Metamodel stavového modelu pomocí NIAMM (6) 2.5. DSM (DomainSpecific Modeling) (9) DomainSpecific Modeling - jak již překlad tohoto termínu napovídá, jedná se o modelování pro specifické odvětví, oblasti jako jsou například finance, průmysl, 12

13 zdravotnictví a další. Jedním z hlavních důvodů pro vznik metamodelování byla potřeba definovat a vytvářet metamodely, které budou specifické pro určitou oblast a kde jeden druh metamodelu (např. UML) nebude plně dostačující. DSM slibuje změnu v přístupu k modelování tím, že poskytuje vyšší úroveň abstrakce od kódu, než je tomu v případě UML. DSM poskytuje modelové konstrukce pro vývojaře, které napodobují reálný svět více do podrobna a v těsnějších souvislostech než tomu bylo doposud. A co je nejdůležitější, DSM má schopnost generovat kompletní kód z modelu, což vede k mnohem produktivnějšímu způsobu práce vývojářů. Vygenerovaný kód z modelu se jmenuje DomainSpecificLanguage (DSL). Základním smyslem DSL je, aby bylo specifické odvětví osvobozeno od zásahů programátorů. DSL chce dosáhnout toho, aby bylo možné vytvořit pouze model pro určité odvětví (např. průmyslová výroba) a z tohoto modelu byl rovnou vygenerován kód, pomocí, kterého budeme moci řídit výrobní linku. Tímto by mělo dojít k zásadnímu usnadnění práce a usnadnění přechodů od modelu přímo k výrobku. Pro modelování DSM je možné použít nástroj MetaEdit+, který se jím přímo zabývá a mnoho dalších, které lze na trhu nalézt. OMG se rovněž rozhodlo podporovat tuto cestu zavedla rozšíření do svého jazyka UML jedná se o tzv. UML Profily. (9) 13

14 3. Případová studie Nokia 3.1. MetaEdit+ přinesl revoluci do vývoje software pro mobilní telefony Nokia Tato případová studie, jejíž plné znění je ke stažení na stránkách www-metacase.com (10) se zabývá tím, jak nástroj MetaEdit+ dokázal ovlivnit vývoj softwarového vybavení ve společnosti Nokia. Efektivní vývojové nástroje jsou životně důležité pro zvýšení produktivity a zlepšení kvality produktů. Když společnost Nokia hledala efektivní nástroj pro modelování, stanovila si hlavní kritéria, které by měl nástroj umět flexibilní způsob podpory, generování kódu apod. Po vyhodnocení velkého množství nástrojů se rozhodli pro vývoj vlastního řešení pomocí MetaEdit+, což je metacase nástroj od firmy MetaCase. Toto rozhodnutí se časem ukázalo být jako zcela uspokojivé. Mobilní telefony a mobilní výpočetní technika je jednou z nejdynamičtěji se rozvíjející oblastí. Mobilní telefony se stále vyvíjejí a výrobci se stále snaží přicházet na trh s inovacemi a novými funkcemi, které mění způsob, jak lidé komunikují a podnikají pomocí mobilních technologií. Software uvnitř mobilních telefonů se stal pro zákazníky jedním z hlavních bodů zájmu kvalitní software určuje vítěze na poli mobilních telefonů. Pro výrobce je životně důležité přicházet na trh s neustálými vylepšeními, aby nezůstal v pozadí za konkurencí, k tomu je za potřebí také samozřejmě kvalitní software. Aby byla Nokia konkurenceschopnější, hledala vývojový nástroj, který by ji pomohl konkurenceschopnost zvýšit a také řádově zvýšit produktivitu vývojových týmů. Vylepšení se Nokia snažila dosáhnout pomocí těchto strategií: Práce na vyšší úrovni abstrakce designeři nemusí znát vše. Mohou se soustředit na design a nemusí přemýšlet nad tím, jak onu konkrétní věc implementovat v kódu. Zapouzdřená doména znalostí nejsou zde žádné přebytečné prvky. Pouze prvky, které se týkají vývoje mobilních telefonů. Tento přístup velice usnadňuje učení a zaškolování nových zaměstnanců. Možnost generovat zdrojový kód rovnou z designu návrháři tedy tvoří design a zároveň, aniž by museli umět programovat, tvoří i zdrojový kód. Na počátku hledání se vývojový tým pokoušel o hodnocení a testování prominentních CASE nástrojů, které se však všechny ukázaly být neuspokojivé. Vždy jim chyběla určitá část 14

15 funkcionality anebo práce s nimi byla značně neefektivní. Na trhu bylo sice mnoho všeobecných nástrojů, které pomocí UML nebo jiných modelovacích jazyků umožňovaly vývoj. Problém byl však v tom, že byly příliš všeobecné a většina z nich se pro oblast mobilních telefonů vůbec nehodila. Nokia se tedy rozhodla, vytvořit si vlastní domainspecific modelovací nástroj, který bude určen přímo pro mobilní telefony. Celkem brzy Nokia zvolila metacase přístup k řešení tohoto problému. Výhody metamodelování jsou popsány výše, takže je zde nebudu znovu opakovat. Jako nástroj byl vybrán MetaEdit+. Vybrán byl zejména proto, že práce v něm je velice flexibilní a rychlá. Nokia si také velice cenila efektivní možnosti generování kódu přímo z modelu (tento princip je popsán v kapitole věnující se DSL 2 ). Přínosy, kterých Nokia implementací dosáhla: Zvýšení produktivity snížily se průměrné doby vývoje produktů. Například modul, jehož vývoj dříve trval dva týdny, nyní trvá pouhý jeden den. Zaměření se na funkcionalitu, ne na implementaci MetaEdit+ umožňuje vývojářům soustředit se na vyvíjenou funkcionalitu a abstrahovat od zdrojového kódu. Už není potřeba se učit programovat. MetaEdit+ také do značné míry usnadňuje změny, které jsou v programech (modulech) prováděny. Generování plnohodnotného kódu z modelů v mnoha případech je vygenerováno 100% potřebného kódu a není jej nutné nikterak upravovat. Tradiční programování tak již není potřeba v takové míře jako v minulosti. Zdokonalená dokumentace dokumentace, kterou MetaEdit+ generuje je plně v souladu se standardy, které Nokia vyžaduje. Automatickým generováním dokumentace došlo také k výraznému ušetření času a nákladů. Podpora pro výuku a zaškolování nových vývojářů další byly zaznamenány ve snížení nákladů na zaškolení nových členů vývojářských týmů. Jelikož je tento nástroj a jazyk v něm používaný plně přizpůsoben tomuto odvětví (domain-specific), všichni vývojáři si jej velmi rychle osvojí. Doba potřebná na zaučení nováčku se snížila z šesti měsíců na pouhé dva týdny a náklady na školení byly sníženy na zlomkovou částku. Hlavním důvodem je orientace na konkrétní odvětví: noví vývojáři nepotřebují rozumět všem detailům a ani nahlížet do kódu, vše je soustředěno na vyšší úroveň abstrakce. (10) 2 DomainSpecificLanguage 15

16 4. Nástroje Meta-CASE 4.1. Actifsource Výrobca: actifsource GmbH Verzia: ( ) Actifsource je DSM nástroj, ktorý sa používa na analýzy oblastí, návrh modelov, generovanie kódu, testovanie, refaktoring a následnú údržbu. Jedná sa o grafický nástroj navrhnutý k tomu, aby pomáhal budovať robustný a udržovateľný software. Funguje ako plug-in pre vývojové prostredie Eclipse. Actifsource umožňuje upravovať štruktúru prvkov a generovať kód štruktúry a vzájomné závislosti potrebné k vytvoreniu komplexného sw systému v akomkoľvek programovacom jazyku pre ktorýkoľvek operačný systém. Obrázek 4 ActifSource (11) Actifsource je k dispozícii v dvoch variantách: Free Community Edition, ktorá je zadarmo, a Enterprise Edition v cene $1490. Prvá zmieňovaná verzia je open source a je podporovaná Actifsource Community prostredníctvom fóra na webových stránkach výrobcu. Enterprise Edition obsahuje viac funkcií a zahŕňa v sebe plnú komerčnú podporu. 16

17 Práca s Actifsource Obrázek 5 Kroky modelování s ActifSource (11) 0. Analýza byznys oblasti 1. Návrh meta modelu K návrhu meta modelu pre vybranú oblasť slúži Grafický Model-Editor actifsource. Využiť je možné vlastné abstraktné pojmy, podľa toho ako sa hodia. (11) Obrázek 6 - Prostředí ActifSource 2. Definovanie modelu oblasti 17

18 V tomto kroku sa zostaví model oblasti a definujú sa konkrétne doménové objekty použitím domain specific classes. Actifsource Resource-Editor podporuje dokončovanie kódu a validáciu v reálnom čase. (11) Obrázek 7 - Prostředí ActifSource 3. Nakódovanie šablóny Actifsource poskytuje nový prístup k šablónovému generovaniu kódu, ktorý umožňuje napísať kód šablóny bez potreby špeciálneho šablónového jazyka. Šablóny tu sú napísané v cieľovom jazyku (napr. C#, Cobol, C, C++, Groovy, html, Java, xml, atď.). Namiesto kódovania špecifických tried sa píše obecný kód. (11) 18

19 4. Vygenerovanie kódu Obrázek 8 - Prostředí ActifSource Kód pre všetky konkrétne triedy je možné zo šablón vygenerovať automaticky alebo kliknutím na tlačítko. Actifsource používa Eclipse builder infrascture, preto sa všetky zmeny zaznamenávajú automaticky a kód sa podľa toho obnovuje. (11) Obrázek 9 - Prostředí ActifSource Internet Posledná aktualizácia verzia Cena Free Community Edition - zdarma Enterprise Edition - $ Meta Programming System MPS Výrobca: JetBrains Verzia: MPS je nástroj, ktorý poskytuje prostredie na vývoj a rozvoj DSL spolu s aplikáciami. Nie je však určený k tvorbe nového jazyka. Jeho počiatky siahajú do roku 2003, kedy odštartoval 19

20 výskumný projekt. Od roku 2006 ho tvorcovia používali k vývoju ich nových produktov a od roku 2009 je k dispozícii verejnosti zdarma. Hlavným cieľom MPS je umožniť rozširovanie jazykov. Vzhľadom na to, že už existujúce jazyky majú definovanú striktnú syntax a to môže limitovať ich flexibilitu. Na MPS je zvláštna netextová prezentácia kódu programu. Uskladnenie a vizuálna reprezentácia programu tu je oddelená, na rozdiel od bežných programovacích jazykov, kde je to jedno a to isté, najčastejšie text. Hlavnou výhodou tohto prístupu je to, že eliminuje potrebu parsovania kódu. Na to, aby presné pravidlá mohli popisovať jazyk, musia byť definované. V MPS je kód udržovaný v tzv. Abstract Syntax Tree, ktorý pozostáva z uzlov s premennými, potomkami a referenciami, a plne popisuje kód programu (12). Celý proces s definovaním pravidiel, vytvorením dobrého parsera a pracovaním s textom je náročný. Keďže v MPS sú programy uchovávané ako modely a nie text, tomuto procesu sa vyhneme. V MPS sa objekty nazývajú koncepty. Namiesto pravidiel sa vytvára meta-model modelu jazyka, z čoho vychádza názov Meta Programming System. V rámci definovania konceptov sa popisujú taktiež vzťahy medzi konceptmi. Na to, aby sme mohli napísať a použiť popísaný jazyk je potrebný nejaký druh editora. A to je presne to, čo sa v MPS vytvára editor či editory, ktoré operujú na modelovej reprezentácii programu. (13) Obrázek 10 MPS koncept (13) MPS obsahuje veľkú kolekciu jazykov. Základný jazyk sa volá Base Language a je MPS verziou Javy. K nemu tu existujú rozšírenia rôznych aspektov ako sú napr. DSL pre kolekcie. 20

21 Mimo Base Language a jeho rozšírení sú v MPS mnohé ďalšie DSL. Napr. jazyk pre popis editorov, jazyk pre popis refaktoringu, pre popis obmedzení konceptov, atď. (13) Internet Posledná aktualizácia verzia Cena Open-source 4.3. AToM 3 Výrobca: MSDL, School of Computer Science, McGill University AToM 3 je vizuálny meta-modelovací nástroj vyvinutý v Modelling, Simulation and Design Lab (MSDL) na School of Computer Science, McGill University v Kanade. Vyvinutý bol v úzkej spolupráci s Prof. Juanom de Lara zo School of Computer Science, Universidad Autónoma de Madrid v Španielsku. Názov AToM 3 znamená: A Tool for Multi-Formalism and Meta-Modelling. K dispozícii je zadarmo na stránkach (14). Dve hlavné úlohy AToM 3 sú meta-modelovanie a transformácia modelov. Meta-modelovanie sa týka popisu a modelovania rôznych druhov formalizmov použitých na modelovanie systémov. Transformácia modelov sa vzťahuje na (automatický) proces konvertovania, prekladu alebo modifikovania modelu v určitom formalizme do iného modelu, ktorý môže a nemusí byť v rovnakom formalizme (15). AToM 3 má meta-modelovaciu vrstvu, v ktorej sú modelované rôzne grafické formalizmy. Z meta špecifikácie AToM 3 generuje nástroj na spracovanie modelov popísaných v špecifikovanom formalizme. Modely sú vnútorne reprezentované použitím Abstract Syntax Graphs (15). AToM 3 je napísaný v jazyku Phyton. Hlavným komponentom je Procesor, ktorý je zodpovedný za nahrávanie, ukladanie, vytváranie a manipulovanie s modelmi. Taktiež sa stará o generovaniu kódu pre upravené nástroje. V AToM 3 sa zachádza s modelmi na hocakej meta-úrovni rovnako. Meta-modely umožňujú vytvárať modeli v určitom formalizme, metameta-modely sa používajú na popis formalizmu samotného. 21

22 Obrázek 11 AtoM (15) Internet Posledná aktualizácia Cena zdarma 4.4. KOGGE Výrobca: Universität Koblenz-Landau KOGGE je meta-case nástroj, ktorý bol vyvinutý na Univerzite Koblenz v Nemecku. Umožňuje generovať nástroje pre vizuálne jazyky. Hlavná myšlienka spočíva v tom, že namiesto programovania nástrojov pre všetky rôzne metódy, tu existuje jeden základný systém (base system). Ten je rovnaký pre všetky nástroje. Ďalej tu funguje špecifický popis nástroja (tool description). Ten je jedinečný. Popis nástroja je interpretovaný základným systémom a ich kombinácia vyústi do konkrétneho nástroja. Z pohľadu užívateľa oddelenie popisu nástroja od základného systému nie je viditeľné (16). 22

23 Obrázek 12 KOGGE (16) Popis nástroja pozostáva z troch častí, ktoré popisujú: Koncept metódy Štruktúru menu Interakciu s užívateľom Koncept metódy popisuje štruktúru repository. Štruktúra menu a interakcia s užívateľom určujú správanie nástroja. Základný systém je statickou časťou KOGGE. Je možné ho rozdeliť do dvoch častí: interpretery a grafické moduly. Interpretery interpretujú popis nástroja a tak produkujú špecifický nástroj. Úlohou grafických modulov je znázorňovať nástroj a jeho komponenty. Grafické moduly poskytujú užívateľské rozhranie a knižnicu symbolov ako sú kruhy, štvorce a čiary. Internet JKOGGE Výrobca: Universität Koblenz-Landau JKogge je nástupcom nástroja KOGGE. Vyvinul sa na základe potreby integrácie CASE s internetom. Tri hlavné nové prvky JKogge sú (17): koncept distribuovaných grafov, idea spracovania grafov komponentami, ktoré sú realizované pomocou plug-inov, základný systém (base system) ktorý je celkom malý a zodpovedný len za nahrávanie dokumentov a komponent. 23

24 Obrázek 13 Jkogge base systém (17) Už KOGGE používal grafy za účelom skladovania popisu nástroja a dát produkovaných aplikáciou. V JKogge sú distribuované grafy, ktoré sa rozkladajú do niekoľkých fyzických grafov (subgrafov). Tieto subgrafy, spojené zdieľanými vrcholmi a spájajúcimi hranami, sa volajú dokumenty. Do systému sa nahrávajú podľa potreby počas behu, z akéhokoľvek miesta dostupného prostredníctvom URL. Komponenty sú nástroje vykonávajúce dobre definované úlohy alebo slúžia k spracovaniu dokumentov špecifického typu. V JKogge sú realizované ako plug-iny. Príkladom plug-inov sú editory, vizuálne komponenty pre GUI alebo grafické symboly, atď. Základný systém je zodpovedný za nahrávanie plug-inov a dokumentov. Dokumenty sa nahrávajú podľa požiadaviek, čo znamená že plug-in si ich musí explicitne vyžiadať. Základný systém funguje taktiež ako mediátor medzi plug-inmi. Umožňuje ich vzájomné prepojenie a komunikáciu. Internet Argo UML Argo UML je diagramová UML aplikace napsaná v jazyce Java. Protože se jedná o Java aplikaci, je k dispozici na všech platformách podporujících Javu. Aplikace je šířena pod 24

25 licencí open source Eclipse Public License. Argo UML zatím zcela kompletně neimplementoval standart UML. (18) V současnosti je aplikace dostupná ve verzi 0.32 a dokáže pracovat s jazyky C++, C#, Java, PHP 4, PHP 5, Python, Ruby, Ada, Delphi a SQL. Argo UML byl původně vytvořen na University of California v Irvinu Jasonem E.Robbinsem. Nyní se jedná o open source projekt hostovaný Tigris.org. Projekt Agro UML má v současné době přes 19,000 registrovaných uživatelů a kolem 150 developerů. (19) Internet Poslední aktualizace duben 2011 verze Cena Open-source 4.7. Concept Base ConceptBase.cc je multi-uživatelský deduktivní databázový systém. Jeho schopnost reprezentace informací na jakékoliv úrovni abstrakce (data, třída, metatřída, atd.) z něj utváří výkonný nástroj pro metamodelování a engeneering vlastních modelovacích jazyků. Nespornou výhodou tohoto nástroje je volná šiřitelnost pro nekomerční účely. (20) Využívá jazyka O-Telos, který v sobě slučuje výhody deduktivních a objektověorientovaných jazyků. Architektura ConceptBase podporuje jazyky C++, Java, TCL, Prolog a operační systémy Windows, Linux, Solaria,Mac OS-X. Concept base je postaven na architektuře klient server, využívající rodiny protokolů TCP/IP. (21) (22) Je vyvíjený katedrou profesora Dr. Matthias Jarke na univerzitě RWTH Aachen v Německu. (21) Internet Poslední aktualizace březen 2011 verze 7.3 Cena Pro komercní využití ceny na vyžádání, nekomercní využití zdarma 25

26 4.8. Coral Coral byl open-source softwarový projekt vyvíjený v CREST (Centre for Reliable Software Technology) při univerzite Abo Akademi ve Finsku. (21) Jednalo se o nezávislý metamodelovací nástroj, který lze použít pro vytváření a transformace nových modelů a modelovacích jazyků v reálném čase. Coral byl plnohodnotným metamodelovacím nástrojem. (21) (23) Bohužel tento projekt již nemá dalšího pokračování a veškeré uvedené linky z minulých prací jsou v současnosti nefunkční. Stejně tak se nám nepodařilo dopátrat žádných aktuálních informací přímo na stránkách Department of information technologies, Abo Akademi 3, kde jsme narazili pouze na další nefunkční odkaz. Poslední zmínka o tomto projektu pochází z roku GME Nástroj GME (The Generic Modeling Environment), který je volně dostupný ke stažení, byl vyvíjen na univerzitě Vanderbilt v Nashvillu USA. Jedná se o propracovaný nástroj zakotvený na konfigurovatelném modelovacím prostředí. Zmíněné konfigurovatelnosti je dosaženo pomocí metamodelů, které jednoznačně specifikují modelovací vzory (modelovací jazyky či modelovací metodologii) aplikační vrstvy. (21) (22) 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. (22) GME je snadno rozšířitelný. Externí komponenty mohou být psány v kterémkoliv jazyce podporujícím COM (C++, Visual Basic, C #, Python, atd.) GME podporuje více aspektů modelování. Poskytuje možnost skládání metamodelů pro opětovné použití existujících modelovacích jazyků a jazykových konceptů. (24) Internet Poslední aktualizace leden 2011 verze Cena Zdarma pro komerční i nekomerční využití

27 4.10. OpenSoul Metamodeler OpenSoul je metamodelovací nástroj vystavěný nad standardem MOF a postavený na MDR (Netbeans Metadata Repository) a JGraphu, programovaný v jazyce Java. Byl, a možná stále je, vyvíjen týmem studentů kolem profesora Řepy na VŠE v Praze. Bohužel jeho poslední dostupná Pre-Alpha verze 0.07 pochází z listopadu 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 a a vychází z podobných existujících nástrojů jako například MetaEdit+, ArgoUML a dalších. (22) (21) Internet %20Metamodeler/ Poslední aktualizace listopad 2005 verze Pre-Alpha 0.07 Cena Open-source MetaView MetaView je název projektu týmu složeného z výzkumné skupiny na katedře počítačové vědy na University of Alberta a členů oddělení počítačové vědy na University of Saskatchevan. Bohužel poslední aktualizace proběhla v roce Zastaralost je bohužel zásadním problémem, a pokud se projekt znovu nerozběhne je pro potřeby dnešní doby nepoužitelným. (25) MetaEdit+ Nástroj byl původně vyvinut na finské univerzitě Jyväskylä. V současnosti jej distribuuje firma Metacase. Je prezentován jako nejúspěšnější DSM software. MetaEdit+ může být využit jako klasický Case nástroj i jako meta-case nástroj. Je složen ze dvou dílčích editorů: MetaEdit+ Workbench a MetaEdit+ Modeler. Poskytuje multiuživatelskou a multiprojektovou podporu a běží na všech hlavních platformách. Je naprogramován nad objektově orientovanou databází. Součástí je i skriptový jazyk, s předdefinovanými výstupy ve formátu TXT, RTF, HTML, GIF, PCT. (26) (27)

28 Internet Poslední aktualizace srpen 2009 verze 4.5 Cena Pro komerční využití v rámci tisíců dolarů GEMS Cílem Generic Eclipse Modeling Systemu je překlenutí propasti mezi komunitami, které mají zkušenosti s metamodelovacími nástroji jako GME a těmi, které mají zkušenosti modelovacími technologiemi Eclipsu, jako je např. Eclipse Modeling Framework (EMF) a Graphical Modeling Framework (GMF). GEMS je vyvíjen na Vanderbiltské Univerzitě, konkrétně na institutu ISIS (Institute for Software Integrated Systems) ve spolupráci s dalšími společnostmi jako Siemens, IBM a PrismTech. Jedná se o opensource projekt. GEMS je nástrojem, který umožňuje vývojářům rychle a jednoduše propojit více Eclipse modelovacích technologií. Cílem GEMS je umožnit doménovým expertům, nejen Java/Eclipse vývojářům, vytvořit DSML, který bude využívat frameworků pro Eclipse, jakými jsou GMF a EMF, vytvářet složité analýzy, optimalizace a prostředky generování kódu. (28) Internet Poslední aktualizace červen 2008 verze 3.0 Cena Open-source

29 5. GME (Generic Modeling Environment) Nástroj Generic Modeling Environment GME byl vyvinut Institutem pro integrované softwarové systémy při Vanderbiltské univerzitě. Je to nástroj, který je velice dobře konfigurovatelný, a slouží k DSM modelování a k programové syntéze prostředí. Konfigurace se provádí prostřednictvím vložených metamodelů, které jsou určeny na Obrázek 44 - Logo GME aplikační sféře programu. Díky tomu lze využít modelovací vzory, ve kterých je obsaženo všechno syntaktické, sémantické a prezentační informace o dané sféře, které pojetí bude použito ke konstrukci modelů, jaké vztahy můžou být mezi nimi definovány, dále jak budou tyto koncepty zobrazeny a zorganizovány pro potřeby modelujícího pracovníka a také jaká jsou pravidla užívání při tvoření modelu. Prostřednictví modelového vzoru lze jasně vymezit, jaké typy modelů lze vytvořit dle výsledného modelovacího prostředí Licence a aktuální verze Program je poskytován zdarma jak pro komerční tak i nekomerční užití, stačí se jen registrovat, program stáhnout a užívat. Je zde jen omezení, že se daný program nemůže prodávat třetím stranám. Poslední verze nástroje byla publikována Velkou výhodou je rovněž volně přístupný zdrojový kód. Díky tomu lze nástroj optimálně upravit a co nejvíce si přizpůsobit vlastnímu užití Architektura GME má modulární architekturu tvořenou komponentami. Tyto komponenty jsou napsány většinou v C++ a jsou propojeny Microsoft technologií COM (Component Object Model), jež umožňuje komponentám vzájemně spolu komunikovat. Model architektury je vidět níže. 29

30 Obrázek 15- Architektura GME (25). Spodní část se nazývá úložná vrstva. Tato vrstva podporuje různé druhy úložných formátů, ovšem některé je třeba implementovat separátně, jak je to třeba u ODBC. Momentálně je u RepositoryStorage podporováno MS SQL Sever nebo MS Access. Pro FileStorage je třeba rychlý proprietární binární formát souborů. Jádro tvoří dva základní kameny Generic Modeling Environment Objekty (s danými atributy) a vztahy. Jádro nabízí služby jako operace s objekty například tvorba objektu, editování, distribuování při editaci se objekt uzamkne, nemůže dojít tedy ke kolizi. Komponenty GModel a GMeta využívají služeb jádra. Komponenta GMeta reprezentuje modelové vzory. Jedná se o pasivní část, která udává pravidla daného modelu omezení, pravidla konstrukce atd. Naopak GModel je interpret, který se řídí pravidly komponenty GMeta. Uživatel se dostává do styku hlavně s komponentami, které jsou na obrázku nejvýše. Jsou to komponenty GME Editor, Browser, Constraint Manager, Interpreter a Add-On. Komponenta Interpreteur (překladač) překládá informace zachycené v modelu a vytváří tak výstupy jako jsou například zdrojové kódy, konfigurační soubory Add-On umožňuje rozšířit možnosti nástroje. Zajímavou komponentou je Constraint Manager. Tato komponenta 30

31 totiž umožňuje ohýbat některá pravidla daného metamodelu. Díky tomu třeba při méně závažném porušení pravidla, pošle Constraint Manager jen varovnou hlášku Základní prvky v GME GME má čtyři základní prvky. Jsou to projekt, složka, model a atom. Projekt umožňuje uživateli lépe se orientovat mezi projekty, na kterých pracuje. Projekt obsahuje složku. Ta umožňuje v rámci projektu vytvářet složky, které pak můžou obsahovat různé modely. Model je pak skládán z atomů, případně dalších modelů, odkazů, spojení a setů. Atom je nejmenší nedělitelná entita, reprezentovaná ikonou. Může obsahovat nějaké vlastnosti, reprezentované atributy. Dále by měl obsahovat název a jednotlivé vztahy, ve kterých se vyskytuje s dalšími objekty. Pro modely v GME jsou definovány tyto zákonitosti: Model se skládá z částí Každá část má přiřazenou roli V modelu se vyskytují omezení, které určují, jaké role jsou dovoleny v dané části Modelující uživatel určuje dané instance a počet částí obsažené v daném modelu Díky předešlému vztahu lze vytvářet hierarchickou strukturu modelu Hloubka hierarchie je teoreticky neomezená díky tomu, že model může obsahovat stejný model Každý objekt v modelu musí mít právě jednoho rodiče, tento rodič musí být model Aspoň jeden model nemá rodiče a tento model nazývá root model (kořenový model) 31

32 Obrázek 16 - Prostředí GME (25) Vyjadřování vztahů v GME Spojení V GME se při určení nějakého vztahu mezi objekty užívá připojováním. Ty můžou být buď přímé nebo nepřímé. Tyto vztahy rovněž umožňují mít své vlastnosti, reprezentované atributy. Vztahy rovněž můžou být omezovány prostřednictvím restrikcí, například určením jejich multiplicity Odkazování 32

33 Odkazování se liší od spojení tím, že umožňuje ukázat na objekt, který není uvnitř daného modelu. Lze ho tedy chápat jako pointer v objektově orientovaných jazycích, který ukazuje na vzor daného objektu. Daný vzor může odkazovat na právě jeden objekt, ale objekt může být odkazován více odkazy. Když odkaz nikam nesměřuje, nazývá se nulovým Sestavování (Set) Spojování a odkazování jsou vztahy binární, ale sestavování, anglicky set, slouží k definování vztahů mezi více objekty, než jen dvěma. Jediným omezením je, že členové v setu musí mít stejného a viditelného rodiče Možnosti rozšíření GME Pro nástroj GME je jedním z hlavních úkolů možnosti integraci dalších řešení či různých rozšíření. To mu umožňuje i jeho multi-komponentní architektura. Další důvod proč je nástroj snadno, tak dobře rozšiřitelný je jeho poskytování jako open source s otevřeným zdrojovým kódem. Právě díky výše uvedené architektuře a volnému zdrojovému kódu lze prostřednictvím COM integrovat vlastní řešení. Primárními programovacími jazyky jsou C++ a Visual Basic, ovšem jazyky jako Java, Python a další jsou také podporovány. U GME se rovněž zdá být proveditelné on-line modelování díky transakčnímu zpracování a duálnímu přístupu k řízení. Proto třeba lze užívat GME UI, jako aplikaci získávající zpětnou vazbu k daným modelům. Duální řízení rovněž umožňuje převést data z novějšího modelu do starších modelů. Programování rozšíření je na úrovni komponent poměrně náročné neboť vyžaduje pokročilé řízení událostí a zpracování událostí. Právě proto je usnadněno jinými způsoby definice maker, C++ API. Samozřejmě je první způsob poměrně snadný, ale zase neumožňuje tolik možností naopak C++ API nabízí pro programátory daleko větší a lepší možnosti pro případná rozšíření GME MetaGME 33

34 Framework pro vytváření designu musí podporovat mnoho abstraktních modelovacích konceptů, které budou dostatečně obecné, aby bylo možné je použít i u jiných typů modelů. Tyto koncepty mohou využívat známé skutečnosti známé z dalších modelů jako například dědičnost, kompozice, agregace, hierarchie a definovat objektům či vztahům číselné nebo textové atributy. Vybrané koncepty lze pak upravit pro danou vrstvu a případně využít vícekrát v různých vrstvách. Na obrázku níže je vidět čtyřvrstvá architektura metamodelování v CDIF a UML specifikaci. Obrázek 17- Přechod z Metamodelu do Modelu (25). Na obrázku výše je vidět tzv. Meta-modelovací jazyk, který musí být dostatečně bohatý, aby bylo možné popsat různé vrstvy modelů. Zároveň tento jazyk popisuje sám sebe ve formě Meta-meta modelu. Tento jazyk dále specifikuje daný meta model a ten finálně meta model upřesňuje a a tím specifikuje daný model systémů. Na výše uvedeném obrázku je vidět zjednodušený model, u kterého je metamodelovacím jazykem UML, ve vrstvě modelu je pak vidět FSM Model odvozený od výše uvedeného modelu Omezení Metamodel slouží buď k úplnému specifikování modelu, nebo k přesnějšímu definování syntaxe daného modelu. V metamodelu se nemusí úplně popisovat sémantika 34

35 jazyka díky tomu, že užívá UML class diagram, který umožňuje určovat asociace a jejich kardinalitu. V případě, že by UML jazyk nestačil, nabízí se rozšíření UML - Object Constraint Language OCL, díky tomu lze třeba specifikovat nějaká další omezení Užívání Metamodelů Tak jako se jednotlivé modely používají u vícero různých aplikací, tak stejně tak by se měly meta modely přenášet z jedné vrstvy do druhé. Ideálně by knihovna meta modelů měla být přístupná všem důležitým vrstvám a tak umožnit danému modeláři, využít k rozšíření a následnému specifikování další vrstvy. Tyto další vrstvy lze pak opět využít bez toho, aby ovlivňovaly vzorový meta model. Díky tomu lze daný modelovací vzor si upravit podle svého lépe ho specifikovat, pochopit a třeba upravit pravidla, aby danému modelu vyhovovala, tyto specifikace pak můžou být použity jako základ nového modelovacího jazyka. Metamodelování v GME je založeno na UML diagramu tříd. Tento diagram však musel být upraven, kvůli například skládání metamodelů. Upraveno tedy bylo přidání nového vztahu ekvivalence a upravena byla dědičnost. Vztah ekvivalence byl přidán kvůli již už výše zmíněné možnosti spojovat více meta modelů do jednoho. Příkladem je vztah dvou tříd tyto třídy jsou v ekvivalenci, to znamená, že z těchto dvou tříd vznikne jedna, která obsahuje všechny atributy, kompozice a vztahů daných tříd. Dědičnost byla rozšířena o rozhraní dědičnosti. Rozhraní dědičnosti znamená, že dané dítě dědí od rodičovské třídy její vztahy, ale nedědí její interní věci, jako například atributy. Zůstala ale i klasická UML dědičnost, ve které se dědí všechno od vztahů až po vnitřní atributy. 35

36 Obrázek 18 - GUI GME s UML diagramem tříd (25). Obrázek ukazuje grafické uživatelské rozhraní. Na něm je vidět diagram s objekty. Ve stereotypech jsou specifikovány jednotlivé objekty Atom, Model, Connection, Folder Jsou tam rovněž znázorněny vztahy mezi objekty včetně dědičnosti. Vztahy rovněž obsahují kardinality a parciality (povinnosti) vztahů mezi objekty. GUI rovněž umožňuje více záložek a mezi těmito záložkami se také můžeme odkazovat Přídavné GME nástroje a utility 36

37 Zde je seznam možných přídavných nástrojů nebo utilit pro GME: Autolayout Rozšíření, které umožňuje pomocí algoritmu optimálně rozložit model v prostředí GME. Generative Modeling Framework Framework pro vytváření generativního modelování. GMEclipse Eclipse plugin pro zobrazování GME v prostředí Eclipse. Nelze však model v prostředí Eclipse upravovat. GReAT Graph Rewriting And Transformation. Metamodel na bázi grafické transformace jazyka. 37

38 6. Závěr Cílem této práce bylo nabídnout svému čtenáři základní úvod do oblasti nástrojů meta- CASE a to po stránce teoretické i praktické. V první části jsme popsali teoretické možnosti meta-case nástrojů a jejich výhody a způsoby užití, zatímco v části druhé jsme porovnali aktuální meta-case nástroje, které jsou dostupné na celosvětovém trhu. Jeden nástroj (GME) jsme prozkoumali zevrubně a věříme, že jsme dosáhli vytyčeného cíle. Jako zajímavost je v naší práci zmíněna případová studie firmy Nokia, kdy tato společnost využila metaedit+ pro modelování a vývoj softwarů pro svá mobilní zařízení. 38

39 7. Citovaná literatura 1. SEO expert services. SEO expert services. [Online] Zentner, Albert. [Online] 3. Jareš, Pavel. Meta CASE systém. Praha, Picka, Marek. METAMODELOVÁNÍ V PRAXI. [Online] [Citace: ] 5. Kelly, Steven. GOPRR Description. [Online] [Citace: 11. duben 2011.] 6. Tolvanen, Juha-Pekka. Metamodels and metamodeling languages. [Online] [Citace: ] 7. Meta-Object Facility. Wikipedia.org. [Online] [Citace: ] 8. Halpin, G. M. Nijssen and Terry. Conceptual Schema and Relational Database Design. Sydney : Prentice Hall, Tolvanen, Dr. Juha-Pekka. Domain-specific Modeling: Welcome to the Next Generation of Software Modeling. DevX.com. [Online] [Citace: ] Nokia Case Study. MetaCASE. [Online] MetaEdit+ revolutionized the way Nokia develops mobile phone software, [Citace: 17. březen 2011.] Actifsource. [Online] JetBrains::Meta Programming System. [Online] [Citace: ] Stoffel, Roman. Comparing Language Workbenches. Seminar: Program Analysis and Transformation. [Online] [Citace: ] pdf. 14. AToM3 A Tool for Multi-formalism and Meta-Modelling. [Online] Using AToM as a Meta-CASE Tool. Juan de Lara, Hans Vangheluwe. 16. Meta-CASE in Practice: A Case for KOGGE. Jurgen Ebert, Roger Suttenbach, Ingar Uhe. 39

40 17. Jurgen Ebert, Roger Suttenbach,Ingar Uhe. Meta-CASE Worldwide. [Online] [Citace: ] CollabNet. Tigris.org Known Incompatibilities. Tigris.org Open Source Software Engineering Tools. [Online] ISR. ISR Tech Transition. ISR Institute for Software Research. [Online] M.Jeusfeld. ConceptBase.cc - A Database System for Metamodeling and Method Engineering. ConceptBase.cc. [Online] Leden Jakub Laušman, Lukáš Kulhavý, Jiří Tománek. Nástroje meta-case. Praha, Petr Burian, Tomáš Gottwald, Jan Přikryl. Nástroje meta-case. Praha, István Balogh, Gabriel Jankó, Jozef Murín, Radim Žilka. Nástroje meta-case. Praha, ISIS. GME: Overview. GME: Generic modeling environment. [Online] Lab, Software Engineering. The Metaview Project. The Metaview Project. [Online] Listopad Kubal, Pavel, Vávra, Ondřej a Fischer, Roman. Nástroje meta-case (charakteristika, vývoj, přehled trhu, trendy). Praha, MetaCase. MetaEdit+ Domain-specific Modeling tools. [Online] MetaCase, About GEMS. Eclipse.org. [Online] Alderson, Albert. Meta-case technology. Springerlink.com. [Online] [Citace: ] 30. The Generic Modeling Environment. Institute for Software Integrated Systems. [Online] GME: Generic Modeling Environment. Institute for Software Integrated Systems. [Online] Molnár, Zoltán, Balasubramanian, Daniel a Lédeczi, Ákos. GME. DSM Forum. [Online] 40