-
Notifications
You must be signed in to change notification settings - Fork 0
How to expand the algorithm to handle other model types
The algorithm should be able to handle all model types. In order for this to work, some implementation is needed.
Create a new appropriately named package for the new model file.
There are some interfaces and abstract classes that must be implemented to provide the algorithm with the necessary information about the model and the means to alter it.
The ActionExtractor is responsible for providing the algorithm with actions that can alter the model. To narrow the search space for the algorithm, a list of errors are provided to the ActionExtractor. It should only return actions that have a chance of solving those errors.
The ErrorExtractor is responsible for providing the algorithm with all the errors that exist in the model.
The Model interface wraps the Model-specific implementation.
The ModelProcessor process the model, and initialize the Q-table for errors in the model. It is also responsible for implementing the application of actions to the model. This can be quite tricky to implement, and we recommend looking at EcoreModelProcessor for inspiration.
The required functionality for the algorithm is implemented in the abstract class Solution. However, it can be interesting to see the distance between the original model and the proposed solution. Therefore, an implementation of a sub-class is necasary. If you don't want this functionality, just return a number for the method calculateDistanceFromOriginal.
QModelFixer is an abstract class implementing ModelFixer. This implementation uses Q-learning, but can be replaced with other algorithms.
The subclass of QModelFixer needs two constructor that instantiates many of the interfaces described above, telling the algorithm what implementations to use. One default constructor without parameters, and one that takes in a List of Integers for the preferences. This parameter should be passed to the super-constructor.
The protected variable Set<Integer> unsupportedErrorCodes needs an implementation. If there is some errors that the algorithm is unable to handle, their code can be added to this set in the constructor.
The protected variables ActionExtractor actionExtractor, ErrorExtractor errorExtractor and ModelProcessor modelProcessor needs to be given an implementation specific to the model type you are trying to handle.
initializeModelFromFile should get the File-reference originalModel in the superclass, and return an implementation of the Model-interface wrapping the model in that file. getModel should do the same, but here the file is passed as a parameter.
updateRewardCalculator is called when the reward calculator updates. This requires a new ModelProcessor, so just return a new instantiation of the interface.
initializeSolution returns a new instantiation of the Solution-interface.