Resumo — As Ontologias visam especificar um conceito. Neste trabalho é proposta uma Ontologia aplicada à Dívida Técnica voltada ao desenvolvimento PL/SQL para facilitar a interação entre os programadores de uma equipe. A Dívida Técnica (DT) é um conceito abstrato que está sendo explorado há pouco tempo. Entretanto, esse conceito representa algo que sempre existiu nas equipes de desenvolvimento de software. A DT é simplesmente uma dívida que existe desde a concepção do produto de software e que uma hora, provavelmente, deverá ser paga. Este trabalho desenvolve um modelo inicial e deixa aberta a sua complementação e melhoria, na tentativa de criar essa especificação de conceito.

Abstract — An Ontology describes a concept. Here is proposed an Ontology applied to Technical Debt on PL/SQL development intended to create an abstract vocabulary, constructing a better interaction between a team of developers. Technical Debt (TD) is an abstract definition and it’s being explored recently. 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, trying to create this new specification.

Palavras-chave — dívida técnica, ontologia, engenharia de software, pl/sql

I. INTRODUÇÃO

s estudos de Ontologias na área de Ciência da Computação têm sido desenvolvidos em ritmo crescente,

procurando descrever os diversos nichos de pesquisa desse campo. Da mesma maneira, muitos trabalhos que envolvem manutenção de sistemas exploram a Dívida Técnica, para evitar surpresas no custo durante o processo de desenvolvimento de software.

O

Ontologias são especificações de um conceito. Servem para criar um vocabulário que será compartilhado por um grupo que estuda um assunto específico e, por isso, facilita a comunicação acerta do tema estudado [1].

A Dívida Técnica é um conceito abstrato que representa algo que sempre existiu em times de desenvolvimento de um produto de software. A DT nada mais é que algo que foi

deixado para fazer depois (uma dívida) e que posteriormente será cobrado [5].

A linguagem de programação Procedural Language / Structured Query Language (PL/SQL) que é comumente implementada em bancos de dados ativos, é utilizada para o desenvolvimento desta Ontologia.

O objetivo principal desta proposta é iniciar a construção de uma especificação do conceito abstrato da Dívida Técnica, voltada à linguagem PL/SQL. A intenção é de facilitar o compartilhamento desse tipo de conhecimento no ramo da Engenharia de Software. No desenvolvimento da proposta um especialista em programação em bancos de dados ativos é consultado, fornecendo os principais problemas relacionados à Dívida Técnica em PL/SQL. O trabalho é focado nesta linguagem, por ser utilizada no Sistema Gerenciador de Banco de Dados (SGBD) Oracle, sendo a mais robusta do mercado.

No capítulo II serão exploradas as principais conceitualizações ligadas à Ontologia e à Dívida Técnica. Após a revisão da literatura, no Capítulo III, são citados os trabalhos relacionados como o tema proposto. No Capítulo IV é proposto um modelo inicial de Ontologia aplicada à Dívida Técnica no desenvolvimento de bancos de dados ativos que utilizam a linguagem PL/SQL. Por fim, o capítulo V apresenta algumas conclusões acerca da pesquisa e alguns trabalhos futuros.

II.TRABALHOS RELACIONADOS

Alves et. al. (2014) desenvolveu um modelo inicial de Ontologia aplicada à Dívida Técnica no processo de desenvolvimento de software. Esse projeto apresenta um desenho de ontologia que aponta a vários problemas de dívidas na manutenção de software. Esses problemas podem ser dívidas representadas pelos seguintes tipos: Arquitetura, Construção, Código, Defeitos, Design, Documentação, Infraestrutura, Pessoas, Processos, Requisitos, Serviços, Testes e Automação de Testes.

O modelo desse autor foi concebido em duas fases: a primeira que define os critérios de qualidade; na segunda, um especialista não envolvido no desenvolvimento da Ontologia é consultado para testar o modelo. A Figura 1 denota a representação visual da Ontologia sobre o conceito de Dívida Técnica.

Proposta de uma Ontologia Aplicada à Dívida Técnica no Desenvolvimento em PL/SQL

José Jorge Barreto Torres, Rogério Patrício C. do Nascimento e Methanias Colaço Rodrigues. Junior.

Universidade Federal de Sergipe - UFS.

Figura 1: Representação visual da Ontologia, desenhada no Protégé.Fonte: Alves et. al. Towards an Ontology of Terms on Technical Debt.[5]

III. REFERENCIAL TEÓRICO

O referencial teórico envolvido nesta pesquisa é explorado neste capítulo, onde se busca absorver os conceitos básicos essenciais ao desenvolvimento do estudo de caso.

A. Ontologia

A “especificação explícita de uma conceitualização” é a definição que utilizamos no ramo da Ciência da Computação, proposta por Thomas Gruber [1] que, no ano de 1992, cria um documento denotando como ocorre a especificação de uma Ontologia. As Ontologias também atendem a outras áreas de conhecimento como Ciências Sociais, Ciências Naturais e Ciências da Linguagem.

Patrícia França [2] reforça todos os elementos que compõem uma Ontologia: Classes, relacionamentos, funções e outros objetos. Essa estrutura facilita a partilha de conhecimento de maneira organizada e padronizada. Nas ontologias, terminologias específicas são criadas com o propósito de evitar confusões por um grupo de pessoas em comum que estuda um determinado assunto, compreendendo-o de forma isonômica.

O termo “Ontologia” é herdado da Filosofia, que se traduz em um conhecimento que pode ser explicitamente representado por meios formais declarativos. O conjunto de objetos de um domínio específico que pode ser representado é denominado Universo do Discurso. Esse conjunto de objetos e seus relacionamentos formam um Vocabulário Representativo [1].

Gruber também apresenta uma área de estudo a qual chama de Ontolinguística. Uma Ontolíngua é um sistema para descrever ontologias em um formato compatível com várias linguagens representativas ou, com outras palavras, a união de uma linguística representativa com um conhecimento ontológico. Ela fornece uma forma de definir classes, relacionamentos, funções, objetos e teorias. A Ontolíngua torna possível o compartilhamento de uma Ontologia entre vários usuários e grupos de pesquisa, utilizando os seus próprios meios de representação. A sua sintaxe e semântica é baseada no Knowledge Interchange Format (KIF) que é uma

linguagem destinada à publicação e comunicação de conhecimento. A Ontolíngua pode ser traduzida de definições escritas em KIF para outras formas de representação específicas. Alguns exemplos dessas linguagens são: Loom, Epikit, Algernon e o KIF puro. A linguagem KIF, que vai definir os axiomas de uma Ontolíngua, possui uma notação semelhante ao Lisp [1].

O conjunto de idiomas que uma Ontologia reconhece e traduz é definido em outra Ontologia que pode ser chamada de Estrutura Ontológica. Esta estrutura especifica por meio de uma forma declarativa os tipos representativos primitivos suportados [1].

As Ontologias também podem ser definidas de maneira hierárquica, onde cada termo possui um pai, apresentando relações taxonômicas. Observa-se a representação deste exemplo na Figura 2.

Figura 2: Exemplo de uma relação taxonômica. Fonte: Adaptado de França [2].

A Figura 2 serve para exemplificar uma relação taxonômica bastante simples, através do seguinte axioma: O ser humano (denominado A) é um animal (denominado B) que é racional (denominado C) [2].

Um vocabulário bem definido é de suma importância para se produzir uma Ontologia. É a partir deste vocabulário que construções de relacionamentos existirão, com a possibilidade

B

C

A

de formar expressões coerentes utilizadas na resolução de problemas [1].

B. Dívida Técnica

O termo explorado sugere uma descrição do custo envolvido nas constantes mudanças e manutenções em um sistema durante seu ciclo de desenvolvimento.

