Geeks With Blogs
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.

Continuing The Project That Time Forgot, a UML case study in comic strip form... (Click pictures for larger images.)

Ulterio Motive Lounge Episode 30

Ulterior Motive Lounge Episode 30A

Here, for your convenience, is a larger version of the activity diagram from panel 2:

Dinosaur Growth Recipe

Figure 1: The Recipe for Growing a Dinosaur

And here is Editor Bill's comment on that diagram: "I hope in the commentary you plan to explain that this activity diagram tells the story of the rest of the Episode." Well, no, Editor Bill. I hoped that by now my readers were UML-savvy enough to figure that out on their own. You're not the only smart reader I have, you know? (Bloody Editor Bill's too smart, keeps figuring out my strategies before I can reveal them. Next thing you know, he's gonna grab my drawing pen. Uh-uh, no way, Editor Bill! This pen is mightier than the sword!)

That diagram is also almost a logical sequencing of the use cases from this diagram from the previous Episode:

Geneticist and Embryologist Use Cases

Figure 2: Geneticist and Embryologist Use Cases

But that's a use case diagram, and the new diagram is an activity diagram. Which is the right way to show this information? Should we draw use cases, or should we draw activities?

Those who know me might guess that my answer is: Yes. (They've heard it too many times: "Whenever you ask me 'A' or 'B', I'll always answer 'Yes' or 'C'.") But in this case, my answer is more nuanced: "Whichever one communicates better; and that may mean drawing both of them." Which of course is a longer way of saying "Yes."

As I mentioned in Q&A #2: Battle of the Twitter Guest Stars!, one purpose for an activity diagram is to show what happens "inside" a use case. So the Figure 1 could be a diagram of what happens within this hypothetical use case:

Grow Dinosaur Use Case

Figure 3: The Grow Dinosaur Use Case

Why do I call this a hypothetical use case? Well, to my way of thinking, it's rather large. Based on what The UML Guy has learned about the laboratories, the process from DNA extraction to a dinosaur ready for release into the Park consists of multiple complex operations, possibly iterations of operations, over weeks to months. I like my use cases to be a lot smaller and more atomic than that. The use cases Isolate Sequence, Replicate Sequence, etc., look a lot more like use cases to me. Grow Dinosaur looks a lot bigger, like some large scale business process.

But here's where it gets a lot more complicated, and where I have to stop giving you easy answers. More important, I have to stop giving you just my answers, because I don't want you to be limited by my biases. I want to suggest other ways of looking at use cases. In fact, I'm seriously hoping that some of the Business Analysts in my audience will add comments and start a discussion, so that the rest of you can see the gamut of approaches to use case modeling.

Because here's the thing: many Business Analysts, including many I respect a lot, would say that Grow Dinosaur is about the right size for a use case. In fact, some might even claim that it's too small, and would prefer a more generalized use case like Care for Dinosaurs.

I once heard an experienced analyst say confidently he had worked on a very large system for a client, the largest system he had ever worked on. In fact, it was so large, it had fifteen use cases! Oh, that was for the entire business operations of a multinational corporation, so it had to be big. But just imagine, he said, fifteen use cases!

And I once heard another experienced analyst say just as confidently that the user interface he was modeling wasn't very complex. After all, it wasn't much more than a dozen or two use cases. That's tiny, right? He was used to working with 80 use cases in a system.

And here's the kicker: those two analysts, one who saw 15 as unimaginably huge and one who saw 24 as kind of small, worked for the same very respected consulting company.

 

 

 

 

In other words, there’s a lot of disagreement in the analyst community over the right level of granularity for use cases. Some see use cases like Shipping and Manage Personnel and Manage Facilities, while others see use cases like Order Supplies and Schedule Repairs. Some see use cases in individual button pushes. Who’s right? I dunno. I gave up trying to answer that question a long time ago. I listen to one point of view, and I say, “Hey, those arguments make a lot of sense!” Then I listen to another point of view, and I say, “Hey, those arguments make a lot of sense!” And then I put them together, and I say, “Hey, this doesn’t make any sense…”

I’ve decided that the difference isn’t in right or wrong, it’s in what level the analyst thinks at and is comfortable thinking at. Those who think at the enterprise level see enterprise use cases like Shipping and Manage Personnel and Manage Facilities. Those who think at the project level see project use cases like Order Supplies and Schedule Repair. Those who think at the UI level see use cases in individual button pushes. And all of those levels are valuable, and none is “right” or “wrong”.

But there’s probably a big difference in the level of documentation for different levels of use cases. The exhaustive level of detail prescribed by, say, Cockburn’s Writing Effective Use Cases may be appropriate for a use case like Manage Facilities; but it’s massive overkill for a use case like Log In. Business analysts have told me horror stories of 15-pages of documentation for Log In; and I’m fairly sure it’s because they were applying enterprise-level documentation practices to application-level use cases.

So in sum, I find the argument over the “proper” granularity of use cases to be pointless. Oh, for a given analysis project, that argument matters: an enterprise analysis effort can’t afford to get bogged down in use cases like Log In and Change Password, or they’ll have thousands of use cases; but an application analysis effort needs more detail than Manage Facilities (and less detail than 15 pages on Log In). But when I see arguments over the “proper” granularity, I can usually resolve them by discovering that the parties arguing are working at different levels.

And far more useful to me is this simple fact: the use case strategy, the use case way of thinking about requirements and solutions, is powerful at all levels of analysis. I’ve used this strategy from way out at the enterprise level all the way down to the level of individual classes. This strategy of saying “Who needs some work done? What’s the work? Who else participates? What information or objects are involved and affected?” has great probative power. If you want to say that Order Supplies isn’t a use case, fine. Call it a feature. Call it a function. Call it a benefit, an operation, a a method. Call it an Apatosaurus for all I care. I don’t care what you call it; I care how I think about it and describe it and figure out how to resolve it. And how I do that is the use case strategy. I’ll call it a use case, and you can laugh at me if you like.

But those who adamantly insist on a “proper” granularity will often also insist on a rule: “Thou shalt not decompose use cases.” And I’m going to completely ignore them when they say that, because to me it means, “Thou shalt not examine use cases at one level and think how they may be realized via use cases at a deeper level.” And as much as I’m loath to use such a black-and-white word as “wrong”, that’s just wrong. When I start to think about the problem at a deeper level, I will think about finer-granularity use cases that make up the use cases from the upper level. For example:

Grow Dinosaur Use Case and Details

Figure 4: The Grow Dinosaur use case, plus detail use cases

In this use case diagram, I introduced some new UML notation: I added two boundaries. A UML boundary is just a box that groups related diagram elements. In this example, the boundaries represent two different perspectives on the system. Operations needs a strategic view. To them, growing a dinosaur is one task they want carried out: “Yeah, this is Ops Chief. We’re ready to start planning the Back Lot now. Could you start growing us some Velociraptors? Thanks!” From that strategic view, Grow Dinosaur is one use case. Meanwhile, the Laboratory sees a number of complex operations that they carry out on different samples and eggs and newborn dinosaurs. From their more tactical perspective, there are many dinosaur-related use cases. So I used the boundaries to help separate these perspectives while still showing them on a single diagram. To me, there’s great value in thinking at the strategic level and then moving to the tactical level, and even deeper. That means there’s great value in decomposing use cases. Others are free to disagree, but I’m going to keep doing it.


Other comments on today’s Episode…

  • Why does Dr. Gene carry around a giant DNA strand? Because I like it! It started life as the spiral staircase from Episode 25; and from there, it kind of grew unexpectedly. Sometimes things grow beyond our plans, and the unexpected happens. The same thing has been known to happen with dinosaur parks. And with comic strips…
  • Yes, I have seen UML diagrams adapted into marketing materials. After all, if a diagram communicates, it may communicate to the audience as well. Of course, most UML tools produce kind of bland diagrams, so the art department usually jazzes them up to the point where the modelers may no longer recognize them.
  • Editor Bill immediately saw the bad joke in panel 5; and he liked it, so I kept it. You can blame him. (But he wouldn’t let the crocodile say, “Ow!”)
  • Cladistics is the hierarchical classification of species based on evolutionary ancestry. You examine the DNA of different species and determine how closely related they are and when they diverged evolutionarily by how closely their DNA matches. It’s also the subject of a fascinating essay by Stephen Jay Gould. (“A fascinating essay by Stephen Jay Gould” may be one of the greatest redundancies I’ve ever written.) To my knowledge, there’s no such thing as cladistic reversal, but it seems like a really clever idea for recreating ancestral DNA by isolating it from descendant species. Hey, you have a better idea for growing dinosaurs, fine, you can open your own park. In my Park, they use cladistic reversal!
  • While cladistic reversal is fictitious, the lab equipment in panel 6 is certainly of the highest quality.
  • In the second page, notice that many of the dinosaurs have the Name : Class format for their labels, such as we first saw in Episode 15. Remember that we typically omit the name if there’s only one instance of a class in a diagram, particularly if the diagram shows what is true for all instances of the class. But when we want to examine different instances – in this case, different dinosaurs – and tell them apart, then we add names.
  • Despite the name (Carnivore Park), all of the dinosaurs in that last scene are herbivores. This is the safe, open section of the Park. Trust me, the carnivores are coming in Act II!
Posted on Wednesday, January 7, 2009 2:22 AM Ulterior Motive Lounge | Back to top


Comments on this post: Ulterior Motive Lounge Episode 30: Touring the Laboratories

# Mightier than the sword?
Requesting Gravatar...
You can bring your pen to fencing class whenever you feel like sparring, my friend...
Left by Editor Bill on Jan 07, 2009 8:56 AM

Your comment:
 (will show your gravatar)


Copyright © Martin L. Shoemaker | Powered by: GeeksWithBlogs.net