Casos de Uso: Diagramas e especificações

Engenharia de Software | Linguagem de modelagem unificada (UML) | Casos de Uso: Diagramas e especificações

Levantamento de requisitos

A atividade de levantar requisitos é de fundamental importância para todo o processo de desenvolvimento de sistemas. O sucesso do produto final, o software que será desenvolvido, depende de um correto levantamento de requisitos.

Levantar requisitos implica em sabermos o que o sistema precisa fazer para atender as necessidades de seus usuários. A qualidade do levantamento de requisitos influenciará todo o processo de desenvolvimento, especialmente as validações junto aos usuários, necessárias ao longo do processo de desenvolvimento e sobretudo na adequação do software.

O levantamento de requisitos visa identificar dois tipos de requisitos:

• Os requisitos funcionais são as funções que o sistema precisa ter.
• Os requisitos não funcionais são os atributos e propriedades do sistema.

Exemplos dos requisitos a serem levantados

Requisitos funcionais

Como exemplos de requisitos funcionais para um sistema de folha de pagamento, podemos enumerar:

• Cálculo da folha de pagamento;
• Cadastramento de funcionários;
• Cadastramento da tabela de imposto de renda;
• Emissão do recibo de pagamento, entre outras funções necessárias ao sistema.
• Requisitos não funcionais

Como exemplos de requisitos não funcionais, que, obviamente, não são funções do sistema, podemos citar:

• Tempo de resposta – o cálculo da folha de pagamento não pode demorar mais que 15 segundos;
• Interface – deve ser composta de janelas de diálogo de fácil entendimento;
• Tipo de ambiente – o sistema precisa estar acessível 24h por dia, nos 365 dias do ano, denotando que precisa ser um sistema voltado para a internet.
• Principal finalidade do diagrama de casos de uso

O diagrama de casos de uso é um dos mais informais e simples dentre os propostos pela UML. Sua principal finalidade é apresentar as principais funcionalidades que o sistema precisa ter; em outras palavras, apresentar os requisitos funcionais do sistema. Ou seja, é um diagrama que começa a ser usado após o levantamento de requisitos de forma a mapear as funcionalidades do sistema, documentar o que o sistema faz.

Esse diagrama é, geralmente, derivado do documento de especificação de requisitos (que não pertence à UML) ou de outro documento que relacione as principais necessidades dos usuários do sistema.

Outra finalidade do diagrama de casos de uso

Outra finalidade do diagrama de casos de uso é possibilitar que os requisitos possam ser validados junto aos usuários para se certificar que:

• Todos os requisitos funcionais tenham sido identificados;
• O entendimento da equipe de desenvolvimento, no que tange aos requisitos identificados, esteja correto e corresponda à realidade.

Elementos do diagrama de casos de uso

Por ser simples, o diagrama de casos de uso possui poucos elementos passíveis de representação, que são:

• Os atores
• Os casos de uso
• Os relacionamentos
  • Entre atores e casos de uso
  • Entre casos de uso
  • Entre atores

Ilustração do diagrama de casos de uso

Por ser simples, o diagrama de casos de uso possui poucos elementos passíveis de representação, que são:

Entendendo o ator

O ator é algo com comportamento, que interage diretamente com o sistema. Um ator participa (realiza) de um ou mais casos de uso do sistema.

No diagrama de casos de uso, a representação do ator é o boneco, chamado stickman, conforme figura ao lado. O ator é o papel que o agente desempenha em relação ao sistema.

Um ator pode representar papéis internos (gerente de compras) e papéis externos (cliente e fornecedor) de acordo com o ilustrado na figura abaixo.

Abaixo exemplo de Ator representando um papel interno:

Abaixo exemplo de Ator representando um papel externo

Um ator pode também representar setores e departamentos da empresa (contabilidade e contas a pagar), bem como funções desempenhadas na empresa (almoxarifado), tal qual ilustrado pela figura a seguir.

Abaixo exemplo de Ator como setor e função desempenhada

Um ator pode ser dispositivos eletrônicos, como, por exemplo, hardwares, servidores ou dispositivos lógicos, como sistemas, de acordo com a imagem a seguir.

Abaixo exemplo de Ator como dispositivo eletrônico e sistema.

