Information Technology Reference
In-Depth Information
It is also assumed that the code to be ported includes implementations of
algorithms and functionalities included in the functional ontology, and calls or
libraries and APIs, which do not (necessarily) correspond to the target API.
The main idea underlying the methodology is the following: to automatically
recognize the algorithms and algorithmic concepts implemented in the source
code and the calls to libraries and APIs performing actions and functionalities
relevant to the target environment, compare through matchmaking the recog-
nized concepts and APIs with those present in the functional ontology which
describes the target API and semantically annotates its elements and calls, and
by means of this matching, eventually map the source code excerpts and the
source calls to APIs to the target API calls and elements.
The methodology represents the following components in a uniform, graph
based, representation, the
knowledge base
:
-
the
Target API
;
-
the
Grounding Ontology
;
-
the
Functional Ontology
;
-
the source code
Call Graph
;
-
the source code
API Graph
;
-
the
Candidate API Ontology Graph
;
-
the source code
Program Dependence Graph
;
-
the source code
Abstract Program Representation Graph
.
The
Target API
is the Application Programming Interface towards which
the porting activity is addressed. Examples are the APIs exposed by the Cloud
providers, offering Cloud resources and services at Infrastructure, Platform and
Application levels. The methodology assumes that this API is (manually) se-
mantically annotated with concepts of the Functional Ontology.
The
Grounding Ontology
is a syntactical representation on an API. It rep-
resents a base to build semantic annotations of the
grounding concepts
(the
syntactical elements of the API) with the Functional Ontology concepts.
The
Functional Ontology
represents a collection of concepts from the domain
of Programming Algorithms and Data Structures [8], general purpose function-
alities offered by libraries related to a given domain, such as Cloud Computing,
and Design Patterns [9].
The
Call Graph
represents the calling relationships between the source codes
procedures.
The
Candidate API Ontology
is an ontology automatically derived from an
API by applying a set of graph transformation patterns, as for instance illus-
trated in [1].
The
Program Dependence Graph
is a structural level representation of a pro-
gram, which represents dependence relationships (control and data) among the
program statements. In our methodology we use a PDG representation slightly
augmented with syntactical control and data dependence information.
Search WWH ::
Custom Search