Casos de Uso e Cenários Engenharia de Requisitos UFPE - Centro de Informática

©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae. 1

Casos de Uso e Cenários

Engenharia de RequisitosUFPE - Centro de Informática


Roteiro

1. Introdução2. Casos de Uso3. Cenários4. Estudo de Caso5. Boas práticas6. Casos de uso ágeis7. Teoria e Prática8. Conclusão


Casos de uso detalham desejos dos usuários finais, não as tarefas dos programadores

• 1980’s: Vamos escrever requisitos como características! Usuários não entendem...

pressão do usuário para escrever como casos de uso.• 1990’s: Vamos escrever requisitos em casos de uso!

Programadores trabalham de acordo com características, não casos de uso...Pressão do programador para escrever como

características.• 2000: Então vamos escrever requisitos como

características! FDD e estórias de usuário do XP...

Perde-se novamente a experiência do usuário final.

Pêndulo das características vs. casos de uso


Definição de Caso de Uso

• Um caso de uso é uma descrição narrativa de uma seqüência de eventos que ocorre quando um ator (agente externo) usa um sistema para realizar uma tarefa[Jacobson 92]

• Uma unidade coerente de funcionalidade provida por um sistema, manifestada por uma seqüência de mensagens trocadas entre o sistema e um ou mais usuários externos (representados como atores), junto com as ações executadas pelo sistema.


Objetivos dos Casos de Uso

• Descrever a funcionalidade do sistema (Requisitos Funcionais)

• Mapear o escopo do sistema, onde explicita a fronteira do sistema.

• Facilitar a comunicação com usuário do sistema.• Gerenciar o projeto.• O RUP o utiliza para guiar todo processo de

desenvolvimento• Mostram apenas o que o sistema faz, e não

como.


Caso de uso: representação gráfica

Uma elipse com o nome do caso de uso no centroNome = Verbo + Substantivo (indicação de ação)


Ponte entre Requisitos e Análise


Ator

• Constituem as entidades que interagem com o ambiente do sistema o Pessoas ou outros sistemas (de hardware ou

software) que interagem com o sistema em desenvolvimento

• Definem um papel particular (uma mesma entidade pode desempenhar diferentes papéis)

• São sempre externos ao sistema• O sistema será descrito através de vários casos

de uso que são executados por um número de atores


Ator: representação gráfica


Diagramas de Caso de Uso

• Introduzida por Jacobson em 1994 para visualização dos casos de uso

• Esse diagrama é parte da UML• Mostram um conjunto de casos de uso, atores e

seus relacionamentos• Indicam a forma como o sistema interage com as

entidades externas


Diagrama de Caso de Uso : representação gráfica


Como encontrar atores?

• Quem usa o sistema?• Quem instala/mantém o sistema?• Quem inicia/desliga o sistema?• Que outros sistemas usam o sistema?• Quem recebe informação do sistema?• Quem provê informação ao sistema?


Como encontrar casos de uso?

• Que funções o ator vai querer do sistema?

• O sistema armazena informações? Que informações atores irão criar, ler, atualizar ou apagar?

• O sistema precisa notificar o ator sobre mudanças no seu estado interno?

• Existe algum evento externo que o sistema precisa saber? Que ator informa o sistema desses eventos?


Fluxo de Eventos

• Especifica o comportamento de um caso de uso• É uma seqüência de comandos declarativos que

descreve as etapas de execução de um Caso de Uso

• Permanece focado no domínio do problema e não em sua solução

• Pode conter testes condicionais e iterações• Contém informações relativas:

Às condições de início e término do caso de uso

Quais os atores interessados no sistema Como o caso de uso interage com esses

atores


Fluxo de Eventos

• O fluxo de eventos de um caso de uso é composto por: Um Fluxo Básico - descreve a funcionalidade

principal do caso de uso, quando nenhum desvio é tomado

Zero ou Mais Fluxos Alternativos - descrevem desvios pré-definidos do fluxo básico

• Esses fluxos podem ser especificados através de: Descrição textual informal Texto semi-formal (através de pré-, pós-

condições e invariantes) Pseudo-código Ou uma combinação destes


Exemplo (Fluxo Básico do caso de uso Comprar Produtos)Descrito em pseudo-código:1. O cliente chega ao ponto de vendas com os produtos da

compra2. Para cada produto trazido pelo cliente:

a) O atendente registra o código e a quantidade do produto

b) O sistema determina o preço do produto e o adiciona à compra

3. O atendente finaliza a compra 4. O sistema calcula e apresenta o total5. O atendente informa ao cliente sobre o total da compra

e pergunta qual a forma de pagamento6. Se (dinheiro) forma de pagamento = “dinheiro”7. O atendente registra a quantia recebida8. O sistema mostra o troco e gera o recibo9. O atendente deposita o dinheiro, devolve o troco e

entrega o recibo de compra10. O sistema registra o final da transação


Exemplo (Fluxos Alternativos de Eventos)

Descrições textuais:1. No passo 2 do fluxo básico, pode haver um

produto com um código inválido. Nesse caso, o sistema avisará que o código fornecido é inválido e pede que o atendente registre o próximo produto. Vá para o passo 2 do fluxo básico.

2. No passo 6, o cliente pode escolher pagar com cartão de crédito ou débito.Neste caso, o atendente passa o cartão e o cliente digita a senha.Se houver, vá para o passo 6 do fluxo básico.

3. A qualquer momento, o atendente pode cancelar a transação. Nesse caso, as informações referentes à compra são descartadas.


Cenários

• Em UML significa um caminho através de um caso de uso.

• Uma instância de um caso de uso• Seqüência de passos que descreve uma interação• Exemplo (Sacar dinheiro):

Saque com sucesso Tentativa de saque MAS senha incorreta Tentativa de saque MAS saldo insuficiente


Casos de Uso x Cenários

• Um caso de Uso não é um cenário, mas pode encapsular um conjunto de cenários

• Cada cenário é uma instância de um caso de uso

• Para cada caso de uso temos, no mínimo, um cenário para o fluxo normal (cenário principal) e outros para cada fluxo excepcional (cenários secundários).


Formato de Documentação de Casos de Uso

• Não existe um padrão comum na indústria ou na literatura para sua formatação

• Deve-se incluir informações que facilitem a comunicação entre os clientes e a equipe de desenvolvimento do sistema


Formato de Documentação de Casos de Uso (Modelo mais usado)

• Nome do Caso de Uso• Breve descrição• Ator (principal)• Prioridade (ex: Essencial, Importante, Desejável)• Pré-Condições• Pós-Condições• Fluxo de eventos:

Fluxo de evento principal Fluxos secundários: alternativos e de exceção

• Requisitos Não-Funcionais Específicos


Relacionamento entre casos de uso

• Os casos de uso podem ser organizados por meio de relacionamentos

• A UML disponibiliza três tipos: generalização inclusão extensão


Generalização

• É um relacionamento de generalização/especialização

• Os casos de uso especializados herdam a estrutura do caso de uso generalizado

• O supertipo contém cenários mais especializado, particular a cada um deles

• Os subtipos contém cenários mais especializados, particular a cada um deles

• Os cenários comuns a mais de um caso de uso é adaptado em um caso de uso generalizado


Generalização

• Quando usar? Quando você estiver descrevendo comportamentos

semelhantes entrecasos de uso, mas algum deles faz um pouco mais que o outro.

Exemplo:


Inclusão

• Um caso de uso incorpora explicitamente o comportamento de outro caso de uso, evitando assimrepetições de descrição de fluxos.

• O cenário comum a mais de um caso de uso é captado em um outro concentra o serviço em um caso de uso base a

ser utilizados por outros evita-se descrever a mesma seqüência de

passos a vários casos de uso• Utiliza o estereótipo <<include>> para expressar

esse tipo de relacionamento


Inclusão

• Quando usar? Quando houver repetição entre casos de uso e você

desejar evitar esta repetição

Exemplo:


Extensão

• É usado para descrever cenários opcionais de um caso de uso os casos de uso descrevem cenários que sempre

acontecerão no sistema os casos de uso estendidos ocorrerão em uma

situação específica concentra-se essa seqüência em um caso de uso

público

• Utiliza o estereótipo <<extend>>para expressar esse tipo de relacionamento


Extensão

• Quando usar? Quando quiser descrever uma variação do comportamento

normal.• partes opcionais de casos de uso• cursos alternativos e complexos que raramente ocorrem

Exemplo:


Fluxo de Requisitos no RUP


Atividades e Responsáveis


Localizar Atores e Casos de Uso• Objetivos

Delimitar o sistemaDestacar os atores que irão interagir com o

sistemaDestacar os casos de uso do sistemaDefinir glossário com os principais termos

• Processo Identificar os Atores Identificar Casos de UsoDescrever Caso de Uso de forma resumidaCriar Diagramas de Caso de UsoDescrever os diagramas (Descrição Analítica)


Priorizar os Casos de uso• Objetivos

Definir em quais iterações os Casos de Uso serão desenvolvidos

Definir quais Casos de Uso participarão da visão arquitetural do Modelo de Caso de Uso

• Processo Identificar os Casos de Usos com mais riscos e os

mais significantes Alimentar a Visão Arquitetural dos diagramas de

Caso de Uso, com os casos de usos mais importantes

Alocar os Casos de Uso as iterações definindo suas prioridades dentro de cada uma delas.


Detalhar Casos de Uso• Objetivos

Descrever o fluxo de eventos de cada caso de uso

• Processo Entrevistar os usuários (atores) que estão

relacionados com cada um dos casos de uso Descrever detalhadamente os passos que

compõem o fluxo de evento do use case (Cada passo deve ter um objetivo claro)

Revisar o detalhamento do caso de uso com os usuários

Refinar a descrição dos casos de uso


Estruturar o Modelo de Caso de Uso

• Objetivos Otimizar o modelo de caso de uso

• Processo Identificar descrições de funcionalidades comuns.

– Extrair tais funcionalidades e criar um use case mais específico que possa ser usado pelos demais <<include>>.

Reuso de use cases – Herança(<<Generalization>>) ou

Factoring(<<include>>) entre casos de uso. Identificar descrições de funcionalidades adicionais

ou opcionais. Extrair as extensões adicionais ou opcionais para um

use case mais específico <<extend>> Ex:Condições, Erros, Alternativas


Valor dos casos de uso

• A lista de objetivos permite aos executivos: Pequenos sumários sobre contribuições do sistema Planejamento do projeto (prioridades e tempos)

• O cenário principal provê a todos: Acordo com as responsabilidades do sistema

• Fluxos alternativos das condições oferece aos programadores: Lista de coisas que os programadores precisam ficar

atentos Lista de coisas que os analistas precisam investigar

• Controle de fluxos alternativos permite a equipe de desenvolvimento: Avaliar (complexas) regras e decisões de negócios

• O caso de uso completo permite a equipe de desenvolvimento: Avaliar completude da funcionalidade requisitada


Pontos fortes• Casos de uso permitem escrever os requisitos

funcionais de forma fácil de ler.

2. Permitem avaliar necessidades de requisitos não-funcionais e definição de calendário do projeto.

Pontos fracos1. Casos de uso mostram apenas requisitos funcionais.

2. Planejamento não pode ser feito somente com casosde uso.

Casos de uso (pontos fortes e fracos)


Bons casos de uso ...

• Comunicam em uma linguagem entendível independente de especialidades

• Descrevem aquilo que o sistema fará Contrato com todos os stakeholders sobre o

comportamento do sistema• Registram decisões• Permitem validação de “completude”• Contextualizam requisitos• Permitem identificação de itens que precisam ser

pesquisados


A parte difícil dos casos de uso não é escrever, mas pensar e concordar.

• ~ 3 dias de construção ~ 2 horas de digitação O restante pensando e discutindo sobre regras

Perguntas para validação dos casos de uso

1. Cada passo está correto?2. Existem responsabilidades do sistema entre os

passos?3. Existe algum sistema externo que este sistema

deve usar?4. Algum outro stakeholders foi desconsiderado?5. Todos os fluxos alternativos foram pensados?


Casos de uso ágeis (use cases agile-ly)

• Metodologia desenvolvida por Alistair Cockburn Casos de uso Metodologia ágil


Desenvolvimento de software ágil

• Valores: Indivíduos e Interações acima de Processos e

Ferramentas. Software funcionando acima de Documentação

compreensível. Colaboração do cliente acima de Negociações

de contrato. Resposta a mudanças acima de Planejamento

exatamente executado.

• Oferecer freqüentemente pequenas partes usáveis de software ao cliente


Escrevendo casos de uso ágeis

1. Identifique os atores e seus objetivosResultado: lista de atores e casos de usoValor: visão geral do sistema (bom para priorização e estimar)

2. Escreva casos de uso simples de acordo com cada objetivoResultado: descrições das funcionalidades do sistemaValor: alinhamento da equipe com as responsabilidades do

sistema3. Determine as condições que precisam de fluxos alternativos

Resultado: lista de cenários alternativos para estudar quando necessário

Valor: Permite programadores iniciarem trabalhos4. Escreva os fluxos alternativos até terminar ou voltar ao fluxo

principalResultado: Caso de uso completoValor: regras de negócios detalhadas para programadores e

testadores


Casos de uso ágeis

• Incrementos, just-in-time, comunicação próxima• Escreve-se conteúdo suficiente para planejar o

necessário Longo prazo: Nomes dos casos de uso e descrição Curto prazo: Casos de uso completos

• Escreve-se conteúdo suficiente para a equipe entender Programadores entendem decisões do sistema Mostrar casos de uso e sistema para usuários e

recebe feedback• Ajusta-se forma de trabalho a cada interação adaptando

para cada situação particular• Sempre questionar quanto gastará para detalhar mais

Quanto? Quando precisa? Qual a forma mais rápida? Quem se beneficiará com mais detalhes?


Casos de uso ágeis

• Escrever pouco, mais claramente (sempre)

Mais curto, econômico e fácil de ler

•Text•No GUI

•No data formats•3 - 9 steps in main

scenario•Easy to read

•At user’s goal level•Record of decisions made

•UML use case diagrams•describing the GUI•describing data formats•multiple-page main scenario•complicated to read•at program-feature level•tutorial on the domain

Agile use cases Common use cases


Casos de uso ágeis

• Escrever menos (as vezes) Depende das prioridades e características do

projetoCasos de uso completamente detalhadosParágrafos descritivosPequenas descrições (1-2 frases)

• Reduzir estruturas dos casos de uso (as vezes) Não são lidos por compiladores, mas por

humanos Adapte-os as necessidades da equipe

• Detalhar depois, adiantar o processo (quase sempre)

Casos de uso podem ser escritosTodos no início ou just-in-time

Cada um até o final ou com incrementos usáveis


Animação de Cenários

• Técnica de validação de requisitos Combinação de objetivos e cenários

• Modelos e comportamentos da aplicação Estados do cenário até alcançar objetivo

• Especificações executadas como um filme


Animação de cenários

• Interação entre componentes para chegar ao objetivo

Documents

Casos de Uso e Cenários Engenharia de Requisitos UFPE - Centro de Informática