Engenharia de Software II Aula 27 http://www.ic.uff.br/~bianca/engsoft2/ Aula 27-26/07/2006 1
Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software Métricas para software Gestão de projetos de software Conceitos (Cap. 21) Métricas (Cap. 22 Seções 22.1 e 22.2) Estimativas (Cap. 23 Seções 23.1 a 23.7) Cronogramação (Cap. 24) Gestão de risco (Cap. 25) Gestão de qualidade (Cap. 26 Seções 26.1 a 26.7) Gestão de modificações (Cap. 27 Seções 27.1 a 27.3) Reengenharia e engenharia reversa (Cap. 31) Aula 27-26/07/2006 2
Reengenharia Considere a seguinte situação: Produto utilizado regularmente, mas está ficando velho, quebra com freqüência, leva tempo para consertar e não utiliza a tecnologia mais recente. Se for hardware, a solução é jogá-lo fora e comprar um novo. Se for software customizado será necessário reconstruí-lo. Com funcionalidade adicional, melhor desempenho, confiabilidade e manutenibilidade. A reengenharia é o processo de reconstrução de um software existente. Muitos dos passos e produtos da reengenharia são os mesmos que os de um processo de software qualquer. Aula 27-26/07/2006 3
Reengenharia de Processos de Negócio vs. Reengenharia de Software A Reegenharia de Processo do Negócio (BPR) é necessária quando a empresa quer mudar/melhorar a forma de trabalhar. Define as metas do negócio, identifica e avalia os processos de negócio existentes e cria processos revisados que satisfazem melhor as metas atuais. À medida que as regras de negócio se modificam, o software deve acompanhar. Criação de novos sistemas. Ex.: baseados em Web. Modificação/reconstrução de aplicações existentes. A Reengenharia de Software pode acontecer mesmo quando as regras de negócio não se modificam. Substitui a funcionalidade do software existente por um software melhor. Aula 27-26/07/2006 4
Reengenharia de Processo do Negócio (BPR) Um processo de negócio é um conjunto de tarefas logicamente relacionadas, realizadas para atingir um resultado definido. Exemplos: Projetar um produto novo. Adquirir serviços e suprimentos. Contratar um novo empregado. Pagar fornecedores. Cada processo de negócio é definido como um conjunto de processos de negócios. Isto gera uma hierarquia de processos. A BPR pode ser aplicada a qualquer nível da hierarquia. Quanto mais alto o nível, mais alto o risco. Por isso, a maioria dos esforços de BPR foca em subprocessos. Muitas vezes é realizada por firmas de consultoria. Aula 27-26/07/2006 5
Um modelo BPR Definição do negócio Metas do negócio são identificadas levando-se em conta redução de custo, redução de prazo, aperfeiçoamento da qualidade e desenvolvimento pessoal. Identificação do processo São identificados e priorizados processos críticos para alcançar as metas. Avaliação do processo O processo existente é rigorosamente analisado e medido. Os custos e o tempo são registrados, e problemas de qualidade/desempenho são isolados. Especificação e projeto do processo Casos de uso são preparados para processo que deve ser reprojetado. Um novo conjunto de tarefas é projetado para o projeto. Prototipação Usada para testar processos antes de integrá-los ao negócio. Refinamento e instanciação Com base na realimentação do protótipo, o processo é refinado e então instanciado. Aula 27-26/07/2006 6
Reengenharia de Software Cenário comum: Uma aplicação é usada durante 10 ou 15 anos por uma empresa. Foi corrigida, aperfeiçoada e adaptada muitas vezes, nem sempre seguindo boas práticas. Agora, a aplicação está instável: funciona mas não é possível modificá-la sem efeitos colaterais. Software não-manutenível! A necessidade de manutenção de software leva a uma ênfase cada vez maior na reengenharia de software. Manutenção de software pode ser: Corretiva = corrigir de erros Adaptativa = acomodar mudanças no ambiente ou nas necessidades do usuário. Prefectiva = melhorar a performance do software. Preventiva = tornar o software mais fácil de manter no futuro = reengenharia. Aula 27-26/07/2006 7
Um Modelo de Processo de Reengenharia de Software Análise de inventário Ordenar aplicações ativas de acordo com a criticalidade para o negócio e manutenibilidade atual a fim de identificar candidatos a reengenharia. Reestruturação de documentos Decidir se vale à pena recriar a documentação; pode-se só mexer na documentação de partes que forem relevantes. Engenharia reversa É o processo de recuperação do projeto a partir do código-fonte; ferramentas extraem informação sobre o projeto de dados, arquitetural e procedimental. Reestruturação de código O código-fonte é analisado e violações das práticas de programação estruturada são registradas e consertadas; o código resultante é revisado e testado. Reestruturação de dados A arquitetura dos dados atual é dissecada e os modelos de dados são definidos; estruturas de dados existentes são revisadas quanto à qualidade; caso mudanças sejam necessárias isso implicará na reengenharia em escala plena. Engenharia avante Recupera informação do código-fonte existente e usa essa informação para reconstituir o sistema a fim de melhorar sua qualidade/performance. Aula 27-26/07/2006 8
Conceitos de Engenharia Reversa Um processo de engenharia reversa pode variar quanto a: Nível de abstração Idealmente, o processo deveria ser capaz de gerar informações em diferentes níveis: Representações de projeto procedimental Informação de programa e estrutura de dados Modelos de fluxo de dados e de controle Modelos entidade-relacionamento Completeza É o nível de detalhe que é fornecido em cada nível de abstração. Normalmente diminui à medida que o nível de abstração aumenta. Melhora proporcionalmente com a quantidade de análise. Interatividade Grau em que a pessoa é familiar com as ferramentas utilizadas. À medida que aumenta o nível de abstração, mais interatividade é necessária para maior completeza. Aula 27-26/07/2006 9
Conceitos de Engenharia Reversa (cont.) Um processo de engenharia reversa também pode variar quanto a: Direcionalidade Sentido único: a informação extraída será fornecida ao engenheiro de software, que fará a atividade de manutenção. Sentido duplo: a informação extraída será alimentada em uma ferramenta de reengenharia que tentará reestruturar ou regerar o programa antigo. Aula 27-26/07/2006 10
Processo de Engenharia Reversa Código-fonte sujo Código reestruturado Código-fonte limpo Processamento Extração de abstrações Especificação Interface Base de dados Refinar e simplificar Especificação final Aula 27-26/07/2006 11
Engenharia Reversa para Entender Dados A engenharia reversa de dados ocorre em diferentes níveis: Estruturas de dados internas A engenharia reversa para os dados internos focaliza na definição de classes de objetos. Isso é conseguido pelo exame do código com o objetivo de agrupar variáveis relacionadas. Estrutura do banco de dados Normalmente a engenharia reversa do banco de dados é feita antes de se mudar de um paradigma de banco de dados para outro. Arquivos para banco de dados relacional. Exige um entendimento dos objetos e relacionamentos. Aula 27-26/07/2006 12
Engenharia Reversa para Entender o Processamento Começa com uma tentativa de entender e depois abstrair abstrações procedimentais. O código é analisado em diversos níveis de de abstração: sistema, programa, componente, padrão procedimental e declaração. Normalmente se usa uma abordagem semiautomática. Ferramentas ajudam o engenheiro a entender a semântica do código existente. Aula 27-26/07/2006 13
Engenharia Reversa das Interfaces com o Usuário O desenvolvimento de GUIs tornou-se um dos tipos mais comuns de atividade de reengenharia. Mas antes deve ocorrer a engenharia reversa da interface. Três perguntas devem ser respondidas para entender o funcionamento de uma interface com o usuário: Quais são as ações básicas (cliques de mouse e pressões de tecla) que a interface deve processar? Qual a descrição compacta da resposta comportamental do sistema a essas ações? Que conceito de equivalência de interfaces é relevante aqui? Um valor entre 0 e 10 pode ser substituído por uma barra de rolagem. A notação de modelagem comportamental fornece um meio de se desenvolver respostas às duas primeiras questões. A maior parte da informação pode ser obtida da interface atual. Aula 27-26/07/2006 14
Reestruturação Modifica o código-fonte/dados para tornálos mais amenos a modificações futuras. Em geral, não modifica a arquitetura global. Se isso acontece, transforma-se em engenharia avante. Ocorre quando a arquitetura básica é sólida, apesar de o interior precisar de trabalho. Aula 27-26/07/2006 15
Reestruturação de código É realizada para gerar um programa que produz a mesma função que o programa original, porém com mais qualidade. Técnicas de reestruturação: A lógica do programa é modelada usando álgebra booleana e uma série de regras de transformação é aplicada para reestruturar a lógica. Um diagrama de intercâmbio de recursos mapeia cada módulo e os recursos que são intercambiados entre ele e outros módulos Recursos: tipos de dados, procedimentos e variáveis. Pela representação do fluxo de recursos, a arquitetura pode ser reestruturada para um acoplamento mínimo. Aula 27-26/07/2006 16
Reestruturação dos dados Antes que a reestruturação dos dados possa começar, uma análise de dados deve ser conduzida. Definições de dados, descrições de arquivos, entradas e saídas, e descrições de interface são avaliadas. O objetivo é extrair itens de dados e objetos para obter informação sobre o fluxo de dados e entender as estruturas de dados existentes. Uma vez completada a análise de dados, começa o reprojeto dos dados. Padronização de registro de dados: consistência entre os nomes, formatos de registros e formatos de arquivo. Translação de um tipo de estrutura/banco de dados para outro. Aula 27-26/07/2006 17
Engenharia Avante Uma análise de inventário pode ser usada para selecionar um programa que: Permanecerá em uso durante um número de anos. Está atualmente sendo usado com sucesso. Provavelmente passará por modificação ou aperfeiçoamento radical. O programa selecionado passará por uma engenharia avante ou manutenção preventiva. Na maioria dos casos, requisitos novos do usuário e tecnologia são integrados na engenharia avante. O programa redesenvolvido amplia a capacidade do antigo. Aula 27-26/07/2006 18
Engenharia Avante para Arquiteturas Cliente/Servidor A engenharia avante para uma arquitetura cliente servidor tem as seguintes características: A funcionalidade da aplicação migra para cada computador cliente. Novas interfaces GUI são implementadas nas instalações do cliente. As funções do banco de dados são atribuídas ao servidor. Funcionalidade especializada pode permanecer no servidor. Novos requisitos de comunicações, segurança, arquivamento e controle. A migração exige reengenharia tanto do negócio quanto do software. Aula 27-26/07/2006 19
Engenharia Avante para Arquiteturas Orientadas a Objeto O software passa por uma engenharia reversa, para que modelos adequados de dados, funcional e comportamental sejam criados. Casos de uso são criados caso o novo sistema amplie a funcionalidade da aplicação. Modelos de dados criados durante a engenharia reversa são depois usados com a modelagem CRC para definir as classes. Hierarquias de classe, modelos de objeto-relacionamento e subsistemas são definidos, e o projeto orientado a objetos começa. Um modelo de processo baseado em componentes pode ser usado caso exista uma biblioteca de componentes apropriada. Pode ser possível reusar algoritmos e estruturas de dados da aplicação convencional existente. Devem ser reprojetados para obedecer à arquitetura orientada a objetos. Aula 27-26/07/2006 20
Engenharia Avante de Interfaces com o Usuário Pode-se usar o seguinte processo: Entender a interface original e os dados que fluem entre ela e o restante da aplicação. Remodelar o comportamento implícito na interface existente em uma série de abstrações que tenham sentido na nova GUI. Ex.: série de comandos em texto é equivalente a uma série de cliques com o mouse. Introduzir aperfeiçoamentos que tornem o modo de interação mais eficiente. Construir e integrar a nova GUI. Pode-se usar bibliotecas e ferramentas automatizadas na construção. Deve-se tomar cuidado para não introduzir efeitos colaterais. Aula 27-26/07/2006 21
A Economia da Reengenharia Uma organização deve realizar uma análise custo/benefício antes de tentar submeter uma aplicação existente a reengenharia. Custo de manutenção = custo anual de operação e manutenção ao longo do ciclo de vida da aplicação atual. Custo de reengenharia = custo do investimento na reengenharia, considerados os riscos, mais custo anual de operação e manutenção ao longo do ciclo de vida da aplicação submetida à reengenharia. Se o custo de reengenharia é menor que o custo de manutenção, vale à pena fazer a reengenharia. Aula 27-26/07/2006 22