inf1413 aula13 maquinaestados - puc-rioinf1413/docs/inf1413_aula13... · 0itxlqdv gh hvwdgr h...
TRANSCRIPT
1
Máquinas de estado
Arndt von Staa
Departamento de Informática
PUC-Rio
Fevereiro 2018
2Arndt von Staa© LES/DI/PUC-RioFev 2018
Especificação
• Objetivo desta aula
– Apresentar máquinas de estado e seu uso ao gerar testes funcionais
• Justificativa
– Muitos testes dependem de uma sequência grande e complexa de decisões.
• Determinar que dados devem ser fornecidos, em que ordem e segundo que condições é uma tarefa complexa e propensa a enganos.
• Gerar e fornecer todos esses dados ao programa sob teste também tende a ser uma tarefa complexa e propensa a enganos.
• Consequentemente, deseja-se estabelecer uma técnica que permita gerar (quase automaticamente) os dados de teste
• Texto
– Pezzè, M.; Young, M.; Teste e Análise de Software; Porto Alegre, RS: Bookman; 2008, capítulo 14
2
3Arndt von Staa© LES/DI/PUC-RioFev 2018
Máquina de estados, exemplo telefone
Livre
Sinal dediscar
Sinal deocupado
Sinalrápido
Desconectado
Mensagemgravada
Alarmeaudível
tira do gancho
Conectado
Discando
1o. dígitodígito i
número válido
circuito estabelecido
receptor atende
receptor desliga
Põe no ganchoPõe no gancho
time out 1
time out 1
time out 2
time out 2
Destinoocupado
Não temcircuito
número ilegal
Exemplo: diagrama de atividades
http://www.uml-diagrams.org/online-shopping-uml-activity-diagram-example.html?context=activity-examples
Fev 2018 Arndt von Staa© LES/DI/PUC-Rio 4
3
Exemplo: UML State chart
5Arndt von Staa© LES/DI/PUC-RioFev 2018
http://www.uml-diagrams.org/bank-atm-uml-state-machine-diagram-example.html
Exemplo: rede de Petri (Petri net)
6Arndt von Staa© LES/DI/PUC-RioFev 2018
Sklenar, J.; PetriSim - Discrete Simulation Environment; University of Malta
Producer - Consumer control
4
7Arndt von Staa© LES/DI/PUC-RioFev 2018
Máquina de estados ilustração genérica
Início
Fim
Estado 1
Estado 2
Estado 3
Transição 5
Transição 2
Transição 3
Transição 6
Transição 4
Transição 1
8Arndt von Staa© LES/DI/PUC-RioFev 2018
Máquina de estados
• Uma máquina de estados é um grafo dirigido
– cada vértice é um estado
– podem existir dois tipos de vértices especiais: início e término
– cada aresta é uma transição
• cada aresta possui zero ou um rótulo condição que designa a condição ou o evento que permite seguir por aquela aresta
• uma aresta sem rótulo condição corresponde a um “else”– no máximo uma aresta de saída de um estado pode estar sem rótulo
5
Máquinas de estados generalizadas
• Em máquinas de estado generalizadas:– os estados podem conter código executável tão complexo
quanto se queira, mas precisa ter interfaces clara e corretamente definidas e respeitadas
– as transições podem conter, além de condições ou eventos, zero ou mais ações, possivelmente complexas, a serem efetuadas caso a máquina transite por aquela aresta
– os fragmentos de código contidos nos estados, e/ou nas arestas podem fazer uso de memória local (estruturas de dados) ou persistente (arquivos, bases de dados)
• ex. carrinho de compras sendo preenchido
• ex. tabelas de símbolos para filtros léxicos
9Arndt von Staa© LES/DI/PUC-RioFev 2018
Confronto com autômatos. Máquinas de estados generalizadas são uma generalização de autômatos tais como os usados ao processar strings (ex análise léxica, análise sintática). Em autômatos os estados somente leem caracteres e decidem qual a transição a percorrer. Em autômatos que admitem memória local com comportamento restrito (pilha na análise sintática de linguagens livres de contexto, fita em máquinas de Turing), os estados podem movimentar e ler da memória e tomar decisões baseados nos dados lidos, podem ainda gravar nessa memória.
Máquinas de estado e testes
• Máquinas de estado generalizadas são úteis
– engenharia direta cria máquinas de estado para fins de especificação, desenvolvimento e geração de suítes de teste
• dependendo da linguagem de representação utilizada ao criar máquinas de estado generalizadas é possível gerar código compilável
– engenharia reversa cria máquinas de estado para fins de geração de suítes de teste para sistemas existentes
10Arndt von Staa© LES/DI/PUC-RioFev 2018
Qualquer programa escrito para um computador baseado na arquitetura Von Neumann é uma máquina de estados.
6
Máquinas de estado e testes
• Um caso de teste de uma máquinas de estado generalizada é uma sequência de ações e condições correspondentes a um caminho viável através da máquina.
– caminho total de algum início até algum fim
– caminho parcial de algum estado a outro (pode ser o mesmo)
• Máquinas de estado devem ser semanticamente conexas• semanticamente conexo: a máquina é um grafo conexo e, considerando a
totalidade dos caminhos semanticamente viáveis de algum início a algum fim, o conjunto de todos os estados poderá ser atingido e o conjunto de todas as transições poderá ser percorrido.
• caminho semanticamente viável: existe pelo menos um conjunto de dados pertencentes ao domínio de dados de entrada que assegure que se possa percorrer o caminho.
• nem sempre é possível verificar se determinada máquina é semanticamente conexa (problema de computabilidade)
11Arndt von Staa© LES/DI/PUC-RioFev 2018
viável : um dado de entrada de um estado, mesmo que satisfaça a assertiva de entrada, pode impedir a seleção de uma ou mais das saídas desse estado, neste caso, caminhar usando uma destas saídas é inviável.
12Arndt von Staa© LES/DI/PUC-RioFev 2018
Exemplo: Interface humano computador
SelecionarDicionário
SelecionarConjunto de
ObjetosSelecionar
Ação
Aplicar ação atodos objetosselecionados
ESC ESC
OK Processoutodos
objetos
^F3
ESC
Comandodicionário
SelecionouDicionário
DicionárioVazio
SelecionouObjetos
SelecionouAção
Criar novoObjeto
SelecionarLinguagem deRepresentação
ESC &&Vazio
ESC &&Não Vazio
INS
• Existem uma ou mais linguagens de representação• Cada linguagem de representação possui n > 1 classes de objetos• Cada classe de objetos pode fazer parte de 1 ou mais linguagens de representação • Cada classe de objetos admite zero ou mais objetos registrados no dicionário da correspondente classe• A visualização de um dicionário exibe os nomes de todos os objetos da correspondente classe • Cada linguagem de representação define um conjunto de zero ou mais ações que podem ser realizadas a
partir de objetos de classes relacionadas com a linguagem
Usando teste exploratório cria-se uma máquina de estados
7
Máquinas de estados generalizadas
• Máquinas de estados generalizadas podem formar uma estrutura de decomposição– estados podem ser decompostos em máquinas de estado mais
detalhadas.
– nas máquinas resultado da decomposição• tudo que atinge o estado decomposto deve aparecer como origem
• e tudo que sai do estado decomposto deve aparecer como término
– pode-se criar uma máquina nível zero formada por um único estado e as origens e términos do processamento como um todo
• isso permite especificar a interface do artefato
13Arndt von Staa© LES/DI/PUC-RioFev 2018
Máquina de estados generalizada, exemplo
14Arndt von Staa© LES/DI/PUC-RioFev 2018
Efetuar Login
Termina execução
Emite nova senha
Autoriza uso
Sis Sis
Cadastrode usuáriosautorizados
Usuário
Diferentes, precisa consertar
Fornecerdados
Trocar a senha
Fornecer identi-ficação alternativa
{ "Cancelar" }
Não autoriza uso
{ "Login" }
{ "Mudarsenha"}
{ "Esqueci senha" }
Emite nova senha
Autorizauso
Dados ebotão Validar
dados
{Erro}{ "Cancelar" }
Cadastrode usuáriosautorizados
Usuário
Controlarerros
Cancela
{Erros além limite}
{Até limite erros}
{Erro léxico}
{ "Cancelar" }
{ "Muda" }
controle
dados
8
15Arndt von Staa© LES/DI/PUC-RioFev 2018
Máquina de estados - fluxo de controle
• A partir do vértice inicial a execução prossegue de estado a estado, de acordo com a condição que vale, ou o evento que ocorreu
• Caso nenhuma das condições ou evento de saída do estado corrente valha, ou caso não existam arestas de saída
– se for estado de término (final) o processamento termina
– se não for, o estado bloqueia erro de projeto da máquina
• ocorre se a disjunção (ou-tório ) de todos os rótulos de condição de saída de um estado não resultar em “true”
• Caso mais de uma das condições de saída do estado corrente valham
– o estado é ambíguo erro de projeto da máquina
• ocorre se existirem um ou mais pares de rótulos condição de saída em que a conjunção das condições (and) não resulta em “false”
assume-se que else corresponda a true
Máquinas de estados - fluxo de eventos
• Máquinas de eventos permitem projetar a sincronização de sistemas multi-threading (redes de petri, state charts)
• Em máquinas de eventos a progressão de estado para estado é dada por um evento – espera-se no estado pela ocorrência de um dos possíveis
eventos, descartando eventos não previstos
– usualmente o conjunto de eventos que podem ocorrer em um determinado estado é conhecido
• podem existir eventos genéricos, ex. cancela
– a progressão espera até que ocorra um evento
– caso a espera possa ser potencialmente ilimitada pode ser conveniente inserir um evento time-out
• no exemplo do telefone – caso a máquina esteja no estado livre, o telefone espera
indefinidamente pelo evento tirar do gancho
– caso a máquina esteja no estado digitando, a espera é limitada por um time-out
16Arndt von Staa© LES/DI/PUC-RioFev 2018
9
17Arndt von Staa© LES/DI/PUC-RioFev 2018
Máquinas de estado: aspectos positivos
• Máquinas de estado permitem
– visualizar e verificar se as ações e transições estão completas e corretas
– implementar condições compostas complexas
– gerar código diretamente a partir do diagrama
• máquinas de estado generalizadas são "código" em nível de abstração mais alto
– verificar as condições (assertivas) de entrada e saída
• verificação de modelos
• controle dinâmico da execução
– assegurar o comportamento do todo, através do controle do comportamento local estabelecido por cada um dos estados e correspondentes transições de saída
18Arndt von Staa© LES/DI/PUC-RioFev 2018
Máquinas de estado: aspectos negativos
• Tendem a levar a um conjunto muito grande de estados
– efeito papel de parede
– dimensão grande pode tornar difícil entender o diagrama
• Pode-se atenuar isso através de uma hierarquia de máquinas
– um estado pode ser decomposto (explodido) em uma nova máquina em um nível de abstração mais baixo
– tudo que atingia (ou saía) o estado decomposto tem que atingir (ou sair de) algum estado da nova máquina
10
Exemplo: Caso de uso Efetuar Login
fluxo principal 1. O componente limpa os campos e gera o captcha2. O usuário digita sua identificação, senha e captcha3. Quando o usuário selecionar a ação “Login” então
3.1 O controle de acesso verifica sintaticamente os dados fornecidos3.2 O controle de acesso verifica se <usuario, senha> existe3.3 O controle de acesso retorna ao sistema Sis, fornecendo a
condição “autorizar uso” e os direitos de uso correspondentes a <usuário, senha>
Fim quando4. Quando o usuário selecionar a ação “Mudar senha” então
4.1 O controle de acesso verifica sintaticamente os dados fornecidos4.2 O controle de acesso verifica se <usuario, senha> existe4.3 O controle de acesso ativa o caso de uso “Trocar a senha”4.4 Repete a partir de 1
Fim quando5. Quando o usuário selecionar a ação “Esqueci a senha” então
5.1 O controle de acesso verifica sintaticamente os dados fornecidos5.2 O controle de acesso verifica se usuário existe5.3 O controle de acesso ativa o caso de uso “Fornecer
identificação alternativa” 5.4 Se retornar do caso de 5.3, repete a partir de 1
Fim quando6. Quando o usuário selecionar a ação “Cancelar” então
6.1 O controle de acesso retorna ao sistema Sis, fornecendo acondição “cancelar uso” e direitos de uso nulo
Fim quando
A forma “... ativa ...” implica o uso de máquina de estados
Fev 2018 Arndt von Staa© LES/DI/PUC-Rio 19
Componente Login: especificação
fluxos alternativos
Evento 1/3.1, 4.1, 5.1 : O usuário digitou incorretamente a identificação ou o captcha
E1.1 Se for a quarta ou mais vez que ocorreu um evento de erro entãoE1.1.1. O controle de acesso emite a mensagem
“Acesso não autorizado” E1.1.2. O controle de acesso retorna ao sistema Sis, fornecendo a
condição “não autorizar uso” e direitos de uso nuloFim se E1.2. O controle de acesso emite a mensagem “Dados incorretos” E1.3. O controle de acesso retorna ao passo 1
Fim evento E1
Evento 2/3.2, 4.2 : O par <usuário, senha> não está definido E2.1 Se for a quarta ou mais vez que ocorreu um evento de erro então
E2.1.1. O controle de acesso emite a mensagem“Acesso não autorizado”
E2.1.2. O controle de acesso retorna ao sistema Sis, fornecendo acondição “não autorizar uso” e direitos de uso nulo
Fim se E2.2. O controle de acesso emite a mensagem “Usuário desconhecido” E2.3. O controle de acesso retorna ao passo 1
Fim evento E2
Fev 2018 Arndt von Staa© LES/DI/PUC-Rio 20
11
Componente Login: especificação
fluxos alternativos
Evento 3/5.2 : A identificação do usuário não existe no cadastroE3.1 Se for a quarta ou mais vez que ocorreu um evento de erro então
E3.1.1. O controle de acesso emite a mensagem“Acesso não autorizado”
E3.1.2. O controle de acesso retorna ao sistema Sis, fornecendo acondição “não autorizar uso” e direitos de uso nulo
Fim se E3.2. O controle de acesso emite a mensagem “Usuário desconhecido” E3.3. O controle de acesso retorna ao passo 1
Fim evento E3
Evento E4: o usuário clica “Cancelar” em qualquer lugarE4.1 O sistema solicita confirmação do cancelamentoE4.2 Se usuário confirma o cancelamento
E4.2.1 O controle de acesso retorna fornecendo o conjunto “cancelar uso” ao sistema Sis
Fim seE4.3 O controle de acesso retorna ao passo 1
Fim evento E4.
Veja Aula 04 Especificações, resumo
Fev 2018 Arndt von Staa© LES/DI/PUC-Rio 21
Máquina de estados derivada do caso de uso
22Arndt von Staa© LES/DI/PUC-RioFev 2018
Com pequenas alterações para não tornar ainda mais complexo o diagrama
O caso de uso pode ser transformado em uma máquina de estados de forma automática
• A geração automática costuma produzir um grafo confuso.
• No caso de geração automatizada da suíte de teste isso é um problema menor.
• Ao gerar a suíte a mão é motivo para muitos erros de geração.
2
3
3.1
3.2
Esqueci
4
4.1
4.2
4.3
5
5.1
5.2
5.3
Cancela
6
6.1
Login
Muda
Esqueci
=> Cancela
E1
E1.1!sintx
!sintx
!sintx não autor.
>=4
>=4
>=4E2
E2.1
!existe
!existe
E3
E3.1
ESC
ESC
!usu
autor
12
23Arndt von Staa© LES/DI/PUC-RioFev 2018
Casos de uso como máquina de estado
O caso de uso pode ser transformado manualmente em uma máquina de estados mais “civilizada”, sintaxe:
• Interações com o usuário são tracejadas
• Pontos de início são disparados ao acionar
• Pontos de término informam o significado do término
• Arestas de controle são dirigidas e vão de estado a estado
• As arestas de controle são rotuladas
– o rótulo informa a condição que faz seguir por aquela aresta
– condições que correspondem a ações do usuário, ex. teclou um botão, têm o seu texto redigido entre aspas
– teclas de atalho devem ser identificadas por um nome entre aspas, e não pelo valor do atalho
• Inclusões e extensões seguem o padrão de caso de uso
24Arndt von Staa© LES/DI/PUC-RioFev 2018
Máquina de estados criada diretamente
• Contexto do caso de uso diagrama nível 0
Efetuar Login
Termina execução
Emite nova senha
Autoriza uso
Sis Sis
Cadastrode usuáriosautorizados
Usuário
13
25Arndt von Staa© LES/DI/PUC-RioFev 2018
Componente Login, máquina de estados
Início
• A máquina pode ser melhorada? • Considere a separação da entrada de dados da verificação dos dados
• verificação léxica pode ser realizada imediatamente• verificação envolvendo bases de dados, métodos etc. devem estar separados da
entrada
Efetuar Login Trocar a senha
Fornecer identi-ficação alternativa
Confirmarusuário
Usuário
{ "Cancelar" ou erro }
Termina execução
{ "Login" }
{ "Login" }
{ "Mudar senha"}
{ "Esqueci senha" }
Emite nova senha
{ "Cancelar" }
Autorizauso
{ "Cancelar" ou erro }
Versão inicial
26Arndt von Staa© LES/DI/PUC-RioFev 2018
Componente Login, máquina de estados
• A máquina pode ser melhorada mais ainda?• Considere fatorar o controle de número de erros.
Fornecerdados
Trocar a senha
Fornecer identi-ficação alternativa
{ "Cancelar" }
Não autoriza uso
{ "Login" }
{ "Mudarsenha"}
{ "Esqueci senha" }
Emite nova senha
Autorizauso
Dados ebotão Validar
dados
{ Quarto oumais erro }
{1o., 2o. ou3o. erro}
{ "Cancelar" }
Cadastrode usuáriosautorizados
Usuário
SistemaSis
versão melhorada, ainda não final
14
Fornecerdados
Trocar a senha
Fornecer identi-ficação alternativa
{ "Cancelar" }
Não autoriza uso
{ "Login" }
{ "Esquecisenha” }
Emite nova senha
Autorizauso
Dados ebotão Validar
dados
Controlarerros
{ Quarto oumais erro }
{ "Cancelar" }
Cadastrode usuáriosautorizados
Usuário
SistemaSis
{erro}{1o. a 3o.erro}
{erro}
{ "OK" }{ "Mudarsenha"}
27Arndt von Staa© LES/DI/PUC-RioFev 2018
Componente Login, máquina de estados
• Ainda tem problemas a serem resolvidos?• Considere a separação de “cancelar” e “não autorizar”, cancelar troca de senha, ...
• cada saída de um estado ou da máquina deve explicitar a causa da escolha
cancelar ?
Qual é a causa do término?
Quase...
28Arndt von Staa© LES/DI/PUC-RioFev 2018
Componente Login, máquina de estados
Fornecerdados
Trocar a senha
Fornecer identi-ficação alternativa
{ "Cancelar" }
Não autoriza uso
{ "Login" }
{ "Mudarsenha"}
{ "Esqueci senha" }
Emite nova senha
Autorizauso
Dados ebotão Validar
dados
{Erro}{ "Cancelar" }
Cadastrode usuáriosautorizados
Usuário
Controlarerros
Cancela
{Erros além limite}
{Até limite erros}
{Erro léxico}
{ "Cancelar" }
{ "Muda" }
controle
dados
Versão final
15
Componente Login, máquina de estados
29Arndt von Staa© LES/DI/PUC-RioFev 2018
Efetuar Login
Não autoriza uso
Emite nova senha
Autoriza uso
Sis Sis
Cadastrode usuáriosautorizados
UsuárioCancela
Fornecerdados
Trocar a senha
Fornecer identi-ficação alternativa
{ "Cancelar" }
Não autoriza uso
{ "Login" }
{ "Mudarsenha"}
{ "Esqueci senha" }
Emite nova senha
Autorizauso
Dados ebotão Validar
dados
{Erro}{ "Cancelar" }
Cadastrode usuáriosautorizados
Usuário
Controlarerros
Cancela
{Erros além limite}
{Até limite erros}
{Erro léxico}
{ "Cancelar" }
{ "Muda" }
controle
dados
Máquina de estados, implementação
• Organização do código de um interpretador de máquina de estados
Fev 201830Arndt von Staa © LES/DI/PUC-Rio
Início
Selecionarestado
Estado 1 Estado 2 Estado n
{estado != FIM}
{estado == E1} {estado == En}
se estado_anterior != estado:
registrar estado_anterior = estadoselecionar a transição a ser efetuada: determinar próximo_estado
efetuar a função associada à transiçãoregistrar estado = próximo_estado
executar ação de entradaprocessar estado
estado :: estado_corrente
se próximo_estado != estado: executar ação de saída
{estado == E2}
. . .
Assume-se que exista somente uma assertiva de saída em cada estado
16
31Arndt von Staa© LES/DI/PUC-RioFev 2018
Exemplo: Fornecer dados 1 / 4
Estado Fornecer dados
Resumo Recebe os dados do usuário e efetua a verificação independente de cadastro (verificação léxica)
Escopo não se aplica a estados
Ator principal não se aplica a estados
Interessados não se aplica a estados
Invariante O número de erros identificados na presente instância de uso é menor ou igual a três.
Pré condição
Acionamento Obter dados inicia quando • ou o sistema Sis solicitar dados do usuário para autorizar o uso• ou o estado validar dados encontra dados ilegais e solicitar novos
dados
32Arndt von Staa© LES/DI/PUC-RioFev 2018
Exemplo: Fornecer dados 2 / 4
Fluxo principal 1. O controle de acesso limpa os campos de entrada2. O controle acesso gera o captcha exibido3. O usuário digita sua identificação e senha, e o captcha4. O usuário clica a ação a ser realizada5. O controle de acesso valida a corretude léxica de idUsuario6. O controle de acesso verifica o captcha digitado7. O controle de acesso ativa o caso de uso Validar Dados
17
33Arndt von Staa© LES/DI/PUC-RioFev 2018
Exemplo: Fornecer dados 3 / 4
Fluxos alternativos
Evento E1: o usuário clica “cancelar”E1.1 O controle de acesso fecha a janela de identificação de usuárioE1.2 O controle de acesso fornece o controle “cancelar uso” ao
sistema SisFim evento E1.
Evento E2/6: o usuário digita captcha incorretoE2.1 O controle de acesso emite a mensagem
“Captcha incorreto” E2.2 Ativa o estado “controlar erros”
Fim evento E2.
Evento E3/5: o usuário fornece identificação usuário lexicamente incorreta
E3.1 O controle de acesso emite a mensagem “Usuário incorreto”
E3.2 Ativa o estado “controlar erros” Fim evento E3.
E3 - Especificação léxica de usuário ver: regra de negócio idUsuario
E1. Melhor:E1.1 O controle acesso prepara o retorno <Cancelar, direitos: vazio>E1.2 Termina
34Arndt von Staa© LES/DI/PUC-RioFev 2018
Pós condições Dados e ação a executar fornecidos ao caso de uso Validar dados
Garantia mínima
• N/A
Requisitos • -.-
Regras de negócio
• idUsuario deve ter entre 5 e 30 caracteres• idUsuario não deve conter letras diacríticas • idUsuario não deve conter dígitos• idUsuario não deve conter brancos• idUsuario pode conter somente os caracteres especiais: ‘–’ e ‘.’
Casos de uso correlatos
Validar dadosReconfirmar usuário correnteTrocar a senhaFornecer identificação alternativa
Exemplo: Fornecer dados 4 / 4
18
35Arndt von Staa© LES/DI/PUC-RioFev 2018
Conversão “Fornecer dados” para tabela de decisão
1 2 3 4 5 6 7 8 9 10
Usuário correto - s s s n n n - - -
Captcha correto - s s s s s s n n n
xorob Tecla “Login” n s n n s n n s n n
xorob “Mudar senha” n - s n - s n - s n
xorob “Esqueci senha” n - - s - - s - - s
xorob “Cancelar” s n n n n n n n n n
Ativar “validar” x x x
Ativar “erro” x x x x x x
Erro “Captcha”x x x
Erro “Léxico” x x x
Termina “cancela” x
xorob – exclusive or obrigatório exatamente uma das condições deve ser true
A tabela está correta?
36Arndt von Staa© LES/DI/PUC-RioFev 2018
Conversão “Fornecer dados” para tabela de decisão
1 2 3 4 5 6 7 S
Usuário lex correto - s s s n s s
Captcha correto - s s s - n s
xorob “Login” - s n n - - n
xorob “Mudar senha” - - s n - - n
xorob “Esqueci senha” - - - s - - n
xorob “Cancelar” s n n n n n n
Ativar “validar” x x x
Ativar “erro” x x
Erro “captcha” x
Erro “usuário” x
Termina “cancela” x
Impossível x
Contagem 32 4 2 1 16 8 1 64
A tabela está correta?
Qual seria a ordem esperada das verificações léxicas de usuário e captcha?
Isso afeta a tabela?
19
37Arndt von Staa© LES/DI/PUC-RioFev 2018
Exemplo: Validar dados 1 / 3
Estado Validar dados e ação
Resumo Valida os dados e a ação solicitada com relação ao cadastro de usuários autorizados
Invariante
Pré condição Nome lexicamente correto, senha qq, ação selecionada é uma de { login, mudaSenha, novaSenha }
Acionamento Validar dados inicia ao receber o controle de Obter dados
Fluxo principal 1. O Controle de acesso busca os dados do idUsuario no cadastro2. Se a ação solicitada for “Esqueci senha”
Então2.1 Ativa o estado Fornecer identificação alternativa
FimSe3. O Controle de acesso verifica se a senha fornecida corresponde a
uma das registradas para este usuário4. Se a ação solicitada for “Login”
Então4.1.1 O Controle de acesso prepara o retorno <autorizado, direitos:
de < idUsuario, senha>>4.1.2 Termina
Senão4.2 O Controle de acesso ativa o estado Trocar senha
FimSe
Não deveria ser :se ação solicitada é “trocar senha” ?
resultado do estado fornecer dados
38Arndt von Staa© LES/DI/PUC-RioFev 2018
Exemplo: Validar dados 2 / 3
Fluxos alternativos
E1. Evento: Identificação do usuário não existe no CadastroE1.1. O Controle de acesso exibe a mensagem “Usuário desconhecido”E1.2. O Controle de acesso ativa o estado “Controlar erros”
Fim evento
E2. Evento: Senha não fornecida, ou lexicamente errada ou não corresponde a qualquer uma das senhas de idUsuario
E2.1. O Controle de acesso exibe a mensagem “Usuário desconhecido”E2.2. O Controle de acesso ativa o estado “Controlar erros”
Fim evento
Razões de segurança indicam que as duas mensagens devem ser alguma coisa similar a “Usuário desconhecido”. Um possível agressor ficará na dúvida se o problema é do idUsuario ou da Senha.
Problema 1: como discernir o erro de dados observado durante os testes?
Problema 2: a condição do evento E2 contém uma expressão lógica composta. Deveria ser simples para que se possa criar tabelas de decisão com condições binárias.
20
39Arndt von Staa© LES/DI/PUC-RioFev 2018
Pós condições
Garantia mínima
Requisitos • Não deve ser possível discernir se o erro foi idUsuario incorreto ou se senha foi incorreta
Regras de negócio
Casos de uso correlatos
Fornecer dadosReconfirmar usuário correnteTrocar a senhaFornecer identificação alternativa
Exemplo: Validar dados 3 / 3
40Arndt von Staa© LES/DI/PUC-RioFev 2018
Conversão “Validar dados” para tabela de decisão
1 2 3 4 5 6 7 8 9
Usuário conhecido s s s s s n n n -
Senha corresponde s s - n n - - - -
xorob Tecla “Login” s n n s n s n n n
xorob “Mudar senha” - s n - s - s n n
xorob “Esqueci senha” - - s - - - - s n
Autorizar x
Ativar “Controlar” x x x x x
Ativar “Trocar” x
Ativar “Esqueci” x
Impossível x
Msg: “Usuário desconhecido”
x x x x x
A tabela está correta?
21
41Arndt von Staa© LES/DI/PUC-RioFev 2018
Nível 0 – Final Autoriza uso
Estado Final: Autoriza uso
Assertivas de saída da máquina decomposta
1. retornou < Autorizado, direitos de acesso de <idUsuario, Senha>>
Fluxo 1. Controle de acesso oblitera os registros decriptados do cadastro2. Controle de acesso fecha a janela3. Controle de acesso retorna < Autorizado, direitos de acesso de:
<idUsuario, Senha>>
O valor retornado poderia ser um objeto da classe “Autorizacao”. Exemplos de atributos e métodos que essa classe pode definir :• atributo idUnicaUsuario – um inteiro identificador interno gerado ao cadastrar o par <idUsuario,
senha>• atributo condicao uma enumeração tpCondicao :: {AUTORIZA, CANCELA, NOVA_SENHA,
NÃO_AUTORIZA}• atributo lista de idDireito’s – criptografada• bool TemDireitos( char idDireito ) :: retorna true sse a condição é AUTORIZA e a lista de
idDireitos contém idDireito• tpCondicao RevalidaUsuario( ) :: abre uma janela similar a login e que contém somente o campo
senha e os botões Login e Cancelar. Retorna AUTORIZA sse a senha fornecida correspondem à idUnicaUsuario
42Arndt von Staa© LES/DI/PUC-RioFev 2018
O resto fica para exercício
22
Apêndice
43Arndt von Staa© LES/DI/PUC-RioFev 2018
44Arndt von Staa© LES/DI/PUC-RioFev 2018
Máquina de estados, caminhos
Caminhos descrevem os estados de um caminho do estado inicial para algum estado final – caminhos são casos de teste abstratosExemplos de caminhos
Fornecer dados; Validar dados; AutorizaFornecer dados; Validar dados; Controlar Erros; Fornecer dados; Validar dados; Trocar
senha - Muda; Fornecer dados; Validar dados; Autoriza...
Em aula futura será discutido como criar os caminhos de forma sistemática
Fornecerdados
Trocar a senha
Fornecer identi-ficação alternativa
{ "Cancelar" }
Não autoriza uso
{ "Login" }
{ "Mudarsenha"}
{ "Esqueci senha" }
Emite nova senha
Autorizauso
Dados ebotão Validar
dados
{Erro}{ "Cancelar" }
Cadastrode usuáriosautorizados
Usuário
Controlarerros
Cancela
{Erros além limite}
{Até limite erros}
{Erro léxico}
{ "Cancelar" }
{ "Muda" }
controle
dados
23
Máquina de estados, casos teste semânticos
• Dado o caminho, um caso de teste abstrato
– Fornecer dados; Validar dados; Autoriza
• Converter para caso de teste semântico
– precisa analisar o caminho,
– usualmente faz-se de trás para diante examinando
• a condição associada à aresta
• as assertivas de saída (origem) e entrada (destino) dos estados
• processamento no estado origem da aresta
• Resultado
– Autoriza: par <Usuário , senha> existe, direitos par definidos
– Validar dados -> Autoriza usuário existe, par <usuário, senha> existe, botão = Login
– Fornecer dados -> Validar dados usuário correto, senha digitada, captcha correto, botão = Login
45Arndt von Staa© LES/DI/PUC-RioFev 2018
Qual é a ideia?
• Criar uma máquina de estados em que cada estado
– ou é "simples"
– ou é decomposto em outra máquina de estados
• Para cada estado
– criar um caso de uso do estado
• fluxo principal
• zero ou mais fluxos alternativos
• o término de um fluxo é uma transição de estado ou o término da máquina raiz
• O término de um fluxo corresponde
– ou a uma mudança de estado
– ou ao término da máquina raiz
– ou ao término da máquina de decomposição
• neste caso a transição (oráculo da tabela de decisão) é uma das transições de saída do estado "pai"
46Arndt von Staa© LES/DI/PUC-RioFev 2018
24
Qual é a ideia?
• Para cada estado cria-se uma tabela de decisão
– a seleção de valores deve obedecer aos critérios de valoração
• espera-se que o número de condições por estado seja pequeno, de modo que se controle o número de colunas das tabelas de decisão
• Cria-se a lista completa de caminhos da máquina de estados
– repetições são resolvidas com base no arrasto e no limite de iterações caso exista
– cada caminho na máquina de estados corresponde a uma cena
• espera-se que cada máquina contenha poucos estados, de modo que o número de cenas seja pequeno
– cada caminho determina as condições saída da tabela de decisão de cada um dos estados
• O teste cobre a combinação de condições em cada estado, mas não realiza as combinações entre estados
47Arndt von Staa© LES/DI/PUC-RioFev 2018
48Arndt von Staa© LES/DI/PUC-RioFev 2018
Referências bibliográficas
• Holcombe, M.; Bogdanov, K.; Gheorghe, M.; “Functional Test Generation for Extreme Programming”; Proceedings of the XP2001 Second International Conference on Extreme Programming and Flexible Processes in Software Engineering; 2001; pags 109-113 Buscado em: 19/08/2004; URL: http://www.dcs.shef.ac.uk/~wmlh/XPtest.pdf
25
49Arndt von Staa© LES/DI/PUC-RioFev 2018
FIM