1 casos de uso e o rup (rational unified process) :
TRANSCRIPT
1
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):
2
Descrever um cenário dos casos de uso do Sistema de robôs, utilizando template RUP
Exercício:
3
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
4
I . RELACIONAMENTOS ENTRE CASOSDE USO
– EXTENSÃO (EXTEND)– I NCLUSÃO (I NCLUDE)– GENERALI ZAÇÃO
5
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.
6
Caso de uso Base
Caso de Uso Extensão
<<extend>>
Ponto deExtensão
7
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
8
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
9
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.
10
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.
11
Comunica atraso
Funcionário
Fatura pedido
(verificação de itens pendentes)
<<extend>>
Cliente
Solução utilizando extensão:
12
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>>
13
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.
14
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
15
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.
16
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.
17
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
(verificação de itens pendentes)
<<extend>>
Cliente
18
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.
19
Caso de uso Base
Caso de Uso Inclusão
<<include>>
20
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
21
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
22
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.
23
Solução utilizando inclusão:
Cliente
Solicita cancelamentode pedido
Valida pedido
Diminui quantidade de um item do pedido
<<include>>
<<include>>
24
Explicando o diagrama criado:
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>>
25
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
26
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.
27
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
28
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.
29
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
30
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 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.
31
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
Continua a partir do passo 2.
32
Solução utilizando generalização:
Cliente Faz pedido
Faz pedido para presentear
33
Explicando o diagrama criado:
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
34
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)
35
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 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.
36
Faz pedido para presentear
1. Cliente informa dados pessoais (cpf , nome,endereço, telefone e e-mail)
Cliente informa dados do presenteado:nome e endereço de entrega
Continua a partir do passo 2.
37
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
38
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
39
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.
40
Exemplo:
Poderíamos no caso exemplo, ter dois packages:Controle de pedidos e Controle de Livros
Controle de livros
Controle de pedidos
41
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
42Gerente
Funcionário
Solicita cancelamentode fatura
Paga fatura
Comunica atraso no pagamento
Avalia cancelamento de fatura
Fatura pedido
Diminui quantidade de um item do pedido
Solicita cancelamentode pedido
Cliente
Faz pedido
Casos de uso do package Controle de Pedidos
43
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
44
1. I dentifi car os atores
Exemplo - Sistema de controle de pedidos:
Cliente Funcionário Gerente
IV. ELABORANDO O DIAGRAMA
45
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
46
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
47
4. Criar para cada evento um caso de usocorrespondente, estabelecendo osrelacionamentos entre os casos de uso e osatores
48Gerente
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
49
5. Estabelecer, quando necessário, relacionamentosentre:
casos de uso atores
50Gerente
Funcionário
Comunica atraso
Valida pedido
Solicita cancelamento de fatura
Paga fatura
Comunica atrasono pagamento
Avalia cancelamento de fatura
Fatura pedido
(verificação de itens pendentes)
<<extend>> Diminui quantidade de um item do pedido
<<include>>
Solicita cancelamentode pedido
<<include>>
Faz pedido
Cliente
Faz pedido parapresentear
51
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
52
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.
53
Cenário alternativo: Venda realizada com sucesso por cliente já cadastrado 1.
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
Cliente atualiza seus dados Continua a partir do passo 2.
54
Cenário alternativo: Autorização de venda negada a um cliente já cadastrado 1.
Cliente informa seu código Código é validado 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.
55
7. Organizar os casos de uso em packages
8. Revisão do modelo
Controle de livros
Controle de pedidos
56
V. NOTAÇÕES ALTERNATIVAS
Associações
Atores
57
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
58
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
59
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
60
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
61
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
62
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.
63
Diagrama com as notações alternativas:
Gerente
Funcionário
Comunica atraso
Valida pedido
Solicita cancelamento de fatura
Paga fatura
Comunica atraso no pagamento
Avalia cancelamento de fatura
Fatura pedido
(verificação de itens pendentes)
<<extend>>Diminui quantidade de um item do
pedido
<<include>>
Solicita cancelamento de pedido<<include>>Faz pedido
Cliente
Faz pedido para presentear
64
Exercício:
Desenvolver o Diagrama de Casos de Uso Refatorado para o sistema de robôs da Petrobrás.
65
Exercício:
Desenvolver os cenários dos Casos de Uso para o sistema de robôs da Petrobrás.
66
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.