DEFECT CONTAINMENT

Bugs

Faults

Failures

Devs

            Defect Prevention
        
            Defect Removal

REMEMBER OUR TARGET AS SOFTWARE ENGINEERS: REDUCE AND MINIMIZE IMPACT OF DEFECTS

TODAY WE ARE GOING TO TALK ABOUT MINIMIZING ITS IMPACT

TEACHING NOTES

Available at:

 

http://dcoloma.github.io/software-quality/all.html#assertion-driven-development-design-by-contract

 

 

ASSERTION DRIVEN DEVELOPMENT AND DESIGN BY CONTRACT

Deffensive Programming

Including in the Software as many check as possible...

 

What if... just in case... for the sake of being on the safe side...

 

Remember in the Triangle problem we initially checked for <= 0 values and valid triangle sizes...

Design By Contract

Real World Contract

when a contract is exhaustive, there is a guarantee that all the obligations are related to the benefits

Software Contract

If all the subtasks are completed correctly, the task will be also finished successfully. If there is a contract between the task and the subtasks, the task will have some guarantees about the completion. Subtasks in software developmentare typically functions, object methods...

Please also think about the Spotify way of working in which they created an architecture that manage every team to deliver different parts of Spotify client independently. It is quite similar, they have divided the main task (the Spotify client) in multiple subtasks (the components of the architecture). If all the components behave properly, the final task will be working properly too.

Design By Contract

  • Preconditions: A certain conditions to be guaranteed on entry by any client module that calls it. It is an obligation for the client module and a benefit for the supplier (no need to handle cases outside of the precondition)
  • Postconditions: Gurantee a certain property on exit. This is an obligation for the supplier and a benefit for the client.
  • Class-invariant: Guarantee that certain properties are not going to be changed on exit.

"What happens if one of these conditions fails during execution?"

Up to the developers

Triangle

  • Preconditions: A, B, C are valid integer values. A, B, C are bigger than 0. The addition of the smallest ones is bigger than the bigger one. 
  • Postconditions: The result is going to be one these values: EQUILATERAL, ISOSCELES, SCALENE. 
  • Class-invariant: The sizes of the triangle are not going to change

Benefits: If the contract is clear, the getTriangleType could be really small as it just need to focus on the valid cases

Real World Application

This is something that comes directly in some Programming Languages (but not well known) such as Eiffel.

 

There are libraries that can be used for other programming languages (e.g. AspectJ for Java) to support this kind of approach, most of them are based on assertions (as test frameworks). The idea is assert the values to check if pre-conditions and post-conditions are honoured.

FAULT TOLERANCE & FAILURE CONTAINMENT

TARGET: INCREASE THE RELIABILITY

BREAK THE BUG/FAILURE CAUSE/EFFECT RELATIONSHIP

FAULT TOLERANCE

TARGET: INCREASE SAFETY

MINIMIZE CONSEQUENCES OF FAILURES

FAILURE CONTAINMENT

for instance a medical system could not be 100% reliable but it should be 100% safe

REDUNDANCY IS KEY!

FAULT TOLERANCE

RECOVERY BLOCKS

N-VERSION PROGRAMMING

N-VERSION

  • Same function performed by two or more components at a time
  • Some of type of voting required to decide output to use
  • If one instance fails, system can still work

N-VERSION: ISSUES

  • The probability of both system failing at the same time should be low. Assumptions:
    • The probability of correlated failures is very low for independently developed software
    • Software errors are random
  • If these assumptions are correct, if all the N modules are implemented by independent teams, we could have ultra-reliable system. Unfortunately, this doesn't seem to be the case.

UNCORRELATED FAILURES

N-VERSION: ISSUES

  • If N=2 and the two instances return different results. How do you know which one is the right one? (simple majority is used what if majority is wrong)
  • Sometimes, the output of the instances is not a single value, but a complex list of values (e.g. aircrafts)
  • Analysing a complex list of values, requires time, calculation effort (e.g. evaluation of different thresholds) and could also be another source of failures

VOTING SYSTEM

N-VERSION: ISSUES

  • Implementation cost of the multiple instances
  • Hardware/Resources cost: N versions of the same software running in parallel would require N-times the number of resources required by a single one.

COST

N-VERSION

  • It's the best way to increase reliability
  • Cost of doing it is high
  • The increase in reliability is way smaller than the theoretical one
  • It presents practical problems
  • It should only be done for systems in which failing is not an option (e.g because of safety reasons)

SUMMARY

Failure Containment

https://www.youtube.com/watch?v=yx_XoqXNtRM

https://www.youtube.com/watch?v=0vZwaMg60FM

https://www.youtube.com/watch?v=aayvBkTGZH0

 
Made with Slides.com