Caso de uso

Na Engenharia de Software, um caso de uso (do inglês use case) é um tipo de classificador representando uma unidade funcional coerente provida pelo sistema, subsistema, ou classe manifestada por sequências de mensagens intercambiáveis entre os sistemas e um ou mais atores.

Especificações de casos de uso são narrativas em texto, descrevendo a unidade funcional, e são amplamente utilizados para representar requisitos funcionais nos sistemas. Os diagramas de Casos de Uso são representações gráficas dos Casos de Uso e seus relacionamentos com outros casos de uso e atores. Neste diagrama um caso de uso é representado por uma elipse contendo, internamente, o nome do caso de uso e um ator é representado por um boneco palito. Opcionalmente o diagrama pode ter uma fronteira, que delimita o sistema, no qual os casos de usos estarão representados dentro da fronteira e os atores fora da mesma.^[1]

O apelo visual dessa ferramenta permite literalmente desenhar o processo de execução do negócio e visualizar a responsabilidade de cada participante, quando ele entrará em cena, qual será sua interação, a amplitude e a sequência em que o seu trabalho precisa ser realizado em relação às responsabilidades e tarefas dos demais integrantes do processo.^[2]

Um caso de uso representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema. Um caso de uso é uma unidade de um trabalho significante. Por exemplo: o "login para o sistema", "registrar no sistema" e "criar pedidos" são todos casos de uso. Cada caso de uso tem uma descrição da funcionalidade que será construída no sistema proposto. Um caso de uso pode "incluir" outra funcionalidade de caso de uso ou "estender" outro caso de uso com seu próprio comportamento.

Casos de uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho.

É importante notar que não descreve como o software deverá ser construído, mas sim como ele deverá se comportar quando estiver pronto. Um software frequentemente é um produto complexo, e sua descrição envolve a identificação e documentação de vários casos de uso, cada um deles descrevendo uma "fatia" do que o software ou uma de suas partes deverá oferecer.

Normalmente evitam o uso de termos técnicos, preferindo a linguagem do utilizador final, são empregados tanto por quem desenvolve o software quanto pelos utilizadores do software.

Origem

O processo de identificação de requisitos na engenharia de software tem uma função fundamental no correto desenvolvimento do projeto, pode-se no entanto facilmente tornar num processo extenso e trabalhoso.

Durante o desenvolvimento da área de Engenharia da computação iniciada em meados da década de 80, vários autores sugeriram diversas técnicas para um processo mais rápido e eficiente de levantamento e validação de requisitos de sistemas de software.

Uma das técnicas mais populares é a utilização de Casos de Uso para descrever claramente todos os requisitos de um dado sistema, esta técnica foi proposta por Ivar Jacobson em sua metodologia de desenvolvimento de sistemas orientados a objetos OOSE, visando identificar os requisitos de um sistema.

Foi aprimorada por várias outras personalidades do campo, como por exemplo, Alistair Cockburn.

Posteriormente foi incorporado à linguagem UML, que define um diagrama para representar graficamente os casos de uso e seus relacionamentos (Diagrama de caso de uso).

Definição

O foco deste artigo é a utilização de casos de uso na engenharia de requisitos. Cada um chamado caso de uso descreve um cenário de possível interação com um utilizador ou um outro sistema. Devem ser os mais claros possíveis para que todos os eventuais leitores de diferentes campos e backgrounds possam entendê-los de igual modo, devendo-se assim evitar termos técnicos ou obscuros que possam dificultar a compreensão inequívoca da funcionalidade descrita.

Cada caso de uso deve descrever somente uma funcionalidade ou objectivo do sistema. É então comum, para sistemas minimamente complexos, serem necessários muitos casos de uso para uma correta e completa descrição de todas as funcionalidades requeridas pelo sistema.

Os casos de uso devem ser identificados através de nomes curtos que identifiquem a sua actividade inequivocamente, para tal são usualmente utilizadas as formas verbais activas.

Para facilitar a visão geral do sistema é usual agregar casos de uso similares em pacotes e criar diagramas que ilustrem essa agregação e qual a iteração com outros sistemas ou utilizadores do sistema.

Os casos de uso nestes diagramas são usualmente representados por ovais com setas a indicar quais os utilizadores ou sistemas externos que interagem com eles.

A criação destes diagramas deve ser feita de uma maneira completamente fechada, ou seja, assumindo que o actor não tem conhecimento sobre o estado interno do sistema quando acessa uma dada funcionalidade, devendo as iterações ser descritas do ponto de vista externo. Esta forma de encarar a descrição de iteração simplifica a descrição dos requisitos e evita falsas assumpções sobre como a funcionalidade será implementada no sistema.

