Back to Square One...

Today, I met with Yoonki in order to deploy and configure iTutor. The most recent version of the API we were able to recover, unfortunately, is the initial version. My next move is to discuss the limitations of the JPF tool with Suresh and Kunal. I recall problems in the previous implementation of the project, where I had the tool generating code that JPF would be unable to execute (i.e., switch statements). I will strive to quickly and efficiently have a working demo of the iTutor tool very soon, before my workload increases greatly. On a side note, I will also work on the tool's website, where instructions about using the tool will be available.

New Semester

I've updated the RAdAC project website. It now has everything that I've done so far. Last week I prepared my abstract for publication. Apparently I used the wrong template and I had a few grammatical errors to correct, but that is finished now and is submitted. I'm excited about starting a new semester. Between classes and research I will be busy! We had our first group meeting of the semester Friday. It was nice to meet everyone (some were new to me) in the group.

Fall 2009 Begins!!!

Today, the undergraduate and graduate students met with Dr. Xie for our regular group meeting. We were debriefed as to our summer activities and planned the projects that we will pursue in the future. It was decided that I and Kamar pursue the iTutor (name's probably going to change) project under Kunal's guidance. I briefly recall problems we ran into pertaining to JPF and hope that we shall resolve them this time around.

My initial task is to come up with somewhat of a prototype to display to anyone interested in the tool's functionality. Although it may not be a perfect exhibition of the final product, having something prospective to show is good enough for now.

Low code coverage doesn't always mean low test confidence

Code coverage is not always the best indicator of a test suite's usefulness, expressiveness, etc.

Contrary to the popular belief, there are cases in which high test coverage is not a good measure of test quality. In fact, high test coverage is not always possible.

Consider the following situation:

public class Container {
object a_1;
object b_1;
object c_1;
⁞
⁞
object z_1;

public object A_1{
get
{
return a_1;
}
set
{
a_1 = value;
}
}
⁞
⁞
⁞
⁞

}

public class A {
Container container;

public A (Container c)
{
container = c;
}

/*all methods of class A interact with container.A_1 ONLY*/

}

The other lettered classes follow the same format.
When Pex tests the Container class it will more than likely get 100% test coverage.
When Pex tests the lettered classes, however, it will not get 100% code coverage. The test coverage report includes coverage of the Container class, which does not require 100% coverage to test the lettered classes. The classes could arguably be written so that they are more easily testable; however, I did not write this code. I actually observed code similar to this in a real application. The lettered classes get 100% block coverage themselves but overall block coverage is never 100%.

Policy Rework and XACML Inefficiencies

I've had to rework the policy format I made earlier this week, mainly because it would have required an excessive amount of Java methods to make it work. I've decided to stay away from adding to the XACML specification wherever possible (with a few exceptions), because it cannot support all the possible rules that could occur in an RAdAC policy. Instead, only individual risk/need factors are calculated by Java methods; how they are combined is determined by the XACML policy. I did run into one problem with this approach, which was that the policy needs to use the risk and need measurements multiple times throughout the policy to make a decision. It is very inefficient to copy-and-paste the part of the policy that calculates risk and need each time they are used. I found a solution in the XACML 2.0 specification, the <VariableDefinition> and <VariableReference> tags. They store the result of a calculation for use throughout the policy. The only snag with using this, if we decide to go this route, is we will have to use the CVS version of Sun's XACML implementation to get the 2.0 features, which, according to their website, is stable.