Entity Bean in Class Diagram

[Din Don]

Hi,

Should we include EntityBean classes in the class diagram ?

Thanks.

[Ricardo Ferreira]

Originally posted by Din Don:
Hi,Should we include EntityBean classes in the class diagram ?

Well,

The world 'should' must not be used because this means some kind of "MUST TO DO", and we aren't here to show you the right way. But we could give you some tips about what can be done at the design model. Try to figure out this questions by yourself and make your senteces with "could", "it's possible ..." please

You're able to put at your class diagram classes representing your entity beans (If you decid to use this kind of persistence). But, I would advice you to use some stereotypes at those classes, something like <<EntityEJB>>, <<Entity>>, or something else.

By concept, if you have entity beans in you application, they represents you persistence domain model, and of course should be included at the class diagrams, since they're created apart your BDM.

Do not worry about the EJB interfaces for an entity bean like javax.EJB.EJBLocalHome, javax.ejb.EntityContext or javax.ejb.EntityBean, just keep in mind your bean classes.

[Santiago Urrizola]

i don't agree to put this stereotypes in thes class diagrams. A class diagram shoul be technology independet. So you model your bussniss regardless the technology you use.
You can put this Desitions (Wich objet are Entitys, Session, Etc) in other diagram, like a component diagram, or a technology class diagram, or perhaps in a document (mucho better in a diagram i think)

[Thomas Taeger]

Hello Santiago,
I think it is a very good praxis to separate the white-box view for different technologies, say direct EJB access vs. WebService, into different class diagrams (though it is not a "must").

However your first sentence "A class diagram shoul be technology independet" is too rigid and thereby confusing, because the second class diagram is a class diagram too Later you say yourself: "You can put this ... in other diagram, like a ... technology class diagram".

I would encourage to
- show all components of both technologies (EJBs vs. WS ...) in one and the same component diagram,
- show both components along with the interfaces that both realize, and then
- specify the white-box view of each component in a separate small class diagram (if not too trivial).

Or, if it becomes too huge,
- show all components of one technology (either EJBs or WS ...) in one component diagram each,
- show one type of components along with the interfaces that it realizes, and then
- specify the white-box view of each component in a separate small class diagram (if not too trivial).

In general there is a good reason to show EJBs in class diagrams too. For EJBs it is quite unusual to show the interfaces (although thay would even tell more!). Other types of components like JSPs do not even have interfaces that we could show in class diagrams. And if we can not show the interface then in my opinion we should show the class of the component in the big class diagram, if any.

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