6

What is a good practice to model Python properties in a UML class diagram? Properties themselves are class objects, their getter and setter are class functions. From Outside the class they look like instance attributes. So, how would you suggest to present that in my class diagram?

bad_coder
  • 11,289
  • 20
  • 44
  • 72
Robert_Jordan
  • 256
  • 4
  • 13
  • Welcome to StackOverflow, @Robert_Jordan. If you found an answer to your question, please consider [accepting it](http://meta.stackexchange.com/q/5234/179419) (by clicking the check-mark), and consider up-voting it (by clicking the up arrow). Accepting an answer indicates to the wider community that you've found a solution, gives yourself some reputation points, and gives some reputation points to the person who answered your question. If you did not find a satisfactory answer to your question, please leave a comment. – Jim L. Mar 25 '16 at 02:59

3 Answers3

2

I recommend you read UML Best Practice: Attribute or Association, by another Stack Overflow user named Geert Bellekens. It states simply:

Use Associations for Classes and Attributes for DataTypes.

You should write the Python attributes that are typed by non-datatypes (which have identity) at the ends of UML associations connecting to those UML classes. You should write the Python attributes typed by simple datatypes (which have no identity other than their value) in the UML class' attribute box.

The accessors and mutators are largely just noise. A model compiler or IDE can generate those for you.

Community
  • 1
  • 1
Jim L.
  • 6,177
  • 3
  • 21
  • 47
1

Good practice is what works on your project.

In order to model Python properties you can add stereotyped getter and setter operations which indicate their use. The link between attribute and operation is usually done via a naming convention. Some tools offer internal linkage to make attributes properties with getters and setters.

If you are not using code generation you can also stereotype the attribute to indicate their use as properties (thus telling the coder to use @property) and leave away the operations. If you are using your own code generator this would work analogously. Tool embedded code generators might need the additional operations as described above.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
0

It really depends what kind of template your UML tool uses. In some tools there is a Properties box along the common Attributes and Methods boxes. The UML notation states that attributes are written in lower camelcase, you could write properties in upper camelcase. They would also differ visually because of the public access modifier (+).

Do you have the need to specify different access modifiers for the getter and setter? Im not sure how i would go about that. Keep in mind the level of abstraction necessary.

Remember that UML is mainly a set of defined standards. If the standard needs a slight tweak to fit your needs dont hesitate. The important thing is that your team and stakeholders understand the syntax.

LuqJensen
  • 310
  • 6
  • 14
  • Well no different access modifier, all public, if one can they so in python. I will go with your last point... thank you! – Robert_Jordan Mar 23 '16 at 12:19
  • In UML, an attribute is the same thing as a property, which makes your third sentence conflict with itself. Can you clarify what you mean? Moreover, UML does not state that attributes are written in lower camel-case, or anything else about how to write the names, for that matter, other than a legal character set. – Jim L. Mar 23 '16 at 15:19
  • You are correct about the UML attribute vs property Jim L. However i have seen a couple of tools where it is possible to define a box for each, as it is not defined in a template. Given Umlet or another free draw tool, you could make boxes for both attributes (fields in this case) and properties (like the ones found in py3, js and c# etc). So it really is up to oneself to define what is necessary to produce clear cut communication. – LuqJensen Mar 23 '16 at 20:04
  • If you use a non-UML drawing tool, you can do anything you like. The original question was how to model Python properties in a *UML* diagram, not an arbitrary drawing tool. The whole point to UML is communicating with a common vocabulary. – Jim L. Mar 24 '16 at 02:13
  • Umlet and many other tools are UML drawing tools, but do not necessarily restrain _everything_. – LuqJensen Mar 24 '16 at 18:18