Semantic and Algorithmic Recognition Support to Porting Software Applications to Cloud - Trustworthy Eternal Systems via Evolving, Software Data and Knowledge - page 6

The Abstract Program Representation represents the recognized algorithmic
concepts in the source code and their structure, the relationships among them,
and groundings within the source code.
The above defined knowledge base components can be grouped in three differ-
ent levels for both the source and the target porting environments, as sketched
in (Fig. 1). In the first level, the grounding level , there are the basic information
extracted by parsing the source code to port, which are the Source API Graph
(in the scenario we have an API to map over another API), the Call Graph and
the Program Dependence Graph (in the scenario we have a source code to port)
in the source environment and the Target API Graph in the target environment.
In the Functional and Algorithmic Concept Level we have on the source side the
Abstract Program Representation Graph and the Candidate API Ontology Graph
witch represent the high level information derived respectively from the Program
Dependence Graph and the Source API Graph. On the source side at functional
and algorithm level we have the graph representation of the Functional Ontol-
ogy. In the Application Level we have concepts related to the application domain
which can be linked with functional and algorithmic concepts.
Fig. 1. Knowledge base levels
The source code is represented using two graph structures: the Program De-
pendence Graph suitable for algorithm recognition, discussed in Section 4.1, and
another based on the Call Graph with one node for each call in the source code.
Given these representations, the methodology tries to find an equivalence of
source code components and target API components, through graphical match-
making of their graph based semantic representations. These are the Abstract
Program representation and the Candidate API Ontology of the source code, and
the functional ontology with which the target API components are represented
and annotated.
The same approach can be used to find equivalent implementations of the
same functionalities among different API. If the two APIs (source and target)
are both semantically described and annotated with the functional ontology the
equivalence is quite straightforward to find because the two annotations will
refer to the same functional ontology concept; while if one of the two APIs is
not annotated, we can produce the Candidate API ontology Graph and match
it with the functional ontology, used to annotate the other API.