BPMN relocating elements

[Adam@Schneider]

I've noticed a quirk, if you create a BPMN process diagram, any elements you drop on it move to where the diagram is located within the project tree, if you move them back to their correct home in the project tree and then move them on a diagram they relocate next to the diagram again.

Why? and is this a user setting?

[ducatiross]

I've had exactly the same thing Adam. See my post http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1416086349

It's so annoying and wastes a lot of time moving things back to where they should be in the project browser.

This is a serious bug that needs to be fixed as it is essential that a project can be organised correctly in order to aid object re-use and management.

[ducatiross]

Doing a quick bit of testing, and it seems to not have this issue in Builds 1106 and 1112 when using a .EAP file as the repository, but it does in build 1112 when using a SQL Server database instead.

What repository type are you using Adam ?

[qwerty]

It surely does not depend on the repository type. Sparx has done a lot of work in direction of BPMN. You should both report a bug.

q.

[Eve]

What are you trying to re-use? What's the circumstance?

BPMN requires any activity to belong to a single process, but a process can be re-used by referencing it with a pool. Just as a Pool belongs to a single collaboration, but it can represent a PartnerEntity or PartnerRole, either of which can be used across multiple collaborations.

[Adam@Schneider]

We are on EA build 1110 and an SQL server repository.

I'll report a bug, there are 2 main reasons we arrange all activities in a single place, firstly the same process can be shown on multiple different diagrams, we might have a very big diagram showing everything, and cut down diagrams that go in certain document sections that are more focussed.

Second, following on from that we pool all activities under a single root so we can easily fire up the relationship matrix to view or assign requirements traceability. This also helps in document generation for example to generate a traceability table.

I dont mind that creating the activities on the diagram puts them with the diagram, but if they are manually moved away, or put onto another diagram (which for example may be in a sub package for doc gen formatting/heading purposes) moves the element then I think its wrong, it was put where it is for a reason.

[ducatiross]

To add to Adam's comments I have some elements that I want to use on any diagram, of any type, such as an Entity that I can flag with a status of 'Incomplete' which I then drag onto any diagram from my 'General' package. I then remove it from the diagram when I have finished drawing it.

By keeping it in my 'General' package, I can quickly locate it and do 'Find in all diagrams' to show me which diagrams I still have work to do on. This works fine for all diagram types except BPMM where once dragged onto one of these, the element is moved from the 'General' package and re-located in the package where the diagram is. This makes it very hard to find the next time I want to use it on any diagram.

Specifically related to BPMN diagrams, I created a folder/package called 'Swimlanes' where I put all the lanes I need. I also have over 40 other packges containing diagrams related to specific processes. Once I drag a swimlane from the 'Swimlane' package into one of these diagrams, the swimlane itself is re-located to the package containing the diagram I have just dragged it on to.

This is bad enough when there is one person doing the modelling, but in a team environment, where people need to know where to find common elements, it is completely unmanageable.

Matthew

[Eve]

Specifically related to BPMN diagrams, I created a folder/package called 'Swimlanes' where I put all the lanes I need. I also have over 40 other packges containing diagrams related to specific processes. Once I drag a swimlane from the 'Swimlane' package into one of these diagrams, the swimlane itself is re-located to the package containing the diagram I have just dragged it on to.

This is bad enough when there is one person doing the modelling, but in a team environment, where people need to know where to find common elements, it is completely unmanageable.

As I said, BPMN is very clear that swimlanes are not common elements.

a Pool belongs to a single collaboration, but it can represent a PartnerEntity or PartnerRole, either of which can be used across multiple collaborations.

[OpenIT Solutions]

Hi Simon,

One thing for Sparx to consider - a lot of customers will have configured their repositories to work with the behavior exhibited by the Sparx version they started with; for us this was 9.3. In 9.3 as you will know the BPMN behavior was different to 11/12.

The issue I face now is that I can't upgrade to 11 or 12; for various reasons we do reuse pools/lanes from a central library of lanes/pools....main reason being that we need standard names displayed on pools/lanes as they represent external parties and internal teams/orgnisational units respectively in our model - so the names need to be consistent (on the face of our diagrams). I can't let modellers add local/new lanes to a diagram and give them a random name.

I know they can set the role/entity/participant ref (defined in a library)... and that I could reliably query this. However when set, this doesn't appear on the diagram; so anyone looking at the diagram only will see the random name the modeler might have given the lane.

What would be good in this regard (pool/lane naming) is that if the name was left blank, but the role/entity/participant ref is set - it is displayed as the name...then I could migrate over to using bpmn as sparx/spec intends. Does this make sense ? Do you understand the dilemma/problem in this case ?

Another thing I've noticed in v12 is that if I add a pool to a diagram sparx magically moves my diagram under a CollaborationModel element. Again this may be as per bpmn spec (although in this case i'd question that) - but it causes issues for those that have written reports/analytics/training etc to use the behavior of previous versions of Sparx.

What we need when Sparx adds these great new features - is a way of turning them off if required. Is there a configure option available to turn of this new behavior (CollaborationModel being added). I also need to be able to stop Sparx moving activities under pools/lanes as child elements when they are placed in the pool/lane....

Appreciate your feedback.

[Eve]

What we need when Sparx adds these great new features - is a way of turning them off if required. Is there a configure option available to turn of this new behavior (CollaborationModel being added). I also need to be able to stop Sparx moving activities under pools/lanes as child elements when they are placed in the pool/lane....

I understand what you're saying, and why you are requesting it. We did consider this issue, and our initial plans were changed after consultation with someone else in much the same position. Ultimately though, we needed to elevate our BPMN support from drawing a picture to creating a model.

Showing the entity/role name on a diagram doesn't seem unreasonable. However, a simpler solution to the pool naming problem is to tell your modellers what is expected. If you can't trust them to name something correctly, can you trust anything else that you've done.

The problem with adding an option to keep the old behavior, is that kind of thing drastically increases code, user interface and testing complexity. Each option of that sort added makes issues with one setting or the other that much more likely.

[OpenIT Solutions]

Hi,

I appreciate that having an option to disable behavior adds to code/testing complexity. But to be blunt without it we will not be able to upgrade beyond v10 and would thus look for a new tool.

As a company we hold circa 1200 Sparx licenses. We have invested $100sK in building circa 6000 process maps over the last three years, along with scripts, reports, model structure etc to support our modelers. The cost of reworking all this to fit with your changes is prohibitive.

Given the seriousness of the issue we face - I have sent a direct email/request to Sparx.

I'm responding here as well as i'm sure many other members of the community will have similar concerns regarding changes in behavior between releases. I'd encourage them to voice them.

[ducatiross]

Ultimately though, we needed to elevate our BPMN support from drawing a picture to creating a model.

OK, I admit I am not the world's best BPMN modeller, but I don't understand what you are saying here. A Swimlane represents the activities of a particular role. That role may be engaged in many disparate processes, modelled in many independent diagrams, but they should all use the same Swimlane for the same Role, so you know, as a totality, what actions/messages/data that role interacts with and can re-use those item in any other diagram that needs that Lane. Thus, you have modelled, rather than simply drawn.

How does allowing a lane to exist in an owning package (where EVERYONE knows where to find it) independent of any specific diagram put this 'model' at risk ?

Are you really saying that each process requires a new Swimlane for the same role because it represents a different interaction/collaboration ? Just looking for some clarification here.

thanks

Matthew

[ducatiross]

The cost of reworking all this to fit with your changes is prohibitive.

I'm with you on this one ! Updates should, unless it is totally unavoidable, be backwards compatible to protect customer's investment.

[Eve]

We have someone looking into what the negative impact of not moving Pools would be. I can't promise a timeframe, but we have heard your concerns.

A Swimlane represents the activities of a particular role.

Assuming you're talking about a Pool, that's not quite true. A Pool represents the activities of a participant (either an entity or role) in a particular collaboration. Which is why BPMN specifies that it is always owned by the collaboration.

That role may be engaged in many disparate processes, modelled in many independent diagrams

Exactly, which is whythere are PartnerRole/PartnerEntity elements which a Pool can reference.

but they should all use the same Swimlane for the same Role, so you know, as a totality, what actions/messages/data that role interacts with and can re-use those item in any other diagram that needs that Lane.

The problem with this is that if in two different diagrams you send a message to this pool (ie. MessageFlow) the model can't distinguish which collaboration each message is part of (without looking at the other end.) Unfortunately, if you've done this the model and any documentation generated from it is either wrong or simply misleading.

You would have the same issue using Classes on a UML Communication diagram instead of creating Objects with the appropriate Classifier set.

But to be blunt without it we will not be able to upgrade beyond v10 and would thus look for a new tool.
...
The cost of reworking all this to fit with your changes is prohibitive.

Obviously, we don't want that, but to be equally blunt. Without these changes there's almost¹ no way that you could export your model and expect another tool to import it in a useable fashion.  We put a lot of effort into version 11.1 to ensure that it could round-trip BPMN models in the standard format. The changes that were made to modelling in 11.1 where what was required to help create models that you would be able to export to an execution engine or other tool.

If you tried exporting to another tool from EA 11.1 without changing your model you will mostly get individual processes across. At a minimum I would expect all the Pool linkages to be broken and need to be recreated. If you tried that from EA 11.0 or earlier I would expect it to be even worse.

If you updated your model and exported with EA 11.1, I would expect most of the model to make it intact². From what I've seen of the BPMN MIWG wiki there's usually some diagram differences too, which vary depending on tool. Unfortunately, we don't have our test results up there yet, but in my opinion we are among the best.

-----

¹ It's possible that some other BPMN tool has explicitly written an importer for our BPMN models that takes the same assumptions about how pools are used that you have done into account.

² Depending on the capabilities of the other tool of course.

[OpenIT Solutions]

Hi,

Quick update on this - I raised a registered support query - sparx have responded indicating that the issues I raised will be addressed in v12 (or shortly after)....which is great - so thank you Sparx .


Regards,


Jon.