iTutor Formal Writing

In the following 2 weeks, my first priority will be to compile the writing behind the current tool development, with the goal being to encompass all efforts up until this point.

I shall implement this by executing the following steps:
1) Finding publications in a similar area to either cite (i.e., statistics) or compare approaches
2) Write abstract and introduction sections
3) Write related work section
4) Write implementation section

Teaching OOP part 2

The past two weeks has only been involving teaching Khiry OOP. We went over methods, the parts of declaring a method, what are parameters, return values and how objects use methods. We started with simple methods and went into more complicated methods to make sure he understands if he sees alot of code that he can understand what is going on. He established a great understanding of how to create different objects of different types and how to use methods within those objects. We will go over this again when we meet again this week.

Teaching OOP

So the past two weeks I submitted my research paper and taught our new freshman student Khiry Arnold some Object Oriented Programming. We went over the definition of what is an object and what is a class and the differences between them. We did a little exercise to also understand how they work together. I gave a little quiz to see if he can try to figure out how to solve a problem with the tools given. He seems that he has the capability to learn OOP, he just needs time so I am working with him slowly and making sure that each time we meet we go over what we discussed the last time.

iTutor Improvements (continued)

After the last 2 weeks, the remaining iTutor goals are as follows:

1. iTutor needs to check whether it can find equivalent public methods in the student solution, if not, it can flag error.
2. When the methods under test accept non-primitive types, a deep copy of the argument should be made. If not, the method under test of teacher solution may modify the argument before passing it to student solution. Similar techniques need to developed for comparing non-primitive return types.
3. A problem arises where methods can be overloaded, leading to multiple possibilities when instantiating each solution. iTutor shall generate numerous test drivers, each of which focuses on one constructor.
   
4. The logging feature now sends the data to files. The data could be formatted in a fashion where it is easier to comprehend.
   

For the next two weeks, I shall address the above points, as well as improving on other features as required by the addition of the above.

Microsoft Help with Pex

So the past two weeks have been very productive on how Pex works. So I met with Nikolai from Microsoft Pex group and he helped me with my problem that I was having with my complex object. He also told me that I would run into alot of problems because I use a lot of float point arithmetic within my program and Pex has problems with floats. Unfortunately, video games do generally use floating points for movement of objects and placement of objects so this is something that I cannot avoid.

I worked on trying to make Pex and Scurvy.Test work together a little bit more but with no sucess. I also had a meeting with Xusheng of our research group and he gave me alot of help on my game and that same MapEngine method. He had given me a way to try to make Pex understand the code better and search better paths by constraining the variables used in the factory methods.

Beginning my first paper

The past two weeks I've gathered my current information in order to find a topic for me to discuss for the SIGSCE student research project. I met with Justin Gorham for some help with Pex on how to use it with my game since he worked with Pex over the summer with the government. I also had help from Bellanov Apilli to learn how to use LaTeX. I had alot of problems just setting it up but got it working later on.

My topic of the paper was on how to deal with complex objects within a game using Pex. I have an example of this which I discussed in an earlier post (the MapEngine) that I will use as my example in the paper.

Continuation of Studies in OOP

My most recent research has been conducted with Charles regarding Object Oriented Programming. Primarily, I've been solidifying my knowledge in Object Oriented Programming, particularly in C# by consistently differentiating between the various aspects which compose a simple program.

Our most recent meetings had me perform several assignments of deciphering coding created by Charles, and explain the capabilities of each class. Inversely, I was given the instructions to create the coding for some assignments based on classes that Charles had defined.

The most prominent (and longest) example involved me creating the portion of a video game which assigned the values of location and velocity to two player characters.

I believe I had taken pictures of this example, but I am having difficulty locating it. When I find it I will upload it into this post, as it was particularly lengthy and will be trouble replicating. I will also ensure that my following posts will contain visual references to better visualize my experiences.


Take Care.

iTutor Improvements

The feedback compiled from the iTutor demo is as follows:

1. iTutor accepts three classes as inputs: Teacher solution, Student solution, and an interface common to them. The users of iTutor can be relieved by removing the interface as input. This interface can automatically be inferred from the public methods of Teacher solution. Also, before processing these solutions, iTutor needs to check whether it can find equivalent public methods in the student solution, if not, it can flag error.
2. iTutor currently renames the solutions to Student and Teacher. This can be easy if there is a single class. But situation can be difficult if there are many classes. Bellanov needs to investigate and develop features to address this issue.
3. Currently, the length of method-call sequences in tests has been limited to three. This can be made configurable.
4. Add "assertions" to all case statements, this would help in automatically generating test cases with variable number of sequences (as assertions exist right after the method-call invocations)
5. Make the index used in the switch statement as symbolic and remove it as a parameter for the driver method
6. Remove arguments passed to method calls as parameters from the driver method.
7. When the methods under test accept non-primitive types, a deep copy of the argument should be made. If not, the method under test of teacher solution may modify the argument before passing it to student solution. Similar techniques need to developed for comparing non-primitive return types.
8. A problem arises where methods can be overloaded, leading to multiple possibilities when instantiating each solution. iTutor shall generate numerous test drivers, each of which focuses on one constructor.
   
9. The logging feature that currently uses print line statements shall be implemented to send that information to a file, which can be accessed and analyzed later.
   

For the next week, I shall address as much of the following as possible. I predict that I will be able to cover and address points 1, 3, and 5. First and foremost, I am developing a test suite to properly test all of iTutor's present functionality to ensure correct behaviors. After I am convinced that the tool is in proper shape, I shall move on to address the points above.