View Helpers and Value Objects in a component diagram?

[Tomi Tuomainen]

Do you think it's appropriate to show View Helpers and Value (or Transfer) Objects in a component diagram? Those aren't actually components but will be probably implemented as classes. On the other hand it's hard to model for example a dependency between Front Controller and Business Delegate without a "helper component".

Any opinions appreciated....

Tomi

[Ramon Gill]

Tomi,
I've looked in zillions of places to try to find examples of component diagrams with DTO's, but couldn't find any. I understand why you might consider it (easier explanation of diagrams). However, most places I've looked at just use sequence diagrams or class (implementation) diagrams.
I've come across non-UML diagrams that show what you want - no good to us though!

Ray

[Dhiren Joshi]

Tomi,
You might want to add a note in your component diagram and clarify it further in your assumptions document.
Thats the way I am going about .Also VO you could expand it in sequence diagram.

HTH
Dhiren

[Tomi Tuomainen]

Thanks guys, leaving obvious classes out of the component diagram might be a reasonable choice.

According to the UML spec we could show implementation classes that specify the component. The problem is that VO's are USED by components in both tiers, I suppose they don't actually specify other components? But I guess we could model a web application component and an EJB application component, which would hold another components and also implementation classes?

Unfortunately a component inside a component is not usually supported by modeling tools, but with some additional "boxes" anything can be done.

[Foram San]

cant v put a utility component & add such classes in that component? - just my suggestion....

[Tomi Tuomainen]

"A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces." (UML spec)

What do you think about "View Helpers" or "Value Objects" component? There wouldn't be a proper interface?

[Parag Doshi]

Originally posted by Tomi Tuomainen:
"A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces." (UML spec)

What do you think about "View Helpers" or "Value Objects" component? There wouldn't be a proper interface?

Tomi,
Would it help if you show dependencies to a generic "View Helper" or "value object" component. That way, you do not have to show any specific view helper or value object, just a dependency of the presentation and business tier to these components.
My knowledge of component diagrams is not that great, but it seems logical to have a couple of components, i.e. 'view helper' and 'value object' and then show dependencies to them by which ever components are using them.
Does this make sense?

Parag

[Tomi Tuomainen]

Parag,

I know what you mean: describing a common view helper in the same way as in J2EE patterns catalog. If we think that component definition, I still feel that such view helper wouldn't be a component. Showing a business delegate as a component is ok, because there is going to be that one business delegate, but there would be many kind of view helpers and that's why I feel uncertain in showing just one common view helper.

It's different with class diagrams, there we could show just one abstract view helper (upper class). I think this is the reason that Sun prefers class diagrams in J2EE patterns presentations (for example here).

On the other hand.. UML is not a formal language, we have just a spec and individual interpretations of the text. And how smart are the examiners? Are they just trained to check some things with some basic J2EE knowledge or can they truly consider these kind of issues?