Aula 7 - (2012)

Prévia do material em texto

16/03/2012
1
Visão Geral
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 2
16/03/2012
2
� Artefatos
© Carla A. Lima Reis e Rodrigo Quites Reis 
(LABES-UFPA) / 2009 3
Sistema
Usuário
XPTO
Diagrama de CasosDiagrama de CasosDiagrama de CasosDiagrama de Casos
de Usode Usode Usode Uso
T elefone
codArea
numero
Funcionario
nome
cargo
dataAdmissao 0..*
0..1
0..*
+subordinado
0..1+chefe
supervisiona
0..*0..*
possui
DadosPessoais
corPele
corOlhos
tipoSanguineo
...
Diagrama de ClassesDiagrama de ClassesDiagrama de ClassesDiagrama de Classes
 : Atendente : Atendente
Tela de Geração 
de Cont a
Tela de Geração 
de Cont a
 : Sessão : Sessão : Item : Item
conta : Contaconta : Conta
 : Promoção : Promoção
1: gerarContaSessão(s)
2: obter(s)
3: s
4: obterItensConsumidos
5: ob terItens
6: itens
7: itens
10: obterPreço
11: preçoUnit ário
12: obterQuantidade(item)
13: quantidade
8: obterNome
9: nome
repetir enquanto houver itens na sessão de consumo
15: criar(s, i tens)
16: conta
17: conta
14: 
Diagrama de SequênciaDiagrama de SequênciaDiagrama de SequênciaDiagrama de Sequência
e Colaboraçãoe Colaboraçãoe Colaboraçãoe Colaboração
Planejado
Cancelado
transferência( novaData, novaHora ) / 
data := novaData; hora := novaHora
Pago
Realizado
Realizado com 
pagamento pendente
Realizado com 
pagamento antecipado
Realizado com 
pagamento pendente
pagamentoEfetuado Realizado com 
pagamento antecipado
solicitaçãoPaciente / criarCancelamento(dataHoraAtual, 
motivo=paciente)
solicitaçãoMédico / criarCance lamento(dataHoraAtual, 
motivo=médico)
autorização( dataHoraAutorização, códigoAutorização, convênio )[ tipo == convênio 
] / criarAutorização(dataHoraAutorização, códigoAutorização, convênio)
pagamentoEfetuado[ tipo == particular ]
Diagrama de EstadosDiagrama de EstadosDiagrama de EstadosDiagrama de Estados
Diagrama deDiagrama deDiagrama deDiagrama de
AtividadesAtividadesAtividadesAtividades
� Relacionamento entre artefatos (1)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 4
Sistema
Usuário
XPTO
Diagrama de CasosDiagrama de CasosDiagrama de CasosDiagrama de Casos
de Usode Usode Usode Uso
 : Atendente : Atendente
Tela de Geração 
de Cont a
Tela de Geração 
de Cont a
 : Sessão : Sessão : Item : Item
conta : Contaconta : Conta
 : Promoção : Promoção
1: gerarContaSessão(s)
2: obter(s)
3: s
4: obterItensConsumidos
5: obterIt ens
6: itens
7: itens
10: obterPreço
11: preçoUnitário
12: obterQuantidade(item)
13: quantidade
8: obterNome
9: nome
repetir enquanto houver itens na sessão de consumo
15: criar(s, itens)
16: conta
17: conta
14: 
Diagrama de SequênciaDiagrama de SequênciaDiagrama de SequênciaDiagrama de Sequência
e Colaboraçãoe Colaboraçãoe Colaboraçãoe Colaboração
Fornece os
cenários
Valida as iterações
16/03/2012
3
� Relacionamento entre artefatos (2)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 5
Sistema
Usuário
XPTO
Diagrama de CasosDiagrama de CasosDiagrama de CasosDiagrama de Casos
de Usode Usode Usode Uso
T elefone
codArea
numero
Funcionario
nome
cargo
dataAdmissao 0..*
0..1
0..*
+subordinado
0..1+chefe
supervisiona
0..*0..*
possui
DadosPessoais
corPele
corOlhos
tipoSanguineo
...
Diagrama de ClassesDiagrama de ClassesDiagrama de ClassesDiagrama de Classes
Fornece os cenários
Validas as iterações (*)
(*) isto é, se não forem achadas as classes envolvidas em um CDU,
há indícios que não se trata de um CDU em si.
� Relacionamento 
entre Artefatos (3)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 6
T elefone
codArea
numero
Funcionario
nome
cargo
dataAdmissao 0..*
0..1
0..*
+subordinado
0..1+chefe
supervisiona
0..*0..*
possui
DadosPessoais
corPele
corOlhos
tipoSanguineo
...
Diagrama de ClassesDiagrama de ClassesDiagrama de ClassesDiagrama de Classes
 : Atendente : Atendente
Tela de Geração 
de Cont a
Tela de Geração 
de Cont a
 : Sessão : Sessão : Item : Item
conta : Contaconta : Conta
 : Promoção : Promoção
1: gerarContaSessão(s)
2: obter(s)
3: s
4: obterItensConsumidos
5: ob terItens
6: itens
7: itens
10: obterPreço
11: preçoUnit ário
12: obterQuantidade(item)
13: quantidade
8: obterNome
9: nome
repetir enquanto houver itens na sessão de consumo
15: criar(s, i tens)
16: conta
17: conta
14: 
Diagrama de SequênciaDiagrama de SequênciaDiagrama de SequênciaDiagrama de Sequência
e Colaboraçãoe Colaboraçãoe Colaboraçãoe Colaboração
Fornece objetos
e classes
Valida o modelo
e fornece detalhes
(atributos e operações)
16/03/2012
4
� Relacionamento entre Artefatos (4)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 7
T elefone
codArea
numero
Funcionario
nome
cargo
dataAdmissao 0..*
0..1
0..*
+subordinado
0..1+chefe
supervisiona
0..*0..*
possui
DadosPessoais
corPele
corOlhos
tipoSanguineo
...
Diagrama de ClassesDiagrama de ClassesDiagrama de ClassesDiagrama de Classes
Planejado
Cancelado
transferência( novaData, novaHora ) / 
data := novaData; hora := novaHora
Pago
Realizado
Realizado com 
pagamento pendente
Realizado com 
pagamento antecipado
Realizado com 
pagamento pendente
pagamentoEfetuado Realizado com 
pagamento antecipado
solicitaçãoPaciente / criarCancelamento(dataHoraAtual, 
motivo=paciente)
soli citaçãoMédico / criarCance lamento(dataHoraAtual, 
motivo=médico)
autorização( dataHoraAutorização, códigoAutorização, convênio )[ tipo == convênio 
] / criarAutorização(dataHoraAutorização, códigoAutorização, convênio)
pagamentoEfetuado[ tipo == particular ]
Diagrama de EstadosDiagrama de EstadosDiagrama de EstadosDiagrama de Estados
Fornece os objetos e classes
Valida o modelo
e fornece detalhes
(atributos e operações)
� Relacionamento entre Artefatos (5)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 8
http://www.voxxel.com.br/pages/introdiauml.html
16/03/2012
5
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 9
� Resumo
◦ Diagrama base para qualquer discussão acerca da 
arquitetura de um sistema com UML
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 10
16/03/2012
6
� Propósito
◦ Representação dos dados manipulados e 
armazenados pelos programas de acordo com os 
conceitos de Orientação a Objetos
◦ Notação fortemente baseada no Diagramas 
Entidade-Relacionamento de Peter Chen
11
� Diagrama de Classe
◦ Notação
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 12
Nome da classeNome da classeNome da classeNome da classe
atributo: tipo de dado
atributo: tipo de dado = valor inicial
Operação(lista de argumentos):
tipo do resultado
Opcionais
(fornecidos somente após
um melhor entendimento
do sistema)
16/03/2012
7
� Aspectos tratados pelos Diagramas de Classe: 
Dados e Funções
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 13
DadosDadosDadosDados
FunçõesFunçõesFunçõesFunções
EventosEventosEventosEventos
Sistema
Obs: a ordem da execução das funções (aspecto temporal) não é tratada
explicitamente nos diagramas de classe
� Associações
◦ Permitem descrever as relações existentes entre os 
elementos (objetos) dos conjuntos (classes)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 14
LivrosLivrosLivrosLivros
PessoasPessoasPessoasPessoasAutor de
Escrito por
16/03/2012
8
� Associações
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 15
LivroLivroLivroLivroPessoaPessoaPessoaPessoaescrito por
0..* 1..*
Multiplicidade da associação
Rótulo da associação
� Associações
◦ Interpretação:
� Um objeto de Livro está associado com no mínimo um 
objeto de Pessoa, e no máximo com uma quantidade 
indeterminada
� Um objeto de Pessoa pode não estar vinculado com 
qualquer objeto de Livro ou com uma quantidade 
indeterminada
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 16
LivroLivroLivroLivro PessoaPessoaPessoaPessoaescrito por
0..* 1..*
16/03/2012
9
� Associações
◦ Classes:
� Nome de “Entidades”
� Rotuladas no Singular
◦ Associações
� Leitura no sentido “convencional” (esquerda para 
direita, de cima para baixo)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 17
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 18
Jogador
Gol
0..* +autor0..*
Relação
18..*
0..*
18..*
0..*
Substituição
0..* +substituto0..*
0..*
+substituído
0..*
Expulsão
0..*
+expulso
0..*Estádio
Arbitro
Torneio
Jogo
0..*0..*
+local
0..*0..*
+principal
2
0..*+auxiliar
2
0..*
1
0..*
+reserva
1
0..*
0..1
1..*
0..1
1..*
HistoriaEquipeJogo
0..*0..*
0..*0..*
0..*0..*
0..*
Equipe
2
0..*
2
0..*
0..*0..*0..*
Ex
em
p
lo
 d
e 
d
ia
g
ra
m
a 
co
n
ce
it
u
al
Ex
em
p
lo
 d
e 
d
ia
g
ra
m
a 
co
n
ce
it
u
al
Ex
em
p
lo
 d
e 
d
ia
g
ra
m
a 
co
n
ce
it
u
al
Ex
em
p
lo
 d
e 
d
ia
g
ra
m
a 
co
n
ce
it
u
al
(t
ip
ic
am
en
te
 p
ro
d
u
zi
d
o
 n
as
 p
ri
m
ei
ra
s 
it
er
aç
õ
es
)
realizado em
16/03/2012
10
� Atributos
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 19
PessoaPessoaPessoaPessoa
Nome: Str
Endereço: {
Logradouro: Str,
Bairro: Str,
Cidade: Str. }
Telefones: Array of Int
Obs: Atributos Compostos e
Multivalorados são
permitidos pelo modelo de
dados OO
No entanto é indicado que uma 
Classe seja criada (facilita 
reutilização) Ex: Pedro e João 
moram no mesmo endereço
� Associações
◦ Observe: não há chave-primária
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 20
LivroLivroLivroLivro
Título: Str
ISBN: Int
Editora: Str
PessoaPessoaPessoaPessoa
Nome: Str
Endereço: {
Logradouro: Str,
Bairro: Str,
Cidade: Str. }
Telefones: Array of Int
escrito por
0..* 1..*
Multiplicidade da associação
Rótulo da associação
16/03/2012
11
� Associações
◦ Papel de Classe/Objeto em uma Associação (em 
inglês, role)
◦ Pode ocorrer simultaneamente com o nome 
(rótulo / label) da associação
◦ O papel é usado na geração de código e BD
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 21
LivroLivroLivroLivro
Título: Str
ISBN: Int
Editora: Str
PessoaPessoaPessoaPessoa
Nome: Str
Endereço: {
Logradouro: Str,
Bairro: Str,
Cidade: Str. }
Telefones: Array of Int
escrito por0..* 1..*
autorobra
Papéis
� Atributos e Métodos
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 22
Conta BancáriaConta BancáriaConta BancáriaConta Bancária
número
saldo
dataAbertura
criar()
bloquear()
desbloquear()
creditar()
debitar()
PessoaPessoaPessoaPessoa
Nome: Str
Endereço: {
Logradouro: Str,
Bairro: Str,
Cidade: Str. }
Telefones: Array of Int
10..*
titular
dependente
0..20..*
16/03/2012
12
� Associações
◦ Exemplo de Geração de Código em Java
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 23
ContaBancariaPessoa 0..*
1
0..*
1
+titular possui
0..* 0..*+dependente 0..*0..*
Class ContaBancaria {Class ContaBancaria {Class ContaBancaria {Class ContaBancaria {
String numero;
float saldo;
Date dataAbertura;
Pessoa titular;
Vector dependente;
� Associações
◦ Exemplos: Associação Unária ou Reflexiva
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 24
Funcionário
0..1
*
Supervisiona
FuncionárioFuncionárioFuncionárioFuncionário
João
supervisiona
É supervisionado por
16/03/2012
13
� Associações
◦ Exemplos: Associação Unária ou Reflexiva
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 25
Funcionário
0..1
*
Supervisiona
Funcionario
0..*
0..1 supervisiona
0..*
0..1+chefe
+subordinado
Evolução:Evolução:Evolução:Evolução: acréscimo dos
papéis facilita a implementação
e o entendimento
� Associações
◦ Exemplos: Associação Unária ou Reflexiva
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 26
�Class Funcionario {
�Xxx;
�Funcionario chefe;
�Vector subordinado;
Funcionario
0..*
0..1 supervisiona
0..*
0..1+chefe
+subordinado
16/03/2012
14
� Associações
◦ Navegabilidade das Associações
� Associação binária e bibibibidirecional
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 27
Funcionário Departamento
0..* trabalha 1
Funcionário trabalha em Departamento
Funcionário
João
Departamento
Financeiro
� Associações
◦ Navegabilidade das Associações
� Associação binária e uniuniuniunidirecional
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 28
Funcionário Departamento
0..* trabalha
Funcionário
João
Departamento
Financeiro
16/03/2012
15
� Associações
◦ Navegabilidade das Associações
� Associação Unidirecional
� Razão da existência � mais fácil a implementação
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 29
� Associações
◦ Navegabilidade das Associações
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 30
16/03/2012
16
� Associações
◦ Multiplicidade: limiar inferior..limiar superior
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 31
Multiplicidade Significado
0..1 Zero ou um
1 Somente 1 (opcional)
0..* Maior ou igual a zero
* Maior ou igual a zero
1..* Maior ou igual a 1
1..15 (m..n) De 1 a 15 (m a n), inclusive
� Exercício: qual o mais correto?
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 32
Funcionário Departamento
1 trabalha 0..1
Funcionário Departamento
0..* trabalha
Funcionário Departamento
0..* trabalha 0..*
(adaptado de BEZ02)
16/03/2012
17
� Exemplos
◦ Funcionário = { João, Maria, José }
◦ Depto = {A, B}
◦ Trabalha = { (João, A), (Maria, B), (José, B)}
◦ Gerente = { (João, B), (Maria, A) }
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 33
Funcionário Departamento
trabalha
1*
gerente 0..1
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 34
Funcionário Departamento
Financeiro
TI
João
Marcela
Amanda
Funcionário Departamento
trabalha
1*
gerente 0..1
16/03/2012
18
� Exemplo
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 35
Financeira
código
nome
Venda
data
hora
Vendedor
número
nenha
nívelAutorização
financia
0..1 * *
realizada por
� Classes associativas
◦ Informação que surge a partir da associação de 
duas outras classes
◦ Podem ser anônimas
◦ Um objeto de classe associativa está associado 
com exatamente um objeto de cada extremidade
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 36
Fulano, Cálculo I, INS, 75%, 1º 2005
Fulano, Cálculo I, BOM, 100%, 2º 2005
Beltrano, Mat, BOM, 90%, 2º 2005
16/03/2012
19
� Classes associativas
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 37
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamentoData
Regime
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamento Data
Regime
Data
Regime
Data
Regime
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 38
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamento Data
Regime
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamento Data
Regime
Data
Regime
Data
Regime
Pessoa
João
Marcela
Amanda
Jorge
Abel
dataX
regimeX
dataY
regimeY
16/03/2012
20
� Classes associativas
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 39
Financeira
código
nome
Venda
data
hora
Vendedor
número
nenha
nívelAutorização
financia
0..1 * *
realizada por
registroAprovação
dataAprovação
Financiamento
� Onde guardar data de locação e outras 
informações da locação? Na classe Locadora 
ou na classe Carro?
Locadora
CNPJ : String
Endereco : String
Carro
Renavan : String
Placa : String
Ano : Date
Modelo : String
0..n
loca
0..n
16/03/2012
21
Locadora
CNPJ : String
Endereco : String
Carro
Renavan : String
Placa : String
Ano : Date
Modelo : String
0..n
loca
0..n
Aluguel
DataLocacao
DataDevolucao
ValorPorHora
� Classes associativas
◦ Observação importante: o conceito de “Classe 
Associativa” não é permitido em todas as 
linguagens de programação e sistemas de banco de 
dados OO
◦ Assim, em muitos casos as classes associativas 
encontradas em Análise são substituídas por 
classes regulares em Projeto
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 42
16/03/2012
22
� Classes associativas
◦ Classe associativa substituída por normal
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 43
Obs: sempre vai ser multiplicidade 1, neste caso
OriginalOriginalOriginalOriginal
(Análise)(Análise)(Análise)(Análise)
ModificadoModificadoModificadoModificado
(Projeto)(Projeto)(Projeto)(Projeto)
� Classes associativas
◦ Classe associativa substituída por normal
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 44
Observar que neste caso a
substituição não é trivial visto
que o objeto de devolução só
é criado após a associação
de Empréstimo e Item.
16/03/2012
23
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 45
� Agregação
◦ Associa de todo/partetodo/partetodo/partetodo/parte
◦ Ação realizada sobre todo atinge as partes
◦ Tipo especial de associação
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 46
Documento Parágrafo Sentença0..* 0..*
Documento Parágrafo Sentença0..* 0..*
composto-por composto-por
16/03/2012
24
� Agregação
◦ A parte pode existir sem o todo
◦ Exemplo
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 47
Associação
Esportiva
Equipe Jogador0..* 0..*
◀ afiliada
� Composição
◦ A parte não existir sem o todo
◦ Exemplo
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 48
Homem Órgão0..*
16/03/2012
25
� Generalização/Especialização
◦ Todos os exemplos anteriores envolviam a ligação 
entre instâncias de classes (objetos)
◦ Com a Herança, o relacionamento fornecido é o de 
subconjunto
◦ Útil para definir hierarquias de classes (não de 
objetos!) que possuem propriedades comuns
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 49
� Generalização/Especialização
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 50
Cliente
nome
PessoaFísica
CPF
RG
Sexo
DataNascimento
PessoaJurídica
CGC
RazãoSocial
Super-classe
Sub-classes
(herdeiras)
16/03/2012
26
� Generalização/Especialização
◦ Em Rational Rose
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 51
Cliente
PFPJ
� Generalização/Especialização
◦ Polimorfismo de dados:
� Uma associação pode ocorrer com objetos de 
diferentes classes (deste que tenham suas classes 
relacionadas por herança).
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 52
16/03/2012
27
� Generalização/Especialização
◦ Polimorfismo de dados: exemplo
� não há necessidade de se criar uma associação entre 
Compra e subclasses de Cliente
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 53
Cliente
nome
PessoaFísica
CPF
RG
Sexo
DataNascimento
PessoaJurídica
CGC
RazãoSocial
Compra*
realiza
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 54
16/03/2012
28
� Generalização/Especialização
◦ Herança Múltipla: caso especial
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 55
Veículo
anfíbio
Veículo
Veículo
terrestre
Veículo
aquático
Conceito pouco usado na prática:
•Poucas linguagens de programação
permitem o uso
•Adiciona maior complexidade ao
modelo
� Generalização/Especialização
◦ Classe Abstrata
� Classe que não instancia objetos.
� Serve apenas para gerar novas sub-classes a partir da 
herança.
� Freqüentemente é uma classe artificial, isto é, que não 
existe no Domínio do Problema e surge para acomodar 
propriedades comuns de classes concretas.
� Representada com título em itálico ou com uma 
restrição {abstrata} (ou {abstract})
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 56
16/03/2012
29
� Generalização/Especialização
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 57
Cliente
ContaBancária
número
dataAbertura
saldo
debitar(quantia)
creditar(quantia)
Transação
ContaCorrente
limiteSaque
ContaPoupança
dataAniversário
* *
Classe Abstrata
possui
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 58
16/03/2012
30
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 59
Evolução Facilitada
� Restrições
◦ São regras especificadas com lógica ou com 
linguagem específica (*) para impedir / condicionar 
a criação de objetos e associações
◦ Úteis para especificar regras de negócios no 
diagrama
◦ (*) Object Constrain Language - OCL
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 60
16/03/2012
31
� Restrições – Exemplo {ou}
◦ Restrição {ou} implica na seleção exclusiva entre 
duas ou mais associações existentes em uma classe
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 61
Conta
corrente
Indivíduo
Organização
0..*
0..*
0..1
0..1
{ou}
cliente
cliente
� Restrições
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 62
Conta
corrente
Cliente
Organização
0..*
0..1
cliente
Indivíduo
Conta
corrente
Indivíduo
Organização
0..*
0..*
0..1
0..1
{ou}
cliente
cliente
Obs: são equivalentes Notar classe
abstrata
16/03/2012
32
� Restrições
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 63
Contrato de
Seguro
Indivíduo
Empresa
0..*
0..*
1..*
1..*
{ou}
Contrato
Cliente
Organização
0..*
1..*
IndivíduoOBS: Não são equivalentes!
Por que?
� Restrições
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 64
Significado: seja uma pessoa (empregado), seu empregador é 
mesmo do seu chefe
16/03/2012
33
� Restrições
◦ Restrição {subconjunto} ou {subset}
� Estabelece relação de subconjunto entre duas 
associações
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 65
Pessoa Comitê
Membro-de
Presidente-de{subconjunto}
0..*
0..*
0..*
� Restrições: exemplos diversos
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 66
EmpregadoEmpregadoEmpregadoEmpregado
salário chefe
{Empregado.salário < Empregado.chefe.salário}
1..*
1
Janela TelaVisível em
{ordenado}
*
16/03/2012
34
� Restrições: exemplos diversos
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 67
PessoaPessoaPessoaPessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1 casamento
Data
Regime
{pessoa.sexo=Feminino}
{pessoa.sexo=Masculino}
Restrições: exemplos diversos
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 68
16/03/2012
35
� Restrições
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 69
Conta BancáriaConta BancáriaConta BancáriaConta Bancária
número
saldo
dataAbertura
criar()
bloquear()
desbloquear()
creditar()
debitar()
PessoaPessoaPessoaPessoa
nome: Str
endereço: {
logradouro: Str,
bairro: Str,
cidade: Str. }
telefones: Array of Int
1..**
correntista
titular
{subconjunto}
*
� Transmutação ou Metamorfose de Objetos
◦ Monitor, Professor, Aluno: herança
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 70
Pessoa
AlunoProfessor
Monitor
16/03/2012
36
� Transmutação ou Metamorfose de Objetos
◦ Monitor, Professor, Aluno: herança
� Problemas
� Acomodação pouco eficiente de objetos que mudam de 
classes
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 71
Pessoa
AlunoProfessor
Monitor
� Transmutação ou Metamorfose de Objetos
◦ Solução Geral: Combinar herança e associação
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 72
PapelPessoa
AlunoProfessor Monitor
Pessoa *
nome
cpf
dataNascimento
exerce
matrícula matrícula
1. Início: 01/02
2. Início: 01/11
Fim: 31/12
3. Fim: 31/12
4. Início: 01/01/próximo ano
0. criação
dataInicio
dataFim
16/03/2012
37
� Erros Comuns
◦ Usar classes ou associações para representar 
consultas ou operações do sistema que não devem 
ser registradas
� Exemplo 1
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 73
Usuário Acervo
consulta
� Erros Comuns
◦ Usar classes ou associações para representar 
consultas ou operações do sistema que não devem 
ser registradas
◦ Exemplo 2
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 74
Usuário Consulta
faz *
16/03/2012
38
� Erros Comuns
◦ Inserir atributos quando o ideal é criar uma 
classe
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 75
Canal
EstiloMusical
Refere-se a
*
� Erros Comuns
◦ Usar herança quando a quantidade de tipos é 
grande ou dinâmica
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 76
EstiloMusical
Pagode Rock Axé
EstiloMusical
Nome: string
16/03/2012
39
� Erros Comuns
◦ Inserir chaves-estrangeiras no diagrama de classes
� As associações são suficientes
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 77
Funcionário
codFunc
codDepto
Depto
codDepto
...
trabalha
*
Chave primária? Usar OID!
Chave estrangeira? Redundante!
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 78
16/03/2012
40
� Descrição:
◦ Representa os sub-sistemas englobados no 
Sistema. 
◦ Possui pacotes e as dependências entre pacotes
◦ Pode ser representado associado com outros 
diagramas
� Objetivo: agrupar classes em pacotes
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 80
Pacote 
Dependência
Pacote 
Dependência
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/pacotes/diag_pacotes.htm
16/03/2012
41
16/03/2012
42
� Descrição:
◦ Descrevem os componentes do Sistema
� Como os componentes são estruturados
� Como os componentes interagem
◦ Representa os Componentes, Interfaces, Portas de 
Comunicação de um ou vários Sistemas
16/03/2012
43
16/03/2012
44
� Descrição:
◦ Determina as necessidades de hardware do Sistema 
� servidores, topologias, protocolos de comunicação
◦ Pode ser representado em conjunto com o 
diagrama de Componentes 
◦ Nós, Topologia, Forma de comunicação
16/03/2012
45
16/03/2012
46
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 92
16/03/2012
47
� Vários diagramas da UML podem ser usados 
para expressar os aspectos temporais
◦ Diagrama de Atividades
◦ Diagrama de Transição de Estados
◦ Diagramas de Interação
� Diagrama de Seqüência
� Diagrama de Colaboração
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 93
� Aspectos principais tratados pelos Diagramas 
Temporais: Funções e Eventos
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 94
DadosDadosDadosDados
FunçõesFunçõesFunçõesFunções
EventosEventosEventosEventos
Sistema
16/03/2012
48
� Objetivos da Modelagem Temporal
◦ Descrever detalhadamente as funções a serem 
desempenhadas em um sistema OO
� Fluxo de mensagens entre objetos
� Métodos necessários para cada classe
� Métodos de classe
� Métodos de objetos
◦ “O que o sistema deve realizar?”
◦ “Quando cada função será realizada?”
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 95
� Modelagem Funcional e Temporal
◦ Definição de Métodos
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 96
PedidoPedidoPedidoPedido
Data recebimento
é_préPago
Número
Preço
?Serviços fornecidos pelaclasse para outros objetos
16/03/2012
49
� Modelagem Funcional e Temporal
◦ Tipos de métodos
� Serviços algoritmicamente simples (90%)
� Criar
� Conectar
� Acessar
� Liberar
� Serviços algoritmicamente complexos
� Calcular
� Calcula um resultado a partir dos valores de atributos do 
objeto
� Monitorar
� Monitora um sistema ou dispositivo externo
� Lida com E/S externas ao sistema
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 97
Diagrama de Transição de Estados
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 98
16/03/2012
50
� Histórico
◦ Notação proposta por David Harel-1987
◦ Máquina com número finito de estados
◦ A máquina pode receber eventos, e cada evento 
pode gerar uma transição de estado
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 99
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
0
Agencia
numero
nome
ContaBancaria
numero
saldo
limite
0..*
Correntista
nome
cpf
0..*
0..*
0..*
0..*
0..*
DTE será construído
16/03/2012
51
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
1
Disponível
Devedora
contaCriada( data ) / 
dataAbertura := data;
realizarSaque(quantia) / sacar(quantia)
realizarDepósito( quantia ) / depositar(quantia)
realizarDepósito( quantia ) / depositar(quantia)
realizarSaque( quantia )[ quantia <= saldo + limite ] / sacar(quantia)
contaFechada( data )[ saldo == 0 ] / 
dataEncerramento := data
realizarSaque( quantia )[ limite + saldo >= quantia 
AND quantia > saldo ] / sacar(quantia)
after( 30 dias ) / aplicarJuros
when( saldo > 0 )
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
2
Class ContaBancaria {
float saldo;
int numero;
Date dataCriacao;
Date dataEncerramento;
int situacao;
ContaBancaria(data) {
dataAbertura = data;
}
void realizarSaque(quantia) {
if (situacao == DISPONIVEL) AND
(quantia > saldo) AND
(quantia <= saldo + limite)
sacar(quantia)
if (situacao == BLOQUEADA)
(quantia <= saldo + limite)
sacar(quantia)
16/03/2012
52
� Estado◦ Situação na vida de um objeto
◦ Estado é determinado pelo conjunto de valores 
armazenados em um objeto
◦ Estados Especiais
� Inicial: somente um em um DTE
� Final
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
3
disponível
Conta criada
� Transições
◦ Um estado é associado a outro (ou a si mesmo) 
pelas transições
◦ Formato:
� evento(lista-parâmetros) [guarda] / ação
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
4
disponível
Realizar depósito(quantia)
/ depositar(quantia)
16/03/2012
53
� Eventos
◦ Uma transição é associada a um evento
◦ Evento: “algo que acontece em algum ponto no 
tempo e que pode modificar o estado de um 
objeto” [Bezerra, 2002]
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
5
Eventos em Software Eventos do Domínio do 
Problema
Mouse pressionado Pedido realizado
Impressora sem papel Fatura paga
Cheque devolvido
� Eventos: tipos
◦ Evento de chamada: recebimento de uma 
mensagem de outro objeto (síncrono)
◦ Evento de sinal: recebimento de um sinal 
(assíncrono)
◦ Evento temporal: passagem de intervalo de 
tempo pré-definido (cláusula after)
� Exemplo: after(30 segundos)
◦ Evento de alteração/tempo: condição que se 
torna verdadeira (cláusula when)
� Exemplos:
� when(saldo > 0)
� when (horário = 00:00 h)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
6
16/03/2012
54
� Guardas
◦ Condição lógica que precisa ser satisfeita para 
habilitar a transição
◦ Diferença entre guardas e evento de mudança
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
7
a b
Evento [quantia=saldo]
a b
when(quantia=saldo)
Se ocorre evento e
quantia = saldo
a transição é disparada
Quando quantia = saldo
a transição é disparada
� Ações
◦ “Ao transitar de um estado para outro, um objeto 
pode realizar uma ou mais ações”
◦ Representação:
� /ação
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
8
16/03/2012
55
� Exemplo: Ponto de Junção
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
9
E0
E1
E2
E3
E4
E5
evento1 [guarda1]/ação1
evento0 [guarda0]/ação0
evento2 [guarda2]/ação2
[else]/ação5
� Exemplo: Despertador
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
0
Desarmado Esperando Tocando
16/03/2012
56
� Exemplo: Despertador
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
1
desarmado
esperando
entry / n := n + 1
tocando alarme
entry / tocarAlarme(10)
Desarmar alarme
Desarmar alarme
when(n > 3)
Armar alarme(horario)
/ horarioDefinido := horario,
n := 0
when(horarioDefinido = agora())
/ horarioDefinido :=
horarioDefinido + 5 minutos
Ação ocorre quando a
ação entry de
tocandoAlarme é
encerrada
Despertador
n
horarioDefinido
� Estados e Sub-estados
◦ Um estado pode ser decomposto em sub-estados
◦ Cada estado composto deve possuir os estados 
inicial e final
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
2
16/03/2012
57
� Estados e Sub-estados
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
3
� Exemplo com Biblioteca
◦ Observar que a prática de cenários com DTE leva à 
descoberta de novas classes e atributos
◦ Observar que agregar os estados “Emprestado” e 
“Emprestado/Reservado” em um estado maior foi 
útil apenas para o evento de extravio
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
4
16/03/2012
58
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
5
Classe para DTE ser construído
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
6
Disponível
Extraviado
Danificado
Conserto
Descartado
Devolvido e 
Reservado
when( 
expiração_reserva )
NewState
Emprestado e 
Reservado
EmprestadoEmprestado e 
Reservado
devolução( data ) 
/ devolver(data)
Emprestado
devolução( data ) / devolver(data)
reservaEfetuada
retirada( 
data ) / 
retirar(data)
extravio( data ) / 
registrarExtravio(
data)
conserto( data ) / 
registrarEnvioConserto(data)
recuperado( data )
reversão[ adm ]
<<exceçao>>
after( 1 ano )
encontrado( data ) / 
tornarDisponível(data)
retirada( data ) / retirar(data)
danificado( data ) / registrarDefeito(data)
extravio( data ) / registrarExtravio(data)
16/03/2012
59
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
7
Elementos destacadosElementos destacadosElementos destacadosElementos destacados: incorporados ao modelo a partir da prática com DTE
� Exemplo de controle de Turmas em um 
sistema de gestão acadêmica
◦ Exemplo mostra como lidar com prazos fixos que o 
sistema deve controlar automaticamente
◦ Além disso, a modelagem considera que há 
situações de exceção – permissões que devem ser 
liberadas para usuários com privilégios
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
8
16/03/2012
60
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
9
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
0
Cancelada Turma 
Concluída
Turma Criada
Inscrições 
encerradas
Ajustes 
encerrados
Aberta para 
i nclusões
when( situação excepcional )
Inscrições 
encerradas cancelamento( aluno ) / número_alunos--
inclusão( aluno )[ administrador ] / inscrever(aluno, hoje); número_alunos++
<<exceção>>
Ajustes 
encerrados
when( hoje > data_limite_exclusões )
inclusão( aluno )[ administrador ] / 
inscrever(aluno, hoje); número_al unos++
<<exceção>>
cancelamento( aluno )[ administrador ] / 
número_alunos--
<<exceção>>
Aberta para 
i nclusões
when( hoj e > data _li mi te_i nclusões )
inscrição( aluno )[ número_alunos <= l im ite_turma ] / inscreve r(aluno, hoj e); núm ero_al unos++
cancelam ento( aluno ) / número_alunos--
[ disciplina 
está ati va ]
when( concei toFi nal é l ançado )
16/03/2012
61
� O exemplo a seguir mostra a gestão de 
consultório médico
◦ O DTE construído – para a classe Procedimento –
lida simultaneamente com várias situações 
(agendamento e pagamento). 
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
1
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
2
16/03/2012
62
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
3
Planejado
Cancelado
transferência( novaData, novaHora ) / 
data := novaData; hora := novaHora
Pago
Realizado
Realizado com 
pagamento pendente
Realizado com 
pagamento antecipado
Realizado com 
pagamento pendente
pagamentoEfetuado Realizado com 
pagamento antecipado
solicitaçãoPaciente / criarCancelamento(dataHoraAtual, 
motivo=paciente)
solicitaçãoMédico / criarCancelamento(dataHoraAtual, 
motivo=médico)
autorização( dataHoraAutorização, códigoAutorização, convênio )[ tipo == convênio 
] / criarAutorização(dataHoraAutorização, códigoAutorização, convênio)
pagamentoEfetuado[ tipo == particular ]
� Histórico
◦ Mecanismo de ativação de subestados
◦ Se a entrada em um estado for por história 
simples (H), o subestado mais recentemente 
visitado é escolhido, em detrimento do estado 
default.
◦ Se for história do tipo H* então considera-se 
como candidato a ser ativado o subestado mais 
recentemente visitado independente do nível 
hierárquico em que se encontra
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
4
16/03/2012
63
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
5
funcionabilidade
enchimento
parada
lavagem
...
H pausatampafechada
tampa levantada
Page-Jones, M. Fundamentos do Desenho
Orientado a Objeto com UML. Makron Books, 2001.
Nodo (H) registra o histórico
do último estado
Estado Aninhado
� Estado de Histórico
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
6
Command Collecting
Copying
CleaningUp
BackingUp
H
End-of-backup
pause
16/03/2012
64
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
7
Exercício 5Exercício 5Exercício 5Exercício 5
Considerando o diagrama de estados abaixo e a seqüência de eventos listada abaixo,
marque a alternativa correta:
estA
estC
estD
est2
H
estB
ev1
new ev2
ev3
ev5
ev0
ev4
Eventos: new, ev1, ev0, ev2, ev3, ev5, ev0, ev2
a) Após a ocorrência de eventos listada o objeto encontra-se no estado estA
b) Após a ocorrência de eventos listada o objeto encontra-se no estado estC
c) Após a ocorrência de eventos listada o objeto encontra-se no estado estB
d) Após a ocorrência de eventos listada o objeto encontra-se no estado estD
e) Após a ocorrência de eventos listada o objeto encontra-se no estado inicial
� Estados concorrentes
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
8
Ociosa
Manutenção
Testando
dispositivos
Auto
Diagnóstico
Esperando Processando
Comando
Testando
Comandando
Iniciar manutenção
16/03/2012
65
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
9
inscrito
Matriculado
cursando 
disc iplinas
realizando 
TCC
H
Não 
selecionado
cursando 
disc iplinas
Aguardando 
diploma
Desligado
when( falecimento, desistência, mudança, etc, etc )
realizando 
TCC
Selecionado
não selecionado
selecionado
when( disciplinas concluídas ) when(TCC entregue)[ 
tcc.conceito >= REG ]
when( matriculaEfetuada )
when( prazo matriculado superado )
H
Trancadoretomada
Diplomado
trancamento solicitado( data )
when( diploma entregue )
Classe Aluno ou MatrículaClasse Aluno ou MatrículaClasse Aluno ou MatrículaClasse Aluno ou Matrícula
Notação usada por diversas
Ferramentas para
indicar concorrência
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
13
0
DTE para
PacMan
16/03/2012
66
� Engenharia de Produção com DTE (1)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
13
1
Waiting
GettingToken
GettingBody
put(c) [c==‘<‘]
put(c) [c==‘>‘]
put(c) [c==‘;‘] / return true
put(c) [c/=‘<‘] / return false
put(c) [c/=‘>‘] / return false
put(c) [c/=‘;‘]
/ body.append(c); return false
Processamento de XML
� Engenharia de Produção com DTE (2)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
13
2
class MessageParser {
Public boolean put(char c) {
switch(state) {
case Waiting:
if (c == ‘<‘) {
state = GettingToken;
token = new StringBuffer();
body = new StringBuffer();
}
break;
case GettingToken:
if (c == ‘>’) state = GettingBody
else token.append(c);
break;
case GettingBody:
if (c == ‘;’) {
state = Waiting;
return true; }
else body.append(c);
}
return false;
...
16/03/2012
67
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
13
3
Agencia
numero
nome
estado : ativa, inativa
Pessoa
ContaBancaria
numero
saldo
estado
limite
dataCriação
dataEncerramento
depositar()
sacar()
aplicarJuros()
0..*0..*
0..*
+titular
0..*
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
13
4
Agencia
numero
nome
estado : ativa, inativa
Class AgenciaClass AgenciaClass AgenciaClass Agencia {
...
final int ativa = 10;
final int inativa = 20;
desativar(data) {
if (estado == ativa) {
if (não existam contas vinculadas à agência
{
estado == inativa;
dataEncerramento = data;
}
}
Ativa
Inativa
desativarAgência( data )[ não existam contas 
vinculadas à agência ]
Novos atributos:
dataCriação,
dataEncerramento
16/03/2012
68
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
13
5
ContaBancaria
numero
saldo
estado
limite
dataCriação
dataEncerramento
Disponivel
Bloqueada
realizarDeposito( quantia, data ) / depositar(data, quantia)
realizarSaque( data, quantia ) / 
sacar(quantia)
usando limite de 
crédito
when( saldo >= 0 )
realizar deposito( quantia, data ) / depositar(quantia, data)
realizarSaque( data, quantia )[ quantia <= saldo 
+ limite ] / sacar(quantia)
after( 12 dias ) / aplicarJuros()when( autorizacao gerente )
criar( data, pessoa, agência ) / dataCriação := data; titular := pessoa; this.agência := agência
solicitaçãoEncerramento( data )[ saldo == 0 ] / 
dataEncerramento := data
when( cheque sem fundos pela 2a vez )
realizarSaque( data, quantia )[ quantia > saldo 
AND saldo+limite >= quantia ] / sacar(quantia)
Processo e Heurísticas para Construção de 
diagramas de transições de estados
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
13
6
16/03/2012
69
� Quantidade de Estados
◦ Em sistemas bastante simples, a definição dos 
estados de todos os objetos não é tão trabalhosa.
◦ No entanto, o crescimento dos estados de um 
sistema cresce exponencialmente com o número de 
objetos
◦ Torna impraticável a construção de um único 
diagrama para todo o sistema 
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
13
7
� Um DTE por classe
◦ Para resolver o problema da explosão exponencial 
de estados, os diagramas de estados são 
desenhados por classe.
� Desvantagem: dificuldade na visualização do estado do 
sistema como um todo.
� Essa desvantagem é parcialmente compensada pelos 
diagramas de interação.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
13
8
16/03/2012
70
� Identificação de Transições
◦ Nem todas as classes de um sistema precisam de 
um DTE.
� Somente classes que exibem um comportamento 
dinâmico relevante.
� Objetos cujo histórico precisa ser rastreado pelo 
sistema são típicos para se construir um diagrama de 
estados. 
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
13
9
� Processo de construção de DTEs (1)
◦ Identifique os estados relevantes para a classe.
◦ Identifique os eventos relevantes. Para cada 
evento, identifique qual a transição que ele 
ocasiona.
◦ Para cada estado: identifique as transições 
possíveis quando um evento ocorre.
◦ Para cada estado, identifique os eventos 
internos e ações correspondentes.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
14
0
16/03/2012
71
� Processo de construção de DTEs (2)
◦ Para cada transição, verifique se há fatores que 
influenciam no seu disparo. (definição de 
condições de guarda e ações).
◦ Para cada condição de guarda e para cada ação, 
identifique os atributos e ligações que estão 
envolvidos.
◦ Defina o estado inicial e os eventuais estados 
finais.
◦ Desenhe o DTE.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
14
1
� Informações para o modelo de classes
◦ A construção de um DTE freqüentemente leva à 
descoberta de novos atributos para uma classe
� principalmente atributos para servirem de abstrações 
para estados.
◦ Além disso, este processo de construção permite 
identificar novas operações na classe
� pois os objetos precisam reagir aos eventos que eles 
recebem.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
14
2
16/03/2012
72
� Uso do DTE no processo de desenvolvimento
◦ Os diagramas de estados podem ser construídos 
com base nos diagramas de interação e nos 
diagramas de classes. 
◦ Durante a construção do diagrama de estados para 
uma classe, novos atributos e novas operações 
podem surgir.Essas novas propriedades devem ser 
adicionadas ao modelo de classes.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
14
3
� Uso do DTE no processo de 
desenvolvimento (continuação)
◦ O comportamento de um objeto varia em função 
do estado no qual ele se encontra. 
◦ Pode ser necessária a atualização de uma ou mais 
operações de uma classe para refletir o 
comportamento do objetos em cada estado.
◦ Por exemplo, o comportamento da operação 
sacar()sacar()sacar()sacar() da classe ContaBancáriaContaBancáriaContaBancáriaContaBancária varia em função 
do estado no qual esta classe se encontra 
� saques não podem ser realizados em uma conta que 
esteja no estado bloqueadabloqueadabloqueadabloqueada.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
14
4
16/03/2012
73
� Quais são as classes candidatas a possuírem 
DTE?
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
14
5
Ativo,
Inativo,
Aposentado
Ativo,
Inativo,
Matriculado,
Não matriculado,
Concluinte,
Concluído,
Etc.
Ativo,
Inativo
Atual,
Passada,
Aberta (p/ inclusão)
Fechada
Etc
*
� Observação importante
◦ Muitas vezes as regras do negócio precisam ser 
flexibilizadas no sistema implementado
◦ Tipicamente necessário em decorrência de erros no 
preenchimento de dados ou ainda em função de 
decisão administrativa de alto nível
◦ Prever as situações e criar transições com 
estereótipo <<exception>>
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
14
6
16/03/2012
74
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
14
7
� Exercício 
◦ Escolha uma classe do sistema escolhido e faça um 
diagrama de estado
Imifarma S.A. - Programação 
Orientada a Objetos
14
8
16/03/2012
75
Diagrama de Atividades
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
14
9
� “Tipo especial de diagrama de estados, onde 
são representados os estados de uma estados de uma estados de uma estados de uma 
atividadeatividadeatividadeatividade, ao invés dos estados de um estados de um estados de um estados de um 
objetoobjetoobjetoobjeto.”
� Estados de Atividade:
◦ Exemplo 1: passos de um algoritmo
◦ Exemplo 2: etapas de um workflow
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
15
0
16/03/2012
76
� Um diagrama de atividade exibe os passos de 
uma computação. 
◦ Cada estado é um passo da computação, onde o 
sistema está realizando algo. 
◦ É orientado a fluxos de controle (ao contrário dos 
DTEs que são orientados a eventos).
� Fluxogramas estendidos...
◦ Além de possuir toda a semântica existente em um 
fluxograma, permite representar ações concorrentes e 
sua sincronização.
� Elementos podem ser divididos em dois 
grupos: controle seqüencial e controle paralelo.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
15
1
� Notação básica
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
15
2
16/03/2012
77
� Concorrência/Paralelismo
◦ Fluxos de controle paralelos: dois ou mais fluxos 
sendo executados simultaneamente.
◦ Uma barra de bifurcaçãobarra de bifurcaçãobarra de bifurcaçãobarra de bifurcação recebe uma transição de 
entrada, e cria dois ou mais fluxos de controle 
paralelos.
� cada fluxo é executado independentemente e em paralelo com 
os demais.
◦ Uma barra de junçãobarra de junçãobarra de junçãobarra de junção recebe duas ou mais transições 
de entrada e une os fluxos de controle em um único 
fluxo.
� Objetivo: sincronizar fluxos paralelos.
� A transição de saída da barra de junção somente é disparada 
quando todas as transições de entrada tiverem sido disparadas.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
15
3
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
15
4
Selecionar local
Contratar arquiteto
Desenvolver plano
Orçar plano
[rejeitado]
[aceito]
Fazer trabalho no
local
Fazer trabalho em
outros setores()
Concluir construção
:CertificadoDeHabitação
[concluído]
Estado inicial
Estado de ação
Concorrência
(bifurcação)
Estado da atividade
com
submáquina
Fluxo de
Objetos
Objeto
Estado
Fluxo: Construção de uma Casa
D
ia
g
ra
m
a
 d
e
 A
ti
vi
d
a
d
e
s
16/03/2012
78
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
15
5
� Diagrama de Atividades: SwimlanesSwimlanesSwimlanesSwimlanes
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
15
6
16/03/2012
79
� Geração de código: exemplo (1)
◦ Classe Linha: método interseção
� Um parâmetro de entrada (l: Linha) e um de retorno
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
15
7
� Geração de código: exemplo (2)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
15
8
Point Line:: intersection (l: Line) {Point Line:: intersection (l: Line) {
if (slope == l.slope) return Point(0,0)if (slope == l.slope) return Point(0,0)
else {else {
int x = (l.delta int x = (l.delta -- delta) / (slope delta) / (slope -- l.slope);l.slope);
int y = (slope * x) + delta;int y = (slope * x) + delta;
return Point(x,y);return Point(x,y);
}}
}}
16/03/2012
80
� Diagrama de Atividades: Uso
◦ O diagrama de atividades é pouco utilizado na 
prática para modelagem de aspectos temporais de 
software
◦ É fortemente utilizado na modelagem de fluxos de 
trabalho de processos negócio
� A própria descrição do Processo Unificado é 
fortemente baseada em diagramas de atividades
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
15
9
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
16
0
16/03/2012
81
-Diagramas de Interação:
-Diagrama de Seqüência
-Diagrama de Colaboração ou Comunicação
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
16
1
� Diagramas de Interação
◦ Interações entre objetos
� Sequência de trocas de mensagem entre um conjunto 
de objetos para realizar um caso de uso.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
16
2
Ator Ator
Caso de Uso
Objeto Objeto
Evento
de
entrada
(estímulo)
Mensagem Evento
de
saída
(resposta)
Tempo
16/03/2012
82
� Diagrama de Interação
◦ Identifica os estados de um objeto em um caso de 
uso específico
◦ Aspectos temporais
� Decisões
� Ordem dos eventos
◦ Dois tipos
� Diagrama de Sequência
� Diagrama de Colaboração
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
16
3
� Descrição
◦ Provê ordem temporal
◦ Mensagens são trocadas entre objetos e classes
◦ Baseia-se em um caso de uso
◦ Apóia-se no diagrama de Classes para determinar 
classes envolvidos
◦ Identifica o ator e o evento gerador da 
funcionalidade
◦ Descreve como uma funcionalidade deve acontecer
16/03/2012
83
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
16
5
� Características
◦ Há preocupação com ordem das ações
◦ Na Análise, erros e situações de tratamento de 
exceção nãonãonãonão são considerados
◦ Geralmente envolve a interação do sistema com 
os usários
◦ Cada mensagem é rotulada com
� nome
� argumentos
� informações de controle
� Condições de guarda
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
16
6
16/03/2012
84
� Características
◦ Principal objetivo: identificar quais mensagens 
devem ser implementadas pelas classes
� Classe/Objeto Emissor da mensagem é um Cliente
� Classe/Objeto Receptor da mensagem é um Servidor
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
16
7
Emissor Receptor
mensagem(parâmetros)
Mensagem deve ser implementado na
Classedo objeto receptor!
� Tipos de Interações:
• síncronasíncronasíncronasíncrona - o emissor fica parado à espera de resposta
• retornoretornoretornoretorno de mensagem síncrona
• assíncronaassíncronaassíncronaassíncrona - o emissor não fica parado à espera de 
resposta
• SimplesSimplesSimplesSimples - não se decide se é síncrona, de retorno ou 
assíncrona
16/03/2012
85
� Características
◦ Tipos de Interação
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
16
9
Simples
Síncrona
Assíncrona
Retorno
Somente fazem sentido
se a linguagem de
programação permitir
esta alternativas
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
17
0
+ocorrência
Equipe
nome
Campo
dimensoes
nome
Arbitro
nome
Jogo
hora-inicio
hora-fim
data 2*
+participante
2*
0..n
+local
0..n
realizado em
0..*
+principal
0..*
mediado por
2
0..n
+auxiliar2
0..n
Posição
nome
Gol
instante
Cartão
instante
tipo : verm, amarelo
Escalação
Jogador
nome
0..*0..*
marcado por0..*0..*
11
0..*
+t itular11
0..*
5
0..*
+reserva
5
0..*
Súmula
0..*0..*
0..*+ocorrência 0..*
possui
Subst ituição
instante
0..*
+substituído
0..*
0..*
+substituto
0..*0..6+ocorrência0..6
16/03/2012
86
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
17
1
 : Juiz : Juiz
Controlador
Gol
Controlador
Gol
s : Súmulas : Súmula e : Equipee : Equipe
 : Gol : Gol
1: registrarGol(s)
7: criarGol(instante, jogador-selecionado, s)
8: <<construtor>> (instante, jogador-selecionado, s)
2: obterEquipe()
3: e
4: obterJogadores()
5: jogadores
6: jogadores
Componente de Implementação (IU)
s: súmula foi recuperado
em outro CDU
A seleção do jogador é
implícita (pois não envolve
troca de mensagens)
1: obterJogadores(s, e)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
17
2
 : Federação : Federação
jogador : 
Jogador
jogador : 
Jogador
1: obterGolsMarcadosJogador(jogador)
2: obterGols()
3: númeroGolsMarcados
G o l
in s t a n t e
Jo g a d o r
n o m e
0 . . *
Obtém todos os gols marcados por um jogador na sua vida,
independente da equipe onde atuou.
16/03/2012
87
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
17
3
Equipe
nome
Jogo
hora-inicio
hora-fim
data 2*
Súmula
Gol
instante
Jogador
nome
0..*
0..*
Objetivo:
Obter o maior artilheiro de
toda história registrada no
sistema de uma equipe eeee.
Classes envolvidas
Resumo:
-A partir do objeto e de Equipe são localizadas
as instâncias de Súmula, as quais são consultadas para
obter os gols e respectivos autores (Jogador).
-O processo de totalização de quantos gols cada
Jogador marcou não aparece no diagrama em virtude
de não envolver troca de msgs.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
17
4
 : Federação : Federação
ControladorIUControladorIU e : Equipee : Equipe : Súmula : Súmula : Gol : Gol
Repetir para cada objeto de súmulas
Repetir para cada objeto de gols
1: 
2: obterSúmulas
3: súmulas
4: obterGols()
5: gols
6: obterJogador()
7: jogador
8: maiorArtilheiro: Jogador
16/03/2012
88
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
17
5
 : Juiz : Juiz
ControladorGolControladorGol : Jogo : Jogo : Equipe : Equipe
 : Gol : Gol
1: registrarGol()
2: recuperarJogos()
3: jogos
4: jogos
5: obterEquipes(jogo)
6: obterEquipes(jogo)
7: equipes
8: equipes
9: obterJogadores(equipe, jogo)
10: obterJogadores(equipe, jogo)
11: jogadores
12: jogadores
13: registrar(instante, jogo, equipe, jogador)
14: <<construtor>> (instante, jogo, equipe, jogador)
15: gol Cadastrado
16: gol Cadastrado
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
17
6
 : Federação : Federação
Controlador : 
ControladorUI
Controlador : 
ControladorUI
 : Jogo : Jogo
objetivo: sendo fornecidos um objeto de arbitro e outro de equipe, 
localizar os jogos onde a equipe foi vencedora.
1: obterVitoriasArbitroEquipe(umArbitro, umaEquipe)
2: obterJogosArbitro(umArbitro)
3: jogosÁrbitro
4: obterJogosEquipe(umaEquipe)
5: jogosEquipe
6: obterEquipeVencedora()
7: equipeVencedora
8: [umaEquipe == equipeVencedora] acrescentarJogo()
repetir para todos os jogos resultantes da interseção de jogosÁrbitro com 
jogosEquipe
9: jogosVitoriasArbitroEquiipe
16/03/2012
89
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
17
7
Voz
numChamado
duracao
TransmissaoDados
bytesTransferidos
Cliente
nome
Conta
numTelefone
1..*1..*
possui
PagamentoFatura
data
Consumo
data-inicio
valor
hora-inicio
FaturaMensal
dataVenc
valor
0..*0..*
0..10..1
possui
0..*0..*
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
17
8
 : Funcionário : Funcionário
Controlador : 
controller
Controlador : 
controller
 : FaturaMensal : FaturaMensal
1: obterMaioresConsumoDados(mes)
2: obterFaturasMes(mes)
3: faturas
4: obterConsumoTransmissaoDados
5: consumoDados
repetir para todas as instâncias de faturas
8: clientes
clientes é um conjunto de objetos 
de cliente que fizeram uso de 
transmissão de dados no mês 
indicado, ordenado de forma 
decrescente
6: obterCliente()
7: cliente
16/03/2012
90
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
17
9
Atendente
name
(from Use Case View)...)
Gerente
(from Use Case View)...)
Funcionario
nome
senha
Telefone
numero
codigo_area
Cliente
nome
sexo
email
dataCadastro
tipo : normal/especial
(from Use Case View)...)
0..*0..*
cadastrado por
0..* 10..* 1
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
18
0
Serviço
Computador
numero
estado : ocupado/disponivel
estado2 : funcionando/defeito
Loja
numero
endereco
0..*0..*
AcessoComputador
Impressão
tipo
Produto
Validade
dias_semana
horario_inicio
horario_fim
Item
nome
preço
Promoção
codigo
desconto
estado : hab/desab
paraClienteVIP : boolean
0..*
0..*
0..*
0..*
Promoção com 
paraClienteVIP valendo 
true, ela é vál ida para 
Clientes com valor de 
tipo = "Especial"
16/03/2012
91
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
18
1
quantidade
quantidade
VendaAvulsa
data
Item
nome
preço
1..*
0.. *
1..*
0.. *
consome
Cliente
nome
sexo
email
dataCadastro
tipo : normal/especial
(from Use Case View)...)
Conta
valor
Sessão
data
hora_inicio
hora_fim 1..*0..* 1..*0..*
consome
0..*0..*
realiza
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
18
2
 : Atendente : Atendente
Tela de Geração 
de Conta
Tela de Geração 
de Conta
 : Sessão : Sessão : Item : Item
conta : Contaconta : Conta
 : Promoção : Promoção
1: gerarContaSessão(s)
2: obter(s)
3: s
4: obterItensConsumidos
5: obterItens
6: itens
7: itens
10: obterPreço
11: preçoUnitário
12: obterQuantidade(item)
13: quantidade
8: obterNome
9: nome
repetir enquanto houver itens na sessão de consumo
15: criar(s, itens)
16: conta
17: conta
14: 
Obter conta de consumo de itens e serviços
Obs: não considera as promoções
16/03/2012
92
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
 : Atendente : Atendente
Tela Inserção 
Computador
Tela Inserção 
Computador
 : Loja : Loja
comp : 
Computador
comp : 
Computador
1: inserirComputador(loja)
2: criar(número)
3: comp
4: recuperar(loja)5: loja
8: inserir(comp)
9: computador inserido
10: computador inserido
6: vincularLoja(loja)
7: loja vinculada
� Descrição
◦ Conhecidos como diagrama de Colaboração até a 
UML 1.5
◦ Amplamente associado ao diagrama de Seqüência
◦ Não se preocupa com a temporalidade
◦ Concentra-se em como os objetos ou classes estão 
vinculados
◦ Identifica quais mensagens são trocadas
16/03/2012
93
 : cliente
 : Locadora
 : Carro
a : 
Aluguel
1: solicitaAluguel( )
5: setDataLocacao( )
6: calcularValor( )
2: verificaDisponibilidade( )
3: disponibilidade
4: [disponibilidade == ok] : efetuarAluguel( )
7: a