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

Em Parte 1 Na série "Analisando Aplicações Legadas", apresentámos a nossa aplicação de simulação de caixas automáticos, e importámos o código fonte Java para um.. UModel projeto, e refinei um diagrama de classes para ter uma visão geral das classes da aplicação e das suas relações. Nesta entrada, vamos criar.. diagramas de casos de uso Para documentar a funcionalidade atual da nossa aplicação de caixas automáticos, vamos adicionar um diagrama de casos de utilização para planear uma melhoria futura. Como vimos na Parte 1, quando um utilizador executa a nossa simulação de caixa automático, é solicitado a iniciar sessão com um número de conta e um PIN, e depois é apresentado com um menu de transações que resume todas as interações disponíveis com a aplicação:

Com o menu "Transações" como referência, podemos criar um diagrama de casos de uso que mostre as interações do utilizador com a simulação do ATM (caixa automático):

Se estiver familiarizado com a notação UML, a primeira coisa que poderá ter notado é que o ator no nosso diagrama não se assemelha à figura típica em "vareta" utilizada na UML. O UModel permite que os modeladores de software atribuam qualquer ficheiro de imagem .bmp do Windows para representar um ator num diagrama de casos de utilização. Utilizamos a janela de ajuda "Propriedades" para atribuir uma imagem da biblioteca fornecida com o UModel.

Um diagrama de casos de uso não é o local adequado para definir o fluxo da aplicação ou as classes orientadas a objetos, mas sim para documentar como um utilizador (um ator, na terminologia UML) interage com o sistema. Podemos criar diagramas de casos de uso adicionais para mostrar mais detalhes sobre cada interação. Expandir cada interação num diagrama separado melhora a clareza, mantendo cada esquema simples e organizado, e deixa espaço suficiente para experimentar diferentes opções.

Adicionámos a autenticação do número de conta e do PIN numa nota, em vez de num diagrama de caso de uso, porque o utilizador do ATM não é o agente que executa essa etapa. Com base na experiência real com ATMs, podemos supor (já que ainda não analisámos o código) que um levantamento será cancelado se o valor solicitado for superior ao saldo da conta. No entanto, a comparação entre o valor do levantamento e o saldo da conta não é realizada pelo utilizador, pelo que essa atividade também não é representada num diagrama de caso de uso.

A seta dentro do caso de uso "Retirar Dinheiro" indica um hiperligação. O UModel permite que você associe uma ou mais hiperligações a qualquer elemento nos seus diagramas. Uma hiperligação pode referenciar uma URL, um ficheiro externo ou outro diagrama. A caixa de diálogo de hiperligações permite até mesmo definir um texto de apoio para as suas hiperligações.

Se definir mais de um hiperligação, o texto de apoio transformará-se num menu de seleção que aparece numa janela pop-up. Suponhamos que nos foi atribuída a tarefa de modificar a simulação existente de um ATM para cobrar uma taxa por cada levantamento. Se o valor do levantamento for inferior a 100 dólares, a taxa será de 2 dólares. Se o valor do levantamento for de 100 dólares ou mais, a taxa será de 4 dólares. Como o ATM não tem notas de um dólar, a taxa deve ser cobrada diretamente na conta, e não deduzida do valor em dinheiro levantado. A taxa será informada antes de qualquer dinheiro ser dispensado, e o utilizador poderá cancelar a transação. Podemos adicionar este novo requisito ao nosso diagrama de casos de utilização "Levantamento de ATM".

Alterámos a cor do oval que representa o caso de utilização "Aprovar taxa" para indicar que esta é uma funcionalidade planeada que ainda não foi implementada. Alguns programadores argumentariam que a nota associada ao oval "Aprovar taxa" é redundante, uma vez que a notação "include" já indica que "Aprovar taxa" é um componente essencial do processo de "Retirar dinheiro". No entanto, muitas pessoas estão confusas sobre a diferença entre "include" e "extend", e é melhor ser absolutamente claro. Também podemos aproveitar a funcionalidade de "Camadas" do UModel para colocar todos os elementos relacionados com a nova funcionalidade numa camada separada.

Agora, a janela de ajuda "Camadas" permite-nos mostrar ou ocultar a funcionalidade planeada na nossa visualização do diagrama.

A experiência real com os caixas automáticos demonstra que uma transação está ausente na simulação existente. O menu de transações não oferece a opção de transferir fundos entre contas. Com base nos diagramas que já criámos, podemos constatar que o design original da aplicação tornará a implementação de uma operação de transferência difícil. O acesso do utilizador é baseado no número da conta, e parece que a aplicação existente não compreende o conceito de um cliente bancário que possui tanto uma conta corrente como uma conta poupança. Se o nosso gestor solicitar a funcionalidade de transferência de fundos, teremos de conversar com o arquiteto de software empresarial da nossa empresa. Será necessário implementar um identificador de utilizador associado a várias contas, não só na nossa aplicação de simulação de caixas automáticos, mas também na base de dados do banco.

The Prémio Jolt, galardoado Altova MissionKit para Arquitetos de Sistemas Empresariais É uma coleção de oito ferramentas em XML, bases de dados e UML, destinada ao arquiteto de software empresarial que possa necessitar de ferramentas de modelagem UML e de gestão de bases de dados, além de funcionalidades avançadas em XML, serviços web e integração de dados.

Clique aqui para descarregar uma versão de avaliação totalmente funcional com duração de 30 dias. No próximo artigo, analisaremos a simulação de caixas automáticos (ATMs) sob uma perspetiva completamente diferente, enquanto nos preparamos para explorar o código.