I am required to draw a class diagram for my JSF application for a project documentation. So I have lots of classes as managed beans, with many attributes therefore many getters and setters.
When I draw the class diagram should I also include the getters & setters in the diagram or can I simply leave them?
It wouldn't be appropriate to include them. You can just add one line saying accessors methods
Including getters and setters would be a bad idea. They are wasting "real estate" to duplicate information that is already shown in the attribute / property section of the class.
Other answer suggest that the UML diagram needs to document "unusual" visibility of Java getters and setters, or "special" behavior in getters and setters.
I guess in some cases that could be justified. However, I would counter that:
A UML diagram doesn't need to show everything. Only the important things. Indeed, one of the signs of a good UML diagram is that it isn't cluttered up with unimportant things. So these details should only be included if they are really important.
The fine details of the abstraction boundaries are generally not the concern of the design. A Java programmer should just know the basics of how to implement abstraction / encapsulation when it is needed. Furthermore, the programmer will most likely have a better insight into situations where "porous" abstraction boundaries are needed; e.g. for performance reasons. (UML is not designed to express that kind of thing.)
The precise behavior of fields and methods is generally not the concern of the UML design documents. (Unless the designer is also going to go to the length of specifying methods' preconditions, postconditions and invariants in OCL!) However, if a UML diagram needs to say that a field can never be null, or that getting a field increments a counter, you should be able to describe that as comments (or OCL constraints) on the field.
Finally, the UML diagram should not be the only technical documentation for the software. The javadocs automatically document the access modifiers / visibility of methods and fields. Likewise, if the programmer has implemented getters and setters with "special" behavior that needs documenting, this should be described in the javadoc comments.
You should not include getters and setters in your diagram until they do something special: null checking and so on. But it is a sign of bad design, so general answer is "No, you should not".
UML is a rather informal notation, the best would be to first set the rules you going to use at your project or organization. For instance, it is usual to hide getters and setters, but sometimes it is important to show all details. A rule could be such as:
if your property is implemented with a private variable and a pair of getters and setters with the same visibility, you just create a property with this visibility.
if your property is implemented with a private variable, but the getter and setter has distinct visibilities, such as a public getter and a protected setter, it would be advisable to show the getter and setter in the model.
and so son...
It may be useful to make the getter/setter convention explicit for the properties concerned by creating your own «get/set» and «get» stereotypes to be used for categorizing these private properties. See my answer to Shortcut for denoting or implying getters and setters in UML class diagrams.
