Engenharia de Requisitos

Alexandre Vasconcelos
(amlv@cin.ufpe.br)

1
Objetivos
 Descrever as principais atividades da
engenharia de requisitos
 Introduzir técnicas para a elicitação
e análise de requisitos
 Descrever validação de requisitos
 Discutir o gerenciamento de
requisitos

2
 O Processo da Engenharia de
Requisitos
Estudo de Elicitação de
viabilidade requisitos e
análise
Especificação
de requisitos
Validação
Relatório de de requisitos
viabilidade

Requisitos do
usuário e do
sistema

Modelos do Documento de
sistema requisitos
3
Estudo de Viabilidade
 O que é um estudo de viabilidade?
 O que estudar e concluir?
 Benefícios e custos
 Análise de custo/benefício
 Alternativas de comparação

4
Estudo de Viabilidade
 Estudo que indica se o esforço em
desenvolver a idéia vale a pena
 Visa tanto a tomada de decisão
 Como a sugestão de possíveis
alternativas de solução

5
Estudo de Viabilidade
 Deve oferecer informações para
ajudar na decisão
 Se o projeto pode ou não ser feito
 Se o produto final irá ou não beneficiar
os usuários interessados
 Escolha das alternativas entre as
possíveis soluções
 Há uma melhor alternativa?

6
O Que Estudar?
 Sistema organizacional apresentado
 Usuários, políticas, funções, objetivos,
etc.
 Problemas com o sistema apresentado
 Inconsistências, funcionalidades
inadequadas, performance, etc.
 Objetivos e outros requisitos para o
novo sistema
 O que precisa mudar?
7
O Que Estudar?
 Restrições
 Incluindo requisitos não-funcionais do
sistema (superficialmente)
 Alternativas possíveis
 Sistema atual é geralmente uma das
alternativas
 Vantagens e desvantagens das
alternativas
8
Testes de Viabilidade
 Operacional
 Medida do grau de adequação da solução
para a organização
 Avaliação de como as pessoas se sentem
sobre o sistema/projeto
 Técnica
 Avaliação da praticidade de uma solução
técnica específica e a disponibilidade dos
recursos técnicos e dos especialistas

9
Testes de Viabilidade
 Cronograma
 Avaliação de quão razoável está o
cronograma do projeto
 Econômica
 Avaliação de custo-eficiência de um
projeto ou solução
 Conhecida como análise de custo/benefício

10
Viabilidade Operacional
 Avalia a urgência do problema (visão e
fases de estudo) ou a aceitação da solução
(definição, seleção, aquisição, e fases do
projeto)
 Há dois aspectos da viabilidade operacional
a serem considerados
 O problema vale a pena ser resolvido ou a
solução proposta para o problema funcionará?
 Como o usuário final e a gerência sentem-se
sobre o problema (solução)?

11
Viabilidade Técnica
 A solução ou a tecnologia proposta é
prática?
 Já possuímos a tecnologia necessária?
 Já possuímos o conhecimento técnico
necessário?

12
Viabilidade de Cronograma
 Dado nosso conhecimento técnico, os
prazos dos projetos são razoáveis?
 Alguns projetos são iniciados com prazos
específicos
 Você precisa determinar se os prazos são
obrigatórios ou desejáveis

Se são mais desejáveis que obrigatórios, o
analista pode propor outros cronogramas

13
Viabilidade Econômica
 Talvez a mais crítica
 Durante as fases iniciais do projeto, a análise
da viabilidade econômica consiste em julgar se
os possíveis benefícios de solucionar o problema
são ou não vantajosos
 Tão logo os requisitos específicos e soluções
sejam identificados, o analista pode levar em
consideração os custos e benefícios de cada
alternativa
 Isso é chamado de análise de custo-benefício

14
Tipos de Custos
 Custos de desenvolvimento de
sistemas
 Desenvolvimento e aquisição
 Custos de instalação e de conversão
 Custos operacionais (contínuo)
 Manutenção
 Pessoal

15
Análise Custo-Benefício
 Há três técnicas principais
 Análise do retorno financeiro (payback
analysis)
 Retorno do investimento (return on
investments)
 Valor atual líquido (Net present value)

16
Análise de Retorno do
Investimento
 A técnica de análise de retorno do
investimento (ROI) compara os benefícios
das diferentes soluções ou projetos
 O ROI para uma solução ou projeto é a taxa
percentual que mede a relação entre a
quantia que a empresa obtém de retorno ao
seu investimento e a quantia investida

17
Análise de Retorno do
Investimento
 O ROI para uma solução ou projeto
potencial é calculado como a seguir:
 ROI = (Benefícios totais - Custos totais) /
Custos totais
 ROI = valor atual líquido / Custos totais
 Ex: ROI = (22508,64-17321,20)/ 17321,20= 29,95%
 EX: ROI = 5187,44/ 17321,20 = 29,95%
 A solução que oferecer o ROI mais alto é a
melhor alternativa

18
Matriz de Viabilidade
 Como nós comparamos alternativas
quando existem vários critérios de
seleção e nenhuma das alternativas é
superior em todos os aspectos?
 Use uma Matriz de Análise de
Viabilidade!

19
Relatório de Viabilidade
 Após o esforço inicial, discutido
anteriormente, deve-se elaborar um
relatório de viabilidade
 Para cada aspecto apresentado, deve
haver seção de avaliação
 Deve haver uma seção conclusiva sobre a
melhor alternativa ou que o sistema não é
viável

20
Exercício
 Determine a viabilidade de (+ROI):
 1. Sistema para uma padaria de pequeno
porte (Só caixa, no balcão também, etc.);
 2. Sistema inteligente de preenchimento
do IRPF pela própria pessoa física;
 3. Sistema para gerar alocação de
docentes, salas, horários, local de forma
otimizada.

21
Elicitação de requisitos e
análise
 Esta atividade divide-se em dois
esforços maiores:
 Elicitação dos requisitos em si
 Técnicas de elicitação
 Análise do que foi elicitado
 Processo de análise

22
Que é um requisito?
 Tanto pode ser
 Uma declaração abstrata de alto nível de
um serviço
 Como uma restrição do sistema
 Quanto uma especificação funcional
matemática detalhada

23
Elicitação de Requisitos
 Também denominada de descoberta de
requisitos
 Envolve pessoal objetivando descobrir o
domínio de aplicação, serviços que devem
ser fornecidos bem como restrições
 Deve envolver usuários finais, gerentes,
pessoal envolvido na manutenção,
especialistas no domínio, etc.
(Stakeholders).
24
Visão dos Requisitos
 Requisitos do Usuário
 Declarações em linguagem natural com
diagramas de serviços que o sistema deve
oferecer e suas restrições operacionais.
Escrito para os clientes
 Requisitos do Sistema
 Documento estruturado com descrições
detalhadas sobre os serviços do sistema.
Contrato entre cliente e fornecedor

25
Tipos de Requisitos
 Requisitos Funcionais

 Requisitos Não-Funcionais

 Requisitos de Domínio

26
Requisitos Funcionais
 Descreve funcionalidade e serviços do
sistema
 Depende do
 Tipo do software
 Usuários esperados
 Tipo do sistema onde o software é usado

27
Exemplos de R.F.
 [RF001] Usuário pode pesquisar todo ou um
sub-conjunto do banco de dados
 [RF002] Sistema deve oferecer
visualizadores apropriados para o usuário
ler documentos armazenados
 [RF003] A todo pedido deve ser associado
um identificador único (PID), o qual o
usuário pode copiar para a área de
armazenamento permanente da conta
28
Exercício
 Dê alguns exemplos de R.F.s para:
 1. Sistema da padaria de pequeno porte;
 2. Sistema inteligente de preenchimento
do IRPF;
 3. Sistema de alocação docente.

29
Requisitos Não-Funcionais
 Definem propriedades e restrições do
sistema (tempo, espaço, etc)
 Requisitos de processo também podem
especificar o uso de determinadas
linguagens de programação, método de
desenvolvimento
 Requisitos não-funcionais podem ser mais
críticos que requisitos funcionais. Não
satisfaz, sistema inútil.
30
Requisitos Não-Funcionais
 Devido à sua própria definição,
requisitos não-funcionais são
esperados mensuráveis
 Assim, deve-se associar forma de
medida/referência a cada requisito
não-funcional elicitado

31
 Medidas de Requisitos
(Não-Funcionais)
Propriedade Medida
Velocidade Transações processadas/seg
Tempo de resposta do usuário/evento
Tamanho K bytes
No de chips de RAM
Facilidade de uso Tempo de treinamento
No de quadros de ajuda
Confiabilidade Tempo médio de falhas
Probabilidade de indisponibilidade
Taxa de ocorrência de falhas
Robustez Tempo de reinício após falha
Percentual de eventos causando falhas
Probabilidade de corrupção de dados após falha
Portabilidade Percentual de declarações dependentes do destin
No de sistemas destino
32
Classificação de R. N. F.
 Requisitos do Produto
 Produto deve comportar-se de forma particular
(velocidade de execução, confiabilidade, etc.)
 Requisitos Organizacionais
 Conseqüência de políticas e procedimentos
organizacionais (padrões de processo usados,
requisitos de implementação, etc.)
 Requisitos Externos
 Conseqüência de fatores externos ao sistema e
ao processo de desenvolvimento (legislação,
etc.)

33
Exemplos de R. N. F.
 Requisitos do Produto
 [RNF001] Toda consulta ao B.D., baseada em
código de barras, deve resultar em até 5 s
 Requisitos Organizacionais
 [RNF002] Todos os documentos entregues
devem seguir o padrão de relatórios XYZ-00
 Requisitos Externos
 [RNF003] Informações pessoais do usuário não
devem ser vistas pelos operadores do sistema

34
Exercício
 Dê alguns exemplos de R.N.F.s para:
 1. Sistema da padaria de pequeno porte;
 2. Sistema inteligente de preenchimento
do IRPF;
 3. Sistema de alocação docente.

35
Requisitos de Domínio
 Derivados do domínio da aplicação e
descrevem características do sistema e
qualidades que refletem o domínio
 Podem ser requisitos funcionais novos,
restrições sobre requisitos existentes ou
computações específicas
 Se requisitos de domínio não forem
satisfeitos, o sistema pode tornar-se
impraticável
36
Requisitos de Domínio
(Problemas)
 Entendimento
 Requisitos são descritos na linguagem do
domínio da aplicação
 Não é entendido pelos engenheiros de
software que vão desenvolver a aplicação
 Implicitude
 Especialistas no domínio entendem a área
tão bem que não tornam todos os
requisitos de domínio explícitos

37
Requisitos de Domínio
(Exemplo 1)
 A desaceleração do trem deve ser
computada através da fórmula
Dtrem=Dcontrole+Dgradiente onde ...

38
Exercício
 Dê alguns exemplos de domínio para:
 1. Sistema da padaria de pequeno porte;
 2. Sistema inteligente de preenchimento
do IRPF;
 3. Sistema de alocação docente.

39
 Requisitos
Requisitos

Usuário  Sistema

Funcionais Não-funcionais Domínio

Produto Organização Externo

40
Técnicas de Elicitação
 Entrevistas
 Questionários
 Casos de Uso
 Jogo de Funções
 Brainstorming
 Workshop de Requisitos

41
Entrevistas
 Técnica direta
 Pode ser usada na análise do problema e na
elicitação de requisitos
 Objetivo
 Entender os problemas reais e soluções
potenciais das perspectivas dos usuários,
clientes, e outros stakeholders

42
Entrevistas
 Quem são o cliente e o usuário?
 Possuem necessidades diferentes?
 Quais são suas
 Capacidades
 Backgrounds
 Ambientes, etc.
 Qual é o problema?
 Como é resolvido atualmente?
43
 Entrevistas
 Qual a razão para resolvê-lo?
 Qual o valor de uma solução bem-
sucedida?
 Onde mais uma solução pode ser
encontrada?

Note que algumas dessas perguntas já

foram feitas no estudo de viabilidade.
44
Questionários
 Aplicabilidade a mercados específicos
 Onde perguntas são bem definidas
 Hipóteses
 Perguntas relevantes podem ser decididas
antecipadamente
 Leitor ouve da maneira desejada
 Suprime o que é bom sobre análise
 Úteis após uma entrevista inicial

