Person: Commitment:
Pictures:
Justin Object interaction diagrams for:
addAppointment
addWeekly
addDaily
showAppointments
removeAppointment
Shawn "New" class diagram
Text:
Justin explaination of "new" class diagram.
Ben Use cases:
addWeekly
addDaily
showAppointment
removeAppointment
Web:
Shawn think about restructuring the web page
(you and I should get together)
Code:
Ben Schedule
addWeekly: aGoal, addDaily: aDaily
Justin Daily
fillDaily, role, boundaries
Goal
fillWeekly, role
Alex Roles
addWeekly: aGoal, addDaily: aDaily
Role
addWeekly: aGoal, addDaily: aDaily
Shawn User
addWeekly: aGoal, addDaily: aDaily,
showAppointments, removeAppointment
Week
addWeekly: aGoal, addDaily: aDaily
This is a pretty long list! There are a couple of other things to note though;
Since Shawn has taken on Weeklies, Dailies, and Appointments as a part of Week
I'm reassigning Appointment to Justin, now Justin has all the types of Goals.
The object ownership now looks like this:
Justin Shawn Alex Ben
--------- --------- --------- ---------
Goal User Roles Schedule
Daily Week Role
Appointment
I think this evens out the work load a bit even though Shawn has done a lot
more than the rest, and still will since he has the two biggest classes. Since
this is the case I'm giving him the right to reassign up to half his methods to
any of the other three people (half in difficulty, not number, as determined by
the project manager which is me for now :). I would also like to see along
with the pictures for the use cases all of the message info:
Reciever message: arguments returning
for each method (the drawing could be created by the table).
Project Manager--Ben