UNIVERSITEIT GENT FACULTEIT ECONOMIE EN...

UNIVERSITEIT GENT

FACULTEIT ECONOMIE EN BEDRIJFSKUNDE

ACADEMIEJAAR 2008 – 2009

HET GEBRUIK VAN DOMEINSPECIFIEKE

VERSUS GENERIEKE TALEN BIJ BUSINESS

MODELING: REA ONTOLOGY METAMODEL

VERSUS REA ONTOLOGY UML PROFILE

Masterproef voorgedragen tot het bekomen van de graad van

Master in de bedrijfseconomie

Wouter Verbeure

onder leiding van

Prof. dr. Geert Poels en dr. Frederik Gailly

PERMISSION

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

Wouter Verbeure

Woord vooraf

In dit klein dankwoord wil ik enkele personen in de bloemetjes zetten.

Eerst en vooral wil ik mijn promotoren dr. Frederik Gailly en Prof. dr. Geert Poelsvan de vakgroep Beleidsinformatica en Operationeel Beheer, faculteit Economieen Bedrijfskunde van de Universiteit Gent bedanken. Zij hebben de begeleidingvan deze thesis op zich genomen.

Verder bedank ik mijn ouders die mij de mogelijkheid hebben gegeven om eenbijkomende opleiding bedrijfseconomie te volgen.

Tenslotte wil ik iedereen bedanken die mee heeft geholpen bij het verwezenlijkenvan dit eindwerk. De welgekomen aanmoedigingen en steun tijdens de ontwikke-ling ervan deden goed.

Wouter, augustus 2009.

iii

Inhoudsopgave

Woord vooraf iii

Inhoudsopgave iv

Lijst van figuren vi

Lijst van tabellen viii

Lijst van symbolen en acroniemen ix

1 Inleiding 1

1.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1 Uitbreiding programma . . . . . . . . . . . . . . . . . . . 3

1.3.2 REA metamodel vs REA UML Profile . . . . . . . . . . . 3

1.4 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Opdrachtgever . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Reamodeller Eclipse Plugin 6

2.1 Google Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Ontwikkeling plugin . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Reamodeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Eclipse-omgeving . . . . . . . . . . . . . . . . . . . . . 8

2.3.2 Waar kan de plugin gevonden worden? . . . . . . . . . . 9

iv

2.3.3 Hoe kan een eerste model gemaakt worden? . . . . . . . . 10

3 Uitbreiding programma 13

3.1 Pijlpunten verwijderen . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Kleur toevoegen . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Nieuwe relaties leggen . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 Multipliciteiten toevoegen . . . . . . . . . . . . . . . . . . . . . 17

3.4.1 Ecore metamodel aanpassen . . . . . . . . . . . . . . . . 17

3.4.2 Mapping model vernieuwen . . . . . . . . . . . . . . . . 18

3.5 Opmerkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Vergelijking REA metamodel vs REA UML Profile 21

4.1 REA metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 REA UML Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.1 Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.2 Werkwijze . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.3 Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.4 Controle . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 REA metamodel vs REA UML Profile . . . . . . . . . . . . . . . 29

4.3.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.2 UML vs Domain Specific Languages . . . . . . . . . . . 30

4.3.3 Voor- en nadelen in functie van het gebruikersgemak . . . 30

5 Besluit 33

5.1 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.1 Uitbreiding reamodeller plugin . . . . . . . . . . . . . . . 33

5.1.2 REA metamodel vs REA UML Profile . . . . . . . . . . . 34

5.2 Uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Bibliografie 36

A REA metamodel Tim Vermeiren 37

B REA model bookshop 38

Lijst van figuren

1.1 Logo Universiteit Gent . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 GMF Dashboard bij GMF project . . . . . . . . . . . . . . . . . 8

2.2 Logo Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Downloadpagina van de plugin . . . . . . . . . . . . . . . . . . . 9

2.4 Aanmaak REA model . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 Vastleggen modelnaam . . . . . . . . . . . . . . . . . . . . . . . 11

2.6 Vastleggen modeldiagramnaam . . . . . . . . . . . . . . . . . . . 11

2.7 REA model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Achtergrondkleur EconomicResourceTypeFigure . . . . . . . . . 14

3.2 Gebruik van kleuren in het diagram . . . . . . . . . . . . . . . . 15

3.3 OCL beperking in Mapping Model . . . . . . . . . . . . . . . . . 17

3.4 Deel nieuw ecore metamodel . . . . . . . . . . . . . . . . . . . . 18

3.5 Typify relatie Link Mapping . . . . . . . . . . . . . . . . . . . . 19

3.6 Typify relatie met multipliciteiten . . . . . . . . . . . . . . . . . 19

4.1 REA model bookshop Vermeiren (2007-2008) . . . . . . . . . . . 22

4.2 REA model bookshop . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3 UML Editor Menu . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4 Stereotype toevoegen . . . . . . . . . . . . . . . . . . . . . . . . 25

4.5 Bookshop klassendiagram . . . . . . . . . . . . . . . . . . . . . 27

4.6 Bookshop REA model (via UML Profile) . . . . . . . . . . . . . 28

4.7 Pop-up met validatie resultaten . . . . . . . . . . . . . . . . . . . 29

vi

4.8 Interactive OCL Console . . . . . . . . . . . . . . . . . . . . . . 29

A.1 REA metamodel Tim Vermeiren . . . . . . . . . . . . . . . . . . 37

B.1 REA model bookshop Gailly & Poels (2007) . . . . . . . . . . . 38

Lijst van tabellen

1.1 Basis REA concepten . . . . . . . . . . . . . . . . . . . . . . . . 2

3.1 Kleurencombinatie REA model . . . . . . . . . . . . . . . . . . . 15

3.2 Toegevoegde relaties . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 REA metamodel vs REA UML Profile (voordelen) . . . . . . . . 31

4.2 REA metamodel vs REA UML Profile (nadelen) . . . . . . . . . 32

viii

Lijst van symbolen enacroniemen

Symbolen

R ResourceE EventA AgentC Commitment

Acroniemen

