2

I've a bunch of classes where one is Abstract class. I draw few derived class from that Abstract base class. For example,

class IBase{
public:
 *register(): bool*
 *update(): bool*
};

class Derived: public IBase{
 // implement register ()
 // implement update ()
};

class Derived2: public IBase{
 // implement register ()
 // implement update ()
};

while drawing the sequence diagram, I'm not sure, how to represent the interaction among abstract class and derived class. What are the standard in this regards?

Any help is highly appreciated.

Thanks.

3
  • Derived lifeline communicates with IBase(1) lifeline and Derived2 lifeline communicates with IBase(2) lifeline
    – xmojmr
    Oct 30 '17 at 13:15
  • 3
    Which UML diagram? If you are modeling class structure, that's pretty straight forward. However, with interactions, Derived and Derived2 are an IBase. There's nothing to model. You model their interactions with other classes and leave the base class out. Oct 30 '17 at 17:42
  • Class diagrams are not the same as sequence diagrams. Oct 30 '17 at 18:46
2

In a sequence diagram, you model the interactions between lifelines. Each lifeline represent a different instance of a type (aka a different object).

So in principle you would represent IBase, Derived and Derived2 in the same sequence diagram, only if there were several different objets of these types. You would then have a distinct lifeline for each object. Their interactions would not depend on the inheritance between the types, but on the "messages" that are exchanged between the instances (e.g. function calls and returns).

You would therefore not show the interaction between a derived class and its base class in a sequence diagram, because both lifelines would in reality refer to the same object.

3
  • I would push a bit further, unless you have a specific reason, you should either have only IBase presented, or only implementations. In the first case it is because you abstract the implementation from the sequence diagram. In the second, it would be because you have a very specific case that require a specific implementation to be used.
    – Walfrat
    Oct 31 '17 at 15:37
  • @Walfrat Excellent argument ! I fully agree !
    – Christophe
    Oct 31 '17 at 16:16
  • Small typo on "instane of a type" (too short for me to edit!) Nov 1 '17 at 21:38
0

I've taught sequence diagrams often, and it's common for students to think that an abstract class is between the sender and the receiver of a message, like a kind of intercepting class object. In fact, I believe sequence diagrams are a great way to catch misunderstandings about polymorphism.

To elaborate on @Walfrat's comment, sometimes it's useful to show the perspective of the design with the abstract class and the perspective of the details of the implementations. However, it takes two diagrams to do this.

I often cite his book (because a lot of the questions with the UML tag are covered in it!) but Craig Larman tackles it with the Monopoly example in Chapter 25.

Showing a call that's polymorphic

The landedOn() is a polymorphic call that will have many implementations, depending on the instance of Square that receives the message. We are maybe not interested in the details from this perspective.

Here are a few diagrams at the perspective of the implementation of the polymorphic call. We, assume that GoSquare and IncomeTaxSquare are both subclasses of the abstract Square class:

GoSquare

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.