I am so, so very touched.

My good friend John Hopkins, current president of GANG, is as big a fan of the Apollo program as I am. We can trade Apollo stories all night. And John has been making me envious the last few meetings with tales of Virtual LM: A Pictorial Essay of the Engineering and Construction of the Apollo Lunar Module. I'm too pragmatic: I can never really picture myself as one of the Apollo astronauts. But the engineers of the program, those folks I can empathize with. My favorite episode of From the Earth to the Moon tells the story of the team who built the LMs. Well, this book is full of incredibly detailed design sketches and notes for the LM, as well as stories from the design and construction. And the bonus CD includes lots of photographs of LM test units, as well as operations manuals and checklists for the LM. It's a true delight.

Tonight, after my presentation at GANG, John gave me a copy of Virtual LM. So I wanted to take this opportunity to thank him publicly. This is truly a book I'll treasure.

I'll let you know when the slides and sample code for my presentation are up at the GANG site. I would post them on my site tonight; but I've got something else to occupy my time right now, thank you very much. (And thank John very much!)

So for Christmas, besides a super-cool Superman Returns lunch box with the two-disc Superman Returns DVD inside (and dang, I can't find a link for that lunch box online anywhere!), Sandy got me The Tick vs. Season One, available on DVD at long last (and for sale by Disney, not Fox, where the shows originally aired — no idea how that happened). And I was reading the back, and saw a little asterisked notice: "Does not include episode 11".

Well, that made me curious, so I went to TV.com and found that episode 11 is The Tick vs. the Mole Men. I remembered that episode: it involved a beautiful supermodel named Mindy who was pursued by a bunch of subterranean Molemen, who were themselves pursued by the evil Lava King. It turns out that the lead Mole Man is in love with Mindy, who actually is a visitor from the mole lands herself. Once the Lava King is defeated, Mindy returns to be the Mole Queen.

So that left me wondering: why leave that episode out? And that led me to this discussion and a bit of unofficial speculation:

""The Tick vs. The Mole Men" features an unauthorized use of Cindy Crawford's likeness, that's why it will not be included

Officially, the episode is missing for "creative considerations", and "may appear in a later collection". But ya know, I've seen this episode maybe half a dozen times; and I just realized that Mindy Moleford does indeed have a prominent mole, just like some other supermodel.

On the other hand, Comics2Film insists that's not the reason, and that there's another reason that they do know but won't discuss because that would complicate legal negotiations between the parties. I can't imagine who else might have an opinion on this episode...

Note: I bumped this to the top, because I got the film from Sandy for Christmas. Merry Christmas, to all! And to all, a good night!

Whoa...

Wow...

Hahahaha...

Yes!!!

Yeehaaa!

Whoa...

Those are a few of the spur-of-the-moment thoughts I recall from the time I just spent watching Superman Returns in IMAX 3D.

And just in case I forgot: Whoa...

OK, this review is going to wander a bit. And there may be spoilers. Just so you can't say you weren't warned.

[Oh, no, Mommy. When Martin tells us he's gonna wander, that means it's gonna be real long. I know, dear. But if he wants to stay at Kinko's until after midnight writing a silly movie review, getting eaten up by mosquitos, how are we going to stop him? I'll bet if Superman were here, he could stop 'im. I don't know if even Superman's that powerful, dear. Once Martin starts making up conversations with imaginary characters, he's pretty much past the point of no return.]

Just so you know where I'm coming from here: Superman is my fav'rit. (And if you don't get the reference there, then you just haven't been reading enough Superman.) Oh, I've been teased away by lots of other, newer superheroes over the years; and I enjoy them all: Batman, Spider-Man, Captain Marvel (the original, please), Metamorpho, Green Lantern (every one of them, even Kyle), Aquaman, Wonder Woman, Supergirl, the Legion of Super-Heroes, Infinity Inc., Blue Devil, 'Mazing Man (for the truly discerning comics fan), the Flash, the Fantastic Four, the New Gods, the Phantom Stranger, the Outsiders, Black Lightning, Luke Cage... Plain and simple, I love mainstream superhero comics. I know, it's corny and old fashioned. I know, anime or indies are what all the cool kids read. (Actually, I like a lot of indies, too. Anime? Eh.) I know, grown ups aren't supposed to read comic books. And I just. Don't. Care. Make fun of me all you want. I'm sure I would find your hobbies to be just hilarious, too, but I'm too polite to point that out.

But of them all, Superman is the one I've read most consistently. While I can't say for certain, I'm guessing I read my first Superman comic roughly 40 years ago. Well, OK, 39 years ago: with the help of indulgent parents and big brothers, I taught myself to read at age 4; and I gotta believe one of the first things I read was a Superman comic. See, one of those brothers bought lots of comics, and so they were always there at hand. And for not being a big comic fan today, he bought some amazing classics: the first issues of Kirby's New Gods and Forever People, half of the Kirby Jimmy Olsen issues, the last three issues of O'Neill/Adams's Green Lantern/Green Arrow (the phrase "Send me a bill" still sends a chill up my spine), "Spider-Man: No More", and a good chunk of the "Kryptonite: No More"/Sandman Superman saga. Brother Joe, if you had kept those in mint condition, they would be worth some money today. But instead, you let little brother and later little sister read them. Thank you. And again: thank you.

[Mommy, is Martin ever going to write about the movie? Shh. Be patient, dear. He thinks he is writing about the movie.]

And so I've been reading Superman all my life; but in a sense, I've been reading him nearly twice that long. Over the years, I've gotten to read a lot of the historical Superman tales. I'm keeping up with the modern Superman tales. And I've also watched the Superman cartoons, from the Fleischer classics to the 70s not-so-classics to the Super-Friends to the modern cartoons. I've also watched Lois & Clark. Thanks to Sandy, I'm getting to see the old George Reeves episodes that they never seemed to rerun in our area when I was growing up.

But for me, the Superman will always be the Superman of the 70s. Part Kirby, part O'Neill, to be sure; but in larger part, the Superman of the 70s was the work of two gentlemen. Carey Bates was one. But the other, and my fav'rit, was Elliot S! Maggin. (The "S!" is because comics scripters of the day tended to go overboard with exclamation points, so Mr. Maggin felt it was an obligation.) But what made me recognize his name was not his comics. At the time, I was fairly ignorant of who was creating the comics. No, I became his fan after reading his first Superman novel, Superman: Last Son of Krypton. And I became a permanent fan with his next book, Superman: Miracle Monday. No, they're not in print any more. (If you ask nicely, Mr. Maggin may explain why. Wear a spittle shield.) Yes, as a matter of fact, I do own two copies of each. No, you may not have my spare copies. Those are for loaning out to close friends and cherished family members, so that if perchance the borrower loses them, I'll still have my originals.

Those two books, published as tie-ins to the first two Chistopher Reeve movies, are in my opinion the two best Superman stories ever. Period. (The third best happens to be Kingdom Come, the novelization of Mark Waid's ground-breaking story of Earth after Superman gave up The Never-Ending Struggle. When Mr. Waid knew a novelization was planned, he knew just who he wanted to write it; and when his chosen author balked, he decided to sway the author by hook or by crook. And so, the very last page of the comic series has this note: "Dedicated to Elliott S! Maggin." So mayhaps I'm not the only one who thinks Mr. Maggin is his fav'rit.)

[Mommy, I was really bad today. Could you send me to my room? Not yet, dear. I think there's a point coming soon.]

And what made these books so much the definition of the character was a bit of Kryptonian philosophy Mr. Maggin dreamed up: There is a right and a wrong in the universe, and the distinction is not very hard to make. And that right there defines Superman at his best. It defines his biggest weakness: no, not kryptonite, but rather a moral blindspot that makes him simply unable to imagine that anyone would do anything but the right thing, and just as much as they are able. He cannot see the world from a criminal's perspective, because it just isn't in him to do so, so criminals can often surprise him. And this philosophy also defines his greatest strength: by always doing what's right no matter what the cost to himself, he inspires the rest of us to try just a little harder. It's not the Super that counts, it's the Man. (We can argue later about whether that Kryptonian philosophy is just a little too simplistic. In the real world, sometimes the best you can do is to choose the least wrong.)

And the fourth and fifth-best Superman stories ever, in my opinion, were the first two Christopher Reeve films. I have never heard a theater crowd explode like they did at "General. Would you care to step outside?" I'm still getting the chills here, just typing that line. Yes, I would have much preferred if they had filmed Mr. Maggin's books instead; but honestly, those were just a little too steeped in DC Universe lore to make good movies for the general public, I think. Even with the too-gimmicky ending in Superman II (come on, where did those powers come from?), those two films were simply the best Superman stories put to film. (Note: were.)

And before you go see Superman Returns, I stongly recommend that you go rent Superman I and II. Let's just ignore III and IV for this discussion, OK? And especially Supergirl. For the purposes of this film, those don't exist. But this film is very much a sequel to Superman II. Not juat "inspired by": it follows directly on the events of the second film.

But beyond sequel, it's an homage to the Christopher Reeve Superman films. And somewhere along the way, I started to see it as an homage to Elliot S! Maggin as well. And without giving too much away, it's an homage to fathers as well.

And one more thing: while it's truly respectful of the Christopher Reeve films, it's better. I expected a lot of things from this film; but I didn't expect to be drying my eyes as I left the theater.

[Yay! He's finally writing about the movie! Hush, dear. You might distract him, just when he's found the point.]

This film starts before it starts: an opening text frame tells how Superman learned that astronomers had found remnants of Krypton, and he left Earth to investigate. This all took place shortly after Superman II. Five years have elapsed. We never really learn much about what he found out there, other than that Krypton really is gone.

But what he finds when he comes back, now there's the story! His mother is still alive, and welcomes him back. (His father died near the start of Superman I.) The Daily Planet is mostly unchanged, except for one vital difference: Lois Lane. She has changed dramatically. She's engaged to Perry White's nephew (Richard), she's a single mother of a rather weak and asthmatic son (Jason), and she has won a Pulitzer — for an editorial entitled, "Why Earth Doesn't Need a Superman". She seems to have moved on; and with that one change, everything in Superman's life is changed, even though nothing else has.

Yes, folks, this is a relationship movie. Oh, it's a superhero movie — and a very cool one at that, especially with the IMAX 3D (selected scenes are in 3D, and they flash glasses on the screen to let you know when to put yours on) — but it's really about Superman's two most important relationships: with Lois, and with his birth father, Jor-El. Even though Jor-El barely puts in an appearance, Superman spends most of the movie trying to live up to his father's legacy. And in the end, he finds that legacy has some mighty big shoes to fill, shoes he never expected. (I won't spoil the ending, even though the "surprise" actually happens about two-thirds of the way through the film. And it wasn't much of a surprise to me, since I guessed it six months before I saw the film.) When he's not trying to live up to the legacy, he's trying to understand how Lois was so hurt by his leaving, and to get her to understand why he had no choice: if he had tried to tell her goodbye, he could never have left. But she's too bitter, for some reason, she can't seem to forgive him.

But while Superman struggles to live up to Jor-El's legacy, Lex Luthor corrupts it. Yes, ol' Lex is back, and meaner than ever; and he uses what he learned about Kryptonian technology in Superman II for his latest scheme: to create a new, Kryptonian continent, so that he can get rich as its owner — while he just happens to drown most of the Americas in the process.

And that's just one example where this film is an homage to the first two. In those two films, Lex's grand schemes always revolved around mega land grabs. In this one, he finally succeeds. Well, for a while. We all know Superman will stop him in the end. (And kudos to the filmmakers: I just now realized just how ironic Lex's final scene is.) Here are some other ways in which this film pays homage to the earlier films:

[Mommy, what's an "omaj"? It means "tribute", dear. Remembering someone in a very nice way. Martin's just being pretentious again, because some of his favorite comics are from a company called "Homage Comics".]

• The opening credits are just about exactly the same design. It was eerie, like I just fell back in time 25 years.


• While newcomer Brandon Routh doesn't exactly look like Christopher Reeve, he certainly sounds like him. In fact, he sounds like him twice. Mr. Reeve affected two different voices for Superman and for Clark Kent. Mr. Routh nails both of them close enough to make you comfortable that you're watching the same characters. (Noboy else consciously imitates their predecessors; but Superman.Clark was the one who counted.)


• Physically, Mr. Routh does very well what Mr. Reeve did so perfectly: play Clark Kent in such a way thatyou really believe no one would notice he's Superman.


• The whole production and art direction is completely modeled on the first two films — especially the Kryptonian technology. The Fortress, the ship, and the all-important crystal are all old friends here.


• The music is a very nice update of the classic John Williams score.


• A running sight gag in the first two films was Luthor's baldness and his various wigs. Well, the gag continues in this film. One very tense but funny scene was when Lois and Jason stumble into an unknown bedroom, and Jason laughs at all the wigs. Lois looks at them, and instantly all the other pieces of the puzzle fall into place (but too late).


• In the first film, Luthor tracks down his first Kryptonite metorite in Addis Abbaba, a city in Ethiopia. In this film, when a meteorite is mysteriously stolen from the museum, the smashed display case includes a sign saying that it came from, yes, Addis Abbaba.


• And the lines. Ah, classic little lines from the first two films show up here. Only now, they're loaded with additional emotional meaning. "I'm always around, Lois."

And there's a lot more. And then, just in case you missed the homage, there's a line in the end credits: "Dedicated with love to Christopher Reeve and Dana Reeve." For those who didn't hear, after seeing her husband through the years of his paralysis and doing what she could for his legacy after his death, Dana Reeve died this year from cancer. And the filmmakers paid their homage to both of them.

But that's not the only homage in this film. We also got two guest stars from the old Adventures of Superman series: Noel Neill (who played Lois Lane) and Jack Larson (who played Jimmy Olsen). Their parts here were small, but it was still a nice nod to them and their fans.

OK, OK, so it's an homage; but how is it better? Oh, in oh so many ways:

• The special effects are 30 years better. Superman I was truly ground-breaking for its day. Today, most personal computers can do better effects. Even though everything looks the same in some ways — the Fortress, especially — it all looks better. One tiny example: the explosion of Krypton in Superman I was actually a microscope recording of a histamine cell exploding. In this film, it's a wonderfully detailed CGI rendering. (In 3D, at IMAX theaters!)


• And wow! What special effects. Now I've said more times than I can recall that special effects in movies aren't that important to me. And as a general rule, they aren't. But come on! This is a superhero film! It has to have larger-than-life action! And this film delivers. The airplane rescue is stupendous. The New Krypton scenes are really creepy. And the crushing of Metropolis — well, I have to save that discussion for just a little bit.


• The whole thing just looks better. Street scenes in the first two films had the feel of soundstages, even when they weren't. Here, you just know you can actually walk around Metropolis.


• No offense to Margot Kidder, but Kate Bosworth just looks more like Lois Lane. Also, she got much more mature dialog to work with.


• And that maturity. That's probably the biggest difference. The first two films had just a touch of camp about them. This film plays it straight.


• And where this film particularly plays it straight is with Lex Luthor. I love Gene Hackman; but his Lex Luthor had a lot of the buffoon about him. (Rather surprising for Mr. Hackman, really.) Even though Kevin Spacey's Lex Luthor surrounds himself with buffoons, he's really, really scary. And when he tries to be funny, he's even scarier. Think the Joker, and you won't be far off: if he's trying to be funny, it's to distract you from his trying to kill you, or to gloat over having already killed you.


• And yet there is humor in the film; but it's more subtle, more gentle than in the first two films. Some of it's in-jokes, like the Addis Abbaba meteorite. Some of it's very subtle, like the name of Luthor's ship (you've got to look fast for that one). And some of it's pretty clever, like when a kid with a cell phone gets better shots of Superman than Jimmy can get with his expensive camera. (Don't worry, Jimmy fans, he makes up for it eventually.) None of it's laugh-out-loud funny (although I laughed at the Addis Abbaba sign, as did the similar-in-age guy next to me); but none of it's camp, either. It fits the story more naturally.

OK, OK, OK. You liked it. But how is it an homage to Mr. Maggin?

Well, it may not be. That may just be me reading into it. But I really felt like there was, if not a Maggin homage, then a definite Maggin influence, in at least five ways:

• First, there's that whole crushing of Metropolis scene. I won't tell you the details, because that would spoil it. But one of Mr. Maggin's specialties in his novels is what I think of as the "Superman is everywhere" chapter. Some criminal plot or some menace comes up, and it has lots of ramifications in lots of places all at once. This is a job for Superman! See, among his many powers, Superman is just a wee bit faster than a speeding bullet. Faster than that, even. So Mr. Maggin tells the story at Superman's rate of perception as he zips from crisis to crisis and handles each in the most appropriate way: disarming a villain here, crashing two villain-laden hang gliders together there, all while using super ventrilloquism to convince another villain that the plan has been called off. Pages and pages of detailed action, all at a leisurely pace for Superman, and all in under 12 seconds for the villains. Prior to this film, I would've called such a scene unfilmable. In fact, I would've predicted exactly what bugged me about some of the fight scenes in Batman Begins: to make the action believably fast, they would have to make it too fast for the viewer to follow. Well, somehow, director Brian Singer defied my expectations. While the crushing of Metropolis isn't quite as involved as one of Mr. Maggin's "Superman is everywhere" chapters, it's pretty involved. There are a lot of menaces in a lot of places, and Superman manages to be everywhere at once, dealing with them. The scene where Superman flies through the city streets but then rolls leisurely over onto his back, so he can look back and vaporize a whole street full of falling debris — priceless! I just looked at that whole section and said, "Wow! That's worthy of Maggin!"


• In Superman: Miracle Monday, Mr. Maggin has a very poignant scene in which Superman turns up his superhearing and listens — really listens — to the whole Earth at once. And eventually, he hears a kind of symphony; and he hears that he has a part in it. In this film, Superman tells Lois that despite her article on why no one needs a Superman, he can hear all over, and he just keeps hearing people calling for help. It wasn't exactly an echo of Mr. Maggin's scene, but it made me think of that scene.


• There's a definite element of "There is a right and a wrong..." here. This is a Superman who just has to do what's right, no matter what. To be blunt, Superman gets the stuffing kicked out of him in this film, far more than in Superman II; and yet he just keeps trying, no matter what. It's simply what he has to do.


• Mr. Maggin had another recurring theme. In fact, he originally wrote it for a writing class; and when he got a lousy grade, he sent it to DC instead, and they bought the script, and they hired him from there. (And now he's teaching writing. Kids, don't give up just because someone tells you you can't succeed, even if it's a teacher. Sometimes teachers are wrong, too. Did you ever see Superman give up? Huh? Huh?) That story, "Must There Be A Superman?" dealt with the possibility that by solving all of our problems, Superman was stunting our growth and making us dependent on him. He learned to let us solve our own problems, stumbling along the way and picking ourselves up and learning in the process; and he just gave a helping hand when the problems were too big for us. Well, that theme came up in this film, in a briefly remembered bit of advice from Jor-El; and in fact, it's Lois and Richard who end up saving Superman at one point. And Superman also steps back at one point to let people solve their own problems. This is straight from Mr. Maggin.

And the last bit of Maggin influence — Well, I want to close with that. So let me just say that this film, while very good, isn't perfect. It's a bit long. The end, especially, drags a bit, and could've been trimmed at least five minutes. And the director relied a little too heavily on slow motion in a couple of places (although one slow-mo scene that I thought dragged on a bit too long was justified in the end with a wince-inducing special effect that was actually kinda cool, if you're not squeamish about eyes). But those are minor quibbles. In most films, I can come up with a dozen quibbles more than that. None of that stopped me from saying toward the end, "OK, when's World's Finest coming?" (For the non-comic fans: World's Finest was a long-running Superman/Batman team-up book. After Batman Begins and this film, it's time for a World's Finest film.)

Back to that last bit of Maggin influence — and again, I'll concede this may be me reading into it. Maybe it's just a coincidence that the theme is so strong in Mr. Maggin's books and in this film, since it is kinda central to the whole Superman mythos. It has to do with fathers. A big element of Mr. Maggin's books was just how much Jor-El loved his son, and how hard he worked to protect him and guide him even though he would be long dead before his son grew up. He left lessons, and he chose protectors, and he chose the best, safest environment he could find for his son. He saw his responsibility to his son as his last, most important duty. And that's pretty much how this film opens; and in subtle ways, that comes up in places throughout the film. And it's how the film ends, as Superman finally fully appreciates just how important those sacrifices were to his father. (And I tried to be oblique, but I probably just ruined the ending for you. Serves you right for being so smart.)

And when I left the theater, I felt — Whoa... I felt — Wow... I felt Hahahaha, and Yes!!! And Yeehaaa! I felt like I was 18 again, seeing this film just after Superman II. I felt awed. I felt invigorated. And a reaction I never expected from a silly superhero film: I miss my fav'rit. I miss my Dad.

[Mommy, Martin sounds sad. Didn't he like the movie? Yes, dear. I think he liked it very, very much. Now goodnight. Sleep tight. Don't let the bedbugs bite.]




Update: Bryce Zabel makes many of the same points. But he uses, like, one-tenth as many words. Bet you wish I'd told you that at the start of the review, huh?

Update 2: Ken Lammers has a very different reaction. (Warning! Major spoilers!) That's OK. I respect that. I don't agree with it, but I respect it. (But, um, dude, if you're going to say that that first action is out of character, then you're going to have to say that the action that led to that action back in Superman II was out of character. It's the same action, really, just cause and effect. And it would never happen in the comics. Movie audiences these days kinda expect it. We can debate the goodness of that expectation, but there it is.)

Update 3: James Hudnall liked it, too, though he thinks there was more room to cut at the end. For those who don't know James, he's a comics writer who has actually written in the Superman series, so I kinda think his opinion has some merit. James also wrote Harsh Realm, which was adapted into a TV series by Chris Carter of X-Files fame. And his book The Psyhco is working its way toward a film version. I first learned of James through his incredible Espers series. And he's a software geek who knows UML. So he's kinda like me, but, umm, cool and all that.

Note: I bumped this to the top, because I got the film from Sandy for Christmas. Merry Christmas, to all! And to all, a good night!

Whoa...

Wow...

Hahahaha...

Yes!!!

Yeehaaa!

Whoa...

Those are a few of the spur-of-the-moment thoughts I recall from the time I just spent watching Superman Returns in IMAX 3D.

And just in case I forgot: Whoa...

OK, this review is going to wander a bit. And there may be spoilers. Just so you can't say you weren't warned.

[Oh, no, Mommy. When Martin tells us he's gonna wander, that means it's gonna be real long. I know, dear. But if he wants to stay at Kinko's until after midnight writing a silly movie review, getting eaten up by mosquitos, how are we going to stop him? I'll bet if Superman were here, he could stop 'im. I don't know if even Superman's that powerful, dear. Once Martin starts making up conversations with imaginary characters, he's pretty much past the point of no return.]

Just so you know where I'm coming from here: Superman is my fav'rit. (And if you don't get the reference there, then you just haven't been reading enough Superman.) Oh, I've been teased away by lots of other, newer superheroes over the years; and I enjoy them all: Batman, Spider-Man, Captain Marvel (the original, please), Metamorpho, Green Lantern (every one of them, even Kyle), Aquaman, Wonder Woman, Supergirl, the Legion of Super-Heroes, Infinity Inc., Blue Devil, 'Mazing Man (for the truly discerning comics fan), the Flash, the Fantastic Four, the New Gods, the Phantom Stranger, the Outsiders, Black Lightning, Luke Cage... Plain and simple, I love mainstream superhero comics. I know, it's corny and old fashioned. I know, anime or indies are what all the cool kids read. (Actually, I like a lot of indies, too. Anime? Eh.) I know, grown ups aren't supposed to read comic books. And I just. Don't. Care. Make fun of me all you want. I'm sure I would find your hobbies to be just hilarious, too, but I'm too polite to point that out.

But of them all, Superman is the one I've read most consistently. While I can't say for certain, I'm guessing I read my first Superman comic roughly 40 years ago. Well, OK, 39 years ago: with the help of indulgent parents and big brothers, I taught myself to read at age 4; and I gotta believe one of the first things I read was a Superman comic. See, one of those brothers bought lots of comics, and so they were always there at hand. And for not being a big comic fan today, he bought some amazing classics: the first issues of Kirby's New Gods and Forever People, half of the Kirby Jimmy Olsen issues, the last three issues of O'Neill/Adams's Green Lantern/Green Arrow (the phrase "Send me a bill" still sends a chill up my spine), "Spider-Man: No More", and a good chunk of the "Kryptonite: No More"/Sandman Superman saga. Brother Joe, if you had kept those in mint condition, they would be worth some money today. But instead, you let little brother and later little sister read them. Thank you. And again: thank you.

[Mommy, is Martin ever going to write about the movie? Shh. Be patient, dear. He thinks he is writing about the movie.]

And so I've been reading Superman all my life; but in a sense, I've been reading him nearly twice that long. Over the years, I've gotten to read a lot of the historical Superman tales. I'm keeping up with the modern Superman tales. And I've also watched the Superman cartoons, from the Fleischer classics to the 70s not-so-classics to the Super-Friends to the modern cartoons. I've also watched Lois & Clark. Thanks to Sandy, I'm getting to see the old George Reeves episodes that they never seemed to rerun in our area when I was growing up.

But for me, the Superman will always be the Superman of the 70s. Part Kirby, part O'Neill, to be sure; but in larger part, the Superman of the 70s was the work of two gentlemen. Carey Bates was one. But the other, and my fav'rit, was Elliot S! Maggin. (The "S!" is because comics scripters of the day tended to go overboard with exclamation points, so Mr. Maggin felt it was an obligation.) But what made me recognize his name was not his comics. At the time, I was fairly ignorant of who was creating the comics. No, I became his fan after reading his first Superman novel, Superman: Last Son of Krypton. And I became a permanent fan with his next book, Superman: Miracle Monday. No, they're not in print any more. (If you ask nicely, Mr. Maggin may explain why. Wear a spittle shield.) Yes, as a matter of fact, I do own two copies of each. No, you may not have my spare copies. Those are for loaning out to close friends and cherished family members, so that if perchance the borrower loses them, I'll still have my originals.

Those two books, published as tie-ins to the first two Chistopher Reeve movies, are in my opinion the two best Superman stories ever. Period. (The third best happens to be Kingdom Come, the novelization of Mark Waid's ground-breaking story of Earth after Superman gave up The Never-Ending Struggle. When Mr. Waid knew a novelization was planned, he knew just who he wanted to write it; and when his chosen author balked, he decided to sway the author by hook or by crook. And so, the very last page of the comic series has this note: "Dedicated to Elliott S! Maggin." So mayhaps I'm not the only one who thinks Mr. Maggin is his fav'rit.)

[Mommy, I was really bad today. Could you send me to my room? Not yet, dear. I think there's a point coming soon.]

And what made these books so much the definition of the character was a bit of Kryptonian philosophy Mr. Maggin dreamed up: There is a right and a wrong in the universe, and the distinction is not very hard to make. And that right there defines Superman at his best. It defines his biggest weakness: no, not kryptonite, but rather a moral blindspot that makes him simply unable to imagine that anyone would do anything but the right thing, and just as much as they are able. He cannot see the world from a criminal's perspective, because it just isn't in him to do so, so criminals can often surprise him. And this philosophy also defines his greatest strength: by always doing what's right no matter what the cost to himself, he inspires the rest of us to try just a little harder. It's not the Super that counts, it's the Man. (We can argue later about whether that Kryptonian philosophy is just a little too simplistic. In the real world, sometimes the best you can do is to choose the least wrong.)

And the fourth and fifth-best Superman stories ever, in my opinion, were the first two Christopher Reeve films. I have never heard a theater crowd explode like they did at "General. Would you care to step outside?" I'm still getting the chills here, just typing that line. Yes, I would have much preferred if they had filmed Mr. Maggin's books instead; but honestly, those were just a little too steeped in DC Universe lore to make good movies for the general public, I think. Even with the too-gimmicky ending in Superman II (come on, where did those powers come from?), those two films were simply the best Superman stories put to film. (Note: were.)

And before you go see Superman Returns, I stongly recommend that you go rent Superman I and II. Let's just ignore III and IV for this discussion, OK? And especially Supergirl. For the purposes of this film, those don't exist. But this film is very much a sequel to Superman II. Not juat "inspired by": it follows directly on the events of the second film.

But beyond sequel, it's an homage to the Christopher Reeve Superman films. And somewhere along the way, I started to see it as an homage to Elliot S! Maggin as well. And without giving too much away, it's an homage to fathers as well.

And one more thing: while it's truly respectful of the Christopher Reeve films, it's better. I expected a lot of things from this film; but I didn't expect to be drying my eyes as I left the theater.

[Yay! He's finally writing about the movie! Hush, dear. You might distract him, just when he's found the point.]

This film starts before it starts: an opening text frame tells how Superman learned that astronomers had found remnants of Krypton, and he left Earth to investigate. This all took place shortly after Superman II. Five years have elapsed. We never really learn much about what he found out there, other than that Krypton really is gone.

But what he finds when he comes back, now there's the story! His mother is still alive, and welcomes him back. (His father died near the start of Superman I.) The Daily Planet is mostly unchanged, except for one vital difference: Lois Lane. She has changed dramatically. She's engaged to Perry White's nephew (Richard), she's a single mother of a rather weak and asthmatic son (Jason), and she has won a Pulitzer — for an editorial entitled, "Why Earth Doesn't Need a Superman". She seems to have moved on; and with that one change, everything in Superman's life is changed, even though nothing else has.

Yes, folks, this is a relationship movie. Oh, it's a superhero movie — and a very cool one at that, especially with the IMAX 3D (selected scenes are in 3D, and they flash glasses on the screen to let you know when to put yours on) — but it's really about Superman's two most important relationships: with Lois, and with his birth father, Jor-El. Even though Jor-El barely puts in an appearance, Superman spends most of the movie trying to live up to his father's legacy. And in the end, he finds that legacy has some mighty big shoes to fill, shoes he never expected. (I won't spoil the ending, even though the "surprise" actually happens about two-thirds of the way through the film. And it wasn't much of a surprise to me, since I guessed it six months before I saw the film.) When he's not trying to live up to the legacy, he's trying to understand how Lois was so hurt by his leaving, and to get her to understand why he had no choice: if he had tried to tell her goodbye, he could never have left. But she's too bitter, for some reason, she can't seem to forgive him.

But while Superman struggles to live up to Jor-El's legacy, Lex Luthor corrupts it. Yes, ol' Lex is back, and meaner than ever; and he uses what he learned about Kryptonian technology in Superman II for his latest scheme: to create a new, Kryptonian continent, so that he can get rich as its owner — while he just happens to drown most of the Americas in the process.

And that's just one example where this film is an homage to the first two. In those two films, Lex's grand schemes always revolved around mega land grabs. In this one, he finally succeeds. Well, for a while. We all know Superman will stop him in the end. (And kudos to the filmmakers: I just now realized just how ironic Lex's final scene is.) Here are some other ways in which this film pays homage to the earlier films:

[Mommy, what's an "omaj"? It means "tribute", dear. Remembering someone in a very nice way. Martin's just being pretentious again, because some of his favorite comics are from a company called "Homage Comics".]

• The opening credits are just about exactly the same design. It was eerie, like I just fell back in time 25 years.


• While newcomer Brandon Routh doesn't exactly look like Christopher Reeve, he certainly sounds like him. In fact, he sounds like him twice. Mr. Reeve affected two different voices for Superman and for Clark Kent. Mr. Routh nails both of them close enough to make you comfortable that you're watching the same characters. (Noboy else consciously imitates their predecessors; but Superman.Clark was the one who counted.)


• Physically, Mr. Routh does very well what Mr. Reeve did so perfectly: play Clark Kent in such a way thatyou really believe no one would notice he's Superman.


• The whole production and art direction is completely modeled on the first two films — especially the Kryptonian technology. The Fortress, the ship, and the all-important crystal are all old friends here.


• The music is a very nice update of the classic John Williams score.


• A running sight gag in the first two films was Luthor's baldness and his various wigs. Well, the gag continues in this film. One very tense but funny scene was when Lois and Jason stumble into an unknown bedroom, and Jason laughs at all the wigs. Lois looks at them, and instantly all the other pieces of the puzzle fall into place (but too late).


• In the first film, Luthor tracks down his first Kryptonite metorite in Addis Abbaba, a city in Ethiopia. In this film, when a meteorite is mysteriously stolen from the museum, the smashed display case includes a sign saying that it came from, yes, Addis Abbaba.


• And the lines. Ah, classic little lines from the first two films show up here. Only now, they're loaded with additional emotional meaning. "I'm always around, Lois."

And there's a lot more. And then, just in case you missed the homage, there's a line in the end credits: "Dedicated with love to Christopher Reeve and Dana Reeve." For those who didn't hear, after seeing her husband through the years of his paralysis and doing what she could for his legacy after his death, Dana Reeve died this year from cancer. And the filmmakers paid their homage to both of them.

But that's not the only homage in this film. We also got two guest stars from the old Adventures of Superman series: Noel Neill (who played Lois Lane) and Jack Larson (who played Jimmy Olsen). Their parts here were small, but it was still a nice nod to them and their fans.

OK, OK, so it's an homage; but how is it better? Oh, in oh so many ways:

• The special effects are 30 years better. Superman I was truly ground-breaking for its day. Today, most personal computers can do better effects. Even though everything looks the same in some ways — the Fortress, especially — it all looks better. One tiny example: the explosion of Krypton in Superman I was actually a microscope recording of a histamine cell exploding. In this film, it's a wonderfully detailed CGI rendering. (In 3D, at IMAX theaters!)


• And wow! What special effects. Now I've said more times than I can recall that special effects in movies aren't that important to me. And as a general rule, they aren't. But come on! This is a superhero film! It has to have larger-than-life action! And this film delivers. The airplane rescue is stupendous. The New Krypton scenes are really creepy. And the crushing of Metropolis — well, I have to save that discussion for just a little bit.


• The whole thing just looks better. Street scenes in the first two films had the feel of soundstages, even when they weren't. Here, you just know you can actually walk around Metropolis.


• No offense to Margot Kidder, but Kate Bosworth just looks more like Lois Lane. Also, she got much more mature dialog to work with.


• And that maturity. That's probably the biggest difference. The first two films had just a touch of camp about them. This film plays it straight.


• And where this film particularly plays it straight is with Lex Luthor. I love Gene Hackman; but his Lex Luthor had a lot of the buffoon about him. (Rather surprising for Mr. Hackman, really.) Even though Kevin Spacey's Lex Luthor surrounds himself with buffoons, he's really, really scary. And when he tries to be funny, he's even scarier. Think the Joker, and you won't be far off: if he's trying to be funny, it's to distract you from his trying to kill you, or to gloat over having already killed you.


• And yet there is humor in the film; but it's more subtle, more gentle than in the first two films. Some of it's in-jokes, like the Addis Abbaba meteorite. Some of it's very subtle, like the name of Luthor's ship (you've got to look fast for that one). And some of it's pretty clever, like when a kid with a cell phone gets better shots of Superman than Jimmy can get with his expensive camera. (Don't worry, Jimmy fans, he makes up for it eventually.) None of it's laugh-out-loud funny (although I laughed at the Addis Abbaba sign, as did the similar-in-age guy next to me); but none of it's camp, either. It fits the story more naturally.

OK, OK, OK. You liked it. But how is it an homage to Mr. Maggin?

Well, it may not be. That may just be me reading into it. But I really felt like there was, if not a Maggin homage, then a definite Maggin influence, in at least five ways:

• First, there's that whole crushing of Metropolis scene. I won't tell you the details, because that would spoil it. But one of Mr. Maggin's specialties in his novels is what I think of as the "Superman is everywhere" chapter. Some criminal plot or some menace comes up, and it has lots of ramifications in lots of places all at once. This is a job for Superman! See, among his many powers, Superman is just a wee bit faster than a speeding bullet. Faster than that, even. So Mr. Maggin tells the story at Superman's rate of perception as he zips from crisis to crisis and handles each in the most appropriate way: disarming a villain here, crashing two villain-laden hang gliders together there, all while using super ventrilloquism to convince another villain that the plan has been called off. Pages and pages of detailed action, all at a leisurely pace for Superman, and all in under 12 seconds for the villains. Prior to this film, I would've called such a scene unfilmable. In fact, I would've predicted exactly what bugged me about some of the fight scenes in Batman Begins: to make the action believably fast, they would have to make it too fast for the viewer to follow. Well, somehow, director Brian Singer defied my expectations. While the crushing of Metropolis isn't quite as involved as one of Mr. Maggin's "Superman is everywhere" chapters, it's pretty involved. There are a lot of menaces in a lot of places, and Superman manages to be everywhere at once, dealing with them. The scene where Superman flies through the city streets but then rolls leisurely over onto his back, so he can look back and vaporize a whole street full of falling debris — priceless! I just looked at that whole section and said, "Wow! That's worthy of Maggin!"


• In Superman: Miracle Monday, Mr. Maggin has a very poignant scene in which Superman turns up his superhearing and listens — really listens — to the whole Earth at once. And eventually, he hears a kind of symphony; and he hears that he has a part in it. In this film, Superman tells Lois that despite her article on why no one needs a Superman, he can hear all over, and he just keeps hearing people calling for help. It wasn't exactly an echo of Mr. Maggin's scene, but it made me think of that scene.


• There's a definite element of "There is a right and a wrong..." here. This is a Superman who just has to do what's right, no matter what. To be blunt, Superman gets the stuffing kicked out of him in this film, far more than in Superman II; and yet he just keeps trying, no matter what. It's simply what he has to do.


• Mr. Maggin had another recurring theme. In fact, he originally wrote it for a writing class; and when he got a lousy grade, he sent it to DC instead, and they bought the script, and they hired him from there. (And now he's teaching writing. Kids, don't give up just because someone tells you you can't succeed, even if it's a teacher. Sometimes teachers are wrong, too. Did you ever see Superman give up? Huh? Huh?) That story, "Must There Be A Superman?" dealt with the possibility that by solving all of our problems, Superman was stunting our growth and making us dependent on him. He learned to let us solve our own problems, stumbling along the way and picking ourselves up and learning in the process; and he just gave a helping hand when the problems were too big for us. Well, that theme came up in this film, in a briefly remembered bit of advice from Jor-El; and in fact, it's Lois and Richard who end up saving Superman at one point. And Superman also steps back at one point to let people solve their own problems. This is straight from Mr. Maggin.

And the last bit of Maggin influence — Well, I want to close with that. So let me just say that this film, while very good, isn't perfect. It's a bit long. The end, especially, drags a bit, and could've been trimmed at least five minutes. And the director relied a little too heavily on slow motion in a couple of places (although one slow-mo scene that I thought dragged on a bit too long was justified in the end with a wince-inducing special effect that was actually kinda cool, if you're not squeamish about eyes). But those are minor quibbles. In most films, I can come up with a dozen quibbles more than that. None of that stopped me from saying toward the end, "OK, when's World's Finest coming?" (For the non-comic fans: World's Finest was a long-running Superman/Batman team-up book. After Batman Begins and this film, it's time for a World's Finest film.)

Back to that last bit of Maggin influence — and again, I'll concede this may be me reading into it. Maybe it's just a coincidence that the theme is so strong in Mr. Maggin's books and in this film, since it is kinda central to the whole Superman mythos. It has to do with fathers. A big element of Mr. Maggin's books was just how much Jor-El loved his son, and how hard he worked to protect him and guide him even though he would be long dead before his son grew up. He left lessons, and he chose protectors, and he chose the best, safest environment he could find for his son. He saw his responsibility to his son as his last, most important duty. And that's pretty much how this film opens; and in subtle ways, that comes up in places throughout the film. And it's how the film ends, as Superman finally fully appreciates just how important those sacrifices were to his father. (And I tried to be oblique, but I probably just ruined the ending for you. Serves you right for being so smart.)

And when I left the theater, I felt — Whoa... I felt — Wow... I felt Hahahaha, and Yes!!! And Yeehaaa! I felt like I was 18 again, seeing this film just after Superman II. I felt awed. I felt invigorated. And a reaction I never expected from a silly superhero film: I miss my fav'rit. I miss my Dad.

[Mommy, Martin sounds sad. Didn't he like the movie? Yes, dear. I think he liked it very, very much. Now goodnight. Sleep tight. Don't let the bedbugs bite.]




Update: Bryce Zabel makes many of the same points. But he uses, like, one-tenth as many words. Bet you wish I'd told you that at the start of the review, huh?

Update 2: Ken Lammers has a very different reaction. (Warning! Major spoilers!) That's OK. I respect that. I don't agree with it, but I respect it. (But, um, dude, if you're going to say that that first action is out of character, then you're going to have to say that the action that led to that action back in Superman II was out of character. It's the same action, really, just cause and effect. And it would never happen in the comics. Movie audiences these days kinda expect it. We can debate the goodness of that expectation, but there it is.)

Update 3: James Hudnall liked it, too, though he thinks there was more room to cut at the end. For those who don't know James, he's a comics writer who has actually written in the Superman series, so I kinda think his opinion has some merit. James also wrote Harsh Realm, which was adapted into a TV series by Chris Carter of X-Files fame. And his book The Psyhco is working its way toward a film version. I first learned of James through his incredible Espers series. And he's a software geek who knows UML. So he's kinda like me, but, umm, cool and all that.

Nick Schulz reviews David Warsh's Knowledge and the Wealth of Nations. It sounds like important reading:

Thus instead of land, labor and capital--the traditional inputs of economic theory--it was "people, ideas and things" that mattered, driving technological change and entrepreneurial creativity. "No longer were the advantages of technical superiority to be understood as a case of 'market failure,'" Mr. Warsh writes. "They were part of the rules of the game." Such superiority was by its nature temporary--i.e., nonmonopolistic. New knowledge constantly trumped old, and the law (rightly) gave ideas only limited property-protection.

More and more, economists came to see that it was knowledge that made the difference in modern societies--e.g., in software, drugs, industrial processes, biotechnology and other parts of the economy where the upfront costs were large, the payoffs enormous and the benefits widespread. Economists inevitably turned their attention to the institutions or invisible structures--constitutions, customs, property rights, cultural sentiments (like trust)--that help to generate knowledge and sustain its effects.

I'll be looking for it.

The second in a series of vaguely related posts.

Did you ever read The Princess Bride?

No, no, no... Not this Princess Bride. That's the movie. And like most fencers I know, I've watched it way too many times, and can quote from it extensively. It is, in my opinion, one of Rob Reiner's finest moments. And that's saying an awful lot.

But as much of a cliche as I know this is: the book is better. Mr. Goldman (who also wrote the screenplay) had time to tell how his characters got to the story in the film. They each had stories only hinted at on screen. And the important story for today's purposes was thet of Inigo Montoya. ("Hello. My name is Inigo Montoya. You killed my father. Prepare to die." See, I told you I could quote from it excessively — I mean, extensively.) In the film, Inigo hunted the six-fingered man who had commissioned his sword-maker father to make a custom sword, but who then refused to pay for it and killed his father.

But in the book, we learn the story that came before the six-fingered sword. It tells of how the elder Montoya was one of if not the finest swordsmen in the land, and his swords came to be prized beyond any others. He had so much work that he couldn't keep up. So he raised his prices to try to drive business away. But buyers decided that such expensive swords must be even more valuable, so the demand increased. Soon he couldn't keep up with his own standards, and he openly said that the quality would suffer; but people didn't care, because only a genuine Montoya would do. And besides, despite his protests, he was too professional to ever let the quality really suffer.

If he hadn't been such a hard worker, he wouldn't have had to work so hard.

Same lesson, different story: Star Trek. The Enterprise crew is exhausted. They haven't had a rest in months. And on their way to some much-needed shore leave, Starfleet throws them another certain death challenge. And McCoy demands, "Why do they keep giving us all the hard jobs?" And Spock answers, "Because we keep succeeding."

No good deed ever goes unpunished. I really believe this is a law of human nature: the more you succeed, the more people expect from you.

Eight years ago, we of the Ann Arbor Dueling Society decided the time had come to finally do what we had been wanting to do for years: host our own tournament. We were complete newbies; but with a lot of help from the Division and a lot of patience and support from the Y, we pulled it off. We were tired and dirty, but we pulled it off. And we learned. And we vowed to do even better the next year.

And we did. In fact, much better. And better still the year after that.

But at the same time, the Y became a little more strict about the clock. There were various, justifiable reasons — cost of maintenance staff, building security needs, etc. — but probably the biggest was that they were saving and budgeting for a new facility. So while we were getting better at running the tournament, we needed to get better just to keep up.

But here's the thing about fencing tournaments (and I would assume other sports as well, but I can't say): people appreciate a well run event. They like it when things go well, and they get more time to fence and spend less time waiting for things to happen. And when they like a tournament, they're more likely to come back the next year — and to tell their friends about it, so they show up, too. So when you get better at running a tournament, more people show up.

And here's the thing about the Duelist: for various reasons, we chose to hold it in late August. That makes it the first tournament of the season; so people who haven't fenced in a tournament all summer are just a little more eager to show up. And also, it's one of the few tournaments during the pre-Labor Day summer season, when people tend to travel a bit more. So that's another pair of reasons why the Duelist has tended to grow.

And then here's another thing about fencing tournaments: when more people show up, more people want to show up. See, fencers (present company excepted) are all obsessed about improving their ratings. It's like horse racers wanting to run at pole position: a better rating helps you in small ways, and also just indicates that you're a better fencer. And the rules for awarding ratings state the you have to place at-and-such a place with so-and-so-many fencers including a minimum number of fencers of a given rating in order for you to advance in rating. So as more people start showing up at a tournament, the chances for a rating go up, enticing more people to show up at the tournament. It's a vicious positive feedback loop. Yes, we're proud of the size of our tournament; but at the same time, it's vicious.

And yet another thing about fencing tournaments: while the sport is still way less popular in the USA than seems right to us (good grief, one evening I caught two hours of competitive hot dog eating on ESPN, but they still won't air fencing tournaments), the popularity is growing. There are just more fencers out there looking for tournaments. (In our own miniscule way, we like to think we're helping that growth.)

Now here's one more thing yet about fencing tournaments: unless you can add fencing strips and directors, adding more people tends to make the tournament take longer according to the square of the number of people. See, initial fencing is divided up into roughly equal pools, where the number of pools is pretty much limited to the number of directors you have. (Michigan has some fine directors, but doesn't have many directors over all.) So if you add more people without adding more directors, you have to make the pools larger. And since the rules for pools are that each person in a pool fences each other person in that pool, well, that's an n-squared growth problem. Actually, its (n-squared + n) / 2 (George could explain why; but because I studied under him, the answer's intuitive to me.) Six people in a pool means 15 pool bouts. Seven people in a pool means 21 pool bouts, so a 16% increase in fencers means a 40% increase in bouts. And eight people in a pool means 28 pool bouts, or nearly double the 15 we started with. Adding people slows you down. A lot.

So while we have been doing everything in our power to get better and better at running a tournament, the very success we achieve makes it harder to run the next one. Every year we have had to learn from our experience last year and do just a little bit better; but since that sort of improvement can only go so far, we have had to invent new techniques for getting lots better at things we thought were pretty darn good already.

And that's the sort of game that can give certain sorts of control freaks (hey, I resemble that remark — and thankfully for the tournament, I'm not alone) a certain thrill as you try to find ways to beat your past performance. But in all modesty, last year's tournament (The Duelist VIII) was run as close to picture perfect as any of us could imagine. In our post mortem review (that's fancy talk for "hanging out in the bar afterwards"), we shared stories from the day; and we learned from each other of a half dozen to a dozen different catastrophes that didn't happen because someone on our very capable and conscientious staff happened to be in the right place at the right time and noticed the problem and had the presence of mind and the experience and the ingenuity to deal with it in the most efficient possible fashion. If we had simply had normal human failings just once, the whole schedule would've collapsed. And we are only human, after all, so we had to count luck as a significant factor in our success last year.

But with all that on our side — ingenuity, experience, willingness, determination, and lots of luck — we barely snuck out the door 30 seconds before the Y's closing time. Literally: they locked the doors behind us. Luck alone is not going to cut it this year.

On the plus side, the Y has lengthened their schedule by one hour this year. That will buy us some breathing room; but if the tournament grows at all, or if one catastrophe goes unaverted, we're at risk of the whole house of cards falling apart.

And yes, to the control freaks among us, that's a sick kind of game: how do we do measurably better than the best we could do last year? It's sad, I know, but we find it fun. We have to do better.

All of which is preamble to my next post...

So I was on the way home from my Tablet PC class in Louisville. I got a late start (as I'll explain shortly), and I wanted to stop in Dayton to see Apollo 15 at the Air Force Museum. So I checked into a hotel for the night. And I turned on the TV, flipping through channels for something to watch on a Saturday night.

And I came across the world premier of Superman - Brainiac Attacks on Cartoon Network. This premier was, naturally, intended to promote the DVD release on Tuesday (as well as to hype interest in the film that opens on the 28th, of course). And as usual for the recent Warner animated superhero shows, it was quite well done.

Tim Daly, one of my favorite underrated actors, returns as the voice of Clark/Superman, and Dana Delaney returns as Lois. The story has two primary threads: Clark's desire to share his secret with Lois and his fear that he might put her in danger, and Luthor's plan to rebuild Braniac and work with him to conquer the Earth. The two threads come together when the new, improved Braniac tracks Clark down in his secret identity, and Lois gets injured and infected in the ensuing battle. Will he have to choose between Lois and his responsibilities as Superman? Well, that would spoil the ending, so I'm not going to say.

I missed the first half hour, so I hope I can see it again soon.

...this listing for 40 Years Of The Amazing Spider-Man - *NEW for $20.54.

Why did it win the award for most confusing (nominated, selected, and awarded by me, and I'm not interested in doing any actual research to find anything even worse)? Was it because 11 CDs of Spider-Man comics are listed under Books > Nonfiction Books? No, lots of eBay listings are filed under the wrong category.

No, the problem is that the category is right. It's the title that's wrong. Here's the revised description of this book:

Description (revised)

The Spirit of Islamic Law
Item Specifics - Nonfiction Books
Author: Bernard G. Weiss Category: Law & Government
Publisher: Univ of Georgia Pr
ISBN: 0820328278
Format: Softcover Condition: New
Publication Year: 2006
Special Attributes: —

And then there follows a great-big splash page that describes the book in detail; and trust me, Spider-Man is not mentioned anywhere on that splash page.

Look, I know it probably costs, like, a dollar to cancel an eBay listing and create another one. But there's just no reason I can see to leave this listing up under such a misleading title. No one who wants The Spirit of Islamic Law will find the book under that title; and anyone looking for 40 Years Of The Amazing Spider-Man is not going to be happy when they open this listing. Amused, perhaps, but not happy: you see, the asking price for this book is half the original price of 40 Years Of The Amazing Spider-Man; and since the CD set is now out of print (drat!), secondary sellers on Amazon are charging $90 and up. $20.54 is a really exciting bargain... and then you find that you're looking at the wrong book.

P.S. And yes, Epee Bill, they have issued this title as well. And since it's in PDF format, it should work on that niche computer platform you prefer (though there are some user comments that indicate problems on Macs, including possible incompatibilities with Mac's built-in PDF reader).

So while I was researching this post, I found a post by Ron Coleman that's pretty informative. It discusses an ongoing dispute about the trademark "Superhero", which is jointly claimed by Marvel and DC. (Joint claim of a trademark is a pretty unusual circumstance.)

But more than that, the post has a link to the "Which Superhero am I?" quiz.

Normally I hate these quizzes. They're a waste of time, and often completely incomprehensible in their conclusions. And often I find that the questions aren't even answerable, because none of the answers is right for me. "Which would you rather do on a Saturday night? A. Go out to the dance club and party all night. B. Go out to a bar and get plastered. C. Hang out on the street corner, looking for a fight. D. Stay home and sulk." Hmmm, I don't see either "Stay home with my wife" or "Role-playing games" on that list. (This quiz is actually much better in that regard: it has a much larger number of questions; and the questions are all answered on a 1 to 5 preference scale, so I could answer every one of them.) And often the range of possible quiz conclusions is severely limited: often under ten, and sometimes under five. (This quiz has at least eleven possible conclusions, which makes it a little better than most.)

But come on... It's a superhero quiz! Like I could possibly resist.

And while I'm pleased with the results, I wouldn't have guessed them...

So in preparation for my trip to Montreal, I asked my sister-in-law Lynette for help with a simple French apology, since she had taken French in college. She refused to help, based on one really important fact: in French, it's all about the accent. In this simple phrase...

Je ne comprends pas le français. (I don't understand French.)

...at least 7 out of 26 letters are either barely spoken or else completely silent. (At least to American ears. Linguists have demonstrated that before a certain age, children can hear and recognize phonemes from every human language; but as they start to develop language skills, they lose the ability to discern phonemes that aren't in their native language. Weird, huh?) That's over 25% of the letters that aren't pronounced. A written French phrase pronounced as an American would sound out the letters is almost completely unintelligible to a French speaker. Here is, as best I can transliterate, how that phrase should be properly spoken in French:

Zh' n' compra pah-l fra'say.

Even that is too fully voiced: the r's in comprends and français are so softly voiced as to be almost w-like or h-like. When I hear a native pronounce those words, I can tell I'm getting them wrong; but I can't quite make my mouth get them right.

And here is how an unknowing American might pronounce that phrase, based on its written form:

Gee nee comprends pass lee frankaze.

So Lynette was right: it's all about the accent. Well, not all, but quite a lot. She recommended that I go to Barnes and Noble and pick up some of their French language CDs. She said that she had some good luck with their Russian tapes; and she further said that the audience wouldn't expect too much out of me, but would appreciate me making the effort. (And she was right.)

But I'm kind of picky when it comes to language instruction. I've heard from many sources I trust a lot that Pimsleur is the way to go when you want to get functional in a language quickly. And having tried some Pimsleur in the past, I found it to be pretty good at conversational fluency. It works on a few core principles. One is brevity. Their research says that more than 30 minutes of study per day won't do you any good, because your brain saturates. Another principle is anticipation: where some language instruction methods work by having you repeat phrases, Pimsleur introduces the phrases and then later asks you questions, where the phrases are the answers. There is some repetition, but there's a lot more anticipation. And they like to blindside you: you'll be in the middle of lesson 3, and they'll ask you a question from lesson 2 or 1. And what's surprising to me is how often I'll know the answer when the question is asked out of the blue like that.

So imagine my delight when I learned that the Barnes and Noble disks are Pimsleur disks. I had no reservations after I saw that, and I bought them immediately.

I've been listening to these disks and working the lessons for about a week now; and though they didn't keep me from embarrassing myself in Montreal (a speaker who won't embarrass himself for the audience's amusement just doesn't understand the power of cheap laughs), I honestly feel like I understand more French today than I do Russian — and I spent two long, miserable, interminably frustrating years studying Russian in college. In fact, my Russian experience convinced me that I have almost no aptitude for languages; and yet now thanks to Pimsleur Instant Conversation French, I'm actually having fun learning a language. That's a new experience for me.

Now there is a downside to Pimsleur: it's based exclusively on spoken language, not written. The emphasis is on conversation first, just like children learn their native tongue. The problem with that, though, is that I honestly think I can already comprehend a lot of written French better than I can understand spoken French. Why? Because again: it's all about the accent with spoken French; but there's no accent in written French. When I look at that phrase...

Je ne comprends pas le français.

...I can see a lot in it. The "ne" implies negative (though I would never have guessed that "pas" also implies negative, and I would never have guessed that a language would commonly use two negative indicators in a single phrase). "Comprends" all but screams "comprehends". "Le" is "the", even I know that. And similarly, I've heard "français", but I probably could have figured it out regardless.

But when I hear the phrase...

Zh' n' compra pah-l fra'say.

...there's almost nothing there that I can recognize. "Fra'say" is about it.

Why do I understand so much of the written phrase? Well, I first learned the answer in a fascinating old PBS documentary, The Story of English, that first aired when I was in high school. (And boy, I'm thrilled to learn that's available on DVD! When crap like this makes it to DVD, it makes me worry about the future of a society that actually wants to dredge up such programs; but then when I learn that this amazing PBS documentary is also available, it gives me new hope.) Hosted by Robert MacNeil, this series provides an overview of the history of the English language. As much as I jumped on the Cosmos bandwagon with the rest of the geeks, The Story of English was actually a more significant PBS series in my life. Cosmos just told me more about the scientific world view that I already held; but The Story of English opened up a whole new world view for me, the world of linguistics, of language as history. One of the many things that had fascinated me about The Lord of the Rings was how Professor Tolkien had invented all of his own languages, and how he had in fact written his "histories" (in part) as a way to explain how the languages became what they were. Suddenly, The Story of English made me see that that was exactly how real world languages work: the language is what the history led it to be.

And then I learned the answer again from Professor Thomas E. Toon, one of the two best professors I ever had at the University of Michigan. (The other was Professor George Piranian, who I'm delighted to see is still listed on the Emeritus faculty of the Math department. Some day, I have to write down my George stories...) Professor Toon roped me in with a class on Tolkien. I mean, come on! Tolkien! I read Tolkien's books over a dozen times before college. It had to be an easy A, right? Well, it wasn't easy, but it was a lot of fun; and that was due in equal parts to Professor Toon's knowledge and to his wit. (When his son was born, he posted a notice in the English department for a "Name That Toon" contest.) And so when I saw the listing for his English 301 class, The Power of Words, I couldn't resist. Here was a class on one of my favorite subjects (the history of English) taught by one of my favorite professors. I had to take it. And I enjoyed every minute of it, despite the fact that my papers were graded by a rather humorless TA who just didn't appreciate my style. (For an assignment on humorous language, I wrote the whole thing in a format that consisted of block-quoted jokes, each followed by a one-paragraph essay inspired by the joke; and then the jokes and paragraphs were arranged in such a way as to form a larger rhetorical point. It would've made a brilliant magazine article, I'm telling you, with the jokes as call-outs and the text as responses. But the TA felt that the jokes should've appeared in-line within the paragraphs, and the paper should've been structured in a more traditional, more academic style. Terminally stuffy, I swear. No imagination, no sense of style at all!) I just kept writing my papers my way, regardless. And I felt vindicated when Professor Toon returned my final paper to me, said some very kind words about it, and gave me a retroactive A for four papers. That final paper — a rather prescient essay (if I do say so myself) on how the evolution of computer terminology and its expansion into general use is a microcosm of the evolution of the English language itself — is still kicking around my office somewhere. After Professor Toon's praise, I just can't let that essay go. (And after all that, I still went into computer programming instead of English. It's a disease, I tell you!)

So after those two rather lengthy digressions (if you don't want digressions, you've come to the wrong blog), what's the answer? For that matter, you may have forgotten what the question was by now, so I'll reiterate. Why can I more easily understand written French than spoken French? The accent is what makes the spoken French harder for me, of course; but what makes the written French easier than, say, written Russian? No, it's not the alphabet, though that's a good guess: Russian uses the Cyrillic alphabet, which

Stop, Martin, stop! Please, please stop! Just get to the answer!

All right, all right, I'll stop digressing (yeah, right). The answer is the Norman invasion of 1066, in which William the Conqueror led a Norman force to conquer and occupy England. And when the Normans became the central government, the Anglo-Norman language became the official language of government. And since the English upper class wanted to curry favor with their new rulers, it became the language of the upper class as well.

And since Anglo-Norman is closely tied to French, that means that the English language gained some very strong French influences. In fact, English became something of a bifurcated language, with two words often standing for one concept: a word for the elite, and a word for the commoners. Professor Toon liked to point out examples from food, since food was one thing the two strata of society had in common: the commoners raised it, and the commoners and the elite both ate it. Thus...

• We raise cows, but we eat beef (from boeuf).


• We raise pigs, but we eat pork (from porc).


• We raise chickens, but we eat poultry (from poulet — though "chicken" is used on American menus a lot more often than is "cow" or "pig").

And so on. There are countless examples where English has two words for one concept, and the more "elite" word is derived very clearly from French. I know it might offend the pride of some Brits; but the language of their aristocracy has an awful lot of French in it to this day. And since American English derives from British English, the same is true here.

See? Language as history. Exactly what Mr. MacNeil and Professor Toon (and even Professor Tolkien) were trying to teach: language is never static (unless it's dead: nobody's inventing any new words or grammatical structures in Latin these days); and as a language changes and grows, it reflects the history and changes of the people who speak it. That, my friends, is very fascinating to me. It is a fundamental insight that changed my view of so much of the world, and still colors my approach to all sorts of topics. It made me, like Professor Tolkien and Professor Toon, a philologist: a lover of words, as Professor Toon explained. (Though the etymology is a little confusing: "philo" = lover + "logos" = knowledge leads to "lover of words"? But apparently "logos" also has a secondary connotation of "speech" or "words".) Oh, I'm strictly amateur in the subject. I have more of a Trivial Pursuit level of linguistics knowledge than any real academic knowledge. But still, the ideas fascinate me, and stick with me, and matter a lot to me. (Witness the length of this post!)

And as an amateur philologist and something of an avid reader, I like to think I have both a sizable English vocabulary and at least some familiarity with the sources for many words. I can recognize some degree of French roots, and Latin roots, and Germanic roots. (I can even sometimes recognize Slavic roots, thanks to those two years of Russian; but those are pretty uncommon in English.) But as those roots have been adopted, they have changed. As English has grown, it has modified in one direction; and meanwhile, despite the best efforts of l'Académie (hehehe), French has grown as well, but often in different directions. From my outsider's view, it sounds like the French language has evolved toward efficiency, toward saying more with fewer sounds by deemphasizing and even eliminating extraneous sounds in the words. The result sounds somewhat liquid or even melodious to me.

So when I see written French, it strikes a chord: I recognize a lot that's there, even though I'm still just beginning my study. But when I hear spoken French, that liquid efficiency undercuts all my knowledge. Sometimes when I hear a sentence on the Pimsleur disks, I have this strange feeling that if I just saw it written down, I would puzzle out the meaning. Practically the first sentence Pimsleur teaches is "Je comprends le français." (I understand French.) Three out of the four words there I can puzzle out with little effort when they're written down: "comprends", "le", and "français". That leaves only one word, "je"; and it's short, and I remember that short words are usually simple, fundamental concepts. In this place, I would guess a pronoun: he, she, you, or I. From movies and books, I know that you is "vous", so I would be left with three choices. I'm betting that I would guess I from context.

But "Zh' compra-l fra'say"? When I hear that, there's nothing I can easily pick out, especially when the speaker speaks at a normal conversational speed — and especially with those softly voiced r's. The first time I heard it, it sounded like "Zhucompal fra'say." All the English vocabulary in the world doesn't help me to recognize that.

So while I'm enjoying the Pimsleur disks, I'm supplementing them a lot. In particular, Babel Fish is my friend: it has done most of the heavy lifting of translating for my Ink in 60 Seconds talk, and for this post. I usually listen to the Pimsleur lessons while I'm driving; but when there's something I just can't get, I translate it on Babel Fish later, and it often clears up the confusion.

I think when I get a little farther along, I'll try to pick up some French books (or maybe comic books). I'll say it again: for the first time, I'm actually having fun learning a language. I know I'll get busy with a lot of things, and it will be hard to stay with this; but I hope I can manage it. It would be nice to say that I finally learned another language.

Eh. Mr. King could've stayed in retirement. His style is engaging as ever. He knows how to make sympathetic characters. But endings? The ending for this one is pretty flat.




I finished it, but I probably won't reread it. I'll give this one to Mom.

And the word in question this morning is "retirement". And it's hard to believe of a man who has written so many books, but apparently Stephen King just doesn't know the meaning of the word. And here's more proof. And more (though he might be forgiven for that one, since it's a non-fiction book about a once-in-a-lifetime event that he as a fan must have savored). I can think of a lot of authors who would love to be so "retired".

The man really just can't help himself. He will write, and no resolution is going to stop him.

Unfortunately, his latest work (Cell) demonstrates why he went into "retirement" in the first place. It's not a bad book at all. Mr. King has a natural talent that makes bad writing all but impossible for him, so the book reads well.

But one thing that led to his "retirement" was his feeling that he was repeating himself, that he had somehow mined all his ideas. This feeling came to him when he wrote From a Buick 8, which bore a superficial but unmistakable similarity to Christine. While the books are very different in almost every way, both are at the core stories about myserious cars which control and possess the lives of the people that encounter them. As Mr. King said in an interview on the Mitch Albom show (paraphrased), "Wait a minute. Haven't I been here before?"

And that's the problem with Cell: it has superficial but strong echoes of The Stand. That book told the story of a sudden release of an engineered virus that wipes out most of the world's population. A few of the survivors then go on a road trip toward some looming confrontation between Good and Evil.

And Cell? It tells the story of a mysterious signal that goes out over cell phones, transforming most of the civilized world's population into drooling zombies that slowly evolve into a group mind. A few of the survivors then go on a road trip toward some looming confrontation with the group mind.

Does that make Cell a rehash of The Stand? No. For one thing, it's only one-third the length. For another thing, it's much smaller in scope, both thematically and geographically.

But if Mr. King wanted to avoid repeating himself, this book was not the way to do it. That's not a criticism of the book itself — I'm quite enjoying it, actually — but I think it points out a flaw in his reasoning when he "retired" in the first place. When you write as many books as he has, you can't help revisiting old themes and motifs. He has largely covered the field already, so there's little room for truly new works. And honestly, I think all great artists revisit and build on their earlier works. For that matter, other artists build upon their ideas. So why shouldn't they?

Professor Reynolds links to this very lengthy essay on cultural contamination, and how that may not be as bad as some people want you to believe, by Kwame Anthony Appiah. There's far too much good content here for me to summarize, so I'll just pull out what I think is the most critical point:

So liberty and diversity may well be at odds, and the tensions between them aren't always easily resolved. But the rhetoric of cultural preservation isn't any help. Again, the contradictions are near to hand. Take another look at that Unesco Convention. It affirms the "principle of equal dignity of and respect for all cultures." (What, all cultures - including those of the K.K.K. and the Taliban?) It also affirms "the importance of culture for social cohesion in general, and in particular its potential for the enhancement of the status and role of women in society." (But doesn't "cohesion" argue for uniformity? And wouldn't enhancing the status and role of women involve changing, rather than preserving, cultures?) In Saudi Arabia, people can watch "Will and Grace" on satellite TV - officially proscribed, but available all the same - knowing that, under Saudi law, Will could be beheaded in a public square. In northern Nigeria, mullahs inveigh against polio vaccination while sentencing adulteresses to death by stoning. In India, thousands of wives are burned to death each year for failing to make their dowry payments. Vive la difference? Please.

I'm currently reading Jack McDevitt's Omega, which involves a sorta Prime Directive situation like in Star Trek: a catastrophe looms for a primitive culture, and the cultural preservationists would rather let the natives die than save them and thus expose them to a more advanced culture. The older I get, the more arrogant the Prime Directive sounds to me: sacrificing people's lives for some supercilious view of "culture" that sounds on awful lot like "keeping the primitives in their place". Kwame Anthony Appiah skewers this notion quite adeptly. His essay is long, but it's well worth your attention.

UPDATE: I just read the credits at the end of the essay. It turns out to be an extract from the author's book, Cosmopolitanism: Ethics in a World of Strangers, coming later this month. Gee, just what I needed: an excuse to shop for books...

In my post on my visit to the Cosmosphere, I oversimplified the timeline from Mercury to Apollo. Serves me right for working from memory. Since then, I've had a chance to refresh my failing memory through rereading Apollo by Charles Murray and Catherine Bly Cox.

I say rereading; but in a sense, this is reading anew. I own a copy of the first edition of this book, and have read it three times. I find it to be without a doubt the most thorough history of Apollo that's available. Why? Because where other fine books — such as Chaikin's most excellent A Man on the Moon — focus primarily on the astronauts, this book is first and foremost about the engineers and managers who made the flights possible. I don't want to disparage the work the astronauts did. Indeed, this book (like many others) makes clear that their work began years before they climbed into their spacecraft, and involved plenty of engineering on the ships themselves, along with their training. I have the utmost respect for the astronauts; but as I wrote elsewhere, I'm not the astronaut type. But these engineers... Ah, now these are my people, my inspirations... These are the people whose example moves me to try to do better in my day-to-day work. Whenever my work seems tough, I look at what they did, and say, "No, my job really isn't rocket science. I can do this."

And Murray and Cox's book was the one that made me really appreciate the intellect and discipline and creativity and ingenuity that made Apollo happen. And so, when I saw the new edition with its colorful new cover at the Cosmosphere gift store, I couldn't resist. Mr. Murray had already told me (in private email) that there wasn't much new in this edition, and he couldn't honestly recommend buying a new copy. (So why a second edition? As they explain in the new foreword, the book has become very popular since the first edition went out of print, and they get lots of requests for it. With good reason, I might add.) But fortunately for their bank account, I'm weak. I'm rereading the book now, and finding it even better than I remembered it. It appears that Murray and Cox may have gone the self-publishing route on this edition, since it's published by their own South Mountain Books. I looked into self-publishing for some of our course materials a few years back. Judging by this book, the technology has improved. The quality of the printing is very good; and as I indicated, the new cover is stunning. The only major change from the first edition is that the photos in this edition aren't on glossy paper. That actually makes for a stronger binding, I believe; but it makes it harder to browse to the pictures, since the picture pages are just like all the other pages.

Anyway... Apollo explains the political history of the program very well. It tells how President Kennedy inherited a space program he really didn't want (though Vice-President Johnsn was a strong supporter), including Project Mercury; and then it tells how, after Soviet space triumphs and the Bay of Pigs debacle, President Kennedy needed a symbol of success. And so he turned to the very space program he once disdained, and said: "What can you give me?" And the managers named a number of conservative, very attainable goals; but none of them was inspiring, and none would demonstrate superiority to the Soviets.

And then they suggested the more extreme goal: "We could go to the Moon." And that grabbed President Kennedy's imagination; and that's what he promised us and the world that we were going to do.

Now from a geopolitical and domestic political position, that proclamation was brilliant: a bold challenge to the Soviets and a bold challenge to the American people. Yet from a technical perspective, it might have proven a horrible misstep. To this day, many in the space travel business will argue that a space station should have been our first goal before the Moon, and that we would have been much farther along in space today if we had followed that course; and indeed, some still pressed for that approach. But with President Kennedy's assassination, Project Apollo took on the mantle of Legacy to a beloved President; and Vice-President Johnson, now succeeded to President, had been NASA's strongest supporter in the Kennedy administration, and was determined to see the Legacy through. That's a combination of historical forces that no one could withstand.

(In a bit of alternate history speculation, I have to wonder what would've happened to Apollo and NASA had President Kennedy lived? Would NASA have persuaded him to let them follow the more cautious approach? Would we have a permanent space colony today, maybe even including settlers on Mars? Or would his attention have lagged as Vietnam and other problems rose? Would a Congress less in awe of his memory have been more willing to cut NASA's funding? Would we even today be waiting for that first footprint on the Moon? I can see a case for either possibility; but we're stuck with the future we have, not the might have beens.)

So Apollo tells of the wrap-up of Project Mercury (the effort to get Americans in orbit), and also of the Gemini program (the effort to learn how to maneuver and work and rendezvous in space); but both are told only briefly and peripherally. As the title suggests, the focus here is all on Apollo. The book is divided into Books:

• Book One, Gathering, tells of the formation of NASA, and of the history of the decision to go to the Moon (as above, only with a lot more history and detail).


• Book Two, Building, tells of the design and construction of the Saturn V, culminating in the story of the first unmanned launch. And along the way, it tells of The Fire. All NASA histories have this in common: there's before The Fire, and after The Fire; and those are two different stories, and even a casual reader can tell. NASA changed in that event. In facing death, NASA had to grow up in some necessary but sad ways. The Can Do people learned that sometimes they couldn't.


• Book Three, Flying, tells the history of the flight controllers in Mission Control, and how they worked with the astronauts during the Apollo missions. And it's here that the real engineering all comes together. As a computer geek, I empathize with these earnest young men glued to their monitors, each watching dozens of simultaneous data points and looking for some key discrepancy that might affect the mission. The book's descriptions of this work are the closest literary equivalent I've ever seen to what it's like to chase down a really ephemeral bug in a mountain of code... except that my bugs usually don't have the lives of three astronauts hanging in the balance... and I usually have more than twenty seconds in which to analyze the data... and I don't have to decide whether to scrub the most-watched mission in history based only on my possibly buggy code... and I don't have to worry about lightning striking my machines and resetting everything right in the middle of the most critical operations... and I don't have to worry about a fuel cell exploding and putting the entire organization into hyper-overdrive. Murray and Cox explore each of these incidents in depth, and they really make me feel the tension of being in the MOCR, making life-and-death decisions based on instinct, experience, and ceaseless drills. They also give what I believe to be the definitive explanations for The Fire and the Apollo 13 accident, as well as a blow-by-blow description of the Apollo 12 lightning strike that made my hair stand on end.

After this, I may go reread Chaikin. I also have EECOM Sy Liebergott's biography (a signed copy picked up at the Cosmosphere) to read. And I may go reread Lost Moon. But this will always be the book that revitalized my childhood love of space travel and made it relevant to me in my career today. For that alone, I would recommend it; but more than that, it's just a fascinating view of Apollo that's usually seen only in the background. That makes it even more valuable to the space fanatic.

Ever have a night when you really need to get up early, and yet things keep you up late, and finally it seems like the safest course is just to stay up? Or does that only happen to me? Either way, this is one of those nights. In five-and-a-half hours, my plane leaves Atlanta. I've been away from Sandy and the dogs and our home for four weeks. I am going to be on that plane. And I already learned this week that this hotel's wake-up calls are still pretty unreliable. And while the M200 has pretty good speakers and usually serves as my alarm clock, it's having some problems right now. (Never buy Toshiba. Toshibas are junk.) And this 3500 has had the speakers repaired, but they pretty much suck, and I can barely hear them. (Never buy Toshiba. Toshibas are junk.)

So at this point, the safe way to be sure I'm on that plane is to stay awake until I board, and then sleep on the plane. So to find things to keep me going, I decided to do something I haven't done in a while. It's time for another installment of Seen around the tech blogs.

--------------------------------------------------------

Richard Hale Shaw makes an interesting argument against the C# using statement (not the using directive; and thank you, C# team, for that bit of confusing language). I disagree with him; but it will take time and sleep before I can fully explain why. The short preview: he says you can't force people to use your class correctly; I say I can, and I'll show you how, soon.

--------------------------------------------------------

Joe Kunk passes along some suggestions on porting MFC code to .NET, including some discussion of tools to automate parts of the port. Since I have a presentation on this topic, I'm going to check out those tools.

--------------------------------------------------------

From the Earth to the Moon links to this discussion of where the Apollo capsules are today. Until it shut down, the Michigan Space and Science Center in Jackson was home to the Apollo 9 capsule. (Commander McDivitt was a Jackson-area native.) I used to go there for inspiration whenever I had a spare afternoon. When I think of what those engineers accomplished at a time where the sum total of all the computers at NASA amounted to less memory than I have in my hand, I realize that no job of mine is that tough. It was a sad day when I learned that MSSC had closed. Now I have to go all the way to San Diego to see Apollo 9. Of course, my flight home tomorrow ends in Dayton (I started this trip with INETA meetings in Cincinatti and Dayton), and Apollo 15 is at the Air Force museum there; and later this year I'll be in Huntsville for another INETA presentation, where Apollo 16 is. So I'll get my fixes then. (Bonus: outside of Dayton and on the road toward home is the Neil Armstrong Museum!)

--------------------------------------------------------

James Avery is looking to switch blog engines, and wishes he had a decent, easy to use and extend .NET solution. I could be wrong, James, but I think it will be really easy to build your own with ASP.NET 2.0.

--------------------------------------------------------

Tablet PC Buzz points out this post by Josh Einstein about fixes that will make Tablet PC components work properly under .NET Framework 2.0. I'm getting a new version of Tablet UML ready, so this was important news to me!

--------------------------------------------------------

Space Law Probe has a round-up of reactions to China's manned space launch.

--------------------------------------------------------

I don't have James Hudnall under Tech Blogs, because I think of him as a comics guy. His Espers is one of my favorite series. But he's also a computer geek. This week, he posted about the latest story on e-paper, and we drooled over the possible comic book applications.

Marvel has released 40 Years Of The Amazing Spider-Man on CD. I haven't picked it up yet, because I'm afraid someone may get it for me as a gift, and I wouldn't want to spoil that. I really would love to read that collection on a Tablet PC (particularly my new Gateway CX200X Tablet PC, to be ordered next week); but a programmable e-paper comic would be equally cool.

(And I hope that Marvel and DC and others release a lot more of their back stock this way.)

--------------------------------------------------------

Mike Swanson shows off the 5 best videos from the PDC. I wish I could've been there, but I was earning the money that will pay for my new Gateway CX200X Tablet PC.

--------------------------------------------------------

Matt Propst announces the Formal Cancellation of Grand Valley Programming Competition. That's too bad, but I hope they can pull it off next year. Josh Holmes and I were asked to be judges. One of my oldest programming memories is high school programming competitions at Grand Valley, so this would've been like going full circle.

--------------------------------------------------------

And speaking of Josh Holmes, he has a couple of posts on his latest work with Compact Framework and Win CE. Josh is my goto guy on this Windows handheld stuff, and he should be yours, too.

--------------------------------------------------------

Sam Gentile posts about a Channel 9 interview with him and Ward Cunningham. Since neither gentleman is shy — especially with their opinions! — it's pretty no-holds-barred.

--------------------------------------------------------

And speaking of Robert Scoble (the guy behind Channel 9), he's on a crusade to get Microsoft to focus on blog searching.

--------------------------------------------------------

Julie Lerman has a 512MB memory chip for a Toshiba Portege M200. Julie, Julie, Julie... Some day you'll learn: never buy Toshiba. Toshibas are junk.

Look at this Gateway CX200X Tablet PC, Julie. Look at the 14" wide-screen. Isn't it... tempting? Look at that optional 4-year, on-site, parts and labor and accidental damage warranty look... comforting?

--------------------------------------------------------

Lora at What Is New posts that the Windows Mobile PC Team (i.e., the Tablet team plus) now has a group blog.

--------------------------------------------------------

And speaking of the Windows Mobile PC Team... This is a little belated note (since I just learned of their blog from Lora): they write of the work their people did in helping to support Hurricane Katrina relief. I've already noted the contributions by Best Buy, WalMart, Home Depot, Edward Jones, McDonald's, and others; so it's only fair that I point out that my favorite software company has pledged over $9 million in cash, materials, and support to the relief effort. Thank you, Microsoft.

--------------------------------------------------------

Howard Lovy has retired NanoBot. That's too bad, but his new job probably keeps him plenty busy.

--------------------------------------------------------

Thom Robbins forwards an announcement of the general availability of the "Project Server Visual Studio Team System Connector" application. "The solution provides guidance for integrating Project Server and Visual Studio Team System. It demonstrates how Project Server and Visual Studio Team System can be integrated together to provide extended value for project and resource managers and guides developers through the process of building and customizing components that link the project management and software development tools. This is a foundation for partners to build applications that can integrate the two server products and provide specialized functionality."

As someone who's more and more excited about process and practices, I'm pleased by this news.

--------------------------------------------------------

James Kendrick — a.k.a. jkOnTheRun — links to this Detroit Free Press story about Bill Gates's visit to Ann Arbor. (Oh, sure, Bill... Come to town when I'm three or four states away! OK, I wouldn't have been invited anyway, since his presentation was for students. But still...) I think the story hints at one reason why I suspect for Microsoft's strong support for the Tablet PC: Bill loves his Tablet, and has wanted one for a long time. You don't believe me? He described his vision of the platform in drooling detail way back in The Road Ahead (or maybe it was Business @ the Speed of Thought — I'm on the road, remember, so I don't have my books with me). There are few people who are more fanatical about Tablet PCs than I am, but Bill's clearly one of them. And so I have a sneaking suspicion that, just as Microsoft will always sell a version of Basic so long as Bill's involved, so too will they make sure that somebody's making new Tablet PCs for Bill to play with.

(NOTE: The above is tongue-in-cheek, and I know nothing about Microsoft's internal platform decisions nor the reasons for those decisions. But I do know that it's true that Bill loves his Tablet PCs.)

--------------------------------------------------------

And speaking of jkOnTheRun... He links to more proof that Toshibas are junk. And he has a plea:

Let’s help Tracy get her Tablet back. Anyone with a Toshiba horror story about repair or customer service difficulties please chime in here with a comment. Let’s see if a string of unsatisfied customers can get Toshiba’s attention about Tracy’s plight. It’s worth a shot as she has nothing to lose since she is already without her precious.

I'm about to throw some links your way, James, as you asked. But at this point, you may already know my conclusion: never buy Toshiba. Toshibas are junk.

--------------------------------------------------------

There! That worked out just about perfectly. I planned to start prepping and packing at 0600, and it's 0553. That gives me just enough time to do a cursory proofread, and then post.

When next you hear from me, I hope to be H*O*M*E! Sandy, I'm on my way!

I write about a lot of stuff on this blog. Mostly, I write about whatever interests me; but clearly, I'm also writing about stuff that's related to my work: UML, Tablet PCs, .NET, and so on. I've had plenty of posts on each of those topics. I've also written on comic books, Persian food, travel, and lots of other topics. And I've written a post or two about Hurrican Katrina relief.

But looking over my referral logs, I find that I could've gotten almost the same traffic with just one post. Depending on the day, anywhere from 13% to up to 20% of recent visitors have come via search engines or Web sites that lead to this post on Borders Rewards vs. the Barnes & Noble Member Program.

I never would've guessed that this would be such a hot topic. I wrote that post just because I was frustrated; and now it's my ninth most-requested page. Too weird...

As an author, it's always nice when someone says they enjoyed your book.

Nice? Heck, it's incredible.

But last night at CMAP, Dr. Osama A. Morad, Ph.D. gave me a compliment I will not soon forget. Upon meeting me, the first thing he said was, "Hello, Martin. I read your book. How's Sandy?" And then he told me how much he appreciated the dedication to my book, reproduced here:

To Dad, for teaching me how to work.
To Mother, for teaching me how to think.
To Sandy, for teaching me how to be me.

I can't speak for other authors, but I worked hard on that dedication, to get it to say exactly what I wanted to say about the three biggest influences in my life. For Dr. Morad to recognize that was really special, and is the nicest of the many nice things that readers have said to me. (He also asked some other good questions about the book, proving that he did indeed get farther than the dedication.)

Sandy's not in my book (computers don't need feeding or walking or grooming, so they don't interest her); but like everything I do, Sandy's all throughout my book. I'm the person I am because she helped me to open up to the world on a personal level. Before I met her, I was a geek. Because I got to know her, I'm a geek who knows how to relate to people and reach out to them and communicate with them a lot better. Growing up, I was an introvert by nature. I still have a self-image of an introvert; but I also know that self-image is inaccurate, because my whole job now is about standing up in front of students and conference attendees and trying to share ideas with them. And an awful lot of that I learned through interacting with her. Sandy is comfortable in many different social situations and groups; and because she drew me into them with her, I became more at ease with them.

That's just one of the many ways Sandy makes me feel somehow more me (if that makes any sense), but it's the one that's most relevant to the book and to my teaching and speaking.

And there's one other way in which Sandy was key to the book: my sample project for the book (and for my UML classes) is an information management system for a high-end pet kennel. Everything I know about pet kennel management comes from Sandy's years in that business.

So I really have to thank Dr. Morad for the kind words, and the chance to acknowledge a little more fully Sandy's role in creating the book.

My buddy Bill Wagner of SRT Solutions has got quite something to be proud of here: a Hungarian edition of his book, Effective C#. Being unable to read so much as a word of Hungarian, I can't vouch for this one. But I highly recommend the English version!

Well, after getting most (but not all) of the needed files onto the backup machine, I had to run to one client, work all day, run home, install more files, fly to Atlanta, and then work-work-work for another client. This project's a bit of a departure for me, but fun: the client wants me to model an existing, pre-UML system for them, so that they can use the model as guidance in transitioning to their next generation system. So I've been immersing myself in a wholely new, unfamiliar problem domain and trying to learn to think like an old hand; and then I've been converting my understanding into UML and communicating that back to the client, so that they can confirm or correct what I've learned. It's all NDA stuff, so I can't share any samples; but it's a great example of why I emphasize UML as a form of communication. I start with only a lay understanding of their problem domain; they start with only a classroom exposure to UML; and in striving to communicate between us, we're growing our understanding in both directions. It's loads of fun!

But that can't take up all of my time, can it? No, but it took up a lot. Then my weekend got derailed by an unfortunate ATM incident (since resolved) that left me planning how to stretch $20 for I wasn't sure how long. So none of the fun stuff I planned to do and blog about took place: no visit to the Bonsai gardens (next trip) and no visit to Borders to get fresh reading material. I just sat in the hotel room and worked on various projects and watched lots of Bond films.

And now it's my last day in Atlanta, and what a day it was! Today, we had our first review meeting, which went better than I dared hope.

Then I drove to Borders, and was delighted to find my book on the shelves. (For all that I'm unimpressed by their discount program, I'm usually pleased to find that Borders carries my book in most outlets.)

And then a little advance scouting had told me that nearby was Fire of Brazil, a Brazilian churrascaria restaurant. That means that the cooks skewer various meats on swords and cook the meat over open flames; and then gauchos bring the meat-laden swords around to the tables. You get a little card, red on one side and green on the other. If you turn it to green, they stop at your table and offer to cut you off a slice of whatever they happen to be carrying. Today I had slices of tenderloin, top sirloin, pork loin, turkey, pork sausages, and so many other meats I can't remember them all. It's not for every day (well, unless you're an Atkins devotee), and it's pricey; but as a treat, it's not to be missed.

And tomorrow, I get to fly home, and get my computer back from the shop, and see my wife and dogs, and then head to Ann Arbor for the 8th annual Duelist. I'll try to post photos.

Well, after getting most (but not all) of the needed files onto the backup machine, I had to run to one client, work all day, run home, install more files, fly to Atlanta, and then work-work-work for another client. This project's a bit of a departure for me, but fun: the client wants me to model an existing, pre-UML system for them, so that they can use the model as guidance in transitioning to their next generation system. So I've been immersing myself in a wholely new, unfamiliar problem domain and trying to learn to think like an old hand; and then I've been converting my understanding into UML and communicating that back to the client, so that they can confirm or correct what I've learned. It's all NDA stuff, so I can't share any samples; but it's a great example of why I emphasize UML as a form of communication. I start with only a lay understanding of their problem domain; they start with only a classroom exposure to UML; and in striving to communicate between us, we're growing our understanding in both directions. It's loads of fun!

But that can't take up all of my time, can it? No, but it took up a lot. Then my weekend got derailed by an unfortunate ATM incident (since resolved) that left me planning how to stretch $20 for I wasn't sure how long. So none of the fun stuff I planned to do and blog about took place: no visit to the Bonsai gardens (next trip) and no visit to Borders to get fresh reading material. I just sat in the hotel room and worked on various projects and watched lots of Bond films.

And now it's my last day in Atlanta, and what a day it was! Today, we had our first review meeting, which went better than I dared hope.

Then I drove to Borders, and was delighted to find my book on the shelves. (For all that I'm unimpressed by their discount program, I'm usually pleased to find that Borders carries my book in most outlets.)

And then a little advance scouting had told me that nearby was Fire of Brazil, a Brazilian churrascaria restaurant. That means that the cooks skewer various meats on swords and cook the meat over open flames; and then gauchos bring the meat-laden swords around to the tables. You get a little card, red on one side and green on the other. If you turn it to green, they stop at your table and offer to cut you off a slice of whatever they happen to be carrying. Today I had slices of tenderloin, top sirloin, pork loin, turkey, pork sausages, and so many other meats I can't remember them all. It's not for every day (well, unless you're an Atkins devotee), and it's pricey; but as a treat, it's not to be missed.

And tomorrow, I get to fly home, and get my computer back from the shop, and see my wife and dogs, and then head to Ann Arbor for the 8th annual Duelist. I'll try to post photos.

This will be the second in a series of posts that will demonstrate simple use of the Unified Modeling Language in the context of a simple project. (Thanks to James Hudnall for the inspiration.) For the first installment, click here.

Objects and Classes

In our last installment, we identified and organized actors, the people and systems with which Your Comic Source will interact. Then I promised that in this installment, we'd identify and organize examples of our second UML concept: domain objects, the information and things that are of interest to the actors and that are affected by the things they do.

Now when I said "objects" above, some of you ran screaming from the room, thinking, "Oh, no, that means object-oriented programming! That's hard!" Well, personally, I think that "objects are hard" is very much old-school thinking. Literally old-school: the object-oriented (OO) approach is a hard transition for programmers who have mastered and adjusted to functional or structured programming. But in my experience, it's actually easier to teach new programmers using OO, because it's a more natural match to how we think and speak about the world.

And when I said "objects" above, others of you shook your heads in disapproval, thinking, "Oh, no, that means object-oriented programming! That means design and code. It's too early for that." There is a tendency to think:

objects = classes = code (Wrong!)

As I argue in my book and in my classes, objects are not just a code construct. Objects are everywhere, becuase they're just things and concepts in the world around us (and thus in the problem domain). Really, the proper formulation is simply this:

objects = nouns (Right!)

Objects are things. The actors and customers and end users are concerned about and work with things. Therefore, actors and customers and end users are concerned about and work with objects. And therefore, objects are an essential part of analysis, not just design and code.

But above, I also mentioned classes. "Aha!" cry the nitpickers. "Now classes are code! And it's too early for code. We told ya so!"

And again, I have to disagree. "Class" is really just another name for "category" or "kind" or "type" (though "type" also has code connotations). It just means a grouping of very similar objects that can be described in similar traits and terms. "Dog" is a class; Betsy, Bluebell, Jake, Radar, and Frosty are particular objects of the class Dog. They differ by many characteristics — breed, sex, height, weight, coat, color, age, and name being the main ones — but they're all Dogs just the same. Meanwhile, Gomer — who has a breed, a sex, a height, a weight, a coat, colors, an age, and a name — is fundametally not a Dog. He's of class Cat. We recognize Dog and Cat as different categories, even though it might be convenient to lump them together in the code.

So while it's true that OO programming languages have a concept called classes, it's not true that classes = code. Classes are a useful part of our analysis model, too. (Insisting that objects = code or classes = code is an example of the That’s Design, Not Analysis antipattern, as I discuss in Requirements Patterns and Antipatterns.)

But categories can themselves be grouped into categories. Or to speak in OO terms, a class can have a base class (or sometimes called a superclass, or a general class, or a parent class, or a number of different synonyms based on the speaker's programming language and habits) that describes common characteristics shared with other classes. For example, Dog and Cat have a base class of Mammal; and it's in Mammal that we describe the characteristics of breed, sex, height, weight, coat, color, age, and name. Because those characteristics are part of Mammal, they are implicitly part of Dog and Cat.

And just as a class can have a base class, it can have multiple subclasses (or sometimes called a derived classes, or a general class, or a child class, or other synonyms) that add more specific characteristics and details. The relationship between base class and subclass is sometimes called "inheritance", because the subclass inherits characteristics from the base class. The relationship is also sometimes called "specialization", because the subclass is a more specialized form of the base class. And in "official" UML parlance, the relationship is called "generalization", because the base class is a more general form of the subclass. (I really must apologize for all these different synonyms. They arose through different branches of OO evolution, and we're just kinda stuck with them. I'll try to consistently use "base class", "subclass", and "inheritance"; but I may slip up from time to time.)

I find that it's usually easier to analyze requirements in terms of classes of objects, not specific objects themselves. So even though I say we're going to identify domain objects, we're really going to look at domain classes more than objects. (I apologize if my terminology is confusing, but it's a habit I find hard to break.)

But what defines a class? Well, UML defines four basic parts to a class:

• Name. This part is obvious: what do we call the class (as distinct from individual objects of the class)?


• Attributes. What are the characteristics that describe objects of the class, and that may help us to distinguish one object from another? In our Dog example above, breed, sex, height, weight, coat, color, age, and name are all attributes.


• Operations. What are the things that all objects of the class can do? In our Dog example, all Dog objects can hunt and play and bark.


• Relations. How do individual objects relate to each other? How does the entire class relate to other objects and classes? A Dog object can have one or more Owner objects (and vice versa, trust me). Inheritance is an example of a relationship between two classes.

Brainstorming About Domain Objects

So now that we're all on the same page regarding domain objects, we can start identifying them. As with actors, if I'm completely new to a problem domain, I won't try to identify a lot of domain objects up front. Instead, I'll go straight to identifying use cases (the subject of our next installment), and then see if any domain objects are discovered through the use cases (as we'll see, possibly in installment 3, possibly installment 4 — I don't have a firm outline yet). I use the use cases partly as an exploratory mechanism, helpng me to explore and learn an unfamiliar domain. (I explain this approach in UML Applied.)

But when you know something about the problem domain, it may be easier to start by brainstorming and listing candidate domain actors. And as I explained in the last installment, I know a fair amount about comic stores! So I'm pretty comfortable in identifying and describing a lot of domain objects. As with the candidate actors from installment 1, this list won't be perfect: I'll miss a lot of domain objects, and I'll list some that we'll end up never needing. But this list is just a starting point for discussion.

So with a little thought, I came up with the domain objects shown in Figure 9:



Figure 9: YCS Domain Objects

The standard UML symbol for an actor is a three-compartment rectangle. The top compartment lists the name, the middle compartment lists the attributes, and the bottom compartment lists the operations. In Figure 9, I also drew some relations between classes, which I'll add to as my domain knowledge evolves.

Note that the domain objects in Figure 9 don't appear in any particular order, as should be expected from brainstorming. These domain objects are described below:

• Action Figure. A plastic, metal, or plush figure, usually of a character from some Comic Book or other Book. Often partly or fully articulated. (Don't ever call them "dolls" if you want to get out of the store without a lecture!)


• Board Game. A Game in which the rules and actions involve moving pieces or counters around a board.


• Book. A single volume publication consisting primarily of text, usually paperback or hardbound.


• CCG. a.k.a. Collectible Card Game.


• Comic Book. A single volume publication consisting primarily of fully illustrated stories (with text as only a secondary element), usually bound in glossy paper or card stock. A single Comic Book may tell all or part of a story.


• Comic Series. A continuing, regularly published series of Comic Books (i.e., numbered "Issues") that involve a common theme, common characters, or common creators.


• Customer. A person who buys Comic Books, Books, Games, or other merchandise at the store. (See below for more discussion of Customer.)


• Customer Order. An Order placed by a Customer to purchase various merchandise.


• Distributor. In most cases, comic stores do not deal directly with individual vendors. Instead, they work Distributors who research and buy from vendors and then solicit orders from the stores.


• Distributor Order. A merchandise order that the store places with the Distributor.


• Employee. This object represents the information that is known about a particular Employee. (See below for more discussion of Employee.)


• Game. A product which allows one or more players to compete against each other or against a set of challenges, all according to a set of rules.


• Game Calendar. A calendar of upcoming Game Events.


• Game Event. A scheduled playing session at which one or more players will play one or more Games.


• Graphic Novel. A single volume publication consisting primarily of fully illustrated stories (with text as only a secondary element), usually bound in hard back or heavy card stock. A single Graphic Novel usually tells one complete story, and usually contains more pages on higher quality paper stock than a typical Comic Book.


• Magazine. A single volume publication consisting primarily of ads, illustrations, stories, articles, and editorials, all of which involve a common theme, common topics, or common creators. Most Magazines are periodicals (with a regular publication schedule), but some are special editions. A magazine is usually bound in and printed on glossy paper.


• Payable Account. An account of funds that the store owes (usually to a vendor, a Distributor, or an Employee).


• Receivable Account. An account of funds that the are owed to the store (usually by a Customer).


• Release Calendar. The schedule of when particular merchandise is expected to arrive in the store.


• RPG. a.k.a. Role Playing Game. A Game in which the rules and actions involve players telling an interactive story in a setting and plot devised by a gamemaster.


• Subscription. A request by a Customer to purchase in advance every issue of a Comic Series or a Magazine.


• Supplement. A Game that does not stand on its own, but rather adds additional rules and options to some other Game.


• Supplies. Merchandise such as counters, dice, comic bags, and other materials which may be used with a Game or Comic Book or other merchandise, but which would usually not be of interest to anyone who hadn't purchased said merchandise (i.e., most people have no use for comic bags unless they buy Comic Books to put in them).


• Time Sheet. A record of the hours an Employee worked.


• Trade Paperback. A single volume publication that collects a number of issues of a Comic Book, usually bound in hard back or heavy card stock. The material contained is not original, but a Trade Paperback is otherwise very much like a Graphic Novel. A single Trade Paperback usually tells one complete story, and usually contains more pages on higher quality paper stock than a typical Comic Book.


• Video Game. A game played by one or more players on a computer or a game console.


• Work Calendar. A schedule of hours to be worked by various Employees.

Note that two of these classes, Customer and Employee, have the same namea as actors from Installment 1. These objects represent the information we know about those actors, not the actors themselves. You may find it confusing that the actors and the classes have the same names. I do, too, honestly, so my usual practice would be to call these "records": Customer Record and Employee Record. But to some people, record = database = design, and they jump back to the That’s Design, Not Analysis antipattern. So when I think that might disturb them, I avoid the phrase "record". In retrospect, I'm feeling that the name confusion is every bit as bad as That’s Design, Not Analysis; so maybe a better choice would be Customer Info and Employee Info. "Info" is such a nice, vague word that no one can really mistake it for a design decision. So I'll switch to those terms as we move forward.

Relating and Organiing Domain Objects

To repeat: the domain objects in Figure 9 appear in a scattershot stream-of-consciousness order, with little thought about how particular domain objects might relate to each other. And just as with the actors in Installment 1, it will be useful to organize the domain objects into packages and also to expand upon the relations between them. So I'll start by subdividing the domain objects into the packages shown in Figure 10:


Figure 10: YCS Domain Object Packages

Accounting Objects

We'll look at each of these packages in more detail below, starting with the easiest: Accounting. This package's contents are shown in Figure 11:


Figure 11: YCS Accounting Objects

In this diagram, I added a new class, Account, to represent characteristics and behavior that are common to both Payable Accounts and Receivable Accounts. I also added two classes found in the Parties package but related to classes in this package: Employee Info and Party (discussed under the Parties package below). I drew these two classes in dark red to make them stand out, as a way to indicate that they're external to this package.

There are two kinds of relationship shown in Figure 11:

• Generalization. As above. Shown with a triangle-headed arrow.


• Association. Shown with a line or arrow, this relationship between two classes indicates that the classes collaborate in some way. You should prefer a line when the two classes interact freely. You should prefer an arrow when one class controls or "owns" the interactions. In Figure 11, for example, there are navigable association from Payables Account and Receivables Account to Party, indicating that the accounts are Paid To or Owed By particular Parties. There is also a simple association between Time Sheet and Employee Info.

(Other types of relations are possible, as we'll see in future installments of Everyday UML.)

Note also that I added specific attributes and operations to some of the classes: an Account has a Balance, and you can Deposit or Withdraw funds (in specific Amounts) or transfer them to another Account; and a Time Sheet indicates the Hours Worked. But I didn't add any attributes or operations to the other classes. In part, this represents that I simply haven't thought through those other classes yet. But it also reflects an important UML practice: not every detail you know appears in every diagram. I called this The Model Rule in UML Applied:

We saw The Model Rule in chapter 1; but it bears repeating. To use UML effectively, you should never be simply drawing pretty pictures; you should always be editing an underlying model, using the pretty pictures as your user interface. Thus, the model should contain more information than is displayed in any one diagram; and information in one diagram should not explicitly contradict information in another diagram. Information that is found in one diagram but not in another should not be considered a contradiction. Rather, this simply indicates that the former diagram displays more detail than the latter. Details may be omitted from a given diagram to make it more comprehensible.

But how do you keep these diagrams consistent with each other? How do you maintain the underlying model? This is where a good modeling tool proves its worth: a good modeling tool will maintain the model as you create and edit your diagrams. If you are not using some sort of modeling tool, this very mechanical burden will fall on you, rather than on the machine. That’s a poor division of labor: brains should do brain work and machines should do mechanical work. If you do the mechanical work, you will do it imprecisely and inefficiently, and you’ll have no time for brain work.

Note the plus sign (+) in front of the attributes and operations in Figure 11. This indicates visibility, a concept which has a lot of design and code implications, but can be summarized pretty simply: the visibility of an attribute or operation indicates where it can be seen and used. Public visibility (+) means an attribute can be read and changed by any part of the system, or an operation can be requested by any part of the system. Private visibility (-) means an attribute can only be read and changed by the class that defines it, or an operation can be requested by the class that defines it. And protected visibility (#) is like private, but the attribute or operation is also visible to all subclasses of the class that defines it. For analysis work, public visibility is the most common, and you shouldn't worry too much about visibility concerns.

Calendar Objects

The contents of the Calendars package are shown in Figure 12:


Figure 12: YCS Calendar Objects

As in Figure 11, Figure 12 indicates an external class (Game) in dark red. I also added attributes to the Game Event class, and I indicated that a Game Calendar contains zero to many (0..*, in UML notation) Game Events.

But the largest addition in Figure 12 is the two added base classes: Schedule and Chronology. These are based on the Chronologies pattern from Requirements Patterns and Antipatterns. Here's a brief excerpt:

Start with an Event class. It should have attributes that describe an event, and that distinguish one event from other similar events. Some of these attributes might include a name, a description, and start and end times for the event. You might also want to indicate whether the event is recurrent (and if so, on what interval) and also whether the event has been completed or not. And you may want your Events to be able to issue notices when they’re due. Event may also be a base class, from which you derive more specific event types. And Event objects may relate to other Event objects. For example, an appointment Event might involve one or more reminder events that remind the user that the appointment will soon occur.

Next, add a class, Chronology, that represents a list of events. It should include operations to add and remove Events. This general class contains Events both past and future. You may also want to add specific Schedule and History subclasses to represent future and past event lists. If you want to maintain both historical and planned events, then your Schedule class should include an operation to complete an Event and move it into a specific History.

Given that excerpt, it makes sense to add an Event base class, modifying Figure 12 to look like Figure 13:


Figure 13: YCS Calendar Objects (Revised)

The change from Figure 12 to Figure 13 is an example of applying a pattern. Again, from Requirements Patterns and Antipatterns:

So putting the two definitions [of "pattern"] together, we see that patterns are a little bit of art and a little bit of science. The science part comes in as three tasks:

• Discovery. Finding some best practice, and recognizing that it is common enough to be worthy of documenting as a pattern.


• Cataloguing. Documenting a number of patterns in detail, including how to recognize them, how to apply them, and even when not to apply them.


• Study. Learning to recognize the patterns, and understanding them well enough that they become part of your nomenclature.

Then the art part comes in when you apply the patterns. You have to learn how to speak in terms of the patterns, how to see where they fit, and how to apply them. It takes a good eye to see the opportunities that patterns create for you; but when you do, they will save you a lot of effort, because they will give you a lot of basic, common, starting ideas without you having to invent those ideas yourself. That will leave your brain free to focus on the aspects that are unique to your problem and your team.

I like to tell students that good patterns let them walk into a new project with some great ideas "in their back pockets", ready to pull out as soon as they see a need. You can apply a lot of established wisdom by building on patterns (where appropriate). We'll see more pattern usage ahead, in both this and future installments.

Party Objects

The contents of the Parties package are shown in Figure 14:


Figure 14: YCS Party Objects

In this package, we see more detail on the Party class that was introduced in Figure 11. This is based on the Party pattern from Martin Fowler, as described in Analysis Patterns : Reusable Object Models. This is a pattern that abstracts out the common characteristics or people and organizations into a base class, Party. A Person, then, is a subclass of Party that represents an individual; and an Organization is a subclass of Party that represents a group of Parties. Person and Organization then serve as base classes for our existing classes: Employee Info, Customer Info, and Distributor Info.

Besides the Party pattern, Figure 14 is also based on the Contact Info minipattern from Requirements Patterns and Antipatterns, in which a single Party can have multiple types of Contact Info, a base class with subclasses that represent different ways a Party might be contacted.

Order Objects

The contents of the Orders package are shown in Figure 15:


Figure 15: YCS Order Objects

I added the base class, Order, as well as a Line Item class to represent items in an order. The Order is placed by a particular Party. (The upper part of the diagram is a simplification of the Orders pattern from Requirements Patterns and Antipatterns.)

I also changed Subscription to be a subclass of Customer Order, one which references a particular Periodical to which the customer subscribes. (The Periodical class is described below.)

Merchandise Objects

The top-level of the Merchandise package are shown in Figure 16:


Figure 16: YCS Merchandise Objects

I added a base class, Merchandise, to represent things sold at YCS. I also added a subclass, Publication, to represent printed Merchandise.

Game Objects

The contents of the Games package are shown in Figure 17:


Figure 17: YCS Game Objects

Publication Objects

The contents of the Publications package are shown in Figure 18:


Figure 18: YCS Publication Objects

I added a Periodical class to represent a scheduled release of issues of some Publication. A Comic Series, then, is a subclass of Periodical; but after a little thought, I decided that a Magazine is also a subclass of Periodical, and it is individual Magazine Issues (a new class) that are published on the schedule.

Note also that I show a new UML relation in Figure 18: dependence, shown as a dashed arrow. While an association (either navigable or not) indicates some structural or functional connection between two classes, dependence indicates a simple "awareness" from one class to another. In Figure 18, we have an association from Periodical to Publication, indicating that a Periodical will consist of some number of Publications. So it would be redundant and even possibly confusing to also have an association from Comic Series to Comic Book, or from Magazine to Magazine Issue. Instead, I redrew those relations as dependence, indicating that a Comic Series "knows about" the Comic Books that make it up, and a Magazine "knows about" its individual issues. (We'll see more about dependence in future installments of Everyday UML.)

Other Merchandise Objects

Although this won't add much of interest, the contents of the Other Merchandise package are shown in Figure 19 for the sake of completeness:


Figure 19: YCS Other Merchandise Objects

What's Next?

In my next installment of Everyday UML, we'll finally get to some use cases. I can't give a schedule for that, so keep your eyes open!

This will be the second in a series of posts that will demonstrate simple use of the Unified Modeling Language in the context of a simple project. (Thanks to James Hudnall for the inspiration.) For the first installment, click here.

Objects and Classes

In our last installment, we identified and organized actors, the people and systems with which Your Comic Source will interact. Then I promised that in this installment, we'd identify and organize examples of our second UML concept: domain objects, the information and things that are of interest to the actors and that are affected by the things they do.

Now when I said "objects" above, some of you ran screaming from the room, thinking, "Oh, no, that means object-oriented programming! That's hard!" Well, personally, I think that "objects are hard" is very much old-school thinking. Literally old-school: the object-oriented (OO) approach is a hard transition for programmers who have mastered and adjusted to functional or structured programming. But in my experience, it's actually easier to teach new programmers using OO, because it's a more natural match to how we think and speak about the world.

And when I said "objects" above, others of you shook your heads in disapproval, thinking, "Oh, no, that means object-oriented programming! That means design and code. It's too early for that." There is a tendency to think:

objects = classes = code (Wrong!)

As I argue in my book and in my classes, objects are not just a code construct. Objects are everywhere, becuase they're just things and concepts in the world around us (and thus in the problem domain). Really, the proper formulation is simply this:

objects = nouns (Right!)

Objects are things. The actors and customers and end users are concerned about and work with things. Therefore, actors and customers and end users are concerned about and work with objects. And therefore, objects are an essential part of analysis, not just design and code.

But above, I also mentioned classes. "Aha!" cry the nitpickers. "Now classes are code! And it's too early for code. We told ya so!"

And again, I have to disagree. "Class" is really just another name for "category" or "kind" or "type" (though "type" also has code connotations). It just means a grouping of very similar objects that can be described in similar traits and terms. "Dog" is a class; Betsy, Bluebell, Jake, Radar, and Frosty are particular objects of the class Dog. They differ by many characteristics — breed, sex, height, weight, coat, color, age, and name being the main ones — but they're all Dogs just the same. Meanwhile, Gomer — who has a breed, a sex, a height, a weight, a coat, colors, an age, and a name — is fundametally not a Dog. He's of class Cat. We recognize Dog and Cat as different categories, even though it might be convenient to lump them together in the code.

So while it's true that OO programming languages have a concept called classes, it's not true that classes = code. Classes are a useful part of our analysis model, too. (Insisting that objects = code or classes = code is an example of the That’s Design, Not Analysis antipattern, as I discuss in Requirements Patterns and Antipatterns.)

But categories can themselves be grouped into categories. Or to speak in OO terms, a class can have a base class (or sometimes called a superclass, or a general class, or a parent class, or a number of different synonyms based on the speaker's programming language and habits) that describes common characteristics shared with other classes. For example, Dog and Cat have a base class of Mammal; and it's in Mammal that we describe the characteristics of breed, sex, height, weight, coat, color, age, and name. Because those characteristics are part of Mammal, they are implicitly part of Dog and Cat.

And just as a class can have a base class, it can have multiple subclasses (or sometimes called a derived classes, or a general class, or a child class, or other synonyms) that add more specific characteristics and details. The relationship between base class and subclass is sometimes called "inheritance", because the subclass inherits characteristics from the base class. The relationship is also sometimes called "specialization", because the subclass is a more specialized form of the base class. And in "official" UML parlance, the relationship is called "generalization", because the base class is a more general form of the subclass. (I really must apologize for all these different synonyms. They arose through different branches of OO evolution, and we're just kinda stuck with them. I'll try to consistently use "base class", "subclass", and "inheritance"; but I may slip up from time to time.)

I find that it's usually easier to analyze requirements in terms of classes of objects, not specific objects themselves. So even though I say we're going to identify domain objects, we're really going to look at domain classes more than objects. (I apologize if my terminology is confusing, but it's a habit I find hard to break.)

But what defines a class? Well, UML defines four basic parts to a class:

• Name. This part is obvious: what do we call the class (as distinct from individual objects of the class)?


• Attributes. What are the characteristics that describe objects of the class, and that may help us to distinguish one object from another? In our Dog example above, breed, sex, height, weight, coat, color, age, and name are all attributes.


• Operations. What are the things that all objects of the class can do? In our Dog example, all Dog objects can hunt and play and bark.


• Relations. How do individual objects relate to each other? How does the entire class relate to other objects and classes? A Dog object can have one or more Owner objects (and vice versa, trust me). Inheritance is an example of a relationship between two classes.

Brainstorming About Domain Objects

So now that we're all on the same page regarding domain objects, we can start identifying them. As with actors, if I'm completely new to a problem domain, I won't try to identify a lot of domain objects up front. Instead, I'll go straight to identifying use cases (the subject of our next installment), and then see if any domain objects are discovered through the use cases (as we'll see, possibly in installment 3, possibly installment 4 — I don't have a firm outline yet). I use the use cases partly as an exploratory mechanism, helpng me to explore and learn an unfamiliar domain. (I explain this approach in UML Applied.)

But when you know something about the problem domain, it may be easier to start by brainstorming and listing candidate domain actors. And as I explained in the last installment, I know a fair amount about comic stores! So I'm pretty comfortable in identifying and describing a lot of domain objects. As with the candidate actors from installment 1, this list won't be perfect: I'll miss a lot of domain objects, and I'll list some that we'll end up never needing. But this list is just a starting point for discussion.

So with a little thought, I came up with the domain objects shown in Figure 9:



Figure 9: YCS Domain Objects

The standard UML symbol for an actor is a three-compartment rectangle. The top compartment lists the name, the middle compartment lists the attributes, and the bottom compartment lists the operations. In Figure 9, I also drew some relations between classes, which I'll add to as my domain knowledge evolves.

Note that the domain objects in Figure 9 don't appear in any particular order, as should be expected from brainstorming. These domain objects are described below:

• Action Figure. A plastic, metal, or plush figure, usually of a character from some Comic Book or other Book. Often partly or fully articulated. (Don't ever call them "dolls" if you want to get out of the store without a lecture!)


• Board Game. A Game in which the rules and actions involve moving pieces or counters around a board.


• Book. A single volume publication consisting primarily of text, usually paperback or hardbound.


• CCG. a.k.a. Collectible Card Game.


• Comic Book. A single volume publication consisting primarily of fully illustrated stories (with text as only a secondary element), usually bound in glossy paper or card stock. A single Comic Book may tell all or part of a story.


• Comic Series. A continuing, regularly published series of Comic Books (i.e., numbered "Issues") that involve a common theme, common characters, or common creators.


• Customer. A person who buys Comic Books, Books, Games, or other merchandise at the store. (See below for more discussion of Customer.)


• Customer Order. An Order placed by a Customer to purchase various merchandise.


• Distributor. In most cases, comic stores do not deal directly with individual vendors. Instead, they work Distributors who research and buy from vendors and then solicit orders from the stores.


• Distributor Order. A merchandise order that the store places with the Distributor.


• Employee. This object represents the information that is known about a particular Employee. (See below for more discussion of Employee.)


• Game. A product which allows one or more players to compete against each other or against a set of challenges, all according to a set of rules.


• Game Calendar. A calendar of upcoming Game Events.


• Game Event. A scheduled playing session at which one or more players will play one or more Games.


• Graphic Novel. A single volume publication consisting primarily of fully illustrated stories (with text as only a secondary element), usually bound in hard back or heavy card stock. A single Graphic Novel usually tells one complete story, and usually contains more pages on higher quality paper stock than a typical Comic Book.


• Magazine. A single volume publication consisting primarily of ads, illustrations, stories, articles, and editorials, all of which involve a common theme, common topics, or common creators. Most Magazines are periodicals (with a regular publication schedule), but some are special editions. A magazine is usually bound in and printed on glossy paper.


• Payable Account. An account of funds that the store owes (usually to a vendor, a Distributor, or an Employee).


• Receivable Account. An account of funds that the are owed to the store (usually by a Customer).


• Release Calendar. The schedule of when particular merchandise is expected to arrive in the store.


• RPG. a.k.a. Role Playing Game. A Game in which the rules and actions involve players telling an interactive story in a setting and plot devised by a gamemaster.


• Subscription. A request by a Customer to purchase in advance every issue of a Comic Series or a Magazine.


• Supplement. A Game that does not stand on its own, but rather adds additional rules and options to some other Game.


• Supplies. Merchandise such as counters, dice, comic bags, and other materials which may be used with a Game or Comic Book or other merchandise, but which would usually not be of interest to anyone who hadn't purchased said merchandise (i.e., most people have no use for comic bags unless they buy Comic Books to put in them).


• Time Sheet. A record of the hours an Employee worked.


• Trade Paperback. A single volume publication that collects a number of issues of a Comic Book, usually bound in hard back or heavy card stock. The material contained is not original, but a Trade Paperback is otherwise very much like a Graphic Novel. A single Trade Paperback usually tells one complete story, and usually contains more pages on higher quality paper stock than a typical Comic Book.


• Video Game. A game played by one or more players on a computer or a game console.


• Work Calendar. A schedule of hours to be worked by various Employees.

Note that two of these classes, Customer and Employee, have the same namea as actors from Installment 1. These objects represent the information we know about those actors, not the actors themselves. You may find it confusing that the actors and the classes have the same names. I do, too, honestly, so my usual practice would be to call these "records": Customer Record and Employee Record. But to some people, record = database = design, and they jump back to the That’s Design, Not Analysis antipattern. So when I think that might disturb them, I avoid the phrase "record". In retrospect, I'm feeling that the name confusion is every bit as bad as That’s Design, Not Analysis; so maybe a better choice would be Customer Info and Employee Info. "Info" is such a nice, vague word that no one can really mistake it for a design decision. So I'll switch to those terms as we move forward.

Relating and Organiing Domain Objects

To repeat: the domain objects in Figure 9 appear in a scattershot stream-of-consciousness order, with little thought about how particular domain objects might relate to each other. And just as with the actors in Installment 1, it will be useful to organize the domain objects into packages and also to expand upon the relations between them. So I'll start by subdividing the domain objects into the packages shown in Figure 10:


Figure 10: YCS Domain Object Packages

Accounting Objects

We'll look at each of these packages in more detail below, starting with the easiest: Accounting. This package's contents are shown in Figure 11:


Figure 11: YCS Accounting Objects

In this diagram, I added a new class, Account, to represent characteristics and behavior that are common to both Payable Accounts and Receivable Accounts. I also added two classes found in the Parties package but related to classes in this package: Employee Info and Party (discussed under the Parties package below). I drew these two classes in dark red to make them stand out, as a way to indicate that they're external to this package.

There are two kinds of relationship shown in Figure 11:

• Generalization. As above. Shown with a triangle-headed arrow.


• Association. Shown with a line or arrow, this relationship between two classes indicates that the classes collaborate in some way. You should prefer a line when the two classes interact freely. You should prefer an arrow when one class controls or "owns" the interactions. In Figure 11, for example, there are navigable association from Payables Account and Receivables Account to Party, indicating that the accounts are Paid To or Owed By particular Parties. There is also a simple association between Time Sheet and Employee Info.

(Other types of relations are possible, as we'll see in future installments of Everyday UML.)

Note also that I added specific attributes and operations to some of the classes: an Account has a Balance, and you can Deposit or Withdraw funds (in specific Amounts) or transfer them to another Account; and a Time Sheet indicates the Hours Worked. But I didn't add any attributes or operations to the other classes. In part, this represents that I simply haven't thought through those other classes yet. But it also reflects an important UML practice: not every detail you know appears in every diagram. I called this The Model Rule in UML Applied:

We saw The Model Rule in chapter 1; but it bears repeating. To use UML effectively, you should never be simply drawing pretty pictures; you should always be editing an underlying model, using the pretty pictures as your user interface. Thus, the model should contain more information than is displayed in any one diagram; and information in one diagram should not explicitly contradict information in another diagram. Information that is found in one diagram but not in another should not be considered a contradiction. Rather, this simply indicates that the former diagram displays more detail than the latter. Details may be omitted from a given diagram to make it more comprehensible.

But how do you keep these diagrams consistent with each other? How do you maintain the underlying model? This is where a good modeling tool proves its worth: a good modeling tool will maintain the model as you create and edit your diagrams. If you are not using some sort of modeling tool, this very mechanical burden will fall on you, rather than on the machine. That’s a poor division of labor: brains should do brain work and machines should do mechanical work. If you do the mechanical work, you will do it imprecisely and inefficiently, and you’ll have no time for brain work.

Note the plus sign (+) in front of the attributes and operations in Figure 11. This indicates visibility, a concept which has a lot of design and code implications, but can be summarized pretty simply: the visibility of an attribute or operation indicates where it can be seen and used. Public visibility (+) means an attribute can be read and changed by any part of the system, or an operation can be requested by any part of the system. Private visibility (-) means an attribute can only be read and changed by the class that defines it, or an operation can be requested by the class that defines it. And protected visibility (#) is like private, but the attribute or operation is also visible to all subclasses of the class that defines it. For analysis work, public visibility is the most common, and you shouldn't worry too much about visibility concerns.

Calendar Objects

The contents of the Calendars package are shown in Figure 12:


Figure 12: YCS Calendar Objects

As in Figure 11, Figure 12 indicates an external class (Game) in dark red. I also added attributes to the Game Event class, and I indicated that a Game Calendar contains zero to many (0..*, in UML notation) Game Events.

But the largest addition in Figure 12 is the two added base classes: Schedule and Chronology. These are based on the Chronologies pattern from Requirements Patterns and Antipatterns. Here's a brief excerpt:

Start with an Event class. It should have attributes that describe an event, and that distinguish one event from other similar events. Some of these attributes might include a name, a description, and start and end times for the event. You might also want to indicate whether the event is recurrent (and if so, on what interval) and also whether the event has been completed or not. And you may want your Events to be able to issue notices when they’re due. Event may also be a base class, from which you derive more specific event types. And Event objects may relate to other Event objects. For example, an appointment Event might involve one or more reminder events that remind the user that the appointment will soon occur.

Next, add a class, Chronology, that represents a list of events. It should include operations to add and remove Events. This general class contains Events both past and future. You may also want to add specific Schedule and History subclasses to represent future and past event lists. If you want to maintain both historical and planned events, then your Schedule class should include an operation to complete an Event and move it into a specific History.

Given that excerpt, it makes sense to add an Event base class, modifying Figure 12 to look like Figure 13:


Figure 13: YCS Calendar Objects (Revised)

The change from Figure 12 to Figure 13 is an example of applying a pattern. Again, from Requirements Patterns and Antipatterns:

So putting the two definitions [of "pattern"] together, we see that patterns are a little bit of art and a little bit of science. The science part comes in as three tasks:

• Discovery. Finding some best practice, and recognizing that it is common enough to be worthy of documenting as a pattern.


• Cataloguing. Documenting a number of patterns in detail, including how to recognize them, how to apply them, and even when not to apply them.


• Study. Learning to recognize the patterns, and understanding them well enough that they become part of your nomenclature.

Then the art part comes in when you apply the patterns. You have to learn how to speak in terms of the patterns, how to see where they fit, and how to apply them. It takes a good eye to see the opportunities that patterns create for you; but when you do, they will save you a lot of effort, because they will give you a lot of basic, common, starting ideas without you having to invent those ideas yourself. That will leave your brain free to focus on the aspects that are unique to your problem and your team.

I like to tell students that good patterns let them walk into a new project with some great ideas "in their back pockets", ready to pull out as soon as they see a need. You can apply a lot of established wisdom by building on patterns (where appropriate). We'll see more pattern usage ahead, in both this and future installments.

Party Objects

The contents of the Parties package are shown in Figure 14:


Figure 14: YCS Party Objects

In this package, we see more detail on the Party class that was introduced in Figure 11. This is based on the Party pattern from Martin Fowler, as described in Analysis Patterns : Reusable Object Models. This is a pattern that abstracts out the common characteristics or people and organizations into a base class, Party. A Person, then, is a subclass of Party that represents an individual; and an Organization is a subclass of Party that represents a group of Parties. Person and Organization then serve as base classes for our existing classes: Employee Info, Customer Info, and Distributor Info.

Besides the Party pattern, Figure 14 is also based on the Contact Info minipattern from Requirements Patterns and Antipatterns, in which a single Party can have multiple types of Contact Info, a base class with subclasses that represent different ways a Party might be contacted.

Order Objects

The contents of the Orders package are shown in Figure 15:


Figure 15: YCS Order Objects

I added the base class, Order, as well as a Line Item class to represent items in an order. The Order is placed by a particular Party. (The upper part of the diagram is a simplification of the Orders pattern from Requirements Patterns and Antipatterns.)

I also changed Subscription to be a subclass of Customer Order, one which references a particular Periodical to which the customer subscribes. (The Periodical class is described below.)

Merchandise Objects

The top-level of the Merchandise package are shown in Figure 16:


Figure 16: YCS Merchandise Objects

I added a base class, Merchandise, to represent things sold at YCS. I also added a subclass, Publication, to represent printed Merchandise.

Game Objects

The contents of the Games package are shown in Figure 17:


Figure 17: YCS Game Objects

Publication Objects

The contents of the Publications package are shown in Figure 18:


Figure 18: YCS Publication Objects

I added a Periodical class to represent a scheduled release of issues of some Publication. A Comic Series, then, is a subclass of Periodical; but after a little thought, I decided that a Magazine is also a subclass of Periodical, and it is individual Magazine Issues (a new class) that are published on the schedule.

Note also that I show a new UML relation in Figure 18: dependence, shown as a dashed arrow. While an association (either navigable or not) indicates some structural or functional connection between two classes, dependence indicates a simple "awareness" from one class to another. In Figure 18, we have an association from Periodical to Publication, indicating that a Periodical will consist of some number of Publications. So it would be redundant and even possibly confusing to also have an association from Comic Series to Comic Book, or from Magazine to Magazine Issue. Instead, I redrew those relations as dependence, indicating that a Comic Series "knows about" the Comic Books that make it up, and a Magazine "knows about" its individual issues. (We'll see more about dependence in future installments of Everyday UML.)

Other Merchandise Objects

Although this won't add much of interest, the contents of the Other Merchandise package are shown in Figure 19 for the sake of completeness:


Figure 19: YCS Other Merchandise Objects

What's Next?

In my next installment of Everyday UML, we'll finally get to some use cases. I can't give a schedule for that, so keep your eyes open!

...or The Best of Discounts, the Worst of Discounts

An open letter to Borders Books:

First, let me make it absolutely clear that I love Borders. I've been shopping at your stores since 1981, back when you only had "store", not "stores". And I still maintain that your original store (now in a new location, of course) has the best selection of computer programming books in any brick-and-mortar store I've ever seen (and as a traveling UML and Tablet PC instructor, I see a lot of book stores — note how cleverly I met my shameless plug quota for this post). For Christmas one year, Mom and Dad gave me a $50 bill and a shove in the direction of Borders (and to show my age, that $50 netted me a grocery bag full of paperback books). I seldom visit Ann Arbor without a Borders visit. I'm a huge fan, despite your complete blindness to any Michigan market west of Ann Arbor (guys, open a Grand Rapids store already — and no, Waldenbooks stores don't count, since they don't have the same selection). And now you've added DVDs to their inventory, easily the best DVD selection I've seen anywhere. And you have TMobile Hotspots in many stores, and I'm a Hotspot member. And your staff has been knowledgeable and helpful, without fail. Heck, you even validate parking in downtown Ann Arbor, which is valuable in itself. I think it's safe to say that I'll always be a Borders customer, with or without a discount program.

Which is good news for you, since your discount program sucks.

To understand why, let's look at a discount program that doesn't suck: the Barnes & Noble Member Program. (And hey, Borders: B&N has six stores on my side of the state, three within 30 miles of my house. Guess who gets more of my money?) Here are the plan details: I pay them $25 per year, and I save 10% on nearly every item online at Barnes & Noble.com and in Barnes & Noble bookstores — including books, CDs, DVDs, bargain books, sale items, and everything in the store Café.

Now this very simple program has one down side: it's not free. But with my buying habits, it pays for itself multiple times over in a year. (OK, I'll be honest: sometimes it pays for itself in a single visit.)

Now here's the Borders program, Border's Rewards: I sign up (for free). Then, when I spend a combined total of $50 or more in one calendar month at Borders, Borders Express, or Waldenbooks, you'll reward me with a Personal Shopping Day. I can redeem that Personal Shopping Day within 30 days after it is issued. On that one day, I'll save 10% on almost everything in your stores, in as many visits and stores as I want. Every calendar quarter, I can earn another Personal Shopping Day. And you gave me one free when I signed up.

But wait, there's more! For each calendar month through October that I spend a combined total of $50 or more, 5% of my qualifying purchases accrue in my Holiday Savings Account. Once that reaches $10, I'll be awarded Holiday Savings in increments of $10 that I can use between November 15, 2005 and January 15, 2006. Also, I'll get exclusive email coupons and special offers. And I can manage my account online.

OK, let's start with the good parts: it's free; it's really easy for me to rack up $50 each month to qaulify for that Personal Shopping Day; and while I haven't tried it yet, the online account management sounds good in principle.

But after that, it's all down hill:

• I have to "qualify" for a discount. I don't just get it. Yes, it's easy for me to qualify, but it means I have to think about it when I'm shopping: "Hey, do I have a Personal Shopping Day or not?" With B&N, I know I'm saving money every time I walk in the door.


• Once I actually qualify for a Personal Shopping Day, I have to use it in 30 days, or it expires. Now that might be less of a problem if you had a store on my side of the state (and don't think I'm done complaining about that). But as it is, I'm pretty sure I've already lost one Personal Shopping Day, simply because I haven't been to Ann Arbor recently. Again, with B&N, my discount never expires, except for the annual renewal. And there, the B&N cashier helpfully reminds me that it has expired when I make my next purchase, offers to renew on the spot, and then immediately applies the discount to that purchase when I inevitably accept. Couldn't be simpler.


• It sounds great that your Personal Shopping Day applies to all visits to all stores on that day; but really, how many people will visit multiple Borders stores or make multiple visits to a single Borders store on a single day? All right, I'll admit it, I've done it. I've even made three visits (with purchases) to two stores in one day. But I've already proven that I'm an addict. The Borders Rewards program had no influence on my shopping that day. So will the casual shopper become a more committed customer due to this "benefit"? I doubt it.


• The Holiday Savings Account is, over all, a pretty good thing. But contrast it with the Suncoast Replay program. Replay isn't free; but they do issue you a reward certificate just for signing up, and those almost make up for the entry fee. And their reward certificates arrive all year long, not just during the holidays. On the whole, I appreciate theirs more, because the rewards show up in the mail more often. Think about it: their customers are pleasantly surprised and reminded of their store all year long; yours are pleasantly surprised only during the hectic holiday season.


• Exclusive email coupons and special offers? Please. You were sending me those (admittedly not as good) before I joined the program. And ya know what? I never, ever, ever remember to print those out and bring them with me. And why should I, honestly? This is the modern age of WiFi. A lot of your customers (me included) have our wireless devices with us; and you already have TMobile infrastructure in many of your stores. So why can't I use the coupons through my computer, somehow? I haven't figured out a good way, yet, but I can't solve all of your problems. Work on it!


• The Borders Rewards program doesn't apply to online purchases through Borders.com, which is actually a partnership with Amazon. Now it may well be that the Amazon pricing is better than the B&N discounted pricing; but it appears like you're taking something away.


• Your cashiers only seem to remind me about the program about 50% of the time. That's important, since I need to qualify for Personal Shopping Days. By contrast, B&N has never forgotten to ask about my card.

And finally, Borders Rewards is just too complicated. Even if by some calculation it's a better deal, people won't be able to follow it. My buddy Bill Heitzeg of Emerald Software, Inc. has done a lot of work with phone rating systems, and knows people who can find me a phone plan that, based on my unique personal calling habits, will give me the lowest possible bill; but the rules I'll have to follow and the hoops I'll have to jump through are more than I can keep straight, so I (and customers like me) go with simple plans from big names like AT&T or SBC. Similarly, the Barnes & Noble plan is just simpler to understand. When plans are complicated, people worry that they're not getting everything they could get, and they suspect the company is pulling a fast one on them. That's not a way to build customer loyalty, which is the whole point of a discount program.

Sorry, guys, but you'll have to go back to the drawing board on this one.

Your loyal customer despite this mistake,

Martin L. Shoemaker

P.S. When are you going to open a Grand Rapids store?

UPDATE: Borders has politely responded to my open letter.

Thank you for contacting Borders Customer Care with your comments.

Feedback from valued customers like you is essential to us as it allows us to keep in touch with areas where we can improve our services. Your suggestion will be included in our regular reporting to our various departments and in information presented to the executives at Borders. While I cannot guarantee that a change will be made, we appreciate your sending us your ideas.

Thanks again for taking the time to write to us. If you should have any other thoughts on how we can improve the shopping experience at Borders stores, please don’t hesitate to share these with us.

Sincerely,

*******
Borders Customer Care
http://www.bordersstores.com

That's fair enough. I don't expect them to change their policies in response to one guy on a blog. I do, however, expect them to listen when customers speak, and think about it. They always have in the past, and they continue to do so now.

Now about that Grand Rapids store...

From The Earth To The Moon reports that Buzz Aldrin has released a children's book on space travel. (They also continue to advertise a deluxe DVD edition of From the Earth to the Moon, the stunning miniseries from Tom Hanks. Drool...)

Dotfuscator and James Avery's book get a mention on Slashdot.

Speaking of books, Bill Wagner reviews Keith Brown's .NET Developer's Guide to Windows Security. "As I said at the top of this review, “The .NET Developer’s Guide to Windows Security” should be required reading for every .NET developer."

And speaking of James Avery, he got asked about blogs and RSS in a job interview this week. Hey, James, I hope that doesn't mean you'll take a new job out of town before I show up next month!

Tablet PC Buzz links to this Channel Insider report on unexpectedly high demands for the new ThinkPads, including the new ThinkPad Tablet PCs. "The ThinkPad Tablet has sold so fast since its introduction that Lenovo quickly ran out of stock and is now working to catch up, he said. The product, intended for vertical markets such as health care, has caught on in the mainstream marketplace, he said."

Howard Lovy takes a hiatus from his blogging hiatus to post outtakes from his Wired story on nanomedicine and cancer. These are parts that were cut for space, but they add nice depth to the overall article. I hope Mr. Lovy finds full-time employment soon, so that he can spare more time for blogging on nanotechnology.

Julie Lerman points out The Regulator, a regular expression testing and learning tool. RegEx has always frustrated me, since it seems to be very powerful yet is incredibly poorly documented. And no one seems to be able to recommend a good book on it. Instead, I hear, "Read chapter such-and-such from that O'Reilly book on SED," or something like that. The Regulator looks like a great help. Thanks, Julie! And thanks, Roy Osherove, for writing it. (Julie also experienced a tornado recently. We have a family friend who was trapped when her house was collapsed by a tornado, and I've had tornado-phobia my whole life. A post like Julie's will give me nightmares tonight. Thanks, Julie...)

Chris from PowerBlogs (my blog service provider; and yes, I'm very pleased with the service) reports that reports are working again. That will be good, because I haven't actually seen reports since I signed up. Now lest you think that's a complaint, I entirely understand the reasons why: Chris was away on his honeymoon; and unlike some people I know, he actually stayed away from tech for the duration. (Actually, judging by the timing, Chris was setting up my account somewhere right in the middle of last-minute wedding stuff.) I look forward to checking out the reports.

Sam Gentile posts on the power of blogs. "So what's the message? An investment in reading quality bloggers every day will increase your knowledge and make you a better Developer/Architect/Marketer, and also your own blog could do wonders for your career and exposure."

me: under a microscope (found via Eric Maino) struggles to balance school and work and like. At that age, I thought it would get so much simpler when I could drop school out of the mix. Sorry to tell ya, bud, but it only got more complicated. Keep working on your balancing skills. They'll serve you well.

Mike Swanson posts on the new WinFX, as well as other new stuff. Mike also bucks the trend in ironic, imaginative, and generally silly blog names, with "Michael Swanson's Blog". I respect that.

hack-a-day links to a robotic drum set that would make Herbie Hancock proud. (And if you don't get the allusion, you must not have spent the early 80s letting MTV rot your brain.)

Thom Robbins points out some new Sharepoint application templates. Some day, I'll understand what that means...

Patrick at The Tablet PC in Teaching & Learning asks about a tool for using Ink in IE. A commenter links to IE Ink 2004, which lets you Ink on any Web page and then save a local copy. I'll have to try that out. Patrick also points out a new Tablet PC commercial from Microsoft, aimed at the education market. This ad almost makes me want to go back to college!


UPDATE AND SHAMELESS PLUG: And And since there's Tablet PC information in this post, Richard Hale Shaw would have my hide if I didn't recommend our new Tablet PC BootCamp.

I just finished reading the latest compilation of Jeph Loeb's Superman/Batman work, Absolute Power.

Wow. Just — wow.

This book isn't for everyone. I would like to think it's something a casual reader could pick up and enjoy, but I just don't believe it. There are too many cameo appearances by minor characters, appearances that won't make much sense unless you've read a small mountain of DC comics, particularly comics from the Silver Age (roughly speaking, the 60s and 70s).

But if you're a Silver Age fan, and especially if you miss alternate timelines and multiple Earths — wow.

This book has a simple premise: a trio of supervillains from the 31st century (Legion fans can guess who) decide that their troubles could all be reversed if they simply went back into the past, abducted the infant Kal El and the orphaned Bruce Wayne, and raised them as super enforcers who would rule the 21st century Earth in the service of their adoptive "parents". But from that simple premise, a wild ride ensues.

With the influence of the Kents and Alfred replaced by a vicious trio that includes a telepath who confounded their brains, Earth's two greatest champions of law and order become tyrants of order over all. As one of the last surviving heroes of what would be the Justice League in a different timeline, Wonder Woman assembles Uncle Sam and the Freedom Fighters (if you don't get the reference, you're kinda proving my point about Silver Age references) to battle Superman and Batman and try to restore the timeline. An accident with a time sphere ensues, and Superman and Batman are blasted into more alternate timelines: the post-Great Disaster world of Kamandi (more stuff from the Silver Age); a Gotham City where Jonah Hex, Cinnamon, Tomahawk, and other western and frontier heroes are modern day law enforcers (yet more Silver Age stuff); an Earth where Darkseid rules, along with the Superman from Kingdom Come and The Kingdom (modern age books, but books that were also tributes to the Silver Age, and that paved the way for this book); and an Earth where Thomas and Martha Wayne were never murdered, and thus Batman was never created, and thus his greatest foe was unopposed in his quest to conquer the Earth.

The story reaches its denouement at one of the iconic symbols of the DC Silver Age, the original Legion clubhouse. And it concludes with a tribute to the book that arguably closed the Silver Age. And when I read that conclusion, my reaction was: wow. Just -- wow. Prior to this, Jeph Loeb was an author whose name I recognized, and I kinda knew he did good work. After this, he's an author I'll search out on the comic racks.

It's hard to describe who the audience for this book is. It's too full of continuity to really make sense to the casual reader; but it also plays too fast and loose with the continuity to please those Continuity Cops who insist on trying to piece every single story into "one seamless tapestry".

Well, actually, there is sort of a description of the audience for this book. It's a one-word description: me.

ZDNet Australia posts this essay on requirements from Psychologist Craig Errey, managing director of PTG Global. The essay is brief, and thus just barely introduces the complexities of requirements analysis; but I recommend every word of it. Particularly these words:

The user interface should no longer be considered a non-functional requirement. The user interface requirements should be given the same standing as functional requirements and conducted in parallel.

There's a strong belief in software that the user interface is not a user requirement, but rather a design/implementation artifact; and I'm happy to see Mr. Errey fighting against this approach. The end users have expectations and requirements when it comes to the user interface. To them, it is a near-tangible thing, right up there with schedules and reports and orders and other domain objects. As I write in my forthcoming Requirements Patterns and Antipatterns:

The customers and end users may expect (and thus require) certain designs. In particular, since the user interface is most of what they understand of the system (see the discussion of the Iceberg Secret under the Prototyping pattern), they may have strong opinions and expectations regarding a particular user interface design. And as we discussed in chapter 1: if the customer expects it, it’s a requirement.

(And for those who recognize the Iceberg Secret in that excerpt: yes, I give full credit for the metaphor to Joel Spolsky, and encourage people to read his essay in its entirety, as well as his whole book. I'm a big Joel fan, even when I think he's wrong.)

An arbitrary line that says the user interface is not a subject for requirements analysis can even be seen as a form of Geek Speak.

The first in a series of excerpts from my next book. This antipattern was mentioned in Everyday UML, Installment 1: Identifying and Organizing Actors.

Anecdote: Programmers Are Weird!

Symptoms: Customers who get frustrated talking to developers who are working as analysts. The jargon and abstraction overwhelms them.

Context: Projects where programmers act as analysts (i.e., programmer-analysts) yet lack training or experience in customer communications. Usually not projects where the customers are also technical personnel.

Motivations:

• Programmers like technology, like to talk about it, and spend much of their time immersed in it. It forms a comfortable language for them, including standards and conventions that simplify and clarify communication.


• 
  
  
  
  

  Programmers further develop writing habits (i.e., coding standards) that help produce more readable and maintainable code. They internalize these habits and tend to use them across the span of development activities. Yet despite programmers’ “comfort level” with these habits, the habits can be completely confusing to regular people.

  Programmers develop writing habits that help produce more readable and maintainable code, but can be completely confusing to regular people.

  
  


• Programmers also like to work in the realm of abstractions: ideal cases and especially common cases that allow programmers to create a solution once and then apply it (with necessary modifications) across a wide range of cases.


• 
  
  
  
  

  Customers and end users tend to work in the world of the concrete: real, distinctive jobs to be done for real, distinctive clients – and with real, distinctive problems and complications and consequences that popup. While they may think about abstract general principles when they need to, their work biases them toward the concrete. Most end users don’t deal with abstractions to the degree that programmers do.

  While customers may think about abstract general principles when they need to, their work biases them toward the concrete.

  
  


• For various reasons – cost, trying to facilitate communication, and simply not knowing any better being chief among them – many development organizations have programmers serving as programmer-analysts, but without training as suggested under the Trained Analysts pattern.

Problem: The problem, I hope, is obvious: programmer jargon can confuse customers and end users. That’s not news to anyone, and it’s a major consideration in many of the patterns in this book. But I want to draw particular attention to two common but confusing programmer habits: coding standards and abstractions.

Programming standards lead programmers to write (and sometimes talk) in odd-but-precise ways that have specific meanings to computers. And beyond that, we (I can be as guilty as anyone) like to show how clever we are by using these odd formulations in non-technical settings. It becomes a form of in-joke: “Let me just access the ICashMachine interface over here so I can instantiate some cash objects.” Our fellow programmers get the joke, laugh, and probably then try to top us. And if regular people took at us funny, shake their heads, and mutter “Geeks,” we take it as a badge of honor. They don’t get the joke, but we do.

And those odd formations really do serve a useful purpose in code; but boy, do they look odd! We stick an “I” in front of anything we “talk” to: IAccount, IBankSystem , ILeasingCompany. And as the examples above show, we like to jam together longStringsOfWordsThatNameSomething, and to use funny capitalization when we do so. And we like to use odd punctuation combinations, such as “==”. “::”, “->”, and “///”.

And believe it or not, every one of those odd usages has a specific and useful meaning. I could teach it to you, even if you’re not a programmer. As a customer, you could learn how to understand it. But why should you have to? Those odd usages are designed to help us to talk to computers, not to people. Just because we geeks can understand them doesn’t mean those habits belong in a requirements discussion. And yet they often end up there. Even when they’re being serious, programmer-analysts who write documents and especially programmer-analysts who create models tend to sprinkle them liberally with coding standards, with their vision of how the code might look. That makes it harder for customers and end users to understand those documents. Since the audience for those documents is people, not computers, that’s just not a smart idea, no matter how compelling it seems to the programmers.

Customers could learn how to understand the arcane jargon of programmers. But why should they have to?

Abstraction is a more insidious problem, because it has some real benefits during analysis as well as some real drawbacks. It’s important for analysts (including programmer-analysts) to identify general principles, commonalities, and other abstractions that can aid their understanding of the problem domain. But it’s also important to realize that customers and end users may not think in those abstractions; and trying to force them to do so may actually hinder communication. It’s all right to introduce an abstraction into the conversation and see if it helps; but you have to be ready to fall back on the concrete if the abstract doesn’t work.

There’s another potential problem with abstractions during analysis: they’re often a sign that you’re designing, not analyzing. When programmer-analysts start seeing possible solution abstractions, they may introduce those into the requirements documents. Not only can this confuse customers and end users, but it can also lead stakeholders to assume that these design concepts are actually requirements (as discussed under the That’s Design, Not Analysis antipattern).

Solution Name: Speak English!

Solution: Fortunately, this is usually a self-correcting problem. Just remind programmer-analysts to rewrite their text or models and to revise their remarks to aim for a general audience. That should be enough to get them to correct themselves.

Remind programmer-analysts to rewrite their text or models and to revise their remarks to aim for a general audience.

In particular, ask programmer-analysts to strip out coding standards wherever they appear, unless the requirement they’re documenting is actually a coding requirement (such as a required interface or protocol or algorithm). And if they’re using abstractions that seem too far from your problem domain for you to understand, ask them to go back to specifics first. From there, ask them to talk you through to explain the benefits and purpose of the abstraction, including how they expect the abstraction will apply across a wide range of cases. And if they can’t do that, then explain to them that the abstraction may be useful as a design concept – and should be documented in their design notes – but is complicating matters when it comes to requirements.

Resulting Context: With a few reminders from customers and end users (and a few jokes at their expense, as needed), programmer-analysts should learn to communicate with a general audience.

Discussion: This antipattern can be a special case of another antipattern: The Department of Obfuscatory Verbiage. And the solution relies heavily on The Echo Effect: stakeholders have to let programmer-analysts know when they have failed to communicate. And the ultimate solution, of course, is Trained Analysts, whether they’re programmers by title or not.

...could write a post that ties together Hollanders, Dr. Laura, Atkins, kids, and Design Patterns.

This part made me laugh:

It's said that Germans make no small mistakes. Since everyone makes mistakes, that should hint at the kind of mistakes that Germans make. And I think Dutch and the Germans are a lot alike. (Being of both Dutch and German ancestry, there's a lot of that in me.)

He may make big mistakes, but I've never seen 'em!

This will be the first in a series of posts that will demonstrate simple use of the Unified Modeling Language in the context of a simple project. (Thanks to James Hudnall for the inspiration.)

What the Heck is UML?

For those who are new to the Unified Modeling Language (or UML), here's a very brief introduction. UML is essentially a set of blueprinting notations for various aspects of system design, with an emphasis on communication to customers, end users, and other developers. Sadly, a lot of software isn’t really designed in the traditional sense. If I gave you a pile of nails and lumber, I’ll bet you could build a decent doghouse by eye. You might build a decent house, but you’d probably want to draw a sketch, at least; and I’ll bet you’d never pass inspection without that sketch, whether you needed it or not. And if you tried to build a skyscraper without detailed plans, you’d never get it off the ground without it collapsing; and government types would shut you down before somebody got hurt. (Thanks to Steve McConnell for the analogy.)

Well, a lot of software is built with doghouse methods, even if it’s a skyscraper project. UML is an industry-standard set of diagram types and modeling syntax that help you draw the plans. It's a standard maintained by the Object Management Group. It won't solve all your problems, but it's a useful tool to help you progress from doghouses to skyscrapers.

Defining the Model

Before you begin modeling, it's always a good idea to identify the purpose of the model. That will help you to know the scope of your model and to thus limit and focus your work.

For this stage of Everyday UML, our model will be defined as follows:

This is a model of operations for Your Comic Source, a full-service comic and game store with both storefront and online sales and events.

Note that this model is described as a model of operations for the comic store. That implies that this is a business model, focused on the operations of the business as a whole, not just on the operations of the software. Remember my message from UML Applied and UML BootCamp:

UML is not about software design; it's about system design, where a system is structure with behavior and goals. And software is certainly one kind of system, but it's not the only kind.

And in this particular set of examples, the system will be the entirety of Your Comic Source.

A business model is only one kind of model you might construct with UML. We'll see other kinds of models in future installments of Everyday UML.

Brainstorming About Actors

It's time to introduce our first UML concept: actors. No, we're not talking John Cusack or Marisa Tomei here. In UML, an actor represents a person or system or event with which your system interacts. It's the things outside your system that either ask your system to do things, or that do things for your system, or both.

If I'm completely new to a problem domain, I'll start with a single actor, Customer, use that as a probe for finding use cases and then participating actors, and then use those actors to probe for more use cases and more participating actors, and so on. (I explain this approach in UML Applied.) But when you know something about the problem domain, it may be easier to start by brainstorming and listing candidate actors. This list won't be perfect: you'll miss some actors, and you'll list some that you'll end up never needing. But remember another lesson from UML Applied:

Don’t worry about being perfect all at once (or ever!). If you’re communicating, you’re using UML effectively. There’s always room for improvement; but don’t let imperfection stop you from progress. That’s a key point in learning UML and in applying UML as part of a process. Your designs will not be perfect; but as your team reviews them and you refine them, they will become good enough: good enough to build the system, good enough to guide the testing and the documentation, good enough to drive the management of the process. A team that waits for perfection is just as bad as a team that is wedded to code-and-fix: neither team produces an effective design that leads to a successful system. Remember: code-and-fix bad; design-and-fix good.

One look at my bookshelves should serve as proof that I've spent a lot of time in comic stores. So I felt pretty comfortable in modeling actors for Your Comic Source (a.k.a. YCS) as shown in Figure 1:




Figure 1: YCS Actors


The standard UML symbol for an actor is a stick figure (whether the actor represents a person or not.) Note that these actors don't appear in any particular order, as should be expected from brainstorming. These actors are described below:

• Bank System. A computer system at the bank. The YCS system will collaborate with this system for payments and other transactions.
  
• Browser. Someone who visits the YCS Web site but who isn't yet a Member.
  
• Customer. Someone who purchases comics or games at YCS, either in person or online.
  
• Gamemaster. This is a person who arranges and runs game events for Gamers.
  
• Gamer. A person who plays games at the YCS store. (Games stores often have space for regularly scheduled games, as a way to expand interest in those games and sell more products.)
  
• Manager. The person in charge of day-to-day operations at YCS.
  
• Member. This is a Web site visitor who has moved beyond Browser status by creating an account and identifying interests. When comics or games of interest to that Member are released, YCS will send out email notices. Members will also qualify for special discounts and deals.
  
• Publisher. A person or company who publishes comics for sale at YCS.
  
• Special Guest. An artist, writer, game designer, publisher, or other individual who will visit YCS for a special event such as a book signing or a talk.
  
• Staffer. Someone who works the shelves or the counter at YCS.
  
• Store Owner. The owner of YCS.
  
• Subscriber. Someone who signs up for and purchases particular comic books in advance, and whose books are then delivered automatically (either in person or via delivery service).
  
• Vendor. This actor represents a person or company that sells or distibutes or consigns products for sale by YCS. (Definitions: Sells = "YCS purchases the item directly. All future profits or losses accrue solely to YCS." Distributes = "YCS stocks the item, but does not purchase it. Upon sale, proceeds are split between distributer and YCS. After a period of time, YCS may return unsold items." Consigns = "Similar to distribution, but a one-time arrangement between YCS and a private individual.")
  
• Vendor System. A computer system owned or run by a Vendor. It will work with the YCS system to transact business.
  

Remember a key rule in regard to actors: an actor represents a role that individuals or systems may play, not any specific individual and not any specific job title. One person or system may fill multiple different actor roles at different times, and a single actor role may be filled by different people or systems at different times. For example, the owner of YCS may fill the Store Owner role primarily, but may also act as a Manager or even a Staffer from time to time.

Relating Actors

To repeat: the actors in Figure 1 appear in a scattershot stream-of-consciousness order, with no real thought about how particular actors might relate to each other. But actually, there's a lot of things we know about these actors already. Next we want to capture that knowledge. Some of these things are shown in Figure 2:



Figure s: YCS Actors (Reorganized)


There are two kinds of relationship shown here:

• Generalization. Sometimes also called specialization, inheritance, or subclassing. Shown with a triangle-headed arrow, this relationship between two actors indicates that one actor is a special case or special kind of another actor (the one to which the arrow points). For instance, Figure 2 says that a Publisher is a special kind of Vendor.
  
• Association. Shown with a line or arrow, this relationship between two actors indicates that the actors collaborate in some way. You should prefer a line when the two actors interact freely. You should prefer an arrow when one actor controls or "owns" the interactions. (We call this a "navigable association", perhaps because the UML standards committee is fond of multisyllables). In Figure 2, for example, there is a navigable association from Manager to Employee, indicating that a Manager has Employees that work for him or her. Note also that the association includes a measure of multiplicity on the Employee end (where it reads "0..*"). Multiplicity indicates how many actors of a given type are involved in the relationship. "*" indicates an unspecified number; so 0..* in our example means that a Manager might have any number of Employees (including 0 — maybe they all got fired?).
  

(Other types of relations are possible, as we'll see in future installments of Everyday UML.)

Note also that I added some new actors into Figure 2. These actors represent common behavior shared by a number of different actors, and let us describe the common behavior in a common way. This is an abstraction, and can be useful. But you have to be careful: too much abstraction too early can confuse your audience. (For more on this topic, see item 64: Geek Speak from my upcoming book, Requirements Patterns and Antipatterns: Best (and Worst) Practices for Defining Your Requirements, coming soon from Addison-Wesley.) These additional actors are:

• User. This actor represents behavior common to all users of the YCS Web site. (This is a simplified version of item 56: Extended Inverted Org Chart from Requirements Patterns and Antipatterns.)
  
• Authorized User. This actor represents users who have some level of privileges within the YCS Web site, such as editing their personal preferences, etc. (This is another element of Extended Inverted Org Chart.)
  
• Employee. This actor represents common behavior for all persons employed by YCS. (This is a simplified version of item 55: Inverted Org Chart from Requirements Patterns and Antipatterns.)
  

Organizing Actors

Notice how I drew lines around groups of actors in Figure 2, dividing them into groups by relations. That suggests better ways to organize the actors. But to organize them, I first need to introduce UML packages. A Package is simply a hierarchical subdivision of a model. It functions very much like a folder on your hard drive, letting you organize a large collection of things into smaller, more comprehensible collections of related things. The icon for a UML package even looks like a file folder, just like a folder on your hard drive.

Looking at Figure 2, it seems natural to me that we should organize the actors into the packages shown in Figure 3:




Figure 3: YCS Actor Packages


This is a stripped down version of item 48: Actor Hierarchy from Requirements Patterns and Antipatterns. The Human Actors package is split into two subpackages, as in Figure 4:




Figure 4: YCS Human Actors


The Users package models the various kinds of users, as in Figure 5:




Figure 5: YCS Users


The Customers package models the various kinds of customers, as in Figure 6:




Figure 6: YCS Customers


And finally, the Systems package shows systems with which YCS must interact, as in Figure 7:




Figure 7: Systems that Collaborate with YCS

Organizing Your Model

Well, that's enough about actors for now. This installment is already a lot longer than I intended. But there's one more topic I want to cover: where these actors fit in the larger model that we're creating. There are a lot of ways that you can organize a model. I like to use an organization scheme as shown in Figure 8:




Figure 8: Organizing Your Requirements


The Actors package contains all the work we've seen in this installment. The Domain Objects package will contain details on things and types of things of interest to the actors of YCS. The Use Cases package will show Use Cases: the operations that actors perform within YCS, including the business rules that apply to those operations. And the Architecture package will show software systems and interfaces that will support the use cases.

What's Next?

In my next installment of Everyday UML, we'll look at some domain objects. I can't give a schedule for that, so keep your eyes open!

This will be the first in a series of posts that will demonstrate simple use of the Unified Modeling Language in the context of a simple project. (Thanks to James Hudnall for the inspiration.)

What the Heck is UML?

For those who are new to the Unified Modeling Language (or UML), here's a very brief introduction. UML is essentially a set of blueprinting notations for various aspects of system design, with an emphasis on communication to customers, end users, and other developers. Sadly, a lot of software isn’t really designed in the traditional sense. If I gave you a pile of nails and lumber, I’ll bet you could build a decent doghouse by eye. You might build a decent house, but you’d probably want to draw a sketch, at least; and I’ll bet you’d never pass inspection without that sketch, whether you needed it or not. And if you tried to build a skyscraper without detailed plans, you’d never get it off the ground without it collapsing; and government types would shut you down before somebody got hurt. (Thanks to Steve McConnell for the analogy.)

Well, a lot of software is built with doghouse methods, even if it’s a skyscraper project. UML is an industry-standard set of diagram types and modeling syntax that help you draw the plans. It's a standard maintained by the Object Management Group. It won't solve all your problems, but it's a useful tool to help you progress from doghouses to skyscrapers.

Defining the Model

Before you begin modeling, it's always a good idea to identify the purpose of the model. That will help you to know the scope of your model and to thus limit and focus your work.

For this stage of Everyday UML, our model will be defined as follows:

This is a model of operations for Your Comic Source, a full-service comic and game store with both storefront and online sales and events.

Note that this model is described as a model of operations for the comic store. That implies that this is a business model, focused on the operations of the business as a whole, not just on the operations of the software. Remember my message from UML Applied and UML BootCamp:

UML is not about software design; it's about system design, where a system is structure with behavior and goals. And software is certainly one kind of system, but it's not the only kind.

And in this particular set of examples, the system will be the entirety of Your Comic Source.

A business model is only one kind of model you might construct with UML. We'll see other kinds of models in future installments of Everyday UML.

Brainstorming About Actors

It's time to introduce our first UML concept: actors. No, we're not talking John Cusack or Marisa Tomei here. In UML, an actor represents a person or system or event with which your system interacts. It's the things outside your system that either ask your system to do things, or that do things for your system, or both.

If I'm completely new to a problem domain, I'll start with a single actor, Customer, use that as a probe for finding use cases and then participating actors, and then use those actors to probe for more use cases and more participating actors, and so on. (I explain this approach in UML Applied.) But when you know something about the problem domain, it may be easier to start by brainstorming and listing candidate actors. This list won't be perfect: you'll miss some actors, and you'll list some that you'll end up never needing. But remember another lesson from UML Applied:

Don’t worry about being perfect all at once (or ever!). If you’re communicating, you’re using UML effectively. There’s always room for improvement; but don’t let imperfection stop you from progress. That’s a key point in learning UML and in applying UML as part of a process. Your designs will not be perfect; but as your team reviews them and you refine them, they will become good enough: good enough to build the system, good enough to guide the testing and the documentation, good enough to drive the management of the process. A team that waits for perfection is just as bad as a team that is wedded to code-and-fix: neither team produces an effective design that leads to a successful system. Remember: code-and-fix bad; design-and-fix good.

One look at my bookshelves should serve as proof that I've spent a lot of time in comic stores. So I felt pretty comfortable in modeling actors for Your Comic Source (a.k.a. YCS) as shown in Figure 1:




Figure 1: YCS Actors


The standard UML symbol for an actor is a stick figure (whether the actor represents a person or not.) Note that these actors don't appear in any particular order, as should be expected from brainstorming. These actors are described below:

• Bank System. A computer system at the bank. The YCS system will collaborate with this system for payments and other transactions.
  
• Browser. Someone who visits the YCS Web site but who isn't yet a Member.
  
• Customer. Someone who purchases comics or games at YCS, either in person or online.
  
• Gamemaster. This is a person who arranges and runs game events for Gamers.
  
• Gamer. A person who plays games at the YCS store. (Games stores often have space for regularly scheduled games, as a way to expand interest in those games and sell more products.)
  
• Manager. The person in charge of day-to-day operations at YCS.
  
• Member. This is a Web site visitor who has moved beyond Browser status by creating an account and identifying interests. When comics or games of interest to that Member are released, YCS will send out email notices. Members will also qualify for special discounts and deals.
  
• Publisher. A person or company who publishes comics for sale at YCS.
  
• Special Guest. An artist, writer, game designer, publisher, or other individual who will visit YCS for a special event such as a book signing or a talk.
  
• Staffer. Someone who works the shelves or the counter at YCS.
  
• Store Owner. The owner of YCS.
  
• Subscriber. Someone who signs up for and purchases particular comic books in advance, and whose books are then delivered automatically (either in person or via delivery service).
  
• Vendor. This actor represents a person or company that sells or distibutes or consigns products for sale by YCS. (Definitions: Sells = "YCS purchases the item directly. All future profits or losses accrue solely to YCS." Distributes = "YCS stocks the item, but does not purchase it. Upon sale, proceeds are split between distributer and YCS. After a period of time, YCS may return unsold items." Consigns = "Similar to distribution, but a one-time arrangement between YCS and a private individual.")
  
• Vendor System. A computer system owned or run by a Vendor. It will work with the YCS system to transact business.
  

Remember a key rule in regard to actors: an actor represents a role that individuals or systems may play, not any specific individual and not any specific job title. One person or system may fill multiple different actor roles at different times, and a single actor role may be filled by different people or systems at different times. For example, the owner of YCS may fill the Store Owner role primarily, but may also act as a Manager or even a Staffer from time to time.

Relating Actors

To repeat: the actors in Figure 1 appear in a scattershot stream-of-consciousness order, with no real thought about how particular actors might relate to each other. But actually, there's a lot of things we know about these actors already. Next we want to capture that knowledge. Some of these things are shown in Figure 2:



Figure s: YCS Actors (Reorganized)


There are two kinds of relationship shown here:

• Generalization. Sometimes also called specialization, inheritance, or subclassing. Shown with a triangle-headed arrow, this relationship between two actors indicates that one actor is a special case or special kind of another actor (the one to which the arrow points). For instance, Figure 2 says that a Publisher is a special kind of Vendor.
  
• Association. Shown with a line or arrow, this relationship between two actors indicates that the actors collaborate in some way. You should prefer a line when the two actors interact freely. You should prefer an arrow when one actor controls or "owns" the interactions. (We call this a "navigable association", perhaps because the UML standards committee is fond of multisyllables). In Figure 2, for example, there is a navigable association from Manager to Employee, indicating that a Manager has Employees that work for him or her. Note also that the association includes a measure of multiplicity on the Employee end (where it reads "0..*"). Multiplicity indicates how many actors of a given type are involved in the relationship. "*" indicates an unspecified number; so 0..* in our example means that a Manager might have any number of Employees (including 0 — maybe they all got fired?).
  

(Other types of relations are possible, as we'll see in future installments of Everyday UML.)

Note also that I added some new actors into Figure 2. These actors represent common behavior shared by a number of different actors, and let us describe the common behavior in a common way. This is an abstraction, and can be useful. But you have to be careful: too much abstraction too early can confuse your audience. (For more on this topic, see item 64: Geek Speak from my upcoming book, Requirements Patterns and Antipatterns: Best (and Worst) Practices for Defining Your Requirements, coming soon from Addison-Wesley.) These additional actors are:

• User. This actor represents behavior common to all users of the YCS Web site. (This is a simplified version of item 56: Extended Inverted Org Chart from Requirements Patterns and Antipatterns.)
  
• Authorized User. This actor represents users who have some level of privileges within the YCS Web site, such as editing their personal preferences, etc. (This is another element of Extended Inverted Org Chart.)
  
• Employee. This actor represents common behavior for all persons employed by YCS. (This is a simplified version of item 55: Inverted Org Chart from Requirements Patterns and Antipatterns.)
  

Organizing Actors

Notice how I drew lines around groups of actors in Figure 2, dividing them into groups by relations. That suggests better ways to organize the actors. But to organize them, I first need to introduce UML packages. A Package is simply a hierarchical subdivision of a model. It functions very much like a folder on your hard drive, letting you organize a large collection of things into smaller, more comprehensible collections of related things. The icon for a UML package even looks like a file folder, just like a folder on your hard drive.

Looking at Figure 2, it seems natural to me that we should organize the actors into the packages shown in Figure 3:




Figure 3: YCS Actor Packages


This is a stripped down version of item 48: Actor Hierarchy from Requirements Patterns and Antipatterns. The Human Actors package is split into two subpackages, as in Figure 4:




Figure 4: YCS Human Actors


The Users package models the various kinds of users, as in Figure 5:




Figure 5: YCS Users


The Customers package models the various kinds of customers, as in Figure 6:




Figure 6: YCS Customers


And finally, the Systems package shows systems with which YCS must interact, as in Figure 7:




Figure 7: Systems that Collaborate with YCS

Organizing Your Model

Well, that's enough about actors for now. This installment is already a lot longer than I intended. But there's one more topic I want to cover: where these actors fit in the larger model that we're creating. There are a lot of ways that you can organize a model. I like to use an organization scheme as shown in Figure 8:




Figure 8: Organizing Your Requirements


The Actors package contains all the work we've seen in this installment. The Domain Objects package will contain details on things and types of things of interest to the actors of YCS. The Use Cases package will show Use Cases: the operations that actors perform within YCS, including the business rules that apply to those operations. And the Architecture package will show software systems and interfaces that will support the use cases.

What's Next?

In my next installment of Everyday UML, we'll look at some domain objects. I can't give a schedule for that, so keep your eyes open!