First, I'd wonder whether you really need to depict the final modifier. Will it be critical to what you want to communicate to your audience?
Even if it is, I'm not aware of any official notation. I'd probably use a final stereotype, or something. Again, the exact approach would depend on the purpose of the diagram and the target audience.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Apr 19, 2002
Thanks! I'm documenting a class that is using the "template method" pattern, so subclasses should not override the "driving" methods. It is analogous to Thread's start() and run() method. I'd like to stress that start() method should not be overridden.
Originally posted by Chu Tan: Thanks! I'm documenting a class that is using the "template method" pattern, so subclasses should not override the "driving" methods. It is analogous to Thread's start() and run() method. I'd like to stress that start() method should not be overridden.
I think the "Leaf" stereotype is what you're looking for. This indicates the very last possible child. You can't inherit further.
OCUP UML fundamental and ITIL foundation
Joined: Jul 11, 2001
Originally posted by Jan Cumps:
I think the "Leaf" stereotype is what you're looking for.
It's the first time I hear of a "leaf" stereotype. If had seen it on a method, I wouldn't have known what it meant.
leaf A generalized element that has no children in the generalization hierarchy. It must be concrete (fully implemented) to be of any use. See also abstract, concrete. Semantics The leaf property declares that an element must be a leaf. The model is ill formed if it declares a child of such an element. The purpose is to guarantee that a class cannot be modified, for example, because the behavior of the class must be well established for reliability. The leaf declaration also permits separate compilation of parts of a system by ensuring that methods cannot be overridden and facilitating inlining of method code. An element for which the property is false may indeed be a leaf for the moment, but children may be added in the future if the model is modified. Being a leaf or being constrained to be a leaf are not fundamental semantic properties but rather software engineering mechanisms to control human behavior.
That last sentence though seems to be a weak attempt to provide a justification for such a feature in a modeling language. In my opinion, leaf (like many other of UML's dustier corners) was only introduced into UML for tool makers who needed a model level concept that was equivalent to final for their code generation, reverse engineering, and roundtrip engineering products. The value that a concept like leaf adds to UML as a modeling language is dubious and it certainly can make UML more heavy weight. You only need 20% of UML to use it - but apparently a much higher level of competence is required to use a UML tool (that is trying to sell its code reverse engineering and generation features).
If you have to provide that much low level detail to your modeling tool then you are in fact programming - and you are potentially obfuscating the grand idea of your overall model.