Suggesting Fixes For Non-Conformances in JML Programs

Suggesting Fixes for Nonconformances in Java/JML
Programs
Alysson Filgueira Milanez
Technical Report SPLAB-2016-001
April 2016
Software Practices Laboratory
Federal University of Campina Grande
Suggesting Fixes for Nonconformances in Java/JML

Programs
Alysson Filgueira Milanez
Software Practices Laboratory

Federal University of Campina Grande
Rua Aprgio Veloso, 882
Campus Universitario
58429-900 Campina Grande - PB
Brazil
Email alyssonfilgueira@copin.ufcg.edu.br
Technical Report SPLAB-2016-001
April 2016
Abstract
When correcting a nonconformance in a contract-based program, a developer may need to change the code, the
contract, or both. In this work, we present suggestions for 119 nonconformances detected by J ML O K 2 in 12
Java/JML programs. As a result of this suggestions, we found the contract as the artifact in which the most fixes
need to be applied (77%). Furthermore, the most recurrent kind of fix was add preconditions to methods and
constructors (almost 40%). This work is a step towards to understand the process of correcting nonconformances
in Java/JML programs.
List of Tables
1 Experimental units summary. Column KLOC shows the code size of each experimental unit.
Column # CC presents the total of contract clauses of each experimental unit. Column # NC
displays the number of nonconformances detected in each unit. . . . . . . . . . . . . . . . . . . . 2
2 Fixes summary. Column Artifact groups the fixes by the part (code or contract) in which the fix is
implemented. Column Kind of fix shows the kinds of fixing recommended. Column # instances
display the number of occurrences of each kind of fix. . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Fixes summary for each experimental unit. Column Experimental Unit presents the name of
each unit. Column Artifact groups the fixes by the part (code or contract) in which the fix is
implemented. Column Kind of fix shows the kinds of recommended. Column # instances display
the number of occurrences of each kind of fix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1 Introduction
According to Pei and colleagues [Pei et al. 2014a], a software bug is the manifestation of a discrepancy between
contracts and implementation: program behavior (implementation) deviates from expectations (contracts). There-
fore, the correction of a bug may involve changing code, contracts, or both.
In the present work, we investigate the problem of fixing nonconformances in the context of Java/JML pro-
grams. For this purpose, we manually suggest fixes for 119 nonconformances detected by J ML O K 2 in 12 open-
source JML projects summing up 26.2 Java KLOC and 2.7 K contract clauses (that we will refer as KCC, in this
work). Furthermore, we analyze the most common fix for solving those nonconformances and in which artifact
(code or contract) the fix is applied.
In summary, the main contribution of this work is the following:
A list of suggestions for fixing all nonconformances detected by J ML O K 2 into 12 experimental units (Sec-
tion 2.2).
2 Suggestion of Corrections for Nonconformances in JML Programs

In this section we discuss repairs (changes in code, contract, or both) for each nonconformance detected by
J ML O K 2 [Milanez 2015]. First, we present the experimental units in which the tool detected nonconformances
(Section 2.1). Next, we explain each suggestion of fix for the nonconformances detected (Section 2.2). Finally, in
Sections 2.3 and 2.4 we summarize and discuss the most common fixes applied to the nonconformances.
2.1 Programs Characterization

The experimental units consist of sample programs available in the JML web site1 and programs collected from
several open-source JML projects; the experimental units totalize more than 26 KLOC and more than 2.7 K
contract clauses (KCC).
The experimental unit named Samples is composed by eight example programs for training purposes2 . The
Samples programs were written by specialists in the JML language. Furthermore, we gathered more 11 open-
source JML programs. While Bank, PayCard and TheSchorrWaiteAlgorithm are presented in the KeY
approach book [Beckert et al. 2007]; Bomber [Rebelo et al. 2009] is a mobile game; Dnivra-Jive is the set
of programs used by the Jive JML Dynamic Program Verifier3 ; HealthCard [Rodrigues 2009] is an application
that manages medical appointments into smart cards. JAccounting is a case study from the ajml compiler
project [Rebelo et al. 2009], implementing an accounting system. On the other hand, Javacard is a technology
used to program smart cards and it comprises a subset of the desktop Java; a subset of the programming language
itself, and a cut down version of the API. The present API implementation has been developed for the KeY
interactive verification system4 . Mondex [Schmitt and Tonin 2007] is a system whose translation from original
Z specification was developed in the Verified Software Repository5 context. In its turn, PokerTop is a poker
system6 . Finally, TransactedMemory [Poll et al. 2002] is a specific feature of the Javacard API.
J ML O K 2 was able to detect 119 nonconformance in 11 out of these experimental units [Milanez 2015]. Ta-
ble 1 summarizes all experimental units in terms of K lines of code (KLOC), contract clauses, and number of
nonconformances detected.
2.2 Fixes for Nonconformances

In this section, we present a list of suggestions for fixing all nonconformances detected by J ML O K 2 in the ex-
perimental units presented in Section 2.1. We first explain how we think this suggestion is able to solve the
nonconformance and then we present an excerpt of code (by code we means source code and also contract clause)
representing the solution.
1 http://www.eecs.ucf.edu/
leavens/JML/examples.shtml
2 dbc,list, misc, reader, sets, stacks, table, and an adaptation of the subpackage stacks stacks2.
3 https://bitbucket.org/dnivra/jive-jml-dynamic-program-verifier
4 http://www.key-project.org/case_studies/
5 http://vsr.sourceforge.net/mondex.htm
6 https://github.com/topless/PokerTop
1
Table 1: Experimental units summary. Column KLOC shows the code size of each experimental unit. Column
# CC presents the total of contract clauses of each experimental unit. Column # NC displays the number of
nonconformances detected in each unit.
Experimental Unit KLOC # CC # NC
Bank 0.79 126 3
Bomber 6.25 120 5
Dnivra-Jive 0.23 94 6
HealthCard 2.15 576 41
JAccounting 6.64 194 26
Javacard API 3.30 46 7
Mondex 0.65 62 2
PayCard 0.11 49 0
PokerTop 0.31 187 1
Samples 3.85 1,084 18
TheSchorrWaiteAlgorithm 0.11 16 2
TransactedMemory 1.78 150 8
Total 26.17 2,704 119
2.2.1 Bank
Invariant problem at ATM constructor
To avoid having to constantly specify that declarations (other than local variables) are non-null, JML makes
them implicitly non null by default [Leavens et al. 2013]. Since the field insertedCard is initialized with a
null value, the developer should add /*@ nullable @*/ in the field declaration, in order to avoid this invariant
error. The code with this suggestion is presented bellow:
public class ATM {
private /*@ spec_public nullable @*/ BankCard insertedCard = null;
}
Postcondition problem at getAccount method (CentralHost class)

In this case, as getAccount returns a null value when called with a value such as 10 as parameter, the
checking whether all reference parameters, fields and method return types are non null breaks in the postcon-
dition [Leavens et al. 2013]. So, adding /*@ nullable @*/ in the signature of getAccount method, the
postcondition problem is solved. The code with this suggestion is presented bellow:
public class CentralHost {
public /*@ pure nullable @*/ PermanentAccount getAccount(int accountNumber){
return accounts[accountNumber];
}
}
Evaluation problem at withDraw method (OfflineAccountProxy class)

The nonconformance should not occur because accountBalance - into the postcondition clause - has
balanceIsAccessible as precondition and this method returns false - this fact should prevent the exe-
cution of accountBalance and the launch of the RuntimeException. However, a pure method is sup-
posed to always either terminate normally or throw an exception, even for calls that do not satisfy its precondi-
tion [Leavens et al. 2013]. So, in order to avoid the nonconformance, the developer should change the body of
accountBalance, removing the throw statement and adding a return clause: return offlineBalance.
The code with this suggestion is presented bellow:
public class OfflineAccountProxy extends Account {
public /*@ pure @*/ int accountBalance(){
return offlineBalance;
}
}
2.2.2 Bomber
Invariant problem at Building constructor
2
In this case, there are two options for fixing this nonconformance: one related to the code: an initialization
of m projection x field with a new object from Point class; and one related to the contract: since the
field m projection x is not initialized into the default constructor, the developer could add a clause /*@
nullable @*/ in the field declaration. The code with this suggestion is presented bellow:
public class Building {
//Code fixing
protected Point m_projection_x = new Point();
//Contract fixing
protected /*@ nullable @*/ Point m_projection_x;
}
Postcondition problem at div method (Common class)

To avoid this problem, the developer should add a precondition to distancePointToLine method, be-
cause the Javadoc present in the head of distancePointToLine has the following statement returns distance
from given point to (given) infinite line, however, nothing is required from the values received as parameter. The
code with this suggestion is presented bellow:
public class Common {
//@requires (vx << 20) > 0 && (vy << 20) > 0;
public static int distancePointToLine(int x, int y, int vx, int vy){
// ...
}
}
Postcondition problem at mod method (Common class) The developer should add a precondition checking
whether the value of y is different of zero: //@ requires y != 0. The code with this suggestion is presented
bellow:
public class Common {
//@ requires y != 0;
public static int mod(int x, int y){
// ...
}
}
Invariant problem at Explosion constructor

This problem occurs because the developer did not initialize all fields into the constructor, the initialization of
some fields is performed by init method, so the default invariant is violated because when init is called into
the constructor the invariant is broken when entering in init method. To solve the problem, the developer should
initializes all fields directly into the body of the constructor without using auxiliary methods. The code with this
suggestion is presented bellow:
public class Explosion implements Visual {
public Explosion(int [] color_table, int x, int y, byte particles, int explosion_initial_size, int
decay, int direction, int direction_dispersion, byte speed, byte speed_dispersion){
m_direction_dispersion = direction_dispersion;
m_direction = direction;
m_speed = speed;
m_speed_dispersion = speed_dispersion;
//Code extracted from init method below
m_explosion = new Point[particles];
m_explosion_size = new int[particles];
m_explosion_color = new int[particles];
m_explosion_direction = new short[particles];
m_explosion_speed = new byte[particles];
m_size = particles;
m_explosion_initial_size = explosion_initial_size;
m_decay = decay;
m_x = x;
m_y = y;
m_color_table = color_table;
for (int i = 0; i < m_explosion.length; i++){
m_explosion[i] = new Point();
newParticle(i);
}
}
}
Postcondition problem at getBoundingBox method (FlakSmoke class)

