UML Class Diagrams Conceptual vs Specification vs Implementation

Question

I am currently reading Martin Fowler's UML Distilled. I have just covered the section on class diagrams, where he places strong emphasis on the need to sort out ones perspective before modelling class diagrams. However, I am slightly confused as to how this looks practically when actually drawing class diagrams. I understand that the theoretical implications change the meaning of an association from one perspective to the next for example.

I guess my main question would be that if for example I was modelling a simple ordering system like he does in the book, would the class diagrams look different and contain different amounts of notation from one perspective to another. For example, from a conceptual perspective would I just show the classes and some vague associations and their multiplicity and then when modelling at the specification perspective include navigability and basic class operations and fields.

I would really appreciate some guidance on this as I would really like to have a better grasp of this subject.

Answer 1

Good question. Here's some thoughts from my own experience; can't say whether Martin would agree (!) but hopefully useful nonetheless.

In summary: main difference comes from formality and design choices for relationships.

I have found the following useful:

• Basic structure: roughly maps to Fowler's UML as sketch, and done on the whiteboard interactively. Main purpose is to understand overall structure. Very informal. In particular, focus on relationships is just to identify them, not formalise - so no cardinality, delete behaviour, choice of container classes, etc.

• Domain Model. A precise model, focused on formalising the relationships. Specifically, naming the association ends, defining cardinality and confirming delete behaviour. Does not consider navigability or choice of container classes for cardinality >1. One of the best techniques I know for learning a problem domain.

I'll nearly always use both of the above. Key thing from the domain model is to use verb-based naming rather than role based - because it describes why the relationship exists (effectively surfaces business rules: e.g. "An order must be placed by exactly one Customer"). I use the naming template described in Simsion & Witt's book.

There's work to be done in translating the domain model to working code, specifically in the relationships. Programming languages don't support relationships very well, so the associations have to be translated into attributes of the participating classes. It's at that point that navigability comes into play, along with choice of collection type for multiplicity >1. It's also where all the operations need to be specified. I don't personally find this type of diagram particularly useful. A domain model plus the code give me everything I need.

I'll only ever use "UML as programming language" if I'm using an executable UML tool.

Apologies if that's a bit rambling, hope it helps...

PS: If you want a better example of verb-based naming, I have a post on my blog. Please don't take that as self-promotion, just no point in repeating here.

Answer 2

Here's how I explain the ideas to developers.

• Conceptual is the relationships. This is the level where coupling should happen. You shouldn't see coupling from conceptual to implementation - that's a signal of a poor design.

• Specification defines the algorithm without defining the implementation. In a class diagram, this might be represented as an abstract class. Alan Shalloway calls methods which fall into this realm "Sergeant methods": They just bark orders.

• Implementation is where the actual work happens. This might be represented by concrete classes which implement your abstract specifications.