Upload
maria-quadros
View
213
Download
1
Embed Size (px)
Citation preview
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
Arquiteto de Informação
Análise e Projeto OO com UML e Padrões| 3
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Projetista deBanco de Dados
Arquiteto de Software
Revisor de projeto
Projetar Casos de Uso
Projetar Subsistemas/componentes
Projetar Base de Dados
Analista deSistemas
Projetar classes
Prototipar Interface gráfica
Analisar Serviços
ProjetarServiços
Arquiteto de Informação
Análise e Projeto OO com UML e Padrões| 4
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Projetista deBanco de Dados
Arquiteto de Software
Revisor de projeto
Projetar Casos de Uso
Projetar Subsistemascomponentes
Projetar Base de Dados
Analista deSistemas
Projetar classes
Prototipar Interface gráfica
Analisar Serviços
ProjetarServiços
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
Analisar caso de uso | 6
Analista de Sistemas
Analisar Caso de Uso
Glossário Modelo de Casos de Uso
Diagrama de Classes
Diagrama de Seqüência
Diagrama de Colaboração
Documento de Requisitos
Documento da
Arquitetura
Realização de Caso de Uso
Passos para Analisar Casos de Uso
Para cada caso de uso:1. Encontrar classes de análise2. Identificar persistência
Para cada classe:3. Distribuir comportamento entre as classes 4. Descrever responsabilidades5. 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
Analisar caso de uso | 9
Modelo de Casos de Uso
Códigos Fonte
Executável
Classes de Análise
Elementos de Projeto
QIB - Diagrama de Casos de Uso• Usaremos o QIB como exemplo
Analisar caso de uso | 10
Operadora do DOC
Desbloquear Talõesde Cheque
Efetuar Login
Alterar Senha
Consultar Saldo
Consultar Extrato
Consultar Qualiti CardRealizar Transferência
Consultar Cheques
Solicitar Talões de Cheque
Realizar DOC
ClienteAtor
Operadora Cartão de Crédito
Efetuar Pagamento do Qualiti Card
Mostrar Dados daConsulta
<<include>>
<<include>>
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
– GUI– Interface com outros sistemas– Interface com dispositivos
Analisar caso de uso | 11
<<boundary>>
Modelam a interação entre o sistema e seu ambiente
Notação em UML
QIB – Efetuar Login
• Regra geral para encontrar classes de fronteira: uma classe por cada par ator/caso de uso
Analisar caso de uso | 12
TelaLogin<<boundary>>
ClienteAtor Efetuar Login
QIB – Efetuar Pagamento do Qualiti Card
• Descobrindo classes de fronteira
Analisar caso de uso | 13
TelaPagamentoQualitiCard<<boundary>>
ComunicacaoOperadoraCartao<<boundary>>
ClienteAtorEfetuar Pagamento
do Qualiti Card Operadora de Cartão de Crédito
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:
– Conhecimento do negócio– Glossário– Modelo de negócios– Documento de requisitos– Especificação do Caso de uso
Analisar caso de uso | 15
<<entity>>
Armazenam e controlam informação no sistema
Notação em UML
QIB – Efetuar Login• Observe o fluxo de eventos do Efetuar Login
Analisar caso de uso | 16
Este caso de uso é responsável por autenticar um usuário do sistema.
Pré-condição: nenhumaPós-condição: um usuário válido é logado e sua sessão é registrada no sistema.
Fluxo de eventos principal1. 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.
Orientações para encontrarClasses 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
• 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
Usuario<<entity>>
Conta<<entity>>
QIB – Efetuar Pagamento do Qualiti Card• Descrição inicial
Analisar caso de uso | 19
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.
QIB – Efetuar Pagamento do Qualiti Card• Fluxo de eventos principal
Analisar caso de uso | 20
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 valor do pagamento.
QIB – Efetuar Pagamento do Qualiti Card
• Fluxo de eventos secundários
Analisar caso de uso | 21
Fluxo Principal1. 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 valor do pagamento.
Fluxo secundário
- 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.
QIB – Efetuar Pagamento do Qualiti Card
• Classes de entidade
Analisar caso de uso | 22
Conta<<entity>>
Cliente<<entity>>
CartaoCredito<<entity>>
Comprovante<<entity>>
Mensagem<<entity>>
CodigoBarras<<entity>>
PagamentoCartao<<entity>>
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
Analisar caso de uso | 23
<<control>>
Coordena o comportamento do caso de uso.Uma classe controle pode ter referência a vários objetos entidade.
Notação em UML
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
Analisar caso de uso | 25
ControladorLogin<<control>>
ClienteAtor Efetuar Login
QIB – Efetuar Pagamento do Qualiti Card
• Encontrando classes de controle
Analisar caso de uso | 26
ControladorPagamentoQualitiCard<<control>>
ClienteAtorEfetuar Pagamento
do Qualiti Card Operadora de Cartão de Crédito
QIB – Efetuar Login
Analisar caso de uso | 27
Classes de análise descobertas até o momento
Usuario<<entity>>
TelaLogin<<boundary>>
ControladorLogin<<control>>
Conta<<entity>>
QIB – Efetuar Pagamento do Qualiti Card
Analisar caso de uso | 28
Conta<<entity>>
Cliente<<entity>>
CartaoCredito<<entity>>
TelaPagamentoQualitiCard<<boundary>>
Comprovante<<entity>>
Mensagem<<entity>>
CodigoBarras<<entity>>
ComunicacaoOperadoraCartao<<boundary>>
PagamentoCartao<<entity>>
ControladorPagamentoQualitiCard<<control>>
Classes de análise descobertas até o momento
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
Análise e Projeto OO com UML e Padrões|
30
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.
QIB – Realizar Doc• Fluxo de eventos principal
Análise e Projeto OO com UML e Padrões|
31
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.
QIB – Realizar Doc• Fluxo de eventos secundários
Análise e Projeto OO com UML e Padrões|
32
Fluxo Principal1. 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.
Fluxo secundário• No passo 3, se o saldo disponível na conta do usuário for menor 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.
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
Analisar caso de uso | 34
Classes persistentes
Usuario<<entity>>
CadastroUsuarios<<entity collection>>
Conta<<entity>>
CadastroContas<<entity collection>>
QIB – Efetuar Pagamento do Qualiti Card
Analisar caso de uso | 35
Classes persistentes
CadastroPagamentosCartao<<entity collection>>
CadastroClientes<<entity collection>>
CadastroContas<<entity collection>>
PagamentoCartao<<entity>>
Cliente<<entity>>
Conta<<entity>>
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
Analisar caso de uso | 39
Classes de Análise Diagrama de
Colaboração
Caso de Uso
Diagrama de Seqüência
Classes de Análise(com responsabilidades)
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
Analisar caso de uso | 43
:Cliente :Fornecedor
Objeto cliente Objeto fornecedor
Foco de controle
Numeração hierárquica para as mensagens
Mensagem reflexiva
1.1: Realize outra responsabilidade
1: Realize responsabilidade
Mensagem
QIB – Efetuar Login
Analisar caso de uso | 44
: ClienteAtor : TelaLogin : ControladorLogin : CadastroContas
efetuarLogin(login, senha)
efetuarLogin(login, senha)
existeConta(login, senha)
registraSessao(login)
Forma Geral de Diagramas de Colaboração
Analisar caso de uso | 45
:Cliente
:Fornecedor
Objeto cliente
Link
Objeto fornecedorMensagem
1: Realize responsabilidade
Mensagem reflexiva
1.1: Realize outra responsabilidade
QIB - Efetuar Login
Analisar caso de uso | 46
: ClienteAtor
: TelaLogin
: ControladorLogin : CadastroContas
4: registraSessao(login)
1: efetuarLogin(login, senha)
2: efetuarLogin(login, senha)
3: existeConta(login, senha)
QIB – Efetuar Pagamento do Qualiti Card
Analisar caso de uso | 47
Exercício: diagramas de seqüência e colaboração do caso de uso Efetuar Pagamento do Qualiti Card
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
Analisar caso de uso | 49
Use o que gostar mais!!
Contexto
Para cada caso de usoencontramos as classes de análiseidentificamos classes persistentesdescrevemos o seu comportamento através de diagramas de interação
Agora, para cada classevamos 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
Analisar caso de uso | 51
:Cliente :Fornecedor
// Realizar responsabilidade
Fornecedor
// Realizar responsabilidade
diagrama de classes
diagrama de interação
QIB – Efetuar Login
Analisar caso de uso | 52
Classes com responsabilidades
TelaLogin
efetuarLogin()
<<boundary>>
ControladorLogin
efetuarLogin()
<<control>>
CadastroContas
existeConta()
<<entity collection>>
Conta<<entity >>
QIB – Efetuar Pagamento do Qualiti Card
Analisar caso de uso | 53
Classes com responsabilidades
Conta
getSaldo()debitar()
<<entity>>
Comprovante<<entity>>
TelaPagamentoQualitiCard
efetuarPagamentoQualitiCard()
<<boundary>>
PagamentoCartao<<entity>>
CadastroPagamentosCartao
inserir()
<<entity collection>>
CadastroContas
consultarConta()atualizar()
<<entity collection>>
ControladorPagamentoQualitiCard
efetuarPagamentoQualitiCard()
<<control>>
ComunicacaoOperadoraCartao
enviar()
<<boundary>>
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
Analisar caso de uso | 59
:Cliente :Fornecedor
Link
Fornecedor
Realizar responsabilidade
Diagramade classe
Diagrama deColaboração
Associação
Cliente Fornecedor
Um relacionamento para cada link
Cliente
1: Realizar responsabilidade
Fonte: Rational
QIB – Efetuar Login
Analisar caso de uso | 60
Diagrama de classes com relacionamentos e atributos
Contaloginsenha
<<entity>>
TelaLogin
efetuarLogin()
<<boundary>>
CadastroContas
existeConta()
<<entity col lection>>
0..n0..n
ControladorLogin
efetuarLogin()
<<control>>
1
0..n
1
0..n
1
1
1
1
QIB – Efetuar Pagamento do Qualiti Card
Analisar caso de uso | 61
Diagrama de classes com relacionamentos e atributos
Contanumerosaldo
getSaldo()debitar()
<<entity>>
ComprovantepagamentoCartao
<<entity>>
PagamentoCartaonumeroFaturadatahoravalorcontaBancaria
<<entity>>
TelaPagamentoQualitiCard
efetuarPagamentoQualitiCard()
<<boundary>>
CadastroContas
consultarConta()atualizar()
<<entity collection>>
0..n0..n
CadastroPagamentosCartao
inserir()
<<entity collection>>
0..n0..n
ComunicacaoOperadoraCartao
enviar()
<<boundary>>
ControladorPagamentoQualitiCard
efetuarPagamentoQualitiCard()verificarSaldo()
<<control>>1
0..n
1
0..n
1 11 1
1
1
1
1 11
11
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álise2. Identificar persistência
Para cada classe:3. Distribuir comportamento entre as classes
4. Descrever responsabilidades5. Descrever atributos e associações
6. Revisar os Resultados
Analisar caso de uso | 64