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

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!


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

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


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


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

QIB - Diagrama de Casos de Uso• Usaremos o QIB como exemplo


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


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


TelaLogin<<boundary>>

ClienteAtor Efetuar Login

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

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!


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


<<entity>>

Armazenam e controlam informação no sistema

Notação em UML

QIB – Efetuar Login• Observe o fluxo de eventos do Efetuar Login


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

Pré-condição: 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



• 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


Usuario<<entity>>

Conta<<entity>>

QIB – Efetuar Pagamento do Qualiti Card• Descrição inicial


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

Pré-condição: O cliente deve estar conectado ao sistema (ter efetuado o login).

Pós-condição: O valor do pagamento é debitado da conta do cliente, o pagamento é enviado à operadora do cartão de crédito e a transação é registrada no sistema.

QIB – Efetuar Pagamento do Qualiti Card• Fluxo de eventos principal


1. O cliente informa os dados necessários para efetuar o pagamento do cartão: - O código de barras da fatura que deseja efetuar o pagamento. - O valor que deseja pagar.

2. O sistema recupera a conta bancária do cliente logado.

3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar o pagamento.

4. O sistema debita da conta do cliente.

5. O sistema envia o pagamento à operadora de cartão de crédito.

6. O sistema registra a transação de pagamento e emite um comprovante da mesma para o usuário. A transação registrada contém os dados da conta do cliente, o código de barras da fatura, data, hora e valor do pagamento.


• Fluxo de eventos secundários


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.


• Classes de entidade


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


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



• Encontrando classes de controle


ControladorLogin<<control>>

ClienteAtor Efetuar Login


• Encontrando classes de controle


ControladorPagamentoQualitiCard<<control>>

ClienteAtorEfetuar Pagamento

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



Classes de análise descobertas até o momento

Usuario<<entity>>

TelaLogin<<boundary>>

ControladorLogin<<control>>

Conta<<entity>>



Conta<<entity>>

Cliente<<entity>>

CartaoCredito<<entity>>

TelaPagamentoQualitiCard<<boundary>>


Mensagem<<entity>>

CodigoBarras<<entity>>

ComunicacaoOperadoraCartao<<boundary>>


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


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


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


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




Classes persistentes

Usuario<<entity>>

CadastroUsuarios<<entity collection>>

Conta<<entity>>

CadastroContas<<entity collection>>



Classes persistentes

CadastroPagamentosCartao<<entity collection>>

CadastroClientes<<entity collection>>

CadastroContas<<entity collection>>


Cliente<<entity>>

Conta<<entity>>


• Dado – Artefatos de requisitos do caso de uso realizar doc– Classes de entidade

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

persistentes


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


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


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)

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)


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


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


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



: ClienteAtor : TelaLogin : ControladorLogin : CadastroContas

efetuarLogin(login, senha)

efetuarLogin(login, senha)

existeConta(login, senha)

registraSessao(login)

Forma Geral de Diagramas de Colaboração


:Cliente

:Fornecedor

Objeto cliente

Link

Objeto fornecedorMensagem

1: Realize responsabilidade

Mensagem reflexiva

1.1: Realize outra responsabilidade

QIB - Efetuar Login


: ClienteAtor

: TelaLogin

: ControladorLogin : CadastroContas

4: registraSessao(login)

1: efetuarLogin(login, senha)

2: efetuarLogin(login, senha)

3: existeConta(login, senha)



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


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

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


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



// Realizar responsabilidade

Fornecedor

// Realizar responsabilidade

diagrama de classes

diagrama de interação



Classes com responsabilidades

TelaLogin

efetuarLogin()

<<boundary>>

ControladorLogin

efetuarLogin()

<<control>>

CadastroContas

existeConta()

<<entity collection>>

Conta<<entity >>



Classes com responsabilidades

Conta

getSaldo()debitar()

<<entity>>


TelaPagamentoQualitiCard

efetuarPagamentoQualitiCard()

<<boundary>>


CadastroPagamentosCartao

inserir()


CadastroContas

consultarConta()atualizar()


ControladorPagamentoQualitiCard


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



• 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


55

Passo 5. Descrever atributos e associações

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

classes


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


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


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



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



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


• 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


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


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. Objetivos deste módulo Apresentar os passos necessários para realizar a atividade analisar casos de uso e discutir seus artefatos