C++

Minimum Requirements:

Satisfied Y/N

UML diagram

Yes

Documentation asked for: Design outline including justification/rationale

Yes

Doxygen output

Yes

Program that builds and runs.

Yes

Source code with doxygen style comments. (soft copy only)

Yes

Test plan and output of test run(s)

Yes

Executable program with associated data files in a separate directory called “executable”. Make sure that the executable runs on a machine which does not have a compiler.

Yes

A declaration indicating what works and what does not work in your program. This can form the summary of your test plan and output of test runs and should be provided as a separate document called “evaluation.txt”

Yes

Components

Comments

UML diagram

UML is fine. All good.

Written rationale for the design + algorithm

Rationale for the maps is fine. It is a shame you didn't use your tree, because there is quite a heavy mark reduction for not using the required structures.

The templated BST is in the textbook. Should have attempted the lab exercise on trees first. This lab exercise had to be done anyway as it was assessed. If the lab exercise had been done, you would have worked out the operation of the BST much earlier and would have been able to incorporate the BST into the assignment.

There are plenty of options for combining the 2 structures; store dates in the tree, map dates to readings; store readings in the tree, map readings to dates; map dates with time/max reading. It didn't have to be cleanest answer, even if the rationale behind why you map/tree something seemed illogical, it still would have been better than getting the -30 marks for not doing it.

Algorithm is concise and clear; all good.

Program including coding style and comments

I was nearly going to put a no next to the doxygen minimum requirement, but then I found it pretty well hidden in your VS project files. I would have moved that to a more obvious location before submission. That said, your doxygen comments are good.

I get an assertion error while attempting to load the input data. But, this does correlate with your test data. Unfortunately though, it makes it hard to test to see if your application is functioning correctly or not.

Your coding style is okay. I only found one instance of an attribute without an obviously clear name, which was “ m” in your main application. That could be anything at a glance. It was a monthly reading though, so something like monthlyReading is much clearer.

Test plan and testing

To be honest, it is good to see someone who actually puts their failed test results in as well. It looks a lot more authentic to have tests that fail, because in the real world it happens all the time.

You made a comment about your test programs. I really needed to see the test outputs from the application as well to correlate them against the test plans. Since you have a column that says output in your test plans I am going to presume that was copied for application outputs.

Minimum Requirements:

Satisfied Y/N

UML diagram

Yes

Documentation asked for: Design outline including justification/rationale

Yes

Doxygen output

Yes

Program that builds and runs.

Yes

Source code with doxygen style comments. (soft copy only)

Yes

Test plan and output of test run(s)

Yes

Executable program with associated data files in a separate directory called “executable”. Make sure that the executable runs on a machine which does not have a compiler.

Yes

A declaration indicating what works and what does not work in your program. This can form the summary of your test plan and output of test runs and should be provided as a separate document called “evaluation.txt”

Yes

Components

Comments

UML diagram

Concise and clear. Where are the details for BST and BSTNode in the UML?

Written rationale for the design + algorithm

Perfectly fine rationales behind the use of the data structures.

From your rationales I can already see inconsistencies with method names though; start with capitals or lower case?

Program including coding style and comments

Where's your Code::Blocks project file? I had to create the project myself to see if it builds correctly. You had it in assignment 1's submission. I shouldn't have to add to a students submission to see if minimum requirements are meet (builds on VS or C::B). As it is the first time you have done this, I'll just give you a warning about it. Always submit the project files as well.

