Community
Participate
Working Groups
I found I found a problem using listeners on ResourceSet : in the general case, we receive Notification for all changes, excepted when the modified property is a derived property. Moreover, it is not possible to find the 'super' properties to listen when we want listen a derived property, that's why I think that it should be interesting to receive Notification for derived properties.
The current behavior was a design choice from the very early beginnings of UML2. While notifications are generally fired for modifiable derived features (e.g., Class::superclass), the values of read-only derived features (such as derived unions) are computed on demand and don't fire notifications (since technically, they can't be "changed"). Note that, since all features which contribute values to a derived feature are generally on the same object, adding notifications for them would simply result in multiple (extraneous) notifications for the same object; it's questionable what value that would bring. Information about the properties from which most derived properties are computed is included in the EMF metadata for UML, in the form of 'subsets' and 'supersets' annotations. Proper support of notifications for derived properties should perhaps be based on a mechanism similar to the one described in bug 73143. Unfortunately, it seems unlikely that such an enhancement will be pursued in EMF any time soon...
In the absence of a general mechanism in EMF, I suppose a specific utility could be introduced in UML2 (and even be generated by the UML2 code generator). The basic idea would be a "DerivedFeatureAdapter" which would contain logic based on the properties from which the various derived properties in UML2 (or any model generated with the UML2 code generator) are computed. This adapter would listen to all changes on an object and call a callback, per derived feature, for each change in a relevant feature. The signature for the callback would be something like notifyChanged(EObject, EStructuralFeature, Notification). When you say "using listeners on ResourceSet", I assume you mean a content adapter on the resource set? If so, I suppose it would make sense for this proposed adapter to be a content adapter (i.e., one which automatically attaches itself to all objects in a content hierarchy)?
(In reply to comment #2) > > When you say "using listeners on ResourceSet", I assume you mean a content > adapter on the resource set? If so, I suppose it would make sense for this > proposed adapter to be a content adapter (i.e., one which automatically > attaches itself to all objects in a content hierarchy)? UML already has such an adapter: the CacheAdapter. However, it now has the option of being scoped per thread, which probably doesn't make sense for this new adapter. In a way, I think it does make sense for this to be a UML2-specific adapter, as it is UML2 that provides the metadata indicating from which features a feature is derived in the specific cases of subsetting and supersetting.
The UML2 code generator has been enhanced to generate a "DerivedUnionAdapter" utility class which can be used to obtain notifications when a feature that affects the value of a derived union has changed. Such an adapter (UMLDerivedUnionAdapter) has been generated for UML and can be found in the org.eclipse.uml2.uml.util package. The changes have been committed and pushed to the 'master' branch in git.
The changes are now available in an integration build for UML2 4.1.0.
(In reply to comment #5) > The changes are now available in an integration build for UML2 4.1.0. Hi Kenn, I tested your last version (M5) with my first usecase : listen notification on ENCAPSULATED_CLASSIFIER__OWNED_PORT, but it didn't work... I saw that you don't notify it when ownedAttribute changes. think you forgot to notify it, no? Concerning your question of the 2nd post, at the beginning I used TriggerListener on ResourceSet to chain command. In my current case, I use your UMLDerivedUnionAdapter to listen the notifications on the eobject. Best regards, /Vincent Lorenzo
(In reply to comment #6) > Hi Kenn, I tested your last version (M5) with my first usecase : listen > notification on ENCAPSULATED_CLASSIFIER__OWNED_PORT, but it didn't work... Aha, that is because EcapsulatedClassifier::ownedPort is not a derived union - it is a modifiable derived feature and so I would expect a "normal" notification to be sent for it. If this is not the case, then I would need to look into the list implementation that is being used... > I saw that you don't notify it when ownedAttribute changes. think you forgot > to notify it, no? No, it wasn't forgotten because this isn't a derived union...
(In reply to comment #7) > Aha, that is because EcapsulatedClassifier::ownedPort is not a derived union > - it is a modifiable derived feature and so I would expect a "normal" > notification to be sent for it. If this is not the case, then I would need > to look into the list implementation that is being used... So EncapsulatedClassifier::ownedPort is a derived subset of StructuredClassifier::ownedAttribute. I debugged this a bit and confirmed that, when elements are added via the ownedPort feature, notifications are fired for both ownedPort and ownedAttribute. However, when the ownedAttribute feature is modified independently of the ownedPort feature, a notification is only fired for the ownedAttribute feature. I don't see an easy way to add the "missing" notifications for features like this, nor do I think it would be worth the effort since there are only a small handful of features in UML2 that are like this: Class::superClass -> Classifier::generalization Classifier::general -> Classifier::generalization EncapsulatedClassifier::ownedPort -> StructuredClassifier::ownedAttribute Package::nestedPackage -> Package::packagedElement Package::ownedStereotype -> Package::packagedElement Package::ownedType -> Package::packagedElement I would seem that, for features like this, it should be sufficient to listen (only) to the superset features.
Thank you for your answer. To my mind, the goal of this bug was to avoid to have to listen the superset. Moreover, I believe that it is not possible to find the initial feature to listen from a derived feature.
(In reply to comment #9) > Thank you for your answer. To my mind, the goal of this > bug was to avoid to have to listen the superset. Moreover, I believe that it > is not possible to find the initial feature to listen from a derived feature. OK. In that case, it would have helped to get feedback/clarification sooner. :( What if I created, by hand, a new "UMLDerivedFeatureAdapter" which subclassed the generated "UMLDerivedUnionAdapter" and which simulated notifications for the remaining/missing features?
(In reply to comment #10) > (In reply to comment #9) > What if I created, by hand, a new "UMLDerivedFeatureAdapter" which subclassed > the generated "UMLDerivedUnionAdapter" and which simulated notifications for the > remaining/missing features? Actually, it would probably only be feasible to introduce a new (generated) "UMLDerivedSubsetAdapter" to cover derived features for which subsets constraints exist in the metadata. Implementing a general adapter for all derived features would be a rather significant undertaking, given the number of derived features in UML and the non-trial way in which many of them are derived...
(In reply to comment #10) > (In reply to comment #9) > > Thank you for your answer. To my mind, the goal of this > > bug was to avoid to have to listen the superset. Moreover, I believe that it > > is not possible to find the initial feature to listen from a derived feature. > > OK. In that case, it would have helped to get feedback/clarification sooner. > :( > > What if I created, by hand, a new "UMLDerivedFeatureAdapter" which > subclassed the generated "UMLDerivedUnionAdapter" and which simulated > notifications for the remaining/missing features? That's OK for us. Thank you.
(In reply to comment #12) > > What if I created, by hand, a new "UMLDerivedFeatureAdapter" which > > subclassed the generated "UMLDerivedUnionAdapter" and which simulated > > notifications for the remaining/missing features? > > That's OK for us. Thank you. To clarify, as per comment #11, the new adapter will only be able to simulate notifications for derived subset features (as opposed to all derived features). Hopefully that will suffice.
(In reply to comment #13) > To clarify, as per comment #11, the new adapter will only be able to simulate > notifications for derived subset features (as opposed to all derived features). > Hopefully that will suffice. Well, crap. There are no derived subset features (which are not also unions) in UML! :( So, we're back to square one when it comes to notifications for derived features which are not unions. Here is a complete list: Action::context ActivityNode::activity Activity::group Activity::node ActivityGroup::inActivity Association::endType Behavior::context Class::extension Class::superClass Classifier::general Classifier::inheritedMember Component::provided Component::required ConnectableElement::end Connector::kind ConnectorEnd::definingEnd DeploymentTarget::deployedElement EncapsulatedClassifier::ownedPort Extension::isRequired Extension::metaclass Message::messageKind MultiplicityElement::lower MultiplicityElement::upper Namespace::importedMember NamedElement::qualifiedName OpaqueExpression::result Operation::isOrdered Operation::isUnique Operation::lower Operation::type Operation::upper Package::nestedPackage Package::nestingPackage Package::ownedStereotype Package::ownedType Parameter::default Port::provided Port::required Property::default Property::isComposite Property::opposite ProtocolTransition::referred RedefinableTemplateSignature::inheritedParameter State::isComposite State::isOrthogonal State::isSimple State::isSubmachineState Stereotype::profile StructuredClassifier::part Type::package Vertex::incoming Vertex::outgoing Unfortunately, I don't see a feasible way to simulate notifications for most of these features because of the complex ways in which they are derived (e.g., many of the values are based on the properties of one or more other objects). For the features mentioned in comment #8, my recommendation is to listen for notifications on their "superset" features. For others, I recommend either not relying on notifications for changes to them at all or establishing application-specific mechanisms for detecting changes that affect the values of the specific feature(s) that matter most to the application.
There is a good chance we are going to work on this in the near future, to improve the situation. See https://www.eclipsecon.org/europe2013/xcore-meets-incquery-how-new-generation-dsls-are-made for the technical details.
