Engenharia de Software

Aula 4 – Engenharia de Requisitos

Problema chave
• Comunicação

3
Sei que você credita que
entendeu o que acha que eu
disse, mas não estou certo de
que percebe que aquilo que
ouviu não é o que eu pretendia
dizer !

4
5
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
6
sistema requisitos
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

7
Estudo de Viabilidade
• Estudo que indica se o esforço em desenvolver a
ideia vale a pena
• Visa tanto a tomada de decisão
• Como a sugestão de possíveis alternativas de
solução

8
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?
9
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?

10
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

11
Testes de Viabilidade e
Anaá lises de Riscos
• 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 12
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
13
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
14
sobre o problema (solução)?
Viabilidade Teá 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?

15
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
16
Viabilidade Econoô 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
17
• Isso é chamado de análise de custo-benefício
Tipos de Custos
Quais os principais componentes de custo de
projeto de software?

A estimativa de custo de projeto e,

especificamente, software requer conhecimento
da demanda do cliente, bem como levantamento
dos principais componentes diretos de custo que
compreende:

18
Tipos de Custos
• Esforço para o projeto (composto da equipe e
duração da participação de cada membro na
execução do projeto).
• Infraestrutura para o projeto (hardware, licenças de
software, acesso a rede).
• Treinamentos necessários aos membros da equipe.
• Viagens, reuniões, eventos, etc.

19
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!

20
21
Relatoá 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

22
Elicitação e análise
de requisitos

23
Elicitaçaã o de requisitos e anaá 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

24
Que eá 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

25
Elicitaçaã o de Requisitos
• Também denominada de descoberta de
requisitos ou levantamento 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).

26
Elicitaçaã o: Maximizar a
satisfaçaã o do cliente!
• Requisito normal
• O cliente lembra de falar
• O cliente ficará satisfeito se esse requisito estiver no sistema
• Requisito esperado
• Requisito implícito
• O cliente não lembra de falar
• O cliente ficará insatisfeito se esse requisito não estiver no
sistema
• Requisito excitante
• O cliente não lembra de falar
• O cliente não espera encontrar esse requisito no sistema
• O cliente ficará satisfeito se esse requisito estiver no sistema 27
Visaã o dos Requisitos
• Requisitos do Usuário
• Declarações em linguagem natural ou 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

28
Cliente x Usuaá rio final
• Nem sempre o cliente é o usuário final
• Cliente
• Quem contrata e paga pelo serviço
• Ex.: Administrador de um hospital
• Usuário final
• Quem usa o software no dia a dia
• Ex.: Médicos e enfermeiros
• Importante
• Nunca deixe de elicitar requisitos com os usuários
finais pois sem a colaboração deles, o software não 29
será usado
Tipos de Requisitos
• Requisitos Funcionais

• Requisitos Não-Funcionais

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

31
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
32
Requisitos Naã 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.

33
Requisitos Naã 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

34
 Medidas de Requisitos
(Naã 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
35
destino
No de sistemas destino
Classificaçaã 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.)

36
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 segundos
• 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
37
Exercíácio
• Descreva os requisitos de uma agenda eletrônica no
papel
• Lista de requisitos funcionais
• Requisitos normais
• Requisitos esperados
• Requisitos excitantes
• Lista de requisitos não funcionais

38
Validaçaã o dos requisitos
Questões
1.Os requisitos estão claros?
2.A fonte dos requisitos está identificada?
3.Os requisitos foram mostrados para essa fonte?
4.Os requisitos estão descritos de forma quantitativa?
5.Os requisitos estão relacionados via referência
cruzada?
6.Os requisitos violam alguma restrição do domínio?
7.O requisito é testável? Os testes foram especificados?
8.Os requisitos são rastreáveis para os modelos e o
código subsequente?
9.Existem requisitos implícitos?
39
Validaçaã o dos requisitos:
Evite ambiguidades
Exemplos de ambiguidade
1.A janela deve abrir rapidamente
2.O sistema deve ser flexível
3.O cálculo deve ser eficiente
4.A interface com o usuário deve ser melhor que a atual
5.Não devem ser mostradas muitas mensagens de erro
6.A exibição do mapa de navegação deve ser amigável

