 DownloadSetup for tests
Add tests for
-
Create a project
-
Create a class
-
Type in a project that "Hello, World"
-
Execute the project
-
verify that the program printed "Hello, World"
Teardown for the test
Building "features" in tests
-
Based on functionality:
-
Create a project
-
Create a class
-
Execute the project
-
Verify that the program printed "Hello, World"
-
Based on user interface:
-
Create a project from the Package Explorer
-
Rename a project from the Package Explorer
-
Import/Export a project from the Package Explorer
-
Combination of the two
-
Create a project from the Package Explorer, and also the Menu Bar
Exercises (Fix the TODOs in tests)
-
Assert project created(Look in the Package Explorer)
-
Assert class created (Open type dialog)
-
Get rid of the sleep(use wait-for-condition)
Removing duplication:
Specifications Exercise
Task
This assignment is the second step of your final project, and its result should be a formal functional specification
document. This is a team-based assignment, and will require significant effort on your side. Please allocate plenty
of time (anywhere between 5 and 8 hours). You will need at least two team meetings.
Functional specifications (specs) translate "requirements" (set of goals/desires that the clients laid out) into
detailed plans for the programmers to follow. These plans include visual specs (how each screen will look, where
the buttons/menus are, typefaces and colors etc) and interaction specs (how the program behaves when the user
clicks, drags, types a character etc.). A functional specification does not care about how the system will be
implemented; it only describes how the product will work entirely from the user's perspective. Fortunately, you got
a head start by expressing requirements as use cases. :-)
Writing the Specs
Begin by completing the 02/02 required readings (Joel on Software, Specs Part 1 through 4). Although we will not
explicitly allocate class time to discuss these readings, you need to parse the materials, and we expect to see
evidence of your having done so in your solution to the assignment (e.g., "Miss Piggy logs in and types "Kermit" in
the [...]"). The structure of your assignment solution needs to follow the WhatTimeIsIt.com specification
example.
Your specs need to be prioritized in three layers: bare-bones, target, and bells-and-whistles. If you think of the system as
a black box with inputs and outputs (as you should at this stage), the bare-bones specs are
what the system will do and act like shortly after Spring Break; the target is what the system will do and act like in
early April (e.g., "the system will do everything specified in the bare-bones version, plus ..."); and the bells version
is what the system will do and act like by the end of the semester. Please note the
layers should reflect the users' priorities, not your own!
Of course, going from the multiple sets of requirements we nailed down in the first step of our final project to a
functional specification is not trivial. You will need to analyze, unify, and organize the use cases we wrote down.
It's best to work as a team through this step, since different members of your team are familiar with different sets
of requirements. Hints: To translate your use cases into scenarios, you may start by: grouping logically-related use
cases, or forming use-case packages; by finding names of related user-goals or tasks; by organizing sets of
events-response pairs; by defining the functionality that manages groupings of similar data inputs and outputs; by
pairing together pre- and post-conditions. State relative priorities for each feature and don't forget your system
requirements. Next, you may delegate the write-up to different members of your team. However, you will need to
meet again as a team and discuss the various screens and forms.
Please submit your team's solution through the course wiki by Wed 10pm.
A few more hints for your spec assignment:
-
Hint: you've done a good chunk of your specs work when you wrote the
user requirements in the form of use cases last week. All you need to
do now is reconcile those use-cases across your team, tie any loose
ends, and prioritize the system features in the three layers we talked
about (bare-bones, target, bells and whistles).
-
Hint: the priorities are dictated by the users, not by you! Aka,
make sure you don't list in the bare-bones version the features that
you judge easiest to implement; list the ones that the users want
most.
-
Hint: copy and paste your consolidated use-cases where Joel Spolsky
asks for "scenarios". Your use-cases are close enough to narrative
form the way they are. Feel free to use Kermit instead of "student" or
"historian" if you wish.
-
Hint: Think of the system as a black
box with inputs and outputs. This is all the spec needs to specify at
this stage.
-
Hint: make sure your mocks contain nothing more than what your users
asked for, and don't sweat the exact layout too much. Make sure you
have the buttons and selection boxes the user needs in their
workflow; don't polish the interface: this is not your design
assignment. Don't add a Message Center if your user did not ask for
one.
Good luck!
The LaTeX Project Public License
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
LPPL Version 1.3c 2008-05-04
Copyright 1999 2002-2008 LaTeX3 Project Everyone is allowed to distribute verbatim copies of this
license document, but modification of it is not allowed.
PREAMBLE
The LaTeX Project Public License (LPPL) is the primary license under
which the LaTeX kernel and the base LaTeX packages are distributed.
You may use this license for any work of which you hold the copyright
and which you wish to distribute. This license may be particularly
suitable if your work is TeX-related (such as a LaTeX package), but
it is written in such a way that you can use it even if your work is
unrelated to TeX.
The section `WHETHER AND HOW TO DISTRIBUTE WORKS UNDER THIS LICENSE',
below, gives instructions, examples, and recommendations for authors
who are considering distributing their works under this license.
This license gives conditions under which a work may be distributed
and modified, as well as conditions under which modified versions of
that work may be distributed.
We, the LaTeX3 Project, believe that the conditions below give you
the freedom to make and distribute modified versions of your work
that conform with whatever technical specifications you wish while
maintaining the availability, integrity, and reliability of
that work. If you do not see how to achieve your goal while
meeting these conditions, then read the document `cfgguide.tex'
and `modguide.tex' in the base LaTeX distribution for suggestions.
DEFINITIONS
In this license document the following terms are used:
`Work' Any work being distributed under this License.
`Derived Work' Any work that under any applicable law is derived from the Work.
`Modification' Any procedure that produces a Derived Work under any applicable
law -- for example, the production of a file containing an
original file associated with the Work or a significant portion of
such a file, either verbatim or with modifications and/or
translated into another language.
`Modify' To apply any procedure that produces a Derived Work under any
applicable law.
`Distribution' Making copies of the Work available from one person to another, in
whole or in part. Distribution includes (but is not limited to)
making any electronic components of the Work accessible by
file transfer protocols such as FTP or HTTP or by shared file
systems such as Sun's Network File System (NFS).
`Compiled Work' A version of the Work that has been processed into a form where it
is directly usable on a computer system. This processing may
include using installation facilities provided by the Work,
transformations of the Work, copying of components of the Work, or
other activities. Note that modification of any installation
facilities provided by the Work constitutes modification of the Work.
`Current Maintainer' A person or persons nominated as such within the Work. If there is
no such explicit nomination then it is the `Copyright Holder' under
any applicable law.
`Base Interpreter' A program or process that is normally needed for running or
interpreting a part or the whole of the Work.
A Base Interpreter may depend on external components but these
are not considered part of the Base Interpreter provided that each
external component clearly identifies itself whenever it is used
interactively. Unless explicitly specified when applying the
license to the Work, the only applicable Base Interpreter is a
`LaTeX-Format' or in the case of files belonging to the
`LaTeX-format' a program implementing the `TeX language'.
CONDITIONS ON DISTRIBUTION AND MODIFICATION
-
Activities other than distribution and/or modification of the Work
are not covered by this license; they are outside its scope. In
particular, the act of running the Work is not restricted and no
requirements are made concerning any offers of support for the Work.
-
You may distribute a complete, unmodified copy of the Work as you
received it. Distribution of only part of the Work is considered
modification of the Work, and no right to distribute such a Derived
Work may be assumed under the terms of this clause.
-
You may distribute a Compiled Work that has been generated from a
complete, unmodified copy of the Work as distributed under Clause 2
above, as long as that Compiled Work is distributed in such a way that
the recipients may install the Compiled Work on their system exactly
as it would have been installed if they generated a Compiled Work
directly from the Work.
-
If you are the Current Maintainer of the Work, you may, without
restriction, modify the Work, thus creating a Derived Work. You may
also distribute the Derived Work without restriction, including
Compiled Works generated from the Derived Work. Derived Works
distributed in this manner by the Current Maintainer are considered to
be updated versions of the Work.
-
If you are not the Current Maintainer of the Work, you may modify
your copy of the Work, thus creating a Derived Work based on the Work,
and compile this Derived Work, thus creating a Compiled Work based on
the Derived Work.
-
If you are not the Current Maintainer of the Work, you may
distribute a Derived Work provided the following conditions are met
for every component of the Work unless that component clearly states
in the copyright notice that it is exempt from that condition. Only
the Current Maintainer is allowed to add such statements of exemption
to a component of the Work.
a. If a component of this Derived Work can be a direct replacement
for a component of the Work when that component is used with the
Base Interpreter, then, wherever this component of the Work
identifies itself to the user when used interactively with that
Base Interpreter, the replacement component of this Derived Work
clearly and unambiguously identifies itself as a modified version
of this component to the user when used interactively with that
Base Interpreter.
b. Every component of the Derived Work contains prominent notices
detailing the nature of the changes to that component, or a
prominent reference to another file that is distributed as part
of the Derived Work and that contains a complete and accurate log
of the changes.
c. No information in the Derived Work implies that any persons,
including (but not limited to) the authors of the original version
of the Work, provide any support, including (but not limited to)
the reporting and handling of errors, to recipients of the
Derived Work unless those persons have stated explicitly that
they do provide such support for the Derived Work.
d. You distribute at least one of the following with the Derived Work:
1. A complete, unmodified copy of the Work;
if your distribution of a modified component is made by
offering access to copy the modified component from a
designated place, then offering equivalent access to copy
the Work from the same or some similar place meets this
condition, even though third parties are not compelled to
copy the Work along with the modified component;
2. Information that is sufficient to obtain a complete,
unmodified copy of the Work.
-
If you are not the Current Maintainer of the Work, you may
distribute a Compiled Work generated from a Derived Work, as long as
the Derived Work is distributed to all recipients of the Compiled
Work, and as long as the conditions of Clause 6, above, are met with
regard to the Derived Work.
-
The conditions above are not intended to prohibit, and hence do not
apply to, the modification, by any method, of any component so that it
becomes identical to an updated version of that component of the Work as
it is distributed by the Current Maintainer under Clause 4, above.
-
Distribution of the Work or any Derived Work in an alternative
format, where the Work or that Derived Work (in whole or in part) is
then produced by applying some process to that format, does not relax or
nullify any sections of this license as they pertain to the results of
applying that process.
-
a. A Derived Work may be distributed under a different license
provided that license itself honors the conditions listed in
Clause 6 above, in regard to the Work, though it does not have
to honor the rest of the conditions in this license.
b. If a Derived Work is distributed under a different license, that
Derived Work must provide sufficient documentation as part of
itself to allow each recipient of that Derived Work to honor the
restrictions in Clause 6 above, concerning changes from the Work.
-
This license places no restrictions on works that are unrelated to
the Work, nor does this license place any restrictions on aggregating
such works with the Work by any means.
-
Nothing in this license is intended to, or may be used to, prevent
complete compliance by all parties with all applicable laws.
NO WARRANTY
There is no warranty for the Work. Except when otherwise stated in
writing, the Copyright Holder provides the Work `as is', without
warranty of any kind, either expressed or implied, including, but not
limited to, the implied warranties of merchantability and fitness for a
particular purpose. The entire risk as to the quality and performance
of the Work is with you. Should the Work prove defective, you assume
the cost of all necessary servicing, repair, or correction.
In no event unless required by applicable law or agreed to in writing
will The Copyright Holder, or any author named in the components of the
Work, or any other party who may distribute and/or modify the Work as
permitted above, be liable to you for damages, including any general,
special, incidental or consequential damages arising out of any use of
the Work or out of inability to use the Work (including, but not limited
to, loss of data, data being rendered inaccurate, or losses sustained by
anyone as a result of any failure of the Work to operate with any other
programs), even if the Copyright Holder or said author or said other
party has been advised of the possibility of such damages.
MAINTENANCE OF THE WORK
The Work has the status `author-maintained' if the Copyright Holder
explicitly and prominently states near the primary copyright notice in
the Work that the Work can only be maintained by the Copyright Holder
or simply that it is `author-maintained'.
The Work has the status `maintained' if there is a Current Maintainer
who has indicated in the Work that they are willing to receive error
reports for the Work (for example, by supplying a valid e-mail
address). It is not required for the Current Maintainer to acknowledge
or act upon these error reports.
The Work changes from status maintained' tounmaintained' if there
is no Current Maintainer, or the person stated to be Current
Maintainer of the work cannot be reached through the indicated means
of communication for a period of six months, and there are no other
significant signs of active maintenance.
You can become the Current Maintainer of the Work by agreement with
any existing Current Maintainer to take over this role.
If the Work is unmaintained, you can become the Current Maintainer of
the Work through the following steps:
1. Make a reasonable attempt to trace the Current Maintainer (and the Copyright Holder, if the two differ) through the means of
an Internet or similar search.
2. If this search is successful, then enquire whether the Work is still maintained.
a. If it is being maintained, then ask the Current Maintainer to update their communication data within one month.
b. If the search is unsuccessful or no action to resume active maintenance is taken by the Current Maintainer, then announce
within the pertinent community your intention to take over
maintenance. (If the Work is a LaTeX work, this could be
done, for example, by posting to comp.text.tex.)
3a. If the Current Maintainer is reachable and agrees to pass maintenance of the Work to you, then this takes effect
immediately upon announcement.
b. If the Current Maintainer is not reachable and the Copyright Holder agrees that maintenance of the Work be passed to you,
then this takes effect immediately upon announcement.
4. If you make an `intention announcement' as described in 2b. above and after three months your intention is challenged neither by
the Current Maintainer nor by the Copyright Holder nor by other
people, then you may arrange for the Work to be changed so as
to name you as the (new) Current Maintainer.
5. If the previously unreachable Current Maintainer becomes reachable once more within three months of a change completed
under the terms of 3b) or 4), then that Current Maintainer must
become or remain the Current Maintainer upon request provided
they then update their communication data within one month.
A change in the Current Maintainer does not, of itself, alter the fact
that the Work is distributed under the LPPL license.
If you become the Current Maintainer of the Work, you should
immediately provide, within the Work, a prominent and unambiguous
statement of your status as Current Maintainer. You should also
announce your new status to the same pertinent community as
in 2b) above.
WHETHER AND HOW TO DISTRIBUTE WORKS UNDER THIS LICENSE
This section contains important instructions, examples, and
recommendations for authors who are considering distributing their
works under this license. These authors are addressed as `you' in
this section.
Choosing This License or Another License
If for any part of your work you want or need to use distribution
conditions that differ significantly from those in this license, then
do not refer to this license anywhere in your work but, instead,
distribute your work under a different license. You may use the text
of this license as a model for your own license, but your license
should not refer to the LPPL or otherwise give the impression that
your work is distributed under the LPPL.
The document `modguide.tex' in the base LaTeX distribution explains
the motivation behind the conditions of this license. It explains,
for example, why distributing LaTeX under the GNU General Public
License (GPL) was considered inappropriate. Even if your work is
unrelated to LaTeX, the discussion in `modguide.tex' may still be
relevant, and authors intending to distribute their works under any
license are encouraged to read it.
A Recommendation on Modification Without Distribution
It is wise never to modify a component of the Work, even for your own
personal use, without also meeting the above conditions for
distributing the modified component. While you might intend that such
modifications will never be distributed, often this will happen by
accident -- you may forget that you have modified that component; or
it may not occur to you when allowing others to access the modified
version that you are thus distributing it and violating the conditions
of this license in ways that could have legal implications and, worse,
cause problems for the community. It is therefore usually in your
best interest to keep your copy of the Work identical with the public
one. Many works provide ways to control the behavior of that work
without altering any of its licensed components.
How to Use This License
To use this license, place in each of the components of your work both
an explicit copyright notice including your name and the year the work
was authored and/or last substantially modified. Include also a
statement that the distribution and/or modification of that
component is constrained by the conditions in this license.
Here is an example of such a notice and statement:
%% pig.dtx
%% Copyright 2005 M. Y. Name
%
% This work may be distributed and/or modified under the
% conditions of the LaTeX Project Public License, either version 1.3
% of this license or (at your option) any later version.
% The latest version of this license is in
% http://www.latex-project.org/lppl.txt
% and version 1.3 or later is part of all distributions of LaTeX
% version 2005/12/01 or later.
%
% This work has the LPPL maintenance status `maintained'.
%
% The Current Maintainer of this work is M. Y. Name.
%
% This work consists of the files pig.dtx and pig.ins
% and the derived file pig.sty.
Given such a notice and statement in a file, the conditions
given in this license document would apply, with the `Work' referring
to the three files pig.dtx',pig.ins', and `pig.sty' (the last being
generated from pig.dtx' usingpig.ins'), the `Base Interpreter'
referring to any LaTeX-Format', and bothCopyright Holder' and
Current Maintainer' referring to the personM. Y. Name'.
If you do not want the Maintenance section of LPPL to apply to your
Work, change maintained' above intoauthor-maintained'.
However, we recommend that you use `maintained', as the Maintenance
section was added in order to ensure that your Work remains useful to
the community even when you can no longer maintain and support it
yourself.
Derived Works That Are Not Replacements
Several clauses of the LPPL specify means to provide reliability and
stability for the user community. They therefore concern themselves
with the case that a Derived Work is intended to be used as a
(compatible or incompatible) replacement of the original Work. If
this is not the case (e.g., if a few lines of code are reused for a
completely different task), then clauses 6b and 6d shall not apply.
Important Recommendations
Defining What Constitutes the Work
The LPPL requires that distributions of the Work contain all the
files of the Work. It is therefore important that you provide a
way for the licensee to determine which files constitute the Work.
This could, for example, be achieved by explicitly listing all the
files of the Work near the copyright notice of each file or by
using a line such as:
% This work consists of all files listed in manifest.txt.
in that place. In the absence of an unequivocal list it might be
impossible for the licensee to determine what is considered by you
to comprise the Work and, in such a case, the licensee would be
entitled to make reasonable conjectures as to which files comprise
the Work.
PROJECT TITLE : Date Estimation in Lineage-Linked Databases
NAME : Vegard Brox
SUPERVISOR : Brian Randell
SECOND SUPERVISOR : Nick Rossiter
ABSTRACT : The aim of this project is to produce a system, which scan a lineage-linked
database in order to provide estimated years for undated events. Such
databases are used by genealogists for holding family trees and associated
information. The system to be produced should first traverse the database,
inserting the year range 0000/9999 in all blank year fields. It should then
repeatedly traverse the database, applying appropriate logical and
heuristic constraints in order to narrow the year ranges, so as to make all
the year ranges in the database consistent with each other, or report
errors if it is not possible to make the year ranges consistent.
AIMS : - Explore how mathemathical relaxation can be used to estimate dates in
lineage linked databases.
- Analyze how best to process lineage-linked databases.
- Get a better understanding of the software development process.
- Get more experience in doing a project.
OBJECTIVES :
- Determine reasonable heuristics for estimating dates in a lineage linked
database.
- Determine internal representation of the database.
- Develop a program which performs the estimation.
- Make the program easy to use.
- Report errors and inconsistencies in the original database to the user.
- Test how well the program is able to oprate on real-life databases.
- Make the program freely available through a web-page that explains what
the program does.
DELIVERABLES :
The main deliverable from the project is the dissertation, which describes
the development process. But the project should also resiult in a
well-tested, robust program with a graphical user interface which can be
used for estimating dates in lineage-linked databases. A webpage that
explains what the program does and offers it for download should also be
made, as the idea is to make the program freely available.
FOCUS :
Problem analysis: 20%
Design: 20%
Implementation: 20%
Testing: 20%
Analysis of result: 20%
BACKGROUND SKILLS :
- Software development skills, including analysis, design and programming
skills (not necessarily for a specific tool or language).
- Project skills, including project planning and time managment.
SKILLS TO BE ACQUIRED :
- Understanding of the GEDCOM standard which is used to define the lineage-
linked databases.
- Knowledge of the chosen programming language.
- Understanding and use of the chosen tools for design, programming and
project planning.
- General knowledge of mathemathics, including mathemathical relaxation.
- Experience and produce a robust and non-trivial program.
REFERENCES :
- D. Hawgood: GEDCOM Data Transfer (3rd edition), Cardon 1999.
A book explaining the GEDCOM protocol.
- Edith Chipo Lwanda: Date-estimation in Genealogical Databases.
MSc project done on a related topic at University of Newcastle in 1992.
RESOURCES :
The only hardware needed should be a normal PC. Of software, it is not
possible to give a list until tools to use have been chosen.
SPECIFICATION :
The aim of this project is to produce a system, which scan a lineage-linked
database in order to provide estimated years for undated events. (Such
databases are used by genealogists for holding family trees and associated
information, though these "trees" are more accurately described as acyclic
directed graphs.) The database will be given as a GEDCOM file - this is a
documented standard ASCII representation used for exporting and importing
such databases.
The program to be produced should first build and traverse an internal
representation of the GEDCOM file, inserting the year range 0000/9999 in
all blank year fields. It should then repeatedly traverse the internal
representation, applying appropriate logical and heuristic constraints in
order to narrow the year ranges, so as to make all the years and year
ranges in the file consistent with each other. An example of a logical
constraint is that person's death cannot his/her marriage. The heuristic
constraints are perhaps less obvious, but can include that people do not
live for more than 110 years or have children before they are 10 years
old etc. The numbers to be used by the heuristic constraints should be
options the user can change the value of, but they should have reasonable
default values.
The program will aim to perform such traversals until a complete traversal
is made during which no year range is further narrowed. (In effect, it will
have performed a simple "mathematical relaxation" process.) However, due to
errors in the original data in the file, the program might find it
impossible to determine a consistent set of year intervals - something
which comes apparent when a year range becomes negative, so to speak. It
will have to be decided what the program should do when it encounters an
error - whether it can continue the estimation at all, and if so, which
data can still be used.
The program is to be written for a PC or a Macintosh, have a good quality
user interface, and be validated using the numerous GEDCOM files that are
readily available. The requirement is to produce a fully operational and
well-documented system, worthy of being used in anger by a genealogist.
The project can be split up in some main stages - initial stage, design,
programming, experimentation, report writing, and final stage. A brief
description of what each of these stages should include is given below. The
development process will be based on the spiral model for software
development.
Initial stage:
One task will be to perform research and background reading into necessary
standards and technologies, e.g. the GEDCOM standard. Which logical and
heuristic constraints to use will have to be decided at this stage, and
reasonable default values for the heuristic constraints should be set. It
should also be decided quite early which platform and programming
language/environment to use, and if necessary gain more knowledge about
this. Finally, a detailed project plan for the (rest of the) project should
be made sometime during the initial stage.
Design:
A design methodology should be chosen, and a detailed design of the
resulting application should be carried out. As the task for the program
has not been well-explored earlier, it would be an advantage to start the
implementation and testing quite early in order to discover unexpected
problems. Before any implementation starts it will be a design phase
focusing mostly on the basics of the program. After an initial version has
been implemented, a new phase will allow for re-design caused by
discovered problems (if any), and more detailed design of the remaining
parts of the program.
Implementation and testing:
The program will have to be implemented using the selected language and
environment. A help system should also be made for the program to explain
the basic operation of the program and help users with usual problems. This
stage also includes testing to ensure that the program works as expected.
This testing can be carried out on both constructed and real-life data.
Experimentation:
The aim in this stage will be to determine how well the program performs on
real data, i.e. how much it manages to narrow down the year intervals given
a number of real databases. It should also be investigated how often errors
occur and perhaps what caused the errors.
Documentation:
The project is supposed to result in a (roughly) 50-page dissertation, and
the main task at this stage will be to determine what to include in the
dissertation, and to write it. Also, things like user manual and
maintenance manual will have to be written.
Final stage:
The idea is to make the finished program available for free use by
genealogists, and one of the tasks in the final stage could be to make a
webpage presenting the program and allowing people to download it.
The main milestones for the project will be at the end of each stage,
although it will be natural to do some of the tasks in parallel. The
provisional dates for the milestones are:
- Initial stage finished: 8/10 1999
- Initial design finished: 29/10 1999
- Initial implementation finished: 26/11 1999
- Final design finished: 17/12 1999
- Implementation and testing finished: 25/2 2000
- Experimentation finished: 31/3 2000
- Documenatation finished: 5/5 2000
- Final stage finished: 5/5 2000
|
