For activity 2d, you need to submit the 4 C++ files in 5.1 Activities for Questions 3 and 4 by August 18 (Sunday). There should be no errors in the C++ files (*.cpp). There are no programming activities to be submitted in 5.2 as these are done during class time.
Place comments (using the double slash //) on:
(a) the error where you have corrected in the code, and
(b) what kind of error (compile-time error, link-time error, run-time error, or logical error) you have corrected.
This will also help you practice placing comments when you submit your Assessment 3. The comments in Assessment 3 will help act as your documentation for that activity.
Remember to save your program files as *.cpp and/or *.h. Please send in the "Assessment 2d - Submission" and attach it as a zip file. Please use the naming convention MIS501_T2_ Asessement_2d.zip likeMIS501_T2_Infante_William_Asessement_2d.zip
14/08/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_75722_1&content_id=_7771615_1&mode=reset 1/9 MODULE 5.1 - PROBLEMS IN COMPUTERMODULE 5.1 - PROBLEMS IN COMPUTER PROGRAMMINGPROGRAMMING The �rst thing you should attempt in this module is the �rst learning activity or engage in an in-class activity about the concept of ambiguity. You should then review the �rst reading (video): This reading details the spectacular failure at NASA in 1999 that was caused by two interpretations: one party assumed the metric measurement system whereas the other assumed the imperial measurement system. It is an extreme example of the potential fallout from failures of software testing and cost the US government $193 million. For greater detail and learning from the failure, then review the second reading. The opening case study in this �rst half of the module highlights that even the hallmark of scienti�c precision and the uno�cial benchmark many people would have for brilliance in science—NASA—and the epitome of human endeavour—space exploration—is not immune from systems problems. It also highlights the truism that failures are not the fault of the system, but the people who built it. Let’s unpack that thought for a short moment: In an earlier module, we learned about algorithms and that they are the building blocks of programming code. Whenever a programmer is given a task, the �rst step in developing the software is to consider the algorithmic sequence �rst so that she can get an understanding of the task before translating it into the required programming language(s). Human beings are capable of questioning a set of instructions given to them, if the instructions do not make sense. If they do, human beings generally use their intuition or their foresight capabilities to ‘see’ if a set of instructions do not make logical sense. 14/08/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_75722_1&content_id=_7771615_1&mode=reset 2/9 Instead of questioning the instructions, human beings possess the intelligence to make necessary adjustments to correct for logical errors, potentially bypassing the questioning phase. But computers do not possess such intelligence and are only capable of following the instruction set given to them. As you will recall from earlier discussions, one of the key features of algorithms—and, in turn, computer execution—is sequence. That means that a computer will follow the instruction set given to it exactly, in the exact sequence it is given in and it will not question the underlying logic; it will do exactly as it is told! Therefore, getting the software development task right de�nitely includes the role of the programmer, but also the systems- and business analysts and project managers who were involved in eliciting the requirements, and also the managers who oversee the development of people that perform the development tasks. It is incumbent on you, the programmer, then, to ensure your code meets the requirements handed to you. There are other considerations as we will begin to consider in this module. 5.1.1 Error Types and Error Checking By now, you will be no-doubt used to your compiler throwing any number of errors at you while you attempt to compile your program. These errors are normally borne from syntactical errors in your code— where you have not used a semicolon to terminate statements, or have attempted to use a variable that was not previously declared. In the early days of computing, systems were not like the laptop, phone or tablet you might be reading this on. Instead, computer machines were enormous and were made of vacuum tubes, consumed huge amounts of energy and were mercilessly complex to program. Programs were fed into computers in the form of punched cards. Sometimes the card-based programs were hundreds of cards long and needed to be fed into the machine in the exact order! If they fell out of order, it could be 14/08/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_75722_1&content_id=_7771615_1&mode=reset 3/9 chaotic to re-order as the programmer would need to retrace their steps to discover the correct order of the program. Even after this reordering, sometimes the computer would malfunction or otherwise produce results that were unexpected. At times, it was discovered that bugs had found their way into the vacuum tubes or the areas around the transistors and that they microbic bodies had shorted the circuitry. Thus, the colloquial term “bugs in the system” was borne. Today, we still use the term ‘bug’ to mean that there is something unidenti�ed in the program logic that is causing the execution to result in unexpected results. Let’s review the third reading (video): The reading (video) demonstrates a number of di�erent types of errors: compile time, link time, run time and logic errors. Each of them is demonstrated one by one. Note that a ‘logic error’ occurs because the algorithm that was in the program did not account for the possibilities that the user might input or not input into the program. Let’s use the following example algorithm to illustrate our point about logic errors. Begin average = 0 running_total = 0 number_count = 0 While numbers are accepted from the keyboard add number to running_total add one to number_count EndWhile average = running total / count of number print average to screen End. This algorithm sets three variables, average, running_total and number_count, to zero and then accepts numbers from the keyboard until the user is �nished inputting numbers. As it does this, the algorithm adds the given number to the running_total variable and increments the number_count variable. When the user has �nished entering the numbers, the algorithm then calculates the average variable, which is 14/08/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_75722_1&content_id=_7771615_1&mode=reset 4/9 de�ned as the quotient of the running total and the count of entered numbers. The problem with this algorithm lies in its logic. If no numbers are entered, the ‘while’ loop will not be executed and the variables— running_total and number_count—will remain set to 0. The entity following the algorithm will then attempt to calculate the average by dividing 0 by 0. We know that anything divided by 0 is not de�ned and so the value assigned to the average variable will be an error, which will then be printed to the screen. If it was a computer program that was running the code, the code would throw an error and the program would be terminated by the operating system before it was able to print anything to the screen. Technically, this is a run-time error, a type of program ‘bug.’ A copy of such a C++ program is provided here. This is our �rst instance of a logical error and needs to be corrected. A better way of writing the algorithm would be as follows: Begin average = 0 running_total = 0 number_count = 0 While numbers are accepted from the keyboard add number to running_total add one to number_count EndWhile If something was entered at the keyboard average = running total / count of number print average to screen EndIf. End. As you will recall from our earlier discussion of sequence, selection and iteration, now the average calculation and printing that calculation will only execute if there was something actually captured from the keyboard. There is now no execution path provided if nothing was captured from the keyboard. Therefore, the algorithm is prevented from https://en.wikipedia.org/wiki/Division_by_zero https://laureate-au.blackboard.com/bbcswebdav/xid-19037283_1 14/08/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_75722_1&content_id=_7771615_1&mode=reset 5/9 attempting to execute a calculation that would put it in danger of throwing an error. The example provided just now was one where a logical error, or a ‘bug’ existed in the algorithm. If we were to convert the �rst version of it to C++ code, compile and run it, it would happily run so long as the user entered numerical data at the keyboard. If they did not, the program would throw a divide-by-zero error and terminate. The example provided also illustrated how we go about ‘debugging’ our program so that the bug no longer exists. We were able to introduce an element of error-checking to eliminate the bug. You have already been doing error-checking at compile time; the third reading (video) demonstrated the extent that compile time errors may pervade your programming. The compiler is very good at highlighting to you where your syntactical error has occurred. It normally provides the line number and, often, the character number where the error was detected and then provides a description of the error. The more experience you get in �xing compiler errors, the easier it becomes to trace your steps and to quickly identify where you went wrong and to correct it very quickly. The other type of error, run-time error is one that occurs despite the program compiling without error and could be due to the way that your program handles memory management or other technical elements, such as the divide-by-zero error we discussed earlier. A run-time error is a type of bug and the other is a logical error, so called because the program compiles and runs without error but it nonetheless produces unexpected results. 5.1.2 Bugs and Debugging As we saw already in the previous sub-section, errors in programming code—especially in C++ programming—in one or more of the following ways: compile time errors – these are typically problems with the syntax or spelling of variables and can be �xed most helpfully as the 14/08/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_75722_1&content_id=_7771615_1&mode=reset 6/9 compiler often describes the error at the time you’re attempting to compile the program; link time errors – these are typically problems that occur when you are attempting to link your program to other modules, functions or �les that may or may not have already been themselves compiled. Like compile time errors, these are generally easily �xed because the compiler lets us know when it cannot make the link; run time errors – these are harder to identify because the compiler will have compiled the program if it is running. A running program may come into problems if it is dealing with data given to it externally and has not been designed to handle that data; and logic errors – these are the hardest type of errors to correct because the program has compiled and there are no run-time errors, but the program still results in confusing or unexpected output. In this subsection of the module we put our focus and attention toward discovering and �xing logic errors. We already discussed earlier in this half of the module that a ‘bug’ refers to an as yet unidenti�ed error in the program. We say that it is unidenti�ed because the compiler did not identify the error, which means that it has nothing to do with syntax or linking between modules of the program; it has to do with the logic you