ONTWIKKELING VAN EEN TOOL VOOR ONTOLOGIE-GESTUURDE BEDRIJFSMODELLERING

UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2007 – 2008

ONTWIKKELING VAN EEN TOOL VOOR ONTOLOGIE-GESTUURDE BEDRIJFSMODELLERING

Masterproef voorgedragen tot het bekomen van de graad van Master in de bedrijfseconomie

Tim Vermeiren onder leiding van Prof. dr. Geert Poels en Frederik Gailly

Woord vooraf Niets gaat vanzelf in het leven, en dat is ook voor deze masterproef het geval. Deze is enkel tot stand kunnen komen door de nodige inspanningen en denkwerk. Gelukkig stond ik er niet alleen voor, maar kreeg ik de hulp en steun van de mensen uit mijn omgeving. In de eerste plaats wil ik mijn begeleider, Frederik Gailly, bedanken. Hij heeft mij de weg gewezen naar vele nuttige papers en bijgestaan met raad en daad. De bijeenkomsten waren telkens weer een leerrijke gedachtenuitwisseling en gaven me de nodige motivatie om ertegenaan te gaan. Verder wil ik mijn ouders bedanken die het mij mogelijk maken dit bijkomend jaar te volgen. Ze hebben mij nooit in een bepaalde richting gedwongen, maar telkens de vrijheid en verantwoordelijkheid gegeven om mijzelf te ontplooien in de richting die ik het liefst wou en mij daarin gesteund. Ik hoop tenslotte dat u, als lezer, mijn werk zult weten te appreciëren en dat u na het lezen van deze masterproef een goed beeld zult hebben van het werk dat ik afgelopen jaar verricht heb.

i

Vertrouwelijkheidsclausule Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding.

Tim Vermeiren

ii

Inhoudsopgave Woord vooraf

i

Vertrouwelijkheidsclausule

ii

Inhoudsopgave

iii

Lijst van afkortingen

iv

Lijst van figuren

vi

1 Inleiding 1.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1 2

2 Bedrijfsmodellering 2.1 Over modellen en meta-modellen . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Het REA metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Een REA model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 3 5

3 De gebruikte frameworks 3.1 Eclipse . . . . . . . . . . . . . . . . 3.2 EMF . . . . . . . . . . . . . . . . . 3.2.1 Het ecore metamodel . . . . 3.2.2 Het generator model . . . . 3.2.3 Code generatie . . . . . . . 3.2.4 EMF.model . . . . . . . . . 3.2.5 EMF.edit . . . . . . . . . . 3.2.6 EMF.editor . . . . . . . . . 3.3 GEF . . . . . . . . . . . . . . . . . 3.4 GMF . . . . . . . . . . . . . . . . . 3.4.1 Domain Model . . . . . . . 3.4.2 Graphical Definition Model 3.4.3 Tooling Definition Model .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

iii

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

8 8 10 10 12 12 12 13 13 13 16 17 18 18

INHOUDSOPGAVE 3.4.4 3.4.5 4 De 4.1 4.2 4.3 4.4 4.5 4.6 4.7

iv

Mapping Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Code generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

REA editor Het Ecore metamodel . . . . . . . Het Graphical Definition Model . . Het Tooling Definition Model . . . Het Mapping Model . . . . . . . . Het exporteren van de REA editor Het installeren van de REA editor Het gebruik van de REA editor . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

5 Besluit 5.1 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Gebruikte frameworks . . . . . . . . . . . . . 5.1.2 Validering met de REA editor . . . . . . . . . 5.2 Naar de toekomst toe . . . . . . . . . . . . . . . . . 5.2.1 OCL . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 UML Profiles . . . . . . . . . . . . . . . . . . 5.2.3 Software ontwikkeling m.b.v. REA modellen 5.3 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . Lijst van geraadpleegde werken

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

19 20

. . . . . . .

22 22 26 27 27 29 30 32

. . . . . . . .

36 36 36 37 38 38 38 40 41 I

Lijst van afkortingen DBMS Database Managements Systeem: software die het mogelijk maakt om een database te beheren EMF Eclipse Modeling Framework: zie sectie 3.2 ER model Entity Relationship model: een schema dat aangemaakt wordt om een bepaalde database te modelleren ERP Enterprize Resource Planning: een systeem om binnen een bedrijf de planning van alle resources bij te houden. Dit kan gaan van voorraadbeheer over klantenbeheer tot een boekhoudprogramma. GEF Graphical Editing Framework: zie sectie 3.3 GMF Graphical Modeling Framework: zie sectie 3.4 GUI Graphical User Interface: de grafische gebruikersinterface MDA Model Driven Architecture: hiermee kan met automatisch programma’s genereren uit formele modellen. MDD Model Driven Development: ontwikkelen volgens de principes van MDA. MOF Meta Object Facility: dit is een OMG standaard voor modellering. Het MOF model bestaat uit vier verschillende niveau’s van modellen en metamodellen. (zie ook figuur 2.1) OCL Object Constraint Language: taal die het mogelijk maakt om beperkingen op te leggen aan een model OMG Object Management Group: een instantie die zich bezighoudt met de standaardisatie van –al dan niet computergerelateerde– modellen. PIM Platform Independent Model: een model gebruikt bij MDA dat onafhankelijk is van het gebruikte systeem. In EMF is ecore het PIM. (zie ook sectie 3.2.1) PSM Platform Specific Model: een model gebruikt bij MDA en dat wel systeem-specifieke informatie bevat. In EMF is het genmodel een PSM. (zie sectie 3.2.2)

v

INHOUDSOPGAVE

vi

RCP Rich Client Platform: het Eclipse platform samen met de strikt noodzakelijke plugins SOAP Simple Object Access Protocol: dit is een standaard waarmee XML boodschappen kunnen uitgewisseld worden tussen verschillende informatiesystemen. UML Unified Modeling Language: een standaard om een grafische weergave te maken van een object-georiënteerd informatiesysteem. XML eXtensible Markup Language: een formele taal om gegevens te gaan voorstellen zodat deze zowel door een programma als voor de mens leesbaar zijn.

Lijst van figuren 2.1 2.2 2.3

De hierarchie van metamodellen (Gailly) . . . . . . . . . . . . . . . . . . . . . Het REA metamodel (Gailly, 2007a) . . . . . . . . . . . . . . . . . . . . . . . Een voorbeeld van een REA model van een boekenwinkel (Gailly, 2007a) . . .

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9

