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:
  

  

All these models, however, reflect only a partial view of the system. Many puzzle pieces are still missing and many others are yet to be refined. The goal of object design is to produce an object design model that integrates all of the above information into a coherent and precise whole. The goal of interface specification, the focus of this chapter, is to describe the interface of each object precisely enough so that objects realized by individual developers fit together with minimal integration issues. To this end, interface specification includes the following activities

1. Identify missing attributes and operations. During this activity, we examine each subsystem service and each analysis object. We identify missing operations and attributes that are needed to realize the subsystem service. We refine the current object design model and augment it with these operations.
2. Specify visibility and signatures. During this activity, we decide which operations are available to other objects and subsystems, and which are used only within a subsystem. We also specify the return type of each operation as well as the number and type of its parameters. This goal of this activity is to reduce coupling among subsystems and provide a small and simple interface that can be understood easily by a single developer.
3. Specify contracts. During this activity, we describe in terms of constraints the behavior of the operations provided by each object. In particular, for each operation, we describe the conditions that must be met before the operation is invoked and a specification of the result after the operation returns.

The large number of objects and developers, the high rate of change, and the concurrent number of decisions made during object design make object design much more complex than analysis or system design. This represents a management challenge, as many important decisions tend to be resolved independently and are not communicated to the rest of the project. Object design requires much information to be made available among the developers so that decisions can be made consistent with decisions made by other developers and consistent with design goals. The Object Design Document, a live document describing the specification of each class, supports this information exchange.

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