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.
Entries in the operation compartment are strings that show operations defined on classes and methods supplied by classes
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.
