Analisar Caso de Uso

Analisar Caso de Uso

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.

Qualiti Software Processes

Analisar caso de uso | 2

Objetivos deste módulo

Apresentar 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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.


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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.


Arquiteto de Informação


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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



Objetivos desta atividade

Encontrar 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 associações

Esta atividade é realizada para cada caso de uso!

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



Visão geral dos artefatos

Analista de Sistemas


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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

TelaLogin<<boundary>>

ClienteAtorEfetuar Login

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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!

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

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.

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




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.

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.

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




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.

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.





Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




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





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





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.

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.

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



Classes de entidade


Conta<<entity>>

Cliente<<entity>>

CartaoCredito<<entity>>

Comprovante<<entity>>

Mensagem<<entity>>

CodigoBarras<<entity>>

PagamentoCartao<<entity>>

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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)

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




Encontrando classes de controle

ControladorLogin<<control>>

ClienteAtorEfetuar Login

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




Encontrando classes de controle

ControladorPagamentoQualitiCard<<control>>

ClienteAtorEfetuar Pagamento

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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




Classes de análise descobertas até o momento

Usuario<<entity>>

TelaLogin<<boundary>>

ControladorLogin<<control>>

Conta<<entity>>

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




Conta<<entity>>

Cliente<<entity>>

CartaoCredito<<entity>>

TelaPagamentoQualitiCard<<boundary>>


Mensagem<<entity>>

CodigoBarras<<entity>>

ComunicacaoOperadoraCartao<<boundary>>


ControladorPagamentoQualitiCard<<control>>

Classes de análise descobertas até o momento

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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.

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.

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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.

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.

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

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.

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




Classes persistentes

Usuario<<entity>>

CadastroUsuarios<<entity collection>>

Conta<<entity>>

CadastroContas<<entity collection>>

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




Classes persistentes

CadastroPagamentosCartao<<entity collection>>

CadastroClientes<<entity collection>>

CadastroContas<<entity collection>>


Cliente<<entity>>

Conta<<entity>>

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




Dado Artefatos de requisitos do caso de uso

realizar doc

Classes de entidade

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

persistentes

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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)

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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)

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




: ClienteAtor : TelaLogin : ControladorLogin : CadastroContas

efetuarLogin(login, senha)

efetuarLogin(login, senha)

existeConta(login, senha)

registraSessao(login)

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



Forma Geral de Diagramas de

Colaboração

:Cliente

:Fornecedor

Objeto cliente

Link

Objeto fornecedorMensagem

1: Realize responsabilidade

Mensagem reflexiva

1.1: Realize outra responsabilidade

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



QIB - Efetuar Login

: ClienteAtor

: TelaLogin

: ControladorLogin : CadastroContas

4: registraSessao(login)

1: efetuarLogin(login, senha)

2: efetuarLogin(login, senha)

3: existeConta(login, senha)

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




Exercício: diagramas de seqüência e colaboração do caso de uso Efetuar Pagamento do Qualiti Card

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



Contexto

Para cada caso de usoencontramos as classes de análise

identificamos classes persistentesdescrevemos o seu comportamento através de diagramas de interação

Agora, para cada classevamos descrever suas responsabilidades

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




Classes com responsabilidades

TelaLogin

efetuarLogin()

<<boundary>>

ControladorLogin

efetuarLogin()

<<control>>

CadastroContas

existeConta()

<<entity collection>>

Conta

<<entity >>

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




Classes com responsabilidades

Conta

getSaldo()debitar()

<<entity>>


TelaPagamentoQualitiCard

efetuarPagamentoQualitiCard()

<<boundary>>


CadastroPagamentosCartao

inserir()


CadastroContas

consultarConta()atualizar()


ControladorPagamentoQualitiCard


<<control>>

ComunicacaoOperadoraCartao

enviar()

<<boundary>>

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



Analisando o Modelo

Classes 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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



Passo 5. Descrever atributos e associações

Detalhando mais as classes definir atributos

estabelecer associações necessárias entre as classes

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



QIB – Efetuar LoginDiagrama de classes com relacionamentos e atributos

Conta

loginsenha

<<entity>>

TelaLogin

efetuarLogin()

<<boundary>>

CadastroContas

existeConta()


0..n0..n

ControladorLogin

efetuarLogin()

<<control>>

1

0..n

1

0..n

1

1

1

1

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




Diagrama de classes com relacionamentos e atributos

Conta

numerosaldo

getSaldo()debitar()

<<entity>>

Comprovante

pagamentoCartao

<<entity>>

PagamentoCartao

numeroFaturadatahoravalorcontaBancaria

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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.




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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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

Cop

yri

gh

t ©

20

02

Qu

alit

i. T

od

os

os

dir

eit

os

rese

rvad

os.



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


Documents

Analisar Caso de Uso