Logical View  «Prev 

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

Use Case Driven Approach

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.