Model Quality: Refactor to avoid assumptions/knowledge about AF3 in the kernel
- Factorize: ModelQualityStorageManager by distributing the variables:
- Exclude the constants to the corresponding packages. The suggested resolution is to distribute the information to other classes.
- how can I get the information for the directory and path into the quality service, if i can not use the org.fortiss.af3.project.utils.FileUtils due to dependency cycles at import?
- Factorize "MetricKey"
- Get rid of constants in this class
- Rather, the data should be provided to the ModelQualityService during the registration of the metrics.
- ModelQualityService and IModelQualityProviders: Avoid assumptions on the overall structure of the model, its implementation, and the traversal order. Ideas:
- IModelMetricProviders define a precedence on project root elements when they are registered, ModelQualityService sorts the list of root elements according to this. In this approach, we still assume that there is an order in which IModelQualityProviders can be applied such that the subsequent IModelQualityProviders will find the expected MetricTreeNodes
- Use an "on-demand" creation of MetricTreeNode: Instead of directly exposing the TreeNodeLookupTable in MetricTreeNode (and using its put() and get() methods), provide a MetricTreeNode.getOrCreate() method. And possibly also MetricTreeNode.get() for read-only scenarios, where it is an error that a node does not exist.
Edited by Simon Barner