Difference between revisions of "CIS 3020 Part 2"
Line 523: | Line 523: | ||
} // End Class DrawSquare5 | } // End Class DrawSquare5 | ||
</pre> | </pre> | ||
+ | ==Continue with [[CIS 3020 Part 3]] |
Revision as of 11:28, 21 February 2007
Contents
- 1 Characteristics of Object Oriented Programming
- 1.1 A program consists of a set of objects
- 1.2 When a program is executing, everything is an object
- 1.3 Each object has its own memory or state
- 1.4 Each object is an instance of a single class
- 1.5 The class defines the state and behaviors
- 1.6 Classes are organized into a single rooted inheritance hierarchy (or tree)
- 2 Unified Modeling Language
- 3 Simple Program
- 4 Real Program
- 5 Terminology
- 6 Software Life Cycle
- 7 Traditional Software Life Cycle costs
- 8 Important Issues in the Real World
- 9 Problem Solving Methodology
- 10 Design
- 11 Object Oriented Design
- 12 UML - Revisited
- 13 Problem
- 14 Implementation
- 14.1 Implementation 1
- 14.2 Improvements for Reusability
- 14.3 Implementation 2
- 14.4 Next Improvement for Reusability
- 14.5 Tempting, but wrong!
- 14.6 Implementation 3 - the right way!
- 14.7 Using the new Class
- 14.8 Final Improvement for Reusability
- 14.9 Implementation 4
- 14.10 Using the new Class
- 14.11 Implementation 5
- 14.12 Using the new class
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? |
---|---|---|
|
|
|
- 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
- Aggregation
- 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
|
<<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:
- Initialization
- Do the required work
- Clean up
It is often helpful to try the task by hand to make sure you know what to do
- Design of the Algorithm
- Initialization
- Create an island
- Create a turtle
- Put the turtle on the island
- Do the work: tell turtle to draw square
- Put down the tail
- Draw first side
- Move forward 75 units
- Draw second side
- Turn left
- Move forward 75 units
- Draw third side
- Turn left
- Move forward 75 units
- Draw fourth side
- Turn left
- Move forward 75 units
- Cleanup
- Point in the starting direction
- Turn left
- Pick tail up
- Point in the starting direction
- 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