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?
Related
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:
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'm taking the Stanford edx course (Databases: Modeling and theory) and the lecturer mentioned this piece of information about association classes and what they imply in a diagram (in reference to an example of two classes "student" and "college" associated by a "applies to" association with the association class "appInfo" containing college application info):
Now what we're saying is that association is going to have affiliated with it a date and a decision. What we cannot describe in UML is the possibility of having more than one relationship or association between the same student and the same college.
So when we have an association, that assumes at most one relationship between two objects. So, for example, if we wanted to add the possibility that students could apply to the same college multiple times so maybe, you know, they wanted to apply for different majors, that would actually have to be captured quite differently. We'd have to add a separate class for the application information with separate relationships to the students and colleges.
but I didn't really get what she meant here, does having an association class create an automatic 1-1 coupling between two classes? or is it prohibited for two classes to have more than one relationship? or what exactly is being said here because it's a bit vague and I'm not experienced in UML data modeling.
The statement is either wrong or it’s taken out of a specific context that was not mentioned here. The reasons are:
there is no implicit one-to-one in an association; the multiplicities at both end of an association specifies if it’s a one to one, a one to many, a many to many association or anything in between.
the same applies to an association class, which is both: an association and a class at the same time.
in a many to many association, there can very well be several times a link between the same objects. In fact, in a one-to-many or many-to-many association, you need to add an explicit constraint if you want to avoid this.
More information:
in this other answer, there are some more explanation about the semantic of association classes
an here a question related to uniqueness. as you will see, it is not that obvious to avoid multiple occurrences
I drives me crazy how many books contradicts themselves.
Class A {} class B {void UseA(A a)} //some say this is an association,
no reference is held but communication is possible
Class A {} class B {A a;} //some say this is
aggregration, a reference is held
But many say that holding a reference is still just an association and for aggregation they use a list - IMHO this is the same, it it still a reference.
I am very confused, I would like to understand the problem.
E.g. here: http://aviadezra.blogspot.cz/2009/05/uml-association-aggregation-composition.html - what is the difference between Strong Association and Aggregation, in both cases the author uses a field to store the reference..
Another example:
This is said to be Association:
And this is said to be Aggregration:
public class Professor {
// ...
}
public class Department {
private List<Professor> professorList;
// ..
}
Again, what is the difference? It is a reference in both cases
This question has been, and will be, asked many times in many different variants, because many people, including many high-profile developers, are confused about the meaning of these terms, which have been defined in the UML. Since the question has been asked many times, it has also been answered many times. See, e.g. this answer. I'll try to summarize the UML definitions.
An association between two classes is not established via a method parameter, but rather via reference properties (class attributes), the range/type of which are the associated classes. If the type of a method parameter is a class, this does not establish an association, but a dependency relationship.
It's essential to understand the logical concept of associations first, before looking at how they are coded. 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.
An association is always encoded by means of reference properties, the range/type of which is the associated class. For instance, like so
class Committee { ClubMember chair; String name;}
In the UML, aggregation and composition are defined as special forms of associations with the intended meaning of classifying part-whole-relationships. In the case of aggregation, as opposed to composition, the parts of a whole can be shared with other wholes. This is illustrated in the following example of an aggregation, where a course can belong to many degree programs.
The defining characteristic of a composition is to have exclusive (or non-shareable) parts. A composition may come with a life-cycle dependency between the whole and its parts implying that when a whole is destroyed, all of its parts are destroyed with it. However, this only applies to some cases of composition, and not to others, and it is therefore not a defining characteristic. An example of a composition where the parts (components) can be detached from the whole (composite) and therefore survive its destruction, is the following:
See Superstructures 2.1.1:
An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element. Composition is represented by the isComposite attribute on the part end of the association being set to true.
Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends.
Your above examples are on different abstraction levels. Department/Course are concrete coding classes while Department/Professor are at some abstract business level. Though there is no good source (I know) explaining this fact, composition and aggregation are concepts you will use only on business level and almost never at coding level (exception below). When you are at code level you live much better with Association having role names on both sides. Roles themselves are a different(/redundant!) rendering of properties of a class that refer to the opposite class.
Aggregation as a strong binding between classes is used e.g. in database modeling. Here you can delete a master only if the aggregates have all been deleted previously (or vice vera: deleting the master will force deletion of the aggregates). The aggregate can not live on its own. The composition as in your example is (from my POV) a silly construct as it pretends to be some week aggregation. But that's simply nonsense. Then use an association. Only on a business level you can try to model (e.g.) machine parts as composite. On a concrete level a composition is a useless concept.
tl;dr;
If there is a relation between classes show it as simple association. Adding details like roles will aid when discussing domain details. Use of composition/aggregation is encouraged only when modeling on business level and dis-encouraged on code level.
I've written an article about the differences between UML Association vs Aggregation vs Composition based on the actual UML specification rather then interpretations of book authors.
The primary conclusion being that
In short, the Composition is a type of Association with real constraints and impact on development, whereas the Aggregation is purely a functional indication of the nature of the Association with no technical impact.
Navigability is a completely different property and independent of the AggregationKind.
For one thing, UML is a rich language, meaning there is more than one way to describe the same thing. That's one reason you find different ways described in different books (and conflicting answers on SO).
But a key issue is the huge disconnect between UML and source code. How a specific source code construct is represented in UML, and vice versa, is not part of the UML specification at all. To my knowledge, only one language (Java) has an official UML profile, and that's out of date.
So the representation of specific source-language constructs are left to the tool vendors, and therefore differ. If you intend to generate code from your model, you must follow the vendor's conventions. If, conversely, you wish to generate a model from existing source code, you get a model based on those same conventions. But if you transfer that model to a different tool (which is difficult at the best of times) and generate code out of that, you won't end up with the same code.
In language-and-tool-agnostic mode, my take on which relationships to use in which situations can be found here. One point there worth repeating is that I don't use undirected associations in source-code models, precisely because they have no obvious counterpart in actual code. If in the code class A has a reference to class B, and B also has one to A, then I draw two relationships instead.
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.