• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Intersection issues in component diagram

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mikeh

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

Regards

Akar
 
mikeh Chang
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Hope this helps.

Thanks
Sankha Subhra Das
reply
    Bookmark Topic Watch Topic
  • New Topic