Diagramas de Seqüência
Projeto de Sistemas de Software
Interações
2

Comportamento que
 Envolve
conjunto de mensagens trocadas entre objetos
dentro de um determinado contexto
 Objetiva atingir resultado específico


Acontecem em função da troca de mensagens entre
objetos
Usadas para a modelagem dos aspectos dinâmicos
de um sistema
Comunicação entre Objetos
3
mensagem
o:Ob1
Mensagem =

:Ob2
Ident. Objeto
Ident. Operação
Parâmetros
Mensagem

Recepção de mensagem por um objeto


Considerado instância de evento
Decorrência da passagem de uma mensagem
Repercute ação representada por um comando executável
 Comando Executável: abstração de procedimento computacional

Diagramas de Interação
4

Deseja-se representar o comportamento de vários objetos



Objetivo



Dentro de um único caso de uso
A partir das mensagens que são passadas entre eles
Definir um contexto de caso de uso
Estabelecer os objetos que interagem e seus relacionamentos
Termo genérico que se aplica a quatro tipos de diagramas que enfatizam
interações entre objetos




Diagrama de Seqüência
Diagrama de Colaboração/Comunicação
Vista Geral de Interação
Temporal ou Timing
Duas formas de representação
5

Informações bastante similares mas de maneira
diferente
 Diagrama
de Seqüência
 Interação
enfatizando o tempo de seqüência
 Mostra objetos participando em interações de acordo com
suas linhas de vida e as mensagens que trocam
 Diagrama
 Interação
de Comunição
enfatizando o relacionamento entre os objetos
Diagrama de seqüência
6
Tempo
(top-down)
condição de guarda
ObjetoA
mensagem síncrona
[se novo]
<<create>>
ObjetoB
objeto
mensagem
mensagem (auto delegação)
(caixa de)ativação
valor de retorno
<<destroy>>
linha de vida
símbolo de destruição
Termos e conceitos
7

Objetos

Linhas de vida

Mensagens

Focos de controle
Objetos
8



Apresentados na dimensão horizontal do diagrama
Ordem dos objetos não é considerada
 Dispô-los de forma a tornar o diagrama “mais legível”
Objetos tem nomes
 obj:Classe
Ex.: joão:Dentista
:Floricultor (um objeto floricultor não identificado)
obj1: (um objeto obj1 sem classe definida)
Objetos
9
j os e
Floricultor
centra l
CentralFloricultura
fl oricul torP etrop ol is
Floricultor
j oa o:Denti s ta
1: enviarFlores("Rosas","Maria","Petropolis","Rua x, 9"):boolean
1.1: atendeCidade("Petropolis"):boolean
1.2:[se nao na cid...] getFloricultorNaCidade("Petropolis"):Floricultor
1.3: aceitaEncomenda("Rosas","Rua X,9"):boolean
Linhas de Vida
10

Dimensão vertical do diagrama

Apresentam o tempo de vida dos objetos

Pode apresentar a ativação ou a desativação dos objetos

Indicam que os objetos estão executando algo


Caixas de ativação podem ser empilhadas



Foco de controle
Indica chamada de método do próprio objeto
Objeto jose no slide anterior
Podem representar a criação e a destruição de objetos
Linhas de Vida
es toq ue
11
v end ed or
Criação
1:new()
p ed i d o
Linhas de vida
2:*[*] //adicionarItem2.1: verificarDisponibilidade
2.2: reservarItem
3: confirmarPedido
Destruição
3.1: confirmarPedido
4: kill()
(Caixas de) Ativação
Mensagens
12

Objetos interagem através da troca de mensagens

Setas sólidas que vão do objeto solicitante para o solicitado



Para o próprio objeto: auto-delegação
Rotulados com os nomes dos estímulos mais os argumentos (ou
valores dos argumentos) do estímulo
Sintaxe
return

:= message(parameter:parameterType):returnType
onde





return é o nome do valor de retorno
message é o nome da mensagem
parameter é o nome de um parâmetro da mensagem
parameterType é o nome do tipo desse parâmetro
returnType é o tipo do valor de retorno
Mensagens - Tipos
13

Tipos de ação que uma mensagem pode representar

call

Invoca uma operação sobre um objeto


Objeto pode mandar uma chamada para si próprio
 Resultando na execução local de uma operação
return
Representa o retorno de um valor para o objeto que chamou a
operação
 Opcional


create


<<create>>
kill()
<<destroy>>
Criação de um objeto
destroy

new()
Eliminação de um objeto
Mensagens - Representações
14
Símbolo
Significado
Mensagem síncrona
Mensagem assíncrona
Mensagem de retorno (opcional)
Mensagens
15
Auto-delegação
j os e
Floricultor
centra l
CentralFloricultura
fl oricul torP etrop o
Floricultor
j oa o:Denti s ta
1: enviarFlores("Rosas","Maria","Petropolis","Rua x, 9"):boolean
1.1: atendeCidade("Petropolis"):boolean
1.2:[se nao na cid...] getFloricultorNaCidade("Petropolis"):Floricultor
1.3: aceitaEncomenda("Rosas","Rua X,9"):boolean
mensagens
Mensagens – Condições de Guarda
16

Mensagens podem apresentar condições de guarda
 condições em que a mensagem é enviada
 [condição de guarda]
:Aluno
:Sistema
:Impressora
login()
sistemaOk
Matrícula
matricula()
[sem vaga]
turmaCheia
[com vaga]
imprimirRelatório()
matriculado
Mensagens - Iteração
17

Uma mensagem pode ser enviada repetidas vezes
*
mensagem(...)
es toq ue
v end ed or
1:
vendedor
pedido
p ed i d o
2:*[*] //adicionarItem2.1: verificarDisponibilidade
2.2: reservarItem
* adicionarItem
3: confirmarPedido
4:
18
3.1: confirmarPedido
Foco de Controle
19


Período de tempo que o objeto executa uma ação
Relação de controle entre ativação e o responsável
pela sua invocação
Diagrama de Seqüência Construção
20

Escolher um caso de uso

Identificar os objetos que fazem parte da interação

Identificar o objeto que começa a interação

Identificar as mensagens trocadas entre os objetos

Identificar a sequência destas mensagens
Análise OO do RUP
21
Objetivo
Modelar o comportamento de cada caso de uso com o objetivo
de detalhar os serviços de negócios oferecidos pelo sistema
Uso de apenas 3 tipos de classes

Fronteira (boundary)


Controle (control)


Classes de interface com o mundo externo
(ex: GUI, sistemas externos)
Coordenam o comportamento do caso de uso definindo uma
interface entre classes fronteira e entidade
Entidade (entity)

Classes que armazenam informações manipuladas pelo sistema
Blog - Casos de uso
22
blogSystem
Criar Blog
Criar Comentario
Ler Conteudo
Usuario
<<include>>
Ler Nota
Ler Comentario
<<include>>
<<include>>
Remover Comentario
Remover Conteudo
Dono do blog
Criar Nota
Remover Nota
Blog - Diagrama de Seqüência: Criar
blog
23
: UsuarioBlog
: GUIBlog
: ControladorBlog
: Blog
1: criarBlog(titulo, usuario)
2: criarBlog(titulo, usuario)
3: new Blog(titulo, usuario, dataCriacao)
Blog - Diagrama de Seqüência: Criar
Nota
24
: UsuarioBlog
: GUIBlog
: ControladorBlog
: Blog
: Nota
1: criarNota(usuario, idBlog, comentario)
2: criarNota(usuario, idBlog, comentario)
3: consultarBlog(idBlog)
4: getDono()
5: [se dono == usuario] new Nota(comentario, usuario)
Estudo de Caso
Estudo de Caso
Considerações sobre o que o sistema se propõe a fazer:
 O sistema suportará um cadastro de clientes, onde cada cliente
cadastrado poderá ter várias contas correntes, vários dependentes
ligados a ele, e várias contas de poupança.
 Cada dependente poderá possuir várias contas de poupança, mas não
poderá ter uma conta corrente própria.
 Entendemos poupança como uma conta que possui um valor, um prazo
de aplicação a uma taxa de juros (definida no vencimento da poupança).
 Entendemos Aplicações Pré-fixadas como uma aplicação de um valor,
em um prazo pré-determinado a uma taxa de juros previamente
definida.
 Tanto a conta-corrente quanto a poupança deverão manter um histórico
de todas as movimentações de crédito, débito, transferências e
aplicações de pré-fixados (pré-fixados apenas para conta corrente).
 Uma conta corrente poderá ter várias aplicações pré-fixadas ligadas a
ela.
Fases do Desenvolvimento
Análise de Requisitos: Modelar o diagrama de casos de uso do sistema.
O sistema implementará funções básicas que serão desempenhadas pela
Administração do banco e pelos seus clientes. As principais funções do sistema
são:
 Cadastrar novo cliente
 Excluir ou editar cliente
 Cadastrar dependente
 Excluir ou editar dependente
 Abrir conta corrente
 Fechar conta corrente
 Abrir poupança
 Fechar poupança
 Movimentar conta corrente
 Aplicar em pré-fixados
 Consultar histórico de conta corrente ou poupança
 Cadastrar Agência
 Excluir ou Editar Agência
Diagrama de Casos de Uso
Representa uma sucessão particular de transações entre o sistema e
um ator (um usuário final ou um sistema externo ao sistema
analisado).
Permite definir todos os modos nos quais os usuários interagem com
a aplicação a ser construída.
Diagrama de Casos de Uso
Cadastrar
Cliente
Remover ou
Atualizar Cliente
Cadastrar
Cadastrar
Dependente
Cliente
Abrir Conta
Corrente
Remover ou
Atualizar
Dependente
Fechar Conta
Corrente
Abrir
Poupança
Cadastrar
Operação
(Histórico)
Administração do
Banco
Remover ou Atualizar
Operação (Histórico)
Fechar Poupança
Cadastrar
Agência
Remover ou
Atualizar Agência
Diagrama de Casos de Uso
Movimentar Conta
Corrente
<<usa>>
Gerar
Histórico
<<usa>>
Consultar Histórico
de Conta Corrente
Aplicar em préfixados
Cliente
Diagrama de Casos de Uso
Manter
Dependente
Manter
Agência
Movimentar Conta
Corrente
Manter
Cliente
Cliente
Consultar Histórico
de Conta Corrente
Administração do
Banco
<<usa>>
Manter Operação
(Histórico)
Aplicar em préfixados
<<usa>>
Manter Conta
Corrente
<<estende>>
Manter Poupança
Fases do Desenvolvimento
Análise: Modelar o diagrama de classes.
Na fase de análise, tendo em mãos o diagrama de use-case, podemos definir o
diagrama de classes do sistema.
Este primeiro diagrama da fase de análise deverá ser totalmente despreocupado
de qualquer tipo de técnica relacionada à implementação do sistema, ou seja,
métodos e atributos de acesso a banco de dados, estrutura de mensagens entre
objetos, etc não deverão aparecer nesse primeiro diagrama, apenas os tipos de
objetos básicos do sistema.
Diagrama de Classes
O Diagrama de Classes é uma estrutura lógica que permite o
desenvolvimento das Classes do Sistema.
Para cada Classe desenvolvida no diagrama é possível especificar
seus atributos e operações, assim como o relacionamento com as
demais classes do sistema.
Diagrama de Classes
Agência
Cod_Agencia:Caracter
Nome_Agencia: Caracter
Histórico
Data: Data
Operação: Operação
Valor: Numérico
Criar ( )
Destruir ( )
Criar ( )
Destruir ( )
1
Possui
*
*
*
Possui
1
1
Conta Corrente
Operação
Cod: Caracter
Saldo: Numérico
Vetor_Aplic_PreFix: Aplic_Pre_Fixadas
Vetor_Historico: Historico
Agência: Caracter
Criar ( )
Destruir ( )
Depositar ( )
Debitar ( )
Transferir ( )
Obter_Saldo ( )
Aplicar_Prefix ( )
Tirar_Extrato ( )
Retirar_Aplic_Prefix ( )
Gera
Cod_Agencia:Caracter
Nome_Agencia: Caracter
Criar ( )
Destruir ( )
Aplicações Pré Fixadas
0
*
Valor: Numérico
Data_Venc: Data
Taxa: Numérico
Criar ( )
Destruir ( )
Diagrama de Classes
Conta Corrente
*
1
Cliente
Possui
Cod: Caracter
Saldo: Numérico
Vetor_Aplic_PreFix: Aplic_Pre_Fixadas
Vetor_Historico: Historico
Agência: Caracter
Poupança
Possui
Data_Venc: Data
*
Criar ( )
Destruir ( )
1
*
Possui
1
Dependente
Nome: Caracter
CPF: Numérico
Parentesco: Caracter
Vetor_Poupanças: Poupança
Criar ( )
Destruir ( )
Localizar ( )
Abrir_Poupança ( )
Fechar_Poupança ( )
Possui
*
Criar ( )
Destruir ( )
Localizar ( )
Abrir_Conta_Corrente ( )
Remover_Conta_Corrente ( )
Adic_Dependente ( )
Excluir_Dependente ( )
Abrir_Poupança ( )
Fechar_Poupança ( )
1
Diagrama de Objetos
Diagrama de Classes
Conta
Cliente
possui
Cod: Caracter
Saldo: Numérico
*
Cod: Caracter
Saldo: Numérico
Agência: Agência
Aplicações
*
Cod_Conta: Caracter
Nome_Aplicação: Caracter
cl1: Cliente
cl2: Cliente
Diagrama de Objetos
Código: "205-6712-09"
Saldo: 100
c1: Conta
: Conta
c2: Conta
: Conta
Cod: “Cc2310
Saldo: 50
Agência: Central
Cod: “Cc205"
Saldo: 30
Agência: Rio Bco
c3: Conta
:Aplicação
:Aplicação
:Aplicação
:Aplicação
:Aplicação
:aplicação
CurtoPrazo
:aplicação
Cod_Conta: Cc2310
Nome_Aplicação: Fix
:Aplicação
Cod_Conta: 205
Nome_Aplicação: Fdo
FdoFix
Fases do Desenvolvimento
Análise: Modelar os diagramas de interação.
Já tendo em mãos as funções primordiais do sistema (diagrama de casos de
uso) e o diagrama de classes da análise do domínio do problema, partiremos
agora para traçar como estas classes irão interagir para realizar as funções do
sistema.
Nesta fase nenhum tipo de técnica de implementação deve ser considerada.
Para modelar como os objetos do sistema irão interagir entre si, utiliza-se o
diagrama de seqüência ou o de colaboração.
E modela-se um diagrama para cada função (caso de uso) definida no diagrama
de casos de uso.
Escolhe-se o diagrama de seqüência para dar mais ênfase à ordem cronológica
das interações entre os objetos.
Já se faz necessário utilizar idéias básicas da modelagem da interface do
sistema como as janelas. Mas esses objetos de interface serão totalmente
detalhados na fase de design.
Diagrama de Seqüência
Um Diagrama de Seqüência mostra interações de objetos
organizadas em uma seqüência de tempo e de mensagens trocadas,
auxiliando na elaboração dos cenários, implementando a seqüência
dos eventos entre os atores e objetos do Sistema.
Diagrama de Seqüência
Administração
do Banco
:Janela Abrir Conta
Corrente
:Cliente
:Conta Corrente
:Histórico
1: Dados do Cliente()
2: Localizar (Caracter)
3: Criar (Cliente)
4: Criar (Operação)
Fases do Desenvolvimento
Análise: Modelar outros diagramas utilizados na UML para a modelagem dos
aspectos dinâmicos do sistema (diagramas de atividades e de estados).
Nesta fase, modela-se também o diagrama de estados das classes.
Mas este se enquadra em situações onde o comportamento dos objetos é
importante para aplicação.
Por exemplo, em casos de modelagens de sistemas para equipamentos
mecânicos.
Diagrama de Estados
A idéia básica do Diagrama de Estado, é estudar certos tipos de
lógicas que envolvem transições possíveis entre diferentes estados.
Um Diagrama de Estados descreve os possíveis estados de uma
classe e os eventos que causam transições dos estados.
São úteis para mostrar o ciclo de vida de uma classe.
Diagrama de Estados
Objeto: Conta Corrente
Criada
Adicionar Conta a Cliente
AssociadaClosed
a Cliente
entry: Finalize
course
entrada:
Atualizar
Cliente
saída: Emitir nº Conta
Remover conta
Fechada
fazer: Enviar msg Fechamento
Diagrama de Atividades
A principal utilização do Diagrama de Atividades é para modelar fluxos
de procedimentos (workflow), onde existe o trabalho cooperativo.
Diagrama de Atividades
Cliente
Administração do Banco
Solicitar abertura
conta
Abrir
conta
Associar cliente a
conta
Movimentar
conta
[Solicitação_encerramento=Sim]
Encerrar
conta
H
Modelos da Análise de Requisitos (Domínio do Problema)
Cliente
Conta
1
*
...
Poupança
...
...
...
Conceitos do domínio
Modelos da Análise
:Sistema
Processo de
Abertura de Conta
:Caixa
Entrar dados ()
...
Diagrama de Casos de Uso
Cenário
Realização do Caso
de Uso com
Diagramas de
Interação
Caixa
Evts sistema
1.Cliente chega
2.Caixa cadastra
3.Gerente cria conta
...
Classes
conceituais
inspiram nomes
de algumas
classes no
Projeto
Processo
Abertura
NovoCliente()
Diagrama de Seqüência do Sistema
Modelos do Projeto
:Abertura
:Rel de Contas
CriarNovaConta()
AssociarCliente()
:ContaCliente
entraDados(CPF,tpcta)
adicionarDados(CPF,tpcta)
...
Abertura
...
criarNovaCta()
entrarDados(...)
...
Relação de Contas
1
*
...
ObterEspecificação(...):EspecificaçaoCta
...
Classes
descobertas no
Projeto podem
ser resumidas
em
Diagrama de
Classes
Diagramas
detalhados
no Projeto
Fases do Desenvolvimento
Testes:
Nesta fase, a aplicação deverá ser testada.
Deve-se verificar se o programa suporta toda a funcionalidade que lhe foi
especificada na fase de análise de requisitos com o diagrama de casos de uso.
A aplicação também deve ser testada da forma mais informal, colocando-se o
sistema nas mãos dos usuários.