Model the implementation of your operations with a single sequence diagram for each operation.
Most UML models I’ve seen in my career contain classes with attributes and operations. An Operation is a specification of a behavioral feature. Adding an operation to a class means that you are specifying that your class will respond to a specific request by executing a certain behavior.
So the operation defines the details of the request to be sent to the class (such as name, parameters…), but it doesn’t specify the details of what needs to happen when the operation is called. Those details are stored in a Behavior, and the operation specifies which behavior needs to be executed when it is called.
In the UML metamodel that looks as follows
The abstract Behavior is linked to the abstract BehavioralFeature where Behavior has the role of method and the BehavioralFeature has the role of specification.
So please never again mix up the terms Operation and Method, these are two different things!
From this diagram we also learn that Behavior is actually an abstract metaclass, and that there are four concrete subclasses of behavior that can be used to be the method of the Operation.
A simple textual definition of the behavior one or more languages (such as English, Java, C#…)
The natural owner of an Activity Diagram
The natural owner of a State Machine Diagram
The natural owner of a Sequence Diagram
From these four choices I’ve had the best experience using Interactions containing a Sequence Diagram to express the method of my operations.
Enterprise Architect Example
I created a small example in Sparx Enterprise Architect to illustrate this:
This view of the project browser shows the class MyClass, containing the operation MyOperation. Then there is the MyOperation Interaction which contains the MyOperation Sequence diagram.
In order to specify that the MyOperation interaction is the method of MyOperation operation you need to link them in the Behavior tab of the operation. Clicking the Element button will allow you to select the Interaction to use.
This interaction owns a single sequence diagram which contains the actual details of the implementation.
For the sequence diagram itself I have the following rules or habits:
- First Message
The first message, calling MyOperation on MyClass is not strictly necessary, but it helps the reader to quickly identify for which operation this is the implementation, without having to search for the operation in the model.
The gate “caller” is the representation of any other object calling the MyOperation operation on MyClass. It is important to keep this “caller” anonymous, even if there is only one class that effectively calls MyOperation. In the future other classes may start using MyOperation as well, and we don’t want to start duplicating the sequence diagram to include all the callers of this operation.
- Only messages from MyClass
Since this sequence diagram represents the implementation of the operation MyOperation I only want to show what happens in that operation. So the sequence diagram will only have messages starting from MyClass and it will not show any details of the implementation of operations on SomeOtherClass or YetAnotherClass. These operations will all have their own Interaction and sequence diagram to specify their behavior.
- Objects for “non-static” operations, classes for static operations.
Non-static operations are always called on instances of a class. Static operations are called on the class itself. Notice the difference between the object “:SomeOtherClass” and the class “YetAnotherClass”.
To quickly navigate between operations and sequence diagrams I of course use the free and open source EA Navigator add in.
More UML best practices
- UML Best Practice: Attribute or Association
- UML Best Practice: 5 rules for better UML diagrams
- UML Best Practice: There are no Activities on an Activity Diagram
update 29/05/2011: Changed the “Caller” lifeline into a gate as suggested by Davide. Thanks Davide!