[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [jwt-dev] JWT meta model changes
|
Hi Chris,
thanks for the update. Just some minor comments:
- 3) XORNode: Create as abstract class (similar to ANDNode);
The only thing that only now comes to my mind is: if it is an abstract class
what use does it have for us? The idea at the beginning was to have a class
with its own view (especially: editpolicy and figure) which can have several
incoming *and* outgoing edges in difference to DecisionNode and MergeNode.
However, if it is an abstract class, it won't be usable in such a way, so we
maybe should discuss this further and either decide to neglect this
requirement and don't integrate these classes at all or make them concrete
classes.
On the other side, if it is a concrete class then the views must specify
whether to show only the more general class or only the two more specific
ones and we need some logic when switching the view:
a) from specific to general: simply use the figure of the more general class
and keep the specific class in the background
b) from general to specific: if a specific class is hold in the background:
no problem, otherwise evaluate the node whether it has only one incoming or
only one outgoing edge and make it a DecisionNode (MergeNode respectively);
If no such case (changing view from more general class to more specific and
the node has several incoming and outgoing edges), then an error message
comes up.
- 9) Remove also package PrimitiveTypes
Best regards,
Florian
-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Christian Saad
Gesendet: Montag, 3. Mai 2010 10:56
An: Java Workflow Tooling
Betreff: Re: [jwt-dev] JWT meta model changes
Hi Marc,
thanks for the update. Seems we won't be changing too much (makes life
easier) :)
* InformationType is still required by Mastek
* Input/OutputParameter by OpenWide
I've updated the table accordingly.
Regards,
Chris
Am 30.04.2010 20:04, schrieb Marc Dutoo:
> Hi Chris, Florian, all
>
> I know that we know have our "magical" converter to handle metamodel
> evolution :) But still, don't remove features that can be useful.
>
> Please add a column that says for each evolution how the converter
> transformation will handle it if not obvious, or whether it won't be
> supported.
>
>
> So I agree with Florian, and further :
>
> 1. remove information type OK
>
> 2. merge input and output parameters NO we are using it today to deduce
> the signature of service calls ! Or another idea about that ?
> I agree we could add (web)service specific attributes or aspects to
> define the signature, but it would be a duplicate of the parameters
> attribute anyway.
> Further, being able to deduce the service signature from the standard
> model is a pretty powerful feature I think.
>
> 3. remove functions OK
>
> 4. and 5. as Florian says (add new ones, but keep the old ones)
>
> 6. move to executable node OK
>
> 7. and 9. java application OK
>
> 8. remove application type OK
>
> 10. webservice application OK cosmetics, supported evolution
>
> 11. remove primitive types OK
>
> Regards,
> Marc
>
> Christian Saad a écrit :
>> Hi Florian,
>>
>> thanks for your input, I've updated the list accordingly. It seems I
>> misunderstood the requirements for AND/XORNode, so I added them as
>> additional abstract nodes.
>>
>> I also added the primitive types for removal since I couldn't find any
>> concrete reference to them in the meta model anyway and sent a message
>> to Ravi as Mastek asking about the informationType.
>>
>> Unfortunately the GSoC currently doesn't look so good but maybe we can
>> provide another funding here (like PvS-SoC ;) ).
>>
>> Regards,
>> Chris
>>
>> Am 23.04.2010 18:24, schrieb Florian Lautenbacher:
>>> Hi Chris,
>>>
>>> thanks for the detailed list. I have some objections of unifying the
>>> DecisionNode/MergeNode and ForkNode/JoinNode while removing those
>>> nodes at
>>> the same time (I'm not sure whether this was the intended meaning of
>>> unification); as those nodes are typical for UML and are heavily used
>>> in all
>>> of our models as well as have different EditPartPolicies I would like
>>> to see
>>> those elements stay but rather get more abstract nodes
>>> *additionally*. What
>>> do others think about it?
>>>
>>> Concerning the attribute informationType I'm unsure whether our Indian
>>> colleagues are using it and if yes, for which purpose. I think I've once
>>> seen a model which made use of them.
>>>
>>> I'm not sure who currently uses the primitive types, so I would agree to
>>> remove those, too.
>>>
>>> Concerning the swimlanes: is there already a decision whether the GSoC
>>> student can assist us here?
>>>
>>> Best regards,
>>>
>>> Florian
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
>>> Auftrag von Christian Saad
>>> Gesendet: Freitag, 23. April 2010 17:29
>>> An: Java Workflow Toolbox
>>> Betreff: [jwt-dev] JWT meta model changes
>>>
>>> Hi guys,
>>>
>>> the long overdue list of proposed metamodel changes. This is supposed to
>>> become the detailled list of changes which will then be applied to the
>>> meta model once everybody gives their +1
>>>
>>> Regards,
>>> Chris
>>>
>>>
>>> _______________________________________________
>>> jwt-dev mailing list
>>> jwt-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/jwt-dev
>>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> jwt-dev mailing list
>> jwt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jwt-dev
>
> _______________________________________________
> jwt-dev mailing list
> jwt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jwt-dev
>
