-------------------------------------------------------------------------- Software Design and Development Winter 1995 COM 1205 --------------------------------------------------------------------------- Final 168 points total QUESTION 1: 2 UNKNOWNs 30 points combined QUESTION 2: 13 UNKNOWNs 3 points each: 39 points QUESTION 3: 13 UNKNOWNs 3 points each: 39 points QUESTION 4: 2 UNKNOWNs 30 points combined QUESTION 5: 1 UNKNOWN, 30 points --------------------------------------------------------------------------- Open book and open notes. To make the grading easier, please put your values for the unknowns on the enclosed answer sheet. THE GAME OF REDUNDANCY AND UNKNOWNS ----------------------------------- Most of the questions in this exam ask you to determine unknowns of the form UNKNOWN1, UNKNOWN2, ... This makes it easier for you to answer the questions, since you get extra context information. Yet you need to master the behavioral objectives of the course to answer the questions. Guessing an answer is not a successful strategy and therefore a "game of redundancy" test is more interesting than a multiple choice test. The questions have the following pattern: I show you several artifacts which are related by the theory of object-oriented design and programming. Because of the dependencies between the artifacts, some of the information is redundant and can be recovered from the context by applying the objectives covered in the course. The information which you should discover is marked UNKNOWNx. If an unknown is not uniquely determined, mark the answer with *CHOICE*. An unknown may be anything, e.g., a number, an identifier, a character, two identifiers with a blank between them, a string etc. If an unknown is the empty string, give NOTHING as answer, e.g., UNKNOWN = NOTHING. Example: 5 + UNKNOWN1 = 8 UNKNOWN1 = 3 --------------- UNKNOWN2 * UNKNOWN3 = 20 UNKNOWN2 = 4 *CHOICE* UNKNOWN3 = 5 *CHOICE* At the beginning of a question we give the number of points per unknown. Question 1: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Class dictionary evolution, class structure design. 30 points combined. You join a company which develops meeting scheduler programs and you are asked to maintain their application. Currently they are using the following class dictionary CAL_SCHED: ====================================================================== // CALENDAR SCHEDULER class dictionary CalendarScheduler = "meetings" List(Meeting) // the following tells us about personal calendars // and preferences of local members. "members" List(Member). Meeting = "meeting" "meetingId" NumericId "title" Title Occurrence "participants" List(ParticipantAll). ParticipantAll : Member | Outsider *common* PeopleName. Outsider = "outsider" . Member = "memberId" Id [ MemberInfo]. MemberInfo = PersonalCal. PersonalCal = "personal" "calendar" List(Appointment). Appointment = "appointment" "appointmentTopic" Title SingleOccurrence. Occurrence : SingleOccurrence | WeeklyOccurrence *common*