REA Resources Events AgentsEMF Eclipse Modeling FrameworkGMF Graphical Modeling FrameworkUML Unified Modeling LanguageGUI Graphical User InterfaceMDD Model Driven DevelopmentMDA Model Driven ArchitecturePIM Platform Independent ModelPSM Platform Specific ModelDSL Domain Specific LanguageDSM Domain Specific ModelingOCL Object Constraint LanguageSDK Software Development Kit

ix

Hoofdstuk 1

Inleiding

Het modelleren van bedrijfsprocessen, kortweg bedrijfsmodellering, is geen nieu-wigheid. In deze thesis wordt de informatie die een onderneming binnenkrijgt,de processen die worden uitgevoerd, . . . gemodelleerd volgens de REA-methode.Alle verzamelde informatie moet het bedrijf in staat stellen om een goed overzichtte hebben over het reilen en zeilen zowel binnen als buiten het bedrijf. Daarbijis het de bedoeling kennis op te doen en sneller te kunnen inspelen op nieuwetendensen, vragen van klanten, . . .

1.1 Situering

De afkorting REA staat voor de 3 belangrijke bouwstenen van het model, name-lijk: Resources, Events en Agents. Deze basis REA concepten worden in tabel 1.1beschreven1.

Het ontstaan van de REA ontologie gaat terug tot het begin van de jaren 80. Wil-liam E. McCarthy heeft dit ontworpen met als hoofdbedoeling het modelleren vanaccounting systemen. Door de jaren heen is dit geevolueerd en wordt REA ookgebruikt voor bedrijfsmodellering.

Zoals bij elke taal horen bij REA regels. Er worden 3 axioma’s geformuleerd(Geerts & McCarthy, 2000):

1. Op zijn minst een inflow event en een outflow event behoren tot een economic

1Vrije vertaling van de beschrijving in Gailly & Poels (2007)

1

1 Inleiding 2

Economic Resource Een schaars goed, bruikbaar voor economicagent, dat gebruikers van bedrijfsapplicatieswillen plannen, volgen en controleren

Economic Agent Individu of organisatie die de mogelijkheidheeft om economic resources te controlerenof in staat is deze rechten te verkrijgen

Economic Event Een stijging of daling in de waarde van eeneconomic resource

Commitment Verbintenis van een economic agent om eeneconomic event uit te voeren

Tabel 1.1: Basis REA concepten

resource

2. Elk event dat een outflow veroorzaakt moet via een duality relation gekop-peld worden met een event dat een inflow veroorzaakt. Dit zowel in de eneals in de andere richting.

3. Elk economic event moet zowel een provide als een receive relatie hebbenmet een economic agent.

Door de evolutie van REA bestaan er verschillende varianten. In deze thesis wordtde variant gebruikt die beschreven staat in Gailly & Poels (2007).

1.2 Basis

Deze masterthesis bouwt verder op de thesis van Vermeiren (2007-2008). Diemasterproef geeft een korte bespreking rond bedrijfsmodellering waarna verderwordt ingegaan op het REA metamodel. Het hoofddoel bestaat er echter uit omeen programma, tool te schrijven die REA modellen kan aanmaken.

Om het programma te ontwikkelen wordt gebruik gemaakt van verschillende fra-meworks (Eclipse, EMF, GMF, . . . ). De belangrijkste onderdelen worden in hetvervolg van deze thesis kort aangehaald. Voor een meer grondige beschrijvingwordt verwezen naar Vermeiren (2007-2008) of kan de betreffende literatuur wor-den geraadpleegd.

1 Inleiding 3

De ontwikkeling van de tool vindt plaats in Eclipse2, dit is een open source plat-form dat gebruik maakt van de Java Virtual Machine. Het programma, de tool iseen plugin die kan worden toegevoegd aan de Eclipse-omgeving. Voor de pluginwordt eerst en vooral een ecore metamodel aangemaakt, voor de beschrijving vanhet REA metamodel. Dit ecore metamodel kan vervolgens verder verwerkt wordenin een GMF project. Via GMF (Graphical Modeling Framework) kan, zonder dui-zenden lijnen code te moeten schrijven, een mooie grafische interface verkregenworden voor de plugin. De werkwijze van een GMF project wordt verder in sectie2.2 p.7 besproken.

1.3 Doelstelling

De thesis van dit jaar bouwt verder, zoals al eerder aangehaald, op het reeds gele-verde werk van Vermeiren (2007-2008). De doelstelling bestaat nu echter uit tweedelen:

1. Uitbreiding van de bestaande tool

2. Vergelijking REA metamodel met REA UML Profile

1.3.1 Uitbreiding programma

De reeds bestaande tool kan al een basis REA model aanmaken. Nu is het debedoeling om dit basismodel uit te breiden met enkele nieuwe relaties. Daarnaastis het de bedoeling gebruik te maken van kleuren voor de verschillende lagen in hetdiagram; operational layer (groen), commitment layer (paars) en knowledge layer(geel). De belangrijkste toevoeging is echter het weergeven van de multipliciteitenop een relatie.

1.3.2 REA metamodel vs REA UML Profile

Naast de uitbreiding van de plugin vormt zich een tweede doelstelling. Het is debedoeling een vergelijking te maken van de manier waarop een REA model wordtaangemaakt. Deze aanmaak van een REA model kan worden verwezenlijkt optwee verschillende manieren:

1. Via de eigen geprogrammeerde tool2The Eclipse Foundation, http://www.eclipse.org

http://www.eclipse.org

1 Inleiding 4

2. Via een UML profile3

Elke werkwijze heeft zijn eigen voor- en nadelen die verder in deze thesis wordenaangehaald (zie hoofdstuk 4).

1.4 Overzicht

Na een kleine schets van de masterproef volgt nu de verdeling.

Hoofdstuk 2 handelt over de ontwikkelde plugin. Gezien de ontwikkeling van deplugin een belangrijk onderdeel van de thesis vormt, wordt hier een apart hoofdstukaan gewijd. Zaken die aan bod komen zijn: Ontwikkeling van de plugin, Waar kande plugin gevonden worden?, Hoe kan de plugin worden opgestart?, . . .

Hoofdstuk 3 beschrijft meer in detail de uitbreidingen en aanpassingen die aan hetprogramma zijn gedaan. Hierin worden ook meer technische termen aangehaald.Tot slot van het hoofdstuk worden nog enkele opmerkingen gegeven die handigkunnen zijn bij een volgende studie.

