INF1413 Aula13 MaquinaEstados - PUC-Rioinf1413/docs/INF1413_Aula13... · 0itxlqdv gh hvwdgr h...

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


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


http://www.uml-diagrams.org/bank-atm-uml-state-machine-diagram-example.html

Exemplo: rede de Petri (Petri net)


Sklenar, J.; PetriSim - Discrete Simulation Environment; University of Malta

Producer - Consumer control

4


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


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


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


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)


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.


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


Máquina de estados generalizada, exemplo


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" }


Usuário

Controlarerros

Cancela

{Erros além limite}

{Até limite erros}

{Erro léxico}

{ "Cancelar" }

{ "Muda" }

controle

dados

8


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


9


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


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


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


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


Máquina de estados derivada do caso de uso


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


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


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


Usuário

13


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


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



• A máquina pode ser melhorada mais ainda?• Considere fatorar o controle de número de erros.

Fornecerdados

Trocar a senha


{ "Cancelar" }

Não autoriza uso

{ "Login" }

{ "Mudarsenha"}

{ "Esqueci senha" }

Emite nova senha

Autorizauso


dados

{ Quarto oumais erro }

{1o., 2o. ou3o. erro}

{ "Cancelar" }


Usuário

SistemaSis

versão melhorada, ainda não final

14

Fornecerdados

Trocar a senha


{ "Cancelar" }

Não autoriza uso

{ "Login" }

{ "Esquecisenha” }

Emite nova senha

Autorizauso


dados

Controlarerros

{ Quarto oumais erro }

{ "Cancelar" }


Usuário

SistemaSis

{erro}{1o. a 3o.erro}

{erro}

{ "OK" }{ "Mudarsenha"}



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



Fornecerdados

Trocar a senha


{ "Cancelar" }

Não autoriza uso

{ "Login" }

{ "Mudarsenha"}

{ "Esqueci senha" }

Emite nova senha

Autorizauso


dados



Usuário

Controlarerros

Cancela


{Até limite erros}

{Erro léxico}

{ "Cancelar" }

{ "Muda" }

controle

dados

Versão final

15



Efetuar Login

Não autoriza uso

Emite nova senha

Autoriza uso

Sis Sis


UsuárioCancela

Fornecerdados

Trocar a senha


{ "Cancelar" }

Não autoriza uso

{ "Login" }

{ "Mudarsenha"}

{ "Esqueci senha" }

Emite nova senha

Autorizauso


dados



Usuário

Controlarerros

Cancela


{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


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



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



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


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


18


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?


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


Qual seria a ordem esperada das verificações léxicas de usuário e captcha?

Isso afeta a tabela?

19


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



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


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



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


21


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


O resto fica para exercício

22

Apêndice



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


{ "Cancelar" }

Não autoriza uso

{ "Login" }

{ "Mudarsenha"}

{ "Esqueci senha" }

Emite nova senha

Autorizauso


dados



Usuário

Controlarerros

Cancela


{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


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"


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



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


FIM

INF1413 Aula13 MaquinaEstados - PUC-Rioinf1413/docs/INF1413_Aula13... · 0itxlqdv gh hvwdgr h...

Documents

Transcript of INF1413 Aula13 MaquinaEstados - PUC-Rioinf1413/docs/INF1413_Aula13... · 0itxlqdv gh hvwdgr h...