dynamic modelling in UML

Over on my personal UML style guide Yanic recently asked “I’m wondering why you prefer collaboration diagrams over sequence diagrams?”. Oops, I never really explained that — so here goes…

The main point about my UML style is to make it clear to the reader that the model is a sketch. What I care about with dynamic models is the division of responsibility among objects; I want to show who does what in carrying out this one system responsibility. But I am rarely interested in describing how those objects do their thing; which means that I don’t care to model:

  1. the exact timing of messages and responses;
  2. the type and content of message parameters;
  3. the type and content of message responses;
  4. what other activities the objects get up to before, during or after the collaboration I’m currently describing.

To my mind, a collaboration diagram is more suited to this style, for at least the following reasons:

  1. A collaboration diagram shows objects, whereas an interaction diagram focuses on timelines. I want to depict objects playing roles in a story; timing and the flow of time is (almost) never relevant for that. When whiteboarding or using CRC cards, I want to be able to point to objects; I want to be able to identify with, and play the part of, objects. Tangible, autonomous, anthropomorphic, responsible actors in the story; not column headings in a flowchart.
  2. Those timelines can be interpreted as implying things about the focus of attention of the objects, particularly when they show “method bodies” as blocks of activity in response to an incoming message. It could then be assumed that the model intentionally says something explicit about such things, which I (almost) never mean to do.
  3. I think of the “messages” on a collaboration diagram as indicating delegation of responsibility; whereas the explicit time axis and the receiver blocks in an interaction diagram can make them seem to be actual messages (or worse, method calls).
  4. The diagram names are indicative: “Collaboration” is about apportioning responsibility; “interaction” is about sending and receiving. The latter seems to me to be at a lower level of abstraction.

I know that one can produce an interaction diagram and a collaboration diagram that are logically equivalent, and so my reason for avoiding the former is, in the end, a matter of personal preference. I like models that say only what I want them to say, without implying anything else. Less is more.

One thought on “dynamic modelling in UML

  1. Hi Kevin,

    It’s your style guide of course so keep on doing whatever works for you, but here’s my take on your arguments…

    I find that sequence diagrams show the distribution of responsibilities much more clearly, each activation bar represents a responsibility that an object ‘performs’.

    And you know, you can be just as vague on a sequence diagram as on a collaboration diagram :o)

    About your reasons :

    1. Time and its flow (doesn’t it always flow in the same direction? ;o) is not important to you, then why do you number the messages in your collaboration diagrams? Numbering them or putting them in a vertical order is just the same as far as timing is concerned.

    I find that it is much easier to get an overview from a sequence diagram than from a collaboration diagram, no need to start chasing the numbers.

    2. Well, how those timelines (lifelines really) are misinterpreted depends on the reader I guess. I don’t really understand this point.

    3. They’re messages on both types of diagram. Whether they correspond to method calls or are sent by pigeons is entirely up to you :o)

    4. That’s just an interpretation. Plus, you’re not comparing the right names : ‘interaction diagram’ is the combined name for both diagram types, i.e. both collaboration and sequence diagrams are kinds of interaction diagrams. Besides, what do their names matter, it’s what they convey and how you use them that counts.

    Both diagram types can be used to show how parties interact during a collaboration.

    They are however generally NOT interchangeble. You can always convert a collaboration diagram to a sequence diagram but not the other way around : sequence diagrams have a much richer ‘vocabulary’ and support many elements you cannot put on a collaboration diagram.

    I’ve found that collaboration diagrams only work well for simple interactions. As soon as objects communicate more heavily in a collaboration, the links can become crowded (especially when return values are involved).

    I can understand that if you’re sketching on a whiteboard, you have a preference for collaboration diagrams, they are indeed easier to draw by hand. But if you’re using a computer, I think the improved expressivity and overview you get with sequence diagrams make them the better choice.

    They do have a lot of layout constraints that can make them difficult to create and change if you do not have the right tool.

    However, a good editor for sequence diagrams such as Trace Modeler can make this very easy ;o)

    Btw, as of UML 2 collaboration diagrams are called communication diagrams. UML2 has introduced a new kind of diagram that was dubbed.. collaboration diagram! (bad choice if you ask me)

    If you decide to give Trace Modeler a try, let me know what you think of it and if it was able to ‘convert you to the other side’ so to speak :o) I’m always looking forward to gettings feedback!

    Best regards,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s