Entendendo definitivamente o que é um Caso de Uso

Compartilhe!

O que seria um “caso de polícia”? Seria uma estória que descreveria uma cena policial, um crime ou investigação, por exemplo.

O que seria um “caso de novela”? Seria uma estória que descreveria uma trama, por exemplo, que se passa numa novela. Quando alguém quer contar alguma coisa a alguém, nos detalhes necessários, é comum dizer: “vou lhe contar um caso”.

O que é Caso de Uso? Vai na mesma linha. Tem como objetivo “contar a alguém”, descrever como será o uso de uma funcionalidade de um sistema.

A diferença é que, para contar este caso, existe um padrão para fazê-lo, um conjunto de regrinhas que serve para padronizar o “conto”, de maneira que o leitor da “estória que está sendo contada” – que poderá ser o programador do sistema que utilizará o caso de uso para codificar a funcionalidade ou o usuário que utilizará o caso de uso para validar a funcionalidade ou outro profissional – entenda a funcionalidade de uma maneira única, seguindo um padrão específico.

No campo da engenharia de software é muito comum esbarrarmos em conceitos que possuem nomes pouco sugestivos, muitas vezes enigmáticos.

/* Engenheiros geralmente tem dificuldade em comunicar-se adequadamente, tendem a supor inconscientemente que os outros pensarão como ele pensa. Então, inconscientemente, definem coisas de maneira que eles entendem, mas que não necessariamente outros entenderão. Se o caso de uso chamasse “especificação do comportamento da funcionalidade” seria mais sugestivo, talvez. */

Contextualizando o Caso de Uso na UML

A UML (Unified Modeling Language ou “Linguagem de Modelagem Unificada”) possui uma séria de diagramas – cada um com uma finalidade específica com suas respectivas regras, premissas e restrições – que podem ser utilizados na especificação de sistemas (tanto sistemas de software quanto em sistemas de hardware, por exemplo).

Estes diagramas são divididos em dois grandes grupos: diagramas estruturais e diagramas comportamentais.

O que é Caso de Uso - Estrutura geral da UML

Os diagramas estruturais são utilizados para se especificar a estrutura do sistema, a parte estática.

Exemplo é o Diagrama de Classe (representa a estrutura das classes do sistema), Diagrama de Componentes (representa uma abstração dos componentes do sistema) ou Diagrama de Pacotes (que mostra os pedaços maiores do sistema – muito utilizado com diagrama de componentes, que mostra pedaços menores).

Os diagramas comportamentais são utilizados para especificar o comportamento do sistema, a parte dinâmica do sistema. Exemplo é o Diagrama de Sequência, que demonstra como algum pedaço do sistema mais dinâmico (ou algorítimo ou uma funcionalidade, por exemplo) se comportará num contexto específico, Diagrama de Caso de Uso (demonstra como uma funcionalidade é utilizada, como ela se comportará diante de eventos, inputs, exceções etc.).

O Diagrama de Caso de Uso na UML é um diagrama comportamental. Mas quando o assunto é caso de uso, o diagrama é só uma parte da solução. O principal mesmo nem é o diagrama (parte gráfica), mas sim a especificação do caso de uso (o que tem “dentro de cada bolinha”), a descrição dos seus cenários.

UML e Agilidade

desenvolvimento-de-software-agil

Agilidade não é produzir software com pressa, é produzir software com velocidade, entregando valor no menor espaço de tempo possível, e melhorando isso continuamente.

Para ser ágil, é fundamental ser eficiente.

Não é plausível falar em agilidade sem eficiência, com desperdício.

Em projetos de software, um dos maiores desafios é a boa comunicação.

Deixar claro o que se quer, o que será entregue, como será produzido etc. Isso não é simples quando produzimos software, devido à complexidade inerente a esta atividade.

Quando se entende um requisito do jeito errado, sempre há o custo de fazer errado, desfazer, e fazer certo. Obviamente, este tipo de desperdício custa 3 vezes mais que se tivéssemos feito certo da primeira vez.

