- Introduction
- 16.1 Applying UML: Common Class Diagram Notation
- 16.2 Definition: Design Class Diagram
- 16.3 Definition: Classifier
- 16.4 Ways to Show UML Attributes: Attribute Text and Association Lines
- 16.5 Note Symbols: Notes, Comments, Constraints, and Method Bodies
- 16.6 Operations and Methods
- 16.7 Keywords
- 16.8 Stereotypes, Profiles, and Tags
- 16.9 UML Properties and Property Strings
- 16.10 Generalization, Abstract Classes, Abstract Operations
- 16.11 Dependency
- 16.12 Interfaces
- 16.13 Composition Over Aggregation
- 16.14 Constraints
- 16.15 Qualified Association
- 16.16 Association Class
- 16.17 Singleton Classes
- 16.18 Template Classes and Interfaces
- 16.19 User-Defined Compartments
- 16.20 Active Class
- 16.21 Whats the Relationship Between Interaction and Class Diagrams?
This chapter is from the book
This chapter is from the book
This chapter is from the book
16.6 Operations and Methods
Operations
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:
visibility name (parameter-list) {property-string}
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 implementation—rather, methods are implementations. When we explored operation contracts, in UML terms we were exploring the definition of constraints for UML operations.
How to Show Methods in Class Diagrams?
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.
){kind=small}
Figure 16.7 How to show a method body in a 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.
Operation Issues in DCDs
The create Operation
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 language—such 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.
Operations to Access Attributes
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.