Report - (3rd Sem.) Week 5 📢 #134
Replies: 3 comments
-
|
Hello. I like your class proposal. I would consider it very complete, covering all the necessary functions, but still simple. This is a good thing, often less is more. I also appreciate the external explanation of the classes, which makes your work more clear to us. Keep going, CookPit. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I really love your detailed overview of the classes and the project. It's very easy to see what you are doing and how your Project works. I also appreciate the explanations on what the classes are for at the end. our Sprint Overview is always a big plus. Only small issue I see is that the explaiantions of what the classes do are very technical and it takes 2-3 readings to fully understand. If there was a way to make it easier, that would be perfect, however its fine as it is as someone with a little clue of the topic can still understand it pretty easily |
Beta Was this translation helpful? Give feedback.
-
|
Hi, i really like your detailed diagrams. Furthermore the explanation enhances the understanding of that. The effort you put into describing your classes eventually pays off. I like your detailed little review of your sprint. |
Beta Was this translation helpful? Give feedback.
-
Welcome to our fifth report of our project. We are excited to share the latest news with you! 🥳
Initiation of the UML-class diagram 📝
We have further identified and refined our entities and their responsibilities in the UML-diagram below followed by a rather detailed
description of these classes and their relationships with each other:
Accounts 👥
In order to exist on the website, the users need to create an account. An account is identified by its id and contains a username, email and password. Depending on the actual purpose of the account, a user may either be a client user which is the target group of our endproduct, or an administrator who has a rather technical view of the website and is responsible for the issues the client users encounter.
The client user differs itself by the option of beeing personalized. This includes the own description, age and the actual course in which the latter studies in. Each client user can only study in one course. If either of both entities choose to delete itself, the corresponding
account entity also gets deleted.
Course and Faculty 🏛️
A faculty is identifiable by its id and name and can contain several courses. Each course has similar attributes and can only be related to one faculty. An example might be "IT" or "Economics" for a faculty whereas "TINF22BX" might be a course.
Posts 📯
Every client user can create several posts. Each post is identified through its id, a title, a description of the problem or question, the timestamp of the creation of the post, the amount of upvotes/likes and several tags, which you can use to search for similar posts. Users can not only create a post, they are also able to save them. In contrast to post creation, saving a post may happen from every user, not only the creator.
Comments 💬
Similar to posts, each client user is able to comment several posts. This means that each post may contain several comments. However,
if a post gets deleted this affects the respective comments too. Latter also have less attributes: These are its own id, description and the date in which the comment has been created.
Pictures 🖼️
Pictures are optional entities which may be used by different other classes. An account is able to upload an picture to further personalize itself. Pictures can also be used by adding them during the post creation.
Additional ER-model
Moreover, we have created the following ER-model for the general classes and entities of our project and added it to our srs-document.
Sprint 3: What have we achieved ❓ What's to come❔
Until next week 💯
Your DHBWhub Team
Beta Was this translation helpful? Give feedback.
All reactions