programação orientada a aspectos
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
Programação orientada a AspectosRadio 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•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
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
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
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
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.
Concerns identificados
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
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
Código relacionado
Código relacionado
Métricas
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
Gráfico de Clones
Código clonado: exemplo (1/2)
Código clonado: exemplo (2/2)
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
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
Concern Fachada •Fachada disponibiliza uma interface para
uma grande quantidade de funcionalidades do programa
•Muito espalhamento das classes sobre ela
•Durante refactoring foi descartado
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”
Concerns atualizados•Com a remoção dos Concerns
mencionados:
Clones (Exemplo 1/4)•Método duplicado: Classes “Grade” e
“Tocada”
Clones (Exemplo 2/4)•Resolvido com Refactoring: Criação da
Classe “DateTimeToString”
Clones(Exemplo 3/4)
•Após Refactoring:▫Método converte realocado para classe CPF
Clones(Exemplo 4/4)
Clones- Gráfico
Aspecto transacional
Aspecto de tratamento de exceção
Pós-Refactoring•Métricas
•Clones (Quantificação)▫Total em pares de clones restantes: 185
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