I have this attribute in Java:
private final Object MUTEX = new Object();
How can I show the init of a new Object in the UML Class Diagram?
EDIT:
The attribute MUTEX is used only for synchronized (MUTEX) operation.
So I was wondering if the initialization of this variables is needed to be specified in a UML class diagram, but i'm not sure if this initialization is behavior like or structural specific.
A class diagram is meant to show structure. As a part of structure you can show initial values of properties as answered in this question.
To show the operation "in progress" you need to create a Sequence Diagram where you can show behavior. The question would be: why? A simple initialization is usually not worth it. And from the skinny context of your question it does not appear to be the case. So the best is to go with above answer.
Edit (past your question edit) This is just structure and you will show it like this:
Related
I am trying to create UML diagram. For example I have a class A with method a() and class B that extends A and overrides method a(). Is there any standard to indicate overridden methods in UML?
No, there is no specific indicator for operations that override operations on a parent class.
If the signature matches it overrides the operation on the parent.
The norms says on p. 101:
Inherited members may also be shown in a lighter color to help distinguish them from non-inherited members. A conforming implementation does not need to provide this option.
Sadly, my tool (EA) does not support that.
The simplest method is to duplicate only the operation signatures of those operations you are going to override. That will make it clear that you are overidding something.
By just looking to Class2 there is no way to tell that b is actually an override. However, if someone wants to deal with Class2 he must know that it's a subclass - and thus will know that b is an override.
Note: The UML 2.5 specs are ambigous about the caret use. While (on p. 100) they say
Members that are inherited by a Classifier may be shown on a diagram of that Classifier by prepending a caret ’^’ symbol ...
the syntax below explictely mentions only properties and connectors and this passage
Analogous notations may be used for all NamedElements that are inheritedMembers of a Classifier to indicate that they are inherited.
As indicated in that answer https://stackoverflow.com/a/28932482/2458991 there is a specific indicator to indicate a member (for instance an operation) is inherited, but that indicator is not mandatory, the norm says :
Members that are inherited by a Classifier may be shown on a diagram of that Classifier by prepending a caret ’^’ symbol to the textual representation that would be shown if the member were not inherited.
So, having :
B does not override oper
But having :
we cannot know except if we are sure the ^ is always used in the model as in previous diagram
[edit]
Notice the norm use two times the words member (and not properties) in that sentence, and Class inherits (indirectly) Classifier, so that applies for operations.
As noticed in an other answer the norm says also :
Inherited members may also be shown in a lighter color to help distinguish them from non-inherited **members*.
so again two times members rather than properties, and the fact they use also clearly reference the fact there is an other way which is the ^. So two consistent sentences indicating ^ applies to operations
[warning]
I used BoUML to make the diagrams and in the first you can see "^oper()" but I 'cheated' to do that naming the corresponding operation "^oper", there is no option to show a ^ in a diagram to indicate an operation or other member is inherited
I have class Controller in my java project, which has method like this:
As you can see, in the first line I am getting Singleton instance of ActualModes class and call method getActualModes().
So the first question is, which relatinship I should use in class diagram.
After that I am creating new instane of ModeContext class and then call method executeStrategy. In this case, which relatiship is better ?
It should be like this:
Access to the singleton (note the stereotype which is just convenient and no obligation or general standard) is anonymous and so you just have a dependency. The ModeContext in contrast uses a private (I don't know the scoping rules of the language you used, so I made it pivate) property called context. Note the dot which is saying exactly that.
Disclaimer: UML does not specify a mapping between Java and UML, so every answer to your question is open for debate.
I think both relationships are dependencies, drawn as dashed arrows from Controller to ActualModes and from Controller to ModeContext. The definition of 'dependency' according to the UML 2.5 specification (§7.8.4.1) is:
A Dependency is a Relationship that signifies that a single model Element or a set of model Elements requires other
model Elements for their specification or implementation.
An example of a type of relationship which is in my opinion less suited, is the association, although its definition (§11.5) is quite broad:
An Association classifies a set of tuples representing links between typed instances. (...) An Association specifies a semantic relationship that can occur between typed instances.
One could argue that there are links between Controller and the other two classes, in the form of variables, but these variables are local method variables, which exist only temporarily during the execution of the method. Associations represent more durable links, e.g. class members - as far as I understand UML and as far as I have seen associations used in practice.
I was looking at an article which had a class diagram on it.
https://sourcemaking.com/design_patterns/template_method
In the section "Structure", you can find the diagram below.
The method compare() appears to be noted as both public and protected, but this doesn't really make sense and I've never seen it before. I would have written it off as a typo is it weren't consistent for all instances of the compare() method in the diagram.
Is there a special meaning for "+#" in a class diagram?
This is typo error.
A NamedElement has 0..1 visibility.
"visibility : VisibilityKind [0..1]
Determines whether and how the NamedElement is visible outside its owning Namespace." p48
And to provide more explanation: NamedElement is one of the root classes of UML meta-model and Operation or Property inherit of NamedElement.
In a UML diagram when you create an instance of a subclass do you usually include the implicit construction of the superclass prior to the sub class constructor?
I usually wouldn't include it. The purpose of the UML sequence diagram is to show what happens between components. It shouldn't be read isolated from other parts of a design, so if a reader is unsure about what any of the components is (i.e. an instance of the subclass and the superclass), he or she should look into the - hopefully - accompanying class diagram.
sequence just shows the sequence of the logic of the module in question. Do you feel there is need to identify which method is truly being called? Also I would guess that the purpose of having a parent clas have a reference to a subclass is that until runtime you won't know which subclass is actually being referred to. If this is not the case, then should the concrete subclass be referred to explictly? does the method being called whether on the subclass or parent class alter the sequence in some way?
Do UML tools have some summary view that show a class object's attributes and methods, including those obtained from parent classes through inheritance?
For example, say I have diagrammed foobar's inheritance from foo (Python code):
class foo:
def doSomething(self):
print 'stuff'
class foobar(foo):
def dontJustStandThere(self):
self.doSomething()
The foobar diagram shows inheritance from foo, and method dontJustStandTherE(). The foo diagram shows method doSomething(). Now, instantiated foobar objects will have two methods -- dontJustStandThere(), and doSomething() (by inheritance). It would be nice to see a summary of foobar that just listed its methods and attributes, without breaking those down into their specific sources, and ideally ignoring parent class methods overloaded by subclasses. Such accumulation of methods into one object is one point of inheritance, yes?
Do UML tools have such a view, and what do they call it? I've looked around the guide and commands for the tool I'm using (Poseidon), and the web, and I don't seem to see anything like this -- but it seems so useful that I imagine it's there somehow.
(I suppose it's also possible that Poseidon is focused on Java code, and that differences in Java's specification for inheritance from Python's might be complicating things.)
In MagicDraw, when clicking on the properties on a class you see (in different boxes) at the same time the own properties of the object and inherited ones (and you can even change them, which updates the superclass owning the property)
Sparx Enterprise Architect does. You select the desired elements and choose the Feature Visibility command, and you can select whether inherited attributes and/or operations are visible:
UML 2.5 introduces a caret notation (e.g., ^ someAttribute: String) that allows you to show inherited members. Hopefully UML tools will support this notation soon.