Boundaries paste as new objects not links

[Paolo F Cantoni]

We have noticed that if you copy a diagram and paste diagram objects as links, Boundary objects are pasted as new copies of the object - not links.  This, naturally, plays havoc with our repository because if people annotate a boundary (as they should), the annotation doesn't appear on all their boundaries.  They are very confused users - especially since the boundary can't be found on the browser.  A query found one boundary had been pasted 47 times over 3 weeks!

We have had to create a mechanism to resolve this for us and restore only ONE copy of a boundary - setting all occurrences in the diagrams to that one.

Surely this a bug...

Reported,
Paolo

[Geert Bellekens]

Paolo,

Boundaries are considered to be diagram-owned elements, so that is why you are seeing that behavior.
I think this is a deliberate behavior, and I think the current behavior is what most people would expect (whether they know it or not).

Maybe boundaries are not the right type of element to use for your purpose?

Geert

[Paolo F Cantoni]

We need the attributes, properties and rendering of the boundary - which aren't available on other elements - without a LOT of work.  We have even stereotyped them - because they are so useful.

ArchiMate has shown that "grouping" - which is what a boundary is (by definition: Mathematics. the collection of all points of a given set having the property that every neighborhood of each point contains points in the set and in the complement of the set.) is a valid form of non-diagram specific element.  Due to the fact that boundary elements aren't (currently) visible in the browser, Sparx was forced to use a different element type, instead of fixing the basic modelling issue.  Using the component element type for grouping has issues of its own in our view.

In any event, I cannot see how when I explicitly say "paste as links", EA doesn't do so.  We can put up with (for the present) the boundary not being directly available on the browser (we have an alternate mechanism for finding the boundaries in the browser packages)  but this cloning is "naff" as the Brits say.

Paolo

[VKN]

We have had to create a mechanism to resolve this for us and restore only ONE copy of a boundary - setting all occurrences in the diagrams to that one.

You'd probably have to include note elements (and may be other diagram only elements) in your mechanism as the behavior is the same.

However, if a boundary/note element is pasted as a link in another diagram, there is only one copy.

[Paolo F Cantoni]

We have had to create a mechanism to resolve this for us and restore only ONE copy of a boundary - setting all occurrences in the diagrams to that one.

You'd probably have to include note elements (and may be other diagram only elements) in your mechanism as the behavior is the same.

However, if a boundary/note element is pasted as a link in another diagram, there is only one copy.

NO the boundary is NOT....  That's my point!   We only discovered this because we were running DB queries for another reason and a large number of boundary elements appeared in the results for a query they shouldn't have been on (in this case 27 newly created boundary objects).  I knew who the author of these boundaries was and he sits next to me.  So I asked: "Did you create new boundaries today?"  "No, I just copied and pasted some diagrams - with boundaries on them".

Further queries showed multiple instances of the same (in our case named) boundaries on the multiple diagrams.

Paolo

[VKN]

I just checked again in 1302.
I created a note and a boundary on a diagram.
Select both the elements and Paste Elements as Link on another diagram.
Save the new diagram
Deleted both the elements from the model through the new diagram and checked that the note and boundary are NOT present in the original diagram.

Apart from deleting the elements I've been checking through searches/back end as well.

Do you have 1302?

However, if I copy the diagram through project browser and paste in another package and select Paste elements as Link then both the note and boundary are duplicated.

[Paolo F Cantoni]

I'm using 1303.

The boundaries (and indeed ALL the objects) on the diagram are NOT in the same package as the diagram.  To quote Sparx "This behaviour is by design".

Sound like a conflation of pasting and cloning.

Needs work anyway - all that's happening as far as I can see is the hole is getting deeper...

Paolo

[Eve]

all that's happening as far as I can see is the hole is getting deeper...

All that's happening as far as I can see is that the evidence is mounting that boundaries are not the object you want despite your assertions. What exactly is the behavior from boundaries that you want?

[Paolo F Cantoni]

all that's happening as far as I can see is the hole is getting deeper...

All that's happening as far as I can see is that the evidence is mounting that boundaries are not the object you want despite your assertions. What exactly is the behavior from boundaries that you want?

