1 casos de uso. 2 princípios de análise e projeto orientados a objetos com uml eduardo bezerra...

1

Casos de Uso

2

Princípios de Análise e Princípios de Análise e Projeto Orientados a Projeto Orientados a Objetos com UMLObjetos com UML

Eduardo Bezerra

Editora CAMPUS

Slides extraídos do livro:

Com adaptações feitas pelo professor

3

Antes de fazer, decida o que você quer fazer.

4

Introdução

O modelo de casos de uso é uma 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

Introdução

O diagrama da UML utilizado na modelagem de casos de uso é o diagrama de casos de uso. Técnica de modelagem idealizada por Ivar

Jacobson, na década de 1970. Mais tarde, incorporada ao método

Objectory. Posteriormente, a notação de casos de uso

foi adicionada à UML.

6

Introdução

O modelo de casos de uso força os desenvolvedores a moldar o sistema de acordo com o usuário.

7

Componentes do modelo

O modelo de casos de uso de um sistema é composto de: Casos de uso Atores Relacionamentos entre os elementos anteriores

Relacionamentos podem ser de: Generalização Associação

8

Casos de uso

Um caso de uso é a especificação de uma seqüência de interações

entre um sistema e os agentes externos. é uma seqüência de ações que um sistema executa

para produzir um resultado de valor observável por um ator

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.

9

Casos de uso

Um caso de uso representa quem faz o que (interage) com o sistema, sem considerar o comportamento interno do sistema.

10

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.

11

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.

12

Exemplo de descrição numerada

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

2. 2. Sistema apresenta solicitação de senha.3. 3. Cliente digita senha.4. 4. Sistema exibe menu de operações

disponíveis.5. 5. Cliente indica que deseja realizar um

saque.6. 6. Sistema requisita quantia a ser sacada.7. 7. Cliente retira a quantia e recibo.

13

Exemplo de descrição numerada

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

14

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.

15

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.

16

Cenário Principal

Descreve um seqüência de ações que serão executadas considerando que nada de errado ocorrerá durante a a execução da seqüência.

É o cenário perfeito

17

Ator: Correntista1. O sistema faz a leitura do cartão magnético.2. O sistema solicita a digitação da senha.O correntista informa sua senha.3. O sistema valida a senha, verificando se é a mesma senha que

está associada ao correntista.4. O correntista seleciona a opção de saldo5. O sistema questiona o tipo de saldo: conta corrente, poupança, investimentos6. O sistema processa e mostra o saldo solicitado pelo clienteetc

Cenário Principal

Trecho do caso de uso

“Emitir Saldo em um terminal de caixa eletrônico”

18

Cenários

O mundo não é perfeito, muito menos as transações de um sistema. Então, como podemos representar as exceções?

Cenário Perfeito:Cenário Perfeito:

É impossível tudo É impossível tudo ocorrer sem ocorrer sem problemas !problemas !

Desenvolver os Desenvolver os

Cenários Alternativos !Cenários Alternativos !

19

Cenários Alternativos

Permite uma seqüência diferente de eventos em relação ao cenário principal

Para cada um destes cenários atípicos será definido o fluxo de eventos correspondente.

São os casos onde podem ocorrer exceções, erros ou qualquer outra ação possível e diferente.

20


1. O sistema faz a leitura do cartão magnético

Alternativa: Problemas na leitura do cartão magnético

1a) Se o sistema não conseguir ler os dados do cartão magnético, tentar novamente por, no máximo, mais duas vezes. Caso persista o problema, encerrar o caso de uso.

21

Atores

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 seqüê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 seqüência de interações como o sistema, ou um evento acontece para que o sistema responda.

22

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

23

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.

24

Atores

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

Um ator pode participar de muitos casos de uso.

Um caso de uso pode envolver vários atores

25

Identificação dos elementos do modelo de casos de uso

26

Identificação dos elementos do modelo de casos de uso

Os atores e os casos de uso são identificados a partir de informações coletadas na fase de levantamento de requisitos do sistema. Durante esta fase, os analistas devem identificar as

