Effective UML

For a while now I’ve been thinking about how to make sure that diagrams produced whilst designing software are actually useful. I mean, it can be very tempting to spend hours crafting a beautiful diagram that perfectly represents the software you are trying to create. And one of the brilliant advantages of diagrams is that, since they can’t be compiled or actually used, they will never have bugs! But just because they are nice isn’t, in my view, a justification for creating them.

Back in August Verity Stob wrote an insightful and witty article about diagramming entitled “In the beginning, there was the flowchart…” In it Verity challenges the usefulness of some modern diagram types (with a particular eye on UML). Her article prompted me to ask the question “Are diagrams pointless?” over at the Construx Best Practices forum which provoked some interesting reactions. Of course I don’t think all diagrams are pointless. But to make sure the diagrams you produce aren’t irrelevant works of perfect genius I would recommend applying the following rules:

Think of the audience

A diagram has to effectively communicate an idea to a specific audience. Think about who you are producing your diagram for. Will it be used to sell a concept to a customer or will it be used by developers to help them understand the work they are about to undertake?

Check that a diagram will be useful

Ask yourself if a diagram is actually the best way to communicate to your target audience. If you are trying to sell an idea to a customer a prototype may convey it far better than a state diagram. If you are producing a class design for a developer then it may be that writing a skeleton class (with comments indicating how each method and attribute should behave) is the best way to communicate your design.

Keep it simple

Creating a useful diagram is more about what you leave out than what you put in. If you show in one diagram every detail of how your product will work then, frankly, you might as well have built it. As you produce a diagram consider whether each detail you add is improving clarity rather than obscuring the main point of the diagram.

If you liked this you might also like some of my other posts about software design and requirements:


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

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: