Question

0

1K

Views

In a UML, if an interface has a relationship with a class would that relationship also apply to whatever classes implement it?

Because any class that implements an interface is of the same type as said interface, would any relationships with the interface also apply to whatever implements it?

For example, say we have an interface called Product which has a method signature that returns an instance of class Colour. We then have 2 classes which implement this interface, called Shelf and Desk. These two classes contain an attribute of the class Colour.

UML example of relationships 1

or

UML example of relationships 2

Would the relationship only need to be shown between Product and Colour or would Product, Shelf and Desk all need to show their relationships with class Colour?

over 4 years ago · Santiago Trujillo

1 answers

Answer question

0

Answer question

Find remote jobs

Answer 1 · 2022-04-20T17:38:52.310Z

Do associations of an interface apply to their implementation?

An interface defines a contract, stating the features that implementing class must provide and constraints that they must fulfil. If an interface has an association with a class T, then all its implementations must behave exactly as if they'd also have an association with a class T.

Here is what the UML specs tell us:

Properties owned by Interfaces (including Association ends) imply that the realizing BehavioredClassifier should maintain information corresponding to the type and multiplicity of the Property and facilitate retrieval and modification of that information. A Property declared on an Interface does not necessarily imply that there will be such a Property on a realizing BehavioredClassifier (e.g., it may be realized by equivalent get and set Operations).

So the answer to your question is ambiguous:

if you are using the implementing classes, you can assume that it has such an association even if it's not shown in the diagram.
if you're designing such an implementing class, you cannot assume that the association is automatically there: implementing is not inheriting. If you do not show anything in your model, it's unspecified how the class will fulfil its contract. If you want to be complete, you have to define the necessary associations in the implementing classes: the second diagram would therefore be more accurate and comprehensive.

You could also have, for one of the implementation, a different situation, where the association is derived from other associations and not maintained explicitly.

Does you narrative really requires an association at all?

In your narrative, you justify the need for an association because of a method that returns a type T. But having parameters or a return type is not sufficient to require an association as explained in this other SO answer. An association requires a semantic relationship.

So, your interface has more probably a dependency to Color.

Miscellaneous remarks

In both diagrams, you should show the realization dependency with a plain blank arrow-head (white triangle at the end) and not an open arrow end.

In older UML versions 1.xx, the interface had a semantic that was equivalent to an abstract class and was not allowed to have its own properties. While things are more relaxed now, I'd advise to stick with this approach because:

an interface is meant provide a set of behaviors
behaviors are implemented in operations
private properties are not visible to the outside world, so have nothing to do in an interface. public properties should be avoided because of the risk for encapsulation and decoupling.
if you really need a property, it could be the symptom of a need for a class.

0

1K