• O balanço é emitido pelo Sistema contábil, externo ao sistema em desenvolvimento
• A mensagem a clientes com dívidas é enviada pelo servidor de email.

Identificando atores

O primeiro passo para a construção do modelo de casos de uso é a identificação de atores.

Algumas perguntas são úteis nessa situação:

1. Quais órgãos, empresas ou pessoas farão uso desse sistema de informação?
2. Quais sistemas ou equipamentos se comunicarão com o sistema que será desenvolvido?
3. Quem deve ser informado de alguma ocorrência no sistema?
4. A quem pode interessar os requisitos funcionais do sistema?

Entendendo o caso de uso

Segundo Jacobson, um dos criadores da UML, “um caso de uso é uma descrição narrativa de uma sequência de eventos que ocorre quando um ator usa um sistema para realizar uma tarefa”. Representam, através de elipses, as funcionalidades do sistema, conforme imagem ilustrativa a seguir.

Sendo uma funcionalidade, o nome do caso de uso deve ser composto de um [verbo no infinitivo] + [complemento verbal], como, por exemplo, [matricular] + [em curso].

• Um caso de uso é um conjunto de cenários.
• Um caso de uso descreve uma sequência de ações do ator e do sistema.
• Cada sequência de ações é chamada de cenário.

Em suma, um cenário é uma sequência específica de ações que ilustra o comportamento do caso de uso.

Identificando casos de uso

Após a identificação dos atores, podemos passar ao reconhecimento dos casos de uso. Em primeiro lugar, podemos pensar nos casos de uso que representam os objetivos dos atores e/ou os processos da empresa. Assim sendo, as seguintes perguntas são úteis neste momento:

• Quais as necessidades e objetivos de cada ator em relação ao sistema?
• Quais informações serão produzidas pelo sistema?
• O sistema realizará alguma ação que ocorra de forma regular no tempo?
• Existe um caso de uso para atender cada requisito funcional?

Em seguida, podemos pensar nos casos de uso que não representam um benefício direto para os atores, mas são necessários para o funcionamento do sistema. Tais casos de uso englobam manutenções de: cadastros, usuários e seus perfis, informações provenientes de outros sistemas.

Atividade proposta

Imagine a seguinte cena: uma clínica oftalmológica precisa de um sistema de agendamento de consultas e exames.

• Um paciente contata a clínica, por telefone ou pessoalmente, e solicita a marcação de uma consulta com seu médico de preferência, informando data e hora desejadas;
• A atendente verifica na agenda do médico a disponibilidade mais próxima de data e hora e marca a consulta;
• Na data e hora agendadas, o paciente realizou a consulta, onde o médico solicitou exames e prescreveu medicamentos;
• Após a consulta, o paciente solicita à atendente a marcação de seus exames, informando data e hora pretendidas. A atendente verifica a disponibilidade próxima à solicitada e agenda o exame para o paciente;
• A qualquer momento, o paciente pode solicitar o cancelamento, não apenas da consulta, mas, também, do exame.

Com base nas descrições anteriores, identifique os atores, os casos de uso envolvidos e desenhe o esboço do diagrama de casos de uso.

Chave de resposta:

Atores: paciente, atendente e médico.

Casos de uso: seguem identificados por ator.

Atendente: Agendar Consulta, Agendar Exame, Cancelar Consulta e Cancelar Exame;

Médico: Consultar Paciente;

Paciente: Embora extremamente relevante nesse processo, não interage diretamente com nenhuma funcionalidade do sistema, embora todas os dados imputados no sistema sejam fornecidos por ele. Em princípio não é considerado um ator, do ponto de vista da interação com o sistema. Todavia, muitos autores consideram-no ator, juntamente com os verdadeiros atores de cada caso de uso.

Assim sendo, podemos ter duas soluções, representadas cada uma por um diagrama de casos. Para vê-los Clique aqui.

A primeira mais alinhada com o conceito de ator, onde o Paciente não figura entre os atores.
A segunda mais alinhada com a situação real, onde o Atendente e Médico interagem com o sistema, baseado no que lhes diz o Paciente.

Relacionamentos entre ator e caso de uso

Como você já viu, o diagrama de casos de uso possibilita relacionamentos entre:

