An abstract class is a class that can’t have any instances.

Abstract classes are generally designed to capture operations that subclasses inherit. The idea is that the operations defined for an abstract class are relatively general, and each class that inherits these operations refines and expands upon them. (You explore inheritance in Chapter 2.)

In UML notation, the name of an abstract class appears in italics (see Figure 1-11).

Figure 1-11.  Abstract class

NOTE Figure 1-11 adds an abstract operation, record, to the Review class. CustomerReview and EditorialReview both inherit this operation, but the operation works differently in the context of each class.

You can also use an «abstract» stereotype for readers of the model who might not realize the significance of the italics.

An active class is a class that represents an independent flow of control, such as a process or a thread.

The class box for an active class has thin vertical bars just inside the borders, as shown in Figure 1-12.

Figure 1-12.  Active class

The instances of an active class are called active objects.

An interface is a collection of operations that represent services offered by a class or a component. (A discussion of components appears in Chapter 9.) By definition, all of these operations have public visibility. (See the section “Visibility,” earlier in this chapter.)

One of the key tenets of object orientation is the separation of an interface from the details of how the exposed operations are implemented as methods. The interface specifies something like a contract that a class must adhere to; the class realizes (or provides a realization for) one or more interfaces.

The UML defines two kinds of interfaces: provided interfaces and required interfaces.

Provided interfaces are interfaces that a class provides to potential clients for the operations that it offers (such as objects belonging to other classes). There are two ways to show a provided interface. One way is called “lollipop” notation: The interface is a circle attached to the class box with a straight line. The other way involves defining the interface using a class box and the built-in «interface» stereotype, and then drawing a dashed line with a triangle at the end that has the interface.

Figure 1-13 shows two examples of provided interfaces, using both notations.

Figure 1-13.  Provided interfaces

Setting up a Password Handler interface to the Account class provides the flexibility to use different encryption algorithms in the implementation of the operation that stores customer passwords. Along the same lines, the Inventory Handler interface allows elements of the system to interact with objects belonging to the Inventory class without having to know whether the inventory system uses FIFO (first in, first out), LIFO (last in, first out), or some other method of handling inventory.

Required interfaces are interfaces that a class needs to fulfill its duties. The symbol for a required interface is a half-circle, as shown in Figure 1-14.

Figure 1-14. Required interfaces

Instances of the Order class use Retrieve Books in fulfilling the given order and Retrieve Tracking Info if the Customer that placed the order wants to track the order’s shipping history. (More detail about these interfaces appears in the following paragraphs.)

You can also show one class providing an interface that another class requires, using “ball and socket” notation, where the ball represents the provided interface and the socket indicates the required interface. Figure 1-15 shows an example.

Figure 1-15.  Provided/required interface

The Inventory class provides the Retrieve Books interface that the Order class requires, as shown in Figure 1-14.

A port specifies a distinct interaction point between a class and its environment. Ports group provided interfaces and/or required interfaces in two ways. They serve as focal points through which requests can be made to invoke the operations that the class makes available. They also serve as gateways for calls that the class makes to operations offered by other classes.

A port appears as a small square on the boundary of the class box. Interfaces are connected to a port via connectors, which are simple straight lines. Figure 1-16 shows two example ports, one with a name and one without.

Figure 1-16.  Ports and connectors

An instance of the Order class receives a request to fulfill the actual order that the instance represents via the Perform Fulfillment interface. The Order instance uses the Retrieve Books interface in meeting this request. After the given order is shipped, the associated Customer may request tracking information via the Provide Tracking Info interface. The Order instance, in turn, uses the Retrieve Tracking Info interface to acquire the necessary information to return to the Customer.