I understand the difference between aggregation and composition but I am struggling a bit with association. My current understanding is that an association exists between classes when ‘they use each other’, for example, one object is passed to the other during a method call. See also:
http://www.codeproject.com/Articles/330447/Understanding-Association-Aggregation-and-Composit
Both objects exist independently and, in contrast to aggregation, no object is a container class of the other. Does this mean that both objects MUST have a copy of the other(s) (e.g. 1:m relationship) or how else is the association ‘stored’. Any feedback would be very much appreciated.
From the UML Superstructure 2.4.1:
An association declares that there can be links between instances of the associated types. A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end. (UML Superstructure, Page 37)
Nothing more, nothing less. and very vague. Because of this, it is also very hard to understand. What I defined (In a course I teach) is a hierarchy of links from dependency to composition where:
Dependency from A to B means that A uses B but indirectly (say by receiving instances of it and forwarding them to other objects).
Association from A to B means that A uses B directly, (for example by calling methods)
Aggregation from A to B means that B is part of A (semantically) but B can be shared and if A is deleted, B is not deleted. Note that this says nothing about how the "is part" is implemented.
Composition from A to B is like Aggregation, where B cannot be shared and if A is deleted, all of its aggregates (Bs) are deleted also.
Aggregation is an Association relationship where the Association can be considered the containing class 'Owning' the contained class, and the lifetime of that relationship is not defined.
Association is an 'Has-A' relationship.
Example:-
public class Person
{
private final Name name;
private Address currentAddress;
//...
}
In this case, the Person Has-A name and Has-A Address, so there is an Association between Person and Name, and Person and Address.
An association describes a relationship between instances of one or more classes. In the words of the UML Reference Manual, "Associations are the glue that holds together a system."
Aggregation is a form of association in which there is a "whole-part" relationship. You may say that if a class Airplane has a class Engine then this forms a "whole-part" relationship.
Aggregation
Let's set the terms. The Aggregation is a metaterm in the UML standard, and means BOTH composition and shared aggregation, simply named shared. Too often it is named incorrectly "aggregation". It is BAD, for composition is an aggregation, too. As I understand, you meant you understand "shared aggregation and composition".
From UML standard:
Precise semantics of shared aggregation varies by application area and
modeler.
I haven't found a word about that aggregation supposed multiplicity, for example.
Association.
A definition from UML 3.4.1 standard:
An association describes a set of tuples whose values refer to typed
instances. An instance of an association is called a link. A link is a
tuple with one value for each end of the association, where each value
is an instance of the type of the end.
Aggregated relationship is a subclass of Association.
Association is based on relationship. IT is the glue for models.
But your feelings didn't lie - as the shared aggregation is not strictly defined, there is also NO any strictly defined boundary between Association and Aggregated association. Authors of tools and modellers have to set it themselves.
Association
It represents a relationship between two or more objects where all objects have their own lifecycle and there is no owner. The name of an association specifies the nature of relationship between objects. This is represented by a solid line.
Let’s take an example of relationship between Teacher and Student. Multiple students can associate with a single teacher and a single student can associate with multiple teachers. But there is no ownership between the objects and both have their own lifecycle. Both can be created and deleted independently.
Aggregation
It is a specialized form of Association where all object have their own lifecycle but there is ownership. This represents “whole-part or a-part-of” relationship. This is represented by a hollow diamond followed by a line.
Let’s take an example of relationship between Department and Teacher. A Teacher may belongs to multiple departments. Hence Teacher is a part of multiple departments. But if we delete a Department, Teacher Object will not destroy.
It depends on the context.
Association: A man drives a car, focus on the caller and callee relationship.
Aggregation: A man has a car, focus on the owner and member relationship.
Composition: A man has a mouth, focus on the owner & member but the owner consists of members, it means that they shared the same life cycle.
Feels like I'm speaking Chinglish.
Association
Association is a relationship where all objects have their own life-cycle and there is no owner. Let’s take the example of Teacher and Student. Multiple students can associate with a single teacher and a single student can associate with multiple teachers but there is no ownership between the objects and both have their own life-cycle. Both can create and delete independently.
Aggregation
the objects in Aggregation have their own life-cycle but there is ownership. Child object can not belong to another parent object. Let’s take an example of Department and teacher. A single teacher can not belongs to multiple departments, but if we delete the department teacher object will not destroy. We can think about the “has-a” relationship.
Composition
It is a strong type of Aggregation. Child object does not have their life-cycle and if parent object deletes all child object will also be deleted. Let’s take again an example of the relationship between House and rooms. House can contain multiple rooms there is no independent life of room and any room can not belongs to two different houses if we delete the house room will automatically delete.
An association between object types classifies relationships between objects of those types. For instance, the association Committee-has-ClubMember-as-chair, which is visualized as a connection line in the class diagram shown below, may classify the relationships FinanceCommittee-has-PeterMiller-as-chair, RecruitmentCommittee-has-SusanSmith-as-chair and AdvisoryCommittee-has-SarahAnderson-as-chair, where the objects PeterMiller, SusanSmith and SarahAnderson are of type ClubMember, and the objects FinanceCommittee, RecruitmentCommittee and AdvisoryCommittee are of type Committee.
See also my alternative CodeProject article.
Related
In OOP when a class forms a HAS-A relationship with another class, it's called an Aggregation, a simple example of that is below where a Car has an Engine but an engine can exist without a car:
class Engine {
start() {
console.log('Engine started');
}
}
class Car {
engine: Engine;
constructor(engine: Engine) {
this.engine = engine;
}
}
Question:
If i had to do the inverse of Aggregation such that i could answer a query Give me all the cars associated with this Engine, what is that called in OOP?
The aggregation (or composition, or association) is a concept: it allows to say that A has a B. You can invert the composition (B has an A) but the concept itself has no "inverse". Or it would be: A does not have B !
has-a as a static relationship gets translated to Aggregation. In a typical Object oriented modeling, after identifying the static relationship between two entities, next question we ask is which is more frequent direction in which we will be raising the queries.
In your example it is one-to-one relationship between objects (vehicle has only one engine and engine is mounted on only one vehicle at given moment).
If most of the time the query is getMeThisVehiclesEngine() (container to contained), then Vehicle holds the reference of engine, if the query is opposite (I think this is kind of your inverse) like getMeTheVehicleWhichIsHoldingThisEngine() (content to container. Here container and content terms are from the domain perspective), then engine will hold the reference of vehicle, and I would call it association. If we need bidirectional navigation, both objects keep each others reference. (In general we avoid bidirectional relationship). with one to one relationship, its not that obvious, but imagine an example of shared aggregation with has-a relationship between Athletics Team and member-student. member-students can be part of different teams simultaneously. From team to student-member I would call it as aggregation and Team will hold collection of Students. From Student-member to Team I would call it association (Student is associated with Athletics Team) and Student will hold either simple reference of Athletics team, or collection of Teams, if Student can be member of multiple teams simultaneously.
I'm learning about the principles of OOP and was doing this exercise question.
We are given a school. The school has classes of students. Each class has
a set of teachers. Each teacher teaches a set of courses. The students
have a name and unique number in the class. Classes have a unique text
identifier. Teachers have names. Courses have a name, count of classes
and count of exercises. The teachers as well as the students are people.
Your task is to model the classes (in terms of OOP) along with their
attributes and operations define the class hierarchy and create a class
diagram with Visual Studio.
I am not sure how to ensure the parts in bold. What I was doing was just normally making the adjectives properties. I am not sure how to ensure that other objects are not able to have the same unique number. I was thinking of using the Dictionary data structure which doesn't allow duplicates. I would use this unique number as the key and the object to be its value. Is my line of thought correct here?
you can have for example static private array property (same for every instance of a class) in class, and on the constructor You can check if this value had been used
In the question I'm doing at the moment gave two confusing sentences:
1. A property can be either be a house or an apartment. For a house it records ..bula bula
For an apartment, it records .. bula bula
2. A property can be either for sale or rent, or for both. If a property is for sale, it
records .. bula bula. If the property is for rent, it records .. bula bula
These two are in the same question. Do I have to represent it by using subclasses or how?
Many thanks.
Yes, a entity can have multiple subclasses and multiple superclasses. Both faculty staff and student assistants may be subclasses of employees, and a student assistant may be a subclass of both employees and students.
You can create a Property entity with four subclasses, House, Appartment, PropertyForRent and PropertyForSale.
A property may not be both a house and an appartment. Therefore, use a circle with a d in it to indicate that it is disjoint. A property may be both for rent and for sale. Use a circle with an o in it to indicate that it may overlap.
This is described on page 443 in Advanced Data Modelling, and another example can be found on page 30 of this presentation.
Sjoerd's answer is correct.
ER modeling tells you how to diagram subclasses, but it doesn't tell you how to implement them. Nor should it.
If you are interested in designing SQL tables that implement subclasses, look up these topics, or their tags in SO:
Single Table Inheritance
Class Table Inheritance
Shared Primary Key
Assume I have a composite relationship, say a Customer having a collection of Orders (and assuming an Order cannot exist without an "owning" Customer.) So, I'm not talking about aggregation.
What terms are used to describe the roles in this relationship? I might say the Customer is the "owner" of an Order and maybe the Order is "owned", but surely there are better terms, terms that can be stated without referring to the other role.
I'm trying to determine these terms so I can propertly name attributes in a meta model. I can "make something up", but would like to use names that will be easily understood.
Thanks in advance for suggestions and/or pointers to definitive sources.
Bill
You want the "has a" relationship; our thing "has a"nother thing attached, as opposed to inheritance of "is a" relationship. You can build fairly robust models around just those two relationships. But.
To postulate further, in Topic Maps (since we're talking about meta models) we have a few in-built relationships which also has global identifiers (which you could use for global knowledge / data exchange), which are the supertype-subtype (denotes hiearchies) and the type-instance (denotes typification, a strongly typed "is a") relationships. These are fairly global (meaning, also outside the Topic Maps world). Have a look at the end of the Topic Maps Data Model for more on this.
This is also called the "has a" relationship. The Customer object "has a" collection of Order objects. Where as in inheritance, you'd say the Customer "is a" Person. You could also say the collection of Orders is a field or member or whatever you're language calls member variables. You'd just call the Customer an object (or a composite type). Most classes are composite types anyway, unless there's no state (i.e. just methods/behavior).
I'm using an ORM (SQLAlchemy, but my question is quite implementation-agnostic) to model a many-to-many relationship between a parent class and its children.. I was wondering, what would be a simple way to express the concept "one of the children is the default/main one"?
For example, I'd need to persist the following:
This Person instance has Address X and Y, the main one is Y.
I saw this implemented using a "middle" class like "PersonAddressRelation" that would contain "Person", "Address" and the "main" flag, but I think it looks a bit cumbersome.. Is there a better way?
The simplest way would be to have a join table, PersonAddressRelation, and also a DefaultAddress column on the Person table that keys to the Address table.
A couple of remarks.
M:N relationships don't specify 'parent' and 'child', as there's no parent nor a child: there are simply two entities having an m:n relationship via a 3rd entity (the intermediate entity).
'Address' is in general not a valid entity type, as semantically it has no identity, similar to a 'name' has no identity (first name, last name). You'll see this when you look at re-using an entity instance of type Address: you won't do that in general. (though you will re-use a Customer entity instance for example, when the customer has multiple orders)
You want to specify an attribute on the M:N relationship (default), as it belongs there. This means that the relationship itself forms an entity (which is the intermediate entity, often it has just two FK fields forming the PK). This is called an 'objectified relationship', as the relationship itself is seen as an entity. Other examples of this are Employee m:n Department and you want to specify the StartDate an employee started for a department the employee works for.
So in general: create the intermediate entity, as it in general should be there, and add the attribute there. In this particular case with Address, be really sure you are re-using Address instances among related entities (Person). If not, merge Address with Person OR if a person can have multiple addresses, create a simple 1:n relationship between Person - Address, to normalize it out, though don't be afraid to merge address data into the entity it is related to, as often address data is really not re-used (so your m:n relationship is really not there: there's no Address instance which is related to multiple person instances.