Posted on Saturday December 20, 2008 by Bellanov Apilli
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.
Saturday, December 27, 2008
iTutor: passing of parameters
Posted on Wednesday December 03, 2008 by Bellanov Apilli
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, ... )
iTutor - Next Steps - Sequence Generation
Posted on Sunday November 23, 2008 by Bellanov Apilli
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.iTutor, Toster, & Next Steps
Posted on Thursday November 13, 2008 by Bellanov Apilli
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
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
iTutor
Posted on Monday October 27, 2008 by Bellanov Apilli
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.
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.
Intelligent Tutor System
Posted on Wednesday September 10, 2008 by Bellanov Apilli
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.
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.
Discussion about Intelligent Tutoring System
Posted on Wednesday September 10, 2008 by THUMMALAPENTA, SURESH
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.
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.
Writing The Paper
Posted on Sunday August 17, 2008 by Bellanov Apilli
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.
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.
Bit Vector Input (cont'd)
Posted on Friday August 08, 2008 by Bellanov Apill
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.
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.
Bit Vector Input
Posted on Thursday August 07, 2008 by Bellanov Apilli
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.
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.
Next Step(s)
Posted on Monday August 04, 2008 by Bellanov Apill
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.
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.
FireEye Input Conversion
Posted on Sunday July 27, 2008 by Bellanov Apilli
I have now completed a program that extracts the attribute data from the policies, compiles them into lists, and writes the data to a text file that is compatible with FireEye. The program, thus far, works correctly for the simplest samples (codeA - codeD as well as pluto). JeeHyun has informed me that some of the policies contain complex names (such as those with numerous occurrences of the "true" attribute) and I am now trying to figure out a way to incorporate these attributes. I have some ideas and will discuss them with JeeHyun before attempting to implement them.
I have now completed a program that extracts the attribute data from the policies, compiles them into lists, and writes the data to a text file that is compatible with FireEye. The program, thus far, works correctly for the simplest samples (codeA - codeD as well as pluto). JeeHyun has informed me that some of the policies contain complex names (such as those with numerous occurrences of the "true" attribute) and I am now trying to figure out a way to incorporate these attributes. I have some ideas and will discuss them with JeeHyun before attempting to implement them.
Attributes & FireEye
Posted on Friday July 18, 2008 by Bellanov Apilli
I met with JeeHyun today to further discuss applying FireEye to the policies. He noted that he possessed a program that extracted data from the policies, compiling them into a tree structure. This tree structure is used by the classes in the project to for numerous tasks, including the creation of the requests. I believe utilizing this program would simplify the process of converting it into FireEye input. I am supposing isolating each type of attribute (subject, resource, action) into it's own respective file. After this isolation will come the compilation of each of these into appropriate FireEye input. As of now, I have been experimenting in FireEye, trying to get a feel of what the generic format of the input file will be. I've got a general idea and will implement it as soon as I receive the program from JeeHyun.
I met with JeeHyun today to further discuss applying FireEye to the policies. He noted that he possessed a program that extracted data from the policies, compiling them into a tree structure. This tree structure is used by the classes in the project to for numerous tasks, including the creation of the requests. I believe utilizing this program would simplify the process of converting it into FireEye input. I am supposing isolating each type of attribute (subject, resource, action) into it's own respective file. After this isolation will come the compilation of each of these into appropriate FireEye input. As of now, I have been experimenting in FireEye, trying to get a feel of what the generic format of the input file will be. I've got a general idea and will implement it as soon as I receive the program from JeeHyun.
NSF REU project on "Testing and Verification of Security Policies"
Posted on Sunday July 13, 2008
We recently recieved an NSF REU supplement grant for my existing NSF grant on Testing and Verification of Security Policies.
Bellanov Apilli, an undergraduate student from our NCSU CS department, has recently joined our project team to work on this REU project. Welcome!
(Sorry that my this annoucement of the project comes in later than Bellanov's first post on his progress below. Bellavnov, keep up the good work in keeping your progress posted here along the way!)
We recently recieved an NSF REU supplement grant for my existing NSF grant on Testing and Verification of Security Policies.
Bellanov Apilli, an undergraduate student from our NCSU CS department, has recently joined our project team to work on this REU project. Welcome!
(Sorry that my this annoucement of the project comes in later than Bellanov's first post on his progress below. Bellavnov, keep up the good work in keeping your progress posted here along the way!)
Subscribe to:
Posts (Atom)