1

DIAGRAMA DE CASOS DE USO PERSPECTIVA CONCEITUAL

1ª PARTE

DIAGRAMA

CASOS DE USO E ATORES

DESCRIÇÃO DE CASOS DE USO

RELACIONAMENTO ENTRE ATOR E CASO DE USO

ELABORANDO O DIAGRAMA

2

I . DIAGRAMA DE CASOS DE USO

Ao iniciar o levantamento de requisitos de

um sistema o primeiro diagrama a ser elaborado é o diagrama de casos de uso.

Permite a descrição das f unções do

sistema, a representação da comunicação do sistema com o exterior e a definição dos limites do sistema.

3Gerente

Funcionário

Solicita cancelamento de faturaPaga fatura

Comunica atraso no pagamento

Avalia cancelamento de fatura

Fatura pedido

Diminui quantidade de um item do pedido

Solicita cancelamento de pedido

Cliente

Faz pedido

Diagrama de casosde uso

4

I I . CASOS DE USO E ATORES

Um diagrama de caso de uso apresenta casos de uso,atores e os relacionamentos entre esse elementos.

Atores representam papéis desempenhados porpessoas, dispositivos de hardware ou outros sistemasque necessitam, por exemplo, de informações dosistema que está sendo modelado

Casos de uso representam as f uncionalidades dosistema.

Cliente - atorFaz pedido - caso de uso

Cliente

Faz pedido

5

I V. RELACIONAMENTO ENTRE ATOR E CASO DE USO

Um ator pode estimular o sistema através deeventos.

No exemplo em que o caso de uso é Faz pedido, oator Cliente estimula o sistema ao f azer umpedido.

Ao f azer o pedido o cliente envia determinadasinf ormações ao sistema e recebe uma respostaindicando se seu pedido f oi aceito ou não.

6

Cliente

Faz pedido

A maneira de apresentar estacomunicação entre o ator e o caso de usoé através de uma associação entre ambos,representada por uma linha.

7

Em algumas situações há mais de um atorenvolvido, como no caso de uso Faturapedido.

O pedido é f aturado pelo funcionário eenviado ao cliente

Funcionário Fatura pedido

Cliente

8

1. I dentifi car os atores

Exemplo - Sistema de controle de pedidos:

Cliente Funcionário Gerente

V. ELABORANDO O DIAGRAMA

9

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 Funcionário f atura pedido Cliente solicita cancelamento de f atura Gerente avalia cancelamento de f atura

10

3. I dentificar os eventos não iniciados pelos atores

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

Podem também ser eventos que ocorrem a qualquer momento, como o evento Atraso de pagamento de f atura. A qualquer dia uma f atura pode sof rer atraso.

Exemplo: Atraso de pagamento de f atura

11

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

12Gerente

Funcionário

Solicita cancelamento de faturaPaga fatura

Comunica atraso no pagamento

Avalia cancelamento de fatura

Fatura pedido

Diminui quantidade de um item do pedido

Solicita cancelamento de pedido

Cliente

Faz pedidoExemplo:

13

Exercício:

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

14

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

15

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.

16

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.

17

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.

18

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

19

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.

20

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.

21

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.

22

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.

23

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.

24

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

Cliente inf orma 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.

Outro cenário alternativo: