sfCon 2012 - Conceitos de Engenharia Reversa aplicados na migração de sistemas legados Symfony 1.x...

Post on 26-Jun-2015

1.828 views 0 download

description

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.

Transcript of sfCon 2012 - Conceitos de Engenharia Reversa aplicados na migração de sistemas legados Symfony 1.x...

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

www.totlab.com.br

Eu souGuilherme Veras

um “ varredor TIC ”

- 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 ...

Objetivos do dia

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.

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.

O que são sistemas legados?

- 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.

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.

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.

Razões para manter um sistema legado:

“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.

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.

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.

Problemas gerados por sistemas legados

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.

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.

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.

O que é Engenharia Reversa?

Visualizando os conceitos

- 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.

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.

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.

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.

Motivações - Razões para engenharia reversa

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.

Técnicas e Sistemas de ER

- 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

Outras Questões - Outros pontos de atenção

Nosso objetivo é falar sobre sistemas que usam●

● Symfony 1.x ●

●como framework de desenvolvimento

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

Falando sobre Web Softwares

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.

Analisar,●

●Analisar,●

Analisar●

●e

Na prática o que eu devo fazer ?

●Tomar um café ●e

●Analisar novamente

Na prática o que eu devo fazer ?

- 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)

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

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)

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

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

Na prática - Uma sugestão de passo a passo

- 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

Nossos objetivos

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)

Conclusão

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.

Desvantagens

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

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.”

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)

...

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)

Visão geral - Diferenças Estrutura

Symfony 1.x Symfony 2.x

Visão geral - Diferenças entre conceitos

Projeto

Aplicação

Módulo

Projeto

Aplicação

Bundle

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)

O que é um Bundle

Aplicação

Módulo

Plugins

Libs

Bundle

Nas Views

Layout

Partial

Slot

Component

ModelosSlots

Symfony 1 - Estrutura

Projeto

Aplicações

Módulos

Joobet

Frontend,Backend

Oferta, Categoria, Empresa

Symfony 2 - Estrutura

Projeto

Aplicações

Bundle

Joobet

Frontend,Backend

Oferta, Categoria, Empresa

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

Dificuldades?

Você domina o que faz?

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 ...

Um pouco de prática ...

Baixando, Instalando e Configurando o Banco de dados

Baixando, Instalando e Configurando o Banco de dados

Baixando, Instalando e Configurando o Banco de dados

Baixando, Instalando e Configurando o Banco de dados

Baixando, Instalando e Configurando o Banco de dados

Baixando, Instalando e Configurando o Banco de dados

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

Como você faria no symfony 1.x

- Faço um build all com o comandosymfony 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 CRUDsymfony doctrine:generate-module  --with-show frontend (Aplicação) mensagem (Modulo) Mensagem (Modelo)

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

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

Conclusões Symfony

- Vale a pena migrar para Symfony 2

guilhermeveras@gmail.com @guilhermeveras www.totlab.com.br

</apresentação>

Questões ???