Análise Orientada a Objetos - Faculdade de Computaçãobacala/DAW/Aula03-1 - Modelagem de Casos de...

125
Análise Orientada a Objetos Modelagem Requisitos usando Casos de Uso Não diga pouco em muitas palavras, mas sim, muito em poucas. Pitágoras

Transcript of Análise Orientada a Objetos - Faculdade de Computaçãobacala/DAW/Aula03-1 - Modelagem de Casos de...

Análise Orientada a

Objetos

Modelagem Requisitos

usando Casos de Uso

Não diga pouco em muitas palavras, mas sim, muito em poucas.

Pitágoras

Especificação e Modelagem

de Requisitos

Elicitar Requisitos de Produto

Especificar casos de uso e validá-los

Especificar requisitos não funcionais

Analisar e Validar os requisitos

Requisitos

p/ Inspeção

Plano e

Casos de Teste

Casos de Uso e

Esp. Suplementar

Regras de

Negócio Glossário

Documento de Visão

Analista de Requisitos

Análise dos Requisitos

• Trabalha com requisitos incompletos

• Se preocupa em descobrir problemas

• Requisitos são enumerados, por exemplo, em uma reunião com stakeholders

– Quais as inconsistências?

– Quais os conflitos?

– Tenho que fazer uma nova reunião?

Especificação de Requisitos

de Produto

• Desenvolvida como uma consequência da fase de análise de requisitos

–Modelo de Casos de Uso

– Especificação Suplementar

• Serve como base para casos de teste

–Requisitos funcionais e não funcionais

Modelo de Casos de Uso

• Representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com o mesmo.

• O modelo de casos de uso modela os requisitos funcionais do sistema.

5

Modelo de Casos de Uso

• Direciona diversas das tarefas posteriores do ciclo de vida do sistema de software.

– Análise e Projeto

– Testes

– Gerência

– Etc...

• Além disso, força o sistema ser moldado pelos desenvolvedores de acordo com o usuário.

6

Componentes do modelo

• O modelo de casos de uso de um sistema é composto de:

– Casos de uso

– Atores

– Relacionamentos entre os elementos anteriores.

7

Cliente

Comprar

Modelo de Casos de Uso

• Ator: Elemento externo que interage com o sistema.

– “externo”: atores não fazem parte do sistema.

– “interage”: um ator troca informações com o sistema.

• Casos de uso: representam uma sequência de interações entre o sistema e o ator.

– no sentido de troca de informações entre eles.

• Normalmente um agente externo inicia a sequência de interações com o sistema, ou um evento acontece para que o sistema responda.

8

Atores

• Representam – o que interage com o sistema – tudo que necessita trocar informação com o sistema – estão fora do sistema

• não são descritos em detalhe

• Diferentes de usuários: – usuário usa o sistema – ator representa uma certa regra seguida pelo usuário – uma mesma pessoa pode aparecer como instância de

vários atores

Atores

• Categorias de atores: – pessoas (Empregado, Cliente,

Gerente, Almoxarife, Vendedor, etc); – organizações (Empresa Fornecedora,

Agência de Impostos, Administradora de Cartões, etc);

– outros sistemas (Sistema de Cobrança, Sistema de Estoque de Produtos, etc).

– equipamentos (Leitora de Código de Barras, Sensor, etc.)

10

Atores

• Um ator corresponde a um papel representado em relação ao sistema. – O mesmo indivíduo pode ser o Cliente que compra

mercadorias e o Vendedor que processa vendas. – Uma pessoa pode representar o papel de

Funcionário de uma instituição bancária que realiza a manutenção de um caixa eletrônico, mas também pode ser o Cliente do banco que realiza o saque de uma quantia.

• O nome dado a um ator deve lembrar o seu papel, ao invés de lembrar quem o representa.

11

Atores primários e

secundários

• Um ator pode participar de muitos casos de uso. • Um caso de uso pode envolver vários atores, o

que resulta na classificação dos atores em primários ou secundários. – Um ator primário é aquele que inicia uma seqüência

de interações de um caso de uso. – Atores secundários supervisionam, operam, mantêm

ou auxiliam na utilização do sistema.

• Exemplo: para que o Usuário (ator primário) requisite uma página a um Browser (sistema), um outro ator (secundário) está envolvido, o Servidor Web.

12

Modelo de Casos de Uso

• Uma instância de um Ator efetua diversas operações no sistema

• Quando um usuário usa o sistema, efetua um sequência de transações relacionadas em um diálogo com o sistema

• Esta sequência é chamada de Caso de Uso • Cada Caso de Uso é uma forma específica de usar

o sistema • Cada execução de um caso de uso pode ser visto

como uma instância do Caso de Uso

Casos de uso

• Um caso de uso é a especificação de uma sequência de interações entre um sistema e os agentes externos.

• Define parte da funcionalidade de um sistema, sem revelar a estrutura e o comportamento internos deste sistema.

• Um modelo de casos de uso típico é formado de vários casos de uso.

14

Casos de uso

15

Um caso de uso representa quem faz o que (interage) com o sistema,

sem considerar o comportamento interno do sistema.

Relacionamentos

• A UML define diversos tipos de relacionamentos no modelo de casos de uso: – Comunicação – Inclusão – Extensão – Generalização

16

Relacionamento de

comunicação

• Casos de uso e atores não existem sozinhos. Podem haver relacionamentos entre eles.

• Representa a informação de quais atores estão associados a quais casos de uso.

• O fato de um ator estar associado a um caso de uso significa que esse ator interage (troca informações) com o sistema.

• Um ator pode se relacionar com mais de um caso de uso.

• É o mais comum dos relacionamentos.

17

Modelo de Casos de Uso

• Casos de Uso capturam os requisitos funcionais

• O conjunto de todos os Casos de Uso especificam a funcionalidade completa do sistema

• Agrupar funcionalidades e chamá-las de Casos de Uso facilita o gerenciamento destes requisitos durante ciclo de desenvolvimento

Modelo de Casos de Uso

• Caso de Uso

–determina um ou mais casos de teste

• Do conjunto de casos de uso é possível derivar o Plano de Testes

–Garantir adequação do software aos requisitos funcionais

De posse dos Casos de

Uso

• Verifique

– se não há requisitos faltando

– que os desenvolvedores entendem os requisitos

• Vantagem:

– apelo visual dos requisitos mais relevantes do cliente

ELABORANDO O MODELO DE

CASOS DE USO

Identificando

• Nenhum sistema existe isoladamente – interage com atores humanos e/ou autômatos

– atores esperam que o sistema se comporte de acordo com o previsto

• Um caso de uso – especifica o comportamento de um sistema (ou de

parte deste)

– é a descrição de um conjunto de sequências de ações

– inclui variantes realizadas pelo sistema para produzir um resultado observável por um ator

Identificando Atores

• Quais grupos precisam de ajuda do sistema para realizar suas tarefas?

• Quais grupos são necessários para a execução das funções do sistema?

• Quais grupos interagem com algum hardware externo ou outros sistemas?

• Quais grupos realizam funções secundárias de administração e de manutenção?

• Existem atividades temporais periódicas?

Identificando Atores

• Atores Primários – necessidades que são supridas pelo sistema

• Caixa, cliente

• Atores de suporte – provem serviços para o sistema

• Agente de cartão de crédito

• Primeiro: encontrar os atores primários – enumere as necessidades para cada ator

Identificando Atores

Exemplo

Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos.

Casos de Uso:

função – transação/serviço

• Sequência de ações, executada pelo sistema, que gera um resultado

– De valor observável

– E para um ou mais atores

Função

Procedimento

computacional

Identificando Casos de

Uso • Em geral, é difícil decidir entre um ou vários Casos de

Uso • Por exemplo, seria Caso de Uso:

– Inserir cartão em um Caixa Automático? – Digitar a senha? – Receber o cartão de volta?

• Casos de Uso devem ser organizados para evitar – Redundância – Conflitos – Ambiguidades

Identificando Casos de

Uso

• Deve representar valor observável para ator

• Pode-se determinar

– Devido a interações Ator x Sistema

• sequência de ações com o sistema que resultam valores para atores

– Devido a necessidades de um Ator

• satisfaz um objetivo particular de um ator que o sistema deve prover

Identificando Casos de

Uso

• Procedimentos Iniciais

– Escolha a fronteira do sistema

– Identifique os atores primários

• aqueles cujas necessidades serão supridas pelo sistema

– Defina Casos de Uso que satisfaça as necessidades dos atores primários

• um caso de uso para cada necessidade

Identificando Casos de

Uso

• Traçar fronteira conceitual

