SlideShare uma empresa Scribd logo
1 de 4
Baixar para ler offline
 
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. 
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. 
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. 
O
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. 
C 
A 
Figura 2: Exemplo de uma relação taxonômica. 
Fonte: Adaptado de França [2]. 
B 
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 
de formar expressões coerentes utilizadas na resolução de
3 
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
4 
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

Mais conteúdo relacionado

Destaque

0011 mak-upatstvo-za-elektronsko-istrazuvanje-pmio final-layout-1
0011 mak-upatstvo-za-elektronsko-istrazuvanje-pmio final-layout-10011 mak-upatstvo-za-elektronsko-istrazuvanje-pmio final-layout-1
0011 mak-upatstvo-za-elektronsko-istrazuvanje-pmio final-layout-1Daniela Lavurovska
 
Erico verissimo 02
Erico verissimo 02Erico verissimo 02
Erico verissimo 02Marli Maciel
 
20090830淡水
20090830淡水20090830淡水
20090830淡水ivy6691
 
Midia kit Missão Cinderela
Midia kit Missão CinderelaMidia kit Missão Cinderela
Midia kit Missão CinderelaMissao2013
 
Los DecáLogos Del Profesor
Los DecáLogos Del ProfesorLos DecáLogos Del Profesor
Los DecáLogos Del ProfesorAnakastillo9
 
Case sete licões da apple
Case   sete licões da appleCase   sete licões da apple
Case sete licões da appleAnderson Lucas
 
Actividades En Bien De La Cumunidad Y Su
Actividades En Bien De La Cumunidad Y SuActividades En Bien De La Cumunidad Y Su
Actividades En Bien De La Cumunidad Y SuCarlos Correa
 
TI como canal y pilar de la adopción de Lean
TI como canal y pilar de la adopción de LeanTI como canal y pilar de la adopción de Lean
TI como canal y pilar de la adopción de LeanJuan José Vázquez Rubio
 
Yes To Stamina
Yes To StaminaYes To Stamina
Yes To StaminaYES Cell
 
นักแสดงนำประกอบ Clip เพื่อการเรียนรู้
นักแสดงนำประกอบ Clip เพื่อการเรียนรู้นักแสดงนำประกอบ Clip เพื่อการเรียนรู้
นักแสดงนำประกอบ Clip เพื่อการเรียนรู้tassanee chaicharoen
 
சா. தேவதாஸ்
சா. தேவதாஸ்சா. தேவதாஸ்
சா. தேவதாஸ்Badri Seshadri
 

Destaque (20)

0011 mak-upatstvo-za-elektronsko-istrazuvanje-pmio final-layout-1
0011 mak-upatstvo-za-elektronsko-istrazuvanje-pmio final-layout-10011 mak-upatstvo-za-elektronsko-istrazuvanje-pmio final-layout-1
0011 mak-upatstvo-za-elektronsko-istrazuvanje-pmio final-layout-1
 
Jawaban Cp Mba 32
Jawaban Cp Mba 32Jawaban Cp Mba 32
Jawaban Cp Mba 32
 
Erico verissimo 02
Erico verissimo 02Erico verissimo 02
Erico verissimo 02
 
20090830淡水
20090830淡水20090830淡水
20090830淡水
 
Cartells Curiosos
Cartells CuriososCartells Curiosos
Cartells Curiosos
 
Midia kit Missão Cinderela
Midia kit Missão CinderelaMidia kit Missão Cinderela
Midia kit Missão Cinderela
 
Organic Mission Prezentáció
Organic Mission PrezentációOrganic Mission Prezentáció
Organic Mission Prezentáció
 
Los DecáLogos Del Profesor
Los DecáLogos Del ProfesorLos DecáLogos Del Profesor
Los DecáLogos Del Profesor
 
Case sete licões da apple
Case   sete licões da appleCase   sete licões da apple
Case sete licões da apple
 
Actividades En Bien De La Cumunidad Y Su
Actividades En Bien De La Cumunidad Y SuActividades En Bien De La Cumunidad Y Su
Actividades En Bien De La Cumunidad Y Su
 
Wa1
Wa1Wa1
Wa1
 
TI como canal y pilar de la adopción de Lean
TI como canal y pilar de la adopción de LeanTI como canal y pilar de la adopción de Lean
TI como canal y pilar de la adopción de Lean
 
Yes To Stamina
Yes To StaminaYes To Stamina
Yes To Stamina
 
นักแสดงนำประกอบ Clip เพื่อการเรียนรู้
นักแสดงนำประกอบ Clip เพื่อการเรียนรู้นักแสดงนำประกอบ Clip เพื่อการเรียนรู้
นักแสดงนำประกอบ Clip เพื่อการเรียนรู้
 
Acqua
AcquaAcqua
Acqua
 
Lei de murphy
Lei de murphyLei de murphy
Lei de murphy
 
Vivela
VivelaVivela
Vivela
 
1 anno con te
1 anno con te1 anno con te
1 anno con te
 
சா. தேவதாஸ்
சா. தேவதாஸ்சா. தேவதாஸ்
சா. தேவதாஸ்
 
Galeria fotogràfica del Centre Obert de Camprodon
Galeria fotogràfica del Centre Obert de CamprodonGaleria fotogràfica del Centre Obert de Camprodon
Galeria fotogràfica del Centre Obert de Camprodon
 

Semelhante a Artigo ontologias v2

Ontologia x meta modelo
Ontologia x meta modeloOntologia x meta modelo
Ontologia x meta modelogenival21
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de SoftwareAricelio Souza
 
Uma_interface_em_linguagem_natural_para
Uma_interface_em_linguagem_natural_paraUma_interface_em_linguagem_natural_para
Uma_interface_em_linguagem_natural_paraVinícios Pereira
 
Glossário APDSI para a Sociedade da Informação v2007
Glossário APDSI para a Sociedade da Informação v2007Glossário APDSI para a Sociedade da Informação v2007
Glossário APDSI para a Sociedade da Informação v2007Luis Borges Gouveia
 
Aula de Introdução - JAVA
Aula de Introdução  - JAVAAula de Introdução  - JAVA
Aula de Introdução - JAVAMoises Omena
 
Aula de Introdução - JAVA
Aula de Introdução  - JAVAAula de Introdução  - JAVA
Aula de Introdução - JAVAMoises Omena
 
Net uma revisão sobre a programação orientada a objetos
Net   uma revisão sobre a programação orientada a objetosNet   uma revisão sobre a programação orientada a objetos
Net uma revisão sobre a programação orientada a objetosLP Maquinas
 
Orientação a objetos java
Orientação a objetos javaOrientação a objetos java
Orientação a objetos javavicnetepc
 
Umlv4 090813182632-phpapp02
Umlv4 090813182632-phpapp02Umlv4 090813182632-phpapp02
Umlv4 090813182632-phpapp02Jhonefj
 
Modalidades Síncronas de Comunicação e Elementos de Percepção em Ambientes de...
Modalidades Síncronas de Comunicação e Elementos de Percepção em Ambientes de...Modalidades Síncronas de Comunicação e Elementos de Percepção em Ambientes de...
Modalidades Síncronas de Comunicação e Elementos de Percepção em Ambientes de...TelEduc
 
Atps paradigmas linguagem programacao
Atps paradigmas linguagem programacaoAtps paradigmas linguagem programacao
Atps paradigmas linguagem programacaopablogranola
 
Exemplo de Ontologia da Pos-Graduação do CEFET-PI
Exemplo de Ontologia da Pos-Graduação do CEFET-PIExemplo de Ontologia da Pos-Graduação do CEFET-PI
Exemplo de Ontologia da Pos-Graduação do CEFET-PIAislan Rafael
 
Potfólio de Evidências
Potfólio de EvidênciasPotfólio de Evidências
Potfólio de EvidênciasPaulo Sateles
 
Livro Algoritmos e Programação de Computadores Autores JR., Dilermando
Livro Algoritmos e Programação de Computadores Autores JR., DilermandoLivro Algoritmos e Programação de Computadores Autores JR., Dilermando
Livro Algoritmos e Programação de Computadores Autores JR., DilermandoOs Fantasmas !
 

Semelhante a Artigo ontologias v2 (20)

Poo frank
Poo frankPoo frank
Poo frank
 
Ontologia x meta modelo
Ontologia x meta modeloOntologia x meta modelo
Ontologia x meta modelo
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Uma_interface_em_linguagem_natural_para
Uma_interface_em_linguagem_natural_paraUma_interface_em_linguagem_natural_para
Uma_interface_em_linguagem_natural_para
 
Glossário APDSI para a Sociedade da Informação v2007
Glossário APDSI para a Sociedade da Informação v2007Glossário APDSI para a Sociedade da Informação v2007
Glossário APDSI para a Sociedade da Informação v2007
 
Gestão de Terminologia
Gestão de TerminologiaGestão de Terminologia
Gestão de Terminologia
 
Ass owl
Ass   owlAss   owl
Ass owl
 
Guia do usuário - ProjectLibre 1.5
Guia do usuário - ProjectLibre 1.5Guia do usuário - ProjectLibre 1.5
Guia do usuário - ProjectLibre 1.5
 
Aula de Introdução - JAVA
Aula de Introdução  - JAVAAula de Introdução  - JAVA
Aula de Introdução - JAVA
 
Aula de Introdução - JAVA
Aula de Introdução  - JAVAAula de Introdução  - JAVA
Aula de Introdução - JAVA
 
Net uma revisão sobre a programação orientada a objetos
Net   uma revisão sobre a programação orientada a objetosNet   uma revisão sobre a programação orientada a objetos
Net uma revisão sobre a programação orientada a objetos
 
UML
UMLUML
UML
 
Orientação a objetos java
Orientação a objetos javaOrientação a objetos java
Orientação a objetos java
 
Umlv4 090813182632-phpapp02
Umlv4 090813182632-phpapp02Umlv4 090813182632-phpapp02
Umlv4 090813182632-phpapp02
 
Aula7-Ontologia.ppt
Aula7-Ontologia.pptAula7-Ontologia.ppt
Aula7-Ontologia.ppt
 
Modalidades Síncronas de Comunicação e Elementos de Percepção em Ambientes de...
Modalidades Síncronas de Comunicação e Elementos de Percepção em Ambientes de...Modalidades Síncronas de Comunicação e Elementos de Percepção em Ambientes de...
Modalidades Síncronas de Comunicação e Elementos de Percepção em Ambientes de...
 
Atps paradigmas linguagem programacao
Atps paradigmas linguagem programacaoAtps paradigmas linguagem programacao
Atps paradigmas linguagem programacao
 
Exemplo de Ontologia da Pos-Graduação do CEFET-PI
Exemplo de Ontologia da Pos-Graduação do CEFET-PIExemplo de Ontologia da Pos-Graduação do CEFET-PI
Exemplo de Ontologia da Pos-Graduação do CEFET-PI
 
Potfólio de Evidências
Potfólio de EvidênciasPotfólio de Evidências
Potfólio de Evidências
 
Livro Algoritmos e Programação de Computadores Autores JR., Dilermando
Livro Algoritmos e Programação de Computadores Autores JR., DilermandoLivro Algoritmos e Programação de Computadores Autores JR., Dilermando
Livro Algoritmos e Programação de Computadores Autores JR., Dilermando
 

Mais de Jorge Barreto

Proposal of an Ontology Applied to Technical Debt on PL/SQL Development
Proposal of an Ontology Applied to Technical Debt on PL/SQL DevelopmentProposal of an Ontology Applied to Technical Debt on PL/SQL Development
Proposal of an Ontology Applied to Technical Debt on PL/SQL DevelopmentJorge Barreto
 
Projeto de sw revisado
Projeto de sw revisadoProjeto de sw revisado
Projeto de sw revisadoJorge Barreto
 
Modelo plano projeto de sw oo
Modelo plano projeto de sw ooModelo plano projeto de sw oo
Modelo plano projeto de sw ooJorge Barreto
 

Mais de Jorge Barreto (6)

Proposal of an Ontology Applied to Technical Debt on PL/SQL Development
Proposal of an Ontology Applied to Technical Debt on PL/SQL DevelopmentProposal of an Ontology Applied to Technical Debt on PL/SQL Development
Proposal of an Ontology Applied to Technical Debt on PL/SQL Development
 
Projeto de sw revisado
Projeto de sw revisadoProjeto de sw revisado
Projeto de sw revisado
 
Tabela de riscos
Tabela de riscosTabela de riscos
Tabela de riscos
 
Modelo plano projeto de sw oo
Modelo plano projeto de sw ooModelo plano projeto de sw oo
Modelo plano projeto de sw oo
 
Projeto de SW
Projeto de SWProjeto de SW
Projeto de SW
 
Der físico
Der físicoDer físico
Der físico
 

Artigo ontologias v2

  • 1.  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. 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. 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. O
  • 2. 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. C A Figura 2: Exemplo de uma relação taxonômica. Fonte: Adaptado de França [2]. B 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 de formar expressões coerentes utilizadas na resolução de
  • 3. 3 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
  • 4. 4 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