Re: AW: AW: AW: AW: [jwt-dev] Bonita Designer use cases and requirements

[Marc Dutoo <marc.dutoo@xxxxxxxxxxx>]

Hi Chris, all

I agree, it seems to me that we're close to have a common architecture, the
next step is creating bugzillas, and wiki pages for complex specs or
discussions. I'll see what I can do about it tomorrow or on Monday.

Regards,
Marc

On Thu, 13 Nov 2008 10:00:25 +0100, "Christian Saad"
<christian.saad@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Hi Marc,
> 
> ok I see this would require to possibility to replace the original
palette
> from somewhere from your plugin that provides the aspects functionality.
> The
> customization offered by adding custom palettes and by configuring the
> palette through views should however be carefully planned so that they
> don't
> interfere.
> We should probably record the new requirements in the bugzilla as soon as
> possible so that no important requirements get lost.
> 
> Regards,
> Chris
> 
>> -----Ursprüngliche Nachricht-----
>> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx]
>> Im Auftrag von Marc Dutoo
>> Gesendet: Mittwoch, 12. November 2008 22:44
>> An: Java Workflow Toolbox
>> Betreff: Re: AW: AW: AW: [jwt-dev] Bonita Designer use cases and
>> requirements
>> 
>> Hi Rodrigue, Chris
>> 
>> Good questions indeed...
>> 
>> Maybe we could have both, and abstract our view impl of the palette
>> behind a palette factory impl ?
>> 
>> Besides I've got requirements on my own on the Palette : not only to be
>> able to specify which type to create, but also which list of aspects to
>> add to it once it has instanciated a type, so you could have different
>> tools in the palette creating the same type but with different aspects.
>> 
>> Regards,
>> Marc
>> 
>> Christian Saad a écrit :
>> > Hi Rodrigue,
>> >
>> > the current JWT palette consists of a static and a dynamic part. The
>> static
>> > part contains the standard entries like the nodes and references
>> while the
>> > dynamic part allows to create references to existing elements, e.g.
>> you
>> > define a new role 'x' and an entry is added to the palette which
>> creates a
>> > new reference to 'x'. Both parts are however subject to the view,
>> i.e. their
>> > elements are hidden if configured so in the view and in the future
>> their
>> > names will also be read from the view and maybe the visibility in the
>> > palette will be decoupled from the visibility in the editor. In
>> theory, it
>> > would be possible to replace the palette with other implementations
>> but the
>> > question is if this is really necessary or if we could put everything
>> in the
>> > view configuration which would provide a much easier way to customize
>> the
>> > palette.
>> >
>> > Regards,
>> > Chris
>> >
>> >
>> >> -----Ursprüngliche Nachricht-----
>> >> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-
>> bounces@xxxxxxxxxxx]
>> >> Im Auftrag von Rodrigue Le Gall
>> >> Gesendet: Donnerstag, 6. November 2008 13:51
>> >> An: Java Workflow Toolbox
>> >> Betreff: Re: AW: AW: [jwt-dev] Bonita Designer use cases and
>> >> requirements
>> >>
>> >> Hi,
>> >>
>> >> In fact the Bonita use cases identify that we need a concept of
>> >> PaletteFactory customizable for each view (like the figure Factory).
>> >>
>> >> A Palette is a very simple composant and it is acceptable and easy
>> to
>> >> write a PaletteFactory if we need to customize it. So JWT must
>> provide
>> >> a default PaletteFactory (with the actual logic of hidding some
>> >> component by using the view configuration), but to be very flexible
>> >> anybody must be able to provide a PaletteFactory with its own logic
>> >> (hardcoded, configurable, ...).
>> >>
>> >> thoughts?
>> >>
>> >> --
>> >> Rodrigue
>> >>
>> >> *Orchestra*, The BPEL open source project: http://orchestra.ow2.org
>> >> *Bonita*, The XPDL open source project: http://bonita.ow2.org
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Christian Saad a écrit :
>> >>
>> >>> Hi,
>> >>>
>> >>> In order to show concrete elements in a more abstract view, the
>> >>> elements could be set to be visible in the abstract view but
>> >>>
>> >> replacing
>> >>
>> >>> their figure and caption with the figure/caption of the abstract
>> >>>
>> >> type.
>> >>
>> >>> Maybe we could also add an option to hide certain elements in the
>> >>> palette, so that the fake abstractcontrolnode (really forknode)
>> >>>
>> >> doesn't show up in the palette.
>> >>
>> >>> And for replacing abstract concepts with concrete ones, I think
>> that
>> >>> this could become quite tedious for the user if the control really
>> >>>
>> >> has
>> >>
>> >>> to be removed and a new one should be added since connections and
>> >>> already set attributes must be restored (if this is the way it is
>> >>>
>> >> done
>> >>
>> >>> until now?). I'm thinking that we could provide a way to do this
>> >>> automatically, e.g. by offering an option in the context menu that
>> >>> shows all concrete subtypes and automatically changes the type of
>> the
>> >>> EMF model element internally to the concrete type while keeping all
>> >>>
>> >> existing preferences.
>> >>
>> >>> Regards,
>> >>> Chris
>> >>>
>> >>>
>> >>>
>> >>>>> FL:
>> >>>>>
>> >>>>> Concerning the abstract activity node: the metamodel already
>> >>>>> includes
>> >>>>>
>> >>>>>
>> >>>> some
>> >>>>
>> >>>>
>> >>>>> abstract nodes such as ExecutableNode or ControlNode that might
>> be
>> >>>>>
>> >>>>>
>> >>>> used for
>> >>>>
>> >>>>
>> >>>>> that purpose. For the moment they are themself abstract classes
>> and
>> >>>>>
>> >>>>>
>> >>>> not
>> >>>>
>> >>>>
>> >>>>> shown in the palette or elsewhere, but it might be possible to
>> add
>> >>>>>
>> >>>>>
>> >>>> those in
>> >>>>
>> >>>>
>> >>>>> one view and remove the concrete subclasses from this (business)
>> >>>>> view
>> >>>>>
>> >>>>>
>> >>>> and to
>> >>>>
>> >>>>
>> >>>>> refine these abstract classes in a more technical view
>> afterwards!?
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>> Yes, it's what we did. By choosing elements to be displayed into
>> the
>> >>>> created view-file (Business/Technical) it becomes possible  to
>> >>>>
>> >> decide
>> >>
>> >>>> elements  that are present  into the palette of the  two views
>> >>>>
>> >> within
>> >>
>> >>>> the editor.
>> >>>> For instance ControlNode can be displayed in the palette of both
>> >>>> views (we simply added ControlNodeFigure ...) since fork/join node
>> >>>>
>> >> is
>> >>
>> >>>> only displayed in the palette of the Technical design.
>> >>>> But the following use case cannot be realized:
>> >>>> - create controlNode in Business view
>> >>>> - switch to Technical view and "replace" controleNode by forkNode
>> >>>> - switch again to Business view :   the forkNode is no more
>> visible
>> >>>>
>> >> in
>> >>
>> >>>> this view. We would want to keep this type of element visible
>> (even
>> >>>> the palette of business view does not contain this element).
>> >>>> In other word after refinement of the abstract class in a more
>> >>>> technical view switching back to the less technical view does not
>> >>>> prevent to display the refined element.
>> >>>> May be this possibility already exists ?
>> >>>>
>> >>>>
>> >>>>
>> >>>>> Concerning "activity, gateways, events, connections and
>> artifacts.
>> >>>>>
>> >>>>>
>> >>>> Should
>> >>>>
>> >>>>
>> >>>>> all of them extend ActivityNode":
>> >>>>> No, definitely not. A connection can't be an ActivityNode of
>> >>>>>
>> >> course.
>> >>
>> >>>> As
>> >>>>
>> >>>>
>> >>>>> already mentioned the ExecutableNode might be the activity, the
>> >>>>>
>> >>>>>
>> >>>> ControlNode
>> >>>>
>> >>>>
>> >>>>> the Gateway. Events are already included in the metamodel but
>> >>>>> without
>> >>>>>
>> >>>>>
>> >>>> any
>> >>>>
>> >>>>
>> >>>>> concrete subclasses, those will be needed in the future anyway,
>> as
>> >>>>>
>> >>>>>
>> >>>> soon as
>> >>>>
>> >>>>
>> >>>>> we decided what kind of events we want to model (hopefully not
>> the
>> >>>>>
>> >>>>>
>> >>>> whole set
>> >>>>
>> >>>>
>> >>>>> of BPMN which makes it quite confusing). For artifacts we
>> currently
>> >>>>> distinguish between Role, Application and Data, which can be
>> >>>>>
>> >> refined
>> >>
>> >>>> via
>> >>>>
>> >>>>
>> >>>>> aspects and those artifacts are connected with a specific edge to
>> >>>>> the Action/ExecutableNode.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>>> 	3. We have already talked about the implication of this
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> multiplicity edges on
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> a given node. As far as I understand, the mode is flexible and
>> >>>>>>> does
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> not
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> constraint this. The graphical layer does constraint action to
>> >>>>>>> have
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> only one
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> incoming and one outgoing transition (as UML-AD specifies).
>> >>>>>>>
>> >>>>>>>
>> >>>> However,
>> >>>>
>> >>>>
>> >>>>>> if we
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> provide our own graphical layer (by extension or modification),
>> >>>>>>> all
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> the tools
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> should still continue to work normally if they are based on the
>> >>>>>>> model
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> and not
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> on the graphical layer model. Right?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> Yes, they "should" ;) The only way to be sure is
>> >>>>>>    * 1. to test them, since they have only been tested on
>> workflow
>> >>>>>> models that have been created with a constrained WE till now
>> >>>>>>    * to have validation rules that validation engines can
>> enforce.
>> >>>>>> That's why I was talking about moving such constraints to a
>> >>>>>>
>> >>>>>>
>> >>>> validation
>> >>>>
>> >>>>
>> >>>>>> engine (ex. EMF's), and then why not allow vendors to customize
>> >>>>>>
>> >> the
>> >>
>> >>>>>> set of validation rules for their own use (profile). However, if
>> >>>>>>
>> >> it
>> >>
>> >>>>>> has to be done in October I'd simply make the existing edge
>> >>>>>>
>> >>>>>>
>> >>>> constraint
>> >>>>
>> >>>>
>> >>>>>> "disablable" using an extension point. Chris, what do you think
>> ?
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>> This shouldn't be a problem. For the time being, I think for the
>> >>>>> time
>> >>>>>
>> >>>>>
>> >>>> being
>> >>>>
>> >>>>
>> >>>>> we could also simply read the constraint for the maximum number
>> of
>> >>>>> incoming/outgoing edges from plugin.properties where it can be
>> >>>>> easily adapted by vendors.
>> >>>>>
>> >>>>> FL:
>> >>>>>
>> >>>>> Hmm, another thought would be to define the maximum number of
>> >>>>>
>> >>>>>
>> >>>> incoming and
>> >>>>
>> >>>>
>> >>>>> outgoing edges for each element by the view-file? So, a business
>> >>>>>
>> >>>>>
>> >>>> manager
>> >>>>
>> >>>>
>> >>>>> would be allowed to ignore such things as control nodes and
>> simply
>> >>>>>
>> >>>>>
>> >>>> used
>> >>>>
>> >>>>
>> >>>>> nodes and edges (as he would love to do), but in the technical
>> view
>> >>>>>
>> >>>>>
>> >>>> could
>> >>>>
>> >>>>
>> >>>>> then be changed and more semantics via different control nodes
>> >>>>>
>> >> added.
>> >>
>> >>>>> Probably this needs also a validation mechanism when switching
>> from
>> >>>>>
>> >>>>>
>> >>>> one view
>> >>>>
>> >>>>
>> >>>>> to another. What do you think?
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>>> 	5. We would like many different ways to display properties.
>> >>>>>>>
>> >> One
>> >>
>> >>>>>>>
>> >>>>>> of them is
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> inside the task itself. There is a strict mapping between the
>> >>>>>>> palette
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> and the
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> model. Therefore, how can we modify the way things (and in our
>> >>>>>>> case
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> actions)
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> are rendered just by extension?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> Properties are already displayed in the PropertyView. There you
>> >>>>>>
>> >> can
>> >>
>> >>>>>> create a custom editor for a given property (extension point by
>> >>>>>> Mickaël), or a whole new tab (by Chris), see wiki. You can make
>> >>>>>> them also appear in the Outline by changing the
>> >>>>>> ModelContentOutlinePage's content and label provider.
>> >>>>>>
>> >>>>>> Or do you mean, display properties within the diagram, like
>> above
>> >>>>>>
>> >>>>>>
>> >>>> the
>> >>>>
>> >>>>
>> >>>>>> task icon ?
>> >>>>>> Maybe the UML View sample plugin (see bugzilla) is
>> interesting...
>> >>>>>> Chris,
>> >>>>>> any idea ?
>> >>>>>>
>> >>>>>> And could your describe concrete examples of such different ways
>> ?
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>> A concrete example would definitly be good in order to get this
>> >>>>>
>> >>>>>
>> >>>> requirement
>> >>>>
>> >>>>
>> >>>>> right.
>> >>>>> Basically, views allow to replace JWT's internal draw2d figures
>> >>>>>
>> >> with
>> >>
>> >>>> your
>> >>>>
>> >>>>
>> >>>>> own, so you could implement a new figure that visualizes some of
>> >>>>>
>> >> its
>> >>
>> >>>>> element's properties.
>> >>>>>
>> >>>>> FL:
>> >>>>>
>> >>>>> Yes, I think that would be the way you were asking for. In
>> >>>>> additional plugins you can say that an already existing figure
>> >>>>>
>> >> shall
>> >>
>> >>>>> be replaced
>> >>>>>
>> >>>>>
>> >>>> by a
>> >>>>
>> >>>>
>> >>>>> new figure and this new figure can be constructed however you'd
>> >>>>>
>> >> like
>> >>
>> >>>> it. So,
>> >>>>
>> >>>>
>> >>>>> if you do not only want to have the name of the action in it, but
>> >>>>>
>> >>>>>
>> >>>> also some
>> >>>>
>> >>>>
>> >>>>> properties, be it. If you'd prefer to show a monkey instead of
>> >>>>>
>> >>>>>
>> >>>> anything, so
>> >>>>
>> >>>>
>> >>>>> just design one ;-)
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>>> We are just starting to get knowledge of EMG/GEF stuff (which
>> is
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> quite huge)!
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> Some questions may sound very simple! All our excuses for that!
>> >>>>>>> ;-)
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> Well, I'm not sure there is any simple one ;) Anyway, we'll try
>> to
>> >>>>>> make it easy to get in. And no need to learn everything, there
>> are
>> >>>>>> other people with other knowledge !
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>> EMF/GEF is definitely anything but trivial and your questions are
>> >>>>>
>> >>>>>
>> >>>> very
>> >>>>
>> >>>>
>> >>>>> important for us since we can decide which way the development
>> >>>>> should
>> >>>>>
>> >>>>>
>> >>>> take
>> >>>>
>> >>>>
>> >>>>> in order to fulfill business requirements.
>> >>>>>
>> >>>>> FL:
>> >>>>>
>> >>>>> I fully agree. Best regards,
>> >>>>>
>> >>>>> Florian
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> 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
>> >>>>
>> >>>>
>> >>> _______________________________________________
>> >>> jwt-dev mailing list
>> >>> jwt-dev@xxxxxxxxxxx
>> >>> https://dev.eclipse.org/mailman/listinfo/jwt-dev
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >> --
>> >> Rodrigue, Le Gall
>> >> Portal Technologies' Leader
>> >> BULL R&D , BPM
>> >>
>> >> Bull, Architect of an Open World TM
>> >> Phone: +33(0)4 7629 7464
>> >> email: rodrigue.le-gall@xxxxxxxx
>> >> http://www.bull.com
>> >>
>> >> *Orchestra*, The BPEL open source project: http://orchestra.ow2.org
>> >> *Bonita*, The XPDL open source project: http://bonita.ow2.org
>> >>
>> >> This e-mail contains material that is confidential for the sole use
>> of
>> >> the intended recipient. Any review, reliance or distribution by
>> others
>> >> or forwarding without express permission is strictly prohibited. If
>> you
>> >> are not the intended recipient, please contact the sender and delete
>> >> all copies.
>> >>
>> >
>> >
>> > _______________________________________________
>> > 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