Numiton

NOTE: To use the advanced features of this site you need javascript turned on.

Home Knowledge Base Software Migrators Generality Metric

Generality Metric

The design and implementation of a software migrator is a complex task. The migrator should ideally cover all variations of the source language syntax and semantics, and be able to translate them into optimal target language constructs. Nevertheless, a partially developed migrator could successfully translate a well chosen set of applications. An incremental approach to development is thus possible, each iteration increasing the coverage degree of the source language.

In order to track progress and have a decisional basis for the features of each iteration, some sort of metric must be devised. The proposed generality metric for software migrators refers to the coverage degree of source language constructions and runtime libraries.

Source language constructions are described in the language's grammar and include program structures, data and instruction definitions. Measurement of the generality degree for software migrators takes into consideration the following aspects:

  1. The coverage degree for constructions and functionalities of the source language

    This degree does not only refer to the number of distinct constructions and functionalities. In the case of complex migrators, the implementation coefficient of each source language feature must be taken into account. A situation where some constructions are partially supported may appear during the development iterations. Determining the implementation coefficient is done by the migrator’s development team, taking into account for example man-days or cost for the current implementation and the estimated effort to completion.

  2. The importance coefficient of each construction

    The importance coefficient of a language construction is also determined by the translator’s developers and is based on the average usage frequency of the construction in a representative set of applications.

  3. The translation degree of runtime libraries

    Usually, apart from language constructions a software application uses a standard program library and possibly a set of third-party libraries. Translating an application also requires translating these libraries.

    A difficulty arises when the source code for third-party libraries is not available. Even more, for many languages not even the source code of the standard library is available.

    When the source code of a library is available, the translation degree of the library does not influence the migrator’s generality. This is because the same migrator is used to automatically translate the library as well as the application.

    When the source code of a library is not available, automated translation cannot be accomplished. Translating the behavior of the source language library into an equivalent behavior in the target language becomes a manual operation.

    Because the standard library is used by any application written in the source language, it is mandatory that the generality metric include the translation degree of the standard library.

Taking these factors into consideration, the proposed generality metric formula is:

where:

GTF – the software migrator generality degree,
CoImpi – the importance coefficient for each construction of the source language,
CoImpli – the implementation coefficient of each source language construction,
ConT – the total number of constructions in the source language,
CL – the importance coefficient of the language,
GTBst – the translation degree of the standard library.

 

The first term of the formula represents the coverage degree of the language constructions.

The CL importance coefficient is the translation generality ratio in relation with the translation generality of the standard library. It depends on the source language. When the source code of the standard library is available, CL has maximum value (1) because the translator's generality is entirely conditioned by the coverage degree of the language constructions. This ideal situation does not often occur, because standard libraries usually have proprietary implementations. Availability might also depend on the licensing model for the source code of the standard library.

The development of software migrators should aim to increase the generality metric as much as it is economically feasible (the development costs are justified). Other aspects, such as execution speed and memory requirements of the software migrator, should also be put in balance.