O procedimento mais seguido para a elaboração de diagramas de caso de uso, também habitualmente referidos como modelos de caso de uso, é o introduzido pelo UML. Embora sendo este o procedimento mais comum, é de notar que existem alternativas e que na prática o procedimento utilizado é o definido pelo manual de qualidade do projecto em curso que habitualmente deve ser previamente definido de acordo com as necessidades previstas do projecto, podendo vir a ser redefinido consoante alterações lógicas encontradas durante o processo.

O nível de detalhe da descrição do caso de uso dependerá sempre do nível de formalidade exigido pelo projecto e do estado actual de desenvolvimento. Em níveis iniciais pode-se assumir uma descrição mais breve e sucinta, em estados mais avançados será de esperar um maior detalhe e cuidado.

É de referir que um caso de uso bem elaborado não inclui somente um diagrama correcto e uma descrição clara. É habitual um caso de uso conter mais secções que ajudem na eficiência do processo de levantamento de requisitos, no próprio workflow de trabalho e na facilidade de imediata compreensão e rápida leitura do caso de uso por elementos estranhos à sua criação.

Também importante para garantir a usabilidade específica do caso de uso é o instrumento entre os diversos casos de uso do projecto. É imperativo elaborar casos de uso que tanto facilitem o acesso à vista global do sistema, como explicitem completamente todos os pormenores de todas as funcionalidades requisitadas.

Área do Caso de Uso

Cada caso de uso foca-se numa característica do sistema. Para a maioria dos projetos de software isto significa que múltiplos, talvez dezenas, de casos de uso são necessários para especificar completamente um novo sistema.

O grau de conformidade de um projeto de software em particular pode influenciar o nível de detalhe requerido em cada caso de uso. É geralmente aceito que cada caso de uso seja curto o suficiente para ser implementado por um desenvolvedor de software num lançamento.

A engenharia de requisitos consiste num processo onde são identificados todos os diferentes requisitos que um sistema de software deverá satisfazer quando se encontrar funcional. Este processo recorre a diferentes técnicas, algumas delas complementares entre si. O objetivo final é obter todos os requisitos idealizados para o sistema, possivelmente classificados por ordem de importância, descritos o mais claramente possível e devidamente validados pelos interessados ou stakeholders do sistema.

A clareza com que os requisitos são descritos e a sua abrangência que é idealizada pelos stakeholders é a máxima prioridade do processo tendo em vista não só a necessidade de transição do conhecimento dos requisitos do sistema tanto para os programadores que o irão implementar quanto para os utilizadores que dele farão uso, mas também para garantir que todo o conteúdo pretendido esteja identificado antes do processo de implementação começar, de modo a facilitar a arquitetura e planejamento de implementação da solução, evitando retrabalho.

Entre as várias técnicas auxiliares à tarefa de levantamento de requisitos, as mais reconhecidas e aconselhadas são:

• Identificação de stakeholders: Determinação clara de quem irá usar o sistema e de quem o projetou, discernindo quais os objetivos iniciais por trás da ideia, de modo a poder entender o que esperam que o sistema cumpra.
• Entrevistas com stakeholders do sistema: Consiste em efetuar entrevistas com os utilizadores e visionários do sistema tentando obter uma ideia das várias necessidades que o sistema deve satisfazer.
• Workshops de requisitos: Sessões de grupo com os utilizadores e visionários do sistema promovendo o debate e discussão de ideias sobre o sistema a desenvolver.
• Listagem contratual de requisitos: Consiste em elaborar uma listagem contendo todas as necessidades que o sistema deverá satisfazer.
• Prototipagem: Criação, apresentação e debate de modelos de interação não funcionais que ajudem a ilustrar como o sistema deverá se comportar, permitindo assim obter feedback mais detalhado dos stakeholders sobre o sistema.
• Diagrama de Caso de Uso: Descreve a funcionalidade proposta para o novo sistema.
• Expansão de Diagrama de Casos de uso: Consiste na explicitação de todas as diferentes funcionalidades do sistema, que permitirá inferir e identificar mais claramente outras necessidades.

Diagramas de casos de uso

Ver artigo principal: Diagrama de caso de uso

Muitas pessoas introduziram os casos de uso via UML, que define uma notação gráfica para representar os casos de uso. O UML não define padrões para o formato escrito objetivando descrever casos de uso, e assim muitas pessoas compreendem erroneamente que a notação gráfica define a natureza do caso de uso; contudo a notação gráfica pode dar a visão geral mais simples de um caso de uso ou de um conjunto destes casos.

O diagrama de casos de uso fornece um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível da funcionalidade.

Seções habituais nos Casos de Uso

