HET GEBRUIK VAN DOMEINSPECIFIEKE

Transcriptie

1 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 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

2 PERMISSION Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Wouter Verbeure

3 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 Poels van de vakgroep Beleidsinformatica en Operationeel Beheer, faculteit Economie en Bedrijfskunde van de Universiteit Gent bedanken. Zij hebben de begeleiding van deze thesis op zich genomen. Verder bedank ik mijn ouders die mij de mogelijkheid hebben gegeven om een bijkomende opleiding bedrijfseconomie te volgen. Tenslotte wil ik iedereen bedanken die mee heeft geholpen bij het verwezenlijken van dit eindwerk. De welgekomen aanmoedigingen en steun tijdens de ontwikkeling ervan deden goed. Wouter, augustus iii

4 Inhoudsopgave Woord vooraf Inhoudsopgave Lijst van figuren Lijst van tabellen Lijst van symbolen en acroniemen iii iv vi viii ix 1 Inleiding Situering Basis Doelstelling Uitbreiding programma REA metamodel vs REA UML Profile Overzicht Opdrachtgever Reamodeller Eclipse Plugin Google Code Ontwikkeling plugin Reamodeller Eclipse-omgeving Waar kan de plugin gevonden worden? iv

5 2.3.3 Hoe kan een eerste model gemaakt worden? Uitbreiding programma Pijlpunten verwijderen Kleur toevoegen Nieuwe relaties leggen Multipliciteiten toevoegen Ecore metamodel aanpassen Mapping model vernieuwen Opmerkingen Vergelijking REA metamodel vs REA UML Profile REA metamodel REA UML Profile Profile Werkwijze Voorbeeld Controle REA metamodel vs REA UML Profile Situering UML vs Domain Specific Languages Voor- en nadelen in functie van het gebruikersgemak Besluit Conclusie Uitbreiding reamodeller plugin REA metamodel vs REA UML Profile Uitbreidingen Bibliografie 36 A REA metamodel Tim Vermeiren 37 B REA model bookshop 38

6 Lijst van figuren 1.1 Logo Universiteit Gent GMF Dashboard bij GMF project Logo Eclipse Downloadpagina van de plugin Aanmaak REA model Vastleggen modelnaam Vastleggen modeldiagramnaam REA model Achtergrondkleur EconomicResourceTypeFigure Gebruik van kleuren in het diagram OCL beperking in Mapping Model Deel nieuw ecore metamodel Typify relatie Link Mapping Typify relatie met multipliciteiten REA model bookshop Vermeiren ( ) REA model bookshop UML Editor Menu Stereotype toevoegen Bookshop klassendiagram Bookshop REA model (via UML Profile) Pop-up met validatie resultaten vi

7 4.8 Interactive OCL Console A.1 REA metamodel Tim Vermeiren B.1 REA model bookshop Gailly & Poels (2007)

8 Lijst van tabellen 1.1 Basis REA concepten Kleurencombinatie REA model Toegevoegde relaties REA metamodel vs REA UML Profile (voordelen) REA metamodel vs REA UML Profile (nadelen) viii

9 Lijst van symbolen en acroniemen Symbolen R E A C Resource Event Agent Commitment Acroniemen REA EMF GMF UML GUI MDD MDA PIM PSM DSL DSM OCL SDK Resources Events Agents Eclipse Modeling Framework Graphical Modeling Framework Unified Modeling Language Graphical User Interface Model Driven Development Model Driven Architecture Platform Independent Model Platform Specific Model Domain Specific Language Domain Specific Modeling Object Constraint Language Software Development Kit ix

10 Hoofdstuk 1 Inleiding Het modelleren van bedrijfsprocessen, kortweg bedrijfsmodellering, is geen nieuwigheid. 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 overzicht te hebben over het reilen en zeilen zowel binnen als buiten het bedrijf. Daarbij is het de bedoeling kennis op te doen en sneller te kunnen inspelen op nieuwe tendensen, vragen van klanten, Situering De afkorting REA staat voor de 3 belangrijke bouwstenen van het model, namelijk: Resources, Events en Agents. Deze basis REA concepten worden in tabel 1.1 beschreven 1. Het ontstaan van de REA ontologie gaat terug tot het begin van de jaren 80. William E. McCarthy heeft dit ontworpen met als hoofdbedoeling het modelleren van accounting systemen. Door de jaren heen is dit geëvolueerd en wordt REA ook gebruikt voor bedrijfsmodellering. Zoals bij elke taal horen bij REA regels. (Geerts & McCarthy, 2000): Er worden 3 axioma s geformuleerd 1. Op zijn minst één inflow event en één outflow event behoren tot een economic 1 Vrije vertaling van de beschrijving in Gailly & Poels (2007) 1

