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 28

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

Park Gate Sign

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:

Transport Staff Actors

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%:

Logical Deployment Diagram (revised)

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:

Physical Deployment Diagram (revised)

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:

Driver Use Cases

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:

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:

Guest and Priority Guest Use Cases

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!

Posted on Tuesday, December 9, 2008 6:23 PM Ulterior Motive Lounge , UML | Back to top


Comments on this post: Ulterior Motive Lounge Episode 28: Meet Danny Diplodocus!

# re: Ulterior Motive Lounge Episode 28: Meet Danny Diplodocus!
Requesting Gravatar...
Ok, I have one issue here... And it's not really with you, UML Guy, it's with verbiage in general.

"Sortation" Why is this a word? Why is it a "Sortation Systiem" Sortation is a noun form of the verb 'to sort', I get that. But we have a perfectly good work in our language for that: Sorting. If somebody asked me what I would call a system that sorts our baggage to the correct location, I would say "sorting system," save a syllable and not sound like a pompous dork.

My own employer does a newspaper circulation system that uses this word constantly. But, why can't we just say 'sorting?' I've never gotten a satisfactory answer for this.

Sorry, about that. I guess I bring my own "baggage" to the project, too.
Left by Editor Bill on Dec 10, 2008 8:48 AM

Your comment:
 (will show your gravatar)


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