Hello,
I am learning UML and I am facing some challenges with the class diagram.
My learning sources don't explain the generalization relationship very well and also the abstract class subject (or I don't understand it enough).
When taking this for example. There is a class person with an attribute ' name' with a generalization relationship to ProjectEmployee.
I see it as Person is the parent and Projectemployee as the child. So the person is a projectemployee as well?
And projectemployee has an aggregation relationship to projectteam. Does this mean that the person is always part of a projectteam?
Is it better to make 'person' an abstract class?
This diagram says that ProjectEmployee is a specialization of the more general Person. In other words, every ProjectEmployee is a Person, but there may be some Person that are not ProjectEmployee
The (shared) aggregation means the same thing as an ordinary association (at least for the current UML specifications, which do not define its semantics). So it means that ProjectEmployee may be associated with a Projectteam. We can’t tell more since multiplicities are not specified in this diagram. Only multiplicities can tell you if a team member must or can belong to a team. For example, 1 on the diamond side means that a member must belong to exactly one team, 1..* that a member must belong to at least one team but can belong to several teams at the same time.
There is no argument here to suggest that Person should be abstract. There is no argument for the contrary either. The question is therefore: what would you want to achieve by making it abstract? For example, do you have some operation that Person should offer, but that could only be defined for subclasses and not for a Person in general? Or do you want to prevent Person to be instantiated?
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 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'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 find these two examples conceptually identical - yet one is a composition and the other aggregation.
In the first example, the relationship 'class (has-a) students' is a compositon.
A class contains students. A student cannot exist without a class.
There exists composition between class and students.
In the second example, the relationship 'department (has-a) professors' is an aggregation.
If the university closes, the departments will no longer exist, but
the professors in those departments will continue to exist
In my opinion the first one is plain wrong. Notice that in the comment section of this SO question #TallPaul is questioning the first example as well. I think in practice it would delete all students enrolled in a class after each semester from the system. Moreover, the students would probably have to be created by the class on its initialisation, because composition in C++ is usually implemented as private attribute (not pointer). Am I right? Is there any way the first example makes sense?
There is no absolute truth and it all depends on the system you are modeling. You can create a system where students are instances that exist only in a specific class and when the class is deleted, so are the students. This may make sense when you don't want to store student information between classes for example.
Yes, those are weak examples, a Class must have a Subject would be a much better example for Composition. The relationship between a Class and Students is Aggregation because the life-time of the two is different.
See [UML Associations in Java] for more detailed examples1
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.