Geeks With Blogs

@UMLGuy
  • UMLGuy @LeeHate are you still selling art? I would like to license Vodun Bokor for book/ebook cover. It's incredible! You're very talented. about 735 days ago
  • UMLGuy @kzoomoo Indeed. You know 2 of my influences. Characters have multiple influences, but Father and Daughter partly inspired by your family. about 1122 days ago
  • UMLGuy @SteveAndrews That is awesome news, man! You worked hard for that. about 1122 days ago
  • UMLGuy The Night We Flushed the Old Town in Digital SF V2. Kindle: http://t.co/8cVA6zw It's about ecological disaster. And beer. about 1138 days ago
  • UMLGuy @kzoomoo Sounds like a very happy birthday! Your kids are great, as always. about 1272 days ago
  • UMLGuy @julielerman You're in Bangalore and Bali... and you need cheap tickets to feel lucky? I would call that great fortune in itself. about 1272 days ago
  • UMLGuy So weird watching Dr. Gregory House M.D. play Bertie Wooster. Same facial expressions convey completely different meanings. about 1273 days ago

News LoungeWare is now available. The UML Guy T-Shirt
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.

So our last episode has generated some back-and-forth between the guest stars in the comments. Due to anomalies in the Spacetime Continuum, these comments appear in reverse order. I'd like to correct that order, and then respond.

First, most-frequent-commenter Mitch (a.k.a. @anklebuster, a.k.a. Dad Geek) wrote:

That was a great comic strip! Thanks for letting me have a part.

At first, I wasn't getting the data flows. Then I thought about Office Race and the "trap" where there is a 66% chance of going back to the top pushpin. Is this the same as "still disrupted"? (Actually, disrupting the Space-Time Continuum seems to have far dire consequences, as I don't see any way OUT of that box?! But if that's just data, does it have any effect on the flow?)

I'm confused about which parts represent the backup plan - is that what to do if the traveler meets his parents by accident?

I have a dozen questions, but it's possible that you can answer the unspoken ones if I can get my head around the answers to the ones above.

It's funny, at first, it was all about just enjoying a humorous comic strip. Now it's about making sens of something that may have practical use for my own projects.

Cheers,
Mitch

First-commenter Corey (a.k.a. @coreyhaines, a.k.a. Traveler) responded:

Sweet! Thanks for including me.

As for the commenter above, the dashed lines represent data flow, but control flow stays where it is. So, when you disrupt the ST Continuum, you do that, but the control flow stays in place.

It is explained in the last paragraph of the post.

Then Corey realized that the Spacetime Continuum was well and truly disrupted: he commented after Mitch, but his comment appeared first!

Oh, in my comment, I mean Mitch (who commented before me), and the comment shows up as the one after me in most-recent-first order. :) Doh!

I tried to step in and bring some calm to the crisis:

Clearly all comment order confusion is due to a Disrupted Spacetime Continuum.

But Mitch was not so easily assuaged:

Thanks Corey. Now explain String Theory.

:)

My problem with understanding this diagram is that I have no idea what the actors do in relation to the data. Is it an independent relationship or is one dependent on the other? Am I even making sense?

Cheers,

Mitch

So I decided there was enough confusion here -- much of it caused by me! -- to deserve a full post in response. (That, and this was too long for Live's comment box.)

Mitch,

Sorry, been working all day. No time for the detailed answers your questions deserve.

And sorry again for colliding goals. My goals with the Lounge are: 1) to teach; and 2) to entertain, so you'll want to stick around for goal 1.

But in this case, I fear goal 2 may have gotten in the way of goal 1. The answer to "what the Actors do" in this diagram is only one thing: entertain by telling bad jokes. (Not the fault of you guest stars, of course, since I wrote the script.) Actors aren't normally part of an Activity Diagram. (I can make a case for including them in some cases, but let's not complicate things yet further today.)

When I finished the diagram today, it seemed awfully dry, with a lot of white space (err, umm, yellow space) just begging to be filled. And since I wanted to make more use of my guest stars, I decided to fill that space with them (you) acting out scenes from the film. (Right now, @jbkazoo is just grateful I can't draw a manure truck!)

But it appears I may have misled you in the process. The Actors on this diagram are merely decorations (and jokes, if I got lucky). They're not part of the diagram itself. I need to make a new version of the diagram without the Actors for tomorrow's episode (which may end up as Thursday's episode); so here it is as a preview (as always, click for a larger image):

Back to the 80s

As for your question: "...I have no idea what the actors do in relation to the data. Is it an independent relationship or is one dependent on the other? Am I even making sense?" You're not quite making sense, because the Actors really don't belong here (sorry); but you've used exactly the right UML terminology: dependence. In UML, the dashed arrow indicates dependence. It means, in the simplest sense, that a dependent thing (where the arrow starts) depends on an independent thing (where the arrow points). If you change the definition of the independent thing, the dependent thing might have to change in response.

While Process Cop is safely banished, I'm going to illustrate dependence in the way that makes most sense to programmers but is supposed to be verboten to UML instructors: actual code! (That should be a link to a famous Dilbert strip, but I'm too busy to find it right now. Trust me, it was funnier than the Lounge, and almost as poorly drawn.) I'm going to use C# for my example, because it's the language I use most often. You Rubyists can just skip all this, because no doubt your code was already written for you before you even sat down at the keyboard. Ruby is that good. (That was supposed to be a link to a House episode; but again, I'm too busy to find it right now.)

Suppose we have a Class A (and I'm coding on the fly in a blog form here, so please forgive the inevitable errors):

class A
{
    protected int _x;
    public int X
    {
        get { return _x; }
    }
}

Now suppose we have a Classes B, C, D, and E:

// B inherits from A.
class B : A
{
    public int Y
    {
        get { return _x * 2; }
    }
}

// C has an A
class C
{
    private A _a = new A();
    public int Z
    {
        get { return 3 * _a.X; }
    }
}

// D uses an A.
class D
{
    public int GetValue(A a)
    {
        return 4 * a.X;
    }
}

// E creates an A.
class E
{
    public A GetAnA()
    {
        return new A();
    }
}

Now B can be modeled as Generalization (a.k.a. inheritance), and C can be modeled as Association; but all of these Classes are at least dependent on A, because a change in A could break all of them. For example, this would be a breaking change:

class A
{
    protected string _x;
    public string X
    {
        get { return _x; }
    }
}

I changed ints to strings. A will still compile just fine; but B, C, D, and E are all now broken, and won't compile until I fix them. They depend on our definition of A.

Now that's a programmer's narrow view of dependence. In the more general sense, it means something depends on or knows about something else. You can qualify that dependence by adding details.

And dependence can serve different purposes in different diagram types. Activity Diagrams usually consist of Activities (the hot dog shapes), Branches (the diamonds), and Transitions (the arrows); but we sometimes add Objects (rectangles) that represent data or things involved in the diagram. I particularly like to show data that's involved in multiple Activities or Branches, especially if the Activities or Branches are scattered across the diagram. In today's episode, the actual damage to the Spacetime Continuum occurs at the very start of the diagram; but we don't detect the damage until the middle, and we don't fix it until nearly the end. (And you have no idea how much it amuses me that we're holding a serious UML discussion about damage to the Spacetime Continuum! What other UML training offers delves into such heavy issues, huh?) It's easy to forget about the damage when we get to the end; but by adding the Spacetime Continuum object, we have a reminder: this is important to this diagram! And the dependency arrows say: and this is where it's important!

But remember, if this were Office Race and you were moving your counter through the diagram, your counter could never follow a dashed arrow. Remember my rule: Flow follows Full arrows, Data follows Dashed arrows. If your counter were on Disrupt Spacetime Continuum, you could spraypaint graffiti on the Spacetime Continuum, but you couldn't move in there and take up residence. (OK, OK, technically you do reside in the Spacetime Continuum. Work with me, people! All models are wrong, but some are useful.) That was the part that had you confused, in that you wondered how to leave Spacetime Continuum once you got there. As you suspected, the answer is: you never go there. Data goes there, but you don't.

OK, let's talk about a more practical example. Suppose you have a Web page that lets users do some task; but certain steps in that task are only permitted to certain users. What you need, of course, is a log in mechanism; and when the user logs in, he or she is assigned a set of permissions based on their credentials. It would be useful to mark those steps that depend on the permissions. So in our Activity Diagram, I start with a Log In Activity; and that Activity creates a Permissions Object. Permissions is a rectangle in the diagram; and a dashed arrow labeled "Create" runs from Log In to Permissions:

Log In

Then for any other Activity in the diagram that requires specific permissions, I added a dashed arrow to Permissions; and label that arrow with the specific permission information required. If any Activity somehow changed the permissions, I would add another dashed arrow, and label it with a description of the change.

That's my traditional example of Objects and Dependence in Activity Diagrams: log in and permissions. But let's face it, isn't it more fun to look at dances and their impact on the Spacetime Continuum?

There's a common convention that I'm trying to give up. This convention is to draw changes to the Object as incoming arrows, and reading the data as outgoing arrows.

Bad habit

I find this is confusing for two reasons. First, it violates the idea of a dependence. In our Log In example, it would mean that Permissions depends on Approve Invoices and Issue Payments, when that's exactly backwards. Second, I think it encourages people to misread the dashed arrows as control flow, when they should be only used for data flow. In fact, I have seen students confused in exactly this way; and it was clear from your questions that it's easy for people to get confused this way. I try to make less confusion, not more So I prefer to draw all data flows as arrows into the Objects, each labeled as to whether it's reading or writing.

As for this question:

I'm confused about which parts represent the backup plan - is that what to do if the traveler meets his parents by accident?

Perhaps this was another place where I was confusing when I tried to be amusing and clever:

An Activity Diagram is a picture of your plan, and the Branches are a picture of your backup plan.

Perhaps that line wasn't as clever and clear as I thought it was (but I still like it!). I was trying, in as few words as possible, to convey the idea that an Activity Diagram shows expected and alternate scenarios for a plan or a process. There are two common ways to approach Activity Diagrams: the Big Picture Way, and the Little Picture Way. Programmers tend toward the Little Picture Way: draw a diagram step by painstaking step, stopping and exploring every decision as it comes up. and probably never finishing because it's all trees and no forest. The Big Picture way is the way I advocate, even if I don't always follow my own advice: start with a basic success path (the "Happy Path", it's sometimes called); and then at each step, ask, "What could go wrong?" and "What will we do if that happens?" Episode 13 is, in fact, a somewhat bizarre example of what I call the What Could Go Wrong Game. Panel 5 showed a simple Happy Path: Find Scientist, Recharge Car, and Drive Home. But that would've made for about a 20 minute movie, and no one would've ever even heard about Teen Wolf. (OK, maybe that wouldn't have been so bad...) So at each step, we looked at plausible complications (yes, disrupting the Spacetime Continuum is plausible -- don't make me prove it!) and added Activities to respond to those complications.

And Mitch, as for this...

It's funny, at first, it was all about just enjoying a humorous comic strip. Now it's about making sens of something that may have practical use for my own projects.

...man, you just made my week! And you made the whole Ulterior Motive Lounge worthwhile. It's almost like I'm accomplishing my Ulterior Motive, or something!

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


Comments on this post: Ulterior Motive Lounge Q&A 2: Battle of the Twitter Guest Stars!

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


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