Use case

Diagramas da UML 2.0	editar
Diagramas estruturais Diagrama de classes Diagrama de objetos Diagrama de componentes Diagrama de instalação ou de implantação Diagrama de pacotes Diagrama de estrutura composta Diagrama de perfil
Diagramas comportamentais ou dinâmicos Diagrama de caso de uso Diagrama de transição de estados ou Máquina de estados Diagrama de atividade Diagramas de interação Diagrama de sequência Diagrama Visão Geral de Interação ou de interação Diagrama de colaboração ou comunicação Diagrama de tempo ou temporal

Na Engenharia de Software, um caso de uso (ou use case) é um tipo de classificador representando uma unidade funcional coerente provida pelo sistema, subsistema, ou classe manifestada por seqüências de mensagens intercambiáveis entre os sistemas e um ou mais atores. Pode ser representado por uma elipse contendo, internamente, o nome do caso de uso.

Os casos de uso foram propostos inicialmente por Ivar Jacobson em sua metodologia de desenvolvimento de sistemas orientados a objetos OOSE. Posteriormente foi incorporado à UML tornando seu uso uma prática frequente na identificação de requisitos de um sistema. Nesse contexto um caso de uso descreve um comportamento que o software a ser desenvolvido apresentará 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" da que o software ou uma de suas partes deverá oferecer.

É importante notar que os casos de uso não descrevem como o software deverá ser construído, e sim, como ele deverá se comportar.

A UML define um diagrama para representar graficamente os casos de uso e seus relacionamentos (Diagrama de Casos de Uso).

Os casos de uso normalmente evitam o uso de termos técnicos, preferindo a linguagem de programação do utilizador final. Normalmente os casos de uso são feitos quer por quem desenvolve o software quer pelos utilizadores que vão usar esse mesmo software.

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.

Á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.

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 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 FUNCIONPARIO" 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.

Diagramas de casos 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 para 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 do sistema mediante uma requisição do usuário.

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

Atríbutos obrigatórios:

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

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.

Benefícios dos Casos de Uso

Os casos de uso, são um formato novo e mais ágil para capturar requerimentos de software. Eles contrastam com documentos maiores e "monolíticos" que tentam, mas falham completamente em conter todos os requerimentos possíveis antes do ínicio da construção de um novo sistema. 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 utilizadores finais.

Problemas com os Casos de uso

O caso de uso também têm as suas dificuldades. São excelentes para capturar os requerimentos funcionais de um sistema, mas não têm tanto sucesso em capturar requerimentos não-funcionais.

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.