程序代写代做 go data structure Java algorithm COLLEGE OF ENGINEERING AND APPLIED SCIENCES DEPARTMENT OF COMPUTER SCIENCE ICSI213 Data Structures

COLLEGE OF ENGINEERING AND APPLIED SCIENCES DEPARTMENT OF COMPUTER SCIENCE ICSI213 Data Structures
Project 01 Created by Qi Wang
Table of Contents
Part I: General project information ……………………………………………………………………………………… 02 Part II: Project grading rubric……………………………………………………………………………………………….. 02 Part III: Examples on how to meet project requirements……………………………………………………… 03 Part IV: Project description ………………………………………………………………………………………………….. 06

Part I: General Project Information
All projects are individual projects unless it is notified otherwise. A project will receive no credit if one the following is true.
Students must turn in their original work. Any copied work from others and/or Internet will not be credited. Any cheating violation will be reported to the college. Students can help others by sharing ideas, but not by allowing others to copy their work.
All projects must be submitted in Blackboard. No late projects will be accepted. Documents to be submitted as a zipped file:
• UML class diagram(s) – created with Violet UML, ArgoUML, or StarUML
• Java source file(s) with Javadoc inline comments – (Java classes created with eclipse.)
• Supporting files if any (For example, files containing all testing data.)
Students are required to submit a design, all error-free source files with Javadoc inline comments, and supporting files. Lack of any of the required items will result in a really low credit or no credit.
Part II: Project grading rubric
All projects will be evaluated based upon the following software development activities.
Analysis:
• Does the software meet the exact specification / customer requirements?
• Does the software solve the exact problem? Design:
• Is the design efficient? Code:
• Are there errors?
• Are code conventions followed?
• Does the software use the minimum computer resource (computer memory and processing
time)?
• Is the software reusable?
• Are comments completely written in Javadoc format?
a. Class Javadoc comments must be included before a class header.
b. Method Javadoc comments must be included before a method header.
c. More inline comments (in either single line format or block format) must be included
inside each method body.
d. All comments must be completed in correct format such as tags, indentation etc.
• The project is late.
• The project is a copy and modification of another student’s project. (Both will receive 0.)
• The project is copied from the Internet or other resources.
Components
Max points
UML Design (See an example in part II.)
Max. 10 points
Javadoc Inline comments (See an example in part II.)
Max. 10 points
The rest of the project
Max. 40 points
2

Debug/Testing:
• Are there bugs in the software? Documentation:
• Complete all documentations that are required.
Part III: Examples on how to meet project requirements
To complete a project, the following steps of a software development cycle should be followed. These steps are not pure linear but overlapped.
Analysis-design-code-test/debug-documentation.
1) Read project description to understand all specifications(Analysis).
2) Create a design (an algorithm for method or a UML class diagram for a class) (Design) 3) Create Java programs that are translations of the design. (Code/Implementation)
4) Test and debug, and (test/debug)
5) Complete all required documentation. (Documentation)
The following shows a sample design.
The corresponding source codes with inline Javadoc comments are included on next page.
3

import java.util.Random;
/**
* Representing a dog with a name.
* @author Qi Wang
* @version 1.0
*/
Class comments must be written in Javadoc format before the class header. A description of the class, author information and version information are required.
public class Dog{
open {
/**
* The name of this dog
*/
/**
* Constructs a newly created Dog object that represents a dog with an empty name.
A description of the method, comments on
TAB TAB
public Dog(){
private String name;
*/
open {
TAB
this(“”);
Comments for fields are required.
Method comments must be written in Javadoc format before the method header. the first word must be a capitalized verb in the third person. Use punctuation marks properly.
TAB
}/**
* Constructs a newly created Dog object withifaanyamaer.e required.
* @param name The name of this dog
*/
public Dog(String name){ } this.name = name;
A Javadoc comment for a formal parameter consists of three parts:
– parameter tag,
– a name of the formal parameter in the design ,
(The name must be consistent in the comments and the header.)
– and a phrase explaining what this parameter specifies.
A Javadoc comment for return type consists of two parts: – return tag,
– and a phrase explaining what this returned value specifies
* this dog and the name of this dog.
* @return A string representation of this dog
*/
return this.getClass().getSimpleName() + “: ” + this.name; }
/**
* Indicates if this dog is “equal to” some other object. If the other object is a dog,
* this dog is equal to the other dog if they have the same names. If the other object is
* not a dog, this dog is not equal to the other object.
* @param obj A reference to some other object
* @return A boolean value specifying if this dog is equal to some other object
*/
More inline comments can be included in single line or block comments format in a method.
public String toString(){
public boolean equals(Object obj){
//The specific object isn’t a dog. if(!(obj instanceof Dog)){
parameters if any, and comments on the return type
/**
* Returns the name of this dog.
* @return The name of this dog
*/
public String getName(){ } return this.name;
/**
* Changes the name of this dog.
* @param name The name of this dog
*/
public void setName(String name){
this.name = name; }
/**
* Returns a string representation of this dog. The returned string contains the type of
return false;
4

}
//The specific object is a dog.
return this.name.equalsIgnoreCase(other.name); }
}
Dog other = (Dog)obj;
5

Part IV: Project description
Project 1 Abstract Data Type(ADT) Bag
The ADT Bag is a group of items, much like what you might have with a bag of groceries. In a software development cycle, specification, design, implementation, test/debug, and documentation are typical activities. The details are provided in the rest of the document.
ADT Bag Specification: (Note: You should not change the names of the operations in your program. This should be included in an interface.)
Specify operations to
• create an empty bag that can hold up to 50 items,
• put an item at the end of the list of the bag (insert(item)),
• remove the last item in the bag ( removeLast()),
• remove a random item from the bag (removeRandom(), (Note: a random item is an item at a random index.)
• get the index of the first occurrence of an item from the bag if it is existed (get(item)),
• get a reference to an item at position index( get(index)),
• check how many items are in the bag (size()),
• check to see if the bag is full (isFull()),
• check to see if the bag is empty( isEmpty()),
• and completely empty the bag (makeEmpty()).
ADT Bag Design:
Complete a UML diagram to include all classes that are needed to meet the specifications. An interface class is usually defined to include all operations. A class implementing this interface provides implementation details.
Exceptions should to be considered when operations are designed.
Java has two types of exceptions: checked exceptions and runtime exceptions.
Checked exceptions are instances of classes that are sub classes of java.lang.Exception class. They must be handled
locally or explicitly thrown from the method. They are typically used when the method encounters a serious problem. In some cases, the error may be considered serious enough that the program should be terminated.
Runtime exceptions occur when the error is not considered as serious. These types of exceptions can often be prevented by fail-safe programming. For example, it is fairly easy to avoid allowing an array index to go out of range, a situation that causes the runtime exception ArrayIndexOutOfBoundsException to be thrown. Runtime exceptions are instances of classes that are subclasses of the java.lang.RuntimeException class. RuntimeException is a subclass of java.lang.Exception that relaxes the requirement forcing the exception to be either handled or explicitly thrown by the method.
In general, some operations of an ADT list can be provided with an index value. If the index value is out of range, an exception should be thrown. Therefore, a subclass of IndexOutOfBoundException needs to be defined.
Also, an exception is needed when the list storing the items becomes full. A subclass of java.lang.RuntimeException should be defined for this erroneous situation. A full ADT bag should throw an exception when a new item is inserted.
ADT Bag Implementation:
Data structure array must be used to store all items in an ADT Bag list. The element type of the array should be Object type. Implement all classes included in the design. Javadoc comments need be written during this activity.
6

Class comments must be included right above the corresponding class header. Method comments must be included right above the corresponding a method header. All comments must be written in Javadoc format. There will be no credits if comments are not complete, and/or not written in Javadoc format.
ADT Bag Test/Debug:
Note: It is required to store all testing data in a file. No credit will be given if not.
It is required to use decomposition design technique. No credit will be given if not.
To test ADT bag design, all operations in the design must be tested. In general, an empty ADT Bag is created, and then, fill the bag list with items read from a text file, invoke any operations via the list, and always display the list after it is changed. It is not efficient to let main to do all. Method main should be very small and should be the only method in the class. It should invoke a method (for example, start) that is decomposed into more methods (for example, fillList, displayList) in a separate class. Every method should be designed as a single-minded method. For example, Class ADTBagTest contains method main; class ADTBagUtility is a helper class. Both classes are used for testing purposes.
public class ADTBagTest{
public static void main(String[] args){
ADTBagUtility.start(); }
}
public class ADTBagUtility {
/**
* Creates a bag of items, and change items in the bag, and displays items. */
public static void start(){
ADTBagArrayBased list = new ADTBagArrayBased();
//Fill the bag.
//A Scanner object must be used to read item information from a file. //Items need to be created before they are put into the bag. fillList(list);
//Display items in the bag. displayList(list);
}
/**
* Stores items into a bag.
* @param list A reference to a bag
*/
public static void fillList(ADTBagArrayBased list){ Scanner input = …
//add items into the bag and/or remove items from the bag. //All operations in ADT Bag design must be used/tested here.
}
/**
* Displays items in the bag.
* @param list A reference to a bag
*/
public…static void displayList(ADTBagArrayBased list){
7

}
}Note:
An Item type can be designed to represent an item in the bag. A String object can be used to represent the item type in the bag.
8