Considerations about component diagram

[Antonio Rafael Rodrigues]

Hi =]
I have some doubts about component diagrams that I'd like to ask. I'm no sure if I'm being overly detailed.

1) As the most part of my EJBs are LocalBeans I don't have interfaces in that, hence I'm not using the lollipop symbol in the relationships, only the arrow that indicates <<use>> (just as in Cade's book example) or others stereotypes like <<send>> or <<listen>>. Can I loose marks if I use only the arrow of relationship? I know that the Cade's book example uses just this, but I have my doubts if it's good to follow.

2) Do we have to show the external systems in component diagram? If yes, which symbol to use to represent it? I thought about using a component with the <<external system>> stereotype, but a external system isn't a component. In examples that I have, the people use a package symbol (from class diagram) or a node (from deployment diagram) but both aren't official symbols for component diagram.

3) By the same way as item 2, how to represent a JMS queue? From my point of view, queues and external systems are all actors, but these aren't official of component diagram as well.

4) Now a very subjective question: I have a ManagedBean with session scope that holds the user information and is injected in all view scope ManagedBeans. Do you think that I shoud show it in component diagram? It's going to add a considerable clutter if I add it and I'm not sure if it's worth to show.

Thank you very much.

[Andres Olarte]

Hey Antonio.

Here's my take.

1 - From the case you're describing, you don't need the lollipop symbol there. But you might need it somewhere else. Are you interfacing with an external system?
2 - In here you can use the external stereotype. That's pretty self explanatory. Just make sure you mention just the bit of surface you're interacting with.
3 - This depends on how you scope it. You could think of JMS as an actor that initiates an operation. You could think of it as an external system where you send data. Just make sure that the whoever reads it understands what the JMS system is doing.
4 - As subjective as your question is, my answer is even more subjective. Most people would assume that you have some session object to keep your data. You don't have to show it in every place. If you have it in your class diagram, do you need it in your component diagram? Yes, if it's required for the component diagram to achieve its purpose (depict how components are wired together to form larger components and or software systems).

Good luck,

Andres

[Antonio Rafael Rodrigues]

Hi Andres. Thanks for you reply.

1 - I have two interfaces.
1.1 A System sends JMS messages to a queue that my application listens to. I have a component with a Message Driven Bean stereotype, linked to a component with a JMS Queue stereotype, the link has a <listen> stereotype. Then I have a component representing the external system with a <external> stereotype linked to my queue, the link has a <send> stereotype. All links are representing the correct directions. Then, I don't see any reason to have a interface here.
1.2 My system has to call a webservice. In my UML diagram I created a package with an interface and a class. I created a note informing that this package represents a client generated by the wsimport tool and the class inside it represents the element root of a JAXB structure generated, the interface represents the WSClient interface that will be generated as well. That was the best form that came in my mind to represent the webservice client inside the flow, filling the JAXB representative class and sending to WSClient representative interface. In this case I created a component representing the generated client and I used the lollipop to represent the interface that it provides and I have connected my ejb to it.

2 - Ok, I'll keep it. A component with a external system stereotype.

3 - Ok, same as 2 with JMS Queue stereotype indicating direction.

4 - Really difficult. The managed beans will show data related to the logged user, then it's essential connect to user session to know who is the user, but all my managed beans have the same need. If it was only one, or two, there wasn't any doubt. But the fact of being injected in all managed beans makes it sound some kind of a trivial component.

Thanks again =]