Estudo e Comparação do Paradigma Orientado a Objetos com o Paradigma Orientado a Aspectos, Teses (TCC) de Computação Aplicada

Baixe Estudo e Comparação do Paradigma Orientado a Objetos com o Paradigma Orientado a Aspectos e outras Teses (TCC) em PDF para Computação Aplicada, somente na Docsity!

UNIVERSIDADE PAULISTA

Jhonatan do Nascimento Yamane Rodrigo Ribeiro de Souza

Estudo e Comparação do Paradigma Orientado a Objetos com

o Paradigma Orientado a Aspectos

Bauru 2011

Jhonatan do Nascimento Yamane Rodrigo Ribeiro de Souza

Estudo e Comparação do Paradigma Orientado a Objetos com

o Paradigma Orientado a Aspectos

Trabalho de Conclusão de Curso apresentado como requisito para obtenção do título de bacharel em Ciência da Computação da Universidade Paulista.

Professora Orientadora: Ms. Angela Teresa Rochetti

Bauru 2011

Jhonatan do Nascimento Yamane Rodrigo Ribeiro de Souza

Estudo e Comparação do Paradigma Orientado a Objetos com

o Paradigma Orientado a Aspectos

Trabalho de Conclusão de Curso apresentado como requisito para obtenção do título de bacharel em Ciência da Computação da Universidade Paulista.

Aprovado em:

BANCA EXAMINADORA _____________________ //___ Prof. Ms. Alex Mauricio Mazo Universidade Paulista – UNIP _____________________ //___ Prof. Ms. Angela Teresa Rochetti Universidade Paulista – UNIP _____________________ //___ Prof. Ms. Célio Ricardo Castelano Universidade Paulista UNIP _____________________ //___ Prof. André Luís de Oliveira IFSP – Campus Avaré

DEDICATÓRIA

Aos meus pais, pelo apoio, incentivo e dedicação para que sempre pudesse alcançar meus objetivos. À minha namorada, Flávia Carina Peretti, pela paciência, compreensão, amor e carinho nos momentos em que mais precisei. Rodrigo Ribeiro de Souza

Aos meus pais, que me propiciaram uma vida digna onde eu pudesse crescer, acreditando que tudo é possível, desde que sejamos honestos, íntegros de caráter e tendo a convicção de que desistir nunca seja uma ação contínua em nossas vidas; que sonhar e concretizar os sonhos só dependem da nossa vontade. Aos meus irmãos, Douglas e Willy, que sempre estiveram torcendo por mim. E uma dedicação especial à minha tia Elena Yamane e minha bathan (avó) Chieko Yamane, por me ajudar e acreditar no meu potencial ao longo desses quatros anos. Jhonatan do Nascimento Yamane

"Tudo o que um sonho precisa para ser realizado é alguém que acredite que ele possa ser realizado". (Roberto Shinyashiki)

RESUMO

O desenvolvimento de software baseado na Programação Orientada a Objetos (POO) trouxe muitos benefícios aos desenvolvedores de software. No entanto, com o aumento da complexidade dos sistemas, nem todas as propostas que este paradigma se propunha a cumprir foram atendidas. O objetivo principal da evolução dos paradigmas de programação é facilitar o desenvolvimento de softwares , tratando ainda de problemas antigos deixados pelos paradigmas anteriores. Nesse contexto, surge então a Programação Orientada a Aspectos (POA), o qual aparece para trabalhar em conjunto com a POO para tornar o processo de desenvolvimento de software mais simples e eficiente. Este trabalho apresenta um estudo comparativo entre o Paradigma Orientado a Objetos com o Paradigma Orientado a Aspectos. Busca-se através do desenvolvimento de um sistema nos dois paradigmas, demonstrar os prós e os contras provenientes do uso da POA no desenvolvimento de software com uma melhor organização no código e na regra de negócio.

Palavras Chaves : Programação Orientada a Aspectos; Programação Orientada a Objetos; Paradigmas de Programação; Separação de Interesses; Regras de Negócio.

