I am be troubled by the chaotic component diagram. How can we make component diagram to be simple and clean? there are many components in the components relationships in the component diagram, such as form beans , Jsps, actions, session beans, DAOs. Do we need draw every dependence relationship in the diagram? If we do, there are many intersections which make diagram cluttered. Do you have any suggestion to discrease the intersection and also make diagram clear enough?
You may use Cade strategy, you break your component diagram into separate diagrams, according to how you package your components : by related use cases, by responsabilities, by tiers.... Anothet strategy is to use generic component to model identical components: you don't need to show each jsp page or each VO (jsp pages may be represented by a generic component labeled "View" or "User Interface", list them in your assumptions. You may also use composite components: component that contains other components: sample a servlet which uses a view dispatcher, a request processor which uses actions, a BMP containing a DAO.... I have a component diagram with 30 components, it's very clean, without any intersection
The assignment ask me to " Create a Component diagram that shows all of the J2EE components used in the system and their interaction. For example, what EJBs, Servlets, and/or JSPs might be needed? ".
I still have the following doubts.
1. The assignment asks us to create a component diagram. Can we really create three diagram in line with Cade's strategy?
2. The assignment asks us to show all of the J2EE components. Do we need to put all VO in component diagram? Each VO communicates with several componets , if showing VO's all interaction, it makes many interaction. How do we process the issue?
3. Do we need to mention SSL in any digram or the summary?
Mikeh, the answer is "it depends". Yes, its perfectly ok to follow Cade's strategy and create few ( 2-3 component diagrams). Normally for each unique flow, there would be 1-2 VO's involved. You may not write the entire details of each VO just a mention would be sufficient. Yes, its best to put non-functional "good-to-have" features like SSL in ur assumption section. Yes, those 4 use cases are the ones u'll be graded on. If you feel additional use cases will support ur understanding and/or architecture, go ahead and depict it. But as for component diagram is concerned, they all will follow standard typical artifacts for each unique flow( ie view, controller, helper, validator etc).I depicted additional use cases if any in sequence diagrams to depict pre/post conditions w.r.t other use cases and left the component diagram from getting cluttered. Yes, alternate processes are important and best represented in sequence diagram and/or in the assumption section.