ptidej_solver

# Ptidej Solver

At the orgin of Ptidej was Hervé Albin-Amiot's and my work on the specification of design motifs, the automated identification of their occurrences, and the automated generation of related code. The identification of occurrences of design motifs is performed using an explanation-based constraint solver, built on top of PaLM and JChoco. Using Ptidej Solver, it is possible to identify occurrences of several built-in design motifs or other recurring patterns.

## Problem Motifs Definitions

Because it uses a constraint solver, Ptidej requires each motif to be defined as a constraint satisfaction problem. A simple example of problem follows:

```public final class CompositionAndInheritanceTest {
public static Problem getProblem(final List allEntities) {
final Problem pb =
new Problem(
90,
"Composition and Strict Inheritance Test",
allEntities);

final Variable subEntity =
new Variable(pb, "SubEntity".toCharArray(), true);
final Variable superEntity =
new Variable(pb, "SuperEntity".toCharArray(), true);

final StrictInheritanceConstraint c1 =
new StrictInheritanceConstraint(
"SuperEntity -|>- SubEntity",
"throw new RuntimeException(\"SuperEntity -|>- SubEntity\");",
subEntity,
superEntity,
50,
DefaultInheritanceApproximations.getDefaultApproximations());
final ContainerCompositionConstraint c2 =
new ContainerCompositionConstraint(
"SubEntity <#>-> SuperEntity",
"throw new RuntimeException(\"SubEntity <#>-> SuperEntity\");",
subEntity,
superEntity,
100,
DefaultNoApproximations.getDefaultApproximations());

pb.post(c1);
pb.post(c2);

return pb;
}
}```

In this problem, two roles are defined: that of `SubClass` and of `SuperClass`. For classes to play the roles of `SubClass` and `SuperClass`, the `SubClass` must inherit from the `SuperClass` (even if zero, one, or more entities stands between the `SubClass` and the `SuperClass` in the inheritance tree) and the `SubClass` must be composed of instances of the `SuperClass`.

## Constraints Definitions

New constraint can be added to Ptidej to express new relation among roles or properties of classes that could play these roles. Ptidej provides three abstract classes so should be sub-classed by new constraints:

• `ptidej.solver.constraint.BinaryConstraint`: for any binary constraint, i.e., constraint between two variables. The constructor of a `BinaryConstraint` takes has arguments the default information required to instantiate a constraint:
• `String name`: the name of the constraint, any string;
• `String command`: the command associated with the constraint, currently any string;
• `Variable v0` and `Variable v1`: instances of class `ptidej.solver.Variable` that represent the two variable between which the constraint must hold;
• `int weight`: the weight of the constraint in the problem. The sum of the weights of all the constraints in a problem should equal 100;
• `IApproximations approximations`: an instance of `ptidej.solver.approximation.IApproximations`, which returns and ordered array of constraint names, to try one after the other if the previous one cannot be verified;

• `ptidej.solver.constraint.BinaryCounterConstraint`: for any binary constraint that count some properties between the two variables, for example a “distance” in terms of number of relationships that must be followed to reach `v1` from `v0`;

• `ptidej.solver.constraint.UnaryConstraint`: for any unary constraint, i.e., constraint on a single variable to verify a property of an entity, for example if an entity is an interface vs. a class.

`BinaryConstraint` has two sub-classes to specialise for inheritance and binary-class relationships.

• `ptidej.solver.constraint.AbstractInheritanceConstraint`
• `ptidej.solver.constraint.AbstractRelationshipConstraint`

`BinaryConstraint` and `BinaryCounterConstraint` may also be further specified using the methods:

• `setSymbol(String)`: the symbol to print in the result file, any string;
• `setStrict(boolean)`: whether the constraint allows a same entity to play both role (false) or not (true);
• `setFieldName(String)`: the name of the field supporting the property between entities that are candidate to play the two roles. Fields include the following, whose names are somewhat self-explanatory:
• `aggregatedEntities`
• `allReachableAggregatedEntities`
• `allReachableAssociatedEntities`
• `allReachableComposedEntities`
• `allReachableContainerAggregatedEntities`
• `allReachableContainerComposedEntities`
• `allReachableCreatedEntities`
• `allReachableKnownEntities`
• `allReachableSuperEntities`
• `allReachableUnknownEntities`
• `associatedEntities`
• `composedEntities`
• `containerAggregatedEntities`
• `containerComposedEntities`
• `createdEntities`
• `knownEntities`
• `methodNames`
• `superEntities`
• `unknownEntities`

## Occurrences Identification

Typically, a call to the constraint solver is made like:

```public class DesignMotifIdentificationCallerSimple {
public static void main(final String[] args) throws FileNotFoundException,
IOException {

final String path = "../Ptidej Solver Tests/rsc/JHotDraw v5.2.jar";
final String name = "JHotDraw v5.2.ini";

final IIdiomLevelModel idiomLevelModel =
ModelGenerator.generateModelFromJAR(path);
final IWalker constraintModelBuilder = new Generator();
final List listOfModelEntities =
Manager.build(idiomLevelModel, constraintModelBuilder);
final Problem constraintProblem =
CompositeMotif.getProblem(listOfModelEntities);

final Writer writer = ProxyDisk.getInstance().fileTempOutput(name);
constraintProblem.setWriter(new PrintWriter(writer));
constraintProblem.automaticSolve(true);

final Properties properties = new Properties();