UML

All right, Mr. DeMille, I'm ready for my close-up

Martin L. Shoemaker — Tue, 26 May 2009 23:58:43 GMT

Back in January, Brian H. Prince from Microsoft interviewed me about the UML features in Visual Studio Team System 2010. Today, he informed me that the interview is finally live on Channel 9.

UML... It's not Rocket Science

Martin L. Shoemaker — Fri, 10 Apr 2009 20:08:36 GMT

If you follow me on Twitter, you may have seen a strange tweet yesterday:

Looking for a word... "Employee" is to "Roster" as "Vehicle" is to _____? "Fleet" doesn't seem quite right.

With a lot of helpful suggestions, especially from @patrickgreene, we settled on “Fleet Manifest”. It’s ideal for what I needed.

But in case you’re wondering why I needed that term, here’s a slide from the UML QuickStart class from 213 Software Studios (click pictures for larger images):

And here’s another:

"Think one through..." is what we'll do after these slides. I'll show you diagrams of the concepts first, so you know what we're trying to accomplish; and then together, we'll think through a live example. And then you and your team will do your own examples, and I'll help you get it right.

These are just a tiny sample of what you’ll get in a full day of intensive hands-on UML training. Email John T. Hopkins at jhopkins@213softwarestudios.com or call (248) 425-8549 for more information.

Ulterior Motive Lounge Episode 31: The Teams Split Up

Martin L. Shoemaker — Sat, 31 Jan 2009 06:59:22 GMT

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

After a long hiatus due to weather, illness, work, conferences, and more stuff than I can explain, the Lounge is back.

This Episode gets the ball rolling for Act II, so there’s not much new UML content here yet. But I can give you a few diagrams of the team’s review process. The process starts with some preliminaries, then splits into three threads of operations, each with a separate team:

Design Review. This team, led by The UML Guy, will create a Design Assessment, summarizing the state of the design and any clear risks and concerns. The details of the Design Review look like this:

Review the original design spec to determine the intent of the original team.
Review design documents and updates since the original spec.
Reverse engineer a design from the code. A good UML tool like Enterprise Architect makes this a lot easier, but not easy. VSTS 2010 will make it even easier, but still not easy. Incorporate this into a design summary.
Review the design with the dev team and revise until it’s ready for presentation.
Review the design with the full review team and revise until it’s ready for assessment.
Create the design assessment.

Functional Review. This team, led by Geek Girl, will create a Functional Assessment: a description of how well the system performs existing functions, with emphasis on usability and correctness. The details of the Functional Review process look like this:

Review the existing requirements docs.
Review outstanding defect reports, and make those the beginning of a functional assessment.
For each function identified in the requirements, identify actors and user who represent those actors. Interview those users to determine how well the system really works, and update the functional assessment.

Requirements Review. This team, led by The Reader, will create a Requirements Assessment: a description of what requirements the system covers; and more important, what it doesn’t cover. The details of the Requirements Review process look like this:

Review the existing requirements docs.
Assess the quality of the existing requirements. Are they quantified? Are they testable? Are they unambiguously stated in words, diagrams, and tests? Are they assigned business values and priorities? Do they have clearly identified actors and use cases and scenarios and goals for each feature? These and many more questions will help to create the requirements assessment.
For each actor represented in the requirements or discovered during interviews, identify and interview representative users. Determine whether they have missing requirements, as well as whether they know of or require previously unidentified actors.

For a really thorough review, you probably need at least three more threads of activity:

Code Review to inspect the code, either completely or through sampling, to identify how well it’s constructed and maintained.
Quality Review to identify Quality Assurance measures, Testing measures, and the status of each.
Process Review to analyze the processes followed by the dev team and related teams.

But for simplicity (and to keep most of my focus on my primary message), I’m going to restrict this case study to Design, Functionality, and Requirements. Code will be reviewed under Design, and Quality will be reviewed under Functionality. Process will be reviewed everywhere.

Is this a lot of work? Yep. But it’s a minimal necessary set of activities to review a project for status and risks after you’ve ignored them for a long time. It would be so much easier if you could do these sorts of assessments in real time right from the start as the project proceeds. It would be so much easier if you could report the status and health of the project at the push of a button, based upon the actual work the team does as they do it. Gee, wouldn’t Owner’s life be a lot easier if there were tools to do all that?

