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.
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
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. */
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.
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.
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!