Appropriate and inappropriate use of stereotypes

[Mike Degteariov]

Hey Ranchers,

I need some help in how to properly use stereotypes in Class diagram.

Cade's book suggests that we can use <<@Stateless>> and <<@Entity>> stereotypes.
Amritendu De's book uses <<@JSF>> and <<@managedBean>> stereotypes, in addition to those from Cade's book.

So I take as granted that using the stereotypes above won't cause lost marks.

Now, here's my questions:
1. Class-level stereotypes: Do you think it is stll OK to use a <<@managedBean>> stereotype for CDI beans annotated as @Named ?
As you probably know, JSF dependency injection is inferior to CDI, and in Java EE6 we should annotate backing beans with javax.inject.Named, not with javax.faces.ManagedBean
Should we use a stereotype <<@Named>> for backing beans instead ?

2. Will it be OK to use stereotype for operations ?
For instance, I'd like to use stereotypes <<@Asynchronous>> for the methods in stateless beans that are annotated as @Asynchronous and meant to be asynchronously executed,
and <<@PostConstruct>> for the methods annotated with @PostConstruct

3. is it OK to annotate dependencies (a.k.a dashed lines with arrows) ? I consider on adding stereotypes like <<@Inject>> or <<@EJB>> to denote different kinds of dependency injection, or <<Include>> to show when JSF views (xhtml) are included into template.

The purpose for all these these stereotypes from p.1-3 above would be to enhance the diagram and to give the inspector an additional information about the logic behind it. I also planned to create a glossary for stereotypes I use.

Then I learned from this post:
http://www.coderanch.com/t/595412/java-Architect-SCEA/certification/Jar-resubmit#2715109
that someone in the past have lost marks on class diagram because of "Incorrect inconsistent use of stereotype" and now I much more sceptical about stereotypes.

4. So, what do you think is better - to use non-standard stereotypes and have a glossary for them, or only use "trusted" stereotypes from books, and use comments to diagrams to provide necessary information as comments ?

5. Most importantly, what stereotypes did you use in your assignments, and do you think that they did not cause lost marks ?

Thanks !

[Andres Olarte]

I think for the most part you can use stereotypes in a way that makes sense to you (and hopefully to other people without having to explain). I would stay away from having a glossary. If you're annotations are so complicated that they need a glossary for a knowledgable reader to understand, they're probably not clear. Remember that it's important for diagrams to stand on their own. Of course this actually implies using them consistently.
Specially in terms of dependencies, as much a possible, I would stick to common stereotypes, and make sure you're using the right combination of lines/arrows. Other than that using annotations like @Named, @EJB, @Asynchronous, etc. as stereotype for objects and methods should be ok.
Remember to focus on details that add to the understanding of your design, not so much the mundane details of possible implementation.

Good luck,

Andres

[Mike Degteariov]

Hi Andres,

Thanks.

I tend to agree with you, but the fact is, someone lost marks because of stereotypes, and I am not sure I know how to avoid it.

Btw, can you please tell me what stereotypes did you put in your diagram s?

[Antonio Rafael Rodrigues]

Hi Mike,

I'm still thinking about the use of annotations as stereotypes. Unless @Entity, don't you think that just <<Entity>> would be better? This would allow you to have other stereotypes that aren't real annotations.
For example. I decided to use @ManagedBean because I think that a ViewScope managed bean would be a better fit to my project (in JEE6 this scope isn't available for @Named beans, only in JEE7). But there's two annotations named @ManagedBean: javax.faces.bean.ManagedBean and javax.annotation.ManagedBean. As I have to use the JSF one, I created a stereotype named <<JSFManagedBean>>.

I really don't think that it's valuable to show @EJB or @Inject unless it is really necessary for the understandment of you diagram.

<<@Asynchronous>> I'm using that on methods.

<<@PostConstruct>> I'm using that too and <<@WebServiceClient>>.

But my doubt regarding the use of annotations still remains.


I think that we can even create our stereotypes, since it is clear to understand. From my point of view the key is empathy, put yourself in the other person's shoes and imagine if you would understand well, if yes, it's ok.

I was thinking about create a glossary too, but after read the Olarte's reply I'm afraid about that now.

Additionally I have one doubt more. I think that it's crucial to show the scope of the EJB or Managed Beans (@Local, @LocalBean,@Remote, @ViewScoped, @SessionScoped). But I didn't see it in any example.
In all my beans I'm using two stereotypes: Stateless, LocalBean. In my controllers: ManagedBean, ViewScoped.

Are you putting that? Someone that has pass in the exam did put that?

Searching about hardware profile I found this class diagram that seems to be util http://spec.org/jEnterprise2010/docs/DesignDocumentation.html#A5 (scroll to the end).

Thanks!

[Mike Degteariov]

Hi Antonio,

Thanks for your input. I do not see much value in usingof "@Inject" stereotype for dependency injection dependencies,
but to be honest I see even less value in assigning of "uses" stereotype to each and every dependency, and I've seen
this kind of abuse in so many places - Cade's book and the resource you provided are just two examples.

Also, I like your idea of not using "@" prefix in from of stereotypes, I think that it will make the diagram more clear and more focused on the design, not on possible way of implementation.

Then, although I agree that it is an interesting idea on showing more than one stereotype for classes,
I have not yet seen it anywhere except the example you provided, and I am not even sure it is legal.
It would be great if someone from the community could clarify whether it is possible to put multiple stereotypes to the element.
Right now I do not think I will use multiple stereotypes.

Lastly, a question for you - does your solution have CDI beans that are not used as JSF backing beans ?
If you do, what stereotype do you use for this kind of beans ?

--
Thanks !

[Antonio Rafael Rodrigues]

Hi Mike.

I think multiple stereotypes are ok since all uml tools allow it, but I'm not sure if it's a good practice.
If you aren't going to use multiple stereotypes, what are you doing to show if your EJB will be local or remote? In my oppinion it's really important to show that, but I didn't see it in any example.
I don't have any CDI beans and I understand your doubt. If we are using annotations as reference to stereotypes the logical way would be a <<Named>> stereotype for CDI, but this word isn't clear at all. As I'm using <<JSF ManagedBean>> I think I would use <<CDI NamedBean>> or something like that, but never <<Named>>.

About the legality of multiple stereotypes: http://www.coderanch.com/t/463496/java-Architect-SCEA/certification/show-multiple-stereotypes

[Mike Degteariov]

Hi Antonio,

If you aren't going to use multiple stereotypes, what are you doing to show if your EJB will be local or remote? In my opinion it's really important to show that, but I didn't see it in any example.

All my stateless beans have no-interface view. I am going to specify this in comments to my class diagram.
If I had session EJBs with different kind of view in my solution (remote interface view, local interface view...) then it would make much more sense to put it to the stereotype, but in my case it would just add clutter.

[Antonio Rafael Rodrigues]

Hi Mike, thanks for reply.

I have already thought about doing in the same way as you. Define some kind of convention (all the ejbs are non-interface view except in the cases where it has a stereotype specifying other thing). Now that I know I'm not alone in the practice I'm going to do the same thing \o/.
Using the same theory, I'm going to make a note that the default stereotype for relationships between components (in component diagram) and classes (in class diagram) is <<use>> and then I could remove all these <<use>> stereotypes that make no sense for me.

[Andres Olarte]

Mike,

Regarding what stereotypes I used, here's a list:

ManagedBean
RequestScoped
Message Driven Bean
Interface
Enumeration
WebListener
Singleton

I think they're fairly basic, but give you an idea of the role each one plays. This is by no means a list of the ones you should use. It really depends.