Supplemental Problems

Supplemental Problems extend the range of problems considered in the course and help sharpen problem-solving skills.

Quick links: 1, 2, 3

Instructions:

Each program for a supplemental problem must follow these instructions:

1. All code must follow the Java/CSC 207 Style Guide
2. Following Javadocs guidelines
   • Include comments within your code to clarify the logic and structure of your code.
     • Comments should identify the logical sections of the work and provide a high-level overview of the main steps being performed.
     • Comments should clarify any complex logic or data structure — what is the motivating idea behind the block of complex code?

     • Include within your code, javadoc documentation for

       • each class
       • each field
       • each method (including each parameter and any return data
     • Comments should not simply repeat the code. For example, the following javadoc comments are not helpful and detract from readability:

          /***
           * equals is a method
           * @param first is a String
           * @param last is a String
           * @returns a boolean value
           */
           equals (String first, String last)
       

3. The first lines of any Java program should be comments containing your name, your mailbox number, this course number (207), an identification of assignment being solved, and an Academic Honesty certification. (You may not talk to anyone, except the instructor, a class mentor, or an evening lab tutor, for any Supplemental Problem.) For example:

       /*****************************************************************
        * Henry M. Walker                                               *
        * PO Box Science II                                             *
        * Program for CSC 207                                           *
        *   A Simple Class Hierarchy                                    *
        * Assignment for Friday, September 28                           *
        *****************************************************************/
   
   
       /* ***************************************************************
        * Academic honesty certification:                               *
        *   Written/online sources used:                                *
        *     [include textbook(s),                                     *
        *       CSC 207 labs or readings;                               *
        *       complete citations for Web or other written sources]    *
        *     [write "none" if no sources used]                         *
        *   Help obtained                                               *
        *     [indicate names of instructor, class mentors              *
        *      or evening lab tutors, consulted                         *
        *      according to class policy]                               *
        *     [write "none" if none of these sources used]              *
        *   My signature below confirms that the above list of sources  *
        *   is complete AND that I have not talked to anyone else       *
        *   [e.g., CSC 161 students] about the solution to this problem *
        *                                                               *
        *   Signature:                                                  *
        *****************************************************************/
   

4. All code must be logically organized into appropriate classes.
5. All code must be tested. A document should explain the rationale behind the testing: what situations can arise in the running of this code, what tests have you designed and run to address each of these situations, and do the test runs provide correct results?
6. All files (e.g., code, testing results, and correctness commentary) must be submitted via GitHub, based on the URL given for the specific assignment.

Some Grading Notes:

• Since every programming task should yield readable and carefully tested code, the grading of all programs for this course will begin with the following algorithm (expressed in C or Java format):

  
     if ((no_comments)
          || (missing pre- or post-conditions)
          || (formatting_does_not_show_structure)
          || (long_methods_not_divided_into_sections_with_clarifying_comments)
          || (no_evidence_of_compilation)
          || (no_test_plan___no_listing_of_circumstances__OR__no_listing_of_test_cases)
          || (no_test_runs)
          || (no_commentary_on_correctness))
          || (no_signed_certification_regarding_sources_and_help)
       return (no_grade);
    
  

Grading Forms

Two grading forms will be used in the grading of each supplemental problem.

• A general form provides feedback on many elements common to most or all object-oriented programs.
  (This form is under development and may evolve through this semester.)
• A problem-specific form that evaluates specifics for an individual problem.

A Simple Class Hierarchy

This problem introduces some simplified elements related to a program to track shopping in a grocery store. Many details would be expanded greatly for a real application, but this problem might make a [small] start.

For this problem, submit your code to the GitHub Classroom assignment for https://classroom.github.com/a/nJNLE3TG.

Items available in a grocery store might be categorized as produce (e.g., vegetables, fruit, cheese, meat, etc.), beverages (bottled water, milk, soft drinks, energy drinks, etc.), and packages (boxes of crackers, noodles, tea, etc.). A class hierarchy to model this categorization of items follows:



To clarify,

• All materials in a store fall within a general category of a class Item.

  • Every Item has a protected name field of type String that indicates the name of the grocery item (e.g., can of soup, box of macaroni and cheese, bottle of Diet Pepsi, etc.).
  • Every Item has a protected cost field of type double that indicates the purchase price of this grocery item.
  • Every Item has a method getCost that returns the cost of the item.
  • Every Item has a method costPerUnit that computes and returns the amount a user pays per unit. Since an Item knows nothing about its units, this computation for a plain Item is the same as cost — the cost for 1 Item unit. (The computation of costPerUnit may differ in subclasses.)
  • Every Item has a method toString that returns a nicely-formatted string containing name and cost information.

• Class Produce is a subclass of Item of fresh, uncooked ingredients.

  • Every Produce has a private field pounds of type double that gives the weight of the object in pounds.
  • Every Produce has a private field category of type String that gives the type of material, such as a vegetable, fruit, cheese item, ice cream, etc.
  • Within Produce, method costPerUnit will need to return the cost per pound of the object, and toString should report weight and category, in addition to the data stored as part of an item.

• A Beverage is an Item for drinking.

  • Each Beverage container holds a specified amount of liquid, reported in the private int field fluidOunces.
  • When sold, the customer must pay the regular price plus a deposit, recorded in a private double field containerDeposit
  • Within Beverage, method costPerUnit will need to return the cost per fluid ounce of the object, and toString should report number of fluid ounces and the amount of the deposit, in addition to the data stored as part of an item. In addition, method getCost will need to include both the actual cost of the item, but also the container deposit.

• A Package is a subclass of Item that comes in a rectangular box.

  • Each Package object has dimensions for length, width, and height that are stored as private double fields.
  • Each Package holds an amount of materials, reported in the private int field ounces.
  • Within Package, toString should report the size (length, width, height) and weight (ounces) of the object, in addition to the data stored as part of an item. (Note that a Package is considered a single unit, so the costPerUnit method of Item need not be modified for this subclass.)

For this problem, you should implement the following:

1. Class definitions for Item and its subclasses Produce, Beverage, and Package

2. A ShoppingCart class, modeled upon the SchoolDirectory class from the CSC 207 lab Generalization, Polymorphism, and Exceptions. The ShoppingCart class should have these features:

   • A private array Cart of Item objects:
     • The size of Cart is given by private field maxSize.
     • Field currentSize gives the actual number of objects stored in Cart, in positions Cart[0] to Cart[currentSize-1].
   • A method addItem places a new item object into the array, expanding the array as needed, and incrementing currentSize
   • A method printCart should provide a listing of all items in the cart.
   • A method totalCost should compute the total cost of all items in the cart.
   • A method numberInCart should take a parameter String groceryName and return how many items in the current shopping cart have that name.
     Notes:
     • An easy way to compare strings is to use the built-in compareTo method. That is, if str1 and str2 are two strings, then str1.equals(str2) returns true if the two strings are the same (including case) and false if the two strings differ in any way.
     • Although class Item and its subclasses contain a name field, this field is protected. Explain why numberInCart cannot be implemented in ShoppingCart with the specified fields and method for Item and its subclasses.
     • To implement numberInCart, class Item could be expanded in two ways (for reasons of correctness and security, we do not consider changing name to public.)
       • A method getName() could be added to class Item to return the name string.
       • A method equals (String str) could be defined in class Item which returns true if the name in the Item matches str and returns false otherwise.
       Modify Item with one of these approaches in order to implement numberInCart. Include a comment explaining why you chose this approach for expanding Item.

Draft problem-specific grading form

Credits and email Addresses

Not required / Extra Credit Option

2. Prolog: Many discussions of data organization focus on individual data structures, such as data organized into linked lists or trees.

   • This problem suggests one way in which multiple data structures might be combined in solving a multi-faceted problem.

   • An alternative solution to problem might utilize a database, such as MySQL, for data storage and retrieval. Although databases are widely used in contemporary applications, database technology is beyond the scope of CSC 207, and the solution of this supplemental problem is designed to provide practice with both singly-linked lists and binary search trees.

   Problem Statement: An abbreviated system containing student data will store both usernames and credits toward graduation.

   • To allow efficient inserting, searching, and printing of student information, the student data will be stored in a binary search tree, ordered by username.

   • To allow printing of students in increasing order of credits toward graduation, the student data will also be stored in a singly-linked list, ordered by credits.

   Methods for this problem include:

   /**
    * a single new node is created,
    *   containing a student's username and credits toward graduation
    * @pre
    *    username is not NULL
    * @post
    *    the new node is inserted to the binary search tree
    *    containing all student records, ordered by username
    * @post
    *    the node is also inserted into a singly-linked list,
    *    ordered by credits toward graduate
    */
    public void insert (String username, double credits);
   
   /** search tree for username to obtain credits for graduation
    * @pre
    *    none
    * @returns
    *    if the username appears in a node,
    *    the credits toward graduate are returned
    * @throws
    *    if the username does not appears in a node,
    *    throws NoSuchElementException
    */
    public double findCredits (String username);
   
   /**
    * update credits toward graduation for
    * @pre
    *    username is not NULL
    * @pre
    *    newCredits gives the new number of credits for the username
    * @post
    *    credits toward graduation is updated with the new parameter
    * @post
    *    node is not moved on the binary search tree
    * @post
    *    node's position on the linked list is adjusted as needed,
    *    to maintain the ordering of list nodes in ascending order
    *    by credits toward graduation
    * @returns
    *    true if username found (with node updated and moved as needed)
    *    false if username not found
    */
   public boolean updateCredits (String username, double newCredits);
   
   /**
    * print username and corresponding credits toward graduation,
    * ordered by username
    * @post
    *     each username/credits value printed on a separate line,
    *     ordered by username
    */
   public void printByUsername ();
   
   /**
    * print username and corresponding credits toward graduation,
    * ordered by credits toward graduation
    * @post
    *     each username/credits value printed on a separate line,
    *     ordered by credits toward graduation
    */
   public void printByCredits ();
   

   Programming Notes:

   • For each student, the username and credits toward graduation will be stored exactly once. (Storage of data in multiple places invites inconsistencies to arise, after data are updated in one location, but not others.)

   • Since each node will be contained in both a binary search tree and a linked list, two sets of points are needed.

   • Consistent with needs for data storage and references, a StudentNode class must contain the following fields:

         private String username;  //always stored in lowercase
         private double credits;   //credits toward graduation
         private left;             //pointer to left subtree within a tree structure
         private right;            //pointer to right subtree within a tree structure
         private next;             //pointer to next node in singly-linked list
         

   • These StudentNodes should be utilized within a Registrar class that contains root and first references for the root of the tree and the beginning of the singly-linked list.

   Example: An illustration showing 4 nodes in this structure follows.

   

Queues of Different Priorities for Printing

3. When a printer serves multiple users, users may sent several print requests to the operating system, but only one file can be printed at a time. Thus, the operating system can direct a file from one print request to the printer, but the other requests must be stored in some type of data structure. The simplest approach involves a single queue. Each user sends one or more files to the operating system, and the operating system places the print requests on a queue. The operating system then sends the files to the printer one-at-a-time from the print queue. Of course, once a printer starts to print a file, the printer must complete that job before moving onto the next print request. Although this approach is simple and treats all jobs equally, this approach has the disadvantage that many short printing jobs (of only a few pages) may have to wait substantial amounts of time for a large print job (hundreds of pages) to finish.

   One way to give some preference to certain print jobs is to create multiple queues of varying priorities. For convenience of notation, suppose a system has n queues, labeled q₀, q₁, q₂, ..., q_n-1. Suppose q_i has priority i, where priority 0 is top priority, priority 1 is the next highest priority, ..., and priority n-1 is the lowest priority. That is requests in q₀ are chosen before print requests in any other queue, and requests in q_n-1 must wait until requests from all other queues have been printed.

   The division of print requests into queues of varying priorities can work well in many cases, but this approach has the drawback that low priority print requests may never be printed if a steady stream of higher priority requests enter the system. In operating-systems jargon, this situation is called starvation; some work is never done because the system spends all of its time on other processing.

   To avoid the possibility of starvation, a typical approach is to periodically move a print request from a low-priority queue to the next higher priority queue, as this would cause any print request to eventually move up to the head of the highest priority queue. To specify this promotion from one queue to the next more precisely, suppose that every time k requests from queue q_i have been sent to the printer, the system removes a request from queue q_i+1 and enqueues the request on queue q_i.

   The Printing Protocol

   The following diagram provides an overview of the process of user submission of print requests, their placement on an appropriate queue, and their subsequent transmission to the printer for printing:

   

   The formal protocol follows:

   • At any time, a user may send a print request to the operating system.

     • The request specifies the name of the file and the number of pages to be printed.

   • The operating system uses an enqueue operation to place the print request on a queue, based on the number of pages to be printed

     • Three algorithms for determining the relevant queue are given later in this problem.

   • If the printer is idle, the operating system will select a print request from the highest priority non-empty queue.

   • If the printer is busy, the operating system simply collects print requests in its queues.

   • If the printer completes a print request, the operating system processes print requests as follows:

     • If no print requests remain unprocessed, the system waits until a new request is submitted.
     • If one or more print requests are unprocessed, the operating system uses a dequeue operation on the non-empty queue of highest priority.
     • Whenever a dequeue operation is executed k times for any queue q_i, the operating system finds the highest priority, non-empty queue q_j with j > i. The operating system then uses the dequeue operation on q_j to retrieve a print request, and that request is then immediately enqueued onto q_i

   Determining Initial Print-request Priority

   The print-queue protocol above requires the operating system to determine which queue should be used for each new print request submitted by the user. Three assignment approaches follow:

   1. All print requests are put on queue q₀; that is, only one queue is used, and requests are printed in strict FIFO order.
   2. n queues are used, and print requests are assigned initially to queues based on their size.
      • Files of size 1-10 pages go initially to queue q₀,
      • Files of size 11-20 pages go initially to queue q₁,
      • Files of size 21-30 pages go initially to queue q₂,
      • ...
      • Files of size i pages go initially to queue q_i/10 (for i < 10 (n-1)),
      • ...
      • All files of 10(n-1) or more pages go to queue q_n-1,
   3. n queues are used, and a print request for a file of size i is initially assigned to queue q_i%n.

   Problem to be Solved

   Supplemental Problem 3 is to investigate the extent to which multiple queues and different assignment algorithms have an impact on the average waiting time for users' print requests.

   For this problem, submit your code to the GitHub Classroom assignment for https://classroom.github.com/a/xNeusa_Y.

   For the purposes of this problem, suppose that printing one page requires one unit of time. The simulation described below will cover 1000 units of time, and the simulation will need a "clock" variable that keeps time units 0, 1, 2, ..., 999.

   1. Identify a Queue class for use with this problem. (If possible, use a queue class from the Java Library, although you may need to expand it to know how many times a dequeue operation has been called since the queue was last empty.)
   2. Define a PrintRequest class that contains relevant information regarding a user request for printing. Likely, this PrintRequest class will need fields to record the number of pages to be printed and the clock time when the user submitted a print request.
   3. Define a Printer class with [at least] these methods (beyond a constructor)
      • a boolean printerIdle() method that returns true if the printer currently is not processing a print request, and false if the printer is busy processing a Print Request (i.e., the printer is printing a requested file).
      • a boolean printFile (PrintRequest pr) method:
        • if the printer is idle, the printer will start processing the given print request, and the method returns true
        • if the printer is already processing another Print Request, the new Print Request pr is ignored, and the method returns false
      • a PrintRequest processForOneUnit() method that prints one page of the current print request
        • if the printer is idle, or if the current Print Request is NOT completed within 1 unit of time, then processForOneUnit returns null. (Internally, the printer object should record that one additional page of the current Print Request has been printed.)
        • if the current Print Request is completed in the current time unit, the method returns the current PrintRequest object that just finishes printing.
   4. Write a Simulation class for the following simulation:
      • The program will read four parameters from the terminal:
        • The probability that some user will make a print request in a single time interval
        • The number n of queues to be used
        • The number k of dequeue operations from one queue before an item from a lower-priority queue is promoted
        • The algorithm ("A", "B", or "C" from above) for determining how the operating system will decide which queue will be used for a user's print request.
      • Processing proceeds one time unit at a time, based upon a "clock" variable.
        Processing in one time unit involves the following:
        • If the printer is in use, then 1 page of the current job is printed (so the print job is 1 page closer to completion).
        • A user may or may not make a print request. For this simulation, the likelihood that a print request is generated in one time of time should be based on a random number generator and a user-entered probability. If a print request is generated, processing in the simulation should depend upon these parameters.
          • The number of pages for the print request should be determined randomly between 1 and 100 pages.
          • A new Print Request object is created, containing the number of pages for the job and the starting "clock" time that this request entered the queue.
          • The user's request is submitted to the operating system in the form of an object with the clock time and print size.
          • The operating system places the new Print Request object on the appropriate queue.
        • If the printer is idle, and if at least one print request is pending, then
          • a print request is selected from the multiple queues, as described above.
          • the wait time (number of time intervals of waiting) for this Print Request is used to update both a maximum wait time and a total average wait.
          • the print request is sent to the printer object.
      • After the "clock" reaches 1000 time units, no new Print Requests should be generated, but the simulation should continue until all existing Print Requests have been processed.
   5. At the end of the simulation, the program prints:
      • the maximum waiting time for any Print Request
      • the average waiting time for all processed Print Requests

   To investigate the impact of different queue-selection strategies, testing should include each of the queue-selection approaches and several loads (numbers of Print Requests entering over the simulation).

   Draft problem-specific grading form

   ---

   This document is available on the World Wide Web as

   http://www.walker.cs.grinnell.edu/courses/207.sp13/suppl-prob.shtml
   

   ---

   created 22 May 2008 last revised 23 April 2013
   For more information, please contact Henry M. Walker at walker@cs.grinnell.edu.