-
Notifications
You must be signed in to change notification settings - Fork 3
Design Documents Feedback
Burak Ömür edited this page Apr 2, 2020
·
19 revisions
- 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? You may add several states or behavior to Journal class, such as Publisher info, or Volume etc.
- 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
- 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.
- 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.
- 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?
- Why does Issue class is the subclass of Milestone class?
- 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.
- However, as a general comment, it is a good class diagram :)
Sequence Diagram
- 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.
- 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.
- 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.
- 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?)
- 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.
- 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?
- 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.
- “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) ?
- 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?
- 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.
- 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.
- 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