Recuperação De Arquitetura De Software

Recuperação de Arquitetura de Software

Authors: Bruno Quintanilha, Janaina Nascimento, Moniele Silva Sousa, Pedro Henrique, Thais Ribeiro

Universidade Federal de Uberlândia

Engenharia de Software

Uberlândia, Brasil

Abstract—The software architecture has an important role in the design and in the development and maintenance of software. However, several software has been implemented without having a previously defined architecture, as recommended by good practices for software development. In other situations, the architecture of the system has been designed in advance, but it may be out-of-date with respect to actual implementation, due to changes in the system.

Keywords— Reverse engineering; Software Architecture; Software Architecture Reconstruction

I. INTRODUÇÃO

A origem da arquitetura de software como um conceito foi primeiramente identificado no trabalho de pesquisa de Edsger Dijkstra em 1968 e David Parnas no início de 1970. Ambos enfatizaram a importância das estruturas de um sistema de software e a criticidade da identificação da sua estrutura. O estudo deste campo aumentou no início de 1990 com os trabalhos de pesquisa concentrando-se nos padrões de estilo de arquitetura, linguagens de descrição de arquitetura, documentação de arquitetura, e métodos formais. Mas foi em 1996 com Mary Shaw e David Garlan com a publicação do livro "Software Architecture. Perspectives on an Emerging Discipline" que Arquitetura de Software se formalizou como uma disciplina de engenharia para o desenvolvimento de software.

Mesmo se for feita uma pesquisa rápida poderá ser encontrado vários conceitos sobre arquitetura de software. Um desses conceitos diz que a Arquitetura de Software inclui um conjunto de decisões significativas sobre a organização de um software, tais como, a seleção dos elementos estruturais e suas interfaces; o comportamento entre esses elementos; a composição destes elementos estruturais e de comportamento em subsistemas maiores e o estilo arquitetural que guia esta organização. Em outras palavras, a Arquitetura de Software é necessária para entender o sistema e organizar o desenvolvimento do projeto

Importante resssaltar que a Arquitetura de Software envolve a documentação. Tal documentação facilita a comunicação entre os stakeholders, registra as decisões iniciais acerca do projeto de alto-nível, e permite o reuso do projeto dos componentes e padrões entre projetos. Ressalta-se que a descrição arquitetural de um sistema é extremamente importante, pois serve como um esqueleto sobre o qual propriedades podem ser provadas e, por isso, é importante para expor a capacidade do sistema em satisfazer seus requisitos principais. Segue como exemplo a essa importância o fato de que a arquitetura de software desempenha um papel de “ponte” entre os requisitos e a implementação do sistema.

Com isso, pode-se perceber que a falta de uma arquitetura de software pode elevar o custo de manutenção do sistema , já que uma parte do tempo será gasta para entender o software e a outra parte para descobrir onde a modificação deverá ser feita.

Outro conceito relevante para este trabalho é o de Engenharia Reversa. Como o próprio nome indica, a Engenharia Reversa é uma engenharia "ao contrário", portanto, é uma atividade que trabalha com um produto existente e tenta entender como este funciona e o que faz exatamente. Essa prática é usada quando se quer trocar ou modificar algo por outro, com as mesmas características,

Dessa forma, entende-se que a Engenharia Reversa define um conjunto de atividades que permitem, a partir de uma solução de software já pronta, extrair todos os conceitos ali empregados, assim, é possível obter a compreensão do software existente, para recapturar ou recriar o projeto e decifrar os requisitos atualmente implementados pelo sistema.

Para melhor entendimento desse conteúdo a figura 1 mostra o ciclo de vida da Engenharia de Software, a qual segue um fluxo progressivo. Na Figura 2, compara essa “progressão” com a “reversão”. Embora esses termos tenha sido utilizado aqui é importante ressaltar que não se pode confudir com a ideia de avanço e regressão. O que acontece na verdade, como pode ser observado na figura 2, enquanto ocorre o processo tradicional da Engenharia de Software - chamada de Engenharia Progressiva - temos que na Engenharia Reversa ocorre o caminho inverso no ciclo de vida

Figura 1: Ciclo de Vida da Engenharia de Software

Pressman define a Engenharia Reversa como a atividade de reverter um software às suas definições mais abstratas de desenvolvimento – modelo – com o objetivo de compreender como funciona e como não funciona para poder ser modificado de acordo com as necessisdades apresentadas.[Pressman, 2006]. E Sommerville diz que a engenharia reversa é o processo de analise de software com o objetivo de recuperar seu projeto e sua especificação. O sistema permanece inalterado durante esse processo [Sommerville, 2006]

O processo de engenharia reversa, ainda segundo Pressman, está sujeito a três tópicos: nível de abstração, completeza e direcionalidade. O nível de abstração se refere à facilidade ou à dificuldade de compreensão de uma informação do projeto. Quanto mais próximo do estágio de implementação, maior será a dificuldade de entendimento do sistema e mais baixo é o nível de abstração. Quanto mais próximo do estágio de análise, maior será a facilidade de entendimento do sistema e mais alto é o nível de abstração. A completeza, ou grau de abstração, se refere ao detalhamento da informação gerada em um nível de abstração. E a direcionalidade do processo de engenharia reversa pode ter sentido único e duplo. Quando o processo de engenharia reversa tem um único sentido, o projeto é resgatado. Um dos processos que geralmente ocorrem após é a manutenção do sistema. Se a direcionalidade é de sentido duplo, após o processo de resgate do projeto acontece à reestruturação de cada nível de abstração ou uma reengenharia [Pressman, 2006]. A engenharia reversa, portanto ocorre de um nível de abstração mais baixo para um mais alto, trazendo à clareza detalhes do projeto que estão implementadas no código.

Se observar a figura 3,