Análise de uma aplicação legada com o Altova UModel – Parte 1

Eventualmente, quase todos os programadores profissionais terão de depurar ou adicionar funcionalidades a uma aplicação já existente, numa aplicação em que não participaram na sua criação. Nestas situações, a documentação imprecisa ou incompleta e a falta de acesso à equipa de desenvolvimento original podem representar grandes obstáculos. Felizmente, o Altova UModel consegue realizar a engenharia reversa de software existente, criando um modelo visual que acelera a análise e melhora a compreensão de uma aplicação legada. Esta é a primeira de uma série de artigos em que vamos aplicar o UModel, da Altova Ferramenta UML para modelação de software e desenvolvimento, para analisar uma simulação de um caixa automático (ATM) escrita em Java. A aplicação é baseada em vários exemplos de sistemas ATM (caixas automáticas) provenientes de tutoriais populares em Java. Como o exemplo é simples e o funcionamento de um ATM é familiar, vamos concentrar-nos mais nas técnicas que podem ser aplicadas aos seus próprios projetos em Java, C# e Visual Basic, em vez de nos exemplos de código. Aqui está uma visão da aplicação legada a funcionar numa janela de comandos:

O desenvolvedor original forneceu convenientemente as informações de exemplo da conta, para que possamos efetuar o acesso. A aplicação, então, apresenta um menu de transações familiar, semelhante ao de um multibanco:

Se examinarmos a pasta que contém a aplicação, podemos ver os ficheiros de código fonte Java e os ficheiros .class compilados, mas não encontramos nenhum ficheiro de projeto.

Não é um problema. O menu do projeto UModel permite importar um projeto, um diretório de origem ou até mesmo os ficheiros binários de uma aplicação compilada. O código fonte de projetos muito grandes provavelmente estará organizado em várias pastas, por isso, mesmo que tenha um ficheiro de projeto, poderá querer analisar uma pasta de cada vez.

Antes de começarmos, é importante configurar as opções do UModel para que ele desenhe automaticamente todas as associações de classes definidas no código fonte

Ao importarmos a pasta, também queremos incluir quaisquer comentários JavaDoc no código fonte, para que sirvam como documentação para o nosso projeto UModel

Para a nossa primeira análise da aplicação existente, queremos ter uma visão geral, por isso não vamos abrir todos os módulos opcionais:

O UModel importa o projeto em apenas alguns segundos, e a janela de mensagens não indica nenhum erro. A árvore de diagramas contém dois diagramas:

Podemos clicar na aba "Árvore de Modelos" e expandir a pasta de origem para visualizar os ícones que representam todas as classes Java que o UModel importou

Podemos voltar para a Árvore de Diagramas para abrir o conteúdo do diagrama de classes UML da fonte UML class diagram. Depois de definir todos os estilos de linha para "ortogonal" e reposicionar algumas linhas e classes para evitar sobreposições, podemos ver que o diagrama ilustra claramente as classes da aplicação e as suas relações:

Note que o nome da classe "Transaction" está em itálico, indicando que se trata de uma classe abstrata (ou classe pai), e que as subclasses "BalanceInquiry", "Withdrawal" e "Deposit" herdam as suas características. Se clicar na classe "Transaction" para a selecionar, a herança será ilustrada na janela de ajuda "Hierarquia" do UModel, e quaisquer comentários JavaDoc que apareçam no código fonte imediatamente antes da definição da classe serão exibidos na janela de Documentação:

Se utilizássemos apenas um editor de texto para analisar a aplicação existente, teríamos de examinar cada ficheiro de código fonte para compreender a estrutura hierárquica mostrada acima. Isso porque a classe "Transaction" não identifica internamente as suas subclasses. Quando localizamos uma subclasse, esta não identifica as suas classes relacionadas. E não podemos ter a certeza de que uma classe com um nome ilógico não é uma subclasse de "Transaction" até examinarmos todas elas. Também pode selecionar cada classe individualmente para consultar a sua documentação na janela de Documentação. Ou, se preferir um diagrama mais limpo, pode remover apenas os rótulos de associação do diagrama:

Agora, o asterisco que representa a multiplicidade "de zero a muitos" de contas no banco de dados é muito mais evidente.

Outro membro da nossa equipa de desenvolvimento encontrou um diagrama de classes parcial, que supostamente representava o projeto legado, e partilhou-o. Podemos verificar imediatamente que não se assemelha ao diagrama gerado pelo UModel:

A documentação da nossa aplicação antiga não corresponde ao código – um problema infeliz, mas comum! Existem várias diferenças entre o diagrama antigo e aquele que gerámos:

· The associations between ATM and the physical components are shown as composition associations

· The association between ATM and the BankDatabase is described by a text annotation

· The association between ATM and Transaction also has a text annotation, and it does not even exist in the UModel diagram

· Multiplicity is defined at each end of each association, but none were created by UModel

Vamos analisar cada um dos pontos:

· The representation of composition in the Java language is identical to ordinary association, so UModel could not deduce the composition characteristic. Of course the ATM “is composed of” a keypad, screen, cash dispenser, and deposit slot, so we can update the diagram to show composition.

· We can add a text annotation to any UModel association arrow. Simply click the arrow and start typing.

· If UModel did not create an association arrow between the ATM class and the Transaction, one must not be defined in the source code. We will postpone further investigation of this anomaly for now. · Multiplicity as shown in the legacy diagram would also require specific definition in the source code. We’ll leave this for investigation later too. Maybe that old diagram was left in the back of the file cabinet for a reason!

Vamos adicionar a anotação e, em seguida, atualizar a característica de agregação de cada associação de ATM na janela de propriedades do UModel. Também vamos usar a barra de ferramentas de layout do UModel para garantir que os retângulos que representam todas as classes tenham o mesmo tamanho. Agora, o nosso diagrama de classes tem a seguinte aparência:

O diagrama de classes finalizado é apenas o ponto de partida para a nossa análise. Nas próximas etapas, aprofundaremos a análise do código da aplicação e geraremos automaticamente mais Diagramas UML, e criar alguns novos diagramas, à medida que a nossa compreensão do código existente se aprofunda.

Se pretende começar imediatamente e analisar o código das suas aplicações Java, C# ou Visual Basic mais antigas, clique aqui para descarregar uma versão de avaliação gratuita e totalmente funcional de 30 dias do <2>Altova UModel</2>