De acordo com Alves et. al. (2014 apud CUNNINGHAM, 1992) esse conceito abstrato representa algo já conhecido que não será executado no momento, existindo um risco de gerar problemas no futuro quando este for necessário. Isso pode representar, por exemplo, um requisito técnico que deixou de ser cumprido por conta de expiração de prazos, mas que no futuro irá exigir a atuação da equipe para sua implantação, podendo até gerar um custo de desenvolvimento mais elevado [5].

A metáfora da Dívida Técnica é constantemente utilizada para descrever o retardo de certas tarefas de manutenção de software. Para que a DT seja utilizada com qualidade, ela deve ser classificada com o intuito de se atribuir pesos diferentes para sua futura avaliação, se vale a pena ou não ser paga e em quanto tempo [3].

Alguns trabalhos propõem métodos de classificação de DTs para estimação dos custos. O estudo de Codabux (2013) referencia outras pesquisas que efetuam ligações diretas entre os diversos tipos de Dívida Técnica e os seus custos. Além disso, Codabux estuda as melhores práticas para priorização de pagamento das dívidas [4].

C.PL/SQL

Esse termo é um acrônimo para Procedural Language / Structured Query Language. É uma linguagem de terceira geração que, inicialmente, foi desenhada para processar comandos SQL. Com o PL/SQL é possível armazenar programas com alto nível de complexidade em um servidor de banco de dados Oracle [7].

IV. PROPOSTA DA ONTOLOGIA PARA O DESENVOLVIMENTO PL/SQL

O objetivo deste estudo é desenvolver uma Ontologia sobre a Dívida Técnica voltada ao desenvolvimento na linguagem PL/SQL, utilizando como base o modelo de Alves et. al. (2014). Algumas entidades utilizadas por ele serão utilizadas para instanciar as dívidas propostas.

Para apoiar um vocabulário direcionado ao código PL/SQL, são definidas algumas entidades que representam dívidas técnicas e as indicações que causam a ocorrência dessas dívidas. Essas entidades e seus indicativos são descritos abaixo:

Dívida de Código: Modularização em pacotes (Stored Procedures e Functions); Tratamento de exceções; Reaproveitamento de código;

Dívida de Design: Escolha dos tipos de dados; Utilização de índices; Estratégia de acesso a dados; Arquitetura de armazenamento;

Dívida de Documentação: Padronização dos documentos; Metodologia de desenvolvimento;

Sistema de versionamento; Atualizações de documentos;

Dívida de Requisitos: Comunicação efetiva com stakeholders; Levantamento de restrições; Aderência às regras de negócio;

Dívida de Testes: Testes unitários; Testes de caixa branca e caixa preta; Testes de stress.

Esses dados são compilados e alimentados em um software de construção de Ontologias denominado Protégé. Esse sistema permite a criação de entidades, classes e suas interações. Taxonomias podem ser definidas e gráficos gerados. O seu código-fonte é armazenado no formato da linguagem OWL (Web Ontology Language), podendo também ser exportado para outros formatos.

Toda ontologia criada no Protégé já inicia com uma entidade thing que representa “qualquer coisa”. Todas as entidades e suas relações são geradas, primeiramente, a partir da thing. Com isso, relações taxonômicas são construídas e definidas baseadas nos axiomas propostos.

A Figura 3 exibe em linhas gerais a representação visual da proposta inicial de Ontologia voltada à Dívida Técnica no desenvolvimento de bancos de dados ativos que utilizam o PL/SQl.

A linguagem PL/SQL é imposta ao tema, mas nada impede que este modelo de ontologia de dívida técnica também seja aplicado a outras tecnologias de bancos de dados ativo.

Figura 3: Representação visual da Ontologia proposta, gerada pelo Protégé.Fonte: Autor.

Na Figura 3 são visualizadas dependências entre diversos tipos de dívidas de um tipo pai chamado “Dívida Técnica”. Outras possibilidades de relações taxonômicas devem ser exploradas em estudos posteriores.

