YACSA

(Yet Another Contest Scoring Application)

This is the specification for the Fall 2009 semester project for CISC475. The project involves the design and development of a scoring application for RC sailplane contests.

Most of these requirements were harvested from a thread on RCGroups, and, in particular, from a post by Brad Willoughby in that thread.

This application was chosen for a semester project because:

It is complicated enough to exercise the team's engineering skills.
It is not too complicated to finish within one semester.
A community of interested, tech-savvy users is available to review the application.

Some of the features described in this document (e.g., audio announcements) may not be part of the original implementation. However, the application must be designed to permit them to be added at a later time without major restructuring.

Comments, suggestions, criticisms, and additional content can be mailed to Walt Leipold or posted on RCGroups.

Contents of this document:

Vision
Glossary
Use Cases
Supplementary spec

Vision

YACSA (Yet Another Contest Scoring Application) provides end-to-end support for managing and scoring hand-launch (F3K) and thermal duration (TD) model sailplane contests. With minor enhancements, it should also support F3J (thermal duration) and F3B (multi-task) contests.

Advantages

Easy installation -- the application can be installed by dragging a single file onto a computer.
Cross-platform application, running on Windows, MacOS, and Linux. May be possible to run on a smartphone or PDA.
Easy to learn and use, with a clean, intuitive interface.
Less potential for error than the Excel spreadsheets used in many contests.
Well-written online help.
Open source application; can be maintained and enhanced by the RC community.

Features

Registration support

Register pilots (including name, class, frequencies, AMA/FAI number, e-mail for results, etc).
Support a number of customizable per-pilot data fields (lunch donation paid, parking fee, etc.).
Import pilot list for event from, e.g., ESL Web site.
Generate pilot time cards for every round and flight group.
Generate personalized name tags showing pilot name and flight groups for each round.
Flexible and customizable flight group generation, with sensible default options.
Capture audio recording of each pilot's name for playback during round announcements.

Event support

Support multiple events in a single database.
Support multiple 'contests' (e.g., Friday, Saturday, Sunday) in an event. A flyoff can be treated as a separate 'contest' at the end of the event.
Allow CD to create and populate the flyoff by simply stating the number of top pilots from each class to include -- no additional data entry should be required.
Allow contest organizers to include event-specific graphics in printouts, name cards, time cards, etc (i.e., club or event logo).
Streamline data entry during the event (select pilot name or number and app will prompt for the required times).
Use pilot number or even a bar code to quickly bring up data entry screen.
Simplified data entry should require no training or practice; easy enough to be done by timers, volunteers, etc.
Live display of leaderboard and graphical scoring statistics.
Live display of current round, flight group, and window time.
Support multiple monitors for full-screen live displays. (Alternatively, an integral Web server can provide 'leaderboard' and other Web pages with auto-refresh.)
Able to include non-standard tasks.
Automatically generate heat/round/contest audio timing files (MP3, wave, etc).
Audio announcements of pilots by name via pre-recorded audio files or text-to-speech.

Scoring

Include all current F3K and F3B tasks and allow the creation of a contest with any number of tasks, throwouts, pilots, etc.
Heat/round/contest/event can be marked 'locked' to prevent inadvertant data entry.
Provide attractive printouts of scoring for each contest and overall summary of the entire event. (Rules for combining contests into an overall score may vary.)
Generate printed score sheets and/or Web-based 'leaderboard' after each round is complete.
Report missing scores, "over-perfect" scores (ie a perfect 5x2 task), or other data-entry possible errors.
Allow data entry from multiple clients simultaneously (to allow multiple score-entering terminals during a contest).
Allow data entry from remote clients (wireless, iPhone, web-based, etc). This feature will only be implemented if reasonable security can be provided.

Data handling

Pilot performance and rankings can be tracked across multiple contests to allow year-end results and rankings.
The scoring database is stored in a single file which can be copied, renamed, and reopened.
Results can be copied (via the 'clipboard') and pasted into a spreadsheet program.
Results can be exported in CSV format for ad hoc analysis.
Data for one or more contests can be imported into another instance of the program, allowing results from multiple contests to be aggregated for season totals.
Results can be easily shared via printouts, web posts to RC Groups, e-mail to registered pilots, etc.