To solve this problem - as the developer wrote return null in the body of getBoundingBox - the developer
should add /*@ nullable @*/ in the signature of the method. The code with this suggestion is presented
bellow:
3
public class FlakSmoke implements Visual {
public /*@ nullable @*/ Object getBoundingBox(){
return null;
}
}
2.2.3 Dnivra-Jive
Postcondition problem at divideComplexNumber method (package complex, class ComplexNumber)
Since the developer uses the value of 0.005 (the ghost field tolerance) to compare two double values
using the method approximatelyEqualTo from JMLDouble class, a possible way of solve this problem is
increase the value, for instance increasing to 0.01. The code with this suggestion is presented bellow:
public class ComplexNumber {
//@ public ghost static final double tolerance = 0.01;
}
Postcondition problem at getAngle method (package complex, class ComplexNumber)

To avoid this nonconformance, the developer should add a precondition to getAngle method, avoiding calls
when the fields realPart and imgPart are a NaN. The code with this suggestion is presented bellow:
//@ requires !Double.isNaN(this.imgPart) && !Double.isNaN(this.realPart);
public double getAngle(){
// ...
}
}
Postcondition problem at getRealPart method (package complex, class ComplexNumber)

To avoid this nonconformance, the developer should add a precondition to getRealPart method, avoiding
calls when the field realPart is a NaN. The code with this suggestion is presented bellow:
//@ requires !Double.isNaN(this.realPart);
public double getRealPart(){
// ...
}
}
Evaluation problem at divideComplexNumber method (int complex package - ComplexNumber class)

In order to solve this problem, the precondition should check if the value being received as parameter has
components (real and imaginaryPart) different from zero in order to avoid the division by zero: //@ requires
num.realPart != 0 && num.imgPart != 0;. The code with this suggestion is presented bellow:
//@ requires num.realPart != 0 && num.imgPart != 0;
public ComplexNumber divideComplexNumber(ComplexNumber num){
// ...
}
}
Postcondition problem at divideComplexNumber method (int complex package - ComplexNumber class)

To solve this problem, the developer should weaken the postcondition: instead of ensures an exactly equals
value, the expression could consider less than or equal or greater than or equal in the comparison. The code with
this suggestion is presented bellow:
/*@ ensures \result.realPart <= (this.realPart * num.realPart + this.imgPart * num.realPart)
@ /(num.realPart * num.realPart - num.imgPart * num.imgPart)
@ || \result.realPart >= (this.realPart * num.realPart + this.imgPart * num.realPart)
@ /(num.realPart * num.realPart - num.imgPart * num.imgPart);
@ ensures \result.imgPart <= (this.imgPart * num.realPart - this.realPart * num.imgPart)
@ /(num.realPart * num.realPart - num.imgPart * num.imgPart)
@ || \result.imgPart >= (this.imgPart * num.realPart - this.realPart * num.imgPart)
@ /(num.realPart * num.realPart - num.imgPart * num.imgPart);
@*/
public ComplexNumber divideComplexNumber(ComplexNumber num){
//...
}
}
Evaluation problem at quickSort method (package quicksort - QuickSort class)

This nonconformance may be solved by fixing the forall clause, because the values are iterating until the
length of the array, launching an ArrayIndexOutOfBoundException when evaluating the clause in the
postcondition. The code with this suggestion is presented bellow:
4
public class QuickSort {
//@ ensures(\forall int i; 0 <= i && i < numbers.length-1; numbers[i] <= numbers[i +1]);
public void quickSort(){
//...
}
}
2.2.4 HealthCard
Precondition problem at setDesignation method (package allergies - Allergy Impl class)
The developer should remove the exceptional behavior definition from the setAllergyDesignation
(Allergies interface) method in order to avoid the precondition problem at setDesignation method. The
code removing the exceptional behavior definition is presented below:
public interface Allergies extends Common {
/*@ public normal_behavior
@ requires position >= 0 && position < AllergiesSetup.MAX_ALLERGY_ITEMS;
@ requires allergies_model.itemAt(position) != null;
@ requires designation != null && designation.length == AllergiesSetup.ALLERGY_CODE_LENGTH;
@ requires (\forall int i; 0 <= i && i < AllergiesSetup.ALLERGY_CODE_LENGTH;
@ ((byte)0x41 <= designation[i] && designation[i] <= (byte)0x5A )
@ || ((byte)0x61 <= designation[i] && designation[i] <= (byte)0x7A )
@ || ((byte)0x30 <= designation[i] && designation[i] <= (byte)0x39 ));
@ assignable allergies_model;
@ ensures (((Allergy) allergies_model.itemAt(position)).designation_model)
@ .equals(toJMLValueSequence(designation));
@*/
public void setAllergyDesignation(short position, byte[] designation)
throws RemoteException, UserException;
}
Postcondition problem at getAllergyDate method (package allergies - Allergies Impl class)

The developer should remove the exceptional behavior definition from the getAllergyDate (Aller-
gies interface) method in order to avoid the postcondition problem, since the exceptional behavior declares
UserException as the only kind of exception to be thrown by this method. The code removing the exceptional
behavior definition is presented below:
@ assignable commons.CardUtil;
@ ensures (((Allergy) allergies_model.itemAt(position)).date_model).equals(toJMLValueSequence(\result));
@*/
public byte[] getAllergyDate(short position) throws RemoteException, UserException;
}
Postcondition problem at getAllergyDesignation method (package allergies - Allergies Impl class)

The developer should remove the exceptional behavior definition from the getAllergyDesignation
(Allergies interface) method in order to avoid the postcondition problem, since the exceptional behavior de-
clares UserException as the only kind of exception to be thrown in this method, and the method throws a
NullPointerException when called with values greater than two the constructor only assigns values for
the three first items of allergies array. The code without the exceptional behavior declaration is presented below:
@ ensures (((Allergy) allergies_model.itemAt(position)).designation_model
@ .equals(toJMLValueSequence(\result));
@*/
public byte[] getAllergyDesignation(short position) throws RemoteException, UserException;
}
Postcondition problem at removeAllergy method (package allergies - Allergies Impl class)

The developer should remove the exceptional behavior definition from the removeAllergy (Allergies
interface) method; otherwise, each call to this method satisfying some of the exceptional preconditions will result
in a postcondition violation. The code without the exceptional behavior declaration is presented below:
5
@ ensures allergies_model.count(null) == \old(allergies_model).count(null)+1;
@ ensures ((allergies_model.subsequence(position, AllergiesSetup.MAX_ALLERGY_ITEMS - 1)).
@ equals(\old(allergies_model).subsequence(position+1, AllergiesSetup.MAX_ALLERGY_ITEMS))
@ && allergies_model.itemAt(AllergiesSetup.MAX_ALLERGY_ITEMS - 1) == null)
@ || allergies_model.itemAt(AllergiesSetup.MAX_ALLERGY_ITEMS - 1) == null;
@*/
public void removeAllergy(short position) throws RemoteException, UserException;
}
Postcondition problem at setAllergyDate method (package allergies - Allergies Impl class)

The developer should remove the exceptional behavior definition from the setAllergyDate (Aller-
gies interface) method in order to avoid the postcondition problem, since the exceptional behavior declares
UserException as the only kind of exception to be thrown in this method, and the method throws a NullPo-
interException when called with values greater than two the constructor only assigns values for the three
first items of allergies array. The code without the exceptional behavior declaration is presented below:
@ requires date != null && date.length == DATE_LENGTH;
@ ensures (((Allergy)allergies_model.itemAt(position)).date_model).equals(toJMLValueSequence(date));
@*/
public void setAllergyDate (short position, byte[] date) throws RemoteException, UserException;
}
Postcondition problem at setAllergyDesignation method - (package allergies - Allergies Impl class)

The developer should remove the exceptional behavior definition from the setAllergyDesignation
(Allergies interface) method in order to avoid the postcondition problem, since the exceptional behavior de-
clares UserException as the only kind of exception to be thrown in this method, and the method throws an
ArrayIndexOutOfBoundsException when called with values greater than 50 (the value of MAX ALLER-
GY ITEMS setup field). The code without the exceptional behavior declaration is presented below:
@ requires designation != null && designation.length == AllergiesSetup.ALLERGY_CODE_LENGTH;
@ requires (\forall int i; 0 <= i && i < AllergiesSetup.ALLERGY_CODE_LENGTH;
@ ensures (((Allergy) allergies_model.itemAt(position)).designation_model)
@*/
public void setAllergyDesignation(short position, byte[] designation)
}
Postcondition problem at validateAllergyPosition method (package allergies - Allergies Impl class)

The developer should remove the exceptional behavior definition from the validateAllergyPosition
(Allergies interface) method; otherwise, any call to this method satisfying the exceptional precondition will
result in a postcondition violation. The code without the exceptional behavior declaration is presented below:
@ requires position >= 0;
@ assignable \nothing;
@ ensures (position < 0 || position >= AllergiesSetup.MAX_ALLERGY_ITEMS) ==> (\result == false);
@ ensures ((position >= 0 && position < AllergiesSetup.MAX_ALLERGY_ITEMS)
@ && allergies_model.itemAt(position) == null) ==> (\result == false);
@ ensures ((position >= 0 && position < AllergiesSetup.MAX_ALLERGY_ITEMS)
@ && allergies_model.itemAt(position) != null) ==> (\result == true);
@*/
public boolean validateAllergyPosition(short position) throws RemoteException, UserException;
}
Invariant problem at Appointments Impl constructor (package appointments)

The developer warns in a comment into Appointments Impl constructor: you have to insert the current
date, otherwise it will give you an invariant violation, so, to avoid the invariant problem the initialization of one
item of appointments (the testing code) should be removed; otherwise, an update of the constructors body
6
need to be done every day. The constructors body without the initialization of one item of appointments is
presented below:
public class Appointments_Impl implements Appointments {
public Appointments_Impl (/*SecurityService security*/) {
super();
appointments = new Appointment[(short)AppointmentsSetup.MAX_APPOINTMENT_ITEMS];
}
}
Invariant problem at CardException class (package javacard.framework)

In order to avoid this invariant problem, the developer should add the clause /*@ nullable @*/ to the
static field systemInstance. The code with the clause added is presented below:
public class CardRuntime extends RuntimeException {
private /*@ nullable @*/ static CardException systemInstance;
}
Invariant problem at CardRuntimeException class (package javacard.framework)

In order to avoid this invariant problem, the developer should add the clause /*@ nullable @*/ to the
static field systemInstance. The code with the clause added is presented below:
public class CardRuntimeException extends RuntimeException {
private /*@ nullable @*/ static CardRuntimeException systemInstance;
}
Precondition problem at arrayCopy method (package commons - CardUtil class)

This nonconformance occurs because the developer did not restrict the range of valid values for designa-
tion in the setDesignation (from Medicine interface) precondition suitably: instead of restricting the in-
put values by using the constant MEDICINE CODE LENGTH (5), the precondition uses the constant MAX ADMIN-
DESCRIPTION LENGTH (50), allowing a call to this method trying to copy an array of size 50 into an ar-
ray of size five. Therefore, to avoid this problem, the contract needs to be fixed, changing the requires to use
MEDICINE CODE LENGTH instead of MAX ADMIN DESCRIPTION LENGTH. The code with the precondition
fixed is presented below:
public interface Medicine extends Common{
@ requires designation != null && designation.length <= MedicinesSetup.MEDICINE_CODE_LENGTH;
@ assignable designation_model;
@ ensures (\forall int i; 0 <= i && i < designation.length;
@ designation_model.itemAt(i).equals(new JMLByte(designation[i])));
@*/
public void setDesignation(byte[] designation);
}
Constraint problems at getDate, getDoctor, getHour, getID, getLocal, getType, setDate, and toString meth-
ods
The nonconformances revealed by the methods getDate, getDoctor, getHour, getID, getLocal,
getType, setDate, and toString are related to some constraints defined into Common interface; so, the
way of solving them is to add a requires clause concerning the size of the values received as parameter in the
constructor of the classes who implement this interface, according to each constraint that can be violated. An
example of precondition is presented below, for the case of the Appointment Impl class:
public class Appointment_Impl implements Appointment {
/*@
@ requires date.length == DATE_LENGTH && hour.length == HOUR_LENGTH
@ && local.length == LOCAL_CODE_LENGTH && doctor.length == DOCTOR_CODE_LENGTH;
@*/
public Appointment_Impl(byte id, byte[] date, byte[] hour, byte[] local, byte[] doctor, byte
type){ //...
}
Invariant problem at Diagnostic Impl constructor (package diagnostics)

This nonconformance could be avoided by adding a precondition to the class constructor defining a range of
valid values to the parameters appointmentID and diagnosticID. The code with the suggested precondi-
tion is presented below:
public class Diagnostic_Impl implements Diagnostic {
/*@ requires 0 <= appointmentID && appointmentID <= 127 &&
@ 0 <= diagnosticID && diagnosticID <= 127;
@*/
public Diagnostic_Impl(byte appointmentID, byte diagnosticID){
//...
}
}
7
Postcondition problem at getDescription method (package diagnostics - Diagnostic Impl class)
The postcondition problem can be avoided by adding a precondition to getDescription method, checking
if the value of the parameter size is in range [0, MAX BUFFER BYTES-1] - the size of buffer field, and also
checking if the value of the parameter offset is in range [0, DiagnosticsSetup.MAX DESCRIPTION -
LENGTH-1] - the size of description field. The code added by this precondition is presented below:
public interface Diagnostic {
/*@ requires size >= 0 && size < MAX_BUFFER_BYTES;
@ requires offset >= 0 && offset < DiagnosticsSetup.MAX_DESCRIPTION_LENGTH;
@*/
public byte[] getDescription(short offset, short size);
}
Invariant problem at setAppointmentID method (package diagnostics - Diagnostic Impl class)

This nonconformance could be avoided by adding a precondition to the method defining a range of valid values
to the parameter appointmentID. The suggested precondition is presented below:
/*@ requires 0 <= appointmentID && appointmentID <= 127;
@ assignable appointmentID_model;
@ ensures appointmentID_model == appointmentID;
@*/
public void setAppointmentID(byte appointmentID);
}
Postcondition problem at setDescription method (package diagnostics - Diagnostic Impl class)

This nonconformance can be solved by adding a precondition defining that the range of valid values for
size buffer: [0, description buffer.length-1] and also for offset parameter: [0, Diagnosti-
csSetup.MAX DESCRIPTION LENGTH-1]. The code with the precondition suggested is presented below:
@ requires size_buffer >= 0 && size_buffer < description_buffer.length;
@ requires offset >= 0 && offset < DiagnosticsSetup.MAX_DESCRIPTION_LENGTH;
@ assignable description_model;
@*/
public void setDescription(byte[] description_buffer, short size_buffer,
short offset, boolean firstBlock);
}
Invariant problem at setDiagnosticID method (package diagnostics - Diagnostic Impl class)

This nonconformance could be avoided by adding a precondition to the method defining a range of valid values
to the parameter id. The code presenting the suggested precondition is available below:
/*@ requires 0 <= id && id <= 127;
@ assignable diagnosticID_model;
@ ensures diagnosticID_model == id;
@*/
public void setDiagnosticID(byte id);
}
Invariant problem at Medicine Impl constructor (package medicines)

Medicine Impl class implements Medicine interface and the interface has some invariants related to the
ids manipulated into the methods. However, the constructor has no preconditions restricting the range of values
received to those ids. Therefore, to prevent the occurrence of this nonconformance, the developer should add a
precondition taking care of the values received as parameters by the constructor. The constructor code added with
the precondition is presented subsequently:
public class Medicine_Impl implements Medicine {
@ requires 0 <= diagnosticID && diagnosticID <= 127;
@ requires 0 <= treatmentID && treatmentID <= 127;
@ requires 0 <= medicineID && medicineID <= 127;
@*/
public Medicine_Impl(byte appointmentID, byte diagnosticID, byte treatmentID, byte medicineID){
//...
}
}
Invariant problem at setAppointmentID method (package medicines - Medicine Impl class)

In order to avoid this problem, the developer should add a precondition to the method, defining the range of
valid values to the parameter appointmentID. The suggested precondition is presented below:
8
public interface Medicine {
//@ requires 0 <= appointmentID && appointmentID <= 127;
}
Invariant problem at setDiagnosticID method (package medicines - Medicine Impl class)

valid values to the parameter diagnosticID. The suggested precondition is presented below:
//@ requires 0 <= diagnosticID && diagnosticID <= 127;
public void setDiagnosticID(byte diagnosticID);
}
Invariant problem at setMedicineID method (package medicines - Medicine Impl class)

valid values to the parameter id. The suggested precondition is presented below:
//@ requires 0 <= id && id <= 127;
public void setMedicineID(byte id);
}
Invariant problem at setTreatmentID method (package medicines - Medicine Impl class)

valid values to the parameter treatmentID. The suggested precondition is presented below:
//@ requires 0 <= treatmentID && treatmentID <= 127;
public void setTreatmentID(byte treatmentID);
}
Invariant problem at Personal Impl constructor (package personal)

In order to avoid this invariant problem, the developer should initializes the field birthplace as follows:
birthplace = new byte[COUNTRY CODE LENGTH];- into the default constructor. The code with the
field initialization is presented below:
public class Personal_Impl implements Personal {
public Personal_Impl(/*SecurityService security*/){
super();
// ...
birthplace = new byte[COUNTRY_CODE_LENGTH];
// ...
}
}
Invariant problem at Treatment Impl constructor (package treatments)

This problem can be avoided by adding a precondition to the constructor, checking the values received as
parameters. The following code present a suggestion of precondition to the class constructor.
public class Treatment_Impl implements Treatment {
@ requires 0 <= diagnosticID && diagnosticID <= 127;
@ requires 0 <= treatmentID && treatmentID <= 127;
@*/
public Treatment_Impl(byte appointmentID, byte diagnosticID, byte treatmentID){
// ...
}
}
Postcondition problem at getMedicalRecommendation method (package treatments - Treatment Impl)

This nonconformance can be solved by adding a precondition to getMedicalRecommendation method,
checking the values received as parameters. The code added by the suggested precondition is presented as follows:
public interface Treatment {
/*@ requires offset >=0 && offset < MAX_MEDICALRECOMMENDATION_LENGTH;
@ requires size >= 0 && size < MAX_BUFFER_BYTES;
@*/
public byte[] getMedicalRecommendation(short offset, short size);
}
Invariant problem at setAppointmentID method (package treatments - Treatment Impl class)

For solving this problem, a developer needs to add a precondition at setAppointmentID method for
checking the value received as parameter. The suggestion of fix for the nonconformance is presented below:
9
//@requires 0 <= appointmentID && appointmentID <= 127;
}
Invariant problem at setDiagnosticID method (package treatments - Treatment Impl class)

For solving this problem, a developer needs to add a precondition at setDiagnosticID method for check-
ing the value received as parameter. The suggestion of fix for the nonconformance is presented below:
//@requires 0 <= diagnosticID && diagnosticID <= 127;
public void setDiagnosticID(byte diagnosticID);
}
Postcondition problem at setMedicalRecomendation method (package treatments - Treatment Impl class)

A way of solving the problem in this method it is to add a precondition checking if the number of bytes that is
wanted to be copied from recommendation buffer to the internal array is in the range of the recommen-
dation buffer (that is, if the number of elements to be copied is less than the array size).
//@ requires size_buffer < recommendation_buffer.length;
public void setMedicalRecommendation(byte[] recommendation_buffer, short size_buffer,
short offset, boolean firstBlock);
}
Invariant problem at setTreatmentID method (package treatments - Treatment Impl class)

For solving this problem, a developer needs to add a precondition at setTreatmentID method for checking
the value received as parameter. The suggestion of fix for the nonconformance is presented below:
//@requires 0 <= id && id <= 127;
public void setTreatmentID(byte id);
}
Postcondition problem at getVaccinationDate method (package vaccines - Vaccines Impl class)

The developer should remove the exceptional behavior specification from the getVaccinationDate
(Vaccines interface) method in order to avoid the postcondition problem, since the exceptional behavior de-
clares UserException as the only kind of exception to be thrown in this method, and the method throws an
ArrayIndexOutOfBoundsException when called with values greater than 50 (the value of MAX VACCI-
NE ITEMS setup field). The code without the exceptional behavior declaration is presented below:
public interface Vaccines extends Common {
@ requires position >= 0 && position < VaccinesSetup.MAX_VACCINE_ITEMS;
@ requires vaccines_model.itemAt(position) != null;
@ ensures (((Vaccine) vaccines_model.itemAt(position)).date_model).equals(toJMLValueSequence(\result));
@*/
public byte[] getVaccinationDate (short position) throws RemoteException, UserException;
}
Postcondition problem at getVaccineDesignation method (package vaccines - Vaccines Impl class)

The developer should remove the exceptional behavior specification from the getVaccineDesignation
NullPointerException when called with a value greater than two only three values are initialized into the
constructor. The code without the exceptional behavior declaration is presented below:
@ ensures (((Vaccine) vaccines_model.itemAt(position)).designation_model)
@ .equals(toJMLValueSequence(\result));
@*/
public byte[] getVaccineDesignation (short position) throws RemoteException, UserException;
}
Postcondition problem at removeVaccine method (package vaccines - Vaccines Impl class)

The developer should remove the exceptional behavior specification from the removeVaccine (Vacci-
nes interface) method in order to avoid the postcondition problem, since the exceptional behavior declares
10
UserException as the only kind of exception to be thrown in this method, and the method throws a ArrayIn-
dexOutOfBoundsException when there is a try to remove one element of one position from the array that
exceeds its the size when called with values greater than 50 (the value of MAX VACCINE ITEMS setup field).
The code without the exceptional behavior declaration is presented below:
@ assignable vaccines_model;
@ ensures vaccines_model.count(null) == \old(vaccines_model).count(null)+1;
@ ensures ((vaccines_model.subsequence(position, VaccinesSetup.MAX_VACCINE_ITEMS - 1 ))
@ .equals(\old(vaccines_model).subsequence(position+1, VaccinesSetup.MAX_VACCINE_ITEMS))
@ && vaccines_model.itemAt(VaccinesSetup.MAX_VACCINE_ITEMS - 1) == null)
@ || vaccines_model.itemAt(VaccinesSetup.MAX_VACCINE_ITEMS - 1) == null;
@*/
public void removeVaccine (short position) throws RemoteException, UserException;
}
Postcondition problem at setVaccineDesignation method (package vaccines - Vaccines Impl class)

The developer should remove the exceptional behavior specification from the setVaccineDesignation
NullPointerException when called with a value greater than two only three values are initialized into the
constructor. The code without the exceptional behavior declaration is presented below:
@ requires designation != null && designation.length == VaccinesSetup.VACCINE_CODE_LENGTH;
@ requires (\forall int i; 0 <= i && i < VaccinesSetup.VACCINE_CODE_LENGTH;
@ assignable vaccines_model;
@ ensures (((Vaccine) vaccines_model.itemAt(position)).designation_model)
@*/
public void setVaccineDesignation (short position, byte[] designation)
}
Postcondition problem at validateVaccinePosition method (package vaccines - Vaccines Impl class)

The developer should remove the exceptional behavior definition from the validateVaccinePosition
(Vaccines interface) method; otherwise, any call to this method satisfying the exceptional precondition will
result in a postcondition violation. The code without the exceptional behavior declaration is presented below:
@ requires position >= 0;
@ ensures (position < 0 || position >= VaccinesSetup.MAX_VACCINE_ITEMS) ==> (\result == false);
@ ensures ((position >= 0 && position < VaccinesSetup.MAX_VACCINE_ITEMS)
@ && vaccines_model.itemAt(position) == null) ==> (\result == false);
@ ensures ((position >= 0 && position < VaccinesSetup.MAX_VACCINE_ITEMS)
@ && vaccines_model.itemAt(position) != null) ==> (\result == true);
@*/
public boolean validateVaccinePosition(short position)
}
2.2.5 JAccounting
Evaluation problem at getCurrency method (package accounting.basic - Account class)
This nonconformance occurs because the field currency is not initialized into the default constructor of
Account class, so, a way of solving it is to initialize the field directly in its declaration. The code presenting this
initialization is presented below:
public class Account {
/*@ spec_public @*/String currency = "";
}
11
Evaluation problem at getDescription method (package accounting.basic - Account class)
This nonconformance occurs because the field description is not initialized into the default constructor
of Account class, so, a way of solving it is to initialize the field directly in its declaration. The code presenting
this initialization is presented below:
public String description = "";
}
Postcondition problem at getName method (package accounting.basic - Account class)

This nonconformance occurs because the field name is not initialized into the default constructor of Account
class, so, a way of solving it is to initialize the field directly in its declaration. The code presenting this initialization
is presented below:
public String name = "";
}
Postcondition problem at getType method (package accounting.basic - AccountingCustomer class)

This problem can be solved by changing the precondition of setType method: instead of be //@ requi-
res true, the precondition should be //@ requires type >= 0 in order to avoid an assignment of a
negative value to type field. Below it is presented the code with the updated precondition of setType method.
public class AccountingCustomer {
//@ requires type >= 0;
//@ ensures this.type == type;
public void setType(int type) {
this.type = type;
}
}
Postcondition and Evaluation problems at getName method (package accounting.basic - AClass class)
A way of solving both nonconformances that can appear in this method is to add a precondition for getName,
checking if the field name is not null and not equals to the empty string. The code added by this precondition is
presented as follows:
public class AClass extends Object {
//@ requires this.name != null && !this.name.equals("");
//@ post !\result.equals("");
public String getName() {
return name;
}
}
Postcondition problem at arrayToString method (package util - ArrayUtils class)

This problem can be solved by adding a precondition to arrayToString method concerning about the size
of the array received as parameter. The code added by the precondition is presented below:
public class ArrayUtils extends Object {
//@ requires sarray.length > 1;
//@ post !\result.equals("");
public static String arrayToString(String sarray[]){
// ...
}
}
Postcondition problem at getMaxIntArrayIndex method (package util - ArrayUtils class)

This problem can be solved by adding a precondition to getMaxIntArrayIndex method concerning about
the size of the array received as parameter. The code added by the precondition is presented below:
//@ pre intarray != null && intarray.length > 0;
//@ post true;
public static int getMaxIntArrayIndex(int intarray[]){
// ...
}
}
Postcondition problem at stringArrayToIntArray method (package util - ArrayUtils class)

This problem occurs because there is no checking in the precondition concerning to the values into the array
received as parameter; so, to solve this problem, the developer should change the precondition (//@ pre true)
into one in which the array elements are checked to satisfy the requirement from parseInt method The
characters in the string must all be decimal digits, except that the first character may be an ASCII minus sign
12
- to indicate a negative value or an ASCII plus sign + to indicate a positive value.7 The code presenting the
precondition is shown below:
//@ requires (\forall int i; 0 <= i && i < sarray.length; sarray[i].matches("[0-9]+"));
public static int[] stringArrayToIntArray(String sarray[]){
// ...
}
}
Invariant problem at byteArrayDataSource method (package mail - ByteArrayDataSource class)

To avoid this nonconformance the developer should add the clause /*@ nullable @*/ in the declaration
of baos field. The suggestion of fix is presented below:
public class ByteArrayDataSource implements DataSource {
private /*@ nullable @*/ ByteArrayOutputStream baos = null;
}
Invariant problem at ByteArrayDataSource constructor (package util - ByteArrayDataSource class)

To avoid this nonconformance the developer should add the clause /*@ nullable @*/ in the declaration
of baos field. The suggestion of fix is presented below:
public class ByteArrayDataSource implements DataSource {
private /*@ nullable @*/ ByteArrayOutputStream baos;
}
Invariant problem at Charge constructor (package accounting.basic - Charge class)

In order to solve this nonconformance, the developer should initializes all fields into the constructor oth-
erwise all getter methods will result in a null return, violating the default assumption of JML that all fields and
method returns are not null (null is not the default)[Leavens et al. 2013]. The constructor initializing all fields of
Charge class is presented as follows:
public class Charge implements Cloneable {
public Charge() {
id = new Integer(0);
created = new Date();
updated = new Date();
companyKey = new Integer(0);
customerKey = new Integer(0);
invoiceKey = new Integer(0);
chargeNumber = new Integer(0);
chargeDate = new Date();
memo = "";
recurrence = new Recurrence();
currency = "";
}
}
Postcondition problem at getId method (package accounting.basic - Company class)

