Modelagem de software com UML

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.

De que se trata o artigo:

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." [...] continue lendo...

Artigos relacionados