Orientações Para a Modelação de Casos de Uso

Este texto descreve uma série de orientações para a modelação de casos de uso, tendo como objectivo ajudar as equipas na gestão de requisitos. Trata-se simplesmente de um guia que também fornece informação sobre a forma de lidar com os casos de uso em ferramentas de modelação como o RSA e o Rose. No fundo, pretende criar standards para o desenvolvimento e manutenção de requisitos com casos de uso, bem como garantir a consistência.

O presente conjunto de orientações está organizado em duas secções. A primeira descreve a forma preferencial de modelação de casos de uso. A segunda fornece orientações para o conteúdo do modelo de casos de uso e para a atribuição de nomes aos elementos que constam do modelo.

Evolução de um caso de uso

O desenvolvimento de um caso de uso é um processo iterativo. Um caso de uso evolui desde uma simples ideia até uma descrição completa da forma como um sistema se comporta.

• Descoberta

Inicialmente, é "descoberto" um caso de uso. Um caso de uso é descoberto quando lhe é atribuído um nome com base no objectivo que um actor está a tentar atingir.

• Descrição breve

Imediatamente após a descoberta de um caso de uso (normalmente quando se está a discutir o nome) é criada uma breve descrição do mesmo. Esta descrição breve fala do objectivo do caso de uso e do valor fornecido ao actor. Normalmente bastam duas ou três frases para este tipo de descrição.

• Sumarização

A fase seguinte da evolução de um caso de uso é a sumarização. Esta sumarização contém uma lista de pontos do fluxo básico e a identificação (sem lista de pontos) de possíveis fluxos alternativos. Isto permite a identificação de cenários e ajuda a fornecer uma compreensão da possível dimensão e complexidade do caso de uso.

• Descrição completa

A fase final é descrever completamente o caso de uso. Isto é feito de forma iterativa. São identificados os fluxos particulares para desenvolvimento numa iteração e depois descritos de forma completa (e implementados). As iterações subsequentes identificam fluxos adicionais que também são descritos de forma completa (e implementados). O caso de uso completo será descrito completamente aquando da conclusão do projecto.

Estrutura do modelo de caso de uso

• Orientações de actor

Cada caso de uso concreto está envolvido com pelo menos um actor. Aos actores é atribuído um nome (ou nomes) intuitivo e descritivo que corresponde à sua função.

• Manter a secção associações de comunicação

As relações entre actores e casos de uso são chamadas associações de comunicação. Uma associação de comunicação entre um actor e um caso de uso indica que interagem. Ou seja, o actor participa no sistema e comunica com o sistema que contém o caso de uso. As associações de comunicação não descrevem o fluxo de dados. As interacções podem ser mecânicas, eléctricas, de dados, audíveis, visuais, ou qualquer combinação destas. Por exemplo, um actor poderá carregar num botão do sistema (estímulo mecânico) e o sistema pode responder com uma luz (resposta visual).

• Relação <<comunicação>>

Uma associação de comunicação é representada em diagramas UML sob a forma de linha sólida. A linha representa um diálogo bidireccional ou global entre o actor e o sistema.

• Relações <<incluir>> e <<alargar>>

Estas actividades devem ser realizadas por arquitectos depois dos casos de uso terem sido detalhados.

As relações <<incluir>> e <<alargar>> podem ser utilizadas para:

1. Determinar o comportamento comum para dois ou mais casos de uso.
2. Determinar o comportamento do caso de uso base que não é necessário para a compreensão do principal propósito do caso de uso; só o resultado dele é que é importante.
3. Mostrar que pode existir um conjunto de segmentos comportamentais, do qual um ou vários podem estar inseridos num ponto de extensão de um caso de uso base.

É recomendável que a utilização de relações <<incluir>> e <<alargar>> seja evitada. Estas relações têm muito mais potencial para criar confusão do que para ajudar a simplificar o modelo de caso de uso. Uma boa prática será evitar inicialmente este tipo de composição e considerar a utilização dessas relações numa fase posterior do processo, quando puderem ser encontrados comportamentos comuns em múltiplos casos de uso. Estas relações só devem ser utilizadas quando adicionam valor, ajudando a simplificar e a gerir o modelo de caso de uso.

