Episode 3: Pestbusters II

Friday, September 26, 2008 – Three weeks of analysis, design, and testing later, Supervisor and The Reader meet in the Lounge.

 

Adding Collaborating Actors to a Use Case Diagram

Here we see our ideas from Episode 2 expanded and elaborated. Again, Use Case Diagrams are about requirements in context. Actors are persons or things that are outside your system but that interact with your system. By adding Collaborating Actors, you can show participants in the goals of an initiating Actor.
Who or what has to provide information as your system works through the Use Case? Who or what must be notified of the results?

And I emphasize or what. In our examples so far, the Actors have all been people (or Pest, who counts as a person for this example). But another computer system or device that participates in a Use Case also counts as an Actor from a requirements perspective. When we look at deployment, we’ll model these as systems or devices (there’s a surprise…); but from a requirements point of view, you probably do the same work when a person files a damage claim as when an automated system files the damage claim.

UML stereotypes and custom icons

Once I’ve explained this, you can easily grasp the concepts that Actor means outside person or thing and stick figure means Actor. So if you were working on my current client’s project (diagnostic systems for Harley-Davidson motorcycles[1]), you would be comfortable with this image:

 

 

 

 

But Use Case Diagrams aren’t just for you! As I discuss below, your customers should review these to help you validate them. And I guarantee that when my end customers see this picture, they’re gonna ask, “Who’s this person called Motorcycle? Is that the rider, or the owner, or the technician, or…?” UML is all about communication, and I just failed to communicate.

There’s an answer for this, and it’s found in UML stereotypes. A stereotype is a custom extension to the UML notation. From a UML perspective, a stick figure called Motorcycle is perfectly sensible. UML has no need for a special notation just for motorcycles. But my project does. So in my Motorcycle Diagnostics model, I added a stereotype: <<motorcycle>>. UML uses <<double angle brackets>> to indicate stereotypes. When you define a stereotype, you’re defining your own local “dialect” of UML.

Now that I’ve explained that notation, it’s easy for you to pick out the motorcycles in this picture:

 

 

 

 

But when the customers look at this diagram, once again they’re gonna ask, “Who are these people? The riders?”
For as long as people have been drawing pictures, “stick figure” has meant “person”. Don’t expect that to change just because you’re now speaking UML.

But never fear! UML can be further extended by defining a custom icon for a given stereotype. When you have nonhuman Actors, you can increase the readability of your diagrams a lot by creating custom icons. For instance, there’s no confusion when my customers look at this diagram:

 

 

 

That is communication. Bad art, but communication.

In fact, this comic strip is full of stereotypes from start to finish. Every character in this strip should be a simple stick figure, like Technician in the diagram above. But that wouldn’t be nearly as much fun.

Who is the audience for UML diagrams?

I’m often asked that question: “Who should read these diagrams? Who are we drawing them for?”

And the response I often hear, even before I can answer, is “Ewww, these are complicated. Let’s just keep these to the development team.
And whatever you do, don’t show them to the customers! That will scare them away!”

The question and the response are natural if you think of UML in the wrong way, the way I think is all too common: as a technology discipline.
It’s not. I’m gonna say this again (and again, and again, and…): It’s all about communication.
So the answer to “Who should read these diagrams?” is “Who are you communicating with?”

Now specific diagrams may be better suited to some audiences than to others. In my first speech class, Mrs. Roberts taught us the importance of MAP:

  • Medium: What medium are you using to convey your message? (Medium can also include setting.)
  • Audience: Who are you trying to convey it to?
  • Purpose: Why are you conveying it?

Your Purpose will vary at different points in your process. Sometimes you’re trying to understand user needs, and sometimes you’re trying to work out complex implementation issues. And different messages are aimed at different Audiences. If you’re discussing requirements, your Audience includes
customers and end users. For that audience, Use Case Diagrams are entirely appropriate if you draw them in the customer’s language.

In later Episodes, we’ll see Activity Diagrams. Again, those are very appropriate for customers, because they’re just pictures of the customer’s business rules. We’ll add Swimlanes to these, representing parts of the system. Those may be appropriate for customers, depending on whether they’re
“visible” parts or “internal” parts. We’ll see Class Diagrams, which can be appropriate for customers, depending on the level of detail.

Who is the Audience for UML diagrams? The best answer I can give is the Universal Answer: “It depends…”

[1] As described at http://www.spx.com/Archive/pdf/ideas_in_action/Harley%20Davidson_08.pdf.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.