Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

what stereotypes are allowed in class diagrams

 
Tomasz Romanowski
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is not clear to me what stereotypes are allowed in class diagrams. I want to flag one of my classes with a <<DataTransferObject>> stereotype but I've come across a few statements that make me believe that UML 2.0 specifies what stereotypes are allowed in class diagrams which would make it illegal to use anything beyond the defined set.
Martin Fowler's book "UML Distilled Third Edition", page 66 reads:
"In UML 2, stereotypes are defined very tightly, and describing what is and isn't stereotype is beyond the scope of this book". The wiki page http://en.wikipedia.org/wiki/Class_diagram lists only three stereotypes, Boundaries, Entities, Controls. Not sure if this is a complete set or not.
 
Tomasz Romanowski
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The more I'm reading up on this the more confused I am. Both the wiki page http://en.wikipedia.org/wiki/Class_diagram ad well as http://www.developer.com/article.php/2206791 are referring to "Analysis Classes".
From what I see "Entity" and "Controller" in that context means something completely different from what I'd call it. They say that Entities contain business logic whereas Controllers don't contain any business logic but merely transfer the control to the appropriate business logic (Entity?) class. My understanding of a controller and an entity is that an entity represents a domain object (i.e. customer, order item etc) whereas a controller woudl be a business logic class very likely to be mapped to a stateless session bean.
Thoughts?
 
Maverick Grotto
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tomasz Romanowski wrote:It is not clear to me what stereotypes are allowed in class diagrams. I want to flag one of my classes with a <<DataTransferObject>> stereotype but I've come across a few statements that make me believe that UML 2.0 specifies what stereotypes are allowed in class diagrams which would make it illegal to use anything beyond the defined set.
Martin Fowler's book "UML Distilled Third Edition", page 66 reads:
"In UML 2, stereotypes are defined very tightly, and describing what is and isn't stereotype is beyond the scope of this book". The wiki page http://en.wikipedia.org/wiki/Class_diagram lists only three stereotypes, Boundaries, Entities, Controls. Not sure if this is a complete set or not.


Interesting question.. I am not sure what the true UML norm is but I have come up with my own stereotypes in the past. However I must say that I have been rather cautious in coming up with new stereotypes.. I try using stereotypes that are commonly understood by the community in general.. and if not, I do provide an explanation of what the steretype means.

In the example you provided <<DataTransferObject>> is a commonly understood design pattern and you might be OK to use it as a stereotype.
 
Maverick Grotto
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tomasz Romanowski wrote:The more I'm reading up on this the more confused I am. Both the wiki page http://en.wikipedia.org/wiki/Class_diagram ad well as http://www.developer.com/article.php/2206791 are referring to "Analysis Classes".
From what I see "Entity" and "Controller" in that context means something completely different from what I'd call it. They say that Entities contain business logic whereas Controllers don't contain any business logic but merely transfer the control to the appropriate business logic (Entity?) class. My understanding of a controller and an entity is that an entity represents a domain object (i.e. customer, order item etc) whereas a controller woudl be a business logic class very likely to be mapped to a stateless session bean.
Thoughts?


I see analysis classes as a rough draft or in other words a precursor to the final detailed design. The analysis classes tend to be centered around the conceptual business model.
When we delve more into the details of the actual business solution, the other components like the controllers and managers that work with the analysis classes aka domain classes take shape.

Controller in my mind is a component that might encapsulate the entire business logic. To accomplish its task, it might delegate to another business component which might be an EJB, POJO or SERVLET.

Entity as you said represents the business domain object but it also means that this object manifests itself in the database via persistence.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic