In a UML class diagram, is it technically correct to have two possible compistion relationships leading to one class?
I.E. I have an inventory class, which has a composition of the inventory class. I want to have the same relationship but with a container class taking the place of the inventory.
So, can I have two compositions, or do I need to turn these into aggregations?
You can have as many composite associations as you like on the class level. But each instance can only be part of one composition at a specific moment in time.
UML superstructure says:
If the whole has aggregationKind = composite then the part can be included in at most one composite at a time
This article I wrote tries to explain the difference: UML Composition vs Aggregation vs Association
Any number of composition association can lead to one class of course. If instance of composed class is composed of instances of more types for example.
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.
In my case, what is appropriate relationship between CarBuilder and SuperCar (SportCar as well)?
Explanation: CarBuilder holds an array of Car class's instance but it doesn't construct any instance of Car class. Instead, it constructs SportCar, and SuperCar classes' instances by directly call CreateInstance() method of these two classes.
Class Diagram:CarBuilder
In your question you are describing three different relationships -- a compositional one (that you already have), and then two others to the constructors of SuperCar and SportCar. So I'd just add an association to SuperCar and SportCar from CarBuilder.
Incidentally, it seems unlikely that you'd only ever have a car composed within CarBuilder -- maybe you mean a (weak) aggregate rather than a composition? Surely a car can exist outside CarBuilder? Also, this looks like a partial implementation of the strategy pattern, might be worth looking whether that's relevant.
i have three classes and each one of them has an association with same forth class, is it okey to use N-ary association in this case ?
It depends on the logic of your domain. If each of the three classes has a logically separate relationship with the fourth class (i.e. they can vary independently) then they are separate associations. If they are all associated by the same relationship then this would be N-ary. For example, a Car, Driver and Route could be all associated one relationship -- that you might call Journey -- which would be three-ended (N-ary), whereas a Car and an aggregate part (e.g. Wheel) would be two-ended. So it depends.
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.