persistência em aplicações desenvolvidas no paradigma

Congresso de Inovação, Ciência e Tecnologia do IFSP - 2016
Persistência em aplicações desenvolvidas no paradigma orientado a objetos – um estudo de caso
comparativo
PEDRO KARUT GIMENEZ1, RINALDO MACEDO DE MORAIS2
1
Graduando em Tecnologia em Análise e Desenvolvimento de Sistemas, Bolsista PIBIC/PIBIT do CNPQ, IFSP, Campus
Catanduva, [email protected].
2
Professor Doutor, IFSP, Campus Catanduva, [email protected].
Área de conhecimento (Tabela CNPq): Banco de Dados – 1.03.03.03-0
Apresentado no
7° Congresso de Iniciação Científica e Tecnológica do IFSP
29 de novembro a 02 de dezembro de 2016 - Matão-SP, Brasil
RESUMO: Esse artigo apresenta um estudo de caso que compara diferentes tecnologias para
persistência. Foram analisadas quatro versões de uma mesma aplicação orientada a objetos em que se
utilizou, como métricas para comparação, o tempo de desenvolvimento e o número de linhas de
código. Os resultados indicaram que houve menor esforço do desenvolvedor, respectivamente, na
versão que utilizou um banco de dados de objetos, seguida pela que utilizou um framework objetorelacional, um SGBD NoSQL e um SGBD relacional.
PALAVRAS-CHAVE: Orientação a Objetos; Framework de Persistência; SGBD Relacional; NoSQL.
Persistence in applications developed in the object-oriented paradigm – a case study
ABSTRACT: This article introduces a case study that compares different persistence technologies.
Four versions of the same object oriented application were analyzed in which some comparison
metrics were used as development time and the number of lines of code. The results showed that a
smaller effort was needed from the developer, respectively, in the object database version, followed by
the version that has used an object-relational framework, a NoSQL DBMS and a relational DBMS.
KEYWORDS: Object Orientation; Persistence Framework; Relational DBMS; NoSQL.
INTRODUÇÃO
Orientação a objetos (OO) é um paradigma emergente na indústria de software, que agrega
vantagens ao processo de desenvolvimento e, consequentemente, à qualidade do produto de software:
desenvolvimento modular, reuso, melhor organização e legibilidade do código e manutenibilidade. A
construção de sistemas OO inclui na definição de sua arquitetura as tecnologias que serão empregadas
no tratamento de persistência.
O uso de sistemas gerenciadores de bancos de dados relacionais exige o tratamento do gap
conceitual entre os paradigmas: o mapeamento de classes para relações e o tratamento das operações
CRUD (Create, Retrieve, Update e Delete), para armazenamento e recuperação de objetos em
memória secundária (YODER et al., 1998). A persistência em bancos de dados relacionais também
pode ser implementada com uso de frameworks objeto-relacionais, que tratam a diferença semântica
entre os paradigmas e disponibilizam uma interface com operações CRUD.
Em bancos de dados orientados a objetos é possível definir estruturas complexas de dados,
pelo uso de atributos de referência e tipos construtores (collection types – set, list, array e bag). Em
uma representação unificada de objetos, tais gerenciadores oferecem suporte à persistência por meio
do binding entre a linguagem de programação e o banco de dados (ELMASRI; NAVATHE, 2011).
As tecnologias NoSQL incluem soluções de armazenamento e processamento de alto volume
de dados, em uma arquitetura escalável, incluem mecanismos de inserção de dados de forma
incremental, eficiente e com suporte à função de persistência em cloud computing (VIEIRA, 2012).
Esse trabalho compara, em um estudo de caso, o esforço de desenvolvimento no uso das quatro
alternativas tecnológicas para persistência em uma aplicação OO.
MATERIAL E MÉTODOS
O processo desenvolvido incluiu a implementação de quatro versões de um mesmo sistema
orientado a objetos, com uso das seguintes ferramentas para persistência: (1) SGBD relacional
MySQL com acesso JDBC; (2) framework objeto-relacional JPA/Hibernate e MySQL; (3) SGBD
orientado a objetos Intersystems Caché e (4) Ferramenta NoSQL MongoDB.
A opção por JPA/Hibernate e MySQL deu-se à ampla utilização dessas ferramentas, enquanto
Mongo DB e Caché foram selecionados por serem avaliados como tecnologias inovadoras e
emergentes (FEINBERG et al., 2015).
Após ambientação e uso das ferramentas e desenvolvimento de um projeto piloto (GIMENEZ;
MORAIS, 2016), as quatro versões de uma mesma aplicação, foram desenvolvidas pelo pesquisador.
A aplicação inclui suporte às operações de coleta de materiais recicláveis, com funcionalidades para
cadastro de materiais, agentes ambientais, pontos de coleta, e registro de coletas, conforme
apresentado no diagrama de classes na Figura 1. A aplicação foi desenvolvida em Java, com uso da
IDE Netbeans, em uma interface Desktop orientada a eventos.
FIGURA 1. Modelo de Classes para o sistema alvo.
Foram utilizadas como métricas para comparação do esforço de desenvolvimento, com uso
das diferentes tecnologias em cada versão, o tempo dispendido e o volume total de linhas de código
escrito pelo desenvolvedor, excluindo-se o código gerado ou bibliotecas reutilizadas.
RESULTADOS E DISCUSSÃO
As quatro versões do sistema alvo foram implementadas nos meses de abril e maio de 2016,
na forma de um estudo de caso, em que foram registrados os tempos e número de linhas de código dos
artefatos desenvolvidos em cada versão. Inicialmente, foi desenvolvida uma interface comum,
utilizada em todas as versões, com o objetivo de uniformizar o tratamento das funcionalidades do
sistema.
A versão 1, com uso de MySQL, incluiu uma fase de mapeamento objeto-relacional e
implementação do banco de dados relacional e outra em que foram desenvolvidas as funcionalidades
de conexão e desenvolvimento e utilização das operações CRUD nas classes de domínio. A versão 2,
em MongoDB, iniciou com a criação do banco de dados, seguido pela criação das collections do
banco. A seguir, foram desenvolvidas as classes e métodos que realizam a conexão e as operações
CRUD com o SGBD.
A terceira versão para o sistema, desenvolvida com uso do framework objeto-relacional
JPA/Hibernate, incluiu uma única fase com três atividades: (1) Definição de acesso a dados, por meio
da parametrização da Unidade de Persistência; (2) Especificação das classes de entidades, por meio
das quais foram definidas as estruturas das classes, relacionamentos e atributos de referência e
mapeamento para tabelas e (3) Geração das classes Controllers, que implementam as operações
CRUD para cada classe.
A versão 4, em Caché, iniciou-se com a definição das classes de domínio no SGBDOO
(Sistema Gerenciador de Banco de Dados Orientado a Objetos), que disponibiliza o binding com java
por meio de geração de código, com classes representantes (padrão proxy) para uso na aplicação. Essas
classes disponibilizam toda a interface necessária para o desenvolvimento da aplicação.
As medidas coletadas no desenvolvimento das quatro versões da aplicação, com uso das
diferentes ferramentas para armazenamento e recuperação de objetos, são descritas na Tabela 1.
TABELA 1. Medidas de esforço observadas nas versões do sistema alvo.
Tecnologia de persistência
Tempo (minutos)
Linhas de Código
MySQL com JDBC
184,81
1115
MongoDB
136,48
721
Hibernate
126,03
607
Caché Intersystems
76,52
633
A primeira versão, com uso de SGBD relacional, apresentou maior esforço de
desenvolvimento, em tempo e volume de código, devido à necessidade de implementação das
operações CRUD nas classes de aplicação, que incluem as cláusulas SQL para armazenamento e
recuperação de objetos em tabelas.
Na versão 2, que utilizou o SGBD NoSQL Mongo DB, de modo semelhante à versão 1,
também foi necessário o desenvolvimento das operações CRUD nas classes, mas houve um pequeno
decréscimo de esforço, devido à semântica orientada a documentos.
Na terceira versão desenvolvida com uso do JPA/Hibernate observou-se considerável ganho
no esforço dispendido, devido principalmente ao mapeamento e geração de tabelas de modo
automático e disponibilização das operações CRUD nas classes controllers, geradas pelo framework.
Na versão 4, em Caché, observou-se o menor esforço, devido à representação unificada de
objetos na aplicação e no banco de dados e ao binding com java por meio de geração de código de
classes representantes (padrão proxy) para uso na aplicação. Essas classes disponibilizaram toda a
interface necessária para o desenvolvimento da aplicação.
CONCLUSÕES
Esse trabalho apresentou um estudo de caso de quatro versões de um mesmo sistema,
desenvolvido com diferentes tecnologias para persistência. As versões com uso de framework objetorelacional e banco de dados de objetos geraram menor volume de código desenvolvido e tempo
dispendido.
Deve-se observar, porém, as restrições inerentes à cada tecnologia, como a não garantia de
integridade de operações da ferramenta NoSQL, a ausência de padrão de interoperabilidade e
portabilidade com o uso do Caché. Espera-se que esse estudo ofereça uma visão comparativa das
tecnologias estudadas e auxilie profissionais no desenvolvimento de sistemas, mais especificamente no
que se refere ao armazenamento e recuperação de objetos em aplicações orientadas a objetos.
AGRADECIMENTOS
Ao órgão de fomento CNPQ pelo patrocínio da pesquisa de iniciação científica PIBIC/PIBIT.
Ao Instituto Federal de Educação, Ciência e Tecnologia de São Paulo, campus Catanduva por
todo seu corpo docente, estrutura e pela oportunidade de realização da pesquisa.
REFERÊNCIAS
D. FEINBERG et al. Magic Quadrant for Operational Database Management Systems.
Disponível
em:
<https://www.gartner.com/doc/reprints?id=1-2PO8Z2O&ct=151013&st=sb>,
Outubro/2015. Acesso em: 24 de agosto 2015.
ELMASRI, R.; NAVATHE, S. Sistemas de Banco de Dados 6ª Ed. Pearson Addison Wesley,
São Paulo, 2011.
GIMENEZ; MORAIS. Persistência em aplicações desenvolvidas no paradigma orientado a
objetos – um estudo de caso comparativo. 2016.
VIEIRA, M. R. et al. Bancos de Dados NoSQL: conceitos, ferramentas, linguagens e estudos
de casos no contexto de Big Data. Simpósio Brasileiro de Bancos de Dados, 2012.
YODER, et al. Connecting Business Objects to Relational Databases. Urbana 51, 2005.
Disponível em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.7703&rep=rep1&type=pdf>.
Acesso
em: 20 de agosto de 2015