This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Granularity of components in Component Diagram

 
Bijan Mohanty
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi friends,
I was thinking about the level of granularity I should go in my component diagram. Should I show all the JSPs and the dependency between with the filter and servlet, or show just a JSP Subsystem and the one dependency with the filter and servlet. Also, should I show all the RequestHandlers(HTMLActions) related to the domain in my component diagram or just one abstract high level component called RequestHandler and call business tier facade from that.
All inputs are welcome.
Thanks.
Bijan
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is my take on this - as an architect you are responsible for documenting the architecture( either in descriptive form ie., documents or as diagrams or both ) and passing it on to your design/implementation team.
Follow this simple rule - all the artifacts put together should unambiguously describe the architecture. Someone looking at your documentation should be in a position to identify the entities, their responsibilities and how they collaborate with other components. If the documentation is vauge, insufficient or inconsistent then you are not doing your job well. It is an architect's job to effectively communicate the architecture and facilitate dissemination of information.
When in doubt, it does not hurt to add more information, especially if that helps you in adding clarity in articulating the nuances of your design. Remember that Sun is not only interested in your architectural skills, but also in your ability to effectively communicate your solution to your team. IIf the person looking at your documentation can understand the design/architecture without having to ask fundamental questions, then you have done your job well.
Hope this gives you something to chew...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic