I attached it in the attached file.
Data Structures 1 COLLEGE OF ENGINEERING AND APPLIED SCIENCES DEPARTMENT OF COMPUTER SCIENCE CSI213 Data Structures Project 04 Created by Qi Wang Click here for the project discussion recording. Table of Contents Part I: General project information ……………………………………………………………………………………… 02 Part II: Project grading rubric……………………………………………………………………………………………….. 03 Part III: Examples on how to complete a project from start to finish …………………………………… 04 Part IV: A. How to test a software design?.................................................................................06 B. Project description ……………………………………………………………………………………………….07 https://albany.zoom.us/rec/share/LlA2PrPtoVmfU3i0pgaN7NzSbAUPLWjP-XRJIhRsCdNgE2GHfSwBwA4WG9zcx9ke.H5Rncc3ZS_SbZ1oU?startTime=1594477852000 2 Part I: General Project Information • All projects are individual projects unless it is notified otherwise. • All projects must be submitted via Blackboard. No late projects or e-mail submissions or hard copies will be accepted. • Two submission attempts will be allowed on Blackboard. Only the last attempt will be graded. • Work will be rejected with no credit if The project is late. The project is not submitted properly (wrong files, not in required format, etc.). For example, o The submitted file can’t be opened. o The submitted work is empty or wrong work. o Other issues. The project is a copy or partial copy of others' work (such as work from another person or the Internet). • Students must turn in their original work. 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. • Documents to be submitted as a zipped file: o UML class diagram(s) – created with Violet UML or StarUML o Java source file(s) with Javadoc style inline comments o 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 style inline comments, and supporting files. Lack of any of the required items will result in a really low credit or no credit. • Your TA will grade, and then post the feedback and the grade on Blackboard if you have submitted it properly and on time. If you have any questions regarding the feedback or the grade, please reach out to the TA first. You may also contact the instructor for this matter. 3 Part II: Project grading rubric 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 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 comments must be included in Javadoc format before a class header. b. Method comments must be included in Javadoc format before a method header. c. More inline comments must be included in either single line format or block format inside each method body. d. All comments must be completed in correct format such as tags, indentation etc. Debug/Testing: • Are there bugs in the software? Documentation: • Complete all documentations that are required. 4 Part III: Examples on how to complete a project from start to finish 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. How to test/debug a software is included on the following pages. 5 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 */ 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; TAB TAB TAB open { open { 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. More inline comments can be included in single line or block comments format in a method. 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. 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 6 } //The specific object is a dog. Dog other = (Dog)obj; return this.name.equalsIgnoreCase(other.name); } } Part IV: A. How to test a software design? There can be many classes in a software design. 1. First, create a UML class diagram containing the designs of all classes and the class relationships (For example, is-a, dependency or aggregation). 2. Next, test each class separately. Convert each class in the diagram into a Java program. When implementing each class, a driver is needed to test each method included in the class design. In the driver program, i. Use the constructors to create instances of the class(If a class is abstract, the members of the class will be tested in its subclasses.). For example, the following creates Dog objects. Create a default Dog object. Dog firstDog = new Dog(); Create a Dog object with a specific name. Die secondDog = new Dog(“Sky”); ii. Use object references to invoke the instance methods. If an instance method is a value-returning method, call this method where the returned value can be used. For example, method getName can be called to return