Home
Ter
02
Set

Anatomia de um Caso de Uso - Parte 1

Atenção, abrir em uma nova janela. PDFImprimirE-mail

Introdução

 

Os principais aspectos por trás do conceito de casos de uso já foram mostrados no nosso artigo anterior, que pode ser lido aqui.

 

A partir deste artigo, trataremos das características relevantes na composição de um caso de uso.

 

 

Um formato para Casos de Uso

 

Se alguém me perguntasse por um formato para escrever casos de uso eu responderia que não existe um único formato.

 

Em nossa área, estamos acostumados a ter “templates” para tudo, mas um caso de uso não pode ser circunscrito em um “template” simplesmente porque não é um documento estático.

 

Não existe um único e mesmo conjunto de informações pré-determinadas que sempre precisem constar de todos os casos de uso. O que existem, são informações que são mais ou menos desejáveis, dependendo da transação que o caso de uso descreve; da sua importância no contexto geral ou mesmo do estágio em que nos encontramos no processo de desenvolvimento do software.

 

Redigir um caso de uso é sempre um processo incremental. A cada nova análise, novos detalhes podem ser descobertos e acrescentados, isso se a própria transação de negócio que estiver sendo descrita não sofrer alterações durante o processo. A filosofia de casos de uso não só absorve esta realidade como tira proveito dela, durante sua elaboração.

 

Com esse espírito é que tentarei analisar a Anatomia de um Caso de Uso.

 

 

O nome do caso de uso

 

Todo caso de uso precisa ter um nome. Ao passo que um caso de uso, necessariamente, corresponde a uma e apenas uma transação de negócio, esta informação é descrita no próprio nome do caso de uso, que deve ser composto como uma sentença curta (o mais curta possível), que utilize um verbo de ação e explique a transação a que ele se refere.

 

Exemplo: Considere que estamos em um projeto para automatizar o setor de serviços a clientes de seguros de automóveis.

 

Um serviço muito comum é a seguradora disponibilizar um reboque para retirar um veículo de um cliente com defeito ou batido. Imagine como seria o nome do caso de uso que descreva a transação em que um cliente tem por objetivo, fazer uso deste serviço:

 

Verbo de Ação: Requisitar

Nome do Caso de Uso: Requisitar Reboque.

 

 

O ator principal do caso de uso

 

Entendemos por atores os nomes dos PAPÉIS funcionais das pessoas ou outros sistemas que interagem no Caso de Uso. Quais seriam em nosso exemplo:

 

- As pessoas para as quais este serviço foi pensado, do ponto de vista do negócio de seguros, são identificadas como “segurados”. Normalmente são as pessoas cujo veículo é protegido pelo seguro e necessita do reboque. Assim temos um ator: Segurado.

 

- Entretanto, ao fazer a requisição, esta é recebida por algum preposto da seguradora, que é responsável por validar a requisição e acionar o serviço de reboque. Normalmente as seguradoras disponibilizam centrais de atendimento telefônico para este fim. Assim temos um segundo ator, que é o operador da central de atendimento.

 

- Temos, naturalmente, outro ator, que é representado pelo próprio serviço de reboque.

 

Dos três atores o “operador da central de atendimento” é aquele que será o usuário direto da função de sistema a ser implementada. Entretanto, o conceito de ator primário determina que este seja aquele cujo objetivo é atendido pela transação descrita pelo caso de uso. Este, no nosso exemplo, é o segurado, pois é ele quem deseja ser atendido pelo reboque, e viabilizar este atendimento é o objetivo do caso de uso.

 


Resumo do Caso de Uso

 

Num primeiro momento, a partir das primeiras conversas a respeito do projeto, você será capaz de obter pelo menos os resumos da maioria dos casos de uso principais.

 

O resumo descreve de forma sucinta o comportamento esperado na maioria das vezes em que o caso de uso for utilizado.

 

No nosso exemplo, poderíamos ter algo como abaixo:

 

Caso de Uso:

Requisitar Reboque

 

Ator Primário:

Segurado

 

Resumo:

Segurado liga para a central telefônica, identifica-se confirmando informações sobre a apólice, informa o endereço onde se encontra o veículo e recebe a estimativa para chegada do veículo.

 

 

Os resumos oferecem uma boa visão do escopo do caso de uso.

 

 

Cenário Principal de Sucesso

 

 

Se soubermos de antemão que este caso de uso é bem relevante para nosso projeto, pode ser necessário, já no primeiro contato, ter uma visão mais aprofundada do seu comportamento.

 

De qualquer forma, mais cedo ou mais tarde, você precisará especificar em detalhes o caso de uso. Você começa a fazer isso pela redação do cenário principal de sucesso.

 

Podemos “abrir” o resumo, se o tivermos, em um cenário principal de sucesso. Caso não tenhamos o resumo, nada impede que já façamos o levantamento buscando entender o comportamento como um cenário principal de sucesso.

 

Qualquer comportamento é descrito em um caso de uso na forma de uma seqüência de passos, onde cada passo descreve uma interação do ator com o sistema, uma ação do sistema ou uma resposta do sistema para o autor.

 

Damos o nome de cenário principal de sucesso, àquela seqüência de passos que descreve a situação mais comum da transação de negócios que ele modela.

 

Naturalmente, a situação mais comum é a mais fácil de ser levantada. Todos os membros da equipe de negócios a conhecem razoavelmente bem e – assim – é um bom ponto de partida na análise dos requisitos da transação. Também, faz com que mantenhamos os pés no chão, ou seja - neste caso – que saibamos a expectativa de funcionamento “normal” da aplicação.

 

