Defensive Programming Flashcards Preview

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

Flashcards in Defensive Programming Deck (14):
1

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

Defensive programming

2

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

Defensive programming

3

Three hardcore topics related to defensive programming

1. Security 2. Data integrity 3. Privacy

4

what is OWASP and what does it do

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

5

Why is defensive programming important

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

6

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

7

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

8

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

9

6 tips and guidelines of defensive programming

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

10

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

Single responsibility principle

11

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

Open/close principle

12

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

13

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

Interface segregation principle

14

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

Dependency inversion principle