Analisar Caso de Usoplm/Ess/analiseCasosDeUsoRT.pdf · 2005-06-17 · Esta atividade é realizada para cada caso de uso! Analisar caso de uso | 6 ... Casos de Uso Diagrama de Classes

Analisar Caso de Uso

Analisar caso de uso | 2

Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.

Qualiti Software Processes

Objetivos deste módulo

Apresentar os passos necessários pararealizar a atividade analisar casos de uso ediscutir seus artefatosApresentar os diagramas de seqüência,colaboração e classes de UML


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Analisar Casos de Uso

AnalisarCasos de Uso

RevisarProjeto

ProjetarArquitetura

Projetista deBanco de Dados

Arquiteto deSoftware

Revisor deprojeto

ProjetarCasos de Uso

ProjetarSubsistemas

ProjetarBase de Dados

Analista deSistemas

ProjetarCápsulas


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



AnalisarCasos de Uso

RevisarProjeto

ProjetarArquitetura

Projetista deBanco de Dados

Arquiteto deSoftware

Revisor deprojeto

ProjetarCasos de Uso

ProjetarSubsistemas

ProjetarBase de Dados

Analista deSistemas

ProjetarCápsulas


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Objetivos desta atividade

Encontrar as classes iniciais do sistema(classes de análise) e distribuircomportamento dos casos de uso entre elasPara cada classe, descrever asresponsabilidades, atributos e associações

Esta atividade é realizada para cada caso deuso!


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Visão geral dos artefatos

Analista deSistemas

Analisar Casode Uso

Glossário Modelo deCasos de Uso

Diagrama deClasses

Diagrama deSeqüência

Diagrama deColaboração

Documento deRequisitos

Documento daArquitetura

Realização deCaso de Uso


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


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 classes4. Descrever responsabilidades5. Descrever atributos e associações

6. Revisar os Resultados


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Passo 1. Encontrar classes de análise

O comportamento do caso de uso édistribuído em classes de análise dosseguintes tipos (estereótipos) fronteira controle entidade

Estes estereótipos são uma conveniência deanálise que desaparecem no projeto


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


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

Modelo deCasos de Uso

Códigos Fonte

Executável

Classes deAnálise

Elementos deProjeto


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


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 deCrédito

Efetuar Pagamento doQualiti Card

Mostrar Dados daConsulta

<<include>>

<<include>>

Usaremos o QIB como exemplo


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Classes de Fronteira (boundary classes)

Isolam o sistema de mudanças no ambienteexternoAtores devem se comunicar apenas com classesde fronteiraExemplos 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

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


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

TelaLogin<<boundary>>

ClienteAtor Efetuar Login


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


QIB – Efetuar Pagamento doQualiti Card

Descobrindo classes de fronteira

TelaPagamentoQualitiCard<<boundary>>

ComunicacaoOperadoraCartao<<boundary>>

ClienteAtorEfetuar Pagamento

do Qualiti Card Operadora de Cartãode Crédito


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Descrevendo Classes deFronteira

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


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


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

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


QIB – Efetuar LoginObserve o fluxo de eventos do Efetuar Login

Este caso de uso é responsável por autenticar um usuário dosistema.

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 seo 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 sistemaexibe uma mensagem e volta ao passo 1.

Este caso de uso é responsável por autenticar um usuário dosistema.

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 seo 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 sistemaexibe uma mensagem e volta ao passo 1.


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Orientações para encontrarClasses de Entidade

Usando a descrição do caso de uso, use aabordagem 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

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Classes de entidade

A classe Conta é uma classe que armazena o login esenha de um cliente.

Algumas classes levantadas podem ser eliminadas enovas serão adicionadas

QIB – Efetuar Login

Usuario<<entity>>

Conta<<entity>>


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


QIB – Efetuar Pagamento do QualitiCard

Observe o fluxo de eventos do caso de usoEfetuar Pagamento do Qualiti Card


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



Descrição inicial

Este caso de uso é responsável por realizar o pagamento do QualitiCard com a operadora de cartão de crédito. Cada cliente possuiapenas um cartão como titular, estando vinculado a apenas umaoperadora.

Pré-condição: O cliente deve estar conectado ao sistema (ter efetuadoo 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.

Este caso de uso é responsável por realizar o pagamento do QualitiCard com a operadora de cartão de crédito. Cada cliente possuiapenas um cartão como titular, estando vinculado a apenas umaoperadora.

Pré-condição: O cliente deve estar conectado ao sistema (ter efetuadoo 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

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



Fluxo de eventos principal1. O cliente informa os dados necessários para efetuar o pagamento docartã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 pararealizar 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 umcomprovante da mesma para o usuário. A transação registrada contémos dados da conta do cliente, o código de barras da fatura, data, hora evalor do pagamento.

1. O cliente informa os dados necessários para efetuar o pagamento docartã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 pararealizar 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 umcomprovante da mesma para o usuário. A transação registrada contémos dados da conta do cliente, o código de barras da fatura, data, hora evalor do pagamento.


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



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 realizaro 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 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 realizaro 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 ovalor do pagamento, o sistema informa que o saldo é insuficiente e retornapara o passo 1.- No passo 5, se a operadora de cartão de crédito estiver inativa, osistema exibe uma mensagem e cancela a operação.- Em qualquer momento o usuário pode cancelar a operação.

Fluxo secundário

- No passo 3, se o saldo disponível na conta do cliente for menor que ovalor do pagamento, o sistema informa que o saldo é insuficiente e retornapara o passo 1.- No passo 5, se a operadora de cartão de crédito estiver inativa, osistema exibe uma mensagem e cancela a operação.- Em qualquer momento o usuário pode cancelar a operação.


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Classes de entidade


Conta<<entity>>

Cliente<<entity>>

CartaoCredito<<entity>>

Comprovante<<entity>>

Mensagem<<enti ty>>

CodigoBarras<<entity>>

PagamentoCartao<<enti ty>>


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Classes de Controle (control classes)Coordenam o comportamento (lógica decontrole) do caso de usoInterface entre fronteira e entidadeDependente do caso de uso, independente doambientePermitem separação entre o uso da entidade(específico do sistema) do comportamentoinerente à 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

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Orientações para encontrarClasses de Controle

Usualmente, uma classe de controle por casode usoEventualmente mais de uma(comportamento complexo) ou nenhuma(manipulação simples de informaçõesarmazenadas)


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



Encontrando classes de controle

ControladorLogin<<control>>

ClienteAtor Efetuar Login


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



Encontrando classes de controle

ControladorPagamentoQualit iCard<<control>>

ClienteAtorEfetuar Pagamento

do Qualiti Card Operadora de Cartãode Crédito


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



Classes de análise descobertas até o momento

Usuario<<entity>>

TelaLogin<<boundary>>

ControladorLogin<<control>>

Conta<<entity>>


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



Conta<<entity>>

Cliente<<entity>>

CartaoCredito<<entity>>

TelaPagamentoQualitiCard<<boundary>>


Mensagem<<enti ty>>

CodigoBarras<<entity>>

ComunicacaoOperadoraCartao<<boundary>>


ControladorPagamentoQualit iCard<<control>>

Classes de análise descobertas até o momento


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Passo 2. Identificar persistência

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


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


QIB – Efetuar LoginClasses persistentes

Usuario<<entity>>

CadastroUsuarios<<entity collection>>

Conta<<entity>>

CadastroContas<<entity collection>>


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



Classes persistentes

CadastroPagamentosCartao<<entity collection>>

CadastroClientes<<entity collection>>

CadastroContas<<entity collection>>


Cliente<<entity>>

Conta<<entity>>


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Contexto

Encontradas as classes de análise eidentificadas as classes persistentes, vamosagora descrever o seu comportamento.

Lembrando que estas atividades sãorealizadas para cada caso de uso


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Passo 3. Distribuircomportamento 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


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Distribuindo comportamentoentre as classes

Classes deAnálise


Caso de Uso

Diagrama deSeqüência

Classes de Análise(com responsabilidades)


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


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

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Alocando responsabilidades

Identificar que classe tem a informaçãonecessária para realizar a responsabilidade isso pode envolver apenas uma classe, pode ser

preciso criar nova classe ou relacionamento entreclasses


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Modelando interações

Diagramas de interação (colaboração eseqüência) modelam interações do sistemacom seus atoresA interação é iniciada por um ator e envolveinstâncias (objetos) das classesDiagramas de interação capturam asemântica do fluxo de eventos do caso deuso Auxiliam a identificar classes, responsabilidades

e relacionamentos


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Forma Geral dos Diagramas deSeqüência

:Cliente :Fornecedor

Objeto cliente Objeto fornecedor

Foco de controle

Numeração hierárquica paraas mensagens

Mensagem reflexiva

1.1: Realize outra responsabilidade

1: Realize responsabilidade

Mensagem


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



: ClienteAtor : TelaLogin : ControladorLogin : CadastroContas

efetuarLogin(login, senha)

efetuarLogin(login, senha)

existeConta(login, senha)

registraSessao(login)


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Forma Geral de Diagramas deColaboração

:Cliente

:Fornecedor

Objeto cliente

Link

Objeto fornecedorMensagem

1: Realize responsabilidade

Mensagem reflexiva

1.1: Realize outraresponsabilidade


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


QIB - Efetuar Login

: ClienteAtor

:TelaLogin

: ControladorLogin : CadastroContas

4: registraSessao(login)

1: efetuarLogin(login, senha)

2: efetuarLogin(login, senha)

3: existeConta(login, senha)


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



Exercício: diagramas de seqüência ecolaboração do caso de uso EfetuarPagamento do Qualiti Card


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Quantos diagramas deinteração fazer?

Quantos for necessário para modelar ocomportamento do caso de uso!

Pelo menos o fluxo principal deveria sermodeladoNã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 todasas responsabilidades


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Que diagramas de interaçãofazer?

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


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Contexto

Para cada caso de usoencontramos as classes de análiseidentificamos classes persistentesdescrevemos o seu comportamento através dediagramas de interação

Agora, para cada classevamos descrever suas responsabilidades


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Passo 4. DescreverResponsabilidades

Responsabilidades identificadas nos fluxos de eventos sãorefletidas em diagramas de interaçãoMensagens nestes diagramas resultam em responsabilidadesnas classes receptoras


// Realizar responsabilidade

Fornecedor

// Realizar responsabilidade

diagrama declasses

diagrama deinteração


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


QIB – Efetuar LoginClasses com responsabilidades

TelaLogin

efetuarLogin()

<<boundary>>

ControladorLogin

efetuarLogin()

<<control>>

CadastroContas

existeConta()

<<entity collection>>

Conta<<entity >>


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.



Classes com responsabilidades

Conta

getSaldo()debitar()

<<entity>>


TelaPagamentoQualitiCard

efetuarPagamentoQualitiCard()

<<boundary>>


CadastroPagamentosCartao

inserir()

<<ent ity collection>>

CadastroContas

consultarConta()atualizar()


ControladorPagamentoQualit iCard


<<control>>

ComunicacaoOperadoraCartao

enviar()

<<boundary>>


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Analisando o Modelo

Classes com responsabilidades similares sãocandidatas a serem combinadasUma classe com responsabilidades disjuntas écandidata a ser divididaClasses sem (ou com apenas uma responsabilidade)e classes que interagem com muitas classes sãocandidatas a serem reexaminadas

Isso poderá resultar em uma alteraçãodos diagramas de interação


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Passo 5. Descrever atributos eassociações

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

classes


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Encontrando Atributos

Possíveis fontes: conhecimento do negócio,requisitos, glossário, modelo do negócio, etc.São propriedades/características das classesidentificadas 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

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Encontrando Relacionamentos

Links entre objetos em diagramas decolaboração indicam a necessidade derelacionamento entre as respectivas classesLinks reflexivos só geram relacionamentosreflexivos quando dois objetos da classeprecisam se comunicar (mas não quando umobjeto envia mensagens para si próprio)A navegabilidade do relacionamento deveestar de acordo com a direção da mensagemInclua também o papel (role) e amultiplicidade dos relacionamentos


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Encontrando Relacionamentos


Link

Fornecedor

Realizar responsabilidade

Diagramade classe


Associação

Cliente Fornecedor

Um relacionamento para cada link

Cliente

1: Realizar responsabilidade

Fonte: Rational


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


QIB – Efetuar LoginDiagrama de classes com relacionamentos e atributos

Contaloginsenha

<<entity>>

TelaLogin

efetuarLogin()

<<boundary>>

CadastroContas

existeCon ta()

<<en tity col lectio n>>

0..n0..n

ControladorLogin

efetuarLogin()

<<control>>

1

0..n

1

0..n

1

1

1

1


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


QIB – Efetuar Pagamento do Qualiti CardDiagrama 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

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Passo 6. Revisar Resultados

Verificar se as classes de análise satisfazemos requisitos funcionaisUnificar as classes de análiseVerificar se todo o modelo está consistenteentre si e com os requisitos


Copy

righ

t ©

2002

Qua

liti.

Tod

os o

s di

reit

os r

eser

vado

s.


Revisando: Passos realizados nestaatividade

Para cada caso de uso:1. Encontrar classes de análise2. Identificar persistência

Para cada classe:3. Distribuir comportamento entre as classes4. Descrever responsabilidades5. Descrever atributos e associações

6. Revisar os Resultados


Documents

Analisar Caso de Usoplm/Ess/analiseCasosDeUsoRT.pdf · 2005-06-17 · Esta atividade é realizada para cada caso de uso! Analisar caso de uso | 6 ... Casos de Uso Diagrama de Classes