LISTA DE FIGURAS

SUMÁRIO

• (CASTELANO, 2009) Figura 2.4.1.1 – Representação de objetos, propriedades e comportamentos
• Figura 2.4.1.2 – Exemplos de diagrama UML (adaptado CASTELANO, 2009)
• Figura 2.4.1.3 – Apresentação dos métodos da classe Conta Corrente
• Figura 2.4.2.1 – Exemplo de herança (adaptado CASTELANO, 2009)
• Figura 2.4.3.1 – Exemplo de polimorfismo
• Figura 2.4.4.1 – Exemplo de encapsulamento (CASTELANO, 2009)
• Figura 2.4.5.1.1 – Desenvolvimento da classe Ponto (RESENDE e SILVA, 2005)
• Figura 2.4.5.1.2 – Desenvolvimento da classe Reta (RESENDE e SILVA, 2005).....
• Figura 2.4.5.2.1 – Exemplo de repetição de linhas código para chamar métodos
• Figura 2.5.2.1 – Exemplo de um pointcut
• Figura 2.5.2.2 – Ponto de atuação utilizando o coringa “+”
• Figura 2.5.3.1 – Exemplo de adendo
• Figura 2.5.7.1 – Ambiente de desenvolvimento Eclipse
• Figura 2.5.7.2 – Apresentação do adendo correspondente ao método.....................
• Figura 4.1.1 – Projetos desenvolvidos no Eclipse
• Figura 4.1.2 – Desenvolvimento do projeto utilizando MVC
• Figura 4.2.1 – Tela principal do sistema orientado a objetos
• Figura 4.2.2 – Exibição dos itens do menu Cadastros
• Figura 4.2.3 – Exibição da tela do Cadastro de Clientes
• Figura 4.2.4 – Exibição da tela Cadastro de Contas
• Figura 4.2.5 – Operações realizadas no Caixa Eletrônico
• Figura 4.2.6 – Exibição da tela de Depósitos
• Figura 4.2.7 – Apresentação do método depósito da classe Caixa...........................
• Figura 4.2.8 – Apresentação da tela de Saques
• Figura 4.2.9 – Apresentação do método saque da classe Caixa
• Figura 4.2.10 – Apresentação da tela de Transferência de valores
• Figura 4.2.11 – Apresentação do método Transferência da classe Caixa
• Figura 4.2.12 – Apresentação da tela de Saldo Bancário
• Figura 4.2.13 – Apresentação do saldo atual da conta do cliente
• Figura 4.2.14 – Exemplo do arquivo LOG.txt
• Figura 4.2.15 – Chamada ao método log da classe Logger
• Figura 4.3.1 – Organização do projeto POA..............................................................
• Figura 4.3.2 – Apresentação da primeira parte do aspecto Condicoes.aj
• Figura 4.3.3 – Apresentação da segunda parte do aspecto Condicoes.aj
• Figura 4.3.4 – Apresentação do aspecto Politicas.aj
• Figura 4.3.5 – Teste 1: aspecto Politicas.aj
• Figura 4.3.6 – Teste 2: aspecto Politicas.aj
• Figura 4.3.7 – Apresentação do aspecto TraceLogger
• Figura 4.4.1 – Implementação utilizando POO
• Figura 4.4.2 – Implementação utilizando POA
• 1 INTRODUÇÃO
• 1.1 Objetivos Gerais e Específicos
• 1.2 Justificativa
• 1.3 Problema e Hipótese
• 2 PRESSUPOSTOS TEÓRICOS
• 2.1 Software e Evolução do Software
• 2.2 Linguagem de Programação............................................................................
• 2.3 Programação Estruturada
• 2.4 Programação Orientada a Objetos
• 2.4.1 Classes, Objetos, Atributos e Métodos
• 2.4.2 Herança.....................................................................................................
• 2.4.3 Polimorfismo
• 2.4.4 Encapsulamento........................................................................................
• 2.4.5 Problemas da Programação Orientada a Objetos
• 2.4.5.1 Entrelaçamento de Código ( Tangled Code )
• 2.4.5.2 Espalhamento de Código ( Spread Code )
• 2.5 Programação Orientada a Aspectos
• 2.5.1 Pontos de Junção ( JoinPoints )
• 2.5.2 Pontos de Atuação ( PointCuts )
• 2.5.3 Adendos ( Advices )
• 2.5.4 Aspectos
• 2.5.5 Desenvolvendo o Software
• 2.5.6 Benefícios do Paradigma Orientado a Aspectos
• 2.5.7 Problemas do Paradigma Orientado a Aspectos
• 3 MATERIAIS E MÉTODOS
• 3.1 Cronograma
• 4 DESENVOLVIMENTO
• 4.1 Implementação dos Projetos
• 4.2 Desenvolvimento Orientado a Objetos
• 4.3 Desenvolvimento Orientado a Aspectos
• 4.4 Comparação entre os projetos POO e POA
• 5 RESULTADOS
• REFERÊNCIAS

