Performing Operations
As you get to know your classes and get to know their properties (attributes), you also get to know their behaviors. UML uses the term operations to refer to the possible behaviors of a class what the objects of the class can do or have done to them. Consider what can you ask objects of the class to do—or what can cause them to change their states—when you create the basic syntax for an operation. A typical example follows:
operationName (optional argumentList): ReturnType So if you wanted to ask a Person object to rent out a crash dummy, the operation would look something like this.
rentOutDummy (): SuccessKind An operation is usually called (asked to be performed) because the caller wants something in return. Specify the ReturnType as an attribute-like type identifier. If nothing is returned when this operation is performed, either use Null or omit the ReturnType altogether. In the previous example operation, a success indicator is returned.
But before something can be returned, something must usually be given—and generally requires information before it can do something. The argument of an operation specifies a piece of information needed by the object to perform this operation.
Specify the information needed by the operation in an optional argumentList of comma-separated arguments or parameters—the specific things the object needs to perform this operation. Here’s how the arguments go together:
operationName (argument1, argument2, . . . ): ReturnType Each argument must have a type declaration so that the kind of information that is needed can be determined. Each argument in the argumentList above looks like a mini-attribute, as shown below:
argumentName: ArgumentType [Multiplicity] = default value So our example operation might be more completely shown as follows:
rentOutDummy (aDummy:CrashDummy[1],forClient:Person[1]): SuccessKind In this example, the operation rentOutDummy has two arguments. The first argument is a singly valued argument named aDummy and is of the Crash Dummy type. The second argument is also a singly valued argument, which is called forClient and is of the type Person. When called, the operation returns a value that is of the enumeration type SuccessKind.
As with attributes, if you don’t specify a multiplicity for an argument, it will default to 1. And as with attributes, you may also specify a default value if you want.
rentOutDummy (aDummy:CrashDummy,forClient:Person): SuccessKind Besides a type, a multiplicity, and a default value, each argument can also have a direction. If you need to set the argument before the operation is called, the argument is an in argument. If you set the argument by calling the operation, then the argument should be an out argument. If the argument must be set before the operation is called and is changed by calling the operation, it’s an inout argument. The direction precedes the name of the argument. (The default is in.)
Here’s the syntax and an example of an operation with the direction included:
direction argumentName: ArgumentType [Multiplicity] = default value rentOutDummy (in aDummy:CrashDummy, in forClient:Person): SuccessKind
The complete specification of the operation name, arguments, and return for an operation is called the operation’s signature. As people have their own signature, each operation has one also. However; more than one person can have the same name, and more than one operation can have the same signature, whenever there is more than class in question, it’s best to precede the operation with the owning class name:
Class::operationName (argument list): ReturnType Person::rentOutDummy (in aDummy:CrashDummy, in forClient:Person): SuccessKind
Naming operations and arguments
Name operations in the same format as attributes (start with a lowercase word, compress blanks, and capitalize all successive words), but operation names should be verbs or verb phrases. Though not technically required,
follow the operation name with () to emphasize the visual distinction from an attribute. When naming the operation, name it from the point of view of target object, the object performing the operation, not from the point of view of the requestor. If the requestor also performs an operation to make the request, then there are two parallel operations. We show some examples in Table 3-5.
Tip Try to choose active verbs whenever possible; you don’t want your readers to fall asleep or drown in those passive helping verbs.
| Requestor’s Operation | Recipient’s Operation |
|---|---|
| hireDummy (aDummy, fromPerson) | rentOutDummy(aDummy, toPerson) |
| borrowTool (aTool, fromPerson) | lendTool (aTool, toPerson) |
| offerProposal () | acceptProposal ():Boolean |
Saying please
Tip One trick to help name the operations correctly from the target object’s point of view is to place a virtual “Please” before each operation. When you want a person to lend you a tool, you ask them, “Please, lend me that tool” and not “Please, borrow me that tool.”
When naming arguments, consider that the argument name has four purposes. The name is supposed accomplish the following:
-
Make it clear to the reader what the argument does.
-
Make it clear to the caller what needs to be supplied.
-
Make it clear to the caller what the argument is going to be used for.
-
Make it clear to the coder what the incoming argument is.
The most useful approach is to make the whole operation signature read like a sentence. Remember to place a logical “Please”(replacing the two colons) right before the operation name and right after the class name. For example, consider the following operation:
Person::rentOutDummy (thisDummy:CrashDummy, toThatPerson:Person):SuccessType It could be translated this way: “Person, please, rentOutDummy, thisDummy of type CrashDummy toThatPerson of type Person, returning a SuccessType”
EAN: 2147483647
Pages: 193