Generování SQL ze specikace v UML a OCL. Jan Donátek. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta.

Transkript

1 ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta Bakalá ská práce Generování SQL ze specikace v UML a OCL Jan Donátek Vedoucí práce: Richta Karel Doc.Ing., CSc. Studijní program: Elektrotechnika a informatika, strukturovaný, Bakalá ský Obor: Výpo etní technika 24. kv tna 2011

2 iv

3 v Pod kování Touto cestou bych cht l pod kovat mému vedoucímu doc. Ing. Karlu Richtovi, CSc., který byl se mnou vºdy ochoten dannou problematiku konzultovat a byl vºdy k dispozici. Mé díky také pat í rodi m, kte í mi umoºnili proºít studium aº do te jako jednu velkou párty a vºdy m podporovali. Díky!!

4 vi

5 vii Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn a pouºil jsem pouze podklady uvedené v p iloºeném seznamu. Nemám závaºný d vod proti uºití tohoto ²kolního díla ve smyslu Ÿ60 Zákona. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm n n kterých zákon (autorský zákon). V A²i dne

6 viii

7 Abstract Programming trends are heading towards higher eectivity. For these purposes dierent kinds of code generators have been created. This way one can save a lot of time when managing projects and more importantly a programmer can concentrate on the scope. MDD (Model Driven Development) is going even further with it [8]. It tries to use the model itself for code generation. The model may be used for generating of a skeleton solution and data structure - Forward Engineering. By Reverse Engineering we can obtain documentation of a ready-made project. Nowadays, the most used tool for such documentation is UML (Unied Modeling Language). UML by itself is not capable of creating a full-edged model. In order to get such a model it is necessary to add descriptions of dierent integrity constraints. For this case UML has got an Object Constraint Language (OCL). However, there is no CASE tool nowadays that would be capable of generating these constraints to SQL. In this study I would like to demonstrate possibilities that one can use to construct SQL from an existing UML/OCL. Abstrakt Trendy v programování sm ují k vy²²í efektivit psaní kódu. Za tímto ú elem jsou vytvá- eny r zné generátory kódu. Tímto zp sobem se u²et í mnoho asu p i vytvá ení projekt a hlavn se programátor m ºe koncentrovat na problém samotný. MDD (Model Driven Development) jde v tomto sm ru je²t dále [8]. Snaºí se vyuºívat pro generování samotný model. Model m ºe být pouºit pro generování kostry e²ení a struktury dat, tzv. Forward Engineering. Reverzním inºenýrstvím m ºeme naopak získat dokumentace k hotovému projektu pro ix

8 x jeho snaº²í pochopení. Nejvíce vyuºívaným nástrojem sou astnosti pro vytvá ení takové dokumentace je standard UML (Unied Modeling Language). UML sám o sob je²t nevytvá í plnohodnotný model. Aby se tak stalo, je t eba doplnit modely o popisy r zných integritních omezení. Pro tento ú el obsahuje UML jazyk OCL (Object Constraint Language). V sou asné dob neexistuje ºádný CASE nástroj, který by um l spolehliv vygenerovat tato ingritní omezení do SQL. V této návrhové práci se budu zabývat moºnostmi, které lze pouºít ke konstrukci SQL z existujícího UML dopln ného o OCL.

9 Obsah 1 Úvod do modelem ízeného vývoje Motivace Modelem ízený vývoj UML a CASE nástroje Jazyk OCL Syntaxe OCL P evod OCL do SQL Základní p evody Kolekce Analýza moºností Enterprise Architect Add-ins Architektura addin Lad ní dopl k MDA transformace XMI Návrh e²ení Pouºitý programovací jazyk - Groovy Struktura knihovny Struktura exportovaného XMI z EA Nalezení cizích klí Contraints - Integritní omezení Atributy SQL parser Struktura tabulek P idání cizích klí Integritní omezení Podobné systémy Dresden OCL Jak Dresden OCL funguje Dal²í podobné systémy xi

10 xii OBSAH 6 Záv r 29 A Seznam pouºitých zkratek 33 B Instala ní a uºivatelská p íru ka 35 B.1 INSTALACE B.2 AKTIVACE V PROJEKTU B.3 UKÁZKOVÉ PROGRAMY C Obsah p iloºeného CD 37

11 Seznam obrázk 2.1 Doménový model Rela ní model po transformaci z doménového modelu Architektura Add-in v EA MDA transformace v EA Architektura návrhu e²ení R zné formy zápisu cizích klí C.1 Seznam p iloºeného CD xiii

12 xiv SEZNAM OBRÁZK

13 Seznam tabulek 2.1 UNIQUE PRIMARY KEY FOREIGN KEY CHECK xv

14 xvi SEZNAM TABULEK

15 Kapitola 1 Úvod do modelem ízeného vývoje 1.1 Motivace Pouºívání model p i vytvá ení komplexních systém je vyºadováno ve v²ech tradi ních in- ºenýrských disciplínách[9]. Nikdo by si dnes nep edstavil, ºe n jaký tým smontuje auto nebo postaví most aniº by nejd íve nesestavili specializované modely. Modely nám pomáhají porozum t sloºitosti problému a nalézt potencionální e²ení skrze abstrakci. A koliv je vyvíjení softwaru také jistou abstrakcí k reálnému systému, tato abstrakce m ºe být také zachycena modelem a vývojá i z n j mohou jen protovat. V²e samoz ejm musí být provád no v rozumné mí e. P edstavme si p ípad, kdy vyvíjíme produkt bez pouºití modelování [7]. Výhodou se m ºe zdát, ºe tímto postupem u²et íme as, který bychom v novali modelování. Neprovádíme ºádné aktivity, které by nevedly p ímo k tvorb produktu. Nevytvá ejí se ºádné vedlej²í produkty a artefakty, výsledkem je katalog poºadavk a kód. Hotový program se p edá rm. Problém nastává v okamºiku, kdy od zákazníka p ijde poºadavek na zm nu i p ídání nové funk nosti. Nová osoba nebo autor sám se musí znovu seznámit s kódem a to, co jsme u²et ili na za átku o to nyní p ijdeme. V opa ném p ípad by se analytik ke skute nému programování ani nedostal a tak by ani ºádný kód nevznikl. Zabýval by se pouze vytvá ením model. Ani jedna situace není optimální, ale jsou známé metodiky, které této absence modelování a vytvá ení dokumentace vyuºívají (ExtremeProgramming) a dokun ují projekty úsp ²n. Ty ale v budoucnu nemusejí nutn znamenat úsporu, vzhledem k tomu, jak se zlep²ují generátory kód z model. Zatím je na úváºení manaºera týmu, kdy jakou metodiku zvolit. Rozumným kompromisem je vytvo it jen takový model, který pom ºe p i analýze, návrhu, implementaci, testování a údrºb produktu, a který navíc z stane rm k dispozici pro dal²í zm ny. Pokud je model udrºován sou asn s produktem, m ºe takto poslouºit po celý jeho ºivotní cyklus. 1.2 Modelem ízený vývoj Modelem ízený vývoj (Model Driven Development), téº známý jako MDE (Model Driven Engineering) i MDA (Model Driven Architecture), vychází z Doménového modelu. Tento 1

