Recent Questions and Assignment Topics

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/