UML - Unified Modeling Language

Importância da Modelagem
• Um modelo é uma simplificação da realidade
• Construímos modelos para compreender melhor o sistema que estamos desenvolvendo
• Objetivos alcançados com a modelagem
o Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja
o Os modelos permitem especificar a estrutura ou o comportamento de um sistema
o Os modelos proporcionam um guia para a construção do sistema
o Os modelos documentam as decisões tomadas.
• Construímos modelos de sistemas complexos porque não é possível compreendê-los em
sua totalidade

Princípios da Modelagem
• A escolha dos modelos a serem criados tem profunda influência sobre a maneira como um
determinado problema é atacado e como uma solução é definida
• Cada modelo poderá ser expresso em diferentes níveis de precisão
• Os melhores modelos estão relacionados à realidade
• Nenhum modelo único é suficiente. Qualquer sistema não-trivial será melhor investigado
por meio de um pequeno conjunto de modelos quase independentes

1
UML - Linguagem Unificada de Modelagem (Unified Modeling Language)
A UML é uma linguagem de modelagem com as seguintes características:
• Absorveu influências de outras técnicas de modelagem :
o Diagrama de Entidade e Relacionamento - DER
o Modelagem de Negócio - WorkFlow
o Modelagem de Objetos e Componentes
• Incorporou idéias de diversos autores :
o Peter Coad, Derek Coleman, Ed Yourdon,...
• Criada a partir de outras ferramentas de modelagem
o Booch´93
o OMT-2
o OOSE
• Linguagem-padrão para a elaboração da estrutura de projetos de software.
• Enfoque Orientado a Objetos
• Utilizada para Visualizar, Especificar, Construir e Documentar artefatos que modelem sistemas de software.
• UML é apenas uma linguagem de modelagem, não uma metodologia para desenvolvimento de sistemas.
• Baseada em Diagramas (Ênfase Visual), onde vários aspectos fundamentais na modelagem de Sistemas são
abordados, tais como : Funcional (estrutura estática e interação dinâmica), não funcional (tempo de
processamento, confiabilidade, produção) e organizacional (organização do trabalho, mapeamento e código).
Cada visão é descrita em um número de diagramas que contém informações enfatizando um aspecto em
particular. Analisando o Sistema através de visões diferentes, é possível se concentrar em um aspecto de
cada vez.

2
Diagramas da UML
• Casos de uso (Use Cases) : Modelam o comportamento geral do Sistema, através dos relacionamentos com
atores externos.
• Classes : Modela classes, interfaces e seus relacionamento, representando uma visão estática da estrutura
do Sistema.
• Interação : modelam uma especificação comportamental representando a troca de mensagens entre objetos,
em UML os Diagramas de Interação são representados por Diagrama de Sequência e Diagrama de
Colaboração.
o Sequência : modela a interação entre objetos através de seus relacionamentos e troca de
mensagens. Demonstram a dinâmica do Sistema com ênfase na ordenação temporal das mensagens.
o Colaboração : Semelhante ao diagrama de Sequência, sendo que sem observar a ordenação
temporal das mensagens.
• Estados : Modela uma máquina de estados, formado por : estados, transições e eventos
• Atividades : Tipo especial de Diagrama de Gráfico de Estado
• Diagramas de Implementação : Modelam a arquitetura lógica e física do hardware e software que
implementam o Sistema.
o Componentes : Exibe a organização e dependências existentes em um conjunto de componentes do
Sistemas (Programas fontes, objetos, executáveis e bibliotecas)
o Implantação : Mostra a configuração dos nós de processamento em tempo de execução e os
componentes neles existentes.

3
Casos de Uso (Use Cases)
Um caso de uso é um documento narrativo que descreve a sequência de eventos de um ator (agente externo) que
usa um Sistema para completar um processo[Jacobson92]. Eles são histórias ou casos de utilização de um Sistema.
Casos de uso não são exatamente especificações de requisitos ou especificações funcional, mas ilustram e implicam
requisitos na história que eles contam.

Figura (CasoDeUso)

Caso de Uso Comprar Itens

Atores Cliente, Caixa
Descrição Um Cliente chega a um ponto de pagamento, com vários itens que deseja comprar. O Caixa
registra os itens de compra, informa o total da compra ao cliente e recebe o pagamento.

Os detalhes dos casos de uso não são formalizados pela UML e podem ser adequados para satisfazer as
necessidades e o espírito de documentação necessários (clareza de comunicação).
Os casos de uso podem ser detalhados através de uma Sequência Típica de Eventos

Sequência Típica de Eventos

Ação do Ator Resposta do Sistema
1. Este caso de uso começa quando um Cliente chega a um
ponto de pagamento (Equipado com um Post) com vários
itens que deseja comprar.
2. O Caixa registra o código de cada item 3. Determina o preço do item e acrescenta a
Se houve mais de um exemplar do mesmo item, o Caixa informação sobre o item à transação corrente de
também pode entrar a quantidade venda.
4. Ao término da entrada de itens, o Caixa indica ao POST 5. Calcula e apresenta o total da venda
que a entrada de itens está completa
6. O Caixa informa ao Cliente o total da compra
7. O Cliente dá um pagamento em dinheiro, possivelmente
maior que o total da venda
8. O Caixa registra o montante de dinheiro recebido 9. Exibe o valor do troco a ser devolvido ao Cliente
10. O Caixa deposita o dinheiro recebido e retira o troco 11. Registra a venda completada
12. O Cliente sai com os itens comprados

4
Diagrama de Casos de Uso
Fornecem a visão externa do Sistema e suas interações com o mundo exterior, representando um visão de alto nível
de funcionalidade intencional mediante o recebimento de um tipo de requisição de usuário, ou seja modela o
comportamento geral do Sistema. O Sistema é visto como uma caixa preta, onde nesse momento não é importante
compreender como o sistema implementa os casos de uso ou como ocorre o funcionamento interno.
O propósito primário dos casos de uso são :
• Descrever os requerimentos funcionais do sistema de maneira consensual entre usuários e
desenvolvedores de sistemas;
• Fornecer uma descrição consistente e clara sobre as responsabilidades que devem ser
implementadas pelo Sistema, além de formar a base para a fase de desenho;
• Oferecer as possíveis situações do mundo real para o teste do Sistema.
Os elementos básicos de um caso de uso são:
• Ator : entidade externa ao sistema que, de alguma maneira, participa da história do caso de uso;
• Caso de uso
• Interação : O ator comunica-se com o sistema através do envio e recebimento de mensagens, sendo
que um caso de uso é sempre iniciado a partir do momento que um ator envia sua mensagem (estímulo);
• Sistema : Domínio do problema modelado.

Arquivo Rose CursoDeUML\DiagramaDeCasoDeUso\DiagramaDeCasoDeUso.mdl

Elementos Básicos
Interação

Ca so de Uso
Ator

Caixa Eletrônico

Login

Consultar de Saldo
Cliente_

Solicitação de extrato

Saque

5
 Venda

Com prar Itens

Reembolsar itens comprados

Caixa Cliente

Log in

Iniciar

Gerente

Gerenciar Usuários

6
Diagrama de Classes
São os diagramas mais importantes na modelagem orientada a objetos e representam a essência da UML. Um
diagrama de classe mostra um conjunto de classes, interfaces, colaborações e seus relacionamentos, fornecendo
uma visão estática do Sistema. Os diagramas de classes são importantes não só para visualização, especificação e
documentação de modelos estruturais, mas também para a construção de sistemas executáveis por intermédio da
engenharia de produção de software.
Os elementos básicos de um diagrama de classes são:
• Classes
• Interfaces
• Relacionamentos de associação, dependência, generalização/especialização e agregação (todo/parte)

Arquivo Rose \CursoDeUML\ClientePedidoProduto\ClientePedidoProduto.mdl

Data

Cadastro

Endereço
Cliente rua
Pedido código numero
nome bairro
total() 0..* 1 complemento
novoPe dido() cep
1

1..*
PedidoProduto PessoaFísica PessoaJurídica
quantidade cpf cgc

0..*

1
Produto
código
descrição
preço

7
Classe - Tipo abstrato formado por atributos e métodos.
Pacote - estrutura organizacional que agrupa elementos do diagrama de classes com o objetivo de melhor organizá-
los

Arquivo Rose \CursoDeUML\Classe\Classe.mdl

NomeDaClasse ClasseAbstrata
atributo1 : String
atributo2 : int = 0
$ atributoEstático

método1(parâmetro : String) : Date

métodoEstático(param1 : Integer)
ClasseFinal
método3() : String

pacote

8
Interfaces - Tipos especial de classes possuindo apenas definições de métodos e/ou constantes.

Arquivo Rose \CursoDeUML\Interface\Interface.mdl

Interface
$ const1 : String = "Valor inicial"
$ const2 : Date = "01/01/01"
$ const3 : Byte = 0 ClasseA
Implementa
método1()
método2()
método3()

9
Relacionamentos :
Associação - é um relacionamento estrutural, especificando que os objetos de uma classe estão
conectados/vinculados a objetos de outra classe. Numa associação podem ser especificados os seguintes itens : um
nome, o papel e multiplicidade em cada extremidade da associação, navegação e qualificação.

Dependência - indica a ocorrência de um relacionamento semântico entre dois elementos do modelo, onde uma
classe cliente é dependente de serviços de uma classe fornecedora, mas não existe uma dependência estrutural
interna com esse fornecedor. Indica que uma alteração na especificação de uma classe poderá afetar outra classe
que a utilize, mas não necessariamente o inverso. A forma mais comum de dependência é quando uma classe utilizar
parâmetros de uma outra classe em seus métodos.

Arquivo Rose \CursoDeUML\Associação\ Associação.mdl

+papelB Associação +papelA

ClasseA ClasseB

Associação com Multiplicidade

ClasseX ClasseY

1..5 0..*

Faz
-cliente Cliente

Possui
Pedido PedidoItem

1 0.. *

ClasseAlpha ClasseBeta
Dependência

Tem
+setor +funcionários
1 0..*
Chefe
Setor -chefe Funcionário

Possui 0.. *

-funcionarios

10
Agregação - é uma forma especial de associação utilizada para mostrar que um tipo de objeto é composto, pelo
menos em parte, de outro em uma relação todo/parte. Indicando que o objeto parte "é um atributo" do objeto todo,
onde o ciclo de vida do objeto parte é limitado ao ciclo de vida do objeto todo.

Arquivo Rose \CursoDeUML\Agregação\ Agregação.mdl

Pedido -pedido -pedidoItem PedidoIt em

1 1..*
-pedidoItem

-prod uto
Produt o

11
Generalização/Especialização - Representa o conceito de herança da orientação a objetos e indica que uma classe
estende outra.
Arquivo Rose \CursoDeUML\Generalização\ Generalização.mdl

ClasseRaiz

SubClasseA SubClasseB SubClasseC

SubClasseD SubClasseE SubClasseF

pacote Veículo
Marc a
chassi : String (f rom pacote)
placa : String #marc a
descrição
modelo : String
logotipo
cor : String

VeículoDeCarga VeículoDePasseio
cargaMáxima quantidadeDePassageiros

12
Classe de Associação - elemento da modelagem que tem associação e propriedades de classe, podendo ser vista
tanto como uma associação que tem propriedades de classe, como uma classe que tem propriedades de associação.
Apesar de ser desenhada como uma associação e uma classe, é apenas um único elemento do modelo e tem apenas
um nome.

Arquivo Rose \CursoDeUML\ClasseAssociação\\ClasseAssociação.mdl

Empresa Pessoa
0..* 1..*

Serviço
descrição : String
dataDeAdmissão : Date
salário : Currency

incluir(e : Empresa, p : Pessoa) : void

13
Diagrama de Sequência

Diagrama de Colaboração

