Multiple instance of same element in diagram

[svr.wi.usa]

I am trying to add multiple instance of "device" element to represent servers. However, EA 8.0 restricts to allowing only 1 instance of an element.

Is it possible to support multiple instance of an element in such cases?

Not sure why such a restriction is in place? Is the intent to actually create multiple elements in the model instead of showing instances in the view?

[qwerty]

Has been asked for many year. Unlikely it will appear as feature in a "near" future.

q.

[skiwi]

Indeed it has been asked for,
but do put in a feature request for the feature
and is available in similar tools such as PowerDesigner
(where duplicates are named as "Object:1" "Object:2", very handy for data modelling)

[Paolo F Cantoni]

Indeed it has been asked for,
but do put in a feature request for the feature
and is available in similar tools such as PowerDesigner
(where duplicates are named as "Object:1" "Object"2, very handy for data modelling)

As I see it, the major stumbling block is determining which instance gets which copy of which link to other objects.
Say Table1 has three FK links (to take your Data Modelling example) to three other tables: Tables 2,3&4.  If all four tables are on the diagram, it's easy, you have just three links.
If you add another Table1 (Table1:2), does it get any links?  If not, then suppose I now have two Table1's (Table1:1 and Table1:2) and on another diagram I add a new FK between Table1 and Table3.  When I switch back to the first diagram which instance gets the new link?

Just interested in how PowerDesigner solved the problem.

TIA,
Paolo

[svr.wi.usa]

Again why should this restriction be imposed on "Deployment View"?

I have a Window Server and a AIX server on which the same instance of a JEE app is installed...

There is no way to show the same JEE app on these 2 servers unless ofcourse i create two "Component" elements and name them App (1) and App (2), but again that is what the separation of View and Model is supposed to offer... i dont need to have 2 elements of the same type and of the same name but just called (1), (2).

[svr.wi.usa]

Submitted the request...lets see what happens.

[Paolo F Cantoni]

Again why should this restriction be imposed on "Deployment View"?

It's not, ALL views are so restricted...

I have a Window Server and a AIX server on which the same instance of a JEE app is installed...

Don't you have two copies of the same app deployed to the two servers?

There is no way to show the same JEE app on these 2 servers unless of course i create two "Component" elements and name them App (1) and App (2), but again that is what the separation of View and Model is supposed to offer... i don't need to have 2 elements of the same type and of the same name but just called (1), (2).

I think you may be conflating two different ideas...  (I'm not sure - just  think so.  So I'd be interested in the discussion about the "same" app being deployed to two different servers...)
I've had similar arguments/discussions with myself and others about the correct way to model similar concepts...

Paolo

[Sunshine]

As far as I'm concerned you can already create multiple instances on the same diagram. For example I create a set of nodes that represents web, application and database servers which define the types of servers and then using the ctrl key, drag the nodes from the explorer onto the diagram. I'm then prompted for a link or instance and choose instance. The instance of the web server could be for development, test or production. Can do the same with other types of elements such as components etc.

[qwerty]

That's a different pair of shoes (like we say in Germany). Ctrl-drag creates new instances being different elements. What had been asked was to place the same element more than once on a diagram.

q.

[Paolo F Cantoni]

[size=18]...[/size]What had been asked was to place the same element more than once on a diagram.

Which CAN be done with automation; but, as I said initially, you get duplicated links...

Paolo

[qwerty]

Which CAN be done with automation

Yes, but Sparx explicitly say that this is a bug...

q.

[Sunshine]

That's a different pair of shoes (like we say in Germany). Ctrl-drag creates new instances being different elements. What had been asked was to place the same element more than once on a diagram.

q.

Yes but if you read the other posts it appears there is some confusion on terminology and modelling the problem. The English Language can be so confusing even to native speakers.

I have a Window Server and a AIX server on which the same instance of a JEE app is installed...
q.

In actual fact you need two instances of the JEE app deployed, one on the AIX System and the other on the Windows System. The two instances refer to the JEE Application. The reason for this is they have independent lifecycles. i.e. one instanced can be created and destroyed independent of the other.

[Paolo F Cantoni]

[size=18]...[/size]

I have a Window Server and a AIX server on which the same instance of a JEE app is installed...
q.

In actual fact you need two instances of the JEE app deployed, one on the AIX System and the other on the Windows System. The two instances refer to the JEE Application. The reason for this is they have independent lifecycles. i.e. one instanced can be created and destroyed independent of the other.

My initial point exactly...

And you're right about language...
Nearly forty years ago, a somewhat obscure French Informatics professor Jean Raymond Abrial (who taught Bertrand Meyer of Eiffel fame and who got me started on the modelling "lark") said (in paraphrase):  "The reason we can't build systems that work properly is that we can't unambiguously tell each other what is required."

Forty years later, the reason were can't build systems that work is...

Paolo

[qwerty]

Yes. It's all about communication. UML was invented to help here. But it helps only those which already are able to communicate "naturally".

q.

[Paolo F Cantoni]

Yes. It's all about communication. UML was invented to help here. But it helps only those which already are able to communicate "naturally".

q.

Actually, with its formalism and graphical nature, I believe UML can help those who aren't able to communicate so well.

• Firstly, it allows the recipient to spot "rubbish" in the transmission more easily than natural language.
• Secondly, it is amenable to various automated checks before transmission or after reception of the "message".
• Thirdly, it can be used to educate the parties when such errors are generated and detected so that they improve their abilities.

But it all comes down to rigor...

Being rigorous in your specification makes it easier to build systems that work.  (and before I get flamed, rigor and agile are NOT incompatible).

My AU$0.05
Paolo