• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to represent "final" modifier in UML?

 
Justin Chu
Ranch Hand
Posts: 209
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As subject.

I've a method with "final" modifier so that subclasses cannot not override.

What's a good way to represent this on UML?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Justin Chu
Ranch Hand
Posts: 209
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jan Cumps
Bartender
Posts: 2602
13
C++ Linux Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Regards, Jan
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Where can I learn more about it?
 
Jan Cumps
Bartender
Posts: 2602
13
C++ Linux Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:


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.

Where can I learn more about it?


I meant property. I was already happy that I could remember the word leaf.
In, the UML User Guide, 2nd edition, it's mentioned and explained in chapter 9, on page 123:
getID( ) : Integer {leaf}

Regards, Jan
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Unified Modeling Language Reference Manual 2e (2004) (amazon US)(p. 434):

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.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Being a leaf or being constrained to be a leaf are not fundamental semantic properties but rather software engineering mechanisms to control human behavior.


Wow, I like that! We try to control human behavior of people who might mess up our fine designs all the time but I haven't seen it stated quite so plainly very often.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
final is definitely about enforcement and has been subject to a great deal of controversy.
E.g.
M. Feathers: It's Time To Deprecate Final
E.R. Harold: Final == Good
E.R. Harold: Eliminating Final

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.

Model-Driven Development: One Curmudgeon's View - Why won't the general purpose language be graphical?

it was simply faster to write code�

Computers don't do big picture.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic