Dankwoord - martes

Dankwoord
Ik wil alle mensen bedanken die rechtstreeks of onrechtstreeks hebben meegewerkt aan het tot
stand brengen van deze thesis.
In de eerste plaats gaat mijn dank naar mijn ouders die deze studies mogelijk gemaakt hebben.
Daarnaast wil ik in het bijzonder mijn promotoren prof. dr. ir. Wouter Joosen en prof. dr.
ir. Yolande Berbers en begeleiders Aram Hovsepyan en dr. Stefan Van Baelen bedanken. Ik
mocht wekelijks langskomen om de evolutie van mijn thesis te bespreken. Aram en Stefan
moedigden me aan waar nodig en stonden steeds klaar met goede raad. Ze zorgden ook voor
het grondig nalezen van deze thesistekst.
Ook wil ik Guy Pauwels en Michel Huybrechts van E2S bedanken.
Nog vele anderen uit mijn omgeving verdienen mijn dank - mijn vrienden en vooral mijn
vriendin voor de steun, interesse, hulp en suggesties die ze geboden heeft bij het maken van
dit eindwerk.
i

Inhoudsopgave
1 Inleiding 1
1.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Probleem beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Wat is OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Motivatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 State-of-the-art 7
2.1 Evaluatiecriteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Invarianten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Pre- en Postcondities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Attributen en Associaties . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.4 Operaties op collecties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.5 @pre en result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.6 Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.7 Slimme controle van klasse-invarianten . . . . . . . . . . . . . . . . . . . 9
2.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Octopus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 OCLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Together 2006 for Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.4 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
ii

INHOUDSOPGAVE
iii
3 Methodologie 17
3.1 Design By Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 Klasse-invarianten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.2 Precondities en postcondities . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3 Assertions in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.3.1 Waarom assertie gebruiken? . . . . . . . . . . . . . . . . . . . . 19
3.2 Beschrijving van de methodologie . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Vertaling van attributen en associaties . . . . . . . . . . . . . . . . . . . 20
3.2.2 Vertaling van OCL operaties over basistypen . . . . . . . . . . . . . . . 21
3.2.2.1 Boolean type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2.2 Real en Integer types . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2.3 String type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Vertaling van OCL collectieoperaties . . . . . . . . . . . . . . . . . . . . 23
3.2.3.1 Eenvoudige collectieoperaties . . . . . . . . . . . . . . . . . . . 24
3.2.3.2 Collectieiteratoren . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3.3 Inkapseling van sjablonen voor collectieoperaties in JAVA methoden
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.4 Vertaling van OCL if-then-else expressies . . . . . . . . . . . . . . . . 32
3.2.5 Vertaling van OCL let expressies . . . . . . . . . . . . . . . . . . . . . . 33
3.2.6 Vertaling van klasse-invarianten . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.7 Vertaling van pre- en postcondities . . . . . . . . . . . . . . . . . . . . . 34
3.2.8 Vertaling van meer geavanceerde constructies . . . . . . . . . . . . . . . 35
3.2.8.1 Vertaling van het sleutelwoord @pre . . . . . . . . . . . . . . . 35
3.2.8.2 Het sleutelwoord result . . . . . . . . . . . . . . . . . . . . . 36
3.3 Naïeve aanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1 Vertaling van invarianten . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1.1 Inkapseling van een invariant in een booleaanse methode . . . 37
3.3.1.2 Inkapseling van alle klasse-invarianten in een gemeenschappelijke
methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2 Vertaling van pre- en postcondities . . . . . . . . . . . . . . . . . . . . . 38
3.4 Intelligente aanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.1 Het Idee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.2 Graafconstructie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.3 String matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

iv
INHOUDSOPGAVE
3.4.4 Vertaling van klasse-invarianten . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.4.1 Inkapseling van een invariant in een booleaanse methode . . . 43
3.4.4.2 Inkapseling van alle relevante klasse-invarianten in een gemeenschappelijke
booleaanse methode . . . . . . . . . . . . . . . . . 43
3.4.5 Vertaling van pre- en postcondities . . . . . . . . . . . . . . . . . . . . . 43
3.5 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Realisatie in HAT 46
4.1 HAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Run-time OCL naar JAVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.1 OCL attribuut-, associatie- en operatiemodelelementen . . . . . . . . . . 49
4.2.2 OCL collectieiterator modelelementen . . . . . . . . . . . . . . . . . . . 49
4.2.3 OCL If-then-else en let modelelementen . . . . . . . . . . . . . . . . . . 50
4.2.4 Inkapseling van collectieoperaties . . . . . . . . . . . . . . . . . . . . . . 50
4.3 Naïeve aanpak in HAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Intelligente aanpak in HAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5 Case study - Royal and Loyal 54
5.1 Beschrijving van de case study . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2 Vertaling met behulp van HAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6 Besluit 59
6.1 Doelstellingen en problemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2 Oplossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3 Kritische noot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4 Toekomstig werk: uitbreidingen en aanpassingen . . . . . . . . . . . . . . . . . 60
A Lijst Van Afkortingen 62

L¼st van guren
1.1 Relatie tussen PIM, PSM en code . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Gesimpliceerd UML model van een Luchthaven systeem . . . . . . . . . . . . . 3
3.1 Afhankelijkheid tussen klasse invarianten en postcondities horend bij operaties . 41
3.2 Klassediagram van het lopende voorbeeld. . . . . . . . . . . . . . . . . . . . . . 45
4.1 Architectuur van de Agile MDA Tool . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Gesimpliceerde OCL meta-model . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Abstract syntax metamodel voor ModelPropertyCallExpr . . . . . . . . . . . . 49
5.1 Het aangepaste model van Royal and Loyal . . . . . . . . . . . . . . . . . . . . 55
5.2 Het model van Royal and Loyal . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
v

L¼st van tabellen
2.1 Evaluatiecriteria voor transformatie van OCL expressies door een tool . . . . . 9
2.2 Evaluatie van Octopus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Evaluatie van OCLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Evaluatie van Together 2006 for Eclipse . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Standaard operaties voor de Boolean type . . . . . . . . . . . . . . . . . . . . . 21
3.2 Standaard operaties voor Integer en Real types . . . . . . . . . . . . . . . . . . 22
3.3 Standaardoperaties voor String type . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Afbeelding van OCL collectie typen naar JAVA collectie typen . . . . . . . . . 23
3.5 Standaardoperaties over alle soorten van collectie typen . . . . . . . . . . . . . 24
3.6 Collectieiteratoren operaties over alle collectietypen . . . . . . . . . . . . . . . . 25
3.7 De resultaten van de evaluatie van naïeve en de intelligente aanpak . . . . . . . 44
4.1 Evaluatie van HAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
vi

Hoofdstuk 1
Inleiding
1.1 Situering
De computer industrie is continu op zoek naar manieren om de productiviteit en kwaliteit van
software ontwikkeling te verbeteren. In de vrij korte geschiedenis van software engineering
hebben we al verschillende aanpakken gezien. Voorbeelden daarvan zijn Object-georiënteerdeontwikkelingen,
Component-gebaseerde- ontwikkelingen, design patterns.
Modelgedreven ontwikkeling (MDD) zou ook een belangrijke bijdrage in het proces van software
ontwikkeling kunnen leveren. Een van de belangrijkste doelstellingen van het MDD is
om het niveau van programmeerabstractie te verhogen zodat ontwikkelaars applicaties met
minder moeite kunnen ontwikkelen. In plaats van applicaties in talen zoals JAVA en C++ te
schrijven, creëren ontwikkelaars applicaties met behulp van specieke, hoogniveau programmeerconstructies.
Dit soort constructies noemt men modellen. Deze software modellen hebben
een centrale rol in het MDD ontwikkelingsproces.
In MDD kan men speciceren hoe modellen gedenieerd in een taal naar modellen van een
andere taal mogen getransformeerd worden. Modelleertalen worden in MDD als ontwikkelingsartefacten
gebruikt veeleer dan enkel als ontwerpmiddelen. Uit een abstract model van
een systeem wordt een meer concreet model gegenereerd. Uit dit model wordt dan nog een
meer concreet model gegenereerd. Dit proces wordt meerdere keren uitgevoerd tot uiteindelijk
het laagste niveau van abstractie bereikt is. Van deze laagniveau modellen wordt de broncode
geproduceerd. Hierbij is codegeneratie niets meer dan een andere vorm van transformatie.
Modelgedreven architectuur (MDA) [20] is eigenlijk een concreet voorbeeld van MDD. Het is
een initiatief van Object Management Group (OMG) [16] dat een consortium van bedrijven en
gebruikers is. De OMG heeft bovendien verschillende standaarden (UML, OCL, ...) ontwikkeld
om MDD te kunnen implementeren.
MDA is een verdere stap in de evolutie van het software ontwikkelingsproces. MDA is een
raamwerk voor software ontwikkeling. Modellen krijgen een hoge prioriteit binnen het proces
van software ontwikkeling. Anders gezegd wordt het ontwikkelingsproces gedreven door de
modelleeractiviteit. Hierbij maakt men onderscheid tussen platformonafhankelijke modellen
(PIM) en platformafhankelijke modellen (PSM). PIMs zijn op een hoogniveau van abstractie
gebouwd en bovendien onafhankelijk van een set van implementatie technologieën. Voorbeelden
daarvan zijn J2EE en .NET. PSMs zijn het resultaat van de transformatie van de
1

2 HOOFDSTUK 1. INLEIDING
PIM naar de nood voor een specieke implementatie technologie, bijvoorbeeld J2EE. Daarna
wordt er vanuit de PSM code gegenereerd wat kan gezien worden als een transformatie van
een PSM-model naar een code-model.
Figuur 1.1: Relatie tussen PIM, PSM en code
Sinds het MDA [3] proces gedreven wordt door een PIM dat automatisch getransformeerd
wordt naar een PSM en nog verder naar code, kan modelleren beschouwd worden als programmeren
op een hoger niveau. PIMs speciceren de code die geproduceerd (gegenereerd) moet
worden. Bijgevolg zal het volume van de handgeschreven code kleiner zijn. Programmeren
wordt uiteindelijk modelleren. Het software ontwikkelingsproces zal rond goede, hoog-niveau,
onafhankelijke modellen draaien.
Modelleren en vooral software modelleren wordt soms gebuikt als synoniem voor het maken
van diagrammen. De meeste van de modellen bestaan uit een aantal vierkantjes, cirkels met
pijlen en bijbehorende tekst. De informatie, die men van de gegeven modellen kan extraheren,
is meestal incompleet, informeel en zelfs niet precies. De Object Constraint Language (OCL)
[21] legt beperkingen op het model en op de semantiek ervan. Met OCL kan men al de supplementaire
en benodigde informatie over de modellen in het model zelf uitdrukken. Speciceren
van modellen gebruik makende van Unied Modeling Language (UML) [15] en de OCL-taal
kan de kwaliteit van de modellen verbeteren.

1.2. PROBLEEM BESCHRIJVING 3
1.2 Probleem beschrijving
Net zoals broncode, moeten MDD modellen juist en precies zijn om tot een correcte broncode te
kunnen komen. Er bestaan verschillende modelleertalen die in een MDD ontwikkelingsproces
gebruikt kunnen worden. Voorbeelden daarvan zijn UML, GME, MetaEdit [15,17,18]. Hoe
juist en precies men in elk van die talen kan modelleren hangt af van taal tot taal. In deze
thesis gaan we enkel naar UML kijken. UML heeft veel zwakke punten maar blijft toch een
van de meest populaire modelleertalen. Een van de zwakheden van UML modellen (vanaf
hier gaan we de term modellen gebruiken in de context van UML) wordt veroorzaakt door de
semantische onvolledigheid van de modellen.
Modellen kunnen niet alle vaststellingen van een specicatie beschrijven. Bijvoorbeeld het
model in figuur 1.2, duidt de associatie tussen de klasse Person en de klasse Flight aan
dat er met een vlucht nul of meer passagiers geassocieerd kunnen zijn : multipliciteit (0..*).
Dit impliceert dat het aantal passagiers oneindig kan zijn. In werkelijkheid zal dit aantal
eerder beperkt zijn tot het aantal zetels in het vliegtuig dat aan de vlucht geassocieerd is.
Dit voorbeeld toont aan dat deze beperking onbeschrijfbaar is in het UML klasse-diagram.
Bijgevolg zullen modellen die in UML uitgedrukt zijn meestal incompleet, informeel en zelfs
niet precies zijn.
Figuur 1.2: Gesimpliceerd UML model van een Luchthaven systeem
1.2.1 Wat is OCL
De Object Constraint Language (OCL) is een notatie taal voor analyse en design van software
systemen. Deze taal laat ons toe om expressies en beperkingen op een object-georiënteerde
model te schrijven. OCL is ook een deelverzameling van de Unied Modeling Language (UML).
Deze constraints zijn nuttig in het software ontwikkelingsproces. Deze laten de ontwikkelaar
toe om een specieke verzameling van regels die de aspecten van de individuele objecten
bestuurt te creëren.
OCL is ook een constructie waarbij UML het concept van Design By Contract (DBC) [25]
kan ondersteunen. Er zijn twee basis soorten van constraints: klasse-invarianten en pre- en

4 HOOFDSTUK 1. INLEIDING
postcondities. Het uitgangspunt is dat UML modellen met constraint declaraties concreter en
preciezer zijn dan modellen die dat niet hebben. Bovendien zijn deze OCL expressies eigenlijk
de invoer voor de codegeneratoren in het MDA raamwerk.
Expressies geschreven in een precieze, wiskundige gebaseerde taal zoals OCL bieden een aantal
voordelen ten opzichte van het puur gebruik van modellen om het software systeem te speci-
ceren. Deze expressies kunnen niet op verschillende manieren geïnterpreteerd worden door
analisten of door programmeurs. Deze zijn ondubbelzinnig en maken onze modellen preciezer
en correcter.
Ten tweede kunnen deze expressies door geautomatiseerde tools gecontroleerd worden. Codegeneratie
wordt op deze manier krachtiger. Met krachtiger bedoelen we hier dat de geproduceerde
artefacten formeel en precies genoeg zijn en dat er geen ingreep door de programmeurs
nodig is om de gegenereerde code aan te passen of om extra broncode toe te voegen.
Laat ons naar het voorbeeld over het Luchthavensysteem teruggaan. De restrictie in de multipliciteit
aan de kant van Person is op te lossen door de volgende OCL constraint aan het
diagram toe te voegen.
context Flight
inv:
passengers->size()

1.4. DOELSTELLINGEN 5
• Ten vierde is het mogelijk om het principe van Design By Contract in een programmeertaal
te simuleren.
Indien we deze aanpak in software ontwikkeling volgen, zal de productiviteit zeker verhogen.
Een implementatie van een systeem door MDD/MDA tools is sneller en eciënter dan een
handgeschreven implementatie. Verder is de kwaliteit van ons systeem verhoogd. Er is garantie
voor een consistentie tussen ons UML/OCL- model en de gegenereerde artefacten.
1.4 Doelstellingen
In het kader van dit eindwerk zullen we een bepaald aspect van de modeltransformaties proberen
te bestuderen - namelijk de transformaties van OCL expressies naar werkende code. Tot
nu toe zijn OCL expressies vooral gebruikt als validatie van modellen en documentatie. Dus
spreken we hier over statische OCL. In deze thesis willen we verder gaan door beperkingen te
leggen op instantiaties van UML modellen. Dit soort van OCL expressies noemt men run-time
OCL. Er zijn twee basissoorten van OCL expressies of constraints: klasse-invarianten en preen
postcondities. Wat we in deze thesis willen realiseren is precies deze twee basissoorten van
OCL expressies te transformeren door een specieke codegeneratie. We gebruiken JAVA als
doeltaal voor deze codegeneratie.
Deze specieke transformatie (codegeneratie) zal gebeuren op basis van twee aanpakken. Een
eerste aanpak is de naïeve aanpak waarbij beide basissoorten van constraints gecontroleerd
worden op iedere stabiel moment van een systeem. Maar hier stoppen we niet. Een tweede
meer geavanceerde aanpak zal bestudeerd worden. Hierbij worden alleen de relevante OCLexpressies
gecontroleerd waarbij de overhead drastisch kan dalen en de eciëntie van ons
systeem verhoogt.
Deze transformaties zullen we uitwerken met het HAT-tool van het software engineeringsbedrijf
E2S uit Gent [10].
Hiernaast zullen we ook een aantal bestaande tools evalueren die run-time OCL ondersteunen.
1.5 Overzicht
In dit hoofdstuk werd het ontwerp van dit eindwerk in een ruimer kader geplaatst. De doelstellingen
werden kort aangehaald.
In het tweede hoofdstuk gaan we de state-of-the-art van OCL toolondersteuning bespreken.
Hier stellen we eerst een aantal evaluatiecriteria voor. Op basis van de opgestelde criteria
evalueren we een aantal tools. Ten slotte trekken we een conclusie over de huidige toolondersteuning
van run-time OCL expressies.
In het derde hoofdstuk stellen we verschillende aanpakken van transformaties van constraints
naar code voor. Deze constraints zijn OCL expressies op UML modellen. Eerst zullen we een
beschrijving van een mogelijke OCL naar JAVA vertaling voorstellen. Daarna zullen we deze
transformaties zowel op een naïeve als op een meer intelligente manier beschrijven.

