Desenvolvimento de Framework de Mapeamento Objeto Relacional para a Plataforma Android

Transcrição

1 4 Desenvolvimento de Framework de Mapeamento Objeto Relacional para a Plataforma Android Aline Odone Santiago 1, Carlos Eduardo Pacheco Menezes 1, Fábio Koiti Shiomi 1 Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Campus Guarulhos {meodone09, pachecomenezes, fk.shiomi}@gmail.com Resumo. Este trabalho aborda o desenvolvimento de um framework de mapeamento objeto relacional para a plataforma móvel Android, que permite a realização de operações de persistência no banco de dados SQLite presente no Android através do mapeamento de um modelo de classes para as suas respectivas tabelas no banco de dados. 1. Introdução 1.1 Persistência de dados e mapeamento objeto relacional A persistência de dados consiste no armazenamento confiável e coerente de informações em um meio não-volátil de dados, ou seja, em um dispositivo físico como um disco rígido. A persistência de dados pode ser realizada em um banco de dados, arquivos de texto, arquivos XML, entre outros. O surgimento do paradigma da programação orientada a objetos possibilitou uma nova maneira de se tratar a forma como os dados são utilizados pelos programas, diferente da forma como os dados são tratados no modelo relacional. Num primeiro momento, ao longo dos anos 80 surgiu uma nova categoria de bancos de dados, conhecidos como banco de dados orientados a objetos. Porém problemas como baixo desempenho, a falta de uma linguagem de consulta padronizada ao estilo SQL e altos custos impedem a adoção destes bancos em larga escala (SILVEIRA et al., 2006). A partir de então foi abordada a técnica de mapeamento objeto relacional que visa eliminar a impedância entre o modelo relacional e o modelo de orientado a objetos, o primeiro framework a utilizar este conceito foi o TopLink da empresa The Object People no ano de 1994, no ano de 1996 o TopLink ganhou uma versão para Java chamada TopLink for Java (SMITH, [S.d.]).

2 5 Em 2002 Gavin King criou o framework Hibernate, referência em mapeamento objeto relacional na plataforma Java por sua simplicidade e desempenho, sendo seus conceitos utilizados amplamente em vários outros frameworks escritos tanto em Java, quanto em outras linguagens ( History - Hibernate - JBoss Community, [S.d.]). Atualmente com o aumento do poder de processamento dos smartphones e dispositivos móveis, a utilização de mapeamento objeto relacional começa a se tornar viável com o desenvolvimento de frameworks específicos para estas plataformas, temos como exemplos Active Android, Active Android Record e ORMLite. 1.2 Mercado de dispositivos móveis e a plataforma Android O mercado de dispositivos móveis (celulares, palms, PDAs, smartphones) está em rápido crescimento, houve um crescimento de 19% no número de vendas de dispositivos móveis no primeiro quadrimestre de 2011 em relação ao mesmo período de Sendo que nesse período os smartphones são responsáveis por 23,6% do total de aparelhos comercializados. As vendas dessa categoria de dispositivo registraram um aumento de 85% em apenas um ano. O principal responsável por impulsionar as vendas de smartphones é a plataforma Android da empresa Google. Foram vendidos 36,2 milhões de equipamentos, no primeiro quadrimestre de 2011, utilizando o Android, o que o deixou com uma participação de 36% do mercado. (Gartner, 2011). A Tabela 1 contém os dados das vendas mundiais de smartphones no primeiro quadrimestre de 2011.

3 6 Tabela 1. Vendas mundiais de smartphones por sistema operacional no primeiro quadrimestre de 2011 (Milhares de Unidades) Company 1Quad11 1Q11 Market Share (%) 1Quad10 1Q10 Market Share (%) Android ,8 36, ,6 9,6 Symbian ,5 27, ,7 44,2 ios ,2 16, ,7 15,3 Research In Motion ,0 12, ,5 19,7 Microsoft 3.658,7 3, ,2 6,8 Other OS 3.357,2 3, ,9 4,4 Total ,3 100, ,5 100,0 1.3 Android Android é uma plataforma open-source criada pela empresa Google para o desenvolvimento de aplicações para dispositivos móveis. Inclui um sistema operacional baseado no kernel Linux e diversas bibliotecas e API s de desenvolvimento (LECHETA, 2010). A Figura1, retirada do site oficial da plataforma Android demonstra os componentes principais da arquitetura da plataforma. Figura 1. Diagrama com os principais componentes da plataforma Android

4 7 1.4 Métricas de Software Métricas de Software referem-se a uma ampla variedade de medidas de software de computador, uma métrica quando aplicada a um software mede ou quantifica uma característica do mesmo. O software é medido por muitas razões: indicar a qualidade do produto, avaliar os benefícios (em termos de produtividade e qualidade) derivados de novos métodos e ferramentas de software (PRESSMAN, 2006; Software Metrics, [S.d.]). Como exemplos de tipos de métricas existem as métricas técnicas que se concentram nas características do software (por exemplo, complexidade lógica, grau de modularidade) e as métricas orientadas a tamanho que são medidas diretas do software e do processo por meio do qual ele é desenvolvido (por exemplo, linhas de código) (PRESSMAN, 2006; REZENDE, 2006). 1.5 Frameworks de software Um framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação (FAYAD; SCHMIDT, 1997). Sendo assim, o principal propósito de um framework é ajudar no processo de desenvolvimento de aplicações. Ele permite que as aplicações sejam desenvolvidas mais rapidamente e mais facilmente, e deve resultar em uma aplicação de qualidade superior (MOTA, 2010). A plataforma Android se encontra em constante desenvolvimento e crescimento entre os usuários, sendo a versão 3.1 a mais atual disponível durante a escrita do presente trabalho, porém, apesar da constante evolução, a comunidade de desenvolvedores de aplicativos para a plataforma ainda não conta com uma ampla gama de frameworks, entre eles os frameworks de mapeamento objeto relacional. Com o exposto acima encontramos as seguintes justificativas para a realização deste trabalho: a procura dos desenvolvedores por um framework do gênero para a plataforma Android e a inexistência de framework gratuito com as funcionalidades propostas por este trabalho. O restante do presente trabalho encontra-se estruturado da seguinte maneira: a seção 2 introduz o leitor aos objetivos propostos por este trabalho; a seção 3 aborda os métodos utilizados para alcançar tais objetivos e as ferramentas utilizadas para tal; a seção 4 demonstra os resultados obtidos ao longo do trabalho; na seção 5 os resultados obtidos são discutidos e melhorias são apontadas e novas funcionalidades são propostas a este trabalho; por fim a

5 8 seção 6 apresenta as conclusões tiradas a partir dos resultados obtidos e a seção 7 aborda propostas para trabalhos futuros. 2. Objetivos 2.1 Objetivo primário O objetivo deste trabalho é o desenvolvimento de um framework de mapeamento objeto relacional para a plataforma Android que forneça uma interface transparente para a persistência de objetos no banco de dados relacional SQLite presente nesta plataforma, o framework desenvolvido chama-se Nano ORM. O framework será dotado das seguintes funcionalidades: realização das operações básicas de persistência de objetos (Inserção, busca por identificador único, retonar todas as instâncias de uma classe, atualização e remoção); um conjunto de anotações para o mapeamento objeto relacional; suporte a carga de objetos sob demanda (Lazy Loading) e por fim, suporte a operações de persistência de objetos em cascata. 2.2 Objetivos secundários Desenvolvimento de um simples aplicativo demo que faça a persistência objeto-relacional, utilizando a API padrão da plataforma Android, este aplicativo se chama AppAndroid. Desenvolvimento de outro simples aplicativo demo que faça a persistência objetorelacional, utilizando o framework Nano ORM desenvolvido neste trabalho, o nome usado para este aplicativo é AppNanoORM. Extrair e comparar métricas de software dos aplicativos AppAndroid e AppNanoORM. 3. Método A seção de método encontra-se organizada da seguinte maneira: a subseção 3.1 trata do método de construção do framework; a subseção 3.2 aborda a construção do aplicativo AppNanoORM e os materiais utilizados; a subseção 3.3 descreve os métodos e materiais empregados no desenvolvimento do aplicativo AppAndroid; e por fim a seção 3.4 demonstra o método de extração e comparação de métricas.

6 9 3.1 Método de construção do framework A construção do framework foi baseada na proposta de Scott W. Ambler em seu artigo intitulado The Design of a Robust Persistence Layer For Relational Databases (AMBLER, 2005), porém, foram realizadas algumas alterações tais como, a simplificação do mecanismo de persistência e método de configuração, visando maior simplicidade e alinhamento com os recursos propostos por este trabalho. A subseção aborda o mecanismo de persistência de objetos; a subseção trata do uso da técnica de lazy loading pelo framework e a subseção demonstra como este objetivo foi alcançado através da utilização da programação orientada a aspectos, a subseção descreve o método de configuração utilizado pelo framework e, por fim, a subseção lista os materiais utilizados para a construção do framework Mecanismo de persistência (Inserção, atualização, busca, remoção) Scott W. Ambler (AMBLER, 2005) em seu artigo citado no início desta seção propõe um modelo de sete classes responsáveis por realizar o mapeamento entre uma determinada classe e sua respectiva tabela no banco de dados. A Figura 2, retirada do artigo proposto por Ambler demonstra o modelo proposto por ele: Figura 2. Classes do mecanismo de mapeamento proposto por Scott W. Ambler

7 10 Este mecanismo foi simplificado para o desenvolvimento do framework Nano ORM onde ele é composto por apenas duas interfaces chamadas ClassMap e AssociationMap respectivamente e duas classes responsáveis por implementá-las chamadas AndroidClassMap e AndroidAssociationMap. As classes que implementam a interface ClassMap possuem todos os métodos necessários para que seja realizado o mapeamento de objetos de uma determinada classe para sua respectiva tabela no banco de dados, dentre suas responsabilidades estão a construção das instruções SQL necessárias a persistência dos objetos, assim como prover informações sobre a classe e tabela mapeadas, além disto ClassMap e suas implementações tem como responsabilidade a construção de objetos das classes mapeadas a partir de cursores retornados pelo banco de dados. As implementações de ClassMap realizam estas responsabilidades sempre com base na configuração por meio de anotações incluída nas classes a serem mapeadas pelo framework e também com base em convenções. A classe AndroidClassMap nada mais é do que a implementação de ClassMap responsável por mapear objetos para o banco de dados SQLite presente na plataforma Android. A interface AssociationMap e suas implementações encapsulam o comportamento necessário para a realização do mapeamento das associações entre objetos de duas classes distintas e a construção de suas respectivas instruções SQL, sendo que, sua utilização se dá quando é necessária uma operação de Lazy Loading. A classe AndroidAssociationMap é responsável por implementar as responsabilidades da interface AssociationMap na plataforma Android.

8 11 ORM: A Figura 3 demonstra as classes que compõem o mecanismo de mapeamento do Nano Figura 3. Classes do mecanismo de mapeamento do Nano ORM As operações de persistência são iniciadas sempre a partir da interface Manager e suas implementações, porém esta interface apenas delega a execução das operações de persistência a outra interface chamada DataSource. A interface DataSource possui os métodos necessários para a implementação básica do acesso a uma fonte de dados qualquer, isto foi feito desta maneira para que o framework possa realizar o mapeamento para outros mecanismos de persistência além de um banco de dados relacional, por exemplo arquivos de texto ou arquivos XML. Por hora o framework Nano ORM possui apenas uma implementação da interface DataSource chamada DataSourceImpl, esta classe encapsula o acesso a bases de dados relacionais. A classe DataSourceImpl controla o acesso a bases de dados relacionais, para isso ela conta com um instância da interface DbConnection que abstrai a conexão utilizada para o acesso ao banco de dados, com isso o framework poderá no futuro trabalhar com suporte a mais bancos de dados, sendo que, no caso do acesso a um banco de dados na plataforma

9 12 Android a classe que implementa a interface DbConnection chama-se AndroidDbConnection. Além do exposto anteriormente a classe DataSourceImpl possui uma coleção de instancias de ClassMap que são utilizadas para obter as instruções SQL a serem executadas através da instancia de DbConnection durante as operações de persistência, uma para cada classe mapeada pelo framework, estas instancias de ClassMap são obtidas a partir da classe ClassMapFactory, desta forma a classe DataSourceImpl fica desacoplada de qualquer banco de dados. A Figura 4 demonstra classes que compõem o mecanismo de persistência do Nano ORM: Figura 4. Classes do mecanismo de persistência do Nano ORM O apêndice B deste trabalho contém o diagrama de classes completo do framework. O banco de dados SQLite possui suporte a poucos tipo de dados, ao total são cinco (NULL, INTEGER, REAL, TEXT, BLOB) ( Datatypes In SQLite Version 3, [S.d.]), o framework suporta todos eles com a exceção do tipo BLOB, porém o framework suporta mais tipos além destes estendendo a gama tipos suportados pelo SQLite. Isto é conseguido através do mapeamento de tipos da linguagem Java para os tipos compatíveis no SQLite, a Tabela 2 demonstra os tipos mapeados pelo framework:

10 13 Tabela 2. Tipos de dados mapeados pelo Nano ORM Tipo de dado Java Tipo de dado SQLite java.util.date java.sql.date java.util.calendar Boolean java.lang.boolean INTEGER INTEGER INTEGER TEXT TEXT Os tipos de dados numéricos inteiros e de ponto flutuante da linguagem Java são mapeados para os tipos INTEGER ou REAL presentes no SQLite Lazy loading A inicialização tardia ou carga de objetos sob demanda é uma técnica em nível de objeto para melhorar o desempenho do sistema através de um objeto proxy (AMBLER, [S.d.]). Um proxy é um objeto substituto que controla o acesso a outro objeto (GAMMA et al., 1994). O objetivo da inicialização tardia é destinar recursos de memória apenas quando necessário carregando e instanciando um objeto no momento em que é absolutamente necessário (MILES, 2004). O mecanismo de lazy loading foi implementado utilizando a linguagem AspectJ, uma linguagem orientada a aspectos, os detalhes da implementação desta funcionalidade são abordados na subseção a seguir Programação orientada a aspectos O paradigma de programação orientada a aspectos foi criado no ano de 1997 por Gregor Kiczales e sua equipe nos laboratórios da empresa Xerox. O objetivo da equipe era construir um conjunto que permitisse à linguagem de programação, composta por uma linguagem central e várias linguagens específicas de domínio, expressar de forma ideal as características sistêmicas (também chamadas de ortogonais ou transversais) do comportamento do programa. A essa abordagem dá-se o nome de meta-programação. (WINCK; JUNIOR, 2006) Em um primeiro momento, os compiladores destinados à programação orientada a aspectos não geram um produto final (um programa executável ou interpretável), mas sim um

11 14 novo código. Este código resultante deve ser novamente compilado, desta vez em conjunto com o código do sistema, para que então seja gerado o produto final. Outra característica no modelo de meta-programação presente na programação orientada a aspectos é a reflexão computacional, em que parte do código gerado é destinada a alterar características do próprio programa em tempo de execução. (WINCK; JUNIOR, 2006) A necessidade de utilização da programação orientada a aspectos na elaboração do trabalho se deu por uma limitação encontrada na máquina virtual presente na plataforma Android chamada Dalvik Virtual Machine. A Dalvik é uma máquina virtual otimizada para dispositivos móveis (PEREIRA; SILVA, 2009), diferente da Java Virtual Machine, sendo assim, embora a linguagem utilizada no desenvolvimento de aplicativos seja a linguagem Java o bytecode executado sobre esta máquina virtual não é um bytecode Java padrão (PEREIRA; SILVA, 2009). Durante o desenvolvimento da funcionalidade de carga sob objetos sob demanda (Lazy Loading) foi tentado o uso do design pattern Proxy dinâmico. O emprego deste pattern requer que as classes persistidas pelo framework sejam alteradas em tempo de execução para que possam suportar a carga de objetos sob demanda. Esta operação necessita que uma nova classe que estenda as capacidades da classe mapeada pelo framework seja gerada, criando a necessidade da geração de um novo bytecode e conseqüentemente a sua carga pela máquina virtual. Implementamos e testamos com sucesso este algoritmo na Java Virtual Machine, contudo houve problemas com a utilização desta técnica na plataforma Android por que aparentemente a máquina virtual Dalvik não suporta a geração de bytecode em tempo de execução. Com a impossibilidade de se utilizar pattern Proxy dinâmico outra solução tentada foi desenvolver o componente de carga de objetos sob demanda na linguagem AspectJ. Esta linguagem adiciona o suporte necessário à programação orientada a aspectos. Deste modo não necessitamos de geração de bytecode em tempo de execução já que a alteração da classe mapeada pelo framework ocorre em tempo de compilação quando o compilador da linguagem AspectJ adiciona o código necessário a funcionalidade de Lazy Loading na classe mapeada. O uso da programação orientada a aspectos também proporcionou um maior desempenho ao framework, já que operações mais custosas como a geração de

12 15 bytecode em tempo de execução foram eliminadas do código fonte e transferidas para o momento da compilação do aplicativo que faz uso do framework. Além do componente de carga de objetos sob demanda, as funcionalidades de operações de persistência em cascata e gerenciamento de relacionamentos muitos-para-muitos também foram desenvolvidas com a linguagem AspectJ, o que permitiu a redução da complexidade envolvida na construção das classes responsáveis por realizar a persistência dos objetos Método de configuração do framework Para que o framework possa trabalhar de maneira adequada é necessária a realização de uma configuração mínima que envolve a decoração das classes a serem mapeadas com as anotações fornecidas pelo framework e pelo subseqüente registro da classe no framework onde a configuração realizada com as anotações é validada com a finalidade de encontrar erros de configuração. O método de configuração por anotações foi baseado na API de persistência JPA, porém simplificado para atender as necessidades especificas do framework dado que o mesmo não oferece todo o espectro de funcionalidades da API JPA. A Figura 5 contém um pequeno exemplo da configuração de uma classe a ser persistida pelo framework: Figura 5. Exemplo de uma classe configurada com as anotações do framework Materiais utilizados Os seguintes softwares foram utilizados para a construção do framework Nano ORM: o software de modelagem UML Umbrello para confeccionar os diagramas necessários, a IDE

13 16 Eclipse em conjunto ao Android SDK que é o kit de desenvolvimento de aplicativos para a plataforma Android, o plugin AJDT que adiciona o suporte a linguagem AspectJ. 3.2 Método de construção do aplicativo AppNanoORM Para a validação deste trabalho foi desenvolvido um aplicativo Android que utiliza o framework desenvolvido para realizar as operações de persistência no banco de dados, este aplicativo chama-se AppNanoORM. O aplicativo valida as principais funcionalidades do framework, como exemplo, o módulo de configuração, as quatro operações básicas de persistência (inserção, atualização, remoção e retorno de dados do banco de dados) e os quatro mapeamentos de associações suportadas (um para um, um para muitos, muitos para um e muitos para muitos). Seu modelo de classes representa um simples cadastro de clientes, produtos e pedidos de produtos efetuados pelos respectivos clientes, estas classes de domínio utilizam os quatro tipos de associações e foram adicionadas anotações de classe fornecidas pelo framework para informar o qual nome da tabela que corresponde a cada classe mapeada e anotações de atributos para mapear um atributo da classe ao seu respectivo campo na tabela, além de mapear os atributos identificadores dos objetos aos campos que são chaves primárias e as associações com outras classes. Para abstrair o método de acesso a dados foi utilizado o design pattern repository para cada classe de domínio. Este pattern atua como mediador na comunicação entre as classes de domínio e as classes de acesso a dados, desacoplando as classes de domínio de um método de acesso a dados em especifico (FOWLER, 2003). A utilização deste pattern permitiu a utilização deste mesmo conjunto de classes de domínio durante a construção do aplicativo AppAndroid abordado na próxima subseção. Por motivos de simplicidade os métodos de persistência presentes em cada um dos repositórios são invocados diretamente pelas classes que representam a interface gráfica do aplicativo.

