Notation for Modeling Operations

Objects have behaviors, things they can do and things that can be done to them and these behaviors are modeled as operations. The UML distinguishes between operation and method, whereas many people use them interchangeably.

• Operation and methods: In the UML, an operation is the declaration of the signature. A method is the implementation of an operation and must conform to the signature of the operation that it implements. Following this logic, completely abstract operations have no method. When we cover the dynamic and functional models, you will see more extensive tools for specifying methods.

The UML definition of operation and method supports the Java concept of interface classes where only the operation is defined. There is never a method in an interface class. The implementing class must provide the method that implements the interface operation. At modeling time, you do not specify the method, only the operation. You may want to keep notes on the methods by documenting them in the constraints for the operation.

• What is a UML Operation? Entries in the operation compartment are strings that show operations defined on classes and methods supplied by classes
  
  • Semantics: An operation is a service that an instance of the class may be requested to perform. It has a name and a list of arguments.
  • Notation: An operation is shown as a text string that can be parsed into the various properties of an operation model element. The default syntax is:
    

    visibility name ( parameter-list ) : return-type-expression { property-string }
    

    Where visibility is one of:
    1. + public visibility
    2. # protected visibility
    3. - private visibility
    4. ~ package visibility
    
    The visibility marker may be suppressed. The absence of a visibility marker indicates that the visibility is not shown (not that it is undefined or public). The visibility marker is a shorthand for a full visibility property specification string. Visibility may also be specified by keywords (public, protected, private, package). This form is used particularly when it is used as an inline list element that applies to an entire block of operations.

OO technologies such as CORBA and COM appeared on the scene, followed by Java, DCOM, EJBs, C#, and .NET, and our use case-driven approach just kept right on working without skipping a beat. Occasionally we would sit back and ponder why it had not broken, and it seemed like we had hit on a systematic approach that provided the answers to some fundamentally important questions that addressed the issue of how to get from use cases to code. This approach involved things like understanding all the scenarios and user interactions (both sunny- and rainy-day scenarios) before trying to do design; taking a little bit of extra time to disambiguate the behavior requirements before attacking detailed design issues; and focusing on object discovery first and "behavior allocation" (assigning operations to classes) later. As the years went by and the number of training classes grew from dozens to hundreds, it became increasingly obvious that the notion of disambiguating behavior requirements using robustness diagrams was one of the most important "fundamental truths" that had emerged from Jacobson's work.

• Operation Requirements: Operations require a name, arguments, and a return. Arguments, or input parameters, are simply attributes, so they are specified using the attribute notation (name, data type, constraints, and default). The arguments do not require constraints when they refer to a previously defined attribute because the constraint should already be defined in the attribute specification. Add a constraint to an argument only if the constraint is unique to the operation and not to the attribute. The return is an attribute data type. You can specify the visibility of the operation: private (-) for internal operations of the class, public (+) for operations visible to other classes, and protected (#) to limit visibility to within the inheritance hierarchy.
  Given these requirements, the following notation is used to define an operation:
  

  

Let's create an example operation to determine the total amount due on an order. The total is the sum of all line items less the volume discount. Each line item amount is the product of the unit price and discount. We need the answer back as a dollar amount.

1. The behavior of a class is represented by its operations
2. Operations may be found by examining interaction diagrams

Classes are drawn as rectangles. Lists of attributes and operations are shown in separate compartments. The compartments can be suppressed when full detail is not needed. A class may appear on several diagrams. The attributes and operations are often shown on one diagram and suppressed on other diagrams. Relationships among classes are drawn as paths connecting class rectangles. The different kinds of relationships are distinguished by line texture and by adornments on the paths or their ends.
Total Order Amount Modeling Operations. In the next lesson, you will learn how to model classes using attributes and operations.

Click the Quiz link below to take a short multiple-choice quiz on modeling operations.
Modeling Operations - Quiz