Shame on me!

I disappeared for a month but now I am back with some of topic stuff.
I will continue to work on MockitoViz as soon as I can, but now I want to write about some other pet project of mine.

Pflection is a view for FDT that shows some Software development metrics for selected project, package or what ever you selected in your project/outline view.
At the moment I implemented Pflection I was not aware of Sonar, but in my opinion the two projects has also different field of use. Sonar is a CI tool, Pflection other wise is development tool. The feedback cycle of Pflection is much shorter.

So what does Pflection can?

It watches you selecting elements(multi selections enabled) in Project or Outline View and shows aggregated data about selected items. For example if you are selecting a project it will aggregate the data about all the containing elements (libraries, source folders, packages etc..)

What data (metrics) we are talking about?

Metrics can be divided in following groups:
Source Containers:
- Number of Libraries (SWC)
- … source folders
- … packages
Compilation Units (Master Elements – representing the file):
- … classes
- … interfaces
- … functions
- … variables
- … constants
- … namespaces
Nested (hidden/local) Elements:
- … classes
- … interfaces
- … functions
- … variables
- … constants
- … namespaces
Type members:
- … methods
- … static methods
- … setter
- … getter
- … field
- … constantField
- … namespace
- … metatag
Object Oriented:
- Interface implementation rate
- class inheritance depth
Dependency based:
- Number of incoming references
- Number of outgoing references
Behavior (Function) based:
- Method lines of code
- Number of conditions
- Number of blocks
- Number of flow terminations

Now I would like to talk about the last three metrics and how they can be computed.
Lets start with the simple one – number of blocks.
blocks are code statements wrapped in ‘{}’.
So by providing the number of blocks in a function we can make assumptions about horizontal and vertical distance inside the function.
FDT has also a Parser that creates AST from source code.
Block is an AST element so we just have to walk throw a function AST and count the appearance of Block Nodes.

I wrote some Scenarios to test the visitor:

Scenario: Check an empty function
Given a function:
function foo(){
}
When applying Function Analyser
Then number of blocks is '1'

It’s pretty simple to test the visitor because there is no need of binding the function. But any way if your Visitor needs a binding based computations it’s better to delegate it to another Class and mock it out for the test. This way you also end up with a better responsibility distribution.

Here is another Scenario for block computations but than let’s move on

Scenario: Check function with nested if/else condition for blocks
Given a function:
function foo():void{
	if(true){
		if(false){
		}
	}else {
	}
}
When applying Function Analyser
Then number of blocks is '4'

Next metric I would like to mention is number of conditions.
This metric show how many ways your code can be executed and how many tests (at least) you should write to have a 100% code coverage.
I implemented all three metric computations in the same visitor for a better performance and because they all have the same responsibility – count appearance of some particular AST element.
The AST elements I am interested in for condition counting are:
all sort of loops, if and case statements.
I also included a try block because the code inside a try block can have different execution flows.
Oh and last but not least condition expression.
Here is a scenario

Scenario: Check a function with nested condition expression 
Given a function:
function foo():void{
	true ? true : false ? trace("a") : trace("b")
}
When applying Function Analyser
Then number of conditions is '2'

Number of flow terminations – this metric provides you with info how many exit points your function has. The more exit points your program has, the more aspects you have to keep in mind when you are reading it.
A simple void function has only one exit point.

Scenario: Check an empty function with void type
Given a function:
function foo():void{
}
When applying Function Analyser
Then number of flow terminations is '1'

A typed function has a termination when it has a return statement

Scenario: Check a simple typed function
Given a function:
function foo():int{
	return 0;
}
When applying Function Analyser
Then number of flow terminations is '1'

A termination point can also be a continue and break statement. Those are no end points for a complete behavior, but they merge two execution flows together.
A global behavior end point is also a throw statement.

Scenario: Check a void function with throw exeption
Given a function:
function foo():void{
	if(false){
		throw new Error("foo");
	}
}
When applying Function Analyser
Then number of flow terminations is '2'

All the scenarios can be browsed in FDT-OS project on google code website
http://code.google.com/p/fdt-os/source/browse/#svn/trunk/FDTPflectionTest/src/de/bomzhi/mz/pflection/model/scenario

So if you think there are some additional scenarios/features I haven’t thought of, please try it out and post it in comments.

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you submit form:
Human test by Not Captcha

© 2011 Max Blog Suffusion theme by Sayontan Sinha