Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: bergst on July 12, 2017, 10:44:53 pm
-
I am trying to place the same element second time in diagram. It is not possible and i get following message:
This diagram already contains an instance of the element you are trying to paste.
Currently, only one instance is supported, so you cannot paste the element here.
Is there a way to solve this problem?
Many thanks
-
You could use virtualized connectors. This will place a "ghost element" on the diagram. Otherwise I'd recommend to not place the same element twice on a diagram as it introduces an ambiguity.
To create such a connector use the context menu of the connector.
q.
-
Perfect, that sounds like a good solution.
But there is one special case:
I created a Block-Diagram including Blocks and Ports. Now it is possible to use these Blocks in an other Block-Diagram, while it is not possible to use these Ports in an other Block-Diagram.
Is there a reason for this behavior? Or is there a workaround for this problem?
Many Thanks!
-
Well, I have no idea. You probably need to experiment with that. Honestly, I never ever use those ghost elements (see above).
q.
-
The fact that you have this problem usually indicates that you are doing something wrong.
It may be that you need instances instead of classifiers, or...
Anyway, figure out what you are doing wrong and the problem goes away.
I've never had the need to put the same element on a diagram twice.
Geert
-
Your basic assumption is incorrect- Items being defined in EA are primarily "types" of items.
So eg. for deployments you can define a device named "router" which specifies certain attributes and behavior. However in complex environments you will certainly want to place several of these on the deployment diagram which, however, are instances of the router type you just defined.
The same applies for class diagrams. Modeling scenarios with eg. multiple credit cards the solution is not to put the credit card class multiple times on the panel but use instance objects instead.
Different example: On some occasions I had component diagrams which went too complex with all these connectors so this might lead to the temptation to have the same component being placed left and right on the diagram to clean up the mess. However this would lead to massive confusion. Therefore the correct approach here would either be to clean up the connectors mess or split the diagran in several parts with a compound component as the basis- This basically is what Geert was refering too- the problem here is lying in the way modeling is performed, not in restrictions of the tool. Often it is really better to think out of the box and improve overview and modularity instead of approaching problem with a hammer ;)
Oliver
-
To follow on from Oliver's comments. Sometimes rather than one element being used multiple times, you actually have another element that is realising the first element.
-
The same applies for class diagrams. Modeling scenarios with eg. multiple credit cards the solution is not to put the credit card class multiple times on the panel but use instance objects instead.
Which basically means that one tries to show behavior in a static view. No matter how, the same element more than once on a diagram indicates a design flaw. Or a double crossed mind.
q.
-
But lets imagine the following UseCase:
I am designing an electronic device in a block-diagram and every interface of this device is modeled by a port, e.g. UDC_out = 3,3V.
Now imagine following steps:
1. I create 5 diagrams, each diagram for an other electronic device
2. Every diagram/ every device needs an UDC_out
3. I am creating 5 ports, one for each diagram, to use these in my model.
4. Each of these ports has the same meaning
5. I put a desctiption under the "notes"-field
Problem 1: I create a new diagram and i have to create a port again.
Problem 2: If i put a description for the port UDC_out under the "notes" and i want to change this description, i have to do this 5 times.
Wouldn´t it be easier, if i could create a port once and then use instances of this port as i can do it with other elements?
Thanks for help!
-
This more sounds like you use instances (concrete elements). You can create as many instances as you like and place them in a single diagram.
q.
-
"This more sounds like you use instances (concrete elements). You can create as many instances as you like and place them in a single diagram."
--> But i can´t create instances from ports, right?
I get following message:
"When dropping embedded elements (Ports, Object Nodes, etc.) on to a diagram, you must drop them on their correct owner."
-
You need to drag the port owner to create the instance. You can not instantiate a port solo. The owner has the port in its Structural Elements.
q.
-
You could use virtualized connectors. This will place a "ghost element" on the diagram. Otherwise I'd recommend to not place the same element twice on a diagram as it introduces an ambiguity.
To create such a connector use the context menu of the connector.
q.
Why should I not be able to place two workstation Wintel devices and Web Browser execution environment in each?? Plus a bunch of Tab execution environments in each of these execution environments. Sparx again failed to grasp the essence of UML
-
Why should I not be able to place two workstation Wintel devices and Web Browser execution environment in each?? Plus a bunch of Tab execution environments in each of these execution environments. Sparx again failed to grasp the essence of UML
Sounds like what you are wanting is to place two instances, not the classifier.
The advice that same element multiple times introduces ambiguity is about the classifier, and the confusion you're demonstrating makes me glad that EA doesn't allow it.
PS. The comment that you are quoting isn't from a Sparx representative.
-
Definitely XD
q.
-
I know this is an old thread but really - please change the message that pops up rather than maing folks raising it feel stupid.
Im frustrated by virtualizing connector ends as a very clunky work around because it doesnt work in reality - its not the answer to a situation where you want to show that an element is duplicated for convenience on a diagram to help the reader of the diagram know that there a relationship to an item that exists more than once on the diagram. We cant all work in nice small packages sometime we have to show the bigger picture (literally).
Whats wrong with "use virtualised connectors" as an answer?
Ok - heres some stuff that shows its not thought out.
The "ghost" shape that gets created is not able to be changed in appearance - its just a visual adornment on the connector really - in fact when you look at it it is still a connector
You cant find the other end that is virtualised (no jump to...);
the fact its a "ghost" is not always visible (depends on the elemnt type so in archimate sparx try to show it by tweaking the embedded icon but of course this doesnt work for elements tha dont have this like dataobject;).
If you associate something with the ghost it hasnt associated it with the "real" element - so thats a bear pit - because you have actually associated your element with a connector not another element.
And also in archimate the whole argument about element type and instance fails (I agree with it but it doesnt help the enterprise architect who wants to represent element that it right over the other side of their diagram).
Heck in 1997 we had SSADM tools like Popkin System Architect that simply stuffed an asterisk or diagonal slash in the corner for you so you know it was a visual duplication *for convenience*).
Small rant over but Sparx you do have a habit of making your arguments based on some peculiar logic that might be sensible for certain context (eg class diagram) but doesnt work for archimate - at least remove "currently" from the error dialogue that appears and stop making us think you are doing something to address what is a basic constraint of your underpinning relational data model.
-
The UML specs actually does not forbid the multiple use of elements. But it uses that only in exceptional cases (namely for generalization). The issue might be that UML does not have a real concept to show a virtual copy, so your asterisk suggestion should go to OMG, not Sparx. Personally I never had the need for multiple occurence of the same element. And I never used those virtual connectors (since honestly they are just a mess). Instead of having elements appear multiply I use different diagrams. And when needed (for the big picture) I make a tapestry of multiple smaller diagrams. Much better to handle and still helps giving an overview.
q.
-
Technically there not much stopping you adding multiple copies of the same element on a diagram.
I remember doing that (as a test) using a little script.
I still can't figure out why they went to all these lengths to figure out another "solution" with the virtualized connector ends when simply allowing it seemed the obvious solution.
Geert
-
Please, no. I also fiddled with that API way. And although it gives you multiple copies of the same element you will start pulling out your hairs when you have connectors with them. Alas, I concur with you finding the "alternative" even stranger.
q.
-
I have previously suggested a (to my mind relatively simple) solution to the problem in the thread: Real t_diagramobjects for Virtual Connector Ends - please, please, please? (https://sparxsystems.com/forums/smf/index.php/topic,43103.msg255757.html#msg255757) over two years ago.
I have seen no indication that this would not solve the various issues surrounding the multiple use of elements in diagrams.
Thoughts?
Paolo
Paolo