I found myself creating small, purpose-specific diagrams showing only those things that were relevant to the task at hand. These diagrams would get tweaked and maintained as my understanding of the task and domain evolved. While maintaining diagrams is not really all that hard, it is time-consuming and distracting.

After some thinking I realized that the answer to developer productivity was sitting right in front of me: Mylyn task context-driven diagrams. Why can't the MDD tooling create and maintain a domain diagram based on the interesting domain elements in the active Mylyn context? There would be no need to create or maintain such a diagram manually: it would always exist, and it would always show only those items that are relevant to the currently active task. Suddenly, purpose-specific diagrams become implied, easy, expected.

I realized that a few simple rules could make such a diagram really work:

• domain elements in the Mylyn context always appear in the diagram
• associations between elements in the diagram are always shown
• removing an element from the Mylyn context causes it to be removed from the diagram
• adding an element to the diagram causes it to be added to the Mylyn context
• diagram elements are positioned according to a default layout algorithm, but remember their positioning if moved manually
• diagram state is saved and associated with the Mylyn task id, such that it is restored when the task is re-activated
• switching active tasks automatically resets the diagram to correspond to the new active task

Now that I've been working with automatic domain diagramming I wonder how I ever got by without. Context-driven diagrams are now an essential part of my toolkit that let me focus on the task at hand without distraction.

From http://greensopinion.blogspot.com