Sparx Systems Forum
Enterprise Architect => Suggestions and Requests => Topic started by: Paolo F Cantoni on August 20, 2009, 11:15:10 am
-
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
-
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
-
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
-
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
-
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
-
So do I...
-
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
-
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.
-
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
-
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
-
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.
-
Hi,
Would be very happy if I could apply tagged values to the diagram itself. Any reason why not allowing this?
-
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
-
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
-
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
-
Magnus,
Yes indeed, i've seen that you can apply a stereotype to a diagram, but that is an EA thing and not UML.
You could ofcourse argue that, since they allow stereotypes on diagrams, they should support tagged values as well.
If you put it like that in a change request they might just implement it.
Geert
-
Geert,
I'll give it a try and post a change request and see if the consider it.
Thanks,
Magnus
-
I guess that diagrams are still 2nd class citizens as I can't see any way to create tagged values for diagrams.
q
P.S. When registering I had to confirm You agree, through your use of this YaBB forum, that you will not post any material which is false, defamatory, inaccurate, abusive, vulgar, hateful, harassing, obscene, profane, sexually-oriented, threatening, invasive of a person's privacy, or otherwise in violation of ANY law.
Does anyone have the law codes for Tuvalu, Somalia and Kanada (to complete my compilation so I'm sure my confirmation is okay...
-
a case CAN be made for allowing more than one "image" of the same item on the diagram.
yes, Yes, YES !!!!
UML has never (in my knowledge) stated that you cannot have the same model element more than once in a diagram. In fact, they have consistently done it themselves over many versions of the spec. What they have said, explicitly, is that any representation of the same element in a diagram "refers to the same damn thing" (my quote).
There is a good point brought out in this discussion. That the diagram could unintentionally become a spiderweb of lines between objects. So, here's a proposal: the first instance of an entity in a diagram becomes the "natural" entity and any other instances become "shadows". However, the modeler should be able to move a link between any diagram instance of the entity an another.
This would allow me to simplify so many diagrams!!!
BUT! The original caveat still applies. If the entity is a classifier, then the shadow objects "shall be" shadows of the classifier, if an object then the shadows shall be shadows of the object entity - not another instance.
The responsibility of the modeler in maintaining the rationality of the diagram is theirs, according to and with UML, not according to certain lifeforms from planet Creswick! :)
(damn ye, ye woke me up agin!)
bruce
-
BTW!
IIRC, I posted a diagram here about a year or more ago showing that you can include in a diagram several "images" that appear, diagrammatically, as the same thing. It's just that EA thinks they are NOT the same thing.
If I recall even more so, two of the diagram images were, in a modelling sense, exactly the same entity. EA didn't think so.
With less recall, I have some belief, that two of the entities were the same thing (according to the the entity UUID) and thus it was possible to (with trickery that I can't remember) actually con EA into having the same entity twice on a diagram.
Can't remember how, when or why. Don't care much anymore.
b
-
Don't schematic capture programs allow the same item to be broken up and shown in convenient places on a single diagram? If you drop a class onto a diagram twice, it still has the same name so it is obviously the same class. Since the diagram is just a visualization of the model I cannot come up with any rationale to limit the number of times one item can appear on a diagram. I vote "yes" for this feature because I have been forced to break up diagrams just to avoid spaghetti strands meandering through a single diagram.
Regarding making diagrams enjoy the rights of elements within the repository, why not create a classifier for that? You could create a classifier that has a tag for referencing a diagram. Along with the diagram tag you could add your other tags. For example, you could have a tag to identify filtering. A transform might then take the original diagram and apply the filtering to produce a specialized rendition. You would be modeling how you want to present your model.
Dan
-
@DanG83616: If you drop a class onto a diagram twice, it still has the same name so it is obviously the same class.
Apparently not, because I am currently looking at 2 Actor classes in the same package with identical names :-?
When teaching diagramming of use cases, I encourage using multiple actors because this makes the diagrams much easier to edit, to manage and to read.
For use cases I consider this feature to be essential, and can imagine no reason for any UML modeling tool to absolutely prevent this, (unless someone let the developers write the requirements ;)).
No other UML tool imposes this restriction, (TTBOMK). Why would they? If worried about spider figures, as a minimum the tool should allow the option to turn off automatically showing relationships.
Although there are no UML restrictions for multiple instances on a diagram, I do believe that element names should be unique, Yet I am able to place 2 instances of separate elements with the same name on the same diagram .. :o
If this is the workaround for my needs .. I am not impressed.
Please fix it so that those of use that wish to encourage 'good' diagramming practices are able to use EA to do this.
:-*
-
sbaldrick,
you should make a formal change request to Sparx and mention that you are training people to create multiple classes with the same name in models just for this purpose. That might get their attention. I shudder to think of trying to manage a model with a bunch of same-named classes in it. :-X
-
sbaldrick,
you should make a formal change request to Sparx and mention that you are training people to create multiple classes with the same name in models just for this purpose. That might get their attention. I shudder to think of trying to manage a model with a bunch of same-named classes in it. :-X
Will do when I figure out how to.
In the meantime, my workaround is to create inheritance trees of classes and show the inherited information where needed.
As mentioned, EA allows children in an inheritance relationship to take the name of their parent, so they all look alike and all I need do is change the parent and all the children inherit that change.
This is especially important on workflow (activity and BPMN) diagrams, which show the data being manipulated by the activities. Although the tool does not allow data flows to classes, I found that I can change the type to 'Object', draw the object flow, then change the type back to 'Class' to display the inherited attributes, and the data flow stays put.
Les.
[Bit like getting the girlfriend into the 'Men-only' club, by dressing her up as a man, getting past the door security and then dressing her back as a woman once inside and no-one notices, because everyone assumes that only men are able to get in.
Makes one wonder - did anyone write requirements before building the tool ;)]
-
Requirements? For whom? From whom? For what purpose? Did Apple write requirements for their iPhone (indeed a good question)? Not trying to say that EA and the iPhone are comparable.
q
-
Requirements? For whom? From whom? For what purpose? Did Apple write requirements for their iPhone (indeed a good question)? Not trying to say that EA and the iPhone are comparable.
q
Hi q,
Every time you take a design/coding decision you are responding to requirements (usually implicit rather than explicit). Unfortunately, these implicit requirements are rarely made explicit (documented) and so later others wonder: WTF?
Paolo
-
I probably forgot to emphasize the ironical aspect of my post.
q
-
OMG, I am definitely in here.
Object oriented modeling, then aspect oriented modeling and now IRONY ORIENTED modeling. More, more, now!
:) :) :)
-
Your new signature is nice. Have you asked Paul to translate it into Latin?
q
-
The signature works exactly according to design. The desings where singed off by the steakholders and all constructibles executed singe that thyme concorde to thje appropriace prequiremints.
Clear, am I myself making?
;)
-
Sure. Don't let the steaks be rotten...
q