When you have a diagram, even if completely locked so no-one can edit it, if you create a new connector in another diagram, EA will add the connector to all the diagrams on which the two end elements are to be found. Now this is part of the notion of a "model" - you change something somewhere, it changes everywhere.
This is theoretically fine, but in practice - at enterprise scale - it can create havoc!
The purpose of the locking function is to stop users (or even maliciously) altering diagrams. In fact, the options are disabled. However, it doesn't (not, I would argue, necessarily) should it stop EA from making changes based on the underlying model changes.
Now as I indicated above, in many enterprise scale circumstances (and, indeed, many others) it may be the case that there are diagrams which need to be "frozen" in a certain state. For example, they may have been used to snapshot into a document.
See how I used the term frozen rather than locked? Freezing could be used to control EA's changes tot he diagram.
Now, whether a connector is to be visible on a diagram is a property of the diagram (so to speak) not the connector (as we know, it's actually a property of the diagram link row). So it seems to me that for a given diagram, once the user has decided which connectors will be visible, Freezing the diagram should tell EA NOT to make any new connectors (that could theoretically be) visible on the diagram.
Ok, this is simple to say, but how to achieve? Well, it's actually quite easy. Since the surrogate key (SK) of the connector (Connector_ID) is a monotonically increasing value, if the frozen property holds the highest SK of the connectors on the diagram, any connectors with SKs higher than that MUST be new and therefore should be placed on the diagram and HIDDEN!
Should the user want to unfreeze the diagram, they can do so and make any changes to the visible/invisible connectors currently defined (using the Set Visible Relations [Alt+I]). Unfreezing discards the recorded SK value and allows future new connectors to be added to the diagram. Re-freezing at a later time will go round the loop again.
We have users complaining frequently about the current (less than helpful behaviour, for our purposes) and will be implementing this functionality (awaiting, hopefully, Sparx's implementation).
Before we implement, though, I'd like thoughts and comments to make sure I've thought it through and, if there's support, putting the proposal to Sparx.
Thoughts?
Paolo
