Deprecation warnings

[qwerty]

EA still uses some constructs which were (silently) deprecated in newer Superstructures editions. One example is the Nesting connector (see http://www.uml-diagrams.org/nested-classifier.html; note in the last 3 paragraphs of the section). I think it would be a good idea to have ways getting them out of sight. E.g. marking them somehow in the toolboxes and/or have options to disable deprecated elements/connectors.

q.

[Paolo F Cantoni]

EA still uses some constructs which were (silently) deprecated in newer Superstructures editions. One example is the Nesting connector (see http://www.uml-diagrams.org/nested-classifier.html; note in the last 3 paragraphs of the section). I think it would be a good idea to have ways getting them out of sight. E.g. marking them somehow in the toolboxes and/or have options to disable deprecated elements/connectors.

q.

By all means mark them as deprecated, but please don't get rid of them (as in EA no longer recognising connector_type=Nesting in t-connector).   Just because UML 2.x decided not to have an explicit notation for nesting doesn't mean the conceptual relationship doesn't exist.  We use it in our MDG to separate true "Nesting" from "Visual Embedding".

Paolo

[qwerty]

So you think this should read "OMG! Don't kill my metatypes!"?

q.

[Paolo F Cantoni]

So you think this should read "OMG! Don't kill my metatypes!"?

q.

That's pretty Good!   (and it's only Tuesday!)

Paolo

[qwerty]

The backside of this is that OMG does not read here. Except that Sparx is part of OMG and could influence it (do they?). OMG has some feedback page. I used that twice. The first entry had vanished until someone inside OMG had a look and somehow uncovered my vote. No idea what happened to my 2nd vote. I guess it had the same fate as my first one. This system reminds me heavily of Sparx's bug reporting system. Except that Sparx assigns a number I could refer to.

q.

[Glassboy]

If you depreciate these elements and connectors, what happens to older models which were perfectly valid at the time?

[qwerty]

They are deprecated. That's what you intend by deprecating single parts. You can leave them in the old context as mummies. Or you keep them alive by using other language elements.

q.

[qwerty]

So, how about deprecating the Method property of the Element object in the API and renaming that to Operation?

q.

[adepreter]

We use the nesting connector heavily in our Enterprise Architecture MDG to indicate ownership and to make this visible in the traceability window.

This is very useful e.g. when we want to distinguish the cases where an Application, an Application Component or a Data Store...
- *Owns* Data Objects (golden source)
- *Is composed of* Data Objects (the app, app comp or data store contains the data object bit is not the golden source)

Please don't shoot the nesting connector (even if you remove it from the UML toolboxes). Our MDG and its army of robots changed Sparx into a very competitive EA tool. I will not be able to share things if you change them into dust.

Related feature request: The ability to specify, in an MDG, the verbs appearing in the traceability window (the implementation approach was provided with the request). If you implement this then we would at least be able to compensate any connector type that you would remove. So that would be to the benefits of everyone.

Alain

[Geert Bellekens]

I agree, the nesting connector is useful for visualizing a nesting relation.
I use that very often when visualizing an imported XSD on a diagram. (some relations use nesting, some relations use associations and other relations use the type of attributes )

I know it's redundant, but it makes things visible on the diagram, which for complex XSD's is an absolute must.

Geert