Há alguns cuidados a ter para ter a certeza que um caso de uso está correctamente compreendido. Habitualmente é adoptado um standard que requer o preenchimento de alguns campos relativos ao caso de uso de modo a facilitar o trabalho em grupo e a clareza do relacionamento entre vários casos de uso, e do caso de uso em relação aos actores e ao próprio sistema.

Algumas das secções habitualmente utilizadas incluem:

• Nome: Identificador inequívoco do caso de uso, deve ser escrito em formato de verbo/substantivo e ser suficiente para o utilizador perceber a que se refere o caso de uso.
• Iteração ou estado de desenvolvimento: Descrição do estado actual do caso de uso à medida que este vai evoluindo.
• Sumário: Curto resumo do caso de uso.
• Pré-condições: Listagem das condições que se devem verificar quando o utilizador inicia este caso de uso. Não incluem triggers.
• Triggers: Eventos que ocorrem dando início ao caso de uso. Podem ser externos, temporais ou internos.
• Linha de Eventos: Esta secção descreve o curso de eventos ou cenário que se realiza. Usualmente é descrito através de uma sequência de eventos numerados.
• Percursos Alternativos: Descrição de percursos alternativos à linha de eventos básica.
• Pós-condições: Descrição do estado do sistema após a execução do caso de uso
• Regras de negócio: Secção reservada para informação adicional relativa à política da empresa ou restrições impostas pelo tipo de negócio.
• Notas: Informação adicional relativamente ao caso de uso, não coberta pelas secções anteriores.
• Autor e data: Listagem dos autores e datas das várias versões revistas.

Benefícios e Vantagens do Caso de Uso

A utilização de casos de uso é uma técnica relativamente recente, mais flexível, apoiada num formato novo e mais ágil para capturar requisitos de software que contrasta com a documentação extensiva e "monolítica" que tenta, mas falha em registrar todos os requisitos possíveis de um sistema antes deste começar a ser construído.

Os casos de uso podem ser facilmente adicionados e removidos do projeto de software assim que as prioridades mudam. Os casos de uso podem também servir como base para estimar, escalonar e validar esforços. Uma razão porque os casos de uso se tornaram populares é que são fáceis de entender por pessoas da área de negócio, e assim provaram ser uma excelente ponte entre quem desenvolve o software e os usuários finais. Entre as vantagens da utilização no processo de engenharia de requisitos incluem-se:

• A modelagem de um caso de uso (incluindo a sua especificação) é geralmente aceita como uma excelente técnica para a captura dos requisitos funcionais de um sistema.
• Desencorajam o design prematuro.
• Podem ser usados a base para o esforço de estimação, planeamento e validação.
• São reutilizáveis dentro de um projecto. O caso de uso pode evoluir com cada interação, desde um método de levantamento de requisitos, para linhas gerais de desenvolvimento aos programadores, de um caso de teste, até a documentação.
• Caminhos alternativos de um caso de uso registram comportamentos adicionais que podem melhorar a robustez do sistema.
• São úteis para sondar o verdadeiro âmbito do sistema. Podem ser facilmente adicionados ou removidos consoante a mudança de prioridades no desenvolvimento do projecto do sistema.
• São facilmente entendidos por todos os tipos de utilizadores, criando uma ponte entre os que desenvolvem o software e os stakeholders do sistema.
• As especificações de um caso de uso não requerem a utilização de uma dada linguagem, podem ser escritas nos mais diversos estilos para encaixar com as necessidades do projecto.
• Permite descrever um requisito como se contasse uma história. Torna-se mais fácil descrever requisitos sob a forma de uma história ou cenário.
• Estão ligados directamente com a interação do sistema, isto permite aos designers da interface um maior envolvimento no processo de desenvolvimento do projecto quer antes ou em paralelo com os programadores de software.
• Colocam os requisitos em contexto, são claramente descritos em relação às tarefas do negócio.
• Os diagramas de caso de uso ajudam os stake holders a entender a natureza e escopo da área de negócio ou sistema em desenvolvimento.
• Diagramas de caso de uso podem ser gravados usando a notação UML e mantidos usando diferentes ferramentas CASE.
• Casos de uso e diagramas de caso de uso podem ser completamente integrados com outras deliverables de análise e design criadas usando uma ferramenta CASE para produzir requisitos, design e repositório de implementação mais completos.

Cenário principal

No mínimo, cada caso de uso deveria ter um "cenário principal", ou o curso típico de eventos. O cenário principal é normalmente um conjunto de passos, por exemplo:

• O sistema pede para o usuário se identificar.
• O usuário digita o seu nome e palavra-chave.
• O sistema verifica a informação de identificação.

O caso de uso representa uma atividade genérica que define um escopo (limite) de uma declaração de problema (texto que explica o que o sistema necessita). Exemplo: pagar faturas.

Cenários alternativos

