COSC 3331 Object-Oriented Programming and Design
Project Software: The Family Tree
There is increasing interest throughout the world in genealogy, the
study of a person's ancestry and heritage. People are increasingly
interested in learning of their ancestors and their relationships.
This information is usually recorded in a family tree. Your
task is to develop a software system for maintaining and presenting
a family tree.
This section outlines the user requirements for the software being developed.
The primary task of this software is to record information about
people. The following information should be recorded about a person.
- First and last name, e.g., Homer Simpson.
- Gender (male or female).
- Date of birth.
- Date of death (may be empty). The date of death must not be
before the date of birth (obviously).
- Place of birth (town and country, e.g., Toronto, Canada).
- Mother and father.
- Children (may be void).
- Partner (may be void).
A person has one mother and one father and zero or more children.
A person may have only one partner who is alive (i.e., who does not have
a void date of death). You should not worry about special cases like
divorce (and, therefore, step-relationships).
Dates will be given as follows: month, day, four digit year. The month
will be written in text, e.g., June, November.
An example of a valid date is June 24, 1960.
The software should allow people to be added to the database. New people
should obey the constraints described above. Each person in the database
is unique. The same name may appear multiple times in the database (though
you may use discriminators like `Junior', `III', if you choose).
Once entered in the database, a person cannot be removed. However, it
should be possible to edit the information associated with a person (because,
after addition, a person may marry, or have children, or pass away).
After entering a new person, it should be possible to add the parents
and/or children of the person.
The system will contain a variable used to represent the current person.
When the system first starts, the current person will be some person in
the tree (you may choose which person, e.g., a root, a leaf; the node that
choose should be precisely documented in your user manual).
At any time, it should be possible to view the information of the
current person. The information about parents, children, and partner
should be restricted to names only.
It should be possible to browse a family tree, starting from a specific
person in the tree.
From a given person in the tree, it should be possible to browse through
the tree as follows:
- set the current person to one of the parents (mother or father).
- set the current person to one of the children.
- set the current person to the partner.
It should be possible to try to find a specific person in
a tree by searching on:
- first or last name.
- date of birth.
- place of birth.
You should decide what your system should do in the case that the search
returns multiple matches. You may choose to display an ordered list of
names, or just the first match. Try to pick a facility that you think is
most useful.
It should be possible to produce output suitable for printing. You should be able
to produce the following display formats, which should be saved in an ASCII text
file, and which may thereafter be printed by a user.
- Full tree, which displays all nodes in the family tree, organized from root
to leaves. The organization of the output is up to you. The minimum information to be displayed
for a node should be a person's name.
- Select subtree, which displays a select portion of the family tree. It should
be possible to select a rooted subtree and all nodes in this tree should be
displayed.
- Single node, where all information related to that node will be saved.
The software developed for this project is required to run on Ariel. You are not required
to make the software run elsewhere. It should compile and execute under ISE
Eiffel (which is installed on Ariel). You may develop your software under
any other version, but make sure it compiles and executes on Ariel.
It is not required that the system be finalized (i.e., that C code is generated).
This project will require a reasonable amount of design and implementation effort. The
project is large enough as is. You are STRONGLY DISCOURAGED from adding any additional
features, bells and whistles, et cetera. Project software that is well-designed, well-implemented,
documented, tested, correct,
and satisfies the requirements above is sufficient to receive a full grade
of A+.
You may want to look at EiffelBase's TREE classes, as well as STORABLE, to help
implement some of the facilities.
There are two main deliverables: a design document, and your source
code. Both are due at the end of term. However, you are encouraged to submit
a preliminary design document to the instructor for ungraded feedback before the
end of term. There is no requirement to do this, but you may find it helpful.
To keep things reasonable, and to encourage you to get started on the project
as soon as possible, the instructor will not accept design documents for
feedback after November 19. Please note that the later you hand in your
preliminary document, the less likely it is that useful feedback can be provided
in time for you to complete your project.
To obtain useful feedback, it is not necessary to have a complete
design document. An overview of your design will be sufficient, e.g., basic
classes and their relationships.
Your design document outlines the architecture of your system (i.e., your classes
and their relationships), written in BON, and discusses the major decisions that
you made in your design. It should be around 10-15 pages in length, and should be
organized as follows (page lengths are approximate).
- 1.
- Title Page
- 2.
- Table of contents
- 3.
- Statement of purpose and requirements (1 page).
- 4.
- Terse description of the design with upper level BON diagram.
(5 pages). This section is of critical importance. Point out strengths and
weaknesses of your design.
You should state all limitations with your software.
- 5.
- Brief User manual (2 pages of text at most).
- 6.
- Short form of all classes arranged alphabetically (may have lower level BON diagrams to show
further detail). Please provide the short form (not short/flat).
It is not necessary to include code in your design document.
Electronically
hand in all your Eiffel source code (i.e., your .e files), your ACE file, and
your testing. Testing will be as in the assignments. Thus, you are expected to include
test cases (i.e., source files), test output, and a brief document outlining what each test
case is aimed at checking, and what is the expected result.
All files should be tarred and gzipped, and submitted electronically using
submit. The directory for the project is called project.
You should also hand in, on paper, a copy of your Eiffel source code, along with a title
page listing the members of your group.