Suporte à Engenharia Reversa para o ambiente SEA

Transcrição

1 Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis - SC 2004

2 Sumário 1 Objetivo p Tema p Delimitação do Tema p Objetivo Geral p Objetivos Específicos p Justificativa p Problema p. 6 2 Metodologia de trabalho p Tecnologias e Ferramentas p. 7 3 Engenharia Reversa p O que é p Limitações p Engenharia Reversa hoje p. 9 4 Compiladores p Descrição e funcionamento p Compiladores para diferentes linguagens e Reutilização de código... p Geração semi-automatizada de compiladores p Análise de caso: GCC p A ferramenta de suporte à Engenharia Reversa para o SEA p. 13

3 5.1 SEA e Ocean p Técnicas para recuperação do projeto p XMI - O formato de transferência de dados da UML p Uma extensão do XMI p Inserção direta de definições p Requisitos da ferramenta p Projeto p Pontos de extensão p Engenharia reversa de código Java p Descrição do projeto p Conclusão e trabalhos futuros p Conclusão p Trabalhos futuros p. 17 Apêndice A -- Documentação do código p. 18 Apêndice B -- Código fonte p. 19 Referências p. 20

4 4 1 Objetivo 1.1 Tema O trabalho terá como tema a inclusão do suporte à Engenharia Reversa no Ambiente SEA. O Ambiente SEA foi desenvolvido por Ricardo Pereira e Silva, como fruto de sua tese de Doutorado, e é uma ferramenta voltada ao projeto de artefatos 1 reutilizáveis de software, e ainda carece de um suporte à Engenharia Reversa. 1.2 Delimitação do Tema A Engenharia Reversa pode ser abordada em diversos níveis, desde código de máquina para código assembly, ou deste para uma linguagem de alto nível, ou desta para o projeto. Iremos trabalhar com a recuperação do projeto a partir do código fonte, ou seja, partiremos de uma linguagem em alto nível e chegaremos nos diagramas que deram origem ao código. O código fonte será necessariamente uma linguagem Orientada a Objetos (Java, C++, Smalltalk, etc.), e os diagramas serão utilizados no formato especificado pelo ambiente. 1.3 Objetivo Geral Apresentar uma estrutura de suporte para construção de ferramentas de engenharia reversa para o ambiente SEA. 1 Por artefato de software entende-se frameworks, componentes, bibliotecas, etc.

5 5 1.4 Objetivos Específicos Os objetivos específicos do trabalho serão a construção efetiva do framework, a construção de ferramentas voltadas a linguagens específicas, como validação do framework, alterações no ambiente SEA e no framework OCEAN para não perder algumas informações semânticas a respeito do código gerado. 1.5 Justificativa É consenso entre os especialistas em projeto e desenvolvimento de software que durante o desenvolvimento orientado a objetos, tanto de aplicações como de artefatos de software é necessário a criação de uma documentação, que compreende desde o projeto da arquitetura do artefato (ou aplicação) até o código gerado. A prática recomendada é manter o código gerado seguindo a risca as especificações do projeto, porém, a criação de um projeto que possa ser convertido em código sem modificações é algo difícil de ser atingido. Existem procedimentos que fornecem um meio de alterar o projeto durante o desenvolvimento do software, porém geralmente as pressões para fazer cumprir os prazos tendem a colocar estes procedimentos em desuso. Como resultado, normalmente temos um projeto diferente do resultado final, e o último será utilizado efetivamente. Quando se trata do desenvolvimento de aplicações, essa diferença entre projeto e resultado final trará conseqüências graves na fase da manutenção, pois a equipe responsável terá uma dificuldade maior em entender o código. Agora, quando o artefato desenvolvido será usado para gerar novas aplicações, como é o caso de frameworks, por exemplo, essa lacuna entre projeto e código pode ser gravíssima, uma vez que isso altera a forma como o desenvolvedor da aplicação precisa utilizar o framework, e normalmente esse uso foi escolhido no projeto da aplicação, com base no projeto do framework. Para evitar esses problemas, ao final do desenvolvimento do software (ou artefato), é feito um processo de atualização do projeto, refletindo as alterações causadas pela geração de código. Porém essa tarefa é tanto mais complexa quanto o tamanho do código, que na maioria das vezes não é pequeno. Para auxiliar a equipe de desenvolvimento nessa parte, existem ferramentas de Engenharia Reversa, que visam construir o projeto a partir do código. Infelizmente, algumas informações são perdidas com a geração de código, como os casos de uso, mas diagramas como os diagramas de classe, diagramas de seqüência 2, 2 Diagramas de seqüência podem ser recuperados, porém com limitações

6 6 entre outros especificados pela Unified Modeling Language (UML) são possíveis de serem reconstruídos. O ambiente SEA foi construído a a partir do framework OCEAN e é uma ferramenta Computer Aided Software Engineering (CASE) especialmente voltada para a construção de frameworks e componentes (1). O ambiente ainda não possui uma ferramenta de engenharia reversa, apesar de planejado pelo autor. 1.6 Problema A criação da ferramenta enfrentará alguns desafios, tais como forte dependência com relação à linguagem alvo e informações de projeto que são perdidas com a geração código. Serão analisadas três formas de introduzir as informações recuperadas no ambiente, de forma direta, através do padrão XMI! ( XMI) ou através de alguma extensão ao XML Metadata Interchange (XMI).