45
Casos de Uso
 Discuta com o cliente o que o sistema
fará
 Identique quem interage com o
sistema
 Identique que interfaces o sistema
terá

46
Casos de Uso
 Verifique se não há requisitos
faltando
 Verifique que os desenvolvedores
entendem os requisitos
 Vantagem é ter apelo visual dos
requisitos mais relevantes do cliente

47
Jogo de Funções
 Engenheiro de requisitos
 Assume a função do usuário ou cliente

Entender o domínio do problema
 Cliente
 Assume a função do usuário

Entender os problemas que podem passar

48
Brainstorming
 Regras para Brainstorming
 Estabeleça o objetivo da sessão
 Gere quantas idéias for possível
 Deixe sua imaginação livre
 Não admita críticas ou debates
 Ajuste e combine as idéias

49
 Workshop de Requisitos
 Põe todos os stakeholders
juntos por um período
intensivo (focado)
 Facilitador conduz a reunião
 Todos têm sua vez de falar
 Resultados são disponíveis
imediatamente
 Provê um ambiente para
aplicar outras técnicas de
elicitação

50
Exercício
 Quais técnicas poderiam ser usadas
em:
 1. Sistema da padaria de pequeno porte;
 2. Sistema inteligente de preenchimento
do IRPF;
 3. Sistema de alocação docente.

51
 Análise de Requisitos
Definição e
Documento
especificação
de requisitos
de requisitos
7 8

Validação
dos requisitos
Entendimento 6
Atrib. Prioridade
Entrada do do domínio
1
processo 5

2 4
Coleta de Resolução
requisitos de conflito
3

Classificação
52
Entendimento do Domínio
 Desenvolver sistemas envolve domínios
além de software e hardware
 Podemos ter que entender sobre
 Contabilidade
 Saúde
 Supermercados
 Etc.

53
Coleta de Requisitos
 Como vimos anteriormente, a coleta de
requisitos é feita através de técnicas
 Nesta etapa, os requisitos são
simplesmente documentados à medida
que são coletados
 Resulta em documento preliminar
(draft)

54
Classificação dos Requisitos
 Esta etapa consiste basicamente em
agrupar os diversos requisitos coletados
em categorias (clusters) bem-definidos
 Por exemplo
 Deve ser possível consultar o preço de uma
mercadoria
 A consulta deve retornar uma resposta em no
máximo 5s

55
Problema da Análise de
Requisitos
 Stakeholders em geral não sabem o
que querem
 Stakeholders expressam requisitos
em sua terminologia
 Stakeholders diferentes podem gerar
requisitos conflitantes

56
Problema da Análise de
Requisitos
 Fatores políticos e organizacionais
podem influenciar os requisitos do
sistema
 Requisitos mudam durante o processo
de análise. Stakeholders novos podem
surgir e o ambiente de trabalho
mudar

57
Resolução de Conflitos
 É normal que ocorram requisitos
conflitantes
 Por exemplo
 R-23: O sistema deve ...
 R-45: O sistema não deve ...
 Cliente/usuário deve ser consultado
para resolver conflitos
(ambigüidades)

58
Atribuição de Prioridade
 Alguns requisitos são mais urgentes
que outros
 É essencial determinar a prioridade
dos requisitos junto ao cliente
 Requisitos de maior prioridade são
considerados em primeiro lugar

59
Prioridade
 Requisitos podem ser vistos em três
classes distintas
 Essenciais
 Importantes
 Desejáveis
 Em princípio, sistema deve resolver
todos os requisitos de essenciais para
desejáveis

60
Exemplo de Prioridade
 [RF001] Consulta X ao B.D. deve retornar
dados A, B, C
 Prioridade: Essencial
 [RNF001] Consulta X ao B.D. deve visualizar
dados segundo padrão Y
 Prioridade: Importante
 [RNF010] Consulta X ao B.D. deve usar
cores azuis nos resultados
 Prioridade: Desejável

61
Validação dos Requisitos
 Será que realmente entendi o que o
cliente deseja?
 Devo me certificar de que não houve
falha em nossa interação
(comunicação)
 Há diversas técnicas de validação

62
Validação de Requisitos
 Demonstrar que os requisitos definem o
sistema que o cliente realmente deseja
 Custos com erros de requisitos são altos
 Consertar um erro de requisitos após entrega
do sistema pode custar mais de 100 vezes o
custo de um erro de implementação

63
Técnicas de Validação de
Requisitos
 Revisões de Requisitos
 Análise manual sistemática dos requisitos
 Prototipação
 Uso de modelo executável do sistema para
avaliar requisitos
 Geração de Casos de Teste
 Desenvolver testes específicos para os
requisitos para avaliá-los
 Análise de Consistência Automática
 Avaliar uma especificação dos requisitos

64
Gerenciamento de Requisitos
 Gerenciamento de requisitos é o
processo de controlar as mudanças
dos requisitos durante
 O processo da engenharia de requisitos
 E desenvolvimento do sistema

65
Gerenciamento de Requisitos
 Requisitos são inevitavelmente incompletos
e inconsistentes
 Requisitos novos surgem durante o processo de
acordo com mudanças nas necessidades do
negócio e um entendimento melhor do sistema é
desenvolvido
 Diferentes pontos de vista têm diferentes
requisitos e esses geralmente são
contraditórios

66
Rastreamento
 Responsável por dependências entre
requisitos, suas origens e projeto do
sistema
 Rastreamento de Origem
 Associação entre requisitos e
stakeholders que propuseram tais
requisitos

67
Rastreamento
 Rastreamento de Requisitos
 Associação entre requisitos dependentes
 Rastreamento de Projeto
 Associação dos requisitos com o projeto
 Usar hipertexto ou referência
cruzada
 Ou matriz de rastreamento

68
 Rastreamento
1.Rastrear requisitos do
Requisitos usuário nos do sistema
Produto Req A 2.Rastrear requisitos no
(Características) projeto
1 3.Rastrear requisitos nos
procedimentos de teste
Requisitos 4.Rastrear requisitos do
Detalhados Req B usuário no plano
(Casos de Uso)
2 3 4

Projeto Teste Doc. Usuário

Modelos Suítes Teste Plano 69

 Rastreamento: Análise de
Impacto
Req A antes Req A depois
“if return value > $5” “if return value > $2”

Req B Req B

Req C Req C

 Links dos requisitos devem ser marcados como

“revisar”
 Links “revisar” devem ser analisados
70
Documento de Requisitos
 Fonte: IEEE/ANSI (830-1998)
 1. Introdução
 1.1 Propósito do documento
 1.2 Escopo do sistema
 1.3 Definições, acrônimos e abreviaturas
 1.4 Referências
 1.5 Descrição do resto do documento

71
Documento de Requisitos
 Fonte: IEEE/ANSI (830-1998)
 2. Descrição geral
 2.1 Perspectiva do produto
 2.2 Funções do produto
 2.3 Características dos usuários
 2.4 Restrições gerais
 2.5 Assertivas e dependências

72
Documento de Requisitos
 Fonte: IEEE/ANSI (830-1998)
 3. Requisitos específicos
 requisitos funcionais, não-funcionais, GUI com
o usuário:
 funcionalidade, interfaces externas,

desempenho, restrições, atributos do

sistema, caract. qualidade, ...
 Apêndices
 Índice
73
Diagramas de Casos de Uso

Alexandre Vasconcelos
(amlv@cin.ufpe.br)

74
Objetivos
 Introduzir conceitos de use case,
ator e fluxo de eventos
 Apresentar sub-fluxos de eventos
 Discutir sobre identificação, evolução
e organização de use cases
 Apresentar notação UML para reusar
atores e use cases

75
 Use Case
 Seqüência de
ações, executada
pelo sistema, que
gera um resultado
 De valor observável
Função  E para ator
particular

Procedimento computacional/algorítmico atômico

76
 Use Case e Ator
 Alguém ou alguma
coisa (fora do
sistema) que
interage com o
sistema

Emissor/Receptor

77
 Use Case e Ator

Resultado de Valor Observável

Ator Particular

Função
Emissor

Função
Receptor
78
Use Case e Ator
 A descrição de um use case define o
que o sistema faz quando o use case é
realizado
 A funcionalidade do sistema é
