Transcript
Page 1: Programação orientada a Aspectos

Programação orientada a AspectosRadio Manager System

Page 2: Programação orientada a Aspectos

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

Page 3: Programação orientada a Aspectos

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

Page 4: Programação orientada a Aspectos

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

Page 5: Programação orientada a Aspectos

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

Page 6: Programação orientada a Aspectos

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

Page 7: Programação orientada a Aspectos

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.

Page 8: Programação orientada a Aspectos

Concerns identificados

Page 9: Programação orientada a Aspectos

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

Page 10: Programação orientada a Aspectos

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

Page 11: Programação orientada a Aspectos

Código relacionado

Page 12: Programação orientada a Aspectos

Código relacionado

Page 13: Programação orientada a Aspectos

Métricas

Page 14: Programação orientada a Aspectos

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

Page 15: Programação orientada a Aspectos

Gráfico de Clones

Page 16: Programação orientada a Aspectos

Código clonado: exemplo (1/2)

Page 17: Programação orientada a Aspectos

Código clonado: exemplo (2/2)

Page 18: Programação orientada a Aspectos

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

Page 19: Programação orientada a Aspectos

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

Page 20: Programação orientada a Aspectos

Concern Fachada •Fachada disponibiliza uma interface para

uma grande quantidade de funcionalidades do programa

•Muito espalhamento das classes sobre ela

•Durante refactoring foi descartado

Page 21: Programação orientada a Aspectos

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”

Page 22: Programação orientada a Aspectos

Concerns atualizados•Com a remoção dos Concerns

mencionados:

Page 23: Programação orientada a Aspectos

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

“Tocada”

Page 24: Programação orientada a Aspectos

Clones (Exemplo 2/4)•Resolvido com Refactoring: Criação da

Classe “DateTimeToString”

Page 25: Programação orientada a Aspectos

Clones(Exemplo 3/4)

Page 26: Programação orientada a Aspectos

•Após Refactoring:▫Método converte realocado para classe CPF

Clones(Exemplo 4/4)

Page 27: Programação orientada a Aspectos

Clones- Gráfico

Page 28: Programação orientada a Aspectos

Aspecto transacional

Page 29: Programação orientada a Aspectos

Aspecto de tratamento de exceção

Page 30: Programação orientada a Aspectos

Pós-Refactoring•Métricas

•Clones (Quantificação)▫Total em pares de clones restantes: 185

Page 31: Programação orientada a Aspectos

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


Top Related