Diagrams as first class citizens of Repository

[Paolo F Cantoni]

Elsewhere, I'm mentioned we're investigating self organizing diagrams.

One big problem standing in the way of achieving this is that a Diagram and its constituents aren't first class citizens of the EA ecosystem.

You can't apply any metadata (such as Tagged Values) to the Diagram itself, nor to the DiagramObject or DiagramLink.

Obviously this would be a significant change to the EA architecture, but I don't believe it would be too hard.

Before I submit a formal Feature Request to Sparx, I thought I'd gauge support via this topic and also investigate any issues and suggestions - especially for work-arounds in the interim.  We have one for applying Tagged Values to Diagrams, but that mechanism won't work for the other two constituents.

TIA,
Paolo

[Geert Bellekens]

Maybe, when they are refactoring the diagram part of EA anyway they might as well allow multiple representations of the same element on a diagram.
Something I've been asking for for ages.

Geert

[Paolo F Cantoni]

Maybe, when they are refactoring the diagram part of EA anyway they might as well allow multiple representations of the same element on a diagram.
Something I've been asking for for ages.

Geert

With the automation interface, you CAN get more than one copy of an element on a diagram.  I've done it unintentionally a couple of times while writing code.

The REAL problem is how to restrict WHICH relationships to WHICH instance....

Paolo

[Geert Bellekens]

True, I've had that happen to me as wel, but I consider the fact that that is possible more as a bug then a feature.
The thing is that the design of the diagrams and their DiagramObject and DiagramLinks is based on the fact that there is only one diagramObject per element on a diagram.

Geert

[Paolo F Cantoni]

Some modelling products (Such as Embarcadero ER/Studio) allow you to customize the appearance of individual Features (Attributes and Operations - though in ERS' case this is basically table Columns) within an Element.

In order to do this, I guess, as a minimum, we need: DiagramAttributes and DiagramOperations to exist and also become first class citizens.

I really miss the ability to customize the appearance of individual features.

Thoughts?
Paolo

[«Midnight»]

So do I...

[Oliver F.]

Maybe, when they are refactoring the diagram part of EA anyway they might as well allow multiple representations of the same element on a diagram.
Something I've been asking for for ages.

And something I have been opposing against for a while. The reason why people might want this is related to diagram layout, not model. This feature does not bring more information to the model but adds confusion, because to do it right you will have to limit the number of connections for all appearances, otherwise the diagram will drift towards spaghetti. And if you do this you loose the ability to overview all aspects of an element because the element identity is divided across the diagram making it easy to overlook things.

So my vote is a clear "no"  8-)

Oliver

[«Midnight»]

OK, I'll try to make my views clearer. [But not too clear; I am still on the fence about some facets of this discussion.]

I would definitely like to see diagrams 'promoted' to first class status. IMO that would not (and should not) be done by bending the UML concepts of diagrams and elements. It should be possible to make this work though.

I also agree with Geert. UML carefully constrains us here. The idea is not to model entire systems on a single diagram, but to develop a hierarchical decomposition of the entire system using as many (or few) diagrams as required. [Or something along those lines, by one name or another. The wording is my own; I do not mean to suggest this as the 'official' UML take. See the specification and other OML documents for that.]

What I would find reasonable is to allow relaxing the multiple element rule as an option. This might be along the same lines as clearing the Strict UML option. But I'd like to see it as a separate option, so that uniqueness would still be enforced (by default) even if string UML were not.

[Geert Bellekens]

Maybe, when they are refactoring the diagram part of EA anyway they might as well allow multiple representations of the same element on a diagram.
Something I've been asking for for ages.

And something I have been opposing against for a while. The reason why people might want this is related to diagram layout, not model. This feature does not bring more information to the model but adds confusion, because to do it right you will have to limit the number of connections for all appearances, otherwise the diagram will drift towards spaghetti. And if you do this you loose the ability to overview all aspects of an element because the element identity is divided across the diagram making it easy to overlook things.

