dynamic modelling in UML

Posted on January 15, 2008


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.

About these ads
Posted in: howto, UML