1

Suppose I have the following client code:

using System;

namespace InterfaceCompositionUml 
{
   internal class Program
   {
      static void Main(string[] args)
      {      
         MyInterfaceImpl x = new MyInterfaceImpl();
         MyClass y = new MyClass();
         x.MyProperty = y;

         Console.WriteLine(x.MyProperty.A);
      }
   }
}

The implementation of the various components is as follows:

MyClass

using System;

namespace InterfaceCompositionUml 
{
   public class MyClass
   {
      public string A => "Hello";
   }
}

MyInterface

using System;

namespace InterfaceCompositionUml 
{
   interface MyInterface
   {
      MyClass MyProperty { get; set; }
   }
}

MyInterfaceImpl

using System;

namespace InterfaceCompositionUml 
{
   public class MyInterfaceImpl : MyInterface
   {
      public MyClass MyProperty { get; set; }
   }
}

I'm a bit stumped on how to represent the relationship between MyClass and MyInterface/MyInterfaceImpl in a class diagram following the UML 2 standard. There are two options that I can think of. Either MyInterface has an acquaintance with MyClass:

enter image description here

OR MyInterfaceImpl has an acquaintance with MyClass:

enter image description here

Which one is correct and why? If neither are correct then what is the correct representation?

2
  • 2
    The first one, because the interface explicitly mentions the type MyClass. It's explicitly referenced by the interface. The realization (implementation) arrow also means that the implementation class inherits all the members of the interface, and therefore, any relationships. The second diagram would imply that the interface has nothing to do with MyClass (and so, that the MyClass reference is meant to be implementation-specific, and invisible to clients that use MyInterface). Sep 8, 2023 at 18:11
  • @FilipMilovanović: why not putting this comment into an answer, so the OP accept it?
    – Doc Brown
    Sep 9, 2023 at 20:33

1 Answer 1

1

In short

Both diagrams are correct but none of them is complete. The first would nevertheless be the way to go, as it a better insight into the design intention. Indeed, in UML you are not obliged to show everything in a diagram and you are allowed to focus on what you think is more important:

  • Showing the association at the interface level is sufficient: readers can guess the missing but implicit association at interface implementation level (if it wouldn't be there, the interface implementation would not be compliant with the interface).
  • Showing the interface at the implementation level is correct, but readers cannot guess the missing association at interface level, which seems more important for the design (which aims at decoupling the abstraction from the implementation).

(By the way, "aquaintance" is pre-UML terminology and is somewhat confusion. The term "association" should be preferred as it is precisely defined in the ISO and OMG official specifications.)

All the details

In your design there is an association between MyInterface and MyClass, and MyInterfaceImpl realises the interface. This can be shortly expressed as:

enter image description here

Considering that the property ensures efficient navigation at runtime between instances of MyInterface to their linked instances of MyClass, you can show the association as navigable, using an open arrow head on the MyClass side.

Now, in C# an interface is only a contract with which its implementations need to comply with. This is why you need to repeat the property definition in the class definition. In UML, interfaces have exactly the same semantic. Their realization does not mean that you inherit from the interface. In principle you should find back at the implementation level all the elements defined in the interface. So if you want to be complete, it should be:

enter image description here

Remark that UML allows a notation, where there is a realisation arrow from the association with MyInterfaceImpl to the association with MyInterface since the one realises the other. However this notation is not well known, and entry level tools such as plantuml do not support.

1
  • 1
    Thanks for your time and valuable insight.
    – user32882
    Oct 9, 2023 at 10:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.