Os casos de uso podem conter cenários alternativos ou secundários que contêm variações do tema principal. Exceções, ou o que acontece quando as coisas não correm bem, podem também ser descritas.

Outras partes de um caso de uso

Há também outros formatos, ou templates para documentos de casos de uso. Normalmente, os casos de uso têm uma secção de "sumário" que pode ser escrita preliminarmente durante o projeto de software para capturar a essência do cenário antes do corpo principal estar completo. Uma secção de "precondições" pode ser usada para conter as condições iniciais que foram assumidas antes do cenário ter começado.

Conceitos

• Ator: Agente externo (uma pessoa ou um sistema) que interage com o sistema, dividindo-se em primário que interage diretamente e secundário que somente faz um serviço.
• Interação: Comunicação dos atores com o sistema.
• Associação entre casos de uso:
  • Inclusão (Include): Um caso de uso pode ser aproveitado no contexto de outros casos de uso. Exemplo: "calcular o DV do CNPJ" é um comportamento que pode ser utilizado como mecanismo para validar a inclusão de um objeto cliente ("cadastrar cliente"), como pode ser utilizado para validar a inclusão de um objeto fornecedor ("cadastrar fornecedor"). Compartilhamento de uma ação por outras ações (reutilização).
  • Extensão (Extend): Um caso de uso pode ter seu comportamento requerido por outro caso de uso (e somente por este outro caso de uso). Dois motivos para a utilização do Extend: melhorar a estabilidade do modelo (i.e. redução do impacto de eventuais mudanças de comportamento) e diminuir a complexidade das operações (i.e. isolar os elementos que apresentem comportamentos mais complexos). Exemplo: "cadastrar funcionário" requer a chamada de uma operação para "cadastrar dependente do funcionário". O comportamento de "cadastrar dependente do funcionário" servirá apenas aos propósitos de "cadastrar funcionário" (i.e. não será compartilhado com outras ações). Modularização. Menor acoplamento e maior coesão.

Os atores

Ator é algo que interage com o sistema, mas sobre o qual não se tem controle. Ele está fora da influência do sistema. Os atores têm um papel externo e são quem iniciam (e quem respondem) aos casos de uso. Por exemplo: fazem o pedido num restaurante, comem, bebem ou pagam.

Tipicamente, um ator representa um papel que um ser humano, um outro processo, um outro sistema, ou até um dispositivo de hardware, desempenha ao interagir com o sistema.

Cada ator corresponde a um papel específico: uma mesma pessoa que desempenha diferentes papéis nas interações com o sistema é representada por diferentes atores; por outro lado, diversas pessoas que desempenham o mesmo papel correspondem a um único ator.

São eles quem:

• Utilizam o sistema.
• Inicializam o sistema.
• Fornecem os dados.
• Usam as informações do sistema.

Atributos dos Casos de Uso

Atributos obrigatórios:

• Nome
• Atores
• Objetivo
• Fluxo de eventos (cenário principal)
• Atitudes

Além destes atributos ainda podemos definir: prioridade, estado, pré-condições, pontos de extensão, identificador único, casos de uso usados, diagrama de atividade, diagrama de sequência, casos de uso subordinados, diagrama de colaboração e outros requerimentos.

Vistas de uma arquitetura

A arquitetura de Software é algo unidimensional, feito por diversas vistas concorrentes:

• Vista do Caso de Uso: O sistema tem conjuntos de transações do ponto de vista de atores externos. Esta vista é criada no início e direciona o resto do processo.
• Vista Lógica: coleção de pacotes, classes e relações.
• Vista do processo: processos, threads, comunicação entre processos e mecanismos de sincronização.
• Vista de implementação: módulos e subsistemas.
• Vista de distribuição: nódos físicos no sistema e ligações entre os nódos.

Limitações

Os casos de uso são excelentes para capturar os requisitos funcionais de um sistema; entretanto, têm as seguintes limitações:

• Não é adequado para o levantamento dos requisitos não funcionais de um sistema.
• O facto de utilizar um template de caso de uso não assegura clareza, esta dependerá sempre de quem elabora o caso de uso.
• A sua correcta interpretação requer sempre um processo de aprendizagem e ambientação, por parte quer dos utilizadores, quer dos programadores.
• Utilizadores do sistema Extreme Programming por vezes consideram os casos de uso demasiado centrados na documentação, preferindo antes seguir descrições de uma utilização.

Ligações externas

• «Entendendo o que é um diagrama de caso de uso»
• O que são requisitos de software?

Referências

1. Vazquez, Carlos; Simões, Guilherme (2016). Engenharia de Requisitos: Software Orientado ao Negócio. [S.l.]: Brasport
2. Carlos Alberto Debastiani (2015). Definindo Escopo em Projetos de Software. São Paulo: Novatec. ISBN 978-85-7522-429-8