Trata-se da análise e criação de diagramas UML de um sistema bancário simples de forma incremental, dividido nos módulos de validação e sistema bancário propriamente dito, buscando eliminar os problemas de coesão que possam existir.
Para que serve:
O tema tratado serve para mostrar ao leitor como elaborar diagramas UML que satisfaçam os requisitos do sistema, além de resolver os problemas de coesão definidos por Page-Jones [2], que eventualmente sejam identificados durante a modelagem.
Em que situação o tema é útil:
O artigo é útil para analistas e desenvolvedores que buscam desenvolver software de qualidade e com alto grau de reusabilidade, utilizando a UML como ferramenta de análise e projeto, independente do processo de software adotado.
Resumo DevMan:
Neste artigo, construiremos diagramas de casos de uso, de atividades e de classes para modelarmos um sistema bancário simples. De maneira a facilitar o processo, o sistema foi dividido em dois módulos: o módulo de validação do cliente e o sistema bancário propriamente dito. Focaremos nosso estudo no desenvolvimento de modelos que satisfaçam todos os requisitos e solucionem os três problemas de coesão existentes.
Para tal, desenvolveremos os diagramas – de classe, principalmente –
de forma incremental para estudarmos cada tipo de problema de coesão. E para
cada um dos problemas de coesão, mostraremos uma maneira de solucioná-lo.
Autores: Carlos Araújo e Celso André Rodrigues de Souza
Vimos nos artigos anteriores os conceitos básicos sobre os principais diagramas UML e sobre o paradigma orientado a objetos. Neste artigo, colocaremos em prática os conceitos já estudados, visando à elaboração de um modelo para simular um sistema bancário que utiliza um sistema de validação de usuário. A ideia principal desta última parte do artigo é mostrar como pensar durante a elaboração de um modelo de software e não apenas mostrar o modelo pronto. Mas antes de iniciar a elaboração dos diagramas precisamos fazer algumas considerações.
É um erro pensar que um simples conjunto de diagramas forma o modelo de um sistema. Modelar em UML não se resume apenas em criar diagramas, mas sim em entender o sistema como um modelo. Os diagramas são apenas janelas neste modelo, como afirmam Miles e Hamilton [1]. Podemos afirmar também que o diagrama não é o modelo, e sim apenas uma maneira de apresentar pequenas partes do que o seu modelo contém.
Segundo Martin Fowler as pessoas tendem a usar a UML de três maneiras: como um esboço para descrever pontos chaves; como um projeto que apresenta especificações detalhadas de um sistema ou; como uma linguagem de programação, que gera código executável a partir do modelo. De qualquer forma, o uso de uma dessas maneiras é influenciado pelo processo de desenvolvimento que é adotado. Por exemplo, se for usado um processo iterativo – tal como o Processo Unificado – o uso da UML vai do esboço ao projeto. Mas se a opção é por uma metodologia ágil, então a utilização da UML como esboço é predominante.
As considerações anteriores são importantes para afirmar que o que será apresentado aqui não foi necessariamente baseado em um processo de desenvolvimento de software. Apenas tentaremos apresentar um modelo que facilita o entendimento do sistema, talvez tendendo mais para um esboço do que propriamente para um projeto.
Para a criação do nosso modelo, utilizaremos os diagramas de casos de uso, de atividades e de classes. Durante a elaboração do diagrama de classes, mostraremos como resolver os problemas de coesão descritos por Page-Jones [2]. Tais problemas serão descritos na seção que mostra a criação do diagrama de classes.
Sistema de validação de usuário
O sistema de validação de usuário serve para averiguar a identidade do cliente. Esse sistema de validação é baseado no sistema de verificação de senhas ilustrado no artigo anterior desta série. Antes de criar os diagramas, é necessário especificar os seguintes requisitos para esse sistema de validação de usuário:
...
