If any class has interesting lifecycle behavior, then show it with a state diagram. I usually try to keep it to no more than a dozen pages. As well as documentation per package, it is also useful to show how collaborations extend across packages. For this identify the key use cases in the system, and document them with interaction diagrams and narrative. A class diagram that highlights the key classes involved is also useful.
Many people advocate drawing interaction diagrams for every use case in the system.
I feel this can lead to too much documentation, but if you find it useful, and you find it isn t a problem to keep it up to date, then go ahead and do it. Even so you should identify no more than a dozen key use-cases to highlight as the ones that everyone needs to understand. In this entire article I m stressing communication. I ve taken a few swipes at CASE tools, but that is primarily to say that using a tool does not by itself mean you are communicating. Any tool can help or hinder communication, how you use it determines the outcome.