Uma Introdução à UML

Resumo
A UML , Linguagem de Modelagem Unificada foi criada por Rambaugh, Booch e Jacobson, profissionais da área de sistemas e processos, que se
uniram com o objetivo de se criar um padrão para desenvolvimento de software que reunisse as melhores práticas de metodologia de sistemas.

Esta linguagem é aberta e pode ser utilizada para criar um modelo para se abstrair as fases de um projeto de criação de software. Neste modelo,
diversos diagramas auxiliam na visualização do problema e a concepção da solução, permitindo uma visão macro dos objetos e seus relacionamentos.

Grandes sistemas necessitam de uma série de especificações e geralmente tais documentos são longos e muito detalhados. A modelagem
proporcionada pela UML permite simplificar o entendimento de um sistema, ao transformar suas complexidades em objetos gráficos simples, onde a
lógica interna de seu funcionamento é abstraída.

Através da modelagem também conseguimos estruturar um sistema. A manutenção que ocorrer nos posteriores ciclos de desenvolvimento fica mais
fácil de ser efetuada já que a mesma ocorre inicialmente num nível lógico, e não no código (programa), de forma que se pode evoluir os diagramas que
serão alterados e verificar suas conseqüências, antes de se preocupar com a fase de desenvolvimento.

Algo que é interessante de se notar é que a UML é uma linguagem e não uma Metodologia. Em função de sua independência, a mesma pode ser
utilizada como ferramenta de apoio por diversas metodologias.

Documentação do Sistema
Este modelo pode ser utilizado para se discutir a visão do projeto de sistema com todos os envolvidos, desde os usuários-chave (e gerência) que irão
se beneficiar do sistema até os elementos da equipe de desenvolvimento (programadores, analistas, testadores, etc). Desta forma, o resultado final
deverá ser um conjunto de diagramas e documentos avaliados por toda a equipe e em conformidade com a necessidade dos stakeholders.

Um Controle de Versões poderá ser implementado, na medida em que se armazena (e identifica-se devidamente) os processos (e suas versões) e
suas funcionalidades. Estes elementos irão mudar na medida em que se verifica a manutenção do sistema, de forma que é necessário identificar a
versão dos mesmos.

* Tais itens (diagramas e documentos), requisitos (funcionais e não funcionais), documento visão e protótipos irão inicialmente compor a
Documentação do Sistema.

Estrutura Básica da UML

Neste artigo irei relacionar alguns dos itens que considero o básico na estrutura da UML. Será algo superficial para o leitor que queira ter uma primeira
noção do que é a UML, de forma que não irei me aprofundar muito nos detalhes. Colocarei também alguns exemplos de diagramas, de maneira que o
leitor possa fazer um comparativo analógico com explicação dada. Os diagramas que descreverei são:-

Descrição de Casos de Uso

Diagrama de Casos de Uso

Diagrama de Classes

Diagrama de Seqüência

Diagrama de Estados

Descrição de Casos de Uso

É uma descrição textual completa de um determinado processo, identificando seu cenário principal, isto é, o fluxo normal que
normalmente ocorreria. Este documento é estruturado descrevendo-se seus passos / instruções sem se ater a detalhes de tecnologia,
porém identificando o limite/restrição/faixa de dados. Além disto, aqui identificamos o (s) ator (es) que interage (m) com o sistema. As
exceções (fluxos / cenários alternativos) também são explicadas porém a ênfase é dada no fluxo principal.

O Ator pode ser entendido como um elemento externo que interage com o sistema. Geralmente simboliza um usuário de algum
departamento, mas também pode simbolizar outros elementos tais como um temporizador (relógio) que aciona o sistema de tempos em
tempos para realizar alguma ação ou sistemas externos que interagem com um determinado sistema.

Através da documentação do sistema, identificamos os atores, eventos e seus processos, de forma a eleger os possíveis Casos de Uso.
Exemplo:-

Nome do Caso de Uso Efetuar Login

