Part 2: UML Questions

[pin guan wang]

Hi all,

I have some UML questions here related to part 2:

1) Class diagram - For a "has a" relationship, if an JPA entity "Customer" has an "Address" entity, the Address will be one of the attributes for the Customer class. However, I have seen a lot of class diagram samples online, for example, the Flight and Plane example in this link: http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/ , the "Plane" object does not appear in the "Flight" attribute list.
In that case, do I need to show the "Address" object in the "Customer"'s attribute list?


2) Class diagram - I have not seen any class diagram example which shows classes which are EJB stateless bean, DAO, Managed bean, etc. I think we still need to include these classes in the part 2 class diagram, but anyone has seen some examples online? If yes, could you share it here?


3) Component diagram - How should I determine a component? If I have an Auction system, the "Payment service" can be a component, the "Payment Account" also can be a component. Any idea how?


Thanks in advance.

[Aditya Kumar]

Hi Wang,

#1 - You are here dealing with a confusion about how to deal with a property. What you have mentioned are both ways of property notation 1) Showing it as attribute (in the class box itself) 2) Showing it as an association. You can choose either of the ways. You do not need to show it using both ways. How I did it was that you can choose the important classes to show as a association and the lesser important ones (and the primitive ones) as attributes. if you look closely that is what the IBM example about Flight/Plane has done as well. I will recommend you to also lookup Martin Fowler's UML Distilled, page 37 for further reading.

#2 - This should be an easy problem to tackle. I suggest you read chapter 9 of Cade's book. It clearly shows an example assignment depicting the @stateless and @entity classes. You just need to decide what stereotype to use. Yes, you are also right about including these classes in the class diagram.

#3 - About the components, well there are more than one ways of doing that. A good way (I think) is to first determine the tiers of your application and decide what classes reside in what tier. I did it like that. Once I was done with that segregation, I broke down the tiers further with sub-systems and the components within. For example, if there are some classes (stateless bean(s)) in the business tier that take care of user account related details, for me that is a subsystem and the classes within that could be the components. I also showed a component as "helper classes" (there are, inevitably). If there are another bunch of classes (interface + EJB) that deal with accomplishing a transaction for an entity at the business tier, that is another sub-system having components. I think if you google around and also search some of the archives of this forum, you will have an idea about this.

In any case, I suggest you to read Fowler's UML Distilled - specially for the class diagram and the sequence diagrams. I hope this was helpful.

Thanks,
Aditya

[pin guan wang]

Hi Aditya,

Thanks for your detailed explanation, please refer to my followup questions below:

Aditya Kumar wrote:
#2 - This should be an easy problem to tackle. I suggest you read chapter 9 of Cade's book. It clearly shows an example assignment depicting the @stateless and @entity classes. You just need to decide what stereotype to use. Yes, you are also right about including these classes in the class diagram.

What is the full name of Cade's book?

Aditya Kumar wrote:
#3 - About the components, well there are more than one ways of doing that. A good way (I think) is to first determine the tiers of your application and decide what classes reside in what tier. I did it like that. Once I was done with that segregation, I broke down the tiers further with sub-systems and the components within. For example, if there are some classes (stateless bean(s)) in the business tier that take care of user account related details, for me that is a subsystem and the classes within that could be the components. I also showed a component as "helper classes" (there are, inevitably). If there are another bunch of classes (interface + EJB) that deal with accomplishing a transaction for an entity at the business tier, that is another sub-system having components. I think if you google around and also search some of the archives of this forum, you will have an idea about this.

Do you mean that in your example, "User Account" is a component in the component diagram?


Thanks again

[pin guan wang]

Aditya Kumar wrote:
#1 - You are here dealing with a confusion about how to deal with a property. What you have mentioned are both ways of property notation 1) Showing it as attribute (in the class box itself) 2) Showing it as an association. You can choose either of the ways. You do not need to show it using both ways. How I did it was that you can choose the important classes to show as a association and the lesser important ones (and the primitive ones) as attributes. if you look closely that is what the IBM example about Flight/Plane has done as well. I will recommend you to also lookup Martin Fowler's UML Distilled, page 37 for further reading.

Are you referring to Martin Fowler's UML Distilled 3rd Edition or 2nd Edition ?
If I am showing it as an attribute, do I need to draw a line to link it to the actual object? For example, I have added an "Address" class as attribute in my "Customer" class, do I still need to draw a line from "Customer" class to "Address" class ?


