Reengenharia

1
Reengenharia

• Primeiras conclusões

2
Análise do Código Fonte

• Arquitetura em Camadas

3
Fachada

• Classe concreta
• impede a substituição por outra implementação
• Acoplado com implementação dos Cadastros
• Apenas delegação

4
Negócio

• Possui interface
• Negócio implementado aqui
• delegação para persistência
• Usa genetico.dll (só roda no windows)
• Alto acoplamento

5
Persistência

• Possui interface
• SQL
• Subclasse de Database
• Alto grau de código semelhante

6
Componentes Básicos

• Entidades de Negócio
• Não possuem inteligência (negócio fica em outra
  camada)
• Usam o padrão Data Transfer Object

7
Outros

• Estrutura de empacotamento inadequada (alto
  acoplamento)
• interfaces e implementação no mesmo pacote
• existência de ciclos de dependências
• Tratamento de exceções complexo (muitas exceções)

8
Conclusão

• Arquitetura deve ser modificada para facilitar o
  reuso
• uso do GRASP (General Responsibility Assignment
  Software Patterns)
• uso de interfaces
• Identificação de 2 domínios controle acadêmico
  (vertical) e alocação de recursos (horizontal)

9
Conclusão

• Ferramentas (frameworks) indicadas para aumentar
  reusabilidade
• Hibernate (Persistência - domínio horizontal)
• PicoContainer (Component Model)
• promove inversion of control

10
Conclusão

• Importante implementação NEUTRA, sem dependência
  com nenhum Component Model (PicoContainer permite
  isso).
• Existe uma .DLL sendo utilizada (genetico.dll) -
  só roda no windows... reimplementação em Java
  aumentaria o reuso)

11
Questões

• Priorizar o reuso do código existente ou
  reutilizar o que for possível?
• Engenharia de domínio trabalhar com dois
  domínios, ou combinar em um domínio híbrido?