Originally posted by Frank Carver:
When I produce model diagrams for clients they are mostly sequence diagrams to show the interaction between actions and entities.
And I presume these would deal mainly with the business model which would suppress obfuscating details like JSPs.
Originally posted by Frank Carver:
For a new developer to the project, on the other hand, a class diagram showing the relationship between classes and interfaces is a much more useful and expressive document.
And even there you have to be careful not to get too detailed. The static class diagram should highlight the dependencies and relationships, acting as an overall map so that it is clear which class is responsible for what. Sometimes it is necessary to break the diagram into multiple logical sub views because one massive diagram can be so overwhelming that it is useless. Collaboration and sequence diagrams can help to explain some �interesting� interactions on a large scale. However for detailed information clear and concise code is far more valuable to a developer.
If you can model your objects and scenarios in your head while engaged in writing code, and if those models are consistent with object thinking great! No need to write them down. If you and your colleagues use a visual model on a white board as an aid in talking about scenarios and in clarifying your collective thinking about those scenarios, and you erase the board when you're done meeting, also great!*** If your models are crudely drawn and use only a subset of the syntax defined here (or a completely different syntax that you and your colleagues collectively agree upon), still great. Model when you must, what you must, and only what you must.
*** You can always take a picture with a digital camera first if you are feeling apprehensive about losing your work.
Use whichever syntax (graphical or textual) you prefer, Remember, object philosophy questions the utility of any representation or model beyond its immediate assistance to those involved in making the model. Don't get caught up in trying to make your model "complete", "accurate", or "true".
David West,
Object Thinking And West is only reiterating what Robert C. Martin (of
Agile Software Development, Principles, Patterns, and Practices) and his contemporaries have been saying all along:
Model only when necessary but no more than necessary. Furthermore it is necessary to know when to let go of your artifacts. See also
Model with a Purpose and
Travel Light.
Pages and pages of UML diagrams that might as well have been produced by a reverse-engineering tool are useless. Useful UML diagrams show what�s relevant and suppress what isn't - so blind modeling is a pointless and wasteful effort (unless you want to practice your diagramming/modeling skills and are willing to discard the result).
Is Design Dead? Code As Documentation Code as Design aka "the Code is the Design"