definida por um conjunto de use
cases, cada um representando um
fluxo de eventos específico

79
 Use Case e Ator
Descrição

Passo 1
Passo 2
…
Passo N

Emissor
Função
80
Exemplo de Use Case e Ator
 Cliente de banco pode usar um caixa
automático para
 sacar dinheiro, transferir dinheiro ou
consultar o saldo da conta
 Ator: Cliente
 Use cases: Sacar dinheiro, transferir
dinheiro e consultar saldo

81
 Exemplo de Use Case e Ator
Valor de
resultado
observável

Transferir
dinheiro

Sacar Consultar
dinheiro saldo

Cliente 82
Identificando Use Cases
 Em geral, difícil decidir entre um ou
vários use cases
 Por exemplo, seriam use cases
 Inserir cartão em um Caixa Automático?
 Entrar com a senha?
 Receber o cartão de volta?

83
Identificando Use Cases
 Representar valor observável para
ator
 Pode-se determinar
 De interações (seqüência de ações) com o
sistema que resultam valores para atores
 Satisfaz um objetivo particular de um
ator que o sistema deve prover

84
Identificando Use Cases
 Facilitar gerenciamento durante ciclo
de desenvolvimento
 A razão para agrupar funcionalidades e
chamá-las de use cases

85
Exercício
 Tenho um sistema que é acionado 2
vezes por dia (às 10:20hs e 17:20hs),
enviando-me um SMS. Também tenho
como obter resultado semelhante
acessando tal funcionalidade a partir
de meu celular (web browser). Crie os
casos de uso correspondentes.

86
Evolução de Use Cases
 Inicialmente use cases são simples
 Apenas esboço sobre funcionamento é
suficiente
 Mas com a sedimentação da modelagem
 Descrição mais detalhada do fluxo de eventos
faz-se necessária
 Fluxo de eventos deve ser refinado
 Todos os stakeholders envolvidos devem estar
de acordo com a descrição

87
Organizando Use Cases
 Sistema pequeno não demanda
estruturação
 Exemplo, seis use cases, com dois/três
atores
 Já sistemas maiores requerem
princípios de estruturação e
organização
 Caso contrário, planejamento, atribuição
de prioridades, etc., podem se tornar
difíceis 88
Pacote de Use Case
 Primeiro esforço de estruturação
 Agrupam-se use cases relacionados
em único container

89
Pacote de Use Cases

Clientes
Clientes :: Atendimento

90
Reuso em Use Cases
 Comportamento comum a mais de dois
use cases (ou forma parte
independente)
 Pode-se modelar como use case para ser
reusado
 Há três possibilidades
 Inclusão
 Extensão
 Generalização/Especialização
91
Inclusão
 Vários use cases possuem texto de
fluxo de eventos
 Comum/idêntico
 Sempre usado
 Equivalente a fatoração feita em
programação através de sub-
programas
 #include da linguagem C
92
Inclusão
 Como exemplo, tanto “Sacar dinheiro”
quanto “Consultar saldo” necessitam da
senha
 Pode-se criar novo use case “Autenticar
usuário” e incluí-lo
 Mas atenção
 NÃO SE DEVE CRIAR USE CASES MÍNIMOS
 Deve haver ganho no reuso

93
Inclusão

Autenticar
<< include >> << include >>
usuário

Sacar Consultar
dinheiro saldo

94
Inclusão
 Descrição de Consultar saldo
 Fluxo de Eventos Principal:
 include (Autenticar usuário). Sistema pede a
Cliente que selecione tipo de conta (corrente,
etc). ...

95
Extensão
 Use case pode ser estendido por
outro
 Extensão de funcionalidade/Caso
excepcional
 Extensão ocorre em pontos
específicos
 Pontos de extensão

96
Extensão
 Há também inclusão de texto (fluxo
de eventos)
 Porém sob condições particulares
 Pode ser usada para
 Simplificar fluxos de eventos complexos
 Representar comportamentos opcionais
 Lidar com exceções

97
 Extensão

<< extend >>

(urgente)

Atendimento Atendimento
de urgência
Pontos de extensão
urgente

98
Extensão
 Descrição de Atendimento
 Fluxo de Eventos Principal:
 Colete os itens do pedido. (urgente).
