Re: [papyrus-rt-dev] Reusing the core component

[Christian Damus <give.a.damus@xxxxxxxxx>]

Hi, Ernesto,

I can provide some background about the usage of element-types, but that’s about it.

The element-types are more generalized than UML metaclass and stereotype extension information.  Their matchers can also inspect an element’s properties, related elements, and whatever else to determine whether the element conforms to the abstract “type” that the element-type represents.  For example, the various specializations of the RTPort element-type match on values of the ‘isService’, ‘isWired’, and other attributes.  So, relying on the types for queries like these utilities ensures a degree of future-proofness on potential evolution of these conformance conditions.

As far as run-time dependencies are concerned, the element-types are in a layer of GMF that doesn’t require the UI (and certainly not diagrams), but all of the registries are loaded from extension points (even the modelled element-type configurations), so it would take a bit of effort to make it work in an Eclipse-free context.  Does the code generator run in an (headless) Eclipse instance?  Or as simply as a Java app?  EMF has demonstrated that it is possible to process simple plugin.xml extensions without the Eclipse run-time, but I don't know that there aren’t more dependencies in GMF on the platform that would make it more difficult.

HTH,

Christian

On 10 June, 2016 at 11:08:23, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

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

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev