The document proposes an ontology for technical debt in PL/SQL development. It discusses relevant concepts like ontologies, technical debt, and PL/SQL. An initial model is developed in Protégé with five types of technical debt - documentation, requirements, tests, design, and code. The model could be expanded to include more debt types and relationships. The ontology provides a standardized vocabulary to describe technical debt for PL/SQL developers.

1. Proposal of an Ontology Applied to Technical Debt on PL/SQL
Development
José Jorge Barreto Torres, Methanias C. R. Junior and Rogério Patrício C. do Nascimento
Universidade Federal de Sergipe – UFS
Keywords: Technical Debt, Ontology, Software Engineering, PL/SQL.
Abstract: An Ontology describes a concept. Here is proposed an Ontology applied to Technical Debt on PL/SQL
development. The main goal is to create an abstract vocabulary, constructing a better interaction between a
team of developers. Technical Debt (TD) is an abstract definition recently explored. However, this concept
represents something that always existed inside software development and maintenance teams. TD is a debt
that must be paid, now or later, since the software conception. This work develops an initial model and
leave it opened to complementation and improvement, craving to create this new specification.
1 INTRODUCTION
Studies on ontology inside Computer Science have
being developed in a growing rhythm, searching on
how to describe several research areas on this field.
On the same way, many articles involving systems
maintenance tend to explore Technical Debt (TD) to
avoid surprises on cost during the software
development process.
Ontologies are specifications of a concept. They
allow us creating a common vocabulary for a group,
facilitating communication about a specific theme.
Technical Debt is an abstract concept that
represents something that always existed inside a
software product development team. TD is nothing
more than something left behind (a debt) that is going
to be charged later.
The Procedural Language / Structured Query
Language (PL/SQL) commonly used to implement
active databases, is applied on this Ontology’s
development.
This proposal’s main goal is to start constructing a
specification over the abstract concept of Technical
Debt, PL/SQL-oriented (called for us OnTD). The
intention is to make it easy sharing some kind of
knowledge within Software Engineering. To develop
this proposal, an expert in active databases
programming is consulted, providing the target
problems related to Technical Debt in PL/SQL. The
present work is focused on this programming
language because this is used by Oracle RDBMS
(Relational Database Management System), being the
most robust language.
After this introduction, a related work to the
theme is presented. From this related work, this
proposal is constructed. On section 3 the main
concepts bonded to Ontology and Technical Debt are
going to be explored. Section 4 describes an initial
model of Ontology applied to Technical Debt on
development of active databases that uses PL/SQL.
After that, some results about the Ontology to TD are
discussed in section 5. Finally, section 6 presents
some conclusions about the research and some tips
about future works.
2 RELATED WORKS
Alves et. al. (2014) developed an initial model of an
ontology applied to technical debt on the software
development process. This paper shows an ontology’s
design that points to several problems concerning
technical debts inside software development. These
problems may be debts represented by the following
types: Architectural, Construction, Code, Defect,
Design, Documentation, Infrastructure, People,
Process, Requirement, Service, Test and Test
Automation.
This author’s model was planned in two phases:
the first one that defines criteria on quality and the
second one where an expert not involved on the
ontology development was consulted to test the