In order to solve this nonconformance, the developer should initializes all fields into the constructor, avoiding
that a call to getId returns a null value and breaks the method postcondition. A code initializing all fields from
Company class is presented below:
public class Company implements java.io.Serializable {
//@ pre true;
//@ post active == true;
public Company(){
id = new Integer(0);
name = "";
active = true;
}
}
Postcondition problem at getCookie method (package util - class CookieUtils)

This problem can be solved by adding checks for the parameters name and value into the precondition of
getCookie in order to satisfy the requirements of Cookie API8 : cookie name must not be null or empty or
contains any illegal characters (for example, a comma, space, or semicolon) or matches a token reserved for use
by the cookie protocol. The strengthened precondition is presented below:
public class CookieUtils extends Object {
//@ requires seconds >= 0;
//@ requires name.indexOf(" ") == -1 && name.indexOf(",") == -1 && name.indexOf(";") == -1;
7 https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html
8 https://docs.oracle.com/javaee/6/api/javax/servlet/http/Cookie.html
13
//@ requires value != null;
public static Cookie getCookie(String name, String value, int seconds){
// ...
}
}
Postcondition problem at getDeleteCookie method (package util - class CookieUtils)

This problem can be solved by adding a precondition to check the value received into the parameter name in
order to satisfy the requirements of Cookie API: cookie name must not be null or empty or contains any illegal
characters (for example, a comma, space, or semicolon) or matches a token reserved for use by the cookie protocol.
The added precondition is presented below:
public class CookieUtils extends Object {
//@ requires name.indexOf(" ") == -1 && name.indexOf(",") == -1 && name.indexOf(";") == -1;
public static Cookie getDeleteCookie(String name){
// ...
}
}
Postcondition problem at getCustomerKey method (package accounting.basic - CustomerLog class)

As the class has the clause /*@ nullable by default @*/ the postcondition should be weaken to deal
with the case in which the get method is called before a set to customerKey field. The weaken postcondition is
presented below:
public class CustomerLog {
//@ post \result >= 0;
public int getCustomerKey() {
//...
}
}
Postcondition problem at monthAsString method (package util - DateUtils class)

Although the developer have added this comment in the method: months range from 0 to 11, there is no
precondition to check that; therefore, to solve this nonconformance we need to add a precondition checking if the
value received as parameter is in range [0, 11]. The precondition for this checking is available below:
public class DateUtils extends Object {
//@ requires 0 <= month && month <= 11;
public static String monthAsString(int month){
// ...
}
}
Invariant problem at Mailer constructor (package mail - Mailer class)

Since this class has three constructors available, the developer should add a clause /*@ nullable @*/ for
each field that is not initialized in at least one of those constructors. This suggestion is presented below:
public class Mailer {
/*@ nullable @*/ InternetAddress[] to;
/*@ nullable @*/ InternetAddress from;
/*@ nullable @*/ InternetAddress[] cc;
/*@ nullable @*/ InternetAddress[] bcc;
/*@ nullable @*/ String subject;
/*@ nullable @*/ String body;
}
Invariant problem at Mailer constructor (package util - Mailer class)

Since this class has three constructors available, the developer should add a clause /*@ nullable @*/ for
each field that is not initialized in at least one of those constructors. This suggestion is presented below:
public class Mailer {
/*@ nullable @*/ InternetAddress[] to;
/*@ nullable @*/ InternetAddress from;
/*@ nullable @*/ InternetAddress[] cc;
/*@ nullable @*/ InternetAddress[] bcc;
/*@ nullable @*/ String subject;
/*@ nullable @*/ String body;
}
Invariant problem at PageElements constructor (package accounting.model - PageElements class)

To avoid this problem, the developer should initializes all fields of this class. The initialization of the fields is
presented below:
14
public class PageElements {
String pageTitle = "";
String sectionColor = "";
String sectionTitle = "";
String mainPage = "";
String searchSection = "";
}
Invariant problem at PaymentDistribution (package accounting.basic - PaymentDistribution class)

This nonconformance can be avoided by the initialization of all fields from this class. The code for that
initialization is presented as follows:
public class PaymentDistribution {
Integer id = new Integer(0);
Integer paymentKey = new Integer(0);
Integer invoiceKey = new Integer(0);
Transaction transaction = new Transaction();
Integer transactionKey = new Integer(0);
Integer companyKey = new Integer(0);
}
Invariant problem at Preferences (package accounting.setup - Preferences class)

This problem may be solved by the initialization of fromEmail field. The code with this initialization is
presented below:
public class Preferences{
String fromEmail = "";
}
Invariant problem at Product (package accounting.basic - Product class)

This nonconformance can be fixed by the initialization of all fields from Product class. The code presenting
this initialization is the following:
public class Product{
String name = "";
String description = "";
String code = "";
BigDecimal rate = new BigDecimal("0.0");
Integer accountKey = new Integer(0);
}
Invariant problem at Recurrence (package accounting.common - Recurrence class)

This nonconformance can be fixed by the initialization of all fields from Recurrence class. The code
presenting this initialization is the following:
public class Recurrence {
/*@spec_public@*/Long id = new Long(0);
/*@spec_public@*/String realm = "";
/*@spec_public@*/String itemKey = "";
Date startDate = new Date();
Date endDate = new Date();
Date nextDate = new Date();
}
Invariant problem at Recurrence StringDataSource (package mail - StringDataSource class)

This nonconformance can be fixed by the initialization of all fields from StringDataSource class. The
code presenting this initialization is the following:
public class StringDataSource implements DataSource {
String s = "";
StringReader in = new StringReader("");
StringWriter out = new StringWriter();
}
Invariant problem at Tax (package accounting.basic - Tax class)

This nonconformance can be fixed by the initialization of all fields from Tax class. The code presenting this
initialization is the following:
public class Tax implements Cloneable {
String name = "";
BigDecimal percent = new BigDecimal("0.0");
Integer payableAccountKey = new Integer(0);
Integer receivableAccountKey = new Integer(0);
Integer invoiceKey = new Integer(0);
}
15
2.2.6 Javacard
Invariant problem at APDU (package javacard.framework - APDU class)
To solve this problem, the developer should add a clause: /*@ nullable @*/ to the declarations of
buffer and instance fields. Another option could be initialize both fields. The code with the former
suggestion is presented below:
public final class APDU {
private /*@ nullable @*/ byte[] _buffer;
private /*@ nullable @*/ static APDU _instance;
}
Invariant problem at CardException (package javacard.framework - CardException class)

In order to solve the problem, the developer could initialize the field systemInstance with a new Card-
Exception. The code containing this initialization is presented as follows:
public class CardException extends java.lang.Exception {
private static /*@ spec_public @*/ CardException _systemInstance = new CardException((short) 0);
}
Invariant problem at CardRuntimeException class (package javacard.framework)

In order to solve the problem, the developer could initialize the field systemInstance with a new Card-
RuntimeException. The code containing this initialization is presented as follows:
public class CardRuntimeException extends java.lang.RuntimeException {
private static /*@ spec_public @*/ CardRuntimeException _systemInstance =
new CardRuntimeException((short) 0);
}
Invariant problem at minPadLen method (package javacardx.crypto - CipherImpl class)

To solve this problem, the developer should add a clause: /*@ nullable @*/ to the declarations of key
and to read fields. The code with the clause added to the fields declaration is provided below:
public class CipherImpl extends Cipher {
protected /*@nullable@*/ Key _key = null;
protected /*@nullable@*/ short[] _read = null;
}
Invariant problem at KeyAgreementImpl and KeyAgreementImplExt classes (package javacard.security)

To avoid this problem, one should add a /*@ nullable @*/ clause to the declaration of privateKey
field. The code presenting this clause added to the field is presented below:
public class KeyAgreementImpl extends KeyAgreement {
protected /*@nullable@*/ PrivateKey _privateKey = null;
}
Invariant problem at minPadLen method (package javacard.security - SignatureImpl class)

To solve this problem, the developer should add a clause: /*@ nullable @*/ to the declarations of key
and to read fields. The code with the clause added to the fields declaration is provided below:
public class SignatureImpl extends Signature {
protected /*@nullable@*/ Key _key = null;
protected /*@nullable@*/ short[] _read = null;
}
2.2.7 Mondex
Invariant problem at APDU class (package javacard.framework)
This problem can be solved by the initialization of the buffer array in order to avoid the violation of one
class invariant. The code presenting the initialization of the field is presented below:
public final class APDU {
private /*@ spec_public @*/ byte[] _buffer = new byte[BUFFER_LENGTH];
}
Invariant problem at ConPurseJC class

As we discussed in our previous tech report [Milanez 2015], the nonconformance in this class is caused by
two problematic parts: the first part is related to the elements from exLog field that are not initialized into the
constructor - so the part (\forall byte i; i>=0 && i<exLog.length; exLog[i] != null); is
violated; and the second part is related to the value received by PayDetails - transaction.value, once
16
PayDetails initializes this value with 0 the invariant (transaction.value > 0) is also broken. There-
fore, the developer needs to add a fix in the code: initializes the exLog array and change the invariant. After
contacting Mondex [Schmitt and Tonin 2007] developers, they suggested the following changes to solve the non-
conformance:
public class ConPurseJC extends Applet {
/*@ public invariant
@ (exLog != null) && (exLog.length > 0) && (exLog.length < (APDU.BUFFER_LENGTH / 10)) &&
@ (logIdx >= 0) && (logIdx <= exLog.length) && (balance >= 0) && (balance <= ShortMaxValue) &&
@ (nextSeq >= 0) && (nextSeq <= ShortMaxValue) && (status >= 0) && (status <= 5) &&
@ (transaction != null) && ((transaction.value > 0) ||
@ ((status == Idle) && (transaction.fromName == 0) && (transaction.toName == 0) &&
@ (transaction.value == 0) && (transaction.fromSeq == 0) && (transaction.toSeq == 0))) &&
@ ((status == Epr) ==> (transaction.value <= balance)) &&
@ ((status == Epv) ==> (transaction.value <= (ShortMaxValue - balance))) &&
@ (\forall byte i; i>=0 && i<exLog.length; exLog[i] != null);
@*/
// Code changes
private ConPurseJC(){
// ...
// exLog length must be smaller or equal than the 1/10 APDU buffer length
exLog = new PayDetails[25];
for(short i=0; i<exLog.length; i++){
exLog[i] = new PayDetails();
}
//...
}
}
2.2.8 PokerTop
Invariant problem at Dealer class
This problem can be solved by removing the comments (\\) from the lines where the fields button and pot
are initialized. The code with all fields initialized is presented below:
public Dealer() {
this.blind = new Blind(0, 0, 0);
this.button = new Button();
this.deck = new Deck();
this.pot = new Pot(0);
}
2.2.9 Samples
Package dbc
Postcondition problem at angle method (package samples.dbc - Polar class)
Since the problem in this method is apparently related to a call to JMLDouble API, a way of solving the
problem is changing the postcondition of angle method into Complex interface. The code presenting the
suggested postcondition is presented below:
public /*@ pure @*/ interface Complex {
/*@
@ ensures StrictMath.atan2(imaginaryPart(), realPart()) <= \result + tolerance ||
@ StrictMath.atan2(imaginaryPart(), realPart()) >= \result + tolerance;
@*/
double angle();
}
Postcondition problem at imaginaryPart method (package samples.dbc - Polar and Rectangular classes)
In both classes, the problem is apparently related to the call to JMLDouble API, so, a way of solving it
is changing the postcondition of imaginaryPart method into Complex interface. The code presenting the
/*@
@ ensures \result + tolerance >= magnitude()*StrictMath.sin(angle()) ||
@ \result + tolerance <= magnitude()*StrictMath.sin(angle()) ||
@ Double.isNaN(\result);
@*/
double imaginaryPart();
}
17
Postcondition problem at realPart method (package samples.dbc - Rectangular class)
Since the problem in this method is apparently related to a call to JMLDouble API, a way of solving the
problem is changing the postcondition of realPart method into Complex interface. The code presenting the
/*@
@ ensures \result + tolerance >= magnitude()*StrictMath.cos(angle()) ||
@ \result + tolerance <= magnitude()*StrictMath.cos(angle()) ||
@ Double.isNaN(\result);
@*/
double realPart();
}
Package list
Postcondition problem at getEntry method (package samples.list.list1 - DLList class)
This problem may be solved by adding a /*@ nullable @*/ clause in the method declaration. The code
added by this clause is shown below:
public class DLList extends E_SLList {
public /*@ nullable @*/ Object getEntry() {
// ...
}
}
Postcondition problem at equals method (package samples.list.list2 - E OneWayList class)

The problem occurs because a code error into equalsNode method when comparing the elements from one
E OneWayList in order to check if the two objects are equal. So, to solve the problem, a developer needs to
change one return clause from this method (false to true); otherwise, an object would never be equals to itself.
The code updated is presented as follows:
public class E_OneWayList extends OneWayList {
private /*@ pure @*/ boolean equalsNode(/*@nullable@*/ OneWayNode nd1, /*@nullable@*/ OneWayNode nd2) {
if (nd1 == null && nd2 == null) {
return true;
} else if (nd1 == null || nd2 == null) {
return false;
} else if (nd1.getEntry() == nd2.getEntry()) {
if (nd1 == nd2) {
return true; // changed here
} else {
return equalsNode(nd1.getNextNode(), nd2.getNextNode());
}
} else {
return false;
}
}
}
Postcondition problem at first method (package samples.list.list2 - TwoWayIterator class)

A way of solving this problem is by weakening the precondition of first method, by adding a requires
true clause. The code added by this precondition is presented below:
public class TwoWayIterator implements RestartableIterator {
/*@
@ also
@ requires true;
@*/
public void first() {
// first node/link is a sentinel
currLink_ = (TwoWayNode) firstLink_.getNextNode();
}
}
Postcondition problem at equals method (package samples.list.list3 - E OneWayList class)

The problem occurs because a code error into equalsNode method when comparing the elements from one
E OneWayList in order to check if the two objects are equal. So, to solve the problem, a developer needs to
change one return clause from this method (false to true); otherwise, an object would never be equals to itself.
The code updated is presented as follows:
public class E_OneWayList extends OneWayList {
private /*@ pure @*/ boolean equalsNode(/*@nullable@*/ OneWayNode nd1, /*@nullable@*/ OneWayNode nd2) {
if (nd1 == null && nd2 == null) {
return true;
} else if (nd1 == null || nd2 == null) {
return false;
18
} else if (nd1.getEntry() == nd2.getEntry()) {
if (nd1 == nd2) {
return true; // changed here
} else {
return equalsNode(nd1.getNextNode(), nd2.getNextNode());
}
} else {
return false;
}
}
}
Postcondition problem at first method (package samples.list.list3 - TwoWayIterator class)

A way of solving this problem is by weakening the precondition of first method, by adding a requires
true clause. The code added by this precondition is presented below:
public class TwoWayIterator implements RestartableIterator {
/*@
@ also
@ requires true;
@*/
public void first() {
// first node/link is a sentinel
currLink_ = (TwoWayNode) firstLink_.getNextNode();
}
}
Evaluation problem at getEntry method (package samples.list.node2 - Link class)

For solving this problem, the developer should initializes the field node in order to avoid the evaluation error
into getEntry postcondition. The code presenting this initialization is presented below:
public /*@ pure @*/ class Link {
protected /*@ nullable @*/ OneWayNode node_ = new OneWayNode();
}
Postcondition problem at toString method (package samples.list.node2 - OneWayNode class)

A way of solving this problem is to adding a clause /*@ nullable @*/ in the declaration of the method.
The code added by this clause is presented below:
public class OneWayNode {
public /*@ pure nullable @*/ String toString() {
return stringOfEntries(this);
}
}
Package misc
Postcondition problem at limit method (package samples.misc - SingleSolution class)
In order to solve this problem, the developer should add a precondition to SingleSolution constructor
restricting the parameter n to be greater than or equals to zero. The code presenting this precondition is available
below:
public abstract class SingleSolution extends LinearSearch {
//@ requires n >= 0;
//@ assignable this.n;
//@ ensures this.n == n;
public SingleSolution(int n) {
this.n = n;
}
}
Package stacks
Postcondition and Invariant problems at BoundedStack (package samples.stacks)
The two nonconformances present in this class are related to the same problem: the absence of a precondition
in the constructor that restricts the range of valid values to the parameter maxSize. The code presenting the
precondition for the constructor is presented below:
public class BoundedStack implements BoundedStackInterface {
@ requires maxSize > 0;
@ assignable MAX_SIZE, size, theStack;
@ ensures theStack.equals(new JMLObjectSequence());
@ ensures_redundantly theStack.isEmpty() && size == 0
@ && MAX_SIZE == maxSize;
@*/
public BoundedStack(int maxSize){
theItems = new Object[maxSize];
19
nextFree = 0;
this.maxSize = maxSize;
}
}
Postcondition problem at toString method (package samples.stacks - BoundedStack class)

Since the class internally maintains an array of Objects - representing the items into the stack (field
theItems), the developer should add a try-catch into toString method in order to avoid exceptions
when getting the string value of each object into the array. The code presenting the try-catch block is shown
below:
/*@ also
@ public normal_behavior
@ ensures \result != null && (* a string encoding of this is returned *);
@*/
public String toString(){
StringBuffer ret = new StringBuffer(this.getClass().toString() + " [");
boolean first = true;
for (int k = nextFree - 1; k >= 0; k--) {
if (first) {
first = false;
} else {
ret.append(", ");
}
try {
if (theItems[k] != null) {
ret.append(theItems[k]);
} else {
ret.append("null");
}
} catch (NullPointerException e) {
ret.append("null");
}
}
ret.append("]");
return ret.toString();
}
}
Postcondition and Invariant problems at BoundedStack (package samples.stacks2)

The two nonconformances present in this class are related to the same problem: the absence of a precondition
in the constructor that restricts the range of valid values to the parameter maxSize. The code presenting the
precondition for the constructor is presented below:
@ requires maxSize > 0;
@ assignable MAX_SIZE, size, theStack;
@ ensures theStack.equals(new JMLObjectSequence());
@ ensures_redundantly theStack.isEmpty() && size == 0
@ && MAX_SIZE == maxSize;
@*/
public BoundedStack(int maxSize){
theItems = new Object[maxSize];
nextFree = 0;
this.maxSize = maxSize;
}
}
Postcondition problem at toString method (package samples.stacks2 - BoundedStack class)

Since the class internally maintains an array of Objects - representing the items into the stack (field
theItems), the developer should add a try-catch into toString method in order to avoid exceptions
when getting the string value of each object into the array. The code presenting the try-catch block is shown
below:
/*@ also
@ public normal_behavior
@ ensures \result != null && (* a string encoding of this is returned *);
@*/
public String toString(){
StringBuffer ret = new StringBuffer(this.getClass().toString() + " [");
boolean first = true;
for (int k = nextFree - 1; k >= 0; k--) {
if (first) {
20
first = false;
} else {
ret.append(", ");
}
try {
if (theItems[k] != null) {
ret.append(theItems[k]);
} else {
ret.append("null");
}
} catch (NullPointerException e) {
ret.append("null");
}
}
ret.append("]");
return ret.toString();
}
}
2.2.10 TheSchorrWaiteAlgorithm
Postcondition problem at getChild method (HeapObject class)
Since the problem occurs because the method returns a null value, a developer might add the clause /*@
nullable @*/ in the method declaration in order to avoid the nonconformance (null is not the default). The
code added by this clause is presented as follows:
public class HeapObject {
public /*@ nullable @*/ HeapObject getChild(int pos) {
//...
}
}
Invariant problem at SchorrWaite class

