1 / 31

Programação orientada a Aspectos

Programação orientada a Aspectos. Radio Manager System. Equipe. Caio César Neves de Oliveira Felipe Soares Queiroga João da Rocha Pascoal Neto João Paulo Sabino de Moraes Mário Barbosa de Araújo Júnior Tiago Farias Silva. Radio Manager System - RMS.

shiloh
Download Presentation

Programação orientada a Aspectos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Programação orientada a Aspectos Radio Manager System

  2. Equipe • Caio César Neves de Oliveira • Felipe Soares Queiroga • João da Rocha Pascoal Neto • João Paulo Sabino de Moraes • Mário Barbosa de Araújo Júnior • Tiago Farias Silva

  3. Radio Manager System - RMS • Sistema de organização e gerenciamento de estações de rádio FM • Visa facilitar o trabalho da equipe organizadora de eventos da estação • Oferece suporte a decisões relativas à programação da rádio FM • Geração de Relatórios • Estatísticas • Dados pessoais e financeiros

  4. Principais funcionalidades • Gerenciar funcionários • Gerenciar programas da rádio • Gerenciar músicas • Gerar relatório financeiro • Gerar relatório de RH • Número de classes: 68 • Número de linhas de código: 15.034

  5. Concerns • Fachada • Para a classe Fachada e Interfaces • Interface Gráfica • Direcionado para a classe da GUI • Transação • Espalhado em diversas classes que realizam transação • Negócio • Espalhado em todas as classes de negócio

  6. Concerns • Controle de Negócio • Espalhado nas classes que controlam funcionalidades de outras classes • Exceção • Relacionado às classes de Exceção do sistema • Dados • Direcionado às classes que se comunicam com classes de transação • Debug • Relacionado com comandos de print para debug

  7. Concerns • Foram considerados concerns, requisitos satisfatórios ao objetivo geral do nosso sistema. • Interface, exceção, negócios e dados são necessários para estabelecer a base do sistema. • Os concerns 'transação' e 'controle de negócios' são úteis ao banco de dados e às técnicas de manipulação de dados respectivamente.

  8. Concerns identificados

  9. Problemas surgidos e dúvidas quanto aos concerns • Houve dúvida quanto a criação do concern Fachada. • Impossibilidade de criação do concern Eventos • Os concerns possuem apenas o nome dos métodos ou os atributos das classes • Deficiências do ConcernTagger

  10. Atividade de atribuição de concerns • 10.222 linhas de códigos marcadas • Tempo total levado para marcar: aproximadamente 8h • Dificuldade: apenas um integrante faz a marcação, por não possuir uma base de dados compartilhada

  11. Código relacionado

  12. Código relacionado

  13. Métricas

  14. Clones (Quantificação) • Interface Gráfica – 219 pares de clones • Exceção – 4 pares de clones • Transação – 28 pares de clones • Controle de Negócios – 1 par de clones • Negócios – 1 par de clones • Debug – 3 Pares de clones • Total: 256 pares de clones

  15. Gráfico de Clones

  16. Código clonado: exemplo (1/2)

  17. Código clonado: exemplo (2/2)

  18. Conclusões (Partes 1 e 2) • As métricas ajudaram a identificar os concerns com maiores focos de crosscutting • Foram geradas pelo framework ConcernTagger e tudo depende se identificarmos corretamente os concerns pra cada atributo e método • Negócio e Transação são exemplo de cross-cutting concerns • A ferramenta GemX nos ajudou a identificar trechos de código clonado

  19. Refactoring do Código • Discutido o propósito de alguns Concerns • Resultado: Concerns Fachada, Dados, Controle de Negócios removidos • Alguns clones removidos • Aspectos adicionados em Transação • Tratamento de exceções removidos dos códigos de debbug da aplicação por Aspectos

  20. Concern Fachada • Fachada disponibiliza uma interface para uma grande quantidade de funcionalidades do programa • Muito espalhamento das classes sobre ela • Durante refactoring foi descartado

  21. Concern Dados • Manipulava dados do programa • Estávamos tratando Dados como Negócios • Incorporada ao Concern Negócios após uma revisão do código • O mesmo aconteceu a “Controle de Negócios”

  22. Concerns atualizados • Com a remoção dos Concerns mencionados:

  23. Clones (Exemplo 1/4) • Método duplicado: Classes “Grade” e “Tocada”

  24. Clones (Exemplo 2/4) • Resolvido com Refactoring: Criação da Classe “DateTimeToString”

  25. Clones(Exemplo 3/4)

  26. Clones(Exemplo 4/4) • Após Refactoring: • Método converte realocado para classe CPF

  27. Clones- Gráfico

  28. Aspecto transacional

  29. Aspecto de tratamento de exceção

  30. Pós-Refactoring • Métricas • Clones (Quantificação) • Total em pares de clones restantes: 185

  31. Conclusão • Nem sempre modularizar ao máximo os concerns ajuda o refactoring • Espalhamento diminuiu insignificantemente • Muito código replicado foi removido • Concern Difusion Over Components diminuiu razoavelmente • Concerns foram remodelados, excluídos e incorporados de acordo com a necessidade • Aspectos foram inseridos no código, melhorando sua modularidade e diminuindo clones

More Related