atividades do negócio relevantes ao sistema a ser construído.

Não há uma regra geral que indique quantos casos de uso são necessários para descrever completamente um sistema.

A quantidade de casos de uso a ser utilizada depende completamente da complexidade do sistema.

27

Identificação de atores

Fontes e os destinos das informações a serem processadas são atores em potencial. uma vez que um ator é todo elemento externo que interage

com o sistema.

O analista deve identificar: as áreas da empresa que serão afetadas ou utilizarão o

sistema. fontes de informações a serem processadas e os destinos

das informações geradas pelo sistema.

28

Identificação de atores

Perguntas úteis: Que órgãos, empresas ou pessoas irão utilizar o

sistema? Que outros sistemas irão se comunicar com o

sistema a ser construído? Alguém deve ser informado de alguma ocorrência

no sistema? Quem está interessado em um certo requisito

funcional do sistema? O desenvolvedor deve ainda continuar a

pensar sobre atores quando passar para a identificação dos casos de uso.

29

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.

30

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

31

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.

32

Casos de Uso

Trabalhando com um caso realTrabalhando com um caso real

Sistema de Contas a PagarSistema de Contas a Pagar

33

Casos de Uso

No No levantamento levantamento

de dados ...de dados ...

Desejo um pequeno sistema que controle minhas contas a pagar. Deve emitir relatórios gerais ou por tipo de conta, para contas

vencidas e a vencer.

No futuro, gostaria de total integração desse sistema com

um conjunto de outros sistemas que vou pedir, além de

exportação e importação de arquivos para Palm.

34

Casos de Uso

Pensando nos Casos de Uso ...Pensando nos Casos de Uso ...

Quais são os atores ?Quais são os atores ?

Micro-Empresário Secretária

35

Casos de Uso

Existe relacionamento Existe relacionamento entre os atores?entre os atores?

Micro-Empresário Secretária

herda deherda de

Veremos isto com mais calma nas próximas aulasVeremos isto com mais calma nas próximas aulas

36

Casos de Uso

Quais as responsabilidades Quais as responsabilidades de cada ator ?de cada ator ?

* Secretária:* Secretária:

- Relatório de contas a vencer- Relatório de contas a vencer

- Relatório de contas vencidas- Relatório de contas vencidas

- Cadastrar tipo de conta- Cadastrar tipo de conta

37

Casos de Uso

Quais as responsabilidades Quais as responsabilidades de cada ator ?de cada ator ?

* Micro-empresário:* Micro-empresário:

todas as tarefas da Secretária + todas as tarefas da Secretária +

- Lançar conta a pagar- Lançar conta a pagar

- Registrar pagamento de conta- Registrar pagamento de conta

- Emitir extrato de lançamentos por período- Emitir extrato de lançamentos por período

38

Descrição dos Casos de Uso

. Cenário Principal . Cenário Principal

fluxo perfeito, no qual nada ocorre de erradofluxo perfeito, no qual nada ocorre de errado

. . Cenários AlternativosCenários Alternativos

alternativas do fluxo ; exceçõesalternativas do fluxo ; exceções

Casos de UsoCasos de Uso

39

Caso de UsoCaso de Uso Lançar Conta a Pagar Lançar Conta a Pagar

. Cenário Principal . Cenário Principal Ator: Micro-empresárioAtor: Micro-empresário

1. O usuário informa um tipo de conta.1. O usuário informa um tipo de conta.

2. O sistema busca e exibe a descrição do tipo 2. O sistema busca e exibe a descrição do tipo de conta.de conta.

3. O usuário informa:3. O usuário informa:

3.1. data de vencimento3.1. data de vencimento

3.2. descrição da conta3.2. descrição da conta

3.3. valor total a pagar3.3. valor total a pagar

3.4. valor parcial a pagar3.4. valor parcial a pagar


40

. Cenários Alternativos. Cenários Alternativos

Tipo de Conta InexistenteTipo de Conta Inexistente

... ... 2. O sistema busca e exibe a 2. O sistema busca e exibe a descrição do tipo de conta ...descrição do tipo de conta ...

