MODULAR PROGRAMME

ASSESSMENT SPECIFICATION

Module Details
Module Code Run Module Title
UFCEKP-20-2 08SEP/1 AY Client-Server Programming
Module Leader Module Tutors
Jin Sa Jin Sa, Julia Dawson, Muhammad Tahir
Weighting: (% of the Module's
Component and Element Number
assessment)
B1
50%
Element Description Total Assignment time
Practical Exercises 24 hours

Dates
Date Issued to Students Date to be Returned to Students
To be supplied 26th March 2009
Submission Place Submission Date
PROJECT ROOM - 2Q30 12th March 2009
(Help Desk open 9.00 - 6.00pm)
Submission Time
2.00 pm

Deliverables
See the assignment

Module Leader Signature

UFCEKP-20-2 Client Server Programming Assignment

Your assignment has 2 parts:

 Part 1: A network application -- a client server computer

software application.
 Part 2: An essay/diary -- a record of the design and the
development of the application.
Part 1: A client-server network application (60% of the
assignment)

Description of the application:

You are asked to develop a client-server download centre. On your server, there are
four resources that can be downloaded: iTune , ZoneAlarm, WinRar and Audacity. (In
your implementation, these resources can be represented as strings.)

The server should be “always-on”. In order to download a resource, a client makes

connection request to the server. The server sends a response to the client telling the
client how to proceed. The server sends the client the terms of reference to be agreed
before showing the client the resources. In order to proceed, the client has to agree the
terms of reference. After that, the server sends the client the list of resources it has.
The client selects a resource; the server sends the resource (i.e. the corresponding
string) to the client. The client can download more resources if he/she wishes. To
disconnect from the server, the client sends the message “bye” to the server.

Here is an example of a typical exchange between the client and the server:

Server says: Here are the terms of reference. Do you accept? yes or no
Client: yes
Server says: 1. iTune 2. ZoneAlarm 3. WinRar 4. Audacity Select a resource for
downloading
Client: 3
Server says: You are downloading WinRar.zip ...
Client: <CR>
Server says: Enter "bye" to exist, and "enter" to continue.
Client: bye

Your application needs to include the different alternatives; for example, the client
may not agree with the terms of references. The application needs to detect bad client
entries, e.g. entering invalid selection for downloading.

Your tasks:

You are required to document, design and implement the application in three stages:
version1, version 2 and version 3.

Version 1:

Implement all the functionalities described above. The client and the server must
adhere to the protocols illustrated. The server must be a concurrent server.

(Hint: You could base your design and implementation on the ideas in the Knock
Knock Joke Socket tutorial
http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html.
However: the Knock Knock programs use some compound if statements. To
improve the readability of your program, you should avoid using the compound if
statement. You should use switch/case statements instead. )

Version 2:

Add a counter for each resource that counts how many times the resource has been
downloaded. Each time a resource is downloaded, the server displays the value of
counter on the server side. (Hint: You need to think about problems with concurrent
threads sharing the same data.)

Version 3:

Provide a GUI front end for the client.

Marks will be awarded as follows for part 1:

 16% Implementation of Functionality in version 1

o Well-defined and clear demonstration of application requirements
o You may wish to include a short “user manual” giving a description of
application use and functionality.

 10% Version 2
o Suitable construct
o Evidence of addressing problem with multiple threads sharing data

 10% GUI Version

o User friendly
o Screenshot(s) must be given.
o Good code separation between functionality and GUI.

Following percentages are dependant on the implementation of reasonable

functionality:

 10% Logic
o Simple and clear.
o Easy to read and maintain code.

 6% Error Trapping. Examples:

o Good exception handling, port in use/server unavailable
o Bad user entry

 8% Documentation/Commenting
o For each class, method and where necessary
Part 2: Production Diary. (40% of the assignment)

You should write a Production Diary of at least 1000 words. This diary is a
record of your programming planning and development. The diary may be used to
confirm that you have written this code yourself.

The diary is in two parts

1. An overall plan of how you will do the assignment – both in terms of an initial
overview of the potential system and a project plan with timescale for different
parts of your project.
2. A recording of each session spent on the assignment. (See example in
Appendix A.)