14 17 A Figura 6, demonstra o modelo de classes apenas com as classes de domínio e repositórios do aplicativo AppNanoORM: Figura 6. Diagrama de classes do aplicativo AppNanoORM Softwares utilizados Para o desenvolvimento do AppNanoORM foram utilizados a IDE Eclipse em conjunto ao Android SDK, o plugin AJDT que adiciona o suporte a linguagem AspectJ ao projeto e o próprio framework Nano ORM. 3.3 Método de construção do aplicativo AppAndroid Com o propósito de efetuar uma comparação por meio da extração de métricas entre o AppNanoORM com um outro aplicativo que utilizasse a API padrão do Android, foi desenvolvido uma aplicação semelhante ao AppNanoORM, mas utilizando a API do Android para realizar as operações de persistência. O aplicativo AppAndroid tem a mesma funcionalidade do aplicativo AppNanoORM, um simples cadastro de clientes, produtos e pedidos de produtos efetuados pelos respectivos clientes, sendo a principal diferença entre o aplicativo AppAndroid e o aplicativo AppNanoORM a adição uma camada de acesso a dados criada no AppAndroid que tem por função abstrair o uso da API da plataforma Android e uso de códigos SQL para a realização das operações de persistência no banco de dados.

15 18 Esta camada de acesso a dados foi construída utilizando o design pattern DAO (Data Access Object), que tem por objetivo gerenciar a conexão com uma fonte de dados para obter e armazenar dados ( Core J2EE Patterns - Data Access Object, [S.d.]). A camada de acesso a dados é por sua vez encapsulada por uma camada de repositórios assim como é feito no aplicativo AppNanoORM, objetivando o máximo de semelhança entre os dois aplicativos. A Figura 7, demonstra o modelo de classes apenas com as classes de domínio, repositórios e classes de acesso a dados do aplicativo AppAndroid: Figura 7. Diagrama de classes do aplicativo AppAndroid Softwares utilizados Para o desenvolvimento do AppAndroid foram utilizados apenas a IDE Eclipse em conjunto ao Android SDK. 3.4 Método de extração das Métricas de Software Como métodos para medir a qualidade do código dos dois aplicativos construídos foram extraídos de ambos, as métricas de complexidade ciclomática, linhas de código, número de

16 19 classes e qualidade total, para posteriormente ser realizado um comparativo dos valores obtidos. A complexidade ciclomática, também conhecida como Métrica McCabe, pois foi criada por Thomas J. McCabe avalia o número de caminhos de execução diferentes de um dado programa, a premissa básica é que o nível de aninhamento de laços e comandos de decisão no código tem relação com sua complexidade de execução. Tanto que estudos têm mostrado que códigos com um valor de complexidade ciclomática igual a 11 têm menor probabilidade de serem propensos a falhas (cerca de 28%). Códigos com complexidade ciclomática no valor de 38 possuem uma probabilidade de 50% de estarem propensos a falhas. Já códigos com complexidade ciclomática no valor 74 ou mais possuem altas probabilidades de ocorrerem falhas (BARROS, 2010; KOSCIANSKI; SOARES, 2007). A métrica de linhas de código é a contagem de linhas de código, sendo a medida mais simples para tamanho de um programa. O tamanho de um método pode afetar a facilidade de compreensão, manutenção e reutilização, e geralmente um produto maior envolve trabalho mais complexo (KOSCIANSKI; SOARES, 2007). A métrica de quantidade de classes representa o número de classes que compõem um software e também é utilizada para estimar seu tamanho durante o desenvolvimento. Um sistema grande com muitas classes é mais complexo do que um menor, pois o número de interações entre os objetos é maior, o que reduz a compreensibilidade do sistema, que por sua vez, torna-se mais difícil testar, depurar e manter ( Maven - Metrics, 2002). A escolha destas duas métricas de tamanho de software foi devido à métrica quantidade de classes complementar a métrica de linhas de código, possibilitando uma melhor análise do código dos aplicativos. A métrica qualidade total reúne quatro domínios de medidas (arquitetura, design, código e teste), a fim de calcular a qualidade global e unificada do projeto. A fórmula de arquitetura é composta pelo nível de emaranhamento entre pacotes, o melhor valor seria 0% o que significa que não há referências de pacotes em outros pacotes, e o pior valor seria 100% por indicar que o nível de emaranhamento entre os pacotes está muito alto ( Metric definitions - Sonar - Codehaus, 2011). Em design, a fórmula envolve complexidade ciclomática, acoplamento eferente (mede a quantidade de classes que são referenciadas pela classe atual, isto é, a dependência que uma

17 20 classe tem em relação a outras), falta de coesão de métodos (mede a diferença de métodos em uma classe por instâncias de variáveis ou atributos); resposta por classe (indica a capacidade de resposta que a classe tem ao receber mensagens de outros objetos) e profundidade de herança (número máximo de superclasses posicionadas hierarquicamente acima da classe em questão) (DANTAS, 2008; DUARTE et al., 2006; FORD, 2009). Já a medida de qualidade do código é composta pela densidade de linhas duplicadas, atendimento das regras de convenção do código, documentação das classes e dos métodos públicos. Por fim na fórmula de teste é avaliada a porcentagem de código do sistema que está coberta pelos testes de unidade e a porcentagem de testes executados com sucesso (LAIRD; BRENNAN, 2006). Na composição da métrica de qualidade total não foram utilizados a medida de teste devido aos aplicativos não possuírem testes de unidade e nem a de código, pois ambos os aplicativos não tiveram os códigos documentados, devido ao fato desses fatores influenciarem negativamente a análise desse projeto, uma vez que não foram utilizados. Para realizar a extração das métricas explicadas anteriormente foi utilizado o Sonar que é um software de gerenciamento de qualidade de software. Para seu funcionamento é necessário criar um arquivo XML de configuração na pasta principal dos projetos (AppAndroid e AppNanoORM), neste precisa ser informado os diretórios dos fontes que deseja extrair as métricas, que no caso dos dois aplicativos, os arquivos foram configurados para extrair somente dos pacotes que continham os repositórios, classes de domínio e de classes de acessos a dados Softwares utilizados Foram utilizados os seguintes softwares para extração das métricas, o Sonar para a exibição das métricas de forma gráfica, o plugin Maven para executar a análise do projeto e o plugin Total Quality para adicionar a métrica de qualidade total.

18 21 A Figura 8, exibe a tela do Sonar após a análise do código fonte do projeto AppNanoORM: AppAndroid: Figura 8. Resultados da análise do projeto AppNanoORM A Figura 9, exibe a tela do Sonar após a análise do código fonte do projeto Figura 9. Resultados da análise do projeto AppAndroid

19 22 4. Resultados A seguir são apresentados os resultados obtidos por este trabalho, a iniciar pelo diagrama de classes do framework Nano ORM exibido na Figura 10:

20 Figura 10. Diagrama de classes do framework Nano ORM 23

21 24 A Figura 11 exibe a tela inicial do aplicativo AppNanoORM sendo executado no emulador de dispositivos móveis do Android SDK: Figura 11. Tela inicial do aplicativo AppNanoORM A Figura 12 demonstra a tela de cadastro de pedidos do aplicativo AppNanoORM: Figura 12. Tela de cadastro de pedidos do aplicativo AppNanoORM

22 25 A Figura 13 exibe a tela inicial do aplicativo AppAndroid em execução no emulador de dispositivos móveis do Android SDK: Figura 13. Tela inicial do aplicativo AppAndroid A Figura 14 exibe a Tela de lista de produtos do aplicativo AppAndroid: Figura 14. Tela de lista de produtos do aplicativo AppAndroid

23 26 A Figura 15 demonstra o código necessário para retornar todos os objetos da classe Produto do banco: Figura 15. Código necessário para retornar todos os produtos no aplicativo AppAndroid A Figura 16 demonstra o código necessário para buscar todas as instancias da classe Produto no banco de dados: Figura 16. Código utilizado para retornar todos os produtos no aplicativo AppNanoORM

24 27 A Tabela 3 exibe o comparativo dos resultados da métrica de complexidade ciclomática analisada pela ferramenta Sonar: Tabela 3. Comparativo de complexidade ciclomática Métrica AppAndroid AppNanoORM Porcentagem de redução Complexidade média por método 1,2 1,1 8,3% Complexidade média por classe 5,4 3,7 31,4% Complexidade média por arquivo 5,4 3,7 31,4% Complexidade total ,1% A Tabela 4 exibe o comparativo dos resultados das métricas de linhas de código e quantidade de classes analisadas pela ferramenta Sonar: Tabela 4. Comparativo das métricas analisadas pelo Sonar Métrica AppAndroid AppNanoORM Porcentagem de redução Linhas de Código % Classes % total: Por fim, a Tabela 5 mostra os resultados obtidos da análise da métrica de qualidade Tabela 5. Comparativo da métrica de qualidade total Métrica AppAndroid AppNanoORM Arquitetura (%) 78,9 100 Design (%) 97,7 98,1 Qualidade total (%) 88,3 99,1 5. Discussão Conforme demonstrado na Tabela 3, a complexidade ciclomática total do aplicativo AppNanoORM é 64,1% menor em relação ao aplicativo AppAndroid, esta redução acontece por que o código que realiza as operações de persistência com o framework é mais simples

25 28 que o código que utiliza a API da plataforma Android. Isto aumenta a confiabilidade e manutebilidade do código desenvolvido com o framework. A Tabela 4 demonstra que durante o desenvolvimento do aplicativo AppNanoORM utilizando o framework Nano ORM foram necessárias apenas 332 linhas de código para implementar as classes de domínio e repositórios. Este valor representa 61% menos linhas de código em relação ao aplicativo AppAndroid onde foram necessárias 849 linhas de código para a implementação das mesmas classes além das classes de acesso a dados (DAOs). O número de classes foi reduzido, foram desenvolvidas 9 classes no aplicativo AppNanoORM contra 17 no aplicativo AppAndroid, uma redução total de 47% no número de classes. Nos resultados da análise de qualidade total demonstrados na Tabela 5 o principal ganho obtido foi na área de arquitetura onde o aplicativo AppNanoORM obteve 100% de qualidade 21,1% a mais que o aplicativo AppAndroid que obteve 78,9 de qualidade. Na área de design também houve ganhos, porém modestos, o aplicativo AppNanoORM obteve 98,1% de qualidade enquanto o aplicativo AppAndroid chegou a 97,7%, representando uma melhoria de apenas 0,4%. Acreditamos que este resultado se deve ao fato de ambos os aplicativos terem sido desenvolvidos seguindo boas práticas de modelagem. Com a média dos índices de qualidade da arquitetura e de design obtemos o índice de qualidade total, onde, o aplicativo AppNanoORM obteve 99,1% e o aplicativo AppAndroid conseguiu 88,3% representando um ganho de 10,8% na qualidade total do projeto. Nos resultados demonstrados anteriormente podemos observar como vantagens da utilização do framework o número reduzido de código a ser desenvolvido, pois menos classes são necessárias para acessar o banco de dados. Além disto há o impacto positivo sobre a qualidade do projeto, isto pode ajudar a desenvolver um software mais simples, mais fácil de ser compreendido e de melhor manutenção, pois os desenvolvedores não necessitam escrever código relativo à persistência de dados. Quando usados em conjunto com padrões de projeto, bibliotecas de classes, e componentes, os frameworks de aplicações orientadas a objetos podem aumentar significativamente a qualidade do software e reduzir o esforço do desenvolvimento (FAYAD; SCHMIDT, 1997).

26 29 No caso do framework Nano ORM a necessidade de conhecimento da linguagem SQL é reduzida já que seu uso é abstraído pelo framework, isto auxilia a produtividade do desenvolvedor, pois menos código é necessário para a persistência de dados devido ao framework Nano ORM trabalhar em um nível de abstração mais alto que a API padrão da plataforma Android. 6. Conclusão Neste trabalho desenvolvemos um framework de mapeamento objeto relacional para a plataforma Android. O framework chama-se Nano ORM e realiza a persistência de objetos no banco de dados relacional SQLite presente na plataforma Android. O conjunto de funcionalidades desenvolvidas para o framework é o seguinte: realização das operações básicas de persistência de objetos (Inserção, busca por identificador único, retonar todas as instâncias de uma classe, atualização e remoção); um conjunto de anotações para o mapeamento objeto relacional; suporte a carga de objetos sob demanda (Lazy Loading) e por fim, suporte a operações de persistência de objetos em cascata. Desenvolvemos um simples aplicativo demo que realiza a persistência de obejtos, utilizando a API padrão da plataforma Android, este aplicativo chama-se AppAndroid. Também desenvolvemos outro simples aplicativo demo que realiza a persistência de objetos, utilizando o framework Nano ORM desenvolvido neste trabalho, o nome dado para este aplicativo é AppNanoORM. Extraímos e comparamos métricas de software dos aplicativos AppAndroid e AppNanoORM. Uma deficiência do framework Nano ORM é dependência de mais de uma linguagem de programação. Para a utilização do Nano ORM é necessário a utilização do compilador da linguagem AspectJ para que funcionalidades como Lazy Loading, operações de persistência em cascata e gerenciamento de relacionamentos muitos-para-muitos funcionem corretamente. Isto força o desenvolvedor que utilizar o framework tenha em seu ambiente de desenvolvimento o suporte a linguagem AspectJ mesmo que ela não seja utilizada pelo desenvolvedor em seu projeto. O framework desenvolvido neste trabalho pode ser utilizado em diversos tipos de programas para a plataforma Android que utilizem persistência, por exemplo, coletores de

27 30 dados, jogos entre outros. Acreditamos que a utilização do Nano ORM pode também auxiliar os desenvolvedores dando a eles uma maior produtividade e contribuir para o desenvolvimento softwares de maior qualidade. 7. Trabalhos futuros Para a continuidade deste trabalho, propomos o desenvolvimento das seguintes funcionalidades para o framework: uma rotina de geração do esquema do banco de dados a partir da configuração das classes mapeadas; uma linguagem de consulta orientada a objetos baseada na técnica de DSL (Domain Specific Language) chamada NQL (Nano ORM Query Language); suporte a técnica de carga ansiosa de objetos (Eager Loading); e por fim a adição do tipo BLOB aos tipos suportados no mapeamento realizado pelo framework. Referências AMBLER, S. W. The Design of a Robust Persistence Layer For Relational Databases.. [S.l: s.n.]. Disponível em: < Acesso em: 5 dez , 21 jun 2005 AMBLER, S. W. Best Practices for Retrieving Objects from Relational Databases. Disponível em: < Acesso em: 14 maio BARROS, B. Evoluindo o design e arquitetura através das métricas do Sonar. MundoJ, n. 43, set Core J2EE Patterns - Data Access Object. Disponível em: < Acesso em: 23 maio DANTAS, M. M. M. MÉTRICAS PARA ACOPLAMENTO E COESÃO EM SISTEMAS ORIETADOS A OBJETOS EM UM AMBIENTE DE VISUALIZAÇÃO DE SOFTWARE.. [S.l: s.n.]. Disponível em: < es.pdf>. Acesso em: 21 maio , 2008 Datatypes In SQLite Version 3. Disponível em: < Acesso em: 24 maio DUARTE, A. S.; SANTOS, D. F. DOS; ARAÚJO, M. A. P. UMA FERRAMENTA DE APOIO AO TESTE DE SOFTWARE ORIENTADO A OBJETOS ATRAVÉS DA COLETA DE MÉTRICAS DE COMPLEXIDADE. Cadernos de Estudos e Pesquisas, n. 23, FAYAD, M. E.; SCHMIDT, D. C. Object-oriented Application frameworks. Communications of the ACM, v. 40, n. 10, out FORD, N. Arquitetura Evolucionária e Design Emergente: O design emergente pelas métricas. CT316. Disponível em: < Acesso em: 20 maio

