Menu
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?
548
Getters and Setters play an important role in retrieving and updating the value of a variable outside the encapsulating class. A setter updates the value of a variable, while a getter reads the value of a variable.
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".
In general, they should be public. If they are private they can only be called from within your class and, since you already have access to the private variables within your class, are redundant. The point of them is to allow access to these variables to other, outside, objects.
To answer your questions in one word, yes. Having a class call its own getters and setters adds extensibility and provides a better base for future code.
It wouldn't be appropriate to include them. You can just add one line saying accessors methods
129
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.
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
