I think it’s a matter of the class containing the operation (for what this Class/Operation was designed) if a Sequence, Activity, StM or OpaqueBehaviour is the best choice, isn’t it? Regarding your statement: “From these four choices I’ve had the best experience using Interactions containing a Sequence Diagram to express the method of my operations.”
Sequence diagram in enterprise architect update#
Update : Changed the “Caller” lifeline into a gate as suggested by Davide.
Sequence diagram in enterprise architect free#
To quickly navigate between operations and sequence diagrams I of course use the free and open source EA Navigator add in. Notice the difference between the object “:SomeOtherClass” and the class “YetAnotherClass”.
Static operations are called on the class itself. Non-static operations are always called on instances of a class. Objects for “non-static” operations, classes for static operations.These operations will all have their own Interaction and sequence diagram to specify their behavior. So the sequence diagram will only have messages starting from M圜lass and it will not show any details of the implementation of operations on SomeOtherClass or YetAnotherClass. Since this sequence diagram represents the implementation of the operation MyOperation I only want to show what happens in that operation. 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. It is important to keep this “caller” anonymous, even if there is only one class that effectively calls MyOperation. The gate “caller” is the representation of any other object calling the MyOperation operation on M圜lass. The first message, calling MyOperation on M圜lass 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. This interaction owns a single sequence diagram which contains the actual details of the implementation.įor the sequence diagram itself I have the following rules or habits: Clicking the Element button will allow you to select the Interaction to use. 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. Then there is the MyOperation Interaction which contains the MyOperation Sequence diagram. This view of the project browser shows the class M圜lass, containing the operation MyOperation. I created a small example in Sparx Enterprise Architect to illustrate this: The natural owner of a State Machine Diagramįrom these four choices I’ve had the best experience using Interactions containing a Sequence Diagram to express the method of my operations. So please never again mix up the terms Operation and Method, these are two different things!įrom 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.Ī simple textual definition of the behavior one or more languages (such as English, Java, C#…) The abstract Behavior is linked to the abstract BehavioralFeature where Behavior has the role of method and the BehavioralFeature has the role of specification.
In the UML metamodel that looks as follows
Those details are stored in a Behavior, and the operation specifies which behavior needs to be executed when it is called. 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. 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. An Operation is a specification of a behavioral feature. Most UML models I’ve seen in my career contain classes with attributes and operations. Model the implementation of your operations with a single sequence diagram for each operation.
0 kommentar(er)