• Atores e casos de uso;
• Atores;
• Casos de uso.

O mais comum é o relacionamento entre atores e casos de uso indicado por uma linha sólida, que liga o ator ao caso de uso, denotando a interação entre ambos. Nos termos técnicos, dizemos que o ator realiza o caso de uso. A figura abaixo ilustra esse relacionamento. Entenda que a comunicação nesse relacionamento é bidirecional; ou seja, além de o ator informar dados ao caso de uso, também recebe informações por ele processadas.

Relacionamentos entre atores

Como você já viu, o diagrama de casos de uso possibilita relacionamentos entre:

• Atores e casos de uso;
• Atores;
• Casos de uso.

Entre atores, é possível haver o relacionamento de generalização/especialização representado por uma linha sólida, com uma seta que aponta para o ator geral, conforme ilustrado na imagem abaixo. Perceba, então, que o ator geral é o funcionário, e o ator especialista, o gerente. O gerente também exerce as atividades de um funcionário; porém, como gerente, possui tarefas específicas a essa função.

Observe o diagrama de casos de uso ilustrado na figura a seguir, onde temos exemplificada a generalização/especialização de atores. A leitura desse diagrama é a seguinte:

• O ator geral é usuário, e os atores especializados são aluno e atendente;
• Aluno e atendente relacionam-se com todos os casos de uso associados ao ator usuário;
• No entanto, apenas o ator atendente se relaciona com cancelar matrícula em curso; ou seja, apenas atendente realiza esse caso de uso.

Essa última é uma associação (ou um relacionamento) útil para definir sobreposição de papéis entre atores, onde:

• O ator especializado interage com o caso de uso ao qual está associado diretamente e com todos os casos de uso com os quais o ator generalizado se associa;
• Já o inverso não ocorre: o ator generalizado não interage com os casos de uso associados ao ator generalizado.

Relacionamentos entre casos de uso

Como você já viu, o diagrama de casos de uso possibilita relacionamentos entre:

• Atores e casos de uso;
• Atores;
• Casos de uso.

Casos de uso podem ser organizados em três tipos de relacionamentos: inclusão, extensão e generalização (sendo que cada um deles é representado de uma maneira específica).

Relacionamentos entre casos de uso – inclusão

Inclusão (include ou uses):

Um caso de uso (caso de uso principal) incorpora, explicitamente, o comportamento de outro caso de uso (caso de uso incluído). O caso de uso incluído é parte integrante do caso de uso principal, e a fatoração acontece, pois outros casos de uso também poderão incorporar o caso de uso incluído e, assim, evitar repetições de fluxos.

Exemplo de inclusão

Observe no diagrama desta tela que o caso de uso validar disciplina é usado por dois casos de uso: incluir disciplina e eliminar disciplina. Isso significa que o caso de uso validar disciplina está contido em ambos; ou seja, se formos descrever as interações que ocorrem no caso de uso, perceberemos que tanto incluir disciplina quanto eliminar disciplinas possuirão uma mesma parte.

O caso de uso validar disciplina será obrigatoriamente executado em algum ponto da execução do caso de uso incluir disciplina, como também em algum ponto na execução do caso de uso eliminar disciplina.

Normalmente, essa percepção da necessidade de fatoração ocorre quando estamos descrevendo os casos de uso, assunto que trataremos adiante.

O cenário comum a mais de um caso de uso é capturado em outro caso de uso. No caso deste último exemplo, validar disciplina agrega o que é comum a incluir disciplina e a eliminar disciplina.

Relacionamentos entre casos de uso – extensão

Extensão (extends):

Usado para descrever cenários opcionais em um caso de uso, uma variação do comportamento normal.

Um caso B (caso de uso estendido) estende-se a A (caso de uso principal) quando alguma condição interrompe a execução do caso A (caso de uso principal) para que B (caso de uso estendido) execute e retorne, ao final, ao caso de uso A (caso de uso principal). A interrupção é feita no chamado ponto de extensão. A imagem desta tela ilustra o relacionamento de extensão.

Exemplos de extensão