Relações <<incluir>>

A relação «incluir» descreve um segmento comportamental que é inserido numa instância de caso de uso que executa o caso de uso base. É um mecanismo similar a uma subrotina e é utilizado normalmente para determinar comportamento comum. A relação incluir só deve ser utilizada quando existem fluxos que são comuns a múltiplos casos de uso. A utilização em excesso de relações «incluir» aumenta a complexidade para os especialistas de teste, designers e autores de documentação, dado que cada «incluir» introduz outro artefacto que tem de ser lido para compreender os requisitos. Também será necessário ter cuidado quando se utiliza a relação «incluir» para que o modelo de caso de uso não fique funcionalmente decomposto.

Relações <<alargar>>

Se existir uma parte de um caso de uso base que seja opcional, ou que não seja necessária para compreender o propósito principal do caso de uso, essa parte pode ser determinada e colocada num caso de uso adicional, de modo a simplificar a estrutura do caso de uso base. A adição é inserida implicitamente no caso de uso base utilizando a relação alargar.

O alargamento é condicional, o que significa que a sua execução está dependente daquilo que aconteceu aquando da execução do caso de uso base (similar a um fluxo alternativo). O caso de uso base não controla as condições para a execução da extensão. Essas condições são descritas dentro da relação alargar.

O caso de uso base é modificado implicitamente pelas extensões. Ou seja, o caso de uso base define uma estrutura à qual podem ser adicionadas extensões, mas a base não tem qualquer visibilidade relativamente às extensões específicas. O caso de uso base não tem qualquer conhecimento do caso de uso que o amplia (alarga). Consequentemente, não consegue ver e até poderá não aceder às propriedades do caso de uso de alargamento. Este último sabe qual é o caso de uso que alarga e pode ver todas as propriedades do caso de uso base. O caso de uso de alargamento pode aceder e modificar as propriedades do caso de uso base.

O caso de uso base deve estar completo em si mesmo, o que significa que deve ser compreensível e ter significado sem qualquer referência às extensões. Contudo, o caso de uso base não é independente das extensões, uma vez que não poderá ser executado sem a possibilidade se acompanhar as extensões.

O caso de uso base tem de identificar pontos de extensão numa secção separada da especificação do caso de uso. O caso de uso de alargamento indica onde alarga o caso de uso base, referenciando os pontos de extensão no caso de uso base.

• Generalização de actor

A generalização de actor é utilizada para simplificar o diagrama de caso de uso e para evitar os problemas das associações de comunicação quando múltiplos actores executam ao mesmo tempo o caso de uso para o mesmo propósito (por exemplo, actores que desempenham a mesma função). De uma forma geral, a generalização de actor pode ser utilizada para definir melhor as diferentes funções desempenhadas pelos utilizadores do sistema a ser desenvolvido. Isto é útil em aplicações com diferentes "categorias" de utilizadores finais. Desta forma, só as funcionalidades relevantes é que serão apresentadas a cada categoria de utilizador. Além disso, é possível controlar os direitos de acesso com base neste tipo de agrupamento.

Utilização da generalização de actor

Cada caso de uso só será iniciado por um actor. Este requisito pode ser contornado, mas em qualquer dos casos a descrição do caso de uso deverá justificar a decisão.

• Generalização de caso de uso

A utilização desta relação é proibida.

• Utilização de digramas de interacção

Em alguns casos é benéfico incluir, além do fluxo textual de eventos, um digrama de interacção para ilustrar o fluxo ?de alto nível? dos eventos do caso de uso. É recomendável que o diagrama de sequência para isto seja desenhado no Rational Rose. Deve-se incluir apenas a comunicação entre os actores e os objectos de fronteira (abarcando as mensagens de entrada e de saída), bem como tratar o sistema como uma caixa negra. Os objectos de fronteira deverão ser utilizados com nomes lógicos, tal como definido no fluxo de eventos do caso de uso, sem os incluir em classes nesta fase. Os diagramas de interacção são opcionais.

• Utilização de digramas de actividade

Em alguns casos, um diagrama de actividade poderá acrescentar valor, ajudando a definir, a clarificar e a completar o fluxo de eventos no caso de uso. É recomendável que os digramas de actividade sejam modelados no RSA. Uma boa prática a seguir é considerar os diagramas de actividade para casos de uso complexos (que contenham vários fluxos alternativos ou fluxos excepcionais). Os diagramas de actividade mostram uma árvore de decisão dos fluxos do caso de uso. Os diagramas de actividade são opcionais.

Como descrever um caso de uso

Seguindo o estilo geral, o caso de uso é escrito utilizando um modelo de referência.

• Nome do caso de uso

O nome do caso de uso terá que ser único, intuitivo e descritivo, de modo a definir, de forma clara e sem ambiguidades, o resultado observável do valor ganho com o caso de uso. Cada nome de caso de uso terá que descrever o comportamento suportado pelo caso de uso. Normalmente, isto traduz-se num simples verbo. Ao caso de uso deverá ser atribuído um nome com base na perspectiva do actor que desencadeia esse caso de uso.

Uma boa forma de testar a eficácia dos nomes dos casos de uso consiste em inquirir os clientes, os representantes de negócio, os analistas e os especialistas em desenvolvimento para verificar se todos eles compreendem os nomes e as descrições dos casos de uso. De igual modo, é necessário verificar se é claro o resultado observável, tomando como referência a perspectiva dos actores.

• Descrição breve do caso de uso

O caso de uso inclui uma descrição breve. Esta descrição deverá ter pelo menos um parágrafo, mas não mais do que três e deverá incluir uma explicação do propósito chave, da proposta de valor e dos conceitos chave do caso de uso.

• Fluxos de estilos de eventos

Os fluxos de caso de uso utilizam títulos para descrever os passos a um nível mais elevado, incluindo depois descrições numeradas daquilo que faz o actor e daquilo que faz o sistema no âmbito de cada título. Estes passos com base em títulos são referenciados em fluxos e subfluxos alternativos. Os títulos deverão estar a negrito e poderão ser formatados no Microsoft Word como títulos. Os subpassos (detalhes do caso de uso) são numerados dentro de cada passo (título), com a numeração a ter continuidade a partir do passo anterior.

• Fluxo básico

O primeiro passo da descrição do caso de uso começa com uma frase do tipo "O caso de uso começa quando o actor...". De cada vez que a interacção entre o actor o sistema muda de enfoque, o segmento seguinte de comportamento começa com um novo parágrafo. Deve-se começar com um actor e depois o sistema. Cada passo no fluxo de eventos deverá apresentar um percurso circular de eventos - do actor para o sistema e do sistema para o actor - normalmente sob a forma de mensagens:

* Aquilo que o actor faz: <Actor> mensagens <Sistema>
* Aquilo que o sistema faz em resposta: <Sistema> mensagens <Um Actor>

Ao fazermos com que cada passo seja um percurso circular estamos a assegurar a possibilidade de teste, a garantir a observância do propósito do caso de uso e a fazer com que os diagramas de sequência sejam muito mais fáceis de ler e de criar. O último passo do caso de uso termina com a frase "O caso de uso termina".

• Fluxos alternativos

Os fluxos alternativos são utilizados para documentar variantes usuais, casos anormais e fluxos excepcionais (de erro). Cada fluxo alternativo define, de forma explícita e clara, todos os pontos possíveis de entrada no fluxo e termina com todos os pontos possíveis de saída do fluxo. O fluxo alternativo também assinala explicitamente o ponto de saída e onde o actor continua para seguinte - ou seja, se o fluxo remete para um passo específico no fluxo básico, ou se termina. Os fluxos alternativos são descritos na sua própria secção e não dentro do fluxo básico. O fluxo básico não referencia qualquer fluxo alternativo.

Utilização dos fluxos alternativos

Um fluxo alternativo específico ocorre um passo específico do fluxo básico (ou outro). Um fluxo alternativo genérico pode ocorrer em qualquer lugar de um outro fluxo. No caso dos fluxos alternativos específicos é detalhada a seguinte informação:

* O local de início no fluxo, onde é desencadeado o fluxo alternativo.
* A condição que desencadeia o início.
* As acções realizadas no fluxo alternativo.
* Onde recomeça o fluxo básico (ou outro) depois de terminar o fluxo alternativo.

Se o caso de uso terminar no fluxo alternativo, deverá especificar-se claramente no fluxo alternativo que "O caso de uso termina".

No caso dos fluxos alternativos genéricos não existe local de início, uma vez que um fluxo deste tipo pode começar em qualquer local. Os fluxos alternativos referidos em descrições deverão ser identificados com texto a negrito e itálico.

• Subfluxos

Quando um fluxo de eventos fica sobrecarregado devido a um comportamento complexo, ou quando um único fluxo ultrapassa uma página impressa, podemos utilizar subfluxos de modo a melhorar a clareza e a gerir a complexidade. Os subfluxos também facilitam a reutilização de fluxos dentro do mesmo caso de uso. Os subfluxos são escritos movendo um grupo lógico e auto-suficiente de comportamento detalhado para um subfluxo e referenciando esse comportamento de forma resumida dentro do fluxo de eventos. Desta forma, podemos pensar num subfluxo como sendo uma "incorporação interna".

A diferença entre um fluxo alternativo e um subfluxo tem a ver com o facto do primeiro se inserir noutro fluxo. O fluxo em que se insere não tem conhecimento do fluxo alternativo. Um fluxo alternativo também pode recomeçar em qualquer local do caso de uso.

Quanto ao subfluxo, é invocado explicitamente a partir de um fluxo. Por outro lado, quando um subfluxo termina, regressa sempre à linha a partir da qual foi invocado. Em termos conceptuais, é similar à invocação de uma subrotina em algumas linguagens de programação. Os subfluxos não são listados como parte de um cenário. Por definição, se o fluxo que procede à invocação faz parte do cenário, o subfluxo também faz parte do mesmo cenário. Tal como acontece com qualquer outro fluxo, um subfluxo pode ter fluxos alternativos.

Utilização de subfluxos

Os subfluxos são descritos na sua própria secção do caso de uso. Têm um identificador à frente deles (S1, S2?) para facilitar a sua identificação como subfluxos. Um subfluxo é invocado explicitamente a partir de um fluxo. Quando um subfluxo termina, regressa sempre à linha a partir da qual foi invocado. Consequentemente, os subfluxos não precisam de uma linha a dizer onde regressam. Cada subfluxo define, de forma clara e explícita, todos os possíveis pontos de entrada no fluxo.

• Pré-condições e pós-condições

A especificação do caso de uso inclui um conjunto de condições, que se espera que sejam verdadeiras antes do início do caso de uso (pré-condições) e depois do caso de uso ter terminado (pós-condições). Convém sublinhar que um caso de uso pode terminar de várias formas, pelo que cada pós-condição deve ser descrita em função dessa realidade.

Utilização de pré-condições

As pré-condições descrevem o estado em que o sistema tem de estar antes do caso de uso poder ter início. Todas as pré-condições têm de ser verdadeiras. As pré-condições reduzem a necessidade de validação dentro do caso de uso, mas não podem ser utilizadas para descrever coisas externas ao sistema.

Utilização de pós-condições

As pós-condições descrevem o estado do sistema no final do caso de uso. As pós-condições são garantidamente verdadeiras no final do caso de uso, independentemente da forma como o caso de uso termina.

• Utilização de cenários

Os cenários representam uma instância de um caso de uso. São um fluxo ao longo de um caso de uso. Devem-se documentar todos os cenários necessários para compreender o sistema que está a ser desenvolvido. Os casos de uso de alto risco e aqueles que são significantes em termos arquitecturais têm de ser documentados.

• Utilização de glossário

Todas as expressões utilizadas num caso de uso são definidas no glossário do projecto. Se existir alguma expressão num caso de uso que não consta do glossário, essa expressão precisará de:

* Ser adicionada ao glossário, incluindo uma descrição breve (um parágrafo, no máximo);
* Ser alterada no caso de uso, de modo a reflectir a expressão correcta que estiver definida no glossário.

As expressões que são específicas de um determinado caso de uso podem ser definidas na secção de glossário desse caso de uso. Os itens definidos no glossário são apresentados de forma sublinhada.

Orientações adicionais

• Comportamento repetitivo e condicional

A utilização de expressões condicionais e repetitivas nos fluxos de eventos fazem com que seja difícil a identificação de cenários. Consequentemente, são proibidas. Todo o comportamento condicional e repetitivo tem de ser expresso em fluxos alternativos. Podem ser utilizados digramas de actividade para visualizar os fluxos alternativos. No entanto, as expressões que se seguem são permitidas em fluxos alternativos:

* SE - utilizada para expressar a condição sob a qual é executado o fluxo alternativo.
* RECOMEÇAR - utilizada para expressar onde o fluxo alternativo recomeça no caso de uso.

• Utilização consistente dos nomes dos actores

A especificação de caso de uso é escrita utilizando nomes de actor consistentes. Não nos devemos referir genericamente ao "actor". Em vez disso, devemos utilizar o nome real utilizado para identificar ou definir inequivocamente o actor. Deverá ter-se o cuidado de garantir que os nomes atribuídos aos actores são claros e sem qualquer ambiguidade. Os nomes dos actores são apresentados com texto formatado a negrito.

• Utilização consistente do imperativo

Os requisitos de sistema nos casos de uso são escritos utilizando imperativos. A expressão "terá" é preferível a "deverá" para descrever os requisitos de forma consistente. A utilização de expressões passivas que possam indicar que o requisito é opcional, bem como de expressões indefinidas (como "deveria", "possivelmente", "etc.") devem ser evitadas.

• Utilização de expressões de acção

Definir onde o sistema é responsável pela apresentação de uma opção de acção

O caso de uso estabelece explicitamente onde o sistema é responsável por apresentar uma acção como opção disponível para ser seleccionada pelo actor. Na maior parte dos casos, as opções disponíveis devem ser apresentadas como parte do fluxo básico e ser referenciadas como ponto de entrada na primeira declaração do fluxo alternativo correspondente.

Utilização consistente da expressão ao longo de todo o caso de uso

A utilização de expressões como Novo, Modificar, Cancelar, Apagar, OK e Imprimir são consistentes ao longo de todo o caso de uso. Ou seja, a mesma acção lógica não é referida utilizando uma terminologia diferente. É necessário ter cuidado para garantir que as expressões de acção utilizadas nos fluxos alternativos são as mesmas que são utilizadas no fluxo básico.

• Utilização de substitutos para detalhes em falta

Quando a informação ainda não foi definida ou ainda não está decidida, o caso de uso inclui uma referência ao elemento e inclui a abreviação de substituição "ASD" (a ser determinado ou a ser definido). Se a secção se destina a ficar em branco, indica-se isso com o substituto "Nenhum".

• Definição de e referência a especificações suplementares

Quando existem requisitos adicionais que não podem ser descritos naturalmente durante o fluxo de eventos, os mesmos são definidos como requisitos suplementares. No caso daqueles que são específicos a um caso de uso, são definidos na secção requisitos especiais da especificação do caso de uso. Os requisitos que são aplicáveis a todo o sistema, especialmente os de natureza não funcional, são definidos no documento separado de especificação suplementar.

• Interface com o utilizador

A interface com o utilizador não é especificada no caso de uso. Este último é agnóstico à interface com o utilizador.

Verificação com base no protótipo/desenho da interface com o utilizador

Os conteúdos do caso de uso são verificados com base no protótipo/desenho da interface com o utilizador, de modo a garantir que não faltam requisitos de sistema do caso de uso ou do protótipo/desenho da interface com o utilizador. Quando for necessário efectuar alterações ao caso de uso, este terá de ser actualizado para reflectir os requisitos em termos de desenho da interface com o utilizador.

Verificação do caso de uso

1. Questão: Cada caso de uso concreto está envolvido com pelo menos um actor?
Resposta: Se não estiver, algo está errado; um caso de uso que não interage com um actor é supérfluo e deverá ser removido.
2. Questão: Cada caso de uso é independente dos outros?
Resposta: Se dois casos de uso forem sempre activados na mesma sequência, devemos provavelmente fundi-los num só caso de uso.
3. Questão: Para um caso de uso incluído: faz conjecturas sobre os casos de uso que o incluem?
Resposta: Tais conjecturas devem ser evitadas, de modo a que o caso de uso incluído não seja afectado por alterações nos casos de uso que o incluem.
4. Questão: Alguns casos de uso têm comportamentos ou fluxos de eventos muito semelhantes?
Resposta: Se isso se verificar e se quisermos que o seu comportamento seja similar no futuro, devemos fundi-los num único caso de uso. Isto faz com que seja mais fácil introduzir alterações futuras. Convém ter em conta que temos de envolver os utilizadores se decidirmos fundir casos de uso, dado que os utilizadores que irão interagir com o novo caso de uso fundido serão provavelmente afectados.
5. Questão: Parte do fluxo de eventos já foi modelado sob a forma de outro caso de uso?
Resposta: Se sim, podemos fazer com que o novo caso de uso utilize o mais antigo.
6. Questão: Alguma parte do fluxo de eventos já faz parte de outro caso de uso?
Resposta: Se sim, devemos extrair esse subfluxo e fazer com que seja utilizado pelo caso de uso em questão. De referir que é necessário envolver os utilizadores se decidirmos "reutilizar" o subfluxo, dado que os utilizadores do caso de uso existente serão provavelmente afectados.
7. Questão: O fluxo de eventos de um caso de uso deve ser inserido no fluxo de eventos de outro caso de uso?
Resposta: Nesse caso, podemos proceder à modelação do caso de uso com um relação de alargar para outro.
8. Questão: Os casos de uso têm nomes únicos, intuitivos e descritivos, de modo a não poderem ser baralhados no futuro?
Resposta: Se isso não acontecer, temos de alterar os nomes.
9. Questão: Os clientes e os utilizadores compreendem os nomes e as descrições dos casos de uso?
Resposta: Cada nome de caso de uso tem que descrever o comportamento suportado pelo caso de uso.
10. Questão: O caso de uso satisfaz todos os requisitos que governam obviamente o seu desempenho?
Resposta: Temos de incluir qualquer requisito (não funcional) nos requisitos especiais do caso de uso para ser tido em conta nos modelos de objecto.
11. Questão: A sequência de comunicação entre o actor e o caso de uso está em conformidade com as expectativas do utilizador?
12. Questão: Está claro o modo e quando o fluxo de eventos do caso de uso inicia e termina?
13.  Questão: Poderá existir comportamento que seja activado apenas quando não se verifique uma determinada condição?
Resposta: Existe uma descrição daquilo que acontecerá se uma dada condição não se verificar?
14. Questão: Algum caso de uso é demasiado complexo?
Resposta: Se quisermos que o nosso modelo de caso de uso seja fácil de compreender, teremos que dividir os casos de uso complexos.
15. Questão: Um caso de uso contém fluxos de eventos diferentes?
Resposta: Se sim, será melhor dividi-lo em dois ou mais casos de uso separados. Um caso de uso que contenha fluxos de eventos diferentes será muito difícil de compreender e de manter.
16. Questão: O subfluxo de um caso de uso está modelado de forma fidedigna?
17. Questão: Não existem dúvidas sobre quem pretende executar um caso de uso? E o propósito do caso de uso também é claro?
18. Questão: A descrição breve dá uma ideia fidedigna do caso de uso?

Baseado em informação da IBM Rational.