Kengkaj Sathianpantarit wrote:
Class Diagram should include all key interfaces, and all important implementations, not just domain model.
Prashant Purkar wrote:
Your class diagram should describe all the patterns & classes with details such as association, multiplicity, other relations such as realization etc..
Also make sure all the method signatures are proper and complete.
Its a good idea to chcek if one can develop the application, looking at the class diagram.
Jason Marston wrote:
In the class diagram, you show classes that directly relate to or are derived from the problem domain (plus a few orchistrating classes. xxxControler, xxxManager etc). Technology belongs in the Component diagrams In the Component diagram you show all the components, JSP, Session, etc. In the sequence daigrams, you show every class in your design (you may split the sequence diagrams of course to keep the ones representing the use cases simple SSDs)
Of course some of the above is different in real life, it seems to me that SUN want the class diagram to be a Technology Independent Design. The Component diagram to reflect the technology design descisions. The sequence diagram to show how all the classes collaborate to get the job done.
Prabu Senthyl Arumugam wrote:Class diagrams should look technology independant. Looking at the Class diagram, a developer can implement it in C++, Java or PHP.
So I don't think that Class diagrams are good place holders for J2EE design patterns.
Borys Marcelo Borches Herrera wrote:
6 - After the Deployment Diagram, do the Component Diagram with all the components you are going to use in your app. Include JSP, XHTML, JSPX files, Actions, Servlets or Managed Beans (JSF Backing BEans). Create using J2EE design Patterns and should be enough. Like Helpers, Business Delegates + Service Locator, Session Facase, Business Objects, ApplicationServices, DAOs etc. Be sure you call external Systems using an ApplicationService layer.
For more information see: J2EE Core Patterns
7 - Then create the class diagram. Be organized and separate the Class diagram per flow, like: Managed BeanA call Helper A, Call Business Delegate that uses Service Locator, that calls Remote Session Facade, that Calls Business Object A that Calls ApplicationServiceA etc.
A diagram that shows the definition, internal structure, and dependencies of component types. There is no sharp line between component diagrams and general class diagrams.
I started by drawing some (six) rather detailed class diagrams containing ALL the elements of my solution