Does double association exist in UML? Let's say, for example that i have two classes: User and Account with their own attributes which are not important and that in the User class there should be exactly two attributes of type Account.
In this type of scenario when making the UML class-diagram should there be a double association or is there another way to emphasise the fact that there are two attributes of that type?
Thanks
In fact to model "a double association", I would use two associations which are useful to speficy a different role for each association as depicted below .
Related
I am learning UML and I've focused on a Netflix-like project on which to practice on.
I've put together a class association diagram, but have been told that the multiplicities are incorrect. The multiplicities in red represent what I think they should be changed to.
Could someone please offer some clarity of where I have gone wrong?
Please, ask any questions that would help gain a fuller understanding of the diagram in reference to the project.
Thanks in advance.
Movie Catalog - User: The 0..* multiplicity is correct. There can be an arbitrary number of users and not only a single one. That would only work if that Netflix was made for a very single person. And that would be pointless, I guess.
Movie - Membership - Member: This represents an association class for the user to track payments (and access, etc.). So it must be the 1, not 0..*. The stream is sent for that single Membership where it is accounted. An association class has a n-1-1-m relation.
In your model it looks like this:
And from my POV it is:
since the Membership is just used to control access to the movies. It is arguable whether there is only a 1-1 relation and not a (preferable) m-1 relation between Member and Membership.
ERD from Wikipedia:
I'm confused to distinguish "has" and "contains" relationship in ERD, what's the difference between them?
With regards to the linked diagram from Wikipedia, both Has and Contains are one-to-many relationships (1..n) with total participation of Character in the relationship (double association line). Total participation means every Character must be related to an Account and a Region.
However, the Has relationship is marked as an identifying relationship (double-bordered diamond) and Character is marked as a weak entity set (double-bordered rectangle). This means that the identifying attributes of Character include the identifying attributes of Account. Character has a weak key CharName, which must be combined with AcctName to fully identify a Character. In other words, the primary key of the Character table will be composite: AcctName, CharName.
Note that these comments apply to the example ERD, not to ERD in general. Has and Contains aren't types of relationships - in general, a relationship can be called anything and have any combination of the features available in ER theory.
Also, see my answer to Is optionality (mandatory, optional) and participation (total, partial) are same?
When class is associated with another, like Flight in the linked image, which has zero or one Plane associated with it, should this not be reflected in the class' attributes?
That is, shouldn't class Flight in this example have an assignedPlane field alongside its flightNumber, departureTime and so on... otherwise how can Flight be said to 'be aware' of its associated Plane?
No.
Showing an association in diagram is equivalent to having an attribute of a specific class. If there is an association(with a role) then this role is an attribute of respective Class.
For reference please see the Figure 9.12 (with description) in section 9.5.5 of UML 2.5 specification.
If you would have an attribute 'assignedPlane : Plane' in class Flight, then the role 'assignedPlane' on the association would be redundant. But merely having the role 'assignedPlane' on the association does not imply that class Flight is aware of it. If Flight would be implemented as a Java class or a class in any other OO programming language, it is not clear from your class diagram whether or not class Flight has any reference to (or knowledge of) the assignedPlane.
If you want to communicate to your audience that class Flight owns a reference called 'assignedPlane' to zero or one instance of Plane, then you could add a thick dot (or a small filled circle) at the end of the association. Here is an example from the UML 2.5 specification:
In this example, 'size' is an attribute of Window, although it is displayed as an association. If you would have a class diagram that shows all attributes of Window, then 'size : Area' would be one of them.
The dot notation is a relatively new notation and it is not widely used. Instead, many designers use the arrow notation, also shown in figure 9.12. According to UML, this so-called navigability arrowhead specifies that the associated instance of Area can be accessed efficiently from Window, irrespective of how and why this is the case. Most designers would assume that it means that Window has an attribute 'size : Area', but strictly speaking, this is not what the UML specification says.
Using both the arrow and the dot, as in figure 9.12, is valid, but redundant.
I have 2 classes in UML and now need to create a constraint for this part - attribute1:String is in class1, and attribute2:int is in class2, connection between classes is generalization - can be changed to association.
I need to write this somehow
if attribute1 contains 'First year',
then attribute2 have multiplicity [1..2],
else if attribute1 contains 'Second year',
then attribute2 have multiplicity [3..4], and so on.
I know all values that attribute1 can take defined as enumeration(12 values, but only 4 if conditions is needed because every 3 have same part of text at begin).
I am creating UML in enterprise architect if its important.
Here is the picture of classes
or
There are several ways to model that
Put a constraint on association
This is a simplest and most obvious solution. Put a constraint describing logic in a note symbol in curly brackets {} and link it to the association. The constraint can have any form, e.g. natural language or formal language like OCL
Note that in such case your multiplicity on a constraint will range from 1 to the achievable maximum for all possible values of each enumeration value.
The drawback is that the information is purely textual and might be difficult to comprehend.
Create subclasses (solution earlier suggested by Jim L. in his answer)
Subclass can redefine an attribute, e.g. changing the multiplicity. On a parent level the class would have a multiplicity with a maximum achievable maximum while each "year specific" subclass will have a multiplicity matching requirements for that year.
You also need to anyway model a constraint for each of subclasses defining which enumeration values are available for that particular subclass.
The drawback of this solution is that when you have a possibility to change from one year to another, it'll not be a simple attribute change but rather a whole replacement of one subtyped object into another one with a different subclass as a type.
Multiplicity as variables
The idea is that you handle a logic of mapping between the possible values and related multiplicities and on association you represent the multiplicity using attributes of that mapping rather than specific numbers.
This approach builds a bunch of possible detailed solution but I group them together as they all follow the same approach with just slight differences on how to handle the multiplicity values. I'll give just one detailed solution example (more to follow if someone asks)
One of solutions here is to use data type rather than enumeration. The data type will have in its structure a name (which can still be using the enumeration as a base) and two values (lower and upper multiplicity values). Then your attribute1 will be of that data type and your multiplicities will reference the attribute1 and it's specific properties.
Your date type might for example contain properties name, minM and maxM and then on attribute you'll have a multiplicity minM..maxM.
Of course you need to add constrains ensuring that {0<=minM<=maxM} on data type and it's good to specify a set of possible values for a data type somewhere in a documentation as e.g. a table.
A drawback of this solution is that the relationship between specific value and its multiplicity restrictions is not directly on a diagram. Yet this is balanced by a much stronger flexibility of a solution.
Multiplicity as a formula
If there is a simple logic between e.g. year and number of related elements that can be written as a formula such formula can also be used in a multiplicity. This is especially useful if you split your enumeration into two separate numeric attributes (hey, you've got a class, when choosing you can still use enumeration, just map it inside the class!). I'll make this assumption in my example.
Let's say that instead of attribute1 you have two attributes: yearNo and yearType. Moreover lets say that in first year you can have 1 or 2 objects of class2 in your class 1 object, in second year you have 3 or 4, and so on. In general you have in n-th year 2n-1 to 2n elements so your multiplicity will be 2*yearType-1..2*yearType
A drawback of this approach is that it is possible only if there is a formula behind.
Additional remarks:
I believe the mentioned in solution 4 split of your attribute1 is a good solution regardless which solution you choose.
Generalization has no multiplicity. This type of relationship shows that object of a subclass is at the same type an object of a supertype. In my opinion you should not use this type of relationship here. Most probably you were thinking of shared/composite aggregation rather than generalization (but it has a different arrow head - a diamond, not triangle. Of course it can be quite safely replaced with association.
Don't use association to the Enumeration (in general to a data type). If you put an attribute as a textual attribute in a class, link it with a type through a dependency (a dashed line with an open arrow). For enumeration (data type in general) this is the only relationship. For normal classes as an attribute type you can exchange inline attribute with an (graphically shown) association (with a role name to make it fully replaceable).
I think you need to replace the enumeration with explicit subclasses under Class2. Each class can then redefine multiplicity for attribute2. While you could express this in OCL about the enumeration, few people would understand it.
I was reading through a tutorial on UML Class diagrams and I'm having problems understanding Association Classes and why this MileageCredit class isn't part of the FrequentFlyer class in the below example (taken from figure 11 of the tutorial here):
Assuming that it's a one-to-one relation between FrequentFlyer and MileageCredit (if a person had two FrequentFlyer memberships they'd still have different frequentFlyerNumber numbers) then I would just put these baseMiles and bonusMiles properties in the FrequentFlyer Class itself.
Could someone please explain why this is wrong?
MileageCredit is an AssociationClass, which means this is simultaneously an Association (linking) Flight and FrequentFlyer) and a class that describes this Association. This fact is depicted by a dashed line connecting the class and the association. Note that acording to the UML specification those class and association together create one entity.
In your example there is Association (that is called MileageCredit) between FrequentFlyer and a Flight. You may assume that this shows a Flight taken by a FrequentFlyer. As for these Association you need additional information (number of award and bonus miles that are awarded to the FrequentFlyer for this Flight) this association has this extra Class describing this information.
If you created baseMiles and bonusMiles on FrequentFlyer that would have absolutely no relationship to the Association - it would be only information about total points awarded to the FrequentFlyer.