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