For example, imagine a diagram where there are 2 association ends such as incoming/outgoingRoads. Is it possible to store these roads together in the same arraylist by giving them the same name like "allRoads" that contains both incoming and outgoing?
Or is there other way to solve this?
naming both of them with same name in uml app brings no errors
Two association ends at the opposite side of the same class are not allowed to have the same role name. It would create a naming ambiguity for City.allRoad:
Two association ends at the opposiste side of different classes can have the same role name. There would be no ambiguity between City.allRoad and WorkOrder.allRoad
Two ends of the same association can have the same role name as well. There would be no ambiguity between City.direction and Road.direction:
In the same way, there is no problem of having two associations between the same classes but with different end names:
Your design could as well deal with only one association for both incoming and outgoing roads. At least three different design could be considered:
making the road graph bidirectional, i.e. if all incoming routes are at the same time outgoing roads (caution: this is a substantial change in the underlying model: it would for example not allow to represent one-way roads)
using an association class, that would tell for each associated road, if it's incoming or outgoing.
using a qualifier (which would probably be implemented as a map or a 2d array, as qwerty_so mentioned in the comments):
Related
I'm having a difficulty figuring out where to put the Level attribute. I want the employee to have a variety of skills which have different levels. For that purpose I made a many to many relationship which is implemented as an EmployeeSkill association class.
An example of said class is as follows: An employee named Jack might have a skill of Java which is level beginner, while he could also have a skill of C# which is advanced level. Should the level be saved in the EmployeeSkill association class or in the Skill class? I suspect it should be on the association class.
A property of the association class?
Your narrative with the Employee instance "Jack" being associated with Skill instance "Java" with a level of "beginner" shows that the skill is independent of the level, and the level is related to the combination of a given employee and a given skill.
To model accurately the semantic of this narrative, level should indeed be the property of the association class EmployeeSkill.
Could it be a property of the skills?
It would not be wrong to move level as a property of Skill. But the model would have a different semantic, since every Employee associated with a Skill would share the same level. This means that "Jack" being associated to a skill like "Java" but rather a skill like Elementary Java.
This alternative model makes it also less convenient to desperately search for all employees knowing about Neural network regardless of the level. And it would not be obvious for the system to see that elementary neural network is related to advanced neural network expertise and that Advanced java has little to do with Advanced javascript.
To have the same power of expression, the skills that are related but correspond to a different level would require an explicit association, which would make the model more cumbersome to use and fragile.
Remarks that are unrelated to your question
You seem to repeat the JobCategory's and the Country's attribute within Employee. This is confusing, as the associations already associate the class with another set of each of these attributes. Did you mean the redundant attributes to implement the associations and show the db table layout than the class? If so, you should disambiguate using some custom stereotypes. But I'd rather recommend to remove the redundant items and make a comment at the bottom of the diagram to explain that you implement associations.
I wonder if the multiplicities of the association between Skill and SkillCategory are not inverted (i.e. one category can have several skills and each skill is associated with only one category) ? Or that you meant a many-to-many association if skills can belong to several categories.
In the association class you use the prefix FK to highlight the foreign keys. Use <<FK>> to make it a custom stereotype (see may first remark about using stereotypes).
As qwerty_so pointed out in the comments, you use a nesting connector for the associations with enumerations. This is syntactically acceptable but does not mean what you think. This is meant to deal with namespaces. Just remove that circle-plus symbol to make it a normal association and it will mean what you think.
I want to understand the difference between connecting classes together with a shared line or by having classes only "connect" through other classes. Is there a significant difference here? If classes share a line are you specifically trying to convey that information is being accessed from each of the other classes on the shared line?
For "Three Objects in a Row" I mean a layout that would appear as follows (sorry my diagram is:
For "Sharing Lines" I mean a layout that would appear as follows:
difference about access
In the first case instances of Flat and instance(s) of Tenant know each other, and independently of that instances of Tenant and instances of LeaseAgreement know each other. Instances of Flat do not have direct access to instances of LeaseAgreement and instances of LeaseAgreement do not have direct access to instances of Flat, they can only access the other instances if Tenant offers these accesses whatever the way (method or public attribute).
In the second case there is an association-class, instances of Flat and Tenant know each other more the corresponding instance of LeasingContract indicating how they are associated.
difference about knowledge
In the first case supposing the hidden multiplicity are not 1 a tenant having two rents is associated with two instances of Flat and two instances of LeaseAgreement but there is nothing in the given model allowing to link the right instance of LeaseAgreement with the right instance of Flat, that means the model as it is do not say for which flat a lease agreement was written.
In the second case there is no ambiguity, each couple of instances Flat and Tenant is associated with (in fact throw) the right instance of LeasingContract
The notation in your lower picture is called Association Class (see this wiki). Bascically it's a shortcut for a 1-* AC *-1 relation where AC is connecting two classes so you can add attributes and operations. In your example the AC is Leasing contract and it would add information about duration, payment, etc. And the two * were taken from the * left and right on the AC's association's far ends. So this would be an equivalent of your lower diagram:
I have a hard time understanding the concept of association class as explained in UML 2.5 specification. The thing that confuses me the most is the following sentence taken from page 199:
NOTE. Even when all ends of the AssociationClass have isUnique=true, it is possible to have several instances associating the same set of instances of the end Classes.
As noted here: https://issues.omg.org/issues/UMLR-757 this single sentence seems to undermine the usefulness of the concept. At the same time, it makes pretty much every text explaining the concept written before 2.5 version of the UML spec obsolete – see for example the discussion here: UML association class - clarifying
But how can this actually work conceptually? Assuming all ends of the association class have isUnique=true, how can one have more than one instance of association class associating the same set of instances of the end classes, when isUnique property of member ends clearly forbids existence of such links?
I’ve always thought that an association class is just a regular association with extra attributes and/or operations. That interpretation seems to invalid now. So what exactly is association class? How can it have uniqueness independent from that of association member ends? There seem to be some unspoken multiplicity lurking somewhere (uniqueness is irrelevant property without maximum multiplicity higher than 1), but I can't figure out where.
In very short
Indeed, this is not super-clear and would deserve a better explanation. To make it short: it’s just a consequence of the lack of integration in the dual semantics defined for the association class.
Detailed explanation
What is uniqueness for an association
According to UML 2.5.1 section 11.5.3.1, page 197:
When one or more ends of the Association have isUnique=false, it is possible to have several links associating the same set of instances.
We can deduct using logical contraposition that:
If it is not possible to have several links associating the same set of instances, all ends of the association have isUnique=true.
So we'd expect this to apply to an assocation class as well, since the association class is also an association.
Association classes are two distinct things at the same time
According to UML 2.5.1 section 11.5.3.2:
An AssociationClass is both an Association and a Class, and preserves the static and dynamic semantics of both.
So, an association class is not just "an association with extra attributes". If it were that simple, the association class could perfectly be a generalization of an association: the specialized association would just inherit the extra attributes. But this is explicitly prohibited page 199:
An AssociationClass cannot be a generalization of an Association or a
Class.
because any specialization into a class would loose the association semantics, and any specialization into an association would loose the class semantics.
And this duality, is the cause of our issue.
Impact of this duality on instances
According to UML section 11.5.3.2, page 199 (formatting from me):
An instance of an AssociationClass has the characteristics both of a link representing an instantiation of the AssociationClass as a kind of Association, AND of an object representing an instantiation of the AssociationClass as a kind of Class.
If isUnique=true for all association ends, the instances of the association are guaranteed to be unique. Remind however that the association is only about tuples made out of the association ends:
An Association declares that there can be links between instances whose types conform to or implement the associated types. A link is a tuple with one value for each memberEnd of the Association, where each value is an instance whose type conforms to or implements the type at the end.
However, nothing in the specs requires that the class instantiation (object) representing the association instantiation needs to be unique.
Imagine for example, that we have an association class between class A and class B, and a and b are instances of these classes. Imagine that the association ends have isUnique=true. This means that there can be only one tuple (a,b) since the association is guaranteed to be unique.
Let P be a property of the association class, and let (a,b,p1) and (a,b,p2) be two instances of the class in the association-class. The class knows no association-ends: from the point of view of the class, there is no unicity requirement. And from the point of view of the association, we have only one tuple (a,b) , so it's ok as well.
The NOTE just explains that this (unfortunate and ambiguous) situation is possible.
Are there contradictions or inconsistencies?
Formally, there is no contradiction. This is the result of the way the association class is defined: a class and an association at the same time, without further defining the relationship between the respective instances.
But this creates some issues in regard of the semantics of associations having non-unique ends:
When one or more ends of the Association have isUnique=false, it is possible to have several links associating the same set of instances. In such a case, links carry an additional identifier apart from their end values.
More precisely, this makes the the association-class with unique ends useless, since the same result can be achieved with non-unique ends:
for a simple association with non-unique ends, you can have duplicates, i.e. several links associating the same instances of the association ends that are distinguished with an additional identifier.
for association classes with unique ends, according to the note you can have duplicates, i.e. several objects (class instances) corresponding to a link made of unique association ends (association instances).
for an association-class with non-unique ends, you could have duplicates, i.e. several object instances correspond to the same set of member ends. It makes no difference if you interpret this as several links associating the same instances of the association ends, each associated with a single object, or, if you interpret this as one link associating a unique set of instances of the association end, that would be each be associated to mutliple object instances.
IMHO, this is unfortunate:
it does not match our mental model in which an association class with all association ends having isUnique=true should have a unique object instance of the class for a unique combination association ends. This clearly goes against the principle of least astonishment: I started with deny and it took me a while to accept this, since it was so terribly different from the traditional ways to implement association classes.
two different models, one with unique association ends, and one without could in fact express the same situation.
A simple solution to this issue would be to require a unique class instance (object corresponding to the association class) to correspond to a link that uniquely associates association ends. In that way, unique association ends would imply unique association object, without requiring other changes to the UML specs.
I work in cattle production and I am learning about database design with postgreSQL. Now I am working on an entity attribute relationship model for a database that allows to register the allocation of the pastures in which cattle graze. In the logic of this business an animal can be assigned to several grazing groups during its life. Each grazing group in turn has a duration and is composed of several pastures in which the animals graze according to a rotation calendar. In this way, at a specific time, animals graze in a pasture that is part of a grazing group.
I have a situation in which many grazing groups can be assigned to many animals as well as many pastures. Trying to model this problem I find a fan trap because there are two one-to-many relationships for a single table. According to this, I would like to ask you about how one can deal with this type of relationship in which one entity relates to two others in the form of many-to-many relationships.
I put a diagram on the problem.
model diagram
Thanks
Traditionally, using a link table (the ones you call assignment) between two tables has been the right way to do many-to-many relationships. Other choices include having an ARRAY of animal ids in grazing group, using JSONB fields etc. Those might prove to be problematic later, so I'd recommend going the old way.
If you want to keep track of history, you can add an active boolean field (to the link table probably) to indicate which assignment is current or have a start date and end date for each assignment. This also makes it possible to plan future assignments. To make things easier, make VIEWs showing only current assignment and further VIEWs to show JOINed tables.
Since there's no clear question in your post, I'd just say you are going the right way.
I have two situations where I would want something like this. In my model, I have a Message which concerns either one or two Persons. Furthermore, the message has an association with two Addresses, i.e. a from Address and a to Address.
In the first situation with the two Persons, I would like to specify an association between Message and Person multiplicity of 1---1..2 or specify two associations, one with 1---1 and the other with 1---0..1. However, I cannot (or don't know how to) set the multiplicity to two. I can imagine that it might be possible to set it to 1--* with a constraint set to maximum 2 (however I don't know how to do that).
By adding the two associations I feel a bit weird when I look at the Message side because both associations have a 1 there which would indicate a Person should have two Messages related to it. I might want something like 0..1 on the Message side for both associations with an xor constraint on them or something, but I don't know if that is good practise or even possible in EF.
For the second situation, the problem is quite similar, except that there is always a from Address and always a to Address. Setting the multiplicity 1--* doesn't seem right to me. Here I would imagine there should definitely be two associations, a from and a to association (which happen to both go to the Address entity). This however results in the same problem on the Message side of having two 1's or two 0..1's.
So my question is, how do I model this correctly in an EDM?
Thanks in advance.
Update 1:
To clarify the question, I will give a little background information on why I need such a model. I have to be able to create a message. In this message I have to specify whether it concerns one or two persons. Of these persons I specify the first name, last name and some other non-unique properties (two people can have the same name). I could dump all these properties in the Message entity (fname1, lname1, fname2, lname2), but that seems a bad idea. Hence the Person entity was born. However, this might look like a Person can be linked to many messages, but this is not the case. There can be two different persons with the same properties. There is no way of telling whether these persons are actually the same person in real life or not.
In the case of the addresses, a similar argument holds. Two addresses can be spelled a bit differently, but if I write them on a letter and mail it, they will both arrive at the same location (e.g. sesamestreet or sesamestr.). So I don't have one Address entity connected to multiple Messages. Again, the only reason Address is a separate entity, is because I have two of em with exactly the same properties.
From a database design point of view this might not make sense, from a class diagram perspective it might make a bit more sense. I was under the impression that the EDM in EF should not be like a database design, but more like a domain model, so I hope I did the right thing.
Update 2:
I just thought of what I think might be the best way in this case. Because there is virtually no difference between Person1 and Person2 I feel like making the association between Message and Person 1..* acceptable. The fact that many means two will be something for lower layers to handle. In the address case, the from and to are quite different. They are both addresses, but I don't feel I can make em a list. I could split the from and to address into separate entities and let them inherit from Address. Then associate Message with each of the subclasses. It might seem a bit overkill, but you could reason that a from address might at some point have different requirements than a to address and hence different properties.
I am not 100% happy though (especially with the address part). This solution might or might not be OK, but I feel like it avoids the core problem.
For the first problem (Message - Person):
The crucial question is: do you want person1 to be non-nullable? And person2?
The second alternative you sketched looks pretty okay to me considered that you require a message to have exactly 1 Person1 (say: creator of the message), so a non nullable property. Person2 (say: person who last updated the message) can be either null or linked to an existing person. Fine!
What you see from the person class perspective is that it has two associations (and 2 navigation properties, which you collapsed...) one for thos messages where a specific person (instance of person entity) is the creator of and one for those messages where this specific person was the last updater. Pretty Fine! Isn't it? This way you can query the model from the perspective of the message (give me all messages and also the persons of each message that created it and last updated it...) Or...query a person and collect all messages that this person created or was the last updater of...get it?
But all comes down to determining if you allow nullability for Person1 and Person2.
I didn't read your second question, but think it's more of the same. need some advice with that one too? Just call me.
Furthermore. If from a business / functional viewpoint it's enough to have two persons then alternative 2 is the way to go. If on the other hand you want a complete history of persons how updated the message and also the one who created it (this will always be exactly one) you end up with one navigation property Message.Creator (exactly one) and Message.Updaters (0 to many). You see? From the person's viewpoint they may be the creator of messages (0 to many) or updater of messages (0 to many).
Phew...Fortunately you saw the importance of decompiling the message entity into more logical and reusable entities like person, message and adress. In my humble opinion you should have this design ->
Hence the Person entity was born.
However, this might look like a Person
can be linked to many messages, but
this is not the case. There can be two
different persons with the same
properties. There is no way of telling
whether these persons are actually the
same person in real life or not.
This sounds so strange to me...Although there might be incorrect input e.g. two persons reflecting one real-life person but with typo's for instance. But still a person could have more messages or not... And when it's really not the case you can handle this in your business code to prevent a specific person to be coupled to more than one message...
**** Update *****
I should model it this way: