JanWittler
commented
2 years ago Before starting a refactoring, it might be a good opportunity to define a reference implementation for such utility methods. The linked approaches realize all the find part of the find-or-create pattern, but with two different concepts: PCM-Java and PCM-UML use inter-domain logic for the matching (i.e. information from both domains is taken) while the UML query util uses intra-domain logic (i.e. information only from UML).
Inter-domain logic allows for more precise customization and is bidirectional but needs to be setup again for every domain pair thus is poor in scaling and scatters matching logic.
Intra-domain logic centralizes the matching logic and scales better but is unidirectional. Thus, when setting up a domain pair, the consistency between the two unidirectional intra-domain matching logics needs to be verified.
A third option which could combine benefits of both approaches would be to define identifying attributes for each element type. Without knowing too much about the Commonalities language, I would guess that this approach follows a similar direction.
From my perspective, the centralization of the matching logic is the most important aspect which is why I would go with the intra-domain matching logic, like it is already done in the UML query util. I would suggest to place these utility methods directly in the domain packages (of the Vitruv-Domains repository) as they are only depending on the domain and any application of the domain should use and therefore easily discover these utilities.
The proposed solution would require to split the isPackageFor method into distinct methods for Java, UML, and PCM that each take a namespace list instead of an element from another domain. Additionally, the getCorrespondingPackageName method would be moved to the PCM domain util and findUml... methods should be moved from the temporary package.
In #175, we have adapted the transformations to ignore the capitalization of package names. We have centralized the functionality for mapping between PCM elements and UML/Java packages two utilities of the according transformations (PCM-UML and PCM-Java). However, there is at least one further place at which functionality for ignoring the capitalization is repeated (as discussed in the according PR), which is a query util for the UML domain (see here).
We should centralize the functionality for matching package names ignoring the capitalization in the Java/UML domains and refer to these domain-specific implementations within the transformations, in particular in the above mentioned utils. This should be fixed together with #169, as it affects the same method implementations.