Programming Assignment 3COVID Testing

Programming Assignment 3
COVID Testing

QQ1703105484

Introduction

In response to the emergence of the novel coronavirus, testing has become widely available with results being shared in the community to help it track and monitor the extent of the problem.

For this assignment, suppose that a sensor is recording virus test results in batches in a results string.  For example, 

    R2+1-1
 

would indicate that a single batch of two tests are being reported with one test being reported as positive for the virus and one test being reported as negative for the virus.  From this information, note that the character R is being used to start a batch of test results, the character + is being used to identify positive results and the character - is being used to report negative results.  More than one batch of results can be reported in a single results string.  For example,

    R2-1+1R5+3-2
 

would indicate two batches of results, one with two test results and one with five test results with a total of four positives tests and three negative tests being reported.  

Precisely, to be a valid test results string, 

- a batch of results must begin with the character R
- a batch of results must report both a positive and negative number of test results with + and - in either order
- no leading zeros are allowed in any numeric value being reported
- the total number of tests in a batch must equal the number of positive and negative test results
- a single result string may include multiple batches of results

All of the following are examples of valid result strings:
 

• R1+0-1R1-0+1               (two batches of results, two total tests being reported, one being positive, one being negative)
• R5-2+3                            (one batch of results, five total tests being reported, two being negative, three being positive)

All of the following are examples of invalid result strings:

• r1+0-1                              (batch must be reported with R)
• R1+-1                               (a number of positive tests is required)
• R1+1-                               (a number of negative tests is required)
• R1+0-1   asdfR               (extra characters not allowed)
• R5+00003-0002          (leading zeros not allowed)
• R5+0-0                           (positive and negative results must equal the total number of tests being reported)

Your task

For this project, you will implement the following five functions, using the exact function names, parameter types, and return types shown in this specification. (The parameter names may be different if you wish).

bool isValidResultString(string results)

This function returns true if its parameter is a well-formed test result string as described above, or  false otherwise.

int positiveTests(string results)

If the parameter is a well-formed test result string, this function should return the total number of positive tests from all the batches being reported in the string.  If the parameter is not valid, return -1 . 

int negativeTests(string results)

If the parameter is a well-formed test result string, this function should return the total number of negative tests from all the batches being reported in the string  If the parameter is not valid, return -1.   

int totalTests(string results)

If the parameter is a well-formed test result string, this function should return the total number of tests being reported from all the batches in the string.  If the parameter is not a valid, return  -1.  
 

int batches(string results)

If the parameter is a well-formed test result string, this function should return the total number of batches being reported in the string.  If the parameter is not a valid, return  -1.  

These are the only five functions you are required to write. Your solution may use functions in addition to these five if you wish. While we won't test those additional functions separately, using them may help you structure your program more readably. Of course, to test them, you'll want to write a main routine that calls your functions. During the course of developing your solution, you might change that main routine many times. As long as your main routine compiles correctly when you turn in your solution, it doesn't matter what it does, since we will rename it to something harmless and never call it (because we will supply our own main routine to thoroughly test your functions).

 

Clearly, I am expecting the last four functions to invoke the first function as they complete their assigned task.  This code reuse is one of the major benefits of having functions.  So please do that.

 

Before you ask a question about this specification, see if it has already been addressed by the Project 3 FAQ. And read the FAQ before you turn in this project, to be sure you didn't misinterpret anything.  

Programming Guidelines

The functions you write must not use any global variables whose values may be changed during execution (so global constants  are allowed).

When you turn in your solution, none of the five required functions, nor any functions they call, may read any input from cin  or write any output to  cout. (Of course, during development, you may have them write whatever you like to help you debug.) If you want to print things out for debugging purposes, write to cerr  instead of cout. cerr  is the standard error destination; items written to it by default go to the screen. When we test your program, we will cause everything written to cerr  to be discarded instead — we will never see that output, so you may leave those debugging output statements in your program if you wish.

