Interfaces
The contents of the Interfaces package is shown in Figure 51. The
Interfaces package is one of the packages of the Classes package.

In order to locate the metaclasses that are referenced from this
package,
· See "BehavioredClassifier
(from Interfaces)".
· See "Classifier (from
Kernel, Dependencies, PowerTypes)".
· See "Operation (from
Kernel)".
· See "Property (from Kernel,
AssociationClasses)" .
· See "Realization
(from Dependencies)".
BehavioredClassifier (from
Interfaces)
Description
A BehavioredClassifier may have implementations.
Associations
- implementation: Implementation
[*] (Specializes Element.ownedElement
and Realization.clientDependency.)
Implementation (from Interfaces)
Description
An Implementation is a specialized Realization relationship between
a Classifier and an Interface. The implementation relationship
signifies that the realizing classifier conforms to the contract
specified by the interface.
Attributes
No additional attributes.
Associations
- contract: Interface [1] References the
Interface specifying the conformance contract. (Specializes Dependency.supplier
and Relationship.target)
- implementingClassifier: Classifier [1] References the
operations owned by the Interface. (Specializes Dependency.client and
Relationship.source)
Constraints
No additional constraints.
Semantics
A classifier that implements an interface specifies instances that
are conforming to the interface and to any of its ancestors. A
classifier may implement a number of interfaces. The set of interfaces
implemented by the classifier are its provided interfaces and
signify the set of services the classifier offers to its clients. A
classifier implementing an interface supports the set of features
owned by the interface. In addition to supporting the features, a
classifier must comply with the constraints owned by the interface.
An implementation relationship between a classifier and an interface
implies that the classifier supports the set of features owned by the
interface, and any of its parent interfaces. For behavioral features,
the implementing classifier will have an operations or reception for
every operation or reception, respectively, owned by the interface. For
properties, the implementing classifier will provide functionality that
maintains the state represented by the property. While such may be done
by direct
mapping to a propertyof the implementing classifier, it may also be
supported by the state machine of the classifier or by a pair of
operations that support the retrieval of the state information and an
operation that changes the state information.
Notation
See "Interface (from
Interfaces)".
Interface (from Interfaces)
Description
An interface is a kind of classifier that represents a declaration
of a set of coherent public features and obligations. In a sense, an
interface specifies a kind of contract which must be fulfilled by any
instance of a classifier that realizes the interface. 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 directly instantiable.
Instead, an interface specification is realized by an instance
of a classifier, such as a class, which means that it presents a public
facade that conforms to the interface specification. Note that a given
classifier may realize more than one interface and that an interface
may be realized by a number of different classifiers.
Attributes
No additional attributes.
Associations
- ownedAttribute: Proprety References the properties
owned by the Interface. (Subsets Namespace.ownedMember and Classifier.feature.)
- ownedOperation: Operation References the operations owned
by the Interface. (Subsets Namespace.ownedMember and Classifier.feature.)
- nestedInterface: Interface (Subsets Namespace.ownedMember.)
- redefinedInterface: 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 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. There will not necessarily be a
property implementing the classifier corresponding to the property of
the interface. Interfaces may also own constraints which 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 "Implementation (from Interfaces)").
Notation
As a classifier, an interface may be shown using a rectangle symbol
with the keyword «interface» preceding the name. The
implementation dependency from a classifier to an interface is shown by
representing the interface by a circle or ball, labelled with
the name of the interface, attached by a solid line to the classifier
that implements this interface (see Figure 59).
The usage dependency from a classifer 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 implements this interface (see Figure 60).
Where two classifiers provide and require the same interface,
respectively, these two notations may be combined as shown in Figure
61. The ball-and-socket notation hints at that the interface in
question serves to mediate interactions between the two classifiers.
Presentation Option
Alternatively, if an interface is shown using the rectangle symbol,
their implementation and usage dependencies to provided and required
interfaces, respectively, may be shown using dependency arrows (see
Figure 62). The classifier at the tail of the arrow implements the
interface at the head of the arrow or uses that interface, respectively.
A set of interfaces constituting a protocol may be depicted as
interfaces with associations between them (see Figure 63).
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 64 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.
Three classes: DoorSensor, DoorAlarm, and DoorBell,
implement the above interfaces (see Figure 65 below). 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.