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.)

Ulterior Motive Lounge Episode 27

There's the business, and then there's the role of the system within the business. If all you focus on is the role of the system, you can miss chances to see where the system's really needed.

So time permitting, I would rather start by understanding the whole business and then work inward. Oh, sometimes the division is very clear: if my client asks for a change to their payroll system, I probably don't need details about their waste management system.

Or do I? What if the waste management staff is made up of hourly employees? What if excess waste problems can result in overtime? What if that overtime gets charged to a different budget, such as the Environmental Quality Initiative?

The boundaries between "business" and "problem domain" can be fuzzy, and it's easy to cross the boundaries without realizing it. I find it's easier to start with a broad scope and narrow in than to start with a narrow scope and expand.

And if I had to pick the number one category of overlooked Actors in requirements analysis, it's the development and maintenance teams themselves. Customers think about what they need from your system; but how often do they think about what you need from the system? Do they think about running diagnostics to chase down problems? Do they think about maintenance and archiving of data? Do they think about staging and deploying patches and new releases? Do they think about detecting and tracking defects and problems and patterns of usage and percentage of down time? Do they think about support personnel and the tools they'll need to keep users running?

Maybe. Maybe, if they're a very experienced system buyer. But most often, the answer is no. If you don't think of the development and maintenance and support staffs as Actors, and you don't identify their Use Cases, no one will. Then you'll deploy, and the system will need maintenance, and your users will need support, and you'll have no tools to help them. And when you start trying to retrofit the tools after the fact, someone will say "You should've thought of that." And they're right. You should have. You're the professionals here.

So Owner has done a good job of identifying the "stars" of the story. These are Actors you will see again as the story plays out. (Trust me: if I didn't need them in the story, I wouldn't draw them. I'm just too busy to draw characters I don't need. (Somewhere Editor Bill and Curtis Gray are stunned into disbelief at that remark.)) But he has barely scratched the surface of the full Park staff. After much longer discussions, The UML Guy identified these basic classes of Actors:

Park Actors

This is a common pattern in many of my models:

  • Users are anyone who might be involved with the system in any way. They may be anonymous visitors to the Park's Web site; or they may be more specific Actors, as described below.
  • Authorized Users are Users who have permissions to do something on the system that Users can't do. This is represented in the diagram above as a set of Authorizations. Different Authorized Users will have different Authorizations. We'll get more specific about what that means when we get closer to code.
  • An Employee is an Authorized User that works within the organization and has additional Authorizations as a result.
  • A Supervisor is an Employee with a Staff of Employees, along with additional Authorizations and responsibilities.
  • A Vendor is an Authorized User who isn't employed by the business, but who provides services to the organization and may have additional Authorizations and responsibilities.

In addition, this model has another class of Authorized Users: Guests. We want each Guest to have Web access to Park content, so that we can sell additional services and souvenirs to them. And then Priority Guests are Guests who pay for full Internet access.

After identifying these major classes of Actors, the team identified more specific versions of each. The Vendor Actors diagram is the simplest:

Vendor Actors

The Supervisor Actors are more numerous:

Supervisor Actors 

The Employee Actors are where the "Actor Explosion" comes in. This is just the first diagram; more detailed Employee diagrams follow:

Employee Actors

Most (but not all) of these Employee classes have more detailed Employees below.

Here are the Ops Staff Actors:

Ops Staff Actors

And Ops Staff is complex enough to require two even more detailed diagrams. Here are the Transport Staff Actors:

Transport Staff Actors

And here are the Facilities Staff Actors:

Facilities Staff Actors

Here are the Laboratory Staff Actors:

Laboratory Staff Actors

Here are the Lodge Staff Actors

Lodge Staff Actors

Here are Concession Staff Actors:

Concession Staff Actors

Here are the Marketing Staff Actors:

Marketing Staff Actors

And finally, here are the Medical Staff Actors:

Medical Staff Actors

Whew! That's a total of 86 different classes and subclasses of Actors! And I'll bet if I spoke to people in the transport, hospitality, marketing, or amusement industries, I'd find more. Owner's 8 Actors may be the most important, but they're less than 10% of the total set of Actors.

And I haven't even started looking at system and device actors. We'll likely end up with around 100 candidate Actors. Will we need all of them? Probably not. But I'm more comfortable now that we haven't overlooked anything.

And yet categorizing isn't enough! We really need to understand relations between them as well. For instance, Employees report to Supervisors. Here is a rough Org Chart for the Park staff, with an arrow from each Employee to the Supervisor to which she or he reports:

Park Org Chart

There's one more lesson in this Episode: although I see this work as identifying Actors, I went a little farther than that, identifying their goals and motivations as well. That's a step down the road to identifying Personas, as described by Alan Cooper in About Face and The Inmates Are Running the Asylum. In fact, since these are fictional characters, it's a lot like defining Personas. Cooper argues that by creating fictional Personas that represent users with personalities and motivations and goals, you create a filter to differentiate "okay software that someone can use" from "great software that will really satisfy this person's goals and make this person happy". I like a lot of what Cooper has to say in these books. I'm not 100% persuaded yet, but he's persuasive. Of course, I've also gone way overboard by his standards. He recommends typically around 3 Personas, 5 for a big project. I have 8, plus the review team, plus almost 80 more Actors. But I have them in part for the demands of the story, not the system. If Alan Cooper were doing Interaction Design for this project, he would likely focus on just one or two of these Actors, and flesh them out to a handful of Personas, and work on designing great software for them. Then he would focus on other Personas over time.


Posted on Friday, December 5, 2008 5:34 PM Ulterior Motive Lounge , UML , Requirements Patterns and Antipatterns | Back to top

Comments on this post: Ulterior Motive Lounge Episode 27: Meet the Crew

# re: Ulterior Motive Lounge Episode 27: Meet the Crew
Requesting Gravatar...

excuse my misunderstanding, but you are using the same type of arrow to show a "has a" (such as the supervisor who has employees to supervise in the earlier charts) relationship and then again used for the "reports to" (in the large hierarchy at the end) relationship. Also this arrow is used to show a relationship between an authorized user and the act of authentication. Are there minor differences that I'm missing? Is it that the "has a" or child relationship also specifies a count, and the "reports to" does not specify a count, and is used to both associate actions and related persons?

Also, just checking on that request for good books on UML design for architecture. Your book seems to be something I could relate to, but you did mention you might have other recommendations.
Left by Stacy Vicknair on Dec 08, 2008 11:15 AM

# re: Ulterior Motive Lounge Episode 27: Meet the Crew
Requesting Gravatar...

Yep, it's the same arrow. Technically, it's called an Association: A is associated with B. Could be "has a", "uses a", "reports to", or a number of other possibilities. In UML, they try to keep the number of different kinds of arrows small, because a lot of different kinds of arrws adds confusion. Instead of "One arrow for every purpose", they have a small number of arrows, and then add a text label for specifics. The triangle arrow for inheritance or generalization or "special case" is one arrow. A dashed arrow for "depends on" is another; and that's a trocky concept until you get used to it, but I can explain more when you're ready. For most everything else, it's just a plain arrow from A to B if A "owns" or "controls" the relationship; or a plain line if A and B can both use the relationship equally.

As for architecture books: the one I remembered was "Applied Software Architecture" by Hofmeister, Nord, and Soni. UML is not their main thrust, but they use a lot of UML diagrams for communicating concepts. Fowler's "Patterns of Enterprise Application Architecture" is a lot deeper, and also makes a lot of use of UML. (Fowler's "UML Distilled" is probably the seminal book on UML, and has a little architectural perspective to it.) Ambler's "Agile Modeling" is about a lot more than UML and a lot more than architecture, but touches on both.

I hope this helps! Please let me know if you have further questions.
Left by Martin L. Shoemaker on Dec 08, 2008 2:13 PM

# re: Ulterior Motive Lounge Episode 27: Meet the Crew
Requesting Gravatar...
Hey Martin,

I hope you're doing well, I'm guessing a busy new year for you! Well, I wanted to let you know I've peeked at Fowler's book and I've also started looking over a book that's been on my list, Head First Design Patterns. The book is in Java but I'm reworking the examples in VB.NET. The book has some praise from the original GoF for its content.

I'm bringing the book up because it also gives a brief introduction to UML (mostly as it pertains to class diagrams) in a very non-threatening way. They also precursor the book by stating that it might not be pure unadulterated UML, but I'm seeing the obvious parrallels between what I see here at the lounge and in their works.

Altogether, I'd recommend you give this book a skim if you get the chance. The head first methodology is something that meets nicely with your approach here in the lounge.

Let me know of your thoughts,
Left by Stacy Vicknair on Jan 03, 2009 1:50 PM

# re: Ulterior Motive Lounge Episode 27: Meet the Crew
Requesting Gravatar...

I have that book. At one time, the editor was discussing me writing a book in that series, so she sent me a copy. I also recommended it to a coworker who doesn't learn well from more traditional texts.

Oddly, the book didn't reach me. Even though I understand their approach, somehow I couldn't appreciate it. I think they have the right idea, trying to present the content in different and engaging styles; so I want to like the book. But I was in a high pressure job situation at the time, and wanted a "just the facts" approach. I need to try it again now that I'm in a less stressed mood.

Left by Martin L. Shoemaker on Jan 05, 2009 9:54 AM

# re: Ulterior Motive Lounge Episode 27: Meet the Crew
Requesting Gravatar...
I'll agree that the book doesn't work well for just a reference. In the introductions and whatnot (I believe specifically the README section) they make note that the book is meant for learning over reference. If you're already familiar with the subjects, I could understand how it's not the best way to just quickly look up the pattern for an abstract factory or singleton or whatnot.

For me, this is my first peek at design patterns, and I find some great things from this book. Firstly, the book doesn't really lose its scope. It's a book on design patterns and it doesn't dissappoint. Secondly, the downloadable code examples are full fledged (albeit in Java, I'm working on the VB.NET translation for myself and for anyone who might find it helpful)

Altogether, when the time comes around I'd recommend you give it a second peek. However, I won't kick you off the Christmas card list if you still don't get into it. Understandably, people have different lifestyles and learning styles.
Left by Stacy Vicknair on Jan 05, 2009 11:11 AM

# re: Ulterior Motive Lounge Episode 27: Meet the Crew
Requesting Gravatar...
It's definitely -- even intentionally -- a book to take time and think about. They're trying to engage the brain. That takes time. At the time, I was traveling a lot AND trying to finish my Requirements Patterns and Antipatterns book. Maybe now that I've FINALLY put RPandAP to bed, I can revisit in the right frame of mind.
Left by Martin L. Shoemaker on Jan 05, 2009 12:32 PM

Your comment:
 (will show your gravatar)

Copyright © Martin L. Shoemaker | Powered by: