Máquinas de Estado

Disciplina: Verificação de Software
Professora: Patrícia Machado
Aluno: Daniel Aguiar
 Roteiro
● Motivação
● Máquinas de estado e Diagramas de Transição
● O modelo FREE
● Projeto de teste baseado em estado
● Escolhendo a estratégia
 Motivação
● O encapsulamento de atributos e métodos é fundamental para OO
● Interações resultantes, dependências e restrições de seqüências de 
mensagens formam o comportamento de uma classe
● Combinação do número de seqüências de mensagens e variáveis é 
muito grande, sendo obstáculo na representação de estados
● Máquinas de estados provêem um modo compacto para tal 
representação
● São então apropriadas para design e teste de comportamentos 
complexos
 Máquina de Estado
● É um sistema cuja saída é determinada por entradas passadas e 
corrente
● O efeito de entradas anteriores é representado por um estado
● É uma abstração composta por eventos (entradas), estados e ações 
(saídas)
● Modela sistemas seqüenciais
● Foram aplicadas para design de software a partir da década de 60
● Foram incorporadas pela UML
 Diagramas de Transição de Estados
● Representação gráfica de máquinas de estado
● Nós representam estados e arcos (direcionados) representam 
transições
● Rótulos nos arcos representam eventos e ações
Diagramas de Transição de Estados
Diagramas de Transição de Estados
 Diagramas de Transição de Estados
● Transições guardadas
– Condições podem ser expressas através de guardas nas 
transições
– Uma transição guardada não pode disparar até que:
● O sistema esteja no estado de aceitação p/ a transição
● O evento a ser avaliado pela guarda ocorra
● O predicado da guarda possua valor verdade “ true”
 Mealy e Moore
● São as duas principais variantes de modelos de estados
● Mealy
– Uma transição pode ter uma ação de saída e qualquer ação de 
saída pode ser usada em mais de uma transição
– Ações de saída não são associadas a estados, que são passivos
– Neste caso as ações de saída podem ser associadas a mais de 
um estado
– Representa a evolução de estados, numa seqüência
Mealy e Moore
 Mealy e Moore
● Moore
– Transições não possuem uma ação de saída
– Uma ação de saída está associada a um estado, que neste caso é 
ativo. O estado produz a ação de saída.
– Ou seja, cada par único ação/estado é representado através de 
um estado
– Utilizado p/ representar estados observáveis eternamente
– Produz modelos maiores que o de mealy
Mealy e Moore
 Limitações do Modelo
● O modelo possui várias limitações como ferramenta da ES e para 
teste de implementações OO:
– Não é específico para sistemas OO
– Possui escalabilidade limitada. Diagramas muito grandes são 
de difícil leitura, mesmo com criteriosa nomenclatura. Neste 
caso para amenizar, hierarquia de modelo ajuda, porém não é 
feita com este modelo básico.
– Concorrência não é modelada. A concorrência pode ser 
modelada através de máquina produto, obtida pelo produto de 
duas ou mais máquinas básicas.
 StateChart
● Desenvolvidas para modelar sistemas complexos
● Comportamento de máquina produto
● Objetiva superar os problemas de 
– escalabilidade e 
– concorrência do modelo básico
● Representa hierarquia através de agregação, onde cada modelo 
fazendo parte de uma agregação é visto como um processo
StateChart
 O Modelo FREE (Flattened Regular 
Expression)
● Desenvolvido para prover um modelo testável para o 
comportamento da classe
● A classe sob teste é “ achatada”  para representar o comportamento 
herdado de outras classes, ou seja, a classe é representada como se 
englobasse todos os métodos e atributos de suas super­classes
● O comportamento é modelado através de estados, eventos e ações
● Toda máquina tem uma expressão regular equivalente
● Tem restrições e definições não encontradas em UML, porém, 
pode ser representado usando UML
● O foco deste modelo é o estado do objeto na ativação e desativação 
de métodos
● Estados resultam  da computação de métodos
 O Modelo FREE
● Apesar de estes modelos serem úteis para análise e design, são 
inadequados para teste
● Alguns modelos formais definem estados em  termos de pré e pós 
condições e invariantes de estados, não sendo atingidos pelas 
deficiências, mas perdendo certas características úteis para teste
● Um modelo testável tem informação suficiente para permitir a 
geração automática de casos de teste
● Para tanto o modelo deve refletir de forma completa a 
implementação a ser testada, abstraindo detalhes que tornam  os 
custos do teste impraticáveis
● O modelo não deve ser ambíguo
 O Modelo FREE 
● Estados
– De uma perspectiva de controle, um estado é apenas um 
placeholder, útil para representar seqüências
– O modelo deve permitir a criação de código que responda à 
questão: “ O objeto está no estado x?”
– Os estados de uma classe são um subconjunto do conjunto de 
todas as combinações possíveis dos valores de variáveis de 
instância
 O Modelo FREE 
● Invariantes de estado
– Assim como todos os valores de instâncias válidas de uma 
classe podem ser expressos por invariante de classe, um estado 
válido pode ser expresso através de variante de estado
– Um invariante pode ser implementado como uma fórmula de 
predicado, através da qual tal estado pode ser facilmente 
checado
– Tem relação direta com invariante de classe e pós condições
– Deve definir um subconjunto de valores permitidos por uma 
invariante de classe
 O Modelo FREE 
● Escopo e Granularidade
– O conceito de estado de objeto ou classe varia de acordo com a 
visibilidade, escopo e granularidade
– Visibilidade pode ser
● Abstrata: visão externa, interface pública
● Concreta: implementação
– Escopo é o nível de abstração:
● Limitado: apenas valores de variáveis de estado são 
considerados
● Recursivo: Todos os níveis de abstração são “ achatados”  
até que apenas dados primitivos permaneçam
 O Modelo FREE 
● Escopo e Granularidade (cont.)
– Granularidade é a unidade de definição para um estado
● Agregada: estados consistem de número arbitrário de 
valores de um conjunto combinado de valores
● Primitiva: cada membro deste conjunto compõe um estado
 O Modelo FREE 
● Transições
– Combinação única de invariantes de estado, evento associado e 
expressões de guarda (opcional)
– Pode ou não estar associada a uma ação (estado de aceitação e 
resultante podem ser o mesmo)
– Apenas um estado é o resultado de uma transição particular
– Evento: qualquer estímulo ao objeto (mensagem, etc...)
– Guarda: expressão de predicado associada ao evento
– Ação: resposta que uma classe pode produzir em resposta a um 
estímulo
 O Modelo FREE 
● Estados Alfa e Omega
– Para alguns projetos de testes, a noção de estados inicial e final 
é problemática
– Se um construtor pode criar estados iniciais que possuem 
comportamentos diferentes, então um único estado inicial não 
é suficiente para modelar a comportamento da classe
– Para simplificar o teste de construtores múltiplos, destrutores e 
tratamento de exceção, são definidos dois estados especiais: 
alfa () e omega ()
 O Modelo FREE 
● Estados Alfa e Omega
– Alfa: estado nulo que representa a declaração de um objeto 
antes de sua construção. 
● Aceita apenas um construtor
– Omega: alcançado após o descarte do objeto
● Pode diferir do estado final modelado
● Permite modelagem e teste sistemático de destrutores, 
coletores de lixo e outras ações de terminação
 O Modelo FREE 
“ Achatando”  a hierarquia de classes
● Herança deve ser considerada para decidir uma prudente extensão 
do teste para a subclasse
● Classes englobam o comportamento de superclasses
● Em uma representação as pré­condições de um método da 
subclasse não podem ser mais restritivos que as da superclasse, 
assim como as pós­condições não podem ser menos restritivas
 O Modelo FREE 
“ Achatando”  a hierarquia de classes
● As representações de subclasses podem ser:
– Composição Ortogonal: subclasse herda todas as características 
de suas superclasses e define algumas novas
– Concatenação: a subclasse não tem características próprias. 
Ex.: A unificação de duas classes
– Particionamento de estado e adição de sub­estados: a subclasse 
define novos comportamentos através de redefinição de 
métodos (overriding)
– Redirecionamento de transição: subclasse redefine o estado 
resultante de alguns eventos
 O Modelo FREE 
“ Achatando”  a hierarquia de classes
 Projeto de teste baseado em estado
● Nem todas as implementações são bem adaptadas para teste 
baseado em estados
● Uma implementação de um comportamento seqüencial exige um 
modelo de estados completo, consistente e correto para ser testado
● Um modelo de teste deve representar corretamente os requisitos e 
refletir a implementação sob teste (IUT) de forma precisa
● Para evitar omissões e inconsistências no modelo, este deve ser 
cuidadosamente examinado, parte a parte de sua composição
 A estratégia N+
● Integra elementos de teste baseado em estados avançado, modelos 
de estado UML e considerações de teste atribuídas somente a 
implementações OO
● Utiliza modelo de estados de “ achatamento”
● Todas as transições implícitas são executadas para revelar 
caminhos ilegais
● A implementação deve prover habilidade de reportar o estado 
resultante de forma confiável
● Um conjunto de testes N+ deve atingir a cobertura N+, revelando 
falhas de controle de estado, caminhos ilegais e bugs de estados
 A estratégia N+
● Como inspeciona a IUT em um escopo “ achatado” , revela 
problemas de interação de classes
● revela falhas em cada transição alfa e omega
● O passos p/ geração de testes N+ são:
– Desenvolve o modelo FREE da IUT
– Gera os casos de teste de caminhos de ida e volta
– Gera os casos de teste de caminhos ilegais
– “ Sensibiliza”  as transições em cada caso de teste
 A estratégia N+
Geração dos caminhos de ida e volta
● Com o modelo testável em mãos, deve­se construir a árvore de 
transições
● Isso inclui toda a seqüência que começa e termina no mesmo 
estado (caminhos de ida e volta)
● O estado inicial é transcrito como nó raiz
● Para cada transição adiciona­se um arco, levando a nodos que 
representam estados resultantes
● Nó folha é marcado como nó terminal caso o estado que representa 
já tenha sido desenhado (passo anterior), seja final, ou um estado 
omega
 A estratégia N+
Geração dos caminhos de ida e volta
● O procedimento é repetido até que todos os nós folhas sejam 
terminais
● Através de conjuntos de teste de caminhos de ida e volta pode­se 
detectar importantes classes de erros:
– Transições incorretas ou ausente
– Respostas incorretas ou ausentes em uma transição
– Ausência de estados necessários e até corrompidos
● Caso todos os testes passem, a classe sob teste está conforme o 
comportamento explícito do modelo
 A estratégia N+
Caminhos ilegais
● Caminhos de ida e volta revelam erros apenas do comportamento 
explícito
● Porém  tem­se que garantir que mudanças incorretas de estado não 
ocorrem
● Casos de teste que envolvem caminhos ilegais são necessários para 
modelos que não têm todos pares de evento/estado definidos
● Comportamento implícito corresponde a situações excepcionais 
como falhas no ambiente e outros eventos que não são diretamente 
testados através da interface da IUT
● Caminhos ilegais são possíveis para cada transição não 
especificada e para todas as situações em que as guardas das 
transições são falsas
 A estratégia N+
Sensibilização de transição
● Trata­se de produzir valores que passem como verdadeiros pelas 
transições desejadas
● Saídas de eventos utilizadas em guardas subseqüentes tornam a 
análise mais complexa
● Valores necessários para expressões condicionais devem ser 
determinados através de análises
 Escolhendo a estratégia
● Boa parte da experiência adquirida com teste de hardware e 
telecomunicações pôde ser aplicada a teste de software OO
● O poder de testes baseados em estados foi estabelecido para essas 
tecnologias usando o mesmo modelo de mealy utilizado para 
classes
● Assim, com uma reinterpretação, as estratégias podem ser 
utilizadas para implementações OO
● Ao escolher uma estratégia é necessário fazer a decisão levando­se 
em conta
– Simplicidade da máquina resultante
– Tratamento de hierarquia: importante para reuso
– Número de transições alcançadas no teste