III. DESCRIÇÃO DE CASOS DE USO

1

5. Descrever cada caso de uso incluindotudo o que acontece a partir da ocorrênciado evento que deu origem ao caso de uso

Exemplo:

Caso de uso Faz Pedido

2

Faz pedidoCenário principal: Venda realizada com sucesso por umnovo cliente1. Cliente informa dados pessoais (cpf , nome, endereço,

telefone e e-mail) e endereço de entrega2. Cliente informa a lista dos livros desejados e

respectivas quantidades3. Sistema armazena além dos dados f ornecidos pelo

cliente, a data de emissão do pedido e o preço cobradopor cada livro, já que pode ser dado algum desconto eo valor cobrado não será o de tabela

4. Sistema envia ao cliente a confi rmação da venda com onúmero de seu pedido, seu código, a lista dos itenspedidos com quantidade e preço de cada item e o preçototal do pedido.

3

Cenário alternativo: Venda realizada com sucesso por cliente já cadastrado 1.

Cliente inf orma seu código Sistema valida o código Sistema apresentada as inf ormações

relativas à última compra: nome, cpf , endereço, telef one, e-mail e endereço de entrega

Cliente atualiza seus dados Continua a partir do passo 2.

4

Cenário alternativo: Autorização de venda negada a um cliente já cadastrado 1.

Cliente informa seu código Sistema valida o código Sistema comunica que o cliente não poderá

f azer um pedido por ter dívidas pendentes. Os passos seguintes não são realizados.

5

Cada caso de uso deve ser descritoatravés de uma seqüência de passos,mostrando a interação entre o ator (ouatores) e o caso de uso.

Nesta descrição deve-se dizer como ocaso de uso inicia, como interage com osatores e as inf ormações que participamnesta comunicação.

O caso de uso Faz pedido poderia serdescrito da seguinte f orma:

III. DESCRIÇÃO DE CASOS DE USO

6

Faz pedido: I nicia quando um cliente emite um pedido. Eledeverá informar seus dados pessoais (cpf , nome, endereço,telefone e e-mail), caso seja um cliente novo. Quando f or umcliente antigo poderá dizer seu código que será validado. Ocliente deverá ainda informar os dados relativos ao pedido: alista dos livros desejados (I SBN) e respectivas quantidades.Deve ser armazenada a data de emissão do pedido e o valorcobrado por cada livro, já que pode ser dado algum desconto eo valor cobrado não será o valor de tabela. O cliente recebe aconfi rmação da venda com o número de seu pedido, seu códigoe todas as demais informações relativas ao pedido. O pedidonão será aceito caso o cliente tenha dívidas pendentes.

7

Essa descrição poderia ser melhor organizadaatravés da descrição com maior clareza dessespassos e da elaboração de cenários.

Um cenário é uma seqüência de passos quedescreve a comunicação entre o ator e osistema.

Poderíamos descrever o seguinte cenário, querelata os passos de uma venda realizada comsucesso por um novo cliente.

8





4. Sistema envia ao cliente a confi rmação da venda com onúmero de seu pedido, seu código, a lista dos itenspedidos com quantidade e preço de cada item e o preçototal do pedido.

9

Em Faz pedido pode ocorrer do cliente játer realizado alguma compraanteriormente.

Assim, poderíamos descrever um outrocenário chamado de alternativo que f azref erência aos passos do cenário principal(só são descritos os passos do cenárioalternativo que são dif erentes do cenárioprincipal)

No cenário alternativo apresentado aseguir o passo 1 do cenário principal ésubstituído pelo que é descrito no cenárioalternativo e todos os demais passos sãoiguais.

10


Cliente inf orma seu código Sistema valida o código Sistema apresentada as inf ormações relativas

à última compra: nome, cpf , endereço, telef one, e-mail e endereço de entrega


11


Cliente inf orma seu código Sistema valida o código Sistema comunica que o cliente não poderá


Outro cenário alternativo:

12

Veja em anexo (arquivo rup_ucspec) como o RUP propõe a especificação de um caso de uso. O documento de especificação de casos de uso complementa a Especificação de Requisitos do Sof tware, um documento do RUP que pode ser visto em anexo (arquivo rup_src)

Casos de uso e o RUP (Rational Unified Process):

13

Descrever um cenário dos casos de uso do Sistema de robôs, utilizando template RUP

Exercício:

14

DIAGRAMA DE CASOS DE USO PERSPECTIVA CONCEITUAL

2ª PARTE RELACIONAMENTOS ENTRE CASOS DE USO

