| Re: [henshin-dev] Multiplicity Contraint for Edges |
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
Attachment:
signature.asc
Description: OpenPGP digital signature