One of the compartments of the UML class box shows the signatures of operations (see Figure 16.1 for many examples). At the time of this writing, the full, official format of the operation syntax is:
Notice there is no
return type element, an obvious problem, but purposefully injected into the UML 2 specification for inscrutable reasons. There is a chance that the specification will revert to a UML1-ish syntax, which in any event many authors show and UML tools will continue to support:
visibility name (parameter-list) : return-type {property-string}
Guideline : Assume the version that includes a return type.
Guideline : Operations are usually assumed public if no visibility is shown.
The property string contains arbitrary additional information, such as exceptions that may be raised, if the operation is abstract, and so forth.
In addition to the official UML operation syntax, the UML allows the operation signature to be written in any programming language, such as Java, assuming the reader or tool is notified. For example, both expressions are possible:
+ getPlayer( name : String ) : Player {exception IOException}
public Player getPlayer( String name ) throws IOException
An operation is
not a method. A UML operation is a
declaration , with a name, parameters, return type, exceptions list, and possibly a set of
constraints of pre-and post-conditions. But, it isn't an implementationrather, methods are implementations. When we explored operation contracts (p. 181), in UML terms we were exploring the definition of constraints for UML operations, as was discussed on p. 191.
A UML method is the implementation of an operation; if constraints are defined, the method must satisfy them. A method may be illustrated several ways, including:
in interaction diagrams, by the details and sequence of messages
in class diagrams, with a UML note symbol stereotyped with «method»
Both styles will be used in subsequent chapters.
Figure 16.7 applies a UML note symbol to define the method body.
Notice, subtly, that when we use a UML note to show a method, we are
mixing static and dynamic views in the same diagram. The method body (which defines dynamic behavior) adds a dynamic element to the static class diagram.
Note that this style is good for book or document diagrams and tool-generated output, but perhaps too fussy or stylized for sketching or tool input. Tools may provide a popup window to simply enter the code for a method.
The
create message in an interaction diagram is normally interpreted as the invocation of the
new operator and a constructor call in languages such as Java and C#. In a DCD this
create message will usually be mapped to a constructor definition, using the rules of the languagesuch as the constructor name equal to the class name (Java, C#, C++, …). Figure 16.1 shows an example, with the
SuperclassFoo constructor stereotyped «constructor» so that its category is clear.
Accessing operations retrieve or set attributes, such as
getPrice and
setPrice . These operations are often excluded (or filtered) from the class diagram because of the high noise-to-value ratio they generate; for n attributes, there may be 2n uninteresting
getter and
setter operations. Most UML tools support filtering their display, and it's especially common to ignore them while wall sketching.