Oh, wait a minute… There are tools like that! In fact, there’s a whole category of such tools: Application Lifecycle Management (ALM). And my current favorite is the aforementioned Visual Studio Team System, perhaps the most poorly named product Microsoft produces today. Why poorly named? Because Visual Studio is a developer tool set, particularly a tool set for .NET developers; so when people hear a name like “Visual Studio Team System”, they assume it’s a developer tool set, only bigger and better. They assume it’s about .NET development.

VSTS is not about .NET development. Oh, VSTS includes Visual Studio, and then adds some powerful developer and architect and DBA and tester features; but those features, as powerful as they are, are just the icing on the cake.

The cake is ALM. VSTS is about your process and how you can define it and design it and manage it and track it, all through tools your team – your whole team, not just .NET developers – are already using. Your Project Managers can create task lists and project plans in Excel or Project. Your developers can work on those plans in Visual Studio – or not! If they’re working with Eclipse or other non-.NET tools, developers can use TeamPlain to access their work items. Testers can create and apply test plans. Executives can view summaries and reports and Key Productivity Indicators (KPIs) through a project Web portal.

And all of these tools are updated automatically as the team works, in real time, through the Team Foundation Server: a powerful set of databases, reports, services, and tools that integrate with Excel and Project and Visual Studio and Sharepoint and other tools to provide a seamless process involving all participants.

I didn’t intend this post to turn into an ad for VSTS, so I’ll leave you to explore further if you like. But I can tell you this: even if Owner had known about VSTS, even if he could’ve convinced Cowboy Consultant to look at it, they would’ve turned it down. Owner already balked at spending proper time and money on requirements and design. Cowboy Consultant already demonstrated that he has no patience for anything beyond the code itself. Well, as powerful as VSTS is, it’s not cheap (though I think it’s well cost justified), and it takes time and effort and training to use it properly. They both would’ve written it off as needless overhead, judging by the attitudes we’ve seen so far.

And those attitudes are going to lead to some mighty big problems pretty soon. Dinosaur sized, even.

One final note on today’s Episode. You may wonder why Dog is going out into the Park with The Reader and Stick Boy. Well, she’s a dog. She smells things, really interesting things. She wants to investigate, not hang around in some sterile, air conditioned computing center. Dogs gotta be walked, ya know?

Ulterior Motive Lounge Episode 29: Touring the Pavilion

Martin L. Shoemaker — Tue, 16 Dec 2008 02:03:15 GMT

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

“We grow dinosaurs!” Big whoop, huh? Like anyone reading the strip hadn’t figured that out before I started Scene 1… It’s hard to surprise the characters in a story when the audience can tell from the promos what the surprise is.

But since The UML Guy has been part of the project before, none of this was a surprise to him. So while the others were taking in the new sights, he was drawing more UML diagrams. His results follow.

We learned a few more specific kinds of scientists on the project:

We added one more category of Employee Actors, Information Staff:

If you’ve ever eaten at a restaurant – certainly if you’ve ever worked at one – you’ll realize we need more detail in our set of Concession Actors, starting with a Restaurant Manager:

And then more specific Restaurant Staff:

We also learned of more systems we’ll need to support the functions described in the Episode:

We added an Information Console, a Laboratory Server, Laboratory Computers, Laboratory Devices, a Commerce Server, and Cash Registers. Note that the Commerce Server has to communicate with the Warehouse Server to schedule deliveries to the rooms and to the mainland.

These new systems complicated the physical Deployment Diagram almost to the breaking point. It’s complex enough that The UML Guy plans to group it, simplify it, and turn it into multiple diagrams when he gets time. But for now, here’s one more look at the single diagram:

We added some new Use Cases for Driver:

And for Guest:

One of those Use Cases, Make Purchase, is complex enough to deserve a dedicated diagram:

We can see from the Episode that there are multiple Classes of souvenirs:

And finally, we have new Use Cases for the Geneticist and the Embryologist. Normally, The UML Guy prefers a single diagram per Actor, focused on the Use Cases for that Actor; but in this case, the Use Cases are closely related and work with related Domain Objects. So he combined the diagrams for now, but may split them later:

That’s it for new UML content for this Episode. Oh, The UML Guy could imagine more, such as Use Cases for the Restaurant Staff and the Souvenir Staff; but Owner just didn’t give enough detail to work with. Those will come out over time.

Other comments on this Episode:

The sign post in panel 2 probably ought to include Seoul, Ottumwa, Mill Valley, Boston, and Crabapple Cove; but that would’ve made it unreadable.
It’s not the Dino Dog that’s bothering The Reader in panel 6, it’s the curry. The fastest way to drive him away is to serve him curry. But boy, curried chicken sausage sounds good to me right now!
Since you insisted (I know you’re thinking it, here’s the recipe for Yabanapple Soup:

Yabanapple Soup (Serves 4)

3 large ripe bananas

1 large sweet potato (sometimes called a yam in America, but not the same as yams elsewhere – it’s a whole different genus and species)

1 large can of chunk pineapple, drained

2 large cans of whole coconut milk (skim if you prefer)

3 tablespoons of honey

1 dash cinnamon

1 dash nutmeg

Clean and peel the sweet potato.
Boil a pan of water. When boiling, add the sweet potato, and boil until slightly soft. Remove from heat and drain.
Peel and slice the banana into quarter-inch slices.
Slice the sweet potato into quarter-inch slices, and then into chunks.
In a sauce pan, mix coconut milk, sweet potato chunks, banana slices, pineapple chunks, honey, cinnamon and nutmeg. Heat until simmering.
Serve hot; or chill and serve with a scoop of ice cream.

Boy, those are some cool-looking souvenirs in panel 7. Let’s take a closer look:

Wow! Too bad this is just a comic strip, not the real world. Wouldn’t it be great if there were a place where you could buy LoungeWare, especially just in time for Christmas?

Wayne H. Boring was a famous and popular Superman artist. I love his work, and I couldn’t resist borrowing his name for the pun in panel 8.

Next Episode: a tour of the Labs!

Ship It On The Side Episode 3

Martin L. Shoemaker — Thu, 11 Dec 2008 07:45:15 GMT

Ship It On The Side Episode 3 -- Use Cases is now released. Complete with goats!

The UML Learning Path

Martin L. Shoemaker — Thu, 11 Dec 2008 02:41:34 GMT

(Click picture for a larger image.)

No, I'm not going to name any of the devs who inspired this post. They wouldn't know who I am, anyway.

But it takes an extremely high degree of arrogance to go from "I don't see a way to use this" to "This has no value, no matter who says they're getting value out of it. So I'll dismiss it, and I'll mock them" Either arrogance, or more likely, insecurity: "I don't understand this; so since those people think it's important, either they understand something I don't, or they're fools. I'll mock them, so everyone thinks they're fools. That will make me look smart."

And that insecurity manifests in a lot of places on a lot of topics, not just UML: Agile Development, Orchestrated Development, CMMI, Test Driven Development, C#, Java, Ruby, linux, .NET... Any time you move from "I don't see it" to "It's worthless", look around: if other developers are putting those tools to productive use, then it's not worthless. It just doesn't help you. So do you call it worthless, and imply they're fools? Or do you openly mock them, demonstrating that you're a fool?

Or do you follow the only exit path in this diagram? There is only one, after all. Once you get UML, you've gotten it for good. You may not use it all the time, but you'll understand when and why you should use it. But the only exit path is the middle: you recognize that UML (or Agile, or Orchestrated, or...) is having some value on some projects, so it's not worthless; but you just can't see the value. You remain open-minded.

Ulterior Motive Lounge Episode 28: Meet Danny Diplodocus!

Martin L. Shoemaker — Wed, 10 Dec 2008 00:23:32 GMT

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

And just in case you can't read that sign above the gate, here's a larger view:

So Editor Bill looked at this strip and said, "Geez, Martin, what happened? You spent so much time drawing that volcano cone, you didn't have time for any UML?"*

"What?" I said, "You don't see the UML content in this Episode?"

"Well, yeah, there are a couple new systems mentioned, I guess."

"Ah," I said, "that's because you're not listening (or reading) with the ears (or eyes) of an analyst. This Episode is chock full of UML content. The UML Guy's listening carefully and updating his diagrams and drawing new diagrams. You just can't see that in the tiny little panels. But I'll be sure the readers can see them in the commentary." Score 1 for The UML Guy!

To start with, The UML Guy remembered the right name for one Actor. He kept blipping out on the name of the workers who load and unload the baggage; so he simply called them "Shipping Staff". Then he remembered the right name: Stevedore. So he updated the model for that, and also to show a previously forgotten Actor, Driver:

Editor Bill responded, "Drivers? I don't see any drivers. The team are just driving themselves."

"Ah," I reminded him, "don't forget: Actors in UML aren't people or job descriptions: they're roles people or systems play. In this Episode, Owner, The Reader, and Geek Girl are fulfilling the Driver role." Score 2 for The UML Guy! It's almost like I'm setting up these points on purpose...

Editor Bill mentioned a couple new systems. Oh, it's a lot more than a couple. Implicit and explicit in Owner's narration are 17 new systems. Score 3 for The UML Guy! That means our original Logical Deployment Diagram has grown by 242%:

Now some of those systems are implicit only because The UML Guy has worked on baggage handling systems and reservation systems. So these aren't requirements or existing infrastructure yet. They're only assumed.

That's OK. You're allowed to bring your experience and history to your projects. You're expected to bring them. Just be sure you don't mistake past experience for present knowledge. The UML Guy will have to present these ideas to Owner and Owner's staff and ask the analyst's most important question: "Is this right?"

And that's a hard question to get answered. It's easy for stakeholders to get confused in jargon and answer "Yes" out of reflex, not out of understanding. It's really easy for an analyst with a strong personality to unintentionally pressure the stakeholders into "Yes." I spend a lot of time saying, "Don't let me convince you that I'm right. If I'm wrong, please tell me. I don't think I'm wrong; but I need you to tell me if I am, because you're the only ones who can."

Now in this particular case, we're going to find that The UML Guy is brilliant, and these changes are all perfect. Scriptwriters have awesome powers, after all. (But I'd love to hear from you if you disagree with anything here.)

So the new systems are these:

Car Information System. This new system is obvious from the Episode.
Guest Information Server. If the Car Information Server is going to present guest-specific info feeds, somewhere there will have to be stored information on each Guest. Since the Central Server is concerned with operation of the Park systems, The UML Guy assumes there will be a separate system for Guest information. He's willing to be told that he's wrong, of course, but that's how he's drawing the diagrams right now.
Reservation Server. Since Owner discussed Priority Guests vs. Guests, we know there has to be a way for Guests to express their preferences as they make reservations. (See the Guest Use Cases below for more details.) That little bit of knowledge implies a reservation system of some kind. The Park will contract with a travel company to book reservations; and their Reservation Server will have to connect with the Guest Information Server to know what rooms are available when, and to inform the Park about reservations.
Guest's Personal PC. Guests will be able to make their reservations online, so their PCs are connected to the rest of the network by connecting to the Reservation Server. It's unlikely that we'll be deploying any code there; but again, we're defining a broad scope now, and narrowing in later.
Weather Station. Since the Island is an independent territory, there's no National Weather Service providing forecasts there. In order to provide up-to-date weather information, they'll need some sort of weather reporting station. Something like this...
Hospitality Console. The Lodge staff will need consoles to enter and maintain Guest information.
Event Planner Console. Event planners will need consoles to plan and manage events.
Room Lock. From Owner's description, the Lodge room locks must tie into the GPS system, since the GPS Locators act as keys; and the Guest Information Server must be able to assign GPS's to locks.
Sorter. The baggage sorter on the Island will be a huge system. (Trust me!) It needs a server dedicated just to sortation logic and planning.
Sorter Controller Module. While the Sorter plans and routes bags (and packages -- Park staff will use the same system for routing packages to installations throughout the Island), the actual sortation hardware needs a separate server to control all the inducts and diverts and carriers and rollers and conveyors and scanners and lifters and loaders and pushers and more and more and more... There's a lot there (Trust me!), so we'll need separate servers for routing logic and for device control and communications.
Bar Code Scanner. Each package will be tagged with a bar code label, and the scanners will use these to locate each package and report the locations to the Sorter Controller Module.
Sorter Car. Each car (or carrier) in the sortation system will have its own control device to help it induct, center, and divert loads.
Baggage Check In Console. When the Guests arrive at the docks on the mainland (or at the heliport for Priority Guests), the Stevedores there will have to check in their baggage at this console.
Baggage Scale. Weighs Guest luggage.
Bar Code Printer. Prints the bar code labels for the baggage.
Shoreside Baggage Server. Manages baggage information at the dock or the heliport.
Dockside Bar Code Scanner. Used to confirm that each bag reachs the dock and is loaded onto the ship.

And if the Logical Deployment Diagram has gotten complicated, the Physical Deployment Diagram has gotten worse -- so complex, The UML Guy had to reorganize it and regroup the nodes by their locations in (and out of ) the Park:

These locations are:

Underground Sortation System. Where all the sortation hardware is found.
Server Room. Where the primary servers are found. (Yes, I can explain why Room Lock is inside that boundary. It's a highly technical concept we call a mistake. The UML Guy goofed. He'll clean it up later.)
Lodge Offices. Where Lodge hardware is found (and probably where Room Lock should be found). It contains two specific locations:
- Concierge Office. Where the Hospitality team works.
- Event Planning Office. Where the Events team works.
Reservation Agent. The offices of the third-party reservation service.
Ops Center. Where the lead Ops staff works.
Comm Center. A separate building where communications hardware is found, including an array of communications towers and antennas mounted on the roof.
Check In. The baggage check-in centers on the mainland.
Field Units. Mobile devices throughout the Island.

And as The UML Guy added hardware and envisioned hardware in different locations, he realized the Park would need more Routers, along with a satellite Internet link; so he added those to this diagram.

The UML Guy also identified initial Use Cases for some Actors, including Driver:

This Use Case relates to two Domain Objects: the GPS Data, and the Guest Feed (which in turn involves a Weather report, Daily Events, and Guest Schedules). The UML Guy also added a note for a known defect. There may be better ways to note this, depending on your defect tracking tools; but this note is a very visible way to indicate it (expecially to my audience, i.e., you).

We also have Stevedore Use Cases:

The UML Guy didn't mark either of these with a defect note: even though he knows the sorter's not working, he doesn't know enough yet to tie it to a particular Use Case.

And finally, with have Use Cases for Guests and Priority Guests:

I could go through the Episode panel by panel and justify every one of those Use Cases; but most of them should be obvious if you've done much traveling. If you have any questions on them, please feel free to ask. The UML Guy probably has some idea of Event Planner and Concierge Use Cases from this Episode as well; but the information is so vague, he left those Actors for later. (Either that, or he was awed by the scenery.)

No UML content, Editor Bill? Ha! It is to laugh! UML content coming out your ears, my friend...

Some other notes on this Episode:

Yes, all cars on the Island are AMC Gremlin X's. Long-time readers will notice a pattern here.
Before I drew panel 4, I had no idea there would be Car Information Systems. Before I drew panel 5, I had never heard of Danny Diplodocus. Now this little bit of imaginary code is whispering in my ear and suggesting that he needs a larger role in the story. He's a blooming drawing of an imaginary blooming computer-animated dinosaur, and he's trying to wrest control of the story from me! I tell ya, authors have no control over their creations, none at all.
No offense is intended toward Italian software developers in their role in the defective sortation system. I'm not blaming them; but it's common for the absent team members to become the scapegoats for all failures, especially when they're from a different company and there's a bit of a language barrier. Do they share the blame in this case? Probably. Do they deserve the whole blame? I seriously doubt it. But since they're not there to defend themselves, they're going to get more than their share, I'll bet.

Next Episode: a tour of the Pavilion!

OK, OK, Editor Bill didn't say that. As author, I get to put words in the mouths of my characters and Editor Bill. He did say, "Well, no, there's not a lot of UML content; but you can be excused, because you've got a lot coming up." Then I told him about the UML content. But if I tell the story this way, I get to brag about how hard I worked on that volcano cone!

Ulterior Motive Lounge Episode 27: Meet the Crew

Martin L. Shoemaker — Fri, 05 Dec 2008 23:34:39 GMT

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

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:

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:

The Supervisor Actors are more numerous:

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

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

Here are the Ops Staff Actors:

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

And here are the Facilities Staff Actors:

Here are the Laboratory Staff Actors:

Here are the Lodge Staff Actors

Here are Concession Staff Actors:

Here are the Marketing Staff Actors:

And finally, here are the 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:

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.

Business Actors

Martin L. Shoemaker — Fri, 05 Dec 2008 19:58:41 GMT

On Twitter, @ClearSpringBA asked:

@UMLguy to show a "parent" actor over subsidiaries, do I use the generalization feature in UML? (doing an actor-UC diagram, new to it)

Wordy cuss that I am, I answered multiple times:

@ClearSpringBA Are subsidiaries subordinates or special cases? For ex, Supervisor is special case of Employee; Emps are subordinates of Supv

@ClearSpringBA For special case, genralization arrow from Supv to Emp. "Supv is an Emp with more responsibilities."

Her questions back:

@UMLGuy thanks for all the info. subsidiaries are parent companies, can do everything on behalf of a sub.

UMLGuy so, i would draw the arrow toward the parent company? the arrow with the "big head", generalization arrow? prob wrong terms!

