The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Terms and Concepts

An interface is a collection of operations that are used to specify a service of a class or a component. A type is a stereotype of a class used to specify a domain of objects, together with the operations (but not the methods) applicable to the object. A role is the behavior of an entity participating in a particular context.

Graphically, an interface may be rendered as a stereotyped class in order to expose its operations and other properties. To show the relationship between a class and its interfaces, a special notation is provided. A provided interface (one that represents services provided by the class) is shown as a small circle attached to the class box. A required interface (one that represents services required by a class of another class) is shown as a small semicircle attached to the class box.

Note

Interfaces may also be used to specify a contract for a use case or subsystem.

Names

Every interface must have a name that distinguishes it from other interfaces. A name is a textual string. That name alone is known as a

simple name ; a

path name is the interface name prefixed by the name of the package in which that interface lives. An interface may be drawn showing only its name, as in Figure 11-2.

Note

An interface name may be text consisting of any number of letters, numbers, and certain punctuation marks (except for marks such as the colon, which is used to separate an interface name and the name of its enclosing package) and may continue over several lines. In practice, interface names are short nouns or noun phrases drawn from the vocabulary of the system you are modeling.

Operations

An interface is a named collection of operations used to specify a service of a class or of a component. Unlike classes or types, interfaces do not specify any implementation (so they may not include any methods, which provide the implementation of an operation). Like a class, an interface may have any number of operations. These operations may be adorned with visibility properties, concurrency properties, stereotypes, tagged values, and constraints.

When you declare an interface, you render an interface as a stereotyped class, listing its operations in the appropriate compartment. Operations may be drawn showing only their name, or they may be augmented to show their full signature and other properties, as in Figure 11-3.

Note

You can also associate signals with an interface.

Relationships

Like a class, an interface may participate in generalization, association, and dependency relationships. In addition, an interface may participate in realization relationships. Realization is a semantic relationship between two classifiers in which one classifier specifies a contract that another classifier guarantees to carry out.

An interface specifies a contract for a class or a component without dictating its implementation. A class or component may realize many interfaces. In so doing, it commits to carry out all these contracts faithfully, which means that it provides a set of methods that properly implement the operations defined in the interface. The set of services that it agrees to provide are its

provided interface . Similarly, a class or a component may depend on many interfaces. In so doing, it expects that these contracts will be honored by some set of components that realize them. The set of services that a class requires from other classes are its

required interface . This is why we say that an interface represents a seam in a system. An interface specifies a contract, and the client and the supplier on each side of the contract may change independently, as long as each fulfills its obligations to the contract.

As Figure 11-4 illustrates, you can show that an element realizes an interface in two ways. First, you can use the simple form in which the interface and its realization relationship are rendered as a line between the class box and a small circle (for a provided interface) or a small semicircle (for a required interface). This form is useful when you simply want to expose the seams in your system; it is usually the preferred form. However, the limitation of this style is that you can't directly visualize the operations or signals provided by the interface. Second, you can use the expanded form in which you render an interface as a stereotyped class, which allows you to visualize its operations and other properties, and then draw a realization relationship (for a provided interface) or a dependency (for a required interface) from the classifier or component to the interface box. In the UML, a realization relationship is rendered as a dashed directed line with a large triangular arrowhead pointing to the interface. This notation is a cross between generalization and dependency.

Note

Interfaces are similar to abstract classes. For example, neither may have direct instances. An abstract class can implement its concrete operations, however. An interface is more like an abstract class in which all of the operations are also abstract.

Understanding an Interface

When you are handed an interface, the first thing you'll see is a set of operations that specify a service of a class or a component. Look a little deeper and you'll see the full signature of those operations, along with any of their special properties, such as visibility, scope, and concurrency semantics.

These properties are important, but for complex interfaces they aren't enough to help you understand the semantics of the service they represent, much less know how to use those operations properly. In the absence of any other information, you'd have to dive into some abstraction that realizes the interface to figure out what each operation does and how those operations are meant to work together. However, that defeats the purpose of an interface, which is to provide a clear separation of concerns in a system.

In the UML, you can supply much more information to an interface to make it understandable and approachable. First, you may attach pre- and postconditions to each operation and invariants to the class or component as a whole. By doing this, a client who needs to use an interface will be able to understand what the interface does and how to use it, without having to dive into an implementation. If you need to be rigorous, you can use the UML's OCL to formally specify the semantics. Second, you can attach a state machine to the interface. You can use this state machine to specify the legal partial ordering of an interface's operations. Third, you can attach collaborations to the interface. You can use collaborations to specify the expected behavior of the interface through a series of interaction diagrams.