Interfaces in UML modeling diagrams

In UML modeling, interfaces are model elements that define sets of operations that other model elements, such as classes, or components must implement. An implementing model element realizes an interface by overriding each of the operations that the interface declares.

You can use interfaces in class diagrams and component diagrams to specify a contract between the interface and the classifier that realizes the interface. Each interface specifies a well-defined set of operations that have public visibility. The operation signatures tell the implementing classifiers what kind of behavior to invoke, but not how they should invoke that behavior. Many classifiers can implement a single interface, each one providing a unique implementation.

Interfaces support the hiding of information and protect client code by publicly declaring certain behavior or services. Classes or components that realize the interfaces by implementing this behavior simplify the development of applications because developers who write client code need to know only about the interfaces, not about the details of the implementation. If you replace classes, or components that implement interfaces, in your model, you do not need to redesign your application if the new model elements implement the same interfaces.

You can specify the following types of interfaces:

Provided interfaces: these interfaces describe the services that instances of a classifier (supplier) offer to their clients
Required interfaces: these interfaces specify the services that a classifier needs to perform its functions and to fulfill its own obligations to its clients

An interface typically has a name that reflects the role that it plays in an application. A common convention is to prefix the name of the interface with a forward slash to indicate that a model element is an interface.

As the following figures illustrate, the diagram editor displays an interface in the following ways:

Class rectangle symbol that contains the keyword «interface». This notation is also called the internal or class view.

Use the class shape when you need to model the details of the interface. Compartments in the class shape display information about the attributes, operations, and signal receptions of the interface.
Ball and socket notation, in which the implementation dependency from a classifier to the provided interface is displayed as a circle (ball) and the usage dependency from a classifier to the required interface is displayed as a half-circle (socket). This notation is also called the external view.
Provided interface (circle shape) Required interface (socket shape)

Use the ball and socket notation, also called the lollypop notation, when you need to model only that provided and required interfaces exist.

Provided interface (circle shape)	Required interface (socket shape)