Asserting java files

A I was working on the project today a thought occured to me.

As of right now I am parsing java files as text in order to create their respective skeletal class. However, I never tested to see rather the or not the file i'm parsing is a legitamite .java file.

What I plan on doing is attempt to compile the source files which are supplied as arguments. If files compile sucessfully, then the process will return the boolean true. Unsucesful compile means the .java file (it may not even be a java file technically) has errors of some sort. More details coming soon.

Posted at 03:46PM Feb 09, 2009 by Justin Gorham in Policy | Comments[0]

iTutor Approach & Other Ideas

I've compiled my thoughts on the approach and began writing the paper. This section includes my understanding of the tool's functionality as well as possible routes the project may take, if feasible. I have also included a file which contains what I perceive as an example test driver and emailed it along with the paper to Suresh & Kunal for their approval.

I have also picked up the Pragmatic Thinking & Learning text Dr. Xie put on the shelf last week. I shall begin reading this weekend, as I wait for a response.

Posted at 09:25PM Jan 09, 2009 by Bellanov Apilli in Policy | Comments[0]

Justin finally makes an entry

After a rough fall semester of hard classes, I am finally able to devote a lot more time to the iTutor project. I have to get a bit caught up, but it will take no time at all. I plan on meeting with Bellanov this weekend to discuss the iTutor project in detail.

Posted at 03:27PM Jan 09, 2009 by Justin Gorham in General | Comments[0]

iTutor: Method Sequences/Declarations

I met with Dr. Xie to discuss my progress on the project. We decided that I should begin writing the "examples" section on the paper as a means to confirm the correctness of my possible implementation. As such, I will create examples and what I expect their output to look like. As far as parameters that each method may require go, Dr. Xie suggested declaring methods after analyzing its contents. For now, I will write the paper and submit my writing to Kunal and Suresh for verification.

Posted at 01:15AM Dec 20, 2008 by Bellanov Apilli in Policy | Comments[0]

iTutor: passing of parameters

While continuing on the test driver and implementing each method's respective switch statement, the problem I've come across relates to the passing of parameters. Take the following case:

case 1:{
addItem(item);
break;
}

It simply invokes the addItem method, sending the parameter "item". As you've instructed, this parameter should go in the method declaration, which brought about another question.

In my mind, the proposed method declaration would be as follows:
addItem(int a, int item1, int item2, int item3, ... )

Where each "item" will map with its respective method call (the method that needs the said parameter). I am formulating to append to this "item" information into the data structure, assigning each item value soon after the class decompression. I just wish for confirmation so that everything I've been doing isn't in vain.

Posted at 05:03PM Dec 03, 2008 by Bellanov Apilli in Policy | Comments[1]

iTutor - Next Steps - Sequence Generation

Kunal has recently showed me how the method sequences will be generated using a switch statement. As I've come to find yet again, the passing of parameters makes things more complex. My question pertains to whether or not JCute can work with variables declared locally in each test driver method.

For instance, take into account that this is the testAddItem method.

void testAddItem(int a)

case 1: {
int item = 0;
stObj.add(item);
taObj.add(item);
break;
}

I initially have a parameter coming in (int a) but am unsure as to whether or not it is useful anymore. My question still lies in whether or not I can declare parameters I may need within each case block, as opposed to sending them all to the method declaration (where (int a) is).

Other than the above, I am beginning to see how this will come in altogether and will try to complete the test driver over the upcoming break.

Posted at 11:34PM Nov 23, 2008 by Bellanov Apilli in Policy | Comments[2]

iTutor, Toster, & Next Steps

I met with Suresh and Kunal today to discuss the contents of a poster I will be creating, as well as my progress regarding the tool. As far as the poster is concerned, we decided on following a similar format to one of Kunal's previous works. Although we technically do not have results (which we are unsure as to what a "result" is), we do have a solid methodology, which we will stress in the poster.

Regarding the iTutor tool, I have compiled all of the elements (from both TA & ST) solutions into a data structure and am focusing on writing them out to the test driver. I should also be able to generate a skeleton with my data structure and will do so after my current task. I went ahead and addressed the issue of having multiple parameters so the tool can keep track of that as well. The problem we encountered regarded testing void methods. The solution we came up with involved invoking the constructor in each solution, calling the void method, and then checking for any changes present within methods containing return values. Another problem we discussed pertained to non-primitive types, where we decided an "equals" method would be predefined in the TA solution.

I am now faced with:
1) Generating Test Cases
2) Using JPF to execute test cases
3) Using Kunal's poster as a basis for my current poster