40
Teá cnicas de Elicitaçaã o
• Entrevistas
• Questionários
• Casos de Uso
• Jogo de Funções
• Brainstorming
• Workshop de Requisitos

42
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

43
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?
44
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?

45
Questionaá rios
• Aplicabilidade a mercados específicos
• Onde perguntas são bem definidas
• Hipóteses
• Perguntas relevantes podem ser decididas
antecipadamente
• Suprime o que é bom sobre análise
• Em média 10 a 15 entrevistas são suficientes para
determinar um conjunto relevante de questões
• Úteis após uma entrevista inicial
46
Casos de Uso
• Discuta com o cliente o que o sistema fará
• Identique quem interage com o sistema
• Identique que interfaces o sistema terá

47
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

48
Jogo de Funçoã 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

49
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

50
Brainstorming
• Útil na geração de uma ampla variedade de
pontos de vista sobre o problema e na
formulação do mesmo de diferentes maneiras
• Útil no início do processo de extração de
requisitos
• Técnica básica para geração de idéias
• Permite que pessoas sugiram e explorem idéias
sem que sejam criticadas e julgadas
• Funciona melhor com um número mínimo de
51
quatro e máximo de dez pessoas
 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

52
 Anaá 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 53

Classificação
10 princíápios de engenharia
de requisitos
Primeiro passo para se resolver um problema é entender
o problema – Não basta comunicar, é necessário
entender!
•Princípio 1: Escute
• Tente prestar a atenção no que o interlocutor fala
• Evite interromper a linha de raciocínio do interlocutor
• Peça detalhes de algo que não ficou claro
• Não desestimule seu interlocutor com gestos ou palavras
•Princípio 2: Se prepare antes da reunião
• Tente entender o problema antes da reunião
• Tente compreender qual é o jargão utilizado no domínio
• Elabore uma agenda para a reunião
54
10 princíápios de engenharia
de requisitos
• Princípio 3: É importante ter um mediador
• O mediador é responsável por manter a reunião com foco
apropriado
• O mediador é responsável por resolver conflitos

• Princípio 4: Comunicação face a face é o ideal

• Na comunicação face a face é possível perceber gestos
• A dedicação na comunicação face a face é maior

• Princípio 5: Tome nota das decisões

• Em pouco tempo, não será possível saber por que uma
decisão foi tomada
• É fundamental documentar as razões de cada decisão 55
10 princíápios de engenharia
de requisitos
• Princípio 6: Estimule colaborações
• Duas ou mais mentes pensam melhor que uma
• Colaborações geram cumplicidade na equipe

• Princípio 7: Mantenha o foco

• Evite que o reunião se desvie muito do seu objetivo
• Lembre às pessoas o que ainda precisa ser visto

• Princípio 8: Se algo estiver obscuro, desenhe!

• Representações visuais ajudam a uniformizar ideias
• Faça uso de papel e quadro branco em abundância

56
10 princíápios de engenharia
de requisitos
• Princípio 9: Siga em frente!
• Se concordarem, sigam em frente
• Se discordarem, sigam em frente
• Se estiverem em dúvida e não for possível tirar a dúvida no
momento, sigam em frente

• Princípio 10: Negociação não é um jogo

• Busque por soluções boas para ambas as partes
• Ceda em aspectos que não são fundamentais
• Brigue somente pelas batalhas que valem a pena

57
UML – Unified Modeling
Language

58
O que eá a UML?
• Linguagem Gráfica de Modelagem para:
• Visualizar
• Especificar
• Construir
• Documentar
• Comunicar
Artefatos de sistemas complexos
• Linguagem: vocabulário + regras de
combinação
Modelos
• O que é um modelo?
• Um modelo é uma simplificação
(representação/abstração) da realidade

• O que modelamos?
• Dimensões: dados, função, comportamento…
Objetivos da Modelagem
• Compreender melhor o sistema que estamos
desenvolvendo
• Visualizar o sistema
• Documentar decisões tomadas
• Especificar comportamento ou a estrutura de um
sistema
A UML naã o eá

• Um processo
• Uma metodologia
• Análise e Projeto OO
• Regras de projeto
 BOOCH UML OMT
 Diagrama de Estados  Diagrama de Estados
 Diagrama de Objetos  Diagrama de Classes
(Colaboração)
 Diagrama de Processo
(Desenvolvimento)
 Diagrama de Módulos  Use Case
(Componentes)  Subsistemas
OOSE (Package)
 Diagrama de
Interações
 MiniEspecificação
Diagramas
• Apresentações gráficas de um conjunto de
elementos, geralmente representadas como
gráficos de vértices (itens) e arcos
(relacionamentos)
• Nove tipos: classes, objetos, pacotes, casos de
uso, sequências, colaborações, estados,
atividades, componentes e implantação
Quais diagramas iremos
estudar?
• Diagrama de Casos de Uso;
• Diagrama de Classes;
• Diagrama de Sequência;
• Diagrama de Estados;
• Diagrama de Atividades;

65
Diagramas de Casos
de Uso
66
 Use Case
• Seqüência de ações,
executada pelo
sistema, que gera um
Função resultado
• De valor observável
• E para ator particular

Procedimento computacional/algorítmico atômico

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

Emissor/Receptor

68
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

69
Use Case e Ator

Descrição

Passo 1
Passo 2
…
Passo N

Emissor
70
Função
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 ...

71
Exemplo de Use Case e Ator

Valor de
resultado
observável

Transferir
dinheiro

Sacar Consultar
dinheiro saldo 72

Cliente
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?

73
Identificando Use Cases
• Representar valor observável para ator
• Pode-se determinar
• A partir 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

74
Por que criar casos de uso?
• Facilitar gerenciamento durante ciclo de
desenvolvimento
• A razão para agrupar funcionalidades e chamá-
las de use cases

75
Exercíácio
• Uma loja de CDs possui discos para venda. Um
cliente pode comprar uma quantidade ilimitada
de discos, sendo que para isto ele deve se dirigir
à loja. A loja possui um atendente cuja função é
atender os clientes durante a venda dos discos. A
loja também possui um gerente cuja função é
administrar o estoque para que não faltem
discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os
clientes durante a venda dos discos. 76
Exercíácio
• Uma loja de CDs possui discos para venda. Um
cliente pode comprar uma quantidade ilimitada
de discos, sendo que para isto ele deve se dirigir
à loja. A loja possui um atendente cuja função é
atender os clientes durante a venda dos discos. A
loja também possui um gerente cuja função é
administrar o estoque para que não faltem
discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os
clientes durante a venda dos discos. 77
Exercíácio

78
Exercíácio
• Uma loja de CDs possui discos para venda. Um
cliente pode comprar uma quantidade ilimitada
de discos, sendo que para isto ele deve se dirigir
à loja. A loja possui um atendente cuja função é
atender os clientes durante a venda dos discos. A
loja também possui um gerente cuja função é
administrar o estoque para que não faltem
discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os
clientes durante a venda dos discos.
79
Exercíácio

Atendente

Gerente 80
Evoluçaã 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

81
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

82
Elementos – Diagrama de
Casos de Uso
• Elementos do diagrama:

• Atores
• Casos de uso
• Relacionamentos
• Associação
• Generalização
• Dependência: Extensão e Inclusão
Elementos – Diagrama de
Casos de Uso
• Elementos do diagrama

• Atores
• Casos de uso
• Relacionamentos
• Associação
• Generalização
• Dependência: Extensão e Inclusão
Elementos – Diagrama de
Casos de Uso
• Atores
• Representam os papéis desempenhados por
elementos externos ao sistema
• Ex: humano (usuário), dispositivo de hardware ou
outro sistema
• Elementos que interagem com o sistema

Notação: Sistema de
Secretária Diretor Relatórios
(from Use Case View) (from Use Case View) (from Use Case View)
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando os atores

• Uma loja de CDs possui discos para venda. Um cliente

pode comprar uma quantidade ilimitada de discos para
isto ele deve se dirigir à loja. A loja possui um atendente
cuja função é atender os clientes durante a venda dos
discos. A loja também possui um gerente cuja função é
administrar o estoque para que não faltem discos. Além
disso é ele quem dá folga ao atendente, ou seja, ele
também atende os clientes durante a venda dos discos.
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando os atores

Gerente Atendente
(from Use Case View) (from Use Case View)

• E o cliente?
• Não é ator pois ele não interage com o sistema!
Elementos – Diagrama de
Casos de Uso
• Elementos do diagrama

• Atores
• Casos de uso
• Relacionamentos
• Associação
• Generalização
• Dependência: Extensão e Inclusão
• Fronteira do sistema
 Elementos – Diagrama de
Casos de Uso
• Caso de Uso
• Representa uma funcionalidade do sistema
(um requisito funcional)

• É iniciado por um ator ou por outro caso de uso

Dicas:
Nomeie os casos de uso iniciando por um verbo

Notação: Nome do Caso de Uso

Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs
Identificando os casos de uso

• Uma loja de CDs possui discos para venda. Um cliente

pode comprar uma quantidade ilimitada de discos
para isto ele deve se dirigir à loja. A loja possui um
atendente cuja função é atender os clientes durante a
venda dos discos. A loja também possui um gerente
cuja função é administrar o estoque para que não
faltem discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os clientes
durante a venda dos discos.
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando os casos de uso

Vender CDs

Administrar estoque
Elementos – Diagrama de
Casos de Uso
• Elementos do diagrama

• Atores
• Casos de uso
• Relacionamentos
• Associação
• Generalização
• Dependência: Extensão e Inclusão
• Fronteira do sistema
Elementos – Diagrama de
Casos de Uso
• Relacionamento de associação
• Indica que há uma interação (comunicação) entre
um caso de uso e um ator
• Um ator pode se comunicar com vários casos de uso

Notação:

interação
Ator Caso de Uso
(from Use Case Vi ew)
(from Use Case View)
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando os relacionamentos de associação

• Uma loja de CDs possui discos para venda. Um cliente pode

comprar uma quantidade ilimitada de discos para isto ele deve se
dirigir à loja. A loja possui um atendente cuja função é atender os
clientes durante a venda dos discos. A loja também possui um
gerente cuja função é administrar o estoque para que não faltem
discos. Além disso é ele quem dá folga ao atendente, ou seja, ele
também atende os clientes durante a venda dos discos.
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando os relacionamentos de associação

Vender CDs

Atendente

Administrar estoque

Gerente
Elementos – Diagrama de
Casos de Uso
• Elementos do diagrama

• Atores
• Casos de uso
• Relacionamentos
• Associação
• Generalização
• Dependência: Extensão e Inclusão
• Fronteira do sistema
Elementos – Diagrama de
Casos de Uso
• Relacionamento de generalização
Generalização de atores
• Quando dois ou mais atores podem se comunicar
com o mesmo conjunto de casos de uso
• Um filho (herdeiro) pode se comunicar com todos
os casos de uso que seu pai se comunica.

Notação:
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando generalização de atores

Vender CDs

Atendente

Administrar estoque

Gerente
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando generalização de atores

Vender CDs

Atendente

Administrar estoque

Gerente
Elementos – Diagrama de
Casos de Uso
• Relacionamento de generalização
Generalização de casos de uso
• O caso de uso filho herda o comportamento e
o significado do caso de uso pai
• O caso de uso filho pode incluir ou sobrescrever o
comportamento do caso de uso pai
• O caso de uso filho pode substituir o caso de uso pai
em qualquer lugar que ele apareça

Notação:
Pai

Filho 1 Filho 2
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs
Identificando generalização de casos de uso
Novos requisitos:
• As vendas podem ser à vista ou a prazo. Em ambos os casos o estoque é
atualizado e uma nota fiscal, entregue ao consumidor.

• No caso de uma venda à vista, clientes cadastrados na loja e que compram

mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de
cadastro.

• No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com
um acréscimo de 20%. As vendas a prazo podem ser pagas no cartão ou no
boleto. Para pagamento com boleto, são gerados boletos bancários que são
entregues ao cliente e armazenados no sistema para lançamento posterior no
caixa. Para pagamento com cartão, os clientes com mais de 10 anos de
cadastro na loja ganham o mesmo desconto das compras a vista.
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs
Identificando generalização de casos de uso

