Este documento apresenta um curso básico sobre a linguagem de modelagem UML (Unified Modeling Language). Ele discute os principais diagramas da UML, incluindo casos de uso, sequência, atividades e classes, além de apresentar um estudo de caso e a ferramenta MS Visio para modelagem.

1. CURSO BÁSICO DE UML
(UNIFIED MODELING LANGUAGE)
Autor: João Carlos da Silva Jr
17/06/2002

2. Conteúdo do curso
1. Introdução
2. Uso da UML
3. Diagramas
a. Use Case
b. Sequência
c. Atividades
d. Classes
4. Ferramenta MS-VISIO
5. Estudo de caso / Diagramas
6. Conclusões

3. 1. Introdução
Pode-se dizer que a UML surgiu para resolver um grande problema no
desenvolvimento de software, a falta de uma notação padronizada e eficaz que
abranja qualquer tipo de aplicação. Cada simbologia existente possui seus
próprios conceitos, gráficos e terminologias resultando em uma grande confusão.
A UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar
Jacobson que são conhecidos como "os três amigos". Eles possuem um extenso
conhecimento na área de modelagem orientado a objetos já que as três mais
conceituadas metodologias de modelagem orientado a objetos foram eles que
desenvolveram e a UML é a junção do que havia de melhor nestas três
metodologias adicionado novos conceitos e visões da linguagem.
Vale a pena dizer que a UML é muito mais que a padronização de uma
notação, é o desenvolvimento de novos conceitos. Por essa razão entender UML
não é apenas aprender a ler uma simbologia, mas significa aprender a modelar
orientado a objetos.
A idéia deste curso é capacitar as pessoas a conhecer a notação UML,
assimilar alguns conceitos importantes na modelagem orientada a objetos,
aprender a “ 1 os diagramas e conhecer uma das inúmeras ferramentas de
ler”
modelagem de sistemas, no nosso curso será o Microsoft Visio.
Não é intuito deste curso ensinar como modelar sistemas de informação e
nem todos os diagramas e métodos da UML. Para esse tipo de aprendizado
aconselho um estudo mais detalhado através de livros especializados, alguns
estão citados na bibliografia.
1
Ler no sentido de saber identificar processos e regras de negócios. Ser capaz de identificar
atributos e funções.

4. 2. Uso da UML
A UML é utilizada em diversos tipos de sistemas, ela abrange todas as
fases desde a especificação de requisitos até a fase de testes.
Mas qual o objetivo da UML?
O objetivo da UML é descrever qualquer tipo de sistema, em termos de
diagramas orientado a objetos.
Vamos trabalhar em função de Sistemas de Informação2. É claro que pode-se
utilizar a UML para sistemas distribuidos, sistemas técnicos, sistemas real-time,
sistemas de negócios entre outros, ou seja, a UML suporta a modelagem de
qualquer tipo de sistema.
2
São sistemas os quais temos que armazenar, pesquisar, editar e mostrar informações para os
usuários. Manter grandes quantidades de dados com relacionamentos complexos, que são
guardados em bancos de dados relacionais ou orientados a objetos.

5. 3. Diagramas
a. Use Case
Por muitos anos as pessoas utilizavam interações para ajudá-las a
compreender o sistema, sempre de modo informal e nunca documentados.Até que
Ivar Jacobson conseguisse tornar os casos de uso como elemento primário no
desenvolvimento e no planejamento do projeto. Antes de explicar o que é
um caso de uso, é necessário entender o conceito de cenário.
Cenário é uma sequência de passos que descreve uma interação entre um
usuário e um sistema. Para melhor entedimento, vou descrever um cenário:
Compra via Internet
O cliente navega pelo site e adiciona itens desejados ao carrinho de
compras. Quando o cliente deseja finalizar a compra, descreve login/senha,
endereço de entrega, fornece as informações do cartão de crédito e confirma a
compra.
O sistema verifica a autorização do cartão de crédito, autoriza a compra e
envia um email informando ao cliente o status da compra.
Dizemos que esse cenário é uma alternativa que pode acontecer. Vale a
pena dizer, que a autorização do cartão pode falhar, o usuário pode não conseguir
logar-se no sistema. Desse modo temos cenário alternativos.
Isso quer dizer que um caso de uso, é um conjunto de cenários ligados por
um objetivo comum de um usuário.
Normalmente quando modelamos sistemas, definimos um caso de uso
principal e outros que serão os alternativos. No nosso exemplo, teriamos: Realizar
compra, como sendo o caso de uso bem-sucedido; Falha na autorização e Falha
na autentificação do usuário como os casos de uso alternativos.
Uma prática comum entre os analistas é descrever um cenário principal
como sendo uma sequencia de passos numerados e as alternativas como
variações naquela sequencia, como ilustrado na Figura 1-1.

6. COMPRA VIA WEB
1. O Cliente navega pelo site e seleciona itens a serem comprados
2. O Cliente vai para o check out
3. O Cliente preenche usuário e senha
4. O Cliente preenche formulário de entrega
5. O Sistema apresenta as informações sobre o pedido (Valor, Impostos, Frete)
6. O Cliente preenche as informações do Cartão de Crédito
7. O Sistema autoriza a venda
8. O Sistema confirma a venda
9. O Sistema envia confirmação para o cliente via email
Alternativa: FALHA NA AUTORIZAÇÃO
No item 7, o sistema falha na autorização da compra por crédito
Envia notificação para o cliente via email
Alternativa: FALHA NA AUTENTIFICAÇÃO
No item 3, o sistema recusa usuário e senha
Permite ao cliente submeter as informações por mais 2 vezes
Se ultrapassar limite bloquear conta
Figura 1-1: Exemplo de texto de Caso de Uso

7. Quando falamos de caso de uso, precisamos entender três conceitos que serão
vistos a seguir.
Ator: É um papel que um usuário desempenha em relação ao sistema. Um
ator pode desempenhar vários casos de uso; um caso de uso pode ter vários
atores. Os atores não precisam ser humanos, o ator pode ser um sistema externo
que necessita de alguma informação do sistema atual.
Associação entre Casos de Uso: Além das associações entre atores e
casos de uso, você pode ilustrar vários tipos de associações entre casos de uso.
Destacam-se três tipos de associações, que são:
Inclusão (USES) – Ocorre quando há uma parte do comportamento que é
semelhante em mais de um caso de uso. Ou seja, quando um caso de uso, “ usa”
o outro. Não pode ser usado se apenas um outro caso de uso o dispara. Nem
justifica o uso para modelar sequência.
Generalização – Quando tem um que é semelhante a outro, mas faz um
pouco mais.
Extensão (EXTENDS) – Quando você estiver descrevendo uma variação
em comportamento normal. Ou seja, um caso de uso, “ estende”o outro, quando o
segundo acrescenta novos comportamentos ao primeiro já modelado.
Apresentei diversos conceitos e não respondi uma pergunta essencial.
Quando devemos utilizar casos de uso?
Sempre. Definir casos de uso é uma tarefa básica na elaboração e
planejamento de sistemas. Uma maneria interessante de identificar casos de uso
é fazer uma modelagem conceitual com usuários.
Vale a pena dizer que casos de uso, representam uma visão externa do
sistema. Não espere nenhuma correlação entre eles e classes do sistema.
NOTAÇÃO:
Diagrama Use Case:
Um diagrama use case é composto:
Ator: é um papel que um usuário desempenha em relação ao sistema. O
nome do ator deve ser um sujeito
Linha de comunicação: Não é necessário identificar a comunicação entre
atores e casos de uso, mas é uma boa prática
Casos de uso: O nome do caso de uso deve ser um verbo que facilite a
identificação da funcionalidade do mesmo.
Veja o exemplo abaixo:

8. Sistema de Biblioteca - Para fins didáticos
Usuario
Pesquisando Livro
Emprestando
material
<<uses>> Cadastrando
Implica em Material
Gerente
Cadastrar usuário
Emprestando
Material

9. b. Sequência
O diagrama de sequência é uma ferramenta que deve ser utilizada sempre
em função dos casos de uso. Um diagrama de sequência captura o
comportamento de um único caso de uso, ou seja, mostra a interação entre os
objetos ao longo do tempo, apresentando os objetos que participam da
interação e a sequência das mensagens trocadas.
NOTAÇÃO:
O diagrama é composto por:
Objeto: É uma caixa na parte superior de uma linha tracejada verticalmente.
A linha vertical é chamada de linha da vida do objeto, e representa a vida do
objeto durante a interação.
Mensagem: É representada por uma flecha entre as linhas de vida de dois
objetos. Cada mensagem deve ter um nome, é comum incluir os argumentos e
algumas informações de controle.
Veja o exemplo abaixo:

