clarify intended practice for relating elements

[Paolo F Cantoni]

[size=14][SNIP][/size]
Well let me phrase, you want someone to borrow you don't want them to steal or convert.  You also don't want anything that you use that element for to be suddenly broken.  In EA any documentation that uses connectors is generally the first thing to suffer.

Yes, I think you've got it.  However, while your observation that any "documentation" using connectors is the first thing to suffer is valid - we decided that not only did we need doppelganger items, but doppelganger relationships.  That way your "borrowed" copy could be altered by you, whereas our original master could only be changed by us.

Obviously, you need automation to assist, but it doesn't seem too hard and so far it's working OK.

Paolo

[bockfu]

http://www.uml-diagrams.org/component-diagrams.html

q.

thank you @qwerty, that site has a good mix of the spec mixed with examples  and commentary.   Still ramping on the UML spec and trying to apply UML correctly, so all the tips help.  

@Geert you stated:

If you have two elements representing the same thing than you have one too many.

You should only ever have one element to represent one (aspect of a) thing.

Arn't there exceptions, for example, you may have an Actor and a component element with the same name.  The actor would be used in a Use Case Diagram and Component in Component diagrams.

[qwerty]

you may have an Actor and a component element with the same name.  The actor would be used in a Use Case Diagram and Component in Component diagrams.

So they are different elements. The name is one part of the identity. The (meta)type is the second part.

q.