Diagramas de Casos de Uso - Casos de Uso

Frank Coelho de Alcantara -2020    

Objetivo

Transformar requisitos e requerimentos em uma ferramenta de suporte ao desenvolvimento do sistema.

Os casos de uso são ferramentas para as análises de negócio e sistemas.

Exemplo 1

Fonte:o autor (2020) Diagrama de caso de uso - exemplo

Exemplo 2

O jogador joga os dados e se sair o número 7 ele ganha o jogo.

  1. Ator: O jogador
  2. Caso de Uso: jogar os dados
  3. Condição: se der 7
  4. Resultado: ganhar o jogo

Modelo de documentação

  1. Nome: Frase Verbal.
  2. Código: UC_2020-08-25-0889
  3. Descrição: Um parágrafo.
  4. Fluxo para o sucesso: valor
  5. Fluxos extras: opções?
  6. Exceções: o que pode dar errado
  7. Prioridade: quando?
  8. Interface: quando?

Nunca esqueça!!!

Se não conseguir explicar em um parágrafo. Você ainda não entendeu o problema.

Sintaxe

diagrama com os símbolos da UML para casos de uso

Extensão e Inclusão

Extensão: diz respeito ao uso, ou não, de um caso de uso, por outros casos de uso. (as vezes!)

Inclusão: diz respeito ao uso de um caso de uso, por outros casos de uso. (sempre!)

Generalização

Um caso de uso, chamado de concreto, herda características de um casos de uso chamado de abstrato.

Muito Importante!

É uma sintaxe, precisa ser obedecida se você quiser ser entendido.

Relações múltiplas

Podem ocorrer relações múltiplas entre atores e casos de uso e entre casos de uso.

  • indefinidas: *
  • Nenhuma ou indefinidas: 0..
  • Nenhuma ou uma: 0..1.
  • Entre uma e cinco: 1..5
  • Exatamente três: 3

Classificação dos Casos de Uso

  • Sistema: interação direta com o sistema;
  • Contextuais: relações com outros sistemas;
  • Interno: interno ao sistema;
  • Sumário: conjunto de objetivos;
  • Abuso: coisas que não queremos.

Classificação dos Casos de Uso

Na prática: em um ambiente de práticas ágeis, partimos de um caso de uso do tipo sumário e detalhamos todos os seus casos de uso, para encontrar os que são de sistema, internos e contextuais. Depois analisamos os casos de uso do tipo abuso.

Casos de uso efetivos

Efetivo significa permanente, que tem caráter definitivo.

  • Precisão 0: definição do Escopo;
  • Precisão 1: ator primário e seu objetivo;
  • Precisão 2: principal caso de sucesso;
  • Precisão 3: extensões e inclusões
  • Precisão 4: alternativas e Exceções

Muito Importante!

Você vai repetir este processo para cada caso de uso do sistema.

Precisão 0: escopo

Análise do domínio do problema, definindo o objetivo geral do sistema, as características específicas do domínio do problema, e os principais stakeholders.

Precisa ser sucinto mas deve conter a ideia principal do sistema. Geralmente são as primeiras frases que o stakeholder usa para definir seu problema.

Precisão 0: escopo - exemplo

A empresa FraldasVerdes, uma fabricante de fraldas ecológicas precisa que todas as suas vendas sejam controladas pelo sistema FraldasVerdes Vende, um sistema de vendas ao consumidor final, online, móvel e acessível. Este sistema irá permitir que o usuário final da fralda ecológica entenda o processo de fabricação e possa fazer seus pedidos sem a necessidade de sair de casa.

Precisão 1: ator primário

Você vai responder a pergunta quem quer o quê? O ator primário de cada caso de uso deve ter sido explicitado na análise de requisitos.

Além do ator primário deste caso de uso, você precisa identificar o trigger, a ação que ele executa. E o valor que ele irá obter do sistema. No caso das FraldasVerdes, um dos atores primários é o cliente. Qual o trigger? Qual o valor?

Precisão 2: caso de sucesso

Precisaremos documentar o caminho para o sucesso deste caso de uso.

