7.3.24 Interface

*Generalizations

   •

    Classifier (from Kernel , Dependencies , PowerTypes ) on page 51

*Description

   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).

*Attributes

   No additional attributes

*Associations

   • 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)

*Constraints

   [1] The visibility of all features owned by an interface must be public.

   self.feature->forAll(f | f.visibility = #public)

*Semantics

   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 )).

*Notation

   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 or ball , labeled with the name of the interface, attached by a solid line to the classifier that realizes this interface (see Figure 7.55 ).

   ISensor

   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 7.56 ).

   TheftAlarm

   ISensor

   Figure 7.56 - Isensor is the required interface of TheftAlarm

*Presentation Options

   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.

   Examples

   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