is a classifier that has declarations of properties and
Some modern languages, such as C++, don't support the concept of interfaces; UML interfaces are typically represented as pure abstract classes. Other languages, such as Java, do support interfaces but don't allow them to have properties. The moral is that you should be aware of how your model is going to be implemented when modeling your system.
There are two representations for an interface; which one you should use depends on what you're trying to show. The first representation is the standard UML classifier notation with the stereotype «interface» . Figure 2-31 shows the Sortable interface.
Figure 2-31. The Sortable interface
The second representation of an interface is the ball-and-socket notation. This representation shows less detail for the interface but is more
Figure 2-32. Examples of providing and requiring interfaces
Because an interface specifies the contract only for a set of features, you can't instantiate an interface directly. Instead, a class is said to
an interface if it provides an implementation for the operations and properties. You show realization using a dashed line starting at the
Figure 2-33. Person realizes the Sortable interface and Alphabetizer depends on it
Providing an implementation of an operation is straightforward. You must provide an implementation on a realizing classifier with the same signature as the operation on the interface. Typically there are semantic constraints associated with an operation that must be honored by any implementation. Realizing a property is more subtle. A property on an interface states that any class that realizes the interface must store the data specified by the property
in some way
. A property on an interface doesn't
Just as interfaces allow you to provide specifications for objects your class will interact with, UML allows you to provide abstractions for the type of class your class may interact with. For example, you can write a List class that can hold any type of object (in C++ this would probably be a void* , in Java and C# it would probably be an Object ). However, while you wanted your List class to be able to support any type of object, you want all of the objects in a given list to be of the same type. UML allows you to create and specify these kinds of abstractions using templates .
Figure 2-34. A templated List class
You can have multiple templated types within a single class; just separate the type
Figure 2-35. A templated class with type restrictions
Specifying restrictions on a type that may be used is functionally similar to specifying an interface for a templated member, except that the user may be able to further restrict an instance of your class by specifying a subclass of your type.
When a user creates an instance of a List , she needs to specify the actual type to use in place of ElementType . This is called binding a type to a template. You show binding with the keyword «bind» , followed by a type specification using the following syntax:
< TemplatedType -> RealType >
You can use the binding syntax whenever you refer to a templated class to indicate you want to use a bound version of that class. This is called explicit binding . For example, Figure 2-36 shows a subclass of List called EmployeeList that binds the ElementType of List to a class named Employee .
Figure 2-36. Explicit template binding
The bind keyword also indicates what types should be used with an instance of a template. This is called implicit binding and is shown in Figure 2-37.
Figure 2-37. Implicit template binding