讲解CSI213留学生、辅导Java程序设计、讲解Data Structures、辅导Java语言
- 首页 >> Java编程COLLEGE OF ENGINEERING AND APPLIED SCIENCES
DEPARTMENT OF COMPUTER SCIENCE
Fall 2018 – CSI213 Data Structures
Project 1
Instructions:
1. All projects are individual projects unless it is notified otherwise.
If one of the following is true, no credits will be given:
The project is late.
The class design is missing.
Wrong files are submitted or part of the source codes is submitted.
The project has errors.
The comments are not completely written in Javadoc format.
The project is a copy and modification of another student’s project. (Both will
receive 0.)
The project is copied from internet or other resource.
2. All projects must be submitted via email on time. No late projects will be accepted.
Documents:
UML class diagram(s)
Java source file(s)
Supporting files if any (For example, files containing all testing data)
Emails:
ZR170102: Email Ms. Lin and me
lilin1@cqupt.edu.cn
qwang3@albany.edu
ZR170304: Email Mr. Jiangping and me
huangjp@cqupt.edu.cn
qwang3@albany.edu
Due:
ZR170102: 10/24/2018
ZR170304: 10/24/2018
2
Software Development General Project Rubric:
Analysis:
Does the software meet the exact specification?
Does each class include all corresponding data and functionalities?
Design:
Is the design (in UML class diagram(s)) efficient?
Code:
Are there errors in the software?
Are code conventions and name conventions followed?
Does the software use the minimum computer resource (computer memory and processing time)?
Is the software reusable?
Debug:
Are there bugs in the software?
Documentation: There will be no credit if comments are not included.
Class comments must be written in Javadoc format before a class header.
Method comments must be written in Javadoc format before a method header.
Javadoc comments must be written before each instance/static variable.
More inline comments must be included in either single line format or block format inside each method
body.
All comments must be complete in correct format.
The following contains additional information on coding conventions and Javadoc. The project
description starts on page 5.
A Java source file can contain a class. Each class is made up of the following components:
Inside a class,
package statement
import statements if any
Javadoc class comments
a class header and its body. The open {of a class body must be at the end of the header.
Inside a class body,
instance/static variables with Javadoc comments above each variable
instance/static methods with Javadoc comments above each method header. The open { of a method
body must be at the end of the header
Inside a method body,
more comments are included in each method body. These comments can be written in single line or
block format.
Readability:
To enforce program readability, consistent indentations must be used to show containment hierarchy.
Readability is very important. Poor readability of a source file will be ignored or misinterpreted. This will
definitely affect a software developer’s performance. Please read the following, and careful exam your source
file.
1. Align Javadoc comments with its source codes.
2. Use consistent indentations to enhance readability:
3
Indent each instance/static variable of a class.
Indent each method of a class.
Indent each statements in a block statement or a method.
3. Use required spaces, not excess spaces to enhance readability:
No spaces between comments and the corresponding method header.
One space after * at the beginning of each line in Javadoc comments.
Align first * of each line in Javadoc comments.
One line in between two sections of codes is needed.
Comments are required almost everywhere in a source file. Double check to make sure they are completed in
the required formats. Code conventions must be followed.
package dog;
import java.util.Random;
/**
* Representing a dog with a name.
* @author Qi Wang
* @version 1.0
*/
public class Dog{
/**
* The name of this dog
*/
private String name;
/**
* Constructs a newly created Dog object that represents a dog with an empty name.
*/
public Dog(){
this("");
}
/**
* Constructs a newly created Dog object with a name.
* @param name The name of this dog
*/
public Dog(String name){
this.name = name;
}
/**
* 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
* this dog and the name of this dog.
* @return A string representation of this dog
*/
TAB
TAB
TAB
package statement is required.
open {
open {
import statements if any
TAB
Class comments must be written in Javadoc format before
the class header. A description of the class, author
information and version information are required.
required In method comments, the first word must be a capitalized
verb in the third person. Use punctuation marks properly.
Method comments must be written in Javadoc
format before the method header. A description of
the method, comments on parameters if any, and
comments on the return type if any are required.
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
4
public String toString(){
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
*/
public boolean equals(Object obj){
//The specific object isn’t a dog.
if(!(obj instanceof Dog)){
return false;
}
//The specific object is a dog.
Dog other = (Dog)obj;
return this.name.equalsIgnoreCase(other.name);
}
}
More inline comments can be included in
single line or block comments format in a
method.
5
Project 1 Abstract Data Type(ADT) Bag
What to submit?
All source files
UML class diagram(s)
Supporting files if any (For example, files containing all testing data)
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.)
Specify operations to
create an empty bag,
put an item in the bag (insert(item)),
remove the last item put in the bag ( removeLast()),
remove a random item from the bag (removeRandom()),
get an item from the bag( get(item)),
get an item at index from the bag( 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:
6
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 should be written during this activity.
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.
ADT Bag Documentation:
Check the entire project, and complete /revise Javadoc comments if needed. 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.