Observe no diagrama desta tela que o caso de uso enviar informe de dívida estende o caso de uso cancelar matrícula em curso. Este poderá ou não solicitar a execução do caso de uso enviar informe de dívida, que somente será executado se o cancelamento do curso implicar no pagamento da dívida do aluno; se o aluno tiver quitado essa dívida, o caso de uso não será executado.

Existe outra conotação e leitura do uso do extends, que está ilustrado no diagrama de caso de uso demonstrado aqui.

Observe que os casos de uso pagar em cheque e pagar em cartão estendem o caso de uso pagar mensalidade. Neste exemplo, haverá uma condição a ser avaliada, que é a forma de pagamento e, de acordo com ela, será executado um ou outro caso de uso: apenas um deles será executado.

Relacionamentos entre casos de uso – generalização

Generalização:

Quando um caso de uso é semelhante a outro, mas executa algumas funções a mais. É pouco usado, pois seu uso confunde-se com o extends na medida em que este também pode resolver esta questão da variação de comportamento; neste caso, um comportamento com adição de funcionalidade.

Exemplo de generalização

Observe o exemplo desta tela, onde existe a especialização do caso de uso solicitar produtos, que pode ser pela internet ou pelo telefone. De acordo com a forma de solicitação, o comportamento do caso de uso variará; porém, existem partes comuns, que estão especificadas em solicitar produtos (caso mais geral).

A importância da especificação de casos de uso

O diagrama de caso de uso é útil na medida em que nos fornece uma visão geral das funcionalidades do sistema (conjunto de casos de uso) e dos atores que com elas se relacionam. Todavia, é pobre na medida em que não nos permite entender como a interação ocorre em cada caso de uso. Podemos dizer que o diagrama é um sumário gráfico do conjunto de casos de uso (funcionalidades) de um sistema.

No entanto, o real valor da técnica está na adequada descrição textual de cada caso de uso, que permite ver, com clareza, como os atores utilizam o sistema, no detalhamento. Mas a UML nada define sobre o texto narrativo, que descreve o caso de uso.

Por exemplo, o processo unificado – PU define o modelo de casos de uso dentro da disciplina de requisitos, onde essencialmente se escreve o comportamento de todos os casos de uso.

Em suma, se o tempo destinado ao modelo de casos de uso for pouco, concentre-se na especificação ou descrição dos casos de uso e esqueça o diagrama. Mas, se tiver oportunidade, modele o diagrama, pois é uma ótima ferramenta de diálogo com o usuário devido à sua simplicidade.

Os formatos para especificar casos de uso

No livro Utilizando UML e Padrões – uma introdução à análise e ao projeto orientados a objeto e ao desenvolvimento iterativo, de Craig Larman, são classificados três formatos para descrever casos de uso:

FORMATO RESUMIDO

O formato resumido trata-se de um resumo de um parágrafo, geralmente contendo o cenário principal do caso de uso, o cenário de sucesso.

Quando usar?

Utilizar o formato resumido na análise de requisitos inicial para obter uma ideia do assunto e escopo do caso de uso.

FORMATO INFORMAL

O formato informal consta de múltiplos parágrafos que cobrem vários cenários de uso.

Quando usar?

Utilizar o formato informal na mesma condição do formato resumido.

FORMATO COMPLETO

No formato completo, todos os passos e variantes são descritos em detalhes, com seções adicionais, complementando a especificação, como pré e pós-condições.

Quando usar?

Utilizar o formato completo depois que muitos casos de uso tiverem sido descritos no formato resumido ou informal, durante a fase de análise de requisitos e de sistemas. Em suma, para os casos de uso relevantes, deve-se usar esse formato.

Em essência, a especificação ou descrição textual de um caso de uso deve mostrar a interação entre o ator e o sistema (caso de uso em questão); ou seja, a “conversa” entre ator e sistema na realização do caso de uso.

Diferenciando os três tipos de especificação

Para mostrar a diferença entre os três tipos de especificação, vamos usar como exemplo o caso de uso registrar venda, com o seguinte trecho de diagrama de casos de uso:

Observe que, no diagrama acima, foram considerados ator tanto o caixa quanto o cliente. O motivo de considerá-los atores é que o cliente também interage com o sistema quando o pagamento é em cartão, por exemplo.

O formato resumido

Caso de Uso: Registrar Venda

