Strategies to relate the program and problem domains using code

instrumentationMario Marcelo Berón

University of Minho

Pedro Rangel HenriquesUniversity of Minho

Maria João Varanda PereiraPolytechnic Institute of Bragança

Roberto UzalUniversity of San Luis

MICEI

Braga – Portugal

MICEI-University of Minho

MotivationIn the context of PCVIA, we want to explore and

implement code inspection approaches and tools for Program Comprehension activities.

We will give special attention to approaches that support the mapping between behavioral and operational views of programs.

We will present a code instrumentation based strategy.

MICEI-University of Minho

• Program Comprehension: concepts and tools• Program Comprehension Approach• Strategy to relate different views• Case Study: EAR (Un Evaluador de Algoritmos

de Ruteo)• Conclusion• Future Work

MICEI-University of Minho

Program Comprehension

Software Engineering discipline which aims at understanding computer code written in a high-level programming language.

Program Comprehension is useful for reuse, maintenance, reverse engineering and many other activities in the context of Software Engineering.

MICEI-University of Minho

Program Comprehension Tool

A program that aims at making the understanding of a software application easier, through the presentation of different perspectives (views) of the overall system or its components.

MICEI-University of Minho

A PC Tool has modules to:

•Extract information by parsing the source code

•Store and handle the information extracted

•Visualize all the retrieved information

MICEI-University of Minho

MICEI-University of Minho

MICEI-University of Minho

Views: System representations that help the user to understand the systems under analysis

Interesting Views

•Machine (ex. Byte Code, Assembly Code)

•Program (ex. C code, Java code)

•Functions and data used in runtime

•Function Graph

•Module Graph

•Effect on the problem domain (behavioral)

MICEI-University of Minho

• Program Comprehension: concepts and tools• Program Comprehension Approach• Strategy to relate different views• Case Study: EAR (Un Evaluador de Algoritmos

de Ruteo)• Conclusion• Future Work

MICEI-University of Minho

Consists in the insertion of useful statements into the source code to get runtime (dynamic) information that allows us to follow program execution.

MICEI-University of Minho

Instrumentation:

• Inspector Function: inserted at check points (begin and end of functions).

• Iteration Control Statements: inserted before inside and after cyclic statements.

MICEI-University of Minho

MICEI-University of Minho

int f (int x, int y)

{

float z,k;

/* more declarations*/

INPUT_INSPECTOR(“f”);

………

/* actions */

OUTPUT_INSPECTOR(“f”);

return value;

}

int f (int x, int y)

{

float z,k;

/* more declarations*/

………

/* actions */

return value;

}

MICEI-University of Minho

for(initialization, condition, action)

actions;

{ 1

for (initialization; condition; action)

{

actions;

2

}

3

}

1. push(s,numberOfTimes)2. v=pop(s); v=v-1; push(s,v)3. pop(s)

MICEI-University of Minho

int a;

int f (int x, int y)

{

float z,k;

/* more declarations*/

INPUT_INSPECTOR(“f”,data);

………

/* actions */

OUTPUT_INSPECTOR(“f”,data);

return value;

}

data

MICEI-University of Minho

long int (*f([][])(int, int (float *[],int []);

• Program Comprehension: concept and tools• Program Comprehension Approach• Strategy to relate different views• Case Study: EAR (Un Evaluador de Algoritmos

de Ruteo)• Conclusion• Future Work

MICEI-University of Minho

MICEI-University of Minho

The relationship between different levels of the architecture can be made using the information available in the information repository.

The problem appear when we want to relate the Operational and Behavioral views. In this case we can use BORS.

Program Output Used Functions to build the output

Behavioral View Operational View

?

The used functions to build the output are known but: What about each object in the problem domain?

Is it possible to recover the functions used to build each object?

MICEI-University of Minho

Program Output Used Functions to build the output

Behavioral View Operational View

!

Objects + Interface Nodes Node Functions Arcs Arc Functions .................................

Function execution tree

MICEI-University of Minho

1. Detect the functions related with each Problem Domain Object.

2. Build an fe-tree (Functions Execution Tree) with the used functions in runtime.

3. Explain the functions found in step 1 using the tree built in step 2.

MICEI-University of Minho

The Grep technique allow us to get all the functions related (by name) with an object (syntactic matching).

The programmer must analyze if the recovered functions are semantically related with the object under consideration.

Important:This process would be easier if the system

under study was implemented using Abstract Data Types.

MICEI-University of Minho

The functions used at runtime to build the output can be obtained through source code instrumentation.

Our annotation scheme inserts “inspector functions” at the beginning and at the end of each functions present in the source code.

With these information we can build a tree denominated fe-Tree.

MICEI-University of Minho

MICEI-University of Minho

• Program Comprehension: concept and tools• Program Comprehension Approach• Strategy to relate different views• Case Study: EAR (Un Evaluador de Algoritmos

de Ruteo)• Conclusion• Future Work

MICEI-University of Minho

MICEI-University of Minho

MICEI-University of Minho

MICEI-University of Minho

MICEI-University of Minho

MICEI-University of Minho

MICEI-University of Minho

MICEI-University of Minho

• Program Comprehension: concept and tools• Program Comprehension Approach• Strategy to relate different views• Case Study: EAR (Un Evaluador de Algoritmos

de Ruteo)• Conclusion• Future Work

MICEI-University of Minho

MICEI-University of Minho

The use of inspector functions (IF), weaved into the source code, allows us to capture the actual flow of the functions during execution.

To control the size of the output list of functions generated by the inpection, we adopted a suitable strategy based on the weaving of iteration control statements (ICS).

Both IF and ICS were inserted into the source code in a systematic instrumentation strategy that could be done automatically.

MICEI-University of Minho

With our approach we can obtain many different views of EAR, very useful to study and understand the system. Statcis:

• Assembly code• Source code• Function graph• Module graph

Dynamics:

• Runtime functions• Trace to module level• Trace to function level

MICEI-University of Minho

BORS is useful to relate the behavioral and operational views and to create a true aid for Program Comprehension.

BORS can be totally automatized if the programming paradigm is object oriented.

• Program Comprehension: concept and tools• Program Comprehension Approach• Strategy to relate different views• Case Study: EAR (Un Evaluador de Algoritmos

de Ruteo)• Conclusion• Future Work

MICEI-University of Minho

MICEI-University of Minho

It is necessary to develop a more robust data structure to handle the recovered information from our instrumentation scheme.

To develop strategies to decorate the algorithms output. In other words to show the behavioral-operational relation explicitly.

To implement metrics to help the programmer to select the input for BORS.

MICEI-University of Minho

To identify the domain objects.

To assess our tool, collecting experimental indicators about its use for program understanding.

MICEI-University of Minho