11 1 Inleiding 2 Economic Resource Economic Agent Economic Event Commitment Een schaars goed, bruikbaar voor economic agent, dat gebruikers van bedrijfsapplicaties willen plannen, volgen en controleren Individu of organisatie die de mogelijkheid heeft om economic resources te controleren of in staat is deze rechten te verkrijgen Een stijging of daling in de waarde van een economic resource Verbintenis van een economic agent om een economic event uit te voeren Tabel 1.1: Basis REA concepten resource 2. Elk event dat een outflow veroorzaakt moet via een duality relation gekoppeld worden met een event dat een inflow veroorzaakt. Dit zowel in de ene als in de andere richting. 3. Elk economic event moet zowel een provide als een receive relatie hebben met een economic agent. Door de evolutie van REA bestaan er verschillende varianten. In deze thesis wordt de variant gebruikt die beschreven staat in Gailly & Poels (2007). 1.2 Basis Deze masterthesis bouwt verder op de thesis van Vermeiren ( ). Die masterproef geeft een korte bespreking rond bedrijfsmodellering waarna verder wordt ingegaan op het REA metamodel. Het hoofddoel bestaat er echter uit om een programma, tool te schrijven die REA modellen kan aanmaken. Om het programma te ontwikkelen wordt gebruik gemaakt van verschillende frameworks (Eclipse, EMF, GMF,... ). De belangrijkste onderdelen worden in het vervolg van deze thesis kort aangehaald. Voor een meer grondige beschrijving wordt verwezen naar Vermeiren ( ) of kan de betreffende literatuur worden geraadpleegd.

12 1 Inleiding 3 De ontwikkeling van de tool vindt plaats in Eclipse 2, dit is een open source platform dat gebruik maakt van de Java Virtual Machine. Het programma, de tool is een plugin die kan worden toegevoegd aan de Eclipse-omgeving. Voor de plugin wordt eerst en vooral een ecore metamodel aangemaakt, voor de beschrijving van het REA metamodel. Dit ecore metamodel kan vervolgens verder verwerkt worden in een GMF project. Via GMF (Graphical Modeling Framework) kan, zonder duizenden lijnen code te moeten schrijven, een mooie grafische interface verkregen worden voor de plugin. De werkwijze van een GMF project wordt verder in sectie 2.2 p.7 besproken. 1.3 Doelstelling De thesis van dit jaar bouwt verder, zoals al eerder aangehaald, op het reeds geleverde werk van Vermeiren ( ). De doelstelling bestaat nu echter uit twee delen: 1. Uitbreiding van de bestaande tool 2. Vergelijking REA metamodel met REA UML Profile Uitbreiding programma De reeds bestaande tool kan al een basis REA model aanmaken. Nu is het de bedoeling om dit basismodel uit te breiden met enkele nieuwe relaties. Daarnaast is het de bedoeling gebruik te maken van kleuren voor de verschillende lagen in het diagram; operational layer (groen), commitment layer (paars) en knowledge layer (geel). De belangrijkste toevoeging is echter het weergeven van de multipliciteiten op een relatie REA metamodel vs REA UML Profile Naast de uitbreiding van de plugin vormt zich een tweede doelstelling. Het is de bedoeling een vergelijking te maken van de manier waarop een REA model wordt aangemaakt. Deze aanmaak van een REA model kan worden verwezenlijkt op twee verschillende manieren: 1. Via de eigen geprogrammeerde tool 2 The Eclipse Foundation,