O cliente chega em um ponto de pagamento da loja com os itens que deseja adquirir. O caixa registra cada item desejado. Ao final, o sistema apresenta o total a pagar e a relação de itens comprados. O cliente informa, e o caixa registra os dados do pagamento, que são validados e registrados pelo sistema, que atualiza o estoque. O cliente recebe o recibo das compras e sai com os itens adquiridos.

O formato informal

Caso de uso: Registrar Venda

Cenário Principal (de sucesso)

O cliente chega ao ponto de pagamento da loja com os itens a serem adquiridos. O caixa usa o sistema PDV para registrar todos os itens comprados. Ao final, o sistema apresenta o total a pagar e a relação de itens comprados. O cliente informa e o caixa registrar os dados do pagamento, que são validados e registrados pelo sistema. O sistema atualiza o estoque. O cliente recebe o recibo das compras  e sai com os itens adquiridos.

Cenários Alternativos

Se o identificador do item adquirido não for encontrado no sistema, esse notifica o caixa e sugere que esse entre manualmente com a identificação do item (que talvez esteja corrompido).

Se o cliente informou pagamento em cartão e a operadora não aprova a transação, informe o cliente e solicite nova forma de pagamento;

Se o sistema não consegue atualiza o estoque, sugere que o caixa registre no formulário de problemas do dia, para balanço ao final do dia.

O formato completo

Caso de uso (registrar venda)

Nome do caso de uso: registrar venda

Escopo: sistema de vendas – PDV

Nível: usuário

Atores: caixa

Interessados e interesses:

• Caixa: deseja que o sistema seja eficiente, sem erros e de fácil utilização;
• Cliente: deseja adquirir os produtos desejados de forma rápida, sem muito esforço, bem como encontrar o que precisa e, ao final, um comprovante do que comprou;
• Órgãos fiscais: desejam cobrar os impostos de cada venda realizada;
• Operadoras de cartão: desejam receber solicitações de autorização de crédito no formato e protocolo corretos;
• Etc.

Pré-condição: todos os produtos registrados no sistema, contendo os respectivos preços; caixa autenticado e PDF registrado.

Pós-condições: venda salva, impostos calculados, estoques atualizados, autorizações de pagamento registradas e recibo gerado.

Cenário principal (ou fluxo básico)

1. Cliente chega ao PDV com os itens que deseja adquirir;

2. Caixa inicia uma nova venda;

3. Para cada item de venda do cliente, faça:

a) Caixa insere o identificador do item;

b) Sistema localiza o item;

c) Sistema registra e apresenta a linha do item de venda, com o identificador, nome e valor unitário do produto;

d) Sistema calcula os impostos do item.

4. Sistema apresenta o valor total da venda com impostos calculados;

5. Caixa informa total ao cliente e solicita pagamento;

6. Caixa informa o pagamento do cliente;

7. Sistema registra e trata o pagamento do cliente;

8. Sistema finaliza a venda e apresenta o recibo;

9. Sistema contabiliza a baixa no estoque de cada item vendido.

Cenários alternativos (extensões)

2.a. Sistema não inicializa:

1. Caixa inicia a venda em planilha manual (contingência), registrando cada item e o pagamento em planilha eletrônica, e encerra o caso de uso.

3.a. Sistema não localiza o identificador do item:

1. Sistema avisa o erro e rejeita a entrada;

2. Caixa responde ao erro:

2.a. Existe ID do item legível:

1. Caixa insere o identificador do item;

2. Sistema mostra descrição e preço.

2.b. Existe preço na etiqueta:

1. Caixa solicita ao gerente executar operação de correção;

2. Gerente realiza correção;

3. Caixa indica entrada manual de preço, insere preço e solicita o imposto padrão para essa quantia.

2.c. Caixa invoca ajuda no sistema para localizar produto a fim de obter identificação e preço real do item.

2.d. Caso contrário, caixa pergunta a um funcionário o preço, e o identificador do item executa entrada manual do identificador (ver acima, 2.a) ou do preço do item (ver acima 2.b).

3-4 a. Cliente solicita o cancelamento de um item da venda:

1. Caixa insere o identificador do item a ser removido;

2. Sistema remove o item e exibe o total parcial atualizado.

3-6. a. Cliente solicita o cancelamento da venda:

