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.
• Definition of Operation and Method: 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
  
  1. 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.
  2. 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:
  

  

1. Operation name: Required
2. Any number of arguments is allowed
3. Return data type: Required for a return value, but return values themselves are optional
4. Visibility: Required before code generation
5. Class operation: Optional
6. Argument name: Required for each argument, but arguments themselves are optional
7. Argument data type: Required for each argument, but arguments themselves are optional
8. Constraints: Optional

• View of the System: 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.

Operation Definitions: 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.

ComputePremium(age:integer, numberofaccidents: integer, driverstraining: boolean):Dollar

ComputeReturnDate(booktype: Category): Date
AverageGrade(grades:listofgrades): numeric{ 2 decimals}
OutstandingOrders(startdate:Date, enddate: Date): integer
TotalPrice(unitprice:Dollar, discount: numeric): Dollar 

Try not to get sidetracked by assigning operations to your classes just yet, that is a detailed design activity.
If you spend time doing that now, you will probably just need to redo it later.
If you leave the behavior implied on the robustness diagram and in the use case, it never gets done on the sequence diagram, and (if you are allocating operations to classes by working through the use cases) it just sort of falls through the cracks to be dealt with in coding-land. The more stuff that falls through those cracks, the less useful the models are, and the less the team will model with enthusiasm.

• Contracts in the UML: Operation Specifications
  The UML formally defines operations. To quote:

  An operation is a specification of a transformation or query that an object may be called to execute

  
  For example, the elements of an interface are operations, in UML terms. An operation is an abstraction, not an implementation. By contrast, a method (in the UML) is an implementation of an operation. A UML operation has a signature (name and parameters), and also an operation specification, which describes the effects produced by executing the operation; that is, the postconditions. The UML operation specification format is flexible, and does not have be the contract format shown in this chapter. However, the UML documents give as examples the contract style with pre- and postconditions, as this is the most well-known approach to formal operation specifications. To summarize: The UML defines operation specifications, which are specifiable in the pre- and post-condition contract style. Note that, as emphasized in this module, a UML operation specification may not show an algorithm or solution, but only the state changes or effects of the operation. In addition to using contracts to specify public operations of the entire System (system operations), contracts can be applied to operations at any level of granularity: the public operations (or interface) of a subsystem, an abstract class, and so forth. The operations discussed in this module belong to a System class. In the UML operations belong to classes. Furthermore, in the UML, "subsystems" are modeled as classes (and simultaneously also as packages). In the UML, the overall "system" is the top-level subsystem, and modeled as a class named System (actually, any name is legal) with public operations and specifications.

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.
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