Other features

The application will be open source and maintained in a single authoritative location (SourceForge, Google code, etc).
The application will be easily extendable with new flight tasks as the F3K rules evolve or to allow non-F3K tasks at the CD's discretion.
The application will be localizable into various languages/cultures. This may include changing things like "AMA number" into their local equivalents.

Glossary

CD: (Contest Director) The person responsible for running a contest. In the US, AMA-sanctioned events must be run by an AMA-approved CD.
class: The pilots in a contest are typically partitioned into classes (e.g., "expert", "sportsman", and "novice"). Scoring reports may rank pilots within classes.
contest: A part of an event, consisting of a number of rounds that are scored as a unit. The simplest example is a weekend event with separate contests for Saturday and Sunday.
event: One or more contests conducted together.
FAI: (Federation Aeronantique Internationale) FAI is the world governing body for air sports and aeronautical world records.
F3B: FAI class for multi-task (duration, distance, and speed) glider competition
F3K: FAI class for hand-launched glider competition
flight group: A group of pilots that flies a single round together. More pilots attend a contest than can fly simultaneously. Within each round, pilots are apportioned into a number of flight groups. Flight groups are randomized for each round to ensure that each pilot has a chance to compete against all other pilots.
flyoff: A 'mini-contest', consisting of from three to six rounds, flown by the highest-scoring pilots in one or more other contests.
heat: (synonym group) One flight group within one round. Heats are typically referenced by letter ("A", "B", etc.) to distinguish them from rounds, which are numbered.
landing points: In thermal duration tasks, points are awarded based on landing distance from a target.
leaderboard: A display of current scores. At a minimum, shows the most recent round and the current contest's overall scores.
man-on-man scoring: ("normalized" scoring) Within each heat, scores are normalized so that the highest-scoring pilot receives 1000 points. This compensates for varying weather conditions in different heats.
matrix: A table showing which pilots fly in each heat within each round.
pilot: (synonyms contestant, competitor) Someone competing in a contest.
pilot sheet: (synonym dance card) A matrix of pilot names and rounds, specifying which heat each pilot will fly in each round. A pilot sheet is handed out to each pilot at the start of each contest.
round: A contest is organized into rounds. Every round involves a particular flight task. Every pilot flies once in each round. Rounds are numbered starting at "1" within each contest of an event.
scorekeeper: (synonym user) Person using the application to register pilots, record times, and generate scores.
task: A unit of work to be accomplished by each pilot in a round. F3K and F3B rules define a number of different tasks. Tasks are referred to either by their letter designation or by name (e.g., F3K task "E" is the "All up, last down" task).
thermal duration (TD): A simplified contest format, in which pilots fly only the 'duration' F3B task.

Supplementary Spec

The Supplementary Specification captures all requirements not stated in the Use Cases.

Domain rules

Flight tasks and constraints: The 'official' F3K rules are promulgated by Federation Aeronantique Internationale (FAI). See pages 23 et seq of this document for details.

Frequency identification: The application must be able to store at least two flight frequencies (primary and backup) for each pilot, and use these frequencies when generating flight groups. The application may incorporate a reference table of frequencies to identify data-entry errors, and provide a pull-down list or other mechanism to simplify data entry. One or more 'special' frequency names (e.g., "2.4GHz") may be used to denote conflict-free frequencies which will be treated specially during flight group generation.

Scoring

Pilot participation: A pilot may register for an entire event or for only a subset of the contests in an event. The registration system must allow the scorekeeper to specify the contests in which each pilot will fly.

Class: A pilot may only fly in a single class (e.g., "sportsman") during an event. The number and names of the various classes can be configured when an event is created. The default classes will be 'expert', 'sportsman', and 'novice'.

Time input: The time for each flight can be entered either as a whole numbers of seconds, or as minutes and seconds separated by a period or colon. For example, '90', '1.30', and '1:30' all mean the same thing. (Note: When internationalized, the application may support alternate time notations.) For threshold tasks such as the F3K 15-second ladder task, the application may provide check boxes rather than text fields to allow the scorekeeper to denote which fixed times were achieve.

Dropped rounds: When computing scores for a contest, the application will drop some number of each pilot's lowest rounds. F3K rules require one dropped round after five rounds, another after nine rounds, and a third after fourteen. The application will default to the F3K rule, but will allow the CD and scorekeeper to specify an alternate strategy. See this post for a discussion and suggestion.

Penalty points: As specified in the F3K rules, a 100-point penalty is assessed if a model in flight contacts anyone except the pilot or his helper. The penalty is in points, not seconds, and is subtracted from the contestant's total score for the contest. The application must allow the scorekeeper to enter penalty points for a pilot. Each penalty should be associated with the heat in which it occurred. To aid a later review of the scores, the application should allow the scorekeeper to enter a text comment for each penalty.

Contest scoring: A pilot's score for a contest is the sum of his normalized scores for each non-dropped round, minus any penalty points accrued.

Task scoring: A pilot's score for a single heat may contain many fields. For example, a TD score contains both flight time and landing points, and an F3K 'All up last down' score contains between three and five flight times.

Round scoring: A pilot's total score for a round is usually simply his normalized score for his heat, which will be between zero and 1000. In a TD contest, the scorekeeper may choose to have landing points added after normalization. In this case, a pilot's score for a round can exceed 1000 points.

Task configuration: The scorekeeper should be able to configure the parameters of a task. For example, in an F3K "All up last down" round, the scorekeeper should be able to change the number of flights (between three and five, default three) and the max time per flight (default 180 seconds). For a "Five longest flights" task, he should be able to specify both the working time (default 600 seconds) and maximum flight length (default 120 seconds). These values should become associated with the round so they will be unaffected by future changes to the default values.

Locked flag: A heat, round, contest, or event can be marked with a 'locked' flag. When this flag is set, the application will not allow data entry or any changes to the configuration of the heat (round, contest, event). Setting the locked flag for a round automatically locks all of its heats, and similarly for contests and events. The locked flag can be temporarily cleared by the scorekeeper when necessary to correct a scoring or data-entry error.

Custom flight tasks: The application design must make it possible to add new flight tasks without recompilation of the entire application. Each flight task, including each predefined F3K and TD flight task, should be a subclass of a single base class. To add a new flight task to the application, it should only necessary to place its .class file in the application's .jar file, or somewhere on the classpath, and (if necessary) add its fully-qualified classname to a configuration file. Interaction of such dynamically loaded flight tasks with application-wide options (for example, in a TD contest, should landing points be added before or after scores are normalized?) is left as an exercise for the student.

Multi-event scoring: The application need not provide reporting or other functions to aggregate results for multiple events. Such scoring is likely to vary widely between organizations. However, the application may be designed to allow drop-in extension modules for a particular organization. As an example of multi-event functionality, this post describes the complex procedure used in the Eastern Soaring League to compute season standings.

Flight groups

To support man-on-man scoring, the application must be able to generate a set of flight groups (a 'matrix') which is randomized but which obeys a number of constraints, including:

Ensure no frequency conflicts within groups.
Avoid frequency conflicts in adjacent flight groups, allowing the scorekeeper to specify the number of heats by which frequencies should be separated. (For example, in a TD contest, it is possible for up to three flight groups to be in the air at once.)
Optionally avoid "back-to-back" groups for pilots. For example, a pilot who flies the last heat of round 'n' should not be scheduled for the first heat of round 'n+1'.
Mix up group assignments by comparing each flight group to all other flight groups. A 'good' matrix is one in which each pilot is matched the same number of times against every other pilot.
Ensure that pilots using 2.4GHz radios are not lumped together unfairly (see this link for details).
Try both primary and secondary frequencies when generating flight groups, but give preference to primary frequency.
Do not require a pilot to change frequencies during a contest.

The application must alert the scorekeeper when it cannot generate a set of flight groups which satisfies all selected constraints.

