-
Notifications
You must be signed in to change notification settings - Fork 3
Design Documents Feedback
- Nice use case diagram :) I have some minor comments below.
- :)
- What are the requests in the use case of “Accept/reject requests” what extends “view own workspaces”? Are they the incoming collaboration requests?
- more specific description added
- You can add a “delete material” or “edit material” that extends “upload material”
- Added
- I am confused with “view own workspaces”. Are they the ones created by me or does it also cover that I am participated in? If so, do they provide the same functionality to owner and the collaborators?
- Made more detailed
- What is SFC and PS?
- Annotation added
-
As an example, in WorkspaceController class, why “invitations” and “applications” are static, but “workspaces” is not?
- We change our design. In the new design the Controller classes are all singletons. So all the fields of these classes are non-static. But they have only one instance in the system. Also we add a new list, which keeps the workspaceId's of registered users.
-
You may add several states or behavior to Journal class, such as Publisher info, or Volume etc.
- We added those, also we added issue number field.
-
I think, there should not be an aggregation between UpcomingEvent and Workspace, since UpcomingEvent is a class, or instances are independent objects by themselves without affected by a Project instance. Same applies for UpcomingEventContoller and UpcomingEvent
- Due to your answer to our last question, we change our cardinality values and make Controller classes singletons(excluding ResearchItemController). With these changes we try to make our controller classes single in the system.
-
I am not sure, it is actually a design issue, but Controller classes should be more general, instead of belonging to a single instance of object. For example, it seems that each user has its own CommentRateController. But it would be better to implement CommentRateController as the class with system-scope to deal with all commenting and rating operations of all users.
- We change our design and make controller classes singletons. If these changes don't provide this meaning, please give us feedback. Because we are not sure about this.
-
An ActivityStreamItem may also include a field like “owner”. A user that I am following or collaborating has an activity on the system, and that activity item falls in my home page. This item belongs to the user I am following, which should be also specified with an identification.
- Done
-
Recommendation system should also be related to the Workspace. Besides, why does the SearchEngine depends on the RecommendationSystem? Which method of the SearchEngine actually utilized the RecommendationSystem. Similarly, why does WorkspaceController depends on SearchEngine? The dependencies should be rechecked.
-
I don’t get the objective of the Filter class. What is the usage of it, can you explain it briefly?
- We hold the search history and the user can save the filters they use to search. Besides, it looks more simple when we have Filter class.
-
Why does Issue class is the subclass of Milestone class?
- Because they both have the same attributes, although they do not mean the same thing. Like a dog and a children, they both need to be fed, and be loved etc. but they are not the same.
-
UpcomingEventController is I think not related to the User class. It should just update the event or similar functionalities, without being actually related to a user object or depend on it.
-
Class diagram is really detailed, there may be other minor details, please check them.
- Done
-
However, as a general comment, it is a good class diagram :)
- :)
-
Most of the feedback about the class diagram states problems about the relations in the diagram. We change most of the relations according to your answer in the piazza
- Relation changes => UpcomingEvent-UpcomingEventController(one-way association)
- Worksapce-WorkspaceController(one-way association)
- ActivityStreamController-ActivityStream(one-way association)
- CommentRateController-CommentRate(one-way association)
- NotificationController-Notification(one-way association)
- SearchEngine-RecommendationSystem(change the direction of dependency)
- Controller-RegisteredUser(two-way association)
- User-UpcomingEventController(dependency)
- SearchEngine-UpcomingEventController(dependency)
- SearchEngine-Filter(dependency)
- For example, since you are creating a new Workspace object (in the 2nd sequence diagram), the “ws” object should be positioned in an aligned manner with the createWorkspace message.
- This was changed according to your answer in the Piazza.
- workspaces.insert(ws) is a valid statement, but not a valid message in a sequence diagram. Either it should be stated as a method, or left out by assuming that adding ws into the list is an instruction that is part of createWorkspace message. Same applies for all .get, .insert etc. list and map operations in all diagrams.
- In Workspace Creation and Link Google Scholar/ResearchGate Account diagrams these, it is assumed that other functions makes this insertion operation.
- I think linking Google Scholar and ResearchGate profiles should be separate operations, both in the sequence diagram and the class diagram (as separate methods in AccountInformation class). The reason is that either is optional. I can just link to my Google Scholar account without linking to ResearchGate. You should also show the API usage for fetching the information from google or researchgate in the sequence diagram, as a separate object/class.
- We added the API usage and divide this diagram into 2. Also, I update the class diagram.
- In the same diagram, shouldn’t I call “addResearchItem” method instead of inserting to the list (this message can be sent to either AccountInformation or ResearchInformationController?)
- We also use this function in the new version of the diagrams.
- Notification Creation diagram could be better :) There should be a sequence of operations (just one of the possibilities is ok), that triggers the notification creation shown in the sequence diagram.
- Made more detailed
- I think “Viewing Activity Stream” is not a key use case. It is just view-get :) There is no “viewActivityStream” method in ActivityStreamController class. Additionally, how does it calls getActivityStream(Ahmet) without receiving any argument from registeredUser? The user passes itself as the argument?
- Removed
- Comment/Rate sequence may start from an earlier step, like searching user, viewing its profile. I think inspectUser method does a similar stuff, but let’s make it more comprehensive.
- Added a reference block.
- “Commenting not permitted” or “commenting was successful” should be returned to the registeredUser I think (check returns to user in the else part of first alternative, but I think it is not the return of addComment method) ?
- Changed it.
- I am a little bit confused in this commenting diagram. Each user has its own CommentRateController. So, user oyku sends its addComment request to comCont object of CommentRateController class. If commenting is successful, new comment is added to the same comCont object, that belongs to oyku, but that comment will appear on cihat’s profile, right?
- Actually, CommentRateController is a static class, so not everyone has a different controller. We changed it in the class diagram.
- Invitation could be also better. It is something more than just “inviteUserToWS”. You can find a user from a recommendation, or search someone specifically, go its profile, then send an invitation for collaboration etc. Also, the system should initially check the workspace information. Where does this information come from? The user first getWorkspaces list etc.
- Changed it so that the user searches for a another user first.
- In responding to invitation diagram, again, I should first check my notifications or see the list of invitations in my profile page etc. Then, I can accept or reject it. If it is notification, then it should be updated as “seen”. Depending on “answer” (the one in the argument list), not just “check”, there should be two separate alternatives.
- Changed it so that the user checks theirs notifications to find the invitation.
- Requirements
- Workspace Creation Scenario
- Application to a Workspace Scenario
- Follow Mechanism Scenario
- Design Documents
- Plan Documents
- Milestone Reports
- API Documentation
- Manuals
- Burak Ömür
- Halil Umut Özdemir
- Hasan Ramazan Yurt
- Öykü Yılmaz (Communicator)
- Ahmet Dadak
- Ertuğrul Bülbül
- Alperen Divriklioğlu
- Burhan Can Akkuş
- Hüseyin Can Bölükbaş
- Hilal Demir
- Umutcan Uvut
- Orkan Akisu
- Frontend Meeting #7 (19.01.2021)
- Frontend Meeting #6 (12.01.2021)
- Android Meeting #5 (08.01.2021)
- Frontend Meeting #5 (05.01.2021)
- Backend Meeting #6 (30.12.2020)
- Meeting #26 (29.12.2020)
- Meeting #25 (28.12.2020)
- Backend Meeting #5 (23.12.2020)
- Frontend Meeting #4 (21.12.2020)
- Android Meeting #4 (18.12.2020)
- Backend Meeting #4 (16.12.2020)
- Meeting #24 (15.12.2020)
- Meeting #23 (09.12.2020)
- Frontend Meeting #3 (10.12.2020)
- Android Meeting #3 (09.12.2020)
- Backend Meeting #3 (09.12.2020)
- Frontend Meeting #2 (08.12.2020)
- Android Meeting #2 (07.12.2020)
- Frontend Meeting #1 (03.12.2020)
- Android Meeting #1 (02.12.2020)
- Backend Meeting #2 (02.12.2020)
- Meeting #22 (25.11.2020)
- Meeting #21 (21.11.2020)
- Backend Meeting #1 (18.11.2020)
- Meeting #20 (17.11.2020)
- Meeting #19 (10.11.2020)
- Meeting #18 (30.10.2020)
- Meeting #17 (27.10.2020)
- Meeting #16 (24.05.2020)
- Meeting #15 (13.05.2020)
- Meeting #14 (10.05.2020)
- Meeting #13 (07.05.2020)
- Meeting #12 (30.04.2020)
- Meeting #11 (23.04.2020)
- Meeting #10 (17.04.2020)
- Meeting #9 (16.04.2020)
- Meeting #8 (09.04.2020)
- Meeting #7 (22.03.2020)
- Meeting #6 (12.03.2020)
- Meeting #5 (05.03.2020)
- Meeting #4 (28.02.2020)
- Customer Meeting #1 (28.02.2020)
- Meeting #3 (27.02.2020)
- Meeting #2 (20.02.2020)
- Meeting #1 (13.02.2020)
- Meeting Notes Template