This question already has answers here:
UML: when one class have as method parameter pointer to other class
(4 answers)
Closed 11 months ago.
I have a project where class Foo has a member function which takes class FooParam as a parameter. Now I want to draw a UML class diagram representing the relationship between class Foo and FooParam.
From the options on the table, inheritance, implementation, aggregation and composition are automatically excluded. Thus, the options that are left are association and dependency, but to my eyes none of them fits quite right.
Given the options, how exactly do we model method parameters in class diagrams?
I agree with Gerd, you will not see a "link" or "relationship" between Foo and FooParam classes. I put below what you should see by default.
Of course, you can always add an explicit link (as a dependency for example) but it is, for me, duplication of the information...
The best is maybe to have a tool which would be able to compute this "link" or "relationship" and show it to you in some way.
Related
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.
This question already has an answer here:
How to represent an attribute's data type as an array of objects on class diagram?
(1 answer)
Closed 2 years ago.
I am new to UML diagrams, so this may be a very ignorant question though I can't find the answer anywhere.
There is a class Classroom that holds an object of lecture times. Should lecture times be its own class or should it be an attribute of Classroom?
Feel free to critique notation.
Edit: I have already seen this post and it has not helped. I would like to know if LectureTime should be a separate class.
Option 1:
Option 2:
You create a new class if it has more than a single attribute and/or additional operations (which are not just a getter/setter). Or of you plan to add them in a later phase.
In your case lectureTime is obviously a simple type and the 2nd variant is to be preferred, except see above.
However, instead of the round braces you should use square brackets like validLectureTimes[] or validLectureTimes[0..*] which are equivalent.
If LectureTime is an Entity then yes. I guess it is, because of the relation you've added.
I am writing a system which generates code for a number of classes and I need to document it with a UML diagram. The classes will follow the same structure but they will have names set by the user. Is there a way to specify that CCodeGenerator generates the code for these classes?
Also, I currently have a relationship between my CDataDefinition class (which defines what should be included in each of the generated classes) and the CCodeGenerator, is there a way to denote that the multiplicity of the relationship between the generated classes and the generator is exactly equal to the number of CDataDefinition instances?
These classes will be used in another system which will also need UML class diagrams made for it. Is there a way to show that a class in this project (CEditior) uses them?
Example of operation:
I have 3 CDataDefinition objects which define classes X, Y, and Z. My CCodeGenerator instance will create 3 classes (C# code in .cs files) from these.
CEditor in a separate solution will then interface with these 3 classes.
If you read some of the introductory information on MOF, you will see that in the UML family an instance of a metaclass in one layer is a classifier in the next.
In your case, a class in the code generator describing the class in its output will be a metaclass (CDataGenerator), and the classes in the output represented by instances of the metaclass.
There is no way in plain UML for associations other than 'X is of type Y' to cross between the layers.
You may be able to model such a relationship using MOV QVT (query, view, transform - i.e. a language for mapping one model to another), but I don't know current state of tool support for that, and if you had a QVT tool you probably wouldn't need to be writing a code generator.
You need to build a template class (CDataDefinition) that will represent the structure of a class that can be created by CCodeGeneratorWhen you're creating actual class you do the binding so all you have to do is show that CCodeGenerator has an operation (let's say) classGenerator(name:String) and then you can show that this method creates a class as a proper binding on CDataDefinition.
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.