Open georghinkel opened 8 years ago
Thank you for the review. Indeed, not much of Sigma was used, but that is because IMHO the case was more about search-based algorithms than model transformation. The actual transformation is therefore limited to class model -> problem solver and solution -> class model.
I'm not an expert in genetic algorithms, however yesterday I did some little tuning (enabling parallelism, setting better crossover and mutation ratio) and I came up with a bit better results:
Model | CRA | Time [s] |
---|---|---|
TTC_InputRDG_A | 3 | 10 |
TTC_InputRDG_B | 4.08 | 13 |
TTC_InputRDG_C | 2.41 | 39 |
TTC_InputRDG_D | 0.87 | 91 |
TTC_InputRDG_E | -9.11 | 1416 |
TTC_InputRDG_F | -29.50 | 2540 |
TTC_InputRDG_G | -359.68 | 13140 |
(cf https://github.com/fikovnik/ttc16-cra-sigma)
Not sure if I understand your very last sentence. I mean the transformation between the class model and search-based problem is the core of the solution, so yes, it was done manually :-)
First, I find the added value of using Sigma in this solution rather small and the solution could also have been written in normal Java, even. Therefore, I think the solution is rather about MOEA than about Sigma.
The idea of encoding the CRA problem with these integer vectors is neat and the results also indicate that. Though the solution is quite slow, it produces quite good results, at least for the smaller models. I suspect that the results of the larger models could be improved by a different configuration of the search algorithms, which is currently hard-coded. However, the translation of the problem into an integer vector must be done manually.
Here is the evaluation sheet: EvaluationSheet.Sigma.xlsx