– Identificar o que está fora e o que está dentro do sistema

• Exemplo: ponto de vendas

– Fora

• Cliente, Caixa, Agente de Cartão de Crédito

– Dentro

• Venda, Emissão Recibo, Estoque, ....

Identificando Casos de

Uso

• O que está dentro do sistema:

– é responsável por executar seu comportamento

• O que está fora:

– o contexto do sistema

– o ambiente onde o sistema existe

– determinam as necessidades que o sistema deve atender

Identificação de casos de

uso

• A partir da lista (inicial) de atores, deve-se passar à identificação dos casos de uso.

• Nessa identificação, pode-se distinguir entre dois tipos de casos de uso – Primário: representa os objetivos dos atores. – Secundário: aquele que não traz benefício

direto para os atores, mas que é necessário para que sistema funcione adequadamente.

32

Casos de uso primários

• Perguntas úteis: – Quais são as necessidades e objetivos de cada ator em relação ao

sistema?

– Que informações o sistema deve produzir?

– O sistema deve realizar alguma ação que ocorre regularmente no tempo?

– Para cada requisito funcional, existe um (ou mais) caso(s) de uso para atendê-lo?

• Outras técnicas de identificação: – Caso de uso “oposto”.

– Caso de uso que precede a outro caso de uso.

– Caso de uso relacionado a uma condição interna.

– Caso de uso que sucede a outro caso de uso.

– Caso de uso temporal. 33

Casos de uso secundários

• Estes se encaixam nas seguintes categorias:

– Manutenção de cadastros.

– Manutenção de usuários.

– Manutenção de informações provenientes de outros sistemas.

• Importante: Um sistema de software não existe para cadastrar informações, nem tampouco para gerenciar os seus usuários.

– O objetivo principal é produzir algo de valor para o ambiente no qual ele está implantado.

34

Identificando Casos de Uso

Exemplo

Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos.

Achando Casos de Uso

• Que funções o ator requer do sistema? O que o ator necessita fazer?

• O ator tem que ler, criar, destruir, modificar ou armazenar algum tipo de informação do sistema?

• O ator tem que ser notificado sobre eventos do sistema, ou o ator necessita notificar o sistema sobre alguma coisa? – o que estes eventos representam em termos de

funcionalidade

Achando Casos de Uso

• Pode o trabalho diário do ator ser simplificado ou mais eficiente através da incorporação de novas funções?

• Outras questões

– Que entradas/saídas o sistema necessita?

• De onde vem e para onde vão?

– Quais os maiores problemas com a implementação atual (quando existir automática ou a manual)

Definindo os Casos de Uso

• Nomeie os casos de uso como uma necessidade – Registrar venda ( um necessidade do caixa)

• Descreva cada caso de uso – primeiro uma descrição simplificada

– complete esta descrição • analise o conjunto de casos de uso e faça uma organização

• Não considere a Interface Homem-máquina – isto é implementação

• Foco : o que fazer

Identificando os

relacionamentos

Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos.

Identificando os

relacionamentos

Descrições narrativas

• Cada caso de uso é definido através da descrição narrativa das interações que ocorrem entre o(s) elemento(s) externo(s) e o sistema.

• Há várias formas de se descrever casos de uso. – Grau de abstração – Formato – Grau de detalhamento

41

Exemplo de descrição

contínua

• O Cliente chega ao caixa eletrônico e insere seu cartão. O Sistema requisita a senha do Cliente. Após o Cliente fornecer sua senha e esta ser validada, o Sistema exibe as opções de operações possíveis. O Cliente opta por realizar um saque. Então o Sistema requisita o total a ser sacado. O Sistema fornece a quantia desejada e imprime o recibo para o Cliente.

42

Exemplo de descrição

numerada

1. Cliente insere seu cartão no caixa eletrônico.

2. Sistema apresenta solicitação de senha.

3. Cliente digita senha.

4. Sistema exibe menu de operações disponíveis.

5. Cliente indica que deseja realizar um saque.

6. Sistema requisita quantia a ser sacada.

7. Cliente retira a quantia e recibo.

43

Exemplo de narrativa

particionada

Cliente Sistema

Insere seu cartão no caixa eletrônico. Digita senha. Solicita realização de saque. Retira a quantia e o recibo.

Apresenta solicitação de senha. Exibe operações disponíveis. Requisita quantia a ser sacada.

44

Detalhamento

• O grau de detalhamento a ser utilizado na descrição de um caso de uso também pode variar.

• Um caso de uso sucinto descreve as interações sem muitos detalhes.

• Um caso de uso expandido descreve as interações em detalhes.

45

Grau de abstração

• O grau de abstração de um caso de uso diz respeito à existência ou não de menção à tecnologia a ser utilizada na descrição deste caso de uso.

• Um caso de uso essencial não faz menção à tecnologia a ser utilizada.

• Um caso de uso real apresenta detalhes da tecnologia a ser utilizada na implementação deste caso de uso .

46

Grau de abstração

1) Cliente fornece sua identificação. 2) Sistema identifica o usuário. 3) Sistema fornece operações disponíveis. 4) Cliente solicita o saque de uma determinada quantia. 5) Sistema fornece a quantia desejada da conta do Cliente. 6) Cliente recebe dinheiro e recibo.

47

Exemplo de descrição essencial (e numerada):

Cenários

• Um caso de uso tem diversas maneiras de ser realizado.

• Um cenário é a descrição de uma das maneiras pelas quais um caso de um pode ser realizado.

• Um cenário também é chamado de instância de um caso de uso.

• Normalmente há diversos cenários para um mesmo um caso de uso.

• Úteis durante a modelagem de interações. 48

Cenários

Um Cliente telefona para a empresa.

Um Vendedor atende ao telefone.

Cliente declara seu desejo de fazer um pedido de compra.

Vendedor pergunta a forma de pagamento.

Cliente indica que vai pagar com cartão de crédito.

Vendedor requisita o número do cartão, a data de expiração e o

endereço de entrega.

Vendedor pede as informações do primeiro item.

Cliente fornece o primeiro item.

Vendedor pede as informações do segundo item.

Cliente fornece o segundo item

Vendedor pede as informações do terceiro item

Cliente e informa o terceiro item.

Vendedor informa que o terceiro item está fora de estoque.

Cliente pede para que O Vendedor feche o pedido somente com os dois

primeiros itens.

Vendedor fornece o valor total, a data de entrega e uma

identificação do pedido.

Cliente agradece e desliga o telefone.

Vendedor contata a Transportadora para enviar o pedido de O Cliente.

49

Caso de Uso: um exemplo

• Caso de Uso: Registrar Venda • Descrição Breve

– O Caixa necessita efetuar a venda de um conjunto de itens selecionados pelo cliente. Deve atualizar estoque, registrar a venda e emitir o recibo

• Descrição Informal – Um cliente chega no caixa com itens a comprar. O Caixa

registra cada item usando o Sistema. O sistema apresenta o total parcial e a descrição de cada item. O cliente entra com a informação de pagamento, que o sistema valida e registra. O sistema atualiza o estoque. O cliente recebe um recibo e parte com os itens adquiridos

Casos de Uso – Detalhado

• Ator primário: o que inicia a ocorrência do caso de uso – Caixa

• Interessados :interessados em validar o Caso de Uso – Caixa

– Cliente

– Gerente

• Pré-condições: o que deve ser verdade antes de iniciar o caso de uso – O caixa está identificado e autenticado

Casos de Uso – Detalhado

• Pós-condições: o que deve ser verdade após o término com sucesso do caso de uso

– A venda está registrada

– O estoque foi atualizado

– Recibo emitido

– As comissões foram calculadas e armazenadas

• descrição ainda informal

Casos de Uso - Descrição

Detalhada

• Fluxo Normal: descreve a história principal de sucesso do caso de uso – Número sequência. Agente + verbo + complemento

• Ex: Cadastrar Cliente 1. O cliente fornece seus dados

2. O sistema verifica que o cliente não está cadastrado

3. O sistema adiciona novo cliente

4. O sistema informa que o cadastro foi efetuado com sucesso

Casos de Uso - Descrição

Detalhada

• Fluxos Alternativos ou Extensões: indicam outros cenários (tanto de sucesso como de insucesso)

– Caso <número>: <Descrição do caso alternativo>

– Número sequência . Agente + verbo + complemento ;

– Finalizar caso de uso ou retornar ao passo...

Casos de Uso – Descrição

• Cadastrar Cliente - Fluxos Alternativos

• Caso 1: Cliente já está cadastrado

2.1 - O sistema verifica que o cliente está cadastrado – número da seq. onde se inicia a variante

2.2 - O sistema informa que já está cadastrado

2.3 - Finalizar caso de uso

Casos de Uso - Descrição

Detalhada

• Requisitos Especiais: requisitos não funcionais, atributos de qualidade ou restrições

– Usar um leitor ótico para o código de barras

Casos de Uso – Descrição

• Registrar Venda

• Fluxo Normal

1. O cliente chega com os itens selecionados no caixa

2. O Caixa inicia uma venda

3. Para cada item (trazido pelo Cliente) 1. Adicionar Item de venda

4. O caixa finaliza a venda

5. O sistema totaliza a compra e informa o total

6. O cliente efetua o pagamento

7. O Caixa registra o pagamento

8. O sistema da baixa no estoque dos itens vendidos

9. O sistema emite o recibo

10. ......................

ORGANIZANDO O MODELO

DE CASOS DE USO

Organizando

• Organize os atores semelhantes em uma hierarquia de generalização/especialização

• Especifique as associações de cada ator para os Casos de Uso

Diagrama de Casos de

Uso

Pessoa Fisica Pessoa Juridica

ClienteRealizar transacao com Cartao de

CreditoAgente de Cartao

de Credito

Processar Conta do Cliente

Instituicao

Financeira

Diagramas de Casos de

Uso

• São secundários

• O importante é o texto descrevendo os Casos de Uso

• Apoiam a organização – Pacotes de Casos de Uso

• Agregam casos de uso funcionalmente coesos

– Visualizam relacionamentos entre • casos de uso

• atores

Revisando Casos de Uso

• Todos os atores envolvidos com um Caso de Uso – Estão se comunicando?

– Aparecem na sua descrição?

– Algum não aparece?

• Tem ator ou Caso de Uso sem nenhuma associação? – Há algo errado...

• Tem algum requisito funcional conhecido não tratado pelos Casos de Uso – Está incompleto...

Revisando Casos de Uso

• Estruturar modelo de Casos de Uso

• Estabelecer relacionamentos entre Casos de Uso

– Trechos similares em mais de um caso de Uso

• “Inclusão”

– A descrição do Caso de Uso está muito complexa

• “Extensão”

• “Generalização”

Inclusão

• Caso de uso base incorpora explicitamente comportamento de outro Caso de Uso em ponto específico

• Representado como uma dependência (seta tracejada) para o Caso de Uso incluído

• Se o Caso de Uso incluído muda o Base, necessita ser revisto

– <<include>>

Inclusão

• Similaridades descritas em mais de um caso de Uso eliminar redundâncias

Caso de uso Base

Caso de Uso Inclusão

<<include>>

Executando uma instância do Caso de uso Base

Inclusão

• Caso de Uso: Venda

• Fluxo Normal

1. ........

2. .........

3. Incluir “Pagar”

4. Finalizar Venda

Inclusão

Venda

Pagar

Cliente

<<include>>

Extensão

• Um Caso de Uso incorpora implicitamente o comportamento de outro caso de uso

• Apenas em circunstâncias específicas (condição) o caso de uso estendido é incorporado ao caso de uso base

• Utilizado para modelar comportamento excepcional do sistema

– Exceções

Extensão

• Representado como uma dependência

– seta tracejada para o Caso de Uso Base

• Se o Caso de Uso base muda o Caso de Uso estendido, necessita ser revisto

– <<extends>>

Extensão

• A descrição do Caso de Uso está muito complexa

Caso de uso Base

Caso de Uso Extensão

<<extends>>

Executando uma instância do Caso de uso Base

Ponto de

Extensão

Extensão

• Caso de Uso: Efetuar Troca

• Fluxo Normal

1. O Cliente chega com produto para troca

2. O Caixa prepara cupom de troca (devolver dinheiro)

3. Reportar ao Estoque

4. Finalizar Operação

– Ponto de extensão : Devolver dinheiro

Extensão

Devolver DinheiroEfetuar Troca

<<extends>>

Generalização de Atores

• Quando dois ou mais atores podem se comunicar com o mesmo conjunto de casos de uso

• Um filho (herdeiro) pode se comunicar com todos os casos de uso que seu pai se comunica.

• Dica: coloque os herdeiros embaixo

Generalização de Casos

de Uso

• Similar a generalização entre Classes

• O caso de uso filho herda

– o significado do caso de uso pai