E neste contexto, fica claro que o uso racional de diagramas UML com o objetivo de transmitir ideias entre membros de um mesmo time, é uma ferramenta que favorece muito uma cultura ágil.

Objetivo

O Diagrama de Caso de Uso serve para representar como os casos de uso interagem entre si no sistema e com os usuários (atores), ou seja, como as funcionalidades se relacionarão umas com as outras e como serão utilizadas pelo usuário, durante o uso do sistema.

/* “durante o uso do sistema”; percebeu a ideia de ação no tempo? Ler um diagrama de caso de uso é imaginar o sistema em utilização pelo usuário final. Por isso é um diagrama “comportamental”, pois define como será o comportamento de funcionalidades do sistema, e comportamento apenas ocorre quando o sistema está em utilização. */

No diagrama de caso de uso, basicamente temos três principais elementos: Ator, Caso de Uso, e Relacionamento.

/* Na UML as formas gráficas utilizadas são chamadas de elementos. Diagramas são compostos de elementos, que possuem significado (e conteúdo, em alguns casos). Ou seja, um diagrama contém elementos, que possuem significados e podem conter ou não especificação “dentro deles”, e podem ou não se relacionar entre si. */

O que é Caso de Uso - Diagrama de Caso de Uso

No diagrama acima temos os três elementos que citamos:

1 – Ator (o bonequinho)

2 – Casos de uso (as bolinhas, na realidade o nome técnico é elipse, pois possuem este formato)

3 – Relacionamentos (as setas que ligam os casos de uso entre si e ligam os usuários aos casos de uso).

Ator

Um ator é quem fará a execução do caso de uso (quem executará a funcionalidade que está especificada no caso de uso). Atores podem ser de dois tipos: humano e sistêmico.

Um ator humano é uma pessoa física, que no diagrama deve possuir como nome o papel que a pessoa executa no contexto empresarial onde o sistema será utilizado. Por exemplo: Cliente, Fornecedor, Atendente.

/* Nunca nomeie um ator humano de “usuário”, o que é muito comum. Isso não quer dizer nada, obviamente que um ator pessoa física é um usuário do sistema. O nome do ator deve gerar valor no diagrama (melhorar o entendimento do contexto, do modelo, da especificação), então tem que refletir o papel que o usuário tem na realidade empresarial onde o sistema será utilizado. */

Um ator sistêmico é um sistema, ou módulo de um sistema, ou componente de um sistema, que realizará a execução da funcionalidade que está especificada pelo caso de uso. No diagrama deve possuir seu nome de fato (se o ator é o sistema “Disparador de rotinas batch” por exemplo, este deve ser o nome do ator sistêmico).

/* Da mesma forma que para o ator humano, nunca nomeie um ator sistêmico de “sistema”, o que é muito comum. Também não quer dizer nada, obviamente que um ator sistêmico é um sistema. A boa prática é dar o nome do sistema que de fato fará a execução da funcionalidade que o caso de uso está representando. */

O relacionamento mais comum de um ator para com um caso de uso é o <<use>>, o que significa que o ator usa o caso de uso (executa a funcionalidade especificada no caso de uso).

Relacionamentos

Casos de uso relacionam entre si (isso não é obrigatório, podemos ter casos de uso que não são chamados por outros, nem chamam outros casos de uso).

Imaginemos por exemplo uma funcionalidade de “Manutenção de Cadastro de Cliente”, que permite alterar dados de um cliente já cadastrado no sistema.

Esta funcionalidade pode utilizar uma outra funcionalidade de “Seleção de Cliente” para filtrar e selecionar o cliente cadastrado que terá seus dados alterados. Neste caso há relacionamento entre os casos de uso de ambas as funcionalidades.

Na especificação da UML são definidos alguns tipos de relacionamento para casos de uso, mas os três principais relacionamentos são: Inclusão (Include), Extensão (Extends) e Herança (Generalization).

Para entender melhor o que são estes relacionamentos e qual o propósito e diferença entre cada um dos três veja Caso de Uso – Include, Extend e Generalização.

Cenários do Caso de Uso

Um caso de uso, como elemento num diagrama, é a elipse (ou bolinha) que vimos na figura anterior. O que tem “dentro da bolinha” são fluxos (ou cenários). Os fluxos compõe a especificação do caso de uso, “o que tem dentro da bolinha”. A seguir um exemplo.

O que é Caso de Uso - Fluxo Principal

Na especificação de um caso de uso, de relevante temos os fluxos (Principal, Alternativo e Exceção). Cada fluxo possui uma série de passos (steps), e uma lógica sequencial que demonstra, passo a passo, como o fluxo é executado.

Para entender melhor o que é o Fluxo Principal veja Caso de Uso – Fluxo Principal.

Para entender melhor o que é o Fluxo Alternativo veja Caso de Uso – Fluxo Alternativo.

Para entender melhor o que é o Fluxo de Exceção veja Caso de Uso – Fluxo de Exceção.

Caso queira ficar expert em Casos de Uso aproveite nosso curso “Casos de Uso na Real”, um curso super diferenciado voltado à prática da modelagem, com o melhor da teoria!

curso-casos-de-uso-desconto-100-reais-vagas

Concluindo

É fundamental entendermos para que serve um Caso de Uso, se vamos utilizá-lo em nosso trabalho.

Um Caso de Uso é uma das várias formas que temos para especificar as funcionalidades de um software. Esta especificação tem como objetivo principal servir de insumo para um projetista ou programador, para o projeto/codificação da funcionalidade.

Mas ainda tem outras finalidades secundárias, onde podemos destacar: servir de documento para validação de especificação por parte do usuário final, servir de documento para metrificação e posterior dimensionamento de esforço/prazo/custo, servir para um analista de teste, com base nos fluxos do Caso de Uso, escrever os cenários de um Caso de Teste, e naturalmente, servir de documentação para entendimento do sistema.

Grande abraço!

caso de uso

  • Pingback: Caso de Uso – Fluxo Principal | Até o Momento – Muito conteúdo de qualidade sobre Engenharia de Software()

  • Pingback: Caso de Uso – Fluxo Alternativo | Até o Momento – Muito conteúdo de qualidade sobre Engenharia de Software()

  • Pingback: Caso de Uso – Fluxo de Exceção | Até o Momento – Muito conteúdo de qualidade sobre Engenharia de Software()

  • Pingback: O que é Requisito Funcional | Até o Momento – Muito conteúdo de qualidade sobre Engenharia de Software()

  • Pingback: Sintaxe e Semântica – Forma e conteúdo na produção de software | Até o Momento – Muito conteúdo de qualidade sobre Engenharia de Software()

  • Thiago Oliveira

    Olá, parabéns pelo conteúdo presente em seu site! Qual a ferramenta CASE que é utilizada no tópico Cenários do Caso de Uso?

    • Plínio Ventura

      Como vai, Thiago!

      Que bom que o conteúdo foi útil para você. A ferramenta que utilizamos é o Enterprise Architect, da Sparx Systems (http://www.sparxsystems.com/products/ea/).

      Obs.: em Janeiro/2017 vamos lançar um super curso de Modelagem de Casos de Uso, fique ligado! 🙂

      Abraço!

  • Carlos T.

    Plínio, uma dúvida:

    O que cada Caso de Uso, ou seja, cada uma das elípses, representa? Uma funcionalidade ou um requisito funcional?
    Para um projeto começando do zero, qual seria a ordem? Primeiro eu identifico uma Funcionalidade, os Requisitos Funcionais que a compõem, depois as Regras de Negócio em cada um desses Requisitos Funcionais, transformo cada um dos Requisitos Funcionais em um Caso de Uso e com tudo isso em mãos eu descrevo os fluxos Principal, Alternativo(s) e de Exceção de cada um desses Casos?

    • Plínio Ventura

      Oi Carlos, tudo bem?

      Pertinente demais sua pergunta! Muita gente tem essa duvida e muita gente a ignora, e produz modelos impossíveis de manter depois, devido aos terríveis problemas semânticos gerados por esta confusão.

      Um Caso de Uso representa uma Funcionalidade. Uma Funcionalidade realiza um ou mais Requisitos Funcionais, e cada um destes Requisitos Funcionais podem ter dependências com uma ou mais Regras de Negócio.

      Depois dá uma olhada no meu canal do Youtube, tem alguns vídeos que podem lhe ajudar neste sentido: https://www.youtube.com/c/plinioventura

      Qualquer dúvida estamos aí!

      Abraço!

      • Plínio Ventura

        Carlos, esqueci da seguida parte da sua pergunta, rs.

        O começo sempre é pelo mais macro, e depois ao mais micro. E também, primeiro o conceito do software, depois seu lado funcional.

        Então, comece pensando exclusivamente no negócio, e a partir daí, separe em módulos, depois, identifique funcionalidades, depois faça a engenharia dos requisitos, e depois, os casos de uso. Em tempo de modelagem de requisitos as funcionalidades são apenas identificadas, e amarradas aos requisitos. Em tempo de modelagem de casos de uso é que o comportamento destas funcionalidades é definido, através da descrição dos cenários dos casos de uso.

        Depois dê uma olhada no nosso curso: http://www.indtech.com.br/lpCursoEngenhariaRequisitosListaPreLancamento.aspx

        Explicamos bem este processo citado, pode lhe ser útil.

        Abraço!

  • Pingback: Diagrama de Atividades - UML()

  • Pingback: Engenharia de Software - Perguntas e Respostas()

  • Adriana Silva

    Boa tarde,
    Pode me esclarecer essa dúvida? dentre os campos de um cadastro há uma lista, onde é possível inserir, excluir e alterar itens da lista. Como trato esta lista? já vi detalhamento de caso uso, onde a lista é outro caso de uso de inclusão. Eu poderia descrevê-la como um subfluxo, com o objetivo de manter o fluxo básico organizado. O que é o mais indicado ou o correto? Desde já agredeço imensamente a atenção.

    • Plínio Ventura

      Olá Adriana, boa noite!

      Se a função de edição de lista NÃO FOR algo contido em outras funcionalidades do sistema, então:

      Se a edição dos dados desta lista for algo que “sempre” será executado pelo usuário quando no acesso à funcionalidade, então tem que ficar no Fluxo Principal. Se assim for, basta incluir alguns passos no Fluxo Principal, destacando a particularidade da execução deste “pedaço” do fluxo. Você pode ver um exemplo em: https://www.ateomomento.com.br/estrutura-de-repeticao-em-caso-de-uso-como-representar-loop/

      Se a edição dos dados desta lista for algo que “nem sempre” será executado pelo usuário quando no acesso à funcionalidade, então tem que ficar em algum Fluxo Alternativo. Assim sendo, basta especificar o comportamento em um Fluxo Alternativo, e referenciá-lo no passo (step) pertinente no Fluxo Principal.

      Se a função de edição de lista FOR algo contido em outras funcionalidades do sistema, então:

      Para viabilizar reuso, coesão dos casos de uso e qualidade no modelo, é necessário “encapsular” toda a lógica pertinente em um caso de uso específico e referenciá-lo quando necessário, através de chamadas oriundas dos casos de uso que usam o recurso da lista.

      Abraço!

  • henrique mello dos santos

    que texto bom, parabéns ao criador, muito bem explicado.

    • Plínio Ventura

      Olá Henrique, com vai?

      Que bom que o conteúdo lhe foi útil, obrigado pela visita!

      Abraço!