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


The focus of M6 was to provide a way to merge people and genealogies. Anyone with a little experience with Graph Theory can tell you just how quickly this can get complicated. In addition, this required us to build on top of our searching criteria from M5 to take account for familial relationships when deciding whether or not to merge data.

Matching Algorithm

We decided that our matching algorithm would utilize the same criteria as M5 plus room for "bonus points". These bonus points came in the form of two persons having alike parents, spouses, or children. Except for parents, these criteria could only increase an overall match rating. However, if two persons had disalike parents, this could completely rule them out from matching contention. One quirk with our system is that these bonus points filled in for any lost points. This is not the most favorable way to do it, because there is no constant ratio of person data matching to familial relationship matching, but this allowed us to factor family relations into our functionality while making it easy to re-use existing code.

You Got Merged!

As you may have noticed, our merging doesn't get very far or do anything too complicated. During the design phase, a lot of time and effort went into planning ahead multi-generational merge capabilities. These involved dictionaries and stacks to keep track of what was designated to be merged and what was already merged. Unfortunately, this planning was not enough, and we quickly realized just how boned we were during implementation. However, we did create a lot of nice windows that might provide to be useful for your project, so we'll show those off instead.

Merging can be initiated in two ways. Either from the Person view or from the Genealogy view. In both cases, the user was given a list of ranked candidate matches or pairings and given the decision on where to start. Once the user selected two people to merge, our program attempted to consequently merge their genealogies as well (however we never got around to supporting intra-genealogy merging).

For the most part, we tried to give the user as much input as possible when deciding how to merge data. When merging two people, we provided a nice interface to pick and choose what data to use from each person (or throw out completely).

Once a person was successfully merged, our algorithm attempted to merge the families in which the original persons were children. In the same fashion, the user was presented with options on which data to take, merge, or to ignore.

If a family member was designated to be merged, they were supposed to be put onto a stack for later merging. Also there was a window to deal with spouse family merging, but time constraints (code-phrase for Dano's incessant napping) stopped us from fully implementing these.

Despite this, I think the most important thing that you, as a CS2340 student, can take from our sixth milestone is our GUI-design. Especially the use of PluggableListMorphs. We use PLM's in a lot of our interfaces, and some of them are really interesting. In a lot of our merge windows for instance, selecting a person from a list triggers a info pane to be presented about the person's vital statistics. If you play around with our stuff and look at the openAsMorph message for any GUI class and the corresponding methods in the "listing" or "lists" category, you should be able to understand how to do what we did. Although this may not help add functionality to whatever kind of project you're working on, it will definitely help impress your TA by showing how well you "know thy user for they are not you".

Pitfalls and Updates

When we first started designing our GUIs in M2, we weren't too familiar with the observer aspects of Squeak. Because of this, a lot of our code had to be changed later on to make better use of changed: and update:. Going back and "fixing" pre-existing code that technically already works can be a big pain, so I would recommend understanding these aspects as early as possible. You can see from our code that most of our GUIs were re-done to fit this concept, but that some vestiges of our old way still exist (see the refresh method). The quicker you understand MVC and observer, the better off you'll be for this class.

Link to this Page