– o comportamento

• O comportamento do Caso de Uso filho normalmente é redefinido

• O Caso de Uso filho pode ser usado no lugar do pai

Generalização de Casos

de Uso

• A descrição do Caso de Uso está muito complexa

Executando uma instância do Caso de uso Filho

Caso de uso Pai

Caso de Uso Filho

Generalização de Casos

de Uso

Pagar a Dinheiro

Pagar com Cartão

Cliente Pagar

base

derivado

Generalização de Casos

de Uso • Ator: Cliente • Fluxo Normal

1. Esse caso de Uso começa quando o cliente deseja efetuar pagamento 2. O Cliente registra o documento de cobrança 3. O Cliente informa a opção desejada

1. Se pagto a dinheiro – executar subseção Pagar a dinheiro 2. Se pagto com cartão de crédito- executar subseção Pagar com Cartão

4. O sistema registra o pagamento 5. O sistema emite o recibo

Subseção – Pagar a Dinheiro 1. O Cliente coloca o dinheiro em um envelope e lacra 2. O Cliente informa o numero do envelope ao sistema 3. O cliente deposita o envelope 4. .......

Identificando

Generalização de Atores

Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos.

Identificando

Generalização de Atores

Identificando Generalização

de Casos de Uso

• Novos requisitos: – Vendas podem ser à vista ou a prazo. Em ambos, o estoque é

atualizado e uma nota fiscal, entregue ao consumidor.

– No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro.

– No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo de 20%. Vendas a prazo podem ser pagas no cartão ou no boleto. Para pagamento com boleto, são gerados boletos bancários que são entregues ao cliente e armazenados no sistema para lançamento posterior no caixa. Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras a vista.

Identificando Generalização

de Casos de Uso

Identificando Generalização

de Casos de Uso

• Novos requisitos: – Vendas podem ser à vista ou a prazo. Em ambos, o estoque é

atualizado e uma nota fiscal, entregue ao consumidor.

– No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro.

– No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo de 20%. Vendas a prazo podem ser pagas no cartão ou no boleto. Para pagamento com boleto, são gerados boletos bancários que são entregues ao cliente e armazenados no sistema para lançamento posterior no caixa. Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras a vista.

Identificando Generalização

de Casos de Uso

Identificando

dependência: extensão

• Novos requisitos:

– No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro.

– No caso de uma venda a prazo...

– ...Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras à vista.

Identificando

dependência: extensão

Identificando

dependência: inclusão

• Novos requisitos:

–Para efetuar vendas ou administrar estoque, atendentes e gerentes terão que validar suas respectivas senhas de acesso ao sistema.

Identificando

dependência: inclusão

Elemento Opcional:

Fronteira

• Serve para definir a área de atuação do sistema

Fronteira

do sistema

Descrição dos Casos de

Uso

Descrição dos Casos de

Uso

Descrição dos Casos de

Uso

Descrição dos Casos de

Uso

Descrição dos Casos de

Uso

Descrição dos Casos de

Uso

CONSTRUÇÃO DO MODELO

DE CASOS DE USO

Construção do diagrama de

casos de uso

• Em sistemas complexos, representar todos os casos de uso do sistema em um único DCU talvez o torne um tanto ilegível.

• Alternativa: criar vários diagramas, de acordo com as necessidades de visualização. – Diagrama exibindo um caso de uso e seus relacionamentos;

– Diagrama exibindo todos os casos de uso para um ator;

– Diagrama exibindo todos os casos de uso a serem implementados em um ciclo de desenvolvimento.

96

Documentação dos atores

• Uma breve descrição para cada ator deve ser adicionada ao modelo de casos de uso.

• O nome de um ator deve lembrar o papel desempenhado pelo mesmo no sistema.

97

Documentação dos casos

de uso

• UML não define uma estruturação específica a ser utilizada na descrição do formato expandido de um caso de uso.

• A seguir, é apresentada uma sugestão de descrição.

– A equipe de desenvolvimento deve utilizar o formato de descrição que lhe for realmente útil.

98

Documentação dos casos

de uso

• Nome

• Descrição

• Identificador

• Importância

• Sumário

• Ator Primário

• Atores Secundários

• Pré-condições

• Fluxo Principal

• Fluxos Alternativos

• Fluxos de Exceção

• Pós-condições

• Regras do Negócio

• Histórico

• Notas de

Implementação

99

Documentação dos casos

de uso

100

A descrição do modelo deve ser mantida no nível mais simples possível...

DOCUMENTAÇÃO ASSOCIADA

AO MODELO DE CASOS DE

USO

Documentação dos casos

de uso

• O modelo de casos de uso força o desenvolvedor a pensar em como os agentes externos interagem com o o sistema.

• No entanto, este modelo corresponde somente aos requisitos funcionais.

• Outros tipos de requisitos (desempenho, interface, segurança, regras do negócio, etc.) também fazem parte do documento de requisitos.

102

Regras do negócio

• São políticas, condições ou restrições que devem ser consideradas na execução dos processos existentes em uma organização.

• Descrevem a maneira pela qual a organização funciona.

• Estas regras são identificadas e documentadas no chamado modelo de regras do negócio.

• A descrição do modelo de regras do negócio pode ser feita utilizando-se texto informal, ou alguma forma de estruturação.

103

Regras do negócio

• Alguns exemplos de regras do negócio: – O valor total de um pedido é igual à soma dos

totais dos itens do pedido acrescido de 10% de taxa de entrega.

– Um professor só pode estar lecionando disciplinas para as quais esteja habilitado.

– Um cliente do banco não pode retirar mais de R$ 1.000 por dia de sua conta.

– Os pedidos para um cliente não especial devem ser pagos antecipadamente.

104

Regras do negócio

• Regras do negócio normalmente têm influência sobre um ou mais casos de uso.

• Os identificadores das regras do negócio devem ser adicionados à descrição do caso de uso. – Utilizando a seção “regras do negócio” da

descrição do caso de uso.

105

Regras do negócio

• Possível formato para documentação de uma regra de negócio.

Nome Quantidade de inscrições possíveis (RN01)

Descrição Um aluno não pode ser inscrever em mais de

seis disciplinas por semestre letivo.

Fonte Coordenador da escola de informática

Histórico Data de identificação: 12/07/2002

106

Requisitos de desempenho

• Conexão de casos de uso a requisitos de desempenho.

Identificador

do caso de uso

Freqüência

da utilização

Tempo

máximo esperado

...

CSU01 5/mês Interativo …

CSU02 15/dia 1 segundo …

CSU03 60/dia Interativo …

CSU04 180/dia 3 segundos …

CSU05 600/mês 10 segundos …

CSU07 500/dia durante

10 dias seguidos.

10 segundos ...

107

MODELO DE CASOS DE

USO NO PROCESSO DE

DESENVOLVIMENTO

Modelo de casos de uso no

processo de

desenvolvimento • A identificação da maioria dos atores e casos

de uso é feita na fase de concepção.

• A descrição dos casos de uso considerados mais críticos começa já nesta fase, que termina com 10% a 20% do modelo de casos de uso completo.

• Ao final da fase de elaboração 80% do modelo de casos de uso está construído. – descrição feita até em um nível de abstração

essencial. 109

Modelo de casos de uso no

processo de

desenvolvimento • Na fase de construção, casos de uso formam

uma base natural através da qual podem-se realizar as iterações do desenvolvimento.

• Um grupo de casos é alocado a cada iteração.

• Em cada iteração, o grupo de casos de uso é detalhado e desenvolvido.

• O processo continua até que todos os casos de uso tenham sido desenvolvidos e o sistema esteja completamente construído.

110

Modelo de casos de uso no

processo de

desenvolvimento • Este tipo de desenvolvimento é chamado de

desenvolvimento dirigido a casos de uso.

• Deve-se considerar os casos de uso mais importantes primeiramente.

• Cantor propõe uma classificação em função do risco de desenvolvimento e das prioridades estabelecidas pelo usuário. 1) Risco alto e prioridade alta

2) Risco alto e prioridade baixa

3) Risco baixo e prioridade alta

4) Risco baixo e prioridade baixa

111

Modelo de casos de uso no

processo de

desenvolvimento • Considerando-se essa categorização, um caso

de uso não tão importante não será contemplado nas iterações iniciais. – Atacar o risco maior mais cedo...

• A descrição expandida de um caso de uso pode ser deixada para a iteração na qual este deve ser implementado. – evita perda de tempo inicial no detalhamento.

– estratégia mais adaptável aos requisitos voláteis.

112

Casos de uso nas atividades

de análise e projeto

• Na fase de análise, descrições de casos de uso devem capturar os requisitos funcionais do sistema e ignorar aspectos de projeto, como a interface gráfica com o usuário (essenciais).

• No projeto, adicionando mais detalhes (reais)

113

Procedimento

1) Identifique os atores e casos de uso na fase de concepção.

2) Na fase de elaboração: – desenhe o(s) diagrama(s) de casos de uso; – escreva os casos de uso em um formato de alto

nível e essencial. – ordene a lista de casos de uso de acordo com

prioridade e risco.

3) Associe cada grupo de casos de uso a uma iteração da fase de construção. – grupos mais prioritários e arriscados nas iterações

iniciais. 114

Procedimento

4) Na i-ésima iteração da fase de construção: – Detalhe os casos de uso do grupo associado a

esta iteração (nível de abstração real).

5) Implemente estes casos de uso.

115

Casos de uso e outras

atividades do

desenvolvimento • Planejamento e gerenciamento do projeto

– Uma ferramenta fundamental para o gerente de um projeto no planejamento e controle de um processo de desenvolvimento incremental e iterativo

• Testes do sistema – Os casos de uso e seus cenários oferecem casos de

teste.

• Documentação do usuário – manuais e guias do usuário podem ser construídos

com base nos casos de uso.

116

PONTOS PRINCIPAIS.....

Dicas/Sugestões

• Todos os Casos de Uso deverão representar algum comportamento distinto e identificável

• Nomeie um comportamento que seja único, identificável e razoavelmente atômico

• Faça a fatoração de comportamento comum, obtendo-se este comportamento de outros casos de uso (inclusão)

• Faça a fatoração de variantes, aplicando esse comportamento a outros casos de uso que o estendem (extensão)

• Descreva o fluxo de eventos de maneira suficientemente clara para que alguém de fora seja capaz de compreendê-lo com facilidade – Especifique um conjunto mínimo de cenários explicitando a

semântica normal e variante do Caso de Uso

Dicas e Sugestões

• Aos clientes, mostre somente

–Casos de Uso importantes para a compreensão do comportamento do sistema (ou da parte sendo modelada)

– Somente os atores relacionados com esses Casos de Uso

Exercício: o Blog

• Um blog tem um título e uma data de criação e além disso é um conjunto de conteúdos.

• Estes conteúdos (mensagens) podem ser notas ou comentários sobre as notas. Tanto notas quanto comentários têm características comuns como o texto e a data de sua criação.

• Todo usuário possui:

– E-mail (deve ser único, ou seja, não há mais de um usuário com o mesmo e-mail)

O Blog deve...

• Permitir a criação de blogs

• Permitir a utilização de blogs

– Qualquer usuário pode ler conteúdos

– Somente o dono do blog pode criar notas

– Qualquer usuário pode criar comentários. Para criar um comentário o usuários precisa ler as notas.

– Somente o dono do blog pode remover conteúdos. Para remover um conteúdo ele precisará ler o conteúdo. Caso ele remova um comentário, o autor do comentário deve ser notificado por e-mail.

Exercício

• Elaborar o Modelo de Casos de Uso para um site de Vendas Online (Diagrama e a especificação do UC) – Usuário se cadastra no sistema

– Usuário pesquisa produtos no site

– Usuário seleciona produtos incluindo no “carrinho de compras”.

– Usuário visualiza produtos no carrinho, podendo excluir algum

– Usuário finaliza a venda (precisa estar logado)

• Usuário deve informar endereço entrega

• Usuário pode pagar com boleto bancário ou cartão

– Usuário faz login no sistema

123

O Blog deve... • Permitir a criação de blogs

• Permitir a utilização de blogs

– Qualquer usuário pode ler conteúdos

– Só o dono do blog pode criar notas

– Qualquer usuário pode criar comentários.

• Para criar um comentário o usuários precisa ler as notas.

– Somente o dono do blog pode remover conteúdos.

• Para remover um conteúdo ele precisará ler o conteúdo.

• Caso ele remova um comentário, o autor do comentário deve ser notificado por e-mail.

1. Usuário cria Blog (conteúdo)

2. Usuário lê conteúdo (nota/ comentário)

3. Usuário criar comentário (precisa ler )

4. Dono cria notas

5. Dono remove conteúdo (nota/comentário). – Precisa ler.

– Remoção de comentário comunica usuário