Computer Science 202


The scope and sequence of this course shall be found in the course Introduction to Computer Science using Java by Bradley Kjell - chapters 25- 35 and chapters 50 - 64. Concepts covered in the Kjell course are reinforced by chapters 8 - 10 of How To Program Fourth Edition by Harvey and Paul Deitel.


This course is the last prerequisite course to gain entry to the grade 12 IB Computer Science courses.


This course, Computer Science 202, assumes that a student has programmed in Java and is comfortable using selection statements, loops, methods and arrays; precisely it assumes that a student has the background equivalent to chapters 2 through 7 of the Deitel textbook, How To Program Fourth Edition.

This course addresses three primary objectives:

  1. Students will become knowledgeable and skillful in applying structures and techniques of OOP (Object Oriented Programming) in solving problems.

  2. Students will become knowledgeable and skillful in the use of the BlueJ IDE, a development environment developed specifically for students learning object oriented programming with the Java computer programming language. Students should immediately download both the BlueJ IDE and the BlueJ Tutorial. Students are required to use the BlueJ IDE throughout this course.

  3. Using the BlueJ IDE, students will become knowledgeable and skillful in applying JUnit Testing in the design and implementation of their programmes.

  4. BlueJ IDE, students will become knowledgeable and skillful in constructing appropriate Javadoc comments in their source code and generating a corresponding HTML Javadoc file from those internal Javadoc comments.


CLICK HERE TO VIEW PRIMARY RESOURCES USED IN THIS COURSE.


ChapAssignment

Std
Docs

Documentaion Conventions

The following documents were lifted from standard conventions for the Spring 2003 course, Computer Science 110: Introduction to Programming at Java Kalamazoo College. It is expected that the work of students of Computer Science 202 will conform to these conventions.

BlueJ

[Home of BlueJ]

BlueJ Integrated Development Environment

BlueJ is an IDE created explicitly for learning OOP with Java.

Students must prepare to learn with the BlueJ IDE. First, do The BlueJ Tutorial. The tutorial explains how to download, install and use the BlueJ IDE.

BlueJ is a special Java IDE that was developed and maintained by a joint research group at Monash University, Melbourne, Australia, and the Mćrsk Institute at the University of Southern Denmark for the explicit purpose of learning to program in Java generally, and for learning object oriented programming (OOP) in Java in particular.

The most important thing that distringuishes BlueJ from other Java IDEs is that you may "directly interact with single objects of any class and execute their public methods. This is very helpful during development of an application - you can test classes individually as soon as they have been written. There is no need to write the complete application first." [quoted from The BlueJ Tutorial, page 8]

GUI

Graphical User Interface Programming

Segue to OOP

This is the beginning of Computer Science 202. Experience has shown that you will need to be comfortable with SWING's GUI components so that you can later focus on learning to understand and compose your own OOP programs.

During the initial two weeks of this course, students are required to first navigate their way through an easily understood set of tutorials for learning the basics of Java's AWT (Abstract Windowing Toolkit) and SWING classes that enable a GUI interface in Java are chapters 55-64 of Kjell's Introduction to Computer Science Using Java. Students should save the most recent version on their computer in case the site is down or the Internet slow when you wish to use it.

There is a quiz for each Kjell Tutorial, chapters 55-64 that you will write.

One site that gives a marvelous feat at clarifying Java code with diagrams and tables is the Markus Falkhausen Java Site.

In the late 1970's a computer was developed that revolutionized the way we do input and output. That computer was the Xerox Star, developed during the 1970's at Xerox Parc in California. The engineers from Apple Computer saw, then studied, and then copied the interface of the Xerox Star. In 1984 Apple released their first Mac personal computer which was essentially a clone of the Xerox Star. Some years later MicroSoft also copied the GUI interface of the Xerox Star and called it "Windows".

The Java programming language has libraries of classes that allow the Java programmer to do GUI input and output using windows (Java calls them "frames"), dialog boxes, buttons, sliders, and other GUI "components".