3a. Se o tipo de conta não existir, carregar a 3a. Se o tipo de conta não existir, carregar a consulta de tipos de contas. consulta de tipos de contas. Extends Extends (Consultar tipos de contas)(Consultar tipos de contas)..

Tipo deTipo de

Relacionamento Relacionamento

entre Casos de Usoentre Casos de Uso


41

Exercício

Caso de uso Escreva um caso de uso que mostre uma

solicitação de reserva em um restaurante.

42

Caso de Uso:

Ator:

Cenário principal 1....


43

Diagrama de casos de uso

44

Diagrama de casos de uso (DCU)

Representa graficamente os atores, casos de uso e relacionamentos entre os elementos.

Tem o objetivo de ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema.

Uma espécie de “diagrama de contexto”. Apresenta os elementos externos de um sistema

e as maneiras segundo as quais eles as utilizam. Todo diagrama de casos de uso tem pelo

menos um ator

45

Relacionamentos

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

A UML define diversos tipos de relacionamentos no modelo de casos de uso: Comunicação Associação

Inclusão Extensão

Generalização VEREMOS MAIS ADIANTE

46

Notação

A notação para um ator em um DCU é a figura de um boneco com o nome do ator definido abaixo desta figura.

Cada caso de uso é representado por uma elipse. O nome do caso de uso é posicionado abaixo ou

dentro da elipse. Um relacionamento de comunicação é

representado por um segmento de reta ligando ator e caso de uso.

Pode-se também representar a fronteira do sistema em um diagrama de casos de uso.

47

É a relação de um ator com o caso de uso com o qual ele está interagindo.

É representada por uma linha sólida que conecta o símbolo de ator ao símbolo de caso de uso.

Relacionamentos de Comunicação

48

Exemplo (Notação)

Reservar Livro

Usuário

AtorCaso de uso

Relacionamentode comunicação

49

Exemplo (Notação)

Ator: é alguém ou alguma coisa que interage com o sistema Um ator é representado graficamente por um ícone de

um “homenzinho” (stickman)

50

Exemplo (Notação)

Sistema de Vendas deLivros por Correio

Cliente

Vendedor

Empresa Transportadora

Realizar Pedido

51

Relacionamentos

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

A UML define diversos tipos de relacionamentos no modelo de casos de uso: Comunicação Associação

Inclusão Extensão

Generalização

52

É a relação de um ator com o caso de uso com o qual ele está interagindo.

É representada por uma linha sólida que conecta o símbolo de ator ao símbolo de caso de uso.

Relacionamentos de Comunicação

53

É uma simples relação de inclusão, ou seja, os cenários ou situações possíveis detalhados em um caso de uso estão incluídos em outro caso de uso.

Quando dois ou mais casos de uso têm comportamento comum - uma seqüência comum de interações - esse comportamento pode ser modelado ou descrito em um caso de uso separado, que é utilizado por outros casos.

Relacionamento de Inclusão

54

Na elaboração de um sistema é comum que a mesma funcionalidade do sistema seja acessada por vários casos de uso.

Por exemplo, a funcionalidade de “Validar

Cliente” pode ser acessada quando: um novo cliente estiver sendo cadastrado; um novo pedido estiver sendo feito; ou uma consulta dos pedidos de um cliente for

solicitada, etc.


55

Esta relação serve para evitar a repetição deste caso de uso nos outros casos de uso, onde é necessário também “Validar Cliente”.

Podemos ler da seguinte maneira: o caso de uso “Consultar pedidos de um cliente” usa o caso de uso “Validar Cliente”.

Além disso, o roteiro de um caso de uso pode ser alterado por outro caso de uso.


56

Este conceito não é novo, podendo ser comparado ao conceito de sub-rotina ou subprograma e estas são algumas características das relações de uso: Aparecem como funcionalidade comum ao invés

de especificar vários casos de uso; Os casos <<include>> usados são casos de uso

por si só, isto é, existem primariamente como um caso de uso;

O caso de uso <<include>> é usado sempre que o caso de uso principal é executado. Isto faz a diferença com as extensões, que são opcionais.