Different sets of constraints (e.g., number of back-to-back rounds to avoid) can be selected by the scorekeeper. The constraints used to generate a flight order will be stored as part of the contest's scoring, so they can be reapplied when scores must be recomputed (e.g., after a scoring error is corrected). Default constraints can be configured by the scorekeeper and will be stored with other local preferences.

The application must permit manual adjustment of flight groups; i.e., it must allow the scorekeeper to move a pilot from one heat to another within a round (for example, to accomodate a late registration or withdrawal, or if a pilot has missed his heat). The application must warn the scorekeeper, and require explicit confirmation, if moving a pilot results in a frequency conflict or any other violation of the flight group generation constraints.

User interface

The application will have a graphical user interface and must follow standard UI guidelines for Java and for the operating system.

The typical user will use this application only once or twice per year. He can be assumed to know a great deal about sailplane contests, but nothing at all about the application. Therefore, the application should provide easily-discovered toolbar buttons, menu items, or "wizards" which will walk the user through common scorekeeping tasks. For example, the "create an event" wizard might consist of a series of dialog boxes with explanatory text.

The user interface must permit cut-and-paste text editing.

The user interface should include an "Undo" capability. At a minimum, the user interface should allow the user to undo a single field edit. A more general multi-level undo capability, while not required, is desirable.

The application must warn the user if he attempts to exit the application and any unsaved changes have been made to application data.

When tabular data is presented, the application should allow the data to be sorted by any column.

The application must remember the last filesystem directory accessed and default to that directory for "open" and "save" operations.

Dates should be displayed in ISO format (yyyy-mm-dd). Day names (e.g., "Saturday") should be displayed using the system's regional settings.

Display size: The application's window(s) must fit on a WVGA (800x480) screen without loss of information or function. (For example, it would be a Bad Thing to display a dialog box whose "OK" button was more than 480 pixels below the top of the window, or to have an application toolbar wider than 800 pixels.) The interface should allow the user to scroll to see information that does not fit on the screen, but should be designed to minimize the amount of scrolling necessary.

Printed output

Pilot sheets: A pilot sheet must display the event name, contest name, and a table mapping pilots to heats. The table will have rows labelled with pilots' names and columns labelled with round numbers. Each cell of the table will show the heat ("A", "B", etc.) to be flown by a pilot in a round. The application should print as many pilot sheets as possible per printed page, but leave enough whitespace at the top of each sheet to allow it to be pinned to a clipboard without obscuring information.

The pilot sheet must display the frequency each pilot will by using, and must make it clear when a pilot is using an alternate frequency. Here is a sample pilot sheet, with one pilot's frequency highlighted to show that it is his alternate:

Runtime requirements

The application can assume that the Java 1.6 runtime is installed, but may not require the installation of any other software. The application must be contained in a single JAR file. It must run on MacOS, Linux, and Windows.

Hardware requirements

The basic application must run acceptably on low-end generic PC hardware. The benchmark low-end hardware to be used for testing is an Asus EEE PC model 701 running Ubuntu Linux.

Import/export functions

[CSV export, pilot list import]

[automated AMA number verification?]

Rather than defining an export file format, the database import and export functions may be implemented by having the application open a second 'database' file and copy the necessary data into its main database.

Unique pilot ID: When importing data, the application must be able to match up pilot records from different contests. In the US, the application may use AMA number to match pilot records between databases. A different 'pilot number' may be used in other jurisdictions. (For example, in the UK, it may be possible to use a BMFA number instead.)

Data and file requirements

Events, contests, and so forth are organized into a strict hierarchy of containment.

Event (e.g., "SKSS Fall Fling")
Contest (e.g., "Saturday" or "Flyoff")
Round (e.g., "Round 3")
Heat (e.g., "Heat C")

Pilot data should not be 'owned' by any single event. However, some pilot data may be event-specific -- for example, a pilot may choose to fly in a different class in one event.

The application may not modify its data file except upon explicit scorekeeper action via a "Save" or "Save as..." command.

The default filename extension for data files will be ".f3k". However, it must allow reading and writing other filename extensions.

