Community
Participate
Working Groups
For our presentations at several conferences it would be nice to have another view which can be easily distinguished from the JWT business or technical view. Chris and I were thinking about the Event-driven process chains (EPCs) which look completely different to JWT's diagrams, but include nearly the same elements as JWT. The only thing that does differ is the usage of events which are needed in JWT after each function (our Action). Probably this needs to be added via aspects to this view. EPCs are part of the ARIS house which is quite common especially in German speaking countries and includes events, functions, connectors (AND, OR, XOR) as well as a control view. It itself has several views: the functional view, organizational view, data view and business value view. Most interesting for us is probably the functional view at the beginning. For each function in these EPCs one can add organizational entities (our roles), data or material (our Data), so it should be quite easy to implement in a rudimentary form.
A new requirement that came up during the current development: At the moment EditPolicies are fixed for one view. I.e. that if an Event is specified as non-resizeable, then this is fact for all kinds of views. For this EPC-view however, events are used all the time and contain the name not below the figure, but in the figure itself. That means that the figures should be resizable in order to display the whole text. Hence, a possibility to change the edit policies from the outside (external plugins) is necessary.
The mentioned requirement is currently developed as part of bug 263241, the new factoryRegistry. With this it will be able to have an own editpart-class which instanciates its own edit policies. Therefore, I mark this bug as dependent on bug 263241.
Small change in JWT-WE (already committed): Each ReferenceableElement (Application, Data and Role) has now its own Figure. This allows in extending plugins that Applications can have different figures than data or roles (and the other way round) and is necessary for the EPC view. Therefore, the ReferenceableElementEditPart has been adapted.
Created attachment 125918 [details] First implementation for an EPC view Please find attached a first draft implementation of the EPC view in JWT. This includes an aspect-oriented extension (new subclass of ExecutableNode called EPCEvent), different figures for Data, Application, Role as well as for existing control nodes.
Created attachment 125919 [details] Screenshot of first EPC implementation A screenshot how it currently looks like.
I made some progress in the JWT view for Event-driven Process Chains (EPCs). Attached you can find a ZIP containing the source code as well as a screenshot how it currently looks like. The implementation builds upon the FactoryRegistry provided by Bull and on the Aspect-mechanism provided by OpenWide. Current issues: -switching from one view to another causes problems since WE searches for a figure for this new element (subclass of ExecutableNode, hence searching for ExecutableNodeFigure) and does not find one. This will be a problem for all future aspect-extensions which is why it needs to be fixed in jwt-we. -when opening Eclipse (Runtime workbench) it does not correctly load the aspect-extended file but throws several exceptions. When closing the file and opening it again in the runtime workbench, then everything works. -transformations necessary for ActivityEdge: when switching to another view, then the new element EPCEvent is not available anymore. If before Action -> EPCEvent -> Action had been connected by ActivityEdges then the edges now don't find the source or target anymore and therefore lead to nowhere (in the diagram: top left). Several possibilities exist to fix this: * have a new extension point as "Hook" ;-) which allows to execute a method if a specific view has been activated or deactivated. These methods then transform the model so that it shows one edge from Action to Action instead of two edges that don't lead anywhere. * the new view mechanism controls the edges (probably a nightmare for Chris who already struggles with refactoring) * changing jwt-we and including an algorithm that looks for MissingElementExceptions and goes through the model and searches which element has been the target and in which edges this element is the source and shows "temporary" edges instead. What do you think of these possibilities? Best regards, Florian.
> -switching from one view to another causes problems since WE searches for a > figure for this new element (subclass of ExecutableNode, hence searching for > ExecutableNodeFigure) and does not find one. This will be a problem for all > future aspect-extensions which is why it needs to be fixed in jwt-we. Do you think that all elements, including those considered as abstract, should have a figure associated? That would not be difficult and would make sense for model extensions. > -transformations necessary for ActivityEdge: when switching to another view, > then the new element EPCEvent is not available anymore. If before Action -> > EPCEvent -> Action had been connected by ActivityEdges then the edges now don't > find the source or target anymore and therefore lead to nowhere (in the > diagram: top left). According to what I understood, the ECPEvent is an aspect on top of ExecutableNode, then, if the view is not able to display an ECPEvent, let's consider it as an ExecutableNode (and we get back to the first issue)... Also, I don't think that changing model when switching view is a good practice. There are risks that data would be lost at dev-time, and that users get unhappy with these unexpected behaviors, and that writing transformations become a nightmare.
With the concept of FactoryRegistries I was now successfull to create a first working draft of an EPC view for our workflows in the WE. This view uses an own Palette, an own view-file, has own figures for the elements (and sometimes also own edit parts resp. edit policies) and extends the existing metamodel using the confmodel with one new node called EPCEvent which is subclass of Event now. Known problems and limitations: - still some figures (e.g. for Function=Action or Event) are missing - there is a compile error in the generated EPCEventItemProvider. The plugin can be run nevertheless, but it is annoying. If somebody knows where the error comes from, I am happy for assistance here :-) - Sometimes when a diagram in EPC is open when Eclipse starts in the runtime workbench, a lot of exceptions happen and the process is not displayed at all. When Eclipse has loaded up completely, the workflow editor is closed and opened again, then everything works fine!? Still don't know where this problem comes from. Nevertheless, I committed the code, so that you can have a closer look on it and report any further problems as bug messages. Best regards, Florian
The bugs described below are now fixed: the palette contains figures for all entries, there is no exception during startup anymore and the error in the ItemProvider is now fixed, too. What would be nice for the usage of the EPC view is the addition of the dynammic entries and packages for the palette, so that roles, applications and data can also be added. I'll open a feature request for that, but think that this bug can be resolved as fixed.
This has been committed and included in version 0.6.0, not in 0.7.0. Changed version afterwards.
