Should I include getters & setters in class diagram?
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.
It wouldn't be appropriate to include them. You can just add one line saying accessors methods