I decided this had gotten complex enough that words weren't working; so we went to email. Since this is general enough not to show any business info from her client, I thought I would share my response, in case anyone else finds it useful:

Here’s a simple diagram of business relationships:

You can read it as follows:

A Business is an Organization. Triangle arrow (“generalization” or “inheritance”) can be interpreted as “is a”.

A Parent Company is a Business.

A Parent Company has zero or more Subsidiaries, which are Businesses. (They might also be Parent Companies themselves, since a Parent Company is a Business.) The plain arrow can be interpreted as “has” or “contains” or “uses”. 0..* means any number, possibly 0. 1..* would mean any number, NOT 0. That could mean, for example, that a Parent Company MUST have at least 1 Subsidiary.

A Business has 0 or 1 Parent, which is a Parent Company. The “topmost” Business has no Parent. All the others have 1.

A Business has zero or more Partner Businesses.

I hope that clarifies things, and gets you thinking about new ideas. Please let me know if you have more questions.

And I hope it helps someone else, too!

Ulterior Motive Lounge Episode 26: Aboard the Helicopters

Martin L. Shoemaker — Tue, 02 Dec 2008 14:59:21 GMT

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

This is the first we've seen of Deployment Diagrams in the Lounge; but they're enough like Class Diagrams that I think you should find them easy to read. Here's the diagram above, larger and more readable:

The cubes represent nodes within the system. By default, they represent Processors: computers where you'll deploy code. The <<device>> stereotype here indicates devices that your system talks to, but you don't actually deploy any code there. The lines connecting the nodes represent paths of communication. Recall from our Class Diagrams that we use arrows to indicate which end of a relationship is a "controller or "owner" in the relationship; but if the ends are "peers" -- or if we just haven't decided the details yet -- we use simple lines, not arrows. Lines are more common in Deployment Diagrams.

As in Class Diagrams, the triangle-headed arrow indicates generalization or inheritance. In this example, a Windows Mobile Phone is a more-specific example of a cell phone, one where we can deploy Windows Mobile apps.

Processors and devices are physical things. Stakeholders who haven't a clue what Classes they need will commonly have strong opinions of what nodes they need. "We're going to have PCs at all these stations, and a server back here, and two printers over here, and a connection to the Internet here, and..." So a Deployment Diagram is often part of their requirements, not just their design. (Of course, the design may result in deployment changes...) Drawing the Deployment Diagram is a good starting point for discussing the system.

To make these diagrams even more readable to the stakeholders, it's common to add specific icons for specific kinds of nodes:

What we've seen so far are logical Deployment Diagrams: these are the nodes that must communicate to carry out requirements, but not the full picture. A physical Deployment Diagram adds the hardware that connects these nodes, and also describes the connections:

Some stakeholders -- particularly IT staff and network admins -- will prefer the physical Deployment Diagrams; but most will prefer to know where work is done, without reference to how the nodes connect.

Note also some added detail here: besides Windows Mobile Phones, we have two other kinds of cellular devices. The Tablet PCs are equipped with Cellular Modems; and the GPS Locators use cell signals to broadcast their locations. Hmmm... That means the cellular network is very close to being a single point of failure. if that went down, it would be bad...

Other notes from today's Episode:

Dog refused to be left home. She's pretty stubborn sometimes.
WiMAX is becoming a very popular solution for wide-range wireless networking. But darn it, they still don't have a tower that can reach my house!
Stick Boy is a gamer geek. He never goes anywhere without his wizard staff.
Hacker Girl's shirt reads, "What-EVER!" in pink on blackl.

And finally: yes, despite his admonitions, The UML Guy just overlooked some vital information. He's not kidding: we all have blind spots, and we need each other to review and catch what we miss. Even knowing that, he didn't listen to Dog. She's always barking about something, so this can't be important, right?

Everyone on the team and every stakeholder has a unique perspective. Think of your problem as a giant abstract sculpture in a dark room; and you're supposed to recreate that sculpture. Everyone has a flashlight. Some are broad beams, and some are narrow, but none is large enough to encompass the entire sculpture. Oh, sure, if you stand back at a distance, you can play your beam over the wole thing; but then you're too far away to see details. So you need everyone, every light, to see angles and perspectives that you overlook. Even with all the beams, you'll miss some details; so go out of your way to get as many beams as possible, and have everyone look from multiple angles.

Of course, most of us would probably overlook Dog as a stakeholder, so I'll cut The UML Guy a little slack. But if only he had listened...