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.

In our last Episode, The UML Guy showed how to organize Activities into larger Activities. Meanwhile, Old Guy absconded with The Reader's UML book and the time-traveling Gremlin...

(Click pictures for larger images.)

Episode 15a

 Episode 15b

And following up on Mitch's suggestion, here's a joke-free version of that diagram:

Episode 15c

And so we see the second film, or at least the finale of it. This was a great opportunity to show parallel behavior with Forks and Joins, illustrating three different timelines. (Actually, experts say there were eight, yes, eight separate timelines in the series. Scary obsessions some people have [says the guy who draws comic strips about software modeling].)

Editor Bill asked, "Question: Is there a notation to denote time/synchronization between events on parallel paths?" That was a truly profound question for someone who's not a programmer, because it's exactly the hard problem programmers face in parallel/multi-threaded programming. Parallel apps screw up or crash when one Thread changes data while another is using it. Parallel apps hang when Thread A waits for Thread B to do work, and Thread B can't do its work without action from Thread A. These are classic, well-studied problems in programming. We know the techniques for avoiding them. (I hope we know!) But the trick is in knowing when and where to apply them. When you're deep in the code, you can easily forget that you need them; but out here at the modeling level, we can more easily see where they're needed.

Many of these techniques involve putting synchronization and locking mechanisms into the system. It's naive (but common) to put synchs and locks in the code wherever you need the data. It's naive, because it's easy to forget, and also because you then have to change the synchs and locks in many places if your rules change. It's much smarter to put the synchs and locks in the data Objects themselves. That way, when any Thread asks for the data or changes the data, the Object enforces the rules uniformly.

And so this is one common use for data Objects in Activity Diagrams: to indicate synchronized data that's shared among Threads. I'm very impressed with Editor Bill for catching this. I was going to explain this in panel 7; but that would've been a full-page panel, and wouldn't have been very funny.

These diagrams also indicate a subtle new bit of notation. Notice how when Traveler appears, he's labeled "I : Traveler" and "II : Traveler". In the Episodes so far, I've simplified things by blurring the line between Class and Object. A Class is a category of things, and an Object is one thing from a category. As long as there's only one Object of a given Class in the discussion, that distinction isn't very important (for analysis, and often for design -- at code time, the distinction is so large that you can't possibly confuse them).

But in this diagram, there are two Travelers: I from Back... to the 80s!, and II from Back... to the 80s! Part II. So I needed to distinguish between two different Objects. (To anticipate upcoming questions: an Actor is really just a form of a Class. As we discussed in Episode 3, an Actor is a role someone or something can fill. So an Object [sometimes called an "Instance"] of an Actor is someone or something filling that role. In this case, we have two Instances of Traveler. (All you folks who want to argue that it's the same person in both cases, go argue with the multiverse/parallel timeline folks in the corner. We're talking UML here, not philosophy of time travel.) We need to distinguish between the two Instances. In UML, we can give both a name and a Class to an Object. We indicate that with the name and the class, separated by a colon. For brevity, I've called these instances I and II. So the full identities are I : Traveler and II : Traveler.

So once again, the Spacetime Continuum is saved! Hooray! But next, I'm afraid we have to get responsible. Ugh!

Posted on Saturday, November 15, 2008 5:01 PM Ulterior Motive Lounge | Back to top

Comments on this post: Ulterior Motive Lounge Episode 15: Back... to the 80s! Part II

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Martin L. Shoemaker | Powered by: