| Re: [henshin-dev] Multiplicity Contraint for Edges |
Thanks a lot for your effort! Am 22.07.2012 21:11, schrieb Andreas Drobisch: > Hi, > I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=385639 for > this, including an image attachment of an unmatched rule (not sure if > uploading the henshin file would be helpful here). > > Cheers, > Andreas > > On 22.07.2012 19:56, Stefan Jurack wrote: >> Hi all, >> >> I never heard of that behavior and it appears very strange to me. Why >> should EMF treat inherited features differently than owned features?! >> I have to check that...which may take some time due to other >> liabilities. >> >> Regards, >> Stefan >> >> Am 20.07.2012 13:58, schrieb Andreas Drobisch: >>> Hi Christian, >>> that did the trick, thank you very much! >>> >>> On thing I noticed in the check method of >>> ...matching.constraints.ReferenceConstraint: >>> >>> (EObject) source.value.eGet(reference); >>> >>> will return a proxy object for subclass instances of the target type, >>> (e.g. when the reference is defined on the superclass). The constraint >>> check will be negative because of the List.contains call that follows. >>> I hacked around this: >>> >>> ... >>> // HENSHIN CODE >>> EObject obj = (EObject) source.value.eGet(reference); >>> if (obj==null) { >>> return false; >>> } >>> ////////////////////////HACK: resolve proxy >>> if (obj.eIsProxy()) { >>> try { // try to resolve proxy in target resource >>> InternalEObject toResolve = (InternalEObject) obj; >>> URI proxyURI = toResolve.eProxyURI(); >>> EObject resolved = target.value.eResource(). >>> getEObject(proxyURI.fragment().toString()); >>> obj = resolved != null ? resolved : obj; >>> } catch (Exception e) { >>> // could not resolve >>> } >>> } >>> >>> ... >>> >>> Is there a tracker for Henshin, to discuss this kind of issues? >>> >>> Cheers, >>> Andreas >>> >>> On 19.07.2012 14:51, Christian Krause wrote: >>>> Hi Andreas, >>>> >>>> take a look at the attached screenshot. This rule matches an >>>> ExclusiveGateway that has exactly one incoming SequenceFlow. Note that >>>> the two forbid actions have different indizes (1 and 2). This is >>>> necessary to distinguish between two forbid patterns which should be >>>> checked individually. If you omit these indices, the match finder will >>>> try to find a match for all forbid-elements in the rule together. >>>> >>>> If you use indizes, then it is basically like an AND: there should >>>> be no >>>> extra SequenceFlow AND there should be no NodeType with the same id. >>>> >>>> If you omit the indizes it is basically like an OR: there should be >>>> either no SequenceFlow OR no NodeType with the same id. >>>> >>>> In your case, you want an AND I think. >>>> >>>> Hope that helps. >>>> >>>> Cheers, >>>> Christian >>>> >>>> >>>> On 07/19/2012 12:29 PM, Andreas Drobisch wrote: >>>>> I want to match the gateways which have only one "incoming" >>>>> SequenceFlow reference. I did an intermediate step and wanted to >>>>> forbid the match of exclusive gateways with a incoming sequence flow, >>>>> but thats not working (see attached image), the node will always be >>>>> created. >>>>> >>>>> I am I missing something here? My other "forbid" works as expected. >>>>> >>>>> On Wed 18 Jul 2012 03:43:08 PM CEST, Christian Krause wrote: >>>>>> Hi Andreas, >>>>>> >>>>>> On 07/18/2012 03:21 PM, wp1101223-androbit wrote: >>>>>>> >>>>>>> Hi Henshin Devs, >>>>>>> >>>>>>> first of all: Henshin is great :) . Currently I am trying to use it >>>>>>> to transform BPMN models to a graph exchange format. >>>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>>> I have managed the basic parts and now I am little bit stuck on >>>>>>> checking the multiplicity of edges. Is it possible to have an >>>>>>> contraint on the number of matching edges / nodes (see attached >>>>>>> image)? >>>>>>> >>>>>> >>>>>> I am not 100% sure whether this is what you want to do, but if you >>>>>> want to make sure that there exists only one SequenceFlow object >>>>>> with >>>>>> a reference to the ExclusiveGate node, you can change the >>>>>> SequenceFlow >>>>>> action to <<preserve>> (for the reference as well), and then add a >>>>>> second SequenceFlow node and reference with the action <<forbid>>. >>>>>> >>>>>> You can find a similar example here: >>>>>> http://wiki.eclipse.org/Henshin_Trace_Model -- the difference is >>>>>> though that in this case Trace objects are created only if they >>>>>> do not >>>>>> exist yet. In your case you want to forbid the application if >>>>>> there is >>>>>> at least one such object already. >>>>>> >>>>>> I hope this helps. Let us know if this is not what you are trying to >>>>>> achieve. >>>>>> >>>>>> Cheers, >>>>>> Christian >>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> henshin-dev mailing list >>>>>>> henshin-dev@xxxxxxxxxxx >>>>>>> https://dev.eclipse.org/mailman/listinfo/henshin-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> henshin-dev mailing list >>>>>> henshin-dev@xxxxxxxxxxx >>>>>> https://dev.eclipse.org/mailman/listinfo/henshin-dev >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> henshin-dev mailing list >>>>> henshin-dev@xxxxxxxxxxx >>>>> https://dev.eclipse.org/mailman/listinfo/henshin-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> henshin-dev mailing list >>>> henshin-dev@xxxxxxxxxxx >>>> https://dev.eclipse.org/mailman/listinfo/henshin-dev >>>> >>> _______________________________________________ >>> henshin-dev mailing list >>> henshin-dev@xxxxxxxxxxx >>> https://dev.eclipse.org/mailman/listinfo/henshin-dev >> >> >> >> >> >> _______________________________________________ >> henshin-dev mailing list >> henshin-dev@xxxxxxxxxxx >> https://dev.eclipse.org/mailman/listinfo/henshin-dev >> > _______________________________________________ > henshin-dev mailing list > henshin-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/henshin-dev
Attachment:
signature.asc
Description: OpenPGP digital signature