Integrated crossover implementation splitting and recombining EMF models based on category theory (MDOver)

[Leative]

The crossover implementation (ProblemPartCrossover) is provided as a Maven artifact and can be found at github.

Most important changes:

• Added Maven dependency to the crossover artifact.
• Extended mopt DSL to allow specification of a ProblemPartSpecifier: the crossover needs information about which parts of the meta model are invariant during optimization. To that end, a use case needs to provide an implementation of the interface IProblemPartSpecifier. In the mopt file the specification is provided in the problem section of the DSL:
  define problem part using <crossoverdefinition.problempart.CraProblemPartSpecifier>
  An example of the implementation for the CRA case would look like this:

public class CraProblemPartSpecifier implements IProblemPartSpecifier {
	@Override
	public Set<EObject> getProblemPart(EPackage metamodel) {
		HashSet<EObject> problemPartTypes = new HashSet<>();
		problemPartTypes.add(ArchitectureCRAPackage.Literals.CLASS_MODEL__FEATURES);
		problemPartTypes.add(ArchitectureCRAPackage.Literals.METHOD__DATA_DEPENDENCY);
		problemPartTypes.add(ArchitectureCRAPackage.Literals.METHOD__FUNCTIONAL_DEPENDENCY);
		return problemPartTypes;
	}
}

• To use the ProblemPartCrossover during optimization crossover.strategy: problempart can be defined in the solver section of the DSL.
• As the crossover can be disruptive, a possibility to perform a repair step after evolutions has been added. It has been integrated into the workflow of MDEO as a CompoundVariation called MoeaRepairingOptimisationVariation which encapsulates all variations. By default a NOOP repair strategy is used which does nothing.
• A SequentialRepairStrategy can be used by specifying rep.strategy: sequential in the solver section of the DSL. This strategy will apply user defined Henshin rules after each evolution step. Note that the user defined rules will be applied in the order of their specification in the mopt file and that each rule will be applied as often as possible before the next rule will be tried.
• To specify repair rules, a new EvolverType has been added to the DSL. An example for a user specified repair rule is:
  repair using <cra-repair.henshin> unit "removeMultiAssignment"

A full example mopt for the CRA case using ProblemPartCrossover with repair would look like this:

problem {
	basepath <models/>
	metamodel <architectureCRA.ArchitectureCRAPackage>
	model <TTC_InputRDG_A.xmi>
	define problem part using <crossoverdefinition.problempart.CraProblemPartSpecifier>
}
goal {
	objective Cohesion maximise java { "guidancefunctions.Cohesion" }
	objective Coupling minimise java { "guidancefunctions.Coupling" }
	constraint MinimiseClasslessFeatures java { "guidancefunctions.MinimiseClasslessFeatures" }
	constraint MinimiseMultiAssignedFeatures java { "guidancefunctions.MinimiseMultiAssignedFeatures" }
}
search { 
	mutate using <cra-mutation.henshin> unit "addUnassignedFeatureToNewClass"
	mutate using <cra-mutation.henshin> unit "addUnassignedFeatureToExClass"
	mutate using <cra-mutation.henshin> unit "moveFeatureToExClass"
	mutate using <cra-mutation.henshin> unit "deleteEmptyClass"
	repair using <cra-repair.henshin> unit "removeMultiAssignment"
}
solver {
	optimisation provider moea algorithm NSGAII {
		population: 100
		variation: probabilistic (0.1, 0.8)
		mutation.step: 1
		mutation.strategy: random
		crossover.strategy: problempart
		rep.strategy: sequential
	}
	termination {
		 delta: 3
		 iterations: 100
	}
	batches 1
}