The problem occurs by the violation of the default invariant from JML: all fields must be non null; so, to
solve the problem the developer should add /*@ nullable @*/ to the declaration of fields current and
previous, or initializes them. The code presenting the former option is presented below - we chose suggest the
clause /*@ nullable @*/ based on the method mark from the class, and the comment available before the
class declaration This class implements the graph marking algorithm known as Schorr-Waite algorithm.:
public class SchorrWaite {
private /*@ nullable @*/ HeapObject previous;
private /*@ nullable @*/ HeapObject current;
}
2.2.11 TransactedMemory
Package JavaImplementation
Invariant problem at DPage class (package JavaImplementation)
In order to solve this nonconformance, the developer should add a precondition to DPage constructor, defining
the range of valid values to the parameters that are related to the invariants of this class. The code presenting this
precondition is shown as follows:
public class DPage{
//@ requires 0 <= tag && tag < TransactedMemory.TSIZE;
//@ requires VA <= version && version <= VC;
//@ requires 0 <= generation && generation < MAXGEN;
//@ requires 0 <= pageNumber && pageNumber < InfoSeq.SSIZE;
public DPage (boolean pageInUse, int tag, int info, int generation, int pageNumber, int version) {
//...
}
}
Invariant problem at DTagData class (package JavaImplementation)

In order to solve this nonconformance, the developer should add a precondition to DTagData constructor,
defining the range of valid values to the parameter size. The code with the precondition is presented below:
public class DTagData{
//@ requires size > 0;
public DTagData(boolean tagInUse, int size, boolean committed){
//...
}
}
21
Package JavaImplementationEnums
Invariant problem at DTagData class (package JavaImplementationEnums)
In order to solve this nonconformance, the developer should add a precondition to DTagData constructor,
defining the range of valid values to the parameter size. The code with the precondition is presented below:
public class DTagData{
//@ requires size > 0;
public DTagData(boolean tagInUse, int size, boolean committed){
//...
}
}
Invariant problem at Generation class (package JavaImplementationEnums)

In order to solve this nonconformance, the developer should add a precondition to Generation constructor,
defining the range of valid values to the parameter sh. The code with the precondition is presented below:
public class Generation {
//@ requires 0 <= sh && sh < TransactedMemory.MAXIND;
public Generation(int sh){
//...
}
}
Invariant problem at GenGenbyte class (package JavaImplementationEnums)

The problem can be solved by initializing the fields oldGen and newGen with Generation objects. The
initialization suggested is presented as follows:
public class GenGenbyte{
/** oldest and newest generation */
public Generation oldGen = new Generation(0);
public Generation newGen = new Generation(1);
}
Invariant problem at Tag class (package JavaImplementationEnums)

In order to solve this nonconformance, the developer should add a precondition to Tag constructor, defining
the range of valid values to the parameter sh.
public class Tag {
//@ requires 0 <= sh && sh < TransactedMemory.TSIZE;
public Tag(int sh){
//...
}
}
Precondition problem at DRead method (package JavaImplementationEnums - TransactedMemory class)

This problem occurs because TestFramework class has a TransactedMemory object, created by calling
the default constructor of TransactedMemory - and the constructor marks all DTagData objects from ddata
array as not in use (tagInUse is set to false), in this way, when the method DRead is called, its precondition
//@ requires ddata[tag.value].tagInUse; is broken. To solve this issue, the developer should
add a call to CarefulDNewTag method into any method that calls DRead; otherwise, this method will never be
able to run. The code presenting the call to CarefulDNewTag is presented below:
public class TestFramework {
public static void Increase(Tag tag) throws UnusedTagException, OutOfTransactedMemoryException,
CardTearException{
try {
theTransactedMemory.CarefulDNewTag(1);
} catch (OutOfTagsException e) {
e.printStackTrace();
}
}
}
Invariant problem at Version class (package JavaImplementationEnums)

In order to solve this nonconformance, the developer should add a precondition to Version constructor,
defining the range of valid values to the parameter sh. The following code presents this precondition:
public class Version {
//@ requires VA <= sh && sh <= VC;
public Version(int sh){
//...
}
}
22
2.3 Results
In Table 2 we make available a summary of all fixes suggested through the Section 2.2. According to the fix
suggested, we grouped them and display the artifact in which this fix should be applied. Column Artifact exposes
the artifact in which the fix should be implemented. Then, column Kind of fix shows the kinds of recommended
fix. Finally, column # instances display how many times this fix was proposed by the manual analysis of each
nonconformance. Moreover, Table 3 presents the fixes grouped for each experimental unit.
Table 2: Fixes summary. Column Artifact groups the fixes by the part (code or contract) in which the fix is
implemented. Column Kind of fix shows the kinds of fixing recommended. Column # instances display the
number of occurrences of each kind of fix.
Artifact Kind of fix # instances
Add precondition 47
Contract Update an existing contract clause 25
Add nullable clause 19
Initialization of field(s) 21
Code
Change the body of a method 7
Concerning the artifact, the manually suggested fixes are distributed in the following way: 91 fixes into the
contracts and 28 into the code. Most of the suggested fixes are related to add a precondition to a method or
constructor (Add precondition) with 47 occurrences. And regarding to code changes, the necessity of initialization
of some field is also recurrent (21).
Respecting the experimental units used, in nine of them the contract was the part in which more fixes were
needed, only in Mondex and PokerTop the code fix was more common. For those units, there were six cases
in which just one or two kinds of fixing was needed to solve all nonconformances: Bank, Dnivra-Jive,
Javacard, Mondex, PokerTop, and TheSchorrWaiteAlgorithm. On the other hands, the units with
the biggest numbers of nonconformances were those in which more different kinds of fixing were applied:
HealthCard (5), Samples (5), JAccounting (4).
2.4 Discussion
As presented in Section 2.3, the most common fix was add a precondition to a method or constructor. This
result it was expected by the fact of developers in general tend to be more opened in the precondition and add
restrictions into postconditions or invariants. Furthermore, previous studies [Milanez 2014], [Milanez 2015]
have already found Weak precondition as the most typical likely cause for nonconformances. As the Design by
Contract [Meyer 1997] methodology establishes rights and obligations for both clients and suppliers, the definition
of a precondition is a task that demands experience: if the precondition is so restrictive clients may be missed;
however, if it does not impose any restrictions, suppliers may be not able to deliver what they are supposed to.
Furthermore, sometimes the clients are not known when the supplier system is being developed, and the developer
needs to look for a reasonable trade-off between the level of restrictions and commitment of each part of the
system (e.g. each method or class).
In JML [Leavens et al. 2006] null is not the default [Leavens et al. 2013], because of this requirement, we have
40 suggestions related to: 19 cases where we believe that the add of /*@ nullable @*/ clause is suitable (the
Add nullable clause into Table 2) indicating to the JML compiler [Cheon and Leavens 2002] that a field or
method return may be null; and 21 cases where the initialization of some fields is apparently more applicable in
order to solve the nonconformance. Theses nonconformances related to null may have been occurred in reason of
some update into the JML language made after the development of the experimental units or because the contract-
aware compiler used into J ML O K 2 - the jmlc [Cheon and Leavens 2002]; nevertheless, it is important to solve the
problems either by adding a clause to say to the compiler that null is allowed or by assigning a value to a class
field.
Given the correction of a nonconformance may involve changing code, contracts, or both [Pei et al. 2014a],
we had some cases in which a change in the code and in the contract was needed to solve the problem. This was
the case of a nonconformance into Mondex [Schmitt and Tonin 2007] system: the nonconformance presented
in ConPurseJC class required a change in the body of ConPurseJC constructor and a change into one class
invariant. We also found some instances where it was possible change code or contract, as for instance, the
23
Table 3: Fixes summary for each experimental unit. Column Experimental Unit presents the name of each unit.
Column Artifact groups the fixes by the part (code or contract) in which the fix is implemented. Column Kind of
fix shows the kinds of recommended. Column # instances display the number of occurrences of each kind of fix.
Experimental Unit Artifact Kind of fix # instances
Contract Add nullable clause 2
Bank
Code Change the body of a method 1
Add nullable clause 2
Contract
Bomber Add precondition 2
Code Initialization of field(s) 1
Add precondition 3
Dnivra-Jive Contract
Update an existing contract clause 3
Add precondition 24
Contract Update an existing contract clause 13
HealthCard Add nullable clause 2
Code
Add precondition 7
JAccounting
Javacard
Mondex Code Initialization of field(s) 2
PokerTop Code Initialization of field(s) 1
Contract Add precondition 5
Samples Add nullable clause 2
Code
TheSchorrWaiteAlgorithm Contract Add nullable clause 2
Contract Add precondition 6
TransactedMemory Change the body of a method 1
Code
cases related to null values: in which add a /*@ nullable @*/ clause or initializes the field, would solve the
problem. In such cases, we looked into class comments in order to choose a suitable correction.
Notwithstanding, there were problems where a single correction was able to solve two or more nonconforman-
ces. This was the case of Common interface (HealthCard unit) constraint problems: by adding a precondition to
the constructor of Appointment Impl class, all problems were solved. Other case were the nonconformances
of evaluation and postcondition into getName from AClass (JAccounting unit) that were solved by adding a
single precondition to the method. Those cases are in accordance to software testing concepts [Sommerville 2010]:
several failures may be related to the same error - in the context of contract-based programs, the error can be in
the source code, in the contracts, or in both.
3 Related Work
In the context of contract-based programs [Guttag et al. 1993], the AutoFix [Wei et al. 2010], [Pei et al. 2011],
[Pei et al. 2014a], [Pei et al. 2014b] approach is available for Eiffel [Meyer 1987] programs. AutoFix is a tech-
nique and supporting tool that can generate corrections for faults of general-purpose software automatically. The
tool combines various program analysis techniques such as dynamic invariant inference, simple static analysis,
and fault localization and produces a collection of suggested fixes, ranked according to a heuristic measurement
24
of relevance. This tool is currently integrated into EiffelStudio Development Environment [Pei et al. 2015]. In
this work, we address the manual suggestion of fixes for the context of Java/JML programs, aiming to create a
basis for automation of the correction process.
4 Conclusions
In the present paper, we created a set of fix suggestions for the 119 nonconformances detected by J ML O K 2 in a
previous study [Milanez 2015]. For each nonconformance being corrected, we explain the thought line followed
and present a code excerpt (either source code or contract code) that is able to solve the problem. As presented in
Section 2.2, we were able to find more than one fix to some problems, so we presented the reasons for choosing
between one or another. In other cases, we detected one fix as being able to solve more than one nonconformance.
All experimental units updated with the fixes suggested in this study are available online.9
We also found that the contract is the artifact in which more changes are needed (77% of the cases) and the
most common fix was the addiction of a precondition to a method or constructor (39.5% of the cases). Moreover,
changes to code were also recurrent: the initialization of fields where the solution for 21 nonconformances.
This work is a step towards to understand the process of correcting nonconformances in Java/JML programs.
As future work, we intend to develop an approach for creating fix suggestions for this context.
References
[Beckert et al. 2007] Beckert, B., Hahnle, R., and Schmitt, P. H. (2007). Verification of Object-oriented Software:
The KeY Approach. Springer-Verlag.
[Cheon and Leavens 2002] Cheon, Y. and Leavens, G. (2002). A Runtime Assertion Checker for the Java Mod-
eling Language (JML). In SERP 2002, pages 322328. CSREA Press.
[Guttag et al. 1993] Guttag, J. V., Horning, J. J., Garl, W. J., Jones, K. D., Modet, A., and Wing, J. M. (1993).
Larch: Languages and Tools for Formal Specification. Spring-Verlag, 1st edition.
[Leavens et al. 2006] Leavens, G., Baker, A., and Ruby, C. (2006). Preliminary Design of JML: A Behavioral
Interface Specification Language for Java. SIGSOFT Softw. Eng. Notes, 31:138.
[Leavens et al. 2013] Leavens, G. T., Poll, E., Clifton, C., Cheon, Y., Ruby, C., Cok, D., Mller, P., Kiniry, J.,
Chalin, P., Zimmerman, D. M., and Dietl, W. (2013). JML Reference Manual.
[Meyer 1987] Meyer, B. (1987). Eiffel: programming for reusability and extendibility. SIGPLAN Not., 22:8594.
[Meyer 1997] Meyer, B. (1997). Object-Oriented Software Construction. Prentice Hall, 2nd edition.
[Milanez 2015] Milanez, A. (2015). A Case Study on Classifying Nonconformances in Java/JML Programs.
Technical report, Software Practices Laboratory, Federal University of Campina Grande.
[Milanez 2014] Milanez, A. F. (2014). Enhancing Conformance Checking for Contract-Based Programs. Mas-
ters thesis, Federal University of Campina Grande.
[Pei et al. 2014a] Pei, Y., Furia, C. A., Nordio, M., and Meyer, B. (2014a). Automatic program repair by fixing
contracts. In 17th International Conference on Fundamental Approaches to Software Engineering (FASE),
volume 8174 of Lecture Notes in Computer Science, pages 251268. Springer.
[Pei et al. 2015] Pei, Y., Furia, C. A., Nordio, M., and Meyer, B. (2015). Automated program repair in an inte-
grated development environment. In Proceedings of the 37th International Conference on Software Engineering
(ICSE 2015). IEEE.
[Pei et al. 2014b] Pei, Y., Furia, C. A., Nordio, M., Wei, Y., Meyer, B., and Zeller, A. (2014b). Automated fixing
of programs with contracts. IEEE Transactions on Software Engineering, 40(5):427449.
9 https://goo.gl/9TE8Hw
25
[Pei et al. 2011] Pei, Y., Wei, Y., Furia, C. A., Nordio, M., and Meyer, B. (2011). Code-based automated program
fixing. In 26th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 392
395. IEEE.
[Poll et al. 2002] Poll, E., Hartel, P., and Jong, E. (2002). A Java Reference Model of Transacted Memory for
Smart Cards. In CARDIS. USENIX Association.
[Rebelo et al. 2009] Rebelo, H., Lima, R., Cornelio, M. L., Leavens, G. T., Mota, A. C., and Oliveira, C. (2009).
Optimizing JML Features Compilation in ajmlc Using Aspect-Oriented Refactorings. In SBLP 09.
[Rodrigues 2009] Rodrigues, R. M. S. (2009). JML-Based Formal Development of a Java Card Application for
Managing Medical Appointments. Masters thesis, Universidade da Madeira.
[Schmitt and Tonin 2007] Schmitt, P. and Tonin, I. (2007). Verifying the Mondex Case Study. In IEEE Interna-
tional Conference on Software Engineering and Formal Methods, pages 4758. IEEE Press.
[Sommerville 2010] Sommerville, I. (2010). Software Engineering. Pearson.
[Wei et al. 2010] Wei, Y., Pei, Y., Furia, C. A., Silva, L. S., Buchholz, S., Meyer, B., and Zeller, A. (2010).
Automated fixing of programs with contracts. In International Symposium on Software Testing and Analysis.
26

