Fluxos secundários


Só devem ser analisados e descritos após a
descrição dos fluxos básicos.
Fluxos alternativos
 situações

especiais (desconto para um cliente)
Fluxos de erro
 situações
de erro
Reuso de fluxos secundários



Fluxos secundários, principalmente de erros,
podem ser referenciados por diferentes casos
de uso.
Evitar duplicação de informação.
O documento de requisitos terá uma seção
para isso.
Prioridade de Casos de Uso




Essencial para gerenciar os requisitos
E para montar as iterações
Definir prioridade de todos os casos de uso
A prioridade pode ser:
 Essencial
 Importante
 Desejável
Agrupamento de casos de uso

Dividir os casos de uso em pacotes
 Ator
 Funcionalidades
 Processos
correlatas
Exercícios

Descrever os casos de uso gerados nos
exercícios anteriores, com mais detalhes,
incluindo fluxos secundários.
Descrição de interface do usuário

Ferramenta para compreensão do caso de
uso
o
nível de detalhes deve ser adequado ao
usuário

Facilidade para a descrição de críticas
básicas
 tamanho
e tipo dos campos
 máscaras
Estruturação do
Modelo de Casos de Uso
Por que estruturar o modelo?



Extrair descrições de funcionalidades genéricas
e compartilhadas que podem ser usadas por
mais de um caso de uso.
Extrair descrições de funcionalidades
adicionais que possam estender descrições
específicas
Facilitar o entendimento do modelo
Mas atenção...
O modelo não deve ser estruturado muito
cedo!
Relacionamentos entre casos de uso

Inclusão

Extensão

Generalização
Inclusão

Use inclusão quando há repetição entre casos
de uso e você quer evitar esta repetição.
Efetuar pagamento
Realizar pedido
Vendedor
<<includes>>
Inclusão de casos de uso


Um caso de uso incorpora explicitamente o
comportamento de outro caso de uso.
O caso de uso incluído é na maioria das vezes
usado desta maneira
 (Ex.

Identificação de usuário no sistema)
Evitando assim repetições de descrição de
fluxos.
Extensão

Use extensão quando quiser descrever uma
variação do comportamento normal.
Realizar pedido
extends
Vendedor
Solicitar catálogo
Extensão de casos de uso

Usado para modelar
 partes
opcionais do sistema
 fluxos alternativos e complexos que raramente
acontecem
 fluxos que são executados somente em certos
casos
Generalização

Generalização de um caso de uso A para
um caso de uso B indica que uma
instância do caso de uso A inclui o
comportamento especificado no caso de
uso B.
Imprimir documento
Gerar relatório
Retornar item
Generalização de casos de uso



É possível abstrair comportamento de casos de
uso.
Os casos de uso “Retornar item” e “Gerar
relatório” ambos precisam imprimir um recibo.
Identificar um caso de uso abstrato para
realizar a impressão.
Generalização de atores

Quando um ator A realiza todos os casos
de uso que o ator B e outros adicionais,
dizemos que A estende B.
Vendedor
Supervisor
Realizar venda
Estabelecer crédito
Generalização de atores
Estudante
Estudante em
Tempo Integral
Estudante em
Tempo Parcial
Tópicos Cobertos









Introdução
Conceitos Chave
Descrição do Problema
Glossário
Modelo de caso de uso
Especificações Suplementares
O Fluxo de Requisitos
Checklists
Estrutura de Documento de Requisitos
Checklists: Modelo de Casos de Uso





O modelo de caso de usos está fácil de se entender?
Estudando o modelo de caso de usos, você pode ter
uma idéia clara das funções do sistema e como elas
estão relacionadas?
Todos os requisitos foram levantados?
O modelo de caso de usos contém algum
comportamento supérfluo?
A divisão em pacotes do modelo de caso de usos
está apropriada?
Checklists: Atores





Todos os atores foram identificados?
Cada ator está envolvido com pelo menos um caso
de uso?
Cada ator desempenha um papél? Algum deveria ser
fundido com outro ou ser dividido em dois?
Existem dois ou mais atores desempenhando o
mesmo papél em relação a um caso de uso?
Os atores têm nomes intuitivos e descritivos? Tanto
os usuários como os patrocinadores do software têm
um entendimento comum?
Checklists: Casos de Uso





Cada caso de uso está envolvido com pelo menos
um ator?
Os caso de usos são independentes uns dos outros?
Algum dos caso de usos têm comportamento ou
fluxo de eventos muito similares?
Os caso de usos têm nomes únicos, intuitivos e
explicativos de modo que não podem ser
confundidos em um estágio posterior?
Os patrocinadores e usuários entendem os nomes e
descrições dos caso de usos?
Checklists: Especificação de Caso de Uso








Está claro quem deseja executar um caso de uso?
A finalidade de cada caso de uso está clara?
A descrição breve dá uma idéia clara do significado do caso de
uso?
Está claro como e quando os fluxos de eventos de cada caso
de uso começam e terminam?
A seqüência de comunicação entre um ator e um caso de uso
está de acordo com as expectativas do usuário?
As interações e trocas de informação entre os atores e o
sistema estão claras?
Existe algum caso de uso demasiadamente complexo?
Os fluxos de eventos (básicos e alternativos) estão modelados
de forma clara?
Checklists: Glossário



Os termos têm uma definição clara e concisa?
Cada termo do glossário foi incluído em algum lugar
nas descrições dos caso de usos?
Os termos são usados consistentemente nas
descrições dos atores e dos caso de usos?
Tópicos Cobertos









Introdução
Conceitos Chave
Descrição do Problema
Glossário
Modelo de caso de uso
Especificações Suplementares
O Fluxo de Requisitos
Checklists
Estrutura do Documento de Requisitos
O Documento de Requisitos: estrutura





Introdução
Descrição Geral do Sistema
Requisitos Funcionais (casos de uso)
Requisitos Não Funcionais
Descrição da Interface com o usuário
Requisitos Funcionais
(casos de uso)








Breve descrição
Ator
Prioridade
Interfaces Associadas (opcional)
Entradas e Pré-condições
Saídas e Pós-condições
Fluxo de eventos principal
Fluxos secundários: alternativos e de exceção
(opcional)
Revisão: Workflow de Requisitos








Quais são os principais artefatos do workflow de
requisitos?
Para quê estes artefatos são usados?
O que é um modelo de caso de usos?
O que é um ator?
O que é um caso de uso?
Qual a diferença entre um caso de uso e um cenário?
O que é uma especificação suplementar e o que ela
inclui?
O que é um glossário e o que ele inclui?
Referências




Applying Use Cases: A Practical Guide
Geri Schneider e Jason P. Winters
Addison-Wesley, 1998.
UML Distilled
Martin Fowler
Addison-Wesley, 1997.
The Unified Software Development Process
Ivar Jacobson, Grady Booch e James Rumbaugh
Addison-Wesley, 1998.
The Unified Modeling Language: The User Guide
Ivar Jacobson, Grady Booch e James Rumbaugh
Addison-Wesley, 1999.