TAILIEUCHUNG - Software Engineering For Students: A Programming Approach Part 27
Software Engineering For Students: A Programming Approach Part 27. This fully revised version of Doug Bell's Software Engineering: A Programming Approach continues to use the successful formula of the previous editions. The author's approach is to present the main principles, techniques and tools used in software engineering, one by one, chapter by chapter. This book is a unique introduction to software engineering for all students of computer science and its related disciplines. It is also ideal for practitioners wishing to remain current with new developments in the area | 238 Chapter 17 Software robustness some systems when a user error arises again it is the role of the software to cope. In many situations of course when a fault arises nothing is done to cope with it and the system crashes. This chapter explores measures that can be taken to detect and deal with all types of computer fault with emphasis on remedial measures that are implemented by software. We will see in Chapter 19 on testing that eradicating every bug from a program is almost impossible. Even when formal mathematical methods for program development are used to improve the reliability of software human error creeps in so that even mathematical proofs can contain errors. As we have seen in striving to make a piece of software as reliable as possible we have to use a whole range of techniques Software fault tolerance is concerned with trying to keep a system going in the face of faults. The term intolerance is sometimes used to describe software that is written with the assumption that the system will always work correctly. By contrast fault tolerance recognizes that faults are inevitable and that therefore it is necessary to cope with them. Moreover in a well-designed system we strive to cope with faults in an organized systematic manner. We will distinguish between two types of faults - anticipated and unanticipated. Anticipated faults are unusual situations but we can fairly easily foresee that they will occasionally arise. Examples are division by zero floating point overflow numeric data that contains letters attempting to open a file that does not exist. What are unanticipated faults The name suggests that we cannot even identify predict or give a name to any of them. Logically if we can identify them they are anticipated faults. In reality this category is used to describe very unusual situations. Examples are hardware faults . an input-output device error or a main memory fault a software design fault . a bug an array subscript that is outside its .
đang nạp các trang xem trước