Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Fall2002 M2 - Check and complete the object structure
M2 - Handle, correct, and support a correct genealogy
Remember how we said in M1 that we'd make sure that there are no inconsistencies in the objects relationships? And that we'd provide both direction relationships? NO MORE! You can now assume that the database that's given to you is inconsistent, has important missing information, is lacking mirrored relationships – just like when you really are trying to build a genealogy.
You must support (on a Person p) the message check which will do three main tasks and return a nicely formatting string with a report on what happened in this check (in other words, you'll PrintIt on a check more than DoIt):
- Check for vital information: You need to check each person in p's family tree (up and down) for missing vital information. One kind of missing vital information is name, birthdate and location, and deathdate and location. Another kind of missing vital information is implied. If p has no listed spouse, but does have children, then there probably was a marriage that you haven't found yet – that's a piece of vital information. If p has no parents, that's a piece of vital information.
For each piece of vital information that you identify, you must report it in the check output AND YOU MUST SUGGEST WHERE THE INFORMATION MIGHT BE FOUND! In other words, check out the databases available on the Web (several are linked to the pages listed on Fall 2002 Project Milestones) where the missing information might be found, and suggest those URLs in your report.
- Connect mirror and transitive information: If x is married to y, make y married to x. If x is y's sibling, make sure that y is x's sibling. If x is y's sibling, then x's parents are y's parents (if one of x or y's parents is missing – it is possible for x and y to have different parents but be siblings).
- Identify contradictions and conflicts: Marriages should always occur after the participants were born and before they die. All death dates should come after birth dates. Mothers can't die before their children are born. Fathers can't die more than nine months before their children are born.
You must also support searches on your family trees. You will construct Query objects that you will ask the Person p to searchFor:. Searches return a collection of Persons that meet the query (or reutrns empty). Valid queries include:
- Queries based on any relationship or information from M1. Query givenName: 'Fred' is a valid query. p searchFor: (Query surName: 'Flintstone') should return all those relatives of p whose surname is 'Flintstone'. Other Query messages of this type include isMale, isFemale, hasAlias, hasSibling: person, hasChild: person, hasParent: person, married: p, born: date, bornIn: 'location string', died: date, diedIn: 'location string', hasInfo: x as: y.
- Queries based on global information. Query livedIn: 'Detroit' should return all Persons where Detroit appears in any birth/date location or any miscellaneous information (like a former residence). Query livedOn: (Date newDay: 1 month: 1 year: 1900) should return all Persons alive on that date. Query generalSearch: '384' should return all Persons who have the string '384' in any information on them (such as house number or SSN).
THIS IS A TEAM PROJECT. Your teams must be defined by this date. Use the page Fall2002 Team-Forming Discussion for advertising and forming your team. A team can be no more than four people, no fewer than three. No team divorces will be allowed after P3! Please pick a Team Name. Anyone who does P2-P7 alone automatically loses 15 points ON EACH ASSIGNMENT.
In class, please turn-in:
- CRC Card analysis of objects: Classes considered and rejected, and CRC cards for each class in the user interface. It's REQUIRED to hand in xeroxed or generated-tables that represent your CRC cards rather than the actual 3x5 cards. You must also include written text of at least two scenarios that you used in your analysis.
- Documentation of a test plan based on the Equivalence Partitioning approach (discussed in class on September 12; see the slides from the ATM example atm.ppt).
- UML class diagram of classes. There should also be a written, text description of each class and what it's methods do. THINK HARD ABOUT THIS.
- Well-documented, hardcopy source code (at least two lines of comments for each non-accessor method, in-line comments at significant portions) with your Team Name and all team members' names, sections, phone numbers, and student numbers on it. The phone numbers are for us to use if teams lose touch with one another. THIS IS THE LAST TURNIN FOR WHICH YOU WILL TURN IN SOURCE CODE.
Before class time, turn-in your code using the Fall 2002 Turnin Information with the code 'M2'.
- 10% Good CRC card analysis: Reasonable names, understandable and clearly defined responsibilities, good exploration of other class names, believable scenarios.
- 10 % Good test plan: equivalence classes clearly identified, test cases clearly defined.
- 10% Good UML class diagram: Correct usage of notation (5%), understandable descriptions and names (5%)
- 10% A generally good design.
- 10% Well-documented and good style source code
- 50% Working system:
- 24% for a good check process. 8 points for making the right additional connections. 8 points for pointing out missing information and good URLs for databases. 8 points for indentifying conflicts and contradictions.
- 10% Good report output – readable and complete
- 16% Correct and complete queries – 8 points for specific info, 8 points for general queries.
Questions on Fall2002 P2 Milestone
Links to this Page