©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 1Dependable software developmentz Programming techniques for building dependable software systems.©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 2Software dependabilityz In general, software customers expect all software to be dependable. However, for non-critical applications, they may be willing to accept some system failuresz Some applications, however, have very high dependability requirements and special programming techniques must be used to achieve this©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 3Dependability achievementz Fault avoidance– The software is developed in such a way that human error is avoided and thus system faults are minimised– The development process is organised so that faults in the software are detected and repaired before delivery to the customerz Fault tolerance– The software is designed so that faults in the delivered software do not result in system failure©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 4Fault minimisationz Current methods of software engineering now allow for the production of fault-free software.z Fault-free software means software which conforms to its specification. It does NOT mean software which will always perform correctly as there may be specification errors.z The cost of producing fault free software is very high. It is only cost-effective in exceptional situations. May be cheaper to accept software faults©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 5Fault removal costsCostper errordeletedFewNumb er of resi du al errorsManyVe r yfew©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 6Fault-free software developmentz Needs a precise (preferably formal) specification.z Requires an organizational commitment to quality.z Information hiding and encapsulation in software design is essentialz A programming language with strict typing and run-time checking should be usedz Error-prone constructs should be avoidedz Dependable and repeatable development process©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 7Structured programmingz First discussed in the 1970'sz Programming without gotosz While loops and if statements as the only control statements.z Top-down design.z Important because it promoted thought and discussion about programmingz Leads to programs that are easier to read and understand©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 8Error-prone constructsz Floating-point numbers– Inherently imprecise. The imprecision may lead to invalid comparisonszPointers– Pointers referring to the wrong memory areas can corrupt data. Aliasing can make programs difficult to understand and changezDynamic memory allocation– Run-time allocation can cause memory overflowzParallelism– Can result in subtle timing errors because of unforseeninteraction between parallel processes©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 9Error-prone constructsz Recursion– Errors in recursion can cause memory overflowz Interrupts– Interrupts can cause a critical operation to be terminated and make a program difficult to understand. they are comparable to goto statements.z Inheritance– Code is not localised. This can result in unexpected behaviour when changes are made and problems of understandingz These constructs don’t have to be avoided but they must be used with great care.©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 10Information hidingz Information should only be exposed to those parts of the program which need to access it. This involves the creation of objects or abstract data types which maintain state and operations on that statez This avoids faults for three reasons:– the probability of accidental corruption of information – the information is surrounded by ‘firewalls’ so that problems are less likely to spread to other parts of the program– as all information is localised, the programmer is less likely to make errors and reviewers are more likely to find errors©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 11A queue specification in Javainterface Queue {public void put (Object o) ;public void remove (Object o) ;public int size () ;} //Queue©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 12Signal declaration in Javaclass Signal {public final int red = 1 ;public final int amber = 2 ;public final int green = 3 ;... other declarations here ...}©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 13Reliable software processesz To ensure a minimal number of software faults, it is important to have a well-defined, repeatable software processz A well-defined repeatable process is one that does not depend entirely on individual skills; rather can be enacted by different peoplez For fault minimisation, it is clear that the procesactivities should include significant verification and validation©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 14Process validation activitiesz Requirements inspectionsz Requirements managementz Model checkingz Design and code inspectionz Static analysisz Test planning and managementz Configuration management is also essential©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 18 Slide 15Fault tolerancez