how to gauge repair risk
play

How to Gauge Repair Risk? We Need to Gauge . . . First Risk Factor: - PowerPoint PPT Presentation

Traditional Approach . . . Static Analysis Tools Some Defects . . . Correcting Non- . . . How to Gauge Repair Risk? We Need to Gauge . . . First Risk Factor: How . . . Francisco Zapata 1 and Vladik Kreinovich 2 Second Risk Factor: . . .


  1. Traditional Approach . . . Static Analysis Tools Some “Defects” . . . Correcting Non- . . . How to Gauge Repair Risk? We Need to Gauge . . . First Risk Factor: How . . . Francisco Zapata 1 and Vladik Kreinovich 2 Second Risk Factor: . . . Resulting Criteria for . . . 1 Department of Industrial, Need to Go Beyond . . . Manufacturing, and Systems Engineering 2 Department of Computer Science Home Page University of Texas at El Paso Title Page 500 W. University El Paso, Texas 79968, USA ◭◭ ◮◮ fazg74@gmail.com, vladik@utep.edu ◭ ◮ Page 1 of 43 Go Back Full Screen Close Quit

  2. Traditional Approach . . . Static Analysis Tools 1. Traditional Approach to Software Testing Some “Defects” . . . • The main objective of software is to compute the de- Correcting Non- . . . sired results for all possible inputs. We Need to Gauge . . . First Risk Factor: How . . . • From this viewpoint, a reasonable way to test the soft- Second Risk Factor: . . . ware is: Resulting Criteria for . . . – to run it on several inputs for which we know the Need to Go Beyond . . . desired answer, and Home Page – to compare the results produced by this software Title Page with the desired values. ◭◭ ◮◮ • This was indeed the original approach to software test- ◭ ◮ ing. Page 2 of 43 Go Back Full Screen Close Quit

  3. Traditional Approach . . . Static Analysis Tools 2. Experts Can Detect Some Software Defects With- Some “Defects” . . . out Running the Program Correcting Non- . . . • Once it turns out that on some inputs, the program is We Need to Gauge . . . not producing the desired result, the next step is: First Risk Factor: How . . . Second Risk Factor: . . . – to find – and correct – the defect Resulting Criteria for . . . – that leads to the wrong answer. Need to Go Beyond . . . • After going through this procedure many times, pro- Home Page grammers started seeing common defect patterns. Title Page • For example, a reasonably typical mistake is forgetting ◭◭ ◮◮ to initiate the value of the variable. ◭ ◮ • In this case: Page 3 of 43 – we may get different results depending on Go Back – what was stored in the part of the computer mem- Full Screen ory which is allocated for this variable. Close Quit

  4. Traditional Approach . . . Static Analysis Tools 3. Software Defects (cont-d) Some “Defects” . . . • This defect is even more dangerous if the variable is a Correcting Non- . . . pointer , i.e., crudely speaking, if We Need to Gauge . . . First Risk Factor: How . . . – it stores not the actual value of the corresponding Second Risk Factor: . . . object, Resulting Criteria for . . . – but rather the memory address at which the actual Need to Go Beyond . . . value is stored. Home Page • In this case, if we do not initialize the pointer, not only Title Page can we access the wrong value, but: ◭◭ ◮◮ – we may also end up with a non-existing address ◭ ◮ – or an address outside the memory segment in which Page 4 of 43 your program is allowed to operate, Go Back – at which point the program stops; – this is known as segmentation fault . Full Screen Close Quit

  5. Traditional Approach . . . Static Analysis Tools 4. Software Defects (cont-d) Some “Defects” . . . • Many programming language do not automatically check Correcting Non- . . . the array indices. We Need to Gauge . . . First Risk Factor: How . . . • Then, a typical defect is asking for a value a [ i ] of an Second Risk Factor: . . . array a for an index i which is outside the array’s range. Resulting Criteria for . . . • In this case, the compiler obediently finds the corre- Need to Go Beyond . . . sponding space in the memory. Home Page • However, this space is beyond the place of the original Title Page array. ◭◭ ◮◮ • This can overwrite important information; this is known ◭ ◮ as buffer overrun . Page 5 of 43 Go Back Full Screen Close Quit

  6. Traditional Approach . . . Static Analysis Tools 5. Static Analysis Tools Some “Defects” . . . • Programmers realized long time ago that there are cer- Correcting Non- . . . tain patterns of code typical for software defects. We Need to Gauge . . . First Risk Factor: How . . . • So, they started to come up with automatic tools for Second Risk Factor: . . . detecting such patterns. Resulting Criteria for . . . • These tools warn the user of possible defects of different Need to Go Beyond . . . potential severity. Home Page • At present, there are many such tools – Coverity, For- Title Page tify, Lint, etc. ◭◭ ◮◮ • Most of these tools are efficiently used in practice. ◭ ◮ Page 6 of 43 Go Back Full Screen Close Quit

  7. Traditional Approach . . . Static Analysis Tools 6. Some “Defects” Found by Static Analysis Tools Some “Defects” . . . Do Not Harm the Program’s Functionality Correcting Non- . . . • Not all “defects” uncovered by a static analysis tool We Need to Gauge . . . are actually hurting the program. First Risk Factor: How . . . Second Risk Factor: . . . • For example, some programs have extra variables , i.e., Resulting Criteria for . . . variables which are never used. Need to Go Beyond . . . • This happens if: Home Page – a programmer originally planned to use the vari- Title Page able, ◭◭ ◮◮ – started coding with it, ◭ ◮ – then changed her mind but forgot to delete all the occurrences of this variable. Page 7 of 43 • Static analysis tools mark it as a possible detect. Go Back Full Screen • Indeed, in some situations, it is indeed an indication that some important value is never used. Close Quit

  8. Traditional Approach . . . Static Analysis Tools 7. Some “Defects” Do Not Harm the Program’s Some “Defects” . . . Functionality (cont-d) Correcting Non- . . . • However, in many other cases: We Need to Gauge . . . First Risk Factor: How . . . – it may be syntactically clumsy, Second Risk Factor: . . . – but it does not cause any problem for the program. Resulting Criteria for . . . • Another defect that may not necessarily be harmful is Need to Go Beyond . . . the logically dead code, when: Home Page – a branch in a branching code Title Page – is never visited. ◭◭ ◮◮ • For example: ◭ ◮ Page 8 of 43 – if as part of the computations, we compute a square root of some quantity, Go Back – it makes sense to make sure that this quantity is Full Screen non-negative. Close Quit

  9. Traditional Approach . . . Static Analysis Tools 8. Some “Defects” Do Not Harm the Program’s Some “Defects” . . . Functionality (cont-d) Correcting Non- . . . • When this quantity appears as result of long computa- We Need to Gauge . . . tions, it may happen that, First Risk Factor: How . . . Second Risk Factor: . . . – due to rounding errors, Resulting Criteria for . . . – a small non-negative value becomes small negative. Need to Go Beyond . . . • In this case, it makes sense, if the value is negative, to Home Page replace this with 0. Title Page • However, if we write a code this way, ◭◭ ◮◮ – but we only use it to compute √ x of a non-negative ◭ ◮ x (e.g., of the weight), Page 9 of 43 – then the branch corresponding to a negative value Go Back is never used. Full Screen Close Quit

  10. Traditional Approach . . . Static Analysis Tools 9. Some “Defects” Do Not Harm the Program’s Some “Defects” . . . Functionality (cont-d) Correcting Non- . . . • In some cases, this may be a real defect, indicating We Need to Gauge . . . that: First Risk Factor: How . . . Second Risk Factor: . . . – we may have missed something Resulting Criteria for . . . – that would lead to the possibility of this condition. Need to Go Beyond . . . • However, in cases described above, this “defect” is mostly Home Page harmless. Title Page • Yes another example of a possible defect is indentation. ◭◭ ◮◮ • In some programming languages like Python, indenta- ◭ ◮ tion is used to indicate: Page 10 of 43 – the end of the condition or Go Back – the end of the loop. Full Screen • However, in most other programming languages, in- dentation is ignored by the compiler. Close Quit

  11. Traditional Approach . . . Static Analysis Tools 10. Some “Defects” Do Not Harm the Program’s Some “Defects” . . . Functionality (cont-d) Correcting Non- . . . • Indentation simply helps people better understand each We Need to Gauge . . . other’s code. First Risk Factor: How . . . Second Risk Factor: . . . • A static analysis tool: Resulting Criteria for . . . – will detect the discrepancy between the indentation Need to Go Beyond . . . and the actual end of the condition or of a loop, and Home Page – indicate it as a defect. Title Page • It indeed may be a serious defect. ◭◭ ◮◮ • However, in many cases, it is just a sloppiness of a pro- ◭ ◮ grammer that does not affect the program’s execution. Page 11 of 43 Go Back Full Screen Close Quit

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend