I don't yet completely seem to understand how association class works, why the role class attributes can't just be inside the person class?
as example:
Person
name
position
description
Suppose we live in a world where a person must have a role in a company in order to live and a company may exist without persons at all.
If that is all you want to know about the relationship between persons and companies, i.e. only the fact that there are such relationships and nothing more, you model it like this:
Then if you want in addition to capture position and description of the Person's role you use so called AssociationClass (Role in our case):
Each instance of Role has four properties (both an attribute and an end of an association are Properties in UML):
Company
Person
position
description
For example, suppose a person named Scott Tiger has roles in two companies - Food Inc and Water Ltd and each company knows that Scott Tiger has role in it. Then there will be two instances of Role (shown as tuples):
(Food Inc., Scott Tigger, eater, eats here)
(Water Inc., Scott Tigger, drinker, drinks here)
Now, returning to you question, it should be clear that an instance of Person with name, position, description attributes actually "lacks" Company and if you "add" an Company you will get Role, not Person!
So what you proposed in the end of your question is a valid design, if you model Company and Role and a person is just an attribute of Role:
It reads as follows: each instance of Company has zero or more Roles and each instance of Role has only one Company. Both ends of the association are navigable, i.e. Role knows its Company and Company knows its Roles.
UML Specification in clause 9.5.3 gives you the following advice:
A Property may represent an attribute of a Classifier, a memberEnd of an Association, or in some cases both simultaneously.
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. This convention is not enforced by UML.
why the role class attributes can't just be inside the person class?
notice the multiplicity 1..*, if you move position and description into Person you have to manage a collection of them and to associate each to the corresponding Company.
[from your remark]
For a given Person the position and description depends on each associated Compagny, so it is not possible to have the fields you propose except if position and description are both a collection, and to have a way/rule to know which entry in position and description correspond to the right Compagny.
Moving also these information in Person you remove the symmetry, it is also possible to move these information in Compagny, with the same remarks as for Person
An association class is both a class and a relation, when you implement it in a language like C++ or Java etc of course that concept does not exist, so one way is as you propose to move the fields in one of the two classes, or to create a third class having the expected fields more one to a Person and one to Company.
The advantage of the third class is to have all the associated information grouped having the equivalent of :
As example an object diagram can be :
Without the third class you need to know how to associate all the separated information, for instance having all in Person using three vectors to memorize the company and position and description you may use the same index value for all, but this is less clear and when you add/remove a Company for a Person you have to update all these vectors.
Related
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?
CONTEXT: I have an abstract class Student. From this class I derive three concrete classes SchoolStudent, UnderGradStudent, PostGradStudent. I have another class Vehicle. A school student must NOT drive a vehicle however, an undergrad or a postgrad student may or may not drive a vehicle.But every vehicle must be driven by somebody hence the Vehicle class has a reference to a student.
PROBLEM: I have association between classes UnderGradStudent & Vehicle and another association between PostGradStudent & Vehicle. However, I am a little confused about the multiplicity.
As I understand the problem, the UML class diagram should look something like this:
However, I suspect the above diagram suggests that each Vehicle will have one UnderGradStudent as well as one PostGradStudent.
Is the above diagram correct as to what I want to model corresponding to the context?
As you've drawn this UML diagram, it implies (but does not say correctly) that a Vehicle must be driven by both one UnderGradStudent and one PostGradStudent. It also implies that an UnderGradStudent can drive any number of Vehicles and a PostGradStudent can drive any number of Vehicles (at the same time). I don't think that's what you intended. The reason I say "implies" is that you have overlaid two associations on one end. Last I checked, that is invalid UML.
I think you wanted to say that a Vehicle may be driven by up to one Undergrad Student or Postgrad Student. To say that, I recommend the following model:
What this says is:
A valid instance of Student must be one of School Student, Undergrad Student, or Postgrad Student (and not multiply classified)
A valid instance of Allowed Driver must be one of Undergrad Student or Postgrad Student (and not multiply classified)
A Vehicle can be driven by up to one Allowed Driver (at a time)
An Allowed Driver drives up to one Vehicle (at a time)
This describes a valid situation at any point in time, which is really useful. Think of it as a way to evaluate the validity of any frame in a movie.
If you need to record all the drivers of every vehicle ever, you would need to make many changes. A Person actually plays the role of a Student (among other roles, usually), and that role can change over time. You would need to record the start and end time of every role change and the start and end time of every driver / vehicle change. Think of this as recording all the frames in a movie, but without the ability to express the validity of any given frame in the movie. You lose that ability when you relax multiplicities.
You can get the benefits of the "single frame" and the "whole movie" approach by combining all of the associations I mentioned.
Your problem will easily be solved by using a 0..1 multiplicity near the *Student classes from the Vehicle. This will tell the reader that both are allowed to have a related optional vehicle. To avoid both using the same car you need to attach a constraint like this:
Alternatively you can do it the following way:
I'm not good in writing OCL but you could formalize the constraint as well.
I have 4 tables:
Doctors
ID,Name,roomNumber
Appointments
ID,whenOccured,ifAttended
Patients
ID, name, address
DPappointments
DoctorID,PatientID,AppointmentID
this roughly becomes
However, i now want to change it such that an appointment can be made to see either a Doctor OR a NURSE?
How can i change the class diagram to reflect an 'OR' type relation?
Depending on the rest of your model's structure, there are different solutions. I supose there is also a class Nurse and that id does not have any special relationship with the Doctor (like inheritance from Employee or similar). So, this would be a generic solution.
Add add an association between Appointment and Nurse, similar to the existing one with a Doctor. The corresponding multiplicity on the Doctor (and Nurse) side should be 0..1 and an additional rule should be added - an Appointment object must have either a link to the Doctor object or to a Nurse object.
This rule could be specified in OCL (if you like a formal style) or as a simple textual note on the diagram.
There are some other ways to model this, with no additional restrictions, but the model itself would (maybe) be necessery complicated. For example, you could derive Doctor and Nurse from an abstract class - AppointmentRespondent and link it with the Appointment using the multiplicity 1..1 on that side. This model permits more flexibility and is more exdensible (easy adding new potential AppointmentRespondents), no OCL, no restrictions.
It's up to you to chose the method that is more in line with your model and future extensions.
P.S. Not that this is not an OR-type of relation, but rather XOR - in each Appointment there MUST be somewhone on behalf of the hospital (this is a reasonable guess :)).
Here is an example:
I have the generic type called "Account". I wish to use this account to represent multiple business entities:
1. Customer
2. Client
3. Company
I wish to use the Account type for the above 3 entities (as they are all types of accounts in my system - where the type is an attribute of the Account). How would I represent this relationship?
The only relationship you've described is that 'type' is an attribute of the Account. If Customer, Client, or Company are not strong enough entities on their own to deserve their own box on the Domain diagram, then you are done. In that case, you can include a note box associated with Account and say "Examples of values for the Type field: Customer, Client, Company, etc.".
If that is not strong enough, you may think about creating an AccountType class which have as sub-classes Customer, Client, Company. In that case you would draw an association from Account to AccountType, which replaces the need for the 'Type" attribute.
When I get a chance, I'll draw examples and post links to them.
You can model the template class (Account) and then bind it to create three different classes using the association link and the bind stereotype on the link, as you can see here, under the "Class Template" title.
I believe the diagram I would use to communicate these relationships between diffrent objects is the "Collaboration" diagram, as what the relationships show is how the different objects are instantiated (Account is instantiated as Customer, Client and Company) and how they (the instances) would interact with each other
I am trying to draw a conceptual class diagram. In my system, I have one person who can be performing 2 roles. One being "teacher" and other being "student". The same person could be a teacher in one instance and the same person could be a student in another instance. In such a situation, is it good to depict them as 2 separate classes (in my conceptual diagram)?
Please advise.
Thanks
Unless the person is teaching themself, don't get caught up in trying to show relationships that cross a use-case boundary. Validate the links for each scenario separately; just realize that not all connections will be used for every scenario.
People fill roles. Try
Person associated with EducationRole
EducationRole has subclasses of 'Student' and 'Teacher'
Here is a diagram.
They can change the role they play depending on the situation. If you need to show a person teaching themself then create a subclass of EducationRole named 'Autodiadact' which just means self-teacher.
A commenter asked about changing the role using a method and I'd like to include the answer here.
So, yes you could code the ability to change the role in a method but back up and ask the bigger question, why are we changing the role? A teacher is becoming a student or a student is becoming a teacher, either way the model as shown allows a Person to have many EducationRoles (which is what the asterisk denotes) at the same time so there isn't really a need to change the role but support a person with multiple possible roles.
In the conceptual model you are attempting to illustrate relationships between any valid state of the system, not necessarily how the change might be executed (using a method).