EXTENSÃO (EXTEND) INCLUSÃO (INCLUDE) GENERALIZAÇÃO

GENERALIZAÇÃO DE ATORES

ORGANIZANDO OS CASOS DE USO EM PACOTES

ELABORANDO O DIAGRAMA

NOTAÇÕES ALTERNATIVAS

15

I . RELACIONAMENTOS ENTRE CASOSDE USO

– EXTENSÃO (EXTEND)– I NCLUSÃO (I NCLUDE)– GENERALI ZAÇÃO

16

I .1 Relacionamento de Extensão (extend)

Utilizamos extensões quando há variações decomportamentos normais e desejamos utilizar umamaneira mais f ormal que os cenários para indicaressas variações e o ponto em elas ocorrem no casode uso.

17

Caso de uso Base

Caso de Uso Extensão

<<extend>>

Ponto deExtensão

18

Funcionário Fatura pedido

Cliente

Exemplo utilizando cenários:

A variação de comportamento normal pode serobservada no cenário Atraso na entrega de umitem do pedido do caso de uso Fatura pedido

19

Fatura pedidoCenário principal: f aturamento de pelo menos um item do pedido

1. Funcionário seleciona um pedido que não tenha sido integralmenteatendido (f aturado)

2. Sistema verifica a quantidade pendente (quantidadePedida -quantidadeAtendidaTotal) de cada item

3. Sistema cria uma f atura com o número da f atura, a data deemissão, a data limite de pagamento e a quantidade de cada item.

4. Sistema emite a f atura que deverá ser encaminhada ao clientejuntamente com os livros. A f atura deverá conter:- Número da f atura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário cobrado

- Preço total

20

Obs: A quantidade f aturada de cada item está limitada ao

que há em estoque. Caso não possa ser f eito umatendimento completo neste momento, mais adiante,logo que haja o item em estoque, será criada uma novafatura.

Uma f atura f az ref erência a um e apenas um pedido.No entanto ela pode estar atendendo apenasparcialmente àquele pedido.

21

Cenário alternativo: Atraso, sem previsão de entrega, de um ou mais itens do pedido 2.

Sistema verifi ca a quantidade pendente (quantidadePedida - quantidadeAtendidaTotal) de cada item.

Sistema verifi ca que um ou mais itens pedidos não poderão ser entregues e que não há previsão de entrega.

Sistema comunica ao cliente descrevendo o número do pedido e os itens para os quais não há previsão de entrega.

Continua a partir do passo 3.

22

Comunica atraso

Funcionário

Fatura pedido

(verificação de itens pendentes)

<<extend>>

Cliente

Solução utilizando extensão:

23

Explicando o diagrama criado:

É criado um caso de uso B e estabelecido umrelacionamento entre o caso de uso original A e estenovo, que representa a extensão.

Este relacionamento é representado através de umaassociação com estereótipo extend.

BA

<<extend>>

24

Na descrição do caso de uso original (A) deve serindicado o ponto de extensão e o caso de usoestendido (B) irá acrescentar um comportamentoadicional exatamente neste ponto.

Estereótipo

Um recurso da UML que permite estender a linguagem. Possibilita a criação de novos elementos derivados de outros já existentes.

25

Fatura pedidoCenário principal: f aturamento de pelo menos um item do pedido

1. Funcionário seleciona um pedido que não tenha sido integralmenteatendido (f aturado)

2. Sistema verifica a quantidade pendente (quantidadePedida -quantidadeAtendidaTotal) de cada item(Extend – Comunicaatraso)

3. Sistema cria uma fatura com o número da f atura, a data deemissão, a data limite de pagamento e a quantidade de cada item.4. Sistema emite a f atura que deverá ser encaminhada ao cliente

juntamente com os livros. A f atura deverá conter:- Número da f atura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário cobrado

- Preço total

26

Obs: A quantidade f aturada de cada item (livro) está

limitada ao que há em estoque. Caso não possa ser f eitoum atendimento completo neste momento, maisadiante, logo que haja o item em estoque, será criadauma nova f atura.

Uma f atura f az ref erência a um e apenas um pedido.No entanto ela pode estar atendendo apenasparcialmente àquele pedido.

27

Comunica atraso

Sistema verifica que um ou mais itens pedidosnão poderão ser entregues e que não há previsãode entrega.

Sistema comunica ao cliente o atrasodescrevendo o número do pedido e os itens paraos quais não há previsão de entrega.

28

Como um caso de uso pode ter vários pontos deextensão devemos indicar em cada associação oponto de extensão ref erenciado.

Comunica atraso

Funcionário

Fatura pedido


<<extend>>

Cliente

29

I .2 Relacionamento de I nclusão (include)

Utilizamos relacionamentos de inclusão quandohá comportamentos similares em dois ou maiscasos de uso e não desejamos repetir a descriçãodesses comportamentos.

30

Caso de uso Base

Caso de Uso Inclusão

<<include>>

31

Exemplo sem inclusão:

Diminui quantidade de um item do pedido eSolicita cancelamento de pedido são doiscasos de uso em que podemos observar que umcomportamento é repetido: a validação donúmero do pedido.

Cliente

Solicita cancelamento de pedido

Diminui quantidade de um item do pedido

32

Diminui quantidade de um item do pedidoCenário principal: Quantidade diminuida

1. Cliente informa seu código2. Sistema valida código3. Cliente informa número do pedido4. Sistema verifica a existência do número do pedido5. Sistema envia ao cliente os dados relativos a seu pedido: a lista dos itens pedidos com quantidade e preço unitário de cada item e o preço

total do pedido a lista das faturas emitidas contendo para cada fatura:- Número da fatura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário- Preço total6. Cliente informa o item a ser reduzido7. Sistema apresenta ao cliente a quantidade pendente (quantidade pedida –

quantidade faturada)8. Cliente informa a nova quantidade (no máximo a quantidade pendente)9. Sistema armazena a nova quantidade10. Sistema envia ao cliente a confi rmação da alteração realizada

33

Solicita cancelamento de pedidoCenário principal: Pedido cancelado por não haver fatura emitida

1. Cliente informa seu código2. Sistema valida código3. Cliente informa número do pedido4. Sistema verifi ca a existência do número do pedido5. Sistema envia ao cliente os dados relativos a seu pedido: a lista dos itens pedidos com quantidade e preço unitário de cada item e o preço total do

pedido a lista das faturas emitidas contendo para cada fatura:- Número da fatura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário- Preço total6. Sistema cancela o pedido (não há nenhuma fatura emitida para ele) e armazena a data de

cancelamento7. Sistema envia ao cliente a confi rmação do cancelamento solicitado.

34

Solução utilizando inclusão:

Cliente

Solicita cancelamentode pedido

Valida pedido


<<include>>

<<include>>

35


Um relacionamento de inclusão de um caso de uso Apara um caso de uso B é representado através deuma associação com estereótipo include e indica queuma instância do caso de uso A sempre conterá ocomportamento especifi cado por B.

O comportamento do caso de uso B é incluído noponto do caso de uso A indicado na especificação docaso de uso A.

BA

<<include>>

36

Diminui quantidade de um item do pedidoCenário principal: Quantidade diminuida

1. Cliente informa seu código2. Sistema valida código3. Cliente informa número do pedido4. Sistema valida número do pedido (include – Valida

pedido)5. Cliente informa o item a ser reduzido6. Sistema apresenta ao cliente a quantidade pendente

(quantidade pedida – quantidade f aturada)7. Cliente informa a nova quantidade (no máximo a

quantidade pendente)8. Sistema armazena a nova quantidade9. Sistema envia ao cliente a confi rmação da alteração

realizada

37

Solicita cancelamento de pedidoCenário principal: Pedido cancelado por não haver f atura emitida

1. Cliente informa seu código2. Sistema valida código3. Cliente informa número do pedido4. Sistema valida número do pedido (include – Valida pedido)5. Sistema cancela o pedido (não há nenhuma fatura emitida para

ele) e armazena a data de cancelamento

6. Sistema envia ao cliente a confirmação do cancelamentosolicitado.

38

Valida pedido

1. Sistema verifica a existência do número do pedido2. Sistema envia ao cliente os dados relativos a seu

pedido: a lista dos itens pedidos com quantidade e preço

unitário de cada item e o preço total do pedido a lista das f aturas emitidas contendo para cada

fatura:- Número da f atura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário

- Preço total

39

I .3 Relacionamento de Generalização

Podemos usar a generalização quando temos um caso deuso que é semelhante a outro mas f az algo a mais.

Podemos representar essa variação através de cenáriosalternativos em um único caso de uso. No entanto, seconsiderarmos que vale a pena separar essa variaçãonum caso de uso, podemos utilizar o relacionamento degeneralização.

40

Exemplo utilizando cenários:

O pedido f eito por um cliente pode seroferecido como presente. Desta f orma teríamosem Faz pedido um cenário alternativo relativo aessa situação.

