I am making a class diagram. I have a Person class and an Address class. I am thinking there is a 'Has-A' relation between the Person class and Address class (Aggregation):
Am I right in marking the relationship as association?
Does it depend on us how we want the model the relationship?
For example, if I have two classes, Book and Library, I could say that Books shall not exist without a Library (composition) or I could say that Books may exist independent of library(Aggregation).
There is no one correct answer. There are many valid ways to model a scenario. In this case you could either mark the relationship between Person and Address as an association (more specifically aggregation), or you could mark it as a complex attribute.
Yes, details like that should be discussed with stakeholders / people who understand the domain you are modelling.
Is the association right?
Yes, you are right: a simple association expresses perfectly that a Person has an Address. Nobody could claim on the base of your narrative that your model would be wrong.
But modeling is a form of communication: You may well chose a different notation to add nuance in what you express, and you may decide for different semantics to tell how you see things in view of your needs.
Does it depend on us? Notation
In our example, you may want to clarify what you mean with the association by giving it a name:
Or you may prefer to clarify the role of the address in the association:
Or in complex diagrams you may prefer the shorter but equivalent property notation, nevertheless keeping in mind that "A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not":
Does it depend on us? Semantics
You could go for aggregation, but I'd strongly discourage it since UML does not define any semantic for it. So there's no benefit compared to a simple association.
You could consider composition. It might in general not be the best choice, as addresses exist independently of the persons. But in an application that creates separate Address objects for each Person, it could reveal how you intend to manage addresses.
Or you may want some richer semantics, for example with an association class to tell that people could have plenty of addresses of different kinds:
Related
I have a class Tutor and there are some instances of that class can be course coordinators, can I represent the relationship using recursive association?
this is how I represented the association at first, which I think is not correct
Quick fix
In your diagram you claim that all Tutors are coordinating exactly a single Course. It's the consequence of 1 being the same as 1..1. But this is not what your narrative says:
some instances of that class can be course coordinators.
You should therefore replace the multiplicity on the Course side with 0..1. It which would translate some Tutors can be coordinating a Course (but not all).
Another alternative
The inconvenience is that the model does not define Course Coordinators. Maybe it's just the wording and doesn't matter. But may be there is more about Course Coordinator that would justify a separate class with additional properties and behaviors:
If it's a special kind of Tutor, just make it a specialization thereof, and let this additional class have the coordinating association.
If this is a special role that a Tutor but also other classes (Professor, Assitant, ...) could take, you'd better prefer composition over inheritance (object composition in OOP corresponds to UML associations). The association between Tutor and Course Coordinator would read "have the role of".
Not related:
A couple of additional questions for you (just to ensure that the multiplicities say what you meant):
One specific Course could be taught by several Tutors ?
No Tutor could teach more than one Course ?
A specific Course could have no Tutor for teaching (because * means 0..*)?
The same Course could be coordinated by several Tutors?
I have short question about class diagrams. In my book we have class Person and class Gender and agregation arrow between them(with diamond pointing to person). Now, in general when I want to decide whether we have agregation or not I am using one of these two rules:
1.When you destroy class that is whole, than part can exist without it;
2.Class that is part in agregation relation, can be mutual to one or more wholes.
Now if we look at this example and rule number 2, it is OK, because one gender is mutual to one or more persons. But for the first one, if there is not person, than we can't talk about gender right?So I would set composition here. Probably I am missing main difference between these two. Any help is appriciated.
In general
Your rule about when using aggregation is not wrong. But it's unnecessarily complex. There is a simpler much simpler rule about when you'd better use aggregation: never.
This may sound provocative, but the hard truth is that the meaning of aggregation is not defined in the UML specifications, which makes it ambiguous and subject to a lot of unnecessary time-consuming debates:
Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. (...) Precise semantics of shared aggregation varies by application area and modeler.- UML specifications 2.5.1, page 112.
I know, it comes as a shock. For years in my career, I have myself selected very carefully aggregation whenever there was a part-whole relation with non-exclusive ownership. But when I came accross James Rumbaugh famous quote, I challenged my own assumptions and realized how vain and subjective this quest was:
Keep in mind that aggregation is association. Aggregation conveys the thought that the aggregate is inherently the sum of its parts. In fact, the only real semantics that it adds to association is the constraint that chains of aggregate links may not form cycle (...) In spite of the few semantics attached to aggregation, everybody thinks it is necessary (for different reasons). Think of it as a modeling placebo.- James Rumbaugh in Unified Modeling Language Reference Manual, chapter 14.
So, whenever you have aggregation in a model, you could simply replace it with an association without real loss of information.
In your specific example
The association: Person ----- Gender expresses perfectly that a person has a gender, and that several persons can share the same gender.
If you want to be super-accurate, you could use the dot notation (with a small dot on Gender side). This would convey the information that Person owns the end of the association.
Composition would definitely be wrong here, because it's an exclusive ownership and no two persons could share the same gender.
Aggregation is ambigous: what is the whole, what is the part? If gender is a part, wouldn't character be a part as well. And what with the name, then ?
A final remark: if you want to implement this with Person having a gender:Gender property (an OOP mechanism called "object composition") the, you don't need aggregation (even if it's a popular practice).
I understand the differences between the three( or at least I think I do). I know there are many other similar questions with definitions like this one.
I was looking an example from gliffy.com and I am strugiling to understand why some releationship were used they way they were used. I guess what I'm really struggling with is understanding when to use association.
Some of the questions I have are:
Why is Customer-Order and Customer-Credit Card an association an not aggregation like Customer-Address?
Why is Order-ItemOrder not composition given that ItemOrder would not exist without an Order?
Why is ItemOrder-Item not aggregation?
In order to answer these questions, it is important to know why this class diagram is drawn. Only the author knows, but maybe it is just a demonstration of the capabilities of gliffy? Otherwise, maybe the classes in this model correspond to classes in source code, written in an object-oriented language like Java or C# and that the diagram is aimed to give insight in the relationships among these classes.
Why is Customer-Order and Customer-Credit Card an association and not aggregation like Customer-Address?
Apparently, the author does not regard these relationships to be 'part-of' relationships. Maybe Customer does not have any reference to Orders or CreditCards in the source code. Maybe Address information belongs to the responsibility of class Customer, but Order and Credit Card information do not.
Why is Order-ItemOrder not composition given that ItemOrder would not exist without an Order?
Maybe the author only uses a subset of UML and does not use composition by convention. Maybe the author thinks the difference between aggregation and composition is not important to convey for the purpose of this diagram.
Why is ItemOrder-Item not aggregation?
Apparently, the author does not regard this relationship to be a part-of relationship. Maybe the author has reserved the aggregation type of relationship to represent one particular programming language construct, which is not used in this case in the source code. Maybe the author has the opinion that an interface can never be aggregated in another class.
By the way, the aggregation between ItemOrder and ShoppingCart is clearly wrong. I think the diamond should be on the other side of the relationship.
Simply forget about shared/composite aggregation. It does have a low semantics and just leads to futile discussions whether it's needed and where it's used right or wrong. Just use (and interpret) the association and multiplicity.
The (almost) only place where you could use aggregations in a meaningful way is in DB foreign key (force delete) and memory (free unused) management.
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.
Sorry for this newb question, i'm new to UML.
The diagram for a system is this one:
From what I know of UML, none of the classes in this diagram can own instances of the associated class as there's no aggregate relationship with it.
Does this mean in an implementation of the system in Java, based on the diagram, an outside class has to own instances of the associated class?
Sorry if the answer is obvious. I've spent hours scratching my head over it.
First off, terminology. #Daniel is right, you don't have an association class. However, I don't think you mean Association Class:
Does this mean in an implementation of the system in Java, based on the diagram, an outside class has to own instances of the associated class?
If I understand correctly that's the nub of your question. In implementation terms, which class(es) have a member variable containing a list of references to instances of Associated Class?
Again - if I understand right - your question stems from the following logic:
In UML, "ownership" is commonly described as a quality of Aggregation (or Composition) relationships.
The relationship between Aggregated/Composite PART Class and Associated Class is a simple binary association - not Aggregate/Composite.
Therefore the "ownership" property doesn't apply
Therefore who owns the list of references to Associated Class instances?
If that's right then the issue is with the specific meaning of "ownership". Whilst not tightly defined in UML, "ownership" typically means responsibility for managing full lifecycle.
I think you're interpreting it more generally: that if an association isn't aggregate, then the participating classes can't hold references to each other.
That's not the case. It's perfectly reasonable for Aggregated/Composite PART Class to hold a reference (or list of references) to instances of Associated Class. The inverse is equally valid. In some cases both are valid (with the attendant need to maintain consistency).
So in summary: is it necessary for an outside class to own the instances of Associated Class? No. It's perfectly valid for either or both ends of a binary association to manage instances of the relationship.
hth and apologies if I misunderstood your question.
PS: a final observation: be very careful about what you mean when using Aggregation. It's notoriously imprecise in the UML spec. Composition has a more rigorous definition, and you can cover 99% plus of all modelling scenarios using Composition and plain Binary Associations. About the only place Aggregation has a well-defined meaning not completely covered by the other two is denoting when recursive relationships must be acyclic.
UML does not specify the full behaviour of a system. So what do you mean, when you say an object owns another object? Also instances AssociatedClass could be root objects that are not owned by any other object.
The diagram you provided doesn't really contain an association class. The class you named 'associated class' is just a normal class. It also isn't owned by anything (that we see in the diagram).
If what you had in mind was association class, then take a look at example diagram with association class:
In this example, the MilleageCredit is an association class. So for each distinct combination of Fligh-FrequentFlyer there is one MilleageCredit.
As for ownership, since the Association class represents a relation between 2 associated objects, it gets deleted when
the association is cleared
either or both of associated objects are deleted
So if you delete either the Flight or FrequentFlyer the MilleageCredit will be gone too.
Also if you unlink Flight from FrequentFlyer again the MilleageCredit will be delete.
There's plenty of good UML docs online, for example UML basics: The class diagram
Hope this helps, otherwise please provide more info in the question.