Posted at 03:20PM Nov 13, 2008 by Bellanov Apilli in Policy | Comments[0]

iTutor

After finally finding some time, I have started implementing my ideas on the iTutor project. I am planning to isolate the method data, compiling all method-related data into a single ArrayList. I will then use the list to parse and generate the compilable test driver files. While writing my implementation, I came across a problem. The problem lies in the fact that I can only work with one file at any given time (either the TA or Student solution, not both). This problem led me to program based on certain assumptions.

Some are as follows:
1) I initially chose to use the TA solution to extract data from since the methods present here follow the interface correctly (as should the student solution)
2) Being able to work with (or decompress) only one file at a time leaves the "_TA" and "_ST" suffixes. I believe inserting code to remove the suffix (given that I am working with the TA solution) would enable me to generate the test driver code, using only the data from the TA solution. I would obviously reinsert them when it comes time to write the output file so that the code distinguishes between the two solutions.

I believe what I am formulating should work, since both implementations follow the same interface. I am questioning whether or not being limited to working with one file at a could lead to problems in the future.

P.S. I'm also have ideas regarding this problem, but it all storms from decompressing only the TA solution.

Posted at 03:59PM Oct 27, 2008 by Bellanov Apilli in Policy | Comments[0]

Policies on Undergraduate Research at NCSU ASE

(1). Each undergraduate student to be supported by our REU grants can be supported with their hours spent on research up to N hours per week during a normal semester, where N is predefined by the advisor in an invidiaul base based on the student's course load, past course performance, and current other responsibilities (such as TA hours, tutoring hours, and other social/service responsibilities). The advisor will communicate with the student individually on their N maximum research hours being supported by our REU grants.

***Only up to N hours actually spent by the student per week can be paid with our REU grants.***

(2). Each undergraduate student to be supported by our REU grants must document a research log on a weekly basis and submit such a log as a textual file (such as a Word, PDF, or plain text file) when requesting for payment for spent research hours. On an entry for each week, the student must document (1). the **actual** hours being spent on research (only up to the maximum N hours can be paid by our REU grants), and (2). a brief description of how the claimed actual hours are spent. The description is expected to be brief but not too brief. Here is one criterion for the student to determine how detailed the description should be: if the advisor cannot tell the semantic differences between two entries' descriptions, the student must refine the descriptions to make them distinct. For example, if a student writes two entries' descriptions as both "implementation of test generation", then these two descriptions are not satisfctory, and the student shall refine them as ones such as one being "implementation of parameter generation" and the other being "implementation of method-sequence generation".

***The REU grants cannot pay for the actual hours documented for a week whose description cannot be distinguished from another paid week's description.***

(3). Each undergraduate student to be supported by our REU grants must write at least one blog entry every **two** weeks with non-zero actual spent research hours (on our NCSU ASE REU blog http://blogs.lib.ncsu.edu/page/asereu). In a blog entry, the student can summarize these two weeks' activities, or write on any topics of the student's choice or interest. It is acceptable (but not recommended) for the student to write late blog entries long after the actual two weeks as "late assignment submissions" for these two weeks.

*** The REU grants cannot pay for the actual hours documented for those two weeks that don't have at least one corresponding blog entry.***

(4). Under very special circumstances, the advisor may approve a request from an undergraduate student who request to work more than N hours (being M hours) being paid by our REU grants for a certain week. Such a request should be sent to the advisor before the student actually spends the M hours. But to avoid the student's over-commiting on research and negatively impacting his or her normal course performance, the advisor generally tends not to approve a request unless really necessary.

(5). During winter breaks or summer breaks, each undergraduate student to be supported by our REU grants must discuss with the advisor ahead of time on the appropriate maximum N hours to be paid by our REU grants for certain weeks during the breaks. Again, the advisor will decide on N based on various factors similar to the ones for a normal semester.

(6). The advisor can have the authority to make special cases for a certain week for paying extra hours more than the predefined maximum N hours even when the student hasn't submitted a request for paid-hour extension for that week ahead of time. Such special cases can be granted only when the advisor is strongly convinced the necessity and importance of spending extra hours on research beyond N for the week. But to avoid the student's over-commiting on research and negatively impacting his or her normal course performance, the advisor generally tends not to make special cases.

** The student should document the actual hours spent on research on the weekly log even when the hours exceed the predefined N hours. But the advisor generally tends not to make special cases on paying extra hours.**

Posted at 10:59PM Oct 15, 2008 by XIE, TAO in General | Comments[0]

Intelligent Tutor System

My role is to synthesize a test driver that is capable of exposing behavioral differences between two versions of a class. This test driver will be executing similar method call sequences on both versions of the class in order to expose possible differences. A problem Justin and I encountered was that we cannot constraint test values within the test driver. We have to be as generic as possible and let the test driver choose the values that are to be tested. I also learned that combinatorial testing could be applied in the test driver because the problem of having a large number of parameters (method calls) still exists. Thus I hope I will be able to incorporate the FireEye tool within this project. Through FireEye, I can focus on unique test cases, eliminating those that are similar to one another. As of now, I believe incorporating combinatorial testing into the test driver could result in better and more efficient tests.

Posted at 07:47PM Sep 10, 2008 by Bellanov Apilli in Policy | Comments[0]

Discussion about Intelligent Tutoring System

Participants: Dr. Tao Xie, Yoonki Song, Kunal Taneja, Suresh Thummalapenta, Bellanov Apilli, Justin Gorham

Discussed about how to start the project and initial set of tasks:

Tools used:
1. ASM : For analyzing class files
2. Eclipse plugin for JPF

@Yoonki: Create a project "ITutor" based on UnitPlus and provide API called "ASMProxy" for accepting a class file as input and set of interface methods for getting the details of the class such as the name, parent class name, public methods, observer methods etc., The ASMProxy interface is based on ASM tool for analyzing byte code.
@Kunal: Provide a BinarySearchTree example to use as a running example through the project. Also explore the format of the driver required by JPF.
@Justin: Checkout the ITutor project and extend the project to use the ASMProxy class provided by Yoonki to generate a compilable interface that can be used by student to put the code.
@Bellanov: Checkout the ITutor project and extend the project to use the ASMProxy to generate a compilable test driver.

Posted at 07:07PM Sep 10, 2008 by THUMMALAPENTA, SURESH in Policy | Comments[0]

Writing The Paper

I had dinner with Professor Tao today and discussed the conclusion of the project, the paper. We went over how each section of the paper should be addressed, as well as the content and proper format, and plagiarism. After covering each section in detail, I have a better perspective of how research papers should be. I will be receiving slides containing a general outline of the paper-writing process. Until then, I will be summing up any ideas I come across.

Posted at 10:21PM Aug 17, 2008 by Bellanov Apilli in Policy | Comments[0]

Bit Vector Input (cont'd)

I have implemented the ideas JeeHyun and I discussed, deciding on "$" as the delimiting character in the output format. I kept the existing feature, which was insufficient, but have also implemented the bit vector method successfully, sending that data to a separate file. The files are denoted differently (original input as *.input & the vector as *.inputVector). I have sent the program(s) to JeeHyun and he will convert the data into the request format for testing.

Posted at 08:59PM Aug 08, 2008 by Bellanov Apilli in Policy | Comments[0]

Bit Vector Input

I met with JeeHyun today to address the format the bit vectors will be in, deciding on a format he could easily convert from.We decided no a format comprising of both the attribute and its type. We also discussed the so-called complex file types (true & false) and decided to implement them as individual attributes. I implemented the idea into the FireEye conversion class I wrote. The format I chose is as follows: attribute : type. I kept the spaces between to make it more readable for JeeHyun when it comes time for him to convert it. This process is complete for code A - D, conference, and pluto. The remaining two (continue a & b) will soon be finished, once I correctly ignore the irrelevant lines.

Posted at 10:13PM Aug 07, 2008 by Bellanov Apilli in Policy | Comments[0]

Next Step(s)

I met with professor Tao today to discuss the necessary steps to take in order to achieve our goal, the coverage testing. As of now, my implementation is able to handle all combinations, given that one value is taken for subject, research, and action each time. Although this method may cover a significant number of requests, it will not be sufficient. It fails in covering cases where more than one of each type (subject, resource, value) were taken. The solution we came up with was similar to what we discussed the very first day, a bit vector whose length is as long as the number of attribute values. I will implement this idea as soon as I am fully complete with the current task, which is converting the FireEye output back into request format. Converting these values will enable us to test coverage, although it may be only for primitive case (one subject, resource, and action at a time). Once I am finished with implementing the conversion on the primitave cases, I will do the same for the complex (more than one subject/resource/action taken at once). In order to successfully convert the files into requests, I need to find some way to map the attributes to their other components, such as their type, id, etc, so I can keep track of their relationships.

Posted at 05:18PM Aug 04, 2008 by Bellanov Apilli in Policy | Comments[0]