57

Criar Pedido

Alterar Pedido

Validar Pedido

Cliente

<<inclui>>

<<inclui>>

58

Relacionamento de extensão

Utilizado para modelar situações onde diferentes seqüências de interações podem ser inseridas em um caso de uso.

Sejam A e B dois casos de uso. Um relacionamento de extensão de A para B

indica que um ou mais dos cenários de B podem incluir o comportamento especificado por A.

Neste caso, diz-se que B estende A. O caso de uso A é chamado de estendido e o

caso de uso B de extensor.

59


Cada uma das diferentes seqüências representa um comportamento opcional, que só ocorre sob certas condições ou cuja realização depende da escolha do ator.

Quando um ator opta por executar a seqüência de interações definida no extensor, este é executado. Após a sua execução, o fluxo de interações volta ao

caso de uso estendido, recomeçando logo após o ponto em que o extensor foi inserido.

Importante: não necessariamente o comportamento definido pelo caso de uso extensor é realizado.

60


Exemplo: considere um processador de textos. Considere que um dos casos de uso deste sistema seja Editar Documento. No cenário principal deste caso de uso, o ator

abre o documento, modifica-o, salva as modificações e fecha o documento.

Mas, em outro cenário, o ator pode desejar que o sistema faça uma verificação ortográfica no documento.

Em outro, o ele pode querer realizar a substituição de um fragmento de texto por outro.

62

Cliente

Solicitar seguro de vida

Solicitar cartão de crédito

<<extend>>

63

Relacionamentos entre casos de usoRelacionamentos entre casos de uso

CadastrarFuncionário

CadastrarDependentes

ValidarCPF

«extends«extends»»

«include»«include»

64

Relacionamento de generalização

Relacionamento no qual o reuso é mais evidente.

Este relacionamento permite que um caso de uso (ou um ator) herde características de um caso de uso (ator) mais genérico.

O caso de uso (ator) herdeiro pode especializar o comportamento do caso de uso (ator) base.

Resumo: Pode existir entre dois casos de uso ou entre dois atores.

65


Vantagem: comportamento do caso de uso original é reutilizado pelos casos de uso herdeiros. Somente o comportamento que não faz sentido ou

é diferente para um herdeiro precisa ser redefinido.

66


A generalização entre atores significa que o herdeiro possui o mesmo comportamento que o ator do qual ele herda.

Além disso, o ator herdeiro pode participar em casos de uso em que o ator do qual ele herda não participa.

Um exemplo: considere uma biblioteca na qual pode haver alunos e professores como usuários. Ambos podem realizar empréstimos de títulos de

livros e reservas de exemplares. No entanto, somente o professor pode requisitar a

compra de títulos de livros à biblioteca.

67

Relacionamentos: Generalização entre casos de uso: significa que um caso de uso

filho herda o comportamento e o significado do caso de uso pai O caso de uso filho deverá acrescentar ou sobrescrever o

comportamento do caso de uso pai

• A generalização é representada graficamente por uma linha sólida com um triângulo numa das extremidades

•O triângulo aponta para o caso de uso pai

Relacionamento de generalização - Resumo

68

Notação Os relacionamentos de inclusão, extensão e herança são

representados por uma seta direcionada de um caso de uso para outro.

A seta (tracejada) de um relacionamento de inclusão recebe o estereótipo <<inclui>>.

A seta (tracejada) de um relacionamento de inclusão recebe o estereótipo <<estende>>.

A seta (sólida) de um relacionamento de herança não recebe estereótipo.

69

Notação

Realizar Saque

Cliente

FornecerIdentificação

«inclui»

«inclui»

RealizarTransferência

Obter Extrato

«inclui»

70

Notação

Editar Documento

Escritor

Corrigir Ortografia

Substituir Texto

«estende»

«estende»

71

Generalização - Atores Notação

Professor

Usuário

Solicitar Comprade Título

Reservar Livro

Devolver Livro

72

Generalização - Atores Notação

Atores podem ter relacionamentos de generalização entre eles (uma vez que representam classes)

Cliente

Cliente especial Cliente regular

73

Notação

Realizar Pagamento

Realizar Pagamentocom Cartão de Crédito

Realizar Pagamentocom Dinheiro

Cliente

74

Desenvolva um diagrama de casos de uso para o problema a seguir:

Quando um cliente compra um eletrodoméstico ele se dirige ao caixa da loja para efetuar o pagamento do que foi comprado. O cliente pode pagar à vista, no crediário da loja ou com cartão de crédito. Para qualquer forma de pagamento a loja realiza uma consulta no SPC para depois emitir a NF de venda.

75

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.

76

Cenário Principal

Descreve um seqüência de ações que serão executadas considerando que nada de errado ocorrerá durante a a execução da seqüência.

É o cenário perfeito

77

Ator: Correntista1. O sistema faz a leitura do cartão magnético.2. O sistema solicita a digitação da senha.O correntista informa sua senha.3. O sistema valida a senha, verificando se é a mesma senha que

está associada ao correntista.4. O correntista seleciona a opção de saldo5. O sistema questiona o tipo de saldo: conta corrente, poupança, investimentos6. O sistema processa e mostra o saldo solicitado pelo clienteetc

Cenário Principal

Trecho do caso de uso

“Emitir Saldo em um terminal de caixa eletrônico”

78


Permite uma seqüência diferente de eventos em relação ao cenário principal

Para cada um destes cenários atípicos será definido o fluxo de eventos correspondente.

São os casos onde podem ocorrer exceções, erros ou qualquer outra ação possível e diferente.

79

Tratamento de Exceções no Caso de Uso

Depois de descrever o fluxo principal do caso de uso, deve-se imaginar o que poderia dar errado em cada um dos passos descritos

Uma exceção é um evento que se não for devidamente tratado impede o prosseguimento do caso de uso

A exceção em um processo não é necessariamente algo que impede que o processo seja iniciado, mas normalmente algo que impede que ele seja concluído

80


1. O sistema faz a leitura do cartão magnético

Alternativa: Problemas na leitura do cartão magnético

1a) Se o sistema não conseguir ler os dados do cartão magnético, tentar novamente por, no máximo, mais duas vezes. Caso persista o problema, encerrar o caso de uso.

81

Partes de um tratamento de exceção (sugestão) Identificador – número da linha no FP e

código da exceção Descrição da exceção – uma frase Ações corretivas – um fluxo alternativo Finalização – se e como retorna-se ao FP

82

Formas de Finalizar um Fluxo Alternativo Voltar ao início do passo que causou a

exceção Ir para algum passo posterior Voltar ao início do caso de uso Abortar o caso de uso

83

Forma a ser evitada no Fluxo Principal Se o cliente possui cadastro então o

funcionário registra...

84

Níveis de Detalhamento

Alto Nível Expandido

85

Exemplo de Caso de Uso de Alto Nível

Caso de uso: Emprestar Fitas

Um cliente solicita a locação de algumas fitas. Após identificar-se e identificar as fitas ele pode levá-las para casa, ciente do prazo de devolução e do valor a ser pago.

86

Exemplo de Caso de Uso Expandido

Fluxo Principal:

1. O cliente chega ao balcão com as fitas que deseja locar.

2. O cliente informa seu nome e entrega as fitas ao funcionário.

3. O funcionário registra o nome do cliente e inicia a locação.

4. O funcionário registra cada uma das fitas.

5. O funcionário finaliza a locação, devolve as fitas ao cliente e lhe informa a data de devolução e o valor total da locação.

6. O cliente vai embora com as fitas.

Tratamento de Exceções:

3a. O cliente não possui cadastro.

3a.1 O cliente deve informar seus dados para cadastro.

3a.2 O funcionário registra o cadastro.

3a.3 Retorna ao fluxo principal no passo 3.

3b. O cliente possui pendências no cadastro (locação anterior não foi paga).

3b.1 O cliente paga seu débito.

3b.2 O funcionário registra a quitação do débito, eliminando assim a pendência.

3b.3 Retorna ao passo 3.

4a. Uma fita está reservada para outro cliente.

4a.1 O funcionário informa que a fita não está disponível para locação.

4a.2 Prossegue a locação do passo 4 sem incluir a fita reservada.

4b. Uma fita está danificada.

4b.1 O funcionário informa que a fita está danificada.

4b.2 O funcionário registra que a fita está danificada.

4b.3 O funcionário verifica se existe outra fita disponível com o mesmo filme.

4b.3 Se existir, o funcionário substitui a fita e segue no passo 4, senão segue do passo 4 sem incluir a fita danificada.

Caso de Uso: Locar Fitas

87

Passos em um Fluxo

Obrigatórios Complementares Não Recomendados

88

Passos Obrigatórios

Indicam as entradas e saídas de informação do sistema necessárias para realizar o caso de uso.

Na falta de qualquer um desses passos o caso de uso pode ficar sem sentido.

89

Exemplo de caso de uso onde falta uma entrada de informação

Caso de Uso (mal construído): Reservar um Filme

1. O cliente entra em contato com o funcionário da videolocadora (possivelmente por telefone).

2. O cliente informa seu nome.

3. O cliente solicita uma reserva.

4. O funcionário confirma a reserva.

90

Um diálogo impossível baseado no caso de uso anterior

Cliente: Boa tarde!

Funcionário: Boa tarde! Em que posso servi-lo?

Cliente: Meu nome é João e eu gostaria de reservar um filme.

Funcionário: Pois não, Senhor. Acabo de efetuar a reserva.

Cliente: Grato!

91

O que faltou?

92

Uma solução mais adequada

Caso de Uso: Reservar um Filme



3. O cliente solicita uma reserva informando o nome do filme.

4. O funcionário confirma a reserva, informando o prazo de validade.

93

Tipos de passos obrigatórios

Eventos de sistema – entradas. Respostas de sistema – saídas.

Obs. Não são respostas de sistema retornos do tipo “ok”. Deve ser enviada ao mundo externo algum tipo de informação que o sistema armazena.

94

Identificação de passos obrigatórios em um Caso de Uso

Caso de Uso: Reservar um Filme


2. [EV] O cliente informa seu nome.

3. [EV] O cliente solicita uma reserva informando o nome do filme.

4. [RS] O funcionário confirma a reserva, informando o prazo de validade.

95

Passos Complementares

Não possuem uma entrada ou saída do sistema, mas ajudam a compreender o contexto.

Estes passos têm pouca ou nenhuma influência na complexidade do software a ser desenvolvido.

96

Exemplos de passos complementares “o cliente chega ao balcão com as fitas que

deseja locar” “o cliente vai embora com as fitas” “o funcionário pergunta o nome do cliente” “o sistema informa que a reserva foi

concluída com sucesso”

97

Passos Não Recomendados

São os processos internos ao sistema . O caso de uso deve descrever a interação

entre o sistema e os atores externos, não o processamento interno.

98

Exemplos de passos que não deveriam constar em um caso de uso

“o sistema registra o nome do cliente no banco de dados”

“o sistema calcula a média das vendas”

99

Um exemplo de caso de uso com passos não recomendados

Caso de Uso (mal construído): Emprestar Fitas

1. O cliente chega ao balcão com as fitas que deseja emprestar.


3. O funcionário registra o nome do cliente.

4. O sistema verifica se o cliente tem cadastro e se o cliente não está suspenso por não pagamento de empréstimos anteriores.

5. O funcionário registra cada uma das fitas.

6. O sistema verifica no banco de dados o registro das fitas e marca cada uma como “emprestada”. Posteriormente o sistema adiciona cada fita ao empréstimo corrente e soma o valor das fitas no total do empréstimo.

7. O funcionário encerra o empréstimo.

8. O cliente vai embora com as fitas.

100

Consultas no caso de uso

Evite: “o sistema verifica se o usuário está cadastrado”

Prefira: “o funcionário informa a identificação do cliente” “o sistema informa os dados do cadastro do

cliente”

1 casos de uso. 2 princípios de análise e projeto orientados a objetos com uml eduardo bezerra...

Documents