Um pouco da história da UML?
No final dos anos 80 e início dos anos 90, tínhamos muitos conflitos de definições e nomenclaturas na área de modelagem. A escolha para utilização de um determinado padrão era definido mais pelo “gosto” pessoal do que por fatores técnicos oferecidos. Então, os três mais respeitados nomes nesse campo, cada qual com seu conceito e implementação de modelo, Ivar Jacobson (OOSE – Object Oriented Software Engineering), Grady Booch (The Booch Method) and James Rumbaugh (OMT –Object Modeling Technique) decidiram por fim aos debates e trabalhar juntos na definição de um modelo único que veio a ser a UML.
A UML permite que você “desenhe” uma “planta” do seu sistema. A comparação ideal é a de um construtor que vai realizar um projeto sem antes ter toda a planta que defina estrutura a ser construída. A experiência do construtor garante, até certo ponto, o sucesso do projeto. Mas, com certeza, uma vez feito o planejamento, o “cálculo estrutural”, o desenho da planta, a garantia de sucesso antes, durante e depois da efetivação da construção é incomparavelmente maior. O mesmo acontece com um projeto de software.
A experiência do desenvolvedor ou analista, não pode substituir a necessidade de um projeto que defina uma “planta” da solução como um todo. Esta “planta” garante, em todas as fases do projeto, seja na definição, desenvolvimento, homologação, distribuição, utilização e manutenção do mesmo, uma maior clareza e objetividade para execução de cada ação, e, com certeza, quanto maior a solução, maior a necessidade de um projeto definido adequadamente. Desta forma, a UML é uma linguagem padrão para visualização, especificação, construção e documentação de um aplicativo ou projeto de software, e objetiva aumentar a produtividade, otimizar as etapas que envolvem o desenvolvimento de um sistema, aumentando assim a qualidade do produto a ser implementado. Ela independe da ferramenta em que o aplicativo será desenvolvido. A idéia e prover uma visão lógica de todo o processo de forma a facilitar a implementação física do mesmo.
A UML disponibiliza, através de conceitos, objetos, símbolos e diagramas, uma forma simples, mas objetiva e funcional, de documentação e entendimento de um sistema. Você pode utilizar os diagramas e arquivos que compõe um modelo UML para o desenvolvimento, apresentação, treinamento e manutenção durante todo o ciclo de vida da sua aplicação. Ela é mais completa que outras metodologias empregadas para a modelagem de dados pois, tem em seu conjunto todos os recursos necessários para suprir as necessidade de todas as etapas que compõe um projeto, desde a definição, implementação, criação do modelo de banco de dados, distribuição, enfim, proporcionando sem qualquer outra ferramenta ou metodologia adicional, um total controle do projeto.
A UML implementa uma modelagem com uma visão orientada a objetos. Através dela podemos definir as classes que compõe a nossa solução, seu atributos, métodos e como elas interagem entre si. Apesar da UML ter como base a orientação a objetos, não significa que a ferramenta e a linguagem utilizada para a implementação do modelo seja também orientada a objetos, embora seja recomendável. Este artigo não irá explorar os conceitos de orientação a objetos, e sim a implementação de um modelo UML simples, para início da documentação de um sistema, utilizando dois diagramas implementados pela UML que são o “Diagrama de Casos e Uso” e o “Diagrama de Classes”.
Os diagramas têm como objetivo representar, através de um conjunto de elementos, como o sistema irá funcionar e como cada peça do sistema ira trabalhar e interagir com as outras. Outra vantagem vem da facilidade de leitura dos diagramas que compõe a UML, além da facilidade de confeccioná-los, pois existem inúmeras ferramentas para modelagem de dados orientados a objetos (ferramentas Case), dentre elas o Rational Rose, o Model Maker, e o Poseidom UML. Além dos diagramas citados a UML disponibiliza outros diagramas, dentre os quais podemos citar o Diagrama de Objetos, Diagrama de Seqüência, Diagrama de Colaboração, Diagrama de Estado, Diagrama de Atividade e Diagrama de Componentes.
Entendendo UML a partir de um exemplo prático
Utilizaremos o Poseidon UML para implementar o modelo do exemplo. O Poseidon UML é uma ferramenta case que suporta os principais diagramas UML e é desenvolvido em Java. Tem algumas facilidades no que se refere a interação com o Java podendo, a partir de um modelo gerar o código Java das classes definidas no mesmo e também suporta a Engenharia Reversa, que é gerar o modelo a partir das classes implementadas. O Poseidon tem sua versão free e pode ser baixado em www.gentleware.com.
O modelo aqui proposto começa a ser implementado a partir de um problema real que é a necessidade de um cliente. O problema proposto é o seguinte:
“Desenvolver um sistema para um caixa eletrônico onde é permitido a um cliente realizar quatro tipos de operações: a de consulta de saldo, solicitação de extrato, depósito e saque. Esse mesmo caixa eletrônico deve ser abastecido de dinheiro e ter os depósitos recolhidos por um funcionário do banco”
Para definição do modelo do nosso sistema, iremos implementar primeiro um Diagrama de Casos de Uso ou Use Cases. Os objetivos principais de um diagrama de Casos de Uso são:
- 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 e sistema, todos ilustrados na Figura 1.
Um ator é uma entidade externa ao sistema que de alguma forma participa de um 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, etc. Os atores representam um papel e iniciam um caso de uso que após executado, retorna um valor para o ator. Um caso de uso especifica um serviço que será executado ao usuário e é composto por um ou mais cenários. Um cenário é uma narrativa de uma parte do comportamento global do sistema. Para o problema proposto, o Diagrama de Casos de Uso pode ser implementado como mostrado na Figura 2.
No Diagrama de Casos de Uso implementado o sistema é o Caixa Eletrônico, os atores representam o Cliente e o Funcionário do banco. O Cliente interage com os Casos de Uso consulta de saldo, solicitação de extrato, depósito e saque e o Funcionário interage com os Casos de Uso Abastece de dinheiro e Recolher envelopes de depósitos.
Para melhor entendimento do Diagrama de Casos de Uso é necessária a descrição textual do fluxo do Caso de Uso (principal e alternativo) e do Cenário ou dos Cenários que compõe cada Caso de Uso. Iremos descrever o Use Case Solicitação de Extrato bem como o Cenário que o compõe.
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 de saldo:
- 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 a tela principal e solicita que o cliente passe o cartão.
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 de 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 a 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 pra 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 de senha alfabética - é executado). Caso a senha seja validada a conta do cliente é consultada de acordo com o período e o extrato é impresso (o subfluxo B2 – Imprimir Extrato - É executado). O sistema volta a tela principal e solicita que o cliente passe o cartão.
B1) Solicitar e Validar de senha alfabética
O sistema solicita que a senha do cartão seja digitada. Consulta a conta do cliente validando a senha digitada. Caso a senha não seja válida o sistema informa na tela e pede mais uma tentativa. O sistema verifica a quantidade de erros de validação de 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 ainda dispõe. O Cliente pode sair da operação e voltar para a tela inicial, ou tentar novamente. Caso a senha seja válida, 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 está ativa e se a mesma possui papel. Caso apresente um dos problemas citados, o sistema mostra uma mensagem solicitando que o cliente realiza a operação em outro caixa eletrônico e volta para a tela inicial e avisa do erro sempre que uma operação que envolva impressão for solicitada. Caso contrário, o conteúdo solicitado para impressão é impresso.
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 a opção de Solicitação de Extrato. Em seguida José seleciona a opção de Extrato no 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.
Cenário Secundário
O Sistema, ao verificar os requisitos para impressão, retornou que a impressora estava sem papel. José, após ser informado do problema pelo sistema, dirigi-se a outro caixa eletrônico e inicia novamente a operação.
Após a descrição textual de todos os Casos de Uso e respectivos Cenário, nossa documentação envolvendo o Diagrama de Casos de Uso está completa.
O segundo diagrama a ser utilizado para solução do problema proposto é 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 Casos de Uso e representam os componentes de interação do nosso sistema e como eles se relacionam. Vamos implementar um Diagrama de Classe, a partir do Diagrama de Casos e Uso implementado, com a definição das classes Cliente, ContaBancaria e Lançamentos da Conta. (Vide Figura )
Uma classe é representada por um retângulo sólido com três partes: a primeira para o nome da classe; outra para os atributos da classe ( que podem ser vistos como características da classe); e a terceira para a declaração das operações definidas para a classe. A Figura 3 mostra a notação UML para classes.
Através da classe Cliente implementada no diagrama da Figura 4, nós definimos as características do nosso cliente (neste caso um Identificador e um Nome que representam os atributos da classe), seu relacionamento com a classe ContaBancaria que é de 1 para muitos ( isto representa a cardinalidade do relacionamento ) e definimos uma operação realizada pela classe que é ObterContaBancaria(). A mesma análise deve ser feita para a classe ContaBancaria e LancamentoConta.
Com esse diagrama, já podemos identificar elementos que existirão em nosso sistema, suas carcterísticas e operações. Essas definições estão contidas nas classes. Essas classes tornam-se reais em nosso sistema a 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 elas começam a interagir com outros objetos das classes relacionadas.
O que entender da UML
A UML se mostra como parte essencial no “ciclo de vida” de uma aplicação. Foi mostrado, utilizando apenas dois diagramas, toda a funcionalidade operacional de um sistema bem como a definição de elementos internos referentes ao desenvolvimento do mesmo. Esses dois diagramas fazem parte da documentação do sistema, e podem ser utilizados para uma apresentação da solução para o requisitante antes da implementação da mesma, visualização dos processos que o sistema irá disponibilizar, definição de elementos inerentes ao desenvolvimento como estrutura de telas, procedimentos operacionais, referência para criação de objetos de persistência em um banco de dados, etc.
Existem outros elementos a explorar, outros diagramas, outros tipos de relacionamentos e documentação, mas este foi um passo inicial para conhecer todos os recursos que a UML disponibiliza e aumentar a qualidade do desenvolvimento de nossas aplicações.
Esse artigo faz parte da revista SQL Magazine edição 01.
