Hi, Ernesto,
See some replies in-line, below.
On 10 June, 2016 at 12:35:19, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote: Hi Christian,
Sorry, I still don't see the value very well. If you need to check that an element is an RTPort, doesn't it suffice to check that it is an instance of Port and has the RTPort stereotype? And if what you need to do is to check that it is a wired port, isn't it enough to check that it is an RTPort that has isWired set to true? Or is the idea that you have an EObject but somehow it doesn't have an EClass that you can use to check, or that it may have a different EClass but still conforms to the various criteria you are looking for?
Yes, checking whether a port is an RTPort might not involve much more than checking that it has the stereotype applied. Checking that it’s an SPP (which is a type specializing RTPort) is also not very complex. Perhaps there’s an “available port of a core run-time service protocol” type that is much more specific still, I don't know. And there are also the hinted types for different visualizations of ports, including “port on part” as distinct from “port” or maybe “port as property shape” vs “port as port shape”. And maybe over time, the matching rules change for new requirements, but maybe that’s not a problem for Papyrus-RT. All of which is just to say that the element-types offer more flexible classification than does EClass. And which flexibility may or may not be important to Papyrus-RT. This is just one of the reasons why GMF-based applications tend to use element-types in this way. EObjects still have to have EClasses in order to work in the EMF run-time, in any case. None of this is intended for such plastic EObjects: an element type is ultimately based on an EClass.
I understand the idea of a general "matcher" to abstract all kinds of checks for different criteria, but for example, why use this matcher instead of say, Hamcrest's Matcher [1] (which by the way is in Orbit)?
GMF is older than Orbit, and Hamcrest is only in Orbit because JUnit 4 requires it, I think. I wouldn't use Hamcrest in production code; only in tests — the implementation of generics in Hamcrest matchers is broken (they don’t make correct use of type parameter constraints) — but that’s not relevant because it’s just not used by GMF anyways.
The ElementTypeUtil.matches uses a String id for the type of the element to obtain the actual type from an ElementTypeRegistry (from GMF). Who adds types to that registry? Is it Papyrus or the Papyrus-RT Tooling?
Papyrus registers the base types for the UML metamodel. Papyrus-RT Core adds specializations of those base types for the UML-RT profiles. Papyrus-RT Tooling adds further specializations for different visualizations of elements in the diagrams and so-called “creation types” that are only used for instantiation and configuration of new model elements, not for matching existing elements.
The stand-alone generator runs as a simple Java app, so no headless Eclipse, and therefore no extensions. I would be very interested in seeing how to use extensions without an Eclipse runtime, since that also limits the availability of user-defined generators in stand-alone. Do you have any links to point me to the use of extensions in pure Java apps?
Have a look for usages of the EcorePlugin.ExtensionProcessor class. For example, in the UML2 project’s JUnit tests (IIRC).
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.
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
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
|
