A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Aluno: Mário Monteiro Orientador: Sérgio Soares 1.

Apresentações semelhantes


Apresentação em tema: "Aluno: Mário Monteiro Orientador: Sérgio Soares 1."— Transcrição da apresentação:

1 Aluno: Mário Monteiro Orientador: Sérgio Soares 1

2 MOTIVAÇÃO Estudos empíricos são essenciais para o avanço científico. Há uma demanda cada vez maior por sistemas mais complexos. POA e Arquitetura em camadas prometem benefícios fundamentais para Engenharia de Software. 2

3 Arquitetura em Camadas Vantagens: Facilidade de Manutenção e Entendimento Melhora de Coesão e Acoplamento Auxiliar o reúso e facilidade de estender o sistema. Desvantagens: Aumento da troca de mensagens Pode ocasionar ineficiência 3

4 Programação Orientada a Aspectos Benefícios são bastante promissores Objetivo de suprimir problemas da POO Disciplina ainda recente, porém em grande crescimento. 4

5 POA e Arquitetura em Camadas Existem poucos estudos que envolvem esses dois temas. Falta de avaliação de violações de camadas em sistemas AO. Carência de estudos de violações de camadas em evolução de software. 5

6 ESTUDO EMPÍRICO Objetivos: Avaliar impactos da POA com relação a violações de camadas. Avaliar aderência à arquitetura em camadas em um ambiente de evolução de software. Realizar análises quantitativas e qualitativas. 6

7 ESTUDO EMPÍRICO Fases: Seleção da Aplicação Documentação e classificação dos módulos. Desenvolvimento de um Framework para coleta das métricas. Análises e Extensão das métricas. Avaliação quantitativa e qualitativa dos resultados. 7

8 ESTUDO EMPÍRICO Seleção da Aplicação: Health Watcher Já foi utilizado em outros estudos empíricos da área Possui duas versões de implementação: OO (Java) e AO (AspectJ). Nove cenários de evolução. Vários interesses transversais implementados. 8

9 ESTUDO EMPÍRICO Cenários: 2- Permitir o uso de múltiplos servlets a fim de melhorar a estensibilidade. 3 - Garantir que o estado de uma queixa seja atualizado quando bloqueado, a fim de protegê-lo de múltiplas atualizações. 4 – Encapsular operações de atualização a fim de melhorar a manutenabilidade através de uso de práticas comuns em engenharia de software. 9

10 ESTUDO EMPÍRICO Cenários: 5 – Aperfeiçoar o encapsulamento do requisito de distribuição, a fim de melhorar seu reúso e customização. 6 – Aperfeiçoar o mecanismo de persistência para melhorar seu reúso e estensibilidade. 7 – Remover as dependências de objetos do tipo request e response, a fim de facilitar o processo de adição de novos componentes na camada GUI. 10

11 ESTUDO EMPÍRICO Cenários: 8 – Tornar o requisito de distribuição mais fácil de reutilizar e de estender. 9 – Adição de novo requisito funcional para permitir consultas com mais tipos de dados. 10 – Modularização do tratamento de exceção e inclusão de recuperação de erros mais efetivos nos tratamentos atuais. 11

12 ESTUDO EMPÍRICO Documentação e Classificação dos Módulos: A princípio, existem quatro camadas: GUI Comunicação Negócio Gerência de Dados Problemas com classificação de alguns módulos: Elementos Reusáveis Aspectos 12

13 ESTUDO EMPÍRICO Camadas do HW 13

14 ESTUDO EMPÍRICO Violações de camadas 14

15 APRESENTAÇÃO DO FRAMEWORK Desenvolvimento de um Framework para coleta das métricas. Identificação das Dependências Coleta das métricas 15

16 16

17 APRESENTAÇÃO DO FRAMEWORK Identificação das Dependências. Módulo A depende de B da seguinte forma: A invoca método de B, ou A instancia B A lê atributo de B A atribui um valor a um atributo de B B é uma exceção e A trata B. 17

18 APRESENTAÇÃO DO FRAMEWORK Identificação das Dependências. Abordagem utilizada através de aspectos da seguinte forma: 18

19 19

20 APRESENTAÇÃO DO FRAMEWORK Coleta das Métricas Cada dependência é consultada no grafo. As camadas dos módulos são consultados para determinar violações. Os ciclos são determinados a partir de componentes fortes no grafo. 20

21 AVALIAÇÃO DOS RESULTADOS Skip-Call - Origem 21

22 AVALIAÇÃO DOS RESULTADOS Skip-Call - Destino 22

23 AVALIAÇÃO DOS RESULTADOS Skip-Call - Total 23

24 AVALIAÇÃO DOS RESULTADOS Skip-Call – Índice de Violação para Sistema 24

25 AVALIAÇÃO DOS RESULTADOS Skip-Call – Índice de Violação para Sistema 25

26 AVALIAÇÃO DOS RESULTADOS Skip-Call – Índice de Violação para Sistema 26

27 AVALIAÇÃO DOS RESULTADOS Back-Call - Origem 27

28 AVALIAÇÃO DOS RESULTADOS Back-Call - Destino 28

29 AVALIAÇÃO DOS RESULTADOS Back-Call – Índice de Violação para Sistema 29

30 AVALIAÇÃO DOS RESULTADOS Back-Call – Índice de Violação para Sistema 30

31 AVALIAÇÃO DOS RESULTADOS Dependência de Ciclo – Strongly Connected Component 31

32 AVALIAÇÃO DOS RESULTADOS Dependência de Ciclo – Índice de Violação para Sistema 32

33 AVALIAÇÃO DOS RESULTADOS Dependência de Ciclo – Índice de Violação para Sistema 33

34 AVALIAÇÃO DOS RESULTADOS Dependência entre Aspectos e Arquitetura em Camadas 34

35 AVALIAÇÃO DOS RESULTADOS Dependência entre Aspectos e Arquitetura em Camadas 35

36 AVALIAÇÃO DOS RESULTADOS Dependência entre Aspectos e Arquitetura em Camadas 36

37 AVALIAÇÃO DOS RESULTADOS Dependência entre Aspectos e Arquitetura em Camadas 37

38 AVALIAÇÃO DOS RESULTADOS Dependência entre Aspectos e Arquitetura em Camadas 38

39 AVALIAÇÃO DOS RESULTADOS Boas Práticas de Programação A abordagem proposta detecta as violações após a fase de construção do software. Evitar que erros se transformem em defeitos Ambientes de desenvolvimento de software complexos podem envolver vários desenvolvedores (experientes e inexperientes). A detecção imediata de uma violação de camada pode ser um importante benefício. 39

40 AVALIAÇÃO DOS RESULTADOS Boas Práticas de Programação 40

41 AVALIAÇÃO DOS RESULTADOS Boas Práticas de Programação 41

42 CONCLUSÕES Analisadas as diferenças entre POA e POO no contexto de violações da arquitetura em camadas. O Framework ajudou a encontrar problemas triviais. Foi analisado como a POA influencia o resultado das métricas. O total de violações é menor na versão OO. 42

43 CONCLUSÕES A métrica SCVI(Health Watcher) se mostrou mais problemática na versão OO. Pouca ocorrência de back-call. Nenhuma na versão AO. Houve apenas uma única ocorrência de dependência de ciclo. A métrica DCVI(Health Watcher) apresentou o pior resultado possível. 43

44 CONCLUSÕES Houve dependências dos aspectos para todas as camadas em todos os cenários. O Framework foi útil para validar os objetivos de alguns cenários de evolução. As métricas SCVI(Sistema) e DCVI(Sistema) se mostraram inadequadas. De forma geral, as análises quantitativas se mostraram coerente com as análises qualitativas. 44

45 TRABALHOS FUTUROS Avaliar em sistemas mais complexos em diferentes contextos. Implementar o framework em IDEs. Utilizar outras linguagens AO. Avaliar a proposta de boas práticas. 45

46 TRABALHOS FUTUROS Implementar novos cenários para o Health Watcher Analisar eficiência do Framework. Criação de novas métricas para suprir problemas atuais Comprovar hipóteses com as métricas atuais. 46


Carregar ppt "Aluno: Mário Monteiro Orientador: Sérgio Soares 1."

Apresentações semelhantes


Anúncios Google