Não. Caso de uso possui informações com uma abordagem mais próxima do cliente e o diagrama de sequência nem tanto. Um mesmo caso de uso pode ter vários de sequência para documentar os processos.
Breve Descrição:
Cliente solicita uma ou mais pizzas do tipo “meio à meio” e indica quais os dois sabores que deseja. Ator(es) Primário(s):
Atendente e Cliente da Pizzaria Pré-condições:
O cliente informa que deseja uma pizza do tipo meio à meio e seleciona de acordo com o cardápio os dois sabores que deseja. Fluxo Principal:
1.O cliente informa os sabores da pizza que deseja[EV].
2.Atendente registra o pedido e seleciona os sabores escolhidos[EV].
3.Sistema retorna o valor da pizza de acordo com o sabor de maior valor[RS].
4.Atendente informa ao cliente o valor da pizza. Fluxos Alternativos e Exceções:
Pós-condições: (Sucesso) O pedido do cliente é registrado com sucesso e o atendente confirma o pedido e informa o valor da(s) pizza(s) e a estimativa de tempo para o preparo e ou a entrega.
(Falha) O pedido não foi registrado. Requisitos funcionais satisfeitos:
R.F.10 Requisitos não funcionais
R.N.F.10.01.
R.N.F.10.02.
Você está tentando representar um processo de negócio (cliente pedindo pizza) com casos de uso. Isto não vai dar muito certo. Utilize os casos de uso apenas para mapear o atendente interagindo com o sistema. A interação entre cliente e atendente não deve ser representado em casos de uso.
Exato! Complementando o que eu havia falado anteriormente, o único Caso de Uso desse cenário seria o “Registrar pedido” e o Ator seria o “Atendente” e não o cliente.
Outra dica: um caso de uso (uma elipse) deve representar uma “funcionalidade” mais abrangente (o seu “Registrar pedido”). Os outros não se parecem com casos de uso, mas os passos do seu caso de uso (escolher o sabor, escolher a forma de pagamento, etc).
O diagrama de caso de uso é só isto. Agora você tem que escrever o caso de uso em si (o fluxo principal, de exceção, alternativos), lembrando que você não deve considerar o cliente um ator do sistema. Restrinja a interação entre o atendente e o sistema.
Não existe certo ou errado neste contexto. A UML é uma linguagem que você usa de acordo com as suas necessidades. A sua metodologia/processo/empresa/professor que deve dizer se está completo ou não. Se o requisito é “pedir pizza meio-a-meio”, você pode escrever o caso de uso “Registrar pedido de pizza meio-a-meio”, ao invés de escrever o caso de uso “Registrar pedido”.