Descrição Este caso de uso descreve a maneira pelo qual um usuário tem acesso ao sistema.
Ator Envolvido Usuário
Ativação Ocorre no momento em que o Usuário acessa o site.
Pré-Requisito Usuário deve estar cadastrado no sistema.
Ator Sistema
O usuário informa sua identificação (login) e senha. Caso o usuário deseje que num próximo
acesso o sistema apresente seu nome automaticamente, ele terá a opção de armazenar a sua
identificação. (EX01)
O sistema consiste se o usuário foi informado, se o mesmo está cadastrado, se a senha é válida
(é igual à cadastrada no sistema) e se o usuário não está com seu acesso ao sistema bloqueado
Interação entre Ator e Sistema (ver observações na próxima página). (EX02, EX03, EX04)
O sistema registra a data e hora do último acesso do usuário.
O Sistema exibe número de acessos efetuados pelo usuário, a data de seu último acesso e a
mensagem:= “Seja bem vindo(a) à Área Reservada”
O sistema memoriza a identificação (login) e tipo de usuário que pode ser Cliente, Operador do
Sistema, Departamento Financeiro ou Departamento Comercial.
Exceções EX01 O sistema apresenta automaticamente a identificação do usuário, caso tenha sido
configurado para isto.
EX02 O sistema verifica se a identificação está em branco e neste caso mostra a mensagem:-
“Campo Identificação em branco - Favor Informar”
EX03 Caso o sistema não consiga encontrar o usuário ou se a senha do mesmo estiver
incorreta, ele exibe a mensagem:-
“Identificação de Usuário ou Senha: Incorreto”
e em seguida o sistema registra a falha da tentativa de login.
EX04 Caso o usuário esteja bloqueado, o sistema exibe a mensagem
“Você está atualmente bloqueado – Favor entrar em contato com a
Administração.”
e em seguida ele registra a tentativa de acesso ao sistema.
Observações Bloqueado: Status do Usuário que faz com que ele não possa acessar o sistema. Este status
pode ser definido pelo Operador do Sistema, Depto Financeiro ou Depto Comercial, em função
das seguintes possibilidades:-

Dívida/Inadimplência do Cliente

Usuário demitido

Usuário temporariamente afastado (férias, licença, etc)

Outras eventualidades.

Diagrama de Casos de Uso

Modelo gráfico que agrupa determinados casos de usos e atores de um determinado sistema, de forma a visualizar-se de maneira rápida e fácil o
relacionamento entre eles, servindo de documento para comunicação entre os participantes do projeto.

O Ator, que representa o elemento externo ao sistema, associa-se ao caso de uso (representado pela figura oval).

Neste exemplo utilizei o conceito de generalização, que permite criar um supertipo, composto de subtipos de mesma função, de forma a criar o Ator
Usuário, e a partir dele associar os atores relacionados, de modo a facilitar o entendimento do diagrama. Verificamos neste exemplo que o Ator Cliente,
além de ter acesso aos casos de uso herdados pelo seu supertipo (Usuário), também tem acesso exclusivo ao Caso de Uso “Solicitar Cadastro de
Cliente”.
Diagrama de Classes
Através deste diagrama podemos verificar os objetos do sistema, seus atributos, métodos e
relações.

Atributo
Um atributo de um objeto é uma característica deste objeto. Se o objeto fosse um Pedido de
Venda, alguns de seus atributos seriam número do pedido, data da venda, código do cliente,
data de previsão de entrega, status, dentre outros.

Método
Um método é uma função que a classe realiza. Considerando o mesmo objeto (pedido de venda) como exemplo, alguns de seus métodos seriam
criar(), alterar(), excluir() , imprimir() e baixar().

Nome da Classe
atributo: tipo
+metodo()

Classe / Objeto
A Classe é a representação genérica de um objeto, contendo os tipos de informações que um objeto pode ter, além dos métodos que o objeto
executar.

Um objeto é uma instância (derivação / criação) de uma classe. Ele contém informações específicas que identificam um item específico no sistema.
Exemplo:-

CLASSE OBJETO
Pedido :Pedido
Numero: integer Numero: 1234
Venda: date Venda: 30/12/2005
Cliente: integer Cliente: 537
Previsão: date Previsão: 15/01/2006
Status: integer Status: 2
+Criar() +Criar()
+Alterar() +Alterar()
+Excluir() +Excluir()
+Imprimir() +Imprimir()
+Baixar() +Baixar()
Relacionamento / Associação
O conceito de associação ocorre quando uma classe relaciona-se com outra classe. Isto ocorre neste exemplo. Cada objeto instanciado da classe
ItensPedido refere-se a um objeto do tipo Produto.
ItensPedido Produto
-mantidos em
-produto : long -codigo : long
-quantidade : int -cadastro : Date
-precoUnitario : float 0..* 1 -estoque : long
+metodo() +metodo()