Hoofdstuk 4 behandelt de tweede belangrijke doelstelling van deze thesis, namelijkde vergelijking tussen de twee verschillende manieren van werken om een REAmodel aan te maken. Gezien REA UML Profile nog niet aan bod kwam, wordt ditgrondig besproken alvorens over te gaan tot de vergelijking.

Hoofdstuk 5 geeft tot slot een conclusie over de verwezenlijkte doelstellingen.Daarnaast komen eventuele onderzoeks- en uitbreidingsmogelijkheden aan bodvoor verdere studie van het onderwerp.

3zie ook Gailly (2008, Hoofdstuk 5)

1 Inleiding 5

1.5 Opdrachtgever

De opdrachtgever voor deze masterthesis is de vakgroep Beleidsinformatica enOperationeel Beheer, faculteit Economie en Bedrijfskunde van de Universiteit Gent(Tweekerkenstraat 2 B-9000 GENT).

Figuur 1.1: Logo Universiteit Gent

Hoofdstuk 2

Reamodeller Eclipse Plugin

In het tot stand komen van deze thesis vormt de ontwikkelde plugin een belangrijkefactor. Vandaar dat hieraan ook een apart hoofdstuk wordt gewijd. Om de pluginvlot toegankelijk te maken voor iedereen is een Google project aangemaakt (ziesectie 2.1). Het vervolg van het hoofdstuk handelt over de ontwikkeling van deplugin, de installatie, . . .

2.1 Google Code

Google Code1 biedt een dienst aan waarbij er de mogelijkheid is om een projectte hosten bij Google. De projecteigenaar geeft hierbij aan onder welke licentiehet project wordt uitgegeven. Dit project is uitgegeven onder de Eclipse PublicLicense 1.0. Naast de licentie worden ook labels toegekend om het programma tekarakteriseren en zoekopdrachten te verbeteren. De projecteigenaar kan verder per-sonen toelaten die meehelpen bij de verwezenlijking van het project. Google Codebiedt daarvoor onder andere een versiebeheersysteem aan zodat meerdere ontwik-kelaars wijzigingen kunnen aanbrengen aan dezelfde bestanden. Een voorbeeldvan een dergelijk versiebeheersysteem is Subversion2. Naast het versiebeheersys-teem kunnen de medewerkers op de site aangeven welke taken nog moeten wor-den uitgevoerd, welke problemen reeds gerepareerd zijn (al dan niet geverifieerd),. . . Vervolgens kunnen aan het project downloads (bijvoorbeeld zip-bestand van deplugin) worden toegevoegd. Tot slot kunnen wiki-documenten worden aangemaaktwaarop installatietips, howto’s, . . . worden weergegeven.

1http://code.google.com/2http://subversion.tigris.org/

6

http://code.google.com/

http://subversion.tigris.org/


2.2 Ontwikkeling plugin

Voor de ontwikkeling van de plugin wordt gebruik gemaakt van reeds bestaandeframeworks. Het Graphical Modeling Framework (GMF) is hier het belangrijk-ste framework. GMF is onlangs ontwikkeld en staat in voor een gemakkelijkerekoppeling van het Eclipse Modeling Framework (EMF) en Graphical Editing Fra-mework (GEF). Bij een GMF project komen verschillende stappen en modellenkijken vooraleer de eigenlijke diagram editor wordt gecreeerd:

∙ Domain Model3 & Domain Generator ModelHet Domain Model is eigenlijk het ecore metamodel. Het ecore metamodelvormt de kern van EMF (onderliggend framework van GMF) en is een plat-vorm onafhankelijk model. Uit dit model wordt het genmodel gegenereerddat de platform specifieke informatie bevat.

∙ Graphical Definition ModelHet Graphical Definition Model bevat alle grafische elementen (zoals recht-hoeken, cirkels, verbindingen, pijlpunten, labels, . . . ) die in het diagramkunnen voorkomen.

∙ Tooling Definition ModelHet Tooling Definition Model bevat alle onderdelen van de palette (alle ele-menten die aan het model toegevoegd kunnen worden), extra knoppen in detoolbar, menu items, pop-up menu’s, acties, . . . .

∙ Mapping ModelHet Mapping Model vormt de link tussen Domain Model, Graphical Defini-tion Model en Tooling Definition Model. Dit model is noodzakelijk om tebepalen welk element uit het domein model door welke grafische elementenwordt voorgesteld en met welke tool het kan worden aangemaakt.

∙ Diagram Editor Gen ModelHet Diagram Editor Gen Model vormt de voorlaatste stap en is een transfor-matie van voorgaande modellen. Hierna kan de noodzakelijke code voor degrafische editor plugin worden gegenereerd.

Bij de aanmaak van een GMF project kan gekozen worden om via het GMF Dash-board te werken (zie figuur 2.1). Dit dashboard zorgt voor een overzichtelijk geheelin de te doorlopen stappen.

3Beschrijving van de verschillende modellen van een GMF project uit Vermeiren (2007-2008)


Tot slot valt nog op te merken dat bij een model, gecreeerd in een GMF editor,twee verschillende bestanden voorkomen. Naast .model is er een .model diagrambestand. Het .model bestand bevat alle domein informatie terwijl .model diagramde grafische informatie bevat.

Figuur 2.1: GMF Dashboard bij GMF project

2.3 Reamodeller

2.3.1 Eclipse-omgeving

Zoals reeds eerder aangehaald is de plugin ontwikkeld in de Eclipse-omgeving.Diezelfde omgeving wordt gebruikt om de plugin in op te starten. Gezien de plugingebruik maakt van verschillende andere plugins moeten deze allemaal aanwezigzijn in Eclipse. Deze plugins kunnen een voor een worden toegevoegd aan de basisEclipse omgeving. Hieronder worden de benodigde onderdelen weergegeven methun minimale vereiste versie:

∙ Eclipse 3.4 Ganymede(Op het moment van schrijven is Eclipse 3.5 Galileo verkrijgbaar)

∙ Eclipse Modeling Framework EMF(minimaal EMF 2.4.0 - nieuwste EMF 2.5.0)

∙ Object Constraint Language (OCL) 2.0


