Question on Component Diagram

[Steven Wong]

Hi,

How detail should I be drawing my component diagrams?
Say if I have 5 session beans, do I have to create 5 components for each one of them?

[I Roberts]

I am assuming that as the Session EJBs are components in their own right then the answer is yes, you do need to show them - but this is only my opinion. Remember a component can be a single class or an association of classes with a common exposing interface that enables other components or applications to interact with it.

Entity EJBs that use the Composite Entity pattern only need to show the name of the component, which is basically the Entity EJB as we can assume that it encapsulates related objects within it. The same is for the Session Facade pattern.

Hope this helps?

[Steven Wong]

Hi Ian,

Thanks for attending to this question.
Yes, I am including each SB as a component by itself.
My other question is now do we need show each of our TOs as a component or it would follow the Composite Entity object, ie one object representing all others? Thanks in advance.

[Vinay Singh]

Hi Steven and Ian
While discussing components , should we
a) show all the components in one single diagram or do we have show as per package we have for eg bd, ejb, , util etc ?
Or we show as per layers like
View - jsp's and Swing client
Controller - Servlet & Request Handlers+ Business Delegate
Model - DAO, Session & Enity Bean

b)If there are more than one diagrams , how do we show relation ship between them or interaction between layers for eg how would Request Handler or BD interact with EJB

c) Do we also need to show dependency and association between various components. ?

Thanks for your help.

[I Roberts]

Transfer Objects are transient objects that have a limited life span (i.e. usually for the duration of the data transfer) and may not be specific to one type of component. I often make sure that my DTOs are independent components in order to improve reusability (i.e. although a Customer component may initiate the creation of a CustomerDTO it may also be amended by a client application in order to change customer information - in this respect the CustomerDTO is not a part of the Customer component but a Customer dependent component. However, I cannot remember whether or not I showed Transfer Objects but there is nothing wrong in doing so, you are clearly providing the reader with information that is valuable for explaining the interaction across application tier boundaries.

Hope this helps! Sorry if it gone into waffle - I can go on for ages about modelling and components - even though I do have a happy life!

[I Roberts]

Vinays,

I only created one main Component diagram, which contained all the major components within their respective architectural tiers, and supplemented this diagram with a number of smaller component and/or class diagrams with specific views. I'm not sure if the supplementary diagrams made any impact upon the assessors but it made me feel better in my attempts to explain the solution.

Regards,