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

Edição das 11h06min de 22 de agosto de 2007

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.

Os casos de uso são textos semi-formais. Isto é uma decorrência de os casos de uso serem uma tentativa de criar uma especificação do sistema que seja escrita pelos usuários finais do sistema, que podem ser leigos quanto à programação de computadores, mas ao mesmo tempo os casos de uso devem ser úteis para os programadores, que irão desenvolver o sistema norteados por esses casos de uso.

O conjunto dos casos de uso de um sistema deve ser coerente, e deve poder ser resumido em uns poucos elementos básicos. Estes elementos básicos podem constituir um documento que descreve qual é o o objetivo que pretendemos alcançar utilizando o sistema como um todo. Esse documento especifica também quais serão os usuários desse sistema e que funções o sistema deverá implementar para permitir ou facilitar 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 seus anseios e exigências através de um documento 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 usuários que tenham em comum algumas características de uso do sistema o, que determina um perfil de uso do Stoa, ou seja, para os casos de uso, o termo "ator" designa um conjunto de usuários com características em comum - e portanto não queremos de maneira alguma implicar que as pessoas que utilizam o Stoa estejam "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, Pesquisar

Professores: Ensinar, Pesquisar

Funcionários: Facilitar o ensino e a pesquisa

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 elementos 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 relativo à 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

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", "Contexto", "Sequência" e "Alternativas", que constituem o formato desse caso de uso.

Considere agora o mesmo caso de uso, com outro formato.

Criar Estilo

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", "Contexto", "Sequência", "Alternativas" 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. Mas com certeza existirão os itens Nome, Sequência e Alternativas, pois estes itens são o mínimo necessário para que existam casos de uso.

No momento, determinamos que o formato de casos de uso do Stoa é o seguinte: Nome, Ator (como só indicaremos o ator principal, podemos deixar de lado o adjetivo principal), Nível, Contexto, Sequência, Alternativas e Observações, sendo estes últimos dois itens opcionais.

Exemplo de um Caso de Uso

Escrever Mensagem no Blog

O sistema não verifica se o usuário utilizaou expressões chulas em sua mensagem; espera-se que o controle de linguagem seja feito dinamicamente pelos usuários através da função Denunciar Mensagem.

Comentários sobre o exemplo

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

1. Nome
2. Lista de Atores
3. Contexto
4. Sequência de Etapas
5. Alternativas
6. Observaçõ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^[1].

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^[2], 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' e 'Adicionar 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 anseio ou uma exigência, 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 poderemos identificar no caso de uso 'Traduzir texto' o ator como sendo um Aluno Estrangeiro.

Quando um caso de uso refere-se a uma ação que pode ser executada por qualquer tipo de usuário, indicamos 'Usuário' como sendo o Ator principal do caso de uso em questão.

É permitido utilizar mais de um ator na especificação de qual o ator principal de um caso de uso (no exemplo do item Exemplo de um Caso de Uso, ao invés de escrever 'Usuário' poderíamos ter escrito 'Aluno, Professor ou Funcionário'.

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^[2], 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, a sequência de um caso de uso não deve ser assim:

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 'nível médio' 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'.

O erro neste caso consiste na mistura dos dois níveis de abstração - pois deverão haver, nesta situação, vários casos de uso: um de nível médio para descrever a função Pesquisar palavra-chave e, no nível baixo, um para Preencher Campo de Texto, outro para Clicar Botão e outro para Exibir Resultados de Pesquisa. O caso de uso de nível médio fará referência aos casos de uso de nĩvel baixo, sem no entanto ser ele mesmo de nível baixo.

Alternativas

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

Em primeiro lugar, este é um esforço colaborativo. Sinta-se livre para editar os casos de uso escritos por outras pessoas, e saiba que os casos de uso que você escrever possivelmente serão editados por outras pessoas, também.

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.

A grande esceção a esta regra é quando uma etapa simples de nível alto ou médio corresponder a muitas etapas de nível médio ou baixo. Nesse caso, uma atividade simples torna-se um caso de uso.

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.

Níveis de Casos de Uso do Stoa

Adotaremos inicialmente três níveis para os casos de uso do Stoa, mas se, no futuro, ficar demonstrado que uma divisão em número diferente de níveis é mais eficiente, poderemos alterar isto.

Os três níveis de abstração dos casos de uso do Stoa são Alto, Médio e Baixo.

Nível Alto

O nível Alto corresponde ao nivel no qual se inserem os casos de uso relacionados a aspirações e exigências do usuário. Neste nível estão, por exemplo, os casos de uso Aprender, Ensinar e Facilitar Ensino, que são os casos de uso mais característicos daquilo que define um aluno, um professor e um funcionário, respectivamente.

O nível Alto tem casos que, em geral, são completados no transcorrer de um período de tempo maior do que geralmente necessário para completar um caso de nível Médio e muito maior do que o tempo geralmente necessário para completar um caso de uso de nível Baixo.

Nível Médio

O nível médio corresponde ao nível no qual se inserem os casos de uso relacionados a atividades realizadas pelos usuários no sistema. Neste nível estão, por exemplo, os casos de uso Escrever Mensagem de Blog, Pesquisar Assunto, Criar Apresentação.

Neste nível estão classificados os casos de uso nos quais há uma função que, quando utilizada, efetiva um objetivo do usuário. Entretanto, os casos de uso do nível médio não são detalhados no tocante às partes e características do sistema que os implementará. O detalhamento do sistema é feito com os casos de uso do nível baixo.

O nível médio engloba casos de uso relativos a funções que podem levar menos de uma sessão para completar-se (por exemplo, Pesquisar Assunto), ou podem levar várias sessões para serem completados (por exemplo, Criar Apresentação). De modo geral, os casos de uso do nível médio demoram mais que os casos de uso de nível baixo e demoram menos que os casos de uso de nível alto.

Nível Baixo

O nível baixo corresponde ao conjunto dos casos de uso relativos às atividades realizadas pelo sistema para os usuários, Neste nível estão, por exemplo, os casos Obter Informações de Formulário, Criar Registro no Banco de Dados e Exibir Página Principal.

Neste nível estão classificados os casos de uso relativos a atividades do sistema necessárias para a realização de alguma função de nível mais alto. (Nota aos techies: é tentador começar a escrever casos de uso de baixo nível imediatamente, descrevendo as funções do sistema que conhecemos em detalhes, mas isto é um erro, pois um dos objetivos ao escrever casos de uso é minimizar os requisitos do sistema, minimizando produção e manutenção desta maneira. Portanto chegamos à conclusão que os casos de uso devem ser criados no nível mais alto de abstração, e os casos de nível médio e baixo devem ser criados apenas por exigência desses casos de nivel alto - isto corresponde, grosso modo ao que os autores de Patterns for Effective Use Cases chamaram de SpiralDevelopment (Desenvolvimento em Espiral - a idéia é criar um conjunto de casos de uso de alto nível, detalhar suas etapas e determinar a partir deles um segundo conjunto de casos de uso, de nível mais baixo, e então retornar e revisar tudo. Quando tudo for considerado aceitável, "descer" mais um pouco o nível, criando os casos de uso mais próximos de uma descrição do sistema computacional).

Os casos de uso deste nível demoram, em geral, menos de uma sessão para serem executados, pois correspondem às atividades que o servidor Stoa deve realizar para cumprir alguma etapa ou função de nível médio, geralmente sob o comando do usuário.

Glossário

Pesquisar 

é o termo consagrado pelo escritores de documentação de informática para designar a ação de "fazer uma busca", por exemplo num site como o Google o usuário "pesquisa" por palavras e expressões. Entretanto o termo pesquisa é utilizado de maneira mais frequente pelos alunos e professores da USP para designar uma atividade acadêmica muito característica que consiste na investigação sistemática de um assunto, geralmente vinculada com o recebimento de uma bolsa ou a obtenção de um título acadêmico. Portanto decidimos utilizar pesquisa para a atividade acadêmica e busca para a atividade computacional.

Sessão 

é o termo utilizado para designar o conjunto de atividades realizadas entre o momento em que um usuário inicia sua interação com o sistema e o momento em que finaliza essa interação. Em teoria, uma sessão pode ter qualquer duração, mas na prática cada sessão dura entre alguns minutos e algumas horas, e é delimitada pelo login e pelo logout. Uma sessão geralmente tem associada a si um cookie, que nada mais é do que um arquivo texto armazenado no computador do usuário, que serve, grosso modo, como solução técnica do problema de "acompanhar" muitos usuários visitando muitas páginas ao mesmo tempo.

Sistema 

é o termo utilizado para designar o conjunto dos aplicativos (softwares) que trabalham em conjunto para fornecer ao usuário as funções que este necessita para que este consiga ou tenha facilitado o cumprimento de seus objetivos. No caso do Stoa, é importante distinguir entre o site Stoa e o sistema Stoa: o site é apenas a página da internet, enquanto que o sistema Stoa é composto por muitas partes, como servidores, bancos de dados, frameworks como Elgg e Moodle, e várias outras coisas de interesse para os desenvolvedores, mas que devem ser invisíveis para os usuários do sistema que não têm interesse em conhecer o Stoa "por dentro". (Nota aos desenvolvedores: os casos de uso referem-se ao sistema Stoa, e portanto podemos modelar o sistema através dos casos de uso com grande liberdade, por exemplo, criando casos de uso que têm funções com etapas que, para serem cumpridas, algumas devem ser executadas pelo Moodle, e outras pelo Stoa-stable. Isto pode parecer um erro à primeira vista, mas cabe lembrar aqui que os casos de uso têm como objetivo primordial definir as funcionalidades do Stoa que sejam de valor para os usuários. Para estes, muitas vezes não importa qual servidor ou qual PHP executa realmente seus comandos, importa apenas que seu objetivo seja cumprido).

Referências

1. ↑ Wikipedia: Use Cases
2. ↑ ^{2,0 2,1} Adolph, Steve & Bramble, Paul. Patterns for Effective Use Cases.