Re: [stp-dev] Re: About BPMN metamodel

["Hugues Malphettes" <hmalphettes@xxxxxxxxxxx>]

Hi Juan,

On 7/27/07, JUAN JOSE CADAVID GOMEZ <jcadav10@xxxxxxxxxxxx> wrote:
Clip...
> However, it is a matter of concern that the behavior of a modeling element is determined by the value of an attribute. In the BPMN specification, the Task element does exist by itself; however, the Service element doesn't, and same issue occurs: "A Task is a BPMN Service when its TaskType is Service". So there it is again, an attribute determining what should be rather defined with specialization.

I agree that it is a matter of concern.

Nevertheless BPMN is first and foremost a visual notation. So when 2
shapes are visually identical, they are roughly behaving in the same
manner to the naive user. As BPMN has already tens of shapes I think
the spec made a good choice by using attributes to differentiate those
things rather than defining even more shapes.


> Our BPMN modeler goes even further, by declaring that "An Activity is a BPMN Task when its ActivityType is Task". In this way, for Service it would be like "An Activity is BPMN Service when its ActivityType is Task, and when it is annotated under the key 'TaskType' with the value 'Service'". If you ask me, this doesn't sound way too natural for me.

If you look at it this way it is indeed not natural. We applied one
criteria very strictly to define what belongs to the core model:
does the attribute has a direct visual interpretation on the diagram?
Every time it was not the case we chose not to place it in the core
object model.

Now, in terms of code the fact that it is an attribute or an
annotation remains a technical detail: ECoreUtil.getAnnotation /
ECoreUtil.setAnnotation will do everything almost as simply as a
getter setter.

This also brings us the great benefit of not having to worry about
BPMN-2.0 too much: the spec is still a moving target and properties
might change there quite a bit. But as we don't reflect that in the
core modeler we remain stable.