16 2 KAPITOLA 1. ÚVOD DO MODELEM ÍZENÉHO VÝVOJE p ístup byl odstartován OMG (Object Management Group[14] 1 ) v roce OMG samotné implementaci neposkytuje. Vypisuje specikace a o implementaci samotnou se starají soukromé rmy nebo Open Source skupiny. Dle OMG [16] MDA je separována bussiness a aplika ní logika od cílové platformy. Jde tedy o PIM (Platfom Independent Model), model nezávislý na platform. Tyto platform nezávislé modely dokumentují funkcionalitu a chování aplikace nezávisle na specickém kódu. Pomocí transformací vytvo íme PSM (Platform Specic Model) daný PDM (Platform Denition Model). Tedy vytvo íme model ve specickém kódu i platform, nap C++, Java, DDL. Pokud se v tomto textu budu dále vyjad ovat o transformacích, bude my²lena transformace z PIM do PSM DDL (Data Denition Language), nap. MySQL. MDD je úzce spojována s dal²ími standardy jako Unied Modeling Language (UML), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC) a dal²í. S UML i XMI se v textu seznámíme podrobn ji pozd ji. 1.3 UML a CASE nástroje Unied Modeling Language ([4]) jak název napovídá je jazyk vytvo ený sjednocením n kolika grackých jazyk, které se pouºívaly v pr b hu 80. a 90. let minulého století. Jazyk UML za ali vyvíjet roku 1994[13] Grady Booch a Jim Rumbaugh z rmy Rational Software Corporation. Verze UML 1.0 byla ociáln spu²t na v roce 1997 [2]. Od té doby jej udrºuje skupina OMG. Jazyk UML je souhrn p edev²ím grackých notací k vyjád ení analytických a návrhových model. Pouºívá se k dorozumívání mezi programátory, jelikoº umoº uje modelovat aplikace pomocí stejné formální syntaxe. Celý model systému se skládá z n kolika logicky odd lených model. V mé práci budu dále pracovat s doménovým modelem. Velkým pomocníkem p i vývoji model jsou CASE (Computer Aided Software Engineering) nástroje. CASE nástroje jsou nástroje pro podporu analýzy a návrhu aplikací. V sou- astnosti v t²ina objektov orientovaných CASE nástroj vychází z UML. Mezi nejznám j²í pat í Enterprise Architect od SparxSystems a Visio od Microsft. Mezi freeware licencemi lze nalézt r zné pluginy nap. do Eclipse. Existují ale i mnohem sostikovan j²í nástroje neº je Visio a Enterprise Architect, jejich cena ale m ºe být aº desetinásobn vy²²í (Rational Rose od Rational, Select Component Architect od Select Business Solutions). 1.4 Jazyk OCL Aby byl model vyjád ený v UML úplný je t eba zapsat jej i s integritními omezeními. Integritní omezení se zapisují do sloºených závorek ({}). Lze je zapsat v p irozeném jazyce nebo formálním jazyce UML Object Constraint Language (OCL). [2] Pouºíváním OCL se vyhneme ²patným interpretacím zp sobeným nejednozna ností p irozeného jazyka. Nadruhou stranu podstupujeme riziko, ºe tená ani analytik nemusejí správn ovládat OCL. [7] Jazyk OCL pochází p vodn z metodiky Syntropy (IBM). Je to ist funkcionální jazyk - vyhodnocení výrazu je bez vedlej²ích efekt - neexistuje tedy ºádná globální pam. Stejná funkce se stejnými argumenty dává vºdy stejný výsledek. OCL není programovací jazyk, je to 1 Originál p ísp vek OMG jiº není funk ní.

17 1.4. JAZYK OCL 3 specika ní jazyk. Zápisy v OCL je t eba chápat jako specikaci pro programy, které budou odpovídající integritní omezení zaji² ovat. Pro je vlastn d leºité vytvo it generátor kódu pro p evod OCL do SQL, kdyº v dne²ní dob existují r zné techniky, které zajistí integritu dat? Integritu lze [3] zajistit uº p ímo v uºivatelském rozhraní nebo ji manuáln vloºit do aplika ní vrstvy nebo napsat SQL dotazy, které budou kontrolovat integritu v perzistentní vrstv. V²echny tyto p ístupy svou funkci spl ují, ale mají také spole nou nevýhodu. Není moºné u nich automaticky p enést omezení specikovaná v OCL z návrhu do implementace systému Syntaxe OCL Zápis v jazyce OCL má jednotný tvar[7]: context <jméno> [inv pre post] <název omezení>:<výraz> <název omezení> je volitelný. Jako odkaz na kontext pro <výraz> slouºí klí ové slovo context. Vezm me v úvahu nap. zápis: context Student inv:<výraz> ozna uje, ºe uvedený výraz se vztahuje na v²echny instance t ídy Student. Pokud chceme pracovat pouze s konkrétní instancí, pouºijeme klí ové slovo self. Klí ová slova inv, pre a post zastupují stereotypy: inv (invariant) - obecn platné tvrzení pre (precondition) - vstupní podmínky operace post (postcondition) - podmínka, která po vykonání operace M jme nap. zápis obecn platné tvrzení (invariantu): context Student inv: self.v k > 17 Tento zápis vyjad uje, ºe kaºdá instance t ídy Student, musí mít v k vy²²í 17 let. Studenty niº²ího v ku nelze v daném systému zaevidovat. Pro popis metody m ºeme pouºít zápis, kde nám vstupní podmínka nakazuje, ºe nelze zapsat p edm t s mén jak 3 kredity: context Student::zapi²PovinnýP edm t( po etkredit :Integer, název:string ) pre : po etkredit >= 3

18 4 KAPITOLA 1. ÚVOD DO MODELEM ÍZENÉHO VÝVOJE

19 Kapitola 2 P evod OCL do SQL Syntaxi jazyka SQL[8] m ºeme rozd lit do 5-ti kategorií. <SQL statement> ::= <QUERY> <DML> <DDL> <TCL> <DCL> Pro generování vyuºíváme p íkazy kategorie DDL (Data Denition Language). T mito p íkazy se vytvá ejí základní rela ní objekty. V tomto textu se budu zabývat pouze tabulkami, nebo práv tyto jsou generovány p i transformaci v EA z PIM do PSM-DDL. Hlavním problémem p i transformaci UML/OCL do SQL je nejednozna nost p evodu, r zný p ístup r zných analytik v návrhu a nedostate ná analýza sloºit j²ích situací (p evody kolekcí). Následující seznam problém 1 s kterými se m ºeme setkat p i p evodu vychází z [1]: Základní datové typy OCL (real, integer,...) jsou rovnou p evád ny do datových typ SQL. Mohou ale nastat problémy pokud takový datový typ neexistuje. To je t eba v SQL typ INTERVAL. I zdánliv jednoduché p evody t ída-tabulka mají svá úskalí. Existuje nekompatibilita mezi objekty a rela ními modely. Rela ní databáze jsou zaloºeny na p esném matematickém principu teorie mnoºin, kdeºto objekty vznikly empiricky, praxí. Integritní omezení v t²inou nebývají svázány pouze s jedním objektem, ale se skupinou objekt a vztah. Je sice moºné skrze r zné asociace v modelu dojít ke správným dotaz m, ty ale asto bývají velmi sloºité a výpo etn náro né. Auto i tohoto seznamu do²li ve své studii k zajímavému záv ru. UML roz²í ené o OCL omezení dokáºe vystihnout p esný konceptuální (doménový) model. Takové modely se v²ak v praxi pro generování kódu nepouºívají. EA a dal²í CASE nástroje dokáºí generovat rela ní schéma, ale omezení zapsaná do PSM modelu jsou dostupné jen na specické platform (SQL, Oracle,..). V XMI souboru, který EA generuje, lze snadno p istoupit jak k omezením zapsaným v konceptuálním modelu, tak k integritním omezením, které zapsal analytik v modelu PSM DDL. 1 Zabývám se pouze e²ením invariant, atribut z tabulek a kolekcemi. Dal²ími problémy jsou problémy s denováním pohled (Views) a konstrukty r zných poddotaz a sjednocení. 5

20 6 KAPITOLA 2. P EVOD OCL DO SQL K p evodu OCL do SQL lze pouºít 2 p ístupy: transformaci p es metamodely (metamodelbased transformation) a nebo transformaci denovanou vzorci (pattern-based transformation). Budu dále rozebírat jen druhou zmín nou, kterou pouºívám i v návrhu. P i p evád ní OCL/UML na SQL p evedeme t ídy na tabulky, atributy na sloupce, vztahy 1:N jsou vytvo eny pomocí primárních a cizích klí, vztahy M:N se realizují pomocí vztahové tabulky. Tyto transformace za nás vytvo í EA p i p echodu z doménového modelu do PSM DDL ( p ed transformací - 2.1, po transformaci - 2.2). Obrázek 2.1: Doménový model

21 7 Obrázek 2.2: Rela ní model po transformaci z doménového modelu Pokud jde o omezení samotné, lze pouºít 2 techniky p evodu. Pozm nit tabulku o omezení a vyuºít SQL constraint CHECK. OCL: context T inv IOT: <výraz>

22 8 KAPITOLA 2. P EVOD OCL DO SQL SQL: Uvaºme nap íklad integritní omezení: ALTER TABLE T ADD CONSTRAINT IOT CHECK ( SQL2OCL<výraz> ) context Student inv IO1: ( self.max_vek < 26 ); Které nahradíme v SQL dotazem: ALTER TABLE Student ADD CONSTRAINT IO1 CHECK ( max_vek < 26 ); Druhým zp sobem je vytvo it pohledy (VIEW), jeº ur í, která data nespl ují podmínky sémantické datové integrity. CREATE VIEW "IOT"AS ( SELECT * FROM "T"AS "T-alias" WHERE NOT ( SQL2OCL<výraz> ) ); Formáln jsou oba p ístupy správné, ale v praxi lze (alespo zatím) pouºít jen pohledy. Constraint CHECK v praxi nelze pouºít nebo se v n m v r zných implementacích SQL nep ipou²tí dotaz nad stejnou tabulkou. Norma ji v²ak p ipou²tí. 2.1 Základní p evody Richta se ve svém lánku [? ] v nuje tzv. okruºní jízd (round-trip). V kapitole "P evod SQL do UML/OCL"(tedy p evod z PSM do PIM) m ºeme nalézt základní transforma ní vzorce. Popí²i zde opa ný postup - z PIM do PSM. Funkci OCL isunique(), která se volá nad sloupcem vyjád íme v SQL jako integritní omezení UNIQUE. (tab. 1) OCL context T inv : self.<sloupec> -> isunique() SQL create table T ( <sloupec> <typ> UNIQUE ); Tabulka 2.1: UNIQUE

23 2.1. ZÁKLADNÍ P EVODY 9 Kombinace funkcí isunique() a isdened() denuje v SQL primární klí. OCL context T inv : self.<sloupec> -> isunique() and isdened() SQL create table T ( <sloupec> <typ> PRIMARY KEY ); Tabulka 2.2: PRIMARY KEY Z diagramu t íd pouºijeme vztah mezi tabulkou T a referencovaným objektem, který se jmenuje <FK> pro vyjád ení cizího klí e v SQL. OCL context T inv : self.<sloupec> -> exists( x:<tabulka> x.<nazev> = self. <FK> ) SQL create table T ( <sloupec> <typ> CONSTRAINT <FK> REFERENCES <nazev>(<tabulka>) ); Tabulka 2.3: FOREIGN KEY OCL funkce forall() se vyjád í v SQL jako integritní omezení CHECK. OCL context T inv : self.<sloupec> -> forall( x:t <výraz> ) SQL create table T ( <sloupec> <typ> CHECK(<výraz>) ); Tabulka 2.4: CHECK Pokud se omezení týká více typ, je nutné je vyjmenovat v prexu a explicitn denovat jména prom nných odpovídajících typ : context v1 : T1,..., vn : Tn inv: <výraz> Takovýto zápis není moºné rovnou p evést do SQL. Nejprve je t eba jej interpretovat jako posloupnost OCL p íkaz. Tento nový zápis nýám íká, ºe <výraz> platí pro v²echny instance v²ech odpovídajících typ. T1.allInstances->forAll(v1:T1.... Tn.allInstances->forAll(vn:Tn <výraz>)...)

24 10 KAPITOLA 2. P EVOD OCL DO SQL Nyní m ºeme jiº tato omezení transormovat na sadu dotaz v SQL, které zavád jí omezení pro v²echny zú astn né tabulky. ALTER TABLE T1 ADD CONSTRAINT IOT1 CHECK (OCL2SQL(<výraz>));. ALTER TABLE Tn ADD CONSTRAINT IOTn CHECK (OCL2SQL(<výraz>)); Výraz <výraz> je rela ní výraz s b ºnými rela ními operátory. Má tvar: <výraz><rela ní-operátor><výraz> Jeho p eklad bude: OCL2SQL(<výraz><rela ní-operátor><výraz>) = OCL2SQL(<výraz>)OCL2SQL(<rela ní-operátor>)ocl2sql(<výraz>) nebo OCL2SQL(<výraz><operátor><výraz>) = OCL2SQL(<výraz>)OCL2SQL(<operátor>)OCL2SQL(<výraz>) V SQL také existují unární operátory, které provád jí operaci pouze nad jedním výrazem jakéhokoli numerického datového typu. V SQL dialektech bývají nej ast ji implementovány tyto: Unární plus: numerická hodnota je pozitivní Unární minus: numerická hodnota je negativní logické NOT: Logické NOT provád né bit po bitu. Nemá ekvivalent v OCL. Výraz s unárním operátorem má v OCL tvar: <unární-operátor><výraz> Jeho p eklad potom bude: OCL2SQL(<unární-operátor><výraz>) = OCL2SQL(<unární-operátor>)OCL2SQL(<výraz>)

