Dankwoord - martes

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