Mudanças entre as edições de "Casos de Uso"

De Stoa
Ir para: navegação, pesquisa
(Adição de exemplos e explicações.)
Linha 39: Linha 39:
  
 
----
 
----
 +
 
'''Criar Estilo'''
 
'''Criar Estilo'''
  
Linha 44: Linha 45:
  
 
1. Navegar até a página de Criação e Edição de Estilos.  
 
1. Navegar até a página de Criação e Edição de Estilos.  
 +
 
2. Criar Estilo
 
2. Criar Estilo
 +
 
3. Aplicar Estilo a páginas de responsabilidade do Usuário.
 
3. Aplicar Estilo a páginas de responsabilidade do Usuário.
  
Linha 50: Linha 53:
  
 
2.a. Caso o usuário pretenda criar um Estilo a partir de um Estilo preexistente, este deverá ser selecionado e editado.
 
2.a. Caso o usuário pretenda criar um Estilo a partir de um Estilo preexistente, este deverá ser selecionado e editado.
 +
 
----
 
----
  
Linha 56: Linha 60:
  
 
----
 
----
 +
 
'''Criar Estilo'''
 
'''Criar Estilo'''
  
 
Ator principal: Usuário
 
Ator principal: Usuário
 +
 
Ator secundário: Outro Usuário
 
Ator secundário: Outro Usuário
 +
 
Nível: Funcional
 
Nível: Funcional
  
 
1. Navegar até a página de Criação e Edição de Estilos.  
 
1. Navegar até a página de Criação e Edição de Estilos.  
 +
 
2. Criar Estilo
 
2. Criar Estilo
 +
 
3. Aplicar Estilo a páginas de responsabilidade do Usuário.
 
3. Aplicar Estilo a páginas de responsabilidade do Usuário.
  
Linha 71: Linha 80:
  
 
Observações:
 
Observações:
 +
 
Este caso de uso não prevê a correção de erro caso a edição ou criação de estilo seja feita de modo tal pelo usuário, que sua utilização como Estilo principal do usuário implique na não-exibição da própria página de seleção de Estilos.
 
Este caso de uso não prevê a correção de erro caso a edição ou criação de estilo seja feita de modo tal pelo usuário, que sua utilização como Estilo principal do usuário implique na não-exibição da própria página de seleção de Estilos.
 +
 
----
 
----
  
Linha 124: Linha 135:
 
A sequência de etapas deve, de maneira global, corresponder a uma única função ou objetivo do ator primário. Na terminologia dos autores de ''Patterns for Effective Use Cases'', um caso de uso deve contemplar um '''CompleteSingleGoal''' (objetivo único e completo em si mesmo), ou seja, a sequência de etapas deve ser uma lista ordenada de passos a serem dados para que o usuário, a partir de uma situação 'padrão' (no caso do Stoa, usuário logado no sistema, com a página principal carregada no navegador), consiga obter um resultado tangível.  
 
A sequência de etapas deve, de maneira global, corresponder a uma única função ou objetivo do ator primário. Na terminologia dos autores de ''Patterns for Effective Use Cases'', um caso de uso deve contemplar um '''CompleteSingleGoal''' (objetivo único e completo em si mesmo), ou seja, a sequência de etapas deve ser uma lista ordenada de passos a serem dados para que o usuário, a partir de uma situação 'padrão' (no caso do Stoa, usuário logado no sistema, com a página principal carregada no navegador), consiga obter um resultado tangível.  
  
O conjunto das etapas deve ser razoavelmente homogêneo, isto é, as etapas não devem ser cada uma de um 'nĩvel de abstração' muito diferente do outro. Por exemplo, um caso de uso não deve ser assim:
+
O conjunto das etapas deve ser razoavelmente homogêneo, isto é, as etapas não devem ser cada uma de um 'nĩvel de abstração' muito diferente do outro. Por exemplo, um caso de uso '''não''' deve ser assim:
  
 
----
 
----

Edição das 15h08min de 15 de agosto de 2007