25 2.2. KOLEKCE Kolekce Jazyk OCL pracuje s kolekcemi a má denovánu sadu operací pro práci s takovými kolekcemi. Nap.test na prázdnost kolekce má operátor isempty(): OCL2SQL(<kolekce> -> isempty()) ::= (SELECT COUNT(*) FROM <kolekce>) = 0 Funkce size() vrací po et prvk mnoºiny: OCL2SQL(<kolekce> -> size()) ::= SELECT COUNT(*) FROM <kolekce> Pot ebujeme-li sekven n projít kolekci pouºijeme funkci iterate() [7] - nap.chceme-li se íst po et ú astník dle zadané podmínky. V OCL zápisu zastupuje prom nná v1 iterátor a v2 akumulátor. Nejprve se v2 nastaví na hodnotu výrazu <výraz1>. Poté se pro kaºdý prvek vyhodnotí výraz <výraz2>. P i sekven ním procházení kolekce je po adáí ur eno jen u uspo ádaných kolekcí. U neuspo ádaných je po adí náhodné. V SQL vzníkne výraz <výraz22> substitucí výrazu<výraz1> za v2 v <výraz2>: OCL2SQL(<kolekce> -> iterate(v1;v2=<výraz1> <výraz2>)) ::= SELECT v1 FROM (SELECT * FROM <kolekce> WHERE <výraz22>) Funkcí exists() ov íme, zda v dané kolekci existuje testovaný element: OCL2SQL(<kolekce> -> exists(v1 <výraz>)) ::= SELECT TRUE FROM <kolekce> WHERE EXISTS <výraz> Univerzálním kvantikátorem v OCL je forall(), kde výraz <výraz1> zastupuje n jakou podmínky, jeº musí v²echny prvky kolekce splnit: OCL2SQL(<kolekce> -> forall(v1 <výraz>)) ::= SELECT TRUE FROM <kolekce> WHERE NOT EXISTS NOT(<výraz>) Pro výb r prvk dle n jakého kritéria slouºí select(): OCL2SQL(<kolekce> -> select(v1 <výraz>)) ::= SELECT v1 FROM <kolekce> WHERE <výraz> Opakem select() je reject(), kterou "zavrhneme"necht né prvky. Kombinací t chto 2 funkcí m ºeme nap. vybrat studenty dle v ku z n jakého intervalu: OCL2SQL(<kolekce> -> reject(v1 <výraz>)) ::= SELECT v1 FROM <kolekce> WHERE NOT <výraz> Pokud chceme ov it, zda kolekce zahrnuje ur itý prvek, pouºijeme iselement(): OCL2SQL(<kolekce> ->iselement(v1 <výraz>)) ::= (SELECT COUNT(*) FROM <kolekce> WHERE <výraz> LIMIT 1) = 1

26 12 KAPITOLA 2. P EVOD OCL DO SQL

27 Kapitola 3 Analýza moºností 3.1 Enterprise Architect Tato kapitola je celá v nována tomuto CASE nástroji, který jsem si vybral pro jeho zna nou roz²í enost jako zástupce mezi CASE nástroji a také, protoºe je jeho licence na na²í fakult pro studenty voln k dispozici. Pro EA jsem nakonec vytvo il i návrh. 3.2 Add-ins Enterprise Architect (dále jen EA) poskytuje uºivatel m moºnost roz²i ování funk nosti pomocí add-in - v podstat jde o plugin. Add-iny jsou ActiveX COM objekty ([10]), které vyuºívají Automation Interface ke skriptování na Windows OLE. Napojit na Automation Interface se m ºe jakékoliv vývojové prost edí, které m ºe vytvá et ActiveX Com objekty. Lze tedy pouºít nap íklad Visual C# 2010 Express. K naprogramování zásuvného modulu lze mimo C# pouºít také Microsoft Visual Basic 6.0, Borland Delphi 7.0 a Javu Architektura addin Rozchození nového addinu není v EA zcela triviální, proto vysv tlím jejich architekturu (obr. 3.1, [12] ). Jakmile nastartujeme EA, za ne íst z registr na adrese HKEY_CURRENT_USER\ Software\SparxSystems\EAAddins. Kaºdý z klí v tomto umíst ní p edstavuje jeden zásuvný modul, který bude na ten do aplikace. Kaºdý klí se skládá z názvu add-inu a jeho t ídy odd lených te kou - MyAddin.MyAddinClass. EA se tedy dotáºe na umíst ní Addinu v COM databázi (COM codebase entries), který vrátí správný plugin. 13

28 14 KAPITOLA 3. ANALÝZA MOšNOSTÍ Obrázek 3.1: Architektura Add-in v EA Lad ní dopl k Hlavním problémem p i vyvíjení pluginu do EA je velmi ²patná podpora pro debugování 1 a testování samotné aplikace. To byl také hlavní d vod, pro jsem od tohoto zp sobu e²ení ustoupil. Dal²ím z d vod byla nedostate ná dokumentace. Nejv t²ím problém totiº p i vývoji pluginu iní, ºe jakmile objevíme bug nebo chceme doplnit novou funk nost, zkompilujeme projekt a vysko í chyba. Chyba vznikne, protoºe add-in pouºívá EA a nem ºe tedy být p epsán na²ím IDE. Takºe musíme zav ít EA, znovu zkompilovat celý projekt, opravit bug, nahodit EA a celý postup znovu opakovat. Tento cyklus má samoz ejm velký dopad na produktivitu. 3.3 MDA transformace MDA transformace [17] neboli Model Driven Architecture transformace velice p íspívají k produktivit. Jde v podstat o p evedení platform nezávislého modelu (PIM) do platform specického modelu (PSM) (3.2). 1 Menu a submenu lze debugovat i za b hu EA.

