São abordados conceitos de Engenharia Reversa aplicados na migração de sistemas legados Symfony 1.x para Symfony 2.x. O objetivo é que o responsável pela migração possa usar este conteúdo como guia de referência no desenvolvimento do seu processo de migração de sistemas.

1. Conceitos de Engenharia Reversa
aplicados na migração de sistemas legados
Symfony 1.x para Symfony 2.x
www.totlab.com.br

2. Eu sou
Guilherme Veras
um “ varredor TIC ”

3. Objetivos do dia
- Algo que possa agregar (Guia de Referência)
- O que são sistemas legados ?
- O que é engenharia reversa ?
- Falando sobre Web Softwares
- Falando sobre Symfony 2
- Symfony 1.x vs Symfony 2.x
- Na prática
- Indagações, reflexões e onde o vento levar ...

4. O que são sistemas legados?
Um sistema legado é um antigo método, tecnologia ou
sistema (programa).
Um sistema legado pode ou não permanecer em uso,
entretanto, mesmo que ele não seja mais usado, ele
pode continuar a impactar na organização devido ao seu
papel histórico.
Dados históricos podem não ter sido convertidos para
um novo sistema e ele ainda pode existir dentro do novo
sistema com um uso personalizado em um esquema
crosswalk.

5. O que são sistemas legados?
Em ambos os casos, o efeito sobre a
inteligência de negócios, relatórios operacionais e
estratégicos pode ser significativo.
Por uma variedade de razões, um sistema legado pode
continuar a ser utilizado, muitas vezes (senão todas),
passado o tempo de vida de suporte pelo seu
fornecedor, resultando em falta apoio e grandes desafios
na manutenção.

6. Razões para manter um sistema legado:
- O sistema funciona satisfatoriamente, e o proprietário
não vê razão para alterá-lo.
- Os custos de redesenhar ou substituir o sistema são
proibitivos porque o mesmo é grande, monolítico,
e/ou complexo.
- O refactory para um novo sistema seria oneroso em
tempo e dinheiro quando comparado com os
benefícios previstos em substituí-lo por completo.

7. Razões para manter um sistema legado:
- O sistema requer constante disponibilidade, de modo
que não pode ser retirado de serviço, e o custo da
concepção de um novo sistema com um nível de
disponibilidade semelhante é elevada.
Exemplos disso incluem: sistemas para lidar com
contas de clientes em bancos, sistemas de reserva,
controle de tráfego aéreo, distribuição de energia (rede
elétrica), usinas nucleares, instalações militares de
defesa etc.

8. Razões para manter um sistema legado:
- A maneira que o sistema funciona não é bem
compreendida. Tal situação pode ocorrer quando os
projetistas do sistema deixaram a organização, e que
o sistema tenha ou não sido devidamente
documentados ou documentação foi perdida.
- O utilizador espera que o sistema possa ser facilmente
substituído quando isso se tornar necessário.

9. Problemas gerados por sistemas legados
“Os sistemas legados são considerados potencialmente
problemáticas pelos engenheiros de software por várias
razões” (Bisbal et al., 1999), por exemplo:
- Os sistemas legados são freqüentemente executados
em hardware obsoleto, e peças de reposição para tais
computadores podem se tornar cada vez mais difíceis
de obter.

10. Problemas gerados por sistemas legados
- Estes sistemas podem ser difíceis de manter, melhorar
e expandir porque há uma falta de compreensão do
sistema, os funcionários que eram peritos podem ter se
aposentado e pode não existir mais documentação.
- Os sistemas legados podem ser vulneráveis a partir de
outras camadas (insegurança recursiva), como antigos
sistemas operacionais e/ou aplicativos, devido à falta de
pacotes de segurança estarem disponíveis ou aplicados.
Também podem existir configurações de produção que
causam problemas de segurança.
E isso pode ser potencialmente explorado por hackers.

11. Problemas gerados por sistemas legados
- Integração com sistemas mais novos também pode ser
difícil, porque o software novo pode usar tecnologias
completamente diferentes e pode não existir uma forma
simples de comunicar tais plataformas.

12. O que é Engenharia Reversa?
A engenharia reversa é o processo de descobrir os
princípios tecnológicos de um dispositivo, objeto ou
sistema através da análise de sua estrutura, funções e
operação.
Muitas vezes envolve reconstruir alguma coisa, por
exemplo: um dispositivo mecânico, componentes
eletrônicos, softwares.
Mas também se estende para outras áreas como:
Química, Biológica, Geográfica etc.

13. O que é Engenharia Reversa?
Além de analisar o funcionamento em detalhes do
produto, ela pode ser usada para dar manutenção, ou
ser desenvolvido um novo dispositivo ou programa que
faz a mesma coisa sem usar ou simplesmente duplicar
(sem estender) o original.
“A engenharia reversa tem suas origens na análise de
hardware para obter vantagem comercial ou militar.”
O objetivo é deduzir decisões de design de produtos
finais com pouco ou nenhum conhecimento adicional
sobre procedimentos envolvidos na produção original.

14. O que é Engenharia Reversa?
Entretanto as mesmas técnicas vem sendo pesquisadas
para aplicação em sistemas de software legados, não
para fins industriais ou de defesa, mas sim para
substituir a documentação incompletas, incorretas, ou
indisponíveis.

15. Visualizando os conceitos

16. Motivações - Razões para engenharia reversa
- Interfaceamento: ER pode ser utilizada quando em
um sistema é necessário fazer a interface com outro e
para que ambos os sistema negociem informações.
Esses requisitos normalmente existem para quando
buscamos a interoperabilidade entre plataformas.
- Militar ou Comercial (espionagem): Aprender sobre a
nova tecnologia de um inimigo ou concorrente,
capturando um protótipo, pode resultar no
desenvolvimento de produto semelhante ou melhor.

17. Motivações - Razões para engenharia reversa
- Melhorar a documentação técnica que pode ser
obsoleta desde a concepção do produto.
ER de software pode fornecer a documentação mais
recente necessária para a compreensão do estado da
arte do sistema e sua continuidade.
- Obsolescência de tecnologia: Muitas vezes o
fornecedor não oferece mais suporte ao produto, o
que significa que a única maneira de incorporar a
funcionalidade em nova tecnologia é a engenharia
reversa do produto existente e em seguida projeta-lo.

18. Motivações - Razões para engenharia reversa
- Modernização Software: ER é geralmente necessária
para compreender situação atual do sistema e estimar
corretamente o esforço necessário para migrar o
mesmo.
- Análise de Segurança do Produto:
Para identificar se é possível remover proteções
contra cópia.
Para avaliar possíveis vulnerabilidades de violação de
patentes e desenvolvimento de contratos específicos.

19. Motivações - Razões para engenharia reversa
- Acadêmico (aprendizagem). ER para efeitos de
aprendizagem, pode ser realizada para compreender
questões-chave de um projeto mal sucedido e
posteriormente melhorar o seu design.
- Inteligência competitiva técnica:
Entender o que seu concorrente está fazendo de
verdade, contra (vs), o que ele diz que esta fazendo.

20. Técnicas e Sistemas de ER
Existem diversas técnicas de ER, entretanto elas não
definem o “como fazer” ou “o que deve ser feito”.
Elas estão ligadas a extração de informação para
levantamento de requisitos.
Depois destas extrações e analises o processo de
desenvolvimento seguiria de forma normal.

21. Outras Questões - Outros pontos de atenção
- Leis especificas em cada país
- Existe muita documentação sobre o assunto
(com visões muito particulares) analise crítica é essencial
- Existem diversas métricas e formulas de avaliação de
esforço de conversão
- Já existem certificações especificas nesta área

22. Falando sobre Web Softwares
Nosso objetivo é falar sobre sistemas que usam
●
● Symfony 1.x
●
● como framework de desenvolvimento

23. Falando sobre Web Softwares
A maioria dos projetos web possui:
- Um banco de dados MySQL ou PostgreSQL ...
- Arquivos estáticos (HTML, Imagens, JavaScript, Css )
- Arquivos Uplodados para o sistema por usuários ou admins
- PHP classes e bibliotecas
- Batch files (scripts de automação e de linha de comando ou cron)
- Log files (da aplicação e do servidor)
- Arquivos de configuração

24. Falando sobre Web Softwares
Para qualquer aplicação existem geralmente quatro tipos de dados:
* Dados iniciais: São necessários para a aplicação trabalhar.
Por exemplo: categorias, tags, configurações.
Muitas vezes também precisamos de usuários administradores previamente
cadastrados para operar o backend da aplicação.
* Dados de testes: São necessários para a aplicação ser testada.
Como desenvolvedor, você precisa escrever testes para garantir que o sistema
se comporte como descrito nas sua documentação, e a melhor forma de fazer
isso é escrever testes. Cada vez que você executa seus testes, você pode precisar
limpar o banco de dados, inserindo alguns dados novos para testar.
* Dados de usuário: São criados pelo usuário durante a vida normal da
aplicação.
* Dados de processamento: Geralmente de rotinas agendadas (cron) ou de
outros sistemas com interface.

25. Na prática o que eu devo fazer ?
Analisar,
●
●
Analisar,
●
Analisar
●
●
e

26. Na prática o que eu devo fazer ?
● Tomar um café
●e
●Analisar
novamente

27. Na prática - Uma sugestão de passo a passo
- Analisar o arquivo de schema (yml, xml na pasta config)
- Analisar o banco de dados real
- Analisar os arquivos de fixtures e sql
- Analisar os comportamentos do ORM (Behaviors)
- Analisar a pasta config global
- Analisar o arquivo global de configurações do projeto (app.yml)

28. Na prática - Uma sugestão de passo a passo
- Analisar pasta lib global
- Filtros (filter)
- Formulários (form) ex: campos obrigatórios e post validators
- Modelo (model) ex: getMyScore
- Widgets ex: data X até data Y com jquery data picker
- Tarefas (task) ex: Enviar uma mensagem para usuários que
atualizaram o perfil em X dias, cancelar acesso por falta de pagamento
- Outras bibliotecas (vendors) ex: Swift Mail, domPDF etc

29. Na prática - Uma sugestão de passo a passo
- Analisar pasta de testes
- Analisar pasta de plugins e realizar etapas acima recursivamente
- Analisar todos os módulos de todas as aplicações e suas partials,
componentes e slots
(gerando um mapa do sistema para isso um plugin pode nos ajudar)
- Analisar pasta lib locais (Classes myUser)
- Analisar os arquivos locais de configurações (aplicação e modulo)
app, rotas, linguagens, filtros etc
- Analisar os arquivos da pasta web
(scripts, imagens, uploads, controladores etc)
- Verificar se existe integração como outros sistemas (web service)

30. Na prática - Uma sugestão de passo a passo
- Verificar se existe dependência entre classes
- Levantamento das interfaces visuais e das suas interações
(mapeamento do workflow) - User Cases
- Levantar com o desenvolvedor original (se possível) uma lista de
pontos de atenção e de melhorias (em entrevista), ele pode ter tido
varias ideias que não foram implementadas (por algum tipo de
viabilidade como tempo o recurso) ou pensando em outras formas de
organização mas na prática não conseguiu implementar.
- Analisar logs do servidor web e do sistema
- Clonar o projeto em um ambiente de teste
- Torcer para que o desenvolvedor não tenha alterado nada do core do
Symfony para fazer o seu projeto

31. Na prática - Uma sugestão de passo a passo
Notas:
* Esse processo pode ser repetir
* É possível usar o plugin sfGraphViz para visualizar o DER
(Caso banco seja Mysql usar mysql workbench)
* O plugin sfApplicationMapPlugin gera um mapa de todo o sistema
* Existe pelo menos 50% de chance de encontramos alguma diferença
entre os modelos mapeados nas configurações, formulários e no banco
* data-dump e data-load irão nos ajudar (lembre-se de sempre clonar o
projeto e testar data-dump e data-load antes de colocar em produção)
* Use Doctrine Migrations

32. Nossos objetivos
- Entender as relações e conexões entre os objetos (tabelas) do banco
de dados e o sistema.
- Entender se existem filtros e/ou se os dados sofrem modificações ao
serem inseridos e/ou consultados no banco (comportamentos)
- Gerar documentação real do atual estado da arte do sistema
(Mapa do sistema)
- Caso o sistema já possua um volume de dados, existe a possibilidade
de otimizar o banco (Normalização) caso ele já não esteja
- Analisar: volume e carga atual, licença (custos), e gerar projeções
- Identificar o que é melhor fazer a ER ou Reengenharia

33. Conclusão
Fazendo todos estes passos você terá
certeza de ter mapeado todo o
sistema?
Resposta: Não
Você terá de ver verificar tudo e ainda corre o risco deixar alguma coisa
passar. Por isso é vital que você teste o que esta sendo feito e
homologue cada interface com o setor/cliente/responsável
(e se houver integração com o desenvolvedor original melhor ainda).
Isso também vai depender do seu ciclo de desenvolvimento e das
metodologias empregadas (Garantia, ex: ANVISA - RDC 17 - GAMP 5)

34. Vantagens de usar Symfony
Usando symfony você tem a vantagem de saber onde as coisas estão e
fazer a o seu mapeamento.
Entretanto o desenvolvedor pode não ter seguido todos os padrões e
por isso você precisa conferir.
Além disso Symfony fornece um conjunto de ferramentas para facilitar
o seu trabalho de analise.
Graças a concepções do framework, um sistema legado Symfony é
melhor tipo de sistema legado que você poderia encontrar.

35. Desvantagens
Você fica viciado em tantas soluções profissionais e que facilitam o seu
trabalho.

36. Mas por que mudar para Symfony 2
- Eventualmente você pode precisar de uma nova tecnologia ou
integração
- Bugs de segurança ou brechas pode ser encontradas
- Referências e evolução da comunidade, as pessoas não falam mais
sobre determinado conteúdo
- Aprender mais, se tornar um profissional melhor
- Velocidade e desempenho
“Dependendo do seu projeto e de suas necessidades, você pode
escolher alguns dos componentes do Symfony 2 e iniciar o projeto com
eles, ou você pode usar tudo do framework e se beneficiar com a
integração que ele proporciona.”

37. Documentos gerados para ER ou RE:
Este documentos também são documentos de projeto (sugestões):
- Criar uma lista de comparação
Tabela | Campo | Tipo | Validação | Comportamento | Filtro
- Documento de mapeamento dos Tipos de dados:
- Dados de Teste
- Dados de Configuração e/ou inicialização
- Dados de Usuário
- Dados de Processamento
- Mapa do sistema
(Aplicações, módulos, componentes, partials, plugins, etc)
...

38. Sobre o Symfony 2
“Se você olhar ao redor, cada componente parece implementar o
padrão MVC. E a maioria deles são anunciados como frameworks
MVC ... mas não Symfony 2, por que eu realmente não me importo se o
Symfony 2 e MVC ou não.”
“Se você gosta de chamar Symfony 2 de um framework MVC, então
você deve saber que ele realmente prove as ferramentas para os
controladores e visões, mas não para o modelo, para você
criar o mesmo faça “no braço” ou com alguma ferramenta ORM com
por exemplo o Doctrine.”
“Eu não gosto de MVC, porque não é assim que a web funciona.
Vejo Symfony 2 como um servidor HTTP, com solicitações e respostas.
Os princípios fundamentais de Symfony 2 estão centradas em torno da
especificação HTTP.”
Tradução adaptada de Fabien Potencier Publicado em Blog Pessoal (25/10/11)

39. Visão geral - Diferenças Estrutura
Symfony 1.x Symfony 2.x

40. Visão geral - Diferenças entre conceitos
Projeto Projeto
Aplicação Aplicação
Módulo Bundle

41. O que é um Bundle
É um bando de coisas?
Sim.
Mas pode ser melhor definido como um conjunto de arquivos que
representação uma funcionalidade.
(Um bando de coisas que serve para alguma coisa)

42. O que é um Bundle
Aplicação
Módulo
Bundle
Plugins
Libs

43. Nas Views
Layout
Partial Modelos
Slots
Slot
Component

44. Symfony 1 - Estrutura
Projeto Joobet
Aplicações Frontend,
Backend
Módulos Oferta,
Categoria,
Empresa

45. Symfony 2 - Estrutura
Projeto Joobet
Aplicações Frontend,
Backend
Bundle Oferta,
Categoria,
Empresa

46. O que é preciso? Processo básico
1 - Preparar o seu projeto (Documentação como DER etc …)
2 - Baixar a última versão do Symfony
3 - Configurar o banco de dados
4 - Configurar o apache
5 - Gerar tudo automágicamente pela linha de comando
6 – Programar minhas regras de negócio

47. Dificuldades?

48. Você domina o que faz?

49. mysql - postgres - mvc - symfony - xp - scrum
uml - tap - php - apache - linux - subversion
websvn - propel - doctrine - django - rails
prado - perl - pear - prototype - cocoa
scriptaculus - tinymce - ajax - yaml - routing
módulo rewitre - i18n - l10n - api - web service
sql - herança - oo - orm - ldap grasp - dot -
graphviz - namespace ...

50. Um pouco de prática ...

51. Baixando, Instalando e Configurando o
Banco de dados

52. Baixando, Instalando e Configurando o
Banco de dados

53. Baixando, Instalando e Configurando o
Banco de dados

54. Baixando, Instalando e Configurando o
Banco de dados

55. Baixando, Instalando e Configurando o
Banco de dados

56. Baixando, Instalando e Configurando o
Banco de dados

57. Como você faria no symfony 1.x
- Criar aplicação
symfony generate:app [--escaping-strategy="..."] [--csrf-secret="..."]
(nome da aplicacao - frontend no caso)
- Configurar o arquivo schema.yml com o seu modelo
config/schema.yml
- Configurar o arquivo fixtures.yml com os dados de inicialização e/ou
teste data/fixtures.yml

58. Como você faria no symfony 1.x
- Faço um build all com o comando
symfony doctrine:build --all --and-load --trace
- Cria o sql necessário para criação das tabelas no banco e executa
- Cria o sql com os inserts dos dados de inicialização e executa
- Mapeia as tabelas do banco em classes (model)
- Mapeia os filtros (filters)
- Mapeia os formulários (forms)
- Mostra todas as saídas por causa do parâmetro - - trace
(que é ótimo para debug)
- Criar CRUD
symfony doctrine:generate-module --with-show frontend (Aplicação)
mensagem (Modulo) Mensagem (Modelo)

59. Como você faria no symfony 2.x
- Criar novo bundle
php app/console generate:bundle
- Totlab/MensagemBundle
- Criar entidades
- php app/console generate:doctrine:entity
- Gerar schema (insere no banco)
- php app/console doctrine:schema:create
- Gerar formulário (opcional)
- php app/console doctrine:generate:form
- Gerar CRUD
- php app/console doctrine:generate:crud

60. Conclusões ER
Quando falamos de Engenharia Reversa, Reengenharia ou Migrações,
os principais fatores de sucesso estão relacionados:
- Com o envolvimento com os usuários e desenvolvedores no processo
- A nova estrutura adotada
- Uma boa gestão do projeto
- Qualificação da equipe envolvida, sempre invista em educação

61. Conclusões Symfony
- Vale a pena migrar para Symfony 2

62. Questões ???
</apresentação>
guilhermeveras@gmail.com
@guilhermeveras
www.totlab.com.br