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.

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

		pb.addVar(subEntity);
		pb.addVar(superEntity);

		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.

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

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 Reader reader = ProxyDisk.getInstance().fileTempInput(name);
		final Properties properties = new Properties();
		properties.load(new ReaderInputStream(reader));
		final OccurrenceBuilder solutionBuilder =
			OccurrenceBuilder.getInstance();
		final Occurrence[] solutions =
			solutionBuilder.getCanonicalOccurrences(properties);

		System.out.print("Found ");
		System.out.print(solutions.length);
		System.out.println(" solutions.");
	}
}