A reengenharia de software consiste da revisão e da reestruturação de um software ou de seus artefatos e serve para minimizar os efeitos da degradação crescente do
software durante sua evolução. A reengenharia de software tem como objetivo o
aumento da qualidade do software através da recuperação de documentos, reestruturação da sua arquitetura, reescrita do código, etc (SNEED, 2008).
Neste contexto, a reengenharia de requisitos é a aplicação das técnicas de reengenharia de software com o objetivo de recuperar, melhorar a qualidade ou reorganizar os documentos de requisitos de um sistema (SNEED, 2008; FAHMI et al., 2007).
Dentre as técnicas de reengenharia de software aplicáveis à reengenharia de requisitos as seguintes se destacam (SNEED, 2008):
• Refatoração: é uma técnica que consiste da reestruturação do código-fonte e
é empregada mais usualmente em códigos-fonte com linguagens orientadas a objeto. Através da refatoração, busca-se reestruturar classes, métodos, heranças e associações, deixando o código mais fácil de compreender e, consequentemente, de manter. A refatoração é considerada, pelos métodos ágeis, inexorável, pois não se espera que o projeto original do software contenha as classes e abstrações corretas;
• Engenharia Reversa: a engenharia reversa consiste da recuperação de
artefatos de mais alto nível de abstração utilizando artefatos de baixo nível de abstração. Ela tem como objetivo extrair vários tipos de informação de um
software existente, esteja este na forma binária ou código-fonte, e utilizar esta
Gestão de Requisitos de Software
2008). A engenharia reversa é considerada um pré-requisito de qualquer projeto de reengenharia, uma vez que os artefatos de mais alto nível são importantes para compreensão do software e, portanto, necessários para a sua alteração. A engenharia reversa também é recomendada como uma tecnologia chave para o suporte da evolução de software quando a única fonte confiável de informações é o código-fonte (CANFORA; PENTA, 2007). A compreensão do que o sistema faz e como está estruturado é fundamental para o sucesso na evolução de um software (FAHMI et al., 2007).
A aplicação das técnicas de refatoração na reengenharia de requisitos é o resultado do trabalho de Rui (2003, 2007). Rui (2003, 2007) propôs uma técnica para refatoração de casos de uso, permitindo a reestruturação dos casos de uso sem que a sua semântica seja alterada.
A engenharia reversa de requisitos é um processo que busca, através da análise de artefatos de nível mais baixo de um software (código-fonte e/ou binários em geral), criar o modelo de requisitos do mesmo (CANFORA et al., 2008). Ela é a principal técnica utilizada na reengenharia de requisitos e é fundamental para a compreensão e/ou manutenção de um software, quando a documentação não é confiável (IEEE 1219-1998, 1998; CANFORA; PENTA, 2007; CANFORA et al., 2008). Segundo estimativas, mais de 50% do esforço de manutenção é despendido na compreensão do programa (CANFORA et al., 2008; FAHMI et al., 2007).
Um modelo conceitual da engenharia reversa está representado por um diagrama de classes na figura 5 (CANFORA et al., 2008).
Figura 5 – Modelo Conceitual da Engenharia Reversa (CANFORA et al., 2008)
Segundo este modelo, a engenharia reversa é realizada para atingir o objetivo de um engenheiro de software (classe ObjetivoEngenhariaReversa) para resolver algum problema relacionado a algum software legado (classe Software Legado) e transformá-lo em um software evoluído (classe Software Evoluído). Este objetivo pode ser o maior entendimento do software (classe ObjetivoEntendimento) ou uma mudança que torne possível realizar sua evolução (classe ObjetivoMudança). Um
Software (classe Software) possui vários artefatos (classe Artefato de Software),
dentre estes artefatos, se encontram código-fonte e os binários. A engenharia reversa pode extrair informações do código-fonte ou dos binários, quando o código- fonte não está disponível. Esta extração é realizada pelo Analisador (classe Analisador) e alimenta uma base de informações sobre o sistema legado (classe Base de Informações). O Abstrator (classe Abstrator) consultando esta base de informações consegue gerar visões de alto nível do software (classe Visão do
Gestão de Requisitos de Software
Software). Entre estas visões se encontram: arquiteturas, diagramas UML, requisitos
e ligações de rastreabilidade entre código-fonte e documentação de alto nível. As visões são importantes para satisfazer o objetivo de entendimento do software e são usadas na Atividade de Mudança do software (classe AtividadeMudança) que é realizada para satisfazer o objetivo de mudança, produzindo um software evoluído (CANFORA et al., 2008).
Dentro deste modelo, destacam-se duas etapas na engenharia reversa de requisitos (CANFORA et al., 2008):
• Extração de informação (realizada pela classe Analisador): a extração da
informação analisa diversos artefatos do sistema e captura dados;
• Abstração (realizada pela classe Abstrator): usa os dados extraídos para criar
uma visão ou documentação voltada para o engenheiro de software.
As técnicas atuais de engenharia reversa permitem a construção de analisadores e abstratores bastante eficientes, permitindo em algumas ferramentas, a visualização de um diagrama de classes que é resultado da engenharia reversa de um código- fonte instantaneamente (CANFORA et al., 2008).
Canfora e Penta (2007) apresentam o estado da arte na engenharia reversa, deixando claro que a engenharia reversa é fundamental para o entendimento de código já desenvolvido, dando um grande apoio à manutenção de software. Dentro desta pesquisa, pode-se perceber que a geração automática de modelos de requisitos, ainda é um assunto sendo pesquisado e sem respostas.
Na busca destas respostas, Yu et al. (2005), ao pesquisar o estado da arte, apresentou os seguintes tópicos de interesse para a engenharia reversa de requisitos:
• Recuperação de requisitos não funcionais de um sistema;
• Recuperação dos objetivos e propósitos de um sistema;
• Recuperação de cenários e diagramas de atividades de um sistema;
• Recuperação de casos de uso de um sistema;
• Confronto de requisitos e implementação, permitindo detectar diferenças
entre o especificado e o implementado;
• Recuperação da rastreabilidade dos requisitos.
Destes tópicos, a recuperação de casos de uso ainda representa um grande desafio e, na falta de meios automatizados de recuperá-los, Liu (2005) apresenta um trabalho para engenharia reversa de requisitos baseado em técnicas semióticas. O seu trabalho propõe um método baseado em investigação, inspeção do sistema e entrevista com os usuários para a recuperação dos requisitos. Ele contribui, ao propor uma abordagem metodológica para a engenharia reversa de requisitos, mas esta abordagem, por ser totalmente manual, tem custo muito elevado e só deve ser usada em sistemas que já não podem ser evoluídos e precisam ser substituídos.
A pesquisa de trabalhos subsequentes mostra que o estado da arte pouco foi alterado após Yu et al. (2005), com destaques para o trabalho de Yang et al. (2006) com recuperação de requisitos iniciais, Fahmi et al. (2007) com um processo de evolução de software baseado na engenharia reversa de requisitos, Canfora et al. (2008) com um modelo conceitual da engenharia reversa e Marcus e Maletic (2003), Jermakovics et al. (2008), De Lucia et al. (2008), Lormans e Deursen (2009) e Oliveto et al. (2010) com técnicas e ferramentas para recuperação da rastreabilidade dos requisitos usando técnicas de LSI (Latent Semantic Indexing).
A pesquisa do estado do arte da engenharia reversa de requisitos revelou uma crescente importância deste tema na evolução de sistemas e a escassez de
Gestão de Requisitos de Software
soluções que permitam o uso extensivo da mesma, principalmente em função da falta de soluções para automatização.