IDEA: Control of connector display

[Paolo F Cantoni]

OK.

In your suggestion, you can describe
[  ] Automatically add all possible connectors
as
[  ] Automatically add all possible connectors to this diagram

(at least in help file)

Hi Peter,

I told I hadn't explained myself well enough...  

Diagram section of Tools|Options:
[X] Automatically add connectors to all applicable diagrams (unless otherwise directed)

In diagram "B"'s properties:
[  ] Automatically add all possible connectors to this diagram[/b]
[X] By default do not add connectors

Correct?
Paolo

[peter.zrnko]

OK. Correct.

What about Sparxians? What do yoy think about this analytical excercise?

[Eve]

My personal opinion is that you're getting close to a very useable solution, but I would suggest a further amendment.

At the Model level.  (Diagram or Links section of Tools | Options)
[ ] Prompt for diagrams to add new connectors to

In Diagram "B"'s properties:
[X] Add new connectors to this diagram.

If the prompt option is checked (not by default to preserve existing functionality) then a comes up to ask what diagrams to add the connector to.  The dialog would then be filled with the appropriate values based on the checkboxes for the relevant diagrams.

If the prompt option is cleared then the behaviour is exactly the same as if the user confirmed the defaults in the dialog.

As far as I can see these two checkboxes provide the full functionality of any of the suggestions above, there is no negative phrasing (as there was still one in the example above) while also allowing connectors not to be added without a prompt.

[sargasso]

(cough, cough... ahem!)
cuse me for butting in here, but as I have said elsewhere ¨ijus are people too¨
To me, ( the problem is simple.  If I change a property of a structural element, that change is (and should be) reflected in all visualisations of that element.  If I change a diagramatic aspect of a ¨nurd or ije" it should just be reflected in the current diagram.
Adding a ¨nurd" to a diagram doesn´t automatically add the same nurd to all other diagrams in the model (or some subset of the model) So why should adding an ¨ije¨ do so?
a) because some ijes are structural/behavioural and some aint.
b) because we aint reilsed that yet!!!

If diagram A and B contain nurds X and Y, and I add an ije betwooks X and Y that is structural or behavioural, then I am changing the nature of both the elements and their interelationships.  If, OTOH, I add an ije that does not implicitly or explicitly change the composition of either nurd, for example an ¨ïnformation flow¨ ije, then that modelling information token is of use an interest to only the current diagram.

(sorry, I´ll shut up now)

bruce

[Paolo F Cantoni]

(cough, cough... ahem!)
cuse me for butting in here, but as I have said elsewhere ¨ijes are people too¨

So you were on the sauce while you were away???  

To me, ( the problem is simple.  If I change a property of a structural element, that change is (and should be) reflected in all visualisations of that element.

Well that's not true...  Whether or not a feature of a nurd is rendered on a given diagram is a function of both the diagram's properties and the Set Feature Visibility within those broad parameters.  That is, a "pull" paradigm.

 If I change a diagrammatic aspect of a ¨nurd or ije" it should just be reflected in the current diagram.

By that you mean routing or appearance (for that diagram).

Adding a ¨nurd" to a diagram doesn´t automatically add the same nurd to all other diagrams in the model (or some subset of the model) So why should adding an ¨ije¨ do so?
a) because some ijes are structural/behavioural and some ain't.
b) because we ain't realised that yet!!!

Because...
a) That's the current behaviour - add a nurd and all it's ijes are added...
b) ijes can be people too and the diagram can exert a "pull" paradigm on them also...

If diagram A and B contain nurds X and Y, and I add an ije betwooks X and Y that is structural or behavioural, then I am changing the nature of both the elements and their interrelationships.  If, OTOH, I add an ije that does not implicitly or explicitly change the composition of either nurd, for example an ¨information flow¨ ije, then that modelling information token is of use an interest to only the current diagram.

Says who?

(sorry, I´ll shut up now)
bruce

By the way, as I hinted above, I'm not proposing to change the current behaviour that when you add a nurd to the diagram, all it's ijes are added...

Paolo

[sargasso]

Aye, and there be the knot (knut?)
I am proposing that the current behaviour be changed.  Some many moons ago I said the diagram is not the model, reality is the model and a diagram is some aspect/facet/viewpoint of it.  The EA model (to me at least,) is the ¨repository¨.  I want to make many, many diagrams that ellicit some salient aspect of ¨ye truth¨ as, sic, truth! Within that metaphore (truthe and ye realitie), aspects of non-code-genyration consideration (non-structural/non-beavioural, yet  somehow informationally significant)  still yet need to be displayed - locally!
Let me emphasize,   the diagram is not the model.  
If I walk up to a whiteboard and draw a UML diagram of something I am trying to explain, the only things I´ll draw are those things pertinent to the current conversation.  If, and only if, the ensuing argument ellicits some pertinent an agreed outcome (ye nurd X shall ellicité ye behaviour Y under constrainte Z), then and only then shall such agreement be included in my model.
After many hours of deliberation and many printings of the old trusty whiteboard, we hopefully have a structural and behavioural conclusion.  To me, EA is that whiteboard, that is the metaphore and tool I work with.  I may produce 20 or 30 diagrams in a day that are trying to ellicit some aspect of the system, at any level of abstraction.  Some are useful, some are not.  Those that are, and quite a few of those that are not, are retained.   Consider an architecture report, it discussed the alternatives to the solution and recommmends some optimals. Any such optimal may be conditional on many different value points, and it is up to the adopters to decide the outcome.  I say EA has exactly the same value. It is a tool that lets me draft, cast and evaluate alternatives. Once they have been evaluated then we can take the irrevocable step towards casting them in stone as a design - or, to get back to my point including structural and/or behavioural decisions on the model.
I am becoming a bit dismayed that an excellent modelling tool, has of late (and wherefore I know not) seem to be becoming a (YUK!) CASE tool.

mtfbwy
Bruce (sic)

[Paolo F Cantoni]

bruce,

I think we're in broad agreement on a number of things...

If you look back on my original post for this topic, I argued that the current behaviour aught to be changeable.  I'm just cognizant that we also need to be able (by default) to preserve the current behaviour (unless the proposed behaviour is so obviously better that the hordes will cheer when Sparx produce the new default).  This is the principle of least astonishment - which we've both in the past accused Sparx of violating...

Also, we agree that the diagram is not the model.  But it is a view into the model.   Again, from my first post, I'm saying that if I decide what I want to see in any given diagram (that is, the view this diagram is presenting), I don't want EA to muck it up for me by using the current default behaviour.  In particular, we are already stereotyping our diagrams to tell our automata how to maintain them - consequently we don't want EA's (current) behaviour to create additional work for us.

I think, madame, that we've determined what you are, we're just arguing the price...   (GBS)

Paolo

[darren.sampson]

The current default behaviour (as of 6.5 802) is getting up my nose very fast.

I have a set of class diagrams that have been reviewed, and I'm adding some extra diagrams to show traceability between the classes and the components.  This involves adding links between classes and sub-classes nested in the classes.

These new links show in the reviewed diagrams which I have not touched

These reviews are in preparation for a formal EN50128 software audit.  The changes in the diagrams are unlikely to go down well with the auditor!

Please, pretty please fix this annoying feature!!

As has been said:

Also, we agree that the diagram is not the model.  But it is a view into the model.   Again, from my first post, I'm saying that if I decide what I want to see in any given diagram (that is, the view this diagram is presenting), I don't want EA to muck it up for me by using the current default behaviour.

Stop mucking up my diagrams.  Please!!

Darren