Reputation: 73

Does interface diagram exist in UML?

Does interface diagram exist in UML or does it form part of the component diagram, i'm confused about that as I am new to the field.

Upvotes: 4

Answers (2)

Ister

Reputation: 6318

TLDR

There is no separate "interface diagram". You can use any structure diagram, e.g. Class, Component etc.

Detailed answer

An Interface is a concept independent from Components diagram and is described in section 10.4 of UML 2.5. specification.

An Interface is a kind of Classifier that represents a declaration of a set of public Features and obligations that together constitute a coherent service. An Interface specifies a contract; any instance of a Classifier that realizes the Interface shall fulfill that contract. The obligations associated with an Interface are in the form of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the Interface.

An Interface can be presented

on a Class diagram (usually as a Classifier with the <<interface>> keyword, but socket-ball notation is also allowed)
on Components diagram where you can either use a Classifier notation or a socket-ball notation.
on Composite structure diagram where it's usually presented using socket-ball notation.

Rectangle, socket-ball and textual notations are fully interchangeable and whenever one is allowed the other can be used as well. The suggested usage of notation here comes from a typical diagram usage only.

Classifier (rectangle) notation

Rectangle notation provides details about interface specification.

10.4.4. says:

An Interface may be designated using the default notation for Classifier (see 9.2.4) with the keyword «interface».

and 10.4.5. specifies further:

(...) in cases where Interfaces are represented using the rectangle notation, InterfaceRealization and Usage dependencies are denoted with appropriate dependency arrows (see Figure 10.11). The Classifier at the tail of the arrow implements the Interface at the head of the arrow or uses that Interface, respectively.

According to aforementioned Figure 10.11 - a realization is depicted with an arrow that has a dashed line and an empty triangle as a head - a dependency is depicted as Usage Dependency (i.e. Dependency arrow that is a dashed line with an open arrowhead, with a <<use>> keyword)

Socket-ball notation

Socket-ball notation visualises Interfaces in a simple graphical way, clearly depicting provided and required interfaces. For Components it is often additional linked with a concept of Ports.

10.4.4. provides this description:

Alternatively an InterfaceRealization dependency from a BehavioredClassifier to an Interface may be shown by representing the Interface by a circle or ball, often also called lollipop, labeled with the name of the Interface, attached by a solid line to the BehavioredClassifier that realizes this Interface.

The Usage dependency from a Classifier to an Interface is shown by representing the Interface by a half-circle or socket, labeled with the name of the Interface, attached by a solid line to the Classifier that requires this Interface.

(...)

If a Dependency is wired from a Usage to an InterfaceRealization that are represented using a socket and a lollipop, the dependency arrow may be shown joining the socket to the lollipop

Compartment notation

A textual notation as a Classifier compartments is defined for Components. As other Classifiers can have any compartments similar notation can be used for any other classifier.

According to 10.6.4.

A conforming tool may optionally support compartments named “provided interfaces” and “required interfaces” listing the provided and required Interfaces by name. This may be a useful option in scenarios in which a Component has a large number of provided or required Interfaces.

Upvotes: 1