I am designing a class diagram for scrabble game. In one of the classes, I have final variable declared. Can anybody tell me, how can I indicate a variable as final in the UML class diagram?
There are different notions of final that are all represented in different ways:
final definition, i.e. it cannot be overridden in sub-classes - this corresponds to the isLeaf property of the attribute:
The isLeaf property, when true for a particular RedefinableElement, specifies that it shall have no redefinitions. - UML 2.5 specifications, page 99
There is no official notation anymore for attributes with isLeaf=true; adding {leaf} was the former official notation (UML 1.x) and it is still common.
final value, i.e. its value cannot be changed - this corresponds to the isReadOnly property of the attribute:
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 2.5 specifications, page 106
Notation for read-only attributes consists of appending {readOnly} to the attribute string.
constant usually refers to a non-changeable attribute of the class itself instead of an instance (static final attribute). In UML it would have both properties mentioned above and additionally be static, which corresponds to the isStatic property:
The isStatic property specifies whether the characteristic relates to the Classifier’s instances considered individually (isStatic=false), or to the Classifier itself (isStatic=true). - UML 2.5 specifications, page 105
Static attributes are indicated by underlining the attribute definition. Constants, as already mentioned are usually UPPERCASE, but that's just a convention.
So, to sum it up, a constant attribute FOO of type String with value "x" would look like this and be underlined in addition (which isn't supported here):
+ FOO : String = "x" {readOnly,leaf}
Constant (i.e. final) fields are indicated via naming convention:
constants should be in ALL_CAPS
Source
Declaring a variable/attribute final is implementation detail. So you don't need to specify it in your CLASS Diagram but you can follow the convention as suggested by eboix.
UML specification doesn't say anything specifically about it; so you can follow convention of showing it in ALL CAPS.
Related
(While this question is tagged with annotation-processing I'm actually asking questions about the type model exposed by javax.lang.model whether or not annotation processing is involved.)
In javax.lang.model, there are two fundamental constructs: Elements and TypeMirrors.
Every Element is backed by a TypeMirror. However only certain TypeMirror subtypes, namely DeclaredType and TypeVariable, have Elements associated with them via DeclaredType#asElement() and TypeVariable#asElement() respectively.
(It follows that all Elements "have" TypeMirrors, but not all TypeMirrors "have" Elements.)
Speaking loosely and intuitively, this makes sense: you declare types by chanting certain Java spells: the spells themselves are the (declared) elements; the things they bring into being are the types that back them. I've programmed in Java for decades and have a good working familiarity with oddities like Foo implements Comparable<Foo>. I'm trying to get more rigorous here.
With all that in mind, and considering the following snippet, how are the javax.lang.model types and elements manifested?
// (Defined by the JDK itself of course.)
public interface Comparable<T> ...
// (My class.)
public class Frob implements Comparable<Frob> ...
I see the following "things", working from "top" to "bottom" with less and less certainty as I go along:
a TypeParameterElement whose affiliated Name is equal to "T"
The return value of its asType() method will be a (definitionally nameless) TypeVariable whose asElement() method will return the TypeParameterElement currently being discussed.
The return value of its getGenericElement() method (and its getEnclosingElement() method) will be the Element we'll talk about next ("Comparable").
a TypeElement whose affiliated Name is equal to "Comparable"
The return value of its asType() method will be a (definitionally nameless) DeclaredType whose asElement() method will return the TypeElement currently being discussed
The DeclaredType so returned will have exactly one type argument which will be the (definitionally nameless) TypeVariable discussed above whose asElement() method will return the TypeParameterElement discussed above ("T")
The return value of its getTypeParameters() method will consist solely of the TypeParameterElement discussed earlier.
a TypeElement whose affiliated Name is equal to "Frob".
(This TypeElement is brought into being with the Java syntax public class Frob ....)
The return value of its asType() method will be a (definitionally nameless) DeclaredType whose asElement() method will return the TypeElement currently being discussed.
The return value of its getInterfaces() method will be discussed in a moment.
an Element of some variety loosely described by "Comparable<Frob>".
I say "of some variety" because as written it itself does not have, say, an explicit or implicit extends or implements clause, or other markers I would expect to see of, say, a TypeElement. Nevertheless I'm not sure that it could be any other kind of Element other than a TypeElement. Maybe it is a TypeElement equal to that denoted by "Comparable<T>", but with its various TypeMirror-returning or -referencing methods using the type denoted by Frob?
The return value of its asType() method will be a (definitionally nameless) TypeMirror of some variety (almost certainly a DeclaredType) whose asElement() method will return the Element currently being discussed (this corresponds somewhat to java.lang.reflect.ParameterizedType in the runtime/reflection model)
The TypeMirror so returned will have exactly one type argument which will be the (definitionally nameless) DeclaredType returned by the asType() method of the TypeElement whose Name is equal to "Frob" described above
The TypeMirror so returned will be the sole member of the return value of the getInterfaces() method when invoked on the TypeElement whose Name is equal to "Frob" described above
Do I have this right as far as it goes?
Your question seems well-reasoned, and I can't find anything specifically wrong with it to point out to you, but it is missing the one vital truth of where Elements and TypeMirrors differ.
Elements represent nodes in the Java type AST that reside "on disk" - the code at rest, either in .java or .class files. Any class/interface/enum/record/annotation that exists on disk in this form is in some way discoverable by this. To get a bit further, these cover the entire API of any of those types above - any members (fields/constructors/methods or nested types, then also the params of those methods/ctors) and packages too are described by elements. But the Element hierarchy only covers the types on disk - to use a concrete example from your question, Comparable<T> and its Comparable<T>.compareTo(T) member, and that method's parameter are covered in this way. And yes, lest I omit the type parameter, both the class and the method have a type param embedded in their respective element - as an element.
On the other hand, TypeMirrors represent those elements "in use" - you can't really reason about Comparable<T> in your code, but instead will either use it raw (please don't), or will parameterize it in some specific way (such as Comparable<Frob>, Comparable<?>, or possibly Comparable<T> where T is the type param of an enclosing element such as the current method or class). This means that T is not the same TypeElement as above - it isn't the value of the TypeElement that was on disk, but is something more specific.
You'll find TypeMirrors in Elements (for example "what is the return type of the method that appears in this class?"), and all Elements can be converted to some form of TypeMirror. On the other hand, not all TypeMirrors can be converted to some Element (such as a primitive), or if they can, that conversion may be "lossy" (for example converting a TypeMirror of List<String> to an Element would give you only List<T> itself).
I want to describe some models of an API in a diagram. Is there a standard how to mark an attribute as readonly? These attributes are set by the system and cannot be modified by the API consumer.
Currently I abuse the class diagram notation for private and public attributes. But I am not satisfied with this.
Thanks for your thoughts :)
The usual way when you interface coding you would make private properties and use getter/setter operations. You could also leave it on a more abstract level and simply stereotype them with <<readonly>> or <<r/o>>. And finally you could use an appropriate getter method.
Edit The current UML 2.5 spec states on p. 17
Attributes: each specified by its name, type, and multiplicity, and any additional properties such as {readOnly}.
An example on how to use this is found on p. 113:
public abstract class Shape {
abstract int area();
}
How do we draw the UML class diagram for the abstract method? Use +, - or #?
public class Room {
int nWindows;
}
And what if the class instance variable doesn't have public, private or protected?
Abstract
According to UML specification:
The name of an abstract Classifier is shown in italics, where permitted by the font in use. Alternatively or in addition, an abstract Classifier may be shown using the textual annotation {abstract} after or below its name.
Note however that Operation is not a Classifier. It still has an isAbstract attribute as a BehavioralFeature but 2.5 specification does not define how to model the fact of being abstract. Older specifications (1.4.x) were using the same method as for Classifiers and it is a widely recognized method to show operation abstraction. Note only that the elements in curly brackets for features are presented at the end of line rather than just after the name (Classifier simply has no other specification directly after name).
Possibly authors made an omission in 2.5 specification for Feature abstraction notation by a mistake.
An abstract operation can of course have any visibility kind.
Of course the operation might be abstract only if its containing Classifier (Class in your case) is also abstract.
No visibility kind
In general visibility kind in UML is optional i.e. you can simply omit it. Just take into consideration that UML is a model so it actually can ignore some irrelevant elements or can specify them at a later stage of modelling. Not using any visibility kind in UML does not allow you to make any assumption about it's final visibility kind.
On the other hand if in actual code you use no visibility kind specification (if allowed at all) there is some default behaviour. For example
in Java it's package (#) - in UML understanding, Java calls it "package-private",
in C++ you'll end up with private feature (-),
in PHP such features are treated as public (+)
and so on.
I know, there are no 'real' private/protected methods in Python. This approach isn't meant to hide anything; I just want to understand what Python does.
class Parent(object):
def _protected(self):
pass
def __private(self):
pass
class Child(Parent):
def foo(self):
self._protected() # This works
def bar(self):
self.__private() # This doesn't work, I get a AttributeError:
# 'Child' object has no attribute '_Child__private'
So, does this behaviour mean, that 'protected' methods will be inherited but 'private' won't at all?
Or did I miss anything?
Python has no privacy model, there are no access modifiers like in C++, C# or Java. There are no truly 'protected' or 'private' attributes.
Names with a leading double underscore and no trailing double underscore are mangled to protect them from clashes when inherited. Subclasses can define their own __private() method and these will not interfere with the same name on the parent class. Such names are considered class private; they are still accessible from outside the class but are far less likely to accidentally clash.
Mangling is done by prepending any such name with an extra underscore and the class name (regardless of how the name is used or if it exists), effectively giving them a namespace. In the Parent class, any __private identifier is replaced (at compilation time) by the name _Parent__private, while in the Child class the identifier is replaced by _Child__private, everywhere in the class definition.
The following will work:
class Child(Parent):
def foo(self):
self._protected()
def bar(self):
self._Parent__private()
See Reserved classes of identifiers in the lexical analysis documentation:
__*
Class-private names. Names in this category, when used within the context of a class definition, are re-written to use a mangled form to help avoid name clashes between “private” attributes of base and derived classes.
and the referenced documentation on names:
Private name mangling: When an identifier that textually occurs in a class definition begins with two or more underscore characters and does not end in two or more underscores, it is considered a private name of that class. Private names are transformed to a longer form before code is generated for them. The transformation inserts the class name, with leading underscores removed and a single underscore inserted, in front of the name. For example, the identifier __spam occurring in a class named Ham will be transformed to _Ham__spam. This transformation is independent of the syntactical context in which the identifier is used.
Don't use class-private names unless you specifically want to avoid having to tell developers that want to subclass your class that they can't use certain names or risk breaking your class. Outside of published frameworks and libraries, there is little use for this feature.
The PEP 8 Python Style Guide has this to say about private name mangling:
If your class is intended to be subclassed, and you have attributes
that you do not want subclasses to use, consider naming them with
double leading underscores and no trailing underscores. This invokes
Python's name mangling algorithm, where the name of the class is
mangled into the attribute name. This helps avoid attribute name
collisions should subclasses inadvertently contain attributes with the
same name.
Note 1: Note that only the simple class name is used in the mangled
name, so if a subclass chooses both the same class name and attribute
name, you can still get name collisions.
Note 2: Name mangling can make certain uses, such as debugging and
__getattr__(), less convenient. However the name mangling algorithm
is well documented and easy to perform manually.
Note 3: Not everyone likes name mangling. Try to balance the need to
avoid accidental name clashes with potential use by advanced callers.
The double __ attribute is changed to _ClassName__method_name which makes it more private than the semantic privacy implied by _method_name.
You can technically still get at it if you'd really like to, but presumably no one is going to do that, so for maintenance of code abstraction reasons, the method might as well be private at that point.
class Parent(object):
def _protected(self):
pass
def __private(self):
print("Is it really private?")
class Child(Parent):
def foo(self):
self._protected()
def bar(self):
self.__private()
c = Child()
c._Parent__private()
This has the additional upside (or some would say primary upside) of allowing a method to not collide with child class method names.
By declaring your data member private :
__private()
you simply can't access it from outside the class
Python supports a technique called name mangling.
This feature turns class member prefixed with two underscores into:
_className.memberName
if you want to access it from Child() you can use: self._Parent__private()
Also PEP8 says
Use one leading underscore only for non-public methods and instance
variables.
To avoid name clashes with subclasses, use two leading underscores to
invoke Python's name mangling rules.
Python mangles these names with the class name: if class Foo has an
attribute named __a, it cannot be accessed by Foo.__a. (An insistent
user could still gain access by calling Foo._Foo__a.) Generally,
double leading underscores should be used only to avoid name conflicts
with attributes in classes designed to be subclassed.
You should stay away from _such_methods too, by convention. I mean you should treat them as private
Although this is an old question, I encountered it and found a nice workaround.
In the case you name mangled on the parent class because you wanted to mimic a protected function, but still wanted to access the function in an easy manner on the child class.
parent_class_private_func_list = [func for func in dir(Child) if func.startswith ('_Parent__')]
for parent_private_func in parent_class_private_func_list:
setattr(self, parent_private_func.replace("_Parent__", "_Child"), getattr(self, parent_private_func))
The idea is manually replacing the parents function name into one fitting to the current namespace.
After adding this in the init function of the child class, you can call the function in an easy manner.
self.__private()
AFAIK, in the second case Python perform "name mangling", so the name of the __private method of the parent class is really:
_Parent__private
And you cannot use it in child in this form neither
In an interface method I want to have a collection of SomeType as an input parameter. How do I represent that within a Class Diagram in EA?
I tried using "SomeType[]" as parameter type, but EA doesn't seem to keep track of this: for instance when I rename the class SomeType to something else, the change doesn't propagate here.
You can specify multiplicity for each parameter of your method.
Parameter multiplicity is not directly visible in the class diagram even if you select "Full detail" in Parameter visibility in Diagram properties. But it is in the model.
The answer is unfortunately: you can't. EA does store the name only and not the reference to the class when you specify a parameter. There are other places where that's also the case (I currently can't recall where). So if you need to track that you need to write a smart SQL to list the used parameters.
Such a SQL could look like:
SELECT * FROM t_operationparams where Type = '<Search Term>'