EECE 310: Software Engineering

1
EECE 310 Software Engineering

• Procedural Abstractions / Exceptions
• To read Liskov chapter 3, 4
• Problems to try 3.1-3.7, 4.1-4.5

2
Roadmap

• abstraction
• specifying procedures
• implementing procedures
• designing procedures

3

• procedural abstraction (procedure)
• define transformation of data
• abstracts from irrelevant details
• Implies that realizations agree on relevant
  characteristics
• allows to introduce new operations
• abstraction by
• parameterization abstracts from the identity of
  data being used
• order, type, presence of arguments still relevant
  
• specification abstracts from the implementation
  details
• Focus on WHAT not on HOW

4
Benefits

• locality -- the implementation of an abstraction
  can be read or written without needing to examine
  the implementations of any other abstractions
• modifiability -- an abstraction can be
  reimplemented without requiring changes to any
  abstraction that use it

5

• public class Vectors
• //OVERVIEW Provides useful standalone
  procedures
• //for manipulating vectors
• public static void removeDupls ( Vector v )
• if ( v null ) return
• for ( int i 0 i lt v.size( ) i)
• Object x v.get(i)
• int j i 1
• // remove all x duplicates from rest of v
• while ( j lt v.size( ) )
• if ( !x.equals( v.get( j ) ) )
• j
• else
• v.set( j, v.lastElement( ) )
• v.remove( v.size( ) -1 )

6
Roadmap

• abstraction
• specifying procedures
• need for precise definitions
• formal vs. informal specifications
• implementing procedures
• designing procedures

7
Specifying procedures
8

• public class Vectors
• //OVERVIEW Provides useful standalone
  procedures
• //for manipulating vectors
• public static void removeDupls ( Vector v )
• // REQUIRES
• // MODIFIES
• // EFFECTS
• if ( v null ) return
• for ( int i 0 i lt v.size( ) i)
• Object x v.get(i)
• int j i 1
• // remove all x duplicates from rest of v
• while ( j lt v.size( ) )
• if ( !x.equals( v.get( j ) ) )
• j
• else
• v.set( j, v.lastElement( ) )

9

• public class Vectors
• //OVERVIEW Provides useful standalone
  procedures
• //for manipulating vectors
• public static void removeDupls ( Vector v )
• // REQUIRES All elements of v are not null
• // MODIFIES v
• // EFFECTS Removes all duplicate elements from
  v
• // uses equals to determine duplicates.
• // The order of remaining elements may
  change.
• if ( v null ) return
• for ( int i 0 i lt v.size( ) i)
• Object x v.get(i)
• int j i 1
• // remove all x duplicates from rest of v
• while ( j lt v.size( ) )
• if ( !x.equals( v.get( j ) ) )
• j

10

• public class Arrays
• //OVERVIEW Provides useful standalone
  procedures
• //for manipulating arrays
• public static int search (int a, int x)
• // REQUIRES
• // MODIFIES
• // EFFECTS
• public static int searchSorted (int a, int x)
• // REQUIRES
• // MODIFIES
• // EFFECTS
• public static int sort (int a, int x)
• // REQUIRES
• // MODIFIES
• // EFFECTS

11

• More
• partial vs. total procedures
• Notation a_post
• Returning a new object
• Implicit imputs

12
Roadmap

• abstraction
• specifying procedures
• implementing procedures
• designing procedures

13
What is a valid implementation?

• modifies only inputs specified in MODIFIES
  clause.
• produces results in accordance with EFFECTS
  clause

14
Roadmap

• abstraction
• specifying procedures
• implementing procedures
• designing procedures

15

• granularity issue how many procedures?
• Too many ? unnecessary complexity
• Procedure specifications should be
• minimally constraining
• Total vs. partial specifications
• Partial if possible implementation should verify
  constraints
• procedure specification
• can specify underdetermined behavior
• procedure implementation
• can have deterministic implementation

16

• underdetermined behavior
• a procedure is underdetermined if for certain
  inputs its specification allows more than one
  possible result
• examples
• int random (int min, int max)
• // REQUIRES max gt min 1
• // EFFECTS returns a random integer result
• // such that min lt result lt max
• public static int findMax(int x, int y, int z)
• // EFFECTS returns the largest number out
• // of the 3 input integers,
• // e.g., if x 10, y 3, z -7, then return
  10

17

• deterministic implementation
• an implementation of a procedure is deterministic
  if, for the same input, it always produces the
  same result.
• int random (int min, int max)
• // REQUIRES max gt min 1
• // EFFECTS returns a random integer result
• // such that min lt result lt max
• public static int findMax(int x, int y, int z)
• // EFFECTS returns the largest number out
• // of the 3 input integers,
• // e.g., if x 10, y 3, z -7, then return
  10

18

• Problem
• Specify a procedure in Java that returns the
  index of the element in an array of integers that
  has minimum value.
• For example, if its given array 1, 2, -1, it
  would return 2.
• Aim at writing specification that is
  sufficiently restrictive, general, and clear.
• Does your specification define underdetermined
  behavior? Explain your answer.
• Does your specification allow nondeterministic
  implementation? Explain your answer.

19
Summary

• abstraction
• definition and benefits
• mechanisms
• types
• specifying procedures
• specification structure REQUIRE/MODIFIES/EFFECTS
  clause
• implementing procedures
• two conditions to be satisfied
• designing procedures
• three properties
• two types of specifications
• implementation

20
EECE 310 Software Engineering

• Exceptions
• To read Liskov chapter 4
• Problems to try 4.

21

• Goal robust programs
• behaves reasonably even in the presence of errors
  
• Total procedures one way to increase robustness
• Q how to notify caller of errors?
• public static int fact (int n)
• // EFFECTS If ngt0 returns n! else ?? ??

22

• public static int fact (int n)
• // EFFECTS In ngt0 returns n! else ??returns 0??
• Why not encode error status in return value?
• Nonstandard way to define them
• What if all return values are possible?
• Will lead to more complex caller code
• int z x Num.fact(y)

23

• Javas solution Exceptions
• throws clause
• public static int fact (int n) throws
  NonPositiveException
• // EFFECTS if ngt0 returns n!
• // else throws NonPositiveException
• Procedure specification should
• List all exceptions in header
• EFFECTS must explain when exceptions are thrown

24
Exception Class Hierarchy

• Unchecked Exceptions Checked
  Exceptions
• Look in the Java API for a full list of
  exceptions

25
Creating Your Own Exception Classes

• Your own exceptions must be a subclass of the
  Exception class and have at least the two
  standard constructors
• public class MyCheckedException extends
  IOException
• public MyCheckedException() super()
• public MyCheckedException(String m)
  super(m)
• public class MyUncheckedException extends
  RuntimeException
• public MyUncheckedException() super()
• public MyUncheckedException(String m)
  super(m)

26

• Creating Exception Instances
• MyCheckedException e
• new MyCheckedException(proc_name - this is
• the reason)
• e.toString()) --gt
• MyCheckedException Proc name - this is the
  reason
• Throwing exceptions
• public static int fact (int n) throws
  NonPositiveException
• // EFFECTS if ngt0 returns n!
• // else throws NonPositiveException
• if (nlt0) throw new NonPositiveException(Num.fact
  )

27
Handling Exceptions

• You can use a try-catch block to handle
  exceptions that are thrown
• try
• // code that might throw exception
• catch (Type of Exception e)
• // what to do if exception is thrown

28

• You can handle multiple possible exceptions by
  multiple successive catch blocks
• try
• // code that might throw multiple
• // exceptions
• catch (IOException e)
• // handle IOException
• catch (ClassNotFoundException e2)
• // handle ClassNotFoundException

29
Finally Block

• You can also use the optional finally block at
  the end of the try-catch block
• The finally block provides a mechanism to clean
  up regardless of what happens within the try
  block
• Can be used to close files or to release other
  system resources

30
Try-Catch-Finally Block

• try
• // code that might throw exception
• catch (Type of Exception e)
• // what to do if exception is thrown
• finally
• // statements here always get
• // executed, regardless of what
• // happens in the try block

31
(No Transcript)
32

• static int willThisPrintAnything?
• (boolean bVal)
• try
• if (bVal)
• return 1
• return 0
• finally
• System.out.println(AHA)

33
Design issues

• Reflecting vs. masking
• Reflecting propagate the exception (or a new
  one) up
• Masking fix the problem at this level
• When to use?
• Local context you do not need one
• Avoid encoding error information in returned
  results
• Use exceptions instead of REQUIRES clauses unless
  a requirement can not be checked or is very
  expensive to check
• Checked vs. unchecked
• Unchecked if you expect that users will write
  code that makes sure the exception is usually
  avoided

34
Defensive programming

• Use exceptions to
• protect your code against errors introduced by
• other procedures (check actual arguments),
• hardware,
• user input
• verify your assumptions about program state

35

• static int surpriseTheProgrammer(boolean bVal)
• while (bVal)
• try
• return 0
• finally
• return 1
• return 2
• System.out.println(surpriseTheProgrammer(false))
• System.out.println(surpriseTheProgrammer(true))

36
(No Transcript)
37
A few more general comments on Java

• Packages. Visibility modifiers
• Objects and variables
• Heap / stack management, method call semantics
• Mutability
• Type checking
• Type safety
• Type hierarchy. Primitive vs. object types
• Apparent vs. actual type for variables
• Conversions
• Automatic for primitive types.
• Overloading
• Most specific criteria