Casos de Uso

Casos de UsoMaria Augusta Constante Puget (Magu)

2

Origens

A idéia de usar casos de uso para descrever requisitos funcionais foi introduzida em 1986 por Ivar Jacobson, um dos principais contribuintes da UML e do PU.

A idéia de Jacobson foi amplamente aceita, sendo suas virtudes principais: a simplicidade e a utilidade.

Embora muitos tenham feito contribuições para o assunto, possivelmente o passo mais influente na sua definição e sobre como escrevê-los deve-se a Alistair Cockburn, com o seu artigo Writing Effective Use Cases.

3

Casos de Uso e Requisitos Casos de uso são requisitos. Eles são os requisitos funcionais que

indicam o que o sistema fará. Definem uma promessa ou contrato de como o

sistema se comportará. Narrativas de casos de uso são

documentos textuais, não diagramas, e a modelagem de casos de uso é basicamente um ato de redigir textos e não desenhar.

Entretanto, a UML define um Diagrama de Caso de Uso para ilustrar os nomes dos casos de uso e atores, assim como seus relacionamentos.

4

Diagramas de Casos de Uso Fornecem uma visão de alto nível do

sistema: Perspectiva externa e dos atores. É o mais informal dos diagramas da UML. Ajuda a capturar os requisitos funcionais do

sistema. É semanticamente limitado: Depende de

interpretação. A sua documentação é essencial. Outros

diagramas da UML, como o de atividades e o de seqüência, mais formais e precisos, podem ser usados nessa documentação.

5

Representam um conjunto de papeis coerentes que os usuários de casos de uso desempenham quando interagem com ele. Podem ser:

Humanos.Dispositivos.Sistemas.

Residem fora do sistema.

Diagrama de casos de uso: Atores

6

Atores e Casos: Representação (1)

Caso de Uso

Ator

7

Atores: Representação (1)

Várias pessoas podem ser representadas por um único ator.

8


Uma pessoa pode atuar como mais de um ator.

9


Ator primário: Estimula o sistema a reagir. Ator secundário: Responde às solicitações

do sistema.

10

Atores: Nomeando (1)

Agrupe os indivíduos segundo a utilização do sistema.

Identifique os papéis que eles assumem ao utilizar o sistema.

Cada papel é um ator em potencial.

Use nomes comuns para um sistema existente (do ponto de vista do usuário). Não invente um nome novo.

11

Relacionamentos de associação (1)

Os relacionamentos de associação entre Atores e classes de Casos de Uso são usados para indicar que o ator participa e se comunica com o sistema conforme descrito no Caso de Uso.

A seta indica quem inicia a comunicação.

Setas não demonstram fluxo.

12


Seta do Ator para o Caso de Uso: Ator dispara o caso de uso; Ator estimula o sistema; Ator principal.

13


Seta do Caso de Uso para o Ator : Sistema solicita informações; Sistema espera uma ação do ator; Ator secundário.

14

Fatoração de Casos de Uso

Existem 3 tipos de relacionamentos de fatoração: Inclusão: Include; Extensão: Extend; Generalização.

Objetivos: Reuso de pedaços do Caso de Uso; Especialização de comportamento; Descrição de procedimentos opcionais.

15

Fatoração de Casos de Uso: Inclusão (1)

Utilizado para: Fatorar o comportamento do Caso de Uso base que

não é necessário para o entendimento do propósito principal do Caso de Uso, mas cujo resultado apenas seja importante.

Fatorar um comportamento que seja comum a mais de um Caso de Uso.

Características: A execução do Caso de Uso incluído é obrigatória; O Caso de Uso base depende do resultado

retornado pelo Caso de Uso incluído; Nem o Caso de Uso base, nem o incluído, acessam os

atributos um do outro; A inclusão é, na essência, um encapsulamento.

16


17


No sistema de Caixa Bancário, os casos de uso “Sacar”, “Depositar” e “Transferir” precisam incluir como o cliente será identificado no sistema.

Este comportamento pode ser fatorado em um Caso de Uso “Identificar Cliente” que os 3 casos de uso incluem.

Da perspectiva dos casos de uso base, não importa qual método é utilizado para a identificação: Se senha, cartão, identificação de retina, etc. Só interessa o resultado.

Da perspectiva do Caso de Uso incluído, não importa qual caso de uso o está utilizando (incluindo) ou como o resultado será processado.

18

Inclusão (include) - Descrição

Exemplo do “Sacar Dinheiro” incluindo o “Identificar Cliente”.

19

Fatoração de Casos de Uso: Extensão (1)

Utilizado para: Mostrar no modelo que uma parte do Caso de Uso é um

comportamento opcional do sistema. Mostrar que um subfluxo é executado somente sob certas

condições. Mostrar que podem existir tipos de comportamento que serão

inseridos no Caso de Uso dependendo da interação do ator com o Caso de Uso.

Características: A execução do Caso de Uso de extensão é opcional; O Caso de Uso de extensão é inserido no Caso de Uso base em

locais específicos chamados “Pontos de extensão”; O Caso de Uso adicional pode acessar e alterar atributos do

Caso de Uso base, mas o Caso de Uso base não conhece os atributos do Caso de Uso adicional.

20


21


