Setting connectors only show in the current diagram by default

[slaza]

Dear All,

When I add a new connection to a diagram, it automatically shows up in all other diagrams. I need to switch off visibility manually for each and every new connector.

Is there any way to set the default visibility of a connector to show only on the current diagram, and I can switch visibility on if I wanted to anywhere else?

(I am sure that I am not the first person to ask this, but I just can't find the answer...)

[Geert Bellekens]

The answer is: you can't, and you shouldn't.

If you find yourself in the situation that you need that,  then you are doing something wrong.
Hiding relations should be an exception, for example when creating an overview diagram that you don't want to clutter with too much relations.

Geert

[MaXyM]

In fact it would be very useful.
When modelling relational database, It's common to create several diagrams containing the same entities while their goal is to show different point of views.
When adding relation between specific elements appearing on those diagrams, usually I don't want to make a connector appear on all diagrams. Just on specific one(s).

Is it still true that there is no option to stop adding connector to all diagrams?

[Paolo F Cantoni]

How many exceptions does it take to make a norm?

You're both right.  Hiding arcs (on most diagrams) should not be automatic, but there should be better control over arc display on diagrams at arc creation time.

As  MaxXym says, some views (especially in Enterprise-wide modelling) require some arcs to be hidden as not helpful to that particular viewpoint.

BUT THE MOST IMPORTANT THING is to provide a "widget" to indicate that there are hidden arcs on a given diagram.  We created our own to do that. It is vitally important that the view is informed that they are NOT seeing the "full story".

Paolo

[matthew.james]

How many exceptions does it take to make a norm?

Some common use cases that are relevant to this (IMO):
- Viewpoints often have focus on a particular types of interaction so the ability to control connector visibility by connector type would be useful (possible enhancement to the 'Set Visible Relations' window to group select by type)
- Some viewpoints are a higher level of abstraction than others and require 'derived' relationships to make the interactions clear, these derived relationships then pollute the more detailed diagrams (I don't have an easy answer to this one automatically, it's very hard to implement - I think Paolo mentioned in a previous post that they have implemented their own connector stereotypes to handle this manually ?)
- When multiple modelers are sharing a common model, changes made by one can affect diagrams being used by others so the ability to prevent additional connectors from appearing on diagrams would be useful (from memory I don't think locking the diagram achieves this)

As always there are downsides to most of this, the widget that Paolo has suggested is an intriguing idea to help mitigate those, and could maybe open the 'Set Visible Relations' window

This was raised in Bugs and Issues, probably better belongs in Suggestions and Requests, or at least General?

[qwerty]

BUT THE MOST IMPORTANT THING is to provide a "widget" to indicate that there are hidden arcs on a given diagram.  We created our own to do that. It is vitally important that the view is informed that they are NOT seeing the "full story".

This should be part of the next UML standard. Unfortunately the mills at OMG grind event slower than those at Sparx.

q.

[Eve]

- Viewpoints often have focus on a particular types of interaction so the ability to control connector visibility by connector type would be useful (possible enhancement to the 'Set Visible Relations' window to group select by type)

EA 14.1 has custom view specifications, and each diagram has the option to filter to the applied view (also called metamodel in places) By default it will use the fade effect, but you can fully hide elements and connectors that don't match the view by changing the diagram filter to use hide.

BUT THE MOST IMPORTANT THING is to provide a "widget" to indicate that there are hidden arcs on a given diagram.  We created our own to do that. It is vitally important that the view is informed that they are NOT seeing the "full story".

This should be part of the next UML standard. Unfortunately the mills at OMG grind event slower than those at Sparx.

q.

I disagree. Something like this is highly process specific and not part of the language itself. In the example of different views that have a different set of connectors visible, it would often be something you wouldn't want. Other than that, where do you draw the line for when this should appear? Is it just connectors? Just ones where the other end is on the diagram?

[matthew.james]

EA 14.1 has custom view specifications ... you can fully hide elements and connectors that don't match the view by changing the diagram filter to use hide.

Interesting, I'll take a look (assuming I can find some doco as we are still on 14.0)

[qwerty]

Simon, looking at the latest UML editions you see that diagram exchange has been added. Likely because they recognized that the semantics of diagrams should be detailed as there's a need for it. So that widget looks like a useful semantic extension that should go into a standard.

q.

[satrman]

How many exceptions does it take to make a norm?

You're both right.  Hiding arcs (on most diagrams) should not be automatic, but there should be better control over arc display on diagrams at arc creation time.

As  MaxXym says, some views (especially in Enterprise-wide modelling) require some arcs to be hidden as not helpful to that particular viewpoint.

BUT THE MOST IMPORTANT THING is to provide a "widget" to indicate that there are hidden arcs on a given diagram.  We created our own to do that. It is vitally important that the view is informed that they are NOT seeing the "full story".

Paolo

In Realtionships dock there can be column "View" added - it gives you the same info, you receive via Ctrl+Shift+I

[Paul Madle]

Hello All,

I have been modelling different scenarios using component diagrams for a cool open source spacecraft project (https://opensourcesatellite.org/).

In the process, I have been adding the same classes to multiple diagrams and adding different relationships between them. Similar to other users on this thread, I have been finding it enormously frustrating that the relationships added to one diagram end up appearing on all and so I sought to try and find a solution and I think I have one. It is not the most slick solution but it seems to work.

I wrote 3 JS scripts that function as follows:

1. A script that removes all links on a diagram. This is useful when you create a new diagram and drag on existing elements that already have relationships between them.

2. A script that "Freezes" the current set of links on a diagram so that the next script knows what to do...

3. A script that "Removes unfrozen links". This removes links that are not "Frozen" on the current diagram. This is useful when you are creating links on diagrams that you do not want to see on other diagrams.

I have created an open source GitHub repository for these scripts that can be found here:

https://github.com/PaulMadle/EA_Scripts

All scripts are MIT Open source.

I would be interested to find ways of improving the scripts. It would be great if I could trigger scripts on the creation of a connector but I could not find a way of doing that.

I hope you find it useful.

[Paolo F Cantoni]

Hi Paul,

We had a need to "freeze" certain diagrams.  We tried the script route for a couple of weeks (I had some work experience students working on it under my direction).  We eventually gave up as there was insufficient information that could be stored easily and returned by the scripts to cover ALL the scenarios we envisaged.  We now use a snapshot of the repository in the "freezer" which is used to physically restore (by DB queries) the diagram to its previous state regardless of what has been done to it since it was frozen.

We haven't used it in anger since it was created, but the testing we did seemed to show it would work well.

I haven't had a chance to view your scripts yet and will take a look to see if you discovered the "secret sauce" that eluded us.  It may be our definition of freezing was more rigorous than yours.

After we changed over to the freezer snapshot we figured that, conceptually, it was the more appropriate solution for our needs.

Paolo

[Edit:  I like the "secret sauce" of adding the frozen state to the path specification.  However, our definition of "frozen" was more complex and so the scripts aren't enough.  Also, I suspect the scripts may be a bit deficient for all possible arc-related scenarios.  At least we found our script swere, but we used a different method]

[Paul Madle]

Hi Paolo,

Many thanks for the recommendation... A Freezer sounds like an interesting idea... Did you use the XML export type functions to produce your freezer object?

So far the scripts seem to be working for us (all except some performance issues... we migrated to hosting the model as a Firebird DB file on an Azure server using Pro Cloud Server which is slowing things down).

I have already made some changes to speed up the freeze script and will commit them to GitHub once I have done some testing.

Many thanks,

Paul.

 

[Paolo F Cantoni]

Hi Paolo,

Many thanks for the recommendation... A Freezer sounds like an interesting idea... Did you use the XML export type functions to produce your freezer object?

[SNIP]

No, we use Project transfer to create a snapshot .eapx file we then use MS Access linked tables to look simultaneously at the Current repository and the frozen one.  Simple SQL queries make the necessary changes.  We can also determine what changes have been made to the "Frozen" diagrams.

Paolo