interfaces and impl classes in sequence diagrams?

[Joe Boxer]

I have a question about using interfaces in sequence diagrams.

Scenario:
A client handles with objects via interfaces. Now, the client invokes only methods of an interface of an object. What is the proper way to model it in a sequence diagram? Do I describe the interaction only using the interfaces or should I use the impl objects instead? Or both? I could still describe the interaction as the main actor sends a message to an interface and the interface forward the message to the impl class. But that would increase the maintenance and complexity of the sequence diagrams.
Is using interfaces in sequence diagrams recommendable or bad practise?
cheers
Joe

[Ilja Preuss]

Invocation through an interface can be indicated by a lollipop:

+---------+               +---------+
| :client |               | :server |
+---------+               +---------+
     H                         |
     H                         |
     H -------> O----------->  H
     H         MyInterface     H
     H                         H
     H

Wether you should do it depends on why you are drawing the diagram. You need to decide wether the audience will find the information valuable, or wether it will just add clutter and distract from the point you want to make. If in doubt, ask someone from the (potential) audience.
Hope this helps...

[Ilja Preuss]

BTW, the lollipop should be filled. My keyboard is somehow missing this essential symbol...

[Stan James]

Interesting notation. Is that new on sequence diagrams?
My first thought was to always show the interface as it's more general and has broader application. But if you're really talking about a concrete class and just want to show that it's providing this method because it implements this interface, that notation is pretty neat.

[Ilja Preuss]

Mhh, I think I've learned it from "UML for Java Programmers", but I am not sure. It's pre UML 2.0 anyway.
As far as I know, it doesn't only mean that server is implementing MyInterface, but also that client actually only has a reference of type MyInterface to the server object.
That is, the code could look something like

class MyServer implements MyInterface {
...
}
class MyClient {
  private MyInterface server;
...
}

[Stan James]

Interestinger and interestinger! Some clients might know the conrete class they're dealing with while others might know only the interface, all in the same diagram. (Sounds like a wacky sit-com to me. Hilarity ensues!) This kind of modeling gets so precise and so subtle it can take a lot more time than the code.

[Ilja Preuss]

Originally posted by Stan James:
This kind of modeling gets so precise and so subtle it can take a lot more time than the code.

Yes. That's why it's important to not do those things just because you can, but only if it helps you make your point. In a discussion on a whiteboard, for example, I wouldn't use the lollipop until I felt that the missing information leads to confusion. Such as in "I don't like coupling Foo to Bar just to be able to call zump() on it" "We don't have to, we can introduce a Zumpable interface for that [adds the lollipop]".

[Thomas Taeger]

I agree on normally using interfaces.

And maybe one or some few abstract classes "on the rightmost end" of a sequence diagram. I found very few cases where to use concrete classes.

By the way: I hate lollipop interfaces in class diagrams because even in UML 2.0 I can not find a clean, non-redundant way to use provided and required lollipops and all the same to declare the methods in one interface instead of within N classes. (using Together Designer 2005)

Thomas.

[Scott Ambler]

An interface is a classifier, therefore it can appear as one of the boxes across the top of a UML sequence diagram.

- Scott

[Ilja Preuss]

Originally posted by Thomas Taeger:
I hate lollipop interfaces in class diagrams because even in UML 2.0 I can not find a clean, non-redundant way to use provided and required lollipops

I have no idea what you are speaking about. What is the difference between a provided and a required lollipop?

declare the methods in one interface instead of within N classes. (using Together Designer 2005)

Sounds more like a tool issue to me, or an issue of using UML as a blue print instead of as a sketch.

The way I use lollipops, they are shorthands for the actual interfaces. I use them when the actual methods implemented by the interface are not the important point to communicate.

[Scott Ambler]

At UML 2 interface style guidelines I show examples of both provided and required interfaces. A provided interface is shown as a lollipop (a short line with a circle on the end) and a required interface is shown as a socket(a short line with a C on the end of it). The idea is that the cup fits over the lollipop in a "ball and socket" notation, as you can see in the third diagram on that page.

So, UML 2 does in fact support this notation. Whether the tool(s) you're using support it is a different issue. A fundamental rule to keep in mind is that whenever a tool vendor claims to support UML 2, what they're actually doing is support their version of a subset of it. Don't get fooled by the marketing rhetoric of tool vendors.

- Scott

[Ilja Preuss]

Originally posted by Scott Ambler:
At UML 2 interface style guidelines I show examples of both provided and required interfaces.

Ah, yes, I remember. I just didn't remember the terminology. Thanks!