Software Design: Class Diagram - User

[bahricanyesil]

Issue Description

As the next part of the software design process, we will provide a class diagram for our project moving from the use case diagram phase. Class diagram will be completed with a collective effort and I will be preparing the user sub-section of the diagram.

• This issue is a sub-issue of Software Design: Class Diagram #86 .

• User class will be formed, using the following sections of the use case diagram as basis.
  Sign-Up
  
  Login
  

• The class diagram will be generated using the Lucichart app, and the diagram can be viewed here .

Step Details

Steps that will be performed:

• Check the corresponding parts of the use-case diagram
• Define the attributes of the user class with name, type and description columns.
• Define the methods of the user class withe name, parameters, return type and requires auth columns.
• Check the possible inheritance, association, aggregation, composition relationships.
• Create the diagram in our project page in Lucidchart .
• Attach a final comment and screenshot of the diagram.

Final Actions

• After each part of the User class is determined and combined into a diagram, it will be merged into the main class diagram provided in this link.
• After completion, this issue will be reviewed and evaluated by the team members upon closing the issue.

Deadline of the Issue

04.04.2022 - Monday - 23.59

Reviewer

Altay Acar

Deadline for the Review

05.04.2022 - Tuesday - 10.00

[bahricanyesil]

Info

I will benefit from my previous work in the issue #60. I will extend it, add/remove/update attributes and methods and so that it will become compatible with our current use-case diagram. I checked the use-case diagram and I will be making necessary updates.

[bahricanyesil]

Attributes

I defined the class attributes as follows:

Attribute Name	Type	Description
user_id	UID	Id of the user
username	string	Unique username of the user
email	string	Unique email of the user
password	string	Hashed password of the user
is_email_confirmed	bool	Whether the user is completed the email verification step
is_active	bool	Whether the user deleted the account and anonymized
language_code	string	The code of the language user is selected (if not selected, locale language code)
device_token	string	Token of the device which is user is actively using (will be used while sending notifications)
enabled_notification	bool	Whether the notifications are enabled
created_at	Date	The date user signed up
updated_at	Date	The last date information under this class is updated
deleted_at	Date	The date user deleted the account

[bahricanyesil]

Methods

I defined the class methods as follows:

Method Name	Parameters	Return Type	Requires Auth
login	username: string, password: string	access_token: string, refresh_token: string, user: User	false
register	username: string, email: string, password: string, device_token: string, language_code: string	verification_token: string	false
verifyEmail	verification_token: string, verification_code: string	access_token: string, refresh_token: string, user: User	false
sendVerificationCode	email: string	verification_token: string	false
forgotPassword	password: string	void	true
changePassword	old_password: string, new_password: string	void	true
deleteUser	-	void	true
getUser	user_id: UID	user: User	true
setLanguage	language_code: string	void	true
setDeviceToken	device_token: string	void	true
hashPassword (private)	password: string	hashed_password: string	false
changeNotificationPreference	enabled_notification: bool	void	true
changeUsername	username: string	void	true
checkUsername	username: string	bool	true

[bahricanyesil]

Relationships

• Can have a composition relationship with Token class that will be created with issue Software Design: Class Diagram - Token #89 and also most of the other classes like Enrollment, Participance, Profile and so on. All other classes that have composition relationship with the users should be connected to the User class by the creator of those classes.
• Can have an inheritance relationship with Admin and other similar classes.

[bahricanyesil]

I completed the user part of the class diagram. You can access it via our class diagram project link. Here's the screenshot of the corresponding part:

[bahricanyesil]

I will add methods for following actions:

• Hash password (private)
• Change notification preference
• Change username
• Check username existence

I will also add an attribute related to the notification preference of the user.

[bahricanyesil]

I added the methods and attributes I mentioned above to the diagram. You can view the updated diagram via the link above. Here's the screenshot of the updated version:

[bahricanyesil]

The user part of the class diagram is completed, the associated diagram link and ss are given above. Now, it is ready to be reviewed by @xltvy.

[xltvy]

Thank you for your very detailed and comprehensive work. I think it is nearly perfect. I think there are just a few things that can be missing. Here I listed them:

• I think we may need an attribute for admin users. For example a boolean, called isAdmin to distinguish an admin user with a regular user.
• I think it is more of a design choice but I came up with the question that if a User class needs lists of annotations, taken courses, notes etc. for access to a specific user's notes, annotations, taken courses etc. or not. If so, then we may add those lists to the attributes of the class.

[bahricanyesil]

Thank you for your very detailed and comprehensive work. I think it is nearly perfect. I think there are just a few things that can be missing. Here I listed them:

• I think we may need an attribute for admin users. For example a boolean, called isAdmin to distinguish an admin user with a regular user.
• I think it is more of a design choice but I came up with the question that if a User class needs lists of annotations, taken courses, notes etc. for access to a specific user's notes, annotations, taken courses etc. or not. If so, then we may add those lists to the attributes of the class.

Thank you for the review @xltvy.

1- Will there be admins of the system? If you are indicating the admin of the courses, it should be under the "enrollment" class or as a separate class. If there will be admins of the system, you're right but can you indicate the corresponding requirement/use-case diagram if that's the case.
2- I think, we will not directly store them under the user class since it will be overwhelming while creating/updating/deleting synchronously from multiple tables. Instead, we will fetch a user's notes and etc. by scanning the notes table with the id of the user since each note should have a user_id attribute. So, we don't need additional attributes for those purposes, we will use the methods of those classes (notes, annotations, and so on).

[xltvy]

Ok, both of them makes sense and I think now we have a separate Lecture Admin class. So, first one resolved by itself. For the second one, your solution also makes sense. I just have one question about it: Where do we store tables for notes, annotations etc?

[bahricanyesil]

Ok, both of them makes sense and I think now we have a separate Lecture Admin class. So, first one resolved by itself. For the second one, your solution also makes sense. I just have one question about it: Where do we store tables for notes, annotations etc?

Thank you for your response. Yes, we have a separate class for it.

For the second one:
We have the

• "Note" class issue here
• "Annotation" class issue here

I think there will be separate tables in the db design for the classes we created here (one-to-one relation).

[xltvy]

Ok, thank you. Closing the issue.