Boundary properties (<Context Menu> | Properties) - the ability to change the Border Style / Fill (particularly to transparent), the ability to specify swimlanes.  These are NOT available elsewhere (AFAIK).  But the behaviour is inconsistent, why create a clone out of package but not within package (if that is indeed the case)- without telling the user (especially when told explicitly to do the opposite).

When I (try to) explain the behaviour to my users, I get perplexed looks - like "who thought that would be what we wanted".  Now if it is indeed the case that there are two different behaviours (within and without packages) I can predict the rolled eyes from my users.

As I've said before, it's hard enough getting users to model using a tool, this kind of friction can really get i the way.

Paolo

[Paolo F Cantoni]

OK, I've done some more investigation.

Copying and pasting an individual boundary (as link) will not create a clone (so VKN was right).  Even pasting across packages doesn't create a clone.

Creating a new diagram and copying it using [Ctrl+A] + [Ctrl+C] (manual copying)  in the origin diagram and then [Ctrl+V] (manual paste) in the destination diagram will not clone - even across packages).

Using the Copy / Paste > Copy Diagram and then Copy / Paste > Paste Diagram...  (selecting shallow copy - as links) will clone - even within the same package.

NOTE: Since I'm on the bus, I'm only testing against a local .EAP file.  I'll confirm against our SQL repository later.

It's a bug, ...

Paolo

[Eve]

Boundary properties (<Context Menu> | Properties) - the ability to change the Border Style / Fill (particularly to transparent), the ability to specify swimlanes.  These are NOT available elsewhere (AFAIK).

So it's the visual representation that you want from a boundary, not any of the intrinsic behavior of a boundary as an element that is owned by the diagram itself.

You're trying to make a round peg fit into a square hole because you like the color.

PS.

Boundaries are considered to be diagram-owned elements, so that is why you are seeing that behavior.

The bug is when they behave otherwise.

[Eve]

Here's a shape script (5-10 minutes work) that replicates the visual options of a boundary on any object using tagged values. (but only up to 3 lanes in each dimension)

It even avoids some of the weirdness in options that exist for legacy reasons and allows you to customize it further.

Code: [Select]

shape main
{
noshadow=true;
if(HasTag("border","dot")) {
SetLineStyle("dot");
}
else if(HasTag("border","dash")) {
SetLineStyle("dash");
}
else {
SetLineStyle("solid");
}

StartPath();

if(HasTag("shape", "circle")) {
Ellipse(0,0,100,100);
}
else if(HasTag("shape", "round")) {
RoundRect(0,0,100,100,20,20);
}
else {
Rectangle(0,0,100,100);
}

EndPath();

if(hastag("filled","true")) {
FillAndStrokePath();
}
else {
StrokePath();
}

if(hasTag("hlanes",2)) {
moveto(0,50);
lineto(100,50);
}
else if(hasTag("hlanes",3)){
moveto(0,33);
lineto(100,33);
moveto(0,66);
lineto(100,66);
}

if(hasTag("vlanes",2)) {
moveto(50,0);
lineto(50,100);
}
else if(hasTag("vlanes",3)){
moveto(33,0);
lineto(33,100);
moveto(66,0);
lineto(66,100);
}

strokepath();
}

[Paolo F Cantoni]

Boundary properties (<Context Menu> | Properties) - the ability to change the Border Style / Fill (particularly to transparent), the ability to specify swimlanes.  These are NOT available elsewhere (AFAIK).

So it's the visual representation that you want from a boundary, not any of the intrinsic behavior of a boundary as an element that is owned by the diagram itself.

You're trying to make a round peg fit into a square hole because you like the color.

PS.

Boundaries are considered to be diagram-owned elements, so that is why you are seeing that behavior.

The bug is when they behave otherwise.

It's still a bug - they behave inconsistently.  If they are diagram owned, then they should never be re-used on a diagram other than the one they are created in. Yet this is patently the case.

I accept that if the boundary object type is defined to be a diagram owned item then I'm (conceptually) using the wrong object type.  Your script (which I was trying to avoid) does mean I can use another object type (although we'll use diagram specific user-selected properties instead of tagged values - for flexibility) We have an automated mechanism to fix this sort of thing up so we'll take that route. 

Was there any reason the Component Object type was used as the base for the Grouping relationship over the other types?  Just interested since I don't expect to be using Components for this purpose.

Notes appear to behave in an analogous way.  Cloned - inconsistently.  There's no way out of that one is there?

Paolo