2. model. A Figure 1 shows the visual representation of the ontology about the technical debt concept.
Figure 1: Ontology visual representation designed on Protégé. Extracted from Alves et. al. (2014)
3 RELEVANT CONCEPTS
The relevant concepts involved on this research are
explored on this section, searching to absorb the
essential fundaments to develop the case study.
3.1 Ontology
The “explicit specification of a conceptualization”
is a definition used on Computer Science’s field,
proposed by Gruber (1993). He created a document
teaching how to specify an ontology. Ontologies
attend to other knowledge fields too, as Social
Sciences, Natural Sciences and Language Sciences.
França (2009) reinforce all the elements that make
and ontology: classes, relations, functions and other
objects. This structure makes easy sharing knowledge
in an organized and standard manner. In ontologies,
specific terminologies are created to avoid confusion
by a common group of people studying a specific
subject.
The “Ontology” term is inherited from
Philosophy, being translated in a knowledge that can
be explicitly represented by declarative and formal
ways. The set of objects from a specific domain that
can be represented is called the Universe of
Discourse. This set of objects and their relations
make a Representational Vocabulary (Gruber, 1993).
Gruber also presents an study area named
Ontolingua. An Ontolingua is a system to describe
ontologies in a compatible format with several other
representative languages or, with other words, the
union of a representative linguistic with an
ontological knowledge. It provides a way to define
classes, relationships, functions, objects and theories.
An Ontolingua makes possible sharing an ontology
between several users and research groups, using
their own means of representation. Its syntax and
semantics are based on Knowledge Interchange
Format (KIF). KIF is a language directed to
publication and communication of a knowledge.
Ontolingua can be translated from KIF-written
definitions to other specific representational forms.
Some language examples are: Loom, Epikit,
Algernon and pure KIF. KIF language, that defines de
axioms of an Ontolingua, have a Lisp-like notation
(Gruber, 1993).
The set of idioms recognized and translated by an
ontology is defined in another ontology called Frame
Ontology. This structure specifies thru a declarative
form, the supported primitive representative types.
Ontologies can also be defined hierarchically,
where each term has a father, representing a
taxonomic relation. See an example on Figure 2.
B
C
A
Figure 2: Example of a taxonomic relation. Adapted from
França (2009).

3. Figure 2 helps to exemplify a simple taxonomic
relation, thru the following axiom: The human being
[A] is an animal [B] that is rational [C].
A well-defined vocabulary is very important to
produce an ontology. It is from this vocabulary that
constructions between relationships will exist,
making possible to form coherent expressions used
on problems resolution (França, 2009).
3.2 Technical Debt (TD)
The explored term suggests a description of the
involved cost on constant changes and maintenances
in a system during its development cycle.
According to Alves et. al. (2014 apud
CUNNINGHAM, 1992) this abstract concept
represents something already known that is not going
to be executed at the time, having the risk of a future
problem when this thing will be necessary. This may
represent, for example, a technical requirement that
wasn’t fulfilled by deadline reasons, but in the future
will require the team’s attention to the
implementation, may even generate a more elevated
development cost.
The TD metaphor is constantly used to describe
the delay of some software maintenance tasks. For
the TD to be used properly, it should be classified
with different weights to its future evaluation, if it
worth or not to be paid and in how much time (Guo
and Seaman, 2011).
Some studies suggest TD’s classification methods
directed to cost’s estimation. Codabux and Williams
(2013) cite other research that explore direct bonds
between several Technical Debt types and its costs.
Furthermore, Codabux studies best practices to debt
payment priorization.
3.3 Procedural Language / Structured
Query Language (PL/SQL)
PL/SQL Is a third-generation programming
language that was developed, at first, to process SQL
commands. It makes possible storing programs with
high-complexity level inside an Oracle database
server (Oracle, 2014).
4 PROPOSAL OF AN ONTOLOGY
TO TECHNICAL DEBT ON
PL/SQL DEVELOPMENT: ONTD
This study’s main objective is to develop and
ontology to Technical Debt on the PL/SQL
development, using as a base model, the Alves et. al.
(2014) work. Some entities used by that work are
harnessed to instantiate the proposed debts.
To support a vocabulary targeted to PL/SQL code,
some entities are defined to represent the technical
debts. The indicatives of their causes are presented
too. They are described below:
 Code Debt: Packages modularization (Stored
Procedures e Functions); Exception
handling; Code reusability;
 Design Debt: Data types choice; Indexation;
Data-access strategy; Storage architecture;
 Documentation Debt: Document’s
standards; Development methods;
Versioning; Document’s updates;
 Requirement Debt: Effective communication
with stakeholders; Restrictions; Adherence
to business rules;
 Test Debt: Unitary Tests; Black box and
