Software Engineering Techniques

• Low level design issues for programming-in-the-large.

• Software Quality
• Design by contract
n Pre- and post conditions
n Class invariants
• Ten do
• Ten do nots

• Another type of summary

OOP: Software Engineering Techniques 1

 Software Quality
• Correctness: Is the ability of software to exactly perform their tasks,
as defined by the requirements and specifications.

• Robustness: Is the ability of software to function even in abnormal

conditions.

• Extendibility: Is the ease with which software may be adapted to

changes of specifications.

• Reusability: Is the ability of software to be reused, in whole or in part

for new applications.

• Compatible: Is the ease with which software may be combined with

others software.
OOP: Software Engineering Techniques 2
 Other Software Quality
• Efficiency: Is the good use of hardware resources.

• Portability: Is the ease with which software may be transferred to

various hardware and software environments.

• Verifiability: Is the ease of preparing acceptance procedures, e.g., test

data and methods for finding bugs and tracing the bugs.

• Integrity: Is the ability of software to protect its components against

unauthorized access and modification.

• Ease of use: Is the ease of learning how to use the software, operating
it, preparing input data, interpreting results and recovering from
errors.
OOP: Software Engineering Techniques 3
 Design By Contract
• Purpose: To increase software quality by giving each part of a
software product certain obligations and benefits.

• Without contract
n All parts of a program take a huge responsibility
n All parts of a program check for all possible error possibilities (called
defensive programming).
n This makes a large program larger and more complicated
• With contracts
n Methods can make assumptions
n Fewer checks for errors possibilities
n This makes a large program simpler.

OOP: Software Engineering Techniques 4

 Design By Contract, Example
• A stack example the push method.

• Client programmer
n Obligation: Only call push(x) on a non-full stack
n Benefit: Gets x added on top of stack.
• Class programmer
n Obligation: Make sure that x is pushed on the stack.
n Benefit: No need to check for the case that the stack is already full

• Think Win-Win!

OOP: Software Engineering Techniques 5

 Pre and Postconditions
• A precondition expresses the constraints under which a method
will function properly.
n The responsibility of the caller to fulfill the precondition.
• A postcondition expresses properties of the state resulting from
a method's execution.
n The responsibility of the method to fulfill the postcondition

• Both preconditions and postconditions are expressed using

logical expressions also called assertions.

• Other issues
n Class invariantss
n Loop invariants
OOP: Software Engineering Techniques 6
 Java 1.4's assert Keyword
• An assertion is a boolean expression that a developer
specifically proclaims to be true during program runtime
execution [Source: java.sun.com].
• New to Java 1.4.
• Used for expressing both pre- and postconditions.

• Syntax:
assert expression1;
assert expression1 : expression2;

OOP: Software Engineering Techniques 7

 Java 1.4's assert Keyword, cont.
• Evaluation of an assert statement.

Evaluate expression1
if true
no further action
else
if expression2 exists
Evaluate expression2 and use the result in a
single-parameter form of the AssertionError
constructor
else
Use the default AssertionError constructor

OOP: Software Engineering Techniques 8

 assert, Examples

assert 0 <= value;

assert 0 <= value : "Value must be positive " + value;

assert ref != null;

assert ref != null : "Ref is null in myFunc";

assert newCount == (oldCount + 1);

assert myObject.myFunc(myParam1, myParam1 );

OOP: Software Engineering Techniques 9

 Pre- and Postcondition, Example
import java.util.*;
public class AStack{
private LinkedList stck = new LinkedList();
private final int no = 42;

public boolean full() {

if (stck.size() >= no) return true;
else return false;
}
public boolean empty() {
return !full();
}

public void push(Object v) {

// precondition
assert !full(): "Stack is full";
stck.addFirst(v);
// postconditions
assert !empty();
assert top().equals(v);
// check no of elements increase by one
}
OOP: Software Engineering Techniques 10
 Pre- and Postcondition, Example
public Object top() {
assert !empty();
return stck.getFirst();
// no post conditions
}
public Object pop() {
assert !empty();
return stck.removeFirst();
assert !full();
// check no of elements decrease by one
}
public static void main(String[] args) {
AStack as = new AStack();
}
}

OOP: Software Engineering Techniques 11

 assert and Inheritance
class Base{
public void myMethod (boolean val){
assert val : "Assertion failed: val is " + val;
System.out.println ("OK");
}
}
public class Derived extends Base {
public void myMethod (boolean val){
assert val : "Assertion failed: val is " + val;
System.out.println ("OK");
}
public static void main (String[] args){
try {
Derived derived = new Derived();
...
}
}
OOP: Software Engineering Techniques 12
 assert and Inheritance, cont
• Preconditions cannot be strengthened in subclasses.
• Postconditions cannot be weakened in subclasses.

OOP: Software Engineering Techniques 13

 Class Invariant
• A class invariant is an expression that must be fulfilled by all
objects of the class at all stable times in the lifespan of an object
n After object creation
n Before execution a public method
n After execution of a public method
• A class invariant is extra requirement on the pre and
postconditions of methods.
• Class invariants can be used to express consistency checks
between the data representation and the method of a class, e.g.,
after if a stack is empty then size of the linked list is zero.
• Class invariants cannot be weakened in subclasses.
• Not supported in Java.

OOP: Software Engineering Techniques 14

 Ten Dos
• Logical naming
n Class name p3452 vs. class name Vehicle
n The foundation for reuse!
• Symmetry
n If a get method then also a set method
n If an insert method then also a delete method
n Makes testing easier.
n To avoid "surprises" for the clients.
• Add extra parameters to increase flexibility
n split (string str) vs.
split (string str, char ch default ' ')
n To anticipate "small" changes.

OOP: Software Engineering Techniques 15

 Ten Dos
• Set a maximum line size (80-100 characters)
n To avoid more the one thing being done in the same line of code
n To be able to print the code with out wrapping. For code reviews
• Set the maximum of lines for a method
n What can be shown on a screen (30-60 lines)
n To increase readability
n To increase modularity
• Indent your code
n Increases readability
• Avoid side-effects
n If a method refers to an object in a database and the object does not exist
then raise and error do not create the object.
n Make program logic impossible to understand
OOP: Software Engineering Techniques 16
 Ten Dos
• Add comments in method
n Comment where you are puzzled yourself or is puzzled the day after you
wrote the code
n Do not comment the obvious!
• Look at (and comment on) other peoples code
n Code reviews are a good investment
n Increases readability of code
n A good way to learn from each other
• Be consistent
n Can automate global changes with scripts

OOP: Software Engineering Techniques 17

 Ten Do Nots
• Make a method do more than one thing
n split_and_store (string str, char ch) vs. split
(string str, char ch) and store (string_array)
n Makes the method more complicated
n Decreases reuse
• Make a method take more than 7±2 parameters
n Can parameters be clustered in objects?
• Make more than 4 level of nesting in a method
n if {if{if{if{if }}}}}
n Decreases readability
• Make use of "magic" numbers
n WHERE employee.status = '1' vs
WHERE employee.status = global.open

OOP: Software Engineering Techniques 18

 Ten Do Nots
• Make use of Copy-and-Paste facilities
n Redundant code
n Make a new method or use inheritance
• Become mad and aggressive if some one suggest changes to
your code.
• Have more than one return statement in a function
• Skip exception handling
• Skip testing
• Assume the requirement specification is stable

OOP: Software Engineering Techniques 19

 Summary
• Any fool can write code that a computer can understand. Good
programmers write code that humans can understand. (Fowler)
• Debug only code - comments can lie.
• If you have too many special cases, you are doing it wrong.
• Get your data structures correct first, and the rest of the
program will write itself.
• Testing can show the presence of bugs, but not their absence.
• The first step in fixing a broken program is getting it to fail
repeatedly.
• The fastest algorithm can frequently be replaced by one that is
almost as fast and much easier to understand.

OOP: Software Engineering Techniques 20

 Summary, cont.
• The cheapest, fastest, and most reliable components of a
computer system are those that are not there.
• Good judgement comes from experience, and experience
comes from bad judgement.
• Do not use the computer to do things that can be done
efficiently by hand.
• It is faster to make a four-inch mirror then a six-inch mirror
than to make a six-inch mirror.
[Thompson's Rule for first-time telescope makers]
• If you lie to the computer, it will get you.
• Inside of every large program is a small program struggling to
get out.

OOP: Software Engineering Techniques 21