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.

Byrd

Modeling with a Sense of Purpose a 2002 IEEE article by John Daniels published on Martin Fowler's site. The article describes a useful distinction between conceptual, specification, and implementation models. – Brad

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.

Nasion

Long time no see.thank you for your efforts in UML tag you are really amazing ,I hope you continue writing in your blog about UML and related topic.I hope I can do the same but I am still beginner – Cardoza

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.

Quell

Answer 3

Exactly, UML class diagrams are just a notation that you could (and should) differently depending on the sofware development phase you are in. You can start with only classes, attributes and associations, then refine the diagram to add types information for the attributes, then navigation, class methods, qualifiers for associations ... until you get a complete class diagram ready for the implementation phase

Note that you could even iterate to the point in which you remove associations and replace them by attributes of complex types to have a class diagram even more similar to the final implementation. It's up to you how to use class diagrams in each phase.

Thamora

Answer 4

Martin fowler's books are crap for me (e.g my personal feeling) as soon as he is starting to talk about the class diagram!! I agree for the other diagrams but the class diagram should be more pragmatic and not just high level designs !!

It is always the same theory that you need to model at higher level of abstraction and then to model what you really need. I prefer to quickly provide a running code and show it to the customer. From that first stage we start modeling in order to have functional demands but also code. Once we finish this second stage we show it again to the customer and again provides UML class diagrams to change what need to be done. After 10 iterations my project is usually finished. For example my project last 3 to 6 months. This is a really complex project and my customers is usually satisfied. Using Martin fowler's recommendation my project would have not been finished in 12-18 months and the customer would certainly be disappointed.

Sheriesherif