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:
·
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:
·
·
·
·
·
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:
·
·
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% |
