Inhoudsopgave. 1 Inleiding Situering Probleem beschrijving Wat is OCL Motivatie Doelstellingen...

Transcriptie

1 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

2 Inhoudsopgave 1 Inleiding Situering Probleem beschrijving Wat is OCL Motivatie Doelstellingen Overzicht State-of-the-art Evaluatiecriteria Invarianten Pre- en Postcondities Attributen en Associaties Operaties op collecties en result Assertion Slimme controle van klasse-invarianten Tools Octopus OCLE Together 2006 for Eclipse Conclusie ii

3 INHOUDSOPGAVE iii 3 Methodologie Design By Contract Klasse-invarianten Precondities en postcondities Assertions in Java Waarom assertie gebruiken? Beschrijving van de methodologie Vertaling van attributen en associaties Vertaling van OCL operaties over basistypen Boolean type Real en Integer types String type Vertaling van OCL collectieoperaties Eenvoudige collectieoperaties Collectieiteratoren Inkapseling van sjablonen voor collectieoperaties in JAVA methoden Vertaling van OCL if-then-else expressies Vertaling van OCL let expressies Vertaling van klasse-invarianten Vertaling van pre- en postcondities Vertaling van meer geavanceerde constructies Vertaling van het Het sleutelwoord result Naïeve aanpak Vertaling van invarianten Inkapseling van een invariant in een booleaanse methode Inkapseling van alle klasse-invarianten in een gemeenschappelijke methode Vertaling van pre- en postcondities Intelligente aanpak Het Idee Graafconstructie String matching

4 iv INHOUDSOPGAVE Vertaling van klasse-invarianten Inkapseling van een invariant in een booleaanse methode Inkapseling van alle relevante klasse-invarianten in een gemeenschappelijke booleaanse methode Vertaling van pre- en postcondities Evaluatie Realisatie in HAT HAT Run-time OCL naar JAVA OCL attribuut-, associatie- en operatiemodelelementen OCL collectieiterator modelelementen OCL If-then-else en let modelelementen Inkapseling van collectieoperaties Naïeve aanpak in HAT Intelligente aanpak in HAT Evaluatie Case study - Royal and Loyal Beschrijving van de case study Vertaling met behulp van HAT Besluit Doelstellingen en problemen Oplossing Kritische noot Toekomstig werk: uitbreidingen en aanpassingen A Lijst Van Afkortingen 62

5 L¼st van guren 1.1 Relatie tussen PIM, PSM en code Gesimpliceerd UML model van een Luchthaven systeem Afhankelijkheid tussen klasse invarianten en postcondities horend bij operaties Klassediagram van het lopende voorbeeld Architectuur van de Agile MDA Tool Gesimpliceerde OCL meta-model Abstract syntax metamodel voor ModelPropertyCallExpr Het aangepaste model van Royal and Loyal Het model van Royal and Loyal v

6 L¼st van tabellen 2.1 Evaluatiecriteria voor transformatie van OCL expressies door een tool Evaluatie van Octopus Evaluatie van OCLE Evaluatie van Together 2006 for Eclipse Standaard operaties voor de Boolean type Standaard operaties voor Integer en Real types Standaardoperaties voor String type Afbeelding van OCL collectie typen naar JAVA collectie typen Standaardoperaties over alle soorten van collectie typen Collectieiteratoren operaties over alle collectietypen De resultaten van de evaluatie van naïeve en de intelligente aanpak Evaluatie van HAT vi

7 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

8 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.

9 1.2. PROBLEEM BESCHRIJVING 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 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

10 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()<= plane.numberofseats In dit voorbeeld is duidelijk te zien dat OCL ons bij het speciceren van modellen kan helpen. In werkelijkheid bestaan er twee soorten van OCL expressies - statische OCL en run-time OCL expressies. De eerste soort houdt zich bezig met de validatie van modellen en documenten. De tweede soort legt beperkingen op instantiaties van modellen op. In deze thesis zullen we enkel op de tweede soort van OCL expressies focussen. 1.3 Motivatie Een UML model zonder OCL is niet voldoende gespeciceerd. Anderzijds hebben OCL expressies geen betekenis indien ze niet aan een UML model geassocieerd zijn want in dat geval verwijzen ze naar niet bestaande modelelementen. Daarom komt de echte kracht van deze expressie wanneer we een combinatie van OCL en UML nemen. Het nut van OCL ligt in het modelleren van applicaties. OCL is formeel genoeg om als invoer door tools te kunnen gebruikt worden. Indien we in onze modellen run-time OCL gebruiken kunnen we van een aantal voordelen genieten. Ten eerste besparen we heel wat tijd. Anders moeten alle beperkingen op onze modellen handmatig door programmeurs geschreven worden. Ten tweede is de kwaliteit van onze modellen verhoogd. De getransformeerde beperkingen zijn correct en bijgevolg zijn onze modellen ook juist en precies. Ten derde is het gebruik van run-time OCL aangemoedigd. Indien run-time OCL niet naar broncode getransformeerd wordt, verliezen modelleurs de motivatie om OCL op modelniveau te gebruiken.

11 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.

12 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.

13 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 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 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 bespreken. Daarom is de ondersteuning van invarianten door tools een basisvereiste. 7

14 8 HOOFDSTUK 2. STATE-OF-THE-ART 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 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 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 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. 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 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

15 2.1. EVALUATIECRITERIA 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 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 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

16 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 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 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

17 2.2. TOOLS 11 alleen maar invarianten en precondities. In de laatste versie die we getest hebben, zijn postcondities nog niet ondersteund. Bijgevolg zijn sleutelwoorden 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); //... <body of operation> 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; 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-

