“Hey, why don’t we go to The Smiling Chef after work?”

As much as I love the get-togethers with my girlfriends, they aren’t without obstacles. Like trying to dodge The Smiling Chef or any other restaurant where you are charged an arm and a leg for a nicely roasted thigh. Squab’s thigh. Nicely roasted, though, which my friends love and can afford.

I have to act quickly, so I wedge the phone between cheek and shoulder and start browsing the Internet. Thank goodness for restaurant search websites that let you specify budget:

“Sure, Louisa. How about click-click-click, Alluro, though? It’s in the same area, has excellent reviews and we haven’t been there before…” And the chef smiles at you for about half the price of The Smiling Chef, but I decide not to mention that.

After a short negotiation we agree that I’d book a table at Alluro and will e-mail the others. Phew!

Thanks to the magic of said website five minutes later I have made a booking and receive a confirmation e-mail, which I forward to my friends and get back to work.

In case Fossey is reading this: it did take five minutes, I swear.

Half an hour later however my phone rings again. This time a nice lady from the booking website is apologising that although I have received a confirmation e-mail, they have to call the restaurant first to check the availability and will be in touch with me shortly.

“Oh, OK. How long shall I wait before I try to book somewhere else?” I ask, while quickly e-mailing my friends with a “Hold on, booking not quite confirmed yet!”

I hear the polite intro again that although I have received a confirmation e-mail…, and apologies for any inconvenience this may have caused… and in touch with me shortly. It doesn’t answer my question, but puts my worries at ease: hearing the same thing recited again makes me think that that’s a standard procedure and not a major luck failure with my booking.

Sure enough two hours later I have another confirmation, which I forward to my friends once more.

This was a few weeks ago, when I was pondering UML Use Case Diagrams, prompted by our reader Amir. The mixed feelings that my online booking brought on, ‘Wasn’t it wonderful to dodge The Smiling Chef with a few clicks!’ to ‘Who on Earth designed this system?!’ reminded me of Alistair Cockburn‘s Altitude Metaphor for the level of detail in Use Case Diagrams, which is what this post is about.

Cloud Level

At Cloud Level a use case represents ways of getting to goals, that are highly summarised, such as as ‘make money’. These use cases don’t neccessarily have do with implementation (or software development) and are usually the topic of discussion at management meetings.

Thinking of restaurant booking websites, they have figured out their Cloud Level use cases a while ago:  restaurants provide details, such as address, business hours and menus; the booking website offers a single go-to point for clients, handles bookings and customer reviews:

Kite Level

Then we have Kite Level, which is still mostly concerned with summary goals, but slightly more detailed:

Sea Level

At Sea Level one deals with users and how their goals are achieved.

This is where my booking experience intrigued me enough to sketch it on a diagram.

You have probably noticed that there aren’t any extensions here. This is cleverly covered by the Apologise scenario, which happens in any case and covers situations from the restaurant being already fully booked to local clown parade blocking access to it.

I doubt that these happen often enough to justify the resource expenditure, though.

If I were in charge of the restaurant booking system (no, Fossey, I’m not considering defecting to the restaurant business), I’d leave the Apologise scenario as an extension – a plan B, really. I would also change the initial automated mail to say pretty much what the person on the phone was telling me: acknowledge that the booking is in progress and that a confirmation will follow within a couple of hours. I bet no one would complain about that.

See, Ma, no call-centre!

And this is why I have decided not to put the address of that website I booked through. I fear violent outbursts from call-centre employees.

Who are very polite, by the way.

Fish Level

If you hold your nose (you’ll see why, I promise) and follow me, we can go below sea level and into a programmer’s pit (I warned you!) and take a peak at the level, which is concerned with the implementation of the system, underlying the diagram above.

Now, because you are sharp, I am sure you have noticed yet another improvement. Because I know that if my colleague Manuel were in charge of designing the system, he’d consider it beneath himself not to try and make it as responsive as possible, I added the ‘connect to the restaurant’s database’ scenario.

Why not try and make the booking immediately, if possible? Happy users are loyal users.

If you haven’t met Manuel, well… good for you. If you insist, however, have a look at his post on UML 2.0 Sequence Diagrams for a gentle introduction.

Clam Level

As I considerately delegated the design and implementation to Manuel, I am leaving this one to him. At Clam Level we get into the nitty-gritty details, such as ‘Enter restaurant name > Click search button’. I’m sure Manuel will have fun.

Plus, even with being a visual girl and all that, I feel I am headed for a massive sense of diagram failure here. The more I look at the scenario bubbles, the more I empathise with Martin Fowler on the topic: forget the bubbles, use text.

Seriously, does anyone use Use Case Diagrams at all?

I expect e-mails, people! Drop us a line at office@diadraw.com

Resources

The cool cartoons are courtesy of zlotence.

About the Author