Defensive Programming Flashcards Preview

CMSC 128 - Introduction to Software Engineering > Defensive Programming > Flashcards

Flashcards in Defensive Programming Deck (14):

a practice wherein developers anticipate failure in their code and add supporting code to detect, isolate and recover from that failure

Defensive programming


Application should behave in a consistent and predictable manner even in cases of unexpected conditions

Defensive programming


Three hardcore topics related to defensive programming

1. Security 2. Data integrity 3. Privacy


what is OWASP and what does it do

Open Web Application Security Project;
An organisation focused on improving security of software


Why is defensive programming important

For security (being free from danger) and safety (being protected)


It was destroyed because of a software error wherein a 64 but floating point number related to the horizontal velocity of the rocket was converted into a 16 bit signed integer

European space agency’s ARIANE 5 flight 501


It is responsible for atleast 5 deaths in the 80’s wherein it malfunctioned (MALFUNCTION 54) specifically, it cannot determine if underdose or overdose

Therac 25 radiation therapy machine


Its system clock drifted 1/3 of a second over.a period of 100 hours causing a failure in locating an incoming missile
(Object tracking and time conversion error)

MIM 104 Patriot


6 tips and guidelines of defensive programming

>never trust user input
>never trust developers’ code
>write tests
>write SOLID
>use frameworks


A principle that states that a class should only have one job

Single responsibility principle


A principle that states that objects should be open to EXTENSION but closed for MODIFICATION

Open/close principle


If q(x) is provable on x (type T) then g(y) is provable on y (type S w/c is a subset of T)

Liskov substitution principle


A principle stating that client s should never be forces to implement an interface/method they do not use

Interface segregation principle


High level modules should not depend on low level modules but on abstractions

Dependency inversion principle