Conteúdo

 [ocultar

Introdução

Casos de Uso (conhecidos como "Use Cases" em inglês) são uma ferramenta de desenvolvimento, geralmente utilizada para o desenvolvimento de software, com o intuito de determinar as especificações funcionais de um sistema.

Estas podem ser agrupadas em um documento que descreve qual é o o objetivo que pretendemos alcançar utilizando o sistema como um todo. O documento especifica também quais serão os usuários desse sistema e que funções o sistema deverá permitir ou facilitar para que os usuários realizem seus objetivos pessoais. Esta página de wiki é tal documento com relação ao conjunto de casos de uso do Stoa, e também uma explicação simplificada do que são casos de uso e como escrevê-los.

No caso do Stoa, que é um sistema em desenvolvimento contínuo, acreditamos que os casos de uso podem ser um canal de comunicação entre os usuários e os desenvolvedores, que permitirá a comunicação pelos usuários de quais suas necessidades de maneira semi-formal, o que facilitará a compreensão dessas necessidades por parte dos desenvolvedores.

Além disso, os casos de uso permitem o desenvolvimento de testes funcionais, na medida em que somente sabendo qual é o funcionamento esperado de um sistema é que podemos determinar um teste para verificar se este funcionamento é realizado satisfatoriamente ou não.

Outra utilidade dos casos de uso é utiliza-los como esboço para a documentação.

Os casos de uso do Stoa devem ser compreendidos dentro de certos limites, ditados pela delimitação do conceito do que é o Stoa, pela indicação de quais são seus "atores" e quais são os objetivos desses atores. (Entendemos por "ator", aqui, um "tipo de usuário" do sistema - ou seja, um conjunto de características de uso do sistema, comum a muitos usuários, e que determina um perfil de uso do sistema - não queremos de maneira alguma implicar que as pessoas que utilizam o Stoa estejam sempre "atuando").

Definições

O que é o Stoa?

O Stoa é uma rede social dos alunos, professores e funcionários da USP.

Quais são os atores do Stoa?

Alunos, Professores e Funcionários.

Quais são os objetivos de cada tipo de usuário do Stoa?

Alunos: Aprender
Professores: Ensinar, Pesquisar
Funcionários: Facilitar o ensino
Todos: Comunicar-se.

Estas definições não são um caso de uso; elas delimitam as fronteiras dentro das quais escreveremos os casos de uso, a partir dos conceitos apresentados.

Formato de um Caso de Uso

Um Caso de Uso pode ter uma infinidade de formatos, dependendo de como seu autor desejar especifica-lo. Além das diferenças textuais nos mesmos itens de informação, um caso de uso pode diferir de outro caso de uso relativos à mesma função pela ausência ou presença de itens de informação. O conjunto dos itens de informação de um caso de uso, desprovidos de texto além de seus nomes, constitui o formato de um caso de uso.

Por exemplo, considere o seguinte caso de uso.


Criar Estilo

Ator principal: Usuário

1. Navegar até a página de Criação e Edição de Estilos.

2. Criar Estilo

3. Aplicar Estilo a páginas de responsabilidade do Usuário.

Exceções:

2.a. Caso o usuário pretenda criar um Estilo a partir de um Estilo preexistente, este deverá ser selecionado e editado.


Esse caso de uso possui os itens "Nome", "Ator principal", "Sequência" e "Exceções", que constituem o formato desse caso de uso. Considere agora o mesmo caso de uso, com outro formato.


Criar Estilo

Ator principal: Usuário

Ator secundário: Outro Usuário

Nível: Funcional

1. Navegar até a página de Criação e Edição de Estilos.

2. Criar Estilo

3. Aplicar Estilo a páginas de responsabilidade do Usuário.

Exceções:

2.a. Caso o usuário pretenda criar um Estilo a partir de um Estilo preexistente, este deverá ser selecionado e editado.

Observações:

Este caso de uso não prevê a correção de erro caso a edição ou criação de estilo seja feita de modo tal pelo usuário, que sua utilização como Estilo principal do usuário implique na não-exibição da própria página de seleção de Estilos.


Neste segundo caso, o formato do caso de uso é: "Nome", "Ator principal", "Ator secundário", "Nível", "Sequência", "Exceções" e "Observações".

É possível deixar a escolha do formato a cargo de cada autor individual, mas isso tornaria o conjunto dos casos de uso menos coerente, e portanto menos interessante para os programadores, que irão no final do processo utilizar os casos de uso para escrever o sistema. Portanto, tentaremos adotar um formato comum nos casos de uso do Stoa, que seja ao mesmo tempo suficientemente completo e com o menor número de elementos possível, a fim de que seja útil e simples.

No momento, ainda estamos na fase inicial da produção dos casos de uso do Stoa, e portanto ainda não determinamos qual formato utilizaremos.

Exemplo de um Caso de Uso


Escrever Mensagem no Blog

Ator principal: Usuário

1. Usuário navega até o blog no qual pretende escrever mensagem.

2. Usuário escreve e aprova nova mensagem.

3. Sistema confirma recebimento da mensagem e passa a exibir a nova mensagem nas páginas adequadas.

Exceções:

2.a. Caso o usuário não tenha permissão de escrever nova mensagem no blog selecionado, o sistema deve informar o usuário de tal fato, e notificar o moderador da comunidade de tal evento, desde que o moderador tenha selecionado que seja informado de tais eventos.


Comentários sobre o exemplo

O caso de uso "Escrever Mensagem no Blog" tem a seguinte estrutura:

  1. Nome
  2. Lista de Atores
  3. Sequência de Etapas
  4. Exceções.

Tal como referido no item Formato de um Caso de Uso, este caso de uso poderia ter outros itens, como por exemplo Versão, Autor, entre outros - veja o formato de caso de uso na página (em inglês) da wikipedia sobre casos de uso: http://en.wikipedia.org/wiki/Use_case.

Nome de um Caso de Uso

O nome de um caso de uso deve ser informativo e tão simples quanto possível. Segundo os autores do livro Patterns for Effective Use Cases, o nome de um caso de uso deve ser um VerbPhraseName, ou seja, o nome de um caso de uso deve ser uma frase que corresponde a uma ação, geralmente escrita como um verbo. Bons nomes para casos de uso seriam, no caso do Stoa, 'Escrever Mensagem de Blog', 'Criar Comunidade' ou 'Adicionar Usuário como Contato'.

Lista de Atores de um Caso de Uso

Os Atores de um Caso de Uso deveriam ser sempre pessoas que utilizam o sistema com um determinado objetivo em mente. Portanto devemos indicar como sendo o Ator de um caso de uso a pessoa que tem um desejo ou uma necessidade, e que pretende satisfazer esse objetivo utilizando o sistema. No caso do Stoa, identificamos três atores (tipos de usuários):

Alunos, Professores e Funcionários

Esta divisão poderia ser refinada; entretanto acreditamos que caso seja necessário escrever casos de uso aplicáveis apenas a categorias mais específicas de um tipo de usuário, será mais adequado criar papéis que subdividam estas categorias em categorias mais específicas. Por exemplo, se for necessário no futuro escrever casos de uso específicos para 'alunos estrangeiros', criaremos o papel Aluno Estrangeiro, e então pdoeremos identificar no caso de uso 'Traduzir texto' o ator como sendo um Aluno Estrangeiro.

Sequência de Etapas

A sequência de etapas deve, de maneira global, corresponder a uma única função ou objetivo do ator primário. Na terminologia dos autores de Patterns for Effective Use Cases, um caso de uso deve contemplar um CompleteSingleGoal (objetivo único e completo em si mesmo), ou seja, a sequência de etapas deve ser uma lista ordenada de passos a serem dados para que o usuário, a partir de uma situação 'padrão' (no caso do Stoa, usuário logado no sistema, com a página principal carregada no navegador), consiga obter um resultado tangível.

O conjunto das etapas deve ser razoavelmente homogêneo, isto é, as etapas não devem ser cada uma de um 'nĩvel de abstração' muito diferente do outro. Por exemplo, um caso de uso não deve ser assim:


  1. Usuário decide qual palavra-chave irá pesquisar.
  2. Usuário pressiona tecla correspondente à primeira letra da palavra-chave que deseja pesquisar.
  3. Usuário repete etapa 2 tantas vezes quantas necessário até escrever toda a palavra-chave.
  4. Usuário move o mouse até o botão "Ok".
  5. O sistema apresenta os resultados da pesquisa.

No exemplo acima, a primeira etapa (usuário decide palavra-chave) corresponde a uma função que pode ser dita de 'alto nível' de abstração - metaforicamente, um objetivo 'claramente visível'. As etapas seguintes podem ser ditas de 'baixo nível' de abstração - cada uma corresponde a uma etapa a ser realizada pelo usuário, mas de maneira muito diferente da etapa 1. Metaforicamente, as demais etapas são 'microscópicas'.

Exceções

As exceções devem complementar a sequência principal do caso de uso de modo que o conjunto da sequência principal mais as exceções constitua o conjunto de todas as possibilidades funcionais relevantes para o caso.

Entretanto, se as exceções tornam-se muito numerosas ou muito ramificadas, isto é sinal de que possivelmente o caso de uso deve ser fracionado, por exemplo promovendo uma exceção ao status de caso de uso.

Metodologia de Criação dos Casos de Uso do Stoa

Cada etapa de um caso de uso pode ou não ser um caso de uso em si mesma. Se a etapa corresponder a um procedimento simples que o sistema deve executar, a etapa não é um caso de uso. Se a etapa corresponder a uma ação simples que um usuário deve fazer, ela tampouco será um caso de uso. Uma etapa será um caso de uso quando ela corresponder a mais de uma ação ou procedimento.

Um caso de uso que tem como uma de suas etapas uma etapa extendida (ou seja, uma etapa que corresponde a mais de uma ação ou procedimento), está ligado a outros casos de uso, aqueles que definem as etapas componentes de suas etapas extendidas.

Referências

Adolph, Steve & Bramble, Paul. Patterns for Effective Use Cases.

http://en.wikipedia.org/wiki/Use_case

http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases

Ferramentas pessoais
Espaços nominais

Variantes
Ações
Navegação
Imprimir/exportar
Ferramentas