Hi. I have some questions for the developers of the "core" component. I'm not sure who wrote them. Was it Remi, Céline, or someone else?
Anway, the core component contains several utilities that are intended to be reusable by both tooling and codegen, but currently codegen doesn't use them because when we were developing, the core utilities were not yet available at the time.
I'm now assessing the changes required in codegen to reuse the core utilities.
Right now it looks like there is an overlap between the *Utils classes in oeprt.umlrt.core.utils and the UMLRealTimeProfile and to some extent the UMLRealTimeStateMachProfile classes in oeprt.codegen.util.
I think some of these could be unified, but I don't understand some of the rationale behind the implementation of some utilites in core. For example, take the CapsulePartUtils class. It has a method
public static boolean isCapsulePart(final Property property) {
return ElementTypeUtils.matches(property, IUMLRTElementTypes.CAPSULE_PART_ID);
}
and in UMLRealTimeProfile we have
public static boolean isCapsulePart(Element el) {
Stereotype s = el.getApplicableStereotype(UML_REAL_TIME_CAPSULE_PART);
return s != null && el.isStereotypeApplied(s);
}
The first question is why the core method has a more narrow parameter type? Is it expected that the caller ensures that it is invoked only on Property elements?
The second question is why does it use ElementTypeUtils.matches? What are the advantages of using that method instead of a standard UML stereotype lookup? Looking at its implementation, it uses classes from GMF. Is this dependency strictly necessary? My concern here is that the code generator should also run in stand-alone mode, and I don't want to bring GMF as an additional dependency there.
Thanks
--
Ernesto Posse
Zeligsoft