Cliente Faz pedido

41





4. Sistema envia ao cliente a confirmação da venda com onúmero de seu pedido, seu código, a lista dos itenspedidos com quantidade e preço de cada item e o preçototal do pedido.

42

Faz pedido Cenário alternativo: Venda realizada com sucesso por um novo cliente para presentear 1.

Cliente inf orma dados pessoais (cpf , nome, endereço, telef one e e-mail)

Cliente informa dados do presenteado: nome e endereço de entrega


43

Solução utilizando generalização:

Cliente Faz pedido

Faz pedido para presentear

44


A generalização de um caso de uso B para um caso de uso Aindica que B é uma especialização de A e é representadocomo o exemplo a seguir.

A

B

45

A generalização é um relacionamento entre umelemento mais genérico (o pai) e um elemento maisespecífi co (o fi lho) que é totalmente consistentecom o primeiro elemento e acrescenta inf ormaçõesadicionais. É um relacionamento utilizado em casosde uso mas também em atores, classes e outroselementos.

Podemos descrever o caso de uso específi coreferenciando o cenário principal do caso de usogenérico (os passos modifi cados são descritos)

46





4. Sistema envia ao cliente a confirmação da venda com onúmero de seu pedido, seu código, a lista dos itenspedidos com quantidade e preço de cada item e o preçototal do pedido.

47


1. Cliente informa dados pessoais (cpf , nome,endereço, telefone e e-mail)

Cliente informa dados do presenteado:nome e endereço de entrega


48

I I . GENERALIZAÇÃO DE ATORES

Caso seja necessário podemos utilizar o relacionamentode generalização entre atores.

A generalização de um ator C para um ator D indica que Cpode se comunicar com os casos de uso que se comunicamcom o ator D. A seta dirige-se do atorque é uma especializaçãopara o ator genérico.

C

D

49

Exemplo:

O gerente também poderia f aturar um pedido. Omesmo não ocorre como o funcionário, que não tempermissão para cancelar uma f atura.

Funcionário Fatura pedido

Gerente Avalia cancelamento de fatura

50

III. ORGANIZANDO OS CASOS DE USO EM PACOTES

Na UML os modelos podem ser organizados empackages (ou pacotes) de f orma que possamoscompreendê-los mais f acilmente.

O package é f ormado por um grupo de elementoscom um tema comum. Esses elementos podem serclasses, componentes, casos de uso e até mesmooutros pacotes.

51

Exemplo:

Poderíamos no caso exemplo, ter dois packages:Controle de pedidos e Controle de Livros

Controle de livros

Controle de pedidos

52

O diagrama de casos de uso apresentado a seguirpertence ao package Controle de pedidos, quecontém os casos de uso relacionados àadministração de pedidos e f aturamento

O package Controle de Livros conteria, porexemplo, casos de uso responsáveis por incluirum novo livro e por atualizar os preços dos livros

53Gerente

Funcionário

Solicita cancelamentode fatura

Paga fatura

Comunica atraso no pagamento

Avalia cancelamento de fatura

Fatura pedido



Cliente

Faz pedido

Casos de uso do package Controle de Pedidos

54

Utilidade do uso de packages quando estamos modelandoum grande sistema:

- possibilita a divisão do sistema em subsistemas

- f acilita o entendimento do sistema

- permite que informações sejam encontradas com maisfacilidade

55

1. I dentifi car os atores

Exemplo - Sistema de controle de pedidos:

Cliente Funcionário Gerente

IV. ELABORANDO O DIAGRAMA

56

2. I dentifi car os eventos externos aos quais o sistema deve responder

Eventos externos são eventos iniciados pelos atores. Um ator inicia o processo, apesar de poderem existir outros atores envolvidos. Os atores podem enviar dados, f azer

solicitações e receber inf ormações. Exemplos: Cliente f az pedido Cliente diminui a quantidade de um item do pedido Cliente paga f atura Cliente solicita cancelamento de pedido Cliente solicita cancelamento de f atura Funcionário f atura pedido Gerente avalia cancelamento de pedido

57

3. I dentifi car os eventos não iniciados pelos atores

Esses eventos podem ocorrer num momento jápré-estabelecido, como a geração de um relatóriosempre no primeiro dia útil do mês, ref erente ao mêsanterior.

Podem também ser eventos que ocorrem aqualquer momento, como o evento Atraso depagamento de f atura. A qualquer dia uma f atura podesof rer atraso.

Exemplo: Atraso de pagamento de f atura

58

4. Criar para cada evento um caso de usocorrespondente, estabelecendo osrelacionamentos entre os casos de uso e osatores

59Gerente

Funcionário

Solicita cancelamento de faturaPaga fatura



Fatura pedido


Solicita cancelamento de pedido

Cliente

Faz pedido

60

5. Estabelecer, quando necessário, relacionamentosentre:

casos de uso atores

61Gerente

Funcionário

Comunica atraso

Valida pedido

Solicita cancelamento de fatura

Paga fatura

Comunica atrasono pagamento


Fatura pedido


<<extend>> Diminui quantidade de um item do pedido

<<include>>


<<include>>

Faz pedido

Cliente

Faz pedido parapresentear

62

6. Descrever cada caso de uso incluindotudo o que acontece a partir da ocorrênciado evento que deu origem ao caso de uso

Exemplo:

Caso de uso Faz Pedido

63

Faz pedidoCenário principal: Venda realizada com sucesso porum novo cliente1. Cliente inf orma dados pessoais (cpf , nome,

endereço, telef one e e-mail) e endereço deentrega

2. Cliente inf orma a lista dos livros desejados erespectivas quantidades

3. São armazenadas a data de emissão do pedido e ovalor cobrado por cada livro, já que pode ser dadoalgum desconto e o valor cobrado não será o valorde tabela

4. Cliente recebe a confirmação da venda com onúmero de seu pedido, seu código e todas asdemais inf ormações relativas ao pedido.

64


Cliente informa seu código Código é validado São apresentadas as inf ormações relativas

à última compra: endereço, telefone, e-mail e endereço de entrega


65


Cliente informa seu código Código é validado Sistema comunica que o cliente não poderá


66

7. Organizar os casos de uso em packages

8. Revisão do modelo

Controle de livros

Controle de pedidos

67

V. NOTAÇÕES ALTERNATIVAS

Associações

Atores

68

Na UML a associação é representada por umalinha.

Outras alternativas vêm sendo utilizadas, como ade [Quatrani], que utiliza uma seta nasassociações entre atores e casos de uso,indicando quem está iniciando a comunicação.

Associações

69

Quando a seta tem o sentido ator - caso de uso

Signifi ca que o ator está iniciando a comunicação,requerendo algo do sistema

Exemplo:Caso de uso Faz pedido

Cliente Faz pedido

70

Quando a seta tem o sentido caso de uso-ator

Signifi ca que algo ocorreu no sistema sem ainterf erência de um ator e este f oi comunicado

Exemplo: Caso de uso Comunica atraso no pagamento

ClienteComunica atraso no pagamento

71

De acordo com a UML todos os atores envolvidos nocaso de uso devem ser representados no diagrama,desde que participem do caso de uso.

Há no entanto variações com relação a essa questão:[Fowler], por exemplo, sugere que se inclua somente

aquele ator que é realmente importante para o caso deuso.

Atores

72

Uma opção, de f orma a tornar o diagrama maissimples, é a seguinte:

- incluir somente aquele ator que é responsávelpor iniciar o caso de uso

- incluir aquele ator que é comunicado, quandoocorre algo no sistema

- outros atores envolvidos com o caso de uso sãomencionados na descrição do caso de uso

73

Avalia cancelamentode fatura

Gerente

Exemplo:Caso de uso Cancela Fatura.

O gerente autoriza ou não o cancelamento dafatura e envia um comunicado para o ator cliente,mas o cliente só é mencionado na descrição do casode uso.

74

Diagrama com as notações alternativas:

Gerente

Funcionário

Comunica atraso

Valida pedido

Solicita cancelamento de fatura

Paga fatura



Fatura pedido


<<extend>>Diminui quantidade de um item do

pedido

<<include>>

Solicita cancelamento de pedido<<include>>Faz pedido

Cliente


75

Exercício:

Desenvolver o Diagrama de Casos de Uso Refatorado para o sistema de robôs da Petrobrás.

76

Exercício:

Desenvolver os cenários dos Casos de Uso para o sistema de robôs da Petrobrás.

77

REFERÊNCIAS

[Fowler] Fowler, Martin; Scott, Kendall; UML Distilled Second Edition – A Brief Guide to the Standard Object Modeling Language, Ed. Addison-Wesley, 1999.

[Quatrani] Terry Quatrani, Visual Modeling With Rational Rose 2000 and UML, Ed. Addison Wesley, 2000.

III. DESCRIÇÃO DE CASOS DE USO

Documents

Transcript of III. DESCRIÇÃO DE CASOS DE USO