Aim The aim of the Module’s portfolio assignment

 

         I. Assessment Requirements

 

A.    Assessment Deliverables

Aim

The aim of the Module’s portfolio assignment is to demonstrate the knowledge gained during the module in understanding BOTH object-oriented analysis and design (OOAD), and object-oriented programming (OOP) using C++. 

 

In this assignment task, you are required to produce a working program in C++ and a structured report describing the program.  The System Specification for the C++ program is given below in Section B ‘C++ Assessment Scenario/Problem’.

 

Working program using C++

For the system specified in Section II, you are required to write a program in C++ using Microsoft Visual Studio 2017 (MSVS).  Your program will use the Windows command line for all output.

 

The program will have: 

 

·         Functionality to store and display a set of graphical shape Objects using a Linked List.  The shape objects represent the status of the condition of areas of a road surface.  The status will be either ‘good’ or ‘alert’ i.e. in need of repair.

 

See the details below on the system and program specification.

 

THE PROJECT SHOULD BE MADE WITHOUT USING PRE-COMPILED HEADERS.  The MSVS solution folder, together with all source files and the working executable program must be provided and submitted to the module dropbox on NOW, as detailed below.  All source files must include the PLAGIARISM DECLARATION, as detailed below.  You may use and adapt the lab code examples, but must reference the lab code or its adaption in your code.  Any code adapted from another source (e.g. online or book) must have a reference to the original source in your code. 

 

Structured report for the C++ program

For the system specified in Section B, you are required to write a report about the design and testing of your program with the following structure:

 

·         It should start with a title, your student id, module name and id,

·         Section 1: Explanation of the design of your program.

·         Section 2: Test Plan and results.

·         Section 3: Evaluation of the program.

·         Appendix: Full Source Code Listing

 

See details below on each report section. 

 

Progress Shown in Lab Questions

Each lab worksheet will have a starred question that needs to be submitted to the ‘Lab Worksheet Questions’ dropbox by the Tuesday following the previous lab and lecture session on a Friday. 

Plagiarism Declaration

 

The following PLAGIARISM DECLARATION must be entered into the report and all source files (.ccp and .h), with the name and ID completed:

 

“I am aware of the University’s rules on plagiarism and collusion and I understand that, if I am found to have broken these rules, it will be treated as Academic Misconduct and dealt with accordingly.  I understand that if I lend this piece of work to another student and they copy all or part of it, either with or without my knowledge or permission, I shall be guilty of collusion.  In submitting this work I confirm that I am aware of, and am abiding by, the University’s expectations for proof-reading.

 

Name: ..................................................... ID No: .......................”.

 

Network Hand in of the C++ Coursework Assignment

 

Submission of the following to the Dropbox folder named ‘OOAD & OOP Assignment’ on this module’s NOW website is mandatory:

 

·         Your C++ Report should be a Word document labelled: your_studentID_OOPReport.docx e.g. N0123456_Report.docx i.e. not zipped

 

·         Your Microsoft Visual Studio solution directory, source and header files should be zipped into a file labelled: your_studentID_OOP_Project.zip

e.g. N0123456_OOPProject.zip i.e. zipped

 

You may be asked to discuss and demonstrate your assignment at a viva after your assignment has been marked.

B.    C++ Assessment Scenario/Problem

Requirements Specification for a Simple Road Condition Data Structure and Management Tool

 

A system (to be developed as a program written in C++ and using the command line for output) is required that allows the user to create and edit a list containing a number of initially unordered Road Condition shape objects.  The Road Condition shape objects represent areas of a road where the condition of the road has been measured.  The shapes will consist of ‘X’ characters, to signify a problem with the road surface, or ‘O’ characters to signify that the road surface is in good condition.  The Road Condition shape objects can overlap and have a date associated with them.  To get a correct view of the road condition the most recent objects have to be drawn last. The Road Condition shape objects will be entered by the user and stored in a linked list (consisting of a List class and a Link class, adapted from those used in lecture 8 and lab 8, or lecture 11 and lab 11). 

 

Each of these shape objects is displayed as a number of characters (‘X’ of ‘O’).  A shape object will be one of the following types: a rectangle, a diamond or a triangle.  The size of the object will be the number of columns and rows of characters for a rectangle or a single value for a diamond or triangle.  For example, a size of (5,7) rectangle and a size of five for a diamond  and triangle will look like:

 

 

 

 

O O O O O O O       X               O     

O O O O O O O    X X X             O O O  

O O O O O O O X X X X X         O O O O O

O O O O O O O    X X X       O O O O O O O

O O O O O O O       X   O O O O O O O O O

 

The generation of the diamond shape was done in question 14* of the lab worksheet 2 for the command line. Only odd valued sizes will be used for the diamond and triangle (i.e. 1,3,5,….)  The distance between consecutive characters and rows on the screen will be a constant.  If they characters overlap, characters from one shape will directly cover characters from another shape i.e. the characters will be displayed as if on an evenly spaced grid.  The road surface has a given width and starts at the top of the screen.  The Road Condition shape objects will not necessarily cover the entire road.  For example, below are five road condition shapes with grid positions in a range 20 wide and 10 down: three rectangles, one diamond and one triangle, with two of the shapes as alerts:

 

    1 2  3  4 5  6  7 8 9 10 11 12 13 14 15 16 17 18 19 20

1 O O O O O O O      O     

2 O O O X O O O   O O O  

3 O O X X X O O O O O O O

4 O X X X X X O O O O O O O

