Brought to you by: Jason Corso, Anya Kanevsky, Jeremy Mullendore, Lewis Raszewski.
Actor identification
There are several levels of abstraction from which to view the application and the actors involved. On the most superficial level we have:
- users - this category includes every subcategory listed below. It is all those who log in and use the C&D applicaiton
- administrator - user who holds special priviledges and responsibilities. Administrator installs the application, configures it, adds/removes users.
They can be described differently for some purposes:
- team members - may have a variety of positions that they hold in their work, but as far as the application is concerned, they are equal.
Going a level deeper, in scenarios such as meetings, other roles emerge as well:
- leader - the person who is responsible for conducting a meeting, and controlling the format and procedure of the meeting. It is reasonable to suppose that the manager will be the leader but it is in no way required.
- speaker - the person who is not a leader in the meeting but is currently the one presenting or discussing some issue. This role can be passed around to all the participants as in the case of a progress meeting, or given to just one or a small number of participants depending on the context of the meeting/activity.
- participant - everyone who is involved in a given meeting/activity.
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, view any Whiteboard, etc.
Use Cases
Design Note: we have noticed that there is a pattern of data flow in our design, which we made a universal design pattern. All the information exchange between clients is achieved via the JavaSpace: packets are sent to the JavaSpace and all the clients are listening on the Java space. This makes all our sequence diagrams look simple - but that is because they are.
Use case list (click each for elaboration)
Use cases for the Code-Walkthrough
Use Case 1 Activity Diagram
Use Case 1 Sequence Diagram (to explain data flow)
Use Case 3 Activity Diagram
Use Case 6 Sequence Diagram
Use Case 7 Sequence Diagram
Here is the activity for Use Case 9 to better explain the domain level-progress meeting.
Here is the activity diagram for Use Case 10 to better explain the design-level meeting.
Use Case 11 Sequence Diagram
UC1: Member Sign In (Design Level)
Actors: Team Member
Trigger: External Trigger - Program Launches
Procedure:
1. Member enters login information in the initial login dialog.
2. Member is validated in the system and retrieves necessary data (theJavaSpace).
3. Server application writes this Member's Member object into the Javaspace.
4. A notify_MemberLogin is passed into the system alerting every other active memberObject that this member has signed on.
5. This member enters normal work-mode in window.
Variations:
2.1 If the login information is invalid, the user repeats login (1)
UC2: User Sign Off (Design Level)
Actors: Team Member
Trigger: In Normal-Op mode, select Sign Off
Procedure:
1. Member clicks sign-off button
2. System alerts Member with a dialog if there are any impending tasks the TM must complete (file transfers, etc).
3. theMemberRegistry logs the Members sign-off
4. memberObject is removed from theJavaSpace.
4. the Member has signed off
UC3: Check Calender (Design Level)
Actors: Team Member
Trigger: CalendarView is enabled
Procedure:
1. Member selects the calendar window to be shown.
2. Member scrolls in the calendarView to the day in question.
3. If there is a current meeting, the TM joins the meeting.
Variations:
3.1 Member sets a meeting (Use Case 6)
3.1.2 If there is no time free for the Member and their task is important, the TM might initiate contact with the person who has already scheduled a task at the current time.
3.2 Member might wish to edit a current entry.
3.2.1 Member selects the entry and clicks edit.
3.2.2 Member edits the entry.
3.2.3 CalendarPacket with updated entry is written to JavaSpace.
3.2.4 CalendarNotify is written to JavaSpace for each TeamMember notifying them of the edit to the Calendar Entry. Note that the JavaSpace inherenly handles the time/synchronization of these Entries which alleviates any need for extra "locking" information.
UC4: Normal Operation
Actors: Team Member
Trigger: No explicit trigger.
Procedure:
1. Member is logged into the system, but using other external systems at the current moment
UC5: Communicate with another Member (Design Level)
Actors: Team Members A and B
Trigger: A message sent from A to B
Procedure:
1. A sends an initial message to B.
2. B responds.
3. If B is free, they chat.
Variations:
3.1 B responds that she is busy upon which B and A check calendar and schedule a meeting.
3.1.1 B responds that she is busy but can easily post a file onto the common space for A to refer to.
3.2 Chat is not enough for their needs, and they create a WhiteBoard.
3.2 WhiteBoard is not enough for their needs, and they enter the meeting space and being an impromptu code-walkthrough session.
UC6: Set a meeting
Actors: Team Member
Trigger: In CalendarView, click "Set Meeting"
Procedure:
1. A dialog pops up which allows the meeting attibutes to be set. These include, date, time, type of meeting (code-walkthrough, status, brainstorm, etc), participants involved, Leader of meeting.
2. The meeting is added to the TeamCalendar.
3. The Member's Client write a notification into theJavaSpace alerting the Team that there is a new meeting.
4. Each active Member listens on theJavaSpace for a notify_NewMeeting. When one is found, they update their TeamCalendarObject and their CalendarView is refreshed reflecting the new meeting.
5. Meeting is set.
UC7: Distribute a memo or file (Design Level)
Actors: Team Member
Trigger: In Normal-Op mode, click distribute object
Procedure:
1. A dialog pops up which allows the Member to select the file (memo, source code, image) which is to be distributed.
2. The system copies this file to theJavaSpace.
3. The file is added to theFileList
4. A notification is written to theJavaSpace alerting the change of theFileList.
5. A notification is written to theJavaSpace alerting the distribution of a fileObject on theFileList
6. Each Member retrieves the file.
Variation:
6.1 A member is not currenlty logged on. The JavaSpace maintains the time-stamped notification for in-active members. When they next logon, they will be notified of the distributed file's presence
UC8: Meeting (Domain level use-case)
Actors: Participants, Leader, Speakers
Trigger: Meeting scheduled on calendar
Procedure:
1. Leader (usually person who called meeting) gives intro on
goals of meeting and its agenda
2. Leader follows the agenda of the meeting (which is
available to all Participants)
3. Participants comment/contribute/brainstorm using the
whiteboard as necessary
4. When Leader is finished with agenda, conclude meeting
Variations:
2.1 The meeting may not be a formal one, & therefore not have a preset agenda -
just a purpose
UC9: Progress Meeting (Domain level use-case)
Actors: Participants, Leader, temporary role of Speaker
Trigger: Meeting scheduled on calendar
Procedure:
1. Leader selects Speaker.
2. Speaker reports current status and progress using
whiteboard if necessary.
3. Speaker lists any blockers
4. Participants offer ideas/suggestions
5. Leader selects next Speaker
6. Repeat steps 2 - 5 untill all group memebers (including
Leader) have reported.
7. Leader closes meeting.
Variations:
3.1 Speaker doesn't have any current blockers
4.1 A meeting is scheduled between Speaker & another group
member(s) to discuss ideas/suggestions regarding Speaker's report.
5.1 Leader may have decided on a time limit for each Speaker,
in which case he will interrupt at some point to select next Speaker.
UC10: Join & Participate in a Meeting (Design level use-case)
Actors: Team Member (TM), Participants
Trigger: Meeting scheduled on calendar
Procedure:
1. User opens dialog to connect to meeting space.
2. User selects meeting to join.
3. User is added to membersHere vector in Meeting.
4. MeetingView is opened in users ClientApp
5. User writes messages in chat window
6. User writes questions in question window
7. User draws on whiteboard.
8. User posts notes.
9. User selects "exit meeting" and leaves.
Variations:
5.1, 6.1, 7.1, 8.1. Steps 5-8 can be performed in any order and any of those steps may be omitted and repeated.
UC11: Add To A Whiteboard(Design level use-case)
Actors: Team Member
Trigger: Primitive Selected in WBView and Added to WBCanvas
Procedure:
1. Member selects a WBPrimitive from the toolbar.
2. Member draws on the WhiteboardView with the WBPrimitive.
3. A new WBPrimitive object is created by the Whiteboard.
4. A WBPrimitivePacket is written in to theJavaSpace.
5. Each activeClient for this Whiteboard reads the WBPrimitivePacket and updates their respective WhiteboardView.
UC12: Add User (Design Level)
Actors: Administrator
Trigger: new Team Member
Procedure:
1. User signs in as administrator (see User Signs In )
2. Administrator selects "Add User" option
3. A window asking for user information (AddUser_Info dialog) comes up.
4. Administrator fills in required information (username, First Name, Last Name, email).
5. Administrator selects "Confirm" option.
6. User info is sent to the javaspace.
7. New member information is added to the MemberRegistry.
8. Success and new UserID is returned to Administrator
Variations:
5.1.Administrator selects "Cancel" option and no new member object is created.
8.1 AddUser fails and error report is returned to administrator.
UC13: Remove User (Design Level)
Actors: Administrator
Trigger: Team Member Leaves Team.
Procedure:
1. User signs in as administrator (see User Signs In )
2. Administrator selects "Remove User" option.
3. A RemoveUser dialog comes up.
4. Administrator fills in required information (username, userid, or some other combination of info.)
5. Administrator confirms the "Remove" option.
6. ServerApp removes member record from MemberRegistry.
Variations:
5.1.Administrator selects "Cancel" option and user is not removed.
UC14: Play a Transcript (Design Level)
Actors: Team Member
Trigger: Team Member selects viewTranscript in MainView
Procedure:
1. ViewTranscript dialog pops up for user to select the transcript.
2. Appropriate Transcript object is returned to TranscriptView.
3. TM selects one of the options to play the transcript (Rewind, Step Back, Play, Step Fwd, Fast Fwd, Pause) in any order necessary.
4. User exits transcriptView.
Code-Walkthrough Use Cases
UC-CW1: Present a code walkthrough
Actors: Leader/Speaker, Participants
Trigger: Leader activates the code walkthrough module and waits for
his audience to join
Procedure:
1. The Leader is shown a file selection dialogue, from which he
selects the file for his presentation. A CodeWalkthrough object is created,
referencing the external file. A Transcript is created for the meeting.
2. A CWTView is created. The source file is loaded as the background
to the associated Whiteboard object.
3. The Leader selects a line of code. This line number is attached to
subsequent MeetingPackets, which are sent to the server as he makes
comments in the chat window. The WhiteboardView illuminates the line
number of the last received MeetingPacket.
3a. Each MeetingPacket placed on the server is copied into the
associated Transcript
3b. Each active user retrieves the MeetingPacket from the server
and updates their ChatView accordingly.
4. Step 3 is repeated until the walkthrough is completed
5. The Leader exits the codewalker interface by pressing the "End
Session" button. The completed Transcript is added to the repositiory.
Variations:
In place of any iteration of step 3, insert any of use cases CW2-CW6,CW9-CW11
UC-CW2: Write a visual cue onto the code
Actors: Leader
Procedure:
See Use Case UC11.
UC-CW3: Add a note to the source
Actors: Leader
Procedure:
1. The Leader presses the "add note" button
2. The Leader clicks at a position in the code view window
3. The "Edit note" dialogue appears, allowing the Leader to type in
a textual note
4. The Leader presses the "OK" button. A packet is sent to the server
describing the note.
5. A Note object is created on the server containing the
input text, which references the Whiteboard.
6. Each active user receives the Note, and shows the note symbol at the
apropos position in the CWTView
UC-CW4: Answer a question from the audience
Actors: Leader, Participant
Trigger: A user has posed a question (see case CW8) which the Leader
wishes to answer
Procedure:
1. The Leader selects the question from the question display
2. The source code region referenced by the QueryPacket is highlighted
3. The Leader presses the "Answer" button
4. The QueryPacket is rewritten as a MeetingPacket and sent
to the server, causing the question to appear in the ChatView of all
users (as in CW1.3).
5. Local copies of the corresponding QueryPacket are deleted, causing the question
to disappear from the question display.
6. The Leader composes a response in the same method as giving a
comment on a line of source.
Variations:
2b. The user may change his mind, and end this case here, or he may
select several questions in rapid succession, viewing the line
highlighted for each. Only the question selected when the "Answer"
button is pressed is considered "answered"
UC-CW5: Change the current file
Actors: Leader
Procedure:
1. The Leader presses the "change file" button
2. A file selection dialogue appears
3. The Leader selects the new file. A packet is sent to the server
instructing it to change the current file, which is copied into the
transcript.
4. The background of the associated Whiteboard is
updated to the new file.
Variations:
2b. The user may cancel the operation instead of selecting a new file.
UC-CW6: Allow another user to take over the presentation
Actors: (old) Leader, Participant (Leader-to-be)
Procedure:
1. The Leader selects a user from the list to take over as Leader
2. The Leader presses the "Yield floor" button. A packet is sent to
the server instructing it to change ownership of the CodeWalkThrough
3. The selected user becomes the new Leader
UC-CW7: Watch a code walkthrough
Trigger: A code walkthrough is in progress. The user wants to join.
Actors: Leader, Participants
Procedure:
1. The user activates the code walkthrough module, becoming a Participant
2. As each packet is sent to the server by the leader, the server performs
the necessary computations. The user reads the packet and his CWTView is
updated accordingly.
Variations:
During step 2, the user may engage in any of CW8-CW11
UC-CW8: Ask a question about the current walkthrough
Actors: Participant, Leader
Procedure:
1. The Participant selects a line of code in the code view
2. The Participant presses the "question" button
3. A text dialog appears, wherein the user types his question.
A QueryPacket is sent to the server, containing the text
of the question, and the line reference.
4. All connected users receive a copy of the packet, and display it
in the Question window.
5. The user waits for his question to be answered
UC-CW9: Get user information
Actors: one or more users
Trigger: One user wishes to know public information (Name, location,
etc) about another user
Procedure:
1. The user selects another user from the list of users
2. The user presses the "User Info" button
3. The user searches the JavaSpace for the MemberInfo object
for the specified user. This object is displayed for the user.
UC-CW10: Conduct a private chat with another user
Actors: At least two users
Trigger: a user wishes to speak with another user during the meeting
outside of the public channel.
Procedure:
1. The initiating user selects another user's name from the user list.
2. The user presses "Private chat"
3. A new Chat is created between the two users.
4. When the user tires of the chat, he closes the dialogue.
UC-CW11: View a source note
Actors: any Participant
Procedure:
1. The user presses the "view note" button
2. The user clicks the note symbol corresponding to the desired note
3. The user searches the JavaSpace for the Note object
they have selected. The result is displayed for the user.
Variations:
3: If the user is the writer of the note, the window which appears
allows him to edit the text of the note, or delete it.