Stereotypes in class diagram ?

[Vinay Singh]

Should the class diagrams have stereotypes which would give the examiner an idea to what these representation would lead to ? For eg if you have an object A and object B, object A might represent an enitiy which would be a database table but object B might be a class which performs some function or might be an EJB.
Cade follows this but he only mentions it for EJB.
If yes, then what possible stereotypes can come up in class diagram?Would the objects which would end up as table be represented as entity ?

[Paulo Asterio Nunes]

Dear Vinays,

I guess you can use any type of stereotypes and notes on your class diagram to clarify your decision, if you take this way you are making it easy for Sun or someone else who can be a possible customer get it better to understand what you was thinking when you made it.

Regarding constructing classes as a snapshot of your database table is not a good idea you can implement a composite instead.

I hope this help.
[ May 17, 2006: Message edited by: Paulo Nunes ]

[Paulo Asterio Nunes]

As you saw in Cade book he made his diagram using stereotypes on operations and on classes. I'm using RSA Rational Software Architect to create my class diagram and I'm putting as much documentation as I think would be useful even to my own understanding about the design. I'd strongly advise you to go ahead because stereotypes are totally possible in UML.

Anyone has more thoughts about it ?

[Vinay Singh]

Hi Paulo
Thanks for response.
1.I am not creating snapshot of database but the entities which are derived out of domain model might be translated into database tables for which I am using entity stereotype.As per policy we cannot discuss anything explicit about exam here but consider another common example of Sales , Product , Payment and SalesLineItem.
In this Sales & Product would be tables in the database and Payment & SalesLineItem might be Value Object.
Is this not correct ?
2.I am not sure what streotype we would use for classes which would be handling business logic and are not EJB.
BD talks to EJB but there might be classes behind that EJB who do some work (I am not in favour of putting 100% business logic in Session Beans). What would stereotype of these classes be ? I don't think they can be control but can they be boundary ?

[Vagner Freitas]

Vinays and Paulo,

The question isn't about if it is possible use stereotypes in class diagram.
Instead, the question is about making the class diagram technology independet or not. I have seen many ranchers making the class diagram only as an extension of BDOM (Business Domain Object Model) without any EJB.
What do you about it?

Vagner

[Paulo Asterio Nunes]

Vagner,

I'm not worried about making a class diagram technology independent and I'm using stereotypes to declare classes as EJBs, I think it's not worth because the requirement emphasizes that the most important thing is "the project must be J2EE" then I'm following this recomendation once our soluctions will be used only by certification purposes.

Do you agree with me ??? please let�s talk .

[Paulo Asterio Nunes]

Vinays,

Have you thought about making these classes as TOs and they may be handled by AppServices ? Your design probably migth work but it may have serious consequences of coupling and a harder maintenance then try make a design totally clear concerning which type of objects or layer does what. I think IMHO it would be better. On the other hand, you shouldn't be worried to give stereotypes to all classes in your diagram at all.

I hope this help, please let me know if you disagree and let�s discuss.
[ May 18, 2006: Message edited by: Paulo Nunes ]

[Vinay Singh]

Vagner & Paulo
In my opinion ,making class diagram technology independent is not that difficult.
And if you don't think about EJB at the begining, you can be more creative.
How I design the system (not only assignment but the real world also)-
1.From the requirements/SRS/Use case get all the valid objects(nouns) and link them together.What you get here is the object representation of the system or domain layer software classses. Lets say User is an object derived out of some requirements.
In design terminology User is the representation decompostion of the domain.

2.Going by one of the design principles Fabrication, assign a cohesive set of responsibilities to an artificial or convenience class for eg for an object User , you might have a class MyUserHelper which has method register user,delete user etc.
Now you see I am not assigning this responsibility to the object User which I could have but it would lead to poor cohesion or coupling and low re use potential.
So User becomes an entity for me which would be saved in database but through a different class. MyUserHelper class has thus been motivated by behaviorial decompostion


In technical terms after the request has been parsed, MyUserHelper class would be used to perform operations on User.
If I use EJB then this would be an EJB with some methods. If I use Spring then this would be a simple plain Java class with some methods.

This information if its an EJB or not can thus be put as stereotype.

So Paulo if this is an entity then it would be VO or TO and MyUserHelper would be AppService.
And Yes I agree not all objects should have stereotype. If you are sure specify it else leave it.

Cheers!!
Guys enjoy your weekend.
I am on rafting trip this weekend.Would come back rejuvenated on Monday!

[Vagner Freitas]

Vinays and Paulo,