Arquivo Rose \CursoDeUML\DiagramaDeInteração\ DiagramaDeInteração.mdl

Clientes

adicionar(cliente : Cliente) : void

remover(cpf : CPF) : void
toString() : String

-cliente 0..*
Cliente Endereço
nome : String (from util)
-endereço

Cliente() Endereço()
toString() toString()

-dataNascimento
-cpf
Data
CPF (from util)
(from util)

Date(data : String)
CPF(cpf : String ) toString() : String
toStri ng() : String

: Clientes : Cliente : CPF : Data : Endereço

Cliente(CPF, String, Endere ço, Data)

CPF(St ring)

Date(String)

Endereço(String, int, String)

14
 : CPF

2: CPF(String)

1: Cliente(CPF, String, Endereço, Data)

4: Endereço(String, int, String)
: Cliente : Clientes :
Endereço

3: Date(String)

: Data

: Clientes : Cliente : CPF : Data : Endereço

toString( )
toS tring( )

toString( )

toString( )

15
: Clientes

1: toString( )

2: toString( )
: Cliente : CPF

3: toString( )
4: toString( )

: : Data
Endereço

16
Diagrama de Estados
Um diagrama de gráfico de estados mostra uma máquina de estados, dando ênfase ao fluxo de controle de um estado
para outro. Uma máquina de estados é um comportamento que especifica as sequências de estados pelos quais um
objeto passa durante seu tempo de vida em resposta a eventos, juntamente com suas respostas a esses eventos. Um
estado é uma condição ou situação na vida de um objeto durante a qual ele satisfaz a alguma condição, realiza
alguma atividade ou aguarda algum evento. Um evento é uma especificação de uma ocorrência significativa para o
objeto. No contexto de uma máquina de estados, um evento é uma ocorrência de um estímulo capaz de ativar uma
transição de estado de um objeto. Uma transição de estado é um relacionamento entre dois estados, indicando que
um objeto no primeiro estado realizará certas ações e entrará no segundo estado quando um evento específico
ocorrer e as condições especificadas estiverem satisfeitas.
Tem como objetivo principal prover uma definição formal explícita de comportamento, permitindo uma verificação dos
eventos e transições de estados aos quais um Sistema está sujeito. A existência de estados em um objeto implica que
a ordem na qual as operações são executadas é importante, o que leva à idéia de objetos como máquinas
independentes. Assim, para cada objeto, a ordem das operações no tempo é tão importante que pode-se formalizar a
caracterização do comportamento de um objeto em termos de uma máquina de estado finita equivalente.
Uma desvantagem do diagrama de estado é ter de definir todos os possíveis estados de um Sistema, impossibilitando
o seu para todo o Sistema, dessa forma, o Diagrama de Estados é utilizado para modelar apenas algumas situações.

Arquivo Rose \CursoDeUML\DiagramaDeEstados\ DiagramaDeEstados.mdl

Carga de um Processo

Novo Processo
Morto Finalizando um Processo

Novo

Pronto escalonado Executand SolicitaçãoI / O Esperando

o

fatia de tempo es gotada

I/O atendido

17
Diagrama de Atividade
Um Diagrama de Atividade é essencialmente um gráfico, mostrando o fluxo de controle de atividades (semelhante a
um Fluxograma). Enquanto o Diagrama de Interação possui foco no relacionamento (troca de mensagens) entre
objetos, o Diagrama de Atividade possui o foco nas Atividades. Uma atividade é uma execução não atômica em
andamento em uma máquina de estado. As atividades ainda podem ser agrupadas em "Swimlanes" (Raias de
natação) com o objetivo de mostrar em qual parte da organização um trabalho é executado ou mostrar explicitamente
onde são encontradas ações (em qual objeto)
Arquivo Rose \CursoDeUML\DiagramaDeAtividades\ DiagramaDeAtividades.mdl

In ici o

Pedido

Registrar
Pedido

[ negado ] [ para cada item ]

Cancelar Autorizar forma de Avaliar item