Estes procedimentos eram armazenados em arquivos separados e podiam ser reutilizados através de uma ou múltiplas chamadas no programa principal. Surgia assim o conceito de bibliotecas. A comercialização dessas bibliotecas foi um passo subsequente. Porém, a complexidade dos sistemas continua crescendo e tornou esse tipo de reutilização ultrapassado (DEITEL et al., 2003). A Programação Orientada a Objetos (POO) surgiu devido à insatisfação dos programadores com as técnicas até então desenvolvidas. Com isso, os sistemas tornaram-se mais bem organizados, pois nestes o mundo passou a ser modelado através de classes e objetos. Buscando simular uma perspectiva de mundo real, a POO buscou agrupar um conjunto de objetos em classes e um conjunto de atributos em objetos. Sendo assim, a orientação a objetos melhorou a compreensão das soluções apresentadas (CHAGAS e OLIVEIRA, 2009). Dentre os diversos benefícios da utilização da POO, se comparados com a programação estruturada, pode-se citar: reuso; modularização; simplificação; redução dos custos de manutenção (GOETTEN et al., 2006). Apesar desses avanços, o aumento da complexidade inseriu novos problemas que a POO é incapaz de resolver. “Desenvolver um sistema é tão complexo que se tornou impossível exigir a um funcionário que domine todas as fases de desenvolvimento” (RESENDE e SILVA, 2005). Esta evolução da indústria de software tem forçado a divisão das áreas de interesses de desenvolvimento de software em partes independentes. Deseja-se ter grupos distintos e especializados em preocupações como: persistência, distribuição, segurança, interface, dentre outras, visando desenvolver soluções personalizadas a cada problema. No final, integram-se as partes, os componentes, para compor o sistema principal (RESENDE e SILVA, 2005). Com o aumento da complexidade, advinda da evolução dos paradigmas de programação, a POO é responsável por gerar outros dois problemas: o Entrelaçamento de Código e o Espalhamento de Código. O primeiro trata da inserção de chamadas de métodos que possivelmente se encontram em uma classe diferente da qual foram invocados. O segundo diz respeito à repetição de código nas diversas classes do sistema, gerando sérios problemas de manutenibilidade (CHAGAS e OLIVEIRA, 2009). Esses dois problemas serão melhor detalhados no capítulo 2.