> I think that the existence of a Service element in the BPMN metamodel is crucial, especially when we will try, in the near future, to integrate the different modeling representations used in SOA (graphical editors for BPMN, SCA, JBI and BPEL), as pointed out in the STP Internal Model Discussion (http://wiki.eclipse.org/STP_Internal_Model_Discussion).

Antoine and myself are developing for my company a transformation of
BPMN to BPEL and WSDL. We have not needed the service attribute or a
similar annotation. In our situation the service attribute has 2
issues:
- It is redundant:
Assume you do represent the messages by message connections. Then a
task that has at least one message connection is either a service
either a service invocation. Looking at the direction of the message
and their order you can actually know for sure. This makes the design
of diagram that provide and expose services very intuitive for users
who are not familiar with those concepts.

- It is not enough information to generate executable code.
For example it does not specify the actual service provided or
invoked. Once you do define an annotation that defines which service
is used by the task the value of the service attribute becomes also
redundant.

I understand that some applications may use the service attribute.
Some other applications do not. In my opinion it is a good idea to let
the application developers define what kind of information they need
for their own application.
This does not mean that BPMN diagrams produced for one type of
application will not work for another. When an annotation is not
interpreted by a particular application, it is just let alone. So once
you have defined a set of annotations to transform shapes inside a
pool into an SCA component, you can connect them to another pool that
annotations are related to BPEL. A builder for each type of
transformation will produce 2 sets of executable code that are
actually collaborating.

I think that what we could add to the current code-base is a plugin to
define those annotations that define extra information on the shapes
and expose them as properties.


What do you think?
Hugues.


On 7/27/07, JUAN JOSE CADAVID GOMEZ <jcadav10@xxxxxxxxxxxx> wrote:
> Thanks a lot for your answers Hugues and Alex! I'm sorry I couldn't get back earlier.
>
> Indeed, I believe the best way to add types to the BPMN modeler is the annotations mechanism, and I think I'll use this one since I don't want to modify the consensus-released solution.
>
> However, it is a matter of concern that the behavior of a modeling element is determined by the value of an attribute. In the BPMN specification, the Task element does exist by itself; however, the Service element doesn't, and same issue occurs: "A Task is a BPMN Service when its TaskType is Service". So there it is again, an attribute determining what should be rather defined with specialization.
>
> Our BPMN modeler goes even further, by declaring that "An Activity is a BPMN Task when its ActivityType is Task". In this way, for Service it would be like "An Activity is BPMN Service when its ActivityType is Task, and when it is annotated under the key 'TaskType' with the value 'Service'". If you ask me, this doesn't sound way too natural for me.
>
> I think that the existence of a Service element in the BPMN metamodel is crucial, especially when we will try, in the near future, to integrate the different modeling representations used in SOA (graphical editors for BPMN, SCA, JBI and BPEL), as pointed out in the STP Internal Model Discussion (http://wiki.eclipse.org/STP_Internal_Model_Discussion).
>
> What do you think? If you don't mind, I would like add a section in that page to leave note of these issues.
>
> Cheers,
>
> Juan
> ------------------------------
>
> Message: 6
> Date: Wed, 18 Jul 2007 07:57:00 -0700
> From: "Alex Boisvert" <boisvert@xxxxxxxxxxx>
> Subject: Re: [stp-dev] About BPMN metamodel
> To: "STP Dev list" <stp-dev@xxxxxxxxxxx>
> Message-ID:
>         <5582dd3b0707180757p1a2d6a0cm6ddcf785169a53a5@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I'll complement Hugues' answer, by saying type of the task can be inferred from the diagram or from more specific subclasses.
>
> Second, I consider TaskType to be restrictive in that it unduly constrains the extensibility of the model by using an attribute to model behavioral character.  This is something that can be better achieved by specialization
> (inheritance) to avoid overloading the meaning/ semantic of base attributes in the Task class.  At first glance, it might seem like this makes it harder for M2M transformation, although my guess is that you'll probably need to
> walk the graph for any kind of comprehensive transformation process.   If
> you'd like to match against specific types, it's possible to introduce new classes to the model, starting with Task itself (with or without the TaskType attribute).
>
> cheers,
> alex
>
> On 7/17/07, Hugues Malphettes <hmalphettes@xxxxxxxxxxx> wrote:
> >
> > Hi Juan,
> >
> > The BPMN metamodel is made to support the BPMN notation for a BPMN
> > modeler.
> > It is does not natively support all the type of extra properties
> > defined in the BPMN specification.
> >
> > However the model can be attached any number of properties by using
> > EMF annotations.
> >
> > So in the case you mention the approach we recommend is to define an
> > annotation to set on the org.eclipse.stp.Activity class.
> >
> > An Activity is a BPMN Task when its ActivityType is Task.
> >
> > This tutorial describes how to expose such annotation in the
> > properties
> > view:
> >
> > http://wiki.eclipse.org/index.php/STP_BPMN_Presentation_Hands_on_tutor
> > ial#Extending_the_modeler:_defining_a_custom_property
> >
> > Hugues
> >
> >
> >
> > On 7/17/07, JUAN JOSE CADAVID GOMEZ <jcadav10@xxxxxxxxxxxx> wrote:
> > > Hello,
> > >
> > > Some time ago I wrote about a college project currently in progress
> > about extending the STP BPMN modeler for M2M transformations. I have
> > checked the bpmn.ecore metamodel against the BPMN specification and
> > noticed that in the specification there are two Activity subtypes
> > declared, Task and Sub-Process. However, I can't seem to find these
> > two subtypes in the STP BPMN schema.
> > >
> > > My concern is that in the specification, the Task element has an
> > attribute called TaskType, with possible values (Service | Receive |
> > Send | User | Script | Abstract | Manual | Reference | None) which I
> > need to capture for the transformation rules I'm writing. However, I
> > don't see how to obtain it with the current metamodel, since the Task
> > element doesn't exist. Can somebody help me here?
> > >
> > > I appreciate your attention.
> > >
> > > -Juan
> > >
> > > _______________________________________________
> > > stp-dev mailing list
> > > stp-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/stp-dev
> > >
> > _______________________________________________
> > stp-dev mailing list
> > stp-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/stp-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: https://dev.eclipse.org/mailman/listinfo/stp-dev/attachments/20070718/c494921d/attachment.html
>
> ------------------------------
>
> _______________________________________________
> stp-dev mailing list
> stp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stp-dev
>
>
> _______________________________________________
> stp-dev mailing list
> stp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stp-dev
>