View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Sp2002 Midterm Review: What's wrong with this picture?

Back to Spring 2002 Midterm Review


a. Student is a God/Manager/Controller class.

b. Avoid cs jargon like "LinkedListOfShelves".

c. Date and Time should be attributes of another candidate object.

d. 1. If every Employee has an hourlyWage, then every employee is a SalariedEmployee, and this is not a generalization - specialization relationship.
d. 2. weeklySalary is a calculation of hoursWorked and hourlyWage.
d. 3. payForHours and payForWeek should be resolved, it is redundant and confused at best, and at worst could cause duplicate work by an employee.
d. 4. If CrossingGuard isVolunteer then the superclass Employee's hourlyWage would be zero. Employee should not have anything about salary or pay, that should be in SalariedEmployee. A Volunteer class should separate Crossing Guard and Employee.

Hank Wilde

a. CrossingGuard should be more general, such as a Volunteer subclas of Employee.
b. LinkedListOfShelves is really to implementation specific for CRC cards. Maybe an Inventory class or something would be better
c. I don't believe you need CRC cards for existing classes.
d. It seems as though Student is now a 'god' class. Also it seems as though Transcript is a responsibility of the Registrar who probably would need to collaborate with the Transcript.

Randy Rockinson

b & d - are close. a and c are not. Mark Guzdial

a. I'm assuming the picture at the bottom goes with this question. The diagram has Student being the central class that keeps track of the Department and the Registrar. These are seperate entities. Instead there should be a dependency relationship. They talk to each other when needed.

b. WarehouseLocation does not need to be a class. It's just a datatype describing an attribute of a warehouse. Maybe a Warehouse class that holds a location would be better.

Marco Rogers

a. I'm going to answer the question about the first diagram here, which is actually asked in part d. The attribute hourlyWage and method payForHours of Employee don't apply to both of its subclasses. If a crossingGuard is a volunteer then they won't have an hourly Wage and won't get paid. Since a salariedEmployee gets paid by the week, they won't have an hourlyWage and won't need to call payForHours. This could really be designed with Employee knowing a name and address, then three subclasses, HourlyEmployee, SalariedEmployee, and Volunteer.

b. You could have a class called Shelf, that fact that it might be in a linked-list is unimportant at this point in design. Also, WarehouseLocation should be an attribute of Item, not a class itself.

c. It seems as though it would be better to subclass Date and Time in order to get the functionality that has already been implemented, but be able to add and change things for your new system as necessary.

d. I'm going to answer the question about the second diagram here, which is actually asked in part a. I agree with Randy on this one, Student is doing way too much work here. It is the only class with methods, and the rest have only attributes. No part of this system could be reused without the student.

Bill Branan

b)I agree with Bill about the Shelf, but I also think that there should be a class Warehouse that knows it's location and possibly holds a LL of shelves. Also, Shipper and Supplier seem to be specific to each Item, shouldn't they be instance variables inside of Item? Kathryn Leland

a. Since we have a salariedEmployee class the Employee class should be generalized more and the wage attribute be removed. The other flaw is that the CrossingGuard could either be a paid employee or a volunteer, in which case the wage could probably go in as an attribute.
b. Item is too general and does not tell us much about the class, and since there are no other obvious specializations of this class, it could be more specific, but this might not be neccessarily be true.
c. While designing we would want to focus on the requirements of the program, so unless they are relevant to the design of the system they should not be discussed. Also implementation comes later, so after deciding all the objects that the program needs - one can see if that is functionality is already built into the language.
d. The registrar class might need to collaborate with the department class to get the pre requisites for the department and whether they have been fulfilled by the student. In this case it would then have to collaborate with the Transcript class.

a) First of all, this is supposed to be an OO design, which is associated with real world objects. I have never seen a student who hasA Department, or hasA Registrar. So, theRegistrar and myMajor instance variables should not be there (myMajor should be inside Student, I think). Second, some of those methods in students should be in Registrar.

b) First, WarehouseLocation should not be an object.. maybe a Warehouse with an attribute called location? LinkedListofShelves should be Shelf.

c) If it's required to use all the methods in Date and Time and nothing else, then I guess it's fine.

d) Should be something like this: (well, I think)
—> WagedEmployee
|—> CrossingGuard
—> SalariedEmployee

Link to this Page