eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Bakalá°ská práce
Generování SQL ze speci kace 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
iv
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!!
vi
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 15. 5. 2010
.............................................................
viii
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 (Uni ed 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
x jeho snaº²í pochopení. Nejvíce vyuºívaným nástrojem sou£astnosti pro vytvá°ení takové dokumentace je standard UML (Uni ed 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.
Obsah 1
Úvod do modelem °ízeného vývoje
2
P°evod OCL do SQL
3
Analýza moºností
4
Návrh °e²ení
5
Podobné systémy
1.1 1.2 1.3 1.4
Motivace . . . . . . . . Modelem °ízený vývoj UML a CASE nástroje Jazyk OCL . . . . . . 1.4.1 Syntaxe OCL .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
1
1 1 2 2 3
5
2.1 Základní p°evody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 Kolekce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1 Enterprise Architect . . . . 3.2 Add-ins . . . . . . . . . . . 3.2.1 Architektura addin· 3.2.2 Lad¥ní dopl¬k· . . . 3.3 MDA transformace . . . . . 3.4 XMI . . . . . . . . . . . . . 4.1 4.2 4.3 4.4 4.5 4.6 4.7
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Pouºitý programovací jazyk - Groovy Struktura knihovny . . . . . . . . . . Struktura exportovaného XMI z EA Nalezení cizích klí£· . . . . . . . . . Contraints - Integritní omezení . . . Atributy . . . . . . . . . . . . . . . . SQL parser . . . . . . . . . . . . . . 4.7.1 Struktura tabulek . . . . . . . 4.7.2 P°idání cizích klí£· . . . . . . 4.7.3 Integritní omezení . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
13
13 13 13 14 14 15
17
17 17 18 19 21 22 22 23 23 23
25
5.1 Dresden OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1.1 Jak Dresden OCL funguje . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2 Dal²í podobné systémy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 xi
xii 6
OBSAH
Záv¥r
29
A Seznam pouºitých zkratek
33
B Instala£ní a uºivatelská p°íru£ka
35
C Obsah p°iloºeného CD
37
B.1 INSTALACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 B.2 AKTIVACE V PROJEKTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 B.3 UKÁZKOVÉ PROGRAMY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Seznam obrázk· 2.1 Doménový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Rela£ní model po transformaci z doménového modelu . . . . . . . . . . . . . .
6 7
3.1 Architektura Add-in v EA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 MDA transformace v EA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Architektura návrhu °e²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 R·zné formy zápisu cizích klí£· . . . . . . . . . . . . . . . . . . . . . . . . . . 20 C.1 Seznam p°iloºeného CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
xiii
xiv
SEZNAM OBRÁZK
Seznam tabulek 2.1 2.2 2.3 2.4
UNIQUE . . . . PRIMARY KEY FOREIGN KEY CHECK . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
xv
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
8 9 9 9
xvi
SEZNAM TABULEK
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 pro tovat. 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
2
KAPITOLA 1. ÚVOD DO MODELEM ÍZENÉHO VÝVOJE
p°ístup byl odstartován OMG (Object Management Group[14]1 ) v roce 2001. OMG samotné implementaci neposkytuje. Vypisuje speci kace 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 speci ckém kódu. Pomocí transformací vytvo°íme PSM (Platform Speci c Model) daný PDM (Platform De nition Model). Tedy vytvo°íme model ve speci cké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 De nition Language), nap°. MySQL. MDD je úzce spojována s dal²ími standardy jako Uni ed 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 Uni ed Modeling Language ([4]) jak název napovídá je jazyk vytvo°ený sjednocením n¥kolika gra cký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 o ciáln¥ spu²t¥na v roce 1997 [2]. Od té doby jej udrºuje skupina OMG. Jazyk UML je souhrn p°edev²ím gra cký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 so stikovan¥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í.
3
1.4. JAZYK OCL
speci ka£ní jazyk. Zápisy v OCL je t°eba chápat jako speci kaci 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í speci kovaná v OCL z návrhu do implementace systému. 1.4.1
Syntaxe OCL
Zápis v jazyce OCL má jednotný tvar[7]:
context <jméno> [inv|pre|post]
: je volitelný. Jako odkaz na kontext pro slouºí klí£ové slovo context. Vezm¥me v úvahu nap°. zápis:
context Student inv: 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
4
KAPITOLA 1. ÚVOD DO MODELEM ÍZENÉHO VÝVOJE
Kapitola 2
P°evod OCL do SQL Syntaxi jazyka SQL[8] m·ºeme rozd¥lit do 5-ti kategorií. <SQL statement> ::= | | | | Pro generování vyuºíváme p°íkazy kategorie DDL (Data De nition 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 speci cké 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. Zabývám se pouze °e²ením invariant·, atribut· z tabulek a kolekcemi. Dal²ími problémy jsou problémy s de nováním pohled· (Views) a konstrukty r·zných poddotaz· a sjednocení. 1
5
6
KAPITOLA 2. PEVOD OCL DO SQL
K p°evodu OCL do SQL lze pouºít 2 p°ístupy: transformaci p°es metamodely (metamodelbased transformation) a nebo transformaci de novanou 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
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:
8
KAPITOLA 2. PEVOD OCL DO SQL
SQL:
ALTER TABLE T ADD CONSTRAINT IOT CHECK ( SQL2OCL ) Uvaºme nap°íklad integritní omezení:
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 ) ); 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
SQL
context T inv : create table T ( self.<sloupec> -> isUnique() <sloupec> UNIQUE ); Tabulka 2.1: UNIQUE
9
2.1. ZÁKLADNÍ PEVODY
• Kombinace funkcí isUnique() a isDe ned() de nuje v SQL primární klí£. OCL
context T inv : self.<sloupec> -> isUnique() and isDe ned()
SQL
create table T ( <sloupec> PRIMARY KEY );
Tabulka 2.2: PRIMARY KEY • Z diagramu t°íd pouºijeme vztah mezi tabulkou T a referencovaným objektem, který
se jmenuje pro vyjád°ení cizího klí£e v SQL. OCL
context T inv : self.<sloupec> -> exists( x: | x. = self. )
SQL
create table T ( <sloupec> CONSTRAINT REFERENCES () );
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 | )
SQL
create table T ( <sloupec> CHECK() );
Tabulka 2.4: CHECK Pokud se omezení týká více typ·, je nutné je vyjmenovat v pre xu a explicitn¥ de novat jména prom¥nných odpovídajících typ·:
context v1 : T1, . . . , vn : Tn inv: 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 platí pro v²echny instance v²ech odpovídajících typ·.
T1.allInstances->forAll(v1:T1| ... .. . Tn.allInstances->forAll(vn:Tn|)...)
10
KAPITOLA 2. PEVOD 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()); .. . ALTER TABLE Tn ADD CONSTRAINT IOTn CHECK (OCL2SQL()); Výraz je rela£ní výraz s b¥ºnými rela£ními operátory. Má tvar:
Jeho p°eklad bude:
OCL2SQL() = OCL2SQL()OCL2SQL()OCL2SQL() nebo
OCL2SQL() = OCL2SQL()OCL2SQL()OCL2SQL() 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:
Jeho p°eklad potom bude:
OCL2SQL() = OCL2SQL()OCL2SQL()
2.2. KOLEKCE
11
2.2 Kolekce Jazyk OCL pracuje s kolekcemi a má de novánu sadu operací pro práci s takovými kolekcemi. Nap°.test na prázdnost kolekce má operátor isEmpty():
OCL2SQL( -> isEmpty()) ::= (SELECT COUNT(*) FROM ) = 0 Funkce size() vrací po£et prvk· mnoºiny:
OCL2SQL( -> size()) ::= SELECT COUNT(*) FROM 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 . Poté se pro kaºdý prvek vyhodnotí výraz . 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 substitucí výrazu za v2 v :
OCL2SQL( -> iterate(v1;v2=|)) ::= SELECT v1 FROM (SELECT * FROM WHERE ) Funkcí exists() ov¥°íme, zda v dané kolekci existuje testovaný element:
OCL2SQL( -> exists(v1|)) ::= SELECT TRUE FROM WHERE EXISTS Univerzálním kvanti kátorem v OCL je forAll(), kde výraz zastupuje n¥jakou podmínky, jeº musí v²echny prvky kolekce splnit:
OCL2SQL( -> forAll(v1|)) ::= SELECT TRUE FROM WHERE NOT EXISTS NOT() Pro výb¥r prvk· dle n¥jakého kritéria slouºí select():
OCL2SQL( -> select(v1|)) ::= SELECT v1 FROM WHERE 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( -> reject(v1|)) ::= SELECT v1 FROM WHERE NOT Pokud chceme ov¥°it, zda kolekce zahrnuje ur£itý prvek, pouºijeme isElement():
OCL2SQL( ->isElement(v1|)) ::= (SELECT COUNT(*) FROM WHERE LIMIT 1) = 1
12
KAPITOLA 2. PEVOD OCL DO SQL
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.
3.2.1
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
14
KAPITOLA 3. ANALÝZA MONOSTÍ
Obrázek 3.1: Architektura Add-in v EA
3.2.2
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¥ speci ckého modelu (PSM) (3.2). 1
Menu a submenu lze debugovat i za b¥hu EA.
15
3.4. XMI
Obrázek 3.2: MDA transformace v EA Transformace jsou de nová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 De nition Language) transformace, která transformuje platform¥ nezávislé t°ídy do platform¥ speci cký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 dode nujeme, generátor kódu2 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 2.0.1. 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í.
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á. 2
16
KAPITOLA 3. ANALÝZA MONOSTÍ
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 speci cké 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
18
KAPITOLA 4. NÁVRH EENÍ
• 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á de nová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>=". "xml"zna£í root dokumentu. • classes ::= <xml.Extension.elements.element xmi:type=uml:Class>
4.4. NALEZENÍ CIZÍCH KLÍ
19
• sql_classes ::= classes && • 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¥ de nová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, ...
20
KAPITOLA 4. NÁVRH EENÍ
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.
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]: 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: 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:
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.
22
KAPITOLA 4. NÁVRH EENÍ
notes - výraz kontext: sql_classes(name) • Pro konektory z "Class diagramu"i "DDL".
umíst¥ní: connectors(xmi:idref)/constraints/constraint(name) struktura:
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í.
23
4.7. SQL PARSER
4.7.1
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 ( PRIMARY KEY (<primární klí£e), UNIQUE ( ), KEY4 ( ) ); 4.7.2
P°idání cizích klí£·
Cizí klí£e jsou de novány jako integritní omezení a p°idány do tabulky aº po jejím vytvo°ení.
ALTER TABLE ADD CONSTRAINT FOREIGN KEY ( <parametr operace - alias primárního klí£e zdrojové tabulky> ) REFERENCES ( < primární klí£ zdrojové tabulky>); 4.7.3
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 ADD CONSTRAINT CHECK ( );
4 Jelikoº jsem unit testoval sql soubory vzhledem k sql vygenerovaným EA, zvolil jsem zp·sob de nová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.
24
KAPITOLA 4. NÁVRH EENÍ
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 3.1.0 a podporuje OCL 2.2. Práce na projektu zapo£ala jiº v roce 1999. 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. 5.1.1
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
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 1.7.2010. 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
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´ neo ciá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.
28
KAPITOLA 5. PODOBNÉ SYSTÉMY
Kapitola 6
Záv¥r Mím úkolem bylo navrhnout moºnosti generování kódu ze speci kace 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
30
KAPITOLA 6. ZÁV
R
Literatura [1] ARMONAS, A. NEMURAITE, L. PATTERN BASED GENERATION OF FULLFLEDGED RELATIONAL SCHEMAS FROM UML/OCL MODELS. INFORMATION TECHNOLOGY AND CONTROL. 2006, 35, 1, s. 2733. [2] FOWLER, M. UML Distilled - Third Edition. Addison-Wesley. 2003. [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. 110. [4] KANISOVá, H. MüLLER, M. UML srozumiteln¥. Computer Press, Brno. 2004. [5] MICELI, R. ocl2sqlcompiler.
http://code.google.com/p/ocl2sqlcompiler/, stav ze 1. 7. 2010.
[6] OMG. XML Metadata Interchange Speci cation, Version 2.0.1. 19503:2005(E). 2005.
ISO/IEC
[7] RICHTA, K. Jazyk OCL a modelem °ízený vývoj. Moderní databáze 2010, Nesuchyn¥, str. 1-23. 2010. [8] RICHTA, K. Rekonstrukce OCL z SQL. DATAKON 2010, Mikulov, ISBN: 978-807368-424-2, str. 71-80. [9] SELIC, B. The Pragmatics of Model-Driven Development. IEEE SOFTWARE. 2003, 20, 5. [10] web:addins. Enterprise Architect Add-In Model.
http://www.sparxsystems.com/uml_tool_guide/sdk_for_enterprise_architect/addins_2.htm,
stav z 15. 5. 2011.
[11] web:dresdenOCL. Dresden OCL.
http://www.dresden-ocl.org/index.php/DresdenOCL, stav z 18. 5. 2011.
[12] web: rstAddin. Tutorial: Create your rst C-Sharp Enterprise Architect addin in 10 minutes.
http://geertbellekens.wordpress.com/2011/01/29/tutorial-create-your-first-c-enterpris
stav ze 29. 1. 2011.
31
32
LITERATURA
[13] web:historyUML. History of UML.
http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/history_of_uml.htm,
stav z 23. 5. 2011.
[14] web:MDDArchitecture. Model-driven architecture.
http://en.wikipedia.org/wiki/Model-driven_architecture, stav z 26. 4. 2011.
[15] web:octopus. Octopus: OCL Tool for Precise Uml Speci cations. http://octopus.sourceforge.net/, stav z 23. 2. 2006. [16] web:OMGMDA. OMG Model Driven Architecture. http://www.omg.org/mda/, stav z 15. 12. 2010. [17] web:transformace. MDA Transformations.
http://www.sparxsystems.com/uml_tool_guide/mda_transformations/mdastyletransforms.htm,
stav ze !15. 5. 2011.
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 Speci c Model
PDM
Platform De nition Model
DDL
Data De nition Language
XMI
XML Metadata Interchange
UML
Uni ed Modeling Language
CASE OCL EA
Computer Aided Software Engineering
Object Constraint Language
Enterprise Architect
33
34
PÍLOHA A. SEZNAM POUITÝCH ZKRATEK
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
36
PÍLOHA B. INSTALANÍ A UIVATELSKÁ PÍRUKA
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"
P°íloha C
Obsah p°iloºeného CD
37
38
PÍLOHA C. OBSAH PILOENÉHO CD
Obrázek C.1: Seznam p°iloºeného CD
