OOA/D with UML and OO Patterns – Conceptual Domain Model

This post is based on the 2nd Ed. of Craig Larman’s most excellent “Applying UML and Patterns”.

Welcome back for yet another adventure into the bright and colourful world of Craig Larman (CL) and UML. I got a slightly tricky domain that I have done some Use Cases for, and now I want to single out one of the high risk areas and start an iteration focused on this – and to gain a good OO basis to start from, I’ll be doing a conceptual Domain Model using UML – and in particular the community edition of Visual Paradigm for UML 7.0. Nice free tool to get you started with UML.

Can you think of anything better to do with an afternoon? Me neither.

So how did we get into this mess in the first place? Well, we decided we wanted to do OO analysis, and Domain Models is one of the core building blocks in Larman’s approach to this. And we like and trust Larman. The essence of OO analysis is division by conceptual classes (not functionality) and the subsequent allocation of responsibilities to these.

So, what is a Domain Model (DM)? Well, it’s a conceptual visualisation of the objects within (a part of) our business domain. So this is still nothing to do with actual Java or C# classes, we are thinking in terms of real world or virtual world actors here. Note that UML does not actually supply a specific syntax for this, so what you do is simply use Class Diagrams, but leave out any code specific details.

ScreenShot016Also, note that we are still in a agile and iterative process (Unified Process) – so don’t try to create a DM that covers every single possible object, association and attribute of your domain. In stead, focus on a high risk area, and within that in your DM only focus on details that are of interest for your current iteration and focus.
If you leave something out, you can revisit this and refine your DM in later iterations. Be cool! Cool as a cucumber. However, don’t try to over-simplify the area you are focusing on. As a general rule more conceptual classes are better than few. Don’t be a pansy. Also note that some objects might only have a behavioural role, which is fine.

So how do we find these blessed conceptual objects?

Well CL recommends using a) a Conceptual Class Category list and b) Identifying Noun Phrases.

I will skip over the first one a bit lightly as I find it a bit rigid and unintuitive – basically it’s a load of categories that you can use as triggers for your poor brain. I found the list online in a word document here if you’re interested:  https://cs.senecac.on.ca/~mary-margaret.walton/conceptualclasscategorylist.doc
Our thanks to Mary Margaret.

Much more fun is going through your Use Cases looking for Noun Phrases!
Now, of couse this is just natural written language with all it’s nuances and ambiguities so you cannot just do a one-to-one mapping, but you’ll work it out.

Either way – all you do now is plunk these into a Class Diagram – and then we’re onto Attributes and Associations. Happy days!

But no! Hang on a mo – first we must head a few words of caution from our wise friend CL:

  • If something is of a simple datatype (string, number) it’s most likely an Attribute.
  • Beware that you will quite often find a need for Definition object and an Instance object. See below here:
    ScreenShot017So the key here is Normalization really – we do not want to duplicate the description and price for every item, and also we need to retain these even if there is currently zero items in the system. (Larman cooks up this elaborate example about flights and some airline disaster where all flights are cancelled, but we have to retain the flight information. Think he might be suffering from post 9/11 trauma).
  • Finally CL recommends “lowering the representational gap” by choosing real world names. I don’t know what else you would do really, but nonetheless it makes sense.
  • Finally, finally – don’t spend days on this, CL says that with some experience you should be able to do a DM from some good Use Cases in a few hours. It’s important, but it’s not rocket science – so don’t worry if you finish it quickly. That’s ok, have a Doughnut.

Adding Associations

Right, probably main sticking point here will be the UML syntax, so let’s cover that. From CL’s book:

ScreenShot018

Note that the direction arrow is just an aid to the text.

Big question is of course, how do we identify the correct associations? Well, two ways: 1) Consider relationships where knowledge of the association need to be recorded or preserved for some duration, and 2) use the Common Associations List below to check through the conceptual objects you have identified.

Category Examples
A is a transaction related to another transaction B CashPayment—SaleCancellation—Reservation
A is a line item of a transaction B SalesLineItem—Sale
A is a product or service for a transaction (or line item) B Item—SalesLineItem (or Sale)Flight—Reservation
A is a role related to a transaction B Customer—PaymentPassenger—Ticket
A is a physical or logical part of B Drawer—RegisterSquare—BoardSeat—Airplane
A is physically or logically contained in/on B Register—Store, Item—ShelfSquare—BoardPassenger—Airplane
A is a description for B ProductDescription—ItemFlightDescription—Flight
A is known/logged/recorded/reported/captured in B Sale—RegisterPiece—SquareReservation—FlightManifest
A is a member of B Cashier—StorePlayer—MonopolyGamePilot—Airline
A is an organizational subunit of B Department—StoreMaintenance—Airline
A uses or manages or owns B Cashier—RegisterPlayer—PiecePilot—Airplane
A is next to B SalesLineItem—SalesLineItemSquare—SquareCity—City

Of the above note the underlined High Priority Associations. Also don’t at this point go overboard with every conceivable association, stick to those that matter in your current iteration and focus. This whole exercise is about conveying meaning, don’t clutter you UML with noise.

Each end of an association is called a Role – and these can have names, multiplicity and navigability – all optional. Below some details on Multiplicity:

ScreenShot019

The standard naming convention for associations is TypeName-VerPhrase-TypeName – see the example above and stick to this format.

Finally CL dispenses a little gem of wisdom. Question is should DM be kept strictly up to date in future iterations as you discover new and interesting complexities or perhaps your requirements change? CL’s answer is – only if there is a practical real value to be gained from this. The purpose of DM is to convey knowledge and inspire later steps (namely our real Class Diagrams) – they are not a strict documentation tool!

Adding Attributes

Again CL tells us to focus on what we care about and what is important when adding these. Also focus on simple datatypes, anything beyond this is likely to be a conceptual object candidate in it’s own right. An example from the post traumatic world of CL:

ScreenShot020

If in doubt: define it as a separate conceptual class and avoid using FKs or overly trivial properties at this point, stick to what describes the Conceptual Class, things that describe the real world object we are working with. However – note also these  examples of seemingly simple data types which should really be conceptual classes are:

  • It is composed of separate sections: phone number, name of person
  • There are operations associated with it, such as parsing or validation: social security number
  • It has other attributes: promotional price could have a start (effective) date and end date
  • It is a quantity with a unit: payment amount has a unit of currency
  • It is an abstraction of one or more types with some of these qualities: item identifier in the sales domain is a generalization of types such as Universal Product Code (UPC) and European Article Number (EAN)

Now, a note on quantities. Most numeric quantities should not be represented as plain numbers – because it is a common requirement to know the unit and support conversions. So the attribute could perhaps be “quantity” and the unit “money” or the attribute is “width” and the unit is “centimeters” or “pixels” – what have you (you might want to convert pixels into print units). However, mapping each of these out into seperate classes called Quantity and Width is overkill, so what you do is collapse this information into the attribute, and you annotate these using “amount: money” or “width: pixels” – etc.
Basically, don’t just write a numerical attribute on it’s own, and be more specific than “number” or “int” when you define the unit. That’s all.

And that’s that!

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: