analisar caso de uso. copyright © 2006 qualiti. todos os direitos reservados. qualiti software...

Analisar Caso de Uso

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Qualiti Software ProcessesAnálise e Projeto OO com UML e Padrões| 2

Objetivos deste móduloApresentar os passos necessários para realizar a atividade analisar casos de uso e discutir seus artefatosApresentar os diagramas de seqüência, colaboração e classes de UML

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Analisar Casos de Uso

Analisar Casos de Uso

Revisar Projeto

Projetar Arquitetura

Projetista deBanco de Dados

Arquiteto de Software

Revisor de projeto

Projetar Casos de Uso

Projetar Subsistemas

Projetar Base de Dados

Analista deSistemas

Projetar Classe

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Objetivos desta atividadeEncontrar as classes iniciais do sistema (classes de análise) e distribuir comportamento dos casos de uso entre elasPara cada classe, descrever as responsabilidades, atributos e relacionamentos

Esta atividade é realizada para cada caso de uso!

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Visão geral dos artefatos

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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Classes de análise: um primeiro passo em direção ao executável

Modelo de Casos de Uso

Códigos Fonte

Executável

Classes de Análise

Elementos de Projeto

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB - Diagrama de Casos de Uso

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>>

Usaremos o QIB como exemplo

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Classes de Fronteira (boundary classes)

Isolam o sistema de mudanças no ambiente externoAtores devem se comunicar apenas com classes de fronteira Exemplos de classes fronteira GUI Interface com outros sistemas Interface com dispositivos

<<boundary>>

Modelam a interação entre o sistema e seu ambiente

Notação em UML

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Efetuar LoginRegra geral para encontrar classes de fronteira: uma classe por cada par ator/caso de uso

TelaLogin<<boundary>>

ClienteAtor Efetuar Login

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Efetuar Pagamento do Qualiti Card

Descobrindo classes de fronteira

TelaPagamentoQualitiCard<<boundary>>

ComunicacaoOperadoraCartao<<boundary>>

ClienteAtorEfetuar Pagamento

do Qualiti Card Operadora de Cartão de Crédito

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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!

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Classes de Entidade (entity classes)

Abstrações e conceitos chaves dos casos de usoFontes: Conhecimento do negócio Glossário Modelo de negócios Documento de requisitos Especificação do Caso de uso

<<entity>>

Armazenam e controlam informação no sistema

Notação em UML

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Efetuar LoginObserve o fluxo de eventos do Efetuar Login

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 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.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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

QIB – Efetuar Login

Usuario<<entity>>

Conta<<entity>>

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



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.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



Fluxo de eventos 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.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



Fluxo de eventos secundáriosFluxo 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.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Classes de entidade


Conta<<entity>>

Cliente<<entity>>

CartaoCredito<<entity>>

Comprovante<<entity>>

Mensagem<<entity>>

CodigoBarras<<entity>>

PagamentoCartao<<entity>>

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Classes de Controle (control classes)

Coordenam o comportamento (lógica de controle) do caso de usoInterface entre fronteira e entidade Dependente do caso de uso, independente do ambientePermitem separação entre o uso da entidade (específico do sistema) do comportamento inerente à entidade

<<control>>

Coordena o comportamento do caso de uso.Uma classe controle pode ter referência a vários objetos entidade.

Notação em UML

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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)

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Efetuar LoginEncontrando classes de controle

ControladorLogin<<control>>

ClienteAtor Efetuar Login

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



Encontrando classes de controle

ControladorPagamentoQualitiCard<<control>>

ClienteAtorEfetuar Pagamento

do Qualiti Card Operadora de Cartão de Crédito

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Efetuar LoginClasses de análise descobertas até o momento

Usuario<<entity>>

TelaLogin<<boundary>>

ControladorLogin<<control>>

Conta<<entity>>

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



Conta<<entity>>

Cliente<<entity>>

CartaoCredito<<entity>>

TelaPagamentoQualitiCard<<boundary>>


Mensagem<<entity>>

CodigoBarras<<entity>>

ComunicacaoOperadoraCartao<<boundary>>


ControladorPagamentoQualitiCard<<control>>

Classes de análise descobertas até o momento

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Realizar DocDescriçã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.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Realizar DocFluxo de eventos 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.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Realizar DocFluxo de eventos secundários

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.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Passo 2. Identificar persistência

Identificar que classes de análise deverão ser persistentesCriar, para cada classe persistente, uma classe de cadastro com estereótipo <<entity collection>>

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Efetuar LoginClasses persistentes

Usuario<<entity>>

CadastroUsuarios<<entity collection>>

Conta<<entity>>

CadastroContas<<entity collection>>

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



Classes persistentes

CadastroPagamentosCartao<<entity collection>>

CadastroClientes<<entity collection>>

CadastroContas<<entity collection>>


Cliente<<entity>>

Conta<<entity>>

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



Dado Artefatos de requisitos do caso de uso

realizar doc Classes de entidade

Produzir Identificação das classes que deverão ser

persistentes

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Passo 3. Distribuir comportamento entre as

classesPara 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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Distribuindo comportamento entre as

classes

Classes de Análise Diagrama de

Colaboração

Caso de Uso

Diagrama de Seqüência

Classes de Análise(com responsabilidades)

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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)

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Modelando interações Diagramas de interação (colaboração e seqüência) modelam interações do sistema com seus atoresA interação é iniciada por um ator e envolve instâncias (objetos) das classesDiagramas de interação capturam a semântica do fluxo de eventos do caso de uso Auxiliam a identificar classes,

responsabilidades e relacionamentos

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Forma Geral dos Diagramas de Seqüência

: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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Efetuar Login

: ClienteAtor : TelaLogin : ControladorLogin : CadastroContas

efetuarLogin(login, senha)

efetuarLogin(login, senha)

existeConta(login, senha)

registrarSessao(login)

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Forma Geral de Diagramas de

Colaboração

:Cliente

:Fornecedor

Objeto cliente

Link

Objeto fornecedorMensagem

1: Realize responsabilidade

Mensagem reflexiva

1.1: Realize outra responsabilidade

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB - Efetuar Login

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



Observe os diagramas de seqüência e colaboração do caso de uso Efetuar Pagamento do Qualiti Card

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Quantos diagramas de interação fazer?

Quantos forem necessários para modelar o comportamento do caso de uso!

Pelo menos o fluxo principal deve ser modeladoNã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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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 Base para eleboração do diagrama de classes

Seqüência Melhores para visualizar a seqüência do fluxo no tempo Melhores para visualizar o fluxo completo Mais adequados para cenários complexos

Sugestão: elaborar diagrama de seqüência, gerar o de colaboração e, a partir deste, o de classes

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


ContextoPara cada caso de uso

encontramos as classes de análiseidentificamos classes persistentesdescrevemos o seu comportamento através de diagramas de interação

Agora, para cada classevamos descrever suas responsabilidades

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Passo 4. Descrever Responsabilidades

Responsabilidades identificadas nos fluxos de eventos são refletidas em diagramas de interaçãoMensagens nestes diagramas resultam em responsabilidades nas classes receptoras


// Realizar responsabilidade

Fornecedor

// Realizar responsabilidade

diagrama de classes

diagrama de interação

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Efetuar LoginClasses com responsabilidades

ControladorLogin

efetuarLogin()

<<control>>

CadastroContas

existeConta()

<<entity collection>>

Conta<<entity >>

TelaLogin

efetuarLogin()registrarSessao()

<<boundary>>

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



Classes com responsabilidades

Conta

getSaldo()debitar()

<<entity>>


TelaPagamentoQualitiCard

efetuarPagamentoQualitiCard()

<<boundary>>


CadastroPagamentosCartao

inserir()


CadastroContas

consultarConta()atualizar()


ControladorPagamentoQualitiCard


<<control>>

ComunicacaoOperadoraCartao

enviar()

<<boundary>>

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Analisando o ModeloClasses com responsabilidades similares são candidatas a serem combinadasUma 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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Passo 5. Descrever atributos e