28 31 FOWLER, M. Patterns of enterprise application architecture. [S.l.]: Addison-Wesley, GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design patterns: elements of reusable object-oriented software. [S.l.]: Addison-Wesley, Gartner. Gartner Says 428 Million Mobile Communication Devices Sold Worldwide in First Quarter 2011, a 19 Percent Increase Year-on-Year. Disponível em: < Acesso em: 20 maio History - Hibernate - JBoss Community. Disponível em: < Acesso em: 29 maio KOSCIANSKI, A.; SOARES, M. DOS S. Qualidade de software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. 2. ed. [S.l.]: Novatec Editora, LAIRD, L. M.; BRENNAN, M. C. Software measurement and estimation: a practical approach. [S.l.]: John Wiley and Sons, LECHETA, R. R. GOOGLE ANDROID - APRENDA A CRIAR APLICAÇOES PARA: DISPOSITIVOS MOVEIS COM O ANDROID SDK. 2. ed. [S.l.]: NOVATEC, Maven - Metrics. Disponível em: < Acesso em: 21 maio Metric definitions - Sonar - Codehaus. Disponível em: < Acesso em: 10 maio MILES, R. Lazy Loading with Aspects - O Reilly Media. Disponível em: < Acesso em: 22 fev MOTA, L. C. Framework - Definição Demoiselle. Disponível em: < Acesso em: 24 nov PEREIRA, L. C. O.; SILVA, M. L. D. ANDROID PARA DESENVOLVEDORES. [S.l.]: Brasport, PRESSMAN, R. S. ENGENHARIA DE SOFTWARE. 6. ed. [S.l.]: Mcgraw Hill - Artmed, REZENDE, D. A. Engenharia de software e sistemas de informação. 3. ed. [S.l.]: Brasport, SILVEIRA, D. G.; ALVES, F. F.; FERREIRA, L. S.; SOUZA, R. R. G. E. Bancos de dados orientados a objetos e objeto-relacionais.. [S.l: s.n.]. Disponível em: < O_e_OR.pdf>. Acesso em: 4 dez , 5 dez 2006 SMITH, D. A Brief History of TopLink. Disponível em: < Acesso em: 19 maio Software Metrics. Disponível em: < Acesso em: 28 maio

29 WINCK, D. V.; JUNIOR, V. G. AspectJ programação orientada a aspectos com Java. 1. ed. [S.l.]: NOVATEC,

30 33 Apêndice A Casos de uso Diagrama de casos de uso do framework Nano ORM Caso de uso 01: Obter gerenciador de objetos Descrição breve Este caso de uso contempla a obtenção do gerenciador de objetos que permitirá a manipulação de objetos no banco de dados. Atores Aplicativo utilizador. Fluxo básico de eventos Ator 1. Informa a configuração do banco de dados. Framework 2. Retorna o gerenciador de objetos.

31 34 Caso de uso 02: Inserir objeto Descrição breve Este caso de uso contempla a inserção de um objeto no banco de dados. Atores Aplicativo Utilizador. Pré-condições Obter gerenciador de objetos. Fluxo básico de eventos Ator 1. Informa o objeto a ser persistido Framework 2. Persiste o objeto no banco. Caso de uso 03: Retornar objeto Descrição breve Este caso de uso contempla o retorno de um objeto da classe que representa uma determinada tabela que contenha o valor do campo que seja chave primária igual ao valor do id informado. Atores Aplicativo utilizador. Pré-condições Obter gerenciador de objetos. Fluxo básico de eventos Ator 1. Informa a classe que terá o objeto retornado e o id. 2. Retorna o objeto. Framework

32 35 Caso de uso 04: Retornar todos objetos Descrição breve Este caso de uso contempla o retorno de todos os objetos da classe que representa uma determinada tabela no banco de dados. Atores Aplicativo utilizador. Pré-condições Retorno de um objeto ou retorno de todos os objetos. Fluxo básico de eventos Ator 1. Informa a classe que terá todos os objetos retornados Framework 2. Retorna uma lista com todos os objetos. Caso de uso 05: Alterar objeto Descrição breve Este caso de uso contempla a alteração de um objeto no banco de dados. Atores Aplicativo utilizador. Pré-condições Retorno de um objeto ou retorno de todos os objetos. Fluxo básico de eventos Ator 1. Informa o objeto a ser alterado. Framework 2. Altera o objeto no banco.

33 36 Caso de uso 06: Remover objeto Descrição breve Este caso de uso contempla a remoção de um objeto no banco de dados. Atores Aplicativo utilizador. Pré-condições Obter o gerenciador de objetos. Fluxo básico de eventos Ator 1. Informa o objeto a ser removido Framework 2. Remove o objeto no banco.

34 Apêndice B Diagrama de classes 37

35 Apêndice C Diagramas de sequência 38 Obter gerenciador de objetos

36 Inserir objeto 39

37 Alterar objeto 40

38 Remover objeto 41

39 Retornar objeto 42

40 Retornar todos objetos 43

41 44 Apêndice D Diagramas de pacotes Diagrama de pacotes do framework Nano ORM Diagrama de pacotes detalhado do framework Nano ORM