The application will provide an 'Open...' command for opening an existing scoring file, a 'New' command for creating a new scoring file, and 'Save' and 'Save as...' commands for saving current scoring information to a scoring file.

External storage format

The application must be able to save all registration and scoring data in a single disk file. The scoring file must be able to store data for an arbitrary number of events. The development team may choose to introduce a 'Season' class to encapsulate all Pilot and Event objects in a single object graph.

The disk storage format is unspecified; it may be serialized Java objects, XML data serialized via XStream, a relational database, or some other mechanism. Human-readable formats such as XML, while having obvious advantages for debugging, are not necessarily preferred.

Application data may be stored in a relational database. If so, an embedded database such as HSQLdb will be supplied and configured as the default, so the user does not have to install any other software on his computer. The application should allow the scorekeeper to configure the JDBC URL and connection string to connect to an external database server (mySQL, PostgreSQL, etc.).

If the application supports an SQL database, it must use an object-relational mapping layer (Hibernate) to decouple the object representations of domain classes (e.g., 'Pilot', 'Round') from their underlying database representation.

Startup and configuration

The application will store local configuration information using the standard Java 'preferences' API. If the application persistence mechanism requires a database, the configuration will include database connection information. When first run after installation, the application must prompt the user to either create a new database or connect to an existing database.

The application will provide an interface that will enable the user to change its configuration, including connecting to a different database or creating a new database.

External hardware and software

Some optional features of the application may use external hardware; for example, an LED marquee may be used to display the current round, heat, and task. Such a feature would require additional interface code to communicate with the marquee, and might require a PC with special interface hardware (e.g., a serial or parallel port).

The application must be designed so that new interface classes for optional hardware features can simply be added to the .jar file and their features (including configuration dialogs) will automatically be available to the scorekeeper. The design should follow MVC (Model-View-Controller) principles to standarize and simplify communication betwen the core application and the extension classes.

Some extension classes may be OS-specific. The class structure or naming convention for extension classes must ensure that only classes appropriate for the current OS will be loaded.

Implementation language

The application will be implemented in Java. Java is the current best choice to meet the requirement for cross-platform operation, and the Java ecosystem provides high-quality free libraries for many of the functions this application will need. Some libraries which may be used are:

HSQLdb, the HypersonicSQL embedded relational database engine
Hibernate object-relational persistence engine
Jetty embedded Web server
Jasper Reports reporting engine
iReport visual reporting tool
XStream XML object serializer

Project management

The application will be developed as a semester-long team project for between five and seven students. If, in the opinion of the instructor, the application works properly, it will be released as open source software at the end of the semester.

However, while the application is a student project, it is not intended to be throwaway code. If successful, it will be maintained and enhanced by other programmers for years, so maintainability is one of the primary goals of the implementation.

The overall architecture of the application must be documented.
Source code must be supportable, maintainable, and comprehensible.
Third-party libraries will not be used except when absolutely necessary.
Code should be well documented, but not over-documented; a maintenance programmer should not have to wade through oceans of irrelevant machine-generated documentation to find a nugget of information.
Code will be modularized into Java packages.
All source code will be formatted according to the project coding conventions.
All project packages will be subpackages of com.bozoid.yacsa.

Use Cases

Use Case CONTEST01: Create new event

The scorekeeper enters the name of the new event along with its date, description, pilot classes, and other information. The system creates and records the new event.

If the application supports multiple types of event (F3K, F3B, etc), the scorekeeper must specify the event type when creating the event.

Use Case CONTEST02: Import pilot list

The application reads a pilot list created in another application (most likely a CSV file). It may require the scorekeeper to specify the columns to be imported.

Use Case CONTEST03: Manage pilot data

The scorekeeper can enter pilots into the application, and edit each pilot's data. Required fields should include name, AMA number (or local national equivalent), class (expert, sportsman, etc), and primary and secondary frequencies. A new pilot entered into the application should be automatically associated with the current event, if there is one. [Future enhancement: The system should support additional fields, including any CD-defined custom fields needed to support the contest. Such fields should be stored along with a particular event.]

