|Previous||UML Classes||Table of Contents||UML Packages||Next|
Classifier (from Kernel , Dependencies , PowerTypes ) on page 51
An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. An
interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract. The obligations
that may be associated with an interface are in the form of various kinds of constraints (such as pre- and post-conditions)
or protocol specifications, which may impose ordering restrictions on interactions through the interface.
Since interfaces are declarations, they are not instantiable. Instead, an interface specification is implemented by an instance
of an instantiable classifier, which means that the instantiable classifier presents a public facade that conforms to the
interface specification. Note that a given classifier may implement more than one interface and that an interface may be implemented
by a number of different classifiers (see
InterfaceRealization (from Interfaces ) on page 90).
No additional attributes
• ownedAttribute: Property References all the properties owned by the Interface. (Subsets Namespace ::ownedMember and Classifier::feature)
• ownedOperation: Operation References all the operations owned by the Interface. (Subsets Namespace ::ownedMember and Classifier::feature)
• nestedClassifier: Classifier (References all the Classifiers owned by the Interface. (Subsets Namespace ::ownedMember)
• redefinedInterface: Interface (References all the Interfaces redefined by this Interface. (Subsets Element::redefinedElement)
 The visibility of all features owned by an interface must be public.
self.feature->forAll(f | f.visibility = #public)
An interface declares a set of public features and obligations that constitute a coherent service offered by a classifier.
Interfaces provide a way to partition and characterize groups of properties that realizing classifier instances must possess.
An interface does not specify how it is to be implemented, but merely what needs to be supported by realizing instances. That
is, such instances must provide a public facade (attributes, operations, externally observable behavior) that conforms to
the interface. Thus, if an interface declares an attribute, this does not necessarily mean that the realizing instance will
necessarily have such an attribute in its implementation, only that it will appear so to external observers.
Because an interface is merely a declaration it is not an instantiable model element; that is, there are no instances of interfaces
at run time.
The set of interfaces realized by a classifier are its provided interfaces, which represent the obligations that instances
of that classifier have to their clients. They describe the services that the instances of that classifier offer to their
clients. Interfaces may also be used to specify required interfaces, which are specified by a usage dependency between the
classifier and the corresponding interfaces. Required interfaces specify services that a classifier needs in order to perform
its function and fulfill its own obligations to its clients.
Properties owned by interfaces are abstract and imply that the conforming instance 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 classifier realizing that Interface (e.g.,
it may be realized by equivalent get and set operations). Interfaces may also own constraints that impose constraints on the
features of the implementing classifier.
An association between an interface and any other classifier implies that a conforming association must exist between any
implementation of that interface and that other classifier. In particular, an association between interfaces implies that
a conforming association must exist between implementations of the interfaces.
An interface cannot be directly instantiated. Instantiable classifiers, such as classes, must implement an interface (see
InterfaceRealization (from Interfaces )).
As a classifier, an interface may be shown using a rectangle symbol with the keyword «interface» preceding the name.
The interface realization dependency from a classifier to an interface is shown by representing the interface by a circle
, labeled with the name of the interface, attached by a solid line to the classifier that realizes this interface (see Figure
Figure 7.55 - Isensor is the provided interface of ProximitySensor
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 (see Figure
Figure 7.56 - Isensor is the required interface of TheftAlarm
Alternatively, in cases where interfaces are represented using the rectangle notation, interface realization and usage
dependencies are denoted with appropriate dependency arrows (see Figure 7.57). The classifier at the tail of the arrow
implements the interface at the head of the arrow or uses that interface, respectively.
Figure 7.57 - Alternative notation for the situation depicted in Figure 7.55 and Figure 7.56
Issue 8746 - replace paragraph with better explanation
It is often the case in practice that two or more interfaces are mutually coupled through application-specific dependencies.
In such situations, each interface represents a specific role in a multi-party protocol. These types of protocol role
couplings can be captured by associations between interfaces as shown in the example in Figure 7.58.
theAlarm the Sensor 11
Figure 7.58 - Alarm is the required interface for any classifier implementing Isensor; conversely, Isensor is the required
interface for any classifier implementing IAlarm.
The following example shows a set of associated interfaces that specify an alarm system. (These interfaces may be
defined independently or as part of a collaboration.) Figure 7.59 shows the specification of three interfaces,
IAlarm, ISensor, and IBuzzer. IAlarm and Isensor are shown as engaged in a bidirectional protocol; IBuzzer describes the required
interface for instances of classifiers implementing IAlarm, as depicted by their respective associations.
theAlarm the Sensor 11
Three classes: DoorSensor, DoorAlarm, and DoorBell
implement the above interfaces (see Figure 7.60). These classifiers
are completely decoupled. Nevertheless, instances of these classifiers are able to interact by virtue of the conforming associations
declared by the associations between the interfaces that they realize.
Figure 7.60 - Classifiers implementing the above interfaces