Papers by Gustavo Villavicencio
The construction of the plan libraries as repository for automatic understanding systems is almos... more The construction of the plan libraries as repository for automatic understanding systems is almost a mystery. So far, there have been no reports that describe some technique on how to accomplish programs analysis about the construction of plan libraries of programming. This paper presents a technique based on the automatic comparison of slices. It permits the analyst to focus his attention on a meaningful code for the design of program plans. The results obtained until now confirm the feasibility of the approach, and lead to strengthen the practical application of the plan libraries in the maintenance and re-engineering process.
Reverse program calculation supported by code slicing
X Congreso Argentino de Ciencias de la Computación, 2004
Little has been written about the component provision problem (programming plans and domain conce... more Little has been written about the component provision problem (programming plans and domain concepts) for the repositories of knowledge in program understanding systems and reports that specifically address this issue are unknown. Model-driven and plan-driven approaches use repositories where construction and evolution are informal and depend on the experts. In domains where the expert is not available the only valid source of information is the source code. But, domain concept design and programming plans from the source code by non-expert professionals is not a trivial task. In this paper, a hybrid top-down/bottom-up approach based on algorithmic pattern matching and slicing techniques has begun to be defined in order to provide plans or concepts (termed activities in the model-driven approaches) to the knowledge base. Initially, the exploration area is restricted by slicing techniques, and then, software inspection tools are used to further limit the relevant areas. Finally, the initially hypothesized pattern is matched with these segments.
In [33] we have applied È È ½ È Ò as a conjuncture to reverse calculate the formal specifications... more In [33] we have applied È È ½ È Ò as a conjuncture to reverse calculate the formal specifications of a program È through the application of static slicing on output variables. This conjecture defines a calculation pattern: the formal specification for each slice is calculated and the whole program specification is obtained by combining the slice specifications by the split () combinator. However, the conjecture fails when we use conditioned slices as a complexity-reduction mechanism. Thus, it is necessary to define a new calculation pattern for the conditioned slices. Since we need to reconstruct the static slice on an output variable combining the conditioned slices on such variable, "transversal calculus" is required instead of a "linear calculation" as in [33]. The definition of the calculus patterns is important when facing the construction of the automatic support for the present approach because they contribute to the systematization of the calculus process.
Toward Ordering the Set of Modifications to Solve a Maintenance Request
2020 IEEE 44th Annual Computers, Software, and Applications Conference (COMPSAC), 2020
In this paper we set out the idea that the text plain nature of the software source code, as we k... more In this paper we set out the idea that the text plain nature of the software source code, as we know it today, is a strong obstacle for an effective maintenance. The reason is that all the software artifact elements, from the most complex to the simplest, are immediately available to the maintenance programmer. Such ease is deceitful since it allows the maintenance programmer to modify any component in any order. However, maintenance in any engineering field is inside-out intrinsically, and such essential characteristic should also be held in software maintenance. The maintenance scenario suggested here restricts modifications by the maintenance programmer and drives her to implement them following an order.
Modifiable Source Code Virtual Views
Proceedings of the XXXIII Brazilian Symposium on Software Engineering, 2019
This paper introduces the modifiable source code virtual view concept, which is a variant of a so... more This paper introduces the modifiable source code virtual view concept, which is a variant of a source code fragment from the version used to generate the binary code for execution, enriched with information provided by the impact analysis process. A modifiable source code virtual view supports the maintenance process instead of the corresponding source code fragment used to generate the binary code, as is the current practice today. The set of key maintenance attributes (maintainability, reusability, etc.) are improved in the view, while the (opposite) set of key software execution attributes (performance, security, etc.) are improved in the source code fragment to generate the binary code. In between, there are refactoring transformations that adjust the metrics related to each set of key attributes, which also support the propagation of modifications from the view to its corresponding fragment in execution.
A bottom-up approach to understand functional programs
Proceedings of The Fourth International C* Conference on Computer Science and Software Engineering - C3S2E '11, 2011
One affective way to carry out a program comprehension process is by refactoring the source code.... more One affective way to carry out a program comprehension process is by refactoring the source code. In this paper we explore this approach in the functional programming paradigm, on Haskell programs specifically. As result, we have identified many correlations between the traditional (procedural and object-oriented) program comprehension process and the so called understanding-oriented refactorings, in the functional programming context. Besides,
A New Software Maintenance Scenario Based on Refactoring Techniques
2012 16th European Conference on Software Maintenance and Reengineering, 2012
This research line proposes the classification of refactoring techniques according to two opposit... more This research line proposes the classification of refactoring techniques according to two opposite program properties: understanding and efficiency, being the former useful for maintenance while the latter for executing. Understanding-oriented refactoring and efficiency-oriented refactoring are considered the inverses of each other. Thus, through the application of the first sort of refactoring, understanding can be improved but efficiency can be affected.
In this paper a new maintenance scenario is outlined based on refactoring techniques. Specificall... more In this paper a new maintenance scenario is outlined based on refactoring techniques. Specifically, refactoring techniques are classified according to two opposed program properties: understanding and efficiency. Understanding oriented refactoring disassembles the program preparing it for maintenance, whereas those oriented to efficiency rearrange it for running. Also, we show the challenges raised from this new perspective on maintenance. At present, this ongoing research is being carried out in the functional
Refactoring for Comprehension
Software maintenance like maintenance in other engineering disciplines
Proceedings of the 22nd Acm Sigsoft International Symposium, Nov 11, 2014
Toward Ordering the Set of Modifications to Solve a Maintenance Request
To appear in proceedings of the IEEE Computer Society Signature Conference on Computers, Software and Applications (COMPSAC 2020)., 2020
In this paper we set out the idea that the text plain nature of the software source code,
as we... more In this paper we set out the idea that the text plain nature of the software source code,
as we know it today, is a strong obstacle for an effective maintenance.
The reason is that all the software artifact elements, from the most complex to the simplest,
are immediately available to the maintenance programmer.
Such ease is deceitful since it allows the maintenance programmer to modify any component in
any order. However, maintenance in any engineering field is inside-out intrinsically,
and such essential characteristic should also be held in software maintenance.
The maintenance scenario suggested here restricts modifications by the maintenance programmer
and drives her to implement them following an order.
Modifiable Source Code Virtual Views
Proceedings of the XXXIII Brazilian Symposium on Software Engineering (SBES 2019). ACM., 2019
This paper introduces the modifiable source code virtual view concept, which is a variant
of a so... more This paper introduces the modifiable source code virtual view concept, which is a variant
of a source code fragment from the version used to generate the binary code for execution,
enriched with information provided by the impact analysis process.
A modifiable source code virtual view supports the maintenance process
instead of the corresponding source code fragment used to generate the binary code, as is the current practice today.
The set of key maintenance attributes (maintainability, reusability, etc.) are improved in the view,
while the (opposite) set of key software execution attributes (performance, security, etc.) are improved
in the source code fragment to generate the binary code.
In between, there are refactoring transformations that adjust the metrics related to each set
of key attributes, which also support the propagation of modifications from the view to its
corresponding fragment in execution.
Work in progress
The bidirectional maintenance lifecycle is based on two referential contexts (execution and maint... more The bidirectional maintenance lifecycle is based on two referential contexts (execution and maintenance), each characterized by a set of proper software attributes, and connected by a bidirectional refactoring mechanism. Such mechanism transforms the implementation version with the corresponding set of software attributes in the execution context to the version with the corresponding set of software attributes in the maintenance context, and in reverse. This paper proposes the integration of the design level in this model. The result of such integration should be a full-automatic environment for reengineering and maintenance with the capacity for solving maintenance requests at a specific abstraction level while keeping the structure and quality synchronizations with the other levels. In turn, such synchronizations should be adjusted to each referential context, i.e. execution and maintenance.
Proceedings of the 22Nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, Nov 2014
Software maintenance exhibits many differences regarding how other engineering disciplines carry ... more Software maintenance exhibits many differences regarding how other engineering disciplines carry out maintenance on their artifacts. Such dissimilarity is caused due to the fact that it is easy to get a copy from the original artifact to be used in maintenance, and also because the flat dimension of the software text facilitates access to the components by simply using a text editor. Other engineering disciplines resort to different artifact 'versions' (obtained by dissassembling) where the introduction of modifications (previous comprehension) is easier. After which the artifact is reassembled. In software engineering this approach can be simulated by combining program transformation techniques, search-based software engineering technology and design attributes.
Proceedings of the 16th European Conference on Software Maintenance and Reengineering, 2012
This research line proposes the classification of refactoring techniques according to two opposit... more This research line proposes the classification of refactoring techniques according to two opposite program properties: understanding and efficiency, being the former useful for maintenance while the latter for executing. Understanding-oriented refactoring and efficiency-oriented refactoring are considered the inverses of each other. Thus, through the application of the first sort of refactoring, understanding can be improved but efficiency can be affected. On the other hand, by applying the second sort of refactoring, efficiency can be improved but understanding can be damaged. So, the challenge to be faced here is to transform a software artifact through the application of a sequence of understanding-oriented refactoring, and to execute maintenance with the most appropriate version obtained. After that, we plan to restore its original efficiency by the application of the opposite sequence of refactorings, i.e. efficiency-oriented refactoring. In this way, a new maintenance scenario is outlined. Up to now, this ongoing research is being carried out in the functional setting.
Proceedings of the 2011 International Conference on Software Engineering Research and Practice, Jul 2011
In this paper a new maintenance scenario is outlined based on refactoring techniques. Specificall... more In this paper a new maintenance scenario is outlined based on refactoring techniques. Specifically, refactoring techniques are classified according to two opposed program properties: understanding and efficiency. Understanding oriented refactoring disassembles the program preparing it for maintenance, whereas those oriented to efficiency rearrange it for running. Also, we show the challenges raised from this new perspective on maintenance. At present, this ongoing research is being carried out in the functional setting.
Proceedings of the Fourth International C* Conference on Computer Science and Software Engineering, May 2011
One affective way to carry out a program comprehension process is by refactoring the source code.... more One affective way to carry out a program comprehension process is by refactoring the source code. In this paper we explore this approach in the functional programming paradigm, on Haskell programs specifically. As result, we have identified many correlations between the traditional (procedural and object-oriented) program comprehension process and the so called understanding-oriented refactorings, in the functional programming context. Besides, we have identified a catalog of refactorings used to improve program efficiency which, applied in reverse order, are valuable for program understanding purposes. Coupled to these refactorings, there is a calculational process by (means of) which we obtain a full formal description of program functionality. All together, a bottom-up program comprehension strategy in the functional setting is described.
Uploads
Papers by Gustavo Villavicencio
as we know it today, is a strong obstacle for an effective maintenance.
The reason is that all the software artifact elements, from the most complex to the simplest,
are immediately available to the maintenance programmer.
Such ease is deceitful since it allows the maintenance programmer to modify any component in
any order. However, maintenance in any engineering field is inside-out intrinsically,
and such essential characteristic should also be held in software maintenance.
The maintenance scenario suggested here restricts modifications by the maintenance programmer
and drives her to implement them following an order.
of a source code fragment from the version used to generate the binary code for execution,
enriched with information provided by the impact analysis process.
A modifiable source code virtual view supports the maintenance process
instead of the corresponding source code fragment used to generate the binary code, as is the current practice today.
The set of key maintenance attributes (maintainability, reusability, etc.) are improved in the view,
while the (opposite) set of key software execution attributes (performance, security, etc.) are improved
in the source code fragment to generate the binary code.
In between, there are refactoring transformations that adjust the metrics related to each set
of key attributes, which also support the propagation of modifications from the view to its
corresponding fragment in execution.
as we know it today, is a strong obstacle for an effective maintenance.
The reason is that all the software artifact elements, from the most complex to the simplest,
are immediately available to the maintenance programmer.
Such ease is deceitful since it allows the maintenance programmer to modify any component in
any order. However, maintenance in any engineering field is inside-out intrinsically,
and such essential characteristic should also be held in software maintenance.
The maintenance scenario suggested here restricts modifications by the maintenance programmer
and drives her to implement them following an order.
of a source code fragment from the version used to generate the binary code for execution,
enriched with information provided by the impact analysis process.
A modifiable source code virtual view supports the maintenance process
instead of the corresponding source code fragment used to generate the binary code, as is the current practice today.
The set of key maintenance attributes (maintainability, reusability, etc.) are improved in the view,
while the (opposite) set of key software execution attributes (performance, security, etc.) are improved
in the source code fragment to generate the binary code.
In between, there are refactoring transformations that adjust the metrics related to each set
of key attributes, which also support the propagation of modifications from the view to its
corresponding fragment in execution.