520 lines
24 KiB
HTML
520 lines
24 KiB
HTML
/**DO NOT DELETE Security Code: 706-US24 Form: form-113.html ****/
|
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<meta name="GENERATOR" content="Mozilla/4.79C-CCK-MCD [en] (X11; U; SunOS 5.8 sun4u) [Netscape]">
|
|
<title>Sun Certified Developer for the Java 2 Platform: Application Submission (Version 1.1.3)</title>
|
|
</head>
|
|
<body>
|
|
<h1>
|
|
<a NAME="top"></a>Sun Certified Developer for the Java 2 Platform: Application
|
|
Submission (Version 1.1.3)</h1>
|
|
<h2>
|
|
Introduction and Index</h2>
|
|
This document tells you what you need, and what you must do, to submit
|
|
your solution to the Sun Certified Developer for the Java 2 Platform programming
|
|
assignment. Read it carefully before you begin work on the solution. This
|
|
document contains strict guidelines about the way the work is to be performed.
|
|
These guidelines ensure consistency and fairness.
|
|
<p>The application distribution is composed of:
|
|
<ul>
|
|
<li>
|
|
This document</li>
|
|
<li>
|
|
A non-relational database file</li>
|
|
</ul>
|
|
Be sure to maintain a backup copy of all files related to your project,
|
|
including the distribution files, until you receive your certificate in
|
|
case one or more is corrupted, lost, or becomes unusable. You must not
|
|
use any materials issued to other certification candidates even if you
|
|
believe they are identical.
|
|
<p>This document is divided into the following sections:
|
|
<ul>
|
|
<li>
|
|
<b><a href="#what_this">Application Overview</a></b> - A general description
|
|
of the application you will write</li>
|
|
<li>
|
|
<b><a href="#arch">Architecture</a></b> - The parts of the application
|
|
and how they fit together</li>
|
|
<li>
|
|
<b><a href="#UI">User Interface</a></b> - GUI specification</li>
|
|
<li>
|
|
<b><a href="#database">Server</a></b> - The data server and its network
|
|
connection</li>
|
|
<li>
|
|
<b><a href="#data">Data file format</a></b> The format and schema of the database file</li>
|
|
<li>
|
|
<b><a href="#Deliverables">Deliverables</a></b> - The components you must
|
|
deliver, and how you should package them.</li>
|
|
<li>
|
|
<b><a href="#marking">Marking</a></b> - How your assignment will be graded</li>
|
|
<li>
|
|
<b><a href="#whattodo">What to do if you have a question</a></b></li>
|
|
</ul>
|
|
<h3>
|
|
Important Note About Automatic Failure</h3>
|
|
<i>Where this document uses the word "must" an absolute requirement is
|
|
being described. If you fail to adhere to such a requirement, your assignment
|
|
will be failed automatically, and without further evaluation. It is therefore
|
|
imperative that you pay close attention to any statement using the word
|
|
"must" in this document. Portions of your submission will be analyzed
|
|
by software; where a specific spelling or structure is required, even a
|
|
slight deviation could result in automatic failure. </i>
|
|
<hr>
|
|
<h2>
|
|
<a NAME="what_this"></a>Application Overview</h2>
|
|
<H3>Background</H3>
|
|
URLyBird is a broker of discount hotel rooms. They sell
|
|
accomodations for business and pleasure travellers at short notice,
|
|
helping hotels to fill rooms that would otherwise be left empty. They
|
|
take bookings only within 48 hours of the start of room occupancy.
|
|
Curently, URLyBird sells the rooms over the phone using a team of
|
|
customer service representatives (CSRs). The CSRs interact with an
|
|
aging custom-written application that has been drawing increasing criticism
|
|
from the CSRs. In the future, URLyBird wants to move into
|
|
Internet-based marketing, and hopes to be able to accept bookings
|
|
direct from customers over the web.
|
|
<P>The company's IT director has decided to migrate the existing
|
|
application to a Java technology based system. Initially, the system
|
|
will support only the CSRs, although the hope is that this interim
|
|
step will give them a starting point for migrating the system to the
|
|
web. The IT director does not anticipate much reuse of the first Java
|
|
technology system, but intends to use that system as a learning
|
|
exercise before going on to a web based system.
|
|
<P>The company's IT department has a data file that contains the
|
|
essential information for the company, but because the data must
|
|
continue to be manipulated for reports using another custom-written
|
|
application, the new system must reimplement the database code from
|
|
scratch without altering the data file format.
|
|
<P>The new application, using the existing data file format, must
|
|
allow the CSRs to generate a list of accomodations that match a
|
|
customer's criteria. This is the project that you have been
|
|
commissioned to implement.
|
|
<h3>
|
|
What you must do</h3>
|
|
The following are the "top level" features that must be implemented:
|
|
<ul>
|
|
<li>
|
|
A client program with a graphical user interface that connects to the database</li>
|
|
<li>
|
|
A data access system that provides record locking and a flexible search
|
|
mechanism</li>
|
|
<li>
|
|
Network server functionality for the database system</li>
|
|
</ul>
|
|
The work involves a number of design choices that have to be made. In all
|
|
such cases, the following principles should be applied.
|
|
<h4>
|
|
Clarity and Maintainability</h4>
|
|
<dl>
|
|
<dd>
|
|
A clear design, such as will be readily understood by junior programmers,
|
|
will be preferred to a complex one, even if the complex one is a little
|
|
more efficient. Code complexity, including nesting depth, argument passing,
|
|
and the number of classes and interfaces, should be reasonable.</dd>
|
|
<dd>
|
|
</dd>
|
|
</dl>
|
|
<h4>
|
|
Documentation</h4>
|
|
<dl>
|
|
<dd>
|
|
The code itself should be as clear as possible; do not provide comments
|
|
that do not add to the comprehensibility of the code. Awkward or complex
|
|
code should have descriptive comments, and javadoc style comments must
|
|
be used for each element of the public interface of each class. You must
|
|
create a full suite of documentation for the classes of the completed project.
|
|
This must be generated using the tool "javadoc" and must be in HTML format.
|
|
Provide javadoc documentation for all classes you write.</dd>
|
|
<dd>
|
|
</dd>
|
|
<dd>
|
|
You must provide basic user documentation. This should be sufficient to
|
|
allow a user who is familiar with the broad purpose of the project to use
|
|
the application. This documentation must be in one of these three formats:</dd>
|
|
</dl>
|
|
<ul>
|
|
<li>
|
|
HTML</li>
|
|
<li>
|
|
Plain text (not a wordprocessor format)</li>
|
|
<li>
|
|
Within the application as a help system.</li>
|
|
</ul>
|
|
<h4>
|
|
Correctness</h4>
|
|
<dt>
|
|
Your project must conform to this specification. Features that deviate
|
|
from specification will not receive full credit. You will not receive
|
|
extra credit points for work beyond the requirements of the specification.</dt>
|
|
<h4>
|
|
Use of Standard Elements</h4>
|
|
<dl>Use of functionality provided by the core Java classes will be preferred
|
|
to your own implementation of that functionality, unless there is a specific
|
|
advantage to providing your own implementation.</dl>
|
|
<i><a href="#top">Return to top</a></i>
|
|
<hr>
|
|
<h2>
|
|
<a NAME="arch"></a>Overall Architecture</h2>
|
|
<h3>
|
|
Major Components</h3>
|
|
The main architecture of the application must be a traditional client-server
|
|
system. There are three key parts: the server-side data management
|
|
system, the client-side GUI, and the network connection between the two.
|
|
<h3>
|
|
Non-Networked Mode</h3>
|
|
The program must be able to work in a non-networked mode. In this mode,
|
|
the database and GUI must run in the same VM and must perform no networking,
|
|
must not use loopback networking, and must not involve the serialization
|
|
of any objects when communicating between the GUI and database elements.
|
|
<p>The operating mode is selected using the single command line argument
|
|
that is permitted. Architecturally, this mode must use the database and
|
|
GUI from the networked form, but must not use the network server code at
|
|
all.
|
|
<h3>
|
|
Network Communication Approach</h3>
|
|
You have a choice regarding the network connection protocol. You must use
|
|
either serialized objects over a simple socket connection, or RMI.
|
|
Both options are equally acceptable. Keep in mind that networking
|
|
must be entirely bypassed in the non-networked mode.
|
|
<h3>
|
|
Restrictions on RMI</h3>
|
|
To avoid unnecessary complexity in the marking environment certain restrictions
|
|
are placed on solutions that use RMI. Specifically:
|
|
<br>
|
|
<li>
|
|
You must not require the use of an HTTP server.</li>
|
|
<li>
|
|
You must not require the installation of a security manager.</li>
|
|
<li>
|
|
You must provide all classes pre-installed so that no dynamic class
|
|
downloading occurs.</li>
|
|
<li>
|
|
You must use RMI over JRMP (do not use IIOP)</li>
|
|
<p><i><a href="#top">Return to top</a></i>
|
|
<hr>
|
|
<h2>
|
|
<a NAME="UI"></a>The User Interface</h2>
|
|
The user interface for this assignment must satisfy the following criteria:
|
|
<ul>
|
|
<li>
|
|
It must be composed exclusively with components from the Java Foundation
|
|
Classes (Swing components).</li>
|
|
<li>
|
|
It must allow the user to search the data for all records, or for records
|
|
where the name and/or location fields exactly match values specified by
|
|
the user.</li>
|
|
<li>
|
|
It must present search results in a JTable.</li>
|
|
<li>
|
|
It must allow the user to book a selected record, updating the database
|
|
file accordingly.</li>
|
|
</ul>
|
|
Your user interface should be designed with the expectation of future functionality
|
|
enhancements, and it should establish a framework that will support this
|
|
with minimal disruption to the users when this occurs.
|
|
<p><i><a href="#top">Return to top</a></i>
|
|
<hr>
|
|
<h2>
|
|
<a NAME="database"></a>Server</h2>
|
|
<H3>Required Interface</H3>
|
|
Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:
|
|
<P><PRE>
|
|
package suncertify.db;
|
|
public interface DB
|
|
{
|
|
// Reads a record from the file. Returns an array where each
|
|
// element is a record value.
|
|
public String[] read(int recNo) throws RecordNotFoundException;
|
|
// Modifies the fields of a record. The new value for field n
|
|
// appears in data[n]. Throws SecurityException
|
|
// if the record is locked with a cookie other than lockCookie.
|
|
public void update(int recNo, String[] data, long lockCookie)
|
|
throws RecordNotFoundException, SecurityException;
|
|
// Deletes a record, making the record number and associated disk
|
|
// storage available for reuse.
|
|
// Throws SecurityException if the record is locked with a cookie
|
|
// other than lockCookie.
|
|
public void delete(int recNo, long lockCookie)
|
|
throws RecordNotFoundException, SecurityException;
|
|
// Returns an array of record numbers that match the specified
|
|
// criteria. Field n in the database file is described by
|
|
// criteria[n]. A null value in criteria[n] matches any field
|
|
// value. A non-null value in criteria[n] matches any field
|
|
// value that begins with criteria[n]. (For example, "Fred"
|
|
// matches "Fred" or "Freddy".)
|
|
public int[] find(String[] criteria);
|
|
// Creates a new record in the database (possibly reusing a
|
|
// deleted entry). Inserts the given data, and returns the record
|
|
// number of the new record.
|
|
public int create(String[] data) throws DuplicateKeyException;
|
|
// Locks a record so that it can only be updated or deleted by this client.
|
|
// Returned value is a cookie that must be used when the record is unlocked,
|
|
// updated, or deleted. If the specified record is already locked by a different
|
|
// client, the current thread gives up the CPU and consumes no CPU cycles until
|
|
// the record is unlocked.
|
|
public long lock(int recNo) throws RecordNotFoundException;
|
|
// Releases the lock on a record. Cookie must be the cookie
|
|
// returned when the record was locked; otherwise throws SecurityException.
|
|
public void unlock(int recNo, long cookie)
|
|
throws RecordNotFoundException, SecurityException;
|
|
}
|
|
</PRE>
|
|
<P>Any unimplemented exceptions in this interface must all be created as member classes of the
|
|
<tt>suncertify.db</tt> package. Each must have a zero argument constructor and a second
|
|
constructor that takes a String that serves as the exception's description.
|
|
<p>Any methods that throw RecordNotFoundException should do so if a specified
|
|
record does not exist or is marked as deleted in the database file.
|
|
<h3>
|
|
<font size=+0>Network Approaches</font></h3>
|
|
Your choice of RMI or serialized objects will not affect your grade, but
|
|
no other approach is acceptable. In either case, the program must allow
|
|
the user to specify the location of the database, and it must also accept
|
|
an indication that a local database is to be used, in which case, the networking
|
|
must be bypassed entirely. No authentication is required for database access.
|
|
<h3>
|
|
Locking</h3>
|
|
Your server must be capable of handling multiple concurrent requests, and
|
|
as part of this capability, must provide locking functionality as specified
|
|
in the interface provided above. You may assume that at any moment,
|
|
at most one program is accessing the database file; therefore your locking
|
|
system only needs to be concerned with multiple concurrent clients of your
|
|
server. Any attempt to lock a resource that is already locked should
|
|
cause the current thread to give up the CPU, consuming no CPU cycles until
|
|
the desired resource becomes available.
|
|
<p><i><a href="#top">Return to top</a></i>
|
|
<hr>
|
|
<h2> <a NAME="data"></a> Data file Format</h2>
|
|
The format of data in the database file is as follows:
|
|
<p>Start of file
|
|
<br>4 byte numeric, magic cookie value. Identifies this as a data file
|
|
<br>2 byte numeric, number of fields in each record
|
|
<p>Schema description section.
|
|
<br>Repeated for each field in a record:
|
|
<br>1 byte numeric, length in bytes of field name
|
|
<br>n bytes (defined by previous entry), field name
|
|
<br>1 byte numeric, field length in bytes
|
|
<br>end of repeating block
|
|
<p>Data section.
|
|
<br>Repeat to end of file:
|
|
<br>1 byte flag. 00 implies valid record, 0xFF implies deleted record
|
|
<br>Record containing fields in order specified in schema section, no separators
|
|
between fields, each field fixed length at maximum specified in schema
|
|
information
|
|
<p>End of file
|
|
<p>All numeric values are stored in the header information use the formats
|
|
of the DataInputStream and DataOutputStream classes. All text values, and
|
|
all fields (which are text only), contain only 8 bit characters, null terminated
|
|
if less than the maximum length for the field. The character encoding is
|
|
8 bit US ASCII.
|
|
<H3>Database schema</H3>
|
|
The database that URLyBird uses contains the following fields:
|
|
<table>
|
|
<tr>
|
|
<td>Field descriptive name</td>
|
|
<td>Database field name</td>
|
|
<td>Field length</td>
|
|
<td>Detailed description</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Hotel Name</td>
|
|
<td>name</td>
|
|
<td>64</td>
|
|
<td>The name of the hotel this vacancy record relates to</td>
|
|
</tr>
|
|
<tr>
|
|
<td>City</td>
|
|
<td>location</td>
|
|
<td>64</td>
|
|
<td>The location of this hotel</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Maximum occupancy of this room</td>
|
|
<td>size</td>
|
|
<td>4</td>
|
|
<td>The maximum number of people permitted in this room, not including infants</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Is the room smoking or non-smoking</td>
|
|
<td>smoking</td>
|
|
<td>1</td>
|
|
<td>Flag indicating if smoking is permitted. Valid values are "Y" indicating a smoking room,
|
|
and "N" indicating a non-smoking room</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Price per night</td>
|
|
<td>rate</td>
|
|
<td>8</td>
|
|
<td>Charge per night for the room. This field includes the currency symbol</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Date available</td>
|
|
<td>date</td>
|
|
<td>10</td>
|
|
<td>The single night to which this record relates, format is yyyy/mm/dd.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Customer holding this record</td>
|
|
<td>owner</td>
|
|
<td>8</td>
|
|
<td>The id value (an 8 digit number) of the customer who has booked this.
|
|
Note that for this application, you should assume that customers and CSRs
|
|
know their customer ids. The system you are writing does not interact with
|
|
these numbers, rather it simply records them. If this field is all blanks, the
|
|
record is available for sale.</td>
|
|
</tr>
|
|
</table>
|
|
<p><i><a href="#top">Return to top</a></i>
|
|
<hr>
|
|
<h2>
|
|
<a NAME="Deliverables"></a>Deliverables</h2>
|
|
<h3>
|
|
Target Platform and Execution</h3>
|
|
Throughout this exercise, you must use exclusively the Java 2 platform.
|
|
You may develop your code using any implementation of the Java 2 platform,
|
|
but the submission that you return must have been tested and shown to work
|
|
under a production (not development) version of the Sun Microsystems' Java
|
|
2 platform and that platform must not have been superseded by a new production
|
|
version for more than 18 months by the time you make your submission.
|
|
<p>You are permitted to use any IDE tool you choose, but you must not submit
|
|
any code that is not your own work. The final program must have no dependencies
|
|
on any libraries other than those of the Java 2 Platform.
|
|
<p>When you submit your assignment, each part (client and server) must
|
|
be executable using a command of this exact form:
|
|
<blockquote><tt>java -jar <path_and_filename> [<mode>]</tt></blockquote>
|
|
Your programs must not require use of command line arguments other than
|
|
the single mode flag, which must be supported. Your programs must
|
|
not require use of command line property specifications. All configuration
|
|
must be done via a GUI, and must be persistent between runs of the program.
|
|
Such configuration information must be stored in a file called suncertify.properties
|
|
which must be located in the current working directory.
|
|
<p>The mode flag must be either "server", indicating the server program
|
|
must run, "alone", indicating standalone mode, or left out entirely, in
|
|
which case the network client and gui must run.
|
|
<p>You must not require manual editing of any files by the examiners.
|
|
<h3>
|
|
Packaging of Submissions</h3>
|
|
All elements of your submission must be packaged in a single JAR file.
|
|
The JAR file must have the following layout and contents in its root:
|
|
<ul>
|
|
<li>
|
|
The executable JAR containing the programs. This must be called <tt>runme.jar</tt>.</li>
|
|
<li>
|
|
The original, <i>unchanged</i> database file that was supplied to you.
|
|
Note that you must keep a copy of the original database file supplied to
|
|
you, and this must be the file you submit. The marking process will expect
|
|
the exact same data without any changes.</li>
|
|
<li>
|
|
A directory called <tt>code</tt>, containing all the source code and related
|
|
parts of your project. You must create subdirectories within this to reflect
|
|
your package structure and distribute your source files within those directories.</li>
|
|
<li>
|
|
A file called <tt>version.txt.</tt> This must contain pure ASCII (not a
|
|
word processor format) indicating the exact version of JDK you used, and
|
|
the host platform you worked on.</li>
|
|
<li>
|
|
A directory called <tt>docs</tt>, containing the following items at the
|
|
top level:</li>
|
|
<ul>
|
|
<li>
|
|
This html file.</li>
|
|
<li>
|
|
A subdirectory called javadoc, containing HTML/Javadoc documentation for
|
|
all classes and interfaces you are submitting.</li>
|
|
<li>
|
|
A file called <tt>choices.txt</tt> that containing pure ASCII (not a word
|
|
processor format) text describing the significant design choices you made.
|
|
Detail the problems you perceived, the issues surrounding them, your value
|
|
judgments, and the decisions that you made. This document should also describe
|
|
any uncertainties you had regarding the project, and the decisions you
|
|
made when resolving them.</li>
|
|
<li>
|
|
User documentation for the database server and the gui client. If your
|
|
user documentation is online then you may omit this file. However, if the
|
|
documentation is not online, you must provide either a single plain ASCII
|
|
(not word processor format) text document, which must be called <tt>userguide.txt</tt>,
|
|
or multiple HTML files which must all be accessible from a starting point
|
|
document that must be called <tt>userguide.html</tt>.</li>
|
|
</ul>
|
|
</ul>
|
|
<p><i><a href="#top">Return to top</a></i>
|
|
<hr>
|
|
<center>
|
|
<h2>
|
|
<a NAME="marking"></a>Marking</h2></center>
|
|
This section describes how your submission will be marked, and the marking
|
|
criteria which govern allocation of marks for the Sun Certified Developer
|
|
for the Java 2 platform application submission. The first part describes
|
|
the marking process, and the second describes how the marks are allocated.
|
|
<p><b>How The Assignment is Marked</b>
|
|
<p>The marking is done in three phases. First, software checks that
|
|
overall structure and nomenclature conform to specification. Second
|
|
the examiner runs the code ensuring that it functions correctly through
|
|
the specified operations. If any automatic failures are noted at this stage,
|
|
the marking process terminates and the assignment is failed.
|
|
<p>Provided the essential behavioral requirements of the assignment have
|
|
been correctly implemented, the examiner proceeds to investigate the design
|
|
and implementation of your assignment. This process is time consuming,
|
|
and it is because this is done carefully and thoroughly that submissions
|
|
take time to grade. The grading process is closely controlled to ensure
|
|
consistency and fairness, and it is performed according to criteria detailed
|
|
in the next section. At any time during this process, if an automatic failure
|
|
is noted, the marking process terminates, and the assignment is failed.
|
|
For any design choice concerning topics not specifically described in the
|
|
requirements, marks are awarded for a clear and consistent approach, rather
|
|
than for any particular solution. Design decisions must be described <i>briefly
|
|
but clearly</i> in your comments.
|
|
<p>In addition to the submission, you will be required to take a written
|
|
examination. This exam tests your understanding of your submission and
|
|
asks you to justify a number of design choices embodied in that submission.
|
|
<h3>
|
|
Automatic Failures</h3>
|
|
<i>As noted at the beginning of this document, where this document uses
|
|
the word "must" an absolute requirement is being described. If you fail
|
|
to adhere to such a requirement, your assignment will be failed automatically,
|
|
and without further evaluation. It is therefore imperative that you pay
|
|
close attention to any statement using the word "must" in this document.</i>
|
|
<h3>
|
|
<b>Marking Criteria</b></h3>
|
|
Your work will be evaluated based on the following criteria. The minimum
|
|
passing score is 320 out of a possible 400 points.
|
|
<p>General Considerations (100 points)
|
|
<br>Documentation (70 points)
|
|
<br>Object-orietned design (30 points)
|
|
<br>User Interface (40 points)
|
|
<br>Locking (80 points)
|
|
<br>Data class (40 points)
|
|
<br>Server (40 points)
|
|
<br>
|
|
<br>
|
|
<p><i><a href="#top">Return to top</a></i>
|
|
<hr>
|
|
<center>
|
|
<h2>
|
|
<a NAME="whattodo"></a>What to do if you have a question</h2></center>
|
|
You might find that you want to ask for further explanation of some part
|
|
of this document, perhaps to seek permission to solve a problem in a particular
|
|
way. This document deliberately leaves some issues unspecified, and some
|
|
problems unraised. Your ability to think through these issues, in the face
|
|
of realistically imperfect specifications, and come to a tenable solution
|
|
is something upon which you are being graded.
|
|
<p>In general, you should <i>not</i> ask your question; rather you should
|
|
consider the options available and make a decision about how to address
|
|
the problem yourself. This decision-making process is part of the marking
|
|
scheme, and as such it is crucially important that you provide documentation
|
|
of your choice. Be sure to describe the options you considered, the perceived
|
|
benefits and weaknesses of each, and why you chose the solution you did.
|
|
Provided you do not contravene any specification in this document you will
|
|
not be marked on the particular choice that you made, but rather on the
|
|
consistency of your decision making process and your adherence to other
|
|
aspects of these notes during that decision making process.
|
|
<p>If you feel you must ask your question, you should address it to who2contact@sun.com.
|
|
Clearly indicate that the question relates to the Sun Certified Developer
|
|
Exam, provide your candidate ID number, name, and include your return email
|
|
address in the <i>body</i> of your message. Describe your issue as briefly
|
|
as reasonably possible; you will be asked for more information if necessary.
|
|
<p><i><a href="#top">Return to top</a></i>
|
|
</body>
|
|
</html>
|