O modelo adotado para a descrição dos casos de uso do Diliframe é apresentado na Tabela 21. As linhas em destaque indicam os títulos de cada etapa, informando, ainda, se são elas opcionais ou não; as linhas subseqüentes apresentam uma breve descrição do propósito de cada uma.
1. Descrição de Caso de Uso Título do caso de uso.
2. Finalidade
Objetivo a ser atingido ou ação a ser desempenhada com a realização do caso de uso.
3. Atores
Lista de atores envolvidos no caso de uso.
4. Pré-condições (opcional)
Condições que devem ser satisfeitas para que o caso de uso tenha início.
5. Fluxo Principal
Seqüência típica de eventos na interação entre atores e sistema.
6. Fluxos Alternativos (opcional)
Qualquer decisão ou variação alternativa ocorrida na seqüência do fluxo principal.
171 Possíveis situações de erro ocorridas durante o fluxo principal.
8. Pós-condições (opcional)
Resultados obtidos após a realização do caso de uso.
9. Testes sugeridos (opcional)
Sugestão de ações a serem realizadas na fase de testes.
Tabela 21 – Modelo de Caso de Uso
A seguir, a semântica e a forma de apresentação do modelo proposto serão discutidas com mais detalhes:
• Descrição de casos de uso
Nesta etapa, é identificado o título do caso de uso. É importante que o nome seja único e sugestivo a fim de informar, prontamente, o que será descrito pelo caso de uso. Recomenda-se que sejam usados verbos no infinitivo no título do caso de uso.
• Finalidade
A etapa relativa à finalidade do caso de uso deve descrever o objetivo de negócio a ser atingido com a realização do mesmo. De forma simples e direta, informar ao leitor qual o cenário de interação com o sistema que este caso de uso pretende descrever. • Atores
Nesta etapa, são listados os atores envolvidos no caso de uso. Recomenda-se grafar o nome dos atores com suas iniciais maiúsculas para que seja facilitada a sua identificação no texto [Larman, 1998]. Opcionalmente os atores podem ser classificados como primários e secundários [Coleman, 1998]. Um ator primário atinge determinado objetivo contando com a assistência do sistema. Já um ator secundário atua na assistência do sistema para que este cumpra alguma tarefa.
• Pré-condições
Diz-se das pré-condições de um caso de uso, os requisitos para que este possa ter início. Estes pré-requisitos têm origens bastante distintas e podem não depender da ação dos atores do caso de uso em questão. Uma lista de pré-condições pode conter, por
172 exemplo: acionamento de uma opção de menu, finalização de uma certa transação, finalização de determinado período de tempo, alimentação de alguns dados de entrada, etc. • Fluxo Principal
Nesta etapa, é relatada a interação dos atores com o sistema. Todos os passos necessários a fim de que o objetivo seja atingido são listados na ordem em que acontecem: a ação do ator e a resposta do sistema. Havendo a necessidade de iteração dos passos o autor deve fazê-lo em linguagem natural.
Cada passo do fluxo deve ser identificado por um número seqüencial. Esta identificação pode ser usada nos fluxos alternativos para o restabelecimento da seqüência de ações. Em seguida, vem a identificação do evento que pode ser uma ação do ator ou uma resposta do sistema. Os passos podem ou não ser acompanhados de exceções ou passos alternativos. Passos alternativos serão descritos na etapa de fluxo secundário. As exceções serão aprofundadas na sua seção correspondente. O caso de uso é finalizado quando não há mais passos a serem executados no fluxo principal ou quando um passo direciona o fluxo para outro caso de uso.
O formato de apresentação de um item do fluxo principal é o seguinte:
P* = P*.<número identificador><ação do ator | resposta do sistema ><E>*|<PA>*
onde:
PA = “Passo Alternativo” P = “Passo”
E = “Exceção”
• Fluxos Alternativos
A etapa de fluxos alternativos lista a seqüência de passos alternativos que podem ser gerados para cada item do fluxo principal. Um passo alternativo é criado quando existe uma tomada de decisão no fluxo principal. Os passos alternativos têm o mesmo formato dos passos no fluxo principal, acrescidos da opção de informar para qual passo se deseja retornar a fim de dar continuidade ao processo.
Não obstante, é recomendado não gerar passos alternativos de passos alternativos. Isto comprometeria o bom entendimento do caso de uso. Além do mais, o objetivo desta etapa não é esgotar todas as possibilidades de interação do sistema, mas, tão
173 somente, realizar uma análise do comportamento do sistema e de seus requisitos de forma mais detalhada.
O formato de apresentação de um item do fluxo alternativo é o seguinte:
PA = PA.<número identificador>
<número sequencial><ação do ator | resposta do sistema > <E>*|<PA>*|<P>*
onde: PA = “Passo Alternativo” P = “Passo”
E = “Exceção”
• Exceções
Nesta etapa, são listadas as exceções que podem ocorrer em cada um dos passos dos fluxos principal e alternativo. As exceções são caracterizadas por comportamentos diferentes dos esperados. Isto pode ter origem a partir de dados de entrada, ações do ator ou sub-sistemas com funcionamento anormal.
Prever exceções, na fase de análise de casos de uso, é interessante e muito útil. As exceções, identificadas nesta fase do processo de desenvolvimento, não estão relacionadas à estrutura interna de implementação, e sim ao domínio da aplicação. Isto sugere que o projetista deve reservar-lhes uma atenção especial nas fases subseqüentes do processo.
Na descrição de uma exceção, deve constar a situação que a desencadeia. Em seguida, é listada uma seqüência de passos de interação podendo resultar em uma das seguintes situações: retorno ao fluxo alternativo, retorno ao fluxo principal, ou ainda a finalização do caso de uso.
O formato de apresentação de um item de exceção é o seguinte:
E = E.<número identificador><descrição da situação de exceção>
<número sequencial><ação do ator | resposta do sistema > <PA>*|<P>*
onde: PA = “Passo Alternativo” P = “Passo”
E = “Exceção”
174 Nesta etapa, são apresentadas as atividades cumpridas ao final do caso de uso. É retratado o resultado final obtido do processo de interação do ator com o sistema. Esta etapa é considerada opcional, pois, normalmente, os casos de uso descrevem ações pontuais cujos resultados esperados já foram descritos na etapa relativa à finalidade. Recomenda-se, então, listar pós-condições de um caso de uso, apenas quando isto não for redundante. • Testes Sugeridos
Nesta etapa, são listadas algumas situações críticas que devem ser consideradas na fase de testes. Assim como a etapa de exceções, a etapa de testes sugeridos não tem pretensão de esgotar todas as possibilidades de testes a serem empreendidos.
O objetivo desta etapa é antecipar comportamentos que podem originar erros no sistema. A previsão de testes, nesta fase do processo de desenvolvimento, denota a preocupação com a qualidade do sistema em desenvolvimento. Os testes sugeridos nesta etapa da descrição dos casos de uso podem ser utilizados como base na elaboração dos planos de teste da aplicação.
175