1. Caixa cancela a venda no sistema.

7.a. Pagamento em dinheiro:

1. Caixa insere quantia do dinheiro fornecida;

2. Sistema apresenta valor do troco e libera gaveta do dinheiro;

3. Caixa deposita dinheiro fornecido e entrega troco ao cliente;

4. Sistema registra pagamento em dinheiro.

7.b. Pagamento com cartão de crédito:

1. Caixa insere dados do cartão do cliente;

2. Sistema mostra o pagamento para confirmação;

3. Caixa confirma o pagamento;

4. Sistema envia solicitação de autorização de pagamento à administradora do cartão do cliente;

4.a. Sistema detecta falha ao tentar se comunicar com sistema externo:

1. Sistema avisa do erro ao caixa;

2. Caixa solicita ao cliente forma de pagamento alternativa.

5. Sistema recebe aprovação de pagamento;

6. Sistema registra pagamento com cartão de crédito;

7. Sistema apresenta o mecanismo para entrada do pagamento a crédito.

8. Caixa solicita ao cliente a assinatura para pagamento a crédito; cliente fornece a assinatura;

9. Se assinatura em papel, caixa insere o papel na gaveta e a fecha.

8.a. Impressora não tem papel:

1. Se o sistema detecta a falha, avisará sobre o pagamento;

2. Caixa repõe o papel;

3. Caixa solicita outro recibo.

Requisitos especiais:

1. Interface de usuário com tela sensível ao toque em um monitor de tela plana com pelo menos 23 polegadas;

2. Resposta de autorização de crédito, dentro de 30 segundos, em 90 % dos casos;

3. A recuperação de falhas de servidores deve ser consistente e robusta.

Observe que cada passo do cenário principal é numerado e que em cada um pode haver uma ou mais falhas (insucessos). Nos cenários alternativos, temos um número e uma letra. Por exemplo, no passo 2 do cenário principal (caixa inicia uma nova venda), pode haver uma exceção (Sistema não inicia), que é tratada no cenário alternativo como 2.a.); ou seja, primeira (a) alternativa do passo 2. Já o passo 7 (sistema registra a trata o pagamento do cliente) possui dois cenários alternativos, representados por 7.a (pagamento em dinheiro) e 7.b (pagamento em cartão de crédito). Caso tivéssemos uma terceira forma de pagamento, como, por exemplo, cheque, seria o passo 7.c dos cenários alternativos.

Repare na quantidade de detalhes dessa especificação. Nesse formato, devem ser consideradas todas as possibilidades de exceção e insucesso de cada passo do cenário principal. A especificação acima poderia ter mais detalhes, como, por exemplo, o tratamento das seguintes exceções:

• A qualquer momento, o sistema pode falhar;
• As várias formas de pagamento a considerar (cheque, débito);
• O caixa cancelar o pagamento;
• Outros.

O detalhamento dependerá do sistema e da necessidade.

Como especificar casos de include

Considere o trecho de diagrama desta tela como de um sistema de locadora para aluguel de DVD. O trecho informa que os dependentes podem ser incluídos e eliminados do plano de sociedade com a locadora. Observe que existe um caso comum a ambos: pesquisar dependente. Vamos, a partir da especificação de um deles (incluir dependente), entender como se dá o uso do <include>.

Especificação do caso “incluir dependente”

Veja como declarar o uso de casos de inclusão:

Cenário principal

1. Atendente informa identificação do cliente;
2. Sistema localiza dados do cliente informado;
3. Atendente informa dados do dependente;
4. Sistema localiza dados do dependente informado

Cenários alternativos

2.a. Cliente não localizado:

– Sistema informa “cliente não registrado no sistema” e retorna ao passo 1 do cenário principal.

4.a. Dependente já registrado:

– Sistema informa “dependente já registrado no sistema ”e retorna ao passo 3 do cenário principal.

A inclusão do caso pesquisar dependente ocorre no passo 4 do cenário principal. Nesse momento, acontece a interrupção na execução do caso incluir dependente, e o fluxo desvia para a execução do caso pesquisar dependente. Ao final do caso de uso pesquisar dependente, o fluxo retorna para o cenário principal do caso incluir dependente. Isso se dá no passo seguinte ao da inclusão do caso de uso, que é o passo 5.

