Having looked at how we can use derived and conditional expressions in our class diagrams, we are now ready to consider a construct so powerful that I shudder to think of what could happen if Iran, North Korea, or Microsoft should get hold of it. In fact, I’m taking a huge risk in revealing it here today. If this is my last post, it’s a good bet that I’m in the hands of foreign agents trying to force me into assisting with a diabolical plot involving germs, radiation, and Tomcat 5.5.

Yes, today you are ready to learn about (cue some suitably momentous music) query expressions! Wait! Where are you going? Come back. I’m tellin’ ya. Query expressions are some serious mojo!

Let us feel their power together by returning again to our consideration of the Arms4Less online superstore (”where you don’t need to spend a lot to destroy a lot”). Sarge explains to us that they don’t sell to just anybody. “For the really good stuff, you gotta be somebody we trust — either somebody we know, or a friend of at least two people we know.” We easily capture this notion of who’s trusted as follows.

We add a Customer entity with an association, friends, referencing customers who are a customer’s friends. We give Customer a boolean attribute, isSomebodyWeKnow, and as well as a derived attribute, isTrusted. The value of isTrusted is derived from the expression:

isSomebodyWeKnow or #friends[isSomebodyWeKnow] >= 2

The []-brackets enclose a selection expression. friends[isSomebodyWeKnow] selects all of the friends of some customer where isSomebodyWeKnow is true. The #-sign is a shorthand for “count”. So, we can see that isTrusted will evaluate to true if the customer is somebody we know or if they have at least 2 friends we know.

When next we meet, we’ll delve into the notion of query expressions more fully. In the meantime, beware of North Koreans toting pirated UML editors….

Stu Stern

Let’s consider some other amusing things we can do with class diagrams. With a little tape, some string, and a pair of scissors, we can of course convert most class diagrams into a ceremonial tribal mask or a pirate hat. Another fun thing we can do is derive attribute values using conditional expressions.

Let’s return to our example of the Arms4Less online superstore. We’re having lunch with our SME, Sarge, and he’s just finished telling us a funny story about a coup he helped stage a few years back. “So Johnny turns to me and says, whadaya mean, where’s the king? Who do we got tied up in the back of your car?” We laugh appreciatively, and then turn the conversation back to the requirements for the store. Sarge explains how they want to offer various sales incentives, “like 20% off for quantities over 50″. We can easily modify our model to reflect this requirement, by adding a new derived attribute called discount to OrderItem, and then modifying the derivation expression on total to reflect any discounting to be applied. We must also add the necessary non-derived attributes, discountQty and discount, to the Product, as shown.

Hopefully, you are beginning to see how much more you could be getting out of your class diagrams if you would just spend a little more time drawing pictures and a little less time writing code. I know how that can be tough with all the pressure you’re getting from religious eXtremists, but as we shall soon see, Precision Requirements Modeling fits very nicely into an Agile approach that even the religious right can love.

In our next installment we’ll really get this party started when we consider how to derive values from query expressions. I know the anticipation will be killing you between now and then, and I’d love to show you right now, but I gotta go write some code.

Stu Stern

In my last post, I promised to reveal how class diagrams can be your secret weapon in the war against imprecise requirements. How can this be, you wonder? Sure, class diagrams capture entities, attributes, and associations, but they’re completely incapable of expressing the hopes, fears, aspirations and unwarranted hostility of my end users. Surely we need all the subtlety and nuance of natural language to fully capture the essence of what we’re being required to build? Surely we need to capture requirements using the flowing prose of use cases?

As we’ve discussed, precision is certainly something to be aspired to in requirements specifications, and yet, the legal profession provides compelling testimony to the horrible things that happen to beautiful prose when we impose precision upon it. Let’s begin to consider some other things we can express clearly, unambiguously, and some might say beautifully, via everybody’s favorite UML diagram.

Suppose we’ve been asked to build an online storefront offering stolen military hardware at low-low prices. The company, Arms4Less, was founded by several retired mercenaries now holed up somewhere in Honduras. Our primary contact is this crusty old guy we know only as “Sarge”. The first thing he says the system needs to do is “store orders for stuff.”

“You know”, he says, “we sell stuff. Hand grenades, bazookas, napalm cannisters, that kinda thing. We’ll need the usual shopping cart deal, letting customers tell us how much of each product they want.” We sketch out the diagram below.

As you would expect, an Order consists of 1 or more (1..*) items, and each OrderItem specifies the quantity of some product being ordered. Each Product has a price. Now, hopefully you’re regarding this model and saying, “Yeah? So? Why am I wasting time reading this stupid guy’s blog when I could be learning Spring?” In a moment we’ll make this model a lot more interesting. The diamond, by the way, signifies a “composite” relationship between an Order and its items, which essentially means that if we delete an Order, all of its items will get deleted too. (You would of course know what the diamond means if you’d been paying attention instead of doing email in that UML course your boss sent you to.) If the other symbols being used here are mysterious to you, go hang out with Ambler and come back when you’re done.

A tremendously useful, but largely underused (Ambler’s overview doesn’t even mention them), facility of class diagrams is the specification of “derived” attributes. Derived attribute values are - uh - derived. That is, their values don’t need to be stored since they can be completely determined from other data values. For example, Sarge explains that we need to total up each order and make the customer’s got enough dough to cover it. “We do this for the customer’s own protection”, Sarge explains. “You don’t wanna know what’s gotta happen if the guy can’t pay us.” And indeed, we really don’t wanna know until a later iteration. So, we add 2 derived attributes to the model to deal with the order total.

We’ve added a total attribute to both the Order and the OrderItem entities. Note that each has a leading slash, which means “derived” in UML. The OrderLine total is, not surprisingly, derived by multiplying the quantity by the price of the associated product (quantity*product.price). The Order total is the sum of the totals of its items (sum(items.total)). We mentioned earlier that derived attributes don’t need to be stored, and indeed you can see how we can simply calculate these attributes’ values on the fly. Certainly, however, there are situations in which we store derived attributes if, for example, they’re too expensive to calculate dynamically. Such a decision however is purely an implementation choice. Logically, these attributes are derived.  This is all about what the system must do, not how it will do it. So let’s keep our functional requirements logical. As Sarge might say, “You don’t wanna get physical with me unless you’re good and ready, computer boy.”

Now, you’re probably still a little underwhelmed by all this. But as we’ll see in our next episode, we’ve only just scratched the surface of the expressive power of the friendly, little class diagram.

Stu Stern