Grupo: Eduardo DóriaBruno LinsMarcus ViniciusDiego Calasans

“Até hoje, o foco da literatura vai no sentido de se ensinar a criar grandes soluções arquiteturais de software, no entanto, e cada vez mais, as necessidades de hoje e amanhã vão no sentido de se ser capaz de evoluir de sistemas existentes, ou legados, para grandes soluções.“

Joshua Kerievsky

Software desestruturado› Não obedece padrões

Ausência de separação entre camadas› Não possui arquitetura definida

Código “Spagheti”› Ausência de modularização

Termo “Software Rejuvenation” citado pela primeira vez em Junho 1995 por Huang no 25th International Symposium on Fault-Tolerance Computing, USA.

“Software rejuvenation is periodic preemptive rollback of continuously running applications to prevent failures in the future”

Evolução de diversos paradigmas relativos à Engenharia de Software

Capacidade de se adaptar às constantes necessidades

Condicionada pela base tecnológica

Características necessárias para um código saudável:› Grau de reutilização do código› Não duplicação do código› Testabilidade do código

Linguagens OO

Maioria dos Sistemas Legados não utilizam OO

Sistema diz-se Legado quando surgem novos requisitos aos quais o mesmo não consegue responder de forma eficaz.

Intervenção de forma gradual

• O rejuvenescimento de software tem a finalidade de melhorar a qualidade do software reduzindo os custos com sua manutenção.

• As técnicas mais utilizadas são:– Redocumentação– Reestruturação /Refatoração– Engenharia reversa– Reengenharia

Importância da documentação

Custo de Manutenção

Rotatividade de profissionais

Características básicas

› Baseado na engenharia reversa (código)

› Gerar documentação mínima necessária

› Buscar automatização quando possível

Modificar um sistema de software para melhorar a estrutura interna do código sem alterar seu comportamento externo.

Melhora no entendimento do código

Testes automatizados

Processo inverso da Engenharia de Software

Recuperar código-fonte

Exemplos de uso:› Cracks, Drivers, Samba (Linux)

Partindo-se do sistema existente (via código-fonte, interface ou ambiente), são abstraídas as suas funcionalidades e são construídos o modelo de análise e o projeto do software.

Pode-se utilizar a engenharia reversa

Relacionamentos no Ciclo de Desenvolvimento de Software (CHIKOFSKY e CROSS, 1990)

Software sempre atual Boa manutenabilidade Adaptabilidade Reusabilidade Evitar queda do sistema

Alto custo de desenvolvimento

DownTime maior na maioria dos casos

Não serve para todos os tipos de sistemas

Processo de envelhecimento› Degradação gradual da sua eficiência, que

ao longo do tempo pode levar a um estado de inutilidade

Causas› Vazamento de memória› Uso progressivo de discos de

armazenamento› Uso de estruturas e arquivos

desatualizados› Muitos erros de arredondamento numérico

O custo da queda imprevista de um software é muito maior do que uma “queda” curta e planejada

Aumenta o tempo de vida, trazendo muita economia

Prevenção reativa› Vê se a aplicação falha e toma a medida

correta› Reiniciar, recuperar, rollback, reordenar,

replay

Prevenção proativa e preventiva› Rejuvenescimento de software› Diferentes maneiras de prevenção, que

minimiza os danos colaterais

Modelo de transição do sistema sem o rejuvenescimento

Modelo de transição com o uso do rejuvenescimento

Pf =

Downtimew/o r(L) = Pf * L

Costw/o r(L) = Pf * L * cf

2111

1

rrr

24

34

111

rr

rr

r

Pr P*1

• Pp =

• Pf =

• Pr =

• P0 =

Prr P*34

Prr P*24

• Downtimew r(L) = (Pf + Pr) * L

• Costw r(L) = (Pf * cf + Pr * cr) * L

O objetivo é manter no So o maior tempo possível

R3 alta -> menor tempo de queda (downtime)

R3 baixa -> maior tempo de queda (downtime)

Lambda alto-> rejuvenescimento mais frequente

Lambda baixo -> rejuvenescimento aumenta o downtime

Tempo de falhas = 1 mês -> = 1/(1*30*24) Leva 30 min para recuperar um erro não

esperado; r1 = 2 Tempo So->Sp = 7 dias; r2 =1/(7*24) Leva 10 min para recuperar um erro

esperado (rejuvenescimento); r3 = 6 Custo médio do sistema fora do ar, cf, is

R$5,000/hora Custo medio do rejuvenescimento, cr, is

R$5/hora

Sem rejuvenescimento

(r4 = 0)

Uma vez por mês

r4 = 1/(20*24)

Uma vez a cada duas semanas

r4 =1/(4*24)

Downtime (em horas) 4.86 5.68 7.03

Custo total do Downtime

R$ 24.310 R$ 18.944 R$ 10.072

Um modelo baseado em caixa-preta Precisam ter os valores médios das

