Descrição Textual de Casos de Uso
Rui GomesInstituto Politécnico de Viana do Castelo, Escola Superior de Tecnologia e Gestão Apartado 574, 4900 Viana do Castelo, Portugal
email: rgomes@estg.ipvc.pt
Resumo
Tendo em consideração a utilização dos casos de uso na captura de requisitos funcionais de um sistema informático e a sua descrição como um formulário textual, pretende esta comunicação clarificar um conjunto de conceitos relevantes para essa descrição. Para tal, apresenta-se a comparação de duas propostas, com base nos conceitos parte interessada, actor, domínio de projecto, nível de objectivo, cenário, estado do sistema e ligação dos casos de uso, finalizando-se com um conjunto de valores-chave e variantes para a escrita de casos de uso.
Palavras chave: domínio do projecto, nível de objectivo, actor, cenário, caso de uso.
1 Introdução
Os casos de uso têm sido utilizados tanto para descrever um processo do negócio [Jacobson 1995] como para desempenhar vários papéis nas actividades de desenvolvimento de software [Jacobson 1993, 1997 , Booch et. al 1999]. A “Unified Modelling Language” [Booch et. al. 1999], define um caso de uso como “ uma descrição de um conjunto de sequências de acções, incluindo variantes, que um sistema desenvolve para entregar um resultado de valor observável a um actor”, e um actor como “representando um conjunto coerente de papéis que os utilizadores dos casos de uso desempenham quando interagem com os mesmos”. Durante a captura e análise de requisitos de um sistema, o modelo de caso de uso desenvolvido é constituído por actores e casos de uso, figura 1.
Figura 1 - Modelo de Caso de Uso Caso de Uso 3 Actor1 Caso de Uso 1 Actor 3 Caso de Uso 2 Actor 2
Para cada combinação actor-caso de uso deverá haver uma descrição do comportamento dinâmico, mostrando como instâncias do actor interagem com instâncias do caso de uso. A esta descrição chama Jacobson [Jacobson 95], descrição do caso de uso, mesmo considerando que também descreve o comportamento do actor, e fá-la utilizando linguagem natural. O modelo conceptual de caso de uso é, por conseguinte, uma descrição textual de cenários conducentes à consecução ou falha de um objectivo do actor.
Tendo em consideração a utilização dos caso de uso na captura de requisitos funcionais e alguns problemas que a sua descrição textual apresenta em relação à definição e consistência da fronteira do sistema, à complexidade do modelo de caso de uso, à dimensão e granularidade da sua especificação e à sua complitude e dificuldade de compreensão apresenta-se, na primeira parte desta comunicação, uma comparação de duas propostas de escrita de casos de uso tendo por base um conjunto de conceitos que contribuem para minorar os problemas referidos. Numa segunda parte referem-se um conjunto de valores-chave e variantes consensuais à comunidade que trabalha na escrita de casos de uso.
2 Comparação de propostas para descrição textual de casos de uso
A descrição textual de casos de uso tem subjacente um modelo e conceitos, tendo-se identificado como mais utilizados, parte interessada, actor, domínio de projecto, nível de objectivo, cenário, estado do sistema e ligação de casos de uso. Com base nesses conceitos compara-se a descrição de um caso de uso proposta pela Rational em “The Unified Software Development Process” [Booch et. al 1999] e por Geri Schneider e Jason Winters em “Applying Uses Cases”[Schneider et. al. 1998], que passarei a designar como Proposta 1 (P1), com a apresentada por Alistair Cockburn em “Writing Effective Use Cases” [Cockburn 2000], que designarei por Proposta 2 (P2), mostrando, nas figura 2 e figura 3 os formatos de apresentação respectivos.
Figura 2 – Formato de Apresentação
Figura 2 – Formato de Apresentação de P1 Título do Caso de Uso: <o objectivo>
Descrição breve < poucas frases resumindo as acções>
Actores < Uma lista de actores que comunicam com o caso de uso> Iniciadores < o que inicia o caso de uso>
1. Fluxo de Eventos
Fluxo Básico < série de afirmações declarativas que listam os passos do caso de uso.> a. ...
Fluxos Alternativos < alternativas ao caminho básico> a. ...
2. Requisitos Especiais < outros requisitos não descritos no caso de uso >
3. Pré-Condições < condições que devem ser verdadeiras antes do iniciar o caso de uso > 4. Pos-Condições < condições que deve ser verdadeira quando o caso de uso finaliza > 5. Pontos de Extensão <pontos da descrição em que são permitidas extensões >
Figura 3- Formato de Apresentação de P2
2.1 Modelo
O modelo “Actor-Objectivo” utilizado pela P1 é complementado em P2 com a ênfase nas falhas de objectivos e formas de as colmatar por parte do sistema, figura 4, e pela consideração das Partes Interessadas, figura 5 . Este modelo das “Partes Interessadas & Interesses” tem como vantagens responder às questões das “Partes Interessadas” não-actores e às correspondentes responsabilidades do sistema para com as mesmas, e indicar, de uma forma mais precisa, o que incluir e excluir na escrita do caso de uso, conduzindo, por conseguinte, a casos de uso mais precisos.
Figura 4 - Modelo Actores & Objectivos Caso de Uso: <número> <o nome deverá ser o objectivo>
Domínio: <âmbito do projecto>
Nível: < sumário, objectivo-do-utilizador, subfunção> Actor Primário: <o nome de um papel para o actor primário>
Partes Interessadas & Interesses: <as entidades com interesse e os interesses chave no caso de uso> Pré-condição: <o que se espera que já seja o estado do mundo>
Garantia de Sucesso: <interesses das “Partes Interessadas” satisfeitos após a conclusão com sucesso do caso de uso>
Garantia Mínima: <compromissos mínimos que o sistema estabelece com as “Partes Interessadas> Iniciador: <o que inicia o caso de uso>
Cenário Principal de Sucesso
< os passos desde o início até à consecução do objectivo> <passo#><descrição da acção>
Extensões
<extensões, referindo-se cada a um passo do cenário principal> <passo alterado> <condição> : <acção ou sub-caso de uso>
Figura 5 - Modelo Partes Interessadas & Interesses
2.2 Conceitos
2.2.1 Parte Interessada
P1 não faz referência a este conceito, definindo-o P2 como alguém com direitos adquiridos no comportamento do caso de uso, mesmo que nunca interaja com o sistema. A “Parte Interessada” surge como a diferença fundamental em relação a P1 pois este só considera entidades que interagem directamente com o sistema.
2.2.2 Actor
P1 define “Actor” como representando um conjunto coerente de papéis que os utilizadores dos casos de uso desempenham quando interagem com os mesmos, desempenhando um actor um papel para cada caso de uso com quem estabeleceu uma associação de comunicação. P2 considera “Actor Primário” e “Actor de Suporte”, definindo “Actor Primário” como a parte interessada que pede ao sistema para realizar um dos seus serviços, e “Actor de Suporte” um actor externo que fornece um serviço ao Sistema em Projecto.
2.2.3 Domínio de Projecto
P1 refere que os caso de uso também podem ser utilizados para modelar o negócio, contudo, não lhe dá relevância no formato de apresentação da descrição do caso de uso.
P2 chama a atenção para o domínio do projecto, o conjunto de sistemas, organização ou software e/ou hardware que se está a projectar ou discutir, e classifica-o como “Companhia”, “Sistema” ou “Subsistema”. O domínio “Companhia” discute o comportamento da organização no seu todo ou em parte, tendo em vista a realização do objectivo do actor primário. O domínio
“Sistema”, discute a peça de software/hardware que temos a responsabilidade de construir, não considerando os interfaces com os quais temos de interagir e o domínio de “Subsistema” significa que abrimos o sistema principal, e falamos da forma como trabalha uma parte dele.
2.2.4 Nível de Objectivo
P1 não considera o “Nível de Objectivo”, não clarificando o objecto de descrição do caso de uso. P2 considera que as interacções num cenário podem ser desdobradas em interacções cada vez mais pequenas, correspondentes a objectivos que o actor deseja atingir e considera 3 níveis: “Objectivo-do-utilizador”, o “Sumário” e o de “Sub-função”. O “Objectivo-do-utilizador” corresponde ao objectivo do actor primário tentando realizar o seu trabalho (“processo elementar do negócio”). O “Sumário” envolve múltiplos objectivos ao nível do utilizador e, no respeitante à descrição do sistema, contribui para mostrar o contexto nos quais operam os objectivos do utilizador, a sequencialização do ciclo de vida de objectivos relacionados e um índice para os casos de uso de mais baixo nível. O nível “Sub-função” é necessário para consecução dos “Objectivos-do-utilizador”, só sendo incluído à medida que é necessário.
2.2.5 Cenário
P1 define cenário como uma sequência específica de acções que ilustra um comportamento e um caso de uso como um conjunto de sequências. Para casos de usos complexos, sugere que se comece por escrever o “Cenário Primário” correspondendo ao caminho básico, sequência de passos mais comum e, a seguir, os “Cenários Secundários” correspondendo às alternativas ao fluxo de eventos, utilizando ramificação e fluxos alternativos. Para os casos de uso simples não são necessários cenários, basta considerar o fluxo de eventos para o caminho básico (caminho seguido mais vulgarmente, com poucas excepções e particularidades) e o fluxo de eventos para o caminho alternativo ao caminho básico. P2 fala em “Cenário Principal de Sucesso”, definindo-o como um cenário típico, fácil de compreender, no qual são satisfeitos o objectivo do actor e todos os interesses das “Partes Interessadas” e apresenta a seguinte estrutura:
- uma condição sob a qual o cenário se desenrola - um objectivo a atingir
- um conjunto de passos acção (corpo do cenário) - uma condição final
Tendo em consideração a importância dada pela proposta P2 às falhas de objectivos e de resposta, podemos dizer que a principal diferença desta em relação à P1 está na forma como adiciona outros cenários ao cenário principal de sucesso. A proposta P2 aconselha que não se escrevam os cenários individuais (para sucesso e falha), mas sugere que se escreva o cenário principal de sucesso como uma simples sequência com início e fim, e um cenário de extensão para cada ponto de ramificação, figura 6 .
A extensão inicia-se com uma condição, a condição de extensão, representada por 6a. na figura 6, e apresenta uma sequência de passos-acção descrevendo o que sucede sob essas condições, podendo ainda haver extensões aos mesmos. A extensão pode finalizar com a entrega ou abandono do objectivo da extensão.
As extensões, o seu tratamento e as falhas no interior de outras falhas vão permitir que se descrevam no mesmo caso de uso os vários cenários e não se tenham que considerar como em P1, um cenário primário separado dos cenários secundários.
Figura 6 – Caso de Uso “Registar dano”
No que se refere à escrita do fluxos de eventos, P1 não dá linhas orientadoras, apenas refere que a sua escrita deve estar adaptada ao tipo de leitor podendo ser escrito em texto informal ou pseudocódigo, sendo de salientar que P2 fornece um conjunto de linhas orientadoras para a escrita de um passo acção:
Caso de Uso: Registar dano ...
...
Cenário Principal de Sucesso 1.
...
6. Empregado confirma que terminou, Sistema grava. Extensões
6a. Empregado confirma que terminou sem completar informação miníma:
6a.1 – Sistema previne Empregado que não pode aceitar o dano sem data, nome do segurado ou número da apólice e atribuir regularizador de sinistros
6a.2. - Empregado decide continuar a introduzir dano. 6a.3. – Empregado grava um relato intermédio e sai.
6a.3.a Empregado insiste no existente sem introduzir informação mínima: 6a.3.a.1 – Sistema renuncia qualquer gravação intermédia e sai
- A frase deverá utilizar uma gramática funcional, apresentando uma estrutura simples: "Sujeito... verbo...complemento directo... expressão preposicional".
- A frase deve mostrar claramente “Que actor passa a mensagem e dados para outro actor”.
- Escrever, a partir de uma visão geral, as acções de todos os actores. Não escrever o caso de uso como visto pelo sistema (interior para o exterior).
- A frase deve mostrar o avanço claro do processo.
- A frase deve mostrar a intenção do actor, não as suas actividades com vista à consecução daquela intenção (semântica, não diálogo).
- As 4 partes de uma interacção composta podem colocar-se num passo acção; contudo, podem ser distribuídas por dois ou mais passos acção.
- Deve escrever-se “valide” e não “teste se”. As frases “teste se” não contribuem para que o processo avançe claramente.
- A referência ao tempo é opcional.
- O actor primário deve indicar o momento em que quer que o sistema em projecto desenvolva uma determinada acção em relação a um actor de suporte.
- Se na descrição tivermos vários passos repetidos, a repetição escrever-se-á
imediatamente a seguir; se houver um só passo a repetir, considera-se no próprio passo.
2.2.6 Estado do sistema
P1 considera que é necessário definir o estado do sistema no início do caso de uso, a chamada “Pré-Condição” e o estado do sistema no final do caso de uso, a “Pós-Condição”, sendo este de sucesso independente do ramo ou alternativa seguida pelo caso de uso.
P2 define a “Pré-Condição” como uma condição reconhecida como verdadeira antes do início do caso de uso, não necessitando de voltar a ser validada e a “Garantia de Sucesso” como os interesses das “Partes Interessadas”, satisfeitos após a conclusão com sucesso do caso de uso, quer no final do cenário principal de sucesso quer de um caminho alternativo de sucesso. Pela descrição anterior, há semelhança entre os estado de sistema das duas propostas, contudo, P2 considera ainda as “Garantias Mínimas”, definindo-as como os compromissos mínimos que o sistema estabelece com as “Partes interessadas”, particularmente quando não podem ser satisfeitos os objectivos do actor primário, sendo estas importantes quando o objectivo principal é abandonado. Por exemplo, no caso de uso “Registar dano” para uma Seguradora, uma “Garantia Mínima” será “Se não for capturada a informação mínima, não é considerada a reclamação parcial e não é realizado nenhum “log” do pedido”.
2.2.7 Ligação dos Casos de Uso
P1 propõe que se utilize relacionamentos “Inclusão”, “Extensão” e “Generalização”. O relacionamento de “Inclusão” significa que o caso de uso base incorpora, explicitamente, o comportamento de um outro caso de uso numa localização especificada no caso de uso base; o relacionamento “Extensão” significa que o caso de uso base incorpora, implicitamente, o comportamento de um outro numa localização especificada indirectamente pelo caso de uso extendido e o relacionamento “Generalização” significa que um caso de uso de mais baixo nível pode especializar um caso de uso de mais alto nível. No estilo puramente textual de P2, cada ou todos as expressões de objectivo são uma potencial referência a um outro caso de uso, podendo um caso de uso incluir um outro, o “Sub-Caso de Uso”. No que se refere ao relacionamento de “Extensão”, considera que só em casos especiais é que é necessário criar um caso de uso para o cenário de extensão, tendo este que referir especialmente partes internas do caso de uso de base. No que se refere ao relacionamento de “Generalização”, sugere que não se deve combinar especialização de actores com especialização de casos de uso. Para concluir, P2 refere que a escrita de casos de uso baseados em texto não enfrenta os problemas referidos para os relacionamentos de generalização.
2.3 Pontos
Relevantes
Da comparação das propostas são de salientar como pontos relevantes da proposta P2 em relação ao modelo e aos conceitos:
Modelo
-
O modelo “Actor/Objectivo” dá ênfase às falhas de objectivos e respostas, contribuindo para clarificar o comportamento do sistema e por conseguinte a captura de requisitos funcionais do mesmo.-
O modelo “Partes Interessadas/Interesses” considera como actor não só o utilizador que interage directamente com o sistema mas outras partes interessadas no sistema, o que melhora a captura de requisitos para o mesmo.Conceitos
-
As “Partes Interessadas” são importantes para os requisitos do sistema. O caso de uso é uma forma de contrato, no qual são reconciliados os possíveis interesses conflituosos de todos as partes interessadas. A consideração das “PartesInteressadas” vai permitir que o sistema adquira responsabilidades correspondentes às entidades que não interagem directamente com o caso de uso, clarificando o que incluir e excluir na sua escrita.
-
O “Domínio de Projecto” é importante para clarificar o que se está a projectar, se estamos a falar da organização, do sistema de software e/ou hardware.-
O “Nível de Objectivo” vai ajudar a clarificar a complexidade (granularidade) da interacção do actor com o caso de uso, pois os objectivos e as interacções num cenário podem ser desdobrados em objectivos e interacções mais finas, causando confusão na descrição.-
A descrição das “Extensões” no “Cenário Principal de Sucesso” vai facilitar a leitura (caminhos de sucesso ou de falha) e o trabalho de escrita no caso de casos de uso complexos, não conduzindo a uma proliferação de cenários.-
Apesar de se poder escrever de diferentes formas os passos-acção, a proposta alerta para um conjunto de características a preservar na escrita dos mesmos.-
As “Garantias Mínimas” permitem garantir que os interesses das “Partes Interessadas” vão ser protegidos no caso de falha do objectivo.3
Valores-Chave e Variantes
Ainda que vários autores refiram para a escrita de casos de uso, orientações diferentes das tratados anteriormente, a comunidade envolvida no seu desenvolvimento [Anderson et. al 1998, Lilly S. 1999, Firesmith´s D. 1999] está de acordo sobre os seguintes valores-chave e variantes:
Valores-Chave
-
Os casos de uso são uma forma de descrição comportamental que pode ser utilizada em vários momentos de um projecto e com vários objectivos.-
Os casos de uso devem ser de fácil leitura.-
Os casos de uso estão centrados nos objectivos dos actores primários, e nos sub-objectivos de vários actores, incluindo o Sistema em Projecto na consecução daquele objectivo.-
O caso de uso é escrito como um relato de um jogo (de fora para dentro), mencionando os actores na descrição das acções.-
Quando utilizado como uma técnica de especificação funcional, o Sistema em Projecto é sempre tratado como uma caixa-preta.-
Os caminhos alternativos de descrição dos casos de uso devem ser indicados depois do cenário principal de sucesso.-
A correcção e adição das extensões aos casos de uso adicionam valor; contudo, o dispêndio de demasiados recursos nesta tarefa só se justifica em projectos críticos.Variantes Adequadas
-
Passos numerados ou parágrafos simples.-
Casos de uso simplificados ou mais completos.-
Frases completas ou diálogo entre actores (texto teatral).-
Modelação precedente do negócio com ou sem casos de uso.-
Diagramas de caso de uso ou lista de actor-objectivo.Variantes não Adequadas
-
Declarações “Se” no interior do cenário principal.-
Interface gráfico de utilizador na especificação funcional.4 Conclusão
Os casos de uso têm sido utilizados com várias finalidades e deles têm sido apresentadas tanto descrições textuais como visuais. Tendo em consideração a utilização dos casos de uso na captura de requisitos funcionais e os problemas identificados na sua descrição textual, pretendeu-se clarificar o modelo e os conceitos mais relevantes para essa descrição, comparando as Proposta 1 e Proposta 2, e apresentar alguns valores chave e variantes consensuais para a comunidade envolvida na descrição textual de casos de uso.
Para uma melhor compreensão das características dos formatos de apresentação dos casos de uso, seria enriquecedor ver como outros modelos de comunicação, além dos referidos, contribuem para essa representação no âmbito da sua aplicabilidade à captura de requisitos funcionais dos sistemas informáticos.
5 Referências
Anderson B., Cockburn A., Flower M., Graham I., Jacobson I., “Question Time! About Use Cases”, OOPSLA 1998, pp.226-229..
Booch G., Rumbaugh J., Jacobson I., The Unified Modeling Language User Guide, Addison-Wesley, 1999.
Booch G., Rumbaugh J., Jacobson I., The Unified Software Development Process, Addison-Wesley, 1999.
Cockburn A., Writing Effective Use Cases, Addison-Wesley, 2000.
Firesmith´s D., “Use Case Modeling Guidelines”, TOOLS’99 USA, Santa Barbara, CA, 1999. Jacobson I., “Modeling with Uses Cases: Formalizing use-case modeling”, JOOP, 8(3), 1995. Jacobson I., Christerson M., Jonsson ¨P. and Övergaard G., Object-Oriented Software Engineering:
A Use Case Driven Approach. Addison-Wesley,1993.
Jacobson I., Ericsson M., Jacobson A., The Object Advantage-Business Process Reengineering with Object Technology. Melo Park, CA: Addison-Wesley, 1994.
Lilly S., “Uses Cases Pitfalls: Top 10 Problems from Real Projects Using Uses Cases”, TOOLS’99 USA, Santa Barbara, CA, 1999, pp.115-125.