6 HOOFDSTUK 1. INLEIDING
In het vierde hoofdstuk beschrijven we de realisatie van OCL transformaties in het HAT tool.
Ten eerste zullen we een pure vertaling van OCL expressies naar JAVA bespreken. Ten tweede
zullen we de naïeve en de intelligente aanpakken bespreken.
In het vijfde hoofdstuk werken we een case studie uit. De voorgestelde aanpakken in het derde
hoofdstuk worden naast elkaar gelegd. Alle voordelen en nadelen zullen we grondig bespreken.
Het laatste hoofdstuk is een afsluitend hoofdstuk waarin we de huidige situering en de toekomst
van MDD/MDA kritisch bespreken.

Hoofdstuk 2
State-of-the-art
De Object Constraint Language (OCL) [1] is een notatietaal voor analyse en ontwerp van
software systemen. Het is een aanvulling op de industrie standaard UML waarbij ontwikkelaars
beperkingen over modellen kunnen schrijven. Vandaag de dag vereisen veel software projecten
complexe formele regels die in het businessmodel moeten worden uitgedrukt. OCL lost dit
probleem op. OCL is eenvoudig genoeg om door business analisten gebruikt te worden maar
ook formeel genoeg om door tools geïnterpreteerd en gemanipuleerd te worden.
In dit hoofdstuk geven we een overzicht van de huidige stand van tools die OCL expressies
naar JAVA vertalen. Hier gaan we eerst een aantal evaluatiecriteria voorstellen. Dan zullen
we een aantal tools evalueren aan de hand van de voorgestelde criteria. Vervolgens zullen we
deze tools naast mekaar zetten.
2.1 Evaluatiecriteria
In deze sectie gaan we een structuur voorstellen om tools te kunnen evalueren. Deze structuur
is niet alleen gebaseerd op constructies die in de OCL taal aanwezig zijn maar ook op andere
factoren: bijvoorbeeld de code die gegenereerd wordt na de vertaling van de OCL expressies
naar een doel taal. In deze thesis wordt JAVA gebruikt als doeltaal voor de vertaling.
In deze thesis onderzoeken we alleen maar een deel van de eigenschappen van OCL. We
gaan voornamelijk in op klasse-invarianten, pre- en postcondities. Ook onderzoeken we de
ondersteuning van meer ingewikkelde sleutelwoorden zoals @pre en result. Ten laatste breiden
we onze criteria uit met manieren om de voldoening van constraints na te gaan. Daarom zijn
onze criteria ook beperkt tot deze deelverzameling.
In de context van OCL kunnen we meer informatie aan een model toevoegen aan de hand van
invarianten. Deze invarianten kunnen op verschillende model elementen inwerken.
2.1.1 Invarianten
In specicaties is zo dat we vaak met invarianten te maken hebben. Klasse-invarianten garanderen
ons dat objecten altijd een geldige toestand hebben. We zullen klasse-invarianten
in meer detail in subsectie 3.1.1 bespreken. Daarom is de ondersteuning van invarianten door
tools een basisvereiste.
7

8 HOOFDSTUK 2. STATE-OF-THE-ART
2.1.2 Pre- en Postcondities
Indien men een meer complete specicatie van een systeem wenst is belangrijk om gebruik te
maken van pre- en postcondities. Pre- en postcondities zijn beperkingen die de eecten en
toepasbaarheid van operaties speciceren. In subsectie 3.1.2 zullen we dieper ingaan op preen
postcondities.
Sommige tools [13] beperken zich alleen maar tot precondities. De argumenten achter deze
beslissing zijn dat de gebruiker de regels van een contract moet volgen. Indien dat niet zo is,
is er geen garantie dat het resultaat van het uitvoeren van een stuk code correct zal verlopen.
Verder wordt ook verondersteld dat het uitvoeren van een stuk code altijd correct beëindigt
indien de precondities niet geschonden zijn.
In deze thesis vertegenwoordigen we het gebruik van pre- en postcondities. De vereisten zijn
dat een tool beide soorten van constraints ondersteunt.
We hebben al twee soorten van constraints gezien: klasse-invarianten, pre- en postcondities.
Bij elk van deze soorten van constraints zijn er verschillende modelelementen betrokken, namelijk
attributen, associatie, operaties, enz.
2.1.3 Attributen en Associaties
Indien de visibiliteit van attributen en associaties als private gemodelleerd is dan zijn deze
beperkt tot de klasse waarin ze gedenieerde zijn. Om naar deze modelelementen te kunnen
refereren is het essentieel om inspectoren voor deze modelelementen te denieren.
Indien een tool ondersteuning biedt voor invarianten en pre- en postcondities moet het tool
minimaal een vertaling van eenvoudige constraints ondersteunen. Met eenvoudige constraints
bedoelen we constraints die bijvoorbeeld alleen maar attributen en operaties op deze attributen
bevatten. Ook vallen enkelvoudige associaties in deze categorie. Indien de associaties een
collectie voorstellen is dat niet meer het geval. Dit wordt uitgelegd in de volgende paragraaf.
2.1.4 Operaties op collecties
Er bestaan twee soorten van operaties op collecties: zij die over de collecties itereren en zij
die dat niet doen. Hier focussen we op de eerste soort, namelijk collectieiteratoren. In JAVA
hebben OCL collectieiteratoren geen tegenhangers. Bijgevolg verkrijgen we meestal complexe
constructies na de vertaling van deze collectieiteratoren naar een doeltaal. Wat we hier willen
onderzoeken is in welke mate de complexiteit van deze constructies kan worden gereduceerd.
2.1.5 @pre en result
In OCL zijn er ook meer geavanceerde constructies voor postcondities. Hier bedoelen we
constructies die naar waarden van modelelementen op twee verschillende tijdstippen refereren,
bijvoorbeeld de OCL constructie @pre. Een andere constructie is een constructie die het result
sleutelwoord bevat. Dit sleutelwoord duidt de terugwaarde van een operatie aan. Het type
van result hangt af van het terugtype van de operatie.
Beide sleutelwoorden kunnen de specicatie van een model verbeteren en hun vertaling naar
een doeltaal is hier gewaardeerd

2.1. EVALUATIECRITERIA 9
2.1.6 Assertion
Hoewel deze criteria cruciaal zijn ontbreekt nog een deel van de puzzel. Is de transformatie
uiteindelijk betrouwbaar? Wat gebeurt als een constraint geschonden is? Is er een exceptie
gegooid? Dat zijn allemaal vragen die men kan stellen.
Hiervoor gebruiken we de techniek van assertion [14]. In sommige programmeertalen is dat
volledig ondersteunt of helemaal niet. Try-catch blokken zijn geen slechte manier van werken.
Maar bij het uitvoeren van een systeem zal elke constraint nagegaan worden. Bij het installeren
(deployment) leidt dat tot een vertraagd systeem. Daarom verkiezen we voor de assertion
techniek die ons toelaat om de beslissing te nemen over het aan- en uitschakelen van de
constraints op run-time. Een code die geen van deze twee technieken gebruikt beschouwen we
als slechte code.
2.1.7 Slimme controle van klasse-invarianten
De criteria die we hanteren wat betreft de technieken voor het nagaan van voldoening van
constraints hebben we hierboven beschreven. Eveneens van belang is de vraag of we telkens
alle klasse-invarianten moeten nagaan na het uitvoeren van een publieke methode. Misschien
is het wel beter om enkel de relevante klasse-invariaten te inspecteren. In hoofdstuk 3 gaan we
een mogelijke intelligente methode voorstellen om na het uitvoeren van een publieke methode
alleen maar relevante klasse-invarianten na te gaan.
Alles wat we tot nu toe besproken hebben is samengevat in tabel 2.1. Deze tabel somt een
aantal criteria op en geeft voor elke vereiste een beschrijving.
Id Criteria Beschrijving
1 invarianten Garanderen een geldige toestand van objecten
2 pre-, postcondities Vervolledigen de specicatie door constraints
op operaties toe te voegen
3 attributen, Basismodelelementen in een OCL
associaties
expressie
4 collectieiteratoren OCL collectieiteratoren hebben geen substituten in
JAVA - hoe worden hulp operaties gegenereerd
5 @pre Verbeteren de specicatie van postcondities
door naar waarden op verschillende tijdstippen
te refereren
6 result Verbeteren de specicatie van postcondities(geeft
de terugwaarde van operaties terug)
7 assertion De manier van controle: zijn de constraints
al dan niet geschonden
8 Slimme controle van Zijn alle constraints nagegaan of maar deze
klasse-invarianten die relevant zijn
Tabel 2.1: Evaluatiecriteria voor transformatie van OCL expressies door een tool

10 HOOFDSTUK 2. STATE-OF-THE-ART
2.2 Tools
Er zijn al een aantal tools op de markt die ondersteuning en afhandeling van OCL expressies
bieden. Hieronder geven we een overzicht van de tools waarmee we geëxperimenteerd hebben.
We voegen ook extracten (skeletten) van code toe die door de tools gegenereerd waren. Sommige
methodes kunnen leeg zijn maar dat is hier niet van belang want we willen de structuur
van de gegenereerde code tonen.
2.2.1 Octopus
Octopus [13] is een tool dat het gebruik van OCL ondersteunt. Octopus staat voor OCL tool
for Precise UML Specication. Het Octopus tool biedt twee belangrijke functionaliteiten. Ten
eerste is in Octopus mogelijk om zowel de syntaxis van OCL expressies als de typen en het
juiste gebruik van modelelementen na te gaan. Met modelelementen wordt hier attributen en
associaties bedoeld. Ten tweede biedt Octopus de mogelijkheid om transformaties van UML
modellen met de bijhorende OCL expressies (beperkingen die in OCL uitgedrukt zijn) naar
JAVA uit te voeren.
Dit tool biedt geen mogelijkheden om modellen te creëren. De modellen moeten eerst in andere
modelleertools zoals bijvoorbeeld MagicDraw [22] gedenieerd worden en pas dan geïmporteerd
worden. Dan kan men de specicatie uitgedrukt in OCL toevoegen. Vervolgens volstaat
het om de codegenerator op te roepen. Het resultaat van de transformatie is een model in
een platformafhankelijke taal. In dit tool is er geen mogelijkheid om de gegenereerde code te
ne-tunen, namelijk om de structuur van de geproduceerde code (de elementen die het tool
genereert) te veranderen.
Id Criteria Opmerking Ondersteuning
1 invarianten Ja
2 pre-, postcondities allen precondities Ja
3 attributen, inspectoren en mutatoren Ja
associaties zijn gegenereerd
4 collecties Voor ieder collectieiterator Ja
een nieuwe methode
5 @pre Neen
6 result Neen
7 assertion Alleen precondities zijn Ja
door assert nagegaan
8 slimme controle Neen
klasse-invarianten
Tabel 2.2: Evaluatie van Octopus
De code die hier gegenereerd wordt, is volledig in de zin dat niet alleen de OCL expressie zijn
vertaald naar JAVA maar er zijn ook constructoren, inspectoren en mutatoren gegenereerd.
Met andere woorden verkrijgen we een volledig uitvoerbaar systeem. Het tool ondersteunt

