Ashay Batwal
Ashay Batwal

Reputation: 5613

How to represent calls within same class using UML-Sequence diagram

I am trying to create UML sequence diagram for a particular process in our application.

The problem is that most of the business logic is in one class and when I try to map it in sequence diagrams, I am getting multiple calls to the same objects in the sequence diagram.

What I need is a representation similar to a stacktrace in UML sequence diagram. Is it possible using sequence diagram or is some other diagram a better way for representing calls within the same class? Please advise.

Upvotes: 23

Views: 54386

Answers (3)

Andrea Sindico
Andrea Sindico

Reputation: 7440

It is actually possible to refer to the self instance

In fact UML spec 2.5b1 page 607, about a Lifeline is said: If the name is the keyword self, then the Lifeline represents the object of the classifier that encloses the Interaction that owns the Lifeline. Ports of the encloser may be shown separately even when self is included.

See https://web.archive.org/web/20131101211441/http://lowcoupling.com/post/47844944042/uml-sequence-diagrams for a complete example

Upvotes: 4

Martin Spamer
Martin Spamer

Reputation: 5585

Representing a self-call on a UML sequence diagram (see step 7).

self-call on a UML sequence diagram

If the called method is (or should be) private, then it can safely be excluded from the sequence diagram as an implementation detail.

However I smell the God-Class anti pattern; your class has multiple responsibilities and should be deconstructed. Break down the class so that is has only a single responsibility using delegation. Those method calls would be a good starting point.

Upvotes: 15

sfinnie
sfinnie

Reputation: 9952

A few suggestions:

  1. You can show successive methods on a sequence diagram using self calls. See Figure 1 here for an example (self calls are the circular invocations on the same lifeline).
  2. As an alternative you might consider an Activity Diagram. Possibly better suited for illustrating order of methods.
  3. Refactor the code. Lots of logic in a single class is usually a bad smell. Assuming you have the scope, refactoring might be a good idea.

hth.

Upvotes: 16

Related Questions