To add a pilot to the current event, the application should allow the scorekeeper to choose from a list of all known pilots (presumably created for previous events in the season).

The scorekeeper may drop a pilot from an event. If any scores have been entered for that pilot, the program will request confirmation before deleting those scores. Dropping a pilot from a event should not erase the pilot from the application.

The scorekeeper may specify the contests within each event in which each pilot will compete.

If the scorekeeper removes a pilot from a contest's scoring, and the pilot has scores for that contest, the application will ask for confirmation. Upon confirmation, the application will erase any scores that have been entered for that pilot in that contest.
If the scorekeeper adds a pilot to a contest, the pilot will be given zero scores for all rounds which have been completed or locked.

If the scorekeeper changes a pilot's class after scores have been entered, the system should recompute any total scores automatically.

In a future enhancement, the application will allow the scorekeeper to make an audio recording of each pilot's name. This will be used by the application when it generates audio files, including round/heat announcements, for a contest.

Use Case CONTEST04: Add contest to event

The scorekeeper chooses an event, then enters the name of the contest (for example, "Saturday") to be added to the event. The system creates and records the necessary data structures.

When a second or subsequent contest is added to a contest, all pilots registered for any previous contest will be automatically added to that contest's scoring list.

The system will allow a contest to be removed from an event. If scores have been entered for that contest, the scorekeeper will be asked to confirm the deletion.

Use Case CONTEST05: Manage rounds and tasks

The scorekeeper chooses a contest, sets the number of rounds to be flown, and then specifies the task, working time, number of flights, and so forth for each round. All F3K tasks and common working times (7, 8, and 10 minutes) should be available for easy selection.

If the application supports multiple types of events, the available tasks must be limited to tasks appropriate for the current event type.

The scorekeeper may add one or more rounds to a contest. If flight groups have already been generated for that contest, the application will prompt the scorekeeper to generate flight groups for the new round(s). The scorekeeper may choose to generate new flight groups for all rounds instead.

The system will allow the scorekeeper to change the task for a round. If scores have been entered for that round, the scorekeeper may not change the task.

The system will allow the scorekeeper to delete a round entirely. If no scores have been entered, the total number of rounds will be decremented and the tasks for subsequent rounds simply shuffled up into its place. However, to ensure that pilot sheets need not be reprinted, the flight group matrix must not be altered. Printing and reporting code should not display the now-superfluous final round of the matrix, but its data should be retained in case the scorekeeper inserts a new round.

If the scorekeeper attempts to delete a round for which scores have been entered , the application must ask for confirmation before deleting the round. Upon confirmation, the system should mark the round as deleted (possibly setting all of its scores to zero), but retain it as a 'place-holder'. For example, if the scorekeeper deletes the third of seven rounds, scoring reports should show rounds 1, 2, 4, 5, 6, and 7. This ensures that existing pilot sheets and handwritten score sheets remain correctly numbered.

Use Case CONTEST06: Create flyoff

The scorekeeper enters a name for the flyoff 'contest' (default "Flyoff") and specifies the number of pilots from each class to be included in a flyoff. The number of pilots may be different for each class; for example, six experts, three sportsmen, and zero novices. The application creates a new contest, chooses the specified number of top-ranking pilots from each class, and marks them as participating in the flyoff contest.

The system may also allow the scorekeeper to specify a total number of pilots regardless of class. In that case, the system will populate the flyoff with the specified number of pilots from the event rankings.

If the event contained more than one contest prior to the flyoff, the scorekeeper may select any number of those contests to be used to seed the flyoff. The application will use the sum of scores for each pilot for the selected contests to determine the flyoff participants.

Use Case CONTEST07: Generate flight groups

Prerequisites: All pilots and their frequencies have been entered into the database for a contest, and the number of rounds to be flown and the number of flight groups have been entered. The scorekeeper asks the system to generate flight groups for one round or for all rounds. The system generates and saves flight group information for the specified round(s).

Use Case CONTEST08: Print pilot sheets

