Diagramas de Casos de Uso

Os Modelos de Caso de Uso são representações pictóricas do documento de requisitos, que têm como objetivo mostrar a funcionalidade do sistema, bem como a interação dos usuários com o mesmo [Belgamo, 2004]. Esses modelos são compostos pelo Diagrama de Casos de Uso e pelas Especificações dos Casos de Uso e são considerados uma técnica para capturar os requisitos funcionais de um sistema, descrevendo as interações típicas entre os usuários desse sistema e o próprio sistema, além de fornecer uma narrativa de como o sistema é utilizado [Fowler, 2005].

Conceitualmente, de acordo com Booch et al. (2000), um Caso de Uso é uma descrição de um conjunto de seqüências de ações, incluindo também as variantes dessas ações, que um sistema executa para produzir um resultado de valor observável por um ator. Graficamente, o Caso de Uso é representado como uma elipse.

Sendo assim, um Caso de Uso é um tipo de classificador que representa: uma unidade coerente de funcionalidade provida por sistema ou por um sub-sistema; uma ou mais interações desta unidade com componentes externos (representado pelos atores); ações realizadas pelo próprio sistema [UML 2003].

Todo Caso de Uso deve ter um nome único (uma seqüência de caracteres textuais) que seja capaz de diferenciá-lo dos demais Casos de Uso.

A Figura 2 mostra a representação de um Caso de Uso com o seu nome.

Figura 2 – Representação gráfica de um Caso de Uso Validar

Para mostrar a interação entre o Caso de Uso com entidades externas a ele existe a figura do ator.

Um ator representa um conjunto coerente de papéis que os usuários dos Casos de Uso desempenham quando interagem com esses Casos de Uso. O ator não precisa necessariamente desempenhar apenas o papel de algum usuário humano; ele também pode desempenhar o papel de um dispositivo de hardware ou até de um outro sistema que interage com o sistema em questão. Por isso Fowler (2005) afirma que “papel” seria o termo mais correto para o que hoje a comunidade de Engenharia de Software chama de “ator”.

Portanto, pode-se concluir que os Casos de Usos modelam aquilo que o sistema deve fazer enquanto os atores definem a interação de alguma coisa de fora com o sistema [Jacobson et al., 1992].

Schneider & Winters (2001) propõem algumas questões básicas para auxilio à identificação de atores no sistema, a saber:

• Quem usa o sistema? • Quem instala o sistema? • Quem inicia o sistema? • Quem mantém o sistema? • Quem finaliza o sistema?

• Quais outros sistemas fazem uso deste sistema? • Quem recebe informações do sistema?

• Quem envia informações para o sistema?

• Alguma coisa acontece automaticamente em um determinado tempo?

A representação de um ator acontece por meio de figuras estilizadas que lembram um ser humano caricato. Esse tipo de representação é o bastante para o ator, pois como ele representa alguma coisa externa ao sistema, não é necessário descrevê-lo em detalhes [Jacobson et al., 1992].

Existe a possibilidade de se definirem grupos gerais de atores que depois poderão ser especializados, como por exemplo, pode-se definir um ator pessoa, que generaliza um grupo

de pessoas qualquer, e depois especializar outros atores como funcionário, professor e aluno, usando o relacionamento de generalização, como é mostrado na Figura 3.

Figura 3 – Atores com relacionamento de generalização (adaptado de Boock et al., 2000)

O relacionamento de generalização é um relacionamento da UML que relaciona itens gerais em tipos mais específicos desses itens, ou seja, há a necessidade das partes que estão se relacionando serem de um mesmo tipo.

Cockburn (2001) inseriu uma forma de se classificar atores, a saber:

• Atores Primários: são aqueles que estão em constante contato com o sistema e por isso irão executar as principais tarefas do sistema. Este ator é freqüentemente aquele que aciona o Caso de Uso

• Atores Secundários: são aqueles que fazem o sistema funcionar através do fornecimento de um serviço para o mesmo. Sendo assim não estão em contato constante com o sistema e não costumam realizar as tarefas principais deixando isso para o ator principal. É importante identificar esses atores, pois a partir deles se identificam as interfaces externas que o sistema usará e os protocolos que cruzam esta interface.

A conexão entre os Casos de Uso e os atores acontece por meio de um relacionamento de associação. Este tipo de relacionamento é usado na UML como um relacionamento estrutural que especifica a conexão de objetos de um item com objetos de outro item. Quando usado para relacionar o Caso de Uso com o ator, essa associação indica que existe uma

Pessoa

Funcionário

Professor

comunicação entre esses itens, tendo cada parte a possibilidade de envio e recebimento de mensagens.

Os Casos de Uso podem ser relacionados entre si através de generalizações, inclusões ou extensões [Boock et al., 2000].

Em uma generalização de Casos de Uso o que acontece é que um Caso de Uso filho irá herdar o comportamento e significado do Caso de Uso pai e poderá acrescentar ou sobrescrever algum comportamento.

Para evitar a escrita de um mesmo fluxo de eventos várias vezes, existe a possibilidade da inclusão de Casos de Uso. Dessa forma, um Caso de Uso (que será chamado de Caso de Uso base), poderá incluir, em algum momento do seu fluxo de eventos, um outro Caso de Uso. Esse Caso de Uso incluído nunca poderá aparecer isoladamente sendo que no momento da inclusão o seu comportamento é explicitamente incorporado pelo Caso de Uso base que o está incluindo.

Um relacionamento de inclusão pode ser representado como uma dependência estereotipada com include. Dependência é um relacionamento de utilização definido pela UML. Exemplos de inclusão podem ser vistos na Figura 4.

Contudo, se o comportamento a ser incluído em um Caso de Uso não for obrigatório, ou seja, há um fluxo de evento no Caso de Uso base que não passa pelo Caso de Uso que esta sendo incluído, o que acontece então é uma extensão de um Caso de Uso. Sendo assim, o Caso de Uso base poderá aparecer isolado e, sob certas condições, seu comportamento poderá ser estendido pelo comportamento de um outro Caso de Uso. O relacionamento estendido é representado como uma dependência estereotipada como extend. Exemplos de extensão podem ser vistos na Figura 4.

Apenas o nome e a interação do Caso de Uso com atores não são suficientes para se descrever o comportamento desse Caso de Uso. É preciso algo que deixe claro o comportamento dos Casos de Uso para qualquer pessoa que precise entender o modelo. Para isso, elaboram-se as Especificações dos Casos de Uso. Na Especificação dos Casos de Uso, existe o que se chama de fluxo de eventos no qual se pode incluir como e quando o Caso de Uso inicia e termina, quando o Caso de Uso interage com os atores, quais objetos são

transferidos e o fluxo básico e alternativo do comportamento, também conhecidos como curso normal e curso alternativo.

Figura 4 – Casos de Uso e seus relacionamentos (adaptado de Boock et al., 2000) O fluxo de eventos de um Caso de Uso pode ser especificado de diversas formas: por meio de um texto estruturado informal, texto estruturado formal (com pré e pós condições), pseudocódigo, fluxograma, redes de Petri ou linguagens de programação [Sommerville, 2005].