V. ANÁLISE DOS RESULTADOS

As DTs exploradas neste experimento são definidas, inicialmente, em cinco: Dívida de Documentação, Dívida de Requisitos, Dívida de Testes, Dívida de Design e Dívida de Código.

Cada uma destas foi discutida com o especialista, procurando achar indicadores que as sustentassem. É clara a necessidade de um maior desenvolvimento dessas ideias e um aprimoramento de relações taxonômicas que sejam frutos dessas dívidas propostas de início.

A Dívida de Documentação indica tudo relacionado a padrões, metodologias e o que for necessário ao acompanhamento do desenvolvimento do produto de software, incluindo suas versões.

A Dívida de Código inclui as melhores práticas de programação da linguagem alvo, que deixam de ser aplicadas. Posteriormente, a manutenção do código poderá ser dificultada, fazendo com que essa dívida tenha que ser paga em algum momento.

Foi entendido como Dívida de Requisito toda aquela que envolva os stakeholders durante o levantamento de requisitos, principalmente nos estágios iniciais do ciclo de desenvolvimento de software. Essa dívida pode também ser confundida com uma Dívida de Requisitos Técnicos, que também é importante mas não é explorada neste trabalho.

A Dívida de Design diz respeito aos modelos conceituais e físicos de um Banco de Dados. Tudo o que é pertinente e específico a uma determinada tecnologia de SGBD é cobrado nesta categoria.

Nos momentos finais do desenvolvimento do produto de software, surgem as Dívidas de Teste. Essas cobram as questões de testes de desempenho e funcionalidade do código construído.

Todas as dívidas incluem a possibilidade de serem segmentadas em duas ou três dívidas distintas, para uma melhor especialização. Pelo tempo disponível para desenvolvimento deste estudo, não foi possível um maior aprofundamento.

VI. CONCLUSÕES E TRABALHOS FUTUROS

Finalmente, algumas conclusões são efetuadas acerca da construção de uma nova Ontologia e verificar os principais problemas encontrados durante esse processo de criação.

A criação de uma Ontologia é complexa por envolver muitos conceitos abstratos de uma área de conhecimento específica.

Durante o desenvolvimento desse trabalho, a principal dificuldade encontrada é gerar a abstração de um vocabulário com a ajuda do especialista. Apenas algumas entidades foram definidas, mas sabe-se que não é o suficiente para padronizar o conceito em foco, portanto, muito mais deve ser feito. O estudo realizado nesse artigo sugere uma Ontologia, sem impedir que esta seja complementada e melhorada. Foi mostrada a necessidade de se aprimorar as dívidas exploradas, além de ser possível segmentá-las em outros tipos de dívidas mais específicos.

Para futuros trabalhos, recomendamos o aprofundamento desta ontologia, buscando novas relações taxonômicas entre as entidades já existentes. Novos relacionamentos podem ser gerados através de diversos axiomas envolvidos no desenvolvimento em PL/SQL. Outras dívidas em PL/SQL podem ser inseridas na ontologia, como a Dívida de Requisitos Técnicos, já mencionada no capítulo V.

REFERÊNCIAS

[1] T. R. Gruber. A Translation Approach to Portable Ontology Specifications. Knowledge Systems Laboratory - Stanford University, 1993.

[2] 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/article/view/10/13

[3] Y. Guo e C. Seaman. Tracking Technical Debt – An Exploratory Case Study. 27th IEEE International Conference on Software Maintenance (ICSM), 2011.

[4] Z. Codabux e B. Williams. Managing Technical Debt: An Industrial Case Study. Mississippi State University, 2013.

[5] 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.

[6] W. Cunningham, “The Wycash Portfolio Management System,” in ACM SIGPLAN OOPS Messenger (Vol. 4, No. 2). ACM. December 1992, pp. 29-30.

[7] Oracle. Oracle Database 12c PL/SQl. Disponível em: http://www.oracle.com/technetwork/database/features/plsql/index.html