∙ Graphical Editing Framework (GEF) Models(minimaal GEF 3.4.0 - nieuwste GEF 3.5.0)

∙ Graphical Modeling Framework SDK(minimaal GMF 2.0.1 - nieuwste GMF 2.2.0)

Een gemakkelijkere oplossing, zonder het zelf toevoegen van plugins, is het down-loaden van de Eclipse modeling version4 met bovenstaande plugins reeds inge-voegd.

Figuur 2.2: Logo Eclipse

2.3.2 Waar kan de plugin gevonden worden?

Het Google project kan teruggevonden worden via onderstaande URL:

http://code.google.com/p/reamodeller/

Op bovenvermelde site is bij ’downloads’ het zip-bestand (zie figuur 2.3 p. 9) tevinden met de plugin. Deze plugin moet worden uitgepakt in de home directoryvan Eclipse.

Figuur 2.3: Downloadpagina van de plugin

4http://www.eclipse.org/modeling/ >> Downloads >> All-In-One Package

http://code.google.com/p/reamodeller/

http://www.eclipse.org/modeling/


2.3.3 Hoe kan een eerste model gemaakt worden?

1. Aanmaken projectFile >> New >> Project

2. Aanmaken model (zie figuur 2.4 p.10)File >> New >> Example >> REAModel Diagram

Figuur 2.4: Aanmaak REA model

3. Model- en diagramnaam vastleggen (zie figuur 2.5 & 2.6)

4. Eerste elementen en relaties toevoegen (zie figuur 2.7 p.12)

Deze informatie kan ook teruggevonden worden op de wikipagina’s van de pro-jectsite.


Figuur 2.5: Vastleggen modelnaam

Figuur 2.6: Vastleggen modeldiagramnaam


Figuur 2.7: REA model

Hoofdstuk 3

Uitbreiding programma

Als eerste belangrijke doelstelling van deze thesis zal dit hoofdstuk handelen overde verwezenlijkte uitbreidingen aan de tool. De tool is een plugin die kan wordentoegevoegd aan de Eclipse omgeving. Daarbij wordt gebruik gemaakt van andereplugins (GMF, EMF,. . . ). Om de plugin op te starten zijn die andere plugins nood-zakelijk. Meer info hierover is terug te vinden in hoofdstuk 2.

Handig bij het werken met EMF, GMF, Eclipse, . . . zijn de verschillende tutorialsdie beschikbaar zijn, o.a. via de Eclipse site. Na het doorlopen ervan wordt eengoed beeld gevormd en kan zelf aan de slag worden gegaan. Daarnaast zijn erlevendige nieuwsgroepen1 waarin vragen kunnen worden gesteld aan andere (pro-fessionele) gebruikers.

De effectieve uitbreidingen aan de plugin worden hieronder besproken. Daarbijhoren enkele kleinere toevoegingen waaronder het toevoegen van kleuren, verwij-deren van pijlpunten, leggen van nieuwe relaties, . . . . De grootste uitbreiding ishet toevoegen van multipliciteiten, wat in sectie 3.4 wordt besproken. Tot slot vanhet hoofdstuk worden nog enkele opmerkingen gegeven die handig kunnen zijn bijeen volgende studie.

3.1 Pijlpunten verwijderen

Als eerste aanpassing wordt het verwijderen van de pijlpunten bekeken. Het Grap-hical Definition Model in het GMF project (.gmfgraph bestand) verzorgt de opmaak

1http://www.eclipse.org/newsportal/index.php

13

http://www.eclipse.org/newsportal/index.php


van de elementen in het diagram. Dit model biedt dus de mogelijkheid om de pijl-punten op te maken. Wanneer naar een verbinding - een Polyline Connection

- wordt gekeken in het Graphical Definition Model, kan daarbij een Polyline

Decoration worden toegevoegd. De Polyline Decoration bevat de opmaakvan de pijlpunt en kan aan het begin (Source Decoration) of einde (TargetDecoration) van de verbinding worden toegevoegd. Zo kan een volle, enkele,dikke, . . . pijlpunt gekozen worden. Deze beschrijving gebeurt in de betreffendeFigure Descriptor waaraan de verbinding is toegevoegd. Indien niets wordtgespecificeerd dan bezit de connectie geen pijlpunt.

Het verwijderen van de pijlpunten bestaat er dus uit alle Polyline Decoration

elementen te verwijderen. Deze elementen zijn ontstaan doordat bij automatischeafleiding van het .gmfgraph bestand aan elke verbinding een pijlpunt wordt toege-kend.

3.2 Kleur toevoegen

Net zoals bij het verwijderen van de pijlpunten, geeft het Graphical Definition Mo-del de mogelijkheid kleur toe te voegen aan de verschillende elementen in het dia-gram. De achtergrondkleur kan gekozen worden uit een lijst met constante kleurenofwel door middel van de RGB2 code.

Figuur 3.1: Achtergrondkleur EconomicResourceTypeFigure

Op figuur 3.1 p.14 wordt de eigenschap Background aan Rectangle EconomicRe-

2Rood Groen Blauw


sourceTypeFigure toegevoegd binnen de Figure Descriptor EconomicResourceTy-peFigure. De toegekende waarde is yellow. Bij Rectangle IncrementCommitment-Figure (niet op de figuur) moet (255, 0, 255) als RGB-code worden gebruikt omde paarse kleur te bekomen.

Tabel 3.1 geeft de kleurencombinatie voor de verschillende lagen in het diagram.

Operational layer Groen

Commitment layer Paars

Knowledge layer Geel

Tabel 3.1: Kleurencombinatie REA model

Figuur 3.2 toont een deel van een diagram waarbij het gebruik van kleuren zicht-baar is. De versie van de plugin waarbij dit screenshot is genomen, dateert vanvoor het nieuwe ecore metamodel (zie verder, sectie 3.4.1 p.17). Hierdoor heb-ben de verbindingen tussen de entiteiten nog een welbepaalde kleur gekregen. Inde nieuwere versie is geen specifieke beschrijving meer voor de opmaak van eenbepaalde verbinding. Er is slechts een opmaak voor alle verbindingen omwillevan het feit dat de opmaak van de verschillende verbindingen quasi niet verschilt.Wanneer de kleur toch een belangrijke factor vormt, kan dit opgelost worden dooropnieuw meerdere verbindingen - Polyline Connections - te beschrijven in hetGraphical Definition Model.

Figuur 3.2: Gebruik van kleuren in het diagram

Het ontstaan van de verschillende opmaken voor de verbindingen komt ook hier,net zoals de pijlpunten, wellicht voort uit het gebruiken van de automatische aflei-ding van het .gmfgraph bestand uit het domeinmodel. Naarmate een beter overzicht


wordt gekregen van de modelleertaal, kunnen verschillende zaken vereenvoudigdworden.

3.3 Nieuwe relaties leggen

De plugin bevat reeds heel wat relaties. Deze verbindingen kunnen echter nogworden uitgebreid3 met linkage, custody,. . . . Tabel 3.2 geeft een overzicht tussenwelke elementen4 de nieuw toegevoegde verbindingen mogelijk zijn.

Association A-A

Custody A-R

Linkage R-R

Tabel 3.2: Toegevoegde relaties

Het weergeven van de nieuwe relaties in de uiteindelijke reamodeller vereist enkelestappen binnen het GMF project:

∙ Domain Model: Aanwezig zijn van link in het ecore metamodel

∙ Graphical Model: Aanmaak van een label, een connection en de beschrijvingvan de verschillende elementen.

∙ Tooling Model: Item aanmaken in de palette.

∙ Mapping Model: Connectie van de verschillende onderdelen.

Een nieuwigheid bij linkage en association is echter het gebruik van OCL beper-kingen. De OCL beperking zorgt ervoor dat een recursieve relatie met betrekkingtot een element niet mogelijk is. Verbindingen kunnen wel plaatsvinden tussen 2verschillende elementen van hetzelfde type.

Figuur 3.3 toont het bewuste gedeelte uit het Mapping Model (.gmfmap bestand).Daarbij is de OCL beperking ’self <>oppositeEnd’ toegevoegd aan de Link

Mapping van linkage die ervoor zorgt dat een recursieve relatie niet mogelijk is.

3Geertsa & McCarthy (2002)4A = Agent, . . . ; zie p.ix


Figuur 3.3: OCL beperking in Mapping Model

3.4 Multipliciteiten toevoegen

Naast de hierboven vermelde kleinere wijzigingen, worden bij een relatie nu mul-tipliciteiten opgeslagen. Om dit mogelijk te maken, was het noodzakelijk het ecoremetamodel van het REA metamodel ingrijpend te veranderen. Hieronder wordende aanpassing van het ecore metamodel en de belangrijkste andere wijzigingenbesproken.

3.4.1 Ecore metamodel aanpassen

Het bestaande ecore metamodel uit Vermeiren (2007-2008) (zie bijlage A p.37)moet een grondige aanpassing ondergaan. De relaties die zichtbaar zijn in hetuiteindelijke REA model, worden in het oude ecore metamodel bijgehouden alsEReferences. Hieraan kan echter geen extra info worden toegekend om bijvoor-beeld multipliciteiten toe te voegen. Om dit op te lossen is in het nieuwe5 ecoremetamodel gebruik gemaakt van een EClass als verbinding. Deze EClass moetwel opnieuw verbonden zijn via EReferences met de andere entiteiten. Belangrijkhierbij is dat de twee EReferences tussen de verbindingsklasse en de entiteitklasseals tegengestelde worden aangegeven bij de eigenschappen. Aan de EClass, die deverbinding voorstelt, kunnen attributen worden toegevoegd die de multipliciteitenvan de verbinding zullen opslaan.

Figuur 3.4 p.18 toont een deel van het nieuwe ecore metamodel waarbij de’typify’ relatie wordt uitgewerkt tussen een EconomicResourceType en eenEconomicResource. Bijzonder hieraan is de plaats van de attributen voor hetopslaan van de multipliciteiten. Normaal gezien wordt verwacht dat deze attribu-ten aan Relation worden toegevoegd waardoor ze in de afgeleide klassen worden

5Door de grote afmetingen van het nieuwe ecore metamodel is het handiger dit model te bekijkenop computer in de Eclipse omgeving. Het ecore metamodel kan gevonden worden op de project sitebij downloads.


Figuur 3.4: Deel nieuw ecore metamodel

overgeerfd. Dit bleek in ecore niet mogelijk waardoor de attributen overal zijntoegevoegd (o.a. navraag op de Eclipse nieuwsgroep).

3.4.2 Mapping model vernieuwen

De veranderingen in het ecore metamodel brengen veel wijzigingen met zich meein het Mapping Model zodat dit model vanaf nul opnieuw wordt opgebouwd. Omervoor te zorgen dat de multipliciteiten goed worden weergegeven op een verbin-ding is het belangrijk de nodige labels aan te maken en deze op een correcte manierte verbinden in het Mapping Model (zie figuur 3.5 p.19). De Link Mapping zorgtervoor dat de verbinding correct verloopt tussen de juiste elementen. Aan de LinkMapping worden vervolgens verschillende labels toegevoegd. De Label Mapping

is niet zo speciaal en zorgt ervoor dat bij de relatie een label met de naam komt testaan, in dit geval ’typify’. De twee Feature Label Mappings hebben een groterbelang en staan in voor het opslaan van de multipliciteiten.


Figuur 3.5: Typify relatie Link Mapping

Figuur 3.6 p.19 toont tot slot nog een voorbeeld van een typify verbinding tusseneen EconomicResource en een EconomicResourceType. Indien oneindig is ge-wenst als grens, wordt dit ingegeven als ’-1’. -1 Is de waarde die wordt bijgehoudenmaar het diagram toont een ’*’.

Figuur 3.6: Typify relatie met multipliciteiten


3.5 Opmerkingen

Hieronder worden enkele interessante weetjes, problemen aangehaald die handigkunnen zijn bij een volgende studie:

∙ Indien in het diagram (REA model) linksboven tekst verschijnt die nergensaan vasthangt , wil dit zeggen dat desbetreffende tekst niet (goed) gelinkt isin het Mapping Model.

∙ In het Tooling Definition Model kunnen afbeeldingen worden toegewezenaan de verschillende elementen. Hierbij is het noodzakelijk zowel een smallals een large afbeelding toe te voegen. Standaard krijgt ieder element eenafbeelding toegewezen. Daarnaast kunnen ook eigen afbeeldingen wordentoegevoegd. De standaard afbeeldingen in de icons map van REAModel.edit(gegenereerde code uit het Domain Generator Model) worden dan over-schreven.

∙ Als het openen van een model diagram problemen geeft, is het aangewezente controleren of Eclipse de juiste grafische editor gebruikt om het betref-fende diagram te openen.

∙ Het publiceren van de plugin kan naast een zip-bestand ook gebeuren via eenUpdate Site6. Het werken met de Update Site kan soms problemen opleverenwaardoor gekozen is voor een zip-bestand.

∙ Met EMF kan aan Model Driven Development (MDD) gedaan worden. Uithet ecore metamodel wordt heel wat code gegenereerd. Echter na verschil-lende kleine wijzigingen, waarbij de code telkens opnieuw gegenereerd is,treden soms kleine onnauwkeurigheden op met fouten tot gevolg. Dit kanopgelost worden door de gegenereerde code volledig te verwijderen en op-nieuw te laten genereren. Gezien deze werkwijze niet zo handig is bij eenversiebeheersysteem (bijvoorbeeld Subversion) is het gebruik hiervan naenige tijd achterwege gelaten. Een ’oude’ back-up is even handig!

∙ ...

6Werkwijze zie Vermeiren (2007-2008)

Hoofdstuk 4

Vergelijking REA metamodel vs

REA UML Profile

Nadat in vorig hoofdstuk de eerste grote doelstelling van deze thesis is besproken,wordt nu verder ingegaan op de vergelijking tussen enerzijds REA metamodel enanderzijds REA UML Profile. Alvorens over te gaan op de vergelijking, komenbeide nog aan bod. REA metamodel wordt kort besproken met enkele voorbeeldengezien het feit dat dit al verschillende malen aan bod is gekomen. Bij REA UMLProfile wordt wat langer stilgestaan en komen naast enkele voorbeelden ook dewerkwijze aan bod.

4.1 REA metamodel

In Hoofdstuk 2 is uitgelegd hoe een REA model kan worden aangemaakt in dereamodeller plugin. In deze sectie zullen enkele modellen worden bekeken. Zoalsin Vermeiren (2007-2008) wordt het bookshop model (zie bijlage B) opgesteld inde plugin. Figuren 4.1 (p.22) en 4.2 (p.23) geven het bookshop model weer in deplugin van respectievelijk vorig en dit jaar. Enkele van de gemaakte wijzigingen(verwijderen van de pijlpunten, gebruik van kleuren en toevoegen van multiplici-teiten) zijn hierin duidelijk zichtbaar.

21


Figuur 4.1: REA model bookshop Vermeiren (2007-2008)


Figuur 4.2: REA model bookshop


4.2 REA UML Profile

Naast het aanmaken van een REA model via de ontwikkelde diagram editor, kandit ook door het toepassen van een UML Profile aan een UML klassendiagram. Hettot stand komen van het model verloopt op een andere manier en wordt hieronderbesproken.

4.2.1 Profile

Alvorens aan de slag te gaan en de werkwijze uit te leggen, moet het REA UMLProfile beschikbaar zijn. Net zoals bij de ontwikkeling van de plugin is er voor deontwikkeling van het profiel een project site opgestart bij Google. Bij de down-load sectie van onderstaande URL kan de laatste nieuwe versie van het REA UMLProfile teruggevonden worden.

http://code.google.com/p/reaprofile/

4.2.2 Werkwijze

Een REA model aanmaken via het REA UML Profile verloopt in twee fases. Inde eerste fase moet een UML klassendiagram model worden opgesteld van het temodelleren gegeven. Vervolgens moet bij dit model het REA UML Profile wordengeladen en toegepast. De laatste fase is het toevoegen van de stereotypes aan deverschillende elementen uit het UML klassendiagram.

Werkwijze in Eclipse1:

∙ Nieuw project aanmakenFile >> New >> Project >> General Project

∙ UML klassendiagram aanmakenFile >> New >> Other >> UML 2.1 Diagrams >> Class DiagramHierna worden 2 bestanden verkregen: .uml en .umlclass (=grafische voor-stelling)

∙ UML klassendiagram opbouwen2 (Eenvoudig via de grafische editor)

1Eclipse 3.5 Galileo modeling versie2Handleidingen te vinden op de Eclipse site.

http://code.google.com/p/reaprofile/


∙ UML Profile in de projectmap kopieren en inladen3

.uml bestand >> Package selecteren >> UML Editor (zie figuur 4.3) >>

Load Resource >> UML Profile selecteren

Figuur 4.3: UML Editor Menu

∙ UML Profile toevoegen aan ons model.uml bestand >> Package selecteren >> UML Editor >> Package >>

Apply Profile >> REAprofile selecteren >> Add >> OK

∙ Stereotypes toevoegenElement selecteren in het grafische UML model >> rechts klikken >> Ap-ply Stereotype >> gewenste stereotype selecteren

Figuur 4.4: Stereotype toevoegen

3Bij de laatste nieuwe versie van het REA UML Profile moet naast het profiel ook nog een tweedebestand (OntoUML.profile.uml) worden ingeladen.


4.2.3 Voorbeeld

Net zoals in sectie 4.1 wordt het voorbeeld van de bookshop gemodelleerd. Figu-ren 4.5 (p.27) en 4.6 (p.28) geven het model weer respectievelijk voor en na hettoepassen van het UML Profile. Bij de grafische weergave van het klassendiagramwordt de multipliciteit ’1..1’ niet weergegeven.

4.2.4 Controle

Naast het aanmaken van een model, is het belangrijk om te controleren of het aan-gemaakte model voldoet aan de vooropgestelde regels (toegevoegd via OCL be-perkingen). Er wordt ook gesproken over het valideren van een model. In Eclipsekan men valideren door het bestand te selecteren, rechts klikken en daarna voorValidate te kiezen. Hierna komt een pop-up tevoorschijn met de validatie resulta-ten (zie figuur 4.7 p.29). Deze functie blijkt echter niet te werken aangezien allegecontroleerde modellen foutloos blijken, zelfs bij bewust foute modellen.

De validatie van een UML model met hierop het REA UML Profile toegepastkan echter ook manueel worden uitgevoerd. Deze werkwijze is natuurlijk tijd-rovend. Om te controleren of het model voldoet aan de opgestelde regels, is hetvan belang alle OCL beperkingen te controleren. De OCL beperkingen kunnengecontroleerd worden in de ’Interactive OCL Console’. Deze console is stan-daard niet bijgevoegd en moet nog worden toegevoegd. Na het toevoegen van vol-gende update site (http://download.eclipse.org/modeling/mdt/updates/releases/), bij de installatie van nieuwe software, kan gekozen worden voorMDT OCL SDK. Na het installeren van enkele pakketten en het herstarten vanEclipse kan de Interactive OCL Console worden gebruikt. (zie figuur 4.8)

http://download.eclipse.org/modeling/mdt/updates/releases/

http://download.eclipse.org/modeling/mdt/updates/releases/


Figuur 4.5: Bookshop klassendiagram


Figuur 4.6: Bookshop REA model (via UML Profile)


Figuur 4.7: Pop-up met validatie resultaten

Figuur 4.8: Interactive OCL Console

4.3 REA metamodel vs REA UML Profile

4.3.1 Situering

Bij softwareontwikkeling wordt de laatste jaren meer en meer gebruik gemaakt vangegenereerde code. Een belangrijke reden hiervoor is het feit dat software meestalgebonden is aan een welbepaald systeem en bij een systeemwissel de software op-nieuw vanaf de grond moet worden opgebouwd. De oplossing hiervoor is ModelDriven Architecture (MDA). Hierbij wordt de specificatie van de systeemfunctio-naliteiten gescheiden van de specificatie van de implementatie van de functiona-liteiten op een welbepaald systeem. Zo ontstaan twee types modellen: PlatformIndependent Model (PIM) en Platform Specific Model (PSM). Daarbij kan wordenuitgegaan vanuit verschillende invalshoeken. Het artikel van Dalgarno & Fowler(Summer 2008) vergelijkt twee belangrijke uitgangspunten:

∙ UML voor programma modellering als onderdeel van Model Driven Archi-tecture (MDA)

∙ Domain Specific Language (DSL)


4.3.2 UML vs Domain Specific Languages

Dalgarno & Fowler (Summer 2008) halen twee belangrijke problemen aan bij hetgebruik van UML Profile om nieuwe modelleertalen te definieren:

1. Met de huidige UML Tools is het meestal moeilijk om delen van UML dieniet relevant zijn te verwijderen.

2. Alle diagramtypes die worden ontwikkeld, hebben beperkingen die geba-seerd zijn op de UML semantiek.

Deze problemen zijn niet aanwezig bij DSL gezien dit vanaf de grond af wordtopgebouwd. Een groot voordeel van UML Profile is dan weer de relatief lage kostvoor de aanmaak van een nieuw profiel.

Wanneer de Domain Specific Language wordt besproken in Dalgarno & Fowler(Summer 2008), komt als groot voordeel naar voor dat bij de DSL benaderinghet model kan worden beperkt tot de domein semantiek. De validatie van eenmodel is hierdoor ook gemakkelijker. Daarnaast is er de jongste tijd een stijgendeondersteuning van DSL tools, o.a. door Microsoft, Eclipse Modeling Framework,. . . .

Welke technologie moet worden gekozen?

’Welke technologie moet worden gekozen?’ Op deze vraag wordt in het artikelgeen duidelijk antwoord gegeven. De keuze moet gemaakt worden door de pro-grammeur. Daarbij moet rekening worden gehouden met de reeds bestaande be-drijfsprocessen, wegen de kosten op tegen de baten (bijvoorbeeld bij real-time sys-temen is reeds veel geınvesteerd),. . . Daarnaast kunnen beide technologieen wor-den gecombineerd.

Tot slot is de verwachting dat DSL implementaties meer zullen worden gebruikt,ten nadele van UML.

4.3.3 Voor- en nadelen in functie van het gebruikersgemak

Nadat voorbeelden en werkwijze van respectievelijk REA metamodel en REAUML Profile aan bod zijn gekomen, is het nu tijd voor een persoonlijke verge-lijking. Tabellen 4.1 en 4.2 geven een opsomming van de voor- en nadelen van


beide. Bij het vergelijken van REA metamodel en REA UML Profile wordt ge-keken vanuit het standpunt van het gebruikersgemak (werkwijze, validatie, over-draagbaarheid, . . . ). Dit omwille van het feit dat het profiel niet zelf ontwikkeld is.Daardoor is er geen goed zicht op de eventuele moeilijkheden en/of tekortkomin-gen. Volgende vragen worden in gedachten gehouden bij de vergelijking:

∙ Kan het model vlot worden aangemaakt?

∙ Voldoet het model aan de regels?

∙ Is het model overdraagbaar naar andere omgevingen?

∙ . . .

Voordelen

REA metamodel REA UML Profile

Voordelen

- Direct modelleren volgens de REAstandaard- Directe controle op REA standaard

- UML klassendiagram is goed ge-kend =>toetredingsbarriere kleiner- Tool voor UML klassendiagram be-staat reeds en gegenereerde modellenkunnen redelijk makkelijk in anderetools worden geımporteerd.- Doordat gestart wordt vanuit eenUML klassendiagram kunnen zelfs re-laties worden weergegeven die mis-schien nog niet gespecificeerd zijn inhet profiel.

Tabel 4.1: REA metamodel vs REA UML Profile (voordelen)


Nadelen

REA metamodel REA UML Profile

Nadelen

- Doordat de plugin zelf is ontwikkeld,kan het aangemaakte model slechtsmet de ontwikkelde plugin worden ge-opend.- (Eclipse) Labels van de multiplicitei-ten worden niet zo goed geplaatst invergelijking met de labels in het UMLklassendiagram.

- Dubbel werk: eerst klassendiagrammaken en daarna nog eens het UMLProfile toepassen.- In het UML klassendiagram kun-nen modellen ontstaan die niet vol-doen aan de eigenlijke model seman-tiek. Dit wordt pas opgemerkt bij hettoevoegen van de stereotypes (con-trole via OCL beperkingen).- Bij het toevoegen van stereotypeskan het voorkomen dat elementen uithet klassendiagram worden vergeten.(in grafische editor)- (Eclipse) Multipliciteiten aanpassenvan het UML klassendiagram is lastig

Tabel 4.2: REA metamodel vs REA UML Profile (nadelen)

Hoofdstuk 5

Besluit

In de vorige hoofdstukken zijn de verschillende delen van de thesis aan bod ge-komen. Dit laatste afsluitende hoofdstuk trekt een besluit en geeft richtingen voorverder onderzoek, nieuwe uitbreidingen,. . .

5.1 Conclusie

Net zoals er twee verschillende hoofdstukken zijn voor de belangrijke doelstellin-gen, wordt deze conclusie ook in twee verdeeld. Sectie 5.1.1 handelt over de uit-breiding terwijl sectie 5.1.2 de vergelijking tussen REA metamodel en REA UMLProfile bespreekt.

5.1.1 Uitbreiding reamodeller plugin

De plugin is zowel uitwendig als inwendig aangepast. Uitwendig is het gebruik vankleuren zichtbaar, zijn de pijlpunten verdwenen, worden multipliciteiten op de rela-ties tussen de verschillende elementen weergegeven,. . . (voorbeelden zie hoofdstuk3). Om multipliciteiten weer te geven op een relatie heeft de plugin inwendig ookeen grote verandering ondergaan. Het ecore metamodel, waarop de plugin bouwt,is grondig vernieuwd. Waar de verbindingen in het metamodel van Vermeiren(2007-2008) nog EReferences waren, is er overgegaan op EClasses met attributen.De multipliciteiten worden bijgehouden in het betreffende attribuut. Als gevolgvan het nieuwe ecore metamodel is het Mapping Model volledig vernieuwd. Naastde vernieuwing van het model zijn er ook enkele nieuwe verbindingen toegevoegd(linkage, custody,. . . ) die kunnen worden weergegeven. Al deze aanpassingen

33

5 Besluit 34

zorgen ervoor dat een REA model beter kan worden aangemaakt en weergegeven.

5.1.2 REA metamodel vs REA UML Profile

De tweede belangrijke doelstelling betrof een vergelijking van REA metamodel enREA UML Profile voor het aanmaken van een REA model. Beide methodes zijnin de loop van de thesis aan bod gekomen en getest waarna een vergelijking is ge-maakt (sectie 5.1.2). Er is een vergelijking uit de literatuur naast een persoonlijkevergelijking op het gebied van het gebruikersgemak (werkwijze, validatie, over-draagbaarheid, . . . ).

Indien een persoonlijke keuze moet worden gemaakt tussen beide alternatieven,zal wellicht gekozen worden voor het REA UML Profile. De belangrijkste redenenhiervoor zijn:

∙ Geen grote verschillen met UML

∙ Mindere kost (Dalgarno & Fowler, Summer 2008)

Ondertussen is echter enige ervaring opgedaan met REA metamodel waardoorhierop ook kan worden verder gebouwd! In de volgende sectie worden enkelerichtingen aangegeven voor verder onderzoek.

5.2 Uitbreidingen

Het REA metamodel is in deze thesis reeds uitgebreid maar dit kan nog steedsworden aangepast, uitgebreid, verfijnd, . . . zodat er nog mogelijkheden zijn voortoekomstig onderzoek. Enkele uitbreidingen die kunnen onderzocht worden zijnde volgende:

∙ Het ecore metamodel van de reamodeller kan nog verder worden uitgebreidzodat bijvoorbeeld aan een Economic Resource Type, Economic Agent,. . . attributen kunnen worden toegevoegd.

∙ Daarnaast bevat de REA ontologie nog verbindingen die nog niet kunnenworden weergegeven met de reamodeller.

∙ Het gebruik van OCL beperkingen voor en nog betere controle op de seman-tiek.

5 Besluit 35

∙ Wanneer het belang van de grafische voorstelling en het gebruikersgemaktoeneemt, kunnen hiervoor nog verschillende verbeteringen worden doorge-voerd. (Bij de vergelijking van REA metamodel en UML Profile bleek datde labels (voor o.a. multipliciteiten) in de UML Eclipse editor beter werdengeplaatst en minder gevoelig waren aan het verschuiven van elementen.)

∙ . . .

Een recent verschenen boek, Eclipse Modeling Project: A Domain-Specific Lan-guage (DSL) Toolkit - Richard C. Gronback, kan nog een beter zicht geven opGMF en de verschillende mogelijkheden.

Bibliografie

M. Dalgarno & M. Fowler (Summer 2008). Uml vs. domain-specific langu-ages. http://www.methodsandtools.com/archive/archive.php?id=71.Methods & Tools.

F. Gailly (2008). Operationalization of Business Ontologies: Representation, For-malization and Application. Ph.D. thesis, Faculty of Economics and BusinessAdministration of Ghent University.

F. Gailly & G. Poels, editors (2007). Ontology-Driven Business Modelling: Impro-ving the Conceptual Representation of the REA Ontology. Faculty of Economicsand Business Administration, Ghent University, Belgium.

G. Geerts & W. E. McCarthy, editors (2000). The Ontological Foundation of REAEnterprise Informaiton Systems. The University of Delaware and Michigan StateUniversity.

G. L. Geertsa & W. E. McCarthy (2002). An ontological analysis of the economicprimitives of the extended-rea enterprise information architecture. InternationalJournal of Accounting Information Systems 3, pp. 1–16.

The Eclipse Foundation (2009). http://www.eclipse.org/.

T. Vermeiren (2007-2008). Ontwikkeling van een tool voor ontologie-gestuurdebedrijfsmodellering. Master’s thesis, Universiteit Gent - Faculteit Economie enBedrijfskunde.

36

http://www.methodsandtools.com/archive/archive.php?id=71

http://www.eclipse.org/

Bijlage A

REA metamodel Tim Vermeiren

Figuur A.1: REA metamodel Tim Vermeiren

37

Bijlage B

REA model bookshop

Figuur B.1: REA model bookshop Gailly & Poels (2007)

38

UNIVERSITEIT GENT FACULTEIT ECONOMIE EN...

Documents

Transcript of UNIVERSITEIT GENT FACULTEIT ECONOMIE EN...