It is expected that students taking further Computer Science courses at Sir Winston Churchill will use a GUI interface for doing input and output. It is fun to create GUI interfaces. It is easier for users to "talk" with a program that has a GUI interface. Virtually all commercial and professional programs on the market today use a GUI interface. GUI interfaces are the most familiar applications of OOP (Object Oriented Programming) techniques that most students have seen. These are all good reasons to use GUI interfaces.

Do Chapters 25 and 55-64 of the Kjell Course.

Audio

Intro To SWING Audiocast

Sun MicroSytems has a wonderful array of resources for teaching Java, including their Technology Audiocasts that deliver technology tutorials in MP3 and RealAudio formats as well as corresponging pdf files. One audiocast is the Intro To SWING Audiocast.

This 40 minute presentation uses language that is unfamiliar to most students at the Computer Science 202 level, but only by reaching for what is over our head can we hope to pull ourselves up. You will remember what you now hear, even if you won't completely understand it at this point. But by hearing and thinking about formerly unfamiliar ideas and processes, you will be able to draw upon current efforts when, in the future, you go after the ideas from a different angle with different resources.

Litvin

Litvin's GUI Components and Events

Gary and Maria Litvin, authors of Advanced Placement computer science text books, created powerpoint slide shows for their textbook, Java Methods, An Introduction to Object-Orient Programming. Note that this particular chapter, numbered 15, is late in their text book and, in any case, assumes that students have progressed through the earlier 14 chapter. Thus the slide show refers to concepts that Computer Science 101 students are not yet aware of or comfortable with. That said, take a peek at Litvin's GUI Components and Events. Much of their "advanced" material will by now be familiar.

GUI
Code

Graphical User Interface

In Computer Science 201 you were given the following short examples of the Java's SWING GUI classes. They are reproduced here so that you may again refer to them as you prefer. Use the following snippets of code as models for various components. They are taken from the book, Java: Your Visual Blueprint for Building Portable Java Programs.

GUI COMPONENTS
EVENT HANDLING

MEM

Java's Memory Model

Review Java's Memory Model with the powerpoint slide show, Truth or Consequences A Discussion of Java’s Memory Model

Main

Should every class have a main method?

A 'main' method does not have a good justification in the OO universe. Its existence is caused by a technical requirement (to somehow link your application to the operating system's invocation mechanism) and not by the object-oriented model that an application represents."

As such, it is different from the model part of the application and, in the name of cohesion, should be textually separated. It is clearer and more logical to pull main out into a separate class with its own declared purpose: to start up the application, And nothing else." -- Michael Kölling [SMTP:mik@mip.sdu.dk], quoted November 12, 2003

On all of my production software projects I require the inclusion of a "static void main" method in every class. That method is used for the purposes of testing. It means that we can test every class in the product simply and independently. The only exceptions are those classes for which "main" is used as the product's "startup". Note that we do this even though we also use JUnit and have unit testing classes for every class as well.

I don't see this as violating abstract data typing, information hiding, or encapsulation. Rather, I see it as good software engineering practice. -- Dr. Jody Paul [SMTP:jody@acm.org], quoted November 12, 2003

Some people use the fact that a public static void main method can be included in any class as a way of building some test code right into the class. This use of main is not the client code that uses the class, but special test code that is used to test when the class is developed. Then write a separate driver class that would use the class.

If the main within the class is intended as a driver, that diverges from the principles of O-O and information hding. -- Chris Nevison [SMTP:chris@cs.colgate.edu], quoted November 12, 2003

Laziness is one (poor) reason to put the main in a class. The main program in Larry's example program below certainly does violate the principles of encapsulation and data hiding, just as he says. Putting the main method for an application in a separate class that represents the application as a whole is a clean design choice.

Some people, though, put a main method in each class for testing purposes, and this is certainly a defensible design choice. The main method in this case just runs through a series of test cases to test every method in the class (using objects and proper encapsulation). I have occasionally used this technique in the past, although I am moving towards using JUnit instead. JUnit is free software that provides a simple technique for generating and running a test suite. It makes regression testing easy, and the positive feedback from successful regression tests actually encourages students to test as they make modifications. --Alyce Brady, Kalamazoo College, quoted November 12, 2003

Object
Game

An Exercise For Studying Objects

Professor Joseph Bergin from Pace University in New York created this exercise for beginners of Object-Oriented Programming. It might be fun to try it at this beginning part of the course.

Abstract
Class

What Is The Difference Between An Abstract Class & An Interface

A "new" Advanced Placement computer science teacher asked this question in December of 2004. If you too wondered about this, check out the replies at How An Interface Differs From An Abstract Class

CRC
Cards

CRC (Class-Responsibility-Collaboration) Cards

If time permits, it should be fun to experiment with CRC (Class-Responsibility-Collaboration) Cards, an activity used by a number of computer programming teachers throughout North America. The following links explain and implement this learning strategy.

OOP
Basics


Object-Oriented Language Basics

The following series of articles by Jeff Friesen were published in Java World during 2001. Students who find our textbook treatments to be stuffy and formal may find Jeff's "hobby-geek" enthusiasm to be refreshing.

TOPICStudy GuideSource Code
1. Declare Classes, Create Objects Study Guide 1 Source Code 1
2. Declare & Access Fields & Methods Study Guide 2 Source Code 2
3. Composition: Build Objects From Other Objects Study Guide 3 Source Code 3
4. Inheritance: Build Objects In Layers Study Guide 4 Source Code 4
5. The Root of all Classes Study Guide 5 Source Code 5
6. Interfaces for Multiple Inheritance, etc. Study Guide 6 Source Code 6
7. Polymorphism & Other Generalities Java 101 Study Hall
Study Hall Solutions
Source Code 7

this

this == instance variable

Read:    How do college professors and text authors explain: this?

static

Using A Static Variable

Read:    How do college professors and text authors explain: a static variable?

8

Object-Based Programming

Assignments

  1. Preview Fran Tree's powerpoint slide show Object Oriented Programming.

  2. Do Kjell tutorials 25, 26, 27, 28, 29, 30, 31, 32, 33, 34A, 34B, and 35 covering "Object Oriented Programming".

  3. From Java By Example by Johannes Wallroth, do the theory and examples of Section Five: Objects and Classes.

  4. Overview the Chapter 8 PowerPoint Slideshow. This just gives you the "lay of the land" for now. Later, after you read the chapter, this slide show will be a very meaningful review.

  5. Read the chapter actively! Execute and tinker with the code. Draw diagrams of concepts.

  6. Implement and run the Chapter 8 source code.

  7. Read Eck's Explanation of Objects and Classes
    Read Chapter 5: Programming in the Large II: Objects and Classes from the 4th edition of David Eck's book Introduction to Programming Using Java.

  8. Read the Optional Case Study (Thinking About Objects: Starting to Program the Classes for the Elevator Simulation) (434-437)

  9. Mentally review the "Self-Review Exercises" (440) (The section containing the answers to these questions follow in the book itself.) This may easily alert you to potential holes in your knowledge and skills.

  10. Study the following practice exercises on the left to get a good feel for how to solve problems in this chapter. Clicking on their links will present you with the publisher's solutions. Then solve and submit solutions to exercises on the right that will be reviewed for grading purposes.

    Pay special attention to the rational numbers exercise #8.03. This is a classic problem that serves as an excellent model for how to develop a class. This model is used in many textbooks to exemplify the construction of a class.

    Note that this chapter requires that you develop separate classes of code that may be used by client programs. You should therefore expect to develop at least two files for each exercise. One file will contain the source code for the class itself. The other file will be a driver program that uses and tests the features of the code generated by the class file.

    WARNING: Work through some or all of the practice exercises before attempting exercises to be submitted. Use the syntax and organization of the practice exercises as models. Failure to first study the practise exercises will probably result in significant frustration!

    Convention For Naming A Package: In Section 8.5 the Deitels remind us of Sun MicroSystems' convention for naming a package of classes. Students at Churchill are asked to name their packages starting with "swc" (Sir Winston Churchill High School), then an abbreviation of the course name (eg: "cs202"), followed by the student's initials (eg: "gdd" for Gerry Douglas Donaldson), followed by the author's name of the textbook being used ("deitel"), followed by a reference to the chapter and exercise numbers ("c8e18"). Thus, the first statement of a file containing a "package" could be:    package  swc.cs202.gdd.deitel.c8e18

    Private or Protected:Protected in Java doesn't mean what it would mean in most languages -- visible to objects of this class and its subclasses. Instead it means visible to objects of this class, its subclasses, or any other class in the same package as this class. So, protected does NOT stop unrelated classes from seeing specified fields and methods.

    One of the best reasons for declaring variables(fields) to be private is quality assurance of the object. By having the modifiers as provided by the original class writer can you assure yourself and your company that the data portion of the object has not been modified in a way that was not specified in a software requirement document. If you make the fields protected, then a writer of a subclass can develop their own methods that modify the field. With private fields, once the class has been through your company's quality assurance/configuration management software test process, the users (who are usually the owners of the data) can be assured that only the approved methods for modifying their data are going to be used.

    Programming Exercises For PracticeProgramming Exercises For Grades
    8.03:     Create class to manipulate rational numbers.
    8.05:     Error check initializer values.
    8.08:     Use set and get methods to access and error check private variables.
    8.09:     Set and check coordinates of rectangle class.
    8.19:     Create a drawing applet that randomly draws lines, rectangles and ovals.
    8.12:    

    Create class TicTacToe

    In solving exercise 8.12, create the Tic Tac Toe grid without using a layout manager. Instead use absolute positioning.

    8.16:     Create class SavingsAccount
    8.17:     Create class IntegerSet
    See a discussion of set theory.

  11. Include the following documentation for each exercise that is submitted to be graded.

    You will want to read the first couple of chapters of an excellent online textbook, Java An Object First Approach to learn about some new techniques that are used to plan and document objects and programs.

    1. List the specifications of the program. These may be deduced in the statement of the exercise.

    2. Source Code of all new files: html file for applets, class file(s), driver program(s).

      Print the source code and screen dump in a Word Processor, two pages per side, double sided. Simultaneously pressing [Alt][PrtScn] will copy the GUI output to the clipboard from whence you can paste it just below your source code. Use a non-proportional font (example: Courier New) to maintain the vertical alignment of the stucture of your source code.

    3. Screen Shots of Input and Output dialog boxes.

      Where I/O (Input/Output) inlcudes multiple GUI (Graphical User Interface) dialog boxes, include at least one screen shot for each input and output dialog box. Where there are various types of dialog boxes and/or messages and/or types of data, include a "reasonable" number of screen shots.

      Typically there will be 1-2 screen shots showing input and 1-2 screen shots showing output. In extraordinary cases, there could conceivably be a dozen or more screen shots. What is "reasonable" is the product of using reason (thought) and reasons (related information). BE REASONABLE!

    4. Trace Table of Changes in Values of the Variables During Execution.

  12. There will be a multiple choice test at the end of this chapter.

9

Object-Oriented Programming

Assignments

  1. Do Kjell tutorials 50, 51, 52, 53, and 54 covering "Advanced Object Oriented Programming".

  2. For a fun, light explanation of polymorphism, check out How My Dog Learned Polymorphism at the Java Ranch where you will also find an interesting example of polymorphism.

  3. The references below refer to the 4th Edition of Deitel's Java How To Program because that is, in fact, the textbook that our school purchased. However, since the Deitel 5th Edition powerpoint slideshows and corresponding sample source code are available to us, we should overview the 5th Edition powerpoint slideshows. Note that chapter 9 from the older 4th Edition was split into two chapters 9 & 10 for the 5th Edition.

  4. Overview the Chapter 9 PowerPoint Slideshow. This just gives you the "lay of the land" for now. Later, after you read the chapter, this slide show will be a very meaningful review.

  5. Read the chapter actively! Execute and tinker with the code. Draw diagrams of concepts.

  6. Implement and run the Chapter 9 source code.

  7. Read the Optional Case Study (Thinking About Objects: Incorporating Inheritance into the Elevator Simulation) Note: The chapter 9 section of this case study in the textbook (Section 9.23 on pages 513-520) is the prepublication version and was published in error. Click on either the foregoing or following link in this paragraph for the corrected pdf version.

  8. Mentally review the "Self-Review Exercises" (531) (The section containing the answers to these questions follow in the book itself.) This may easily alert you to potential holes in your knowledge and skills.

  9. Professor Joseph Bergin of Pace University in New York is a brilliant computer scientist. Read Joseph Bergin's four email discussions concerning polymorphism and how it relates to using inheritance versus an interface to define classes and types. You may not understand the issues at this point, but Bergin's email discussions will immediately expose you to some profound issues concerning computer programming languages. That in itself is a treat.

    1. Bergin's 1st Email Concerning Polymorphism
    2. Bergin's 2nd Email Concerning Polymorphism
    3. Bergin's 3rd Email Concerning Polymorphism
    4. Bergin's 4th Email Concerning Polymorphism
  10. Volume 8, Issue 9 of the Java Developer's Journal had a really interesting article by Yakov Fain entitled Are You Using Abstract Classes, Polymorphism and Interfaces? Read it now with joy and comprehension. Play with the source code.

  11. You will find a thread concerning Usefulness of Java Interfaces from the Java Ranch Big Moose Saloon to be interesting and clarifying of a number of points.

  12. Study the following practice exercises on the left to get a good feel for how to solve problems in this chapter. Clicking on their links will present you with the publisher's solutions. Then solve and submit solutions to exercises on the right that will be reviewed for grading purposes.

    Note that this chapter requires that you develop separate classes of code that may be used by client programs. You should therefore expect to develop at least two files for each exercise. One file will contain the source code for the class itself. The other file will be a driver program that uses and tests the features of the code generated by the class file.

    All classes must now be saved in a packaged named after the student's name. Remember that the directories identified by the package will be automatically created during compilation. For example, the first processing line of code in the source code of a class definition file might be:

    package org.donaldson.gerry.jhtp4.ch09 ; // location of class definition file

    A client program that imports a class might then have the following line near the beginning of the source code:

    import org.donaldson.gerry.jhtp4.ch09.* ;

    Programming Exercises For Practice Theory Exercises for Grades Programming Exercises For Grades
    9.10:     Rewrite using composition instead of inheritance.
    9.11:     Write with inheritance and again with composition.
    9.12:     Does the subclass-is-a-superclass object relationship hold?
    9.13:     Indicate common attributes and behaviors.
    9.14:     Write an inheritance hierarchy.
    9.16:     Give advantages to programming "in the general" with polymorphism rather than "in the specific".
    9.17:     Discuss problems of using switch logic.
    9.18:     Distinguish "inheriting interface" from "inheriting implementation".
    9.19:     Distinguish "abstract methods" from "nonabstract methods".
    9.20:     Answer & explain: Must all methods in an abstract interface be declared abstract?
    9.22:     How does polymorphism promote extensibility?
    9.15:     Develop a shape class hierarchy.
    9.26:     Write classes & a driver for the Shape class hierarchy.
    9.27:     Rewrite Exercise 9.26 to use a Shape interface instead of an abstract Shape class.
    9.28:     Modify Exercise 8.19 to create a drawing application.
    9.29:     Change 9.28 single MyShape reference into an array of MyShape references.

  13. Include the following documentation for each exercise that is submitted to be graded.

    1. List the specifications of the program. These may be deduced in the statement of the exercise.

    2. Source Code of all new files: html file for applets, class file(s), driver program(s).

      Print the source code and screen dump in a Word Processor, two pages per side, double sided. Simultaneously pressing [Alt][PrtScn] will copy the GUI output to the clipboard from whence you can paste it just below your source code. Use a non-proportional font (example: Courier New) to maintain the vertical alignment of the stucture of your source code.

    3. Screen Shots of Input and Output dialog boxes.

      Where I/O (Input/Output) inlcudes multiple GUI (Graphical User Interface) dialog boxes, include at least one screen shot for each input and output dialog box. Where there are various types of dialog boxes and/or messages and/or types of data, include a "reasonable" number of screen shots.

      Typically there will be 1-2 screen shots showing input and 1-2 screen shots showing output. In extraordinary cases, there could conceivably be a dozen or more screen shots. What is "reasonable" is the product of using reason (thought) and reasons (related information). BE REASONABLE!

    4. Trace Table of Changes in Values of the Variables During Execution.

  14. There will be a multiple choice test at the end of this chapter.

10

Strings and Characters

Assignments

  1. Overview the Chapter 10 PowerPoint Slideshow. This just gives you the "lay of the land" for now. Later, after you read the chapter, this slide show will be a very meaningful review.

  2. Read the chapter actively! Execute and tinker with the code. Draw diagrams of concepts.

  3. Implement and run the Chapter 10 source code.

  4. Read the Optional Case Study (Thinking About Objects: Event Handling) (583-590)

  5. Mentally review the "Self-Review Exercises" (594) (The section containing the answers to these questions follow in the book itself.) This may easily alert you to potential holes in your knowledge and skills.

  6. Sudy the following practice exercises on the left to get a good feel for how to solve problems in this chapter. Clicking on their links will present you with the publisher's solutions. Then solve and submit solutions to exercises on the right that will be reviewed for grading purposes.

    Note that this chapter requires that you develop separate classes of code that may be used by client programs. You should therefore expect to develop at least two files for each exercise. One file will contain the source code for the class itself. The other file will be a driver program that uses and tests the features of the code generated by the class file.

    WARNING: Work through some or all of the practice exercises before attempting exercises to be submitted. Use the syntax and organization of the practice exercises as models. Failure to first study the practise exercises will probably result in significant frustration!

    Programming Exercises For PracticeProgramming Exercises For Grades BONUS Programming Projects
    10.03:     Deal a five card poker hand.
    10.07:     Compare two strings input by the user.
    10.11:     Encode English language phrases into pig Latin.
    10.14:     Alphabetize a list of strings.
    10.16:     Determine the number of occurrences of a character in the text.
    10.18:     Output only strings beginning with the letter b.
    10.04:     Deal and evaluate two five-card poker hands.
    10.09:     Create sentences with random number generation.
    10.13:     Display tokens in reverse order.
    10.15:     Output text in uppercase and lowercase letters.
    WARNING: These projects are challenging and time consuming.

    10.23:     Verify authorship by comparing different manuscripts.
    10.27:     Translate an English phrase into Morse Code and vice versa.
    10.29:     Design and implement a Spelling Checker.
    10.30:     Design and implement a Crossword Puzzle Generator

  7. Include the following documentation for each exercise that is submitted to be graded.

    1. List the specifications of the program. These may be deduced in the statement of the exercise.

    2. Source Code of all new files: html file for applets, class file(s), driver program(s).

      Print the source code and screen dump in a Word Processor, two pages per side, double sided. Simultaneously pressing [Alt][PrtScn] will copy the GUI output to the clipboard from whence you can paste it just below your source code. Use a non-proportional font (example: Courier New) to maintain the vertical alignment of the stucture of your source code.

    3. Screen Shots of Input and Output dialog boxes.

      Where I/O (Input/Output) inlcudes multiple GUI (Graphical User Interface) dialog boxes, include at least one screen shot for each input and output dialog box. Where there are various types of dialog boxes and/or messages and/or types of data, include a "reasonable" number of screen shots.

      Typically there will be 1-2 screen shots showing input and 1-2 screen shots showing output. In extraordinary cases, there could conceivably be a dozen or more screen shots. What is "reasonable" is the product of using reason (thought) and reasons (related information). BE REASONABLE!

    4. OPTIONAL: JSP Notation (Jackson Structured Programming Notation) showing the design and documentation of actions.

    5. OPTIONAL: Class Diagram showing the services that an instance of the class being designed will offer its clients.

    6. OPTIONAL: Instance Diagram illustrating the actual object instances which are used in the client program.

    7. OPTIONAL: Trace Table of Changes in Values of the Variables During Execution.

  8. There will be a multiple choice test at the end of this chapter.


[Counter On Strike [Home of Gerry Donaldson's Com Sci Gate]
[Gerry Donaldson's Email Address]
csgate@donaldson.org
ICQ# 62833374
[EFC Blue Ribbon - Free Speech Online]

URL:   http://www.donaldson.org/    Last Revised:   March 14, 2004