10. c. Atividades
Utilizado para descrever a sequência de atividades, utilizando
comportamento condicional e paralelo. È composto por:
Início: Representado por um círculo preenchido.
Estado de Atividade ou Atividade: Representado por um retângulo com
bordas arredondadas. Atividade é um estado de estar fazendo algo.
Desvio(Branch): Representado por um losango.
Intercalação(Merge): Também representado por um losango, é utilizada
para marcar o final de um comportamento condicional iniciado por um desvio, ou
seja, tem múltiplas entradas e uma única saída.
Separação(Fork): Representado por um traço horizontal, quando temos
comportamento paralelo, ou seja, temos uma entrada e várias transições de saída
que são executadas em paralelo.
Junção(Joins): Representado por um traço horizontal, utilizamos para
completar a separação, ou seja, quando temos um processamento paralelo,
precisamos sincronizar.
Veja o exemplo abaixo:

11. d. Classes
Sem sombra de dúvidas, o diagrama mais importante da documentação,
onde podemos encontrar as informações sobre métodos, atributos, nome das
funções e como serão integradas. Um diagrama de classes bem modelado é
fundamental para auxiliar o desenvolvedor.
NOTAÇÃO:
Classe: No modelo de classe trabalhamos com um único elemento um
retângulo dividido em 3 partes, a primeira divisão é utilizada para o nome da
classe, a segunda divisão colocamos as informações de atributos e a última
divisão é utilizada para identificar os métodos. É importante apresentar o
conceito de instância, isto é, cada objeto é uma instância de sua classe. Cada
instância tem seus próprios valores de atributos, compartilha os nomes dos
atributos e os métodos com os outros objetos da mesma classe.
É importante entender a diferença entre classe e objeto(instância), veja
abaixo:
Outro conceito importante que temos que ver é o de estereótipos:
Estereótipo (s.m) – (2) Lugar comum, clichê, chavão.
Veremos agora, os estereótipos de uma classe, são eles:
Entidade ou Negócio (Entity): São classes de objetos que refletem
entidades do mundo real, ou seja, pertence ao domínio do problema.
Fronteira ou Interface (Boundary): São classes de objetos que permitem a
comunicação entre o mundo externo e o sistema.
Controle (Control): São classes que modelam a sequência de controle
específica de um caso de uso do sistema, ou seja, controlam a execução dos
eventos necessários para um caso de uso.
Com isso, temos que aprender “ Como identificar as classes?”
As classes de negócio são identificadas a partir das definições dos casos
de uso obtidos na fase de Especificação de requisitos. Vale a pena dizer, que é
comum encontrar as mesmas classes em diferentes funções no negócio.

12. No decorrer da modelagem, você encontrará a necessidade de associar as
classes, por exemplo:
Não podemos deixar da falar do conceito de HERANÇA. Usamos o
conceito de herança quando queremos representar uma classe “ filha” que
herda todas as características da classe “ , agregando alguns atributos que
pai”
são particulares. A Classificação não é trivial. Deve-se tomar muito cuidado.
Outro tipo de associação é a agregação. A agregação faz-se necessário
quando duas classes associadas tem um sentido próprio e separadas
continuam existindo como unidade autônoma, podendo até se associar com
outras instâncias. A agregação é representada por um losango sem
preenchimento. Imagine as seguintes classes (Telefone, Aparelho e
Assinante), podemos ilustrar a agregação entre a classe aparelho e telefone.
Duas classes indepententes, mas que juntas tem um sentido próprio.
É sabido que toda regra tem exceção e não seria diferente na UML. Existe
um caso particular de agregação, quando duas classes só possuem sentido
quando estão associadas. Chamamos esse tipo de associação com forte
depedência de composição.
Isto implica em se uma instância da classe deixar de existir, todas as outras
associadas por composição, deixarão de existir também. O símbolo que
representa a composição é um losango preenchido.
Veja o exemplo de composição:

13. Em resumo, o diagrama de classes é composto por objetos (instâncias),
que podem ser de negócios, interfaces ou de controle, e os mesmos são
associados por herança, agregação ou composição.

14. 4. A ferramenta MS-VISIO
O Microsoft VISIO é uma ferramenta para diagramação de sistemas de
tecnologia da informação. Essa ferramenta possui diversos modelos e suporta
diversas metodologias de desenvolvimento de software. A versão que utilizamos é
o VISIO2000 Professional.
Não é necessário explicar o funcionamento da ferramenta, toda ferramenta
de diagramação de sistemas, são intuitivas desde que o usuário conheça os
conceitos da metodologia UML.
Antes de iniciar o trabalho, abra um novo documento, escolha o software
UML. O MS VISIO irá preparar o ambiente para documentar UML. Os detalhes da
ferramenta, uso e dicas serão explicados durante o curso.

15. 5. Estudo de caso / Diagramas
A idéia deste treinamento é introduzir os principais conceitos da UML.
Espero que tenha conseguido atingir o objetivo. Uma ferramenta importante para
medir o aprendizado são os estudo de caso. Irei propor a seguir um estudo de
caso e diagramar o mesmo. Ao final deste tópico peço que vocês façam o mesmo.
Tente diagramar o estudo de caso. Certamente teremos diversas propostas para o
sistema.
O estudo de caso:
A Number One Idiomas é uma escola de inglês, localizada em São
Paulo/SP, atua no mercado desde 1985 com método próprio. Hoje a escola
está com 900 alunos na unidade SP. Com o sucesso do curso de inglês, a
escola começou a lecionar Espanhol e Alemão. Hoje, 2002, a Number One
está com 1600 alunos, com possibilidade de crescimento em função dos novos
cursos. A escola não utiliza sistema para controlar os alunos, apenas planilhas
e documentos, com o crescimento este tipo de controle está ficando difícil e
ineficaz.
A necessidade:
A Number One deseja um sistema de informação para controlar o cadastro
de alunos, manter controle de pagamentos, histórico de notas e faltas,
relatórios de aproveitamento dos alunos, relatórios de inadimplentes e de fácil
utilização.
Problemas:
Atualmente os dados dos alunos estão armazenados em fichas, o controle
de pagamento é feito por uma planilha do excel, existe outra planilha onde
estão registradas as notas/faltas. Existe apenas um funcionário responsável
pelas informações e o mesmo responde por outras funções dentro da escola.
A escola tem 4 equipamentos com a seguinte configuração:
Processador HD Memória RAM Sistema Operacional
486 4.2 GB 32MB Windows 95
486 4.2 GB 32MB Windows95
Pentium II 10 GB 64 MB Windows 98
Pentium III 40 GB 64MB Windows 98
A escola Number One está iniciando uma fase de franquias e está em
processo de abertura de duas unidades no interior de São Paulo. Devido ao
fato o cliente quer um sistema que permita o uso em rede.

16. O que espero?
Proposta de solução utilizando metodologia UML
- Diagrama use case
- Descrição dos use case
- Diagrama de sequência de um caso de uso
- Diagrama de atividades
- Diagrama de classes
Diagramas devem ser feitos com a ferramenta MS VISIO.
Tempo gasto para modelar cada diagrama.
Conclusões.

17. 7. Conclusões
Preparar este treinamento foi um desafio muito grande para mim. Fazer os
diagramas, entender a metodologia UML para mim tinha um significado. Mas
como transmitir o conhecimento adquirido com livros, universidade e vida
prática. É difícil sentar na frente de um editor de texto e começar a escrever, o
que é o seu trabalho? Como dever ser feito? Foi uma experiência que ajudou-
me a aprimorar os conceitos e o mais importante a possibilidade de agregar
novos valores.
Este curso básico foi elaborado em função das experiências que adquiri em
empresas anteriores e principalmente em função do projeto Banco1.net
O material utilizado como referência foi:
Apresentação “ Engenharia de Software” professor Ivan Granja, mestre da
,
PUC – Campinas
Livro UML Essencial, Kendall Scott, editora Bookman
Minha intenção com este treinamento foi capacitar desenvolvedores a
entender o que é UML, como ler documentações em UML, e introduzir os pré-
requisitos necessários para um aprendizado mais detalhado sobre a UML.
Espero que eu tenha conseguido de forma clara, expor os conceitos e técnicas
da modelagem UML. Gostaria de deixar claro que este treinamento engloba
apenas o básico da modelagem, existem outros diagramas e outras técnicas
que podem ser assimilados através de leitura especializada.
Estou a disposição para esclarecer dúvidas e maiores informações através
do email: joao@atenacriacao.com.br