First of all apologies for my not so good english, I´m spanish speaker
I´ve been working for a while on my assignment and I think I´ve got an almost finished solution which hopefully fulfills the requirements, but now I doubt a lot about how I´m expected by Sun examiners to represent that solution using UML.
I started by drawing some (six) rather detailed class diagrams containing ALL the elements of my solution (all interfaces, all classes, EJBs, JSF pages,etc, etc, I´ve included even DAOS, DTOs and JPA Entities). Now, when I´m working on component diagrams, some big doubts have arisen. [And by the way, please, I´m not asking about concrete advice on how to architect my assignment, I know many of you think DTOs and DAOs are dead, but that´s the way I wan´t to go and I repeat I´m not asking nor interested about that]
I know now that maybe my approach (starting with class diagrams) wasn´t the righ one but the majority of work is done and I think is good enough (hopefully
) not to have to redo it all over again...
Despite I´m very far from being an UML expert I believe I understand the main differences between class and component diagrams but I´ve got several questions about them that I would like to raise here:
1) Which is the level of detail we´re expected to offer in each type of diagram to pass the assignment? Should it be greater on component or on class diagrams?
2) May/should class and component diagrams overlap? I mean, for instance: Must I show JSF pages on both of them? Only on one of them? Only on component diagram?
3) May I show technological dependencies on Class diagram? Should I avoid them?
4) May I use several component/class diagrams? If I do that, is it a good way to distribute them using use cases/flow control?
I haven´t been able to find clear answers to these questions so far. Maybe they simply don´t exist because the ones I´ve come across while reading this forum are somehow contradictory. Some quotes on this:
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 diagramsIn 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.
And finally (to make my doubts and my grieves even bigger
) in "The Unified Modeling Language Reference Manual Second Edition" you can read in component diagram definition
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.
Please any advice on what it´s expected to pass the exam about detail and scope of component and class diagrams would be very welcome.
Thanks in advance