UML Class-Diagrams : class inheritance and relationships between classes
I've never made a class diagram before, that's why I tried to ask. I always learn from my mistake. I have read some references, but I am confused how to test the results I made? because this is not a coding which if have error, the error message will be appear.
this my design database
and this is a class diagram that I made based on design database.
is the method for creating class diagrams similar to erd? I am very confused how to inherit the class and which arrow should I use?
in the path that I made there are three users. and each has a different role
- Public Relations = Input data from external user (the applicant comes and gives a written proposal) then the data is stored in the database. The data includes applicant data and proposal data. PR can also see data that has been confirmed by the Division
- Division = The division can see data that has been stored by PR and confirm the data. Data that has been confirmed will be filed and made a report.
- Manager = can only see reports
uml class-diagram
asked Dec 26 '18 at 17:49
AdityaDSAdityaDS
288114
|
show 2 more comments
I've never made a class diagram before, that's why I tried to ask. I always learn from my mistake. I have read some references, but I am confused how to test the results I made? because this is not a coding which if have error, the error message will be appear.
this my design database
and this is a class diagram that I made based on design database.
is the method for creating class diagrams similar to erd? I am very confused how to inherit the class and which arrow should I use?
in the path that I made there are three users. and each has a different role
- Public Relations = Input data from external user (the applicant comes and gives a written proposal) then the data is stored in the database. The data includes applicant data and proposal data. PR can also see data that has been confirmed by the Division
- Division = The division can see data that has been stored by PR and confirm the data. Data that has been confirmed will be filed and made a report.
- Manager = can only see reports
uml class-diagram
asked Dec 26 '18 at 17:49
AdityaDSAdityaDS
288114
Please bear in mind that this is no homework correction place. Your question as such is too broad. There are a couple of issues with your design. Try to be more specific in your question.
– Thomas Kilian
Dec 26 '18 at 19:12
The problem statement "public relations receives ... have been made by division X." is very strange, it looks like an automatic translation. Check your inheritances, for instance a User is not a Login so User cannot inherit Login, Public Relations and Division X cannot be by themselves a User (Person is probably a better name). Do not prefix the name of your attributes by the name of the class. The representation of the enumerations is very strange.
– bruno
Dec 26 '18 at 20:42
@ThomasKilian sorry, now I have updated my question.
– AdityaDS
Dec 26 '18 at 22:00
@bruno please check my update, I just changed according to what you said.
– AdityaDS
Dec 26 '18 at 22:00
Before you create a class diagram, determine its purpose. A class diagram is a model of 'something'. That 'something' can be a database, an application, the real world or anything else. What is it in your case? A model of the database?
– www.admiraalit.nl
Dec 27 '18 at 19:54
|
show 2 more comments
I've never made a class diagram before, that's why I tried to ask. I always learn from my mistake. I have read some references, but I am confused how to test the results I made? because this is not a coding which if have error, the error message will be appear.
this my design database
and this is a class diagram that I made based on design database.
is the method for creating class diagrams similar to erd? I am very confused how to inherit the class and which arrow should I use?
in the path that I made there are three users. and each has a different role
- Public Relations = Input data from external user (the applicant comes and gives a written proposal) then the data is stored in the database. The data includes applicant data and proposal data. PR can also see data that has been confirmed by the Division
- Division = The division can see data that has been stored by PR and confirm the data. Data that has been confirmed will be filed and made a report.
- Manager = can only see reports
uml class-diagram
asked Dec 26 '18 at 17:49
AdityaDSAdityaDS
288114
I've never made a class diagram before, that's why I tried to ask. I always learn from my mistake. I have read some references, but I am confused how to test the results I made? because this is not a coding which if have error, the error message will be appear.
this my design database
and this is a class diagram that I made based on design database.
is the method for creating class diagrams similar to erd? I am very confused how to inherit the class and which arrow should I use?
in the path that I made there are three users. and each has a different role
- Public Relations = Input data from external user (the applicant comes and gives a written proposal) then the data is stored in the database. The data includes applicant data and proposal data. PR can also see data that has been confirmed by the Division
- Division = The division can see data that has been stored by PR and confirm the data. Data that has been confirmed will be filed and made a report.
- Manager = can only see reports
uml class-diagram
uml class-diagram
asked Dec 26 '18 at 17:49
AdityaDSAdityaDS
288114
asked Dec 26 '18 at 17:49
AdityaDSAdityaDS
288114
edited Dec 26 '18 at 21:59
AdityaDS
asked Dec 26 '18 at 17:49
AdityaDSAdityaDS
288114
asked Dec 26 '18 at 17:49
AdityaDSAdityaDS
288114
asked Dec 26 '18 at 17:49
AdityaDSAdityaDS
288114
288114
Please bear in mind that this is no homework correction place. Your question as such is too broad. There are a couple of issues with your design. Try to be more specific in your question.
– Thomas Kilian
Dec 26 '18 at 19:12
The problem statement "public relations receives ... have been made by division X." is very strange, it looks like an automatic translation. Check your inheritances, for instance a User is not a Login so User cannot inherit Login, Public Relations and Division X cannot be by themselves a User (Person is probably a better name). Do not prefix the name of your attributes by the name of the class. The representation of the enumerations is very strange.
– bruno
Dec 26 '18 at 20:42
@ThomasKilian sorry, now I have updated my question.
– AdityaDS
Dec 26 '18 at 22:00
@bruno please check my update, I just changed according to what you said.
– AdityaDS
Dec 26 '18 at 22:00
Before you create a class diagram, determine its purpose. A class diagram is a model of 'something'. That 'something' can be a database, an application, the real world or anything else. What is it in your case? A model of the database?
– www.admiraalit.nl
Dec 27 '18 at 19:54
|
show 2 more comments
Please bear in mind that this is no homework correction place. Your question as such is too broad. There are a couple of issues with your design. Try to be more specific in your question.
– Thomas Kilian
Dec 26 '18 at 19:12
The problem statement "public relations receives ... have been made by division X." is very strange, it looks like an automatic translation. Check your inheritances, for instance a User is not a Login so User cannot inherit Login, Public Relations and Division X cannot be by themselves a User (Person is probably a better name). Do not prefix the name of your attributes by the name of the class. The representation of the enumerations is very strange.
– bruno
Dec 26 '18 at 20:42
@ThomasKilian sorry, now I have updated my question.
– AdityaDS
Dec 26 '18 at 22:00
@bruno please check my update, I just changed according to what you said.
– AdityaDS
Dec 26 '18 at 22:00
Before you create a class diagram, determine its purpose. A class diagram is a model of 'something'. That 'something' can be a database, an application, the real world or anything else. What is it in your case? A model of the database?
– www.admiraalit.nl
Dec 27 '18 at 19:54
Please bear in mind that this is no homework correction place. Your question as such is too broad. There are a couple of issues with your design. Try to be more specific in your question.
– Thomas Kilian
Dec 26 '18 at 19:12
Please bear in mind that this is no homework correction place. Your question as such is too broad. There are a couple of issues with your design. Try to be more specific in your question.
– Thomas Kilian
Dec 26 '18 at 19:12
The problem statement "public relations receives ... have been made by division X." is very strange, it looks like an automatic translation. Check your inheritances, for instance a User is not a Login so User cannot inherit Login, Public Relations and Division X cannot be by themselves a User (Person is probably a better name). Do not prefix the name of your attributes by the name of the class. The representation of the enumerations is very strange.
– bruno
Dec 26 '18 at 20:42
The problem statement "public relations receives ... have been made by division X." is very strange, it looks like an automatic translation. Check your inheritances, for instance a User is not a Login so User cannot inherit Login, Public Relations and Division X cannot be by themselves a User (Person is probably a better name). Do not prefix the name of your attributes by the name of the class. The representation of the enumerations is very strange.
– bruno
Dec 26 '18 at 20:42
@ThomasKilian sorry, now I have updated my question.
– AdityaDS
Dec 26 '18 at 22:00
@ThomasKilian sorry, now I have updated my question.
– AdityaDS
Dec 26 '18 at 22:00
@bruno please check my update, I just changed according to what you said.
– AdityaDS
Dec 26 '18 at 22:00
@bruno please check my update, I just changed according to what you said.
– AdityaDS
Dec 26 '18 at 22:00
Before you create a class diagram, determine its purpose. A class diagram is a model of 'something'. That 'something' can be a database, an application, the real world or anything else. What is it in your case? A model of the database?
– www.admiraalit.nl
Dec 27 '18 at 19:54
Before you create a class diagram, determine its purpose. A class diagram is a model of 'something'. That 'something' can be a database, an application, the real world or anything else. What is it in your case? A model of the database?
– www.admiraalit.nl
Dec 27 '18 at 19:54
|
show 2 more comments
2 Answers
2
active
oldest
votes
Here are a couple of findings:
- User->Login: This is no generalization. A user isn't a login. It might have some login information associated. So that shall be an association.
- Similar for Proposal->StatusProposal. But here it's a dependency since you will not create an enumeration object. You just use it to type an attribute.
- Same for User->Gender/RoleUser. Both are dependencies.
There are also a couple of design issues. But here YMMV too much. Having User implement userLogin() is at least questionable. There should be a security system taking care which validates a user login. So why does Login have a loginStatus()? However, design is not be discussed here.
As to class/ERD: they are similar, but not the same. UML has a broader scope while ERD focuses plainly on databases. So all the *_id attributes in your classes stem from a database design. The class design in that state is very much focused on databases. In a MDA it might be derived from a PIM to a PSM (so from an abstract view to a DB-specific one).
answered Dec 27 '18 at 20:47
Thomas KilianThomas Kilian
23.5k63562
thanks, so i need remove object on status Proposal and change with dependency right? and also remove userLogin and statusLogin ?
– AdityaDS
Dec 28 '18 at 9:45
I can't discuss the design issues without domain knowledge. Re. StatusProposal it's only the Generalization to be changed to a Dependency.
– Thomas Kilian
Dec 28 '18 at 9:51
okay it's not a problem, it seems like I only have to delete it and the problem will be solved. Okay, I change the entire flow to the enum with dependency. Thank you very much.
– AdityaDS
Dec 28 '18 at 13:03
add a comment |
In addition to Thomas Killian's observations, your composition associations appear to be inaccurate. In effect, for example, you are specifying that the lifetime of a Department object is dependent on the lifetime of a User object. You are also specifying a whole-part relationship between Users and Departments, where the user is an aggregation of departments. I would think that it's the other way around. I also suspect that a user's lifetime isn't dependent on a department's lifetime, since a user can typically change departments. Therefore, an aggregation diamond (white) is probably correct, and it should be on the Department end.
Similarly, I have trouble making sense of your other two composition associations.
answered Dec 31 '18 at 0:41
BobRodesBobRodes
4,34821723
I just overlooked them. I almost never use composition for a couple of reasons. Mainly it's because lifetime dependencies tend to be superfluous except for security or memory management. People tend to over-use them, and wrongly too. Even worse when it comes to shared aggregation.
– Thomas Kilian
Dec 31 '18 at 8:45
@ThomasKilian I agree that both forms of aggregation are overused, in that most associations between classes aren't whole-part relationships and are often diagrammed as such anyway. As for which to use when warranted, I usually imagine how a whole-part relationship will be implemented; if the whole will instantiate the parts, then I see it as composition, and if not then simple aggregation. Tom Pender gives the example of a car and its parts, where in a manufacturing context the parts will always be part of the car (once assembled), while in a junkyard context they won't.
– BobRodes
Jan 3 at 8:30
Funny you take the car example ;-) I don't have Pender's bible (rev. 2003?) but a quick google revealed slideplayer.com/slide/13019772 where he uses the "old" composition definition which clearly does not match that of the current 2.5 specs. It looks like UML has some bad heritage here.
– Thomas Kilian
Jan 3 at 10:18
@ThomasKilian Interesting. I haven't taken a deep dive into the specs since I worked as a tech editor on the first edition of Tom's book. (Didn't know he made a revision; the first version came out a little while after UML 2.0.) Does the car example work in 2.5?
– BobRodes
Jan 5 at 18:32
Not really. They boiled compositions rather down (see p. 110 of UML 2.5). And instead of introducing the dot-notation for owned properties I'd liked the composition diamond used for it, since basically that what everybody seems to use it for (and not a real live-time indicator). OTOH that would probably had introduced even more confusion.
– Thomas Kilian
Jan 6 at 2:06
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53935349%2fuml-class-diagrams-class-inheritance-and-relationships-between-classes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Here are a couple of findings:
- User->Login: This is no generalization. A user isn't a login. It might have some login information associated. So that shall be an association.
- Similar for Proposal->StatusProposal. But here it's a dependency since you will not create an enumeration object. You just use it to type an attribute.
- Same for User->Gender/RoleUser. Both are dependencies.
There are also a couple of design issues. But here YMMV too much. Having User implement userLogin() is at least questionable. There should be a security system taking care which validates a user login. So why does Login have a loginStatus()? However, design is not be discussed here.
As to class/ERD: they are similar, but not the same. UML has a broader scope while ERD focuses plainly on databases. So all the *_id attributes in your classes stem from a database design. The class design in that state is very much focused on databases. In a MDA it might be derived from a PIM to a PSM (so from an abstract view to a DB-specific one).
answered Dec 27 '18 at 20:47
Thomas KilianThomas Kilian
23.5k63562
thanks, so i need remove object on status Proposal and change with dependency right? and also remove userLogin and statusLogin ?
– AdityaDS
Dec 28 '18 at 9:45
I can't discuss the design issues without domain knowledge. Re. StatusProposal it's only the Generalization to be changed to a Dependency.
– Thomas Kilian
Dec 28 '18 at 9:51
okay it's not a problem, it seems like I only have to delete it and the problem will be solved. Okay, I change the entire flow to the enum with dependency. Thank you very much.
– AdityaDS
Dec 28 '18 at 13:03
add a comment |
Here are a couple of findings:
- User->Login: This is no generalization. A user isn't a login. It might have some login information associated. So that shall be an association.
- Similar for Proposal->StatusProposal. But here it's a dependency since you will not create an enumeration object. You just use it to type an attribute.
- Same for User->Gender/RoleUser. Both are dependencies.
There are also a couple of design issues. But here YMMV too much. Having User implement userLogin() is at least questionable. There should be a security system taking care which validates a user login. So why does Login have a loginStatus()? However, design is not be discussed here.
As to class/ERD: they are similar, but not the same. UML has a broader scope while ERD focuses plainly on databases. So all the *_id attributes in your classes stem from a database design. The class design in that state is very much focused on databases. In a MDA it might be derived from a PIM to a PSM (so from an abstract view to a DB-specific one).
answered Dec 27 '18 at 20:47
Thomas KilianThomas Kilian
23.5k63562
thanks, so i need remove object on status Proposal and change with dependency right? and also remove userLogin and statusLogin ?
– AdityaDS
Dec 28 '18 at 9:45
I can't discuss the design issues without domain knowledge. Re. StatusProposal it's only the Generalization to be changed to a Dependency.
– Thomas Kilian
Dec 28 '18 at 9:51
okay it's not a problem, it seems like I only have to delete it and the problem will be solved. Okay, I change the entire flow to the enum with dependency. Thank you very much.
– AdityaDS
Dec 28 '18 at 13:03
add a comment |
Here are a couple of findings:
- User->Login: This is no generalization. A user isn't a login. It might have some login information associated. So that shall be an association.
- Similar for Proposal->StatusProposal. But here it's a dependency since you will not create an enumeration object. You just use it to type an attribute.
- Same for User->Gender/RoleUser. Both are dependencies.
There are also a couple of design issues. But here YMMV too much. Having User implement userLogin() is at least questionable. There should be a security system taking care which validates a user login. So why does Login have a loginStatus()? However, design is not be discussed here.
As to class/ERD: they are similar, but not the same. UML has a broader scope while ERD focuses plainly on databases. So all the *_id attributes in your classes stem from a database design. The class design in that state is very much focused on databases. In a MDA it might be derived from a PIM to a PSM (so from an abstract view to a DB-specific one).
answered Dec 27 '18 at 20:47
Thomas KilianThomas Kilian
23.5k63562
Here are a couple of findings:
- User->Login: This is no generalization. A user isn't a login. It might have some login information associated. So that shall be an association.
- Similar for Proposal->StatusProposal. But here it's a dependency since you will not create an enumeration object. You just use it to type an attribute.
- Same for User->Gender/RoleUser. Both are dependencies.
There are also a couple of design issues. But here YMMV too much. Having User implement userLogin() is at least questionable. There should be a security system taking care which validates a user login. So why does Login have a loginStatus()? However, design is not be discussed here.
As to class/ERD: they are similar, but not the same. UML has a broader scope while ERD focuses plainly on databases. So all the *_id attributes in your classes stem from a database design. The class design in that state is very much focused on databases. In a MDA it might be derived from a PIM to a PSM (so from an abstract view to a DB-specific one).
answered Dec 27 '18 at 20:47
Thomas KilianThomas Kilian
23.5k63562
answered Dec 27 '18 at 20:47
Thomas KilianThomas Kilian
23.5k63562
answered Dec 27 '18 at 20:47
Thomas KilianThomas Kilian
23.5k63562
answered Dec 27 '18 at 20:47
Thomas KilianThomas Kilian
23.5k63562
23.5k63562
thanks, so i need remove object on status Proposal and change with dependency right? and also remove userLogin and statusLogin ?
– AdityaDS
Dec 28 '18 at 9:45
I can't discuss the design issues without domain knowledge. Re. StatusProposal it's only the Generalization to be changed to a Dependency.
– Thomas Kilian
Dec 28 '18 at 9:51
okay it's not a problem, it seems like I only have to delete it and the problem will be solved. Okay, I change the entire flow to the enum with dependency. Thank you very much.
– AdityaDS
Dec 28 '18 at 13:03
add a comment |
thanks, so i need remove object on status Proposal and change with dependency right? and also remove userLogin and statusLogin ?
– AdityaDS
Dec 28 '18 at 9:45
I can't discuss the design issues without domain knowledge. Re. StatusProposal it's only the Generalization to be changed to a Dependency.
– Thomas Kilian
Dec 28 '18 at 9:51
okay it's not a problem, it seems like I only have to delete it and the problem will be solved. Okay, I change the entire flow to the enum with dependency. Thank you very much.
– AdityaDS
Dec 28 '18 at 13:03
thanks, so i need remove object on status Proposal and change with dependency right? and also remove userLogin and statusLogin ?
– AdityaDS
Dec 28 '18 at 9:45
thanks, so i need remove object on status Proposal and change with dependency right? and also remove userLogin and statusLogin ?
– AdityaDS
Dec 28 '18 at 9:45
I can't discuss the design issues without domain knowledge. Re. StatusProposal it's only the Generalization to be changed to a Dependency.
– Thomas Kilian
Dec 28 '18 at 9:51
I can't discuss the design issues without domain knowledge. Re. StatusProposal it's only the Generalization to be changed to a Dependency.
– Thomas Kilian
Dec 28 '18 at 9:51
okay it's not a problem, it seems like I only have to delete it and the problem will be solved. Okay, I change the entire flow to the enum with dependency. Thank you very much.
– AdityaDS
Dec 28 '18 at 13:03
okay it's not a problem, it seems like I only have to delete it and the problem will be solved. Okay, I change the entire flow to the enum with dependency. Thank you very much.
– AdityaDS
Dec 28 '18 at 13:03
add a comment |
In addition to Thomas Killian's observations, your composition associations appear to be inaccurate. In effect, for example, you are specifying that the lifetime of a Department object is dependent on the lifetime of a User object. You are also specifying a whole-part relationship between Users and Departments, where the user is an aggregation of departments. I would think that it's the other way around. I also suspect that a user's lifetime isn't dependent on a department's lifetime, since a user can typically change departments. Therefore, an aggregation diamond (white) is probably correct, and it should be on the Department end.
Similarly, I have trouble making sense of your other two composition associations.
answered Dec 31 '18 at 0:41
BobRodesBobRodes
4,34821723
I just overlooked them. I almost never use composition for a couple of reasons. Mainly it's because lifetime dependencies tend to be superfluous except for security or memory management. People tend to over-use them, and wrongly too. Even worse when it comes to shared aggregation.
– Thomas Kilian
Dec 31 '18 at 8:45
@ThomasKilian I agree that both forms of aggregation are overused, in that most associations between classes aren't whole-part relationships and are often diagrammed as such anyway. As for which to use when warranted, I usually imagine how a whole-part relationship will be implemented; if the whole will instantiate the parts, then I see it as composition, and if not then simple aggregation. Tom Pender gives the example of a car and its parts, where in a manufacturing context the parts will always be part of the car (once assembled), while in a junkyard context they won't.
– BobRodes
Jan 3 at 8:30
Funny you take the car example ;-) I don't have Pender's bible (rev. 2003?) but a quick google revealed slideplayer.com/slide/13019772 where he uses the "old" composition definition which clearly does not match that of the current 2.5 specs. It looks like UML has some bad heritage here.
– Thomas Kilian
Jan 3 at 10:18
@ThomasKilian Interesting. I haven't taken a deep dive into the specs since I worked as a tech editor on the first edition of Tom's book. (Didn't know he made a revision; the first version came out a little while after UML 2.0.) Does the car example work in 2.5?
– BobRodes
Jan 5 at 18:32
Not really. They boiled compositions rather down (see p. 110 of UML 2.5). And instead of introducing the dot-notation for owned properties I'd liked the composition diamond used for it, since basically that what everybody seems to use it for (and not a real live-time indicator). OTOH that would probably had introduced even more confusion.
– Thomas Kilian
Jan 6 at 2:06
add a comment |
In addition to Thomas Killian's observations, your composition associations appear to be inaccurate. In effect, for example, you are specifying that the lifetime of a Department object is dependent on the lifetime of a User object. You are also specifying a whole-part relationship between Users and Departments, where the user is an aggregation of departments. I would think that it's the other way around. I also suspect that a user's lifetime isn't dependent on a department's lifetime, since a user can typically change departments. Therefore, an aggregation diamond (white) is probably correct, and it should be on the Department end.
Similarly, I have trouble making sense of your other two composition associations.
answered Dec 31 '18 at 0:41
BobRodesBobRodes
4,34821723
I just overlooked them. I almost never use composition for a couple of reasons. Mainly it's because lifetime dependencies tend to be superfluous except for security or memory management. People tend to over-use them, and wrongly too. Even worse when it comes to shared aggregation.
– Thomas Kilian
Dec 31 '18 at 8:45
@ThomasKilian I agree that both forms of aggregation are overused, in that most associations between classes aren't whole-part relationships and are often diagrammed as such anyway. As for which to use when warranted, I usually imagine how a whole-part relationship will be implemented; if the whole will instantiate the parts, then I see it as composition, and if not then simple aggregation. Tom Pender gives the example of a car and its parts, where in a manufacturing context the parts will always be part of the car (once assembled), while in a junkyard context they won't.
– BobRodes
Jan 3 at 8:30
Funny you take the car example ;-) I don't have Pender's bible (rev. 2003?) but a quick google revealed slideplayer.com/slide/13019772 where he uses the "old" composition definition which clearly does not match that of the current 2.5 specs. It looks like UML has some bad heritage here.
– Thomas Kilian
Jan 3 at 10:18
@ThomasKilian Interesting. I haven't taken a deep dive into the specs since I worked as a tech editor on the first edition of Tom's book. (Didn't know he made a revision; the first version came out a little while after UML 2.0.) Does the car example work in 2.5?
– BobRodes
Jan 5 at 18:32
Not really. They boiled compositions rather down (see p. 110 of UML 2.5). And instead of introducing the dot-notation for owned properties I'd liked the composition diamond used for it, since basically that what everybody seems to use it for (and not a real live-time indicator). OTOH that would probably had introduced even more confusion.
– Thomas Kilian
Jan 6 at 2:06
add a comment |
In addition to Thomas Killian's observations, your composition associations appear to be inaccurate. In effect, for example, you are specifying that the lifetime of a Department object is dependent on the lifetime of a User object. You are also specifying a whole-part relationship between Users and Departments, where the user is an aggregation of departments. I would think that it's the other way around. I also suspect that a user's lifetime isn't dependent on a department's lifetime, since a user can typically change departments. Therefore, an aggregation diamond (white) is probably correct, and it should be on the Department end.
Similarly, I have trouble making sense of your other two composition associations.
answered Dec 31 '18 at 0:41
BobRodesBobRodes
4,34821723
In addition to Thomas Killian's observations, your composition associations appear to be inaccurate. In effect, for example, you are specifying that the lifetime of a Department object is dependent on the lifetime of a User object. You are also specifying a whole-part relationship between Users and Departments, where the user is an aggregation of departments. I would think that it's the other way around. I also suspect that a user's lifetime isn't dependent on a department's lifetime, since a user can typically change departments. Therefore, an aggregation diamond (white) is probably correct, and it should be on the Department end.
Similarly, I have trouble making sense of your other two composition associations.
answered Dec 31 '18 at 0:41
BobRodesBobRodes
4,34821723
answered Dec 31 '18 at 0:41
BobRodesBobRodes
4,34821723
answered Dec 31 '18 at 0:41
BobRodesBobRodes
4,34821723
answered Dec 31 '18 at 0:41
BobRodesBobRodes
4,34821723
4,34821723
I just overlooked them. I almost never use composition for a couple of reasons. Mainly it's because lifetime dependencies tend to be superfluous except for security or memory management. People tend to over-use them, and wrongly too. Even worse when it comes to shared aggregation.
– Thomas Kilian
Dec 31 '18 at 8:45
@ThomasKilian I agree that both forms of aggregation are overused, in that most associations between classes aren't whole-part relationships and are often diagrammed as such anyway. As for which to use when warranted, I usually imagine how a whole-part relationship will be implemented; if the whole will instantiate the parts, then I see it as composition, and if not then simple aggregation. Tom Pender gives the example of a car and its parts, where in a manufacturing context the parts will always be part of the car (once assembled), while in a junkyard context they won't.
– BobRodes
Jan 3 at 8:30
Funny you take the car example ;-) I don't have Pender's bible (rev. 2003?) but a quick google revealed slideplayer.com/slide/13019772 where he uses the "old" composition definition which clearly does not match that of the current 2.5 specs. It looks like UML has some bad heritage here.
– Thomas Kilian
Jan 3 at 10:18
@ThomasKilian Interesting. I haven't taken a deep dive into the specs since I worked as a tech editor on the first edition of Tom's book. (Didn't know he made a revision; the first version came out a little while after UML 2.0.) Does the car example work in 2.5?
– BobRodes
Jan 5 at 18:32
Not really. They boiled compositions rather down (see p. 110 of UML 2.5). And instead of introducing the dot-notation for owned properties I'd liked the composition diamond used for it, since basically that what everybody seems to use it for (and not a real live-time indicator). OTOH that would probably had introduced even more confusion.
– Thomas Kilian
Jan 6 at 2:06
add a comment |
I just overlooked them. I almost never use composition for a couple of reasons. Mainly it's because lifetime dependencies tend to be superfluous except for security or memory management. People tend to over-use them, and wrongly too. Even worse when it comes to shared aggregation.
– Thomas Kilian
Dec 31 '18 at 8:45
@ThomasKilian I agree that both forms of aggregation are overused, in that most associations between classes aren't whole-part relationships and are often diagrammed as such anyway. As for which to use when warranted, I usually imagine how a whole-part relationship will be implemented; if the whole will instantiate the parts, then I see it as composition, and if not then simple aggregation. Tom Pender gives the example of a car and its parts, where in a manufacturing context the parts will always be part of the car (once assembled), while in a junkyard context they won't.
– BobRodes
Jan 3 at 8:30
Funny you take the car example ;-) I don't have Pender's bible (rev. 2003?) but a quick google revealed slideplayer.com/slide/13019772 where he uses the "old" composition definition which clearly does not match that of the current 2.5 specs. It looks like UML has some bad heritage here.
– Thomas Kilian
Jan 3 at 10:18
@ThomasKilian Interesting. I haven't taken a deep dive into the specs since I worked as a tech editor on the first edition of Tom's book. (Didn't know he made a revision; the first version came out a little while after UML 2.0.) Does the car example work in 2.5?
– BobRodes
Jan 5 at 18:32
Not really. They boiled compositions rather down (see p. 110 of UML 2.5). And instead of introducing the dot-notation for owned properties I'd liked the composition diamond used for it, since basically that what everybody seems to use it for (and not a real live-time indicator). OTOH that would probably had introduced even more confusion.
– Thomas Kilian
Jan 6 at 2:06
I just overlooked them. I almost never use composition for a couple of reasons. Mainly it's because lifetime dependencies tend to be superfluous except for security or memory management. People tend to over-use them, and wrongly too. Even worse when it comes to shared aggregation.
– Thomas Kilian
Dec 31 '18 at 8:45
I just overlooked them. I almost never use composition for a couple of reasons. Mainly it's because lifetime dependencies tend to be superfluous except for security or memory management. People tend to over-use them, and wrongly too. Even worse when it comes to shared aggregation.
– Thomas Kilian
Dec 31 '18 at 8:45
@ThomasKilian I agree that both forms of aggregation are overused, in that most associations between classes aren't whole-part relationships and are often diagrammed as such anyway. As for which to use when warranted, I usually imagine how a whole-part relationship will be implemented; if the whole will instantiate the parts, then I see it as composition, and if not then simple aggregation. Tom Pender gives the example of a car and its parts, where in a manufacturing context the parts will always be part of the car (once assembled), while in a junkyard context they won't.
– BobRodes
Jan 3 at 8:30
@ThomasKilian I agree that both forms of aggregation are overused, in that most associations between classes aren't whole-part relationships and are often diagrammed as such anyway. As for which to use when warranted, I usually imagine how a whole-part relationship will be implemented; if the whole will instantiate the parts, then I see it as composition, and if not then simple aggregation. Tom Pender gives the example of a car and its parts, where in a manufacturing context the parts will always be part of the car (once assembled), while in a junkyard context they won't.
– BobRodes
Jan 3 at 8:30
Funny you take the car example ;-) I don't have Pender's bible (rev. 2003?) but a quick google revealed slideplayer.com/slide/13019772 where he uses the "old" composition definition which clearly does not match that of the current 2.5 specs. It looks like UML has some bad heritage here.
– Thomas Kilian
Jan 3 at 10:18
Funny you take the car example ;-) I don't have Pender's bible (rev. 2003?) but a quick google revealed slideplayer.com/slide/13019772 where he uses the "old" composition definition which clearly does not match that of the current 2.5 specs. It looks like UML has some bad heritage here.
– Thomas Kilian
Jan 3 at 10:18
@ThomasKilian Interesting. I haven't taken a deep dive into the specs since I worked as a tech editor on the first edition of Tom's book. (Didn't know he made a revision; the first version came out a little while after UML 2.0.) Does the car example work in 2.5?
– BobRodes
Jan 5 at 18:32
@ThomasKilian Interesting. I haven't taken a deep dive into the specs since I worked as a tech editor on the first edition of Tom's book. (Didn't know he made a revision; the first version came out a little while after UML 2.0.) Does the car example work in 2.5?
– BobRodes
Jan 5 at 18:32
Not really. They boiled compositions rather down (see p. 110 of UML 2.5). And instead of introducing the dot-notation for owned properties I'd liked the composition diamond used for it, since basically that what everybody seems to use it for (and not a real live-time indicator). OTOH that would probably had introduced even more confusion.
– Thomas Kilian
Jan 6 at 2:06
Not really. They boiled compositions rather down (see p. 110 of UML 2.5). And instead of introducing the dot-notation for owned properties I'd liked the composition diamond used for it, since basically that what everybody seems to use it for (and not a real live-time indicator). OTOH that would probably had introduced even more confusion.
– Thomas Kilian
Jan 6 at 2:06
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53935349%2fuml-class-diagrams-class-inheritance-and-relationships-between-classes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Please bear in mind that this is no homework correction place. Your question as such is too broad. There are a couple of issues with your design. Try to be more specific in your question.
– Thomas Kilian
Dec 26 '18 at 19:12
The problem statement "public relations receives ... have been made by division X." is very strange, it looks like an automatic translation. Check your inheritances, for instance a User is not a Login so User cannot inherit Login, Public Relations and Division X cannot be by themselves a User (Person is probably a better name). Do not prefix the name of your attributes by the name of the class. The representation of the enumerations is very strange.
– bruno
Dec 26 '18 at 20:42
@ThomasKilian sorry, now I have updated my question.
– AdityaDS
Dec 26 '18 at 22:00
@bruno please check my update, I just changed according to what you said.
– AdityaDS
Dec 26 '18 at 22:00
Before you create a class diagram, determine its purpose. A class diagram is a model of 'something'. That 'something' can be a database, an application, the real world or anything else. What is it in your case? A model of the database?
– www.admiraalit.nl
Dec 27 '18 at 19:54