relacionamentosDetalhando mais as classes definir atributos estabelecer associações necessárias entre

as classes

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Encontrando AtributosPossí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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Encontrando Relacionamentos

Links entre objetos em diagramas de colaboração indicam a necessidade de relacionamento entre as respectivas classesLinks 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 mensagemInclua também o papel (role) e a multiplicidade dos relacionamentos

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Encontrando Relacionamentos


Link

Fornecedor

Realizar responsabilidade

Diagramade classe

Diagrama deColaboração

Associação

Cliente Fornecedor

Um relacionamento para cada link

Cliente

1: Realizar responsabilidade

Fonte: Rational

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


QIB – Efetuar LoginDiagrama de classes com relacionamentos e atributos

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



Diagrama de classes com relacionamentos e atributos

Contanumerosaldo

getSaldo()debitar()

<<entity>>

ComprovantepagamentoCartao

<<entity>>

PagamentoCartaonumeroFaturadatahoravalorcontaBancaria

<<entity>>

TelaPagamentoQualitiCard


<<boundary>>

CadastroContas

consultarConta()atualizar()


0..n0..n

CadastroPagamentosCartao

inserir()


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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Passo 6. Revisar Resultados

Verificar se as classes de análise satisfazem os requisitos funcionaisUnificar as classes de análiseVerificar se todo o modelo está consistente entre si e com os requisitos

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.



Dado: Artefatos de requisitos do caso de uso Comprar

Ações, especialmente o fluxo de eventos (ver slide a seguir)

Produzir: Identificação das classes de análise, com seus

estereótipos e breve descrição Identificação das classes que deverão ser

persistentes Diagramas de interação do caso de uso VOPCs com relacionamentos e atributos

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Fluxo de eventos – Consultar Extrato

Fluxo de eventos1. O cliente seleciona entre um extrato simples ou

multiconta1. No extrato simples, o cliente escolhe uma conta (corrente,

poupança ou investimento) dentre as pertencentes a ele.2. No extrato multiconta, o cliente escolha uma ou mais contas.2. O sistema pesquisa por todas as transações relacionadas às contas do extrato.3. O sistema mostra os dados da consulta de uma maneira unificada e uniforme (para todos os tipos de extrato) na tela.

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Qualiti Software Processes

Fluxo de eventos – Configurar Conta

Fluxo de eventos O usuário seleciona uma de contas associadas ao cliente. O usuário configura uma das seguintes ações automáticas à conta:

• Enviar um e-mail caso haja uma determinada variação N (positiva ou negativa) na conta.

• Transferência automática de uma valor X de uma conta reserva (do mesmo cliente) para a conta em questão, caso o saldo alcance um determinado limite Y.

• Mudança de estratégia (conservadora ou agressiva) de investimento dependendo da variação do saldo da conta. Esta ação só poderá ser associada às contas do tipo investimento.

Após o usuário preencher os parâmetros da configuração e confirmar a configuração, o sistema associa a ação à conta.

Fluxo secundário Caso em uma transferência automática, a conta reserva tenha

saldo insuficiente, um email é enviado ao cliente. Problemas no envio de e-mails são guardados no log do sistema,

para posterior re-envio.

Análise e Projeto OO com UML e Padrões| 66

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Qualiti Software Processes

Fluxo de eventos – Agendar Transação

Fluxo de eventos1. Durante a realização de qualquer uma das seguintes operações o

usuário poderá agendar sua para uma determinada data D.• Pagamento de um cartão• Realizar DOC• Transferência entre contas

2. Após a confirmar o agendamento, o sistema armazena o agendamento da transação.

3. Na data D, o sistema recupera todos o agendamentos para esta data e executa eles.

Fluxo secundário Durante a execução de uma operação agendada, caso a conta

tenha saldo insuficiente, a operação é cancelada e um email é enviado ao cliente.

Problemas no envio de e-mails são guardados no log do sistema, para posterior re-envio.

Análise e Projeto OO com UML e Padrões| 67

analisar caso de uso. copyright © 2006 qualiti. todos os direitos reservados. qualiti software...

Documents