Your BST and BSTNode classes stand out from the rest of the project. Lack of UML data, lack of doxygen comments, and mostly written in a different coding style (different naming conventions for parameters, method, and attributes; different location for the { in the code blocks).

The inconsistencies of the BST and BSTNode classes can invite questions as to the authorship of these classes. If the code was sourced elsewhere and not referenced, it becomes plagiarism. Although I don't wish to imply that the BST code was sourced from elsewhere, it is inconsistent with the rest of the project, making it stand out. If say, for example, you get code examples from books, use them, and reference them. For example, BST code from the textbook could have been used and referenced.

Check you BST’s destructor. Deleting the root node doesn’t delete the tree. Please see the textbook which shows how this is done.

It does not make sense to expose the internals of the BST with a public getroot() method. Makes a mockery of the encapsulation that is done via the class mechanism.

The class declaration doxygen comments are good, but they should go directly before the declaration in your source. For example:

#include “someheader.h”

using namespace somenamespace;

/**

* @class example

* etc ..

*/

class MyClassName {};

The rest of your doxygen comments are very brief; just in the form of single line /// comments. There is a good example of a doxygen comments on the unit website @ Practice/DoxyExample/unzipped/ModelFile.h.

Generally, your code in clear enough to be read by a third party, so that's all good. It is important to focus writing readable code first.

Program execution is fine. No issues there.

Test plan and testing

Your test plans are fairly brief, but structured okay. I would have tried to have had a bit more detail here where possible.

Minimum Requirements:

Satisfied Y/N

UML diagram

Yes

Documentation asked for: Design outline including justification/rationale

Yes

Doxygen output

Yes

Program that builds and runs.

Yes

Source code with doxygen style comments. (soft copy only)

Yes

Test plan and output of test run(s)

Yes

Executable program with associated data files in a separate directory called “executable”. Make sure that the executable runs on a machine which does not have a compiler.

Yes

A declaration indicating what works and what does not work in your program. This can form the summary of your test plan and output of test runs and should be provided as a separate document called “evaluation.txt”

Yes

Components

Comments

UML diagram

Your UML is simple, but accurately reflects your classes in your project. All good.

Written rationale for the design + algorithm

Although I feel the goals that your maps achieve could be handled by data validation in the date class, your rationale behind why you chose to implement your maps in a certain way is sound. So no issues there at all.

What I am having trouble finding is a rationale for why your tree contains the data it does. I may be missing something, but I read the Use of Data Structures: Maps & Binary Trees section twice, and the first two paragraphs state that the assignment needed a BST and that you had created one.

So I had a look at CustomeBinaryTree, and I see a lot of how, but not really why, it stores the data it does. I'm sure this only a misinterpretation of what you are trying to express. I'm not marking you down for it, but personally I feel it could have been stated clearer.

Program including coding style and comments

I had fun typing long sentences in the menu and watching the error message spam for every character in the sentence. It's good though, because the

application didn't break with inaccurate inputs.

Took me awhile to workout that when your asking the user to enter the month, they need to enter it as a word. Which is fine, but there would have to be a note for the user about the format for data input.

Other than that, your application works as intended. All good.

Your doxygen comments are nicely detailed, so that is all good too.

Test plan and testing

This is really good here. Lots of detailed testing. The test plans are fleshed out; the outputs are shown; each unit has been tested individually.

Probably not the most exciting part of a project to excel at, but your testing documentation is very good.

Minimum Requirements:

Satisfied Y/N

UML diagram

Yes

Documentation asked for: Design outline including justification/rationale

Yes

Doxygen output

Yes

Program that builds and runs.

Yes

Source code with doxygen style comments. (soft copy only)

Yes

Test plan and output of test run(s)

Yes

Executable program with associated data files in a separate directory called “executable”. Make sure that the executable runs on a machine which does not have a compiler.

Yes

A declaration indicating what works and what does not work in your program. This can form the summary of your test plan and output of test runs and should be provided as a separate document called “evaluation.txt”

Yes

Components

Comments

UML diagram

UML looks fine. Had to really zoom in though to make it out -_-

Written rationale for the design + algorithm

It's good that you reference self-balancing trees. Everything comes at a cost though; self-balancing trees take much longer to input data as the tree is rearranging itself after each insert.

Rock solid rationale for your tree and map.

Clear, meaningful names for your methods and attributes. All good there.

Algorithm is good. It's quite long and detailed, but that's no issue.

Program including coding style and comments

Yes I did have the side-by-side configuration error again. But it's okay because you mentioned it in your evaluation document. But you do need to get this fixed.

Doxygen comments are good. I can see you have adjusted the little things from the first assignment, so no issues here whatsoever.

I like that you have extended the menu options to add more functionality. It's simple but effective.

I think your coding standard for a 2nd year unit is very good. Meaningful names, clear program flow, well commented; all good. But I have to pick on you for something, so I'd say more use of the const keyword. In particular after method declarations.

For example:

void IDontChangeAnything() const; and

void IChangeSomethingSoNotConst( const int& valueThatDoesntChange);

All things considered it is a minor consideration.

Test plan and testing

Test plan is good. The test methods correlate to the outputs. All good.

Minimum Requirements:

Satisfied Y/N

UML diagram

No

Documentation asked for: Design outline including justification/rationale

Yes

Doxygen output

Yes

Program that builds and runs.

Yes

Source code with doxygen style comments. (soft copy only)

Yes

Test plan and output of test run(s)

Yes

Executable program with associated data files in a separate directory called “executable”. Make sure that the executable runs on a machine which does not have a compiler.

Yes

A declaration indicating what works and what does not work in your program. This can form the summary of your test plan and output of test runs and should be provided as a separate document called “evaluation.txt”

Yes

Components

Comments

UML diagram

This is, rather unfortunately, what I see in your documentation:

Two large blank squares. You probably have done your UML and attempted to insert the images, but as I cannot see them at present, I will have to mark it down as a missing requirement. You could have provide the uml as a separate file and referred to this file in your write up.

Written rationale for the design + algorithm

As with the first assignment, having identifiers on your private member attributes (the m_) is very useful for people reading your code.

Although brief, and not actually under the section Written Rationale, I found a rationale behind why you used your map and tree the way you did. Which is good, as it was a requirement (the paragraph at the end of 5. Program).

Rationales are all good.

Algorithm is good too; no dramas.

Program including coding style and comments

Avoid using #define and global variables where possible. For starters, number of months is never going to change, also the months array is only used in 2 places; month_str_to_int and month_int_to_str. You could have mapped the date strings to integer values in your main, or possibly considered an enumerator to represent the months.

Your BST class uses a different naming convention to the rest of your classes. Also, add doxygen comments for your private methods as well. Other than that, no issues with your doxygen comments/outputs.

The program runs good. I'm not very concerned about how fast the application runs, as long as it runs correctly, which is seems to do. All good there.

Test plan and testing

No pass/fail column for your test plans? Other than that, your test plans and outputs are good.

Minimum Requirements:

Satisfied Y/N

UML diagram

Yes

Documentation asked for: Design outline including justification/rationale

Yes

Doxygen output

Yes

Program that builds and runs.

Yes

Source code with doxygen style comments. (soft copy only)

Yes

Test plan and output of test run(s)

Yes

Executable program with associated data files in a separate directory called “executable”. Make sure that the executable runs on a machine which does not have a compiler.

Yes

A declaration indicating what works and what does not work in your program. This can form the summary of your test plan and output of test runs and should be provided as a separate document called “evaluation.txt”

Yes

Components

Comments

UML diagram

Your UML is fine, but I can see inconsistencies in naming conventions for methods in the BST. Methods start with upper-case or lower-case? Either is correct, just be consistent.

Written rationale for the design + algorithm

Although you offer a rationale behind why some private attributes in the Power class are prefixed with m_ and some are not, they are still all private attributes and the m_ would identify that clearly to anyone reading your code. I recommended staying consistent with that in the future. Same thing with your node in BST.

Your rationales are fine, but it is bit long winded. Scientific documentation tends to be brief and concise (we're too easily distracted by shiny things and buttons). Leave the 3000 word essays to the Law students. It will save yourself a lot of typing on future assignments =)

A good example is your BST/Map rationale. If you supplied the list and reworded it slightly to express reasoning as well as purpose, that would be all you need.

Algorithm is good. Clear and concise.

Program including coding style and comments

#pragma are Visual Studio directives; they aren't portable to other compilers. Also, suppressing a warning instead of fixing it is like hiding the body under your bed and just hoping it will go away.

While we're on portability and re-use, the very first line of your program calls a batch file to execute a DOS command to generate a directory listing. Obviously this greatly reduces the portability of the code and also making the application dependant on the BAT file for operation.

Here is a C example of reading a directory listing: http://www.dreamincode.net/code/snippet2295.htm .

All those global variables again. The 101 Coding Standards #18 states: Declare variables as locally as possible. You had already written it for the first assignment and I wouldn't expect you to change previous work, but by having a line in your evaluation.txt document like, “I am aware that my global variables should be local variables, as per 101 coding standards”, completely covers you. It shows that you are aware of the issue, even if the issue hasn't been rectified directly.

Doxygen comments are good. All good there.

Test plan and testing

“Your evaluation documentation does not list what does and does not work in your program. If you feel your submission is working as intended then include something like, “All required features implemented and working.” in future submissions.” - quoted myself from your assignment one feedback.

Good test plan; simple and clear.

Minimum Requirements:

Satisfied Y/N

UML diagram

Yes

Documentation asked for: Design outline including justification/rationale

Yes

Doxygen output

Yes

Program that builds and runs.

Yes

Source code with doxygen style comments. (soft copy only)

Yes

Test plan and output of test run(s)

Yes

Executable program with associated data files in a separate directory called “executable”. Make sure that the executable runs on a machine which does not have a compiler.

Yes

A declaration indicating what works and what does not work in your program. This can form the summary of your test plan and output of test runs and should be provided as a separate document called “evaluation.txt”

Yes

Components

Comments

UML diagram

Brief, accurate and detailed. All good.

Written rationale for the design + algorithm

I noticed your deleteNode method is not implemented. Delete node is also in the textbook. There is a fair amount of detail with diagrams, algorithm and code.

Also see http://www.algolist.net/Data_structures/Binary_search_tree/Removal . It has pictures and code examples.

What are you mapping your CollectedRecord struct to in your map in your rationale description? Record holds the date, units, time of max output, and max output; what is in the rest of the map?

Good clear method names in your design.

Algorithm is clear. All good there too.

Program including coding style and comments

Once again, no issues with the comments / doxygen ouput.

Menu is fine. Program functions accurately. No issues there.

Same as what I said in the first assignment; having the application as an interface shows a good understanding of object-orientation concepts. Having completed the games units your code is clear and well structured from experience with coding now.

In your BST I would have avoided C-style #defines of values. Consider possibly using a enum for the same result (your custom method can return enum values instead). It's not technically wrong by any means, only a suggestion.

Test plan and testing

This is more of a general formatting thing with your documentation than an issue with the way the information is presented, but using page breaks here so that each test starts on a new page would have made it look at lot clearer and easier to read.

Your test information is there, but it's not really structured in a test plan. Topic 8 has an example test plan document (the XLS link).

Minimum Requirements:

Satisfied Y/N

UML diagram

Yes

Documentation asked for: Design outline including justification/rationale

Yes

Doxygen output

Yes

Program that builds and runs.

Yes

Source code with doxygen style comments. (soft copy only)

Yes

Test plan and output of test run(s)

Yes

Executable program with associated data files in a separate directory called “executable”. Make sure that the executable runs on a machine which does not have a compiler.

Yes

A declaration indicating what works and what does not work in your program. This can form the summary of your test plan and output of test runs and should be provided as a separate document called “evaluation.txt”

Yes

Components

Comments

UML diagram

UML is good. Relationships are accurate, public/private/protected is all accurately depicted, and attribute/method names correlate to your classes. So all good.

Written rationale for the design + algorithm

From assignment2.pdf; “ You must use the Binary search

tree data structure and the STL map (and/or multimap) data structure. You need to identify where these

data structures can be used and provide a rationale for their use. There is a 30 marks penalty if you do

not do this.”.

This is your rationale for the map and bst:

map<int,Record>; STL Template class; public;

Stores elements formed by the combination of a key value and a mapped value.

BinarySearchTree<int>; Template class; public;

Stores int elements in an ordered tree stucture. Used for fast searching.

You need to tell us why you are using these two structures in the way you are. What is the integer value stored in the map and the tree? Why is that integer mapped to a Record? What is a Record? There just isn't enough here to get around the -30 mark hit. See note at the bottom about penalties.

The rest of your rationales are fine.

Algorithm is good.

Program including coding style and comments

Tried putting invalid data inputs into your application. It didn't break it, but for example, if I put the word 'dog' in when the application is asking me to input a value to test against, then it treats each individual char in the string as a separate input, and loops through the process multiple times.

Data validation wasn't a requirement of the application, so it's not a big issue; just noting it. Otherwise your application seems to behave itself.

Once again your doxygen comments are very brief (see what I did there O_o). It's fine for the submission, but I was really hoping you would flesh the comments out with more details. There is a good example header file on the unit website @ Practice/DoxyExample/unzipped/ModelFile.h.

Your coding style is very good. Good use of the const keyword in particular. Clear, concise, easy to read; everything code should be really.

Test plan and testing

Test plans are clear; good. Outputs correlate. No dramas here at all.