When creating references between ECore entities there is the possibility to mark a reference as "containment".
Can somebody explain me in easy words what's the difference between a plain reference and a containment? The definitions and explainations I found so far didn't do the trick for me.
Reference: A reference is a plain "A knows B" relation. Separate references do not influence each other. A can know B and B can know C. Hence, if you have A, you can go to C over B. If you remove the reference, A, B and C will still exist, they just don't know each other any more.
Containment: A containment is the "A has B" kind of relation. Usually used for lists, e.g. "A has multiple B". ECore/EMF can then perform atomic commands on such collections, such as move all objects from one containment to another. It can also enforce constraints, such as a minimum amount of contained objects or a maximum amount of contained objects, or ensuring that the contained object is not contained in any other containment.
Example:
Assume you have an object called ShoppingCart with a reference called Customer and a containment called OrderedProducts. The OrderedProducts has a reference to a Product.
What does this model tell you?
You can assign a Customer to the ShoppingCart. If you remove the Customer from the ShoppingCart, the Customer object itself will still exist (e.g. in the database)
The OrderedProduct objects need a ShoppingCart to exist. If you remove one from the ShoppingCart, it will cease to exist.
Each OrderedProduct has a reference to an existing Product in the database. If you remove one of the OrderedProducts from the ShoppingCart, the Product in the database will still be there - just the order of that product for that specific customer is gone
Reference : can be like association in UML
Containment : is the composition relation from UML
Also this can be seen in the EMF diagram, if you set the containment to true, then the line will have a filled side, showing the containment/composition. This is what I have observed.
Related
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 am new to CoreData environment and I'm trying to understand how it works.
In my project, I have a superclass VetExam whose subclasses are Examination, Treatments and Vaccination, which share the same attributes of their superclass and has a reference to Pet class. On the other hand, Pet class holds an array of reference of every class except of VetExam, which should only be used for Polymorphism (so that I can use VetExam object and create a single view for each type).
Based on this model, I've tried to create entities in CoreData, but it seems that I have to specify for each type the inverse relationship for each entity. This represent a problem since from VetExam entity side the relationship is of type Pet but on Pet side is To-Many for each type of Examination, which does not allow me to get the inverse reference of VetExam.
Since this explaination can easily be misunderstood, I will show you the visual representation of it.
The problem is in VetExam entity, whose Inverse attribute is not known.
Does anyone know how to deal with this type of situation?
A preliminary note on inheritance...
Class inheritance
AND
Entity inheritance
For the second, I highlight the note in the Apple Documentation:
Be careful with entity inheritance when working with SQLite persistent
stores. All entities that inherit from another entity exist within the
same table in SQLite. This factor in the design of the SQLite
persistent store can create a performance issue.
What this means is that Core Data framework creates one large table in the SQLite database that includes the parent entity and the child entities. Such a large table inherently contains inefficiencies. While this may seem convenient for you to manage now in your model editor and in your NSManagedObject subclasses, this may cause inefficiencies / performance issues in the long run if you expect your app to persist and retrieve large amounts of data in the four entities you mention.
Advice from others is very relevant here because four separate entities will in my humble opinion be easier to manage, rather than one parent entity and three child entities. You do not have to give up the class inheritance you’ve developed in your code if you choose this option.
So, to answer your question...
My logic:
Every Pet may have many instances of VetExam during its life, but each instance of VetExam is carried out on only one Pet?
If yes, then create a one-to-many relationship between Pet and VetExam -
Pet <—>> VetExam.
Whatever occurs during the VetExam is any combination of one Examination, Treatment and/or Vaccination. That is and in an attempt to be clear, the VetExam may optionally have an examination, but it may not have a treatment or a vaccination. This is likely to change for each VetExam, therefore this is directly related to the VetExam, not the Pet.
If yes, then create optional one-to-one relationships between VetExam and the entities Examination, Treatment and Vaccination.
VetExam <—> Examination
VetExam <—> Treatment
VetExam <—> Vaccination
In this model, each entity relationship detailed above has an inverse.
Finally, it might be worth noting that in this proposed model, the relationship between a Pet and all the examinations, treatments and vaccinations it receives during its lifetime is stored against PetExam, not directly against the Pet.
In my UML class diagrams I usually do object collections by placing the attribute name above the arrow that relates both classes (as opposed to the other notation that just adds the attribute with brackets indicating the multiplicity).
But I have cases in which there are more than one collection of the same kind of object. For example (a very simple example off the top of my head):
Let's say there is a course that has some students who applied for it (so I have a collection of students, let's say an attribute that is an ArrayList of Student, called "applied"). But also, I need to keep a separate collection of the students who actually attended the course (let's say, "attended": another attribute that is an ArrayList, or even a different collection type, like a Vector, of Student).
Should I just add all attribute names on the relationship line?
I'm looking to do this the standard UML way. Only clarifying this because I know UML rules can be flexible when we need them to.
UML does allow for multiple associations between classes using roles.
You would simply draw two arrows:
See here for a similar question where the diagram is taken from.
I have three entities, A, B and C.
Where A has a to-many relationship with B
and B has a to-many relationship with A
Then C has a to-one (correct terminology?) relationship to A, and a to-one relationship to B.
However I want it so C's relationship with A must be an instance of A that is in a relationship with the B related to C.
Normally in code I'd use NSArrays in place of relationships and then in C have store the index of the needed instance. This is my first time using CoreData, so I'm unsure about most of it.
EDIT: To clarify:
First, it'd be easier to discuss your situation if you'd avoid using b to mean several different things. There are four relationships in your diagram; for the sake of the discussion, you could name them d, e, f, and g.
To answer your question, you can't and don't need to include the kind of restriction that you're talking about in the model. The model defines relationships between kinds of managed objects, but it doesn't say anything about individual objects. It's usually better to try to think in terms of objects when you're learning Core Data, but you should know that the entities you define in the model are analogous to tables in a relational database: they define can be stored, not what the code should or must (or must not) store.
To restrict C.a to one of the A's in C.b.bs, you'll need to write some code. If C.a is only set in one place, you might choose to implement the restriction in that code. If the restriction is essential to the proper operation of C, you might instead (or in addition) choose to add a check to the setter for C.a that verifies that the A is one of the allowed ones. You may also need to fix up the setter for C.b so that if C.b changes, it verifies that C.a is still valid and does something appropriate if it's not (clear C.a, pick a new C.a, refuse to accept the new C.b, post a notification, throw an exception, whatever).
I've download a trial of Altova UModel and am starting using UML. As a practical beginning I am modelling a personal information manager application, which includes a web bookmark managing.
A Bookmark can belong to many (or no) Tags at once and a Tag can contain many (or no if all the bookmarks it contained were deleted) bookmarks. The relation has to be both-way navigable - a user has to be able to see all Bookmarks with a particular Tags ans all Tags of a Bookmark.
What is the correct UML relation between Bookmark and Tag classes?
As far as I understand UML now, it is an Association (not an Aggregation). But for a 2-way navigable many-to-many relation I can specify ends roles as "memberEnd" or "when navigableOwnedEnd", graphically the connection looks the same in both cases (an arrow) (which as I understand means navigability) but a property appears in the class box in case only when "memberEnd" is used.
How should I specif it in the model If I mean both-way navigable many-to-many relation there?
From UML Superstructure Specification, v2.1.2 section 7.3.3:
memberEnd : Property [2..*]
Each end represents participation of instances of the classifier connected to the end in links of the association. This is ordered association. Subsets Namespace::member.
ownedEnd : Property [*]
The ends that are owned by the association itself. This is an ordered association. Subsets Association::memberEnd,
Classifier::feature, and Namespace::ownedMember.
navigableOwnedEnd : Property [*]
The navigable ends that are owned by the association itself. Subsets Association::ownedEnd.
So if the end is 'owned' by the association, use the ownedEnd/navigableOwnedEnd type, otherwise use the memberEnd type.
Either can be used for a 'both-way navigable many-to-many relation'; if each relation link is a separate instance in your design, it can own the ends (e.g. class A and class B has a reference to a list of pairs of references to related As and Bs), but if the relation link is implicit then it does not own anything (e.g. class A has a list of references to related Bs, class B has a list of references to related As).
Having used UML since the late `90s, you're the first person I've met who cared about the difference!