Herman :)
Nothing can beat a whiteboard even if your using it on your own.
Indeed. But I forgot to mention a specific case where tools are actually quite valuable: reverse engineering of complex, existing code ;)
I just feel that modern tools are not up to it yet
Well, tools such as Rational's Rose or Borland's Together *are* but it takes a very long and steep learning curve to use them to full potential and that usually only pays off in very large and complex projects.
I agree with you. Guess I should have said "up to it regarding usability". I've been using Together recently and find it to be quite sensible. Poseidon has a very good UI but some other quirks that make it annoying. The thing is, each tool seems to be quite strong in some areas and dismally weak in others; there is no consistency across the whole set of features supported.
Also the developments on Model Driven Architectures (MDA) look very promising and if you want to go on that road you'll have to use UML tools.
He, he... MDA. We could start a very interesting argument about this I guess :) It indeed looks promising but there are still many issues to be addressed. But you are right, comitting to MDA means committing to one tool or another. But part of our argument could be whether you really need UML for that :)
... and jump to code straight ahead. Which is not any good actually.
There are degrees of jumping ;-) and a well prepared jump is something that the Agile movement is suggesting as long as you take into account *that* you are jumping and be prepared to revise your designs on a regular and controlled way.
Thank you so much for clarifying this. In fact, I have become a big fan of Agile, as long as it is *not* eXtreme Programming. I prefer the approach outlined by Cockburn in "Agile Software Development".
Another one that might give you some handles is Agile Database Techniques by Scott Ambler specially if you come from a relational background.
Ambler also publishes a monthly columnn in Software Development (www.sdmagazine.com) where he touches on many Agile issues, from development to management. In fact his last three articles have been a series about agile database refactoring, I should also have mentioned this yesterday.
One thing you have to take into account is that you have to be aware what you are modeling just data or a complete application. Because Cache is both a database *and* an application server mixing the two is a very common error that people make. At least in the beginning try to seperate your data and application designs.
Indeed - this is common. If you put too much logic into entity classes, they become bloated and the systems using them would be too coupled to them as well. The other extreme is having very "thin" entity classes which barely do anything (the real extreme in this sense is to have classes only to query them via SQL!) A good division of responsibilities between a set of core domain classes and families of application-specific classes seems to be the best way to develop large systems of systems.
Matthew - you'll probably have noticed by now that Herman is one of those persons I mentioned from which much can be learned :)
Ram�n
