Other post regarding Class and Component diagram. Give your opinion!

[Samuel Pessorrusso]

I know that there are a lot of posts like this, but I've been searching for some answers and the more I search more confusing I�m getting.

The fact is that UML is a great way to document you project, BUT it does not tell you what to document . So my questions are:

1)Class diagram: Do I need to show DTO, Business Delegate, Entity Beans, Session Beans, Servlet, etc� or just the Domain Model Classes ? There are a lot of discussions regarding this point, but I didn�t take part in any side yet.

2) Component diagram: Do I need to show the DTOs ? If so, how can I do it? (Should I need to show it like a Component? The Entity Bean represented by the DTO should have a dependency to the DTO?)

3) Component diagram: When I use Entity Beans CMR, should I show a dependency between the beans that participate in the relationship? (e.g. Customer and Profile)

4) Component diagram: How can I show a Queue? I�m just showing an Interface and a Component called Queue, is that right?


Please, give you opinion! I think that these doubts are not just mine.

[suekar meredilko]

My opinion: At some point of time when you interact with the developer you will have to show DTO, BD, Entity/Session Beans and so on.
Initially, the Domain Model is enough. So my view is everthing is required. Some judgement is required, you not want to show utility classes which might be obvious. For the assignment, I suppose we should be as detailed possible, so I have 2 answers for your question. In the real world this would be difficult as it depends on the size of the project, time, resource and so on.

2) Component diagram: Do I need to show the DTOs ? If so, how can I do it? (Should I need to show it like a Component? The Entity Bean represented by the DTO should have a dependency to the DTO?)

My view: From a truly architectural perspective, i dont agree you should show DTO(s). The reason i believe DTO should not be there is because they are not 'alive' or or providing any runtime function on the 'node' in a deployment diagram. Component diagram help show the structural relationships between the components of a system and as per UML 2.0, Components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces. They represent larger design units. DTO is not a large design object according to me. Its a pattern you follow in your design

3) Component diagram: When I use Entity Beans CMR, should I show a dependency between the beans that participate in the relationship? (e.g. Customer and Profile)

No, same as above, we should focus on larger design objects

4) Component diagram: How can I show a Queue? I�m just showing an Interface and a Component called Queue, is that right?

I am curious to know about this also.

these is my opinion, hope am not wrong

[Santiago Urrizola]

4) Component diagram: How can I show a Queue? I�m just showing an Interface and a Component called Queue, is that right?

in my work i do it with a new sterotype called QUEQUE, and an interface, i dont know if this is the correct way ...

[Thomas Taeger]

Originally posted by Samuel Pessorrusso:
1)Class diagram: Do I need to show DTO, Business Delegate, Entity Beans, Session Beans, Servlet, etc� or just the Domain Model Classes ? There are a lot of discussions regarding this point, but I didn�t take part in any side yet.

Yes, there are a lot of discussions regarding this point. What would you expect to get if you were the customer?

Originally posted by Samuel Pessorrusso:
2) Component diagram: Do I need to show the DTOs ?

Does a DTO have a noteworthy interface, noteworthy enough to make it a pluggable, replaceable component?

Originally posted by Samuel Pessorrusso:
4) Component diagram: How can I show a Queue? I�m just showing an Interface and a Component called Queue, is that right?

If it is a inter-subsystem queue like for JMS, then I would agree - except for the name. "Queue" may be good as stereotype name but the component as well as the interface name should be more specific.

If it is a client-side/internal queue, I would not show it as a component.

Thomas

[suekar meredilko]

Originally posted by Thomas Taeger:


Does a DTO have a noteworthy interface, noteworthy enough to make it a pluggable, replaceable component?

Thomas

Hello,

I see that in some internet sites, JSP, ActionServlets(controllers) etc are part of the component diagram. Strictly speaking JSP does not have an interface and UML defines a component as the ones having an interface. Does that mean we should or should not show JSP(s) and others which are runtime components ?

any ideas ?

[Thomas Taeger]

Hello,

Originally posted by suekar meredilko:
I see that in some internet sites, JSP, ActionServlets(controllers) etc are part of the component diagram. Strictly speaking JSP does not have an interface and UML defines a component as the ones having an interface. Does that mean we should or should not show JSP(s) and others which are runtime components ?

Sorry for the confusion.

Some types of artifacts or classes, like JSPs or other HTML generators, have been standardized for being a component and, as you said, must be shown in the component diagram.

Other components composed of "normal" classes should provide their services via interfaces. There is no technical enforcment to do so, one could just draw dashed dependency arrows between components directly. But my personal rule for (non-JSP ...) components is: Check their interfaces wether they are worth to declare separate components, i.e. offer enough cohesive methods that make sense to be provided in the same interface.

Otherwise we could provide each and any class as a component (our deployer will not be too happy ...).

For a JSP it differs slightly: It usually is composed of generator code for several HTML UI elements like <FORM ...>, that are welded together and are handled as one very cohesive thing. The technique of JSPs in contrary to just .html pages plus hand-coded HTML generators has been introduced for
- concentrating the concerns of all the UI element generators of one logical page within one component and
- separating the concerns of multiple logical pages from each other

But for [Data] Transfer Objects ([D]TOs): What else than values ("VO"...) to be transfered ("TO"...) are provided, with or without trivial getters/setters? Any other component using this DTO has to carry in its .jar either that DTO's .class or that DTO component's .jar anyway.

Only if the DTO's attributes change then its potential interface would change, so introducing this trivial interface and that trivial component would not concentrate or decouple anything and would not bring any benefit - but more work for the deployer.

Thomas

[Parag Bharambe]

DTO's are required in Application as well as Presentation. So rather than showing DTO's in component diagram and cluttering the diagram more, I would prefer to mention this in Assumption section.

I agree that we can mention Queue as a steriotype. Will Queue and MDB be mentioned in Class diagram or Component diagram. I believe they need to be in Component diagram, becuase both of them are Component?? Your thoughts....

Parag

[Thomas Taeger]

Originally posted by Parag Bharambe:
DTO's are required in Application as well as Presentation. So rather than showing DTO's in component diagram ...

Classes like DTOs used in multiple tiers ("Application as well as Presentation") often are grouped in a third package "common".

A package totally differs from a component (e.g. in one sub-package there are all DTOs used in the system), but say a component is to realize only one usecase like e.g. Payment, so some Payment-related classes of the com.co.common.dto package, some Payment-related classes of the say com.co.common.model package etc. could form a "PaymentCommonComponent" that is an intersection of multiple packages (has only some classes from a package but from multiple packages).

Then an Application component as well as a Presentation component can use this prepared common PaymentCommonComponent,
- partly through well defined interfaces and
- partly (for my DTOs not having interfaces) directly, shown by direct dependency arrows.

What do you think about this way to clean up components structure and get loose coupling based on usecases?

Thomas
[ June 12, 2006: Message edited by: Thomas Taeger ]

[Samuel Pessorrusso]

Originally posted by Thomas Taeger:
...
Then an Application component as well as a Presentation component can use this prepared common PaymentCommonComponent,
- partly through well defined business interfaces and
- partly (for my DTOs not having interfaces) directly, shown by direct dependency arrows.

Don't you think that you are going too deep? You can explaining these things in your assumption in a section "how the application is packed" but I think that is not necessary.

In the SUN's training material, the DTO are showed not as a dependency, but something like an association at remote calls.
Something like this:

[Comp1] ----> [Comp2]
          |
          |
       [MyDTO]

But I haven�t found a tool compatible with this notation and I don�t think that is really necessary. I think I will just mention the DTO in my assumptions.

Any comments?

Regards,

[Thomas Taeger]

Hello Samuel,

Originally posted by Samuel Pessorrusso:
Don't you think that you are going too deep?

I have considered your question for quite a while, and my thoughts are:

There are two kinds of dependencies,
- "interfaced dependencies" concerning only signature changes and
- uggly "implementation dependencies" concerning also each implementation change and therefore should be kept rare.

A component diagram mainly is a "dependencies showing diagram".
Therefore this distinction between "interfaced dependencies vs. implementation dependencies" is important, and this is the reason why I still would prefere "an Application component as well as a Presentation component ... use this prepared common PaymentCommonComponent,
- partly through well defined business interfaces and
- partly (for my DTOs not having interfaces) directly, shown by direct dependency arrows." ... the "uggly" part.

PS: In a component diagram
- showing the components is the minimal base
- showing the interfaces of components is showing quality of architecture
- showing direct dependency arrows between components is showing the remaining risks.

Thomas
[ June 19, 2006: Message edited by: Thomas Taeger ]