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.
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.
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.
I started by drawing some (six) rather detailed class diagrams containing ALL the elements of my solution
You may want to pause for a moment and consider how granular you get with your detail of the solution.
Any assignment.... if you think of as a software project in the real world.. is gonna take 6 months to 1 year (before your VP starts yelling about time to market).
Thats a big gestation period and yes people have the luxury and the necessity to go into great details.
I think this assignment should be considered an 'assignement'.. just like school with a two week or a two month dead line.
Class diagram is a great starting point to get the verb(controllers) and nouns(entities) from the requirements.
Class diagram fuels your component diagram in turn your sequence diagram(s).
So if you already have 6 class diagrams.. how many component diagrams will you have..
Long story short.. you got to be concise..
I may be wrong..