13 1 Inleiding 4 2. Via een UML profile 3 Elke werkwijze heeft zijn eigen voor- en nadelen die verder in deze thesis worden aangehaald (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 de plugin een belangrijk onderdeel van de thesis vormt, wordt hier een apart hoofdstuk aan gewijd. Zaken die aan bod komen zijn: Ontwikkeling van de plugin, Waar kan de plugin gevonden worden?, Hoe kan de plugin worden opgestart?,... Hoofdstuk 3 beschrijft meer in detail de uitbreidingen en aanpassingen die aan het programma zijn gedaan. Hierin worden ook meer technische termen aangehaald. Tot slot van het hoofdstuk worden nog enkele opmerkingen gegeven die handig kunnen zijn bij een volgende studie. Hoofdstuk 4 behandelt de tweede belangrijke doelstelling van deze thesis, namelijk de vergelijking tussen de twee verschillende manieren van werken om een REA model aan te maken. Gezien REA UML Profile nog niet aan bod kwam, wordt dit grondig 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 bod voor verdere studie van het onderwerp. 3 zie ook Gailly (2008, Hoofdstuk 5)

14 1 Inleiding Opdrachtgever De opdrachtgever voor deze masterthesis is de vakgroep Beleidsinformatica en Operationeel Beheer, faculteit Economie en Bedrijfskunde van de Universiteit Gent (Tweekerkenstraat 2 B-9000 GENT). Figuur 1.1: Logo Universiteit Gent

15 Hoofdstuk 2 Reamodeller Eclipse Plugin In het tot stand komen van deze thesis vormt de ontwikkelde plugin een belangrijke factor. Vandaar dat hieraan ook een apart hoofdstuk wordt gewijd. Om de plugin vlot toegankelijk te maken voor iedereen is een Google project aangemaakt (zie sectie 2.1). Het vervolg van het hoofdstuk handelt over de ontwikkeling van de plugin, de installatie, Google Code Google Code 1 biedt een dienst aan waarbij er de mogelijkheid is om een project te hosten bij Google. De projecteigenaar geeft hierbij aan onder welke licentie het project wordt uitgegeven. Dit project is uitgegeven onder de Eclipse Public License 1.0. Naast de licentie worden ook labels toegekend om het programma te karakteriseren en zoekopdrachten te verbeteren. De projecteigenaar kan verder personen toelaten die meehelpen bij de verwezenlijking van het project. Google Code biedt daarvoor onder andere een versiebeheersysteem aan zodat meerdere ontwikkelaars wijzigingen kunnen aanbrengen aan dezelfde bestanden. Een voorbeeld van een dergelijk versiebeheersysteem is Subversion 2. Naast het versiebeheersysteem kunnen de medewerkers op de site aangeven welke taken nog moeten worden uitgevoerd, welke problemen reeds gerepareerd zijn (al dan niet geverifieerd),... Vervolgens kunnen aan het project downloads (bijvoorbeeld zip-bestand van de plugin) worden toegevoegd. Tot slot kunnen wiki-documenten worden aangemaakt waarop installatietips, howto s,... worden weergegeven

16 2 Reamodeller Eclipse Plugin Ontwikkeling plugin Voor de ontwikkeling van de plugin wordt gebruik gemaakt van reeds bestaande frameworks. Het Graphical Modeling Framework (GMF) is hier het belangrijkste framework. GMF is onlangs ontwikkeld en staat in voor een gemakkelijkere koppeling van het Eclipse Modeling Framework (EMF) en Graphical Editing Framework (GEF). Bij een GMF project komen verschillende stappen en modellen kijken vooraleer de eigenlijke diagram editor wordt gecreëerd: Domain Model 3 & Domain Generator Model Het Domain Model is eigenlijk het ecore metamodel. Het ecore metamodel vormt de kern van EMF (onderliggend framework van GMF) en is een platvorm onafhankelijk model. Uit dit model wordt het genmodel gegenereerd dat de platform specifieke informatie bevat. Graphical Definition Model Het Graphical Definition Model bevat alle grafische elementen (zoals rechthoeken, cirkels, verbindingen, pijlpunten, labels,... ) die in het diagram kunnen voorkomen. Tooling Definition Model Het Tooling Definition Model bevat alle onderdelen van de palette (alle elementen die aan het model toegevoegd kunnen worden), extra knoppen in de toolbar, menu items, pop-up menu s, acties,.... Mapping Model Het Mapping Model vormt de link tussen Domain Model, Graphical Definition Model en Tooling Definition Model. Dit model is noodzakelijk om te bepalen welk element uit het domein model door welke grafische elementen wordt voorgesteld en met welke tool het kan worden aangemaakt. Diagram Editor Gen Model Het Diagram Editor Gen Model vormt de voorlaatste stap en is een transformatie van voorgaande modellen. Hierna kan de noodzakelijke code voor de grafische editor plugin worden gegenereerd. Bij de aanmaak van een GMF project kan gekozen worden om via het GMF Dashboard te werken (zie figuur 2.1). Dit dashboard zorgt voor een overzichtelijk geheel in de te doorlopen stappen. 3 Beschrijving van de verschillende modellen van een GMF project uit Vermeiren ( )

17 2 Reamodeller Eclipse Plugin 8 Tot slot valt nog op te merken dat bij een model, gecreëerd in een GMF editor, twee verschillende bestanden voorkomen. Naast.model is er een.model diagram bestand. Het.model bestand bevat alle domein informatie terwijl.model diagram de grafische informatie bevat. Figuur 2.1: GMF Dashboard bij GMF project 2.3 Reamodeller 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 plugin gebruik maakt van verschillende andere plugins moeten deze allemaal aanwezig zijn in Eclipse. Deze plugins kunnen één voor één worden toegevoegd aan de basis Eclipse omgeving. Hieronder worden de benodigde onderdelen weergegeven met hun minimale vereiste versie: Eclipse 3.4 Ganymede (Op het moment van schrijven is Eclipse 3.5 Galileo verkrijgbaar) Eclipse Modeling Framework EMF (minimaal EMF nieuwste EMF 2.5.0) Object Constraint Language (OCL) 2.0

18 2 Reamodeller Eclipse Plugin 9 Graphical Editing Framework (GEF) Models (minimaal GEF nieuwste GEF 3.5.0) Graphical Modeling Framework SDK (minimaal GMF nieuwste GMF 2.2.0) Een gemakkelijkere oplossing, zonder het zelf toevoegen van plugins, is het downloaden van de Eclipse modeling version 4 met bovenstaande plugins reeds ingevoegd. Figuur 2.2: Logo Eclipse Waar kan de plugin gevonden worden? Het Google project kan teruggevonden worden via onderstaande URL: Op bovenvermelde site is bij downloads het zip-bestand (zie figuur 2.3 p. 9) te vinden met de plugin. Deze plugin moet worden uitgepakt in de home directory van Eclipse. Figuur 2.3: Downloadpagina van de plugin 4 >> Downloads >> All-In-One Package

19 2 Reamodeller Eclipse Plugin Hoe kan een eerste model gemaakt worden? 1. Aanmaken project File >> 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 projectsite.

20 2 Reamodeller Eclipse Plugin 11 Figuur 2.5: Vastleggen modelnaam Figuur 2.6: Vastleggen modeldiagramnaam

21 2 Reamodeller Eclipse Plugin 12 Figuur 2.7: REA model

22 Hoofdstuk 3 Uitbreiding programma Als eerste belangrijke doelstelling van deze thesis zal dit hoofdstuk handelen over de verwezenlijkte uitbreidingen aan de tool. De tool is een plugin die kan worden toegevoegd aan de Eclipse omgeving. Daarbij wordt gebruik gemaakt van andere plugins (GMF, EMF,... ). Om de plugin op te starten zijn die andere plugins noodzakelijk. Meer info hierover is terug te vinden in hoofdstuk 2. Handig bij het werken met EMF, GMF, Eclipse,... zijn de verschillende tutorials die beschikbaar zijn, o.a. via de Eclipse site. Na het doorlopen ervan wordt een goed beeld gevormd en kan zelf aan de slag worden gegaan. Daarnaast zijn er levendige nieuwsgroepen 1 waarin vragen kunnen worden gesteld aan andere (professionele) gebruikers. De effectieve uitbreidingen aan de plugin worden hieronder besproken. Daarbij horen enkele kleinere toevoegingen waaronder het toevoegen van kleuren, verwijderen van pijlpunten, leggen van nieuwe relaties,.... De grootste uitbreiding is het toevoegen van multipliciteiten, wat in sectie 3.4 wordt besproken. Tot slot van het hoofdstuk worden nog enkele opmerkingen gegeven die handig kunnen zijn bij een volgende studie. 3.1 Pijlpunten verwijderen Als eerste aanpassing wordt het verwijderen van de pijlpunten bekeken. Het Graphical Definition Model in het GMF project (.gmfgraph bestand) verzorgt de opmaak

23 3 Uitbreiding programma 14 van de elementen in het diagram. Dit model biedt dus de mogelijkheid om de pijlpunten 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 opmaak van de pijlpunt en kan aan het begin (Source Decoration) of einde (Target Decoration) van de verbinding worden toegevoegd. Zo kan een volle, enkele, dikke,... pijlpunt gekozen worden. Deze beschrijving gebeurt in de betreffende Figure Descriptor waaraan de verbinding is toegevoegd. Indien niets wordt gespecificeerd 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 automatische afleiding van het.gmfgraph bestand aan elke verbinding een pijlpunt wordt toegekend. 3.2 Kleur toevoegen Net zoals bij het verwijderen van de pijlpunten, geeft het Graphical Definition Model de mogelijkheid kleur toe te voegen aan de verschillende elementen in het diagram. De achtergrondkleur kan gekozen worden uit een lijst met constante kleuren ofwel door middel van de RGB 2 code. Figuur 3.1: Achtergrondkleur EconomicResourceTypeFigure Op figuur 3.1 p.14 wordt de eigenschap Background aan Rectangle EconomicRe- 2 Rood Groen Blauw

24 3 Uitbreiding programma 15 sourcetypefigure toegevoegd binnen de Figure Descriptor EconomicResourceTypeFigure. De toegekende waarde is yellow. Bij Rectangle IncrementCommitment- Figure (niet op de figuur) moet (255, 0, 255) als RGB-code worden gebruikt om de paarse kleur te bekomen. Tabel 3.1 geeft de kleurencombinatie voor de verschillende lagen in het diagram. Operational layer Commitment layer Knowledge layer Groen Paars Geel Tabel 3.1: Kleurencombinatie REA model Figuur 3.2 toont een deel van een diagram waarbij het gebruik van kleuren zichtbaar is. De versie van de plugin waarbij dit screenshot is genomen, dateert van voor het nieuwe ecore metamodel (zie verder, sectie p.17). Hierdoor hebben de verbindingen tussen de entiteiten nog een welbepaalde kleur gekregen. In de nieuwere versie is geen specifieke beschrijving meer voor de opmaak van een bepaalde verbinding. Er is slechts één opmaak voor alle verbindingen omwille van het feit dat de opmaak van de verschillende verbindingen quasi niet verschilt. Wanneer de kleur toch een belangrijke factor vormt, kan dit opgelost worden door opnieuw meerdere verbindingen - Polyline Connections - te beschrijven in het Graphical 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 afleiding van het.gmfgraph bestand uit het domeinmodel. Naarmate een beter overzicht

25 3 Uitbreiding programma 16 wordt gekregen van de modelleertaal, kunnen verschillende zaken vereenvoudigd worden. 3.3 Nieuwe relaties leggen De plugin bevat reeds heel wat relaties. Deze verbindingen kunnen echter nog worden uitgebreid 3 met linkage, custody,.... Tabel 3.2 geeft een overzicht tussen welke elementen 4 de nieuw toegevoegde verbindingen mogelijk zijn. Association Custody Linkage A-A A-R R-R Tabel 3.2: Toegevoegde relaties Het weergeven van de nieuwe relaties in de uiteindelijke reamodeller vereist enkele stappen binnen het GMF project: Domain Model: Aanwezig zijn van link in het ecore metamodel Graphical Model: Aanmaak van een label, een connection en de beschrijving van 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 beperkingen. De OCL beperking zorgt ervoor dat een recursieve relatie met betrekking tot één element niet mogelijk is. Verbindingen kunnen wel plaatsvinden tussen 2 verschillende 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. 3 Geertsa & McCarthy (2002) 4 A = Agent,... ; zie p.ix

26 3 Uitbreiding programma 17 Figuur 3.3: OCL beperking in Mapping Model 3.4 Multipliciteiten toevoegen Naast de hierboven vermelde kleinere wijzigingen, worden bij een relatie nu multipliciteiten opgeslagen. Om dit mogelijk te maken, was het noodzakelijk het ecore metamodel van het REA metamodel ingrijpend te veranderen. Hieronder worden de aanpassing van het ecore metamodel en de belangrijkste andere wijzigingen besproken Ecore metamodel aanpassen Het bestaande ecore metamodel uit Vermeiren ( ) (zie bijlage A p.37) moet een grondige aanpassing ondergaan. De relaties die zichtbaar zijn in het uiteindelijke REA model, worden in het oude ecore metamodel bijgehouden als EReferences. Hieraan kan echter geen extra info worden toegekend om bijvoorbeeld multipliciteiten toe te voegen. Om dit op te lossen is in het nieuwe 5 ecore metamodel gebruik gemaakt van een EClass als verbinding. Deze EClass moet wel opnieuw verbonden zijn via EReferences met de andere entiteiten. Belangrijk hierbij is dat de twee EReferences tussen de verbindingsklasse en de entiteitklasse als tegengestelde worden aangegeven bij de eigenschappen. Aan de EClass, die de verbinding voorstelt, kunnen attributen worden toegevoegd die de multipliciteiten van 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 een EconomicResource. Bijzonder hieraan is de plaats van de attributen voor het opslaan van de multipliciteiten. Normaal gezien wordt verwacht dat deze attributen aan Relation worden toegevoegd waardoor ze in de afgeleide klassen worden 5 Door de grote afmetingen van het nieuwe ecore metamodel is het handiger dit model te bekijken op computer in de Eclipse omgeving. Het ecore metamodel kan gevonden worden op de project site bij downloads.

27 3 Uitbreiding programma 18 Figuur 3.4: Deel nieuw ecore metamodel overgeërfd. Dit bleek in ecore niet mogelijk waardoor de attributen overal zijn toegevoegd (o.a. navraag op de Eclipse nieuwsgroep) Mapping model vernieuwen De veranderingen in het ecore metamodel brengen veel wijzigingen met zich mee in het Mapping Model zodat dit model vanaf nul opnieuw wordt opgebouwd. Om ervoor te zorgen dat de multipliciteiten goed worden weergegeven op een verbinding is het belangrijk de nodige labels aan te maken en deze op een correcte manier te verbinden in het Mapping Model (zie figuur 3.5 p.19). De Link Mapping zorgt ervoor dat de verbinding correct verloopt tussen de juiste elementen. Aan de Link Mapping 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 te staan, in dit geval typify. De twee Feature Label Mappings hebben een groter belang en staan in voor het opslaan van de multipliciteiten.

28 3 Uitbreiding programma 19 Figuur 3.5: Typify relatie Link Mapping Figuur 3.6 p.19 toont tot slot nog een voorbeeld van een typify verbinding tussen een EconomicResource en een EconomicResourceType. Indien oneindig is gewenst als grens, wordt dit ingegeven als Is de waarde die wordt bijgehouden maar het diagram toont een *. Figuur 3.6: Typify relatie met multipliciteiten

29 3 Uitbreiding programma Opmerkingen Hieronder worden enkele interessante weetjes, problemen aangehaald die handig kunnen zijn bij een volgende studie: Indien in het diagram (REA model) linksboven tekst verschijnt die nergens aan vasthangt, wil dit zeggen dat desbetreffende tekst niet (goed) gelinkt is in het Mapping Model. In het Tooling Definition Model kunnen afbeeldingen worden toegewezen aan de verschillende elementen. Hierbij is het noodzakelijk zowel een small als een large afbeelding toe te voegen. Standaard krijgt ieder element een afbeelding toegewezen. Daarnaast kunnen ook eigen afbeeldingen worden toegevoegd. De standaard afbeeldingen in de icons map van REAModel.edit (gegenereerde code uit het Domain Generator Model) worden dan overschreven. Als het openen van een model diagram problemen geeft, is het aangewezen te controleren of Eclipse de juiste grafische editor gebruikt om het betreffende diagram te openen. Het publiceren van de plugin kan naast een zip-bestand ook gebeuren via een Update Site 6. Het werken met de Update Site kan soms problemen opleveren waardoor gekozen is voor een zip-bestand. Met EMF kan aan Model Driven Development (MDD) gedaan worden. Uit het ecore metamodel wordt heel wat code gegenereerd. Echter na verschillende kleine wijzigingen, waarbij de code telkens opnieuw gegenereerd is, treden soms kleine onnauwkeurigheden op met fouten tot gevolg. Dit kan opgelost worden door de gegenereerde code volledig te verwijderen en opnieuw te laten genereren. Gezien deze werkwijze niet zo handig is bij een versiebeheersysteem (bijvoorbeeld Subversion) is het gebruik hiervan na enige tijd achterwege gelaten. Een oude back-up is even handig!... 6 Werkwijze zie Vermeiren ( )

30 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 en anderzijds REA UML Profile. Alvorens over te gaan op de vergelijking, komen beide nog aan bod. REA metamodel wordt kort besproken met enkele voorbeelden gezien het feit dat dit al verschillende malen aan bod is gekomen. Bij REA UML Profile wordt wat langer stilgestaan en komen naast enkele voorbeelden ook de werkwijze aan bod. 4.1 REA metamodel In Hoofdstuk 2 is uitgelegd hoe een REA model kan worden aangemaakt in de reamodeller plugin. In deze sectie zullen enkele modellen worden bekeken. Zoals in Vermeiren ( ) wordt het bookshop model (zie bijlage B) opgesteld in de plugin. Figuren 4.1 (p.22) en 4.2 (p.23) geven het bookshop model weer in de plugin van respectievelijk vorig en dit jaar. Enkele van de gemaakte wijzigingen (verwijderen van de pijlpunten, gebruik van kleuren en toevoegen van multipliciteiten) zijn hierin duidelijk zichtbaar. 21

31 4 Vergelijking REA metamodel vs REA UML Profile 22 Figuur 4.1: REA model bookshop Vermeiren ( )

32 4 Vergelijking REA metamodel vs REA UML Profile 23 Figuur 4.2: REA model bookshop

33 4 Vergelijking REA metamodel vs REA UML Profile REA UML Profile Naast het aanmaken van een REA model via de ontwikkelde diagram editor, kan dit ook door het toepassen van een UML Profile aan een UML klassendiagram. Het tot stand komen van het model verloopt op een andere manier en wordt hieronder besproken Profile Alvorens aan de slag te gaan en de werkwijze uit te leggen, moet het REA UML Profile beschikbaar zijn. Net zoals bij de ontwikkeling van de plugin is er voor de ontwikkeling van het profiel een project site opgestart bij Google. Bij de download sectie van onderstaande URL kan de laatste nieuwe versie van het REA UML Profile teruggevonden worden Werkwijze Een REA model aanmaken via het REA UML Profile verloopt in twee fases. In de eerste fase moet een UML klassendiagram model worden opgesteld van het te modelleren gegeven. Vervolgens moet bij dit model het REA UML Profile worden geladen en toegepast. De laatste fase is het toevoegen van de stereotypes aan de verschillende elementen uit het UML klassendiagram. Werkwijze in Eclipse 1 : Nieuw project aanmaken File >> New >> Project >> General Project UML klassendiagram aanmaken File >> New >> Other >> UML 2.1 Diagrams >> Class Diagram Hierna worden 2 bestanden verkregen:.uml en.umlclass (=grafische voorstelling) UML klassendiagram opbouwen 2 (Eenvoudig via de grafische editor) 1 Eclipse 3.5 Galileo modeling versie 2 Handleidingen te vinden op de Eclipse site.

34 4 Vergelijking REA metamodel vs REA UML Profile 25 UML Profile in de projectmap kopiëren en inladen 3.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 toevoegen Element selecteren in het grafische UML model >> rechts klikken >> Apply Stereotype >> gewenste stereotype selecteren Figuur 4.4: Stereotype toevoegen 3 Bij de laatste nieuwe versie van het REA UML Profile moet naast het profiel ook nog een tweede bestand (OntoUML.profile.uml) worden ingeladen.

35 4 Vergelijking REA metamodel vs REA UML Profile Voorbeeld Net zoals in sectie 4.1 wordt het voorbeeld van de bookshop gemodelleerd. Figuren 4.5 (p.27) en 4.6 (p.28) geven het model weer respectievelijk voor en na het toepassen van het UML Profile. Bij de grafische weergave van het klassendiagram wordt de multipliciteit 1..1 niet weergegeven Controle Naast het aanmaken van een model, is het belangrijk om te controleren of het aangemaakte model voldoet aan de vooropgestelde regels (toegevoegd via OCL beperkingen). Er wordt ook gesproken over het valideren van een model. In Eclipse kan men valideren door het bestand te selecteren, rechts klikken en daarna voor Validate te kiezen. Hierna komt een pop-up tevoorschijn met de validatie resultaten (zie figuur 4.7 p.29). Deze functie blijkt echter niet te werken aangezien alle gecontroleerde modellen foutloos blijken, zelfs bij bewust foute modellen. De validatie van een UML model met hierop het REA UML Profile toegepast kan echter ook manueel worden uitgevoerd. Deze werkwijze is natuurlijk tijdrovend. Om te controleren of het model voldoet aan de opgestelde regels, is het van belang alle OCL beperkingen te controleren. De OCL beperkingen kunnen gecontroleerd worden in de Interactive OCL Console. Deze console is standaard niet bijgevoegd en moet nog worden toegevoegd. Na het toevoegen van volgende update site ( releases/), bij de installatie van nieuwe software, kan gekozen worden voor MDT OCL SDK. Na het installeren van enkele pakketten en het herstarten van Eclipse kan de Interactive OCL Console worden gebruikt. (zie figuur 4.8)

36 4 Vergelijking REA metamodel vs REA UML Profile 27 Figuur 4.5: Bookshop klassendiagram

37 4 Vergelijking REA metamodel vs REA UML Profile 28 Figuur 4.6: Bookshop REA model (via UML Profile)

38 4 Vergelijking REA metamodel vs REA UML Profile 29 Figuur 4.7: Pop-up met validatie resultaten Figuur 4.8: Interactive OCL Console 4.3 REA metamodel vs REA UML Profile Situering Bij softwareontwikkeling wordt de laatste jaren meer en meer gebruik gemaakt van gegenereerde code. Een belangrijke reden hiervoor is het feit dat software meestal gebonden is aan een welbepaald systeem en bij een systeemwissel de software opnieuw vanaf de grond moet worden opgebouwd. De oplossing hiervoor is Model Driven Architecture (MDA). Hierbij wordt de specificatie van de systeemfunctionaliteiten gescheiden van de specificatie van de implementatie van de functionaliteiten op een welbepaald systeem. Zo ontstaan twee types modellen: Platform Independent Model (PIM) en Platform Specific Model (PSM). Daarbij kan worden uitgegaan vanuit verschillende invalshoeken. Het artikel van Dalgarno & Fowler (Summer 2008) vergelijkt twee belangrijke uitgangspunten: UML voor programma modellering als onderdeel van Model Driven Architecture (MDA) Domain Specific Language (DSL)

39 4 Vergelijking REA metamodel vs REA UML Profile UML vs Domain Specific Languages Dalgarno & Fowler (Summer 2008) halen twee belangrijke problemen aan bij het gebruik van UML Profile om nieuwe modelleertalen te definiëren: 1. Met de huidige UML Tools is het meestal moeilijk om delen van UML die niet relevant zijn te verwijderen. 2. Alle diagramtypes die worden ontwikkeld, hebben beperkingen die gebaseerd zijn op de UML semantiek. Deze problemen zijn niet aanwezig bij DSL gezien dit vanaf de grond af wordt opgebouwd. Een groot voordeel van UML Profile is dan weer de relatief lage kost voor 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 benadering het model kan worden beperkt tot de domein semantiek. De validatie van een model is hierdoor ook gemakkelijker. Daarnaast is er de jongste tijd een stijgende ondersteuning 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 artikel geen duidelijk antwoord gegeven. De keuze moet gemaakt worden door de programmeur. Daarbij moet rekening worden gehouden met de reeds bestaande bedrijfsprocessen, wegen de kosten op tegen de baten (bijvoorbeeld bij real-time systemen is reeds veel geïnvesteerd),... Daarnaast kunnen beide technologieën worden gecombineerd. Tot slot is de verwachting dat DSL implementaties meer zullen worden gebruikt, ten nadele van UML Voor- en nadelen in functie van het gebruikersgemak Nadat voorbeelden en werkwijze van respectievelijk REA metamodel en REA UML Profile aan bod zijn gekomen, is het nu tijd voor een persoonlijke vergelijking. Tabellen 4.1 en 4.2 geven een opsomming van de voor- en nadelen van

40 4 Vergelijking REA metamodel vs REA UML Profile 31 beide. Bij het vergelijken van REA metamodel en REA UML Profile wordt gekeken vanuit het standpunt van het gebruikersgemak (werkwijze, validatie, overdraagbaarheid,... ). Dit omwille van het feit dat het profiel niet zelf ontwikkeld is. Daardoor is er geen goed zicht op de eventuele moeilijkheden en/of tekortkomingen. 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 Voordelen REA UML Profile - Direct modelleren volgens de REA standaard - Directe controle op REA standaard - UML klassendiagram is goed gekend =>toetredingsbarrière kleiner - Tool voor UML klassendiagram bestaat reeds en gegenereerde modellen kunnen redelijk makkelijk in andere tools worden geïmporteerd. - Doordat gestart wordt vanuit een UML klassendiagram kunnen zelfs relaties worden weergegeven die misschien nog niet gespecificeerd zijn in het profiel. Tabel 4.1: REA metamodel vs REA UML Profile (voordelen)

41 4 Vergelijking REA metamodel vs REA UML Profile 32 Nadelen REA metamodel REA UML Profile Nadelen - Dubbel werk: eerst klassendiagram maken en daarna nog eens het UML Profile toepassen. - In het UML klassendiagram kunnen modellen ontstaan die niet vol- - Doordat de plugin zelf is ontwikkeld, kan het aangemaakte model slechts doen aan de eigenlijke model semantiek. Dit wordt pas opgemerkt bij het met de ontwikkelde plugin worden geopend. toevoegen van de stereotypes (controle via OCL beperkingen). - (Eclipse) Labels van de multipliciteiten worden niet zo goed geplaatst in - Bij het toevoegen van stereotypes vergelijking met de labels in het UML kan het voorkomen dat elementen uit klassendiagram. het klassendiagram worden vergeten. (in grafische editor) - (Eclipse) Multipliciteiten aanpassen van het UML klassendiagram is lastig Tabel 4.2: REA metamodel vs REA UML Profile (nadelen)

42 Hoofdstuk 5 Besluit In de vorige hoofdstukken zijn de verschillende delen van de thesis aan bod gekomen. Dit laatste afsluitende hoofdstuk trekt een besluit en geeft richtingen voor verder onderzoek, nieuwe uitbreidingen, Conclusie Net zoals er twee verschillende hoofdstukken zijn voor de belangrijke doelstellingen, wordt deze conclusie ook in twee verdeeld. Sectie handelt over de uitbreiding terwijl sectie de vergelijking tussen REA metamodel en REA UML Profile bespreekt Uitbreiding reamodeller plugin De plugin is zowel uitwendig als inwendig aangepast. Uitwendig is het gebruik van kleuren zichtbaar, zijn de pijlpunten verdwenen, worden multipliciteiten op de relaties tussen de verschillende elementen weergegeven,... (voorbeelden zie hoofdstuk 3). Om multipliciteiten weer te geven op een relatie heeft de plugin inwendig ook een grote verandering ondergaan. Het ecore metamodel, waarop de plugin bouwt, is grondig vernieuwd. Waar de verbindingen in het metamodel van Vermeiren ( ) nog EReferences waren, is er overgegaan op EClasses met attributen. De multipliciteiten worden bijgehouden in het betreffende attribuut. Als gevolg van het nieuwe ecore metamodel is het Mapping Model volledig vernieuwd. Naast de vernieuwing van het model zijn er ook enkele nieuwe verbindingen toegevoegd (linkage, custody,... ) die kunnen worden weergegeven. Al deze aanpassingen 33

43 5 Besluit 34 zorgen ervoor dat een REA model beter kan worden aangemaakt en weergegeven REA metamodel vs REA UML Profile De tweede belangrijke doelstelling betrof een vergelijking van REA metamodel en REA UML Profile voor het aanmaken van een REA model. Beide methodes zijn in de loop van de thesis aan bod gekomen en getest waarna een vergelijking is gemaakt (sectie 5.1.2). Er is een vergelijking uit de literatuur naast een persoonlijke vergelijking op het gebied van het gebruikersgemak (werkwijze, validatie, overdraagbaarheid,... ). Indien een persoonlijke keuze moet worden gemaakt tussen beide alternatieven, zal wellicht gekozen worden voor het REA UML Profile. De belangrijkste redenen hiervoor zijn: Geen grote verschillen met UML Mindere kost (Dalgarno & Fowler, Summer 2008) Ondertussen is echter enige ervaring opgedaan met REA metamodel waardoor hierop ook kan worden verder gebouwd! In de volgende sectie worden enkele richtingen aangegeven voor verder onderzoek. 5.2 Uitbreidingen Het REA metamodel is in deze thesis reeds uitgebreid maar dit kan nog steeds worden aangepast, uitgebreid, verfijnd,... zodat er nog mogelijkheden zijn voor toekomstig onderzoek. Enkele uitbreidingen die kunnen onderzocht worden zijn de volgende: Het ecore metamodel van de reamodeller kan nog verder worden uitgebreid zodat bijvoorbeeld aan een Economic Resource Type, Economic Agent,... attributen kunnen worden toegevoegd. Daarnaast bevat de REA ontologie nog verbindingen die nog niet kunnen worden weergegeven met de reamodeller. Het gebruik van OCL beperkingen voor en nog betere controle op de semantiek.

44 5 Besluit 35 Wanneer het belang van de grafische voorstelling en het gebruikersgemak toeneemt, kunnen hiervoor nog verschillende verbeteringen worden doorgevoerd. (Bij de vergelijking van REA metamodel en UML Profile bleek dat de labels (voor o.a. multipliciteiten) in de UML Eclipse editor beter werden geplaatst en minder gevoelig waren aan het verschuiven van elementen.)... Een recent verschenen boek, Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit - Richard C. Gronback, kan nog een beter zicht geven op GMF en de verschillende mogelijkheden.

45 Bibliografie M. Dalgarno & M. Fowler (Summer 2008). Uml vs. domain-specific languages. Methods & Tools. F. Gailly (2008). Operationalization of Business Ontologies: Representation, Formalization and Application. Ph.D. thesis, Faculty of Economics and Business Administration of Ghent University. F. Gailly & G. Poels, editors (2007). Ontology-Driven Business Modelling: Improving the Conceptual Representation of the REA Ontology. Faculty of Economics and Business Administration, Ghent University, Belgium. G. Geerts & W. E. McCarthy, editors (2000). The Ontological Foundation of REA Enterprise Informaiton Systems. The University of Delaware and Michigan State University. G. L. Geertsa & W. E. McCarthy (2002). An ontological analysis of the economic primitives of the extended-rea enterprise information architecture. International Journal of Accounting Information Systems 3, pp The Eclipse Foundation (2009). T. Vermeiren ( ). Ontwikkeling van een tool voor ontologie-gestuurde bedrijfsmodellering. Master s thesis, Universiteit Gent - Faculteit Economie en Bedrijfskunde. 36

46 Bijlage A REA metamodel Tim Vermeiren Figuur A.1: REA metamodel Tim Vermeiren 37

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