Interactive Programming: Language Technologies and Paradigms for Testing and Debugging, Study Guides, Projects, Research of Programming Languages

A portion of the spring 2005 syllabus for a university course, cmsc 433, focusing on programming language technologies and paradigms. Topics related to interactive development environments, testing, and debugging. It discusses the use of tools like drjava and eclipse, the importance of testing and debugging, and techniques for effective debugging. Students are encouraged to use the scientific method and defensive programming to identify and address issues.

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 07/30/2009

koofers-user-4q3-1
koofers-user-4q3-1 🇺🇸

10 documents

1 / 9

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CMSC 433 – Programming Language
Technologies and Paradigms
Spring 2005
Interactive Development Environments,
Testing, and Debugging
February 10, 2005
Administrivia
Project 2 posted
JUnit and testing
Interactive Development Environments
A system that covers many development tasks
Editor – usually with nice syntax coloring, indentation
Compiler – automatic compilation, errors linked to code
Debugger – step through source code
Etc... – Testing, search, code transformations, ...
Examples: DrJava, NetBeans, Eclipse, Visual Studio,
emacs
Dr. Java
Light-weight IDE
Editing
Syntax coloring, auto-indent, brace matching
Testing
Integrates with Junit testing framework
Uses suite() or auto-generated suite
Interaction panel allows interactive method invocations
Debugging
Integrates with Java debugger
Interactions panel also useful
pf3
pf4
pf5
pf8
pf9

Partial preview of the text

Download Interactive Programming: Language Technologies and Paradigms for Testing and Debugging and more Study Guides, Projects, Research Programming Languages in PDF only on Docsity!

CMSC 433 – Programming Language

Technologies and Paradigms

Spring 2005

Interactive Development Environments,

Testing, and Debugging

February 10, 2005

Administrivia

• Project 2 posted

– JUnit and testing

Interactive Development Environments

• A system that covers many development tasks

– Editor – usually with nice syntax coloring, indentation

– Compiler – automatic compilation, errors linked to code

– Debugger – step through source code

– Etc... – Testing, search, code transformations, ...

• Examples: DrJava, NetBeans, Eclipse, Visual Studio,

emacs

Dr. Java

• Light-weight IDE

• Editing

– Syntax coloring, auto-indent, brace matching

• Testing

– Integrates with Junit testing framework

  • Uses suite() or auto-generated suite

– Interaction panel allows interactive method invocations

• Debugging

– Integrates with Java debugger

– Interactions panel also useful

Debugging

• My program doesn’t work: why?

• Use the scientific method:

– Study the data

  • Some tests work, some don’t

– Hypothesize what could be wrong

– Run experiments to check your hypotheses

  • Testing!

– Iterate

Starting to Debug

• What are the symptoms of the misbehavior?

– Input/output

– Stack trace (from thrown exception)

• Where did the program fail?

• What could have led to this failure?

• Test possible causes, narrow down the problem

Checking that Properties Hold

• Print statements

– Check whether values are correct

  • E.g., look at value of i to check if i > 0

– Check whether control-flow is correct

  • E.g., see if f() is called after g()

• Automatic debugger

– Allows you to step through the program interactively

– Verify expected properties

  • Don’t need to put in print statements and recompile

– Use as part of testing

Eclipse’s Automatic Debugger

• Set execution breakpoints

• Step through execution

– into , over , and out of method calls

• Examine the stack

• Examine variable contents

• Set watchpoints

– Notified when variable contents change

CMSC 433 – Programming Language

Technologies and Paradigms

Spring 2005

Abstraction and Parametric Polymorphism

February 10, 2005

Data Abstraction

• Data abstraction = objects + operations

– List + { addFirst, addLast, removeFirst, ... }

– Set + { add, contains, ...}

• Categories of operations

– Constructors (creators/producers)

– Mutators

– Observers

Abstraction Function

• Specification for data structure is abstract

• Implementation of data structure is concrete

• How do you know if implementation meets the

spec?

• Abstraction function : concrete abstract

– Relates implementation to abstraction

Example

class IntSet { int[] elts; ... }

– AF(s) = { s.elts[i] | 0 <= i <= elts.length }

• You always need an abstraction function when

you build a data abstraction

– Often it’s implicit

Representation Invariant(s)

• Properties of data structure that must always hold

– After the constructor has finished

– Before and after each operation

class IntSet { // rep inv: elts contains no duplicates int[] elts; ... }

• Part of the (internal) specification

Implementing the Rep Invariant

• Interesting idea: Write a function to check the rep

public boolean repOK() { ...check for duplicates in elts... }

• Where can you use this?

– Can add wherever you expect rep to hold

– Can call during unit testing

• Cost?

Exposing the Rep

• Be careful of exposing the representation

class IntSet { int[] elts; int[] getElements () { return elts; } }

• What’s the problem?

– Other people may rely on implementation details

– Clients may violate the rep invariant

Polymorphism

• Recall that B is a subtype of A if, everywhere you

expect an A, you can accept a B

– Subtypes come from subclassing with extends

– Subtypes come from interfaces with implements

• This is a kind of type polymorphism

– Methods can accept objects of many types, not just one

– This is usually called subtype polymorphism

General Problem

• When we move from an X container to an Object

container

– Methods that take X’s as input parameters are OK

  • If you’re allowed to pass Object in, you can pass any X in

– Methods that return X’s as results require downcasts

  • You only get Objects out, which you need to cast down to X

• This is a general feature of subtype polymorphism

Parametric Polymorphism (for Classes)

• Idea: We can parameterize the Stack class by its

element type

• Syntax:

– Class declaration: class A { ... }

  • A is the class name, as before
  • T is a type variable , can be used in body of class (...)

– Client usage declaration: A x;

  • We instantiate A with the Integer type

Parametric Polymorphism for Stack

class Stack { class Entry { Element elt; Entry next; Entry(Element i, Entry n) { elt = i; next = n; } } Entry theStack; void push(Element i) { theStack = new Entry(i, theStack); } Element pop() throws EmptyStackException { if (theStack == null) throw new EmptyStackException(); else { Element i = theStack.elt; theStack = theStack.next; return i; }}}

Stack Client

Stack is = new Stack(); Integer i; is.push(new Integer(3)); is.push(new Integer(4)); i = is.pop();

• No downcasts

• Type-checked at compile time

• No need to duplicate Stack code for every usage

Parametric Polymorphism for Procedures

• String is a subtype of Object

1. static Object id(Object x) { return x; }

2. static Object id(String x) { return x; }

3. static String id(Object x) { return x; }

4. static String id(String x) { return x; }

• Can’t pass an Object to 2 or 4

• 3 doesn’t type check

• Can pass a String to 1 but you get an Object out

Parametric Polymorphism, Again

• Observation: id() doesn’t care about the type of x

– It works for any type

• So parameterize the static method :

static T id(T x) { return x; }

Integer i = id(new Integer(3)); // Notice no need to

// instantiate id; compiler

// figures it out

Summary: Kinds of Polymorphism

• Subtype polymorphism

– Use subtype wherever supertype allowed

• Parametric polymorphism

– When classes/methods work for any type; uses type

variables

• Ad-hoc polymorphism

– Overloading in Java

Parametric Polymorphism in Java

• Part of Java 1.5 (called “generics”)

– Available now

– Comes with replacement for java.util.*

  • class LinkedList { ...}
  • class HashMap { ... }
  • interface Collection { ... }

• Available on linuxlab

– In directory /usr/local/j2sdk1.5.

  • Run /usr/local/j2sdk1.5.0/bin/javac to compile
  • Run /usr/local/j2sdk1.5.0/bin/java to execute
  • API at http://java.sun.com/j2se/1.5.0/docs/api