Question

I’m designing a new system and finding that I am struggling with the structure of what I want to do. A symptom is that every time I re-approach the problem I have to try to draw the relationships of the components on paper. (It is not yet clear in my mind as to what these components are precisely or what the relationship is – for example I managed to delete one that wasn’t doing anything).

Is UML a useful way forward? I used to be very sceptical and tried early versions where the production version cost way too much money. Now I see there is a plugin in Netbeans which inter alia has a good selection of Patterns (this alone might make it worth the while).

I’ve read most of the top-level posts on SO and there doesn’t seem to be a very clear consensus. My context is that this is related to research rather than coding for a client so the main purpose is not to document a final product but to help clear my mind (and possibly write some simple structures).

If any answers support UML it would be useful to suggest how long it will take to get productive and how often it will be used. (As a reference I use tests, loggers, and debuggers every day).

SUPPLEMENTARY Is there anything in UML software that enforces consistency (at any level) between the code and the diagram. I assume that when, say, a StrategyPattern, is created then it can generate stub code. But can that code be included in such a way that if the Pattern is broken the UML tool detects this?

Answer 1

Martin Fowler is IMHO right when he says there are three ways to use UML:

• as a sketch of what you are going to do
• as a blueprint for what you are going to do
• as the thing you are going to do in itself

It sounds like you are mostly leaning towards the first, with a side order of the second. It definitely helps to pick one and set your expectations correspondingly – you can’t expect to execute a sketch, or produce an executable blueprint in 3 minutes.

Whether it works for you depends on a bunch of things like:

• how visual you are as a thinker: people vary very strongly in this.
• whether you can get an effective tool for free, or from your budget.
• whether you need to communicate the design to other people
• if you are effectively using some other means of design (e.g. test driven design).