Change Request #3365
The Objective/Constraint editors of the DSE perspective are using the eclass "SMTObjective/-Constraint" to construct DSML expressions. These eclasses are located in the ...exploration.smt plugin, which requires other DSE plugins to depend on this plugin if they shall be able to parse DSML expressions. This breaks the intended architecture of the exploration plugins.
Introduce two "generic" eclasses in the "org.fortiss.af3.exploration" plugin, or transform the existing ExplorationObjective/-Constraint from interfaces to instantiatable classes. Then, use these classes in the DSE editors.
Nevertheless, it is still possible to have plugin-specific specializations of the ExplorationObjectives/-Constraints, but the DSML expressions created in the perspective would be passed by the common Exploration Targets.
#7 Updated by Alexander Diewald 5 months ago
- Status changed from New to Resolved
- Assignee changed from Alexander Diewald to Johannes Eder
- % Done changed from 0 to 100
- Kernel: https://git.fortiss.org/af3/kernel/-/merge_requests/116
- AF3: https://git.fortiss.org/af3/af3/-/merge_requests/336
@Johannes: Could you please review this one? It is a prerequisite for one of the issues to be resolved for HUBCAP and is already some time "overdue". Moreover, it is needed to properly resolve #4022, otherwise we can get a lot of conflicts.
If you do not have time, please reassign to me and I will look for someone else.
For testing, please load the ACC example, test the constraint and objective creation and check that the DSE generates solutions. That should be sufficient.
For the review, please note that I removed "sub-ExplorationTargets" as they are not used and not fully implemented. Only the "implict Constraints" for Objectives are still there since they are needed by the bandwidth minimization Objective and I currently see no other clean way to generate supporting constraints for objectives.