Programação orientada a Aspectos

Preview:

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 Presentation

Citation preview

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

Recommended