Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jwt-dev] [Fwd: Re: [stp-dev] Re: About BPMN metamodel]

FYI.

Interesting discussion on stp-dev about integrating their BPMN modeler with their other tools using additional metamodel properties constituting a common intermediate metamodel throughout stp.

This is a subject we've discussed with Miguel last week in Grenoble. I'll put more about this soon.

Regards
Marc Dutoo
Open Wide
--- Begin Message ---
Hi Hugues,

I see you're right, there's no 'L' in BPMN, and maybe the lack of formalism that a language imposes is what enables it to fulfill its goal of a flexible, yet simple modeling notation for business analysts. And so should be its metamodel.

In this way, I agree that the solution to integrate BPMN with the other notations in STP should be something external to the BPMN modeler and its metamodel. I like the idea of a plug-in to add the extra information as properties. In fact, Adrian Mos is working on a common intermediate metamodel for service definition for which all the other model types should work with, and he will submit it soon. This will give a starting point on how the STP sub-projects should be extended to allow integration and model transformation.

Thanks again, and I'll be looking forward to what's coming!

-Juan


> -----Original Message-----
> From: stp-dev-bounces@xxxxxxxxxxx [mailto:stp-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Hugues Malphettes
> Sent: Monday, July 30, 2007 8:08 PM
> To: STP Dev list
> Subject: Re: [stp-dev] Re: About BPMN metamodel
> 
> 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
> >
> _______________________________________________
> 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

--- End Message ---

Back to the top