7 7 2 Metodologia de trabalho No desenvolvimento deste projeto adotaremos uma metodologia de desenvolvimento orientada a objetos, seguindo um modelo baseado no modelo em V, com possibilidade de retorno de fases. 2.1 Tecnologias e Ferramentas Na área de engenharia reversa temos algumas tecnologias em uso, tanto na área de construção de compiladores quanto na área de engenharia de software. Algumas ferramentas, citadas apenas como exemplo, são Flex, Bison e GALS, na área de compiladores, e outras ferramentas de engenharia reversa. Um outro software que será cuidadosamente avaliado será o GNU Compiler Collection (GCC), que traz uma estrutura de reuso voltada a compiladores.

8 8 3 Engenharia Reversa 3.1 O que é A engenharia reversa pode ser definida como sendo a reconstrução do modelo de software a partir do software já construído, ou seja, é o inverso do processo de engenharia normal. Quando se desenvolve um software, por exemplo, com um modelo de desenvolvimento baseado no modelo em cascata, o software passa primeiro por um estágio de levantamento de requisitos, seguido por estágio de análise, onde se desenvolvem diagramas como os de casos de uso e iteração, que serão usados para gerar um diagrama de classes e outros diagramas, conforme a metodologia em uso, e só então será gerado o código para o software. Na engenharia reversa, nos interessa percorrer o caminho inverso, já temos o código do software pronto, mas sua documentação é inexistente, ou quando existe é muito incompleta, casos típicos de desenvolvimento de software sem processo. 3.2 Limitações Quando se dá o processo de engenharia reversa sobre um código, alguns diagramas são simples de se reconstruir, como os digramas de corpo de método, introduzido com outro nome na UML 2.0 ((2)), mas já presente na especificação original do Ocean ((1)), e diagramas de classe. Outros diagramas, como por exemplo diagramas de casos de uso e statecharts são mais complicados de se obter de forma automática, necessitando de intervenção humana.

9 9 3.3 Engenharia Reversa hoje As ferramentas de engenharia reversa encontradas hoje estão normalmente presentes em ferramentas CASE, como módulo adicional, e limitam-se a recuperar o diagrama de classes a partir do código fonte. Exemplos de ferramentas CASE com suporte a engenharia reversa são o Rational Rose, Poseidon UML e Togheter.

10 10 4 Compiladores 4.1 Descrição e funcionamento Define-se um compilador como sendo um tradutor que transforma uma linguagem de alto nível, em uma linguagem de mais baixo nívelprocurar citação. Um compilador é, em essência, um parser que, dadas determinadas regras de funcionamento (léxicas, sintáticas e semânticas), gera um código equivalente ao da linguagem de entrada (por exemplo Java), em uma outra linguagem (por exemplo, Assembly). Um compilador pode ser decomposto em alguns módulos para melhor entender seu funcionamento. Basicamente, ele possui um analisador léxico, responsável por decompor o código em tokens, que serão comparados contra construções sintáticas válidas, pelo analisador sintático. Sendo então submetidos à uma análise semântica, verificando se as construções possuem um significado válido. Após a análise semântica, um código intermediário é gerado, que será então otimizado e transformado em código final. Quando as operações acima ocorrem de forma seqüencial, uma após a outra, o compilador é dito ser em forma de pipelineprocurar referência. Uma outra possível abordagem é a compilação dirigida pela sintaxe, que tem algumas vantagens em termos de tempo de resposta para situações de erro, do que o compilador em pipeline, mas esta análise foge ao escopo deste trabalhocolocar referência. No compilador dirigido pela sintaxe, as mesmas etapas ocorrem, porém coordenadas pelo analisador sintático, que solicita tokens ao analisador léxico, e envia construções ao analisador semântico conforme a sintaxe da linguagem de entrada for sendo analisada.

11 4.2 Compiladores para diferentes linguagens e Reutilização de código 11 As diferentes linguagens possuem estruturas léxicas, sintáticas e semânticas diferentes. Portanto, em princípio cada uma precisaria de um compilador próprio. Considerando-se essa óptica, é difícil poder imaginar uma reutilização de código quando se faz compiladores. Apesar de termos analisadores diferentes para diferentes linguagens, esses são diferentes normalmente apenas nas tabelas de análise. Por exemplo, um analisador léxico universal poderia ser construído se considerar que ele implementa apenas a lógica de navegação e reconhecimento no autômato regular, e que este lhe fosse fornecido como argumento de entrada. A mesma analogia pode ser aplicada aos analisadores sintáticos, porém nestes há uma peculiaridade extra que deve ser considerada. Conforme as construções sintáticas que uma linguagem apresenta, esta pode exigir um parser LALR, SALR, dentre outros. A análise semântica dificilmente pode ser reutilizada. Apesar da possibilidade de reuso nesse aspecto, não vemos nenhum compilador completo que possua capacidade de apresentar essa flexibilidade. Isso se deve, principalmente, ao fato de que o maior esforço despendido está na geração das tabelas de parse para as diferentes análises, e na construção do analisador semântico Geração semi-automatizada de compiladores Existem disponíveis ferramentas de geração semi-automatizada de compiladores. Nelas, o usuário informa as gramáticas (léxica e sintática) da linguagem e as ferramentas se encarregam da geração do analisador léxico e sintático, deixando o usuário a cargo da geração do analisador semântico e melhoria das mensagens de erros. Alguns exemplos dessas ferramentas: Yacc e Bison, JavaCC, GALS. 4.3 Análise de caso: GCC O GCC foi um projeto ousado e que teve sucesso, sendo hoje parte do projeto GNU! (GNU). O GCC se propõe a ser uma coleção de compiladores, e de fato, é isso. O pacote completo do GCC traz compiladores para linguagens mais atuais, como C (gcc), C++ (g++) e mais recentemente, Java (gcj), e compiladores para linguagens mais antigas,

12 12 como Fortran (?). Além da gama de opções de linguagem, o GCC fornece geradores de código para diversas plataformas, incluindo x86, Motorola 68k, SPARC, MIPS 64, entre outros. A grande magia do GCC, é o fato de que um compilador feito para uma nova linguagem já estará apto a gerar código para qualquer plataforma suportada pelo GCC, e de forma semelhante, o suporte à uma nova plataforma se fará disponível a todas as linguagens suportadas. Isso faz do GCC o melhor exemplo de reuso de código em termos de compiladores. Procurar mais informações sobre o funcionamento do GCC e analisar se ele é útil

13 13 5 A ferramenta de suporte à Engenharia Reversa para o SEA 5.1 SEA e Ocean Colocar descrição do SEA e Ocean 5.2 Técnicas para recuperação do projeto Para recuperar o projeto de um software para dentro do ambiente SEA, uma vez que o código tenha sido, ou esteja sendo analisado, existem algumas técnicas possíveis, todas com vantagens e desvantagens. As seções abaixo se dedicam à análise das três abordagens aparentemente mais interessantes XMI - O formato de transferência de dados da UML A própria definição da UML traz como apêndice um formato para intercâmbio dos diagramas, chamado XMI. Esse formato dita algumas regras de escrita de um metamodelo, que pode (e deve) ser compreendido por todas as ferramentas compatíveis com UML. A principal vantagem dessa proposta é a possibilidade de gerar modelos para qualquer ferramenta CASE compatível com UML. Porém tem um grande obstáculo, que são as próprias limitações oferecidas pela UML. Como descrito na seção 5.1, o SEA oferece algumas extensões à UML padrão, que não poderiam ser exploradas corretamente só com esse modelo de descrição.

14 14 O padrão do XMI está definido em (3) Uma extensão do XMI Uma outra possibilidade, ainda tendo em vista a portabilidade, seria propor uma extensão ao XMI, que tivesse apenas as limitações comuns ao SEA e à UML, mantendo compatibilidade completa com o XMI padrão. A principal vantagem dessa proposta é, ainda, a possibilidade da portabilidade, pois qualquer ferramenta capaz de ler XMI deveria ser capaz de ler o XMI estendido. Como desvantagens aparentes, percebe-se apenas as limitações da UML que são comuns às limitações do SEA, e a possibilidade de não se conseguir explorar ao máximo o potencial do ambiente para manter compatibilidade com o XMI Inserção direta de definições A terceira alternativa seria não utilizar um modelo intermediário de representação e inserir as definições diretamente no meta-modelo do SEA. Essa alternativa poderia tirar máximo proveito das potencialidades do SEA, mas tornaria a ferramenta de engenharia reversa altamente dependente do design do framework Ocean. Essa não é categoricamente uma desvantagem, mas seria muito interessante poder dar suporte a múltiplas ferramentas. Esse problema poderia ser contornado com a criação de um componente de geração de XMI a partir do SEA. 5.3 Requisitos da ferramenta A ferramenta para engenharia reversa deve cumprir os seguintes requisitos: Compatibilidade semântica entre o modelo e o código Construção incremental e interativa do modelo Facilidade de fornecer suporte à novas linguagens Verificar se não há mais requisitos a serem cumpridos

15 Projeto Colocar as especificações de projeto assim que possível 5.5 Pontos de extensão Apresentar os pontos de extensão da ferramenta, se fizer sentido; depende do projeto

16 16 6 Engenharia reversa de código Java 6.1 Descrição do projeto

17 17 7 Conclusão e trabalhos futuros 7.1 Conclusão 7.2 Trabalhos futuros

18 18 APÊNDICE A -- Documentação do código Inserir a documentação gerada do código aqui.

19 19 APÊNDICE B -- Código fonte Inserir código fonte aqui.

20 20 Referências 1 SILVA, R. P. Suporte ao desenvolvimento e uso de frameworks e componentes. Dissertação (Tese de Doutorado) Universidade Federal do Rio Grande do Sul, Instituto de Informática, Março , 8 2 OMG. UML 2.0 superstructure specification. Draft version in September 8, OMG. UML 2.0 diagram interchange specification. Draft version in September 8,