Sparx Systems Forum
Enterprise Architect => Suggestions and Requests => Topic started by: Jan Vlcinsky on February 05, 2009, 11:52:59 pm
-
Trying to place the same element second time in diagram results currently (EA 7.1) in alert box telling
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.
I have read annoncement about EA 7.5 beta and wonder, if the possibility for multiple instances in one diagram is going to be here. I did not find there any note about this.
Reasoning: For diagrams with bigger number of elements and more relations one gets into problem, that some relationships would have to cross half of others and result becomes quite cluttered. UML allows to insert another instance of the element (e.g. class) and link related relationships there.
When discussing EA functionality with other power users, they very often mention this problem even without having to name the problem and asking for severity of it.
-
No, it's not in 7.5.
-
And if you ever include it, please make it optional so I can configure EA to work the old way.
I guess I'd use it while documenting the dependencies of legacy code, but it would mean a lot of work. You would have to set the individual visibility of all connectors (and EA would have to save it per diagram and per instance) to make a diagram readable.
For planning and designing purposes I'd rather have a warning when I inadvertently drop an element a second time. And if a diagram gets so complicated I would need second instances, I'd rather stop it, have a cup of coffee, and think up a better structure.
-
Add me to the want list. Even choosing a diagram like Extended->Analysis, which has no restrictions or standards gets you nowhere. So if you have to put together a business, or executive level presentation about business processes you either need to hack up your model with a folder full of 'dupes' or head off to Visio.
-
Add me to the want list. Even choosing a diagram like Extended->Analysis, which has no restrictions or standards gets you nowhere. So if you have to put together a business, or executive level presentation about business processes you either need to hack up your model with a folder full of 'dupes' or head off to Visio.
Be aware that having multiple objects in one diagram breaks the idea behind most UML diagrams. In the systems modeled there is always only one type of an element and everything else is an instance of that type.
Imagine having a complex activity diagram where the same activity is present in multiple branches which would require that both share the same connections. That would make the diagram totally unreadable. If I added a new connector to one it would surely be valid for the second also.
A class is a unique element type as well as a component and a use case is.
If you want to show the same element in several different aspects it is best practice to show this in a separate view (aka diagram) and do a nested/composite model structure. This also applies to business processes and requirements- not only technical UML models.
Oliver
-
Exactly.... If you are creating diagrams that big... then you really need to consider the use of composite features to hide detail or to break the activity into smaller logical parts.
I think you can say that "feature" will not be available until the UML specification would change, and as Oliver states that really would lead to multiple problems... Smaller, Simpler, Clearer... Go team!
David
-
Add me to the want list. Even choosing a diagram like Extended->Analysis, which has no restrictions or standards gets you nowhere. So if you have to put together a business, or executive level presentation about business processes you either need to hack up your model with a folder full of 'dupes' or head off to Visio.
Be aware that having multiple objects in one diagram breaks the idea behind most UML diagrams. In the systems modeled there is always only one type of an element and everything else is an instance of that type.
Imagine having a complex activity diagram where the same activity is present in multiple branches which would require that both share the same connections. That would make the diagram totally unreadable. If I added a new connector to one it would surely be valid for the second also.
A class is a unique element type as well as a component and a use case is.
If you want to show the same element in several different aspects it is best practice to show this in a separate view (aka diagram) and do a nested/composite model structure. This also applies to business processes and requirements- not only technical UML models.
Oliver
Then remove the non-UML model types from EA. I'm talking about flowcharts, and analysis diagrams where you just need to get your artifacts on a diagram to help present a picture of your enterprise to a bunch of executives.
"Analysis Diagrams are simplified Activity diagrams used to describe high-level business processes with less UML formality."
That description (by Sparx) is false, the "Analysis" diagram is held to standards. High-level business process to me means something like "Pay Claim", or even "Claims Processing". If I want to create a diagram showing a landscape of applications (as clouds, borders, or whatever) and I want to show the business process inside them (rather then having lines all over which would imply that they all use the same business processing 'service') I can't. A DFD is another example of a diagram that has no such limitation (or real standards).
-
Then remove the non-UML model types from EA. I'm talking about flowcharts, and analysis diagrams where you just need to get your artifacts on a diagram to help present a picture of your enterprise to a bunch of executives.
Sean, I accept your motivation and see your issue. However the problems of duplicate elements will remain, especially when it comes to connecting elements together, changing appearance, creating references or searching in diagrams. This is regardless the type of elements or diagrams you are creating and I assume that the efforts of implementing a clean solution (touching various aspects in the model and diagram handling) which is satisfactory for most application are rather high not justifying the cause.
Oliver
-
Then remove the non-UML model types from EA. I'm talking about flowcharts, and analysis diagrams where you just need to get your artifacts on a diagram to help present a picture of your enterprise to a bunch of executives.
Sean, I accept your motivation and see your issue. However the problems of duplicate elements will remain, especially when it comes to connecting elements together, changing appearance, creating references or searching in diagrams. This is regardless the type of elements or diagrams you are creating and I assume that the efforts of implementing a clean solution (touching various aspects in the model and diagram handling) which is satisfactory for most application are rather high not justifying the cause.
Oliver
No arguments here, it's a modeling tool not a presentation tool. However as you climb the chain in an organization eventually you need presentations that even numb minded executives with marketing degrees can 'understand'. Visio it is for now.
-
Then remove the non-UML model types from EA. I'm talking about flowcharts, and analysis diagrams where you just need to get your artifacts on a diagram to help present a picture of your enterprise to a bunch of executives.
Sean, I accept your motivation and see your issue. However the problems of duplicate elements will remain, especially when it comes to connecting elements together, changing appearance, creating references or searching in diagrams. This is regardless the type of elements or diagrams you are creating and I assume that the efforts of implementing a clean solution (touching various aspects in the model and diagram handling) which is satisfactory for most application are rather high not justifying the cause.
Oliver
No arguments here, it's a modeling tool not a presentation tool. However as you climb the chain in an organization eventually you need presentations that even numb minded executives with marketing degrees can 'understand'. Visio it is for now.
What if the 'duplicate' was merely a 'ghost' image - not a real component / element - just a replicant that referred back to the single 'real' element?
Even connections from other elements to the 'ghost replicant' would - in terms of the UML model and repository - show up as being connected to the one single 'real' element?
Thinking laterally here ... we need to preserve the integrity of UML - but it would be nice to be able to create simpler presentation material for 'numb minded executives' ;)
-
What if the 'duplicate' was merely a 'ghost' image - not a real component / element - just a replicant that referred back to the single 'real' element?
How would that be different to the (exisiting) "instance of" type? ;)
Oliver
-
What if the 'duplicate' was merely a 'ghost' image - not a real component / element - just a replicant that referred back to the single 'real' element?
How would that be different to the (exisiting) "instance of" type? ;)
Oliver
Not sure, Oliver. But let me use an example to find out what you're referring to.
So if I have a 'Component' element in a busy, large, complex diagram, and it would be really useful to have a copy of the same element on the same diagram just for presentation purposes - with connectors from the copy to certain other components - how can I create an 'instance of' one of the Components and have both on the same diagram?
Or does my question belie my lack of understanding of the nuances of UML?
:-[
-
What if the 'duplicate' was merely a 'ghost' image - not a real component / element - just a replicant that referred back to the single 'real' element?
How would that be different to the (exisiting) "instance of" type? ;)
Oliver
Not sure, Oliver. But let me use an example to find out what you're referring to.
So if I have a 'Component' element in a busy, large, complex diagram, and it would be really useful to have a copy of the same element on the same diagram just for presentation purposes - with connectors from the copy to certain other components - how can I create an 'instance of' one of the Components and have both on the same diagram?
In default configuration you get a dialog to choose whether to drag the element as a link (which you normally do), an instance or a new element. If you have diabled this dialog you can enforce it by dragging and dropping the element from the project browser while holding the Ctrl-Key.
Or does my question belie my lack of understanding of the nuances of UML?
:-[
Not at all.
My proposal was more of some sort of workaround. The "ghost" element you described behaved like an instance- it has the same type but different connectors.
But in fact its meaning in UML is different as the "ghost" element and I believed that it would be valid to be used for business process descriptions as there is no "instance of".
However I would not apply this method to class, component, use case and other UML diagrams because it invalids their meaning and intention.
Oliver
-
Me too!
This is one of the biggest drawbacks I see in EA with regards to other modelling tools.
And for those opposed: nowhere int he UML specs it says that you cannot represent a certain element twice on a diagram. In a lot of cases it would make life a lot easier if we could just add an element more then once on a diagram. It allows to draw a much cleaner diagram without connectors that have to go all over the place.
As an example consider a usecase diagram with say 5 actors and 5 usecases. Now try to make a clean diagram when each actor needs to be connected to at least three (random) usecases.
If we could add the representation of the actor twice on the diagram that would be very easy.
There is in my mind no danger to that. A diagram is just a specific view on the model. It's not because on one representation you only show three links, and on another you show three other links that the actual element in the model doesn't have all six links.
I do believe that it won't be an easy change for the guys from Sparx, since this one-to-one relation between element and diagram is probably hardcoded pretty deep in the application logic (and database)
-
bump
-
I'm with Geert on this one. Having been teaching people EA for a while now, it's about the most common question from new users when they start to use EA diagrams. I, like others above, have mumbled something about 'better style', 'smaller diagrams' etc, which is partly true, but it's a decision I'D like to make, not have EA do for me.
So, Spaxians, please can you look at this for us? Or is it, as Geert suggests, hard-coded?
-
This idea has been suggested many times before.
It gets my vote, but I've given up hoping for it.
-
Can you submit a Feature Request or Bug Report (depending on how you feel about it) so that your request finds its way to the right people? Thanks.
Using this forum to ask Sparx to do something is like telling your next-door-neighbour you wish the council would fix the street lamp. Unless your neighbour is the council officer for raising work orders to fix street lamps, ain't nothing gonna happen!
-
From my point of view, I dont see the need for it. Use more diagrams. Keeping it simple is always better and I expect it would be a real PITA to implement. How would you choose which relationships to apply to the various instances of an element?
-
Then see
Multiple Instances of an Element in a Diagram (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1311769406/0#0)
Multiple instance of same element in diagram (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1301322303/0#0)
Multiple instances of elements (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1068140267/0#0)
Multiple instances of diagram elements (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1054516545/0#0)
Me, I find it really useful for data modelling and ERD diagram to clarify/simplify the layout. (implemented well in PowerDesigner)
Multiple Instances On A Diagram (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1250730910/21#21)
-
Just curious here - what is it about the way EA implements "multiple instances of an element on a diagram" that doesn't meet your needs?
On the rare occassions I need to do this, it works as I'd expect it to.
-
Hi spirax, I think that's a different meaning of the word "instance". If you have a class X, you can have any number of elements classified by X (instances of X), but they are distinct elements. X itself can only appear once on a diagram.
And before anyone asks, I have no information on whether or not we have plans to address this.
-
Feature request made
-
Does that mean there has never been a feature request for this functionality until now ? :o
-
Since none of us users has insight in Sparx' bug tracker we don't have an answer. Except for those having sent a FR formerly. I'm pretty sure there are quite a number of those.
q.
-
Can you submit a Feature Request or Bug Report (depending on how you feel about it) so that your request finds its way to the right people? Thanks.
Using this forum to ask Sparx to do something is like telling your next-door-neighbour you wish the council would fix the street lamp. Unless your neighbour is the council officer for raising work orders to fix street lamps, ain't nothing gonna happen!
Roy
without wanting to diss you (cause we appreciate your being on here) to point being made in this forum is that this request has been made possibly many times directly to Sparx as a feature request.
Graham
I certainly have made a request for this feature at least twice (see earlier post for one of these).
Why do we have to do it again?
Simon
-
Arrr - you got me there. Any one person should only need to submit a Feature Request directly to Sparx once. It possibly isn't a good idea to submit a Feature Request on behalf of several other people, as it obscures the level of demand for the feature. (Unless you link to the forum post and perhaps list a few names and numbers...? Dunno.)
I'm not one of the technical decision makers, so I can't comment on how or why a feature request is selected for implementation. Or not selected. I can only observe that there has been some argument between the users as to whether the feature is necessary or practical, which might reduce the number of actual requests for the feature we have received.