Artigos Canal Mais Reengenharia de software orientado a objetos - Revista Engenharia de Software 37

Atenção: esse artigo tem um vídeo complementar. Clique e assista!

De que trata o artigo

Este artigo apresenta a manutenção de software evolutiva e adaptativa. Neste contexto, apresenta a aplicação dos padrões para reengenharia de software orientado a objeto.


Para que serve

Ampliar o conhecimento sobre reengenharia de software, saber identificar e aplicar os padrões para a reengenharia, e para auxiliar os gerentes de projeto em TI e analistas de sistemas na adoção de reengenharia de sistemas legados procedimentais para o paradigma orientado a objetos.


Em que situação o tema é útil

O tema discutido neste artigo é útil, principalmente, em três situações: na avaliação de um re-projeto de um sistema legado procedimental; no apoio à melhoraria da qualidade dos processos de software e do planejamento de questões administrativas em projetos de TI, e para garantir a qualidade do processo de reengenharia de software orientado a objetos.

Autores: Giuliano Prado de Morais Giglio e Gizelle Sandrini Lemos

Desde a edição 33 da Engenharia de Software Magazine, apresentamos os principais conceitos sobre a reengenharia de sistemas orientados a objetos de sistemas legados, com a abordagem de padrões de melhoria da qualidade deste processo. O Fusion/RE foi criado a partir do método Fusion com o objetivo de recuperar o projeto de softwares legados procedimentais em uma forma orientada a objetos. A experiência adquirida com a utilização do Fusion/RE em alguns sistemas norteou a sua evolução para o PRE/OO, que é um Processo de Reengenharia Orientada a Objetos com Ênfase na Garantia da Qualidade.

Dessa forma, o PRE/OO foi criado aproveitando nos clusters 2, 3 e 4, técnicas do Fusion/RE. A Figura 1 ilustra o processo de reengenharia orientada a objetos denominado PRE/OO, o qual é organizado em sete clusters de padrões.

Figura 1: Clusters de Padrões do PRE/OO.

Na edição 35, exemplificamos a aplicação do PRE/OO através de um estudo de caso apenas sobre os clusters 1 a 5 destinados à engenharia reversa. A fim de finalizarmos todo o ciclo previsto pelo PRE/OO, procuramos neste artigo demonstrar os clusters 6 e 7 destinados à Engenharia Avante, ou seja, a reconstrução do sistema legado ao paradigma orientado a objetos, dando continuidade e finalizando o referido estudo de caso.

Padrões de engenharia avante do PRE/OO

A engenharia avante é a segunda etapa do processo de reengenharia com o PRE/OO, sendo dividida em dois passos: elaborar o projeto avante e realizar a re-implementação do software. Cada passo foi documentado na forma de um cluster de padrões:

Cluster 6 – Elaborar o Projeto Avante. Contém os padrões relacionados à obtenção do modelo de projeto orientado a objetos correspondente ao software legado:

· Padrão 16: Elaborar Diagrama de Classes de Projeto: reflete o projeto das classes de forma a separar a lógica dos negócios da lógica de armazenamento do software, visando aumentar a modularidade, a manutenibilidade e melhorar o entendimento do sistema.

· Padrão 17: Construir Diagramas de Sequência: foi criado com o objetivo de documentar o fluxo das operações realizadas pelo software.

Cluster 7 – Re-Implementar o software. Reúne os padrões responsáveis pela mudança da implementação do software Delphi procedimental para orientado a objetos, objeto do estudo de caso:

· Padrão 18: Implementar as Classes.

· Padrão 19: Implementar a Lógica de Armazenamento.

· Padrão 20: Implementar a Lógica de Apresentação.

Os padrões Implementar as Classes, Implementar a Lógica de Armazenamento e Implementar a Lógica de Apresentação foram propostos como forma de conduzir o engenheiro de software no processo de re-implementação de softwares Delphi construídos sem a adoção do paradigma orientado a objetos.

A seguir são descritos os padrões de engenharia avante do PRE/OO, os quais foram agrupados nos clusters 6 e 7.

Cluster 6 - Elaborar o Projeto Avante

Serão apresentados aqui os padrões de reengenharia constantes deste cluster do PRE/OO.

Padrão 16. Elaborar Diagrama de Classes de Projeto

  • Intuito: Modularizar a funcionalidade do software, de forma a separá-la do acesso aos dados.
  • Problema: Criar uma nova instância do diagrama de classes com menor nível de abstração, de forma a visualizar as modularizações necessárias à separação da lógica de negócios da lógica de armazenamento do software.
  • Influência: Separar o acesso aos dados dos aspectos funcionais, bem como da interface do software é difícil para um programador sem experiência em programação orientada a objetos.
  • Solução:
    1. Derivar cada classe constante do diagrama de classes elaborado com a aplicação do padrão 13, Abstrair Diagrama de Pseudo-Classes;
    2. Criar um método para cada funcionalidade presente em relação à manipulação e ao acesso aos dados da(s) tabela(s) com as quais cada classe se relaciona;
    3. Caso necessário, criar atributos que facilitem a manipulação dos dados;
    4. Criar um diagrama de classes de projeto para documentação das classes definidas nos Passos 1 a 3 da Solução.
  • Exemplo: Para a classe “Cliente”, do exemplo da locadora de vídeos, foi derivada a classe “DBCliente”, como forma de modularizar o acesso à tabela de dados “Cliente”. O Diagrama de Classes de Projeto parcialmente concluído é apresentado na ...
    Quer ler esse conteúdo completo? Tenha acesso completo