Modeling States for Business People

In a model intended for business people I prefer to model states as subclasses. Some say this is not a good idea, but I'm going to give you what I think are some pretty compelling reasons for why it is.

Modeling states as an enumeration is pretty standard, so I don't think I need to go into the details here. What I do want to go into is how subclasses are very similar, yet have more benefits.

UML 1.x generalizations used to have a "discriminator", which was a value (string, integer, enumeration, or whatever) to represent each subclass. Every subclass had its own discriminator value, which made the discriminator look an awful lot like an enumeration. (Discriminators have now morphed into a similar but more complex notion of "powertypes" in UML 2.)

A subclass per state specifies the equivalent of enumeration literals while also specifying which states should have additional properties and constraints. There are many cases where a thing in a state has different properties than that thing in a different state. For example, an Unfilled Customer Order should not have a shipment tracking number, but a Filled Customer Order should have one. Reifying these states as sub-classifications allows us to capture this business rule.

Without subclasses, all we could capture is two unrelated facts, as an enumeration (filled and unfilled) and an optional shipment tracking number. Business people naturally understand the sub-classification in a concept model without explanation because it is how they think. (We could also use OCL, but it is just not natural for them.)

It's not necessary for every one of these subclasses to have different properties, which means we can generalize and say that states can be represented as subclasses.

UML allows a lot more flexibility with generalization sets than most programming languages and databases naturally support, so many technical people react with "you can't do that!" Well, the business people naturally understand such high-level models without explanation, especially when I run the model through my über glossary generator that describes the generalization sets in plain, structured English.

Why can't business people have the classifications they envision directly in their models? One should be able to transform a model for business people (without technology limitations) into a target technology (perhaps with technology limitations). In fact, I can use the MDS ModelPro tool (also part of NoMagic's Cameo SOA+ plugin) to transform these models into Java, XSD, and DDL. These models work well for both business people and computers.

So, the reasons for using subclasses to represent states are that you can tie together unrelated facts with business rules, present models to business people that reflect how they think, and still be able to transform these models into technology artifacts.