I understand your view's point. But I am not sure that representing class like "MyUserHelper" in class diagram is the best approach. I actualy will model this in component diagrams. My class diagram will be composed only by entity class.

Vagner

[Paulo Asterio Nunes]

Vagner,

Are you putting only entity classes in your class diagram ??? Could you explain that ??

I'll appreciate that !

[Samuel Pessorrusso]

Originally posted by Vagner Freitas:
My class diagram will be composed only by entity class.

So do I.

I'm placing technology dependent classes in my Component diagram.

[Thomas Taeger]

Originally posted by Samuel Pessorrusso:
I'm placing technology dependent classes in my Component diagram.

- Do you explicitely show classes in your Component diagrams, i.e. white box view?
- Do you mix black box and white box view?
- Or do you provide a separate black box view?
- Most important: In which of the said diagrams do you show the classes that you needed in your Sequence diagram?

Thomas

[Vagner Freitas]

Paulo,

My class diagram is similar to the Cade's book figure 8.6, except that I didn't represent StatelessSessionBeans. And my component diagrams are similar to the Cade's book figure 8.8. In these diagrams I show the components envolved using stereotypes like JSP, Servlet, BusinessDelagate, ServiceLocator, StatelessSessionBean, EntityBean, etc. But I didn't show all componets in my component diagrams, for sample DTOs.
I didn't show classes in my component diagramas, and I show these components in my sequence diagrams as Cade's book figure 8.12. Of course may appear some components (like DTOs) in sequence diagrams that are missing in component diagrams.


Vagner

[Samuel Pessorrusso]

- Do you explicitely show classes in your Component diagrams, i.e. white box view?
=>Yes

- Do you mix black box and white box view?
=>Yes

- Most important: In which of the said diagrams do you show the classes that you needed in your Sequence diagram?
=> Component diagram, but I thing I will write two class diagram, one just to explain the framework and other extending the BDOM.

These are my answers, but I can change everything.
I've already written the class diagram and I'm starting the component diagram.


If you have got any comments, please reply.

Regards

[Thomas Taeger]

Hello Vinays,
first thank you for your elaborated answer.
One thing is not quite clear to me:

Originally posted by Vinays Singh:
This information if its an EJB or not can thus be put as stereotype. [...] if this is an entity then it would be VO or TO [...]

You would not stereotype the EJB to be a TO, would you?

A TO may come from an EJB, but different from an EJB it is _transferred_ (as its name sais).

"Transferring an EJB" would sound more as transferring a RowSet or ResultSet, transferring _all_ attributes.

TO typically transfers only those attributes that are needed for a specific use or a group of uses.

Did I understand you wrong?
Thomas

[Thomas Taeger]

Hello Samuel,

Originally posted by Samuel Pessorrusso:
So do I.
I'm placing technology dependent classes in my Component diagram.

Every component, technology dependent or not, must be shown in the component diagram, ok.

But that does not automatically mean the other way round that this is sufficient.

Class diagrams are diagrams with classes you can point to to explain something. Otherwise you would provide a component diagram and some sequence diagrams only.

So you may be right in hiding EJBs (for any reasons, not just for technology dependency) from the class diagram - but only if there is another class or better interface in the class diagram that takes the role that you want to talk about and that would otherwise be represented by e.g. the EJB.

That is where interfaces come in. Everybody knows that an interface must be implemented somewhere, at the latest by a component of the component diagram. So just provide the business interface instead of the EJB, but do not provide nothing. Your component diagrams will highly benefit from introducing interfaces as well.

Technology independenca may be one goal,
not making class diagrams useless must be the main goal.
Interfaces are the glue between both goals.

Thomas

[Vinay Singh]

Thomas
I did'nt meant that.What I wanted to say was that if we model an object in class diagram it could be an entity or an EJB or some helper class.
If we think that an object would be Session Bean we define the stereotype as <<SessionBean>>.
If an object is an entity we classify that as <<entity>> stereotype. What is an entity would translate into an Value Object or Transfer Object in actual world in java.
I hope I am clear now.
Sorry for the confusion!

Referring to your second post in which you talk about interfaces, I do agree that component diagrams would benefit a lot by interfaces.But I am also of opinion that derive interfaces from the domain model in class diagram.Along with this when you are using EJB's and DAO , you implement them through interface.
My questions are
1. DO we show all the interfaces and their realizing classes (domain as well as EJB) in the component diagram ?
2.If not then do we depict the interfaces and their classes in sequence diagram ?
3. Do we also represent To & VO also in component diagram ? Won't it be too cluttered ?
Cheers!!