Suggesting Fixes For Non-Conformances in JML Programs

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Suggesting Fixes For Non-Conformances in JML Programs

Загружено:

Авторское право:

Доступные форматы

Suggesting Fixes for Nonconformances in Java/JML

Alysson Filgueira Milanez

Technical Report SPLAB-2016-001

Suggesting Fixes for Nonconformances in Java/JML

Alysson Filgueira Milanez

Software Practices Laboratory

Technical Report SPLAB-2016-001

2 Suggestion of Corrections for Nonconformances in JML Programs

2.1 Programs Characterization

2.2 Fixes for Nonconformances

Postcondition problem at getAccount method (CentralHost class)

Evaluation problem at withDraw method (OfflineAccountProxy class)

Postcondition problem at div method (Common class)

Invariant problem at Explosion constructor

Postcondition problem at getBoundingBox method (FlakSmoke class)

Postcondition problem at getAngle method (package complex, class ComplexNumber)

Postcondition problem at getRealPart method (package complex, class ComplexNumber)

Evaluation problem at divideComplexNumber method (int complex package - ComplexNumber class)

Postcondition problem at divideComplexNumber method (int complex package - ComplexNumber class)

Evaluation problem at quickSort method (package quicksort - QuickSort class)

Postcondition problem at getAllergyDate method (package allergies - Allergies Impl class)

Postcondition problem at getAllergyDesignation method (package allergies - Allergies Impl class)

Postcondition problem at removeAllergy method (package allergies - Allergies Impl class)

Postcondition problem at setAllergyDate method (package allergies - Allergies Impl class)

Postcondition problem at setAllergyDesignation method - (package allergies - Allergies Impl class)

Postcondition problem at validateAllergyPosition method (package allergies - Allergies Impl class)

Invariant problem at Appointments Impl constructor (package appointments)

Invariant problem at CardException class (package javacard.framework)

Invariant problem at CardRuntimeException class (package javacard.framework)

Precondition problem at arrayCopy method (package commons - CardUtil class)

Invariant problem at Diagnostic Impl constructor (package diagnostics)

Invariant problem at setAppointmentID method (package diagnostics - Diagnostic Impl class)

Postcondition problem at setDescription method (package diagnostics - Diagnostic Impl class)

Invariant problem at setDiagnosticID method (package diagnostics - Diagnostic Impl class)

Invariant problem at Medicine Impl constructor (package medicines)

Invariant problem at setAppointmentID method (package medicines - Medicine Impl class)

Invariant problem at setDiagnosticID method (package medicines - Medicine Impl class)

Invariant problem at setMedicineID method (package medicines - Medicine Impl class)

Invariant problem at setTreatmentID method (package medicines - Medicine Impl class)

Invariant problem at Personal Impl constructor (package personal)

Invariant problem at Treatment Impl constructor (package treatments)

Postcondition problem at getMedicalRecommendation method (package treatments - Treatment Impl)

Invariant problem at setAppointmentID method (package treatments - Treatment Impl class)

Invariant problem at setDiagnosticID method (package treatments - Treatment Impl class)

Postcondition problem at setMedicalRecomendation method (package treatments - Treatment Impl class)

Invariant problem at setTreatmentID method (package treatments - Treatment Impl class)

Postcondition problem at getVaccinationDate method (package vaccines - Vaccines Impl class)

Postcondition problem at getVaccineDesignation method (package vaccines - Vaccines Impl class)

Postcondition problem at removeVaccine method (package vaccines - Vaccines Impl class)

Postcondition problem at setVaccineDesignation method (package vaccines - Vaccines Impl class)

Postcondition problem at validateVaccinePosition method (package vaccines - Vaccines Impl class)

Postcondition problem at getName method (package accounting.basic - Account class)

Postcondition problem at getType method (package accounting.basic - AccountingCustomer class)

Postcondition problem at arrayToString method (package util - ArrayUtils class)

Postcondition problem at getMaxIntArrayIndex method (package util - ArrayUtils class)

Postcondition problem at stringArrayToIntArray method (package util - ArrayUtils class)

Invariant problem at byteArrayDataSource method (package mail - ByteArrayDataSource class)

Invariant problem at ByteArrayDataSource constructor (package util - ByteArrayDataSource class)

Invariant problem at Charge constructor (package accounting.basic - Charge class)

Postcondition problem at getId method (package accounting.basic - Company class)

Postcondition problem at getCookie method (package util - class CookieUtils)

Postcondition problem at getDeleteCookie method (package util - class CookieUtils)

Postcondition problem at getCustomerKey method (package accounting.basic - CustomerLog class)