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.
Related
I know there are some related questions about this question, such as this, this and this, but no one of them really helped me. My array keys are dynamic, so I can't create an additional class holding this attributes (like done in second linked question).
The idea of my concept is to hold instances of classes as follows:
$instances = [
"nameOfClass" => [
//instances of "nameOfClass"
],
"nameOfClass2" => [
//instances of "nameOfClass2"
]
//some more classes
];
But I don't know how to model these concept with UML when the array-key is unanimously with the class-name.
Is there a way to model my concept/in general associative arrays?
The correct way to express this in UML is to use a qualifier, or qualified association. There you have an owner and that has a qualifier, i.e., "key", that associates to a class. Further you can give the qualifier a type, to express that your key is a String, int, or Object of a certain class.
See also p. 206 of UML 2.5.
It sounds like you are wanting to simulate classes in PHP by building an associative array of named classes, where each class name (e.g., Person or ShoppingCart) maps to a collection of instances. If so, you are essentially trying to represent a non-OO simulation of OO in UML. UML is already OO, so you are trying to jump through your own belly button!
Unlike in PHP, in UML, a Property (i.e., a variable) must be owned by a Classifier, which is usually a Class or an Association. Therefore, to express $instances as a Property, it would have to be owned by a Class or Association.
If you are willing to accept that there will be an owning Class (let's call it ClassIndex), you will then need another UML Class, probably called Class, to represent each class (e.g., Person or ShoppingCart) and its attributes (e.g., firstName and lastName). Are you getting confused by the meta-programming yet? We haven't even gotten to the part about how to track the attributes of each class and so on.
While UML has all of the parts you need to re-invent OO programming, you have a fundamental mismatch between UML and PHP. The same would be true for C or assembler. UML allows you to work at a much higher level of abstraction than those languages. Therefore, I recommend you get an OO simulation working, then use UML to model your domain classes (e.g., Person or ShoppingCart) and generate a "configuration" that your OO simulation can run.
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.
I want to make an UML diagram and show the dependencies between three classes: TransparentOverlayCamera, ViewCameraView and SubpartCameraPreview.
TransparentOverlayCamera has access to ViewCameraView and the other way around. So I used a bidirectional association.
ViewCameraView has access to SubpartCameraPreview but not the other way around. So I used a unidirectional association.
But ViewCameraView also passes an instance of TransparentOverlayCamera to SubpartCameraView, so that it has access to TransparentOverlayCamera.
How do I model this last association in UML correctly?
You can draw the usage dependency link from SubpartCameraView to TransparentOverlayCamera
If you want to avoid circles and keep your architecture layered then cross-layer dependencies are often modeled through <<interface>> as in this example: http://www.uml-diagrams.org/design-pattern-abstract-factory-uml-class-diagram-example.html
See also: http://www.uml-diagrams.org/component-diagrams.html#provided-interface
There is not necessary to use dependency relationship in your model.
If you need to define structural relationship between classes , association is enough.
Be careful, association has no direction. Arrows at the association end represents navigability. Navigability defines that, instance at the association end is unambiguously identifiable. Association does not define communication as well.
If something is passed to instance, it is not a structural model but behavioral. You probably mean passing argument to operation. You need to define operation with arguments of specific type.
From you example: TransparentOverlayCamera will be set as argument type of operation defined on SubpartCameraView class.
hi every body i'm trying to understand UML but there are some questions about it
In UML what is the significance of tagging a class with the stereotype <<abstract>>?
and how to express this constraint as an invariant,
A stereotype "abstract" does not exist - an abstract class should be depicted using italic font. Abstract means that a class cannot be instantiated. It needs a subclass to do so. So as a pseudo-code constraint this would mean
for all instances i of MyAbstractClass holds: i.actualClass != MyAbstractClass
or in ocl for MyAbstractClass holds
self.allInstances()->forAll(i: MyAbstractClass | i.classifier <> self)
As the word 'abstract' was not displayed in your first question version, I expanded on stereotypes in general:
First of all: When learning UML, stereotypes should not be the first things you look into. They are rather complex.
Stereotypes or keywords (both denoted with <<MyStereotype>>) do not have a general meaning. It is defined by the specific stereotype. Commonly you cannot express a stereotype as an invariant instead.
But some other aspects of UML can be shown the same way: A class from the UML Metalevel is marked with <<metaclass>> even though it does not have a stereotype or even is of different actual type. The Stereotypes themselves are shown with a <<stereotype>> marker (even if they are instances of a special class).
An example for a custom stereotype could be "Service". You could mark classes with it which represent a Service. There could be a constraint which tells you that a "Service" must implement a special Interface. In this case you could express this constraint as a (boring) invariant. But probably it is even just a marker. In the latter case you can use a keyword as replacement.
I realize this thread is a couple of years old, but I came to it when it was referenced by someone else, as supporting the assertion that the «abstract» stereotype isn't supported by the UML spec. That assertion isn't quite accurate, and I'd like to explain why. I'll start by clarifying what abstract classes are.
Abstract classes are definitions of classes that don't include complete implementation. Therefore, abstract classes can't be directly instantiated; they have to be specialized (inherited). Abstract classes are notated by italicizing the class name and the methods that are abstract, and additionally by optionally adding an {abstract} property to the class name and/or to the operations (methods, we usually say, but methods are actually the "method" by which the operation is implemented) that are abstract.
Interfaces are actually a specific type of abstract class: a class with zero implementation. Their notation is different from other types of abstract classes (don't italicize, use the «interface» keyword, and notate all the specialization arrows with dotted lines). So, as Christian says here, there is standard notation for abstract classes--at least, there is in class diagrams.
Now, while it is true, as Christian also says, that the «abstract» stereotype doesn't exist, it is also true that you can create it if you want to, and that doing so is supported by the UML spec. It's unlikely that you'll have a reason to (at least in class diagrams), but you still can.
A stereotype is an "extensibility mechanism" for UML (there are three: stereotypes, tagged values, and constraints). It allows you to more specifically define some sort of element. Stereotypes are applied to classes (metaclasses actually, metaclasses are classes whose instances are also classes). A number of stereotypes are pre-defined "Standard Stereotypes" (in UML 1.4 they were called "Standard Elements"). Examples of these are «metaclass» (again, a class whose instances are also classes) and «file» (a physical file in the context of the system developed).
Stereotypes are a type of keyword. The spec (Superstructure 2.0, Annex B, p. 663) has this to say about keywords:
UML keywords are reserved words that are an integral part of the UML
notation and normally appear as text annotations attached to a UML
graphic element or as part of a text line in a UML diagram. These
words...cannot be used to name user-defined model elements where such naming would result in ambiguous interpretation of
the model. For example, the keyword “trace” is a system-defined
stereotype of Abstraction (see Annex C, “Standard Stereotypes”) and,
therefore, cannot be used to define any user-defined stereotype.
In UML, keywords are used for four different purposes:
To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form...
To distinguish a particular kind of relationship between UML concepts (meta-association) from other relationships sharing the same general graphical form...
To specify the value of some modifier attached to a UML concept (meta-attribute value)...
To indicate a Standard Stereotype (see Annex C, “Standard Stereotypes”)...
Keywords are always enclosed in guillemets («keyword»), which serve as visual cues to more readily distinguish when a keyword is being used...In addition to identifying keywords, guillemets are also used to distinguish the usage of stereotypes defined in user profiles. This means that:
Not all words appearing between guillemets are necessarily keywords (i.e., reserved words), and
words appearing in guillemets do not necessarily represent stereotypes.
In other words, you can create any stereotype that you want, so long as it isn't a keyword. Since "abstract" is not a keyword, it follows that you can create an «abstract» stereotype.
In order to do so, however, you would have to go to some trouble, more trouble in UML 2.0 and above than in UML 1.4. UML 1.4 simply stated that a stereotype was an extension mechanism for the UML spec. One could simply define the stereotype, apply it to whichever part of the UML metamodel one wanted, and document the change. UML 2.0 wanted to formalize the relationship of a stereotype to a UML metaclass (any item on a UML diagram is a metaclass, and part of the UML metamodel). So, they came up with Profiles. This sample diagram shows how profiles work:
Now, that black arrow may look a bit strange, since you don't see it in any context but this one. UML 2.0 introduced the concept of an Extension, which it defines as "used to indicate that the properties of a metaclass are extended through a stereotype." This black arrow indicates an extension.
I'll quote Tom Pender (The UML Bible, Wiley Publishing, 2004) for an explanation of this diagram, since he does a better job than the spec (and I certainly can't improve on it):
It shows that a Component is extended by a Bean stereotype, which is required. The Bean stereotype is an abstract type, with two subtypes - Entity and Session. Each instance of Component, therefore, must be extended by an instance of either the Entity stereotype or the Session stereotype. Remember that a stereotype is a kind of class that can have properties - in this case, a Session stereotype has an attribute named state. This corresponds to a tagged definition whose value specifies the state of the Session. The tagged value is an enumeration, StateKind, which has either a stateless or stateful value.
The Component has a constraint on it, displayed in the note attached to the Component symbol, which states that a Component cannot be generalized or
specialized.
The diagram also shows that an Interface metaclass is extended by the Remote and Home stereotypes. The EJB package has a constraint, displayed in the note that sits in the package, that states a Bean must realize exactly one Home interface.
So, you can indeed use an «abstract» stereotype if you have reason to go to the trouble of creating it. The main reason that anyone might want to is to represent an abstract class in some place other than a class diagram.