29 3.4. XMI 15 Obrázek 3.2: MDA transformace v EA Transformace jsou denovány ve skriptech psaných v template jazyce (template language). Bohuºel k t mto se mi nepoda ilo najít v bec ºádnou dokumentaci ani na internetu ani v dokumentaci k EA. A koliv tento zp sob by byl pravd podobn nejsnaº²í pro zpracovávání OCL do SQL. EA nabízí n kolik zabudovaných typ transformací: C#, datový model do ERD, DDL, EJB entity a n kolik dal²ích. Pro p evod z UML/OCL do SQL se pouºívá DDL (Data Denition Language) transformace, která transformuje platform nezávislé t ídy do platform specických tabulek. Bohuºel EA netransformuje v²echny vlastnosti element modelu. Jednou z takových vlastností jsou omezení (constraints). I pokud je v nov vytvo- eném modelu dodenujeme, generátor kódu 2 je ve výsledném kódu nezahrne (ani ve form komentá ). 3.4 XMI XMI je zkratka pro XML Metamodel Interchange. Jde o otev ený standard formátu soubor, který spravuje OMG a slouºí pro vým nu informací mezi modely a nástroji. Nejb ºn ji se vyuºívá pro UML modely. Poslední verze ISO je z ervence 2005 ([6]), XMI Tato verze v²ak není EA podporována. EA podporuje pouze verze 1.1, 1.2 a 2.1. Verze 1.* podporují pouze UML verze 1.3. Pro návrh jsem vybral XMI 2.1, který má podporu pro UML 2.0 a UML 2.1. XMI má p isp t ke snadnému exportu model z jednoho CASE nástroje do jiného. Bohuºel vým na diagram a pouºití univerzálního generátoru tém není moºná, kv li r zné implementaci spole ností, které s XMI pracují. 2 Generátor kódu se pouºívá k dal²ímu navý²ení produktivity. Existuje globální prom nná $constraint, z které by m lo být moºné p istoupit k obsahu omezení, ale je vºdy prázdná.

30 16 KAPITOLA 3. ANALÝZA MOšNOSTÍ

31 Kapitola 4 Návrh e²ení Jako nejlep²í návrh se nakonec, dle mého názoru jeví, pouºít pro generování z UML/OCL do SQL formát XMI. D vod je z ejmý. Export z XMI obsahuje údaje o v²ech modelech a v²ech jejich vlastnostech vytvo ených v rámci projektu a navíc je moºné, ºe v budoucnu se jednotlivý prodejci software sjednotí ve formátech XMI a bude moºné vytvo it obecné e²ení. Pro na²e ú ely budeme vyuºívat doménový model a model po transformaci na DDL. Pro správnou funkci je tedy nutné mít vytvo ený projekt v EA, který obsahuje minimáln tyto dva specické modely a exportovat celý projekt ve formátu XMI 2.1. Práce s EA XMI bohuºel není zcela pr hledná, jelikoº se asto objevují zcela identické t ídy li²ící se pouze v nic ne íkajícím id a také názvy atribut ne zcela vºdy korespondují s názvy v EA, ba asto jsou názvy zavád jící. 4.1 Pouºitý programovací jazyk - Groovy Programovací jazyk Groovy je vytvo en nad Java Virtual Machine. Kompiluje t ídy do Java bytekódu, takºe m ºe být pouºit kdekoliv spolu s Javou. Navíc bezproblému integruje v²echny existující Javovské t ídy a knihovny. Vysledná knihovna m ºe být tedy pouºita v Java projektu. Groovy jsem si vybral pro implentaci hlavn pro jeho velmi snadnou práci s XML soubory - XMI je vlastn soubor v XML formátu. P ístup k jednolivým uzl m a atribut m je v Groovy zcela triviální a lze tak i dob e sledovat strukturu XMI. Dále také pro jeho velkou p ehlednost v napsaném kódu. Velmi jsem vyuºíval jeho nativní podporu pro kolekce a hash-mapy. K urychlení práce a v t²í p ehlednosti kódu také velmi p ispivají "closures" ( eský ekvivalent mi není znám). 4.2 Struktura knihovny Hlavní t ídy pro zpracování p evodu jsou Xmi_processing.groovy, Table.groovy a MySqlParser.groovy (4.1). Table.groovy - je entitní t ída, která obsahuje v²echny informace nutné k vytvo ení struktury databáze v n jakém dialektu SQL. 17

32 18 KAPITOLA 4. NÁVRH E ENÍ Xmi_processing.groovy - vytahuje informace z exportu projektu v XMI. Ty ukládá v instancích Table. MySqlParser.groovy - Vytvo í z instancí Table soubor *.sql a ze statického atributu "[] constraints"(integritní omezení nejsou vºdy svázána pouze s jednou tabulkou, proto je kolekce statická) p idá za pomoci n jaké knihovny t etí strany pro p evod OCL do SQL integritní omezení. Obrázek 4.1: Architektura návrhu e²ení 4.3 Struktura exportovaného XMI z EA V komponent Xmi_processing.groovy pracuji s exportovaným XMI. T ída má denovány atributy, kterými p istupuji k jednotlivým logickým ástem dokumentu. Jejich lokaci popí²i v duchu Groovy, tedy uzel a jeho potomek jsou odd leni te kou a uzav en do <>. Atribut uzlu je název atributu>=<hodnota>". "xml"zna í root dokumentu. classes ::= <xml.extension.elements.element xmi:type=uml:class>

33 4.4. NALEZENÍ CIZÍCH KL̓ 19 sql_classes ::= classes && <classes.code gentype=sql 1 > ddl_classes ::= <xml.model.packagedelement.packagedelement.packagedelement.packagedelement name=ddl> && <xml.model.packagedelement.packagedelement.packagedelement.packagedelement. packagedelement xmi:type=uml:class> connectors ::= <xml.extension.connectors.connector> K tomu, aby bylo moºné vytvo it kompletní strukturu v SQL, je nutné dostat správná data z XMI. Proto nyní vysv tlím, v jaké ásti lze jednotlivé atributy tabulek, jejich vlastnosti a integritní omezení nalézt. N které vlastnosti lze nalézt na více umíst ních. Omezím se pouze na ty, pot ebné pro návrh. Uvedu "název atributu v Table"/ "Umíst ní v XMI".@"název atributu". Operace bude mít "název operace"/""umíst ní v XMI".@"název atributu". * zna í divokou kartu: název tabulky (table_name) / ddl_classes.@name id / ddl_classes.@xmi:id atributy (attrs) / sql_classes.attributes.attribute Základní vlastnosti atribut - datový typ, délka,... atributy (attrs) / ddl_classes.ownedattribute Dal²í vlastnosti a omezení atribut - NOT NULL, zda jde o derivovaný atribut,... cizí klí e (FK) / ddl_classes.@name=fk_* primární klí e (PK) / ddl_classes.@name=pk_* unikátní (UQ) / ddl_classes.@name=uq_* 4.4 Nalezení cizích klí Operace s kterými pracuji jsou typu FK, PK, UQ. Primární a unikátní klí e jsou jasn denovány p edponami "PK_"a "UQ_". V p ípad cizích klí se situace trochu komplikuje. Jediným ukazatelem "cizosti"není jen p edpona "FK_". Operace cizího klí e m ºe existovat i bez této p edpony. Není to zp sobeno pouze p ípadem, kdy by uºivatel p epsal generovaný kód. Tato situace m ºe nastat také pokud existuje vztah 1:N mezi 2 entitami, pak EA vygeneruje p i transformaci do PSM nové jméno sloºené z "FK_", "názvu zdrojové tabulky"a "názvu cílové tabulky". Pokud bychom navíc m li pojmenovanné asociace, p ejme operace cizího klí e práv toto jméno. Kv li této nejednotnosti jmen operací, je sloºité nalézt tabulky, kde se tento klí nachází jako primární. Na obrázku (4.2) lze jasn vid t n které varianty, které mohou nastat. 1 hodnota zde záleºí na vybraném dialektu SQL - MySql, Oracle SQL,...

34 20 KAPITOLA 4. NÁVRH E ENÍ Obrázek 4.2: R zné formy zápisu cizích klí Neprovedl jsem kompletní analýzu v²ech t chto p ípad, protoºe pro nalezení operace cizího klí e v dokumentu XMI jich není zapot ebí. M ºeme si v²imnout, ºe v diagramech není ºádný problém cizí klí e nalézt, a uº mají jakýkoliv název. Bohuºel, jejich itelnost v XMI jiº tak p ímo ará není. V XMI nalezneme v²echny operace i s jejich parametry a p i adíme je k jejich tabulce. Mnoºinovým rozdílem 2 odstraníme v²echny primární a unikátní klí e. Získáme tak pouze cizí klí e, ale je²t nám zbývá zjistit, vzhledem k jaké tabulce jsou tyto klí e cizí. Pak budeme porovnávat parametry operací FK s parametry operací PK. Existuje-li 2 Ten je v implementaci návrhu proveden p es ltrování p edpon.

35 4.5. CONTRAINTS - INTEGRITNÍ OMEZENÍ 21 shoda, nalezli jsme zdrojovou tabulku. Nutnou pro podmínkou pro funk nost této metody je, aby se parametry cizích i primárních klí jmenovaly stejn a zárove, aby neexistovaly 2 identické primární klí e. Tato podmínka je p i transformaci spln na. K nespln ní by mohlo dojít v p ípad, kdy uºivatel pojmenuje jinak názvy parametr cizího klí e. To ale z hlediska návrhu nemá ºádný smysl. 4.5 Contraints - Integritní omezení V EA lze zapisovat OCL do komentá a nebo do li²ty "constraints", kde nám ov í i správnou syntaxi OCL. Jak sem se jiº zmínil v úvodu textu, ani p i generování ani p i transformaci generátor kódu s "constraints"nepracuje. Pokud chceme generovat SQL kód, posta í pouze pouºít omezení zapsaná v PSM DDL. Pokud budeme chtít proces co nejvíce zautomatizovat, jeví se jako rozumné pouºít omezení zapsaná v konceptuálním modelu (PIM) a ne vytvá et pro kaºdou transformaci omezení nová. Proto v návrhu zpracovávám jak omezení zapsaná v doménovém modelu, tak v transformovaném DDL modelu. V t chto dvou modelech nalezneme 5 typ omezení - omezení zapsaná u t ídy, jejich atribut a konektor v diagramu t íd a u tabulek a konektor v DDL modelu. Chceme-li zpracovat údaje o omezeních pot ebujeme znát následující atributy - kontext (context), název omezení (pod kterým bude uveden VIEW i ALTER TABLE), typ (zda jde o OCL) a výraz. Zápis v jazyce OCL má vºdy jednotný tvar: [7] context <jméno> [inv pre post]: <výraz> Informace pro jednotlivé typy omezení jsou: Pro t ídy z "Class diagramu"a tabulky z "DDL"existuje stejná cesta a stejný atribut. Li²í se pouze v p i azeném id. umíst ní: xml/extension/elements/element(xmi:type="uml:class"name=název tabulky/t ídy>")/constraints/constraint(name) struktura: <constraint name=""type=""status=""weight=""description=""/> name - název omezení type - typ omezení; { Invariant Post-condition Pre-condition Process OCL }, pro nás je d leºité, aby byl typ nastaven na OCL status - { Approved Build Implemented Mandatory Proposed Validated } weight - je reálné íslo. Ur uje po adí v jakém jsou zobrazeny omezení v záloºce "constraints" description - výraz kontext: sql_classes(name) Pro atributy z "Class diagramu". umíst ní: xml/extension/elements/element(xmi:type="uml:class"name=název tabulky/t ídy>")/ struktura: <Constraint 3 name=""type=""notes=""/> 3 Zde jsem narazil na bug v nativní knohovn Groovy XmlSlurper. Neumí si poradit s uzly pojmenovanými na za átku velkým písmenem. Proto je v implementaci sice funkce pro nalezení omezení u atribut nakódována, ale není nikde pouºita, jelikoº hlásí chybu.

36 22 KAPITOLA 4. NÁVRH E ENÍ notes - výraz kontext: sql_classes(name) Pro konektory z "Class diagramu"i "DDL". umíst ní: connectors(xmi:idref)/constraints/constraint(name) struktura: <constraint name=""type=""description=" kontext: connectors/source/model(name) ; Jako kontext je pouºita zdrojová t ída/tabulka 4.6 Atributy Základní vlastnosti atribut získáme z umíst ní sql_classes/attributes/attribute/properties. EA v tomto uzlu generuje i jiné vlastnosti, ale pro mou práci nejsou d leºité. <properties type="" length="" precision="" scale=" type - SQL datový typ length - pouºívá se u datových typ CHAR, NCHAR, VARCHAR, NVARCHAR pro vyjád ení, kolik znak se má uloºit. Také se pouºívá pro FLOAT, kde ur uje po et bit v mantise. Hodnoty pro length pak jsou {1, 2,..., 53}. precision, scale - precision je po et digit v ísle. Scale je po et digit napravo od desetinné árky. Je ur en pro datové typy DECIMAL, DOUBLE, DOUBLE PRECISION, NUMERIC a REAL. Zbylé vlastnosti a omezení získáme z umíst ní ddl_classes/ownedattribute. V tomto uzlu lze nalézt n které zajímavé vlastnosti, jako nap íklad visibility (public, protected, private) i zda jde o derivovaný atribut. <ownedattribute name=""isunique=" name - název atributu isunique - nabývá hodnot { true false }. Název je dosti zavád jící. O ekával jsem, ºe ur uje unikátnost atributu (UNIQUE). Jde ale o omezení NOT NULL, pokud je atribut isunique nastaven na "false". 4.7 SQL parser P i vytvá ení parseru jsem se snaºil napodobit strukturu *.sql souboru jako ji vytvá í EA. Soubor lze tedy rozd lit do 3 ástí - vytvo ení struktury tabulky, p idání cizích klí a p idání omezení.

37 4.7. SQL PARSER Struktura tabulek V²echna data pot ebná pro vytvo ení struktury tabulek jsou uloºena v instancích Table.groovy. Struktura vypadá následovn : CREATE TABLE <název tabulky>( <atributy> PRIMARY KEY (<primární klí e), UNIQUE ( <unikátní atributy> ), KEY 4 ( <cizí klí e> ) ); P idání cizích klí Cizí klí e jsou denovány jako integritní omezení a p idány do tabulky aº po jejím vytvo ení. ALTER TABLE <název tabulky> ADD CONSTRAINT <název operace> FOREIGN KEY ( <parametr operace - alias primárního klí e zdrojové tabulky> ) REFERENCES <zdrojová tabulka> ( < primární klí zdrojové tabulky>); Integritní omezení Pro zápis integritních omezení jsem zvolil výraz CHECK. Sice ºádný poskytovatel databází s ním neumí pracovat nad více tabulkami, ale jde o prototyp generování SQL z OCL a formáln je CHECK zcela správn. Pro výraz z OCL do SQL je t eba pouºít knihovnu pro tento ú el ur enou. ALTER TABLE <kontext> ADD CONSTRAINT <název omezení> CHECK ( <výraz z OCL v SQL> ); 4 Jelikoº jsem unit testoval sql soubory vzhledem k sql vygenerovaným EA, zvolil jsem zp sob denování cizího klí e také p es ALTER TABLE. Nena²el jsem jaký má tento zp sob (ne)výhody. Jinak bych generoval cizí klí e rovnou v CREATE TABLE pomocí operace FOREIGN KEY.

38 24 KAPITOLA 4. NÁVRH E ENÍ

39 Kapitola 5 Podobné systémy 5.1 Dresden OCL Aplikací pro p evod OCL/UML do SQL není mnoho. V t²inou jde o pluginy, vyjime n o standalone aplikaci, ale nesetkal jsem se s ºádnou organizací, která by poskytovala samostatnou knihovnu a to ani v komer ní oblasti. Nejzajímav j²í je práce na²ich n meckých soused z univerzity v DrẠanech. Jde o projekt Dresden OCL [11]. Poslední stabilní verzí je Dresden OCL a podporuje OCL 2.2. Práce na projektu zapo ala jiº v roce Systém je udrºován p eváºn studenty a v dci ze Software Technology Group na Technické Univerzit DrẠany. Dresden OCL je zaloºen na Eclipse SDK a vydáván jako set plug-in pro Eclipse. Eclipse verze po krátkém otestování vypadá na slibný a robustní nástroj. Vydávájí také v distribuci samotnou Javovskou knihovnu. Není s ní nijak jednoduché pracovat a navíc je provázána s GUI a ani její chod není bezchybný. Naobranu v²ak musím dodat, ºe standalone verze jiº není déle udrºována Jak Dresden OCL funguje Hlavní rozdíl mezi mím návrhem a DrẠanským spo ívá v p ístupu k XMI. Abyste vygenerovali SQL soubor, je zapot ebí mít exportovaný model v XMI a samostatný soubor s omezeními v OCL *.ocl. Pokud tedy navrhneme model, musíme navíc zapsat dal²í soubor s omezeními. Omezení tak nemáme synchronizována s modelem. Pokud by existoval generátor OCL z UML integrovaný v daném analytickém prost edí, pak by toto zas aº takový problém nebyl. Ani EA od SparxSystems ani Rational Rose od IBM v²ak takovou funkci nepodporují. Pro samotné p evád ní omezení OCL invariant se pouºívají v SQL pohledy. Následující p íklad je uveden v dokumentaci tohoto produktu a má demonstrovat, jak se z jednoduchého OCL omezení vygeneruje velmi sloºitý SQL dotaz. Ten, jak jsem psal d íve, má samoz ejm dopad na výkon. Omezení context Student inv tudoclinv2: self.supervisor.grade.value > self.grade.value 25

40 26 KAPITOLA 5. PODOBNÉ SYSTÉMY je transformováno do SQL dotazu: CREATE OR REPLACE tudoclinv2 AS ( SELECT * FROM OV_Student AS ALIAS2 WHERE NOT ( ( ( SELECT value FROM OV_Grade AS foo WHERE PK_Grade IN ( SELECT FK_grade FROM OV_Person AS foo WHERE PK_Person IN ( SELECT FK_supervisor FROM OV_Student AS foo WHERE PK_Person = ALIAS2.PK_Person ) ) ) > ( SELECT value FROM OV_Grade AS foo WHERE PK_Grade IN( SELECT FK_grade FROM OV_Person AS foo WHERE PK_Person = ALIAS2.PK_Person ) ) ) ) ); 5.2 Dal²í podobné systémy Dal²ím zajímavým projektem v této oblasti se mohl stát compiler studenta Renata Miceliho [5], ke kterému neexistuje tém ºádná dokumentace (pouze v kódu a navíc v t²inou v ital²tin ). Podle code.google je v²ak jiº aktivita na projektu nulová. Poslední zaznamenaný commit je z Tipuji tuto práci na semestrální projekt, jelikoº stránka byla zaloºena v kv tnu spole n s prvními commity. To je pravd podobn také d vod ukon ení. Jedná se o kompilátor OCL do SQL také z XMI souboru. Projekt Octopus má domovskou stránku na [15]. Na stránce lze nalézt jen velmi málo informací, protoºe celý projekt je²t kompletn nemigrovali a p vodní web je jiº nefunk ní. Výjá ský tým, podle domény, pochází z Holandska. Octopus je plug-in pro Eclipse. Sice negeneruje kód v SQL, ale auto i se zam ili také na podoboný úkol - p evod z PIM do PSM

41 5.2. DAL Í PODOBNÉ SYSTÉMY 27 - p evod z UML/OCL do JAVA. Tento generátor tým vytvo il jako d kaz vize MDA, ºe "lze vytvo it aplikaci modelováním PIM a jeho následnou transformací do platform závislého modelu PSM". Zatím jde pouze o prototyp. Projekt byl naposledy updatován v roce 2006, takºe uº je pravd podobn také ukon en (by neociáln ). V ím, ºe existují i dal²í obdobné projekty, ty se mi v²ak nepoda ilo nalézt. Je vid t, ºe tato oblast MDD je teprve v za átcích.

42 28 KAPITOLA 5. PODOBNÉ SYSTÉMY

43 Kapitola 6 Záv r Mím úkolem bylo navrhnout moºnosti generování kódu ze specikace pomocí diagramu t íd UML v kombinaci s popisem OCL do SQL. B hem studia jsem asto slýchával pojmy jako je OCL a to m dovedlo k p edstav, ºe jde o beºný nástroj s kterým vývoja i b ºn pracují. ƒekal jsem, ºe naleznu v²ude plno dostupných materiálu a tutoriál, ve kterých bude jednodu²e vysv tleno, jak p evád t OCL do SQL. Skute nost je naprosto opa ná. O OCL se sice hodn mluví, ale konretní postupy zatím nejsou. Strávil jsem mnoho hodin studováním materiál a manual o transformacích a generování script pro v Enterprise Architect. Velmi m p ekvapilo, ºe SparxSystems nedali k dispozici dokumentaci. Je sice, ºe v manuálech jsou popsána 4 transforma ní makra, ale chybí mnoho v cí, na které lov k musí p ijít sám. Toto byl m j první pokus a zárove první slepá uli ka. Studiem add-in sem také nestrávil málo asu. Kdyº porovnám vývoj pluginu pro Enterprise Architect s vývojem pluginu pro Netbeans IDE, vyvíjet pro "Netbeany"je nesrovnateln jednodu²²í. Je k dispozici kompletní dokumentace, GUI builder, mnoºství tutoriál a alespo malá komunita programátor. Tak jsem se pokusil o dal²í e²ení, které nem lo konce. Cíl bakalá ské práce jsem splnil. Prozkoumal jsem r zné moºnosti. Jedinou smysluplnou se ukázalo zpracování XMI souboru. Takové projekty jiº sice existovaly, ale na trochu jiné bázi. Negenerují omezení p ímo z XMI, musí se jim dodat je²t samostatný soubor s omezeními. V ím, ºe jsem správn zdokumentoval ásti XMI d leºité pro zpracování OCL. Rád bych pokra oval v této práci, nap íklad jako téma pro diplomovou práci. Zam il bych se spí²e na univerzáln j²í generování neº jen pro Enterprise Architect. Byl bych rád, kdyby tento projekt z stal pouze jako knihovna s funkcemi pro zpracování XMI a generování OCL/UML do SQL, jelikoº takový produkt jsem nena²el. 29