Composição
Classe

Classe Classe Classe

Um tipo de associação de agregação é a Composição, e podemos perceber isto através do exemplo abaixo. A classe Pedido tem suas informações
gerais (número do pedido, data do pedido, código do cliente, etc), bem como seus métodos. A classe ItensPedido contém os itens de um determinado
Pedido, com seus atributos (código do produto, quantidade pedida, precoUnitario), além de seus métodos específicos. Entretanto a existência de um
objeto do tipo ItensPedido está totalmente relacionada à existência de um objeto do tipo Pedido, ou a 1a. classe é composta dos itens da 2a. classe, de
forma que não tem sentido a existência de ItensPedido sem a existência de Pedido.

Note que o Diagrama de Classe não está prevendo o acesso aos dados, sendo comum na Fase de Projeto. Posteriormente, muitas informações serão
inseridas na fase de Desenvolvimento, dentre elas serão acrescidas as classes de acesso à dados.

Pedido
-numero : long
-data : Date
-cliente : long
+metodo()

0..*

ItensPedido
-produto : long
-quantidade : int
-precoUnitario : float
+metodo()

Herança
Quando uma determinada classe (sub-classe) herda os atributos e métodos da classe pai (super-classe). No exemplo abaixo, notamos a existência
das classes Poupança e Folha, que derivam da classe pai (Conta_Bancária), herdando seus atributos e métodos, mas que possuem atributos que lhe
são próprios.
 Conta Bancária
-numero : long
-banco : string
-agencia : string
-conta : string
-saldo : float
+depositar()
+sacar()
+consultar()

Poupança Folha
-vencimento : Date -funcionario : long

Diagrama de Seqüência
Utilizado para se verificar a seqüência dos passos de um determinado caso de uso, num determinado momento do sistema. Neste diagrama
verificamos a interatividade do ator e as mensagens ocorridas entre os objetos.

Ator: Usuário, interage com o sistema

Objeto TelaLogon: boundary, representa a fronteira entre o sistema e o usuário. Também chamado de interface.
Objeto CtrlLogin: control, representa a classe que gerencia a seqüência e controla as mensagens do sistema.
Objeto Usuário: entity: Entidade, representa a classe que retrata o objeto real, onde se recupera e armazena as informações necessárias ao sistema.

Linha Vertical: Representa a temporalidade da existência do objeto no diagrama, que ocorre enquanto houver interações entre os demais objetos.
Seta Horizontal com Flecha: Representa a mensagem trocada entre os objetos, podendo conter parâmetros.

Diagrama de Estados
O objetivo de um diagrama de estados é mostrar os possíveis estados de um objeto e os eventos que altera seu status. O estado de um objeto é o
resultado das operações deste objeto num determinado momento. Em geral, o objeto tem um estado inicial quando de sua criação, e em geral é
alterado pela ocorrência de um determinado evento. Após ser acionado, o objeto realiza uma ou mais operações de forma que seu estado muda para
uma outra condição. Num determinado momento o objeto tem o seu estado alterado para um estado final, que pode ocorrer em diversas
circunstâncias, indicando o fim das alternâncias de estado. Desta forma, através deste diagrama é possível visualizar os possíveis estados que um
objeto pode ter, de forma a se prever seu comportamento.

No exemplo a seguir, mostro os estados possíveis para um pedido, os eventos que modificam seu estado e seu estado final.

Para finalizar, aconselho aos usuários a criação de protótipos de telas e formulários, que serão baseados nas descrições de casos de uso e sua
funcionalidade se dará conforme os diagramas de seqüências criados.

Figura 1 – Protótipo de Tela de Login

Figura 2 – Protótipo de Tela de Entrada de Pedidos

Carlos Majer

Desenvolvedor (desde 1986)

Analista de Sistemas (desde 1988)
Pioneiro no uso da Internet participando do projeto experimental da Internet Brasileira de Abril a Dezembro de
1994.
Pioneiro na criação de software Shareware no Brasil (1994)
Tecnólogo e Professor da Universidade Cidade de São Paulo.

cmajer@uol.com.br