Diagrams as first class citizens of Repository

[Geert Bellekens]

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

[MagnusH]

Geert,

I'll give it a try and post a change request and see if the consider it.

Thanks,
Magnus

[qwerty]

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...

[sargasso]

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  

[sargasso]

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

[DanG83616]

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

[sbaldrick]

@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 ..  

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.

 

[DanG83616]

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.

[sbaldrick]

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.

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  ]

[qwerty]

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

[Paolo F Cantoni]

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

[qwerty]

I probably forgot to emphasize the ironical aspect of my post.

q

[sargasso]

OMG, I am definitely in here.

Object oriented modeling, then aspect oriented modeling and now IRONY ORIENTED modeling.  More, more, now!
 

[qwerty]

Your new signature is nice. Have you asked Paul to translate it into Latin?

q

[sargasso]

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?