I have two classes – Type and Model.
A Type can be primitive, but any Model can be further used as a Type. Hence, a Type can be a Model, but doesn't have to be.
How do I represent this using a UML Class Diagram?
My initial idea is to also define a PrimitiveType and then connect that class and the Model class to the Type using a generalization, but I can't help but assume there is a better way.
One generalization is enough. The arrow should point from Model to Type, which means: a Model is a Type. All Models are Types, but not all Types are Models.
By default, a superclass is not abstract, i.e. instances of the superclass may exist. For example, if File is a superclass and Image File and Text File are the only subclasses, then there are three kinds of Files: Images Files, Text Files and Files that are neither Image Files nor Text Files. However, if File is declared as an abstract superclass, then all Files are either Image Files or Text Files.
Related
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.
Is it correct in accordance with UML specification for UML in version 2.5 to model generalization relationship between UML enumeration and UML class? In page 166 the specification states "As a specification of Classifier, Enumerations can participate in generalization relationships". Is it however correct to put generalization relationship between class and enumeration? If yes, how such a enumeration should than be interpreted?
Yes, you can do so. Both elements are Classifiers as the UML 2.5 metamodel shows.
As such you can use inheritance between both.
Now for your question what that would mean. Well, honestly I don't know. Enumerations are basically meant to be just enumerations. In the old days they were just that list of EnumerationLiterals. More recent languages allow for operations/properties as well. But when you pimp them with a Class, then what is the point? Generalization is a blade with two edges. Defining an amphi-car as inheriting from car and ship feels strange. It's neither of both but something new. So in case of Enumeration it's similar.
I still did not find a formal constraint, but you may use the Generalization definition to find evidence whether a generalization between a Class and an Enumeration makes sense (or find examples which have an interpretation):
A Generalization is a taxonomic relationship between a more general
Classifier and a more specific Classifier. Each instance of the
specific Classifier is also an instance of the general Classifier. (UML 2.5.1, p.138)
With your construction, an instance of the Enumeration would also be an instance of the Class (or vice versa). Now let's look at what that means.
When a Classifier is generalized, certain members of its
generalizations are inherited, that is they behave as though they were
defined in the inheriting Classifier itself. For example, an inherited
member that is an attribute may have a value or collection of values
in any instance of the inheriting Classifier... (UML 2.5.1, p.100)
In fact an Enumeration can have attributes just like any Classifier, thus why shouldn't it inherit those from a Class? Looking further into what it means to be an instance of an Enumeration or an instance of a class, we find this:
DataTypes model Types whose instances are distinguished only by their
value. ... Each value of an Enumeration corresponds to one of its
user-defined EnumerationLiterals. ... EnumerationLiterals may not
change during their existence, so any attributes on an Enumeration
shall be read-only. (UML 2.5.1, p. 209 f.)
Aha, maybe we could enumerate objects with their attribute values (instances of Class) as values of an Enumeration? Would the instances of the Enumeration than also be instances of the Class? Would that be a suitable interpretation?
I am just thinking out loud, not being sure if this makes much sense. I just wouldn't rule out that there is an interpretation just because I never encountered one or cannot imagine one. In fact, look at Enums in Java - they implicitly extend the Class java.lang.Enum and the only reason why they can not extend further user-defined classes or other Enums is that Java does not support multiple inheritance of state (Oracle Java tutorials).
Let's assume I have 2 classes with association relation.
What is the difference between adding attributes to one of the classes and adding an Association Class with attributes?
I understand that association class describes the association relation, but cannot I use simple class attributes instead?
What are the added values of Association Class?
Association and attributes are actually different renderings of the same thing. The difference is more a bit of esoteric nature. An association is visually more exposed than an attribute. So you would use the attribute if it has a more local importance rather than a more system wide in case of an association.
What you should not do is to use both. When using an association and you need to name it then use a role along with the association and do not repeat it as attribute.
An association class (AC) is actually a combination of a class and an association (in UML it inherits from both). This way the pure relation between two classes can have methods and attributes itself. An association class is used if you want to relate two classes with M-N relation. E.g. the AC between Student and Exam describes the results a student has achieved in exams. So you have a Class 1-M AC N-1 Class relation rather than having this information as array attributes inside either of the opposing classes.
As a side note (since you tagged it EA): EA offers a drop down in the roles which is fed from attributes of the class. You should not make use of that. This is some heritage and/or a misinterpretation of the definition. As said: its not wrong, but also not good style.
You say you already have two classes with an association between them. In that case, there is a huge difference between adding attributes to one of those two classes and changing the association into an association class with its own attributes. They are not at all similar.
Unnamed properties already exist at each end of the association and are typed by their adjacent class. Adding redundant attributes is unnecessary and would be incorrect.
An association class allows you to record additional facts about a link between instances of the other two classes, such as the point in time the link came into existence. Association classes are like associative entities in a database.
I think part of your question is also about when to use an association vs when to use attributes. The UML spec doesn't provide any guidance on this. However, common practice is to use an attribute only for types that have no identity, such as the number "5", the string "Hello", or the combination of "7" with an enumeration literal of "pounds". In UML, these types are called primitives and datatypes. If you want a property typed by one of those, use an attribute; otherwise, use an association with named association ends.
What are differences between instance and role in terms of UML (class diagram, object diagram, sequence diagram) ?
Roles (e.g., in a composite structure diagram) are another representation of properties shown in a class diagram. On the composite structure diagram one can show a particular configuration of which subtype is used for each property. A role name and type is not underlined.
In contrast, an instance specification represents a partial or complete instance. On a class diagram, an instance specification can show values for every property, including links to other instance specifications. An instance specification name and type is underlined on the diagram.
These diagrams look pretty similar, but the intent is different. Instance specifications show instances at one flat level. Composite structure diagrams show internal configurations within a class (or other context, such as a collaboration) and can nest to any level.
Role names are found at the opposite end of connectors and denote the name of the instance by which a class references it.
CollaborationRoles are used to represent different implementations (or aspects) of a single use case.
Users (and systems) play roles of Actors.
Instances as described in UML 2.5:
InstanceSpecifications represent instances of Classifiers in a modeled system. They are often used to model example configurations of instances. They may be partial or complete representations of the instances that they correspond to.
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.