Username must be unique and can't be changed in Mastermind

Question

I'm designing a UML class diagram for a Mastermind game and I'm having trouble figuring out how to make the attribute 'Name' unique and not changeable. I'm assuming that I do this by naming the 'Name' attribute private and show it in the class diagram as well. Any sort of help would be highly appreciated. Thanks

Answer 1

As per Python you can only indicate private attributes by adding an underscore in front of the name. Language-wise this is not a language construct but a convention. UML does not care since it's language-agnostic. Model it as private (by showing the - in front of the name). If you are generating code from that UML model the code generator might create the underscore automatically.

In any case, if you create a model with UML and indicate something to be private then the coder for the language must take care. For a closed implementation you just need to train your coders. For an open (library) implementation Python will let you stand in the rain with that.

Answer 2

In short

Since you're looking for the UML notation more than the Python aspects:

More explanations

Not changeable

UML has read-only properties annotated with a {readOnly}. The specifications define the semantics:

If a StructuralFeature is marked with isReadOnly true, then it may not be updated once it has been assigned an initial value. Conversely, when isReadOnly is false (the default), the value may be modified.

UML does however not tell how the initial value is provided. If it's a private property, you'll probably provide the initial name to the constructor. Showing it (with a preceeding «create») will clarify the ambiguity.

Unique

It is likewise possible to indicate {unique} for a property. However, this makes only sense for multivalued properties because it means that there are no duplicates values among the multliple property values of the same object. You'll probably have somePlayer object with a single Name: it then makes no difference if you add {unique} or not.

If you have somewhere a Game associated with two Players you could put a {unique} on the association-end to say that its two different player, but nothing would prevent them having the same name. Fortunately, there are two preagmatic solutions:

• Add a natural language constraint to the association, e.g. { player names must be unique }. The advantage is that is clear an unambiguous for human readers. You could translate this into a more formal OCL expression but it's like double coding: onces in OCL and once in Python.

• Add {id} after the name, to tell that the name is the identifier for the class. Identifiers are in principle unique within the class. However, although most readers will understand this, it is ambiguous, since UML does not define the semantics of identifiers:

  A Property may be marked, via the property isID, as being (part of) the identifier (if any) for Classifiers of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML.

  Moreover, this would prevent two players of a different game having the same name.

On the diagram, I showed both alternatives, but IMHO you should not use id if it has no clear benefits.