Pedido pagamento em estoque

[ ok ] [ em estoque ]

[ Pagamento ok e Estoque ok ]

fim Aceitar Pedido

18
 Cli ente Vendas Estoque
In ici o

Solicitar
Produto

Processar
Pedido

Separar
Materiais

Enviar Pedido

Receber Cobrar Client e

Pedido

[ não pago ]
Pagar
Cobrança

Cancelar
pago Pedido

Fechar Pedido

fim

19
Diagrama de Componentes

Arquivo Rose \CursoDeUML\DiagramaDeComponentes\ DiagramaDeComponentes.mdl

Servlet servlet .
.java jar

Servlet
.class BancoDa
dos.class

BancoDa
dos.GDB
BancoDa
dos.java

interba
se.jar

20
Diagrama de Implantação

Arquivo Rose \CursoDeUML\DiagramaDeImplantação\ DiagramaDeImplantação.mdl

Servidor WEB Servidor de

Aplicação

Cliente Servidor de Banco

de Dados

21
Outros Tópicos

Estereótipo
Mecanismo para estender o vocabulário da UML, que permite a criação de novos tipos de blocos de
construção derivados dos já existentes, mas que são específicos a determinado ambiente.
Nota e Ligação de Nota
Comentário colocado em componente gráfico para descrever elementos da UML

Arquivo Rose \CursoDeUML\Estereótipo_e_Nota\ Estereótipo_e_Nota.mdl

Classe Cliente
<<Tabela>> com Estereótio de
Cliente Tabela de
cpf Banco de Dados
nome
endereç o

22
Contratos
Documento que descreve o que uma operação se compromete a fazer. Usualmente, ele segue um estilo
declarativo, enfatizando o que acontecerá, em vez de como será conseguido. É comum os contratos serem
expressos em termos de mudanças de estado definidas por pré-condições e pós-condições. Um contrato pode
ser escrito para um método individual de uma classe ou para uma operação mais abrangente do Sistema.

Contrato
Nome entrarItem(código: String, quantidade : int)
Responsabilidade Entrar (registrar) a venda de um item e acrescentá-lo à venda.
Exibir a descrição e o preço do item
Notas Use acesso rápido ao Banco de Dados
Exceções Se o código não for válido, indique erro
Saída
Pré-Condições O código deverá ser válido
Pós-Condições • Se for uma nova Venda, uma Venda foi criada (criação de instância)
• Se for uma nova Venda, a nova Venda foi associada ao Post (Formada uma
associação)
• Uma LinhaDeItemDeVenda foi criada (criação de instância)
• A LinhaDeItemDeVenda foi Associada à Venda (Formada uma associação)
• LinhaDeItemDeVenda.quantidade recebeu o valor quantidade (Modificação de
atributo)
• A LinhaDeItemDeVenda foi associada a uma EspecificaçãoDeProduto, baseada
numa correspondência com o código (Formada Associação)

23
RationalRose 2000
Tools/Options
Editando
Use Case View
Logical View
Component View
Deployment View
Tools/Java/Project Specification
Tools/Java/Generate Java
Tools/Java/Reverse Engineer Java
Tools/Web Publisher

24
Estudo de Caso - Supermercado
Arquivo Rose \CursoDeUML\EstudoDeCaso\Supermercado\Supermercado.mdl
Fontes Java \CursoDeUML\EstudoDeCaso\Supermercado\Supermercado.jpr

TabelaRelacional

Caixas Vendas Registradoras Produtos

-caixas -registradoras
-vendas
0..* 0..* -produtos
<<TabelaRelacion al>> 0..* Registradora 0..*
Caixa Venda codigo : int
co digo : i nt -vendas -vendas Produto
nome : St ring vendas()
0..* troco() 0..* login()
codigo : int

ve ndas() logout()

-produto
-tipoPagamento

VendaProduto
-produto codigo : int
TipoDePagamento quantidade : int
codigo : int 0..* preco : float
descricao : String

toString()

0..*
-tiposPagamento
TiposDePagamento

25