clarify intended practice for relating elements

[bockfu]

what is the intended practice for modeling different perspectives of the same entity?  

For example, what I have done is define a UML class element and specify associations and attributes.   Then if I want to show its connections to other elements, create an UML Component diagram.   Again, add provides/requires interface and other connections.

I would think there should be a way to associate the two elements if they are modeling the same entity.   The rationale is to have consistent names, reconcile and leverage each elements associations and attributes.    I haven't come across a way to do this.  

Anyone have pointers here?  

[Geert Bellekens]

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.

Geert

[bockfu]

Geert - I concur.  I am trying to learn what the common practice is when modeling a system.  

Contrasting your response to the example shared here
http://stackoverflow.com/questions/17390049/component-diagram-versus-class-diagram, I'll infer that the model shall avoid duplicate elements of different types.  Class elements may relate to component elements, but they are different elements, and used to model different structural aspects of the system.

[qwerty]

Despite the title the upper diagram is not a component diagram but a set of notes.

q.

[Eve]

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.

The UML specification disagrees with you on this and defines the Trace connector for this situation.

Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models. Traces are mainly used for tracking requirements and changes across models. As model changes can occur in both directions, the directionality of the dependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and is usually informal.

It's still preferable to avoid if possible, but there are circumstances where it is appropriate.

[Glassboy]

Despite the title the upper diagram is not a component diagram but a set of notes.

q.

I agree, that's a horrible example.

[qwerty]

@Simon: It say "same concept in different models". But here we have one model (aka repository). And inside one model there is only one representation of a concept. Else it would be ambiguous or contradicting.

q.

[Glassboy]

You can have multiple models in one repository.  

The usefulness of your model will be severally hampered if everyone starts "borrowing" one of your elements and using it elsewhere, rather than copying it and tracing back to it.  Imagine the garbage a project that fails could create in an otherwise good reflection of reality :-)

[Paolo F Cantoni]

You can have multiple models in one repository.  

The usefulness of your model will be severally hampered if everyone starts "borrowing" one of your elements and using it elsewhere, rather than copying it and tracing back to it.  Imagine the garbage a project that fails could create in an otherwise good reflection of reality :-)

Well if the model is a "good reflection of reality", then it should survive the project failure.

When you are building a common repository, you want people to "borrow" the common item.  But you also need to control changes to the common item.  We've implemented the notion of doppelgangers which are duplicates of the common item in each project and we control how changes at either end are disseminated.  Technically, you can argue that they are «traces», but it is much stronger than that.  Automation keeps things in line behind the scenes.

Paolo

[Geert Bellekens]

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.

The UML specification disagrees with you on this and defines the Trace connector for this situation.

Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models. Traces are mainly used for tracking requirements and changes across models. As model changes can occur in both directions, the directionality of the dependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and is usually informal.

It's still preferable to avoid if possible, but there are circumstances where it is appropriate.

Simon,

It's not because you CAN that you SHOULD.

I was not stating that it was against UML syntax, I was merely stating a best practice.

Geert

[bockfu]

my original question has been answered, thank you all for the dialog.  Here is a summary as I see it:

• The trace association can be used to relate elements to one another.  Rationale from OMG UML spec Traces are mainly used for tracking requirements and changes across models.
  
• Multiple elements modeling the same entity should be avoided.  Rationale is the different element types are intended to model different aspects of the system.  The intention of the model can be unclear and have added complexity if two elements are representing the same thing.

Background
I have been using EA for several years, but rarely in a multi-user usage model.  A team of us will start using a common model and I am investigating what guard rails we should apply for how we work.

I found I had used class diagrams to illustrate the types of widgets via specialization/generalization, and component diagrams for how the widgets interface with one another.    This didn't seem right and I wanted to get input from other UML practitioners.

[bockfu]

Despite the title the upper diagram is not a component diagram but a set of notes.

q.

I agree, that's a horrible example.

This example from OMG UML spec 2.5 (document number formal/15-03-01) is both more illustrative then the first example and better representation of what might be found in a component diagram.

[Geert Bellekens]

I think you should not read too much in the type of diagram.
Whether you call it a component diagram, or a class diagram really doesn't play a role.

What does play is what you show on those diagrams. In the example from the UML specs above it is still only showing classes and interfaces.

Geert

[qwerty]

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

q.

[Glassboy]

You can have multiple models in one repository.  

The usefulness of your model will be severally hampered if everyone starts "borrowing" one of your elements and using it elsewhere, rather than copying it and tracing back to it.  Imagine the garbage a project that fails could create in an otherwise good reflection of reality :-)

Well if the model is a "good reflection of reality", then it should survive the project failure.

When you are building a common repository, you want people to "borrow" the common item.  But you also need to control changes to the common item.  We've implemented the notion of doppelgangers which are duplicates of the common item in each project and we control how changes at either end are disseminated.  Technically, you can argue that they are «traces», but it is much stronger than that.  Automation keeps things in line behind the scenes.

Paolo

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.