Caso de uso – Wikipédia, a enciclopédia livre

Prévia do material em texto

Caso de uso
Origem: Wikipédia, a enciclopédia livre.
(Redirecionado de Casos 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.
Casos de uso são narrativas em texto, descrevendo a unidade funcional, e são amplamente utilizados para
descobrir e registrar requisitos de sistemas. Os diagramas de Casos de Uso são representações dos Casos de
Uso e podem ser representados por uma elipse contendo, internamente, o nome do caso de uso.
Um caso de uso representa uma unidade discreta da interacçã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
1 Origem
2 Definição
3 Área do Caso de Uso
3.1 Diagramas de casos de uso
4 Secções habituais nos Caso de Uso
5 Benefícios e Vantagens do Caso de Uso
6 Cenário principal
7 Cenários alternativos
8 Outras partes de um caso de uso
9 Conceitos
9.1 Os atores
10 Atributos dos Casos de Uso
11 Vistas de uma arquitetura
12 Limitações
13 Ligações externas
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 iteração com um utilizador ou um outro sistema. Devem ser o 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 inequivoca
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 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 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 aceite 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 objectivo 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 stakeholder é 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çãoda 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 objectivos iniciais por detrá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 interacçã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
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 do sistema mediante uma requisição
do usuário.
Secções habituais nos Caso 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 inequivoco 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 à politica 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 apoiado 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
escritos nos mais diversos estilos para encaixar com as necessidades do projecto.
Permite descrever um requisito como se contasse uma história. Torna-se mais facil 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 stakeholders 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 criados 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)
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, tem as
seguintes limitações:
Não facilitam muito o levantamento dos requisitos não funcionais do 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
Curso online sobre Casos de uso (http://www.aspercom.com.br)
Obtida de "http://pt.wikipedia.org/w/index.php?title=Caso_de_uso&oldid=32592978"
Categorias: Diagramas da UML Engenharia de Requisitos Engenharia de software
Esta página foi modificada pela última vez à(s) 21h56min de 14 de outubro de 2012.
Este texto é disponibilizado nos termos da licença Atribuição-Partilha nos Mesmos Termos 3.0 não
Adaptada (CC BY-SA 3.0); pode estar sujeito a condições adicionais. Consulte as condições de uso
para mais detalhes.