2.2. TOOLS 11
alleen maar invarianten en precondities. In de laatste versie 2.2.0 die we getest hebben, zijn
postcondities nog niet ondersteund. Bijgevolg zijn sleutelwoorden als @pre en result ook niet
vertaald.
Iedere keer een OCL expressie gebruik maakt van collectieoperaties die over collecties itereren
zijn er hulp methoden voor gecreëerd. Op deze manier wordt de code met dupliceerde
hulp methoden aangevuld. Bij operaties zijn er wel de precondities gecheckt maar niet de
invarianten.
Hieronder geven we een skelet van hoe de gegenereerde JAVA code eruit ziet:
Listing 1 Octopus
class X{
private int attribute;
public X(){
}
public void operation(){
assert (precondition);
//...
}
private boolean helpMethod(){
}
public void inv0(){
boolean result = helpMethod();
if(!result) throw new InvariantException();
public void inv1(){
}
public List checkAllInvariants(){
List result = new ArrayList();
try{
inv0();
}catch(InvariantException e){result.add(e);}
try{
inv1();
}catch(InvariantException e){result.add(e);}
return result;
}
}
2.2.2 OCLE
OCLE [12] is een UML CASE tool dat OCL volledig ondersteunt, zowel op metamodel als
op modelniveau. De codegenerator produceert code voor de modelstructuur en voor de OCL
specicatie. Het resultaat is een volledig werkende code. Versie 2.0 van het tool biedt ondersteuning
voor OCL 2.0 en is compatibel met UML 1.5.
Indien men dit tool voor codegeneratie wil gebruiken moet men eerst een model in het tool
creëren en dan de bijbehorende OCL constraints toevoegen. Deze constraints kunnen geva-

12 HOOFDSTUK 2. STATE-OF-THE-ART
lideerd worden voordat men code gaat genereren. Men kan niets aan de structuur van de
gegenereerde code veranderen. Bovendien om de code te kunnen compileren moet men een
bibliotheek importeren die bij het tool te vinden is.
Alhoewel pre- en postcondities ondersteund zijn, worden de sleutelwoorden @pre en result niet
correct geimplementeerd. Dat is te wijten aan het feit dat deze sleutelwoorden genegeerd zijn
door de codegenerator.
De controle over de constraints gebeurt door if-blokken. Indien de beperkingen in de specicatie
geschonden zijn, wordt een boodschap getoond. Er is geen mogelijkheid om deze controles
aan en uit te schakelen wanneer dat gewenst is. Dat is een min punt voor dit tool vermits
volgens B.Meyer pre- en postcondities tijdens testen of debuggen moeten aangezet worden
maar tijdens de echte uitvoering van het programma moeten afstaan [25].
Bij collectieiteratoren worden geen hulpmethodes gegeneerd. Alle bewerkingen rond collectieiteratoren
zijn te vinden in de methode van de invariant of pre- en postconditie zelf. Bijgevolg
zijn de gegenereerde JAVA methoden langer en soms niet overzichtelijk.
Hieronder tonen we in Listing 2 hoe een klasse met de bijbehorende specicatie eruit ziet.
Listing 2 OCLE
class X{
private int attribute;
public void operation(){
class ConstraintChecker{
public void checkPreconditions(){
}
public void checkPostconditions(){
}
ConstraintChecker ch = new ConstraintChecker();
ch.checkPreconditions();
ch.checkPostconditions();
}
}
public class ConstaintChecker{
public void checkConstaints(){
check_X_inv0();
check_X_inv1();
}
public void inv0(){
//...
if(!test)
System.out.println(postcondition failed for object+X.this);
}
public void inv1(){
}
}
}
De gegenereerde code verkrijgen uit het OCLE tool is min of meer volledig in de zin dat we een

2.2. TOOLS 13
compleet systeem als resultaat hebben. Natuurlijk zijn meer geavanceerde constructie (zoals
@pre en result) nog niet ondersteund. In de tabel 2.3 is alles nog eens samengevat.
Id Criteria Opmerking Ondersteuning
1 invarianten Ja
2 pre-, postconditie Ja
3 attributen, Geen inspectoren of Neen
associaties mutatoren gegenereerd,
attributen met publieke visibiliteit
4 collectie Ja
5 @pre dit sleutelwoord is Neen
genegeerd
6 result Neen
7 assertion Neen
8 slimme controle Neen
klasse-invarianten
Tabel 2.3: Evaluatie van OCLE
2.2.3 Together 2006 for Eclipse
De Together 2006 Release 2 for Eclipse [11] versie 8.1.1 is een visueel platform dat ondersteuning
biedt voor een grote groep van gebruikers, van software architecten en ontwikkelaars tot
business process analisten. De mogelijkheden van dit tool zijn enorm groot. Hier gaan we ons
tot een bepaald deel van de eigenschappen van het tool beperken, namelijk transformatie van
OCL expressies naar code.
Id Criteria Opmerking Ondersteuning
1 invarianten Ja
2 pre-, postconditie Ja
3 attributen, Geen mutatoren of inspectoren, Neen
associaties publieke visibiliteit attributen
4 collectie Geen hulp methoden Ja
5 @pre Ja
6 result De semantiek van de vertaalde Ja
code is niet precies
7 assertion Goed gebruik van assertions Ja
slimme controle
8 klasse-inavianten Neen
Tabel 2.4: Evaluatie van Together 2006 for Eclipse
In dit tool kan men opnieuw zelf modellen creëren en dan constraints erop toevoegen. Het tool
beschikt over een 'syntax completion' functie die men toelaat om snel en eciënt constraints

14 HOOFDSTUK 2. STATE-OF-THE-ART
te schrijven. Controle voor geldigheid en consistentie van constraints is door het tool gedaan.
Er is geen mogelijkheid om de structuur van de gegenereerde code te veranderen.
Een van de positieve punten van dit tool is dat het tool ondersteuning biedt voor zowel
invarianten als voor pre- en postcondities. Binnen elke gegenereerde klasse uit het model is
een statische klasse gedenieerd met de bijbehorende constraints. Het skelet van een klasse
ziet als volgt uit:
Listing 3 Together
class X{
private int attribute;
public void operation(){
assert ( OCL.preOperation());
// ...
assert(OCL.AllInvariants() && OCL.postOperation());
}
protected static class OCL{
private OCL(){
}
static boolean inv0(){
}
static boolean inv1(){
}
static boolean allInvariants(){
return inv0()&& inv1();
}
static boolean preOperation(){
}
static boolean postOperation(){
}
}
}
Het tool genereert code voor alle attributen, associaties en operaties en natuurlijk ook voor
de constraints uitgedrukt in OCL. Constructoren, mutatoren en inspectoren worden niet gegenereerd.
De vertaalde OCL code refereert naar de attributen of associaties zelf en niet naar
hun inspectoren. Vermits visibiliteit van attributen meestal beperkt is tot de klasse waarin ze
gedenieerd zijn, is de gegenereerde code soms niet compileerbaar omwille van het probleem
van visibiliteit. Een oplossing is om alle attributen publiek te maken wat niet altijd gewenst is.
Operaties op collecties zijn ook ondersteund. Indien in een OCL expressie collectieiteratoren
aanwezig zijn, zijn deze niet ingekapseld in aparte methoden maar tussen try-catch blokken
binnen de invariant of pre- en postconditie methode zelf. Dat leidt bij complexe OCL expressie
tot lange en soms niet overzichtelijke methoden met een aantal grote try-catch blokken.
Indien we de code structuur van de gegenereerde code bekijken, zien we dat de controle op de
constraints gebeurt door het gebruik van asserties. Dat beschouwen we als een goede techniek.
Postcondities mogen meer geavanceerde constructies hebben. De sleutel worden @pre en result
zijn geimplementeerd.

2.2. TOOLS 15
Indien het sleutelwoord @pre in een van de postcondities aanwezig is dan is de structuur van
de klasse waarbij deze postconditie behoort uitgebreid. Deze uitbreiding is gevat in een nieuwe
abstracte statische klasse PrePost. Deze nieuwe klasse is een hulpklasse om de toestand van
een variabele of object op te slaan voor de uitvoering van de operatie. Op deze manier worden
pre- en postcondities correct geëvalueerd.
We kunnen nu alles recapituleren in tabel 2.4.
Listing 4 Together 2
class X{
private int attribute;
public void operation(){
OCL.PrePost oclPreState = OCL.preOperation();
// ...
assert(OCL.PrePost.checkPost(oclPreState,null) && OCL.AllInvariants() );
}
protected static class OCL{
private static final boolean isEnabled = X.class.desiredAssertStatus();
private OCL(){
}
protected static abstract class PrePost{
private static boolean checkPost(PrePost preState, Object result){
return preState != null ? preState.post(result) : !isEnabled;
}
protected abstract boolean post(Object result);
}
static protected PrePost preOperation(){
if(!OCL.isEnabled) return null;
PrePost preState = new PrePost(){
// save the preState of the postcondition
protected boolean post(Object _result){
// ...
}
};
return preState;
}
static boolean inv0(){
}
static boolean inv1(){
}
static boolean allInvariants(){
return inv0()&& inv1();
}
static boolean preOperation(){
}
}
}

16 HOOFDSTUK 2. STATE-OF-THE-ART
2.2.4 Conclusie
Er bestaan veel tools die statische OCL ondersteunen, namelijk voor validatie en documentatie
van modellen. Bovendien zijn ze tegenwoordig betrouwbaar om mee te kunnen werken.
Indien we run-time OCL willen gebruiken, is dat niet meer het geval. Het aantal tools dat
deze soort van OCL ondersteuning aanbieden, is beperkt. Daarenboven is de code die ze
genereren meestal niet volledig, of nog erger niet correct. In dit hoofdstuk hebben we de
huidige ondersteuning van run-time OCL generatie onderzocht. De conclusie is dat de huidige
state-of-the-art tools onvolledig zijn wat betreft de criteria opgesteld in het begin.
In het volgende hoofdstuk gaan we zelf een transformatie uitwerken gebruik makende van het
HAT tool en zien in welke mate die de criteria kan ondersteunen. Maar eerst zullen we een
methodologie uitwerken voor het omzetten van OCL expressies naar JAVA code.

Hoofdstuk 3
Methodologie
In dit hoofdstuk bespreken we eerst wat Design By Contract (DBC) is. Hier worden klasseinvarianten,
pre- en postcondities grondig uitgelegd. Verder leggen we uit hoe DBC in programmeertalen
zoals JAVA kan gesimuleerd worden die per denitie geen expliciete ondersteuning
van DBC heeft. Na deze inleiding over DBC gaan we uitleggen welke aanpakken we
in deze thesis hebben gebruikt om de doelstellingen te kunnen bereiken. De eerste aanpak
is redelijk naïef. Deze aanpak is eenvoudig maar veroorzaakt in sommige gevallen veel overhead.
Een tweede aanpak die we ontwikkeld en bestudeerd hebben, noemen we de intelligente
aanpak. Deze is meer eciënt dan de naïeve aanpak ten opzichte van de uitvoeringstijd maar
tegelijkertijd is de complexiteit van de structuur die uiteindelijk de broncode gaat genereren
ook verhoogd.
3.1 Design By Contract
Desing By Contract [25] is een methode voor het ontwikkelen van kwaliteitssoftware bedacht
door Bertrand Meyer. DBC focusseert zich op het maken van software contracten op een
expliciete en formele manier. Deze software contracten speciceren wat elke operatie in een
systeem van de oproeper vereist en wat aan de oproeper gegarandeerd wordt.
De denitie van een contract is in het DBC principe afgeleid van de notie van een contract.
Een contract is een wettelijke overeenkomst tussen twee partijen waarin beide partijen alle
verbintenissen aanvaarden. In termen van object-georiënteerde ontwikkeling is een contract
een middel om de verantwoordelijkheden van objecten op een precieze en niet ambigu manier
vast te leggen. Een object is aansprakelijk voor het uitvoeren van diensten (verplichten) enkel
en alleen als sommige voorwaarden voldaan zijn. Een contract is een nauwkeurige specicatie
van de interface van een object. Alle objecten die gebruik willen maken van de aangeboden
diensten heten klanten of consumenten. Het object dat deze diensten aanbiedt noemt men de
leverancier of producent.
Alhoewel de notie van contract afkomstig van de rechten praxis is, wijkt het contract beetje af
wanneer het men in de context van object-georiënteerde ontwikkeling neerzet. Namelijk een
contract is aangeboden door een leverancier al dan niet een klant aanwezig is. Echter als een
klant gebruik van de aangeboden diensten in een contract maakt, verplicht de klant zich aan
de voorwaarden in het contract.
17

18 HOOFDSTUK 3. METHODOLOGIE
Een contract beschrijft de diensten die door een object aangeboden worden. Voor elke dienst
speciceert het contract:
• Onder welke voorwaarden de dienst zal aangeboden worden.
• De specicatie van het resultaat van de aangeboden dienst gegeven dat alle voorwaarden
voldaan zijn.
Elk object kan een aantal operaties uitvoeren. Deze operaties zijn te vinden in de interface
van het object zelf. Voor elke van deze operaties kan een contract geëxpliciteerd worden.
De rechten van het object komen met precondities overeen en de verplichten van het object
corresponderen met de postcondities.
Indien minstens een van beide partijen de voorwaarden van het contract niet respecteren, is
het contract geschonden. Als dat gebeurt dan is het duidelijk wie aan de voorwaarden van
het contract niet voldeed. Ofwel heeft de klant de aangeboden diensten niet correct gebruikt,
ofwel heeft de leverancier de aangeboden dienst niet correct uitgevoerd. De programmeertaal
EIFFEL [19] is de enige taal die een implementatie van DBC voorziet. DBC kan gebruikt
worden binnen de context van object-georiënteerde ontwikkeling.
In volgende sectie zullen we bespreken wat klasse-invarianten, pre- en postcondities zijn.
3.1.1 Klasse-invarianten
Klasse-invariant - is een booleaanse expressie die een conditie vaststelt. Deze conditie moet
altijd voldaan zijn voor alle instanties waarvoor deze conditie gedenieerd is. Een invariant
moet juist na de afhandeling van een constructor of na de afhandeling van elke publieke
operatie waar zijn maar niet noodzakelijk tijdens het uitvoeren van de operatie. Anders
gezegd, een klasse-invariant moet waar zijn op eender welke consistente toestand van een
systeem. Indien het systeem bijvoorbeeld een operatie uitvoert dan is ons systeem niet in een
consistente toestand en bijgevolg moet de invariant niet meer waar zijn. Uiteraard moet na
de uitvoering van de operatie de invariant opnieuw waar zijn.
3.1.2 Precondities en postcondities
Pre- en postcondities zijn gebruikt om operaties te speciceren. Deze vervolledigen de interface
van een operatie. Pre- en postcondities speciceren niet hoe het lichaam van een operatie
geimplementeerd moet worden. Hieronder zijn deze concepten gedenieerd:
Preconditie - is een booleaanse expressie die op het moment dat het uitvoeren van de operatie
begint waar moet zijn.
Postconditie - is een booleaanse expressie dat op het moment dat het uitvoeren van de operatie
eindigt waar moet zijn.
Met andere woorden pre- en postcondities moeten alleen op bepaalde tijdstippen (respectievelijk
voor en na het uitvoeren van operaties) waar zijn in tegenstelling tot invarianten die
altijd waar moeten zijn.

3.1. DESIGN BY CONTRACT 19
Het principe achter pre- en postcondities is meestal gerefereerd naar het principe van Design
By Contract (DBC) dat wij in de vorige sectie uitgelegd hebben.
Vermits niet alle programmeertalen het principe van DBC ondersteunen, kan DBC op een of
ander manier gesimuleerd worden in andere programmeertalen. Volgende sectie introduceert
het begrip assertion en meer bepaald hoe dat kan geimplementeerd worden in de programmeertaal
JAVA.
3.1.3 Assertions in Java
Een assertie (assertion) [14] is een booleaanse expressie die ons toelaat om een veronderstelling
over een programma te toetsen. Als deze veronderstelling niet waar is, zal het programma een
exceptie gooien. Indien de vericatie van deze booleaanse expressie waar levert dan bevestigt
de corresponderende assertion de gemaakte veronderstelling. Als gevolg krijgt men foutsvrije
programmas en de kwaliteit van de programmas is verhoogd.
Ervaring toont dat het gebruik van assertions tijdens programmeren een van het snelste en
meest eectieve manieren is om fouten te detecteren en corrigeren. Bovendien dienen assertions
voor documentatie van programmas en op deze manier is de onderhoud verbeterd.
In JAVA heeft assertion de volgende vorm:
assert Expressie1 : Expressie2 ;
waarbij Expressie1 een booleaanse expressie is en Expressie2 een expressie is die een waarde
heeft (deze expressie kan geen invocatie van een methode zijn die als void gedenieerd is). Het
systeem evalueert Expressie1 en als dat false is dan gooit het systeem een AssertionError.
Dan wordt de waarde van Expressie2 doorgegeven aan de constructor van AssertionError die
de stringrepresentatie van de waarde van Expressie2 gebruikt om een gedetailleerde bericht
van de fout te geven.
De assert constructie is een informele soort van Design By Contract. Toch kan men een
ondersteuning voor klasse-invarianten, pre- en postcondities bieden. De assert constructie
dwingt ons niet om een bepaalde soort van constraint-checking te gebruiken. Meestal is gelegen
om de expressies die constraints op de objecten van ons systeem opleggen te combineren in een
enkele booleaanse methode. Dan wordt deze booleaanse methode opgeroepen door de assertie
clausule.
3.1.3.1 Waarom assertie gebruiken?
Veel mensen zouden zich afvragen waarom men een assertie faciliteit moet aanbieden. Deze
speciale ondersteuning van assertie in de JAVA programmeertaal kan expliciet geprogrammeerd
worden.
Alhoewel een ad hoc implementatie mogelijk is is het meestal minder gestructureerd (ifstatements
nodig voor elke assert) en ineciënt (evaluatie van de condities zelfs als asserties
uitgeschakeld zijn). Ten tweede heeft elke ad hoc implementatie zijn eigen manier van aanen
uitschakelen van asserties. Dit reduceert het nut van deze implementaties vooral bij debuggen.
Bijgevolg is de assertie cultuur nooit gevolgd door software ingenieurs in de JAVA
programmeertaal.

20 HOOFDSTUK 3. METHODOLOGIE
Het grootste voordeel van het assert statement in de JAVA programmeertaal is de mogelijkheid
om deze asserties aan en uit te schakelen. Bij de implementatie- en testfasen van het
ontwikkelingsproces is essentieel om deze opties aan te schakelen. Als we in plaats van asserties
gewoon if-statements gebruiken om de constraints over ons model te veriëren maakt
dat geen groot verschil. Het nadeel van de if-statements tegenover de asserties komt bij de
fase van het installeren (deployment) van applicaties. Deze overhead van zulke vericatie kan
enorm groot zijn waardoor de eciëntie van ons systeem kan dalen. If-statements zullen in
alle gevallen uitgevoerd worden. Gebruik makende van asserties kunnen wij op elk moment
beslissen of we al dan niet de constraints willen nagaan.
3.2 Beschrijving van de methodologie
In deze sectie zullen we een formele beschrijving van OCL expressies naar broncode geven, in
ons geval is dat JAVA. We zullen ons op een deelverzameling van de OCL taal focussen. Deze
deelverzameling zal attribuutmodelelementen, associatiemodelelementen, operaties en meer
geavanceerde constructies zoals tijdgerefereerde variabelen bevatten.
3.2.1 Vertaling van attributen en associaties
De aanwezigheid van attributen en associatie is niet zo maar toevallig in OCL expressies.
Attribuutwaarden stellen eigenschappen van klassen voor. Anderzijds representeren associatiewaarden
de relaties tussen de verschillende klassen in een model. Bij gevolg hebben allebei
een belangrijke rol en hun vertaling is wel nodig.
Een attribuut of associatie kan in een OCL expressie zowel expliciet als impliciet gerefereerd
worden. Indien men expliciet naar een contextuele instantiatie moet refereren, kan men gebruik
maken van het sleutelwoord self. Als de referentie naar een contextuele instantiatie
(in ons geval een attribuut of associatie) duidelijk is, is dit sleutelwoord optioneel.
Bij vertaling van het OCL sleutelwoord self naar JAVA beeld dit zich af op het sleutelwoord
this in JAVA. De waarde van het attribuut attribute is in JAVA te verkrijgen door de operatie
getAttribute() op te roepen. Eender welke attribuutreferentie in OCL wordt op bijbehorende
get operatie afgebeeld. Als we de volgende OCL expressie hebben:
self.attribute
wordt deze vertaald in JAVA op de volgende manier.
this.getAttribute()
De JAVA vertaling van associaties is als volgt: associaties worden afgebeeld op private JA-
VA attributen met de bijbehorende get operatie. Dat wil zeggen dat OCL navigatie binnen
associaties als een operatie oproep in JAVA gemodelleerd wordt. De OCL expressie

3.2. BESCHRIJVING VAN DE METHODOLOGIE 21
self.associationEnd
wordt getransformeerd naar de volgende JAVA code:
this.getAssociationEnd();
3.2.2 Vertaling van OCL operaties over basistypen
Deze sectie denieert de vertaling van operaties over basistypen. Met basistypen bedoelen
we hier de Boolean, Integer, Real en String typen. De vertaling van deze basistypen en
hun bijbehorende operaties is op zichzelf niet zo moeilijk. We kunnen voor elke van deze
operaties een implementatie in JAVA voorzien door middel van een van standaard bibliotheek
waarin voor elk type een klasse zal geimplementeerd worden en binnen zo'n klasse zullen de
bijbehorende operaties als statische methoden geimplementeerd worden. Vermits in JAVA
deze typen en hun bijbehorende operaties tegenhangers hebben verkiezen we hier om een
hergebruik van de JAVA API te maken. Bijgevolg is de vertaling van deze OCL operaties
eigenlijk een afbeelding op hun tegenhangers in JAVA. We zullen kort de vertaling van de meest
voorkomende operaties bespreken. We zullen deze vertaling ook in een tabelvorm voorstellen.
We hebben al gezegd dat er Boolean, Integer, Real en String basistypen in OCL zijn. We
beginnen met het Boolean basistype.
3.2.2.1 Boolean type
Een boolean type kan twee waarden hebben: false of true. JAVA biedt equivalente sleutelwoorden
en bijgevolg is de vertaling naar JAVA direct. Natuurlijk moeten de bijbehorende operaties
wel afgebeeld worden. In tabel 3.1 introduceren we het meest voorkomende booleaanse operaties.
Booleaanse operaties hebben twee delen, namelijk een rechter- en een linkerdeel. In
de tabel hieronder stelt 'a' het linker deel van deze operaties voor die een OCL expressies
is. Hetzelfde geldt voor het rechterdeel. Het resultaat van het toepassen van een booleaanse
operaties geeft een booleaanse waarde terug.
Operatie OCL notatie Java vertaling Type van het resultaat
or a or b a || b Boolean
and a and b a && b Boolean
exclusieve or a xor b (a || b) &&(a != b) Boolean
negation not a ! a Boolean
equals a = b a == b Boolean
not equals a b a != b Boolean
implies a implies b a ? b : true Boolean
Tabel 3.1: Standaard operaties voor de Boolean type
We gaan dat verduidelijken aan de hand van een voorbeeld voor de conjunctie en disjunctie
van twee booleaanse attributen. Stel dat we de volgende OCL expressie hebben:

22 HOOFDSTUK 3. METHODOLOGIE
self.attr1 and self.attr2 or self.attr3
Dit wordt getransformeerd naar de volgende JAVA code:
this.getAttr1() && this.getAttr2() || this.getAttr3();
De volgorde van deze booleaanse operaties is voor de JAVA vertaling ook behouden bij de
OCL expressie van daarboven.
3.2.2.2 Real en Integer types
Een Integer type stelt de natuurlijke getallen voor. Een Real type representeert het wiskundige
concept van de reële getallen. Bijgevolg zijn integers een subtype van de reële getallen.
Integers hebben tegenhangers in JAVA. Voor het Real type biedt JAVA float en double type
aan. Men moet bij de vertaling een van deze twee types kiezen. De standaard operaties over
Integer en Real types mogen op de java.lang.Math API afgebeeld woorden. In tabel 3.2
hieronder geven we een JAVA vertaling van deze operaties.
Operatie Notaties Java vertaling Resultaat
equals a = b a == b Boolean
not equals a b a != b Boolean
less a < b a < b Boolean
more a > b a > b Boolean
less or equal a

3.2. BESCHRIJVING VAN DE METHODOLOGIE 23
3.2.2.3 String type
Voor de vertaling van operaties over strings kan een groot deel van de java.lang.String API
opnieuw gebruikt worden. De operatie size() moet naar de methode length() in JAVA
vertaald worden. Indien we de gelijkheid van twee strings willen nagaan kunnen we in JAVA
gebruik maken van de equals() methode. Dit is samengevat in tabel 3.3.
Operaties Notaties Java vertaling Resultaat
concatenation str.concat(str) str.concat(str) String
size str.size() str.length() Integer
to lower case str.toLower() str.toLowerCase() String
to upper case str.toUpper() str.toUpperCase() String
substring str.substring(int,int) str.substring(int,int) String
equals str1 = str2 str1.equals(str2) Boolean
not equals str1 str2 ! str1.equals(str2) Boolean
Tabel 3.3: Standaardoperaties voor String type
3.2.3 Vertaling van OCL collectieoperaties
Voor we aan de vertaling van collectieoperaties beginnen moeten we eerst iets over OCL collectietypes
zeggen. Deze OCL collectietypes moeten op de collectietypen van een doeltaal
afgebeeld worden. Gelukkig biedt JAVA een brede waaier van collectietypes aan. Een mogelijke
afbeelding is voorgesteld in tabel 3.4.
OCL collectietype Java type Concreet Java type
Set Set HashSet
Sequence List ArrayList
Bag List ArrayList
OrderedSet List ArrayList
Tabel 3.4: Afbeelding van OCL collectie typen naar JAVA collectie typen
Een Set in OCL stelt een wiskundige verzameling voor. Deze Set bevat elementen zonder
duplicaten. Een OrderedSet is een Set waarbij zijn elementen geordend zijn. Bovendien een
OrderedSet bevat geen duplicaten.
Een Bag is een collectie waarbij duplicaten wel toegelaten zijn. Met andere woorden kan een
object meerdere keren een element van een Bag worden. In een Bag is er geen volgorde.
Een Sequence is een collectie waarbij de elementen geordend zijn. Een element kan meer dan
een keer deel van een Sequence maken.
In OCL hebben we twee typen van operaties over collecties. Operaties die over collecties
itereren en operaties die dat niet doen. De eerste soort noemt men collectieiteratoren en
de tweede eenvoudige collectieoperaties. We zullen eerst de vertaling van de tweede soort
beschrijven.

24 HOOFDSTUK 3. METHODOLOGIE
3.2.3.1 Eenvoudige collectieoperaties
De implementatie van eenvoudige collectieoperaties is meestal niet zo moeilijk. De meeste van
deze operaties hebben een tegenhanger in de JAVA API over collectietypen. Indien dat niet
het geval is zullen we voor deze operaties een aparte implementatie voorzien. Daarvoor zullen
we een soort van sjablonen gebruiken. In tabel 3.5 tonen we de meest gebruikte standaard
OCL operaties over alle collectietypen en hun JAVA tegenhangers.
OCL operatie Java Tegenhanger Omschrijving
excludes(object) ! contains(object) Geeft waar terug indien het object
geen element van de collectie is
excludesAll(collection) ! containsAll(collection) Geeft waar terug indien alle
elementen van de gegeven
collectie niet aanwezig
in de huidige collectie zijn
includes(object) contains(object) Geeft waar terug indien het object
een element van de collectie is
includesAll(collection) containsAll(collection) Geeft waar terug indien alle
elementen van de gegeven
collectie aanwezig in
de huidige collectie zijn
isEmpty() isEmpty() Geeft waar terug indien de collectie
geen enkel element bevat
notEmpty() ! isEmpty() Geeft waar terug indien de collectie
een of meerdere elementen bevat
size() size() Geeft het aantal elementen
in de collectie terug
Tabel 3.5: Standaardoperaties over alle soorten van collectie typen
3.2.3.2 Collectieiteratoren
Collectieiteratoren laten ons om over collecties te itereren. De collecties waarop deze operaties
toegepast zijn noemen we hier source. Ieder element van de source wordt tegen een expressie
geëvalueerd. Deze expressie noemen we body. In tabel 3.6 tonen we de collectieiteratoroperaties
over alle collectietypen.
Omdat de collectieiteratoren altijd over collecties itereren moet men deze iteraties in termen
van de doeltaal genereren. Bijvoorbeeld, zijn iteraties meestal in JAVA geimplementeerd met
behulp van de interface Iterator. We zullen hier namelijk deze constructie gebruiken om over
collectie te kunnen itereren.
De OCL collectieiteratoren (zie tabel 3.6) hebben geen tegenhangers in de JAVA Collection
API. Bijgevolg moeten we voor elke collectieiterator een methode creëren. Hiervoor zullen we
een soort van sjablonen gebruiken. In deze sjablonen zullen we een vaste en een variërende
stukcode hebben. De variërende code zullen we met een bold-italic lettertype noteren.

3.2. BESCHRIJVING VAN DE METHODOLOGIE 25
Operaties
any(expr)
collect(expr)
collectNested(expr)
exists(expr)
forAll(expr)
isUnique(expr)
iterate(...)
one(expr)
reject(expr)
select(expr)
sortedBy(expr)
Omschrijving
Geeft een willekeurig element uit de source collectie
terug waarvoor de expressie expr waar is
Geeft een collectie van objecten terug als resultaat
van de evaluatie van expr voor ieder element
uit de source collectie
Geeft een collectie van collecties terug als resultaat
van de evaluatie van expr voor ieder element
uit de source collectie
Geeft waar terug als er minstens een element in
de source collectie bestaat waarvoor expr waar is
Geeft waar terug als expr voor alle elementen in
de source collectie waar is
Geeft waar terug als expr een unieke waarde voor alle
elementen in de source collectie heeft
Itereert over alle elementen in de source collectie
Geeft waar terug als er juist een element in de source
collectie is waarvoor expr waar is
Geeft een deelcollectie van de source collectie terug
waarvoor voor ieder element uit de source collectie
expr niet waar is
Geeft een deelcollectie van de source collectie terug
waarvoor voor ieder element uit de source collectie
expr waar is
Geeft een collectie terug die alle elementen van de
source collectie bevat en geordend volgens expr zijn.
Tabel 3.6: Collectieiteratoren operaties over alle collectietypen
any operatie
Om eender welk element van een source collectie te verkrijgen die aan een bepaalde voorwaarde
voldoet kunnen we de any operatie gebruiken. De body parameter van deze operatie is een
booleaanse expressie. Deze operatie zal over alle elementen van de collectie itereren om een of
meer elementen te vinden die aan de body expressie voldoen. Indien er meer dan een element
is die aan de body conditie voldoet dan is willekeurig een van deze elementen teruggeven.
In onze implementatie wordt het eerste element teruggegeven. Anders is het resultaat niet
gedenieerd. De volgende OCL expressie representeert de any operatie met de bijbehorende
body conditie die op een source collectie toegepast is.
source->any(body)
De JAVA code ziet er zo uit:

26 HOOFDSTUK 3. METHODOLOGIE
Listing 5 Sjabloon voor OCL any operatie
ElementType result = null;
Iterator it = source.iterator();
while(it.hasNext()){
ElementType elem = (ElementType) it.next();
if(elem.body){
return elem;
}
}
return result;
Wat te merken is dat er weinig van de OCL code in de JAVA code terug te vinden is. Bovendien
is er een expliciete vermelding van het type van de elementen in de collectie source nodig. In
termen van JAVA noemt men dat casten. In dat fragment casten we naar elementen van type
ElementType.
one operatie
De one operatie geeft een booleaans resultaat terug. Indien er juist een element in de source
collectie is die aan de voorwaarde in de body voldoet geeft deze operatie als resultaat waar
terug.
source->one(body)
De JAVA code ziet er zo uit voor de one operatie:
Listing 6 Sjabloon voor OCL one operatie
Iterator it = source.iterator();
int nr = 0;
while(it.hasNext()){
ElementType elem = (ElementType) it.next();
if(elem.body){
nr++;
}
}
if(nr != 1){
return false;
}
return true;
collect operatie
De collect operatie itereert over een gegeven source collectie dan berekent een waarde voor
elk element in de collectie en verzamelt vervolgens de geëvalueerde waarden in een nieuwe
collectie. De elementen in de nieuwe collectie zijn niet noodzakelijk van hetzelfde type als de
source collectie. Het resultaat van een collect operatie is altijd een vlakke collectie.

3.2. BESCHRIJVING VAN DE METHODOLOGIE 27
source->collect(body)
De JAVA code ziet er zo uit:
Listing 7 Sjabloon voor OCL collect operatie
List result = new ArrayList();
Iterator it = source.iterator();
while(it.hasNext()){
ElementType elem = (ElementType) it.next();
Object bodyObj = elem.body;
if(bodyObj != null){
result.add(bodyObj);
}
}
return result;
iterate operatie
De iterate operatie is de meest fundamentele en ingewikkelde operatie die over collecties
itereert maar bijzonder generisch. De operaties reject, select, forAll, exists, collect
kunnen allemaal in termen van iterate beschrijven worden. De collect operatie beschreven
in termen van iterate is als volgt:
Listing 8 collect operatie in termen van iterate
collection->collect(x:T|x.property)
is identiek aan :
collection->iterate(x:T; acc: T2= Bag{}|
acc->including(x.property))
In deze thesis hebben we geen sjabloon voor iterate voorgesteld. We vinden dat wat men met
iterate wil uitdrukken kan in de meeste gevallen ook uitgedrukt worden met een specieke
collectieiterator. Bovendien is veel makkelijker en overzichtelijker indien we een collectieiterator
gebruiken dan gewoon de OCL iterate operatie bij run-time OCL. Indien we de OCL
expressies van Listing 8 met elkaar vergelijken dan is duidelijk dat de eerste indrukking overzichtelijker
is die de collectieiterator collect gebruikt. In werkelijkheid zal een implementatie
van de iterate operatie op zichzelf niet zo veel werk vragen.
exists operatie
Meestal wil men speciceren dat er minstens een element in een collectie is die aan een bepaalde
conditie voldoet. De exists operatie kan hiervoor gebuikt worden. Deze operatie geeft een
booleaans resultaat terug. Met andere woorden is het resultaat van deze operatie waar indien
er minstens een element in de collectie bestaat dat aan de voorwaarden gespeciceerd in de
body van de operatie voldoet. Indien we de volgende OCL expressie hebben

28 HOOFDSTUK 3. METHODOLOGIE
source->exists(body)
dan is de corresponderende JAVA code in Listing 9 te zien. Hier source is een collectie en
daarvoor gebruiken we de JAVA interface Iterator om over deze collectie te kunnen itereren.
De JAVA code ziet er zo uit:
Listing 9 Sjabloon voor OCL exists operatie
Iterator it = source.iterator();
while(it.hasNext()){
ElementType elem = (ElementType) it.next();
if(elem.body){
return true;
}
}
return false;
forAll operatie
Soms wil men dat er een beperking voor alle elementen uit een collectie geldt. In dat geval kan
hij de forall operatie gebruiken. Indien de OCL expressie in de body van de operatie voor
een of meer elementen uit de collectie faalt geeft de forall operatie niet waar als resultaat
terug. Gegeven de volgende OCL expressie
source->forall(body)
De vertaling van de OCL expressie naar JAVA die de forall operatie bevat is te zien in de
volgende sjabloon:
Listing 10 Sjabloon voor OCL forAll operatie
Iterator it = source.iterator();
while(it.hasNext()){
ElementType elem = (ElementType) it.next();
if(! elem.body){
return false;
}
}
return true;
isUnique operatie
Indien men in een collectie van elementen een unieke waarde voor ieder element in deze
collectie wenst moet hij de isUnique operatie gebruiken. De body van deze operatie is meestal
een expressie over een bepaalde eigenschap van het type van de betrokkene elementen in de
collectie. Het resultaat van deze operatie geeft een booleaanse waarde terug. Deze operatie zal
over alle elementen itereren en zal voor elk element de gevraagd waarde met de meegegeven

3.2. BESCHRIJVING VAN DE METHODOLOGIE 29
body waarde vergelijken. Indien geen enkel van deze waarden aan elkaar gelijk zijn geeft deze
operatie als resultaat waar terug. Voor de volgende OCL expressie hebben we
source->isUnique(body)
De JAVA code ziet er zo uit:
Listing 11 Sjabloon voor isUnique operatie
Iterator it = source.iterator();
List values = new ArrayList();
while(it.hasNext()){
ElementType elem = (ElementType) it.next();
if(values.contains(body)){
return false;
}
values.add(body);
}
return true;
select operatie
Zowel associaties als resultaten uit operaties kunnen een collectie teruggeven. Indien men in
een deelverzameling van deze collectie geïnteresseerd is kan hij de select operatie gebruiken.
Met andere woorden kan men in de body van deze operatie een lijst van criteria speciceren
om een selectie te maken. Bijgevolg is de body van de select operatie een booleaanse expressie.
Het resultaat van deze operatie resulteert in een deelverzameling van de oorspronkelijke
collectie. In deze deelverzameling zijn alleen maar elementen uit de oorspronkelijke collectie
geselecteerd die aan de voorwaarden van de body voldoen.
Gegeven de volgende OCL expressie, is source een collectie en body een booleaanse expressie.
De corresponderende JAVA sjabloon is hieronder getoond.
source->select(body)
De vertaling van de select operatie naar JAVA is als volgt:
Listing 12 Sjabloon voor OCL select operatie
Set result = new HashSet();
Iterator it = source.iterator();
while(it.hasNext()){
ElementType elem = (ElementType) it.next();
if(elem.body){
result.add(elem);
}
}
return result;

30 HOOFDSTUK 3. METHODOLOGIE
reject operatie
De reject operatie is analoog aan de select operatie met het enige verschil dat allen elementen
uit de source collectie geselecteerd moet worden waarvoor de expressie in de body van de
operatie tot niet waar moet evalueren.
source->reject(body)
Hieronder geven we de JAVA vertaling van de OCL reject expressie.
Listing 13 Sjabloon voor OCL reject operatie
Set result = new HashSet();
Iterator it = source.iterator();
while(it.hasNext()){
ElementType elem = (ElementType) it.next();
if(!elem.body){
result.add(elem);
}
}
return result;
sortedBy operatie
De operatie sortedBy resulteert in een gesorteerde verzameling. Het element in de body van
de operatie die de laagste waarde heeft komt als eerste element enz. Het type van de body
expressie moet de < operatie denieren die een booleaanse waarde moet teruggeven. Indien
we de volgende OCL expressie hebben
source->sortedBy(body)
De JAVA code ziet er zo uit:
Listing 14 Sjabloon voor OCL sortedBy operatie
List result = new ArrayList();
result.addAll(source);
Comparator comp = new ComparatorElementTypebody();
Collections.sort(result,comp);
return result;
Combinatie van collectieiteratoren
Het lichaam van een collectieoperatie kan veel complexer in vergelijking met de vorige voorbeelden
uitzien wanneer we een combinatie van collectieiteratoren nemen. In zulke gevallen
wordt onze JAVA code heel wat ingewikkeld en moeilijk om de OCL code te herkennen. We
gaan dat aantonen aan de hand van een voorbeeld.

3.2. BESCHRIJVING VAN DE METHODOLOGIE 31
source1->select(source2->forall(body))
In deze OCL expressie hebben we met twee collecties te maken. De ene die over source1
itereert en de andere die over source2 itereert. In OCL is wel mogelijk dat we meerdere
geneste operaties over collecties kunnen hebben alhoewel dat uitzonderlijk is. De vertaalde
JAVA code is als volgt:
Listing 15 Sjabloon voor combinatie van collectieiteratoren
Iterator it1 = source1.iterator();
Set result = new HashSet();
while(it1.hasNext()){
Source1 s1 = (Source1) it.next();
Iterator it2 = s1.source2.iterator();
boolean forAllRes = true;
while(it2.hasNext()){
Source2 s2 = (Source2) it2.next();
forAllRes = forAllRes && (s2.body);
}
if(forAllRes ){
result.add(s1);
}
}
return result;
We kunnen samenvatten dat iedere collectieoperatie over een sjabloon moet beschikken. Deze
sjabloon moet vervolgens ingevuld worden met de elementen van de OCL expressies. Er
mogen nog wat optimalisaties over de sjablonen gemaakt worden. Natuurlijk resulteert dat in
ingewikkelde JAVA code. Bijvoorbeeld, de sjabloon van hierboven kan herschrijven worden.
Met andere woorden moet de iteratie stopen zodra het resultaat fout is.
Een andere oplossing voor geneste collectieiteratoren is om gewoon de voorgestelde sjablonen
voor elke collectieiterator te gebruiken. In ons voorbeeld van daarboven passen we eerst de
sjabloon voor de select operatie toe. Vervolgens roepen we de sjabloon voor de forAll operatie
op in de plaats waarin we de body van de select operatie nagaan. Op deze manier
moeten we geen nieuwe sjablonen voor geneste collectieiteratoren denieren die wat gecompliceerd
kunnen zijn. Als resultaat verkrijgen we in dit voorbeeld twee in plaats van een hulp
methoden. Daarenboven zijn de verkregen hulp methoden overzichtelijk en eenvoudig.
Met deze oplossing reduceren we niet alleen de complexiteit van onze sjablonen maar ook
het aantal sjablonen die in elk geval gedenieerd moeten worden door een hergebruik van al
bestaande sjablonen te maken.
3.2.3.3 Inkapseling van sjablonen voor collectieoperaties in JAVA methoden
De daarnet beschreven sjablonen voor OCL collectieoperaties moeten op een of andere manier
in JAVA methoden ingekapseld worden. Hieronder geven we een aantal mogelijke oplossingen
voor dit probleem.

32 HOOFDSTUK 3. METHODOLOGIE
Een eerste oplossing die wie hier voorstellen is als volgt: telkens we een collectieoperatie
tegenkomen dan gaan we een hulpmethode voor deze genereren in de klasse (context) waarbij
deze hoort. In deze context zijn hulpmethode OCL collectieoperaties die geen tegenhangers
in JAVA Collection API hebben. Bijgevolg is er de mogelijkheid van gedupliceerde methoden
met dezelfde inhoud niet uitgesloten.
Een tweede oplossing zou kunnen zijn om een keer een standaard bibliotheek te genereren die
alle hulpoperaties zal bevatten die geen tegenhangers in de JAVA API hebben. Vermits onze
sjablonen zowel een vast als een variabel deel hebben, moeten we in de signatuur van deze
operaties als argumenten de source collectie en de body expressie meegeven om het variabele
gedeelte in te vullen. Dit lijkt een goede oplossing maar aan de andere hand moeilijk te
implementeren.
Een derde oplossing zou kunnen zijn om in plaats van een standaard bibliotheek met statische
methoden te genereren nemen we de eerste oplossing en passen we paar verbeteringen erop toe.
Voor we een hulpoperatie gaan genereren, gaan we eerst nagaan of al deze niet gegenereerd
was. Indien dat het geval was, moeten we deze niet meer gaan genereren. Om deze aanpak
te kunnen implementeren, moeten we ergens alle onze gegenereerde hulpoperaties met hun
bijbehorende source collectie en de body expressies bijhouden.
In deze thesis gebruiken we de eerste aanpak. De uiteindelijke geproduceerde code zorgt voor
heel wat duplicatie van methoden bij gebruik van collectieiteratoren. Indien dat door een
programmeur handgeschreven is kan dat heel wat lastig zijn en tot fouten leiden. Vermits de
code door een tool gegenereerd is, is deze code replicatie niet een probleem. Het enige nadeel
is de grootte van de geproduceerde code. In alle systemen behalve embedded systemen is dat
geen probleem. In embedded systemen waarin de geheugengrootte beperkt is is deze aanpak
minder geschikt. Maar dit ligt buiten het bereik van onze thesis.
3.2.4 Vertaling van OCL if-then-else expressies
Er zijn twee mogelijkheden voor de vertaling van de OCL if-then-else constructie naar
JAVA. Ofwel gebruiken we de corresponderende if-then-else constructie in JAVA ofwel de
korte notatie voor deze constructie. Als voorbeeld geven we de volgende OCL if-then-else
expressie.
Listing 16 Een voorbeeld van een OCL if-then-else expressie
if
then
else
endif
In dit eenvoudige voorbeeld hebben we geen collectieoperaties (collectieiteratoren) opgenomen
maar indien dat het geval was dan zouden we extra hulpmethoden genereren. De JAVA code
maakt gebruik van de verkorte notatie van de if-then-else constructie ook bekend als de
ternaire operator ( ? : ). We gebruiken toch de verkorte notatie van de if-then-else
constructie want deze past eleganter in onze sjablonen.

3.2. BESCHRIJVING VAN DE METHODOLOGIE 33
Listing 17 Sjabloon OCL if-then-else expressie
return (< translation of boolean OCL expression >) ?
: ;
3.2.5 Vertaling van OCL let expressies
In OCL let expressies zijn er lokale variabelen gedenieerd. De implementatie van de let
expressie in JAVA gebeurt op dezelfde wijze. In de sjabloon voor de let expressie worden
deze lokale variabelen ook gedenieerd. Er moet wel aandacht aan de scope van de lokale
variabelen besteed worden. De typen van deze variabelen in de OCL let expressie moeten op
de juiste JAVA typen afgebeeld worden. Dat is het variabel gedeelte voor de let sjabloon. In
de JAVA code is dat te zien met bold-italic lettertypen.
Listing 18 Een voorbeeld van een OCL let expressie
let
tmp1 : Integer = self.attribute1,
tmp2: String = self.attribute2
in
if self.attr3 then
tmp1 >= 18
else tmp1 < 18
endif
De bovenstaande OCL let-expressie illustreert hoe de vertaling naar JAVA gebeurt. Er
kunnen ook nog collectieiteratoren in het 'let' of 'in' deel van de let expressie voorkomen.
In dit geval worden hulpmethoden voor deze collecties gegenereerd.
Listing 19 Sjabloon voor OCL let expressie
boolean result = false;
int tmp1 = this.getAttribute1() ;
String tmp2 = this.get Attribute2() ;
result = (this.getA ttr3() ? tmp1 >= 18 : tmp1 < 18;
return result;
3.2.6 Vertaling van klasse-invarianten
Elke invariant wordt vertaald in een publieke booleaanse methode. Bij de naam van deze
booleaanse methoden wordt de naam van de invariant geconcateneerd. Op deze manier is er
een garantie voor consistentie tussen de verschillende gegenereerde invarianten. De publieke
visibiliteit van de methode zorgt voor dat instantiaties van de klasse waarin deze methode
gedenieerd is een toegang tot deze methode krijgen. Hieronder tonen we een sjabloon van
een methode voor een klasse-invariant die een vast en een variabel gedeelte heeft.

34 HOOFDSTUK 3. METHODOLOGIE
Listing 20 Sjabloon voor inkapseling van OCL invariant expressie in JAVA methode
public boolean checkInvNameOfInvariant(){
return < translation of inv OCL expressie >;
}
OCL expressies mogen constructies bevatten die hulpmethoden vereisten. Voorbeeld van zulke
constructies hebben we al in de vorige sectie gezien, namelijk operaties die over collecties
itereren. In dit geval worden een of meerdere hulpmethoden gegenereerd. Hier moeten we ook
voor unieke namen van deze hulpmethoden zorgen. Dezelfde benadering als bij de namen van
klasse-invarianten is genomen om het probleem van name clashes op te lossen.
Dan zal onze sjabloon er als volgt uitzien.
Listing 21 Sjabloon voor inkapseling van OCL invariant expressie in een JAVA methode
public boolean checkInvNameOfInvariant(){
return typeOfOCLExpressionNameOfInvariant();
}
private type typeOfOCLExpressionNameOfInvariant(){
< template for the corresponding OCL expression >;
}
Met typeOfOCLExpression bedoelen we het type van een OCL expressie. Bijvoorbeeld dat
kan een collectieiterator zijn (forall, exists, ...) of een let expressie of een andere OCL
expressie zijn.
3.2.7 Vertaling van pre- en postcondities
De vertaling van pre- en postcondities heeft een aantal gelijkenissen met de vertaling van
klasse-invarianten: elke pre- en postconditie zal in een aparte booleaanse methode ingekapseld
worden. Er zullen nog hulpmethoden gegenereerd worden indien dit nodig zijn.
Natuurlijk moeten we niet vergeten dat pre- en postcondities altijd bij operaties horen. Bijgevolg
moeten ze bij het lichaam van de operatie zelf ingevoegd worden. Voor precondities is
dat in het begin van de operaties, juist voor het uitvoeren van deze en voor postcondities is
dat juist na het uitvoeren van de operatie.
De sjabloon is hieronder te zien:

3.2. BESCHRIJVING VAN DE METHODOLOGIE 35
Listing 22 Sjabloon voor pre- en postcondities
public boolean checkPreNameOfPreconditionNameOfOperation(){
return ;
}
public boolean checkPostNameOfPostconditionNameOfOperation(){
return ;
}
operation(){
assert checkPreNameOfPreconditionNameOfOperation();
//
// body of the operation
//
assert checkPostNameOfPostconditionNameOfOperation();
//return statement if not void type
}
Klasse-invarianten zijn niet expliciet in operaties opgenomen maar ze moeten toch nagegaan
worden na het uitvoeren van publieke methoden en constructoren. We hebben nog niet getoond
hoe we dat zullen doen. In sectie 3.3 en 3.4 zullen we dat grondig bespreken.
3.2.8 Vertaling van meer geavanceerde constructies
3.2.8.1 Vertaling van het sleutelwoord @pre
Het sleutelwoord @pre representeert de waarde van een attribuut of associatie op het begin
van de uitvoering van een operatie. Dit sleutelwoord moet na de naam van het betrokken
attribuut of associatie vermeld worden. Vermits hier duidelijk te zien is dat we met variabelen
over tijd te maken hebben, moeten tijdelijke variabelen in de vertaalde code voorzien worden.
Een voorbeeld is de volgende OCL postconditie in de context van een operatie operation die
tot de klasse Class behoort.
context Class :: operation(attribute2 : Integer)
post p1:
attribute = attribute@pre + attribute2
Bij de vertaling naar JAVA moeten we een tijdelijke variabele denieren die de waarde van het
attribuut attribute bijhoudt. We zullen deze variabele old_attribute noemen. Old_attribute
moet een kloon of kopie zijn maar geen kopie van de referentie want de gerefereerde waarde
zal tijdens het uitvoeren van de operatie veranderen.

36 HOOFDSTUK 3. METHODOLOGIE
Listing 23 Sjabloon voor OCL @pre expressie
void operation(int attribute2){
int old_attr = this.getAttribute();
// ...
//
// ...
assert checkPostP1Operation(old_attr,attribute2);
}
public boolean checkPostP1Operation(int old_attr, int i){
return this.getAttribute() == old_attr + i;
}
Indien we tijdelijke objecten willen bijhouden gebruiken we dan een kopie-constructor. Kopieconstructors
moeten dan in de klasse waarin de betrokken operatie behoort gedenieerd worden.
Vervolgens mogen we de sjabloon van daarvoor toepassen. De JAVA code tonen we
hieronder:
Listing 24 @pre object
void operation(Object object2){
Object old_obj = new Object(obj);
// ...
//
// ...
assert checkPostP1Operation(old_obj,object2);
}
public boolean checkPostP1Operation(Object old_obj, Object object2){
return this.getObject().getProperty() ==
old_obj.getProperty() + object2.getProperty();
}
3.2.8.2 Het sleutelwoord result
Het sleutelwoord result geeft de terugwaarde van een operatie terug indien er een is. Bijgevolg
is het type van result bepaald door het terugtype van de operatie. Dit sleutelwoord wordt
gebruikt bij postcondities van operaties.
Listing 25 Een voorbeeld van het OCL result sleutelwoord
context Class :: operation(attribute2 : Integer):Integer
post p2: result = attribute2*1000
De resulterende JAVA code is:

3.3. NAÏEVE AANPAK 37
Listing 26 Sjabloon voor OCL result sleutelwoord
int operation(int attribute2){
int result = 0;
// ...
//
// ...
assert checkPostP2Operation(result,attribute2);
return result;
}
public boolean checkPostP2Operation(int result,int i){
return result == this.getAttribute2()*1000;
}
3.3 Naïeve aanpak
In deze sectie illustreren we de meest evidente aanpak. In deze aanpak worden klasseinvarianten,
pre- en postcondities ingekapseld in booleaanse methoden. Klasse-invarianten
moeten waar zijn op ieder consistent moment. Met andere woorden zijn klasse-invarianten
gecontroleerd voor en na elke uitvoering van publieke methodes en constructoren. Alle klasseinvarianten
zijn verder in een gemeenschappelijke booleaanse methode ingekapseld door een
conjunctie van deze invarianten te nemen. Pre- en postcondities worden respectievelijk voor
en na de executie van de publieke methoden en constructoren nagegaan.
3.3.1 Vertaling van invarianten
In de vorige sectie hebben we een beschrijving van een mogelijke vertaling van OCL expressies
naar JAVA gezien. Nu kunnen we deze methodologie op klasse-invarianten in een model
toepassen.
3.3.1.1 Inkapseling van een invariant in een booleaanse methode
De inkapseling van klasse-invarianten en de bijbehorende sjablonen waren al in de vorige
sectie besproken. Hier zullen we meer uitgebreid deze vertaling bespreken. Stel voor dat we
een klasse met een aantal klasse-invarianten hebben:
Listing 27 voorbeeld
context ClassA
inv invariant_1:
inv invariant_2:
inv invariant_3: -> forall()
De vertaling van deze klasse-invarianten naar JAVA is hieronder gegeven. Elke invariant is
vertaald in een booleaanse methode. Bij de naam van elke van deze booleaanse methoden is
de naam van de invariant geconcateneerd. Op deze manier is er een garantie voor consistentie
tussen de verschillende gegenereerde invarianten. In invariant_3 zien we dat we met een

38 HOOFDSTUK 3. METHODOLOGIE
collectieiterator (forall operatie) te maken hebben. In dit geval is een aparte methode
gegenereerd waarin alle bewerkingen omtrent deze invariant ingekapseld zijn.
Listing 28 Sjabloon vertaling van klasse invarianten
public boolean checkInvInvariant1(){
return ;
}
public boolean checkInvInvariant2(){
return ;
}
public boolean checkInvInvariant3(){
return forallInvariant3();
}
private boolean forallInvariant3(){
}
3.3.1.2 Inkapseling van alle klasse-invarianten in een gemeenschappelijke methode
Eens we een implementatie voor alle invarianten hebben kunnen we deze in een gemeenschappelijke
booleaanse methode inkapselen. Hierin geven we een conjunctie van alle invarianten
terug. Deze methode zal vervolgens na iedere afhandeling van een publieke constructor of
methode opgeroepen worden. Dat zal gebeuren door de assert statement die we in het begin
van dit hoofdstuk besproken hebben. Op deze manier controleren we altijd alle invarianten.
Dat levert een overhead van testen die overbodig kunnen zijn. We zullen een meer geavanceerde
aanpak in volgende sectie bespreken. Hieronder tonen we de JAVA code die alle OCL
invariant-expressies in een gemeenschappelijke methode inkapselt.
Listing 29 Sjabloon checkAllInvariants
public boolean checkAllInvariants(){
return checkInvInvariant1()&&
checkInvInvariant2()&&
checkInvInvariant3();
}
3.3.2 Vertaling van pre- en postcondities
Tot nu hebben we gezien hoe klasse-invarianten vertaald kunnen worden. Hier gaan we bespreken
hoe de vertaling van de pre- en postcondities naar JAVA gebeurt. Pre- en postcondities
horen altijd bij operaties. Bijgevolg zullen we deze in de operaties implementeren waarin ze
gedenieerd zijn. Het mechanisme dat we hier gaan gebruiken is de JAVA assert. Laat ons
veronderstellen dat we een operatie operation1 in de context van een klasse ClassA hebben.
Deze operatie heeft twee precondities en een postconditie. De OCL code is hieronder gegeven:

3.3. NAÏEVE AANPAK 39
Listing 30 voorbeeld operatie met pre- en postcondities
context ClassA :: operation1() :
pre pre1:
pre pre2:
post post1:
Voor elke pre- en postconditie zullen we een aparte booleaanse methode genereren. Daarna
voegen we de pas gegenereerde pre- en postconditiemethoden in in de juiste plaatsen van onze
operatie. Voor precondities is dat in het begin van de operatie. Voor postcondities is dat op
het einde van deze operatie. Het invoegen van deze code gebeurt door de assert constructie
die we in het begin van dit hoofdstuk besproken hebben.
De naam van elke pre- en postconditiemethode is geconcateneerd met de naam van de preof
postconditie die ze voorstellen en met de naam van de operatie waartoe ze behoren. Dat
zorgt voor unieke namen van methoden en lost het probleem van name clashes op.
De JAVA code ziet er als volgt uit:
Listing 31 Sjabloon voor pre- en post-condities bij de naïeve aanpak
operation1(){
assert(checkAllInvariants());
assert(checkPrePre1Operation1());
assert(checkPrePre2Operation1()) ;
//
// body of operation
//
assert(checkPostPost1Operation1());
assert(checkAllInvariants());
}
private boolean checkPrePre1Operation1(){
return ;
}
private boolean checkPrePre2Operation1(){
return ;
}
private boolean checkPostPost1Operation1(){
return ;
}
We moeten ook niet vergeten dat bij operaties klasse-invarianten ook gecontroleerd moeten
worden alhoewel ze niet opgenomen zijn in de operatie. De controle op invarianten moet
voor en na de uitvoering van elke publieke methode en na de uitvoering van elke constructor
gebeuren. Bijgevolg moeten we een assertie van alle invarianten toevoegen. Dat is te zien in
de eerste en laatste regel van de JAVA vertaling voor de operation1() methode.

40 HOOFDSTUK 3. METHODOLOGIE
3.4 Intelligente aanpak
De aanpak die we in de vorige sectie voorgesteld hebben is de meest intuïtieve aanpak. Voor
elke uitvoering van een publieke operatie en na elke uitvoering van een publieke operatie of
constructor toetsen we alle klasse-invarianten. We doen dat door een conjunctie van deze
invarianten te nemen.
In deze sectie stellen we een intelligentere aanpak voor. In plaats van alle klasse-invarianten
te controleren na het uitvoeren van een publieke operatie gaan we alleen maar de relevante
klasse-invariante testen.
3.4.1 Het Idee
De condities die in de klasse-invarianten vastgesteld zijn moeten altijd voldaan voor alle instantiaties
zijn waarvoor deze voorwaarden gedenieerd zijn. Wanneer een instantiatie van
toestand verandert door bijvoorbeeld een publieke operatie erop toe te passen dan moeten
alle condities in de klasse-invarianten ook voldaan zijn. Echter betrekken operaties vaak niet
alle condities van klasse-invarianten op de toegepaste instantiaties. Bijgevolg is de controle
van alle klasse-invarianten overbodig. Bovendien is op deze manier de uitvoeringstijd van
applicaties verhoogd. Een reductie van controles op de geldigheid van klasse-invarianten en
uitvoeringstijd van applicaties is wat we met de intelligente aanpak willen bereiken.
We gaan nu een constructie voorstellen voor de implementatie van een intelligente aanpak.
Binnen deze intelligente aanpak hebben we twee mogelijke implementaties bedacht. De ene is
door een graaf te construeren en de andere is op string matching gebaseerd. We sluiten hierbij
niet uit dat er nog andere manieren zijn om de intelligente aanpak te kunnen implementeren.
3.4.2 Graafconstructie
Het idee van deze aanpak is om een twee-stap graaf te construeren. We willen een afhankelijkheid
tussen invarianten en postcondities van operaties bouwen. In deze constructie hebben
we twee stappen. De eerste stap noemen we post-code generatie en de tweede stap noemen
we pre-compilatie. Bij de eerste stap kijken we naar de postcondities van onze methoden. Bij
de tweede stap kijken we naar de implementaties van onze methoden.
Bij de post-code generatie stap controleren we of de toestand van een variabele of object
veranderd is. Om dat te kunnen doen, doen we beroep op de postcondities van onze operaties
en de klasse-invarianten. Op deze manier kunnen we beslissen welke invarianten na
het uitvoeren van de operatie nagegaan moeten worden. Hierbij zullen niet alle betrokken
objecten of variabelen van toestand veranderen. Bijgevolg verwachten we dat de gegenereerde
verzameling van relevante klasse-invarianten kleiner is.
Indien onze operaties geen postcondities bevatten dan stappen we naar de tweede stap over,
namelijk de pre-compilatie stap.
Bij de pre-compilatie stap kijken we naar alle referenties van de objecten of variabelen betrokken
bij de implementatie van de methode. Vervolgens zoeken we in welke klasse-invarianten
deze variabelen te vinden zijn. Op deze manier selecteren we een deelverzameling van alle

3.4. INTELLIGENTE AANPAK 41
Figuur 3.1: Afhankelijkheid tussen klasse invarianten en postcondities horend bij operaties
klasse-invarianten. Deze deelverzameling is in ieder geval kleiner of gelijk dan de oorspronkelijke
verzameling van alle klasse-invarianten.
Kijken in de broncode van de operatie (pre-compilatie stap) voor variabelen die van toestand
veranderen kan soms lastig zijn. Indien een operatie een andere operatie oproept en deze op
zijn beurt een derde operatie oproept dan ontstaat er een geneste oproep van operaties die tot
een serie van complexe testen leidt.
Laat ons dit uitleggen aan de hand van een klein voorbeeld. Ons voorbeeld heeft drie klasseinvarianten
en een operatie met een postconditie.
Listing 32 voorbeeld
context Class
inv inv1: age > 18
inv inv2: firstName->size()->notEmpty()
inv inv3: lastName->size()->notEmpty()
context Class :: method2()
post post1: lastName = firstName + 'Jr'
In de post-code generatie stap gaan we naar variabelen of objecten kijken die van toestand
veranderen. In ons voorbeeld verandert allen maar de variabele lastName van toestand. Bijgevolg
moeten we alleen inv3 controleren. De corresponderende JAVA code is hieronder
gegeven:

42 HOOFDSTUK 3. METHODOLOGIE
Listing 33 sjabloon post-code
method2(){
//
// body of operation
//
assert(checkPostPost1Method2());
assert(checkInvInv3());
}
In de pre-compilatie stap is de verzameling van klasse-invarianten die gecheckt moeten worden
groter. Hier moeten we naar alle variabelen die betrokken (gerefereerd) zijn in de implementatie
van deze operatie gaan kijken. De variabele betrokken bij inv1 wordt niet gerefereerd
in deze operatie. Daarom beschouwen we deze niet. De variabelen lastName en rstName
worden wel gerefereerd. Deze zijn in inv2 en inv3 betrokken en bijgevolg moeten we deze
twee invarianten controleren. De gegenereerde JAVA code zou zo eruitzien:
Listing 34 sjabloon pre-compilatie
method2(){
//
// body of operation
//
assert(checkPostPost1Method2());
assert(checkInvInv2());
assert(checkInvInv3());
}
3.4.3 String matching
String matching is een lichte versie van de graafconstructie aanpak. Bij deze aanpak wordt geen
expliciete graaf opgebouwd. Hierbij maken we gebuikt van reguliere expressies. Vervolgens
passen we deze reguliere expressies op de postcondities van de operaties toe. Met andere
woorden om te bepalen of een variabele of object in een postconditie van toestand veranderd
is, moet deze aan de linkerkant van een toekenningsoperator zitten of moeten er operaties erop
uitgevoerd worden. Vervolgens wordt het relevante object of variabele (die in een postconditie
van toestand verandert) in alle klasse-invarianten opgezocht. Indien deze in een van de klasseinvariante
betrokken is, dan is deze invariant geselecteerd (toegevoegd aan de verzameling van
relevante klasse-invarianten).
3.4.4 Vertaling van klasse-invarianten
De vertaling van klasse-invarianten is gebaseerd op de sjablonen die we in sectie 3.2 voorgesteld
hebben. Vervolgens zijn deze sjablonen in booleaanse methoden ingekapseld. In subsectie
3.4.4.1 gaan we dat bespreken.

3.5. EVALUATIE 43
3.4.4.1 Inkapseling van een invariant in een booleaanse methode
Inkapseling van klasse-invarianten bij het gebruik van de intelligente aanpak verschilt niet
van de inkapseling van klasse-invarianten bij het gebruik van de naïeve aanpak. Elke klasseinvariant
is in een booleaanse methode ingebakken. Voor meer informatie verwijzen we naar
sectie 3.3.1.1
Wat hier meer aandacht vereist is de inkapseling van de relevante klasse-invarianten in een
gemeenschappelijke booleaanse methode. Dat gaan we hieronder bespreken.
3.4.4.2 Inkapseling van alle relevante klasse-invarianten in een gemeenschappelijke
booleaanse methode
Bij de naïeve aanpak hebben we gezien dat alle klasse-invarianten in een gemeenschappelijke
methode ingepakt waren door een conjunctie van deze te nemen.
Een mogelijke oplossing voor de intelligente aanpak is opnieuw een conjunctie van de relevante
klasse-invarianten te nemen die vervolgens in een gemeenschappelijke methode ingekapseld
worden. Het bepalen van de verzameling van relevante klasse-invarianten hangt af van de
postconditie of de implementatie van een publieke methode. Wat een nadeel hier kan zijn
is dat we telkens voor elke operatie een gemeenschappelijke methode zullen hebben die een
conjunctie van de bijbehorende relevante klasse-invarianten zou bevatten. Daarom stellen we
hieronder een andere oplossing voor.
Een tweede oplossing is om in plaats van een conjunctie van alle relevante klasse-invarianten
te nemen, voegen we elke relevante klasse-invariant op het einde van een methode toe door
gebruik van de assert constructie te maken. Met andere woorden zijn de relevante klasseinvarianten
bij een operatie niet in een gemeenschappelijke methode ingepakt. Op deze manier
verwijderen we de overhead van generatie van methoden die de geldigheid van klasseinvarianten
voor elke operatie gaan controleren.
3.4.5 Vertaling van pre- en postcondities
Voor de vertaling van pre- en postcondities van een methode verwijzen we naar 3.3.2. Het
enige verschil dat hier zou kunnen zijn is dat de gemeenschappelijke methode omtrent het
nagaan van klasse-invarianten op basis van subsectie 3.4.4.2 zou gegenereerd worden. Met
andere woorden kunnen we ofwel een conjunctie van de relevante klasse-invarianten nemen
ofwel de relevante klasse-invarianten afdrukken door de assert constructie te gebruiken.
3.5 Evaluatie
In deze sectie zullen we de naïeve en de intelligente aanpak evalueren in functie van uitvoeringstijd.
Om dat te kunnen doen hebben we een klein lopend voorbeeld bedacht (zie Figuur
3.1). Daarna hebben we manueel de code met de bijbehorende beperkingen voor de naïeve en
de intelligente aanpak gemodelleerd.

44 HOOFDSTUK 3. METHODOLOGIE
Wat wij met dit voorbeeld willen meten is de verhouding van de twee aanpakken ten opzichte
van elkaar. In de naïeve aanpak hebben we op iedere uitvoering van een publieke methode
alle gedenieerde klasse-invarianten getest. Bij de intelligente aanpak hebben we maar een
deelverzameling van alle klasse-invarianten gecontroleerd. Deze deelverzameling is afhankelijk
van de opgeroepen operatie.
Ons lopend voorbeeld bestaat uit vijf klassen met een totaal van 21 klasse-invarianten.
Om betrouwbare uitvoeringstijd te verkrijgen hebben we de testen 100000 keer in een lus laten
draaien. Op deze manier verkrijgen we een acceptabele meting voor onze testverzameling.
Het experiment wordt uitgevoerd op een PC 1.4 Ghz machine met 512 MB RAM geheugen
en Windows XP als besturingssysteem.
De resultaten wijken niet veel van onze veronderstellingen af. We hebben een verschil in
uitvoeringstijd van 1.6 keer meer bij de naïeve aanpak dan bij de intelligente aanpak gemeten
op voorwaarde dat onze methoden geen computationeel intensieve implementaties bevatten.
De gemeten factor van 1.6 kan sterk variëren. In ons experiment is het nagaan van de klasseinvarianten
de dominante operatie in een methode en vandaar komt deze versnelling tot 40
percent bij de intelligente aanpak. Indien onze methoden computationeel intensieve algoritmes
bevatten of grote bestanden aan lezen of wegschrijven zijn dan wordt het nagaan van
consistentie van klasse-invarianten niet meer de dominanten factor. Dan verwachten we bijna
gelijke metingen te krijgen zowel voor de intelligente aanpak als voor de naïeve aanpak.
aanpak gemetentijd met init gemetentijd zonder init
naïeve 8.6 sec 3.4 sec
intelligente 5.2 sec 0.4 sec
Tabel 3.7: De resultaten van de evaluatie van naïeve en de intelligente aanpak
Indien we de initialisatie van de objecten en de oproep van constructoren buiten de lus doen,
hebben we een factor van 7.9 gemeten. In dit geval is de naïeve aanpak tot bijna 8 keer
trager dan de intelligente aanpak. Dit is te wijten aan het feit dat in JAVA de initialisatie
van objecten en de oproep van constructoren veel tijd vraagt. Indien we de initialisatie buiten
de lus laten dan wordt duidelijk dat de dominante factor het nagaan van voldoening van
klasse-invarianten wordt en bijgevolg verkrijgen we deze factor van bijna 8.
Ons voorbeeld bestaat maar uit een model uit 5 klassen en 21 invarianten. In totaal zijn er 8
publieke operaties opgeroepen. We verwachten dat het toepassen van de intelligente aanpak
bij grootschalige systemen toch een voordeel over de naïeve aanpak zou hebben.
De code van ons experiment is terug te vinden op de CD horende bij deze thesis.

3.5. EVALUATIE 45
Figuur 3.2: Klassediagram van het lopende voorbeeld.

Hoofdstuk 4
Realisatie in HAT
In dit hoofdstuk gaan we eerst een inleiding tot het HAT tool geven. Vervolgens gaan we
beschrijven hoe de methodologie die we in hoofdstuk 3 besproken hebben in de context van
het HAT tool kunnen toepassen. Namelijk welke stukken van de methodologie mogen wel
geimplementeerd worden in HAT en welke niet.
4.1 HAT
Het HAT tool van de rma E2S (onlangs hernoemd naar ATO) is een UML tool dat Agile
MDA ondersteunt. De architectuur van dit tool bestaat uit drie stukken.
1. UML editor. Dat is het belangrijkste tool en biedt een grasche interface om applicatiemodellen
te denieren, samenhangendheid van constraints na te gaan, transformaties
van modellen naar andere modellen of naar broncode uit te voeren en documenten te
genereren. Al dat wordt ondersteunt door verschillende proelen. UML proelen worden
in de interactieve prole builder gedenieerd en documentproelen in de interactieve
document generator.
• Een UML proel wordt gebruikt om de vereiste grasche representatie van verschillende
objecten te tonen of beperkingen na te gaan of een model in een ander model
te transformeren en code te genereren.
• Een documentproel wordt gebruikt om de vereiste documenten van een gegeven
UML model te produceren
2. Interactive prole builder. Een UML proel bevat OCL constraints op het model,
modeldenities, modeltransformaties, codegeneratoren, specicaties van diagrammen,
grasche representatie van klassen, stereotypen, ... enz.
3. Interactive document generator. Deze generator maakt gebruik van documentpro-
elen waarin de gebruiker de inhoud van de nodige document denieert en de volgorde
beschrijft waarin de data van een UML model moet verschijnen.
46

4.1. HAT 47
Figuur 4.1: Architectuur van de Agile MDA Tool
Figuur 4.1 geeft een overzicht van de architectuur van dit Agile MDA tool. De modeltransformatie
en codegeneratie gebeurt aan de hand van de UML proelen. Deze proelen
moeten eerst in de UML editor ingeladen worden. Binnen zo'n proel speciceert men een
representatie van een UML model en hoe het model getransformeerd moet worden.
De interactive prole editor biedt een interface om UML proelen te denieren en bewerken.
Deze laat ons toe om zowel modelelementen binnen een domein te denieren als om
beperkingen en codegeneratoren over dit domein te speciceren.
De run-time OCL constraints die in het model zitten mogen ook geëvalueerd worden. Men
moet gewoon voor elke OCL constraint op het UML model de functie GenerateCode() oproepen
die drie argumenten meekrijgt. De eerste is een stringwaarde die de operatie bevat
om een generator op te roepen, de tweede is het tekstbestand waarin de gegeneerde code geschreven
zal worden en de derde is een stringwaarde die gebruikersgedenieerde inhoud bevat
(bijvoorbeeld contextinformatie). We mogen verschillende generatoren voor dezelfde run-time
OCL expressie meegeven indien dat nodig is. Deze operatie transformeert de run-time OCL
expressie naar een expressieboom. De elementen in deze boom zijn OCL modelelementen
die aan het OCL metamodel corresponderen. Dit metamodel denieert verschillende soorten
van OCL expressiemeta-elementen: literalen, if-expressie, let-expressie, enz. Een deel van het
OCL metamodel is te zien in Figuur 4.2. De meegegeven generator aan de GenerateCode()
operatie gaat vervolgens schrijvers voor elk OCL modelelement oproepen. Deze schrijvers
zullen eigenlijk de code voor onze applicatie produceren voor de gegeven OCL expressies.
In volgende sectie zullen we de vertaling van run-time OCL expressie naar JAVA bespreken
met behulp van het HAT tool van E2S.

48 HOOFDSTUK 4. REALISATIE IN HAT
Figuur 4.2: Gesimpliceerde OCL meta-model
4.2 Run-time OCL naar JAVA
In hoofdstuk 3 hebben we een mogelijke methodologie voorgesteld om run-time OCL expressie
naar JAVA te vertalen. We hebben verschillende sjablonen voor verschillende OCL modelelementen
voorgesteld. Nu gaan we deze methodologie in het HAT tool van E2S toepassen.
Om een run-time OCL expressie te kunnen evalueren moeten we eerst van een run-time OCL
expressie een expressieboom maken. In het HAT tool gebeurt dat door de operatie GenerateCode()
op te roepen. Deze expressie boom bevat OCL modelelementen. Voor elk van
deze modelelementen moeten we een representatie naar een doeltaal voorzien, in ons geval
is dat JAVA. Om deze representatie te kunnen produceren geven we een generator aan de
GeneratorCode() operatie mee. Deze generator moet een aantal schrijvers bevatten waarin
voor elk OCL modelelement een representatie naar JAVA voorzien is. De representatie van
deze schrijvers bevat eigenlijk de sjablonen die we in hoofdstuk 3 voorgesteld hebben.
Met andere woorden om broncode in het HAT tool te produceren moet men voor elk OCL
modelelement in de expressieboom de bijbehorende schrijver met zijn bijbehorende representatie
toepassen. Toch is deze oplossing niet altijd van toepassing. In subsectie 4.2.2 gaan we
uitleggen wat er mis kan gaan en wat een mogelijke oplossing zou kunnen zijn.
Nu gaan we voor een aantal run-time OCL modelelementen bespreken hoe we de sjablonen
(voorgesteld in hoofdstuk 3) zullen toepassen.

4.2. RUN-TIME OCL NAAR JAVA 49
Figuur 4.3: Abstract syntax metamodel voor ModelPropertyCallExpr
4.2.1 OCL attribuut-, associatie- en operatiemodelelementen
De sjablonen die we voor attributen en associaties voorgesteld hebben zijn probleemloos toepasbaar
in het HAT tool. Telkens we een attribuut- of associatiemodelelement in een expressieboom
ontmoeten roepen we de bijbehorende schrijvers voor deze modelelementen (resp.
modelelementen van type AttributeCallExpr en modelelementen van type AssocEndExpr zie
Figuur 4.3). Indien we met een operatiemodelelement te maken hebben roepen we dan de
schrijver die bij dit modelelement hoort, namelijk een schrijver van type OperationCallExpr.
4.2.2 OCL collectieiterator modelelementen
In hoofdstuk 3 over de methodologie hebben we grondig besproken dat we voor collectieiteratoren
wat extra code moeten genereren. De reden is dat deze OCL collectieoperaties geen

50 HOOFDSTUK 4. REALISATIE IN HAT
tegenhangers in JAVA API hebben.
Bij het doorlopen van een expressieboom gaan we voor elk OCL modelelement de bijbehorende
schrijver oproepen. Deze schrijvers zullen een JAVA representatie voor het OCL modelelement
produceren. Voor collectieiteratoren moeten we nieuwe hulpmethoden genereren die geen
tegenhangers in JAVA hebben. Bij het doorlopen van een OCL expressieboom willen we
maar een oproep naar deze extra hulpmethoden produceren. Natuurlijk moeten deze extra
hulpmethoden ergens anders gegenereerd worden.
Nu wordt duidelijk dat indien we met een generator te werk gaan komen we terecht in een probleem.
De oproep naar een gewenste hulpmethode wordt wel geproduceerd maar de methode
zelf is nergens gegenereerd.
We hebben dat opgelost door voor elk OCL modelelement dat extra hulpmethoden vereist,
nieuwe generatoren te creëren. Deze nieuwe generatoren zullen voor elk OCL modelelement een
schrijver hebben. Natuurlijk deze schrijvers zullen een verschillende representatie (sjabloon)
bevatten.
Met andere woorden gaan we voor een run-time OCL expressie de operatie GenerateCode()
telkens met verschillende generatoren oproepen. Bij de eerste oproep van de GenerateCode()
operatie wordt een oproep naar een gewenste hulpmethode gecreëerd. Vervolgens wordt opnieuw
de GenerateCode() operatie met een andere generator opgeroepen. Deze generator zal
maar schrijvers voor OCL elementen van type LoopExpr hebben. Deze schrijver zal de sjablonen
voor de verschillende collectieiteratoren bevatten die eigenlijk de hulpmethoden zullen
produceren.
4.2.3 OCL If-then-else en let modelelementen
De voorgestelde sjabloon in hoofdstuk 3 voor OCL if-then-else expressie kunnen we ook
in HAT implementeren. We doen dat door in de schrijvers voor OCL modelelementen van
type IfExpr de sjabloon voor if-then-else expressie toe te voegen. Indien de if-then-else
expressies een of meerdere collectieiteratoren bevatten dan moeten we de aanpak van subsectie
4.2.2 implementeren. Namelijk roepen we een tweede keer de GenerateCode() operatie op met
de generator voor collectieiteratoren.
Voor OCL let-expressies gaan we de bijbehorende sjabloon in een aparte hulpmethode inkapselen
zoals in hoofdstuk 3 uitgelegd was. Om dat te kunnen implementeren gaan we bij
de eerste oproep van de GenerateCode() operatie een oproep naar een let methode produceren.
Vervolgens gaan we een tweede keer GenerateCode() oproepen met een andere generator
(generator voor OCL let expressie) die de let methode zelf gaat genereren.
4.2.4 Inkapseling van collectieoperaties
In subsectie 3.2.3.3 hebben we verschillende oplossingen voorgesteld voor inkapseling van OCL
collectieoperatiesjablonen in JAVA methoden. Voor de transformatie van run-time OCL expressie
naar JAVA in HAT hebben we de eerste oplossing geimplementeerd. We hebben dat
al in subsectie 4.2.2 op de vorige pagina besproken.
De tweede voorgestelde oplossing waarbij we een keer een standaard bibliotheek met alle collectieoperaties
genereren, is moeilijk in de huidige versie van HAT te implementeren. Het idee

4.3. NAÏEVE AANPAK IN HAT 51
van deze oplossing is dat we voor elke collectieoperatie de source (de collectie waarop we
de collectieoperatie zullen toepassen) en de body ( het lichaam van de collectieoperatie in de
vorm van een expressie) moeten als parameters doorgeven. Voor de source is dat geen probleem
maar vermits de body meestal een uitvoerbare expressie is wordt dan de implementatie
onmogelijk.
De derde voorgestelde oplossing is ook niet mogelijk te implementeren in de huidige versie van
HAT. De datastructuur die bijhoudt welke collectieoperatie met de bijbehorende source en
body al gegenereerd was bevindt zich in het OCL metamodel horend bij een gegeven generator.
We hebben al gezien dat de overgang van het UML metamodel naar het OCL metamodel
gaat met de GenerateCode operatie. Maar de GenerateCode operatie wordt telkens met
verschillende generatoren opgeroepen. Op deze manier is de referentie naar deze datastructuur
verloren
4.3 Naïeve aanpak in HAT
De implementatie van de naïeve aanpak in HAT gebeurt aan de hand van een UML proel.
Dit UML proel bevat eigenlijk de transformaties (vertaling van run-time OCL expressies)
naar JAVA.
De geproduceerde code komt overeen met de methodologie die wie in hoofdstuk 3 voorgesteld
hebben. Klasse-invarianten worden in booleaanse methoden ingepakt en er is een gemeenschappelijke
methode gegenereerd die een conjunctie van alle invarianten bevat.
Bij operaties worden zowel pre- als postcondities gegenereerd. Deze zijn in booleaanse methoden
geencapsuleerd. Vervolgens zijn deze pre- en postconditiemethoden bij de horende
operatie (respectievelijk in het begin en op het einde van de operatie) toegevoegd met de
assert constructie. In het begin en op het einde van het lichaam van een operatie is ook de
gemeenschappelijke methode toegevoegd die alle klasse-invarianten nagaat.
4.4 Intelligente aanpak in HAT
Voor de implementatie van de intelligente aanpak in HAT maken we opnieuw gebruik van een
UML proel dat onze transformaties bevat.
Voor de vertaling van klasse-invarianten, pre- en postcondities hebben we de implementatie van
de naïeve aanpak overgenomen en vervolgens hebben we een aantal aanpassingen toegevoegd
om de intelligente aanpak te kunnen implementeren. Met andere woorden inkapseling van
klasse-invarianten, pre- en postcondities gebeurt op precies dezelfde manier als in de naïeve
aanpak: elke invariant, pre- en postconditie is in een booleaanse methode ingepakt.
De aanpassing die we gemaakt hebben betreft de assertie van relevante klasse-invarianten op
het einde van het uitvoeren van operaties in plaats van een conjunctie van alle aanwezige
invarianten te nemen.
Deze aanpassingen zijn gebaseerd op string matching.
Het idee is als volgt: voor elke postconditie van een operatie zoeken we of er een object of
variabele tijdens de uitvoering van de operatie aangepast is. Dat doen we aan de hand van

52 HOOFDSTUK 4. REALISATIE IN HAT
Algorithm 1 Algoritme intelligente aanpak gebaseerd op string matching
foreach operation
if(set of postconditions not empty)
foreach postcondition
pat := search for pattern
foreach invariant
find pat
if(found)
print invariant using assert construction
else do nothing
else do nothing
reguliere expressies. Vervolgens gaan we zoeken of dit object (variabele) ook in een van de
klasse-invarianten betrokken is. Indien dat het geval is gaan we deze invariant afdrukken door
gebruik van de assert constructie. We tonen het algoritme in Algorithm1.
Dat kan in sommige gevallen goed werken maar de mogelijkheid voor het afdrukken van dezelfde
invariant meerdere keren in een operatie is niet uitgesloten. Bijgevolg is onze intelligente
aanpak niet meer intelligent.
We willen dit probleem oplossen door in plaats van elke keer de gevonden invariant af te
drukken, gaan we deze in een collectie opslaan en dan duplicaten weghalen. Vervolgens door
het afdrukken van ieder element van deze collectie krijgen we het gewenste resultaat.
4.5 Evaluatie
Voor de evaluatie van dit tool gaan we opnieuw de voorgestelde criteria van hoofdstuk 2
gebruiken. We hebben al in hoofdstuk 2 gezien dat de geëvalueerde tools geen mogelijkheden
aanbieden om aanpassingen en verjningen aan de gegenereerde code uit te voeren. Wat wel
mogelijk is is allen een model en de bijbehorende beperkingen te modelleren en vervolgens code
te genereren. In HAT is wel mogelijk dat een gebruiker stereotypen, regels en constraints en
code specicatie zelf kan denieren. Dit gebeurt met behulp van UML proelen. Eens zijn deze
UML proelen op UML modellen toegepast dan verrijken deze UML proelen de modellen
en bovendien controleren ze of het model met de opgestelde constraints samengaat. UML
proelen kunnen ook verschillende projectproducten opleveren: documenten, testsequenties,
metrieken enz.
Hieronder vatten we alles samen.

4.5. EVALUATIE 53
Id Criteria Opmerking Ondersteuning
1 invarianten Ja
2 pre-, postcondities Ja
3 attributen, Ja
associaties
4 collecties Voor ieder collectieiterator Ja
een nieuwe methode
5 @pre Neen
6 result Neen
7 assertion Ja
8 slimme controle Ja
klasse invarianten
Tabel 4.1: Evaluatie van HAT

Hoofdstuk 5
Case study - Royal and Loyal
In dit hoofdstuk willen we nagaan hoe de transformatie van OCL expressies naar JAVA die we
met behulp van het HAT tool geimplementeerd hebben in werkelijkheid kunnen toepassen. Om
dat te realiseren hebben we als gevalstudie het voorbeeld van [1] overgenomen. Dit voorbeeld
gaat over een software systeem van een imaginaire bedrijf die Royal and Loyal (R&L) noemt.
5.1 Beschrijving van de case study
R&L behandelt loyaliteitsprogrammas voor bedrijven die aan hun klanten verschillende soorten
van bonussen bieden. Deze toeslagen hebben meestal de vorm van extra punten of air
miles maar zijn er ook andere soorten van bonussen mogelijk. Met andere woorden eender
welke dienst een bedrijf wenst te bieden dan is deze in een loyaliteitsprogramma overgebracht.
figuur 5.1. toont het UML klassemodel dat R&L voor het meest van zijn klanten gebruikt.
De centrale klasse in het model is LoyalyProgram. Een bedrijf dat aan zijn klanten lidmaatschap
in een loyaliteitsprogramma biedt noemen we ProgramPartner. Meer dan een bedrijf
mag gebruik maken van hetzelfde programma. Bijgevolg kunnen klanten van alle diensten
genieten die door de participerende bedrijven aangeboden zijn indien ze in een loyaliteitsprogramma
participeren.
Elke klant van een ProgramPartner kan in een loyaliteitsprogramma toetreden door het invullen
van een formulier en het verkrijgen van een lidmaatschapskaart. De klasse Customer
representeert de klanten die in het programma participeren. De lidmaatschapskaart is door
de klasse CustomerCard voorgesteld. Een CustomerCard is maximaal aan een persoon geassocieerd,
maar kan gebruikt worden door de ganse familie of zaak. De meeste programmas
laten klanten toe om punten te sparen. Elke individuele programmapartner beslist de toekenning
van punten aan zijn klanten voor een bepaalde aankoop. Elke klant kan met zijn/haar
bespaarde punten specieke diensten van een van de programmapartners aankopen. Beheren
van spaarpunten is in klasse LoyaltyAccount opgenomen.
Op een LoyaltyAccount zijn verschillende transacties mogelijk: transacties waarbij een klant
punten verkrijgt en andere waarbij een klant punten besteedt. De eerste soort is in ons systeem
als de klasse Earning modelleert en de tweede als Burning. Deze twee soorten van transacties
zijn als subklassen van de klasse Transaction gemodelleerd.
54

5.2. VERTALING MET BEHULP VAN HAT 55
Figuur 5.1: Het aangepaste model van Royal and Loyal
De klasse ServiceLevel is geïntroduceerd om verschillende niveaus van diensten te besturen.
Deze is gedenieerd door een loyaliteitsprogramma en is door een lidmaatschap gebruikt.
5.2 Vertaling met behulp van HAT
Het oorspronkelijke klasse-diagram van daarboven hebben we licht aangepast om de constraints
van dit model te kunnen transformeren naar JAVA . Uit de associatieklasse Membership
hebben we een gewone klasse gemaakt. De reden voor deze aanpassing was dat veel van de OCL
expressies (die bij dit model horen) konden niet gevalideerd worden in HAT. In de volgende
paragraaf gaan we meer concreet bespreken welke soort van constraints niet gevalideerd kon.

56 HOOFDSTUK 5. CASE STUDY - ROYAL AND LOYAL
Figuur 5.2: Het model van Royal and Loyal
We hebben alle constraints op het model gegenereerd met behulp van het HAT tool met
paar uitzonderingen. Met sommige constraints hadden we moeilijkheden om deze te kunnen
valideren in het tool zelf. Indien een beperking niet gevalideerd is dan kan deze niet gegenereerd
worden. Bijgevolg moesten we de constraints licht aanpassen om deze te kunnen genereren.
We gaan nu de punten bespreken waarop we aanpassingen moesten uitvoeren of gewoon niets
konden doen.
• Indien we in een OCL expressie een associatie hebben die een collectie van objecten
voorstelt (dus multipliciteit is groter dan een) en indien deze associatie op zijn beurt
een tweede associatie oproept dan worden zulke OCL expressie in HAT niet gevalideerd.

5.2. VERTALING MET BEHULP VAN HAT 57
In zulke gevallen zijn er geen mogelijkheden om aanpassingen uit te voeren. Bijgevolg
hebben we OCL expressies van deze soort genegeerd. We geven een voorbeeld van zo'n
OCL expressie in de context LoayaltyProgram zie figuur 5.1
context LoayaltyProgram
inv:
partners.deliveredServices -> forall(x|x.condition = true)
• Indien we twee klassen hebben die met elkaar verbonden worden met een associatieklasse,
dan kunnen we niet navigeren via deze associatieklasse. In OCL navigeert men in
dergelijke situaties door de naam van de associatieklasse te concateneren aan de naam
van het gewenste associatieeinde en deze met een punt uit elkaar te scheiden. De naam
van de associatieklasse moet met een hoofdletter beginnen. In HAT worden deze OCL
expressies niet gevalideerd. Dat was ook een van de redenen waarom we onze associatieklasse
Membership naar een gewone klasse getransformeerd hebben. Voorbeeld van
zulke expressies is de volgende OCL expressie (zie figuur 5.1)
context Customer
inv:
Membership.account -> select(x|x.points>0)->isEmpty()
• Indien we constraints in de context van een associatieklasse willen denieren dan moeten
we deze in HAT denieren bij een van de betrokkene klassen bij deze associatieklasse.
Met andere woorden wordt de context van deze constraint niet de associatieklasse maar
een van de betrokken klassen. Daarvoor hebben we uit de associatieklasse een gewone
klasse gemaakt.
• Veel van de postcondities bevatten sleutelwoorden zoals @pre en result. Voor OCL expressies
die het sleutelwoord result bevatten kunnen we niets doen. Deze expressies zijn
niet gevalideerd. De sleutelwoorden @pre hebben we gewoon niet toegevoegd. Bijgevolg
is ook de betekenis van een OCL expressie veranderd maar deze expressies zijn wel gevalideerd
in HAT en gegenereerd. Indien we zulke OCL expressie negeren dan kunnen we
onze intelligente aanpak niet testen. Daarom hebben we zulke expressies behouden maar
we hebben deze licht aangepast aangepast . Bijvoorbeeld de volgende OCL expressie:
context LoayaltyProgram::enroll(c:Customer)
post:
wordt
participants = participants@pre->including(c)
context LoayaltyProgram::enroll(c:Customer)
post:
participants = participants->including(c)
De aanpakken die we in hoofdstuk 3 ontwikkeld hebben werkten zoals ze beschreven waren.
We konden een groot deel van de code direct van ons model genereren. Indien we nu onze
gegenereerde code met de handgeschreven code gaan vergelijken dan zou er toch een groot
verschil zijn. Een groot deel was hierboven beschreven.
We hebben een inspanning gedaan om het tool te laten evalueren op een gevalstudie. Indien
we sommige aanpassingen niet gedaan hebben op ons model zouden de resultaten niet bevredigend
worden. Maar de tekorten wat betreft associatieklassen kunnen altijd opgelost worden.

58 HOOFDSTUK 5. CASE STUDY - ROYAL AND LOYAL
Telkens we een UML proel creëren wordt deze uit een default proel afgeleid. Deze default
proel heeft een aantal ingebakken constraints (bijvoorbeeld, ). Dat zijn allemaal beperkingen
die een rem kunnen worden om verschillende gevalstudies te reproduceren. Maar dat zou niet
zeggen dat deze gevalstudies niet op een andere manier gemodelleerd kunnen worden in HAT
om de semantiek ervan te behouden.

Hoofdstuk 6
Besluit
MDD zou moeten een revolutionair softwareontwikkelingstijdperk inluiden waarbij alle aandacht
gevestigd wordt op abstracte modellen van een applicatie op verschillende niveaus van
detail in plaats van op de code. Automatische transformaties tussen deze modellen hebben
een centrale rol in MDD namelijk zorgen deze dat bepaalde aspecten correct ingevuld worden.
Eens zijn deze transformaties gedenieerd kan dan code automatisch gegenereerd worden.
6.1 Doelstellingen en problemen
De doelstellingen waren in het begin van de thesis ruim omschreven. We wouden een bepaald
aspect van de modeltransformaties bestuderen, namelijk transformaties van OCL expressies
naar werkende code. De doeltaal van de transformatie moest JAVA zijn. Daarvoor hebben we
twee aanpakken uitgewerkt voor deze specieke transformaties (codegeneraties). Deze twee
aanpakken zijn onafhankelijk van de transformatie naar een doelprogrammeertaal. De eerste
aanpak die we de naïeve noemen controleert alle constraints op ieder stabiel moment van
een systeem. Deze aanpak is ook de meest intuïtieve aanpak. De tweede aanpak is meer
geavanceerd. Bij deze aanpak hebben we een methode ontwikkeld die laat ons toe om op een
slimme manier constraints na te gaan. Deze aanpakken zijn onafhankelijk van de doeltaal
waarmee we deze transformatie (codegeneratie) zullen produceren.
Oorspronkelijk hebben we intensief naar tools gezocht om deze specieke transformaties te
kunnen implementeren. We wilden gebruik maken van MOFScript [23]. Al snel werd duidelijk
dat we deze transformaties niet zouden kunnen implementeren. De reden was dat MOFScript
niet over een OCL parser beschikte.
Het schrijven van een OCL parser en dan integreren in MOFScript was ver van de doelstellingen
van deze thesis. Daarom hebben we dit idee verlaten.
6.2 Oplossing
We hebben het HAT tool van E2S gebruikt om onze doelstellingen te kunnen implementeren.
De resultaten verkrijgen van dit tool waren bevredigend voor de naïeve aanpak. De
doelstellingen wat betreft deze aanpak waren bereikt.
59

60 HOOFDSTUK 6. BESLUIT
De oorspronkelijke mogelijkheden van HAT lieten ons niet toe om de intelligente aanpak te
implementeren. Dat was eigenlijk het moment van de geboorte van de intelligente aanpak
gebaseerd op string matching. Deze methode zoekt voor elke postconditie horend bij een
publieke operatie welke object of variabele tijdens de uitvoering van deze operatie zou moeten
aangepast worden. Vervolgens gaan we de gevonden object of variabele met een of meerdere
klasse-invarianten proberen te matchen. Met deze oplossing hebben we het probleem van de
intelligente aanpak niet kunnen implementeren omgezeild.
Tijdens de implementatie in HAT hebben we samen met E2S naar verschillende oplossingen
gezocht om wat verjningen aan het tool aan te brengen.
6.3 Kritische noot
Een nadeel van het HAT tool is dat er geen ondersteuning is voor sleutelwoorden zoals @pre
en result. Blijkbaar is de complexiteit verhoogd om deze sleutelwoorden te implementeren
dan de voordelen die dat zou opbrengen.
Naast de methodologie die we voor het bereiken van de doelstellingen ontwikkeld hebben,
hebben we ook een evaluatie van bestaande tools gemaakt die run-time OCL ondersteunen.
Voor onze grote verassing wat wij uit de gegenereerde code gemerkt hebben is dat er geen enkel
van de geëvalueerde tools een meer intelligente, slimme implementatie had voor het nagaan
van voldoening van constraints. Alle tools volgen min of meer een aanpak die op onze naïeve
aanpak lijkt. Dat plaats HAT tool een stap voor zijn concurrenten alhoewel nog wat werk
moet gedaan worden om een een deftige implementatie van de intelligente aanpak in HAT te
hebben.
6.4 Toekomstig werk: uitbreidingen en aanpassingen
We hebben aangegeven hoe run-time OCL expressies naar werkende code in HAT getransformeerd
kunnen zijn. We sommen enkele uitbreidingen op die nuttig zijn om het systeem
bruikbaarder te maken.
Het zou interessant zijn om een ondersteuning voor sleutelwoorden zoals @pre en result te
voorzien. Dat zou het tool bruikbaarder maken wat betreft transformaties van run-time OCL
expressies.
Op basis van de methodologie die we in deze thesis ontwikkeld hebben, zouden we generatoren
ook in andere talen moeiteloos kunnen implementeren.
Een volledige beschrijving van OCL taal kan ook beschouwd worden. De methodologie die we
voorgesteld hebben, is niet volledig in de zin dat we maar een deelverzameling van de OCL
taal genomen hebben. We hebben vooral op een aantal aspecten gefocust: klasse-invarianten,
pre- en postcondities. Aeiding regels, initiële waarden, body-of-query operaties hebben we
niet bestudeerd.
Alhoewel onze aandacht in deze thesis op de JAVA programmeertaal gericht was, zou er interessant
zijn om een alternatieve implementatie wat betreft aspect-georiënteerde uitbreidingen

6.4. TOEKOMSTIG WERK: UITBREIDINGEN EN AANPASSINGEN 61
te beschouwen. Aspecten kunnen modularizatie van klasse-invarianten en pre- en postcondities
aanbieden. Op deze manier kunnen deze klasse-invarianten en pre- en postcondities uit de
code afgezonderd worden. Andere voordelen van aspect-georiënteerde programmeertechnieken
moeten nog uitgebreider en dieper bestudeerd worden.

B¼lage A
Lijst Van Afkortingen
API Application Programming Interface
DBC Design By Contract
GME Generic Modeling Enviroment
MDA Model Driven Architecture
MDD Model Driven Development
OCL Object Constraint Language
OMG Object Management Group
PIM Platform Independent Model
PSM Platform Specic Model
UML Unied Modeling Language
62

Bibliograe
[1] A.Kleppe, J.Warmer, The Object Constrait Language, Second Edition, Getting your models ready for
MDA,Addison-Wesley, 2003
[2] David S. Frankel, Model Driven Architecture: Applyoing MDA to Enterprise Computing,Joe Wikert,
2003
[3] A.Kleppe, J.Warmer, W.Bast,MDA explained - The model driven Architecture: practice and
promices,Addison-Wesley, 2003
[4] M.Fowler, Language WorkBenches and Model Driven Architecture,
http://www.martinfowler.com/articles/mdaLanguageWorkbench.html
[5] S.H.Czarnecki, S.Helsen, Feature-based survey of model transformation approaches,IBM SYSTEMS
JOURNAL, 2006, http://www.research.ibm.com/journal/sj/453/czarnecki.pdf
[6] Object Constraint Language OMG Available Specication Version 2.0, 2006,
http://www.omg.org/docs/formal/06-05-01.pdf
[7] J.Oldevik,MOFScript User guide (v0.6),2006, http://www.eclipse.org/gmt/mofscript/doc/MOFScript-
User-Guide.pdf
[8] A.Hovsepyan,S.Van Balen, B.Vanho, W.Jossen, Y.Berbers, Key Research Challenges for Successfully
Applying MDD within Real -Time Embeded Software Development, 2006
[9] A.Kleppe, J.Warmer, W.Bast,MDA explained - The model driven Architecture: practice and
promices,Addison-Wesley, 2003
[10] E2S nv, http://www.e2s.be
[11] Borland Together tool, http://www.borland.com/together
[12] OCL tool, http://lci.cs.ubbcluj.ro/ocle
[13] Octopus tool, http://www.klasse.nl
[14] Programming with assertions, http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
[15] OMG, Unied Modeling Language, http://www.uml.org
[16] OMG, The Object Management Group, http://www.omg.org
[17] GME, The Generic Modeling Enviroment, http://www.isis.vanderbilt.edu/projects/gme/
[18] MetaEdit, Domain-Specic Modeling with MeataEdit+, http://www.metacase.com/index.html
[19] Eiel, http://www.eiel.com/
[20] OMG, OMG Model Driven Architecture, http://www.omg.org/mda
63

64 BIBLIOGRAFIE
[21] OMG, The Object Constrait Language, http://www.omg.org/docs/formal/06-05-01.pdf
[22] No Magic Inc, MagicDraw - visual UML modeling and CASE tool, http://www.magicdraw.com/
[23] Modelbased, MOFScript , http://www.eclipse.org/gmt/mofscript
[24] E2S nv, HAT Manual, https://www.e2s.be/Content/Software_Products/Hat/Download_Data/HatManual.pdf
[25] B.Meyer,Design by Contract, http://se.ethz.ch/~meyer/publications/computer/contract.pdf