aspose file tools
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Intersection issues in component diagram Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of The Software Craftsman this week in the Agile forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Intersection issues in component diagram" Watch "Intersection issues in component diagram" New topic

Intersection issues in component diagram

mikeh Chang

Joined: Sep 05, 2005
Posts: 6
Hello All,

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?
Akar Rafidj
Ranch Hand

Joined: Aug 30, 2005
Posts: 44

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


mikeh Chang

Joined: Sep 05, 2005
Posts: 6
Hi, my friend,

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 Chang

Joined: Sep 05, 2005
Posts: 6
Hi, my friend,

Another doubt is the following.

do we only need to care about the four use cases and ignore other use cases such as login, create profile, view frequent flyer miles ?

Do we need to mention alternative flows such as customer not login, credit card authorisation fails and customer selects award travel?

If we do, how do we process them?
sankha subhra das

Joined: Jun 24, 2003
Posts: 22
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.

Hope this helps.

Sankha Subhra Das
Have you tried LearnNowOnline?
subject: Intersection issues in component diagram