O sucesso ocorre quando a interação produz o valor desejado.

A documentação pode ser um passo-a-passo, mas precisa ser validada com stakeholders e desenvolvedores.

Precisão 3: alternativas e extensões

Hora de verificar os caminhos alternativos para o sucesso. Os caminhos alternativos para o fracasso.

Documentar as extensões e inclusões. Talvez repetindo todo o processo para cada novo caso de uso.

Extensão, inclusão e exceção. Todos estes casos estão na responsabilidade do analista.

Precisão 4: extensões e inclusões

Hora de detalhar a história que estamos contando destacando os casos de extensão e inclusão.

Você precisa responder a pergunta o que mais precisa acontecer para que isso dê certo?

É a hora de ver os casos de uso, com funcionalidades que você pode criar, ou utilizar. Também é a hora de pensar em falhas. Todo mundo falha, inclusive os sistemas.

Histórias de Usuário

Em práticas de desenvolvimento ágil, substituímos todo o digrama de casos de uso e análise de requisitos por Histórias de Usuário.

Histórias de Usuário são uma descrição sucinta, porém efetiva, de uma interação de um stakeholder com o sistema.

Histórias de Usuário - Problema

A análise de requisitos primeiro, e o diagramas de casos de uso depois, foram criados para permitir o entendimento e congelar os requisitos durante o desenvolvimento da solução.

As Histórias de Usuário fazem exatamente isso se existir colaboração entre equipe de desenvolvimento e stakeholders e se o tempo de desenvolvimento da funcionalidade for curto.

Histórias de Usuário

Em práticas de desenvolvimento ágil, substituímos todo o digrama de casos de uso e análise de requisitos por Histórias de Usuário.

Histórias de Usuário são uma descrição sucinta, porém efetiva, de uma interação de um stakeholder com o sistema.

Histórias de Usuário - Definição

Eu, como um <insira o ator>, quero <insira o objetivo> já que <insira a razão>.

Esta é a frase típica. Comece com ela, mas não fique restrito a ela. As histórias de usuário precisam ser simples, diretas, claras e, principalmente, completas.

Histórias de Usuário - Exemplos

  1. Eu, como um aluno, quero ver minhas notas já que preciso saber se fui aprovado.
  2. Eu, como um cliente, quero me autenticar no sistema já que gostaria de comprar fraldas.
  3. Eu,como um paciente do sus, eu quero receber alta do hospital, já que meu tratamento acabou.

Exercício Formativo 1

Resolva o Exercício Formativo 1.

Histórias de Usuário - Redação

Desconfie de histórias de usuários muito curtas. e muito longas.

A história de usuário deve conter uma descrição da interação com o sistema que permita o entendimento das características desta interação, dos recursos necessários e do tempo que será utilizado para a sua construção.

Histórias de Usuário - Redação

Em práticas ágeis, criamos histórias de usuários em fichas ou post-its.

Isso permite que, por exemplo, seja possível escrever as exceções no verso da ficha. Ordenar as fichas por prioridade e criar o backlog. Alterar as histórias a medida que o sistema fica pronto.

Lembre-se: em práticas ágeis, tudo pode, e deve, ser negociado.

Histórias de Usuário - Características

Independentes: cada história deve ser independente das outras histórias e da ordem em que serão construídas. As histórias dependentes de outras histórias, ou da ordem de construção adicionam níveis de complexidade desnecessários ao desenvolvimento de software.

Histórias de Usuário - Características

Negociáveis: as histórias não são contratos nem detalhamento de requisitos. Tanto a equipe de desenvolvimento quanto os stakeholders devem se envolver na definição da história. Ela não deve ser muito detalhada justamente para não criar a sensação de que todos os detalhes são conhecidos.

Histórias de Usuário - Características

Valorosas: as histórias devem agregar valor ao sistema que está sendo desenvolvido. Este valor deve ser percebido pela equipe de desenvolvimento e pelos stakeholders. Se a história não tiver um valor claro, será difícil determinar sua prioridade no backlog.

Histórias de Usuário - Características

Estimáveis: todas as histórias devem ser estimadas em termos de tempo e recursos necessários para a sua conclusão. Esta estimação precisa ser justa. Uma história muito grande é difícil de estimar, difícil de priorizar e irá causar problemas no desenvolvimento por quebra de expectativas.

Histórias de Usuário - Características

Tamanho apropriado: eventualmente as histórias precisarão ser divididas, ou reduzidas, para caber no tempo de desenvolvimento de uma determinada versão do software. Este é o momento em que serão negociados os requerimentos de cada história, a ordem de sua execução e a prioridade.

Histórias de Usuário - Características

Testáveis: todas as histórias devem permitir que tanto os desenvolvedores quanto os stakeholders sejam capazes de testar o resultado do processo de desenvolvimento e determinar se o valor esperado foi atingido.

Exemplo 1 - Máquina de Venda

Crie um diagrama de casos de uso para uma máquina automática de venda que vende apenas refrigerantes e salgadinhos. Esta máquina aceita um cartão e dinheiro em notas. Tente usar as associações de extensão, inclusão e generalização e lembre-se que esta máquina irá precisar de manutenção de tempos em tempos. Esta máquina é diferente das máquinas que vemos todos os dias. Os produtos não estão visíveis para o cliente. O cliente precisa escolher o produto em uma interface do sistema. Não existe manutenção preventiva.

Exemplo 1 - domínio

Detalhamento do domínio: a especificação do problema não apresenta nenhuma informação sobre a máquina estar, ou não conectada a um sistema central de controle. Por simplicidade vamos considerar que não. Então a máquina deve resolver todos os seus problemas de forma independente. A exceção será feita para o técnico, a máquina precisa sofrer manutenção, vamos considerar apenas manutenção corretiva..

Exemplo 1 - atores

A1_cliente: ator que irá comprar um dos produtos ofertados pela máquina o sucesso desta relação será determinado pela entrega do produto. É preciso considerar que a máquina pode dar defeito e, neste caso, o ator deve receber o dinheiro de volta e, em casos extremos, chamar o técnico.
A2_técnico: ator responsável pela manutenção. Este ator será responsável por recarregar a máquina e por concertar eventuais defeitos. Como no domínio determinamos que a existência de só e somente só manutenção corretiva, este ator não terá acionamentos temporais.

Exemplo 1 - casos de uso

UC_1: escolher o produto: o cliente escolhe o produto que pode ser um refrigerante ou um salgadinho e digita o código deste produto.
UC_2: pagar o produto: o cliente escolhe o meio de pagamento, dinheiro ou cartão e paga pelo produto.
UC_3: o cliente confirma a compra.
UC_4: receber o produto: o cliente recebe o produto e encerra a compra.

Exemplo 1 - casos de uso

UC_5: o cliente cancela a compra, antes de receber o produto, durante a confirmação, o cliente cancela a compra.
UC_6: o cliente não recebe o produto por um problema da máquina e chama o técnico.
UC_7: o técnico concerta a máquina. Sempre que for chamado por um cliente.
UC_8: o técnico recarrega a máquina.

Diagrama de Casos de Uso

diagrama com os símbolos da UML para casos de uso

Material de apoio

Você pode baixar o material de apoio clicando aqui

Obras Citadas

BAUSOLA, D. Activity Diagram. zeroinfluence, 2012. Disponível em: http:zeroinfluence.wordpress.com/uml. Acesso em: 04 Ago. 2020.
BECK, Kent et. Al. Manifesto para Desenvolvimento Ágil de Software. 2001. Disponível em: https://agilemanifesto.org/iso/ptbr/manifesto.html . Acesso em: 10 ago 2020.
BECK, Kent e ANDRES, Cynthia. Extreme Programming Explained. 2012.Boston, MA. USA. Addison Wesleyt. 2º Edição.
SOMMERVILLE, I. Engenharia de software. São Paulo, SP. Brasil: Pearson , 2012.
UNHELKAR, B. Software Engineering with UML. Boca Raton, FL. USA: Taylor & Francis Group, LLC, 2018.