So my vote is a clear "no"  8-)

Oliver

I see your point. Actually the main reason why I wanted to be able to put an element on a diagram more then once were the Activity diagrams.
I'll try to explain: suppose you have 4 activities: act1,act2,act3 and act4
You start with a decision going to act1 or act2.
From both act1 as act2 you go to act3. And then you go to act4 only if the first step was act1.
The only elegant way I saw to model this was to draw act3 twice on the diagram, once continuing to act4, and the other time not.

But now, in the light of the recent discussions I think I found the solution for this with the Actions. Instead of modelling a series of activities I can model two different actions that execute the same activity. Those Actions can then have different transitions; problem solved.

But I still think EA should allow to put an element on a diagram more then once. A warning might be in place, or even an option to allow/disallow this. I just don't like the fact that the tool limits me in how I want to model UML. I have a hard enough time trying to follow all the UML rules as is. (and no AFAIK it is not against UML rules to allow multiple representations of an element on a diagram)

Geert

[Paolo F Cantoni]

Maybe, when they are refactoring the diagram part of EA anyway they might as well allow multiple representations of the same element on a diagram.
Something I've been asking for for ages.

And something I have been opposing against for a while. The reason why people might want this is related to diagram layout, not model. This feature does not bring more information to the model but adds confusion, because to do it right you will have to limit the number of connections for all appearances, otherwise the diagram will drift toward spaghetti. And if you do this you loose the ability to overview all aspects of an element because the element identity is divided across the diagram making it easy to overlook things.

So my vote is a clear "no"  8-)

Oliver

Whoops... I inadvertently appear to have spread some confusion...  Maybe I've been using EA (and therefore EAUI) for too long - like the slowly cooking frog  )  I've been a bit lax in my terminology.

I'll try to clear up what I'm trying to say.

I SHOULD have said - make Diagrams first class citizens of the Repository.    But because of EAUI that might have been truncated on the post, so I opted for model - bad call!    I've now changed the heading on the topic.

Oliver is, of course, correct saying we should separate modelling from layout  I'm not (nor is Geert or David) suggesting that there should be two model elements on the diagram.  But (sometimes - and particularly given EA's current drawing engines) a case CAN be made for allowing more than one "image" of the same item on the diagram.  The issue, for me, as I said is which connectors go to which image (I assume that each connector would go to only one of the images).

By making Diagram Elements first class citizens of the repository I meant that they should be identifiable, classifiable, and have metadata attached - specific to the element in that diagram.

The issue of diagrams as first-class citizens of a Model is a different argument.  If we want to continue that one we might create a second Topic.

Paolo

[«Midnight»]

I'll share some blame with Paolo here. I too should have been clear that I wanted diagrams to be first class citizens of the repository.

[MagnusH]

Hi,

Would be very happy if I could apply tagged values to the diagram itself. Any reason why not allowing this?

[Geert Bellekens]

Hi,

Would be very happy if I could apply tagged values to the diagram itself. Any reason why not allowing this?

Probably because UML doesn't.
I think Diagram is not a metaclass in UML and therefore it cannot be extended by a stereotype. And since UML superstructure 2.2 states:

In UML 2.0, a
tagged value can only be represented as an attribute defined on a stereotype.

you can't add tagged values to diagrams.

Geert

[Paolo F Cantoni]

Hi,

Would be very happy if I could apply tagged values to the diagram itself. Any reason why not allowing this?

We currently (build 850) use the "trick" of making each diagram have a title block and applying the tagged values to that...

It's KLUDGE, but it works...  Our automata can detect the presence of the title block and use that as the proxy for the diagram.

HTH,
Paolo

[MagnusH]

Thanks,

The trick with the title block could work for us also.

Geert, your comment about stereotypes seems fair but as far as I understand it's possible to apply a stereotype on a diagram. In fact we are using that.

// Magnus