No sistema Caixa Bancário, quando o cliente for identificado, o sistema precisa saber se ele já adquiriu seguro contra roubo do cartão e, caso negativo, oferecer a aquisição do seguro.

Pode-se evidenciar isso com a criação de um Caso de Uso chamado “Adquirir Seguro” que estende a funcionalidade de “Identificar Cliente”.

22

Fatoração de Casos de Uso: Generalização (1)

Utilizado para: Destacar o comportamento comum a mais de um

Caso de Uso, mas com algumas particularidades adicionais.

Demonstrar formas mais específicas de comportamento em um Caso de Uso.

Características: Relacionamento “é-um” entre um caso de uso base

(pai) com um ou mais casos de uso filhos. Semelhante a generalização-herança de classes. O filho herda toda a estrutura: Comportamento e

relacionamentos do pai; O filho é totalmente dependente da estrutura do pai.

23

Fatoração de Casos de Uso: Generalização (2)

24

Generalização - Descrição

25

Exemplo (1)

Cliente

PessoaFísica

PessoaJurídica

Instituiçãode varejo

InstituiçãoFinanceira

Realiza atransação com

cartão

Processa aconta do cliente

Reconcilia astransações

Gerencia aconta do cliente

26

Exemplo (2)

27

Diagramas bem estruturados - Características

Um diagrama de Caso de Uso bem estruturado: Tem como foco comunicar um aspecto da

visão de Caso de Uso do sistema. Contém somente os casos de uso e atores

essenciais à compreensão desse aspecto. Fornece detalhes consistentes com seu nível

de abstração; deverão ser expostos os adornos essenciais à compreensão.

Não é tão minimalista, que informe mal o leitor sobre a semântica que é importante.

28

Diagramas bem estruturados - Sugestões

Ao definir um diagrama de caso de uso: Dê-lhe um nome capaz de comunicar seu propósito. Distribua os elementos de tal forma a minimizar o

cruzamento de linhas. Organize os elementos espacialmente, de maneira que

os comportamentos e papéis semanticamente relacionados apareçam fisicamente próximos.

Use notas e cores como indicações visuais e para chamar atenção para características importantes do diagrama.

Tente não mostrar muitos tipos de relacionamentos. Em geral, se você tiver relacionamentos de inclusão e extensão complicados, coloque esses elementos em outro diagrama.

29

Anatomia de Narrativas de Casos de Uso (1)

30

Anatomia de Narrativas de Casos de Uso (2)

31

Casos de Uso: Seções (1)

Descrição: Apresenta uma breve descrição do objetivo do caso de uso.

32


Pré-Condição:É o estado do sistema requerido antes do caso de uso ser iniciado;

Pode ser omitido: Usar apenas quando relevante;

É uma restrição para o início do caso de uso, não o evento que inicia o caso de uso.

33


Pós-Condição:É o estado no qual o sistema deve estar ao final do caso de uso.

Pode ser omitido: Usar apenas se agregar valor.Quando usado com extends deve-se ter cuidado para que o caso de uso estendido não introduza um sub-fluxo que viole a pós-condição.

34


Cenário:É o diálogo ator-sistema detalhando a execução do caso de uso.

Fluxo Básico: Fluxo onde tudo dá certo: Caminho feliz.

Fluxos alternativos: Variações na execução do fluxo básico. Erros (exceções) que podem ocorrer no fluxo

básico. Em alguns processos são chamados de fluxos de exceção.

35


36


37

O que os Casos de Uso não contém (1)

O caso de uso descreve a funcionalidade do sistema de uma perspectiva orientada à tarefa (passos).

O caso de uso não contém:Detalhes da interface com o usuário.Objetivos de performance.Detalhes da arquitetura da aplicação.Requisitos não funcionais.

38

“... O ator clica no botão Ok...”

“... O sistema exibe um DBGrid com os...”

“... A resposta deverá ser retornada em menos de 10 s...”

“... O sistema inicia uma conexão com o servidor de aplicação...”

“... O usuário deverá entrar com os códigos através da caneta ótica...”

O que os Casos de Uso não contém (2)

39

Identifique as interações do usuário (concentre-se nos objetivos do usuário):

“Sacar dinheiro...”“Transferir dinheiro entre contas...”“Cadastrar contas de débito automático...”

Descreva as funções que o usuário deseja.Descreva as funções que criam, lêem, atualizam e excluem informações.

Descreva como os atores são notificados sobre alterações de estado do sistema.

Descreva como os atores informam ao sistema sobre eventos ocorridos.

Como encontrar Casos de Uso (1)

40

Validação do modelo:O sistema fornece o comportamento correto às necessidades do negócio?

Todas as necessidades são resolvidas pelos casos de uso que você identificou?

Quais casos de uso suportarão as principais funcionalidades do sistema?

Quais informações devem ser modificadas ou criadas no sistema?

Validação com Casos de Uso (1)

41

Nomeie o caso de uso com uma frase que especifique o objetivo do ator.

Utilize verbos concretos, “fortes”, ao invés de verbos genéricos e fracos.

Seja explícito. Utilize termos específicos. Exemplos:

Termos fracos: Formulário, dado, sistema.Termos fortes: Propriedade, pagamento, conta.

Nomeando Casos de Uso (1)

Documents

Casos de Uso