Het Eclipse platform . . . . . . . . . . . . . . . . . . . . . . . De belangrijkste elementen van het ecore model (Bacvanski & Het EMF Framework . . . . . . . . . . . . . . . . . . . . . . . De GEF flow diagram editor . . . . . . . . . . . . . . . . . . . Het Graphical Editing Framework (GEF) (Hudson, 2006) . . De GEF shapes editor . . . . . . . . . . . . . . . . . . . . . . Het GMF Mindmap voorbeeld . . . . . . . . . . . . . . . . . De GMF Dashboard View in Eclipse . . . . . . . . . . . . . . De Eclipse Run Configuration . . . . . . . . . . . . . . . . . .

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11

De standaard EMF ecore editor . . . . . . . . . . . . . . . . . . . . Het EMF metamodel (links) en EMF model (rechts) van REA . . De grafische ecore editor . . . . . . . . . . . . . . . . . . . . . . . . Het REA metamodel in de grafische ecore editor . . . . . . . . . . Een vereenvoudigd Graphical Definition Model van de REA editor Het Tooling Definition Model en de palette . . . . . . . . . . . . . Een vereenvoudigd Mapping Model van de REA editor . . . . . . . Het REA Update Site Project . . . . . . . . . . . . . . . . . . . . . De installatie van de REA editor . . . . . . . . . . . . . . . . . . . De Preferences van de REA editor . . . . . . . . . . . . . . . . . . Het bookshop voorbeeld in de REA editor . . . . . . . . . . . . . .

5.1 5.2 5.3

. . . . . . . . .

9 10 11 14 14 15 17 18 20

. . . . . . . . . . .

23 23 24 25 26 27 28 29 31 32 34

Validatie van het boekenwinkel-voorbeeld . . . . . . . . . . . . . . . . . . . . De uitgebreide versie van het boekenwinkel-voorbeeld . . . . . . . . . . . . . Mogelijkheid om OCL constraints toe te voegen aan de REA editor . . . . . .

38 39 40

vii

. . . . . . . . Graff, 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 6 7

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

Hoofdstuk 1

Inleiding 1.1

Situering

Tegenwoordig moet er in het bedrijfsleven steeds meer informatie bijgehouden worden. Onder het motto “knowledge is power” wordt er in elk bedrijf zoveel mogelijk informatie opgeslagen over het klantenbestand, de voorraden, de leveranciers en dergelijke meer. Dit kan het verschil maken tussen een bedrijf dat snel kan inspelen op veranderingen in de omgeving en een bedrijf dat stilstaat en langzaamaan verdrongen wordt door de concurrentie. Om al deze informatie bij te houden bestaan er in het bedrijfsleven verschillende informatiesystemen. Deze systemen zullen de informatie op een systematische manier bijhouden. Bij het ontwerp van zo’n informatiesysteem is het belangrijk dat men op voorhand een goed afgebakend plan opstelt over welke informatie op welke manier opgeslagen dient te worden. Zo’n plan wordt dan in een model gegoten, dat opgesteld is volgens een bepaalde standaard, zodat iedereen (databaseontwerpers, managers...) dit plan kan lezen als hij de standaard begrijpt. Het REA metamodel is zo’n standaard en zal in deze masterproef nader bekeken worden.

1.2

Doelstellingen

In deze thesis zal het REA metamodel eerst omgezet worden naar een algemenere standaard, het ecore metamodel. Dit metamodel zal vervolgens gebruikt worden om een REA editor te implementeren die gebruikt kan worden om een REA model in aan te maken en te controleren of dit model voldoet aan de gebruikte REA standaard. Aangezien het hoofddoel van deze masterproef erin bestaat om een programma te schrijven, maakt dit programma zelf ook deel uit van het resultaat van de masterproef en kan het werk dat nu voor u ligt gezien worden als een verslag hiervan. Ik heb dan ook bewust ervoor gekozen om in deze masterproef ook de technische details uit te leggen, zodat deze kennis niet verloren gaat en anderen mijn werk kunnen verderzetten en de REA editor verder perfectioneren. Verder zou ik nog enkele notaties die in dit werk gebruikt worden willen verduidelijken. Wanneer een woord in het cursief geschreven staat gaat het om een Engelstalige term of om een naam van een instantie in het besproken model. Wanneer een woord in teletype geprint staat, is het een naam van een klasse uit het model (dat meestal afgebeeld staat) of een stukje 1

HOOFDSTUK 1. INLEIDING

2

programmacode.

1.3

Overzicht

Hieronder vindt u een overzicht van de verschillende hoofdstukken van deze masterproef en wat u hiervan mag verwachten. Hoofdstuk 2 zal een inleiding geven over bedrijfsmodellering en het REA metamodel. Dit is vooral bedoeld voor de externe lezer, zodat deze masterproef als een zelfstandig werk kan bekeken worden. Hoofdstuk 3 gaat over de frameworks die gebruikt zijn bij het ontwerpen van de REA editor. Dit is een zeer technisch hoofdstuk en dient om het volgende hoofdstuk in te leiden. Hoofdstuk 4 legt uit hoe de REA editor tot stand gekomen is en welke stappen nodig zijn om deze te implementeren, installeren en gebruiken. Hoofdstuk 5 besluit deze masterproef en zal een evaluatie geven op basis van mijn persoonlijke ervaringen en dit hoofdstuk zal mogelijke ontwikkelingen naar de toekomst toelichten om tenslotte mijn conclusie te formuleren.

Hoofdstuk 2

Bedrijfsmodellering Dit hoofdstuk zal de basis over modellering, en REA modellen in het bijzonder, uit de doeken doen. Het is vooral bedoeld voor lezers die nog niet vertrouwd zijn met deze problematiek.

2.1

Over modellen en meta-modellen

Er bestaan zeer veel verschillende soorten modellen om een afgebakend deel van de werkelijkheid, zoals bijvoorbeeld een bedrijf, te gaan modelleren. Hoe zo’n model opgebouwd dient te worden, wordt vastgelegd in een standaard, een metamodel. Hoe zo’n metamodel formeel gespecificeerd dient te worden, is op zijn beurt officieel vastgelegd door het OMG in een meta-metamodel, de Meta-Object Facility of kortweg MOF. Dit model is zelfverklarend, wat wil zeggen dat je het MOF kan specificeren door gebruik te maken van het MOF zelf. We bekomen dus een hiërarchie met vier niveau’s van (meta-)modellen, zoals ge¨ıllustreerd is in figuur 2.1. Het meest algemene niveau is niveau M3 met het MOF. Vervolgens bevat niveau M2 enkele bekende metamodellen, zoals het UML metamodel en het REA metamodel (dat in sectie 2.2 besproken wordt). Op niveau M1 vinden we dan de gewone modellen terug, dit kan bijvoorbeeld een UML domeinmodel zijn, een REA model of een OWL model. Tenslotte stelt niveau M0 de echte wereld voor die gemodelleerd wordt. We merken dus op dat elk niveau in de hiërarchie een instantie is van het bovenliggende niveau en de veralgemening is van het onderliggende niveau. In het vervolg van deze thesis zullen we vooral gebruik maken van het REA metamodel en het REA model dat we nu zullen bespreken.

2.2

Het REA metamodel

Een wijdverspreid metamodel om aan bedrijfsmodellering te gaan doen, is het REA metamodel. REA staat voor Resources, Events, Agents en deze drie entiteiten vormen dan ook de bouwstenen van het REA metamodel. Er bestaan evenwel een aantal verschillende varianten van het REA metamodel en in deze thesis zullen we kiezen voor het REA metamodel zoals in de paper van Gailly en Poels (2007a) besproken wordt. In figuur 2.2 zie je dit REA metamodel weergegeven. De bovenste helft van deze figuur bevat alle soorten types van elementen die de onderneming kan bevatten, dit wordt het Policy Level of Knowledge Level genoemd. De 3

« extends »

« instantiates »

REA OWL

REA UOP model

UML metamodel

REA UML REA Model REA Model Model

UML OWL profile (UOP)

Ontology Def. metamodel

MOF (ecore)

REA profile REA Model REA Model Model

UML REA profile

REA metamodel

M3

REA REA Model REA Model Model

M2

M1

M0

HOOFDSTUK 2. BEDRIJFSMODELLERING 4

Figuur 2.1: De hierarchie van metamodellen (Gailly)

HOOFDSTUK 2. BEDRIJFSMODELLERING

5

onderste helft bevat de eigenlijke REA elementen die op dat ogenblik aanwezig zijn of uitgevoerd worden en wordt de Operational Level genoemd. Links ziet u bijvoorbeeld de Economic Resource Type dat de middelen voorstelt waarover de onderneming (vroeger, nu of in de toekomst) kan beschikken. Via de typify relatie wordt verwezen naar alle Economic Resources die op dit moment in de onderneming aanwezig zijn. In het midden van het diagramma ziet u een Economic Event Type dat opgesplitst wordt in gebeurtenissen die een stijgende of een dalende invloed hebben op een bepaald soort resource. Rechts ziet u dan tenslotte de Economic Agent Type dat een soort entiteit verbonden met de onderneming voorstelt (zoals een klant-relatie) en deze kan getypeerd worden door een Economic Agent (bijvoorbeeld een welbepaalde klant). Tenslotte hebben we centraal in het REA metamodel de Commitments. Dit zijn verbintenissen van een bepaalde Economic Agent om een bepaalde Economic Event uit te voeren. Dit kan bijvoorbeeld de belofte van een klant zijn om na de ontvangst van de goederen te betalen. Nu zijn er –zoals in de paper van Gailly (2007a) ook aangebracht– een aantal beperkingen waaraan een REA metamodel moet voldoen, opdat het een geldig metamodel zou zijn. Deze kunnen samengevat worden in drie axioma’s: Het stockflow axioma: elke Economic Resource Type moet via een inflow en een outflow relatie verbonden zijn met minimaal één Increment Economic Event Type en één Decrement Economic Event Type. Het dualiteits axioma: elke Increment Economic Event Type moet via een dualiteitsrelatie gekoppeld zijn met één of meerdere Decrement Economic Event Types. Dit geldt wel enkel op het Knowledge Level, want een aankoop kan bijvoorbeeld op een later tijdstip betaald worden. Het participatie axioma: elke Economic Event moet minstens één provide en één receive relatie hebben met een Economic Agent.

2.3

Een REA model

Wanneer men in een bepaald bedrijf het REA metamodel gebruikt om de business van dat bedrijf te modelleren, krijgen we een REA model. In de paper van Gailly (2007a) wordt een verduidelijkend voorbeeld gegeven van een boekenwinkel, dat ik ook verder in deze masterproef zal gebruiken als illustratie. In figuur 2.3 wordt het REA model van dit voorbeeld getoond. Links ziet u terug de Economic Resources. De resource account is van het type accountType en van elke titel van een boek kunnen nul, één of meerdere kopies voorradig zijn. Vervolgens heb je een Decrement Economic Event sale dat het aantal boeken doet afnemen bij een verkoop. Deze worden geleverd door de boekenwinkel en ontvangen door de klant. Duaal hieraan is de Increment Economic Event payment dat het bedrag op de account doet stijgen. Hier ontvangt de boekenwinkel het geld dat door de klant gegeven wordt. De verbintenis van de klant om te betalen wordt door het Increment Commitment voorgesteld en de belofte van de winkel om de boeken te leveren zit vervat in het Decrement Commitment.


Figuur 2.2: Het REA metamodel (Gailly, 2007a)

6


Figuur 2.3: Een voorbeeld van een REA model van een boekenwinkel (Gailly, 2007a)

7

Hoofdstuk 3

De gebruikte frameworks Voor het bouwen van de REA editor, heb ik gebruik gemaakt van verschillende frameworks, zodat ik mij op de essentie kon concentreren en geen tijd verloor bij het bouwen van bijvoorbeeld een grafische gebruikersinterface. De gebruikte frameworks worden in de verschillende secties van dit hoofdstuk besproken. Het is belangrijk hier een goed beeld van te krijgen om het volgende hoofdstuk beter te begrijpen.

3.1

Eclipse1

Het belangrijkste onderliggende framework waar ik gebruik van gemaakt heb, is het Eclipse Platform. Figuur 3.1 toont waar Eclipse zich situeert tegenover de andere frameworks. Eclipse is een open source platform voor het bouwen van ontwikkelomgevingen. Eclipse is geschreven in Java en draait dus op de Java Virtual Machine. Dit heeft tot gevolg dat het op eender welk besturingssysteem kan draaien. Een voordeel waar de REA-editor ook onmiddellijk van zal profiteren. Indien u meer informatie wenst over hoe Eclipse precies gebruik maakt van de Java Virtual Machine, is “Eclipse - a tale of two VMs (and many classloaders)” (Blewitt) een zeer interessant artikel. Het Eclipse platform zelf bestaat eigenlijk vooral uit een gebruikersomgeving (de workbench en de GUI), die speciaal ontworpen is voor ontwikkelomgevingen en al een aantal standaardvoorzieningen aan boord heeft zoals een editor, een debug tool, ondersteuning om met meerderen aan een project te werken... Het Eclipse platform is zeer modulair opgebouwd d.m.v. plugins. Deze plugins voegen functionaliteit toe, maar kunnen zelf ook gebruikt worden door andere plugins. Zo ontstaat er dus een hierarchie van plugins. Eclipse is het meest bekend van de Java Development Tools (JDT), dit is een reeks plugins die je toelaten om Eclipse als Java ontwikkelomgeving te gebruiken. Bij wijze van illustratie is het JDT framework ook in figuur 3.1 getekend, maar verder wordt hier nauwelijks gebruik van gemaakt in deze masterproef. Frameworks die hier wel zeer belangrijk zijn, zijn EMF, GEF en GMF. Deze worden uitgebreid besproken in de volgende secties. Voorlopig volstaat het om in te zien dat dit 1

Zie ook op de Eclipse Project Site

8

HOOFDSTUK 3. DE GEBRUIKTE FRAMEWORKS

Figuur 3.1: Het Eclipse platform

9


10

Figuur 3.2: De belangrijkste elementen van het ecore model (Bacvanski & Graff, 2005)

eigenlijk gewoon Eclipse plugins zijn die gebruikt zullen worden door de REA-editor. De REA-editor is op zijn beurt ook een Eclipse plugin.

3.2

EMF2

EMF staat voor Eclipse Modeling Framework en stelt ons in staat om een (ecore) metamodel te definiëren en hieruit een Eclipse editor plugin te genereren. EMF kan dus gezien worden als een tool om te modelleren, maar ook als een tool om automatisch code te genereren. We kunnen met EMF dus aan Model Driven Development (MDD) doen. Een voordeel van EMF is ook dat zowel het ecore metamodel zelf als de instanties ervan (het bedrijfsmodel), persistent opgeslagen worden in het XML formaat. Zo wordt het ook gemakkelijk om nieuwe tools te schrijven die gebruik maken van een bestaand ecore model.

3.2.1

Het ecore metamodel

Het ecore metamodel is eigenlijk de kern van EMF. Het is een platform onafhankelijk model (PIM). Op figuur 3.2 zie je de belangrijkste elementen waaruit een ecore metamodel opgebouwd is. Een EClass stelt een bepaalde entiteit voor, die kan ge¨ınstantieerd worden en is dus te vergelijken met een Java klasse. In tegenstelling tot Java kan een EClass 0, 1 of meerdere supertypes hebben, meervoudige overerving wordt dus wel ondersteund. Een EClass kan ook een willekeurig aantal EReferences hebben naar andere EClasses. Een EReference kan 2

Zie ook de uitgebreide presentatie van EMF (Bacvanski & Graff, 2005)


11

user

UML Tool

XML Schema

Emfatic model

import

Java Interfaces

define

base

ecore model

generator model

generate

EMF.model

EMF.edit

EMF.editor

Figuur 3.3: Het EMF Framework

ook een tegengestelde relatie hebben. Voor elke EReference kan in het ecore metamodel een boven- en ondergrens opgelegd worden, deze kunnen ook onbegrensd zijn (waarde -1). Als bij een EReference de containment vlag op true staat, wil dit zeggen dat de EClass een container is voor deze EReference. Het is belangrijk om in te zien dat elke referentie (of zijn tegengestelde) ergens moet opgeslagen worden. Verder kan van een EReference ook een unique vlag op true gezet worden, die afdwingt dat elke element in een meervoudige relatie uniek moet zijn. Tenslotte kan elke EClass een aantal EAttributes hebben die van een bepaald EDataType zijn. Ook voor elk EAttribute kan een boven- en ondergrens opgelegd worden. Op figuur 3.3 zie je dat de gebruiker op drie manieren een ecore metamodel kan aanmaken. De eerste manier is door een bestaand metamodel te importeren. Dit kan gaan om een metamodel dat gemaakt is met een UML tool (zoals Rational Rose of EclipseUML), een bestaand XML schema of een emfatic model (dit is een metamodel dat geschreven is in een Java-achtige taal). Een tweede manier is om het ecore metamodel rechtstreeks te definiëren gebruik makende van de EMF plugin in Eclipse. De derde manier is om Java interfaces aan te maken met in elke interface een get-methode voor elk attribuut en annotaties om de cardinaliteiten te definiëren.


3.2.2

12

Het generator model

Uit het ecore metamodel kan men automatisch een generator model maken in EMF. Dit generator model is nodig om de code te genereren (zie volgende sectie). Het genmodel bevat de platform specifieke informatie en vult het ecore metamodel dus aan. Het genmodel stelt ons in staat om de wijze waarop de code gegenereerd zal worden te configureren. Zo kan men in het genmodel specificeren welke packages gebruikt dienen te worden, welke attributen gebruikt worden om een EClass weer te geven en kan men eventuele copyright informatie meegeven.

3.2.3

Code generatie

Eens het ecore metamodel en het genmodel aangemaakt is, kunnen hieruit drie Eclipse plugins gegenereerd worden, zoals aangegeven onderaan in figuur 3.3. Deze drie plugins werken samen om een editor aan te bieden waarmee instanties van het ecore metamodel kunnen aangemaakt worden. De EMF.editor plugin maakt gebruik van de EMF.edit plugin, die op zijn beurt gebruik maakt van de EMF.model plugin. Deze plugins worden hieronder verder beschreven. De gegenereerde plugins voorzien automatisch in de mogelijkheid om het model persistent te maken in XML. Zo kan elk aangemaakt model makkelijk opgeslagen en geopend worden. De gegenereerde code is natuurlijk zeer algemeen, want niet geschreven voor een specifiek domein. Daarom zal het vaak voorkomen dat deze code niet volstaat en manueel aangepast dient te worden. Het is natuurlijk best om de gegenereerde code grondig te testen om te weten te komen of het ecore metamodel correct is, vooraleer aanpassingen te doen aan de code. Toch is het mogelijk om na aanpassingen aan de gegenereerde code, het metamodel aan te passen en de code opnieuw te genereren. Men dient dan de @generated tag van de aangepaste methode te verwijderen en dan zal deze code niet overschreven worden door nieuwe gegenereerde code.

3.2.4

EMF.model

De EMF.model plugin bevat een gewone Java klasse voor elke EClass uit het ecore metamodel en dient dus om het metamodel intern bij te houden. Voor de EAttributes en EReferences worden automatisch get-methoden aangemaakt om de gegevens op te vragen uit het model. Voor elk element in het model is ook een toString methode die het element omzet naar een begrijpbare tekst, die weergegeven kan worden in de editor. Het kan vaak wel nuttig zijn om deze methode aan te passen, zodat bijvoorbeeld de naam van het element ook getoond wordt in de editor. Verder wordt aangeraden om zo weinig mogelijk aanpassingen te doen aan de EMF.model plugin. In de EMF.model plugin wordt gebruik gemaakt van het observer patroon. Dit is een veelgebruikte manier van programmeren om wijzigingen aan een centraal model bekend te maken bij verschillende weergave’s van dat model (observers of listeners genoemd). Iedereen die ge¨ınteresseerd is in wijzigingen aan het model kan zich registreren bij het model en zal gewaarschuwd worden wanneer er iets gewijzigd wordt. In het EMF.model wordt dit gebruikt


13

om alle voorstellingen van het model (de boomstructuur, het eigenschappen-venster...) te updaten als het model wijzigt.

3.2.5

EMF.edit

De EMF.edit plugin is de link tussen de gebruikersinterface en het bedrijfsmodel. Deze plugin bevat alle mogelijke commando’s die je op het model kunt toepassen, bijvoorbeeld het wijzigen van de naam van een element of het verwijderen van een connectie. Het is zeer waarschijnlijk dat aan de EMF.edit plugin manuele wijzigingen zullen moeten worden gedaan om bijvoorbeeld nieuwe commando’s te definiëren of om het label of icoontje van een EClass te veranderen.

3.2.6

EMF.editor

De EMF.editor plugin bevat dan weer alle code die nodig is om het model te gaan weergeven. Dit omvat dus de grafische gebruikersinterface (menu’s, wizards...) en bepaalt of het model in een boom- of lijststructuur weergegeven wordt. Wanneer je enkel het ecore metamodel wil testen volstaat de EMF.editor, maar meestal zal men grote aanpassingen willen doen aan deze editor of zelfs een volledig nieuwe plugin schrijven. Men kan ook gebruik maken van de GEF of GMF frameworks die hierna besproken worden.

3.3

GEF

Het Graphical Editing Framework (GEF) stelt ons in staat om makkelijk een grafische editor plugin te schrijven voor Eclipse. Dit kan gaan om een UML editor, een flow diagram editor (zie figuur 3.4), een eenvoudig vectorieël tekenprogramma, een WYSIWYG HTML editor, een editor voor database schema’s... Zonder GEF zou voor elk van deze editors veel werk opnieuw moeten gebeuren. GEF biedt standaard al heel wat functionaliteit aan, waar gebruik van gemaakt kan worden. Zo geeft GEF ondersteuning voor auto-routering van verbindingen tussen elementen, een gebruikersinterface (menu’s, acties, toolbars), undo-functionaliteit, een overzicht view, een eigenschappen balk, persistent opslaan van de grafische gegevens (posities van de elementen) in XML formaat, WYSIWYG tekst editors... Terwijl GEF instaat voor de grafische weergave, is het framework volledig onafhankelijk van het gebruikte metamodel. De gebruiker kan dus gerust zijn zelfgeschreven Java-klassen gebruiken om het metamodel voor te stellen en GEF gebruiken om de grafische editor plugin aan te maken. GEF maakt –net als EMF– gebruik van het observer patroon om wijzigingen aan het model te propageren en de grafische weergave te updaten. Voor elk element van het metamodel dat gemanipuleerd kan worden, dient een Edit Part gedefinieerd te worden. (zie figuur 3.5) De Edit Part is dan verantwoordelijk voor het updaten van de weergave van dit element. Meer informatie hierover vind je in de presentatie van (Hudson, 2006).


Figuur 3.4: De GEF flow diagram editor

Figuur 3.5: Het Graphical Editing Framework (GEF) (Hudson, 2006)

14


15

Figuur 3.6: De GEF shapes editor

Verder dienen in GEF ook commando’s gedefinieerd te worden voor elke mogelijke actie in de editor, zoals bijvoorbeeld het aanmaken of verwijderen van een element. De commando’s moeten een undo methode voorzien om het commando ongedaan te maken en een redo methode om ze nadien opnieuw uit te kunnen voeren. Deze commando’s kunnen dan aan acties gekoppeld worden die door de GUI uitgevoerd worden, zoals bijvoorbeeld het drukken op een knop in de toolbar of een bepaalde toetsencombinatie. Een meegeleverd voorbeeld van een GEF plugin zie je op figuur 3.6 en wordt uitgebreid beschreven in het Eclipse Corner Article van Majewski (2004). Dit eenvoudig voorbeeld toont zeer goed alle mogelijkheden die GEF standaard aanbiedt. Het is eigenlijk een eenvoudig tekenprogramma waarbij je twee vormen hebt (de rechthoek en de ellips) en je deze vormen kan verbinden met twee soorten connecties (volle lijn en stippellijn). De connecties vermijden botsingen met andere objecten. Op de figuur ziet u ook dat GEF gebruik maakt van de Properties View om alle eigenschappen van het geselecteerde element te tonen en wanneer je een eigenschap wijzigt zal dit onmiddellijk zichtbaar worden in de grafische editor. Omdat zowel EMF als GEF ondersteuning bieden voor commando’s en het observer patroon om wijzigingen te propageren, zijn deze zeer makkelijk samen te gebruiken. EMF wordt dan gebruikt om het onderliggende metamodel bij te houden en GEF wordt gebruikt voor de grafische voorstelling. In de paper van Chris Aniszczyk (2005) wordt beschreven hoe men


16

GEF en EMF aan elkaar kan koppelen en dit wordt uitgelegd aan de hand van de Shapes Editor.

3.4

GMF

Het Graphical Modeling Framework (GMF) is een zeer recent Eclipse project dat het veel eenvoudiger maakt om EMF te koppelen aan GEF. Je kan met GMF dus makkelijk een grafische editor genereren om een ecore metamodel te bewerken. Doordat het project nog zeer nieuw is, is er nog niet zo veel documentatie over beschikbaar. Er zijn voorlopig nog geen boeken over geschreven, maar de GMF Tutorial is een zeer goede online tutorial en er is ook de GMF Nieuwsgroep. In figuur 3.1 zag u reeds dat GMF gebouwd is bovenop EMF en GEF, zodat het alle mogelijkheden van EMF of GEF ook automatisch aanbiedt. Verder biedt GMF nog heel wat extra functionaliteit aan die het de plugin-ontwikkelaar veel makkelijker maakt en heel wat werk bespaart. Een uitgebreid overzicht van de GMF Runtime wordt beschreven in het Eclipse Corner Article van Plante (2006), hier houden we het bij een opsomming. De GMF omgeving voorziet standaard in de mogelijkheid om knoppen aan de toolbars toe te voegen, de labels van de model elementen direct te bewerken (eventueel zelfs met auto-completion), toevoegen van notities of tekst, elementen toevoegen m.b.v. context gevoelige pop-up bars, connection handles van een element gebruiken om een verbinding van of naar dit element te tekenen, gebruiken van de geanimeerde zoom, uitlijnen of automatisch schikken van de elementen, gebruiken van de Properties View met aparte tabbladen voor de grafische eigenschappen en de model eigenschappen, mogelijkheid om het diagramma te printen of te exporteren als afbeelding... In een editor die met GMF gegenereerd is, wordt het domein model strikt gescheiden gehouden van het diagram model. Het diagram model bevat alle grafische informatie (zoals de positie en de kleur). Voor elk diagramma in de GMF editor worden er twee bestanden aangemaakt: het domein model (extensie .modelnaam) en het diagram model (extensie .modelnaam diagram). Om in je gegeneerde GMF editor een domein model te bewerken, heb je beide bestanden nodig. Wanneer je reeds het bestand met het domein model bezit, maar nog geen diagram bestand, kan je dit aanmaken door in het snelmenu van het domein model de optie “Initialize diagram file” te kiezen. In figuur 3.7 zie je het GMF Mindmap voorbeeld dat je in staat stelt om een bepaalde gedachtengang visueel voor te stellen. In de palette rechts zie je eerst de standaard tools (de selectie, zoom en notitie tool), vervolgens de Topic tool om een nieuw onderwerp aan te maken en tenslotte de tool om een verbinding te tekenen die een Topic-Subtopics relatie voorstelt. Onderaan zie je de Properties View met een tabblad voor zowel de core als de appearance eigenschappen van het geselecteerde element. Eens de GMF plugin gedownload en ge¨ınstalleerd is vanaf de GMF Projectsite, kan je in Eclipse een nieuw GMF project aanmaken. Op het einde van deze wizard krijg je de mogelijkheid om direct het GMF Dashboard te tonen voor het nieuwe project. Deze view, die je in figuur 3.8 ziet, is een zeer krachtig hulpmiddel om je GMF project te beheren. Het


17

Figuur 3.7: Het GMF Mindmap voorbeeld

toont eigenlijk onmiddellijk de te ondernemen stappen om je eigen grafische editor plugin te creëren. GMF is eigenlijk een tool die werkt volgens de principes van Model Driven Architecture (MDA). Men kan er, vertrekkende vanuit een correct model, automatisch een programma mee genereren. GMF genereert grafische editors voor Eclipse. Wanneer je tevreden bent met de standaard mogelijkheden van GMF, hoef je dan ook niets in de programmacode te wijzigen. Het aanmaken van de modellen volstaat, maar dit moet uiteraard zeer zorgvuldig gebeuren. De verschillende modellen die nodig zijn om een editor te genereren met GMF, zie je in figuur 3.8 en worden in de volgende secties besproken.

3.4.1

Domain Model

De meest logische start bij het maken van een GMF editor is om met het Domain Model te beginnen. Dit is niets anders dan een ecore metamodel en dit metamodel kan je aanmaken net zoals dat in EMF gebeurt. Het GMF Dashboard voorziet knoppen om een bestaand ecore metamodel te selecteren, een nieuw ecore model aan te maken en om het gekozen metamodel te editeren. Dit zal het ecore metamodel openen in de EMF editor waar het ecore metamodel getoond wordt als een boomstructuur waaraan elementen toegevoegd of verwijderd kunnen worden en de eigenschappen van het geselecteerde element gewijzigd kunnen worden.


18

Figuur 3.8: De GMF Dashboard View in Eclipse

Vanuit het Domain Model kan men het genmodel automatisch laten afleiden. Dit is het genmodel zoals dat in sectie 3.2.2 besproken werd. Hieraan moeten normaal niet veel aanpassingen gebeuren, enkel de Base Package eigenschap van het root package kan best aangepast worden. Tenslotte kan je best in het snelmenu van het root package van het genmodel kiezen om de model code en de edit code te genereren, zoals dat ook voor een EMF project gebeurde.

3.4.2

Graphical Definition Model

Het Graphical Definition Model bevat alle grafische elementen (zoals rechthoeken, cirkels, verbindingen, pijlpunten, labels) die in het diagramma kunnen voorkomen. Vanuit het GMF Dashboard kan je ook het Graphical Definition Model automatisch gaan afleiden. De deriveknop zal een wizard openen die het root element van het diagramma vraagt en die vraagt uit welke elementen van het metamodel een node, een connection of een label aangemaakt dienen te worden. Dit automatisch gegenereerde Graphical Definition Model zal mogelijk wel nog aangepast moeten worden om de voorstelling te krijgen zoals je wilt. Zo kan het bijvoorbeeld zijn dat je bepaalde elementen een andere kleur, lijndikte of vorm wil geven of een extra label wil toevoegen aan een element.

3.4.3

Tooling Definition Model

Het Tooling Definition Model bevat alle items van de palette (alle elementen die aan het model toegevoegd kunnen worden), extra knoppen in de toolbar, menu items, pop-up menu’s, acties... Wanneer je het Tooling Definition Model automatisch laat afleiden via het Dashboard zal voor elke node of connectie automatisch een knop aan de palette toegevoegd worden. Voor


19

eenvoudige editors zal dit volstaan. Men zal dan hoogstens enkele kleine wijzigingen doorvoeren zoals het groeperen van verschillende tools in zogenaamde tool groups of de volgorde van de knoppen wijzigen. Wanneer men een uitgebreide grafische editor wil maken met GMF zal men in het Tooling Definition Model de mogelijkheid zien om een zeer uitgebreide GUI te maken met specifieke knoppen en pop-up menu’s.

3.4.4

Mapping Model

Het Mapping Model vormt de link tussen de drie vorige modellen en is dus noodzakelijk om te bepalen welk element uit het domein model door welke grafische elementen voorgesteld wordt en met welke tool het aangemaakt kan worden. In het GMF Dashboard kan met de Combine knop een wizard gestart worden om een standaard Mapping Model aan te maken. In deze wizard moet onder andere het root element van het diagram venster gekozen worden. Dit is het element dat het volledige diagramma voorstelt en dus verwijzingen bevat naar alle elementen die rechtstreeks aan een leeg diagramma toegevoegd kunnen worden. Het standaard gegenereerde Mapping Model zal zelden volstaan en er is meestal nog zeer veel werk nodig om de gewenste plugin te kunnen genereren. Een veelgemaakte aanpassing is het toevoegen van labels aan nodes en connecties. Zo kan men bijvoorbeeld in een UML editor labels toevoegen aan de klassen die de naam, stereotype, instantiatievariabelen, methodes of operaties voorstellen. Ook aan de referenties tussen klassen kan men dan labels toevoegen met de naam en de cardinaliteiten. Er bestaan verschillende soorten labels. Een feature based label is een label dat een attribuut van een EClass voorstelt en wordt dus opgeslagen in het model bestand. Dit label moet met een label mapping gekoppeld worden aan een bepaald attribuut zodat beide consistent blijven. Een design label is een label dat geen deel uitmaakt van het ecore metamodel, maar enkel ter verduidelijking van het diagramma dient. Het wordt dan ook in het diagram bestand opgeslagen. Een default label is dan weer een label dat niet door de gebruiker gewijzigd kan worden. Wanneer je bijvoorbeeld in elke klasse van een UML editor het woord “class” wil tonen, kan je hiervoor best een default label gebruiken. Dankzij het gebruik van een Mapping Model kan men in GMF een bepaald element uit het Graphical Definition Model gebruiken om meerdere elementen uit het Domain Model voor te stellen. Wanneer verschillende connecties er hetzelfde uitzien (bijvoorbeeld een gewone volle lijn met een pijlpunt aan één kant), kan men deze grafische voorstelling hergebruiken voor meerdere verbindingen. Een ander voordeel van de aparte modellen is dat men eenzelfde tool in de palette kan gebruiken om meerdere elementen aan te maken. Zo kan er één connection tool getoond worden om verschillende relaties tussen de elementen aan te maken. Wanneer twee elementen verbonden worden zal GMF zelf uitzoeken wat alle mogelijke relaties zijn die tussen deze twee elementen kunnen toegevoegd worden. Wanneer dit meerdere mogelijkheden oplevert, zal GMF een pop-up menu tonen met de keuze uit verschillende mogelijkheden.


20

Figuur 3.9: De Eclipse Run Configuration

3.4.5

Code generation

De laatste stap in ons GMF project is het genereren van de noodzakelijke code voor onze grafische editor plugin. Hiervoor zullen we in het GMF Dashboard eerst het Diagram Editor Gen Model aanmaken door op Transform te klikken. De optie RCP staat voor Rich Client Platform en stelt ons in staat om onze plugin te genereren zodat hij draait op een minimale Eclipse configuratie (met enkel de strikt noodzakelijke plugins). Wij zullen deze optie niet gebruiken, omdat dit foutmeldingen kan veroorzaken bij het heropenen van een editor. Het nu gegenereerde Diagram Editor Gen Model bevat een aantal opties voor het genereren van de editor, zoals de copyright tekst, de GUI acties, de tabbladen voor de Properties View... Hieraan zijn meestal geen aanpassingen nodig en kan je dus gerust laten voor wat het is. In de Dashboard View kan je nu “Generate diagram editor” kiezen om alle code voor je editor te genereren. Vergeet niet dat hiervoor de model code en edit code, die uit het genmodel gegenereerd zijn, noodzakelijk zijn. Eens dit gebeurd is, kan het automatisch aangemaakte .diagram project gestart worden. Hiervoor kan in de Eclipse Run Configuration best een nieuwe launch configuratie toegevoegd worden voor een Eclipse Applicatie. Belangrijk hierbij is dat op het plugins tabblad de juiste plugins geselecteerd worden, zoals getoond in figuur 3.9. Best selecteer je “Launch with: plug-ins selected below only”, deselecteer je alles, selecteer je de aangemaakte .diagram plugin en kies je “Add required Plug-ins”. Zo zal je een minimaal aantal plugins moeten starten en ben je zeker dat alle noodzakelijke plugins geladen zijn.


21

Wanneer je nu op Run klikt, zal een nieuwe Eclipse applicatie gestart worden met je zelfgegenereerde plugin. Nu kan je in een nieuw project een nieuw diagramma aanmaken (kies File → New → Examples...).

Hoofdstuk 4

De REA editor We zullen een grafische editor bouwen waarmee we een REA model kunnen editeren volgens het REA metamodel dat beschreven is in de paper Ontology-Driven Business Modelling: Improving the Conceptual Representation of the REA Ontology (Gailly, 2007a). In dit hoofdstuk worden de verschillende stappen overlopen die ondernomen zijn om tot de REA editor te komen.

4.1

Het Ecore metamodel

Zoals in sectie 3.2.1 beschreven kan men met EMF rechtstreeks een ecore metamodel aanmaken. Hiervoor kan men gebruik maken van de ecore editor die in EMF zit en die weergegeven is in figuur 4.1. Het ecore metamodel wordt dan weergegeven als een boomstructuur waaraan EClasses, EAttributes en EReferences kunnen toegevoegd worden. Van elk van deze elementen kunnen de eigenschappen dan ingesteld worden via de Properties View. Vervolgens zullen we uit het ecore metamodel het genmodel, de model code, de edit code en de editor code genereren. Wanneer we de gegenereerde editor starten kunnen we het model instantiëren zoals rechts op figuur 4.2 weergegeven. Hier werd het voorbeeld van de boekenwinkel gebruikt uit de paper van Gailly (2007a) als REA model. Er bestaat ondertussen ook al een grafische editor waarmee men een ecore metamodel kan aanmaken. Deze editor is zelf eigenlijk gebouwd met GMF. In figuur 4.3 zie je hoe het REA metamodel bewerkt wordt met deze editor. In de palette zie je alle mogelijke ecore elementen die aan het diagramma toegevoegd kunnen worden. Van het geselecteerde element (hier de inflow relatie) kunnen alle eigenschappen gewijzigd worden in de Properties View. De Outline View wordt ook gebruikt om een overzicht te geven van het diagramma. Meer informatie vindt u op de site van de Reflective Ecore Model Diagram Editor.

22

HOOFDSTUK 4. DE REA EDITOR

23

Figuur 4.1: De standaard EMF ecore editor

instantie

EMF metamodel Model

Figuur 4.2: Het EMF metamodel (links) en EMF model (rechts) van REA


Figuur 4.3: De grafische ecore editor

24


25

Figuur 4.4: Het REA metamodel in de grafische ecore editor

Het REA ecore metamodel ziet u in figuur 4.4. Helemaal bovenaan ziet u de REAModel EClass, die het volledige REA diagramma voorstelt. Het REAModel bevat een referentie naar alle klassen die rechtstreeks aan het model kunnen toegevoegd worden. Deze referentie is een zogenaamde containment reference , wat wil zeggen dat het REAModel als een container fungeert voor die andere klassen. Op het ecore diagramma is dit aangeduid met een ruit aan het begin van de verbinding en het komt overeen met een aggregatie relatie in UML. Aangezien het ecore metamodel geen overerving ondersteunt tussen EReferences, moeten we voor de StockflowType, Stockflow en Participation relatie aparte EClassen voorzien. Dit heeft als bijkomend voordeel dat we namen kunnen geven aan deze relaties, die in onze REA editor als een label zichtbaar zullen zijn. De Stockflow klassen en de Participation klassen zitten niet rechtstreeks in het REAModel, omdat ze verbindingen voorstellen in de REA editor. Zij worden bijgehouden door een klasse die ernaar verwijst via een containment relatie. Het is dus belangrijk dat elke EClass in het metamodel vanuit het root element, REAModel, bereikbaar is via containment relaties. M.a.w. elke EClass moet via één of meerdere containment relaties met het REAModel verbonden zijn. Wanneer dit niet het geval is, geeft dit de foutmelding “Phantom nodes that


26

Figuur 4.5: Een vereenvoudigd Graphical Definition Model van de REA editor

are not targeted by a link mapping exist” in het .gmfmap bestand.

4.2

Het Graphical Definition Model

Het automatisch gegenereerde Graphical Definition Model voldeed niet voor de REA editor, dus heb ik een volledig nieuw Graphical Definition Model aangemaakt dat voldoet aan de noden van de REA editor. De verschillende elementen van het Graphical Definition Model worden in figuur 4.5 getoond en worden hierna overlopen. Het Canvas Reamodel is het root element van het .gmfgraph bestand en bevat alle grafische elementen die in het diagram kunnen voorkomen, namelijk de Figure Gallery, de Nodes, de Connections en de Diagram Labels. De Figure Gallery bevat alle figuren die gebruikt kunnen worden als node of connectie. De Polyline Decoration is eigenlijk gewoon de opmaak van een pijlpunt. Een figure Descriptor bevat alle figuren die een node of een connectie voorstellen. In de eerste figure Descriptor van figuur 4.5 is dit een rechthoek die twee labels bevat, waarvan één label met de Child Access gelinkt is aan de naam van de resource in het model. De tweede figure Descriptor bevat een gewone lijn. Het Node element in het Graphical Definition Model verwijst naar een figuur uit de Figure Gallery en kan in het Mapping Model gebruikt worden om op een EClass te mappen. Ook een Connection verwijst naar een figuur uit de Figure Gallery en kan in het Mapping Model gebruikt worden om een EReference voor te stellen. Een Diagram Label tenslotte verwijst naar een bepaald label in de Figure Gallery en


27

Figuur 4.6: Het Tooling Definition Model en de palette

kan ook een verwijzing hebben naar een Child Access object om het aan een EAttribute van het onderliggende ecore model te koppelen.

4.3

Het Tooling Definition Model

Het Tooling Definition Model bevat alle GUI elementen van de Eclipse Workbench (die dus niet in het diagram zelf voorkomen). Bij de REA editor zullen we dit model enkel gebruiken om de palette van de nodige tools te voorzien om alle elementen van het REA model te kunnen aanmaken. In figuur 4.6 is links het Tooling Definition Model weergegeven en rechts het resultaat van de palette zoals hij in de REA editor weergegeven zal worden. In het .gmftool bestand zien we dat aan de palette drie Tool Groups zijn toegevoegd. De Policy Nodes groep bevat alle elementen van het Policy Level. De Operational Nodes groep bevat de nodes van het Operational Level. De Connections groep tenslotte bevat één Connection die gebruikt kan worden om eender welke connectie te tekenen. GMF zal dan zelf de gewenste relatie aanmaken.

4.4

Het Mapping Model

Ook bij het Mapping Model heb ik alle elementen manueel toegevoegd om ervoor te zorgen dat voor elk element uit het ecore metamodel het juiste grafische element gebruikt wordt en dat het met de juiste tool aangemaakt kan worden. In figuur 4.7 zie je de drie belangrijkste elementen van het Mapping Model, namelijk de Top Node Reference, de Link Mapping en de Canvas Mapping. De Canvas Mapping bepaald welke EClass uit het ecore metamodel het volledige diagramma voorstelt, dit wordt ook wel het root element genoemd.


28

Figuur 4.7: Een vereenvoudigd Mapping Model van de REA editor

De Top Node Reference moet bereikbaar zijn vanuit het root element en met zijn property Containment Feature kan gekozen worden welke relatie van het root element deze node voorstelt. De Node Mapping van een Top Node Reference bepaalt de mapping tussen de EClass uit het ecore metamodel, de node uit het Graphical Definition Model en de tool om dit element aan te maken. Dit kan nog een Feature Label Mapping bevatten die een bepaald Diagram Label uit het Graphical Definition Model zal mappen op een bepaald EAttribute uit het ecore metamodel. In dit voorbeeld wordt de Label Mapping gebruikt om een label te tonen met de naam van een Economic Resource in de REA Editor. De Link Mapping zal de mapping verzorgen voor de Connection elementen uit het Graphical Definition Model. Er zijn echter twee soorten Link Mappings. De eerste soort zal een Connection mappen op een EReference van het ecore metamodel, terwijl de tweede soort een Connection zal mappen op een EClass van het ecore metamodel. De laatste soort heeft het voordeel dat je aan de relatie zelf nog eigenschappen kunt toewijzen in het model, zoals bijvoorbeeld een naam voor een participation relatie in een REA model. Voor de REA editor worden beide Link Mappings gebruikt. De eerste soort Link Mappings is te herkennen aan de Element property die gezet is om naar de juiste EClass te verwijzen die de connectie voorstelt. Het bevat ook de Containment Feature property, dit is de containment relatie van het element dat naar deze EClass verwijst. Om even een voorbeeld te geven: zoals je kan zien in figuur 4.4 heeft de Decrement Economic Event klasse een containment relatie (herkenbaar aan het ruitje) met de Outflow klasse, die een verwijzing heeft naar de Economic Resource. Dit wil zeggen dat de Decrement Economic Event klasse de Outflow klasse bevat. Deze Outflow klasse stelt eigenlijk een relatie voor tussen de Decrement Economic Event klasse en de Economic Resource klasse en zal als een pijl worden voorgesteld in de REA editor. In figuur 4.7 zie je bij de properties van de Link Mapping (rechts) dat de Containment Feature ingesteld is op de outflow relatie, dit is de relatie van de Decrement Economic Event klasse naar de Outflow klasse die je ook op figuur 4.4 terugvindt.


29

Figuur 4.8: Het REA Update Site Project

4.5

Het exporteren van de REA editor

Nadat we alle stappen van het GMF Dashboard doorlopen hebben en alle code gegenereerd is zoals in 3.4 uitgelegd, kunnen we onze REA editor lokaal uittesten. Wanneer we de REA editor publiek willen maken of op andere systemen willen installeren, moeten we de REA editor exporteren. Nu kan ook nog een eventuele copyright tekst ingevuld worden in het .genmodel en het .gmfgen bestand en kan de naam van de plugin, de provider en het versienummer in de plugin.xml bestanden ingevuld worden. Om de REA editor publiek te maken moeten we eerst een Feature Project aanmaken (File → New → Other... → Plug-in Development → Feature Project). In de volgende wizard moeten de nodige projecten geselecteerd worden, dus zowel het model, edit als diagram project. Vervolgens kunnen we een Update Site Project aanmaken op analoge wijze. Als je het site.xml bestand opent van het Update Site Project kan je categorieën aanmaken en hieraan het hierboven aangemaakte feature project toevoegen zoals weergegeven in figuur 4.8. Als men vervolgens op Build All klikt in het Update Site Project, zal er in dit project een features en plugins map aangemaakt worden met de benodigde .jar bestanden om onze REA editor te exporteren. Deze bestanden dienen dan (samen met het site.xml bestand) online geplaatst te worden zodat men een volwaardige update server heeft voor de REA editor.


4.6

30

Het installeren van de REA editor

Vooraleer je de REA editor installeert, moet je controleren of je de juiste versie van Eclipse bezit en de juiste versies van de nodige plugins ge¨ınstalleerd zijn. Het is aan te raden om een nieuwe Eclipse installatie aan te maken, zodat er zeker geen fouten sluipen in de installatie. Dit is de aangeraden configuratie om de REA editor te installeren: Eclipse 3.4.0 (M6 or later) EMF 2.4.0 GEF 3.4.0 GMF 2.0.1 Ga eerst naar de downloadpagina van Eclipse1 en download er versie 3.4M6 of ouder. Unzip deze in een nieuwe folder en start de Eclipse installatie. Nu ga je naar Help → Software Updates... → Available Software en voeg de standaard Eclipse update site toe, voor de Ganymede versie is dit: http://download.eclipse.org/releases/ganymede/ Van deze update site installeer je volgende projecten: Models and Model Development -> Eclipse Modeling Framework (EMF) Enabling Features -> Object Constraint Language (OCL) 2.0 Graphical Editor and Frameworks -> Graphical Editing Framework (GEF) Models and Model Development -> Graphical Modeling Framework SDK Om de REA editor te installeren ga je in Eclipse terug naar Help → Software Updates... → Available Software. In dit venster moet u een nieuwe Remote Site aanmaken met de URL van de REA Update Server. Op het ogenblik van dit schrijven kan u daarvoor volgende site gebruiken: http://www.timvermeiren.be/rea/ Selecteer de REA Editor Feature van deze update site zoals u ziet in figuur 4.9 en klik op Install.... Als je nu de wizard verder volgt zou de REA editor goed ge¨ınstalleerd moeten zijn. Dit kan je controleren door in Window → Preferences te kijken of er een categorie REAmodel Diagram in de lijst voorkomt. Als dit niet het geval is, zal je mogelijk nog andere benodigde projecten moeten installeren. Na het opstarten van Eclipse zal je dan vermoedelijk in de Error Log een lijst krijgen van foutmeldingen met de benodigde dependencies die nog ontbreken. De foutmelding is dan van de volgende vorm: Unsatisfied dependency: [...] requiredCapability: org.eclipse.equinox.p2.iu/xyz/[1.0.0,2.0.0]. Negeer de verwijzing naar equinox, dit is de update manager van Eclipse, maar probeer de plugin te vinden en installeren die het package xyz bevat. 1

http://download.eclipse.org/eclipse/downloads/


Figuur 4.9: De installatie van de REA editor

31


32

Figuur 4.10: De Preferences van de REA editor

4.7

Het gebruik van de REA editor

Eens de editor ge¨ınstalleerd is, kan je een nieuw REA model aanmaken via File → New → Example... → REAmodel diagram. Deze wizard zal twee bestanden aanmaken: een .reamodel bestand, dat het REA model zelf opslaat, en een .reamodel diagram bestand, om de posities van de elementen en andere grafische informatie in op te slaan. Eens de wizard doorlopen is, krijg je normaalgezien een lege diagram editor te zien met rechts de palette met de REA model elementen. Wanneer de Properties View nog niet geopend is, is het best om deze te openen via Window → Show View → Other... → General → Properties. Als je nu in het lege diagram klikt (en hiermee eigenlijk de canvas selecteert), krijg je in de Properties View de eigenschappen van het REA model element te zien. In het Core tabblad kan je enkel een beschrijving opgeven, maar je krijgt ook een Rulers & Grid tabblad te zien. Ik raad aan om de Snap to grid optie uit te zetten, want wanneer het rooster iets te groot ingesteld staat, wordt het quasi onmogelijk om de elementen nog te kunnen positioneren zoals je wil. Je kan deze standaardinstellingen ook globaal wijzigen in de Preferences, zodat bij elk nieuw aangemaakte REA model de instellingen goed staan. Ga hiervoor naar Window → Preferences... → REAmodel diagram → Rulers And Grid en neem de instellingen over van figuur 4.10. Nu kan je starten met het aanmaken van je REA model in de REA editor. Je kan rechts in de palette alle elementen van het REA model terugvinden en toevoegen aan het REA model. Ook kan je gebruik maken van de Toolbar bovenaan om bijvoorbeeld de elementen


33

uit te lijnen of automatisch te schikken. Wanneer je het voorbeeld van de boekenwinkel uit de paper van Gailly (2007a) modelleert krijg je een REA model zoals weergegeven in figuur 4.11. Je kan een REA model ook gaan valideren door in het menu Diagram de optie Validate te kiezen. Wanneer je nu de Problems View opent (via Window → Show View → Problems), zal je een lijst krijgen van alle fouten die gevonden zijn bij het valideren. Voorbeeld 4.12 toont ons het bookshop.reamodel XML bestand. Hier zie je duidelijk hoe het XML bestand hiërarchisch is opgebouwd. Alle REA model elementen zitten in de tags vervat. De Economic Resources zitten letterlijk via de tag in de vervat, want ze zijn met een containment relatie met de Economic Resource Types verbonden.


Figuur 4.11: Het bookshop voorbeeld in de REA editor

34


35

Voorbeeld 4.12: Het .reamodel bestand van het Bookshop voorbeeld

<xmi:XMI x m i : v e r s i o n=” 2 . 0 ” xmlns:xmi=” h t t p : //www. omg . o r g /XMI” x m l n s : x s i=” h t t p : //www. w3 . o r g /2001/XMLSchema−i n s t a n c e ” xmlns:REAModel=” h t t p : ///REAModel . e c o r e ”> <eventTypes x s i : t y p e=” REAModel:DecrementEconomicEventType ” name=” s a l e T y p e ” d u a l i t y T y p e=”paymentType”> <eventTypes x s i : t y p e=” REAModel:IncrementEconomicEventType ” name=”paymentType” d u a l i t y T y p e=” s a l e T y p e ”>

Hoofdstuk 5

Besluit 5.1

Evaluatie

Hieronder zal ik eerst een evaluatie geven van de frameworks die ik gebruikt heb gedurende mijn masterproef. Deze evaluatie is uiteraard gebaseerd op mijn persoonlijke praktische ervaringen. Vervolgens zal ik de ontwikkelde REA editor evalueren wat betreft praktisch nut en praktische mogelijkheden.

5.1.1

Gebruikte frameworks

Het Eclipse Platform is ondertussen al wereldwijd bekend in alle rangen van de IT-wereld. De grootste voordelen van Eclipse zijn ongetwijfeld de platformonafhankelijkheid (draait zowel op Windows, Mac als Linux), het feit dat het een open source project is (gratis downloadbaar en constante ontwikkeling door vele onafhankelijke programmeurs) en zijn uitbreidbaarheid (iedereen kan het platform uitbreiden m.b.v. plugins). Helaas zijn deze voordelen tegelijkertijd ook nadelen. Eclipse is voor geen enkel platform geoptimaliseerd. Er zijn zeer veel verschillende versies voor Eclipse beschikbaar en er komen zeer vaak nieuwe versies uit, zodat het up-to-date houden van je eclipse configuratie een fulltime job is. Als je vandaag een Eclipse plugin schrijft, is het nooit zeker hoe deze zich op de volgende Eclipse versie zal gedragen. Dit heb ik aan den lijve ondervonden bij het maken van de REA Editor. Het was zeer moeilijk om de correcte Eclipse configuratie (versies en andere plugins) te vinden waarop de REA Editor zonder problemen kon ge¨ınstalleerd en gebruikt worden. Ook het feit dat plugins gebruik kunnen maken van andere plugins (d.m.v. dependencies), maken dat er zeer snel fouten in een Eclipse configuratie opduiken. Vanaf het moment dat er een dependency ontbreekt of er één corrupte plugin in je installatie kruipt, kan je volledige Eclipse configuratie onbruikbaar worden. Dit heeft men proberen op te lossen door een nieuwe versie van de Update Manager voor Eclipse uit te brengen, Equinox genaamd, maar ook deze slaagt er niet in om alle dependency problems op te lossen. Deze tekortkomingen buiten beschouwing gelaten, blijft Eclipse toch nog altijd de referentie tussen de ontwikkelomgevingen. Toch zou één en ander kunnen opgelost worden door minder en stabielere totaalpakketten van Eclipse (met een pakket aan plugins voorge¨ınstalleerd) ter beschikking te stellen. Op de downloadpagina

36

HOOFDSTUK 5. BESLUIT

37

van Eclipse1 denkt men ook al in die richting, maar ontbreekt nog een modeling package. De commercialisatie van Eclipse, zoals IBM met Websphere doet, is een andere –maar helaas dure– oplossing. Het EMF framework, dat ik gebruikt heb om het ecore model aan te maken, zit momenteel al in een volwassen fase. Het is een zeer goed, stabiel en wijdverspreid framework en waarover dan ook veel goede documentatie bestaat, zoals het boek van Steinberg, Budinsky, Paternostro & Merks (2007). Zo kan je een ecore model aanmaken met de EMF standaard editor, die het model in een boomstructuur weergeeft (zoals in figuur 4.1), maar ook met de grafische editor (zoals in figuur 4.3). Dit alles maakt EMF tot een zeer makkelijk te gebruiken modeling framework. Ook het GEF framework is een veelgebruikt framework dat op zijn eigen benen kan staan. Vele UML tools of grafische editors zijn reeds gemaakt m.b.v. GEF en bewijzen dat dit framework zeer vernuft in elkaar zit. Voor het aanmaken van de REA editor heb ik nooit rechtstreeks gebruik gemaakt van GEF en ik heb bijgevolg ook weinig praktische ervaring met het framework. Uit de gelezen papers en artikels weet ik wel dat het een zeer volledig framework is, maar dat het ook zeer complex in elkaar zit, waardoor vele ontwikkelaars vaak afgeschrikt worden. Uiteindelijk is voor het aanmaken van de REA editor vooral gebruik gemaakt van GMF. Dit framework maakt het mogelijk om van Eclipse een ware Model Driven Development (MDD) omgeving te maken en zodoende een Eclipse plugin te genereren zonder zelf programmacode te moeten schrijven. Dit is natuurlijk een enorm goede ontwikkeling die zeker voortgezet moet worden, want GMF bevindt zich helaas wel nog in de ontwikkelingsfase. In 2005 zat het GMF project nog officieel in de Validation Phase. Momenteel is GMF wel degelijk bruikbaar om Eclipse plugins te ontwikkelen, zoals deze masterproef bewijst, maar het gebrek aan documentatie, onduidelijke foutmeldingen, fouten in gegenereerde code e.d. bewijzen dat er nog heel wat verbeteringen mogelijk zijn. Ik kan dus concluderen dat dit framework zeer hoopgevend is voor de toekomst van MDD en ik hoop dat in de (nabije) toekomst MDD kinderspel zal worden en het “domme programmeerwerk” overbodig maakt.

5.1.2

Validering met de REA editor

We kunnen de gebouwde REA editor makkelijk gebruiken om een REA model te valideren. Zo kunnen we controleren of een bepaald REA model voldoet aan het ecore model zoals voorgesteld door Gailly (2007a), maar ook is het mogelijk om het REA metamodel aan te passen om vervolgens de effecten ervan te gaan testen op bestaande voorbeelden. Ik heb –bij wijze van proef– eens even het voorbeeld van de boekenwinkel (zie figuur 4.11) met de REA editor gevalideerd en dit bracht de twee problemen aan het licht die in figuur 5.1 weergegeven worden. Elke Economic Resource Type moet volgens het REA metamodel zowel een Inflow Type als een Outflow Type hebben, wat niet het geval was. Vervolgens heb ik een uitbreiding van dit voorbeeld gemaakt, zodat dit ook voldoet aan deze voorwaarden en dus volledig conform is met het REA metamodel. Het resultaat hiervan ziet u in figuur 5.2. In de onderste helft van de figuur is het model uitgebreid zodat ook de aankoop van nieuwe boeken 1

http://www.eclipse.org/downloads/


38

Figuur 5.1: Validatie van het boekenwinkel-voorbeeld

bij de leverancier gemodelleerd wordt. Er is nu ook een Increment Economic Event dat het aantal boeken in voorraad verhoogt en een Decrement Economic Event dat het bedrag op de account verlaagt. Verder is er een CommitmentToDeliverOrder toegevoegd dat de verbintenis van de Supplier voorstelt om de boeken te leveren en een CommitmentToPayOrder dat de verbintenis van de bookshop voorstelt om de bestelling te betalen.

5.2 5.2.1

Naar de toekomst toe OCL

Momenteel controleert de validatie van het REA model enkel de beperkingen van het ecore model. Enkel de onder- en bovengrenzen van de cardinaliteiten van elke referentie en de naamgeving (niet leeg en geen dubbels) worden gecontroleerd. Door gebruik te maken van de Object Constraint Language (OCL), kan men nog verdere beperkingen aan het REA model opleggen en deze ook laten controleren bij de validatie. Een voorbeeld van zo’n extra controle vind je bij Increment Commitment. Deze klasse is altijd verbonden met een Increment Economic Event Type en wanneer deze commitment voldaan wordt, zal ze een fullfill relatie hebben naar een Increment Economic Event. Er zou eigenlijk ook nog gecontroleerd moeten worden of deze klasse van hetzelfde type is als de Increment Economic Event Type. Anders zou je volgens het model een verbintenis om te betalen kunnen nakomen door het aantal boeken in de boekenwinkel te doen toenemen, dus met de verkeerde Increment Economic Event. GMF biedt reeds de mogelijkheid om aan het .gmfmap bestand OCL constraints toe te voegen die dan automatisch ook gevalideerd zullen worden. Je kan dan zelf specifieke foutmeldingen opgeven die weergegeven zullen worden wanneer een bepaalde constraint niet voldaan is. In figuur 5.3 zie je dat je aan het Mapping Model een Audit Container kan toevoegen, die dan één of meerdere Audit Rules bevat met een aantal Constraints.

5.2.2

UML Profiles

Een mogelijk alternatief voor het aanmaken van een REA editor, zoals in deze masterproef besproken, is het aanmaken van een UML Profile voor het REA model. Een UML profile


Figuur 5.2: De uitgebreide versie van het boekenwinkel-voorbeeld

39


40

Figuur 5.3: Mogelijkheid om OCL constraints toe te voegen aan de REA editor

is eigenlijk een uitbreiding van de UML standaard voor een domeinspecifiek probleem. Zo zou je een UML class diagram kunnen gaan uitbreiden met specifieke klassen uit het REA model, bijvoorbeeld een Economic Resource klasse. Er bestaan verschillende soorten UML Profiles: Featherweight, Lightweight, Middleweight en Heavyweight. Deze worden uitgebreid besproken en vergeleken in het online Eclipse artikel van Bruck en Hussey (2007). Voor een REA UML Profile kan je best een Lightweight extension gaan gebruiken waarbij je stereotypes kan gebruiken om keywords toe te voegen aan bestaande elementen. Ook kan je bepaalde beperkingen aan het model opleggen. Voor het aanmaken van een UML model bestaat er de Eclipse UML2 2.0 plugin die besproken wordt in het online Eclipse artikel “Getting Started with UML2” (Hussey, 2006a). Met de UML2 2.0 plugin kan je ook UML Profiles aanmaken zoals besproken wordt in “Introduction to UML2 Profiles” (Hussey, 2006b). Het grote voordeel van het gebruik van UML Profiles is dat je dan bestaande, uitgebreide UML tools (zoals Rational Rose) kan gebruiken om een REA model aan te maken. Een UML Profile is ook zeer universeel en overdraagbaar tussen verschillende applicaties, onder andere omdat het profile zelf in XML formaat opgeslagen wordt. Ook is het redelijk eenvoudig om kleine aanpassingen te maken aan het REA model en deze snel te gaan testen met een aangepast UML Profile. Een nadeel tegenover de REA editor is dan weer dat je de REA editor makkelijker kan uitbreiden naar domein specifieke behoeften. Zo zou men de mogelijkheid kunnen voorzien in de REA editor om automatisch een aan- en verkoop event aan te maken voor elke Economic Resource of om alle nodes op het Knowledge Level te verbergen.

5.2.3

Software ontwikkeling m.b.v. REA modellen

Een volgende stap na het modelleren en valideren van een REA model, zou kunnen zijn om vanuit dit REA model een programma te laten genereren. Het REA model zou dan bijvoorbeeld als basis kunnen dienen voor een ERP systeem. Men zou dan het gegenereerde programma kunnen gebruiken om bijvoorbeeld de voorraden bij te houden. Hierop zou men


41

dan events kunnen toepassen zoals een aan- of verkoop. We zouden nog een stap verder kunnen gaan en de REA modellen gebruiken om de ERP systemen van verschillende bedrijven aan elkaar te koppelen. Zo kan men dan onmiddellijk een order doorgeven aan de leverancier als een bepaald resource onder een bepaald niveau zakt. Dit order kan dan bijvoorbeeld via het SOAP protocol naar de leverancier gestuurd worden in de vorm van XML boodschappen. Ook bij een eventuele fusie of overname kunnen dan makkelijk de verschillende informatiesystemen van de bedrijven aan elkaar gekoppeld worden. Men moet dan enkel de REA modellen samenvoegen en vervolgens het nieuw ERP systeem gaan destilleren uit het nieuwe REA model. Een andere mogelijkheid bestaat erin om het REA model te gebruiken als datamodel voor het Database Management System (DBMS). Dan zou men in een bedrijf geen apart ER schema moeten maken voor de database, maar enkel een REA model. Eens men dit model van een bedrijf heeft, kan men dit onmiddellijk gebruiken om een database op te zetten. Dit zou veel tijd en werk kunnen besparen.

5.3

Conclusie

In deze masterproef is het REA model uitgebreid getest en gebruikt geweest. We hebben een voorbeeld gevalideerd en de tekortkomingen weggewerkt door het voorbeeld uit te breiden. We kunnen dus stellen dat het REA model zeker bruikbaar is om in een levensechte situatie in te zetten. Wanneer men REA modellen wil aanmaken en valideren kan daarbij de, in deze masterproef ontwikkelde, REA editor van groot praktisch nut zijn. Deze stelt ons in staat om uitgebreid met REA modellen te gaan experimenteren. Wel zouden hier, naar de toekomst toe, nog een aantal verbeteringen kunnen gebeuren, zoals het toevoegen van OCL constraints. Ook zou het mooi zijn mochten we het aangemaakte REA model vervolgens kunnen gebruiken als invoer van andere programma’s, zoals een ERP systeem of een DBMS. Toegegeven, in grote bedrijven zal een dergelijk REA model veel te complex worden om nog praktisch mee te kunnen modelleren, maar een KMO zou hier wel nuttig gebruik van kunnen maken. Verder stelt het ons ook in staat om op academisch niveau na te denken over modellen en modellering. Verder is deze masterproef zeer leerrijk geweest om te achterhalen wat er vandaag de dag allemaal al mogelijk is op het vlak van Model Driven Development. Tot enkele jaren terug was dit louter science-fiction, maar ondertussen beginnen de eerste volwaardige tools te ontstaan die deze droom waarmaken. Het moet gezegd, er is nog een lange weg te gaan. De kinderziektes in een framework als GMF waren vaak een doorn in het oog, maar eens deze zullen weggewerkt zijn, heeft MDD nog een mooie toekomst voor de boeg.

Lijst van geraadpleegde werken Papers Gailly, 2007a Frederik Gailly, and Geert Poels, Ontology-Driven Business Modelling: Improving the Conceptual Representation of the REA Ontology, Universiteit Gent, 2007 Gailly, 2007b Frederik Gailly, Supporting Business Software Interoperability with Ontologies, thesis, Vrije Universiteit Brussel, 2007 Na, Choi, Lim Hong-Seok Na, O-Hoon Choi, and Jung-Eun Lim, A Metamodel-Based Approach for Extracting Ontological Semantics from UML Models, Korea University Abouzahra, Bezivin, Del Fabro, Jouault Anas Abouzahra, Jean Bézivin, Marcos Didonet Del Fabro, Frédéric Jouault, A practical Approach to Bridging Domain Specific Languages with UML profiles, University of Nantes Brockmans, Volz, Eberhart, Loffler Sara Brockmans, Raphael Volz, Andreas Eberhart, and Peter Löffler, Visual Modeling of OWL DL Ontologies Using UML, University of Karlsruhe, Germany Borch, Jespersen, Linvald, Osterbye Signe Ellegaard Borch, Jacob Winther Jespersen, Jesper Linvald, Kasper Østerbye, A Model Driven Architecture for REA based systems, IT University of Copenhagen, Denmark Susi, Perini, Mylopoulos Angelo Susi, Anna Perini and John Mylopoulos, The Tropos Metamodel and its Use, University of Trento, Italy

Boeken Clayberg, Rubel, 2007 Eric Clayberg, and Dan Rubel, July 2007, Eclipse: Building CommercialQuality Plug-ins, Pearson Education Inc., Boston Steinberg, Budinsky, Paternostro, Merks, 2007 Dave Steinberg, Frank Budinsky, Marcelo Paternostro, and Ed Merks, February 2007, EMF: Eclipse Modeling Framework, Pearson Education Inc., Boston

I


II

Internetbronnen Eclipse Project Site Eclipse Project Site, the Eclipse Foundation, URL: www.eclipse. org/. (20/11/2007). Bacvanski, Graff, 2005 Vladimir Bacvanski, Petter Graff, Mastering Eclipse Modeling Framework, InferData Ltd., URL: www.eclipsecon.org/2005/presentations/EclipseCon2005_Tutorial28.pdf. (28/02/2005). Smith, Welty, McGuinness, 2004 Michael K. Smith, Chris Welty, and Deborah L. McGuinness, 2004, OWL Web Ontology Language Guide, URL: www.w3.org/TR/owl-guide. (20/11/2007). Griffin, 2003 Catherine Griffin, May 2003, Using EMF, Eclipse Corner Article, URL: www. eclipse.org/articles/Article-Using%20EMF/using-emf.html. (01/12/2007). Majewski, 2004 Bo Majewski, 2004, A Shape Diagram Editor, Eclipse Corner Article, URL: www.eclipse.org/articles/Article-GEF-diagram-editor/shape.html. (10/12/2007). Hudson, 2006 Randy Hudson, 20/03/2006, High level Eclipse Con presentation of GEF and Draw2D, URL: wiki.eclipse.org/GEF_Articles. (21/04/2008). Aniszczyk, 2005 Chris Aniszczyk, 2005, Using GEF with EMF, Eclipse Corner Article, URL: www.eclipse.org/articles/Article-GEF-EMF/gef-emf.html. (20/12/2007). Blewitt Alex Blewitt, Eclipse - a tale of two VMs (and many classloaders), Eclipse Zone, URL: www.eclipsezone.com/articles/eclipse-vms. (19/01/2008). Plante, 2006 Frederic Plante, 2006, Introducing the GMF Runtime, Eclipse Corner Article, URL: www.eclipse.org/articles/Article-Introducing-GMF/article.html. (20/01/2008). GMF Projectsite Graphical Modeling Framework (GMF), URL: www.eclipse.org/modeling/gmf/. (21/01/2008). GMF Tutorial GMF Tutorial, Eclipse Wiki, URL: wiki.eclipse.org/index.php/GMF_ Tutorial. (21/01/2008). GMF Nieuwsgroep eclipse.modeling.gmf, registreren op: www.eclipse.org/newsgroups/, url nieuwsgroep: news://news.eclipse.org/eclipse.modeling.gmf. (21/01/2008). Ecore Diagram Editor Reflective Ecore Model Diagram Editor, URL: dynamicgmf.sourceforge.net/. (29/02/2008) Bruck, Hussey, 2007 James Bruck and Kenn Hussey, IBM 19/07/2007, Customizing UML: Which Technique is Right for You? URL: www.eclipse.org/modeling/mdt/uml2/


III

docs/articles/Customizing_UML2_Which_Technique_is_Right_For_You/article.html. (20/03/2008). Hussey, 2006a Kenn Hussey, IBM, 18/07/2006a, Getting Started with UML2 URL: www. eclipse.org/modeling/mdt/uml2/docs/articles/Getting_Started_with_UML2/article. html. (18/03/2008). Hussey, 2006b Kenn Hussey, IBM, 18/07/2006b, Introduction to UML2 Profiles URL: www. eclipse.org/modeling/mdt/uml2/docs/articles/Introduction_to_UML2_Profiles/ article.html. (21/03/2008).

ONTWIKKELING VAN EEN TOOL VOOR ONTOLOGIE-GESTUURDE BEDRIJFSMODELLERING

Recommend Documents