Introdução a modelagem utilizando UML

Este artigo visa auxliar estudantes e profissionais nos conceitos básicos de modelagem utilizando UML.

por Helbert Carvalho Tiago

                Entre os anos 80 e 90 haviam muitos conflitos na definição de nomenclatura na área de modelagem. A escolha de padrões era feito a gosto pessoal do que por fatores técnicos. Com isso os três nomes mais respeitados nessa área, cada qual com seus conceitos, Ivar Jacobson, Grand Booch e James Rumbaugh decidiram criar um modelo único que veio a ser UML. A UML seria como uma planta para construção do seu sistema.

                Os conceitos a serem apresentados neste artigo serão em cima de um sistema de caixa eletrônico, um exemplo clássico encontrados em livros de tecnologia como os publicados pela Deitel & Associates entre outros.

                Suponha que o seu cliente dono de um banco te faça a seguinte solicitação:

                “Necessito de um sistema para caixa eletrônico onde possa ser permitido ao cliente realizar quatro operações: consultar saldo, solicitar extrato, depositar e sacar. Esse mesmo caixa deve ser abastecido de dinheiro e ter os depósitos recolhidos pelo funcionário do banco.”

                Para definição do modelo do nosso sistema iremos utilizar primeiro o Diagrama de casos de uso.

Ø Devemos descrever os requisitos funcionais do sistema de maneira uniforme para usuários e desenvolvedores;

Ø Descrever de forma clara e consistente as responsabilidades a serem cumpridas pelo sistema formando a base para a fase de projeto;

Ø Oferecer as possíveis situações do mundo real para a fase de testes do sistema.

Os elementos básicos de um diagrama de caso de uso são: ator, caso de uso, interação do sistema.

Um ator é uma entidade externa ao sistema que de alguma forma participa do caso de uso.  Um ator pode ser um ser humano, máquinas, dispositivos ou outros sistemas. Atores típicos são: cliente, usuário, gerente, computador, impressora e etc. Os atores representam um papel e iniciam um caso de uso que após executado retorna um valor para o ator.

        No nosso caso de uso a ser implementado do nosso sistema de caixa eletrônico, os atores representam os clientes e funcionários do banco. O cliente interage com os casos de uso consulta saldo, solicita extrato, depósito e saque. O funcionário interage com os casos de uso: abastecer dinheiro e recolher depósitos.

        Para melhorar o entendimento do diagrama de caso de uso é necessária a descrição textual do caso de uso (principal e alternativo) e do cenário ou cenários que o compõe.

        Após descrição textual de todos os casos de uso e seus respectivos cenários, nossa documentação envolvendo caso de uso esta completa.

Caso de uso: Solicitação de extrato

1) Descrição textual do fluxo principal do use case solicitação de extrato

Este caso de uso inicia-se quando o cliente escolhe a opção extrato após passar o cartão no caixa eletrônico e ter a sua conta validada. Após a validação da conta o sistema pede ao cliente para escolher dentre as opções:

ü Extrato rápido: O subfluxo A1 (imprimir extrato rápido é executado)

ü Extrato no período: o subfluxo A2 (imprimir extrato no período é executado)

ü Sair: o caso de uso é encerrado, o sistema volta á tela principal e solicita que o cliente passe o cartão.

2) Descrição textual dos subfluxos alternativos associados a este use case

A1 – Imprimir extrato rápido

                O sistema solicita que o cliente entre com a senha para autorizar a impressão do extrato (o subfluxo B1 – solicitar e validar senha alfabética é executado). Caso a senha seja validada a conta do cliente é consultada e o extrato é impresso (o subfluxo B2 – Imprimir extrato é executado). O sistema volta á tela principal e solicita que o cliente passe o cartão.

A2 – Imprimir extrato no período

                O sistema solicita que o cliente informe a data inicial e final para impressão do extrato. Em seguida o sistema solicita que o cliente entre com a senha para autorizar a impressão do extrato (o subfluxo B1 – Solicitar e validar senha alfabética é executado). Caso a senha seja validada a conta do cliente é consultada de acordo com o período, o extrato é impresso (o subfluxo B2 – Imprimir extrato é executado). O sistema volta á tela principal e solicita que o cliente passe o cartão.

B1 – Solicitar e validar senha alfabética

                O sistema solicita que a senha do cartão seja digitada, caso a senha não seja validada, o sistema informa na tela e pede mais uma tentativa. O sistema verifica a quantidade de erros de validação da senha ocorridos no dia e informa que após 3 tentativas erradas o cartão do cliente será bloqueado e informa o número de tentativas que o cliente dispõe. O cliente pode sair da operação e voltar para a tela inicial e tentar novamente. Caso a senha seja validada a operação prossegue. Caso contrário após três tentativas o cartão do cliente é bloqueado.

B2 – Imprimir extrato

                O sistema verifica se a impressora do caixa eletrônico esta ativa e se a mesma possui papel. Caso apresente falha em um dos problemas citados, o sistema mostra uma mensagem ao cliente solicitando que o mesmo realize operação em outro equipamento e volta para a tela inicial e avisa do erro sempre que uma operação que envolva impressão seja solicitada. Caso contrário o conteúdo solicitado para impressão é impresso.

3) Cenário primário

José dirige se ao caixa eletrônico e passa o cartão na máquina. O sistema após validar a conta exibe as opções disponíveis. José seleciona opção de solicitação de extrato. Em seguida José seleciona opção de extrato por período. Informa a data inicial e final. O sistema solicita a senha a José. Após José digitar a senha e confirmar a operação o sistema valida a senha, consulta a conta de José e imprime o extrato de movimentação da conta no período selecionado.

4) Cenário secundário

O sistema, ao verificar os requisitos para impressão, retorna que a impressora estava sem papel.

José, após ser informado do problema, dirige se a outro caixa eletrônico e inicia novamente a operação.

O segundo diagrama a ser utilizado para solução do problema é o diagrama de classes. Este diagrama contém as classes que caracterizam os objetos do nosso sistema. As classes são extraídas a partir da análise do diagrama de caso de uso e representam os componentes de interação do nosso sistema e como eles se relacionam. Vamos implementar um diagrama de casos de uso implementado com a definição das classes Cliente, ContaBancaria e lançamento da conta.

Uma classe é representada por um retângulo solido com três partes: a primeira para o nome da classe, outra para atributos da classe (que podem ser vistas como características da classe) e a terceira para a declaração das operações definidas para a classe.

Através da classe Cliente implementada no diagrama anterior, nos definimos as características do nosso cliente (neste caso um identificador e um nome que representa os atributos da classe),seu relacionamento com a classe conta bancária que é de 1 para muitos (isto representa a cardinalidade de relacionamento) e definimos uma operação realizada pela classe que é ObterContaBancaria(). A mesma análise deve ser feita para a classe ContaBancaria e LançamentoConta. Com esse diagrama já podemos identificar elementos que existirão no nosso sistema, suas características e expressões. Essas definições estão contidas na classe. Essas classes tornam se reais em nosso sistema quando são manipuladas por ele e a partir daí, são conhecidas como objetos, pois suas características passam a ter um valor e eles começam a interagir com outros objetos das classes relacionadas.