The correctness of your program must not depend on undefined program behavior. For example, you can assume nothing about  c 's value at the point indicated, nor even whether or not the program crashes:

         int main()

         {

             string s = "Hello";

             char c = s[5];   // c's value is undefined

             …

Be sure that your program builds successfully, and try to ensure that your functions do something reasonable for at least a few test cases. That way, you can get some partial credit for a solution that does not meet the entire specification.

There are a number of ways you might write your main routine to test your functions. One way is to interactively accept test strings:

         int main()

         {

             string s;

           cout.setf( ios::boolalpha ); // prints bool values as "true" or "false"

            for(;;)

            {

                cout << "Enter a possible result string: ";

                getline(cin, s); if (s == "quit") break;

                cout << "isValidResultString returns ";

                   cout << isValidResultString(s) << endl;

                cout << "positiveTests(s) returns ";

                cout << positiveTests(s) << endl;

                cout << "negativeTests(s) returns ";

                cout << negativeTests(s) << endl;

                cout << "totalTests(s) returns ";

                cout << totalTests(s) << endl;

                cout <<< "batches(s) returns ";

                cout << batches(s) << endl;

             }

            return( 0 );

         }

While this is flexible, you run the risk of not being able to reproduce all your test cases if you make a change to your code and want to test that you didn't break anything that used to work.

Another way is to hard-code various tests and report which ones the program passes:

         int main()

         {

             if (!isValidResultString(""))

                   cout << "Passed test 1: !isValidResultString(\"\")" << endl;

             if (!isValidResultString("   "))

                   cout << "Passed test 2: !isValidResultString(\"   \")" << endl;

            

            return( 0 );

        }

This can get rather tedious. Fortunately, the library has a facility to make this easier:  assert . If you #include the header <cassert> , you can call assert  in the following manner:

         assert(some boolean expression);

During execution, if the expression is true, nothing happens and execution continues normally; if it is false, a diagnostic message is written to cerr telling you the text and location of the failed assertion, and the program is terminated. As an example, here's a very incomplete set of tests:

         #include <cassert>

         #include <iostream>

         #include <string>

         using namespace std;

         …

         int main()

         {

int main()

         {

            assert( isValidResultString("") == false );

            assert( isValidResultString("    ") == false );

            assert( positiveTests( "    " ) == -1 );

            assert( negativeTests( "      " ) == -1 );

            assert( totalTests( "      " ) == -1 );

            assert( batches( "      " ) == -1 );

            assert( isValidResultString( "R2+1-1" ) == true );

            assert( positiveTests( "R2+1-1" ) == 1 );

            assert( negativeTests( "R2+1-1" ) == 1 );

            assert( totalTests( "R2+1-1" ) == 2 );

            assert( batches( "R2+1-1" ) == 1 );

             cerr << "All tests succeeded" << endl;

            return( 0 );

         }

             assert( isValidResultString("") == false );

             assert( isValidResultString("    ") == false );

            assert( positiveTests( "    " ) == -1 );

            assert( negativeTests( "      " ) == -1 );

            assert( totalTests( "      " ) == -1 );

            assert( batches( "      " ) == -1 );

            assert( isWellFormedGroceryOrderString( "R2+1-1" ) == true );

            assert( positiveTests( "R1+1-1" ) == 1 );

            assert( negativeTests( "R1+1-1" ) == 1 );

            assert( totalTests( "R1+1-1" ) == 2 );

            assert( batches( "R1+1-1" ) == 1 );

             cerr << "All tests succeeded" << endl;

            return( 0 );

         }

The reason for writing one line of output at the end is to ensure that you can distinguish the situation of all tests succeeding from the case where one function you're testing silently crashes the program.

What to turn in

What you will turn in for this assignment is a zip file containing these two files and nothing more:

1. A text file named covid.cpp  that contains the source code for your C++ program. Your source code should have helpful comments that tell the purpose of the major program segments and explain any tricky code. The file must be a complete C++ program that can be built and run, so it must contain appropriate #include lines, a main routine, and any additional functions you may have chosen to write.
2. A file named report.doc  or report.docx (in Microsoft Word format) or report.txt  (an ordinary text file) that contains in addition your name:
   1. A brief description of notable obstacles you overcame.
   2. A description of the design of your program. You should use  pseudocode in this description where it clarifies the presentation.
   3. A list of the test data that could be used to thoroughly test your program, along with the reason for each test. You don't have to include the results of the tests, but you must note which test cases your program does not handle correctly. (This could happen if you didn't have time to write a complete solution, or if you ran out of time while still debugging a supposedly complete solution.)

Turn in the file by the due time above. Give yourself enough time to be sure you can turn something in, because we will not accept excuses like "My network connection at home was down, and I didn't have a way to copy my files." There's a lot to be said for turning in a preliminary version of your program and report early (You can always overwrite it with a later submission). That way you have something submitted in case there's a problem later. Notice that most of the test data portion of your report can be written from the requirements in this specification, before you even start designing your program.