Como especificar casos de extends

Observe o diagrama a seguir, que usaremos para explicar o uso de casos de extensão ( <extends> ). Temos três extends no diagrama; porém, dois deles estão relacionados entre si, e o terceiro, não. O caso de uso calcular multa será usado se, e apenas se (condição), a entrega estiver sendo feita com atraso. Já os casos de uso pagar em dinheiro e pagar em cheque são mutuamente exclusivos; ou seja, apenas um deles será executado, de acordo com a forma de pagamento (condição) escolhida pelo cliente.

Especificação do caso “registrar devolução de DVD”

Cenário principal

1. Atendente informa identificação da mídia;

2. Sistema localiza locação com a mídia informada;

3. Sistema apresenta registro da locação com valor a pagar;

4. Atendente informa forma de pagamento;

5. Caso forma de pagamento seja DINH: <extends PAGAR EM DINHEIRO>; caso seja CARTÃO: <extends PAGAR no CARTÃO>;

Fim-Caso

6. Sistema registra devolução;

7. Sistema emite recibo de quitação do pagamento.

Cenários alternativos

1.a. Mídia não localizada:

Sistema informa “mídia não registrada no sistema ou não alugada” e retorna ao passo 1 do cenário principal.

2.a. Locação não localizada (inconsistência de dados):

Sistema informa “locação não registrada para a mídia no sistema” e encerra caso de uso.

2.b. SE Data Corrente > Data Prevista de Devolução ENTÃO Calcular Multa <<Extends CALCULAR MULTA POR A>>

Para melhor visualização, destacamos em negrito as chamadas aos casos de extends. No cenário principal, opcionalmente usamos pagar em dinheiro ou pagar em cartão e, nos cenários alternativos, condicionalmente, usamos calcular multa por atraso.

Considerações finais sobre especificações

Conforme já mencionado, a UML não descreve nada a respeito de especificações textuais de casos de uso, limitando-se a especificar os elementos e uso do diagrama de casos de uso. Porém, como também já mencionado, a especificação de casos de uso é extremamente relevante para o entendimento dos requisitos para a futura implementação de outros modelos e dos códigos-fontes dos programas que comporão o sistema.

Dicas sobre especificações de casos de uso

1. Não use detalhes de implementação ou de uma tecnologia específica em suas especificações. Evite, assim, que o seu caso de uso tenha de ser revisto quando a tecnologia ficar obsoleta. Exemplificando:

• Imagine um sistema de autoatendimento bancário para caixas eletrônicos. Ao descrever a ação do usuário para que ele informe seus dados de acesso, evite, por exemplo, solicitar: “Usuário, insira o seu cartão”. Em vez disso, use: “Usuário, informe os dados da agência, conta e senha de acesso”;
• Amanhã, a tecnologia muda, a identificação passa a ser, por exemplo, pela leitura da digital, e o caso de uso precisará ser reescrito. Se você fizer como proposto, criará um sistema adequado a qualquer tecnologia.

2. Procure não associar casos de uso a telas de sistemas. Entenda melhor:

• Muitos autores sugerem que listemos, nas especificações de casos de uso, esboços de telas. Geralmente, são os autores favoráveis a processos de desenvolvimentos ágeis, que visam entregar o código o mais rápido possível;
• Procure evitar essa prática, pois, no momento em que estamos especificando os casos de uso, ainda é cedo para pensarmos em interface, que será objeto da fase de projeto do sistema;
• Resista a essa tentação, pois sabemos que usuários adoram telas.

3. Existe um formato de especificação que muitos gostam, pois fica mais claro o diálogo que acontece entre ator e caso de uso. O modelo tem duas colunas:

• Na primeira, descrevemos as ações do ator;
• Na segunda, descrevemos as ações do sistema.

Quadro comparativo entre ações do ator e do sistema

Referências

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Campus, 2006.

BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usuário. 2. ed. Rio de Janeiro: Campus, 2006.

FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 3. ed. Porto Alegre: Artmed, 2005.

LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento interativo. 3. ed. São Paulo: Bookman, 2008.

Engenharia de Software | Linguagem de modelagem unificada (UML) | Casos de Uso: Diagramas e especificações