After flight groups have been generated for a contest, the system will allow the scorekeeper to print one or more copies of the pilot sheet. The default number of sheets to be printed will be the number of pilots flying in the contest.

Use Case CONTEST09: Generate/play timing files

[Future capability.]

Use Case SCORE01: Enter scores

The scorekeeper selects a heat, and enters scores for one or more pilots in the heat. For each pilot, the application provides the correct number of data-entry fields for the task, e.g., two fields for a "Next to last and last flights" round, five fields for a 'Poker' round, or time and landing points fields for a TD round.

The program will assume a score of zero for an empty field.

Scores cannot be entered if the heat, or its containing round, contest, or event, is locked.

Use Case SCORE02: Lock heat, round, contest, or event

When data entry for a heat has been completed, the scorekeeper can ask the system to mark the heat as locked. Once a heat is marked as locked, the system will not allow further data entry. This prevents the scorekeeper from entering scores in the wrong heat. The system will include similar 'locked' flags for rounds, contests, and entire events.

User Case SCORE03: Unlock heat, round, contest, or event

The system allows the scorekeeper to unlock a locked heat (round, etc...) for further data entry or data correction.

Use Case SCORE04: View detailed scores for contest

The scorekeeper selects an event and contest. The application displays detailed scores for each round along with pilot rankings, total scores, and other information. The display can be sorted by pilot name, pilot class, or pilot's total score.

Use Case SCORE05: View scores for event

The scorekeeper selects an event. The application displays a score summary for the event, with a row for each pilot and columns for each round and each contest, and per-contest and overall sums and rankings. Scores can be sorted by pilot name, pilot class, or pilot's total score.

Use Case SCORE06: Generate score reports

Generate score reports for round, contest, or entire event. When generating scores for a contest, the system will discard zero or more rounds depending on the contest's configuration. (The configuration defaults to the number of throwout rounds specified by F3K rules.)

Reports will be formatted professionally and will include the event name and contest name (if different). Reports will also include the club name and/or club logo if those were specified during application setup.

Use Case SCORE07: Display leaderboard

A user uses a Web browser to connect to the computer running the application. The application provides a Web page that displays an up-to-date summary of scores for the current contest. It may optionally display results for the entire event, and other 'interesting' information.

Use Case SCORE08: Display current round/heat/task

The application displays the current round, heat, and task in a large format. The scorekeeper will have the ability to advance the display to the next heat or round. (If the application is enhanced to generate and play timing files, it will be able to advance the display automatically.)

The display device may be a separate window on the computer screen, which can be dragged to a second monitor and turned to face the flying area. It may also be a Web page, served by the same Web server thread that displays the leaderboard. Finally, it may be an external display device such as an LED marquee.

Use Case SCORE09: Export scores to CSV file

...in several formats, e.g., score summary for a single contest, score summary for an event, score summary for all contests by pilot.

Use Case UTIL01: Configure application

Allow the scorekeeper to specify default values for a number of application-wide or event-wide options, including:

club name and club-specific graphics for reports
default parameters for flight order generation
number of throwout rounds (e.g., one throwout after six rounds, two throwouts after nine, ...)
for TD contests, whether to add landing points before or after normalizing flight scores

Changing a global scoring option (e.g., number of rounds to discard) for an event should cause scores to be recomputed without manual intervention.

Application-wide options which affect event scoring must also be stored as part of the event, so that subsequent changes to global settings will not cause changes to published scores.

Use Case UTIL02: Export event database

This function can be used to combine scores from a number of events into a central scoring repository. The scorekeeper selects an event. The application exports all data for that event in a form which can be imported into another instance of the application's database.

Use Case UTIL03: Import event database

The scorekeeper specifies a file containing exported event data. The system imports the data into its local database. The event will not be imported if existing data would be overwritten (for example, if an event by that name already exists).

This function must ensure that pilots are matched up correctly between databases, even when a pilot's name may be spelled differently in each database. The application may generate and display a tentative matchup of pilot names, and ask the scorekeeper to confirm or correct before importing data.

Last modified: 2009-12-02 17:41