Padrões de casos de uso (use case patterns)

Ao se projetar software usando casos de uso essenciais, observa-se que existem se- qüências de interação no fluxo de eventos que recorrem dentro do mesmo sistema e, mais importante ainda, em outros sistemas. Estes sistemas nem precisam ser do mesmo

44

domínio de negócio, pois podem ser tão diferentes quanto um sistema de controle de estoques e um sistema de controle de rede.

Ao investigar estas seqüências recorrentes no corpo dos casos de uso, constata-se que elas representam soluções para problemas particulares na modelagem de casos de uso: as seqüências são em comum porque elas fornecem soluções para problemas em comum ao modelar as interfaces dos sistemas com os atores que os rodeiam (Biddle et al., 2001).

Desta forma, é possível identificar padrões de casos de uso (use case patterns) (Sa- eki, 1999; Biddle et al., 2001; Overgaard & Palmkvist, 2005) que podem ser documen- tados e catalogados de forma semelhante a padrões de projeto (Gamma et al., 2000).

Entretanto, Biddle, Noble e Tempero (2001) salientam que os padrões de caso de uso estão filosoficamente mais próximos de padrões de análise (Fowler, 1997) do que de padrões de projeto, pois da mesma forma que os padrões de análise, esses padrões também descrevem artefatos de análise ao invés de projetos OO. Mas há uma diferença básica entre padrões de casos de uso e padrões de análise: padrões de casos de uso es- senciais descrevem padrões em casos de uso essenciais (diálogos característicos de in- tenções de usuário e responsabilidades do sistema) enquanto que os padrões de análise descrevem padrões em modelos no negócio de domínio.

Um padrão de caso de uso é aquele que pode ser reusado em função de representar uma tarefa (orientado a tarefa) ou um domínio (orientado a domínio) recorrente a vários sistemas.

Procura-se, sempre que possível, definir padrões de casos de uso parametrizados, ou seja, a parametrização do texto da narrativa do caso de uso de forma a aumentar as chances de reuso. Parâmetros tornam localizadas as referências específicas ao sistema ou ao domínio da aplicação para o qual ele foi criado e possibilita que o mesmo caso de uso possa ser usado em situações diferentes.

De uma forma geral, os padrões de casos de uso orientados a tarefas são mais facil- mente parametrizáveis e reusáveis do que padrões de casos de uso orientados a domí- nios.

Para transformar as descrições de seqüências de interação em um padrão de caso de uso é preciso analisar as forças agindo no caso de uso, ou seja, as considerações impor- tantes que estão impactando no caso de uso (Alexander et al., 1977). Para os padrões de caso de uso essenciais, as forças capturam características da interação entre o ator e o sistema: questões de iniciativa, fluxo de informação e usabilidade. Cada padrão tem conseqüências positivas e negativas em algumas destas forças.

Um exemplo de padrão de caso de uso é apresentado na figura 3.16, o “Caso de uso de Alarme”. O problema que este padrão resolve é escrever um caso de uso essencial que modele uma interação onde o sistema precisa notificar um ator sobre um evento importante, tal como uma mudança no seu estado interno ou uma potencial violação de uma regra de negócio.

45

Caso de uso de alarme

Como você faz o sistema informar o usuário sobre algo?

Forças

O sistema precisa chamar a atenção do usuário para uma mudança no seu estado in- terno.

O sistema está prestes a quebrar uma regra de negócio.

A notificação deve ser assíncrona, ou seja, os atores não devem ter que disparar o caso de uso.

Portanto: Escreva um caso de uso que comece com o sistema tendo a responsabilidade de avisar o usuário.

Exemplo

Avisa início de Apresentação

Intenção do usuário Responsabilidade do sistema

emite sinal de “apresentação vai começar” mostra o nome, teatro e tempo da

apresentação

Conseqüências

+ O sistema assume a responsabilidade por iniciar o caso de uso. + O sistema pode passar informação sobre o alarme para o ator.

+ O ator não tem que interromper imediatamente a tarefa que estiver fazendo para responder ao alarme.

- O ator pode ignorar o alarme.

Variante

Se o alarme é importante, você pode precisar incluir um passo de confirmação:

Avisa lotação esgotada

Intenção do usuário Responsabilidade do sistema emite sinal de “lotação esgotada”

mostra o nome, teatro e data e hora da apresentação

confirma o aviso

Esta variante tem as seguintes conseqüências diferentes do padrão principal:

- O ator não pode continuar com a tarefa que está fazendo: ele deve interrompê-la para con- formar o alarme.

+ O ator não pode ignorar o alarme

Figura 3.16: Exemplo de padrão de caso de uso. Fonte: Biddle et al. 2001

46

Um catálogo de padrões de caso de uso é muito útil para construir facilmente descri- ções de caso de uso. Os padrões dependem de domínios de problema, daí que é necessá- ria uma técnica que mostre como extrair padrões de caso de uso como componentes reusáveis das reais descrições de caso de uso, e como armazená-las em um tipo de sis- tema de base de dados, chamado de base de padrões (Saeki, 1999).

Um dos problemas com os padrões de casos de uso é o de encontrar um padrão de caso de uso que corresponda à funcionalidade sendo modelada (catalogação e pesquisa). Vários autores propõem mecanismos para minimizar este problema. Woo e Robinson (2002), por exemplo, propõem que, a partir de uma especificação da narrativa de um caso de uso em um diagrama da UML (diagrama de atividades, por exemplo), seja pos- sível submeter este diagrama como se fosse uma “query” e recuperar todos os casos de uso que contenham uma seqüência de interação o mais próxima possível da narrativa original. Isto não permite que a narrativa seja reusada (já que foi preciso descrevê-la antes de submeter a “query”) mas pode levar ao reuso da realização do caso de uso a partir das especificações do caso de uso padrão encontrado.