Vender CDs

Atendente

Vender CDs a prazo Vender CDs à vista

Administrar estoque

Gerente
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs
Identificando mais generalização de casos de uso
Novos requisitos:
• As vendas podem ser à vista ou a prazo. Em ambos os casos o estoque é
atualizado e uma nota fiscal, entregue ao consumidor.

• No caso de uma venda à vista, clientes cadastrados na loja e que compram

mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de
cadastro.

• No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com
um acréscimo de 20%. As vendas a prazo podem ser pagas no cartão ou no
boleto. Para pagamento com boleto, são gerados boletos bancários que são
entregues ao cliente e armazenados no sistema para lançamento posterior no
caixa. Para pagamento com cartão, os clientes com mais de 10 anos de
cadastro na loja ganham o mesmo desconto das compras a vista.
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando generalização de casos de uso

Vender CDs

Atendente

Vender CDs a prazo Vender CDs à vista

Vender c/ boleto Vender c/ cartão

Administrar estoque

Gerente
Elementos – Diagrama de
Casos de Uso
• Elementos do diagrama

• Atores
• Casos de uso
• Relacionamentos
• Associação
• Generalização
• Dependência: Extensão e Inclusão
Elementos – Diagrama de
Casos de Uso
• Relacionamento de dependência:
Extensão:
• Representa uma variação/extensão do
comportamento do caso de uso base
• O caso de uso estendido só é executado
sob certas circunstâncias
• Separa partes obrigatórias de partes opcionais
• Partes obrigatórias: caso de uso base
• Partes opcionais: caso de uso estendido

Notação: <<extends>>
<<extends>>

A direção do relacionamento é do caso de uso extensor para o caso

de uso estendido
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando dependência: extensão

Novos requisitos:
• No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de
5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro.

• No caso de uma venda a prazo...

...Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja
ganham o mesmo desconto das compras à vista.
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando dependência: extensão

Vender CDs

Atendente

Vender CDs a prazo Vender CDs à vista

<<extend>>

<<extend>>
Vender c/ boleto Vender c/ cartão Calcular desconto

Administrar estoque

Gerente
Elementos – Diagrama de
Casos de Uso
• Relacionamento de dependência:
Inclusão:
• Um caso de uso pode incluir vários casos de uso

Notação: <<includes>>
<<includes>>
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando dependência: inclusão

Novos requisitos:
• Para efetuar vendas ou administrar estoque, atendentes e
gerentes terão que validar suas respectivas senhas de acesso ao
sistema.
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs

Identificando dependência: inclusão

Vender CDs

Atendente

Vender CDs a prazo Vender CDs à vista

<<extend>>

<<extend>>
Vender c/ boleto Vender c/ cartão Calcular desconto

<<include>>
Fazer login

<<include>>

Administrar estoque

Gerente
Elementos – Diagrama de
Casos de Uso
• Fronteira do Sistema
• Elemento opcional (mas essencial para um bom entendimento)
• Serve para definir a área de atuação do sistema

Notação:
Elementos – Diagrama de
Casos de Uso
Exemplo: Loja de CDs
Identificando a fronteira do sistema

Vender CDs

Atendente

Vender CDs a prazo Vender CDs à vista

<<extend>>

<<extend>>
Vender c/ boleto Vender c/ cartão Calcular desconto

<<include>>
Fazer login

<<include>>

Administrar estoque

Gerente
114
115
116
117
Fluxo de Eventos
• Parte mais importante de um use case
• Atividade de requisitos
• Define a sequência de ações entre o ator e o
sistema

118
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)

119
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 ATM. 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”; 120
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;

121
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 e debita o
valor da conta do usuário;
9. O sistema informa o término da operação.

122
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

124
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)

125
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.
126
• Fluxo excepcional:
• Se Cliente entra com senha inválida, o use case
reinicia.
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

127
Elementos de um Diag. Ativ.

128
Exercíácio
• Remodele o exercício anterior usando um
diagrama de atividade no lugar de linguagem
natural

129
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

130
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.

131