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?
Related
I have a sequence diagram, and I would like to create a class diagram from it.
This is the sequence diagram:
I'm struggling with classes operations (which class should I give what operations)
You can derive the class from the life line. Each is an instance of a class. With the used notation you can say that the title corresponds to the class name directly. The actor is some informal compromise and is not a class.
The messages towards a life line correspond to operations of the class. E.g. ViewBookForm has onClick().
In any case you can pinpoint only those operations you have in the diagram. And you can't find out the atributes. So your classes will be skeletons only.
Suppose an abstract class X and its subclasses Y and Z. How do I represent in UML class diagrams that Y and Z should be singletons. Is it possible to represent that all X subclasses must be singletons?
To specify that all subclasses of X are singletons, you can write a constraint in between braces: { every subclass of X is a singleton }. This constraint should be put in a constraints compartment in the class rectangle.
The UML 2.5 specification, §7.6.4 defines the notation for constraints in general and §9.2.4 specifies how to show the constraints of a classifier:
If a Classifier owns Constraints, a conforming tool may implement a compartment to show the owned Constraints listed
within a separate compartment of the owning Classifier’s rectangle. The name of this optional compartment is
“constraints.”
Alternatively, you could give a singleton indication on each and every subclass of X. From your wording, I assume that that is not what you want. Anyway, the latest version of UML (2.5.1) does not have a standard way to indicate that a class is a singleton. Some people indicate it by writing 1 in the top right corner of the rectangle. However, that is not valid UML. You may use that for parts, but not for classes. Instead, you could invent your own stereotype ≪singleton≫.
There is another StackOverflow question about this topic.
Here's another possibility: you can adorn the class with a <<singleton>> stereotype. I always used it that way and the coder knows how to handle that. It's no UML standard, but see the last sentence.
§11.4.4 of the UML 2.5 spec says:
A usage dependency may relate an InstanceSpecification to a
constructor for a Class, describing the single value returned by the
constructor Operation. The Operation is the client, the created
instance the supplier.
If you create a GeneralizationSet that has the meta-property isComplete=true (to say that all possible subclasses are accounted for), and you connect one InstanceSpecification to each constructor by a usage dependency, the model means that every class is a singleton.
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.
A few query and opinions to seek on the best type of relationship and representation to be used in a class diagram for modelling with uml
1) Third party library used by my class
-- I have modeled them as packages
2) Wrapper Class to wrap around modified code
-- I have modeled this class as an interface
3) My wrapper class actually use non-class member function that is written in another namespace
-- This puzzled me. How should I modeled them?
4) For classes in my own created library(dll), how do i differentiate the class that is exported and those that is not
Thanks
1) That's fine. However, it depends on the layer. I could think of a component to represent a library.
2) Not necessary. A wrapper inherits from a class. So use a generalization.
3) You can not really do that. You might use an artifact and a relation (association) to it.
4) I would use a component with interfaces (lollipops) to show the exported ones. The others are kept inside.
For all answers: YMMV
How do i model a call to a static method in a class diagram ? Can someone show me a link to a class diagram that has done that?
for example there's a class called Animal. and i have another class called Vertibrates, and it has a method which is static (and this is the only method in that class). My Animal class will be using this static method of the class Vertibrate. Therefore how can i model it in class diagram ?
You don't. Well, not in a class diagram at least. Instead, you should use sequence chart diagrams to express method calls (whether static or dynamic).
You can't model the call directly in a class diagram (as #Imontrieux says), but you can model the relationship (i.e., that Animal uses (calls) static methods in Vertibrate; BTW, the correct spelling is Vertebrate), which I suspect is actually what you meant.
You use a UML dependency for this, not an association (since the latter are for associations between instances of the classes at each end)--- see How to show usage of static methods UML Classdiagram.
Great question. One thing the GoF do in Design Patterns is used notes to demonstrate intended uses. For example, from the section on the Command Pattern:
Command Pattern
While #user1315906 is technically correct that you don't model such things in Class Diagrams, but rather in Use Case or Sequence Diagrams, if it makes sense to note how something is intended to be used in a Class Diagram, you can use a note :)