I am building a class diagram where "Interface A" is implemented by a member of "Class B".

I don't know if I should even be drawing a relationship between these or if I should, what would the line look like?

EDIT: To give a little more context I'll give a small example of what I'm talking about (downvotes without explanations why don't really help me):

interface ISampleInterface
    void SampleMethod();

class SampleClass {
    ISampleInterface someVarName;

How do I show the relationship between the member "someVarName" and the interface "ISampleInterface"

I think the correct way is to use Composition / Aggregation to show this.

  • A quick search can help you. Else I can post in a while Nov 4, 2019 at 3:39
  • I've been searching. It doesn't seem to fit any of cdn.visual-paradigm.com/guide/uml/uml-class-diagram-tutorial/… Nov 4, 2019 at 3:40
  • From what I've seen, maybe a <<uses>> is appropriate but I'm not sure Nov 4, 2019 at 3:48
  • Actually, maybe this is just composition - I assume the interface has the same lifetime as the class that has a member who implements this interface Nov 4, 2019 at 3:59
  • I am not a programmer and I don't know what language are you using, but the code snippet is confusing for me. From my knowledge, the interface implementation by the class is declared at the class level already, something like class SampleClass implements ISampleInterface {} (this, of course, depends on the language). As the name suggests, then the class has to implement the methods required by the interface(directly on the class level). Please clarify if that is what you want to achieve.
    – Ister
    Nov 4, 2019 at 10:07

3 Answers 3


Yes, you are correct. Show it as composition or aggregation depending on the lifetime of participants.


enter image description here


enter image description here

  • 2
    A directional association (no diamond) would also work, but would offer less information about the life of the member. That may be appropriate depending on the level of detail you wish to convey in your diagram.
    – Thomas Owens
    Nov 4, 2019 at 11:55
  • I agreed with thomas Nov 4, 2019 at 12:17
  • I'm still not getting tired to point to p. 110 of UML 2.5 which states that the shared aggregation has no defined semantic an needs to be individually defined in the domain where it is used.
    – user188153
    Nov 5, 2019 at 22:09

You do have a simple association here:

enter image description here

You do not specify any requirements that tell something about the lifetime of someVarName. In that case you just have an association here. Your language snippet does not tell (me) anything about visibility so I marked it public. Also note the dot to the right of the association which makes someVarName a private property of SampleClass.

N.B.: If you have any requirement that the instance someVarName must die along with SampleClass you can make it a composite aggregation. Without that requirement it's a plain association. A shared aggregation is (almost all times) used with wrong (historic) propositions. It has no defined semantics as p. 110 of UML 2.5 states:

shared | Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.


Let me focus on specific parts of your questions:

I don't know if I should even be drawing a relationship between these

As a rule of thumb, if the relationship is important, you should show it on your diagram. So the answer to this one is: yes, you should show it.

I am building a class diagram where "Interface A" is implemented by a member of "Class B".

First, to be on the same page, let me start from what an interface is:

Interface, in C#, is a code structure that defines a contract between an object and its user. It contains a collection of semantically similar properties and methods that can be implemented by a class or a struct that adheres to the contract.1

While the definition here is for C#, in general, it is valid for all modern programming languages.

Let me emphasise this - interface is a contract. It means that class that implements the interface has to adhere to that contract. In other words, it has to implement methods listed in the contract (interface). It does not mean though that it contains an interface as a property. On the contrary, every class can (and usually has to) implement the methods required by the interface in various ways, depending on the internal structure of the class itself. Moreover by adding the interface the way you did in your snippet you do not make the class adhere to the contract.

Typically class implementation is declared on the class definition level and then the method itself has to be directly declared again in the class body. Unlike on interface, there the methods are only listed (thus defining the contract), in the class it has to contain the body of the class itself (thus implementation).

A typical code for that will look something like that (the way implementation is declared depends on the programming language):

interface ISampleInterface {
  public void sampleMethod();

// You see interface declaration at the very beginning
class SampleClass implements ISampleInterface {
// Internal class structure ensuring the right behaviour, data stracture etc.
  private int someVarName;

  private void doSomethingMethod(int someDoInternalVar) {
    someVarName = someVarName + someDoInternalVar;

// Methods required by the interface, including their body
  public void sampleMethod() {
    int someInternalVarName;


This example uses Java notation, but in other languages you have some similar constructs. PHP actually will look exactly the same, in C# you will have a slightly different way of interface implementation declaration:

interface ISampleInterface {
  public void sampleMethod();

class SampleClass : ISampleInterface {
  public void sampleMethod() {

For this type of "proper" interface implementation, the UML notation is a dashed line with an empty triangle, going from the class to the interface it implements:

Interface implementation

For more details please have a look at Section 10.4.5 of UML Specification, especially figure 10.11.

Your code snippet is somewhat misleading though, as it indicates that an interface is a member of a class, not that the class itself implements it. I must say I am not sure what your intention is here as I have never seen such approach. I am not a programmer though.

If you are sure you want to have interface as a property of a class rather than class implementing the interface (i.e. adhering to the interface contract), then the typical notation here will depend on how strong your relationship is. In general, it is some kind of association (so solid line). Whether it is a stronger relationship (shared or composite aggregation, so hollow or filled diamond on class side respectively) will depend on your specific case. I strongly recommend checking answers to this question as they explain it with all details. Yet, since you probably want your interface to die with your object, that would be a composite aggregation.


  • Thanks for the detailed response. I am using interfaces as members as the type isn't known until run time Nov 7, 2019 at 22:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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