stereotypes and annotations

[Ronald Wouters]

Hi all,

is there a recommended set of JEE 5 stereotypes out there somewhere ? If not I am inclined to use stereotypes that correspond to the annotations being used in the pojo's like :
<<Stateless>>, <<WebServiceRef>>, <<Entity>>, ... you get the picture.

Regards.

[Hong Anderson]

UML is a unified, and by design extensible language.

Profile is one of UML extension mechanism. You can create a Profile that contains many stereotypes (or just create stereotypes), and use it in your project. It's absolutely correct.

[Amar Thia]

Hi Kengkaj/Ronald,
This is further extension of the question on annotations and streotypes.

How about annotations that are attached to methods? For example: I need to specify two annotations @TransactionAttribute(REQUIRES_NEW) and @RolesAllowed("Onlyme") for one of my methods.

Sequence Diagram:
I had specified the two attributes as notes in the sequence diagram. Is this ok or is it better to specify these attributes with stereotypes such as

<<TX: REQUIRES_NEW>>

and

<<ROLES: Onlyme>>

Class Diagram:
Do I specify the method in the Class diagram as

+ somemethod() : void {TX: REQUIRES_NEW; ROLES: Onlyme}

What do you think?

Thanks,
Amar.

[J J Wright]

How about annotations that are attached to methods?

You could argue the case for using a guard condition when it comes to transactions and security constraints. After all, these are conditions that must be met for the operation to be callable.

That said, I'd have serious reservations about going into that kind of detail when it comes to documenting an architecture. Does it add real value to your diagrams from an architectural perspective?

[Amar Thia]

Does it add real value to your diagrams from an architectural perspective?

From an NFR perspective, the choices that we make in the design will affect the outcome - atleast for transactions. Refer the Writing Performant EJB Beans in the Java EE 5 article from Sun.

You could argue the case for using a guard condition when it comes to transactions and security constraints

What is the replacement for guard in UML 2? Per Martin Fowler, there is no guard condition in sequence diagrams in UML2 - Refer "From UML 1.x to UML 2.0" in "UML Distilled".

[J J Wright]

From an NFR perspective, the choices that we make in the design will affect the outcome - at least for transactions.

I appreciate what your saying; my point is that these details are more implementation than architectural in nature. Of course, the best design in the world may still fall over if not implemented correctly. However, I still believe, and this is only my opinion, that going into excessive detail during the architectural modeling phase is wrong. Modeling at this level should be about eliciting good OO design. Documenting programming details seems very un-agile and waterfall-like. By making diagrams excessively detailed you may well be limiting their lifespan, and hence usefulness, as requirements evolve throughout the lifespan of a project.