User Tools

Site Tools


towards_a_unified_source_code_measurement_framework_supporting_multiple_programming_languages

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
towards_a_unified_source_code_measurement_framework_supporting_multiple_programming_languages [2014/02/04 13:34]
yann
towards_a_unified_source_code_measurement_framework_supporting_multiple_programming_languages [2019/10/06 20:37] (current)
Line 8: Line 8:
  
 //​Yann-Gaël Guéhéneuc,​ 2014/​02/​03//​ //​Yann-Gaël Guéhéneuc,​ 2014/​02/​03//​
 +
 +This paper make explicit the problem of having consistent measurements across programming languages. It starts by observing three problems with the state-of-the-art and state-of-the-practice: ​
 +  - the inconsistent metric definitions across different programming languages;
 +  - which is aggravated by the inconsistent metrics definitions for the same languages across different tools;
 +  - the lack of tool support to analyse in the same, consistent framework components written in different languages.
 +
 +The paper then recalls that several tools exist and name a few of them (but not [[PADL]]...) and justifies the lack of multi-language support in these tools by the cost of developing analysers and metrics for different languages. It then proposes a new framework that should have a "​lower-cost"​ although it is not clear how different is the proposed framework from that of the previous tools. The paper implicitly states the need for a unified meta-model, which is then describes in the form of the Unified Code Model (UCM).
 +
 +The UCM is the result of a thorough and systematic study of [[http://​www.tiobe.com/​index.php/​content/​paperinfo/​tpci/​index.html|20 popular programming languages]] and of their measurable elements. Table III in the paper is very interesting because it provides a global view of the elements common and different across programming languages. However, I feel that the elements "​method",​ "​procedure",​ and "​function"​ could have been considered together wrt. the measurements. Also, it is not clear why the Ruby programming language is marked as having no modules. ​
 +
 +The paper then describes a tool, [[http://​www.unicoen.net/​|UNICOEN]],​ that can parse components in various programming languages and generate UCM models. Using UCM, UNICOEN, and a study of some major metrics, focusing "on size and complexity because they are the most important measurements"​ (McCabe, Halstead'​s,​ CK...), the paper shows the metrics values can be computed on components in Java and JavaScript.
 +
 +The paper does not raise the problem of dealing with the dependencies among heterogeneous components, i.e., components written in different programming languages. Also, it faces the same issues as other works: how to "​provide an easy way to measure a metric",​ "to evaluate the metrics of software written in more than one programming language",​ and to "use the same metric definition standard"​. It solves these issues through the UCM and UNICOEN, as we did with [[PADL]] and its various parsers. Now, the paper does not say, for example, if each UCO (unified code objects, our constituents) keep track of a line start and end, although they are map to statements. It does not consider the presence of "​ghosts",​ i.e., UCO known only be references but not analysed. Finally, it brushes the problem of consistency of the analysis and metric computations for different programming languages, which would be a very nice follow-up for this paper.
towards_a_unified_source_code_measurement_framework_supporting_multiple_programming_languages.1391520867.txt.gz · Last modified: 2019/10/06 20:37 (external edit)