Guia de Modelagem de Casos de Uso

Exemplo de Guia de Modelagem de Casos de Uso

Versão <n.m>

Última Atualização <aaaammdd>

1. Introdução

1.1 Finalidade

A finalidade deste conjunto de diretrizes é assegurar a consistência do modelo de Casos de Uso. Ele fornece orientação em como documentar um Caso de Uso bem como ajuda geral sobre tópicos relacionados tidos como problemáticos para os Especificadores de Requisitos e os Analistas de Sistemas.

1.2 Escopo

Esta diretrizes podem ser usadas como se encontram, ou adaptadas, para atender às necessidades da maioria dos projetos.

1.3 Definições, Acrônimos e Abreviações

1.4 Referências

1.5 Visão Geral

Este conjunto de diretrizes é organizado em duas seções: a primeira descreve nosso modo preferido de modelar os Casos de Uso, a segunda parte, fornece as diretrizes para o conteúdo do modelo de Casos de Uso e para a nomeação dos elementos dentro do modelo.

2. Guia Geral de Modelagem de Casos de Uso

2.1 Estilo Geral

Os Casos de Uso serão escritos usando o template fornecido pelo Rational Unified Process, com alguma modificação de estilo e layout para se adequar aos padrões de documentação do projeto. Clique aqui para consultar a versão HTML deste template.

2.2 Uso do relacionamento de <<comunicação>>

A associação entre um Ator e um Caso de Uso é denominada relacionamento de comunicação. Recomenda-se que essa associação seja feita de modo unidirecional. Usando essa estratégia de modelagem distinguiremos:

q Ator Ativo
O Ator é considerado ativo em um par Ator-Caso de Uso quando o Ator inicia (ou dispara) a execução do Caso de Uso. A seta no relacionamento de comunicação aponta para o Caso de Uso.

q Ator Passivo
O Ator é considerado passivo em um par Ator-Caso de Uso quando o Caso de Uso inicia a comunicação. Os Atores Passivos normalmente são sistemas ou dispositivos externos com os quais nosso sistema precisa se comunicar. A seta no relacionamento de comunicação aponta para o Ator.

Essa recomendação é feita porque a noção de atores ativos e passivos é valiosa para o modelo de Casos de Uso.

2.3 Uso dos relacionamentos de <<inclusão>> e <<extensão>>

Na primeira instância, é recomendável evitar o uso desses relacionamentos. Essa recomendação é feita porque o uso errado desses relacionamentos tem mais potencial para gerar confusão do que para ajudar a simplificar o Modelo de Casos de Uso. A melhor prática é evitar esse tipo de decomposição inicial, e usar esses relacionamentos em um estágio posterior do processo. É possível usar esses relacionamentos para:

2. Fatorar o comportamento do caso de uso base que não é necessário ao entendimento da finalidade primária do caso de uso, somente o seu resultado é importante.

3. Mostrar que talvez haja um conjunto de segmentos de comportamento dos quais um ou vários podem ser inseridos em um ponto de extensão em um caso de uso base.

Mas eles só devem ser usados onde for relevante para ajudar a simplificar e gerenciar o modelo de casos de uso.

2.3.1 Uso do relacionamento de <<inclusão>>

O relacionamento de inclusão descreve um segmento de comportamento que é inserido em uma instância de caso de uso que execute o caso de uso base. Trata-se de um mecanismo de natureza semelhante a uma sub-rotina e geralmente é usado para fatorar o comportamento comum.

2.3.2 Uso do relacionamento de <<extensão>>

O relacionamento de extensão é um relacionamento mais difícil de se tirar vantagem, basicamente, porque o caso de uso de extensão não é conhecido pelo caso de uso base. De modo geral, há poucos lugares em que esse relacionamento é útil para a maioria dos sistemas de negócios. Lembre-se, no entanto, de que sempre há exceções às regras e de que esse mecanismo pode ser útil em certas circunstâncias.

2.4 Uso de Generalização de Ator

Geralmente, a Generalização de Ator pode ser usada para definir melhor os diferentes papéis assumidos pelos usuários do sistema a ser desenvolvido. Isso é útil em aplicativos com diferentes "categorias" de usuários finais. Dessa forma, apenas a funcionalidade relevante será apresentada para cada categoria de usuários, e nós poderemos controlar os direitos de acesso com base nesse agrupamento.

Método empírico: Cada caso de uso será iniciado por um Ator. Esse método pode ser suprimido, neste caso, a descrição do caso de uso deve justificar a decisão.

Exemplo do Domínio de Negócio da Universidade: Bibliotecário e Professor são dois exemplos de dois papéis (atores) existentes no Domínio Universidade. Esses papéis têm algumas tarefas comuns e outras que são exclusivas dos seus papéis no Negócio. O modo preferencial de modelar isso é mostrado abaixo.

2.5 Uso de Diagramas de Interação

Em alguns casos, é benéfico incluir - além do fluxo textual de eventos - um diagrama de Interação para ilustrar o fluxo de eventos de "alto nível" do caso de uso. É recomendável desenhar um diagrama de seqüência para isso no Rational Rose. Inclua apenas a comunicação entre os atores e os objetos de fronteira (cobrindo tanto as mensagens de entrada quanto as de saída) e trate o sistema como uma caixa preta. Use objetos de fronteira com nomes lógicos como foram definidos no fluxo de eventos do caso de uso, sem atribuí-los a classes nesse momento.

Não é necessário que cada caso de uso tenha um diagrama de interação correspondente: trata-se de um produto liberado opcional.

2.6 Uso de Diagrama de Atividades

Onde um diagrama de atividades ajudar a definir, esclarecer e concluir o fluxo de eventos do caso de uso, é recomendável que eles sejam modelados no Rational Rose. Um bom método empírico é utilizar os Diagramas de Atividades para casos de uso complexos (contendo vários fluxos alternativos e/ou excepcionais). O diagrama de atividades mostra uma árvore de decisão dos fluxos do caso de uso.

Não é necessário que cada caso de uso tenha um diagrama de atividades correspondente: trata-se de um produto liberado opcional.

3. Como Descrever um Caso de Uso

Para obter informações gerais e diretrizes de Casos de Uso adicionais, consulte o Rational Unified Process.

3.1 Diretrizes de Ator

Para obter informações gerais e diretrizes de Atores adicionais, consulte o Rational Unified Process.

3.1.1 Cada Caso de Uso concreto estará envolvido com pelo menos um Ator

Cada caso de uso concreto está envolvido com pelo menos um ator? Caso não esteja, alo está errado; um caso de uso que não interage com um ator é supérfluo, e você o removerá ou identificará o ator correspondente.

Em alguns casos, pode haver mais de um ator na interação do caso de uso. Certifique-se de que a utilização de vários atores no caso de uso é válida (consulte Generalização de Ator).

3.1.2 Nomes de Atores Intuitivos e Descritivos

Os atores têm nomes intuitivos e descritivos? Tanto os usuários quanto os clientes entendem os nomes? É importante que os nomes de atores correspondam a seus papéis. Caso contrário, troque-os.

Consulte o Modelo de Casos de Uso para assegurar que esteja usando o nome de ator correto para todos os atores do seu caso de uso.

3.1.3 Uso Consistente de Nomes de Atores

A especificação de caso de uso será escrita usando nomes de atores consistentemente. Tome cuidado para assegurar que a nomeação de atores seja clara e inconfundível.

Não faça referência genérica ao "ator"; em vez disso, use o nome real para identificar com exclusividade ou definir o ator. O nome do ator pode ser visto como um papel assumido em um conjunto de interações do sistema.

3.2 Nome do Caso de Uso

O nome do caso de uso será exclusivo, intuitivo e explicativo a fim de definir com clareza e sem ambigüidade o resultado observável obtido do caso de uso.

Uma boa verificação do nome do caso de uso é pesquisar se todos os clientes, representantes de negócios, analistas e desenvolvedores compreendem os nomes e as descrições dos casos de uso. Lembre-se: você está definindo um resultado observável importante do ponto de vista dos atores.

Cada nome de caso de uso descreverá o comportamento dos suportes de caso de uso. O nome combinará tanto a ação que está sendo realizada como o elemento que está "sofrendo a ação". Geralmente, eles serão uma simples combinação Verbo/Nome. O caso de uso deve ser nomeado do ponto de vista do ator que dispara o caso de uso. São exemplos: "Inscrever em um curso", "Selecionar um curso para ministrar".

3.3 Breve Descrição do Caso de Uso

3.3.1 Pelo menos um parágrafo

O caso de uso conterá uma descrição breve. Essa descrição terá, pelo menos, um parágrafo e, no máximo, três parágrafos de extensão. A descrição abordará uma explicação da finalidade principal, da proposição de valor e dos conceitos do caso de uso.

3.3.2 Um exemplo (opcional)

Onde for relevante, uma "história" curta de exemplo pode ser incluída com a descrição breve que ajuda a fornecer mais contexto. Esse exemplo normalmente seguirá o Fluxo Básico e, onde for conveniente, incluirá valores de dados.

3.4 Uso consistente do futuro: do indicativo

Os requisitos do sistema dentro dos casos de uso serão escritos usando o futuro do indicativo. Os verbos no futuro foram escolhidos em detrimento de "Deverá" e "Deve" para descrever os requisitos consistentemente. Será evitado o uso de expressões que impliquem que os requisitos são opcionais ou indefinidos, como "deveria", "possivelmente" "etc.", "talvez" ou "pode".

3.5 Uso de Termos do Glossário

Todos os Termos do Negócio usados no caso de uso serão definidos no Glossário do projeto. Se existir um Termo do Negócio em um caso de uso que não exista no glossário, o termo precisará:

1. Ser adicionado ao glossário, incluindo uma breve descrição (máximo de um parágrafo).

2. Ser alterado no caso de uso para refletir o Termo de Negócio correto definido no glossário.

3.6 Uso de Termos de "Ação"

3.6.1 Definir onde o sistema é responsável por apresentar a Opção de Ação

O caso de uso definirá explicitamente onde o sistema é responsável por apresentar uma ação como uma opção disponível para o ator selecionar. Na maioria dos casos, as opções disponíveis devem ser apresentadas como parte do fluxo básico e mencionadas como o ponto de entrada na primeira sentença do fluxo alternativo correspondente.

3.6.2 Uso consistente do termo em todo o Caso de Uso

O uso de termos como Novo, Modificar, Cancelar, Excluir, OK e Imprimir será consistente em todo o caso de uso: A mesma ação lógica não será mencionada usando uma terminologia diferente. Cuidado especial deverá ser tomado para assegurar que os Termos de Ação usados nos Fluxos Alternativos correspondam àqueles usados no fluxo básico.

3.7 Separar parágrafos para comportamento de Ator e de Sistema

Toda vez que a interação entre o ator e o sistema mudar o foco (entre o ator e o sistema), o próximo segmento de comportamento começará com um parágrafo. Comece primeiro com um ator e depois com o sistema.

A frase deve começar com 'O <nome-do-ator> fará xxxxx', ou 'O sistema fará xxxx'. Sempre expresse o nome do ator corretamente, por extenso, em vez de por uma abreviação.

3.8 Fluxos Alternativos e Subfluxos

Cada Fluxo Alternativo e Subfluxo definirão explícita e claramente todos os pontos de entrada possíveis no fluxo e concluirão com todos os pontos de saída possíveis do fluxo.

O fluxo alternativo também expressará explicitamente o ponto de saída e onde o ator continua - retornando a um passo específico do fluxo básico ou finalizando.

Onde o fluxo de eventos se tornar desordenado devido a um comportamento complexo, ou um único fluxo exceder o tamanho de uma página impressa, poderão ser usados subfluxos para melhorar a clareza e gerenciar a complexidade. Os subfluxos serão escritos movendo-se um grupo lógico e independente de comportamento detalhado para um subfluxo, e mencionando esse comportamento em formato resumido dentro do fluxo de eventos.

3.9 Precondições e Pós-condições

A especificação do caso de uso incluirá um conjunto de condições (também chamadas de suposições) que se esperam ser verdadeiras antes do início do caso de uso (precondições) e após o término do caso de uso (pós-condições). Observe que o caso de uso pode terminar de várias formas, e cada "pós-condição" deve ser descrita apropriadamente.

3.10 Uso de espaços reservados para detalhe ausente (TBD)

Onde as informações ainda não estiverem definidas ou não foram decididas, o caso de uso incluirá uma referência ao problema ou elemento e incluirá um espaço reservado: TBD.

3.11 Definição e Referência a Especificações Suplementares

Onde houver requisitos adicionais que não possam ser descritos naturalmente durante o fluxo de eventos, eles serão definidos como requisitos suplementares. Os que forem específicos de um caso de uso serão definidos na seção Requisitos Especiais da especificação do caso de uso.

Os requisitos aplicáveis em todo o sistema, especialmente aqueles de natureza não-funcional, serão definidos em um ou mais documentos separados de especificação suplementar.

Confiabilidade: - O sistema deve estar disponível 24 horas por dia , 7 dias por semana.

Desempenho: - O sistema deve fornecer uma resposta on-line que não exceda 5 segundos sob condições normais de carga.

3.12 Verificação Cruzada com Protótipo/Design de UI

O conteúdo do caso de uso será comparado com o Protótipo/Design de UI para assegurar que nenhum requisito do sistema esteja faltando no caso de uso ou no Protótipo/Design de UI. Onde forem necessárias mudanças no caso de uso, elas serão acionadas: as mudanças no Protótipo de UI serão anotadas como uma discussão para uma ação futura.

3.13 Fluxos de Exceção (Opcional)

As diretrizes a seguir são fornecidas para auxiliar a descobrir Fluxos de Exceção:

3.13.1 O que pode dar errado?

Para cada passo do caso de uso, pense no que pode dar errado. Cada exceção exclusiva pode ser capturada como um Fluxo de Exceção. Em alguns casos, um único Fluxo de Exceção será usado em todo o caso de uso, por exemplo, "Timeout". A principal informação a ser captada é: qual é o requisito de negócio quando ocorre a exceção, quer dizer, qual deve ser a experiência dos atores?