Brought to you by: Jason Corso, Anya Kanevsky, Jeremy Mullendore, Lewis Raszewski.
Clarifications
Below is a list of issues that were brought to our attention during Design Document Creation, and an explanation for them
- How will the system be initialized? I mean who and how will start the system
before any member will sign in?
There exists an Admin who is responsible for starting the system. This Admin is also the only person capable of adding, removing, and locking members of the system. The Admin need not be a member of the group. - Is manager a subclass of Member? If so what kind of methods will be there
corresponding to his/her privileges?
We have come to the conclusion that the while using our system, the team manager is functionality equivalent to a regular member. Thus, we are not creating a separate class for Manager. However, as you can note from the meeting diagrams, there may exist a leader for a meeting. This leader can be any member of the team and will change inter and intra meeting. - In UC3, other calenders are not updated if member edits an entry. What about
deleting an entry, who can delete (update) an entry? (I guess you have scheduler
in the CalendarEntry for this purpose, but it is not clear from the use cases.)
See UC3 for an update
Note: We assume a good natured team in this project which relieves the need for complicated permission setting. We evaluated the scope of this semester's project and pushed the issuing of Object based permission to a future extension of this project. Thus, any member may edit any calendar entry. - What happens if a non team member tries to join a meeting? In general it is
not clear how team specific data like calendar, files, scripts are prevented
from outside world. (I don't know if Javaspace handles these issues for you.)
C&D is intended to be used by one development team exclusively. Thus, there will exist a separate C&D install for each project development team. We felt this restriction was satisfactory for our current system and plan to leave the extension to a multi-team domain to future work. External security is left to external devices, such as network firewalls, etc. - Can WBPrimitive objects like circle, rectangle be moved, resized? Use-cases?
These objects, as in traditional whiteboards, are immutable. - In distributing a file or setting a meeting only the active users are notified
(I assume active user means one who is already signed in). What happens if I
wasn't online at that point?
In distributing a file, a notification for each team member is written to the JavaSpace. This notifcation is written for each member regardless of their current online status (see updated UC7). The JavaSpace inherently handles the persistence of this data. - Can one be a member of two teams? If this is allowed (which is reasonable)
what will be the complications?
C&D is intended to be used by one development team exclusively. Thus, there will exist a separate C&D install for each project development team. We felt this restriction was satisfactory for our current system and plan to leave the extension to a multi-team domain to future work. - Use cases for replaying a script.
- Use cases for some file operations (e.g. deleting, updating).
- What are the buttons 'add user', 'delete user', or the access list at your
whiteboard GUI?