Module Title: KF7010 Program Design and
Implementation
Module Code: KF7010
Module Tutors: Dr Mark C. Sinclair
Academic Year: 201 9-20 20
%Weighting: 100%
Coursework Title: Program Design and Implementation
Average Study Time
Required by Students:
60 study hours
Dates and Mechanisms for Assessment Submission and Feedback
Date of Handout to Students:
TBC
Mechanism for Handout to Students:
via eLP
Date and Time of Submission by Student:
Thursday 16 th Jan 20 20 by 16:00
Mechanism for Submission of Work by Student:
via eLP
Date by which Work, Feedback and Marks will be returned to Students:
3 Weeks after Final Submission
Mechanism for return of assignment work, feedback and marks to
students:
via eLP
1
COURSEWORK ASSESSMENT SPECIFICATION 2
1. Learning Outcomes
All the module learning objectives are covered by this assignment:
1. Demonstrate a systematic understanding of the principles, knowledge and
skills required to design, implement, test and document programs written
in an object -oriented language.
2. Demonstrate a critical understanding of the essential principles and
practices relating to object -oriented programming, including the need for
standards, principles of quality, and appropriate software support.
3. Critically evaluate the methods and conceptual tools used in developing
solutions to programming problems.
4. Analyse , specify, design, implement and test a high -level solution to a
programming problem using object -oriented and general imperative
programming language constructs, using appropriate documentation
standards and software tools.
5. Effectively communicate development of a solution to a programming
problem, including critical evaluation
The work is set in W eek 06 of the module by which time you will have covered
enough to make a start on the work.
2. Scope
The assignment is an individual assignment.
You will be provided with some initial program source code and a compiled
version of the program as described in the section below.
You must extend the program to meet the specification below.
What follows is a detailed discussion of the program and how it is
modelled and its functions, you will need to look very closely at the
specification for the object -orientated (OO) programs you are to create.
3. Assignment
3.1 The Server -Client Model
In this ass ignment, you will be provided with a set of client -server codes, which
allow you to communicate from a computer to another computer. You will be
asked to add extra codes to read data from one computer and transfer it via
network to another computer. The sy stem architecture can be shown in the
figure below. 3
To allow a client application to connect with a server, usually you need to
provide the address of the server, which includes two parts,
• IP address such as 144.122 .11.01
• Port number, such as 8080
This will allow a communication channel to be established between the server
and the client. You don’t need to fully understand these client -server codes and
the provided codes give n you a s a test platform for your OO programming
skills.
Fig.1 Client -Server Model
3.2. The Tasks
Based on the BlueJ platform, the challenge is to develop the software that will,
1) enable the chat communication between server and client;
2) provide a log system to store t he chat in both client and server side, so
that each time the system can load the previous dialogues into the
window;
3) load the initial data from a local file into the memory and transfer it to the
server side via the network, and
4) process it on the server s ide and save the process records in a log
file.
Fig.2 and 3 illustrate the user interface of the client -server system.
You are asked to write a report explaining the functionality and solutions to
various aspects of the program with regard to OO programming skills. The
report should not exceed 4000 words. 4
Fig.2 Server’s GUI style Fig.3 Client’s GUI s tyle
3.3. Functional Specification
The tasks you are required to implement are as follows,
1) You are going to build up a client -server application to enable
communication between two sides; the server will allow multiple clients
to connect to the chat room.
2) The server side will record all events and chats in a log file for records.
3) The server will be allowed to set its port number, and a button to
start/stop.
4) Each client will set up a unique ID and a unique log file, to store its
communication records.
5) The client side may have following GUI functions:
a. A text input box of the server IP address.
b. A text input box of the targeted server port.
c. A text input box of the client name.
d. A text input box of chat messages.
e. A button to log in/out (or two buttons separately)
f. A button to find out who are in the chat room and print out all
clients.
6) You are also required to develop a test plan and test the functiona lity of
your client classes. A test report will be included in your submission 5
4 Deliverables
4.1. General Points
1. The development of your codes is based on object -orientated model, and
you MUST make use of classes in developing your system. Each will have
its own methods and properties though they could inherit from other
classes.
2. All interactions must be made via a GUI. You may design the GUI as you
see fit: see the example depicted in Figure 2 and 3.
3. You might consider writing a custom dialogue to input the us er’s
preference and other information. This will require a little investigation on
your part.
4. The program should consist of a number of classes each with well -defined
functionality. There should be a driver class to set things going; a GUI
class to provide the user interface; a class and subclasses for the sensory
data reading.
5. The code you produce must adhere to the published course coding
standards. Marks are awarded for code quality.
6. You will be expected to test parts of your program against a suitable set of
situations. In the documentation you should describe your testing plan and
results ; also include your test results as screen shots as evidence.
4.2. Design
You must produce design documentation. This will include a class diagram for
the system, a short explanation as to the general purpose of each of the
classes you have produced and a justification for any design decisions you
have made.
4.3. Implementation
You must provide listings for your program. The code must adhere to t he
object -orientated style standards as defined for the module.
4.4 Testing
You are expected to test your code using the strategies studied during the
module.
The testing section of your documentation indicates the approach you have
taken to verifying and validating your system. Just as you should not convey
the design of your system by presenting the code or even listing the classes,
you should not merely list the tests performed. Rather, discuss how tests were
selected, why they are sufficie nt, why a reader should believe that no important 6
tests were omitted, and why the reader should believe that the system will
really operate as desired when in use.
1. Strategy : An explanation of the overall strategy for testing: Black box
an d/or white box, integration, kinds of test beds or test drivers used,
sources of test data, test suites. You might want to use different
techniques (or combinations of techniques) in different parts of the
program. In each case, justify your decisions.
2. Tes t Data : A set of tables showing the test data you used for each class,
etc. The format of the test documentation should be as follows: for each
test case in the tables,
• a unique test ID
• a brief description of the purpose of the test
• the pre -conditions for running the test
• the test data
• the expected result
4.5. Reflection
You must provide a final critical evaluation of your work. The reflection section
is where you can generali se from specific failures or successes to rules that
you or others can use in future software development. What surprised you
most? What do you wish you knew when you started? How could you have
avoided problems that you encountered during development?
1. Evaluation : What you regard as the successes and failures of the
development: unr esolved design problems, performance problems, etc.
Identify which features of your design are the important ones. Point out
design or implementation techniques that you are particularly proud of.
Discuss what mistakes you made in your design, and the prob lems that
they caused.
2. Lessons : What lessons you learned from the experience: how you might
do it differently a second time round, and how the faults of the design
and implementation may be corrected. Describe factors that caused
problems such as missed mi lestones or to the known bugs and
limitations.
3. Known Bugs and Limitations : In what ways does your implementation fall
short of the specification? Be precise. Although you will lose points for
bugs and missing features, you will receive partial credit for a ccurately
identifying those errors, and the source of the problem.
This reflection should be 1 to 2 pages long. 7
4.6. Deliverables
Submit a zip archive containing the following items:
1. Your source code with comments;
2. The executable application .
3. A document in pdf format containing
(a) Design documentation as specified above;
(b) Test documentation as specified above;
(c) Your reflection report as specified above.
A links will be provided on the eLP (BlackBoard) for you to upload this zip .
5. Collaboration and Academic Integrity
• You can discuss work , but submitted work MUST be your own.
• You can use some public domain code, but it must be clearly
referenced . It must be a very small component (less than 5%) of the
submitted assignment. Generally, it will NOT attract marks.
• The assignments are designed to allow YOU to demonstrate YOUR
achievement of learning outcomes.
• You can NOT use the work of your fellow students .
• You are advised to read the University regulations concerning
academic misconduct.
6. Marking Scheme
Introduction The marking for the assignment is designed to reflect the general guidance given
on the University’s web site for the assessment of postgraduate work. Some modifications to
the generic criteria have been made to better reflect the nature of the assignment.
70 -100 Distinction Excellent work providing evidence to a very high level of the knowledge,
understanding and skills appropriate to level 7. All learning outcomes met, many at high
level. Marks at the high end of this range indicate outstanding work where all learning
outcomes are met at a high level. Excellent in all the specific areas of the assessment
criteria listed below for the assignment; evidence of successful independent learning as
demonstrated by the implementation of optional features in the program; use of up -to-
date material from a variety of sources; critical evaluation and creative use of theory.
60 -69 Co mmendation Commendable work providing evidence to a high level of the knowledge,
understanding and skills appropriate to level 7. All learning outcomes met, many are
more than satisfied. Good in all or most of: the specific assessment criteria listed below
for the assignment; evidence of independent learning; critical evaluation and creative
use of theory.
55 -59 Pass Satisfactory work providing evidence of the knowledge, understanding and skills
appropriate to level 7. All learning outcomes are met. Satisfactory in all or most of the 8
assessment criteria listed below.
50 -54 Pass Adequate work providing evidence of the knowledge, understanding and skills
appropriate to level 7 but only at a bare pass level. All learning outcomes are me t (or
nearly met and balanced by strengths elsewhere). Adequate in all of (or most of, with
balancing strength elsewhere) of the criteria listed below.
40 -49 Fail The program fails to achieve the basic pass criteria specified below. Work is not
acceptable i n providing evidence of the knowledge, understanding and skills appropriate
to level 7. May be adequate in some but not all of the assessment criteria listed below.
1-39 Fail Work is not acceptable and provides little evidence of the knowledge, understandi ng
and skills appropriate to level 7. Few of the learning outcomes are met. Inadequate in
terms of the various criteria given below as a basis for judging the work.
0 Fail Work not submitted OR Work giving evidence of serious academic misconduct OR
Work sh owing no evidence of the knowledge, understanding and skills appropriate to
level 7. None of the learning outcomes are met
Specific Criteria
• Basic functionality and code quality: 15%
1. Model provides a basic functional application ;
2. Coding standards;
3. Well commented
• Quality of design and implementation 25%
1. OO aspects
2. Methods
3. Properties
• GUI 20%
1. Internal structure
2. Action Listeners
3. Graphical elements
• Testing 20%
1. Adequacy
2. Functionality
3. Justification
• Report 20%
1. Class diagram and description of classes
2. Evaluation
3. Lessons learnt
4. Bugs and limitations
Feedback will be provided within three weeks after the submission timeline,
mostly by e -mail or by eLP.
Submission Timeline
This is an individual assignment. Complete all the tasks list ed above. The 9
report needs to be submitted via eLP. The submission time is as follows,
Thursday 16 th Jan 20 20 by 16:00
7. Feedback Techniques used in this Module
Individual written feedback will be provided for the assessment. Feedback will
be given for each element of the marking scheme .
8. Return of Feedback
Marks and written feedback for the assignment will be returned within thee working
weeks after the submission deadline.
9. Late Submission
Unapproved late submission may cause the deduction of your marks. You can
find more details at https://www.northumbria.ac.uk/about -us /university -
services/academic -registry/quality -and -teaching -
excellence/assessment/guidance -for -students/
10. Failure to Submit
Note that failure to submit work will result in a record of incomplete (IC) for the
assessment component. Referral in that componen t will then be required . You
can find more details at https://www.northumbria.ac.uk/about -us/uni versity -
services/academic -registry/quality -and -teaching -
excellence/assessment/guidance -for -students/
11. Referencing Style
Any commonly used referencing style is acceptable as long as it is used
correctly and consistently. For technical work of this nature you might prefer to
use Harvard style.
12. Academic Integrity
You must adhere to the university regulations on academic conduct. Formal
inquiry proceedings will be instigated if there is any suspicion of plagiarism or
any other form of misconduct in yo ur work. Refer to the University’s
Assessment Regulations for Taught Awards if you are unclear as to the
meaning of these terms. The latest copy is available on the University website.
More details can be found at: https://www.northumbria.ac.uk/about -
us/university -services/academic -registry/quality -and -teaching -
excellence/assessment/guidance -for -stude nts/