Speaking to a client a couple of weeks ago, I came across a modelling idea so simple, and so useful, I’m kicking myself from not thinking of it years ago.

They called them ‘NODs’ – Notice Of Decision.

The idea is as straightforward as possible.

They make a decision, then they write it down. What’s the decision, why was it made, and by whom. That’s it.

Ok, so they also link the decision ‘thing’ in their model to the stuff which is affected by the decision. For example, the decision to ‘make all widgets blue’ would be linked-up the the ‘Widget’ idea in a Domain Model, and the the Configure Widget process, which is might be where the Widgets get made blue.

So, many years from now, when some newbie modeller has to idea of making all the blue Widgets go red, they can find the Widgets idea, follow the link back to the decision, and maybe, just maybe, pause before they undo what’s gone before.

Needless to say, this is going onto my ‘top 10 ways to create a good model’, and fairly near the top.

Enterprise Architect Logo 100

For Sparx Enterprise Architect users, I’ve use a ‘Decision’ element. This is normally used in flowcharts, but to use anything else would be misleading, so I used the ‘Info View’ facility in 12.1, and give it a ‘NOD’ stereotype, just I remember that this shouldn’t be used like other decisions.

And I also hooked it up to the process and the Domain Model class with simple ‘Dependency’ connectors, since they are available on all menus.

About the Author Ian Mitchell

Ian Mitchell is a business analyst and software developer. He's been using UML since before it was UML, and has managed teams of BAs all over the place. He also teaches UML and BPMN, and writes the eaDocX document generator for the Sparx EA tool.
%d bloggers like this: