Difference between revisions of "CIS 3020 Part 2"

From In The Wings
Jump to navigation Jump to search
 
Line 523: Line 523:
 
} // End Class DrawSquare5
 
} // End Class DrawSquare5
 
</pre>
 
</pre>
==Continue with [[CIS 3020 Part 3]]
+
==Continue with [[CIS 3020 Part 3]]==

Latest revision as of 11:28, 21 February 2007

Characteristics of Object Oriented Programming

These characteristics were first developed by Alan Kay.

A program consists of a set of objects

  • Computation is performed through the interaction of the objects with each other
  • The objects tell each other what to do through messages
  • A message consists of:
    • A request
    • The data necessary to serice that request

When a program is executing, everything is an object

  • The object stores data, and you can "make requests" of that object - ask it to perform operations on itself
  • Note: Java violates this rule by having non-object "primitives": boolean, byte, short, int, long, double, float, and char

Each object has its own memory or state

  • Consists of references to other objects (and/or primitives, in Java)
  • The object encapsulates (contains/controls) the state

Each object is an instance of a single class

  • A class is a grouping of objects having similar:
    • State
    • Behaviors - which the object also encapsulates

The class defines the state and behaviors

  • All instances of a class perform the same actions - respond to the same set of messages
  • Each instance behaves similarly, but not necessarily identically

Classes are organized into a single rooted inheritance hierarchy (or tree)

  • States and behaviors associated with a particlar class are accessible to descendant classes

Unified Modeling Language

Graphical notation used to describe object-oriented software systems

Rules

  • In computer science trees are drawn with the root at the top and leaves at the bottom
  • As you move up the tree, you generalize
  • As you move down you specialize
  • Each class can define its own behaviors but also inherits the behaviors of its superclasses or ancestors
  • In Java, all classes are derived from the class Object

Simple Program

class Program1 {
  public static void main(String[] arg) {
    // statements to execute
  }
}
  • All programs consist of at least one class
  • The start and end of a class definition are encapsulated in curly braces ( "{" and "}" )
  • Line two above is a method that defines the driver program
  • The start and end of the program are also encapsulated in curly braces
  • Actual statements of the program go inside these braces
    • NOTE: The "//" is a comment, and comments are critical to understanding a program
  • White space and carriage returns or line feeds (CRLF's) do not matter

The above is the same as:

class Program1 {Public static voide main(String[] arg){
//statements to execute
}}

Real Program

class RectangleDemo {
    public static void main (String[] arg) {
	//create an island and a turtle and associate them
	Island hawaii = new Island(400,400);
	Turtle tina = new Turtle();
	hawaii.putTurtleAtCenter(tina); //faces east
	//instruct turtle to draw rectangle
	tina.tailDown();
	tina.move(10.0);
	tina.turnLeft(90.0);
	tina.move(30.0);
	tina.turnLeft(90.0);
	tina.move(10.0);
	tina.turnLeft(90.0);
	tina.move(30.0);
    } //end main()
} //end class RectangleDemo

Terminology

  • Operation:
    • Behavior which is invoked by a request
    • The abstract description of what is done
  • Method:
    • A specific implementation of an operation
    • The actual code implementation
  • Operation's signature consist of:
    • Name
    • Parameters
    • The returned value's type
  • Interface:
    • A set of related operation signatures
  • Type:
    • A named interface
  • Object's Interface:
    • The set of all operations supported by that object
    • Defined by the class of which the object is an instance
  • An object is an instance of a single class

Software Life Cycle

The Iterative Waterfall Model:

  • Marketing - Requirements
  • Analysis - Specifications
  • Design - Architecture
  • Implementation - Untested Software
  • Testing - Product
  • Maintenance

Any of the above can relegate the software back up the chain however many steps are necessary if something needs to be fixed that was not thought of before. The further up the chain the software needs to be relegated (number of hops) for a single problem, the larger the problem and the bigger the mistake in the first place.

Traditional Software Life Cycle costs

Phase % of Effort
Requirements Definition 3%
Specification 15%
Implementation (Coding) 14%
Testing 8%
Maintenance 60%

Important Issues in the Real World

Note:

  • Recent graduate working at Intel identified:
    • Six months spent on analysis and design
    • Two weeks for implementation
  • Documentation is not mentioned
    • Is an on-going process
    • Occurs throughout the entire software lifecycle
  • Software Prototyping
    • Don't develop the entire system at once
    • Develop a rough prototype that does not have complete functionality
    • Test this prototype with user to verify it meets all of the required specifications
    • Therefore, early changes can be made reducing modifications in the maintenance phase - saving time and cost.
  • Maintenance
    • Code is continually being modified, rewritten, and improved.
    • Much of your effort will be in maintenance
    • Important to develop code that is:
      • Well structured
      • Readable
      • Well documented

Problem Solving Methodology

Analysis:

  • Examine the problem statement (do you really know what you need to do?)
  • Work the problem by hand with a simple set of data to verify you understand what needs to be done
  • Describe the input, output, constraints, assumptions, and relationships

Design:

  • Design a solution based upon the analysis

Implementation:

  • Translate the design into code

Testing:

  • Thoroughly test the solution with data
  • Pay close attention to boundary cases

Analysis

Abstract from the problem statement the data and their relationships

  • Read the problem statement CAREFULLY
  • Identify:
    • Inputs: the data provided to solve the problem
    • Output(s): the desired solution to the problem
      • Return values (eg cash from ATM)
      • Side effects (eg change in account balance)
    • Constraints: requirements that limit the solution
    • Relationships: relationships between the inputs and outputs given the constraints (eg new balance = previous balance - withdrawn amount)
    • Assumptions: information not explicit in problem statement that were used to develop relationships - make as few as possible
  • When reading the problem statement, underline the phrases that identify the inputs, outputs, and constraints

Example

Problem: Given the weight of a set of apples and the price per pound of apples, compute the price of those apples.

Underline the phrases identifying inputs, outputs, and constraints.

What are the inputs? What are the constraints? What are the outputs?
  1. Weight of apples
  2. Price per pound of apples
  1. None
  1. Price of apples
What are the relationships? 
Abstractly phrased: Price = Weight X Price / Weight
Price of Apples = weight of apples X price per lb of apples
How do we identify relationships?
Look for an abstract relationship
Rephrase the problem's terminology
What are the assumptions?
The weight will be given in lbs

Design

  • Once we have performed an analysis of the problem, we can construct a design
  • Top Down Design/Analysis:
    • Decompose the problem into subproblems until each subproblem is trivial to solve
    • Note: A subproblem is a problem, therefore break it down into subproblems
  • Example: Writing a term paper
    • Create a list of topics to cover
    • Take each topic in turn and outline it

Object Oriented Design

  • Identify the existing class that apply to the domain
  • Identify and reuse existing classes that can be adapted to the solution using:
    • Aggregation
      • Use one or more instances of class(es) working together to solve problem
      • example: make a cart from board, wheels, etc.
    • Inheritance
      • Create a specialized version of existing class
      • Add new behaviors and/or modify the state
  • Write a new class from scratch
    • This is not preferred... don't reinvent the wheel!

UML - Revisited

  • Unified Modeling Language
  • Graphical notation used to describe object-oriented software system
Class Name

State (attributes)

Operations

Turtle Class

Turtle Class Name
  Attributes of class
<<constructor>> Operations of class
+ Turtle() Used to create instance of class
  • always has same name as class
  • initializes the starting state of the instance
<<pen status>> Stereotype: provides descriptive information
+ tailUp(): void  
+ tailDown(): void  
<<movement>>  
+ move(Distance:double): void UML Signature of an operation
<<orientation>>  
+ faceEast(): void  
+ turnLeft(Change:double): void double is equivalent to real number
+ turnRight(Change:double): void  

Problem

Display a picture consisting of a square with a side length of 75 units.

What is our first step?
underline phrases identifying inputs, outputs, and constraints
Analysis
In this problem, if we consider 75 as an input, we will produce a general solution, but if we consider it a constraint, we get a specific solution
What items must we identify in our analysis?
Inputs Side Length
Outputs Picture of a square
Constraints Canvas must be large enough
Relationships Square has the side length
Assumptions None
Design
Assumption: We will use existing Turtle and Island classes to solve problem

Here we describe and detail our algorithm. A computational process typically decomposes into:

  1. Initialization
  2. Do the required work
  3. Clean up

It is often helpful to try the task by hand to make sure you know what to do

Design of the Algorithm
  1. Initialization
    1. Create an island
    2. Create a turtle
    3. Put the turtle on the island
  2. Do the work: tell turtle to draw square
    1. Put down the tail
    2. Draw first side
      1. Move forward 75 units
    3. Draw second side
      1. Turn left
      2. Move forward 75 units
    4. Draw third side
      1. Turn left
      2. Move forward 75 units
    5. Draw fourth side
      1. Turn left
      2. Move forward 75 units
  3. Cleanup
    1. Point in the starting direction
      1. Turn left
    2. Pick tail up
Note
Sometimes one or more of these steps will require refinement. Just repeat the Analysis & Design process for each of these.

Implementation

Implementation 1

class DrawSquare1 {
  public static void main(String args[]) {
    // Initialization
    Island maui = new Island(200,200);
    Turtle tim = new Turtle();
    maui.putTurtleAtCenter(tim);
    
    // Do the work - Draw Square
    tim.tailDown();
    // Draw first side
    tim.move(75.0);
    // Draw second side
    tim.turnLeft(90);
    tim.move(75.0);
    // Draw third side
    tim.turnLeft(90);
    tim.move(75.0);
    // Draw fourth side
    tim.turnLeft(90);
    tim.move(75.0);
    
    // Cleanup
    // Face in starting direction and pickup tail
    tim.turnLeft(90);
    tim.tailUp();
  } // End main()
} // end class DrawSquare1

Improvements for Reusability

  • To improve the reusability of the code, use symbolic values instead of manifest constants
  • This allows the code to be reused more easily
  • If we wish to change the size, we update the code in only one location!

Implementation 2

class DrawSquare2 {
  public static void main(String args[]) {
    // The length of the side is now a symbolic
    // value: len
    double len = 75.0;
    // Initialization
    Island maui = new Island(200,200);
    Turtle tim = new Turtle();
    maui.putTurtleAtCenter(tim);
    
    // Do the work - Draw Square
    tim.tailDown();
    // Draw first side
    tim.move(len);
    // Draw second side
    tim.turnLeft(90);
    tim.move(len);
    // Draw third side
    tim.turnLeft(90);
    tim.move(len);
    // Draw fourth side
    tim.turnLeft(90);
    tim.move(len);
    
    // Cleanup
    // Face in starting direction and pickup tail
    tim.turnLeft(90);
    tim.tailUp();
  } // End main()
} // end class DrawSquare2

Next Improvement for Reusability

  • Code allows one specific turtle, tim, to draw a square
  • Better to define a specialized Turtle class that supports drawing squares
  • Changes:
    • Initialization no longer needed
    • Since we do not know who the turtle will be, "tim" is replaced with "this" which references the current instance of the class (i.e. whichever turtle is being told to draw the square)

Tempting, but wrong!

class GeoTurtle extends Turtle {
  public void drawSquare() {
    // same code as before dropping the
    // initialization section and replacing "tim"
    // with "this"
    double len = 75.0;
    
    // Draw Square
    this.tailDown();
    // Draw first side
    this.move(len);
    // Draw second side
    this.turnLeft(90);
    this.move(len);
    // Draw third side
    this.turnLeft(90);
    this.move(len);
    // Draw fourth side
    this.turnLeft(90);
    this.move(len);
    
    // Cleanup
    // Face in starting direction and pickup tail
    this.turnLeft(90);
    this.tailUp();
  } // End drawSquare()
} // end class GeoTurtle

Implementation 3 - the right way!

class GeoTurtle extends Turtle {
  public void drawSquare( double len ) {
    // same code as before dropping the
    // initialization section and replacing "tim"
    // with "this"
    
    // Draw Square
    this.tailDown();
    // Draw first side
    this.move(len);
    // Draw second side
    this.turnLeft(90);
    this.move(len);
    // Draw third side
    this.turnLeft(90);
    this.move(len);
    // Draw fourth side
    this.turnLeft(90);
    this.move(len);
    
    // Cleanup
    // Face in starting direction and pickup tail
    this.turnLeft(90);
    this.tailUp();
  } // End drawSquare()
} // end class GeoTurtle

Using the new Class

class DrawSquare3 {
  public static void main(String[] args) {
    // Initialization
    Island maui = new Islans(200,200);
    GeoTurtle tim = new GeoTurtle();
    maui.putTurtleAtCenter(tim);
    
    // Draw the square
    tim.drawSquare(75.0);
  } // End main
} // End Class DrawSquare3

Final Improvement for Reusability

  • It is likely that we will need to draw other shapes than squares
  • For example, a rectangle
  • Since a square is a general case of a rectangle (width=height) we could use the drawRectangle method to implement drawSquare

Implementation 4

class SquareDrawingTurtle extends RectangleDrawingTurtle {
  public void drawSquare( double len) {
    this.drawRectangle(len,len);
  } // end drawSquare() method
} // end SquareDrawingTurtle

Using the new Class

class DrawSquare4 {
  public static void main(String[] args) {
    // Initialization
    Island maui = new Island(200,200);
    SquareDrawingTurtle tim = new SquareDrawingTurtle();
    maui.putTurtleAtCenter(tim);
    
    // Draw the square
    tim.drawSquare(75.0);
  } // End main
} // End Class DrawSquare4

Implementation 5

class GeoTurtle extends Turtle {
  public void drawSquare( double len ) {
    this.drawRectangle(len,len);
  } // end drawSquare() method

  public void drawRectangle ( double sideA, double sideB ) {
    // code to implement drawRectangle
  } // end drawRectangle() method
} // end GeoTurtle class

Using the new class

class DrawSquare5 {
  public static void main(String[] args) {
    // Initialization
    Island maui = new Island(200,200);
    GeoTurtle tim = new GeoTurtle();
    maui.putTurtleAtCenter(tim);
    
    // Draw the square
    tim.drawSquare(75.0);
  } // End main
} // End Class DrawSquare5

Continue with CIS 3020 Part 3