How to depict other dependencies in UML

[gluzm]

Hi,

I created four examples of code and UML model to it.

OwnerEx1 – association
OwnerEx2 – composition

But how to depict the dependencies for the last 2 examples
OwnerEx1 and OwnerEx2

Thanks
Jan

Code: [Select]

namespace UML
{
     /// <summary>
     /// asociation
     /// </summary>
     public class OwnerEx1
     {
           private Owned _owned;
           public OwnerEx1(UML.Owned owned)
           {
                 _owned = owned;
                 
           }
     }
     /// <summary>
     /// composition
     /// </summary>
     public class OwnerEx2
     {
           private Owned _owned;
           public OwnerEx2()
           {
                 _owned = new UML.Owned();
                 
           }
     }
     /// <summary>
     /// ???
     /// </summary>
     public class OwnerEx3
     {
           public OwnerEx3()
           {
                 UML.Owned owned;
                 owned = new UML.Owned();
                 
           }
     }
     /// <summary>
     /// ???
     /// </summary>
     public class OwnerEx4
     {
           public UML.Owned GetOwned()
           {
                 return new UML.Owned();
           }
     }
     public class Owned
     {            

     }
}

[thomaskilian]

Tried to reverse engineer that code?

[gluzm]

Yes the ressult is presented in the diagram
Jan

[gluzm]

Actually what is interesting is that EA did not recognized the composition. I have to change it.
Jan

[angel-o-sphere]

You draw dependencies to Owned with stereotypes like <<returns>> and <<creates>>.

<<returns>> is likely also a creation otherwise you had a reference I guess. If you could attach the dependency on the operation ... <<returns>> would be suiting.

You can invent stereotypes in such situations, its only important that you are consistent and your team agrees with you in their usage.

Instead of <<creates>> in our days <<instanciates>> is used as well, but that one is most of the time used in class to object dependencies.

angel'o'sphere

[gluzm]

Yes thank you, I was thinking that this must be solved by stereotypes.

But then <<returns>> sounds for me also not unambiguously, instance <<returns>> instance (when not static class) so then it will be suitable in object model, but for classes it is misleading.

Actually I can not imagine such code example except static class, my opinion it is not good approach to return something without keeping a reference to it. This is against destruction handling.

But what stereotype to use if the class is instantiated in the method scope?

Jan