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 correlatas Processos

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 Na RF queremos “desobrigar” o definidor de ter que encarregar-se do projeto detalhado da GUI. Assim, a seção de Interface, no doc. De requisitos, não necessariamente conterá a descrição detalhada de todas as interfaces - fazer uma descrição detalhada ou não fica a critério do definidor. Se ele quiser, pode usar a seção de Interface apenas para dar uma ideia de como deve ser a interface e dizer que campos ela deve conter, deixando para os desenvolvedores o projeto propriamente dito. Claro que se ele (o definidor) quiser fazer uma descrição detalhada da interface, ele pode fazê-lo. Em sistemas já existentes ele pode, inclusive, capturar telas do sistema e incluí-las na seção de interface, para ilustrar algum ponto do fluxo dos casos de uso. Assim, a descrição de interfaces funciona como uma ferramenta para a compreesão dos casos de uso - este é o seu objetivo. O nível de detalhes depende do estilo de cada definidor. Porém, via de regra, a descrição não deveria ser um projeto completo da interface, até porque é provável que características técnicas, levantadas nas atividades de análise e projeto, influenciem o design da interface. Os definidores costumam descrever também as críticas que são feitas aos campos da interface (ex.: este campo é numérico da forma xx.xxx.xx, etc.). Essas críticas podem ser feitas na própria descrição das interfaces, evitando assim a descrição de uma série de fluxos de erro que iriam especificar essas entradas erradas. Mas, cuidado! As críticas descritas em conjunto com a descrição das interfaces devem ser críticas bem básicas,destas que Java e Delphi permitem que você trate apenas setando uma propriedade dos campos. Críticas que traduzem regras de negócio mais complexas DEVEM ser descritas nos fluxos de erro, para não induzir que sejam tratadas diretamente na interface do sistema e não em camadas mais “internas” da aplicação (como a camada de regras de negócio). Senão você acaba favorecendo uma dependência de interface nos sistemas.

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

<<includes>> Inclusão Use inclusão quando há repetição entre casos de uso e você quer evitar esta repetição. Efetuar pagamento <<includes>> Realizar pedido Vendedor

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. Solicitar catálogo Vendedor Realizar pedido extends

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. Realizar venda Vendedor Estabelecer crédito Supervisor

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 The Unified Modeling Language: The User Guide Addison-Wesley, 1999.