No nosso exemplo, poderíamos ter algo como o que segue:

 

 

Caso de Uso:

Requisitar Reboque

 

Ator Primário:

Segurado

 

Resumo:

Segurado liga para a central telefônica, identifica-se confirmando informações sobre a apólice, informa o endereço onde se encontra o veículo e recebe a estimativa para chegada do veículo.

 

Cenário Principal de Sucesso:

 

1. Segurado liga para central telefônica;

2. Operador da central, atende a ligação e pergunta o número da apólice;

3. Segurado informa apólice;

4. Operador pesquisa apólice no sistema;

5. Sistema apresenta informações da apólice;

6. Operador confirma informações com Segurado;

7. Operador solicita localização do veículo;

8. Operador insere localização informada pelo Segurado;

9. Sistema obtém expectativa de atendimento dos serviços de reboque;

10. Operador informa ao Segurado;

11. Fim do Caso.

 

 

Perceba algumas das características do exemplo acima:

 

1) Cada passo é numerado;

2) Cada passo identifica seu acionador e a ação que ele executa;

3) Cada passo é descrito em termos do negócio;

4) O conjunto corresponde a uma transação completa e bem sucedida!

 

Outra característica importante é não se apegar aos detalhes. Não importa, neste momento, quais informações precisam ser confirmadas com o segurado, no passo 6. Também não importa, ainda, como o sistema obtém a expectativa de atendimento, no passo 9. Só importa realmente que isto acontece e o fluxo em que isto acontece.

 

 

Prelúdio das Extensões

 

Num primeiro momento, você deve se concentrar em compreender e registrar o cenário principal de sucesso. Ele e apenas ele! Resista à tentação de descobrir as respostas para perguntas do tipo “O que acontece se a apólice não existir ?”, “Como fazemos se o segurado não souber o número da apólice ?” ou mesmo “Como, exatamente, o sistema obtém expectativas de atendimento dos serviços de reboque ?”.

 

A Especificação de Requisitos é um processo que tem de ser vivido como tal. No processo de Especificação por Casos de Uso, a especificação se desenvolve gradualmente a partir da análise do cenário principal de sucesso. Assim, consolidá-lo deverá ser sua primeira preocupação.

 

E o que fazemos com essas dúvidas que surgiram?

 

Claro que não podemos simplesmente ignorá-las. Assim, você pode registrá-las no próprio caso de uso da forma como demonstrado abaixo:

 

 

 

Caso de Uso:

Requisitar Reboque

 

Ator Primário:

Segurado

 

Resumo:

Segurado liga para a central telefônica, identifica-se confirmando informações sobre a apólice, informa o endereço onde se encontra o veículo e recebe a estimativa para chegada do veículo.

 

Cenário Principal de Sucesso:

 

1. Segurado liga para central telefônica;

2. Operador da central, atende a ligação e pergunta o número da apólice;

3. Segurado informa apólice;

4. Operador pesquisa apólice no sistema;

5. Sistema apresenta informações da apólice;

6. Operador confirma informações com Segurado;

7. Operador solicita localização do veículo;

8. Operador insere localização informada pelo Segurado;

9. Sistema obtém expectativa de atendimento dos serviços de reboque;

10. Operador informa ao Segurado;

11. Fim do Caso.

 

Extensões:

 

3a) Segurado não sabe o número da apólice;

 

6a) Segurado não consegue confirmar informações;

 

6b) A pessoa quem fez a ligação não é o segurado;

 

 

 

Perceba as características das nossas adições:

 

1) Adicionamos OUTRA seção ao documento, específica para consolidar todas as Extensões;

2) Listamos cada extensão pela sua condição divergente em relação ao fluxo normal do cenário principal de sucesso, (exemplo, no passo 3, no cenário principal, o segurado sempre sabe o número da apólice. A condição divergente a isto, originou a extensão 3a);

3) Numeramos usando o número do passo no cenário principal de sucesso que produz a extensão;

4) Acrescentamos uma letra para distinguir extensões ligadas a um mesmo passo do cenário principal de sucesso;

 

 

Finalizando (por enquanto)

 

Embora simples, este é um assunto extenso. Enquanto um post de blog não seja o melhor espaço para um texto longo, estarei publicando este conteúdo em um conjunto de posts, buscando possibilitar uma leitura contínua, rápida e proveitosa.

 

Em nosso próximo artigo, analisaremos mais detalhadamente a especificação das extensões. Outros deverão se seguir, analisando cada aspecto específico que possa ser especificado em um caso de uso. Por isso, finalizo, por enquanto!

 

 

Sobre o Autor

 

Júlio Oliveira
Júlio Oliveira é Analista de Sistemas com Pós-graduação em Gerência de Projetos de Software pela PUC/Rio. Têm 20 anos de experiência em desenvolvimento de software corporativo, dos quais 10 anos, em seguradoras de médio e grande porte, atualmente, trabalha com consultoria de TI e desenvolvimento de web sites.

 

 



Adicionar este artigo ao seu site de favoritos ?
Digg! Reddit! Del.icio.us! Google! Live! Facebook! Technorati! StumbleUpon! MySpace! Netvouz! Mister-Wong! Diigo! Faves! Ask! DZone! Swik! Twitter! LinkedIn!

Adicionar comentário

Seu apelido/nome:
Comentário:

Menu Principal

Editar traduo para English (United Kingdom) Editar traduo para Português (Brasil)
Blog Sistemas e Cia