Thanks again

[Aditya Kumar]

Hi Wang,

Are you referring to Martin Fowler's UML Distilled 3rd Edition or 2nd Edition ? If I am showing it as an attribute, do I need to draw a line to link it to the actual object?

I referred to the 3rd edition. Your doubts are addressed on page 37. You can do either ways, as I said. Generally the more important object types are shown as a class box. So then you will need to connect the two with a line. If you do that, you do not need to show them as attributes in each other's box - that would be redundant information. You can show the primitive types (and some other lesser important objects) as attributes.

What is the full name of Cade's book?

Sun Certified Enterprise Architect for Java EE Study Guide by Mark Cade, Humphrey Sheil. Google it. This book was meant for the JEE 5 version of the test but you can still refer to chapter 9 and 10 as the assignment is common for OCMJEA 5 and 6.

Do you mean that in your example, "User Account" is a component in the component diagram?

No. At least not with that name. For example, you have some code in your project which deals with user authentication/user profile information. So "Generic User Logic" becomes your sub-system. And say, there is one SLSB -- that is the class where most of the user-fetching business logic is present, that SLSB could be a component in that sub-system. Now, there are a few helper classes for that SLSB - some have a business calculation or maybe some have SQL queries required by the main SLSB - those become the helper classes and they together can be a component. So your "Generic User logic" sub-system then has these two components. You should take a look at this example here: UML Component diagram.

I hope this helped.
Aditya

[pin guan wang]

Hi all,

Sorry, I have more class diagram questions:


1) For stereotype for classes, is it completely alright to create my own stereotype, for example, is it ok if I have stereotype like <<Stateless Session Bean>>, <<Interceptor>>, <<JSF Managed Bean>> ?

2) Mark Cade & Humphrey Sheil's book also represent stateless session bean like "BidManager (@Stateless)" and entity class like "Bid (@Entity), is this the correct way of representation?

3) I have seen Mark Cade & Humphrey Sheil's book adding JSP files into the class diagram, should I include JSF (.xhtml files) into my class diagram?

4) Do we need to add getters and setters methods into the classes? I have read the below article where it mentioned it is redundant to include them. Are getters and setters unnecessary?
http://stackoverflow.com/questions/5242133/should-i-include-getters-setters-in-class-diagram


Thanks

[pin guan wang]

pin guan wang wrote:Hi all,

Sorry, I have more class diagram questions:


1) For stereotype for classes, is it completely alright to create my own stereotype, for example, is it ok if I have stereotype like <<Stateless Session Bean>>, <<Interceptor>>, <<JSF Managed Bean>> ?

2) Mark Cade & Humphrey Sheil's book also represent stateless session bean like "BidManager (@Stateless)" and entity class like "Bid (@Entity), is this the correct way of representation?

3) I have seen Mark Cade & Humphrey Sheil's book adding JSP files into the class diagram, should I include JSF (.xhtml files) into my class diagram?

4) Do we need to add getters and setters methods into the classes? I have read the below article where it mentioned it is redundant to include them. Are getters and setters unnecessary?
http://stackoverflow.com/questions/5242133/should-i-include-getters-setters-in-class-diagram


Thanks

I think one of the difficult part for UML is that different sources (web site or books) are using different ways of drawing for some of the notations.

[Aditya Kumar]

Hi Wang,

There is no standard set of rules for stereotypes. I strongly suggest that you do a search of the old archives of this forum and see what other people have used. In any case, you can always use what the Mark Cade & Humphrey Sheil's book suggests as it is the official guide of the exam.

I have seen Mark Cade & Humphrey Sheil's book adding JSP files into the class diagram, should I include JSF (.xhtml files) into my class diagram?

One word answer: Yes. Long answer: I personally am not in favour of having those files in the class diagram but that seems to be the standard practice and that is also what Oracle expects so yes, display technology files should be there in class diagrams.

Do we need to add getters and setters methods into the classes

No, I think it is a bad idea and it would serve no purpose.

As far as UML diagrams are concerned - I suggest you take the examples in the Cade and Sheil Book to be your guiding light. You need to ensure that you use UML2 notation. I think you are over-analyzing this. As long as your UML diagrams are UML2 compliant and you follow generally acceptable UML standards like the one found in Martin Fowler's book, you should be OK. Remember - the real hard work is the architecture and design. The UML is just a way of representing your thoughts.

Thanks
aditya