5 O O X X X O O O O O O O O O

6 O O O X O X X X

7                 X X X

8       O O O X X X

9       O O O X X X

10     O O O O O

 

The user will be able to set the attributes of each of the shape objects: the character (‘O’ or ‘X’), the shape size and the shape location on the screen (e.g. the distances in character positions from the left and from the top), but cannot change the object type.

 

The Road Condition objects will have a Shape superclass that has the subclasses: Rectangle, Diamond and Triangle. 

 

Shape will be an abstract class and its subclasses will be concrete classes.

 

The user will be able to set the attributes of the Road Condition objects only when they are created and not after addition to the link list.  An identifier for the object sub-class should not need to be stored.

 

The user interface will be a menu having the following options:

 

Q - Quit: The program should end (without saving the Road Condition objects to a file).

I - Insert an object: The user should be prompted to enter a Road Condition object type and its attributes, and place the Road Condition object at the top of the linked list.

D - Delete an object: The user should be prompted to delete the Road Condition object from the top of the linked list.

C - Contents of the display: Display a list of all the Road Condition objects, their type and their attributes.

S - Save to file: Ask the user for a filename and append (add to the end of the file) all the Road Condition objects, from the linked list, and their attributes in that file in a suitable text format.

L - Load from file: Ask the user for a filename and load the Road Condition objects and their attributes from that file into the program’s linked list.  The Road Condition objects are added to those already in the program’s linked list.

R – Display: The user should be prompted to display (to the command line) all the Road Condition objects from the linked list in their correct locations and in the order from the linked list with the top object first (n.b. this function should not re-order the objects by date). HINT: one approach is to add the Road Condition objects to a string variable and display this to the command line.

 

N – Linear Search: Perform a linear search through the link list to find a Road Condition object by date and display its attribute values.  The linear search algorithm should use the algorithm specified in the lectures.

B – Binary Search: Perform a binary search through the link list to find a Road Condition object by date and display its attribute values.  The binary search algorithm should use the algorithm specified in the lectures.

T – Sort: Sort the Linked List so that the date attribute of each Road Condition object is increasing from the top of the link list.  The sort algorithm used should use the algorithm specified in the lectures.

 

After completion of each choice, other than Quit, the system waits for the user to press a key to return to the menu again.

 

The time taken to do the linear search, binary search and sort functions should be displayed when each function has been completed.  The time must be calculated using the clock timer from the lectures. 

 

Your report section ‘Evaluation of the program’ (see below) should include an evaluation of the implementation and performance gain of a binary search with a sort compared with a linear search for the type of link list used in this specification.  This section should also discuss the appropriateness and limitations of using a binary search.

 

An interface will be required to perform the functionality above.  Clarity, performance and simplicity should be considered in the interface design.

 

Additional Program Design Requirements Specification

 

1.    There will be base class named Shape. The display of the Road Condition objects will use a class RCDataManager that has a linked list containing pointers to Shape objects. Dynamic memory for the objects will be allocated/deallocated with new and delete.

2.    The RCDataManager class will use a linked list to store the Road Condition objects.  The linked list will have a List class and a Link class which should be adapted from those used in lecture 8 and lab 8 or lecture 11 and lab 11.

3.    A file created by you containing at least one of each type of Road Condition objects should be submitted with the code.  This file should be associated with your test plan and enable testing of all the functions.

4.    A file of 1000 transactions will be supplied with this specification.  This is to test the performance of the link list searches and sorting by recording the time taken for doing: a linear search on the original file data; a sort on the original file data; a binary search on the original file data following the sort.

5.    Code given in the lectures should be used to perform the algorithms for linear search, binary search and sort, and the timer function.

C.    Report Specification

The report about the design and testing of your program should start with a title, your student id, module name and id, and the following four sections:

Explanation of the Design of the Program

This section, which should be no longer than two pages, should describe the design of your source code and how it works. (You will provide a listing of your source code in Appendix A). This explanation should be based on your classes, class operations, class attributes, and how these produce your program’s functionality.

Test Plan and Results

This section should contain: a series of tests and expected outcomes; the results of running these tests; an evaluation of the test results.  The tests should relate to the list of function requirements in Section B.

Evaluation of the Program

This section, which should be no longer than one page, should state the success of the program.

Appendix: Full Source Code Listing

This section should contain all your source code for the program.  The files that you wrote should be included but not standard C++ header or library content.

 

D.   Summary of Requirements

 

Report on Design and Testing

Percentage

Explanation of Design of the Program

Test Plan and Results

Evaluation of the Program

15%

Appendix A – Full source code listing provided

If not included, the whole program will be given a fail grade

 

 

C++ Program

Percentage

Does the program compile on Visual Studio 2017

If not, the whole program will be given a fail grade

Adherence to a Coding Standard, code structure,

use of Classes and File Structure

5%

Functions working:

Q: ‘QUIT’

I: ‘INSERT’

D: ‘DELETE’

C: ‘CONTENTS’

S: ‘SAVE’

L: ‘LOAD’

R: ‘DISPLAY’

 

35%

INHERITANCE USED APPROPRIATELY

USES LINKED LIST CORRECTLY

TEST FILE READ CORRECTLY

25%

Advanced Functions Working:

 

N – Linear Search and timed correctly

B – Binary Search and timed correctly

T – Sort and timed correctly

 

15%

Lab Worksheet Starred Questions in Dropbox on time

5%


 


51作业君 51作业君

扫码添加客服微信

添加客服微信: IT_51zuoyejun