Buscando solucionar os problemas deixados pela POO, surgiu a Programação Orientada a Aspectos (POA). Esse paradigma tem como objetivo separar os níveis de preocupação durante a fase de desenvolvimento de software. Assim, problemas relacionados à segurança, persistência de dados, auditoria, registros de logs e tratamento de exceções, poderiam ser pensados separadamente sem se preocupar com as demais partes. À medida que fossem integradas as interações, seria adicionado um novo nível de preocupação sem ser necessário alterar o que já está feito. Por isso, a POA ganhou força na comunidade científica e tecnológica como a provável solução para a lacuna deixada pela POO, com certa eficácia na mudança de pensamento e do conhecimento na área de desenvolvimento de sistemas. Muitas empresas têm incorporado rapidamente a POA por não exigir nenhuma adaptação de seus equipamentos e ser de fácil compreensão aos desenvolvedores e testadores de software (BORGES et al., 2008). IBM e Microsoft são exemplos de empresas que utilizam e investem no desenvolvimento da POA. A POA introduziu um novo conceito, denominado aspecto, que corresponde a uma estrutura apropriada para a modularização e separação de requisitos transversais. A principal linguagem de programação para POA e a mais utilizada é o AspectJ, que é atualmente mantido pela Eclipse Foundation (ANDRADE, 2004). Nesse contexto, entende-se então, que a POA não surgiu no mercado para excluir a POO, e sim para complementá-la. Visto que, uma parte do código fica na definição dos aspectos, e por estarem em uma única unidade, alterações são muito mais simples, não sendo preciso reescrever inúmeras classes. Neste projeto, o principal objetivo é o estudo e comparação do Paradigma Orientado a Objetos com o Paradigma Orientado a Aspectos, apresentando possíveis soluções aos problemas referentes ao entrelaçamento e espalhamento de código gerado pelo uso do Paradigma Orientado a Objetos. O próximo capítulo aborda a teoria sobre o assunto proposto neste trabalho. O capítulo 3 descreve os métodos e ferramentas necessárias para o desenvolvimento. O capítulo 4 apresenta o desenvolvimento e comparação entre POO e POA. O capítulo 5 apresenta os resultados obtidos com o desenvolvimento deste trabalho.

1.3 Problema e Hipótese

 Como realizar o entrelaçamento de código necessário para integrar os componentes ao software final, de forma simples, limpa e eficiente?

Utilizando a Programação Orientada a Aspectos.

 Como possibilitar a inserção de uma nova funcionalidade no software , sem alterar o código fonte do módulo?

Utilizando aspectos é possível alterar o fluxo de execução do sistema, para inserir uma nova funcionalidade sem alterar o código fonte do módulo ou componente alterado.

 Como obter uma melhor produtividade e manutenibilidade do software , em relação ao espalhamento de código necessário para atender um determinado requisito de software?

Através do paradigma orientado a aspectos.

2 PRESSUPOSTOS TEÓRICOS

Esse capítulo aborda os conceitos teóricos necessários ao entendimento do tema deste trabalho.

2.1 Software e Evolução do Software

Quando se fala sobre o termo software , consequentemente, pode ocorrer a associação de software com programas de computador. No entanto, segundo a concepção de Sommerville (2003, p.5), “ software não é apenas o programa, mas também toda a documentação associada e os dados de configuração necessários para fazer com que esses programas operem corretamente”. De forma geral, normalmente todo software contém uma documentação do sistema o qual descreve como o mesmo está estruturado (desenvolvido) e também uma documentação do usuário o qual este tem o papel de orientar e/ou exemplificar como o software deve ser utilizado. Softwares estão constantemente em evolução, independentemente da complexidade e tamanho da aplicação (PRESSMAN, 2006). Uma característica marcante dos softwares é a flexibilidade a mudanças (manutenção do software ), onde estas podem ser realizadas em qualquer instante, isto é, durante ou após o desenvolvimento do software. Normalmente o software poderá passar por mudanças depois que for entregue ao cliente, visto que este pode detectar erros, necessitar de adaptações devido à migração para outro sistema operacional, ou até mesmo para atender uma determinada necessidade de negócio, solicitar o acréscimo de uma funcionalidade específica. Segundo Pressman (2006, p.9), a manutenção do software “ocorre quando erros são corrigidos, quando o software é adaptado a um novo ambiente, quando o cliente solicita novas características ou funções e quando a aplicação é “reengenheirada” para fornecer benefícios em um contexto moderno”. É importante ressaltar que, frequentemente, os custos referentes à manutenção do software são bem maiores quando comparados aos custos de