31
Programação orientada a Aspectos Radio Manager System

Programação orientada a Aspectos

  • Upload
    shiloh

  • View
    31

  • Download
    0

Embed Size (px)

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

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