ICSI213-IECE213-Project 03 Solved

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.  

 

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. By convention. 

•      Constructors and constants should not be included in a class diagram. 

•      For each field (instance variable), include visibility, name, and type in the design. 

•      For each method, include visibility, name, parameter type(s) and return type in the design. 

o DON’T include parameter names, only parameter types are needed. 

•      Show class relationships such as dependency, inheritance, aggregation, etc. in the design. Don’t include the driver program and its helper class since they are for testing purpose only. 

 



The corresponding source codes with inline Javadoc comments are included on next page.  

             


import java.util.Random; 

 

/** 

Class comments must be written in Javadoc format before the class header. A description of the class, author information and version information are required.  
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. 
*  Representing a dog with a name.  

*  @author Qi Wang  

*  @version 1.0  */ public class Dog{  

        /** 

 TAB 

        */ 

 TAB 

        

        

/** 

*   Constructs a newly created Dog object that represents a dog with an empty name. 

        */ 

       public Dog(){ 

 TAB thisTAB (""); 

       }/**                                           A description of the method, comments on
 

*  Constructs a newly created Dog object with a name. parameters if any, and comments on the return type         * @param name The name of this dog     if any are required.  

   */ A Javadoc comment for a formal parameter consists of  public Dog(String name){ three parts:    this.name = name; - parameter tag,  

       } 

       - a name of the formal parameter in the design ,   /**   (The name must be consistent in the comments and the   * Returns the name of this dog. header.) 

*  @return The name of this dog   - and a phrase explaining what this parameter specifies. 

  */ A Javadoc comment for return type consists of two parts:   public String getName(){ - return tag,  

              return this.name;                        - and a phrase explaining what this returned value specifies 

       }                                              

       /** 

*  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 

More inline comments can be included in single line or block comments format in a method.  
*  @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); 

       }       

} 

Part IV: Project description  

2*((3+4)+5)

2*(3+(4+5))

2*((3+5)+4)

2*(3+(5+4))

2*((4+3)+5)

22 * ((3+4)+5)

22 * ((3 + 4) + 5)

22 * ( (3 + 4) + 10)

 

 To represent an arithmetic expression, Expression class needs to be designed. Each expression object contains an infix, a string. For example, the infix expression 2*((3+4)+5) can be represented as an Expression object like this

 

Expression myExpression = new Expression(“2*((3+4)+5)”); 

 

 

                                        myExpression 

  “2*((3+4)+5)” 

 

 

 

Specifications:  

Here are what should be included in Expression class:  

•       An instance variable for the infix

•       A default constructor

•       A second constructor that takes a specific infix string

•       Getter/setter for the infix

•       An instance method that converts this infix to postfix and returns the postfix as a list of tokens o Use the infix to postfix algorithm we discussed in class. Use the ADT stack that you have completed from the previous lab.  

o When splitting an infix into tokens, you should not use charAt method and expect all operands are single-digit tokens. Instead you should split an infix by choosing proper delimiters. One way is to use operators, spaces and parentheses as delimiters and use them as tokens. Please check StringTokenizer class for proper methods that can be used.

•       An instance method that evaluates this infix and returns the result. In this method, o First, you should convert this infix to postfix by calling the previous method.

o And then, evaluate the postfix and return the result. Use the postfix evaluation algorithm discussed in class. Use the ADT stack that you have completed from the previous lab.  

•       Overridden equals and toString

 

Design:  

Include your Expression design and ADT stack design completed for the lab in the same diagram.  

 


 

     Code/Test/Debug: 

After implementing the Expression class, create an input file and add more expressions to the end of the list.  

2*((3+4)+5)

2*(3+(4+5))

2*((3+5)+4)

2*(3+(5+4))

2*((4+3)+5)

22 * ((3+4)+5)

22 * ((3 + 4) + 5)

22 * ( (3 + 4) + 10)

 

Write a simple driver to test your classes.

      public static void main(String[] args) throws FileNotFoundException{ 

            

            //Create a scanner object to read the input file.      

             

//as long as there are more infix expressions,  

                                //    -read one infix at a time, make an expression object.  

//    -use the object reference to call the infix to postfix method and    //      evaluate method. And print the results.