Relationships between classes and interfaces

[nexdev]

Hi,

I'm trying to understand how best to describe the relationship between a class and an interface. From what I have read the only relationships that are valid between a class and an interface are dependency and realization. Is this the case?

E.g.

If I have a client class and a queue class and I want to show that the client has 2 instances of the queue class, one of which is used as an input queue and the other an output queue, I can use 2 associations each clearly marked to show the role of the association and the multiplicity.

If the queue is replaced with an iqueue interface how can I show the same relationships? Is it valid to simply substitute the interface for the class, or do I now need to simply show a dependency relationship between the client class and the iqueue interface? Doing so would lose a lot of information.

Thanks.

[Dave.B]

You are at perfect liberty to substitute an interface class for a concrete class without any loss in modelling fidelity.

A concrete class that implements an interface is said to realise that interface. You could also use sub-classing, but since modern UML also provides the more restricted realise form for working with interface classes this is probably clearer.

Regards
Dave B.

[Geert Bellekens]

nextdev,

There is no reason why you wouldn't be allowed to create regular association to and from your interface.

Creating a relation from an interface to another class simply states, that every class that implements the interface has to realize this association in some way.

In concreto this means that the class that realizes this interface has to have the CRUD operations implemented that one would expect if it has such an association.
Exactly how this is implemented in the code is in fact irrelevant. It could be that the realizing class has an attribute of the type of the other class (or two attributes in your case), but it could also have an ordered list, or even just an operation that gets the details of the two other classes from the database.
As you see there are a number of way (better or worse) that you can implement an association in programming code, but it still remains an association in UML.

You have to remember that you are modelling in UML, not representing code in a slightly different UML-ish way.

Geert