CODEWITHSUNDEEP
umlclass-diagram
AdityaDees
AdityaDees

Reputation: 1037

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 image1

and this is a class diagram that I made based on design database. image2

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

  1. 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
  2. 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.
  3. Manager = can only see reports

Upvotes: 0

Views: 4374

Answers (2)

BobRodes
BobRodes

Reputation: 6165

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.

Upvotes: 1

qwerty_so
qwerty_so

Reputation: 36295

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).

Upvotes: 2

Related Questions