white box tests; Stress tests.
These data are compiled and fed into an Ontology
construction software, called Protégé. This system
allows the creation of entities, classes and their
interactions. Taxonomies can be defined and graphs
may be generated. Its source code is stored in the
Web Ontology Language (OWL) format and may be
exported to other formats.
Every ontology created on Protégé starts with a
thing entity that represents “anything”. Entities and
its relationships are generated, initially, from the
thing entity. With this, taxonomic relationships are
constructed and defined based on the proposed
axioms.
Figure 3 shows the visual representation of the
OnTD.
The PL/SQL programming language is imposed
to this theme, but this model may be applied to other
active databases’ technology.
Figure 3: Ontology visual representation build in Protégé.

4. On Figure 3 some dependencies between several
types of debts and a parent type named “Technical
Debt”, are shown. Other possibilities involving
taxonomic relationships must be explored in future
studies.
5 ONTD SHORT ANALYSIS
The explored TDs on this experiment are initially
defined in five types: Documentation Debt,
Requirement Debt, Test Debt, Design Debt and Code
Debt.
Each one of these types where discussed with an
expert programmer on PL/SQL, looking to find
indicators that sustained them. It’s clear the need to a
better development of this ideas and an enhancement
of taxonomic relations that are result of the initially
proposed debts.
The Documentation Debt indicates everything that
has relation to patterns, methodologies and whatever
necessary to the software product development,
including versioning.
Code Debt includes programming best practices,
that weren’t applied. Later, code maintenance can be
hardened, making this debt to be paid in some
moment.
It was understood as a Requirement Debt, the one
involving stakeholders during requirements phase,
mainly on initial stages on the software development
cycle. This debt may be confused with a Technical
Requirement Debt, also important but not explored on
this work.
Design Debt concerns to database’s conceptual
and physical models. All pertinent and specific to
some SGBD technology is charged on this category.
In the last moments of a software product
development, Test Debts arise. They charge test
questions beyond performance and functionality on
the constructed code.
All debts include the possibility to be segmented
in other several distinct debts, to better specialization.
Inside the available time to develop this study wasn’t
possible a greater immersion.
6 CONCLUSION AND FUTURE
WORKS
Finally, some conclusions are made about
constructing a new Ontology and the main problems
during this creation process are found.
Creating a new Ontology is complex and involves
many abstract concepts from a specific knowledge
area. During this work’s development, the main
difficulty found is generating abstraction for a
vocabulary, with help from an expert. Only a few
entities were defined, but is known that is not enough
to standardize the focused concept. Many more must
be done inside this theme. The study performed in
this paper suggests the OnTD, without hindering its
improvement and complement. It was shown the need
to improve all the explored debts, besides being
possible segmentation in other more specific debt
kinds.
On future works, is recommended deepening of
this ontology, searching for new taxonomic relations
between the existent entities. New relationships may
be generated by several axioms involved on PL/SQL
development. Other PL/SQL debts can be inserted on
this OnTD like, for example, the already mentioned
Technical Requirements Debt.
REFERENCES
T. R. Gruber. A Translation Approach to Portable Ontology
Specifications. Knowledge Systems Laboratory -
Stanford University, 1993.
P. C. França. Conceitos, Classes e/ou Universais: com o
que é que se constrói uma ontologia? Disponível em:
http://www.linguamatica.com/index.php/linguamatica/a
rticle/view/10/13. LinguaMÁTICA, 2009.
Y. Guo e C. Seaman. Tracking Technical Debt – An
Exploratory Case Study. 27th IEEE International
Conference on Software Maintenance (ICSM), 2011.
Z. Codabux e B. Williams. Managing Technical Debt: An
Industrial Case Study. Mississippi State University,
2013.
N. S. R. Alves, L. F. Ribeiro, V. Caires, T. S. Mendes e R.
O. Spínola. Towards an Ontology of Terms on
Technical Debt. 2014.
W. Cunningham, “The Wycash Portfolio Management
System,” in ACM SIGPLAN OOPS Messenger (Vol. 4,
No. 2). ACM. December 1992, pp. 29-30.
Oracle. Oracle Database 12c PL/SQl. Disponível em:
http://www.oracle.com/technetwork/database/features/p
lsql/index.htm. Last access in November 18th, 2014