The types of things you should record are:

 Dates and times
 Sources of information/reference
 Problems encountered and how you solved them (showing code
examples where required)
 How you would extend the application
 Any design used e.g. UML diagrams, state transition diagram
 Version development showing how the code developed

This is NOT a user guide/manual but a “diary” of events and reflections.

You will find it very much easier (and gain more marks!) if you record your progress
as you develop your application rather than leaving it until afterwards.

You can find further information about the diary and an example session entry in
Appendix A (or at http://www.cems.uwe.ac.uk/~jedawson/ufcekp/DiaryTemplate.doc )

Marks will be awarded as follows:

 5% Evidence of good initial planning/design

 30% True reflection of design and code development in real-time
 5% Awareness of possible improvements, failings and limitations of
application (a critical appraisal).
Deliverables

 Part 1: Hard Copy (printout) and soft copy of computer software system(s) plus
supporting documentation.

 Part 2: Hard copy of your Production Diary of at least 1000 words documenting
the plan, the design and the development of the system
Appendix A

Client Server Programming Assignment

Production Diary Template/Example

Student Name/Number:

You should write a production diary/essay at least 1000 words. This diary is a record
of your programming planning and development. The diary may be used to confirm
that you have written this code yourself.

Use this box to present your overall project plan, timescale and milestones.

Overall project plan, Timescale and Milestones.

For each diary entry, the type of things you should record are:
 Dates and times
 Sources of information/reference
 Problems encountered and how you solved them (showing code
examples where required)
 How you would extend the application
 Any design used e.g. UML diagrams.
 Version development showing how the code developed
 Full explanation of your protocol

=======================================================
Date: Start time: Time allowed:
To be achieved:

Your entry goes here.

Finish time:
Main achievement:
Code version (if applicable):
Next task:
An example of a diary entry

Date: 2 Oct 2007 Start time: 4:30pm Time allowed:60 min

To be achieved: Working on refactoring KnockKnockProtocol class to make the
Protocol clearer

 Need to take nasty if/else construct out of Protocol and replace with more
readable/manageable switch statement.

Ref. http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html

Can't remember switch syntax. Googled "java switch case" got useful ref:
http://java.sun.com/docs/books/tutorial/java/nutsandbolts/switch.html

Identify allowed states. (See Diagram Below)

Can use existing values … e.g. WAITING, ANOTHER etc. switch is easy 'cos states
are int already so …

switch (state) {
case WAITING : theOutput = hello(); break;

Identify what to do in each state

WAITING : starting state , no input reqd.

+ hello( ) : String
Set current joke; send a greeting string; change state to SENTKNOCKKNOCK

SENTKNOCKKNOCK; need input ("Who's there?")

+ sendClue(String) : String
If input incorrect output a helpful message and stay in same state
Else send first clue (name) and change state

Other states .. OK can read if/else code form original and translate but need to write
out method names for reference (consistency) …

+ hello( ) : String // awakening!!

+ sendClue(String) : String // got Who's there? OK
+ sendJoke(String) : String // got name who? OK
+ sendClue(String) : String // got Y or n
+ sendAnother (String) : String // need to quit on n or
else go to hello()

CODE:
switch (state) {
case WAITING : theOutput = hello() ; break;
case SENTKNOCKKNOCK : theOutput = sendClue(theInput); break;
case SENTCLUE : theOutput = sendJoke(theInput); break;
 case ANOTHER : theOutput = sendAnother(theInput); break;
}
return theOutput;

Sample method:

private String sendClue(String theInput) {

if (theInput.equalsIgnoreCase("Who's there?")) {
theOutput = clues[currentJoke];
state = SENTCLUE;
} else {
theOutput = "You're supposed to say \"Who's there?\"! " +
"Try again. Knock! Knock!";
}
return theOutput;
}

OK – code all compiled OK. Code Version: V4.2

Finished before time!!

Finish time: 5:20pm

Main achievement: Made the program structure readable and maintainable by
removing the nasty nested if/else statements.
Code version (if applicable): Protocol.java V4.2