diferentes transições Não leva em conta a performance do

sistema

Um intervalo de rejuvenescimento periódico e fixo

Usam redes de Petri para observar o comportamento do sistema

Não leva em conta a performance do sistema

É possível identificar a performance do sistema de acordo com observações

O processo de degradação vem de uma seqüência sucessiva de falhas e quebras

Existe um parâmetro de observação que vai decidir se o sistema entrou em um estado de “crash”

Dois critérios decidem:› O risco da decisão que precisa ser tomada

de modo que ocorrer um risco antes do rejuvenescimento seja inferior a um nível de risco premeditado

› Os alertas dos limiares baseados nos parâmetros (S(t) -> índice de degradação)

Baseado na observação do comportamento do sistema em espaços iguais de tempo

Baseados na quantidade de falhas encontradas em um intervalo de tempo

Regras para renovar o sistema antes que ele chegue num estado limiar

Dois tipos de políticas› Baseadas em riscos premeditados› Baseadas em alertas de limiares

A escolha depende da equipe e da instituição

O papéis do pessoal da equipe seguem o mesmo modelo definido pela instituição e pela metodologia

Micro Focus Net Express LegacyJ Metex

Permite integração de aplicações escritas em COBOL com tecnologias baseadas em J2EE

Pouca ou nenhuma modificação no código

Permite utilização de EJB Permite Edição de código utilizando

ECLIPSE

Moderniza aplicações legadas escritas em COBOL

Reutiliza códigos existentes para criar aplicações modernas

Expões aplicações COBOL como WEB Services

Torna uma aplicação COBOL compatível com Servidores JAVA

Compartilha dados de aplicações diferentes através de XML

Automatiza completamente a reconstrução de softwares legados

Gera código de alta qualidade Gera aplicações Java ou .NET Pode gerar aplicações pra WEB PowerBuilder, Oracle Forms, Forte, VB

e Centura Não é apenas um migrador de código

Transformação Reengenharia Documentação UML Migração de Banco de Dados Habilitação para WEB

Revisão de arquitetura – Discussão com o cliente sobre a nova arquitetura;

Conversão automática de código – A ferramenta converte o código automaticamente;

Utilização de ferramentas avançadas para completar o código – Utilização de algumas ferramentas avançadas do Metex para completar a conversão;

Teste de integração e Verificação – O Metex também oferece ferramentas para verificação e testes do código gerado;

Teste de aceitação de usuário – Ao final do processo é utilizado um rastreador de bugs online para correção de possíveis erros.

Disponibiliza a aplicação na WEB Move as funções do negócio para

dispositivos Wireless Maior competitividade Reduz custos operacionais

Nova Funcionalidade› Necessidade de implementação de uma

nova funcionalidade ou alteração dos requisitos de uma funcionalidade já implementada

› Normalmente, o cliente identifica uma nova necessidade não atendida pelo sistema

Recolher histórias dos clientes› Tem como objetivo identificar os requisitos

da nova funcionalidade.› São realizadas reuniões com os

desenvolvedores e os clientes.› Tem como resultado uma lista de requisitos

que devem ser atendidos por essa nova funcionalidade.

Desenho (Design)› Representação da nova funcionalidade

através de modelos.› Deve ser usada para a validação.

Conseguir uma melhor percepção dos impactos do desenvolvimento de novas funcionalidades.

Escrita de Testes› Descreve o comportamento esperado para

a nova funcionalidade› A especificação dos testes deve ser feita

antes da codificação› Ao iniciar a codificação, os testes serviram

para o desenvolvedor saber o objetivo da nova funcionalidade

Codificação› Codifica a nova funcionalidade uma

linguagem de programação.› O uso de padrões na codificação melhora a

legibilidade no código e propõe soluções para problemas comuns.

› Normalmente, não se é usado padrões de codificação nas primeiras iterações. Refactoring

Execução de Testes› Fase essencial no desenvolvimento de

software› Garante que o comportamento do sistema

continua a funcionar de acordo com os seus requisitos

Produto› Cada iteração termina com a geração de

uma nova versão do sistema.› Não deve ter um grande volume de

alterações

Na área de TI, as mudanças tem sido cada vez mais constantes.

Aumento no número de projetos e com complexidades cada vez maiores.

A empresa precisa manter bem organizado o controle sobre os seus projetos.

Desejo de melhorar a taxa de sucesso de projetos, que continuamente se tornam mais complexos

Necessidade de aliviar o gerente de projetos de tarefas administrativas associadas ao gerenciamento de um projeto.

É uma área da empresa que possui a visão de todos os projetos.

Tem como objetivos:› Melhoria da eficiência no planejamento e

condução dos projetos› Informação rápida sobre os projetos

existentes› Auxílio nas decisões a serem tomadas

sobre o futuro de cada projeto

Padronização de uma metodologia› Defini uma ferramenta e métodos de

controle e acompanhamento dos projetos.› Manter essas ferramentas e métodos

atualizados e adaptados às necessidades da empresa

› Realizar o treinamento dos funcionários e mantê-los atualizados na metodologia e ferramentas

Avaliação dos recursos de projetos› São analisados todos os recursos do

projeto: Humano Financeiro Tempo Material

› É importante para a análise de desempenho dos projetos e a priorização dos mesmos.

Planejamento de Projetos› Tem como objetivo manter cada projeto

organizado, priorizado, distribuído em áreas e devidamente documentado

› É possível se obter também dados históricos que auxiliam a elaboração de novos planos.

Gerenciamento de Projetos› Definir melhores práticas de trabalho para

facilitar o gerenciamento Revisão e Análise de Projetos

› Constante revisão das atividades Custo e prazo Impactos no desempenho

Y. Huang, C. Kintala, N. Kolettis, N.D. Fulton, Software rejuvenation: analysis, module and applications, in: Proceedings of the 25th International Symposium on Fault-Tolerance Computing (FTCS-25), Pasadena, CA, USA, June 1995.

Bobbio, A., M. Sereno and C. Anglano, 2001. Fine grained software degradation models for optimal rejuvenation policies. Performance Evaluation

S. Garg, A. Pfening, A. Puliafito, M. Telek, K.S. Trivedi, Modelling and analysis of load and time-dependent software rejuvenation policies, in: Proceedings of the Third International Workshop on Performability Modeling of Computer and Communication Systems (PMCCS3), Bloomingdale, IL, September 1996, pp. 35–39.

S. Garg, A. Puliafito, M. Telek, K.S. Trivedi, Analysis of software rejuvenation using Markov regenerative stochastic Petri net, in: Proceedings of the Sixth International Symposium on Software Reliability Engineering (ISSRE95), Toulouse, France, October 1995.

Universidade Aberta. Rejuvenescimento de Software . Disponível em: <http://www.moodle.univ-ab.pt/moodle/mod/glossary/print.php?id=2243&mode=&hook=ALL&sortkey=&sortorder=&offset=-10>. Acesso em: 17 out. 2008.

SILVA, Nuno Alberto Pereira da. Rejuvenescimento de Aplicações: Uma experiência com software de seguros. Universidade do Minho, 2005. Disponível em: < http://repositorium.sdum.uminho.pt/handle/1822/5635 >. Acesso em: 17 out. 2008

LABUTO, Gianncarla Cutini Barcellos. A gestão de Projetos e o Project Office. Disponível em: <http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/103>. Acesso em: 17 out. 2008.

VAIDYANATHAN, Kalyanaraman; TRIVEDI , Kishor S. A Comprehensive Model for Software Rejuvenation, 2005. Disponivel em: < http://ieeexplore.ieee.org/iel5/8858/31216/01453531.pdf > Acesso em: 17 out. 2008.

AVRITZER Alberto ;BONDI Andre; GROTTKE Michael ; TRIVEDI Kishor S. ; WEYUKER Elaine J. Performance Assurance via Software Rejuvenation: Monitoring, Statistics and Algorithms, 2006. Disponivel em: < http://ieeexplore.ieee.org/iel5/10881/34248/01633532.pdf> Acesso em: 17 out. 2008.

MARCHIORO, Eliete. UM ESTUDO SOBRE REJUVENESCIMENTO DE SOFTWARE EM SERVIDORES WEB APACHE, 2003. Disponivel em: <http://www1.capes.gov.br/estudos/dados/2003/41001010/002/2003_002_41001010025P2_Teses.pdf >. Acesso em: 17 out. 2008.

• BAUMOTTE, Ana CláudiaBAUMOTTE, Ana Cláudia. . Project Office: como vender essa idéia na sua organização. Disponível em: < http://www.pmimg.org.br/downloads/ProjectOffice.ppt> . Acesso em: 17 out. 2008.

• PIEKARSKI, Ana ElisaTozetto ; QUINÁIA, Marcos Antonio. Reengenharia de software: o que, por quê e como. Disponível em: < http://www.unicentro.br/editora/revistas/recen/v1n2/Reengenharia.pdf>. Acesso em: 29 nov. 2008.

• ANQUETIL, Nicolas; OLIVEIRA, Káthia Marçal de. Processo de Redocumentação: Uma Necessidade. Disponível em: < http://www.ucb.br/prg/professores/anquetil/Publicacoes/sbqs02.doc>. Acesso em: 29 Mai. 2008.

• WIKIPEDIA. Engenharia reversa de software. Disponível em: <http://pt.wikipedia.org/wiki/Engenharia_reversa>. Acesso em: 29 Mai. 2008

• WIKIPEDIA. Refatoração. Disponível em: <http://pt.wikipedia.org/wiki/Refatora%C3%A7%C3%A3o>. Acesso em: 29 Mai. 2008.