44 30 KAPITOLA 6. ZÁV R

45 Literatura [1] ARMONAS, A. NEMURAITE, L. PATTERN BASED GENERATION OF FULL- FLEDGED RELATIONAL SCHEMAS FROM UML/OCL MODELS. INFORMATION TECHNOLOGY AND CONTROL. 2006, 35, 1, s [2] FOWLER, M. UML Distilled - Third Edition. Addison-Wesley [3] HEIDENREICH, F. WENDE, C. DEMUTH, B. A Framework for Generating Query Language Code from OCL Invariants. Electronic Communications of the EASST. 2008, 9, s [4] KANISOVá, H. MüLLER, M. UML srozumiteln. Computer Press, Brno [5] MICELI, R. ocl2sqlcompiler. stav ze [6] OMG. XML Metadata Interchange Specication, Version ISO/IEC 19503:2005(E) [7] RICHTA, K. Jazyk OCL a modelem ízený vývoj. Moderní databáze 2010, Nesuchyn, str [8] RICHTA, K. Rekonstrukce OCL z SQL. DATAKON 2010, Mikulov, ISBN: , str [9] SELIC, B. The Pragmatics of Model-Driven Development. IEEE SOFTWARE. 2003, 20, 5. [10] web:addins. Enterprise Architect Add-In Model. stav z [11] web:dresdenocl. Dresden OCL. stav z [12] web:rstaddin. Tutorial: Create your rst C-Sharp Enterprise Architect addin in 10 minutes. stav ze

46 32 LITERATURA [13] web:historyuml. History of UML. stav z [14] web:mddarchitecture. Model-driven architecture. stav z [15] web:octopus. Octopus: OCL Tool for Precise Uml Specications. stav z [16] web:omgmda. OMG Model Driven Architecture. stav z [17] web:transformace. MDA Transformations. stav ze!

47 P íloha A Seznam pouºitých zkratek MDD Model Driven Development MDA Model Driven Architecture MDE Model Driven Engineering OMG Object Management Group PIM Platform Independent Model PSM Platform Specic Model PDM Platform Denition Model DDL Data Denition Language XMI XML Metadata Interchange UML Unied Modeling Language CASE Computer Aided Software Engineering OCL Object Constraint Language EA Enterprise Architect 33

48 34 P ÍLOHA A. SEZNAM POUšITÝCH ZKRATEK

49 P íloha B Instala ní a uºivatelská p íru ka Knihovna na CD se nachází na nal-xmi-to-sql/dist. Soubor se jmenuje lib-xmi-to-sql.jar. B.1 INSTALACE P idání knihovny z terminálu: 1. javac -classpath.:/pathtojar/jarname.jar ClassName.java 2. java -classpath.:/pathtojar/jarname.jar ClassName P idání knihovny v Netbeans IDE: 1. V Netbeans klikneme na Tools/Libraries a vytvo íme novou knihovnu "New Library..." 2. Jako jméno knihovny uvedeme "xmi-to-sql" a zkontrolujeme, zda je typ nastaven na "Class Libraries". Formulá potvrdíme. 3. V ásti "Libraries" ozna íme na²í knihovnu, v záloºce "Classpath" klepneme na "Add JAR/Folder" a najdeme "lib-xmi-to-sql.jar". 4. Potvrdíme "OK" 5. Nyní vybereme n jaký Java/Groovy projekt a pravým tla ítkem my²i otev eme vlastnosti "Properties" 6. V ásti "Categories" vybereme "Libraries". 7. V záloºce "Compile" p idáme knihovnu kliknutím na "Add Library...", kde vybereme "xmi-to-sql" B.2 AKTIVACE V PROJEKTU Pouºití v Java/Groovy projektu: 1. Pro základní funk nost je nutné importovat následující balíky: import bak.xmi.to.sql.xmi.*; import bak.xmi.to.sql.parser.*; 35

50 36 P ÍLOHA B. INSTALAƒNÍ A UšIVATELSKÁ P ÍRUƒKA 2. Pro validaci xmi souboru se musí je²t doplnit: import bak.xmi.to.sql.file.validator.*; 3. Pro generování je nutné pouºít tuto deklaraci, kde nahradíme pouze prom nnou "xmipath" námi zvolenou cestou ke xmi souboru: Xmi_processing mp = new Xmi_processing( xmipath ); Parser parser = new MySqlParser( mp.createtables(), Table.constraints ); 4. Chceme-li si ov it, zda ze zadaného xmi souboru lze vygenerovat sql, p idáme je²t následující ádek: filevalidator2sql validator = new filevalidator2sql( xmipath ); B.3 UKÁZKOVÉ PROGRAMY Ob ukázky jsou jiº zkompilované knihovnou xmi-to-sql. Sta í je pouze spustit z p íkazové ádky z adresá e, kde se nachází.jar soubor p íkazem: java -jar název_ukazky.jar 1. Test knihovny v shell-aplikaci: test-xmi-to-sql/dist/test-xmi-to-sql.jar Tato aplikace p edpokládá, ºe v ko enovém adresá i CD bude existovat examples/student_predmet_zkouska.xmi. Výsledný sql soubor se uloºí do sloºky "examples". 2. Test knihovny v GUI prost edí: test-gui-xmi-to-sql/dist/test-gui-xmi-to-sql.jar V ko enovém adresá i CD existuje sloºka "examples", kde si lze ov it funk nost na 2 xmi souborech. Generované.sql se uloºí na Vámi vybranou pozici. Program funguje pouze pod Windows, jelikoº vyuºívá nativní prvky prost edí. Pozn.: Zdrojové soubory si lze prohlédnout ve sloºce projektu pod sloºkou "src"

51 P íloha C Obsah p iloºeného CD 37

52 38 P ÍLOHA C. OBSAH P ILOšENÉHO CD Obrázek C.1: Seznam p iloºeného CD