CODEWITHSUNDEEP
umlclass-diagramsequence-diagram
Tim Bezhashvyly
Tim Bezhashvyly

Reputation: 9100

Abstract/concrete class separation at sequence diagram

Is there a way to separate abstract class and it's concrete branches at a sequence diagram?

My use case is that some transactions must hit methods implemented in abstract class and some from its concrete implementations.

Or it is a concern of a class diagram and not a sequence diagram?

Upvotes: 3

Views: 10571

Answers (2)

xmojmr
xmojmr

Reputation: 8145

If you want to model two different classes then in the Sequence Diagram it would mean two different lifelines. That is all (as far as I know).

You can show any <<stereotype>> (including <<abstract>>) in the lifeline head as in this example: uml-diagrams.org: UML Sequence Diagrams Examples → Submit Comments to Pluck

For example, let's suppose we have this (useless) C# code:

abstract class BaseClass
{
    protected abstract string Name { get; }

    public virtual void DoSomething()
    {
        Console.WriteLine("Something useful done.");
    }

    protected void SayHello(string to)
    {
        Console.WriteLine("Hi {0}, I'm {1}", to, this.Name);
    }
}

class Case1 : BaseClass
{
    protected override string Name { get { return "Case 1"; } }

    public override void DoSomething()
    {
        base.DoSomething();
    }
}

class Case2 : BaseClass
{
    protected override string Name { get { return "Case 2"; } }

    public void DoSomething(string to)
    {
        this.SayHello(to);
        base.DoSomething();
    }
}

class Program
{
    static void Main(string[] args)
    {
        var c1 = new Case1();
        var c2 = new Case2();
        c1.DoSomething();
        c2.DoSomething("Jane");
    }
}

Then UML Sequence Diagram capturing what happens withing the Program.Main might look like this:

enter image description here

I drew the abstract class as implicit friend object sharing the lifetime (and most of the memory) with the concrete class instance. It is actually how is class inheritance implemented in some languages so the scenario is not completely "made-up".

However, the level of detail maybe too much focused on the implementation leaving no place for useful abstraction. This diagram would not survive even small code re-factoring

Upvotes: 0

Geert Bellekens
Geert Bellekens

Reputation: 13740

In your sequence diagram you should only use objects of the types you know them to be at that particular point in execution.

Then you call the method on that object, even if it is a method implemented on the abstract parent class.

Sequence diagrams are very much like code int hat respect.

So suppose you have following situation: Class diagram

Then you call both the implemented as the abstract operation on an object of ConcreteSubClass, because your user class has an association to ConcreteSubClass, regardless of where the operation is implemented.

Sequence diagram

If the User class had an association to the AbstractClass then you call the operations on an object of type AbstractClass

Upvotes: 5

Related Questions