18 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 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(){ //... <body of operation> 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

19 2.2. TOOLS 13 compleet systeem als resultaat hebben. Natuurlijk zijn meer geavanceerde constructie 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 dit sleutelwoord is Neen genegeerd 6 result Neen 7 assertion Neen 8 slimme controle Neen klasse-invarianten Tabel 2.3: Evaluatie van OCLE Together 2006 for Eclipse De Together 2006 Release 2 for Eclipse [11] versie 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 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

20 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()); //... <body of operation> 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 en result zijn geimplementeerd.

21 2.2. TOOLS 15 Indien het 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(); //... <body of operation> 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){ //... <body of postcondition> ; return prestate; static boolean inv0(){ static boolean inv1(){ static boolean allinvariants(){ return inv0()&& inv1(); static boolean preoperation(){

22 16 HOOFDSTUK 2. STATE-OF-THE-ART 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.

23 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

24 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 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 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.

25 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 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 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.

26 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 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

27 3.2. BESCHRIJVING VAN DE METHODOLOGIE 21 self.associationend wordt getransformeerd naar de volgende JAVA code: this.getassociationend(); 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 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:

28 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 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 <= b a <= b Boolean more or equal a >= b a <= b Boolean plus a + b a + b Integer or Real minus a - b a - b Integer or Real multiplication a * b a * b Integer or Real division a / b a / b Real modulus a.mod(b) a % b Integer integer division a.div(b) (int)(a / b) Integer absolute value a.abs() java.lang.math.abs(a) Integer or Real maximum of a and b a.max(b) java.lang.math.max(a,b) Integer or Real minimum of a and b a.min(b) java.lang.math.min(a,b) Integer or Real round a.round() java.lang.math.round(a) Integer oor a.floor() java.lang.math.floor(a) Integer Tabel 3.2: Standaard operaties voor Integer en Real types We kunnen eventueel voor een eigen implementatie van alle operaties op de Integer en Real types kiezen. Vermits er voor alle basis operaties op deze types tegenhangers in de java.lang.math API te vinden zijn doen we dat hier niet.

29 3.2. BESCHRIJVING VAN DE METHODOLOGIE 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 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.

30 24 HOOFDSTUK 3. METHODOLOGIE 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 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.

31 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:

32 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.

33 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

34 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

35 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;

36 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.

37 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 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.

38 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 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 <boolean OCL expression> then <OCL expression 1> else <OCL expression 2> 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.

39 3.2. BESCHRIJVING VAN DE METHODOLOGIE 33 Listing 17 Sjabloon OCL if-then-else expressie return (< translation of boolean OCL expression >)? <OCL expression 1 > : <OCL exprssion 2 >; 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; 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.

40 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 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:

41 3.2. BESCHRIJVING VAN DE METHODOLOGIE 35 Listing 22 Sjabloon voor pre- en postcondities public boolean checkprenameofpreconditionnameofoperation(){ return <translation of OCL pre expression >; public boolean checkpostnameofpostconditionnameofoperation(){ return <translation of OCL post expression >; <type> 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 Vertaling van meer geavanceerde constructies Vertaling van het Het 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.

42 36 HOOFDSTUK 3. METHODOLOGIE Listing 23 Sjabloon voor expressie void operation(int attribute2){ int old_attr = this.getattribute(); //... // <body of operation> //... 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 object void operation(object object2){ Object old_obj = new Object(obj); //... // <body of operation> //... assert checkpostp1operation(old_obj,object2); public boolean checkpostp1operation(object old_obj, Object object2){ return this.getobject().getproperty() == old_obj.getproperty() + object2.getproperty(); 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:

43 3.3. NAÏEVE AANPAK 37 Listing 26 Sjabloon voor OCL result sleutelwoord int operation(int attribute2){ int result = 0; //... // <body of operation> //... 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 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 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: <OCL expressie> inv invariant_2: <OCL expressie> inv invariant_3: <OCL expressie> -> forall(<ocl expressie>) 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

44 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 <translation of OCL expression>; public boolean checkinvinvariant2 (){ return <translation of OCL expression>; public boolean checkinvinvariant3 (){ return forallinvariant3 (); private boolean forallinvariant3 (){ <template for the forall operation> 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 (); 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:

45 3.3. NAÏEVE AANPAK 39 Listing 30 voorbeeld operatie met pre- en postcondities context ClassA :: operation1() : <type> pre pre1: <OCL expressie> pre pre2: <OCL expressie> post post1: <OCL expressie> 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 <type> operation1(){ assert(checkallinvariants()); assert(checkprepre1operation1 ()); assert(checkprepre2operation1 ()) ; // // body of operation // assert(checkpostpost1operation1 ()); assert(checkallinvariants()); private boolean checkprepre1operation1 (){ return <translation of OCL expression>; private boolean checkprepre2operation1 (){ return <translation of OCL expression>; private boolean checkpostpost1operation1 (){ return <translation of OCL expression>; 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.

46 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 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 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

47 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:

48 42 HOOFDSTUK 3. METHODOLOGIE Listing 33 sjabloon post-code <type> 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 <type> method2(){ // // body of operation // assert(checkpostpost1method2 ()); assert(checkinvinv2 ()); assert(checkinvinv3 ()); 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) 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 gaan we dat bespreken.

49 3.5. EVALUATIE 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 Wat hier meer aandacht vereist is de inkapseling van de relevante klasse-invarianten in een gemeenschappelijke booleaanse methode. Dat gaan we hieronder bespreken 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 Vertaling van pre- en postcondities Voor de vertaling van pre- en postcondities van een methode verwijzen we naar Het enige verschil dat hier zou kunnen zijn is dat de gemeenschappelijke methode omtrent het nagaan van klasse-invarianten op basis van subsectie 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.

50 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 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.

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

52 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

53 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.