I have a Proffesor table in a database. I would like to create an UML diagram for the code-behind part.
The class structure would be:
- a Proffesor class that maps the information from the database table (id, first name, etc)
- a ProffesorDAL class which connects to the DB and queries it in order to add,remove,update Proffesor instances
- 3 forms which add/delete/update proffesors, by accesing the ProffesorDAL class
I thought that the forms-ProffesorDAL relationship is a composition relationship. Is this correct?
How about the ProffesorDAL-Proffesor relationship, could it be aggregation or is it just association? What's the best UML relationship for the forms-Proffesor relationship?
Thanks!
I'd start by assuming association and from there to analyse and design if there should be a stronger relation between the two.
My question goes "Does it own it". Example I'd say a Car owns 4 wheels (among a long list of other items).
In my standard design I have a BLL between my UI and DAL. I start by assuming a loose association between my three, later I reach the conclusion that the BLL and DAL are somewhat closely connected and could benefit from a strong tie.
As for the Professor class, I assume this to be a Model class. Model classes I only have a loose connection / knowledge to - meaning they appears only as parameters (association). My DALs do not have a strong connection with my Model classes (aggregation). They are but Message bringers, complex ints and bools.
The UML Aggregation relationship is almost worthless - it creates far more confusion than value. It has only one useful property, namely that if used in a recursive relationship, the resulting object structure is acyclic.
It's really not worth getting hung up about. My advice would be to use a simple binary association and concentrate on getting the cardinality right. That's a lot more useful and valuable.
hth.
Related
Here I am, with another question about aggregation and association. I wanted to learn some basics of UML, so I started reading "UML distilled" by Martin Fowler. I read both chapters about classes, and there is one thing that I can't fully grasp I think, and that is aggregation vs association. In the book there is this quote:
In the pre-UML days, people were usually rather vague on what was aggregation and what was
association. Whether vague or not, they were always inconsistent with everyone else. As a result,
many modelers think that aggregation is important, although for different reasons. So the UML
included aggregation (Figure 5.3) but with hardly any semantics. As Jim Rumbaugh says, "Think of it
as a modeling placebo" [Rumbaugh, UML Reference].
As I understand from this quote and topics that I read on Stack Overflow it doesn't matter which one of those two relations I use, they mean basically the same, or is there any situation where the usage of aggregation instead of association would be justified and/or I could not change one to the other without changing the "meaning" of a class diagram?
I am asking this, because this book is from 2003 and some things could have changed during those few years.
Maybe this can help you, but i don't think you will find the perfect explanation:
The difference is one of implication. Aggregation denotes whole/part
relationships whereas associations do not. However, there is not
likely to be much difference in the way that the two relationships are
implemented. That is, it would be very difficult to look at the code
and determine whether a particular relationship ought to be
aggregation or association. For this reason, it is pretty safe to
ignore the aggregation relationship altogether. [Robert C. Martin | UML]
And an example for each situation:
a) Association is a relationship where all object have their own
lifecycle and there is no owner. Let’s take an example of Teacher and
Student. Multiple students can associate with a single teacher and
single student can associate with multiple teachers, but there is no
ownership between the objects and both have their own lifecycle. Both
can create and delete independently.
b) Aggregation is a specialized form of Association where all object have their own lifecycle but there is ownership and child
object can not belong to another parent object. Let’s take an example
of Department and teacher. A single teacher can not belong to
multiple departments, but if we delete the department, the teacher object
will not be destroyed. We can think about “has-a” relationship.[Maesh | GeeksWithBlogs]
Rumbaugh's statement is the most telling and Uncle Bob's good advice. As I've said elsewhere, Aggregation is semantically so weak as to offer nothing practically beneficial. It only has one valid corner case (acyclicity of recursive relationships) however few people know and understand that. So you end up having to point out in comments anyway.
I just don't use it. And have never felt any loss. Stick with simple binary associations and focus on what really matters - getting the cardinality and naming right. You'll get far more from that than trying to decide the undecidable association vs. aggregation.
hth.
I tend to use Aggregation to show a relation that is the same as a Composition with one big distinction: the containing class is NOT responsible for the life-cycle of the contained object. Typically, a (non-null) pointer or reference to the object-to-be-contained is passed to the containing class's constructor. The containing object, for the duration of its life-cycle, depends upon the contained object existing. The containing object cannot do its job (fully) without the contained object. This is my interpretation of the "Part/Whole" relationship implied by Aggregation.
This term often gets confused.
Aggregation and composition are some of the types of association. There is
hardly a difference between aggregations and associations during
implementation, and many will skip aggregation relations altogether in
their diagrams with association relation.
You can get the idea from this analogy.
Class:A(person) and Class:B(car) has association relation, if
Class:A has a Class:B declaration, and also Class:B(car) object is not essential to create a Class:A(person) object.
Class:A(car) and Class:B(tyre) has aggregation relation, if
Class:A has a Class:B declaration, and also Class:B(tyre) object is essential to create a Class:A(car) object.
Cheers!
In UML aggregation is under-defined and since they haven't got any clearly defined semantic.
A valid use-case of an aggregation is the encapsulation of a several classes, as stated in "Domain Driven Design" by Eric Evans.
E.g. a car has four wheels.
You might want to calculate the total amount of meters each wheel has driven, for each car.
This calculation is done by the car-entity, since it knows which wheels it has and you don't care which wheels belong to which car.
The car is the aggregation-root for all it's parts, like wheels, and you can't access the parts of a car from outside the aggregation, just the root.
So basically an aggregation encapsulates a set of classes which belong to each other.
They do not mean the same! I can put it in this way:
Association relationship: A class references another class. Actually it shows that a class is related to another class but they
don't necessarily have attributes to show this relationship... e.g
'Teacher' and 'Student' classes, although 'Teacher' class has no
attribute that refer to students, but we do know that in reality a
teacher do have students... And also 'School' class has 'teachers' and
'students' properties that now make those two classes related to each
other.
Aggregation relationship: A class contains another class. But if the container(ClassRoom) is destroyed, the contained(Chair) is not.
Actually the ClassRoom owns the Chair. Aggregation is a more stronger
relationship than the Association relationship.
Here is also a tutorial about it and the whole UML2.0 which explains everything easy and simple, you may find it useful: https://github.com/imalitavakoli/learn-uml2
TIP: Also let me mention that because the Association relationship exists between classes most of the times, we sometimes don't draw it to prevent unnecessary complexity.
Implementation wise there is not much of a difference but conceptually there is big difference: aggregations are used to express a hierarchy. When you work with a hierarchy of components there are certain type of operations you need to have in the root interface:
find subcomponents in the hierarchy
add/remove subcomponents to/from the hierarchy
change common attributes of all components
traverse the hierarchy recursively (Visitor pattern)
reconfigure the hierarchy and the links (associations) between the components
Most of these operations are not needed when dealing with associations.
To add, I would just suggest to download the UML specification from the OMG site: best reference and see p 110.
None indicates that the property has no aggregation semantics.
Shared indicates that the property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
Composite indicates that the property is aggregated compositely, i.e., the composite object has responsibility for
the existence and storage of the composed objects (see the definition of parts in 11.2.3).
Here I am, with another question about aggregation and association. I wanted to learn some basics of UML, so I started reading "UML distilled" by Martin Fowler. I read both chapters about classes, and there is one thing that I can't fully grasp I think, and that is aggregation vs association. In the book there is this quote:
In the pre-UML days, people were usually rather vague on what was aggregation and what was
association. Whether vague or not, they were always inconsistent with everyone else. As a result,
many modelers think that aggregation is important, although for different reasons. So the UML
included aggregation (Figure 5.3) but with hardly any semantics. As Jim Rumbaugh says, "Think of it
as a modeling placebo" [Rumbaugh, UML Reference].
As I understand from this quote and topics that I read on Stack Overflow it doesn't matter which one of those two relations I use, they mean basically the same, or is there any situation where the usage of aggregation instead of association would be justified and/or I could not change one to the other without changing the "meaning" of a class diagram?
I am asking this, because this book is from 2003 and some things could have changed during those few years.
Maybe this can help you, but i don't think you will find the perfect explanation:
The difference is one of implication. Aggregation denotes whole/part
relationships whereas associations do not. However, there is not
likely to be much difference in the way that the two relationships are
implemented. That is, it would be very difficult to look at the code
and determine whether a particular relationship ought to be
aggregation or association. For this reason, it is pretty safe to
ignore the aggregation relationship altogether. [Robert C. Martin | UML]
And an example for each situation:
a) Association is a relationship where all object have their own
lifecycle and there is no owner. Let’s take an example of Teacher and
Student. Multiple students can associate with a single teacher and
single student can associate with multiple teachers, but there is no
ownership between the objects and both have their own lifecycle. Both
can create and delete independently.
b) Aggregation is a specialized form of Association where all object have their own lifecycle but there is ownership and child
object can not belong to another parent object. Let’s take an example
of Department and teacher. A single teacher can not belong to
multiple departments, but if we delete the department, the teacher object
will not be destroyed. We can think about “has-a” relationship.[Maesh | GeeksWithBlogs]
Rumbaugh's statement is the most telling and Uncle Bob's good advice. As I've said elsewhere, Aggregation is semantically so weak as to offer nothing practically beneficial. It only has one valid corner case (acyclicity of recursive relationships) however few people know and understand that. So you end up having to point out in comments anyway.
I just don't use it. And have never felt any loss. Stick with simple binary associations and focus on what really matters - getting the cardinality and naming right. You'll get far more from that than trying to decide the undecidable association vs. aggregation.
hth.
I tend to use Aggregation to show a relation that is the same as a Composition with one big distinction: the containing class is NOT responsible for the life-cycle of the contained object. Typically, a (non-null) pointer or reference to the object-to-be-contained is passed to the containing class's constructor. The containing object, for the duration of its life-cycle, depends upon the contained object existing. The containing object cannot do its job (fully) without the contained object. This is my interpretation of the "Part/Whole" relationship implied by Aggregation.
This term often gets confused.
Aggregation and composition are some of the types of association. There is
hardly a difference between aggregations and associations during
implementation, and many will skip aggregation relations altogether in
their diagrams with association relation.
You can get the idea from this analogy.
Class:A(person) and Class:B(car) has association relation, if
Class:A has a Class:B declaration, and also Class:B(car) object is not essential to create a Class:A(person) object.
Class:A(car) and Class:B(tyre) has aggregation relation, if
Class:A has a Class:B declaration, and also Class:B(tyre) object is essential to create a Class:A(car) object.
Cheers!
In UML aggregation is under-defined and since they haven't got any clearly defined semantic.
A valid use-case of an aggregation is the encapsulation of a several classes, as stated in "Domain Driven Design" by Eric Evans.
E.g. a car has four wheels.
You might want to calculate the total amount of meters each wheel has driven, for each car.
This calculation is done by the car-entity, since it knows which wheels it has and you don't care which wheels belong to which car.
The car is the aggregation-root for all it's parts, like wheels, and you can't access the parts of a car from outside the aggregation, just the root.
So basically an aggregation encapsulates a set of classes which belong to each other.
They do not mean the same! I can put it in this way:
Association relationship: A class references another class. Actually it shows that a class is related to another class but they
don't necessarily have attributes to show this relationship... e.g
'Teacher' and 'Student' classes, although 'Teacher' class has no
attribute that refer to students, but we do know that in reality a
teacher do have students... And also 'School' class has 'teachers' and
'students' properties that now make those two classes related to each
other.
Aggregation relationship: A class contains another class. But if the container(ClassRoom) is destroyed, the contained(Chair) is not.
Actually the ClassRoom owns the Chair. Aggregation is a more stronger
relationship than the Association relationship.
Here is also a tutorial about it and the whole UML2.0 which explains everything easy and simple, you may find it useful: https://github.com/imalitavakoli/learn-uml2
TIP: Also let me mention that because the Association relationship exists between classes most of the times, we sometimes don't draw it to prevent unnecessary complexity.
Implementation wise there is not much of a difference but conceptually there is big difference: aggregations are used to express a hierarchy. When you work with a hierarchy of components there are certain type of operations you need to have in the root interface:
find subcomponents in the hierarchy
add/remove subcomponents to/from the hierarchy
change common attributes of all components
traverse the hierarchy recursively (Visitor pattern)
reconfigure the hierarchy and the links (associations) between the components
Most of these operations are not needed when dealing with associations.
To add, I would just suggest to download the UML specification from the OMG site: best reference and see p 110.
None indicates that the property has no aggregation semantics.
Shared indicates that the property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
Composite indicates that the property is aggregated compositely, i.e., the composite object has responsibility for
the existence and storage of the composed objects (see the definition of parts in 11.2.3).
I found a definition for association in UML as below.
An "association" in UML is defined as a kind of relationship between
classes,which represents the semantic relationship between two or more classes that
involves connections (links) among their instances .
I am not clear what is semantic relationship. Can anyone explain it with example with comparing it with non semantic relationship?
Associations in plain text
An association is a semantic relationship. The UML clause means that there is a structural relationship between instances of the associated classes independently of any specific implementation. "Semantic" underlines that the relationship is between the instances themselves, and not just "accidentally" for an operation:
Use associations primarily where there are structural relationships among objects. Do not use them to show transient relationships such as parameters or local variables of procedures.- Booch, Rumbaugh & Jacobson in Unified Modeling Language User Guide, 2nd edition
More arguments
What is "semantic"?
The term "semantic" is borrowed from linguistics and refers to the meanings behind the words. Linguists and map words (e.g. "Car", "Driver") to their meaning (e.g. a real car, a real person), and analyze the relation between words with a view of this mapping:
So, applying this to UML (modelling language) if you'd have the classes Car and Driver, you CAN model the semantic relationship as an association between the two classes.
What is not semantic?
Not all relationships are of semantic nature. You can have dependencies, which can express a technical relationship:
a transient relationship during an operation: with a factory pattern for example, a DriverFactory would «create» a Driver instance. Both instances the factory and the driver are related only at the exact moment of the creation operation. But the two instances are completely independent the nanosecond after.The same applies if the implementation of an operation needs to create a local instance of another class. Both classes are not associated, since we could imagine another implementation that works without such an instance.
a structural dependency: Maybe an operation require some other classes as parameter. Since the parameters themselves are transient, there is no association. But nevertheless, teh class needs to know about the other class.
For the records, I'm grateful to this public domain contributor for the nice car and driver and to 18f for advice on inclusive communication.
The subject of Semantics is sense. If one thing has something that is connected by sense to another thing, it is the semantic relationship. That definition is terribly wide. And, applied to UML relationship, incorrect. It is incorrect for two reasons.
First, UML covers not only Class-Instance languages, such as Java or C++, but pure object languages with heredity created by Prototypes as well. And this second variant is not covered by your definition at all.
Second, in UML you can have class A connected to class B through some complex AssociationClass, that is shown by a box with arrows, not arrow only. And it still will be named an association and it IS a semantic relationship, too. But a the semantic relationship goes from A to B through two classes, it is still a semantic relationship, but it is not an association in UML.
If you are trying to be deep in subject, better read the UML documentation: "An Association classifies a set of tuples representing links between typed instances." (UML 2.5, pharagraph 11.5.1). Notice: ANY link between two instances can be shown as an association. Maybe the book you are reading is wholely not so bad, but in the very place that you have cited the author merely tries to use pretty words not understanding their meaning and not even trying to be understandable to readers and to be CORRECT.
A model says something about the things being modeled. This is its semantics. Almost all elements of UML have semantics, defined in the sections titled "semantics". One exception is the comment. Adding a comment to a model doesn't influence its meaning.
Then why does the UML say this explicitely about associations? The reason is, that an association may or may not say something about the structure. If it doesn't, it is purely semantic.
For example it could tell us, that a Car can have at most one Driver. It doesn't necessarily mean that the car has an attribute of type Driver.
If we want to model that the two associated classes own attributes typed by the other end of the association, the notation will show this by small dots on its ends. Many people are not familiar with this notation and interpret associations without a dot in the same way. However, without the dots attributes are owned by the association itself and the structure of the classes is not influenced.
By the way, a class being the type of a parameter of an operation or having a dependency also means a semantic relationship.
Here I am, with another question about aggregation and association. I wanted to learn some basics of UML, so I started reading "UML distilled" by Martin Fowler. I read both chapters about classes, and there is one thing that I can't fully grasp I think, and that is aggregation vs association. In the book there is this quote:
In the pre-UML days, people were usually rather vague on what was aggregation and what was
association. Whether vague or not, they were always inconsistent with everyone else. As a result,
many modelers think that aggregation is important, although for different reasons. So the UML
included aggregation (Figure 5.3) but with hardly any semantics. As Jim Rumbaugh says, "Think of it
as a modeling placebo" [Rumbaugh, UML Reference].
As I understand from this quote and topics that I read on Stack Overflow it doesn't matter which one of those two relations I use, they mean basically the same, or is there any situation where the usage of aggregation instead of association would be justified and/or I could not change one to the other without changing the "meaning" of a class diagram?
I am asking this, because this book is from 2003 and some things could have changed during those few years.
Maybe this can help you, but i don't think you will find the perfect explanation:
The difference is one of implication. Aggregation denotes whole/part
relationships whereas associations do not. However, there is not
likely to be much difference in the way that the two relationships are
implemented. That is, it would be very difficult to look at the code
and determine whether a particular relationship ought to be
aggregation or association. For this reason, it is pretty safe to
ignore the aggregation relationship altogether. [Robert C. Martin | UML]
And an example for each situation:
a) Association is a relationship where all object have their own
lifecycle and there is no owner. Let’s take an example of Teacher and
Student. Multiple students can associate with a single teacher and
single student can associate with multiple teachers, but there is no
ownership between the objects and both have their own lifecycle. Both
can create and delete independently.
b) Aggregation is a specialized form of Association where all object have their own lifecycle but there is ownership and child
object can not belong to another parent object. Let’s take an example
of Department and teacher. A single teacher can not belong to
multiple departments, but if we delete the department, the teacher object
will not be destroyed. We can think about “has-a” relationship.[Maesh | GeeksWithBlogs]
Rumbaugh's statement is the most telling and Uncle Bob's good advice. As I've said elsewhere, Aggregation is semantically so weak as to offer nothing practically beneficial. It only has one valid corner case (acyclicity of recursive relationships) however few people know and understand that. So you end up having to point out in comments anyway.
I just don't use it. And have never felt any loss. Stick with simple binary associations and focus on what really matters - getting the cardinality and naming right. You'll get far more from that than trying to decide the undecidable association vs. aggregation.
hth.
I tend to use Aggregation to show a relation that is the same as a Composition with one big distinction: the containing class is NOT responsible for the life-cycle of the contained object. Typically, a (non-null) pointer or reference to the object-to-be-contained is passed to the containing class's constructor. The containing object, for the duration of its life-cycle, depends upon the contained object existing. The containing object cannot do its job (fully) without the contained object. This is my interpretation of the "Part/Whole" relationship implied by Aggregation.
This term often gets confused.
Aggregation and composition are some of the types of association. There is
hardly a difference between aggregations and associations during
implementation, and many will skip aggregation relations altogether in
their diagrams with association relation.
You can get the idea from this analogy.
Class:A(person) and Class:B(car) has association relation, if
Class:A has a Class:B declaration, and also Class:B(car) object is not essential to create a Class:A(person) object.
Class:A(car) and Class:B(tyre) has aggregation relation, if
Class:A has a Class:B declaration, and also Class:B(tyre) object is essential to create a Class:A(car) object.
Cheers!
In UML aggregation is under-defined and since they haven't got any clearly defined semantic.
A valid use-case of an aggregation is the encapsulation of a several classes, as stated in "Domain Driven Design" by Eric Evans.
E.g. a car has four wheels.
You might want to calculate the total amount of meters each wheel has driven, for each car.
This calculation is done by the car-entity, since it knows which wheels it has and you don't care which wheels belong to which car.
The car is the aggregation-root for all it's parts, like wheels, and you can't access the parts of a car from outside the aggregation, just the root.
So basically an aggregation encapsulates a set of classes which belong to each other.
They do not mean the same! I can put it in this way:
Association relationship: A class references another class. Actually it shows that a class is related to another class but they
don't necessarily have attributes to show this relationship... e.g
'Teacher' and 'Student' classes, although 'Teacher' class has no
attribute that refer to students, but we do know that in reality a
teacher do have students... And also 'School' class has 'teachers' and
'students' properties that now make those two classes related to each
other.
Aggregation relationship: A class contains another class. But if the container(ClassRoom) is destroyed, the contained(Chair) is not.
Actually the ClassRoom owns the Chair. Aggregation is a more stronger
relationship than the Association relationship.
Here is also a tutorial about it and the whole UML2.0 which explains everything easy and simple, you may find it useful: https://github.com/imalitavakoli/learn-uml2
TIP: Also let me mention that because the Association relationship exists between classes most of the times, we sometimes don't draw it to prevent unnecessary complexity.
Implementation wise there is not much of a difference but conceptually there is big difference: aggregations are used to express a hierarchy. When you work with a hierarchy of components there are certain type of operations you need to have in the root interface:
find subcomponents in the hierarchy
add/remove subcomponents to/from the hierarchy
change common attributes of all components
traverse the hierarchy recursively (Visitor pattern)
reconfigure the hierarchy and the links (associations) between the components
Most of these operations are not needed when dealing with associations.
To add, I would just suggest to download the UML specification from the OMG site: best reference and see p 110.
None indicates that the property has no aggregation semantics.
Shared indicates that the property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
Composite indicates that the property is aggregated compositely, i.e., the composite object has responsibility for
the existence and storage of the composed objects (see the definition of parts in 11.2.3).
I have read several tutorials on what a UML model should contain and what not. As a developer I always think in terms of a relational data model where you could never have a many to many relationship between tables. Now with a UML class model, I've read that if they don't provide added value, you could just skip the linktables.
However I've also read a tutorial where examples where given using data inside tables and was strongly suggesting to picture each class as a simple table while modeling your class model.
I am confused, what is it now?!
The "relational link table" is an implementation technique for a Many-to-Many relationship.
The relationship exists irrespective of how it's implemented.
In an object model, you have many choices for how to implement many-to-many, which may (or may not) involve an additional persistent table. It could be done lots of different ways.
The point of UML is to be able to describe the essential features of what the model really is.
You can also describe the implementation. They're separate diagrams with separate purposes. You can easily show the relational implementation with the link table. You can also show the essential model without the link table.
Here's the essential relationship
Here's the implementation of the relationship
Both are valid UML. The real question is "what do you need to show other people?" Essential truth or one particular implementation?
Model it as an M:N relationship. Same as in a relationship model there will be an associate class (or link class) of some kind in code. No need to put that on the diagram unless it has attributes on top of the join attributes (much like you would generally omit a join entity from an ERD unless it had attributes that weren't foreign keys in the related entities). The link class is typically drawn as a class connected to the relationship by a dashed line.
The Enrolment join entity is a good example of this in UML 2 Class Diagrams.