UML's good for docs
But if you've got everything and the kitchen sink in your diagram (ie- all 1500 classes) then you're not using it properly.
You've got to approach something like that in a layered perspective. For example, a client server application's top level uml diagram should have two or maybe three things on it; a client and the server, with the calls happening between them, and perhaps the actual network between them. Then, you can get the top level diagram for each of those two subsystems, keeping it simple throughout, breaking things down into subsystems as needed. You might also want to create a diagram representing the actual network between them if you have to deal with the particularities of the infrastructure architecture for your app, so that if you need to detail failover options at the network level you can do it in that specific diagram.
Having it all in one diagram might make for a neat pic, but it's not very useful. The point of it is to help communicate the architecture of the application to other people, and a spaghetti diagram isn't going to do a very good job of that.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