Submeta pedido para processamento.

99
Especialização
 Use case pode especializar outro
 Adição/refinamento do fluxo de eventos
original
 Especialização permite modelar
comportamento de estruturas de
aplicação em comum

100
 Especialização

∆
Atendimento Atendimento
de urgência

∆
Cliente Cliente
comercial 101
Fluxo de Eventos
 Parte mais importante de um use case
 Atividade de requisitos
 Define a seqüência de ações entre o
ator e o sistema

102
Fluxo de Eventos
 Geralmente em linguagem natural
 Uso preciso de termos definidos no
glossário de acordo com o domínio do
problema
 Também expresso formalmente
 Pré e pós-condições (ou pseudo-código)

103
Exemplo de Fluxo de Eventos
 Um esboço inicial sobre Sacar
dinheiro seria
1. O use case inicia quando o Cliente
insere um cartão no CA. Sistema lê e
valida informação do cartão
2. Sistema pede a senha. Cliente entra
com a senha. Sistema valida a senha.
3. Sistema pede seleção do serviço.
Cliente escolhe “Sacar dinheiro”

104
Exemplo de Fluxo de Eventos
 Um esboço inicial sobre Sacar
dinheiro seria
4. Sistema pede a quantia a sacar. Cliente
informa.
5. Sistema pede seleção da conta
(corrente, etc). Cliente informa.
6. Sistema comunica com a rede para
validar a conta, senha e o valor a sacar.

105
Exemplo de Fluxo de Eventos
 Um esboço inicial sobre Sacar
dinheiro seria
7. Sistema pede remoção do cartão.
Cliente remove.
8. Sistema entrega quantia solicitada.

106
Exercício
 Remodele exercício anterior para
mostrar a situação excepcional
quando o serviço pode ser solicitado
pelo browser do celular.

107
Fluxo de Eventos
 Na descrição do que o sistema faz
através de fluxos de eventos
completos
 Surgem caminhos alternativos
 Casos diferentes a considerar
 Efeitos/valores diferentes a produzir
 Eventualmente descreve todos esses
caminhos possíveis
108
Sub-fluxos de Eventos
 Fluxo de eventos visto como
 Vários sub-fluxos de eventos
 Sub-fluxos são descritos como
 Principal
 Alternativos/excepcionais
 Abordagem visa reuso de fluxos de
eventos (sub-fluxos)

109
Exemplo de Sub-fluxos
 Seja o use case Validar usuário
 Fluxo principal:
 O use case inicia quando o sistema pede ao Cliente a
senha. Cliente entra com senha. Sistema verifica se a
senha é válida. Se a senha é válida, sistema confirma e
termina o use case.
 Fluxo excepcional:
 Cliente pode cancelar a transação a qualquer momento
pressionando a tecla ESC, reiniciando o use case. Nenhuma
modificação é feita na conta do Cliente.
 Fluxo excepcional:
 Se Cliente entra com senha inválida, o use case reinicia.

110
Diagrama de Atividades
 Descreve fluxo de tarefas
 Aspectos dinâmicos de um sistema
 Podem também ser usados para criar
sistemas executáveis

Depende do nível de detalhamento e grau de
execução dos elementos usados
 Alternativa para modelar fluxos de
eventos de casos de uso

111
Diagrama de atividades: exemplo

112
Exercício
 Remodele o exercício anterior usando
um diagrama de atividade no lugar de
linguagem natural

113
Diagramas de Use Cases
 Caracterizar limites da funcionalidade
do sistema
 Use cases são organizados dentro de um
diagrama
 Em diagramas de use cases
 Atores são relacionados por
generalização/especialização

114
 Exemplo de Diagrama
Sistema de validação
de cartão de crédito

Transação de
cartão

Cliente Instituição
∆ ∆ Processa
fatura vendedora

Reconcilia
transações

Cliente Cliente
Gerencia
individual corporativo conta
Financeira

115
Bibliografia
 Sommerville, I. Software Engineering
 Kruchten, P. The Rational Unified
Process: An Introduction. 2nd Ed
 Booch, G. et al. The Unified Modeling
Language User Guide.

116