Analisar Caso de Uso
Objetivos deste módulo
• Apresentar os passos necessários para realizar
a atividade analisar casos de uso e discutir
seus artefatos
• Apresentar os diagramas de seqüência,
colaboração e classes de UML
Analisar caso de uso | 2
Analisar
Serviços
Arquiteto de
Software
Projetar
Arquitetura
Projetar
Serviços
Revisor de
projeto
Prototipar
Interface gráfica
Arquiteto de
Informação
Analisar
Casos de Uso
Projetar
Casos de Uso
Projetar
Subsistemas/
componentes
Analista de
Sistemas
Projetar
classes
Revisar
Projeto
Projetar
Base de Dados
Projetista de
Banco de Dados
Análise e Projeto OO com
UML e Padrões| 3
Analisar
Serviços
Arquiteto de
Software
Projetar
Arquitetura
Projetar
Serviços
Revisor de
projeto
Prototipar
Interface gráfica
Arquiteto de
Informação
Analisar
Casos de Uso
Projetar
Casos de Uso
Projetar
Subsistemas
componentes
Analista de
Sistemas
Projetar
classes
Revisar
Projeto
Projetar
Base de Dados
Projetista de
Banco de Dados
Análise e Projeto OO com
UML e Padrões| 4
Objetivos desta atividade
• Encontrar as classes iniciais do sistema
(classes de análise) e distribuir
comportamento dos casos de uso entre elas
• Para cada classe, descrever as
responsabilidades, atributos e associações
Esta atividade é realizada para cada caso de uso!
Analisar caso de uso | 5
Visão geral dos artefatos
Documento de Glossário Documento da
Requisitos
Arquitetura
Analista de
Sistemas
Modelo de
Casos de Uso
Analisar Caso
de Uso
Diagrama de
Classes
Realização de
Caso de Uso
Diagrama de
Colaboração
Diagrama de
Seqüência
Analisar caso de uso | 6
Passos para Analisar Casos de Uso
Para cada caso de uso:
1. Encontrar classes de análise
2. Identificar persistência
Para cada classe:
3. Distribuir comportamento entre as classes
4. Descrever responsabilidades
5. Descrever atributos e associações
6. Revisar os Resultados
Analisar caso de uso | 7
Passo 1. Encontrar classes de análise
• O comportamento do caso de uso é
distribuído em classes de análise dos
seguintes tipos (estereótipos)
– fronteira
– controle
– entidade
• Estes estereótipos são uma conveniência de
análise que desaparecem no projeto
Analisar caso de uso | 8
Classes de análise: um primeiro passo em direção
ao executável
Modelo de
Casos de Uso
Classes de
Análise
Códigos Fonte
Elementos de
Projeto
Executável
Analisar caso de uso | 9
QIB - Diagrama de Casos de Uso
• Usaremos o QIB como exemplo
Desbloquear Talões
de Cheque
Efetuar Login
Solicitar Talões de Cheque
Alterar Senha
Consultar Cheques
ClienteAtor
<<include>>
Consultar Saldo
<<include>>
Realizar DOC
Consultar Extrato
Mostrar Dados da
Consulta
Realizar Transferência
Consultar Qualiti Card
Efetuar Pagamento do
Qualiti Card
Operadora do DOC
Operadora Cartão de
Crédito
Analisar caso de uso | 10
Classes de Fronteira (boundary classes)
• Isolam o sistema de mudanças no ambiente externo
• Atores devem se comunicar apenas com classes de
fronteira
• Exemplos de classes fronteira
Notação em UML
– GUI
– Interface com outros sistemas
– Interface com dispositivos
Modelam a interação entre o sistema e seu ambiente
<<boundary>>
Analisar caso de uso | 11
QIB – Efetuar Login
• Regra geral para encontrar classes de fronteira: uma
classe por cada par ator/caso de uso
ClienteAtor
Efetuar Login
<<boundary>>
TelaLogin
Analisar caso de uso | 12
QIB – Efetuar Pagamento do Qualiti
Card
• Descobrindo classes de fronteira
ClienteAtor
Efetuar Pagamento
do Qualiti Card
<<boundary>>
TelaPagamentoQualitiCard
Operadora de Cartão
de Crédito
<<boundary>>
ComunicacaoOperadoraCartao
Analisar caso de uso | 13
Descrevendo Classes de Fronteira
• GUI
– Concentre-se nas informações que serão
apresentadas, não em um projeto gráfico
• Interface com outros sistemas ou dispositivos
– Concentre-se em quais protocolos devem ser
definidos, não como serão implementados
• Concentre-se nas responsabilidades, não nos
detalhes!
Analisar caso de uso | 14
Classes de Entidade (entity classes)
• Abstrações e conceitos chaves dos casos de uso
• Fontes:
–
–
–
–
–
Notação em UML
Conhecimento do negócio
Glossário
Modelo de negócios
Documento de requisitos
Especificação do Caso de uso
Armazenam e controlam informação no sistema
<<entity>>
Analisar caso de uso | 15
QIB – Efetuar Login
• Observe o fluxo de eventos do Efetuar Login
Este caso de uso é responsável por autenticar um usuário do
sistema.
Pré-condição: nenhuma
Pós-condição: um usuário válido é logado e sua sessão é
registrada no sistema.
Fluxo de eventos principal
1. O cliente informa login e senha.
2. O sistema verifica se o login e a senha são válidos (verifica-se se
o login e senha pertencem a uma conta).
3. O sistema registra o início de uma sessão de uso.
Fluxos secundários
- No passo 2, se o login ou a senha forem inválidos, o sistema
exibe uma mensagem e volta ao passo 1.
Analisar caso de uso | 16
Orientações para encontrar
Classes de Entidade
• Usando a descrição do caso de uso, use a
abordagem tradicional de filtrar substantivos
– identifique substantivos no fluxo de eventos
– remova candidatos redundantes e vagos
– remova atores que apenas interagem com o
sistema mas não fazem parte da modelagem
– remova atributos (serão usados mais tarde) e
operações
Analisar caso de uso | 17
QIB – Efetuar Login
• Classes de entidade
<<entity>>
Usuario
<<entity>>
Conta
• A classe Conta é uma classe que armazena o login e senha
de um cliente.
• Algumas classes levantadas podem ser eliminadas e novas
serão adicionadas
Analisar caso de uso | 18
QIB – Efetuar Pagamento do Qualiti Card
• Descrição inicial
Este caso de uso é responsável por realizar o pagamento do Qualiti
Card com a operadora de cartão de crédito. Cada cliente possui
apenas um cartão como titular, estando vinculado a apenas uma
operadora.
Pré-condição: O cliente deve estar conectado ao sistema (ter efetuado
o login).
Pós-condição: O valor do pagamento é debitado da conta do cliente,
o pagamento é enviado à operadora do cartão de crédito e a transação
é registrada no sistema.
Analisar caso de uso | 19
QIB – Efetuar Pagamento do Qualiti Card
• Fluxo de eventos principal
1. O cliente informa os dados necessários para efetuar o pagamento do
cartão:
- O código de barras da fatura que deseja efetuar o pagamento.
- O valor que deseja pagar.
2. O sistema recupera a conta bancária do cliente logado.
3. O sistema verifica se o saldo da conta do cliente é suficiente para
realizar o pagamento.
4. O sistema debita da conta do cliente.
5. O sistema envia o pagamento à operadora de cartão de crédito.
6. O sistema registra a transação de pagamento e emite um
comprovante da mesma para o usuário. A transação registrada contém
os dados da conta do cliente, o código de barras da fatura, data, hora e
Analisar caso de uso | 20
valor do pagamento.
QIB – Efetuar Pagamento do Qualiti Card
• Fluxo de eventos secundários
Fluxo Principal
1.
2.
O cliente informa os dados necessários para efetuar o pagamento do cartão: - O código de
barras da fatura que deseja efetuar o pagamento. - O valor que deseja pagar.
O sistema recupera a conta bancária do cliente logado
3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar
o pagamento.
4. O sistema debita da conta do cliente.
5. O sistema envia o pagamento à operadora de cartão de crédito.
secundário
6. O Fluxo
sistema registra
a transação de pagamento e emite um comprovante da mesma para o usuário.
A transação registrada contém os dados da conta do cliente, o código de barras da fatura,
data, hora e valor do pagamento.
- No passo 3, se o saldo disponível na conta do cliente for menor que o
valor do pagamento, o sistema informa que o saldo é insuficiente e retorna
para o passo 1.
- No passo 5, se a operadora de cartão de crédito estiver inativa, o
sistema exibe uma mensagem e cancela a operação.
- Em qualquer momento o usuário pode cancelar a operação.
Analisar caso de uso | 21
QIB – Efetuar Pagamento do Qualiti
Card
• Classes de entidade
<<entity>>
PagamentoCartao
<<entity>>
CartaoCredito
<<entity>>
Conta
<<entity>>
CodigoBarras
<<entity>>
Comprovante
<<entity>>
Mensagem
<<entity>>
Cliente
Analisar caso de uso | 22
Classes de Controle (control classes)
• Coordenam o comportamento (lógica de controle) do
caso de uso
• Interface entre fronteira e entidade
• Dependente do caso de uso, independente do
ambiente
• Permitem separação entre o uso da entidade
(específico do sistema) do comportamento inerente à
entidade
Notação em UML
Coordena o comportamento do caso de uso.
Uma classe controle pode ter referência a vários objetos entidade.
<<control>>
Analisar caso de uso | 23
Orientações para encontrar
Classes de Controle
• Usualmente, uma classe de controle por caso
de uso
• Eventualmente mais de uma (comportamento
complexo) ou nenhuma (manipulação simples
de informações armazenadas)
Analisar caso de uso | 24
QIB – Efetuar Login
• Encontrando classes de controle
ClienteAtor
Efetuar Login
<<control>>
ControladorLogin
Analisar caso de uso | 25
QIB – Efetuar Pagamento do Qualiti
Card
• Encontrando classes de controle
ClienteAtor
Efetuar Pagamento
do Qualiti Card
Operadora de Cartão
de Crédito
<<control>>
ControladorPagamentoQualitiCard
Analisar caso de uso | 26
QIB – Efetuar Login
Classes de análise descobertas até o momento
<<control>>
ControladorLogin
<<entity>>
Usuario
<<boundary>>
TelaLogin
<<entity>>
Conta
Analisar caso de uso | 27
QIB – Efetuar Pagamento do Qualiti Card
Classes de análise descobertas até o momento
<<entity>>
Mensagem
<<entity>>
CodigoBarras
<<entity>>
Conta
<<entity>>
Cliente
<<entity>>
CartaoCredito
<<boundary>>
ComunicacaoOperadoraCartao
<<entity>>
Comprovante
<<entity>>
PagamentoCartao
<<control>>
ControladorPagamentoQualitiCard
<<boundary>>
TelaPagamentoQualitiCard
Analisar caso de uso | 28
Exercício – Qualiti Internet Banking
• Dado:
– Artefatos de requisitos do Qualiti Internet
Banking, especialmente o fluxo de eventos do
caso de uso RealizarDoc (ver próximos slides)
• Produzir:
– Identificação das classes de análise, com seus
estereótipos e breve descrição
Análise e Projeto OO com
UML e Padrões| 29
QIB – Realizar Doc
• Descrição inicial
Este caso de uso é responsável por realizar a transferência de valores
entre uma conta deste banco para uma conta de um outro banco. A
transferência pode ocorrer entre contas com mesmo CPF ou CPFs
distintos.
Pré-condição: o cliente deve estar conectado ao sistema (ter efetuado
o login).
Pós-condição: o valor da transferência foi debitado da conta do
cliente, o DOC foi enviado à operadora de DOC e a transação foi
registrada.
Análise e Projeto OO com
UML e Padrões| 30
QIB – Realizar Doc
• Fluxo de eventos principal
1. O cliente informa os dados necessários para a realização do DOC:
- Banco, agência e conta destino;
- CPF do favorecido;
- Valor do DOC.
2. O sistema recupera a conta bancária do cliente logado.
3. O sistema verifica se o saldo da conta do cliente é suficiente para a
realização do DOC.
4. O sistema envia o DOC à operadora.
5. Debita-se o valor da conta.
6. O QIB registra a ocorrência desta transação (um DOC).
7. Emite-se um comprovante da mesma para o usuário, contendo os
dados da conta de origem e destino, assim como a data e valor do
DOC.
Análise e Projeto OO com
UML e Padrões| 31
QIB – Realizar Doc
• Fluxo de eventos secundários
Fluxo Principal
1. O cliente informa os dados necessários para a realização do DOC:
- Banco, agência e conta destino;
- CPF do favorecido;
- Valor do DOC.
2. O sistema recupera a conta bancária do cliente logado.
3. O sistema verifica se o saldo da conta do cliente é suficiente para a
realização do DOC.
4. O sistema envia o DOC à operadora.
5. Debita-se o valor da conta.
secundário
6. O Fluxo
QIB registra
a ocorrência desta transação (um DOC).
7. Emite-se
um comprovante
o usuário, contendo
os dados
conta de origem
e
• No passo
3, se da
o mesma
saldopara
disponível
na conta
dodausuário
for menor
destino, assim como a data e valor do DOC.
que o
valor do DOC, o sistema informa que o saldo é insuficiente e retorna ao
passo 1 do fluxo principal de eventos.
• No passo 4, se a operadora de DOC estiver inativa ou se ocorrer algum
erro de comunicação que impeça a efetivação da transação, o sistema
emite uma mensagem para o cliente e aborta a transação.
• Em qualquer momento o usuário pode cancelar a operação.
Análise e Projeto OO com
UML e Padrões| 32
Passo 2. Identificar persistência
• Identificar que classes de análise deverão ser
persistentes
• Criar, para cada classe persistente, uma classe
de cadastro com estereótipo
<<entity collection>>
Analisar caso de uso | 33
QIB – Efetuar Login
Classes persistentes
<<entity>>
Usuario
<<entity collection>>
CadastroUsuarios
<<entity>>
Conta
<<entity collection>>
CadastroContas
Analisar caso de uso | 34
QIB – Efetuar Pagamento do Qualiti
Card
Classes persistentes
<<entity>>
PagamentoCartao
<<entity collection>>
CadastroPagamentosCartao
<<entity>>
Conta
<<entity collection>>
CadastroContas
<<entity>>
Cliente
<<entity collection>>
CadastroClientes
Analisar caso de uso | 35
Exercício – Qualiti Internet
Banking
• Dado
– Artefatos de requisitos do caso de uso realizar doc
– Classes de entidade
• Produzir
– Identificação das classes que deverão ser
persistentes
Análise e Projeto OO com
UML e Padrões| 36
Contexto
• Encontradas as classes de análise e
identificadas as classes persistentes, vamos
agora descrever o seu comportamento.
• Lembrando que estas atividades são
realizadas para cada caso de uso
Analisar caso de uso | 37
Passo 3. Distribuir comportamento
entre as classes
• Para cada fluxo de eventos
– alocar responsabilidades do caso de uso às classes
de análise
– modelar interações entre as classes através dos
diagramas de interação
Analisar caso de uso | 38
Distribuindo comportamento entre
as classes
Classes de
Análise
Diagrama de
Seqüência
Diagrama de
Colaboração
Caso de Uso
Classes de Análise
(com responsabilidades)
Analisar caso de uso | 39
Alocando responsabilidades
• Use estereótipos de análise como guia
– Classes de fronteira
• comportamento que envolve comunicação com um
ator
– Classes de entidade
• comportamento que envolve informação encapsulada
na abstração
– Classes de controle
• comportamento específico ao caso de uso (lógica de
controle do caso de uso)
Analisar caso de uso | 40
Alocando responsabilidades
• Identificar que classe tem a informação
necessária para realizar a responsabilidade
– isso pode envolver apenas uma classe, pode ser
preciso criar nova classe ou relacionamento entre
classes
Analisar caso de uso | 41
Modelando interações
• Diagramas de interação (colaboração e
seqüência) modelam interações do sistema
com seus atores
• A interação é iniciada por um ator e envolve
instâncias (objetos) das classes
• Diagramas de interação capturam a semântica
do fluxo de eventos do caso de uso
– Auxiliam a identificar classes, responsabilidades e
relacionamentos
Analisar caso de uso | 42
Forma Geral dos Diagramas de
Seqüência
Objeto fornecedor
Objeto cliente
:Cliente
:Fornecedor
Mensagem reflexiva
1: Realize responsabilidade
1.1: Realize outra responsabilidade
Mensagem
Numeração hierárquica para
as mensagens
Foco de controle
Analisar caso de uso | 43
QIB – Efetuar Login
: ClienteAtor
: TelaLogin
: ControladorLogin
: CadastroContas
efetuarLogin(login, senha)
efetuarLogin(login, senha)
existeConta(login, senha)
registraSessao(login)
Analisar caso de uso | 44
Forma Geral de Diagramas de
Colaboração
Objeto cliente
Mensagem reflexiva
Link
1.1: Realize outra
responsabilidade
:Cliente
:Fornecedor
1: Realize responsabilidade
Mensagem
Objeto fornecedor
Analisar caso de uso | 45
QIB - Efetuar Login
4: registraSessao(login)
1: efetuarLogin(login, senha)
:
TelaLogin
: ClienteAtor
2: efetuarLogin(login, senha)
3: existeConta(login, senha)
: ControladorLogin
: CadastroContas
Analisar caso de uso | 46
QIB – Efetuar Pagamento do Qualiti
Card
Exercício: diagramas de seqüência e
colaboração do caso de uso Efetuar
Pagamento do Qualiti Card
Analisar caso de uso | 47
Quantos diagramas de interação
fazer?
• Quantos forem necessários para modelar o
comportamento do caso de uso!
• Pelo menos o fluxo principal deveria ser
modelado
• Não é necessário modelar todos os fluxos
– Os fluxos secundários geralmente não acrescentam
muito à modelagem do principal
• O importante é exemplificar o uso de todas as
responsabilidades
Analisar caso de uso | 48
Que diagramas de interação fazer?
• Diagramas de colaboração x diagramas de seqüência
• Colaboração
– Melhores para visualizar os relacionamentos e responsabilidades
de um dado objeto
– Mais fáceis de desenhar - úteis em sessões de brainstorm
• Seqüência
– Melhores para visualizar a seqüência do fluxo no tempo
– Melhores para visualizar o fluxo completo
– Mais adequados para cenários complexos
Use o que gostar mais!!
Analisar caso de uso | 49
Contexto
Para cada caso de uso
encontramos as classes de análise
identificamos classes persistentes
descrevemos o seu comportamento através de diagramas
de interação
Agora, para cada classe
vamos descrever suas responsabilidades
Analisar caso de uso | 50
Passo 4. Descrever
Responsabilidades
• Responsabilidades identificadas nos fluxos de eventos são refletidas em
diagramas de interação
• Mensagens nestes diagramas resultam em responsabilidades nas classes
receptoras
diagrama de
interação
:Cliente
:Fornecedor
// Realizar responsabilidade
diagrama de
classes
Fornecedor
// Realizar responsabilidade
Analisar caso de uso | 51
QIB – Efetuar Login
Classes com responsabilidades
<<entity collection>>
CadastroContas
<<boundary>>
TelaLogin
existeConta()
efetuarLogin()
<<entity >>
Conta
<<control>>
ControladorLogin
efetuarLogin()
Analisar caso de uso | 52
QIB – Efetuar Pagamento do Qualiti
Card
Classes com responsabilidades
<<control>>
ControladorPagamentoQualitiCard
<<entity>>
Comprovante
<<entity collection>>
CadastroPagamentos
Cartao
efetuarPagamentoQualitiCard()
inserir()
<<boundary>>
TelaPagamentoQualitiCard
<<entity>>
Conta
efetuarPagamentoQualitiCard()
getSaldo()
debitar()
<<boundary>>
ComunicacaoOperadoraCartao
enviar()
<<entity collection>>
CadastroContas
consultarConta()
atualizar()
<<entity>>
PagamentoCartao
Analisar caso de uso | 53
Analisando o Modelo
• Classes com responsabilidades similares são candidatas a
serem combinadas
• Uma classe com responsabilidades disjuntas é candidata a ser
dividida
• Classes sem (ou com apenas uma responsabilidade) e classes
que interagem com muitas classes são candidatas a serem
reexaminadas
Isso poderá resultar em uma alteração
dos diagramas de interação
Analisar caso de uso | 54
Exercício – Qualiti Internet Banking
• Dado:
– Artefatos de requisitos do QIB, especialmente o
fluxo de eventos do caso de uso Realizar DOC
– As classes de análise identificadas no exercício
anterior
• Produzir:
– Diagrama de interação para o caso de uso
– VOPC com responsabilidades
Análise e Projeto OO com
UML e Padrões| 55
Passo 5. Descrever atributos e
associações
• Detalhando mais as classes
– definir atributos
– estabelecer associações necessárias entre as
classes
Analisar caso de uso | 56
Encontrando Atributos
• Possíveis fontes: conhecimento do negócio, requisitos,
glossário, modelo do negócio, etc.
• São propriedades/características das classes identificadas
– informação cujo valor é o aspecto crucial
– informação de propriedade exclusiva do objeto
– informação que pode ser lida ou escrita por operações, mas sem outro
comportamento a não ser fornecer um valor
• Se a informação tem comportamento complexo ou é
compartilhada, deve gerar uma classe
Analisar caso de uso | 57
Encontrando Relacionamentos
• Links entre objetos em diagramas de colaboração
indicam a necessidade de relacionamento entre
as respectivas classes
• Links reflexivos só geram relacionamentos
reflexivos quando dois objetos da classe precisam
se comunicar (mas não quando um objeto envia
mensagens para si próprio)
• A navegabilidade do relacionamento deve estar
de acordo com a direção da mensagem
• Inclua também o papel (role) e a multiplicidade
dos relacionamentos
Analisar caso de uso | 58
Encontrando Relacionamentos
1: Realizar responsabilidade
Diagrama de
Colaboração
:Cliente
:Fornecedor
Link
Cliente
Diagrama
de classe
Fornecedor
Cliente
Fornecedor
Realizar responsabilidade
Fonte: Rational
Associação
Um relacionamento para cada link
Analisar caso de uso | 59
QIB – Efetuar Login
Diagrama de classes com relacionamentos e atributos
<<boundary>>
TelaLogin
efetuarLogin()
0..n
1
<<control>>
ControladorLogin
efetuarLogin()
1
1
<<entity>>
Conta
<<entity collection>>
CadastroContas
existeConta()
0..n
login
senha
Analisar caso de uso | 60
QIB – Efetuar Pagamento do Qualiti Card
Diagrama de classes com relacionamentos e atributos
<<boundary>>
TelaPagamentoQualitiCard
efetuarPagamentoQualitiCard()
<<entity>>
Comprovante
pagamentoCartao
0..n
1
<<entity collection>>
CadastroContas
consultarConta()
atualizar()
<<control>>
ControladorPagamentoQualitiCard
1
1 efetuarPagamentoQualitiCard()
verificarSaldo()
1
1
1
<<boundary>>
ComunicacaoOperadoraCartao
enviar()
0..n
<<entity>>
Conta
numero
saldo
getSaldo()
debitar()
1
<<entity collection>>
CadastroPagamentos
Cartao
inserir()
<<entity>>
PagamentoCartao
0..n
numeroFatura
data
hora
valor
contaBancaria
Analisar caso de uso | 61
Exercício – Qualiti Internet Banking
• Dado:
– Classes de análise do caso de uso Realizar DOC
com estereótipos e responsabilidades
– Diagramas de interação do caso de uso
– VOPCs desenvolvidos no exercício anterior
• Produzir:
– VOPCs com relacionamentos e atributos. Incluir
multiplicidade e navegabilidade dos
relacionamentos
Análise e Projeto OO com
UML e Padrões| 62
Passo 6. Revisar Resultados
• Verificar se as classes de análise satisfazem
os requisitos funcionais
• Unificar as classes de análise
• Verificar se todo o modelo está consistente
entre si e com os requisitos
Analisar caso de uso | 63
Revisando: Passos realizados nesta
atividade
Para cada caso de uso:
1. Encontrar classes de análise
2. Identificar persistência
Para cada classe:
3. Distribuir comportamento entre as classes
4. Descrever responsabilidades
5. Descrever atributos e associações
6. Revisar os Resultados
Analisar caso de uso | 64