AdverServer Servidor de Ranking para AdverGames Parte 3 Felipe Maia.

Apresentação em tema: "AdverServer Servidor de Ranking para AdverGames Parte 3 Felipe Maia."— Transcrição da apresentação:

1 AdverServer Servidor de Ranking para AdverGames Parte 3 Felipe Maia

2 AdverServer  Servidor de ranking para jogos online – AdverGames  Produto comercial  Não é vendido como um produto mas faz parte dos jogos

3 AdverServer  Permite cadastro e manipulação de administradores, empresas, jogos, jogadores, invite-emails e entradas de ranking  Sistema de Informação com banco de dados  Realiza comunicação com interface JSP e com um protocolo de mensagem HTTP para comunicação Flash

4 AdverServer  Possui controle de persistência, porém sem controle de concorrência nem de transação  Razoavelmente modularizado

5 AdverServer - Arquitetura JSP Page Flash Game HttpServlet FabricaHandler Handlers... Fachada Negocio

6 Concern Identificados  Concerns  Persistence  Concurrency  ExceptionHandling  ErrorLogging  PropertiesReading  FlashProxy  Business

7 Remodularização Adverserver  Processo de remodularização OO  Primeiramente o Adverserver foi remodularizado em Java básico OO  Bons resultados foram obtidos na remoção dos clones  Foram encontrados alguns bugs que foram corrigidos (exemplo: editar não validava os campos fornecidos)

8 Remodularização Adverserver  Processo de remodularização OO  A marcação do código via concerntagger forneceu um bom conhecimento do sistema  O projeto original possuia uma arquitetura decente, utilizando design patterns como AbstractFactory e Singleton

9 Remodularização Adverserver  Processo de remodularização OO  O projeto original possuia alguns pequenos problemas básicos e simples de design  Algumas classes estavam mal nomeadas  Exemplo: Repositorio era na verdade um repositorio especifico SQL  Algumas classes estavam em pacotes que não deveriam estar  Exemplo: Repositorio SQL estava no pacote de negocio  Classes básicas acessavam cadastros para se autalizarem na persistencia

10 Remodularização Adverserver  Processo de remodularização AO  Somente após a modularização OO foi realizada a modularização AO  A modularização AO não encontrou muitos locais onde atuar  O controle de persistencia foi completamente modularizado via OO e AO  O controle de sincronização só evitava a quebra da pattern Singleton

11 Remodularização Adverserver  Processo de remodularização AO  Não existia controle de transação, as operações eram simples  O tratamento de exceção não continha clones reais a serem modularizados  O logging de erro só ocorria na geração de uma exceção  A comunicação Flash já estava bem modularizada via OO

12 Remodularização Adverserver  Processo de remodularização AO  A camada de negócio já estava bem modularizada via OO

13 Dados recolhidos  Tempo da remodularização  28 horas entre estudo e remodularização  Refactorings OO via eclipse:  Rename:  13x  Move:  4x  EncapsulateFields:  5x

14 Dados recolhidos  Refactorings OO via eclipse:  Extract Method:  6x  Padrões:  Removidos 4 singletons  Adicionado um singleton  Utilização de Fabrica na modularização da persistencia  Idiomas AO:  Tag (marker) interface

15 Refactorings

16 Dados recolhidos  Refactorings não existentes no Eclipse:  Feitos a mão  Exemplo:  Encapsulate method  As páginas JSP não foram modificadas  Foram criadas 3 novas classes java e 1 novo aspecto aj

17 Dados recolhidos  Pares de clones encontrados na nova versão:  35  Porém nenhum par parece ser bem modularizável via OO ou AO  A maioria é negócio similar ou strings SQL

18 Resultados  Problemas na modularização OO foram detectados e foram consertados  Inclusive alguns bugs foram detectados e corrigidos  Decorreu de todas as três partes do projeto

19 Resultados  Somente o crosscutting concearn Persistence foi totalmente modularizado  Decorreu da primeira parte do projeto  Antes invadia código de cadastros e de classes básicas  Agora consiste de repositórios, gerenciador de conexão e aspecto de inicialização  Alto ganho em modularização

20 Resultados  Tratamento de exceção já estava parcialmente sem duplicação de código  Pequenos problemas foram consertados via OO  Evitando assim duplicação

21 Conclusão  O projeto foi bastante trabalhoso e cansativo  AOP é extremamente potente porém extremamente complexa sem as ferramentas corretas  OO gera bons resultados quando utilizada em conjunto com uma boa arquitetura e design patterns  Porém podem se tornar excelentes via adição de AOP