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 o qual descreve a funcionalidade que irá 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.

Índice
[esconder]

 1Origem
 2Definição
 3Área do Caso de Uso
o 3.1Diagramas de casos de uso
 4Seções habituais nos Casos de Uso
 5Benefícios e Vantagens do Caso de Uso
 6Cenário principal
 7Cenários alternativos
 8Outras partes de um caso de uso
 9Conceitos
o 9.1Os atores
 10Atributos dos Casos de Uso
 11Vistas de uma arquitetura
 12Limitações
 13Referências
Origem[editar | editar código-fonte]
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[editar | editar código-fonte]

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